Angels Livre Page 369 Mercredi, 1.

avril 2009 7:46 19

13
Rappels sur les SGBDR

Une base de données est un ensemble d’informations stockées sur un support et doté
d’une certaine organisation. Votre carnet d’adresses en est un exemple élémentaire,
l’annuaire du téléphone également, mais à une autre échelle.
L’accès rapide à l’information via des réseaux comme ceux des entreprises puis par
Internet a nécessité la création de systèmes d’organisation des données permettant un
accès rapide à l’information. Imaginez que vous deviez trouver toutes les personnes
portant le même nom dans un département donné. La consultation de l’annuaire vous
prendrait des heures. Face à de tels problèmes, l’informatisation du stockage des données
est devenue une nécessité. C’est dans ce but qu’ont été créés les SGBDR (Système de
gestion de base de données relationnelle).
L’objectif de ce chapitre n’est pas de vous fournir un cours complet sur les bases de
données, loin de là. Il s’agit simplement de rappeler les notions essentielles qui vous
permettront, à partir d’un besoin particulier de stockage d’information, de structurer les
différentes données dans une base. Pour approfondir le sujet de la conception des bases
de données et en particulier la méthode de conception UML (Unified Modeling
Language, Langage de modélisation unifié en français), mieux adaptée à la conception
orientée objet, vous pouvez vous reporter utilement à l’ouvrage de Christian Soutou,
De UML à SQL : Conception de bases de données, paru aux éditions Eyrolles.
L’organisation des données doit permettre de répondre à des contraintes précises, notam-
ment les suivantes :
• Les données doivent occuper le moins d’espace possible.
• Les redondances d’information doivent être évitées.
Angels Livre Page 370 Mercredi, 1. avril 2009 7:46 19

PHP 5
370

• Les mises à jour ou la suppression de données doivent laisser la base intègre et ne pas
créer d’incohérences.
• La recherche d’informations doit être rapide et sûre.
Vous allez donc aborder successivement les phases suivantes :
1. Élaboration du modèle d’organisation des données à l’aide de la méthode entité/asso-
ciation. Cela entraîne la création d’un modèle conceptuel de données (MCD), qui est
une représentation abstraite des données à stocker et des liens entre elles.
2. Passage du modèle ainsi créé au modèle relationnel, qui est actuellement le plus
courant. Cela entraîne la création d’un modèle logique de données (MLD), qui est la
représentation d’un modèle implantable dans un système particulier.
3. Implémentation dans un SGBDR (Système de gestion de base de données relation-
nelle) particulier, comme MySQL ou SQLite, qui font l’objet des chapitres suivants.
L’exemple qui servira de socle à tout ce chapitre est la modélisation de la base de données
nécessaire à la gestion d’un site de commerce en ligne.

Le modèle entité/association
Le nom anglais du modèle entité/association (Entity/Relationship) est à l’origine de la
confusion que l’on retrouve souvent dans la définition d’une base de données relation-
nelle (BDR). Certains auteurs définissent un BDR comme une base ayant des relations
entre tables. Or une base est dite relationnelle si elle repose sur la notion de table, qui est
la traduction du concept mathématique de relation entre ensembles. Une base de données
peut en effet être qualifiée de relationnelle et ne comporter qu’une seule table.
Le modèle entité/association permet la modélisation abstraite d’une base de données.
Il utilise un ensemble de conventions de représentation graphique pour modéliser les
différents concepts contenus dans une information et les liens qui existent entre eux.
Les schémas réalisés sont similaires à ceux de la méthode Merise et donc différents de
la notation UML.

Les entités
On appelle entité une représentation d’un ensemble d’objets réels ou abstraits qui ont
des caractéristiques communes. Une information du monde réel peut correspondre à
plusieurs entités. Cette décomposition de l’information en plusieurs entités, dont chacune
a une nature différente, constitue la première étape du travail de conception. Si vous
voulez modéliser une commande faite par un client, il apparaît en première lecture au
moins deux entités, une personne d’un côté et les articles qu’elles commande de l’autre.
Vous avez bien fait apparaître deux entités de nature différente. Chaque personne réelle
est une occurrence de l’entité générale personne.
Angels Livre Page 371 Mercredi, 1. avril 2009 7:46 19

Rappels sur les SGBDR

