Identifiez les éléments clés du modèle relationnel

Rappelez-vous les trois étapes de la modélisation d’une BDD :

1. Le modèle conceptuel (MCD).

2. Le modèle logique (MLD).
3. Le modèle physique (MPD).
L’étape 1 modélise des concepts par un humain, alors que les étapes 2 et 3 s’approchent de
plus en plus de l’implémentation concrète de la BDD dans l’ordinateur.

Dans cette nouvelle partie, nous allons voir la seconde étape, le modèle logique. Pour les
bases de données relationnelles, le niveau logique utilise la modélisation relationnelle. Votre
modèle relationnel découlera de votre diagramme UML, et quand vous l’aurez défini, il sera
ensuite très simple de créer votre base de données finale !

Représentez votre table et vos attributs

Dans une BDD relationnelle, les informations sont stockées sous forme de tableaux. Dans le
jargon des BDD, un tableau s’appelle une Table.

Comme le modèle relationnel se veut proche de l’implémentation, il permet de modéliser ces

tables. Officiellement, l’objet de modèle relationnel qui correspond à une table s’appelle
la Relation.

Le mot « relation » peut prêter à confusion. En effet, ce mot fait penser au concept
d’« association » que nous avons vu lors des chapitres précédents. En plus, dire qu’un tableau
est une « relation », ce n’est pas très intuitif. Pour ne pas vous emmêler les pinceaux, nous
n’emploierons pas le mot Relation, mais plutôt Table.
Tout au long des chapitres de cette troisième partie, vous allez traduire votre diagramme
UML en un modèle relationnel.

La première étape de cette traduction est aussi la plus simple : nous allons créer une table pour
chaque classe du diagramme UML. Nous laissons pour le moment de côté les classes héritées
( serie_tv, telefilm, etc), que vous verrez plus tard.
Voici donc les tables que nous avons actuellement :

 œuvre ;
 lieu ;
 tournage ;
 societe_de_production ;
 realisateur_ice.
Bonne nouvelle ! Le concept d’attribut existe également dans le modèle relationnel, et il a la
même signification qu’en UML. Retenez juste que attribut est synonyme de colonne.

Ainsi, nos cinq tables possèdent les même attributs que leurs classes correspondantes en
UML :

 localisation_de_la_scene,code_postal, latitude, longitudepour la table lieu;

 titrepour la tableoeuvre;
 etc.
Familiarisez-vous avec les représentations graphiques
Il existe différentes façons de représenter un modèle relationnel : l’une sous forme de texte, et
l’autre sous forme graphique.

La représentation textuelle
Notre table lieu, qui possède quatre attributs, s’écrit de cette manière :
lieu (localisation_de_la_scene:Texte, code_postal:Numérique, longitude:Numérique, latitude:Numérique)
La représentation graphique
Elle est très similaire à l’UML car elle représente les tables par des rectangles divisés en trois
parties, mais ces trois parties sont remplies différemment qu’en UML. Attention donc à ne pas
les confondre !

Par défaut, les attributs sont notés dans la troisième partie (au lieu de la deuxième en UML).

Vous aurez plus de détails prochainement. 😉

Représentation graphique du modèle relationnel

Contrairement au diagramme UML dont la représentation est définie de manière stricte,
la représentation graphique du modèle relationnel peut différer d’un logiciel à l’autre.
Les illustrations de ce cours sont réalisées avec le logiciel SQLPowerArchitect.
À ces deux représentations, nous ajouterons une troisième, que nous
appellerons représentation en tableaux. Elle n’est pas officielle et servira juste à illustrer les
exemples de ce cours.
Habituez-vous dès maintenant à différencier les deux représentations graphiques pour ne pas
vous emmêler les pinceaux en parcourant le cours.

La représentation en tableaux ressemble à ce que vous voyez sur votre tableur :

 Les attributs sont placés en colonne tout en haut ;

 Quelques exemples (non exhaustifs) sont placés ensuite au niveau des lignes du
tableau :

Exemple d’une représentation en tableau du modèle relationnel

Sur cette illustration, on voit que la table lieu contient quatre colonnes et plusieurs lignes.
L’une de ces lignes représente la rue Corvisart et contient les valeurs ("rue corvisart", 75013,
2.3472, 48.8322).
("rue corvisart", 75013, 2.3472, 48.8322)est aussi appelé un tuple, un enregistrement, plus
rarement un vecteur ou même un n-uplet ! Si nous étions encore à la phase de modélisation
UML, on pourrait aussi dire que ("rue corvisart", 75013, 2.3472, 48.8322)est une instance de la
classelieu.
Dans une table, l'ordre des lignes et des colonnes n'a pas d'importance et pas de
signification. Deux tables contenant les mêmes colonnes (mais dans un ordre différent) et les
mêmes lignes (dans un ordre différent) sont considérées comme identiques.
En résumé
 Le MLD est la deuxième étape de la modélisation d’une BDD relationnelle, et il se
représente grâce au modèle relationnel.
 L’objet principal du modèle relationnel est la table, qui contient des lignes et
des colonnes.
Rappel du vocabulaire :

Terme Synonymes

Table Relation
 Ligne Tuple, enregistrement, vecteur, n-uplet, (instance)

Colonne Attribut
Maintenant que vous avez posé les bases de votre modèle avec vos 5 tables, il est temps de
l’approfondir en déterminant les clés primaires de vos tables : voyons cela au chapitre
suivant !
Déterminez vos clés primaires
Cette vidéo couvre ce chapitre ainsi que le suivant.
Jusqu’à maintenant, vous avez vu que les classes UML se traduisent en tables. Ici, nous allons
plonger plus en détail au cœur des tables pour analyser ce qui les compose : les lignes et les
colonnes.

Pour commencer, vous verrez comment le modèle relationnel permet d’identifier une ligne
d’une table.

