Modélisez et implémentez une base de données relationnelle avec UML

Mis à jour le 15/12/2020

Chap 1 : Appréhendez les objets et le modèle relationnel
Les bases de données servent à la collecte et à l'enregistrement d'informations.
Avant de commencer à enregistrer, vous devez décider quoi enregistrer : c'est
le domaine fonctionnel de votre projet !
Il existe différentes natures de bases de données (BD ou DB en anglais pour «
DataBase ») ou plus précisément, de systèmes de gestion de bases de données
(SGBD), présentant des caractéristiques différentes et adaptées à des contextes
particuliers. En voici les principaux :

 SGBD relationnel : les données sont représentées dans différents tableaux

pouvant être liés entre eux.
 SGBD NoSQL (clé-valeur, orienté graphe, orienté document...) : les
données sont organisées dans d'autres structures :
o clé-valeur : par exemple un dictionnaire qui à chaque mot (clé)
associe une définition (valeur)
o orienté graphe : associe à chaque élément les éléments liés (ex : les
amis d'une personne)
o ...
Dans ce cours, nous nous concentrerons sur les SGBD relationnels (SGBD-R).
Comme je l'ai évoqué dans l'introduction, nous allons organiser votre ensemble
de données de manière structurée et qui plus est, en utilisant le vocabulaire du
domaine fonctionnel de votre projet.
Pour cela, nous adoptons une approche orientée objet (AOO). Un objet
représente un concept ou une entité du monde "réel". Le domaine fonctionnel est
vu comme une composition de ces objets.
Afin de modéliser la composition d'objet de votre domaine fonctionnel, nous
allons utiliser un langage spécifique et particulièrement bien adapté : UML.
UML signifie « Unified Modeling Language ». Il s'agit d'un langage de
modélisation graphique normalisé permettant de représenter les multiples
aspects de la conception d'un système. Il propose plusieurs types de
diagrammes, chacun permettant de décrire les différentes facettes du système
(fonctionnalité, architecture logique ou physique...).
Bien qu'UML soit destiné à décrire l'organisation d'un système avec
une approche orientée objet (AOO), et non une base de données relationnelle, il
peut servir de base à sa conception en modélisant le domaine fonctionnel (grâce
au diagramme de classes).
C'est cette démarche que nous allons voir maintenant.
Que va-t-on enregistrer dans la base de données ?
Tout d'abord, vous devez définir ce que va stocker votre base de données et c'est
là qu'UML entre en scène !
Grâce au diagramme de classes UML, vous allez décrire ce que vous pensez
devoir enregistrer comme information mais aussi comment l'enregistrer (la
structuration de l'information).
Avant d'entrer dans le vif du sujet, il est utile de comprendre quelques concepts
de base de l'approche orientée objet (AOO) et leur "traduction" dans une base de
données relationnelle.
Les notions manipulées en objet
La notion d'objet
Un objet est un élément autonome. Il peut être identifié comme un élément
physique « réel » (un crayon, une voiture...) ou comme un élément abstrait ou
conceptuel (un ensemble, une liste...).
L'objet possède plusieurs caractéristiques, entre autres :

 un nom : nom commun unique, il donne le type de l'objet (ex. : voiture)

 des attributs : ce sont les propriétés de l'objet (ex. : couleur, masse à vide,
longueur...)
La notion de classe
Une classe est le modèle abstrait d'un objet. Elle définit les attributs et les
opérations de cet objet. C'est à partir de ce modèle que seront créés les objets «
concrets » possédant des valeurs particulières pour leurs attributs.
Ainsi la classe définit les caractéristiques de tous les objets de cette classe (nom,
liste des attributs).
La notion d'instance
L'instanciation est l'action de création d'un objet à partir d'une classe. Le résultat
de cette création est une instance de la classe. Les instances d'une classe sont les
occurrences d'objets correspondant à cette classe (ex. : la voiture de mon voisin).
Dans la pratique, les termes d'objet et d'instance sont souvent équivalents.
Les notions manipulées par la base de données
Comme nous l'avons vu plus haut, une base de données relationnelle est un
ensemble de tableaux (appelés « tables »). Ces tables correspondent globalement
aux classes en AOO.
Chaque colonne d'une table représente un attribut.
Chaque ligne (appelée tuple ou n-uplet) représente une instance donnant ainsi la
valeur de chaque attribut de l'objet.
Une base de données relationnelle est donc composée d'un ensemble de tables,
pouvant être liées entre elles. Cette manière d'organiser les éléments s'appuie sur
ce que l'on appelle un modèle relationnel.
Maintenant que nous avons vu les notions essentielles, nous allons commencer
la modélisation de notre domaine.
Décrire vos premières classes
Voici un exemple de classe en UML (nous allons voir cela plus en détail juste en
dessous) :