CHAPITRE 13
371

On distingue deux sortes d’entités :

• Les entités fortes, qui ne dépendent pas de l’existence d’une autre entité. C’est le cas,
par exemple, d’une entité représentant un personne ou un produit.
• Les entités faibles, dont l’existence dépend d’une autre entité. C’est le cas d’une entité
représentant une commande qui dépend de l’entité personne (pas de commande s’il n’y
a pas de client).
Les entités sont représentées graphiquement par des rectangles (voir figure 13-1).

Figure 13-1
Représentation des entités

Les attributs
Chaque entité a des caractéristiques particulières, que l’on retrouve dans toutes ses
occurrences. Un client a, par exemple, nécessairement un nom, un prénom, une adresse,
etc. Ces caractéristiques sont nommées attributs de l’entité.
Chaque entité doit avoir au moins un attribut, qui permet de distinguer une occurrence
d’une autre. Cet attribut particulier est la clé primaire de l’entité. Cette clé doit être
unique dans l’entité. Pour une personne, il est évidemment possible de trouver deux
personnes de même nom. Le nom est donc un mauvais candidat pour effectuer cette
distinction.
Pour distinguer deux clients, on utilise habituellement un numéro de client pour chaque
personne. La clé primaire peut être constituée de la réunion de plusieurs attributs, par
exemple, le nom et l’adresse, si nous admettons qu’il n’est pas possible que deux personnes
homonymes habitent au même endroit. L’utilisation d’une clé primaire abstraite, comme
un identifiant numérique (par exemple le numéro INSEE propre à chaque personne),
représente une solution plus sûre que le choix d’un autre attribut, et il est conseillé de
l’utiliser systématiquement.
Un attribut peut être défini comme obligatoire ou facultatif dans l’entité. Il peut être
élémentaire ou décomposable en plusieurs autres attributs. L’adresse complète d’une
personne peut constituer un seul attribut ou être décomposée en rue, ville, département
et code postal. Il n’y a pas d’obligation en ce domaine. Cela relève d’un choix du pro-
grammeur en fonction des besoins du client. S’il n’envisage pas de réaliser un jour des
recherches de personnes par ville ou par département, il est inutile de décomposer l’attri-
but adresse.
Chaque attribut possède un domaine de valeurs possibles. Un nom est représenté par une
chaîne de caractères de longueur variable et le code postal par un nombre de cinq chiffres.
À chaque attribut correspond un type de donnée particulier. C’est à prendre en compte
lors de l’implantation de la base de données sur un SGBDR particulier.
Angels Livre Page 372 Mercredi, 1. avril 2009 7:46 19

PHP 5
372

Une entité munie de ses attributs est représentée par un rectangle contenant le nom de
l’entité suivi de celui de ses attributs. Dans la représentation graphique de l’entité, le nom
de l’attribut qui constitue la clé primaire est placé en premier et souligné (voir figure 13-2).

Figure 13-2
Représentation graphique d’une entité

Les associations
Le concept d’association permet de représenter le lien existant entre deux ou plusieurs
entités. Une association reliant deux entités est dite binaire. Celle qui en relie plusieurs
est dite n-aire. Dans la décomposition de l’information en entités vous avez toujours inté-
rêt à créer des associations binaires et à redécomposer celles qui seraient ternaires.
Une association est généralement nommée à l’aide d’un verbe d’action (à la forme active
d’une entité vers l’autre et passive dans l’autre sens). Par exemple, la phrase « Un client
commande un article » résume l’association commande entre l’entité client et vers l’entité
article. Une association est représentée graphiquement par une ellipse contenant son
nom. La figure 13-3 donne la représentation graphique de cette association. Une associa-
tion peut, comme les entités, posséder des attributs. La clé de l’association est la conca-
ténation des clés des entités qu’elle relie. Une association peut être réflexive, c’est-à-dire
relier une entité à elle-même. Par exemple, l’association conjoint relie une personne avec
une autre personne.

Figure 13-3
Représentation d’une association binaire

Les cardinalités
La cardinalité d’une association mesure le nombre d’occurrences d’une entité qu’il est
possible d’associer à une occurrence de l’autre entité associée. Elles sont indiquées de
chaque coté de l’association pour chaque entité.
Angels Livre Page 373 Mercredi, 1. avril 2009 7:46 19

