Remarques :

Les donnes qui figurent dans le MCD (et donc dans le dictionnaire des donnes)
doivent tre, dans la plupart des cas, lmentaires :
o Elles ne doivent pas tre calcules : les donnes calcules doivent tre
obtenues, par le calcul, partir de donnes lmentaires qui, elles, sont
conserves en base. Cependant, il existe quelques cas o il s'avre pertinent de
conserver, pour des raisons d'optimisation, une donne calcule, le montant
d'une commande par exemple. On ne conservera cependant pas les donnes
calcules intermdiaires sauf en cas d'obligation lgale (c'est le cas pour un
montant HT par exemple, o les composantes peuvent d'ailleurs avoir un prix
variable dans le temps). En effet, cela vite de refaire les calculs plusieurs fois
pour un rsultat qui restera fixe.
o Elles ne doivent pas tre composes : les donnes composes doivent tre
obtenues par la concatnation de donnes lmentaires conserves en base. Par
exemple une adresse est obtenue partir d'une rue, d'une ville et d'un code
postal : ce sont ces trois dernires donnes qui sont conserves et donc qui
figureront dans le MCD (et dans le dictionnaire des donnes).
Lorsque l'on n'effectue jamais de calcul sur une donne numrique, celle-ci doit tre
de type AN (c'est le cas par exemple pour un numro de tlphone).
II-C. Les dpendances fonctionnelles
Soit deux proprits (ou donnes) P1 et P2. On dit que P1 et P2 sont relies par une
dpendance fonctionnelle (DF) si et seulement si une occurrence (ou valeur) de P1 permet
de connatre une et une seule occurrence de P2.
Cette dpendance est reprsente comme ceci :
P1 P2
On dit que P1 est la source de la DF et que P2 en est le but .
Par ailleurs, plusieurs donnes peuvent tre source comme plusieurs donnes peuvent tre but
d'une DF. Exemples :
P1,P2 P3
P1 P2,P3
P1, P2 P3,P4,P5

En reprenant les donnes du dictionnaire prcdent, on peut tablir les DF suivantes :
id_em date_em, delais_em, id_i, ref_e
id_i nom_i, prenom_i, rue_i, ville_i, cp_i, tel_i, tel_port_i, email_i, date_naissance_i
ref_e id_l
id_l titre_l, annee_l, resume_l, id_t, id_ed
id_t libelle_t
id_ed nom_ed
id_a nom_a, prenom_a, date_naissance_a, nom_p
On peut dduire les conclusions suivantes de ces DF :
partir d'un numro d'emprunt, on obtient une date d'emprunt, un dlai, l'identifiant
de l'inscrit ayant effectu l'emprunt, la rfrence de l'exemplaire emprunt.
partir d'une rfrence d'exemplaire, on obtient l'identifiant du livre correspondant.
partir d'un numro de livre, on obtient son titre, son anne de parution, un rsum,
l'identifiant du type correspondant, son numro d'dition.
...
Remarque :
Une DF doit tre :
lmentaire : C'est l'intgralit de la source qui doit dterminer le but d'une DF. Par
exemple si P1 P3 alors P1,P2 P3 n'est pas lmentaire.
directe : La DF ne doit pas tre obtenue par transitivit. Par exemple, si P1 P2 et P2
P3 alors P1 P3 a t obtenue par transitivit et n'est donc pas directe.
Conclusion :
Les DF qui existent entre les donnes sont parfois videntes et ne ncessitent pas toujours une
modlisation mais celle-ci peut s'avrer utile car elle permet, entre autres, de distinguer les
futures entits du MCD et leur identifiants.
II-D. Le Modle Conceptuel de Donnes (MCD)
II-D-1. Les entits
Chaque entit est unique et est dcrite par un ensemble de proprits encore appeles attributs
ou caractristiques. Une des proprits de l'entit est l'identifiant. Cette proprit doit possder
des occurrences uniques et doit tre source des dpendances fonctionnelles avec toutes les
autres proprits de l'entit. Bien souvent, on utilise une donne de type entier qui
s'incrmente pour chaque occurrence, ou encore un code unique spcifique du contexte.
Le formalisme d'une entit est le suivant :

Ainsi, si on reprend notre dictionnaire de donnes prcdent, on schmatise par exemple une
entit Auteur comme ceci :

partir de cette entit, on peut retrouver la rgle de gestion suivante : un auteur est identifi
par un numro unique (id_a) et est caractris par un nom, un prnom et une date de
naissance.
Une entit peut n'avoir aucune, une ou plusieurs occurrences. Pour illustrer ce terme
d'occurrence qui a dj t utilis plusieurs fois, voici un exemple de table d'occurrences
de l'entit Auteur :
id_a nom_a prenom_a date_naissance_a
1 Hugo Victor 1802-02-26
2 Rimbaud Arthur 1854-10-20
3 de Maupassant Guy 1850-08-05
Cette table est compose de trois occurrences de l'entit Auteur .
Remarques :
Les occurrences sont parfois appels tuples . Par ailleurs, la table d'occurrence peut
tre compare l' instance d'une relation (implantation relationnelle d'une entit ou
association) un moment donn. Nous reviendrons sur cette notion de relation dans la
partie III.
Au niveau conceptuel, on devrait plutt parler d' entits-types , les entits tant en fait
des instances d'entits-types. Par soucis de simplicit, on gardera les termes d'entits et
associations tout au long du cours.
II-D-2. Les associations
Une association dfinit un lien smantique entre une ou plusieurs entits. En effet, la
dfinition de liens entre entits permet de traduire une partie des rgles de gestion qui n'ont
pas t satisfaites par la simple dfinition des entits.
Le formalisme d'une association est le suivant :

Gnralement le nom de l'association est un verbe dfinissant le lien entre les entits qui sont
relies par cette dernire. Par exemple :

Ici l'association tre n traduit les deux rgles de gestion suivantes :
Un auteur est n dans un et un seul pays,
Dans un pays, sont ns aucun, un ou plusieurs auteurs.
Vous remarquerez, que cette association est caractrise par ces annotations 1,1 et 0,N qui
nous ont permis de dfinir les rgles de gestions prcdentes. Ces annotations sont appeles
les cardinalits .
Une cardinalit est dfinie comme ceci :
minimum, maximum
Les cardinalits les plus rpandues sont les suivantes : 0,N ; 1,N ; 0,1 ; 1,1 . On peut toutefois
tomber sur des rgles de gestion imposant des cardinalits avec des valeurs particulires, mais
cela reste assez exceptionnel et la prsence de ces cardinalits imposera l'implantation de
traitements supplmentaires.
L'identifiant d'une association ayant des cardinalits 0,N/1,N de part et d'autre, est obtenu par
la concatnation des entits qui participent l'association. Imaginons l'association suivante :

Ici un auteur rdige au moins un ou plusieurs livres et pour chaque livre, on connat le nombre
de chapitres rdigs par l'auteur (on connat aussi le nombre total de chapitres pour chaque
livre).
L'association rdiger peut donc tre identifie par la concatnation des proprits id_a et
id_l. Ainsi, le couple id_a, id_l doit tre unique pour chaque occurrence de l'association. On
peut galement dfinir la dpendance fonctionnelle suivante :
id_a, id_l nb_chapitres
On dit que nb_chapitres (nombre de chapitres rdigs par un auteur, pour un livre) est une
donne porte par l'association rdiger. Cette association est donc une association porteuse
de donnes.
Pour une association ayant au moins une cardinalit de type 0,1 ou 1,1 considrons dans un
premier temps que cette dernire ne peut tre porteuse de donnes et qu'elle est identifie par
l'identifiant de l'entit porteuse de la cardinalit 0,1 ou 1,1.
Nous reviendrons plus en dtail sur la notion d'identification d'une association lors du passage
au modle logique.
II-D-3. laboration du MCD
Avec toutes ces connaissances, il nous est donc possible d'laborer le MCD complet partir
des donnes prsentes dans le dictionnaire des donnes :

