Conception d'une base de donnes

Date de publication : 17/10/2005 , Date de mise jour : 12/09/2009

Par Cyril Gruau (Home)

Ce support de cours regroupe quelques notions concernant la modlisation conceptuelle de

systme d'information par schma entits-associations (via l'tude des dpendances
fonctionnelles), la traduction en schma relationnel et la dmarche inverse (rtro-conception).
Il prsente galement les extensions majeures du modle conceptuel de donnes.
Complments apports l'dition de novembre 2003 :

une rcriture complte des rgles de normalisation

un nouveau paragraphe sur les dpendances fonctionnelles

une rcriture complte de la section sur les agrgations

idem pour les identifiants relatif

et l'hritage

auxquels s'ajoutent de nouveaux exemples et donc de nombreuses figures illustratives

Remerciements
L'auteur tient exprimer toute sa gratitude envers Frdric Brouard pour son travail de
correction sur ce document, ses judicieux conseils et son soutien en toutes circonstances.

Version PDF (Miroir) Version hors-ligne (Miroir)

I. Introduction
II. Modle conceptuel de donnes (MCD)
II-A. Schma entits-associations
II-A-1. Entits et associations
II-A-2. Attributs et identifiants
II-A-3. Cardinalits
II-A-4. Associations plurielles
II-A-5. Association rflexive
II-A-6. Associations non binaires
II-B. Rgles de normalisation
II-B-1. Les bonnes pratiques dans un schma entits-associations
II-B-2. Les formes normales
II-C. Dpendances fonctionnelles
II-C-1. Dfinitions et proprits
II-C-2. Graphe de couverture minimale
II-C-3. Traduction vers un schma entits-associations
II-C-4. Gestion des dates et du caractre historique
II-C-5. Dpendances plurielles et rflexives
II-C-6. Associations sans attributs
II-D. Mthodologie de base
III. Modle logique de donnes (MLD)
III-A. Systmes logiques
III-B. Modle logique relationnel
III-B-1. Tables, lignes et colonnes
III-B-2. Cls primaires et cls trangres
III-B-3. Schma relationnel
III-C. Traduction d'un MCD en un MLDR
IV. Modle physique de donnes (MPD)
IV-A. Distinction entre MLD et MPD
IV-B. Optimisations
V. Rtro-conception
V-A. Traduction inverse
V-B. Cas particuliers
VI. Complments
VI-A. Agrgation
VI-A-1. Association de type 1 : n
VI-A-2. Association de type n : m
VI-A-3. Tables de codification ou tables de rfrence
VI-B. Identifiant relatif ou lien identifiant
VI-B-1. Rsolution d'un problme sur le schma relationnel
VI-B-2. Modle conceptuel correspondant
VI-B-3. Discussion autour de la numrotation des exemplaires
VI-C. Hritage
VI-C-1. Sous-entit
VI-C-2. Utilisation de l'hritage pour sparer les informations complmentaires
VI-C-3. Spcialisation des associations
VII. Conclusion
VIII. Rfrences

I. Introduction
Quand nous construisons directement les tables d'une base de donnes dans un logiciel de
gestion des bases de donnes (Oracle, SQL Server, DB2, Access, MySQL, PostGre, ...), nous
sommes exposs deux types de problme :

nous ne savons pas toujours dans quelle table placer certaines colonnes (par exemple,
l'adresse de livraison se met dans la table des clients ou dans la table des
commandes ?) ;
 nous avons du mal prvoir les tables de jonction intermdiaires, par exemple, la table
des interprtations qui est indispensable entre les tables des films et la table des
acteurs).

Il est donc ncessaire de recourir une tape prliminaire de conception.

Les techniques prsentes ici font partie de la mthodologie Merise (Mthode d'tude et de
Ralisation Informatique pour les Systmes d'Entreprise) labore en France en 1978 [Tardieu
et al.], qui permet notamment de concevoir un systme d'information d'une faon standardise
et mthodique.

Le but de ce support de cours est d'introduire le schma entits-associations section Modle

conceptuel de donnes (MCD) ), le schma relationnel (sections Modle logique de
donnes (MLD) et Modle physique de donnes (MPD) ) et d'expliquer la traduction
entre les deux (sections Traduction d'un MCD en un MLDR et Rtro-conception ). La
construction du schma entits-associations peut se faire en tudiant les dpendances
fonctionnelles (section Dpendances fonctionnelles ) et en tenant compte d'un certain
nombre d'extensions conceptuelles incontournables (section Complments ).

Ne sont malheureusement pas abords ici : les contraintes, les traitements, le langage
relationnel et la gestion de projet. Pour toutes ces notions importantes, car lies la
conception de systmes d'information, le lecteur est dirig vers [Akoka et Comyn-Wattiau],
[Matheron] et [Nanci et al.]. La modlisation objet ne fait pas non plus partie des outils
exposs dans ce document.

II. Modle conceptuel de donnes (MCD)

Avant de rflchir au schma relationnel d'une application, il est bon de modliser la
problmatique traiter d'un point de vue conceptuel et indpendamment du logiciel utilis.

II-A. Schma entits-associations

La modlisation conceptuelle que nous proposons dans ce document pour un univers dont on
veut stocker les donnes, conduit l'laboration d'un type de schma trs rpandu, le schma
entits-associations.

II-A-1. Entits et associations

Une entit est une population d'individus homognes. Par exemple, les produits ou les articles
vendus par une entreprise peuvent tre regroups dans une mme entit articles (figure 1), car
d'un article l'autre, les informations ne changent pas de nature ( chaque fois, il s'agit de la
dsignation, du prix unitaire, etc.).

Figure 1 - Entits
Par contre, les articles et les clients ne peuvent pas tre regroups : leurs informations ne sont
pas homognes (un article ne possde pas d'adresse et un client ne possde pas de prix
unitaire). Il faut donc leur rserver deux entits distinctes : l'entit articles et l'entit clients.

Une association est une liaison qui a une signification prcise entre plusieurs entits. Dans
notre exemple, l'association commander est une liaison vidente entre les entits articles et
clients, tandis que l'association livrer tablit le lien smantique entre les entits articles et
fournisseurs.

Figure 2 - Associations
Remarquons que dans ce schma, les entits clients et fournisseurs ne sont pas lies
directement, mais indirectement, via l'entit articles, ce qui est assez naturel.

II-A-2. Attributs et identifiants

Un attribut est une proprit d'une entit ou d'une association.

Toujours dans notre exemple (figure 3), le prix unitaire est un attribut de l'entit articles, le
nom de famille est un attribut de l'entit clients, la quantit commande est un attribut de
l'association commander et la date de livraison est un attribut de l'association livrer.

Figure 3 - Attributs
Une entit et ses attributs ne doivent traiter que d'un seul sujet afin d'assurer une certaine
cohrence au modle. Dans notre exemple, il est donc prfrable de ne pas mettre les
informations relatives aux fournisseurs dans l'entit des articles mais plutt dans une entit
fournisseurs spares (et lie l'entit articles via l'association livrer).

Ensuite, chaque individu d'une entit doit tre identifiable de manire unique. C'est pourquoi
toutes les entits doivent possder un attribut sans doublon (c'est--dire ne prenant pas deux
fois la mme valeur). Il s'agit de l'identifiant que l'on souligne sur le schma, par convention.
Le numro de client constitue un identifiant classique pour l'entit clients (figure 4).

Figure 4 - Identifiants
Remarques :

une entit possde au moins un attribut (son identifiant) ;

au contraire, une association peut tre dpourvue d'attribut.

II-A-3. Cardinalits

La cardinalit d'un lien entre une entit et une association prcise le minimum et le maximum
de fois

qu'un individu de l'entit peut tre concern par l'association.

Exemple : un client a au moins command un article et peut commander n articles (n tant

indtermin), tandis qu'un article peut avoir t command entre 0 et n fois (mme si ce n'est
pas le mme n que prcdemment). On obtient alors le schma entits-associations complet
(figure 5).

