Architectures, modèles et langages de données

Transcription

1 Architectures, modèles et langages de données OLAP Hypercube Ingénierie des bases de données Fascicule 3 c,d Volume I Langage SQL, indexation et vue relationnelle André Gamache 2005

2

3 Architectures, Modèles et Langages de Données Volume 1 Fascicule 1 1- Introduction 1 2- Architecture fonctionnelle du SGBD Modèle conceptuel des données 79 - Index Fascicule 2 4- Modèle relationnel : théorie et contraintes d intégrité 1 5- Algèbre relationnelle Transposition du MCD au MRD Index Volume 2 Fascicule 3 7- Langage de données SQL 1 8- Indexation, vue relationnelle et base réactive Index Fascicule 4 9- Langage de programmation et SQL Théorie de la normalisation relationnelle : les formes normales FN1 à FN Optimisation des requêtes relationnelles 117 Annexes : A- SQLoader B- Projet ALU-Nord : Script de chargement des données - Index

4

5 5 Chapitre 7 Langage de données SQL DDL, DML et les recherches Dans les sections précédentes, les éléments au langage SQL ont été présentés afin d illustrer les formulations équivalentes aux opérateurs algébriques. La facette DDL du langage a aussi été présentée avec plusieurs détails afin de pouvoir créer et formuler correctement les contraintes des tables. Dans ce chapitre, nous approfondirons les clauses SQL DDL en examinant quelques paramètres qui ont trait aux structures physiques et nous poursuivrons l étude du langage de requête SQL, en accentuant davantage les diverses fonctions disponibles dans ce langage sans égard à leur implémentation dans un SGBD particulier. Encore ici, de nombreux exemples sont formulés avec le SQL implémenté par Oracle, lequel correspond à peu près au niveau 2 de la norme SQL 92. Nous étudierons en détails l implémentation Oracle de certaines notions qui sont particulières à ce logiciel SGBD. Cependant, notre étude débordera les limites imposées par Oracle pour discuter aussi de plusieurs autres notions et implémentations propres à d autres SGBD. 7.1 Langage SQL et l exploitation de la base de données Le langage de données SQL créé dans les années 70 découle des travaux d une équipe de chercheurs de la société IBM qui travaillait à la mise au point des langages de données SQUARE et SEQUEL dans le cadre du développement du système R, précurseur de plusieurs SGBD relationnels, notamment du système SGBD DB2. Lʹacronyme SQL signifie Structured Query Language. C est un langage à mots clés réservés. Il est non procédural dans sa formulation, masquant assez bien le caractère algébrique des expressions syntaxe relativement simple, mais affiche une facette de langage naturel, soit l anglais élémentaire. Le langage SQL a fait lʹobjet de plusieurs efforts de normalisation qui ont débuté de façon sérieuse en 1989 et qui se poursuivent toujours. Toute norme SQL publiée peut être implantée à divers niveaux, selon les choix faits par le développeur du SGBD. Trois niveaux sont possibles : minimal (1), intermédiaire (2) et complet (3). Ce dernier niveau doit respecter intégralement la norme SQL. Il y a plusieurs normes SQL, chacune enrichissant la version précédente : SQL 89, SQL 92 et SQL 93. Lʹimplantation de SQL par la société Oracle est fortement similaire à la norme ISO SQL 92 de niveau 2. Il en est de même aussi pour le système WATCOM SQL. Le langage SQL comporte trois facettes fortement intégrées peu importe le SGBD relationnel : a) DDL (Data Definition Language), pour la définition des tables, des contraintes diverses et des vues relationnelles stockées dans le dictionnaire du SGBD. b) DML, (Data Manipulation Language) pour la manipulation des tables et plus précisément les manipulations des tuples de relations. c) DCL, (Data Control Language) pour gérer la définition physique des accès (index), la spécification des fichiers physiques et la validation des opérations exécutées dans un contexte multiposte.

