DEUXIÈME PARTIEConception et création d’un site À partir d’ici nous commençons la conception et la réalisation du site WEBSCOPE, une application complète de gestion d’une base de films e
Trang 1178 Chapitre 3 Programmation objet
$ l i g n e [ ’ l i b e l l e ’ ] , 3 0 ) ;
$form−>champListe ( $ t h i s −>e n t e t e s [ ’ t y p e ’ ] , " t y p e " ,
$ l i g n e [ ’ t y p e ’ ] , 1 ,
$ t h i s−>t y p e s A u t o r i s e s ) ;
$form−>f i n T a b l e ( ) ;
i f ( $ a c t i o n == IhmBD : : MAJ_BD)
$form−>champValider ( " M o d i f i e r " , " submit " ) ;
e l s e
$form−>champValider ( " I n s é r e r " , " submit " ) ;
r e t u r n $form−>formulaireHTML ( ) ;
}
}
? >
Seules deux méthodes sont surchargées : le constructeur et le formulaire Pour le constructeur, notez que l’on combine un appel au constructeur de la classe générique avec parent:: construct et l’ajout de quelques initialisations Quand on mani-pulera un objet de la classe IhmCarte, le constructeur et le formulaire seront ceux de
la sous-classe, toutes les autres méthodes provenant par héritage de la super-classe
Trang 2DEUXIÈME PARTIE
Conception
et création d’un site
À partir d’ici nous commençons la conception et la réalisation du site WEBSCOPE, une application complète de gestion d’une base de films et d’appréciations sur ces films Comme pour les exemples, récupérez le code sur le site du livre et
décompressez-le dans htdocs La structure des répertoires est plus complexe que celle
utilisée jusqu’à présent Pour vous aider à retrouver les fichiers, les exemples du livre donnent leur nom en le préfixant par le chemin d’accès à partir de la racine webscope
Vous trouverez dans le répertoire WEBSCOPE un fichier LISEZ_MOI qui indique comment installer l’application, créer la base et l’initialiser avec un ensemble de films et d’artistes
Trang 4Création d’une base MySQL
4
Ce chapitre présente le processus de conception et de définition du schéma d’une base
MySQL Le schéma correspond à tout ce qui relève de la description de la base Il définit la forme de la base, ainsi que les contraintes que doit respecter son contenu
La conception d’un schéma correct est essentielle pour le développement d’une application viable Dans la mesure ó la base de données est le fondement de tout le système, une erreur pendant sa conception est difficilement récupérable par la suite Nous décrivons dans ce chapitre les principes essentiels, en mettant l’accent sur les pièges à éviter, ainsi que sur la méthode permettant de créer une base saine
4.1 CONCEPTION DE LA BASE
La méthode généralement employée pour la conception de bases de données est de
construire un schéma Entité/Association (E/A) Ces schémas ont pour caractéristiques
d’être simples et suffisamment puissants pour représenter des bases relationnelles De plus, la représentation graphique facilite considérablement la compréhension
La méthode distingue les entités qui constituent la base de données, et les asso-ciations entre ces entités Ces concepts permettent de donner une structure à la
base, ce qui s’avère indispensable Nous commençons par montrer les problèmes qui surviennent si on traite une base relationnelle comme un simple fichier texte, ce que nous avons d’ailleurs fait, à peu de choses près, jusqu’à présent
4.1.1 Bons et mauvais schémas
Reprenons la table FilmSimple largement utilisée dans les chapitres précédents Voici
une représentation de cette table, avec le petit ensemble de films sur lequel nous avons travaillé
Trang 5182 Chapitre 4 Création d’une base MySQL
titre année nom_realisateur prénom_realisateur annéeNaiss Alien 1979 Scott Ridley 1943 Vertigo 1958 Hitchcock Alfred 1899 Psychose 1960 Hitchcock Alfred 1899 Kagemusha 1980 Kurosawa Akira 1910 Volte-face 1997 Woo John 1946 Pulp Fiction 1995 Tarantino Quentin 1963 Titanic 1997 Cameron James 1954 Sacrifice 1986 Tarkovski Andrei 1932
L’objectif de cette table est clair Il s’agit de représenter des films avec leur metteur en scène Malheureusement, même pour une information aussi simple, il est facile d’énumérer tout un ensemble de problèmes potentiels Tous ou presque découlent d’un grave défaut de la table ci-dessus : il est possible de représenter la même information plusieurs fois
Anomalies lors d’une insertion
Rien n’empêche de représenter plusieurs fois le même film Pire : il est possible
d’in-sérer plusieurs fois le film Vertigo en le décrivant à chaque fois de manière différente,
par exemple en lui attribuant une fois comme réalisateur Alfred Hitchcock, puis une autre fois John Woo, etc
Une bonne question consiste d’ailleurs à se demander ce qui distingue deux films l’un de l’autre, et à quel moment on peut dire que la même information a été répétée Peut-il y avoir deux films différents avec le même titre par exemple ? Si la réponse est
« non », alors on devrait pouvoir assurer qu’il n’y a pas deux lignes dans la table avec
la même valeur pour l’attribut titre Si la réponse est « oui », il reste à déterminer quel est l’ensemble des attributs qui permet de caractériser de manière unique un film
Anomalies lors d’une modification
La redondance d’informations entraîne également des anomalies de mise à jour
Supposons que l’on modifie l’année de naissance de Hitchcock pour la ligne Vertigo et pas pour la ligne Psychose On se retrouve alors avec des informations incohérentes.
Les mêmes questions que précédemment se posent d’ailleurs Jusqu’à quel point peut-on dire qu’il n’y a qu’un seul réalisateur nommé Hitchcock, et qu’il ne doit donc
y avoir qu’une seule année de naissance pour un réalisateur de ce nom ?
Anomalies lors d’une destruction
On ne peut pas supprimer un film sans supprimer du même coup son metteur en
scène Si on souhaite, par exemple, ne plus voir le film Titanic figurer dans la base de
données, on va effacer du même coup les informations sur James Cameron