Cours de bases de donnes relationnelles

1. Introduction
1. Dfinitions
2. Fonctionnalits
3. Architecture logique d'un SGBD
1. Architecture Ansi/Sparc
2. Indpendance donnes - programmes
2. Le modle relationnel de donnes
1. Dfinition formelle
2. Caractristiques des relations
3. Contraintes d'intgrit
3. Les langages relationnels
1. L'algbre relationnelle
2. Les langages prdicatifs (nuplet et domaine)
1. Spcification formelle du calcul relationnel variable nuplet
2. Spcification formelle du calcul relationnel variable domaine
3. Exemple de la base des invitations
4. Le langage SQL
1. Introduction
2. Prsentation de la base exemple Cooprative
3. Le langage de dfinition des donnes
4. Le langage d'interrogation
1. Syntaxe gnrale
2. Requetes mono-relation
3. Expression de jointure
4. Oprateurs ensemblistes
5. Fonctions - Agrgats
6. Partitionnement
7. Quantificateurs
8. Synthse
5. Le langage de mise jour
6. Normalisation de SQL
7. Complments sur intgrit, vues et droits
1. Contraintes d'intgrit
1. Dfinition
2. Exemples
3. Vrification
2. Vues relationnelles
1. Principes
2. Vue relationnelle
3. Evaluation d'une vue
3. Gestion des droits
5. Conception Entit-Association
1. Introduction
2. Les concepts
3. Comparaison modles E/A et relationnel
4. Rgles de passage E/A vers relationnel
5. Des exemples pour illustrer
1. La base de gestion du personnel
2. La base cooprative
6. Avantages - Inconvnients
6. Dpendances fonctionnelles et normalisation
1. Dpendance fonctionnelle sur une relation (DF)
2. Proprits des dpendances fonctionnelles
3. Dcomposition binaire d'une relation
4. Dfinitions :
5. Normalisation des relations (formes normales)
6. Dpendances fonctionnelles et conception de schmas
7. Architecture logicielle d'un SGBD
8. Evaluation et Optimisation de requtes
1. Optimisations algbriques
1. Rgles de transformation de l'algbre relationnelle
2. Algorithme gnral d'optimisation heuristique
2. Optimisation par une fonction de cot
9. Contrle des accs concurrents et reprise
1. Introduction
2. Problmes lis aux accs concurrents
3. Mcanismes pour assurer la concurrence et la reprise
1. Transactions et journalisation
2. Concurrence par verrouillage
3. Granularit de contrle de concurrence
4. Principes gnraux de la reprise
10. Performances des systmes relationnels : benchmarks TPC
11. BIBLIOGRAPHIE
 BD et SGBD : Table des Matires
Introduction
Les limites l'utilisation des fichiers
Objectifs des systmes de gestion de bases de donnes
Concepts de base
Composants des systmes de gestion de bases de donnes
Un peu d'histoire
Le modle relationnel
Dfinitions
Oprateurs relationnels
Formes normales
Langages de manipulation de donnes relationnelles
Remarques
L'optimiseur de requtes
Rcriture des requtes
Choix des chemins d'accs
Requte portant sur une seule table
Jointures sans index
Jointures avec index
ORDER BY
Cohrence des interrogations et accs concurrents
Interrogation
Mise jour
Contrle des accs la base et scurit des donnes
Droits d'accs aux tables
Stockage des donnes
Les index
Les clusters
Bibliographie
Index

Introduction
Les bases de donnes sont actuellement au cur du systme d'information des entreprises. Les systmes de
gestion de bases de donnes, initialement disponibles uniquement sur des "mainframes", peuvent maintenant tre
installs sur tous les types d'ordinateurs y compris les ordinateurs personnels. Mais attention, souvent on dsigne,
par abus de langage, sous le nom "bases de donnes" des ensembles de donnes qui n'en sont pas.
Qu'est-ce donc qu'une base de donnes? Que peut-on attendre d'un systme de gestion de bases de donnes?
C'est ces questions, entre autres, que cet ouvrage essaie d'apporter des rponses.
Dans un premier temps, et de faon informelle, on peut considrer une Base de Donnes (BD) comme une
grande quantit de donnes, centralises ou non, servant pour les besoins d'une ou plusieurs applications,
interrogeables et modifiables par un groupe d'utilisateurs travaillant en parallle. Quant au Systme de Gestion
de Bases de Donnes (SGBD), il peut tre vu comme le logiciel qui prend en charge la structuration, le stockage,
la mise jour et la maintenance des donnes ; c'est, en fait, l'interface entre la base de donnes et les utilisateurs
ou leurs programmes.
Les limites l'utilisation des fichiers
Objectifs des systmes de gestion de bases de donnes
Concepts de base
Composants des systmes de gestion de bases de donnes
Un peu d'histoire
Les limites l'utilisation des fichiers
L' utilisation de fichiers impose d'une part, l'utilisateur de connatre l'organisation (squentielle, indexe, ...)
des fichiers qu'il utilise afin de pouvoir accder aux informations dont il a besoin et, d'autre part, d'crire des
programmes pour pouvoir effectivement manipuler ces informations. Pour des applications nouvelles,
l'utilisateur devra obligatoirement crire de nouveaux programmes et il pourra tre amen crer de nouveaux
fichiers qui contiendront peut-tre des informations dj prsentes dans d'autres fichiers.
De telles applications sont :
rigides,
contraignantes,
longues et coteuses mettre en uvre.
Les donnes associes sont :
mal dfinies et mal dsignes,
redondantes,
peu accessibles de manire ponctuelle,
peu fiables.
La prise de dcision est une part importante de la vie d'une socit. Mais elle ncessite d'tre bien inform sur la
situation et donc d'avoir des informations jour et disponibles immdiatement.
Les utilisateurs, quant eux, ne veulent plus de systmes d'information constitus d'un ensemble de programmes
inflexibles et de donnes inaccessibles tout non spcialiste ; ils souhaitent des systmes d'informations globaux,
cohrents, directement accessibles (sans qu'ils aient besoin soit d'crire des programmes soit de demander un
programmeur de les crire pour eux) et des rponses immdiates aux questions qu'ils posent. On a donc
recherch des solutions tenant compte la fois des dsirs des utilisateurs et des progrs techniques. Cette
recherche a abouti au concept de base de donnes.
Dfinition (base de donnes) : Une base de donnes est un ensemble d'informations sur un sujet qui est :
exhaustif,
non redondant,
structur,
persistant.
Dfinition (systme de gestion de base de donnes) : Un systme de gestion de base de donnes est un
logiciel qui permet de :
dcrire,
modifier,
interroger,
administrer,
les donnes d'une base de donnes.