6 6 SQL et les autres langages L3G Le langage SQL (Oracle) est utilisé de façon autonome et interactive (au moyen du module SQL*Plus interactif). Il est aussi utilisé dans les blocs de PL/SQL (SQL intégré à un langage procédural interactif de Oracle) et dans les applications mises au point avec les L3G grâce aux API (interfaces de programmation pour les applications). Finalement, le SQL dynamique permet la formulation de requêtes dont la spécification complète ne sera connue qu au moment de lʹexécution. SQL*Plus (rappel sur cette application) Les clauses du langage SQL de Oracle sont prises en charge par le module utilitaire SQL*Plus qui les réceptionne et les transmet à lʹinterpréteur de SQL qui est un service intégré du SGBD. Après le calcul de la réponse, le module SQL*Plus reçoit les tuples et les affiche selon des paramètres qui peuvent être fixés par lʹutilisateur au moyen de directives particulières. Il y a dʹautres modes dʹinteraction avec le SGBD, notamment par lʹentremise des applications développées en langage de troisième génération (L3G) et utilisant lʹinterface API appelée OCI chez Oracle. Le module SQL*Plus est donc lʹintermédiaire incontournable lorsquʹun développeur veut exécuter une clause SQL en mode interactif. Le texte de la dernière clause est placé dans un tampon prédéfini et nommé par un nom interne suffixé par SQL. Cet espace peut contenir seulement une clause SQL, excluant les directives ayant trait au formatage, à lʹenvironnement et à lʹaffichage de la réponse par le module SQL*Plus. Pour contourner cette restriction, il est possible de définir un autre tampon courant par la directive SET BUFFER dont la durée est celle de la session de travail. BD Directives SQL*Plus SGBD SQL*Plus serveur Tampon SQL*Plus client Figure 7.1 Utilitaire SQLPlus et script d exécution L application utilitaire SQLPlus est incontournable pour la mise au point et l exécution en ligne des clauses SQL. Cette utilitaire SQL*Plus comporte plusieurs directives : SET BUFFER tampon1 -- un autre tampon courant est créé SAVE C:\tampon1.sql --sauvegarde du tampon dans un fichier sur C SET BUFFER SQL -- retour au tampon par défaut de SQL*Plus

7 7 En outre, il est possible dʹenregistrer une trace complète de lʹaffichage avec la directive SPOOL : SPOOL C:\trace.4juillet -- trace dans un fichier SPOOL ON -- début de la trace SPOOL OFF -- pour terminer la trace; spool ON pour redémarrer Un fichier de directives est très utile pour obtenir lʹenvironnement désiré et cela, dès le début dʹune session de travail. Voici un exemple dʹun tel fichier script qui est exécuté par la directive : START :environbd3.sql) Dans le fichier script, il faut insérer les commandes et/ou les directives suivantes : ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YYYY', ALTER SESSION SET NLS_LANGUAGE_FORMAT = french COLUMN NOM FORMAT A25.../*liste des formats requis pour l affichage des colonnes*/ Le fichier est exécuté par START envirobd3.sql ou en le nommant init.sql ou login.sql, auquel cas il sera exécuté automatiquement avec le lancement du module SQL*Plus. Avant dʹaborder lʹétude du langage SQL, il est utile de survoler les différentes structures utilisées par la base de données afin de donner un sens physique aux paramètres des ordres SQL DDL. Ce survol est effectué en faisant référence au système Oracle dont lʹimplémentation du modèle relationnel et du langage SQL est reconnue comme étant de très bon niveau. Les directives du module SQL*Plus sont résumées dans le tableau ci dessous. APPEND* CHANGE CLEAR DEL DESCRIBE GET HOST <commande> LIST RUN *** SAVE <fichier.sql> SPOOL <fichier.sql> Ajout de texte à la fin de la ligne courante Changement de texte dans une ligne Supprimer le contenu du tampon courant Supprimer la ligne courante Liste du schéma d une table Lecture d un fichier dans le tampon Exécution d une commande de l OS (hôte) Afficher le contenu du tampon courant Exécution de la commande ou du script rangé dans le tampon courant de l application SQL*Plus Écriture de tampon courant dans un fichier Écriture de la trace de l écran dans un fichier

