2006 EPITECH 2-CSI Merise - bliaudet.free.fr

EPITECH - Conception des systèmes d’information - 2005 - page 1

CONCEPTION des SYSTEMES d’INFORMATION - MERISE

Epitech 2 - 2005-2006

Bertrand LIAUDET 1

0. SOMMAIRE

1. INTRODUCTION 5 1.1 Conception 5

Division du travail : Conception vs. Réalisation (ou Exécution) 5 Le cycle en V 5 Analyse fonctionnelle vs. Analyse organique (architectonique) 6 Réalisation et langage de programmation 7

1.2 Système d’information 8 1.3 MERISE 9

Définition 9 Historique 9

1.4 Distinction entre données et traitement : le cycle d’abstraction MERISE 10 Le cycle d’abstraction 10

2. PREMIERE APPROCHE 12 2.1 Exemple : soit le cahier des charges suivant 12 2.2 La description conceptuelle de l’entreprise 12 2.3 Acteur, flux, événement, diagramme des flux 13

L’acteur 13 Diagramme des flux 13 Simplification du diagramme des flux : entreprise mono-utilisateur, mono-poste 14 Evénement 14

1 Aux § 5.2, 7.4.7, 7.5, 7.6, 8.3, 8.4, 8.6, ce cours reprend les exemples de MCD qui étaient proposés dans le cours des

années précédentes.


Tableau des flux 14

3. LE MODÈLE RELATIONNEL : MODÈLE LOGIQUE DES DONNÉES 15 3.1 Table, tuple, attribut, clé primaire 15 3.2 Dictionnaire des attributs 16

2.1 Dictionnaire des attributs 16 3.3 Clé étrangère 17 3.4 Attribut calculé 18 3.5 Modèle relationnel et SQL 19

4. LE MODELE ENTITE-ASSOCIATION : MODELE CONCEPTUEL DES DONNEES 20 4.1. Entités et attributs 20

Les entités 20 Les attributs 20

4.2. Associations 21 4.3. Cardinalité et type des associations 21

Cardinalité 21 Association hiérarchique 22 Associations non-hiérarchiques 22 Associations semi-hiérarchiques 23 Retour au MLD 23

5. LES 4 REGLES DE PASSAGE DU MCD AU MLD 23 Schéma d’une base de données 24

6. METHODOLOGIE CONCRETE 26 6.1 Exemple 1 26

Analyse du problème formulé 26 Analyse des entités 26 Analyse des associations 27 Analyse des attributs 28 Les données isolées 28 Résultats 28

6.2. Exemple 2 28


Résultats 28 Passage du MLD au MCD 29 Modélisation du temps 29

6.3 Exemple 30

7. LES FORMES NORMALES 31 7.1 Les formes normales 31

Première forme normale : 1FN 31 Notion de dépendance fontionnelle 32 Deuxième forme normale : 2FN 32 Troisième forme normale : 3FN 32 Forme normale de BOYCE-CODD : BCNF 33 Exemple 33 Conclusion : les trois écueils à éviter 34

7.2. Formes normales et modèle entité-association (MCD) 35

8. APPROCHE OBJET 36 8.1 Notions de spécialisation, de généralisation et d’héritage 36 8.2. Formalisme 36

Spécialisation des entités 36 Généralisation des entités 38 Spécialisation des associations 38

8.3. Approche objet et MLD 39

9. LES CONTRAINTES D’INTÉGRITÉ DU SYSTÈME D’INFORMATION 40 9.1 Les formes normales 40 9.2 Les cardinalités des associations 40 9.3 Les contraintes d’intégrité référentielles 40 9.4 Les contraintes concernant les valeurs des attributs 41

Présentation 41 La contrainte de type 42 La non-nullité 42 Unicité 42 Limites 42


Contraintes sur les clés étrangères 42 Formalisme et exemples 42

9.5 Les contraintes sur les entités dans le modèle orienté objet 44 Présentation 44 Cas général : disjonction et non-couverture 45 Contrainte de couverture et disjonction 45 Contrainte de couverture et non-disjonction 45 Contrainte de non-couverture et disjonction 46

9.6 Les contraintes sur associations 46 Contrainte d’exclusion : non-couverture + disjonction 47 La contrainte de partition : couverture + disjonction 47 La contrainte de totalité : couverture + non-disjonction 48 La contrainte d’inclusion 48 La contrainte d’égalité 49 La contrainte d’unicité 50

10. COMPLÉMENTS DE MODÉLISATION 52 10.1 Retour sur les DF 52

Les DF entre les entités 52 Les DF entre les relations 53 Les DF entre les entités et les relations 53 Les DF et les CIF pour les relations 1 à 1 53

10.2 Cas particulier de dépendance fonctionnelle 53 10.3 Quatrième forme normale 55

Les dépendances multi-valuées (DM) 55 La 4ème forme normale : 4FN 55

10.4 L’identification relative 55


1. INTRODUCTION

Objectif général : Comprendre CSI - Merise Objectifs techniques : • Distinction analyse fonctionnelle - analyse organique • Maîtriser MCD -MLD • Maîtriser MCT Principe du cours : approche inductive. On part d’un cas réel qu’on traite en abordant au fur et à mesure les éléments théoriques.

1.1 Conception

Division du travail : Conception vs. Réalisation (ou Exécution) La distinction entre la conception et la réalisation est une façon d’organiser la division du travail. La division du travail consiste à mettre en évidence les étapes de la réalisation d’un logiciel.

Le cycle en V Etapes de la réalisation d’un logiciel

1 : la conception 2 : la réalisation Ces deux étapes se déroulent successivement : d’abord on conçoit, ensuite on réalise.

Cycle en V Ces deux étapes forment les deux branches du cycle en V : Conception Réalisation Ces deux étapes sont détaillées dans le cycle en V :


Analyse fonctionnelle Recette Analyse organique : architecture Tests Codage C’est le lien entre les étapes de chaque branche qui justifie le cycle en V : Analyse fonctionnelle Recette Analyse organique : architecture Tests Codage Quand on fait l’analyse fonctionnelle, on peut préparer la procédure de recette. Quand on fait l’analyse organique, on peut préparer la procédure de test. On peut encore détailler le cycle en V : Analyse fonctionnelle Recette Analyse organique générale Tests d’intégration Analyse organique détaillée Tests unitaires Codage

Analyse fonctionnelle vs. Analyse organique (architectonique2)

2 Est architectonique ce qui est conforme à la technique de l’architecture. L’architectonique c’est la technique de la construction, mais aussi la structure ou l’organisation de la construction.


On vient de voir que la conception se divise en deux parties : • l’analyse fonctionnelle d’abord • l’analyse organique (ou architectonique) ensuite.

Point de vue de l’utilisateur Point de vue de l’ informaticien Point de vue du maître d’ouvrage Point de vue du maître d’œuvre Point de vue de celui qui commande le logiciel Point de vue de celui qui réalise le logiciel The right system The system right Le QUOI Le COMMENT Analyse fonctionnelle Analyse organique Externe Interne Build the right system Build the system right Construire le bon système Construire bien le système

Il faut distinguer : • le point de vue de l’utilisateur : le maître d’ouvrage (l’utilisateur, le client) • le point de vue de l’informaticien : le maître d’œuvre. Pour l’utilisateur, ce qui compte, c’est l’usage du système : les cas d’utilisation (vocabulaire UML). L’analyse fonctionnelle permettra de modéliser l’ensemble des cas d’utilisation. Pour l’informaticien, ce qui compte c’est l’architecture interne du système. L’analyse fonctionnelle garantit qu’on va bien faire ce qui est demandé : répondre aux exigences du client. L’analyse organique garantit que ce qu’on va faire, on va bien le faire.

Réalisation et langage de programmation Une fois la conception terminée, on passe à la réalisation. La réalisation peut se faire avec n’importe quel langage : assembleur, C, Java, php-mysql, mais aussi des environnements de développement rapide du type de 4D (quatrième dimension) ou de Oracle Database XE (freeware depuis mars 2006).


1.2 Système d’information

