Systmes de Gestion

Bases de Donnes

de

Editeurs successifs :
Jean-Pierre CHEINEY, Philippe PICOUET, Jean-Marc SAGLIO,
Talel ABDESSALEM

Extraits pour le lUE INF225

Septembre 2011

page 1

page 2

TABLE DES MATIERES

Table des Matires ................................................................................................................ 3

ChapitreS 1 & 2 : INTRODUCTION AUX bases de donnes ............................................ 7
I.1.

Pourquoi des bases de donnes ? ........................................................................ 7

I.2.
Le principe d'un modle de donnes ................................................................ 10
I.2.1.
Le modle entit-association ....................................................................... 11
I.2.2.
Modles, langages et schmas ..................................................................... 13
I.3.

Prcisions sur les niveaux de description ........................................................ 13

I.4.
Du modle Entit-Relation a UML .................................................................. 15
I.4.1.
Entits et individus ou classes d'objets ........................................................ 15
I.4.2.
Liens, rles et cardinalits ........................................................................... 16
I.4.3.
Associations identifiantes et/ou entits faibles ............................................ 18
I.4.4.
Agrgations .................................................................................................. 19
I.4.5.
Gnralisation et spcialisation ................................................................... 20
I.4.6.
Autres concepts............................................................................................ 20
I.4.7.
Demain, un seul modle conceptuel? .......................................................... 21
I.5.
Les objectifs des SGBD ..................................................................................... 21
I.5.1.
Offrir diffrents niveaux d'abstraction......................................................... 21
I.5.2.
Assurer l'indpendance physique des donnes ............................................ 22
I.5.3.
Assurer l'indpendance logique des donnes .............................................. 22
I.5.4.
Contrler la redondance des donnes .......................................................... 23
I.5.5.
Permettre tout type d'utilisateur de manipuler des donnes...................... 23
I.5.6.
Assurer l'intgrit des donnes .................................................................... 23
I.5.7.
Assurer le partage des donnes .................................................................... 24
I.5.8.
Assurer la scurit des donnes ................................................................... 24
I.5.9.
Optimiser l'accs aux donnes ..................................................................... 24
I.6.

Conclusions......................................................................................................... 25

I.7.Bibliographie GENERALE ..................................................................................... 25

Chapitre 2 : Le modle relationnel .................................................................................... 27
III.1.
Le modle relationnel .................................................................................... 27
III.1.1. Une premire approche du relationnel......................................................... 28
III.1.2. La construction du modle relationnel ........................................................ 28
III.1.3. Une manipulation ensembliste des donnes ................................................ 31
III.2.
L'algbre relationnelle .................................................................................. 32
III.2.1. Les oprateurs ensemblistes ........................................................................ 32
III.2.2. Les oprateurs relationnels .......................................................................... 35
III.2.3. Oprateurs de base et oprateurs drivs ..................................................... 38
III.2.4. Des exemples de requtes ............................................................................ 38
III.2.5. Les arbres algbriques et l'optimisation ...................................................... 39
III.3.

Conclusions..................................................................................................... 46

III.4.

Rfrences....................................................................................................... 47

page 3

Chapitre 4 : Les langages relationnels .............................................................................. 49

IV.1.
Le standard SQL ........................................................................................... 49
IV.1.1. Elments d'un langage pour les SGBD relationnels .................................... 50
IV.1.2. Expression des oprations relationnelles ..................................................... 51
IV.1.3. Sous-questions, prdicats quantifis, composition de questions ................. 55
IV.1.4. Fonctions et groupements ............................................................................ 57
IV.1.5. Mises jour ................................................................................................. 59
IV.1.6. Le langage de dclaration de donnes ......................................................... 60
IV.1.7. Intgration d'un langage de manipulation de donnes dans un langage de
programmation............................................................................................................. 61
IV.2.
Autres langages relationnels ......................................................................... 65
IV.2.1. QUEL........................................................................................................... 65
IV.2.2. Query By Example (QBE) ........................................................................... 65
IV.3.

Conclusions..................................................................................................... 67

IV.4.

Annexe : smantique et syntaxe de SQL ..................................................... 67

IV.5.

Rfrences....................................................................................................... 69

Chapitre 5 : Bien concevoir une base de donnes ............................................................. 71

V.1. La thorie de la normalisation .......................................................................... 73
V.1.1.
Les dpendances fonctionnelles .................................................................. 74
V.1.2.
Dpendance fonctionnelle lmentaire ........................................................ 76
V.1.3.
Graphe des dpendances fonctionnelles ...................................................... 76
V.1.4.
Fermeture transitive ..................................................................................... 77
V.1.5.
Couverture minimale ................................................................................... 78
V.1.6.
Cl d'une relation ......................................................................................... 79
V.1.7.
Dcomposition des relations ........................................................................ 79
V.2. Les trois premires formes normales ............................................................... 80
V.2.1.
La premire forme normale 1FN ................................................................. 80
V.2.2.
La deuxime forme normale 2FN ................................................................ 80
V.2.3.
La troisime forme normale 3FN ................................................................ 81
V.2.4.
Algorithme de dcomposition en troisime forme normale ........................ 81
V.2.5.
Insuffisance de la troisime forme normale ................................................ 82
V.3. La quatrime forme normale............................................................................ 83
V.3.1.
Les dpendances multivalues..................................................................... 83
V.3.2.
Quatrime forme normale ............................................................................ 84
V.4. La cinquime forme normale............................................................................ 85
V.4.1.
Les dpendances de jointure ........................................................................ 86
V.4.2.
Cinquime forme normale ........................................................................... 86
V.5.

Conclusions......................................................................................................... 87

V.6.

Rfrences........................................................................................................... 87

Chapitre 6 : La protection de l'information....................................................................... 89

VI.1.
Les vues externes ........................................................................................... 90
VI.1.1. Les objectifs : voir le monde comme il n'est pas ! ...................................... 90
VI.1.2. Le relationnel simplifie les vues .................................................................. 91
VI.2.
Manipulation au travers des vues ................................................................ 93
VI.2.1. Consultation au travers des vues ................................................................. 93
VI.2.2. Influence sur l'optimisation des requtes ..................................................... 94

page 4

VI.2.3.

Mise jour travers les vues....................................................................... 96

VI.3.
Confidentialit ................................................................................................ 97
VI.3.1. Autorisations sur une relation ou sur une vue ............................................. 98
VI.3.2. La cession de droits ..................................................................................... 99
VI.4.
Intgrit smantique ...................................................................................... 99
VI.4.1. Les diffrents types de contraintes .............................................................. 99
VI.4.2. Comment dfinir une contrainte d'intgrit ? ............................................ 101
VI.4.3. Comment regrouper (classer) les contraintes ?.......................................... 101
VI.4.4. Contraintes d'intgrits et transactions bases de donnes.......................... 101
VI.5.

Conclusions................................................................................................... 102

VI.6.

Rfrences..................................................................................................... 102

page 5

page 6

CHAPITRES 1 & 2 : INTRODUCTION AUX BASES DE DONNEES

Les Bases de Donnes occupent aujourd'hui une place de plus en plus importante dans les systmes
informatiques. Les Systmes de Gestion de Bases de Donnes (SGBD) remplacent les anciennes
organisations o les donnes, regroupes en fichiers, restaient lies une application particulire. Ils
assurent le partage, la cohrence, la scurit d'informations qui, de plus en plus, constituent le cur de
l'entreprise. Des premiers modles hirarchique et rseau au modle relationnel, du mainframe au
micro, du centralis au rparti, les ambitions des SGBD augmentent d'anne en anne. Mais quoi
peuvent bien ressembler ces logiciels de plusieurs dizaines de milliers de lignes de code qui grent
avec une relative facilit quelques milliards d'octets d'information ?

I.1.

POURQUOI DES BASES DE DONNEES ?

Comme c'est le cas pour de nombreuses innovations technologiques, une importante pression des
besoins est l'origine de l'mergence des Systmes de Gestion de Bases de Donnes. Dans
l'environnement informatique traditionnel des gros systmes d'exploitation, le seul mode de gestion de
donnes reste le gestionnaire de fichiers. Les donnes traites par une application (gestion de la paie,
des stocks, de la comptabilit, des locaux) demeurent spcifiques cette application.

L'organisation des donnes en fichiers telle qu'elle est traditionnellement conue rpond des besoins
prcis : les services utilisent des informations le plus souvent distinctes pour des traitements diffrents.
Pour cette raison, chaque quipe de l'entreprise dispose de ses propres fichiers de donnes o ne
figurent que les informations la concernant. La forme sous laquelle cette information est stocke
dpend de facteurs nombreux et varis : matriel disponible, bonne volont et harmonisation des
quipes de dveloppement (choix du langage de programmation, choix de la structure de stockage) ;
surtout, les accs l'information dterminent le plus souvent l'organisation choisie pour les donnes :
le choix des informations regroupes dans un mme fichier, le choix de l'organisation du fichier
(squentiel, alatoire).

page 7

Dans ce contexte, on constate l'apparition de nombreuses difficults :

Redondance des donnes

La rptition en diffrents endroits de donnes identiques pose de difficiles problmes lors des
mises jour ; chaque modification doit tre rpercute sur toutes les occurrences de l'objet
concern. Par exemple, le changement de nom d'un employ (c'est frquemment le cas lors des
mariages) doit tre effectu aussi bien au service du personnel qu' la comptabilit, etc.
Difficult d'accs aux donnes
L'accs aux donnes ncessite l'intervention d'un informaticien (ncessit de connatre la machine
o rsident les informations, les structures utilises pour stocker ces informations, les chemins
d'accs disponibles). La seule manipulation possible d'informations stockes sur fichiers est une
manipulation "programme" ; les informations sont en effet dcrites de faon trs physique et ne
permettent pas un niveau d'abstraction suffisant pour envisager une interrogation directe et
interactive par un utilisateur final non spcialiste.
Problmes de partage des donnes
Le problme est bien connu des concepteurs de systmes d'exploitation : comment ragir
plusieurs ouvertures simultanes d'un mme fichier. Des problmes identiques se posent ds que
plusieurs utilisateurs dsirent effectuer des modifications sur les mmes donnes. De surcrot,
l'existence de plusieurs occurrences d'une mme donne en plusieurs endroits (plusieurs fichiers
diffrents) provoque une complexit accrue si le systme doit garantir la cohrence pour des
utilisateurs manipulant la mme information au mme moment.
Risques d'incohrence
Des liens smantiques existent trs souvent entre les donnes : le poste d'un employ, figurant
dans le fichier du service du personnel, n'est pas sans rapport avec le salaire qui lui est vers par la
comptabilit. Pourtant la modification de l'un n'entrane pas automatiquement celle de l'autre. De
telles situations ncessitent souvent force courrier et coups de tlphone ; des incohrences
apparaissent trop frquemment du fait de la difficult et du cot qu'implique le contrle de
"contraintes d'intgrit" liant les donnes entre elles.

page 8

Problmes de scurit
Garantir de la scurit physique de l'information est une des tches de base d'un systme
informatique. Qu'arrive-t-il si une panne interrompt un programme augmentant tous les salaires de
3% ? Combien de modifications ont t prises en compte ; o reprendre le travail ? La prsence de
la mme information en plusieurs exemplaires n'est videmment pas de nature faciliter la tche
du SGBD et des programmes de reprise aprs panne. De mme, la confidentialit de l'information
est plus facile assurer avec une seule occurrence de l'information protger.
Manque de portabilit des applications
Que se passe-t-il lorsque l'on change de systme d'exploitation ou de support de stockage ? Dans
la plupart des cas, les applications dveloppes sont si fortement lies aux possibilits propres du
systme et du gestionnaire de fichiers qu'il est parfois aussi difficile de les actualiser que de les
rcrire entirement. Si la normalisation des langages de programmation est de plus en plus
frquente, les accs aux fichiers dpendent la plupart du temps de la machine ; le manque de
sparation entre le code de l'interface et celui du traitement des donnes interdit de faire une
simple modification du code.
Problmes de maintenance
Enfin, quand la modification de la structure des donnes manipules devient ncessaire, il faut
assurer le passage des donnes depuis les anciennes vers les nouvelles structures choisies et
presque toujours rcrire compltement les programmes d'application dont la plupart ralisent
pourtant la mme opration qu'auparavant.

Au total, les organisations traditionnelles des donnes sous la forme de fichiers lis aux applications
prsentent de srieux inconvnients ds qu'un ensemble de programmes manipulent et partagent des
informations qui ne sont pas compltement indpendantes. Le dfaut de base des organisations
traditionnelles provient du fait que les donnes et les traitements ne sont pas explicitement spars.
L'ancienne vision du monde faisait en effet tourner les donnes autour des traitements (tout comme le
soleil tournait autour de la terre !). Aujourd'hui, on sait que le centre du monde est constitu par
l'information manipule (les donnes dont elle est constitue) : le centre c'est le systme d'information
de l'entreprise !

Une bonne solution ces problmes passe par le regroupement et l'unicit des donnes, ainsi que par la
centralisation des moyens de gestion de ces donnes. L'administration unique et centralise des
donnes l'chelle de l'entreprise garantit la cohrence de l'information et permet l'indpendance des

page 9

programmes et des donnes . Elle est mise en uvre par un Systme de Gestion de Bases de Donnes
(SGBD).

L'ensemble de toutes les donnes peut tre regroup sous l'appellation de base de donnes. Cette base
de donnes reprsente l'information de l'entreprise. Elle existe indpendamment de l'usage qu'en font
les programmes d'application ou les utilisateurs finals. L'information doit donc pouvoir tre dcrite
indpendamment de l'usage qui en est fait. Cette description ncessite un modle de donnes, c'est
dire un ensemble de concepts et de rgles assez gnraux et riches de smantique pour pouvoir donner
de faon formelle un schma de la structure permanente de cette information.

Le systme logiciel qui met en uvre le modle de donnes (qui stocke les donnes, gre les accs, les
droits des utilisateurs, et plus gnralement traite au mieux l'ensemble des problmes que nous venons
d'voquer) forme vritablement le SGBD.

I.2.

LE PRINCIPE D'UN MODELE DE DONNEES

Ds 1965 apparat l'ide de distinguer les donnes de leurs traitements. Cela exige une description
pralable des donnes qui doit tre fournie par les utilisateurs.

Pour bien comprendre cela, observons le travail que devait raliser le programmeur et que le systme
doit maintenant prendre en charge : le programmeur devait transformer en structures informatiques une
certaine vision de la ralit (par exemple une personne est stocke sous la forme d'un enregistrement
compos d'un champ "numro de scurit sociale", d'un champ "nom", d'un champ "prnom" et d'un
champ "date de naissance"). C'est prsent le SGBD qui va effectuer ce travail : il recevra en entre une
description abstraite des donnes. Disposant de rgles dclares par l'administrateur, il choisira la
faon de les stocker et de grer les accs.

Les outils offerts par le SGBD pour dcrire les donnes qu'il aura stocker repose sur un ensemble de
rgles et de concepts permettant de dcrire le monde rel (en fait une toute petite partie du monde
rel : celle sur laquelle portent les traitements). Ces rgles et concepts constituent un modle de
donnes. Le modle entit-association peut ici tre donn titre d'exemple.

page 10

I.2.1.

Le modle entit-association

Ce modle de donnes correspond une modlisation assez naturelle du monde rel. Le modle se
compose de trois concepts lmentaires : l'entit, l'association et les contraintes portant sur ces
associations.

Une entit peut tre :

-

un objet du monde rel ;

des donnes composes ;

un ensemble d'entits.

Une association peut tre :

-

un lien entre entits ;

un ensemble d'associations.

Une contrainte peut tre :

-

une proprit prcisant le nombre d'entits qu'une association peut unir. On parle alors de
cardinalit d'association qui peut tre de type 1-1, 1-N, ou N-M ;

une proprit propre l'association et sans rapport avec les entits rapproches par ces
associations.

Ce modle est mis en uvre par un langage de description. Ce langage est ici graphique :

page 11

reprsente un ensemble d'entits (type d'entit)

reprsente un ensemble d'associations