8 8 * Les directives et les commandes peuvent être écrites indifféremment en majuscules ou minuscules. Fonctions du dictionnaire de données Le dictionnaire de données (DD) dʹun système relationnel est implanté comme une base de données du même type. Les structures de données utilisées sont les mêmes que celles utilisées pour stocker les données transactionnelles. Le dictionnaire contient les métadonnées nécessaires pour définir notamment les tables de la base de données. Le dictionnaire de données joue un rôle central dans le fonctionnement du SGBD relationnel. Son contenu est rangé dès le démarrage dans la RAM, accessible en ligne par le noyau du SGBD. Les tables du dictionnaire servent à diverses fonctions: a) Stockage de la définition de la base de données : schéma, index, trigger, packages, fonctions, procédures, synonymes (alias) etc. Il est entièrement accessible à lʹadministrateur des données (DBA) et partiellement aux utilisateurs qui peuvent consulter les tables (et les autres objets) dont ils sont propriétaires. b) Passerelle incontournable entre le noyau du SGBD et lʹinterpréteur du SQL pour effectuer lʹanalyse et le traitement des requêtes SQL. Le dictionnaire est essentiel à lʹappariement (binding) dynamique avec les applications L3G, notamment en ce qui concerne la compatibilité entre le type interne dʹune donnée et le type externe disponible dans le langage de programmation hôte. c) Documentation des divers objets de la base de données : tables, index, attributs, déclencheurs, packages. d) Participation à la sécurité et à lʹintégrité de la base en stockant les droits dʹaccès des utilisateurs aux tables de base, aux vues et aux espaces de données. e) Répartition des données au moyen des liens entre les bases qui sont spécifiées dans le dictionnaire et leur localisation géographique. Introduction à lʹorganisation des espaces physiques et logiques de la base de données Oracle La base de données Oracle est définie comme un ensemble de tables (relations) appartenant au compte créateur des tables qui a généralement la propriété du DBA. L unicité du nom dʹune table est assurée par l adjonction automatique du préfixe formé avec le numéro de compte de lʹutilisateur propriétaire. La répartition des données sur plusieurs serveurs est prise en considération par les métadonnées du dictionnaire sur la localisation, notamment les liens de placement. L ensemble des définitions de table correspond au schéma de la base de données qui est exprimé en SQL DDL. 7.2 Objets Oracle Un objet ou plus précisément une entité de la base de données Oracle, est la notion utilisée pour représenter les éléments suivants : le schéma de relation, lʹextension d une

9 9 relation (table), les déclencheurs (trigger), la fonction, la procédure interne, lʹespace de données, lʹindex, la vue, le trigger et le package. Tous ces objets sont rangés dans les tables du dictionnaire du SGBD, sauf l extension de la relation qui est stockée dans un espace de table (tablespace). L accès à chacun des objets est contrôlé par des droits qui sont accordés et, au besoin, révoqués par le DBA. Compte4.r1 Dictionnaire de données, schémas, procédures, Compte5.r2 BD SGBD Instance1 Compte6.r2 Figure 7.2 Espace de stockage Oracle Une relation du MRD est implémentée par une structure de table définie comme une liste de pages physiques appartenant à un tablespace défini et associé à un ou plusieurs fichiers gérés par le système d,exploitation du serveur. Chaque table ne contient généralement que des tuples de même schéma. Il y a une exception avec les tables stockées dans un cluster. Un extent est l unité d allocation de l espace et les extents d une même table forment un segment. Piage i Page i+1 extent1 extent2 Structure physique de table : pages enchaînées Figure 7.2a Chaque table dʹun schéma appartient au compte (Oracle) qui l a créée. Par défaut, le nom complet dʹune table est formé du nom du compte suffixé par le nom de la table: comptechef. Tous les droits d accès sur une table sont acquis automatiquement par le propriétaire de la table qui peut cependant les partager en propageant aux autres les droits dʹaccès appropriés (commande GRANT). Une table Oracle est accessible par diverses interfaces relationnelles, notamment via le module SQL*Plus, le langage procédural PL/SQL et lʹinterface de programmation des applications (API) utilisant un langage de troisième génération.

10 10 Organisation logique des espaces de stockage pour les données et les index La structure de l espace physique d une base de données est définie par le DDL au moyen de plusieurs paramètres qui spécifient l allocation initiale de l espace pour une table, à même celui du tablespace auquel la table sera associée. Les données du système Oracle sont stockées via des espaces logiques, appelés espaces de table (tablespaces) (TS), chacun composé de segments, eux mêmes composés de lots homogènes et contigus d octets appelés extents. Ces espaces sont utilisés pour stocker notamment les tables, les index, les clusters et les données des segments de recouvrement transactionnel (rollback). B Fichier B Fichier A Espace de table AB Segment 1 Segment 2 pages Extent 1 Extent 2 Extent 3 Extent 4 Figure 7.2b Une extent est défini comme une unité dʹallocation de lʹespace physique. Les extents dʹun segment peuvent être dispersés et chaînés. Sur le plan de l espace physique, un extent est formé de pages contiguës (blocs Oracle). Finalement, une page est constituée de plusieurs blocs du système d exploitation hôte, blocs dont la taille est fixée lors de la création de la base de données. Lʹespace physique dʹune base de données peut être augmenté par le DBA, par lʹajout, en tout temps, dʹun ou de plusieurs fichiers dans un espace de table particulier. Page Oracle Une page Oracle est une suite de blocs physiques constitués dʹoctets contigus (1 K à 16 K). La taille d une page est fixée à la création de la base de données par le paramètre DB_BLOCK_SIZE initialisé dans le fichier INIT.ORA. Une page contient normalement des tuples dont la structure est homogène, i.e. appartenant à une seule table, sauf pour les pages de cluster. Ces pages ont une structure particulière permettant d y ranger des tuples en provenance d au moins tables différentes. Espace de table (tablespace) Toute entité ou tout objet dans une base de données relationnelle est rangée dans une table qui est elle même placée dans un espace de table particulier appelé tablespace. Cet espace sur disque est associé à un fichier physique. Le compte Oracle SYS est, à la création de la base de données, le propriétaire initial des objets du dictionnaire et de

