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