(type d'association)

reprsente un attribut (type d'attribut)

reprsente une liaison entre attribut et entit

ou entre entit et association

Exprimons avec ce modle la ralit suivante : des nageurs, dont les caractristiques sont un nom, un
prnom et une qualit, prennent des bains d'une certaine dure une certaine date, sur certaines plages
dont les caractristiques sont le nom le la plage, la rgion et la pollution :
Le schma entit/association est le suivant :
NOM

PRNOM

DATE

BAIGNEUR

a pris un bain

QUALIT

DURE

NOMP

RGION

PLAGE

POLLUTION

Les contraintes dfinir (dont les cardinalits d'association) posent, par exemple, les problmes
suivants :

un baigneur peut-il prendre plusieurs bains? sur des plages diffrentes?

une ou plusieurs personnes peuvent-elles se baigner sur une plage trs pollue ?

autorise-t-on les mauvais nageurs se baigner sur une plage des Landes ?

page 12

I.2.2.

Modles, langages et schmas

Plus gnralement, nous dirons que le modle de donnes est un mode de formalisation du monde rel.
Il doit permettre la description et la reprsentation :

des entits et des donnes qui les constituent ;

des liens (association, relations, correspondances) qui les relient ;

de certaines assertions (proprits ou contraintes d'intgrit) que doivent vrifier les donnes de la
base.

Dfinition : modle de donnes

un modle de donnes est l'ensemble des concepts et des rgles de composition qui permettent de
dcrire les donnes.
Dfinition : langage de description
un langage de description est un langage supportant un modle de donnes et permettant de dfinir
ces donnes.
Dfinition : schma
Un schma est la description au moyen d'un langage dtermin d'un ensemble particulier de
donnes.
Un Systme de Gestion de Bases de Donnes est donc un systme logiciel qui met en uvre un modle
de donnes particulier et qui offre des outils de dfinition et de manipulation de donnes des
utilisateurs possdant des connaissances plus ou moins approfondies sur le modle et sur le logiciel :
administrateur, dveloppeurs d'applications ou utilisateurs finals non spcialistes.

Les principaux modles de donnes sur lesquels s'appuient les SGBD sont le modle hirarchique, le
modle rseau, et le modle relationnel que nous examinerons ultrieurement.

I.3.

PRECISIONS SUR LES NIVEAUX DE DESCRIPTION

La description des donnes peut s'effectuer plusieurs niveaux d'abstraction qu'on appelle niveaux de
description et de schmas.

page 13

Le premier niveau concerne la ralit informatique. C'est l'administrateur de la base de donnes qui
effectue ce travail. Les objets dcrits sont ici l'environnement matriel et systme (organisation et
partitionnement du disque, systme d'exploitation), les fichiers (nom, taille, organisation), les
articles (nom, longueur, placement), les champs (nom, format, localisation), les chemins d'accs
(cl, lien, type).

Le second permet la description conceptuelle. La ralit au niveau de toute l'entreprise y est dcrite.
L'administrateur ou l'utilisateur donne une vue canonique des donnes : c'est de ce schma, unique, que
seront drives diffrentes vues externes. Les objets dcrits restent ici abstraits : entit (nom,
attributs), association (nom, cardinalit), contrainte (objet, assertion), etc.

Enfin le niveau externe permet de dcrire plusieurs visions diffrentes d'une mme ralit (le schma
conceptuel); chacune de ces visions correspondra une application ou un groupe particulier
d'utilisateurs (service du personnel, service de comptabilit, comit d'entreprise). Le niveau
d'abstraction de la description est ici le mme que celui du niveau conceptuel.

Des rgles de correspondance sont utilises pour transformer les donnes d'un niveau de schma dans
un autre. Ces rgles sont en gnral fixes par l'administrateur et permettent de librer l'utilisateur des
contraintes lies "l'informatique profonde".

Historiquement, c'est en 1971, qu'une recommandation du DBTG-CODASYL (DB Task Group) isolait un
niveau interne (spcialis dans le stockage et l'accs aux informations) et un niveau externe, proche de
l'utilisateur, qui gre les rapports avec les programmes d'application. La recommandation de trois
niveaux (interne, conceptuel et externe) date de 1979.

Dans cette introduction, nous ne nous proccupons que peu du niveau interne (voir cependant le
chapitre 7 qui prsente diffrentes possibilits d'implantation physique des donnes dans un SGBD),
mais nous pouvons profiter de ce paragraphe pour en dire quelques mots.

Prcisons en effet qu'un SGBD gre des milliards d'octets de donnes et que, pour ce faire, il n'utilise
pas les structures de donnes offertes par les langages de programmation (tels l'article en Pascal ou la
structure en C). Il n'utilise pas non plus, en gnral, les fichiers offerts par les systmes d'exploitation
pour stocker les informations sur disque ; il prfre utiliser ses propres techniques de stockage. Un
SGBD rserve une partie du disque et de la mmoire, y manipule des pages mmoire (chargement,
dchargement, lecture, criture) grce aux primitives de bas niveau offertes par le systme

page 14

d'exploitation. Sur ces pages mmoire, l'information est vue comme une suite d'octets dont
l'organisation est connue du systme1 qui sait ainsi lire les informations stockes.

Dans l'avenir nous n'aborderons plus les dtails de structure de cette couche interne, mais il faut garder
l'esprit qu'un SGBD, son plus bas niveau, ne fait que lire ou crire des pages mmoire. Il a de telles
quantits de donnes manipuler qu'il doit mettre en uvre le maximum de techniques pour diminuer
le nombre d'entres/sorties ncessaires. Ces mthodes, que nous nous bornerons prsenter rapidement
dans ces chapitres, s'appellent optimisation de requtes, mthodes de stockage, etc.

I.4.

DU MODELE ENTITE-RELATION A UML

Le modle "Entit-Association" ("Entity-Relationship" ou ER), prsent plus haut, est contemporain

des premiers SGBD. C'est un modle de conception2, gnralement utilis en mode graphique,
indpendant des possibilits (logiques et physiques) des SGBD. Pour cette raison il reste trs
populaire, d'autant que les schmas de donnes qu'il permet de construire peuvent tre traduits presque
automatiquement dans les modles logiques des SGBD des diffrentes gnrations : hirarchique,
rseau (CODASYL), relationnel (SQL) et mme orient objet (ODMG).

Il a t au fil du temps "enrichi" (Enhanced => EER) ou "complt" (ERC). Les nouveaux modles de
conception orients objet (OO) ont toutefois vocation le remplacer, surtout depuis leur rcente3
unification avec l' "Unified Modeling Language" (UML).

Le foisonnement des variantes de l'ER et des modles OO (OMT, Booch, OOSE...) ont entrain une
certaine confusion chez ceux-l mmes qui apprciaient la clart des schmas graphiques produits par
l'ER ou ses successeurs. Aussi tenterons-nous, en quelques courts paragraphes, de montrer que pour
l'essentiel (les concepts) ils prsentent, au del des diffrences de notation, une progression continue et
sans perte des acquis principaux.
I.4.1.

Entits et individus ou classes d'objets

L'entit , comme ensemble d'individus de mme type, est un concept auquel on peut facilement
substituer celui de classe d'objets ayant les mmes types (ou "structures") de donnes (et les mmes

1nous dsignons, ici et dans les pages qui suivent, par "systme" le SGBD qui, l'utilisant ou non, masque le systme de
gestion de fichiers - SGF - du sytme d'exploitation - OS.
2 qualifi aussi de "smantique"...
3 l'Object Management Group (OMG) en a accept en 1997 la version 1.0

page 15

"mthodes" pour les manipuler). Les individus "instancient" les entits comme les objets instancient
les classes. Les individus comme les objets doivent avoir un nom commun (celui de l'entit ou classe)
et un identifiant unique et invariant de leur naissance leur mort, que le concept physique de clef sur
un article ne suggre qu'imparfaitement (on peut changer une clef pas un identifiant). Ayant le mme
type ils sont de surcrot dcrits par les mmes variables nommes : caractristiques ou attributs
(synonymes). Ces variables peuvent tre de structures simples ou complexes : n-uplets (variables
composites par ex. une Adresse) ou ensembles (variables multivalues par ex. un Prnom). Les formes
graphiques reprsentant entits ou classes sont diffrentes mais traduisibles l'une dans l'autre comme
illustr ci-dessous par l'exemple de l'entit PLAGE :

NOMP

RGION

PLAGE
NOMP
RGION
POLLUTION

PLAGE

(mthode1
...)

POLLUTION

N.B. l'attribut soulign est un identifiant externe, il appartient au SGBD de crer le vritable identifiant
invariant (appel pour cette raison identifiant interne ou "surrogate")
I.4.2.

Liens, rles et cardinalits

Entre les objets (ou les entits) peuvent exister des liens nomms porteurs d'une smantique commune
: le rle. Ils peuvent lier des objets de classes diffrentes (comme BAIGNEUR et PLAGE, pour
exprimer le rle AIMER ou le rle SE_BAIGNER ou un autre rle) ou de mme classe (comme
BAIGNEUR, pour exprimer un rle comme PARENT_DE ou comme ENSEIGNE_A). Dans le
modle ER ces liens sont reprsents par des associations (il est interdit de relier directement des
entits entre elles), mme si elles n'ont pas d'attributs propres. Dans le modle UML, si aucun attribut
n'est associable au lien, celui-ci se reprsente par une simple arc entre les classes qu'il lie, sinon une
classe association est ajoute. Exemple :

page 16

NAGEUR

NAGEUR
date

AIME

SE_BAIGNE
date
dure

SE_BAIGNE

AIME

dure
PLAGE

PLAGE

Schma UML

Schma ER

Les cardinalits de ces liens ou associations spcifient, pour chaque extrmit d'un lien, c..d. pour
chaque classe lie, le nombre d'objets pouvant tre relis un mme objet de la classe l'autre
extrmit. Les diffrentes notations ci-dessous sont quivalentes :

On peut tre plus prcis en spcifiant des cardinalits minimum et maximum, c..d.

au lieu de 1 l'une des paires (0,1) ou (1,1), au lieu de n l'une des paires (0,n) ou (1,n), on peut aussi
afficher cette valeur n maximale, par exemple (0,3) ou (1,10)... Les dernires notations de la figure
prcdente pour l'association - de plusieurs plusieurs, "n n" - NAGEUR-aime-PLAGE pourraient
tre utilises comme ci-dessous :

page 17

NAGEUR

0..n

1..n

NAGEUR

PLAGE

PLAGE

(dans la 2e notation le rond est un zro et la barre verticale un 1)

Attention: dans le modle ER classique, quand les cardinalits (min,max) sont indiques, elles le sont
gnralement l'inverse de toutes les notations prcdentes. En effet les liens directs entre entits tant
impossibles et l'association tant toujours considre comme une classe intermdiaire instanciable,
cette inversion s'explique pourvu que l'on passe bien par toutes les tapes de la traduction, ce que nous
illustrons ci-dessous pour l'association - de 1 n - REGIONaffichePLAGE :

UML REGION

0..1

0..n
affiche

REGION

ER

REGION

1,1

0,n

0,n

affiche

0,1 1,1

affiche

0,1

PLAGE

PLAGE

PLAGE

(la raison pour laquelle la "classe association" est note par un double rectangle sera explique plus
loin)
I.4.3.

Associations identifiantes et/ou entits faibles

Les entits ou les classes s'opposent aux associations ou aux liens en ce qu'elles sont dfinissables en
elles-mmes. De mme les identifiants de leurs individus ou instances sont autonomes. Or il existe de
nombreux cas dans les univers modliser o certaines entits ne sont dfinies que relativement
d'autres, et les identifiants de leurs individus composs d'un identifiant d' "individu parent" suivi d'un
identifiant propre en tant qu' "individu enfant". Dans ce cas on dit que l'entit correspondante est
"faible" et que l'association parent-enfant est "identifiante".

page 18

Pensez par exemple aux diffrents

comptes bancaires d'une mme client d'une banque, aux diffrentes personnes la charge d'un mme
assur social, aux diffrents joueurs d'une mme quipe de foot, aux diffrents bureaux dans un mme
couloir, etc... La suppression de l'individu parent entraine celle de tous les individus enfants lis
(suppression en "cascade"). Les diffrentes notations en usage sont illustres par l'exemple classique
ci-dessous :

UML

1
COMMANDE

n
LIGNE_CDE

1
PRODUIT

ER

Dans cet exemple les COMMANDE et PRODUIT sont des entits "fortes" par opposition
LIGNE_CDE (rectangle doubl) qui est une entit "faible, dont le lien (trait continu) ou l'association
(losange doubl) identifiant gauche se distingue du lien (trait discontinu) ou de l'association (losange
simple) non identifiant droite.
I.4.4.

Agrgations

Les agrgations sont des associations ou liens particuliers ayant la smantique "compos-composant".

La suppression d'un "compos" peut ou non entraner celle des "composants" ("pices dtaches"
irrcuprables ou rcuprables!). Rciproquement la suppression d'un "composant" peut ou non
entraner la suppression du "compos" (une voiture sans roue ne change pas d'identit, une voiture
avec un nouveau chssis est une autre voiture...). La notation ER classique tait insuffisante pour
rendre compte de ces surcharges smantiques. La notation UML en rend compte assez prcisment
comme illustr ci-dessous :

page 19

VOITURE

1
CHASSIS
I.4.5.

5
ROUE

MOTEUR

Gnralisation et spcialisation

C'est le couple de concepts le plus important pour enrichir le modle ER. C'est un des concepts
fondamentaux de l'approche oriente objet. Entre une classe, par exemple d'Employs, et une classe
plus gnrale, par exemple de Personnes, le lien ou l'association est du type "EST-UN" (IS-A in
english) : un Employ est une Personne. Mme si les individus de la classe spcialise (Employs)
peuvent avoir une identification locale cette sous-classe, il est entendu qu'ils peuvent d'abord tre
identifi en tant qu'individus de la super-classe (Personnes). Plus gnralement un individu d'une sousclasse "hrite" de tous les attributs de la super-classe. Le lien rciproque de la gnralisation est la
spcialisation. Selon que les sous-classes d'une mme classe forment ou non une partition de cette
classe, on dit que la spcialisation est complte ou non. Diffrentes classes se gnralisant dans une
classe par l'opration d'union sont appeles des "catgories" pour cette classe. Les notations varient un
peu entre les modles ERC, .., OMT, UML. Le principal changement est apparu entre l'ER classique
qui dessinait autant d'associations que de liens "Est-un" et les modles suivants qui ont cr un nouveau
symbole pour un nud arborescent liant une super-classe plusieurs sous-classes.

Salari

Salari
...
Est-un

Horaire

Est-un

Horaire

Mensuel

UML

ER classique
I.4.6.

Mensuel

Autres concepts

Il est trs vite apparu ncessaire d'ajouter des contraintes une association, comme, par exemple pour
une association parent-enfant, d'ordonner les individus lis, ou des contraintes entre associations,

page 20

comme, par exemple une contrainte d'exclusion pour le couple d'associations

"dfendu_par" et

"accus_par", ou, pour les associations de type "Est-un", une contrainte de partitionnement ventuel.
Le fait que toute association peut ou non crer une association inverse (affirmer qu'un pre "connat"
ses enfants, ce n'est pas automatiquement affirmer que chaque enfant "connat" son pre...) est aussi
une surcharge que les modles ajoutent souvent. D'autres concepts, comme celui de "qualificatif" (dans
le modle UML) ou celui d' "assertion" (dans l'ERC) ont aussi t ajouts pour reprsenter d'autres
contraintes que celles voques ci-dessus. Tous les modles actuellement utiliss buttent sur l'infinie
richesse du langage naturel pour l'expression des contraintes...
I.4.7.

Demain, un seul modle conceptuel?

Les modles pour produire des schmas de bases de donnes ont suivi deux histoires parallles: les
modles de dfinition conceptuelle , qui cherchent la plus grande richesse smantique plus que la
facilit d'implmentation sur un SGBD, ont suivi une voie propre depuis l'ER de Chen; les modles
d'implmentation logique, lis aux structures de stockage et aux langages de manipulation des SGBD,
ont connu une histoire faite de continuits et de ruptures (environ tous les 10 ans) du modle
hirarchique au modle objet, fortement contrainte par les phnomnes de diffusion et de parc install.
A l'heure de la "convergence relationnel-objet" (et du SQL3) on se plait esprer une "convergence
logique-conceptuel".

I.5.

LES OBJECTIFS DES SGBD

De faon plus formalise, voici reprise et complte la liste des objectifs des SGBD.
I.5.1.

Offrir diffrents niveaux d'abstraction

Niveau physique :
Ce niveau appel aussi niveau interne, gre le stockage et l'accs aux donnes. Il n'y a qu'un seul
niveau physique par SGBD.
Niveau conceptuel :
C'est ce niveau, galement appel le niveau logique, que l'on parle de modle (conceptuel) de
donnes. Ce modle dcrit l'ensemble des donnes de l'entreprise. La description conceptuelle
d'une base de donnes - BD - est unique.

page 21

Niveau externe (vues) :

C'est le plus haut niveau d'abstraction de la base de donnes. Il est aussi appel niveau externe et
est propre un utilisateur ou un groupe d'utilisateurs et ne lui prsente qu'une vue partielle de la
ralit : celle qui intresse son service. Il y a bien entendu plusieurs vues d'une mme BD.

SCHMAS EXTERNES
OU VUES

SCHMA CONCEPTUEL

SCHMA INTERNE

I.5.2.

Assurer l'indpendance physique des donnes

Le but est ici de permettre l'utilisateur du niveau conceptuel d'ignorer la structure du niveau
physique. Cela ncessite une transformation entre niveau logique et physique, mais prsente deux
avantages considrables :
-

les programmes d'applications sont plus simples crire, du fait de ne pas avoir manipuler des
entits complexes (structures d'enregistrement, mthodes d'accs) ;

dans le cas d'une modification des caractristiques du niveau physique, les applications n'ont pas
tre modifies.

I.5.3.

Assurer l'indpendance logique des donnes

Le but est ici de permettre l'utilisateur du niveau vue (typiquement les programmeurs
d'application ou les utilisateurs finals) d'ignorer la structure du niveau conceptuel. Cela ncessite
une transformation entre niveau externe et conceptuel, mais offre l encore deux avantages de
poids :
-

les programmes d'applications du niveau externe n'ont pas avoir la vision globale de toute
l'entreprise. Ils agissent partir des vues ;

page 22

les applications du niveau externe, en cas d'une modification du schma au niveau conceptuel, ne
sont rcrire que si cette modification entrane celle de la vue, ce qui est rarement le cas.

I.5.4.

Contrler la redondance des donnes

Un des objectifs de base des SGBD, la suppression de la redondance des donnes, vise garantir la
cohrence de l'information et simplifier les mises jour. Cependant, la redondance est parfois
ncessaire pour garantir la fiabilit et les performances, ou pour la rpartition des donnes.

Les donnes sont rparties quand plusieurs SGBD situs sur des sites distincts relis par un rseau
partagent les informations dont ils disposent. Possder certaines informations sur tous les sites est alors
parfois indispensable (par exemple la description des donnes prsentes sur les diffrents sites pour
savoir o, comment, et dans quel ordre aller les chercher en cas de besoin).

En consquence, la redondance anarchique des donnes doit tre limine et la redondance existante
doit tre contrle en propageant la mise jour d'une donne redondante.
I.5.5.

Permettre tout type d'utilisateur de manipuler des donnes

Le but est d'offrir aux diffrents types d'utilisateurs des moyens d'accs la base adapts leurs
besoins et leurs connaissances. Nous devrons ainsi distinguer :

un ou plusieurs administrateur de la base qui doivent pouvoir dcrire les donnes aux niveaux
physique (administrateur BD et ingnieur systme) et conceptuel (administrateur BD et
concepteur) ;

un ou plusieurs dveloppeur d'applications qui crivent, partir du niveau conceptuel ou des

niveaux externes, des programmes d'application pour eux-mmes ou pour les utilisateurs finals ;

un ou plusieurs utilisateur final ont besoin d'un langage simple (si possible proche du langage
naturel) pour manipuler les donnes de manire interactive ou partir de programmes
d'application.

I.5.6.

Assurer l'intgrit des donnes

L'intgrit logique de l'information est souvent vrifie par les programmes d'applications dans les
organisations traditionnelles bases de fichiers. Dans une approche base de donnes, elle fait partie de
la description de la ralit conceptuelle du systme d'information. La vrification de l'intgrit est une
composante du modle de donnes et une tche du SGBD qui le met en uvre. L'intgrit smantique
correspond des rgles explicitant des contraintes du monde rel.

page 23

Nous pouvons donner comme exemple :

il est interdit et impossible de se baigner sur une plage trs pollue ;

un baigneur ne peut pas se baigner sur une plage non recense ;

un baigneur ne peut pas se baigner Binic en mars.

Toute requte de mise jour des donnes (insertion, modification ou suppression) ne respectant pas
l'ensemble des contraintes d'intgrit doit tre rejete par le SGBD.
I.5.7.

Assurer le partage des donnes

Composant transactionnel d'un systme informatique, un SGBD doit permettre le partage des donnes
entre diffrents utilisateurs et applications. Un utilisateur n'a pas se demander si quelqu'un d'autre
travaille sur les mmes informations au mme moment et doit pouvoir accder aux donnes en
consultation ou en mise jour comme s'il tait seul : le systme doit grer les conflits, en refusant ou
en retardant ventuellement un ou plusieurs accs.
I.5.8.

Assurer la scurit des donnes

Cela consiste protger les donnes contre les pannes et refuser les accs aux personnes non
autorises. Le systme doit prsenter un mcanisme de vrification des droits d'accs aux objets de la
base. Il doit garantir des reprises aprs panne en restaurant la base de donnes dans le dernier tat
cohrent avant la panne. La fiabilit est traditionnellement sur les gros systmes mise en uvre des
techniques trs sophistiques. La qualit de l'implantation de ces techniques a d'importantes
consquences sur les performances en cas d'utilisation intensive.
I.5.9.

Optimiser l'accs aux donnes

En permettant aux utilisateurs d'ignorer les structures physiques et les chemins d'accs l'information,
le SGBD prend sa charge un lourd travail d'optimisation. En utilisant les meilleurs chemins d'accs,
mais aussi le paralllisme ou des algorithmes de recherche sophistiqus, il permettra de minimiser le
volume des donnes accdes et le temps d'excution des questions.

page 24

I.6.

CONCLUSIONS

Cette introduction nous a permis de prsenter les motivations et les buts des Systmes de Gestion de
Bases de Donnes. Placs ici sur un pied d'galit, les diffrents objectifs sont atteints des degrs
divers : les aspects transactionnels (concurrence, scurit physique,) sont bien implants et assurent
aujourd'hui une efficacit trs importante aux systmes utiliss en production et destins couler un
nombre important de transactions par seconde ; les indpendances physique - conceptuel / interne - et
logique - externe / conceptuel - sont bien assures par les systmes relationnels, mais mal ou pas du
tout dans les produits s'appuyant sur les modles rseau ou hirarchique ; la dtermination par les
systmes des meilleurs algorithmes et chemins d'accs aux donnes ont fait faire des progrs
considrables aux mthodes d'accs des systmes informatiques modernes ; la vrification automatique
des contraintes d'intgrit gnrales est, en revanche, encore peu implante dans les produits.

I.7.BIBLIOGRAPHIE GENERALE
S. ABITEBOUL, R.HULL

FUNDATIONS OF DATABASES,

AND V.VIANU

ADDISSON-WESLEY, 1995

M. ADIBA ET C.DELOBEL