Objectifs des systmes de gestion de bases de donnes

Les bases de donnes et les systmes de gestion de bases de donnes ont t crs pour rpondre un certain
nombre de besoins et pour rsoudre un certain nombre de problmes.
Des objectifs principaux ont t fixs aux systmes de gestion de bases de donnes ds l'origine de ceux-ci et ce,
afin de rsoudre les problmes causs par la dmarche classique.
Ces objectifs sont les suivants :
 Il faut pouvoir accder aux donnes sans savoir programmer ce qui signifie des langages
"quasi naturels".
Efficacit des accs aux donnes

Ces langages doivent permettre d'obtenir des rponses aux interrogations en un temps
"raisonnable". Ils doivent donc tre optimiss et, entre autres, il faut un mcanisme
permettant de minimiser le nombre d'accs disques. Tout ceci, bien sur, de faon
compltement transparente pour l'utilisateur.
Administration centralise des donnes
Des visions diffrentes des donnes (entre autres) se rsolvent plus facilement si les
donnes sont administres de faon centralise.
Non-redondance des donnes
Afin d'viter les problmes lors des mises jour, chaque donne ne doit tre prsente
qu'une seule fois dans la base.

Cohrence des donnes

Les donnes sont soumises un certain nombre de contraintes d'intgrit qui dfinissent
un tat cohrent de la base. Elles doivent pouvoir tre exprimes simplement et vrifies
automatiquement chaque insertion, modification ou suppression des donnes.
Partageabilit des donnes
Il s'agit de permettre plusieurs utilisateurs d'accder aux mmes donnes au mme
moment. Si ce problme est simple rsoudre quand il s'agit uniquement d'interrogations
et quand on est dans un contexte mono-utilisateur, cela n'est plus le cas quand il s'agit de
modifications dans un contexte multi-utilisateurs. Il s'agit alors de pouvoir :

permettre deux (ou plus) utilisateurs de modifier la mme donne "en mme
temps" ;

assurer un rsultat d'interrogation cohrent pour un utilisateur consultant une table

pendant qu'un autre la modifie.
Scurit des donnes

Les donnes doivent pouvoir tre protges contre les accs non autoriss. Pour cela, il
faut pouvoir associer chaque utilisateur des droits d'accs aux donnes.
Rsistance aux pannes
Que se passe-t-il si une panne survient au milieu d'une modification, si certains fichiers
contenant les donnes deviennent illisibles? Les pannes, bien qu'tant assez rares, se
produisent quand mme de temps en temps. Il faut pouvoir, lorsque l'une d'elles arrive,
rcuprer une base dans un tat "sain". Ainsi, aprs une panne intervenant au milieu d'une
modification deux solutions sont possibles : soit rcuprer les donnes dans l'tat dans
lequel elles taient avant la modification, soit terminer l'opration interrompue.
Malheureusement, ces objectifs ne sont pas toujours atteints.
Concepts de base
Pour assurer ces objectifs (surtout les deux premiers), trois niveaux de description des donnes ont t dfinis par
la norme ANSI/SPARC.
Niveau interne

Description du stockage des donnes au niveau des units de stockage, des fichiers, ... On
appelle cette description le schma interne.
Niveau conceptuel
Description de la structure de toutes les donnes qui existent dans la base, description de
leurs proprits (relations qui existent entre elles) c'est--dire de leur smantique
inhrente, sans soucis d'implmentation physique ni de la faon dont chaque groupe de
travail voudra s'en servir. On appelle cette description le schma conceptuel.
Niveau externe
Description pour chaque utilisateur de sa perception des donnes. On appelle cette
description le schma externe ou vue.
Le rsultat de la conception d'une base de donnes sera une description des donnes. Par description on entend
dfinir les proprits d'ensembles d'objets modliss dans la base de donnes et non pas d'objets particuliers. Les
objets particuliers sont dfinis par les programmes d'applications lors des insertions et des mises jour des
donnes. Ils doivent alors vrifier les proprits des ensembles auxquels ils appartiennent.
Cette description des donnes sera effectue en utilisant un modle de donnes. Ce dernier est un outil
intellectuel utilis pour comprendre l'organisation logique des donnes. C'est un ensemble de concepts et de
rgles pour les utiliser, permettant de construire avec des types de donnes une reprsentation de la ralit.
Un systme de gestion de bases de donnes est caractris par le modle de description des donnes qu'il
supporte. Les donnes sont dcrites sous la forme de ce modle, grce un langage de description des donnes.
Cette description est appele schma. Les modles utiliss sont : rseau, relationnel, objet, ...
Une fois la base de donnes spcifie, on peut y insrer des donnes, les rcuprer, les modifier et les dtruire.
C'est ce qu'on appelle manipuler les donnes. Les donnes peuvent tre manipules non seulement par un
langage spcifique de manipulation des donnes mais aussi par des langages de programmation "classiques".