11 11 certaines autres tables utilisées en cours dʹexploitation pour stocker les métadonnées traitant de la performance et de lʹexploitation des tables. Le premier compte DBA créé lors de lʹinstallation du SGBD est nommé SYSTEM. L espace de table SYSTEM est aussi créé à lʹinstallation et il appartient au compte de même nom. Les divers objets créés y sont placés par défaut, y compris ceux des utilisateurs, sauf si lʹutilisateur propriétaire de lʹobjet requiert de le faire autrement. Une meilleure performance est atteinte si les objets dʹindex et de tables des utilisateurs sont placés dans autant de TS (tablespace) distincts créés par le DBA. C est le principe de base de l architecture optimale appelée OFA (Optimal Flexible Architecture) et suggérée pour Oracle BD * EspaceDeTab FichierPhysique 1..* 1..* * Comptes * 1..* Table * Page 1..* * 1..1 Schémas 1..1 Segment 1..* 1..* 1..1 Extent Figure 7.3 Structure générale de page Une page a une taille fixée au lancement de lʹinstance et cela, par lʹentremise du paramètre de système BLOCK_SIZE. Sa taille peut varier jusquʹà 16 Ko. Chaque page a une zone de gestion de son espace qui est appelée répertoire des tuples ou de lignes. L espace d une page est assortie d une contrainte qui est la suivante : PCTFREE + PCTUSED < 100 Dans ce répertoire, on trouve une entrée où est inscrit un déplacement (offset) dans la page qui est en quelque sorte un pointeur sur le début du tuple. Lors dʹune réorganisation de la page, les tuples sont déplacés vers le bas afin de récupérer lʹespace libre. Seuls les déplacements sont modifiés, tandis que le rid ( soit le TID pour Ingres et le ROWID pour Oracle) demeure constant, évitant ainsi de faire la mise à jour des index

12 12 En tête de page Zone d élargissement des tuples Zone de tuples INITRANS : espace pour la gestion des accès à la page MAXTRANS : nombre maximum de transactions en accès simultané. PCTFREE : % de l espace de page réservé à l élargissement des tuples lors de la mise à jour. Répertoire des tuples PCTUSED : % de la page réservé aux données et en dessous duquel la Figure 7.4 Lʹen tête de la page contient des données pour la gestion transactionnelle, notamment les adresses logiques (rid) des tuples verrouillés avec le numéro de la transaction propriétaire du verrou. Lors dʹune relecture de la page, le système vérifie si une transaction inscrite dans lʹen tête (qui a donc lu un tuple) est encore active et, dans le cas affirmatif, considère que le tuple est toujours verrouillé. Sinon, le verrou est périmé et le tuple est considéré disponible pour les autres transactions. L adresse logique d un tuple nommé rid ou rowid (row identifier) est souvent formée de la façon suivante : rid ::= nofichier:nopage:noentreedansrepertoire Page Oracle Chaque page ou bloc Oracle est composé de blocs physiques d octets contigus et est l espace utilisé pour ranger les tuples d une même table. La structure de la page comprend au moins trois parties : un en tête, une zone primaire pour ranger les tuples (PCTUSED) et une zone de débordement (PCTFREE) pour ranger les tuples dont la taille a augmenté suite à une mise à jour. Par défaut, le système Oracle fixe la zone primaire à 40% de la taille de la page et la zone de débordement à 10 %. Dans les cas où il y a peu de mises à jour et beaucoup d ajouts, les valeurs par défaut (10/40) pour les paramètres PCTFREE et PCTUSED ne sont pas toujours adaptées aux besoins d un tel environnement d exploitation. Il faut les ajuster par exemple à 5/80 lorsquʹil y a peu de mises à jour. Le rôle du paramètre PCTFREE est de réduire le chaînage des parties de tuples dʹune page à lʹautre. Cette fragmentation dʹun tuple devrait se faire pour réaliser une mise à jour qui exige un espace plus grand non disponible à lʹadresse actuelle. À la création dʹune page, le paramètre PCTFREE indique le pourcentage de la page à garder en réserve pour y reloger les tuples mis à jour. Le paramètre PCTUSED permet de

