Académique Documents
Professionnel Documents
Culture Documents
Regional Merise
Regional Merise
ees
Cyril Gruau
17 octobre 2005 (corrige le 13 juillet 2006)
R
esum
e
Ce support de cours regroupe quelques notions concernant le modelisation conceptuelle de syst`eme
dinformation par schema entites-associations (via letude des dependances fonctionnelles), la traduction en schema relationnel et la demarche inverse (retro-conception). Il presente egalement les
extensions majeures du mod`ele conceptuel de donnees.
Remerciements
Lauteur tient `a exprimer toute sa gratitude envers Frederic Brouard pour son travail de correction
sur ce document, ses judicieux conseils et son soutien en toutes circonstances.
Cyril.Gruau@ensmp.fr
`
TABLE DES MATIERES
1 Mod`
ele conceptuel de donn
ees (MCD)
1.1 Schema entites-associations . . . . . . . . . . . . . . . . . . . . .
1.1.1 Entites et associations . . . . . . . . . . . . . . . . . . . .
1.1.2 Attributs et identifiants . . . . . . . . . . . . . . . . . . .
1.1.3 Cardinalites . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.4 Associations plurielles . . . . . . . . . . . . . . . . . . . .
1.1.5 Association reflexive . . . . . . . . . . . . . . . . . . . . .
1.1.6 Associations non binaires . . . . . . . . . . . . . . . . . .
1.2 R`egles de normalisation . . . . . . . . . . . . . . . . . . . . . . .
1.2.1 Les bonnes mani`eres dans un schema entites-associations
1.2.2 Les formes normales . . . . . . . . . . . . . . . . . . . . .
1.3 Dependances fonctionnelles . . . . . . . . . . . . . . . . . . . . .
1.3.1 Definitions et proprietes . . . . . . . . . . . . . . . . . . .
1.3.2 Graphe de couverture minimale . . . . . . . . . . . . . . .
1.3.3 Traduction vers un schema entites-associations . . . . . .
1.3.4 Gestion des dates et du caract`ere historique . . . . . . . .
1.3.5 Dependances plurielles et reflexives . . . . . . . . . . . . .
1.3.6 Associations sans attributs . . . . . . . . . . . . . . . . .
1.4 Methodologie de base . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
4
5
6
7
7
8
10
10
14
16
16
17
17
18
20
20
21
2 Mod`
ele logique de donn
ees (MLD)
2.1 Syst`emes logiques . . . . . . . . . . . . .
2.2 Mod`ele logique relationnel . . . . . . . .
2.2.1 Tables, lignes et colonnes . . . .
2.2.2 Cles primaires et cles etrang`eres
2.2.3 Schema relationnel . . . . . . . .
2.3 Traduction dun MCD en un MLDR . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
22
22
22
22
23
24
3 Mod`
ele physique de donn
ees (MPD)
3.1 Distinction entre MLD et MPD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Optimisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
27
27
4 R
etro-conception
4.1 Traduction inverse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Cas particuliers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
28
29
5 Compl
ements
5.1 Agregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1 Association de type 1 : n . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.2 Association de type n : m . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.3 Tables de codification ou tables de reference . . . . . . . . . . . . . . .
5.2 Identifiant relatif ou lien identifiant . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 Resolution dun probl`eme sur le schema relationnel . . . . . . . . . . .
5.2.2 Mod`ele conceptuel correspondant . . . . . . . . . . . . . . . . . . . . .
5.2.3 Discussion autour de la numerotation des exemplaires . . . . . . . . .
5.3 Heritage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.1 Sous-entite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.2 Utilisation de lheritage pour separer les informations complementaires
5.3.3 Specialisation des associations . . . . . . . . . . . . . . . . . . . . . . .
30
30
30
32
34
35
35
36
37
38
38
39
40
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
INTRODUCTION
Conclusion
41
R
ef
erences
41
42
Index
43
Introduction
Quand nous construisons directement les tables dune base de donnees dans un logiciel de gestion des
bases de donnees (Oracle, SQL Server, DB2, Access, MySQL, PostGre, ...), nous sommes exposes `
a deux
types de probl`eme :
nous ne savons pas toujours dans quelle table placer certaines colonnes (par exemple, ladresse de
livraison se met dans la table des clients ou dans la table des commandes?) ;
nous avons du mal `a prevoir les tables de jonction intermediaires (par exemple, la table des interpretations qui est indispensable entre les tables des films et la table des acteurs).
Il est donc necessaire de recourir `a une etape preliminaire de conception.
Les techniques presentees ici font partie de la methodologie Merise (Methode dEtude
et de Realisation
Informatique pour les Syst`emes dEntreprise) elaboree en France en 1978 [Tardieu et al.], qui permet notamment de concevoir un syst`eme dinformation dune facon standardisee et methodique.
Le but de ce support de cours est dintroduire le schema entites-associations (section 1), le schema
relationnel (sections 2 et 3) et dexpliquer la traduction entre les deux (sections 2.3 et 4). La construction
du schema entites-associations peut se faire en etudiant les dependances fonctionnelles (section 1.3) et
en tenant compte dun certain nombre dextensions conceptuelles incontournables (section 5).
Ne sont malheureusement pas abordes ici : les contraintes, les traitements, le langage relationnel et la
gestion de projet. Pour toutes ces notions importantes, car liees `a la conception de syst`emes dinformation,
le lecteur est dirige vers [Akoka et Comyn-Wattiau, Matheron, Nanci et al.]. La modelisation objet ne
fait pas non plus partie des outils exposes dans ce document.
MODELE
CONCEPTUEL DE DONNEES
(MCD)
Mod`
ele conceptuel de donn
ees (MCD)
Avant de reflechir au schema relationnel dune application, il est bon de modeliser la problematique
a traiter dun point de vue conceptuel et independamment du logiciel utilise.
`
1.1
Sch
ema entit
es-associations
La modelisation conceptuelle que nous proposons dans ce document pour un univers dont on veut stocker les donnees, conduit `a lelaboration dun type de schema tr`es repandu, le schema entites-associations.
1.1.1
Entit
es et associations
Une entite est une population dindividus homog`enes. Par exemple, les produits ou les articles vendus
par une entreprise peuvent etre regroupes dans une meme entite articles (figure 1), car dun article
a lautre, les informations ne changent pas de nature (`a chaque fois, il sagit de la designation, du prix
`
unitaire, etc.).
clients
articles
fournisseurs
numro client
nom client
prnom
adresse client
...
- numro article
- dsignation
- prix unitaire
de vente
- ...
- n fournisseur
- nom contact
- n tlphone
contact
- ...
Fig. 1 Entites
Par contre, les articles et les clients ne peuvent pas etre regroupes : leurs informations ne sont pas
homog`enes (un article ne poss`ede pas dadresse et un client ne poss`ede pas de prix unitaire). Il faut donc
leur reserver deux entites distinctes : lentite articles et lentite clients.
Une association est une liaison qui a une signification precise entre plusieurs entites. Dans notre
exemple, lassociation commander est une liaison evidente entre les entites articles et clients, tandis
que lassociation livrer etablit le lien semantique entre les entites articles et fournisseurs.
clients
-
numro client
nom client
prnom
adresse client
...
commander
- quantit
commande
- date de
commande
articles
- numro article
- dsignation
- prix unitaire
de vente
- ...
livrer
- quantit livre
- date livraison
- nom livreur
fournisseurs
- n fournisseur
- nom contact
- n tlphone
contact
- ...
Fig. 2 Associations
Remarquons que dans ce schema, les entites clients et fournisseurs ne sont pas liees directement,
mais indirectement, via lentite articles, ce qui est assez naturel.
MODELE
CONCEPTUEL DE DONNEES
(MCD)
1.1.2
Attributs et identifiants
clients
-
numro client
nom client
prnom
adresse client
...
commander
- quantit
commande
- date de
commande
articles
- numro article
- dsignation
- prix unitaire
de vente
- ...
livrer
- quantit livre
- date livraison
- nom livreur
fournisseurs
- n fournisseur
- nom contact
- n tlphone
contact
- ...
Fig. 3 Attributs
Une entite et ses attributs ne doivent traiter que dun seul sujet afin dassurer une certaine coherence
au mod`ele. Dans notre exemple, il est donc preferable de ne pas mettre les informations relatives aux
fournisseurs dans lentite des articles mais plutot dans une entite fournisseurs separees (et liee `a lentite
articles via lassociation livrer).
Ensuite, chaque individu dune entite doit etre identifiable de mani`ere unique. Cest pourquoi toutes
les entites doivent posseder un attribut sans doublon (cest-`a-dire ne prenant pas deux fois la meme
valeur). Il sagit de lidentifiant que lon souligne sur le schema, par convention. Le numero de client
constitue un identifiant classique pour lentite clients (figure 4).
clients
-
numro client
nom client
prnom
adresse client
...
commander
- quantit
commande
- date de
commande
articles
- numro article
- dsignation
- prix unitaire
de vente
- ...
livrer
- quantit livre
- date livraison
- nom livreur
Fig. 4 Identifiants
Remarques :
une entite poss`ede au moins un attribut (son identifiant) ;
au contraire, une association peut etre depourvue dattribut.
fournisseurs
- n fournisseur
- nom contact
- n tlphone
contact
- ...
MODELE
CONCEPTUEL DE DONNEES
(MCD)
1.1.3
Cardinalit
es
La cardinalite dun lien entre une entite et une association precise le minimum et le maximum de fois
quun individu de lentite peut etre concerne par lassociation.
Exemple : un client a au moins commande un article et peut commander n articles (n etant indetermine),
tandis quun article peut avoir ete commande entre 0 et n fois (meme si ce nest pas le meme n que
precedemment). On obtient alors le schema entites-associations complet 1 (figure 5).
clients
-
numro client
nom client
prnom
adresse client
...
commander
- quantit
1,n
commande
- date de
commande
articles
- numro article
0,n - dsignation
- prix unitaire
de vente
- ...
livrer
1,n - quantit livre
- date livraison
- nom livreur
fournisseurs
- n fournisseur
1,n - nom contact
- n tlphone
contact
- ...
Fig. 5 Cardinalites
Une cardinalite minimale de 1 doit se justifier par le fait que les individus de lentite en question ont
besoin de lassociation pour exister (un client nexiste pas avant davoir commande quoique ce soit, donc
la cardinalite minimale de lentite clients dans lassociation commander est 1). Dans tous les autres cas,
la cardinalite minimale vaut 0 (cest le cas pour une liste pre-etablie darticles par exemple).
Ceci dit, la discussion autour dune cardinalite minimale 0 ou 1 nest vraiment interessante que lorsque
la cardinalite maximale est 1. Nous verrons en effet lors de la traduction vers un schema relationnel (section 2.3), que lorsque la cardinalite maximale est n, nous ne pouvons pas faire la difference entre une
cardinalite minimale de 0 et une cardinalite minimale de 1.
Notons que sur notre exemple, un article peut etre commande par plusieurs clients. Cela provient du
fait que tous les crayons rouges ne sont pas numerotes individuellement, mais portent un numero darticle
collectif. En toute rigueur, notre entite articles aurait du sappeler types darticle. Ainsi, un crayon
rouge peut etre commande par plusieurs clients, ce nest simplement pas le meme crayon `a chaque fois.
Il sagit dun choix de modelisation, le lecteur peut tr`es legitimement faire le choix inverse qui consiste `
a
numeroter individuellement chaque crayon rouge.
La seule difficulte pour etablir correctement les cardinalites est de se poser les questions dans le bon
sens. Autour de lassociation commander, par exemple :
cote clients, la question est (( un client peut commander combien darticles ? )) et la reponse est
(( entre 1 et plusieurs )) ;
cote articles, la question est (( un article peut etre commande par combien de client ? )) et cette
fois-ci, la reponse est (( entre 0 et plusieurs )).
1. Le lecteur avise aura note que le schema de la figure 5 comporte des erreurs de conception. Ces erreurs seront corrigees
dans la section 1.2 dediee `
a la normalisation des schemas entites-associations.
MODELE
CONCEPTUEL DE DONNEES
(MCD)
1.1.4
Associations plurielles
Deux memes entites peuvent etre plusieurs fois en association (cest le cas sur la figure 6).
possder
- date
dacquisition
- prix achat
0,n
personnes
-
n personnel
nom
prnom
...
0,1
0,n
rsider
principalement
- date dentre
- montant du
loyer
1,1
logements
0,n
- n logement
- adresse
- ...
0,n
rsider
secondairement
- date dentre
- montant du loyer
Association r
eflexive
Il est permis `a une association detre branchee plusieurs fois `a la meme entite, comme par exemple
lassociation binaire reflexive de la figure 7.
diriger
- date dbut
0,n
0,1
employs
-
n employ
nom
fonction
adresse
...
MODELE
CONCEPTUEL DE DONNEES
(MCD)
1.1.6
Lorsquautour dune entite, toutes les associations ont pour cardinalites maximales 1 au centre et n
` lexterieur, cette entite est candidate pour etre remplacee par une association branchee `a toutes les
a
entites voisines avec des cardinalites identiques 0,n.
La deuxi`eme condition quil faut imperativement satisfaire est la r`egle de normalisation des attributs
des associations (section suivante). Cette r`egle conduit parfois `a lapparition dassociations qui etablissent
un lien semantique entre 3 entites ou plus.
Sur lexemple de la figure 8 issu dun cinema, lentite projections est uniquement entouree dassociations dont les cardinalites maximales sont 1 cote projections et n de lautre cote. De plus, la donnee
dun creneau, dun film et dune salle suffit `a determiner une projection unique 2 . On peut donc la remplacer par une association projeter branchee aux trois entites salles, cr
eneaux horaires et films.
On parle alors dassociation ternaire.
MODELE
CONCEPTUEL DE DONNEES
(MCD)
La difficulte de concevoir une association ternaire (ou plus) directement est detablir les bonnes cardinalites. Il est donc conseille den passer par un schema entites-associations dans lequel on ne trouve
que des associations binaires, puis de reperer les entites remplacables par des associations, comme sur la
figure 8 `a gauche.
Cette r`egle de conduite permet deviter dintroduire une association ternaire abusive, par exemple
entre les avions, les pilotes et les vols (figure 9), car le concepteur peut sapercevoir que lune des cardinalites maximales ne convient pas.
avions
0,n -
utiliser
1,1
vols
- numro vol
- heure de dpart
prvue
- heure darrive
prvue
numro avion
date mise en service
modle
propritaire
dparts
0,n
correspondre
- numro dpart
1,1 - date
- heure de dpart
effective
1,n
assurer
pilotes
0,n - numro pilote
- nom
- grade
occuper
0,n
- motif
0,n
0,n
crneaux horaires
dans la journe
- n crneau
- heure de dbut
salles
- n salle
- capacit
MODELE
CONCEPTUEL DE DONNEES
(MCD)
1.2
10
R`
egles de normalisation
Un bon schema entites-associations doit repondre `a 9 r`egles de normalisation, que le concepteur doit
connatre par cur.
1.2.1
tudiants
-
n tudiant
nom
prnom
adresse
enseignants
-
personnes
n enseignant
nom
prnom
adresse
fusion
n personnel
nom
prnom
adresse
clients
- numro client
- nom client
- adresse de
livraison
commandes
passer
1,n
1,1
- n commande
- date commande
- adresse de
livraison
MODELE
CONCEPTUEL DE DONNEES
(MCD)
11
occuper
employs
employs
-
n employ
nom
adresse principale
adresse secondaire
n tlphone domicile
n tlphone portable
- n employ
- nom
1,n
normalisation
possder
1,n
- type
adresses
1,n
- n adresse
- adresse
numros de tl.
1,n - n de n de tl.
- n de tlphone
- fixe ou portable
commandes
- n commande
- date commande
- montant total
figurer
1,n
- quantit
articles
- numro article
0,n - dsignation
- prix unitaire
de vente
calculable partir de
(b) Attribut calculable quil faut retirer du schema
MODELE
CONCEPTUEL DE DONNEES
(MCD)
12
clients
-
- quantit
commande
1,n
passer
articles
concerner (1)
numro client
nom client
prnom
adresse client
1,!
- numro article
0,n - dsignation
- prix unitaire
de vente
fournisseurs
concerner (2)
1,n
- n fournisseur
- nom contact
- n tlphone
contact
- quantit livre
1,n
1,n
commandes
livraisons
- n commande
- date commande
- n livraison
- date de
livraison
1,n
livrer
1,!
- nom du livreur
livraisons
livrer
1,n
- nom du livreur
1,1
- n livraison
- date de
livraison
-
MODELE
CONCEPTUEL DE DONNEES
(MCD)
13
Normalisation des associations (importante) : il faut eliminer les associations fantomes (figure 15(a)),
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 tlphone
du contact
1,1
n fournisseur
nom fournisseur
adresse
nom du contact
n tlphone
du contact
(a) les cardinalites sont toutes 1,1 donc cest une association fant
ome
rglements
payer
0,n
clients
- numro client
- nom client
0,n
1,1 - n rglement
- date rglement
- montant
factures
recevoir
1,1
correspondre
0,n
1,1 - n facture
- date facture
- montant total
(b) si un client ne peut pas regler la facture dun autre client, alors lassociation
payer est inutile et doit etre supprimee (dans le cas contraire, lassociation payer
doit etre maintenue)
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
(c) une association suffit pour remplacer les 4 associations participer en tant que ...
MODELE
CONCEPTUEL DE DONNEES
(MCD)
14
En ce qui concerne les associations redondantes, cela signifie que sil existe deux chemins pour se rendre
dune entite `a une autre, alors ils doivent avoir deux significations ou deux durees de vie differentes. Sinon, il faut supprimer le chemin le plus court, car il est deductible `a partir de lautre chemin. Dans notre
exemple de la figure 15(b), si on supprime lassociation payer, on peut retrouver le client qui a paye le
r`eglement en passant par la facture qui correspond.
Remarque : une autre solution pour le probl`eme de la figure 15(b) consiste `a retirer lentite r`
eglements
et dajouter une association r
egler avec les memes attributs (sauf lidentifiant) entre les entites clients
et factures.
Normalisation des cardinalit
es : une cardinalite minimale est toujours 0 ou 1 (et pas 2, 3 ou n)
et une cardinalite maximale est toujours 1 ou n (et pas 2, 3, ...).
Cela signifie que si une cardinalite maximale est connue et vaut 2, 3 ou plus (comme sur la figure 15(c) `
a
droite, ou pour un nombre limite demprunts dans une biblioth`eque), alors nous considerons quand meme
quelle est indeterminee et vaut n. Cela se justifie par le fait que meme si nous connaissons n au moment
de la conception, il se peut que cette valeur evolue au cours du temps. Il vaut donc mieux considerer n
comme une inconnue d`es le depart.
Cela signifie egalement quon ne modelise pas les cardinalites minimales qui valent plus de 1 car ce
genre de valeur est aussi amenee `a evoluer. Par ailleurs, avec une cardinalite maximale de 0, lassociation
naurait aucune signification.
Dans un SGBD relationnel, nous pourrions assurer les cardinalites valant 2, 3 ou plus, via lutilisation
de declencheurs. Mais cette notion nest pas abordee dans ce document qui se contente, au contraire, de
decrire ce quil est possible de faire sans utiliser de declencheur.
1.2.2
` ces 6 r`egles de normalisation, il convient dajouter les 3 premi`eres formes normales traditionnelA
lement enoncees pour les schemas relationnels, mais qui trouvent tout aussi bien leur place en ce qui
concerne les schemas entites-associations.
Premi`
ere forme normale : `a un instant donne dans une entite, pour un individu, un attribut ne
peut prendre quune valeur et non pas, un ensemble ou une liste de valeurs.
Si un attribut prend plusieurs valeurs, alors ces valeurs doivent faire lobjet dune entite supplementaire,
en association avec la premi`ere (figure 16).
livres
-
numro livre
titre
auteurs
diteur
nombre de pages
anne
livres
1
re
forme normale
numro livre
titre
diteur
nombre de pages
anne
crire
1,n
auteurs
1,n - numro auteur
- nom
Fig. 16 Application de la premi`ere forme normale : il peut y avoir plusieurs auteurs pour un livre donne
MODELE
CONCEPTUEL DE DONNEES
(MCD)
15
Deuxi`
eme forme normale : lidentifiant peut etre compose de plusieurs attributs mais les autres
attributs de lentite doivent dependre de lidentifiant en entier (et non pas une partie de cet identifiant).
Cette deuxi`eme forme normales peut etre oubliee si on suit le conseil de nutiliser que des identifiants
non composes et de type entier. En verite, elle a ete videe de sa substance par la r`egle de normalisation
des attributs des associations (page 12).
Considerons malgre tout le contre-exemple suivant : dans une entite clients dont lidentifiant est
compose des attributs nom et pr
enom, la date de fete dun client ne depend pas de son identifiant en
entier mais seulement de pr
enom. Elle ne doit pas figurer dans lentite clients, il faut donc faire une
entite calendrier `a part, en association avec lentite clients.
Troisi`
eme forme normale de Boyce-Codd (importante) : tous les attributs dune entite doivent
dependre directement de son identifiant et daucun autre attribut.
Si ce nest pas le cas, il faut placer lattribut pathologique dans une entite separee, mais en association
avec la premi`ere.
numero avion
1
2
3
constructeur
Airbus
Boeing
Airbus
mod`ele
A380
B747
A380
capacite
180
314
180
proprietaire
Air France
British Airways
KLM
Tab. 1 Il y a redondance (et donc risque dincoherence) dans les colonnes constructeur et capacit
e
Par exemple, lentite avions (figure 17 `a gauche) dont les valeurs sont donnees dans le tableau 1,
nest pas en troisi`eme forme normale de Boyce-Codd, car la capacit
e et le constructeur dun avion
ne dependent pas du num
ero davion mais de son mod`
ele. La solution normalisee est donnee figure 17 `
a
droite.
avions
-
numro avion
constructeur
modle
capacit
propritaire
modles davion
avions
3me forme normale
- numro avion
- propritaire
tre du
1,n
1,n -
numro modle
modle
constructeur
capacit
MODELE
CONCEPTUEL DE DONNEES
(MCD)
1.3
16
D
ependances fonctionnelles
Pour etablir efficacement un mod`ele entites-associations bien normalise, on peut etudier au prealable
les dependances fonctionnelles entre les attributs puis, les organiser en graphe de couverture minimale.
Cette technique est traditionnellement employee pour normaliser des schemas relationnels, mais elle
sapplique tr`es bien en amont, au niveau des mod`eles conceptuels.
1.3.1
D
efinitions et propri
et
es
directe ?
oui
oui
oui
non
MODELE
CONCEPTUEL DE DONNEES
(MCD)
1.3.2
17
En representant tous les attributs et toutes les dependances fonctionnelles directes entre eux, nous
obtenons un reseau appele graphe de couverture minimale. Dans notre exemple sur les clients, les commandes et les articles, ce graphe est donne sur la figure 19.
numro de commande
numro de client
numro darticle
date de commande
dsignation
quantit commande
nom du client
adresse du client
` partir du graphe de couverture minimale (figure 19), le schema entites-associations normalise corA
respondant apparat naturellement (figure 20), en suivant quelques etapes simples.
numro de commande
numro de client
numro darticle
date de commande
dsignation
quantit commande
nom du client
adresse du client
Fig. 20 Identification des entites et des associations sur un graphe de couverture minimale
Etape
1 : il faut reperer et souligner les identifiants.
Etape
2 : puis tous les attributs non identifiant qui dependent directement dun identifiant et dun
seul, forment une entite (avec lidentifiant, bien s
ur).
Etape
3 : ensuite, les dependances elementaires entre les identifiants forment des associations binaires
dont les cardinalites maximales sont 1 au depart de la dependance fonctionnelle et n `a larrivee.
Etape
4 : sauf si entre deux identifiants se trouvent deux dependances elementaires reflexives 5 , auquel cas lassociation binaire a deux cardinalites maximales valant 1.
5. cest `
a cause de cette etape 4 quil est preferable de ne pas traduire directement le graphe de couverture minimale en
un schema relationnel, cf. les commentaires de la r`egle 4 page 25
MODELE
CONCEPTUEL DE DONNEES
(MCD)
18
Etape
5 : enfin, les attributs (non identifiants) qui dependent de plusieurs identifiants sont les attributs dune association supplementaire dont les cardinalites maximales sont toutes n.
La traduction du graphe de couverture minimale de la figure 20 en un schema entites-associations
normalise est donnee sur la figure 21.
passer
1,1
commandes
articles
- n commande
- date commande
- numro article
- dsignation
1,n
1,n
clients
-
0,n
concerner
numro client
nom client
prnom
adresse client
- quantit
commande
Dans une biblioth`eque, on peut vouloir stocker les emprunts en cours (figure 22) et/ou les emprunts
historiques (figure 23). Pour les emprunts en cours, la date de retour prevu est un attribut de lentite
numro de livre
livres
traduction
titre
date d
emprunt
date de
retour prvu
numro de membre
nom
n livres
titre
date demprunt
date retour prvu
emprunts en
0,1
cours
membres
0,n - n membre
- nom
- adresse
adresse
MODELE
CONCEPTUEL DE DONNEES
(MCD)
19
Par contre, un livre peut faire lobjet de plusieurs emprunts historiques et dans ces conditions, la date
demprunt est determinante pour connatre la date de retour prevue (figure 23 en haut `a gauche). Or
une date nest pas un identifiant 6 et une dependance fonctionnelle ne peut partir que dun ou plusieurs
identifiant(s). Cest le signe quil manque un identifiant : le numero demprunt (figure 23 en haut `a droite).
numro de livre
numro de livre
date demprunt
date demprunt
numro demprunt
correction
titre
date de
retour prvu
date de
retour
effectif
numro de membre
nom
titre
date de
retour prvu
- n livre 0,n
- titre
concerner
1,1
adresse
ion
uct
d
a
r
emprunts historiques
-
numro de membre
nom
adresse
t
livres
date de
retour
effectif
numro demprunt
date demprunt
date de retour prvu
date retour effectif
1,1
avoir
effectuer
membres
0,n - n membre
- nom
- adresse
Fig. 23 Meme pour une entite historisee, il vaut mieux eviter que la date nentre dans lidentifiant
Notons que lentite emprunts historiques supplementaire qui apparat apr`es traduction (figure 23
en bas) ne peut pas etre transformee en une association comme on pourrait le croire au simple examen
des cardinalites qui lentourent. En effet, les attributs de lassociation qui en resulterait ne verifieraient
pas la normalisation des attributs des associations. Notamment, la date de retour effectif ne depend pas
du numero de livre et du numero de membre, mais du numero de livre et de la date demprunt.
`
La normalisation des entites ne sapplique donc pas aux entites qui ont un caract`ere historique. A
moins que les dates ne soient regroupees dans une entite separee, ce qui nest pas conseille tant quaucune
information liee aux dates (comme le caract`ere ferie, par exemple) nest necessaire.
6. Si on suit le precieux conseil de nutiliser que des entiers arbitraires et auto-incrementes comme identifiant.
MODELE
CONCEPTUEL DE DONNEES
(MCD)
1.3.5
20
D
ependances plurielles et r
eflexives
Une ou plusieurs dependances fonctionnelles peuvent partir ou arriver plusieurs fois du meme attribut. Pour clarifier la signification de chaque dependance fonctionnelle, on peut ajouter un commentaire
sur la fl`eche (figure 24). Ce commentaire sert ensuite `a donner un nom aux associations correspondantes.
pre mre
mdecin remplac
numro de mdecin
numro de remplacement
numro personnel
mdecin remplaant
nom
adresse
professionnelle
date de
dbut
date de
fin
nom
prnom
La lacune majeure de cette methode reste tout de meme le fait que les associations dont toutes les
cardinalites 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 speciale (par exemple, une dependance non
elementaire qui ne debouche sur aucun attribut).
Pour illustrer ce defaut, prenons lexemple des films et des acteurs (figure 25). Il ny a pas dattribut
numro de film
titre
dure
numro dacteur
nom de scne
films
traduction
date de naissance
- n film
- titre
- dure
jouer dans
0,n
acteurs
0,n - numro acteur
- nom de scne
- date naissance
Fig. 25 Utilisation dune dependance non elementaire et sans enfant sur un graphe de couverture
minimal
qui depende `a la fois du numero de film et du numero dacteur (`a moins dimaginer le temps dapparition
a lecran). Et pourtant, les deux entites films et acteurs sont en association. Grace `a la dependance
`
non elementaire et sans enfant, on peut rendre compte de cette situation sur le graphe de couverture
minimale et faire ainsi apparatre lassociation sur le schema entites-associations qui en est traduit.
MODELE
CONCEPTUEL DE DONNEES
(MCD)
1.4
21
M
ethodologie de base
Face `a une situation bien definie (soit `a travers un enonce precis, soit `a travers une collection de formulaires ou detats que le nouveau syst`eme dinformation est cense remplacer), nous pouvons proceder
sans etablir le graphe de couverture minimale :
identifier les entites en presence ;
lister leurs attributs ;
ajouter les identifiants (numero arbitraire et auto-incremente) ;
etablir les associations binaires entre les entites ;
lister leurs attributs ;
calculer les cardinalites ;
verifier les r`egles de normalisation et en particulier, la normalisation des entites (cest `a ce stade
quapparaissent les associations non binaires), des associations et de leurs attributs ainsi que la
troisi`eme forme normale de Boyce-Codd ;
effectuer les corrections necessaires.
Mais, il est parfois plus intuitif den passer par letude des dependances fonctionnelles directes :
identifier les entites en presence et leur donner un identifiant (numero arbitraire et auto-incremente) ;
ajouter lensemble des attributs et leur dependances fonctionnelles directes avec les identifiants (en
commencant par les dependances elementaires) ;
traduire le graphe de couverture minimale obtenu en un schema entites-associations ;
ajuster les cardinalites minimales et ;
a` ce stade, la majorite des r`egles de normalisation devraient etre verifiees, il reste tout de meme
la normalisation des noms, la presence dattributs en plusieurs exemplaires et dassociations redondantes ou en plusieurs exemplaires, `a corriger.
Il faut garder egalement `a lesprit que le mod`ele doit etre exhaustif (cest-`a-dire contenir toutes les
informations necessaires) et eviter toute redondance qui, on ne le dira jamais assez, constitue une perte
despace, une demultiplication du travail de maintenance et un risque dincoherence.
Il faut par ailleurs veiller `a eliminer les synonymes (plusieurs signifiants pour un signifie, exemple :
nom, patronyme, appellation) et les polys`emes (plusieurs signifies pour un signifiant, exemples : qualite,
statut).
Il va de soi que cette methodologie ne doit pas etre suivie pas-`a-pas une bonne fois pour toute. Au
contraire, il faut iterer plusieurs fois les etapes successives, pour esperer converger vers une modelisation
pertinente de la situation.
MODELE
LOGIQUE DE DONNEES
(MLD)
22
Mod`
ele logique de donn
ees (MLD)
Maintenant que le MCD est etabli, on peut le traduire en differents syst`emes logiques et notamment
les bases de donnees relationnelles qui proposent une vision plus concr`ete pour modeliser la situation.
2.1
Syst`
emes logiques
Avant lapparition des syst`emes de gestion de base de donnees (SGBD ou DBMS pour Data Base
Management System), les donnees etaient stockees dans des fichiers binaires et gerees par des programmes
executables (developpes en Basic, Cobol ou Dbase, par exemple). [Gabay] propose `a ce sujet une traduction dun MPD vers un MLD fichier. Mais la maintenance des programmes (en cas de modification de la
structure des donnees, notamment) etait tr`es problematique.
Sont alors apparus les SGBD hierarchiques dans lesquels les donnees sont organisees en arbre (IMSDL1 dIBM, par exemple), puis les SGBD reseaux dans lesquels les donnees sont organisees selon un
graphe plus general (IDS2 de Bull, par exemple). [Matheron, Nanci et al., Gabay] decrivent la traduction dun MPD vers un MLD Codasyl (base de donnees reseaux). Ces deux types de SGBD sont dit
navigationnels car on peut retrouver linformation `a condition den connatre le chemin dacc`es.
Aujourdhui, ils sont largement remplaces par les SGBD relationnels (SGBDR) avec lesquels linformation peut etre obtenue par une requete formulee dans un langage quasiment naturel (la langage SQL
pour Structured Query Langage). Parmi les SGBDR les plus repandus nous trouvons Oracle, SQL Server
et DB2. Nous nous contentons ici dexposer le mod`ele logique de donnees relationnel (MLDR).
Plus recemment, sont apparus le mod`ele logique oriente objet et meme des SGBD orientes objets.
Pourtant, les SGBD relationnels restent extremement majoritaires, tandis que lapproche oriente objet
est parfaitement adaptee au developpement dapplications clientes dynamiques et liees aux donnees du
syst`eme dinformation.
2.2
Mod`
ele logique relationnel
Lorsque des donnees ont la meme structure (comme par exemple, les renseignements relatifs aux
clients), on peut les organiser en table dans laquelle les colonnes decrivent les champs en commun et les
lignes contiennent les valeurs de ces champs pour chaque enregistrement (tableau 3).
numero client
1
2
3
4
...
nom
Dupont
Durand
Dubois
Dupuis
...
prenom
Michel
Jean
Claire
Marie
...
adresse
127, rue...
314, boulevard...
51, avenue...
2, impasse...
...
Tab. 3 Contenu de la table clients, avec en premi`ere ligne les intitules des colonnes
2.2.2
Cl
es primaires et cl
es
etrang`
eres
Les lignes dune table doivent etre uniques, cela signifie quune colonne (au moins) doit servir `
a les
identifier. Il sagit de la cle primaire de la table.
MODELE
LOGIQUE DE DONNEES
(MLD)
23
Labsence de valeur dans une cle primaire ne doit pas etre autorisee. Autrement dit, la valeur vide
(NULL) est interdite dans une colonne qui sert de cle primaire, ce qui nest pas forcement le cas des autres
colonnes, dont certaines peuvent ne pas etre renseignees `a toutes les lignes.
De plus, la valeur de la cle primaire dune ligne ne devrait pas, en principe, changer au cours du temps.
Par ailleurs, il se peut quune colonne Colonne1 dune table ne doive contenir que des valeurs prises
par la colonne Colonne2 dune autre table (par exemple, le numero du client sur une commande doit
correspondre `a un vrai numero de client). La Colonne2 doit etre sans doublons (bien souvent il sagit
dune cle primaire). On dit alors que la Colonne1 est cle etrang`ere et quelle reference la Colonne2.
Par convention, on souligne les cles primaires et on fait preceder les cles etrang`eres dun di`ese # dans
la description des colonnes dune table :
clients(num
ero client, nom client, pr
enom, adresse client)
commandes(num
ero commande, date de commande, #num
ero client (non vide))
Remarques :
une meme table peut avoir plusieurs cles etrang`eres mais une seule cle primaire (eventuellement
composees de plusieurs colonnes) ;
une colonne cle etrang`ere peut aussi etre primaire (dans la meme table) ;
une cle etrang`ere peut etre composee (cest le cas si la cle primaire referencee est composee) ;
implicitement, chaque colonne qui compose une cle primaire ne peut pas recevoir la valeur vide
(NULL interdit) ;
par contre, si une colonne cle etrang`ere ne doit pas recevoir la valeur vide, alors il faut le preciser
dans la description des colonnes.
Les SGBDR verifient au coup par coup que chaque cle etrang`ere ne prend pas de valeurs en dehors
de celles dej`a prises par la ou les colonne(s) quelle reference. Ce mecanisme qui agit lors de linsertion,
de la suppression ou de la mise `a jour de lignes dans les tables, garantit ce que lon appelle lintegrite
referentielle des donnees.
2.2.3
Sch
ema relationnel
On peut representer les tables dune base de donnees relationnelle par un schema relationnel dans
lequel les tables sont appelees relations et les liens entre les cles etrang`eres et leur cle primaire est symbolise par un connecteur (figure 26).
clients
commandes
numro client
nom client
prnom
adresse client
- n commande
- date commande
- #numro client
(non vide)
MODELE
LOGIQUE DE DONNEES
(MLD)
2.3
24
fournisseurs
- n fournisseur
- nom contact
- n tlphone
contact
livraisons
1,n
livrer
- n livraison
1,1 - date de
livraison
- nom livreur
fournisseurs
traduction
- n fournisseur
- nom contact
- n tlphone
contact
livraisons
- n livraison
- date de
livraison
- nom livreur
- #n fournisseur
(non vide)
MODELE
LOGIQUE DE DONNEES
(MLD)
25
R`
egle 3 : une association binaire de type n : m devient une table supplementaire (parfois appelee
table de jonction, table de jointure ou table dassociation) dont la cle primaire est composee de deux
cles etrang`eres (qui referencent les deux cles primaires des deux tables en association). Les attributs de
lassociation deviennent des colonnes de cette nouvelle table.
Par exemple, lassociation concerner (1) de la figure 13 est traduite par la table supplementaire
lignes de commande :
lignes de commande(#n commande, #n article, quantit
e command
ee)
commandes
- n commande
- date commande
1,n
concerner (1)
commandes
traduction
- quantit
commande
- n commande
- date commande
0,n
lignes de
commandes
articles
- #n commande
- #n article
- quantit
commande
- numro article
- dsignation
- prix unitaire
de vente
articles
- numro article
- dsignation
- prix unitaire
de vente
services
employs
- n employ
- nom
0,1
diriger
employs
services
1,1 - n service
- nom service
traduction
- n employ
- nom
- n service
- nom service
- #n employ
(unique, non vide)
MODELE
LOGIQUE DE DONNEES
(MLD)
26
En realite, la r`egle 4 proposee ici consid`ere quune association binaire de type 1 : 1 correspond `
a
une association binaire de type 1 : n particuli`ere. Une alternative consiste `a voir une association binaire
de type 1 : 1 comme une association binaire de type n : m particuli`ere. Il suffit pour cela dajouter une
contrainte dunicite sur chacune des cles etrang`eres de la table de jonction supplementaire :
services(n service, nom service)
directions(#n service (unique), #num
ero employ
e (unique)
employ
es(num
ero employ
es, nom)
employs
- n employ
- nom
directions
services
- #n service (unique)
- #n employ (unique)
- n service
- nom service
- n crneau
- date
- heure de dbut
- n crneau
- date
- heure de dbut
0,n
projeter
- tarif
films
0,n - n film
- titre
- dure
traduction
projections
films
#n film
#n salle
#n crneau
tarif
- n film
- titre
- dure
0,n
salles
salles
- n salle
- capacit
- n salle
- capacit
MODELE
PHYSIQUE DE DONNEES
(MPD)
27
Mod`
ele physique de donn
ees (MPD)
Un mod`ele physique de donnees est limplementation particuli`ere du mod`ele logique de donnees par
un logiciel.
3.1
La traduction dun MLD conduit `a un MPD qui precise notamment le stockage de chaque donnee `
a
travers son type et sa taille (en octets ou en bits). Cette traduction est egalement loccasion dun certain
nombre de libertes prises par rapport aux r`egles de normalisation afin doptimiser les performances du
syst`eme dinformation.
La traduction dun MLD relationnel en un mod`ele physique est la creation (par des requetes SQL
de type CREATE TABLE et ADD CONSTRAINT) dune base de donnees hebergee par un SGBD relationnel
particulier. Il peut sagir dune base Oracle, dune base SQL Server, dune base Access ou dune base DB2,
par exemple. Le fait que tous les SGBDR reposent sur le meme mod`ele logique (le schema relationnel)
permet `a la fois la communication entre des bases heterog`enes et la conversion dune base de donnees
dune SGBDR `a lautre.
3.2
Optimisations
Loptimisation des performances en temps de calcul se fait toujours au detriment de lespace memoire
consomme. Dans le pire des cas, reduire les temps de reponse consiste `a denormaliser volontairement le
syst`eme dinformation, avec tous les risques dincoherence et les probl`emes de gestion que cela comporte.
Pour les bases de donnees relationnelles, loptimisation qui vise `a accelerer les requetes peut passer
par :
lajout dindex aux tables (au minimum sur les colonnes cles primaires et cles etrang`eres) ; ces index
consomment de lespace memoire supplementaire, mais la base de donnees reste normalisee ;
lajout de colonnes calculees ou de certaines redondances pour eviter des jointures co
uteuses (auquel cas la base est denormalisee) ; il faut alors veiller `a ce que la coherence entre les colonnes
soit respectee, soit par lutilisation de declencheurs, soit dans les applications clientes du syst`eme
dinformation ;
la suppression des contraintes dunicite, de non vacuite ou encore de cle etrang`ere (auquel cas,
lintegrite des donnees doit etre assuree par le code client du syst`eme dinformation).
Par exemple, la table commandes de la figure 28 peut etre supprimee et la date de commande est
alors ajoutee `a la table lignes de commandes. On renonce donc `a la troisi`eme forme normale (figure 32)
commandes
- n commande
- date commande
lignes de
commandes
lignes de
commandes
articles
- #n commande
- #n article
- quantit
commande
- numro article
- dsignation
- prix unitaire
de vente
dnormalisation
n commande
#n article
date commande
quantit
commande
articles
- numro article
- dsignation
- prix unitaire
de vente
RETRO-CONCEPTION
28
puisque la date de commande est repetee autant de fois quil y a de lignes dans la commande, mais on
evite ainsi une jointure co
uteuse en temps de calcul lors des requetes SQL.
Le conseil le plus precieux, en mati`ere doptimisation, est de ne jamais optimiser a priori, mais toujours
a posteriori, cest-`a-dire en reponse `a une lenteur que le SGBDR nest pas capable de resoudre tout seul.
Il faut alors mesurer le gain de toute optimisation manuelle en effectuant des tests (chronometrages
avant/apr`es) sur un volume de donnees significatif et de preference en exploitation.
R
etro-conception
Dans la majorite des cas, le travail du concepteur de bases de donnees consiste non pas `a creer une
base de donnees ex nihilo, mais plutot `a corriger ou etendre une base existante. Dans ce cas, la mati`ere de
travail initiale est un mod`ele physique et la methode de retro-conception ou reverse engineering consiste
a traduire ce MPD en un mod`ele conceptuel, modifier le MCD obtenu puis modifier le mod`ele physique
`
en consequence.
4.1
Traduction inverse
Dans le cadre des bases de donnees relationnelles, il faut convertir le mod`ele physique en un schema
relationnel normalise (en detricotant les optimisations eventuelles et en renommant les colonnes des tables
pour assurer lunicite et le caract`ere explicite (non code) des noms), puis appliquer les r`egles de traduction
de la section 2.3 dans le sens inverse.
Etape
1 : chaque table dont la cle primaire ne contient pas de cle etrang`ere devient une entite dont
lidentifiant est la cle primaire de la table et dont les attributs sont les colonnes de la table qui ne sont
pas cle etrang`ere.
Etape
3 : chaque table dont la cle primaire est composee exclusivement de cles etrang`eres qui
referencent plusieurs cles primaires, devient une association autour de laquelle toutes les cardinalites
maximales valent n, cest-a-dire soit une association binaire de type n : m soit une association ternaire
ou plus (les autres colonnes non cles etrang`eres de la table deviennent des attributs de lassociation).
Etape
5 : les colonnes cles etrang`eres restantes deviennent des associations binaires de type 1 : n sil
ny a pas de contrainte dunicite ou de type 1 : 1 sil y a une contrainte dunicite (il faut trouver un nom
a cette association).
`
Etape
6 : la cardinalite minimale vaut 1 pour les cles etrang`eres qui font partie dune cle primaire
ou qui poss`edent une contrainte (non vide), sinon elle vaut 0.
RETRO-CONCEPTION
4.2
29
Cas particuliers
Malheureusement, ces quatres etapes ne suffisent pas pour traduire tous les schemas relationnels possibles. Notamment, les tables de la figure 33 necessitent linsertion detapes supplementaires.
chques
rglements
- n rglement
- date rglement
- montant
- #n rglement
- n chque
- nom banque
paiements par carte
parcours
trous
- n parcours
- nom parcours
- #n parcours
- n trou dans
parcours
- par
- distance
- #n rglement
- n carte
- date dexpiration
Etape
2 : chaque table dont la cle primaire est composee exclusivement de cles etrang`eres qui
referencent une seule cle primaire, devient une sous-entite ou une sous-association (les autres colonnes
non cles etrang`eres de la table deviennent des attributs de cette sous-entite).
Etape
4 : chaque table dont la cle primaire est composee partiellement de cles etrang`eres provient
soit dune optimisation quil faire defaire (comme sur la figure 32) soit dun identifiant relatif dune entite
comme dans la section 5.2 (auquel cas les autres colonnes non cles etrang`eres de la table deviennent des
attributs de cette entite).
COMPLEMENTS
30
Compl
ements
5.1
Agr
egation
Une association nest pas forcement etablie exclusivement entre des entites.
5.1.1
Association de type 1 : n
Considerons lexemple de la figure 34 issu du monde des courses hippiques. La dependance fonctionnelle n cheval + n course n jockey est la premi`ere dependance fonctionnelle non elementaire
vers un identifiant que nous rencontrons. Ce type de dependance fonctionnelle nous incite `a creer une
association binaire de type 1 : n entre lentite jockeys et lassociation binaire de type n : m quil y a entre
les entites chevaux et courses. Dun point de vue semantique, la logique est respectee puisque un jockey
ne monte pas un cheval, mais un cheval-qui-participe-`a-une-course.
Pour tenir compte de ce nouveau cas de dependance fonctionnelle, il convient dajouter une sixi`eme
etape `a la technique de traduction dun graphe de couverture minimal en un schema entites-associations,
telle quelle est commencee section 1.3.3 :
Etape
6 : lorsquun identifiant depend de plusieurs autres identifiants, son entite est en association
de type 1 : n avec lassociation qui lie les autres identifiants.
COMPLEMENTS
31
nom du cheval
numro de cheval
date de naissance
dossard
nom du jockey
numro de jockey
ordre darrive
prnom
lieu de la course
date de la course
tra
du
cti
on
numro 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 darrive
#n jockey
(non vide)
courses
courses
- n course
- lieu course
- date course
- n course
- lieu course
- date course
- dossard
- ordre d
arrive
jockeys
1,1
monter
0,n - n jockey
- nom jockey
- prnom
traduction
jockeys
- n jockey
- nom jockey
- prnom
COMPLEMENTS
5.1.2
32
Association de type n : m
A
donne que nous avons la
nom du
parieur
date de naissance
dossard
numro de jockey
numro de parieur
numro
de
compte
ordre darrive
montant
nom du jockey
prnom
lieu de la course
numro de course
correction
date de la course
nom du cheval
numro de cheval
nom du
parieur
date de naissance
dossard
numro de jockey
numro de parieur
numro
de
compte
ordre darrive
montant
numro de course
nom du jockey
prnom
lieu de la course
date de la course
COMPLEMENTS
33
Dans notre exemple, la traduction de la nouvelle dependance fonctionnelle en une association de type
n : m (figure 36 en haut) se fait en appliquant, comme dhabitude, letape 4 de la section 1.3.3.
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
arrive
jockeys
1,1
monter
0,n - n jockey
- nom jockey
- prnom
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 arrive
#n jockey
(non vide)
courses
- n course
- lieu course
- date course
chevaux
- n cheval
- nom cheval
- date naissance
jockeys
- n jockey
- nom jockey
- prnom
COMPLEMENTS
5.1.3
34
Certains attributs ne peuvent prendre quun jeu volontairement limite de valeurs. Cest le cas sur la
ere. Cela evite sur cet exemple quune meme
figure 37 `a gauche, pour les attributs enseignant et mati`
mati`ere ne soit decrite de deux mani`eres differentes et quun meme nom denseignant ne soit orthographie
deux fois.
semaines
dans lanne
semaines
dans lanne
- n semaine
- date de dbut
- n semaine
- date de dbut
jours
dans la semaine
- n jour
- jour
jours
dans la semaine
0,n
0,n
occuper
- enseignant
crneaux horaires
0,n - matire
dans la journe
- n crneau
- heure de dbut
0,n
correction
enseignants
- n enseignant
- nom
0,n
0,n
assurer
- n jour
- jour
0,n
crneaux horaires
dans la journe
- n crneau
- heure de dbut
0,n
occuper
1,1
1,1
concerner
0,n
0,n
salles
salles
matire
- n salle
- capacit
- n salle
- capacit
- n matire
- libell
COMPLEMENTS
5.2
35
R
esolution dun probl`
eme sur le sch
ema relationnel
Prenons par exemple le schema relationnel en haut de la figure 38, tire dune base de donnees pour
un centre de golf. Dans la table trous, la cle primaire n trou est en increment automatique, tandis que
la colonne n trou dans parcours est un nombre (generalement compris entre 1 et 18) qui correspond
a la numerotation des trous dans le parcours.
`
Le probl`eme de ce schema relationnel est quen letat, il peut y avoir un score dans la table scores
pour un trou qui nappartient pas au parcours sur lequel la partie se joue (le lecteur est invite a
` bien
observer la figure pour sen apercevoir).
participations
parcours
- n partie
- #n parcours
(non vide)
- date
- n parcours
- nom parcours
trous
- n trou
- #n parcours
(non vide)
- n trou dans
parcours
- par
- distance
- #n golfeur
- #n partie
parties
- n golfeur
- nom golfeur
- handicap
scores
-
participations
- n partie
- #n parcours
- date
golfeurs
#n golfeur
#n partie
#n trou
score
correction
parties
- #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
COMPLEMENTS
36
partie en increment automatique). Les tables trous et parties poss`edent alors une cle primaire composite et partiellement etrang`ere (figure 38 en bas).
Les cles etrang`eres des tables participations et scores qui referencent ces nouvelles cles primaires
sont alors completees par une nouvelle colonne (le numero de parcours). Dans la table des scores, comme
cette colonne n parcours nest introduite quune fois, il nest plus possible pour un joueur davoir un
score sur un trou qui nappartient pas au parcours sur lequel se joue la partie.
5.2.2
Mod`
ele conceptuel correspondant
En retro-conception, pour tenir compte du fait que le numero de parcours fera partie de la cle primaire
de la table trous sur le schema entites-associations, il suffit de mettre entre parenth`eses la cardinalite 1,1
de lassociation entre les entites trous et parcours (figure 39). Lidentifiant de lentite cote 1,1 devient
alors relatif `a celui de lautre entite en association.
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
nom du golfeur
numro de golfeur
handicap
date
score
numro de trou
dans un parcours
numro de parcours
nom du parcours
par
distance
COMPLEMENTS
5.2.3
37
Dans un magasin de location de videos, le gerant peut vouloir numeroter separement les exemplaires
de chaque video (figure 41 colonne de gauche), alors que le concepteur de la base de donnees aurait
tendance `a vouloir numeroter globalement lensemble des exemplaires (colonne de droite).
titre
date dacquisition
numro dexemplaire
numro de vido
titre
date dacquisition
numro de vido
numro dexemplaire
emprunt
emprunt
numro de membre
date de
tlphone
rservation
numro de membre
date demprunt
date de
tlphone
rservation
exemplaires
vidos
correspondre
- n vido
- titre
0,n
correspondre
0,n
membres
1,1 - n exemplaire
- date acquisition
- date emprunt
0,1
rserver
0,n - n membre
- date rservation
- nom
- tlphone
traduction
0,n
exemplaires
vidos
0,n
emprunter
traduction
(1,1) - n exemplaire
- date acquisition
- date emprunt
0,n
0,1
membres
emprunter
rserver
0,n - n membre 0,n
- date rservation
- nom
- tlphone
- n vido
- titre
nom
traduction
traduction
nom
date demprunt
vidos
- n vido
- titre
rservations
membres
- # n vido
- # n membre
- date rservation
- n membre
- nom
- tlphone
exemplaires
vidos
exemplaires
# n vido
n exemplaire
date acquisition
#n membre
date emprunt
- n vido
- titre
- # n vido
(non vide)
- n exemplaire
- date acquisition
- #n membre
- date emprunt
rservations
membres
- # n vido
- # n membre
- date rservation
- n membre
- nom
- tlphone
COMPLEMENTS
5.3
38
H
eritage
Enfin, il est parfois utile de factoriser les attributs communs `a plusieurs entites au sein dune entite
m`ere.
5.3.1
Sous-entit
e
Considerons lexemple suivant : les factures dune entreprise font lobjet dun r`eglement par ch`eque
ou par carte. Cette entreprise souhaite connatre pour chaque r`eglement la date, le montant et :
le numero et le nom de la banque des ch`eques ;
ou le numero et la date dexpiration des paiements par carte.
On a donc une entite generique r`
eglements et deux entites specialisees ch`
eques et paiements par
carte. Ces deux sous-entites de lentite r`
eglements ont des attributs propres mais pas didentifiant
propre. Au niveau logique objet, on retrouve la notion dheritage.
Conformement aux notations objets, sur le schema entites-associations, on represente le lien qui unit
une sous-entite `a son entite generique par une fl`eche creuse (figure 42 au centre). Ce lien remplace une association ^
etre de type 1 : 1 (un ch`eque (( est un )) r`eglement et un paiement par carte (( est un )) r`eglement).
numro de chque
numro de rglement
numro de facture
date de rglement
et montant
numro de rglement
rglements
- n chque
- nom banque
1,1 - n rglement
- date rglement
- montant
traduction
correspondre
numro de carte
chques
factures
- n facture
0,n
- date facture
- montant total
nom de la banque
date dexpiration
traduction
date de facture
et montant total
numro de rglement
chques
rglements
factures
- n facture
- date facture
- montant total
n rglement
date rglement
montant
#n facture
(non vide)
- #n rglement
- n chque
- nom banque
paiements par carte
- #n rglement
- n carte
- date dexpiration
COMPLEMENTS
39
une sous-entite de lentite ovales car celle-ci poss`ede davantage dattributs (centre, rayon principal,
rayon secondaire et rotation).
La traduction des sous-entites au niveau logique relationnel fait intervenir une cle primaire identique
a celle de lentite m`ere, mais dans les sous-entites la cle primaire est aussi etrang`ere (figure 42 en bas).
`
Sur le graphe de couverture minimale (figure 42 en haut), lidentifiant dont dependent les attributs
communs est volontairement duplique autant de fois que necessaire pour les attributs specialises. Nous
pouvons alors remarquer que les attributs qui dependent dun meme identifiant peuvent etre regroupes
avec des (( et )) logiques tandis que d`es quil est necessaire de faire appel `a un (( ou )) logique, cest le signe
dune specialisation.
Sur la figure 42, il est tentant de traduire directement le graphe de couverture minimale en le schema
relationnel, car il en est beaucoup plus proche que le schema entites-associations. Cest une technique
licite, `a condition de traduire correctement les associations de type 1 : 1 (etape 4 page 17).
5.3.2
Utilisation de lh
eritage pour s
eparer les informations compl
ementaires
Lheritage peut etre utilise meme lorsquil ny a quune entite specialisee. Cest utile pour stocker
dans une table separee des informations complementaires.
Considerons la table clients dans laquelle nous stockons dej`a le numero, le nom et le code postal. Nous souhaitons desormais stocker egalement le numero de telephone, ladresse courier et ladresse
electronique. La premi`ere idee consiste `a ajouter trois colonnes supplementaires dans la table clients.
Mais pour les clients qui ont dej`a ete 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 cle primaire reference celle de la table clients (figure 43). Formellement, annuaire clients est
issue dune sous-entite de lentite clients.
numro de client
nom
code postal
tlphone
clients
clients
- n client
- nom
- code postal
- n client
- nom
- code postal
traduction
traduction
annuaire clients
numro de client
adresse
email
- tlphone
- adresse
- email
annuaire clients
-
# n client
tlphone
adresse
email
COMPLEMENTS
5.3.3
40
Sp
ecialisation des associations
La notion dheritage est valable egalement pour les associations. Nous pouvons donc faire appel `
a
des sous-associations avec des attributs specifiques et des associations generiques qui contiennent les
attributs communs. Mais sans aller jusqu`a lintroduction de sous-associations, d`es quun schema entitesassociations fait appel `a des sous-entites, il est frequent que les associations concernees par ces sous-entites
soient elles-memes specialisees .
Considerons une entreprise artisanale qui vend non seulement des articles produits en serie `
a prix
unitaire fixe, mais aussi des articles fait sur mesure et dont le prix unitaire est calcule `a partir de la
duree de confection et dun taux horaire. Dans ce cas, non seulement lentite articles est specialisee
en articles en s
erie et articles sur mesure, mais en plus, lassociation concerner entre les entites
commandes et article est specialisee selon quil sagit dun article en serie ou sur mesure (figure 44 au
centre).
numro darticle
numro darticle
quantit
numro darticle
dure
numro de commande
du
ct i
on
concerner (1)
articles en srie
articles
0,n
- quantit
commande
commandes
- n commande
1,n - date commande
1,n
1,1
concerner (2)
articles
- n article
- dsignation
lignes de
commandes
tr a
articles en srie
- #n article
- prix unitaire
de vente
du
c ti
on
- n article
- dsignation
- prix unitaire
de vente
- #n commande
- #n article
- quantit
commande
commandes
- n commande
- date commande
CONCLUSION
41
Conclusion
Avec la pratique, vient un moment o`
u le concepteur peut se passer du mod`ele entites-associations
et produire directement des schemas relationnels corrects. Pourtant, continuer de travailler `a un niveau
conceptuel plutot qu`a un niveau logique reste une tactique payante pour lui, dans la mesure o`
u les
donnees pourtant stockees sous une forme relationnelle, doivent de nos jours etre accedees par des applications orientees objet. Le mod`ele conceptuel permet de faire le lien entre dune part la representation
objet des donnees et dautre le stockage relationnel des memes donnees.
Par exemple, on peut tr`es bien imaginer quun schema entites-associations soit dun cote traduit en
un schema relationnel puis implemente dans une base de donnees Oracle ; tandis quen parall`ele, il est
traduit en un diagramme de classe (mod`ele logique objet), lui-meme implemente dans un ensemble de
classes Java. Ces classes Java permettent ensuite aux developpeurs de construire des applications clientes
orientees objet et qui attaquent de mani`ere transparente les donnees de la base Oracle. Il sagit dune
solution de passage entre la modelisation orientee objet (pertinente pour developper des interfaces graphiques) et la modelisation relationnelle (pertinente pour gerer les donnees).
Par ailleurs, la methodologie Merise est certes typiquement francaise, mais en Grande-Bretagne, la
methodologie standard sappelle SSADM (Structured Systems Analysis ans Design Method) et repose
sur les memes principes. Les nord-americains quant `a eux utilisent ce quon appelle des diagrammes de
flux, dont les principes sont repris par la version 2 de Merise.
Aujourdhui, ce sont les modelisations objets et leur unification UML (Unified Modeling Language,
autrement dit langage unifie de modelisation) qui se placent `a la pointe de letat de lart. Malheureusement, UML nest quun ensemble de notations (dailleurs moins intuitives que celles des schemas entitesassociations 7 ). La connaissance de ce langage ne permet donc pas au concepteur de faire leconomie dune
methodologie de conception. Voil`a pourquoi il nest pas anachronique de re-editer en 2005 un document
sur des methodes qui auront bientot 30 ans ;-)
R
ef
erences
[Akoka et Comyn-Wattiau] Akoka, J. et Comyn-Wattiau I. Conception de bases de donnees relationnelles. Vuibert Informatique.
Ce livre tr`es didactique contient de bon exercices sur la phase de conception dun syst`eme dinformation.
[Gabay] Gabay, J. Apprendre et pratiquer Merise. Masson, 1989.
Ce livre tr`es synthetique permet de sexercer sur la methode.
[Matheron] Matheron, J.-P. Comprendre Merise. Eyrolles, 1994.
Cet ouvrage tr`es accessible permet vraiment de comprendre la methode.
[Nanci et al.] Nanci, D., Espinasse, B., Cohen, B. et Heckenroth, H. Ingenierie des syst`emes dinformation avec Merise. Sybex, 1992.
Cet ouvrage complet detaille la methode dans son ensemble.
[Panet et al.] Panet, G., Letouche, R. et Tardieu, H. Merise/2 : Mod`eles et techniques Merise
avances. Edition
dorganisation, 1994.
Ce livre decrit la version 2 de la methode.
[Tardieu et al.] Tardieu, H., Rochfeld, A. et Coletti, R. La methode Merise. Principes et outils.
Edition
dorganisation, 1986.
Il sagit-l`
a du livre de reference par les auteurs de la methode.
42
Entites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attributs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Identifiants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cardinalites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Associations plurielles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Association reflexive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Entite remplacable par une association ternaire . . . . . . . . . . . . . . . . . . . . . . . .
Contre-exemple : lentite d
eparts nest pas remplacable par une association ternaire . . .
Exemple dentite quaternaire ou 4-aire . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contre-exemples de la normalisation des noms . . . . . . . . . . . . . . . . . . . . . . . . .
Contre-exemples de la normalisation des attributs . . . . . . . . . . . . . . . . . . . . . . .
Normalisation des attributs des associations . . . . . . . . . . . . . . . . . . . . . . . . . .
Cardinalite 1,1 et attributs dune association . . . . . . . . . . . . . . . . . . . . . . . . .
Contre-exemples de la normalisation des associations . . . . . . . . . . . . . . . . . . . . .
Application de la premi`ere forme normale : il peut y avoir plusieurs auteurs pour un livre
donne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Application de la troisi`eme forme normale de Boyce-Codd . . . . . . . . . . . . . . . . . .
Dependance fonctionnelle non elementaire, mais directe . . . . . . . . . . . . . . . . . . .
Graphe de couverture minimale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Identification des entites et des associations sur un graphe de couverture minimale . . . .
Schema entites-associations normalise obtenu `a partir du graphe de couverture minimale .
Sans historisation des emprunts, pas de probl`eme . . . . . . . . . . . . . . . . . . . . . . .
Meme pour une entite historisee, il vaut mieux eviter que la date nentre dans lidentifiant
Dependances fonctionnelles commentees . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Utilisation dune dependance non elementaire et sans enfant sur un graphe de couverture
minimal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Schema relationnel simple entre deux tables . . . . . . . . . . . . . . . . . . . . . . . . . .
Traduction dune association de type 1 : n . . . . . . . . . . . . . . . . . . . . . . . . . . .
Traduction dune association de type n : m . . . . . . . . . . . . . . . . . . . . . . . . . . .
Traduction dune association de type 1 : 1 . . . . . . . . . . . . . . . . . . . . . . . . . . .
Traduction alternative dune association de type 1 : 1 . . . . . . . . . . . . . . . . . . . . .
Traduction dune association ternaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sacrifice de la troisi`eme forme normale . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tables particuli`eres en retro-conception . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Association binaire de type 1 : n (monter), liee `a une association binaire de type n : m
(participer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Association ternaire remplacee par deux associations binaires . . . . . . . . . . . . . . . .
Association binaire de type n : m (parier), liee `a une autre association binaire de type n : m
Agregation et entites de codification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Utilisation de cles primaires partiellement etrang`eres . . . . . . . . . . . . . . . . . . . . .
Representation des identifiants relatifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Representation des identifiants relatifs sur le graphe de couverture minimale . . . . . . . .
Numerotations alternatives des exemplaires . . . . . . . . . . . . . . . . . . . . . . . . . .
Representation des sous-entites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Separation des informations complementaires par heritage . . . . . . . . . . . . . . . . . .
Specialisation des associations en presence de sous-entites . . . . . . . . . . . . . . . . . .
4
4
5
5
6
7
7
8
9
9
10
11
12
12
13
14
15
16
17
17
18
18
19
20
20
23
24
25
25
26
26
27
29
31
32
33
34
35
36
36
37
38
39
40
INDEX
43
Index
transitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
diagramme de flux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
agregation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
doublon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
aspiration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4-aire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
enregistrement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
binaire
de type 1 : 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 entier auto-incremente . . . . . . . . . . . . . . . . . . . . . . . . . .11
de type 1 : n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 entite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
de codification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
de type n : m. . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
de reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
en plusieurs exemplaires . . . . . . . . . . . . . . . . . . . . 13
des dates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
fantome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
remplacable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
plurielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
redondante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
exemplaires
(numerotation) . . . . . . . . . . . . . . . . . . . . 37
reflexive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
specialisee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40 exhaustif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
ternaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
attribut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
calculable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 factorisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
en plusieurs exemplaires . . . . . . . . . . . . . . . . . . . . 11 fichier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
imaginaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12, 20 fl`eche pleine ou en pointilles . . . . . . . . . . . . . . . . . . . . 36
forme normale
deuxi`eme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
premi`ere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
cardinalite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6, 24
troisi`eme de Boyce-Codd . . . . . . . . . . . . . . . . . . . 15
maximale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
fusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
minimale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6, 14
question. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
ternaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
genericite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
cle
graphe de couverture minimale . . . . . . . . . . . . . . . . . 17
etrang`ere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
particuli`ere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
primaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Codasyl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 heritage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
coherence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5, 27 hierarchique (SGBD) . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
colonne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 historisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
commentaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 homogeneite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
G
H
contrainte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
conversion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
identifiant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5, 11
relatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
incoherence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10, 11, 15
incrementation automatique . . . . . . . . . . . . . . . . . . . . 11
index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
integrite referentielle . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
intitule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
date. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
declencheur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14, 32
dependance fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . 16
directe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
non elementaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
vers un identifiant. . . . . . . . . . . . . . . . . . . . . . . .30
non elementaire
sans enfant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 jointure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
externe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
plurielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
reflexive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
INDEX
44
SSADM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
symbole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
lien identifiant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
synonyme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
ligne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
syst`eme dinformation . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
lisibilite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
dinformations complementaires . . . . . . . . . . . . 39
MCD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
de codification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Merise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3, 41
de jonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3, 25
version 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
de reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
MLD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
des dates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
MLDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
taille
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
MPD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
traduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17, 18
transitivite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
navigationnel (SGBD) . . . . . . . . . . . . . . . . . . . . . . . . . . 22 type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
normalisation
des associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
des attributs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
des associations . . . . . . . . . . . . . . . . . . . . . . . . . . 12
des cardinalites . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
des entites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10, 19
des identifiants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
des noms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
NULL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
O
optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
oriente objet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22, 41
P
performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
polys`eme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
R
redondance . . . . . . . . . . . . . . . . . . . . . . 10, 13, 15, 21, 27
reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
requete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
reseau (SGBD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
retro-conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
reverse engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
S
schema
entites-associations . . . . . . . . . . . . . . . . . . . . . . . . . . 6
relationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
SGBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3, 22
SGBDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
sous-entite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
specialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38, 40
SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
U
UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
unicite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25, 28
V
vacuite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
vide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23