Composants des systmes de gestion de bases de donnes

Un systme de gestion de bases de donnes va donc possder un certain nombre de composants logiciels et ce,
quel que soit le modle de donnes qu'il supporte. On trouve donc des composants chargs de :
La description des donnes

Cette partie sera constitue des outils (en gros des langages) permettant de dcrire la
vision des donnes de chaque utilisateur et l'intgration dans une vision globale. On y
trouve aussi les outils permettant de dcrire le stockage physique des donnes.

La rcupration des donnes

Cette partie prend en charge l'interrogation et la modification des donnes et ce, de faon
optimise. Elle est compose de langages de manipulation de donnes spcifiques et
d'extensions de langages "classiques". Elle gre aussi les problmes de scurit.
La sauvegarde et la rcupration aprs pannes
Cette partie comporte des outils permettant de sauvegarder et de restaurer de faon
explicite une base de donnes. Elle comporte aussi des mcanismes permettant, tant
qu'une modification n'est pas finie, de pouvoir revenir l'tat de la base avant le dbut de
 cette modification.
Les accs concurrents aux donnes
C'est la partie charge du contrle de la concurrence des accs aux donnes. Elle doit tre
telle que chaque utilisateur attende le moins possible ses donnes tout en tant certain
d'obtenir des donnes cohrentes en cas de mises jour simultanes de la base.
Chacun de ces composants est dcrit de faon plus dtaille par la suite.

Un peu d'histoire
1960
Uniquement des systmes de gestion de fichiers plus ou moins sophistiqus.
1970
Dbut des systmes de gestion de bases de donnes rseaux et hirarchiques proches des
systmes de gestion de fichiers. Ces systmes de gestion de bases de donnes avaient
rempli certains des objectifs prcdents mais on ne pouvait pas interroger une base sans
savoir o tait l'information recherche (on "naviguait") et sans crire de programmes.
Sortie du papier de CODD sur la thorie des relations, fondement de la thorie des bases
de donnes relationnelles.
1980

Les systmes de gestion de bases de donnes relationnels apparaissent sur le march.

1990
Les systmes de gestion de bases de donnes relationnels dominent le march.
Dbut des systmes de gestion de bases de donnes orients objet.