13 13 minimiser les lectures et les écritures sur le disque en indiquant au serveur le pourcentage de lʹespace occupé dʹune page, qui doit être atteint avant que la page soit désignée à nouveau comme une page insérable. En effet, les insertions se poursuivent dans une page tant et aussi longtemps que le pourcentage du PCTFREE est respecté. À ce moment, la page est marquée non insérable et supprimée de la liste des pages disponibles (free list). Des insertions de tuples seront faites à nouveau dans cette page, lorsque les suppressions ramèneront le pourcentage dʹoccupation de lʹespace sous la barre du paramètre PCTUSED. Les tuples des tables et des index peuvent cohabiter ou non dans le même espace de table tout en étant rangés obligatoirement dans des segments différents et donc dans des extensions différentes. Dans une extension donnée, il n y a donc que des pages de données de tables ou d index et non les deux. Dans les deux cas, les paramètres PCTFREE et PCTUSED sont utilisés pour la gestion de lʹespace de la page. Avec lʹindex, le paramètre PCTFREE doit être assez grand pour une table indexée, surtout lorsque le taux de mise à jour est élevé. En effet, tout ajout de tuples dans une table indexée entraîne une mise à jour de lʹindex, donc une augmentation de la taille des entrées, notamment pour les index sur les attributs de type chaîne. Ceci entraîne rapidement un débordement dans la zone libre. Pour éviter le chaînage des tuples qui ralentit la lecture, il faut prévoir dans chaque page un espace libre un peu plus grand pour les pages destinées à stocker les index. Page insérable Une page a le statut dʹinsérable si le SGBD est autorisé à y ajouter encore des tuples, sinon elle a le statut de page non disponible. Lorsque l occupation dʹune page est telle que lʹespace restant correspond à lʹespace réservé par le PCTFREE, la page est enlevée de la liste des pages insérables (free list). Elle ne peut plus recevoir de nouveaux tuples, mais on peut toujours mettre à jour les tuples présents en utilisant la zone libre ou de débordement. Par contre, lorsque les suppressions et les modifications (changement de la valeur d un attribut qui fait passer sa taille de 450 à 40 caractères ou la mise à jour d un attribut null) ramènent l espace occupé en dessous de la valeur PCTUSED pour cette page, celle ci est réinscrite dans la liste des pages insérables et de nouveaux tuples peuvent y être ajoutés. Lorsquʹun tuple est ajouté dans une page, il est possible que lʹespace occupé dépasse le PCTUSED, et cela, tant que la limite du PCTFREE est toujours respectée. Cette situation peut se produire si PCTUSED + PCTFREE < 100. Lorsque les paramètres PCTUSED et PCTFREE ne sont pas adaptés à lʹenvironnement d exploitation de la base de données, cela conduit à des échanges de pages supplémentaires inutiles entre le disque et la ZMP (Zone de Mémoire Partagée). Pour une exploitation avec un faible taux de réorganisation et de mise à jour, le facteur PCTUSED devrait être de l ordre de 80 et le PCTFREE de 10.

14 14 Migration des tuples Lorsquʹun tuple est modifié et quʹil ne peut pas être replacé dans son espace dʹorigine, le système cherche à le ranger en entier dans lʹespace du PCTFREE (zone de débordement) et une adresse de suivi est placée dans lʹespace dʹorigine afin de garder lʹadressage initial fonctionnel pour les index. Tuple modifié et placé dans la zone de débordement 12 :89 Place initiale du tuple de rid = 12 :34 Figure 7.5 Ainsi, les entrées dʹindex sur cette table pointent toujours au même rid (ou rowid) et dans la même page et cela, même si le tuple pointé a été déplacé. Le traitement des index incorpore celui du suivi dʹun tuple au fil de ses adresses de déplacement. Cʹest la migration des tuples. Pour lire un tel tuple, le système nʹa pas à effectuer un accès disque supplémentaire puisquʹil se trouve dans lʹespace de débordement de la même page. Après lʹinsertion du tuple dans lʹespace PCTFREE (débordement), lʹespace dʹorigine nʹest occupé que par une adresse de suivi et le reste de cet espace pourra être éventuellement récupéré pour y placer les données dʹun autre tuple. Si le tuple modifié ne peut pas être rangé dans lʹespace du PCTFREE, il est déplacé entièrement dans une nouvelle page insérable et la nouvelle adresse est aussi rangée dans son emplacement initial afin dʹen permettre le suivi à partir des index existants, qui pointent toujours sur lʹemplacement dʹorigine. Lʹinconvénient de cette gestion est que cela oblige à faire deux lectures au lieu dʹune seule pour accéder au tuple recherché. Fragmentation des grands tuples et chaînage Une deuxième solution à la gestion des tuples plus encombrants (par exemple les tuples avec un BLOB) consiste à les diviser et à chaîner leurs parties. Lorsquʹun tuple modifié ne peut pas être rangé ni dans sa page dʹorigine ni dans une autre page de la base de données, le serveur divise le tuple en parties chaînées et chacune sera rangée dans une page ayant lʹespace suffisant. PCTFREE en tête tuple rid : 23:12 123:45 PCTUSED 56:77 Figure 7.6