La notion de système d’information est une notion issue de la science des systèmes (ou sytémtique). Le système d’information est une représentation possible de n’importe quel système, notamment de tout système humain organisé. Les systèmes d’information préexistent donc à l’informatique. L’analyse systémique facilite la compréhension de l’entreprise. Elle permet d’arriver à la modélisation suivante de l’entreprise : Environnement Entreprise / Organisation

Système de pilotage Communication Génération

Système d’information Traitement Mémorisation Communication

Système opérant Le système opérant est le siège de l’activité productive de l’entreprise. Cette activité consiste en une transformation des flux primaires. Ces flux primaires peuvent être des flux de matière, de finance, de personnel ou d’information. Le système de pilotage est le siège de l’activité décisionnelle de l’entreprise. Il permet le pilotage, la régulation et l’adaptation. Il conduit aux évolutions, notamment des systèmes opérant et d’information. Cette activité décisionnelle est très large et elle est assurée par tous les acteurs de l’entreprise à des niveaux divers. Le système d’information est la représentation de l’activité du système opérant et/ou du système de pilotage, représentation conçue à l’initiative du système de pilotage en fonction des objectifs à atteindre et de l’organisation choisie. Cette modélisation très générale de l’entreprise sera utile comme cadre générale de référence dans l’analyse de système d’information très complexe.


1.3 MERISE

Définition MERISE est une méthode systémique de conception des systèmes d’information.

Historique 1970 Modèle Relationnel de Codd. Années 70 Premiers prototypes de SQL 1976 Modèle Entité Association 1974-78 Le noyau de Merise est établi par une équipe d’ingénieurs et de chercheurs aixois. 1978 Développement de MERISE : méthode française de conception de systèmes d’information, sous l’égide du ministère de l’industrie. 1979 Conception du système d’information, construction de la base de données, H. Tardieu, D. Nanci, D. Pascot (préfacé par J.-L. Le Moigne), Editions d’Organisation. 1979 Première version de SQL, proposé par ORACLE. 1983 La méthode MERISE - Tome 1 : principes et outils. H. Tardieu, A. Rochfeld, R. Colletti. Éditions d’Organisation. 1985 La méthode MERISE - Tome 2 : démarche et pratique. H. Tardieu, A. Rochfeld, R. Colletti, G. Panet, G. Vahée. Éditions d’Organisation. 1986 SQL ANSI (American National Standard Institute) 1989 SQL-1, ISO et ANSI (International Standard Organisation) 1989 La méthode MERISE - Tome 3 : gamme opératoire. A. Rochfeld, J. Moréjon. Édition d’Organisation. 1992 Ingéniérie des systèmes d’information : MERISE. 1ère édition. D. Nanci, B. Espinasse. Sybex. 1992 SQL-2, ISO et ANSI fin années 90 PHP-MySQL 1999 SQL-3, ISO et ANSI 2001 Ingéniérie des systèmes d’information : MERISE. 4ème édition. D. Nanci, B. Espinasse. Vuibert. 2006 Oracle Database XE En 2001, la méthode MERISE était encore la méthode de conception de systèmes d’information la plus largement pratiquée en France. MERISE a pris en compte les évolutions de l’informatique et continue de s’adapter aux nouvelles technologies : architectures clients/serveur, interfaces graphiques, démarche de développement rapide, approche objet, applications intra/internet. Aujourd’hui, la méthode MERISE correspond encore globalement aux savoir-faire actuels en ingénierie des systèmes d’information de gestion. MERISE constitue un standard de fait en conception des systèmes d’information.


1.4 Distinction entre données et traitement : le cy cle d’abstraction MERISE

La démarche de développement proposée par MERISE s’inscrit dans trois dimensions : • Le cycle de vie : c’est le découpage du projet en trois périodes : conception, réalisation et maintenance (conception et réalisation = cycle en V) • Le cycle de décision : c’est la liste de tous les moments où une décision est prise sur le projet (décision de faire le projet après une étude préalable, décision de valider l’analyse fonctionnelle et de passer à l’architecture, validation de la recette, etc.) • Le cycle d’abstraction : c’est l’organisation structurelle des données et des traitements. Dans un premier temps, on va surtout s’intéresser au cycle d’abstraction.

Le cycle d’abstraction Le cycle d’abstraction est basé sur une distinction entre les données et les traitements. C’est la dichotomie fondamentale de MERISE. Elle est directement issue de l’approche base de données. Le cycle d’abstraction est aussi découpé en quatre niveaux : conceptuel, organisationnel, logique et physique. • Le niveau conceptuel exprime des choix fondamentaux de gestion (recherche d’éléments stables indépendamment des moyens à mettre en œuvre, de leurs contraintes et de leur organisation). • Le niveau organisationnel exprime les choix d’organisation de ressources humaines et matérielles, au travers notamment de la définition de sites et de postes de travail. • Le niveau logique exprime les choix de moyens et de ressources informatiques, en faisant abstraction de leurs caractéristiques techniques précises. • Le niveau physique traduit les choix techniques et la prise en compte de leurs spécificités.


DONNEES TRAITEMENTS

Niveau conceptuel

M C D Modèle conceptuel des données Signification des informations sans contraintes techniques, organisationnelle ou économique

M C T Modèle conceptuel des

traitements Activité du domaine sans préciser les ressources et leur organisation

Niveau organisationnel

M O D Modèle organisationnel des

données Signification des informations avec contraintes organisationnelles et économiques

M O T Modèle organisationnel des

traitements Fonctionnement du domaine avec les ressources utilisées et leur organisation

Niveau logique

M L D Modèle logique des données Description des données tenant compte de leurs conditions d’utilisation par les traitements et des techniques de mémorisation

M L T Modèle logique des traitements Fonctionnement du domaine avec les ressources et leur organisation informatique

Niveau physique

M P D Modèle physique des données

Description de la (ou des) base(s) de données dans la syntaxe du SG de données (SGF ou SGBD)

M P T Modèle physique des

traitements Architecture technique des programmes

ISIM, p. 37 Trois sigles sont importants à retenir : MCD, MLD et MPD.


2. PREMIERE APPROCHE

2.1 Exemple : soit le cahier des charges suivant

La ville de Paris gère des centres d’animations. La société « Graphico » est une société qui vend au détail des articles papeterie et de graphisme dans ses 5 magasins mais également par correspondance (courrier et internet). Chaque magasin mène des campagnes de fidélisation de ses clients, en effectuant des envois personnalisés promotionnels selon les profils de sa clientèle. (type d’achat, volume d’achats, lieu d’habitation). Les clients qui n’ont pas commandé depuis 3 ans sont radiés des fichiers. Chaque magasin est indépendant mais passe ses commandes de réapprovisionnement à une centrale d’achat globale après avoir choisi ses fournisseurs. Chaque responsable de magasin souhaite gérer, d’une manière autonome, à travers son propre système d’information :

• Ses clients : fiche signalétique, volume d’affaires, articles achetés. • Les commandes des clients et leur suivi : bon de commande comptoir, papier, internet,

respect du délai de livraison, constitution du bon de livraison, gestion des ruptures de stock avec lettre d’accompagnement, retour de marchandise, échanges.

• Ses fournisseurs : un même article peut provenir de plusieurs fournisseurs, prix. • Ses articles : gestion des pièces en commande et en stock, procédure de réapprovisionnement

auprès de la centrale d’achat, gestion des entrées magasin et des sorties (livraison des fournisseurs, ventes…).

• Sa facturation : émission et suivi des paiements, relances. • Les campagnes promotionnelles : gestion des offres et des envois.

2.2 La description conceptuelle de l’entreprise

La première difficulté, c’est de ne pas tout mélanger. Lorsque quelqu’un essaye de faire comprendre ce qu’est son activité, le plus souvent il ne fait pas la distinction entre les contraintes d’ordre conceptuel, organisationnel, logique ou matériel.


