Conception d’une base de donn´ ees

Cyril Gruau ∗ 13 novembre 2003

R´ esum´ e Ce support de cours regroupe quelques notions concernant le mod` ele entit´ e-association, le sch´ ema relationnel et la traduction de l’un vers l’autre.

Mots-clef : Merise, MCD, entit´ e, association, MLD, relation, traduction, MPD

Table des mati` eres
Introduction 1 Mod` ele conceptuel de donn´ ees 1.1 Sch´ ema entit´ e-association . . 1.2 Cas particuliers . . . . . . . . 1.3 R` egles de normalisation . . . 1.4 M´ ethodologie . . . . . . . . . (MCD) . . . . . . . . . . . . . . . . . . . . 2 2 2 4 6 7 7 7 8 8 12 12 13 13 14 16 17 18 19 19 20

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

2 Mod` ele logique de donn´ ees (MLD) 2.1 Syst` emes logiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Sch´ ema relationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Traduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Mod` ele physique de donn´ ees (MPD) 4 R´ etro-conception 5 Compl´ ements 5.1 Agr´ egation . . . 5.2 Identifiant relatif 5.3 Sous-entit´ e . . . 5.4 Sous-association Conclusion Table des figures R´ ef´ erences Index

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

Cyril.Gruau@ensmp.fr

1

INTRODUCTION

2

Introduction
Les techniques pr´ esent´ ees ici font partie de la m´ ethodologie Merise ´ elabor´ ee en France en 1978 (cf. [5]) qui permet notamment de concevoir un syst` eme d’information d’une fa¸ con standardis´ ee et m´ ethodique. Le but de ce support de cours est d’introduire le sch´ ema entit´ e-association, le sch´ ema relationnel et d’expliquer la traduction entre les deux. Ne sont pas abord´ es ici : les d´ ependances fonctionnelles, les contraintes, les traitements, les langages relationnels, la gestion de projet. Pour tout cela, le lecteur est dirig´ e vers [2, 3]. La mod´ elisation objet ne fait pas non plus partie des outils expos´ es dans ce document.

1

Mod` ele conceptuel de donn´ ees (MCD)

Avant de r´ efl´ echir au sch´ ema relationnel d’une application, il est bon de mod´ eliser la probl´ ematique a traiter d’un point de vue conceptuel et ind´ ` ependamment du logiciel utilis´ e. C’est le but de cette partie.

1.1

Sch´ ema entit´ e-association

Une entit´ e est une population d’individus n’ayant que des caract´ eristiques comparables. Par exemple, dans une entreprise qui ach` ete et vend des produits, on a l’entit´ e clients, l’entit´ e articles et l’entit´ e fournisseurs.

Fig. 1 – Entit´ es Une association est un lien entre plusieurs entit´ es. Dans notre exemple, l’association acheter fait le lien entre les entit´ es articles et clients, tandis que l’association livrer fait le lien entre les entit´ es articles et fournisseurs.

Fig. 2 – Associations

. Fig. le nom du client est un attribut de l’entit´ e clients. la date de livraison est un attribut de l’association livrer.` ´ 1 MODELE CONCEPTUEL DE DONNEES (MCD) Un attribut est une propri´ et´ e d’une entit´ e ou d’une association. l’identifiant . 3). C’est pourquoi les entit´ es doivent poss´ eder un attribut sans doublon. La cardinalit´ e d’un lien entre une entit´ e et une association est le minimum et le maximum de fois qu’un individu de l’entit´ e peut ˆ etre concern´ e par l’association. le prix unitaire est un attribut de l’entit´ e articles. – conclusion : dans le mod` ele physique de donn´ ees (cf. – une association peut ne pas poss´ eder d’attribut. La quantit´ e command´ ee est un attribut de l’association acheter. – il faut un identifiant totalement ind´ ependant des autres attributs (´ eviter par exemple d’ajouter un identifiant NomPr´ enom qui serait la concatenation des attributs nom du client et pr´ enom) . on utilise une cl´ e num´ erique (un entier) incr´ ement´ ee automatiquement. Fig. 4 – Identifiants Remarques : – un attribut ne doit pas figurer dans deux entit´ es ou associations diff´ erentes (donc il faut sp´ ecialiser l’attribut nom en nom du client. 3 – Attributs Chaque individu d’une entit´ e doit ˆ etre identifiable de mani` ere unique. – une entit´ e poss` ede au moins un attribut (son identifiant) . Conseils : – ´ eviter les identifiants compos´ ees de plusieurs attributs (comme par exemple un identifiant form´ e par les attributs nom du client et pr´ enom) . – pr´ ef´ erer un identifiant court pour rendre la recherche la plus rapide possible (´ eviter par exemple les chaˆ ınes de caract` eres comme le num´ ero de s´ ecurit´ e sociale ou la plaque d’immatriculation) . 3 Toujours dans notre exemple. Le num´ ero de client est l’identifiant de l’entit´ e clients (on souligne cet attribut sur le sch´ ema). nom du produit et nom du fournisseur) .