Le modle relationnel
Le modle relationnel a t formalis par CODD en 1970. Quelques exemples de ralisation en sont :
DB2(IBM), INFORMIX, INGRES, ORACLE.
Dans ce modle, les donnes sont stockes dans des tables, sans prjuger de la faon dont les informations sont
stockes dans la machine. Un ensemble de donnes sera donc modlis par un ensemble de tables.
Le succs du modle relationnel auprs des chercheurs, concepteurs et utilisateurs est d la puissance et la
simplicit de ses concepts. En outre, contrairement certains autres modles, il repose sur des bases thoriques
solides, notamment la thorie des ensembles et la logique mathmatique( thorie des prdicats d'ordre 1).
Les objectifs du modle relationnel :
proposer des schmas de donnes faciles utiliser,
amliorer l'indpendance logique et physique,
mettre la disposition des utilisateurs des langages de haut niveau pouvant ventuellement tre utiliss
par des non informaticiens,
optimiser les accs la base de donnes,
amliorer l'intgrit et la confidentialit,
fournir une approche mthodologique dans la construction des schmas.
De faon informelle, on peut dfinir le modle relationnel de la manire suivante :
Les donnes sont organises sous forme de tables deux dimensions, encore appeles relations et
chaque ligne n-uplet ou tuple,
les donnes sont manipules par des oprateurs de l'algbre relationnelle,
l'tat cohrent de la base est dfini par un ensemble de contraintes d'intgrit.
Au modle relationnel est associe la thorie de la normalisation des relations qui permet de se dbarrasser des
incohrences au moment de la conception d'une base de donnes.
Dfinitions
Oprateurs relationnels
Formes normales
Dpendance fonctionnelle
Notion de cl
Formes normales
Langages de manipulation de donnes relationnelles
Remarques

Dfinitions
Dfinition (Domaine) : Ensemble de valeurs.
Dfinition (Relation) : Sous-ensemble du produit cartsien d'une liste de domaines caractris par un nom.
En d'autres termes, une relation n'est ni plus ni moins qu'une table dans laquelle chaque colonne correspond un
domaine et porte un nom ce qui rend leur ordre sans aucune importance.
Dfinition (Attribut) : Colonne d'une relation caractrise par un nom.
Dfinition (Schma de relation) : Nom de la relation, suivi de la liste des attributs avec leurs domaines.
Dfinition (Base de donnes relationnelles) : Base de donnes dont le schma est un ensemble de schmas de
relations et dont les occurrences sont les tuples de ces relations.
Dfinition (Systme de gestion de bases de donnes relationnel) : C'est un logiciel supportant le modle
relationnel, et qui peut manipuler les donnes avec des oprateurs relationnels.

Oprateurs relationnels
Dfinition (Projection) : Opration qui consiste supprimer des attributs d'une relation et liminer les tuples
en double apparaissant dans la nouvelle relation. Cette opration est note Π.
Dfinition (Restriction) : Opration qui consiste supprimer les tuples d'une relation ne satisfaisant pas la
condition prcise.
Dfinition (Jointure) : Opration qui consiste faire le produit cartsien de deux relations, puis supprimer
les tuples ne satisfaisant pas une condition portant sur un attribut de la premire relation et sur un attribut de la
seconde.
Dfinition (Union) : Opration portant sur deux relations ayant le mme schma et construisant une troisime
relation constitue des tuples appartenant chaque relation. Les tuples en double sont limins.
Dfinition (Diffrence relationnelle) : Opration portant sur deux relations ayant le mme schma et
construisant une troisime relation dont les tuples sont constitus de ceux ne se trouvant que dans une seule
relation.
Dfinition (Intersection) : Opration portant sur deux relations ayant le mme schma et construisant une
troisime relation dont les tuples sont constitus de ceux appartenant aux deux relations.

Formes normales
Dpendance fonctionnelle
Dfinition (dpendance fonctionnelle) : Soit R(A1,A2,...An) un schma de relation, et X et Y des sous-
ensembles de {A1,A2,...An}. On dit que X dtermine Y ou que Y dpend fonctionnellement de X si, et seulement
si, des valeurs identiques de X impliquent des valeurs identiques de Y. On le note : X -> Y
Dfinition (dpendance fonctionnelle lmentaire) : C'est une dpendance fonctionnelle de la forme X -> Y,
o A est un attribut unique n'appartenant pas X et o il n'existe pas X' inclus dans X tel que X -> Y.
Notion de cl
Dfinition (cl de relation) : Soit R(A1, A2, ..., An) un schma de relation, et X un sous-ensemble de (A1, A2, ...,
An), X est une cl si, et seulement si, :
X -> (A1, A2, ..., An)
X est minimal
Formes normales
Dfinition (Premire forme normale) : Une relation est en premire forme normale si et seulement si tout
attribut contient une valeur atomique.
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.
Dfinition (Troisime forme normale) : Une relation est en troisime forme normale si et seulement si :
elle est en deuxime forme normale ;
tout attribut n'appartenant pas une cl ne dpend pas d'un attribut non-cl.
Dfinition (Forme normale de BOYCE-CODD) : Une relation est en Forme normale de BOYCE-CODD
(BCNF) si, et seulement si, les seules dpendances fonctionnelles lmentaires sont celles dans lesquelles une cl
dtermine un attribut.

Langages de manipulation de donnes relationnelles

Ces langages, dits assertionnels, sont bass sur la logique des prdicats d'ordre 1 et permettent de spcifier les
donnes que l'on souhaite obtenir, sans dire comment y accder. On doit y trouver des oprations permettant de :
[la modification]
la recherche
retrouver des tuples vrifiant certains critres,

l'insertion
ajouter des tuples,
la suppression
enlever des tuples vrifiant certains critres,
la modification
modifier des tuples vrifiant certains critres.
Un langage de manipulation de donnes n'est pas utilisable lui seul, il doit aussi pouvoir tre incorporable dans
un langage de programmation classique.
On peut distinguer trois grandes classes de langages :
Les langages algbriques bass sur l'algbre relationnelle de CODD dans lesquels les requtes sont
exprimes comme l'application des oprateurs relationnels sur des relations. C'est dans cette catgorie
que l'on trouve le langage sql(structured query language), standard pour l'interrogation de bases de
donnes.
Les langages bass sur le calcul relationnel de tuples construits partir de la logique des prdicats dans
lesquels les variables manipules sont des tuples.
Les langages bass sur le calcul relationnel de domaines, construit aussi partir de la logique des
prdicats mais en faisant varier les variables sur les domaines des relations.
Le langage sql (Structured Query Language) comprend lui seul l'ensemble des instructions ncessaires la
spcification et l'utilisation d'une base de donnes relationnelle. C'est un langage de type dclaratif c'est--dire
que l'on spcifie les proprits des donnes que l'on recherche et pas, comme dans un langage impratif,
comment les retrouver.
Le langage sql est un langage normalis, la dernire version de la norme date de 92 et, souvent, on y fait
rfrence en parlant de sql-92. La prochaine version de la norme est en cours de rdaction afin d'intgrer, entre
autres, la notion de types abstraits algbriques, on la dsigne sous le nom de sql3.
C'est la fois :
un langage d'interrogation de donnes (LID) : SELECT ;
un langage de manipulation de donnes (LMD) : UPDATE, INSERT, DELETE ;
un langage de dfinition des donnes (LDD) : ALTER, CREATE, DROP;
un langage de contrle des donnes et des utilisateurs (LCD) : GRANT, REVOKE.

Remarques
Beaucoup de systmes de gestion de donnes (et non pas de gestion de bases de donnes ) sont vendus comme
tant relationnels, souvent parce qu'ils prsentent les donnes sous forme de tables.
Un systme est dit minimalement relationnel s'il satisfait aux conditions suivantes :
toute information dans la base est reprsente par des valeurs dans des tables,
il n'y a pas de pointeurs visibles par l'utilisateur entre les tables,
le systme doit supporter au moins les oprateurs relationnels de restriction, projection, jointure
naturelle.
Un systme est dit compltement relationnel s'il satisfait, en plus, aux conditions suivantes :
il supporte tous les oprateurs de l'algbre relationnelle,
il supporte la contrainte d'unicit de cl d'une relation,
il supporte les contraintes rfrentielles qui permettent de s'assurer que la valeur d'une donne d'une
relation existe dans une autre relation (notion de foreign key).
En dpit de sa simplicit et de son lgance le modle relationnel n'apporte pas une rponse satisfaisante tous
les problmes des applications. Il faut :
Pouvoir prendre en compte des "objets" structurs ainsi que les oprations qui leur sont associes (bases
de donnes orientes objet).
Prendre en compte des donnes peu structures : textes, sons, images, graphiques (bases de donnes
multimdia).
Faire le pont avec l'intelligence artificielle afin de pouvoir dduire de nouvelles donnes partir de
celles existant dj (bases de donnes dductives)

L'optimiseur de requtes
Avec des langages tels que sql, l'utilisateur prcise les proprits des donnes qui l'intressent sans fournir
d'algorithme d'accs. Les optimiseurs de requte sont l pour cela, leurs objectifs sont de :
vrifier la correction syntaxique de la question,
rechercher des questions quivalentes plus simples,
dterminer l'ordre des oprations lmentaires d'accs en vue de :
rduire le nombre d'entres/sorties,
rduire le temps cpu,
rduire la taille des ressources mmoires ncessaires,
optimiser en premier les questions les plus frquentes.
Chaque sgbd contient un optimiseur de requtes qui peut tre lgrement diffrent d'un sgbd l'autre. Les
algorithmes utiliss sont rarement connus en dtail mais les grandes tapes de l'optimisation sont en gnral :
1. Reprsenter la requte sous une forme interne et la dcomposer en une squence d'oprations
lmentaires.
2. Transformer la requte par :
simplification : remplacement d'une question par une question quivalente plus simple,
ordonnancement des oprations lmentaires.
3. Construire un ensemble de plans d'excution candidats.
4. Calculer le cot de chaque plan et choisir le meilleur.
5. Excuter la requte.
Rcriture des requtes

Choix des chemins d'accs

Requte portant sur une seule table

Jointures sans index

Jointures avec index

ORDER BY

Rcriture des requtes

La reformulation de la requte par l'optimiseur a pour but de minimiser le nombre de calculs effectus. Voici
quelques exemples de transformations possibles :
Les expressions et conditions faisant intervenir des constantes sont, si c'est possible, values. Ainsi,
ge > 60 - 10 sera transform en ge > 50 mais ge + 10 > 60 ne sera pas rcrit en ge
> 50.
un BETWEEN sera remplac par une expression contenant les symboles >= et <= spars par AND.
Une expression logique complexe prface par NOT sera rcrite afin que celui-ci soit mis devant
chacune de ses sous-expressions. Le NOT devant une expression simple sera, si c'est possible, supprim.
Ainsi NOT ge > 50 deviendra ge <= 50.
Les requtes comportant des OR sont rcrites en utilisant des UNION.
Les sous-requtes sont remplaces par des jointures.

Choix des chemins d'accs

L'optimiseur d'interrogation d'oracle est charg de dterminer le chemin d'accs optimal pour excuter un
SELECT.
Le choix porte essentiellement sur l'utilisation des index portant sur les colonnes mentionnes dans la clause
WHERE, sachant qu'en l'absence d'index utilisable une interrogation portant sur une table ncessitera le balayage
total de la table.

Requte portant sur une seule table

L'optimiseur d'interrogation classe les diffrents types de prdicats en fonction de leur syntaxe dans l'ordre
suivant ; du plus slectif au moins slectif :
WHERE rowid = constante
WHERE cl de cluster = constante
WHERE colonne de CONNECT BY indexe = constante
WHERE colonne indexe (unique) = constante
WHERE colonne indexe ( non unique) = constante
WHERE colonne indexe = constante
WHERE colonne indexe BETWEEN val1 AND val2 ou WHERE colonne indexe LIKE 'c%'
WHERE colonne indexe > ou < constante
WHERE MAX ou MIN de colonne indexe
WHERE colonne non indexe = constante
WHERE colonne is null ou is not null
WHERE colonne ! = constante
WHERE colonne indexe LIKE '%c' o WHERE colonne indexe LIKE '_c'
oracle peut dans certains cas utiliser plusieurs index sur une mme table (5 au max), y compris pour valuer des
prdicats lies par OR.
Un SELECT avec plusieurs prdicats indexs lis par AND sera excut comme une intersection du rsultat de
plusieurs SELECT bnficiant chacun d'un index, si les prdicats sont des galits.
Exemple :

SELECT *
FROM emp
WHERE nom = 'MARTIN'
AND n_dept = 20;
De mme un SELECT avec plusieurs prdicats lis par OR sera excut comme une union du rsultat de
plusieurs SELECT bnficiant chacun d'un index. Dans ce cas, il faut que tous les prdicats bnficient d'un
index.
Exemple :

SELECT *
FROM emp
WHERE nom = 'MARTIN'
OR n_dept = 20 ;
Dans ces cas il se peut que l'utilisation de l'un des index soit pnalisante. Ce peut tre le cas d'un index peu
slectif, alors que les autres index utilisables sont trs slectifs. Dans ce cas l'on peut empcher oracle d'utiliser
les index inadquats, en formulant les conditions de telle faon que le critre de recherche soit une fonction de la
colonne indexe et non pas la colonne indexe elle-mme (dans ce cas oracle n'utilise pas l'index).
Exemple :

SELECT *
FROM emp
WHERE nom = 'MARTIN'
AND n_dept + 0 = 20;
o les champs nom et n_dept sont indexs. Le fait d'ajouter 0 la colonne n_dept empche d'utiliser l'index
sur n_dept, qui ne ferait que ralentir la requte car il est peu slectif. L'index sur nom, qui est trs slectif,
suffit.
De la mme faon, l'on peut concatner une chane vide une colonne de type caractre pour empcher oracle
d'utiliser l'index sur cette colonne :

SELECT *
FROM emp
WHERE nom = 'MARTIN'
AND fonction ||''= 'directeur' ;

Jointures sans index

Dans le cas de jointure sans index, oracle classe au pralable chaque table selon le critre de jointure.
L'algorithme est symtrique et l'ordre dans lequel les tables sont mentionnes n'a donc pas d'influence sur les
performances.

Jointures avec index

Dans le cas o le critre de jointure est index au moins dans l'une des tables, oracle choisit une table directrice :
c'est cette table qui sera lue en premier et qui pilotera la jointure. Si le critre de jointure est index dans une
seule des tables, oracle choisit l'autre table comme table directrice. Si le critre de jointure est index dans les
deux tables, la table directrice est celle sur laquelle portent les prdicats les moins slectifs(compte tenu de la
classification des prdicats ci-dessus). Si les prdicats portant sur chaque table sont quivalents, la table
directrice sera la dernire table mentionne dans la clause FROM.
Ainsi, dans l'exemple suivant, l'optimiseur considre que les restrictions portant sur chacune des tables sont
quivalentes, et la table directrice sera la table dept qui est cite en dernier dans la clause FROM.

SELECT *
FROM emp, dept
WHERE emp.n_dept = dept.n_dept
AND dept.nom = 'vente'
AND fonction ='directeur' ;
ORDER BY
L'optimiseur d'interrogation d'oracle dcidera dans certains cas de passer par l'index pour slectionner les lignes
d'une table selon un certain ordre. Pour cela il faut que :
le critre de classement soit le contenu d'une colonne indexe
cette colonne ait l'attribut not null (obligatoire)
la slection porte sur toute la table (pas de WHERE)
Exemple : Le SELECT suivant utilisera l'index sur la colonne salaire si cette colonne ne contient pas de
valeurs NULL.

SELECT nom, salaire

FROM emp
ORDER BY salaire ;

Cohrence des interrogations et accs

concurrents
Ce chapitre tudie les conditions de bon fonctionnement d'un systme de gestion de bases de donnes travaillant
dans un contexte multi-utilisateurs multi-tches. Comme un systme d'exploitation classique gre, partage les
ressources et synchronise les processus, un systme de gestion de bases de donnes doit assurer (entre autres) le
partage des donnes. On retrouve, ici, les problmes classiques de gestion de ressources partages.
Les problmes viter se classent, en gros, en deux catgories : les pertes d'oprations et la rcupration d'une
bases de donnes incohrente. De faon plus dtaille on peut avoir des :
lectures inconsistantes
lectures non reproductibles
des lectures de donnes fantmes
des modifications perdues
des donnes incohrentes
des accs des donnes inexistantes
Il est facile de raliser un systme de gestion de bases de donnes avec un contrle de concurrence simple et
efficace consistant, par exemple, verrouiller la base entire pendant l'excution de chaque transaction. Les
performances d'un tel systme se dgraderaient rapidement avec l'augmentation du nombre d'usagers et il
deviendrait trs rapidement inutilisable.
Un systme raliste doit assurer que :
lectures et critures ne mettant pas en jeu les mmes donnes peuvent s'excuter en parallle ;
les lectures ne sont pas en attente de fin d'criture ou de fin de lecture des mmes donnes ;
les critures ne sont pas en attente de fin de lecture des mmes donnes ;
les critures attendent uniquement la fin d'criture des mmes donnes.
Il faut trouver une solution qui prserve l'intgrit des donnes sans pnaliser les performances. Cette solution
repose sur les notions de :
fichier image avant, "before image" ou "rollback segment", tous ces mots dsignant un, ou plusieurs,
fichiers contenant la valeur des donnes avant la modification ainsi que celle-ci.
base cohrente et de transaction (ces deux notions sont dfinies ci-dessous).
Dfinition (contrainte d'intgrit) : assertion(proprit, prdicat) qui doit tre vrifie par certaines donnes
des instants dtermins.
Dfinition (bases de donnes cohrente) : bases de donnes dont toutes les contraintes d'intgrit sont
respectes.
Les contraintes d'intgrit peuvent non seulement porter sur une donne unique : contrainte de domaine de
variation, contrainte de plage de valeurs, mais aussi sur des donnes rfrenant d'autres donnes .
Dfinition (transaction) : unit de traitement squentiel excute pour le compte d'un usager qui, applique
une base cohrente restitue une base cohrente.
Interrogation
Cohrence d'une interrogation
Cohrence de plusieurs interrogations successives
Mise jour
Interrogation
Cohrence d'une interrogation
Un utilisateur qui interroge une table (mme trs grande) est garanti de voir toutes les donnes telles qu'elles
taient au moment du dbut de l'interrogation, mme si d'autres utilisateurs modifient la table et valident leurs
modifications pendant ce temps.
Les sgbd dont oracle utilisent alors le fichier image avant pour assurer cette cohrence. Le COMMIT des
utilisateurs modifiant la table n'est pas diffr la fin de l'interrogation.
Remarque : Ds que l'on interroge une table, un verrou est plac sur la dfinition de la table, c'est dire qu'un
autre utilisateur ne peut pas dtruire la table, l'indexer, la mettre en cluster ou modifier sa dfinition, jusqu' ce
que l'interrogation soit termine.
Cohrence de plusieurs interrogations successives
Si l'utilisateur dsire que l'on ne modifie pas une table pendant une session de travail, celui-ci peut verrouiller la
table en mode partag au moyen de l'ordre sql suivant :

LOCK TABLE nom_table IN SHARE MODE NOWAIT;

o l'option NOWAIT, qui peut s'adjoindre toutes les commandes de verrouillage, spcifie que le process qui
demande le verrou n'est pas mis en attente si celui-ci n'est pas disponible.
La table n'est alors accessible aux autres utilisateurs qu'en lecture jusqu' la fin de la transaction de celui qui l'a
verrouille (les autres utilisateurs peuvent aussi verrouiller la table en share mode).
Les modifications des autres utilisateurs seront suspendues.

Mise jour
Pour s'assurer l'accs exclusif en modification une table, l'on peut verrouiller cette table en mode exclusif par la
commande :

LOCK TABLE nom_table IN EXCLUSIVE MODE NOWAIT;

La table n'est alors accessible aux autres utilisateurs qu'en lecture et ils ne peuvent plus la verrouiller en mode
exclusif, ni en mode mise jour partage, ni en mode partag jusqu' la fin de la transaction. Ce verrou est
galement obtenu automatiquement ds que l'on effectue un UPDATE, INSERT ou DELETE sur une table. C'est
le mode par dfaut de mise jour d'une table.

Contrle des accs la base et scurit des donnes

Les systmes de gestion de bases de donnes permettent plusieurs utilisateurs de travailler en toute scurit sur
la mme base ou sur des bases diffrentes.
Chaque donne peut tre dfinie, soit comme confidentielle et accessible un seul utilisateur, soit comme tant
partageable entre plusieurs utilisateurs.
Les ordres GRANT et REVOKE du langage sql permettent de dfinir les droits de chaque utilisateur sur les objets
de la base.
Tout utilisateur doit possder un nom d'utilisateur et un mot de passe pour pouvoir accder la base. C'est ce
nom d'utilisateur qui dterminera les droits d'accs aux objets de la base.
Droits d'accs aux tables

Droits d'accs aux tables

La protection des objets d'une base de donnes est dcentralise : c'est le crateur d'un objet qui possde tous les
droits de lecture, de modification et de suppression de cet objet. Les autres utilisateurs n'ont aucun droit d'accs
cet objet, moins que le crateur ne les leur accorde explicitement par une commande GRANT :
 GRANT privilege ON {nom_table | nom_vue} TO nom_utilisateur
WITH GRANT OPTION ;
Les privilges pouvant tre accords sont entre autres les suivants : [update(col,...) ]
SELECT

consultation
INSERT

rajout des lignes

UPDATE(col,...)

modification des lignes (peut-tre restreint certaines colonnes)

DELETE

suppression des lignes

ALTER

modification de la dfinition de la table

ALL

tous les droits ci-dessus

Un utilisateur ayant reu un privilge avec l'option GRANT peut le transmettre son tour (WITH GRANT
OPTION).
Exemple : L'utilisateur scott peut autoriser l'utilisateur douglas lire sa table emp.

GRANT SELECT ON emp TO douglas ;

Les droits peuvent tre accords tous les utilisateurs en employant le mot rserv PUBLIC la place du nom
d'utilisateur.

GRANT SELECT, UPDATE ON emp TO PUBLIC;

Un utilisateur ayant accord un privilge peut le reprendre l'aide de l'ordre REVOKE.

REVOKE PRIVILGE ON {nom_table | nom_vue} FROM nom_utilisateur;

Le propritaire d'une table peut donner des droits de lecture non pas sur la table entire, mais sur une vue base
sur la table. Ainsi, seules les informations faisant partie de la vue seront accessibles.

CREATE VIEW emp1 AS

SELECT nom, fonction, embauche
FROM scott.emp
WHERE n_dept != 10 ;

GRANT SELECT ON emp1 TO PUBLIC;

Tous les utilisateurs pourront slectionner les employs travers la vue emp1 : ils ne verront que les colonnes
nom, fonction, embauche de la table emp et n'auront pas accs aux employs du dpartement 10. Avec
l'option de contrle (CHECK OPTION), les vues peuvent servir raliser les contrles lors des mises jour.
Exemple : La vue suivante ne permettrait pas d'insrer dans la table des employs emp un employ dont le
numro de dpartement ne figurerait pas dans la table des dpartements dept :

CREATE VIEW majemp AS

SELECT *
FROM emp
WHERE n_dept IN (SELECT n_dept
FROM dept)
WITH CHECK OPTION ;
Comme il est impossible de faire une mise jour sur une vue comportant une jointure il faut transformer le
critre de jointure en une sous-interrogation.
Pour oracle , le nom complet d'une table ou d'une vue est le nom donn par le crateur, prfix par le nom du
crateur. Par exemple scott.emp est le nom complet de la table emp cre par l'utilisateur scott . Ceci
permet plusieurs utilisateurs de crer des objets de mme nom sans qu'il y ait confusion. En revanche, pour
accder un objet dont on n'est pas le crateur, il faut le dsigner par son nom complet incluant le nom du
crateur.
 Stockage des donnes
La taille des donnes stockes dans une bases de donnes va de l'ordre de plusieurs centaines de Mega-octets
pour des bases moyennes des dizaines ou des centaines de Giga-octets pour des bases importantes. La plus
grosse base connue ce jour atteint le Tra-octet.
Ces donns, bien videmment, vont tre stockes sur un ou plusieurs disques de faon compltement
transparente pour l'utilisateur final. Les temps d'accs disques tant trs pnalisants, il va falloir essayer de les
minimiser.
Il existe deux possibilits lies au stockage des donnes de minimiser les accs disques :

Les index
Utilisation des index
Valeurs NULL
Conversions
Choix des index
Index comprim et non comprim
Index concatn
Les clusters
Buts

Les index
Selon le modle relationnel les slections peuvent tre faites en utilisant le contenu de n'importe quelle colonne
et les lignes sont stockes dans n'importe quel ordre.
Considrons le SELECT suivant :

SELECT *
FROM emp
WHERE nom = 'MARTIN'
Un moyen de retrouver la ou les lignes pour lesquelles nom est gal MARTIN est de balayer toute la table.
Un tel moyen d'accs conduit des temps de rponse prohibitifs pour des tables dpassant quelques centaines de
lignes.
Une solution offerte par tous les systmes de gestion de bases de donnes est la cration d'index, qui permettra
de satisfaire aux requtes les plus frquentes avec des temps de rponse acceptables.
Un index sera matrialis par la cration de blocs disque contenant des couples (valeurs d'index, numro de bloc)
donnant le numro de bloc disque dans lequel se trouvent les lignes correspondant chaque valeur d'index.

Utilisation des index

L'adjonction d'un index une table ralentit les mises jour (insertion, suppression, modification de la cl) mais
acclre beaucoup la recherche d'une ligne dans la table.
L'index acclre la recherche d'une ligne partir d'une valeur donne de cl, mais aussi la recherche des lignes
ayant une valeur d'index suprieure ou infrieure une valeur donne, car les valeurs de cls sont tries dans
l'index.
Exemple : Les requtes suivantes bnficieront d'un index sur le champ n_dept.

SELECT * FROM emp WHERE num = 16034 ;

SELECT * FROM emp WHERE num >= 27234 ;
SELECT * FROM emp WHERE num BETWEEN 16034 AND 27234;
Un index est utilisable mme si le critre de recherche est constitu seulement du dbut de la cl.
Exemple : La requte suivante bnficiera d'un index sur la colonne nom.

SELECT *
FROM emp
WHERE nom LIKE 'M
Par contre si le dbut de la cl n'est pas connu, l'index est inutilisable.
Exemple : La requte suivante ne bnficiera pas d'un index sur le champ nom.
 SELECT *
FROM emp
WHERE ename LIKE '

Valeurs NULL
Elles ne sont pas reprsentes dans l'index, ceci afin de minimiser le volume ncessaire pour stocker l'index. En
contrepartie, l'index ne sera d'aucune utilit pour retrouver les valeurs NULL lorsque le critre de recherche est
du type IS NULL.

Conversions
L'index n'est utilisable que si le critre de slection est le contenu de la colonne indexe, sans aucune
transformation. Par exemple un index sur salaire ne sera pas utilis pour la requte suivante :

SELECT * FROM emp

WHERE salaire * 12 > 300000 ;
Attention en particulier aux conversions de type qui peuvent empcher l'utilisation de l'index.
sql est un langage typ, chaque type de donnes (numrique, caractre, date) ayant ses propres oprateurs, ses
propres fonctions et sa propre relation d'ordre. En consquence, si dans une expression, figurent la fois un
nombre et une chane de caractres, sql convertira la chane de caractres en nombre. De mme si dans une
expression, figurent la fois une chane de caractres et une date, sql convertira la chane de caractres en date.
Or, dans un prdicat du type :

WHERE fonction(col_indexe) = constante

sql ne peut pas utiliser l'index.
Ceci peut se produire , de faon insidieuse, lorsque sql est oblig d'ajouter un appel une fonction de conversion
cause d'une discordance de type.
Exemple : Le prdicat suivant ne bnficiera pas d'un index sur le champ embauche.

SELECT * FROM emp

WHERE embauche LIKE '
En effet, sql est oblig d'effectuer une conversion, et le prdicat qui sera valu est :

WHERE TO_CHAR(embauche) LIKE '

Le critre de recherche est une fonction de embauche, et non le champ embauche lui-mme, dans ce cas
l'index est inutilisable.

Choix des index

Indexer en priorit :
1. les cls primaires
2. les colonnes servant de critre de jointure
3. les colonnes servant souvent de critre de recherche
Ne pas indexer :
1. les colonnes contenant peu de valeurs distinctes (index alors peu efficace)
2. les colonnes frquemment modifies

Index comprim et non comprim

Les cls dans les index peuvent tre comprimes ou non. La compression est une technique permettant de rduire
dans des proportions trs importantes (d'autant plus que la cl est longue) le volume de l'index.
En contrepartie, il faut parfois un traitement supplmentaire pour recomposer la cl lors des mises jour de
l'index.
Par dfaut, les index sont comprims, les avantages de rduction de taille l'emportant sur les inconvnients dans
la plupart des cas.
sql sait excuter certaines requtes directement au niveau de l'index sans passer par le segment de donnes, si
l'index est non comprim et si tous les champs rsultats de la requte sont dans l'index.
Exemple : L'index cre par :

CREATE INDEX x
ON emp (num, nom)
nocompress ;
permettra de rpondre la question :

SELECT nom
FROM emp
WHERE num > 17217 ;
sans lire la table puisque toutes les informations se trouvent dans l'index et que l'index est non concatn.
Index concatn
Un index concatn est un index portant sur plusieurs colonnes.
Exemple :

CREATE INDEX xemp

ON (n_dept,num) ;
Les index concatns peuvent tre utiliss pour matrialiser une cl compose de plusieurs colonnes.
sql sait utiliser un index concatn mme si le critre de recherche ne porte pas sur toutes les colonnes prsentes
dans l'index.
Exemple : L'index ci-dessus est utilisable si l'on ne connat que le numro de dpartement.

SELECT nom
FROM emp
WHERE n_dept = 20 ;

Les clusters
Buts
Le cluster est une organisation physique des donnes qui consiste regrouper physiquement (dans un mme bloc
disque) les lignes d'une ou plusieurs tables ayant une caractristique commune (une mme valeur dans une ou
plusieurs colonnes) constituant la cl du cluster.
La mise en cluster a trois objectifs :
acclrer la jointure selon la cl de cluster des tables mises en cluster,
acclrer la slection des lignes d'une table ayant mme valeur de cl, par le fait que ces lignes sont
regroupes physiquement,
conomiser de la place, du fait que chaque valeur de la cl du cluster ne sera stocke qu'une seule fois.
Le regroupement en cluster est totalement transparent l'utilisateur : des tables mises en cluster sont toujours
vues comme des tables indpendantes.
Par exemple on pourrait mettre en cluster les tables emp et dept selon n_dept. Ces tables seraient
rorganises de la faon suivante : un bloc de cluster serait cr pour chaque numro de dpartement, ce bloc
contenant la fois les lignes de la table emp et de la table dept correspondant ce numro de dpartement. La
jointure entre les tables emp et dept selon n_dept deviendrait alors beaucoup plus rapide, puisqu'elle serait
dj ralise dans l'organisation physique des tables.
Pour que l'on puisse mettre une table en cluster il faut que l'une au moins des colonnes faisant partie du cluster
soit dfinie comme obligatoire (NOT NULL).
On peut indexer les colonnes d'une table en cluster, y compris les colonnes correspondant la cl ou une partie
de la cl du cluster. La cl elle-mme est automatiquement indexe, on peut ventuellement la rindexer pour
crer un index unique servant contrler son unicit.