(YUNIT) Base de Donnée

Modéliser vos bases de
données
Tout programme informatique, qu'il soit une appli mobile, web, ou un logiciel de
bureau, utilise des bases de données.
23/11/2022
1 Le concept de base de données
Vous découvrirez tout d’abord le concept de base de données, à quoi ça sert et comment on
l’utilise
2 Type de données
Vous apprendrez à reconnaître celles qui sont très structurées, et celles qui le sont moins
Sommaire
3 Modélisation d’une base de données
Vous modéliserez une base de données en dessinant votre premier diagramme de classes UML
4 Modèle conceptuel vers un modèle relationnel
Vous découvrirez comment traduire votre diagramme UML en un modèle relationnel
2
Mise
En contexte
Mise en contexte
Tout au long du cours, vous suivrez ce scénario : vous faites partie d’une
équipe de développeurs et développeuses d’une application de Smartphone.
L’une des fonctionnalités originales de cette application est qu’elle
permettra de vous rendre sur les lieux de tournage de vos films ou séries
préférés. Dans votre équipe, vous êtes chargé de réaliser la structure de la
base de données. Vos collègues, quant à eux, se chargeront de programmer
la partie applicative de l’appli.
Ce cours ne nécessite pas de prérequis. Vous n'apprendrez pas de code

informatique ici.
La modélisation relationnelle est massivement utilisée dans le monde

professionnel dès qu'il s'agit de modéliser des données dites structurées.
OBJECTIFS PÉDAGOGIQUES
À la fin de ce cours, vous serez capable de :
- Analyser vos données pour choisir le type de base de données approprié.

- Créer le diagramme de classe UML de votre base de données.
- Déterminer le modèle relationnel de votre base à partir de votre diagramme UML.
Le concept de base de données
A quoi ça sert ?
A quoi ça sert ?
UNE BASE DE DONNÉES, À QUOI ÇA SERT ?
Comme son nom l’indique, une base de données (BDD), ça sert à stocker des données !
En général, ce ne sont pas des humains qui interagissent avec la base de données, mais plutôt des
programmes informatiques (applis mobiles, logiciels, sites web, etc. ).
MAIS UNE DONNÉE, C’EST QUOI ?
Eh bien, c’est très variable ! Voici quelques exemples :
- Le site web Wikipédia vous permet d’accéder à des données de type encyclopédique.
- L’application Smartphone Instagram stocke des données photos.
- Votre logiciel de messagerie interagit quant à lui avec vos e-mails : ce sont des données également !
La base de données et le programme informatique (appli, site web, etc.) sont complémentaires : l’un ne
va pas sans l’autre. Si vous arrêtez un programme informatique qui n'est pas lié à une base de données,
le programme ne se souviendra plus de rien.
C'est pour ça qu'il doit interagir avec la base de données : elle est en quelque sorte sa mémoire.
Découvrez le système de gestion de base de données (SGBD)
C’EST QUOI LE SGBD ?
Le SGBD est spécialisé dans le stockage, l’accès et l’écriture de données. Eh oui, bien gérer les données,
c’est tout un métier ! De cette manière, les programmes ou applications qui interagiront avec un SGBD
n’auront plus à se soucier :
- de l’optimisation d’accès aux données (en termes de temps d’accès) ;

- de l’optimisation du stockage des données (réorganisations, segmentations, etc.) ;
- de l’administration des données (format de stockage, statistiques sur la quantité de données, etc.) ;
- de la partageabilité des données (avec d’autres programmes ou des humains) ;
- du contrôle de la cohérence des données ;
- de la sécurité des données (authentification, droit d’accès, etc.) ;
- de la persistance des données (en cas de panne, des sauvegardes sont conservées).
SGDB TRÈS CONNU : SQLITE
Nous l’utiliserons plus tard dans ce cours. Il est assez simple d’utilisation : il est donc parfait pour débuter.
Si vous avez déjà fouillé dans les dossiers de votre ordinateur, vous avez probablement déjà rencontré des
fichiers dont l’extension est .db, .db3, .sqlite ou .sqlite3.
Tous ces fichiers sont créés et lus par SQLite. Quand vous en voyez un, vous savez qu’il s’agit d’une base de
données, et qu’il y a des données dedans !
RÉSUMÉ
- Une base de données sert à stocker des données pour qu’elles soient accessibles par un ou plusieurs
programmes/applications.
- Un SGBD est un programme qui fait l’intermédiaire entre le programme/application et les données, à
l’aide d’un langage prédéfini, comme le SQL, par exemple.
- Le SGBD est spécialisé dans le stockage de données, et optimise les accès en lecture et en écriture.
Maintenant que vous savez ce que sont une BDD et un SGBD, il faut entrer un peu plus dans le détail des différentes
formes que peut prendre une donnée. Cela nous permettra de bien choisir la forme de la BDD qui accueillera nos données
des lieux de tournage de films.
Modélisez vos bases de données
Choisissez entre une BDD relationnelle ou NoSQL
Choisir entre une BDD relationnelle ou NoSQL
APPRÉHENDEZ LA STRUCTURE DE VOS DONNÉES
Vous avez déjà utilisé un tableur comme Excel, Google Sheet, ou LibreOffice Calc ? Alors bravo ! Vous savez
manipuler des données dites structurées.
Sur un tableur, il y a des lignes et des colonnes.
En général, on y indique sur chaque ligne chacune des entités que l’on enregistre, et en colonne les
caractéristiques de chacune de ces entités.
10
Choisir entre une BDD relationnelle ou NoSQL
STRUCTURE
Ce que l’on représente, ce sont des lieux de tournage. On met donc :
- Pour chaque ligne, les lieux de tournage.

- Et, en colonnes, on indique les caractéristiques de ces lieux de tournage : date, adresse, film,
réalisateur, etc.
11
AVEZ-VOUS DÉJÀ ENTENDU PARLER DU BIG DATA ?
Il s’agit d’un phénomène très actuel où une importante quantité de données est produite au quotidien.
En effet, on utilise de plus en plus d’appareils électroniques tels que nos Smartphones, tablettes, etc. Face à ce
volume important de données, il a fallu s’adapter et trouver de nouvelles technologies pour stocker ces
données, mais aussi pour savoir les représenter, les organiser, et surtout les analyser !
On parle souvent des trois V qui caractérisent le big data :
- Volume
- Vélocité
- Variété
Arrêtons-nous sur ce troisième point : la variété. Les formes de données générées par le Web sont de plus en
plus diverses : images, vidéos, textes, opinions sur les réseaux sociaux, e-mails, etc. Ces données sont
difficiles à représenter sous forme de tableau : on dit donc qu’elles sont peu structurées.
Les données de nos lieux de tournage sont au contraire structurées, car elles se représentent facilement
dans un tableau.
12
REPRÉSENTEZ VOS DONNÉES EN FONCTION DE LEUR STRUCTURE
Imaginons que vous souhaitiez enregistrer des informations sur des personnes (dans le strict respect du
RGPD, bien entendu), de manière structurée. Vous allez donc faire un tableau avec une ligne par personne
et une colonne par caractéristique.
En effet, on peut caractériser une personne par son état civil (nom, prénom, date de naissance, etc.), mais
aussi par ses comportements sur Internet (quelles pages va-t-elle visiter?), par ses comportements d’achat
(quels produits achète-t-elle?), par les personnes avec qui elle interagit (son cercle amical, professionnel,
associatif), et il y a encore beaucoup d’autres possibilités !
Beaucoup de caractéristiques possibles, c’est beaucoup de colonnes dans notre tableau.
De plus, vous obtiendrez rarement toutes les caractéristiques d’une personnes d’un coup, loin de là !
13
REPRÉSENTEZ VOS DONNÉES EN FONCTION DE LEUR STRUCTURE
Cela veut dire que pour une ligne donnée, seule une toute petite proportion des colonnes seront remplies ;
Et pour la ligne suivante, d’autres colonnes seront remplies, mais pas forcément les mêmes !
Vous aurez donc un tableau très peu rempli, avec énormément de colonnes. Avouez que sur Excel, ce n’est
pas pratique d’avoir une feuille énorme avec très peu de données éparpillées un peu partout !
14
MAIS ALORS, COMMENT REPRÉSENTE-T-ON DES DONNÉES NON STRUCTURÉES ?
Il y a une infinité de représentations possibles !
Si on reprend l’exemple des données relatives à une personne, on peut le faire sous une représentation de type
Clé-Valeur.
C’est-à-dire que chaque clé est l’intitulé d’une caractéristique (« nom », « prénom », etc) et à chaque clé
est associée sa valeur (« Diard », « Margeritte », etc.).
L’une des représentations qui utilise le principe Clé-Valeur est le format de fichiers JSON (« JavaScript
Object Notation »).
ET POUR LES DONNÉES STRUCTURÉES, QUEL FORMAT DE FICHIER FAUT-IL ?
Le plus souvent, on utilise le format CSV (« Comma-separated values »), conçu pour représenter un tableau.
La première ligne du fichier donne le nom des colonnes, et les suivantes présentent toutes les données,
séparées par des virgules, des point-virgules ou des tabulations :
Le plus souvent, on utilise le format CSV (« Comma-separated values »), conçu pour représenter un tableau.
La première ligne du fichier donne le nom des colonnes, et les suivantes présentent toutes les données,
séparées par des virgules, des point-virgules ou des tabulations. Comme vous le voyez ci-dessus, le
séparateur utilisé n'est pas une virgule, mais un point virgule.
16
PROBLÈMES COURANTS
Sachez que cela est généralement dû à un problème d'encoding. L'encoding, c'est la norme utilisée pour transformer les différents
caractères que nous utilisons dans une version "informatique".
C'est un sujet assez complexe que nous n'aborderons pas ici en détail, mais sachez que les 3 grandes normes d'encoding sont :
- ASCII : l'enconding le plus basique qui ne permet pas d'écrie des accents
- Latin-1 : un encoding très utilisé, notamment via Windows et Excel
- UTF-8 : un enconding très large et très permissif, très utilisé dans le web et en data
Si vous avez des caractères étranges au chargement d'un fichier CSV, essayer de recharger votre fichier en spécifiant un encoding 17
différent: latin-1 ou UTF-8 par exemple.
CHOISISSEZ VOTRE SGBD EN FONCTION DE LA STRUCTURE DE VOS DONNÉES
Connaître la structure de vos données vous permet de bien choisir votre SGBD. Si votre SGBD est mal adapté
à vos données, alors il sera plus complexe de lui formuler des requêtes pour accéder aux données, et le temps
de réponse sera probablement plus long.
Le plus pratique pour stocker des données structurées, c’est d’utiliser une base de données relationnelle.
Ce terme vient du « modèle relationnel », qui est un moyen de représenter les relations dans un ensemble
d’informations.
Les SGBD qui gèrent les bases de données relationnelles sont appelés SGBDR. Pour éviter d’avoir un
langage différent pour chacun de ces SGBDR, on a créé le langage SQL. Il est commun à la quasi-totalité
des SGBDR, et il permet d’insérer, de lire, d’actualiser ou de supprimer des données dans une base
relationnelle
Les plus célèbres SGBDR sont :