La classe « Restaurant »
Dans un diagramme de classes, une classe est représentée par une boîte
rectangulaire, comprenant plusieurs parties séparées par des traits horizontaux :

 dans la partie haute : le nom de la classe

 dans la partie en dessous : la liste des attributs.
Nous voyons ici que dans notre domaine fonctionnel nous manipulons
des Restaurants (via la classe Restaurant) et les attributs de la classes
(nom, cuisine, adresse, note) sont les informations que nous voulons enregistrer
pour chaque restaurant.
Si nous traduisons cela en base de données, nous allons créer
une table restaurant qui contiendra les
colonnes nom, cuisine, adresse, note (chaque attribut devient une colonne).
Chaque instance de restaurant sera représentée par une ligne dans cette table :
nom cuisine adresse note

Chez Luigi Italien 1 Rue d'Issy 4

Burger quid Fast food 2 Chai Watt 1

 nom cuisine adresse note

La cuisine au beurre Terroir Le Faubourg Ville 3

Au lit on dort Asiatique 10B Rue Seully 3

La mère Michelle Fruits de mer Port Salle Hutte 5

Sur le même principe, voici une autre table listant les informations relatives à un
groupe d'amis :

id prenom nom couleur_yeux

1 Chandler Bing bleu

2 Phoebe Buffay vert

3 Monica Geller bleu

4 Ross Geller marron

5 Rachel Green bleu

6 Joey Tribbiani marron

7 Phoebe Abbott bleu

Nous avons dans la table 7 tuples qui correspondent à 7 instances de la
classe Ami.
Voici la classe Ami qui correspond à cette table, avec en précision
supplémentaire le type de donnée de chaque attribut (String ce qui correspond à
du texte) :

La classe « Ami »
Vous avez sûrement remarqué dans la table la colonne id qui ne semble
correspondre à aucune caractéristique "réelle" des amis et qui n'est d'ailleurs pas
présente dans la classe Ami. Nous en reparlerons dans un prochain chapitre.
Vous avez également dû remarquer la différence d'écriture de l'attribut relatif à
la couleur des yeux. Il s'écrit couleur_yeux dans la table et couleurYeux dans la
classe. Cela n'est pas une erreur mais une convention de nommage. Nous
reviendrons plus en détail sur ce point à la fin de ce chapitre.
Nous observons d'ores et déjà des différences entre la représentation des
données à l'aide de classes UML et leur structuration dans la base de données.
Cela est tout à fait normal, car nous représentons l'information de points de vue
légèrement différents.
Mais rassurez-vous, nous allons voir comment passer de l'une à l'autre, en
introduisant un nouveau type de schéma : le modèle physique de données.
Passez du diagramme de classes au modèle physique de données
Dis-moi à quoi ressemble ta base de données...
Vous vous dites peut-être qu'autant avec un diagramme de classes on a bien une
représentation schématique de l'organisation de l'information, autant la
description des tables n'a rien de très synthétique. Et si ma base de données doit
contenir plusieurs tables, ça va vite être illisible ! C'est pas faux !
C'est ici qu'intervient un autre type de schéma : le modèle physique de
données (ou MPD) .
Le modèle physique de données provient de la méthode d'analyse et conception
de projet informatique Merise. Nous n'aborderons pas cette méthode dans ce
cours, nous ne ferons que lui emprunter ce type de schéma, parfaitement adapté
à la modélisation d'une base de données relationnelle.
Voyons comment est représentée la table ami dans un MPD :

Modèle physique de données ‒

Table « ami »
Avouez que cela ressemble beaucoup à la représentation de la classe Ami. Nous
avons ici 3 parties :
1. celle du haut contient le nom de la table
2. les deux suivantes contiennent les attributs (colonnes de la table). Ne vous
préoccupez pas de la séparation des colonnes en deux parties distinctes
pour l'instant.
Comme dans le diagramme de classes, nous précisions le type de données de
chaque attributs (VARCHAR, ce qui correspond à du texte, comme nous le
verrons plus tard).
Vous voyez apparaître des informations supplémentaires comme NOT
NULL, [ PK ]... nous y reviendrons.
Quelle démarche adopter ?
OK. C'est bien joli tout ça, mais je fais quoi moi, concrètement, devant ma
feuille blanche ?
Effectivement, nous avons vu tout un tas de notions, et il est temps de voir
comment s'en servir.
La démarche est assez simple en réalité, comme nous l'avons vu, vous vous
basez sur une approche orientée objet :
1. Vous commencez par identifier les concepts ou entités de votre domaine
fonctionnel.
=> Vous listez ainsi les classes.
2. Pour chaque classe, vous identifiez ensuite les informations à enregistrer
et leur type (texte, nombre...).
=> Vous obtenez ainsi un diagramme de classes avec leurs attributs.
3. Vous créez le modèle physique de données à partir du diagramme de
classes en :
1. créant une table pour chaque classe ;
2. créant, dans chaque table, une colonne pour chaque attribut de la
classe correspondante.
Une dernière chose avant d'entrer plus dans le détail de la conception d'une base
de données, mais qui a toute son importance : quels noms donner aux différents
éléments (classes, tables, attributs...) ?
C'est ce que nous allons voir maintenant.
Bien nommer les choses
Guitariste, Musicien, Personne ou Légende... ?
Prenons Mark Knopfler (ou Robert Johnson, Jimmy Page, Jimi Hendrix, Jack
White, Matthieu Chedid...), suivant l'information que vous souhaitez enregistrer
et le domaine fonctionnel dans lequel vous vous inscrivez, vous pouvez dire que
ce sont des guitaristes ou bien des musiciens ou simplement des personnes ou
même des légendes !
Quelques exemples :
 Pour un système d'organisation de concert, Musicien semble pertinent
 Pour un système fiscal, Personne serait plus adapté
 Pour un sondage, Guitariste ou Légende pourrait convenir...