Cela se justifie par le fait que mˆ eme si on connaˆ ıt n au moment de la conception. un employ´ e est dirig´ e par un employ´ e (sauf le Fig. 1. de telle sorte qu’on ne puisse avoir que des cardinalit´ es 0. 5 – Cardinalit´ es Remarque : si une cardinalit´ e est connue et vaut 2. 1 ou n. tandis qu’un article peut avoir ´ et´ e achet´ e entre 0 et n fois (mˆ eme si ce n’est pas le mˆ eme n) et n’est livr´ e que par 1 fournisseur. on consid` ere quand mˆ eme qu’elle est ind´ etermin´ ee n. Il vaut donc mieux consid´ erer n comme une inconnue d` es le d´ epart. il se peut que cette valeur ´ evolue avec la politique de l’entreprise. 3.2 Cas particuliers Exemple d’association binaire r´ eflexive : dans ce cas.` ´ 1 MODELE CONCEPTUEL DE DONNEES (MCD) 4 Un client a au moins achet´ e un article et peut acheter n articles (n ´ etant ind´ etermin´ e). On obtient alors le sch´ ema entit´ e-association complet suivant : Fig. . etc. 6 – Association r´ eflexive directeur g´ en´ eral) et un employ´ e peut diriger plusieurs employ´ es.

8 – Associations plurielles propri´ etaire. locataire et/ou charg´ e de l’entretien. un avion.` ´ 1 MODELE CONCEPTUEL DE DONNEES (MCD) 5 Exemple d’association entre trois entit´ es (association ternaire ) : dans ce cas. qu’un logement n’est occup´ e que par une personne au maximum et qu’un logement est entretenu par une et une seule personne (il s’agit d’un exemple). d’une part un vol peut Fig. plusieurs pilotes (s’il y a un co-pilote) et plusieurs a´ eroports (d´ epart/escales/arriv´ ee) d’o` u la n´ ecessit´ e d’une association ternaire et d’autre part. 7 – Association ternaire concerner plusieurs avions (si c’est un vol avec escale). Exemple de plusieurs associations entre deux mˆ emes entit´ es : dans ce cas. On suppose qu’un ˆ etre humain ne r´ eside que dans un logement au maximum. un ˆ etre humain peut ˆ etre Fig. un pilote ou un a´ eroport peuvent ˆ etre utilis´ es 0 ou plusieurs fois par l’ensemble des vols (d’o` u les cardinalit´ es). .

