Vous êtes sur la page 1sur 205

Informatique

Synthse de cours

& exercices
corrigs

Cration de bases de donnes


Toutes les tapes de la cration dune base de donnes, de lanalyse la ralisation laide du langage SQL Les mcanismes de prservation et de scurisation des donnes Des ressources sur www.pearson.fr : chiers des donnes et textes des requtes

collection

Synthex

Nicolas Larrousse

Informatique

Synthse de cours

&

exercices corrigs

Cration de bases de donnes


Nicolas Larrousse CNRS
Avec la contribution de ric Innocenti Universit de Corse Pasquale Paoli

Synthex

collection

ISBN : 978-2-7440-7386-1 ISSN : 1768-7616

2009 Pearson Education France Tous droits rservs

Composition sous FrameMaker : IDT

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

82 95 96 97 110 116 120


Sommaire III

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

Cration de bases de donnes

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.

Cration de bases de donnes

Chapitre

Introduction aux bases de donnes


1. Quest-ce quune base de donnes ? .............................2 2. volution des bases de donnes et de leur utilisation ....................4 3. Systmes de gestion de bases de donnes ..............................13 4. tapes de la conception des bases de donnes ..............................17 5. Mtiers des bases de donnes 19 6. Plan de louvrage .....................20 7. Prsentation de la BD exemple ...20 Exercices 1. Notion de base de donnes........22 2. Recherche dichotomique ............22 3. Langages dun SGBD.................23 4. Modles de reprsentation .........23 5. Mtiers des bases de donnes ....23 6. Utilisateurs dune base de donnes ..............................24 7. Vues externes ...........................24 8. Base de donnes rparties .........25 9. XML .........................................25 10. Fouille de donnes et entrepts de donnes ..............................26

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.

Quest-ce quune base de donnes ?


Le nombre dinformations disponibles et les moyens de les diffuser sont en constante progression. La croissance du World Wide Web a encore accru ce dveloppement, en fournissant laccs des bases de donnes trs diverses avec une interface commune. Celles-ci se situent au cur de lactivit des entreprises, des administrations, de la recherche et de bon nombre dactivits humaines dsormais lies linformatique. Dans le domaine purement informatique, elles interviennent dornavant tous les niveaux. Les dveloppeurs dapplications sappuient sur des bases de donnes externes pour grer leurs donnes alors quauparavant elles taient intgres dans le programme. Citons un autre exemple : la gestion des fichiers dans les nouveaux systmes dexploitation (par exemple, Panther de chez Apple ou le futur Vista de Microsoft) volue vers de vritables bases de donnes mises jour en permanence. Elles permettent de retrouver les fichiers instantanment, par leur nom mais aussi par leur contenu, la manire dun moteur de recherche. Les bases de donnes reposent sur des thories solides et sont lorigine dune des plus importantes disciplines de linformatique : lingnierie des systmes dinformation. Cette section prsente une ide intuitive de ce quest une base de donnes, de son utilisation puis des lments de qualit qui lui sont associs.

1.1 NOTION DE BASE DE DONNES


Tout le monde a une ide naturelle de ce que peut tre une base de donnes : elle peut revtir la forme dune liste de CD contenant le nom des artistes et les titres des morceaux ou encore celle de fiches de recettes de cuisine. On remarque quune caractristique des donnes contenues dans une base de donnes est quelles doivent possder un lien entre elles. En effet, des donnes choisies au hasard ne constituent certainement pas une base de donnes. Celle-ci est donc une reprsentation partielle et (trs) simplifie du monde rel, que lon a obtenu par un processus de modlisation. En rsum, on dfinit une base de donnes comme lensemble des donnes stockes. Pour les manipuler, on utilise gnralement un logiciel spcialis appel SGBD (Systme de Gestion de Bases de Donnes). Il y a parfois confusion, par abus de langage, entre base de donnes et SGBD. On appelle aussi systme dinformation lensemble compos par les bases de donnes, le SGBD utilis et les programmes associs. Plus formellement, on appelle Base de Donnes (BD) un ensemble de fichiers informatiques ou non structurs et organiss afin de stocker et de grer de linformation.

1.2 UTILISATION DUNE BASE DE DONNES


La cration dune base de donnes recle un but prcis : elle doit permettre de retrouver de linformation par son contenu en se fondant sur des critres de recherche. On dsire, par exemple, retrouver toutes les recettes qui ncessitent des ufs ou tous les CD qui contiennent un morceau donn. La grande diffrence avec un programme crit dans un langage de programmation est quune base de donnes doit pouvoir rpondre des questions pour lesquelles elle na pas forcment t prvue la conception. Une autre diffrence est que les donnes sont susceptibles dtre utilises par des applications diffrentes. Dans un programme classique, la structuration des donnes est dcrite

Cration de bases de donnes

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

Titre Streetwise Underground Two a day

Musicien Olivier Temime Thelonious Monk Chet Baker

Label Nocturne Columbia Dreyfus

Anne 1978 2005 1968

Chane de caractres de taille 50

Chane de caractres de taille 20

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.

1.3 QUALIT DUNE BASE DE DONNES


Comme on la voqu prcdemment, lun des objectifs de cration dune base de donnes est de pouvoir retrouver les donnes par leur contenu. Dans cette optique, il faut sassurer que les donnes contenues dans la base sont de bonne qualit . Comment dfinir la qualit des donnes ? De nombreux critres peuvent tre pris en compte ; on peut citer parmi les principaux : la cohrence des donnes contenues dans la base ; labsence de redondance. La cohrence des donnes est fondamentale ; elle ncessite une rflexion pralable sur la normalisation du contenu des champs. On suppose quun champ contient la qualit dune personne (par exemple, Monsieur, Madame, Mademoiselle). Si lon trouve dans ce champ Mr la place de Monsieur, il est clair que les recherches sur ce champ par le contenu Monsieur risquent dtre errones. Dans ce cas, les informations seraient moins nombreuses que celles obtenues avec le contenu correct. On qualifie cet tat de fait de silence , qui signifie que certains rsultats pertinents sont ignors lors dune interrogation. Dans un autre cas, si lon saisit Mme pour Madame et Melle pour Mademoiselle, et quil y ait eu par erreur plusieurs saisies de Mme alors quil sagissait dune demoiselle, la recherche par le contenu Mme donne cette fois plus de rsultats quil ny a rellement de dames. On qualifie cet tat de fait de bruit , qui signifie que certains rsultats non

Introduction aux bases de donnes 3

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.

Nom Jaco Stanley Marcus Charles Steve

Tlphone 0668541087 0654789254 0658741263 0639517720 0659874120

Ville Bordeaux Nancy Bordo Nancy Boredeaux

Code postal 33000 54000 33000 54000 33000

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.

volution des bases de donnes et de leur utilisation


Le dveloppement des bases de donnes stend sur une priode dune quarantaine dannes. Cette section prsente tout dabord le contexte dans lequel elles se sont dveloppes. On aborde ensuite les modles utiliss successivement pour les reprsenter. Enfin, la dernire partie prsente une vue prospective des changements dans lutilisation 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.

Cration de bases 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.

Modle hirarchique et modle rseau


Le traitement de linformation cette poque est encore trs li lorganisation des fichiers sur une machine. Les modles conceptuels de donnes sont eux aussi trs proches du systme de fichiers puisque lon manipule des graphes ou des arbres. Les nuds de ces structures constituent les informations et les liens entre ces donnes les artes. ce moment, on nest pas encore capable de sparer compltement le niveau logique du niveau physique dun systme de bases de donnes (voir figure 1.2). Le modle hirarchique propose une classification arborescente des donnes la manire dune classification scientifique. Dans ce type de modle, chaque enregistrement na quun seul possesseur ; par exemple, une commande na quun seul client. Cependant, notamment cause de ce type de limitations, ce modle ne peut pas traduire toutes les ralits de linformation dans les organisations. Le modle rseau est une extension du modle prcdent : il permet des liaisons transversales, utilise une structure de graphe et lve de nombreuses limitations du modle hirarchique. Dans les deux cas, les enregistrements sont relis par des pointeurs : on stocke ladresse de lenregistrement auquel il est li. Des SGBD de type hirarchique ou rseau sont encore employs pour des raisons defficacit lorsque la structure des donnes sy prte. On utilise cet effet des SGBD de conception ancienne, comme IMS (Bull) pour le modle rseau ou IDMS (Computer Associate). Figure 1.2
Modle hirarchique.
Personne
Nom Prnom NumINSEE

Voiture Logement
Marque Type Couleur Numro Rue Ville Type

Introduction aux bases de donnes 5

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

Cration de bases de donnes

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-

Introduction aux bases de donnes 7

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

Nom Durand Atamp

Prnom Dal Charles

Les ditions du temps qui ne passe pas

La vie sans mode demploi

Romazava
Nom Brass Duporche Chteau Paclaire Prnom Alexis Jean-Marie Romain Anne-Isabelle

2.3 VOLUTION DE LUTILISATION DES BASES DE DONNES


Cette section prsente une description de nouvelles manires de stocker ou dutiliser les bases de donnes. La diffrence par rapport la section prcdente est que lon ne remet pas en cause le modle utilis pour dcrire les donnes sauf, dans une certaine mesure, pour le cas de XML.

Base de donnes rparties


Le dploiement des rseaux ainsi que laugmentation de leur dbit ces dernires annes ont conduit rpartir les donnes sur plusieurs sites gographiques, ce qui facilite la politique de dcentralisation des organisations. Ce type darchitecture masque la rpartition de linformation tout en garantissant une gestion transparente aux utilisateurs, comme sils disposaient dune seule base de donnes (voir figure 1.6). Les bases de donnes rparties assurent ainsi une plus grande fiabilit, de meilleures performances et facilitent lvolution du systme dinformation. La fiabilit et la scurit. On effectue une copie de scurit des donnes sur un site distant intervalles rguliers pour viter le dsastre de la perte de donnes due un incendie par exemple. La disponibilit. On procde des rplications quasi permanentes des donnes dans le but de rapprocher les utilisateurs des donnes dun point de vue de la topologie du rseau. On amliore galement le temps de rponse en rpartissant la charge entre les serveurs. Cette distribution est gre de manire intelligente par les systmes informatiques, ce qui permet de rpartir linformation efficacement sur les diffrents sites, en fonction des accs utilisateurs. Ces principes sont notamment utiliss par les moteurs de recherche. Les donnes sont rparties sur des sites spars. Le dispositif permet de masquer cet aspect aux utilisateurs et de fonctionner comme si un seul serveur tait prsent sur un seul site. Lvolution du systme est rendue totalement transparente pour les utilisateurs : en cas notamment de changement de machine la suite dune panne, de

Cration de bases de donnes

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 Ocan indien

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.

Extraction dinformations non explicitement stockes dans une base de donnes


Il existe deux manires de crer de la nouvelle information partir de linformation stocke explicitement dans une base de donnes. Soit on est capable dnoncer des rgles prcises de constitution de linformation partir du sens mme des donnes, soit on utilise des mthodes danalyse afin de trouver des corrlations sur un volume de donnes important, ce qui permet ensuite den dduire des rgles. La premire possibilit a t formalise et mise en uvre sous le nom de base de donnes dductives, dans le but dutiliser des mthodes semblables celles pratiques pour la dduction en intelligence artificielle. On dfinit un ensemble de rgles et on les applique aux donnes de la base, laide dun programme que lon appelle un moteur dinfrence . Les SGBD qualifis de dductifs utilisent cet effet un driv du langage Prolog : Datalog. Les relations de parent entre individus sont une bonne illustration de lutilisation des bases de donnes dductives. Intuitivement, on peut apprhender le fonctionnement gnral de ces SGBD dductifs en considrant lexemple suivant. On suppose que lon a une base de donnes qui reprsente les relations pre-fils (voir figure 1.7). Une rgle trs simple permet de dfinir un lien de parent anctre : Si pre-fils(X,Y) et pre-fils(Y,Z), alors anctre(X,Z). La seconde possibilit dobtenir linformation nouvelle partir de linformation existante relve des mthodes dites de fouilles de donnes (ou data mining). Ce type dexploitation des bases de donnes a connu un grand succs ces dernires annes, par lanalyse de grands volumes de donnes afin didentifier des corrlations entre des valeurs de champs. Par exemple, les personnes moustachues de plus de quarante ans habitant une maison individuelle lisent plutt des revues de psychologie . Les techniques danalyses employes sont une alchimie concocte partir de statistiques, de rseaux de neurones, de classifications et autres techniques employes en intelligence artificielle. Une fois ces rgles tablies, on peut les utiliser au sein des bases de donnes dductives dcrites prcdemment.

Introduction aux bases de donnes 9

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.

Entrepts de donnes (datawarehouse)


Les entrepts de donnes sont des bases de donnes rcapitulatives , constitues partir de diffrentes sources de lentreprise (comptabilit, ventes, achats, service du personnel) pour disposer dun accs homogne lensemble des donnes. Les donnes disperses ne peuvent pas tre exploites directement en tant quinformation dcisionnelle. En effet, il nest pas possible danalyser efficacement dans le temps des indicateurs de gestion par mtiers ou par individus. Les donnes sont alors rapatries et stockes dans un entrept de donnes ou datawarehouse (voir figure 1.8). Si linformation est disponible, on stocke les diffrentes valeurs dune donne, ce qui permet de conserver un historique dans le temps de certaines donnes : elles sont dites historises. Ce dernier aspect est dsign parfois aussi comme une base de donnes temporelle, dans la mesure o le SGBD procure des outils danalyse adapts. Il est alors possible deffectuer des analyses dcisionnelles qui combinent tous les paramtres de lentreprise : cest lanalyse dcisionnelle multidimensionnelle. Les techniques prcdentes de fouille de donnes et de dduction peuvent tre utilises. Elles sont combines avec dautres outils danalyse de lvolution dune donne partir de son historique pour en extrapoler des tendances et ainsi faire des prvisions. Lide des entrepts de donnes est plus quintressante, mais il est vident que sa mise en uvre est dlicate tant dun point de vue du stockage de linformation (volume de donnes, htrognit des donnes traiter) que de lanalyse des donnes (comment analyser, quelle information stocker). En outre, il sagit le plus souvent du poste budgtaire le plus onreux dans un projet dinformatique dcisionnelle.

10

Cration de bases de donnes

Chapitre Figure 1.8


Entrepts de donnes.
Service achats
Analyse

Production

Entrept de donnes Service marketing (datawarehouse)

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

Introduction aux bases de donnes 11

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> <nom> <prix>

</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

Cration de bases de donnes

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.

Systmes de gestion de bases de donnes


On a beaucoup parl dans les sections prcdentes des SGBD. Un SGBD est un logiciel complexe qui permet de grer et dutiliser les donnes que lon stocke en utilisant les modles cits prcdemment. La premire partie de la section permet de comprendre le mcanisme dabstraction partir duquel se fait le passage du simple fichier informatique la gestion de linformation qui se fonde sur lutilisation dun SGBD. Une seconde partie dtaille le modle en couches des SGBD ainsi que leurs fonctionnalits de base.

3.1 FICHIERS INFORMATIQUES


Un fichier peut tre vu (historiquement) comme un morceau de bande magntique. Les mcanismes de gestion de fichiers des langages de programmation, comme le langage C, fonctionnent encore avec cette mtaphore. Lorsquon utilise un fichier pour stocker de linformation, il est ncessaire de prvoir un dcoupage de celui-ci par enregistrements, souvent de taille fixe. Pour passer dun enregistrement lautre, il suffit alors davancer la tte de lecture de la taille dun enregistrement (voir figure 1.10). Les donnes sont stockes dans lenregistrement par un dcoupage interne suivant la taille de chaque donne. On utilise gnralement des structures de donnes (par exemple, en langage C) pour rcuprer directement chaque valeur de champ dans une variable. Dans une base de donnes, on recherche les donnes par leur contenu. Pour retrouver lune dentre elles, il faut donc parcourir tous les enregistrements un un (recherche squentielle), et en examiner le contenu.

Introduction aux bases de donnes 13

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

Cration de bases de donnes

Chapitre

3.2 FONCTIONNALITS DUN SGBD


De mme que lISO a dtermin un modle thorique en sept couches pour distinguer les applications rseaux et leurs interactions, il existe dsormais un modle thorique en trois couches (trois niveaux dabstraction) afin de concevoir et dorganiser les fonctionnalits des SGBD. Ce modle est labor par la commission SPARC de lANSI : cest larchitecture ANSI/SPARC (voir figure 1.12). Cette dernire, qui date de 1975, sinscrit dans les concepts et thories de la premire gnration des bases de donnes, dont lobjectif est davoir une indpendance entre les donnes et les traitements : Niveau interne ou physique. Cest le niveau le plus bas . On dcrit les structures de stockage de linformation, ce qui le rend trs dpendant du SGBD employ. Il se fonde sur un modle de donnes physique. Niveau conceptuel. Il correspond limplmentation du schma conceptuel de la base de donnes, que lon ralise lors de la phase danalyse (voir Modle Conceptuel des Donnes, Modle Logique des Donnes). Il est utilis pour dcrire les lments constitutifs de la base de donnes et les contraintes qui leur sont associes. Il sagit dune certaine faon de la documentation de la base de donnes. Niveau externe. Le niveau externe sert dcrire les vues des utilisateurs, cest--dire le schma de visualisation des donnes qui est diffrent pour chaque catgorie dutilisateurs. Un schma externe permet de masquer la complexit de la base de donnes complte en fonction des droits ou des besoins des utilisateurs. Cela facilite la lecture et la scurit de linformation.
Utilisateurs

Figure 1.12
Niveaux ANSI/ SPARC.
Niveau externe
Vues

Schma conceptuel

Modle conceptuel

Niveau interne

Modle physique SGBD

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.

Introduction aux bases de donnes 15

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

Cration de bases de donnes

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.

tapes de la conception des bases de donnes


On peut dcomposer le processus de conception dune base de donnes en plusieurs tapes : lanalyse du systme du monde rel modliser ; la mise en forme du modle pour lintgrer dans un SGBD ; la cration effective dans le SGBD des structures et leur remplissage (voir figure 1.13).

4.1 ANALYSE DU MONDE REL


La premire tape de la dmarche de modlisation des donnes consiste effectuer lanalyse de la situation du monde rel considrer. Cette action sapparente au travail effectu par une entreprise de consulting. Cest une approche humaine qui se fonde en partie sur des entretiens avec les personnels concerns et ressemble plutt une analyse du discours et de lorganisation de lentreprise. Cest lors de cette phase danalyse que lon dtermine les objectifs du systme dinformation concevoir et que lon identifie tous les lments prendre en compte dans le systme ; ce sont les champs qui contiendront les donnes. Un ensemble de champs peut constituer un objet du monde rel. Par exemple les champs nom , prnom et adresse que lon regroupe constituent une personne . Enfin, il faut identifier les liens modliser entre ces objets ainsi que les lments caractristiques de ces liens. Par exemple une personne achte une voiture 10 000 euros. Ici les deux objets lis sont personne et voiture , et le prix est le composant du lien. Cette tape est dlicate et fondamentale, car elle conditionne laspect reprsentatif et la qualit du modle du monde rel considr. Lors de cette phase, il convient galement dexprimer les rgles qui dfinissent le domaine de validit du contenu des champs. Par exemple, le prix dune voiture ne peut pas tre infrieur 500 euros ou suprieur 150 000 euros. Cette modlisation du rel permet de proposer un schma conceptuel qui servira la description gnrale du systme dinformation. La notion de sens des donnes et surtout des liens entre les entits ne sera rellement exprime que dans ce schma qui est plus proche du monde rel. Ce schma est souvent ralis laide de la symbolique du modle entitassociation ou, plus couramment aujourdhui, exprim avec le langage UML (Unified Modeling Language). Il existe diffrentes mthodes intgrant les concepts prsents ci-dessus. Lobjectif est de guider le travail danalyse et daider la ralisation dun modle de donnes le plus juste possible. Parmi celles-ci, la mthode Merise a connu un certain succs dans le domaine en France.

4.2 PASSAGE AU SGBD


La reprsentation prcdente doit tre transforme pour la rendre acceptable par le SGBD, quil soit relationnel, objet ou relationnel-objet. Souvent, cette tape modifie considrablement les objets du monde rel ainsi que les liens dfinis dans le schma prcdent. Cest lors de cette phase que lon vrifie la qualit de la base de donnes en utilisant les critres

Introduction aux bases de donnes 17

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.

4.3 CRATION ET UTILISATION DE LA BASE DE DONNES


Une fois le schma prcdent dfini, on utilise le SGBD pour passer la cration des tables qui constituent la base de donnes. Puis, on insre videmment les valeurs dans les tables. Le cas chant, on cre les vues dfinies ltape prcdente et par l mme les utilisateurs concerns. Le systme est alors oprationnel. Toute cette tape se fait forcment en utilisant le SGBD, alors que les prcdentes taient plus thoriques. La cration des tables et lutilisation de la base de donnes ncessiteront le langage SQL. Cependant, il existe de nos jours de nombreux outils graphiques dans les SGBD qui masquent lutilisation du SQL. Figure 1.13
tapes de la conception dune base de donnes.
Monde rel

Analyse
Modle entit-association

Vue 1
Transformation

Schma
Vue 2

LMD LDD

SGDB

relationnel

Vue 3

Base de donnes physique

18

Cration de bases de donnes

Chapitre

Mtiers des bases de donnes


Comme on peut le constater lorsque lon considre les diffrentes tapes de la conception dune base de donnes, des acteurs aux comptences trs diverses interviennent dans ce processus.

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.

5.2 CONCEPTEURS DE LA BASE


