4.2 SCHÉMA DE LA BASE DE DONNÉES La création d’un schéma MySQL est simple une fois que l’on a déterminé les entités et les associations.. Étant donné le schéma E/A Films, on obtient les
Trang 1Réponse : comme une association, car on connaỵt alors non seulement le nom, mais aussi toutes les autres propriétés (prénom, année de naissance, ) De plus, ces informations peuvent être associées à beaucoup d’autres films En utilisant une association, on permet à tous ces films de référencer le metteur en scène, en évitant
la répétition de la même information à plusieurs endroits
« Est-il indispensable de gérer une entité Horaire ? »
Réponse : pas forcément ! D’un cơté, cela permet de normaliser les horaires Plusieurs séances peuvent alors faire référence au même horaire, avec les avantages
en termes de gain de place et de cohérence cités précédemment En revanche, on peut considérer que cela alourdit le schéma inutilement On peut alors envisager de
déplacer les attributs de Horaire (soit heure d´ ebut et heure fin) dans Séance.
« Pourquoi ne pas mettre le nom du pays comme attribut de Film ? »
C’est envisageable Mais l’utilité d’associer un film au pays qui l’a produit est certainement de pouvoir faire des classements par la suite Il s’agit d’une situation
typique ó on utilise une codification pour ranger des données par catégorie Si on
met le nom du pays comme attribut, l’utilisateur peut saisir librement une chaỵne
de caractères quelconque, et on se retrouve avec « U.S.A », «États Unis », « U.S », etc, pour désigner les États-Unis, ce qui empêche tout regroupement par la suite Le
fait de référencer une codification imposée, représentée dans Pays, force les valeurs
possibles, en les normalisant
4.2 SCHÉMA DE LA BASE DE DONNÉES
La création d’un schéma MySQL est simple une fois que l’on a déterminé les entités
et les associations En pratique, on transcrit le schéma E/A en un schéma relationnel comprenant toutes les tables de la base, en suivant quelques règles données dans ce
qui suit Nous prenons bien entendu comme exemple le schéma de la base Film, tel
qu’il est donné dans la figure 4.1, page 185
4.2.1 Transcription des entités
On passe donc d’un modèle disposant de deux structures (entités et associations) à
un modèle disposant d’une seule (tables) Logiquement, entités et associations seront toutes deux transformées en tables La subtilité réside dans la nécessité de préserver
les liens existants dans un schéma E/A et qui semblent manquer dans les schémas de
tables Dans ce dernier cas, on utilise un mécanisme de référence par valeur basé sur
les clés des tables.
La clé d’une table est le plus petit sous-ensemble des attributs qui permet d’identifier chaque ligne de manière unique Nous avons omis de spécifier la clé dans certaines tables des chapitres précédents, ce qui doit absolument être évité
Trang 2194 Chapitre 4 Création d’une base MySQL
quand on passe à une application sérieuse Une table doit toujours avoir une clé À
partir de maintenant, nous indiquons la clé en gras.
Chaque entité du schéma E/A devient une table de même nom dans la base de
données, avec les mêmes attributs que l’entité Étant donné le schéma E/A Films, on
obtient les tables suivantes :
• Film (id, titre, année, genre, résumé)
• Artiste (id, nom, prénom, année_naissance)
• Internaute (email, nom, prénom, mot_de_passe, année_naissance)
• Pays (code, nom, langue)
On a perdu pour l’instant tout lien entre les relations
4.2.2 Associations de un à plusieurs
On désigne par « associations de un à plusieurs » (que l’on abrège « associations 1
à n ») celles qui ont une cardinalité multiple d’un seul cơté Pour une association
A − • B, le passage à une représentation relationnelle suit les règles suivantes :
1 on crée les tables A et B correspondant aux entités ;
2 la clé de A devient aussi un attribut de B.
L’idée est qu’une ligne de B doit référencer une (et une seule) ligne de A Cette
référence peut se faire de manière unique et suffisante à l’aide de l’identifiant On
« exporte » donc la clé de A dans B, ó elle devient une clé étrangère Voici le schéma obtenu pour la base Films après application de cette règle Les clés étrangères sont en
italiques.
• Film (id, titre, année, genre, résumé, id_réalisateur, code_pays)
• Artiste (id, nom, prénom, année_naissance)
• Internaute (email, nom, prénom, mot_de_passe, année_naissance)
• Pays (code, nom, langue)
Il n’y a pas d’obligation à donner le même nom à la clé étrangère et la clé
principale (que nous appellerons clé primaire à partir de maintenant) L’attribut
id_realisateur correspond à l’attribut id d’Artiste, mais son nom est plus représentatif
de son rơle exact : donner, pour chaque ligne de la table Film, l’identifiant de l’artiste
qui a mis en scène le film
Les tables ci-dessous montrent un exemple de la représentation des associations
entre Film et Artiste d’une part, Film et Pays d’autre part (on a omis le résumé du film).
Si on ne peut avoir qu’un artiste dont l’id est 2 dans la table Artiste, en revanche rien
n’empêche cet artiste 2 de figurer plusieurs fois dans la colonne id_realisateur de la table Film On a donc bien l’équivalent de l’association un à plusieurs élaborée dans
le schéma E/A
Trang 3Tableau 4.5 — La tableFilm
id titre année genre id_realisateur code_pays
1 Alien 1979 Science Fiction 51 US
3 Psychose 1960 Suspense 52 US
5 Volte-face 1997 Action 54 US
Tableau 4.6 — La tableArtiste
id nom prénom année_naissance
51 Scott Ridley 1943
52 Hitchcock Alfred 1899
53 Kurosawa Akira 1910
56 Cameron James 1954
57 Tarkovski Andrei 1932
58 Pialat Maurice 1925
Tableau 4.7 — La tablePays
code nom langue
US Etats Unis anglais
FR France français
JP Japon japonais
4.2.3 Associations de plusieurs à plusieurs
On désigne par « associations de plusieurs à plusieurs » (que l’on abrège en
« associations n-m ») celles qui ont des cardinalités multiples des deux côtés
La transformation de ces associations est plus complexe que celle des associations
un à plusieurs, ce qui explique que le choix fait au moment de la conception
soit important Prenons l’exemple de l’association Joue entre un artiste et un film On ne peut pas associer l’identifiant d’un film à l’artiste, puisqu’il peut jouer dans plusieurs, et réciproquement on ne peut pas associer l’identifiant d’un acteur
à un film
En présence d’une association A • − • B, on doit donc créer une table spécifiquement
destinée à représenter l’association elle-même, selon les règles suivantes :
1 on crée les tables A et B pour chaque entité ;
2 on crée une table AB pour l’association ;
3 la clé de cette table est la paire constituée des clés des tables A et B ;
4 les attributs de l’association deviennent des attributs de AB.
Pour identifier une association, on utilise donc la combinaison des clés des deux entités Si on reprend la représentation sous forme de graphe, il s’agit en fait d’identifier le lien qui va d’une entité à une autre Ce lien est uniquement déterminé par ses points de départ et d’arrivée, et donc par les deux clés correspondantes
Trang 4196 Chapitre 4 Création d’une base MySQL
Voici le schéma obtenu après application de toutes les règles qui précèdent On
obtient deux nouvelles tables, Rôle et Notation, correspondant aux deux associations
n-m du schéma de la figure 4.1
• Film (id, titre, année, genre, résumé, id_réalisateur, code_pays)
• Artiste (id, nom, prénom, année_naissance)
• Internaute (email, nom, prénom, mot_de_passe, année_naissance)
• Pays (code, nom, langue)
• Rôle (titre, id_acteur, nom_rôle)
• Notation (titre, email, note)
Il peut arriver que la règle d’identification d’une association par les clés des deux entités soit trop contraignante quand on souhaite que deux entités puissent être liées plus d’une fois dans une association Si, par exemple, on voulait autoriser un internaute à noter un film plus d’une fois, en distinguant les différentes notations par
leur date, il faudrait, après avoir ajouté l’attribut date, identifier la table Notation
par le triplet (email, id_film, date) On obtiendrait le schéma suivant
• Notation (email, id_film, date, note)
Il ne s’agit que d’une généralisation de la règle pour les associations n-m Dans tous les cas, la clé est un sur-ensemble des clés des entités intervenantes
Les tables suivantes montrent un exemple de représentation de Rôle On peut
constater le mécanisme de référence unique obtenu grâce aux clés des relations Chaque rôle correspond à un unique acteur et à un unique film De plus, on ne peut pas trouver deux fois la même paire (titre,id_acteur) dans cette table, ce qui n’aurait pas de sens En revanche, un même acteur peut figurer plusieurs fois (mais pas associé au même film) Chaque film peut lui-aussi figurer plusieurs fois (mais pas associé au même acteur)
Tableau 4.8 — La tableFilm
id titre année genre id_realisateur code_pays
9 Impitoyable 1992 Western 100 USA
10 Ennemi d’état 1998 Action 102 USA
Tableau 4.9 — La tableArtiste
id nom prénom année_naissance
100 Eastwood Clint 1930
101 Hackman Gene 1930
102 Scott Tony 1930
103 Smith Will 1968
Tableau 4.10 — La tableRôle
id_film id_acteur rôle
9 100 William Munny
9 101 Little Bill
10 103 Robert Dean
On peut remarquer finalement que chaque partie de la clé de la table Rôle est
elle-même une clé étrangère qui fait référence à une ligne dans une autre table :
1 l’attribut id_film fait référence à une ligne de la table Film (un film) ;
2 l’attribut id_acteur fait référence à une ligne de la table Artiste (un acteur).
Trang 5Le même principe de référencement et d’identification des tables s’applique à la
table Notation dont un exemple est donné ci-dessous Il faut bien noter que, par
choix de conception, on a interdit qu’un internaute puisse noter plusieurs fois le même film, de même qu’un acteur ne peut pas jouer plusieurs fois dans un même film Ces contraintes ne constituent pas des limitations, mais des décisions prises
au moment de la conception sur ce qui est autorisé, et sur ce qui ne l’est pas Vous devez, pour vos propres bases de données, faire vos propres choix en connaissance
de cause
Tableau 4.11 — La tableFilm
id titre année genre id_realisateur code_pays
1 Alien 1979 Science Fiction 51 US
3 Psychose 1960 Suspense 52 US
5 Volte-face 1997 Action 54 US
Tableau 4.12 — La tableInternaute
email nom prénom année_naissance
doe@void.com Doe John 1945
fogg@verne.fr Fogg Phileas 1965
Tableau 4.13 — La tableNotation
id_film email note
1 fogg@verne.fr 4
5 fogg@verne.fr 3
1 doe@void.com 5
8 doe@void.com 2
7 fogg@verne.fr 5
Le processus de conception détaillé ci-dessus permet de décomposer toutes les informations d’une base de données en plusieurs tables, dont chacune stocke un des ensembles d’entités gérés par l’application Les liens sont définis par un mécanisme
de référencement basé sur les clés primaires et les clés étrangères Il est important de bien comprendre ce mécanisme pour maîtriser la construction de bases de données qui ne nécessiteront par de réorganisation – nécessairement douloureuse – par la suite
Il reste maintenant à créer cette base avec MySQL La création d’un schéma
comprend essentiellement deux parties : d’une part la description des tables et de leur contenu, d’autre part les contraintes qui portent sur les données de la base La
spécification des contraintes est souvent placée au second plan malgré sa grande importance Elle permet d’assurer, au niveau de la base des contrôles sur l’intégrité des donnés qui s’imposent à toutes les applications accédant à cette base