BASES DE DONNEES ET SYSTEMES RELATIONNELS,

DUNOD, 1982

C.J. DATE

AN
INTRODUCTION
TO
DATABASE
SYSTEMS,
ADDISSON-WESLEY, VOLUME 1, 4TH EDITION, 1987,
VOLUME 2, 1983

C.J. DATE

A GUIDE TO THE SQL STANDARD

ADDISSON-WESLEY, 1987

R. ELMASRI
AND S.B. NAVATHE

FUNDAMENTALS OF DATABASES SYSTEMS

ADDISSON-WESLEY, WORLD STUDENT SERIES, 2ND ED,
1994

G. GARDARIN

BD: LES SYSTEMES ET LEURS LANGAGES,

EYROLLES, 3E EDITION, 1985

G. GARDARIN

MAITRISER LES
EYROLLES, 1993

J.MELTON AND A.SIMON

UNDERSTANDING THE NEW SQL: A COMPLETE GUIDE,

MORGAN KAUFMANN, 1993

J.D. ULLMAN

PRINCIPLES OF DATABASE SYSTEMS,

page 25

BD:

MODELES

ET

LANGAGES,

COMPUTER SCIENCE PRESS, 1982

G. VOSSEN

DATA MODELS, DB LANGUAGES AND DBMS, ADDISONWESLEY, 1991

page 26

CHAPITRE 2 : LE MODELE RELATIONNEL

Dbut des annes 70, le modle relationnel fait son apparition [Codd 70]. La recherche se passionne :
impossible de nier les progrs apports concernant la reprsentation et la manipulation des donnes par
les systmes. Dix ans passent, les spcialistes dchantent : ce top-model engendre en dfinitive des
systmes commerciaux bien moins performants que leurs concurrents fonds sur les modles rseau ou
hirarchique. Deux ans plus tard et voil que les produits relationnels peuvent prtendre relayer les
"vieux" systmes. Leurs apports sont fondamentaux : les nouvelles fonctionnalits permettent un
confort d'utilisation sans prcdent. Les systmes commerciaux s'emparent des concepts de ce nouveau
modle. Celui-ci, dsormais, s'impose.

Mais quels sont ces concepts, leurs avantages, leurs limites ? Certains sont dj bien rpandus. Ce sont
les notions de base que nous dtaillerons dans la premire partie : domaine, relation, attribut ; puis la
manipulation ensembliste des relations par les oprateurs de l'algbre relationnelle (deuxime partie)
sur lesquels sont construits des langages non procduraux comme SQL (chapitre 4) ; l'importante base
thorique du modle enfin fournit des mthodes pour la conception des bases de donnes (chapitre 5).
D'autres concepts sont toutefois moins connus qui constituent pourtant un progrs essentiel : les vues
relationnelles permettent chaque utilisateur de personnaliser sa vision des donnes et les contraintes
d'intgrit compltent la description de l'information (chapitre 6). Les chapitres suivants prsentent
chacun des ressorts qui font du modle relationnel la rfrence oblige en matire de gestion de bases
de donnes.

III.1.

LE MODELE RELATIONNEL

Le modle relationnel, contrairement ceux prsents dans le chapitre prcdent, ne manipule pas des
structures de donnes figes, mais des valeurs : aucun chemin d'accs n'est pralablement dfini (on ne
parlera dsormais plus de dplacements ou de langages navigationnels), toute manipulation des
donnes est dsormais possible. L'important bagage thorique, et la vision tabulaire des informations,
qui est agrable l'utilisateur, assurent le succs du modle relationnel.

page 27

III.1.1.

Une premire approche du relationnel

Nous prsentons dans ce paragraphe un moyen simple de visualiser la structure de base du modle
relationnel : la relation. Nous dcrivons ci-dessous une extension de la base des nageurs sous la forme
de tableaux de colonnes de valeurs types et nommes.
La relation des nageurs :
NAGEURS

NN

NOM

PRENOM

QUALITE

100

Plouf

Jean

Mauvaise

110

Coule

Paul

Excellente

120

Brasse

Jean

Bonne

La relation des plages :

PLAGES

NP

NOMP

TYPE

REGION

POLLUTION

110

Trgastel

sable

Bretagne

absente

119

Nice

galets

Cte d'Azur

forte

107

Oleron

sable

Atlantique

moyenne

118

Binic

sable

Bretagne

forte

La relation des baignades :

BAIGNADES

III.1.2.

NN

NP

DATE

DUREE

110

118

14/07/89

110

118

15/07/89

10

120

119

12/07/89

120

La construction du modle relationnel

Nous allons dans ce paragraphe introduire les notions utilises dans la construction thorique du
modle relationnel: domaine, relation, tuple, attribut, schma.

page 28

La notion de domaine
Dfinition : domaine
Un domaine est un ensemble de valeurs (distinctes).
Cette dfinition correspond l'ensemble des valeurs que peut prendre une certaine
manifestation du monde rel. Elle s'apparente souvent un type (entier, rel), mais peut
galement tre htroclite (date). Dans l'exemple prcdent, un domaine est l'ensemble des
valeurs d'une colonne d'un tableau : {'Mauvaise', 'Excellente', 'Bonne'} est un domaine.
Exemples de domaines :
-

l'ensemble des entiers est un domaine ;

{3, 5.7, 124} est un domaine ;

[-3, 4] {5, 7} est un domaine ;

('Jean', 'Paul', 'Louis', 'Arthur') est un domaine ;

(14/07/89, 15/07/89, 15/07/89) est un domaine ;

Tout ensemble de valeurs est un domaine.

Produit cartsien de plusieurs domaines :

Dfinition : produit cartsien
Le produit cartsien d'un ensemble de domaines D1, D2,, Dn, not D1xD2xxDn, est
l'ensemble de n-uplets (ou tuples) <v1, v2,, vn> tels que vi Di.
Exemple :
Ralisons le produit cartsien des domaines suivants, (Plouf, Coule, Brasse), (Jean, Paul).
Plouf

Jean

Plouf

Paul

Coule

Jean

Coule

Paul

Brasse

Jean

Brasse

Paul

Comme on le voit, si un domaine reprsente l'ensemble des valeurs possibles d'une manifestation du
monde rel (exemples : les cheveux sont blonds, noirs, bruns ou blancs ; les ages sont compris entre 0
et 130, etc.), le monde rel "possible" est constitu par le produit cartsien des domaines et le monde
rel "rel" est forcment un sous ensemble du produit cartsien.
La notion de relation
Dfinition : relation
une relation est un sous-ensemble du produit cartsien d'une liste de domaines.

page 29

Exemple :
la relation NAGEURS est un sous-ensemble du produit cartsien des domaines suivants :
(100, 110, 120), (Plouf, Coule, Brasse), (Jean, Paul), (Mauvaise, Bonne, Excellente).
La notion de n-uplet
Dfinition : n-uplet ou tuple
un n-uplet (lment) correspond une ligne d'une relation.
Une autre reprsentation des relations
Une autre faon de considrer une relation N domaines D1, D2,... DN est de reprsenter un
espace N dimensions. Dans cet espace chaque domaine correspond l'une des dimension,
chaque n-uplet ou tuple correspond un point de l'espace.
Exemple
PRENOM

Paul
Jean
(Plouf, Jean, mauvais)
NOM
Plouf
mauvaise
bonne
Excellente
QUALITE

La notion d'attribut
Dfinition : attribut
Un attribut est le nom donn une colonne d'un tableau reprsentant une relation.
Exemple :
les attributs de la relation PLAGES sont NP, NOMP, REGION, TYPE et POLLUTION.
La notion de schma
Dfinition : schma d'une relation
Le schma d'une relation est compos de son nom suivi du nom de ses attributs et de leurs
domaine :
R(A1 D1, A2 D2,, AN DN).
Lorsque le choix des domaines est vident, on simplifie l'criture de la faon suivante :
R(A1, A2,, AN).
Exemple :
PLAGES (NP, NOMP, TYPE, REGION, POLLUTION).

page 30

Dfinition : schma d'une base de donnes relationnelle

Le schma d'une base de donnes relationnelle est l'ensemble des schmas des relations
qui la composent..
Une base de donnes relationnelle est constitue par l'ensemble des tuples de toutes les
relations dfinies dans le schma de la base.
III.1.3.

Une manipulation ensembliste des donnes

Nous avons tudi au chapitre prcdent les premiers modles de SGBD. Que ce soit le segment dans le
modle hirarchique ou l'article dans le modle rseau, la manipulation des informations s'effectue
enregistrement par enregistrement.

Dans un systme relationnel, les informations ne sont pas forcment repres individuellement ; on sait
appliquer le mme traitement un ensemble d'enregistrements caractriss, non par la liste des
identifiants individuels, mais par le critre que vrifie chacun des enregistrements qui composent
l'ensemble. On dit que la manipulation est ensembliste.

En particulier, pour rechercher des tuples, il suffit de prciser un critre de slection ; le systme
dterminera l'ensemble des tuples satisfaisant ce critre et rendra un rsultat. Les tuples de ce rsultat,
extraits de relations de la base, constituent eux-mme une relation qu'il sera ainsi ais de conserver, si
ncessaire, pour le plus grand confort de l'utilisateur.

Par exemple, pour connatre les dates et dures des bains pris par Paul Coule ainsi que les noms des
plages, on obtient le rsultat suivant, qui est une relation RESULTAT trois attributs NOMP, DATE,
DUREE :

RESULTAT

NOMP

DATE

DUREE

Binic

14/07/89

Binic

15/07/89

10

Typiquement, on peut classer les requtes en deux grandes catgories : la mise jour de tuples dans
une relation et la recherche de tuples vrifiant une certaine condition. Eventuellement, ces deux types
de requtes peuvent tre combins.

La manipulation ensembliste est trs utile en mise jour. Elle permet, par exemple, de modifier
directement la qualit de tous les nageurs ayant pris un bain sur la plage de Binic le 14 juillet 1989,

page 31

sans avoir dterminer pralablement la liste des nageurs qui prsentent cette caractristique. Cette
puissance d'expression explique largement le succs du relationnel.

Les insertions/suppressions sont ralises l'aide de relations temporaires internes et d'oprateurs

ensemblistes d'union et de diffrence (dtails au paragraphe suivant). La combinaison de ces
oprateurs et des oprateurs relationnels de slection sur des critres de recherche

facilite

sensiblement les oprations de modification. C'est le cas en particulier des modifications calcules,
c'est--dire des modifications portant sur un ensemble de tuples rsultant eux-mmes d'une slection.
Exemples
-

insertion ou suppression de Paul Brasse, mauvais nageur, qui a pris un bain de 2 minutes le
14/07/1989 sur la plage de sable trs pollue de Binic, en Bretagne.

recherche des noms des nageurs ayant pris des bains de plus d'une minute en Bretagne.

suppression de tous les nageurs ayant pris, en fvrier, des bains de plus de 2 minutes en
Bretagne (hydrocution ?).

Pour manipuler ces relations, nous avons besoin d'un langage adapt dont la particularit est de savoir
manipuler aisment ces tableaux de donnes. Ce langage constitue l'algbre relationnelle.
III.2.

L'ALGEBRE RELATIONNELLE

L'algbre relationnelle est le langage interne d'un SGBD relationnel. Elle se compose d'oprateurs de
manipulation des relations. Ces oprateurs sont regroups en deux familles : les oprateurs
ensemblistes et les oprateurs relationnels. Chacune de ces familles contient quatre oprateurs.
III.2.1.

Les oprateurs ensemblistes

L'union
Not R S, o R et S reprsentent deux relations de mme schma, cet oprateur permet de
raliser l'insertion de nouveaux tuples dans une relation. Par exemple, ajouter la relation
permanente RP...
RP

NP

NOMP

TYPE

REGION

POLLUTION

110

Trgastel

sable

Bretagne

absence

119

Nice

galets

Cte d'Azur

forte

107

Oleron

sable

Atlantique

moyenne

118

Binic

sable

Bretagne

forte

page 32

... la relation de travail RT...

RT

NP

NOMP

TYPE

REGION

POLLUTION

110

Trgastel

sable

Bretagne

absence

115

Deauville

sable

Normandie

forte

117

Trouville

sable

Normandie

forte

... on obtient la nouvelle relation RESULTAT = RP RT...

RESULTAT

NP

NOMP

TYPE

REGION

POLLUTION

110

Trgastel

sable

Bretagne

absence

119

Nice

galets

Cte d'Azur

forte

107

Oleron

sable

Atlantique

moyenne

118

Binic

sable

Bretagne

forte

115

Deauville

sable

Normandie

forte

117

Trouville

sable

Normandie

forte

Remarquons que la manipulation est rellement ensembliste : les lments qui pourraient tre
dupliques (insertion de la plage de Trgastel qui figure dj dans la relation permanente) ne le sont
pas.
L'intersection
Oprateur not R S, o R et S reprsentent deux relations de mme schma, qui permet de
retrouver les tuples identiques dans deux relations .
La diffrence
Oprateur not R - S, o R et S reprsentent deux relations de mme schma, qui permet de
raliser la suppression de tuples dans une relation. Par exemple, retrancher la relation
permanente RP...

page 33

RP

NP

NOMP

TYPE

REGION

POLLUTION

110

Trgastel

sable

Bretagne

absence

119

Nice

galets

Cte d'Azur

forte

107

Oleron

sable

Atlantique

moyenne

118

Binic

sable

Bretagne

forte

115

Deauville

sable

Normandie

forte

117

Trouville

sable

Normandie

forte

... La relation de travail RT...

RT

NP

NOMP

TYPE

REGION

POLLUTION

110

Trgastel

sable

Bretagne

absence

107

Oleron

sable

Atlantique

moyenne

... Pour obtenir la relation RESULTAT = RP - RS

RESULTAT

NP

NOMP

TYPE

REGION

POLLUTION

119

Nice

galets

Cte d'Azur

forte

118

Binic

sable

Bretagne

forte

115

Deauville

sable

Normandie

forte

117

Trouville

sable

Normandie

forte

Le produit cartsien
Si R1 et R2 sont des relations de schmas respectifs (att1,1, att1,2,...,att1,N) et (att2,1, att2,2,...,
att2,M) contenant respectivement T1 et T2 tuples, alors la relation R = R1 X R2 rsultant du
produit cartsien des deux relations a pour schma (att1,1, att1,2,...,att1,N, att2,1, att2,2,..., att2,M)
et contient T1 * T2 tuples obtenus par concatnation des T1 tuples de R1 et des T2 tuples de R2.

page 34

III.2.2.

Les oprateurs relationnels

La restriction
Not E(R) o E exprime un prdicat sur une relation R, cet oprateur permet de ne conserver,
dans une relation, que les tuples dont les attributs vrifient une certaine condition. Par exemple,
la relation permanente RP...
RP

NP

NOMP

TYPE

REGION

POLLUTION

110

Trgastel

sable

Bretagne

absence

119

Nice

galets

Cte d'Azur

forte

107

Oleron

sable

Atlantique

moyenne

118

Binic

sable

Bretagne

forte

115

Deauville

sable

Normandie

forte

117

Trouville

sable

Normandie

forte

rduite aux plages forte pollution (le prdicat E se note POLLUTION = 'forte') donne la
relation RESULTAT
RESULTAT

NP

NOMP

TYPE

REGION

POLLUTION

119

Nice

galets

Cte d'Azur

forte

118

Binic

sable

Bretagne

forte

115

Deauville

sable

Normandie

forte

117

Trouville

sable

Normandie

forte

La projection
Not

A1,...,AN(R)

o A1,...,AN reprsentent des attributs particuliers de la relation R, cet

oprateur permet de ne conserver que certains attributs d'une relation. Par exemple, les
diffrentes rgions et leurs niveaux de pollution sont obtenus par projection de la relation
PLAGES sur les attributs REGION et POLLUTION...

page 35

RESULTAT

REGION

POLLUTION

Bretagne

absence

Cte d'Azur

forte

Atlantique

moyenne

Bretagne

forte

Normandie

forte

Notons l'aspect ensembliste de cette opration qui ne duplique pas le tuple ('Normandie', 'forte')
qui figurait en double dans la relation intermdiaire rsultat d'une projection brutale de la
relation initiale.
La jointure
Dfinition :
La jointure de deux relations R et S selon une qualification multi-attributs Q est l'ensemble
des tuples du produit cartsien RxS satisfaisant la qualification Q.
Notation
Il existe plusieurs notations possibles de cet oprateur. Les plus rpandues sont :
-

JOIN (R, S/Q) ;

R |x|Q S

qui-jointure
La qualification Q consiste simplement en l'galit entre diffrents attributs des deux
relations. C'est le cas le plus courant de jointure.
Exemple :
Pour connatre les bains pris par les diffrents nageurs, il suffit d'effectuer l'qui-jointure
entre les deux relations NAGEURS et BAIGNADES sur chacun de leur attribut NN
RESULTAT

NOM

PRENOM

QUALITE

NN

NN

NP

DATE

DUREE

Coule

Paul

Excellente

110

110

118

14/07/89

Coule

Paul

Excellente

110

110

118

15/07/89

10

Brasse

Jean

Bonne

120

120

119

12/07/89

120

dans le cas d'une qui-jointure, on peut liminer la colonne en double ; on parle alors d'quijointure naturelle.

page 36

Exemple d'inqui-jointure :
Quels sont les nageurs ayant pris des bains sur une plage de numro NP suprieur leur
propre numro d'identification NN ?
RESULTAT

NOM

PRENOM

QUALITE

NN

NP

NN

DATE

DUREE

Coule

Paul

Excellente

110

118

110 14/07/89

Coule

Paul

Excellente

110

118

110 15/07/89

10

Autre exemple de jointure :

Quels sont les nageurs ayant pris des bains de dure gale leur numro ?
RESULTAT

NOM

PRENOM

QUALITE

NN

DUREE

NN NP

DATE

Brasse

Jean

Bonne

120

120

120 119

12/07/89

La division
Not R S o R et S dsignent deux relations, cet oprateur, plus complexe, permet de
connatre toutes les valeurs d'un domaine qui sont en correspondance avec toutes les valeurs
d'un autre domaine. Par exemple, existe-t-il des nageurs qui ont pris des bains la fois le
14/07/89 et le 15/07/89 ? Pour le savoir, il suffit d'effectuer la division de la relation Baignade
projete sur (NN, DATE) (note RES1) par la colonne DATE restreinte aux 14/07/89 et au
15/07/89 :
BAIGNADES

RES1

NN

NP

DATE

DUREE

110

118

14/07/89

110

118

15/07/89

10

120

119

12/07/89

120

DATES

DATE

NN

DATE

110

14/07/89

14/07/89

110

15/07/89

15/07/89

120

12/07/89

page 37

RESF

NN
110

Les tuples du rsultat RESF (NN), concatns tout tuple de DATES (DATE) donne un tuple de
RES1 (NN, DATE).

Ainsi, l'ensemble des tuples rsultats du produit cartsien de RESF et DATES

sont dans RES1.

III.2.3.

Oprateurs de base et oprateurs drivs

Cinq de ces huit oprateurs forment les oprateurs de base (ce sont l'union, la diffrence, le produit
cartsien, la restriction et la projection) tandis que les trois autres, appels oprateurs drivs,
s'obtiennent plus ou moins facilement par combinaison des oprateurs de base :

R S = R - (R - S)

R |x| S (Ai, Bj) = ij (R x S)

R S = i1,,i(r-s) (R) - i1,,i(r-s) ( (i1,,i(r-s) (R) x S) - R)