- PostgreSQL
- MySQL
- Oracle
- SQLite
18
ET POUR LES DONNÉES NON STRUCTURÉES ?
C’est plus complexe, car les données non structurées ont des formes extrêmement variées. Tout dépend de
ce que vous voulez y stocker. Les SGBD qui s’écartent du modèle relationnel sont appelés « NoSQL »
(c’est-à-dire « Not Only SQL », soit en français « pas uniquement SQL »).
Parmi les SGBD NoSQL, on trouve :
- Elasticsearch : très performant pour stocker du texte et y effectuer des recherches.

- Neo4j : qui stocke des « graphes », c.-à-d. des données de type « réseaux » constitués d’éléments
connectés entre eux : réseaux sociaux, routiers, informatiques, etc.
- MongoDB : qui stocke des données au format Clé-Valeur, comme dans l’exemple que nous avons vu plus
haut.
Pour nos données (celles des lieux de tournage), quel SGBD utiliser ?
19
Décomposez la modélisation de votre BDD en trois étapes clés
BASES DE DONNÉES RELATIONNELLES
Bon… résumons un peu ce que nous avons appris jusqu’à maintenant. Une base de données, c’est
comme un entrepôt. Elle est destinée à alimenter un programme informatique, de la même
manière qu’un entrepôt de matières premières alimente une usine textile. Entre les deux, il y a le
SGBD, qui est comme l’entreprise qui gère l’entrepôt.
Comme nous l’avons vu, il existe des données très structurées et d’autres moins structurées.
L’objet de ce cours, c’est d’apprendre à modéliser une base de données pour des données
structurées (les données des lieux de tournage), ce qui implique que nous utilisions une base de
données relationnelle.
Bon… résumons un peu ce que nous avons appris jusqu’à maintenant. Une base de données, c’est
comme un entrepôt. Elle est destinée à alimenter un programme informatique, de la même
manière qu’un entrepôt de matières premières alimente une usine textile. Entre les deux, il y a le
SGBD, qui est comme l’entreprise qui gère l’entrepôt.
Comme nous l’avons vu, il existe des données très structurées et d’autres moins structurées.
L’objet de ce cours, c’est d’apprendre à modéliser une base de données pour des données
structurées (les données des lieux de tournage), ce qui implique que nous utilisions une base de
données relationnelle.
20
1. CONSTRUISEZ VOTRE MODÈLE CONCEPTUEL DE DONNÉES (MCD)
La première étape, c’est le modèle conceptuel des données (MCD). Elle se décompose elle-même en
trois sous-étapes :
- Cherchez les concepts présents dans vos données.

- Cherchez les associations qui existent entre ces concepts
- Caractérisez ces associations par une multiplicité, que vous indiquez grâce à des signes du type
0, 1, 1..*, 0..*,, etc
Pas besoin de les comprendre pour le moment, mais retenez juste que les multiplicités permettent de
spécifier par exemple :
Si un film est produit par une ou plusieurs boîtes de production ;
Si un réalisateur peut réaliser un ou plusieurs films, etc.
21
DESSINER LE MODÈLE CONCEPTUEL
Pour dessiner le modèle conceptuel, il y a plusieurs possibilités. Les deux plus répandues sont :
- Le modèle Entité-Associations (E-A), qui fait partie de la méthode MERISE ;

- Le diagramme de classes, qui fait partie du langage de modélisation UML.
Dans leurs principes, ces deux méthodes de modélisation sont très similaires, même si elles utilisent
des conventions graphiques un peu différentes.
22
MODÈLE E-A
Par exemple, un modèle E-A ressemble à ceci :
23
DIAGRAMME DE CLASSES UML
Par exemple, un diagramme de classe ressemble à ceci :

CONCEVEZ VOTRE MODÈLE LOGIQUE DE DONNÉES (MLD)
Le modèle conceptuel est un ensemble de concepts. Mais maintenant, il va falloir donner une structure à ces concepts.
Vous vous souvenez ? On a dit que des données structurées peuvent se représenter sous forme de tableaux. Eh bien c’est notre prochaine étape : formater tous
nos concepts en des tableaux !
Vous allez construire le modèle logique des données (MLD). Ici, vous n’avez plus vraiment le choix entre plusieurs modes de représentation comme c’était le
cas pour le MCD. Vous utiliserez la modélisation relationnelle.
En modélisation relationnelle, un tableau s’appelle une table.
La principale transformation pour passer de l’UML au modèle relationnel sera de transformer les multiplicités des associations en clés étrangères. Le concept
des clés étrangères vous est étranger ? Ne vous inquiétez pas, vous y viendrons !
Ici, vous vous rapprochez de la solution technique, car vous commencez à façonner vos données pour qu’elles puissent rentrer dans un SGBDR.
EXEMPLE DE MODÈLE RELATIONNEL

DÉTERMINEZ VOTRE MODÈLE PHYSIQUE DE DONNÉES (MPD)
Au bout d’un moment, il va bien falloir dialoguer avec la machine qui accueillera votre BDD.
Et comme vous le savez, pour parler avec un ordinateur, on utilise du code !
La dernière étape est donc de traduire le modèle relationnel en code SQL compréhensible par le SGBDR que vous aurez choisi (PostgreSQL, MySQL,
Oracle, SQLite, etc.).
Même si ces SGBDR comprennent tous le langage SQL, il existe parfois des différences. C’est-à-dire que chaque SGBDR a ses propres variantes du
langage SQL.
Le SQL peut se décomposer en quatre langages :
- Le langage de définition de données (LDD ou DDL en anglais) : pour créer la structure de la BDD
- Le langage de manipulation de données (LMD ou DML) : pour insérer, actualiser, supprimer ou récupérer des données
- Le langage de contrôle des données (LCD ou DCL) : pour gérer les droits d’accès aux données
- Le langage de contrôle des transactions (LCT ou TCL) : pour la validation ou l’annulation de modifications de données.
Dans ce cours, nous ne verrons que les deux premiers niveaux : le MCD et le MLD. Quant au MPD, il nécessite d’utiliser le langage SQL et de choisir un
SGBDR, puis de l’installer. Nous avons fait le choix de ne pas aller jusque-là pour conserver un cours court.
À VOUS DE JOUER !
Voici un modèle conceptuel d’une base de données, sous forme de diagramme de classes UML.
Essayez de deviner quel type de logiciel peut utiliser cette BDD ?

Quelles sont les fonctionnalités que ce logiciel propose, et comment l’utilisateur peut bien l’utiliser ?
RÉPONSE
Il s’agit d’une BDD utilisée par un logiciel de gestion de commandes et de facturation (utilisé dans un magasin, par exemple).
Le logiciel permet d’enregistrer tous les articles en vente, où chaque article fait partie d’une catégorie. Il permet aussi d’enregistrer des commandes,
lesquelles sont relatives à un ou plusieurs clients. Chaque commande a une adresse de livraison.
Lorsqu’une commande est expédiée, l’expédition est enregistrée automatiquement dans le logiciel, et une facture est associée à chaque expédition.
RÉSUMÉ
Tableau uniquement valable pour des bases de données structurées :
Niveau de modélisation Abréviation Caractéristiques Mode de représentation
Niveau conceptuel MCD Graphique compréhensible par un être humain Modèle E-A (MERISE)
ou
Diagramme de classes (UML)
Niveau logique MLD Traduction du MCD pour le structurer selon les principes du modèle relationnel, commun Modèle relationnel
à tous les SGBD-R
Niveau physique MPD Très spécifique au SGBD-R choisi, souvent écrit en SQL SQL – LDD (Langage de Définition des
Données)
Tenez compte de la redondance dans votre modélisation
LES INCOHÉRENCES
Commençons par une devinette. Une incohérence est présente dans notre fichier, entre les identifiants 2018-650 et 2018-672 :
LES INCOHÉRENCES
La voici : la réalisatrice de la série Vernon Subutex est orthographiée de deux manières différentes : « Cathy Verne » et « Cathy Verney ».
Le souci, c’est que l’information selon laquelle la productrice de Vernon Subutex est Cathy Verney est présente à plusieurs endroits dans notre fichier : aux
identifiants 2018-658, 2018-659, 2018-660, etc.
On appelle ceci une redondance d’information.
La redondance, c’est problématique, pour différentes raisons.
- Premièrement cela peut provoquer des incohérences dans les données : c’est ce que nous venons de voir.
- Ensuite, imaginez que Cathy Verney change de nom. Il faudra actualiser l’information à plusieurs endroits dans le fichier, et on aura vite fait d’oublier une
ou deux lignes : cela créera encore des incohérences !
- Imaginez enfin que nous décidions de supprimer Vernon Subutex de notre BDD. Cela supprimera également les informations relatives à Cathy Verney. Or
selon les cas d’utilisation, on peut très bien souhaiter qu’un réalisateur puisse exister dans notre base, même si elle ou il n’est associé à aucun lieu de
tournage. De même, on ne peut actuellement pas ajouter de réalisateur s'il n’a pas tourné au moins une scène, car notre fichier décrit des lieux de tournage
et non pas des réalisateurs/réalisatrices.
ALORS, QUELLE EST LA SOLUTION ?
Il suffit de créer un nouveau tableau contenant les réalisateurs !
Avec ce nouveau tableau, les réalisateurs pourront exister indépendamment des