Ce sont les personnes qui soccupent de traduire le modle prcdent en un modle logique exploitable par le SGBD. Le concepteur est un spcialiste des bases de donnes qui prpare les tables, les vues, les schmas daccs. Cest lui qui renseigne les utilisateurs et programmeurs pour la dfinition des requtes. Il na pas, en principe, tre spcialis sur un SGBD particulier, mais en pratique les lments quil manipule sont lis au SGBD qui sera employ. Cest ordinairement lui qui cre les lments ncessaires la base de donnes (tables, vues) en collaboration avec ladministrateur de la base. Cest parfois la mme personne qui est en charge de la partie analyse et de la conception, ce qui peut induire une vision un peu trop oriente techniquement comme celle dun programmeur qui crirait le cahier des charges dune application. Par contre, le concepteur peut aussi tre administrateur du SGBD, ce qui ne pose pas de problmes particuliers dapproche.

5.3 ADMINISTRATEURS DE BASE DE DONNES (DBA, DATABASE ADMINISTRATOR)


Ladministrateur a la responsabilit du fonctionnement gnral du SGBD. Il cre les ressources (bases, comptes) la demande. Il donne les droits daccs et gre les personnes qui accdent au systme. Il vrifie que les ressources sont suffisantes (taille du disque, puissance de la machine), effectue les sauvegardes, vrifie les failles de scurit. Pour ces oprations, il est en relation avec ladministrateur systme et rseau de la structure. Ce mtier est extrmement li au SGBD employ. Il ny a pas vraiment de normalisation pour les oprations dadministration des SGBD qui sont spcifiques au SGBD et la version utiliss.

5.4 UTILISATEURS STANDARD ET PROGRAMMEURS DAPPLICATIONS


Ce sont eux qui utilisent le systme dinformation. Ils y ont accs grce aux vues dfinies par le concepteur de la base. Ils utilisent les schmas dtermins aux deux premires tapes de la conception. Ils nont pas besoin thoriquement dtre spcialiss sur le SGBD employ. En pratique il est prfrable, surtout pour les dveloppeurs dapplications, davoir de bonnes connaissances du fonctionnement du SGBD. Par exemple, pour optimiser les performances, la manire dcrire les requtes peut tre assez diffrente suivant le SGBD employ.

Introduction aux bases de donnes 19

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

Cration de bases de donnes

Chapitre Figure 1.14


Base de donnes exemple.
Marque Nom

Vente Type Couleur Ville

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.

Introduction aux bases de donnes 21

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

Cration de bases de donnes

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

MTIERS DES BASES DE DONNES


Est-il possible de faire raliser toutes les tapes de la conception dune base de donnes par une mme personne ? Si oui, quelles sont alors ses comptences minimales ? Dans une petite structure, cest souvent la mme personne qui ralise lensemble du processus de construction dune base de donnes. Ce nest videmment pas la bonne mthode, car la vision dun systme dinformation labor par un administrateur de base de donnes est trs oriente par le SGBD quil emploiera. On peut facilement faire le parallle avec le dveloppement de logiciels o un programmeur va avoir une approche dforme par les proccupations lies au langage plutt que dadopter un point de vue sur la structure gnrale de lapplication. Au minimum, la personne devra disposer des comptences en conception de base de donnes et en administration du SGBD qui sera utilis.

Introduction aux bases de donnes 23

Exercices

EXERCICE 6

UTILISATEURS DUNE BASE DE DONNES


On utilise pour cet exercice la base de donnes exemple de vente de voitures. On considre les oprations suivantes : 1. 2. 3. 4. Ajouter une personne dans le fichier client. Modifier les possibilits dajout dans le champ couleur . Augmenter la taille du champ couleur. Sortir le chiffre daffaires par marques pour le mois en cours afin de limporter dans un tableur. 5. Enregistrer une vente. Quels types dutilisateurs sont concerns par ces oprations ? 1. Un utilisateur final (par exemple un vendeur) muni des droits appropris peut intervenir sur le contenu des donnes. 2. Pour cette opration, cela dpend sil sagit dune convention ou si cela est entr au niveau des contraintes du SGBD. Dans le premier cas, un utilisateur final peut sen charger ; dans le second, il faut recourir au concepteur ou ladministrateur de base de donnes. 3. Pas dambigut ici, car on touche la structure mme des donnes ; cela est du ressort du concepteur ou de ladministrateur de base de donnes. 4. Il sagit du domaine du programmeur dapplication qui rcupre les donnes en utilisant le SGBD et qui les traite dans un programme pour leur donner leur forme finale. 5. Un utilisateur final (par exemple un vendeur ou la comptabilit) muni des droits appropris peut intervenir sur le contenu des donnes.

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

Cration de bases de donnes

Chapitre

EXERCICE 8

BASE DE DONNES RPARTIES


On dcide de recopier rgulirement une base de donnes complte sur chacun des six sites de lentreprise. Quel est lintrt de cette solution ? Cest une solution coteuse en ressources, en particulier pour la synchronisation de toutes les mises jour, mais qui peut remplir deux fonctions : 1. De toute vidence, lide est que les diffrents sites de lentreprise accdent leur copie locale des donnes. Cela permet dacclrer les accs et de rpartir la charge sur les serveurs locaux de chaque site. Accessoirement, la circulation des requtes dinterrogation et de mise jour peut tre limite au rseau local, ce qui renforce la scurit. 2. Il existe six copies des donnes sur des sites gographiquement spars. En cas de sinistre, on peut repartir sans problmes avec une des copies de la base. Avant de mettre en place un tel dispositif, on doit se poser la question de la mise jour des donnes. Est-ce que les modifications se font uniquement sur la base matre , ce qui semble plus raisonnable, ou peut-on les effectuer sur toutes les bases et consolider ensuite ?

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.

Introduction aux bases de donnes 25

Exercices

EXERCICE 10

FOUILLE DE DONNES ET ENTREPTS DE DONNES


Par des mthodes danalyse dassociations, on dcouvre quen utilisant votre systme dinformation les clients dont le nom commence par M achtent le samedi plus de produits que les autres. Ils gnrent donc un chiffre daffaires plus important, mais ces produits sont marge faible et le bnfice est moins important que pour ceux dont le nom commence par un Z. Quavez-vous intgr comme donnes dans votre entrept de donnes pour pouvoir effectuer cette opration en supposant que votre entreprise soit organise avec une structure de services classique ? Pour obtenir les lments ncessaires lanalyse, il nous faut intgrer les donnes de diffrents services de lentreprise. Les donnes du fichier clientle sont gres par le service commercial (peut-tre avec un tableur ou un traitement de texte pour faire des mailings) afin dobtenir le nom des clients. Les donnes du service comptabilit permettent dobtenir les journaux de ventes ; la gestion est faite par exemple par une application de gestion spcifique connecte aux caisses. Les donnes du service achat sur les ngociations avec les fournisseurs peuvent tre gres par exemple par une application dveloppe en interne. La marge provenant de la ngociation avec les fournisseurs est fluctuante pour le mme article au cours du temps en fonction du march, des personnes qui ngocient, etc. Il serait donc intressant pour ces donnes de disposer des valeurs historises par priodes pour affiner lanalyse par des tendances. Pour intgrer ces donnes provenant de sources diffrentes dans votre entrept de donnes, vous utiliserez une (ou plusieurs) application(s) de type ETL (Extract, Transform and Load) que lon appelle aussi datapumping .

26

Cration de bases de donnes

Chapitre

Analyse du monde rel


1. Dmarche danalyse .................28 2. Modlisation par le modle entit-association ......................30 3. Remise en cause et volution du modle ...............................35 4. Reprsentation avec UML ..........40 Exercices 1. Identifiant dune entit ...............44 2. Identification des entits et des associations ....................44 3. Questions associes aux cardinalits ........................45 4. Description du monde rel partir des cardinalits .............47 5. Association inutile .....................48 6. Association rflexive...................49 7. Association ternaire ..................49 8. De lnonc au modle entit-association ......................51 9. Reprsentation avec UML ..........52 10. Autre exemple le camping lUliastru ..................................53

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

1.1 APPROCHE DU MONDE REL


Comment apprhender et simplifier le monde rel, par nature complexe, pour raliser une modlisation ? Cette tche relve de comptences multiples du domaine dun cabinet de consulting. Il est ncessaire didentifier les besoins des utilisateurs ainsi que les objectifs et les processus dalimentation en donnes des systmes dinformation concevoir. Les bases de donnes sont dornavant au cur de la plupart des applications, et leur structure doit correspondre au mieux aux attentes de lorganisation. Son laboration ncessite diffrentes tapes et se droule souvent en mme temps que le processus danalyse du problme. Des allers-retours entre ces diffrentes tapes de la conception sont souvent ncessaires la constitution du modle conceptuel de la base. On qualifie alors ce processus ditratif. Il sagit de construire la structure de la base de donnes par raffinements successifs. La premire phase de lanalyse du monde rel du problme est ralise par des entretiens, gnralement codifis, avec les utilisateurs. On effectue une analyse du discours pour en extraire linformation utile que lon resitue dans le contexte de lorganisation en gnral. Lobjectif principal est de guider lanalyste, on utilise des mthodes danalyse et de conception issues de ltude des flux dinformation de lentreprise. Parmi celles-ci, on peut citer la mthode Merise dorigine franaise trs rpandue en France dans les annes 1980 ainsi que dautres issues de la recherche et du gnie logiciel, ou spcifiques des grandes entreprises de consulting. La prsentation de ces mthodes fort complexes dpasse largement le cadre de cet ouvrage. Lobjectif de cette section est de donner quelques pistes pour approcher la ralit modliser. Lexpression des besoins repose sur la formulation du problme laide de phrases simples qui dcrivent la ralit modliser. Ces phrases se prsentent sous la forme sujet-verbe-complment , avec une tournure active quand cela est possible. Le but est dobtenir deux types de phrases : Celles qui dcrivent les liens entre les objets du monde rel gnralement une action ou une proprit. Exemple : Un lecteur emprunte un livre. Un livre a un auteur. Celles qui caractrisent la manire dont sont relis ces objets. Exemple : Un lecteur est considr comme lecteur sil a au moins dj emprunt un livre. Un livre peut tre emprunt par plusieurs lecteurs. Il ny a pas de livres anonymes, un livre est crit par au moins un auteur. On doit ensuite prciser les donnes qui constituent les objets ainsi que celles qui caractrisent les liens entre les objets.

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

Cration de bases de donnes

Chapitre

1.2 MISE EN UVRE


Comment procder intuitivement pour obtenir ces phrases ? Un bon point de dpart consiste faire linventaire des objets tangibles ou perus du monde rel. Une fois ces objets identifis, on cherche exprimer le (ou les) lien(s) qui permet(tent) de les associer. Par exemple, si lon doit modliser une activit de location de DVD, les objets que lon peut apprhender immdiatement sont les DVD et les clients. En ce qui concerne les liens entre ces objets, on note quun client rserve un DVD ou quun client loue un DVD, etc. Ensuite, il faut identifier les objets moins faciles percevoir directement : les fournisseurs, les acteurs, les ralisateurs Enfin, une fois les objets identifis, on cherche qualifier les liens trouvs. Il faut tenir compte du fait que le lien est toujours double sens. Par exemple, un client emprunte plusieurs DVD. Un DVD est emprunt plusieurs fois ou nest jamais emprunt par un client. Pour obtenir ce rsultat, quelles questions faut-il se poser et quelles questions doit-on poser aux acteurs de lorganisation ? Dcrivez lactivit globalement, en termes simples, sans entrer dans les dtails, pour identifier les objets et leurs liens ventuels. Indiquez quelles sont les procdures utilises dans lactivit pour caractriser les liens entre les objets. Les procdures permettent dnoncer les contraintes qui seront intgres ensuite dans la base de donnes. On note que lon modlise souvent des actions qui reprsentent une activit, plus rarement des lments statiques. Les actions reprsentent frquemment le lien entre les objets : une personne emprunte un DVD, une voiture est achete par un client, etc.

1.3 NOTION DE TEMPS


Le temps est une notion importante, une base de donnes modlise des actions qui ont lieu durant une priode de temps. Il faut toujours avoir lesprit cet aspect pour viter des erreurs de conception. Une erreur classique est de confondre laspect simultan dune action avec la possibilit de la ritrer durant la priode concerne. Lorsque lon spcifie qu un livre peut tre emprunt plusieurs fois , il est vident quun livre ne peut tre emprunt par deux personnes simultanment, mais plutt quil pourra tre emprunt plusieurs reprises durant la priode modlise du fonctionnement de la bibliothque.

1.4 CAS PRATIQUE


Afin dillustrer les recommandations prcdentes, on considre la modlisation trs schmatique du fonctionnement dun htel. Quelle(s) phrase(s) simple(s) dcri(ven)t lactivit de lhtel ? On peut proposer en premire approche cette phrase : Un htel loue des chambres des clients qui effectuent des rservations. Aprs avoir procd lanalyse de la phrase pour en extraire les parties importantes, on peut la rcrire de la manire suivante : Un client loue une chambre ; un client rserve une chambre.

Analyse du monde rel 29

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.

Modlisation par le modle entit-association


Aprs ltape de recueil dinformations, on dispose dun ensemble de phrases simples qui expriment les besoins dcrivant la ralit modliser : on doit alors en effectuer une reprsentation. Cette dernire est trs importante, car elle est la seule qui donnera une vue densemble des donnes et des liens qui les caractrisent. Le modle obtenu cette tape est en gnral nomm Modle Conceptuel des Donnes (MCD). En effet, on verra lors de ltape du passage au modle relationnel, appel galement modle logique, que cette information napparat plus. Les donnes stockes dans le SGBD seront presque inutiles si lon ne dispose pas du modle conceptuel qui est lquivalent du schma technique dun appareil ou du plan dun btiment. Le formalisme le plus rpandu pour constituer ce schma est le modle entit-association (ou entity-relationship en anglais). Il a t prsent lorigine par P. Chen en 1976 aux tats-Unis quasi simultanment avec le modle de H. Tardieu en France, ce qui explique les notations lgrement diffrentes en Europe et aux tats-Unis, en particulier au niveau de la reprsentation des cardinalits. Le modle entit-association a t normalis lISO. On verra dans la section suivante que lon peut utiliser galement le formalisme UML pour la reprsentation. Le formalisme entit-association , tout comme UML, utilise une reprsentation graphique sous forme de diagrammes. Les entits sont les objets concrets ou abstraits du monde rel voqus plus haut. Les associations reprsentent le lien entre ces entits. Comme on la vu prcdemment, on peut identifier les entits et les associations en effectuant une analyse du discours, cest--dire des phrases de type sujet-verbe-complment . Les sujets et les complments sont les entits, et le verbe modlise lassociation.

30

Cration de bases de donnes

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

Occurrences chambre Chambre


13

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

Analyse du monde rel 31

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

Cration de bases de donnes

Chapitre Figure 2.5


Entit personne relie par lassociation est_mari_.

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.

Analyse du monde rel 33

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.

2.4 CAS DTUDE CASSE


On a prsent dans le chapitre dintroduction la base de donnes exemple casse , qui dcrit lactivit de vente de voitures doccasion. Voici sa modlisation sous forme de modle entit-association. On rappelle la description de 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, caractrise par le prix de la vente et sa date. Une personne peut acheter plusieurs voitures ou aucune. Une personne peut acheter aucune ou plusieurs voitures. Une voiture peut tre vendue ou non.

Recherche des identifiants


Les deux entits voiture et clients ainsi que leurs attributs respectifs sont bien dfinis ; il manque pour chacune de ces entits un identifiant capable de diffrencier les occurrences (ou reprsentants) des entits voitures et des clients. Sur cet exemple simple, il est facile de vrifier quaucun attribut ni ensemble dattributs ne permet de dfinir sans ambigut un identifiant. Le processus de recherche dun identifiant partir des relations de dpendances entre les attributs, est dtaill au chapitre 3.

Recherche des cardinalits


Les cardinalits sont dduites des deux dernires phrases : 0,n. Pour une personne peut acheter plusieurs (n) voitures ou aucune (0) . 0,1. Pour une voiture peut tre vendue une seule fois (1) ou jamais (0) .

34

Cration de bases de donnes

Chapitre Figure 2.8


Entits voiture et client lies par lassociation vente avec cardinalits.

Client
NumAch Nom ge Ville Sexe

1,n

Vente
DateVente Prix

Voiture 0,1
# NumVoit Marque Type Couleur

Remise en cause et volution du modle


Cette section nonce quelques conseils pour amliorer et affiner le modle conceptuel obtenu ltape prcdente.

3.1 QUALIT DES ATTRIBUTS


Dans cette sous-section, on aborde les qualits gnrales que doivent possder les attributs des entits et des associations. Des rgles simples permettent de guider le choix des attributs. Une premire rgle est de ne stocker que les attributs strictement ncessaires : la tendance des utilisateurs est en gnral de prvoir le plus dattributs possible juste au cas o. Le choix seffectue en tenant compte des fonctionnalits attendues du systme dinformation par limination systmatique des donnes non utiles. Une deuxime rgle consiste ne pas retenir les attributs qui peuvent tre dduits dautres attributs. La dduction peut se faire soit par le calcul, soit par un lien smantique entre plusieurs attributs : Le chiffre daffaires peut tre calcul partir du prix de vente et de la quantit. Une rfrence peut tre construite partir du nom du produit et du fournisseur. Le but est de rduire la place occupe ainsi que les risques dincohrence. Enfin, une dernire rgle concerne le nom des attributs qui doivent tre parlants . Il ne faut pas hsiter utiliser des noms de grande taille si cela facilite la comprhension du rle de lattribut dans lentit. Par exemple, il est prfrable dutiliser un attribut Numro_Srie plutt quun attribut ns. Dans la mesure du possible, on essaie de donner des noms dattributs spcifiques pour chacune des entits. Ces deux dernires prcautions faciliteront la comprhension gnrale du modle et son utilisation future dans le SGBD.

3.2 RORGANISATION DES ENTITS


Dans cette sous-section, on remet en cause le dcoupage en entits produits par une premire approche. Le processus itratif de cette remise en cause peut conduire un redcoupage des entits ou leur fusion. On considre lexemple de la bibliothque de prt, que lon a dj utilis prcdemment. La phrase caractristique dcrivant lactivit de la bibliothque est la suivante : Un lecteur

Analyse du monde rel 35

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.

Que se passe-t-il si lon possde plusieurs exemplaires du mme ouvrage ?


Le numro ISBN nest plus identifiant puisquil est le mme pour chacun des exemplaires. Une solution consiste ajouter un numro supplmentaire unique pour chaque livre, qui correspond la notion de cote dans une bibliothque. Ainsi, mme si lon a dix exemplaires dun ouvrage, il est possible de les diffrencier. Linconvnient de cette solution est que lon rpte les informations communes aux diffrents ouvrages (titre, auteur) chaque exemplaire. Lun des risques est de rpter incorrectement ces informations et daboutir ainsi des incohrences. La solution correcte dans ce cas est de sparer lentit livre en deux entits livre et ouvrage (voir figure 2.10). Lactivit de la bibliothque est alors dcrite par deux phrases : Un lecteur emprunte un exemplaire. Un livre reprsente un exemplaire dun ouvrage. Un livre est caractris par un numro (cote) identifiant et un ISBN. Un ouvrage est caractris par un ISBN, qui est bien dans ce cas un identifiant, un titre, un auteur et un diteur. Dans cet exemple, lobjet du modle conceptuel livre, utilis comme entit, est dcompos en deux autres entits dont une est abstraite : louvrage. Louvrage est un regroupement dattributs qui na pas dexistence tangible dans le monde rel.

36

Cration de bases de donnes

Chapitre Figure 2.10


Entits livre, ouvrage et lecteur lies par les associations emprunte et est un exemplaire (sans cardinalits).

Ouvrage
#Cote ISBN

Emprunte
DateEmprunt

Lecteur
# NumLecteur Nom Prnom Adresse

Est un exemplaire Livre


Titre Auteur #ISBN diteur

Que se passe-t-il si louvrage possde plusieurs auteurs ?


Une solution simpliste est de prvoir un champ par auteur supplmentaire, cest--dire dajouter des champs auteur2, auteur3, auteur4, etc. Cette solution pose de nombreux problmes : Si seulement dix livres sur un million possdent plusieurs auteurs, on rserve la place pour les champs auteurs supplmentaires qui sera inutilise. Si un livre possde un nombre dauteurs suprieur au nombre de champs prvus, on ne rsout pas le problme. Si lon considre quun auteur peut avoir crit plusieurs ouvrages, on rpte dans ce cas les informations le concernant pour chacun de ses ouvrages. Cela constitue un cas typique de redondance qui risque de provoquer des incohrences. La solution correcte dans ce cas est de crer une entit supplmentaire pour ces attributs qui sont smantiquement de mme type. On crera ici une entit auteur qui contiendra un numro dauteur (identifiant), son nom et son prnom. Cette entit est relie lentit ouvrage par lassociation a_crit (voir figure 2.11). Figure 2.11
Entits livre, ouvrage, auteur et lecteur lies par les associations emprunte, a_crit et est un exemplaire (sans cardinalits).
Ouvrage
#Cote ISBN

Emprunte
DateEmprunt

Lecteur
# NumLecteur Nom Prnom Adresse

Est un exemplaire Livre


Titre #ISBN diteur

Auteur A crit
# NumAuteur Nom Prnom

Analyse du monde rel 37

Que se passe-t-il si un auteur emprunte un livre ?


Un auteur peut galement emprunter un livre et revtir par consquent le rle de lemprunteur. Dans ce cas, on rpte les informations le concernant dans lentit lecteur. De mme que prcdemment, cela provoque de la redondance et peut gnrer des incohrences. Comme les entits lecteur et auteur ont la mme structure (cest--dire des mmes attributs), la solution consiste les fusionner en une entit unique personne. Cette opration conduit une association entre les entits personne et livre (emprunte) et les entits personne et ouvrage (a_crit) (voir figure 2.12). Figure 2.12
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

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.

3.3 LIMINATION ET FUSION DASSOCIATIONS


Dans cette sous-section, on sintresse la rorganisation dassociations qui nont pas de raison dtre, par une fusion des associations ou par leur intgration dans les entits.

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

Cration de bases de donnes

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

1,1 Rgle 1,1

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