Figure 5 - Cardinalits
Une cardinalit minimale de 1 doit se justifier par le fait que les individus de l'entit en
question ont besoin de l'association pour exister (un client n'existe pas avant d'avoir
command quoique ce soit, donc la cardinalit minimale de l'entit clients dans l'association
commander est 1). Dans tous les autres cas, la cardinalit minimale vaut 0 (c'est le cas pour
une liste prtablie d'articles par exemple).
Ceci dit, la discussion autour d'une cardinalit minimale 0 ou 1 n'est vraiment intressante que
lorsque la cardinalit maximale est 1. Nous verrons en effet lors de la traduction vers un
schma relationnel (section Traduction d'un MCD en un MLDR ), que lorsque la
cardinalit maximale est n, nous ne pouvons pas faire la diffrence entre une cardinalit
minimale de 0 et une cardinalit minimale de 1.

Notons que sur notre exemple, un article peut tre command par plusieurs clients. Cela
provient du fait que tous les crayons rouges ne sont pas numrots individuellement, mais
portent un numro d'article collectif. En toute rigueur, notre entit articles aurait du s'appeler
types d'article. Ainsi, un crayon rouge peut tre command par plusieurs clients, ce n'est
simplement pas le mme crayon chaque fois. Il s'agit d'un choix de modlisation, le lecteur
peut trs lgitimement faire le choix inverse qui consiste numroter individuellement chaque
crayon rouge.

La seule difficult pour tablir correctement les cardinalits est de se poser les questions dans
le bon sens. Autour de l'association commander, par exemple :

ct clients, la question est un client peut commander combien d'articles ? et la

rponse est entre 1 et plusieurs ;

ct articles, la question est un article peut tre command par combien de client ?
et cette fois-ci, la rponse est entre 0 et plusieurs .

II-A-4. Associations plurielles

Deux mmes entits peuvent tre plusieurs fois en association (c'est le cas sur la figure 6).

Figure 6 - Associations plurielles

Dans cet exemple issu d'une agence immobilire, une personne peut tre propritaire, rsider
principalement ou rsider secondairement dans un logement gr par l'agence. Les logements
qui ne sont pas grs par l'agence ne figurent pas dans l'entit des logements, ce qui explique
certaines cardinalits 0 du schma. Nous supposons galement qu'un logement n'est dtenu
que par une seule personne et que ce propritaire figure obligatoirement dans l'entit des
personnes.

II-A-5. Association rflexive

Il est permis une association d'tre branche plusieurs fois la mme entit, comme par
exemple l'association binaire rflexive de la figure 7.

Figure 7 - Association reflexive

Dans cet exemple, tout employ est dirig par un autre employ (sauf le directeur gnral) et
un employ peut diriger plusieurs autres employs, ce qui explique les cardinalits sur le
schma.

II-A-6. Associations non binaires

Lorsqu'autour d'une entit, toutes les associations ont pour cardinalits maximales 1 au centre
et n l'extrieur, cette entit est candidate pour tre remplace par une association branche
toutes les entits voisines avec des cardinalits identiques 0,n.

La deuxime condition qu'il faut imprativement satisfaire est la rgle de normalisation des
attributs des associations (section suivante). Cette rgle conduit parfois l'apparition
d'associations qui tablissent un lien smantique entre 3 entits ou plus.

Sur l'exemple de la figure 8 issu d'un cinma, l'entit projections est uniquement entoure
d'associations dont les cardinalits maximales sont 1 ct projections et n de l'autre ct. De
plus, la donne d'un crneau, d'un film et d'une salle suffit dterminer une projection unique.
On peut donc la remplacer par une association projeter branche aux trois entits salles,
crneaux horaires et films. On parle alors d'association ternaire.
Figure 8 - Entit remplaable par une association ternaire
La difficult de concevoir une association ternaire (ou plus) directement est d'tablir les
bonnes cardinalits. Il est donc conseill d'en passer par un schma entits-associations dans
lequel on ne trouve que des associations binaires, puis de reprer les entits remplaables par
des associations, comme sur la figure 8 gauche.

Cette rgle de conduite permet d'viter d'introduire une association ternaire abusive, par
exemple entre les avions, les pilotes et les vols (figure 9), car le concepteur peut s'apercevoir
que l'une des cardinalits maximales ne convient pas.

Figure 9 - Contre-exemple : l'entit dparts n'est pas remplaable par une association ternaire
Par ailleurs, une association peut tre branche plus de trois entits, comme sur la figure 10.
L-encore, le conseil pour tre sr de la lgitimit de cette association 4-aire, est de vrifier
les cardinalits sur un schma intermdiaire faisant apparatre la place, une entit
occupations et quatre associations binaires.

Figure 10 - Exemple d'entit quaternaire ou 4-aire

II-B. Rgles de normalisation

Un bon schma entits-associations doit rpondre 9 rgles de normalisation, que le
concepteur doit connatre par coeur.

II-B-1. Les bonnes pratiques dans un schma entits-associations

Normalisation des entits (importante) : toutes les entits qui sont remplaables par une
association doivent tre remplaces (comme sur la figure 8).

Normalisation des noms : le nom d'une entit, d'une association ou d'un attribut doit tre
unique.

Conseils :

pour les entits, utiliser un nom commun au pluriel (par exemple : clients) ;

pour les associations, utiliser un verbe l'infinitif (par exemple : effectuer, concerner)
ventuellement la forme passive (tre command) et accompagn d'un adverbe
(avoir lieu dans, pendant, ) ;
 pour les attributs, utiliser un nom commun singulier (par exemple : nom, numro,
libell, description), ventuellement accompagn du nom de l'entit ou de l'association
dans laquelle il se trouve (par exemple : nom de client, numro d'article).

Remarque : lorsqu'il reste plusieurs fois le mme nom, c'est parfois symptomatique d'une
modlisation qui n'est pas termine (figure 11(a)) ou le signe d'une redondance (figure 11(b)).

(a) Deux entits homognes peuvent tre fusionnes

(b) Si deux attributs contiennent les mmes informations, alors la redondance induit non
seulement un gaspillage d'espace mais galement un grand risque d'incohrence : ici, les
adresses risquent de ne pas tre les mmes et dans ces conditions, o faut-il livrer ?

Figure 11 - Contre-exemples de la normalisation des noms

Normalisation des identifiants : chaque entit doit possder un identifiant.

Conseils :

viter les identifiants composs de plusieurs attributs (comme par exemple un

identifiant form par les attributs nom et prnom), car d'une part c'est mauvais pour les
performances et d'autres part, l'unicit suppose par une telle dmarche finit tt ou tard
par tre dmentie ;

prfrer un identifiant court pour rendre la recherche la plus rapide possible (viter
notamment les chanes de caractres comme un numro de plaque d'immatriculation,
un numro de scurit sociale ou un code postal ) ;

viter galement les identifiants susceptibles de changer au cours du temps (comme

les plaques d'immatriculation ou les numros de scurit sociale provisoires).

Conclusion : l'identifiant sur un schma entits-associations (et donc la future cl primaire

dans le schma relationnel) doit tre un entier, de prfrence incrment automatiquement.
Normalisation des attributs (importante) : remplacer les attributs en plusieurs exemplaires
en une association supplmentaire de cardinalits maximales n et ne pas ajouter d'attribut
calculable partir d'autres attributs.

En effet, d'une part, les attributs en plusieurs exemplaires posent des problmes d'volutivit
du modle (sur la figure 12(a) gauche, comment faire si un employ a deux adresses
secondaires ?) et d'autre part, les attributs calculables induisent un risque d'incohrence entre
les valeurs des attributs de base et celles des attributs calculs, comme sur la figure 12(b).

(a) Attributs en plusieurs exemplaires remplacs par une association supplmentaire

(b) Attribut calculable qu'il faut retirer du schma

Figure 12 - Contre-exemples de la normalisation des attributs

D'autres d'attributs calculables classiques sont viter, comme l'ge (qui est calculable partir
de la date de naissance) ou encore le dpartement (calculable partir d'une sous-chane du
code postal).

Normalisation des attributs des associations (importante) : les attributs d'une association
doivent dpendre directement des identifiants de toutes les entits en association.

Par exemple, sur la figure 5 la quantit commande dpend la fois du numro de client et du
numro d'article, par contre la date de commande non. Il faut donc faire une entit
commandes part, idem pour les livraisons (figure 13).
Figure 13 - Normalisation des attributs des associations
L'inconvnient de cette rgle de normalisation est qu'elle est difficile appliquer pour les
associations qui ne possdent pas d'attribut. Pour vrifier malgr tout qu'une association sans
attribut est bien normalise, on peut donner temporairement cette association un attribut
imaginaire (mais pertinent) qui permet de vrifier la rgle.

Par exemple, entre les entits livres et auteurs de la figure 16, l'association crire ne possde
pas d'attribut. Imaginons que nous ajoutions un attribut pourcentage qui contient le
pourcentage du livre crit par chaque auteur (du mme livre). Comme cet attribut pourcentage
dpend la fois du numro de livre et du numro d'auteur, l'association crire est bien
normalise.

Autre consquence de la normalisation des attributs des associations : une entit avec une
cardinalit de 1,1 ou 0,1 aspire les attributs de l'association (figure 14).

Figure 14 - Cardinalit 1,1 et attributs d'une association

Normal isation des associations (importante) : il faut liminer les associations fantmes
(figure 15(a)), redondantes (figure 15(b)) ou en plusieurs exemplaires (figure 15(c)).

(a) les cardinalits sont toutes 1,1 donc c'est une association fantme
(b) si un client ne peut pas rgler la facture d'un autre client, alors l'association payer est
inutile et doit tre supprime (dans le cas contraire, l'association payer doit tre maintenue)

(c) une association suffit pour remplacer les 4 associations participer en tant que ...

Figure 15 - Contre-exemples de la normalisation des associations

En ce qui concerne les associations redondantes, cela signifie que s'il existe deux chemins
pour se rendre d'une entit une autre, alors ils doivent avoir deux significations ou deux
dures de vie diffrentes. Sinon, il faut supprimer le chemin le plus court, car il est dductible
partir de l'autre chemin. Dans notre exemple de la figure 15(b), si on supprime l'association
payer, on peut retrouver le client qui a pay le rglement en passant par la facture qui
correspond.

Remarque : une autre solution pour le problme de la figure 15(b) consiste retirer l'entit
rglements et d'ajouter une association rgler avec les mmes attributs (sauf l'identifiant) entre
les entits clients et factures.

Normalisation des cardinalits : une cardinalit minimale est toujours 0 ou 1 (et pas 2, 3 ou
n) et une cardinalit maximale est toujours 1 ou n (et pas 2, 3, ...).

Cela signifie que si une cardinalit maximale est connue et vaut 2, 3 ou plus (comme sur la
figure 15(c) droite, ou pour un nombre limit d'emprunts dans une bibliothque), alors nous
considrons quand mme qu'elle est indtermine et vaut n. Cela se justifie par le fait que
mme si nous connaissons n au moment de la conception, il se peut que cette valeur volue au
cours du temps. Il vaut donc mieux considrer n comme une inconnue ds le dpart.
Cela signifie galement qu'on ne modlise pas les cardinalits minimales qui valent plus de 1
car ce genre de valeur est aussi amen voluer. Par ailleurs, avec une cardinalit maximale
de 'association n'aurait aucune signification.

Dans un SGBD relationnel, nous pourrions assurer les cardinalits valant 2, 3 ou plus, via
l'utilisation de dclencheurs. Mais cette notion n'est pas aborde dans ce document qui se
contente, au contraire, de dcrire ce qu'il est possible de faire sans utiliser de dclencheur.

II-B-2. Les formes normales

ces 6 rgles de normalisation, il convient d'ajouter les 3 premires formes normales

traditionnellement nonces pour les schmas relationnels, mais qui trouvent tout aussi bien
leur place en ce qui concerne les schmas entits-associations.

Premire forme normale : un instant donn dans une entit, pour un individu, un attribut
ne peut prendre qu'une valeur et non pas, un ensemble ou une liste de valeurs.

Si un attribut prend plusieurs valeurs, alors ces valeurs doivent faire l'objet d'une entit
supplmentaire, en association avec la premire (figure 16).

Figure 16 - Application de la premire forme normale : il peut y avoir plusieurs auteurs pour
un livre donn
Deuxime forme normale : l'identifiant peut tre compos de plusieurs attributs mais les
autres attributs de l'entit doivent dpendre de l'identifiant en entier (et non pas une partie de
cet identifiant).

Cette deuxime forme normales peut tre oublie si on suit le conseil de n'utiliser que des
identifiants non composs et de type entier. En vrit, elle a t vide de sa substance par la
rgle de normalisation des attributs des associations (paragraphe Normalisation des
attributs des associations ).

Considrons malgr tout le contre-exemple suivant : dans une entit clients dont l'identifiant
est compos des attributs nom et prnom, la date de fte d'un client ne dpend pas de son
identifiant en entier mais seulement de prnom. Elle ne doit pas figurer dans l'entit clients, il
faut donc faire une entit calendrier part, en association avec l'entit clients.

Troisime forme normale de Boyce-Codd (importante) : tous les attributs d'une entit
doivent dpendre directement de son identifiant et d'aucun autre attribut. Si ce n'est pas le cas,
il faut placer l'attribut pathologique dans une entit spare, mais en association avec la
premire.

numro avion constructeur modle capacit propritaire

1 Airbus A380 180 Air France
2 Boeing B747 314 British Airways
3 Airbus A380 180 KLM
Tableau 17 - Il y a redondance (et donc risque d'incohrence) dans les colonnes constructeur
et capacit

Par exemple, l'entit avions (figure 18 gauche) dont les valeurs sont donnes dans le
tableau 17, n'est pas en troisime forme normale de Boyce-Codd, car la capacit et le
constructeur d'un avion ne dpendent pas du numro d'avion mais de son modle. La solution
amliore est donne figure 18 droite.

Figure 18 - Application de la troisime forme normale de Boyce-Codd

En toute rigueur, la colonne constructeur ne doit pas tre maintenue dans l'entit modles
d'avion, mais doit tre place dans une entit spare constructeurs (en association avec
modles d'avion), afin d'viter la redondance du nom d'un constructeur pour tous ses modles.

II-C. Dpendances fonctionnelles

Pour tablir efficacement un modle entits-associations bien normalis, on peut tudier au
pralable les dpendances fonctionnelles entre les attributs puis, les organiser en graphe de
couverture minimale. Cette technique est traditionnellement employe pour normaliser des
schmas relationnels, mais elle s'applique trs bien en amont, au niveau des modles
conceptuels.

II-C-1. Dfinitions et proprits

Un attribut Y dpend fonctionnellement d'un attribut X si et seulement si une valeur de X

induit une unique valeur de Y. On note une dpendance fonctionnelle par une flche simple :
X ? Y.
Par exemple, si X est le numro de client et Y le nom de client, alors on a bien X ? Y. Par
contre, on a pas Y ? X, car plusieurs clients de numros diffrents peuvent porter le mme
nom.

Transitivit : si X ? Y et Y ? Z alors X ? Z.

Par exemple, on a numro de commande ? numro de client ? nom de client, donc on a aussi
numro de commande ? nom de client.

Mais la dpendance fonctionnelle numro de commande ? nom de client est dite transitive, car
il faut passer par le numro de client pour l'obtenir. Au contraire, la dpendance fonctionnelle
numro de client ? nom de client est directe. Seules les dpendances fonctionnelles directes
nous intressent. D'autres exemples sont donns dans le tableau 19.

dpendance fonctionnelle directe ?

numro de livraison ? date de livraison oui
numro de livraison ? numro du fournisseur oui
numro du fournisseur ? nom du fournisseur oui
numro de livraison ? nom du fournisseur non
Tableau 19 - Exemples de dpendances fonctionnelles

Un attribut Y peut avoir une dpendance fonctionnelle qui repose sur la conjonction de
plusieurs attributs, auquel cas la dpendance est dite non lmentaire. Les dpendances
fonctionnelles non lmentaires sont notes par une flche unique mais comportant plusieurs
points d'entre (regroups autour d'un cercle).

Par exemple, la quantit commande (d'un article dans une commande) dpend de deux
attributs : le numro de commande et le numro d'article (figure 20). Notons que cette
dpendance numro de commande + numro d'article ? quantit est la fois non lmentaire
et directe.

Figure 20 - Dpendance fonctionnelle non lmentaire, mais directe

II-C-2. Graphe de couverture minimale

En reprsentant tous les attributs et toutes les dpendances fonctionnelles directes entre eux,
nous obtenons un rseau appel graphe de couverture minimale. Dans notre exemple sur les
clients, les commandes et les articles, ce graphe est donn sur la figure 21.
Figure 21 - Graphe de couverture minimale
La technique de traduction en un schma entits-associations qui suit, suppose qu'aucun
attribut n'a t oubli sur le graphe de couverture minimal et notamment, aucun identifiant.
D'ailleurs toutes les dpendances fonctionnelles du graphe doivent partir d'un identifiant. Si ce
n'est pas le cas, c'est qu'un identifiant a t omis.

II-C-3. Traduction vers un schma entits-associations

partir du graphe de couverture minimale (figure 21), le schma entits-associations

normalis correspondant apparat naturellement (figure 22), en suivant quelques tapes
simples.

Figure 22 - Identification des entits et des associations sur un graphe de couverture minimale
tape 1 : il faut reprer et souligner les identifiants.

tape 2 : puis tous les attributs non identifiant qui dpendent directement d'un identifiant et
d'un seul, forment une entit (avec l'identifiant, bien sr).

tape 3 : ensuite, les dpendances lmentaires entre les identifiants forment des associations
binaires dont les cardinalits maximales sont 1 au dpart de la dpendance fonctionnelle et n
l'arrive.

tape 4 : sauf si entre deux identifiants se trouvent deux dpendances lmentaires rflexives,
auquel cas l'association binaire a deux cardinalits maximales valant 1.

tape 5 : enfin, les attributs (non identifiants) qui dpendent de plusieurs identifiants sont les
attributs d'une association supplmentaire dont les cardinalits maximales sont toutes n.

La traduction du graphe de couverture minimale de la figure 22 en un schma entits-

associations normalis est donne sur la figure 23.
Figure 23 - Schma entits-associations normalis obtenu partir du graphe de couverture
minimale
Dans ce genre de traduction, il faut donner un nom aux entits et aux associations, car ce n'est
pas le cas sur le graphe de couverture minimale et il reste les cardinalits minimales tablir.

Remarquons galement qu'en ralit, il faut dj connatre les entits en prsence pour tablir
correctement le graphe de couverture minimale, ne serait-ce que pour y faire figurer leurs
identifiants. Donc finalement, cette technique n'est une aide pour tablir les associations entre
les entits et pour normaliser les entits et leurs associations (jusqu'en troisime forme
normale de Boyce-Codd).

II-C-4. Gestion des dates et du caractre historique

Dans une bibliothque, on peut vouloir stocker les emprunts en cours (figure 24) et/ou les
emprunts historiques (figure 25).

Figure 24 - Sans historisation des emprunts, pas de problme

Pour les emprunts en cours, la date de retour prvu est un attribut de l'entit livres car un livre
ne peut faire l'objet que d'un seul emprunt en cours. Dans ce cas, l'tablissement du graphe de
couverture minimal ne pose aucun problme.

Par contre, un livre peut faire l'objet de plusieurs emprunts historiques et dans ces conditions,
la date d'emprunt est dterminante pour connatre la date de retour prvue (figure 25 en haut
gauche). Or une date n'est pas un identifiant et une dpendance fonctionnelle ne peut partir
que d'un ou plusieurs identifiant(s). C'est le signe qu'il manque un identifiant : le numro
d'emprunt (figure 25 en haut droite).
Figure 25 - Mme pour une entit historise, il vaut mieux viter que la date n'entre dans
l'identifiant
Notons que l'entit emprunts historiques supplmentaire qui apparat aprs traduction
(figure 25 en bas) ne peut pas tre transforme en une association comme on pourrait le croire
au simple examen des cardinalits qui l'entourent. En effet, les attributs de l'association qui en
rsulterait ne vrifieraient pas la normalisation des attributs des associations. Notamment, la
date de retour effectif ne dpend pas du numro de livre et du numro de membre, mais du
numro de livre et de la date d'emprunt.

La normalisation des entits ne s'applique donc pas aux entits qui ont un caractre historique.
moins que les dates ne soient regroupes dans une entit spare, ce qui n'est pas conseill
tant qu'aucune information lie aux dates (comme le caractre fri, par exemple) n'est
ncessaire.

II-C-5. Dpendances plurielles et rflexives

Une ou plusieurs dpendances fonctionnelles peuvent partir ou arriver plusieurs fois du mme
attribut. Pour clarifier la signification de chaque dpendance fonctionnelle, on peut ajouter un
commentaire sur la flche (figure 26). Ce commentaire sert ensuite donner un nom aux
associations correspondantes.
Figure 26 - Dpendances fonctionnelles commentes
Les dpendances fonctionnelles plurielles entre les mdecins et les remplacements
(figure 26(a)) deviennent, aprs traduction, des associations plurielles entre les entits
mdecins et remplacements. Notons que l'entit remplacements ainsi gnre, a aussi un
caractre historique.

Les fonctionnelles rflexives (X ? X), quoique toujours vraies, ne prsentent aucun intrt,
moins qu'elles aient une signification particulire. Un exemple de dpendance rflexive licite
sur un graphe de couverture minimale est la dpendance fonctionnelle personne ? personne,
lorsqu'elle signifie diriger , tre en couple avec ou tre le pre ou la mre de
(figure 26(b)).

Dans le mme ordre d'ide, il est inutile de faire figurer sur le graphe de couverture minimal
des dpendances fonctionnelles non lmentaires vraies, mais idiotes, comme par exemple
numro de commande + numro d'article ? numro de commande.

II-C-6. Associations sans attributs

La lacune majeure de cette mthode reste tout de mme le fait que les associations dont toutes
les cardinalits maximales sont n mais qui sont sans attribut ne figurent pas sur le graphe de
couverture minimale. Il faut alors, soit leur inventer temporairement un attribut (comme pour
la normalisation des attributs des associations), soit introduire une notation spciale (par
exemple, une dpendance non lmentaire qui ne dbouche sur aucun attribut).

Pour illustrer ce dfaut, prenons l'exemple des films et des acteurs (figure 27).
Figure 27 - Utilisation d'une dpendance non lmentaire et sans enfant sur un graphe de
couverture minimal
Il n'y a pas d'attribut qui dpende la fois du numro de film et du numro d'acteur ( moins
d'imaginer le temps d'apparition l'cran). Et pourtant, les deux entits films et acteurs sont
en association. Grce la dpendance non lmentaire et sans enfant, on peut rendre compte
de cette situation sur le graphe de couverture minimale et faire ainsi apparatre l'association
sur le schma entits-associations qui en est traduit.

II-D. Mthodologie de base

Face une situation bien dfinie (soit travers un nonc prcis, soit travers une collection
de formulaires ou d'tats que le nouveau systme d'information est cens remplacer), nous
pouvons procder sans tablir le graphe de couverture minimale :

identifier les entits en prsence ;

lister leurs attributs ;

ajouter les identifiants (numro arbitraire et auto-incrment) ;

tablir les associations binaires entre les entits ;

lister leurs attributs ;

calculer les cardinalits ;

vrifier les rgles de normalisation et en particulier, la normalisation des entits (c'est

ce stade qu'apparaissent les associations non binaires), des associations et de leurs
attributs ainsi que la troisime forme normale de Boyce-Codd ;

effectuer les corrections ncessaires.

Mais, il est parfois plus intuitif d'en passer par l'tude des dpendances fonctionnelles directes
:

identifier les entits en prsence et leur donner un identifiant (numro arbitraire et

auto-incrment) ;
 ajouter l'ensemble des attributs et leur dpendances fonctionnelles directes avec les
identifiants (en commenant par les dpendances lmentaires) ;

traduire le graphe de couverture minimale obtenu en un schma entits-associations ;

ajuster les cardinalits minimales ;

ce stade, la majorit des rgles de normalisation devraient tre vrifies, il reste tout
de mme la normalisation des noms, la prsence d'attributs en plusieurs exemplaires et
d'associations redondantes ou en plusieurs exemplaires, corriger.

Il faut garder galement l'esprit que le modle doit tre exhaustif (c'est--dire contenir toutes
les informations ncessaires) et viter toute redondance qui, on ne le dira jamais assez,
constitue une perte d'espace, une dmultiplication du travail de maintenance et un risque
d'incohrence.

Il faut par ailleurs veiller liminer les synonymes (plusieurs signifiants pour un signifi,
exemple : nom, patronyme, appellation) et les polysmes (plusieurs signifis pour un
signifiant, exemples : qualit, statut).

Il va de soi que cette mthodologie ne doit pas tre suivie pas--pas une bonne fois pour toute.
Au contraire, il faut itrer plusieurs fois les tapes successives, pour esprer converger vers
une modlisation pertinente de la situation.

III. Modle logique de donnes (MLD)

Maintenant que le MCD est tabli, on peut le traduire en diffrents systmes logiques et
notamment les bases de donnes relationnelles qui proposent une vision plus concrte pour
modliser la situation.

III-A. Systmes logiques

Avant l'apparition des systmes de gestion de base de donnes (SGBD ou DBMS pour Data
Base Management System), les donnes taient stockes dans des fichiers binaires et gres
par des programmes excutables (dvelopps en Basic, Cobol ou Dbase, par exemple).
[Gabay] propose ce sujet une traduction d'un MPD vers un MLD fichier. Mais la
maintenance des programmes (en cas de modification de la structure des donnes,
notamment) tait trs problmatique.

Sont alors apparus les SGBD hirarchiques dans lesquels les donnes sont organises en arbre
(IMS-DL1 d'IBM, par exemple), puis les SGBD rseaux dans lesquels les donnes sont
organises selon un graphe plus gnral (IDS2 de Bull, par exemple). [Matheron], [Nanci et
al.]et [Gabay] dcrivent la traduction d'un MPD vers un MLD Codasyl (base de donnes
rseaux). Ces deux types de SGBD sont dit navigationnels car on peut retrouver l'information
condition d'en connatre le chemin d'accs.

Aujourd'hui, ils sont largement remplacs par les SGBD relationnels (SGBDR) avec lesquels
l'information peut tre obtenue par une requte formule dans un langage quasiment naturel
(la langage SQL pour Structured Query Langage). Parmi les SGBDR les plus rpandus nous
trouvons Oracle, SQL Server et DB2. Nous nous contentons ici d'exposer le modle logique
de donnes relationnel (MLDR).

Plus rcemment, sont apparus le modle logique orient objet et mme des SGBD orients
objets. Pourtant, les SGBD relationnels restent extrmement majoritaires, tandis que
l'approche orient objet est parfaitement adapte au dveloppement d'applications clientes
dynamiques et lies aux donnes du systme d'information.

III-B. Modle logique relationnel

Concentrons-nous dsormais sur le MLDR.

III-B-1. Tables, lignes et colonnes

Lorsque des donnes ont la mme structure (comme par exemple, les renseignements relatifs
aux clients), on peut les organiser en table dans laquelle les colonnes dcrivent les champs en
commun et les lignes contiennent les valeurs de ces champs pour chaque enregistrement
(tableau 28).

numro client nom prnom adresse

1 Dupont Michel 127, rue...
2 Durand Jean 314, boulevard...
3 Dubois Claire 51, avenue...
4 Dupuis Marie 2, impasse...
... ... ... ...
Tableau 28 - Contenu de la table clients, avec en premire ligne les intituls des colonnes

III-B-2. Cls primaires et cls trangres

Les lignes d'une table doivent tre uniques, cela signifie qu'une colonne (au moins) doit servir
les identifier. Il s'agit de la cl primaire de la table.
L'absence de valeur dans une cl primaire ne doit pas tre autorise. Autrement dit, la valeur
vide (NULL) est interdite dans une colonne qui sert de cl primaire, ce qui n'est pas forcment
le cas des autres colonnes, dont certaines peuvent ne pas tre renseignes toutes les lignes.

De plus, la valeur de la cl primaire d'une ligne ne devrait pas, en principe, changer au cours
du temps.

Par ailleurs, il se peut qu'une colonne Colonne1 d'une table ne doive contenir que des valeurs
prises par la colonne Colonne2 d'une autre table (par exemple, le numro du client sur une
commande doit correspondre un vrai numro de client). 2 doit tre sans doublons (bien
souvent il s'agit d'une cl primaire). On dit alors que 1 est cl trangre et qu'elle rfrence 2.

Par convention, on souligne les cls primaires et on fait prcder les cls trangres d'un dise
# dans la description des colonnes d'une table :

clients(numro client, nom client, prnom, adresse client)

commandes(numro commande, date de commande, #numro client (non vide))

Remarques :

une mme table peut avoir plusieurs cls trangres mais une seule cl primaire
(ventuellement composes de plusieurs colonnes) ;

une colonne cl trangre peut aussi tre primaire (dans la mme table) ;

une cl trangre peut tre compose (c'est le cas si la cl primaire rfrence est
compose) ;

implicitement, chaque colonne qui compose une cl primaire ne peut pas recevoir la
valeur vide (NULL interdit) ;

par contre, si une colonne cl trangre ne doit pas recevoir la valeur vide, alors il faut
le prciser dans la description des colonnes.

Les SGBDR vrifient au coup par coup que chaque cl trangre ne prend pas de valeurs en
dehors de celles dj prises par la ou les colonne(s) qu'elle rfrence. Ce mcanisme qui agit
lors de l'insertion, de la suppression ou de la mise jour de lignes dans les tables, garantit ce
que l'on appelle l'intgrit rfrentielle des donnes.

III-B-3. Schma relationnel

On peut reprsenter les tables d'une 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 (figure 29).
Figure 29 - Schma relationnel simple entre deux tables
Certains diteurs inscrivent sur le connecteur un symbole 1 ct cl primaire et un symbole ?
ct cl trangre ( condition que celle-ci ne soit pas dj cl primaire). Il faut prendre garde
avec cette convention, car le symbole ? se trouve du ct oppos la cardinalit maximale n
correspondante.

III-C. Traduction d'un MCD en un MLDR

Pour traduire un MCD en un MLDR, il suffit d'appliquer cinq rgles.

Notations : on dit qu'une association binaire (entre deux entits ou rflexive) est de type :

1 : 1 (un un) si aucune des deux cardinalits maximales n'est n ;

1 : n (un plusieurs) si une des deux cardinalits maximales est n ;

n : m (plusieurs plusieurs) si les deux cardinalits maximales sont n.

En fait, un schma relationnel ne peut faire la diffrence entre 0,n et 1,n. Par contre, il peut la
faire entre 0,1 et 1,1 (rgles 2 et 4).

Rgle 1 : toute entit devient une table dans laquelle les attributs deviennent les colonnes.
L'identifiant de l'entit constitue alors la cl primaire de la table.

Par exemple, l'entit articles de la figure 13 devient la table :

articles(numro article, dsignation, prix unitaire de vente)

Rgle 2 : une association binaire de type 1 : n disparat, au profit d'une cl trangre dans la
table ct 0,1 ou 1,1 qui rfrence la cl primaire de l'autre table. Cette cl trangre ne peut
pas recevoir la valeur vide si la cardinalit est 1,1.

Par exemple, l'association livrer de la figure 13 est traduite par :

fournisseurs(n fournisseur, nom contact, n tlphone contact)

livraisons(n livraison, date de livraison, nom livreur, #n fournisseur (non vide))

Figure 30 - Traduction d'une association de type 1 : n
Il ne devrait pas y avoir d'attribut dans une association de type 1 : n, mais s'il en reste, alors ils
glissent vers la table ct 1.

Rgle 3 : une association binaire de type n : m devient une table supplmentaire (parfois
appele table de jonction, table de jointure ou table d'association) dont la cl primaire est
compose de deux cls trangres (qui rfrencent les deux cls primaires des deux tables en
association). Les attributs de l'association deviennent des colonnes de cette nouvelle table.

Par exemple, l'association concerner (1) de la figure 13 est traduite par la table supplmentaire
lignes de commande :

lignes de commande(#n commande, #n article, quantit commande)

Figure 31 - Traduction d'une association de type n : m

Rgle 4 : une association binaire de type 1 : 1 est traduite comme une association binaire de
type 1 : n sauf que la cl trangre se voit imposer une contrainte d'unicit en plus d'une
ventuelle contrainte de non vacuit (cette contrainte d'unicit impose la colonne
correspondante de ne prendre que des valeurs distinctes).

Si les associations fantmes ont t limines, il devrait y avoir au moins un ct de

cardinalit 0,1. C'est alors dans la table du ct oppos que doit aller la cl trangre. Si les
deux cts sont de cardinalit 0,1 alors la cl trangre peut tre place indiffremment dans
l'une des deux tables.

Par exemple, l'association diriger de la figure 32 est traduite par :

services(n service, nom service, #numro employ (non vide, unique))

employs(numro employ, nom)

Figure 32 - Traduction d'une association de type 1 : 1

En ralit, la rgle 4 propose ici considre qu'une association binaire de type 1 : 1 correspond
une association binaire de type 1 : n particulire. Une alternative consiste voir une
association binaire de type 1 : 1 comme une association binaire de type n : m particulire. Il
suffit pour cela d'ajouter une contrainte d'unicit sur chacune des cls trangres de la table de
jonction supplmentaire :

services(n service, nom service)

directions(#n service (unique), #numro employ (unique))

employs(numro employ, nom)

Figure 33 - Traduction alternative d'une association de type 1 : 1

Mais rien ne garantit, dans cette traduction alternative (figure 33), qu'un service possde un
dirigeant, alors que c'est obligatoire. La premire traduction (figure 32) est donc prfrable.

Remarque : d'autres techniques sont parfois proposes pour cette rgle 4 (fusionner les tables,
utiliser une cl primaire identique, utiliser deux cls trangres rflexives) mais elles ne sont
pas exploitables dans le cas gnral.

Rgle 5 : une association non binaire est traduite par une table supplmentaire dont la cl
primaire est compose d'autant de cls trangres que d'entits en association. Les attributs de
l'association deviennent des colonnes de cette nouvelle table.

Par exemple, l'association projeter de la figure 8 devient la table :

projections(#n film, #n salle, #n crneau, tarif)

Figure 34 - Traduction d'une association ternaire

IV. Modle physique de donnes (MPD)

Un modle physique de donnes est l'implmentation particulire du modle logique de
donnes par un logiciel.

IV-A. Distinction entre MLD et MPD

La traduction d'un MLD conduit un MPD qui prcise notamment le stockage de chaque
donne travers son type et sa taille (en octets ou en bits). Cette traduction est galement
l'occasion d'un certain nombre de liberts prises par rapport aux rgles de normalisation afin
d'optimiser les performances du systme d'information.

La traduction d'un MLD relationnel en un modle physique est la cration (par des requtes
SQL de type CREATE TABLE et ADD CONSTRAINT) d'une base de donnes hberge par
un SGBD relationnel particulier. Il peut s'agir d'une base Oracle, d'une base SQL Server, d'une
base Access ou d'une base DB2, par exemple. Le fait que tous les SGBDR reposent sur le
mme modle logique (le schma relationnel) permet la fois la communication entre des
bases htrognes et la conversion d'une base de donnes d'une SGBDR l'autre.

IV-B. Optimisations
L'optimisation des performances en temps de calcul se fait toujours au dtriment de l'espace
mmoire consomm. Dans le pire des cas, rduire les temps de rponse consiste d-
normaliser volontairement le systme d'information, avec tous les risques d'incohrence et les
problmes de gestion que cela comporte.

Pour les bases de donnes relationnelles, l'optimisation qui vise acclrer les requtes peut
passer par :

l'ajout d'index aux tables (au minimum sur les colonnes cls primaires et cls
trangres) ; ces index consomment de l'espace mmoire supplmentaire, mais la base
de donnes reste normalise ;

l'ajout de colonnes calcules ou de certaines redondances pour viter des jointures

coteuses (auquel cas la base est d-normalise) ; il faut alors veiller ce que la
cohrence entre les colonnes soit respecte, soit par l'utilisation de dclencheurs, soit
dans les applications clientes du systme d'information ;

la suppression des contraintes d'unicit, de non vacuit ou encore de cl trangre

(auquel cas, l'intgrit des donnes doit tre assure par le code client du systme
d'information).

Par exemple, la table commandes de la figure 31 peut tre supprime et la date de commande
est alors ajoute la table lignes de commandes.

Figure 35 - Sacrifice de la troisime forme normale

On renonce donc la troisime forme normale (figure 35) puisque la date de commande est
rpte autant de fois qu'il y a de lignes dans la commande, mais on vite ainsi une jointure
coteuse en temps de calcul lors des requtes SQL..

Le conseil le plus prcieux, en matire d'optimisation, est de ne jamais optimiser a priori,

mais toujours a posteriori, c'est--dire en rponse une lenteur que le SGBDR n'est pas
capable de rsoudre tout seul. Il faut alors mesurer le gain de toute optimisation manuelle en
effectuant des tests (chronomtrages avant/aprs) sur un volume de donnes significatif et de
prfrence en exploitation.
V. Rtro-conception
Dans la majorit des cas, le travail du concepteur de bases de donnes consiste non pas crer
une base de donnes ex nihilo, mais plutt corriger ou tendre une base existante. Dans ce
cas, la matire de travail initiale est un modle physique et la mthode de rtro-conception ou
reverse engineering consiste traduire ce MPD en un modle conceptuel, modifier le MCD
obtenu puis modifier le modle physique en consquence.

V-A. Traduction inverse

Dans le cadre des bases de donnes relationnelles, il faut convertir le modle physique en un
schma relationnel normalis (en dtricotant les optimisations ventuelles et en renommant
les colonnes des tables pour assurer l'unicit et le caractre explicite (non cod) des noms),
puis appliquer les rgles de traduction de la section Traduction d'un MCD en un MLDR
dans le sens inverse.

tape 1 : chaque table dont la cl primaire ne contient pas de cl trangre devient une entit
dont l'identifiant est la cl primaire de la table et dont les attributs sont les colonnes de la table
qui ne sont pas cl trangre.

tape 3 : chaque table dont la cl primaire est compose exclusivement de cls trangres qui
rfrencent plusieurs cls primaires, devient une association autour de laquelle toutes les
cardinalits maximales valent n, c'est-a-dire soit une association binaire de type n : m soit une
association ternaire ou plus (les autres colonnes non cls trangres de la table deviennent des
attributs de l'association).

tape 5 : les colonnes cls trangres restantes deviennent des associations binaires de type
1 : n s'il n'y a pas de contrainte d'unicit ou de type 1 : 1 s'il y a une contrainte d'unicit (il faut
trouver un nom cette association).

tape 6 : la cardinalit minimale vaut 1 pour les cls trangres qui font partie d'une cl
primaire ou qui possdent une contrainte (non vide), sinon elle vaut 0.

V-B. Cas particuliers

Malheureusement, ces quatre tapes ne suffisent pas pour traduire tous les schmas
relationnels possibles. Notamment, les tables de la figure 36 ncessitent l'insertion d'tapes
supplmentaires.
 a. cl sur une colonne, mais la fois primaire et trangre

b. cl primaire compose partiellement de cl trangre

Figure 36 - Tables particulires en rtro-conception

tape 2 : chaque table dont la cl primaire est compose exclusivement de cls trangres qui
rfrencent une seule cl primaire, devient une sous-entit ou une sous-association (les autres
colonnes non cls trangres de la table deviennent des attributs de cette sous-entit).

tape 4 : chaque table dont la cl primaire est compose partiellement de cls trangres
provient soit d'une optimisation qu'il faire dfaire (comme sur la figure 35) soit d'un
identifiant relatif d'une entit comme dans la section Identifiant relatif ou lien identifiant
(auquel cas les autres colonnes non cls trangres de la table deviennent des attributs de cette
entit).

VI. Complments
Aucune situation complte, ou presque, ne peut tre parfaitement modlise si le concepteur
se contente des fonctionnalits abordes ce stade du document. Ne serait-ce que pour
comprendre l'laboration des tables de la figure 36, il est ncessaire d'introduire de nouvelles
notations sur le schma entits-associations. Les trois extensions majeures prsentes dans
cette section font partie de la version 2 de Merise [Panet et al.]. Elles permettent de traiter
davantage de situations relles et souvent de manire plus simple.

Dans cette section, nous reprenons la dmarche qui consiste tudier les dpendances
fonctionnelles directes sur le graphe de couverture minimale, puis traduire ce graphe en
schma entits-associations, pour obtenir finalement un schma relationnel. Les notions
abordes ici ne permettent plus au schma relationnel d'tre crit textuellement sans
ambigut. Afin de lever toute ambigut pour savoir quelle cl primaire est rfrence par
telle cl trangre, il est impratif de reprsenter le schma relationnel de manire graphique,
ce que nous nous contentons de faire.
VI-A. Agrgation
Une association n'est pas forcment tablie exclusivement entre des entits.

VI-A-1. Association de type 1 : n

Considrons l'exemple de la figure 37 issu du monde des courses hippiques. La dpendance

fonctionnelle n cheval + n course ? n jockey est la premire dpendance fonctionnelle non
lmentaire vers un identifiant que nous rencontrons. Ce type de dpendance fonctionnelle
nous incite crer une association binaire de type 1 : n entre l'entit jockeys et l'association
binaire de type n : m qu'il y a entre les entits chevaux et courses. D'un point de vue
smantique, la logique est respecte puisque un jockey ne monte pas un cheval, mais un
cheval-qui-participe--une-course.

Figure 37 - Association binaire de type 1 : n (monter), lie une association binaire de type
n : m (participer)
Pour tenir compte de ce nouveau cas de dpendance fonctionnelle, il convient d'ajouter une
sixime tape la technique de traduction d'un graphe de couverture minimal en un schma
entits-associations, telle qu'elle est commence section Traduction vers un schma entits-
associations :

tape 6 : lorsqu'un identifiant dpend de plusieurs autres identifiants, son entit est en
association de type 1 : n avec l'association qui lie les autres identifiants.

Certains auteurs considrent que l'agrgation des entits chevaux, courses et de l'association
participer constitue une nouvelle entit participations qui englobe ces trois lments
graphiques. Dans ce cas, l'association monter fait le lien entre les deux entits (participations
et jockeys). Le rsultat final sur le schma relationnel est le mme. Malheureusement, cette
notation n'est pas trs pratique car le schma entits-associations devient vite illisible
lorsqu'une entit participe plusieurs agrgations.

Nous prfrons donc autoriser, dans ce document, qu'une association puisse tre lie une
association binaire de type n : m ou une association ternaire (ou plus). Cependant pour ne
pas confondre les liens entres associations et entits avec les liens entres associations, nous
encadrons soigneusement les associations qui interviennent dans une agrgation, comme sur
la figure 37 en bas gauche.

En tout cas, une association ne peut pas tre lie une association binaire de type 1 : n ou 1 :
1. Dans ce cas, l'association doit tre directement lie l'entit qui se trouve du ct o la
cardinalit maximale est 1.

Sur le schma relationnel final (figure 37 en bas droite), la table de jonction participations
reoit une cl trangre supplmentaire, mais qui contrairement aux autres, ne participe pas
la cl primaire.

VI-A-2. Association de type n : m

prsent, ajoutons les parieurs notre exemple de la figure 37. tant donn que nous avons
la dpendance fonctionnelle n cheval + n course + n parieur ? montant de la mise
(figure 38 en haut), nous pourrions avoir une association ternaire entre les entits chevaux,
courses et parieurs. Mais dans ce cas, un parieur peut miser sur un cheval dans une course,
alors que ce cheval ne participe pas cette course.
Figure 38 - Association ternaire remplace par deux associations binaires
Pour pallier cette lacune, on pourrait faire appel des dclencheurs programms dans la base
de donnes finale. Les dclencheurs sont des procdures SQL qui, dans notre exemple,
permettraient chaque insertion ou mise jour de lignes dans la table des paris, d'assurer
qu'un pari ne puisse pas concerner un cheval dans une course laquelle il ne participe pas.
Cependant, il existe une solution plus simple qui repose uniquement sur l'intgrit
rfrentielle.

En ralit (figure 38 en bas), la vraie dpendance fonctionnelle directe est n cheval + n

course) + n parieur ? montant, ce qui garantit qu'un parieur ne peut miser que sur un cheval-
qui-participe--une-course.

Le fait qu'une association ternaire (ou plus) disparaissent au profit d'une ou plusieurs
agrgations est trs frquent lorsque l'on modlise une situation complte. tel point qu'on
peut partir du principe qu'un schma entits-associations sans agrgation est gnralement
faux.

Dans notre exemple, la traduction de la nouvelle dpendance fonctionnelle en une association

de type n : m (figure 39 en haut) se fait en appliquant, comme d'habitude, l'tape 4 de la
section Traduction vers un schma entits-associations .
Figure 39 - Association binaire de type n : m (parier), lie une autre association binaire de
type n : m
Sur le schma relationnel obtenu (figure 39 en bas), la traduction de l'association binaire de
type n : m lie une autre association binaire de type n : m fait apparatre dans la table paris
une cl trangre composite qui rfrence la cl primaire composite de la table participations.

Rappelons qu'il est dconseill d'utiliser des identifiants composites. Mais la cl primaire
composite de la table participations est lgitime puisqu'elle est issue d'une association binaire
de type n : m. En consquence de quoi la cl trangre composite de la table paris est
galement lgitime puisqu'elle est aussi issue d'une association binaire de type n : m.

On peut ainsi imaginer avoir sur un schma relationnel des cls primaires ou trangres
composes d'un nombre arbitraire de colonnes, sans pour autant qu'il n'y ait un seul identifiant
composite sur le schma entits-associations correspondant.

VI-A-3. Tables de codification ou tables de rfrence

Certains attributs ne peuvent prendre qu'un jeu volontairement limit de valeurs. C'est le cas
sur la figure 40 gauche, pour les attributs enseignant et matire. Cela vite sur cet exemple
qu'une mme matire ne soit dcrite de deux manires diffrentes et qu'un mme nom
d'enseignant ne soit orthographi deux fois.

Figure 40 - Agrgation et entits de codification

Il est recommand de regrouper ces valeurs au sein d'une entit dite de codification (qui
donnera ensuite une table de codification). Si l'attribut concern appartient une entit, alors
cette entit est en association binaire de type 1 : n avec cette entit de codification. Par contre,
si l'attribut fait partie d'une association, il faut recourir l'agrgation afin de mettre en
association l'entit de codification avec l'association de cet attribut (figure 40 droite).

Ainsi, l'agrgation vite notamment aux entits de codification de transformer une association
binaire en une association ternaire (ou plus).

VI-B. Identifiant relatif ou lien identifiant

Mme en utilisant des agrgations, il reste des situations o tout le potentiel de l'intgrit
rfrentielle n'est pas exploit.

VI-B-1. Rsolution d'un problme sur le schma relationnel

Prenons par exemple le schma relationnel en haut de la figure 41, tir d'une base de donnes
pour un centre de golf. Dans la table trous, la cl primaire n trou est en incrment
automatique, tandis que la colonne n trou dans parcours est un nombre (gnralement
compris entre 1 et 18) qui correspond la numrotation des trous dans le parcours.
Le problme de ce schma relationnel est qu'en l'tat, il peut y avoir un score dans la table
scores pour un trou qui n'appartient pas au parcours sur lequel la partie se joue (le lecteur est
invit bien observer la figure pour s'en apercevoir).

Figure 41 - Utilisation de cls primaires partiellement trangres

Pour rgler ce problme, on peut nouveau se reposer sur l'emploi de dclencheurs. Mais l-
encore, il existe une solution ne faisant appel qu' l'intgrit rfrentielle.

Cette solution consiste faire entrer le numro de parcours dans la numrotation des trous
(remplaant ainsi le n trou) ainsi que dans la numrotation des parties (en conservant cette
fois-ci le n partie en incrment automatique). Les tables trous et parties possdent alors une
cl primaire composite et partiellement trangre (figure 41 en bas).

Les cls trangres des tables participations et scores qui rfrencent ces nouvelles cls
primaires sont alors compltes par une nouvelle colonne (le numro de parcours). Dans la
table des scores, comme cette colonne n parcours n'est introduite qu'une fois, il n'est plus
possible pour un joueur d'avoir un score sur un trou qui n'appartient pas au parcours sur lequel
se joue la partie.
VI-B-2. Modle conceptuel correspondant

En rtro-conception, pour tenir compte du fait que le numro de parcours fera partie de la cl
primaire de la table trous sur le schma entits-associations, il suffit de mettre entre
parenthses la cardinalit 1,1 de l'association entre les entits trous et parcours (figure 42).
L'identifiant de l'entit ct 1,1 devient alors relatif celui de l'autre entit en association.

Figure 42 - Reprsentation des identifiants relatifs

De mme, sur le graphe de couverture minimal, nous introduisons une nouvelle notation
(flche en pointills) pour reprsenter le caractre relatif des identifiants (figure 43).

Figure 43 - Reprsentation des identifiants relatifs sur le graphe de couverture minimale

Si les flches taient pleines, les numros de trou dans un parcours et de partie sur un parcours
figureraient dans des entits spares et rduites leur identifiant ( viter).

VI-B-3. Discussion autour de la numrotation des exemplaires

Dans un magasin de location de vidos, le grant peut vouloir numroter sparment les
exemplaires de chaque vido (figure 44 colonne de gauche), alors que le concepteur de la base
de donnes aurait tendance vouloir numroter globalement l'ensemble des exemplaires
(colonne de droite).

Figure 44 - Numrotations alternatives des exemplaires

La seule diffrence entre les deux solutions est l'entre ou non de la colonne numro vido
dans la cl primaire de la table exemplaire. L'inconvnient majeur de la solution avec
identifiant relatif (colonne de gauche), est le traitement de l'incrment automatique du numro
d'exemplaire, car il faut un compteur pour chaque vido et non pas un compteur pour
l'ensemble des vidos, contrairement la solution de la colonne de droite. Le concepteur
devrait donc retenir sa solution pour la base de donnes et proposer une colonne
supplmentaire avec la numrotation du grant, afin de lui faire plaisir.

VI-C. Hritage
Enfin, il est parfois utile de factoriser les attributs communs plusieurs entits au sein d'une
entit mre.

VI-C-1. Sous-entit

Considrons l'exemple suivant : les factures d'une entreprise font l'objet d'un rglement par
chque ou par carte. Cette entreprise souhaite connatre pour chaque rglement la date, le
montant et :

le numro et le nom de la banque des chques ;

ou le numro et la date d'expiration des paiements par carte.

On a donc une entit gnrique rglements et deux entits spcialises chques et paiements
par carte. Ces deux sous-entits de l'entit rglements ont des attributs propres mais pas
d'identifiant propre. Au niveau logique objet, on retrouve la notion d'hritage.

Conformment aux notations objets, sur le schma entits-associations, on reprsente le lien

qui unit une sous-entit son entit gnrique par une flche creuse (figure 45 au centre). Ce
lien remplace une association tre de type 1 : 1 (un chque est un rglement et un
paiement par carte est un rglement).
Figure 45 - Reprsentation des sous-entits
Toutefois, il ne faut pas voir d'hritage chaque fois que l'on peut dire est un , car il faut en
plus que l'entit mre ne possde que les attributs communs de ses entits filles. Par exemple,
un cercle est mathmatiquement un ovale. Mais l'entit cercles (avec les attributs centre et
rayon) n'est pas une sous-entit de l'entit ovales car celle-ci possde davantage d'attributs
(centre, rayon principal, rayon secondaire et rotation).

La traduction des sous-entits au niveau logique relationnel fait intervenir une cl primaire
identique celle de l'entit mre, mais dans les sous-entits la cl primaire est aussi trangre
(figure 45 en bas).

Sur le graphe de couverture minimale (figure 45 en haut), l'identifiant dont dpendent les
attributs communs est volontairement dupliqu autant de fois que ncessaire pour les attributs
spcialiss. Nous pouvons alors remarquer que les attributs qui dpendent d'un mme
identifiant peuvent tre regroups avec des et logiques tandis que ds qu'il est ncessaire
de faire appel un ou logique, c'est le signe d'une spcialisation.

Sur la figure 45, il est tentant de traduire directement le graphe de couverture minimale en le
schma relationnel, car il en est beaucoup plus proche que le schma entits-associations.
C'est une technique licite, condition de traduire correctement les associations de type 1 : 1
(tape 4).
VI-C-2. Utilisation de l'hritage pour sparer les informations
complmentaires

L'hritage peut tre utilis mme lorsqu'il n'y a qu'une entit spcialise. C'est utile pour
stocker dans une table spare des informations complmentaires.

Considrons la table clients dans laquelle nous stockons dj le numro, le nom et le code
postal. Nous souhaitons dsormais stocker galement le numro de tlphone, l'adresse
courrier et l'adresse lectronique. La premire ide consiste ajouter trois colonnes
supplmentaires dans la table clients. Mais pour les clients qui ont dj t saisis dans la table,
ces trois colonnes seront vides.

Pour gagner de la place, ces trois colonnes peuvent constituer une nouvelle table annuaire
clients dont la cl primaire rfrence celle de la table clients (figure 46). Formellement,
annuaire clients est issu d'une sous-entit de l'entit clients.

Figure 46 - Sparation des informations complmentaires par hritage

La configuration d'hritage sur le schma relationnel (figure 46 droite) constituera une
occasion d'crire des requtes SQL avec des jointures externes (c'est--dire facultatives).

VI-C-3. Spcialisation des associations

La notion d'hritage est valable galement pour les associations. Nous pouvons donc faire
appel des sous-associations avec des attributs spcifiques et des associations gnriques qui
contiennent les attributs communs. Mais sans aller jusqu' l'introduction de sous-associations,
ds qu'un schma entits-associations fait appel des sous-entits, il est frquent que les
associations concernes par ces sous-entits soient elles-mmes spcialises.

Considrons une entreprise artisanale qui vend non seulement des articles produits en srie
prix unitaire fixe, mais aussi des articles fait sur mesure et dont le prix unitaire est calcul
partir de la dure de confection et d'un taux horaire. Dans ce cas, non seulement l'entit
articles est spcialise en articles en srie et articles sur mesure, mais en plus, l'association
concerner entre les entits commandes et article est spcialise selon qu'il s'agit d'un article en
srie ou sur mesure (figure 47 au centre).
Figure 47 - Spcialisation des associations en prsence de sous-entits
Le fait d'avoir volontairement ddoubler l'identifiant commun des entits en hritage, permet
d'utiliser chaque identifiant dupliqu dans l'association qui le concerne.

Sur le schma relationnel (figure 47 en bas), les associations spcialises sont traduites de
manire classique. charge ensuite pour le dveloppeur du formulaire de facturation,
d'effectuer la runion des articles commands.

VII. Conclusion
Avec la pratique, vient un moment o le concepteur peut se passer du modle entits-
associations et produire directement des schmas relationnels corrects. Pourtant, continuer de
travailler un niveau conceptuel plutt qu' un niveau logique reste une tactique payante pour
lui, dans la mesure o les donnes pourtant stockes sous une forme relationnelle, doivent de
nos jours tre accdes par des applications orientes objet. Le modle conceptuel permet de
faire le lien entre d'une part la reprsentation objet des donnes et d'autre le stockage
relationnel des mmes donnes.
Par exemple, on peut trs bien imaginer qu'un schma entits-associations soit d'un ct
traduit en un schma relationnel puis implment dans une base de donnes Oracle ; tandis
qu'en parallle, il est traduit en un diagramme de classe (modle logique objet), lui-mme
implment dans un ensemble de classes Java. Ces classes Java permettent ensuite aux
dveloppeurs de construire des applications clientes orientes objet et qui attaquent de
manire transparente les donnes de la base Oracle. Il s'agit d'une solution de passage entre la
modlisation oriente objet (pertinente pour dvelopper des interfaces graphiques) et la
modlisation relationnelle (pertinente pour grer les donnes).

Par ailleurs, la mthodologie Merise est certes typiquement franaise, mais en Grande-
Bretagne, la mthodologie standard s'appelle SSADM (Structured Systems Analysis ans
Design Method) et repose sur les mmes principes. Les nord-amricains quant eux utilisent
ce qu'on appelle des diagrammes de flux, dont les principes sont repris par la version 2 de
Merise.

Aujourd'hui, ce sont les modlisations objets et leur unification UML (Unified Modeling
Language, autrement dit langage unifi de modlisation) qui se placent la pointe de l'tat de
l'art. Malheureusement, UML n'est qu'un ensemble de notations (d'ailleurs moins intuitives
que celles des schmas entits-associations). La connaissance de ce langage ne permet donc
pas au concepteur de faire l'conomie d'une mthodologie de conception. Voil pourquoi il
n'est pas anachronique de r-diter en 2005 un document sur des mthodes qui auront bientt
30 ans ;-)