Normalisation des relations 1 (importante) : les attributs des associations doivent d´ ependre des identifiants de toutes les entit´ es en association. Par exemple.3 R` egles de normalisation Premi` ere forme normale : chaque entit´ e doit poss´ eder un identifiant qui caract´ erise ses individus de mani` ere unique. Il faut donc faire une entit´ e commandes ` a part : Fig. Forme normale de Boyce-Codd (` a oublier ´ egalement) : les attributs d’un identifiant compos´ e ne doivent pas d´ ependre d’un autre attribut de l’entit´ e. 9 – Normalisation des relations 1. il reste les associations. Deuxi` eme forme normale : l’identifiant peut ˆ etre compos´ ee de plusieurs attributs mais les autres attributs de l’entit´ e doivent ˆ etre d´ ependant de l’identifiant en entier (et non pas une partie de cet identifiant). comprendre : normalisation des associations . Elle ne doit pas figurer dans l’entit´ e clients. Par exemple. en association avec clients. Ces deux premi` eres formes normales peuvent ˆ etre oubli´ ee si on suit le conseil de n’utiliser que des identifiants non compos´ es de type num´ ero.` ´ 1 MODELE CONCEPTUEL DE DONNEES (MCD) 6 1. il faut donc faire une entit´ e calendrier ` a part. seules les entit´ A es ont ´ et´ e normalis´ ees. Troisi` eme forme normale (importante) : les attributs d’une entit´ e doivent d´ ependre directement de son identifiant. ` ce stade. la quantit´ e command´ ee d´ epend ` a la fois du num´ ero de client et du num´ ero d’article. la date de fˆ ete d’un client ne d´ epend pas de son identifiant num´ ero de client mais plutˆ ot de son pr´ enom. par contre la date de commande non.

Un mod` ele logique de donn´ ees orient´ e objet permet par exemple de concevoir des classes Java s’appuyant sur une base de donn´ ees relationnelle et permettant le d´ eveloppement d’une application web. puis les SGBD r´ eseaux dans lesquels les donn´ ees sont organis´ ees selon un graphe plus g´ en´ eral (IDS2 de Bull par exemple). – ´ etablir les associations entre les entit´ es . 2. – ´ eliminer les synonymes (plusieurs signifiants pour un signifi´ e) et les polys` emes (plusieurs signifi´ es pour un signifiant) . Il faut garder ´ egalement ` a l’esprit que le mod` ele doit ˆ etre exhaustif (c’est-` a-dire contenir toutes les informations n´ ecessaires) et ´ eviter toute redondance (le prix unitaire d’un article n’a pas besoin de figurer dans l’entit´ e commandes. c’est la troisi` eme forme normale). comme les syst` emes par fichiers ou les bases de donn´ ees. .1 Syst` emes logiques Avant l’apparition des syst` emes de gestion de base de donn´ ees (SGBD ou DBMS pour Data Base Management System en anglais). Voir [1] pour une traduction d’un MPD vers un MLD fichier. Ces deux types de SGBD sont dit navigationnels car on peut retrouver l’information ` a condition d’en connaˆ ıtre le chemin d’acc` es. – v´ erifier la troisi` eme forme normale et la normalisation des relations (surtout pour les associations non binaires) . – ajouter les identifiants . La maintenance des programmes (en cas de modification de la structure des donn´ ees par exemple) ´ etait tr` es probl´ ematique. 3. Cobol ou Dbase par exemple). – lister leurs attributs . Voir [2. – calculer les cardinalit´ es . sont apparus des SGBD orient´ es objets qui offrent ` a la fois un langage de requˆ ete et une navigation hypertexte. 2 Mod` ele logique de donn´ ees (MLD) Maintenant que le MCD est ´ etablit. Nous nous contentons donc ici du mod` ele logique de donn´ ees relationnel (MLDR). 1] pour une traduction d’un MPD vers un MLD Codasyl (base de donn´ ees r´ eseaux). les donn´ ees ´ etaient stock´ ees dans des fichiers binaires et g´ er´ ees par des programmes ex´ ecutables (Basic.4 M´ ethodologie Face ` a un probl` eme bien formul´ e (mˆ eme si ¸ ca n’existe pas) proc´ eder ainsi : – identifier les entit´ es en pr´ esence . Ce sont les SGBD les plus r´ epandus (Oracle et DB2 d’IBM par exemple). – effectuer les corrections n´ ecessaires.` ´ 2 MODELE LOGIQUE DE DONNEES (MLD) 7 1. Sont alors apparus les SGBD hi´ erarchiques dans lesquels les donn´ ees sont organis´ ees en arbre (IMSDL1 d’IBM par exemple). Aujourd’hui. ils sont largement remplac´ es par les SGBD relationnels (SGBDR) avec lesquels l’information peut ˆ etre obtenue par une requˆ ete formul´ ee dans un langage quasiment naturel. on peut le traduire en diff´ erents syst` emes logiques. – lister leurs attributs . Plus r´ ecemment.

il se peut qu’une colonne Colonne1 d’une table ne doive contenir que des valeurs prises par une colonne Colonne2 d’une autre table (par exemple. La cl´ e primaire d’une ligne ne doit pas changer au cours du temps et ne peut contenir la valeur NULL.. – une cl´ e´ etrang` ere peut aussi ˆ etre primaire .. . on peut les organiser en table dans laquelle les colonnes d´ ecrivent les champs en commun et les lignes contiennent les valeurs de ces champs pour chaque enregistrement.) Remarques : – une mˆ eme table peut avoir plusieurs cl´ es ´ etrang` eres mais une seule cl´ e primaire (´ eventuellement compos´ ees de plusieurs colonnes) .1 ou 1. Par convention. les bordereaux de livraison).` ´ 2 MODELE LOGIQUE DE DONNEES (MLD) 8 2.2 Sch´ ema relationnel Concentrons-nous sur le MLDR.) commandes(num´ ero commande.1 . on dit qu’une association entre deux entit´ es (´ eventuellement r´ eflexive) est de type : – 1 : 1 si les deux cardinalit´ es sont 0.. La section suivante contient des exemples. – n : m (plusieurs ` a plusieurs) si les deux cardinalit´ es sont 0.n ou 1. .n ou 1.n. On peut repr´ esenter les tables d’une base de donn´ ees relationnelle par un sch´ ema relationnel dans lequel les tables sont appel´ ees relations et les liens entre les cl´ es ´ etrang` eres et leur cl´ e primaire est symbolis´ e par un connecteur : Fig. on souligne les cl´ es primaires et on fait pr´ ec´ eder les cl´ es ´ etrang` eres d’un di` ese # dans la description des colonnes d’une table : clients(num´ ero client. Lorsque des donn´ ees ont la mˆ eme structure (comme par exemple. 10 – Sch´ ema relationnel 2. cela signifie qu’une colonne (au moins) doit servir de cl´ e primaire . pr´ enom. il suffit d’appliquer cinq r` egles (` a connaˆ ıtre par cœur). – une cl´ e´ etrang` ere peut ˆ etre compos´ ee (c’est le cas si la cl´ e primaire en liaison est compos´ ee). le num´ ero du client sur une commande doit correspondre ` a un vrai num´ ero de client). #num´ ero client..n . Mais avant. – 1 : n si une des deux cardinalit´ e est 0.3 Traduction Pour traduire un MCD en troisi` eme forme normale en un MLDR. La Colonne2 doit ˆ etre sans doublons (bien souvent il s’agit d’une cl´ e primaire) et on dit que la Colonne1 est cl´ e´ etrang` ere . adresse client. Les lignes d’une table doivent ˆ etre uniques. Par ailleurs. nom client. alors que les autres colonnes le peuvent. date. .

L’identifiant de l’entit´ e constitue alors la cl´ e primaire de la table.1 ou 1. t´ el´ ephone.1. . on ajoute. r` egles 2 et 3). Par exemple.. on ajoute une contrainte d’unicit´ e sur chaque de ces cl´ es ´ etrang` eres (la colonne correspondante ne peut prendre que des valeurs distinctes). .n. date.. Les attributs de l’association sont alors repartis vers l’une des deux tables.1 alors la cl´ e´ etrang` ere ne peut recevoir la valeur NULL (autrement dit. . il peut la faire entre 0. l’association livrer de la figure 9 est traduite par : fournisseurs(num´ ero fournisseur.. Et si la cardinalit´ e est 1.1 (cf.) articles(num´ R` egle 2 : dans le cas de deux entit´ es reli´ ees par une association de type 1 : n.` ´ 2 MODELE LOGIQUE DE DONNEES (MLD) 9 En fait.. nom. Par contre. pr´ enom. vers la cl´ e primaire de la table cˆ ot´ e 0.. 11 – Traduction d’une association de type 1 : n R` egle 3 : dans le cas de deux entit´ es reli´ ees par une association de type 1 : 1. prix unitaire de vente. nom livreur) Fig. montant du loyer. #num´ ero fournisseur (non vide).n et 1. nom article.) livraisons(num´ ero livraison. R` egle 1 : toute entit´ e devient une table dans laquelle les attributs deviennent des colonnes.. une cl´ e´ etrang` ere vers la cl´ e primaire de l’autre. vide interdit). . vide interdit). Par exemple. Les attributs de l’association glissent vers la table cˆ ot´ e 0.1 ou 1. date d’entr´ ee. #num´ ero personnel (unique). un sch´ ema relationnel ne peut faire la diff´ erence entre 0.n. on ajoute une cl´ e ´ etrang` ere dans la table cˆ ot´ e 0. #num´ ero appartement (unique).. Par exemple. l’association r´ esider de la figure 8 est traduite par : etres humains(num´ ^ ero personnel. nom fournisseur.) logement(num´ ero appartement.n ou 1.) .1. l’entit´ e articles de la figure 9 devient la table : ero article.1 et 1.1 alors la cl´ e´ etrang` ere concern´ ee ne peut recevoir la valeur NULL (autrement dit.. adresse. aux deux tables. Et si la cardinalit´ e est 1. Afin d’assurer la cardinalit´ e maximale de 1.

. Autre technique : ajouter une table interm´ ediaire dont la cl´ e primaire est compos´ ee de cl´ es ´ etrang` eres vers les cl´ es primaires des tables en association et une contrainte d’unicit´ e sur ces cl´ es ´ etrang` eres (c’est-` a-dire consid´ erer le type 1 : 1 comme un cas particulier du type n : m) : ^tres humains(num´ e ero personnel. Les attributs de l’association deviennent des colonnes de cette table.` ´ 2 MODELE LOGIQUE DE DONNEES (MLD) 10 Fig. Remarque : d’autres techniques sont parfois propos´ ees pour la r` egle 3 (fusionner les tables. .) r´ esider(#num´ ero personnel (unique). 13 – Traduction alternative d’une association de type 1 : 1 Cette alternative est sans doutes pr´ ef´ erable. R` egle 4 : une association entre deux entit´ es et de type n : m est traduite par une table suppl´ ementaire (parfois appel´ ee table de jointure ) dont la cl´ e primaire est compos´ ee de deux cl´ es ´ etrang` eres vers les cl´ es primaires des deux tables en association. adresse. #num´ ero appartement (unique). . nom. date d’entr´ ee. car plus ´ evolutive (si le type 1 : 1 est un jour converti en un autre type). la r` egle 3 consid` ere que le type 1 : 1 correspond ` a deux type 1 : n sym´ etriques. pr´ enom. . utiliser une cl´ e primaire identique) mais en pratique elles ne sont pas exploitables dans le cas g´ en´ eral.) logement(num´ ero appartement. 12 – Traduction d’une association de type 1 : 1 En fait.. montant du loyer) Fig...

Par exemple. .. prix unitaire de vente..) lignes de commande(#num´ ero commande.) commandes(num´ 11 Fig. 14 – Traduction d’une association de type n : m R` egle 5 : une association non binaire est traduite par une table suppl´ ementaire dont la cl´ e primaire est compos´ ees d’autant de cl´ es ´ etrang` eres que d’entit´ es. date.. l’association concerner (1) de la figure 9 est traduite par : articles(num´ ero article. 15 – Traduction d’une association ternaire . l’association vols de la figure 7 devient la table : vols(#num´ ero avion. nom article. . #num´ ero pilote.` ´ 2 MODELE LOGIQUE DE DONNEES (MLD) Par exemple. #num´ ero a´ eroport. #num´ ero article. dur´ ee. Les attributs de l’association deviennent des colonnes de cette table. quantit´ e command´ ee) ero commande. date et heure.. distance) Fig.

R` egle 2 : les tables dont la cl´ e primaire est compos´ ee (exclusivement) de cl´ es ´ etrang` eres deviennent des associations n-aires. Il s’agit de r´ etro-conception ou reverse engineering . puis d’appliquer les r` egles de traduction du paragraphe 2. On renonce donc ` a la troisi` eme forme normale Fig. 4 R´ etro-conception Dans la majorit´ e des cas. mais on ´ evite une jointure coˆ uteuse en temps de calcul lors des requˆ etes. le MPD s’int´ eresse au stockage des donn´ ees ` a travers le type et la taille (en octets ou en bits) des attributs du MCD. . la donn´ ee est un mod` ele physique et la m´ ethode consiste ` a le traduire en un mod` ele conceptuel. le travail du concepteur de bases de donn´ ees consiste non pas ` a cr´ eer une base ex nihilo. Dans ce cas. on peut traduire un MPD Access en un MLDR puis traduire ce MLDR en un MPD Oracle. o` u n est le nombre de colonne d´ efinissant la cl´ e primaire (les autres colonnes non cl´ es ´ etrang` eres deviennent attributs). R` egle 1 : les tables dont la cl´ e primaire est non compos´ ee (et non cl´ e ´ etrang` ere) deviennent des entit´ es (les colonnes non cl´ es ´ etrang` eres deviennent des attributs et la cl´ e primaire devient identifiant). Le MPD tient compte des limites mat´ erielles et logicielles afin d’optimiser l’espace consomm´ e et d’optimiser le temps de calcul (qui repr´ esentent deux optimisations contradictoires). le MPD d´ efinit les index et peut ˆ etre amen´ e` a accepter certaines redondances d’information afin d’acc´ el´ erer les requˆ etes. Le MPD est une impl´ ementation particuli` ere du MLD pour un mat´ eriel. Dans le cas d’un SGBDR.3 dans le sens inverse. Dans le cadre des bases de donn´ ees relationnelles. 16 – Sacrifice de la troisi` eme forme normale puisque la date est r´ ep´ et´ ee autant de fois qu’il y a de lignes dans la commandes. modifier ce mod` ele et r´ eg´ en´ erer le mod` ele physique modifi´ e. c’est faux. un environnement et un logiciel donn´ e. Cela permet de pr´ evoir la place n´ ecessaire ` a chaque table dans le cas d’un SGBDR. Notamment. la table commandes de la figure 14 peut ˆ etre supprim´ ees et ses colonnes. Par exemple. notamment date. il suffit de traduire le mod` ele physique en un MLDR.` ´ 3 MODELE PHYSIQUE DE DONNEES (MPD) 12 3 Mod` ele physique de donn´ ees (MPD) Bien que certains outils (PowerAMC notamment) consid` ere que le MPD et le MLD repr´ esentent la mˆ eme chose. sont ajout´ ees ` a la table lignes de commandes. Une application pratique de la s´ eparation entre le MLDR et le MPD est le portage d’une base de donn´ ees d’un SGBD ` a un autre. Par exemple. mais plutˆ ot ` a corriger ou ´ etendre une base existante.

. une des r` egles de gestion est qu’un produit pour une r´ egion donn´ ee. alors cette r` egle n’est pas forc´ ement respect´ ee. Elles permettent de traiter certaines situations r´ eelles plus simplement. Il faut Fig.´ 5 COMPLEMENTS 13 R` egle 3 : les colonnes cl´ es ´ etrang` eres restantes deviennent des associations binaires de type 1 : n (il reste ` a r´ e-inventer leur nom). Si on se contente du sch´ ema de la figure 17. Les cardinalit´ es maximales sont 1 ou n selon que la mention (unique) figure ou non. [4]).1 Agr´ egation Exemple : dans un entreprise dont les repr´ esentants vendent des produits dans diff´ erentes r´ egions. 5. figure 18). 5 Compl´ ements Les extensions pr´ esent´ ees dans cette section font partie de la version 2 de Merise (cf. R` egle 4 : les cardinalit´ es minimales sont 1 si figure la mention (non vide) et ` a retrouver par le bon sens sinon (0 par d´ efaut). 17 – Mauvais MCD utiliser une agr´ egation qui permet d’associer une entit´ e` a un couple d’entit´ es en associations (cf. ne peut ˆ etre vendu que par un seul repr´ esentant. L’agr´ egation constitue alors une entit´ e dont l’identifiant est compos´ e des identifiants de ses propres entit´ es en association.

nom produit.) produits(num´ ero produit. .. #num´ ero produit) vendre(##num´ ero r´ egion. . nom repr´ esentant.) couvrir(#num´ ero r´ egion.´ 5 COMPLEMENTS 14 Fig.. figure 19). le sch´ ema relationnel que l’on obtient est alors le suivant : repr´ esentants(num´ ero repr´ esentant.. nom r´ egion. #num´ ero repr´ esentant. . ##num´ ero produit. #num´ ero produit. date et heure) Si l’association vendre ´ etait de type n : m (cf... nom repr´ esentant. nom produit....) r´ egions(num´ ero r´ egion. ..) produits(num´ ero produit. #num´ ero repr´ esentant (non vide).. 18 – Solution avec agr´ egation Comme l’association vendre est de type 1 : n.. .2 Identifiant relatif Exemple : une entreprise du bˆ atiment num´ erote les factures relatives ` a un chantier par le num´ ero du chantier suivi d’un num´ ero automatique. date et heure) 5. alors le sch´ ema relationnel ferait intervenir une table suppl´ ementaire : repr´ esentants(num´ ero repr´ esentant. .) r´ egions(num´ ero r´ egion. . nom r´ egion. Les factures du chantier 14 sont 1401.) couvrir(#num´ ero r´ egion.. 1402 et 1403 tandis que celles du chantier 15 sont 1501 et 1502.

.) . 19 – Agr´ egation avec une association de type n : m Le num´ ero de facture est donc relatif au num´ ero de chantier. date.. num´ ero facture... figure 21) pour indiquer que l’identifiant de l’entit´ e concern´ ee est relatif ` a l’autre entit´ e en association. On aimerait avoir le sch´ ema de la figure Fig. mais on ne peut pas utiliser deux fois un mˆ eme attribut dans un MCD. il suffit de mettre entre parenth` eses la cardinalit´ e 1.´ 5 COMPLEMENTS 15 Fig.) factures(#num´ ero chantier. adresse.1 (cf.. . Au niveau logique relationnel. Avec Merise 2. 20 – Identifiant par concat´ enation 20. cela se traduit par une cl´ e primaire compos´ ee notamment d’une cl´ e ´ etrang` ere : chantiers(num´ ero chantier.

´ 5 COMPLEMENTS 16 Fig. Fig. pour les r` eglements par ch` eque. Cette entreprise souhaite connaˆ ıtre pour tous les r` eglements. le nom de la banque et le num´ ero du ch` eque et pour les r` eglements par carte. num´ ero carte. . num´ ero ch` eque) cartes(#num´ ero r` eglement. on retrouve la notion d’h´ eritage. on repr´ esente le lien qui unie une sous-entit´ e` a son entit´ e g´ en´ erique par une fl` eche (cf. nom banque) ch` eques(#num´ ero r` eglement. Sur le sch´ ema entit´ e-association. 21 – Repr´ esentation d’un identifiant relatif 5. le num´ ero de la carte. 22 – Repr´ esentation des sous-entit´ es La traduction des sous-entit´ es au niveau logique relationnel fait intervenir une cl´ e primaire commune qui est aussi ´ etrang` ere : r` eglements(num´ ero r` eglement. leur date. figure 22 ). le nom de la banque et la date d’expiration. Ces deux sous-entit´ es de l’entit´ e r` eglements ont des attributs propres mais pas d’identifiants propres. date expiration) Remarque : au niveau logique objet. date. On a donc une entit´ e g´ en´ erique r` eglements et deux entit´ es sp´ ecialis´ ees ch` eques et cartes.3 Sous-entit´ e Exemple : les factures d’une entreprise font l’objet d’un r` eglement par ch` eque ou par carte.

4 Sous-association Exemple : une entreprise artisanale vend non seulement des produits ` a prix unitaire fixe..) produits standards(#(1)num´ ero produit. #num´ ero produit. dur´ ee) . quantit´ e) concerner standard(##num´ ero commande. ##(1)num´ ero produit) concerner personnalis´ e(##num´ ero commande. mais avec leurs attributs propres : produits(num´ ero produit. figure 23 ).) concerner(#num´ ero commande. prix unitaire) produits personnalis´ es(#(2)num´ ero produit. . Dans ce cas. 23 – Repr´ esentation des sous-associations On a alors les sous-associations concerner standard et concerner personnalis´ e dont le lien avec l’association g´ en´ erique concerner est repr´ esent´ e par une fl` eche.. les sous-associations sont traduites de la mˆ eme mani` ere que l’association g´ en´ erique correspondante. . l’association concerner entre les entit´ es commandes et produits est sp´ ecialis´ ee selon qu’il s’agit d’un produit standard ou personnalis´ e (cf. mais aussi des produits sur mesure dont le prix unitaire est calcul´ e` a partir de la dur´ ee de confection et d’un taux horaire... date. taux horaire) commandes(num´ ero commande. non seulement l’entit´ e produits est sp´ ecialis´ ee en produits standards et produits personnalis´ es. nom produit. Fig. mais en plus. ##(2)num´ ero produit.´ 5 COMPLEMENTS 17 5. Dans le sch´ ema relationnel.

– le MLD peut ˆ etre obtenu automatiquement par des outils de g´ enie logiciel . Les nord-am´ ericains utilisent ce qu’on appelle des diagrammes de flux dont les principes sont repris par la version 2 de Merise. Le lecteur est donc invit´ e` a se documenter sur le cadre UML pour ˆ etre ` a la pointe de l’´ etat de l’art en m´ ethodologie de conception. autrement dit langage unifi´ e de mod´ elisation objet) qui tendent ` a remplacer Merise et ses extensions objets. non binaires ou r´ eflexives sont en pr´ esence (c’est important) . . ce sont les m´ ethodologies objets et leur unification UML (Unified Modeling Language. Aujourd’hui.CONCLUSION 18 Conclusion Int´ erˆ ets de la d´ ecomposition MCD/MLD/MPD : – le MCD permet d’´ eviter certaines erreurs de conception (en contradiction avec les r` egles de normalisation) . – le MCD permet de voir facilement quelles associations de type n : m. En Grande-Bretagne. Cependant. – le MCD peut ˆ etre traduit en diff´ erents MLD coh´ erents (notamment on peut traduire un MCD en un MLDR puis en une base de donn´ ees Access tandis qu’en parall` ele le MCD est traduit en un ensemble de classes Java (MPD orient´ e objet) afin de d´ evelopper une application web sur cette base Access). la m´ ethodologie standard s’appelle SSADM (Structured Systems Analysis ans Design Method) et repose sur les mˆ emes principes. la m´ ethodologie Merise est typiquement fran¸ caise.

. . . . . . . . . . . . Eyrolles. . . . . . . . . . . . . 1994. . . . . et Heckenroth. . . . . . . . . . . . Repr´ esentation des sous-entit´ es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B. . . . . et Tardieu. . . . . . . . . . . . R. . . . . . . . . . . . . . D. . . . . Apprendre et pratiquer Merise. . Edition d’organisation. . . . . . . . . . . . . . . . . . . . . . . . . Traduction d’une association ternaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Il s’agit-l` a du livre de r´ ef´ erence par les auteurs de la m´ ethode. . . . . . . Cet ouvrage tr` es accessible permet vraiment de comprendre la m´ ethode. . . . Agr´ egation avec une association de type n : m . . . . . . . Espinasse. . . . . . . . . . . . . .. . . . . . . . . . . . Ce livre d´ ecrit la version 2 de la m´ ethode. . . . . . . . . . Solution avec agr´ egation . . . . . . . . . . H. Comprendre Merise. . . . . . . . . . . .. . . . . . Rochfeld. . . . . . . . . . . . . . . . . . . . . . . . . . La m´ ethode Merise. . . . . . . . B. et Coletti. . . . . . . . Masson. . . . . . . . . . . . . . . . . Sch´ ema relationnel . . . . . . . Ing´ enierie des syst` emes d’information avec Merise. . . . . . . [2] Matheron. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . Sacrifice de la troisi` eme forme normale . . . . . . Ce livre tr` es synth´ etique permet de s’exercer sur la m´ ethode. . . . . . . . . . . . . . . . Cet ouvrage complet d´ etaille la m´ ethode dans son ensemble. . . . . . Traduction d’une association de type 1 : n . . . . . . . . . . Merise/2 : Mod` eles et techniques Merise avanc´ es. . . . . . . Identifiant par concat´ enation . 1994. . . . . . . . . . A. . Principes et outils. . . . 1986. . . . . . . . . . . . . . .TABLE DES FIGURES 19 Table des figures 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Entit´ es . ´ [4] Panet. . . . . . . . . . . . . . . . . . . . Repr´ esentation d’un identifiant relatif . . . . . . . . . .. . . . . . . . J. . . . . . . . . . . . . . . . . . Normalisation des relations . . . . . . . . . . . . . . . R. . . . . . . . . . Association r´ eflexive . . . . . . . . Associations . . . . . . . . . . . . . . . . . . . . . J. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Identifiants . . . . . . . . . 2 2 3 3 4 4 5 5 6 8 9 10 10 11 11 12 13 14 15 15 16 16 17 R´ ef´ erences [1] Gabay. . . . . . . . . . . Attributs . . . . . . . H. G. . . . . . Letouche. . . . . . . 1989. . Traduction d’une association de type 1 : 1 . . . . . . . . . . . . . . . . . . . . . Traduction alternative d’une association de type 1 : 1 Traduction d’une association de type n : m . . . . . . . . [3] Nanci. . . . . . Associations plurielles . . . . . . . . . . . . . . . . . Repr´ esentation des sous-associations . . . . . . . . . . . . . . ´ [5] Tardieu. . . . . . . . . .-P. . . . . . . . . . . . . Cohen. . . . . . Association ternaire . . . . . . . . . . . . . . . . . . . . . Cardinalit´ es . . . . . . . . . . 1992. . . . . . . . . . Sybex. . . . Edition d’organisation. . . . . Mauvais MCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . H. . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 SGBDR . . . . . . . . . . . .. . . . . . . . . . . . . .. . 13 association. . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . 3. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . .. . . . . 6 R r´ eseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 sp´ ecialisation . . . . . 6 T table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . .. . . . . . . . . ..5 attribut. . . . . . . . 2.. . . . . . . . .. . . . . . . . 7 F fichier . . . . .. . . . . . . .. . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .2 exhaustif . . . . . 7 D DBMS . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . .2 r´ eflexive . .3 P polys` eme . . . . . . . . . . . . . . 18 unicit´ e.. . . 7 normalisation des relations . . . . . . . . . . . . 8 primaire . . . 3 V vide . .. . . . . . . . . . . . . . . . . . . 9 O optimisation . . . . . . . . . . . 12 type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 cl´ e ´ etrang` ere . . . . . . . . . . . . . . . ... . . . . . . . . . 8 de jointure . . . . . . . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . 18 S SGBD . . . . . . . . . . . . . . . . . . .. .. . . . . . .. . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . 17 SSADM . . . . . . . . . . .. . . . .. . . . . . . . 16. .INDEX 20 Index A agr´ egation . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . 7 deuxi` eme forme normale . . . . . . . . . . . 12 redondance . . . .. . . . . . .. . . . . .. 7 I identifiant . . . . . 7 sous-association . . . . .. . 12 C cardinalit´ e . . . . . . . . . . . .. . .. . . . . . . . .. . . . . . . . . . . 8. . . . . . . . . . . . . . . 17 sous-entit´ e . . . . . . . . . . . . .. . . . . . 6 NULL . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . 7 portage . . . . . . . . . . . . . . . . .. . . . . . . . . . . . 7 r´ etro-conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . 18 synonyme . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . 8 Codasyl . . . . . . . . . . . . 7 forme normale de Boyce-Codd . . . . . . . . 18 MLDR . 7 E entit´ e. . .. .. . . .. . . . . . . . . . . . . . . . . . . . . . 7 reverse engineering . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . 7 N navigationnel . . . . . . . . . . . . . . . .. . . . . . . . . . .. . . . . . . .. . . . . . . . . . . . . . . . . . .. .9 H hi´ erarchique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . 16. .. . . . . . . . . . . 6. . . . . . .. . .. . . . . . . . . .. . . . 7 . .. . . 17 U UML . . . . . . . . . . . . . . . . . . . . 8 G g´ en´ ericit´ e . . . . . . . . . . .. . . . . . .. . . . . .. . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 premi` ere forme normale . . . . . . . .. . .. . . . . . . . . . 4 ternaire. . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . 7 relation . . . . . . 9 M Merise . 12 orient´ e objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 troisi` eme forme normale .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . 6 diagramme de flux . . . . . . . 8 requˆ ete . . . . . . . . . . . . . .

Sign up to vote on this title
UsefulNot useful