15 15 Cʹest le chaînage dʹun tuple qui nʹintervient que lorsque la migration est impossible. Le chaînage est aussi pénalisant parce quʹil faut faire plusieurs lectures sur disque pour retrouver la première partie et autant de lectures supplémentaires pour lire les autres. Placement des données : regroupement La notion de regroupement des tuples (dans une structure de cluster) concerne généralement plusieurs tables qui partagent les pages dʹun même segment spécial appelé cluster. Valeur de clé du cluster = 45 ::::23 :34 (45) ::::23 :67 En tête du cluster 45, jacques, 75 75, patricia, 45 Figure 7.6a Ces tuples cohabitent parce qu ils ont en commun des valeurs d attributs de regroupement (key cluster attributes) et quʹils sont souvent utilisés par les applications dans une opération de jointure. Étant logés dans les mêmes pages, la vérification de la condition de jointure sera faite plus rapidement parce quʹils seront accessibles sans nécessiter d échanges de pages supplémentaires entre le noyau du SGBD et le disque des données. On peut concevoir la structure logique dʹun cluster comme ayant un répertoire dʹen tête construit avec les valeurs partagées par deux tuples de tables différentes. Chaque entrée du répertoire pointe sur les deux tuples au moyen de deux rid. Un cluster peut aussi être défini pour ne loger que les tuples dʹune même table, en les regroupant selon la valeur dʹun attribut particulier. Rappel de quelques notions sur les arbres utilisés par les index Les index utilisés par Oracle 2 ont généralement une structure en B* arbre. Ils sont rangés dans des tables, elles mêmes placées dans un segment dédié à un index et éventuellement dans un espace de données (tablespace) spécialisé, créé par le DBA. Cette structure est du type index hiérarchique : les feuilles pointent sur les adresses rids (ou encore ROWID) des tuples indexés par un attribut dont les valeurs indexées sont regroupées et ordonnées dans une cellule terminale (feuille). Chaque cellule terminale est indexée au niveau supérieur qui contient un pointeur de plus que le nombre de valeurs dans la cellule. Par exemple, la recherche du tuple indexé par la valeur 76 débute à la racine, par l examen de la première et de la dernière entrée pour déterminer le sousarbre à explorer. Le premier examen indique qu il faut explorer le sous arbre milieu et la

16 16 procédure se poursuit ainsi jusqu à l atteinte du dernier niveau. Une telle structure arborescente est gardée équilibrée par une procédure de mise à jour et la longueur moyenne du chemin d accès à n importe quel tuple est constante. Pour 10 6 tuples, il faut environ cinq accès pour retrouver un tuple. Dans le pire des cas, cinq lectures sur disque sont nécessaires pour obtenir autant de pages. Chaque clé primaire spécifiée dans un schéma de table génère soit un index interne (du type Système), soit une procédure interne pour vérifier la contrainte de clé. Toutefois, lʹindex système peut être désactivé (disable), auquel cas l index nʹest pas utilisé pour renforcer la contrainte dʹentité. La contrainte de NULL continue de sʹappliquer aux attributs primaires. La création d un index avec un attribut se fait par une commande SQL DCL et suppose un tri des valeurs de la clé. Lʹopération sera effectuée dans un espace de mémoire temporaire géré par le SGBD. Un index créé par le DBA peut être supprimé à volonté et refait plus tard. Dans certains cas, le DBA peut accorder à un utilisateur le droit de créer un index. Si une telle structure est intéressante pour la recherche, elle gêne souvent la mise à jour. En effet, l ajout d un nouveau tuple indexé par la valeur 9 implique une insertion de la clé dʹindexation dans la cellule référencée par le pointeur droit de la clé 3 (voir Figure 7.8). Or, cette cellule étant déjà saturée, la cellule ciblée sera divisée et la valeur médiane insérée au niveau supérieur par la même procédure. Ces opérations exigent des accès aux disques qui ralentissent les opérations dʹaccès à la base de données. Le maintien de l équilibre de l arbre est toutefois assuré et réparti entre les différentes opérations sur la base de données. 7.3 B arbre Le B arbre dʹorigine est construit à partir de la racine et il est géré pour demeurer toujours équilibré, i.e. avec une hauteur à peu près constante (Figure 7.7) tuple Pointeur sur clés supérieures à celles de gauche et inférieures à celles de droite. Pointeur sur tuple L absence de la flèche indique l absence de pointeur. Figure