tournages qu’ils ont réalisés ou non. C’est un premier avantage.
Mais il y a un autre avantage important : dans ce tableau, un seul réalisateur n’est

présent que sur une seule ligne ! Ainsi, si vous souhaitez actualiser une information
relative à un seul réalisateur, vous ne le ferez qu’à un seul endroit ! Fini les
incohérences liées à la redondance d'informations.
Aussi, si l’information n’est présente qu’à un seul endroit, le stockage

d’information prend moins de place dans le mémoire de l’ordinateur.
Cette méthode est propre au modèle relationnel (le MLD).

Au niveau du vocabulaire, on dit que :
- L’identifiant réalisateur est la clé primaire de la table « realisateur_ice »
- La colonne « Réalisé par » de la table « lieu_de_tournage » est une clé étrangère qui référence
la clé primaire de la table « realisateur_ice ».
Posez les premières briques de votre diagramme de classes
C’EST A VOUS !
Dans cette seconde partie du cours, vous verrez la première des trois étapes de la modélisation d’une base relationnelle. Cette première étape, c’est le modèle
conceptuel des données (MCD).
Comme son nom l’indique, vous allez représenter les concepts présents dans vos données, et vous allez aussi chercher les associations qu’il existe entre ces
concepts.
A vous de jouer !
À partir des données des lieux de tournage, il faut que vous dégagiez les concepts principaux, ainsi que leurs caractéristiques.
Je vous propose de faire des petits rectangles divisés en trois parties. Dans la partie haute, vous mettrez le nom du concept, dans la partie centrale la liste des
caractéristiques. Et pour la partie basse, un peu de patience, je vous en parle un peu plus loin dans le chapitre.
Habituez-vous à utiliser dès maintenant :

- La convention Upper Camel Case pour vos noms de concepts :
- lettres sans accents
- Pas d’espace entre les mots
- Mots au singulier
- Première lettre de chaque mot en majuscule.
- Le Lower Camel Case pour les attributs :
- même chose que le Upper Camel Case sauf que la toute première lettre est en minuscule.
RÉPONSES
Il n’y a pas de bonne ou de mauvaise réponse à cet exercice : si votre réponse diffère un peu de la mienne, ce n’est pas très grave. Certes, deux modélisations ne
se valent pas toujours, mais c’est avec l’expérience que vous acquerrez les automatismes de modélisation.
Voici une réponse possible :

J’ai ici volontairement ignoré la colonne « identifiant du lieu »,
car vous verrez la notion d’identifiant un peu plus tard.
La colonne « Producteur » a été représentée sur ce diagramme
par la caractéristique « nom » du concept
« SocieteDeProduction ».
La colonne « Réalisateur_ice » a été représentée sur ce
diagramme par la caractéristique « nom » du concept
« Realisateur_ice ».
Les colonnes « Coordonnée en X » et « Coordonnée en Y » ont
été respectivement transformées en « longitude » et
« latitude ».
Formalisez vos concepts en classes
UML
Sur ce diagramme, chaque classe est représentée par un rectangle, dont le nom figure sur la partie haute.
Une classe, c’est un peu comme un moule : elle donne la forme générale des instances qui seront créées à partir d’elle.
À partir d’un moule à gaufre, vous pouvez fabriquer autant de gaufres que vous souhaitez.
Le moule, c’est la classe, et vos gaufres, ce sont les instances.
De même, la classe « Film » définit la forme générale des instances issues de cette classe.
Caractérisez vos classes avec les attributs et les méthodes
UML
Dans la partie centrale de notre rectangle, nous indiquons les attributs. Un attribut, c’est une caractéristique de la classe.
Un attribut doit être typé, c’est-à-dire que l’on sait à l’avance quels types de valeurs il peut contenir :
- Valeurs numériques (un nombre entier, un nombre décimal, etc.)
- Du texte
- Une date
- Etc.
L’ensemble des valeurs que peut prendre un attribut est appelé son domaine.
Pour définir un domaine, vous pouvez le faire soit en énumérant toutes les valeurs possibles (définition en extension), soit en donnant les caractéristiques des
valeurs, comme par exemple « ce doit être un nombre entier » (définition en intention).
Par exemple :
- Définition en extension :
- domaine de l’attribut « typeDeTournage »:
- ["Long métrage", "Téléfilm", "Série TV", "Série web"]
- Définition en intention :
- domaine de « dateDeDebut »: date
- domaine de « codePostal »: nombre entier compris entre 1 000 et 99 999.
UML
On peut définir des attributs composites : ils sont composés de plusieurs valeurs (dont le nombre est fixe) qui ne sont pas forcément du même type. Par
exemple, un attribut « adresse » est souvent composé de :
- Un numéro de voie (nombre entier supérieur à 0)
- Un libellé de voie (du texte)
- Un code postal (nombre entier)
- Un nom de ville (texte)
- Etc.
On peut définir aussi des attributs multivalués : cela signifie que l’attribut peut prendre zéro, une ou plusieurs valeurs du même type (ou même domaine), sans
que l’on sache à l’avance combien il y en aura.
Ce serait par exemple le cas d’un attribut numéro(s) de téléphone d’une classe « Personne », car une personne peut avoir zéro, un, ou de multiples numéros de
téléphone.
Enfin, on dit qu’un attribut est dérivé, lorsqu’il peut être déterminé à partir d’autres attributs.
Dans votre cas, « anneeDuTournage » peut être déterminé à partir « dedateDeDebut ».
LES MÉTHODES
Les méthodes se programment soit dans le code de l’application qui va utiliser le SGBD, soit dans le SGBD lui-même lorsque celui-ci le permet. Mais dans les
deux cas, vous ne verrez pas cela dans ce cours. En effet, la programmation de méthodes dans un SGBD est trop spécifique au SGBD en question pour être
abordé ici.
Une méthode est un enchaînement d'opérations destiné :
Soit à modifier les attributs ;
Soit à calculer un résultat à partir des attributs ;
Soit les deux en même temps.
En fait, les méthodes définissent le « comportement » de votre classe, c’est-à-dire les actions qu’elle est capable de réaliser.
En général, on préfère représenter les attributs dérivés par des méthodes, car un attribut dérivé est le résultat d’un calcul sur les attributs non dérivés.
Dans votre cas, vous pouvez donc créer une méthode qui s’appelle determinerAnneeDeTournage(), qui déterminera l’année de tournage à partir de
dateDeDebut.
Dialoguez avec les développeurs logiciel grâce à l’UML
DIALOGUEZ GRÂCE AU DIAGRAMME DE CLASSES
Vous avez déjà entendu parler de la programmation « orientée objet » ?
Dans un langage de programmation orientée objet, le développeur définit des objets. Un objet, c’est un concept, une idée ou une chose du monde réel. Chaque
objet possède des attributs (ce sont ses caractéristiques) ainsi qu’un ensemble de comportements possibles.
Oui mais ici, on ne fait pas de programmation logicielle, on modélise une base de données !
Oui, mais avouez que la description que je viens de vous donner est quand même très proche de ce que vous venons de voir : des classes caractérisées par des
attributs et dont les méthodes définissent un comportement.
En fait, le diagramme de classes UML est aussi utilisé par les développeurs qui codent avec des programmes orientés objet : Python, PHP, C++, Java, etc. Et
c’est bien plus pratique comme ça !
L'utilisation du diagramme de classes UML pour la modélisation de la base de données s'est généralisée avec la croissance de la programmation objet. Étant
donné qu'une base de données fonctionne quasiment toujours en dialogue avec un programme informatique, il y a des échanges d'informations entre les deux.
Si des deux côtés, les concepts manipulés sont les mêmes, alors c'est bien plus simple pour communiquer entre ceux qui s'occupent de la BDD et ceux qui
codent le programme.
On comprend donc pourquoi le diagramme de classes UML est utilisé des deux côtés de la barrière (côté base de données et côté applicatif).
Certains langages orientés objet proposent même des fonctionnalités qui permettent de créer automatiquement la structure de la base de données relationnelle à
partir du code informatique écrit en ce langage. On appelle cela des ORM pour Object-Relational Mapping.
DISTINGUEZ LE DIAGRAMME DE CLASSE DES AUTRES DIAGRAMMES UML
Le diagramme de classes que vous avez dessiné est bien adapté à votre problème, car il décrit la structure de votre future BDD. Cette structure est statique, elle
ne varie pas dans le temps. En effet, la structure d’une base de données ne change uniquement que lorsque le logiciel qui l’utilise est mis à jour sous une
nouvelle version.
Conclusion, pour une BDD, le diagramme de classe UML est suffisant. Il est aussi très utile pour les développeurs qui vont représenter les classes de leur
programme. Même si pour eux, quelque chose de statique reste insuffisant. Le langage UML prévoit alors aussi d’autres types de diagrammes permettant par
exemple de représenter le comportement du programme dans le temps.
RÉSUMÉ
Vocabulaire Signification Exemple(s) NomDeLaClasse

Classe Un concept, un objet Un film
Instance Une réalisation concrète d’un Le film « 120 Battements par attributs
concept minute »
Attribut Une caractéristique d’une classe Le titre du film methodes()
Type (Domaine d’un attribut) Type de valeur (ou ensemble de « Nombre », « texte »,
valeurs) que peut prendre un « Nombre compris entre 0 et
attribut 100 », « Choix parmi trois
valeurs : Homme, Femme, Non-
binaire », etc.
Attribut composite Attribut composé d’un nombre Adresse (numéro, voie,

fixe de valeurs de domaines commune, etc.)
différents
Attribut multivalué Attribut composé d’un nombre Numéro(s) de téléphone

variable de valeurs d’un même
domaine
Méthode Suite d’opérations calculant un Méthode calculerAge =