Le rôle du MCT sera de décrire l’activité du domaine indépendamment des contraintes organisationnelles (l’organisation des services de l’entreprise, par exemple), logiques (on envoie des courriers ou on envoie des mails) et matérielles (l’entreprise dispose d’un réseau informatique ou n’en dispose pas). • Objectif : représenter formellement les activités exercées par le domaine (l’entreprise ou une partie de l’entreprise). • Intérêt : la connaissance de ces activités est la base du système d’information. • Abstraction : le MCT fait abstraction de l’organisation, c’est-à-dire des moyens et des ressources nécessaires à l’exécution de ces activités. • Le QUOI : Le MCT exprime le QUOI et pas le PAR QUI, le QUAND, le OU ou le COMMENT. Puisqu’il s’occupe du QUOI, le MCT relève de l’analyse fonctionnelle.

2.3 Acteur, flux, événement, diagramme des flux

L’acteur L’acteur c’est une personne ou un service (au sens d’un département ou d’un domaine d’activité). L’acteur peut être interne ou externe. L’acteur est une unité active : il fait quelque chose : stimulé par des flux, il les transforme et les renvoie.

Diagramme des flux Le flux représente un échange entre deux acteurs. Il est émis par un acteur à destination d’un autre acteur. On peut représenter les flux comme des échanges entre 3 lieux séparés par deux cercles concentriques : Le cercle qui sépare le monde extérieur du système entreprise. Le monde extérieur est le lieu des acteurs externes. Le cercle qui, à l’intérieur du système entreprise, sépare le système d’information informatisé du reste de l’entreprise. Ce « reste de l’entreprise » est le lieu des acteurs internes.

Monde extérieur Système entreprise

Système d’information informatisé


Simplification du diagramme des flux : entreprise mono-utilisateur, mono-poste On peut simplifier l’analyse du diagramme des flux en considérant l’entreprise comme un système mono-utilisateur (un seul acteur interne) et mono-poste (tout se passe au même endroit et sur le même ordinateur et le même logiciel). Le reste du monde va donc communiquer avec cette abstraction (cet acteur unique) et, éventuellement, avec le système d’information informatisé. Simplification de l’entreprise : mono-tâche, mono-utilisateur, mono-poste : une personne qui fait tout ; le reste du monde communique avec cette abstraction et, éventuellement, avec le SI informatisé.

Evénement Par défaut, le système est considéré comme étant au repos. Un événement, c’est ce qui met le système en branle : une opération va se dérouler. Il y a trois types d’événement : • L’acteur externe • L’échéance • La décision

Tableau des flux On liste dans un tableau tous les flux entre le monde extérieur et l’entreprise. On précise dans quel sens se fait le flux. On ajoute les échéances et les décisions.


3. LE MODÈLE RELATIONNEL : MODÈLE LOGIQUE DES

DONNÉES

Le modèle relationnel a été inventé par CODD à IBM-San Jose en 1970. C’est un modèle mathématique rigoureux basé sur un concept simple : celui de relation (ou table, ou tableau).

3.1 Table, tuple, attribut, clé primaire

Table, tuples et attributs On veut gérer un catalogue de disque. Dans un premier temps, on veut pouvoir connaître le titre de chaque disque, le nom de l’artiste ou du groupe, le nombre de chansons sur le disque, la durée du disque, l’année de sortie, le style de musique. Chaque disque a donc les caractéristiques suivantes :

Titre, artiste, style, nb chansons, durée. Pour ranger ces données, on peut faire un tableau à 6 colonnes : RELATION 6 attributs : Disques Titre Artiste Année Style Nb chansons Durée 5 tuples :

Vocabulaire Relation = tableau = table Tuple = élément du tableau = ligne du tableau = enregistrement = individu Attribut = colonne du tableau = caractéristique = propriété

Clé primaire On souhaite pouvoir distinguer facilement chaque ligne d’une autre ligne. Or, certains disque auront le même titre, d’autre le même artiste, etc. Pour distinguer chaque ligne, on introduit la notion de clé primaire. La clé primaire est un attribut qui détermine tous les autres.


Exemple type de clé primaire : le numéro de sécurité sociale dans un tableau de personne. Quand on connaît le numéro de sécurité sociale, on sait de qui on parle, donc tous les attributs sont déterminés. Dans le tableau des disques, la clé primaire pourrait être un numéro de référence de la maison d’édition (mais il y a un risque que deux maisons de disque ait le même type de numérotation). Le mieux sera d’introduire un attribut qui numérote les disques : Numéro du disque. RELATION 6 attributs : Disques Numéro du disque Titre du disque Artiste Année Style Nb chansons Durée 1 2 3 5 tuples : 4 5

3.2 Dictionnaire des attributs

Les attributs sont listés dans un dictionnaire, avec un certain nombre de caractéristiques. Distinction entre l’intitulé et le nom de code

On a donné des intitulés aux attributs des disques (aux colonnes du tableau de disque). Il va falloir leur donner un nom de code qui sera utilisé dans la programmation. Il faudra aussi préciser le type et diverses caractéristiques :

2.1 Dictionnaire des attributs

N° Désignation Code Type Obl Enum Déf 1 N° du disque numdisq E Oui 2 Titre Titdisq A 20 3 Artiste Artis A 20 Oui 4 Année Andisq D 5 Style Style A 10 * 6000 6 Nb Chanson Nbchant. E 7 Durée Durdisq Date

• Type : A = alphabétique, B = booléen, D = date, E = entier, R = réel, I = image. • Obl : précise si l’attribut est obligatoire ou pas (non NULL) • Enum : précise si les valeurs de l’attributs sont définis dans une liste de valeurs énumérées..


• Déf : précise une valeur par défaut. • Souligné : les attributs-clés sont soulignés. L'attribut « style » est un énuméré : les styles peuvent être prédéfinis : Jazz, Rock, Classique, etc.

Formalisme : schéma d’une relation On peut représenter la table sous cette forme : Disques (NumDisq, Titre, Artis, Andisq, style, nbchans, durdisq) On met l’attribut clé en premier. De façon shématique, on écrira : D (D, Dx) D, c’est le nom de la table (initial de Disques). D : c’est la clé primaire de la table D Dx : ce sont les attributs de la table D

3.3 Clé étrangère

Dans le catalogue de disques, on veut en plus connaître le titre des chansons pour chaque disque, l’ordre des chansons sur le disque et la durée de chacune des chansons. On va se doter d’une nouvelle relation (nouvelle table) : Chansons RELATION 5 attributs : Chansons N° de la chanson Titre de la chanson Ordre Durée #N° Disque

1 1 1 2 2 1 3 3 1 5 tuples : 4 1 2 5 2 2 Le n° de la chanson, c’est la clé primaire. L’attribut #N° Disque correspond au numéro du disque de la chanson. On considère dans un premier temps que une chanson appartient à un disque et un seul (on ne gère pas les compilations). Cet attribut est la clé primaire de la table des Disques. Il permet de faire le lien entre les chansons et les disques. Il est appelé « clé étrangère ». On met un # devant les clés étrangères.

Formalisme : schéma d’une relation


