1. www.tifawt.com
www.tifawt.com
Conception d’une base de donn´es
e
Cyril Gruau ∗
17 octobre 2005 (corrig´ le 13 juillet 2006)
e
R´sum´
e
e
Ce support de cours regroupe quelques notions concernant le mod´lisation conceptuelle de syst`me
e
e
d’information par sch´ma entit´s-associations (via l’´tude des d´pendances fonctionnelles), la trae
e
e
e
duction en sch´ma relationnel et la d´marche inverse (r´tro-conception). Il pr´sente ´galement les
e
e
e
e
e
extensions majeures du mod`le conceptuel de donn´es.
e
e
Mots-clef : Merise, mod`le conceptuel, entit´, association, d´pendance fonctionnelle,
e
e
e
graphe de couverture minimale, sch´ma relationnel, traduction, r´tro-conception,
e
e
agr´gation, identifiant relatif, h´ritage
e
e
Compl´ments apport´s ` l’´dition de novembre 2003 :
e
e a e
–
–
–
–
–
–
une r´-´criture compl`te des r`gles de normalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
ee
e
e
un nouveau paragraphe sur les d´pendances fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
e
une r´-´criture compl`te de la section sur les agr´gations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
ee
e
e
idem pour les identifiants relatifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
et l’h´ritage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
e
auxquels s’ajoutent de nouveaux exemples et donc de nombreuses figures illustratives . . . . . . . . . 42
Remerciements
L’auteur tient ` exprimer toute sa gratitude envers Fr´d´ric Brouard pour son travail de correction
a
e e
sur ce document, ses judicieux conseils et son soutien en toutes circonstances.
∗
Cyril.Gruau@ensmp.fr
www.tifawt.com
1
3. www.tifawt.com
INTRODUCTION
3
Conclusion
41
R´f´rences
ee
41
Table des figures
42
Index
43
Introduction
Quand nous construisons directement les tables d’une base de donn´es dans un logiciel de gestion des
e
bases de donn´es (Oracle, SQL Server, DB2, Access, MySQL, PostGre, ...), nous sommes expos´s ` deux
e
e a
types de probl`me :
e
– 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 ` pr´voir les tables de jonction interm´diaires (par exemple, la table des ina e
e
terpr´tations qui est indispensable entre les tables des films et la table des acteurs).
e
Il est donc n´cessaire de recourir ` une ´tape pr´liminaire de conception.
e
a
e
e
´
Les techniques pr´sent´es ici font partie de la m´thodologie Merise (M´thode d’Etude et de R´alisation
e
e
e
e
e
Informatique pour les Syst`mes d’Entreprise) ´labor´e en France en 1978 [Tardieu et al.], qui permet noe
e
e
tamment de concevoir un syst`me d’information d’une fa¸on standardis´e et m´thodique.
e
c
e
e
Le but de ce support de cours est d’introduire le sch´ma entit´s-associations (section 1), le sch´ma
e
e
e
relationnel (sections 2 et 3) et d’expliquer la traduction entre les deux (sections 2.3 et 4). La construction
du sch´ma entit´s-associations peut se faire en ´tudiant les d´pendances fonctionnelles (section 1.3) et
e
e
e
e
en tenant compte d’un certain nombre d’extensions conceptuelles incontournables (section 5).
Ne sont malheureusement pas abord´s ici : les contraintes, les traitements, le langage relationnel et la
e
gestion de projet. Pour toutes ces notions importantes, car li´es ` la conception de syst`mes d’information,
e a
e
le lecteur est dirig´ vers [Akoka et Comyn-Wattiau, Matheron, Nanci et al.]. La mod´lisation objet ne
e
e
fait pas non plus partie des outils expos´s dans ce document.
e
www.tifawt.com
4. www.tifawt.com
`
´
MODELE CONCEPTUEL DE DONNEES (MCD)
1
1
4
Mod`le conceptuel de donn´es (MCD)
e
e
Avant de r´fl´chir au sch´ma relationnel d’une application, il est bon de mod´liser la probl´matique
e e
e
e
e
a
` traiter d’un point de vue conceptuel et ind´pendamment du logiciel utilis´.
e
e
1.1
Sch´ma entit´s-associations
e
e
La mod´lisation conceptuelle que nous proposons dans ce document pour un univers dont on veut stoe
cker les donn´es, conduit ` l’´laboration d’un type de sch´ma tr`s r´pandu, le sch´ma entit´s-associations.
e
a e
e
e e
e
e
1.1.1
Entit´s et associations
e
Une entit´ est une population d’individus homog`nes. Par exemple, les produits ou les articles vendus
e
e
par une entreprise peuvent ˆtre regroup´s dans une mˆme entit´ articles (figure 1), car d’un article
e
e
e
e
a
` l’autre, les informations ne changent pas de nature (` chaque fois, il s’agit de la d´signation, du prix
a
e
unitaire, etc.).
clients
-
articles
fournisseurs
numéro client
nom client
prénom
adresse client
...
- numéro article
- désignation
- prix unitaire
de vente
- ...
- n° fournisseur
- nom contact
- n° téléphone
contact
- ...
Fig. 1 – Entit´s
e
Par contre, les articles et les clients ne peuvent pas ˆtre regroup´s : leurs informations ne sont pas
e
e
homog`nes (un article ne poss`de pas d’adresse et un client ne poss`de pas de prix unitaire). Il faut donc
e
e
e
leur r´server deux entit´s distinctes : l’entit´ articles et l’entit´ clients.
e
e
e
e
Une association est une liaison qui a une signification pr´cise entre plusieurs entit´s. Dans notre
e
e
exemple, l’association commander est une liaison ´vidente entre les entit´s articles et clients, tandis
e
e
que l’association livrer ´tablit le lien s´mantique entre les entit´s articles et fournisseurs.
e
e
e
clients
-
numéro client
nom client
prénom
adresse client
...
commander
- quantité
commandée
- date de
commande
articles
- numéro article
- désignation
- prix unitaire
de vente
- ...
livrer
- quantité livrée
- date livraison
- nom livreur
fournisseurs
- n° fournisseur
- nom contact
- n° téléphone
contact
- ...
Fig. 2 – Associations
Remarquons que dans ce sch´ma, les entit´s clients et fournisseurs ne sont pas li´es directement,
e
e
e
mais indirectement, via l’entit´ articles, ce qui est assez naturel.
e
www.tifawt.com
5. www.tifawt.com
`
´
MODELE CONCEPTUEL DE DONNEES (MCD)
1
1.1.2
5
Attributs et identifiants
Un attribut est une propri´t´ d’une entit´ ou d’une association.
ee
e
Toujours dans notre exemple (figure 3), le prix unitaire est un attribut de l’entit´ articles, le nom
e
de famille est un attribut de l’entit´ clients, la quantit´ command´e est un attribut de l’association
e
e
e
commander et la date de livraison est un attribut de l’association livrer.
clients
-
numéro client
nom client
prénom
adresse client
...
commander
- quantité
commandée
- date de
commande
articles
- numéro article
- désignation
- prix unitaire
de vente
- ...
livrer
- quantité livrée
- date livraison
- nom livreur
fournisseurs
- n° fournisseur
- nom contact
- n° téléphone
contact
- ...
Fig. 3 – Attributs
Une entit´ et ses attributs ne doivent traiter que d’un seul sujet afin d’assurer une certaine coh´rence
e
e
au mod`le. Dans notre exemple, il est donc pr´f´rable de ne pas mettre les informations relatives aux
e
ee
fournisseurs dans l’entit´ des articles mais plutˆt dans une entit´ fournisseurs s´par´es (et li´e ` l’entit´
e
o
e
e e
e a
e
articles via l’association livrer).
Ensuite, chaque individu d’une entit´ doit ˆtre identifiable de mani`re unique. C’est pourquoi toutes
e
e
e
les entit´s doivent poss´der un attribut sans doublon (c’est-`-dire ne prenant pas deux fois la mˆme
e
e
a
e
valeur). Il s’agit de l’identifiant que l’on souligne sur le sch´ma, par convention. Le num´ro de client
e
e
constitue un identifiant classique pour l’entit´ clients (figure 4).
e
clients
-
numéro client
nom client
prénom
adresse client
...
commander
- quantité
commandée
- date de
commande
articles
- numéro article
- désignation
- prix unitaire
de vente
- ...
livrer
- quantité livrée
- date livraison
- nom livreur
Fig. 4 – Identifiants
Remarques :
e
e
– une entit´ poss`de au moins un attribut (son identifiant) ;
– au contraire, une association peut ˆtre d´pourvue d’attribut.
e
e
www.tifawt.com
fournisseurs
- n° fournisseur
- nom contact
- n° téléphone
contact
- ...
6. www.tifawt.com
`
´
MODELE CONCEPTUEL DE DONNEES (MCD)
1
1.1.3
6
Cardinalit´s
e
La cardinalit´ d’un lien entre une entit´ et une association pr´cise le minimum et le maximum de fois
e
e
e
qu’un individu de l’entit´ peut ˆtre concern´ par l’association.
e
e
e
Exemple : un client a au moins command´ un article et peut commander n articles (n ´tant ind´termin´),
e
e
e
e
tandis qu’un article peut avoir ´t´ command´ entre 0 et n fois (mˆme si ce n’est pas le mˆme n que
ee
e
e
e
pr´c´demment). On obtient alors le sch´ma entit´s-associations complet 1 (figure 5).
e e
e
e
clients
-
numéro client
nom client
prénom
adresse client
...
commander
- quantité
1,n
commandée
- date de
commande
articles
- numéro article
0,n - désignation
- prix unitaire
de vente
- ...
livrer
1,n - quantité livrée
- date livraison
- nom livreur
fournisseurs
- n° fournisseur
1,n - nom contact
- n° téléphone
contact
- ...
Fig. 5 – Cardinalit´s
e
Une cardinalit´ minimale de 1 doit se justifier par le fait que les individus de l’entit´ en question ont
e
e
besoin de l’association pour exister (un client n’existe pas avant d’avoir command´ quoique ce soit, donc
e
la cardinalit´ minimale de l’entit´ clients dans l’association commander est 1). Dans tous les autres cas,
e
e
la cardinalit´ minimale vaut 0 (c’est le cas pour une liste pr´-´tablie d’articles par exemple).
e
ee
Ceci dit, la discussion autour d’une cardinalit´ minimale 0 ou 1 n’est vraiment int´ressante que lorsque
e
e
la cardinalit´ maximale est 1. Nous verrons en effet lors de la traduction vers un sch´ma relationnel (sece
e
tion 2.3), que lorsque la cardinalit´ maximale est n, nous ne pouvons pas faire la diff´rence entre une
e
e
cardinalit´ minimale de 0 et une cardinalit´ minimale de 1.
e
e
Notons que sur notre exemple, un article peut ˆtre command´ par plusieurs clients. Cela provient du
e
e
fait que tous les crayons rouges ne sont pas num´rot´s individuellement, mais portent un num´ro d’article
e e
e
collectif. En toute rigueur, notre entit´ articles aurait du s’appeler types d’article. Ainsi, un crayon
e
rouge peut ˆtre command´ par plusieurs clients, ce n’est simplement pas le mˆme crayon ` chaque fois.
e
e
e
a
Il s’agit d’un choix de mod´lisation, le lecteur peut tr`s l´gitimement faire le choix inverse qui consiste `
e
e e
a
num´roter individuellement chaque crayon rouge.
e
La seule difficult´ pour ´tablir correctement les cardinalit´s est de se poser les questions dans le bon
e
e
e
sens. Autour de l’association commander, par exemple :
– cˆt´ clients, la question est ( un client peut commander combien d’articles ? ) et la r´ponse est
oe
(
)
e
(( entre 1 et plusieurs ) ;
)
– cˆt´ articles, la question est ( un article peut ˆtre command´ par combien de client ? ) et cette
oe
(
e
e
)
fois-ci, la r´ponse est ( entre 0 et plusieurs )
e
(
).
1. Le lecteur avis´ aura not´ que le sch´ma de la figure 5 comporte des erreurs de conception. Ces erreurs seront corrig´es
e
e
e
e
dans la section 1.2 d´di´e ` la normalisation des sch´mas entit´s-associations.
e e a
e
e
www.tifawt.com
7. 1
www.tifawt.com
`
´
MODELE CONCEPTUEL DE DONNEES (MCD)
1.1.4
7
Associations plurielles
Deux mˆmes entit´s peuvent ˆtre plusieurs fois en association (c’est le cas sur la figure 6).
e
e
e
posséder
- date
d’acquisition
- prix achat
0,n
personnes
-
n° personnel
nom
prénom
...
0,1
0,n
résider
principalement
- date d’entrée
- montant du
loyer
1,1
logements
0,n
- n° logement
- adresse
- ...
0,n
résider
secondairement
- date d’entrée
- montant du loyer
Fig. 6 – Associations plurielles
Dans cet exemple issu d’une agence immobili`re, une personne peut ˆtre propri´taire, r´sider princie
e
e
e
palement ou r´sider secondairement dans un logement g´r´ par l’agence. Les logements qui ne sont pas
e
ee
g´r´s par l’agence ne figurent pas dans l’entit´s des logements, ce qui explique certaines cardinalit´s 0 du
ee
e
e
sch´ma. Nous supposons ´galement qu’un logement n’est d´tenu que par une seule personne et que ce
e
e
e
propri´taire figure obligatoirement dans l’entit´ des personnes.
e
e
1.1.5
Association r´flexive
e
Il est permis ` une association d’ˆtre branch´e plusieurs fois ` la mˆme entit´, comme par exemple
a
e
e
a
e
e
l’association binaire r´flexive de la figure 7.
e
diriger
- date début
0,n
0,1
employés
-
n° employé
nom
fonction
adresse
...
Fig. 7 – Association r´flexive
e
Dans cet exemple, tout employ´ est dirig´ par un autre employ´ (sauf le directeur g´n´ral) et un
e
e
e
e e
employ´ peut diriger plusieurs autres employ´s, ce qui explique les cardinalit´s sur le sch´ma.
e
e
e
e
www.tifawt.com
8. 1
`
´
MODELE CONCEPTUEL DE DONNEES (MCD)
1.1.6
www.tifawt.com
8
Associations non binaires
Lorsqu’autour d’une entit´, toutes les associations ont pour cardinalit´s maximales 1 au centre et n
e
e
a
` l’ext´rieur, cette entit´ est candidate pour ˆtre remplac´e par une association branch´e ` toutes les
e
e
e
e
e a
entit´s voisines avec des cardinalit´s identiques 0,n.
e
e
La deuxi`me condition qu’il faut imp´rativement satisfaire est la r`gle de normalisation des attributs
e
e
e
des associations (section suivante). Cette r`gle conduit parfois ` l’apparition d’associations qui ´tablissent
e
a
e
un lien s´mantique entre 3 entit´s ou plus.
e
e
Sur l’exemple de la figure 8 issu d’un cin´ma, l’entit´ projections est uniquement entour´e d’assoe
e
e
ciations dont les cardinalit´s maximales sont 1 cˆt´ projections et n de l’autre cˆt´. De plus, la donn´e
e
oe
oe
e
2 . On peut donc la remd’un cr´neau, d’un film et d’une salle suffit ` d´terminer une projection unique
e
a e
placer par une association projeter branch´e aux trois entit´s salles, cr´neaux horaires et films.
e
e
e
On parle alors d’association ternaire.
Fig. 8 – Entit´ rempla¸able par une association ternaire
e
c
2. sans la date dans l’entit´ cr´neaux horaires, la donn´e d’un cr´neau, d’un film et d’une salle aurait d´termin´ plusieurs
e e
e
e
e
e
projections et l’association ternaire n’aurait pas pu se faire
www.tifawt.com
9. 1
www.tifawt.com
`
´
MODELE CONCEPTUEL DE DONNEES (MCD)
9
La difficult´ de concevoir une association ternaire (ou plus) directement est d’´tablir les bonnes care
e
dinalit´s. Il est donc conseill´ d’en passer par un sch´ma entit´s-associations dans lequel on ne trouve
e
e
e
e
que des associations binaires, puis de rep´rer les entit´s rempla¸ables par des associations, comme sur la
e
e
c
figure 8 ` gauche.
a
Cette r`gle de conduite permet d’´viter d’introduire une association ternaire abusive, par exemple
e
e
entre les avions, les pilotes et les vols (figure 9), car le concepteur peut s’apercevoir que l’une des cardinalit´s maximales ne convient pas.
e
avions
0,n -
utiliser
1,1
vols
- numéro vol
- heure de départ
prévue
- heure d’arrivée
prévue
numéro avion
date mise en service
modèle
propriétaire
départs
0,n
correspondre
- numéro départ
1,1 - date
- heure de départ
effective
1,n
assurer
pilotes
0,n - numéro pilote
- nom
- grade
Fig. 9 – Contre-exemple : l’entit´ d´parts n’est pas rempla¸able par une association ternaire
e e
c
Par ailleurs, une association peut ˆtre branch´e ` plus de trois entit´s, comme sur la figure 10. L`e
e a
e
a
encore, le conseil pour ˆtre sˆr de la l´gitimit´ de cette association 4-aire, est de v´rifier les cardinalit´s
e
u
e
e
e
e
sur un sch´ma interm´diaire faisant apparaˆ ` la place, une entit´ occupations et quatre associations
e
e
ıtre a
e
binaires.
jours
dans la semaine
- n° jour
- jour
0,n
semaines
dans l’année
- n° semaine
- date de début
occuper
0,n
- motif
0,n
0,n
créneaux horaires
dans la journée
- n° créneau
- heure de début
salles
- n° salle
- capacité
Fig. 10 – Exemple d’entit´ quaternaire ou 4-aire
e
www.tifawt.com
10. 1
www.tifawt.com
`
´
MODELE CONCEPTUEL DE DONNEES (MCD)
1.2
10
R`gles de normalisation
e
Un bon sch´ma entit´s-associations doit r´pondre ` 9 r`gles de normalisation, que le concepteur doit
e
e
e
a
e
connaˆ par cœur.
ıtre
1.2.1
Les bonnes mani`res dans un sch´ma entit´s-associations
e
e
e
Normalisation des entit´s (importante) : toutes les entit´s qui sont rempla¸ables par une associae
e
c
tion doivent ˆtre remplac´es (comme sur la figure 8).
e
e
Normalisation des noms : le nom d’une entit´, d’une association ou d’un attribut doit ˆtre unique.
e
e
Conseils :
– pour les entit´s, utiliser un nom commun au pluriel (par exemple : clients) ;
e
– pour les associations, utiliser un verbe ` l’infinitif (par exemple : effectuer, concerner) ´ventuellement
a
e
a
` la forme passive (ˆtre command´) et accompagn´ d’un adverbe (avoir lieu dans, pendant, `) ;
e
e
e
a
– pour les attributs, utiliser un nom commun singulier (par exemple : nom, num´ro, libell´, descripe
e
tion) ´ventuellement accompagn´ du nom de l’entit´ ou de l’association dans laquelle il se trouve
e
e
e
(par exemple : nom de client, num´ro d’article).
e
Remarque : lorsqu’il reste plusieurs fois le mˆme nom, c’est parfois symptomatique d’une mod´lisation
e
e
qui n’est pas termin´e (figure 11(a)) ou le signe d’une redondance (figure 11(b)).
e
étudiants
-
n° étudiant
nom
prénom
adresse
enseignants
-
personnes
n° enseignant
nom
prénom
adresse
-
fusion
n° personnel
nom
prénom
adresse
(a) Deux entit´s homog`nes peuvent ˆtre fusionn´es
e
e
e
e
clients
- numéro client
- nom client
- adresse de
livraison
commandes
passer
1,n
1,1
- n° commande
- date commande
- adresse de
livraison
redondance, donc risque d’incohérence
(b) Si deux attributs contiennent les mˆmes informations, alors
e
la redondance induit non seulement un gaspillage d’espace mais
´galement un grand risque d’incoh´rence : ici, les adresses risquent
e
e
de ne pas ˆtre les mˆmes et dans ces conditions, o` faut-il livrer
e
e
u
?
Fig. 11 – Contre-exemples de la normalisation des noms
www.tifawt.com
11. 1
www.tifawt.com
`
´
MODELE CONCEPTUEL DE DONNEES (MCD)
11
Normalisation des identifiants : chaque entit´ doit poss´der un identifiant.
e
e
Conseils :
– ´viter les identifiants compos´s de plusieurs attributs (comme par exemple un identifiant form´ par
e
e
e
les attributs nom et pr´nom), car d’une part c’est mauvais pour les performances et d’autres part,
e
l’unicit´ suppos´e par une telle d´marche finit tˆt ou tard par ˆtre d´mentie ;
e
e
e
o
e
e
– pr´f´rer un identifiant court pour rendre la recherche la plus rapide possible (´viter notamment les
ee
e
chaˆ
ınes de caract`res comme un num´ro de plaque d’immatriculation, un num´ro de s´curit´ sociale
e
e
e
e
e
3) ;
ou un code postal
– ´viter ´galement les identifiants susceptibles de changer au cours du temps (comme les plaques
e
e
d’immatriculation ou les num´ros de s´curit´ sociale provisoires).
e
e
e
Conclusion : l’identifiant sur un sch´ma entit´s-associations (et donc la future cl´ primaire dans le sch´ma
e
e
e
e
relationnel) doit ˆtre un entier, de pr´f´rence incr´ment´ automatiquement 4 .
e
ee
e
e
Normalisation des attributs (importante) : remplacer les attributs en plusieurs exemplaires en une
association suppl´mentaire de cardinalit´s maximales n et ne pas ajouter d’attribut calculable ` partir
e
e
a
d’autres attributs.
En effet, d’une part, les attributs en plusieurs exemplaires posent des probl`mes d’´volutivit´ du
e
e
e
mod`le (sur la figure 12(a) ` gauche, comment faire si un employ´ a deux adresses secondaires ?) et
e
a
e
occuper
employés
employés
-
n° employé
nom
adresse principale
adresse secondaire
n° téléphone domicile
n° téléphone portable
- n° employé
- nom
1,n
normalisation
posséder
1,n
- type
adresses
1,n
- n° adresse
- adresse
numéros de tél.
1,n - n° de n° de tél.
- n° de téléphone
- fixe ou portable
(a) Attributs en plusieurs exemplaires remplac´s par une association suppl´mentaire
e
e
commandes
- n° commande
- date commande
- montant total
figurer
1,n
- quantité
articles
- numéro article
0,n - désignation
- prix unitaire
de vente
calculable à partir de
(b) Attribut calculable qu’il faut retirer du sch´ma
e
Fig. 12 – Contre-exemples de la normalisation des attributs
d’autre part, les attributs calculables induisent un risque d’incoh´rence entre les valeurs des attributs de
e
3. Un num´ro de s´curit´ sociale, un code postal ou un num´ro de t´l´phone sont bien des chaˆ
e
e
e
e
ee
ınes de caract`res, mˆme
e
e
si elles ne comportent que des chiffres, tout simplement parce que ces num´ros peuvent commencer par un 0, ce qui, en
e
informatique, n’est pas possible avec un entier.
4. Le seul inconv´nient de cette num´rotation arbitraire est qu’il devient possible ` une table de poss´der deux fois la
e
e
a
e
mˆme ligne (avec deux num´ros diff´rents). Le conseil reste pourtant largement avantageux
e
e
e
www.tifawt.com
12. www.tifawt.com
`
´
MODELE CONCEPTUEL DE DONNEES (MCD)
1
12
base et celles des attributs calcul´s, comme sur la figure 12(b).
e
D’autres d’attributs calculables classiques sont ` ´viter, comme l’ˆge (qui est calculable ` partir de
ae
a
a
la date de naissance) ou encore le d´partement (calculable ` partir d’une sous-chaˆ du code postal).
e
a
ıne
Normalisation des attributs des associations (importante) : les attributs d’une association
doivent d´pendre directement des identifiants de toutes les entit´s en association.
e
e
Par exemple, sur la figure 5 la quantit´ command´e d´pend ` la fois du num´ro de client et du
e
e e
a
e
num´ro d’article, par contre la date de commande non. Il faut donc faire une entit´ commandes ` part,
e
e
a
idem pour les livraisons (figure 13).
clients
-
- quantité
commandée
- numéro article
0,n - désignation
- prix unitaire
de vente
fournisseurs
concerner (2)
1,n
1,n
commandes
1,!
- n° fournisseur
- nom contact
- n° téléphone
contact
- quantité livrée
1,n
1,n
passer
articles
concerner (1)
numéro client
nom client
prénom
adresse client
livraisons
- n° commande
- date commande
- n° livraison
- date de
livraison
1,n
livrer
1,!
- nom du livreur
Fig. 13 – Normalisation des attributs des associations
L’inconv´nient de cette r`gle de normalisation est qu’elle est difficile ` appliquer pour les associations
e
e
a
qui ne poss`dent pas d’attribut. Pour v´rifier malgr´ tout qu’une association sans attribut est bien nore
e
e
malis´e, on peut donner temporairement ` cette association un attribut imaginaire (mais pertinent) qui
e
a
permet de v´rifier la r`gle.
e
e
Par exemple, entre les entit´s livres et auteurs de la figure 16, l’association ´crire ne poss`de pas
e
e
e
d’attribut. Imaginons que nous ajoutions un attribut pourcentage qui contient le pourcentage du livre
´crit par chaque auteur (du mˆme livre). Comme cet attribut pourcentage d´pend ` la fois du num´ro
e
e
e
a
e
de livre et du num´ro d’auteur, l’association ´crire est bien normalis´e.
e
e
e
Autre cons´quence de la normalisation des attributs des associations : une entit´ avec une cardinalit´
e
e
e
de 1,1 ou 0,1 aspire les attributs de l’association (figure 14).
fournisseurs
- n° fournisseur
- nom contact
- n° téléphone
contact
livraisons
livrer
1,n
- nom du livreur
1,1
- n° livraison
- date de
livraison
-
cet attribut passe ici
Fig. 14 – Cardinalit´ 1,1 et attributs d’une association
e
www.tifawt.com
13. 1
www.tifawt.com
`
´
MODELE CONCEPTUEL DE DONNEES (MCD)
13
Normalisation des associations (importante) : il faut ´liminer les associations fantˆmes (figure 15(a)),
e
o
redondantes (figure 15(b)) ou en plusieurs exemplaires (figure 15(c)).
fournisseurs
1,1
- n° fournisseur
- nom fournisseur
- adresse
fournisseurs
-
travailler chez
fusion
contacts
- n° contact
- nom du contact
- n° téléphone
du contact
1,1
n° fournisseur
nom fournisseur
adresse
nom du contact
n° téléphone
du contact
(a) les cardinalit´s sont toutes 1,1 donc c’est une association fantˆme
e
o
règlements
payer
0,n
clients
- numéro client
- nom client
0,n
1,1 - n° règlement
- date règlement
- montant
factures
recevoir
1,1
correspondre
0,n
1,1 - n° facture
- date facture
- montant total
(b) si un client ne peut pas r´gler la facture d’un autre client, alors l’association
e
payer est inutile et doit ˆtre supprim´e (dans le cas contraire, l’association payer
e
e
doit ˆtre maintenue)
e
joueurs de tennis
0,n
joueur 1
n° joueur
nom
genre
classement
0,n
joueur 2
1,1
joueurs de tennis
1,1
-
0,n
0,n
0,n
co-équipier 1
0,1
n° joueur
nom
genre
classement
co-équipier 2
jouer
normalisation
0,1
matchs de tennis
- n° match
- date
2,4 ou plutôt 1,n
matchs de tennis
- n° match
- date
(c) une association suffit pour remplacer les 4 associations participer en tant que ...
Fig. 15 – Contre-exemples de la normalisation des associations
www.tifawt.com
14. www.tifawt.com
`
´
MODELE CONCEPTUEL DE DONNEES (MCD)
1
14
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 dur´es de vie diff´rentes. Siea
e
e
non, il faut supprimer le chemin le plus court, car il est d´ductible ` partir de l’autre chemin. Dans notre
e
a
exemple de la figure 15(b), si on supprime l’association payer, on peut retrouver le client qui a pay´ le
e
r`glement en passant par la facture qui correspond.
e
Remarque : une autre solution pour le probl`me de la figure 15(b) consiste ` retirer l’entit´ r`glements
e
a
e e
et d’ajouter une association r´gler avec les mˆmes attributs (sauf l’identifiant) entre les entit´s clients
e
e
e
et factures.
Normalisation des cardinalit´s : une cardinalit´ minimale est toujours 0 ou 1 (et pas 2, 3 ou n)
e
e
et une cardinalit´ maximale est toujours 1 ou n (et pas 2, 3, ...).
e
Cela signifie que si une cardinalit´ maximale est connue et vaut 2, 3 ou plus (comme sur la figure 15(c) `
e
a
droite, ou pour un nombre limit´ d’emprunts dans une biblioth`que), alors nous consid´rons quand mˆme
e
e
e
e
qu’elle est ind´termin´e et vaut n. Cela se justifie par le fait que mˆme si nous connaissons n au moment
e
e
e
de la conception, il se peut que cette valeur ´volue au cours du temps. Il vaut donc mieux consid´rer n
e
e
comme une inconnue d`s le d´part.
e
e
Cela signifie ´galement qu’on ne mod´lise pas les cardinalit´s minimales qui valent plus de 1 car ce
e
e
e
genre de valeur est aussi amen´e ` ´voluer. Par ailleurs, avec une cardinalit´ maximale de 0, l’association
e ae
e
n’aurait aucune signification.
Dans un SGBD relationnel, nous pourrions assurer les cardinalit´s valant 2, 3 ou plus, via l’utilisation
e
de d´clencheurs. Mais cette notion n’est pas abord´e dans ce document qui se contente, au contraire, de
e
e
d´crire ce qu’il est possible de faire sans utiliser de d´clencheur.
e
e
1.2.2
Les formes normales
`
A ces 6 r`gles de normalisation, il convient d’ajouter les 3 premi`res formes normales traditionnele
e
lement ´nonc´es pour les sch´mas relationnels, mais qui trouvent tout aussi bien leur place en ce qui
e
e
e
concerne les sch´mas entit´s-associations.
e
e
Premi`re forme normale : ` un instant donn´ dans une entit´, pour un individu, un attribut ne
e
a
e
e
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´ suppl´mentaire,
e
e
en association avec la premi`re (figure 16).
e
livres
-
numéro livre
titre
auteurs
éditeur
nombre de pages
année
livres
1
ère
forme normale
-
numéro livre
titre
éditeur
nombre de pages
année
écrire
1,n
auteurs
1,n - numéro auteur
- nom
Fig. 16 – Application de la premi`re forme normale : il peut y avoir plusieurs auteurs pour un livre donn´
e
e
www.tifawt.com
15. 1
www.tifawt.com
`
´
MODELE CONCEPTUEL DE DONNEES (MCD)
15
Deuxi`me forme normale : l’identifiant peut ˆtre compos´ de plusieurs attributs mais les autres
e
e
e
attributs de l’entit´ doivent d´pendre de l’identifiant en entier (et non pas une partie de cet identifiant).
e
e
Cette deuxi`me forme normales peut ˆtre oubli´e si on suit le conseil de n’utiliser que des identifiants
e
e
e
non compos´s et de type entier. En v´rit´, elle a ´t´ vid´e de sa substance par la r`gle de normalisation
e
e e
ee
e
e
des attributs des associations (page 12).
Consid´rons malgr´ tout le contre-exemple suivant : dans une entit´ clients dont l’identifiant est
e
e
e
compos´ des attributs nom et pr´nom, la date de fˆte d’un client ne d´pend pas de son identifiant en
e
e
e
e
entier mais seulement de pr´nom. Elle ne doit pas figurer dans l’entit´ clients, il faut donc faire une
e
e
entit´ calendrier ` part, en association avec l’entit´ clients.
e
a
e
Troisi`me forme normale de Boyce-Codd (importante) : tous les attributs d’une entit´ doivent
e
e
d´pendre directement de son identifiant et d’aucun autre attribut.
e
Si ce n’est pas le cas, il faut placer l’attribut pathologique dans une entit´ s´par´e, mais en association
e e e
avec la premi`re.
e
num´ro avion
e
1
2
3
constructeur
Airbus
Boeing
Airbus
mod`le
e
A380
B747
A380
capacit´
e
180
314
180
propri´taire
e
Air France
British Airways
KLM
Tab. 1 – Il y a redondance (et donc risque d’incoh´rence) dans les colonnes constructeur et capacit´
e
e
Par exemple, l’entit´ avions (figure 17 ` gauche) dont les valeurs sont donn´es dans le tableau 1,
e
a
e
n’est pas en troisi`me forme normale de Boyce-Codd, car la capacit´ et le constructeur d’un avion
e
e
ne d´pendent pas du num´ro d’avion mais de son mod`le. La solution normalis´e est donn´e figure 17 `
e
e
e
e
e
a
droite.
avions
-
modèles d’avion
numéro avion
constructeur
modèle
capacité
propriétaire
avions
3ème forme normale
- numéro avion
- propriétaire
être du
1,n
1,n -
numéro modèle
modèle
constructeur
capacité
Fig. 17 – Application de la troisi`me forme normale de Boyce-Codd
e
www.tifawt.com
16. 1
www.tifawt.com
`
´
MODELE CONCEPTUEL DE DONNEES (MCD)
1.3
16
D´pendances fonctionnelles
e
Pour ´tablir efficacement un mod`le entit´s-associations bien normalis´, on peut ´tudier au pr´alable
e
e
e
e
e
e
les d´pendances fonctionnelles entre les attributs puis, les organiser en graphe de couverture minimale.
e
Cette technique est traditionnellement employ´e pour normaliser des sch´mas relationnels, mais elle
e
e
s’applique tr`s bien en amont, au niveau des mod`les conceptuels.
e
e
1.3.1
D´finitions et propri´t´s
e
e e
Un attribut Y d´pend fonctionnellement d’un attribut X si et seulement si une valeur de X induit
e
une unique valeur de Y . On note une d´pendance fonctionnelle par une fl`che simple : X → Y .
e
e
Par exemple, si X est le num´ro de client et Y le nom de client, alors on a bien X → Y . Par contre,
e
on a pas Y → X, car plusieurs clients de num´ros diff´rents peuvent porter le mˆme nom.
e
e
e
Transitivit´ : si X → Y et Y → Z alors X → Z.
e
Par exemple, on a num´ro de commande → num´ro de client → nom de client, donc on a aussi
e
e
num´ro de commande → nom de client. Mais la d´pendance fonctionnelle num´ro de commande → nom
e
e
e
de client est dite transitive, car il faut passer par le num´ro de client pour l’obtenir.
e
Au contraire, la d´pendance fonctionnelle num´ro de client → nom de client est directe . Seules
e
e
les d´pendances fonctionnelles directes nous int´ressent. D’autres exemples sont donn´es dans le tableau 2.
e
e
e
d´pendance fonctionnelle
e
num´ro de livraison → date de livraison
e
num´ro de livraison → num´ro du fournisseur
e
e
num´ro du fournisseur → nom du fournisseur
e
num´ro de livraison → nom du fournisseur
e
directe ?
oui
oui
oui
non
Tab. 2 – Exemples de d´pendances fonctionnelles
e
Un attribut Y peut avoir une d´pendance fonctionnelle qui repose sur la conjonction de plusieurs attrie
buts, auquel cas la d´pendance est dite non ´l´mentaire . Les d´pendances fonctionnelles non ´l´mentaires
e
ee
e
ee
sont not´es par une fl`che unique mais comportant plusieurs points d’entr´e (regroup´s autour d’un
e
e
e
e
cercle).
Par exemple, la quantit´ command´e (d’un article dans une commande) d´pend de deux attributs :
e
e
e
le num´ro de commande et le num´ro d’article (figure 18). Notons que cette d´pendance num´ro de
e
e
e
e
commande + num´ro d’article → quantit´ est ` la fois non ´l´mentaire et directe.
e
e
a
ee
numéro de commande
quantité commandée
numéro d’article
Fig. 18 – D´pendance fonctionnelle non ´l´mentaire, mais directe
e
ee
www.tifawt.com
17. 1
www.tifawt.com
`
´
MODELE CONCEPTUEL DE DONNEES (MCD)
1.3.2
17
Graphe de couverture minimale
En repr´sentant tous les attributs et toutes les d´pendances fonctionnelles directes entre eux, nous
e
e
obtenons un r´seau appel´ graphe de couverture minimale. Dans notre exemple sur les clients, les come
e
mandes et les articles, ce graphe est donn´ sur la figure 19.
e
numéro de commande
numéro de client
numéro d’article
date de commande
désignation
quantité commandée
nom du client
adresse du client
Fig. 19 – Graphe de couverture minimale
La technique de traduction en un sch´ma entit´s-associations qui suit, suppose qu’aucun attribut n’a
e
e
´t´ oubli´ sur le graphe de couverture minimal et notamment, aucun identifiant. D’ailleurs toutes les
ee
e
d´pendances fonctionnelles du graphe doivent partir d’un identifiant. Si ce n’est pas le cas, c’est qu’un
e
identifiant a ´t´ omis.
ee
1.3.3
Traduction vers un sch´ma entit´s-associations
e
e
`
A partir du graphe de couverture minimale (figure 19), le sch´ma entit´s-associations normalis´ core
e
e
respondant apparaˆ naturellement (figure 20), en suivant quelques ´tapes simples.
ıt
e
numéro de commande
numéro de client
numéro d’article
date de commande
désignation
quantité commandée
nom du client
adresse du client
Fig. 20 – Identification des entit´s et des associations sur un graphe de couverture minimale
e
´
Etape 1 : il faut rep´rer et souligner les identifiants.
e
´
Etape 2 : puis tous les attributs non identifiant qui d´pendent directement d’un identifiant et d’un
e
seul, forment une entit´ (avec l’identifiant, bien sˆr).
e
u
´
Etape 3 : ensuite, les d´pendances ´l´mentaires entre les identifiants forment des associations binaires
e
ee
dont les cardinalit´s maximales sont 1 au d´part de la d´pendance fonctionnelle et n ` l’arriv´e.
e
e
e
a
e
´
Etape 4 : sauf si entre deux identifiants se trouvent deux d´pendances ´l´mentaires r´flexives 5 , aue
ee
e
quel cas l’association binaire a deux cardinalit´s maximales valant 1.
e
5. c’est ` cause de cette ´tape 4 qu’il est pr´f´rable de ne pas traduire directement le graphe de couverture minimale en
a
e
ee
un sch´ma relationnel, cf. les commentaires de la r`gle 4 page 25
e
e
www.tifawt.com
18. 1
www.tifawt.com
`
´
MODELE CONCEPTUEL DE DONNEES (MCD)
18
´
Etape 5 : enfin, les attributs (non identifiants) qui d´pendent de plusieurs identifiants sont les attrie
buts d’une association suppl´mentaire dont les cardinalit´s maximales sont toutes n.
e
e
La traduction du graphe de couverture minimale de la figure 20 en un sch´ma entit´s-associations
e
e
normalis´ est donn´e sur la figure 21.
e
e
passer
commandes
1,1
articles
- n° commande
- date commande
- numéro article
- désignation
1,n
1,n
clients
-
0,n
concerner
numéro client
nom client
prénom
adresse client
- quantité
commandée
Fig. 21 – Sch´ma entit´s-associations normalis´ obtenu ` partir du graphe de couverture minimale
e
e
e
a
Dans ce genre de traduction, il faut donner un nom aux entit´s et aux associations, car ce n’est pas
e
le cas sur le graphe de couverture minimale et il reste les cardinalit´s minimales ` ´tablir.
e
ae
Remarquons ´galement qu’en r´alit´, il faut d´j` connaˆ les entit´s en pr´sence pour ´tablir core
e e
ea
ıtre
e
e
e
rectement 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 entit´s et pour normaliser
e
e
les entit´s et leurs associations (jusqu’en troisi`me forme normale de Boyce-Codd).
e
e
1.3.4
Gestion des dates et du caract`re historique
e
Dans une biblioth`que, on peut vouloir stocker les emprunts en cours (figure 22) et/ou les emprunts
e
historiques (figure 23). Pour les emprunts en cours, la date de retour pr´vu est un attribut de l’entit´
e
e
numéro de livre
livres
traduction
titre
date d’
emprunt
date de
retour prévu
numéro de membre
nom
-
n° livres
titre
date d’emprunt
date retour prévu
emprunts en
0,1
cours
membres
0,n - n° membre
- nom
- adresse
adresse
Fig. 22 – Sans historisation des emprunts, pas de probl`me
e
livres car un livre ne peut faire l’objet que d’un seul emprunt en cours. Dans ce cas, l’´tablissement du
e
graphe de couverture minimal ne pose aucun probl`me.
e
www.tifawt.com
19. 1
www.tifawt.com
`
´
MODELE CONCEPTUEL DE DONNEES (MCD)
19
Par contre, un livre peut faire l’objet de plusieurs emprunts historiques et dans ces conditions, la date
d’emprunt est d´terminante pour connaˆ
e
ıtre la date de retour pr´vue (figure 23 en haut ` gauche). Or
e
a
6 et une d´pendance fonctionnelle ne peut partir que d’un ou plusieurs
une date n’est pas un identifiant
e
identifiant(s). C’est le signe qu’il manque un identifiant : le num´ro d’emprunt (figure 23 en haut ` droite).
e
a
numéro de livre
numéro de livre
date d’emprunt
date d’emprunt
numéro d’emprunt
correction
titre
date de
retour prévu
date de
retour
effectif
numéro de membre
nom
titre
date de
retour prévu
- n° livre 0,n
- titre
concerner
1,1
adresse
n
ctio
adu
r
emprunts historiques
-
numéro de membre
nom
adresse
t
livres
date de
retour
effectif
numéro d’emprunt
date d’emprunt
date de retour prévu
date retour effectif
1,1
avoir
effectuer
membres
0,n - n° membre
- nom
- adresse
Fig. 23 – Mˆme pour une entit´ historis´e, il vaut mieux ´viter que la date n’entre dans l’identifiant
e
e
e
e
Notons que l’entit´ emprunts historiques suppl´mentaire qui apparaˆ apr`s traduction (figure 23
e
e
ıt
e
en bas) ne peut pas ˆtre transform´e en une association comme on pourrait le croire au simple examen
e
e
des cardinalit´s qui l’entourent. En effet, les attributs de l’association qui en r´sulterait ne v´rifieraient
e
e
e
pas la normalisation des attributs des associations. Notamment, la date de retour effectif ne d´pend pas
e
du num´ro de livre et du num´ro de membre, mais du num´ro de livre et de la date d’emprunt.
e
e
e
`
La normalisation des entit´s ne s’applique donc pas aux entit´s qui ont un caract`re historique. A
e
e
e
moins que les dates ne soient regroup´es dans une entit´ s´par´e, ce qui n’est pas conseill´ tant qu’aucune
e
e e e
e
information li´e aux dates (comme le caract`re f´ri´, par exemple) n’est n´cessaire.
e
e e e
e
6. Si on suit le pr´cieux conseil de n’utiliser que des entiers arbitraires et auto-incr´ment´s comme identifiant.
e
e
e
www.tifawt.com
20. 1
www.tifawt.com
`
´
MODELE CONCEPTUEL DE DONNEES (MCD)
1.3.5
20
D´pendances plurielles et r´flexives
e
e
Une ou plusieurs d´pendances fonctionnelles peuvent partir ou arriver plusieurs fois du mˆme attrie
e
but. Pour clarifier la signification de chaque d´pendance fonctionnelle, on peut ajouter un commentaire
e
sur la fl`che (figure 24). Ce commentaire sert ensuite ` donner un nom aux associations correspondantes.
e
a
père mère
médecin remplacé
numéro de médecin
numéro de remplacement
numéro personnel
médecin remplaçant
adresse
professionnelle
nom
date de
début
date de
fin
nom
(a) d´pendances plurielles
e
prénom
(b) d´pendances r´flexives
e
e
Fig. 24 – D´pendances fonctionnelles comment´es
e
e
Les d´pendances fonctionnelles plurielles entre les m´decins et le remplacements (figure 24(a)) dee
e
viennent, apr`s traduction, des associations plurielles entre les entit´s m´decins et remplacements. Noe
e e
tons que l’entit´ remplacements ainsi g´n´r´e, a aussi un caract`re historique.
e
e ee
e
Les fonctionnelles r´flexives (X → X), quoique toujours vraies, ne pr´sentent aucun int´rˆt, ` moins
e
e
ee a
qu’elles aient une signification particuli`re. Un exemple de d´pendance r´flexive licite sur un graphe de
e
e
e
couverture minimale est la d´pendance fonctionnelle personne → personne, lorsqu’elle signifie ( diriger )),
e
(
( ˆtre en couple avec ) ou ( ˆtre le p`re ou la m`re de ) (figure 24(b)).
(e
)
(e
e
e
)
Dans le mˆme ordre d’id´e, il est inutile de faire figurer sur le graphe de couverture minimal des
e
e
d´pendances fonctionnelles non ´l´mentaires vraies, mais idiotes, comme par exemple num´ro de commande
e
ee
e
+ num´ro d’article → num´ro de commande.
e
e
1.3.6
Associations sans attributs
La lacune majeure de cette m´thode reste tout de mˆme le fait que les associations dont toutes les
e
e
cardinalit´s maximales sont n mais qui sont sans attribut ne figurent pas sur le graphe de couverture
e
minimale. Il faut alors, soit leur inventer temporairement un attribut (comme pour la normalisation
des attributs des associations), soit introduire une notation sp´ciale (par exemple, une d´pendance non
e
e
´l´mentaire qui ne d´bouche sur aucun attribut).
ee
e
Pour illustrer ce d´faut, prenons l’exemple des films et des acteurs (figure 25). Il n’y a pas d’attribut
e
numéro de film
titre
durée
numéro d’acteur
nom de scène
films
traduction
date de naissance
- n° film
- titre
- durée
jouer dans
0,n
acteurs
0,n - numéro acteur
- nom de scène
- date naissance
Fig. 25 – Utilisation d’une d´pendance non ´l´mentaire et sans enfant sur un graphe de couverture
e
ee
minimal
qui d´pende ` la fois du num´ro de film et du num´ro d’acteur (` moins d’imaginer le temps d’apparition
e
a
e
e
a
a e
` l’´cran). Et pourtant, les deux entit´s films et acteurs sont en association. Grˆce ` la d´pendance
e
a a
e
non ´l´mentaire et sans enfant, on peut rendre compte de cette situation sur le graphe de couverture
ee
minimale et faire ainsi apparaˆ l’association sur le sch´ma entit´s-associations qui en est traduit.
ıtre
e
e
www.tifawt.com
21. 1
`
´
MODELE CONCEPTUEL DE DONNEES (MCD)
1.4
www.tifawt.com
21
M´thodologie de base
e
Face ` une situation bien d´finie (soit ` travers un ´nonc´ pr´cis, soit ` travers une collection de fora
e
a
e
e e
a
mulaires ou d’´tats que le nouveau syst`me d’information est cens´ remplacer), nous pouvons proc´der
e
e
e
e
sans ´tablir le graphe de couverture minimale :
e
– identifier les entit´s en pr´sence ;
e
e
– lister leurs attributs ;
– ajouter les identifiants (num´ro arbitraire et auto-incr´ment´) ;
e
e
e
– ´tablir les associations binaires entre les entit´s ;
e
e
– lister leurs attributs ;
– calculer les cardinalit´s ;
e
– v´rifier les r`gles de normalisation et en particulier, la normalisation des entit´s (c’est ` ce stade
e
e
e
a
qu’apparaissent les associations non binaires), des associations et de leurs attributs ainsi que la
troisi`me forme normale de Boyce-Codd ;
e
– effectuer les corrections n´cessaires.
e
Mais, il est parfois plus intuitif d’en passer par l’´tude des d´pendances fonctionnelles directes :
e
e
– identifier les entit´s en pr´sence et leur donner un identifiant (num´ro arbitraire et auto-incr´ment´) ;
e
e
e
e
e
– ajouter l’ensemble des attributs et leur d´pendances fonctionnelles directes avec les identifiants (en
e
commen¸ant par les d´pendances ´l´mentaires) ;
c
e
ee
– traduire le graphe de couverture minimale obtenu en un sch´ma entit´s-associations ;
e
e
– ajuster les cardinalit´s minimales et ;
e
– ` ce stade, la majorit´ des r`gles de normalisation devraient ˆtre v´rifi´es, il reste tout de mˆme
a
e
e
e
e e
e
la normalisation des noms, la pr´sence d’attributs en plusieurs exemplaires et d’associations redone
dantes ou en plusieurs exemplaires, ` corriger.
a
Il faut garder ´galement ` l’esprit que le mod`le doit ˆtre exhaustif (c’est-`-dire contenir toutes les
e
a
e
e
a
informations n´cessaires) et ´viter toute redondance qui, on ne le dira jamais assez, constitue une perte
e
e
d’espace, une d´multiplication du travail de maintenance et un risque d’incoh´rence.
e
e
e
Il faut par ailleurs veiller ` ´liminer les synonymes (plusieurs signifiants pour un signifi´, exemple :
ae
nom, patronyme, appellation) et les polys`mes (plusieurs signifi´s pour un signifiant, exemples : qualit´,
e
e
e
statut).
Il va de soi que cette m´thodologie ne doit pas ˆtre suivie pas-`-pas une bonne fois pour toute. Au
e
e
a
contraire, il faut it´rer plusieurs fois les ´tapes successives, pour esp´rer converger vers une mod´lisation
e
e
e
e
pertinente de la situation.
www.tifawt.com
22. 2
www.tifawt.com
`
´
MODELE LOGIQUE DE DONNEES (MLD)
2
22
Mod`le logique de donn´es (MLD)
e
e
Maintenant que le MCD est ´tabli, on peut le traduire en diff´rents syst`mes logiques et notamment
e
e
e
les bases de donn´es relationnelles qui proposent une vision plus concr`te pour mod´liser la situation.
e
e
e
2.1
Syst`mes logiques
e
Avant l’apparition des syst`mes de gestion de base de donn´es (SGBD ou DBMS pour Data Base
e
e
Management System), les donn´es ´taient stock´es dans des fichiers binaires et g´r´es par des programmes
e e
e
ee
ex´cutables (d´velopp´s en Basic, Cobol ou Dbase, par exemple). [Gabay] propose ` ce sujet une traduce
e
e
a
tion d’un MPD vers un MLD fichier. Mais la maintenance des programmes (en cas de modification de la
structure des donn´es, notamment) ´tait tr`s probl´matique.
e
e
e
e
Sont alors apparus les SGBD hi´rarchiques dans lesquels les donn´es sont organis´es en arbre (IMSe
e
e
e
e
e
DL1 d’IBM, par exemple), puis les SGBD r´seaux dans lesquels les donn´es sont organis´es selon un
graphe plus g´n´ral (IDS2 de Bull, par exemple). [Matheron, Nanci et al., Gabay] d´crivent la traduce e
e
tion d’un MPD vers un MLD Codasyl (base de donn´es r´seaux). Ces deux types de SGBD sont dit
e
e
navigationnels car on peut retrouver l’information ` condition d’en connaˆ le chemin d’acc`s.
a
ıtre
e
Aujourd’hui, ils sont largement remplac´s par les SGBD relationnels (SGBDR) avec lesquels l’infore
mation peut ˆtre obtenue par une requˆte formul´e dans un langage quasiment naturel (la langage SQL
e
e
e
pour Structured Query Langage). Parmi les SGBDR les plus r´pandus nous trouvons Oracle, SQL Server
e
et DB2. Nous nous contentons ici d’exposer le mod`le logique de donn´es relationnel (MLDR).
e
e
Plus r´cemment, sont apparus le mod`le logique orient´ objet et mˆme des SGBD orient´s objets.
e
e
e
e
e
Pourtant, les SGBD relationnels restent extrˆmement majoritaires, tandis que l’approche orient´ objet
e
e
est parfaitement adapt´e au d´veloppement d’applications clientes dynamiques et li´es aux donn´es du
e
e
e
e
syst`me d’information.
e
2.2
Mod`le logique relationnel
e
Concentrons-nous d´sormais sur le MLDR.
e
2.2.1
Tables, lignes et colonnes
Lorsque des donn´es ont la mˆme structure (comme par exemple, les renseignements relatifs aux
e
e
clients), on peut les organiser en table dans laquelle les colonnes d´crivent les champs en commun et les
e
lignes contiennent les valeurs de ces champs pour chaque enregistrement (tableau 3).
num´ro client
e
1
2
3
4
...
nom
Dupont
Durand
Dubois
Dupuis
...
pr´nom
e
Michel
Jean
Claire
Marie
...
adresse
127, rue...
314, boulevard...
51, avenue...
2, impasse...
...
Tab. 3 – Contenu de la table clients, avec en premi`re ligne les intitul´s des colonnes
e
e
2.2.2
Cl´s primaires et cl´s ´trang`res
e
e e
e
Les lignes d’une table doivent ˆtre uniques, cela signifie qu’une colonne (au moins) doit servir ` les
e
a
identifier. Il s’agit de la cl´ primaire de la table.
e
www.tifawt.com
23. 2
www.tifawt.com
`
´
MODELE LOGIQUE DE DONNEES (MLD)
23
L’absence de valeur dans une cl´ primaire ne doit pas ˆtre autoris´e. Autrement dit, la valeur vide
e
e
e
(NULL) est interdite dans une colonne qui sert de cl´ primaire, ce qui n’est pas forc´ment le cas des autres
e
e
colonnes, dont certaines peuvent ne pas ˆtre renseign´es ` toutes les lignes.
e
e a
De plus, la valeur de la cl´ primaire d’une ligne ne devrait pas, en principe, changer au cours du temps.
e
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 num´ro du client sur une commande doit
e
correspondre ` un vrai num´ro de client). La Colonne2 doit ˆtre sans doublons (bien souvent il s’agit
a
e
e
d’une cl´ primaire). On dit alors que la Colonne1 est cl´ ´trang`re et qu’elle r´f´rence la Colonne2.
e
ee
e
ee
Par convention, on souligne les cl´s primaires et on fait pr´c´der les cl´s ´trang`res d’un di`se # dans
e
e e
e e
e
e
la description des colonnes d’une table :
clients(num´ro client, nom client, pr´nom, adresse client)
e
e
commandes(num´ro commande, date de commande, #num´ro client (non vide))
e
e
Remarques :
– une mˆme table peut avoir plusieurs cl´s ´trang`res mais une seule cl´ primaire (´ventuellement
e
e e
e
e
e
compos´es de plusieurs colonnes) ;
e
– une colonne cl´ ´trang`re peut aussi ˆtre primaire (dans la mˆme table) ;
ee
e
e
e
– une cl´ ´trang`re peut ˆtre compos´e (c’est le cas si la cl´ primaire r´f´renc´e est compos´e) ;
ee
e
e
e
e
ee
e
e
– implicitement, chaque colonne qui compose une cl´ primaire ne peut pas recevoir la valeur vide
e
(NULL interdit) ;
– par contre, si une colonne cl´ ´trang`re ne doit pas recevoir la valeur vide, alors il faut le pr´ciser
ee
e
e
dans la description des colonnes.
Les SGBDR v´rifient au coup par coup que chaque cl´ ´trang`re ne prend pas de valeurs en dehors
e
ee
e
de celles d´j` prises par la ou les colonne(s) qu’elle r´f´rence. Ce m´canisme qui agit lors de l’insertion,
ea
ee
e
de la suppression ou de la mise ` jour de lignes dans les tables, garantit ce que l’on appelle l’int´grit´
a
e
e
r´f´rentielle des donn´es.
ee
e
2.2.3
Sch´ma relationnel
e
On peut repr´senter les tables d’une base de donn´es relationnelle par un sch´ma relationnel dans
e
e
e
e e
e
e
lequel les tables sont appel´es relations et les liens entre les cl´s ´trang`res et leur cl´ primaire est syme
bolis´ par un connecteur (figure 26).
e
clients
-
commandes
numéro client
nom client
prénom
adresse client
- n° commande
- date commande
- #numéro client
(non vide)
Fig. 26 – Sch´ma relationnel simple entre deux tables
e
Certains ´diteur inscrivent sur le connecteur un symbole 1 cˆt´ cl´ primaire et un symbole ∞ cˆt´
e
oe e
oe
cl´ ´trang`re (` condition que celle-ci ne soit pas d´j` cl´ primaire). Il faut prendre garde avec cette
e e
e
a
ea e
convention, car le symbole ∞ se trouve du cˆt´ oppos´ ` la cardinalit´ maximale n correspondante.
oe
ea
e
www.tifawt.com
24. 2
www.tifawt.com
`
´
MODELE LOGIQUE DE DONNEES (MLD)
2.3
24
Traduction d’un MCD en un MLDR
Pour traduire un MCD en un MLDR, il suffit d’appliquer cinq r`gles.
e
Notations : on dit qu’une association binaire (entre deux entit´s ou r´flexive) est de type :
e
e
– 1 : 1 (un ` un) si aucune des deux cardinalit´s maximales n’est n ;
a
e
– 1 : n (un ` plusieurs) si une des deux cardinalit´s maximales est n ;
a
e
– n : m (plusieurs ` plusieurs) si les deux cardinalit´s maximales sont n.
a
e
En fait, un sch´ma relationnel ne peut faire la diff´rence entre 0,n et 1,n. Par contre, il peut la faire
e
e
entre 0,1 et 1,1 (r`gles 2 et 4).
e
R`gle 1 : toute entit´ devient une table dans laquelle les attributs deviennent les colonnes. L’identie
e
fiant de l’entit´ constitue alors la cl´ primaire de la table.
e
e
Par exemple, l’entit´ articles de la figure 13 devient la table :
e
articles(num´ro article, d´signation, prix unitaire de vente)
e
e
R`gle 2 : une association binaire de type 1 : n disparaˆ au profit d’une cl´ ´trang`re dans la table
e
ıt,
ee
e
cˆt´ 0,1 ou 1,1 qui r´f´rence la cl´ primaire de l’autre table. Cette cl´ ´trang`re ne peut pas recevoir la
oe
ee
e
ee
e
valeur vide si la cardinalit´ est 1,1.
e
Par exemple, l’association livrer de la figure 13 est traduite par :
fournisseurs(n◦ fournisseur, nom contact, n◦ t´l´phone contact)
e e
livraisons(n◦ livraison, date de livraison, nom livreur, #n◦ fournisseur (non vide))
fournisseurs
- n° fournisseur
- nom contact
- n° téléphone
contact
livraisons
1,n
livrer
- n° livraison
1,1 - date de
livraison
- nom livreur
fournisseurs
traduction
- n° fournisseur
- nom contact
- n° téléphone
contact
livraisons
- n° livraison
- date de
livraison
- nom livreur
- #n° fournisseur
(non vide)
Fig. 27 – 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 cˆt´ 1.
oe
www.tifawt.com
25. 2
www.tifawt.com
`
´
MODELE LOGIQUE DE DONNEES (MLD)
25
R`gle 3 : une association binaire de type n : m devient une table suppl´mentaire (parfois appel´e
e
e
e
table de jonction, table de jointure ou table d’association) dont la cl´ primaire est compos´e de deux
e
e
cl´s ´trang`res (qui r´f´rencent les deux cl´s primaires des deux tables en association). Les attributs de
e e
e
ee
e
l’association deviennent des colonnes de cette nouvelle table.
Par exemple, l’association concerner (1) de la figure 13 est traduite par la table suppl´mentaire
e
lignes de commande :
lignes de commande(#n◦ commande, #n◦ article, quantit´ command´e)
e
e
commandes
- n° commande
- date commande
1,n
concerner (1)
commandes
traduction
- quantité
commandée
- n° commande
- date commande
0,n
lignes de
commandes
articles
- #n° commande
- #n° article
- quantité
commandée
- numéro article
- désignation
- prix unitaire
de vente
articles
- numéro article
- désignation
- prix unitaire
de vente
Fig. 28 – Traduction d’une association de type n : m
e
R`gle 4 : une association binaire de type 1 : 1 est traduite comme une association binaire de type 1 : n
sauf que la cl´ ´trang`re se voit imposer une contrainte d’unicit´ en plus d’une ´ventuelle contrainte de
ee
e
e
e
non vacuit´ (cette contrainte d’unicit´ impose ` la colonne correspondante de ne prendre que des valeurs
e
e
a
distinctes).
Si les associations fantˆmes ont ´t´ ´limin´es, il devrait y avoir au moins un cˆt´ de cardinalit´ 0,1.
o
eee
e
oe
e
C’est alors dans la table du cˆt´ oppos´ que doit aller la cl´ ´trang`re. Si les deux cˆt´s sont de cardinalit´
oe
e
ee
e
oe
e
0,1 alors la cl´ ´trang`re peut ˆtre plac´e indiff´remment dans l’une des deux tables.
ee
e
e
e
e
Par exemple, l’association diriger de la figure 29 est traduite par :
e
e
services(n◦ service, nom service, #num´ro employ´ (non vide, unique))
employ´s(num´ro employ´s, nom)
e
e
e
services
employés
- n° employé
- nom
0,1
diriger
employés
services
1,1 - n° service
- nom service
traduction
- n° employé
- nom
Fig. 29 – Traduction d’une association de type 1 : 1
www.tifawt.com
- n° service
- nom service
- #n° employé
(unique, non vide)
26. 2
www.tifawt.com
`
´
MODELE LOGIQUE DE DONNEES (MLD)
26
En r´alit´, la r`gle 4 propos´e ici consid`re qu’une association binaire de type 1 : 1 correspond `
e e
e
e
e
a
une association binaire de type 1 : n particuli`re. Une alternative consiste ` voir une association binaire
e
a
de type 1 : 1 comme une association binaire de type n : m particuli`re. Il suffit pour cela d’ajouter une
e
contrainte d’unicit´ sur chacune des cl´s ´trang`res de la table de jonction suppl´mentaire :
e
e e
e
e
services(n◦ service, nom service)
directions(#n◦ service (unique), #num´ro employ´ (unique)
e
e
employ´s(num´ro employ´s, nom)
e
e
e
directions
employés
- n° employé
- nom
services
- #n° service (unique)
- #n° employé (unique)
- n° service
- nom service
Fig. 30 – Traduction alternative d’une association de type 1 : 1
Mais rien ne garantit, dans cette traduction alternative (figure 30), qu’un service poss`de un dirigeant,
e
alors que c’est obligatoire. La premi`re traduction (figure 29) est donc pr´f´rable.
e
ee
Remarque : d’autres techniques sont parfois propos´es pour cette r`gle 4 (fusionner les tables, utiliser
e
e
une cl´ primaire identique, utiliser deux cl´s ´trang`res r´flexives) mais elles ne sont pas exploitables dans
e
e e
e
e
le cas g´n´ral.
e e
R`gle 5 : une association non binaire est traduite par une table suppl´mentaire dont la cl´ primaire
e
e
e
est compos´e d’autant de cl´s ´trang`res que d’entit´s en association. Les attributs de l’association dee
e e
e
e
viennent des colonnes de cette nouvelle table.
Par exemple, l’association projeter de la figure 8 devient la table :
projections(#n◦ film, #n◦ salle, #n◦ cr´neau, tarif)
e
créneaux horaires
créneaux horaires
- n° créneau
- date
- heure de début
- n° créneau
- date
- heure de début
0,n
projeter
- tarif
projections
films
0,n - n° film
- titre
- durée
traduction
-
films
#n° film
#n° salle
#n° créneau
tarif
- n° film
- titre
- durée
0,n
salles
salles
- n° salle
- capacité
- n° salle
- capacité
Fig. 31 – Traduction d’une association ternaire
www.tifawt.com
27. 3
www.tifawt.com
`
´
MODELE PHYSIQUE DE DONNEES (MPD)
3
27
Mod`le physique de donn´es (MPD)
e
e
Un mod`le physique de donn´es est l’impl´mentation particuli`re du mod`le logique de donn´es par
e
e
e
e
e
e
un logiciel.
3.1
Distinction entre MLD et MPD
La traduction d’un MLD conduit ` un MPD qui pr´cise notamment le stockage de chaque donn´e `
a
e
e a
travers son type et sa taille (en octets ou en bits). Cette traduction est ´galement l’occasion d’un certain
e
nombre de libert´s prises par rapport aux r`gles de normalisation afin d’optimiser les performances du
e
e
syst`me d’information.
e
La traduction d’un MLD relationnel en un mod`le physique est la cr´ation (par des requˆtes SQL
e
e
e
de type CREATE TABLE et ADD CONSTRAINT) d’une base de donn´es h´berg´e par un SGBD relationnel
e
e
e
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 mˆme mod`le logique (le sch´ma relationnel)
e
e
e
permet ` la fois la communication entre des bases h´t´rog`nes et la conversion d’une base de donn´es
a
ee e
e
d’une SGBDR ` l’autre.
a
3.2
Optimisations
L’optimisation des performances en temps de calcul se fait toujours au d´triment de l’espace m´moire
e
e
consomm´. Dans le pire des cas, r´duire les temps de r´ponse consiste ` d´normaliser volontairement le
e
e
e
a e
syst`me d’information, avec tous les risques d’incoh´rence et les probl`mes de gestion que cela comporte.
e
e
e
Pour les bases de donn´es relationnelles, l’optimisation qui vise ` acc´l´rer les requˆtes peut passer
e
a
ee
e
par :
– l’ajout d’index aux tables (au minimum sur les colonnes cl´s primaires et cl´s ´trang`res) ; ces index
e
e e
e
consomment de l’espace m´moire suppl´mentaire, mais la base de donn´es reste normalis´e ;
e
e
e
e
– l’ajout de colonnes calcul´es ou de certaines redondances pour ´viter des jointures coˆteuses (aue
e
u
quel cas la base est d´normalis´e) ; il faut alors veiller ` ce que la coh´rence entre les colonnes
e
e
a
e
soit respect´e, soit par l’utilisation de d´clencheurs, soit dans les applications clientes du syst`me
e
e
e
d’information ;
– la suppression des contraintes d’unicit´, de non vacuit´ ou encore de cl´ ´trang`re (auquel cas,
e
e
e e
e
l’int´grit´ des donn´es doit ˆtre assur´e par le code client du syst`me d’information).
e
e
e
e
e
e
Par exemple, la table commandes de la figure 28 peut ˆtre supprim´e et la date de commande est
e
e
alors ajout´e ` la table lignes de commandes. On renonce donc ` la troisi`me forme normale (figure 32)
e a
a
e
commandes
- n° commande
- date commande
lignes de
commandes
lignes de
commandes
articles
- #n° commande
- #n° article
- quantité
commandée
- numéro article
- désignation
- prix unitaire
de vente
dénormalisation
-
n° commande
#n° article
date commande
quantité
commandée
Fig. 32 – Sacrifice de la troisi`me forme normale
e
www.tifawt.com
articles
- numéro article
- désignation
- prix unitaire
de vente
28. 4
´
RETRO-CONCEPTION
www.tifawt.com
28
puisque la date de commande est r´p´t´e autant de fois qu’il y a de lignes dans la commande, mais on
e ee
´vite ainsi une jointure coˆteuse en temps de calcul lors des requˆtes SQL.
e
u
e
Le conseil le plus pr´cieux, en mati`re d’optimisation, est de ne jamais optimiser a priori, mais toujours
e
e
a posteriori, c’est-`-dire en r´ponse ` une lenteur que le SGBDR n’est pas capable de r´soudre tout seul.
a
e
a
e
Il faut alors mesurer le gain de toute optimisation manuelle en effectuant des tests (chronom´trages
e
avant/apr`s) sur un volume de donn´es significatif et de pr´f´rence en exploitation.
e
e
ee
4
R´tro-conception
e
Dans la majorit´ des cas, le travail du concepteur de bases de donn´es consiste non pas ` cr´er une
e
e
a e
base de donn´es ex nihilo, mais plutˆt ` corriger ou ´tendre une base existante. Dans ce cas, la mati`re de
e
o a
e
e
travail initiale est un mod`le physique et la m´thode de r´tro-conception ou reverse engineering consiste
e
e
e
a
` traduire ce MPD en un mod`le conceptuel, modifier le MCD obtenu puis modifier le mod`le physique
e
e
en cons´quence.
e
4.1
Traduction inverse
Dans le cadre des bases de donn´es relationnelles, il faut convertir le mod`le physique en un sch´ma
e
e
e
relationnel normalis´ (en d´tricotant les optimisations ´ventuelles et en renommant les colonnes des tables
e
e
e
pour assurer l’unicit´ et le caract`re explicite (non cod´) des noms), puis appliquer les r`gles de traduction
e
e
e
e
de la section 2.3 dans le sens inverse.
´
Etape 1 : chaque table dont la cl´ primaire ne contient pas de cl´ ´trang`re devient une entit´ dont
e
ee
e
e
l’identifiant est la cl´ primaire de la table et dont les attributs sont les colonnes de la table qui ne sont
e
pas cl´ ´trang`re.
ee
e
´
Etape 3 : chaque table dont la cl´ primaire est compos´e exclusivement de cl´s ´trang`res qui
e
e
e e
e
r´f´rencent plusieurs cl´s primaires, devient une association autour de laquelle toutes les cardinalit´s
ee
e
e
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 cl´s ´trang`res de la table deviennent des attributs de l’association).
e e
e
´
Etape 5 : les colonnes cl´s ´trang`res restantes deviennent des associations binaires de type 1 : n s’il
e e
e
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
e
e
a
` cette association).
´
Etape 6 : la cardinalit´ minimale vaut 1 pour les cl´s ´trang`res qui font partie d’une cl´ primaire
e
e e
e
e
ou qui poss`dent une contrainte (non vide), sinon elle vaut 0.
e
www.tifawt.com
29. 4
www.tifawt.com
´
RETRO-CONCEPTION
4.2
29
Cas particuliers
Malheureusement, ces quatres ´tapes ne suffisent pas pour traduire tous les sch´mas relationnels pose
e
sibles. Notamment, les tables de la figure 33 n´cessitent l’insertion d’´tapes suppl´mentaires.
e
e
e
chèques
règlements
- n° règlement
- date règlement
- montant
- #n° règlement
- n° chèque
- nom banque
paiements par carte
parcours
trous
- n° parcours
- nom parcours
- #n° parcours
- n° trou dans
parcours
- par
- distance
- #n° règlement
- n° carte
- date d’expiration
(a) cl´ sur une colonne, mais ` la fois prie
a
maire et ´trang`re
e
e
(b) cl´ primaire compos´e partiele
e
lement de cl´ ´trang`re
ee
e
Fig. 33 – Tables particuli`res en r´tro-conception
e
e
´
Etape 2 : chaque table dont la cl´ primaire est compos´e exclusivement de cl´s ´trang`res qui
e
e
e e
e
r´f´rencent une seule cl´ primaire, devient une sous-entit´ ou une sous-association (les autres colonnes
ee
e
e
non cl´s ´trang`res de la table deviennent des attributs de cette sous-entit´).
e e
e
e
´
Etape 4 : chaque table dont la cl´ primaire est compos´e partiellement de cl´s ´trang`res provient
e
e
e e
e
soit d’une optimisation qu’il faire d´faire (comme sur la figure 32) soit d’un identifiant relatif d’une entit´
e
e
comme dans la section 5.2 (auquel cas les autres colonnes non cl´s ´trang`res de la table deviennent des
e e
e
attributs de cette entit´).
e
www.tifawt.com
30. 5
´
COMPLEMENTS
5
www.tifawt.com
30
Compl´ments
e
Aucune situation compl`te, ou presque, ne peut ˆtre parfaitement mod´lis´e si le concepteur se
e
e
e e
contente des fonctionnalit´s abord´es ` ce stade du document. Ne serait-ce que pour comprendre l’´lae
e a
e
boration des tables de la figure 33, il est n´cessaire d’introduire de nouvelles notations sur le sch´ma
e
e
entit´s-associations. Les trois extensions majeures pr´sent´es dans cette section font partie de la vere
e
e
sion 2 de Merise [Panet et al.]. Elles permettent de traiter davantage de situations r´elles et souvent de
e
mani`re plus simple.
e
Dans cette section, nous reprenons la d´marche qui consiste ` ´tudier les d´pendances fonctionnelles
e
ae
e
directes sur le graphe de couverture minimale, puis ` traduire ce graphe en sch´ma entit´s-associations,
a
e
e
pour obtenir finalement un sch´ma relationnel. Les notions abord´es ici ne permettent plus au sch´ma
e
e
e
relationnel d’ˆtre ´crit textuellement sans ambigu¨ e. Afin de lever toute ambigu¨ e pour savoir quelle
e
e
ıt´
ıt´
cl´ primaire est r´f´renc´e par telle cl´ ´trang`re, il est imp´ratif de repr´senter le sch´ma relationnel de
e
ee
e
ee
e
e
e
e
mani`re graphique, ce que nous nous contentons de faire.
e
5.1
Agr´gation
e
Une association n’est pas forc´ment ´tablie exclusivement entre des entit´s.
e
e
e
5.1.1
Association de type 1 : n
Consid´rons l’exemple de la figure 34 issu du monde des courses hippiques. La d´pendance fonctione
e
◦ cheval + n◦ course → n◦ jockey est la premi`re d´pendance fonctionnelle non ´l´mentaire
nelle n
e
e
ee
vers un identifiant que nous rencontrons. Ce type de d´pendance fonctionnelle nous incite ` cr´er une
e
a e
association binaire de type 1 : n entre l’entit´ jockeys et l’association binaire de type n : m qu’il y a entre
e
les entit´s chevaux et courses. D’un point de vue s´mantique, la logique est respect´e puisque un jockey
e
e
e
ne monte pas un cheval, mais un cheval-qui-participe-`-une-course.
a
Pour tenir compte de ce nouveau cas de d´pendance fonctionnelle, il convient d’ajouter une sixi`me
e
e
´tape ` la technique de traduction d’un graphe de couverture minimal en un sch´ma entit´s-associations,
e
a
e
e
telle qu’elle est commenc´e section 1.3.3 :
e
´
Etape 6 : lorsqu’un identifiant d´pend de plusieurs autres identifiants, son entit´ est en association
e
e
de type 1 : n avec l’association qui lie les autres identifiants.
www.tifawt.com
31. 5
www.tifawt.com
´
COMPLEMENTS
31
nom du cheval
numéro de cheval
date de naissance
dossard
nom du jockey
numéro de jockey
ordre d’arrivée
prénom
lieu de la course
date de la course
tra
du
cti
on
numéro de course
chevaux
- n° cheval
- nom cheval
- date naissance
chevaux
- n° cheval
- nom cheval
- date naissance
0,n
participations
participer
0,n
#n° course
#n° cheval
dossard
ordre d’arrivée
#n° jockey
(non vide)
courses
courses
- n° course
- lieu course
- date course
- n° course
- lieu course
- date course
- dossard
- ordre d’
arrivée
jockeys
1,1
monter
0,n - n° jockey
- nom jockey
- prénom
traduction
-
jockeys
- n° jockey
- nom jockey
- prénom
Fig. 34 – Association binaire de type 1 : n (monter), li´e ` une association binaire de type n : m
e a
(participer)
Certains auteurs consid`rent que l’agr´gation des entit´s chevaux, courses et de l’association pare
e
e
ticiper constitue une nouvelle entit´ participations qui englobe ces trois ´l´ments graphiques. Dans
e
ee
ce cas, l’association monter fait le lien entre les deux entit´s (participations et jockeys). Le r´sultat
e
e
final sur le sch´ma relationnel est le mˆme. Malheureusement, cette notation n’est pas tr`s pratique car
e
e
e
le sch´ma entit´s-associations devient vite illisible lorsqu’une entit´ participe ` plusieurs agr´gations.
e
e
e
a
e
Nous pr´f´rons donc autoriser, dans ce document, qu’une association puisse ˆtre li´e ` une associaee
e
e a
tion binaire de type n : m ou ` une association ternaire (ou plus). Cependant pour ne pas confondre les
a
liens entres associations et entit´s avec les liens entres associations, nous encadrons soigneusement les
e
associations qui interviennent dans une agr´gation, comme sur la figure 34 en bas ` gauche.
e
a
En tout cas, une association ne peut pas ˆtre li´e ` une association binaire de type 1 : n ou 1 : 1. Dans ce
e
e a
cas, l’association doit ˆtre directement li´e ` l’entit´ qui se trouve du cˆt´ o` la cardinalit´ maximale est 1.
e
e a
e
oe u
e
Sur le sch´ma relationnel final (figure 34 en bas ` droite), la table de jonction participations re¸oit
e
a
c
une cl´ ´trang`re suppl´mentaire, mais qui contrairement aux autres, ne participe pas ` la cl´ primaire.
ee
e
e
a
e
www.tifawt.com
32. 5
www.tifawt.com
´
COMPLEMENTS
5.1.2
32
Association de type n : m
`
´
A pr´sent, ajoutons les parieurs ` notre exemple de la figure 34. Etant donn´ que nous avons la
e
a
e
◦ cheval + n◦ course + n◦ parieur → montant de la mise (figure 35 en
d´pendance fonctionnelle n
e
haut), nous pourrions avoir une association ternaire entre les entit´s chevaux, courses et parieurs.
e
Mais dans ce cas, un parieur peut miser sur un cheval dans une course, alors que ce cheval ne participe
pas ` cette course.
a
nom du cheval
numéro de cheval
nom du
parieur
date de naissance
dossard
numéro de jockey
numéro de parieur
numéro
de
compte
ordre d’arrivée
montant
nom du jockey
prénom
lieu de la course
numéro de course
correction
date de la course
nom du cheval
numéro de cheval
nom du
parieur
date de naissance
dossard
numéro de jockey
numéro de parieur
numéro
de
compte
ordre d’arrivée
montant
numéro de course
nom du jockey
prénom
lieu de la course
date de la course
Fig. 35 – Association ternaire remplac´e par deux associations binaires
e
Pour pallier cette lacune, on pourrait faire appel ` des d´clencheurs programm´s dans la base de
a
e
e
donn´es finale. Les d´clencheurs sont des proc´dures SQL qui, dans notre exemple, permettraient `
e
e
e
a
chaque insertion ou mise ` jour de lignes dans la table des paris, d’assurer qu’un pari ne puisse pas
a
concerner un cheval dans une course ` laquelle il ne participe pas. Cependant, il existe une solution plus
a
simple qui repose uniquement sur l’int´grit´ r´f´rentielle.
e
e ee
En r´alit´ (figure 35 en bas), la vraie d´pendance fonctionnelle directe est (n◦ cheval + n◦ course)
e e
e
◦ parieur → montant, ce qui garantit qu’un parieur ne peut miser que sur un cheval-qui-participe+ n
a
`-une-course.
Le fait qu’une association ternaire (ou plus) disparaissent au profit d’une ou plusieurs agr´gations
e
`
est tr`s fr´quent lorsque l’on mod´lise une situation compl`te. A tel point qu’on peut partir du principe
e e
e
e
qu’un sch´ma entit´s-associations sans agr´gation est g´n´ralement faux.
e
e
e
e e
www.tifawt.com
33. 5
www.tifawt.com
´
COMPLEMENTS
33
Dans notre exemple, la traduction de la nouvelle d´pendance fonctionnelle en une association de type
e
n : m (figure 36 en haut) se fait en appliquant, comme d’habitude, l’´tape 4 de la section 1.3.3.
e
chevaux
- n° cheval
- nom cheval
- date naissance
0,n
participer
parier
parieurs
- n° parieur
0,n
- montant
- nom parieur
- n° compte
0,n
- dossard
- ordre d’
arrivée
jockeys
1,1
monter
0,n - n° jockey
- nom jockey
- prénom
0,n
traduction
courses
- n° course
- lieu course
- date course
parieurs
- n° parieur
- nom parieur
- n° compte
paris
-
#n° parieur
#n° course
#n° cheval
montant
participations
-
#n° course
#n° cheval
dossard
ordre arrivée
#n° jockey
(non vide)
courses
- n° course
- lieu course
- date course
chevaux
- n° cheval
- nom cheval
- date naissance
jockeys
- n° jockey
- nom jockey
- prénom
Fig. 36 – Association binaire de type n : m (parier), li´e ` une autre association binaire de type n : m
e a
Sur le sch´ma relationnel obtenu (figure 36 en bas), la traduction de l’association binaire de type n : m
e
li´e ` une autre association binaire de type n : m fait apparaˆ dans la table paris une cl´ ´trang`re
e a
ıtre
ee
e
composite qui r´f´rence la cl´ primaire composite de la table participations.
ee
e
Rappelons qu’il est d´conseill´ d’utiliser des identifiants composites. Mais la cl´ primaire composite
e
e
e
de la table participations est l´gitime puisqu’elle est issue d’une association binaire de type n : m. En
e
cons´quence de quoi la cl´ ´trang`re composite de la table paris est ´galement l´gitime puisqu’elle est
e
ee
e
e
e
aussi issue d’une association binaire de type n : m.
On peut ainsi imaginer avoir sur un sch´ma relationnel des cl´s primaires ou ´trang`res compos´es
e
e
e
e
e
d’un nombre arbitraire de colonnes, sans pour autant qu’il n’y ait un seul identifiant composite sur le
sch´ma entit´s-associations correspondant.
e
e
www.tifawt.com
34. 5
www.tifawt.com
´
COMPLEMENTS
5.1.3
34
Tables de codification ou tables de r´f´rence
ee
Certains attributs ne peuvent prendre qu’un jeu volontairement limit´ de valeurs. C’est le cas sur la
e
figure 37 ` gauche, pour les attributs enseignant et mati`re. Cela ´vite sur cet exemple qu’une mˆme
a
e
e
e
mati`re ne soit d´crite de deux mani`res diff´rentes et qu’un mˆme nom d’enseignant ne soit orthographi´
e
e
e
e
e
e
deux fois.
semaines
dans l’année
semaines
dans l’année
- n° semaine
- date de début
- n° semaine
- date de début
jours
dans la semaine
- n° jour
- jour
jours
dans la semaine
0,n
0,n
occuper
- enseignant
créneaux horaires
0,n - matière
dans la journée
- n° créneau
- heure de début
0,n
correction
enseignants
- n° enseignant
- nom
0,n
0,n
assurer
- n° jour
- jour
0,n
créneaux horaires
dans la journée
- n° créneau
- heure de début
0,n
occuper
1,1
1,1
concerner
0,n
0,n
salles
salles
matière
- n° salle
- capacité
- n° salle
- capacité
- n° matière
- libellé
Fig. 37 – Agr´gation et entit´s de codification
e
e
e
e
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
e
a
e
e
en association binaire de type 1 : n avec cette entit´ de codification. Par contre, si l’attribut fait partie
e
d’une association, il faut recourir ` l’agr´gation afin de mettre en association l’entit´ de codification avec
a
e
e
l’association de cet attribut (figure 37 a droite).
`
Ainsi, l’agr´gation ´vite notamment aux entit´s de codification de transformer une association binaire
e
e
e
en une association ternaire (ou plus).
www.tifawt.com
35. 5
www.tifawt.com
´
COMPLEMENTS
5.2
35
Identifiant relatif ou lien identifiant
Mˆme en utilisant des agr´gations, il reste des situations o` tout le potentiel de l’int´grit´ r´f´rentielle
e
e
u
e
e ee
n’est pas exploit´.
e
5.2.1
R´solution d’un probl`me sur le sch´ma relationnel
e
e
e
Prenons par exemple le sch´ma relationnel en haut de la figure 38, tir´ d’une base de donn´es pour
e
e
e
un centre de golf. Dans la table trous, la cl´ primaire n◦ trou est en incr´ment automatique, tandis que
e
e
la colonne n◦ trou dans parcours est un nombre (g´n´ralement compris entre 1 et 18) qui correspond
e e
a
` la num´rotation des trous dans le parcours.
e
Le probl`me de ce sch´ma relationnel est qu’en l’´tat, il peut y avoir un score dans la table scores
e
e
e
pour un trou qui n’appartient pas au parcours sur lequel la partie se joue (le lecteur est invit´ ` bien
e a
observer la figure pour s’en apercevoir).
participations
parties
- n° parcours
- nom parcours
- #n° golfeur
- #n° partie
trous
- n° trou
- #n° parcours
(non vide)
- n° trou dans
parcours
- par
- distance
scores
-
participations
parties
- n° partie
- #n° parcours
- date
- n° golfeur
- nom golfeur
- handicap
#n° golfeur
#n° partie
#n° trou
score
correction
parcours
- n° partie
- #n° parcours
(non vide)
- date
golfeurs
- #n° golfeur
- #n° partie
- #n° parcours
golfeurs
- n° golfeur
- nom golfeur
- handicap
parcours
- n° parcours
- nom parcours
scores
trous
- #n° parcours
- n° trou dans
parcours
- par
- distance
-
#n° golfeur
#n° partie
#n° parcours
#n° trou dans
parcours
- score
Fig. 38 – Utilisation de cl´s primaires partiellement ´trang`res
e
e
e
Pour r´gler ce probl`me, on peut ` nouveau se reposer sur l’emploi de d´clencheurs. Mais l`-encore,
e
e
a
e
a
il existe une solution ne faisant appel qu’` l’int´grit´ r´f´rentielle.
a
e
e ee
Cette solution consiste ` faire entrer le num´ro de parcours dans la num´rotation des trous (rema
e
e
pla¸ant ainsi le n◦ trou) ainsi que dans la num´rotation des parties (en conservant cette fois-ci le n◦
c
e
www.tifawt.com
36. 5
www.tifawt.com
´
COMPLEMENTS
36
partie en incr´ment automatique). Les tables trous et parties poss`dent alors une cl´ primaire come
e
e
posite et partiellement ´trang`re (figure 38 en bas).
e
e
Les cl´s ´trang`res des tables participations et scores qui r´f´rencent ces nouvelles cl´s primaires
e e
e
ee
e
sont alors compl´t´es par une nouvelle colonne (le num´ro de parcours). Dans la table des scores, comme
ee
e
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.
5.2.2
Mod`le conceptuel correspondant
e
En r´tro-conception, pour tenir compte du fait que le num´ro de parcours fera partie de la cl´ primaire
e
e
e
de la table trous sur le sch´ma entit´s-associations, il suffit de mettre entre parenth`ses la cardinalit´ 1,1
e
e
e
e
de l’association entre les entit´s trous et parcours (figure 39). L’identifiant de l’entit´ cˆt´ 1,1 devient
e
e oe
alors relatif ` celui de l’autre entit´ en association.
a
e
avoir lieu sur
0,n
golfeurs
parties
(1,1) - n° partie
- date
0,n
participer
0,n
- n° golfeur
- nom golfeur
- handicap
parcours
0,n
- n° parcours
- nom parcours
0,n
trous
faire partie
(1,1)
- n° trou dans
parcours
- par
- distance
0,n
obtenir
- score
Fig. 39 – Repr´sentation des identifiants relatifs
e
De mˆme, sur le graphe de couverture minimal, nous introduisons une nouvelle notation (fl`che en
e
e
pointill´s) pour repr´senter le caract`re relatif des identifiants (figure 40).
e
e
e
numéro de partie
sur un parcours
nom du golfeur
numéro de golfeur
handicap
date
score
numéro de trou
dans un parcours
numéro de parcours
nom du parcours
par
distance
Fig. 40 – Repr´sentation des identifiants relatifs sur le graphe de couverture minimale
e
Si les fl`ches ´taient pleines, les num´ros de trou dans un parcours et de partie sur un parcours
e
e
e
figureraient dans des entit´s s´par´es et r´duites ` leur identifiant (` ´viter).
e e e
e
a
ae
www.tifawt.com
37. 5
www.tifawt.com
´
COMPLEMENTS
5.2.3
37
Discussion autour de la num´rotation des exemplaires
e
Dans un magasin de location de vid´os, le g´rant peut vouloir num´roter s´par´ment les exemplaires
e
e
e
e e
de chaque vid´o (figure 41 colonne de gauche), alors que le concepteur de la base de donn´es aurait
e
e
tendance ` vouloir num´roter globalement l’ensemble des exemplaires (colonne de droite).
a
e
titre
date d’acquisition
titre
numéro d’exemplaire
numéro de vidéo
date d’acquisition
numéro de vidéo
numéro d’exemplaire
emprunt
emprunt
numéro de membre
date de
téléphone
réservation
numéro de membre
date d’emprunt
date de
téléphone
réservation
exemplaires
vidéos
correspondre
- n° vidéo
- titre
0,n
correspondre
0,n
membres
1,1 - n° exemplaire
- date acquisition
- date emprunt
0,1
réserver
0,n - n° membre
- date réservation
- nom
- téléphone
traduction
0,n
exemplaires
vidéos
0,n
emprunter
traduction
(1,1) - n° exemplaire
- date acquisition
- date emprunt
0,n
0,1
membres
emprunter
réserver
0,n - n° membre 0,n
- date réservation
- nom
- téléphone
- n° vidéo
- titre
nom
traduction
traduction
nom
date d’emprunt
vidéos
exemplaires
- n° vidéo
- titre
réservations
membres
- # n° vidéo
- # n° membre
- date réservation
- n° membre
- nom
- téléphone
-
vidéos
exemplaires
# n° vidéo
n° exemplaire
date acquisition
#n° membre
date emprunt
- n° vidéo
- titre
- # n° vidéo
(non vide)
- n° exemplaire
- date acquisition
- #n° membre
- date emprunt
réservations
membres
- # n° vidéo
- # n° membre
- date réservation
- n° membre
- nom
- téléphone
Fig. 41 – Num´rotations alternatives des exemplaires
e
La seule diff´rence entre les deux solutions est l’entr´e ou non de la colonne num´ro vid´o dans la cl´
e
e
e
e
e
primaire de la table exemplaire. L’inconv´nient majeur de la solution avec identifiant relatif (colonne de
e
gauche), est le traitement de l’incr´ment automatique du num´ro d’exemplaire, car il faut un compteur
e
e
pour chaque vid´o et non pas un compteur pour l’ensemble des vid´os, contrairement ` la solution de
e
e
a
la colonne de droite. Le concepteur devrait donc retenir sa solution pour la base de donn´es et proposer
e
une colonne suppl´mentaire avec la num´rotation du g´rant, afin de lui faire plaisir.
e
e
e
www.tifawt.com
38. 5
www.tifawt.com
´
COMPLEMENTS
5.3
38
H´ritage
e
Enfin, il est parfois utile de factoriser les attributs communs ` plusieurs entit´s au sein d’une entit´
a
e
e
m`re.
e
5.3.1
Sous-entit´
e
Consid´rons l’exemple suivant : les factures d’une entreprise font l’objet d’un r`glement par ch`que
e
e
e
ou par carte. Cette entreprise souhaite connaˆ pour chaque r`glement la date, le montant et :
ıtre
e
– le num´ro et le nom de la banque des ch`ques ;
e
e
– ou le num´ro et la date d’expiration des paiements par carte.
e
On a donc une entit´ g´n´rique r`glements et deux entit´s sp´cialis´es ch`ques et paiements par
e e e
e
e
e
e
e
carte. Ces deux sous-entit´s de l’entit´ r`glements ont des attributs propres mais pas d’identifiant
e
e e
propre. Au niveau logique objet, on retrouve la notion d’h´ritage.
e
Conform´ment aux notations objets, sur le sch´ma entit´s-associations, on repr´sente le lien qui unit
e
e
e
e
une sous-entit´ ` son entit´ g´n´rique par une fl`che creuse (figure 42 au centre). Ce lien remplace une asea
e e e
e
sociation ^tre de type 1 : 1 (un ch`que ( est un ) r`glement et un paiement par carte ( est un ) r`glement).
e
e
(
) e
(
) e
numéro de chèque
numéro de règlement
numéro de facture
date de règlement
et montant
numéro de règlement
règlements
- n° chèque
- nom banque
1,1 - n° règlement
- date règlement
- montant
paiements par carte
- n° carte
- date d’expiration
traduction
correspondre
numéro de carte
chèques
factures
- n° facture
0,n
- date facture
- montant total
nom de la banque
date d’expiration
traduction
date de facture
et montant total
numéro de règlement
chèques
règlements
factures
- n° facture
- date facture
- montant total
-
n° règlement
date règlement
montant
#n° facture
(non vide)
- #n° règlement
- n° chèque
- nom banque
paiements par carte
- #n° règlement
- n° carte
- date d’expiration
Fig. 42 – Repr´sentation des sous-entit´s
e
e
Toutefois, il ne faut pas voir d’h´ritage ` chaque fois que l’on peut dire ( est un ) car il faut en
e
a
(
),
plus que l’entit´ m`re ne poss`de que les attributs communs de ses entit´s filles. Par exemple, un cercle
e e
e
e
( est math´matiquement un ) ovale. Mais l’entit´ cercles (avec les attributs centre et rayon) n’est pas
(
e
)
e
www.tifawt.com
39. 5
www.tifawt.com
´
COMPLEMENTS
39
une sous-entit´ de l’entit´ ovales car celle-ci poss`de davantage d’attributs (centre, rayon principal,
e
e
e
rayon secondaire et rotation).
La traduction des sous-entit´s au niveau logique relationnel fait intervenir une cl´ primaire identique
e
e
a
` celle de l’entit´ m`re, mais dans les sous-entit´s la cl´ primaire est aussi ´trang`re (figure 42 en bas).
e e
e
e
e
e
Sur le graphe de couverture minimale (figure 42 en haut), l’identifiant dont d´pendent les attributs
e
communs est volontairement dupliqu´ autant de fois que n´cessaire pour les attributs sp´cialis´s. Nous
e
e
e
e
pouvons alors remarquer que les attributs qui d´pendent d’un mˆme identifiant peuvent ˆtre regroup´s
e
e
e
e
avec des (( et )) logiques tandis que d`s qu’il est n´cessaire de faire appel ` un ( ou ) logique, c’est le signe
e
e
a
(
)
d’une sp´cialisation.
e
Sur la figure 42, il est tentant de traduire directement le graphe de couverture minimale en le sch´ma
e
relationnel, car il en est beaucoup plus proche que le sch´ma entit´s-associations. C’est une technique
e
e
licite, ` condition de traduire correctement les associations de type 1 : 1 (´tape 4 page 17).
a
e
5.3.2
Utilisation de l’h´ritage pour s´parer les informations compl´mentaires
e
e
e
L’h´ritage peut ˆtre utilis´ mˆme lorsqu’il n’y a qu’une entit´ sp´cialis´e. C’est utile pour stocker
e
e
e e
e e
e
dans une table s´par´e des informations compl´mentaires.
e e
e
Consid´rons la table clients dans laquelle nous stockons d´j` le num´ro, le nom et le code pose
ea
e
tal. Nous souhaitons d´sormais stocker ´galement le num´ro de t´l´phone, l’adresse courier et l’adresse
e
e
e
ee
´lectronique. La premi`re id´e consiste ` ajouter trois colonnes suppl´mentaires dans la table clients.
e
e
e
a
e
Mais pour les clients qui ont d´j` ´t´ saisis dans la table, ces trois colonnes seront vides.
eaee
Pour gagner de la place, ces trois colonnes peuvent constituer une nouvelle table annuaire clients
dont la cl´ primaire r´f´rence celle de la table clients (figure 43). Formellement, annuaire clients est
e
ee
issue d’une sous-entit´ de l’entit´ clients.
e
e
clients
numéro de client
- n° client
- nom
- code postal
nom
code postal
téléphone
clients
- n° client
- nom
- code postal
traduction
traduction
annuaire clients
adresse
numéro de client
email
- téléphone
- adresse
- email
annuaire clients
-
# n° client
téléphone
adresse
email
Fig. 43 – S´paration des informations compl´mentaires par h´ritage
e
e
e
La configuration d’h´ritage sur le sch´ma relationnel (figure 43 a droite) constituera une occasion
e
e
`
d’´crire des requˆtes SQL avec des jointures externes (c’est-`-dire facultatives).
e
e
a
www.tifawt.com
40. 5
www.tifawt.com
´
COMPLEMENTS
5.3.3
40
Sp´cialisation des associations
e
La notion d’h´ritage est valable ´galement pour les associations. Nous pouvons donc faire appel `
e
e
a
des sous-associations avec des attributs sp´cifiques et des associations g´n´riques qui contiennent les
e
e e
attributs communs. Mais sans aller jusqu’` l’introduction de sous-associations, d`s qu’un sch´ma entit´sa
e
e
e
associations fait appel ` des sous-entit´s, il est fr´quent que les associations concern´es par ces sous-entit´s
a
e
e
e
e
soient elles-mˆmes sp´cialis´es .
e
e
e
Consid´rons une entreprise artisanale qui vend non seulement des articles produits en s´rie ` prix
e
e
a
unitaire fixe, mais aussi des articles fait sur mesure et dont le prix unitaire est calcul´ ` partir de la
e a
dur´e de confection et d’un taux horaire. Dans ce cas, non seulement l’entit´ articles est sp´cialis´e
e
e
e
e
en articles en s´rie et articles sur mesure, mais en plus, l’association concerner entre les entit´s
e
e
commandes et article est sp´cialis´e selon qu’il s’agit d’un article en s´rie ou sur mesure (figure 44 au
e
e
e
centre).
numéro d’article
numéro d’article
quantité
prix unitaire de vente
désignation
tra
numéro d’article
durée
numéro de commande
taux horaire de facturation
du
ct i
on
concerner (1)
articles en série
articles
0,n
- quantité
commandée
commandes
- n° commande
1,n - date commande
articles sur mesure
- taux horaire
de facturation
- durée
1,n
1,1
concerner (2)
articles
- n° article
- désignation
articles sur mesure
- #n° article
- taux horaire
de facturation
- durée
- #n° commande
(non vide)
lignes de
commandes
tr a
articles en série
- #n° article
- prix unitaire
de vente
du
c ti
on
- n° article
- désignation
- prix unitaire
de vente
- #n° commande
- #n° article
- quantité
commandée
commandes
- n° commande
- date commande
Fig. 44 – Sp´cialisation des associations en pr´sence de sous-entit´s
e
e
e
Le fait d’avoir volontairement d´doubler l’identifiant commun des entit´s en h´ritage, permet d’utilie
e
e
ser chaque identifiant dupliqu´ dans l’association qui le concerne.
e
Sur le sch´ma relationnel (figure 44 en bas), les associations sp´cialis´es sont traduites de mani`re
e
e
e
e
`
classique. A charge ensuite pour le d´veloppeur du formulaire de facturation, d’effectuer la r´union des
e
e
articles command´s.
e
www.tifawt.com
41. www.tifawt.com
CONCLUSION
41
Conclusion
Avec la pratique, vient un moment o` le concepteur peut se passer du mod`le entit´s-associations
u
e
e
et produire directement des sch´mas relationnels corrects. Pourtant, continuer de travailler ` un niveau
e
a
conceptuel plutˆt qu’` un niveau logique reste une tactique payante pour lui, dans la mesure o` les
o
a
u
donn´es pourtant stock´es sous une forme relationnelle, doivent de nos jours ˆtre acc´d´es par des applie
e
e
e e
cations orient´es objet. Le mod`le conceptuel permet de faire le lien entre d’une part la repr´sentation
e
e
e
objet des donn´es et d’autre le stockage relationnel des mˆmes donn´es.
e
e
e
Par exemple, on peut tr`s bien imaginer qu’un sch´ma entit´s-associations soit d’un cˆt´ traduit en
e
e
e
oe
un sch´ma relationnel puis impl´ment´ dans une base de donn´es Oracle ; tandis qu’en parall`le, il est
e
e
e
e
e
traduit en un diagramme de classe (mod`le logique objet), lui-mˆme impl´ment´ dans un ensemble de
e
e
e
e
classes Java. Ces classes Java permettent ensuite aux d´veloppeurs de construire des applications clientes
e
orient´es objet et qui attaquent de mani`re transparente les donn´es de la base Oracle. Il s’agit d’une
e
e
e
solution de passage entre la mod´lisation orient´e objet (pertinente pour d´velopper des interfaces grae
e
e
phiques) et la mod´lisation relationnelle (pertinente pour g´rer les donn´es).
e
e
e
Par ailleurs, la m´thodologie Merise est certes typiquement fran¸aise, mais en Grande-Bretagne, la
e
c
m´thodologie standard s’appelle SSADM (Structured Systems Analysis ans Design Method) et repose
e
sur les mˆmes principes. Les nord-am´ricains quant ` eux utilisent ce qu’on appelle des diagrammes de
e
e
a
flux, dont les principes sont repris par la version 2 de Merise.
Aujourd’hui, ce sont les mod´lisations objets et leur unification UML (Unified Modeling Language,
e
autrement dit langage unifi´ de mod´lisation) qui se placent ` la pointe de l’´tat de l’art. Malheureusee
e
a
e
ment, UML n’est qu’un ensemble de notations (d’ailleurs moins intuitives que celles des sch´mas entit´se
e
7 ). La connaissance de ce langage ne permet donc pas au concepteur de faire l’´conomie d’une
associations
e
m´thodologie de conception. Voil` pourquoi il n’est pas anachronique de r´-´diter en 2005 un document
e
a
ee
sur des m´thodes qui auront bientˆt 30 ans ;-)
e
o
R´f´rences
ee
[Akoka et Comyn-Wattiau] Akoka, J. et Comyn-Wattiau I. Conception de bases de donn´es relatione
nelles. Vuibert Informatique.
Ce livre tr`s didactique contient de bon exercices sur la phase de conception d’un syst`me d’ine
e
formation.
[Gabay] Gabay, J. Apprendre et pratiquer Merise. Masson, 1989.
Ce livre tr`s synth´tique permet de s’exercer sur la m´thode.
e
e
e
[Matheron] Matheron, J.-P. Comprendre Merise. Eyrolles, 1994.
Cet ouvrage tr`s accessible permet vraiment de comprendre la m´thode.
e
e
[Nanci et al.] Nanci, D., Espinasse, B., Cohen, B. et Heckenroth, H. Ing´nierie des syst`mes d’ine
e
formation avec Merise. Sybex, 1992.
Cet ouvrage complet d´taille la m´thode dans son ensemble.
e
e
[Panet et al.] Panet, G., Letouche, R. et Tardieu, H. Merise/2 : Mod`les et techniques Merise
e
´
avanc´s. Edition d’organisation, 1994.
e
Ce livre d´crit la version 2 de la m´thode.
e
e
[Tardieu et al.] Tardieu, H., Rochfeld, A. et Coletti, R. La m´thode Merise. Principes et outils.
e
´
Edition d’organisation, 1986.
Il s’agit-l` du livre de r´f´rence par les auteurs de la m´thode.
a
ee
e
7. qui sont facilement traduisibles en sch´mas UML, grˆce ` certains outils automatiques
e
a a
www.tifawt.com