Identifiez les clés primaires

Apprenez à identifier les lignes d’un table
Prenons quelques secondes pour raisonner. Est-ce que vous vous souvenez que pour éviter la
redondance, il faut que chaque information ne soit présente qu’une seule fois dans la BDD ?

Si chaque information ne doit être présente qu’une seule fois, cela implique que dans une
table donnée, par exempleoeuvre, il ne doit pas y avoir deux lignes décrivant une même œuvre.
Ainsi,oeuvrecontiendra exactement autant de lignes qu’il y a d'œuvres dont les lieux de tour-
nage ont été enregistrés dans notre fichier CSV.
Mais cela pose une question fondamentale : comment nous assurer que deux lignes deoeuvre
font bien référence à 2 œuvres différentes ?
Autrement dit, comment différencier deux lignes ?

Cette question fondamentale, c’est celle de l’identité. Dans le monde, chaque personne est
unique. Ce qui garantit votre unicité, c’est votre identité. En effet, deux personnes ne peuvent
pas avoir la même identité, et une personne ne peut avoir deux identités différentes (à part
dans le monde des espions et espionnes, mais ça c’est une autre histoire).

Dans un SGBDR, chaque ligne doit avoir une identité.

D’ailleurs, la plupart des SGBDR n’acceptent pas que deux lignes d’une table soient iden-
tiques (c’est-à-dire que chacun de leurs attributs aient les mêmes valeurs).
L’identité d’une ligne est appelée clé primaire.

Qu’est-ce que cela veut dire ?

Si on est sûr que n'importe quelle ligne peut être retrouvée en connaissant la valeur de
quelques-uns de ses attributs, c'est que ces quelques attributs forment une clé primaire !

Cette illustration vous aidera peut-être à visualiser ce concept :

Chaque ligne a une clé qui lui est unique. Cette clé est composée d’un ou plusieurs attributs
(ici, deux)
Illustrons cela par un exemple plus concret : cette notion d’identification est essentielle pour
les facteurs qui doivent identifier de manière certaine les logements pour lesquels ils distri-
buent le courrier. Imaginez une table qui répertorie des logements, possédant ces colonnes :

1. Type de logement (maison, appartement, etc.).

2. Superficie.
3. N° de logement (ex. : appartement numéro 203).
4. N° de voie (ex. : 5).
5. Complément (ex. : 5 bis).
6. Intitulé de la voie (ex. : rue de la République).
7. Commune (ex. : Passillac-les-Flots).
8. Code postal.
9. Pays.
La clé primaire de cette table, ce sera le groupe de colonnes minimum que l’on peut donner
au facteur pour qu’il soit sûr de pouvoir distribuer un courrier au bon logement.

Si on lui donne uniquement les attributsintitulé de la voie,code postaletcommune (par exemple

« rue de la République, 93124 Passillac-les-Flots »), il lui sera difficile de donner le courrier,
car la rue de la République de Passillac contient plusieurs logements.
Si au contraire, on lui donne tous les attributs, le courrier pourra à coup sûr être distribué. Ce-
pendant, le groupe d’attributs 1 à 9 n’est pas considéré comme minimal : la superficie n’a pas
besoin d’être connue pour distribuer un courrier. superficiene doit donc pas figurer dans la clé
primaire.
Une bonne clé primaire pour cette table sera donc le groupe des attributs 3 à 9. Même si pour
une maison, l’attributn° de logementn’a pas besoin d’être connu, il est quand même important de
le placer dans la clé primaire de la table, afin de pouvoir identifier les différents appartements
d’un même immeuble.
En choisissant les colonnes 3 à 9 comme clé primaire de la tableLogement, on définit implicite-
ment que deux lignes de cette table ne peuvent pas avoir des valeurs identiques pour ces at-
tributs. Le SGBDR vous l’interdira. On dit que l’on définit une contrainte d’unicité sur le
groupe de colonnes 3 à 9.
Autrement dit, le groupe(code_postal, commune)ne peut pas être une clé primaire car les lignes
« 3 rue de la Charrue avant les bœufs, 93124 Passillac-les-Flots » et « 5 rue du Pangolin su-
perstitieux, 93124 Passillac-les-Flots » ont toutes les deux les mêmes valeurs pour (code_pos-
tal, commune), soit93124etPassillac-les-Flots. Ce groupe d’attributs violerait donc la contrainte
d’unicité.
Formellement, on dira que la clé primaire d’une table est un groupe d’attributs mini-
mum permettant d’identifier de manière unique une ligne.
À vous de jouer

Ça y est, vous êtes prêt à déterminer les clés primaires de votre modèle. Je vous remets ici
l’état actuel du modèle :
Représentation graphique du modèle relationnel à l'état actuel
Tablessociete_de_productionetrealisateur_ice
Pour les tablessociete_de_productionetrealisateur_ice, il n’y a pas beaucoup de choix : nous pren-
drons l’attributnompour chacune de ces deux tables. Bien sûr, cela suppose qu’il n’y ait pas
deux sociétés de production ayant le même nom, ni deux réalisateurs/réalisatrices ayant le
même nom. C’est très peu probable, donc on peut considérer quenomest une bonne clé pri-
maire pour ces 2 tables.
Tablelieu
Pour la tablelieu, c’est moins évident. Il pourrait y avoir deux clé primaires possibles :
1. Le groupe(localisation_de_la_scene, code_postal).
2. Le groupe(latitude, longitude).
Pour la première solution, il faut supposer quelocalisation_de_la_scenecontienne bien au moins le
nom de la rue (de la voie) ainsi que la commune. Dans ce cas, la contrainte d’unicité est res-
pectée car il n’existe pas deux noms de voie identiques pour une même commune. Et même
s’il existe en France plusieurs communes ayant le même nom, le code postal permet de lever
cette ambiguïté. Avec cette clé primaire, on peut donc identifier dans quelle rue est tournée
une œuvre donnée.
Mais cette première solution a des inconvénients. Tout d’abord, l’attri-
but localisation_de_la_scene est de mauvaise qualité : l’utilisateur qui entre une adresse n’est pas
contraint d'indiquer cette adresse de manière normalisée : rien ne l'oblige à indiquer le nom de
la commune. Il pourrait même indiquer le code postal, alors que celui-ci est censé être déjà
présent dans l’attribut code_postal: bonjour la redondance ! De plus, l’utilisateur peut écrire une
même adresse de deux manières différentes, par exemple « 2, boulevard Joffre» et « 2 Bd
Joffre » : cela rend difficile la détection de doublons !
Regardez dans le fichier aux lignes 2016-980et 2019-608 vous avez une adresse avec le code
postal redondant, et l’autre n’indique pas la ville : elles sont de plus écrites différemment
(l’une en majuscules, l’autre avec un accent) ! C’est le bazar.