17 17 Les cellules feuilles sont aussi reliées par un chaînage latéral afin de faciliter le balayage séquentiel partiel ou complet des tuples d une table. Les caractéristiques de cette structure sont les suivantes : Une cellule contient p pointeurs aux sous arbres toujours équilibrés et un maximum de (p 1) clés. Lʹarbre est dit dʹordre p. Le pointeur à la gauche dʹune valeur de clé référence un sous arbre dont les clés sont inférieures ou égales à la clé du nœud; le pointeur à la droite fait référence un sous arbre dont les clés sont supérieures. Le pointeur sur un tuple est constitué du rid, cʹest à dire lʹadresse de la page. Ce pointeur est inséré dans chaque nœud et non seulement dans les feuilles. Avec l arbre d ordre 3 de la Figure 7.7 ( 3 pointeurs et 2 valeurs de clé), la clé 9 est ajoutée pour fournir l arbre suivant représenté à la figure 7.8. Le rééquilibrage est généralement immédiat, ou légèrement différé, cʹest à dire quʹil est fait pratiquement à chaque ajout ou modification dans le B arbre. En insertion, le tuple est stocké dans une page et sa clé insérée dans la cellule appropriée de lʹindex avec les divisions et les migrations des tuples quʹimposent les règles dʹéquilibre. La principale caractéristique de cet arbre est que les nœuds internes contiennent des pointeurs aux tuples et que les clés ne sont pas redondantes dans les feuilles. Procédure algorithmique dʹinsertion La clé dʹun tuple est insérée en trouvant la cellule où elle devrait être normalement placée. Sʹil y a lieu, la division de la cellule est faite et la clé à la droite de la médiane est déplacée au le niveau supérieur en utilisant la procédure dʹinsertion. Lʹopération est récursive. Procédure de suppression La suppression dʹun tuple dans une cellule conserve cette dernière intacte si le nombre de pointeurs résiduel est supérieur à p/2, où p est lʹordre de lʹarbre.

18 tuple tuple Figure Calcul de la hauteur dʹun arbre dʹordre 3 (avec p = 3 pointeurs par cellule) La hauteur dʹun B arbre peut être estimée par un simple raisonnement inductif : niveau h=1: 1 cellule, 3 pointeurs et 2 clés : 3 0 p 0 cellule et p 0 x (p 1) clés niveau h=2: 3 cellules, 9 pointeurs et 6 clés : 3 1 p 1 cellules et p 1 x (p 1) clés niveau h=3 9 cellules, 27 pointeurs et 18 clés : 3 2 p 2 cellules et p 2 x (p 1) clés donc au niveau h : p (h 1) (p 1) >= n (où n est le nombre de tuples) (h 1)log p + log(p 1) >= log n h>= 1 + (log n log(p 1)) avec log dans la base p (soit l ordre de l arbre). Donc le nombre moyen de pages lues dans un accès est environ logp n (dans la base p). Pour un arbre d ordre plus élevé, par exemple 50, les gains en terme d accès sont encore plus significatifs : avec n = tuples et p = 50 on a h 4. Soit quatre lectures nécessaires pour atteindre la feuille recherchée dans un B arbre. Dans le cas courant où la cellule est une page, lʹadresse se réfère à celle ci, la recherche dʹune clé en mémoire se fait très rapidement. En effet, la taille d une page (8Ko) pour la cellule confère un ordre relativement élevé à l arbre pour ainsi en diminuer sensiblement la hauteur à une constante généralement inférieure à 8. La base p du logarithme joue un rôle critique. En effet, plus p est grand, plus la valeur du log dans la base p est petite. Avantages de la structure en B arbre Le B arbre offre plusieurs avantages lorsquʹil est utilisé comme index : Le parcours moyen pour trouver un tuple est inférieur à la hauteur de lʹarbre.