Les cinq oprateurs de base permettent de rpondre toutes les questions que l'on peut poser avec la
logique du premier ordre (c'est dire sans les fonctions) : on dit que l'algbre relationnelle est
complte.

En ralit, nous n'utiliserons dans nos requtes que les oprateurs les plus maniables : ce sont l'union et
la diffrence pour l'insertion et la suppression de tuples dans la base et la restriction, la projection et la
jointure pour la recherche slective de tuples.
III.2.4.

Des exemples de requtes

Exemple 1 :
Donner les noms des plages fortement pollues.
Cette requte comprend deux oprations (o dsigne l'affectation)
TEMP Rest (PLAGES, POLLUTION = 'forte')
RESU Proj (TEMP, NOMP)

Ce qui se note encore :

page 38

RESU Proj (Rest(PLAGE, POLLUTION = 'forte'), NOMP)

Exemple 2 :
Donner les noms des personnes ayant pris un bain en Bretagne.
T1 Rest (PLAGE, REGION = 'Bretagne')
T2 Join (T1, BAIGNADE, T1.NP = BAIGNADE.NP)
T3 Join (T2, NAGEURS, T2.NN = NAGEURS.NN)
RESU Proj (T3, NOM)

Exemple 3 :
Insertion de la plage de sable "Fort bloqu", en Bretagne, faiblement pollue avec le numro
120.
PLAGES PLAGES (120, 'Fort bloqu', 'sable', 'Bretagne', 'faible').

Exemple 4 :
Suppression des nageurs de qualit mdiocre.
NAGEURS NAGEURS - Rest( NAGEURS, QUALITE = 'mdiocre')

III.2.5.

Les arbres algbriques et l'optimisation

Nous venons de voir comment dcrire une requte au moyen des oprateurs de l'algbre relationnelle.
Toutefois, l'criture de cette combinaison d'oprateurs est malaise dchiffrer. Il existe en
contrepartie une description graphique plus lisible : l'arbre algbrique.

Un arbre algbrique est un arbre dont :

-

les feuilles sont les relations de base ;

les nuds sont les oprateurs ;

la racine est le rsultat ;

les liens reprsentent les flux de donnes.

Ainsi, des nuds diffrents reprsentent les cinq principaux oprateurs relationnels : l'union, la
diffrence, la restriction, la projection et la jointure.

page 39

L'union :

La diffrence :

La restriction :

La projection :

La jointure :

page 40

Nous pouvons ds lors facilement reprsenter la requte :

"Sur quelle plage (NOMP) Jean Plouf a-t-il pris des bains de plus de deux minutes ? "

Remarquons que cette requte peut s'excuter de diverses faons :

NAGEURS

qui-jointure

BAIGNADES

NN

PLAGES

NN

qui-jointure

NP

NP

restriction sur
NOM = Plouf
PRENOM = Jean
DUREE > 2mn

projection sur NOMP

Premire mthode
Une premire mthode d'excution de requte peut minimiser le nombre d'oprations effectuer. C'est
ce que nous faisons ici en excutant les jointures dans un premier temps, puis en repoussant la fin la
restriction et la projection qui permettent d'obtenir le rsultat dsir. On minimise ainsi le nombre
d'oprations effectuer, mais on ralise des jointures sur des relations trs volumineuses. ce qui
augmente considrablement les tailles des relations intermdiaires et donc le cot global d'excution de
la requte.

page 41

Deuxime mthode
NAGEURS

BAIGNADES

qui-jointure

qui-jointure

NN

PLAGES

NP

NP

NN

restriction sur
NOM = Plouf
PRENOM = Jean
DUREE > 2mn

projection sur NOMP

Quelle que soit l'heuristique choisie pour excuter la requte. Dterminer dans quel ordre
l'excution des jointures entrane un cot minimum est intressant. Suivant la taille des relations
mises en jeu, la diffrence de cot Correspondant une inversion dans l'ordre des jointures peut
tre considrable.

page 42

Troisime mthode
NAGEURS

restriction sur
NOM = Plouf
PRENOM = Jean

BAIGNADES
BAINS

DUREE > 2mn

projection sur
NN

qui-jointure

PLAGES

NN, NP

NN

NP, NOMP

NN

qui-jointure

NP

NP

projection sur NOMP

Toutefois, compte tenu du cot trs important des jointures et de l'importance de la taille des relations
mises en jeu, il vaut mieux rajouter des tapes intermdiaires qui diminuent la taille des relations
l'entre des jointures. Le cot supplmentaire est compens par une baisse sensible du cot des
jointures. C'est ce que nous faisons ici : les oprations de jointure agissent sur des relations rduites au
maximum par des restrictions et des projections.

page 43

Quatrime mthode
NAGEURS

PLAGES

BAIGNADES

Restriction sur
NOM = "Plouf" et
PRENOM = "Jean"

DUREE > 2mn

Projection sur
NN

NN, NP

qui-jointure

NN

NN, NOMP

NN

projection sur NP

qui-jointure NP

NP

projection sur NOMP

Nous pouvons affiner cette mthode en liminant aprs chaque jointure les attributs devenus inutiles
pour l'obtention du rsultat final.

page 44

Cinquime mthode
NAGEURS

projection sur
NN, NOM, PRENOM

BAIGNADES

PLAGES

NN, NP, DUREE

restriction sur
NOM = Plouf
PRENOM = Jean

DUREE > 2mn

projection sur
NN

NN, NP

qui-jointure

NN

NP, NOMP

NN

projection sur NP

qui-jointure

NP

NP

projection sur NOMP

Enfin, nous pouvons galement tre amens rechercher les critres de variation du cot entre la
mthode dcrite ci-dessous et la prcdente. Nous rajoutons ici une premire tape de projection avant
la premire restriction.

page 45

A partir de cet exemple, nous constatons qu' une mme requte correspond de multiples plans
d'excution. Le choix d'un plan par rapport un autre a de nombreuses implications quant la dure
d'excution de la requte.

Enfin, si la vrification que l'ordre des oprateurs permet de raliser la question initialement pose,
choisir parmi les nombreuses solutions qui n'affectent pas le rsultat, mais seulement la rapidit
d'excution de la requte est plus dlicat .

En effet, se proccuper activement du cot d'excution d'une requte est ncessaire : un SGBD est jug
sur sa rapidit.

Une heuristique simple consiste restreindre le plus vite possible la taille des relations intermdiaires
pour diminuer le cot . Pour ce faire, nous utilisons les proprits des diffrents oprateurs :
-

associativit des jointures ;

commutativit restriction/jointure ;

commutativit restriction/projection (si le critre de restriction porte sur les attributs

projets);

commutativit projection/jointure (si le critre de jointure porte sur les attributs projets).

Une mthode relativement aise mettre en uvre consiste disposer en entre des jointures de
relations les plus petites possibles, ce qui revient faire prcder les jointures, oprations les plus
coteuses, du maximum de restrictions et de projections possibles sans altrer le rsultat final.

De faon gnrale ; il est indispensable de disposer :

-

de relations initiales et intermdiaires les plus petites possibles ;

de techniques de placement adaptes qui permettent de ne pas rapatrier toute une relation
pour isoler les informations intressantes (voir chapitre 7) ;

III.3.

d'algorithmes performants implantant les oprateurs relationnels.

CONCLUSIONS

Les SGBD existant ce jour mettent en uvre des techniques performantes pour la manipulation des
donnes.

Par exemple, tous les SGBD offrent aujourd'hui un langage assertionnel de requtes, SQL. Un langage
assertionnel permet de poser la requte sous la forme d'une ou de plusieurs conditions (assertions)

page 46

remplir sans se proccuper de l'ordre des diffrentes oprations effectuer au niveau du systme. C'est
au SGBD d'analyser la condition et de la dcomposer en une requte de l'algbre relationnelle.

L'optimiseur de requtes est un composant trs important d'un SGBD relationnel. L'tape fondamentale
est la construction d'un arbre algbrique optimis, en dterminant le meilleur ordre d'excution des
diverses oprations. Cependant, les SGBD utilisent d'autres critres (contraintes d'intgrit, taille des
relations candidates, mthodes de placement) soit pour aider la construction de l'arbre optimis,
soit pour rfuter logiquement une requte et pour choisir l'algorithme adquat la ralisation d'une
opration particulire (une mme opration dispose couramment de diffrents algorithmes dont les
performances varient suivant les caractristiques des relations mises en jeu).

L'opration de jointure ou la prise en compte des temps de transit de donnes dans des systmes
rpartis sont un bon exemple de la multiplicit des algorithmes existants.

Les amliorations sur le march suivent de prs les progrs de la recherche et les produits voluent
vite : les premires versions de nombreux produits offraient des algorithmes peu performants, mais la
situation a bien chang depuis. Les SGBD demeurent toutefois des produits dlicats valuer, comme
c'est souvent le cas des produits informatiques. L'utilisation d'un algorithme ne suffit pas garantir sa
bonne utilisation. Notez en particulier l'importance essentielle des mthodes de stockage et des
primitives de bas niveau offertes par le systme d'exploitation pour l'efficacit des SGBD. Pour toutes
ces raisons, le modle relationnel, malgr sa "beaut conceptuelle", a mis beaucoup de temps
s'imposer sur le march.

III.4.

REFERENCES

[Astrahan 76]

M. ASTRAHAN

et al : "System R : A Relational Approach to Database

Management", ACM Transactions on Database Systems, Vol 1, N2, 1976.

[Codd 70]

E.F. CODD,

"A Relational Model of Data for Large Shared Data Banks",

Communications ACM, V13, N6, Juin 1970, pp 377-387.

page 47

page 48

CHAPITRE 4 : LES LANGAGES RELATIONNELS

Les oprateurs algbriques, qui effectuent la manipulation interne des relations dans un SGBD
relationnel, forment un premier langage de requtes. Ils prsentent cependant l'inconvnient majeur
d'exprimer les manipulations effectuer de faon procdurale. En effet, la spcification directe par
l'utilisateur d'une squence d'oprations relationnelles correspond au choix d'une excution
particulire ; plusieurs excutions sont possibles pour une mme question. L'utilisateur qui l'on offre
un langage algbrique a donc plusieurs choix pour formuler sa question : certains sont performants,
d'autres induisent des temps de rponses impressionnants, car ils gnrent un volume considrable de
donnes intermdiaires et de trs nombreux accs.

Les concepteurs de systmes ont donc cherch proposer un langage de manipulation de donnes qui
ne demande prcise pas l'ordre des oprations. Un tel langage est donc non-procdural. Pour cela, la
compltude de l'algbre relationnelle est exploite, c'est--dire qu'elle est quivalente la logique des
prdicats du premier ordre (sans fonctions). Il s'agit d'un rsultat important que nous admettrons
simplement ici. Une requte s'exprime donc comme une assertion sur la base de donnes. Le critre
logique que doivent vrifier les tuples du rsultat est spcifi ; cette assertion dcrit une caractristique
du rsultat, indpendamment de la faon de l'obtenir. C'est le systme qui, partir de l'expression d'une
assertion, gnre une excution particulire, c'est--dire une certaine squence d'oprateurs
relationnels.

La premire tentative pour construire un vritable langage de requtes, transformable en squence

d'oprations relationnelles, date de 76 : le langage SEQUEL du laboratoire IBM de San Jos. C'est lui qui
donnera plus tard naissance SQL (Structured Query Language).

IV.1.

LE STANDARD SQL

Hier norme de fait, SQL est devenu une norme de droit quand l'International Organization for
Standardization l'a pris en compte en 86 [ISO 86]. SQL est arriv maturit. Sa version normalise par
l'ISO fige ses diffrents aspects : dfinition des concepts, du vocabulaire, du langage de dfinition de
donnes (dclaration du schma, des vues, du contrle des autorisations) et du langage de manipulation
sont dsormais stabiliss. Les procdures d'intgration des appels SQL dans un langage hte (de type

page 49

Cobol, Pascal, C, Fortran), regroupes sous le nom de "Embedded SQL", souvent not ESQL, sont
galement dfinies. Presque tous les constructeurs proposent le langage SQL. Plus de 70 produits du
march le fournissent, sur des machines qui vont du PC au plus importants mainframes. Celui-ci tend
mme sa perce vers des produits micros qui, sans devenir de vritables SGBD relationnels complets,
intgrent dj la partie de SQL qui concerne la manipulation des donnes.

SQL

est un facteur important de promotion du modle relationnel. Il apporte une vision unifie et une

large communaut de concepts et de vocabulaire. Reposant sur une base thorique solide (la logique
des prdicats), il concerne la fois les administrateurs, les programmeurs d'applications, et les
utilisateurs finals pour la dfinition et la manipulation des donnes.

IV.1.1.

Elments d'un langage pour les SGBD relationnels

La norme SQL comporte trois parties distinctes concernant :

-

la manipulation de l'information ; le (DML : Data Manipulation Language) concerne

l'ensemble des requtes de recherche et de mise jour des informations : selection,
insertion, modification et suppression. Il est essentiellement destin l'utilisateur final ;

la dfinition des structures de donnes ; le DDL (Data Definition Language) contient

l'ensemble des commandes de cration, de suppression, de modification des relations. Elle
intgre la crations, la suppressions de chemins d'accs (index) et les commandes
concernant la gestion des droits et des autorisations. Elle est largement destine
l'administrateur ;

l'accs aux informations stockes dans le SGBD depuis un langage de programmation ; l'
Embedded SQL dfinit l'ensemble des interfaces, l'utilisation des ordres SQL dans un
langage de programmation, ainsi que l'ensemble des codes d'erreur renvoys par le SGBD
au programme d'application dfini. L' Embedded SQL est destin au programmeur
d'applications.

La liste des avantages et inconvnients de la norme SQL telle qu'elle se prsente aujourd'hui peut tre
rapidement dresse : son actif, citons sa simplicit, sa souplesse et ses fonctionnalits tendues ;
son passif, un manque de rigueur (il autorise - et encourage - certaines formulations procdurales), une
utilisation lourde (mot cls, pas d'utilisation de moyens modernes d'interface homme/machine), le fait
qu'il constitue, comme toute norme, un frein la crativit des concepteurs de nouveaux systmes.
Rappelons enfin qu'il s'agit d'un langage invent par IBM, argument stratgique dlicat placer dans les
qualits ou les dfauts du langage.

page 50

La normalisation de SQL, dont la premire version a t acheve en 86, conduit galement se poser
la question " qui peut servir la normalisation ?". En effet, si l'on examine les diffrentes parties de la
norme, on constate que l'administrateur doit disposer d'outils moins primitifs et plus spcifiques pour
grer convenablement son SGBD ; l'utilisateur final a bien du mal utiliser directement SQL en
interactif : il utilise des interfaces spcifiques (menus, crans) plus conviviales ; enfin le
programmeur d'applications est aujourd'hui largement sollicit par les Langages de quatrime
Gnration (L4G) qui, sans tre normaliss, sont plus pratiques et procurent les mmes services de
base que du Embedded SQL. Certaines mauvaises langues en concluent donc que la normalisation ne
sert qu'aux normalisateurs L'apport de la normalisation du SQL est cependant indiscutable pour les
utilisateurs dsirant garantir la portabilit de leurs applications d'un systme SQL sur un autre. C'est
l'interface standard de tout vritable SGBD relationnel. Il prcise, d'autre part, un niveau d'interface
prcis lorsqu'on envisage des systmes rpartis et htrognes.

Comme pour les oprateurs de l'algbre relationnelle, nous illustrerons l'utilisation de SQL sur la basejouet suivante :
PLAGE (NP, NOMP, TYPE, REGION, POLLUTION)
NAGEUR (NN, NOM, PRENOM, QUALITE)
BAIGNADE (NN, NP, DATE, DUREE)

o NP dsigne le numro de plage, NN le numro de nageur.

IV.1.2.

SQL

Expression des oprations relationnelles

permet d'exprimer simplement les oprations relationnelles de base.

Le bloc

SQL

se compose du mot-cl

rsultat, du mot cl
WHERE,

FROM,

SELECT,

suivi des attributs qu'on dsire voir figurer dans le

suivi de la liste des relations touches par la question, enfin du mot cl

suivi d'une qualification. Deux blocs SQL peuvent tre conjugus par lun des oprateurs

binaires de lalgbre relationnelle : UNION, INTERSECT, MINUS.

SELECT <liste d'attributs projets>

FROM <liste de relations>
WHERE <qualification>

page 51

Expression de projections
L'obtention de colonnes dtermines s'effectue simplement en omettant de spcifier une
qualification (le prdicat absent derrire le WHERE est alors suppos 'vrai' pour tous les tuples).
SELECT NOMP, REGION
FROM PLAGE

permet d'obtenir l'ensemble des couples (nom_de_plage, rgion) prsents dans la relation
PLAGE.

Cependant l'limination des doubles n'est pas automatique : pour lister l'ensemble des

rgions distinctes on utilise le mot cl DISTINCT:

SELECT DISTINCT REGION
FROM PLAGE

Enfin, les mots cls ORDER BY, ASC, DESC permettent de complter le langage et d'ordonner les
rsultats pour l'utilisateur. Ainsi, pour obtenir toutes les plages, tries par ordre alphabtique
dcroissant sur les pollutions et croissant sur les noms de plage, on crit :
SELECT *
FROM PLAGE
ORDER BY POLLUTION DESC, NOMP ASC

L'utilisation du "*" permet de demander tous les attributs de la relation.

Expression des restrictions
La restriction consiste slectionner l'ensemble des tuples vrifiant le critre plac dans la
clause WHERE. Ce critre de restriction est une combinaison de critres lmentaires, connects
l'aide de AND et de OR et pouvant prsenter des NOT. Le critre atomique est de la forme
<Attribut valeur> ou <Attribut1 Attribut2>. Le comparateur appartient l'ensemble {=,
<>, >, , <, }.
Un bloc permettant d'exprimer la restriction est par exemple:
SELECT *
FROM NAGEUR
WHERE QUALIT = 'mdiocre' OR PRNOM <> 'Jean'

La forme <Attribut1 Attribut2> exprime un critre de restriction s'il s'agit d'une comparaison
entre la valeur de l'Attribut1 et la valeur de l'Attribut2 du mme tuple. Le critre est valu
pour chaque tuple en comparant deux valeurs d'attributs diffrents du mme tuple. Par
exemple, pour connatre les bains pris sur des plages de mme identifiant (NP) que celui du
baigneur (NN) - smantiquement peu intressant! - on crirait :
SELECT *
FROM BAIGNADE

page 52

WHERE NP = NN

La slection mono-relation gnrale utilise un bloc SQL qui combine une restriction et une
projection. Ainsi, pour obtenir les plages de sable de Bretagne, tries par ordre alphabtique
dcroissant sur les pollutions et croissant sur les noms de plage, on crira :
SELECT NP, NOMP, POLLUTION
FROM PLAGE
WHERE TYPE = 'sable' OR REGION <> 'Bretagne'
ORDER BY POLLUTION DESC, NOMP ASC

Expression des jointures

L'expression de questions multi-relations en SQL , c'est--dire de questions mettant en uvre,
dans le rsultat ou dans la qualification, des informations issues de plusieurs relations,
ncessite d'exprimer l'opration de jointure.
SQL

propose deux faons d'exprimer la jointure : l'une est vritablement assertionnelle, l'autre

reste procdurale et utilise une imbrication de blocs de base (un bloc de base est un ensemble
SELECTFROMWHERE).

Exemple : donner les noms des nageurs ayant pris un bain

a) Expression assertionnelle :
SELECT NOM
FROM NAGEUR, BAIGNADE
WHERE NAGEUR.NN = BAIGNADE.NN

Pour distinguer deux attributs portant le mme nom, ceux-ci sont prfixs par le nom de la
relation d'origine
b) Expression procdurale
SELECT NOM
FROM NAGEUR
WHERE NN IN (SELECT NN
FROM BAIGNADE)

page 53

Cette manire d'exprimer la jointure prsente deux inconvnients :

-

elle est procdurale et demande par consquent au systme d'excuter une squence

d'oprations particulires. L'optimisation et l'ordonnancement ne sont plus mis en uvre

