On utilisera la palette pour positionner les différents éléments qui composeront votre modèle
conceptuel des données.
PS : Si celle-ci n’apparaît pas à l’écran, vous avez la possibilité de l’afficher en utilisant le
menu « Outils » puis « Personnaliser les barres d’outils… ».
13
Vous devez alors cliquer sur la case « Palette » pour pouvoir l’afficher.
L’entité et les attributs
L'entité est définie comme un objet de gestion considéré d'intérêt pour représenter l'activité à
modéliser (exemple : entité Produit) et chaque entité est porteuse d'une ou plusieurs
propriétés simples (appelé attributs), dites atomiques. Exemples : CODART (qui représentera
le code du produit), LIBART (libellé du produit)...
Pour compléter votre entité, cliquez droit / propriété.
14
Sur l’onglet « Général », on indique le nom de notre entité. Pour compléter nos différents
attributs, cliquez sur l’onglet « Attributs ».
Si vous avez créé un domaine, alors c’est ici que vous devez l’indiquer. Le type de données se
sélectionne alors automatiquement.
On cochera les cases « O » s’il s’agit d’une donnée obligatoire ou facultative et « P » pour
indiquer la clé primaire. Une entité doit en effet posséder une propriété unique et
discriminante, qui est désignée comme identifiant (exemple : CODART). On reportera cette
information sur l’onglet « Identifiants ».
15
On devra préciser le type des données attendues pour chaque attribut.
Par construction, le MCD impose que tous les attributs d'une entité aient vocation à être
renseignées (il n'y a pas d’attribut « facultatif »). Les informations calculées (ex: montant
taxes comprises d'une facture), déductibles (ex: densité démographique = population /
superficie) ne doivent pas y figurer.
L'association (ou relation)
Ce sont des liaisons logiques entre les entités. Elles peuvent être de nature factuelle, ou de
nature dynamique. Par exemple, une personne peut acheter un objet (action d'acheter), mais
16
si l'on considère qu'une personne est propriétaire d'un objet, alors l'association entre l'objet et
cette personne est purement factuelle.
Les associations se représentent dans une ellipse (ou un rectangle aux extrémités rondes),
reliée par des traits aux entités qu'elles lient logiquement.
Une association peut elle aussi contenir des attributs.
La plupart des associations sont de nature binaire, c'est à dire composées de deux entités
mises en relation par une ou plusieurs associations. C'est le cas par exemple de l'association
"est propriétaire" mettant en relation "être humain" et "appartement".
Cependant il arrive qu'une association concerne plus de deux entités (on dit alors qu'il s'agit
d'association "n-aires").
17
Mais dans ce cas il y a de grandes difficultés pour exprimer les cardinalités. On aura tout
intérêt à essayer de transformer le schéma de manière à n'obtenir que des associations
binaires.
Il arrive dans certains cas que l'attribut "date" soit d'une importance capitale, notamment
dans les applications SGBDR portant sur la signature de contrats à échéance ou dans la durée
(assurance par exemple). Il n'est pas rare alors que le seul attribut "date" constitue à lui seul
une entité.
On appelle alors cela une entité temporelle. Une entité temporelle possède souvent un seul
attribut, mais dans le cas où elle possède plusieurs attributs (année, mois, jour, heure,
minute, seconde...), l'ensemble de ces attributs constitue alors la clef de l'entité.
Mais dans ce cas on peut aussi retirer cette entité et introduire la date en tant qu'attribut de
l'association "souscrit". Deux mêmes entités peuvent être plusieurs fois en association.
18
Il est permis à une association d’être branchée plusieurs fois à la même entité, comme par
exemple l’association binaire réflective suivante :
En résumé
. Une classe de relation récursive (ou réflexive) relie la même classe d'entité
. Une classe de relation binaire relie deux classes d'entité
. Une classe de relation ternaire relie trois classes d'entité
. Une classe de relation n-aire relie n classes d'entité
La dimension d’une association indique le nombre d’entités participant à l’association. Les
dimensions les plus courantes sont 2 (association binaire) et 3 (association ternaire)
Une occurrence d’association est un lien particulier qui relie deux occurrences d’entités. Le
schéma ci-dessous présente deux exemples d’occurrences de l’association « Habite ».
Remarque : Certains auteurs définissent l’identifiant d’une association comme étant la
concaténation des identifiants des entités qui participent à l’association.
19
Toute occurrence d’une association de dimension n doit être reliée à n occurrences d’entités.
Par exemple, pour une association ternaire dans laquelle participent trois entités « A », « B »
et « C », toute occurrence doit être reliées à 3 occurrences des entités respectives A, B et C.
On ne peut donc pas avoir une occurrence à 2 pattes de la forme ci-dessous.
Dans le schéma ci-dessous, les entités "Personne physique" (des êtres humains) et "Personne
morale" (des sociétés, associations, collectivités, organisations…) sont généralisées dans
l'entité "Propriétaire". On dit aussi que l'entité "Propriétaire" est une entité parente et que les
entités "Personne morale" et "Personne physique" sont des entités enfants, car il y a une
notion d’héritage...
Par exemple une entité "Être humain" est une généralisation pour toute entité faisant appel à
une personne, comme les entités "Étudiant", "Client", "Artiste", "Souscripteur", "Patient",
"Assujetti"... On les appelle aussi "entités-génériques". Certains ateliers de modélisation
représentant les données sous la forme d’entités « encapsulées ».
Les cardinalités
Les cardinalités permettent de caractériser le lien qui existe entre une entité et la relation à
laquelle elle est reliée. La cardinalité d'une relation est composée d'un couple comportant une
borne maximale et une borne minimale, intervalle dans lequel la cardinalité d'une entité peut
prendre sa valeur :
. La borne minimale (généralement 0 ou 1) décrit le nombre minimum de fois qu'une entité
peut participer à une relation
. La borne maximale (généralement 1 ou n) décrit le nombre maximum de fois qu'une entité
peut participer à une relation.
On note les cardinalités de chaque côté de l'association, sur les traits faisant la liaison entre
l'association et l'entité.
20
Dans l’exemple précédent, tout employé est dirigé par un autre employé (sauf le directeur
d’où le 0,n) et un employé peut diriger plusieurs autres employés, ce qui explique les
cardinalités sur le schéma.
Des relations différentes entre mêmes entités peuvent posséder des cardinalités
différentes. C'est même souvent le cas.
La relation « loue » est de type n:m.
La relation « réside » est de type 1:n.
La relation « possède » est de type n:m.
Pour revenir à notre cas pratique, on en déduit les cardinalités suivantes :
21
Notion d’identifiant relatif
Les identifiants relatifs font partie des extensions Merise/2. Certaines entités ont une
existence totalement dépendante d’autres entités. Dans ce cas nous avons recours à un
identifiant relatif. Dans le schéma ci-dessus, nous avons un identifiant relatif entre l’entité
LIGCOM et l’association COMPORTER qui s’écrit toujours avec une cardinalité (1,1). Une ligne
de commande ne peut exister s’il elle ne comporte pas un numéro de commande.
Règles de normalisation
. Normalisation des entités : Toutes les entités qui sont remplaçables par une association
doivent être remplacées.
. Normalisation des noms : Chaque entité doit posséder un identifiant qui caractérise ses
individus de manière unique. Le nom d’une entité, d’une association ou d’un attribut doit être
unique.
. Normalisations des identifiants : L’identifiant peut être composé de plusieurs attributs,
mais les autres attributs de l’entité doivent être dépendant de l’identifiant en entier (et non
pas une partie de cet identifiant). Ces deux premières formes normales peuvent être oubliées
si on suit le conseil de n’utiliser que des identifiants non composés de type numéro.
. Normalisation des attributs des associations : Les attributs d’une entité doivent
dépendre directement de son identifiant. Par exemple, la date de fête d’un client ne dépend
pas de son identifiant numéro de client, mais plutôt de son prénom. Elle ne doit pas figurer
dans l’entité clients, il faut donc faire une entité « calendrier » à part, en association avec
clients.
En effet, d’une part, les attributs en plusieurs exemplaires posent des problèmes d’évolutivité
du modèle (comment faire si un employé à deux adresse secondaires ?) et d’autre part, les
attributs calculables induisent un risque d’incohérence entre les valeurs des attributs de base
et celles des attributs calculés.
. Normalisation des associations : Les attributs des associations doivent dépendre des
identifiants de toutes les entités en association. Par exemple, la quantité commandée dépend
à la fois du numéro de client et du numéro d’article, par contre la date de commande non.
. Normalisation des cardinalités : Il faut éliminer les associations fantômes, redondantes
ou en plusieurs exemplaires.
Le modèle logique des données (MLD)
La transcription d'un MCD en modèle relationnel s'effectue selon quelques règles simples qui
consistent d'abord à transformer toute entité en table, avec l'identifiant comme clé primaire,
puis à observer les valeurs prises par les cardinalités maximums de chaque association pour
représenter celle-ci soit (ex : card. max 1-n ou 0-n) par l'ajout d'une clé étrangère dans une
table existante, soit (ex : card. max n-n) par la création d'une nouvelle table dont la clé
primaire est obtenue par concaténation de clés étrangères correspondant aux entités liées.
Règle n°1 : Toute entité doit être représentée par une table. Toute entité devient une table
dans laquelle les attributs deviennent des colonnes. L’identifiant de l’entité constitue alors la
clé primaire de la table.
22
Règle n°2 : Dans le cas d'entités reliées par des associations de type 1:1, les tables doivent
avoir la même clef.
Règle n°3 : Dans le cas d'entités reliées par des associations de type 1:n, chaque table
possède sa propre clef, mais la clef de l'entité côté 0,n (ou 1,n) migre vers la table côté 0,1
(ou 1,1) et devient une clef étrangère (index secondaire).
Règle n°4 : Dans le cas d'entités reliées par des associations de type n:m, une table
intermédiaire dite table de jointure, doit être créée, et doit posséder comme clef primaire une
conjonction des clefs primaires des deux tables pour lesquelles elle sert de jointure.
Règle n°5 : Cas des associations pourvues d'au moins un attribut :
. Si le type de relation est n:m, alors les attributs de l'association deviennent des attributs de
la table de jointure.
. Si le type de relation est 1:n, il convient de faire glisser les attributs vers l’entité pourvue
des cardinalités 1:1.
. Si le type de relation est 1:1, il convient de faire glisser les attributs vers l’une ou l’autre des
entités.
Avec Power AMC, le modèle logique de données se génère automatiquement si vous avez
préalablement complété comme il se doit votre Modèle Conceptuel de données. Cliquez sur
« Outils » de la barre de menu puis « Générer un Modèle Logique de Données… ».
Des options de configurations sont alors disponibles :
23
Cliquez sur « Ok » pour générer le MLD :
La base de données relationnelle PAPYRUS est constituée des relations suivantes :
PRODUIT (CODART, LIBART, STKLE, STKPHY, QTEANN, UNIMES)
ENTCOM (NUMCOM, OBSCOM, DATCOM, NUMFOU)
LIGCOM (NUMCOM, NUMLIG, CODART, QTECDE, PRIUNI, QTELIV, DERLIV)
FOURNIS (NUMFOU, NOMFOU, RUEFOU, POSFOU, VILFOU, CONFOU, SATISF)
VENDRE (CODART, NUMFOU, DELLIV, QTE1, PRIX1, QTE2, PRIX2, QTE3, PRIX3)
Modèle physique de données (MPD)
Le MPD est une implémentation particulière du MLD pour un matériel, un environnement et un
logiciel donné. Notamment, le MPD s’intéresse au stockage des données à travers le type et la
taille (en octets ou en bits) des attributs du MCD. Cela permet de prévoir la place nécessaire à
chaque table dans le cas d’un SGBDR.
Le MPD tient compte des limites matérielles et logicielles afin d’optimiser l’espace consommé
et d’optimiser le temps de calcul (qui représentent deux optimisations contradictoires). Dans
le cas d’un SGBDR, le MPD définit les index et peut être amené à accepter certaines
redondances d’information afin d’accélérer les requêtes.
Tout comme pour le modèle logique de données, avec Power AMC, le modèle physique de
données se génère automatiquement si vous avez préalablement complété comme il se doit
votre Modèle Conceptuel de données. Cliquez sur « Outils » de la barre de menu puis
« Générer un Modèle Physique de Données… ».
24
Vous devez alors configurer les différentes options et notamment le SGBD dans lequel nous
allons créer notre base de données.
Sur l’onglet « Détails » on précisera les options suivantes :
25
Nous obtenons le MPD suivant :
26
Créer la base de données
Création de la base de données sous MySQL
Les bases de données sont les ensembles ou nous allons stocker des objets tels que les tables, les
vues, les index... Il existe deux façons de créer des bases de données sous MySQL. En utilisant
l’interface proposée par « phpMyAdmin », ou bien en utilisant le code. Chacune de ces deux
méthodes possède ses avantages et ses inconvenants, il vous appartient d’adopter celle que vous
trouvez la plus productive ou bien la plus pratique.
En utilisant l’interface
Pour créer une base de données sous MySQL en utilisant le programme « phpMyAdmin »,
cliquez l’onglet « Bases de données ». Donnez un nom à votre base puis cliquez sur
« Créer ». Nous nommerons la base « Papyrus ».
Un message vous confirme la bonne exécution.
27