0,n Morceau 0,n


# NumMorceau Titre

Piano

0,n 0,n

Basse

0,n 0,n Saxophone

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).

Analyse du monde rel 39

Figure 2.16
Entits musicien et morceau lies par lassociation interprte.

Musicien
#NumMusicien Nom Prnom

1,n Interprte Instrument 1,n

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.

Reprsentation avec UML


Le langage UML (Unified Modeling Language) est un standard labor linitiative de lOMG (Object Management Group). Il est donc spcifiquement destin la modlisation objet. Comme son nom lindique, UML est le rsultat dun processus de fusion (unification) de diffrentes mthodes existantes dans le domaine de la conception objet : Booch, OMT, OOSE. Ces concepts reposent principalement sur les travaux de Grady Booch, James Rumbaugh et Ivar Jacobson. Cest un langage indpendant de la plate-forme utilise ainsi que des autres langages de plus bas niveau employs en programmation objet, comme Java et C++. Il utilise une notation graphique et a connu trs rapidement le succs dans le monde objet par la souplesse quil apporte en gestion de projets de dveloppement.

4.1 UML ET BASES DE DONNES


Quel est le rapport avec les bases de donnes ? UML a t adapt afin dtre utilis pour la modlisation en bases de donnes : on recourt cet effet un profil spcifique (UML profile for data modeling). Mme sil est prvu initialement uniquement pour la modlisation objet, UML permet aussi de reprsenter un modle conceptuel utilisable pour crer des bases de donnes relationnelles et relationnelles-objet. Les approches objet et relationnelles-objet en bases de donnes ont t introduites dans le premier chapitre et dpassent largement le cadre de cet ouvrage. En outre, une motivation supplmentaire pour utiliser UML est de pouvoir disposer doutils logiciels graphiques du march pour la description et lautomatisation du processus de passage au SGBD, allant jusqu la gnration de code SQL. UML offre des garanties de prennit du fait de sa normalisation. Mme si UML napporte pas dvolutions majeures quant aux mthodes existantes de modlisation en bases de donnes, il est de plus en plus largement rpandu et permet dutiliser le mme formalisme et les mmes outils que les concepteurs dapplications logicielles.

40

Cration de bases de donnes

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.

4.2 REPRSENTATION DU MODLE CONCEPTUEL AVEC LES DIAGRAMMES DE CLASSES UML


UML a t dvelopp lorigine pour la modlisation des concepts objet. La tendance actuelle consiste utiliser une partie restreinte de ce puissant langage de modlisation, afin de reprsenter le modle conceptuel des donnes. Dans sa version complte, UML propose neuf types de diagrammes rpartis en deux catgories : les diagrammes de structure qui dcrivent la partie statique du modle ; les diagrammes de comportement qui dcrivent la partie dynamique, cest--dire les traitements. On utilise les diagrammes de classes qui font partie des diagrammes de structure pour reprsenter les lments du modle conceptuel.

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).

Analyse du monde rel 41

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

Voiture Acheteur Dpense


# NumVoit Marque Type Couleur

4.3 DU MODLE ENTIT-ASSOCIATION UML


La notation UML est utilise dans cette section pour reprsenter les entits et les associations issues de la dmarche danalyse primitive que lon a dcrite dans la premire sec-

42

Cration de bases de donnes

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.

Analyse du monde rel 43

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

IDENTIFICATION DES ENTITS ET DES ASSOCIATIONS


On veut modliser lactivit de vente de billets pour un thtre. Quelles phrases vont nous permettre didentifier les entits et la manire dont elles sont associes ? Proposez les attributs que vous utiliseriez pour dcrire ces entits et leurs associations ainsi que les identifiants de chaque entit. Que se passe-t-il si le prix du billet varie pour chaque sance et en fonction de la place ? Les lments qui simposent intuitivement sont les spectateurs et la pice joue. La phrase qui reprsente le lien entre ces entits peut tre de la forme : les spectateurs achtent un billet pour une pice . On identifie deux entits spectateur et pice lies par lassociation achat. Lentit spectateur contient les attributs nom, numro de tlphone. On cre un identifiant numero_client puisque nom et numro de tlphone ne sont pas identifiants. On

44

Cration de bases de donnes

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

QUESTIONS ASSOCIES AUX CARDINALITS


Dans lexemple sur la bibliothque, prsent prcdemment dans ce chapitre, on est parvenu au modle suivant la suite de la remise en cause du modle (voir figure 2.21) : Les entits livre ouvrage sont lies par lassociation est_un_exemplaire Les entits personne et livre sont lies par lassociation emprunte. Les entits personne et livre sont lies par lassociation a_crit.

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

Analyse du monde rel 45

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

Cration de bases de donnes

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

Est un exemplaire Livre


1,1 Titre #ISBN diteur

A crit

1,n

EXERCICE 4

DESCRIPTION DU MONDE REL PARTIR DES CARDINALITS


On considre le schma entit-association, muni de ses cardinalits, qui dcrit une partie de lorganisation de sminaires (voir figure 2.23).

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

Analyse du monde rel 47

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

Cration de bases de donnes

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.

Analyse du monde rel 49

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,n Voiture Vente 1,1


# NumVente DateVente Prix

1,1

0,1

# NumVoit Marque Type Couleur

1,1 Vendeur
# NumVendeur Nom

1,n
Tl

50

Cration de bases de donnes

Chapitre

EXERCICE 8

DE LNONC AU MODLE ENTIT-ASSOCIATION


Vous dsirez grer un club de prt de DVD. Les clients (adhrents du club) versent une somme sur leur compte lors de leur adhsion. Ils peuvent rserver le film avant de le louer et peuvent le garder une semaine au maximum. Le prix de location du film est forfaitaire par jour emprunt. Il leur est possible de se faire livrer le film chez eux : cette opration est facture forfaitairement en plus. Le film est dcrit par son titre, le genre du film, le ralisateur et les trois acteurs principaux. On prcise galement le nombre de DVD (il peut y en avoir plusieurs dans la pochette : making of , autres versions, etc.) et leur prix dachat qui permettra de dbiter le compte du client en cas de non-retour du film. Vous voulez pouvoir annuler et mettre jour les rservations et grer les comptes des adhrents (par exemple ne plus prter au-del dun certain seuil). Vous vous servirez galement de cette base de donnes pour effectuer des bilans (tels que le chiffre daffaires en fin de mois), des relances (les films non rendus temps) et des statistiques (film le plus emprunt, meilleur client). Proposez un modle entit-association pour cette activit. On peut extraire de lnonc des phrases cls qui permettent de caractriser les entits et leurs associations : Un client rserve un film. Un client loue un film. Une personne joue dans un film. Une personne ralise un film. Trois entits apparaissent : client, film et personnel. Les entits client et film sont relies par deux associations : rservation et location. Les entits film et personnel sont relies par deux entits joue et ralise (voir figure 2.28). Le fait dutiliser la mme entit pour un ralisateur et pour un acteur (regroups dans personnel) provient du fait quun acteur peut en mme temps tre ralisateur. Si lon sparait les entits, il y aurait alors une duplication de linformation concernant cette catgorie acteurs/ralisateurs. Le reste de lnonc permet de dcrire les attributs des entits et des associations. Entit client On a peu dinformations sur cette entit, si ce nest que le client possde un compte qui fera partie de ses attributs. Les autres attributs ont t choisis classiquement (nom, prnom, adresse, tl., etc.). Il est ncessaire dutiliser un attribut pour lidentifiant : ici, NumClient. Entit film Lentit est mieux dcrite par son titre, son genre, son prix et le nombre de DVD dans la pochette. Il est galement ncessaire dutiliser un attribut pour lidentifiant : ici, NumFilm. Entit personnel Lentit ne comprend que les informations nom et prnom. Il est galement ncessaire de crer un attribut pour lidentifiant : ici, NumPers.

Analyse du monde rel 51

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

Client # NumClient NomClient PrnomClient AdresseClient TlClient Compte

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

Cration de bases de donnes

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

0..n 0..n Location


# NumLoc NbeJourLoc DateLoc # NumFilm Titre Genre Prix NbDVD

Film

0..n 0..n Rservation


# NumRs NbeJourRs DateRs

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).

Analyse du monde rel 53

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

Cration de bases de donnes

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.

1.1 MODLE RELATIONNEL


Le modle relationnel tire son nom de la notion de relation mathmatique entre des lments. Chacun de ces lments peut prendre des valeurs dans un ensemble dfini. On suppose que lon considre les appareils electromnagers dune cuisine. Ils peuvent tre contenus dans lensemble des valeurs suivantes : rfrigrateur, cuisinire, hotte, robot, lave-vaisselle. On considre par ailleurs un ensemble de couleurs qui peuvent tre contenues dans lensemble des valeurs suivantes : rouge, bleu, vert, jaune, blanc, noir, rose, jaune. Les combinaisons possibles entre les appareils et les couleurs sont au nombre de 40, puisquil y a 5 appareils que lon peut associer 8 couleurs. Parmi toutes ces combinaisons possibles, on effectue une slection qui reprsente par exemple la description dune (horrible) cuisine dans le monde rel. Ces couples de valeurs choisis reprsentent les faits de la vie relle.
(rfrigrateur, rouge) (robot,mauve) (cuisinire,jaune) (lave-vaisselle,rouge)

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

Cration de bases de donnes

Chapitre Figure 3.1


Table ma_cuisine.

Appareil Rfrigrateur Robot Cuisinire Lave-vaisselle

Couleur Rouge Mauve Jaune Rouge

1.2 NOTION DE CL DUNE RELATION ET DPENDANCE FONCTIONNELLE


Lorsque que lon utilise une base de donnes, il est ncessaire daccder un enregistrement par le contenu dun ou de plusieurs champs. On nomme cl dune relation un champ, ou un ensemble de champs, dune relation qui permet didentifier prcisment un enregistrement. Une relation peut comprendre plusieurs cls possibles ; ce sont les cls candidates. La cl choisie doit tre minimale, cest--dire quelle doit contenir le minimum de champs. Cette cl minimale ainsi dfinie est appele la cl primaire de la relation. Une cl doit toujours contenir une valeur et celle-ci doit tre unique pour chacun des enregistrements de la relation. La cl ne peut tre dduite simplement partir du contenu de la relation ; on ne peut prjuger du contenu futur des enregistrements. Si lon prend la relation ma_cuisine vue prcdemment, le champ Appareil semble tre une cl puisquil contient une valeur unique pour chacun des enregistrements. Cependant, il est tout fait possible que la cuisine considre comprenne un autre rfrigrateur de couleur bleue, auquel cas la valeur ne serait plus unique et ne permettrait pas de retrouver lenregistrement. Dans ce cas de figure, la combinaison Appareil Couleur pourrait sembler tre une cl, mais on ne peut en tre certain compte tenu de lvolution des donnes. Pour dsigner une cl primaire, il faut donc galement prendre en compte le sens des donnes dans la vie relle. Les relations qui existent entre les diffrents champs dune relation vont tre importantes : on exprime ces relations laide de dpendances fonctionnelles. Une dpendance fonctionnelle existe entre deux ensembles de champs si les valeurs contenues dans lun des ensembles de champs permettent de dterminer les valeurs contenues dans lautre ensemble. Cette proprit se traduit en termes mathmatiques de la manire suivante :
Soit Cx un ensemble de champs (x1,x2,x3) et Cy un ensemble de champs (y1,y2,y3) dune relation R(d1,d2,x1,x2,x3,u1,u2,u3,y1,y2,y3). Supposons que lon considre des valeurs (x1_i, x2_i, x3_i) et (x1_j, x2_j, x3_j) telles que lon ait R(d1_i,d2_i,x1_i,x2_i,x3_i,u1_i,u2_i,u3_i,y1_i,y2_i,y3_i) et R(d1_j,d2_j,x1_j,x2_j,x3_j,u1_j,u2_j,u3_j,y1_j,y2_j,y3_j). On dit que Cy dpend fonctionnellement de Cx lorsque pour tout i et j si (x1_i, x2_i, x3_i) est gal (x1_j, x2_j, x3_j) alors (y1_i,y2_i,y3_i) est gal (y1_j,y2_j,y3_j).

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

Cration de bases de donnes

Chapitre

1.3 COHRENCE DES DONNES ET CONTRAINTES DINTGRIT


Afin de garantir la cohrence des donnes pour lensemble des relations constitutives de la base de donnes, on applique des restrictions sur le contenu des donnes que lon nomme contraintes dintgrit. La vrification de la cohrence se situe plusieurs niveaux : adapter le contenu des champs par rapport au sens des donnes dans le monde rel ; prserver la cohrence du contenu de lensemble des relations qui sont lies ; liminer les problmes dincohrence dus la redondance : en effet la duplication des donnes rend dlicates la maintenance et lvolution de la relation.

Adapter le contenu des donnes


La cohrence par rapport au sens des donnes est lie la notion de domaine de valeurs du champ dj aborde : on parle de contrainte de domaine ou cohrence smantique. Par exemple, lge dune personne ne peut tre ngatif ou excder 120. On a prcdemment dfini une contrainte dintgrit sur lensemble des champs qui constituent une cl primaire : une cl ne peut contenir de valeur nulles et ses valeurs doivent tre uniques. On procde la dfinition des contraintes lors de ltape danalyse du monde rel. Leur mise en uvre effective interviendra au moment de la cration de la relation et sera ralise par le SGBD.

Prserver la cohrence des donnes


On rappelle quune base de donnes est constitue par un ensemble de relations relies entre elles. Les contenus des champs capables de lier ces relations doivent tre cohrents entre eux pour pouvoir effectuer lopration de jointure. Si lon considre lexemple de la base de donnes exemple casse, on ne doit pas permettre la saisie dune valeur identifiant une voiture dans la relation vente qui nexiste pas dans la relation voiture. On fait dans ce cas rfrence au contenu dune colonne dune autre relation, le champ NumVoit de la relation voiture, pour contrler le contenu du champ NumVoit de la relation vente. Le champ NumVoit est alors une cl trangre qui permet de raliser la notion dintgrit rfrentielle. De mme que prcdemment, on dtermine ces rfrences lors de la phase danalyse du monde rel et le SGBD permet de les raliser. On prfre appliquer en gnral ces contraintes non pas lors de la cration des relations, mais plutt lorsque les donnes ont dj t insres, en particulier dans les relations de rfrences. Cette prcaution vite les problmes de rfrences impossibles rsoudre entre les relations, ce qui provoque parfois lincapacit insrer des donnes.

liminer la redondance des donnes


Les incohrences provoques par la redondance dinformation reprsentent le principal souci du concepteur dune base de donnes. En effet, lorsque les donnes sont dupliques, aucun mcanisme ne peut garantir que le changement de la valeur dune donne est rpercut correctement sur les autres donnes. Dans lexemple ci-dessus (voir figure 3.2) dune relation des lecteurs de bibliothque, on remarque la redondance dinformation qui existe entre les champs Ville et Etablissement. Si le nom de ltablissement INPL change, il faut mettre jour toutes les lignes qui contiennent son nom. La redondance est mise en vidence par la dpendance fonctionnelle qui existe entre ces deux champs. Dans cet exemple, dtecter la redondance est vident. Cependant, il sagit gnralement dincohrences dlicates dceler lorsque le nombre de relations est lev ou encore si le sujet modlis par la base de donnes nest pas familier. Les incohrences de ce type seront rsolues par la rorganisation des relations lors de la phase de normalisation.

Approche relationnelle 59

Oprations du modle relationnel


La manipulation des donnes dans le modle relationnel se fait laide doprations formelles reposant sur des concepts mathmatiques issus de la thorie des ensembles : cest lalgbre relationnelle. Les oprations de lalgbre relationnelle portent sur une ou plusieurs relations (ou tables). Le rsultat retourn par ces oprations est toujours une relation (ou table). Cette section prsente une liste non exhaustive des diffrentes oprations de lalgbre relationnelle. Ces dernires peuvent tre regroupes en plusieurs catgories : les oprations classiques issues de la thorie des ensembles (union, intersection, diffrence) ; les oprations plus spcifiques du monde relationnel (projection, slection, jointure) qui constituent les oprations fondamentales de lalgbre relationnelle ; les oprations de types calcul et agrgats qui ne constituent pas rellement des oprations fondamentales (ni ensemblistes, ni relationnelles) mais qui sont le complment indispensable des prcdentes.

2.1 OPRATIONS ENSEMBLISTES


Lalgbre relationnelle emprunte un certain nombre de concepts la thorie des ensembles. lexception du produit cartsien, ces oprations ont la particularit de ne pouvoir sutiliser que pour des relations qui ont exactement la mme structure ou des structures compatibles. Elles sont toutes de type binaire, car elles sappliquent deux relations.

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.

Lecteur_1(Numero_carte, Nom, Age, Ville, Etablissement)


Numero_carte 1 2 3 Nom Henri Stanislas Henriette Age 10 34 44 Ville Paris Paris Lyon Etablissement Universit Sorbonne Universit Jussieu CHU Bron

Lecteur_2(Numero_carte, Nom, Age, Ville, Etablissement)


Numero_carte 3 4 5 Nom Henriette Dominique Isabelle Age 44 19 56 Ville Lyon Nancy Nancy Etablissement CHU Bron Universit Poincar INPL

60

Cration de bases de donnes

Chapitre Figure 3.4


Union des relations Lecteur_1 et Lecteur_2.

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.

Appareil rfrigrateur rfrigrateur robot robot cuisinire cuisinire

Couleur rouge rouge mauve mauve jaune jaune

Nom Jaco Pastorius Bill Evans Jaco Pastorius Bill Evans Jaco Pastorius Bill Evans

Instrument Basse lectrique Piano Basse lectrique Piano Basse lectrique Piano

2.2 OPRATIONS RELATIONNELLES


Projection
La projection consiste extraire certains champs de la relation, ce qui donne cette dernire un degr infrieur la relation de dpart. Voici la relation obtenue partir de la relation Lecteur en projetant les champs Nom et Ville (voir figure 3.9). Figure 3.9
Projection des champs Nom et Ville de la relation Lecteur.

Lecteur_proj(Nom, Ville)
Nom Henri Stanislas Ville Paris Paris

62

Cration de bases de donnes

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.

Lecteur_sel(Numero_carte, Nom, Age, Ville, Etablissement)


Numero_carte 6 11 Nom Olivier Antoine Age 51 16 Ville Marseille Marseille Etablissement Universit Saint Charles Universit Saint Charles

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.

Lecteur_bis(Numero_carte, Nom, Num_Etablissement)


Numero_carte 1 2 3 Nom Henri Stanislas Henriette Num_Etablissement 1 2 1

Etablissement(Num Etablissement, Ville, Nom_Etablissement)


Num_Etablissement 1 2 3 4 Ville Paris Lyon Nancy Paris Nom_Etablissement Universit Jussieu CHU Bron Universit Poincar Universit Sorbonne

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.

Lecteur_joint_Etablissement(Numero_carte, Nom, Num_Etablissement_1, Num_Etablissement_2, Ville, Nom_Etablissement)


Numero _carte 1 2 3 Nom Henri Stanislas Henriette Num_Etablissement_1 1 2 1 Num_Etablissement_2 1 2 1 Ville Paris Lyon Paris Nom _Etablissement Universit Jussieu CHU Bron Universit Jussieu

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.

Lecteur_jointnat_Etablissement(Numero carte, Nom, Num_Etablissement, Ville, Nom_Etablissement)


Numero_carte 1 2 3 Nom Henri Stanislas Henriette Num _Etablissement 1 2 1 Ville Paris Lyon Paris Nom _Etablissement Universit Jussieu CHU Bron Universit Jussieu

64

Cration de bases de donnes

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.

Produit_cartesien_Etablissement(Numero_carte, Nom, Num_Etablissement_1, Num_Etablissement_2, Ville, Nom_Etablissement)


Numero _carte 1 1 1 1 2 2 2 2 3 3 3 3 Nom Henri Henri Henri Henri Stanislas Stanislas Stanislas Stanislas Henriette Henriette Henriette Henriette Num_Etablissement_1 1 1 1 1 2 2 2 2 1 1 1 1 Num _Etablissement 1 2 3 4 1 2 3 4 1 2 3 4 Ville Paris Lyon Nancy Paris Paris Lyon Nancy Paris Paris Lyon Nancy Paris Num_Etablissement_2 Universit Jussieu CHU Bron Universit Poincar Universit Sorbonne Universit Jussieu CHU Bron Universit Poincar Universit Sorbonne Universit Jussieu CHU Bron Universit Poincar Universit Sorbonne

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

Etablissement_jointext_ Lecteur(Num_Etablissement_1, Ville, Nom_Etablissement, Numero_carte, Nom, Num_Etablissement_2) Jointure externe


des relations Lecteur_bis et tablissement sur le champ Num _Etablissement.

Num_Etablissement_1 1 2 3 4

Ville Paris Lyon Nancy Paris

Nom _Etablissement Universit Jussieu CHU Bron Universit Poincar Universit Sorbonne

Numero _carte 1 2 NULL NULL

Nom Henri Stanislas NULL NULL

Num_Etablissement_2 1 2 NULL NULL

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.

2.3 CALCULS ET AGRGATS


Une rgle dans le domaine des bases de donnes est que tout ce qui peut se calculer ne doit pas tre stock. On vite ainsi la perte de place et lincohrence qui peut en dcouler suite au stockage dinformations redondantes. Les oprations de lalgbre relationnelle prsentes dans les sections prcdentes ne permettent pas de crer de nouveau champ par calcul partir du contenu dautres champs sans utiliser un langage de programmation. Des

66

Cration de bases de donnes

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.

La_boutique(Num_Facture, Article, Prix, Quantite)


Num_Facture 101 1034 2345 0987 Article Bananes Choux Riz Gazelle Prix 12 5 4 15 Quantite 45 129 60 48

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.

La_boutique_total(Num_FactureArticle, Prix, Quantite, Total)