par le systme ; une question mal pose peut, par consquent, entraner des temps de
rponse catastrophiques. Nanmoins certains bons systmes acceptent une question ainsi
formule, mais la transformer en une assertion de faon pouvoir ensuite utiliser leur
optimiseur.
-

elle ne permet pas d'exprimer une 'vraie' jointure : en effet seuls les attributs originaires
d'une seule des deux relations peuvent tre prsents dans le rsultat ; il s'agit en fait d'une
semi-jointure

Dfinition : semi-jointure:
la semi-jointure de R1 par R2, note R1 |X R2, est la jointure de R1 et de R2 projete sur
les attributs de R1.
La semi-jointure peut tre considre comme une gnralisation de la restriction. Ceci explique
en effet son cot relativement faible : l'opration n'exige qu'une seule passe sur chaque relation.
La relation R2 est d'abord lue pour obtenir les valeurs de l'attribut de jointure ; puis la relation
R1 est restreinte avec les valeurs de l'attribut de jointure apparaissant dans R2. Chacun des
tuples de R1 et R2 n'est lu qu'une seule fois.
L'utilisation de blocs imbriqus dans SQL permet cependant d'exprimer simplement des
prdicats quantifis (, ) grce aux sous-questions (voir IV.1.3).
Remarque: restriction et auto-jointure
La prsence de prdicat de la forme <Attribut1 Attribut2> dans une qualification peut
correspondre soit un prdicat de jointure, soit un prdicat de restriction. En fait, la question
est de savoir si la comparaison porte sur la valeur des attributs 1 et 2 d'un mme tuple ou de
tuples diffrents. Si l'Attribut1 et l'Attribut2 sont prfixs par une variable relation identique
(ou ne le sont pas dans les cas o il n'y a pas d'ambigut sur la relation), il s'agit des valeurs du
mme tuple. C'est donc d'un critre de restriction. Si l'Attribut1 et l'Attribut2 sont prfixs par
des variables relations diffrentes, il s'agit de la comparaison d'une valeur de l'Attribut1 avec
toutes les valeurs de l'Attribut. C'est donc d'un critre de jointure.

page 54

Question :
SELECT NN
FROM NAGEUR
WHERE NOM = PRENOM

exprime la requte 'quels sont les nageurs dont le nom est identique au prnom ?'
(restriction);
en explicitant par une variable N1 le lien attributs- relation, la question devient :
SELECT N1.NN
FROM NAGEUR N1
WHERE N1.NOM = N1.PRENOM

alors qu'en crivant:

SELECT N1.NN
FROM NAGEUR N1, NAGEUR N2
WHERE N1.NOM = N2. PRENOM AND N1.NN <> N2.NN

on exprimerait 'quels sont les nageur ayant pour nom le prnom d'un autre nageur ?'
(auto-jointure). Deux variables distinctes N1 et N2 sont dclares cette fois-ci sur la
relation NAGEUR. SQL, on le voit, oblige a plus de prcision que la langue "naturelle".
IV.1.3.

Sous-questions, prdicats quantifis, composition de questions

L'utilisation de blocs imbriqus permet d'exprimer simplement et de faon trs comprhensible des
expressions quantifies. Le bloc interne est alors une sous-question.
Dfinition : sous-question
Une sous question est une question SQL qui rend une seule colonne
Cette colonne est un ensemble de valeurs qui constitue l'argument d'un prdicat IN, ALL, ANY ou
EXISTS

du bloc externe (dans le cas du EXISTS la sous-question peut rendre un nombre quelconque de

colonnes).

Illustrons ces possibilits sur des exemples :

a) Prdicat IN : quels sont les nageurs qui se sont baigns (au moins une fois) sur une plage trs
pollue ?
SELECT NN FROM BAIGNADE
WHERE NP

IN

(SELECT NP FROM PLAGE

WHERE POLLUTION = 'leve')

page 55

IN

est le test de prsence de la valeur d'un attribut dans un ensemble de valeur du mme type. On

l'utilise pour exprimer la semi-jointure.

b) Prdicat EXISTS : quels sont les nageurs qui se sont [ne se sont pas] baigns en 89 ?
SELECT *
FROM NAGEUR N
WHERE [NOT] EXISTS (SELECT * FROM BAIGNADE
WHERE DATE BETWEEN '01-JAN-89' AND '31-DEC-89'
AND B.NN = N.NN )

c) Prdicat ALL : quelle est la plus longue baignade ?

SELECT *
FROM BAIGNADE
WHERE

DUREE >=

ALL

(SELECT DISTINCT DUREE

FROM BAIGNADE)

d) Prdicat ANY : quels sont les noms des nageurs qui se sont baigns plus longtemps que Dupond ?
(qui se sont baigns au moins une fois plus longtemps qu'au moins une des baignades de Dupond)
SELECT N1.NOM
FROM NAGEUR N1, BAIGNADE B1
WHERE N1.NN = B1.NN
AND

B1. DUREE > ANY

(SELECT DISTINCT DUREE

FROM BAIGNADE B2, NAGEUR N2
WHERE B2.NN = N2.NN
AND N2.NOM = 'Dupond')

Enfin, on peut composer logiquement - par union, intersection, diffrence, cf. III.2.1 - deux questions
SQL. Si, par exemple, on voulait comparer notre table de nageurs une table d'lves qui aurait le
schma ELEVE(NE, NOM, PRENOM, AGE) alors les expressions SQL suivantes sont possibles - et
leur sens est identique celui des expressions algbriques quivalentes :
SELECT NOM , PRENOM FROM ELEVE

UNION

SELECT NOM , PRENOM FROM NAGEUR

INTERSECT
MINUS

page 56

IV.1.4.

Fonctions et groupements

La norme SQL prsente un ensemble de fonctions prdfinies : COUNT, SUM, AVG, MAX et MIN. Ces
fonctions oprent sur une collection de valeurs scalaires d'une colonne (ventuellement plusieurs pour
COUNT)

d'une relation.

COUNT nombre

de valeurs de la colonne ;

SUM

somme des valeurs de la colonne (argument de type numrique) ;

AVG

moyenne des valeurs de la colonne (argument de type numrique) ;

MAX

plus grande valeur de la colonne ;

MIN

plus petite valeur de la colonne.

Cette collection de valeurs scalaires d'une colonne est obtenue en effectuant un agrgat.
Dfinition : agrgat
Un agrgat est un partitionnement horizontal (les tuples sont rpartis en plusieurs groupes)
d'une relation selon des valeurs d'attributs, suivi d'un regroupement par une fonction de
calcul (somme, moyenne, minimum, maximum, compte)
Les fonctions s'appliquent sur un agrgat dfini par les attributs figurant derrire un mot cl GROUP BY,
et aprs application d'un ventuel critre figurant derrire un mot cl WHERE.

La clause HAVING permet d'appliquer un critre de restriction sur des groupes.

Exemple :
Donner, par numro de plage, la dure moyenne et la somme des dures des baignades
effectues aprs le 1/1/88, lorsque les dures cumules dpasse 200 minutes.
SELECT NP, AVG(DURE), SUM(DURE)
FROM BAIGNADE
WHERE DATE '01-JAN-88'
GROUP BY NP
HAVING SUM(DURE) > 200

Le systme excute d'abord la restriction, puis effectue le regroupement, le calcul des fonctions
et la restriction sur le rsultat du calcul ; exemple excution de la question prcdente :

page 57

BAIGNADE

DATE

12/1/88
2/12/87
16/2/88
3/3/88
10/3/88

NP DURE

NN

30
43
30
43
30

67
24
45
12
24

72
24
46
12
92

WHERE DATE 01/01/88

BAIGNADE

DATE

12/1/88
16/2/88
3/3/88
10/3/88

NP DURE

NN

30
30
43
30

67
45
12
24

72
46
12
92

GROUP BY NP

BAIGNADE

DATE

NP DURE

NN

12/1/88
16/2/88
10/3/88

30
30
30

72
46
92

67
45
24

3/3/88

43

12

12

CALCUL DES FONCTIONS

BAIGNADE

NP
30
43

AVG(DURE)
70
12

page 58

SOM(DURE)
210
12

HAVING SOM(DURE) > 200

BAIGNADE

NP

AVG(DURE)

30

IV.1.5.

SQL

70

SOM(DURE)
210

Mises jour

propose trois clauses correspondant aux diffrents types de mises jour possibles sur une base de

donnes : l'insertion (clause INSERT), la modification (clause UPDATE) et la suppression (clause

DELETE).

Insertion
Une insertion est l'ajout d'un ou plusieurs tuples dans une relation. On peut insrer, par la
commande INSERT, des tuples explicitement mais un par un; le mot-cl VALUES prcde les
valeurs de ses attributs.
INSERT INTO NAGEUR
VALUES (145, 'BOUJUS', 'Jacques', 'excellent')

On peut galement insrer directement un ensemble de tuples. Cet ensemble de taille

quelconque doit tre le rsultat d'une requte ensembliste. La seule condition est que le schma
de la relation rsultat (nombre et types des attributs) soit le mme que celui de la relation dans
laquelle on ajoute des valeurs. On parle dans ce cas d'insertion calcule.
La puissance d'expression d'un langage relationnel s'affirme ici clairement. Ainsi la requte :
INSERT INTO BAIGNADE
SELECT '10', NP, DATE, DUREE
FROM BAIGNADE
WHERE NN = '20'

ajoute pour le nageur 10 les baignades effectues par le nageur 20.

Mise jour
L'aspect ensembliste du langage est ici encore particulirement utile pour les applications.
Accder aux tuples un par un n'est pas ncessaire. Il suffit d'exprimer correctement la condition
qui conduit la modification.

page 59

Par exemple :
UPDATE PLAGE
SET POLLUTION = 'leve'
WHERE REGION = 'Bretagne'
AND NP IN

( SELECT NP FROM BAIGNADE

GROUP BY NP, DATE
HAVING COUNT (NN) > 5000 )

permettra de prendre en compte le fait qu'une forte frquentation des plages de Bretagne (les
plages ayant vu plus de 5000 baignades en un jour !) entrane une pollution leve.
Suppression
Enfin, la suppression ensembliste s'exprime elle aussi trs simplement. On supprime
directement les mauvais nageurs considrs comme noys au del de 300 minutes dans l'eau.
DELETE FROM NAGEUR
WHERE QUALITE = 'excrable'
AND NN IN

( SELECT NN FROM BAIGNADE

WHERE DURE > 300 )

ou, dans un exemple plus srieux, on supprime les baignades de Dupond comme ceci :
DELETE FROM BAIGNADE
WHERE NN IN ( SELECT NN FROM NAGEUR
WHERE NOM = 'Dupond' )

IV.1.6.

Le langage de dclaration de donnes

Rappelons qu'une base de donnes est dfinie par un schma. Ce schma est compos d'un ensemble
de relations. La cration d'une nouvelle relation (vide) est ralise par l'instruction :
CREATE TABLE nom_de_relation ( liste de noms_d'attributs )

Chaque nom d'attribut a un type (CHARACTER, NUMERIC, DECIMAL, INTEGER, SMALLINTEGER, FLOAT,
REAL).

Une contrainte NOT NULL ou UNIQUE peut, de surcrot, tre impos un attribut . Dclarer une

cl utilise simultanment ces deux contraintes.

page 60

Exemple :
CREATE TABLE PLAGE (

NP INTEGER NOT NULL UNIQUE,

NOMP CHARACTER(30) NOT NULL,
REGION CHARACTER (30),
POLLUTION CHARACTER (20) )

CREATE TABLE NAGEUR

NN INTEGER NOT NULL UNIQUE,

NOM CHARACTER(15) NOT NULL,
PRENOM CHARACTER(15),
QUALIT CHARACTER(20) )

CREATE TABLE BAIGNADE

NN INTEGER NOT NULL,

NP INTEGER NOT NULL,
DATE CHARACTER(8) NOT NULL,
DURE INTEGER ,
UNIQUE (NN, NP, DATE) )

Remarquez l'utilisation de la clause UNIQUE dans la cration de BAIGNADE : il s'agit ici de dclarer une
cl multi-attributs (il n'existe pas deux triplets identiques de valeurs NN, NP, DATE). Chaque attribut NN,
NP

et DATE est dclar NOT NULL, puis l'unicit du triplet est dclare.

La clause CREATE TABLE est beaucoup plus complte que nous ne l'indiquons ici : elle permet
notamment de prciser d'autres contraintes d'intgrit, des droits ainsi qu'un certain nombre de
contraintes concernant l'implantation physique de la relation.

IV.1.7.

Intgration d'un langage de manipulation de donnes dans un langage de

programmation

L'intgration de SQL dans un langage de programmation apparat trs vite indispensable lorsqu'on
considre l'utilisation, par des programmes d'application, des informations stockes dans la BD
relationnelle. Deux approches sont possibles : la premire consiste intgrer le langage de
manipulation de donnes dans un langage de programmation quelconque, considr comme un langage
hte. La seconde, plus ambitieuse, tend un langage de programmation donn avec des clauses
spcifiques de la manipulation des donnes. Elle est reste jusqu' prsent du domaine de la recherche,
mais le problme, bien rel, de la "cohabitation" entre un langage de programmation procdural,
privilgiant un traitement unaire et un langage de manipulation ensembliste des donnes, redevient
d'actualit avec les Bases de Donnes Orientes Objet. L'approche Objet tente, en effet, de rconcilier
donnes et traitements.

page 61

La dmarche dominante d'intgration de SQL est prcise jusque dans la norme sous le nom de
Embedded SQL. Dans cette approche, les attributs des relations manipules sont d'abord dclars
comme des variables du langage de programmation. Un programme hte comporte des instructions
standard du langage, une section de dclaration, un ensemble de dfinitions de curseurs et un ensemble
de traitements SQL.

L'implantation d'un Embedded SQL est gnralement effectue l'aide d'une technique de
prcompilation. Le prcompilateur analyse des commandes SQL et insre des appels de sousprogrammes du langage hte destination du SGBD (cela suppose l'existence d'une bibliothque de
primitives de bas niveau entre le langage hte et le SGBD). Il recopie telles quelles les instructions du
langage hte. Le prcompilateur gnre en sortie, on obtient un programme en langage hte qui est
compilable par le compilateur de ce langage.

Nous donnons ici un exemple en C-Embedded SQL d'une mise jour sur l'attribut POLLUTIONde la
relation PLAGE :

#include <stdio.h>
EXEC SQL

INCLUDE SQLCA.H ;

main (argc,argv)
int argc ;

char *argv[]; {
char *answer[1];
EXEC SQL

EXEC SQL

BEGIN DECLARE SECTION ;

VARCHAR

db_connect_string[32];

VARCHAR

xx[32];

VARCHAR

yy[16];

VARCHAR

zz[16];

END DECLARE SECTION ;

strcpy(db_connect_string, argv[1]);
EXEC SQL

CONNECT : db_connect_string;

EXEC SQL

DECLARE C1 CURSOR FOR

SELECT nomp,

pollution FROM plage WHERE region = :yy

FOR UPDATE OF pollution;

page 62

while (printf("\nRgion? (\0 pour fin): ") && scanf("%s", zz) && strcmp(zz,'\0') != 0)
{
EXEC SQL OPEN C1 ;

while (sqlca.sqlcode = 0) {
EXEC SQL FETCH C1 INTO :xx,

/* la

structure sqlca est dans SQLCA.H*/

:zz;

printf("\n%32s, qui tait %16s, devient-elle Alarmante? (O|N)", xx, zz) ;

scanf("%s", answer) ;
if (answer == 'O')
EXEC SQL

UPDATE PLAGE

SET pollution = 'Alarmante'

WHERE CURRENT OF C1 ;

} /* end of while cursor open */

EXEC SQL CLOSE C1 ;
EXEC SQL

COMMIT WORK ;

} /* end of while Rgion indique */

} /* end of main */
Commentaires
-

un traitement SQL est annonc par EXEC SQL et termin par un caractre point-virgule ;

toutes les variables htes rfrences dans un traitement SQL sont dfinies ; dans une
"embedded declare section", dlimite par un BEGIN DECLARE SECTION et un END
DECLARE SECTION

le type des variables htes doit tre compact avec celui des attributs qui les accueillent ;

tout programme SQL doit inclure une variable hte appel SQLCODE. A chaque excution
d'un traitement SQL, l'indicateur numrique SQLCODE, renvoie le rsultat de la requte SQL
(OK, OK, fin curseur).

un traitement SQL inclut des rfrences aux variables htes. Celles-ci doivent tre prfixes
par un nom d'attribut pour les distinguer.

Des curseurs. sont utiliss pour traiter des ensembles de tuples dans le langage. Le mcanisme de
curseur permet un traitement unaire (tuple tuple) d'un ensemble de tuples fourni par le SGBD, par le
langage hte, en rponse une requte SQL. Les curseurs peuvent tre ouverts (OPEN C) , ferms
(CLOSE C), positionns en lecture sur un tuple (ordre FETCH) et utiliss comme position de rfrence
(CURRENT OF C).

Remarquez que cette approche, prsent normalise, est assez riche en possibilits ; elle est cependant
relativement lourde mettre en uvre et l'on peut s'attendre dans les prochaines annes son abandon
progressif au profit des langages de quatrime gnration (L4G).

page 63

Langage de quatrime gnration

Nous terminerons cette section par quelques mots sur les langages de quatrime gnration.
Concernant directement les dveloppeurs d'applications, ces langages visent faire gagner du
temps et baisser les cots d'criture des programmes. Ils utilisent largement les possibilits des
SGBD

relationnels travers une manipulation essentiellement ensembliste des donnes. Ils ne

constituent cependant pas simplement un langage de manipulation de donnes comme

SQL,

mais

intgrent un ensemble complet de possibilits de traitement en fournissant des structures de

contrle d'un langage structur de haut niveau (boucle, condition, parcours). Ils s'efforcent, de
surcrot, d'intgrer un ensemble d'outils (gnrateurs de rapports, de graphiques, d'applications)
souvent disponibles comme des logiciels adjoindre au

SGBD.

Orients vers la programmation

visuelle, ils constituent parfois un vritable environnement de dveloppement et sont aujourd'hui

l'objet d'une forte demande.

Il ne faut cependant pas perdre de vue que ces langages modernes ne constituent qu'une couche de
manipulation des informations stockes dans un

SGBD.

La qualit, les performances, la puissance

d'expression rsulte, en dernire analyse, essentiellement la qualit du

SGBD

relationnel sous-

jacent.

Signalons de surcrot qu'un

L4G

ne fournit aucun support une gestion de transactions (voir

chapitre 6), ncessaire tout usage multi-utilisateurs : cette gestion de transactions doit alors tre
prise en compte au niveau de l'application. Les

L4G

ne sont pas l'objet d'une dfinition standard

accepte par tous : ce jour, le choix d'un L4G particulier condamne l'utilisateur une dpendance
totale envers son fournisseur. Certains L4G gnrent cependant du SQL standard, lment favorable
qui peut tre pris en compte dans le choix.

page 64

IV.2.

AUTRES LANGAGES RELATIONNELS

Deux autres langages mritent d'tre mentionns : QUEL et QBE.

IV.2.1.

QUEL

Le langage QUEL fut le concurrent malheureux de SQL sur le terrain de la normalisation. Trs proche, il
constitue le langage natif du prototype INGRES de BERKELEY (INGRES, prsent propose les deux
langages QUEL et SQL).

Sa syntaxe oblige dclarer des variables sur les relations manipules:

RANGE OF variable IS nom-de-relation

Plusieurs variables peuvent tre associes une relation. Les recherches lmentaires s'expriment par
les clauses :
RETRIEVE (liste rsultat)
WHERE qualification

Exemple :
donner le nom des nageurs qui se sont baigns la fois Deauville et Bayonne en 1983.
RANGE OF P, P', N, B, B' IS PLAGE, PLAGE, NAGEUR, BAIGNADE, BAIGNADE
RETRIEVE N.NOM
WHERE N.NN = B.NN AND B.NP = P.NP AND B.DATE = '1983' AND P.NOM = 'Deauville'
AND N.NN = B'.NN AND B'.NP = P'.NP AND B'.DATE = '1983' AND P'.NOM = 'Bayonne'

Seules les recherches avec fonctions et agrgats s'loignent de SQL par exemple :
RETRIEVE AVG (B.DURE WHERE B.DATE = '02-07-89')

permet de demander la dure moyenne des baignades du 2 juillet 1989.

IV.2.2.

Query By Example (QBE)

La langage QBE est conu comme un langage graphique. Dvelopp par IBM Yorktown Height, et
aujourd'hui commercialis par IBM. Il est bas sur une mise en uvre visuelle des questions et des
rsultats ; il constitue ce titre un prcurseur des langages visuels d'aujourd'hui.

page 65

Lorsqu'un utilisateur dsire utiliser les informations d'une relation, il en demande l'affichage du
squelette, c'est--dire le schma. C'est dans ce squelette qu'il spcifie ses requtes. Nous illustrons trs
rapidement les possibilits de QBE par quelques questions simples.

a) Quelles sont les dures des baignades du baigneur N10 ?

BAIGNADE

NN

NP

DATE DURE

10

P.

b) Quelles sont les pollutions des plages o s'est baign Durand ?