Rappels sur les SGBDR

CHAPITRE 13
373

On distingue des cardinalités minimales et maximales :

• La cardinalité minimale mesure le nombre minimal de participation d’une entité dans
l’association. Pour être enregistrée dans la base, une personne doit passer au moins
une commande. La cardinalité minimale du coté de l’entité personne est donc 1. Un
produit peut n’être commandé par aucune personne. La cardinalité minimale du coté
de l’entité article est donc 0. En résumé, on indique ces deux cardinalités par la nota-
tion 0.N.
• La cardinalité maximale mesure le nombre maximal de participations d’une entité
dans l’association. Une personne peut passer un nombre quelconque de commandes.
La cardinalité maximale du coté de l’entité personne est donc notée N. Un produit peut
être commandée par N personnes différentes. La cardinalité maximale du coté de
l’entité article est donc N. En résumé, on indique ces deux cardinalités par la notation
N.N. En pratique, on la note N.M pour montrer que les cardinalités ne sont pas néces-
sairement égales.
Par combinaison des différentes possibilités, on obtient quatre cardinalités possibles pour
chaque entité :
• 0.1 : zéro ou une seule au maximum ;
• 1.1 : une et une seule ;
• 0.N : zéro ou plusieurs ;
• 1.N : une ou plusieurs.
• La figure 13-4 représente l’association commande munie de ses cardinalités.

Figure 13-4
Association et cardinalités

Une association peut être définie au moyen des seules cardinalités maximales. L’associa-
tion de la figure 13-4 peut être définie par la cardinalité N:M.
Après étude des cardinalités, on distingue plusieurs cas, qui vont constituer l’organisation
des tables dans le modèle relationnel.

Détermination des cardinalités

Vous verrez dans les exemples qui suivent que la détermination des cardinalités peut
dépendre des contraintes imposées au programmeur.
Angels Livre Page 374 Mercredi, 1. avril 2009 7:46 19

PHP 5
374

Exemple 1
Un ministère comprend plusieurs services. Chaque service est dirigé par une seule
personne. Pour tenir compte des changements de directeur, l’association dirige doit avoir
un attribut date qui contienne la date de nomination. La figure 13-5 donne une représen-
tation de cette association.

Figure 13-5
Association 1:1

Une et une seule personne dirige un service, ce qui correspond à une cardinalité 1.1 pour
l’entité dirigeant. Chaque service est dirigé par une et une seule personne, ce qui se
traduit par une cardinalité 1.1 pour l’entité service.

Exemple 2
Reprenons le même ministère qu’à l’exemple 1 mais en représentant l’association entre
tous les employés du ministère, quel que soit leur grade ou le service dans lequel ils
travaillent. Une personne travaille dans un et un seul service. La cardinalité du côté de
l’entité personne est donc 1.1. Un service emploie de une personne à plusieurs personnes.
La cardinalité du côté de l’entité service est donc 1.N.
La figure 13-6 donne une représentation de cette association.

Figure 13-6
Association 1:N

Exemple 3
Pour suivre l’évolution des prix, on recense un nombre de produits vendus dans un
ensemble de magasins. Chaque magasin peut vendre un ou plusieurs produits. La cardi-
nalité du coté de l’entité magasin est donc 1.N. Chaque produit peut être vendu par un ou
Angels Livre Page 375 Mercredi, 1. avril 2009 7:46 19

Rappels sur les SGBDR

CHAPITRE 13
375

plusieurs magasins. La cardinalité du coté de l’entité produit est donc 1.N. Chaque maga-
sin vend le produit à un prix donné. L’association doit donc posséder un attribut prix.
La figure 13-7 donne une représentation de cette association.

Figure 13-7
Association N.M

