Vous êtes sur la page 1sur 18

Conception dune base de donn ees

Cyril Gruau 14 octobre 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 lun vers lautre.

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 11 11 11 13 14 15 16 17 17 18

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

2 Mod` ele logique de donn ees (MLD) 2.1 Les syst` emes logiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Sch ema relationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Traduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Mod` ele physique de donn ees (MPD) 4 Compl ements 4.1 Agr egation . . . 4.2 Identiant relatif 4.3 Sous-entit e . . . 4.4 Sous-association Conclusion Table des gures R ef erences Index

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

Cyril.Gruau@ensmp.fr

INTRODUCTION

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 dinformation dune fa con standardis ee et m ethodique. Le but de ce support de cours est dintroduire le sch ema entit e-association, le sch ema relationnel et dexpliquer 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.

Mod` ele conceptuel de donn ees (MCD)

Avant de r e echir au sch ema relationnel dune application, il est bon de mod eliser la probl ematique a traiter dun point de vue conceptuel et ind ` ependamment du logiciel utilis e. Cest le but de cette partie.

1.1

Sch ema entit e-association

Une entit e est une population dindividus nayant que des caract eristiques comparables. Par exemple, dans une entreprise qui ach` ete et vend des produits, on a lentit e clients, lentit e articles et lentit e fournisseurs.

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

Fig. 2 Associations

` 1 MODELE CONCEPTUEL DE DONNEES (MCD) Un attribut est une propri et e dune entit e ou dune association.

Toujours dans notre exemple, le prix unitaire est un attribut de lentit e articles, le nom du client est un attribut de lentit e clients. La quantit e command ee est un attribut de lassociation acheter, la date de livraison est un attribut de lassociation livrer.

Fig. 3 Attributs Chaque individu dune entit e doit etre identiable de mani` ere unique. Cest pourquoi les entit es doivent poss eder un attribut sans doublon, lidentiant . Le num ero de client est lidentiant de lentit e clients (on souligne cet attribut sur le sch ema).

Fig. 4 Identiants Remarques : un attribut ne doit pas gurer dans deux entit es ou associations di erentes (donc il faut sp ecialiser lattribut nom en nom du client, nom du produit et nom du fournisseur) ; une entit e poss` ede au moins un attribut (son identiant) ; une association peut ne pas poss eder dattribut. Conseils : eviter les identiants compos ees de plusieurs attributs (comme par exemple un identiant form e par les attributs nom du client et pr enom) ; il faut un identiant totalement ind ependant des autres attributs ( eviter par exemple dajouter un identiant NomPr enom qui serait la concatenation des attributs nom du client et pr enom) ; pr ef erer un identiant 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 dimmatriculation) ; conclusion : dans le mod` ele physique de donn ees (cf. 3), on utilise une cl e num erique (un entier) incr ement ee automatiquement. La cardinalit e dun lien entre une entit e et une association est le minimum et le maximum de fois quun individu de lentit e peut etre concern e par lassociation.

` 1 MODELE CONCEPTUEL DE DONNEES (MCD)

Un client a au moins achet e un article et peut acheter n articles (n etant ind etermin e), tandis quun article peut avoir et e achet e entre 0 et n fois (m eme si ce nest pas le m eme n) et nest livr e que par 1 fournisseur. On obtient alors le sch ema entit e-association complet suivant :

Fig. 5 Cardinalit es Remarque : si une cardinalit e est connue et vaut 2, 3, etc. on consid` ere quand m eme quelle est ind etermin ee n, de telle sorte quon ne puisse avoir que des cardinalit es 0, 1 ou n.

1.2

Cas particuliers

Exemple dassociation binaire r eexive : dans ce cas, un employ e est dirig e par un employ e (sauf le

Fig. 6 Association r eexive directeur g en eral) et un employ e peut diriger plusieurs employ es.