résultat à partir des attributs dateActuelle – dateNaissance
et/ou modifiant les attributs.
Associez vos classes pour garder du lien dans vos données
ASSOCIEZ VOS CLASSES POUR GARDER DU LIEN DANS VOS DONNÉES
Alors. Où en êtes-vous ?
Vous avez identifié toutes les classes ainsi que leurs attributs.
À ce stade, toutes les colonnes du fichier CSV ont trouvé une place dans votre modélisation.
Vous savez par exemple que les informations sur la réalisatrice Cathy Verney seront stockées dans la classe Realisateur_ice, et que la série « Vernon Subutex »
sera enregistrée dans la « classeSerieTV ».
Mais ces deux informations sont séparées dans deux classes distinctes.
Or, il faut que vous puissiez indiquer le lien qui lie « Vernon Subutex » à sa réalisatrice : et à présent, ce lien n’est pas encore modélisé.
Vous l’aurez compris, dans ce chapitre, vous allez créer du lien entre les classes.
CONSTITUEZ VOS ASSOCIATIONS
Pour créer vos associations, je vous propose de tracer des traits qui relient vos classes, et de leur donner un nom, de préférence un verbe tel que « réalise », «
produit », etc.
C’est à vous !
CONSTITUEZ VOS ASSOCIATIONS

DÉFINISSEZ LES MULTIPLICITÉS DE VOS ASSOCIATIONS
Il y a un concept très important quand on définit une association : c’est la notion de multiplicité.
Elle permet de dire si un film peut être réalisé par UN SEUL ou par PLUSIEURS réalisateurs, et inversement : si un réalisateur peut produire UN SEUL ou
PLUSIEURS films.
Il ne faut pas négliger les multiplicités, car ceci aura des implications dans le SGBDR.
Par exemple, si vous considérez à tort qu’un réalisateur ne peut réaliser qu’un seul film, alors la structure de votre BDD ne sera pas faite pour accueillir plus
d’un film par réalisateur : et pour modifier cette structure, ce sera un peu plus complexe qu’on ne le pense.
Il existe trois types d’associations :

- Plusieurs à plusieurs (many-to-many) :
- un film peut être réalisé par plusieurs réalisateurs, et un réalisateur peut avoir réalisé plusieurs films
- Un à plusieurs (one-to-many) ou plusieurs à un (many-to-one) :
- un film n’est réalisé que par au plus 1 société de production, et une société peut produire plusieurs films ;
- Un à un (one-to-one) :
- vous n’avez pas ce cas dans vos données, mais c’est lorsqu’une instance d’une classe
A ne peut être associée qu’à au plus 1 instance d’une classe B. Et qu’une instance de
B ne peut être associée qu’à au plus 1 instance de A.
Par exemple, un cinéma n’a qu’une seule adresse, et une adresse donnée ne peut accueillir qu’un seul cinéma.
Ensuite, vous pouvez aller plus loin dans la précision des multiplicités.
Par exemple, quand vous dites « au plus 1 », vous pouvez préciser s’il s’agit de « strictement 1 », ou bien « 0 ou 1 ». Aussi, quand vous dites « plusieurs »,
vous pouvez entendre « 0, 1 ou plus », ou bien « strictement plus que 1 », etc.
Voici comment noter cela :