BAIGNADE NN

NP

100

200

NAGEUR NN

DATE DURE

100

NOM

PRENOM QUALIT

Durand

PLAGE NP NOMP TYPE RGION POLLUTION

200

P.

on utilise ici la notion de variable exemple (une chane quelconque souligne est un exemple)
pour exprimer la jointure entre deux relations. Le "P." indique la colonne demande en rsultat.

c) Lister les noms des plages de sable moins pollues que la plage n 10.
PLAGE NP NOMP TYPE RGION POLLUTION
10

Q
P.

sable

page 66

< Q

On a exprim ci-dessus une auto-jointure.

IV.3.

CONCLUSIONS

Les langages relationnels d'aujourd'hui s'articulent tous autour du SQL. Sa standardisation par l'ISO SQL1 ou SQL89, puis SQL2 ou SQL92 - est en effet incontournable, mais prsente des inconvnients
et des lourdeurs lies l'absence, de prise en compte des outils moderne d'interface (menus, multifentrage, souris). De surcrot, SQL, malgr son apparente simplicit, prsente des subtilits qui le
rendent difficilement utilisable par l'utilisateur final. Pour toutes ces raisons, l'ensemble des
constructeurs proposent aujourd'hui des outils (easy SQL, gnrateur de SQL) destins faciliter
l'tilisation interactive de SQL.

IV.4.

ANNEXE : SEMANTIQUE ET SYNTAXE DE SQL

a) Smantique de SQL
Afin de bien comprendre la smantique d'une requte SQL, il faut se rappeler qu' chaque ligne d'une
question correspond une opration. Les oprations sont interprtes dans l'ordre 1/ 2/ 3/ 4/ 5/ 6/.

SELECT
FROM

<liste d'attributs>

<liste de relations>

WHERE

5/ projection finale ;
1/ produit cartsien de toutes les relations cites ;

<qualification> 2/ applications des restrictions sur les tuples (aprs le produits cartsien,
tous les prdicats lmentaires de la qualification sont
des prdicats de restriction) ;

GROUP BY
HAVING

<liste d'attribut>

3/ calcul des agrgats et des fonctions ;

<qualification> 4/ application d'une restriction sur les groupes rsultant d'un calcul de
fonction ;

ORDER BY

<liste d'attribut>

6/ tri du rsultat.

Attention : il s'agit de l'interprtation smantique de la requte SQL ; il ne faut surtout pas en conclure
qu'un SGBD relationnel excute la requte de cette faon.

page 67

b) Rgles syntaxiques en grammaire BNF

Query expressions
query-exp

::=

query-term | query-exp [UNION | INTERSECT | MINUS query-term]

query-term

::=

query-spec | (query-exp)

query-spec

::=

SELECT [ALL | DISTINCT]

selection

::=

scalar-exp-commalist | *

table-exp

::=

from-clause

selection table-exp

[ where-clause ]
[ group-by-clause ]
[ having-clause ]
from-clause

::=

FROM

table-ref-commalist

table-ref

::=

table [range-variable]

where-clause

::=

search-condition

group-by-clause

::=

GROUP BY

having-clause ::=

HAVING

column-ref-commalist

search-condition

Search conditions
search-condition

::=

boolean-term | search-condition OR boolean-term

boolean-term

::=

boolean-factor | boolean-term AND boolean-factor

boolean-factor ::=

[ NOT] boolean-primary

boolean-primary

::=

predicate | ( search condition )

predicate

::=

comparison-predicate
| between-predicate
| like-predicate
| test-for-null
| in-predicate
| all-or-any-predicate
| existence-test

comparison-predicate ::=

scalar-exp comparison {scalar-exp | subquery}

comparison

::=

= | <> | < | > | |

between-predicate

::=

scalar-exp [NOT] BETWEEN scalar-exp AND scalar-exp

like-predicate

::=

column-ref [NOT] LIKE atom [ESCAPE atom]

test-for-null

::=

column-ref IS [NOT] NULL

in-predicate

::=

scalar-exp [NOT] IN
{ subquery | atom [, atom-commalist] }

all-or-any-predicate

::=

scalar-exp comparison [ALL | ANY | SOME ] subquery

existence-test

::=

EXISTS

subquery

::=

( SELECT [ALL | DISTINCT] selection table-exp )

subquery

page 68

Scalar expressions
scalar-exp

::=

term | scalar-exp { + | - } term

term

::=

factor term { * | / } factor

factor

::=

primary

[ + | - ] primary
::=

atom
| column-ref
| function-ref
| ( scalar-exp )

atom

::=

parameter-ref
| literal
| USER

parameter-ref

::=