Num_Facture 101 1034 2345 0987 Article Bananes Choux Riz Gazelle Prix 12 5 4 15 Quantite 45 129 60 48 Total 540 645 240 720

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

Ville Marseille Nancy Paris

Nombre 2 3 5

Passage du modle conceptuel au relationnel


On a expos au chapitre sur lanalyse du monde rel deux formalismes diffrents entitassociation et UML pour reprsenter le modle conceptuel obtenu. Il existe des rgles simples pour passer de ces modles un ensemble de relations qui sera utilisable directement dans le SGBD. Cet ensemble de relations sappelle le schma relationnel et constitue le modle logique des donnes. On prsente dans cette section les rgles de transition qui permettent dexprimer le schma relationnel partir du modle conceptuel des donnes. Pour illustrer ces rgles, on utilise la terminologie du modle entit-association, mais leur expression est aisment adaptable au formalisme UML.

3.1 RGLES GNRALES


Deux grandes rgles gnrales sappliquent toujours, quel que soit le cas. Les exceptions que lon aborde ensuite permettent simplement dobtenir un schma plus compact : Une entit devient une relation compose des champs de lentit. La cl de cette relation est la mme que celle de lentit. Une association devient une relation compose des deux cls des entits associes. Lensemble de ces deux cls constitue celle de la relation. Lorsquelle en possde, les champs de lassociation forment les champs non cls de cette nouvelle relation.
Client
NumAch Nom Age Ville Sexe

Figure 3.21

Modle entitassociation de la base de donnes casse.

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

Cration de bases de donnes

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.

4.1 PREMIRE FORME NORMALE


La premire forme normale sintresse au contenu des champs. Elle interdit la prsence, appele multivaluation, de plusieurs valeurs dans un mme champ dune relation. En effet, la notion de dpendance fonctionnelle entre les champs ne peut plus tre vrifie sils possdent plusieurs valeurs. Elle sexprime de la manire suivante : Tout champ contient une valeur atomique.

Comment passer en premire forme normale ?


La relation suivante nest pas en premire forme normale ; le champ Auteurs contient plusieurs valeurs (voir figure 3.23).

70

Cration de bases de donnes

Chapitre Figure 3.23


Relation Publication avec un champ multivalu.

Publication(NumPubli, Titre, Auteurs)


NumPubli 13490 21322 45333 Titre Le vin et lavenir Bire et progrs social Le champagne et la France Auteurs Jean Lasso, Hubert De la Tuque, Stanislas Wilski Aristide Salem, Jean Lasso, Salome Dupont Penelope Light, Vanessa Martinez, Salome Dupont

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

Auteur(NumAuteur, Nom, Prenom)


NumAuteur 1 2 3 4 5 6 7 Nom Lasso De la Tuque Wilski Salem Dupont Light Martinez Prenom Jean Hubert Stanislas Aristide Salome Penelope Vanessa

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.

4.2 DEUXIME FORME NORMALE


Bien videmment, une relation doit dj se trouver en premire forme normale pour tre en deuxime forme normale. Cette dernire recherche la redondance dinformation dans une relation. Elle interdit les dpendances fonctionnelles possibles entre les champs qui composent la cl et les autres champs. On peut lexprimer de la manire suivante : La relation est en premire forme normale. Tout champ qui nappartient pas la cl ne dpend pas dune partie de la cl.

Comment passer en deuxime forme normale ?


La solution consiste dcomposer la relation en deux relations. La nouvelle relation cre a pour cl la partie de la cl dont dpendent les autres champs qui constituent ses champs. On considre la relation Produit suivante (voir figure 3.25). Figure 3.25
Relation Produit.

Produit(Article, Fournisseur, Adresse, Prix)


Article Marteau Tournevis Tournevis Pince Mtre Fournisseur SOGENO ARTIFACT SOGENO LEMEL ARTIFACT Adresse Paris Lille Paris Paris Lille Prix 5 10 23 34 24

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

Cration de bases de donnes

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.

Produit(Article, Fournisseur, Prix)


Article Marteau Tournevis Tournevis Pince Mtre Fournisseur SOGENO ARTIFACT SOGENO LEMEL ARTIFACT Prix 5 10 23 34 24

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.

4.3 TROISIME FORME NORMALE


La troisime forme normale recherche galement la redondance dinformation dans une relation. On cherche sil existe une dpendance entre deux champs qui ne font pas partie dune cl. Si cest le cas, on se trouve dans la situation o un champ dpend dun autre champ qui dpend lui mme dune cl. La cl considre peut tre primaire ou secondaire. La troisime forme normale interdit donc les dpendances fonctionnelles dites transitives entre les champs. Elle sexprime de la manire suivante : La relation est en deuxime forme normale (donc en premire forme normale). Tout champ nappartenant pas une cl ne dpend pas dun autre champ non cl.

Comment passer en troisime forme normale ?


La solution est galement de dcomposer la relation de dpart en deux relations. La nouvelle relation cre a pour cl le champ dont dpendent les autres champs qui constituent ainsi la dpendance transitive. On considre la relation suivante (voir figure 3.27).

Approche relationnelle 73

Figure 3.27
Relation Baladeur.

Baladeur(NumBal, Marque, Type, Couleur)


NumBal 12 43 23 29 34 Marque Apple Creative Apple Creative Sony Type Ipod Zen Ipod Zen MZ-RH910 Couleur Blanc Noir Noir Gris Rouge

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(NumBal, Type, Couleur)


NumBal 12 43 23 29 34 Type Ipod Zen Ipod Zen MZ-RH910 Couleur Blanc Noir Noir Gris Rouge

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

Cration de bases de donnes

Chapitre

4.4 FORME NORMALE DE BOYCE-CODD


La forme normale de Boyce-Codd traite un cas un peu diffrent de ceux de la deuxime et troisime forme normale. Il sagit du cas o une partie dune cl dpend dun champ. Comme pour la troisime forme normale, la cl considre peut tre une cl primaire ou secondaire. Une relation en troisime forme normale nest pas toujours en forme BoyceCodd , mais linverse est toujours vrai. Tout champ appartenant une cl ne dpend pas dun autre champ non cl.

Comment passer en forme normale de Boyce-Codd ?


Lors de la dcomposition de la relation en deux relations, plusieurs choix sont envisageables compte tenu des liens de dpendances multiples entre les diffrents champs. On choisit la dcomposition qui permet de reconstituer strictement linformation dorigine sans gnrer de donnes supplmentaires. La perte dune dpendance fonctionnelle est frquente lors de cette opration. La relation cre a pour cl la partie de celle-ci dont dpendent les autres champs constituant la dpendance. On considre la relation suivante (voir figure 3.29). Figure 3.29
Relation Dictaphone.

Dictaphone(Marque, Produit, Prix, Couleur)


Marque Philips Olympus Philips ImaginR Olympus Produit LD 1024 VN 1664 LD 5647 H VN 1664 VN 234 PC Prix 49 49 59 69 79 Couleur Blanc Noir Blanc Gris Rouge

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.

Dictaphone(Produit, Prix, Couleur)


Produit LD 1024 VN 1664 LD 5647 H Prix 49 49 59 Couleur Blanc Noir Blanc

Approche relationnelle 75

Produit VN 1664 VN 234 PC

Prix 69 79

Couleur Gris Rouge

Marque_coul(Couleur, Marque)
Couleur Blanc Noir Gris Rouge Marque Philips Olympus ImaginR Olympus

On a perdu la dpendance de Couleur par rapport Marque, Produit.

Logique du premier ordre et base de donnes


Dans cette section, le fondement logique de lapproche relationnelle est brivement abord pour prsenter une mthode dinterrogation : les QBE (Query By Example). La logique du premier ordre a pour but de formaliser le raisonnement naturel en considrant la dduction comme le rsultat dun calcul. Elle a fait lobjet de recherches intenses depuis lAntiquit : Aristote, Frege et Gdel pour nen citer que quelques-uns sont parmi les plus prestigieux stre penchs sur la question. Les principes de la logique du premier ordre, dans une version restreinte que lon appelle le calcul des propositions, ont trouv de nombreuses applications en informatique. Aprs quelques rappels sur le formalisme de la logique, on aborde ses liens avec lapproche relationnelle en base de donnes et lon prsente la mthode dinterrogation par QBE.

5.1 RAPPELS SUR LA LOGIQUE DU PREMIER ORDRE


Le formalisme de la logique du premier ordre permet dexprimer des phrases dans un langage non ambigu. Il offre la possibilit, par des rgles de drivation, ou rcritures, de dduire dautres phrases. Llment fondamental de la logique du premier ordre est le prdicat qui exprime le lien entre diffrents lments. La validit de ce prdicat est gnralement restreinte un ensemble de valeurs que lon nomme domaine du discours.
mange(x,y) sera par exemple vrai pour les valeurs du couple (x,y) suivantes (homme,navet) (lapin,carotte) (homme,lapin).

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

Cration de bases de donnes

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)

x y signifie que y est dfini en fonction de x, on remplace y par F(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.

5.2 LIEN AVEC LES BASES DE DONNES


Le lien avec ce qui a t nonc prcdemment sur le modle de bases de donnes relationnelles est le suivant : Le prdicat correspond la relation. Le domaine du discours correspond au contenu de la relation. Ce formalisme permet dexprimer les questions, naturellement ambigus du langage parl, par une formule. Cette formule est rcrite en utilisant les rgles vues prcdemment pour arriver un ensemble de clauses simples. On constitue ensuite des sous-ensembles de tuples de la relation pour lesquels les clauses rcrites sont vrifies : ces tuples reprsentent la rponse la question pose. Voici quelques exemples de questions exprimes en utilisant ce formalisme. On obtient ainsi des sortes de patrons de recherche permettant de caractriser les tuples qui sont solutions. Dans lexemple gnral (voir section 3.1), le schma de la relation voiture est voiture(NumVoit, Marque, Type, Couleur) et le schma de la relation vente est vente(DateVent, Prix, NumAch, NumVoit). Lexpression afficher la liste des marques et des types de voitures , ou projection des champs Marques et Types de la relation voiture, peut scrire sous la forme :
{ (m,t) | voiture(_,m,t,_) }

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.

5.3 INTERROGATION PAR QBE (QUERY BY EXAMPLE)


Lors de la phase de dveloppement du prototype de SGBD bas sur lapproche relationnelle dans les laboratoires dIBM, un premier sous-produit a t conu : le langage dinterrogation SEQUEL, puis SQL. Une autre mthode dinterrogation a t dveloppe cette occasion : les QBE (Query By Example). Lide est de disposer dun mode dinterrogation dune base de donnes sans connatre de langage et en utilisant le formalisme vu la section prcdente, prsent sous une forme graphique. Comme son nom lindique, on va utiliser des exemples pour dfinir les questions. La relation est reprsente sous la forme dun tableau : La projection dun champ se fait en cochant la case correspondant au nom de la colonne (voir figure 3.31). Figure 3.31
Projection du champ Marque dans un QBE.

Afficher la liste des marques et des types de voitures :


{ (m,t) | voiture(_,m,t,_) }

NumVoit

Marque

Type

Couleur

Les critres de slection se font par des valeurs exemples (voir figures 3.32 et 3.33).

78

Cration de bases de donnes

Chapitre Figure 3.32


Slection sur un contenu et projection dans un QBE.

Afficher le type des voitures de couleur rouge :


{ (t) | voiture(_,_,t,rouge) }

NumVoit

Marque

Type

Couleur Rouge

Figure 3.33
Slection sur un critre et projection dans un QBE.

Afficher les prix de vente suprieurs 10 000 :


{ (p) | vente(_,p,_,_) p > 10000 }

DateVent

Prix > 10 000

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)}

DateVent > 01/01/1997

Prix > 10 000

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)}

DateVent > 01/01/1997

Prix > 10 000

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

Cration de bases de donnes

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

Type Couleur Noir/Blanc Couleur Noir/Blanc Noir/Blanc

Nombre 3 1 1664 890 1

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

Cration de bases de donnes

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

ma_cuisine (ma_cuisine - sa_cuisine)


Appareil Cuisinire Couleur jaune

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

Cration de bases de donnes

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

Type Couleur Noir/Blanc Couleur Noir/Blanc Noir/Blanc

Nombre 3 1 1664 890 1

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.

Film(Prix, Format, Type, Nombre, Numero_Film)


Prix 12 4 12 35 12 Format 4/3 16/9 16/9 4/3 16/9 Type Couleur Noir/Blanc Couleur Noir/Blanc Noir/Blanc Nombre 3 1 1 664 890 1 Numero_Film 2 4 12 12

Approche relationnelle 85

Exercices

50

Catalogue(Numero_Film, Titre) Figure 3.44


Relation Catalogue.

Numero_Film 2 4 56 111 12

Titre

Le train qui passe


A toi ! Les chats du Sngal Le temps expliqu

Les impts faciles

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

Numero _Film (Films) 2 4 12 12

Numero _Film (Catalogue) 2 4 12 12

Titre

12 4 35 12

4 :3 16 :9 4 :3 16 :9

Couleur Noir/Blanc Noir/Blanc Noir/Blanc

3 1 890 1

Le train qui passe


A toi ! Les impts faciles Les impts faciles

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

Cration de bases de donnes

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

Numero _Film (Films) 2 4 50 12

Numero _Film (Catalogue) 12 4 12 12

Titre

12 4 12 12

4 :3 16 :9 16 :9 16 :9

Couleur Noir/ Blanc Couleur Noir/ Blanc

3 1 1664 1

Les impts faciles


A toi ! Les impts faciles Les impts faciles

Cette opration na aucune signification dans la ralit.

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

Numero _Film (Films) 2 4 50 12 12

Numero _Film (Catalogue) 2 4 NULL 12 12

Titre

12 4 12 35 12

4 :3 16 :9 16 :9 4 :3 16 :9

Couleur Noir/ Blanc Couleur Noir/ Blanc Noir/ Blanc

3 1 1664 890 1

Le train qui passe


A toi ! NULL Les impts faciles

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

Les impts faciles

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

Couleur Noir/ Blanc NUL NUL Noir/ Blanc

3 1 NUL NUL 890

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

Les chats du Sngal Le temps expliqu


Cet exercice permet de mettre en vidence lasymtrie de lopration de jointure externe et son rle indispensable pour rpondre des questions de ce type. Cest pour cette raison quelle a t introduite dans le langage SQL dans un second temps, mme si elle nen faisait pas partie lorigine.

EXERCICE 9

CALCUL SUR DES AGRGATS


Quelle est la moyenne des prix pour les films par format ? On va commencer par une opration qui consiste constituer autant de sous-relations que lon trouve de valeurs diffrentes dans le champ Format de la relation Film . Ici, il y a deux

88

Cration de bases de donnes

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.

Prix 29,5 9,3333

Format 4 :3 16 :9

EXERCICE 10

PASSAGE DU MODLE ENTIT-ASSOCIATION AU RELATIONNEL


partir du modle entit-association modlisant une location de DVD, effectuez le passage au modle relationnel (voir figure 3.53).

Figure 3.53
Modle entitassociation de la location de DVD.
Location 0,n
NbeJourLoc DateLoc

Client # NumClient NomClient PrenomClient AdresseClient TeleClient Compte

0,n 0,n Reservation


NbeJourRes DateRes

Film
# NumFilm Titre Genre Prix NbDVD

0,n 1,n 1,1

Joue Personnel 0,n


# NumPers NomPers PrenomPers

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

PASSAGE DU MODLE ENTIT-ASSOCIATION AU RELATIONNEL

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

Cration de bases de donnes

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.

Nom Andr Dupont Stanislas De la Motte Elisabeth Macroix

Adresse_mail adup@philips.com, andre@dupond.fr sdlm@versailles.mairie.fr elsa@yago.to, mac@rien.fr

Poste Directeur Employ, asserment Assistante

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

Nom Andr Dupont Stanislas De la Motte Elisabeth Macroix

Poste Directeur Employ, asserment Assistante

Adresse_mail1 adup@philips.com sdlm@versailles.mairie.fr elsa@yago.to

Adresse_mail2 andre@dupond.fr sdlm@versailles.mairie.fr mac@rien.fr

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

Type Couleur Noir/Blanc Couleur Noir/Blanc Noir/Blanc Noir/Blanc

Nombre 3 1 1664 890 1 3

Numro_Film 2 4 56 12 12 111

Support VHS DVD DVD VHS DVD VHS

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

Type Couleur Noir/Blanc Couleur Noir/Blanc Noir/Blanc

Nombre 3 1 1664 890 1

Numero Film 2 4 50 12 12

FormatSup(Format, Support)
Format 4 :3 16 :9 Inconnu Support VHS DVD VHS

92

Cration de bases de donnes

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.

Lecteur(Numero_carte, Nom, Age, Etablissement)


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 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

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

Cration de bases de donnes

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

Concepts du langage SQL


Le langage SQL est essentiellement un sous-produit issu des travaux du groupe de travail System-R. Il sagissait de la ralisation pratique des concepts de lapproche relationnelle chez IBM. Cest une volution du langage SEQUEL, lui-mme driv du langage de recherche SQUARE. Le langage est normalis par lISO depuis 1987. La deuxime version du langage, SQL2, a t adopte en 1992. Les exemples de cet ouvrage sont bass, dans la mesure du possible, sur cette norme. La troisime version du langage, SQL3, normalise en 1999, ajoute essentiellement les fonctionnalits lies lutilisation de lapproche objet. La quasi-totalit des SGBD disposent dune interface SQL mme si aucun ne couvre lensemble de la norme. La norme SQL prvoit trois niveaux de conformit : le niveau dentre, le niveau intermdiaire et le niveau complet. Les SGBD respectent en gnral le premier niveau et adoptent certains lments des autres niveaux. La normalisation du langage garantit la portabilit gnrale des applications dun SGBD un autre, mme sil subsiste des diffrences entre les approches des diffrents diteurs. En effet, compte tenu du temps ncessaire au processus de modification de la norme, certains diteurs la devancent parfois et intgrent des fonctionnalits qui leur semblent essentielles ou susceptibles de leur donner un avantage concurrentiel. Le langage SQL manipule lobjet fondamental de lapproche relationnelle : la relation reprsente par une table vue au chapitre 3. SQL est un langage dit non procdural ou dclaratif , cest--dire que lon ne dcrit pas la manire deffectuer les oprations pas pas : cest le SGBD qui choisit la mthode utilise pour y parvenir. Cest ce qui explique que des concours de rapidit de rsolution de requte soient organiss chaque anne pour tester les diffrentes stratgies des diteurs. Par consquent, il ne dispose pas dinstructions de structuration, telles que des boucles. Pour effectuer ce type doprations, on utilise un langage de programmation classique , comme les langages C, php, Java et bien dautres. Les instructions SQL sont alors intgres dans le langage via une interface spcifique. Les rsultats de la requte SQL sont alors stocks dans des structures de donnes propres au langage employ (par exemple un tableau) afin de pouvoir les manipuler. Cest typiquement ce procd qui est employ pour construire une interface daccs une base de donnes par le Web. Le langage de programmation qui intgre le langage SQL est alors appel langage hte (voir figure 4.1). De petites diffrences de syntaxe peuvent apparatre entre une requte SQL exprime interactivement et la version intgre dans un langage de programmation. Enfin, il existe une extension procdurale de SQL qui ajoute les fonctions, procdures et mthodes SQL mais qui ne sera pas traite dans le cadre de cet ouvrage.

Remarque
Un ensemble dinstructions SQL se nomme une requte. Une requte SQL se termine toujours par le caractre ; .

96

Cration de bases de donnes

Chapitre Figure 4.1


Interface entre SQL et les langages de programmation.

Programme en langage hte


+ code SQL

Bibliothque fonctions SQL

SGBD

1.1 ORGANISATION DU CHAPITRE


Linterrogation dune ou de plusieurs tables est aborde dans la section Oprations relationnelles avec SQL . Toutes les requtes de ce type retournent comme rsultat une table qui peut tre sauvegarde sous forme de table temporaire. Cette table intermdiaire est utilise pour effectuer dautres requtes. La cration, la modification et la destruction dune table sont abordes dans la section Gestion de tables et de vues . Lexpression des contrles de cohrence (contraintes dintgrit) que lon souhaite appliquer une table est traite logiquement dans cette section. La manipulation (insertion, modification et suppression) des donnes dune table est aborde dans la section Gestion des donnes . La partie de SQL qui est consacre la gestion des autorisations sera aborde plus loin au chapitre 6. Cet ouvrage ne traite pas de lintgralit de la norme SQL ; ce nest pas son objectif. Pour en savoir plus, vous pouvez vous reporter louvrage dit dans la mme collection (F. Brouard et C. Soutou, Syntex SQL).

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.

Oprations relationnelles avec SQL


Cette section prsente lexpression en SQL des oprations de lalgbre relationnelle vues prcdemment : projection, slection, agrgats, produits cartsiens et jointures. Une description prcise de ces oprations se trouve au chapitre 3. Les exemples simples qui prsentent les oprations relationnelles utilisent la base de donnes casse (voir figure 4.2).

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

2.1 PROJECTION (SELECT)


Lopration de projection consiste slectionner la (les) colonne(s) que lon veut voir figurer dans la table rsultat . On spcifie la liste des colonnes inclure dans cette table derrire linstruction SELECT en les sparant par des virgules. Si lon dsire afficher toutes les colonnes, on les dsigne par le caractre * .
Projection sur les colonnes Nom et Ville de la table Personne.
SELECT Nom, Ville FROM personne ;

Nom Nestor Irma Henri Josette Jacques

Ville Paris Lille Paris Lyon Bordeaux

98

Cration de bases de donnes

Chapitre
Projection sur tous les champs de la table Personne.
SELECT * FROM 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

Les colonnes de la table rsultat peuvent tre renommes par le mot cl AS.
SELECT Ville AS City FROM personne ;

City Paris Lille Paris Lyon Bordeaux

Valeurs distinctes dune colonne


