Conception dune base de donnes

Peter-christman

Rsum Ce support de cours regroupe quelques notions concernant le modle entit-association, le schma relationnel et la traduction de lun vers lautre.

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

Table des matires

Introduction 1 Modle conceptuel de donnes (MCD) 1.1 Schma entit-association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 1.3 1.4 Cas particuliers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rgles de normalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . M t h od olo gie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 2 2 4 6 7 7 7 8 8 11 11 11 13 14 15 16 17 17 18

2 Modle logique de donnes (MLD) 2.1 Les systmes logiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Schma relationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Traduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Modle phys ique de donnes (MPD) 4 Complments 4.1 Agrgation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 I d en tif ian t rela tif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 4.4 S o u s -e n t i t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sous-association

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Conclusion Table des figures Rfrences Index

kounkechrist@gmail.com 1

INTRODUCTION

Introduction
Les techniques prsentes ici font partie de la mthodologie Merise labore en France en 1978 (cf. [5]) qui permet notamment de concevoir un systme dinformation dune faon standardise et mthodique. Le but de ce support de cours est dintroduire le schma entit-association, le schma relationnel et dexpliquer la traduction entre les deux. Ne sont pas abords ici : les dpendances fonctionnelles, les contraintes, les traitements, les langages relationnels, la gestion de projet. Pour tout cela, le lecteur est dirig vers [ 2 , 3 ] . La modlisation objet ne fait pas non plus partie des outils exposs dans ce document.

1 Modle conceptuel de donnes (MCD)

Avant de rflchir au schma relationnel dune application, il est bon de modliser la problmatique traiter dun point de vue conceptuel et indpendamment du logiciel utilis. Cest le but de cette partie.

1.1 Schma entit-association

Une e n t i t est une population dindividus nayant que des caractristiques comparables. Par exemple, dans une entreprise qui achte et vend des produits, on a lentit clients, lentit articles et lentit fournisseurs.

FIG. 1 Entits Une a s s o c i a t i o n est un lien entre plusieurs entits. Dans notre exemple, lassociation acheter fait le lien entre les entits articles et clients, tandis que lassociation livrer fait le lien entre les entits articles et fournisseurs.

FIG. 2 A s s o c i a t i o n s

1 MODLE CONCEPTUEL DE DONNES (MCD)

Un at t ri b u t est une proprit dune entit ou dune association. Toujours dans notre exemple, le prix unitaire est un attribut de lentit articles, le nom du client est un attribut de lentit clients. La quantit commande est un attribut de lassociation
acheter, la date de livraison est un attribut de lassociation livrer.

FIG. 3 Attri bu ts Chaque individu dune entit doit tre identifiable de manire unique. Cest pourquoi les entits doivent possder un attribut sans doublon, li d e n t i f i an t. Le numro de client est lidentifiant de lentit clients (on souligne cet attribut sur le schma).

FIG. 4 Identifiants Remarques : un attribut ne doit pas figurer dans deux entits ou associations diffrentes (donc il faut spcialiser lattribut nom en nom du client, nom du produit et nom du fournisseur) ; une entit possde au moins un attribut (son identifiant) ; une association peut ne pas possder dattribut. Conseils : viter les identifiants composes de plusieurs attributs (comme par exemple un identifiant form par les attributs nom du client et prnom) ; il faut un identifiant totalement indpendant des autres attributs (viter par exemple dajouter un identifiant NomPrnom qui serait la concatenation des attributs nom du client et prnom) ; prfrer un identifiant court pour rendre la recherche la plus rapide possible (viter par exemple les chanes de caractres comme le numro de scurit sociale ou la plaque dimmatriculation) ; conclusion : dans le modle physique de donnes (cf. 3 ) , on utilise une cl numrique (un entier) incrmente automatiquement.

La c a r d i n a l i t dun lien entre une entit et une association est le minimum et le maximum de fois quun individu de lentit peut tre concern par lassociation.

1 MODLE CONCEPTUEL DE DONNES (MCD)

Un client a au moins achet un article et peut acheter n articles ( n tant indtermin), tandis quun article peut avoir t achet entre 0 et n fois (mme si ce nest pas le mme n ) et nest livr que par 1 fournisseur. On obtient alors le schma entit-association complet suivant :

FIG. 5 Cardinalites Remarque : si une cardinalit est connue et vaut 2, 3, etc. on considre quand mme quelle est indtermine n , de telle sorte quon ne puisse avoir que des cardinalits 0, 1 ou n .

1.2 Cas particuliers

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