Choisir un nom demande réflexion !
Les noms sont l'appellation des éléments constitutifs des systèmes complexes. Si
les noms ne sont pas appropriés, le système peut rapidement être inintelligible.
Si les noms sont clairs, bien choisis et partagés par tous les membres de l'équipe
projet, alors la communication sera bien plus efficace !
Puisqu'une base de données permet de sauvegarder des informations afin de
modéliser la manière dont un système fonctionne, choisir de bons noms et créer
un modèle précis d'un système nécessite de parler aux différents acteurs
concernés. Différentes personnes peuvent avoir des point de vues différents sur
un système.
Un diagramme UML est un excellent outil pour cette discussion. Et grâce à cette
discussion, vous développerez un modèle qui commencera à refléter la façon
dont son système fonctionne.
Cela nécessitera peut-être plusieurs versions successives de diagrammes UML et
plusieurs conversations avant d'arriver à une image claire du système. Mais
croyez-moi, si les composants d'un système sont nommés avec précision, le
modèle que vous créerez sera clair à la fois pour vous et pour vos clients.
Regardez le diagramme de classes ci-dessous, vous êtes en train de concevoir
une base de données pour un tourneur (organisateur de concerts) :

Votre client ne connaît peut-être pas comment fonctionne une base de données,
mais il sera en mesure de voir comment vous appelez les choses et comprendre à
peu près comment les différents éléments du domaine fonctionnel sont
représentés et liés.
Si quelque chose le dérange, il pourra discuter avec vous sur le lexique employé
ou la logique à laquelle vous pensez.
Par exemple, dans le diagramme ci-dessus, le client pourrait vous suggérer
d'utiliser le terme « Lieu » à la place de « Salle » car il organise des concerts
aussi dans des stades, sur des places publiques...
Il peut aussi critiquer (objectivement) le fait qu'un groupe est composé des
mêmes musiciens tout au long d'une même tournée.
Trouver des noms pertinents
Choisir les bons noms est important pour le schéma d'une base de données. La
précision dans la dénomination conduit à une communication précise pendant le
projet, dans l'entreprise, mais aussi dans votre code source.
Il est tout à fait normal de ne pas trouver les bon termes du premier coup. Mais
voici quelques pistes pour vous aider.
Est-ce un nom trop général ou trop spécifique ?
Vous devez choisir des noms qui ne soient ni trop spécifiques ni trop généraux.
Par exemple, si vous avez une classe représentant ce que vous vendez dans une
boulangerie, vous pouvez l'appeler Pain (baguette, gâche, boule de campagne...).
Si c'est tout ce qui est vendu, ça peut être un bon nom. Mais si en plus le
boulanger vend des viennoiseries le terme Pain devient bien plus discutable.
A contrario, si vous choisissez un nom trop général comme Article et que votre
boulanger fait aussi traiteur et distribue le journal local, vous allez peut-être
mélanger les torchons avec les serviettes (ou plutôt les miches avec les
canards) ! Dans ce cas, avoir trois
classes ArticleBoulangerie, PlatAEmporter et Journal permettrait d'avoir une
organisation plus claire.
Un exemple plus concret
Vous êtes en train de modéliser une base de données pour la gestion d'une
entreprise.
Vous aller probablement créer une table contenant les informations sur le
personnel de l'entreprise. Vous pourriez l'appeler employe.
Mais imaginez que cette table contienne en fait les informations de toutes les
personnes travaillant pour l'entreprise comme les intérimaires, les consultants...
alors le nom employe sera confus.
Un autre programmeur de votre équipe peut ne pas comprendre que la
table employe contienne plus que des employés. Potentiellement, il ou elle
créerait une autre table pour les informations sur les « travailleurs externes »
(intérimaires, consultants) en reproduisant partiellement votre table employe.
Si vous aviez compris que le client voulait mettre toutes les informations sur le
personnel (interne ou externe) dans la même table, vous auriez probablement dû
choisir un nom plus général que « Employé ». Si vous aviez nommé la
table travailleur ou main_d_oeuvre par exemple, la confusion aurait
probablement été évitée.
Donc, après avoir créé le diagramme de classes UML, révisez-le avec vos
clients. Leur retour sur vos choix de noms et votre organisation de l'information
sera très utile à la fois pour la compréhension du système mais aussi pour le
développement d'un modèle précis, cohérent et adapté au contexte.
Conventions de nommage
Les conventions de nommage sont un peu comme les règles de grammaire et
d'orthographe. Vous choisissez le lexique, mais les règles d'orthographe vous
indiquent comment écrire.
Il n'y a pas de règles absolues, mais voici celles qui sont généralement observées
:

 En UML :