19 19 Il nʹy a pas de redondance des clés à la suite dʹune duplication dans les feuilles. La hauteur dʹun arbre pour indexer un nombre n de dossiers est la même quel que soit le chemin parcouru. Pour 2 millions de tuples, il est de lʹordre de 5 accès au disque. Inconvénients du B arbre Lʹajout et la suppression sont des opérations complexes en raison de la réorganisation des nœuds internes. Périodiquement, le DBA aura à supprimer lʹindex et à le recréer pour compacter les entrées. Les pointeurs aux tuples (8 octets) occupent lʹespace des cellules autrement occupé par des clés. Finalement, le parcours séquentiel des tuples est parfois difficile, voire impossible ou impraticable, en cas dʹabsence de chaînage latéral à tous les niveaux et en raison de la dispersion des pages qui exige plusieurs lectures sur le disque. B* arbre La structure du B* arbre est similaire à celle du B arbre, mais les clés des cellules intermédiaires sont aussi insérées dans les feuilles avec le pointeur aux tuples, i.e. aux données. Les nœuds intermédiaires ne pointent pas sur les tuples. Il y a donc une certaine réduction de la redondance, augmentant ainsi la densité des tuples dans les pages de données. Le parcours séquentiel des feuilles est possible au moyen du pointeur de chaînage latéral. Variantes du B arbre Deux variantes existent pour le B arbre : B + arbre : il correspond au B arbre classique avec des pointeurs aux tuples placés uniquement dans les feuilles et un remplissage des cellules qui ne dépasse pas la moitié de leur capacité. B* arbre : il est identique au B + arbre, mais avec la garantie dʹun remplissage de chaque cellule ne dépassant pas les deux tiers de sa capacité. Le nombre de réorganisations des cellules peut devenir important, surtout à lʹapproche de la saturation des feuilles de lʹarbre. Dans la pratique, lorsque cet état est atteint au cours d une mise à jour, les procédures de gestion de l arbre amorcent immédiatement sa réorganisation en divisant le contenu de la cellule saturée en deux parties et en réallouant l espace pour une ou plusieurs nouvelles cellules du B arbre. L effort de rééquilibrage est consenti au fur et à mesure, par quanta répartis, afin d éviter l accaparement du noyau du SGBD aux temps d une demande forte et durant lesquelles le travail de réajustement ralentirait les opérations dans la base de données. Mécanisme de verrouillage des tuples Normalement, un utilisateur du système Oracle exploitant directement les données par lʹentremise de SQL*Plus, soit par une application n a pas à se soucier du verrouillage des données. La gestion des verrous est automatique et assumée par le SGBD du serveur. Un premier utilisateur qui accède à une table acquiert aussi un verrou dʹexclusivité TX (ou plus simplement X) sur chaque tuple modifié ou inséré et un verrou RX sur la table. Le verrou RX (RS en premier se transformant en RX) sur une table autorise la transaction à faire dʹautres actions sur les tuples de la table qui ne sont pas encore verrouillés par une

20 20 autre transaction. À la fin de la mise à jour marquée par un COMMIT transactionnel, les verrous sont automatiquement libérés par le moteur dʹoracle. Le système pose un verrou au niveau des tuples, sauf si une application le demande explicitement par la commande explicite LOCK TABLE. Le verrou contrôle alors toute la table. L atomicité de chaque ordre SQL est assurée par le SGBD en ce sens quʹun ordre est complété ou en cas d erreur, défait entièrement, et cela, sans intervention directe de lʹapplication. 7.4 Association des espaces de table avec les fichiers physiques Les espaces de table nommés tablespaces (TS) sont associés à des fichiers physiques dʹun OS lors de leur création par le DBA. Les tables et les index sont créés et associés explicitement à un TS particulier par une commande particulière utilisée seulement par le DBA. CREATE TABLESPACE ESPACE_USER3 --commande pour le DBA DATAFILE '/usr/users/fichier1.dbf' SIZE 25M DEFAULT STORAGE INITIAL 50K NEXT 30K PCTINCREASE 0 MINEXTNENTS 1 MAXEXTENTS 100 ONLINE; Une table peut être rangée explicitement dans ce tablespace déjà créé par la commande DDL suivante : CREATE TABLE Usines( no number(2) constraint cp_usines primary key, libelle varchar2(45), ville varchar2(60), capacite number, -- par défaut un entier de précision 32 classe char(1)) TABLESPACE ESPACE_USER3; Lʹespace de table est nommé et son espace maximal spécifié dans une commande antérieure est de 50 Mo. Toutefois, lʹespace initial est de 50K et augmente, selon les besoins, par quanta de 30 Ko. Toute table stockée dans cet espace de table aura les caractéristiques de stockage par défaut. Normalement, lʹespace de table est créé par le DBA et non par les développeurs. La création d une table se fit dans un espace prédéfini par le DBA et alloué au compte Oracle par défaut. N.B. Si lʹespace de table nʹest pas fourni dans la commande CREATE TABLE ou prédéfini par défaut, les objets sont rangés dans lʹespace de table SYSTEM. Les segments ROLLBACK et les INDEX sont aussi créés explicitement par le DBA : CREATE INDEX Usines_nom_idx On Usine(nom); CREATE [PUBLIC] ROLLBACK SEGMENT segt25 TABLESPACE TS_table10; La création d un segment temporaire est effectuée automatiquement par le SGBD lors de son installation. Rappelons aussi que les segments de rollback sont nécessaires pour