Au plus 1 :
Notation Abréviation Signification
0..1 (pas d'abréviation) 0 ou 1
1..1 1 Exactement 1
Plusieurs :
Notation Abréviation Signification
0..* * 0, 1 ou plus
1..* (pas d'abréviation) Au moins 1
n..n n Exactement n (où n est un nombre

entier)
m..n (pas d'abréviation) Au moins m et au plus n (avec m et n

nombres entiers tels que m<n)
Voici comment s’utilisent ces notations :

- Un film peut être réalisé par au moins 1 réalisateur (noté 1..* ), et un réalisateur peut avoir produit 0, 1 ou plusieurs (noté * ) films :
- Un film est réalisé par exactement 1 société de production ( 1 ), et une société peut produire 0, 1 ou plusieurs films ( * ) :
Un cinéma a exactement 1 adresse ( 1 ), et une adresse donnée ne peut accueillir que 0 ou 1 seul cinéma ( 0..1 ) :
Le choix du minimum fixé à 0 ou 1 est souvent discutable.

Dans l’exemple ci-dessus, considérer qu’un réalisateur peut avoir produit 0, 1 ou plusieurs films, c’est considérer qu’il peut y avoir dans votre BDD un
réalisateur qui n’est associé à aucun film.
Si la notion de réalisateur est centrale dans le fonctionnement de votre application, alors vous pouvez décider qu’un réalisateur peut exister sans avoir produit
de film.
Mais si la notion de réalisateur est secondaire, alors vous pouvez dire « Non, telle que j’ai conçu mon appli, réalisateur sans film, ça ne sert à rien », et donc
choisir une multiplicité de 1..*au lieu de *.
Voici donc votre modélisation avec les multiplicités :
Les termes multiplicité et cardinalité sont souvent confondus.

Mais officiellement, une multiplicité désigne l’ensemble des cardinalités possibles entre deux instances.
Par exemple, on dira qu’une société de production peut produire 0, 1 ou plusieurs films.
Cela correspond à une multiplicité de 0..*.
Et concrètement, dans vos données : La société Les Films de Pierre a produit 120 Battements par minute et Arthur Rambo (ce qui correspond à une cardinalité
égale à 2) ; La société Haut et Court a produit trois films (cardinalité de 3).
CARACTÉRISEZ VOS ASSOCIATIONS GRÂCE AUX CLASSES D’ASSOCIATION
Il arrive de devoir donner des caractéristiques à une association.

Peut-être qu’intuitivement, vous aviez envie de dessiner ce schéma conceptuel...
... au lieu de dessiner trois classes : Film, Tournage et Lieu, comme nous l’avons fait précédemment. Et vous auriez eu raison ! Mais dans ce cas, vous n’auriez
pas réussi à placer les colonnes Date de début et Date de fin. En fait, ces deux dates sont des caractéristiques de l’association qui unit un lieu à un film. Eh
bien, sachez qu’il est possible de donner des caractéristiques à un lien, grâce à une classe d’association. Ici, comme l’association s’appelle « est tourné », vous
pouvez appeler votre classe « Tournage » :
RENFORCEZ VOS ASSOCIATIONS GRÂCE À LA COMPOSITION
Il existe un type d’association particulier, appelé l’association de composition. Celle-ci s’utilise quand une classe est un composant d’une autre classe. Prenez
l’exemple d’un circuit électronique : il est composé de composants électroniques : diodes, condensateurs, microprocesseurs, etc. Ainsi, on peut avoir une
association de composition entre une classe CircuitElectronique et une classe CompostantElectronique.
Imaginez que votre circuit soit défaillant et que vous deviez donc le jeter. Dans ce cas, vous jetez automatiquement tous ses composants. C’est là la particularité
de la composition : le composant (une diode, par exemple) ne peut exister que via son composite (circuit électronique). Pour votre appli, vous pourriez
considérer qu’un tournage est un composant du film. En effet, rien ne sert d’enregistrer dans votre BDD un tournage si vous ne savez pas à quel film il est
associé. On peut aussi avoir une composition entre FilmetSocieteDeProduction.
En effet, un film ne peut exister si une société ne l'a pas produit. De plus, 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.
Voici comment cette composition aurait été représentée : avec un losange noir (plein) du côté du composite :
RENFORCEZ VOS ASSOCIATIONS GRÂCE À LA COMPOSITION
La composition s’emploie quand ces trois caractéristiques sont réunies : Le composite est « composé » de composants. L’association de composition est de type
un-à-plusieurs, car le composite peut avoir plusieurs composants (0..1, 1, *ou1..*), et le composant appartient à un et un seul composite (la multiplicité est donc
forcément1, rien d’autre) : on dit que le composite n’est pas partageable. Il y a un lien entre le cycle de vie du composite et du composant : un composant
disparaît dès que l'objet composite auquel il appartient est supprimé. La composition est un cas particulier d’association un-à-plusieurs. Tadaaaaaaam ! Je vous
présente donc, en exclusivité, la dernière version de votre modélisation UML !
PRENEZ GARDE À LA REDONDANCE !
Attention, la redondance peut aussi se cacher dans les associations !
Par exemple, vous pouvez être tenté de dire qu’un réalisateur travaille pour une société de production lorsqu’il réalise un film. On aurait donc ceci :
Cependant, on peut déduire l’association travaille pour grâce aux deux autres associations. En effet, si on sait que Le Temps des égarés est réalisé par Virginie
Sauveur et produit par Delante Productions, alors on déduit que Virginie Sauveur a travaillé pour Delante Productions.
À VOUS DE JOUER
Voici un diagramme de classes représentant des concerts donnés par des groupes de musique. Déterminez les multiplicités possibles des associations :
RÉPONSE
Voici une réponse possible :
- Un groupe de musique peut donner 0, 1 ou plusieurs concerts

- Un même concert peut accueillir plusieurs groupes (mais au moins 1) ;
- Par contre, un même concert ne peut se tenir que dans une seule salle de concert ;
- Cette salle peut quant à elle accueillir 0, 1 ou plusieurs concerts (à des dates différentes) ;
- Une salle de concert a obligatoirement une et une seule adresse ;
- Mais une adresse donnée n’accueille pas forcément de salle de concert, ou peut en accueillir plusieurs.
RÉSUMÉ
- Graphiquement, on modélise les associations entre les classes par des traits qui les relient.
- Une association peut être de trois types :
- plusieurs-à-plusieurs
- un-à-plusieurs
- un-à-un.
- On précise ces trois types grâce aux multiplicités :0..1, 1, 1..*, etc.
- Une association peut avoir des caractéristiques, que l’on indique dans une classe d’association.
- Pour indiquer qu’une association est de type « composant », on utilise une composition.
Voilà, vous avez posé les bases de votre diagramme UML. Maintenant, il ne reste plus qu’à le perfectionner grâce aux possibilités du langage UML.
Améliorez votre diagramme de classes
AMÉLIOREZ VOTRE DIAGRAMME DE CLASSES
À présent, vous connaissez les bases de la modélisation UML : comment représenter des classes et les associer.
Je vous propose maintenant de perfectionner votre modélisation.
GÉNÉRALISEZ ET SPÉCIALISEZ VOS CLASSES
Jusqu’à maintenant, j’ai parlé de films de manière générale.

Mais vos données sont un peu plus précises que cela.
En effet, ce que j’ai appelé « film » peut en réalité être un long-métrage, un téléfilm ou une série (diffusée sur le web ou à la télévision).
Pour être plus correct, je vais maintenant employer le terme « Oeuvre » au lieu de « Film ».
Une œuvre sera donc soit un long-métrage, soit un téléfilm, ou une série.
Un long-métrage est un film tel que nous l’entendons habituellement, un téléfilm est un film spécialement conçu pour passer à la télévision plutôt qu’au
cinéma, et une série est un enchaînement de plusieurs épisodes, souvent regroupés en saisons.
Jusqu’à maintenant, le type de l'œuvre est enregistré dans l’attribut typeDeTournage . J’ai vu dans le fichier CSV que dans le cas des séries, on connaît parfois
le numéro de saison.
Peut-on ajouter un attribut saison dans la classe Œuvre ?
C’est une bonne idée.
Cependant, cet attribut ne sera utilisé que si l'œuvre est une série.
Il restera vide si l'œuvre est un téléfilm ou un long-métrage. Cette solution n’est donc pas optimale. L’idéal serait de placer cet attribut dans une classe Serie.
Heureusement, c’est possible ! On fait cela via la notion d’héritage, comme ceci :
La relation d’héritage se représente par une flèche triangulaire blanche (vide).

Elle indique que la classe Oeuvre(appelée classe mère) est plus générale que ses classes filles, qui sont plus spécialisées.
Ainsi, toutes les classes filles (Telefilm, Serie et Long Metrage) héritent de Oeuvre, et cette dernière transmet automatiquement à ses filles ses attributs et ses
méthodes. De cette manière, toutes les classes filles possèdent l’attribut Titre. La classe Serie a quant à elle deux attributs : Titre et Saison.
Sur ce schéma, les classes Telefilm et Long Metrage sont vides.

Ce n’est pas grave ! Mais si vous aviez eu plus d’informations dans le fichier, vous auriez pu ajouter, par exemple, un attribut chaine pour indiquer la chaîne de
télévision sur laquelle est diffusée le Telefilm.
Soyons fous : on peut aussi enchaîner les relations d’héritage, en créant les classes SerieTV et SerieWeb !
Voici le résultat :
RESTREIGNEZ L’INSTANCIATION DES CLASSES GRÂCE AUX CLASSES ABSTRAITES
Lorsque l’on utilise l’héritage, il est parfois utile de spécifier qu’une classe est abstraite, c’est-à-dire qu’elle ne peut pas être instanciée.
C’est votre cas : dans la BDD, vous voulez qu’une œuvre soit obligatoirement un téléfilm, une série TV, une série web ou un long-métrage. La notion d'œuvre
est trop générale pour que vous l’acceptiez. En effet, considérer un téléfilm simplement comme une oeuvre, c’est perdre les informations spécifiques au
téléfilm.
Par exemple, En Thérapie est une instance de SerieTV, mais pas de Oeuvre . De même, 120 Battements par minute est une instance de Long Metrage. Bref, on
veut qu’aucune œuvre soit enregistrée dans la BDD sans préciser si c’est un téléfilm, une série ou un long métrage. Pour indiquer une classe abstraite, il suffit
de mettre son titre en italique. Voici donc ce que cela donne si vous définissez Œuvre et Serie comme abstraites :
Une classe abstraite est toujours héritée. Elle peut d’ailleurs être héritée par d'autres c
classes abstraites, mais en fin de chaîne, il doit y avoir une classe non abstraite.
Je vous donne ici quelques autres possibilités qui concernent les associations entre les classes. Dans le cadre de ce cours, il n’est pas nécessaire de les détailler,
mais sachez juste que ces possibilités existent. Je vous donnerai quelques liens utiles si vous souhaitez creuser le sujet.
L’agrégation
L’agrégation s’utilise lorsqu’une classe est un ensemble ou un regroupement d'objets. Elle est très similaire à une association classique, et que vous l'utilisiez ou
non, cela n’aura aucune implication lors de la traduction du MCD vers le MLD.
Elle se représente comme ceci, avec un losange blanc (vide) :

Contrairement à la composition, il n’y a pas de contrainte sur les multiplicités, ni sur le cycle de vie des objets agrégés (ils peuvent exister même lorsque l’objet
agrégeant disparaît).
L’association ternaire
Il est possible de créer des associations entre plus que 2 classes. Ce sont les associations N-aires. Voici un exemple d’association ternaire :
En pratique, on n’utilise jamais d’association de degré supérieur à trois. De plus, les associations ternaires peuvent
toujours être transformées en trois associations binaires, en transformant l’association en une nouvelle classe,
comme ceci.
Il est conseillé de ne pas abuser des associations ternaires, car elles sont souvent moins intelligibles.
LES NOTES
Il est possible d’ajouter des notes au diagramme de classes. Elles servent à apporter tout type de précisions. Notamment les contraintes sur certains attributs.
Sur votre diagramme, vous auriez pu poser la contrainte que l’attribut « dateDeDebut » doit être une date antérieure à « dateDeFin ». Eh oui, cela paraît
logique, mais il faudra le spécifier à votre SGBDR car il ne le fera pas automatiquement !
Les notes servent aussi à préciser les domaines des attributs quand ceux-ci sont plus complexes que « Entier », « Date », « Texte », etc.
Par exemple : “Entier compris entre 1 000 et 2 000”.

LES DOUBLES ASSOCIATIONS
Deux classes peuvent être liées entre elles via deux (ou plus) associations.
Ce serait le cas lorsqu’une personne écrit un livre, et lorsqu’une autre personne traduit ce livre dans une autre langue :
Dans ce cas, il est nécessaire de donner un nom aux associations pour les différencier.
LES RÔLES DE CLASSES
Plutôt que de donner un nom aux associations, vous pouvez aussi caractériser une association par le rôle que tient chacune des deux classes. C’est le cas dans
cet exemple, où on peut remplacer le nom de l’association « conduit » par « conducteur » et « moyen de locomotion » :
C’est à vous de choisir si vous trouvez cette manière plus simple à comprendre. Si vous indiquez les rôles, pas besoin d’utiliser de verbes.
L’ASSOCIATION RÉFLEXIVE
Une classe peut être associée à elle-même !
Par exemple, une classe « Categorie » peut avoir des sous-catégories et des catégories parentes :
RÉSUMÉ
- Un lien de généralisation se modélise par l'héritage, qui permet de généraliser ou spécialiser un concept.
- L’héritage s’utilise parfois avec des classes abstraites, qui sont des classes non instanciables.
- Il existe d’autres types d’associations, comme l’agrégation et l’association ternaire.
- On précise tout type de commentaire ou de contrainte grâce aux notes.
- Deux classes peuvent être liées par plusieurs associations ayant toutes un nom ou un rôle différent. Une classe peut aussi être liée à elle-même par une
association réflexive.
Utilisez les outils de modélisation favorisant la collaboration
DÉCOUVREZ L’INTÉRÊT D’UN OUTIL DE MODÉLISATION
Il existe beaucoup de logiciels permettant de réaliser un diagramme de classes UML.

Globalement, ils se regroupent en deux catégories :
- Les outils graphiques, qui ne sont pas réservés à l’UML, mais qui permettent de créer facilement tous types de diagrammes.
- Les ateliers de génie logiciel (AGL) : ce sont des environnements de conception, souvent très puissants. Contrairement aux outils graphiques (qui ne font
que produire un dessin), les AGL « comprennent » la modélisation UML et ils sont capables d’interpréter votre modélisation afin de vous faciliter la tâche :
vérification du modèle, génération du code informatique découlant du diagramme de classes, etc). Ils sont cependant plus difficiles à prendre en main.
Parmi les outils graphiques les plus connus, on trouve LibreOffice Draw, diagrams.net (anciennement draw.io), LucidChart, etc.
En ce qui concerne les AGL, l’un des plus connus s’appelle ArgoUML. Vous pouvez tester également Papyrus, qui est un environnement de modélisation
performant fonctionnant sous Windows, MacOS et Linux. Il est gratuit, open source et développé par la fondation Eclipse.
À VOUS DE JOUER
Ici, le but n’est pas de générer du code informatique à partir du diagramme UML : nous souhaitons juste nous limiter à la partie graphique. Pas besoin non plus
d’options sophistiquées, comme celles qui permettent de vérifier si notre diagramme respecte bien les standards UML. Je vous conseille de réserver cela pour
des gros projets de développement informatique (si vous devez développer un programme dans un langage orienté objet).
Un outil graphique nous suffira amplement.
Je vous propose donc d’utiliser diagrams.net (anciennement draw.io).
Il est gratuit, et ne nécessite pas d’installation : c’est une application web, qui s’utilise depuis votre navigateur (Firefox, Chrome, Safari, Edge, etc.), et ne
nécessite même pas la création d’un compte !
De plus, il est très intuitif, très connu, et souvent utilisé pour créer tous types de diagrammes (pas seulement UML). Il permet également la collaboration grâce
à l’enregistrement des diagrammes dans un cloud (type Google Drive, par exemple).
À VOUS DE JOUER
Pour l’utiliser, c’est très simple :

- Rendez-vous sur la page de diagrams.net.
- Cliquez sur « Start ».
- Vous devrez ensuite choisir où enregistrer votre fichier.
- Vous êtes prêt à dessiner votre diagramme !
Pour rappel, voici la dernière version de notre diagramme UML, que je vous invite à reproduire :
À VOUS DE JOUER
Pour créer le diagramme que vous avez élaboré tout au long de cette partie, suivez les instructions de ces vidéos.
Dans cette première vidéo, je vais vous présenter l’outil Diagrams et nous allons créer les différentes classes.
https://player.vimeo.com/video/635154998
À VOUS DE JOUER
Nos classes ajoutées, voyons dans cette vidéo comment ajouter les relations entre les classes.
https://player.vimeo.com/video/635154705
EN RÉSUMÉ
Dans ce chapitre vous avez appris :
- À distinguer deux types d'outil de modélisation : les outils graphiques et les atelier de génie logiciel (AGL)
- À utiliser l'outil graphique Diagrams
Identifiez les éléments clés du modèle relationnel
IDENTIFIEZ LES ÉLÉMENTS CLÉS DU MODÈLE RELATIONNEL
Rappelez-vous les trois étapes de la modélisation d’une BDD :
- Le modèle conceptuel (MCD).

- Le modèle logique (MLD).
- 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.
REPRÉSENTEZ VOTRE TABLE ET VOS ATTRIBUTS
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, longitude pour la table lieu;

- titre pour la table oeuvre;
- 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.
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 :
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.
- 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
Déterminez vos clés primaires
IDENTIFIEZ LES CLÉS PRIMAIRES
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.
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 exempl eoeuvre, il ne doit pas y avoir deux lignes
décrivant une même œuvre.
Ainsi, œuvre contiendra exactement autant de lignes qu’il y a d'œuvres dont les lieux de tournage 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 identiques (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 :

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 distribuent le courrier. Imaginez une table qui répertorie des logements, possédant ces colonnes :
- Type de logement (maison, appartement, etc.).

- Superficie.
- N° de logement (ex. : appartement numéro 203).
- N° de voie (ex. : 5).
- Complément (ex. : 5 bis).
- Intitulé de la voie (ex. : rue de la République).
- Commune (ex. : Passillac-les-Flots).
- Code postal.
- 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 attributs intitulé de la voie, code postal et commune (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é. Cependant, 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. Superficie ne 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’attribut n° de logement n’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 table Logement, on définit implicitement que deux lignes de cette table ne peuvent pas avoir des
valeurs identiques pour ces attributs. 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 superstitieux, 93124 Passillac-les-Flots » ont toutes les deux les mêmes valeurs pour (code_postal, commune), soit 93124 et
Passillac-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 minimum permettant d’identifier de manière unique une ligne.
C’EST À VOUS !
Ç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 :
Tables « societe_de_production » et « realisateur_ice »
Pour les tables « societe_de_production » et « realisateur_ice », il n’y a pas beaucoup de choix : nous prendrons l’attribut nom pour 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 que nom est une bonne clé primaire pour ces 2 tables.
C’EST À VOUS !
Table « lieu »
Pour la table « lieu », c’est moins évident. Il pourrait y avoir deux clé primaires possibles :
- Le groupe (localisation_de_la_scene, code_postal).

- Le groupe (latitude, longitude).
Pour la première solution, il faut supposer que « localisation_de_la_scene » contienne bien au moins le nom de la rue (de la voie) ainsi que la commune. Dans
ce cas, la contrainte d’unicité est respecté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’attribut « 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.
C’EST À VOUS !
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 pour « lieu ». Plus formellement, on dit que les différentes options sont des clés candidates,
et que l’option finalement retenue est la clé primaire. Pour la table « lieu », nous choisirons arbitrairement le groupe (localisation_de_la_scene, code_postal)
comme clé primaire.
Tables œuvre et tournage
TABLES ŒUVRE ET TOURNAGE
Pour les tables « œuvre » et « tournage », 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 cela : « 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 « œuvre » ne 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
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 inscrits 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 ».
Créez des clés primaires artificielles
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 signification dans le domaine que l'on modélise, mais sa seule fonction
est d'identifier de maniè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 artificielles 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 :
Si vous le transformez pour le faire coller à votre modèle relationnel (donc avec deux tables œuvre et societe_de_production, avec une clé étrangère
societe_prod) en y ajoutant des clés artificielles, vous pourriez être tenté de simplement découper le fichier en deux :
Or ici, il y a 2 lignes de « societe_de_production » qui 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) de « societe_de_production » et
vérifier que (nom) ne contient pas de doublons. Si vous faites cela, vous arriverez à cette solution correcte :
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’unicité (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 production 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é primaire artificielle.
- Dans le MLD, l'usage de clé primaire artificielle est à réserver pour les cas particuliers, et il faut prendre certaines précautions.
Créez du lien entre vos tables avec les clés étrangères
Créez du lien entre vos tables avec les clés étrangères
CRÉEZ DU LIEN ENTRE VOS TABLES AVEC LES CLÉS ÉTRANGÈRES
- Dans ce chapitre, vous verrez comment modéliser les associations que vous avez déterminées dans le diagramme UML. C’est-à-dire comment associer une
ligne d’une table (ex. :oeuvre) à une ligne d’une autre table (ex. :societe_de_production).
- Lorsque vous avez dessiné votre diagramme UML, vous aviez défini les associations entre classes. Par exemple : une œuvre est produite par une (et une
seule) société de production.
- C’est un bon début. Mais maintenant, il faut être plus précis : il faut savoir quel film est produit par quelle société. Autrement dit, il faut relier chaque ligne
de la table œuvre avec les lignes de societe_de_production.
Découvrez l’utilité des clés étrangères
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, livre et personne :
Les valeurs présentes dans la colonne « auteur_ice » doivent obligatoirement avoir une correspondance dans la colonne « id », sinon les données sont
incohérentes. La plupart des SGBDR n’accepteront pas que vous introduisiez un livre dont l’auteur indiqué dans la colonne « auteur_ice » n’existe pas dans la
table « personne ». 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 « Foreign Key ». Graphiquement, on représente une clé étrangère par un
trait en pointillés entre les deux tables, comme ceci :
Ici, la clé étrangère n’est composée que d’un attribut (auteur_ice) car la clé primaire de personne ne contient qu’un attribut (id). Mais si la clé primaire
contient deux attributs, comme pour votre table « lieu », alors il faudrait une clé étrangère à deux attributs, que l’on pourrait appeler par exemple « loc_scene »
et « code_postal » :
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ée « null ». Cette valeur est équivalente à une case vide dans un tableau,
lorsqu'une information est manquante ou inexistante.
Par exemple, si une table « Personne » contient les attributs « date_naissance » et « date_deces », alors on pourrait contraindre l’attribut « date_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 valeur « null » est différente de la valeur 0, ou de la chaîne de caractères vide "". Contrairement à 0 ou à "", null indique 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 CARDINALITÉ 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 entre Œuvre et SocieteDeProduction. Elle est de type un-à-plusieurs, car du côté de SocieteDeProduction, la multiplicité
est 1. Cela signifie qu’une œuvre a forcément une et une seule société de production.
Cette association se traduit par une clé étrangère dans « œuvre ». Cette clé étrangère contient une seule colonne : « societe_prod », et elle référence la clé
primaire « nom » 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 colonne
« societe_prod »:
Or ici, la cardinalité minimale est de 1, ce qui signifie qu’il faut absolument quesociete_prod soit remplie pour toutes les lignes, et qu’il ne peut donc pas y
avoir de valeurs nulles.
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é primaire 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.
Transformez les associations de votre diagramme de classes UML
TRANSFORMEZ LES ASSOCIATIONS DE VOTRE DIAGRAMME DE CLASSES UML
- 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 relationnel.
- 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 traduction » 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 composition pour le moment, pour nous concentrer sur l’aspect un-à-plusieurs :
Cette illustration est un diagramme UML, pas un modèle relationnel.

L’ASSOCIATION UN-À-PLUSIEURS
Comme une société de production produit PLUSIEURS oeuvres, il faut ajouter une clé étrangère dans œuvre qui référence la clé primaire de
societe_de_production:
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’association oeuvre - societe_de_production est une composition, elle respecte la règle citée ci-dessus, mais elle a une particularité en plus que je vous
explique un peu plus bas.
L’ASSOCIATION UN-À-UN
Pour une association un-à-un entre une table A et une table B, on utilise aussi une clé étrangère. La clé étrangère est placée dans A et elle référence la clé
primaire de B.
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 table A et une table B, on utilise aussi une clé étrangère. La clé étrangère est placée dans A et elle référence la clé
primaire de B.
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é « plusieurs », 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ère societe_prod dans oeuvre , qui référence societe_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_prod est à 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.
TRANSFORMEZ VOS COMPOSITIONS
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 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 entre oeuvre et lieu est 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 :
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 !

CLASSE D’ASSOCIATION SUR UNE RELATION PLUSIEURS-À-PLUSIEURS
Voici donc le résultat final :
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 suffisaient 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 effet, on ne peut pas avoir 2 lignes de tournage relatives au
même film, au même endroit, et commenç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'association sont ajoutés à la table qui est du côté « 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.
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.
Transformez 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. Chacune 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 d eoeuvre 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 vers oeuvre, et à la fois clé primaire de chaque table fille :
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
inté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 attribut 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:
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 valeurs 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):
Cette méthode est adaptée lorsque la classe mère est abstraite, car l’absence de table correspondant à 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 relationnel, je vous laisse traduire entièrement votre diagramme UML
en modèle relationnel !
RÉPONSE
Voici la réponse :
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.
Améliorez votre modélisation grâce aux formes normales
AMÉLIOREZ VOTRE MODÉLISATION GRÂCE AUX FORMES NORMALES
Il y a toujours plusieurs façons de modéliser des données : certaines sont meilleures que d’autres. L’un des principaux critères est la présence ou non de
redondance dans la modèle. Pour nous aider à différencier la qualité de deux modèles donnés, des critères ont été créés, appelés formes normales.
Jusqu’à maintenant, nous avons souvent parlé de redondance, mais sans réellement formaliser de règle. Les formes normales vont combler ce manque.
APPRÉHENDEZ LA NOTION DE DÉPENDANCE
Réfléchissons un peu plus sur la question de la redondance, en nous basant sur votre fichier CSV :
Ici, vous avez par exemple une redondance sur le type d'œuvre. L’information selon laquelle Fleabag des studios Banijay est une série TV est présente plusieurs
fois. Pourquoi ? Parce que le type d'œuvre ne dépend que de l'œuvre. Or dans le fichier, il y a beaucoup de lignes qui concernent une même œuvre :
l’information est donc dupliquée.
J’ai employé ici le terme « ne dépend que de... ». Vous allez voir : tout est une question de dépendance d’attributs les uns envers les autres.
Quand vous dites « le type d’oeuvre ne dépend que de l’oeuvre », cela signifie que dans le fichier, si vous voyez « Fleabag des studios Banijay », alors le type
sera forcément « Série TV ».
Seulement, qu’est-ce qui permet d'identifier une œuvre dans votre fichier ? On en a déjà parlé : on identifie une œuvre par son titre et sa société de production,
soit (titre, societe_prod)
On dit donc que type_de_tournage dépend fonctionnellement du groupe d’attributs (titre, societe_prod) . Cela s’appelle une dépendance fonctionnelle. Elle se
note avec une flèche :
(titre, societe_prod) -> type_de_tournage
Seulement voilà : dans votre fichier, le groupe(titre, societe_prod) n’est pas unique : plusieurs lignes correspondent à une même œuvre. S’il y a plusieurs fois la
même œuvre, alors il y aura, à cause de la dépendance fonctionnelle, plusieurs lignes qui indiquent de quel type est une œuvre donnée. Et il y aura donc de la
redondance.
Conclusion : pour éviter la redondance, il faudrait que (titre, societe_prod) soit unique. Donc que ce groupe d’attributs soit une clé primaire (ou tout au moins
une clé candidate). Voici donc ce que vous pouvez en conclure :
Pour éviter (une bonne partie de) la redondance dans une table, il faut que chaque attribut (qui n’appartient pas à la clé primaire) ne dépende que de la clé
primaire de la table.
Petit complément : si un attribut dépend d’une partie de la clé primaire, il y a tout de même risque de redondance. Imaginons une table dont la clé primaire
serait(titre, societe_prod), et un attributadresse_societe_prod donnant l’adresse postale de la société de production.
adresse_societe_prod dépend uniquement desociété_prod . Comme societe_prod n’est pas unique (car ce n’est qu’une partie de la clé primaire), alors il y a
quand même risque de redondance :
Titre [PK] Société de production [PK] Adresse société prod
Rocky bat le boa Pathé-en-croûte productions 361 rue de la Boucherie,

87000 Limoges
Fast and Curious Pathé-en-croûte productions 361 rue de la Boucherie,

87000 Limoges
Vous pouvez donc compléter la phrase précédente par :
De plus, un attribut doit dépendre de l'ensemble de la clé primaire.

SACHEZ DÉTERMINER UNE DÉPENDANCE
Mais au fait, comment être sûr qu’un attribut A dépend d’un groupe d’attributs G ?
Imaginez que vous connaissiez parfaitement les données que vous modélisez. Posez-vous cette question : en ne connaissant que G, puis-je déterminer de
manière certaine A, sans ambiguïté, et sans avoir besoin d’autre information ?
Par exemple :
Pouvez-vous déterminer le type de tournage (Téléfilm, Série TV, etc.) d’une œuvre en ne connaissant que sa société de production ? La réponse est non, car une
société de production peut avoir produit plusieurs œuvres de types différents. Il y a donc une ambiguïté, et pour la résoudre il vous faut une information en
plus : le titre de l’œuvre. Avec le titre et la société de production, vous pouvez déterminer le type de tournage, si vous connaissez sur le bout des doigts vos
données. On peut donc dire que :
- type_de_tournage ne dépend pas uniquement de societe_prod
- type_de_tournage dépend de (titre, societe_prod)
Oui, mais si je connais le titre, la société de production et le lieu de tournage d’un tournage donné, je peux aussi déterminer type_de_tournage . Peut-on dire
que type_de_tournage dépend de (titre, societe_prod, localisation_de_la_scene) ?
Oui, mais ce n’est pas très intéressant, car (titre, societe_prod, localisation_de_la_scene) n’est pas minimal, c’est-à-dire que l’on peut enlever l’un des
attributs ( localisation_de_la_scene ) sans casser le lien de dépendance. On dira alors que :
type_de_tournage dépend d’une partie de (titre, societe_prod, localisation_de_la_scene) .

DÉDUISEZ-EN LES TROIS PREMIÈRES FORMES NORMALES
Le raisonnement que vous venez de mener a été formalisé sous forme de trois règles, appelées formes normales. Il en existe plus que trois, mais on considère en
général qu’une modélisation qui respecte ces trois premières formes évite déjà une très grande partie de la redondance qui peut se cacher dans les données.
La 1NF
La première forme normale est un prérequis aux deux suivantes. Comme on parle de clés primaires, il faut que :
Chaque table ait une clé primaire ;
Chaque attribut ne contienne qu’une seule information à la fois (sinon c’est rapidement le bazar dès qu’il s’agit de contrôler la redondance d’information ou
l’unicité d’un attribut).
Autrement dit, chaque attribut doit être atomique, c’est-à-dire qu’il ne doit être ni multivalué ni composite
Un attribut composite peut être décomposé en plusieurs attributs atomiques. Voici un exemple avec un attribut adresse :
attribut composite attributs

atomiques
•adresse => •numero_voie

•bis_ter
•nom_voie
•commune
•code_postal
•pays
DÉDUISEZ-EN LES TROIS PREMIÈRES FORMES NORMALES
Un attribut multivalué peut être transformé en une nouvelle table liée à la table d’origine par une association un-à-plusieurs ou plusieurs-à-plusieurs selon le
cas.
Regardons l’exemple ci-dessous. ;)
Dans notre fichier, la colonne realisateur_ice est multivalué, car une seule cellule contient parfois deux noms de réalisateurs.
Par exemple la ligne 2019-1450 : Lise Akoka et Romane Gueret.
Intuitivement, vous avez bien pris en compte ceci dans votre modèle relationnel, car vous avez transformé cet attribut multivalué en une nouvelle table
realisateur_ice , contenant un attribut nom qui est atomique (et c’est bien !). Cette nouvelle table est liée avec la table oeuvrepar une association plusieurs-à-
plusieurs :
Une table est en 1NF si elle possède une clé primaire et si tous ses attributs
sont atomiques.
LA 2NF
La deuxième forme normale découle de la réflexion que vous avez menée plus haut :
Une table est en 2NF si :
- Elle est en 1NF