o Pour le nom des classes :
 au singulier
 avec des lettres non accentuées
 commençant par une majuscule
 utilisant Pascal Case (chaque mot commence avec une
majuscule)
Ex : PierrePrecieuse
o Pour les attributs :
 au singulier
 avec des lettres non accentuées
 commençant par une minuscule
 utilisant Camel Case (chaque mot commence avec une
majuscule sauf le premier)
Ex : couleurYeux
 Dans le MPD :
o Pour le nom des tables et des attributs :
 au singulier
 avec des lettres non accentuées
 en minuscules
 utilisant Underscore Case (_)
Ex : pierre_precieuse, couleur_yeux
Le but de ces règles est de réduire les possibles erreurs de typographie et d'être
compatible avec leur mise en œuvre tant dans le code de l'application que dans
la base de données.
D'autres conventions peuvent être utilisées (comme préfixer le nom des colonnes
par le nom de la table...). Le plus important est qu'elles soient adaptées au
contexte de développement et surtout d'être cohérent dans toute la modélisation.
Dans le prochain chapitre, nous examinerons comment les classes peuvent
interagir et comment modéliser les liens qui existent entre elles.

 #

J'AI TERMINÉ CE CHAPITRE ET JE PASSE AU SUIVANT

et implémentez une base de données relationnelle avec UML

Mis à jour le 15/12/2020

Chap 2 : Décrivez votre domaine fonctionnel grâce au diagramme de classes
UML
Jusque-là, nous parlions de classes unitaires, mais un domaine c'est souvent un
ensemble de classes liées entre elles. Dans ce chapitre, nous allons aborder plus
en détail la façon de relier les classes pour former un tout. Nous verrons
comment représenter ceci en UML et comment cela se traduit en termes de base
de données relationnelle.
Lors de la modélisation d'un domaine fonctionnel, vous devez tout d'abord
comprendre quels sont les différentes entités en jeu (-> les classes) et comment
celles-ci forment un système cohérent.
Pour ce faire, dans le cadre d'un système de vente en ligne, vous pouvez poser
des questions comme :

 Qu'est-ce qui est vendu ?

 Les articles sont-ils classables en plusieurs catégories ?
 Dois-je prendre en compte le stock des articles ?
 Un client peut-il avoir des bons d'achat sur son compte ?...
Tout ce questionnement va vous permettre de vous faire une idée générale du
domaine fonctionnel en identifiant les différentes parties qui le composent et les
liens qui existe entrent elles (un Article est dans une Categorie, un Client peut
détenir des BonAchat...).
Décrivez les relations
Une base de données relationnelle s'appuie sur un modèle relationnel et donc il
s'agit d'un système possédant des relations entre ses différentes parties (les
tables).
Je me répète un peu avec le mot relation mais c'est un aspect fondamental des
bases de données relationnelles : stocker des informations regroupées par
concept (les tables) et tirer des liens entre ces concepts / tables.
UML fournit un formalisme pour décrire les relations entre les classes ainsi que
les contraintes apposées sur ces relations.
Comme nous l'avons déjà vu dans le chapitre précédent, nous avons, de manière
générale, une correspondance entre les classes du modèle objet (UML) et les
tables de la base de données (MPD).
Dans ce chapitre, nous allons nous concentrer sur la modélisation des relations
dans le diagramme de classes UML. Nous verrons leur traduction dans le
modèle physique de données (MPD) dans un prochain chapitre.
En UML, la relation entre deux classes s'appelle une association.
Dans les diagrammes UML qui vont suivre, j'ai coloré les notations UML qui
ont un rapport entre elles afin que vous visualisiez bien leurs liens. Ce n'est qu'à
but pédagogique et cela ne fait pas partie du formalisme UML.
Pour modéliser une association entre deux classes, vous tracez simplement un
trait entre elles.

Une association entre deux