parameter [ [INDICATOR] parameter

function-ref

::=

COUNT

distinct-function-ref

::=

{ AVG | MAX | MIN | SUM | COUNT } ( DISTINCT column-ref

(*) distinct-function-ref all-function-ref

)
all-function-ref ::=

{ AVG | MAX | MIN | SUM | COUNT } ( [ALL] scalar-exp )

column-ref

::=

[column-qualifier.] column

column-qualifier

::=

table | range-variable

IV.5.

REFERENCES

[Date 87] C.J. DATE : "A Guide to the SQL Standard", Addison-Wesley, 1987.

[ISO 86]

ISO ANSI,

"Database Language SQL", ISO/DIS 9075, Draft International Standard, 1986.

[ISO 88]

ISO ANSI,

"Database Language SQL2", Working Draft, 1988.

page 69

page 70

CHAPITRE 5 : BIEN CONCEVOIR UNE BASE DE DONNEES

Nous tidions dans ce chapitre comment bien concevoir une BD. Pour ce faire, partir d'un
mme ensemble de connaissances ayant trait aux plages, nous proposons deux choix
d'organisation des informations sous forme relationnelle. Nous tudions les qualits et les
dfauts de ces diffrents choix avant de prsenter les rgles de "bonne" conception d'une BD
relationnelle.
Premier choix :
BAINS (NN, NOM, PRENOM, QUALITE, DATE, DUREE, NP, NOMP, TYPE, REGION, POLLUTION)

Deuxime choix :
NAGEUR (NN, NOM, PRENOM, QUALITE)
PLAGE (NP, NOMP, TYPE, REGION, POLLUTION)
BAIGNADE (NN, NP, DATE, DUREE)
NN

et NP sont des numros permettant de distinguer respectivement les nageurs et les plages.

NN

est l'quivalent du numro de scurit sociale.

Nous constatons sur cet exemple l'existence de plusieurs faons de structurer un mme
ensemble d'informations. Si nous privilgions instinctivement l'une des deux solutions
proposes, c'est qu'elle correspond davantage notre perception du monde rel, dans laquelle
nous distinguons naturellement certaines entits : les personnes, les plages, etc.
L'tape de conception est primordiale pour le bon fonctionnement d'un SGBD. Elle fait partie
des quelques facteurs qui peuvent entraner des incohrences dans les rponses et une
diminution inacceptable des performances du systme ; c'est pourquoi il est indispensable d'y
attacher une attention toute particulire.
Une solution "instinctive" n'est pas suffisante pour concevoir le schma d'une base importante.
Il est donc ncessaire d'isoler les critres de dcision et de formaliser des mthodes de
conception des bases de donnes. Tel est l'objet de ce chapitre.
Les problmes les plus courants rencontrs dans des bases de donnes mal conues peuvent
tre regroups selon les critres suivants :

page 71

Redondance des donnes

Certains choix de conception entranent une rptition des donnes lors de leur insertion dans
la base. Cette redondance est souvent la cause d'anomalies provenant de la complexit des
insertions.
C'est, par exemple, le cas de la premire organisation propose : ds qu'une personne prend un
nouveau bain, on doit non seulement rpter son numro qui, par hypothse, suffit le
dterminer, mais aussi toutes les informations lies ce numro (son nom, son prnom, sa
qualit). Au contraire, dans le deuxime choix, seul le numro indispensable la distinction
d'un nageur est rpt. La situation est identique pour les plages.
Incohrence en modification

La redondance de l'information entrane galement des risques en cas de modification d'une

donne rpte en diffrents endroits : on oublie frquemment de modifier toutes ses
occurrences (en gnral par simple ignorance des diffrentes places o figure l'information).
Par exemple, dans la premire organisation propose, si une personne change de nom (cas
frquent lors de mariages), il faut changer ce nom dans tous les tuples o apparaissent ses
coordonnes. Dans la deuxime organisation, un seul tuple est modifi.
Anomalie d'insertion

Une mauvaise conception peut parfois empcher l'insertion d'un tuple, faute de connatre la
valeur de tous les attributs de la relation. Pour remdier ce problme, certains SGBD
implantent une valeur non type qui signifie que la valeur d'un attribut d'un tuple est inconnue
ou indtermine. Cette valeur (appele usuellement NULL) indique rellement une valeur
inconnue et non une chane de caractres vide ou un entier gal zro (analogie avec un
pointeur gal NIL en Pascal).
Dans le premier schma propos, insrer une nouvelle plage o personne ne s'est jamais
baign est aussi impossible.
Anomalie de suppression

Enfin, une mauvaise conception peut entraner, lors de la suppression d'une information, la
suppression d'autres informations, smantiquement distinctes, mais regroupes au sein d'un
mme schma.

page 72

C'est ce qui se produit dans notre premier exemple, la suppression d'une plage entrane
automatiquement la suppression de tous les nageurs ne s'tant baigns que sur cette plage.
De nombreux travaux ont permis de mettre au point une thorie de conception d'une base de
donnes relationnelle : la thorie de la normalisation, que nous allons maintenant dvelopper.

V.1.

LA THEORIE DE LA NORMALISATION

Cette thorie est base sur les "dpendances fonctionnelles" (DF). Les dpendances
fonctionnelles traduisent des contraintes sur les donnes (par exemple, on dcide que deux
individus diffrents peuvent avoir mme nom et prnom mais jamais le mme numro NN).
Ces contraintes sont reprsentatives d'une perception de la ralit et imposent des limites la
base.
Les dpendances fonctionnelles et des proprits particulires, dfinissent une suite de formes
normales (FN). Elles permettent de dcomposer l'ensemble des informations en diverses
relations. Chaque nouvelle forme normale marque une tape supplmentaire de progression
vers des relations prsentant de moins en moins de redondance. Ces tapes traduisent une
comprhension de plus en plus fine de la ralit.
Chacune de ces formes normales peut tre obtenue au moyen d'algorithmes de dcomposition.
Le point de dpart de ces algorithmes est la relation universelle, c'est--dire la relation qui
regroupe toutes les informations stocker (dans notre exemple, le premier schma reprsente
cette relation universelle) ; le but est d'obtenir, en sortie, une reprsentation canonique des
donnes prsentant un minimum de redondance l'intrieur de chaque relation et un
maximum d'indpendance entre les diffrentes relations .

page 73

Dpendances
fonctionnelles

nom

type

NN

rgion

dure

Normalisation

date
nomp

qualit
NP

prnom

R1()
R2()

pollution

relation universelle

V.1.1.

Les dpendances fonctionnelles

Dfinition : dpendance fonctionnelle

On dit qu'un attribut B dpend fonctionnellement d'un attribut A si, tant donn une valeur
de A, il lui correspond une unique valeur de B (quel que soit l'instant t considr).
Notation : A B
Exemple :
La dpendance fonctionnelle NN NOM signifie qu' un numro est associ un nom
unique (c'est, par exemple, le cas du numro de scurit sociale). Remarquons qu'une
dpendance fonctionnelle n'est gnralement pas symtrique, c'est--dire que NN NOM
n'interdit pas que deux personnes distinctes (correspondant deux NN diffrents) portent le
mme nom.

Une dpendance fonctionnelle est une proprit dfinie sur tous les tuples d'une relation et pas
seulement sur un tuple particulier. Elle traduit une certaine perception de la ralit (par
exemple, deux personnes distinctes peuvent porter le mme nom). Elle correspond une
contrainte qui doit tre vrifie en permanence.
Les dpendances fonctionnelles sont parties intgrantes du schma d'une BD. Elles doivent
donc thoriquement tre dclares par l'administrateur et contrles par le SGBD.

page 74

Exemple :

Nous dfinissons les proprits vrifies par notre base de baignades. Deux personnes
distinctes peuvent, par exemple, porter le mme nom, le mme prnom, et avoir la mme
qualit de nage. Deux numros de nageur diffrent les distinguent l'une de l'autre. Les
dpendances fonctionnelles que nous venons de dcrire sont donc
NN NOM, NN PRENOM, NN QUALITE

Nous pouvons supposer galement que deux plages distinctes ont toujours deux numros
diffrent ; ce qui implique :
NP NOMP
NP REGION

que la pollution et le type sont propres une plage :

NP POLLUTION
NP TYPE

et que deux plages d'une mme rgion ne peuvent porter le mme nom :
(NOMP, REGION) NP

Proprits des dpendances fonctionnelles

Les dpendances fonctionnelles obissent certaines proprits connues sous le nom

d'axiomes d'Armstrong.
Rflexivit :
Y

XZ

Augmentation :
X

YZ

Transitivit :
X

Y et

D'autres proprits se dduisent de ces axiomes :

Union :
X

Y et

YZ

XW

Pseudo-transitivit :
X

Y et

YW

Dcomposition :
X

Y et

page 75

L'intrt de ces axiomes et des proprits dduites est de pouvoir construire, partir d'un
premier ensemble de dpendances fonctionnelles, l'ensemble de toutes les dpendances
fonctionnelles qu'elles gnrent. On parle alors de dpendance fonctionnelle lmentaire.
V.1.2.

Dpendance fonctionnelle lmentaire

Dfinition : dpendance fonctionnelle lmentaire

Une dpendance fonctionnelle X A est lmentaire si
-

A n'est pas inclus dans X ;

il n'existe pas X' inclus dans X tel que X' A.

Cette notion de dpendance fonctionnelle lmentaire est primordiale car elle permet de
construire une sorte de famille gnratrice minimale (appele couverture minimale) des
dpendances fonctionnelles utiles pour structurer la base.
Exemple :

Deux plages d'une mme rgion ne peuvent pas porter le mme nom (contrairement deux
plages de rgions diffrentes) ; le degr de pollution d'une plage dpend exclusivement de la
plage et non de la rgion. On a alors
(NOMP, REGION) POLLUTION

mais on n'a aucunement

NOMP POLLUTION
ni
REGION POLLUTION

donc (NOMP, REGION) POLLUTION est une dpendance fonctionnelle lmentaire.

V.1.3.

Graphe des dpendances fonctionnelles

C'est une reprsentation graphique permettant de visualiser aisment toutes les dpendances
fonctionnelles et d'isoler les principales (i.e. les DF lmentaires).
Exemple :

Toutes les dpendances fonctionnelles cites prcdemment peuvent tre reprsentes de la

faon suivante.

page 76

PRENOM
NN

NOM
DATE
QUALITE
DUREE
REGION

POLLUTION

NP
NOMP

V.1.4.

TYPE

Fermeture transitive

Dfinition : fermeture transitive

La fermeture transitive d'un ensemble de dpendances fonctionnelles est ce mme ensemble

enrichi de toutes les dpendances fonctionnelles dduites par transitivit.
Exemple :

De l'exemple prcdent , on dduit par transitivit deux nouvelles dpendances

fonctionnelles :
(NOMP, REGION) TYPE
(NOMP, REGION) POLLUTION

page 77

qui enrichit le graphe de la faon suivante :

PRENOM
NN

NOM
DATE
QUALITE
DUREE
REGION

POLLUTION

NP
NOMP

V.1.5.

TYPE

Couverture minimale

Dfinition : couverture minimale

La couverture minimale d'un ensemble de dpendances fonctionnelles est un sous
ensemble minimum de dpendances fonctionnelles lmentaires permettant de gnrer
toutes les autres.
Exemple :
L'ensemble des dpendances fonctionnelles suivant :
(NN NOM, NN PRENOM, NN QUALITE, NP NOMP, NP REGION, (NOMP, REGION)
POLLUTION, (NOMP, REGION) NP)

est une couverture minimale de l'ensemble des dpendances fonctionnelles.

Thorme :
Tout ensemble de dpendances fonctionnelles admet une couverture minimale, en gnral
non unique.
Exemple :
L'ensemble des dpendances fonctionnelles suivant :
(NN NOM, NN PRENOM, NN QUALITE, NP NOMP, NP REGION, NP POLLUTION,
(NOMP, REGION) NP)

est une autre couverture minimale de l'ensemble des dpendances fonctionnelles.

La recherche de la couverture minimale d'un ensemble de dpendances fonctionnelles est un

lment essentiel du processus de normalisation, dont le but est de dcomposer une relation en
plusieurs relations plus petites.

page 78

V.1.6.

Cl d'une relation

Dfinition : cl d'une relation

Soit R(A1, A2, ..., AN) un schma de relation, soit F+ l'ensemble des dpendances
fonctionnelles associes R, soit X un sous-ensemble de A1, A2, ..., AN, on dit que X est
une cl de R si et seulement si
-

X A1, A2, ..., AN ;

il n'existe pas de sous ensemble Y inclus dans X tel que Y A1, A2, ..., AN.

Une cl d'une relation est un ensemble minimum d'attributs qui dtermine tous les autres.
Exemple :
NN

est cl de la relation PERSONNE (NN, NOM, PRENOM, QUALITE) ;

(NOMP, REGION)

est cl de la relation (NP, NOMP, REGION, POLLUTION, TYPE).

Plusieurs cls peuvent tre candidates pour une mme relation.

Exemple :
NP

et (NOMP, REGION) sont deux cls candidates la relation (NP, NOMP, REGION,

POLLUTION, TYPE).

Dans l'criture des schmas de relations, on indique les cls en soulignant les attributs
constitutifs.
Exemple :
PLAGE (NP, NOMP, REGION, POLLUTION, TYPE)

V.1.7.

Dcomposition des relations

La thorie de la normalisation repose sur un principe de dcomposition des relations.

Dfinition : dcomposition d'une relation
La dcomposition d'un schma de relation R(A1, A2, ..., AN) est son remplacement par une
collection de schmas de relations (R1, R2, ..., Ri) telle que :
SCHEMA(R) = SCHEMA(R1) SCHEMA(R2) ... SCHEMA (Ri).

Dfinition : dcomposition sans perte

Une dcomposition d'une relation R en N relations R1, R2, ..., RN est sans perte si et
seulement si, pour toute extension de R, on a :
R = R1 |x| R2 |x| ... |x| RN
Thorme : dcomposition sans perte
Une dcomposition en deux relations est sans perte si l'attribut de jointure de la
recomposition est cl d'une au moins des deux relations.

page 79

Dfinition : dcomposition prservant les dpendances fonctionnelles

Une dcomposition (R1, R2, ..., RN) de R prserve les dpendances fonctionnelles si la
fermeture des dpendances fonctionnelles de R est la mme que celle de l'union des
dpendances fonctionnelles des relations R1, R2, ..., RN.
V.2.

LES TROIS PREMIERES FORMES NORMALES

Nous dfinissons ici des rgles de dcomposition la relation universelle sans perdre
d'information en utilisant les dpendances fonctionnelles. Le but est d'obtenir une
reprsentation du monde rel qui minimise la redondance et les risques d'anomalies lors des
mises jour.

V.2.1.

La premire forme normale 1FN

Dfinition : premire forme normale

Une relation est en premire forme normale si tout attribut est atomique.
Consquences :
-

un attribut reprsente une donne lmentaire du monde rel ;

un attribut ne peut dsigner, ni une donne compose d'entits de nature quelconque, ni

une liste de donnes de mme nature.

La premire forme normale correspond un souci de simplicit au niveau du langage de

manipulation. Elle a pour particularit d'viter toute hirarchie dans une relation en interdisant
les domaines composs de plusieurs valeurs.
Exemple :
Nous pourrions imaginer une relation BAINS de schma BAINS (NN, NP, DATE,
DUREES) o DUREES serait la liste des dures des bains pris par le nageur NN sur la plage
NP

la date DATE. A lieu de cela, la premire forme normale nous oblige dcomposer

cette relation en BAINS (NN, NP, DATE, DUREE) ce qui induira autant de tuples qu'il y a
de baignade d'un mme baigneur, sur la mme plage, le mme jour ; avec (nn, np, date,
durei) pour le ime bain de la journe.
V.2.2.

La deuxime forme normale 2FN

Dfinition : deuxime forme normale

Une relation est en deuxime forme normale si et seulement si :
-

elle est en premire forme normale ;

tout attribut n'appartenant pas une cl ne dpend pas que d'une partie de cette cl.

page 80

Exemple :
Considrons la relation PLAGE de schma suivant :
PLAGE (NOMP, REGION, TYPE, POLLUTION)

o la cl est (NOMP, REGION). Supposons que la pollution est bien dpendante de la plage
mais que le type est, quant lui, dpendant de la rgion. La deuxime forme normale nous
impose de distinguer deux relations R1 et R2 de schmas respectifs :
R1 (NOMP, REGION, POLLUTION) ;
R2 (REGION, TYPE).

V.2.3.

La troisime forme normale 3FN

L'objectif de cette troisime forme normale est l'limination des redondances dues aux
dpendances fonctionnelles dduites par transitivit.
Dfinition : troisime forme normale
Une relation est en troisime forme normale si :
-

elle est en deuxime forme normale ;

tout attribut n'appartenant pas une cl ne dpend pas d'un attribut non cl.

Thorme :
Toute relation R admet au moins une dcomposition (R1, R2, ..., RN) en troisime forme
normale telle que :
-

la dcomposition conserve les dpendances fonctionnelles ;

la dcomposition est sans perte.

Exemple :
Considrons maintenant la relation PLAGE de schma PLAGE (NP, REGION, TYPE,
POLLUTION) o la cl est NP. Supposons maintenant comme dans l'exemple prcdent
que le type est dpendant de la rgion. La troisime forme normale nous impose de
distinguer deux relations R1 et R2 de schmas respectifs :
R1 (NP, REGION, POLLUTION) ;
R2 (REGION, TYPE).

V.2.4.

Algorithme de dcomposition en troisime forme normale

Cet algorithme accepte en entre la relation universelle dcomposer et les dpendances

fonctionnelles de la relation.
Principe de l'algorithme :
1- partir du graphe G des dpendances fonctionnelles, CALCULER une couverture minimale
C;

page 81

2- EDITER l'ensemble des attributs isols dans une mme relation (tous les attributs sont
cls) ;
3- RECHERCHER le plus grand ensemble X d'attributs qui dtermine d'autres attributs ;
4- EDITER la relation R(X, A1, ..., AN) qui est en troisime forme normale ;
5- SUPPRIMER toutes les dpendances fonctionnelles figurant dans R du graphe de
couverture minimale C ;
6- SUPPRIMER les attributs isols de C (c'est--dire les attributs non sources ou cibles de
dpendances fonctionnelles) ;
7- REPETER l'opration de rduction du graphe C partir de l'tape 3 jusqu' ce que C soit
vide.

Remarque : Cet algorithme fournit bien une dcomposition en 3FN qui prserve les DF mais
qui n'est pas ncessairement sans perte. Pour avoir une dcomposition sans perte, il suffit
d'ajouter la dcomposition finale une relation compose des attributs formant la cl de la
relation universelle (ou ajouter ces attributs la relation cre l'tape 2, si elle existe).

V.2.5.

Insuffisance de la troisime forme normale

Il s'agit ici de dtecter les boucles pouvant exister dans le graphe des dpendances
fonctionnelles. Supposons, par exemple une relation PLAGE indiquant le nom, la rgion et le
canton o se situent les plages. Supposons en outre que deux plages d'une mme rgion ne
puissent pas porter le mme nom et qu'il n'existe pas deux cantons de mme nom. La relation
se note :
PLAGE (NOMP, REGION, CANTON)

et possde les dpendances fonctionnelles suivantes :

(NOMP, REGION) CANTON et CANTON REGION

Bien que la relation soit en 3me forme normale, il existe encore des redondances dues au fait
qu'un attribut non cl dtermine une partie de la cl. Afin d'liminer ce type de redondance,
BOYCE et CODD ont introduit une nouvelle forme normale :

Dfinition : Forme Normale de BOYCE-CODD (BCNF) :

Une relation est en BCNF si et seulement si les seules dpendances fonctionnelles
lmentaires sont celles dans lesquelles une cl dtermine un attribut. Pour l'exemple
prcdent une dcomposition en BCNF serait :
PLAGE (NOMP,CANTON) et GEO(CANTON,REGION)

page 82

Thorme de dcomposition en BCNF :

Toute relation admet au moins une dcomposition en BCNF qui est sans perte ; cependant,
une telle dcomposition ne prserve gnralement pas les dpendances fonctionnelles.
Dans l'exemple prcdent on ne prserve pas la premire DF.
V.3.

LA QUATRIEME FORME NORMALE

La notion de dpendance fonctionnelle nous a conduit dcomposer les relations en troisime

forme normale et en forme normale de BOYCE CODD. Ceci est pourtant insuffisant pour
liminer les redondances et les anomalies de mises jour. Considrons, par exemple, une
relation PREFERENCES o nous indiquons, pour chaque nageur, ses diffrents domiciles et les
plages qu'il a l'habitude de frquenter :
PREFERENCES (NN, VILLE, NP)

Il n'existe aucune dpendance fonctionnelle entre les diffrents attributs, ce qui conduit des
situations du type :

PREFERENC
ES

NN

VILLE

1
1
2
2
2
2

Caen
Caen
Nice
Nice
Evreux
Evreu
x

NP
115
117
119
115
119
115

Dans cette relation, tout est cl : elle est en 3me forme normale. Pourtant, il subsiste de
nombreuses redondances. La relation n'est pas dcomposable selon les critres que nous
venons d'voquer, ce qui nous conduit introduire la notion de dpendance fonctionnelle
multivalue.

V.3.1.

Les dpendances multivalues

Dfinition : Dpendance Multivalue

Soit R(A1, A2, ,An) un schma de relation. Soient X et Y des sous-ensembles de A1, A2,
,An. On dit que X ->-> Y (X multi-dtermine Y, ou il y a une dpendance multivalue

page 83

de Y sur X) si, tant donnes des valeurs de X, il y a un ensemble de valeurs de Y

associes et cet ensemble est indpendant des autres attributs Z = R-X-Y de la relation R.
( X ->-> Y) ( (xyz) et (xy'z') R (xy'z) et (xyz') R)
Proprit :
Les dpendances fonctionnelles sont des cas particuliers de dpendances multivalues :
(XY) ( (xyz) et (xy'z') R y = y')

De mme que pour les dpendances fonctionnelles, il existe des axiomes d'infrence de
dpendances multivalues. Ce sont les suivants :
-

Complmentation : (X ->-> Y) (X ->-> R - X - Y)

Augmentation : (X ->-> Y) et (V W) (XW ->-> YV)

Transitivit : (X ->-> Y) et (Y ->-> Z) (X ->-> Z-Y)

Dont on peut dduire d'autres rgles telles l'union :

-

Union : (X ->-> Y) et (Y ->-> Z) (X ->-> YZ)

A partir de ces axiomes, on introduit la notion de Dpendance Multivalue Elmentaire :

Dfinition : Dpendance Multivalue Elmentaire

Une dpendance multivalue lmentaire X ->-> Y d'une relation R est une dpendance
multivalue telle que :
-

Y n'est pas vide et est disjoint de X ;

R ne contient pas une autre Dpendance Multivalue du type X' ->-> Y' telle que

X'X et Y'Y.

Ainsi, dans l'exemple prcdent nous isolons les Dpendances Multivalues Elmentaires
suivantes :
NN ->-> VILLE et NN ->-> NP

V.3.2.

Quatrime forme normale

Dfinition : quatrime forme normale

Une relation est en quatrime forme normale si et seulement si, lorsqu'il existe une
dpendance multivalue lmentaire, celle-ci est unique.
Proprit :
Toute relation a une dcomposition en quatrime forme normale qui est sans perte. Cette
dcomposition n'est pas forcment unique.

page 84

Du fait qu'une dpendance fonctionnelle est un cas particulier de dpendance multivalue,

nous pouvons dduire qu'une relation en quatrime forme normale est en forme normale de
BOYCE-CODD et donc en troisime forme normale.
Sur l'exemple que nous venons de voir (PREFERENCES), la cl est l'ensemble des trois attributs
et il existe deux dpendances multivalues : la relation n'est donc pas en quatrime forme
normale. Une dcomposition de cette relation en quatrime forme normale donne deux
relations PREF1 (NN, VILLE) et PREF2 (NN, NP)

V.4.

LA CINQUIEME FORME NORMALE

La quatrime forme normale n'est pas encore suffisamment pousse pour liminer tous les
risques de redondances et d'anomalies.
Exemple :

Nos prcdents nageurs sont amateurs de fruits de mer et en consomment couramment quand
ils vont sur leurs plages prfres. Voyons une extension de la relation CONSOMMATION
(NAGEUR, CRUSTACES, VILLE) :
CONSOMMATION

NAGEUR

!CRUSTACES

VILLE

Plouf

Tourteau

Binic

Plouf

Tourteau

Trouville

Plouf

Langouste

Trouville

Coule

Tourteau

Trouville

Nous constatons aisment que cette relation prsente de la redondance. Cette redondance
provient d'une contrainte d'intgrit implicite dans la conception du monde rel :
"Tout nageur ayant consomm un type de crustacs et ayant sjourn dans une ville les
cultivant a consomm de ce type de crustacs dans cette ville."

Ainsi, le fait que Plouf ait mang du tourteau est rpt plusieurs reprises, etc.

Toutefois, cette relation est en quatrime forme normale car il n'y a pas de dpendance
multivalue. Pour nous en assurer, nous pouvons considrer les projections B1, B2, B3 de la
relation CONSOMMATION sur les diffrents couples d'attributs C1(NAGEUR, CRUSTACES),

page 85

et C3(CRUSTACES, VILLE), et constater que la jointure de deux de ces relations

ne redonne jamais la relation CONSOMMATION. La relation n'est donc pas dcomposable en
deux autres relations.
C2(NAGEUR, VILLE)

V.4.1.

Les dpendances de jointure

Le problme provient du fait que nous avons jusqu'alors toujours essay de dcomposer une
relation en deux relations. Comme nous allons le montrer ci-dessous, certaines relations sont
dcomposables, non pas en deux, mais en trois relations. C'est le cas dans notre exemple en
raison de la contrainte d'intgrit que nous rappelons ci-dessous :
"Tout nageur ayant consomm un type de crustacs et ayant sjourn dans une ville les
cultivant a consomm de ce type de crustacs dans cette ville."

qui se note de faon plus formelle :

(nageur, crustacs) C1 et (nageur, ville) C2 et (crustacs, ville) C3
(nageur, crustacs, ville) CONSOMMATION
Dfinition : dpendance de jointure
Soit R(A1, A2, , An) un schma de relation et X1, X2, , Xm des sous-ensembles de
(A1, A2, , An). On dit qu'il existe une dpendance de jointure *(X1, X2, ,Xm) si R est
la jointure de ses projections sur X1, X2, , Xm, c'est--dire si :
R=

X1(R) |x| X2(R) |x| |x| Xm(R).

Par exemple, la relation CONSOMMATION obit la dpendance de jointure suivante :

* (NAGEUR CRUSTACES, NAGEUR VILLE, CRUSTACES VILLE)
Proprit :
Les dpendances multivalues sont des cas particuliers de dpendances de jointure :
(XY) ( (xyz) et (xy'z') R y = y')
V.4.2.

Cinquime forme normale

La cinquime forme normale est une gnralisation de la quatrime forme normale qui
ncessite de prendre en compte les dpendances de jointure induites par la connaissance des
cls d'une relation.

page 86

Dfinition : Cinquime Forme Normale

Une relation R est en cinquime forme normale si et seulement si toute dpendance de
jointure est implique par des cls candidates de R.
V.5.

CONCLUSIONS

Dans ce chapitre, nous avons prsent la thorie de la normalisation des schmas relationnels.
Cette normalisation est trs importante dans la pratique si l'on veut viter de stocker des
informations redondantes. On considre, en gnral, que la troisime forme normale est
suffisante dans les cas courants.
Dpendant de la smantique des donnes, le processus de normalisation reste la charge de
l'utilisateur du SGBD. Cette phase, dlicate, est aujourd'hui largement facilite par des outils
d'aide la conception que proposent diffrents constructeurs.

V.6.
[Codd 74]

RFRENCES
E.F.

CODD,

"Recent Investigations in Relational Database

Systems", IFIP Congrs 1974, North-Holland Ed., pp 1017-1021.

[Fagin 79]

R. FAGIN,

"Normal Forms and Relational Database Operators",

ACM SIGMOD 1979, Boston, Juin 1979, pp 153-160.

[Nicolas 78]

J.M. NICOLAS,

"Mutual Dependencies and Some Results on

th
Undecomposable Relations", 5 Very Large Data Bases, Berlin
1978, IEEE Ed., pp 360-367.

page 87

page 88

CHAPITRE 6 : LA PROTECTION DE L'INFORMATION

Comme nous l'avons voqu dans le premier chapitre, un SGBD comprend trois niveaux
d'abstraction diffrents. Le troisime chapitre est consacr au niveau conceptuel qui regroupe
et gre l'ensemble des informations de l'entreprise. Le prochain s'intresse aux mthodes de
stockage du niveau interne. Nous nous plaons ici au niveau externe, l o intervient
l'utilisateur final dont on doit pouvoir contrler les actions sur les donnes de la base.
La dmarche consistant centraliser les donnes induit un certain nombre de problmes, tant
pour l'utilisateur final d'un SGBD que pour les programmes chargs de contrler la protection,
et la cohrence des informations de la base.
La vision de l'entreprise qu' l'utilisateur final est limite l'ensemble des informations lies
son travail (par exemple, le service du personnel ne se proccupe pas de la gestion des stocks).
Elle ne correspond donc pas au schma global tel qu'il est dcrit au niveau conceptuel. Le
SGBD doit prendre en compte ce problme en recrant l'environnement de travail habituel de
chaque utilisateur.
En outre, il est indispensable de limiter l'accs des utilisateurs aux informations de l'entreprise.
De mme que de nombreux systmes d'exploitation offrent des possibilits de protection sur
les fichiers par affectation de droits de lecture, d'criture ou d'excution, des moyens d'assurer
la confidentialit des informations contenues dans la base doivent exister, dans les SGBD.
Toutefois, la diffrence des systmes d'exploitation, les objets sur lesquels ces droits doivent
pouvoir tre distribus sont plus varis. L'utilisateur d'un systme d'exploitation possde un
droit sur l'ensemble d'un fichier. L'exigence typique d'un utilisateur de SGBD est de demander
des droits d'accs, non pas une relation du niveau conceptuel, mais un ensemble
d'informations. Celles-ci sont issues d'un certain nombre de relations de ce niveau. La seule
particularit de cet ensemble est sa conformit un prdicat (cet ensemble de donnes rpond
un critre de slection).
En outre, la confidentialit n'est pas le seul facteur de contrle des donnes d'un SGBD.
Inroduisons maintenant la notion d'intgrit des donnes qui rsulte de l'existence de liens

page 89

smantiques (appels contraintes d'intgrit) entre les donnes de la base, lesquels doivent tre
vrifis aprs chaque modification de la base.

VI.1.

LES VUES EXTERNES

Dans les modles base de pointeurs (hirarchique et rseau), sont limites les possibilits
d'accs de l'utilisateur des sous-schmas stricts du schma de la base. Un certain nombre de
champs du schma initial peuvent tre cachs ou renomms, mais la structure de l'information
reste la mme. Il est, par exemple, impossible l'utilisateur final de dfinir son propre schma
provenant du "rapprochement" (ou jointure en relationnel) de deux schmas du niveau
conceptuel. Ce qui signifie par exemple :
-

que l'on peut connatre les noms, prnoms et niveaux de tous les nageurs (masquage du
numro NN et remplacement de QUALITE en NIVEAU) ;

que l'on ne peut pas connatre les noms et prnoms des nageurs d'excellent niveau (car on
ne peut pas isoler les enregistrements des excellents nageurs des autres) ;

que l'on ne peut pas connatre uniquement les noms de tous les nageurs et les dates
auxquelles ces nageurs se sont baigns (impossibilit de changer la structure des
enregistrements visibles donc de visualiser un rsultat du type jointure dans le modle
relationnel).

La solution idale ces nombreux problmes est de recrer, pour chaque utilisateur, sa propre
vision de l'entreprise (sans avoir bien entendu rpter l'information au sein de la base) en
laissant au SGBD le soin de grer la confidentialit et l'intgrit des donnes.
Le mcanisme des vues des SGBD relationnels a l'ambition de rsoudre un grand nombre de
problmes que les modles prcdents n'ont pas su traiter. Nous verrons successivement les
objectifs de ce systme et constaterons ensuite la facilit de leur mise en uvre. Nous
voquerons enfin, les limites de ce mcanisme.

VI.1.1.

Les objectifs : voir le monde comme il n'est pas !

Le mcanisme des vues permet de rpondre aux besoins suivants :

- adaptation aux applications
Les applications ne doivent pas dpendre du schma adopt au niveau conceptuel.
L'utilisateur manipule plus naturellement les donnes sous leur forme habituelle plutt que
de devoir les retrouver et les traiter au sein d'une quantit importante de donnes parasites.

page 90

- intgration des applications existantes

Les donnes vues par l'utilisateur tant les mmes que celles disponibles avant d'avoir
accs un SGBD, il doit pouvoir, grce de faibles modifications, aisment adapter ses
anciennes applications.
- dynamique du schma de la base
Les modifications du schma conceptuel, parfois ncessaires pour des raisons de
performances ou de nouveaux besoins, ne doivent pas impliquer de changements des
schmas du niveau externe si ces derniers n'voluent pas. Si cette rgle est respecte, ces
modifications n'entranent pas non plus la rcriture des applications du niveau externe.
- confidentialit et scurit
L'administrateur de la base dfinit les vues et les utilise pour dfinir prcismment les
droits d'accs d'un utilisateur. Ces derniers peuvent ainsi dpendre de la valeur des
informations.
- dcentralisation de l'administration d'une BD
Chaque utilisateur ou chaque quipe de dveloppement voluant au niveau externe doit
tre responsable des donnes qu'il gre avec ses propres droits. Il devient administrateur de
sa vue et peut dlguer ses droits un autre utilisateur.
- htrognit des modles
Pouvoir prsenter un accs homogne et unifi un ensemble de bases de donnes de
types diffrents est particulirement intressant . Le mcanisme de vue permet cette vision
unique.
VI.1.2.

Le relationnel simplifie les vues

Le modle relationnel, grce la manipulation ensembliste des donnes, autorise la dfinition

d'un ensemble particulier de tuples l'aide d'un critre de recherche. Ces tuples peuvent tre
composs partir de plusieurs relations de base. Le rsultat de n'importe quelle requte est
une relation au mme titre que n'importe quelle relation effectivement implante en machine ;
les rsultats d'une requte constituent ainsi une relation ordinaire qui peut servir de base une
nouvelle manipulation.
Dfinir une vue revient alors dterminer le critre qui permet de rassembler les tuples dsirs
et de les prsenter sous la forme souhaite. Une telle opration se ralise aisment l'aide de
l'algbre relationnelle, mais est encore simplifie par l'utilisation des langages assertionnels
des systmes relationnels actuels.
Dans un systme relationnel, la notion d'une vue est donc quasi identique une interrogation
de la base. Attention cependant : la cration d'une vue dfinit le critre d'obtention de la vue

page 91

dsire. Les tuples rsultats ne sont pas rellement constitus ; le mcanisme reste entirement
virtuel. Nous allons maintenant en donner quelques exemples.

Exemple 1 :
Crer la vue des nageurs dont la qualit est bonne ou excellente.
CREATE VIEW BONS_NAGEURS AS
SELECT NN, NOM, PRENOM, QUALITE
FROM NAGEURS
WHERE QUALITE IN ('Excellente', 'Bonne');

Exemple 2 :
Des vues peuvent tre dfinies partir d'autres vues . Crer la vue des nageurs appartenant
BONS_NAGEURS

et dont la qualit est excellente.

CREATE VIEW CHAMPIONS AS

SELECT NN, NOM, PRENOM
FROM BONS_NAGEURS
WHERE QUALITE = 'Excellente';

Exemple 3 :
On peut aussi crer la vue des mauvais nageurs :
CREATE VIEW MAUVAIS_NAGEURS AS
SELECT NOM, PRENOM
FROM NAGEURS
WHERE QUALITE = 'Mauvaise';

Exemple 4 :

Des vues peuvent galement tre cres partir de critres plus complexes. Par exemple, crer
la vue des exploits, c'est--dire des nageurs ayant pris des bains de plus de 10 heures. On
souhaite conserver des informations sur le nom et le prnom du nageur, le nom de la plage o
a eu lieu l'exploit, ainsi que la date et la dure du bain.

page 92

CREATE VIEW EXPLOITS AS

SELECT N.NN, N.NOM, N.PRENOM, N.QUALITE, P.NOMP, B.DATE, B.DUREE
FROM NAGEUR N, BAIGNADE B, PLAGE P
WHERE N.NN = B.NN
AND B.NP = P.NP
AND B.DUREE > 600mn ;

VI.2.

MANIPULATION AU TRAVERS DES VUES

VI.2.1.

Consultation au travers des vues

L'interrogation exprime sur une vue est toujours possible. Une vue est une relation virtuelle.
Chaque requte portant sur la vue est transforme en une requte portant sur les relations
relles du niveau conceptuel. Celles partir desquelles la vue a t dfinie.
Exemple 1 :

Rechercher, dans la vue BONS_NAGEURS, les noms des excellents nageur se prnommant Paul.
SELECT NOM
FROM BONS_NAGEURS
WHERE QUALITE = 'Excellente'
AND PRENOM = 'Paul';

Cette requte, exprime au niveau conceptuel, devient :

SELECT NOM
FROM NAGEURS
WHERE QUALITE IN ('Excellente', 'Bonne')
AND QUALITE = 'Excellente'
AND PRENOM = 'Paul';

Aprs optimisation elle devient :

SELECT NOM
FROM NAGEURS
WHERE QUALITE = 'Excellente'
AND PRENOM = 'Paul';

page 93

VI.2.2.

Influence sur l'optimisation des requtes

Nous avons dj mis en vidence dans le modle relationnel la simplicit du concept de vue et
de sa mise en uvre . Dans ce paragraphe, nous revenons sur cette simplicit en tudiant son
influence sur l'optimisation des requtes.
Les vues sont des relations fictives (ou virtuelle, ou drive). Les requtes formules sur ces
vues sont transformes, en requtes appliquer des relations de base rellement implantes
en machine.
Comment le SGBD transforme t-il le niveau vue en niveau conceptuel ? Il concatne
simplement la requte de l'utilisateur la requte crant la vue et optimise l'ensemble. Nous
visualisons aisment ceci l'aide des arbres algbriques.
Crer la vue correspond un arbre algbrique :

NAGEURS

restriction sur
qualit = Excellente
ou qualit = Bonne

Vue
BONS_NAGEURS

la requte sur la vue correspond galement un arbre algbrique :

page 94

Vue
BONS_NAGEURS

restriction sur
qualit = Excellente

RESULTAT

La requte transforme finalement applique aux relations correspond un arbre algbrique

rsultant de la concatnation des deux prcdents.

NAGEURS

restriction sur
qualit = Excellente
ou qualit = Bonne

restriction sur
qualit = Excellente

RESULTAT

L'optimiseur peut en consquence modifier l'arbre pour acclrer son excution.

page 95

NAGEURS

restriction sur
qualit = Excellente

RESULTAT

Cet exemple d'optimisation, ici trs simple, ne met en jeu que des restrictions. Cette tape est
cependant importante et parfois complexe : mettre bout bout deux arbres optimiss
sparment ne donne pas ncessairement un arbre global optimal. Repasser par l'optimiseur
pour dterminer l'arbre optimal (descente des oprateurs unaires, ordonnancement des
jointures) est indispensable.

VI.2.3.

Mise jour travers les vues

De nouvelles difficults surgissent lors de la mise jour. Mme si l'utilisateur possde des
droits de modification sur la vue, les modifications qu'il souhaite apporter la base demeurent
indfinies dans de nombreux cas. Voyons quelques exemples ;
Exemple 1 :
Peut-on insrer par la vue BONS_NAGEURS le tuple (73, 'Albert', 'COULE', 'Excellente') ? (on
suppose que la cl NN=73 est libre). Cette insertion ne pose pas de problme si l'utilisateur
possde un droit d'accs en insertion sur la vue. Tous les champs de la relation
conceptuelle NAGEURS dont dpend la vue sont dfinis. L'insertion peut avoir lieu.
Exemple 2 :
Peut-on insrer travers la vue CHAMPIONS le tuple (73, 'Albert', 'COULE') ? (on suppose
que la cl NN=73 est libre). Ce cas est dj plus complexe, mais cette vue correspond une
seule valeur de l'attribut manquant QUALITE. L'insertion du tuple devient celle du tuple
(73, 'Albert', 'COULE', Excellente') dans la relation NAGEURS.
Exemple 3 :
Voyons maintenant un exemple de modifications. Si la modification au sein de la vue des
BONS_NAGEURS

du tuple (73, 'Albert', 'COULE', 'Excellente') en (73, Albert',

page 96

'COULE',

'Bonne') semble naturelle, transformer ce tuple en (73, 'Albert', 'COULE', 'Mauvaise') est
moins vident : la modification qui fait disparaitre un tuple de la vue des BONS_NAGEURS
est-elle autorise? La question de savoir si ce droit doit tre donne ou non est intressant.
Un utilisateur a-t-il le droit de "faire disparatre" des tuples de sa vue ?
Exemple 4 :
Peut-on maintenant insrer par la vue MAUVAIS_NAGEURS le tuple ('Albert', 'COULE') ?
Comme dans l'exemple numro 2, la valeur de l'attribut QUALITE de la relation NAGEURS.
Mais, dans le cas prsent, la valeur de la cl, l'attribut NN, doit galement tre complte
tout d'abord, Albert COULE peut dj tre recens dans une autre catgorie de la base.
L'insertion peut n'tre en fait qu'une modification. Par exemple, Albert COULE peut tre
recens en tant que bon nageur. Il s'agit alors d'une modification avec les risques que cela
comporte. Nous les avons voqus dans l'exemple prcdent.
Albert COULE peut tre une personne diffrente de toutes celles qui sont dj recenses
dans la base. Dans ce cas le traitement doit tre l'ajout d'un tuple dans la relation NAGEURS
sous un numro diffrent.
Exemple 5 :
Enfin, pour insrer un tuple du type (73, 'Albert', 'COULE', NULL) depuis la vue
BONS_NAGEURS

on ne sait pas si le niveau d'Albert COULE est bon ou excellent. Doit-on

accepter une telle insertion ? En effet, pour l'utilisateur de la relation NAGEURS, rien
n'indique que Albert COULE est bon ou excellent nageur et non pas de niveau faible ou
mdiocre.
L'tude de ces exemples nous montre que le mcanisme des vues externes, apporte des avantages
en confidentialit et en confort de travail considrables, mais pose des problmes non rsolus dans
le domaine des mises jour. L'utilisateur qui dispose des droits ncessaires, n'est pas certain de
pouvoir modifier certaines donnes auxquelles il a pourtant accs.

Les produits actuels limitent les mises jour travers les vues de faon drastique : seules les
vues mono-relation sans fonction dont la dfinition conserve la cl sont concernes. Toutes les
autres ne peuvent tre manipules qu'en interrogation.

VI.3.

CONFIDENTIALITE

La confidentialit assure la protection des donnes de la base contre les accs non autoriss.
Elle est gnralement obtenue en dfinissant des autorisations diverses sur les objets
susceptibles d'tre manipuls par les usagers. Le choix de l'objet dtermine la mthode de
vrification des droits d'accs. Ces droits sont gnralement de plusieurs sortes (lecture,

page 97

modification et droit d'administration) car ils doivent rpondre aux diffrentes exigences des
utilisateurs.
Quelque soit la nature du SGBD, cette protection doit porter sur la plus petite unit
d'information accessible par un utilisateur. Le modle relationnel dfinie n'importe quel objet
(relation, vue, ensemble de tuples, l'attribut d'une relation, d'une vue ou d'un tuple) par un
simple critre permettant sa slection. La dfinition des droitss sur tout objet, aussi petit soit il
est thoriquement possible, mais l'encombrement occasionn par de telles informations
ncessite une gestion trop gourmande en performances. Ainsi, la gestion de droits dans le
systme relationnels d'aujourd'hui est elle rduite aux seules relations et vues.
La plupart des Systmes de Gestion de Bases de Donnes offrent, outre les droits habituels de
lecture et de modification, des possibilits d'administration comparables aux services offerts
par les systmes d'exploitation. Un utilisateur peut ainsi transmettre ses propres droits, droits
d'administration inclus, un autre utilisateur. Les SGBD compensent ainsi partiellement les
inconvnients de la centralisation qu'ils imposent.

VI.3.1.

Autorisations sur une relation ou sur une vue

Les droits accords - ou autorisations - sur les relations ou vues sont de trois types :
-

droit de consultation ;

droit de modification (mises jour, suppression, insertion) ;

droit d'administration (dfinir les contraintes d'intgrit, attribuer les autorisations, dtruire
ou modifier le schma de la relation).

Insistons plus particulirement sur le droit d'administration qui est la seule contre-partie la
centralisation outrance des donnes. Chaque utilisateur retrouve un certain pouvoir de
dcision : il a le droit de dlguer tout ou partie de ses droits sur les relations cres.
Forcer tout utilisateur passer par une vue, conduit considrer que l'utilisateur des droits
uniquement sur ce qu'il voit. Le mcanisme est trs souple et permet de dfinir un droit en
fonction d'un critre de slection. Ainsi, le directeur d'un service ne peut, dans le cas d'une
relation EMPLOYE lire que les salaires des membres de son propre service. De nombreuses
limitations, dues l'impossibilit des mises jours gnrales travers les vues, limitent ce
mcanisme des utilisations particulires.

page 98

VI.3.2.

La cession de droits

Dans le standard SQL, le mcanisme d'attribution et de rvocation des droits reste classique :
les droits portent les relations de base. La requte permettant de cder ou de retirer tout ou
partie de ses droits un autre usager est la suivante :
GRANT | REVOKE <liste de droits> ON <nom de relation>
TO | FROM <listes d'usagers>
[WITH GRANT OPTION]

Les droits possibles sont les suivants :

SELECT
INSERT
UPDATE

(nom d'attribut)

DELETE

Le crateur d'une relation dispose de tous les droits sur la relation cre. Il a le droit

d'administration, c'est dire qu'il peut dtruire ou modifier le schma de sa relation. Il peut
donner des droits aux autres usagers par la clause GRANT ; si la clause WITH GRANT
OPTION est spcifie, les droits sont transmissibles en aval. Notons que l'instruction
REVOKE retire galement les droits transmis en aval sur la relation, c'est dire qu'un
utilisateur peut se voir retirer ses droits, non seulement par celui qui les lui a concds, mais
aussi par un plus ancien donateur dont il ignorait l'existence... jusqu'au crateur lui-mme.

VI.4.

INTEGRITE SEMANTIQUE

VI.4.1.

Les diffrents types de contraintes

On dresse ici une typologie possible des contraintes d'intgrit :

Domaine de variation
C'est la dfinition du domaine auquel appartient la valeur d'un attribut (entier, rel, texte,
date). Chaque donne de la base doit vrifier cette contrainte qui peut correspondre
une simple concordance de type (c'est le cas de l'entier) ou une condition plus complexe
(c'est le cas du type date qui suppose des connaissances le nombre de jour dans un mois,
les annes bissextiles, etc.).

page 99

Plages de valeurs
C'est la restriction du domaine un sous-ensemble d'un domaine. Par exemple, on peut
imposer qu'un ge soit compris entre 0 et 150 ans, qu'aucun bain ne soit jamais pris entre
novembre et mars
Non nullit
La "nullit" ne correspond pas un entier de valeur 0 ou une chane de caractres vide,
mais, pour tout type, une valeur indfinie ou non renseigne lors d'une mise jour
(NULL). Il peut tre indispensable d'interdire la nullit certains champs pour la permettre
d'autres. Par exemple, une cl de relation doit avoir une valeur non nulle, que ce soit un
numro ou une chane de caractre, puisqu'elle est le seul moyen de distinguer deux tuples
ayant les mmes valeurs d'attributs.
Unicit
L'unicit est galement une notion importante, en particulier pour la dfinition des cls qui
doivent tre uniques.
Dpendances fonctionnelles
Les dpendances fonctionnelles sont des contraintes d'intgrit. Par exemple, un numro
de scurit sociale dtermine un tuple dfinissant un individu.
Dpendances rfrencielles
Elles indiquent que les valeurs d'un attribut (ou d'un groupe d'attributs) d'une relation R1
doivent dj tre dfinies dans un autre attribut (ou un autre groupe d'attributs). Par
exemple, prendre un bain implique que NN et NP soient respectivement un individu et une
plage et qu'ils figurent dans les tables appropries. Un nageur peut exister sans
ncessairement avoir pris de bain, mais un bain ne peut tre pris que si le nageur existe.
Contraintes temporelles
Ces contraintes vrifient l'volution des donnes par rapport au temps. Par exemple, le
salaire affect un poste ne peut pas diminuer.
Contraintes avec agrgats
Ces contraintes ne portent pas sur la valeur d'un atome, mais sur une fonction concernant
une collection de valeurs d'atomes. Par exemple, la dure moyenne des bains doit tre
suprieure deux minutes.
Contraintes gnrales
Il existe galement des contraintes qui n'appartiennent aucune des catgories dfinies cidessus et sont plus gnrales. Par exemple : le nombre de bains pris par une personne ne
peut pas dcrotre.

Cette contrainte fait intervenir la fois la notion de contrainte

temporelle et de contrainte avec agrgats.

page 100

VI.4.2.

Comment dfinir une contrainte d'intgrit ?

Comme nous pouvons le constater, les contraintes qui viennent d'tre dcrites sont mises en
uvre de diffrentes faons. Par exemple, les contraintes exprimant les dpendances
fonctionnelles servent la conception du schma de la base : c'est le processus de conception
qui assure automatiquement la vrification des contraintes de dpendance fonctionnelle.
Toutefois, toutes les contraintes ne sont pas lies l'tape de conception de la base. Le
langage de manipulation de donnes doit donc permettre la dfinition des contraintes
d'intgrits. Ces contraintes peuvent alors tre considres comme des proprits (assertions)
indpendantes les unes des autres. Toute modification de la base de donnes doit les respecter.
Ce formalisme est d'ailleurs le mieux adapt au modle relationnel.

VI.4.3.

Comment regrouper (classer) les contraintes ?

On peut regrouper les contraintes d'intgrit suivant diffrents critres : leur cot de
validation, leurs caractristiques individuelles (la contrainte s'applique tuple tuple) ou
ensembliste (la contrainte s'applique sur un ensemble de tuples), le fait qu'elles soient
spcifiques d'une relation qu'elles en mettent plusieurs en jeu, etc.

VI.4.4.

Contraintes d'intgrits et transactions bases de donnes

La notion de transaction sur une base de donnes est dfinie comme un ensemble d'actions qui
font passer la base d'un tat cohrent un autre tat cohrent (une BD cohrente est une BD
o toutes les contraintes d'intgrit sont satisfaites). Trois fonctions d'un SGBD sont
concernes : le contrle de concurrence, la fiabilit et l'intgrit smantique. Nous ne traitons
dans ce paragraphe que le troisime aspect : le respect de rgles smantiques.
Le problme concerne l'instant de vrification des diffrentes contraintes : quel moment
doit-on vrifier les contraintes d'intgrit ? Quelles sont les contraintes vrifiables au gr des
mises jour de la base. Quelles sont celles qui sont vrifies la fin de la transaction ?
Voyons quelques exemples.

Exemple 1 :

Considrons la relation NAGEURS (NN, NOM, PRENOM, QUALITE) et imposons la contrainte :

page 101

"Tous les nageurs dont le numro est suprieur 1000 sont d'excellent niveau."

Cette contrainte est vrifiable chaque insertion de nouveau tuple ou chaque modification
de la relation NAGEURS.
Exemple 2 :

Considrons maintenant la mme relation

(contrainte avec agrgats) :

NAGEURS

avec la contrainte d'intgrit suivante

"Il doit y avoir autant de nageurs d'excellent niveau que de mauvaise qualit."

Supposons que l'on dsire insrer dans la base un ensemble de nouveaux nageurs. A chaque
insertion de nageur d'excellente ou de mauvaise qualit, la contrainte n'est pas vrifie.
Pourtant, cette mme contrainte peut trs bien tre vrifie lorsque touts les nouveaux nageurs
ont t ajouts.
Notifier au SGBD que l'ensemble des modifications effectues prcdemment doit tre valid et
que les contraintes d'intgrit peuvent dsormais tre vrifies s'avre donc indispensable .
L'ensemble des modifications valides forme ce qui est classiquement appel une
"transaction". Mais ceci est une autre histoire

VI.5.

CONCLUSIONS

Garantir la cohrence de l'information est un apport trs important des Systmes de Gestion de
Bases de Donnes. L'utilisateur est libr d'une tche parfois difficile. Le systme vrifie lui
mme des contraintes et des droits associs aux donnes. Vrifier les contraintes et les droits
d'accs dans les programmes applicatifs des anciens systmes tait peu cohrent.

VI.6.

RFRENCES

[Ullman 80]

J. ULLMAN :"Principles

of Databases Systems" Computer Sciences

Press, 1980.
[Bancilhon 79]

F.

BANCILHON :

"Supporting View Updates in Relational

Databases" in Data Base Architectures, Bracchi Nijssen Editors,

North Holland Publishing Company, 1979.

page 102

page 103