Extrait des lignes 2016-980 et 2019-608

Il aurait été plus judicieux de demander à l’utilisateur de saisir les adresses dans des champs
séparés : numéro de voie, nom de voie, complément d’adresse, commune, code postal, etc.

Quant à la solution 2, elle pose un autre problème : celui de la précision. Faut-il considérer le
couple latitude-longitude (48.87512, 2.348979) comme étant différent du couple (48.87506,
2.348963), alors que ces deux endroits sont séparés de 3 mètres, se trouvent dans la même
rue et désignent donc le même lieu de tournage ?

Comme vous l’avez vu, certains types d’attributs sont moins propices à appartenir à une clé
primaire. Ainsi, on préférera les nombres entiers aux nombres décimaux (pour une question
de précision), et les chaînes de caractères courtes et sans confusion possible (différentes
orthographes, etc.).
Il peut exister plusieurs solutions pour la clé primaire : c’est le cas pourlieu. Plus formelle-
ment, on dit que les différentes options sont des clés candidates, et que l’option finalement
retenue est la clé primaire. Pour la tablelieu, nous choisirons arbitrairement le groupe(localisa-
tion_de_la_scene, code_postal)comme clé primaire.
Tablesoeuvreet tournage
Pour les tables oeuvreettournage , il est impossible, pour le moment, de trouver une clé primaire.
En effet, dans le chapitre où nous parlions de la composition en UML, nous avions dit ce-
la : « Il existe parfois des films différents ayant le même nom (exemple : au moins quatre
films portent le titre Home). Ainsi, pour identifier un film de manière certaine, on a besoin de
son titre mais aussi du nom de sa société de production, ce qui prouve le lien de dépendance
entre ces deux classes. »

Problème : la table oeuvrene contient pas, pour l’instant, d’attribut donnant le nom de la socié-
té de production. Sans cet attribut, on ne peut pas avoir de clé primaire.
Pour la table tournage, nous n’avons que deux attributs : la date de début et la date de fin.
Problème : deux tournages (de deux films différents, sur deux lieux différents) peuvent avoir
débuté et s’être terminés exactement aux mêmes dates. Pour vous en convaincre, vous pouvez
vérifier aux lignes 2016-87 et 2016-189 . Il n’y a donc pas d’unicité possible.

Nous laissons donc ces 2 tables en suspens, nous trouverons leurs clés primaires plus tard. 😉
Un point sur les notations et représentations graphiques
Graphiquement, il est courant de représenter les attributs qui constituent la clé primaire dans
la partie centrale du rectangle qui représente la table, et tous les autres attributs sont ins-
crits dans la partie basse. Mais il peut arriver que vous rencontriez d’autres représentations,
ailleurs que dans ce cours. Par exemple avec la clé primaire en gras ou soulignée.

Aussi, on peut indiquer les attributs de la clé primaire par l’abréviation « PK », mise pour
« Primary Key ».

Représentation graphique du modèle relationnel avec la présence des clés primaires notées
[PK]
Créez des clés primaires artificielles
Parmi les attributs d’une table, il est parfois impossible de trouver une clé primaire. Dans
d’autres cas, la clé primaire est trop complexe (trop d’attributs, par exemple). Dans ce cas, il
est possible de créer une clé artificielle.

Une clé artificielle est un attribut que l'on ajoute à la table. Cet attribut n'a pas de réelle si-
gnification dans le domaine que l'on modélise, mais sa seule fonction est d'identifier de ma-
nière unique les lignes de la relation. C’est donc un identifiant.
Exemple : le numéro de Sécurité sociale ou le numéro de carte d’identité sont des clés artifi-
cielles permettant d'identifier les personnes de nationalité française.

Quand vous dessinez votre MLD, vous pouvez être tenté de créer un identifiant pour chaque
table ; cependant il est préférable de ne faire cela que pour les cas particuliers.
Par exemple, prenez cet extrait de votre fichier CSV :
Extrait de lignes du fichier CSV
Si vous le transformez pour le faire coller à votre modèle relationnel (donc avec deux tables
oeuvreetsociete_de_production, avec une clé étrangèresociete_prod) en y ajoutant des clés artifi-
cielles, vous pourriez être tenté de simplement découper le fichier en deux :

Les deux tables "oeuvre" et "societe_de_production"

Or ici, il y a 2 lignes desociete_de_productionqui font référence à la même société de production,
et c’est une erreur !
Voilà pourquoi, même en choisissant une clé artificielle, il faut garder en tête la contrainte
d’unicité de la clé primaire(nom)desociete_de_productionet vérifier que(nom)ne contient pas de
doublons. Si vous faites cela, vous arriverez à cette solution correcte :

La bonne solution
Par contre, quand on passe au MPD (la troisième étape de la modélisation), il est fréquent
d’utiliser des clés artificielles systématiquement, car :

 Il y a toujours un risque qu’une clé primaire non artificielle perde la propriété d’unici-