Une colonne Salutations ne devrait contenir que les valeurs normalises Madame , Monsieur , Mademoiselle . Laffichage des valeurs distinctes permet de lister les diffrentes valeurs prises par la colonne pour reprer dventuelles incohrences comme la prsence dune valeur Mr. , M. , etc. Afin dliminer les doublons ventuels des valeurs dune colonne de la table rsultat , on fait prcder le nom de la colonne par le mot cl DISTINCT.
Projection sur les valeurs distinctes du champ Marque de la table voiture.
SELECT DISTINCT Marque FROM voiture ;

Marque Peugeot Citroen Opel Renault

Utilisation dexpressions pour crer une colonne


On rappelle quun grand principe en base de donnes est que lon ne stocke pas dans une table ce qui peut tre calcul. On vite ainsi loccupation de place inutile ainsi que les problmes dincohrence provoqus par la mise jour des donnes. Par exemple, si lon dispose dune colonne prix et dune colonne quantit, on ne stocke pas la colonne chiffre daffaire on calcule ses valeurs partir des colonnes prcdentes (chiffre daffaires = prix quantit). Cette manire de procder sera plus coteuse en

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.

+ * / %

Addition Soustraction Multiplication Division Modulo

Cration dune colonne Prix_Euros dans la table vente contenant le prix de vente en euros.

SELECT Prix, DateVente, (Prix / 6.5596) AS Prix_Euros FROM vente ;

Prix 10 000 70 000 30 000 45 000

DateVente 1985-12-03 1996-03-30 1998-06-14 2000-04-02

Prix_Euros 1 524.483 200 10 671.382 401 4 573.449 601 6 860.174 401

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 ;

NomMajuscule NESTOR IRMA HENRI JOSETTE JACQUES

Extraction du mois de la colonne 'DateVente' de la table 'Vente'.

SELECT MONTH(DateVente) AS Mois FROM vente ;

Mois 12 3 6 4

Utilisation de fonctions statistiques sur toutes les valeurs dune table


SQL ne possde pas dinstruction de structuration et ne permet donc pas de raliser des boucles. Il possde des fonctions simples de traitement des donnes dune colonne ; les calculs plus complexes seront raliss laide dun langage de programmation comme on

100

Cration de bases de donnes

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.

COUNT MAX MIN AVG SUM

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

Calcul du nombre de personnes (le nombre de lignes en ralit) de la table personne.

SELECT COUNT(*) AS Nombre_Personne FROM personne ;

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.

2.2 SLECTION OU RESTRICTION (WHERE)


Lopration de slection (ou restriction) consiste indiquer un ou plusieurs critres pour choisir les lignes inclure dans la table rsultat . Ces critres utilisent videmment le contenu des valeurs des colonnes. Le critre de slection est indiqu la suite du mot cl WHERE. Il est constitu dexpressions de conditions composes laide doprateurs de comparaison et combines laide de connecteurs logiques. Voici la liste des oprateurs de comparaison classiques permettant de constituer les expressions en SQL (voir tableau 4.3), la liste des oprateurs de comparaison spcifiques SQL (voir tableau 4.4), et la liste des oprateurs et connecteurs logiques (voir tableau 4.5). Tableau 4.3
Oprateurs de comparaison de SQL.

= <> <

gal Diffrent Infrieur

SQL 101

> <= >=


Extraction des enregistrements de la table vente dont le prix est suprieur 50 000.
SELECT * FROM vente WHERE Prix > 50 000 ;

Suprieur Infrieur ou gal Suprieur ou gal

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.

BETWEEN <valeur> AND <valeur> IN <liste de valeurs> IS NULL LIKE


SELECT * FROM voiture WHERE Couleur IN ("Blanc","Rouge") ;

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

Nom Henri Jacques

Age 45 50

Ville Paris Bordeaux

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

SELECT * FROM voiture WHERE Couleur="Blanche" OR Marque="Peugeot" ;

NumVoit 1 3 4

Marque Peugeot Opel Peugeot

Type 404 GT 403

Couleur Rouge Blanche Blanche

102

Cration de bases de donnes

Chapitre
Extraction des personnes nhabitant pas Paris.
SELECT * FROM personne WHERE NOT (Ville=Paris);

NumAch 2 4 5

Nom Irma Josette Jacques

Age 20 34 50

Ville Lille Lyon Bordeaux

Sexe F F M

2.3 AGRGATS OU GROUPAGE (GROUP BY)


Les oprations d agrgation ou de groupage regroupent les lignes dune table par valeurs contenues dans une colonne. On applique gnralement des oprations de type statistique sur les sous-tables ainsi cres. Pour raliser cette opration avec SQL, on utilise le mot cl GROUP BY suivi du nom de la colonne sur laquelle seffectue lagrgat.
Affichage des diffrentes marques de voitures de la table voiture.
SELECT Marque FROM voiture GROUP BY Marque ;

Marque Citroen Opel Peugeot Renault

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 ;

Marque Citroen Opel Peugeot Renault

Compte 1 1 2 2

Calcul de la moyenne dge par ville partir de la table personne.

SELECT Ville, AVG(ge) AS Moyenne_Age FROM personne GROUP BY Ville ;

Ville Bordeaux

Moyenne_Age 50.0000

SQL 103

Ville Lille Lyon Paris

Moyenne_Age 20.0000 34.0000 70.5000

Restriction sur le rsultat


Le rsultat de lopration de groupage peut lui-mme tre filtr : cest--dire que lon effectue une slection des lignes par rapport au contenu des colonnes obtenues dans la table rsultat prcdente. En pratique, on filtre sur le rsultat des oprations statistiques appliques aux sous-ensembles dfinis par le groupage. On reprend lexemple prcdent qui a permis de calculer le nombre de voitures par marques. On suppose que lon limine du rsultat les marques dont on possde moins de deux voitures en considrant que ces marques ne sont pas reprsentatives du parc.
Calcul du nombre de voitures par marque de la table voiture dont le nombre est suprieur 1.
SELECT Marque, COUNT(*) AS Compte FROM voiture GROUP BY Marque HAVING Compte > 1;

Marque Peugeot Renault

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;

Marque Citroen Opel Peugeot Renault

Compte 1 1 1 2

2.4 REQUTES SUR PLUSIEURS TABLES


Lorsque lon utilise plusieurs tables dans une requte SQL, il peut exister une ambigut dans les expressions sur les noms de colonnes. En effet, deux tables peuvent avoir une colonne de nom identique. Pour cette raison, on prfixera le nom de la colonne par le nom

104

Cration de bases de donnes

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 ;

Marque Peugeot Citroen Opel Peugeot Renault Renault

Couleur Rouge Noire Blanche Blanche Rose Bleue

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;

Marque Peugeot Citroen Opel Peugeot Renault Renault

Couleur Rouge Noire Blanche Blanche Rose Bleue

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

Nom Nestor Irma Henri Josette Jacques Nestor

Age 96 20 45 34 50 96

Ville Paris Lille Paris Lyon Bordeaux Paris

Sexe M F M F M M

Num Voit 1 1 1 1 1 2

Marque Peugeot Peugeot Peugeot Peugeot Peugeot Citroen

Type 404 404 404 404 404 SM

Couleur Rouge Rouge Rouge Rouge Rouge Noire

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.

Jointure interne (INNER JOIN)


Il sagit de lopration de base de lalgbre relationnelle. Elle permet de lier deux tables entre elles en introduisant un critre de sens des donnes issu du monde rel par opposition lopration prcdente. Elle peut sexprimer de plusieurs manires en SQL. La premire est semblable la restriction du produit cartsien prcdent, mais dans ce cas la requte nest gnralement pas traite de manire optimale par le SGBD.

106

Cration de bases de donnes

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 ;

Marque Peugeot Citroen Peugeot Renault

Couleur Rouge Noire Blanche Rose

Prix 10 000 70 000 30 000 45 000

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);

Marque Peugeot Citroen Peugeot Renault

Couleur Rouge Noire Blanche Rose

Prix 10 000 70 000 30 000 45 000

Nom Nestor Josette Nestor Irma

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

Jointure externe (OUTER JOIN)


Lopration de jointure interne ne permet pas de rpondre des questions du type : Quelles sont les voitures qui nont pas t vendues ? . cette fin, il nous faut utiliser un oprateur capable dinclure dans le rsultat les lignes de la table voiture qui nont pas de correspondance dans la table vente (par rapport aux valeurs de la colonne NumVoit) sans quil sagisse dun produit cartsien : cette opration spcifique se nomme la jointure externe. Loprateur SQL de jointure externe sexprime par le mot cl OUTER JOIN. Cette opration nest pas symtrique : soit on inclut toutes les lignes dune table, soit toutes celles de lautre. On prcise cela laide des mots cls LEFT et RIGHT ou en inversant simplement lordre des tables dans lexpression de linstruction de jointure. Dans la requte qui suit, toutes les lignes de la table voiture seront affiches, y compris celles pour lesquelles la colonne NumVoit na pas de correspondance dans vente : les colonnes issues de vente ne pourront alors tre mises en correspondance et auront la valeur NULL.
Construction de la jointure externe 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 voiture LEFT OUTER JOIN vente ON voiture.NumVoit=vente.NumVoit ;

NumVoit 1 2 3 4 5 6

NumVoit 1 2 NULL 4 5 NULL

Marque Peugeot Citroen Opel Peugeot Renault Renault

Couleur Rouge Noire Blanche Blanche Rose Bleue

Prix 10 000 70 000 NULL 30 000 45 000 NULL

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

Marque Peugeot Citroen Peugeot Renault

Couleur Rouge Noire Blanche Rose

Prix 10 000 70 000 30 000 45 000

108

Cration de bases de donnes

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

Marque Opel Renault

Couleur Blanche Bleue

Prix NULL NULL

2.5 TRI DU RSULTAT DUNE REQUTE


On utilise le mot cl ORDER BY pour spcifier la (les) colonne(s) sur laquelle (lesquelles) on souhaite trier le rsultat.
Tri par Marque de la table voiture.
SELECT Marque, Type FROM voiture ORDER BY Marque ;

Marque Citroen Opel Peugeot Peugeot Renault Renault

Type SM GT 404 403 Alpine A310 Floride

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 ;

Prix 70 000 45 000 30 000 10 000

DateVente 1996-03-30 2000-04-02 1998-06-14 1985-12-03

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 ;

Nom Jacques Irma Josette Henri Nestor

Age 50 20 34 45 96

Ville Bordeaux Lille Lyon Paris Paris

Gestion de tables et de vues

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

Cration de bases de donnes

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.

INT SMALLINT REAL FLOAT(n)

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.

CHAR(n) VARCHAR(n) NCHAR(b) NVARCHAR(b)

Tableau 4.8
Types de donnes date de SQL.

BOOLEAN BLOB DATE TIME[(n)]

Binary Large Object : permet de stocker tout type


binaire (photo, fichier traitement de texte) Date Heure, n (optionnel) est le nombre de dcimales reprsentant la fraction de secondes

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 ;

SELECT * FROM voiture ;

NumVoit 1 2 3 4 5 6

Marque Peugeot Citroen Opel Peugeot Renault Renault

Type 404 SM GT 403 Alpine A310 Floride

Couleur Rouge Noire Blanche Blanche Rose Bleue

enplus NULL NULL NULL NULL NULL NULL

Suppression de la colonne de nom Couleur de la table voiture (DROP COLUMN). Affichage de la table voiture modifie.

ALTER TABLE voiture DROP COLUMN Couleur;

SELECT * FROM voiture ;

NumVoit 1 2 3 4 5 6

Marque Peugeot Citroen Opel Peugeot Renault Renault

Type 404 SM GT 403 Alpine A310 Floride

enplus NULL NULL NULL NULL NULL NULL

112

Cration de bases de donnes

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

Marque Peugeot Citroen Opel Peugeot Renault Renault

Type 404 SM GT 403 Alpine A310 Floride

Couleur Rouge Noire Blanche Blanche Rose Bleue

Teinte NULL NULL NULL NULL NULL NULL

Recopie des donnes de Couleur dans Teinte. Affichage de la table voiture modifie.

UPDATE voiture SET Teinte=Couleur ;

SELECT * FROM voiture ;

NumVoit 1 2 3 4 5 6

Marque Peugeot Citroen Opel Peugeot Renault Renault

Type 404 SM GT 403 Alpine A310 Floride

Couleur Rouge Noire Blanche Blanche Rose Bleue

Teinte Rouge Noire Blanche Blanche Rose Bleue

Suppression de la colonne Couleur.

ALTER TABLE voiture DROP COLUMN Couleur;

SQL 113

Affichage de la table voiture modifie.

SELECT * FROM voiture ;

NumVoit 1 2 3 4 5 6

Marque Peugeot Citroen Opel Peugeot Renault Renault

Type 404 SM GT 403 Alpine A310 Floride

Teinte Rouge Noire Blanche Blanche Rose Bleue

3.2 CONTRAINTES DINTGRIT


Lors de ltape de conceptualisation, on a dfini la notion de domaine , qui dcrira lensemble des valeurs que peut prendre un attribut. Au niveau de SQL, une premire approche du domaine est tablie par le choix du type de la colonne, mais cela nest pas assez restrictif en gnral. SQL vous permet de dfinir des conditions de validit plus fines lors de la cration de la table, que lon nomme contraintes dintgrit. Cest le SGBD qui applique ces conditions au moment de linsertion, de la modification ou mme de la suppression de donnes dans le cas ou ces dernires sont lies dautres tables. Cette tape est parfois fastidieuse, mais elle garantit la cohrence des donnes et vite de se retrouver avec des bases de donnes, conceptuellement correctes, mais inutilisables faute de donnes valides. On peut distinguer diffrents types de contraintes sur les colonnes : les proprits gnrales comme lunicit ; les restrictions dappartenance un ensemble ; les dpendances entre plusieurs colonnes.

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

Cration de bases de donnes

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) ) ;

Condition dappartenance un ensemble


Il sagit de dcrire le domaine dans lequel la colonne pourra prendre ses valeurs. Un ensemble peut tre dcrit : En donnant la liste de tous ses lments constitutifs (IN). Lensemble des jours de la semaine ne peut tre exprim que de cette manire : lundi , mardi , etc. On vrifie que la colonne couleur ne peut prendre que des valeurs normalises : Rouge Vert ou Bleu.
CREATE TABLE voiture( NumVoit INT PRIMARY KEY, Marque CHAR(30) NOT NULL, Type CHAR(20), Couleur CHAR(40), CHECK Couleur in (Rouge,Vert,Bleu)

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) ) ;

Condition sur plusieurs colonnes (contrainte de table)


Lorsque lon dsire exprimer des contraintes plus labores impliquant plusieurs colonnes, on peut dfinir une contrainte de table en utilisant le mot cl CONSTRAINT. On vrifie que la colonne Age et la colonne Ville doivent tre renseignes ou vides en mme temps.

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

3.3 VUES (CREATE VIEW)


Une vue est le rsultat dune requte que lon peut manipuler de la mme faon quune table. On peut considrer une vue comme une table dynamique dont le contenu est recalcul chaque utilisation. On utilise les vues pour des raisons de commodit il nest pas ncessaire que certains utilisateurs voient le modle complet qui est parfois complexe ou encore de scurit/confidentialit en restreignant laccs certaines donnes. Dans cette optique, les vues viennent en complment de la gestion des droits daccs, qui est traite au chapitre 6.
CREATE VIEW personne_bis (NumAch, Nom, Age) AS SELECT NumAch, Nom, Age FROM personne ;

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.

Gestion des donnes


Les commandes SQL qui sont prsentes dans cette section concernent non plus la gestion de la structure des tables, mais celle des contenus. On dispose classiquement de trois oprations : linsertion, la suppression et la mise jour, pour grer les donnes dune table. Linsertion se fait enregistrement par enregistrement, mais cela peut se rvler fastidieux. Cependant, linsertion de donnes est possible galement partir de la lecture dun fichier externe dont le format est accept par le SGBD. Ces instructions dpendent donc du SGBD utilis. Les oprations de suppression et de modification des donnes se font partir de critres de slection des enregistrements (lignes) modifier ou supprimer. Par exemple, on peut dcider de supprimer toutes les personnes qui habitent Paris. Autre exemple : on actualise le prix en euros de lensemble des ventes qui ont eu lieu aprs la date du passage leuro. Ces critres sexpriment de la mme manire que pour les oprations de slection vues prcdemment. Il est galement possible dutiliser le rsultat dune requte pour dterminer lensemble des valeurs dune colonne afin deffectuer cette slection.

4.1 INSERTION (INSERT INTO)


Linsertion denregistrements dans une table peut se raliser de plusieurs manires : enregistrement par enregistrement (INSERT INTO) ; en insrant la rponse une requte SQL (INSERT INTO).

116

Cration de bases de donnes

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>

Insertion dun enregistrement dans la table voiture


INSERT INTO voiture (NumVoit, Marque, Couleur) VALUES (10,Triumph,Bleue) ;

Affichage de la table voiture modifie.

SELECT * FROM voiture ;

NumVoit 1 2 3 4 5 6 10

Marque Peugeot Citroen Opel Peugeot Renault Renault Triumph

Type 404 SM GT 403 Alpine A310 Floride NULL

Couleur Rouge Noire Blanche Blanche Rose Bleue Bleue

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.

Insertion denregistrement(s) partir du rsultat dune requte


La table dans laquelle on insre les donnes doit avoir le mme nombre de colonnes que la table rsultat de la requte (et le mme type).
INSERT INTO voiture SELECT NumVoit, Marque, Type, Couleur FROM voiturebis WHERE NumVoit>10;

Remarque
Pour tre insres, les valeurs des colonnes doivent respecter les contraintes dintgrit associes la table.

4.2 SUPPRESSION (DELETE FROM)


Lopration de suppression permet de supprimer un ensemble denregistrements (lignes) que lon identifiera avec une expression identique aux conditions de slection vues prcdemment.
DELETE FROM voiture WHERE Couleur=Rouge ;

SQL 117

Affichage de la table voiture modifie.

SELECT * FROM voiture ;

NumVoit 2 3 4 5 6

Marque Citroen Opel Peugeot Renault Renault

Type SM GT 403 Alpine A310 Floride

Couleur Noire Blanche Blanche Rose Bleue

Attention, si lon ne spcifie aucune condition, tous les enregistrements sont supprims.
DELETE FROM personne ;

4.3 MODIFICATION (UPDATE)


Pour cette opration, il faut prciser : la (les) colonne(s) concerne(s) ; la (les) nouvelle(s) valeur(s) ; les enregistrements pour lesquels on modifiera ces valeurs. De mme que prcdemment, on identifiera les enregistrements concerns par une expression de slection. La valeur modifie peut tre statique ou calcule partir des valeurs dautres colonnes.
Modification du nom dune ville dans la table personne. Affichage de la table personne modifie.
UPDATE personne SET Ville=Paris-Centre WHERE Ville=Paris ; SELECT * FROM personne ;

NumAch 1 2 3 4 5

Nom Nestor Irma Henri Josette Jacques

Age 96 20 45 34 50

Ville Paris-Centre Lille Paris-Centre Lyon Bordeaux

Sexe M F M F M

118

Cration de bases de donnes

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>

Linterrogation et la recherche dans les tables.


SELECT <liste de colonnes> FROM <nom de la table> WHERE <critre>

Figure 4.3
Synthse des commandes SQL.

AS, DISTINCT

JOIN (LEFT/RIGHT) JOIN

ON

+, , *, /, %

SELECT FROM

<liste de champs>
=, <, >, LIKE IS NULL, IN, BETWEEN OR, AND, NOT

AVG, MAX, MIN SUM, COUNT

<liste de tables> <liste de critres>

WHERE

ORDER BY <liste de champs>

ASC, DESC

GROUP BY <liste de champs> HAVING <liste de critres>

INSERT INTO CREATE TABLE <Table>

<Table>

( <liste de champs> )( <liste de valeurs> ) DELETE FROM <Table>

( <liste de champs + Type> )


DROP TABLE ALTER TABLE <Table> <Table>

WHERE <liste de critres> UPDATE <Table> SET < champ=valeur > WHERE <liste de critres>

( <liste de champs + Type> )

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

PROJECTION AVEC UNE COLONNE CALCULE


Affichez le chiffre daffaires, cest--dire la somme des prix de vente, toutes taxes (20 %) en considrant que la table contient les prix hors taxes. Renommez la colonne Rsultat en CA_TTC .

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

PROJECTION/RESTRICTION AVEC UN OPRATEUR STATISTIQUE


Trouvez lge moyen des personnes habitant Paris dans la base de donnes casse. Toutes les informations ncessaires se trouvent dans la table personne. Pour rsoudre cet exercice, on peut raisonner en deux temps : Extraire de la table personne les enregistrements dont la colonne Ville contient Paris (slection).
SELECT * FROM Personne WHERE Ville=Paris ;

Calculer laide dune fonction statistique la moyenne de la colonne Age pour ses enregistrements (projection).
SELECT AVG(Age) FROM Personne WHERE Ville=Paris ;

120

Cration de bases de donnes

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;

Calculer laide dune fonction statistique le nombre de lignes par marque.


SELECT Marque, COUNT(*) AS Nombre 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);

On aurait pu galement crire :


SELECT vo.Marque, pe.Nom FROM voiture AS vo, vente AS ve, personne AS pe WHERE (vo.NumVoit=ve.NumVoit) AND (pe.NumAch=ve. NumAch);

Le rsultat est-il identique ? Pourquoi ?

EXERCICE 8

REQUTE

SQL TRANGE

Que donnerait cette requte ?


SELECT vo.Marque, pe.Nom FROM voiture AS vo JOIN vente AS ve JOIN personne AS pe ON (vo.NumVoit=ve. NumAch) AND (pe.NumAch=ve. NumVoit);

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

AUTRE QUESTION NGATIVE

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

Cration de bases de donnes

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

SLECTION SUR UN AGRGAT DUNE JOINTURE


