4.2 Passage d’un schéma E/A à un schéma relationnel
4.2.1 Règles générales
Nous allons considérer dans un premier temps que la clé est définie, pour chaque type d’entité E, par un identifiant abstrait, idE.
Règles de passage : entités
Rappel : le schéma d’une relation est constitué du nom de la relation, suivi de la liste des attributs. Alors, pour chaque entité du schéma E/A:
1. On crée une relation de même nom que l’entité.
2. Chaque propriété de l’entité, y compris l’identifiant, devient un attribut de la relation. 3. Les attributs de l’identifiant constituent la clé de la relation.
Exemple 4.1 À partir du schéma E/A Officiel des spectacles, à l’exception des entités concernant les ci-
némas, les salles et les horaires, on obtient les relations suivantes : – Film (idFilm, titre, année, genre, résumé)
– Artiste (idArtiste, nom, prénom, annéeNaissance) – Internaute (email, nom, prénom, région)
– Pays (code, nom, langue)
Règles de passage : associations de un à plusieurs
Soit une association de un à plusieurs1 entre et A . Le passage au modèle logique suit les règles suivantes :
1. On crée les relationsU = et
U
? correspondant respectivement aux entités etA . 2. L’identifiant deA devient un attribut de
U
= .
L’idée est qu’une occurence de d référence l’occurence deA qui lui est associée à l’aide d’une clé
étrangère. Cette référence se fait de manière unique et suffisante à l’aide de l’identifiant.
Exemple 4.2 Voici le schéma obtenu pour représenter l’association entre les types d’entité Film, Artiste
et Pays. Les clés étrangères sont en italiques.
– Film (idFilm, titre, année, genre, résumé, idArtiste, codePays) – Artiste (idArtiste, nom, prénom, annéeNaissance)
– Pays (code, nom, langue)
Le rôle précis tenu par l’artiste dans l’association disparaît. L’artiste dans Film a un rôle de metteur en scène, mais il pourrait tout aussi bien s’agir du décorateur ou de l’accessoiriste. Rien n’empêche cependant de donner un nom plus explicite à l’attribut. Il n’est pas du tout obligatoire en fait que les attributs consti- tuant une clé étrangères aient le même nom que ceux de le clé primaire auxquels ils se réfèrent. Voici le schéma de la table Film, dans lequel la clé étrangère pour le metteur en scène est nommée idMES.
Film (idFilm, titre, année, genre, résumé, idMES)
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). Noter que 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 idMES de la table Film. On a donc bien l’équivalent de l’association un à plusieurs élaborée dans le schéma E/A.
idFilm titre année genre idMES codePays
100 Alien 1979 Science Fiction 1 US
101 Vertigo 1958 Suspense 2 US
102 Psychose 1960 Suspense 2 US
103 Kagemusha 1980 Drame 3 JP
104 Volte-face 1997 Action 4 US
105 Van Gogh 1991 Drame 8 FR
106 Titanic 1997 Drame 6 US
107 Sacrifice 1986 Drame 7 FR
La table Film
idArtiste nom prénom annéeNaiss
1 Scott Ridley 1943 2 Hitchcock Alfred 1899 3 Kurosawa Akira 1910 4 Woo John 1946 6 Cameron James 1954 7 Tarkovski Andrei 1932 8 Pialat Maurice 1925 La table Artiste
code nom langue
US Etats Unis anglais
FR France français
JP Japon japonais
La table Pays
Règles de passage : associations avec type entité faible
Une entité faible est toujours identifiée par rapport à une autre entité. C’est le cas par exemple de l’association en Cinéma et Salle (voir chapitre 3). Cette association est de type un à plusieurs car l’entité faible (une salle) est liée à une seule autre entité (un cinéma) alors que, en revanche, un cinéma peut être lié à plusieurs salles.
Le passage à un schéma relationnel est donc identique à celui d’une association 1-; classique. On utilise un mécanisme de clé étrangère pour référencer l’entité forte dans l’entité faible. La seule nuance est que la clé étrangère est une partie de l’identifiant de l’entité faible.
Exemple 4.3 Voici le schéma obtenu pour représenter l’association entre les types d’entité Cinéma et
Salle. On note que l’identifiant d’une salle est constitué de l’identifiant du cinéma (ici on a considéré que
le nom du cinéma suffisiat à l’identifier), et d’un numéro complémentaire permettant de distinguer les salles au sein d’un même cinéma. La clé étrangère est donc une partie de la clé primaire.
– Cinéma (nomCinéma, numéro, rue, ville) – Salle (nomCinéma, no, capacité)
Règles de passage : associations binaires de plusieurs à plusieurs
Soit une association binaire n-m entre etA . 1. On crée les relationsU
= et
U
? correspondant respectivement aux entités etA . 2. On crée une relationU
=Fef? pour l’association. 3. La clé deU
= et la clé de
U
? deviennent des attributs de
U
=Fef? . 4. La clé de cette relation est la concaténation des clés des relationsU
= et
U
? . 5. Les propriétés de l’association deviennent des attributs deU
=Fe'? .
Exemple 4.4 Toujours à partir du schéma Officiel des spectacles, on obtient la table Rôle représentant
l’association entre les films et les acteurs.
– Film (idFilm, titre, année, genre, résumé, idMES, codePays) – Artiste (idArtiste, nom, prénom, annéeNaissance)
– Role (idFilm, idActeur, nomRôle)
De même, on obtient une table Notation pour représenter l’association entre un internaute et les films qu’il a notés.
– Film (idFilm, titre, année, genre, résumé, idMES, codePays) – Internaute (email, nom, prénom, région)
– Notation (email, idFilm, note)
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 (idFilm,idActeur) 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), ainsi qu’un même film (mais pas associé au même acteur).
idFilm titre année genre idMES codePays
20 Impitoyable 1992 Western 100 USA
21 Ennemi d’état 1998 Action 102 USA
idArtiste nom prénom annéeNaiss 100 Eastwood Clint 1930 101 Hackman Gene 1930 102 Scott Tony 1930 103 Smith Will 1968 La table Artiste
idFilm idActeur rôle
20 100 William Munny
20 101 Little Bill
21 101 Bril
21 103 Robert Dean
La table Rôle
On peut remarquer finalement que chaque partie de la clé de la table Rôle est elle-même une clé étran- gère qui fait référence à une ligne dans une autre table :
1. l’attributidFilmfait référence à une ligne de la table Film (un film) ; 2. l’attributidActeurfait référence à une ligne de la table Artiste (un acteur) ;
Le 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.
idFilm titre année genre idMES codePays
100 Alien 1979 Science Fiction 1 USA
101 Vertigo 1958 Suspense 2 USA
102 Psychose 1960 Suspense 2 USA
103 Kagemusha 1980 Drame 3 JP
104 Volte-face 1997 Action 4 USA
105 Van Gogh 1991 Drame 8 FR
106 Titanic 1997 Drame 6 USA
107 Sacrifice 1986 Drame 7 FR
La table Film
email nom prénom annéeNaiss
doe@void.com Doe John 1945
fogg@verne.fr Fogg Phileas 1965 La table Internaute
idFilm email note
100 fogg@verne.fr 4 104 fogg@verne.fr 3 100 doe@void.com 5 107 doe@void.com 2 106 fogg@verne.fr 5 La table Notation
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.
Associations ternaires
Dans le cas d’associations impliquant plus de deux entités, on atteint une des limites du modèle En- tité/Association en matière de spécification de contraintes. En première approche, on peut appliquer la règle énoncée précédemment pour les associations binaires et la généraliser. On obtiendrait alors, pour l’association Séance :
idCinéma no capacité
Le Rex 1 200
Kino 1 130
Le Rex 2 180
La table Salle
idHoraire heureDébut heureFin
1 14 16
2 16 18
La table Horaire
idFilm titre année genre idMES codePays
100 Alien 1979 Science Fiction 1 USA
101 Vertigo 1958 Suspense 2 USA
102 Psychose 1960 Suspense 2 USA
103 Kagemusha 1980 Drame 3 JP
104 Volte-face 1997 Action 4 USA
105 Van Gogh 1991 Drame 8 FR
106 Titanic 1997 Drame 6 USA
107 Sacrifice 1986 Drame 7 FR
La table Film
idFilm nomCinéma noSalle idHoraire tarif
103 Le Rex 2 1 23
103 Le Rex 2 2 56
100 Kino 1 2 45
102 Le Rex 2 1 50
La table Séance
FIG. 4.3 – Représentation d’une association ternaire : Séance
– Salle (nomCinéma, no, capacité)
– Film (idFilm, titre, année, genre, résumé, idMES, codePays)
– Horaire (idHoraire, heureDébut, heureFin)
– Séance (idFilm, nomCinéma, noSalle, idHoraire, tarif)
Donc, la relation Séance a pour clé la concaténation des identifiants de chacune des entités composantes, ce qui donne une clé d’une taille assez importante. On autorise alors une base comme celle de la figure 4.3. On ne peut pas trouver deux fois le même triplet constituant la clé.
Maintenant on s’aperçoit que la même salle présente deux films différents au même horaire. Si on souhaite éviter cette situation, la clé devient (nomCinéma, noSalle, idHoraire), et on ne respecte plus la règle de passage du schéma E/A vers le schéma relationnel.
En d’autres termes, en cas d’association entre plus de 2 entités, la clé de la table représentant l’asso- ciation est un sous-ensemble de la concaténation des clés. Il faut se poser soigneusement la question de la (ou des) clé(s) au moment de la création de la table car elle(s) ne peu(ven)t plus être déduite(s) du schéma E/A. On parle parfois de clé candidate. Ces clés peuvent être spécifiées avec la clauseUNIQUEdu langage SQL2.