- Et si tout attribut (n’appartenant pas à une clé candidate) ne dépend pas d'une partie seulement d’une clé candidate.
Rappel : une clé candidate est un groupe d’attributs éligible à être une clé primaire. Une table peut avoir plusieurs clés candidates, mais une seule d’entre elles
doit être retenue comme clé primaire.
LA 3NF
Une relation est en 3NF si :
Elle est en 2NF
Et si tout attribut (n'appartenant pas à une clé candidate) ne dépend pas d'un autre attribut n'appartenant pas à une clé candidate.
APPRENEZ À RESPECTER LES TROIS FORMES NORMALES
Pour respecter la 1 NF, il vous faut :

Choisir une clé primaire pour chaque table ;
Transformer les attributs multivalués en une nouvelle table liée avec la table d’origine par une association un-à-plusieurs ou plusieurs-à-plusieurs ;
Décomposer les attributs composites en des attributs atomiques (exemple : décomposer « Mme Jeanne Herry » en trois attributs civilité, nom, prénom).
Pour les 2NF et 3NF, il faut étudier les dépendances entre les attributs.
Pour vous aider, il y a une règle pour « séparer » les attributs d’une table pour réduire la redondance ET ne pas perdre d’information. La voici :
Dans une table T1, si :
- Un attribut A dépend uniquement d'un groupe d'attributs G
- Et que ce groupe d'attributs n'est pas une clé candidate ;
alors il faut créer une nouvelle table T2 qui contiendra les attributs A et G.
G deviendra la clé primaire de cette nouvelle table. Dans la table T1, on pourra supprimer A mais garder G, et G sera défini comme clé étrangère référençant
T2.
Il faut cependant s'assurer que G soit minimal (c'est-à-dire que l'on ne puisse pas enlever d'attribut au groupe G sans casser la dépendance entre A et G).
Aussi, si un autre attribut B dépend également uniquement de G, alors il faut aussi le déplacer dans la nouvelle table T2 !
Pour mieux saisir ce concept, je vous conseille vivement cette courte vidéo sur Openclassrooms, qui est bien plus explicite que ce qu’il n’est possible
d’exprimer avec du texte. ;)
Par exemple, dans votre fichier CSV, vous avez vu que type_de_tournage dépend de ( titre, societe_prod). De plus, ce groupe est minimal. On peut donc
appliquer la règle ci-dessus avec :
- T1 = votre fichier CSV
- A = type_de_tournage
- G = (titre, societe_prod)
En suivant cette règle,
- On crée T2 dont la clé primaire est(titre, societe_prod), et qui contient comme attribut type_de_tournage .
- On supprime la colonne type_de_tournage du gros fichier CSV.
- On indique que(titre, societe_prod) est une clé étrangère qui référence T2.
Et là… surprise ! Vous vous rendez compte que T2 correspond tout à fait à la table oeuvre que vous avez définie précédemment !
titre [PK] societe_prod [PK] type_de_tournage
Fleabag Banijay Studios France Série TV
Munch saison 3 JLAPRODUCTIONS Série TV
Madame Claude Les Compagnons du Cinéma Long métrage

