Pratique de MySQL et PHP- P44 docx

4.2 Schéma de la base de données 193 Ré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)dansSé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 où 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.2SCHÉMADELABASEDEDONNÉ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é 194 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, où elle devient une clé étrangère.Voicilesché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. 4.2 Schéma de la base de données 195 Tableau 4.5 —LatableFilm id titre année genre id_realisateur code_pays 1 Alien 1979 Science Fiction 51 US 2 Vertigo 1958 Suspense 52 US 3 Psychose 1960 Suspense 52 US 4 Kagemusha 1980 Drame 53 JP 5 Volte-face 1997 Action 54 US 6 Van Gogh 1991 Drame 58 FR 7 Titanic 1997 Drame 56 US 8 Sacrifice 1986 Drame 57 FR Tableau 4.6 —LatableArtiste id nom prénom année_naissance 51 Scott Ridley 1943 52 Hitchcock Alfred 1899 53 Kurosawa Akira 1910 54 Woo John 1946 56 Cameron James 1954 57 Tarkovski Andrei 1932 58 Pialat Maurice 1925 Tableau 4.7 —LatablePays 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 àunfilm. 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. 196 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-mduschémadelafigure4.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.Onpeut 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 —LatableFilm 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 —LatableArtiste 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 —LatableRôle id_film id_acteur rôle 9 100 William Munny 9 101 Little Bill 10 101 Bril 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). 4.3 Création de la base Films avec MySQL 197 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. Vous devez, pour vos propres bases de données, faire vos propres choix en connaissance de cause. Tableau 4.11 —LatableFilm id titre année genre id_realisateur code_pays 1 Alien 1979 Science Fiction 51 US 2 Vertigo 1958 Suspense 52 US 3 Psychose 1960 Suspense 52 US 4 Kagemusha 1980 Drame 53 JP 5 Volte-face 1997 Action 54 US 6 Van Gogh 1991 Drame 58 FR 7 Titanic 1997 Drame 56 US 8 Sacrifice 1986 Drame 57 FR Tableau 4.12 —LatableInternaute email nom prénom année_naissance doe@void.com Doe John 1945 fogg@verne.fr Fogg Phileas 1965 Tableau 4.13 —LatableNotation 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. 4.3 CRÉATION DE LA BASE FILMS AVEC MySQL 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. . 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. 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. manière unique et suffisante à l’aide de l’identifiant. On « exporte » donc la clé de A dans B, où elle devient une clé étrangère.Voicileschéma obtenu pour la base Films après application de cette règle.