classes est matérialisée par un trait
Vous pouvez, si besoin, préciser un nom pour cette association au milieu du trait
(généralement un verbe) :

Une association peut

avoir un nom
On lit alors la relation comme ceci :

 « Un musicien forme des groupes »

 « Un groupe est formé par des musiciens »
Vous pouvez également donner un rôle à chaque classe en le notant du côté des
classes concernées :

Il est
possible de préciser le rôle de chaque classe dans une association
On interprète alors la relation comme ceci :

 « Une personne, en tant que conducteur, conduit un véhicule »

 « Un véhicule, en tant moyen de locomotion, est conduit par une personne
»
Les noms et les rôles apposés sur les associations ne sont pas obligatoires, mais
ils permettent de préciser la nature de la relation. Le noms ou les rôles
deviennent indispensables si vous créez plusieurs associations entre deux
classes.
Imaginez 2 associations entre une classe Personne et une classe Livre :
 la première indique le/les auteurs d'un livre
 la deuxième indique le/les traducteurs d'un livre
Voici comment cela peut être représenté avec les noms des associations :
 Différencier des
associations avec des noms
Voici comment cela peut être représenté avec les rôles sur les associations :

Différencier des associations

avec des rôles
Les noms et rôles ne sont pas exclusifs entre eux, vous pouvez les utiliser
ensemble sur une même association. Cependant, veillez à la bonne lisibilité de
votre diagramme. Ne le surchargez pas !
De même vous n'êtes pas obligé de préciser systématiquement les rôles des deux
côtés de l'association.
Posez des limites avec les multiplicités
Les multiplicités servent à apposer des contraintes numériques sur l'association,
ou plus précisément, combien d'instances d'une classe peuvent être liées à une
instance de la classe de l'autre côté de l'association. En d'autres termes, elles
bornent les cardinalités des instances liées entre elles.
Si on reprend l'exemple du dessus avec les musiciens, il est possible de fixer le
nombre de musiciens minimum et maximum qui peuvent jouer dans un groupe.
De même il est possible de définir dans combien de groupes différents (min et
max) un même musicien peut jouer.
Voici un exemple abstrait montrant comment sont représentées les multiplicités :

Diagramme de classes ‒
Multiplicités des classes A et B
Cela s'interprète comme ceci :

 Une instance de la classe A doit être associée à au moins m et au

plus n instances de la classe B
 Une instance de la classe B doit être associée à au moins x et au
plus y instances de la classe A
Pour retenir l'ordre des multiplicités, vous pouvez utiliser la question :
Combien de moi pour l'autre ?
Ce qui donne ici :
 Combien de A pour un B ? entre x et y
 Combien de B pour un A ? entre m et n
Si je reprends l'exemple des musiciens, voici, ci-dessous, le diagramme
correspondant aux règles suivantes :

 Un musicien joue dans 5 groupes maximum, mais peut aussi ne jouer dans
aucun groupe.
 Un groupe est constitué d'au moins 2 musiciens et 10 au maximum

Diagramme de classes
‒ Exemple de multiplicités entre Musiciens et Groupes
Il est important de noter que les multiplicités imposent des limites de cardinalité
à un instant t. Dans l'exemple ci-dessus, un musicien peut avoir joué dans 50
groupes différents au cours de sa vie, mais sans jamais avoir joué dans plus de 5
groupes à la fois.
Il n'y a pas de notion d'historique dans les associations.
Concrètement nous n'aurons un lien que pour les 5 groupes actuels du musicien
et n'aurons aucune information sur ses contributions antérieures dans les 45
autres groupes.
Synthèse des multiplicités
Il existe des abréviations pour certaines plages de cardinalités. Voici un tableau
de synthèse des multiplicités, avec leur notation, leur abréviation éventuelle et
leur signification en termes de cardinalités :

Multiplicité Abréviation Cardinalités

0..0 0 Aucune instance

0..1   Aucune ou une seule instance

1..1 1 Exactement une instance

0..* * Aucune, une ou plusieurs instances (aucune

limite)

1..*   Au moins une instance (aucune limite maximum)

 Multiplicité Abréviation Cardinalités

x..x x Exactement x instance(s)

m..n   Au moins m et au plus n instances

Les 3 catégories d'association
Les associations sont classées en trois catégories en fonction des multiplicités
apposées sur celles-ci :
1. un à un (one-to-one) :

o Un conducteur conduit une et une seule voiture à la fois

o Une voiture n'est pas conduite (en stationnement) ou conduite
par un seul conducteur à la fois
2. un à plusieurs (one-to-many) ou plusieurs à un (many-to-one) :

o Un journal contient aucun (journal en préparation), un