` 1 MODELE CONCEPTUEL DE DONNEES (MCD)

Exemple dassociation entre trois entit es (association ternaire ) : dans ce cas, un avion, un pilote ou

Fig. 7 Association ternaire un a eroport peuvent etre utilis es 0 ou plusieurs fois par lensemble des vols (do` u les cardinalit es). Exemple de plusieurs associations entre deux m emes entit es : dans ce cas, un etre humain peut etre

Fig. 8 Associations plurielles propri etaire, locataire et/ou charg e de lentretien. On suppose quun etre humain ne r eside que dans un logement au maximum, quun logement nest occup e que par une personne au maximum et quun logement est entretenu par une et une seule personne (il sagit dun exemple).

` 1 MODELE CONCEPTUEL DE DONNEES (MCD)

1.3

R` egles de normalisation

Premi` ere forme normale : chaque entit e doit poss eder un identiant qui caract erise ses individus de mani` ere unique. Deuxi` eme forme normale : lidentiant peut etre compos ee de plusieurs attributs mais les autres attributs de lentit e doivent etre d ependant de lidentiant en entier (et non pas une partie de cet identiant). Ces deux premi` eres formes normales peuvent etre oubli ee si on suit le conseil de nutiliser que des identiants non compos es de type num ero. Troisi` eme forme normale (importante) : les attributs dune entit e doivent d ependre directement de son identiant. Par exemple, la date de f ete dun client ne d epend pas de son identiant num ero de client mais plut ot de son pr enom. Il faut donc faire une entit e calendrier ` a part. Forme normale de Boyce-Codd (` a oublier egalement) : les attributs dun identiant compos e ne doivent pas d ependre dun autre attribut de lentit e. ` ce stade, seules les entit A es ont et e normalis ees, il reste les associations. Normalisation des relations 1 (importante) : les attributs des associations doivent d ependre des identiants de toutes les entit es en association. Par exemple, la quantit e command ee d epend ` a la fois du num ero de client et du num ero darticle, par contre la date de commande non. Il faut donc faire une entit e commandes ` a part :

Fig. 9 Normalisation des relations

1. comprendre : normalisation des associations

` 2 MODELE LOGIQUE DE DONNEES (MLD)

1.4

M ethodologie

Face ` a un probl` eme bien formul e (m eme si ca nexiste pas) proc eder ainsi : identier les entit es en pr esence ; lister leurs attributs ; ajouter les identiants ; etablir les relations entre les entit es ; lister leurs attributs ; eliminer les synonymes (plusieurs signiant pour un signi e) et les polys` emes (plusieurs signi e pour un signiant) ; calculer les cardinalit es ; v erier la troisi` eme forme normale et la normalisation des relations ; eectuer les corrections n ecessaires. Il faut garder egalement ` a lesprit que le mod` ele doit etre exhaustif (cest-` a-dire contenir toutes les informations n ecessaires) et eviter toute redondance (le prix unitaire dun article na pas besoin de gurer dans lentit e commandes).

Mod` ele logique de donn ees (MLD)

Maintenant que le MCD est etablit, on peut le traduire en di erents syst` emes logiques, comme les syst` emes par chiers ou les bases de donn ees.

2.1

Les syst` emes logiques

Avant lapparition des syst` emes de gestion de base de donn ees (SGBD ou DBMS pour Data Base Management System en anglais), les donn ees etaient stock ees dans des chiers binaires et g er ees par des programmes ex ecutables (Basic, Cobol ou Dbase par exemple). La maintenance des programmes (en cas de modication de la structure des donn ees par exemple) etait tr` es probl ematique. Voir [1] pour une traduction dun MPD vers un MLD chier. Sont alors apparus les SGBD hi erarchiques dans lesquels les donn ees sont organis ees en arbre (IMSDL1 dIBM par exemple), 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). Voir [2, 3, 1] pour une traduction dun MPD vers un MLD Codasyl (base de donn ees r eseaux). Ces deux types de SGBD sont dit navigationnels car on peut retrouver linformation ` a condition den conna tre le chemin dacc` es. Aujourdhui, ils sont largement remplac es par les SGBD relationnels (SGBDR) avec lesquels linformation peut etre obtenue par une requ ete formul ee dans un langage quasiment naturel. Ce sont les SGBD les plus r epandus (Oracle et DB2 dIBM par exemple). Nous nous contentons donc ici du mod` ele logique de donn ees relationnel (MLDR). Plus r ecemment, sont apparus des SGBD orient es objets qui orent ` a la fois un langage de requ ete et une navigation hypertexte. Un mod` ele logique de donn ees orient e objet permet par exemple de concevoir des classes Java sappuyant sur une base de donn ees relationnelle et permettant le d eveloppement dune application web.

` 2 MODELE LOGIQUE DE DONNEES (MLD)