FIG. 6 Association relexive directeur gnral) et un employ peut diriger plusieurs employs.

1 MODLE CONCEPTUEL DE DONNES (MCD)

Exemple dassociation entre trois entits (association t e r n a i r e ) : dans ce cas, un avion, un pilote ou

FIG. 7 A s s oc i at io n t e rna i r e un aroport peuvent tre utiliss 0 ou plusieurs fois par lensemble des vols (do les cardinalits). Exemple de plusieurs associations entre deux mmes entits : dans ce cas, un tre humain peut tre

FIG. 8 A s s oc i at io n s plur i e ll e s propritaire, locataire et/ou charg de lentretien. On suppose quun tre humain ne rside que dans un logement au maximum, quun logement nest occup que par une personne au maximum et quun logement est entretenu par une et une seule personne (il sagit dun exemple).

1 MODLE CONCEPTUEL DE DONNES (MCD)

1.3 Rgles de normalisation

Premire forme normale : chaque entit doit possder un identifiant qui caractrise ses individus de manire unique. Deuxime forme normale : lidentifiant peut tre compose de plusieurs attributs mais les autres attributs de lentit doivent tre dpendant de lidentifiant en entier (et non pas une partie de cet identifiant). Ces deux premires formes normales peuvent tre oublie si on suit le conseil de nutiliser que des identifiants non composs de type numro. Troisime f orme normale (importante) : les attributs dune entit doivent dpendre d i r e c t e m e n t de son identifiant. Par exemple, la date de fte dun client ne dpend pas de son identifiant numro de client mais plutt de son prnom . Il faut donc faire une entit calendrier part. Forme normale de Boyce-Codd ( oublier galement) : les attributs dun identifiant compos ne doivent pas dpendre dun autre attribut de lentit. ce stade, seules les entits ont t normalises, il reste les associations. Normalisation des relations (importante) : les attributs des associations doivent dpendre des identifiants de t o ut es les entits en association.
'

Par exemple, la quantit commande dpend la fois du numro de client et du numro darticle , par contre la date de commande non. Il faut donc faire une entit commandes part:

FIG. 9 Normalisation des relations

1. comprendre : normalisation des associations

2 MODLE LOGIQUE DE DONNES (MLD)

1.4 Mthodologie
Face un problme bien formul (mme si a nexiste pas) procder ainsi : identifier les entits en prsence; lister leurs attributs; ajouter les identifiants; tablir les relations entre les entits; lister leurs attributs; liminer les synonymes (plusieurs signifiant pour un signifi) et les polysmes (plusieurs signifi pour un signifiant) ; calculer les cardinalits ;

vrifier la troisime forme normale et la normalisation des relations; effectuer les corrections ncessaires. Il faut garder galement lesprit que le modle doit tre exhaustif (cest--dire contenir toutes les informations ncessaires) et viter toute redondance (le prix unitaire dun article na pas besoin de figurer dans lentit commandes ).

2 Modle logique de donnes (MLD)

Maintenant que le MCD est tablit, on peut le traduire en diffrents systmes logiques, comme les systmes par fichiers ou les bases de donnes.

2.1 Les systmes logiques

Avant lapparition des systmes de gestion de base de donnes (SGBD ou DBMS pour Data Base Management System en anglais), les donnes taient stockes dans des fichiers binaires et gres par des programmes excutables (Basic, Cobol ou Dbase par exemple). La maintenance des programmes (en cas de modification de la structure des donnes par exemple) tait trs problmatique. Voir [1] pour une traduction dun MPD vers un MLD fichier. Sont alors apparus les SGBD hirarchiques dans lesquels les donnes sont organises en arbre (IMSDL1 dIBM par exemple), puis les SGBD rseaux dans lesquels les donnes sont organises selon un graphe plus gnral (IDS2 de Bull par exemple). Voir [ 2 , 3 , 1 ] pour une traduction dun MPD vers un MLD Codasyl (base de donnes rseaux). Ces deux types de SGBD sont dit navigationnels car on peut retrouver linformation condition den connatre le chemin daccs. Aujourdhui, ils sont largement remplacs par les SGBD relationnels (SGBDR) avec lesquels linformation peut tre obtenue par une requte formule dans un langage quasiment naturel. Ce sont les SGBD les plus rpandus (Oracle et DB2 dIBM par exemple). Nous nous contentons donc ici du modle logique de donnes relationnel (MLDR). Plus rcemment, sont apparus des SGBD orients objets qui offrent la fois un langage de requte et une navigation hypertexte. Un modle logique de donnes orient objet permet par exemple de concevoir des classes Java sappuyant sur une base de donnes relationnelle et permettant le dveloppement dune application web.