ou plusieurs articles
o Un article est contenu dans aucun (en cours d'écriture) ou un
seul journal
3. plusieurs à plusieurs (many-to-many) :

o Un musicien fait partie d'aucun, un ou plusieurs groupes

o Un groupe est constitué de un ou plusieurs musiciens
Il est important de bien mémoriser ces trois catégories d'associations car ce sera
en fonction de celles-ci que vous traduirez les associations en relation dans la
base de données.
Dans ce chapitre nous avons vu :

 comment décrire les relations entre les différentes classes du domaine

fonctionnel,
 comment imposer des limites de cardinalité
 et les 3 catégories de relations :
o un à un (one-to-one)
 o un à plusieurs (one-to-many) ou plusieurs à un (many-to-one)
o plusieurs à plusieurs (many-to-many)
Dans le prochain chapitre, nous verrons comment mettre en œuvre ces relations
dans la base de données en commençant par s'assurer que chaque instance d'une
classe ait un identifiant unique.
Qu'est-ce que cela signifie ? C'est justement ce que nous allons aborder !

 #

J'AI TERMINÉ CE CHAPITRE ET JE PASSE AU SUIVANT

 Mis à jour le 15/12/2020
Chap 3 : Comprendre les clés primaires
Dans le chapitre précédent, vous avez vu comment définir des relations entre les
instances de différentes classes.
Vous vous rappelez sûrement qu'à une instance de classe correspond
un tuple (une ligne) dans la table.
Afin de pouvoir relier ces tuples, il faut bien les identifier de manière unique.
Si je reprends la table contenant les informations sur un groupe d'amis que je
vous donnais en exemple dans le premier chapitre :

prenom nom couleur_yeux

Chandler Bing bleu

Phoebe Buffay vert

Monica Geller bleu

Ross Geller marron

Rachel Green bleu

Joey Tribbiani marron

Phoebe Abbott bleu

Vous remarquez que pour identifier un tuple, je ne peux me baser :

 ni sur le prénom : Phoebe Buffay et Phoebe Abbott ont le même prénom

 ni sur le nom : Monica Geller et Ross Geller ont le même nom
 et encore moins sur la couleur des yeux... !
L'attribut id
Dans ce cas, afin de vous assurer de pouvoir identifier un tuple de manière
unique, il y a deux solutions :
1. identifier un tuple par le nom  ET le prénom
2. ajouter un attribut (une colonne) réservé à accueillir un identifiant unique
Je vous laisse vous rendre compte que la deuxième solution est en général plus
fiable : si un jour, le fils de Ross Geller décide d'appeler son fils Ross en
hommage à un célébrissime paléontologue, le nom et le prénom ne suffiront pas
à différencier les deux tuples !
J'ajoute donc un attribut spécifique id dans la table Ami :
id prenom nom couleur_yeux

1 Chandler Bing bleu

2 Phoebe Buffay vert

3 Monica Geller bleu

4 Ross Geller marron

5 Rachel Green bleu

6 Joey Tribbiani marron

7 Phoebe Abbott bleu

Cet attribut ne représente rien de concret, il ne sert que d'identifiant unique.
Vous pouvez l'appeler comme vous le souhaitez, mais en général, il est
nommé id ou code. Parfois, on ajoute le nom de la table en préfixe (ami_id).
Je n'ai désormais plus de problème pour identifier à coup sûr un ami de manière
unique !
Lors de la création de la table dans la base de données, cet attribut spécifique
sera indiqué comme l'identifiant des tuples de la table : c'est la clé primaire,
ou primary key (PK) en anglais.
Grâce à cette configuration, la base de données veillera à ce qu'il n'y ait aucun
doublon dans cette colonne. Il me sera impossible d'ajouter deux tuples ayant la
même valeur dans l'attribut id.
Comme nous le verrons plus loin dans le cours, il est également possible d'être
aidé par la base de données pour remplir la valeur de la clé primaire en la
qualifiant d'auto-incrémentée. Ainsi, lors de l'ajout d'un nouveau tuple dans la
table, la valeur de l'attribut est calculée automatiquement par la base de données.
La clé primaire (PK)
Dans le modèle physique de données (MPD), la clé primaire est située dans la
partie du milieu et porte l'indication PK :
 Modèle physique de données ‒
Table « ami »
Selon le logiciel de modélisation que vous utilisez, il se peut que les clés
primaires soient matérialisées de manière différente : tous les attributs sont dans
la même partie et la clé primaire est soulignée (ou à une icône représentant une
clé devant le nom de l'attribut).
Unique et constante
Afin d'assurer la cohérence du modèle relationnel, la clé primaire, doit ‒ vous
l'aurez compris ‒ être unique mais elle doit aussi ne jamais changer.
Une colonne unique signifie que la base de données ne vous laissera pas créer de
doublon dans cette colonne : aucun tuple ne peut avoir la même valeur qu'un
autre tuple pour l'attribut contenu dans cette colonne.
Ainsi, un attribut email dans une table utilisateur est unique, mais l'adresse email
peut aussi changer au cours de temps. Cet attribut ne devra donc pas être utilisé
en tant que clé primaire.
Vous pouvez cependant indiquer à la base de données que la colonne email ne
devra contenir que des valeurs uniques. Cette configuration est réalisée à l'aide
d'un index unique, mais ceci fera l'objet d'un autre chapitre.
Servant de référence
La clé primaire (PK) sert d'identifiant pour chaque tuple.
À quoi va bien servir cet identifiant ?
Rappelez-vous, au début de ce chapitre, je vous disais qu'avant de faire un lien
entre les tuples de différentes tables (ou instances de classes), il fallait pouvoir
les identifier de manière unique et certaine.
C'est ce que fait la clé primaire.
Et c'est cette clé qui va servir de référence pour relier les tuples de la table à
ceux d'une autre table !
Tout se tient, et nous allons voir ça ensemble dans le chapitre suivant.
 #

J'AI TERMINÉ CE CHAPITRE ET JE PASSE AU SUIVANT



Mis à jour le 15/12/2020

Chap 4 : Mettez en œuvre les différents types de relations à l'aide des clés
étrangères
Je vous ai présenté les associations entre les classes avec l'approche orientée
objet (AOO), il est temps maintenant de vous montrer comment les traduire dans
un modèle relationnel et donc dans votre base de données.
Le principe général de mise en œuvre d'une relation est le suivant : utiliser une
référence vers le tuple lié dans un attribut ad hoc. C'est ce que l'on appelle
une clé étrangère ou foreign key (FK) en anglais.
Clé étrangère, clé primaire... je ne suis pas serrurier !
Clé primaire, clé étrangère... ça commence à faire beaucoup de clés tout ça...
Mais rassurez-vous, cela n'a rien de compliqué. 
La valeur de la clé étrangère dans un tuple n'est rien d'autre que la valeur de
la clé primaire du tuple lié. 
Je vous ai perdu... ? Voici un exemple illustrant tout cela.
Imaginez l'association pilote/machine suivante entre un Motard et une Moto.

Association «
pilote/machine » entre un « Motard » et une « Moto »
Voici les tables correspondantes :

Tuples des tables « motard » et « moto »

Le but est de matérialiser les liens suivants entre les tuples de motards et de
motos :
Relation entre les pilotes et leur machine (tuples)
Pour enregistrer quelle est la machine (rôle de la classe Moto dans l'association)
associée à chaque pilote (rôle de la classe Motard dans l'association), il suffit de
créer un attribut machine_id en tant que clé étrangère (FK) dans la
table motard et d'y enregistrer la valeur de la clé primaire de la moto
correspondante :

Ajout de la clé étrangère « machine_id » dans la table « motard »

Il est désormais possible de demander à la base de données de nous renvoyer un
tableau contenant le nom de chaque pilote et le modèle de la machine qui lui est
associé :

nom modele

Édouard Bracame Honda CB 750

Jean Manchzeck Norton Commando 850

Jean-Raoul Ducable Kawasaki 750 H2

Il existe un langage standardisé pour l'interrogation des bases de données
relationnelles : le SQL (Structured Query Language).
J'aborderai celui-ci dans les deux dernières parties de ce cours.
Mettez en œuvre différents types de relation
Vous vous souvenez des trois catégories d'associations que je vous ai présentées
dans un des chapitres précédents ?

 un à un (one-to-one)
 un à plusieurs (one-to-many) ou plusieurs à un (many-to-one) :
 plusieurs à plusieurs (many-to-many) :
Eh bien, nous avons désormais tous les ingrédients pour les mettre en œuvre.
Mais attention, chaque type d'association a une mise en oeuvre différente !
L'association un à un (one-to-one)
L'association un à un (one-to-one) est une association qui possède 1 comme
cardinalité maximum de part et d'autre de celle-ci.
Si je reprends l'exemple de l'association Conducteur / Voiture :

Association « un à
un » (one-to-one)
 Un conducteur conduit une et une seule voiture à la fois
 Une voiture n'est pas conduite (en stationnement) ou conduite par un
seul conducteur à la fois
Sa mise en œuvre correspond à celle que je vous ai montrée en exemple dans la
section précédente avec la relation Motard / Moto.
Comme il n'est possible d'associer qu'une seule Voiture à un Conducteur et
qu'un seul Conducteur à une Voiture, à vous de choisir dans quel sens vous
voulez matérialiser la relation (conducteur -> voiture ou voiture -> conducteur).
En général on prend le sens privilégié dans le domaine fonctionnel.
Il n'est pas nécessaire, et même fortement déconseillé, de matérialiser la relation
dans les deux sens. En effet, cela impliquerait de modifier la valeur des clés
étrangères dans les deux tables à chaque fois qu'un lien est modifié (ex : lorsque
le conducteur change de voiture).
Ici on peut considérer plus « naturel » de faire monter un conducteur dans une
voiture que de mettre la voiture autour du conducteur  .
Je prendrais donc l'option de mettre une clé étrangère conducteur_id dans la
table voiture.
 MP
D ‒ Relation « un à un » (one-to-one)
L'association un à plusieurs (one-to-many)
L'association un à plusieurs (one-to-many) ou plusieurs à un (many-to-one) est
une association qui possède 1 comme cardinalité maximum d'un côté et une
cardinalité maximum supérieure à 1 (cardinalité multiple) de l'autre côté de
celle-ci.

Association « un à
plusieurs » (one-to-many)
 Un journal contient aucun (journal en préparation), un
ou plusieurs articles
 Un article est contenu dans aucun (en cours d'écriture) ou un seul journal
Sa mise en oeuvre est la même qu'avec une association un à un (one-to-one),
sauf que le sens est imposé. Vous devez créer la clé étrangère dans la table
correspondant à la cardinalité maximum supérieure à 1 (cardinalité multiple).

MPD ‒
Relation « un à plusieurs » (one-to-many)
Il est ainsi possible de référencer plusieurs fois le même journal dans des articles
différents (cardinalité *), et un article ne peut être lié qu'à un seul journal au
maximum (cardinalité 0..1) :
Tuples montrant la relation « un à plusieurs » (one-to-many)
L'association plusieurs à plusieurs (many-to-many)
L'association plusieurs à plusieurs (many-to-many) est une association qui
possède une cardinalité maximum supérieure à 1 (cardinalité multiple) de part et
d'autre de celle-ci.

Association «
plusieurs à plusieurs » (many-to-many)
 Un musicien constitue aucun, un ou plusieurs groupes
 Un groupe est constitué de un ou plusieurs musiciens
Il n'est ici plus possible de faire ce simple lien d'une table à l'autre, en témoigne
l'exemple ci-dessous :

Tuples montrant la relation « plusieurs à plusieurs » (many-to-many)

Nous voyons bien qu'un musicien comme Jack White entre dans la composition
de plusieurs groupes (The White Stripes, The Raconteurs). Et inversement, un
groupe comme Led Zeppelin est composé de plusieurs musiciens (Page, Jones,
Plant, Bonham).
La solution consiste à créer une table ad hoc, matérialisant les liens multiples en
créant une clé primaire composée des clés étrangères pointant vers les
tables musicien et groupe.
Il s'agit de la table composition dans l'exemple ci dessous :

MPD ‒ Relation « plusieurs à plusieurs » (many-to-many)

Ajout d'une table matérialisant la relation « plusieurs à plusieurs » (many-to-

many)
La classe d'association
Il est possible d'ajouter des attributs à une association grâce à une classe
d'association.
Imaginez une association représentant les concerts donnés par un groupe de
musique dans des lieux de spectacle : à chaque fois que j'ai un lien entre
un Groupe et un Lieu, cela représente un Concert. En créant la classe
d'association Concert, je peux ajouter, par exemple, un attribut date qui spécifie
la date du concert.
 Classe
d'association « Concert »
Une classe d'association se traduit dans le MPD comme une
association plusieurs à plusieurs (many-to-many) : en créant une table du nom
de la classe d'association avec une clé primaire composée et contenant les
attributs de la classe d'association :

MPD ‒ La classe d'association « Concert » devient une table comme pour une
relation « plusieurs à plusieurs » (many-to-many)
Il y a de nombreux cas où les classes d'association sont utiles, par exemple
enregistrer le numéro de siège dans une relation Passager/Vol, etc.
Une autre utilité des classes d'association
Je vous disais précédemment qu'il n'y a pas de notion d'historique dans les
associations. Le lien entre deux instances existe ou n'existe pas. Point !
Cependant, avec une classe d'association, il est possible de simuler une sorte
d'historique en ajoutant des attributs comme dateDebut et dateFin par exemple.
Le lien existera toujours, mais on va désormais pouvoir interpréter son «
effectivité » en se basant sur cette plage de dates.
Je peux ainsi modéliser le changement du batteur dans le groupe Matmatah en
2003, en utilisant cette approche :

MPD ‒ Ajout de dates à l'association « Musicien / Groupe » (many-to-many)

Tuple de la table « composition »
NULL signifie que l'attribut ne contient aucune valeur.
On voit que :

 Fañch est entré dans le groupe Matmatah dès le début du groupe (debut =

NULL) et en a fait partie jusqu'en 2002.

 Scholl est entré dans le groupe en 2003 et en fait toujours partie (fin =

NULL).

J'AI TERMINÉ CE CHAPITRE ET JE PASSE AU SUIVANT