Calculez la moyenne des prix de vente par marques en ne considrant que les marques dont cette moyenne est suprieure 40 000. Les informations permettant de rpondre cette question se trouvent dans deux tables vente et voiture. Il nous faut donc effectuer une jointure sur la colonne NumVoit pour lier ces deux tables.
SELECT vo.Marque, ve.Prix FROM voiture AS vo JOIN vente AS ve ON vo.NumVoit=ve.NumVoit ;

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

SLECTION PAR RAPPORT AU RSULTAT DUN CALCUL STATISTIQUE


Affichez les prix qui sont suprieurs la moyenne. Ici, on doit comparer les valeurs de la table vente par rapport une opration qui a t ralise sur toutes les valeurs de la table. Cest une question simple en apparence, mais parfois difficile traiter car tous les SGBD nacceptent pas les requtes imbriques. Comme toujours, on peut dcomposer le raisonnement en plusieurs tapes : Calculer la moyenne des prix.
SELECT AVG(vente.Prix) AS Moyenne_Prix FROM vente ;

Comparer les prix.


SELECT ve1.Prix FROM vente AS ve1 WHERE ve1.Prix > (SELECT AVG(ve2.Prix) FROM vente AS ve2);

EXERCICE 12

CRATION DUNE TABLE


Crez la table personne avec les colonnes suivantes : NumAch. De type entier, cl de la relation. Nom. De type caractre, de taille 30, ne doit pas tre vide. Age. De type entier, compris entre 16 et 100. Ville. De type caractre, de taille 40. Sexe. De type caractre, de taille 1, doit contenir H ou F .
CREATE TABLE personne (NumAch INT PRIMARY KEY, Nom CHAR(30) NOT NULL, Age INT, Ville CHAR(40), Sexe CHAR(1), CHECK (Age BETWEEN 16 AND 100), CHECK Sexe IN (H,F) );

124

Cration de bases de donnes

Chapitre

EXERCICE 13

INSERTION DE DONNES DANS UNE TABLE


Insrez les valeurs suivantes dans la table prcdemment cre. NumAch : 100 Nom : Essai Ville : Paris Lenregistrement est-il valid ? (Satisfait-il aux contraintes dintgrit ?) On ninsre par toutes les valeurs des colonnes ; donc, il faut prciser la liste des colonnes pour lesquelles une valeur est prsente dans lordre que lon choisit.
INSERT INTO personne (NumAch, Ville, Nom) VALUES (100,Paris,Essai) ;

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

MODIFICATION DES DONNES DUNE TABLE


Modifiez le prix de vente (+10 %) des voitures. Les informations modifier se trouvent simplement dans la table vente bien que la question voque les voitures . Il ny a pas de critre dans ce cas puisque lon modifie toute la table.
UPDATE vente SET Prix=Prix*1.1 ;

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

Du langage parl SQL


1. Prsentation de lactivit modliser ............................128 2. laboration du modle entit-association ....................129 3. Passage au modle relationnel ..134 4. Interrogation de la base de donnes ............................141 Exercices 1. Reprsentation UML ................148 2. Calculs par expression SQL .....148 3. Code SQL et signification ........149 4. Agrgats et slection ...............150 5. Requtes combines ...............151 6. Simple slection ou jointure externe ? ....................152 7. Mise jour de la base ............153 8. volution de la base de donnes ............................154 9. Autre exemple complet ............154

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

Prsentation de lactivit modliser


On veut modliser la gestion dune entreprise de fabrication et de livraison de pizzas domicile : la socit RaPizz. Il sagit dune socit en franchise qui utilise des formats et des compositions de pizzas normaliss partir dun ensemble dingrdients dtermins. En dautres termes, le client na pas la libert de composer lui-mme une pizza personnalise ; il doit choisir dans le catalogue propos.

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

Cration de bases de donnes

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.

laboration du modle entit-association


Lors de cette tape, on dtermine les lments qui permettront de constituer les futures tables de la base de donnes. Pour laborer ce modle, on procde en deux temps : construction du graphe des entits relies par les associations ; qualification des associations par leurs cardinalits. Ce schma est trs important, car il reprsente en somme la documentation de la future base de donnes. Lensemble de tables obtenues la suite de lopration de passage au schma relationnel est gnralement peu lisible et donne peu dindications sur les liens entre les diffrents lments. En effet, il est quasi impossible de dterminer quelles tables peuvent tre jointes, du point de vue du sens des donnes dans la ralit, sans disposer du schma entit-association associ.

2.1 IDENTIFICATION DES ENTITS ET DES ASSOCIATIONS


La premire tape consiste reprer les diffrentes entits que lon doit considrer. Pour ce faire, il nous faut trouver les phrases simples qui identifient lactivit par rapport lnonc. Paralllement, on peut chercher quels objets concrets du monde rel semblent impliqus dans le systme. Puis, pour chaque entit, on doit dterminer une cl parmi les attributs. Enfin, on caractrise les liens entre les entits par des associations.

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

Cration de bases de donnes

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

Du langage parl SQL 131

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

# NumCommande DateCom Taille Retard

Constitue

Vhicule
# NumImmat Marque Type

Ingrdient
# NumIngre NomIngre
Compose

Pizza
# NomPizza Prix

2.2 DTERMINATION DES CARDINALITS


On se pose ensuite des questions sur la nature des liens entre les entits capables de dterminer les cardinalits qui seront utilises pour le passage au modle relationnel. On doit trouver deux cardinalits, maximales et minimales, par entit associe, ce qui correspond deux questions doubles par association. Il sagit dune tape dinventaire un peu fastidieuse, mais elle est indispensable et permet de poser un autre regard sur le modle. Association Compose Ingrdient : un ingrdient peut-il ne jamais tre utilis dans la composition dune pizza et peut-il tre utilis plusieurs fois ? On suppose que si un ingrdient est au catalogue, cest quil est utilis au moins une fois (1) et quil peut entrer dans la composition de plusieurs (n) pizzas. Les cardinalits associes sont de type 1-n. Pizza : une pizza peut-elle navoir aucun ingrdient et peut-elle en avoir plusieurs ? On suppose quune pizza est constitue dau moins un (1) ingrdient et quelle peut en avoir plusieurs (n). Les cardinalits associes sont de type 1-n. Association Passe Client : un client peut-il navoir jamais pass de commandes et peut-il en avoir pass plusieurs ? Il peut y avoir une priode pendant laquelle le client a approvisionn son compte mais na pas encore pass (0) de commande et il est videmment encourag en passer plusieurs (n). Les cardinalits associes sont de type 0-n. Commande : une commande peut-elle avoir t passe par aucun client ou par plusieurs ? Une commande donne est passe par un (1) et un (1) seul client. Les cardinalits associes sont de type 1-1.

132

Cration de bases de donnes

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

Livre 1,1 1,1

Transporte Constitue 1,n 0,n

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.

Du langage parl SQL 133

Passage au modle relationnel


Cette section reprsente le travail prliminaire effectu en vue du passage lutilisation dun SGBD. Elle comprend plusieurs parties : la transformation du modle entit-association en modle relationnel laide des rgles nonces prcdemment ; la vrification de la conformit des relations cres par rapport la dfinition des formes normales du modle relationnel ; la discussion sur le type des donnes adopter pour chaque champ ainsi que sur les contraintes dintgrits dfinir ; la cration des tables en SQL.

3.1 TRANSFORMATION DU MODLE ENTIT-ASSOCIATION


Les deux rgles gnrales de passage du modle entit-association vers le modle relationnel sont les suivantes : Une entit donne une relation de mme cl que lentit qui contient les mmes attributs que lentit. Une association donne une relation dont la cl est compose des deux cls des entits associes et des attributs de lassociation.

Application de la rgle gnrale


On obtient les relations suivantes partir des entits : commande (NumCommande, DateCom, Taille, Retard) ; client (NumClient, NomClient, Adresse, Compte, PointsRaPizz) ; pizza (NomPizza, Prix) ; livreur (CodeLivreur, NomLivreur, Telephone) ; vhicule (NumImmat, Marque, Type) ; ingrdient (NumIngre, NomIngredient). En appliquant la rgle gnrale, on obtient les relations suivantes partir des associations : livre (CodeLivreur, NumCommande) ; transporte (NumImmat, NumCommande) ; passe (NumClient, NumCommande) ; constitue (NomPizza, NumCommande) ; compose (NumIngre, NomPizza).

Cas particuliers des associations de cardinalit 1-1


Un cas particulier existe lorsque lune des cardinalits dune association est de type 1-1. La relation reprsentant lassociation disparat et fusionne avec la relation reprsentant lentit associe avec la cardinalit 1-1. On peut dire quil y a aspiration de lassociation par lentit. Dans cet exemple, de nombreuses associations sont de type 1-1 par rapport lentit commande , comme lassociation livre . Lapplication de cette rgle produit une sim-

134

Cration de bases de donnes

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).

3.2 VRIFICATION DE LA CONFORMIT AUX FORMES NORMALES


On doit vrifier que lensemble de relations cres ltape prcdente est bien en conformit avec les formes normales. On peut se limiter en gnral aux trois premires formes normales. En effet, celle de Boyce-Codd provoque frquemment un certain niveau de perte dinformations (voir chapitre 3 pour plus de prcisions).

Premire forme normale


A priori, aucune des relations ne dispose de champs plusieurs valeurs (multivalus) : chaque champ possde une valeur atomique . Cependant, on pourrait sinterroger par exemple sur le contenu du champ NomClient dans la relation client ainsi que sur le champ NomLivreur de la relation livreur. Sils contiennent le nom et le prnom de la personne, il est prfrable de les sparer systmatiquement en deux champs : NomClient et PrenomClient, NomLivreur et PrenomLivreur. De mme, il faut considrer le contenu du champ Adresse de la relation client : pour des raisons de simplification et de lisibilit de lexemple, on na pas dcoup ladresse en ses diffrents composants classiques : numro, type de voie, nom de la voie, ville, code postal et pays. Toutes les relations sont en premire forme normale si lon tient compte des remarques sur le contenu de champs du prcdent paragraphe.

Du langage parl SQL 135

Deuxime forme normale


La recherche de non-conformit la deuxime forme normale na de sens que si la cl est compose de multiples champs. Dans notre cas, la seule relation qui possde une cl composite est la relation compose. De plus, cette relation ne contient aucun attribut qui ne fasse pas partie de la cl. La relation est en deuxime forme normale. Toutes les relations sont en deuxime forme normale.

Troisime forme normale


En revanche, la troisime forme normale concerne les liens qui peuvent exister entre des champs qui ne font pas partie de la cl dune relation. Si lon considre la relation client, les champs ne faisant pas partie de la cl sont les suivants : NomClient, Adresse, Compte, PointsRaPizz. Il est clair que le solde du compte ne permet de dterminer ni le nom du client, ni son adresse, ni son nombre de points de fidlit. Ce dernier et le nom dune personne ne permettent pas non plus didentifier le contenu des autres champs. La question pourrait ventuellement se poser pour le champ Adresse, susceptible dans certains cas dtablir le nom du client si lon suppose que deux clients nhabitent pas la mme adresse. Par le mme type de raisonnement sur la relation vehicule, on peut tre amen identifier une relation de dpendance entre le type qui est unique pour un vhicule. Si lon suppose que les constructeurs dposent le nom du type de leur vhicule, il permet de dterminer sans ambigut le nom de la marque. Ce dernier pouvant tre identique pour deux vhicules on vite ainsi la redondance provoque par sa rptition. En toute rigueur, on serait conduit dans ce cas dcomposer la relation vhicule en deux relations : vhicule (NumImmat, Type) ; constructeur (Type, Marque). On remarque immdiatement la complexit introduite par cette dcomposition en regard du gain apport pour viter une redondance modeste, surtout si le nombre de vhicules est relativement faible. Aprs analyse, on ne trouve de relations de dpendance entre aucun des champs de la relation commande qui ne font pas partie de la cl, cest--dire les champs DateCom, Taille, Retard, CodeLivreur, NumImmat, NumClient et NomPizza. Sil y avait de trs mauvais livreurs qui livrent systmatiquement en retard et dautres qui ne livrent jamais en retard, il pourrait exister une relation de dpendance entre les champs CodeLivreur et Retard, mais cela est peu probable dans la ralit. On pourrait trouver une relation de dpendance entre les champs de cette relation en forant un peu le raisonnement pour la relation Livreur. En effet, si lon suppose que le tlphone est un numro de portable personnel et quil est associ un livreur donn, alors le numro de tlphone permet de dterminer le nom du livreur et son code client. Le champ devient une cl candidate. On pourrait peut-tre supprimer la cl constitue par le code client pour viter la redondance entre ce code que lon a fabriqu et le numro de tlphone. Il ne sagit plus dans ce cas que dun problme de conformit la troisime forme normale puisque le champ cl est concern. Dans la pratique, un critre pour la slection entre plusieurs cls est de choisir le champ dont le contenu est le plus stable dans le temps. Un numro de tlphone peut changer ; on lui prfrera donc le numro de code. Toutes les relations ne sont pas strictement en troisime forme normale, mais on considre les redondances rsiduelles comme acceptables.

136

Cration de bases de donnes

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.

3.3 TYPES DE DONNES ET CONTRAINTES


Cette section permet de dterminer quels contrles doivent tre appliqus sur le contenu des champs afin den garantir la cohrence. Les contraintes sont mises en uvre par le SGBD employ et sont exprimes dans les instructions de cration des tables. Ces contraintes expriment lappartenance un ensemble. Un ensemble en SQL peut tre dcrit de quatre manires : le typage gnral dun point de vue des types prdfinis de SQL (par exemple, entier, rel, caractre, date) ; une numration des diffrentes valeurs possibles (par exemple, do , r , mi , fa , sol ) ; lexpression dun intervalle dans lequel les valeurs sont contenues (par exemple, compris entre 10 et 30) ; la rfrence aux valeurs dun champ dune autre table (par exemple, contenu du champ code_postal de la table communes). Seule la description du type est obligatoire pour crer un champ, les autres contraintes tant videmment optionnelles. Les champs dont les valeurs doivent tre absolument renseignes sont indiqus spcifiquement en langage SQL par le mot cl NOT NULL .

Type(s) des donnes


La dfinition du type des donnes a pour but de faire une premire restriction sur les valeurs que peut prendre un champ et surtout de spcifier les oprations et fonctions quil sera possible de lui appliquer. Lutilisation du type date pour le champ DateCom permettra dutiliser des fonctions dextractions du mois, du jour de la semaine ainsi que dautres oprations spcifiques aux donnes de type date pour ce champ. Le champ Telephone de la table livreur ne contiendra que des valeurs de type numrique, mais on neffectuera jamais doprations de calculs sur ce champ : une moyenne des numros de tlphone na gure de sens. En revanche, lextraction dun prfixe, comme par exemple les deux premiers chiffres dun numro peut tre utile. On emploie alors un champ de type chane de caractres sur lequel il est possible demployer des fonctions dextraction de chane. Les champs de type numrique sont presque tous de type entier, sauf le champ Compte de la table client et le champ Prix de la table Pizza qui sont de type rel. La taille des champs de type chane de caractres est un compromis trouver entre loccupation de place inutile et la taille maximale suppose des valeurs que peuvent contenir ce champ. Table client NumClient : code simple de type entier NomClient : chane de caractres ( renseigner obligatoirement) Adresse : chane de caractres Compte : solde de type rel

Du langage parl SQL 137

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

Cration de bases de donnes

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.

3.4 CRATION DES TABLES


La cration des tables se fait partir de la dfinition des relations effectues prcdemment. On spcifie le nom des champs, leur type, les contraintes dintgrit et la dfinition des cls. On peut choisir galement ce moment les champs sur lesquels on souhaite crer des index. Ces derniers amliorent la recherche par le contenu, mais pnalisent les mises jour puisquil faut modifier les tables dindex. En gnral, mme si lon est susceptible deffectuer des recherches sur tous les champs, on ne cre pas dindex pour chacun dentre eux afin de ne pas pnaliser les performances, mme si lon est susceptible deffectuer des recherches sur tous les champs. Cela pourrait tre cependant envisageable si le contenu de la base est trs statique et que lon souhaite favoriser les performances de recherche. Les index peuvent tre crs sparment. En pratique, on cre systmatiquement un index sur les cls des relations, ne serait-ce que pour amliorer les oprations de jointure. Certains SGBD prennent dailleurs linitiative de crer lindex sur la cl mme si lon ne le spcifie pas explicitement. Table client
CREATE TABLE client ( NumClient INT PRIMARY KEY, NomClient VARCHAR(20) NOT NULL, Adresse VARCHAR(150) , Compte REAL, PointsRaPizz INT );

Table pizza
CREATE TABLE pizza( NomPizza CHAR(30) PRIMARY KEY, Prix CHAR(30) NOT NULL,

Du langage parl SQL 139

CHECK (Prix BETWEEN 1 AND 30) );

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

Cration de bases de donnes

Chapitre

Interrogation de la base de donnes


Cette section aborde la manire de passer dune question en langage parl la requte SQL conduisant au rsultat. Lensemble des questions nest videmment pas exhaustif ; on a effectu un choix qui permet de mettre en valeur certains points jugs intressants. On utilise galement ces questions pour porter un regard sur les reprsentations choisies et vrifier quelles sont bien adaptes. Le sujet de loptimisation des requtes en fonction du SGBD choisi nest pas trait, car il dpasse largement le cadre de cet ouvrage.

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;

La seconde, plus efficace, est dutiliser linstruction de jointure JOIN.


SELECT pizza.NomPizza, ingredient.NomIngre, pizza.Prix FROM pizza JOIN ingredient JOIN compose ON (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.

4.2 FICHE DE LIVRAISON


On veut imprimer une fiche de livraison qui mentionne le nom du livreur, le type du vhicule utilis, le nom du client, la date de la commande, le retard ventuel, le nom et le prix de base de la pizza. Par le mme raisonnement que prcdemment, on identifie les tables commande, client, pizza, livreur et vehicule pour les champs projeter :

Du langage parl SQL 141

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.

4.3 QUELS SONT LES VHICULES NAYANT JAMAIS SERVI ?


Si lon se reporte aux cardinalits du modle entit-association, le cas ne doit pas exister. On a choisi une cardinalit de type 1-n, ce qui signifie quun vhicule a livr au moins une commande et quil a pu en livrer plusieurs. Cette requte va permettre de vrifier quil ny a pas dincohrence ce niveau. On espre que le rsultat sera vide. On a besoin pour rpondre aux questions du type quels sont les qui nont pas dutiliser une extension des oprations de jointure : la jointure externe. Celle-ci permet dinclure dans le rsultat dune jointure les enregistrements qui nont pas de valeur correspondante dans lautre table. Les valeurs des champs de cette autre table sont alors logiquement vides. Il suffit de slectionner ces lignes vides pour obtenir la rponse la question. Cest une opration non symtrique ; on part de la table vehicule que lon va joindre.
SELECT vehicule.NumImmat, vehicule.Marque, vehicule.Type FROM vehicule LEFT OUTER JOIN commande ON vehicule.NumImmat = commande.NumImmat WHERE commande.NumImmat IS NULL;

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

Cration de bases de donnes

Chapitre

4.4 QUELS CLIENTS COMMANDENT PLUS QUE LA MOYENNE ?


Bien que la question dorigine exprime en langage parl soit simple, ce genre de requte doit tre aborde avec prudence. La meilleure approche consiste sparer les tapes de ralisation de la requte ; cette dernire peut tre dissocie en trois tapes : On calcule ce que commande chaque client. On calcule la moyenne des commandes. On cherche les clients qui ont command plus que la moyenne. chaque tape, on cre une table temporaire qui nous permet de rutiliser le rsultat de la requte pour les autres tapes. Les tables temporaires disparaissent la fin de la session SQL.

Calcul du nombre de commandes par client


On utilise la notion dagrgat pour effectuer une opration statistique sur des regroupements denregistrements de la table. La prsence du mot par dans la question oriente assez naturellement vers un regroupement et donc vers lutilisation dun agrgat.
CREATE TEMPORARY TABLE requete1 SELECT commande.NumClient, NomClient, COUNT(*) AS NombreCommande FROM client JOIN commande ON client.NumClient=commande.NumClient GROUP BY commande.NumClient;

Calcul de la moyenne des commandes


On doit calculer la moyenne du nombre de commandes par client ; on utilise cet effet une opration statistique classique sur le champ de la table nombre de commande cre par la requte prcdente.
CREATE TEMPORARY TABLE requete2 SELECT AVG(NombreCommande) AS MoyenneCommande FROM requete1;

Extraction des clients ayant command plus que la moyenne


Enfin, on utilise la valeur de la moyenne obtenue par la seconde requte dans lexpression du critre de slection des enregistrements sur la table obtenue par la premire requte. Un petit artifice est employ ici. Comme la table provenant de la seconde requte ne contient quun champ, on effectue un produit cartsien entre ces deux tables sans modifier le nombre de lignes du rsultat. Le but est de pouvoir disposer de la valeur du champ de la moyenne des commandes pour le comparer au compte du nombre de commandes.
SELECT requete1.NumClient, requete1.NomClient FROM requete1, requete2 WHERE requete1.NombreCommande > requete2.MoyenneCommande;

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)

Du langage parl SQL 143

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.

4.5 CALCUL DU PRIX DUNE COMMANDE


On dsire calculer le prix dune commande dans le but dtablir ensuite le rcapitulatif du chiffre daffaires mensuel, par exemple par client, et de faon gnrale dautres calculs. Le prix dune commande est fonction de la taille de la pizza commande, qui pondre le prix de base de la pizza ; on peut lextraire de la table pizza.

Difficults lies la reprsentation choisie


On saperoit lors de cette opration que la reprsentation sous forme textuelle ( naine , humaine , ogresse ) de la taille dune pizza nest pas adapte pour le calcul. En effet, on est incapable de calculer son prix directement en SQL partir des informations contenues dans la table. Il ny a pas dindication dans la base de donnes du mode de calcul du prix de la pizza, ce qui signifie que lon doit faire un test de ce type : si taille vaut ogresse , alors prix = prix (1 + 1/3). Le plus simple est alors de passer par un langage de programmation pour associer la taille au coefficient qui permet de calculer le prix. Ce nest pas le but recherch ; la base de donnes doit tre autonome et il sagit dune information importante que lon doit pouvoir retrouver dans la base et qui doit donc y tre stocke.