Conception du MCD
Pour établir le modèle conceptuel de données (MCD) correspondant à l’ensemble
d’informations à stocker, il faut procéder de la façon suivante :
1. Décomposer l’information globale en entités indépendantes représentant des concepts
différents.
2. Pour chaque entité, faire l’inventaire des attributs qui permettent de la décrire. Le
degré de précision de cette description dépend des besoins du client et de l’utilisation
qui sera faite de la base de données. Chaque attribut doit être utile. Il faut, par exemple,
envisager quels seront les critères de recherche utilisés sur la base. Chaque attribut
doit pouvoir être exprimé clairement par une chaîne de caractères, un nombre ou une
date, par exemple.
3. Pour chaque entité, choisir l’attribut ou le groupe d’attributs qui peut constituer une
clé primaire, en évitant les clés primaires composites dans la mesure du possible.
L’utilisation d’une clé primaire numérique est souvent la meilleure solution.
4. Définir les associations qui relient les différentes entités. Il faut privilégier les associa-
tions binaires, quitte à créer des entités supplémentaires. La gestion et l’interrogation
de la base s’en trouvent facilitées.
5. Déterminer les attributs de l’association en ne retenant que les attributs vraiment
nécessaires caractérisant l’association. Si un attribut n’est pas nécessaire, mieux vaut
le placer dans une entité.
6. Exprimer les cardinalités de l’association pour chaque entité qui y est reliée.

Normalisation du MCD
Le MCD élaboré à l’étape précédente doit être vérifié et normalisé au moyen de méthodes
particulières.
Angels Livre Page 376 Mercredi, 1. avril 2009 7:46 19

PHP 5
376

Il faut introduire ici la notion de dépendance fonctionnelle (DF), proche de la notion

mathématique de fonction. On dit que deux attributs A et B sont en dépendance fonction-
nelle si, à une valeur de A, correspond, au plus, une valeur de B.
On a, par exemple, les dépendances fonctionnelles suivantes :
numéro_client → Nom_client
commune → code postal
alors que les réciproques ne sont pas vraies.
Les méthodes permettant de vérifier et de normaliser le MCD sont les suivantes :
• Chaque attribut est atomique, c’est-à-dire qu’il ne peut contenir qu’une seule valeur
choisie dans un domaine particulier. Par exemple, un attribut ne peut contenir
plusieurs noms de personnes différentes. C’est ce qu’on nomme la première forme
normale (1 N.F)
• Tous les attributs d’une entité en 1 N.F doivent dépendre complètement de la clé de
l’entité et non d’une partie seulement de la clé. C’est la deuxième forme normale
(2 N.F). Une entité en 1 N.F qui a une clé primaire composée d’un seul attribut est
nécessairement en 2 N.F.
• Tous les attributs d’une entité en 2 N.F dépendent uniquement de la clé et non d’un
autre attribut nom-clé. Si ce n’est pas le cas, il faut décomposer l’entité en deux entités
distinctes, la nouvelle entité contenant les attributs nom-clé qui sont en dépendance
fonctionnelle. C’est la troisième forme normale (3 N.F).
• Les attributs d’une association doivent être en 2 N.F et donc dépendre de toute la clé
de l’association (constituée par la concaténation des clés des entités reliées).

La base magasin en ligne

Votre objectif premier étant de modéliser la base de données d’un site de commerce en
ligne, vous devez envisager les contraintes d’utilisation de la base qui vous permettront
de créer son MCD :
1. Un client enregistré dans la base a passé au moins une commande, sinon il ne figure
pas dans la base.
2. Une commande peut contenir un ou plusieurs articles. Chaque commande a une date.
3. Le modèle doit permettre de retrouver toutes les commandes d’un client et la compo-
sition de chaque commande.
En fonction de ces contraintes, vous constatez immédiatement que le MCD de la
figure 13-4 ne convient pas. En effet, il ne prend pas en compte le fait qu’un client peut
commander plusieurs articles (contrainte n˚ 2).
Vous devez créer une entité séparée pour représenter une commande et les associations
répondant aux besoins suivants :
Angels Livre Page 377 Mercredi, 1. avril 2009 7:46 19

Rappels sur les SGBDR

CHAPITRE 13
377

• Un client passe une ou plusieurs commandes. L’association passe relie les entités
client et commande. Un client passe une ou plusieurs commandes, ce qui implique une
cardinalité 1.N du coté de l’entité client. Une commande est passée par un seul client,
ce qui implique une cardinalité 1.1 du coté de l’entité commande.
• Une commande contient un ou plusieurs articles. Vous créez donc une association
contient, qui relie les entités commande et article. La cardinalité du côté de l’entité
commande est 1.N. Un article pouvant se trouver dans aucune ou plusieurs commandes, la
cardinalité du coté de l’entité article est 0.N.
Vous obtenez finalement le MCD représenté à la figure 13-8.