2 MODLE LOGIQUE DE DONNES (MLD)

2.2 Schma relationnel

Concentrons-nous sur le MLDR. Lorsque des donnes ont la mme structure (comme par exemple, les bordereaux de livraison), on peut les organiser en t a b l e dans laquelle les colonnes dcrivent les champs en commun et les lignes contiennent les valeurs de ces champs pour chaque enregistrement.

Leslignesdunetabledoiventtreuniques,celasignifiequunecolonne(aumoins)doitservirdecl primaire.Laclprimairedunelignenedoitpaschangeraucoursdutemps,alorsquelesautres colonnesle 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 numro du client sur une commande doit correspondre un vrai numro de client). La Colonne2 doit tre sans doublons (bien souvent il sagit dune cl primaire) et on dit que la Colonne1 est c l t r a n g r e . Par convention, on souligne les cls primaires et on fait prcder les cls trangres dun dise # dans la description des colonnes dune table :
clients(numro client, nom client, prnom, adresse client, ...) commandes(numro commande, date, #numro client, ...)

Remarques : une mme table peut avoir plusieurs cls trangres mais une seule cl primaire (ventuellement composes de plusieurs colonnes) ; une cl trangre peut aussi tre primaire; une cl trangre peut tre compose (cest le cas si la cl primaire en liaison est compose). La section suivante contient des exemples. On peut reprsenter les tables dune base de donnes relationnelle par un schma relationnel dans lequel les tables sont appeles relations et les liens entre les cls trangres et leur cl primaire est symbolis par un connecteur :

FIG. 10 S c h m a r e l a tion n el

2.3 Traduction
PourtraduireunMCDentroisimeformenormaleenunMLDR,ilsuffitdappliquercinqrgles(connaitreparcur).Maisavant,onditquuneassociationentredeuxentits(ventuellement rflexive) est de type : 1 : 1 si les deux cardinalits sont 0,1 ou 1,1; 1 : n si une des deux cardinalit est 0,n ou 1,n; n : m (plusieurs plusieurs) si les deux cardinalits sont 0,n ou 1,n.

2 MODLE LOGIQUE DE DONNES (MLD)

Rgle 1 : toute entit devient une table dans laquelle les attributs deviennent des colonnes. Lidentifiant de lentit constitue alors la cl primaire de la table.
Par exemple, lentit articles de la figure 9 devient la table :
articles(numro article, nom article, prix unitaire de vente, ...)

Rgle 2 : dans le cas de deux entits relies par une association de type 1 : 1, on ajoute aux deux tables une cl trangre vers la cl primaire de lautre. Les attributs de lassociation sont alors repartis vers lune des deux tables.
Par exemple, lassociation rsider de la figure 8 est traduite par :
tres humains(numro personnel, nom, prnom, #numro appartement, date dentre, ...) logement(numro appartement, adresse, #numro personnel, montant du loyer, ...)

FIG. 11 Traduction dune association de type 1 : 1 Remarque : dautre techniques sont parfois proposes pour la rgle 2 (fusionner les tables, utiliser une cl primaire identique) mais en pratique elles ne sont pas exploitables dans le cas gnral.

Rgle 3 : dans le cas de deux entits relies par une association de type 1 : n, lidentifiant de lentit ct 0,n ou 1,n devient une cl trangre vers la cl primaire de la table ct 0,1 ou 1,1. Les attributs de lassociation glissent vers la table ct 0,1 ou 1,1.
Par exemple, lassociation concerner (2) de la figure 9 est traduite par :
articles(numro article, nom article, prix unitaire de vente, ...) livraisons(numro livraison, date, #numro article, quantit livre)

FIG. 12 Traduction dune association de type 1 : n

2 MODLE LOGIQUE DE DONNES (MLD)

10

Rgle 4 : une association entre deux entits et de type n : m est traduite par une table supplmentaire (parfois appele table de jointure) dont la cl primaire est compose de deux cls trangres vers les cls primaires des deux tables en association. Les attributs de lassociation deviennent des colonnes de cette table.
Par exemple, lassociation concerner (1) de la figure 9 est traduite par :
articles(numro article, nom article, prix unitaire de vente, ...) lignes de commande(#numro commande, #numro article, quantit commande) commandes(numro commande, date, ...)

FIG. 13 Traduction dune association de type n : m

Rgle 5 : une association entre trois entits ou plus est traduite par une table supplmentaire dont la cl primaire est composes dautant de cls trangres que dentits. Les attributs de lassociation deviennent des colonnes de cette table.
Par exemple, lassociation vols de la figure 7 devient la table :
vols( #numro avion, #numro pilote, #numro aroport, date et heure, dure, distance)

FIG. 14 Traduction dune association ternaire

3 MODLE PHYSIQUE DE DONNES (MPD)

11

3 Modle physique de donnes (MPD)

Bien que certains outils (PowerAMC notamment) considre que le MPD et le MLD reprsentent la mme chose, cest faux. Le MPD est une implmentation particulire du MLD pour un matriel, un environnement et un logiciel donn. Notamment, le MPD sintresse au stockage des donnes travers le type et la taille (en octets ou en bits) des attributs du MCD. Cela permet de prvoir la place ncessaire chaque table dans le cas dun SGBDR. Le MPD tient compte des limites matrielles et logicielles afin doptimiser lespace consomm et doptimiser le temps de calcul (qui reprsentent deux optimisations contradictoires). Dans le cas dun SGBDR, le MPD dfinit les index et peut tre amen accepter certaines redondances dinformation afin dacclrer les requtes. Par exemple, la table commandes de la figure 1 3 peut tre supprimes et ses colonnes, notamment date, sont ajoutes la table lignes de commandes. On renonce donc la troisime forme normale

FIG. 15 { Sacrifice de la troisime forme normale

puisque la date est rpte autant de fois quil y a de lignes dans la commandes, mais on vite une jointure coteuse en temps de calcul lors des requtes. Une application pratique de la sparation entre le MLDR et le MPD est le portage dune base de donnes dun SGBD un autre. Par exemple, on peut traduire un MPD Access en un MLDR puis traduire ce MLDR en un MPD Oracle.

4 Complments
Les extensions prsentes dans cette section font partie de la version 2 de Merise (cf. [4]). Elles permettent de traiter certaines situations relles plus simplement.

4.1 Agrgation
Exemple : dans un entreprise dont les reprsentants vendent des produits dans diffrentes rgions, une des rgles de gestion est quun produit pour une rgion donne, ne peut tre vendu que par un seul reprsentant. Si on se contente du schma de la figure 1 6, alors cette rgle nest pas forcment respecte. Il faut utiliser une agrgation qui permet dassocier une entit un couple dentits en associations (cf. figure 17) . Lagrgation constitue alors une entit dont lidentifiant est compos des identifiants de ses propres entits en association.

4 COMPLMENTS

1 2

FIG. 16 M a u v a i s M C D

FIG. 17 Solution avec agrgation

4 COMPLMENTS

13

Comme lassociation vendre est de type 1 : n, le schma relationnel que lon obtient est alors le suivant :
reprsentants(numro reprsentant, nom reprsentant, ...) rgions(numro rgion, nom rgion, ...) produits(numro produit, nom produit, ...) couvrir(#numro rgion, #numro produit, #numro reprsentant, date et heure)

Si lassociation vendre tait de type n : m (cf. figure 1 8 ) , alors le schma relationnel ferait intervenir

FIG. 18 Agrgation avec une association de type n : m une table supplmentaire :

reprsentants(numro reprsentant, nom reprsentant, ...) rgions(numro rgion, nom rgion, ...) produits(numro produit, nom produit, ...) couvrir(#numro rgion, #numro produit) vendre(#numro rgion, #numro produit, #numro reprsentant, date et heure)

4.2 Identifiant relatif

Exemple : une entreprise du btiment numrote les factures relatives un chantier par le numro du chantier suivi dun numro automatique. Les factures du chantier 14 sont 1401, 1402 et 1403 tandis que celles du chantier 15 sont 1501 et 1502.

Le numro de facture est donc r e l a t i f au numro de chantier. On aimerait avoir le schma de la figure

4 COMPLMENTS

14

FIG. 19 Identifiant par concatnation

1 9 , mais on ne peut pas utiliser deux fois un mme attribut dans un MCD.
Avec Merise 2, il suffit de mettre entre parenthses la cardinalit 1,1 (cf. figure 2 0) pour indiquer que

FIG. 20 Reprsentation dun identifiant relatif

lidentifiant de lentit concerne est relatif lautre entit en association.

Au niveau logique relationnel, cela se traduit par une cl primaire compose notamment dune cl trangre :
chantiers(numro chantier, adresse, ...)

factures( #numro chantier, numro facture, date, ...)

4 .3 S o u s -e n ti t
Exemple : les factures dune entreprise font lobjet dun rglement par chque ou par carte. Cette entreprise souhaite connatre pour tous les rglements, leur date, pour les rglements par chque, le nom de la banque et le numro du chque et pour les rglements par carte, le numro de la carte, le nom de la banque et la date dexpiration. On a donc une entit gnrique rglements et deux entits spcialises chques et cartes. Ces deux sous-entits de lentit rglements ont des attributs propres mais pas didentifiants propres. Sur le schma entit-association, on reprsente le lien qui unie une sous-entit son entit gnrique par une flche (cf. figure 21 ).

4 COMPLMENTS

15

FIG. 21 Reprsentation des sous-entits La traduction des sous-entits au niveau logique relationnel fait intervenir une cl primaire commune qui est aussi trangre :
rglements(numro rglement, date, nom banque)

chques(#numro rglement, numro chque) cartes( #numro rglement, numro carte, date expiration)

Remarque : au niveau logique objet, on retrouve la notion dhritage.

4.4 Sous -association

Exemple: une entreprise artisanale vend non seulement des produits prix unitaire fixe, mais aussi des produits sur mesure dont le prix unitaire est calcul partir de la dure de confection et dun taux horaire. Dans ce cas, non seulement lentit produits est spcialise en produits standards et produits personnaliss, mais en plus, lassociation concerner entre les entits commandes et produits est spcialise selon quil sagit dun produit standard ou personnalis (cf. figure 2 2 ). On a alors les sous-associations concerner standard et concerner personnalis dont le lien avec lassociation gnrique concerner est reprsent par une flche. Dans le schma relationnel, les sous-associations sont traduites de la mme manire que lassociation gnrique correspondante, mais avec leurs attributs propres :
produits(numro produit, nom produit, ...)

produits standards(#numro produit, prix unitaire) produits personnaliss(#numro produit, taux horaire)
commandes(numro commande, date, ...)

concerner(#numro commande, #numro produit, quantit) concerner standard(#numro commande, #numro produit) concerner personnalis(#numro commande, #numro produit, dure)

CONCLUSION

16

FIG. 22 Reprsentation des sous-associations

Conclusion
I n t r ts d e l a dc o mposi tio n MC D / MLD / MP D : le MCD permet dviter certaines erreurs de conception (en contradiction avec les rgles de normalisation) ; le MCD permet de voir quelles associations de type n : m, non binaires ou rflexives sont en prsence (cest important) ; le MLD peut tre obtenu automatiquement par des outils de gnie logiciel; le MCD peut tre traduit en diff rents MLD cohrents (notamment on peut traduire un MCD en un MLDR puis en une base de donnes Access tandis quen parallle le MCD est traduit en un ensemble de classes Java (MPD orient objet) afin de dvelopper une application web sur cette base Access). Cependant, la mthodologie Merise est typiquement franaise. En Grande-Bretagne, la mthodologie standard sappelle SSADM (Structured Systems Analysis ans Design Method) et repose sur les mmes principes. Les nord-amricains utilisent ce quon appelle des diagrammes de flux dont les principes sont repris par la version 2 de Merise. Aujourdhui, ce sont les mthodologies objets et leur unification UML (Unified Modeling Language, autrement dit langage unifi de modlisation objet) qui tendent remplacer Merise et ses extensions objets. Le lecteur est donc invit se documenter sur le cadre UML pour tre la pointe de ltat de lart en mthodologie de conception.

Rfrences
[ 1 ] G A B A Y , J . Apprendre et pratiquer Merise . M a s s o n , 1 9 8 9 .

Ce livre trs synthtique permet de sexercer sur la mthode.

[ 2 ] M A T H E R O N , J . - P . Co mp re nd re Me ri se . E y r o l l e s , 1 9 9 4 . Cet

ouvrage trs accessible permet vraiment de comprendre la mthode.

[ 3 ] NANCI, D., ESPINASSE, B., COHEN, B. et HECKENROTH, H. Ingnierie des systmes dinformation avec Merise . Sybex, 1992.

Cet ouvrage complet dtaille la mthode dans son ensemble.

[ 4 ] PANET, G., LETOUCHE, R. et TARDIEU, H. Merise/2 : Modles et techniques Merise avancs. dition dorganisation, 1994.

Ce livre dcrit la version 2 de la mthode.

[ 5 ] TARDIEU, H., ROCHFELD, A. et COLETTI, R. La mthode Merise. Principes et outils. dition dorganisation, 1986.

Il sagit-l du livre de r~efrence par les auteurs de la mthode.