2.2

Sch ema relationnel

Concentrons-nous sur le MLDR. Lorsque des donn ees ont la m eme structure (comme par exemple, les bordereaux de livraison), 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. Les lignes dune table doivent etre uniques, cela signie quune colonne (au moins) doit servir de cl e primaire . La cl e primaire dune ligne ne doit pas changer au cours du temps, alors que les autres colonnes le peuvent. Par ailleurs, il se peut quune colonne Colonne1 dune table ne doive contenir que des valeurs prises par une colonne Colonne2 dune autre table (par exemple, le num ero du client sur une commande doit correspondre ` a un vrai num ero de client). La Colonne2 doit etre sans doublons (bien souvent il sagit dune cl e primaire) et on dit que la Colonne1 est cl e etrang` ere . Par convention, on souligne les cl es primaires et on fait pr ec eder les cl es etrang` eres dun di` ese # dans la description des colonnes dune table : clients(num ero client, nom client, pr enom, adresse client, ...) commandes(num ero commande, date, #num ero client, ...) Remarques : une m eme table peut avoir plusieurs cl es etrang` eres mais une seule cl e primaire ( eventuellement compos ees de plusieurs colonnes) ; une cl e etrang` ere peut aussi etre primaire ; une cl e etrang` ere peut etre compos ee (cest le cas si la cl e primaire en liaison est compos ee). La section suivante contient des exemples. On peut repr esenter les tables dune 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. 10 Sch ema relationnel

2.3

Traduction

Pour traduire un MCD en troisi` eme forme normale en un MLDR, il sut dappliquer cinq r` egles (` a conna tre par cur). Mais avant, on dit quune association entre deux entit es ( eventuellement r eexive) est de type : 1 : 1 si les deux cardinalit es sont 0,1 ou 1,1 ; 1 : n si une des deux cardinalit e est 0,n ou 1,n ; n : m (plusieurs ` a plusieurs) si les deux cardinalit es sont 0,n ou 1,n.

` 2 MODELE LOGIQUE DE DONNEES (MLD)

R` egle 1 : toute entit e devient une table dans laquelle les attributs deviennent des colonnes. Lidentiant de lentit e constitue alors la cl e primaire de la table. Par exemple, lentit e articles de la gure 9 devient la table : articles(num ero article, nom article, prix unitaire de vente, ...) R` egle 2 : dans le cas de deux entit es reli ees par une association de type 1 : 1, on ajoute aux deux tables une cl e etrang` ere vers la cl e primaire de lautre. Les attributs de lassociation sont alors repartis vers lune des deux tables. Par exemple, lassociation r esider de la gure 8 est traduite par : ^tres humains(num e ero personnel, nom, pr enom, #num ero appartement, date dentr ee, ...) logement(num ero appartement, adresse, #num ero personnel, montant du loyer, ...)

Fig. 11 Traduction dune association de type 1 : 1 Remarque : dautre techniques sont parfois propos ees pour la r` egle 2 (fusionner les tables, utiliser une cl e primaire identique) mais en pratique elles ne sont pas exploitables dans le cas g en eral. R` egle 3 : dans le cas de deux entit es reli ees par une association de type 1 : n, lidentiant de lentit e c ot e 0,n ou 1,n devient une cl e etrang` ere vers la cl e primaire de la table c ot e 0,1 ou 1,1. Les attributs de lassociation glissent vers la table c ot e 0,1 ou 1,1. Par exemple, lassociation concerner (2) de la gure 9 est traduite par : articles(num ero article, nom article, prix unitaire de vente, ...) livraisons(num ero livraison, date, #num ero article, quantit e livr ee)

Fig. 12 Traduction dune association de type 1 : n

` 2 MODELE LOGIQUE DE DONNEES (MLD)

10

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. Les attributs de lassociation deviennent des colonnes de cette table. Par exemple, lassociation concerner (1) de la gure 9 est traduite par : ero article, nom article, prix unitaire de vente, ...) articles(num ero commande, #num ero article, quantit e command ee) lignes de commande(#num ero commande, date, ...) commandes(num

Fig. 13 Traduction dune association de type n : m R` egle 5 : une association entre trois entit es ou plus est traduite par une table suppl ementaire dont la cl e primaire est compos ees dautant de cl es etrang` eres que dentit es. Les attributs de lassociation deviennent des colonnes de cette table. Par exemple, lassociation vols de la gure 7 devient la table : vols(#num ero avion, #num ero pilote, #num ero a eroport, date et heure, dur ee, distance)

Fig. 14 Traduction dune association ternaire

` 3 MODELE PHYSIQUE DE DONNEES (MPD)

11

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, cest faux. Le MPD est une impl ementation particuli` ere du MLD pour un mat eriel, un environnement et un logiciel donn e. Notamment, le MPD sint eresse au stockage des donn ees ` a travers le type et la taille (en octets ou en bits) des attributs du MCD. Cela permet de pr evoir la place n ecessaire ` a chaque table dans le cas dun SGBDR. Le MPD tient compte des limites mat erielles et logicielles an doptimiser lespace consomm e et doptimiser le temps de calcul (qui repr esentent deux optimisations contradictoires). Dans le cas dun SGBDR, le MPD d enit les index et peut etre amen e` a accepter certaines redondances dinformation an dacc el erer les requ etes. Par exemple, la table commandes de la gure 13 peut etre supprim ees et ses colonnes, notamment date, sont ajout ees ` a la table lignes de commandes. On renonce donc ` a la troisi` eme forme normale

Fig. 15 Sacrice de la troisi` eme forme normale puisque la date est r ep et ee autant de fois quil y a de lignes dans la commandes, mais on evite une jointure co uteuse en temps de calcul lors des requ etes. Une application pratique de la s eparation entre le MLDR et le MPD est le portage dune base de donn ees dun SGBD ` a un autre. Par exemple, on peut traduire un MPD Access en un MLDR puis traduire ce MLDR en un MPD Oracle.

Compl ements

Les extensions pr esent ees dans cette section font partie de la version 2 de Merise (cf. [4]). Elles permettent de traiter certaines situations r eelles plus simplement.

4.1

Agr egation

Exemple : dans un entreprise dont les repr esentants vendent des produits dans di erentes r egions, une des r` egles de gestion est quun produit pour une r egion donn ee, ne peut etre vendu que par un seul repr esentant. Si on se contente du sch ema de la gure 16, alors cette r` egle nest pas forc ement respect ee. Il faut utiliser une agr egation qui permet dassocier une entit e` a un couple dentit es en associations (cf. gure 17). Lagr egation constitue alors une entit e dont lidentiant est compos e des identiants de ses propres entit es en association.

4 COMPLEMENTS

12

Fig. 16 Mauvais MCD

Fig. 17 Solution avec agr egation

4 COMPLEMENTS

13

Comme lassociation vendre est de type 1 : n, le sch ema relationnel que lon obtient est alors le suivant : repr esentants(num ero repr esentant, nom repr esentant, ...) r egions(num ero r egion, nom r egion, ...) ero produit, nom produit, ...) produits(num couvrir(#num ero r egion, #num ero produit, #num ero repr esentant, date et heure) Si lassociation vendre etait de type n : m (cf. gure 18), alors le sch ema relationnel ferait intervenir

Fig. 18 Agr egation avec une association de type n : m une table suppl ementaire : repr esentants(num ero repr esentant, nom repr esentant, ...) r egions(num ero r egion, nom r egion, ...) produits(num ero produit, nom produit, ...) couvrir(#num ero r egion, #num ero produit) vendre(#num ero r egion, #num ero produit, #num ero repr esentant, date et heure)

4.2

Identiant relatif

Exemple : une entreprise du b atiment num erote les factures relatives ` a un chantier par le num ero du chantier suivi dun num ero automatique. Les factures du chantier 14 sont 1401, 1402 et 1403 tandis que celles du chantier 15 sont 1501 et 1502. Le num ero de facture est donc relatif au num ero de chantier. On aimerait avoir le sch ema de la gure

4 COMPLEMENTS

14

Fig. 19 Identiant par concat enation 19, mais on ne peut pas utiliser deux fois un m eme attribut dans un MCD. Avec Merise 2, il sut de mettre entre parenth` eses la cardinalit e 1,1 (cf. gure 20) pour indiquer que

Fig. 20 Repr esentation dun identiant relatif lidentiant de lentit e concern ee est relatif ` a lautre entit e en association. Au niveau logique relationnel, cela se traduit par une cl e primaire compos ee notamment dune cl e etrang` ere : chantiers(num ero chantier, adresse, ...) factures(#num ero chantier, num ero facture, date, ...)

4.3

Sous-entit e

Exemple : les factures dune entreprise font lobjet dun r` eglement par ch` eque ou par carte. Cette entreprise souhaite conna tre pour tous les r` eglements, leur date, pour les r` eglements par ch` eque, le nom de la banque et le num ero du ch` eque et pour les r` eglements par carte, le num ero de la carte, le nom de la banque et la date dexpiration. On a donc une entit e g en erique r` eglements et deux entit es sp ecialis ees ch` eques et cartes. Ces deux sous-entit es de lentit e r` eglements ont des attributs propres mais pas didentiants propres. Sur le sch ema entit e-association, on repr esente le lien qui unie une sous-entit e` a son entit e g en erique par une ` eche (cf. gure 21 ).

4 COMPLEMENTS

15

Fig. 21 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, date, nom banque) ch` eques(#num ero r` eglement, num ero ch` eque) cartes(#num ero r` eglement, num ero carte, date expiration) Remarque : au niveau logique objet, on retrouve la notion dh eritage.

4.4

Sous-association

Exemple : une entreprise artisanale vend non seulement des produits ` a prix unitaire xe, mais aussi des produits sur mesure dont le prix unitaire est calcul e` a partir de la dur ee de confection et dun taux horaire. Dans ce cas, non seulement lentit e produits est sp ecialis ee en produits standards et produits personnalis es, mais en plus, lassociation concerner entre les entit es commandes et produits est sp ecialis ee selon quil sagit dun produit standard ou personnalis e (cf. gure 22 ). On a alors les sous-associations concerner standard et concerner personnalis e dont le lien avec lassociation g en erique concerner est repr esent e par une ` eche. Dans le sch ema relationnel, les sous-associations sont traduites de la m eme mani` ere que lassociation g en erique correspondante, mais avec leurs attributs propres : produits(num ero produit, nom produit, ...) produits standards(#num ero produit, prix unitaire) produits personnalis es(#num ero produit, taux horaire) commandes(num ero commande, date, ...) concerner(#num ero commande, #num ero produit, quantit e) concerner standard(#num ero commande, #num ero produit) concerner personnalis e(#num ero commande, #num ero produit, dur ee)

CONCLUSION

16

Fig. 22 Repr esentation des sous-associations

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 quelles associations de type n : m, non binaires ou r eexives sont en pr esence (cest important) ; le MLD peut etre obtenu automatiquement par des outils de g enie logiciel ; le MCD peut etre traduit en di erents MLD coh erents (notamment on peut traduire un MCD en un MLDR puis en une base de donn ees Access tandis quen parall` ele le MCD est traduit en un ensemble de classes Java (MPD orient e objet) an de d evelopper une application web sur cette base Access). Cependant, la m ethodologie Merise est typiquement fran caise. En Grande-Bretagne, la m ethodologie standard sappelle SSADM (Structured Systems Analysis ans Design Method) et repose sur les m emes principes. Les nord-am ericains utilisent ce quon appelle des diagrammes de ux dont les principes sont repris par la version 2 de Merise. Aujourdhui, ce sont les m ethodologies objets et leur unication UML (Unied Modeling Language, autrement dit langage uni e de mod elisation objet) qui tendent ` a remplacer Merise et ses extensions objets. Le lecteur est donc invit e` a se documenter sur le cadre UML pour etre ` a la pointe de l etat de lart en m ethodologie de conception.

TABLE DES FIGURES

17

Table des gures


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 Entit es . . . . . . . . . . . . . . . . . . . . . . Associations . . . . . . . . . . . . . . . . . . . Attributs . . . . . . . . . . . . . . . . . . . . Identiants . . . . . . . . . . . . . . . . . . . Cardinalit es . . . . . . . . . . . . . . . . . . . Association r eexive . . . . . . . . . . . . . . Association ternaire . . . . . . . . . . . . . . Associations plurielles . . . . . . . . . . . . . Normalisation des relations . . . . . . . . . . Sch ema relationnel . . . . . . . . . . . . . . . Traduction dune association de type 1 : 1 . . Traduction dune association de type 1 : n . . Traduction dune association de type n : m . Traduction dune association ternaire . . . . . Sacrice de la troisi` eme forme normale . . . . Mauvais MCD . . . . . . . . . . . . . . . . . Solution avec agr egation . . . . . . . . . . . . Agr egation avec une association de type n : m Identiant par concat enation . . . . . . . . . Repr esentation dun identiant relatif . . . . Repr esentation des sous-entit es . . . . . . . . Repr esentation des sous-associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 3 3 4 4 5 5 6 8 9 9 10 10 11 12 12 13 14 14 15 16

R ef erences
[1] Gabay, J. Apprendre et pratiquer Merise. Masson, 1989. Ce livre tr` es synth etique permet de sexercer sur la m ethode. [2] Matheron, J.-P. Comprendre Merise. Eyrolles, 1994. Cet ouvrage tr` es accessible permet vraiment de comprendre la m ethode. [3] Nanci, D., Espinasse, B., Cohen, B. et Heckenroth, H. Ing enierie des syst` emes dinformation avec Merise. Sybex, 1992. Cet ouvrage complet d etaille la m ethode dans son ensemble. [4] Panet, G., Letouche, R. et Tardieu, H. Merise/2 : Mod` eles et techniques Merise avanc es. Edition dorganisation, 1994. Ce livre d ecrit la version 2 de la m ethode. [5] Tardieu, H., Rochfeld, A. et Coletti, R. La m ethode Merise. Principes et outils. Edition dorganisation, 1986. Il sagit-l` a du livre de r ef erence par les auteurs de la m ethode.

INDEX

18

Index

A
agr egation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 association. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 r eexive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 ternaire. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 attribut. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

P
polys` eme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 portage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 premi` ere forme normale . . . . . . . . . . . . . . . . . . . . . . . 6

R
r eseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 redondance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 requ ete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

C
cardinalit e....................................3 cl e etrang` ere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 primaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Codasyl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

S
SGBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 SGBDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 sous-association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 sous-entit e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 sp ecialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14, 15 SSADM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 synonyme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

D
DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 deuxi` eme forme normale . . . . . . . . . . . . . . . . . . . . . . 6 diagramme de ux . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

E
entit e.........................................2 exhaustif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

T
table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 de jointure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 troisi` eme forme normale . . . . . . . . . . . . . . . . . . . 6, 11 type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

F
chier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 forme normale de Boyce-Codd . . . . . . . . . . . . . . . . 6

G
g en ericit e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14, 15

U
UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

H
hi erarchique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

I
identiant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

M
Merise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2, 16 MLDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

N
navigationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 normalisation des relations . . . . . . . . . . . . . . . . . . . . 6

O
optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 orient e objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7