Académique Documents
Professionnel Documents
Culture Documents
Creat Bases Donnees
Creat Bases Donnees
Synthse de cours
& exercices
corrigs
collection
Synthex
Nicolas Larrousse
Informatique
Synthse de cours
&
exercices corrigs
Synthex
collection
Aucune reprsentation ou reproduction, mme partielle, autre que celles prvues l'article L. 122-5 2 et 3 a) du code de la proprit intellectuelle ne peut tre faite sans l'autorisation expresse de Pearson Education France ou, le cas chant, sans le respect des modalits prvues l'article L. 122-10 dudit code.
Sommaire
Lauteur Le relecteur Avant-propos Chapitre 1 Introduction aux bases de donnes 1 Quest-ce quune base de donnes ? 2 volution des bases de donnes et de leur utilisation 3 Systmes de gestion de bases de donnes 4 tapes de la conception des bases de donnes 5 Mtiers des bases de donnes 6 Plan de louvrage 7 Prsentation de la BD exemple Exercices Chapitre 2 Analyse du monde rel 1 Dmarche danalyse 2 Modlisation par le modle entit-association 3 Remise en cause et volution du modle 4 Reprsentation avec UML Exercices Chapitre 3 Approche relationnelle 1 Concepts 2 Oprations du modle relationnel 3 Passage du modle conceptuel au relationnel 4 Normalisation
5 Logique du premier ordre et base de donnes
V VII IX 1 2 4 13 17 19 20 20 22 27 28 30 35 40 44 55 56 60 68 70
76
Exercices Chapitre 4 SQL 1 Concepts du langage SQL 2 Oprations relationnelles avec SQL 3 Gestion de tables et de vues 4 Gestion des donnes Exercices
Chapitre 5 Du langage parl SQL 1 Prsentation de lactivit modliser 2 laboration du modle entit-association 3 Passage au modle relationnel 4 Interrogation de la base de donnes Exercices Chapitre 6 Prservation des donnes 1 Contrle daccs et sauvegarde 2 Limitations daccs au SGBD 3 Transactions 4 Triggers Exercices Annexe Bibliographie Index
127 128 129 134 141 148 157 158 161 166 173 176 183 189 191
IV
Lauteur
Nicolas Larrousse est ingnieur au CNRS. Spcialis en informatique, il enseigne les bases de donnes au niveau Master luniversit de Versailles Saint-Quentin-en-Yvelines et au service de formation permanente de luniversit Pierre et Marie-Curie Jussieu. Il est responsable dun atelier sur les outils informatiques pour le master de sciences cognitives de lcole normale suprieure (Ulm). Il a mis en place une formation de type IUP (bac + 4) en informatique luniversit dAntananarivo (Madagascar). Il a particip la conception et la mise en uvre de nombreuses bases de donnes, essentiellement dans le domaine documentaire lINIST (CNRS). Il est impliqu dans le programme des formations TRANSFER de lAUF (Agence universitaire de la francophonie), o il soccupe plus particulirement des formations rseaux et des certifications Linux.
Avant-propos V
Le relecteur
ric Innocenti est matre de confrences en informatique luniversit de Corse Pasquale Paoli. Il est responsable pdagogique des filires SRC (Services et Rseaux de Communication) et LPM (Licence Professionnelle Multimdia). Il enseigne lalgorithmique, la programmation ainsi que les systmes dinformation lInstitut universitaire de technologie. Son parcours professionnel la conduit de la gestion informatique pour le compte de socits prives la recherche universitaire o il travaille sur la modlisation et la simulation informatique des systmes complexes. Il est galement auteur de progiciels de gestion et continue dexercer la fonction danalyste consultant auprs dentreprises et dadministrations.
Le relecteur VII
Avant-propos
Objectifs de louvrage
Le but de cet ouvrage est de proposer une mthode ceux qui veulent concevoir un systme dinformation robuste et volutif en vitant les cueils classiques aboutissant des donnes inutilisables. En effet, une mauvaise conception de dpart conduit stocker des donnes inutiles (redondance) et ainsi gnrer des incohrences. Par ailleurs, une structure de donnes inadapte peut provoquer des erreurs fondamentales dexpression dans linterrogation de la base de donnes. Il nest pas ais de prsenter dans un seul ouvrage toutes les facettes du monde des bases de donnes de lenqute pralable la ralisation pratique en SQL et il a donc fallu oprer certains choix pour ne conserver que lessentiel. La bibliographie propose permet dapprofondir les diffrents sujets prsents dans louvrage. La langue utilise est volontairement peu technique pour rendre accessibles les concepts au public dbutant vis. Louvrage sadresse des tudiants, de toutes les filires, qui dbutent dans ce domaine, mais aussi aux professionnels qui veulent mettre en place une base de donnes, mme de taille modeste. En effet, les problmes pratiques que pose la ralisation dune base de donnes se retrouvent toutes les chelles, et ces aspects sont traits dans cet ouvrage au mme niveau que les notions thoriques.
Organisation de louvrage
Le chapitre 1 est une introduction la notion de base de donnes et aux mtiers associs. Il propose une mise en perspective de lvolution des bases de donnes, mais aussi de leur utilisation (fouille de donnes, entrepts de donnes, etc.). Les chapitres 2, 3 et 4 dcrivent les diffrentes tapes de la conception dune base de donnes : la construction du modle conceptuel (entit-association dans cet ouvrage), le passage au modle relationnel puis la ralisation avec le langage SQL.
Avant-propos IX
Le chapitre 5 reprend les notions prsentes dans les chapitres prcdents en les appliquant un exemple concret, ainsi trait de manire complte. Un regard critique sur la modlisation effectue conduit la remise en cause et lvolution du modle.
Le chapitre 6 est consacr la prservation des donnes. En effet, une fois le processus de cration ralis, on doit mettre en uvre des outils pour garantir la prennit des donnes. Aprs avoir nonc quelques conseils gnraux, on prsente ici les deux outils fondamentaux que sont les transactions et les dclencheurs (triggers).
Notation
Les mots importants dune section sont mis en exergue par lutilisation de gras. Lorsque lon fait rfrence des objets dfinis dans louvrage, par exemple une table, ils sont entre guillemets simples (). Afin que la lecture soit facilite et les confusions vites, un mot unique par chapitre a t choisi pour dsigner les synonymes que constituent les termes attribut , champ et colonne . Le terme attribut est utilis dans le chapitre 2 pour le modle entit-association, le terme champ est utilis dans le chapitre 3 pour le modle relationnel et le terme colonne est utilis dans le chapitre 4 consacr SQL. Les noms des entits, des associations et de leurs attributs sont accentus dans le chapitre 2 alors que les noms des tables, des relations et de leurs champs ne sont pas accentus dans les chapitres 3 et 4 car ils sont utiliss directement dans le code SQL ainsi que dans les SGBD, qui ne les acceptent pas systmatiquement. Les mots cls du langage SQL sont en majuscules pour les diffrencier facilement des parties variables que sont les noms des colonnes et des tables qui sont en minuscules. Dans la mesure du possible, les exemples en SQL sont indpendants du SGBD employ.
Ressources complmentaires
Les scripts prsents dans louvrage sont accessibles sur le site de Pearson Education France (http://www.pearsoneducation.fr), diteur de louvrage. Vous y trouverez galement des jeux de donnes pour les bases de donnes que lon utilise ici ainsi que les scripts de cration des diffrentes tables.
Remerciements
Je tiens remercier ric Innocenti pour son implication dans le projet. Je remercie particulirement Christophe Lenne, chez Pearson Education France, notamment pour sa patience.
Chapitre
Au cours des dernires annes, les bases de donnes ont connu un dveloppement considrable, au point quelles jouent dsormais un rle dans chacune de nos oprations quotidiennes du simple achat effectu avec sa carte bancaire jusqu nos dclarations de revenus. Lobjectif de ce chapitre est de dfinir la notion de base de donnes ainsi que les principaux concepts qui sy rattachent. La mthodologie qui permet de les concevoir, les applications informatiques associes leur mise en uvre (SGBD) et les diffrents mtiers des bases de donnes y sont prsents.
Chapitre directement dans le code, ce qui rend leur utilisation difficile par dautres programmes, en particulier lorsque lon modifie cette structure. Ce que lon recherche en utilisant une base de donnes est dassurer lindpendance entre le traitement et les donnes. Cest pourquoi, il est ncessaire que lapplication obtienne des informations sur la structure des donnes (nom, type, taille, etc.). Pour ce faire, on associe la base de donnes une description que lon appelle mtadonne ou catalogue . Cette dernire dcrit la structure interne de la base de donnes qui est spcifique au SGBD employ (voir figure 1.1). En plus de la structure et du type des donnes, on stocke galement cet endroit les informations concernant les rgles de cohrence des donnes abordes la section suivante. Figure 1.1
Base de donnes de CD et mtadonne.
Nombre entier suprieur 1 Chane de caractres de taille 30 Nombre entier suprieur 1900 et infrieur lanne en cours
NumCD 1 2 3
Lide gnrale est que lutilisateur ou lapplication utilisatrice des donnes ne doit pas tre dpendante de leur reprsentation interne, ce qui constitue une abstraction des donnes. Cest la raison pour laquelle on utilise une description des donnes sous la forme dun modle pour permettre la restitution la plus efficace possible de linformation.
pertinents sont retourns lors dune interrogation. La redondance est parfois plus dlicate identifier. Si lon considre le cas trs simple dun carnet dadresses qui contiendrait en mme temps le code postal et le nom de la ville, elle est ici vidente. Tableau 1.1
Exemple de redondance de linformation.
On remarque que lon stocke plusieurs fois la mme association dinformation (par exemple, Nancy et 54000), ce qui consomme de la place inutilement et peut devenir significatif lorsque la base atteint quelques millions denregistrements. De plus il existe des incohrences dans la saisie du nom de la ville Bordeaux. La recherche par le nom Bordeaux ne donnera pas le mme rsultat que la recherche par le code 33000. On verra plus loin que lapproche relationnelle procure des outils capables de dtecter et damliorer considrablement ce genre de problmes de qualit des bases de donnes.
2.1 CONTEXTE
partir des annes 1960, les ordinateurs voluent rapidement. Ils sont de plus en plus performants mais aussi de plus en plus rpandus du fait de leur cot plus raisonnable. Leur utilisation change galement ; on passe de la notion de calculateurs purs des machines capables aussi de traiter de linformation. On parvient un niveau dabstraction supplmentaire par rapport aux machines et on obtient en consquence une indpendance par rapport larchitecture et surtout par rapport aux constructeurs. La dcennie des annes 1970 est une priode faste pour la recherche et linnovation en informatique dont les rsultats sont encore utiliss aujourdhui. On peut utiliser des langages de programmation de haut niveau, afin de guider, voire de faonner, la dmarche du programmeur (Pascal), et lon envisage des systmes dexploitation indpendants de la machine employe (Unix). Cest galement cette poque que lon pose les fondements des techniques qui sont utilises dans les rseaux (TCP/IP), en particulier pour Internet. Cest dans ce contexte favorable que E. F. Codd dfinit et dveloppe lapproche relationnelle en base de donnes.
Chapitre Lobjectif principal est dloigner lutilisateur des dtails dimplmentation et de faciliter ainsi lusage de linformatique. Un autre but est de rendre gnriques et rutilisables les dveloppements informatiques, parfois devenus caducs en raison dun changement de machine. Dans le domaine des bases de donnes, le dveloppement de larchitecture trois niveaux constitue une premire tape importante. Les fonctionnalits des systmes de bases de donnes sont spares en trois niveaux : niveau physique, niveau logique et niveau externe.
2.2 MODLES
Les modles de donnes correspondent la manire de structurer linformation dans une base de donnes. Ils reposent sur les principes et les thories issus du domaine de la recherche en informatique et permettent de traduire la ralit de linformation vers une reprsentation utilisable en informatique.
Voiture Logement
Marque Type Couleur Numro Rue Ville Type
Modle relationnel
En 1970, E. F. Codd propose un nouveau modle relationnel dans un article rest clbre : A Relational Model of Data for Large Shared Data Banks , CACM 13, no 6, June 1970. Il cherche crer un langage dinterrogation des bases de donnes plus proche du langage naturel. Dans cette optique, il fonde sa recherche sur des concepts mathmatiques rigoureux, tels que la thorie des ensembles et la logique du premier ordre. Le modle relationnel permet de modliser les informations contenues dans les bases de donnes en utilisant des relations, cest--dire des ensembles dattributs (voir figure 1.3). De lide de dpart la ralisation dun produit utilisable, le laps de temps est souvent de lordre dune dcennie. La mise en uvre des ides de Codd se fait chez IBM dans le cadre du projet de recherche System-R. Le premier produit commercial sera non pas le fait dIBM, mais celui dHoneywell en 1976. Il sera suivi dun produit rellement abouti de chez Relationnel Software en 1980 : Oracle, qui a connu le succs que lon sait. De son ct IBM en tirera un produit qui deviendra DB2. Toujours dans le cadre du projet de recherche System-R, E. F. Codd met au point, en mme temps que le modle relationnel, un langage dinterrogation des donnes, SEQUEL, qui deviendra ensuite SQL (Structured Query Language). La normalisation du langage SQL ds 1986 par lANSI (institut de normalisation amricaine), puis par lISO (organisation internationale de normalisation), a assur pour une grande partie le succs du modle relationnel auprs des entreprises. Fait rare dans le monde informatique, ce langage a t adopt par la quasi-totalit des diteurs commerciaux qui participent activement son volution. SQL est devenu le standard de fait, mme si aucun diteur ne respecte la lettre la norme. Dailleurs, partir de SQL 2, il existe une dfinition de quatre niveaux de compatibilit avec la norme officielle. La normalisation de ce langage garantit sa prennit, mme si son volution sen trouve ralentie. Les requtes crites pour un SGBD fonctionnent en gnral sans trop de modifications avec un autre SGBD, ce qui permet denvisager des migrations moins douloureuses et de conserver une partie de linvestissement initial. Figure 1.3
Modle relationnel.
Ouvrage (Cote, Titre, Auteur,Editeur)
Cote 1 2 3 4 5 6 Titre La programmation sous Unix Les bases de donnes Internet pour les nuls Le langage C Petit Larousse illustr Godel, Escher & Bach Auteur J. M. Rifflet G. Gardarin C. Baroudi C. Delannoy P. Larousse D. Hofstadter Editeur MC Graw Hill Eyrolles First Interactive Eyrolles Larousse Basic Book Inc.
Modle objet
Dans le sillage du dveloppement des langages orients objet (C++, Java) dans les annes 1980, le concept objet a t adapt aux bases de donnes. Plusieurs raisons, en dehors des qualits reconnues de lapproche objet, ont conduit dfinir une extension objet pour les bases de donnes (voir figure 1.4). La premire est que le modle relationnel, dans sa simplicit, ne permet pas de modliser facilement toutes les ralits. La deuxime est quun objet permet de reprsenter directement un lment du monde rel. Les structures dlments complexes se retrouvent souvent disperses entre plusieurs tables dans lapproche relationnelle classique. De plus, le concept objet est mieux adapt pour modliser des volumes de texte importants ou dautres types de donnes multimdias (sons, images, vidos). Enfin, il est beaucoup
Chapitre plus commode de manipuler directement des objets lorsque lon dveloppe avec un langage objet (comme C++ ou Java). Les bases de donnes, on le rappelle, sont dornavant des briques constitutives des applications. Les bases de donnes orientes objet apportent ainsi aux applications dveloppes en langage objet la persistance des objets manipuls : ces derniers peuvent ainsi directement tre rutiliss par lapplication dorigine ou par dautres sans redfinition. Ces concepts ont t intgrs partir de la version 2 de la norme SQL. Les produits commerciaux adapts ces concepts nont pas connu une diffusion suffisamment importante. Le monde des bases de donnes volue assez lentement : la migration dun systme dinformation vers lobjet reprsente pour une organisation un investissement considrable qui nest pas toujours justifi. La robustesse et la popularit de lapproche relationnelle, qui a mis presque vingt ans simposer, a galement frein le dveloppement de lapproche objet pure dans les bases de donnes. Les donnes modlises sous forme dobjets sont aussi plus complexes reprsenter du point de vue du SGBD et lon rencontre encore trs souvent des problmes de performance. Figure 1.4
Modle objet.
Objet
Mthodes
Encapsulation
Donnes
Hritage
Dplacer()
X1,Y1 X2,Y2
Fermer Agrandir()
Retourner
Modle relationnel-objet
Une demande dvolution du strict modle relationnel existe toutefois. En effet, la gestion des donnes autres que du texte et des nombres comme des images, du son et des vidos implique lvolution du modle relationnel. De mme, les champs dits multivalus , disposant de plusieurs valeurs telles quune liste de prnoms ou des coordonnes gographiques, ne peuvent pas tre modliss efficacement en utilisant ce type dapproche. Lide est alors dintgrer de lobjet au modle relationnel existant plutt que dutiliser lapproche objet pure. Il convient de remarquer que ce type dvolution a dj t dvelopp dans le cadre des langages de programmation. Le langage C++ est lvolution intgrant lapproche objet du langage C et non pas un langage objet pur comme peut ltre Smalltalk. Cette extension, adopte par la plupart des SGBD, se nomme relationnel-objet et permet aux concepteurs des bases de donnes de disposer de types volus abstraits plus simples concevoir et surtout plus commodes faire voluer. Elle offre en outre la possi-
bilit de modliser plus facilement la complexit des organisations (voir figure 1.5). Dans cette optique, la norme SQL a logiquement t adapte. Dans sa version 3, elle prend en compte lextension objet. Les types de donnes sont tendus et les oprations dencapsulation et dhritage, typiques de lapproche objet, sont supportes. Cette solution a lavantage doffrir un bon niveau de compatibilit avec lapproche prcdente trs rpandue et deffectuer ainsi une migration plus aise. Figure 1.5
Modle relationnel-objet.
1
Cote
Titre
Auteur
Editeur
Le vide
Romazava
Nom Brass Duporche Chteau Paclaire Prnom Alexis Jean-Marie Romain Anne-Isabelle
Chapitre modification de localisation, daugmentation de la taille de la base, dajouts dordinateurs sur le rseau afin daugmenter la capacit de stockage de la base de donnes. Figure 1.6
Base de donnes rparties.
Filiale Est
Copie sauvegarde
Sige social
Copie sauvegarde
Copie sauvegarde
Filiale Asie
Interrogation (rpartition)
Ces technologies possdent nanmoins des inconvnients. La scurit sur les rseaux informatiques ncessite beaucoup plus de travail que dans le cas dun systme non rparti. Les techniques de scurit mettre en uvre sont plus complexes et plus coteuses.
Figure 1.7
Base de donnes dductives prefils.
Pre Hugo Tapeneau Tian Merlin Alize Fils Tian Merlin Lastoul Alize Teanne
Linformation dcisionnelle ainsi extraite a de nombreux dbouchs : du ciblage marketing la mdecine en passant par la prvision financire. Les mthodes saffinent et deviennent rellement efficaces, ce qui a cependant donn lieu quelques escroqueries, les entreprises spcialises dans le domaine refusant bien sr de donner les spcifications de leurs mthodes danalyses, qui relevaient parfois de la divination, au motif de ne pas perdre leur avantage concurrentiel.
10
Production
Consultation
Service du personnel
XML
Le World Wide Web est la mise en uvre du concept dhypertexte par lutilisation de la structure de communication fournie par Internet. Les fichiers disperss sur diffrentes machines du rseau Internet peuvent ainsi tre associs. Son succs a provoqu un glissement de lide originale, qui consistait relier simplement des textes entre eux, vers la notion dinterface universelle. On ne transmet plus seulement le contenu dun fichier statique, mais galement le rsultat de lexcution dun programme : le contenu devient donc dynamique. Par extension, on imagine aisment que le mcanisme du Web peut galement transmettre le rsultat de linterrogation dune base de donnes. Le concepteur du Web, T. B. Lee, sest appuy pour sa mise en uvre, outre la structure technique existante dInternet, sur un langage de description de documents utilisant des balises : le SGML (Standard Generalized Markup Language). Le dcoupage du document par les balises est dcrit dans un document associ que chacun peut crer en fonction des ses besoins : la DTD (Data Type Definition). Cette dernire, formule dans un langage normalis, permettra des programmes spcialiss, les parsers , de vrifier si le document est conforme la structure attendue et den extraire facilement le contenu. Le langage SGML est assez complexe manipuler, car il est trs gnral. Pour des besoins spcifiques, on utilise des versions simplifies, telles que HTML ou XML. T. B. Lee a donc dvelopp un langage de prsentation, HTML (Hyper Text Markup Language), bas sur les notions dveloppes par SGML. Ce langage permet essentiellement de spcifier des critres de prsentation (gras, soulign, couleur) et, bien sr, de dcrire les liens entre les fichiers. Il ne comprend aucun lment de structuration des donnes du texte contenu dans la page HTML. Les moteurs de recherche parcourent le Web et indexent le contenu des pages par rapport des listes de mots cls combins dautres mthodes (beaucoup) plus sophistiques. Cependant, ils ne peuvent diffrencier dans le texte le titre dun rsum ou dune lgende associe une image. Lefficacit et la pertinence de lindexation en sont diminues dautant. Pour remdier cela, le W3C (World Wide Web Consortium) a dfini un langage, qui est galement une simplification de SGML, permettant de dcrire la structure interne dun document : XML (eXtended Markup Language). La structure dun document XML est reprsente sous la forme dun arbre tout comme celle dun document HTML. La description de
cette structure arborescente se trouve dans une DTD ou plus rcemment dans un schma XML. Le schma est plus souple et permet demployer les mmes outils de traitement que pour les fichiers XML. Le langage HTML possde videmment lui aussi une DTD, mais, la diffrence de XML, elle est normalise par le W3C et ne peut tre modifie et adapte pour ses besoins propres (voir figure 1.9). Lobjectif terme est que les fichiers du World Wide Web soient dsormais dcrits en utilisant XML la place de HTML. La prsentation des donnes repose alors sur les feuilles de styles (telles que eXtended Stylesheet Language) pour gnrer les formats de prsentation classiques (HTML, PDF, PostScript) partir du format XML. De cette manire, les moteurs de recherche pourront extraire directement par exemple le rsum ou le titre dun paragraphe dun fichier XML. Lindexation peut ainsi tre plus prcise ; un mot figurant dans un titre tant plus important que le mme mot dans une note de bas de page. Figure 1.9
Structure arborescente XML.
<catalogue> <article> <nom> banane </nom> <prix>
2 catalogue
</prix>
1000
</quantit>
article article
pige 300
</nom>
</prix>
35
<quantit> </article>
</quantit>
quantit prix nom 1000 prix 2 banane 300 nom quantit
<catalogue>
pige
Quel est le rapport avec les bases de donnes ? Comme on la vu prcdemment, une page Web peut tre le rsultat dune requte provenant dun SGBD ; cest mme devenu le moyen le plus courant dinterroger un SGBD. Dans cette optique, si le SGBD est capable de gnrer directement du XML, cela facilite le processus. Cest dautant plus vrai que le passage du modle relationnel un modle arborescent de type XML est parfois complexe et quil est bien agrable que le SGBD sache le faire. Le langage de description XML, par sa versatilit, simpose comme un format dchange universel. Cest vident pour des fichiers gnrs par un traitement de texte : on spare ainsi laspect structurel de laspect prsentation. On se donne galement la possibilit douvrir le document indpendamment du logiciel utilis, ce qui garantit sa prennit. De la mme manire, XML est utilis comme format dchange entre SGBD et dun SGBD vers dautres logiciels (tableurs, traitements de texte). Le langage XML est adopt petit petit par la plupart des diteurs et il est amen jouer un rle croissant dans les changes de donnes. De plus en plus de SGBD sont capables de produire des rsultats de requte en XML, dimporter du XML et acceptent mme de grer les donnes directement dans ce format. Cette dernire possibilit implique que les SGBD supportent des donnes moins bien structures : cette capacit constitue lune des volutions futures des SGBD.
12
Chapitre
Contenu multimdia
Le multimdia sest fortement dvelopp depuis la fin des annes 1990. La demande tant trs forte dans ce domaine, les diteurs de SGBD se doivent dintgrer de linformation multimdia (image, son, vido) dans les bases de donnes. Les bases de donnes multimdias posent de nouveaux problmes, en particulier pour effectuer des recherches sur les contenus multimdias, ce qui est par nature difficile. Une solution est deffectuer une indexation prliminaire manuelle laide de mots cls qui permettent doprer par la suite des interrogations, mais cela semble illusoire de raliser ce traitement pour des volumes importants de documents multimdias. Dans le cas contraire, il existe des mthodes de recherche sur des fichiers de type image par rapport des schmas prdfinis. Cette possibilit reste pour linstant plutt du domaine de la recherche, mme si lon est dj (malheureusement) capable didentifier des visages par rapport un modle dans certaines conditions.Dans le mme ordre dide, il est dj possible dutiliser des techniques pour valuer le style de musique (classique, jazz, pop) dun fichier en analysant son contenu. On est cependant assez loin de pouvoir identifier un genre de film en se basant sur lanalyse des images. Les bases de donnes multimdias constituent un sujet de recherche trs prometteur et trs actif. Ces problmatiques relvent pour linstant plutt des proccupations des socits dveloppant les moteurs de recherche que des bases de donnes au sens strict. Cependant, le groupe de normalisation ISO/IEC prpare lvolution pour le multimdia de la norme SQL-MM, qui est une volution pour le multimdia de la norme SQL.
Figure 1.10
Fichier informatique.
Fichier
Accs squentiel
Dans le cas dun accs squentiel, la recherche dun enregistrement en position n ncessite daccder aux n1 enregistrements qui le prcdent. Si lon recherche larticle de rfrence DR-NetCard10.102, contenu dans le fichier Article, il sera ncessaire de parcourir tous les enregistrements, depuis le dbut du fichier jusqu larticle recherch. Pour retrouver une information, il faut donc parcourir tous les enregistrements un un et en examiner le contenu. Une alternative au parcours squentiel est de construire des tables descriptives afin dacclrer laccs aux donnes. Une premire table permet laccs direct un enregistrement par une cl associe ladresse (pointeur) de lenregistrement. On rappelle que cest ce mcanisme de pointeurs sur des enregistrements qui est modlis dans les modles hirarchiques ou rseaux pour faire le lien entre des enregistrements. On constitue ainsi le graphe qui permet de naviguer dans lensemble des enregistrements. Une seconde table contient lordre relatif des enregistrements ordonns suivant les valeurs dun champ : on appelle cette table un index (voir figure 1.11). Cette seconde table permet demployer des mthodes de recherche par le contenu du champ index beaucoup plus efficaces quune recherche squentielle. La recherche dichotomique bien connue est lune dentre elles. Une fois lenregistrement identifi, on y accde directement grce la premire table. Les techniques de constitution des index constituent un sujet part entire ainsi que les algorithmes de recherche qui leur sont associs. Figure 1.11
Fichier et index.
Fichier
Index
On constate que la simple recherche dinformations recourt dj des algorithmes assez sophistiqus et ncessite la construction et le maintien de structures annexes pour tre efficace. De mme, la destruction denregistrements et lvolution de la structure de la base sont galement des oprations lourdes mettre en uvre ; elles requirent souvent la recopie complte des informations dans un nouveau fichier. Cette section nous permet de comprendre pourquoi on utilise prfrentiellement des SGBD pour grer les donnes. Toutes ces fonctionnalits et bien dautres que nous allons dtailler sont intgres dans le logiciel.
14
Chapitre
Figure 1.12
Niveaux ANSI/ SPARC.
Niveau externe
Vues
Schma conceptuel
Modle conceptuel
Niveau interne
Il sagit comme pour le modle rseau de lISO dun cadre de rflexion ; les SGBD ne respectent pas la lettre le dcoupage propos. Ils se doivent cependant de possder les principales caractristiques qui dcoulent de ce modle en couches : Indpendance physique des donnes. Masquer la reprsentation interne des donnes ainsi que les mthodes systme daccs aux utilisateurs. Indpendance logique des donnes. Permettre la modification du schma conceptuel des donnes sans remettre en cause les mcanismes de stockage et de manipulation internes des donnes. Intgrit des donnes. Faire en sorte que linformation rsultant des liens entre les donnes soit cohrente. Il peut apporter galement des fonctionnalits supplmentaires utilises dans le cadre de bases de donnes rparties dcrites prcdemment : Rplication des donnes. Copie automatise de sauvegarde.
Virtualisation des donnes. Masquage de la distribution gographique des donnes. Haute disponibilit des donnes. Duplication de la base de donnes sur diffrents sites pour diminuer la distance client/serveur et la charge des serveurs. Le but principal de lutilisation dun SGBD est de masquer la reprsentation physique des donnes et les mthodes daccs que lon vient de voir prcdemment. Cependant les mcanismes de cration, dindexation et de recherche sous-jacents sont globalement les mmes. videmment, pour des questions defficacit, les SGBD utilisent leur propre gestion de fichiers et parfois mme contournent le systme de fichiers fourni avec le systme dexploitation de la machine. Un SGBD doit permettre galement la manipulation de la structure de la base de donnes, comme lajout et la modification de champs, de manire transparente. Il conserve cet effet une description de la structure de la base de donnes que lon appelle le dictionnaire de donnes . Pour raliser ces oprations avec lindpendance souhaite par rapport la reprsentation, le SGBD offre deux langages de haut niveau : un Langage de Description de Donnes (LDD) qui permet dagir sur la structure de la base de donnes (ajout, suppression et modification des tables) ; un Langage de Manipulation de Donnes (LMD) qui permet dinterroger et de mettre jour le contenu de la base de donnes. Ces langages sont de type non procdural , cest--dire que lon sintresse leffet de lopration (le quoi) et non pas la manire dont elle est ralise (le comment). On a pu se rendre compte dans la section prcdente du niveau de complexit de certaines oprations qui, grce ces langages, sont nonces simplement. Par exemple, la modification de la taille dun champ peut tre nonce en une seule instruction avec le LDD. Il est courant que les SGBD modernes implmentent ces langages de manipulation laide dobjets graphiques. Le SGBD doit galement assurer la protection des donnes en cas de problmes. Ceux-ci peuvent tre la consquence dune manipulation malheureuse, mais galement dune panne du systme qui survient par exemple la suite dune coupure de courant. Dans tous les cas, le SGBD doit permettre de restaurer les donnes. Ces oprations sont gnralement ralises en utilisant des journaux qui enregistrent au fur et mesure les oprations faites sur la base : cest le mcanisme de la journalisation. Ce journal est utilis pour refaire, ou dfaire le cas chant, ces oprations. En ce qui concerne les oprations de modification effectues sur la base de donnes, que lon appelle des transactions, des proprits de mesure de la qualit de ces transactions sont proposes sous le terme ACID : Atomicit. Une transaction est atomique ; elle est excute entirement ou abandonne. Cohrence. La transaction doit se faire dun tat cohrent de la base vers un autre tat cohrent. Isolement. Des transactions simultanes ne doivent pas interfrer entre elles. Durabilit. La transaction a des effets permanents mme en cas de panne. noter que tous les SGBD ne ralisent pas cette proprit ACID pour les transactions. Les machines sont connectes au rseau ou sont simplement multi-utilisateurs : le SGBD doit permettre de donner laccs aux bases de donnes plusieurs utilisateurs concurremment. Laccs concurrentiel implique des oprations algorithmiques complexes raliser, puisquil faut par exemple empcher la modification dune valeur par un utilisateur alors quelle est en lecture par un autre. Cela ncessite la gestion dune structure de description
16
Chapitre des utilisateurs comprenant les droits qui leur sont associs pour chaque lment (lecture, modification) : les droits daccs aux donnes. Les mcanismes sont les mmes que ceux qui sont mis en uvre dans les systmes dexploitation multi-utilisateurs.
vus prcdemment, comme llimination de la redondance. Le modle relationnel procure cette fin des outils capables de tester la cohrence du systme et de le modifier le cas chant : ce sont les formes normales , qui seront vues au chapitre 3. Il est possible de constater des incohrences ce niveau de lanalyse, ce qui implique de modifier le modle conceptuel de donnes dvelopp ltape prcdente. On obtient un schma des donnes qui fournira aux utilisateurs les informations ncessaires pour effectuer leurs requtes, par exemple la description des noms de tables, de champs et leurs types. Par contre, on perd ce niveau linformation du sens des donnes et du lien entre elles. Ce schma nest gure utilisable en pratique sans le prcdent. En effet, comment savoir que les personnes achtent des voitures et non pas le vendeur si lon ne dispose pas de linformation de liaison entre les objets du monde rel ? Cest galement lors de cette phase que lon dfinit les vues du systme dinformation qui sont adaptes chaque catgorie dutilisateurs.
Analyse
Modle entit-association
Vue 1
Transformation
Schma
Vue 2
LMD LDD
SGDB
relationnel
Vue 3
18
Chapitre
5.1 CONSULTANTS/ANALYSTES
Ils prennent en charge la premire tape qui consiste en lanalyse des activits et des flux dinformation mis en jeu dans le monde rel modliser. Le profil de ces acteurs nest pas toujours purement technique, puisque cette phase ncessite parfois beaucoup de dialogues et de psychologie pour parvenir faire exprimer leurs besoins rels par les futurs utilisateurs. La gageure est de parvenir faire exprimer correctement les besoins dinformatisation par les utilisateurs du systme dinformation, afin de proposer un modle conceptuel de donnes le plus juste possible.
Plan de louvrage
Le plan de louvrage est dtermin par les diffrentes tapes de la conception dune BD. Le deuxime chapitre traite de ltape danalyse du monde rel pour en concevoir un modle descriptif. La modlisation est effectue classiquement par le modle entitassociation . On aborde galement la reprsentation du modle avec UML. Le troisime chapitre est essentiellement consacr au modle relationnel et aux oprations qui lui sont associes. On sintresse ensuite aux mthodes grce auxquelles il est possible de passer du modle prcdent un ensemble de tables du modle relationnel. Puis, on continue par ltape de normalisation qui permet de mettre en vidence les incohrences du systme dinformation ainsi cr et de les rectifier. On prsente dans ce chapitre les trois premires formes normales et celle de Boyce-Codd. Une autre approche de la cration dune base de donnes partir de la relation universelle est aborde la fin du chapitre. Le quatrime chapitre prsente le langage SQL. Aprs avoir expos la syntaxe gnrale du langage, il sattache la ralisation en SQL des oprations relationnelles vues prcdemment. On aborde ensuite la correspondance entre les questions classiques des bases de donnes en langage parl et leur reprsentation avec SQL. La dernire partie du chapitre traite de la partie description de donnes de SQL, qui permet de crer et grer les tables dans un SGBD. Le cinquime chapitre constitue un exemple complet de ralisation dune base de donnes par la pratique. Cet exemple part de lnonc du monde rel en langage parl jusqu la ralisation du systme dinformation, puis bien sr son utilisation. Ce chapitre reprend les notions vues aux chapitres prcdents de manire pratique. Le sixime chapitre aborde les mcanismes gnraux de prservation des donnes associs aux SGBD. On aborde la scurit des accs et les sauvegardes, mais aussi les outils qui participent la scurisation des donnes comme les transactions ou les triggers .
Prsentation de la BD exemple
Une base de donnes extrmement simplifie est utilise rgulirement tout au long de louvrage afin dillustrer les concepts dvelopps au fil de louvrage. Dautres bases de donnes plus complexes sont prsentes au fur et mesure des explications (voir figure 1.14). Ce systme dinformation qui constitue ltude de cas basique modlise lactivit de vente de voitures doccasion. Dans ce systme, deux entits du monde rel sont identifies : les personnes et les voitures. Une voiture est caractrise par sa marque, son type, sa couleur. Une personne est caractrise par son nom, son ge, sa ville, son sexe. Laction modlise est la vente qui est caractrise par le prix de la vente et sa date. Une personne peut acheter une plusieurs voitures. Une voiture peut tre vendue une seule fois ou jamais.
20
ge
Sexe
Le modle entit-association et la reprsentation UML correspondant cette description seront crs au chapitre 2, Analyse du monde rel . Le modle relationnel sera cr au chapitre 3, Approche relationnelle . La base de donnes rsultante sera utilise pour les exemples du chapitre 4, SQL .
Rsum
Une base de donnes dsigne lensemble des donnes stockes. Pour manipuler ces donnes, on utilise un SGBD (Systme de Gestion de Bases de Donnes) qui est un logiciel complexe. Lensemble compos par les donnes et le SGBD constitue un systme dinformation. La conception dune base de donnes de la modlisation du monde rel son implmentation dans le SGBD fait appel des techniques et des mthodes trs diffrentes pour chaque tape. Des mtiers spcifiques se sont donc dvelopps autour de ces concepts et les mettent en uvre. Par exemple, lapproche du monde rel sapparente lanalyse faite par un cabinet de consulting alors que limplmentation dans le SGBD et son administration sont proches des mtiers informatiques. Les SGBD ont volu paralllement aux concepts de modlisation des bases de donnes. On est pass dune organisation comparable celle des fichiers informatiques (modles hirarchiques ou rseaux) un modle plus abstrait : le modle relationnel. Ce modle est toujours le plus utilis actuellement. Il est associ troitement SQL, un langage normalis de description, de manipulation et dinterrogation de donnes. La modlisation objet, adapte aux bases de donnes, na pas connu un dveloppement considrable, et ce, malgr les avantages quelle procure par rapport au modle relationnel en particulier pour le typage des donnes. Comme cest le cas dans le domaine de la programmation, une approche mixte semble prendre de lampleur : le modle relationnel-objet. Il sagit dapporter au modle relationnel les possibilits tendues de modlisation procures par les objets sans remettre profondment en question lexistant. Le dveloppement des rseaux apporte dautres manires dutiliser les bases de donnes, comme la rpartition des donnes pour amliorer leur disponibilit et leur scurit. Linterfaage avec le World Wide Web a introduit la prise en compte du langage XML comme format dchange et de stockage par les SGBD. De nouvelles formes dinterrogation, telles que la fouille de donnes (ou data mining) et les bases de donnes dductives, permettent dextrapoler de linformation non explicitement stocke dans les bases de donnes. Ces approches ainsi que la prise en compte des donnes multimdias vont faire voluer les modles de bases de donnes et les SGBD que lon utilise actuellement. Cela se fera probablement sans remettre totalement en cause le modle relationnel, mais plutt en le faisant voluer progressivement.
Exercices
EXERCICE 1
NOTION DE BASE DE DONNES
Quelles sont les diffrences majeures entre un fichier informatique et une base de donnes gre par un SGBD ? On peut lister ces points essentiels qui les diffrencient : Il nest pas ncessaire de connatre la mthode de stockage des informations sur le disque pour manipuler les donnes avec une base de donnes. Un fichier informatique simple nest pas conu pour effectuer une recherche dinformation par le contenu : pour retrouver le(s) enregistrement(s), on est oblig de parcourir tout le fichier. Les modifications de structure (ajout/suppression dun champ ou modification de sa taille) ncessitent de recrer un autre fichier et dy recopier les donnes. Une base de donnes contient en gnral plusieurs fichiers dont les enregistrements sont relis entre eux.
EXERCICE 2
RECHERCHE DICHOTOMIQUE
Donnez un algorithme intuitif simple de recherche dichotomique en utilisant une table dindex et une table accs direct. Soit V la valeur recherche, Ti le tableau dindex de taille n. On suppose que la table dindex contient les valeurs du champ indexes dans sa colonne 1 et les numros denregistrement correspondants dans sa colonne 2. Si le tableau est rduit un lment dont la valeur dans la premire colonne Ti[1,1] est diffrente de la valeur recherche alors la recherche est un chec sinon comparer llment du milieu z du tableau Ti avec la valeur V Si llment Ti[z,1] est gal la valeur, accder lenregistrement directement par son numro Ti[z,2] Si llment Ti[z,1] est infrieur la valeur recommencer avec la partie basse du tableau (de 1 z-1) Si llment Ti[z,1] est suprieur la valeur recommencer avec la partie basse du tableau (de z+1 n)
22
Chapitre
EXERCICE 3
LANGAGES DUN
SGBD
On veut supprimer tous les enregistrements qui contiennent la valeur 666 dans le champ catgorie. Utilise-t-on le langage de description de donnes ou le langage de manipulation de donnes ? Que se passerait-il si lon voulait augmenter la taille du champ catgorie. Le langage de description de donnes sintresse la modification de structure dune table dj cre ou la gestion des tables (cration/modification). Dans notre cas, on ne touche pas la structure, on supprime des enregistrements, donc des donnes de la table. On ne touche pas au dictionnaire de donnes. On utilisera par consquent le langage de manipulation de donnes du SGBD. Pour augmenter la taille du champ, on modifie cette fois la structure mme de la table, on utilise alors le langage de description de donnes.
EXERCICE 4
MODLES DE REPRSENTATION
Vous devez reprsenter lorganisation de donnes correspondant une classification scientifique despces doiseaux. Quel modle de donnes (hirarchique, rseau, relationnel, objet) choisiriez-vous ? Par nature, ce type de donnes est structur strictement de manire arborescente et cette structure reste assez stable dans le temps. Il est donc tout fait possible dutiliser un simple modle hirarchique. Un modle rseau ne sera pas utile en principe du fait de la structure arborescente des donnes. On peut galement utiliser les modles relationnel ou objet, mais il napporteront pas davantage dcisif dans ce cas (trs) particulier.
EXERCICE 5
Exercices
EXERCICE 6
EXERCICE 7
VUES EXTERNES
On utilise galement pour cet exercice la base de donnes exemple de vente de voitures. On considre trois types dutilisateurs de la base : 1. les clients ; 2. les vendeurs ; 3. le service comptabilit. Quelles sont les vues prvoir pour ces catgories dutilisateurs ? 1. Les clients ne doivent avoir accs en lecture quaux informations concernant les voitures en stock (non encore vendues). 2. Les vendeurs, sils grent galement le parc de voitures comme cest souvent le cas, peuvent avoir accs en lecture et en criture toutes les donnes (ventes, voitures, personnes). 3. Le service comptabilit peut avoir accs en lecture toutes les informations, mais ne peut modifier les informations concernant les voitures ou les personnes du fichier client.
24
Chapitre
EXERCICE 8
EXERCICE 9
XML
Pourquoi prfre-t-on utiliser XML plutt que HTML pour reprsenter les donnes provenant dune base de donnes ? Les donnes XML sont dites autodescriptives . Questce que cela signifie et par quel(s) dispositif(s) est-ce ralis ? Par nature, les donnes contenues dans une base de donnes sont structures. Le langage HTML a t conu pour dcrire la mise en forme dun texte sans considration de sa structure interne. Donc, il nest pas adapt si lon dsire conserver la structuration des donnes. Le langage XML a t prcisment cr pour dcrire la structure des donnes. Il est toujours possible de passer ensuite du langage XML au langage HTML par une feuille de style ; linverse nest pas possible. XML permet de reprsenter des structures de donnes diffrentes sous forme arborescente ; il est donc ncessaire de possder une description de la grammaire de la structure. Ce document accompagnateur dun fichier XML est une DTD, comme pour les fichiers XML classiques, ou plus commodment un schma XML. Un des avantages du schma est que lon peut utiliser les mmes algorithmes de parcours que pour le fichier XML.
Exercices
EXERCICE 10
26
Chapitre
Ce chapitre prsente la premire tape du processus de modlisation du monde rel, qui consiste recueillir les informations puis les transcrire sous une forme conduisant un passage ais au modle relationnel. On utilise cette fin le modle entit-association, dont les concepts et la mise en uvre sont prsents dans ce chapitre. Cette dmarche de modlisation est utilise depuis plus de vingt ans et prsente lintrt de proposer une mthode danalyse simple et efficace dans la majorit des cas. Au cours des dernires annes, la reprsentation utilisant le formalisme du modle entit-association est progressivement remplace par le langage de modlisation UML. Ce dernier apporte, en plus des avantages de la normalisation, de la disponibilit doutils graphiques logiciels ainsi que des possibilits tendues de description. Les bases de la notation UML sont abordes la fin de ce chapitre.
27
Dmarche danalyse
Remarque
Le terme dobjet du monde rel employ ici nest pas pris au sens de la programmation objet. Il sagit plutt de caractriser un regroupement logique de donnes. Un titre, un auteur, un diteur constituent un livre. Un nom, un prnom, un numro de Scurit sociale constituent une personne.
28
Chapitre
Les deux objets du monde rel la chambre et le client apparaissent clairement. On a identifi ici un double lien entre ces deux objets, cas assez frquent. Ensuite, on sintresse la caractrisation des liens : Une chambre peut navoir jamais t loue ni rserve. Un client est insr dans le systme dinformations partir du moment o il a effectu soit une rservation soit une location. Un client peut rserver ou louer plusieurs chambres. Une chambre peut tre rserve ou loue plusieurs fois, mais pas pendant la mme priode de temps. On rappelle que lon considre toujours une modlisation associe une priode de temps donne. Au dbut du processus, une chambre peut ne pas encore avoir t loue. Enfin, on dcrit les donnes des objets et des liens. Un client est caractris par son nom, son adresse et son numro de tlphone. Une chambre est caractrise par son numro, un nombre de places, son tarif journalier et la prsence ou non dun cabinet de toilettes. Une location est caractrise par une date de dbut, un nombre de jours et les consommations annexes (petits djeuners, tlphone). Une rservation est caractrise par une date de dbut, un nombre de jours et le versement dune avance ventuelle.
30
Chapitre
2.1 ENTITS
Les entits sont composes de champs de donnes que lon nomme attributs. Un attribut, ou un ensemble dattributs, doit tre choisi comme identifiant de lentit, avec pour objectif didentifier une occurrence (ou reprsentant) de cette entit. La notion didentifiant a les mmes proprits que la cl dans une relation qui sera introduite au chapitre 3. On reprsente une entit par un rectangle qui contient le nom de lentit et ses attributs. Lidentifiant est soulign ou prcd dun caractre # (voir figure 2.1). Figure 2.1
Entits chambre, attributs et occurrences.
Entit chambre Chambre
# IDChambre NombrePlaces Tarif 4 75
Chambre
176 1
Chambre
123 2 55
40
Le choix de lidentifiant nest pas toujours trivial. Il est parfois ncessaire dintroduire artificiellement un attribut supplmentaire afin de pouvoir disposer dun identifiant. Dans le cas de lhtel, il faudrait intgrer un attribut pour identifier un client (voir figure 2.2), dans la mesure o aucun des attributs issus de lanalyse ne permet didentifier de manire unique un client. Classiquement, une identification sans ambigut reposera sur un numro unique ; dans notre exemple, cest lattribut IDClient. Les identifiants peuvent tre composs par la juxtaposition de diffrents attributs. Par exemple, on peut identifier un client en juxtaposant les attributs nom+prnom+date_naissance+ville_naissance. En effet, il est peu probable que deux homonymes soient ns le mme jour dans la mme ville. Cependant, dans la pratique, il est recommand, autant que faire se peut, de choisir un seul attribut comme identifiant. En effet, il sera plus difficile de vrifier quun identifiant composite reste valide lorsque les donnes voluent. Cest pourquoi, quand cela est possible, il est indispensable de choisir un identifiant dont les contenus ne sont pas susceptibles dvoluer au fil du temps. On prfre identifier une personne par un numro de scurit sociale que par un numro de passeport qui a une dure de validit limite. Figure 2.2
Entit client.
Client
# IDClient Nom Adresse NumTlphone
2.2 ASSOCIATIONS
Les associations reprsentent les liens qui existent entre les entits. Elles sont composes le cas chant dattributs, bien que cela ne soit pas indispensable. Par consquent, il nest pas ncessaire de disposer dun identifiant pour une association. Lorsque les entits sont associes par deux, elles sont qualifies de binaires. Cependant, il est possible den associer plus de deux ; les associations sont alors non plus binaires, mais n-aires. Le nombre dentits associes sappelle le degr de lassociation. On reprsente une association par un ovale qui contient le nom de lassociation et ses attributs. Figure 2.3
Entits client et chambre relies par lassociation location.
Chambre
# IDChambre NombrePlaces Tarif
Client Location
DateDbut NombreJours # IDClient Nom Adresse NumTlphone
Il peut galement y avoir plus dune association entre deux entits ; cest le cas de lexemple de lhtel (voir figure 2.4). Les entits client et chambre sont relies par deux associations ayant des attributs diffrents : location et rservation. Figure 2.4
Entits client et chambre relies par les associations location et rservation.
Chambre
# IDChambre NombrePlaces Tarif
Client Location
DateDbut NombreJours # IDClient Nom Adresse NumTlphone
Rservation
DateDbut NombreJours
Enfin, il est possible de relier par une association une entit elle-mme. Si lon prend lexemple de la modlisation des liens de mariage entre personnes, on obtient une seule entit personne qui est associe elle-mme par lassociation est_mari_ (voir figure 2.5). Dans ce cas, on dit que lassociation est rflexive.
32
Client
# IDPersonne Nom Adresse NumTlphone
Est mari
DateMariage
2.3 CARDINALITS
Les cardinalits dcrivent les caractristiques de lassociation entre les entits. On utilise deux nombres qui reprsentent les valeurs minimales et maximales pour caractriser lassociation. Ces nombres modlisent le nombre doccurrences minimales et maximales des entits impliques dans lassociation. Par exemple, comme illustre sur la figure ciaprs (voir figure 2.6) , une association binaire sera caractrise entirement par quatre nombres. En effet, chaque entit participe de manire diffrente lassociation. Figure 2.6
Cardinalits dune association binaire.
Chambre
# IDChambre NombrePlaces Tarif
0,n Location
DateDbut NombreJours
Client 1,n
# IDClient Nom Adresse NumTlphone
Les cardinalits peuvent prendre les valeurs suivantes : De un un, note 1,1. Une brosse dents possde en thorie un (1) et un (1) seul propritaire. De un plusieurs, note 1,n. Un livre a au moins un (1) auteur ; il peut en possder plusieurs (n). On ne considre pas les ouvrages anonymes. Optionnel, note 0,1. Une personne est clibataire (0) ou marie (lgalement) une (1) autre personne au plus. De zro plusieurs, note 0,n. Un appartement peut tre libre (0) ou habit ventuellement par plusieurs habitants (n). Dans lexemple de lhtel prcdent, lanalyse pralable permet de dduire les proprits suivantes (voir figure 2.7) : Un client loue au minimum une (1) chambre ; il peut en louer plusieurs (n). La cardinalit est donc de 1,n. Une chambre peut tre loue plusieurs fois (n) et elle peut ne pas tre occupe (0). La cardinalit est donc de 0,n.
Figure 2.7
Entits client, chambre et association location avec cardinalit.
Chambre
# IDChambre NombrePlaces Tarif
0,n Location
DateDbut NombreJours
Client 1,n
# IDClient Nom Adresse NumTlphone
Remarque
Les cardinalits se notent diffremment dans le modle de Chen employ aux tats-Unis et dans celui utilis en Europe. Dans le modle europen, on dispose les cardinalits du ct de lentit concerne. La cardinalit 0,n dduite de une chambre peut tre loue plusieurs fois et elle peut ne pas tre occupe se trouve du ct de lentit chambre. Cette notation prsente lavantage dtre plus cohrente lors de lutilisation dassociations n-aires . Il ny a pas de changement dans lemplacement des cardinalits des entits associes.
34
Client
NumAch Nom ge Ville Sexe
1,n
Vente
DateVente Prix
Voiture 0,1
# NumVoit Marque Type Couleur
emprunte un livre. On en dduit les deux entits lecteur et livre lies par lassociation emprunte (voir figure 2.9). Un lecteur est caractris classiquement par son nom, son prnom et son adresse. Comme il ny a pas dattribut possdant les caractristiques dun identifiant pour lentit lecteur, on ajoute un attribut identifiant. Cet attribut supplmentaire est le numro de lecteur. noter que dans le monde rel, ce numro pourrait correspondre par exemple un numro de carte de lecteur. Un livre est caractris par son titre, son auteur, son numro ISBN, son diteur. Le numro ISBN est ici un identifiant pour lentit puisquil est unique. Lassociation emprunte a pour attribut la date demprunt.
Livre
Titre Auteur #ISBN diteur
Figure 2.9
Entits livre et lecteur lies par lassociation emprunte (sans cardinalits).
Emprunte
DateEmprunt
Lecteur
# NumLecteur Nom Prnom Adresse
Cet exemple simple permet de se poser quelques questions qui vont conduire une rorganisation du modle.
36
Ouvrage
#Cote ISBN
Emprunte
DateEmprunt
Lecteur
# NumLecteur Nom Prnom Adresse
Emprunte
DateEmprunt
Lecteur
# NumLecteur Nom Prnom Adresse
Auteur A crit
# NumAuteur Nom Prnom
Emprunte
DateEmprunt
Personne
# NumLecteur Nom Prnom Adresse
Est un exemplaire
Livre
Titre #ISBN diteur
A crit
On a identifi dans cette sous-section plusieurs cas qui ncessitent de rorganiser les entits obtenues lors dune premire analyse : Si lon repre lintrieur dune entit des attributs qui reprsentent un ensemble logique (mis en valeur dans lexemple par un dfaut didentifiant pour un livre), on spare ces attributs dans une entit supplmentaire. Si des attributs dans une mme entit possdent une smantique identique (auteurs, numros de tlphone multiples), on cre une entit supplmentaire pour sparer ces attributs. Cette entit sera associe celle dont proviennent les attributs lorigine. Si des entits ont la mme structure (et reprsentent le mme type dobjet), on les fusionne et lon conserve les associations qui existaient avant la fusion. On retrouvera ce processus de remise en question du modle un autre niveau, lors de ltape de normalisation qui est aborde au chapitre 3.
limination dassociations
On considre le cas dun acte dachat effectu sur Internet avec une carte bancaire. Une facture est rgle par une carte. On peut distinguer les deux entits facture et carte . Une facture est identifie par un numro de facture, et est constitue dun montant et dune date. Une carte bancaire est identifie par son numro, son type (Visa, MasterCard), sa date de validit et son propritaire. Les cardinalits entre les entits carte et facture sont de type 1-1 (une facture est paye par une et une seule carte) et 1-n (une
38
Chapitre carte peut servir rgler plusieurs factures). On peut utiliser une Ecarte qui permet damliorer la scurit de ces transactions. Une Ecarte est une carte virtuelle associe une vritable carte bancaire, valable pour une seule transaction. Les cardinalits deviennent alors de type 1-1 des deux cts : une Ecarte ne permet de rgler quune et une seule facture (voir figure 2.13). Figure 2.13
Entits carte et facture lies par lassociation rgle avec ses cardinalits.
Carte
#NumCarte Type DateValidit Propritaire
Facture
# NumFacture Montant DateFacture
Dans ce cas, lassociation rgle na plus lieu dtre puisquil sagit dune pure bijection : une facture correspond une Ecarte et une seule, et une Ecarte correspond un produit et un seul. On peut fusionner les deux entits carte et facture et liminer lassociation (voir figure 2.14). Figure 2.14
Entit facture_bis fusionne.
# NumFacture Montant DateFacture NumCarte Type DateValidit Propritaire
Fusion dassociations
Suivant le mme principe, il est possible de fusionner plusieurs associations ayant le mme rle smantique. Si lon considre la description de lactivit suivante, lie lexcution de morceaux de jazz en quartet. Pour un morceau donn, le premier musicien joue la partie de basse, le deuxime celle de batterie, le troisime celle de piano et le quatrime celle de saxophone (voir figure 2.15). Figure 2.15
Entits musicien et morceau lies par les associations basse, batterie, piano et saxophone.
Musicien
#NumMusicien Nom Prnom
0,n 0,n
Batterie
Piano
0,n 0,n
Basse
Comme il sagit de la mme activit (un musicien interprte un morceau), on peut remplacer toutes les associations par une association interprte. Lassociation interprte contiendrait lattribut instrument pour ne pas perdre linformation de linstrument associ (voir figure 2.16).
Figure 2.16
Entits musicien et morceau lies par lassociation interprte.
Musicien
#NumMusicien Nom Prnom
Morceau
# NumMorceau Titre
Remarque
Il en serait diffremment pour des associations entre ces deux entits qui exprimeraient un autre sens. Si lon considre lassociation compose ou arrange entre les entits musicien et morceau, il ne sagit pas de la mme activit que lassociation interprte : on ne fusionnera pas les associations dans ce cas.
Dans cette section, on a essay de porter un regard critique sur le modle conceptuel brut issu dune premire phase danalyse que lon a obtenue en utilisant les techniques nonces dans les sections prcdentes. Cette tape fait partie intgrante du processus itratif de constitution du modle par raffinements successifs. Le processus se poursuivra un autre niveau par la normalisation des relations dduites de ce modle. Cette partie sera traite au chapitre 3.
40
Chapitre
Remarque
UML est un formalisme de reprsentation. Il nest associ aucune mthode particulire comme peut ltre la mthode Merise qui associe une mthodologie et un langage de description.
Classes
Dans ce type de reprsentation les entits sont interprtes comme des objets et sont reprsentes par des classes. La description dune classe en UML comprend trois parties : le nom de la classe ; la description des attributs ; les mthodes associes lobjet. Cette section nutilise pas la notion de mthode spcifique lapproche objet. La description des attributs peut tre ralise de manire plus prcise. UML offre la possibilit de dcrire ce niveau le domaine de lattribut : jour : (lundi, mardi, mercredi, jeudi, vendredi, samedi, dimanche) Une classe est reprsente graphiquement par un rectangle spar en trois zones correspondant aux trois parties prcdentes (voir figure 2.17). Figure 2.17
Entit voiture reprsente par une classe UML.
Voiture
# NumVoit Marque Type Couleur
Nom de la classe
Attributs
Mthodes
Associations et multiplicit
Les classes sont relies par des associations identifies par leur nom. Si lassociation possde elle-mme des attributs, ils sont intgrs dans une classe dassociation. Lexpression des cardinalits est quasiment la mme en UML que pour le modle entit-association ; elles sont appeles multiplicit. UML permet de dfinir plus prcisment les cardinalits en utilisant les valeurs suivantes. 1. Obligatoire, un et un seul (peut scrire galement 1..1). *. Non obligatoire (peut scrire galement 0..n).
0..1. Non obligatoire restreint 1. 1..*. Obligatoire. 2..4. Obligatoire restreint de 2 4. Les associations sont matrialises par un trait entre les classes reprsentant les entits. Le nom de lassociation est inscrit au-dessus du trait. Dans le cas o lassociation possde des attributs, on utilise une classe dassociation sans nom qui contiendra les attributs. La classe dassociation est relie par un trait pointill (voir figure 2.18). Figure 2.18
Entits voiture et client lies par lassociation vente reprsentes par une classe UML.
Client
NumAch Nom ge Ville Sexe
Voiture
# NumVoit Marque Type Couleur
1..*
0..1
Vente
DateVente Prix
Remarque
Attention, la position des cardinalits dans un diagramme de type UML est inverse par rapport celle utilise dans un diagramme de type modle entit-association prsente dans ce chapitre. En effet, UML utilise la notation employe aux tats-Unis, mal adapte la reprsentation dassociation de degr suprieur aux associations binaires.
On peut dcrire plus finement lassociation en spcifiant un rle de lassociation pour chacune des classes associes. Cest--dire que lon distingue, du point de vue de chacune des classes impliques dans lassociation, la manire dont elle est associe une autre classe par un terme spcifique : le rle. Comme les cardinalits sont diffrentes pour chacune des classes impliques dans une association, on dispose alors dune description complmentaire. La notion de rle est surtout utile lorsquune classe est associe elle-mme. Par exemple, si lon considre les classes voiture et client (voir figure 2.19), du point de vue de la classe voiture, la classe client a le rle dacheteur. Du point de vue de la classe client, la classe voiture a le rle dune dpense. Ainsi, on note le nom du rle au mme emplacement que celui de lassociation (au-dessus du trait), mais du ct de la classe concerne. Figure 2.19
Classes voiture et client lies par lassociation vente avec des rles.
Client
NumAch Nom ge Ville Sexe
42
Chapitre tion. La correspondance qui est faite avec celle fonde sur le modle entit-association est la suivante : Une entit est reprsente par une classe. Une association est reprsente par une association. Une cardinalit est reprsente par une multiplicit. ce niveau dutilisation, les avantages quapporte la notation UML napparaissent pas clairement. Lintrt rside dans la possibilit dutiliser des outils logiciels. Ces derniers, partir du schma du modle conceptuel exprim en UML, automatisent, ou plutt assistent, le processus de passage au modle relationnel qui sera abord au chapitre 3. Lide terme est de gnrer automatiquement le langage SQL ncessaire, comme cela se fait en gnie logiciel o lon gnre le code du langage utilis. En revanche, lutilisation dUML prendra tout son sens pour une modlisation plus complexe utilisant par exemple le concept objet dhritage qui dpasse le cadre de cet ouvrage.
Rsum
Ce chapitre aborde lapproche de la modlisation, qui consiste dabord extraire les informations du monde rel puis en proposer une reprsentation formelle appele modle conceptuel. Il nexiste pas rellement de dmarche scientifique pour raliser cette tape. Elle est plutt constitue dun ensemble de techniques diverses qui permettent dapprhender la complexit du monde rel modliser et de la simplifier. Lanalyse du monde rel a pour but de pouvoir identifier les donnes qui interviennent dans le domaine considr et de les regrouper dans des objets. Ltape suivante consiste caractriser les liens qui les unissent. cette fin, on dcrit le systme modliser par des phrases simples de type sujet-verbe-complment , que lon peut classer en deux grandes catgories : celles qui dcrivent les objets du monde rel et les liens qui les unissent : le sujet et le complment sont reprsents par des entits (classes) et le verbe est reprsent par une association ; celles qui dcrivent la manire dont sont relis ces objets : on en dduira les cardinalits (ou multiplicits dans le cas dutilisation dUML) des associations. Les entits sont constitues de champs de donnes que lon nomme attributs . Pour identifier de manire unique les reprsentants dune entit, appels galement instance , un attribut (ou un ensemble dattributs) est choisi : on lappelle identifiant . Une fois les lments modliser identifis, leur reprsentation normalise recourt diffrents langages. Les deux types de formalismes les plus courants employs sont les suivants : Le modle entit-association. Il a fait ses preuves ; sa notation est trs intuitive et il est encore couramment utilis. UML (Unified Modeling Language). Il reprsente (probablement) lavenir, car il est soutenu par une communaut trs importante qui dpasse celle des bases de donnes. Il offre lavantage dtre bien adapt la modlisation de donnes complexes qui ncessitent une approche objet. Ni le modle entit-association, ni UML ne sont des mthodes danalyse ; il sagit dans les deux cas de simples formalismes de reprsentation.
Exercices
EXERCICE 1
IDENTIFIANT DUNE ENTIT
On considre lentit ci-aprs, qui dcrit des salles de cinmas. Les attributs de cette entit sont les suivants : nom de la salle ; nom du cinma ; ville du cinma ; nombre de places ; taille de lcran.
Que proposez-vous comme identifiant pour cette entit ? Si lentit dcrit des cinmas situs sur le territoire franais par exemple, le nom du cinma nest pas significatif : le Rex existe dans bon nombre de villes. Il en est de mme pour le nom de la salle : on peut imaginer sans peine que plusieurs cinmas possdent une salle John Cassavettes . Les autres attributs peuvent difficilement prtendre identifier une salle de cinma : le nombre de places et la taille sont communs beaucoup de salles ainsi que la ville. Si lon essaie la combinaison Nom du cinma & Nom de la salle, on court le risque que deux cinmas Camo disposent de la mme salle Franois Truffaut . Finalement, un identifiant possible serait la combinaison Nom du cinma & Nom de la salle Ville du cinma. Il est peu probable en effet que la mme ville dispose de plusieurs cinmas du mme nom encore que ce soit du domaine du possible. Dans ce cas, il est prfrable de crer un champ identifiant de toutes pices qui identifiera la salle. Classiquement, on utilisera un chiffre identifiant que lon peut nommer Numero_salle.
EXERCICE 2
44
Chapitre pourrait ventuellement utiliser la combinaison des deux attributs comme identifiant, car deux personnes de mme nom ont rarement le mme numro de tlphone, mais il est prfrable de crer un identifiant dans ce cas. Lentit pice comprend un titre, lauteur, le metteur en scne et le prix dune place (on suppose que toutes les places sont au mme prix). De mme que pour lentit spectateur, on a besoin de crer un identifiant pour la pice. Lassociation a pour attributs la date et le numro de sige. Ces attributs sont en effet caractristiques de laction dachat et non pas du spectateur ou de la pice (voir figure 2.20). Figure 2.20
Entits spectateur et pice lies par lassociation achat (sans cardinalits).
Spectateur
# Num Nom Tel
Achat
DateAchat NumSiege
Pice
# NumPiece Titre Auteur MetteurScene Prix
Si le prix des places varie pour chaque sance, il est non plus une caractristique de la pice, mais de lachat. Lattribut prix devient un attribut de lassociation achat. Il ny a jamais de solution unique en base de donnes. On aurait pu, par exemple, utiliser une entit billet lie aux deux entits spectateur et pice.
EXERCICE 3
Figure 2.21
Entits livre, ouvrage, personne lies par les associations emprunte, a_crit et est_un_exemplaire (sans cardinalits).
Ouvrage
#Cote ISBN
Emprunte
DateEmprunt
Personne
# NumLecteur Nom Prnom Adresse
Livre
Titre #ISBN diteur
A crit
Exercices
Est un exemplaire
Quelles questions faut-il poser aux utilisateurs de la base de donnes pour dterminer les cardinalits des associations ? Proposez une rponse ces questions et dduisez-en les cardinalits pour chaque entit. On doit dterminer pour chaque association les deux cardinalits minimales et maximales associes aux deux entits lies, puisquil sagit dassociations binaires. Il y aura donc quatre questions (se) poser par association. On pose ici les questions et on propose les rponses ; dans la vie relle, ce sont les utilisateurs de la base de donnes qui apporteraient les rponses (voir figure 2.22). Association est_un_exemplaire Pour dterminer les cardinalits du ct de lentit ouvrage : Peut-on avoir une fiche douvrage sans disposer du livre lui-mme dans la bibliothque ? Si cest le cas, la valeur minimale sera de 0, sinon elle sera 1. La valeur 1 est plus logique dans ce contexte, sauf si lon a rcupr le catalogue descriptif dun diteur. Une fiche douvrage peut-elle servir plusieurs livres ? Si cest le cas, la valeur maximale sera de n ; sinon, elle sera de 1. Cest le but ici de regrouper les informations douvrages communes plusieurs exemplaires. La cardinalit maximale choisie est de n. Pour dterminer les cardinalits du ct de lentit livre : Peut-on avoir un livre sans avoir de fiche ouvrage ? Si cest le cas, la valeur minimale sera de 0, ; sinon, elle sera de 1. Il parat clair que tout livre a une fiche ouvrage, moins quil ne soit juste identifi dans la bibliothque mais pas encore catalogu. Un livre peut-il avoir plusieurs fiches ouvrage ? Si cest le cas, la cardinalit maximale sera de n ; sinon, elle sera de 1. On peut supposer quun livre na quune fiche ouvrage. Association emprunte Pour dterminer les cardinalits du ct de lentit livre : Un livre peut-il navoir jamais t emprunt ? Si cest le cas, la valeur minimale sera de 0 ; sinon elle sera de 1. On choisit 0 : un livre peut ne rencontrer aucun succs. Un livre peut-il tre emprunt plusieurs fois ? Si cest le cas, la valeur maximale sera de n ; sinon elle sera de 1. On rappelle quune base de donnes modlise une activit sur une priode de temps. Un livre peut tre emprunt plusieurs fois mme si lon ne peut pas le prter deux personnes simultanment. On choisit n. Pour dterminer les cardinalits du ct de lentit personne : Une personne peut-elle ne pas avoir emprunt de livre ? Si cest le cas, la valeur minimale sera de 0 ; sinon, elle sera de 1. Une personne ne sinscrit la bibliothque que dans le but demprunter un livre ; elle en a donc au moins emprunt un. On choisit 1. Une personne peut-elle emprunter plusieurs livres ? Si cest le cas, la cardinalit maximale sera de n ; sinon, elle sera de 1. On choisit n : un lecteur nest pas limit lemprunt dun seul livre. Association a_crit Pour dterminer les cardinalits du ct de lentit ouvrage : Un ouvrage peut-il ne pas avoir dauteur ? Si cest le cas, la valeur minimale sera de 0 ; sinon, elle sera de 1. On choisit 1 : on suppose quil ny a pas de livre anonyme.
46
Chapitre Un ouvrage peut-il avoir plusieurs auteurs ? Si cest le cas, la valeur maximale sera de n ; sinon, elle sera de1 : un livre peut avoir plusieurs auteurs ; ctait dailleurs la motivation pour crer lentit auteur. On choisit donc n. Pour dterminer les cardinalits du ct de lentit personne : Une personne peut-elle ne pas avoir crit de livre ? Si cest le cas, la valeur minimale sera de 0 ; sinon, elle sera de 1. On choisit 0 : une personne peut ne pas tre un auteur. Une personne peut-elle tre lauteur de plusieurs livres ? Si cest le cas, la cardinalit maximale sera de n ; sinon, elle sera de1. On choisit n : un auteur peut crire plusieurs livres.
Ouvrage
#Cote ISBN 0,n
Figure 2.22
Entits livre, ouvrage, personne lies par les associations emprunte, a_crit et est_un_exemplaire (avec cardinalits).
Emprunte
DateEmprunt 1,n
Personne
# NumLecteur Nom Prnom Adresse
1,n
0,n
A crit
1,n
EXERCICE 4
Figure 2.23
Entits sminaire, thme, intervenant lies par les associations traite, est_responsable et intervient (avec cardinalits).
Th me # NumThme Libell 0,n
Sminaire Traite
1,1 1,n 1,1 # NumSminaire DateSem NbeJours NbeInscrits Prix
Anime
Salaire NbeHeures
Intervient
0,n # NumInter Nom Prnom
Est_responsable
Prime
0,n
Exercices
Quelle description pouvez-vous donner du lien entre les diffrentes entits partir des cardinalits ? Un sminaire traite dun thme et dun seul (cardinalit 1-1). Un thme peut tre trait par aucun sminaire ou par plusieurs (cardinalit 0-n). Un sminaire a un intervenant au minimum (cardinalit 1-n). Un intervenant peut intervenir dans plusieurs sminaires ou aucun (cardinalit 0-n). Un sminaire a toujours un responsable et un seul (cardinalit 1-1). Un intervenant peut ntre responsable daucun sminaire ou ltre de plusieurs (cardinalit 0-n).
EXERCICE 5
ASSOCIATION INUTILE
On dcrit une (partie de la) ralit biologique dun systme parasite-hte de la manire suivante : Un parasite utilise un et un seul type dhte. Un hte a un et un seul parasite. Dcrivez les entits et les associations que vous identifiez partir de cette description et dduisez-en les cardinalits associes. Que proposez-vous pour amliorer le schma ? On identifie aisment les entits parasite et hte comme les sujets ou les complments des phrases de type sujet-verbe-complment qui dcrivent le systme. Les cardinalits seront de type 1-1 de chaque ct : chaque hte est associ de manire unique un parasite et inversement. Les associations de cardinalits 1-1 de chaque ct sont gnralement inutiles : il est prfrable de les remplacer par une entit unique mme si lon perd en lisibilit au niveau du schma. On fusionne les entits parasite et hte en une seule entit cosystme (voir figure 2.24).
Figure 2.24
Entits parasitehte lies par lassociation utilise et fusion en une entit unique.
Parasite
# NumParasite NomPara 1,1
Utilise
Hte
1,1 # NumHte NomHte
cosystme
# NumHte NomHte NumParasite NomPara
48
Chapitre
EXERCICE 6
ASSOCIATION RFLEXIVE
On veut reprsenter les liens de nourriture entre des humains, des animaux et des vgtaux. Lide, partir des schmas dalimentation modliss, est de pouvoir dduire des chanes alimentaires de ce type : un homme mange un lapin qui mange des carottes . On pourrait diffrencier les humains/animaux des vgtaux et crer deux entits diffrentes. Mais comme les humains mangent des animaux et des vgtaux et que les animaux mangent galement dautres animaux et des vgtaux, il nest pas pertinent de les sparer pour reprsenter ce type dinformation. On utilise une seule entit humain_animal_vgtal qui est lie elle-mme par lassociation mange. Les cardinalits sont de type 0-n (voir figure 2.25) : Un humain_animal_vgtal peut manger ou ne pas en manger un autre (un vgtal ne mange pas ses congnres). Un humain_animal_vgtal peut tre mang ou ne pas tre mang par un autre.
vgtal
Figure 2.25
Entit humain_animal _vgtal lie par lassociation mange (avec cardinalits).
0,n
# IdHAV NomHAV
Mange
0,n
EXERCICE 7
ASSOCIATION TERNAIRE
partir de la base de donnes exemple de vente de voitures, on souhaite ajouter les informations concernant le vendeur qui a ralis la vente. Proposez une (ou plusieurs) modification(s) du modle entit-association labor prcdemment. Ajoutez les nouvelles cardinalits introduites par cette modification. On doit dfinir une nouvelle entit vendeur. En effet, les informations du vendeur sont indpendantes de celles des voitures ou des clients. On peut envisager le cas o lon ajoute les informations du vendeur comme attributs de lassociation vente, mais un vendeur est susceptible de raliser plus dune vente. On rpterait alors ces informations, identiques pour le mme vendeur, avec les risques dincohrence classiques. Lentit vendeur est lie lentit voiture mais galement lentit client. Ces liens sont crs par lopration de vente : Un vendeur vend une voiture. Un vendeur vend un client.
Exercices
Cette nouvelle entit sera lie aux deux autres par lassociation vente. On se trouve dans le cas o lassociation sera donc non plus de type binaire, mais ternaire. Les cardinalits associes aux entits voiture et client ne changent pas ; elles sont de type 0-n ( une personne peut acheter plusieurs voitures ou aucune ; une voiture peut tre vendue une seule fois ou jamais ). Pour une association de type ternaire, on emploie plus ou moins implicitement des cardinalits de type 0-n. Cela correspond du ct du vendeur une phrase un peu ambigu de la forme : un vendeur peut vendre aucune ou plusieurs voitures aucun ou plusieurs clients . Comme on utilise la notation europenne, on neffectue pas de changements du ct des entits client et voiture (voir figure 2.26). Figure 2.26
Entits voiture, client et vendeur lies par les associations ternaire vente (avec cardinalits).
Client
NumAch Nom ge Ville Sexe
0,n
Vente
DateVente Prix
Voiture 0,1
# NumVoit Marque Type Couleur
0,n Vendeur
# NumVendeur Nom Tl
Les associations ternaires sont parfois dlicates utiliser et difficiles reprsenter en UML sans contorsions. De plus, les cardinalits perdent de leur pertinence dans ce contexte. Il est souvent prfrable de remplacer cette association par une entit que lon relie aux autres par des associations binaires. Figure 2.27
Entits voiture, client, vendeur et vente lies par des associations binaire aprs transformation de lassociation ternaire vente en entit (avec cardinalits).
Client
NumAch Nom ge Ville Sexe
1,1
0,1
1,1 Vendeur
# NumVendeur Nom
1,n
Tl
50
Chapitre
EXERCICE 8
Exercices
Association rservation Lassociation a pour attribut la date de rservation et le nombre de jours de rservation. On a ajout un champ identifiant de la rservation NumRs. Il nest pas absolument ncessaire dun point de vue du modle, une association na pas besoin dun attribut identifiant, mais il facilitera la gestion. Association location Lassociation a pour attribut la date et le nombre de jours de location. On a ajout un champ identifiant de la location, NumLoc, pour les mmes raisons que prcdemment. Lattribut livraison indique si la livraison a t effectue, afin le cas chant de la facturer. Associations joue et ralise Les deux associations nont pas dattributs. Figure 2.28
Entits clients, film, personnel lies par les associations rservation, location, joue et ralise (sans cardinalits).
Location
# NumLoc NbeJourLoc DateLoc
Film Rservation
# NumRs NbeJourRs DateRs # NumFilm Titre Genre Prix NbDVD
Joue Personnel
# NumPers NomPers PrnomPers
Ralise
EXERCICE 9
REPRSENTATION AVEC
UML
partir du modle entit-association modlisant le club de location de DVD prcdent, faites sa reprsentation en utilisant UML. Proposez des cardinalits pour les associations en les justifiant. Les entits sont reprsentes par des classes UML. Les associations sont reprsentes par des associations UML. Les associations location et rservation qui possdent des attributs seront munies dune classe UML sans nom qui permet dutiliser ces attributs. Les cardinalits sont dduites des phrases suivantes : Location : Un client loue aucun ou plusieurs films (0..n). Un film est lou aucune ou plusieurs fois (0..n). Rservation : Un client rserve aucun ou plusieurs films (0..n).
52
Chapitre Un film est rserv aucune ou plusieurs fois (0..n). Joue : Une personne joue dans aucun ou plusieurs films (0..n). Un film a au moins un acteur (1..n). Ralise : Une personne ralise aucun ou plusieurs films (0..n). Un film a un et un seul ralisateur (1..1). Enfin, la notation des cardinalits est inverse par rapport au modle entit-association (voir figure 2.29). Figure 2.29
Reprsentation UML des entits clients, film, personnel lies par les associations reservation, location, joue et ralise (avec cardinalits).
Client # NumClient NomClient PrnomClient AdresseClient TlClient Compte
Film
0..n
0..n
Personnel
# NumPers NomPers PrnomPers
1..n
Joue Ralise
1..n
EXERCICE 10
AUTRE EXEMPLE
LE CAMPING LULIASTRU
Le camping lUliastru (lolivier sauvage), situ dans lextrme sud de la France, propose ses clients diffrents types de locations : des bungalows toile pour 350 /semaine, des caravanes pour 440 /semaine, des tentes pour 45 /jour. Les diffrentes formules offrent un quipement complet et appartiennent au camping. Il est galement possible de louer un emplacement tourisme la journe pour 28 /personne. Lensemble de ces locations sadresse un maximum de quatre personnes. Proposez un modle entit-association modlisant cette activit de gestion en fonction des lments de lnonc. Voici les phrases cls dduites de lnonc qui permettent de caractriser les entits et les cardinalits des associations du modle entit-association : Les clients louent des sjours, ils peuvent en louer plusieurs (1..n). Les sjours peuvent tre lous par un ou plusieurs clients (du moment que les priodes de location ne se chevauchent pas) (0,n).
Exercices
On en dduit les entits Sjour et Client, ainsi que lassociation Louer. La premire difficult que lon rencontre est lie la notion de temps. En effet, dans quelle entit doit tre stocke la notion de dure de la location ncessaire la gestion ventuelle des disponibilits ? Daprs lnonc, la dure de la location est fonction du type de location (bungalows toile : 7 jours, caravanes : 7 jours, tentes : 1 jour, emplacements tourisme : 1 jour). Le client ne peut donc pas choisir la dure minimum ; cette dernire est dtermine en fonction du type de location. Par consquent, il convient de stocker lattribut duree_mini modlisant la dure de location minimum dans lentit location. Lunit commune lensemble des locations pour la facturation est la journe ; les dures sexpriment alors en nombre de jours. La seconde difficult est lie la notion de personne. Comment intervient-elle dans le schma conceptuel ? Tout dabord, remarquons que, daprs la premire phrase cl, un client peut reprsenter plusieurs personnes car il peut louer plusieurs locations. Par consquent, le moyen dintgrer efficacement la limite de quatre personnes et les quantits ncessaires la facturation des diffrents types de location consiste en lajout de lattribut quantit dans lassociation Louer. Le client du modle reprsente la personne physique que lon facture. Finalement, voici le MCD de cette activit de gestion : Sjour(Type, Dure_mini, Prix_ttc) Client(ID, Nom, Prnom, Adresse, Ville, CP, Tlphone) Louer(quantit, date_dbut) La date de dbut de location dpend la fois du client et de la location ; cest la raison pour laquelle elle apparat dans lassociation Louer. La date de fin dune location est calcule partir de la dure minimale et de la quantit loue en fonction de la date de dbut de location ; cest la raison pour laquelle il est inutile de la stocker.
54
Chapitre
Approche relationnelle
1. Concepts .................................56 2. Oprations du modle relationnel ................................60 3. Passage du modle conceptuel au relationnel ...........................68 4. Normalisation ..........................70 5. Logique du premier ordre et base de donnes ...................76 Exercices 1. Relation, degr, cardinalit ........82 2. Cl dune relation .....................82 3. Contraintes dintgrit ...............83 4. Opration ensembliste ..............83 5. Projection ................................84 6. Restriction ................................85 7. Jointure ...................................85 8. Autre jointure ...........................87 9. Calcul sur des agrgats .............88 10. Passage du modle entit-association au relationnel ...89 11. Passage du modle entit-association au relationnel II ........................90 12. Normalisation ..........................91 13. Normalisation II ........................92 14. Normalisation III .......................93
Lapproche relationnelle prsente par E. F. Codd possde un fondement mathmatique rigoureux qui lui assure sa robustesse : le modle relationnel est de loin le plus rpandu dans le monde des bases de donnes. Ce chapitre prsente le concept de relation fondamental du modle relationnel, ainsi que les oprations qui lui sont associes. Puis on aborde les mthodes qui permettent de passer du modle conceptuel vu au chapitre prcdent (entitassociation ou UML) un ensemble de relations. La qualit des relations ainsi produites est contrle par leur conformit aux trois premires formes normales. Ce processus peut conduire une rorganisation des relations sans perte dinformation. La manire de rsoudre les incohrences laide de la forme normale de Boyce-Codd est galement prsente. Enfin, le lien entre les bases de donnes et la logique du premier ordre est rapidement expos, afin de dcrire la mthode dinterrogation de base de donnes par QBE (Query By Example) qui en dcoule.
55
Concepts
Cette section expose la notion de relation et la terminologie qui lui est associe. On prsente ensuite les diffrents types de contraintes associes au contenu dune relation, ainsi que la notion de cl dune relation.
Cet ensemble de couples de valeurs lies entre elles, que lon nomme tuples dans le modle relationnel, reprsente la relation entre les lments appareil et couleur. Un tuple est aussi dsign par les termes nuplets ou enregistrements . On dsigne galement les lments constitutifs de ces couples par les termes attributs ou champs . On peut crire formellement la relation de la manire suivante : ma_cuisine(appareil, couleur). Cette criture reprsente le schma relationnel de la relation ma_cuisine. Les valeurs nonces prcdemment pour les champs reprsentent leurs domaines, cest-dire les ensembles de toutes les valeurs possibles pour un champ. Une relation est totalement dcrite par : le schma relationnel ; les domaines des diffrents champs ; les tuples qui la constituent. Le nombre de champs de la relation sappelle son degr de la relation. Ici, la relation ma_cuisine est de degr 2. Le nombre de tuples se nomme la cardinalit de la relation. La relation ma_cuisine est de cardinalit 4. Attention, il ne sagit pas de la mme cardinalit que pour le modle entit-association vu prcdemment. On reprsente une relation par une table, correspondant la notion de tableau. Les tuples correspondent aux lignes et les colonnes aux champs de la relation. Voici sous forme de table une reprsentation de lexemple prcdent (voir figure 3.1). Dans le modle relationnel, la relation est llment fondamental. Toutes les oprations sur une ou plusieurs relations retourneront une relation. Un ensemble de relations relies entre elles par des liens smantiques constitue une base de donnes.
56
Les dpendances fonctionnelles expriment la relation de hirarchie qui existe entre les champs. On considre lexemple de table suivant (voir figure 3.2), qui correspond la relation Lecteur(Numero_carte, Nom, Age, Ville, Etablissement). Cet exemple modlise les lecteurs dune bibliothque.
Approche relationnelle 57
Figure 3.2
Relation Lecteur.
Numero _carte 1 2 3 4 5 6 7 8 9 10 11 12
Nom Henri Stanislas Henriette Dominique Isabelle Olivier Henri Jerome Laurence Christian Antoine Laurence
Age 10 34 44 19 56 51 98 23 34 41 16 34
Ville Paris Paris Lyon Nancy Nancy Marseille Paris Nancy Bordeaux Paris Marseille Paris
Etablissement Universit Sorbonne Universit Jussieu CHU Bron Universit Poincar INPL Universit Saint Charles Universit Sorbonne INPL Universit Victor Segalen Ecole Normale Suprieure Universit Saint Charles Universit Jussieu
Si lon examine les donnes, on remarque quil ne peut y avoir de dpendances fonctionnelles entre les couples de champs (Ville, Etablissement) et les champs (Nom, Age). Il existe un enregistrement (Laurence, 34) pour lequel les valeurs des champs (Nom, Age) correspondent deux valeurs diffrentes de (Ville, Etablissement). En revanche, on sait que, dans la ralit, un tablissement est situ dans une ville et une seule (on le suppose pour cet exemple). Cela signifie quil existe une relation de dpendance entre les champs Etablissement et Ville. Le contenu des champs Ville et Etablissement des enregistrements de notre relation se conforment cette relation de dpendance. A une valeur donne de Etablissement correspond bien une valeur unique de Ville. La valeur du champ Numero_carte est unique pour chacune des personnes. On constate que ses valeurs sont identifiantes pour tous les autres champs de la relation. Chaque champ dpend fonctionnellement du champ Numero_carte. Ses valeurs sont uniques et jamais vides : cest une cl candidate. Dans cet exemple, cest la seule cl possible car les autres champs nont jamais de valeur unique. Le champ Numero_carte est choisi comme cl primaire de la relation.
Remarque
Tous les champs qui ne font pas partie dune cl candidate dune relation possdent des dpendances fonctionnelles avec cette cl.
Les dpendances entre les champs reprsentent les liens entre les diffrents lments du monde rel. On rappelle quelles ne peuvent tre dduites du contenu de la relation, mme si cela peut constituer un point de dpart. Elles sont donc dtermines durant la phase prcdente danalyse du monde rel. Il est possible en revanche de vrifier si les enregistrements prsents dans la relation se conforment ces dpendances. La dtermination des dpendances fonctionnelles entre les champs est fondamentale pour ltape de normalisation, traite la section Normalisation . Elles sont galement la base de la mthode dite de la relation universelle , qui sera aborde dans la section Normalisation .
58
Chapitre
Approche relationnelle 59
Union
Lopration dunion consiste en la mise en commun des enregistrements de chaque relation. Les enregistrements identiques ne sont intgrs quune seule fois. Dans lexemple ci-aprs (voir figures 3.3 et 3.4), le tuple dont la valeur du champ Numero_carte vaut 3 ne sera pas dupliqu. Lunion est reprsente par le caractre . Cette opration sert typiquement la consolidation de donnes de mme type provenant de diffrentes sources. Figure 3.3
Relations Lecteur_1et Lecteur_2.
60
Lecteur_1 Lecteur_2
Numero_carte 1 2 3 4 5 Nom Henri Stanislas Henriette Dominique Isabelle Age 10 34 44 19 56 Ville Paris Paris Lyon Nancy Nancy Etablissement Universit Sorbonne Universit Jussieu CHU Bron Universit Poincar INPL
Diffrence
Lopration diffrence consiste dsigner les enregistrements qui appartiennent une relation sans appartenir lautre. La diffrence est reprsente par le caractre (voir figure 3.5). Attention, cette opration nest pas symtrique ; le rsultat de lopration Lecteur_1 Lecteur_2 est en gnral diffrent de Lecteur_2 Lecteur_1. Elle permet par exemple dliminer des enregistrements dune relation par rapport une liste. Figure 3.5
Diffrence des relations Lecteur_1 et Lecteur_2.
Lecteur_1 Lecteur_2
Numero_carte 1 2 Nom Henri Stanislas Age 10 34 Ville Paris Paris Etablissement Universit Sorbonne Universit Jussieu
Intersection
Lopration intersection peut se dduire de la prcdente ; elle dsigne les enregistrements qui sont communs aux deux relations. Lintersection est reprsente par le caractre (voir figure 3.6). Elle permet de trouver les lments communs deux relations. Figure 3.6
Intersection des relations Lecteur_1 et Lecteur_2.
Lecteur_1 Lecteur_2
Numero_carte 3 Nom Henriette Age 44 Ville Lyon Etablissement CHU Bron
Produit cartsien
Le produit cartsien permet la combinaison des enregistrements de deux relations sans tenir aucun compte du contenu des donnes. Les relations nont donc pas besoin davoir la mme structure. Le caractre reprsentant le produit cartsien est X .
Approche relationnelle 61
Figure 3.7
Relations ma_cuisine et musicien.
ma_cuisine(Appareil, Couleur)
Appareil Rfrigrateur Robot Cuisinire Couleur rouge mauve jaune
musicien(Nom, Instrument)
Nom Jaco Pastorius Bill Evans Instrument Basse lectrique Piano
Lexemple a t choisi de manire montrer que les relations ne ncessitent pas de rapports entre elles pour faire un produit cartsien. Combiner des appareils de cuisine et des musiciens na aucun sens dans la ralit (voir figures 3.7 et 3.8). Figure 3.8 Le_resultat(Appareil, Couleur, Nom, Instrument) = ma_cuisine(Appareil, Couleur) X musicien(Nom, Instrument) Produit cartsien
des relations ma_cuisine et musicien.
Nom Jaco Pastorius Bill Evans Jaco Pastorius Bill Evans Jaco Pastorius Bill Evans
Instrument Basse lectrique Piano Basse lectrique Piano Basse lectrique Piano
Lecteur_proj(Nom, Ville)
Nom Henri Stanislas Ville Paris Paris
62
Chapitre
Nom Henriette Dominique Isabelle Olivier Henri Jerome Laurence Christian Antoine Laurence
Ville Lyon Nancy Nancy Marseille Paris Nancy Bordeaux Paris Marseille Paris
Intuitivement, dans une reprsentation de type table, on conserve uniquement les colonnes sur lesquelles la projection est faite.
Slection ou restriction
La slection consiste extraire les enregistrements de la relation. On utilise des critres pour caractriser les enregistrements slectionns. Voici la relation obtenue partir de la relation Lecteur en slectionnant les enregistrements dont le contenu du champ Ville est Marseille (voir figure 3.10). La structure de la relation rsultat est la mme que celle de la relation de dpart. Figure 3.10
Slection sur la relation Lecteur.
Intuitivement, dans une reprsentation de type table, on conserve uniquement les lignes rpondant au critre.
Jointure
La jointure est lopration fondamentale de lalgbre relationnelle qui permettra dexprimer le sens du lien entre les relations dans le monde rel. La liaison entre les relations seffectue par le contenu commun dun champ. Lopration de jointure peut tre vue comme une slection des enregistrements obtenus par le produit cartsien des relations, dont les contenus du champ sur lequel on effectue la jointure sont gaux. On lappelle dans ce cas une quijointure. Les champs dont on compare les contenus sont nomms champs de jointure. On considre les deux relations Lecteur_bis(Numro_carte, Nom, Num_Etablissement) et Etablissement(Num_Etablissement, Ville, Nom_Etablissement) dont le contenu suit (voir figure 3.11).
Approche relationnelle 63
Figure 3.11
Relations Lecteur_bis et Etablissement.
Mme si lon ne dispose pas du modle conceptuel associ, on constate que lon peut relier ces deux relations par le champ Num_Etablissement. Les informations concernant ltablissement de la relation Lecteur_bis sont stockes dans la relation Etablissement dont la cl est le champ Num_etablissement. Pour obtenir la liste des lecteurs ainsi que les informations concernant leur tablissement, on effectue une jointure entre ces relations sur le champ Num_Etablissement (voir figure 3.12). Figure 3.12
Jointure des relations Lecteur_bis et Etablissement sur le champ Num _Etablissement.
Le champ Num_Etablissement y figure deux fois car une occurrence vient de la relation Lecteur et lautre de la relation Etablissement. Afin de ne conserver quune valeur du champ Num_Etablissement, on utilise lopration de jointure naturelle (voir figure 3.13). Figure 3.13
Jointure naturelle des relations Lecteur_bis et Etablissement sur le champ Num _Etablissement.
64
Chapitre On peut considrer lopration de jointure comme une slection sur le produit cartsien des deux relations. On ne conserve que les lignes dont le contenu du champ sur lequel seffectue la jointure est gal. Les lignes grises sont celles qui sont slectionnes lors dune jointure (voir figure 3.14). Figure 3.14
Produit cartsien des relations Lecteur_bis et Etablissement.
On verra au chapitre consacr SQL que cest lune des manires dcrire une jointure.
Jointure externe
La jointure externe nest pas rellement une opration de base de lalgbre relationnelle. Elle est cependant ncessaire pour pouvoir rpondre plus facilement des questions du type Quels sont les tablissements qui nont pas de lecteurs ? Il sagit dune opration de jointure tendue qui inclut dans le rsultat les lignes nayant pas de correspondance sur le contenu du champ de jointure. Voici le rsultat de la jointure externe de la relation Etablissement avec la relation Lecteur sur le champ Num_Etablissement (voir figure 3.15). On met en correspondance les valeurs du champ Num_Etablissement de toutes les lignes de la relation Etablissement avec celles de la relation Lecteur.
Approche relationnelle 65
Figure 3.15
Num_Etablissement_1 1 2 3 4
Nom _Etablissement Universit Jussieu CHU Bron Universit Poincar Universit Sorbonne
Ici, les valeurs 3 et 4 du champ Num_Etablissement_1 provenant de la relation Etablissement nont pas de correspondance dans la relation Lecteur. Les lignes sont tout de mme incluses dans le rsultat mais les champs provenant de la relation Lecteur prennent la valeur NULL. Cette valeur signifie que le champ ne contient pas de valeur. Pour rpondre la question Quels sont les tablissements qui nont pas de lecteurs ? , il nous suffit de slectionner les lignes qui contiennent la valeur NULL, par exemple dans le champ Numro_carte. Dans un second temps, on effectue une projection sur le champ Nom_Etablissement (voir figure 3.16). Figure 3.16
Slection et projection sur la jointure externe des relations Lecteur_bis et Etablissement sur le champ Num _Etablissement.
Etablissement_jointext_Lecteur_selproj(Nom_Etablissement)
Nom _Etablissement Universit Poincar Universit Sorbonne
La jointure externe nest pas une opration symtrique. Lopration inverse, cest--dire la jointure externe de la relation Lecteur avec la relation Etablissement sur le champ Num_Etablissement donne dans ce cas le mme rsultat quune jointure naturelle. En effet, toutes les valeurs du champ Num_Etablissement de la relation Lecteur ont une correspondance dans la relation Etablissement. Cest ce que lon souhaite puisque la relation Etablissement fait office de relation de rfrence pour le champ Num_Etablissement de la relation Lecteur. Lopration de jointure externe peut tre utilise pour dtecter ce type dincohrence.
66
Chapitre fonctions de calculs ont t dfinies afin de rpondre ce besoin. Elles seront dtailles au chapitre sur SQL . On considre la relation La_boutique(Num_facture, Article, Prix, Quantite) [voir figure 3.17]. Figure 3.17
Relation La_boutique.
On suppose que lon veut exemple trouver le total pour chaque facture en multipliant le prix par la quantit. Il est alors possible dajouter un champ Total dont le contenu sera calcul par lexpression Prix Quantit (voir figure 3.18). Figure 3.18
Relation La_boutique avec le champ calcul Total.
Il est galement possible deffectuer des oprations statistiques globales dun champ, comme les calculs du nombre denregistrements, de moyenne, de maximum, de minimum. On obtient dans ce cas une nouvelle relation rduite une ligne et une colonne qui contient la valeur calcule. En effet, le rsultat dune opration sur une relation est toujours une relation (voir figure 3.19). Figure 3.19
Moyenne des prix de la relation La_boutique.
La_boutique_moyenne(Moyenne_Prix)
Moyenne_Prix 9
De mme, les oprations de base de lalgbre relationnelle ne permettent pas de rpondre des questions du type : Combien trouve-t-on de personnes par ville ? La solution consiste alors regrouper les enregistrements qui contiennent les mmes valeurs dans le champ Ville : ce regroupement sappelle un agrgat. On applique ensuite chaque sousrelation ainsi constitue une opration statistique, dans notre cas lopration de comptage (voir figure 3.20). Figure 3.20
Agrgat par ville de la relation La_boutique.
Lecteur_parville(Ville, Nombre)
Ville Bordeaux Lyon Nombre 1 1
Approche relationnelle 67
Nombre 2 3 5
Figure 3.21
1,n
Vente
DateVente Prix
Voiture 0,1
# NumVoit Marque Type Couleur
partir du modle entit-association de la base de donnes casse labor au chapitre prcdent (voir figure 3.21), on obtient trois relations en appliquant ces rgles. Les entits voiture et personne deviennent les relations voiture(NumVoit, Marque, Type, Couleur) et personne(NumAch, Nom, Age, Ville, Sexe). Lassociation se transforme en relation vente(DateVent, Prix, NumAch, NumVoit).
68
Chapitre
3.2 CAS PARTICULIER DES ASSOCIATIONS AVEC UNE CARDINALIT DE TYPE 1-1
Considrons le cas du modle entit-association qui reprsente lactivit dorganisation de sminaires dcrite trs succinctement de la manire suivante : Figure 3.22
Modle entitassociation de la base de donnes animation de sminaire.
Anime
Salaire NbeHeures
Un sminaire est anim par un ou plusieurs intervenants. Un sminaire ne possde quun seul responsable.
Seminaire
# NumSeminaire DateSem NbeJours Prix 1,1
1,n
Intervenant
0,n # NumInter NomInter TelInter
Est responsable
Prime
0,n
Deux associations existent entre les deux entits Sminaires et Intervenant : Anime et Est_responsable. Les attributs utiliss pour les entits et les associations sont visibles sur le modle entit-association (voir figure 3.22). Si lon applique les rgles gnrales nonces ci-dessus, on obtient quatre relations : Intervenant(NumInter, NomInter, TelInter) Seminaire(NumSem, DateSem, Prix, NbeJour) Anime(NumInter, NumSem, NbeHeure, SalaireHor) Est_responsable(NumInter, NumSem, Prime) Lune des cardinalits de lassociation Est_responsable est de type 1-1, car un sminaire possde un responsable et un seul. De cette dernire proprit, on peut en dduire que la cl de la relation Est_responsable nest pas minimale. En effet, pour la relation Est_responsable lidentifiant du sminaire dtermine celui du responsable. En dautres termes, on identifie une dpendance fonctionnelle entre les champs NumSem et NumInter pour la relation Est_responsable. On choisit le champ NumSem comme cl de la relation Est_responsable. La relation Est_responsable devient ainsi Est_responsable(NumSem, NumInter, Prime). Les relations Est_responsable et Seminaire ont alors la mme cl, et il est possible de les regrouper. On obtient la relation Seminaire_Res(NumSem, DateSem, Prix, NbeJour, NumInter, Prime). Il sest produit une sorte de glissement des lments de lassociation Est_responsable vers lentit Seminaire. On peut en dduire une rgle complmentaire des rgles gnrales prcdentes : Lorsque lassociation entre deux entits comprend une cardinalit de type 1-1, on ne cre pas de relation pour lassociation. Les champs de lassociation seront intgrs la
Approche relationnelle 69
relation cre pour lentit qui est associe avec la cardinalit 1-1. La cl de cette relation est toujours celle de lentit.
Remarque
Lun des intrts dUML est de disposer de logiciels capables, partir dun modle conceptuel exprim en UML, de dduire automatiquement les relations en utilisant les rgles nonces ici. Dautres rgles apparatraient dans le cas de lutilisation des extensions objet que propose UML ; cependant ces possibilits dpassent le cadre de cet ouvrage.
Normalisation
Le modle relationnel procure des outils destins tester la qualit et la cohrence des relations dans un schma relationnel cr ltape prcdente. Cette tape, appele normalisation, permettra de vrifier certaines proprits des relations et le cas chant de les transformer. On aborde dans cette section les trois premires formes normales qui suffisent dans la plupart des cas et qui permettent une dcomposition du schma relationnel sans perte dinformation. La forme normale de Boyce-Codd qui dtecte dautres incohrences, mais propose une dcomposition avec perte dinformations de dpendance, est prsente la fin de la section. Il existe dautres formes normales la quatrime et la cinquime , qui ne sont pas prsentes dans cet ouvrage : ces dernires sont parfois difficiles apprhender et les trois premires formes normales suffisent en gnral pour obtenir un schma relationnel de qualit. La normalisation dun schma relationnel suggre une autre mthode pour obtenir un ensemble de relations. On part dune relation unique qui contient tous les champs, que lon appelle la relation universelle. laide des dcompositions proposes par la mise en forme normale et du graphe des dpendances fonctionnelles des champs de cette relation, on parvient par raffinements successifs un ensemble de relations normalises. Cette mthode de la relation universelle est toutefois assez difficile manipuler ds que lon dpasse une taille critique du nombre de champs.
70
Une solution pour rsoudre ce problme est de dcomposer le champ Auteurs en Auteur_1, Auteur_2, Auteur_3, Auteur_4, etc. Ainsi, la relation est bien en premire forme normale. Lennui est que lon ne sait pas lavance le nombre dauteurs que peut possder une publication, et le problme consiste donc savoir combien de champs ajouter. La solution plus correcte, mais galement plus lourde mettre en uvre, est de dcomposer cette relation en trois relations : Publication(NumPubli, Titre), Auteur(NumAuteur, Nom, Prenom) et EstEcrite(NumPubli, NumAuteur). Ces trois relations sont la reprsentation de la ralit une publication est crite par des auteurs . Elle se modlise par deux entits Publication et Auteur relies par lassociation EstEcrite, comme on la vu au chapitre 2, Analyse du monde rel . On obtient alors le rsultat suivant (voir figure 3.24). Figure 3.24
Dcomposition de la relation Publication en trois relations.
Publication(NumPubli, Titre)
NumPubli 13490 21322 45333 Titre
Le vin et lavenir
Bire et progrs social Le champagne et la France
Approche relationnelle 71
EstEcrite(NumPubli, NumAuteur)
NumPubli 13490 13490 13490 21322 21322 21322 45333 45333 45333 NumAuteur 1 2 3 4 1 5 6 7 5
On doit alors effectuer des jointures sur les diffrentes relations afin de reconstituer linformation dans son intgralit. Cette dcomposition en trois relations se fait sans perte dinformation.
La cl est constitue des champs Article et Fournisseur. Or, il y a une relation de dpendance entre le champ Fournisseur, qui est une partie de la cl, et le champ Adresse. On dcompose alors la relation pour liminer la redondance ainsi cre. La nouvelle relation
72
Chapitre aura pour cl la partie de la cl de la relation dorigine dont dpendent fonctionnellement les autres champs. Dans cet exemple, il sagit du champ Fournisseur. Les autres champs dpendants constituent le reste de la relation. Il sagit ici du champ Adresse. On obtient alors le rsultat suivant (voir figure 3.26). Figure 3.26
Dcomposition de la relation Produit pour passer en deuxime forme normale.
Fournisseur(Fournisseur, Adresse)
Fournisseur SOGENO ARTIFACT LEMEL Adresse Paris Lille Paris
Comme prcdemment, il est ncessaire de faire une jointure pour reconstituer linformation. La dcomposition en deux relations se fait sans perte dinformation.
Remarque
Si la cl dune relation est atomique, cest--dire compose dun seul champ, elle est naturellement en deuxime forme normale.
Approche relationnelle 73
Figure 3.27
Relation Baladeur.
La cl de cette relation est un numro, NumBal, car il peut y avoir dans notre stock plusieurs baladeurs de mme marque, de mme type et de mme couleur. Les marques dposent les noms des objets quelles fabriquent de faon les identifier sur le march. Il existe donc une dpendance fonctionnelle entre le champ Type (qui nappartient pas la cl) et le champ Marque (qui nappartient pas la cl). On dcompose la relation en en crant une nouvelle qui a pour cl le champ dont dpendent les autres champs constituant la dpendance transitive. Il sagit dans ce cas du champ Type. Les autres champs de la nouvelle relation sont composs des champs qui en dpendent fonctionnellement : ici, le champ Marque (voir figure 3.28). Figure 3.28
Dcomposition de la relation Baladeur pour passer en troisime forme normale.
Baladeur_type(Type, Marque)
Type Ipod MZ-RH910 Zen Marque Apple Sony Creative
Comme prcdemment, il est ncessaire de faire une jointure pour reconstituer linformation dans son intgralit. La dcomposition en deux relations se fait sans perte dinformation.
Remarque
Les deuxime et troisime formes normales traitent des problmes diffrents. Lordre dans lequel on les considre pour la normalisation, mise en deuxime forme puis en troisime forme normale, est plutt li lhistorique qu une ncessit relle.
74
Chapitre
La cl de cette relation est constitue par les champs Marque et Produit. En effet, un produit est fabriqu sous licence par la socit ImaginR et a donc le mme nom que celui propos par la socit Olympus. Il est alors ncessaire dutiliser les deux champs pour constituer la cl. Pour se dmarquer les unes des autres, les socits utilisent des couleurs personnalises destines identifier la marque : Philips, le blanc et lorange ; Olympus, le rouge et le noir ; ImaginR, le gris. On a donc une relation de dpendance entre ces deux champs. La relation est en troisime forme normale, mais elle nest pas en forme de Boyce-Codd. Plusieurs dcompositions sont possibles : par exemple Dictaphone(Marque, Type, Prix) et Marque_coul(Couleur, Marque). Mais cette dcomposition gnre des tuples non dsirs au moment de la jointure. Quant la dcomposition Dictaphone(Type, Prix, Couleur) et Marque_coul(Couleur, Marque), elle permet de reconstituer linformation de dpart par une jointure sur le champ Couleur (voir figure 3.30). Figure 3.30
Relation Dictaphone dcompose pour passer en forme de Boyce-Codd.
Approche relationnelle 75
Prix 69 79
Marque_coul(Couleur, Marque)
Couleur Blanc Noir Gris Rouge Marque Philips Olympus ImaginR Olympus
On utilise classiquement des variables (x,y dans notre exemple) et des constantes dans les expressions. Les prdicats peuvent tre associs par des connecteurs logiques : (et), (ou), (non), (implique). Le domaine de discours des variables sexprime partir des quantificateurs (quel que soit) et (il existe). Ce formalisme simple permet dexprimer des proprits comme celle-ci : si x est mang par y ou y est mang par x, ils appartiennent tous deux la mme chane alimentaire .
76
Chapitre
x y mange(x,y) mange(y,x) meme_chaine_alimentaire(x,y)
Cette formule peut se rcrire en utilisant des rgles de dduction dans le but daboutir un ensemble de clauses plus aises vrifier : cest sur ce principe que fonctionne la dmonstration automatique de thormes. La diffrence entre un (bon) mathmaticien et un programme est videmment que le mathmaticien va choisir demble la srie de rgles adapte pour parvenir plus rapidement au rsultat. Voici une possibilit de rcriture de la formule prcdente.
a b donne a b x y ((mange(x,y) mange(y,x)) (meme_chaine_alimentaire(x,y))) (a b) donne a b x y (mange(x,y) ? mange(y,x)) (meme_chaine_alimentaire(x,y))) (a b) c donne (a c) (b c) x y ((mange(x,y) meme_chaine_alimentaire(x,y)) meme_chaine_alimentaire(x,y))) a b donne a b x y ((mange(x,y) meme_chaine_alimentaire(x,y)) meme_chaine_alimentaire(x,y)) ((mange(y,x)
(mange(y,x)
On obtient ainsi deux clauses relies par , on lappelle clause de Horn qui reprsente la fin de la rcriture :
mange(x,F(x)) meme_chaine_alimentaire(x,F(x))) mange(F(x),x) meme_chaine_alimentaire(x, F(x))
Dans notre cas, on peut sassurer assez facilement que ces deux implications sont toujours vrifies pour le domaine du discours.
Cela signifie que les valeurs des champs Marque et Type des tuples de la relation voiture sont reprsentes par les variables m et t. Le signe _ reprsente nimporte quelle valeur des autres champs NumVoit et de Couleur.
Approche relationnelle 77
Lexpression afficher le type des voitures de couleur rouge , qui est une projection et une slection sur la relation voiture, peut scrire sous la forme :
{ (t) | voiture(_,_,t,rouge) }
Cette fois, on utilise une constante, rouge, dans lexpression pour fixer la valeur dun champ et la variable, t, pour les valeurs du champ recherches. On peut exprimer lappartenance dun champ un ensemble par un critre. Lexpression afficher les prix de vente suprieurs 10 000 , qui est une projection et une slection sur la relation vente, peut scrire sous la forme :
{ (p) | vente(_,p,_,_) p > 10000 }
Enfin, la jointure entre deux relations est galement possible. Lexpression afficher le type des voitures vendues et leur prix , qui met en jeu deux relations, peut scrire sous la forme :
{ (t,p) | nv voiture(nv,_,t,_) vente(_,p,_ ,nv)}
Il suffit dutiliser la mme variable dans les deux relations : ici nv, pour le champ NumVoit qui sert effectuer le lien. Le quantificateur permettra de ne slectionner que les tuples dans les deux relations pour lesquels les valeurs de NumVoit sont identiques, ce qui est exactement la dfinition dune jointure (quijointure). Le formalisme de la logique du premier ordre permet dexprimer toutes les oprations relationnelles vues prcdemment : cest normal puisquil sagit de la base de lapproche relationnelle. On peut alors considrer un SGBD comme un outil de dmonstration de thormes, tels que lon peut en rencontrer en intelligence artificielle, qui agirait sur un ensemble trs restreint de rgles.
NumVoit
Marque
Type
Couleur
Les critres de slection se font par des valeurs exemples (voir figures 3.32 et 3.33).
78
NumVoit
Marque
Type
Couleur Rouge
Figure 3.33
Slection sur un critre et projection dans un QBE.
DateVent
NumAch
NumVoit
Les conditions situes sur la mme ligne sont relies par un et (voir figure 3.34). Afficher les prix de vente suprieurs 10 000 et dont la date de vente a eu lieu aprs le Figure 3.34 Slection multicri- 1er janvier 1997 :
tre obligatoire et projection dans un QBE.
{ (p) | vente(d,p,_,_) (p > 10000 d > 01/01/1997)}
NumAch
NumVoit
Figure 3.35
Slection multicritre optionnel et projection dans un QBE.
Les conditions situes sur deux lignes diffrentes sont relies par un ou (voir figure 3.35). Afficher les prix de vente suprieurs 10 000 ou dont la date de vente a eu lieu aprs le 1er janvier 1997 :
{ (p) | vente(d,p,_,_) (p > 10000 d > 01/01/1997)}
NumAch
NumVoit
Figure 3.36
Jointure et projection dans un QBE.
La jointure entre deux relations se fait en utilisant une variable, exactement comme dans une formule de la logique de premier ordre (voir figure 3.36). Afficher le type des voitures vendues et leur prix :
{ (t,p) | nv voiture(nv,_,t,_) vente(_,p,_ ,nv)}
NumVoit Nv
Marque
Type
Couleur
DateVent
Prix
NumAch
NumVoit Nv
Cette mthode dinterrogation simple et efficace est encore propose par de nombreux SGBD.
Approche relationnelle 79
Rsum
Lapproche relationnelle modlise les faits de la vie relle par des tuples, qui sont des ensembles de valeurs de diffrents champs (ou attributs) : (rfrigrateur, 2003, rouge) est un tuple qui reprsente des valeurs des champs Objet, Anne, Couleur lies dans le monde rel. Lensemble des tuples sappelle une relation. Il sagit du concept de base qui sera manipul par lapproche relationnelle et peut tre reprsent sous la forme dune table. Pour identifier un tuple, on utilise le contenu dun ou de plusieurs champs que lon nommera la cl dune relation. Cette dernire est tablie en utilisant le concept de dpendance fonctionnelle entre les diffrents champs. La cl est constitue par le plus petit ensemble de champs dont dpendent fonctionnellement les autres champs. Si plusieurs cls sont possibles, on parle de cls candidates. La cl choisie sera nomme la cl primaire. Les oprations de manipulation de ces relations peuvent tre regroupes en trois catgories : Les oprations du monde ensembliste. Produit cartsien, intersection, union et diffrence. Les oprations spcifiques relationnelles. Projection, slection (ou restriction) et jointure. On a prsent galement la jointure externe qui permet de rpondre des questions spcifiques mme sil ne sagit pas dune opration de base du relationnel. Les oprations et les fonctions de calcul. Elles ne constituent pas rellement des oprations du monde relationnel mais sont utiles pour effectuer des calculs sans recourir un langage de programmation. La cohrence des donnes contenues dans les relations est amliore par la dfinition de contraintes que lon appliquera sur les relations au moment de leur cration. Ces contraintes expriment essentiellement les conditions dappartenance un ensemble que lon nomme le domaine du champ. On peut dcrire cet ensemble de plusieurs manires : Une liste exhaustive de valeurs, comme celles des jours de la semaine : lundi , mardi , etc. Le respect de proprits, comme : lge doit tre compris entre 7 et 77 ans . Lutilisation des valeurs dun champ comprises dans une autre relation de rfrence. On parle de cl trangre. La mise en uvre de ces contraintes est assure par le SGBD en utilisant le Langage de Dfinition de Donnes (LDD). Aprs avoir prsent les concepts de relation (ou de table) et les outils qui permettent de les manipuler, on a dcrit les rgles qui conduisent du modle conceptuel prsent au chapitre prcdent un ensemble de relations constituant le modle logique de la base de donnes. Les liaisons entre les relations, qui expriment les liens de sens dans la ralit, seront tablies dynamiquement par lopration fondamentale de lapproche relationnelle qui est la jointure. On value ensuite la qualit de ces relations en vrifiant leur conformit par rapport des proprits que lon appelle les formes normales. Ces proprits visent essentiellement dtecter la redondance et la cohrence des donnes dans les relations. On a prsent dans ce chapitre les quatre formes normales les plus courantes : la premire forme normale qui interdit les champs multivalus ; la deuxime forme normale qui dtecte une relation de dpendance entre une partie de la cl et un champ ;
80
Chapitre la troisime forme normale qui dtecte une dpendance transitive entre une cl et un champ, cest--dire quun champ non-cl dpend dun autre champ non-cl qui dpend lui mme de la cl ; la forme normale de Boyce-Codd qui dtecte la relation de dpendance entre un champ non-cl et une partie dune cl ; cest une extension de la troisime forme normale qui est plus restrictive. La normalisation est une mthode de rorganisation qui consiste dcomposer une relation pour la rendre conforme aux formes normales. La recomposition des donnes se fait alors par une opration de jointure qui peut se rvler coteuse en ressources. Cest pour cette raison de performance que certaines relations sont parfois laisses en forme non normalise. Les deux tapes prcdentes de passage du modle conceptuel au schma relationnel et de normalisation peuvent tre quasiment automatises. Enfin, on a abord les bases du fondement logique de lapproche relationnelle. Lobjectif est de prsenter une mthode dinterrogation intuitive et graphique dune base de donnes qui en dcoule : les QBE ou interrogation par lexemple .
Approche relationnelle 81
Exercices
EXERCICE 1
RELATION, DEGR, CARDINALIT
On considre deux relations. La premire Garage est de degr 7 et de cardinalit 3. La seconde Film est de degr 2 et de cardinalit 15. Quels sont le degr et la cardinalit du produit cartsien de Garage par Film ? Quels sont le degr et la cardinalit du produit cartsien de Film par Garage ? Comme le produit cartsien est une combinaison de tous les tuples des deux relations, le nombre de tuples sera le produit du nombre de tuples des deux relations. Tous les champs sont intgrs dans le rsultat en une sorte de juxtaposition : le nombre de champs du produit cartsien est gal la somme du nombre de champs des deux relations. Enfin, le produit cartsien est une opration symtrique ; le rsultat sera le mme pour les deux questions. La relation Garage possde 3 tuples de 7 champs et la relation Film possde 15 tuples de 2 champs. Le rsultat est une relation qui possde 45 tuples et 9 champs. On peut galement dire que le rsultat est une table qui possde 45 lignes et 9 colonnes.
EXERCICE 2
CL DUNE RELATION
Quelle est la cl de cette relation (voir figure 3.37) ?
Film(Prix, Format, Type, Nombre)
Figure 3.37
Relation Film.
Prix 12 4 12 35 12
Format 4 :3 16 :9 16 :9 4 :3 16 :9
Si lon considre simplement le contenu de la relation, il ny a pas de cl constitue par un seul champ. Il semble que la combinaison de deux champs, Prix et Nombre est une cl et que cest la seule qui contient deux champs. On pourrait trouver des combinaisons avec trois champs qui fonctionnent : par exemple Prix et Format et Couleur. Ce serait alors une cl candidate, mais on choisit celle qui est la plus atomique possible. On peut sinterroger en revanche sur le bien-fond dune cl constitue des deux champs Prix et Nombre si lon considre leur sens dans le monde rel. Il semble vident que lon puisse avoir deux films diffrents avec le mme prix et le mme nombre. Comment choisir la cl dans ce cas ? On ne peut donc en gnral pas choisir une cl sans tenir compte des dpendances fonctionnelles entre les champs. Mme si les donnes prsentes dans
82
Chapitre la relation semblent confirmer quil sagit bien dune cl, il ny a pas ici de dpendance entre les champs Prix et Nombre. Sauf si le commanditaire de la base de donnes vous affirme le contraire pour son cas particulier. Sans faire une analyse exhaustive des dpendances entre tous les champs, il semble quil ny a pas dans cette relation de bons candidats pour identifier un tuple. Une solution est dajouter un champ spcifique ; cest ce que proposent la plupart des SGBD lorsque vous ne dfinissez pas de cl pour une relation.
EXERCICE 3
CONTRAINTES DINTGRIT
On considre la relation Film(Prix, Format, Type, Nombre) de lexemple prcdent. Proposez des contraintes dintgrit pour chaque champ. On suppose que lon ajoute un champ Numro_Film qui correspond son identifiant dans une relation descriptive qui est un catalogue de films. Que proposez-vous comme contrainte pour ce champ ? Pour les champs de type numrique comme Prix et Nombre, on peut proposer des limites dappartenance un intervalle. Le prix doit tre compris entre 0 et 1 000, et le nombre entre 0 et 10 000. Pour les champs de type caractre comme Format et Couleur, il semble que les valeurs puissent tre incluses dans des ensembles numrs. Le format peut tre compris dans lensemble (3 :4,16 :9) et la couleur dans lensemble (Couleur,Noir/Blanc) . Le contenu du champ Numro_Film peut tre dfini par rapport au contenu du champ correspondant dans la relation catalogue. Cela revient imposer la contrainte suivante : on nentre pas de numro de films qui ne se trouveraient pas dans le catalogue. Dans tous les cas, ces valeurs sont dterminer avec les usagers de la base de donnes.
EXERCICE 4
OPRATION ENSEMBLISTE
Exprimez lintersection entre deux relations partir des oprations dunion et de diffrence. Donnez-en une illustration avec ses deux relations (voir figure 3.38).
Figure 3.38
Relations ma_cuisine et sa_cuisine.
ma_cuisine(Appareil, Couleur)
Appareil Rfrigrateur Robot Cuisinire Couleur rouge mauve jaune
sa_cuisine(Appareil, Couleur)
Appareil Rfrigrateur Cuisinire Hotte Couleur mauve jaune bleue
Pour raliser ces oprations, il faut que les relations possdent le mme schma. Lintersection entre deux ensembles peut se concevoir de la manire suivante en utilisant lop-
Approche relationnelle 83
Exercices
rateur de diffrence : ma_cuisine sa_cuisine = ma_cuisine (ma_cuisine - sa_cuisine) [voir figure 3.39]. Figure 3.39
Opration sur les relations ma_cuisine et sa_cuisine.
ma_cuisine - sa_cuisine
Appareil Rfrigrateur Robot Couleur rouge mauve
On obtient bien le rsultat de lintersection de ma_cuisine sa_cuisine. Vrifiez par la mme mthode que sa_cuisine ma_cuisine peut scrire sa_cuisine (sa_cuisine - ma_cuisine) et que lopration est symtrique bien que lopration de diffrence ne le soit pas.
EXERCICE 5
PROJECTION
Trouver le prix et le type de tous les films de la relation Film vue prcdemment. Peuton en dduire que Prix & Type est une cl candidate, cest--dire que toute combinaison des valeurs du prix et du type dun film permet didentifier un film ? Il sagit simplement dune projection sur les champs (voir figure 3.40).
Figure 3.40
Projection de la relation Film.
Film_proj(Prix, Type)
Prix 12 4 12 35 12 Type Couleur Noir/Blanc Couleur Noir/Blanc Noir/Blanc
Cette projection permet de mettre en vidence que Prix et Type nest pas une cl candidate, car il y a un doublon : le tuple (12, Noir/Blanc).
84
Chapitre
EXERCICE 6
RESTRICTION
Donnez le prix des films de la base films en Noir/Blanc . Quels sont le degr et la cardinalit de la relation obtenue ? Est-il possible de calculer ces valeurs lavance, comme on le fait pour un produit cartsien ? Il sagit de raliser une restriction sur les tuples dont le champ Type contient Noir/ Blanc ; on fait ensuite une projection sur le champ Prix (voir figure 3.41).
Figure 3.41
Restriction et projection de la relation Film.
Prix 12 4 12 35 12
Format 4 :3 16 :9 16 :9 4 :3 16 :9
On obtient une relation de degr 1 et de cardinalit 2 (voir figure 3.42). Figure 3.42
Rsultat de la restriction et de la projection de la relation Film.
Film_NB(Prix)
Prix 4 35
On peut calculer le degr facilement, puisquil sagit du nombre de champs sur lesquels on fera la projection. Pour la cardinalit qui reprsente le nombre de lignes du rsultat, on ne peut la calculer lavance puisquelle va dpendre du contenu du champ Type des tuples de la relation.
EXERCICE 7
JOINTURE
On considre ces deux relations prsentes dans un exercice prcdent (voir figures 3.43 et 3.44).
Figure 3.43
Relation Film.
Approche relationnelle 85
Exercices
50
Numero_Film 2 4 56 111 12
Titre
Trouvez la liste des titres de films et leur format. Voyez-vous une incohrence dans le rsultat ? Pouvez-vous lors de cette opration dtecter si la contrainte dintgrit rfrentielle suggre lexercice prcdent a t respecte ? Est-il possible de faire une jointure entre ces deux relations sur le champ Prix de la relation Film avec le champ Numero_film de la relation Catalogue ? Si oui, que signifie le rsultat ? On fait une jointure entre les deux relations sur les champs Numero_Film (voir figure 3.45). Figure 3.45
Jointure des relations Film et Catalogue.
Prix
Format
Type
Nombre
Titre
12 4 35 12
4 :3 16 :9 4 :3 16 :9
3 1 890 1
On projette sur les champs Titre et Format (voir figure 3.46). Figure 3.46
Projection sur la jointure des relations Film et Catalogue.
Titre Le train qui passe A toi ! Les impts faciles Les impts faciles
Format 4 :3 16 :9 4 :3 16 :9
Il nest pas incohrent dobtenir deux fois le mme titre avec deux formats diffrents. En revanche, la contrainte dintgrit rfrentielle nest pas respecte, car on nobtient pas la mme cardinalit que la relation de dpart lors de lopration de jointure. On aurait d obtenir une cardinalit de 5. On constate sur cet exemple que le contenu 50 du champ Numero_Film ne se trouve pas dans la relation Catalogue. Il manque donc un tuple dans le rsultat.
86
Chapitre La jointure sur les champs Prix et Numro_film est possible, car ils sont de mme type. Elle sera donc effectue par le SGBD sans rejet. On obtient la relation suivante (voir figure 3.47). Figure 3.47
Jointure sans objet des relations Film et Catalogue.
Prix
Format
Type
Nombre
Titre
12 4 12 12
4 :3 16 :9 16 :9 16 :9
3 1 1664 1
EXERCICE 8
AUTRE JOINTURE
Comment trouver la(les) valeur(s) qui ne respectent pas lintgrit rfrentielle du champ Numro_Film de la relation Film par rapport la relation Catalogue dans lexemple prcdent ? Quels sont les films du catalogue qui ne sont pas utiliss dans la relation Film ? On fait une jointure externe cette fois entre les relations sur les champs Numero_Film. Attention, lopration nest pas symtrique, la jointure se fait partir de la relation Film sur la relation Catalogue (voir figure 3.48)
Figure 3.48
Jointure externe des relations Film et Catalogue.
Prix
Format
Type
Nombre
Titre
12 4 12 35 12
4 :3 16 :9 16 :9 4 :3 16 :9
3 1 1664 890 1
Il suffit alors de faire une slection sur le contenu dun champ provenant de la relation Catalogue dont le contenu est NULL, par exemple le champ Titre. On projette ensuite sur le champ Numero_Film provenant de la relation Film. On obtient une relation une ligne et une colonne (ou une relation de degr 1 et de cardinalit 1) [voir figure 3.49].
Approche relationnelle 87
Exercices
Figure 3.49
Slection et projection de la jointure externe des relations Film et Catalogue.
Numero _Film 50
Pour dtecter les films du catalogue non utiliss, on va cette fois faire une jointure externe symtrique de la prcdente partir de la relation Catalogue sur la relation Film (voir figure 3.49).
Numero _Film (Catalogue) 2 4 56 111 12 Numero _Film (Film) 2 4 NUL NUL 12
Figure 3.50
Jointure externe des relations Catalogue et Film.
Titre Le train qui passe A toi ! Les chats du Sngal Le temps expliqu Les impts faciles
Prix
Format
Type
Nombre
12 4 NULL NUL 12
4 :3 16 :9 NUL NUL 4 :3
De mme que prcdemment, il suffit de faire une slection sur le contenu dun champ provenant de la relation Film dont le contenu est NULL, par exemple le champ Prix. On projette ensuite sur le champ Numero_Film provenant de la relation Film. On obtient une relation deux lignes et une colonne (ou une relation de degr 1 et de cardinalit 2) [voir figure 3.51]. Figure 3.51
Slection et projection de la jointure externe des relations Catalogue et Film.
Titre
EXERCICE 9
88
Chapitre valeurs pour toute la relation 4 :3 et 16 :9. Lopration sappelle raliser des agrgats par rapport au contenu dun champ . Ensuite, pour ces deux sous-relations, on calcule la moyenne des valeurs du champ Prix. Dans la relation rsultat, on a le champ projet Format et le champ calcul Moyenne (voir figure 3.52). Figure 3.52
Agrgat sur la relation Film.
Format 4 :3 16 :9
EXERCICE 10
Figure 3.53
Modle entitassociation de la location de DVD.
Location 0,n
NbeJourLoc DateLoc
Film
# NumFilm Titre Genre Prix NbDVD
Realise
0,n
On applique les rgles classiques de passage vues prcdemment dans ce chapitre. Une entit devient une relation compose des champs de lentit, ayant comme cl celle de lentit. Client (NumClient, Nom, Prenom, Adresse, Tel, Compte) ; Films(NumFilm, Titre, Genre, Prix, NombreDVD) ; Personnels(NumPers, Nom, Prenom). Les associations deviennent des relations ayant comme champs ceux de lassociation et comme cl celles des entits associes. Locations(DateLoc, NbeJourLoc, Livraison, NumFilm, NumClient) ; Reservations(DateRes, NbJourRes, NumFilm, NumClient) ; Joue(NumPers, NumFilm) ; Realise(NumPers, NumFilm).
Approche relationnelle 89
Exercices
On remarque que lassociation Realise a une cardinalit de type 1-1 lors de son association avec Films. Cela signifie dans le monde rel quun film a un et un seul ralisateur. On est dans le cas o lassociation Realise est absorbe par la relation cre partir de lentit associe, ici Film. On obtient la relation suivante : Films(NumFilm, Titre, Genre, Prix, NombreDVD, NumPers) et la relation Realise disparat. On peut noter que les cls des relations cres partir des associations Locations et Reservations supposent quun client ne rserve et ne loue pas le mme film deux fois. Dans le cas contraire, on serait oblig dajouter un champ identifiant pour ces deux relations. L encore, on ne peut dcider cela qu lisssue de discussions avec les utilisateurs de la base de donnes.
EXERCICE 11
II
partir du modle entit-association modlisant le lien de mariage, effectuez le passage au modle relationnel (voir figure 3.54). Figure 3.54
Modle entitassociation du mariage.
Client
# IDPersonne Nom Adresse NumTlphone
0,n
Est mari
DateMariage
0,n
Le fait que lassociation se fasse sur une mme entit ne pose pas de problmes particuliers ; on applique les rgles classiques. On obtient deux relations : Lentit personne devient une relation Personne(NumPersonne, Nom, Prenom, Adresse, Tel). Lassociation est_mari_ devient une relation Mariage(NumPersonne 1, NumPersonne 2, DateMariage). Les champs de lassociation de mme nom doivent tre renomms car ils ne peuvent avoir le mme nom. Les cardinalits 0-n de lassociation mariage ne signifient pas forcment que lon accepte la polygamie, mais plutt que lon peut avoir t mari plusieurs fois des dates diffrentes. ce sujet, la cl de la relation Mariage suppose quune personne ne se marie pas deux fois avec la mme personne.
90
Chapitre
EXERCICE 12
NORMALISATION
Cette relation est-elle en premire forme normale (voir figure 3.55) ? Personne(Nom, Adresse_mail, Poste)
Figure 3.55
Relation Personne.
La relation nest pas en premire forme normale en raison des valeurs qui correspondent bien des valeurs multiples contenues dans le champ Adresse_Mail. En revanche, il nest pas sr que la valeur Employ, asserment de le champ Poste soit une valeur multiple. Une virgule dans un champ ninduit pas ncessairement quil contient des valeurs multiples : cest peut-tre un contenu normalis (un peu trange certes). On remarque que cette relation na pas non plus de cl candidate srieuse, si lon tient compte des dpendances fonctionnelles entre les champs. Or, seule la prsence dune cl permettra de faire la dcomposition ncessaire la normalisation. On ajoute un champ Ident_Personne qui en sera la cl et lon dcompose en trois relations comme on la vu prcdemment. Une autre solution moins lourde est dajouter un champ supplmentaire pour ladresse mail en supposant que lon nen stockera toujours que deux. On effectue alors la rpartition des valeurs entre les champs. Il faut tout de mme ajouter le champ Ident_Personne pour que la relation possde une cl (voir figure 3.56). Personne(Ident_Personne, Nom, Poste, Adresse_mail1, Adresse_mail2) Figure 3.56
Relation Personne modifie.
Ident _Personne 1 2 3
Approche relationnelle 91
Exercices
EXERCICE 13
NORMALISATION
II
On considre la relation Film prcdente laquelle on a ajout le champ Support (voir figure 3.57). Film(Prix, Format, Couleur, Nombre, Numero_Film, Support) Figure 3.57
Relation Film avec support.
Prix 12 4 12 35 12 99
Format 4 :3 16 :9 16 :9 4 :3 16 :9 Inconnu
Numro_Film 2 4 56 12 12 111
Aprs discussion avec les utilisateurs de la base de donnes, il ne peut y avoir deux fois le mme film avec le mme format dans cette relation qui est un tat des stocks rcapitulatif. ce sujet, les utilisateurs indiquent que les formats 16 :9 seront toujours sur support DVD et les formats 4 :3 et Inconnu en support VHS. La relation est-elle en deuxime forme normale ? La relation est en premire forme normale. Il ny a pas de cl candidate atomique pour cette relation. Daprs lnonc, on dtermine que le couple de champs Numero_Film & Format est une cl. Or, il y a une dpendance fonctionnelle entre le support et le format. On a donc une dpendance entre un champ non cl et une partie de la cl ; la relation nest pas en deuxime forme normale. On dcompose la relation de la manire suivante (voir figure 3.58). Film(Prix, Format, Type, Nombre, Numero Film) Figure 3.58
Dcomposition de la relation Film avec support.
Prix 12 4 12 35 12
Format 4 :3 16 :9 16 :9 4 :3 16 :9
Numero Film 2 4 50 12 12
FormatSup(Format, Support)
Format 4 :3 16 :9 Inconnu Support VHS DVD VHS
92
Chapitre Les relations sont en premire et en deuxime forme normale. On effectue une jointure pour reconstituer linformation de dpart.
EXERCICE 14
NORMALISATION
III
On considre la relation suivante que lon a dj tudie au dbut du chapitre (voir figure 3.59). Lecteur(Numero carte, Nom, Age, Ville, Etablissement) Figure 3.59
Relation Lecteur .
Numro carte 1 2 3 4 5 6 7 8 9 10 11 12
Nom Henri Stanislas Henriette Dominique Isabelle Olivier Henri Jerome Laurence Christian Antoine Laurence
Age 10 34 44 19 56 51 98 23 34 41 16 34
Ville Paris Paris Lyon Nancy Nancy Marseille Paris Nancy Bordeaux Paris Marseille Paris
Etablissement Universit Sorbonne Universit Jussieu CHU Bron Universit Poincar INPL Universit Saint Charles Universit Sorbonne INPL Universit Victor Segalen Ecole Normale Suprieure Universit Saint Charles Universit Jussieu
Est-elle en troisime forme normale ? La relation est en premire forme normale, il ny a pas de champs multivalus. La cl de cette relation est atomique. Cest le champ Numero_carte qui a sans doute t ajout cet effet, sinon il ny avait pas vraiment de cls candidates. Si la cl est atomique, alors on est sr que la relation est en deuxime forme normale : il ne peut y avoir de dpendance entre un champ et une partie de la cl. Il existe une dpendance fonctionnelle entre deux champs non cl Ville et Etablissement (voir discussion au dbut du chapitre). On est dans le cas dune dpendance de type transitif . Le champ Ville dpend du champ Etablissement qui dpend de la cl Numero_carte. On dcompose la relation de la manire suivante (voir figures 3.60 et 3.61).
Approche relationnelle 93
Exercices
Figure 3.60
Relation Lecteur dcompose I.
Attention, la dcomposition suppose que le nom de ltablissement est unique quelle que soit la ville. En effet, le champ Etablissement est la cl de la deuxime relation. Cest ce qui a permis dtablir la relation de dpendance fonctionnelle. Cela ne peut tre garanti sans discussion avec les utilisateurs de la base de donnes. Si ce ntait pas le cas, il faudrait utiliser un identifiant unique pour chaque tablissement, qui se trouverait alors dans les deux relations et servirait faire la jointure. Figure 3.61
Relation Lecteur dcompose II.
Etablissement_Ville(Etablissement, Ville)
Etablissement Universit Sorbonne Universit Jussieu CHU Bron Universit Poincar INPL Universit Saint Charles Universit Victor Segalen cole Normale Suprieure Ville Paris Paris Lyon Nancy Nancy Marseille Bordeaux Paris
Les deux relations sont en troisime forme normale. On effectue une jointure pour reconstituer linformation de dpart.
94
Chapitre
SQL
1. Concepts du langage SQL ........96 2. Oprations relationnelles avec SQL .................................97 3. Gestion de tables et de vues ....110 4. Gestion des donnes ..............116 Exercices 1. Projection simple ....................120 2. Projection avec une colonne calcule .................................120 3. Projection/restriction avec un oprateur statistique ...........120 4. Agrgat .................................121 5. Question ngative ..................121 6. Produit cartsien .....................121 7. Jointure simple .......................122 8. Requte SQL trange ..............122 9. Autre question ngative jointure externe ....................122 10. Slection sur un agrgat dune jointure .........................123 11. Slection par rapport au rsultat dun calcul statistique ..............124 12. Cration dune table ...............124 13. Insertion de donnes dans une table ...............................125 14. Modification des donnes dune table ............................125 15. Requte combine ..................125
Le langage SQL est lun des lments qui ont contribu au dveloppement et au succs de lapproche relationnelle dans le monde des bases de donnes. En effet, la normalisation internationale du langage garantit la prennit et la stabilit des donnes ainsi que des dveloppements qui leur sont associs, indpendamment du SGBD et du langage utiliss. Ce chapitre aborde les concepts et la syntaxe du langage SQL, et prsente les trois grandes familles doprations que le langage permet dexprimer : Linterrogation et la recherche dans les tables. La gestion de tables et de vues munies des contraintes associes. Ces instructions concernent la table et sa structure et constituent la partie LDD (Langage de Description des Donnes) de SQL. La manipulation de donnes. Ces instructions concernent les donnes contenues dans la table et constituent la partie LMD (Langage de Manipulation des Donnes) de SQL.
95
Remarque
Un ensemble dinstructions SQL se nomme une requte. Une requte SQL se termine toujours par le caractre ; .
96
SGBD
Remarque
Par convention, dans tous les exemples qui suivent, les instructions SQL sont indiques en majuscules afin de les diffrencier des noms de tables et de champs. Les interprteurs SQL ne diffrencient pas les majuscules des minuscules en ce qui concerne les instructions. En revanche, cela dpend du systme dexploitation utilis ; le nom des champs ou des tables doit en gnral tre crit de manire exacte.
SQL 97
Figure 4.2
Base de donnes casse.
1 2 3 4 5 6
Voiture
NumVoit Marque
Peugeot Citroen Opel Peugeot Renault Renault
Type
404 SM GT 403 Alpine A310 Floride
Type
Rouge Noire Blanche Blanche Rose Bleue
Personne
NumAch
1 2 3 4 5
Nom
Nestor Irma Henri Josette Jacques
Age
96 20 45 34 50
Ville
Paris Lille Paris Lyon Bordeaux
Sexe
M F M F M
Vente
DateVente
1985-12-03 1996-03-30 1998-06-14 2000-04-02
Prix
10 000 70 000 30 000 45 000
NumVoit
1 2 4 5
NumAch
1 4 1 2
98
Chapitre
Projection sur tous les champs de la table Personne.
SELECT * FROM personne ;
NumAch 1 2 3 4 5
Age 96 20 45 34 50
Sexe M F M F M
Les colonnes de la table rsultat peuvent tre renommes par le mot cl AS.
SELECT Ville AS City FROM personne ;
SQL 99
calcul et pourra ventuellement affecter les performances du systme. Les valeurs des colonnes (colonnes) de la table rsultat peuvent tre constitues par des expressions construites avec les oprateurs suivants (voir tableau 4.1). Tableau 4.1
Oprateurs dexpressions de SQL.
+ * / %
Cration dune colonne Prix_Euros dans la table vente contenant le prix de vente en euros.
SQL dispose de nombreuses autres fonctions intgres, parfois dpendantes du SGBD utilis, qui permettent par exemple le traitement des colonnes de types caractres, date
Transformation dune colonne Nom de la table Personne en majuscules.
SELECT UPPER(Nom) AS NomMajuscule FROM personne ;
Mois 12 3 6 4
100
Chapitre la indiqu prcdemment. Les colonnes (colonnes) de la table rsultat peuvent tre constitues de rsultats de fonctions statistiques intgres SQL. Voici une liste (non exhaustive) des oprateurs statistiques de SQL (voir tableau 4.2) : Tableau 4.2
Oprateurs statistiques de SQL.
Comptage du nombre dlments (lignes) de la table Maximum des lments dune colonne Minimum des lments dune colonne Moyenne des lments dune colonne Somme des lments dune colonne
Remarque
Les fonctions statistiques sappliquent lensemble des donnes dune colonne (sauf pour la fonction COUNT qui sapplique aux lignes de la table entire). Pour toutes ces oprations, la table rsultat contiendra une seule ligne et souvent une seule colonne. Calcul de la moyenne des prix de vente pour la table vente.
SELECT AVG(Prix) AS Prix_Moyen FROM vente ;
Prix_Moyen 38 750.000 0
Nombre_Personne 5
Dans le cas de la fonction COUNT, on ne spcifie pas la colonne sur laquelle sapplique la fonction puisquil sagit de la table entire.
= <> <
SQL 101
DateVente 1996-03-30
Prix 70 000
NumVoit 2
NumAch 4
Tableau 4.4
Oprateurs de comparaison spcifiques SQL permettant de constituer des expressions. Extraction des voitures blanches ou rouges.
Appartient un intervalle Appartient un ensemble de valeurs Teste si la colonne nest pas renseigne Compare des chanes de caractres
NumVoit 1
Extraction des personnes dont lge est compris en 40 et 60.
SELECT * FROM personne WHERE Age BETWEEN 40 AND 60;
Marque Peugeot
Type 404
Couleur Rouge
NumAch 3 5
Age 45 50
Sexe M M
Tableau 4.5
Oprateurs et connecteurs logiques de SQL permettant de constituer des expressions. Extraction des voitures de couleur Blanche ou de marque Peugeot .
AND OR NOT
Et : les deux conditions sont vraies simultanment Ou : lune des deux conditions est vraie Inversion de la condition
NumVoit 1 3 4
102
Chapitre
Extraction des personnes nhabitant pas Paris.
SELECT * FROM personne WHERE NOT (Ville=Paris);
NumAch 2 4 5
Age 20 34 50
Sexe F F M
On obtient dans ce cas le mme rsultat que si lon avait utilis le mot cl DISTINCT vu prcdemment. Lutilisation courante de cette opration est dappliquer en une seule instruction les fonctions statistiques dj abordes aux diffrents sous-ensembles dune table ainsi constitus.
Calcul du nombre de voitures des diffrentes marques de la table voiture.
SELECT Marque, COUNT(*) AS Compte FROM voiture GROUP BY Marque ;
Compte 1 1 2 2
Ville Bordeaux
Moyenne_Age 50.0000
SQL 103
Compte 2 2
Remarque
Le mot cl HAVING permet deffectuer une slection sur le rsultat de lopration de groupage. Le mot cl WHERE opre une slection sur les lments (lignes) de la table avant lopration de groupage..
Supposons que lon veuille liminer les voitures rouges de notre calcul.
Calcul du nombre de voitures par marque de la table voiture dont la couleur est Rouge .
SELECT Marque, COUNT(*) AS Compte FROM voiture WHERE NOT (Couleur=Rouge) GROUP BY Marque;
Compte 1 1 1 2
104
Chapitre de la table. Pour des questions de lisibilit, il est prfrable de le faire systmatiquement pour toutes les requtes mme si ce nest pas absolument ncessaire.
Qualification des attributs par leur table dappartenance.
SELECT voiture.Marque, voiture.Couleur FROM voiture ;
Cette notation peut devenir rapidement fastidieuse si le nombre de tables est lev et si leurs noms sont longs. Dans ce cas, on dsigne la table par un alias plus commode, qui peut tre rduit une simple lettre, plutt que par son nom complet. Lalias est indiqu simplement la suite du nom de la table ou laide du mot cl AS qui est optionnel.
Qualification simplifie des attributs par leur table dappartenance.
SELECT Vo.Marque, Vo.Couleur FROM voiture AS Vo;
Produit cartsien
Le produit cartsien est la combinaison de toutes les lignes dune table avec toutes les lignes dune autre table sans tenir aucun compte du sens associ aux donnes. Cest une opration qui na gure dintrt en pratique. En SQL, cette opration scrit simplement.
Produit cartsien.
SELECT * FROM personne, voiture ;
NumAch 1 2 3 4 5 1
Age 96 20 45 34 50 96
Sexe M F M F M M
Num Voit 1 1 1 1 1 2
SQL 105
NumAch 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5
Nom Irma Henri Josette Jacques Nestor Irma Henri Josette Jacques Nestor Irma Henri Josette Jacques Nestor Irma Henri Josette Jacques Nestor Irma Henri Josette Jacques
Age 20 45 34 50 96 20 45 34 50 96 20 45 34 50 96 20 45 34 50 96 20 45 34 50
Ville Lille Paris Lyon Bordeaux Paris Lille Paris Lyon Bordeaux Paris Lille Paris Lyon Bordeaux Paris Lille Paris Lyon Bordeaux Paris Lille Paris Lyon Bordeaux
Sexe F M F M M F M F M M F M F M M F M F M M F M F M
Num Voit 2 2 2 2 3 3 3 3 3 4 4 4 4 4 5 5 5 5 5 6 6 6 6 6
Marque Citroen Citroen Citroen Citroen Opel Opel Opel Opel Opel Peugeot Peugeot Peugeot Peugeot Peugeot Renault Renault Renault Renault Renault Renault Renault Renault Renault Renault
Type SM SM SM SM GT GT GT GT GT 403 403 403 403 403 AlpineA 310 AlpineA 310 AlpineA 310 AlpineA 310 AlpineA 310 Floride Floride Floride Floride Floride
Couleur Noire Noire Noire Noire Blanche Blanche Blanche Blanche Blanche Blanche Blanche Blanche Blanche Blanche Rose Rose Rose Rose Rose Bleue Bleue Bleue Bleue Bleue
Le nombre de lignes de la table rsultat est gal au produit du nombre de lignes des deux tables. Les colonnes sont celles des deux tables simplement juxtaposes.
106
Chapitre
Construction de la jointure des tables voiture et vente sur le critre dgalit de la colonne NumVoit.
SELECT voiture.Marque, voiture.Couleur, vente.Prix FROM voiture, vente WHERE voiture.NumVoit=vente.NumVoit ;
Une autre manire dexprimer la jointure interne passe par un oprateur de jointure spcifique JOIN. Il faut bien sr spcifier la colonne sur laquelle seffectue la jointure.
SELECT voiture.Marque, voiture.Couleur, vente.Prix FROM vente JOIN voiture ON voiture.NumVoit=vente.NumVoit ;
Le traitement de la requte est dans ce cas optimis par le SGBD. Cest important, car lopration de jointure est complexe raliser pour un SGBD et est coteuse en temps et en ressources. Le nombre de lignes de la table rsultat est gal cette fois au nombre de lignes contenues dans les deux tables pour lesquelles le critre dgalit des colonnes est respect. Il est bien sr possible deffectuer la jointure sur plus de deux tables : on indique alors les diffrents critres de jointure entre les tables.
Construction de la jointure des tables voiture, personne et vente sur les critres dgalit des colonnes NumaAch et NumVoit.
SELECT vo.Marque, vo.Couleur, ve.Prix, pe.Nom, pe.Age FROM voiture AS vo, vente AS ve, personne AS pe WHERE (vo.NumVoit=ve.NumVoit) AND (pe.NumAch=ve. NumAch);
Age 96 34 96 20
ou
SELECT vo.Marque, vo.Couleur, ve.Prix, pe.Nom, pe.Age FROM voiture AS vo JOIN vente AS ve JOIN personne AS pe ON (vo.NumVoit=ve.NumVoit) AND (pe.NumAch=ve. NumAch);
Dans ce cas, il est indispensable de prciser le nom de la table pour chaque colonne dans la mesure o les tables ont des noms de colonnes en commun ; de plus, il peut tre intressant de les dsigner par des alias pour une simple commodit dcriture.
Remarque
Lopration de jointure prcdente est dite galement interne ; le mot cl INNER devant JOIN est, pour la plupart des SGBD, implicite et donc optionnel, mais il faudrait crire en toute rigueur :
SELECT voiture.Marque, voiture.Couleur, vente.Prix FROM vente INNER JOIN voiture ON voiture.NumVoit=vente.NumVoit ;
SQL 107
NumVoit 1 2 3 4 5 6
Si lon opre la requte en inversant lordre des tables, ou en employant le mot cl RIGHT, on obtient la mme rponse que pour la requte dqui-jointure ci-dessus. Cela signifie quil ny a pas de lignes dans vente dont le contenu de la colonne NumVoit ne possde pas de correspondance dans la colonne NumVoit de la table voiture. Ce rsultat est prvisible puisquune voiture doit exister dans la table voiture pour pouvoir faire lobjet dune vente. On dispose alors dun moyen de contrler la cohrence des donnes entre les tables : dans notre cas, on pourra ainsi vrifier quil ny a pas de valeur didentifiant de voiture dans la table vente (contenu de la colonne NumVoit de la table vente) qui ne se trouve pas dans la table voiture (contenu de la colonne NumVoit de la table voiture).
Construction de la jointure externe inverse des tables voiture et vente sur les critres dgalit de la colonne NumVoit.
SELECT voiture.NumVoit, vente.NumVoit, voiture.Marque, voiture.Couleur, vente.Prix FROM vente LEFT OUTER JOIN voiture ON voiture.NumVoit=vente.NumVoit ;
NumVoit 1 2 4 5
NumVoit 1 2 4 5
108
Chapitre ou
SELECT voiture.NumVoit, vente.NumVoit, voiture.Marque, voiture.Couleur, vente.Prix FROM voiture RIGTH OUTER JOIN vente ON voiture.NumVoit=vente.NumVoit ;
Il faut terminer la requte et rpondre la question de dpart : Quelles sont les voitures qui nont pas t vendues ? Pour ce faire, il suffit de slectionner les lignes dont lune des colonnes issues de la table vente na pas pu tre mise en correspondance avec une ligne de la table voiture : le contenu de cette colonne sera vide, ce qui signifie que lon peut le tester avec le mot cl NULL. Par exemple, on teste le contenu de la colonne Prix issue de la table vente.
Slection des lignes de la table prcdente.
SELECT voiture.NumVoit, voiture.Marque, voiture.Couleur, vente.Prix FROM voiture LEFT OUTER JOIN vente ON voiture.NumVoit=vente.NumVoit WHERE vente.Prix IS NULL;
NumVoit 3 6
Il est possible de prciser lordre de tri par les mots cls ASC (croissant par dfaut) ou DESC (dcroissant).
Tri par Marque de la table voiture en ordre dcroissant.
SELECT Prix, DateVente FROM vente ORDER BY Prix DESC ;
SQL 109
On peut indiquer plusieurs critres de tri, qui sont lus et traits de gauche droite (ici, on trie dabord par villes puis par ges).
Tri par Ville et par Age de la table personne.
SELECT Nom, Age, Ville FROM personne ORDER BY Ville, Age ;
Age 50 20 34 45 96
3.1 TABLES
Le langage SQL comprend une partie manipulation de donnes (LMD) pour grer les tables, qui est prsente dans cette section. Les oprations de cration, de suppression et de modification des tables mettent jour le dictionnaire de donnes du SGBD. On rappelle que le dictionnaire de donnes est une structure propre au SGBD qui contient la description des objets du SGBD (base de donnes, tables, colonnes, droits, etc.).
Remarque
Pour pouvoir grer une table, il faut au pralable disposer des droits sur la base de donnes qui la contient : ces aspects sont abords au chapitre 6.
Cration
La cration dune table est une opration importante quil faut entreprendre avec soin. Cest lors de cette tape que lon dfinit le type de donnes, la cl, les index ventuels et quil convient dimposer des contraintes de validation garantissant la bonne qualit des informations entres dans la table. La forme gnrale de linstruction de cration de table est la suivante :
CREATE TABLE <Nom de la table> ( liste des colonnes avec leur type spar par ,) ;
Remarque
Le nom de la table ou dune colonne ne doit pas dpasser 128 caractres. Il commence par une lettre, contient des chiffres, des lettres et le caractre _ . Attention de mme ne pas utiliser un mot cl SQL.
CREATE TABLE voiture ( NumVoit INT, Marque CHAR(40), Type CHAR(30), Couleur CHAR(20) ) ;
110
Chapitre Les tables peuvent tre cres de manire temporaire : elles seront donc effaces la fin de la session de lutilisateur laide du mot cl TEMPORARY.
Cration de la table voiture.
CREATE TEMPORARY TABLE temporaire ( Identifiant INT, Jour DATE, Valide BOOLEAN ) ;
Les tables peuvent tre issues directement du rsultat dune requte en utilisant le mot cl AS : cest particulirement commode pour pouvoir disposer de rsultats intermdiaires en fin de vrification, lors dune srie de manipulations sur une table.
CREATE TEMPORARY TABLE resultat AS (SELECT Vo.Marque, Vo.Couleur FROM voiture AS Vo);
Type de donnes Le type de donnes est choisi essentiellement en fonction des oprations qui sont effectues sur la colonne. Le choix du type permet galement de mettre en place un premier niveau de restriction sur le contenu des donnes : une colonne de type numrique ne pourra pas contenir de caractres. Des restrictions plus fines seront dfinies la section Contraintes dintgrit . Voici une liste (non exhaustive) des types de donnes SQL (voir tableaux 4.6, 4.7, 4.8 et 4.9). Tableau 4.6
Types de donnes numriques de SQL.
Entier standard (32 bits) Entier petit (16 bits) Rel (taille spcifique au SGBD) Rel (reprsent sur n bits) Chane de caractres de longueur n (codage ASCII 1 octet) Chane de caractres de longueur maximale n (codage ASCII 1 octet) Chane de caractres de longueur n (codage Unicode sur 2 octets) Chane de caractres de longueur maximale n (codage Unicode sur 2 octets) Boolen
Tableau 4.7
Types de donnes chanes de caractres de SQL.
Tableau 4.8
Types de donnes date de SQL.
Tableau 4.9
Types de donnes binaires de SQL.
SQL 111
Suppression
La commande DROP TABLE permet de supprimer une table.
DROP TABLE voiture
Si la table est rfrence dans une autre table (par exemple, contrainte dintgrit rfrentielle), le SGBD refuse en gnral de la supprimer : il utilise loption RESTRICT par dfaut. Si lon dsire tout de mme la supprimer ainsi que tous les objets qui lui sont lis, il faut alors utiliser loption CASCADE. Dans lexemple, si la table vente utilise la table voiture comme table de rfrence pour le contenu de la colonne NumVoit, on ne peut supprimer la table voiture avant davoir supprim la table vente.
DROP TABLE voiture CASCADE
Modification
La commande ALTER TABLE permet de modifier la structure de la table, cest--dire dajouter, de supprimer ou modifier des colonnes.
Ajout dune colonne de nom enplus de type INT la table voiture (ADD COLUMN). Affichage de la table voiture modifie.
ALTER TABLE voiture ADD COLUMN enplus INT ;
NumVoit 1 2 3 4 5 6
Suppression de la colonne de nom Couleur de la table voiture (DROP COLUMN). Affichage de la table voiture modifie.
NumVoit 1 2 3 4 5 6
112
Chapitre La commande ALTER permet de modifier galement les contraintes associes aux colonnes. Cette partie est traite la section suivante, Contraintes dintgrit . Le mot cl COLUMN est optionnel.
Remarque
Il nest pas possible de modifier directement le nom dune colonne ou son type. Il faut pour cela crire une srie doprations, en utilisant par exemple des colonnes temporaires.
Voici la suite dinstructions permettant la modification du nom de la colonne de nom Couleur de la table voiture en Teinte en changeant son type. Linstruction UPDATE sera dtaille la section Gestion des donnes .
Ajout de la colonne Teinte. Affichage de la table voiture modifie.
ALTER TABLE voiture ADD COLUMN Teinte CHAR(60); SELECT * FROM voiture ;
NumVoit 1 2 3 4 5 6
Recopie des donnes de Couleur dans Teinte. Affichage de la table voiture modifie.
NumVoit 1 2 3 4 5 6
SQL 113
NumVoit 1 2 3 4 5 6
Proprits gnrales
La valeur de la colonne doit tre renseigne absolument (NOT NULL). La valeur doit tre unique compare toutes les valeurs de la colonne de la table (UNIQUE). Lorsque les deux conditions prcdentes sont runies, la colonne peut servir identifier un enregistrement et constitue donc une cl candidate . On rappelle quil ne peut y avoir quune seule cl que lon dsignera en SQL par le mot cl PRIMARY KEY. Ici, on indique que la colonne NumAch est choisie comme cl de la table (donc implicitement unique et non nulle) et que la colonne Nom doit toujours tre renseigne.
CREATE TABLE personne ( NumAch INT PRIMARY KEY, Nom CHAR(20) NOT NULL, Age INT ) ;
Si aucune mention nest prcise comme pour la colonne Age, elle peut tre renseigne ou non. Attention, une colonne non renseigne (cest--dire qui contient la valeur NULL pour SQL) signifie quelle ne contient aucune donne, et non pas, par exemple, quelle
114
Chapitre contient 0 pour une colonne de type entier ou un espace pour une colonne de type caractre . Si la cl est constitue de plusieurs colonnes (elle est dite composite) ; on indique la liste des colonnes constitutives de la cl la suite du mot cl PRIMARY KEY.
CREATE TABLE vente ( DateVente DATE, PRIX INT, NumAch INT, NumVoit INT, PRIMARY KEY (NumAch, NumVoit) ) ;
Par une expression (>, < , BETWEEN). Par exemple, le prix doit tre suprieur 1 000. On vrifie que lge est compris entre 1 et 80.
CREATE TABLE personne (NumAch INT PRIMARY KEY, Nom CHAR(20) NOT NULL, Ville CHAR(40), AGE INT NOT NULL, CHECK (Age BETWEEN 1 AND 80) );
Par une rfrence aux valeurs dune colonne dune autre table (REFERENCES). Les colonnes doivent tre de mme type et lon ne peut plus dtruire par dfaut une table qui apparat comme rfrence. On vrifie que les valeurs identifiantes des personnes NumAch et des voitures NumVoit de la table vente existent bien dans les tables de rfrence personne et voiture.
CREATE TABLE vente ( DateAch DATE, PRIX INT, NumAch INT NOT NULL REFERENCES personne(NumAch), NumVoit INT NOT NULL REFERENCES voiture(NumVoit), PRIMARY KEY (NumAch, NumVoit) ) ;
SQL 115
CREATE TABLE personne (NumAch INT PRIMARY KEY, Nom CHAR(20) NOT NULL, Ville CHAR(40), AGE INT, CONSTRAINT la_contrainte CHECK ( (Age IS NOT NULL AND Ville IS NOT NULL) OR IS NULL AND Ville IS NULL) ) ;
(Age
Les vues permettent galement de mettre jour les tables, condition que les rgles dintgrit de(s) table(s) utilises pour construire la vue soient respectes : en pratique, seules les vues concernant une seule table peuvent effectuer des mises jour.
116
Chapitre La commande pour insrer des donnes est de la forme gnrale suivante :
INSERT INTO <nom de la table> [ liste des colonnes ] VALUES <liste des valeurs>
NumVoit 1 2 3 4 5 6 10
Si certaines colonnes sont omises, elles prendront la valeur NULL. Si la liste des colonnes est omise, on considre quil sagit de la liste de celles prises dans lordre dfini lors de la cration de la table.
Remarque
Pour tre insres, les valeurs des colonnes doivent respecter les contraintes dintgrit associes la table.
SQL 117
NumVoit 2 3 4 5 6
Attention, si lon ne spcifie aucune condition, tous les enregistrements sont supprims.
DELETE FROM personne ;
NumAch 1 2 3 4 5
Age 96 20 45 34 50
Sexe M F M F M
118
Chapitre
Rsum
Voici une synthse des commandes SQL prsentes dans ce chapitre. Le langage SQL permet : La gestion de tables et de vues munies des contraintes associes (LDD, Langage de Description des Donnes). Ces instructions concernent la table et sa structure.
cration CREATE TABLE/VIEW <nom de la table> destruction DROP TABLE/VIEW <nom de la table> modification ALTER TABLE/VIEW <nom de la table>
La manipulation de donnes (LMD, Langage de Manipulation des Donnes). Ces instructions concernent les donnes contenues dans les tables.
insertion INSERT INTO <nom de la table> (<liste de colonnes> <liste de valeurs>) modification UPDATE <nom de la table> SET <colonne=valeur> WHERE <critre> destruction DELETE FROM <nom de la table> WHERE <critre>
Figure 4.3
Synthse des commandes SQL.
AS, DISTINCT
ON
+, , *, /, %
SELECT FROM
<liste de champs>
=, <, >, LIKE IS NULL, IN, BETWEEN OR, AND, NOT
WHERE
ASC, DESC
<Table>
WHERE <liste de critres> UPDATE <Table> SET < champ=valeur > WHERE <liste de critres>
Le langage SQL se rvle beaucoup plus complet que la partie qui est prsente dans ce chapitre. Le choix effectu parmi les commandes permet de rpondre aux questions les plus courantes en base de donnes.
SQL 119
Exercices
EXERCICE 1
PROJECTION SIMPLE
Trouvez les diffrentes villes dans lesquelles habitent les personnes. Ordonnez le rsultat par ordre dcroissant. Il sagit dune projection simple sur la colonne Ville de la table personne laide du mot cl DISTINCT.
SELECT DISTINCT Ville FROM personne ORDER BY Ville DESC ;
EXERCICE 2
Solution
Il sagit dutiliser la fois une fonction statistique et une colonne calcule partir de la colonne Prix de la table vente.
SELECT SUM(Prix*1.2) AS CA_TTC FROM vente ;
EXERCICE 3
Calculer laide dune fonction statistique la moyenne de la colonne Age pour ses enregistrements (projection).
SELECT AVG(Age) FROM Personne WHERE Ville=Paris ;
120
Chapitre Pour complter cet exercice, il serait plus lgant de renommer la colonne ainsi calcule, par exemple en Moyenne_Paris :
SELECT AVG(Age) AS Moyenne_Paris FROM Personne WHERE Ville=Paris ;
EXERCICE 4
AGRGAT
Trouvez le nombre de voitures par marques dans la base de donnes casse. Toutes les informations ncessaires existent dans la table voiture. De mme que pour lexercice prcdent, il est intressant de raisonner en deux temps : Grouper les donnes par marques de voitures (agrgat).
SELECT Marque FROM Voiture GROUP BY Marque;
EXERCICE 5
QUESTION NGATIVE
Trouvez lge des personnes qui nhabitent pas Paris. Toutes les informations ncessaires sont prsentes dans la table personne. Le problme est toujours dexprimer une condition ngative, ici la non-appartenance un ensemble. Dans ce cas, cest assez simple puisque toutes les valeurs de la colonnes Ville sont renseignes. Ce serait plus difficile si certains enregistrements possdaient une colonne Ville vide (valeur NULL) : il faudrait logiquement les exclure du rsultat. Il est prudent dinclure dans la rponse, en phase de vrification, la colonne sur laquelle on exprime un critre (ici, la colonne Ville). Il est en effet assez facile de faire une erreur dans lexpression dun critre.
SELECT Age, Ville FROM personne WHERE NOT (Ville=Paris) ;
EXERCICE 6
PRODUIT CARTSIEN
crivez lexpression du produit cartsien de la table voiture et de la table personne. Combien de lignes et de colonnes possde la table rsultat ? Est-ce une opration symtrique (dans laquelle on retrouve le mme rsultat en inversant lordre des tables).
SQL 121
Exercices
Il ny a aucun critre de projection, ni de slection ; toutes les colonnes et les lignes des deux tables participent donc au produit cartsien. On obtient 30 lignes (6 5) et 9 colonnes (5 + 4).
SELECT * FROM personne, voiture;
Lopration est videmment symtrique. En revanche, si les donnes sont les mmes, elles ne se trouveront pas dans le mme ordre.
EXERCICE 7
JOINTURE SIMPLE
Donnez les noms des personnes et la marque des voitures quelles ont achetes. Linformation se trouve dans les tables voiture et personne. Mais pour relier smantiquement ces deux tables, on a besoin de la table vente. Il faut donc faire une qui-jointure entre ces trois tables.
SELECT vo.Marque, pe.Nom FROM voiture AS vo JOIN vente AS ve JOIN personne AS pe ON (vo.NumVoit=ve.NumVoit) AND (pe.NumAch=ve. NumAch);
EXERCICE 8
REQUTE
SQL TRANGE
Obtient-elle une rponse ou provoque-t-elle un message derreur ? Cest pratiquement la mme requte que pour lexercice prcdent, mais le lien entre les tables a t ralis sur des colonnes diffrentes. La syntaxe est correcte et le type des colonnes sur lesquelles a t faite la jointure est compatible ; SQL retournera donc une table rsultat . Le fait que ce rsultat na aucun sens du point de vue du monde rel ne peut tre dduit du schma des relations. Pour ce faire, il faut consulter le modle conceptuel qui lui a servi de base.
EXERCICE 9
JOINTURE EXTERNE
Quelles sont les villes o habitent les personnes qui nont pas achet de voiture ? Cest une question ngative , comme celle de lexercice 4.5, mais qui met en jeu deux tables. Il sagit de trouver, en comparant les valeurs de la colonne NumVoit comprises
122
Chapitre dans les tables vente et voiture , celles qui sont dans voiture et pas dans vente . cet effet, on utilise une opration, qui nest pas proprement parler une opration de lalgbre relationnelle, qui sappelle la jointure externe qui permet dafficher les enregistrements qui nont pas de correspondance dans lautre table. L encore, le raisonnement peut se dcomposer en deux tapes : Construction de la jointure externe des deux tables : lajout des colonnes NumAch des deux tables dans la rponse sert simplement vrifier notre requte.
SELECT personne.Ville, personne.NumAch, vente.NumAch FROM personne LEFT OUTER JOIN vente ON personne.NumAch=vente.NumAch ;
Slection dans cette table rsultat des lments nayant pas de correspondance dans vente et qui ont donc une valeur NULL pour la colonne NumAch.
SELECT personne.Ville FROM personne LEFT OUTER JOIN vente ON personne.NumAch=vente.NumAch WHERE vente.NumAch IS NULL;
noter que la question demandait dtablir la liste des villes. Si le contenu de la base de donnes tait plus important, la mme ville pourrait apparatre plusieurs fois dans la rponse. Pour viter ce cas de figure, on prcise que lon veut la liste des diffrentes occurrences de ville par le mot cl DISTINCT.
SELECT DISTINCT personne.Ville FROM personne LEFT OUTER JOIN vente ON personne.NumAch=vente.NumAch WHERE vente.NumAch IS NULL;
EXERCICE 10
Ensuite, on utilise lopration dagrgation pour effectuer un regroupement par Marque et calculer pour chaque sous-ensemble la moyenne des prix de vente.
SELECT vo.Marque, AVG(ve.Prix) FROM voiture AS vo JOIN vente AS ve ON vo.NumVoit=ve.NumVoit GROUP BY vo.Marque ;
SELECT vo.Marque, AVG(ve.Prix) AS Moyenne FROM voiture AS vo JOIN vente AS ve ON vo.NumVoit=ve.NumVoit GROUP BY vo.Marque HAVING Moyenne >= 40000 ;
SQL 123
Exercices
Enfin, on limine du rsultat du calcul prcdent les marques dont la moyenne des prix est infrieure 40 000 en ne gardant que les lignes dont la moyenne est suprieure ou gale 40 000.
On peut utiliser lalias du nom de la colonne calcule (ici Moyenne ) pour effectuer la slection. Attention, on ne peut pas utiliser le mot cl WHERE ici, car il sagit dune slection sur le rsultat du calcul et non pas a priori avant le calcul. On utiliserait WHERE pour rpondre une question du type : Calculez la moyenne des prix de vente par marques en ne considrant pour ce calcul que les prix suprieurs 40 000.
SELECT vo.Marque, AVG(ve.Prix) AS Moyenne FROM voiture AS vo JOIN vente AS ve ON vo.NumVoit=ve.NumVoit WHERE ve.Prix >= 40000 GROUP BY vo.Marque;
Avec le jeu de donnes restreint dont on dispose, on remarque que le rsultat est identique, mais cest videmment un hasard.
EXERCICE 11
EXERCICE 12
124
Chapitre
EXERCICE 13
Lenregistrement est valide ; aucune colonne ne contredit les contraintes dfinies prcdemment : la cl NumAch est unique, le nom est renseign, les colonnes Age et Sexe ne sont pas renseignes, mais ne sont pas obligatoires.
EXERCICE 14
EXERCICE 15
REQUTE COMBINE
Quelles sont les personnes qui nont pas achet de voitures rouges ? La question parat simple, mais elle doit tre bien analyse. On doit considrer deux catgories de personnes : celles qui ont achet des voitures mais pas de voitures rouges ; celles qui nont achet aucune voiture. Pour obtenir la liste des personnes qui nont achet aucune voiture, on utilise une requte de type jointure externe. Les informations se trouvent dans les deux tables personne et vente .
SELECT personne.Nom FROM personne LEFT OUTER JOIN vente ON personne.NumAch=vente.NumAch WHERE vente.NumAch IS NULL;
SELECT pe.Nom FROM voiture AS vo JOIN vente AS ve JOIN personne AS pe ON (vo.NumVoit=ve.NumVoit) AND (pe.NumAch=ve. NumAch) WHERE vo.Couleur != Rouge;
SQL 125
Exercices
Pour obtenir la liste des personnes qui ont achet une voiture, mais pas rouge, on utilise une requte de type slection sur une quijointure. Les informations se trouvent dans les deux tables personne et voiture, que lon doit relier par la table vente.
Chapitre
Ce chapitre prsente un exemple complet de ralisation dune base de donnes, tape par tape. On part de lnonc dans la vie relle jusqu linterrogation de la base laide du langage SQL. Cet exemple permet de rcapituler les concepts prsents dans les chapitres prcdents, savoir : lanalyse du monde rel et la cration du modle entit-association ; le passage au modle relationnel ; la cration des tables en SQL par lintgration des contraintes de contenu ; linterrogation de la base de donnes par des requtes SQL. On aborde galement ici les diffrents aspects dordre pratique qui se posent chaque tape de la ralisation dune base de donnes.
127
Produits
Les produits vendus sont des pizzas. Une pizza est caractrise par son nom, les ingrdients qui la composent et son prix de base. Pour chaque pizza, il existe trois tailles : naine , humaine et ogresse . La naine est 1/3 moins chre que le prix de base, cest--dire la taille humaine , et l ogresse est 1/3 plus chre.
Mode de distribution
Les pizzas sont livres par des livreurs qui circulent en voiture ou moto et qui nont pas de vhicules attitrs. La base de donnes doit galement permettre le suivi de lactivit des livreurs et des vhicules quils utilisent.
Modalits de vente
Le mode de vente est du type prpay : pralablement toute commande, les clients doivent sabonner au service et approvisionner leur compte. On vrifie le solde du compte avant de prparer et de livrer la commande. Il existe deux systmes de bonification : Une pizza gratuite est offerte au bout de 10 pizzas achetes. Toute pizza livre en plus de trente minutes est gratuite.
Objectifs du systme
Le but de cette base de donnes est de grer lactivit quotidienne de vente et de livraison de pizzas : vrification du solde du compte et facturation aux clients ; suivi du chiffre daffaires ; refus dhonorer les commandes pour lesquelles le solde du compte client est insuffisant ; non-facturation des pizzas gratuites (retard ou fidlit). On veut galement effectuer des statistiques diverses sur lactivit : identification du meilleur client ; identification du plus mauvais livreur (nombre de retards dans la livraison) et du vhicule utilis ; identification de la pizza la plus ou la moins demande ; identification de lingrdient favori
128
Chapitre
Remarque
Afin de simplifier le problme, on considre que lopration de base modliser dans cette activit est la vente dune unique pizza. La notion de commande qui peut contenir plusieurs pizzas nest pas prise en compte. On pourra faire voluer le systme plus tard si besoin est pour intgrer cet aspect. Il est en effet plus simple de raisonner en termes de ventes unitaires, que lon peut agrger ensuite, plutt que dattaquer directement sur des commandes multiples.
Entits et attributs
On rappelle quil ne sagit pas vraiment dun processus scientifique bas sur des rgles prcises. Une certaine part dintuition est ncessaire, dautant plus quil nexiste pas une solution unique dans la majorit des cas. On peut remarquer quelques mots cls dans la description gnrale : pizza, ingrdient, client, livreur, vhicule. Ces descripteurs reprsentent des objets familiers du monde rel. En revanche, les mot cls taille, prix, compte, retard, nom et autres sont clairement plus des qualifiants que des objets. Ce qui relie tous ces objets pour constituer la reprsentation de lactivit est la notion de commande. Cette dernire est lun des seuls objets abstraits, compare aux autres objets concrets du monde rel, comme peut ltre un vhicule par exemple. partir de ces constatations, voici une proposition de quelques phrases extraites ou dduites de la description gnrale qui permettent deffectuer une premire synthse de lactivit : Une pizza est constitue de plusieurs ingrdients. Un client passe une commande. Une commande est livre par un et un seul livreur. Une commande est livre par un et un seul vhicule.
Du langage parl SQL 129
On en dduit lexistence des entits suivantes : commande ; client ; pizza ; livreur ; vhicule ; ingrdient. On peut se poser la question de savoir si un ingrdient est une entit part entire ou un simple attribut dune pizza. Lentreprise considre est une franchise ou tout est trs normalis, et lon peut imaginer que la liste des ingrdients lest aussi. Un mme ingrdient entre certainement dans la composition de plusieurs pizzas. Il est donc prfrable de sparer les ingrdients des pizzas ; lassociation entre les deux entits est reprsente par la phrase : Une pizza est constitue dingrdients. Notons propos des ingrdients que le systme ne doit grer que les aspects commande et livraison ; lon ne sintresse pas ici la gestion des stocks dingrdients. Il manque dans la description un nombre important de donnes qui vont constituer certaines entits, en particulier les entits vhicule ou client. Le cas est frquent lors de la ralisation du processus ; il est alors ncessaire de poser de nouvelles questions pour combler ces lacunes. On imagine qu la suite dun dialogue avec les diffrents acteurs de lentreprise, on obtient les renseignements suivants : Un client est caractris par son nom et son adresse. Un livreur est caractris par son nom et son numro de tlphone. Un vhicule est caractris par sa marque, son type et son numro dimmatriculation. Ces informations complmentaires permettent de dterminer quelques attributs des entits ainsi constitues. Les autres attributs des entits se trouvent dans lnonc : par exemple une pizza est caractrise par son nom et par son prix ou un ingrdient est caractris par son nom . Laffectation dun attribut une entit nest pas toujours vidente. On va crer un attribut compte qui contiendra les informations de solvabilit du client puisque lon fonctionne en mode prpay. Il faut se poser la question : est-ce une proprit caractristique du client ? La rponse dans notre cas est aise et lattribut sera affect lentit client. Mais comment prendre en compte la taille de la pizza ? Sagit-t-il dune proprit caractristique de lentit pizza ou la taille est-elle associe la commande ou mme au client ? Pour rpondre cette question, on doit considrer le moment ainsi que lendroit o intervient la notion de taille et dterminer son utilit. La taille sert uniquement pondrer le prix de base de la pizza : elle nest donc pas associe la pizza, dont le prix est fixe ; elle ne constitue pas non plus on sen doutait un peu une caractristique dun client. On pourrait, la limite, la considrer comme telle si lon disposait dune information du type : les grandes tailles sont uniquement commandes par des hommes, les tailles normales par des femmes et les petites tailles par des enfants de sexe indiffrenci . Comme ce nest pas le cas, on associe logiquement la taille lentit commande. Ce type de rflexion doit tre engag galement pour modliser les possibilits de bonification qui peuvent tre obtenues soit en raison dun retard de livraison soit par une capitalisation sous forme de points de fidlit. Par un raisonnement semblable, on dtermine que le retard est associ la commande alors que la fidlisation est associe au client. Si lon rcapitule, on obtient les entits munies de leurs attributs suivants : commande (DateCom, Taille, Retard) ;
130
Chapitre client (NomClient, Adresse, Compte, PointsRaPizz) ; pizza (NomPizza, Prix) ; livreur (NomLivreur, Tlphone) ; vhicule (NumImmat, Marque, Type) ; ingrdient (NomIngrdient).
Choix de la cl
Les attributs tant identifis, on doit maintenant choisir une cl pour chaque entit. Si lon prend lentit client, il est clair quaucun attribut ne peut convenir pour constituer une cl. De mme, lassociation de plusieurs attributs NomClient-Adresse, NomClientCompte, Compte-PointsRaPizz et autres ne permet pas de crer une cl. On ajoute alors classiquement un attribut identifiant qui sert de cl : ce peut tre un simple nombre ou un mlange de lettres et de nombres (alphanumriques) plus commode mmoriser. En utilisant ces mmes arguments, on est amen ajouter des attributs numriques comme cls pour les entits livreur et commande. Pour lentit pizza, on peut supposer que le nom de la pizza est significatif et quil peut donc servir de cl. En effet, le catalogue de pizzas propos est restreint et codifi par le fait quil sagisse dune entreprise de type franchis . Il ny a pas dintrt pour le franchiseur, dun simple point de vue commercial, donner deux fois le mme nom une pizza. En pratique, mme si le nom est unique, on pourrait dcider de ne pas lutiliser car le contenu est un peu long. Lentit vhicule dispose dun champ identifiant : son numro dimmatriculation qui est par dfinition unique. Enfin, en ce qui concerne les ingrdients, il peut tre moins vident que le nom seul de lingrdient suffise lidentifier. Il est prfrable de lui ajouter un numro. On obtient les entits suivantes munies de leurs attributs : commande (NumCommande, DateCom, Taille, Retard) ; client (NumClient, NomClient, Adresse, Compte, PointsRaPizz) ; pizza (NomPizza, Prix) ; livreur (CodeLivreur, NomLivreur, Tlphone) ; vhicule (NumImmat, Marque, Type) ; ingrdient (NumIngre, NomIngrdient).
Associations et attributs
On peut, partir des phrases qui ont permis de reprer les entits, en dduire les associations suivantes : Livre entre Livreur et Commande ; Transporte entre Vhicule et Commande ; Passe entre Client et Commande ; Constitue entre Pizza et Commande ; Compose entre Pizza et Ingrdient. Il reste dterminer les attributs ventuels des associations. Dans notre cas, le choix dutiliser une entit commande fait que lon regroupe naturellement dans cette entit les attributs qui auraient pu se retrouver sur les associations. ventuellement, une date de commande pourrait tre un attribut de lassociation Passe si elle tait diffrente de la date de la commande. On peut cependant imaginer que ce genre
dentreprise ne prend pas les commandes lavance : on commande une pizza lorsque lon a faim. On se trouve donc dans le cas un peu particulier o aucune des associations ne possde dattribut (voir figure 5.1). Figure 5.1
Modle entitassociation Livraisons de pizzas sans cardinalits.
Commande Livreur
# CodeLivreur NomLivreur Tlphone
Transporte Livre
Passe
Client
# NumClient NomClient Adresse Compte PointsRapizz
Constitue
Vhicule
# NumImmat Marque Type
Ingrdient
# NumIngre NomIngre
Compose
Pizza
# NomPizza Prix
132
Chapitre Association Livre Livreur : un livreur peut-il navoir jamais livr de pizzas et peut-il en avoir livr plusieurs ? Un livreur a au moins effectu une (1) livraison, sinon il nest pas considr comme tel. On peut imaginer que lon ne rentre les informations associes un livreur qu partir du moment o il a rellement effectu une livraison. Il est suppos faire plusieurs (n) livraisons. Les cardinalits associes sont de type 1-n. Commande : une commande peut-elle avoir t livre par plusieurs livreurs ou par aucun ? Une commande est livre par un (1) et un (1) seul livreur. Les cardinalits associes sont de type 1-1. Association Transporte Vhicule : un vhicule peut-il navoir jamais livr de pizzas et peut-il en avoir livr plusieurs ? Dans ce cas, la situation nest pas tout fait la mme que pour les livreurs. On peut imaginer que les informations concernant un vhicule pourraient tre insres dans la base de donnes sans que le vhicule nait encore effectu une livraison (0). Si ctait le cas, on aurait des cardinalits de type 0-n. On choisit ici des cardinalits associes de type 1-n. Dans les deux cas, un vhicule est suppos tre utilis pour livrer plusieurs (n) commandes. Commande : une commande peut-elle avoir t livre par plusieurs vhicules ou par aucun ? Une commande est livre par un (1) et un (1) seul vhicule. Les cardinalits associes sont de type 1-1. On obtient le modle entit-association suivant (voir figure 5.2) : Figure 5.2
Modle entitassociation Livraisons de pizzas avec cardinalits.
1,n 1,1
Commande
# NumCommande DateCom Taille Retard
1,1
Passe
0,n
Client
# NumClient NomClient Adresse Compte PointsRapizz
Livreur
# CodeLivreur NomLivreur Tlphone
Vhicule
# NumImmat Marque Type
Ingrdient
1,n
Pizza
Compose 1,n
# NumIngre NomIngre
# NomPizza Prix
Remarque
Toutes les associations qui lient lentit commande sont de cardinalit 1-1. On aurait pu ainsi considrer lentit commande comme une association qui serait alors quaternaire.
Cependant, si cela est possible, on prfre cependant viter les associations autres que binaires, plus complexes transformer en relations. De plus, le modle UML ne propose pas de solution trs cohrente pour reprsenter les associations ternaires ou de plus haut degr.
134
Chapitre plification du nombre de relations au dtriment de la lisibilit gnrale. On perd ainsi une partie de linformation sur le lien entre ces entits. Ce processus peut tre expliqu de la manire suivante. La cl de lassociation livre est compose des attributs CodeLivreur & NumCommande. Du fait de la cardinalit 1-1, on peut en dduire qu un numro de commande correspond un et un seul code du livreur. La cl peut alors tre simplifie et rduite lattribut NumCommande. On obtient la relation : livre (NumCommande, CodeLivreur) Les deux relations commande et livre possdent alors la mme cl ; on peut les fusionner. On obtient la relation commande augmente suivante : commande (NumCommande, DateCom, Taille, Retard, CodeLivreur). Les associations transporte , passe et constitue sont de cardinalit 1-1 par rapport lentit commande . On peut aussi fusionner ces relations avec la relation commande . On obtient : commande (NumCommande, DateCom, Taille, Retard, CodeLivreur, NumImmat, NumClient, NomPizza). Voici la liste des relations ainsi constitues : client (NumClient, NomClient, Adresse, Compte, PointsRaPizz) ; pizza (NomPizza, Prix) ; livreur (CodeLivreur, NomLivreur, Telephone) ; vhicule (NumImmat, Marque, Type) ; ingrdient (NumIngre, NomIngredient) ; commande (NumCommande, DateCom, Taille, Retard, CodeLivreur, NumImmat, NumClient, NomPizza) ; compose (NumIngre, NomPizza).
136
Chapitre
Remarque
En pratique, on neffectue pas toujours cette tape de manire stricte compte tenu de la complexit que produit la dcomposition par le processus de normalisation. Il est parfois prfrable de conserver un peu de redondance pour limiter le nombre de tables et prserver ainsi lefficacit du systme.
PointsRaPizz : nombre de points de type entier Table pizza NomPizza : chane de caractres Prix : solde de type rel ( renseigner obligatoirement) Table livreur CodeLivreur : code simple de type entier NomLivreur : chane de caractres ( renseigner obligatoirement) Telephone : chane de caractres ( renseigner obligatoirement) Table vehicule NumImmat : chane de caractres Marque : chane de caractres ( renseigner obligatoirement) Type : chane de caractres ( renseigner obligatoirement) Table ingredient NumIngre : code simple de type entier NomIngrdient : chane de caractres ( renseigner obligatoirement) Table commande NumCommande : code simple de type entier DateCom : type date ( renseigner obligatoirement) Taille : chane de caractres ( renseigner obligatoirement) Retard : chane de caractres ( renseigner obligatoirement) CodeLivreur : code simple de type entier NumImmat : chane de caractres NumClient : chane de caractres NomPizza : chane de caractres Table compose NumIngre : code simple de type entier NomPizza : chane de caractres ( renseigner obligatoirement)
Contraintes dintgrit
Les contraintes permettent de dcrire de manire plus prcise les ensembles auxquels appartiennent les champs. Intervalle. Le champ Prix de la table pizza peut tre limit lintervalle 1 .. 30. On pourrait dfinir un intervalle de validit pour les dates de commande (champ DateCom de la table commande), par exemple la date de commande doit tre suprieure ou gale la date du jour. numration. Le champ Retard de la table commande doit contenir les valeurs O ou N. Le champ Taille de la table commande doit contenir les valeurs naine , humaine ou ogresse . Comme il sagit dune franchise o les contenus sont norma-
138
Chapitre liss, on peut imaginer que lensemble des noms de pizzas est connu (par exemple, quatre saisons, margherita). Le champ NomPizza apparat dans plusieurs tables, mais la contrainte de type numration porterait uniquement sur le champ NomPizza de la table pizza. Les autres champs NomPizza sont plutt soumis des contraintes de rfrences comme on va le voir dans la partie consacre aux rfrences. Rfrence au contenu dune table. Les champs cls qui proviennent des associations transformes en relations font rfrence au contenu des relations qui proviennent des entits. Pour la relation compose, le champ NumIngre fait rfrence au contenu du champ NumIngre de la table ingrdient et le champ NomPizza au contenu du champ NomPizza de la table pizza. En pratique, ici, la plupart des champs fusionns de la relation commande font aussi rfrence des champs dautres relations. CodeLivreur de la relation commande. Rfrence au champ CodeLivreur de la relation livreur. NumImmat de la relation commande. Rfrence au champ NumImmat de la relation vehicule. NumClient de la relation commande. Rfrence au champ NumClient de la relation client. NomPizza de la relation commande. Rfrence au champ NomPizza de la relation pizza.
Table pizza
CREATE TABLE pizza( NomPizza CHAR(30) PRIMARY KEY, Prix CHAR(30) NOT NULL,
Table ingredient
CREATE TABLE ingredient( NumIngre INT PRIMARY KEY , NomIngre CHAR(30) NOT NULL );
Table vehicule
CREATE TABLE vehicule( NumImmat CHAR(30) PRIMARY KEY, Marque CHAR(30) NOT NULL, Type CHAR(30) NOT NULL );
Table livreur
CREATE TABLE livreur ( CodeLivreur INT PRIMARY KEY, NomLivreur CHAR(30) NOT NULL, TeleLivreur CHAR(30) NOT NULL );
Table compose
CREATE TABLE compose ( NomPizza CHAR(30) REFERENCES pizza(NomPizza), NumIngre INT REFERENCES ingredient(NumIngre), PRIMARY KEY (NomPizza, NumIngre) );
Table commande
CREATE TABLE commande ( NumCommande INT PRIMARY KEY, DateCom DATE, Taille CHAR(30) NOT NULL, Retard CHAR(1) NOT NULL, NumClient INT REFERENCES client(NumClient), NomPizza CHAR(30) REFERENCES pizza(NomPizza), CodeLivreur INT REFERENCES livreur(CodeLivreur), NumImmat CHAR(30) REFERENCES vehicule(NumImmat), CHECK Taille in (Ogresse,Humaine,Naine), CHECK Retard in (O,N) );
Exemple de cration dun index appel Index_NumCommande sur le champ NumCommande de la table commande dans lordre ascendant. Linstruction de cration dun index nest pas toujours normalise et la syntaxe peut diffrer suivant les SGBD.
CREATE INDEX Index_NumCommande ON commande (NumCommande ASC) ;
La cration des tables ne peut pas se faire dans nimporte quel ordre. Il faut dabord crer les tables auxquelles ont fait rfrence, puis seulement ensuite les autres tables. En dautres termes, on ne pourra crer la table commande quaprs avoir cr les tables client, pizza, livreur et vehicule. La destruction des tables se fait logiquement dans lordre inverse : on ne peut dtruire une table qui est rfrence par une autre table. Cest le SGBD qui ralise ces vrifications.
140
Chapitre
4.1 MENU
On veut extraire les donnes qui servent imprimer la carte, ce qui signifie que lon veut disposer du nom de chaque pizza, de son prix et des ingredients qui la composent. Pour ce faire, on commence par identifier les tables o se trouvent les champs que lon veut projeter : Le nom de la pizza est dans la table pizza. Le prix de la pizza est dans la table pizza. Les noms des ingrdients se trouve dans la table ingredient. Le lien entre ces deux tables est matrialis par le modle entit-association : il sagit de lassociation compose. Cette dernire est devenue la relation compose. On effectue donc une double jointure entre les trois tables pizza, ingredient et compose. Les tables pizza et compose seront jointes sur le champ NomPizza et les tables ingredient et compose seront jointes sur le champ NumIngre. Il y a deux manires dcrire une jointure. Une jointure peut tre La premire consiste lapprhender comme une slection sur un produit cartsien. Lcriture est plus pdagogique, mais totalement inefficace du point de vue du SGBD qui doit effectuer le produit cartsien puis slectionner les lignes.
SELECT pizza.NomPizza, ingredient.NomIngre, pizza.Prix FROM pizza, ingredient, compose WHERE pizza.NomPizza = compose.NomPizza AND ingredient.NumIngre = compose.Numingre;
On se trouve dans le cas trs classique de deux entits lies par une association, qui donnent trois tables (pizza et ingredient lies par compose). Il sera ncessaire dutiliser un langage de programmation pour obtenir un affichage lgant du nom de la pizza, de son prix et des ingrdients qui la composent. En effet, pour chaque nom de pizza, on obtiendra autant de lignes que dingrdients.
client, pour le nom du client ; pizza, pour le nom et le prix de la pizza ; livreur, pour le nom du livreur ; vehicule, pour le type du vhicule ; commande, pour le retard, le numro de commande et surtout pour tablir le lien entre toutes les tables.
SELECT C.NumCommande, CI.NomClient, P.NomPizza, P.Prix, LI.NomLivreur, V.Type, C.Retard FROM commande C JOIN livreur LI JOIN pizza P JOIN client CI JOIN vehicule V ON (C.CodeLivreur=LI.CodeLivreur AND P.NomPizza=C.NomPizza AND C.NumClient=CI.NumClient AND C.NumImmat=V.NumImmat) ORDER BY C.NumCommande ;
La table pivot est ici la table commande qui assure la jointure avec toutes les autres tables. Cela confirme lintuition que lentit commande aurait pu tre considre comme une association n-aire. Sur une requte aussi simple, on remarque que le travail du SGBD est assez lourd puisquil doit effectuer la jointure de cinq tables. Cest la raison pour laquelle on prfre parfois utiliser des relations, et donc des tables, avec une certaine redondance afin damliorer les performances : lopration de jointure est coteuse. Une stratgie couramment employe consiste grer en interne une base de donnes sans redondance et gnrer une table redondante qui servira faire les requtes. On dispose ainsi dune garantie de cohrence et des performances prserves. Les bases de donnes en ligne accessibles par le Web sur lesquelles on effectue beaucoup de requtes fonctionnent de cette manire. On rserve bien sr cette mthode aux bases de donnes dont le contenu est assez stable : lopration de regnration de bases chaque changement est coteuse.
Cette requte est typique des requtes de vrification que ladministrateur dune base doit effectuer pour procder certaines vrifications de cohrence. Cela est surtout vrai lorsque la base de donnes na pas t conue en intgrant les contraintes dintgrit indispensables.
142
Chapitre
On peut crire ces diffrentes requtes dans une seule en utilisant les sous-requtes (ou requtes imbriques). Cependant, il est prudent daccomplir dabord les tapes prcdentes. En dcomposant, il est possible de vrifier les rsultats chaque tape et dviter ainsi un certain nombre derreurs.
SELECT A.NumClient, A.NomClient FROM (SELECT commande.NumClient, NomClient, COUNT(*) AS NombreCommande FROM client JOIN commande ON client.NumClient=commande.NumClient GROUP BY commande.NumClient) A WHERE R1.NombreCommande > (SELECT AVG(B.NombreCommande)
FROM (SELECT commande.NumClient, NomClient, COUNT(*) AS NombreCommande FROM client JOIN commande ON client.NumClient=commande.NumClient GROUP BY commande.NumClient) B )
Il sagit exactement des mmes requtes que celles obtenues lors des tapes prcdentes. Attention, tous les SGBD ne permettent pas dimbriquer les requtes.
144
Chapitre
SELECT commande.NumCommande, pizza.Prix*commande.Taille_Prix AS Prix_Commande FROM commande JOIN pizza ON commande.NomPizza=pizza.NomPizza;
On obtient alors les instructions SQL suivantes pour calculer le prix dune commande. Il est ncessaire de faire une jointure entre les trois tables commande, pizza (pour le prix) et tarification (pour le coefficient).
SELECT commande.NumCommande, pizza.Prix*tarification.Coefficient AS Prix_Commande FROM commande JOIN pizza JOIN tarification ON commande.NomPizza=pizza.NomPizza AND commande.Taille=tarification.Taille;
La pizza de la commande a une et une seule taille : la cardinalit est de type 1-1. Une tarification peut navoir jamais t utilise pour une commande et plusieurs commandes diffrentes peuvent avoir la mme tarification : la cardinalit est de type 0-n (voir figure 5.3).
1,1 1,n
Figure 5.3
Modle entitassociation Livraisons de pizzas avec cardinalits.
Commande
# NumCommande DateCom Retard
1,1 Utilise
1,1
0,n Passe
Client
# NumClient NomClient Adresse Compte PointsRapizz
Livreur
# CodeLivreur NomLivreur Tlphone
Livre 1,1
1,1
Tarification
0,n
Vhicule
# NumImmat Marque Type
#Taille Coefficient
Pizza
1,n Compose
Ingrdient
# NumIngre NomIngre
1,n
# NomPizza Prix
On dcompose lassociation emploie et lentit tarification : Lentit tarification devient une relation dont la cl est Taille Lassociation a une cardinalit 1-1, il sagit du cas particulier voqu prcdemment, la relation produite par lassociation est aspire par la relation cre par lentit associe avec la cardinalit 1-1, cest--dire commande. La fusion produit le dplacement de lattribut Taille vers la relation commande. Finalement, la relation commande reste inchange mme si lentit dont elle est issue a t modifie au niveau du modle entit-association. On a introduit une nouvelle relation tarification comme cela a t fait de manire intuitive prcdemment. On obtient lensemble de relations suivant : client (NumClient, NomClient, Adresse, Compte, PointsRaPizz) ; pizza (NomPizza, Prix) ; livreur (CodeLivreur, NomLivreur, Tlphone) ; vhicule (NumImmat, Marque, Type) ; ingrdient (NumIngre, NomIngrdient) ; commande (NumCommande, DateCom, Taille, Retard, CodeLivreur, NumImmat, NumClient, NomPizza) ; compose (NumIngre, NomPizza) ; tarification(Taille, Coefficient).
146
Chapitre
pilogue
Cet exemple illustre comment le modle entit-association peut tre remis en cause par ncessit. Le problme de reprsentation de dpart a provoqu une modification du modle par une dmarche inverse de celle utilise prcdemment : on a remis en cause le modle entit-association partir de lensemble des relations. En revanche, il ne faut pas oublier de modifier le modle entit-association pour quil soit cohrent avec lensemble des tables employes dans le SGBD. Les tables sont inutilisables sans modle descriptif. On peut le constater avec ce systme relativement simple qui possde dj huit tables. Les allers-retours entre les diffrents niveaux de modles sont frquents dans la vie dune base de donnes.
Remarque
Les requtes retournent toujours un rsultat. Cependant, on ne peut tre sr que ce dernier reprsente la rponse exacte la question pose. Il est ncessaire de systmatiquement vrifier le rsultat sur un jeu de donnes rduit. De mme quen programmation, on ne peut prouver quun programme ralise correctement ce quon lui demande dans tous les cas de figure ; il est difficile dtablir quune requte fournit la rponse adquate lorsque le nombre denregistrements devient lev.
Rsum
Ce chapitre dtaille lensemble des tapes ncessaires la ralisation dune base de donnes, mme les plus fastidieuses. La grande difficult est de passer dun nonc en langage parl, qui fait gnralement suite un entretien avec les commanditaires et les utilisateurs, un systme utilisable en pratique et efficace. Le flot dinformations recueilli doit tre ordonn et structur. Lexemple choisi est peu complexe, mais il permet daborder quelques questions essentielles. On saperoit cette occasion que lensemble des tables utilises dans le SGBD devient rapidement illisible si lon ne possde pas un schma descriptif (modle entit-association ou UML) correct. La partie Interrogation illustre les catgories dutilisations et dinterrogations classiques dune base de donnes. Lide est de donner des indications afin didentifier le type de requte SQL utiliser en fonction de la question exprime en langage courant. La dmarche suggre est de toujours dcomposer les questions en sous-questions plus simples rsoudre puis de procder par tapes. Un des exemples aborde ensuite le cas o, au cours de lutilisation de la base de donnes, il est impossible de trouver la solution en raison dune reprsentation inadquate. Il est alors ncessaire de remettre en cause le modle utilis : Soit on modifie le contenu des tables et lon rpercute les modifications sur le modle descriptif utilis. Soit on modifie le modle descriptif et lon ritre les tapes de passage au modle relationnel. La seconde mthode est la solution la plus juste dun point de vue thorique. Mais, en pratique, on utilise une combinaison des deux approches pour obtenir le rsultat. Il est essentiel de comprendre quil ny a pas de solution unique en base de donnes. Le modle est frquemment adapt et aucune reprsentation nest fige. De mme que la ralit peut tre envisage diffremment suivant les personnes, il existe souvent plusieurs visions valides.
Exercices
EXERCICE 1
REPRSENTATION
UML
Reprsentez le modle entit-association en utilisant le formalisme UML. On part du modle entit-association final, celui auquel on a ajout lentit tarification . La partie dUML qui est utilise est le diagramme de classe ; celui-ci comprend le nom de la classe, la description des attributs et les mthodes associes la classe. Dans ce cas, on nutilise pas la partie objet et donc il ny a pas de mthodes associes aux classes. Une entit est reprsente par un diagramme de classe. Avec UML, il est possible dintgrer les notions de contraintes dintgrit au niveau du schma. On peut par exemple spcifier que lattribut retard de lentit commande ne pourra prendre comme valeurs que O et N . Les associations utilises dans ce message nont pas dattributs. Une diffrence majeure est que les cardinalits seront positionnes de manire inverse par rapport au modle entit-association (voir figure 5.4). Figure 5.4
Modle UML Livraisons de pizzas avec cardinalits.
Livreur
1..1 Livre 1..n Passe
Client
1..1
Commande
# NumCommande DateCom Retard
0..n
0..n
0..n
1..n
Transporte
Tarification
1..1
Vhicule
# NumImmat Marque Type
#Taille Coefficient
1..1
Pizza
1..n
Ingrdient
Compose
# NomPizza Prix
# NumIngre NomIngre
1..n
EXERCICE 2
SQL
Combien de pizzas ont-elles t livres en retard ? Quelle est la perte occasionne par ces retards ? Pour calculer le nombre de pizzas livres en retard, il faut se souvenir dun point important que lon a fix comme axiome lors de llaboration du modle : une pizza est associe une commande et une seule. Une commande ne contient quune seule pizza. Cest important : si ce ntait pas le cas, la requte serait beaucoup plus complexe.
148
Chapitre Le type de question qui inclut le mot combien suggre que lon va effectuer un comptage sur la table. Il nous suffit de compter le nombre denregistrements dont le champ retard est positionn Oui . On a vu lors de la dfinition de la table commande que le contenu du champ retard a t normalis et restreint par une contrainte dintgrit aux valeurs N et O . Ces rflexions conduisent la simple requte suivante :
SELECT COUNT(*) AS NombreRetard FROM commande WHERE retard=O;
On compte le nombre de lignes de la table commande dont le champ commande est gal O . On ne spcifie pas de nom de champ dans la fonction COUNT de SQL, car il sagit dun calcul indpendant dun champ donn. Pour connatre la perte occasionne, on calcule la somme du prix de chaque commande. Le modle a t modifi pour pouvoir calculer directement cette information. On a besoin du prix de base de la pizza qui se trouve dans la table pizza et du coefficient qui se trouve dans la table tarification. On effectue une jointure sur ces trois tables.
SELECT SUM(pizza.prix*tarification.coefficient) AS PerteRetard FROM commande JOIN pizza JOIN tarification ON commande.NomPizza=pizza.NomPizza AND commande.Taille=tarification.Taille WHERE commande.retard=O;
La fonction SQL SUM a besoin du contenu prcis du champ concern par le calcul. Ici, il sagit dune expression constitue partir du prix et du coefficient. Il est prfrable de prfixer les noms de champ par le nom de la table do ils proviennent pour viter les ambiguts et faciliter la lecture ultrieure de la requte. Les ambiguts sont signales par le SGBD qui refuse dexcuter la requte. On aurait pu crire les jointures en utilisant classiquement un produit cartsien et une slection. Dans ce cas, les expressions qui servent la jointure sont mlanges celles qui servent faire la slection dans la clause WHERE. De plus, la requte est effectue de manire beaucoup moins efficace par le SGBD ; cela est nettement perceptible lorsque lon dispose de tables de taille importante.
SELECT SUM(pizza.prix*tarification.coefficient) AS PerteRetard FROM commande, pizza, tarification WHERE commande.NomPizza=pizza.NomPizza AND commande.Taille=tarification.Taille AND commande.retard=O;
Les deux tables rsultat sont des tables qui possdent une seule ligne et une seule colonne. On peut utiliser ces valeurs par exemple pour faire une comparaison (voir lun des exercices suivants) en les associant par un produit cartsien la table sur laquelle on veut effectuer la comparaison.
EXERCICE 3
CODE
SQL ET SIGNIFICATION
Imaginez quel type de question a voulu rpondre la personne qui a fait cette requte.
Exercices
La requte retourne un rsultat, car la syntaxe est correcte et le type des champs sur lesquels on a effectu la jointure sont de type compatible et contiennent des valeurs communes. Bien videmment, le rsultat na aucun sens dun point de vue la ralit. Le schma entit-association montre que les liens entre les tables client et livreur passent par la table commande et les associations livre et passe. Il sagit du cas typique qui illustre le fait quune requte donne toujours un rsultat, mme sil na aucun sens. En aucun cas, cette requte ne permettrait deffectuer des recherches de corrlation entre le livreur et le client. Si lon cherche afficher le nom du client et le nom du livreur correspondant par commande, on doit utiliser la table commande mme si lon ne projette aucun champ de la table commande. Pour faciliter la lecture et reprer dventuelles corrlations, on ordonne par noms de clients.
SELECT client.NomClient, livreur.NomLivreur FROM livreur JOIN commande JOIN client ON livreur.CodeLivreur=commande.CodeLivreur AND client.NumClient= commande.NumClient ORDER BY client.NomClient;
Pour savoir quels clients sont toujours livrs par le mme livreur, la dmarche serait plus complexe.
EXERCICE 4
AGRGATS ET SLECTION
Donnez le chiffre daffaires par pizza vendue. On ne tient pas compte ce niveau des pizzas gratuites obtenues grce aux points de fidlit ou en raison dun retard de livraison. La mthode conseille dans ce chapitre est daborder la question en dcomposant le problme. Pour calculer le chiffre daffaires, il faut dabord regrouper les commandes par pizza et ensuite effectuer le calcul. La notion de regroupement suggre lemploi des agrgats. Le nom de la pizza est directement accessible dans la table commande. Pour vrifier combien de commandes ont t passes par pizza, on les compte.
SELECT commande.NomPizza, COUNT(*) AS NombreCommande FROM commande GROUP BY commande.NomPizza;
Pour calculer le prix, on a besoin du prix de base qui se trouve dans la table pizza et du coefficient qui se trouve dans la table tarification.
SELECT commande.NomPizza, COUNT(*) AS NombreCommande, SUM(pizza.prix*tarification.coefficient) AS TotalCommande FROM commande JOIN pizza JOIN tarification ON commande.Taille=tarification.Taille AND commande.NomPizza=pizza.NomPizza GROUP BY commande.NomPizza ORDER BY TotalCommande;
On trie le rsultat en utilisant le champ calcul TotalCommande. Lopration de tri se fait donc aprs les oprations de jointures, dagrgation et de calculs. Il est possible de raliser une slection sur le rsultat final de cette opration en ne considrant que les pizzas dont le chiffre daffaires dpasse le nombre 200 . On nemploie pas dans ce cas le mot cl WHERE qui sert raliser les slections sur une table standard. On utilise le mot cl HAVING qui fait une slection sur le rsultat des calculs sur les agrgats. Cette slection se fait, de mme que le tri, la fin de lopration sur la table rsultat finale.
SELECT commande.NomPizza, COUNT(*) tion.coefficient) AS TotalCommande AS NombreCommande, SUM(pizza.prix*tarifica-
150
Chapitre
FROM commande JOIN pizza JOIN tarification ON commande.Taille=tarification.Taille AND commande.NomPizza=pizza.NomPizza GROUP BY commande.NomPizza HAVING TotalCommande > 200 ORDER BY TotalCommande;
En revanche, si lon avait voulu liminer du rsultat les pizzas dont le prix de vente nest pas assez lev considrant que cela fausse le rsultat, le mode de slection ne serait pas le mme. Il faudrait raliser une slection sur lensemble de dpart avant deffectuer les agrgats et les calculs ; dans ce cas, on utiliserait le mot cl WHERE.
SELECT commande.NomPizza, COUNT(*) AS NombreCommande, SUM(pizza.prix*tarification.coefficient) AS TotalCommande FROM commande JOIN pizza JOIN tarification ON commande.Taille=tarification.Taille AND commande.NomPizza=pizza.NomPizza WHERE pizza.prix > 10 GROUP BY commande.NomPizza ORDER BY TotalCommande;
Dans le premier cas, la slection est faite a fortiori ; dans le second, a priori.
EXERCICE 5
REQUTES COMBINES
Quel est le nom du livreur qui a le plus de retard ? On dcompose le problme : calcul du nombre de retards par livreur ; calcul du maximum de ces retards ; slection du nom du livreur qui a le maximum de retard.
Calcul du nombre de retards par livreur. Le mot par suggre comme prcdemment lemploi dagrgats sur lesquels on utilise la fonction de comptage.
CREATE TEMPORARY TABLE requete1 SELECT commande.CodeLivreur, COUNT(*) AS NombreRetard FROM commande GROUP BY commande.CodeLivreur ORDER BY NombreRetard ;
Calcul du maximum de ces retards. On utilise la fonction SQL MAX sur le contenu de la table prcdente.
CREATE TEMPORARY TABLE requete2 SELECT MAX(NombreRetard)AS MaxRetard FROM requete1 ;
Il sagit dun cas o lon effectue dans la mme requte un produit cartsien et une jointure.
Exercices
Slection du nom du livreur qui a le maximum de retard. Il est demand dafficher le nom du livreur, disponible uniquement dans la table livreur. On fait classiquement une jointure pour le rcuprer. On doit galement disposer de la valeur du maximum de retard que lon trouve dans la table temporaire requete2. On lassocie lopration sur les deux autres tables par un produit cartsien. Cela ne change pas le nombre de lignes du rsultat car la table requete2 na quune ligne.
SELECT livreur.NomLivreur FROM requete1 JOIN livreur ON livreur.CodeLivreur=requete1.CodeLivreur, requete2 WHERE requete1.NombreRetard=requete2.MaxRetard ;
Avec un peu dexprience, on saperoit quil sagit dune requte semblable celle que lon prsente dans le chapitre pour connatre les clients qui commandent plus que la moyenne.
EXERCICE 6
Quel est le nom du livreur qui nest jamais en retard ? La tournure de phrase qui na jamais semble suggrer lemploi dune jointure externe, comme ctait dj le cas dans le chapitre o on a dtermin les vhicules nayant jamais servi. Cependant, cette jointure externe sert dterminer les entits non associes dans une jointure. Ici, on peut obtenir linformation du retard directement dans la table commande. Si lon considre les rsultats de lexercice prcdent, on a calcul le nombre de retards par livreur par la requte suivante.
CREATE TEMPORARY TABLE requete1 SELECT commande.CodeLivreur, COUNT(*) AS NombreRetard FROM commande GROUP BY commande.CodeLivreur ORDER BY NombreRetard ;
Un livreur naura jamais t en retard si le nombre de retards ainsi calcul est gal zro.
SELECT requete1.CodeLivreur FROM requete1 WHERE requete1. NombreRetard=0 ;
On cherche le nom du livreur et non pas son code. Il y a deux manires de procder : Soit on fait une jointure sur la table livreur pour la premire requte de manire inclure le nom du livreur dans la table rsultat.
CREATE TEMPORARY TABLE requete1 SELECT commande.CodeLivreur, livreur.NomLivreur, COUNT(*) AS NombreRetard FROM commande JOIN livreur ON commande.CodeLivreur=livreur.CodeLivreur GROUP BY commande.CodeLivreur ORDER BY NombreRetard SELECT requete1.NomLivreur FROM requete1 WHERE requete1. NombreRetard=0 ;
152
Chapitre Il est possible de regrouper ces deux requtes en une seule. La stratgie de regroupement dpendra du SGBD employ. Le cas serait diffrent si lon cherchait identifier les noms des livreurs qui nont jamais effectu de livraison. Laction de livraison est reprsente par lassociation livre dans le modle entit-association. Cette association, puisque de cardinalit 1-1, a disparu en tant que table et a t intgre dans la relation commande issue de lentit commande. En rsum, linformation nest disponible que par une jointure entre les tables commande et livreur. Lide ici est de trouver les codes des livreurs prsents dans la table livreur mais pas dans la table commande. Daprs notre dfinition du modle entitassociation, ce ne devrait pas tre possible puisque la cardinalit du point de vue (du ct) de lentit livreur est de type 1-n : un livreur a au moins livr une pizza et est susceptible den livrer plusieurs. On emploie alors une jointure externe qui nous permet dinclure dans le rsultat les lignes nayant pas de correspondance dans la table commande.
SELECT * FROM livreur LEFT JOIN commande ON livreur.CodeLivreur=commande.CodeLivreur ;
Pour slectionner ceux qui nauraient pas effectu de livraison, on choisit une ligne dont un champ issu de la table commande est vide (a une valeur nulle en SQL). On projette sur le champ NomLivreur de la table commande qui tait linformation demande.
SELECT livreur.NomLivreur FROM livreur LEFT JOIN commande ON livreur.CodeLivreur=commande.CodeLivreur WHERE commande.CodeLivreur IS NULL ;
EXERCICE 7
La requte de mise jour serait la suivante, on rcupre les champs prix de la commande de la premire requte pour effectuer la mise jour du solde du compte du client dans la table client.
UPDATE client,requete1 SET Compte=Compte-requete1.Prix_Commande WHERE client.NumClient=requete1.NumClient ;
Exercices
Il est prvu de pouvoir lancer dans un SGBD une requte au moment o lon effectue une opration : on appelle cela des triggers ou procdures stockes. Typiquement, il faudrait lancer cette requte chaque fois que lon cre une commande.
EXERCICE 8
Si le taux nest pas fixe, il faut linclure dans le systme dinformation ; on cre une table taxe avec une ligne et une colonne, qui contiendra uniquement le taux.
CREATE TABLE taxes ( Taux FLOAT ); INSERT INTO taxes (Taux) VALUES (19.6) ;
On rcupre la valeur du taux comme on la fait prcdemment, en faisant un produit cartsien avec la table taxes.
SELECT NomPizza, Prix*(1+Taux) AS Prix_Ttc FROM pizza, taxes ;
Dans ce second cas, il faudrait pour tre complet ajouter lentit taxes au modle entitassociation. Elle ne serait lie aucune entit par une association.
EXERCICE 9
154
Chapitre
1. Ralisez le modle conceptuel des donnes, spcifiez les cardinalits. 2. Dduisez-en le modle entit-association correspondant. 3. Crez les tables correspondantes (commande SQL create table), en spcifiant les cls uniques. Indiquez les contraintes dintgrit pour ces tables. 4. Donnez la requte permettant de lister les rservations effectues en 2006. Les numros de chambres ne peuvent pas constituer un identifiant de lentit Chambre, dans la mesure o les deux htels possdent des chambres ayant le mme identifiant. En consquence, il convient dajouter un identifiant unique supplmentaire lentit Chambre. La priode de rservation modlise laide dune date de dbut et dune date de fin dpend fonctionnellement de la chambre et du client. Le nombre de jour sera dduit partir de ces donnes laide dun traitement informatique afin de procder la facturation du sjour. Le type de chambre dterminant le prix de la chambre, une entit supplmentaire Type doit tre cre. 1. Modle conceptuel Htel(ID_Hotel, Nom_hotel, CP, Ville) Chambre(ID_Chambre, Num_chambre) Type(ID_Type, Libelle, Prix) Reserver(Date_debut, Date_Fin) entre Client et Chambre (1,n 0,n) Composer() entre Chambre et Hotel (1,1 1,n) Correspondre() entre Chambre et Type (1,1 0,n) 2. Modle relationnel Hotel(ID_Hotel, Nom_hotel, CP, Ville) Chambre(ID_Chambre, Num_chambre, ID_hotel, ID_Type) Type(ID_Type, Libelle, Prix) Reserver(Code_client, ID_Chambre, Date_debut, Date_fin,) Client(Code_client, Nom_client, Prenom_client, Num_tel, Adresse, CP, Ville) 3. Code SQL de cration des tables
CREATE TABLE HOTEL ID_HOTEL INT PRIMARY KEY, NOM_HOTEL VARCHAR(20) NOT NULL, CP VARCHAR(5) NOT NULL, VILLE VARCHAR(50) NOT NULL ) ;
CREATE TABLE CHAMBRE( ID_CHAMBRE INT PRIMARY KEY, NUM_CHAMBRE INT NOT NULL, ID_HOTEL INT REFERENCES HOTEL(ID_HOTEL), ID_TYPE INT NOT NULL REFERENCES TYPE(ID_TYPE) ) ;
CREATE TABLE TYPE( ID_TYPE INT PRIMARY KEY, LIBELLE VARCHAR(50) NOT NULL, PRIX FLOAT(10,2), CHECK LIBELLE IN (SIMPLE,DOUBLE,ROYALE) ) ;
Exercices
CREATE TABLE RESERVER( CODE_CLIENT VARCHAR(9) NOT NULL REFERENCES CLIENT(CODE_CLIENT, ID_CHAMBRE INT NOT NULL REFERENCES CHAMBRE(ID_CHAMBRE), DATE_DEBUT DATE, DATE_FIN DATE ) ;
CREATE TABLE CLIENT( CODE_CLIENT VARCHAR(9) PRIMARY KEY, NOM_CLIENT VARCHAR(50) NOT NULL, PRENOM_CLIENT VARCHAR(50) NOT NULL, NUM_TEL VARCHAR(10) NOT NULL, ADRESSE VARCHAR(250), CP VARCHAR(5), VILLE VARCHAR(50) NOT NULL ) ;
156
Chapitre
Ce chapitre traite de la scurit des donnes qui est une notion fondamentale des bases de donnes. En effet, le pire pour une base de donnes est la perte ou la modification de donnes. Des problmes srieux peuvent tre provoqus de manire intentionnelle ou accidentelle, mais le rsultat obtenu est le mme. Lactivit des organisations repose sur les donnes : il convient par consquent de les protger, mais galement den assurer la disponibilit permanente. On distinguera plusieurs niveaux de granularit quant aux recommandations gnrales concernant la scurit des donnes : la protection de laccs la machine dun point de vue physique ou rseau, les aspects de dure de vie du systme ainsi que la politique de sauvegarde ; la politique de restriction daccs aux donnes du SGBD par des comptes et lutilisation des vues ; la capacit des outils du SGBD protger les oprations sur les donnes, les restaurer et revenir en arrire, comme pour les transactions. On introduit en fin de chapitre un outil complmentaire : le trigger . Les triggers (ou dclencheurs) sont utiliss pour forcer une bonne gestion du contenu des donnes lors des oprations dinsertion, de mise jour ou de suppression de donnes.
157
158
Chapitre impossible quun simple utilisateur efface les fichiers des autres, mais certains systmes sont plus permables que dautres. Dans le second cas, si lon peut devenir administrateur sur la machine concerne du point de vue du systme dexploitation, tout est possible. Sil sagit dun cas de malveillance, les dgts peuvent tre considrables. Les protections dans ce domaine ne dpendent pas spcifiquement de ladministrateur du SGBD, mais aussi de ladministrateur systme et rseau de lenvironnement dans lequel se trouve la machine qui hberge le SGBD. Le systme et les applications prsentes sur la machine doivent tre maintenus et mis jour rgulirement pour viter les problmes. Ladministrateur systme doit galement tenir jour les comptes utilisateurs qui possdent les droits daccs la machine et vrifier la qualit des mots de passe associs. Classiquement, une intrusion se fait en utilisant un compte oubli , cr par exemple pour un besoin ponctuel, dont le mot de passe est assez simple pour tre devin. Le SGBD luimme est une application parmi les autres ; il peut prsenter des failles et doit faire partie du programme des mises jour critiques. Cette tche est gnralement effectue par ladministrateur du SGBD, qui doit galement tenir jour les comptes dutilisateurs spcifiques du SGBD disposant de droits daccs la machine. En rsum, le systme sur lequel est hberge la base de donnes doit faire lobjet dun suivi permanent tous les niveaux. Il nest pas raisonnable dinstaller un SGBD sur une machine dont le systme ne peut tre mis jour ou dont les mises jour sont disponibles trop tardivement. Toute application prsente sur la machine peut recler des failles et tre le maillon faible de lensemble. Les informations de vulnrabilit et les correctifs sont fournis par les diteurs de ces applications. Dans notre cas, on doit porter une attention particulire une application importante : le SGBD. La ractivit des diteurs constitue un critre dcisif pour choisir un systme et un SGBD. Dun point de vue humain, la qualit de ladministration du systme et du rseau sur lequel se trouve la machine peut tre galement un lment du choix.
disparatra pas dans les annes venir. Il est important denvisager ds la conception lventualit dune migration vers un autre SGBD, ventuellement hberg par un autre systme.
160
Hbergement 3
Hbergement 2 Hbergement 3
protger qui est au centre du processus : les droits dutilisation de cet objet sont ensuite affects des couples de types (nom, identifiant). Le SGBD stocke les informations suivantes pour chaque objet quil contient : Le type de droit. Slection, cration, destruction Lobjet sur lequel sappliquent les droits. Une base de donnes, une table, une vue Le nom de lutilisateur. Lidentifiant, au sens du mot de passe. Le donneur des droits.
Remarque
En pratique, la plupart des SGBD intgrent une instruction pour crer un utilisateur et lui associer un identifiant qui reste unique. Mme si elle nest pas dfinie rellement dans la norme SQL, elle est frquemment de la forme :
CREATE USER <type de droit> IDENTIFIED BY <identifiant> ;
Cette instruction met jour le dictionnaire de donnes du SGBD. Ce dernier utilise les informations de lutilisateur pour authentifier la connexion au SGBD. L encore, le mode de connexion dpend du SGBD utilis. Par extension, celui-ci fournira en gnral une instruction du type DROP USER pour dtruire lutilisateur cr par la prcdente commande. Comme les informations du dictionnaire de donnes sont le plus souvent stockes dans des bases de donnes, on peut galement les manipuler avec des instructions SQL classiques de types INSERT et DELETE. La spcificit de linstruction CREATE USER est de possder une instruction de cryptage du mot de passe.
Compte tenu de la remarque prcdente, les diteurs intgrent souvent la notion plus classique dutilisateur dans un SGBD. Ce dernier permet en gnral de distribuer des autorisations un ensemble dutilisateurs qui constituent ainsi un groupe. Les tches de gestion en sont facilites, mais les groupes, qui reprsentent lorganisation de lentreprise, sont parfois complexes grer. Laffectation de droits une hirarchie de groupes et sous-groupes peut relever du casse-tte. Afin de rsoudre ce problme, on dispose dun autre modle de distribution des droits : le rle. Celui-ci dsigne un assortiment de droits que lon dsire affecter un objet du SGBD. Cest une vue inverse o les utilisateurs prennent le(s) rle(s) dont ils ont besoin pour pouvoir travailler sur les objets du SGBD qui les concernent. Linstruction pour crer un rle est la suivante :
CREATE ROLE consultation_seulement ;
Laffectation des droits un rle et la distribution de rles des utilisateurs sont prsentes la section suivante. La gestion des rles, mme sils font partie de la norme SQL, nest pas propose par tous les SGBD. Il en est de mme pour les groupes dutilisateurs ou tout simplement de la notion dutilisateur qui nexiste pas toujours dans le SGBD. En rsum, il ny a pas de rgle gnrale de gestion des autorisations de connexion au SGBD. Linitiative en est laisse lditeur du SGBD. Cet aspect peut provoquer des soucis lors de la migration vers un autre SGBD.
162
Chapitre
Voici un exemple dutilisation de GRANT. Ladministrateur cre un utilisateur pastorius avec lidentifiant fender .
CREATE USER pastorius IDENTIFIED BY fender ;
Il lui donne tous les droits sur la base de donnes pastorius_base quil vient de crer. Loption ALL PRIVILEGES sert transmettre lensemble des droits dont dispose le donneur : en loccurrence, ladministrateur dispose de tous les droits sur tous les objets. Le fait de prciser pastorius_base.* signifie tous les sous-objets prsents et venir contenus dans la base de donnes pastorius_base
CREATE DATABASE pastorius_base; GRANT ALL PRIVILEGES ON pastorius_base.* TO pastorius ;
Lutilisateur pastorius cre la table jaco dans la base de donnes pastorius_base et donne laccs de type SELECT lutilisateur nhop pralablement cr.
USE pastorius_base; CREATE TABLE jaco (NumMorceau INT PRIMARY KEY, Titre CHAR(50) ) ; GRANT SELECT ON jaco TO nhop ;
On obtient un message derreur : lutilisateur pastorius na pas le droit de retransmettre ses droits un autre utilisateur. Ladministrateur aurait d entrer la commande suivante :
GRANT ALL PRIVILEGES ON pastorius_base.* TO pastorius WITH GRANT OPTION ;
Cette fois, la commande de transmission de droits peut tre faite par lutilisateur pastorius
Lutilisateur nhop a le droit deffectuer toutes les oprations de consultation de la table jaco de la base de donnes pastorius_base, il peut par exemple excuter la squence suivante :
USE pastorius_base; SELECT * FROM jaco;
Lorsque lon veut donner un droit tous les utilisateurs du SGBD, on utilise le mot cl PUBLIC comme nom dutilisateur.
GRANT SELECT ON jaco TO PUBLIC;
Lensemble des utilisateurs peut alors interroger la table jaco de la base de donne pastorius_base .On peut affiner ces permissions en ne les accordant que pour certains champs de la table. On spcifie alors pour le type de droit le ou les champs sur lesquels ils sappliquent.
GRANT UPDATE Adresse ON jaco TO nhop ;
Lutilisateur nhop a le droit de mettre jour le champ Adresse de la table jaco. Ce droit peut lui avoir t accord par lutilisateur pastorius ou par ladministrateur du systme. Si lon ne spcifie pas le champ comme on la fait prcdemment, le SGBD considre que le droit concerne tous les champs de la table.
Voici un exemple dutilisation de GRANT avec les rles. On considre les rles suivants sur la table jaco : consultation : interrogation ; utilisation : mise jour et insertion ; gestion : destruction. On cre les rles et on met jour les droits ncessaires.
CREATE ROLE consultation; CREATE ROLE utilisation; CREATE ROLE gestion; GRANT SELECT ON jaco TO consultation; GRANT UPDATE, INSERT ON jaco TO utilisation; GRANT DELETE ON jaco TO gestion;
Les utilisateurs qui ont plusieurs rles disposent des droits de tous les rles auxquels ils appartiennent. Ainsi, lutilisateur miller possde les droits suivants sur la table : INSERT, UPDATE, SELECT . Pour retirer les droits accords par linstruction GRANT, on utilise linstruction REVOKE. Elle est de la forme suivante :
REVOKE <type de droit> ON <objet> FROM <nom utilisateur>
164
Chapitre Pour retirer les droits de lutilisateur nhop sur la table jaco, on procde comme suit :
REVOKE SELECT ON jaco FROM nhop ;
Remarque
Seul lutilisateur qui lui a donn ces droits peut les lui retirer. Dans notre cas, la commande prcdente doit tre lance par lutilisateur pastorius.
Les droits donns par plusieurs utilisateurs sont cumulatifs. Cela signifie que tous les droits accords doivent tre retirs pour quun utilisateur ne puisse plus effectuer les oprations. Ce graphe de permissions nest pas toujours simple grer et devient rapidement de taille exponentielle. Par consquent, les administrateurs des SGBD ont tendance accorder parcimonieusement les possibilits de redistribuer des droits. Pour aider ladministrateur, un bon SGBD procure une option de linstruction de destruction dun utilisateur, capable de dtruire galement tous les objets quil a crs. Linstruction DROP USER, non normalise par SQL comme on la vu prcdemment, sutilise avec loption CASCADE pour dtruire les tables, les vues et autres que lutilisateur a crs.
CREATE VIEW couleur_ville (Couleur, Ville) AS SELECT voiture.couleur, client.ville FROM voiture JOIN vente JOIN client ON voiture.NumVoit=vente.Numvoit AND client.NumAch = vente.Numach ;
On donne les droits de visualiser ces informations aux personnes du service marketing qui sont les utilisateurs nhop et miller.
GRANT SELECT ON couleur_ville TO nhop, miller ;
Loption CHECK OPTION permet les mises jour des donnes au travers de la vue. On donne les droits un rle que les utilisateurs pastorius et miller vont utiliser.
CREATE ROLE comptabilite ; GRANT SELECT ON journal_compta TO comptabilite; GRANT UPDATE Prix_de_vente ON journal_compta TO comptabilite;
Lutilisation des vues permet de dfinir des objets dynamiques puisquune vue est le rsultat dune requte et nest jamais stocke. Les vues sutilisent en complment du systme gnral de droits prsent la section prcdente. Il sagit de la bonne solution pour viter la complexit de description des permissions sur la totalit des champs. Comme pour le reste de la norme SQL, tous les SGBD ne proposent pas les vues.
Transactions
Cette section prsente plusieurs outils procurs par les SGBD pour protger les oprations effectues sur les donnes. Les incidents lis aux donnes dans un SGBD proviennent essentiellement de laccs concurrent ces dernires par plusieurs utilisateurs. Ces problmes sont habituellement rsolus par les mcanismes associs aux transactions prsentes dans cette section. Celles-ci permettent galement de rsoudre les pertes dues aux
166
Chapitre erreurs de manipulation ou celles lies aux erreurs dans le traitement des donnes, par exemple en cas de panne matrielle.
Lecture(s) trange(s)
Laccs multiple en lecture ne pose pas habituellement de problmes, mais que se passe-til lorsquun ou plusieurs utilisateurs dcident de modifier les mmes donnes au mme moment ? On considre la squence dinstructions suivante applique la base de donnes casse . On suppose que tous les utilisateurs disposent de tous les droits sur tous les objets (tables et champs) de cette base de donnes : Lutilisateur pastorius consulte la liste des voitures non vendues. Lutilisateur nhop enregistre la vente dune voiture. Lutilisateur pastorius relance la mme requte et trouve un rsultat diffrent. Lutilisateur nhop invalide la vente de cette voiture. Lutilisateur pastorius pensant stre tromp relance la mme requte qui aboutit au rsultat initial. Pour trois excutions de la mme requte, lutilisateur pastorius va obtenir des rsultats diffrents. On peut considrer la mme squence excute dans un ordre diffrent. Lutilisateur pastorius consulte la liste des voitures non vendues. Lutilisateur pastorius relance la requte et trouve le mme rsultat. Lutilisateur nhop enregistre la vente dune voiture. Lutilisateur nhop invalide la vente de cette voiture. Lutilisateur pastorius relance la requte prcdente et retrouve le mme rsultat. Comment dcider de lordre dans lequel excuter les instructions ? En pratique, le SGBD ne dispose pas dlments de comparaison qui lui permettraient dordonner la srie dinstructions afin que cela passe inaperu comme dans la deuxime srie. On pourrait utiliser ici le terme de lecture fantme pour qualifier les problmes rencontrs : une donne apparat puis disparat.
Incohrence de rsultats
On peut imaginer une autre srie dinstructions qui ralisent des modifications de donnes effectues par diffrents utilisateurs. En raison de laugmentation des frais de structure, le service comptable a dcid dune augmentation gnrale du prix de vente de 5 %. Afin que cette dernire passe inaperue et dans le cadre dune campagne de communication, le service marketing offre 100 euros de ristourne sur tout le catalogue pendant un mois. Lutilisateur pastorius appartient au service comptable et lutilisateur nhop au service marketing. Les vrifications sont effectues par lutilisateur miller de la direction (voir figure 6.2). Lutilisateur pastorius consulte le prix de vente de la voiture X.
Lutilisateur nhop effectue la modification de promotion sans vrifier le prix de vente (Prix_vente = Prix_vente 100). Lutilisateur pastorius effectue la modification daugmentation (Prix_vente = Prix_vente 1,05). Lutilisateur miller vrifie le rsultat de lopration de modification du prix de vente et constate une diffrence avec le rsultat attendu : le prix est gal (Prix_vente 100) 1,05, alors quil sattendait un prix gal (Prix_vente 1,05) 100. Figure 6.2
Droulement de la squence dinstructions de mise jour du prix de vente.
Pastorius : consultation du prix de vente Prix de vente 9 700
On obtient alors une incohrence due la squence de modification des donnes. Les oprations effectues sur le champ Prix ne sont en effet pas commutatives. L encore, le SGBD ne dispose pas dlments lui permettant dordonner correctement les oprations. En revanche, pour certains prix de vente, la mise jour pourra tre correcte. Il existe bien dautres types dincohrences qui peuvent tre provoques par laccs concurrent aux donnes. On peut citer le cas des anomalies de lecture : Deux lectures successives ne donnent pas le mme rsultat. Cela survient lorsque la modification dune donne est effectue par un processus concurrent entre deux lectures successives. Le SGBD traite naturellement les requtes de manire squentielle, dans lordre de leur arrive. Si lon augmente le nombre dutilisateurs, ce type de problmes peut videmment se multiplier.
Verrous
On a donc besoin de disposer dun mcanisme qui garantisse une certaine exclusivit sur les donnes lors des oprations de mise jour. Un tel mcanisme existe depuis longtemps en informatique pour rsoudre ce problme : il sagit des verrous. Lide est simple : on bloque une ressource pour effectuer les oprations et on la libre ds que les oprations sont effectues. Cette mthode semble rsoudre le problme ; elle prsente cependant quelques piges et doit tre utilise avec prudence. En effet, on peut rapidement parvenir une situation de blocage que lon nomme treinte fatale (deadlock en anglais) ou parfois
168
Chapitre interblocage. Pour illustrer cette situation, on suppose que deux vendeurs veulent mettre jour la base de donnes casse : Lutilisateur pastorius veut insrer une vente de voiture dans la table vente et constate cette occasion une erreur sur la couleur dans la table voiture quil veut modifier. Lutilisateur miller veut insrer la fois une nouvelle voiture dans la table voiture et la mention de sa vente dans la table vente. La squence dinstruction peut tre la suivante : Lutilisateur pastorius pose un verrou sur la table vente. Lutilisateur miller pose un verrou sur la table voiture. Lutilisateur pastorius a termin la mise jour de vente et veut raliser celle de voiture mais la table voiture est verrouille par miller. Lutilisateur miller a termin la mise jour de voiture et veut procder celle de vente mais la table vente est verrouille par pastorius. On parvient une situation o les deux utilisateurs attendent que lautre libre la ressource pour continuer. videmment, cest une attente infinie qui se profile pour chacun. Dautres phnomnes de blocage peuvent survenir dans lutilisation des verrous. On parle parfois dans ce cas de famine. Voici un exemple illustrant cette possibilit. Lutilisation classique des verrous pour protger laccs une ressource est la suivante (algorithme des lecteurs-rdacteurs ) : Tous les lecteurs peuvent lire en mme temps. Si un rdacteur veut crire, aucun lecteur ne doit plus utiliser la donne. Si un rdacteur est en train dcrire, aucun lecteur ne peut lire la donne et aucun autre rdacteur ne peut y accder (accs exclusif). Sil existe un grand nombre de lecteurs qui se succdent en lecture sur la donne, lattente pour un rdacteur qui voudrait la modifier peut alors devenir quasi infinie. Laisser la gestion des verrous un utilisateur est donc dlicat et peut conduire des blocages du systme. Les SGBD performants disposent doutils capables de dtecter et rsoudre ces phnomnes, voire de les prvenir le cas chant. Les algorithmes utiliss cet effet dpassent le cadre de cet ouvrage.
Les proprits que doivent vrifier les transactions sont rsumes par le terme ACID : Atomicit. Une transaction est atomique : elle est excute entirement ou abandonne. Cohrence. La transaction doit se faire dun tat cohrent de la base vers un autre tat cohrent. Isolement. Des transactions simultanes ne doivent pas interfrer entre elles. Durabilit. La transaction a des effets permanents mme en cas de panne. Les qualits des transactions sont un argument de vente pour un SGBD. Il est en effet complexe de trouver un compromis entre la scurit et les performances. Bien quil sagisse dun mcanisme prouv qui existe depuis fort longtemps, les transactions ainsi que les techniques de gestion des accs concurrentiels restent des sujets de recherches importants dans les laboratoires. Les transactions font partie de la norme SQL.
Remarque
Les transactions permettent de rsoudre les problmes lis aux accs concurrentiels, mais galement de traiter le cas de la reprise en cas de panne. Le SGBD est ainsi capable de remettre la base de donnes dans ltat cohrent o elle se trouvait avant le dbut de la transaction qui a chou pour cause de panne. Les transactions sont galement employes pour annuler des erreurs de traitement ventuelles. En effet, grce ce mcanisme, on peut revenir ltat initial dans lequel se trouvait la base de donnes avant le dbut de la srie de mauvaise(s) manipulation(s) sur la base de donnes. Il sagit certainement de lutilisation principale des transactions.
170
Chapitre 0, READ UNCOMMITED. Lecture de donnes non valides en cours de transaction (niveau le plus bas). 1, READ COMMITED. Modification des donnes possible en cours de transaction. 2, REPEATABLE READ. Insertion de nouveaux enregistrements possible en cours de transaction. 3, SERIALIZABLE. Toutes les transactions sont traites en srie (niveau le plus sr). Pourquoi prvoir plusieurs niveaux, puisque le but est dobtenir une scurit maximale ? La scurit a un cot en matire de performances et, dans certains contextes, il nest pas ncessaire de demander au SGBD de traiter une requte avec le niveau maximal dexclusivit. Il est clair que, pour une simple opration de lecture, le niveau 1 qui garantit limpossibilit de lire des donnes non valides peut tre suffisant.
Remarque
Les SGBD ne fonctionnent pas par dfaut au mme niveau disolation. Il est prudent de vrifier dans la documentation quel niveau se trouve par dfaut le SGBD que lon utilise. En effet, certains SGBD trs rpandus fonctionnent par dfaut au niveau 1 ! Ce peut tre suffisant pour certaines applications, encore faut-il en tre bien conscient. Le choix du niveau est motiv par des arguments plus commerciaux que techniques : le SGBD est plus rapide en utilisant un niveau moins lev.
Voici un exemple de destruction dans la table client de la base de donnes casse que lon valide ensuite :
#Dmarrage de la transaction START TRANSACTION ; #Destruction des tuples dont le champ Ville vaut Paris dans la table client DELETE FROM client WHERE Ville=Paris; #Validation des modifications faites depuis START TRANSACTION COMMIT ;
On peut choisir le niveau disolation au moment o lon dmarre la transaction. Dans lexemple suivant, on fixe le niveau maximal de scurit.
START TRANSACTION ISOLATION LEVEL SERIALIZABLE ;
Une diffrence essentielle par rapport linstruction ROLLBACK vue prcdemment est que, dans ce cas, la transaction nest pas termine. Un autre ROLLBACK reviendrait ltat de la base de donnes avant lexcution de linstruction START TRANSACTION. Figure 6.3
Point de retour dans une transaction.
START TRANSACTION ;
SAVEPOINT UN
ROLLBACK TO UN ;
ROLLBACK
Le mcanisme des points de retour est trs utile pour prvenir les cas de mauvaise manipulation de donnes. On combine ainsi la possibilit deffectuer les modifications dans une seule transaction avec celle de ne pas annuler toutes les modifications. Certaines dentre elles prennent en effet un temps considrable.
Remarque
La plupart des SGBD considrent que chaque instruction SQL est en soi une transaction qui est automatiquement valide (mode AUTO COMMIT). Certains fonctionnent en crant une nouvelle transaction lors de chaque connexion au SGBD, ce qui permet dannuler le cas chant toutes les oprations effectues depuis la connexion. Dans le doute, il est donc prfrable de spcifier explicitement le dbut de toute transaction par une instruction START TRANSACTION.
172
Chapitre Le systme des transactions gres par le SGBD est un outil indispensable pour prendre en compte les problmes cits prcdemment : la concurrence daccs, les erreurs et les reprises aprs les pannes. Comme on la vu dans cette section, la ralisation des transactions fait appel des compromis entre la rapidit et la scurit. Tous les SGBD neffectuent pas les mmes choix et prsentent des degrs diffrents de fiabilit. Les cas dinterblocage peuvent tre frquents dans certains SGBD pourtant trs utiliss. Dautres, galement fort rpandus, ne proposent mme pas les transactions sur leurs tables en standard .
Triggers
Les triggers ou dclencheurs ont un objectif diffrent des outils tels que les transactions. Ils servent excuter des contrles complmentaires personnaliss au moment des oprations dajout, de suppression et mise jour des donnes. Ils sont utiles galement pour effectuer un formatage spcifique des donnes. Pratiquement, un trigger est un ensemble dinstructions SQL, dfinies par lutilisateur, qui seront dclenches lors dune action dajout, de suppression ou de mise jour de donnes. Il sapplique donc un objet de type table. On peut choisir dexcuter un trigger avant ou aprs une instruction de mise jour. Les donnes manipules par le trigger sont stockes dans des tables temporaires que lon dsigne dans le code du trigger par les termes : NEW valeurs, aprs lexcution de lopration de mise jour ; OLD valeurs, avant lexcution de lopration de mise jour.
Le moment peut prendre les valeurs BEFORE ou AFTER. Les oprations concernes sont INSERT, UPDATE et DELETE. La diffrence entre ROW et STATEMENT est que lon excute les instructions pour chaque ligne ou pour toute la table. Pour dtruire un trigger, on utilise linstruction DROP et on spcifie le nom du trigger que lon veut dtruire.
DROP TRIGGER conversion
Comme toujours, la syntaxe peut tre lgrement diffrente suivant le SGBD employ.
Le compte du client de numro NumAch gal 2 sera automatiquement diminu de la somme de 50000. Un trigger apporte de la souplesse et de la personnalisation dans la dfinition des contraintes que lon associe aux tables. Pour ce faire, il dclenche lexcution dun morceau de code spcifique associ un vnement de mise jour de la table. Il est parfois possible de raliser les oprations dune autre de manire plus complexe. Du point de vue de la scurit des donnes, le code associ au trigger sexcute sur le serveur sans interaction avec le client. On rduit ainsi les risques derreur lis aux changes entre le client et le serveur.
174
Chapitre
Rsum
Ce chapitre expose les diffrentes dispositions que lon doit prendre afin de prvenir laltration ou la perte des donnes. On a prsent tout dabord les prcautions de premier niveau quil ne faut pas ngliger. Elles concernent essentiellement lenvironnement dans lequel se trouve le SGBD : la machine munie de son systme dexploitation, les locaux informatiques et enfin le rseau sur lequel elle est connecte. Un autre point important concerne la sauvegarde et la duplication des donnes, de faon garantir laccessibilit ces dernires mme en cas de sinistre. Une fois lenvironnement du SGBD scuris, on a abord les permissions et les restrictions qui sont gres directement par le SGBD. Il sagit de la partie prise en charge par ladministrateur du SGBD qui dfinit les droits sur les diffrents objets de la base de donnes. Cette gestion devient rapidement complexe : on utilise en complment les vues SQL pour dcrire plus finement les objets sur lesquels on distribue les droits. Les prcautions prcdentes mises en uvre, on se trouve confront au problme de laccs concurrent aux donnes. La solution consiste en lutilisation de verrous. Leur mcanisme est trs dlicat grer et lon prfre laisser ce soin au SGBD. Ce dernier procure de surcrot un mcanisme de journalisation des instructions capable de remettre la base de donnes dans ltat cohrent prcdant la squence dinstructions. Cette combinaison des mcanismes daccs exclusif associs la journalisation se nomme les transactions. Enfin, les triggers (ou dclencheurs en franais) sont trs utiles pour complter la panoplie doutils qui assurent le contrle des donnes dune base de donnes.
Exercices
EXERCICE 1
SCURIT DE BASE
Quelles sont les vrifications de base indispensables avant de faire hberger un SGBD serveur de bases de donnes par une structure ? La dcision doit reposer sur la prise en considration de plusieurs points ; la liste ci-dessous nest pas exhaustive. Aspects techniques. Lune des premires proccupations doit tre dauditer le type de machine ainsi que le systme dexploitation sur lequel sera hberg le SGBD. Dautre part, les SGBD sont gourmands en ressources de calcul et de stockage et il faut donc sassurer que lon disposera du ncessaire dans ces domaines. On peut supposer que la machine sera connecte un rseau quil faut auditer galement. De quel type de connexion dispose lhbergeur, quels matriels de protection contre les intrusions utilise-t-il ? Le minimum est de disposer dun dispositif de filtrage pour se protger des intrusions lies au rseau. Un plus est de disposer de deux fournisseurs daccs, lun prenant le relais en cas de faille de lautre. Enfin, quel matriel de sauvegarde peut-on utiliser, et de quelle taille de stockage disposet-on ? Une sauvegarde quotidienne est indispensable pour une base de donnes standard, cest--dire sur laquelle les mises jours sont raisonnablement frquentes. En cas de mises jour intensives, on peut prvoir de conserver plusieurs versions de la base sauvegarde. Aspects humains. Les machines et les rseaux aussi performants soient-ils sont grs avant tout par des tres humains. Il est donc essentiel de savoir combien de personnes assurent cette mission, et de quelle faon ; didentifier la politique de scurit gnrale : accs physique aux machines, protection contre les intrusions rseau et le suivi des incidents, mise jour des machines, gestion des comptes
EXERCICE 2
176
Chapitre compte de la proximit , au sens informatique, du serveur par rapport au client qui effectue la requte. Cette proximit peut tre calcule en termes de distance combien de nuds du rseau sont traverss ? mais galement en termes de charge des branches du rseau. Il existe des outils capables de tenir jour en permanence ce genre dinformations, mais ils sont assez complexes grer. Lors du choix de la machine vers laquelle on va rediriger la demande, on doit prendre en considration galement sa charge et donc son aptitude rpondre rapidement. Les inconvnients dune solution complte de ce type sont vidents. Les applications de rpartition de charge sur un rseau standard sont dj complexes grer ; on imagine bien quelles le sont dautant plus lorsque lon passe une chelle suprieure. Un autre inconvnient est la difficult de maintenir des copies des donnes jour par rapport la base primaire. Si les mises jour sont trs frquentes, il devient difficile de disposer des mmes donnes sur tous les secondaires. Une autre solution plus facile grer pour rpartir naturellement la charge entre les serveurs consiste rpartir les donnes entre ces serveurs. Ainsi, cette opration se fait par larchitecture mme de la base de donnes qui est dite rpartie . En revanche, cette solution ne rsout pas le problme de la recopie des donnes. Si lun des serveurs tombe en panne, il nexiste pas, contrairement au systme prcdent, de mcanisme automatique pour le remplacer. On peut envisager des variantes qui panachent les deux systmes : par exemple, on peut mettre en place un serveur matre qui recopie une partie des donnes sur les secondaires. Cette problmatique gnrale est illustre par les grands moteurs de recherche, ou encore les serveurs de vido qui utilisent plusieurs milliers de serveurs rpartis sur le rseau Internet.
EXERCICE 3
Exercices
On rsume dans un tableau (voir tableau 6.1) les droits par catgories sur les tables (par criture , on entend mise jour, insertion et destruction). Figure 6.1 : Synthse des droits par catgories de la base de donnes pizza
commande Client Employ Gestionnaire X Lecture/ criture Lecture pizza Lecture Lecture Lecture/ criture compose Lecture Lecture Lecture/ criture ingredient tarification Lecture Lecture Lecture/ criture Lecture Lecture Lecture/ criture client Lecture Lecture livreur X Lecture vehicule X Lecture
EXERCICE 4
178
Chapitre
GRANT GRANT GRANT GRANT GRANT GRANT GRANT GRANT GRANT GRANT GRANT GRANT GRANT GRANT GRANT GRANT GRANT GRANT GRANT GRANT GRANT GRANT DELETE INSERT SELECT UPDATE DELETE INSERT SELECT UPDATE DELETE INSERT SELECT UPDATE DELETE INSERT SELECT UPDATE DELETE INSERT SELECT UPDATE DELETE INSERT ON ON ON ON ON ON ON ON ON ON ON ON ON ON ON ON ON ON ON ON ON ON livreur TO gestionnaire; livreur TO gestionnaire; vehicule TO gestionnaire; vehicule TO gestionnaire; vehicule TO gestionnaire; vehicule TO gestionnaire; tarification TO gestionnaire; tarification TO gestionnaire; tarification TO gestionnaire; tarification TO gestionnaire; ingrdient TO gestionnaire; ingrdient TO gestionnaire; ingrdient TO gestionnaire; ingrdient TO gestionnaire; compose TO gestionnaire; compose TO gestionnaire; compose TO gestionnaire; compose TO gestionnaire; pizza TO gestionnaire; pizza TO gestionnaire; pizza TO gestionnaire; pizza TO gestionnaire;
On distribue les rles des utilisateurs : swallow et clarke sont des clients.
GRANT clientTO swallow, clarke;
EXERCICE 5
VUES
De nouveaux utilisateurs aux besoins plus spcifiques vont utiliser la base de donnes de livraison de pizzas vue au chapitre 5, Du langage parl SQL . Le service comptabilit doit rmunrer les livreurs : il a besoin de connatre le nombre de commandes livres par chacun deux. Le service du personnel effectue un suivi des livreurs : il a besoin de connatre le nombre de retards de chacun, mais galement le nombre de commandes livres. Un laboratoire de recherche en sociologie effectue des tudes sur la clientle, spcifiquement sur la relation entre les ingrdients des pizzas achetes et ladresse des clients. Ces utilisateurs ne doivent accder quaux champs dont ils ont strictement besoin. On remarque que les informations dont ces utilisateurs ont besoin ne sont pas directement disponibles dans une table ni mme dans un champ particulier. Il sagit de rsultats de calculs sur lensemble de la base de donnes. Le moyen le plus simple pour grer ces besoins est de crer des vues pour chaque catgorie dutilisateurs, auxquels on distribuera les permissions sur ces vues. Il est videmment possible de crer des rles dutilisateurs comme dans lexercice prcdent, ce qui est plus lgant mais nest pas support par tous les SGBD.
Exercices
Service comptabilit. Le besoin est uniquement davoir accs aux nombres de commandes livres pour chaque livreur. Il sagit du rsultat dun calcul classique sur un agrgat. On affiche uniquement les informations du livreur (code et nom) et le rsultat du calcul.
SELECT L.CodeLivreur, L.NomLivreur, COUNT(*) AS Nombre_Livraison FROM commande C JOIN livreur L ON C.CodeLivreur=L.CodeLivreur GROUP BY C.CodeLivreur ORDER BY L.NomLivreur;
Service du personnel. Par un raisonnement identique, on obtiendrait la requte qui permet de calculer le nombre de retards cumuls par livreur.
CREATE VIEW retard_livreur AS SELECT L.CodeLivreur, L.NomLivreur, COUNT(*) AS Nombre_Retard FROM commande C JOIN livreur L ON C.CodeLivreur=L.CodeLivreur WHERE C.Retard=O GROUP BY C.CodeLivreur ORDER BY L.NomLivreur;
Pour tre complet, on pourrait crer une vue rcapitulative qui permette de visualiser les commandes livres et les retards dans une seule table. Ce nest pas le moyen le plus simple, mais cela rend le processus plus lisible.
CREATE VIEW retard_commande_livreur AS SELECT R.CodeLivreur, R.NomLivreur, C.Nombre_Livraison, R.Nombre_Retard FROM retard_livreur R JOIN commande_livreur C ON R.CodeLivreur = C.CodeLivreur ORDER BY R.NomLivreur;
Laboratoire de sociologie. Le laboratoire de recherche doit pouvoir accder au contenu de deux champs sans calcul ni mise en forme. En revanche, on ne donne pas la possibilit ces utilisateurs extrieurs de connatre la structure interne des donnes et davoir accs dautres champs. On cre une vue qui est le rsultat de la jointure entre les tables commande, client, pizza, compose, ingredient.
CREATE VIEW adresse_ingredient AS SELECT CL.Adresse, I.NomIngre FROM commande C JOIN client CL JOIN pizza P JOIN compose CO JOIN ingredient I ON C.NumClient=CL.NumClient AND C.NomPizza=P.NomPizza AND P.NomPizza = CO.NomPizza AND CO.NumIngre=I.NumIngre ;
180
Chapitre On distribue les droits de lecture sur cette vue lutilisateur sociologue.
GRANT SELECT ON adresse_ingredient TO sociologue;
On se trouve dans les cas typiques dutilisation de vues pour dfinir des objets qui nexistent pas ltat naturel dans la base de donnes. La distribution des droits en est dautant simplifie. De plus, lensemble est volutif ; on peut sans difficults ajouter un champ dans ces vues sans avoir besoin de changer lensemble des droits sur les tables, les champs, etc.
EXERCICE 6
TRANSACTIONS
On dsire effectuer une simulation de mise jour de la base de donnes livraison de pizzas . Lide est de procder une augmentation gnrale de 10 % du prix des pizzas, tout en vitant de faire fuir les clients. On essaie de jouer sur les coefficients affects aux diffrentes tailles de pizzas (naine, humaine, ogresse) et sur les prix de base. Lobjectif est de mesurer les effets de ces modifications sur le compte des clients. On modifie dans un premier temps les prix ; ensuite, les coefficients en se donnant la possibilit de revenir en arrire pour tester diffrentes combinaisons de coefficients et de prix. Une fois les essais termins, on abandonne toutes les modifications : ce ntait quune simulation. On utilise videmment le mcanisme des transactions en dfinissant des points de retour pour pouvoir annuler les effets des modifications des coefficients et des prix. On abandonne toutes les modifications, y compris celles des prix la fin de la transaction.
#Dmarrage de la transaction START TRANSACTION ; # Dfinition dun point de retour que lon nomme PRIX SAVEPOINT PRIX ; #Augmentation des prix des pizzas de 10 % UPDATE pizza SET Prix=Prix*1.1;
On a dfini ici un point de retour PRIX qui permet de revenir ltat de la base avant la modification de prix.
# Dfinition dun point de retour que lon nomme COEFF_NAINE SAVEPOINT COEFF_NAINE ; #Modification des coefficients de la taille nainedans la table tarification UPDATE tarification SET Coefficient=0.5 WHERE Taille=naine ; # Dfinition dun point de retour que lon nomme COEFF_OGRE SAVEPOINT COEFF_OGRE ; #Modification des coefficients de la taille ogressedans la table tarification UPDATE tarification SET Coefficient=1.5 WHERE Taille=ogresse ;
On a dfini ici deux points de retour COEFF_NAINE et COEFF_OGRE qui permettent de revenir ltat de la base avant les modifications des coefficients. Pour revenir ltat de la base avant modification de tous les coefficients, on retourne au point COEFF_NAINE.
La transaction ne se termine pas lorsque lon fait un ROLLBACK vers un point de retour. On peut donc essayer dautres coefficients, sans oublier de redfinir de nouveaux points de retour.
# Dfinition dun point de retour que lon nomme COEFF_NAINE2 SAVEPOINT COEFF_NAINE2 ; #Modification des coefficients de la taille nainedans la table tarification UPDATE tarification SET Coefficient=0.5 WHERE Taille=naine ;
Exercices
Et ainsi de suite. Puis, on abandonne lensemble des modifications par linstruction ROLLBACK qui termine la transaction et remet la base dans ltat de dpart.
EXERCICE 7
TRIGGER
On dsire effectuer des mises jour proprement dans la base de donnes livraison de pizzas . Lorsque lon dtruit une pizza dans la table pizza, on veut que les entres de la table compose correspondant cette pizza disparaissent automatiquement. Ainsi, la table composene contiendra aucune entre orpheline . On utilise un trigger (dclencheur) pour mettre jour automatiquement la table compose lors dune destruction dans la table pizza.
CREATE TRIGGER maj_compose BEFORE DELETE ON pizza FOR EACH ROW BEGIN DELETE FROM compose WHERE NomPizza=OLD.NomPizza ; END
On remarque dune part que, par rapport aux triggers dfinis dans le chapitre, on fait appel aux valeurs de la table OLD . En effet, lors dune instruction DELETE, le SGBD ne gre pas de table NEW dans la mesure o il nexiste pas de nouvelles valeurs ; dans ce cas, la table OLD fera rfrence aux valeurs supprimes de la table pizza. Dautre part, on effectue lopration de destruction dans la table compose avant celle de pizza laide du terme BEFORE . Ici, elle aurait peut-tre pu intervenir galement aprs, sauf sil existe une contrainte dintgrit de rfrence de la table compose par rapport la table pizza : un entre du champ NomPizza dans compose ne peut exister que si elle existe dans la table pizza. Le trigger permet alors dautomatiser les instructions quil aurait t fastidieux deffectuer la main lors de la destruction dune entre dans la table pizza.
182
A
Annexe
Historiquement, la transmission dinformation distance se faisait de manire visuelle. La marine transmettait des messages entre les bateaux par des fanions qui reprsentaient chacun une lettre de lalphabet. Le tlgraphe de Chappe reposait sur le mme principe : une position des bras figurait une lettre. Il disposait en outre dun mcanisme de cryptage ainsi que de codes spciaux qui accompagnaient le message (par exemple, urgent , en attente , etc.). Avec linvention de llectricit est arriv le tlgraphe lectrique qui utilisait un fil par lettre de lalphabet (donc, 26 en tout). Samuel Morse invente en 1840 un codage qui passe un seul fil pour la transmission. Il sagit du premier codage moderne international qui inclut les chiffres, les lettres et certains caractres accentus. Il possde galement des caractres de contrle utiliss pour la transmission du message (par exemple, rptez ). Ce codage universel permet de transmettre des informations en utilisant une source lumineuse, sonore ou lectrique. Le tlex apparat vers 1920 ; il se sert dun codage sur 5 positions invent par le Franais Baudot. Les messages envoys par tlex sont dabord saisis sur un ruban perfor et lenvoi ainsi que la rception sont automatiss. Cest le mme type de code qui a servi stocker de linformation sur les cartes perfores 80 colonnes. Ces dernires reprsentent le premier stockage dinformation avec un code qui prfigure ce qui est utilis actuellement. Le codage 5 positions permet 32 possibilits (25). Cette capacit est quasiment double (diminue de caractres de contrle) par lemploi de deux tables. On indique par un caractre spcifique la table dans laquelle on se situe. Le codage comprend les lettres, les chiffres et quelques caractres de ponctuation. noter que, dans les caractres de contrle, on trouve un code pour ramener le chariot de limprimante en dbut de ligne (CR, Carriage Return) et un caractre pour passer la ligne suivante (LF, Line Feed). Les annes 1940 voient apparatre les ordinateurs qui recourent au dpart aux cartes perfores puis dautres systmes de stockage. Chaque constructeur dfinit son systme de codage ; il arrive parfois que plusieurs systmes cohabitent chez le mme constructeur. IBM dfinit le codage BCD qui servira de base EBCDIC plus tard et utilise 6 positions. Dans les annes 1960, les constructeurs se sont regroups pour dfinir une norme commune qui sera publie au final par lorganisme de normalisation ASS (American Standard Association) sous le nom de code ASCII (American Standard Code for Information Interchange). Le code ASCII possde 7 positions, ce qui permet de stocker 128 (27) caractres. Les 32 premiers caractres sont des caractres de contrle, un hritage du transfert de donnes par ruban perfor. Le reste du code contient des caractres majuscules et minuscules, les chiffres et des caractres divers (? @ $ , etc.). De nombreuses variantes nationales existent en particulier pour le signe montaire qui diffre suivant les pays ( $ , pour les USA, , pour la Grande-Bretagne, etc.). En dpit de ces spcificits, lusage du codage
de caractre ASCII est encore trs rpandu, car il suffit bon nombre dapplications condition que lon crive sans lettres accentues. Si lon a besoin de caractres diacritiques ou dautres caractres ne se trouvant pas dans la table de codage ASCII, on peut les reprsenter par une suite spcifique de caractres ASCII comme on le fait en HTML. Par exemple se reprsente par la suite é .
Remarque
Un point, qui peut se rvler pnible lusage, concerne les caractres de fin de ligne. On a vu que le codage, hrit du temps o lon utilisait des machines mcaniques pour transmettre les caractres, propose deux caractres distincts pour changer de ligne : le retour chariot (CR) et le passage la ligne (LF). Il nest plus techniquement utile aujourdhui de spcifier ces deux caractres pour indiquer une fin de ligne. Cependant, la plupart des protocoles rseaux (par exemple HTTP) ainsi que le monde DOS/Windows ont conserv la combinaison CR-LF pour passer la ligne. Les familles UNIX utilisent le seul caractre LF et Apple le caractre CR. Il est donc ncessaire deffectuer des transformations pour passer dun type de fichier lautre.
184
Unicode
A
Annexe Aujourdhui, on envoie des mails et lon schange des fichiers dun bout lautre du monde et lon aimerait pouvoir les exprimer avec les caractres corrects. Le franais scrit avec des caractres diacritiques : la lecture dun texte sans accents est dsagrable et peut mme nuire la comprhension. La section prcdente donne une ide de la confusion qui rgne pour le codage des caractres malgr les efforts de normalisation. De plus, on ne peut deviner (cest--dire dtecter automatiquement) en ouvrant un fichier sil est cod en ISO-8859-l ou en MacRoman et il est impossible dutiliser des tables de langues diffrentes au sein dun mme fichier. Pour rsoudre ces problmes, un groupement de constructeurs et dditeurs de logiciels (Adobe, Xerox, Apple, IBM, MicroSoft, etc.) ont fond le consortium Unicode au dbut des annes 1990. Unicode est un standard dfini par un consortium priv, mais aprs quelques errements la norme ISO-10646 a repris lensemble du standard. Lide est de disposer dun systme de codage de tous les caractres du monde ou plus exactement de pouvoir coder la reprsentation de ces caractres. Unicode spare la notion de caractre de sa reprsentation que lon appelle un glyphe . Ainsi, les notions daspect, de police ou de taille du caractre nexistent pas dans le codage Unicode ; ces informations sont reportes au niveau de lapplication. Le standard fournit tout de mme un exemple de reprsentation (glyphe) du caractre titre informatif. En revanche, on inclut des informations complmentaires, comme la direction dans laquelle il faut lire les caractres ou des proprits alphabtiques qui seront importantes pour les bases de donnes. En ce qui concerne plus particulirement les caractres diacritiques, la rgle gnrale est de donner la possibilit de construire le caractre plutt que de le stocker : un sera construit en utilisant le code e combin au code ` . Cependant, pour des raisons pratiques de compatibilit, Unicode a repris intgralement les codages existants tels que ISO-8859-1 : dans ce cas, on stocke galement le caractre . La plupart des langues vivantes peuvent scrire dsormais avec Unicode (plus ou moins 100 000 caractres sont actuellement dfinis), mme si certains choix ont fait lobjet de fortes critiques. Les symboles mathmatiques, musicaux ou autres font galement partie du code. Le processus se poursuit avec les langues mortes, comme le codage des hiroglyphes gyptiens. Techniquement, Unicode utilise un codage sur 21 positions. Le codage est divis en 17 tables de 65 536 (216) caractres que lon appelle des plans. Lun des intrts de ce dcoupage est que par exemple le premier plan suffit coder la plupart des langues vivantes. De surcrot, le tout dbut de ce premier plan reprend exactement la norme ISO-8851-1. De cette manire, on nest pas oblig dutiliser la place des 21 positions pour coder les caractres Unicode. Il suffit de trouver un codage astucieux qui indique que lon utilise le premier plan ou mme le dbut du premier plan, et alors 8 positions suffisent. Avec des caractres plus exotiques , le codage utilise alors 16 positions et ainsi du suite. Cet aspect offre beaucoup de souplesse et assure galement la compatibilit avec lexistant ASCII et ISO-8859. Les machines et les logiciels utilisent traditionnellement, et cest l lhritage des codages prcdents, comme unit de base loctet qui contient 8 positions. Les diffrentes manires de coder les caractres Unicode seront donc des multiples doctets. Essentiellement, on trouve : UTF-8 : il sagit dun encodage gnial sur 8 bits concoct en une journe (une nuit ?) par K. Thompson. Lide est que tout ce qui est en ASCII est cod sur un octet ; ce qui est cod avec des diacritiques conformes la norme ISO-8859 est cod sur deux octets et ainsi de suite. Cette manire de coder permet de conserver la compatibilit totale avec le codage ASCII ainsi que de continuer utiliser les logiciels et matriels conus lorigine pour lire des octets.
UTF-16 : on reprsente Unicode sur deux octets. Cest plus conomique en termes de place si lon utilise frquemment des langues extrme-orientales (UTF-8 utilise 3 octets dans ce cas). Le problme est de savoir de ces deux octets lequel est le premier (dit de poids fort ). En effet, deux architectures diffrentes de machines coexistent toujours, car cette information est code au niveau matriel. Ces dernires sont dsignes par les termes Little Endian et Big Endian . Il existe donc une version UTF16LE et une version UTF-16BE. Pour la petite histoire, les termes Big Endian et Little Endian proviennent du livre Les Voyages de Gulliver, o lauteur dcrit des peuplades qui mangent les ufs par le petit bout , opposes celles qui les mangent par le grand bout . Il existe dautres reprsentations du codage Unicode : UTF-32 sur 32 positions, UTF-7 sur 7 positions, etc. UTF-8 est logiquement le codage le plus frquemment utilis actuellement, car il est celui qui consomme le moins de place (si lon utilise des caractres ASCII ou europens) et qui ncessite le moins de changements structurels aux niveaux logiciel et matriel. noter que, dans tous les cas, on pourra reconnatre informatiquement le type de codage qui est utilis. Unicode nest pas parfait, puisquil a intgr les systmes de codage hrits des systmes prcdents (presque depuis le code Morse). En revanche, les langues qui ne possdaient aucun codage prliminaire disposent dun codage lgant et cohrent. Unicode est actuellement support par la plupart des systmes dexploitation, mais la transformation de tous les textes et bases de donnes existants prendra du temps : Ken Whistler (directeur technique du consortium Unicode) prvoit environ 10 ans pour la transition. Figure A.1
Les diffrents codages de caractres.
Morse
Autres plans
Baudot (5 positions)
UNICODE ISO-10646
(21 positions)
ASCII (7 positions)
Windows-1251 (8 positions)
MacRoman (8 positions)
186
A
Annexe
On peut dfinir un jeu de caractres spcifique pour chaque champ. Il existe des noms de jeux de caractres prdfinis dans la norme SQL : Unicode, ASCII_FULL, LATIN1 etc. Les SGBD proposent en gnral des jeux de caractres complmentaires. Il est possible en SQL dindiquer lutilisation dun jeu de caractres prdfini avec le mot cl NATIONAL CHARACTER. En pratique, dans les SGBD actuels, le jeu de caractres employ dans ce cas est le plus souvent UTF-8.
La collation utiliser est spcifie par le mot cl COLLATE suivi du nom de la collation utiliser.
Nom_client CHAR(20) CHARACTER SET Unicode COLLATE LATIN1;
Les SGBD proposent de nombreuses collations en dehors de celles prdfinies dans la norme SQL. Les jeux de caractres et les collations peuvent tre dfinis plus gnralement au niveau des tables, des bases de donnes et du SGBD lui-mme. Un jeu de caractres ainsi quune collation par dfaut sont utiliss dans le SGBD ; il est intressant den vrifier le contenu avant dutiliser le SGBD si lon ne les spcifie pas explicitement.
188
Bibliographie
G. Gardarin, Bases de donnes, Eyrolles, 2001 (ISBN : 2-212-09283-0). R. Elmasri et S. Navathe, Conception et Architecture des bases de donnes, Pearson Education, 2004 (ISBN : 2-7440-7055-6). C. Delobel, C. Lcluse et P. Richard, Bases de donnes et Systmes relationnels, Dunod. N. Boudjlida, Bases de donnes et Systmes dinformations. Le Modle relationnel : langages, systmes et mthodes, Dunod, 1999. C. J. Date, Introduction aux bases de donnes, Vuibert, 2004 (ISBN 2-7117-8640-4). T. Connoly et C. Begg, Systmes de bases de donnes, Eyrolles (ISBN 2-89377-267-6). F. Brouard et Ch. Soutou, Synthex SQL, Pearson Education, 2005 (ISBN : 2-7440-7095-5). B. Charroux, A. Osmani et Y. Thierry-Mieg, Synthex UML2, Pearson Education, 2005 (ISBN : 2-7440-7124-2). Ch. Soutou, De UML SQL, Eyrolles, 2002 (ISBN : 2-212-11098-7). H. Tardieu, A. Rochfeld et R. Colleti, La Mthode MERISE, Eyrolles, 2000. D. Nanci et B. Espinasse, Ingnierie des systmes dinformation : Merise deuxime gnration, Vuibert, 2001 (ISBN 2-7117-8674-9). P. Andr et A. Vailly, Conception des systmes dinformation, panorama des mthodes et des techniques, Technosup, Ellipse, 2001 (ISBN 2-7298-0479-X). E.F. Codd, A Relational Model of Data for Large Shared Data Banks, 1970.
Bibliographie 189
Index
A
Accs concurrent 167 ACID 16, 170 Administrateur 19, 161 Algbre relationnelle 60 ANSI/SPARC 15 Association 17, 30, 32, 38, 41, 68 Attributs 6, 31, 35 Dpendance fonctionnelle 57, 70, 72, 73 Disponibilit 8, 16, 160 Domaine 17, 41, 56, 59 DTD 11, 12
E
Entits 31 Entrepts de donnes 10, 11
B
Bases de donnes 8, 9, 10, 19 dductives 9, 10 volution 4 mtiers 19 modles 5 rparties 8, 9
F
Fichier informatique 13, 14 Forme normale 70, 72, 73, 75, 135, 136 Boyce-Codd 75 deuxime 72, 136 premire 70, 135 troisime 73, 136 Fouilles de donnes 9 Fusion 38, 39
C
Cardinalits 30, 33, 34, 43, 56, 69 Champs 3, 31, 56 Cl 14, 56, 57, 58, 59, 114 candidate 57, 58, 114 composite 115 trangre 59 primaire 57 Cohrence 3, 16, 59 Collation 187 Contraintes dintgrit 59, 114
H
HTML 11
I
Identifiant 31 Incohrences 4, 18, 35, 36, 37, 38, 59, 167 Index 14, 110, 140
D
Data mining 9 Datawarehouse 10, 11 Dcomposition 70, 72, 73, 74 Degr 32, 56
J
Jeu de caractres ASCII 183 ISO-8859-n 184
Index 191
MacRoman 184 unicode 185 UTF-16 186 UTF-32 186 UTF-8 185 Windows-1252 184 Jointure 64, 65 externe 65 naturelle 64 Journalisation 16, 170
union 60
Q
QBE 76, 78
R
Redondance 3, 4, 37, 38, 59, 72, 73, 136, 160 Relation 56 Rle 42, 162, 164
L
Langage hte 96 LDD 16, 80, 95 LMD 16, 95 Logique du premier ordre 76
S
Sauvegarde 15, 160 SGBD 13 SQL - 100 % 100 * 100 + 100 / 100 < 101 <= 102 <> 101 = 101 > 101 >= 102 ALTER TABLE 112 AND 102 AVG 101 BETWEEN 102 CHECK 115 COMMIT 171 CONSTRAINT 116 COUNT 101 CREATE INDEX 140 CREATE ROLE 166 CREATE TABLE 110 CREATE TEMPORARY TABLE 111 CREATE TRIGGER 173 CREATE VIEW 116 DELETE FROM 117 DISTINCT 99 DROP TABLE 112 DROP TRIGGER 173 GRANT 166 GROUP BY 103 HAVING 104 IN 102 INNER JOIN 106 INSERT INTO 116 IS NULL 102 LIKE 102 MAX 101
M
Mtadonne 3, 160 Modle 5, 6, 7, 8, 30, 56, 68 entit-association 30 hirarchique 5 logique 68 objet 6, 7 relationnel 6, 56 relationnel-objet 7, 8 rseau 5 Multivaluation 70
N
Niveau 5, 15 conceptuel 15 externe 5, 15 interne 15 logique 5 physique 5, 15
O
Objet 7, 28, 29 Oprations agrgat 67, 103 diffrence 61 quijointure 63 intersection 61, 83 jointure 63 jointure externe 108 jointure interne 106 produit cartsien 61, 105 projection 62, 98 restriction 63 slection 63, 101 192 Cration de bases de donnes
MIN 101 NOT 102 OR 102 ORDER BY 109 OUTER JOIN 108 PRIMARY KEY 114 ROLLBACK 171 SAVEPOINT 172 SELECT 98 START TRANSACTION 171 SUM 101 UPDATE 118 WHERE 101
T
Tables 110 Transactions 169 Tri 109 Triggers 173 Type SQL BLOB 111 BOOLEAN 111 CHAR 111 DATE 111 FLOAT 111 INT 111 NCHAR 111 NVARCHAR 111 REAL 111 SMALLINT 111 TIME 111 VARCHAR 111
U
UML 17, 30, 40, 41, 42
V
Verrouillage 170 Verrous 168 Vues 116, 165
W
World Wide Web 2, 11
X
XML 11, 12
Index
193
Informatique
Synthse de cours
Lauteur :
Nicolas Larrousse est ingnieur au CNRS. Spcialis en informatique, il enseigne les bases de donnes luniversit de Versailles Saint-Quentinen-Yvelines et au service de formation permanente de luniversit Pierre et Marie Curie Jussieu.
Le relecteur :
ric Innocenti est matre de confrences en informatique luniversit de Corse. Il est responsable pdagogique des lires SRC (Services et Rseaux de Communication) et LPM (Licence Professionnelle Multimdia). Il enseigne lalgorithmique, la programmation et les systmes dinformation.
La collection Synthex informatique propose de (re)-dcouvrir les fondements thoriques et les applications pratiques des principales disciplines de science informatique. partir dune synthse de cours rigoureuse et dexercices aux corrigs dtaills, le lecteur, tudiant ou professionnel, est conduit au cur de la discipline, et acquiert une comprhension rapide et un raisonnement solide.
Pearson Education France 47 bis, rue des Vinaigriers 75010 Paris Tl. : 01 72 74 90 00 Fax : 01 42 05 22 17 www.pearson.fr
ISBN : 978-2-7440-7386-1