Figure 13-8
Le MCD de la base magasin

Passage au modèle relationnel

La phase précédente vous a permis de créer le MCD de la base. C’est la partie la plus
importante de votre travail. Il vous faut maintenant créer le modèle logique de données
(MLD), qui permettra l’implémentation physique de la base sur des SGBDR comme
MySQL ou SQLite.

Le modèle relationnel
La théorie des SGBDR s’appuie sur les notions mathématiques de la théorie des ensembles
et des relations entre ensembles. À chaque attribut correspond un ensemble de valeurs
possibles (parfois très grand) nommé domaine.
Supposez, par exemple, que vous deviez étudier les notes attribuées à une classe de
26 élèves nommés par des lettres de A à Z et qu’il existe, pour simplifier, quatre catégo-
ries de notes de 1 à 4. À la rentrée scolaire, où tous les espoirs sont permis, il y a donc
théoriquement 26 × 4 = 104 associations (couples) possibles entre l’ensemble des élèves
et celui des notes correspondant au produit cartésien des deux ensembles, soit l’énuméra-
tion {(A,1),(A,2),(A,3),...(B1,B2),...,(Z,1),(Z,2),(Z,3),(Z,4)}. À la fin de l’année, quand
les moyennes annuelles sont faites, il n’y a plus que 26 couples réels représentant la
réalité de la classe. Cette réalité est représentée par une relation entre l’ensemble des
élèves et celui des notes. Dans le cas présent, à un élève ne correspond qu’une note, mais
à une note correspondent plusieurs élèves.
Angels Livre Page 378 Mercredi, 1. avril 2009 7:46 19

PHP 5
378

Chaque relation est représentée par une table. Vous pouvez comparer aisément une table
à une feuille de tableur que chacun doit connaître. Dans une table, on stocke les informa-
tions représentatives d’un type particulier d’objet, réel ou abstrait, comme une personne
ou une commande. Tous les objets représentés dans une même table doivent représenter
un même concept.
La représentation des notes de la classe serait donc une table à deux colonnes, chaque
colonne étant un attribut de la table. La première contient le nom et la seconde la note de
l’élève. Elle aurait au total vingt-six lignes.
La figure 13-9 donne une représentation d’une table représentant des articles. La première
ligne d’en-tête donne le nom de la table, la deuxième contient la liste des attributs, et les
suivantes contiennent les valeurs de plusieurs occurrences, chacune représentant un tuple
(ou n-uplet).

Figure 13-9
Représentation d’une table

Conception du MLD
Pour passer du MCD au MLD, il vous faut appliquer les règles suivantes :
1. Toute entité devient une table, avec pour corollaires que la table porte le nom de
l’entité, que les attributs de l’entité deviennent les colonnes de la table et que la clé
primaire de l’entité devient la clé de la table.
2. Pour une association binaire ayant des cardinalités maximales 1:1 (par exemple 1.1-
1.1), une des tables reçoit comme attribut supplémentaire une copie de la clé primaire
de l’autre table. Cet attribut devient une clé étrangère pour la table qui la reçoit. Les
attributs éventuels de l’association sont reportés dans cette même table. Au MCD
présenté à la figure 13-5 correspond le MLD de la figure 13-10 pour l’association
dirige.
Si vous voulez par exemple conserver l’historique des différents responsables d’un
service, vous devez créer une nouvelle table représentant l’association. Elle contient
les clés des deux entités reliées, et la concaténation des ces clés en constitue la clé
primaire. Cette table contient également l’attribut de l’association.
Angels Livre Page 379 Mercredi, 1. avril 2009 7:46 19

Rappels sur les SGBDR

CHAPITRE 13
379

Figure 13-10
MLD d’une association 1:1

3. Pour une association binaire ayant des cardinalités maximales de type 1:N, par exem-
ple, 1.1-1.N ou 0.1-0.N, la table représentant l’entité ayant la cardinalité 1.1 reçoit la
clé de l’autre entité comme clé étrangère. Les attributs de l’association sont ajoutés à
cette même table. Le MCD de la figure 13-6 devient le MLD présenté à la figure 13-11
pour les employés d’un service.

Figure 13-11
MLD d’une association 1:N