Modification de la base de donnes


On propose une modification de la base de donnes pour intgrer cette notion. Une premire solution simple serait de remplacer le libell de la taille par le coefficient qui permet de calculer le prix. On remplace naine par 2/3 , humaine par 1 et ogresse par 4/3 . On doit changer le type du champ Taille sans perdre le contenu. Le plus simple est de recrer un champ Taille_Prix et de faire une mise jour. Les commandes qui modifient le contenu sont les suivantes :
Ajout du champ Taille_prix ALTER TABLE commande ADD COLUMN Taille_Prix Float; Cration du contenu du champ en fonction du contenu de Taille UPDATE commande SET Taille_Prix=2/3 WHERE Taille=naine ; UPDATE commande SET Taille_Prix=1 WHERE Taille=humaine ; UPDATE commande SET Taille_Prix=4/3 WHERE Taille=ogresse ; Destruction du champ Taille ALTER TABLE commande DROP COLUMN Taille;

On peut alors calculer le prix dune commande directement.

144

Cration de bases de donnes

Chapitre
SELECT commande.NumCommande, pizza.Prix*commande.Taille_Prix AS Prix_Commande FROM commande JOIN pizza ON commande.NomPizza=pizza.NomPizza;

Rflexion sur la modification apporte et amlioration de la solution


Si le mode de calcul change, par exemple si lon dcide quune pizza naine cote 3/4 du prix normal, il faut alors modifier le(s) coefficient(s) pour toutes les commandes. On perd galement la mention du libell, plus commode manipuler et probablement indispensable pour imprimer les factures. On aurait pu conserver le champ Taille avec le libell pour ne pas perdre cette information, il suffit de ne pas effacer la colonne Taille (dernire commande de la liste prcdente). On se trouve alors dans la situation o il existe une dpendance fonctionnelle entre les champs Taille et Taille_Prix. En effet, une taille correspond un unique prix : la relation commande nest plus en troisime forme normale et lon a cr de la redondance. Pour rgler ce problme, il suffit de dcomposer la relation commande en crant une nouvelle relation tarification qui dcrira le coefficient en fonction du libell.
Cration de la table tarification CREATE TABLE tarification( Taille CHAR(30) PRIMARY KEY, Coefficient FLOAT NOT NULL ); Insertion des donnes dans la table tarification INSERT INTO tarification (Taille, Coefficient) VALUES (naine, 2/3) ; INSERT INTO tarification (Taille, Coefficient) VALUES (humaine, 1) ; INSERT INTO tarification (Taille, Coefficient) VALUES (ogresse, 4/3) ;

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;

Implications des modifications apportes au modle entitassociation


Quelles sont les rpercussions de cette modification sur le modle entit-association utilis jusqu prsent ? Par un processus inverse, on doit retrouver logiquement le mme ensemble de relations. La phrase qui reprsente lassociation entre les entits est la suivante : Une commande utilise la tarification . La nouvelle relation introduite provient dune nouvelle entit associe lentit commande : Lattribut Taille ne se trouve plus dans lentit commande. La nouvelle entit Tarification contient les attributs Taille et Coefficient, lattribut Taille est la cl de cette entit. Lentit tarification est associe lentit commande par une association que lon peut nommer utilise.

Du langage parl SQL 145

Cardinalits de lassociation utilise.

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

Transporte 0,n 1,n Constitue

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

Cration de bases de donnes

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.

Du langage parl SQL 147

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

# CodeLivreur NomLivreur Tlphone

Commande
# NumCommande DateCom Retard
0..n

0..n

0..n

1..n

# NumClient NomClient Adresse Compte PointsRapizz

Transporte

Utilise 1..1 Constitue

Tarification
1..1

Vhicule
# NumImmat Marque Type

#Taille Coefficient

1..1

Pizza
1..n

Ingrdient
Compose

# NomPizza Prix

# NumIngre NomIngre

1..n

EXERCICE 2

CALCULS PAR EXPRESSION

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

Cration de bases de donnes

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

Cette requte SQL donne-t-elle un rsultat ? Si oui, que signifie-t-il ?


SELECT client.NomClient, livreur.NomLivreur FROM livreur JOIN client ON livreur.CodeLivreur=client.NumClient ;

Imaginez quel type de question a voulu rpondre la personne qui a fait cette requte.

Du langage parl SQL 149

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

Cration de bases de donnes

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.

Du langage parl SQL 151

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

SIMPLE SLECTION OU JOINTURE EXTERNE

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 ;

Soit on fait la jointure lors de la seconde requte.


CREATE TEMPORARY TABLE requete1 SELECT commande.CodeLivreur, COUNT(*) AS NombreRetard FROM commande GROUP BY commande.CodeLivreur ORDER BY NombreRetard ; SELECT livreur.NomLivreur FROM requete1 JOIN livreur ON requete1.CodeLivreur=livreur.CodeLivreur WHERE requete1. NombreRetard=0 ;

152

Cration de bases de donnes

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

MISE JOUR DE LA BASE


On veut mettre jour le solde du compte dun client aprs chaque commande. Pour ce faire, il est ncessaire de recourir un langage de programmation ou des notions qui dpassent le cadre de cet ouvrage ; on sintresse simplement aux diffrentes requtes prvoir pour raliser cette opration. Pour linstant, on considrera que lon cre la requte de mise jour sans se proccuper des aspects de solde (ngatif ou positif) du compte. On calcule le prix de la commande comme on la vu prcdemment. La commande est identifie par son numro de commande, ici 60. On aura galement besoin du numro de client pour faire la mise jour.
CREATE TEMPORARY TABLE requete1 SELECT commande.NumClient, pizza.Prix*tarification.Coefficient AS Prix_Commande FROM commande JOIN pizza JOIN tarification ON commande.NomPizza=pizza.NomPizza AND commande.Taille=tarification.Taille WHERE NumCommande=60 ;

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 ;

Du langage parl SQL 153

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

VOLUTION DE LA BASE DE DONNES


On veut pouvoir calculer les prix des pizzas hors taxes et toutes taxes. Que faut-il modifier dans la base de donnes selon que le taux est considr comme fixe ou susceptible de varier ? Pour traiter ce genre de cas, on doit se rappeler que lon ne stocke jamais une donne qui peut tre calcule. Par consquent, on ne stocke pas les prix hors taxes et toutes taxes de chaque pizza. On suppose que le prix stock dans la table pizza est le prix hors taxes. Si le taux est fixe, on peut lutiliser pour les calculs de prix toutes taxes. On affiche le contenu de lexpression qui permet de calculer le prix toutes taxes.
SELECT NomPizza, Prix*(1+19.6) AS Prix_Ttc FROM pizza ;

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

AUTRE EXEMPLE COMPLET


Xavier S. possde deux tablissements hteliers dans le Limousin : Le Saint-Bob Saint-Robert et Le Saint-Sgur Sgur-le-Chteau. Il dsire automatiser la gestion des rservations. Les chambres proposes dans les deux tablissements sont de trois types : simples (50 /jour), doubles (65 /jour) et royales (150 /jour). Dans chacun des deux htels, les chambres sont numrotes en fonction de ltage : les chambres en rez-dechausse portent les numros 001, 002 ; les chambres du premier tage portent les numros 100, 101 ainsi de suite. Les rservations sont centralises Saint-Robert au 0800 800 800 et un employ est charg de rpondre au tlphone pour les deux tablissements. Lorsquun client rserve une chambre, sil nest pas rfrenc, on lui demande son nom, son prnom, son numro de tlphone ainsi que son adresse.

154

Cration de bases de donnes

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) ) ;

Du langage parl SQL 155

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 ) ;

4. Code SQL permettant de lister les rservations de 2006


SELECT * FROM `RESERVER` WHERE `DATE_DEBUT` >= '01/01/2006 ' AND `DATE_FIN` <= '31/12/2006' ;

156

Cration de bases de donnes

Chapitre

Prservation des donnes


1. Contrle daccs et sauvegarde ............................158 2. Limitations daccs au SGBD ...161 3. Transactions ...........................166 4. Triggers ................................173 Exercices 1. Scurit de base .....................176 2. Disponibilit des donnes ........176 3. Niveaux dutilisation dune base de donnes ............................177 4. Gestion des droits ...................178 5. Vues ......................................179 6. Transactions ...........................181 7. Trigger ...................................182

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

Contrle daccs et sauvegarde


Toute rflexion autour de la scurit doit se concevoir de manire globale en utilisant en premier lieu le bon sens : il est inutile dinstaller une porte blinde inviolable sur une palissade en bois. Les recommandations qui sont nonces dans cette section sont applicables tous les systmes informatiques, en particulier ceux qui sont connects un rseau ou situs dans un milieu qualifi d hostile . On dcrit ici plusieurs types de proccupations : laccs physique la machine ; laccs distant la machine travers le rseau ; les aspects de prennit de lensemble machine, systme dexploitation et SGBD ; les sauvegardes, la redondance des donnes et leur accessibilit.

1.1 ACCS PHYSIQUE LA MACHINE


Cette mesure de scurit informatique lmentaire est trs souvent nglige. Procurer un accs physique la machine permet en gnral de contourner toutes les protections lies au systme dexploitation ou au SGBD que lon aborde dans ce chapitre. Il suffit de dmarrer une machine avec un autre systme dexploitation prsent sur un CD ou une cl USB par exemple pour obtenir un accs au disque et ainsi aux donnes associes au SGBD. La premire prcaution prvoir consiste protger le BIOS (Basic Input Output System) ou lquivalent de la machine pour lempcher de dmarrer sur un autre disque que celui qui contient le bon systme dexploitation. Le fait de pouvoir accder directement la machine permet galement une personne anime de mauvaises intentions dempcher laccs aux donnes en dtruisant physiquement le disque sur lequel se trouvaient les fichiers ou mme la machine. Par consquent, la ou les machines qui contiennent le SGBD et les fichiers de donnes doivent se trouver dans des pices dont laccs est, au minimum, contrl. Dans le mme ordre dide, lalimentation lectrique ne doit pas tre accessible. On a tous entendu ou vcu une histoire de machines ou dlments rseaux dbranchs par erreur pour effectuer le mnage, sans parler de la malveillance. Comme on peut le constater, les prcautions concernant laccs physique la machine ne sont pas toujours dordre purement technique ; elles relvent souvent du simple bon sens commun.

1.2 ACCS LA MACHINE PAR LE RSEAU


Laccs la machine par le rseau est devenu une porte dentre privilgie pour les personnes malintentionnes, car rares sont les serveurs qui ne sont pas connects aujourdhui. On distingue ainsi principalement deux aspects de problmes de scurit : les attaques internes qui proviennent de personnes ayant accs la machine par un compte standard associ un mot de passe correct ; les attaques externes qui se font en profitant dune faille du systme dexploitation ou dune des applications installes sur la machine. Dans les deux cas, on peut tre confront un problme de destruction de donnes par simple effacement de fichiers de donnes. Cette opration deffacement sera rendue plus ou moins facile suivant les systmes employs. Dans le premier cas, il est en principe

158

Cration de bases de donnes

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.

1.3 PRENNIT DU SYSTME


Une base de donnes se conoit gnralement pour de nombreuses annes dutilisation. Il est donc essentiel, avant de choisir une machine, son systme dexploitation ainsi que le logiciel de SGBD, de prendre en considration leurs prennits respectives. Le choix peut alors se porter sur des ensembles moins performants mais que lon considre comme plus viables en termes de dure de vie. Voici quelques points considrer : Le suivi de la machine elle-mme. Par exemple, la dure de la garantie matrielle, la possibilit de retrouver les pices etc. La dure de vie du systme dexploitation. Un systme qui nest plus mis jour par son diteur et qui prsente des trous importants de scurit se rvle un trs mauvais choix. La plupart des diteurs continuent assurer une maintenance minimale pour les anciens systmes, mais ce nest pas systmatique. Lvolutivit du SGBD. Un SGBD propritaire qui noffre pas les changes de donnes avec dautres logiciels handicape la migration vers un autre SGBD. De mme que pour les points prcdents, un SGBD qui prsente des failles importantes de scurit daccs ou de fonctionnement et qui nest plus mis jour par lditeur constitue un problme potentiel quaucune autre prcaution ne saurait combler. Cette projection dans lavenir nest pas toujours vidente compte tenu du nombre de paramtres prendre en compte. Il est difficile de prdire quun constructeur ou un diteur ne

Prservation des donnes 159

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.

1.4 SAUVEGARDE, REDONDANCE ET ACCESSIBILIT DES DONNES


Sauvegarde des donnes
Des copies de sauvegarde des donnes contenues dans la base, mais aussi des mtadonnes (dictionnaire de donnes) du SGBD, doivent tre ralises rgulirement. Outre les problmes de malveillance, un incendie ou une inondation peuvent rduire nant des annes de travail. Dans la mesure du possible, les sauvegardes ne doivent pas tre stockes dans le mme endroit que la machine. Lidal tant de disposer dune armoire de stockage adapte qui soit ignifuge et situe dans un endroit labri des inondations. Si ce stockage se trouve dans un lieu diffrent, cest encore mieux. Compte tenu du volume des donnes utilis actuellement, la sauvegarde peut poser des problmes de taille de support physique de stockage. cet effet, on utilise frquemment des robots de sauvegarde spcialiss, manipulant des bandes que lon peut regrouper pour former un espace de stockage suffisant. Les disques regroups dans un dispositif autonome (type RAID) sont galement trs employs pour les sauvegardes en raison de leur prix relativement abordable. Ils apportent de plus une certaine scurit lie des mcanismes de redondance, qui leur assure un fonctionnement sans pertes de donnes en cas de panne de lun des disques.

Redondance des donnes


Un procd plus efficace et plus sr consiste disposer de copies de la base en plusieurs endroits gographiquement distincts. La plupart des SGBD sont capables deffectuer des mises jour sur des copies de la base de donnes situes sur dautres machines via le rseau. La frquence de ces mises jour va dpendre de celle de modification des donnes. Cette mthode permet de plus damliorer la disponibilit des donnes : Si lun des serveurs est inaccessible, un autre peut prendre le relais. Il est possible ainsi de rpartir la charge sur plusieurs serveurs. On obtient une redondance de machines et donc des donnes. Cela peut sembler paradoxal dans la mesure o une grande partie de louvrage est consacre la suppression de la redondance, mais le concept mis en uvre ici est diffrent. Les donnes sont simplement dupliques pour se prmunir contre leur perte et augmenter leur disponibilit. Ce dispositif est complexe grer dun point de vue du rseau et ncessite de disposer de plusieurs hbergements gographiquement distants (voir figure 6.1).

160

Cration de bases de donnes

Chapitre Figure 6.1


Redondance et rpartition de charge.

Rpartition & redondance

Hbergement 3

Hbergement 2 Hbergement 3

Recopie des donnes Recopie des donnes


Base originale

Recopie des donnes

Limitations daccs au SGBD


Aprs avoir rsolu les problmes gnraux daccs la machine, abords dans la section prcdente, il convient de restreindre laccs au SGBD. Ces restrictions concernent les autorisations accordes ou non sur les diffrents lments que contient le SGBD, mais aussi permettent de contrler laccs gnral au SGBD. Ces oprations de gestion sont effectues typiquement par ladministrateur de la base de donnes, qui dfinira des identifiants et leur affectera des droits, de manire totalement indpendante du systme dexploitation. Ces informations seront stockes dans le dictionnaire de donnes du SGBD. Il est possible daccder au SGBD, ventuellement distance, sans possder de compte sur la machine qui lhberge. Ladministrateur du SGBD doit donc grer avec le plus grand soin ces identifiants, afin quils deviennent pas un moyen de pntrer dans le systme dexploitation en cas de faille dans le SGBD.

2.1 SQL ET LA GESTION DES UTILISATEURS


Les instructions qui permettent daffecter les droits sont dfinies dans la norme SQL. Comme pour les autres lments de la norme, les diteurs ne les ont pas toujours intgres totalement dans leurs produits. linverse, ils ont souvent ajout des instructions qui ne figurent pas dans la norme pour grer ces droits. Classiquement, pour protger une ressource, on commence par en interdire laccs tous. Puis on dcrit ceux qui sont autoriss lutiliser (utilisateurs). On associe ensuite chaque utilisateur un identifiant (mot de passe) pour viter les emprunts didentit. Dans le principe, SQL ne considre pas rellement la notion dutilisateur pour le SGBD tel quon le conoit au sens dun systme dexploitation. On peut envisager lutilisation de plusieurs identifiants associs au mme nom : cela correspondrait grossirement la possibilit dutiliser des mots de passe spcifiques selon la ressource. Il sagit donc dune logique diffrente de celle qui consiste associer strictement un mot de passe un compte et lui procurer des droits sur les ressources. La norme SQL considre que cest lobjet

Prservation des donnes 161

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

Cration de bases de donnes

Chapitre

2.2 SQL ET LA GESTION DES DROITS


Une fois que lutilisateur est connect au systme, il convient de grer son accs aux donnes. Une pratique courante pour les SGBD est que tout nouvel objet cr une base de donnes par exemple est par dfaut inaccessible tous. Les droits sont distribus ensuite des utilisateurs, des groupes ou des rles. Il existe ensuite une hirarchie entre les diffrents objets du SGBD : une table est comprise dans une base de donnes ; un champ est compris dans une table, etc. Afin de simplifier la gestion, la plupart des SGBD permettent laffectation de droits un objet associ tous les sous-objets qui constituent une branche de la hirarchie.

Droits sur les objets du SGBD


Avec SQL, il est possible de spcifier des droits essentiellement sur les oprations de manipulation de tables (ou de vues considres comme des tables) suivantes : interrogation (SELECT) ; insertion (INSERT) ; mise jour (UPDATE) ; destruction (DELETE) ; rfrence une table (REFERENCE). Les bnficiaires des droits sont les utilisateurs, les groupes ou les rles. Les droits sont accords par ladministrateur du SGBD. Cependant, il est possible de transfrer la facult de redistribuer ces droits un autre utilisateur avec loption WITH GRANT OPTION. Linstruction GRANT permet de raliser lassociation des droits et du bnficiaire. Sa forme gnrale est la suivante :
GRANT <type de droit> ON <objet> TO <nom utilisateur>

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

Prservation des donnes 163

GRANT SELECT ON jaco TO nhop ;

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.

Droits associs aux rles


Linstruction GRANT permet galement de donner un rle un utilisateur ou un ensemble dutilisateurs et sutilise alors de la manire suivante :
GRANT <rle> TO <liste des noms dutilisateur spars par des virgules>

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;

On affecte les rles aux utilisateurs.


GRANT consultation TO pastorius, nhop, miller ; GRANT utilisation TO pastorius, miller ; GRANT gestion TO pastorius;

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

Cration de bases de donnes

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.

2.3 UTILISATION DES VUES


La gestion des droits dans le SGBD, prsents la section prcdente, peut constituer un vritable casse-tte lorsque le nombre dutilisateurs et dobjets augmente. En effet, les droits sur les tables et surtout sur les champs peuvent tre dfinis par linstruction GRANT, mais il devient vite fastidieux et particulirement difficile de les modifier. Un des aspects de cette difficult est le manque de lisibilit de lensemble des permissions. La notion de rle permet de factoriser , ou rassembler, un ensemble de droits sur un ou plusieurs objets. Une approche complmentaire consiste dfinir plus finement les objets sur lesquels on affecte les droits en se servant simplement des vues SQL. Celles-ci permettent de cacher certaines donnes laide de critres de slection prcis, ce qui est impossible raliser dune autre manire. De plus, les vues permettent de masquer aux utilisateurs la complexit de la structure des donnes, leur fournissant ainsi une interface plus commode avec la base de donnes. Le mcanisme de cration des vues a t abord rapidement au chapitre 4. Les donnes ne sont pas stockes et sont recalcules chaque utilisation de la vue. Une vue est le rsultat dune instruction SQL SELECT : les possibilits de dfinition sont donc trs tendues puisquil sagit du cur mme du fonctionnement de SQL. Enfin, il est galement possible de mettre jour les donnes contenues dans les vues sous certaines conditions. Les permissions sur les vues sont ensuite accordes par les instructions de type GRANT utilises prcdemment. Voici quelques exemples de vues qui recourent la base de donnes exemple casse.

Vue utilisant une jointure simple


Le service marketing veut vrifier sil ny a pas de corrlations entre la couleur des vhicules vendus et la ville dans laquelle rsident les clients qui les achtent. Il est inutile de fournir ce service la procdure pour obtenir ces informations qui ncessite de lier les trois tables voiture, vente et client. On cre une vue qui contient uniquement la projection de ces deux informations et qui slectionne les voitures vendues.

Prservation des donnes 165

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 ;

Vue utilisant une jointure plus labore


On souhaite que tous les utilisateurs puissent consulter le catalogue des voitures non encore vendues. Cette liste de voitures est accessible par une requte plus complexe que la prcdente, de type jointure externe. Il sagit dun cas dutilisation dune vue, trs pratique pour les utilisateurs qui nont pas connatre les notions avances de jointure externe.
CREATE VIEW catalogue (NumVoit, Marque, Type, Couleur) AS SELECT voiture.NumVoit, voiture.Marque, voiture.Type, voiture.Couleur FROM voiture LEFT OUTER JOIN vente ON voiture.NumVoit=vente.Numvoit WHERE vente.Numvoit IS NULL;

On donne la permission lutilisateur PUBLIC, cest--dire tous les utilisateurs.


GRANT SELECT ON catalogue TO PUBLIC;

Vue avec possibilit de mise jour