On peut représenter la table sous cette forme : Chansons (numchans, titchans, ordre, durchans, #numdisq) • La clé primaire est soulignée, et apparaît en premier. • Les clés étrangères sont précédées d’un signe #, et apparaissent en dernier.

3.4 Attribut calculé

La durée total du disque (durdisq) est égale à la somme des durée des chansons du disque (durchans). Le nombre de chansons est donné par le nombre de lignes dans la table des chansons. Les attributs « durdisq » et « nbchans » peuvent donc être calculés. Il peut aussi être supprimé : on le calculera à chaque fois qu’on en aura besoin

Quelle est le nombre de chansons et la durée du disque dont le titre est « shakara ». EN équivalent C ou Pascal : nbChansons=0 ; dureeDisq=0 ; Pour i allant de 1 à nbChansons Pour j allant de 1 à nbDisques Si tabDisque(j, 2) = « shakara »

Si tabDisques(j, 1)=tabChansons(i, 5) nbChansons++ ; duréeDisq=dureeDisq+tabChansons(i, 4) ;

Fin si Fin si

Fin boucle j Fin boucle i EN SQL Select count(*), sum(durchant) From disques, chansons Where chansons.numdisq=disques.numdisq And titdisq= « shakara »; Dans le dictionnaire des attributs, on rajoute une colonne: calculé (oui ou non).


3.5 Modèle relationnel et SQL

Ce modèle, c’est celui qui est implanté dans les SGBR-R. C’est celui qui est utilisé par le langage SQL


4. LE MODELE ENTITE-ASSOCIATION : MODELE

CONCEPTUEL DES DONNEES

Le modèle Entité-Association a été conçu en 1976 et il est aujourd’hui à la base de la plupart des méthodes de modélisation (dont MERISE). On le retrouve aussi dans UML. Le modèle entité-association permet de modéliser le monde réel à l’aide d’entités qui représentent les objets ayant une existence indépendante des autres, et d’associations entre ces entités. Ce modèle est utile pour la modélisation parce qu’il est plus structurant que le modèle relationnel. Il permet ensuite un passage quasi-mécanique au modèle relationnel (et donc à la programmation).

4.1. Entités et attributs

Reprenons l’exemple de la discothèque.

Les entités La table des disques correspond à une entité : l’entité disques. Ensuite la table des chansons correspond à une entité : l’entité chansons.

Les attributs Un même attribut n’apparaît qu’une seule fois dans le modèle conceptuel des données. Il faut donc l’attribuer à l’entité qui lui correspond le mieux. Ca ne pose aucun problème, sauf pour l’attribut n° du disque qui apparaissait comme clé primaire dans la table des disques et comme clé étrangère dans la table des chansons. La notion de clé primaire reste dans ce modèle. Par contre il n’y a plus de clé étrangère. En effet, ce sont les associations qui vont les remplacer. Disques Chansons N° disque N° Chanson Artiste Titre etc. Etc.


Les rectangles figurent les entités.

4.2. Associations

Continuons avec l’exemple de la discothèque. Pour représenter le lien entre les disques et les chansons, on va utiliser la notion d’association entre entités : Disques Appartient à Chansons N° disque N° Chanson Artiste Titre etc. Etc. L’association à un nom. En général c’est un verbe qui relie les deux entités. Les rectangles figurent les entités, les ovales les associations.

4.3. Cardinalité et type des associations

Cardinalité La cardinalité est une notion fondamentale du MCD.

Les associations se caractérisent par leurs cardinalités. On les note : (min1, max1)- (min2, max2). Les valeurs du premier couple fixent les nombres minimum et maximum de tuples de la seconde entité auxquels chaque tuple de la première entité est associé, et réciproquement. Par exemple : (1,1)- (0, n) signifie que • chaque tuple de la première entité est associé au minimum à 1 et au maximum à 1 (donc à 1 et 1 seul) tuple de la seconde entité ; • et que chaque tuple de la seconde entité est associé au minimum à 0 et au maximum à n tuples de la première entité (donc que tous les tuples de la seconde entité ne sont pas nécessairement associés à ceux de la première). Chaque chanson appartient à un album et un seul (c’est l’hypothèse qu’on fait dans un premier

0.N 1.1


temps). Un album est constitué de 0 ou n chansons. On met 0 en valeur minimum car il peut arriver qu’on crée un album sans avoir créer les chansons qu’il contient.

Association hiérarchique Les associations dont un des couples de cardinalités est (1,1) sont dites « hiérarchiques ». Ce sont les associations (1,1)- (0 ou 1, n). Elles sont aussi appelées « associations 1-n » On distinguera les associations hiérarchiques des associations non hiérarchiques.

Associations non-hiérarchiques On va maintenant s’intéresser à un modèle qui nous permettrait de gérer les compilations : on considère donc qu’une chanson peut appartenir à plusieurs disques. Le MCD devient le suivant : Disques Appartient à Chansons N° disque N° Chanson Artiste Titre etc. Etc. Les rectangles figurent les entités, les ovales les associations. Cette fois ci, la cardinalité nous dit que une chanson peut appartenir 1 disque (au moins, pas 0) ou à n disques. Une association non hiérarchique a un nom qui correspond à un verbe reliant les deux entités, dans le sens que l’on veut. On pourra aussi lui donner un nom correspondant à un nom commun. Disques Contient Chansons N° disque N° Chanson Artiste Titre etc. Etc. On peut aussi préciser le sens de lecture : Disques Contient -> Chansons N° disque N° Chanson Artiste Titre etc. Etc.

0.N 1.N

0.N 1.N

0.N 1.N


Comment gérer l’attribut « ordre de la chanson dans le disque ». Cet attribut n’est plus propre à la chanson, mais à la chanson dans le disque. C’est un attribut de l’association. Disques Contient -> Chansons N° disque N° Chanson Artiste ordre Titre etc. Durée Les associations non-hiérarchiques peuvent porter des attributs. Inversement, les associations hiérarchiques ne portent jamais d’attributs. Si une association hiérarchique à des attributs alors, soit ces attributs sont en réalité des attributs de l’entité inférieure, soit l’association est en réalité une association non hiérarchique.

Associations semi-hiérarchiques Les associations (0-1)- (0 ou 1- N) sont des associations semi-hiérarchiques.

Retour au MLD Comment transformer le MCD d’une association non-hiérarchique en MLD ? La règle est la suivante : une association non-hiérachique se transforme en une table. Les attributs clés primaires des entités associées deviennent des attributs clés étrangères dans la nouvelle table. La clé primaire de la nouvelle table peut être constituée par la concaténation des attributs clés primaires, mais ce n’est pas toujours le cas. Il faut vérifier et chercher. Dans notre exemple, on obtient pour les disques : Disques (numdisq, titdisq, artis, andisq, style) Chansons(numchans, titchans, durchans) Disqchans(#numdisq, #numchans, ordre)

Remarque sur la clé de Disqchans On peut considérer que c’est (numdisq, numchans) qui est la clé : c’est un couple unique qui détermine le reste. Sur un même disque, la même chanson n’apparaît qu’une fois. Cela dit, on pourrait imaginer qu’il y ait plusieurs fois la même chanson sur le même disque. En réalité, sur un disque, c’est l’ordre qui est unique, plus que la chanson. C’est donc le couple (numdisq, ordre) qui est véritablement la clé primaire de la table disqchans.

5. LES 4 REGLES DE PASSAGE DU MCD AU MLD

0.N 1.N


Le passage du MCD au MLD est quasiment mécanique et ne pose donc aucun problème si le MCD a été correctement réalisé. Il y a quatre règles de passage d’un MCD à un MLD : • une pour les entités • une pour les associations hiérarchiques • une pour les associations non hiérarchiques • une pour les associations semi-hiérarchiques.

Règle 1 Chaque entité devient une table relationnelle. Chaque attribut de l’entité devient un attribut de cette table.

Règle 2 Une association hiérarchique (1,1 — 0 ou 1, N) ou (1,1 — 0, 1) ne donne pas lieu à la création d’une nouvelle table. Elle donne lieu à la création d’un attribut dans la table issue de son entité inférieure, cet attribut correspondant à la clé primaire de l’entité supérieure associée. Ce nouvel attribut est appelé clé étrangère. Dans le cas d’une association hiérarchique réflexive, ce nouvel attribut doit être renommé et ajouté dans le dictionnaire des attributs (cf. 5.2.d).

Règle 3 Les associations non hiérarchiques (0 ou 1, N — 0 ou 1, N) deviennent des tables. Chaque attribut de l’association devient attribut de cette table. Les clés primaires des entités associées deviennent des attributs clés étrangères dans cette nouvelle table. La clé primaire de cette table est, le plus souvent, constituée par la concaténation des clés primaires des entités associées. Toutefois, cette règle syntaxique doit être associée à une vérification sémantique. Si ce n’est pas le cas, on peut essayer d’ajouter des attributs qui ne sont pas clés étrangères. On peut aussi essayer de retirer un ou plusieurs attributs clés étrangères.

Règle 4 Dans le cas des associations semi-hiérarchiques (0,1 — 0 ou 1, N) : si elles portent des attributs, elles seront nécessairement traitées comme des associations non-hiérarchiques. Si elles ne portent pas d’attributs, on les traitera comme des associations hiérarchiques (toutefois, on pourrait aussi les traiter comme des associations non hiérarchiques).

Schéma d’une base de données La liste de tous les schémas des relations constitue le schéma d’une base de données. Habituellement, on présente la liste des relations du modèle dans l’ordre suivant : • d’abord les relations ayant une clé primaire simple et pas de clé étrangère,


• ensuite les relations ayant une clé primaire simple et une ou plusieurs clés étrangères, • enfin les relations ayant une clé primaire concaténée, formée de plusieurs autres clés primaires. Dans l’exemple de la médiathèque, on arrive au schéma suivant : Disques (NumDisq, Titre, Artis, Andisq, style) Chansons (numchans, titchans, ordre, durchans, #numdisq) De façon très synthétique, on pourrait écrire : D(D, Dx) C(C, Cx, #D) Dans le cas où on gère les compilations, on a le schéma suivant : Disques (NumDisq, Titre, Artis, Andisq, style) Chansons (numchans, titchans, durchans) Dischans (#NumDisq, #numchans, ordre) De façon très synthétique, on pourrait écrire : D(D, Dx) C(C, Cx, #D) DC(#D, #C, DCx)


6. METHODOLOGIE CONCRETE

6.1 Exemple 1

Soit l’exercice suivant : Une association a des membres et reçoit des dons de donateurs privés. Elle désire pouvoir envoyer des reçus fiscaux contenant la date du don, le montant et le nom du donateur. Comment analyser le problème ?

Analyse du problème formulé On part d’une situation décrite par un texte : on va donc faire une analyse du texte. A chaque mot du texte, va pouvoir correspondre une entité, un attribut ou une association.

Nom Entité ou attribut Adjectif attribut Verbe association

En même temps, il faut lister les objectifs à atteindre, c'est-à-dire les traitements que l'on veut faire subir aux entités. Il faut donc d'abord distinguer les données (entités) et les traitements (objectifs). Notez que les traitements peuvent faire découvrir de nouvelles données. Dans notre exemple : Entités potentielles : association, membres, dons, donateurs, reçus Attributs : reçus (date du don, montant don, nom donateur), dons (date du don, montant don), donateur (nom donateur) Objectifs : envoyer des reçus

Analyse des entités Questions à se poser : • Quelle est la clé ? S’il n’y a pas de clé, ce n’est pas une entité. • Qui y a-t-il comme attribut ? S’il n’y a pas d’attributs en plus de la clé, ou si les attributs qu’on peut imaginer sont hors sujet, ce n’est pas une entité.


• S’il y a un seul attribut en plus de la clé, il faudra se poser la question de savoir quelles association cette entité entretient avec les autres entités. Si elle n’entretient que des associations hiérarchiques (n de son côté), alors cette entité peut-être remplacée par un attribut dont les valeurs appartiendront à une liste prédéfinie. • Puis-je imaginer des objets concrets dans l’entité (des tuples en MLD) ? Sinon, ce n’est pas une entité. • Puis imaginer plusieurs objets concrets dans l’entité, et pas un seul ou un tout petit nombre fixe dont les valeurs sont déterminées une fois pour toutes. Dans ce dernier cas, ce n’est pas une entité. • Si deux entités contiennent les mêmes objets, ou les mêmes attributs, ou la même clé, ou sont reliées par une association 1.1 - 1.1, alors ces deux entités sont identiques. • Si un attribut d’une entité A est une entité B, alors il y a une association entre A et B. • Est-ce que les objectifs induisent de nouveaux attributs ? Dans notre exemple : Association : ne contient qu’un seul objet concret : ce n’est pas une entité. Membres : aucun attribut précisé. Membres ne sert à rien pour les objectifs à atteindre : ce n’est pas une entité. Dons : montant, date du don. Donateur semble être un attribut : il y a donc probablement une association entre Dons et Donateurs. Donateurs : nom. Du fait qu’il faut leur écrire, ils ont aussi une adresse. Reçus fiscal : montant, date du don. Donateur semble être un attribut : il y a donc probablement une association entre Reçus fiscal et Donateurs. Quelles sont les clés ? numéro du don, numéro du donateur, numéro du reçu fiscal. Le don et le reçu fiscal ont les même attributs : un reçu fiscal est une information calculé à partir du don et du donateur.

Analyse des associations Question à se poser : • Quelles sont les cardinalités? Il est essentiel de bien distinguer les associations hiérarchiques des associations non hiérarchiques. • Si on a une association 1.1 - 1.1, c’est que les deux entités associées sont identiques. • Dans le cas d’une association non hiérarchique à trois pattes ou plus, il faut se demander quelle sera la clé dans la table issue de cette association. Il peut s’avérer que certaines pattes traduisent en réalité une association entre une association et une entité. Dans notre exemple :


Il y a une association entre don et donateur : un don est fait par un et un seul donateur, un donateur peut faire 0 ou n dons.

Analyse des attributs L’analyse des attributs se fait avec celle des entités. On peut aussi reprendre tous les attributs du MCD et faire un graphe des dépendances fonctionnelles.

Les données isolées Dans le système d’informations, il peut y avoir des données isolées : elles ne se rangent pas dans une entité. Par exemple : le taux de TVA, la valeur du SMIC, etc. Les informations décrivant l’association (son nom, son adresse, etc.) Ces données sont utilisées pour certains calculs concernant l’intégrité du système. On a intérêt à les ranger dans une entité spéciale contenant les données isolées.

Résultats MDC : MLD : Dons(numDon, montant, date, #numDonat) Donat(numDonat, nom, prénom, adresse, CP, ville) DN(DN, NDx, #DT) DT(DT, DTx)

6.2. Exemple 2

Dans une bibliothèque de prêt de livres, un abonné muni de sa carte peut se présenter pour emprunter des livres. Un abonné ne peut pas emprunter plus de 3 livres à la fois. Les livres doivent être rendus après une durée de 15 jours maximum. Des amendes sont calculées en fonction du nombre de jour de retard. Des courriers peuvent être envoyés aux abonnés. La bibliothèque souhaite faire des statistiques sur les emprunts de livre : elle souhaite donc conserver la date de tous les emprunts de tous les livres.

Résultats


MDC : Abonnés <--n----Emprunts(dateemp, datret)----n-- >Livres MLD : Abonnés(numAbo, nom, adresse, CP, ville) Livres(numLiv, titre, auteur) Emprunts(#numAbo, #numLiv, dateEmp, dateRet) On détermine la clé en emprunts en réfléchissant

Passage du MLD au MCD On peut ensuite revenir au MCD qui aurait permis d’arriver mécaniquement au MLD Pour cela, il suffit de faire de chaque attribut participant à la clé une clé étrangère : DateEmp devient clé étrangère : il fait référence à une entité date.

Modélisation du temps Attribut date

L’attribut date ne pose pas de difficulté. Exemple : la date de naissance d’une personne. C’est un attribut comme un autre dans l’entité des personnes.

Entité Date L’entité Date permet de modéliser le fait qu’on veut garder un historique. C’est le cas de l’exemple de la bibliothèque. Si on voulait garder l’historique des prix d’un produit Produits Prix chaque mois Date NumP Date Prix actuel Etc.

Passage au MLD

0.N

Prix

0.N


Le MCD oblige à faire une entité date. Cette entité ne contient qu’un attribut : la date qui est en même temps la clé. De ce fait, quand on passera au MLD, on pourra se dispenser de la table

6.3 Exemple

Soit l’exercice suivant : On souhaite gérer le personnel d'une société. Chaque membre du personnel a un nom, une fonction, un salaire, une commission, une date d'entrée dans la société. Chaque membre du personnel travaille dans un département caractérisé par son nom (commercial, production, personnel, comptable et recherche) et la ville dans lequel il se trouve. Chaque membre du personnel a un supérieur hiérarchique lui-même membre du personnel. Les associations réflexives Dept(numDept, nom, ville) Emp(numEmp, nom, fonction, salaire, commission, entrée, #numDept, *numEmp)


7. LES FORMES NORMALES ��

7.1 Les formes normales

Première forme normale : 1FN La première forme normale concerne toutes les tables. Toute table possède une clé et tout attribut a une valeur simple (atomique). Donc la valeur d’un attribut ne peut pas être une liste, ni être inexistant. Exemple : Dans la table, livresempruntés, on propose une liste de livres actuellement empruntés : dupond en 2, durand 1, delarue 0. EstAuteurDe NomAbo Liste des livres Dupond C++, Merise Durand SQL Delarue On considère que la clé de la table, c’est NomAbo (on pourrait mettre un numéro à la place). Cette table n’est pas en première forme normale. En effet : il y a 2 valeurs pour la liste des livres de Dupond, et 0 pour celle de Delarue. La table mise en première forme normale sera : EstAuteurDe NomAbo Livre Dupond C++ Dupone Merise Durand SQL Cette table est bien en première forme normale. A noter que : Delarue a disparu. La clé de la table n’est plus NomAbo, mais le couple (NomAbo-Livre) Remarques : � Il faut distinguer l’absence de valeur et une valeur inconnue. La valeur d’une valeur inconnue sera dite "NULL". On peut avoir des valeurs inconnues, NULL, mais on ne peut


pas ne pas avoir de valeur. (Remarque : NULL ne signifie pas 0, ni chaîne vide). � Il ne faut jamais signifier l’absence de valeur par un code spécial (-1, xxx, etc.). Si un attribut ne peut pas être renseigné, c’est que l’entité doit au moins être divisée en deux. � La valeur d’un attribut clé primaire ne peut pas être inconnue. Exemple de problème concret : si le numéro de sécurité sociale est la clé primaire pour une table de personne, alors celui qui n’a pas de numéro de sécurité sociale, ou qui ne le connaît pas ne pourra pas entrer dans la BD. Pour éviter cela, on a intérêt à donner un simple numéro pour gérer la clé de la table des personnes, et faire du numéro de sécurité sociale un simple attribut. � La valeur d’un attribut clé étrangère peut être NULL dans le cas d’une association semi-hiérarchique (0-1).

Notion de dépendance fontionnelle La notion de dépendance fonctionnelle s’applique à l’origine au modèle relationnel (MLD). Un attribut Y (ou premier groupe d’attributs) dépend fonctionnellement d’un attribut X (ou second groupe d’attributs), si étant donné une valeur de X, il lui correspond une valeur unique de Y (et ceci quel que soit l’instant considéré). On dit que X détermine fonctionnellement Y et on note :

X - > Y

Deuxième forme normale : 2FN La deuxième forme normale concerne les tables dont la clé est constituée de plusieurs attributs. Une table est en deuxième forme normale si elle est en première forme normale et si aucun attribut non clé ne dépend fonctionnellement d’une partie de cette clé. Ce qu’on pourrait écrire schématiquement et intuitivement ainsi :

La relation (A1, A2, A3, A4) est 2FN si il n’existe pas A1 - > A3 La correction consiste à créer deux tables :

(A1, A3) (A1, A2, A4)

Cette règle permet d’éviter la redondance des données.

Troisième forme normale : 3FN La troisième forme normale, comme la deuxième, concerne toutes les tables. Une relation est en troisième forme normale si elle est en deuxième forme normale et si aucun attribut non clé ne dépend fonctionnellement d’un attribut non-clé. Ce qu’on pourrait écrire schématiquement et intuitivement ainsi :

La relation (A1, A2, A3, A4) est en 3FN si il n’existe pas A3 - > A4 La correction consiste à créer deux tables :


(A3, A4) (A1, A2, #A3)

Cette règle permet d’éviter la redondance des données. Cette règle permet d’éviter la redondance des données (1er et 2ème écueil).

Forme normale de BOYCE-CODD : BCNF La forme normale de BOYCE-CODD, comme la deuxième et la troisième, concerne les tables dont la clé est constituée de plusieurs attributs. Une relation est en forme normale de BOYCE-CODD si elle est en troisième forme normale et si aucun attribut faisant partir de la clé ne dépend fonctionnellement d’un attribut non-clé. Ce qu’on pourrait écrire schématiquement et intuitivement ainsi :

La relation (A1, A2, A3, A4) est en BCNF si il n’existe pas A3 - > A1 Ce cas est beaucoup plus rare et peu significatif.

Exemple Exemple3 : Soit la table (ou l’entité) PROPRIÉTAIRES constituée des attributs suivants : NumIm Marque Type Puiss. Coul. NumSS Nom Prénom Date Prix 672 RH 75 RENAULT R 12 TS 6 ROUGE 100 MARTIN PAUL 10/02/98 10 000

800 AB 64 PEUGEOT 504 9 VERTE 100 MARTIN PAUL 11/06/95 30 000

686 HK 75 CITROEN 2 CV 2 BLEUE 200 DUPOND JEAN 20/04/97 5 000

720 CD 60 CITROEN AMI 8 5 BLEUE 200 DUPOND JEAN 20/08/96 15 000

400 XY 75 RENAULT R 12 TS 6 VERTE 300 DURANT PIERRE 11/09/97 12 000

Les dépendances fonctionnelles sont les suivantes : NumIm : Marque, Type, Puiss, Coul Type : Marque, Puissance NumSS : Nom, Prénom NumIm, NumSS : Date, Prix Ce qui veut dire que : quand on connaît le numéro d’immatriculation, on connaît la marque, le

3 Cet exemple est extrait de Gardarian Georges, Bases de données, Eyrolles 1994, p. 69.


type la puissance et la couleur. Quand on connaît le type on connaît la marque et la puissance, etc. Du fait de l’existence de ces dépendances fonctionnelles, on peut et on doit décomposer la table des propriétaires en une table des personnes (déterminées par leur numéro de sécurité sociale), une table des véhicules (déterminés par leur immatriculation), une table des types de véhicules (déterminés par le type) et une table des ventes (déterminées par le numéro de sécurité sociale, l’immatriculation). Du point de vue du modèle conceptuel, on peut et doit décomposer l’entité en 3 entités : personnes, véhicules et types de véhicules, et y ajouter une association hiérarchique entre véhicules et types de véhicules, une association non hiérarchique entre personnes et véhicules. Le schéma résultant est le suivant : Personnes (NumSS, Nom, Prénom) Véhicules (NumIm, Coul, #Type) TypeVéhicule (Type, Marque, Puissance) Ventes (#NumIm, #NumSS, Date, Prix) Le modèle conceptuel résultant est le suivant : Personnes Ventes Véhicules NumSS NumIm Nom Coul Prénom A pour type TypeVéhicule Type Marque Puissance

Conclusion : les trois écueils à éviter � redondance des données � incohérence des données � signifier l’absence de relation par un code spécial.

1.N

Date Prix

0.1

1.N

1.1


7.2. Formes normales et modèle entité-association ( MCD)

La 1FN peut s’appliquer directement au modèle entité association : chaque entité doit avoir une clé et chaque attribut doit être simple. Par contre, les principes du modèle entité-association préservent par eux-mêmes de violer les 2FN, 3FN et BCNF puisque ces formes normales concernent des tables dont les clés sont composées de plusieurs attributs. Or, dans le modèle entité-association, la clé d’une entité est toujours composée d’un attribut et d’un seul Les tables du MLD dont la clé est composée de plusieurs attributs proviennent de la transformation des associations non-hiérarchique en table. C’est donc au moment du passage du MCD au MLD qu’il faudra être particulièrement vigilant pour éviter de violer ces formes normales.


Bonobos

8. APPROCHE OBJET ��

8.1 Notions de spécialisation, de généralisation et d’héritage

On peut considérer les entités comme des ensembles. Les attributs de l'entité sont les attributs de l’ensemble. Chaque occurrence de l’entité (chaque tuple) est un élément de l’ensemble. L’espèce est un sous-ensemble de l’ensemble dont on parle : le bonobo est une espèce de singe. Quand on parle d’un sous-ensemble, on dit aussi « sous-type ».

Singes Le genre est un « sur-ensemble » de l’ensemble dont on parle : le singe est le genre du bonobo. Quand on parle d’un « sur-ensemble », on dit aussi « sur-type ». Chaque élément d’un ensemble est aussi élément des ensembles qui le contiennent : bonobo_1 appartient à l’ensemble des bonobos mais aussi à l’ensemble des singes. Un ensemble hérite des attributs des ensembles de niveaux supérieurs qui le contiennent. Un ensemble fait hériter ses attributs à tous les ensembles de niveaux inférieurs qu’il contient. Cette organisation forme une hiérarchie, c’est la hiérarchie de spécialisation/généralisation, encore appelée hiérarchie « is-a », « est-un ». (Dans le langage courant on dit indifféremment : le bonobo est un singe et ce singe est un bonobo). Ces trois notions : spécialisation, généralisation, héritage sont les notions clés du modèle « orienté objet ». Dans le formalisme objet, on parle d’objet à la place des entités. Et on parle d’occurrence de l’objet à la place d’occurrence des entités.

8.2. Formalisme

Spécialisation des entités Dans la spécialisation, le sur-type préexiste, il s’agit de décomposer une entité (sur-type) en plusieurs entités (sous-types).

Division du sur-type

Bonobo 1


À chaque sous type correspond un seul sur type. Exemple :

Représentation ensembliste :

Employés

Intersection de sur-types

Pour un sous-type, il existe au moins deux sur-types. Exemple :

Représentation ensembliste : Étudiants Salariés

Héritage Les propriétés de l’entité générique sont transmises aux entités spécialisées. Ce mécanisme s’applique aussi à l’identifiant du sur type : l’identifiant de l’entité générique est transmis aux entités spécifiques : il ne faut donc pas définir d’identifiant pour les entités spécifiques si l’identifiant de l’entité générique est déjà défini.

Employés hommes Employés femmes

Etudiants salariés


Généralisation des entités Cette fois-ci, ce sont les entités sous-types qui préexistent. Il s’agit d’est une factorisation des propriétés communes à plusieurs entités (sous types), qui seront regroupés dans une seule entité (sur type). Les propriétés communes sont donc retirées des entités spécifiques et remontées dans l’entité générique. Exemple :

Héritage

Les propriétés de l’entité générique sont transmises aux entités spécialisées. L’héritage de la clé :

Avec la généralisation, on a créé une entité genre. Il faut qu’elle ait un attribut clé. Deux options : • Soit on laisse les attributs clés dans les entités spécifiques auxquels cas la généralisation/spécialisation est équivalente à une association hiérarchique. • Soit on supprime les attributs clés dans les entités spécifiques et on arrive au même résultat que dans le cas de la spécialisation des entités.

Spécialisation des associations Les types et sous type de relations concernent des restrictions de la relation à des sous types d’entités. Exemple :

On suppose que : il y a au plus une secrétaire qui est affectée au projet. La relation travailler est une relation sous type et hérite de toutes les propriétés de la relation sur type affecter, et peut comporter des propriétés propres.


8.3. Approche objet et MLD

La transformation d’un modèle objet en modèle relationnel est difficile et oblige à revenir au modèle entité-association. L’intérêt du modèle objet est que ses concepts (spécialisation, généralisation, héritage) permettent d’améliorer l’analyse conceptuelle.


9. LES CONTRAINTES D’INTÉGRITÉ DU SYSTÈME

D’INFORMATION

Une contrainte d’intégrité est une règle de contrôle du système d’information (du MCD). Cette règle peut s’appliquer aux entités, aux associations, aux propriétés. La définition de l’ensemble des contraintes d’intégrité permet de maintenir au maximum la cohérence du système d’information au cours de son existence (au fur et à mesure que l’on crée, que l’on détruit ou que l’on modifie des occurrences d’entités ou d’association. Les contraintes d’intégrité sont les suivantes : • Les formes normales • Les cardinalités des associations • Les contraintes d’intégrité référentielles • Les contraintes concernant les valeurs des propriétés

9.1 Les formes normales

La 1FN garantit l’existence d’une clé et du fait qu’un attribut ait une valeur. Si un attribut n’a pas de valeur, sa valeur par défaut sera NULL. Les 2FN, 3FN, BCNF évitent des duplications d’information en décomposant une table non-normale en plusieurs tables normales.

9.2 Les cardinalités des associations

Les cardinalités des associations sont des contraintes. Quand on écrit (1.1) : il y a obligatoirement une association (donc une valeur pour la clé étrangère dans chaque occurrence de l’entité en question). Si ce n’est pas le cas, une erreur doit être signalée par le système. Si on écrit (1.n), il doit y avoir au moins deux associations. S’il y en a moins une erreur doit être signalée par le système. La description de ces contraintes a été faite au § 3.3.

9.3 Les contraintes d’intégrité référentielles


Les contraintes d’intégrité référentielle concernent les clés étrangères : c’est-à-dire les attributs qui font références à la clé primaire d’une autre entité. Les contraintes d’intégrité référentielle imposent un ordre dans la création des tables et des tuples quand on passe au MLD. Quand on crée une table qui contient une clé étrangère qui fait référence à une clé primaire dans une autre table, il faut que cette autre table et sa clé primaire ait déjà été créée. De même, quand on crée une tuple qui contient une clé étrangère qui fait référence à une clé primaire dans une autre tuple, il faut que cette autre tuple et sa clé primaire ait déjà été créé. Pour détruire une table qui est référencée par une clé étrangère dans une autre table, il faut d’abord détruire la ou les tables qui référencent la table qu’on veut détruire. De même, quand on veut détruire un tuple qui est référencé par d’autres tuples, alors on a deux options : • Soit la destruction est interdite tant qu’il existe des tuples qui référencent le tuple qu’on veut détruire. • Soit la destruction du tuple en question est accompagnée automatiquement de la destruction de tous les tuples qui le référence. Exemple : Soit deux tables, la table des employés et la table des départements. Les employés travaillent dans un département et un seul. On arrive au schéma suivant :

E (E, Ex, #D) D (D, Dx) Quand on crée les tables, il faut commencer par la table D. Quand on crée un employé, il faut que le département dans lequel il travaille existe déjà. Quand on détruit un département : soit il faut faire en sorte qu’il n’y ait plus aucun employé qui travaille dans ce département (destruction des employés ou affectation des employés dans un autre département) ; soit, automatiquement, la destruction du département conduit à la destruction des tuples. Si ces contraintes n’étaient pas vérifiées, on pourrait avoir des employés qui travaillent dans un département qui n’existe plus.

9.4 Les contraintes concernant les valeurs des attr ibuts

Présentation Ces contraintes s’appliquent aux attributs des entités et des associations. Elles permettent de limiter le domaine des valeurs possible de l’attribut. On peut définir 4 types de contraintes d’attribut • Le type • La non-nullité


• L’unicité • Des limites quand aux valeurs possibles que l’attribut peut prendre. • Les contraintes de groupe

La contrainte de type Le type de l’attribut limite le domaine de valeurs possible : entier, texte, réel, etc.

La non-nullité Tout attribut doit avoir une valeur. Quand on ne connaît pas la valeur, par défaut elle vaut NULL. On peut imposer le fait que la valeur de l’attribut ne soit jamais NULL.

Unicité Les clés primaires sont des attributs qui ont une valeur unique dans l’ensemble de la table. On peut imposer que d’autres attributs, qui ne sont pas clés, aient aussi cette caractéristique d’unicité.

Limites Une fois le type défini, on peut imposer des limites aux valeurs possibles de l’attribut. Par exemple : mettre une borne inférieure, une borne supérieure, lister les valeurs possibles. Ces limites peuvent aussi être calculées en fonction de la valeur d’autres éléments du système d’information.

Contraintes sur les clés étrangères On peut aussi limiter la possibilité de valeur d’une clé étrangère en regardant si les valeurs des attributs du tuple référencé vérifient certaines conditions.

Formalisme et exemples L’expression des règles de contraintes dans un MCD comporte : - Le nom de la règle. - La description de l’algorithme (sous forme de français structuré ou pseudo_code) - Les entités, relations et propriétés utilisées par la règle. La règle est représentée dans le MCD dans un rectangle à coin cornée, le lien avec les propriétés, relations, et entités est représenté en pointillés.

Exemple 1


C1 = si x ∈ Employé, alors x.salaire > = SMIG Exemple 2

La moyenne des salaires du service commerciale doit être < = 300 D C2 = si x ∈ Employé, et service.noms = "commercial", alors MOY (x.salaire) < = 300 D

Exemple 3

Le salaire d’un employé ne peut pas décroître. C3 = si x ∈ Employé, alors x.salaire > = ancien (x.salaire)

Exemple 4

Les employés du service peuvent avoir une augmentation de salaire au maximum de 7 % C4 = si x ∈ Employé, et x.service.noms = "commercial", alors x.salaire < = ancien (x.salaire) * 1.07

Exemple 5


La somme des salaires du service administratif doit être > = à la somme des salaires de service commercial. C5 = si x, y ∈ Employé, et x.service.noms = "administratif" et y.service.noms = "commercial", SOM (x.salaire) > = Som (y.salaire)

Exemple 6

Dans un mariage, les époux doivent être de sexes différents. C2 = si x ∈ Personne et y ∈ Personne, et existe une relation marier à (x, y), alors x.sexe # y.sexe

9.5 Les contraintes sur les entités dans le modèle orienté objet

Présentation Ces contraintes concernent l’existence même des occurrences des entités (des tuples). Elles sont à vérifier à chaque fois qu’on crée une nouvelle occurrence d’entité. Pour les aborder, on va d’abord présenter deux notions utiles du modèle objet :

La notion de couverture Il y a couverture si toute occurrence de A (sur-type) appartient au moins à l’un des sous types (B et C) :

non couverture couverture couverture

La notion de disjonction Il y a disjonction quand toute occurrence de A (sur-type) appartient au plus à un seul sous-type :


disjonction disjonction non-disjonction

Cas général : disjonction et non-couverture Remarque : Si nous avons non-disjonction + non-couverture, il n’y a plus de contraintes à représenter.

Contrainte de couverture et disjonction

Dans ce cas, le système d’information doit empêcher la création d’occurrences dans la table des personnes.

Contrainte de couverture et non-disjonction


Dans ce cas le système d’information doit imposer que les occurrences dans la table des personnes en classes fassent référence à un étudiant et à un salarié : ces occurrences correspondent aux personnes qui sont à la fois étudiant et salarié.

Contrainte de non-couverture et disjonction

Dans ce cas, les occurrences de la table des comptes (C) correspondent aux comptes qui ne sont ni courant (CC), ni épargne (CE). Ces occurrences ne font référence ni au CC ni au CE, de même que ni les CC, ni les CE ne font référence aux C.

9.6 Les contraintes sur associations

Ces contraintes concernent l’existence même des occurrences des associations. Elles sont à vérifier à chaque fois qu’on crée une nouvelle occurrence d’association.


Contrainte d’exclusion : non-couverture + disjonction

Exemple 1 :

Dans ce cas, par exemple, le système vérifie quand on veut créer une occurrence de l’association salarié, que la personne concernée n’est pas étudiante.

Exemple 2 :

Exemple 3 :

La contrainte de partition : couverture + disjonction


Exemple :

La contrainte de partition diffère de la contrainte d’exclusion par le fait que la personne est forcément associée une fois : la somme des cardinalités des associations sur lesquelles on pose la contrainte de partition (0,1) et (0,1) vaut (1, 1) avec la contrainte.

La contrainte de totalité : couverture + non-disjonction

Exemple :

La contrainte d’inclusion


Exemple 1 :

Exemple 2 :

La contrainte d’égalité


Dans ce cas, on peut aussi considérer qu’on devrait créer une association entre les trois entités, ce qui nous permettrait de savoir dans quel club les personnes pratiquent les sports, et ce qui réglerait l’obligation de faire en sorte que toute personne qui pratique un sport fasse partie d’une équipe. Dans l’exemple, on a : P (P, Px) ; C (C, Cx) ; S (S, Sx) ; App (#C, #P) ; Prat (#P, #S) La contrainte d’égalité dit que quand je crée une occurrence App (cx, p1) je dois créer un Prat (p1, sx). L’autre solution de modélisation consisterait à proposer le schéma suivant : P (P, Px) ; C (C, Cx) ; S (S, Sx) ; PratiqueDansUnClub (#C, #P, #C)

La contrainte d’unicité


Dans ce cas, c’est comme si on avait une association hiérarchique entre l’association « nommer » et l’entité « fonction ».


10. COMPLÉMENTS DE MODÉLISATION

10.1 Retour sur les DF

Les DF entre les entités Il existe une DF entre deux entités A et B, si toute occurrence de A détermine une et une seule occurrence de B. La cardinalité maximale (1) correspond toujours à une DF, dans ce cas l’association est remplacée par une DF, l’orientation du lien entre les entités est indiqué par une flèche. Exemple :

⇓

On peut assimiler les DF entre les entités comme étant des DF entre les identifiants de ces entités. Une DF est faible (lien faible) si le couple de cardinalité est (0,1), la DF est représentée avec un trait en pointillé. Exemple :

Une DF est forte (lien fort) si le couple de cardinalité est (1,1), elle est notée en trait plein. Exemple :

Une CIF (Contrainte d’Intégrité Fonctionnelle) est une DF stable, c’est à dire, une fois le lien est établi, il ne peut pas être modifié dans le temps. Le couple de cardinalité source doit être obligatoirement (1,1). Exemple :

Rappel : les DF sont des liens non porteurs de propriétés, il est impossible d’avoir le cas suivant :


car les informations de la relation migrent normalement vers A (c’est le principe des associations hiérarchiques).

Les DF entre les relations

Une occupation correspond à un seul enseignement, et un enseignement peut être donné n fois, donc un enseignement peut avoir plusieurs occupations.

Les DF entre les entités et les relations

Une commande pour un produit est livrée par un seul dépôt.

Les DF et les CIF pour les relations 1 à 1

Pour savoir dans quel sens prendre le DF ou la CIF, lorsque l’on a une cardinalité maximale (1) des deux côtés, il faut faire intervenir le temps. La contrainte sera prise dans le sens allant de l’occurrence la plus récente à l’occurrence la plus ancienne.

10.2 Cas particulier de dépendance fonctionnelle

Lorsque des DF sont définies sur une relation n-aire, une décomposition de cette relation est envisageable. Cette décomposition permettra d’une part de mieux matérialiser certaines DF, et d’autre part, rendra les relations plus facilement interprétables. Exemple :


La décomposition n’est possible qu’à deux conditions : Condition 1 : si les entités émettrices des DF ont une cardinalité (1,1), alors la décomposition est systématique. Exemple :

Condition 2 : Si les entités émettrices de la DF ont une cardinalité (0,1), alors on ne procédera à la décomposition que si les deux nouvelles relations ont une existence liée, c’est-à-dire, il est nécessaire d’ajouter une contrainte d’égalité. Exemple :


10.3 Quatrième forme normale

Les dépendances multi-valuées (DM)

La 4ème forme normale : 4FN

10.4 L’identification relative

Un identifiant absolu permet l’identification univoque de l’objet. Un identifiant relatif permet l’identification de l’objet dans un certain contexte. Exemple :

L’identifiant de tranche est le n° d’ordre relatif à un projet. L’identification relative peut être représentée de la manière suivante :

Dans l’identification relative, la relation doit être porteuse d’une DF forte (cardinalité : 1,1). Une entité avec un identifiant relatif est appelée aussi entité faible, l’identifiant absolu de cette entité est la juxtaposition de son identifiant relatif et de l’identifiant absolu de l’entité de rattachement.


L’identification relative peut être multiple et s’exprimer à travers plusieurs relations. Exemple :

2006 EPITECH 2-CSI Merise - bliaudet.free.fr

Documents

Transcript of 2006 EPITECH 2-CSI Merise - bliaudet.free.fr