SÉPAREZ VOTRE FICHIER
Ce que je vous propose, c’est de considérer que votre fichier CSV est une table, puis de la séparer en plusieurs tables en analysant les dépendances entre les
attributs. Il faudra utiliser la règle citée ci-dessus.
Mais avant de commencer, il faut déterminer la clé primaire de votre gros fichier.
Facile ! Chaque ligne est identifiée par la colonne identifiant_du_lieu, c’est donc la clé primaire !
C’est bon signe, cela signifie que, sans le savoir, vous étiez sur la bonne voie quand vous avez déterminé votre modèle relationnel !
La question est maintenant de savoir : aurions-nous abouti au même modèle relationnel si nous avions suivi cette procédure jusqu’au bout ? C’est-à-dire en
séparant successivement le gros fichier CSV en différentes tables ?
Eh bien… vous allez vous-même réfléchir à la réponse dans quelques secondes ! De plus, c’est cette procédure que vous allez appliquer au chapitre suivant,
quand vous allez séparer votre fichier CSV en différentes tables.
Quand vous êtes face à une table, demandez-vous TOUJOURS quelle peut en être la clé primaire, en testant la contrainte d’unicité.
En effet, c’est la clé primaire qui vous renseigne sur la nature de chacune des lignes de la table.
Instinctivement, vous auriez pu vous dire « Chaque ligne est identifiée par la colonne identifiant_du_lieu », chaque ligne est donc un lieu. Or c’est faux : il y a
parfois plusieurs lignes qui correspondent à un même lieu, par exemple les lignes 2016-1817et 2016-1622. Il y a donc moins de lieux que de lignes dans votre
fichier.
C’est dangereux, car si on vous avait demandé de compter à combien de lieux différents ont été tournées des œuvres, vous auriez été tenté de compter les lignes
de votre fichier (8 919 dans mon fichier), alors qu’il y a des adresses en double (il n’y a qu’environ 5 000 lieux différents dans mon fichier).
La colonne identifiant_du_lieu n’est donc pas un identifiant du lieu, mais plutôt un identifiant de sessions de tournage d’une œuvre donnée, sur un lieu donné,
sur une période donnée. Autrement dit, c’est l’identifiant d’une association entre :
Un lieu (identifié parlocalisation_de_la_sceneet code_postal)
Et une période de tournage (identifiée pardate_de_debut) d’une œuvre (identifiée par titre etsociete_prod).
Vous pouvez donc déduire que l’une des clés primaires possibles est (localisation_de_la_scene, code_postal, date_de_debut, titre, societe_prod) .
À partir de cette information, tout attribut qui ne dépendra pas de cette clé primaire, ou qui n’en dépendra que d’une partie, pourra être déplacé dans une
nouvelle table !
À VOUS DE JOUER !
Vous avez toutes les clés en main pour déduire un modèle relationnel à partir des colonnes de votre fichier !
Attention ! Ne lisez pas tout de suite ce qui suit. :)
Faites d’abord l’exercice et continuez votre lecture pour avoir la réponse. ;-)
En guise de réponse, je vous donne les dépendances entre les attributs :
( titre, societe_prod) -> type_de_tournage .
( date_de_debut ) -> annee_du_tournage . Cet attribut est inutile car dérivé.
( localisation_de_la_scene, code_postal) -> (latitude, longitude) . C’est certes discutable, mais nous considérerons ici qu’il n’y a qu’un seul couple lat/long
pour une adresse donnée.
( titre, societe_prod , date_de_debut,date_de_fin ) → realisateur_ice.
Sur les points 1 à 3, tout correspondait à ce que vous aviez trouvé avant ce chapitre. Mais pour le point 4, c’est différent : en effet, on s’aperçoit que le
réalisateur d’une œuvre ne dépend pas que de l’oeuvre en question, mais aussi de la période de tournage.
À VOUS DE JOUER !
En effet, il arrive que des réalisateurs se succèdent au cours de la réalisation d’une œuvre. C’est souvent le cas pour les séries, dans lesquelles chaque épisode
est parfois réalisé par des personnes différentes.
Par exemple pour la série « Munch », réalisé par Thierry BINISTI en juillet 2019 et par Laurent TUEL en mai 2019 .
Si vous regardez le modèle relationnel que vous aviez jusqu’au chapitre précédent, vous n’aviez pas moyen de savoir quel réalisateur dirigeait le tournage
d’une période donnée. En d’autres termes, même si vous pouviez connaître les réalisateurs de « Munch », vous n’aviez plus moyen de savoir que les tournages
de mai 2019 ont été dirigés par Laurent TUEL.
Pour résoudre cela, il faut appliquer la règle donnée ci-dessus et créer une table dont la clé primaire est ( titre, societe_prod,date_de_debut , date_de_fin), et
qui contient un attribut realisateur_ice . Cette table donne des périodes de tournage d’une œuvre donnée (mais sans indication de lieu). On
l’appeleraperiode_de_tournage.
De plus, la colonne « Réalisateur/Réalisatrice » de votre fichier est multivalué, car certaines lignes contiennent des couples de réalisateurs (voir la ligne2019-
407). Comme nous l’avions dit plus haut dans ce chapitre, vous pouvez donc le décomposer en une nouvelle table appelée realisateur_ice, qui est liée
àperiode_de_tournage par une association plusieurs-à-plusieurs, comme ceci :
À VOUS DE JOUER !
À la fin, quand vous aurez séparé toutes les tables, il ne vous restera plus que :
- id_lieu
- Une clé étrangère vers lieu, composée de deux colonnes ;
- Une clé étrangère vers periode_de_tournage, composée de quatre colonnes.
Vous pouvez supprimer id_lieu: il ne sert plus à rien. Cette table a tout à fait la forme d’une table d’association entre lieu et periode_de_tournage: et ça tombe
bien, car une table d’association signifie une association plusieurs-à-plusieurs. Or :
- Un tournage peut se réaliser à la même période sur deux lieux différents (avec deux équipes différentes ou avec une équipe qui se déplace dans la même
journée) ;
- Un lieu peut accueillir différents tournages sur une même période !
Appelons donc cette tableassoc_periode_lieu.