Le service comptabilit doit pouvoir accder aux informations de vente et de clientle afin de facturer et calculer le chiffre daffaires. En outre, ce service a besoin de mettre jour le prix de vente.
CREATE VIEW journal_compta (Date_de_vente, Prix_de_vente, Nom_client, Ville_client) AS SELECT vente.DateVent, vente.Prix, client.Nom, client.Ville FROM vente JOIN client ON vente.NumAch=client.NumAch WITH CHECK OPTION ;

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;

On donne le rle comptabilit aux utilisateurs pastorius et miller.


GRANT comptabilite TO pastorius, miller

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

Cration de bases de donnes

Chapitre erreurs de manipulation ou celles lies aux erreurs dans le traitement des donnes, par exemple en cas de panne matrielle.

3.1 ACCS CONCURRENT AUX DONNES


La section prcdente aborde la dfinition des accs et des permissions sur les diffrents objets grs par le SGBD. Implicitement, cela signifie que plusieurs utilisateurs ou applications peuvent accder aux donnes en mme temps. De surcrot, la plupart des machines sont connectes un rseau, ce qui augmente encore le nombre potentiel dutilisateurs simultans.

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.

Prservation des donnes 167

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

Nhop : promotion et modification du prix de vente (Prix = Prix 100)

Prix de vente 9 600

Pastorius : augmentation du prix de vente

Prix de vente 10 185

constat Miller : vrification du prix de vente attendu Prix de vente 10 085

Prix de vente 10 185

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

Cration de bases de donnes

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.

3.2 MCANISME DES TRANSACTIONS


Pour rsoudre les problmes daccs concurrents vus prcdemment, les SGBD proposent aux utilisateurs un outil que lon nomme une transaction. Lide est de considrer un ensemble dinstructions comme une seule instruction. Lensemble dinstructions est dit unitaire ou atomique.

Proprits des transactions


La notion datomicit peut tre dcrite en ces termes : Soit le SGBD est capable dexcuter toutes les instructions qui composent une transaction et il effectue les mises jour provoques par ces instructions. Soit il ny parvient pas et il remet la base de donnes dans ltat cohrent prcdent le dbut de lexcution des instructions de la transaction.

Prservation des donnes 169

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.

Ralisation des transactions dans les SGBD


Pour mettre en uvre les transactions, le SGBD doit offrir lexclusivit daccs aux donnes ainsi que la possibilit dannuler des modifications effectues. Afin de garantir laccs exclusif aux donnes, le SGBD utilise les verrous vus prcdemment. Ces mcanismes sont associs des algorithmes de protection sophistiqus afin de prvenir les problmes des mthodes de verrouillage. La possibilit de revenir en arrire repose sur lutilisation dun journal de transactions. Pour ce faire, le SGBD garde une trace de toutes les requtes de la transaction et des donnes qui sont modifies par ces instructions. Ce mcanisme est identique celui qui est utilis pour les systmes de fichiers modernes dans les systmes dexploitation. Puisque la plupart des critures se font en mmoire pour gagner du temps, le systme de fichiers nest pas forcment cohrent en cas de panne de courant qui entrane la perte de toutes les informations se trouvant en mmoire. On conserve donc un journal de lensemble des lectures et critures afin de pouvoir reconstituer un systme cohrent. En utilisant ce journal, partir dun tat courant du systme, on est capable de rexcuter les instructions qui nont pu ltre effectivement ou on revient en arrire si ce nest pas possible. La description faite ci-dessus est videmment simpliste par rapport la ralit plus complexe des SGBD. Les mthodes de verrouillage implmentes dans ces derniers sont bien plus labores que celles prsentes ici. Il en est de mme pour les mcanismes de journalisation qui disposent de plusieurs niveaux.

Diffrents niveaux de transaction


La norme SQL fixe plusieurs degrs de qualit pour les transactions : on parle de niveaux disolation. Cest--dire quune transaction pourra tre rendue plus ou moins permable aux autres transactions. Les niveaux standard sont les suivants :

170

Cration de bases de donnes

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.

Syntaxe SQL des transactions


Linstruction pour dbuter une transaction est START TRANSACTION. La transaction prendra fin par lune des instructions suivantes : COMMIT. Les instructions effectues depuis START TRANSACTION sont valides. ROLLBACK. Les instructions effectues depuis START TRANSACTION sont annules. Voici un exemple dinsertion et de mise jour dans la base de donnes casse que lon annule ensuite :
#Dmarrage de la transaction START TRANSACTION ; #Insertion dun tuple dans la table client INSERT INTO client VALUES (6,'Laetitia',34,'Paris','F'); #Mise jour des donnes de prix (augmentation de 5 %) UPDATE vente SET Prix=Prix*1.05 ; #Annulation des modifications faites depuis START TRANSACTION ROLLBACK ;

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 ;

Prservation des donnes 171

Points de retour dans les transactions


Les instructions contenues dans une transaction sont considres par le SGBD comme unitaires , cest--dire quelles sont excutes dun seul bloc ou ne sont pas excutes. Linstruction ROLLBACK annule toutes les instructions effectues depuis linstruction START TRANSACTION. Cependant, il est possible de diviser cet ensemble dinstructions en sousensembles par la dfinition de points de retour utiliss par linstruction ROLLBACK. Au lieu dannuler les instructions excutes depuis START TRANSACTION, on revient ltat de la base de donnes depuis le point dfini par linstruction SAVEPOINT (voir figure 6.3).
#Dmarrage de la transaction START TRANSACTION ; #Insertion dun tuple dans la table client INSERT INTO client VALUES (8,'Annabelle',29,'Paris','F'); # Dfinition dun point de retour que lon nomme UN SAVEPOINT UN #Mise jour des donnes de prix (augmentation de 5 %) UPDATE vente SET Prix=Prix*1.05 ; #Destruction des tuples dont le champ Ville vaut Paris dans la table client DELETE FROM client WHERE Ville=Paris; #Annulation des modifications faites depuis le point UN ROLLBACK TO UN ;

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 ;

INSERT INTO client VALUES (8,'Annabelle',29,'Paris','F');

SAVEPOINT UN

UPDATE vente SET Prix=Prix*1.05 ;

DELETE FROM client WHERE Ville=Paris;

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

Cration de bases de donnes

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.

4.1 SYNTAXE GNRALE POUR CRER ET DTRUIRE UN TRIGGER


Linstruction, normalise par la norme SQL, est de la forme gnrale suivante :
CREATE TRIGGER Nom du trigger Moment o le trigger est excut Opration concerne ON Nom de la table FOR EACH ROW(ou STATEMENT) BEGIN Instructions END

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.

Prservation des donnes 173

4.2 EXEMPLES DUTILISATION DUN TRIGGER


Contrle de la forme du contenu des champs
Pour le formatage, on veut imposer que les noms dune ville dans la table client soient transforms en majuscules avant dtre insrs. On fait rfrence ici la nouvelle table NEW que lon modifie avant linsertion.
CREATE TRIGGER ville_majuscule BEFORE INSERT ON client FOR EACH ROW BEGIN SET NEW.Ville=UPPER(NEW.Ville) ; END

Modification automatique du contenu dun champ


Les triggers permettent, par exemple, de complter le mcanisme dintgrit rfrentielle par des contrles plus fins et la dfinition des actions associes ces derniers. On considre lexemple de la base de donnes casse. Si le prix de vente est suprieur 40 000 lors dune insertion de donnes dans la table vente, on suppose que la personne a saisi par erreur le prix en francs et non pas en euros. On effectue automatiquement la conversion des francs en euros. L encore, on modifie les donnes de la table NEW qui contient celles que lon va insrer.
CREATE TRIGGER conversion BEFORE INSERT ON vente FOR EACH ROW BEGIN IF New.Prix> 40000 THEN SET NEW.Prix=NEW.Prix/6.5596 ; END IF; END

Mise jour dautres tables


On peut galement provoquer la mise jour dautres tables laide dun trigger. Si lon ajoute un champ compte la table client qui reprsente ltat du solde de son compte vis-vis de lentreprise, on veut pouvoir mettre jour automatiquement le champ compte de lacheteur lors de linsertion dune opration de vente. cette occasion, on soustrait le prix de vente de la voiture du montant du compte du client. Cest la seule manire de raliser cette opration de modification dune autre table lors dune simple insertion.
# Ajout dun champ compte la table client ALTER TABLE client ADD COLUMN compte INT ; # Cration du trigger CREATE TRIGGER compte BEFORE INSERT ON vente FOR EACH ROW BEGIN UPDATE client SET client.Compte=client.Compte-NEW.Prix WHERE client.NumAch=New.NumAch ; END # Ajout dune vente dans la table vente INSERT INTO vente VALUES (6, '2005-03-01',50000,2,5)

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

Cration de bases de donnes

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.

Prservation des donnes 175

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

DISPONIBILIT DES DONNES


Quel type darchitecture permet de garantir en mme temps la haute disponibilit des donnes et de disposer de sauvegarde ? Quels sont les inconvnients de ce systme ? La haute disponibilit ncessite que laccs aux donnes soit dune part permanent et dautre part performant. Afin de garantir que les donnes soient disponibles en permanence, on doit effectuer des copies intervalles rguliers des donnes qui proviennent dune base de donnes primaire vers des bases de sauvegarde secondaires . En cas de panne du primaire, on peut basculer rapidement vers lun des secondaires. Lidal est de disposer de plusieurs secondaires dans des lieux gographiquement loigns, situs sur des rseaux (informatiques) diffrents. Disposer en outre dun accs performant suppose que lon utilise galement les secondaires pour faire de la rpartition de charge. Le systme de rpartition choisi doit tenir

176

Cration de bases de donnes

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

NIVEAUX DUTILISATION DUNE BASE DE DONNES


Lors de la conception dune base de donnes, on doit envisager ds le dbut les diffrentes catgories dutilisateurs qui vont lutiliser. On considre lexemple complet livraison de pizzas trait au chapitre 5, Du langage parl SQL . Quels niveaux dutilisation des donnes doit-on prvoir ? On se limite aux grandes catgories. La notion dutilisateur ne reprsente pas forcment une personne physique ; il sagit le plus souvent dapplications qui disposent ou non de droits sur certaines donnes. En premire approche, on peut distinguer trois grandes catgories dutilisateurs de la base de donnes. Les clients peuvent consulter les informations les concernant ainsi que le catalogue des pizzas disponibles avec leur prix et leur composition. Lactivit courante, qui par consquent va gnrer les mises jour les plus frquentes, est la commande de pizzas. Les utilisateurs concerns sont les employs qui mettent jour les donnes de la table commande, mais galement celles de la table client pour crer de nouveaux clients le cas chant. Ils ont accs en lecture toutes les donnes des autres tables. Enfin, les gestionnaires de lactivit doivent pouvoir mettre jour toutes les informations de gestion : en particulier, celles sur les pizzas, les clients, les livreurs et les voitures utilises. En revanche, on peut considrer quils nont pas besoin de modifier les informations concernant les commandes, mais quils doivent pouvoir y accder en lecture.

Prservation des donnes 177

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

Lecture/ Lecture/ Lecture/ criture criture criture

EXERCICE 4

GESTION DES DROITS


Comment reprsenter pratiquement les catgories identifies lexercice prcdent dans un SGBD ? crivez les instructions permettant de le faire. Si le SGBD le supporte, la solution la plus lgante est dutiliser les rles. On cre un rle par catgorie et on lui affecte les permissions. Il suffira ensuite de donner ce rle aux utilisateurs ou aux applications concernes. Dans cet exemple, on a surtout cherch mettre en vidence tous les droits distribuer. Il existe des notations plus concises. Cration du rle client et distribution des droits. CREATE ROLE client;
GRANT GRANT GRANT GRANT GRANT SELECT SELECT SELECT SELECT SELECT ON ON ON ON ON pizza TO client; compose TO client; ingrdient TO client; tarification TO client ; client TO client;

Cration du rle employe et distribution des droits. CREATE ROLE employe;


GRANT GRANT GRANT GRANT GRANT GRANT GRANT GRANT GRANT GRANT GRANT GRANT GRANT GRANT SELECT SELECT SELECT SELECT SELECT SELECT SELECT UPDATE DELETE INSERT SELECT UPDATE DELETE INSERT ON ON ON ON ON ON ON ON ON ON ON ON ON ON pizza TO employe ; compose TO employe ; ingrdient TO employe ; tarification TO employe ; vehicule TO employe ; livreur TO employe ; client TO employe ; client TO employe; client TO employe; client TO employe; commande TO employe ; commande TO employe; commande TO employe; commande TO employe;

Cration du rle gestionnaire et distribution des droits. CREATE ROLE gestionnaire;


GRANT GRANT GRANT GRANT GRANT GRANT GRANT SELECT SELECT UPDATE DELETE INSERT SELECT UPDATE ON ON ON ON ON ON ON commande TO gestionnaire ; client TO gestionnaire; client TO gestionnaire; client TO gestionnaire; client TO gestionnaire; livreur TO gestionnaire; livreur TO gestionnaire;

178

Cration de bases de donnes

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;

gomez et pattitucci sont des employs.


GRANT employe TO gomez, pattitucci;

pastorius est un gestionnaire.


GRANT gestionnaire TO pastorius;

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.

Prservation des donnes 179

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;

On cre une vue partir de cette requte :


CREATE VIEW commande_livreur AS 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;

On distribue les droits de lecture lutilisateur comptabilit


GRANT SELECT ON commande_livreur TO comptabilite;

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;

On distribue les droits de lecture lutilisateur personnel.


GRANT SELECT ON retard_livreur TO personnel;

Le service du personnel a besoin galement dutiliser la prcdente vue :


GRANT SELECT ON commande_livreur TO personnel;

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;

On distribue les droits de lecture sur cette vue lutilisateur personnel:


GRANT SELECT ON retard_commande_livreur TO personnel;

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

Cration de bases de donnes

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 ;

Prservation des donnes 181

Exercices

#Annulation des modifications faites depuis le point COEFF_NAINE ROLLBACK TO COEFF_NAINE;

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

Cration de bases de donnes

Codages de caractres et bases de donnes


Du code Morse au code ASCII : un rapide historique du codage des caractres

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

Codages de caractres et bases de donnes 183

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 &eacute; .

Tables ISO-8859 et codages propritaires


Le systme de codage des caractres absents de la table ASCII vue plus haut nest gure commode. Afin quil soit possible de reprsenter dautres langues, le codage ASCII a t tendu. Le nombre de caractres disponibles a augment en passant un codage 8 positions, ce qui donne 256 (28) possibilits. Les constructeurs ont propos leurs propres extensions de ASCII. Par exemple, IBM avec EBCDIC et DEC avec la norme VT200 . Enfin, lISO (Organisation internationale de normalisation) a dfini une normalisation de lextension ASCII pour les langues europennes. Lennui est que lon ne peut reprsenter tous les caractres utiliss dans les langues latines, puisque leur nombre est limit 256. Plusieurs tables ont donc t dfinies, le critre choisi pour regrouper les jeux de caractres est fond sur la proximit gographique et commerciale. On dispose de 16 tables qui seront nommes ISO-8859-n, n pouvant varier de 1 15. Lavantage est que les 128 premiers caractres sont identiques ceux de lASCII. La compatibilit avec lexistant est donc assure. La table dfinie pour lEurope occidentale est la table ISO-8859-1, nomme galement Latin1 , laquelle il manque videmment quelques caractres pour tre exhaustive. On peut citer labsence du fameux franais ou du signe . Pour pallier ces manques, une version modifie de Latin1 a t dfinie : Latin9 ou ISO8859-15. Elle est toutefois peu rpandue, probablement en raison du temps important qua ncessit sa dfinition. La norme ISO-8859 dispose de tables pour le codage dautres langues comme le grec (ISO-8859-7), le cyrillique (ISO-8859-5), etc. Les langues extrmes-orientales utilisent beaucoup plus de 256 caractres et codent les caractres sur plus de 8 positions. Une version allge du Japonais peut toutefois tre code par une extension de ASCII sur 8 positions : JIS X. Dans un souci de simplification, les constructeurs ont conu des extensions de ces normes. En ce qui concerne lEurope occidentale, on peut citer lextension de ISO-8859-1, ralise par Microsoft (Windows-1252), qui remplace certains caractres de contrle de la table Latin1 pour y stocker les caractres manquants cits plus haut. Apple utilisait un codage spcifique, MacRoman , incompatible avec les autres.

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

Cration de bases de donnes

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.

Codages de caractres et bases de donnes 185

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

Plan Multilingue Base

Baudot (5 positions)

UNICODE -SO-10646 I
(21 positions)

ISO 8859 (8 positions) BCD- IBM (6 positions)


ISO-8859-1 (Latin1) ISO-8859-15 (Latin9) ISO-8859-7 (Grec)

UTF 8 (octets) UTF 16 (doubles octets)


UTF-7, UTF-32, UCS-2.

ASCII (7 positions)

Windows-1251 (8 positions)

JIS X Japonais (8 positions)

MacRoman (8 positions)

186

Cration de bases de donnes

Codage dans une base de donnes et ordre de tri


Les bases de donnes contiennent des donnes textuelles. On peut donc trouver dans une base de donnes tous les codages de caractres prsents plus haut du simple ASCII Unicode.

A
Annexe

Comment choisir le codage de caractre employer au moment de la conception de la base de donnes ?


Une des premires proccupations est de choisir le codage de caractre qui conviendra aux donnes entres. Si lon utilise les tables de la norme ISO-8859, il faut dcider laquelle est convenable en fonction du contenu futur. Le problme ne se pose videmment pas sil ne se trouve aucun diacritique dans les donnes. Une autre question est de savoir ce que les utilisateurs feront des donnes extraites de la base. Par exemple, sont-ils capables dutiliser un format de type Unicode ou ont-ils recours exclusivement Windows-1252 ? De mme, disposent-ils de logiciels clients capables dinterroger directement la base de donnes en Unicode ou en IS0-8859-15 par exemple ? Un dernier critre de choix pourrait tre la place occupe. Dans le cas du choix dUnicode, si lon emploie des langues latines, UTF-8 est plus intressant que UTF-16. Dans le cas de langues asiatiques, UTF-16 est plus appropri. Le plus conomique est sans doute la norme ISO-8859, mais cela est valable condition que la table utilise soit suffisamment complte pour les donnes considres. Un bon compromis est la norme Unicode code en UTF-8, qui permet de reprsenter tous les caractres tout en tant conome en place.

Ordre de tri et collation


Le codage de caractre consiste associer un code une lettre. Par exemple on affecte le code 1 la lettre a , le code 2 la lettre b , et ainsi de suite. Pour trier, il suffit alors de mettre les lettres dans lordre des codes. Que se passe-t-il si, dans notre code, la lettre a est code en majuscules et en minuscules ? Si la lettre A a le code 30 dans notre codage, le tri par ordre croissant des numros va se faire dabord par lettres minuscules puis par lettres majuscules. De mme, si notre codage affecte le numro 50 la lettre accentue , elle va se retrouver la suite des majuscules et non pas au mme niveau que la lettre a . Afin de pouvoir effectuer le tri correctement, il faut disposer dune table de correspondance qui indique que les codes 1, 30 et 50 de notre codage doivent se trouver au mme niveau dans le rsultat du tri. On appelle cette table de correspondance la collation ; elle sera en gnral diffrente suivant la langue employe.

Choix du jeu de caractres et de la collation avec SQL


On doit donc effectuer au moment de la cration de la table le choix du codage de caractres employer ainsi que la collation lui appliquer. Le choix du jeu de caractres se fait par le mot cl CHARACTER SET suivi du nom du jeu de caractres.
Nom_client CHAR(20) CHARACTER SET Unicode ;

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.

Codages de caractres et bases de donnes 187

Nom_client NATIONAL CHARACTER(20) ;

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

Cration de bases de donnes

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

Base de donnes book Page 191 Lundi, 5 juin 2006 3:33 15

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

Base de donnes book Page 192 Lundi, 5 juin 2006 3:33 15

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

Base de donnes book Page 193 Lundi, 5 juin 2006 3:33 15

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

Cration & de bases exercices corrigs de donnes


Cet ouvrage propose une dmarche progressive ceux qui veulent concevoir un systme dinformation robuste et volutif en vitant les cueils classiques qui conduisent rendre les donnes inutilisables. Toutes les tapes de la ralisation dune base de donnes, de lanalyse pralable au choix du codage des caractres, sont tudies et illustres par des exemples. Le livre prsente plus particulirement la modlisation du monde rel au moyen du modle entit-association, le passage au modle relationnel et la mise en uvre du systme ainsi conu laide du langage SQL. Une tude de cas rcapitulative permet ensuite dappliquer les notions prsentes dans les chapitres prcdents. Le dernier chapitre traite de la scurisation des donnes, notament au moyen des transactions et des triggers. Les exercices, qui occupent la moiti du livre, sont intgralement corrigs an que le lecteur mette progressivement en uvre ses connaissances. Par ailleurs, les donnes et les scripts SQL utiliss tant pour les exemples que pour les exercices sont disponibles ladresse www.pearsoneducation.fr. Le livre sadresse aux tudiants de premier et de second cycles (IUT, BTS, universits et coles dingnieurs) qui dbutent lapprentissage des bases de donnes. Il sera galement utile aux professionnels qui veulent mettre en place une base de donnes, mme de taille modeste.

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.

Dans la mme collection :


Algorithmique, Applications en C, Jean-Michel Lry Algorithmique en C++, Jean-Michel Lry Algorithmique en Java 5, Jean-Michel Lry Architecture de lordinateur, Emmanuel Lazard Java 5, Robert Chevallier LateX, Jean-Cme Charpentier, Denis Bitouz Le langage C, Jean-Michel Lry Le langage C++, Marius Vasiliu Linux, Jean-Michel Lry Mathmatiques discrtes appliques linformatique, Rod Haggarty SQL, Frdric Brouard, Christian Soutou Systmes dexploitation, Bart Lamiroy, Laurent Najman, Hugues Talbot Rseaux, Dominique Seret, Danile Dromard UML 2, Benot Charroux, Aomar Osmani et Yann Thierry-Mieg

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