VIII. Rfrences
[Akoka et Comyn-Wattiau]Akoka, J. et Comyn-Wattiau I. Conception de bases de donnes
relationnelles. Vuibert Informatique. Ce livre trs didactique contient de bons exercices sur la
phase de conception d'un systme d'information.

[Gabay] Gabay, J. Apprendre et pratiquer Merise. Masson, 1989. Ce livre trs synthtique
permet de s'exercer sur la mthode.

[Matheron]Matheron, J.-P. Comprendre Merise. Eyrolles, 1994. Cet ouvrage trs accessible
permet vraiment de comprendre la mthode.

[Nanci et al.] Nanci, D., Espinasse, B., Cohen, B. et Heckenroth, H. Ingnierie des systmes
d'information avec Merise. Sybex, 1992. Cet ouvrage complet dtaille la mthode dans son
ensemble.

[Panet et al.] Panet, G., Letouche, R. et Tardieu, H. Merise/2 : Modles et techniques Merise
avancs. dition d'organisation, 1994. Ce livre dcrit la version 2 de la mthode.

[Tardieu et al.] Tardieu, H., Rochfeld, A. et Coletti, R. La mthode Merise. Principes et outils.
dition d'organisation, 1986. Il s'agit-l du livre de rfrence par les auteurs de la mthode.