À VOUS DE JOUER !
Youpi ! Vous avez maintenant votre modèle relationnel définitif, qui est en 3NF !
À VOUS DE JOUER !
Lorsque vous modifiez votre modèle relationnel pour le mettre en 3NF, il faut toujours actualiser l’UML en conséquence :
EN RÉSUMÉ
- Certains attributs peuvent dépendre d'autres attributs.

- Pour éviter (une bonne partie) de la redondance dans une table, il faut que chaque attribut (qui n’appartient pas à la clé primaire) ne dépende que de la clé
primaire de la table. De plus, un attribut doit dépendre de l'ensemble de la clé primaire.
- Une table est en 1NF si elle possède une clé primaire et si tous ses attributs sont atomiques.
- Une table est en 2NF si elle est en 1NF et si tout attribut (n’appartenant pas à une clé candidate) ne dépend pas d'une partie seulement d’une clé candidate.
- Une relation est en 3NF si elle est en 2NF et si tout attribut (n'appartenant pas à une clé candidate) ne dépend pas d'un autre attribut n'appartenant pas à une
clé candidate.
- Il y a une règle pour « séparer » les attributs d’une table pour réduire la redondance ET ne pas perdre d’information.
- Après la normalisation d'une modélisation relationnelle, il faut penser à actualiser l'UML en conséquence.
Merci !

(YUNIT) Base de Donnée

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

(YUNIT) Base de Donnée

Transféré par

Droits d'auteur :

Formats disponibles

Modéliser vos bases de

4 Modèle conceptuel vers un modèle relationnel

Vous découvrirez comment traduire votre diagramme UML en un modèle relationnel

Ce cours ne nécessite pas de prérequis. Vous n'apprendrez pas de code

La modélisation relationnelle est massivement utilisée dans le monde

À la fin de ce cours, vous serez capable de :

- Analyser vos données pour choisir le type de base de données approprié.

UNE BASE DE DONNÉES, À QUOI ÇA SERT ?

MAIS UNE DONNÉE, C’EST QUOI ?

Eh bien, c’est très variable ! Voici quelques exemples :

C’EST QUOI LE SGBD ?

- de l’optimisation d’accès aux données (en termes de temps d’accès) ;

SGDB TRÈS CONNU : SQLITE

APPRÉHENDEZ LA STRUCTURE DE VOS DONNÉES

Ce que l’on représente, ce sont des lieux de tournage. On met donc :

- Pour chaque ligne, les lieux de tournage.

AVEZ-VOUS DÉJÀ ENTENDU PARLER DU BIG DATA ?

On parle souvent des trois V qui caractérisent le big data :

REPRÉSENTEZ VOS DONNÉES EN FONCTION DE LEUR STRUCTURE

Beaucoup de caractéristiques possibles, c’est beaucoup de colonnes dans notre tableau.

REPRÉSENTEZ VOS DONNÉES EN FONCTION DE LEUR STRUCTURE

MAIS ALORS, COMMENT REPRÉSENTE-T-ON DES DONNÉES NON STRUCTURÉES ?

Il y a une infinité de représentations possibles !

ET POUR LES DONNÉES STRUCTURÉES, QUEL FORMAT DE FICHIER FAUT-IL ?

CHOISISSEZ VOTRE SGBD EN FONCTION DE LA STRUCTURE DE VOS DONNÉES

Les plus célèbres SGBDR sont :

ET POUR LES DONNÉES NON STRUCTURÉES ?

Parmi les SGBD NoSQL, on trouve :

- Elasticsearch : très performant pour stocker du texte et y effectuer des recherches.

BASES DE DONNÉES RELATIONNELLES

1. CONSTRUISEZ VOTRE MODÈLE CONCEPTUEL DE DONNÉES (MCD)

- Cherchez les concepts présents dans vos données.

DESSINER LE MODÈLE CONCEPTUEL

- Le modèle Entité-Associations (E-A), qui fait partie de la méthode MERISE ;

Par exemple, un modèle E-A ressemble à ceci :

DIAGRAMME DE CLASSES UML

Par exemple, un diagramme de classe ressemble à ceci :

CONCEVEZ VOTRE MODÈLE LOGIQUE DE DONNÉES (MLD)

En modélisation relationnelle, un tableau s’appelle une table.

EXEMPLE DE MODÈLE RELATIONNEL

DÉTERMINEZ VOTRE MODÈLE PHYSIQUE DE DONNÉES (MPD)

Essayez de deviner quel type de logiciel peut utiliser cette BDD ?

Tableau uniquement valable pour des bases de données structurées :

Niveau de modélisation Abréviation Caractéristiques Mode de représentation

On appelle ceci une redondance d’information.

La redondance, c’est problématique, pour différentes raisons.

ALORS, QUELLE EST LA SOLUTION ?

Il suffit de créer un nouveau tableau contenant les réalisateurs !

Avec ce nouveau tableau, les réalisateurs pourront exister indépendamment des

Mais il y a un autre avantage important : dans ce tableau, un seul réalisateur n’est

Aussi, si l’information n’est présente qu’à un seul endroit, le stockage

Cette méthode est propre au modèle relationnel (le MLD).

Habituez-vous à utiliser dès maintenant :

Voici une réponse possible :

Une méthode est un enchaînement d'opérations destiné :

Soit à modifier les attributs ;

Soit à calculer un résultat à partir des attributs ;

Soit les deux en même temps.

DIALOGUEZ GRÂCE AU DIAGRAMME DE CLASSES

Vous avez déjà entendu parler de la programmation « orientée objet » ?

DISTINGUEZ LE DIAGRAMME DE CLASSE DES AUTRES DIAGRAMMES UML

Vocabulaire Signification Exemple(s) NomDeLaClasse

Attribut composite Attribut composé d’un nombre Adresse (numéro, voie,