té (exemple : si une même société de production produit deux films ayant le même
nom).
 Si la valeur d’une clé non artificielle est modifiée (si par exemple une société de pro-
duction change de nom), il faut modifier toutes les clés étrangères qui la référencent.
En résumé
 La clé primaire d’une table est un groupe de colonnes minimum permettant d'identifier
une ligne d'une table.
 Une clé primaire a donc forcément une contrainte d'unicité.
  Dans certains cas, il est impossible de trouver une clé primaire parmi les colonnes pré-
sentes. Dans d’autres cas, la clé primaire est trop complexe. On crée alors une clé pri-
maire artificielle.
 Dans le MLD, l'usage de clé primaire artificielle est à réserver pour les cas particu-
liers, et il faut prendre certaines précautions.
Vous avez identifié vos clés primaires, c’est bien. Mais vos tables sont encore séparées les
unes des autres. Dans le chapitre suivant, vous verrez comment les relier entre elles.
Découvrez l’utilité des clés étrangères
La modélisation relationnelle permet cela, grâce au concept de clé étrangère.

Une clé étrangère, c’est un attribut (ou groupe d'attributs) d’une table qui fait référence à la
clé primaire d’une autre table, afin de modéliser le lien entre les lignes de ces deux tables.

Voici ce que cela donnerait si vous modélisiez le lien entre deux tables,livreetpersonne :

La table « livre » est liée à la table « personne » grâce à la clé étrangère

Les valeurs présentes dans la colonneauteur_icedoivent obligatoirement avoir une correspon-
dance dans la colonneid, sinon les données sont incohérentes. La plupart des SGBDR n’ac-
cepteront pas que vous introduisiez un livre dont l’auteur indiqué dans la colon-
neauteur_ice n’existe pas dans la tablepersonne. Cette contrainte est à garder à l’esprit lorsqu'une
personne sera supprimée de la base de données.
Les attributs qui constituent une clé étrangère sont désignés par le signe « FK », pour « Fo-
reign Key ». Graphiquement, on représente une clé étrangère par un trait en pointillés entre
les deux tables, comme ceci :
Représentation graphique de la clé étrangère entre les tables « livre » et « personne »
Ici, la clé étrangère n’est composée que d’un attribut (auteur_ice) car la clé primaire de per-
sonne ne contient qu’un attribut (id). Mais si la clé primaire contient deux attributs, comme
pour votre tablelieu, alors il faudrait une clé étrangère à deux attributs, que l’on pourrait appe-
ler par exempleloc_sceneetcode_postal :

Représentation en tableau des tables « lieu » et « tournage », avec les clés primaires [PK] et
étrangères [FK] spécifiées
Cardinalités minimales et valeurs nulles
Qu’est-ce qu’une valeur nulle ?
Le modèle relationnel met à disposition une valeur bien pratique : la valeur nulle, notéenull.
Cette valeur est équivalente à une case vide dans un tableau, lorsqu'une information est
manquante ou inexistante.
Par exemple, si une tablePersonnecontient les attributsdate_naissanceetdate_deces , alors on pour-
rait contraindre l’attributdate_naissanceà n’être jamais null si on veut que la date de naissance
soit obligatoirement renseignée pour chaque personne. C’est la contrainte de non-nullité. Par
contre, la date de décès sera nulle pour les individus étant encore en vie.
La valeurnull est différente de la valeur 0, ou de la chaîne de caractères vide"". Contrairement
à0 ou à"", nullindique l’absence d’information : soit parce que l’information n’a pas pu être
récoltée, soit parce que l’information n’existe tout simplement pas.
Les attributs qui composent une clé primaire ne peuvent jamais être nuls, car ils servent
à identifier les lignes de la table. Une ligne sans identité (ou avec une identité incomplète),
c’est interdit !
Comprenez l’utilité des valeurs nulles dans les clés étrangères en fonction de la cardina-
lité minimale
Quand on transforme des associations UML en clés étrangères, la contrainte de non-nullité est
utile lorsque la cardinalité minimale est 1 (et non pas 0).

Prenez l’exemple de la composition entreOeuvreetSocieteDeProduction. Elle est de type un-à-plu-

sieurs, car du côté deSocieteDeProduction, la multiplicité est1 . Cela signifie qu’une œuvre a for-
cément une et une seule société de production.

Le diagramme UML montrant la composition entre "Oeuvre" et « SocieteDeProduction »

Cette association se traduit par une clé étrangère dansoeuvre. Cette clé étrangère contient une
seule colonne :societe_prod, et elle référence la clé primairenom de societe_de_production :
Clé étrangère « societe_prod » référençant la clé primaire de « societe_de_production »
Si la cardinalité minimale était de 0, on aurait pu avoir une œuvre sans société de production.
Cela se serait traduit par une valeur nulle dans la colonnesociete_prod:
Sans la contrainte de non-nullité
Or ici, la cardinalité minimale est de 1, ce qui signifie qu’il faut absolument que societe_prod
soit remplie pour toutes les lignes, et qu’il ne peut donc pas y avoir de valeurs nulles.
Avec la contrainte de non-nullité sur la colonne « societe_prod »
On devra donc spécifier au SGBDR une contrainte de non-nullité sur societe_prod.
En résumé
 Une clé étrangère est un groupe de colonnes d’une table qui fait référence à la clé pri-
maire d’une autre table, afin de modéliser le lien entre les lignes de ces deux tables.
 Une clé étrangère peut être composée d'une ou plusieurs colonnes.
 Dans une table, une absence de valeur est modélisée par une valeur nulle.
 Les valeurs nulles peuvent être utilisées dans une clé étrangère pour spécifier qu'une
ligne d'une table A n'est liée à aucune ligne d'une table B.
Voilà ! Dans le chapitre suivant, vous apprendrez à utiliser les concepts de clés primaires et
étrangères pour traduire tous les types d’associations que vous avez définis dans votre
UML !
Transformez les associations de votre diagramme de
classes UML
Cette vidéo abordera les notions de ce chapitre et des suivants, jusqu'à la fin de la partie.
Bonne nouvelle ! Maintenant que vous maîtrisez les clés primaires et étrangères, vous avez
toutes les clés en main pour à présent traduire votre diagramme UML en un modèle rela-
tionnel.

Vous verrez, la traduction est automatique : il n’y a qu’à appliquer quelques règles, et le tour
est joué !

Dans ce chapitre, ne cherchez pas à tout retenir par cœur : cherchez d’abord à comprendre la
logique des traductions UML-relationnel. Voyez-le plutôt comme un « dictionnaire de traduc-
tion » dans lequel vous viendrez piocher les cas qui vous seront utiles au moment où vous en
aurez besoin.

L’association un-à-plusieurs
Reprenez votre diagramme UML, et regardez l’association entre Oeuvreet SocieteDeProduction.
Elle est de type un-à-plusieurs. Certes, c’est aussi une composition. Mais une composition est
un cas particulier de un-à-plusieurs. Si vous le voulez bien, oublions donc l’aspect composi-
tion pour le moment, pour nous concentrer sur l’aspect un-à-plusieurs :

L’association entre « Oeuvre » et « SocieteDeProduction »

Cette illustration est un diagramme UML, pas un modèle relationnel.
Comme une société de production produit PLUSIEURS oeuvres, il faut ajouter une clé étran-
gère dans oeuvrequi référence la clé primaire desociete_de_production:

Ajout de la clé étrangère « societe_prod »

Représentation graphique de la clé étrangère

Une association un-à-plusieurs se traduit en ajoutant une clé étrangère dans la table qui est du
côté « plusieurs ». Cette clé étrangère référence la clé primaire de la table qui est du côté
« un ».
Comme l’associationoeuvre - societe_de_production est une composition, elle respecte la règle ci-

tée ci-dessus, mais elle a une particularité en plus que je vous explique un peu plus bas. 😉
L’association plusieurs-à-plusieurs
Prenez maintenant l’association oeuvre - realisateur_ice, qui est de type plusieurs-à-plusieurs.
Si vous essayez de mettre une clé étrangère dansoeuvreréférençant la clé primaire de realisa-
teur_ice, alors vous verrez qu’une œuvre ne peut avoir qu’un réalisateur : ce n’est pas ce que
vous voulez. Si inversement vous mettez une clé étrangère dans realisateur_ice, alors vous ne
pourrez avoir qu’une œuvre par réalisateur.
Pour mieux visualiser ce problème, je vous conseille cette très bonne vidéo sur Openclass-
rooms.

Il faut donc trouver une autre solution. 🤓

La solution est d’ajouter une table en plus. Cette table contiendra deux clés étrangères :
l’une référençant oeuvre , et l’autre référençant realisateur_ice :

Ajout de la troisième table supplémentaire « assoc_oeuvre_real »

Temporairement, comme vous ne savez pas encore quelle est la clé primaire de oeuvre, j’ai
ajouté une clé primaire artificielle id_oeuvre, juste pour cette illustration.

Vous voyez ici qu’une œuvre peut avoir plusieurs réalisateurs, et qu’un réalisateur peut avoir
réalisé plusieurs œuvres.

La clé primaire de cette nouvelle table sera composée des deux clés étrangères :
Représentation graphique des tables avec leurs clés primaires et étrangères
Comme assoc_oeuvre_real et realisateur_ice sont liées par une clé étrangère ( real), et que cette clé
étrangère fait également partie de la clé primaire de assoc_real_oeuvre, on lie les deux tables
par un trait plein (et non pas en pointillés comme précédemment).
L’association un-à-un
Pour une association un-à-un entre une tableA et une tableB, on utilise aussi une clé étrangère.
La clé étrangère est placée dans A et elle référence la clé primaire deB .
L’association un-à-un des tables « cinema » et « adresse »
Mais, c’est la même chose que pour l’association un-à-plusieurs, non ?

Oui, mais il y a un petit détail en plus. 😉 Selon le graphique ci-dessus, un cinéma ne peut avoir
qu’une adresse, mais deux cinémas peuvent avoir la même adresse : ce n’est pas ce que l’on
veut.

Pour spécifier qu’une adresse ne peut accueillir qu’un seul cinéma, il faut ajouter
une contrainte d’unicité sur l’attribut adresse . Ainsi, la colonne adresse ne pourra pas contenir
deux fois la même valeur. Ce qui signifie que adresse ne pourra pas contenir deux fois la même
référence vers une adresse donnée. Autrement dit, une adresse ne pourra pas accueillir plus
d’un cinéma.
Il faut donc également spécifier au SGBDR une contrainte d’unicité sur la clé étrangère.
En résumé
 Une association un-à-plusieurs se traduit en ajoutant une clé étrangère dans la table qui
est du côté « plusieurs ». Cette clé étrangère référence la clé primaire de la table qui
est du côté « un ».
 Une association plusieurs-à-plusieurs se traduit en ajoutant une nouvelle table. La clé
primaire de cette nouvelle table sera composée des deux clés étrangères référençant les
deux tables à associer.
 Pour une association un-à-un entre une tableAet une table B, on utilise aussi une clé
étrangère. La clé étrangère est placée dans Aet elle référence la clé primaire de B.
La première étape de traduction de votre diagramme UML en modèle relationnel est termi-
née. Bravo ! Vous avez transformé les associations de votre diagramme de classe UML.
Voyons, au chapitre suivant comme transformer vos compositions et vos classes d'associa-
tions.

Transformez vos compositions et vos classes d'associations

Transformez vos compositions
Une composition, c’est un cas particulier d’association un-à-plusieurs. Comme nous l’avons
vu précédemment, il faut donc ajouter une clé étrangère dans la table qui est du côté « plu-
sieurs », cette clé étrangère référence la clé primaire de la table qui est du côté « un ».

Mais vous le savez désormais, ce qui différencie une composition d’une simple association
un-à-plusieurs, c’est que le composant ne peut exister sans son composite. Ainsi, on identifie
un composant à partir de son composite. C’est-à-dire que la clé primaire du composant
inclut/comprend obligatoirement le composite.

C’est le cas entre une œuvre et sa société de production. Car comme vous l’avez vu précé-
demment, une œuvre se définit par son titre ET par la société qui l’a produite (car il arrive que
deux œuvres aient le même titre).

Maintenant que nous avons ajouté une clé étrangèresociete_proddans oeuvre , qui référence so-
ciete_de_production, il est donc possible d’identifier chaque œuvre par son titre et sa société.
Vous avez donc trouvé la dernière des clés primaires de votre modèle relationnel : celle de la

table oeuvre . 😎 La voici : (titre, societe_prod).

Ici, societe_prodest à la fois une clé étrangère ET une partie de la clé primaire de oeuvre.
Une composition est traduite de la même manière qu’une association un-à-plusieurs ; mais en
plus, on ajoute à la clé primaire de la table composant la clé étrangère vers la table composite.
Maintenant que vous avez la clé primaire de oeuvre, il faut actualiser la
table assoc_oeuvre_real avec cette nouvelle clé. Voici le résultat :
Transformez vos classes d'associations
Vous l’avez vu dans ce cours, une classe d’association sert à donner des caractéristiques à une
association entre deux classes. C’est le cas par exemple pour la classe d’association tournage ,
qui caractérise le lien entre une œuvre et un lieu grâce à une date de début et de fin de tour-
nage :
La classe d’association « Tournage »
Cette illustration est un diagramme UML, pas un modèle relationnel.

Jusqu’à maintenant, notre table tournage n’avait que deux attributs. Seules, ces deux dates ne
veulent rien dire : il faut pouvoir les lier à l’œuvre et au lieu correspondants. Vous vous en
doutez peut-être : il va falloir utiliser des clés étrangères !
Classe d’association sur une relation plusieurs-à-plusieurs
La relation entreoeuvre et lieuest de type plusieurs-à-plusieurs.
Vous savez déjà comment traduire une telle relation : en ajoutant une nouvelle table qui
contient deux clés étrangères référençant les deux tables de part et d’autre de l’association.
Voici ce que cela donnerait :
Représentation graphique d’une association plusieurs-à-plusieurs
Mais en plus, il faut ajouter les attributs qui caractérisent cette association. Il suffit d’ajouter
ces attributs à notre nouvelle table !

Mais cette nouvelle table dont on parle, c’est notre table tournage, non ?
Oui, tout à fait, bravo !

Voici donc le résultat final :

Traduction d’une classe d’association en une nouvelle table « tournage »
Traduction d’une classe d’association en une nouvelle table
Une association plusieurs-à-plusieurs avec une classe d’association se traduit en une nouvelle
table. Cette table contient tous les attributs de la classe d’association, ainsi que deux clés
étrangères référençant les deux tables de part et d’autre de l’association.
Clé primaire
Nous n’avons toujours pas trouvé la clé primaire detournage!
Effectivement, vous aviez vu au chapitre précédent que les deux dates, à elles seules, ne suffi-
saient pas à garantir la contrainte d’unicité (deux œuvres peuvent être tournées sur une même
période). Mais avec les clés étrangères que nous avons ajoutées, c’est maintenant faisable !

Vous avez vu que par défaut, la clé primaire d’une table issue d’une association plusieurs-à-
plusieurs est composée des deux clés étrangères référençant les deux tables de part et d’autre
de l’association.

Ici, vous êtes donc sûr que le groupe (titreoeuvre, loc_scene, code_postal) fait partie de la clé
primaire de tournage . Cependant, selon le cas, il faudra parfois ajouter d’autres attributs à la
clé. Dans notre cas, il est clairement possible qu’une œuvre soit tournée plusieurs fois au
même endroit.
Voici donc une clé primaire possible : (titre_oeuvre, loc_scene, code_postal, date_de_debut). En ef-
fet, on ne peut pas avoir 2 lignes de tournage relatives au même film, au même endroit, et com-
mençant le même jour. Si c’est le cas, cela signifie que ces deux lignes correspondent en fait à
une seule et unique session de tournage.
La clé primaire de la table issue d’une classe d’association plusieurs-à-plusieurs est composée
d’au moins les deux clés étrangères, et optionnellement de certains des autres attributs (à dé-
terminer sur le critère de l’unicité de la clé primaire).
Classe d’association sur une relation un-à-plusieurs
Pour une classe d’association d’une relation un-à-plusieurs, les attributs de la classe d'associa-
tion sont ajoutés à la table qui est du côté « plusieurs ».

Classe d’association sur une association un-à-plusieurs

Traduction de la classe d’association un-à-plusieurs

Classe d’association sur une relation un-à-un
Pour une classe d’association d’une relation un-à-un, les attributs de la classe d'association
sont ajoutés à la table qui a été choisie pour recevoir la clé étrangère.
Classe d’association sur une association un-à-un

Même traduction de la classe d’association un-à-un, que le visuel précédent pour que vous
l'ayez facilement sous les yeux !
En résumé
 Une composition est traduite de la même manière qu’une association un-à-plusieurs ;
mais en plus, on ajoute, à la clé primaire de la table composante, la clé étrangère vers
la table composite.
 Une classe d’association sur une association plusieurs-à-plusieurs se traduit en une
nouvelle table. Cette table contient tous les attributs de la classe d’association, ainsi
que deux clés étrangères référençant les deux tables de part et d’autre de l’association.
La seconde étape de traduction de votre diagramme UML en modèle relationnel est terminée.
Bravo ! Vous avez transformé vos compositions et vos classes d'associations. Voyons, au cha-
pitre suivant, comment transformer vos relations d'héritage.

Transformez vos compositions et vos classes d'associations

Transformez vos compositions
Une composition, c’est un cas particulier d’association un-à-plusieurs. Comme nous l’avons
vu précédemment, il faut donc ajouter une clé étrangère dans la table qui est du côté « plu-
sieurs », cette clé étrangère référence la clé primaire de la table qui est du côté « un ».

Mais vous le savez désormais, ce qui différencie une composition d’une simple association
un-à-plusieurs, c’est que le composant ne peut exister sans son composite. Ainsi, on identifie
un composant à partir de son composite. C’est-à-dire que la clé primaire du composant
inclut/comprend obligatoirement le composite.

C’est le cas entre une œuvre et sa société de production. Car comme vous l’avez vu précé-
demment, une œuvre se définit par son titre ET par la société qui l’a produite (car il arrive que
deux œuvres aient le même titre).

Maintenant que nous avons ajouté une clé étrangèresociete_proddans oeuvre , qui référence so-
ciete_de_production, il est donc possible d’identifier chaque œuvre par son titre et sa société.
Vous avez donc trouvé la dernière des clés primaires de votre modèle relationnel : celle de la

table oeuvre . 😎 La voici : (titre, societe_prod).

Ici, societe_prodest à la fois une clé étrangère ET une partie de la clé primaire de oeuvre.
Une composition est traduite de la même manière qu’une association un-à-plusieurs ; mais en
plus, on ajoute à la clé primaire de la table composant la clé étrangère vers la table composite.
Maintenant que vous avez la clé primaire de oeuvre, il faut actualiser la
table assoc_oeuvre_real avec cette nouvelle clé. Voici le résultat :
Transformez vos classes d'associations
Vous l’avez vu dans ce cours, une classe d’association sert à donner des caractéristiques à une
association entre deux classes. C’est le cas par exemple pour la classe d’association tournage ,
qui caractérise le lien entre une œuvre et un lieu grâce à une date de début et de fin de tour-
nage :
La classe d’association « Tournage »
Cette illustration est un diagramme UML, pas un modèle relationnel.

Jusqu’à maintenant, notre table tournage n’avait que deux attributs. Seules, ces deux dates ne
veulent rien dire : il faut pouvoir les lier à l’œuvre et au lieu correspondants. Vous vous en
doutez peut-être : il va falloir utiliser des clés étrangères !
Classe d’association sur une relation plusieurs-à-plusieurs
La relation entreoeuvre et lieuest de type plusieurs-à-plusieurs.
Vous savez déjà comment traduire une telle relation : en ajoutant une nouvelle table qui
contient deux clés étrangères référençant les deux tables de part et d’autre de l’association.
Voici ce que cela donnerait :
Représentation graphique d’une association plusieurs-à-plusieurs
Mais en plus, il faut ajouter les attributs qui caractérisent cette association. Il suffit d’ajouter
ces attributs à notre nouvelle table !

Mais cette nouvelle table dont on parle, c’est notre table tournage, non ?
Oui, tout à fait, bravo !

Voici donc le résultat final :

Traduction d’une classe d’association en une nouvelle table « tournage »
Traduction d’une classe d’association en une nouvelle table
Une association plusieurs-à-plusieurs avec une classe d’association se traduit en une nouvelle
table. Cette table contient tous les attributs de la classe d’association, ainsi que deux clés
étrangères référençant les deux tables de part et d’autre de l’association.
Clé primaire
Nous n’avons toujours pas trouvé la clé primaire detournage!
Effectivement, vous aviez vu au chapitre précédent que les deux dates, à elles seules, ne suffi-
saient pas à garantir la contrainte d’unicité (deux œuvres peuvent être tournées sur une même
période). Mais avec les clés étrangères que nous avons ajoutées, c’est maintenant faisable !

Vous avez vu que par défaut, la clé primaire d’une table issue d’une association plusieurs-à-
plusieurs est composée des deux clés étrangères référençant les deux tables de part et d’autre
de l’association.

Ici, vous êtes donc sûr que le groupe (titreoeuvre, loc_scene, code_postal) fait partie de la clé
primaire de tournage . Cependant, selon le cas, il faudra parfois ajouter d’autres attributs à la
clé. Dans notre cas, il est clairement possible qu’une œuvre soit tournée plusieurs fois au
même endroit.
Voici donc une clé primaire possible : (titre_oeuvre, loc_scene, code_postal, date_de_debut). En ef-
fet, on ne peut pas avoir 2 lignes de tournage relatives au même film, au même endroit, et com-
mençant le même jour. Si c’est le cas, cela signifie que ces deux lignes correspondent en fait à
une seule et unique session de tournage.
La clé primaire de la table issue d’une classe d’association plusieurs-à-plusieurs est composée
d’au moins les deux clés étrangères, et optionnellement de certains des autres attributs (à dé-
terminer sur le critère de l’unicité de la clé primaire).
Classe d’association sur une relation un-à-plusieurs
Pour une classe d’association d’une relation un-à-plusieurs, les attributs de la classe d'associa-
tion sont ajoutés à la table qui est du côté « plusieurs ».

Classe d’association sur une association un-à-plusieurs

Traduction de la classe d’association un-à-plusieurs

Classe d’association sur une relation un-à-un
Pour une classe d’association d’une relation un-à-un, les attributs de la classe d'association
sont ajoutés à la table qui a été choisie pour recevoir la clé étrangère.
Classe d’association sur une association un-à-un

Même traduction de la classe d’association un-à-un, que le visuel précédent pour que vous
l'ayez facilement sous les yeux !
En résumé
 Une composition est traduite de la même manière qu’une association un-à-plusieurs ;
mais en plus, on ajoute, à la clé primaire de la table composant, la clé étrangère vers la
table composite.
 Une classe d’association sur une association plusieurs-à-plusieurs se traduit en une
nouvelle table. Cette table contient tous les attributs de la classe d’association, ainsi
que deux clés étrangères référençant les deux tables de part et d’autre de l’association.
La seconde étape de traduction de votre diagramme UML en modèle relationnel est terminée.
Bravo ! Vous avez transformé vos compositions et vos classes d'associations. Voyons, au cha-
pitre suivant, comment transformer vos relations d'héritage.
Transformez vos relations d’héritage

Le modèle relationnel n’a pas été pensé pour représenter des relations d’héritage. Il est certes
possible de les modéliser, mais cela nécessitera un peu de réflexion de votre part.

Il y a trois manières différentes de traduire une relation d’héritage :

 L’héritage par référence ;

 L’héritage par classe mère ;
 L’héritage par classes filles.
Chacune de ces trois méthodes possède ses avantages et inconvénients, que nous allons dé-
tailler ici.

La méthode la plus fréquente est la transformation de l’héritage par référence, car elle est bien
adaptée à la majeure partie des cas de figure.

Transformez votre héritage par référence

Avec cette méthode, il vous faut créer une table pour la classe mère, et une table par classe
fille. Des clés étrangères dans les tables des classes filles permettront de référencer la table de
la classe mère.

La clé primaire de chaque table fille doit être la même clé primaire que la table mère. Cha-
cune des clés primaires des tables filles est donc également une clé étrangère qui référence la
table mère.

C’est à-dire ?
Dans notre cas, la clé primaire deoeuvre est(titre, societe_prod). Ces deux attributs devront donc
être ajoutés aux tables filles (telefilm, long_metrage,serie_web, serie_tvetserie), et ils seront à la fois
clé étrangère versoeuvre, et à la fois clé primaire de chaque table fille :
Cas de l’héritage par référence
On pourrait aussi considérer aussi que saison fait partie de la clé primaire deserie , mais pour ne
pas allonger le cours, je ne traiterai pas ce cas ici.

Cette méthode est adaptée à la majeure partie des cas de figure. Utilisez-la donc par défaut.
Cependant, dans votre cas, cela implique six tables, et la majeure partie de ces tables n’a pas
d’autre attribut que la clé primaire. Elles ne contiennent donc quasiment pas d'information in-
téressante. La création d’une table par classe fille est donc ici peu adaptée.
Transformez votre héritage par la classe mère
C’est la solution la mieux adaptée à votre cas ; c’est donc celle que vous utiliserez pour la
suite du cours.
Avec cette méthode, il n’y a qu’une seule table : celle qui correspond à la classe mère.
Elle nécessite donc de regrouper toutes les informations des classes filles dans cette unique
table. Tous les attributs des classes filles seront donc réintégrés à la classe mère. En plus, un
attribut supplémentaire sera ajouté (appelé attribut de discrimination), qui indique pour
chaque ligne à quelle classe fille cette ligne correspond.

En reprenant votre UML, vous verrez que parmi toutes les classes filles de oeuvre , il n’y a
qu’un seul attribut : saison . Vous allez donc l’ajouter à la table oeuvre. Remarquez que cet attri-
but aura la valeur NULL lorsque l’œuvre en question ne sera pas une série.
Aussi, il vous faut ajouter l’attribut de discrimination qui permet de savoir si une œuvre est un
téléfilm, un long-métrage, etc. Appelez cet attribut type_de_tournage:
La table «

oeuvre » avec l’attribut de discrimination « type_de_tournage »

Cette méthode est particulièrement adaptée quand les classes filles ne contiennent que très peu
d’attributs. Dans le cas contraire, la table contiendra beaucoup de colonnes et beaucoup de va-
leurs NULL.
Transformez votre héritage par la classe fille
Avec cette méthode, la classe mère ne donne pas lieu à une table. À l’inverse, chaque classe
fille est traduite par une table, et chacune de ces tables doit alors reprendre les attributs de la
classe mère.

De plus, la clé primaire de chaque table fille doit être la clé primaire de la classe mère.
Dans votre cas, chaque table fille aurait donc eu comme clé primaire(titre, societe_prod):
 Héritage par

classes filles : les classes mères « Oeuvre » et « Serie » ne sont pas traduites en tables
Cette méthode est adaptée lorsque la classe mère est abstraite, car l’absence de table corres-
pondant à la classe mère traduit bien de fait qu’il est interdit d’instancier la classe mère.
Autres alternatives
Le modèle relationnel n’ayant pas été conçu pour gérer efficacement l’héritage, il a été créé
une amélioration du modèle relationnel : le modèle objet-relationnel. Il reprend les concepts
du modèle relationnel, mais y ajoute quelques notions empruntées à l’orienté objet (qui se
modélise par le diagramme de classes UML), comme l’héritage.

Les SGBDR PostgreSQL et Oracle Database savent gérer le relationnel-objet.

À vous de jouer
Maintenant que vous avez sous la main toutes les règles de traduction de l’UML vers le rela-
tionnel, je vous laisse traduire entièrement votre diagramme UML en modèle relationnel !

Voici la réponse :
Réponse à l'exercice
En résumé
Une relation d'héritage peut être traduite de 3 manières différentes :

 par référence ;
 par classe mère ;
 par classes filles.
Bravo, vous savez maintenant traduire entièrement n’importe quel diagramme UML en un
schéma relationnel. Mais au fait, est-ce que votre modélisation minimise la redondance ?
C’est ce que nous allons voir dans la dernière partie.