Remarques :
Souvent, pour un mme ensemble de rgles de gestion, plusieurs solutions sont
possibles au niveau conceptuel. Par exemple, rien ne nous obligeait ici crer une
entit Type . Une simple donne porte par l'entit Livre aurait pu convenir
galement.
Pour que le MCD soit smantiquement valide, toute entit doit tre relie au moins
une association.
Les entits et les proprits peuvent tre historises. Dans ce cas on met un (H) la fin
du nom de l'entit ou de la proprit que l'on souhaite historiser (cela permet de
prciser que l'on archivera toutes les modifications sur une entit ou une proprit
donne). Cela doit galement rpondre une rgle de gestion.
Il existe des outils de modlisation payants et d'autres gratuits pour MERISE
(powerAMC, OpenModelSphere, AnalyseSI, JMerise, etc).
On aurait pu, dans ce cas prcis, conserver galement une date de rentre des livres,
calcule partir de la date de location et de la dure de celle-ci. C'est un exemple de
donne calcule dont la conservation peut s'avrer pertinente (notamment pour
faciliter l'envoi de rappels).
III.Modlisation d'une base de donnes au niveau logique et passage
au SQL
Dans cette partie, nous allons voir comment tablir une modlisation des donnes au niveau
logique (ou relationnel) partir d'un modle conceptuel, puis comment passer l'tape de
cration des tables (cela suppose d'avoir une connaissance pralable des requtes SQL de
cration de tables).
III-A. Le passage du MCD au MLD et SQL
III-A-1. Les relations
Le modle logique de donnes (MLD) est compos uniquement de ce que l'on appelle des
relations . Ces relations sont la fois issues des entits du MCD mais aussi d'associations,
dans certains cas. Ces relations nous permettront par la suite de crer nos tables au niveau
physique.
Une relation est compose d'attributs. Ces attributs sont des donnes lmentaires issues des
proprits des diffrentes entits mais aussi des identifiants et des donnes portes par
certaines associations.
Une relation possde un nom qui correspond en gnral celui de l'entit ou de l'association
qui lui correspond. Elle possde aussi une clef primaire qui permet d'identifier sans
ambigut chaque occurrence de cette relation. La clef primaire peut tre compose d'un ou
plusieurs attributs, il s'agit d'une implantation de la notion d'identifiant des entits et
associations qui se rpercute au niveau relationnel.
Voici un premier exemple de relation (issue de l'entit Edition de notre prcdant MCD) :
Edition ( id_ed , nom_ed)

Lgende :
x : relation
x : clef primaire
Remarques :
Ce premier MLD est reprsent de manire textuelle. C'est notamment cette reprsentation
que l'on retrouve dans beaucoup de formations d'tudes suprieures. Il existe toutefois une
reprsentation graphique quivalente.
Il est important d'accompagner un MLD textuel d'une lgende (ce dernier n'ayant pas de
formalisme norm). Ceci est d'ailleurs exig dans certaines formations.
Il existe un autre type de clef appel clef trangre . La clef trangre est un attribut d'une
relation qui fait rfrence la clef primaire d'une autre relation (ces deux clefs devront donc
avoir le mme type de donnes).
Compltons notre premier exemple avec une autre relation o apparat une clef trangre :
Edition ( id_ed , nom_ed)
Exemplaire ( ref_e , id_ed #)

Lgende :
x : relation
x : clef primaire
x #: clef trangre
Remarques :
Au niveau relationnel, on devrait plutt parler de clef candidate qui permet d'identifier sans
ambigut une occurrence de la relation pour les clefs primaires. De mme, on devrait
dsigner une clef trangre par une contrainte d'inclusion vers une clef candidate. Par souci
de simplicit, on gardera les termes de clefs primaires et trangres.
Par convention, on fait prcder ou suivre la clef trangre du symbole #. Ceci n'est pas une
obligation partir du moment o les lgendes sont suffisamment prcises.
Ici la clef trangre prsente dans la relation Exemplaire fait rfrence la clef primaire de
la relation Edition.
Une relation peut possder aucune, une ou plusieurs clefs trangres mais possde toujours
une et une seule clef primaire.
Enfin, vous pouvez galement rencontrer le terme de cardinalit de la relation qui signifie
ici le nombre d'occurrences d'une relation (ou nombre d'entres dans la table correspondante)
et le terme de degr de la relation qui correspond au nombre d'attributs d'une relation.