4. Pour une association binaire ayant des cardinalités maximales de type N:M, par
exemple, 1.N-1.N ou 0.N-1.N, l’association est toujours traduite par une table. La clé
primaire de cette table est la concaténation des clés primaires des entités reliées par
cette association. Les attributs de l’association sont ajoutés à cette nouvelle table. Le
MCD de la figure 13-7 correspond au MLD de la figure 13-12. Il s’agit d’un MCD
primaire, car il suppose qu’une personne ne peut commander qu’un article par
commande et une seule fois le même article, faute de quoi vous seriez en infraction
avec les règles définies (à une même clé primaire correspondrait deux dates diffé-
rentes).

Figure 13-12
MLD d’une association N:M
Angels Livre Page 380 Mercredi, 1. avril 2009 7:46 19

PHP 5
380

Association réflexive
Si l’association est réflexive, elle devient une table dont la clé est la concaténation des clés des deux
éléments associés. Ce serait le cas de l’association conjointe envisagée plus haut.

Le MLD de la base magasin en ligne

En appliquant les règles énoncées précédemment, le MLD de la base magasin du site
de commerce en ligne est construit à partir du MCD représenté à la figure 13-8 de la
manière suivante :
• Les entités client, commande et article deviennent des tables.
• L’association passe qui relie les entités client et commande ne devient pas une table. La
clé primaire de la table commande reçoit la clé primaire de la table client comme clé
étrangère.
• L’association contient, dont les cardinalités maximales sont de type N:M, devient une
table nommée ligne, dont chaque occurrence représente une ligne d’une commande. La
clé primaire de cette table est la concaténation des clés id_comm de la table commande et
id_article de la table article. Elle reçoit les attributs quantite et prix_unit.

L’attribut prix_unit
L’attribut prix_unit n’existe que pour permettre de retrouver la réalité d’une commande ancienne, même
après modification d’un tarif dans la table article.

La figure 13-13 présente le MLD obtenu.

Figure 13-13
MLD de la base magasin en ligne

Modèle physique de données

Le modèle physique de données est l’implémentation matérielle du MLD créé sur un
système (SGBDR) donné. Il est réalisé à l’aide du langage SQL (Structured Query
Language) et des particularités de chaque système, tel que MySQL, SQLite ou Microsoft
Access. L’apprentissage du langage SQL spécifiquement orienté vers MySQL fait l’objet
du chapitre suivant.
Angels Livre Page 381 Mercredi, 1. avril 2009 7:46 19

Rappels sur les SGBDR

CHAPITRE 13
381

Exercices
Exercice 1
Créez le MCD d’une base de données voiture qui enregistre les certificats d’immatricu-
lation des véhicules en circulation (carte grise). Elle doit répondre aux contraintes
suivantes :
• Un véhicule est d’un modèle donné identifié par un numéro de type.
• Un véhicule peut avoir un ou plusieurs propriétaires simultanément (copropriété).
• Les recherches effectuées sur la base doivent permettre de retrouver, par exemple, tous
les véhicules d’une personne, la ou les personnes propriétaires d’un véhicule dont on
connaît l’immatriculation et tous les propriétaires d’un modèle de voiture donné.
Exercice 2
Créez le MLD de la base voiture à partir du MCD de l’exercice 1. Vérifiez la conformité
du modèle par rapport aux formes normales.
Exercice 3
Créez le MCD d’une base de données tournoi permettant d’enregistrer les participants à
un tournoi de tennis et l’ensemble des matches joués en trois sets au maximum. La base
doit enregistrer les participants d’un match donné, ainsi que le gagnant et le score de
chaque set.
Exercice 4
Créez le MLD de la base tournoi, et vérifiez sa conformité.
Exercice 5
Créez le MCD d’une base permettant à un groupe de gérer les droits d’auteur des livres
publiés par ses différentes maisons d’édition. Elle doit répondre aux contraintes suivantes :
• Un livre peut être écrit par un ou plusieurs auteurs. Un auteur peut écrire un ou
plusieurs livres. Chaque auteur touche un pourcentage des droits totaux d’un livre en
fonction de sa participation.
• Un livre est publié par un seul éditeur.
Exercice 6
Créez le MLD correspondant à la base de l’exercice 5, et vérifiez sa conformité.