Upload
builiem
View
222
Download
0
Embed Size (px)
Citation preview
HAKIM BENAMEURLAINE
ACCÈS À UNE TABLE PAR
L'UTILISATION DE PLUSIEURS INDEX
Mémoire
présenté
à la faculté des études supérieures
de l’Université Laval
pour l’obtention
du grade de maître ès sciences (M.Sc.)
Département d’informatique
FACULTÉ DES SCIENCES ET DE GÉNIE
UNIVERSITÉ LAVAL
FÉVRIER 1996
Hakim Benameurlaine, 1996
RÉSUMÉ
La technique des index multiples implantée sur des ordinateurs à architecture
parallèle, et couplée à un partitionnement et à un placement judicieux des données,
semble constituer une solution candidate intéressante et prometteuse pour l'optimisation
des requêtes à une base de données.
L'idée repose sur le constat que toute requête peut être avantageusement et
judicieusement décomposée en plusieurs sous-requêtes indépendantes qui peuvent
s'exécuter en parallèle. Ce mémoire présente les différents algorithmes d’indexation
multiple pour l'accès à une base de données en les comparant à des algorithmes
conventionnels de recherche séquentielle.
Nadir Belkhiter Hakim Benameurlaine
Directeur de recherche Étudiant gradué
ii
REMERCIEMENTS
Je voudrais tout d'abord exprimer ma plus profonde gratitude à mon directeur de
recherche, monsieur Nadir Belkhiter, professeur au département d'informatique de
l'Université Laval, pour la qualité de son encadrement. Il m'a prodigué de nombreux
conseils judicieux pour la réalisation de ce projet. Je lui suis des plus reconnaissants pour
sa patience, sa confiance ainsi que pour ses qualités humaines et professionnelles.
Mes remerciements s'adressent également à tous les membres du personnel du
département d'informatique de l'Université Laval pour leur aimable et appréciable
collaboration.
Je voudrais aussi remercier tous mes amis ainsi que mes camarades pour leurs
encouragements et leur support continuels tout au long de ce travail.
Merci également à mon épouse pour sa patience durant mes recherches et mon travail de
rédaction pendant les soirées et les fins de semaine.
Finalement, je ne saurais terminer cet avant-propos sans rendre un grand hommage à mes
parents pour tous leurs efforts et sacrifices qui ont fait de moi ce que je suis aujourd’hui.
Qu’ils acceptent en guise de reconnaissance la dédicace de ce modeste travail.
iii
TABLE DES MATIÈRES
REMERCIEMENTS.................................................................................................................................. III
LISTE DES FIGURES..............................................................................................................................VII
LISTE DES TABLEAUX ....................................................................................................................... VIII
INTRODUCTION.........................................................................................................................................1
1. TERMINOLOGIE ET DÉFINITIONS ..................................................................................................8
1.1 REQUÊTE .......................................................................................................................................8
1.2 PRÉDICAT ......................................................................................................................................8
1.3 RID ................................................................................................................................................10
1.4 INDEX ...........................................................................................................................................11
1.4.1 CHOIX DES ATTRIBUTS À INDEXER.............................................................................................. 12
1.4.2 CHOIX DES ATTRIBUTS D'UN INDEX COMPOSÉ......................................................................... 16
1.5 FONCTION DE HASHING ...........................................................................................................17
1.5.1 COLLISION........................................................................................................................................... 19
1.6 TÂCHES DE L'OPTIMISEUR.......................................................................................................20
1.7 JOINTURE.....................................................................................................................................20
1.8 GROUPEMENT(CLUSTERING) ..................................................................................................21
1.8.1 TABLES CANDIDATES AU GROUPEMENT.................................................................................... 24
1.8.2 INDEX DE GROUPEMENT VERSUS INDEX DE TABLE................................................................ 26
1.9 CHEMINS D'ACCÈS AUX DONNÉES .........................................................................................26
1.10 INDEX ÉLIGIBLE .......................................................................................................................29
1.11 SÉLECTIVITÉ D'UN PRÉDICAT ...............................................................................................29
1.11.1 MÉTHODE DE CALCUL DE LA SÉLECTIVITÉ............................................................................. 31
1.12 SÉLECTIVITÉ D'UN INDEX ......................................................................................................32
1.13 TRANSACTION ...........................................................................................................................33
1.14 GRANULARITÉ...........................................................................................................................33
2. TRAITEMENT DES REQUÊTES.......................................................................................................34
2.1 CAS DES PRÉDICATS CONJONCTIFS.......................................................................................34
2.1.1 INTERSECTION DES INDEX ............................................................................................................. 34
2.1.1.1 EXEMPLE..................................................................................................................................... 34
2.1.2 PHASE D'OPTIMISATION .................................................................................................................. 37
2.1.3 PHASE D'EXÉCUTION........................................................................................................................ 40
2.1.3.1 EXEMPLE (avec des prédicats conjonctifs) .................................................................................. 41
2.1.3.2 EXEMPLE (avec des prédicats conjonctifs et disjonctifs)............................................................. 43
2.1.4 ÉVALUATION D'UNE NÉGATION.................................................................................................... 45
iv
2.1.4.1 EXEMPLE..................................................................................................................................... 45
2.2 CAS DES PRÉDICATS DISJONCTIFS.........................................................................................46
2.2.1 UNION DES INDEX ............................................................................................................................. 46
2.2.2 PHASE D'OPTIMISATION .................................................................................................................. 48
2.2.3 PHASE D'EXÉCUTION........................................................................................................................ 49
2.2.3.1 EXEMPLE..................................................................................................................................... 50
3. TECHNIQUES D’IMPLANTATION..................................................................................................52
3.1 BALAYAGE SÉQUENTIEL AVEC UTILISATION DE LISTES ....................................................52
3.1.1 EXEMPLE ............................................................................................................................................. 53
3.2 ACCÈS AUX DONNÉES ...............................................................................................................54
3.3 VECTEURS DE BITS ....................................................................................................................55
3.3.1 EXEMPLE ............................................................................................................................................. 56
3.4 GESTION DES ACCÈS CONCURRENTS ....................................................................................57
3.4.1 VERROUILLAGE PARTIEL (CURSOR STABILITE) ....................................................................... 57
3.4.2 VERROUILLAGE TOTAL (REPEATABLE READ) .......................................................................... 58
3.4.2.1 PRÉDICAT DISJONCTIF............................................................................................................. 58
3.4.2.2 PRÉDICAT CONJONCTIF........................................................................................................... 58
3.4.2.2.1 EXEMPLE............................................................................................................................. 59
3.5 APPORTS DU PARALLÉLISME...................................................................................................59
4. ENVIRONNEMENT D’EXPÉRIMENTATION.................................................................................61
4.1 LES T800 ET LA MACHINE VOLVOX .........................................................................................61
4.2 PROCESSUS .................................................................................................................................63
4.3 LANGAGE DE CONFIGURATION INMOS .................................................................................64
4.4 LE LANGAGE INMOS C...............................................................................................................69
5. RÉSULTATS EXPÉRIMENTAUX ET ANALYSE ...........................................................................70
5.1 APPROCHE EXPÉRIMENTALE MULTI-INDEXATION.............................................................70
5.1.1 TOPOLOGIE ......................................................................................................................................... 71
5.1.2 RÉSULTATS ......................................................................................................................................... 73
5.2 BALAYAGE SÉQUENTIEL DE LA TABLE DE DONNÉES .........................................................76
5.2.1 DESCRIPTION...................................................................................................................................... 76
5.2.2 TOPOLOGIE ......................................................................................................................................... 76
5.2.3 RÉSULTATS ......................................................................................................................................... 77
5.3 ANALYSE DE L’EFFICACITÉ DES ALGORITHMES .................................................................82
5.3.1 DESCRIPTION...................................................................................................................................... 82
5.3.2 BALAYAGE SÉQUENTIEL................................................................................................................. 83
5.3.3 MULTI-INDEXATION ......................................................................................................................... 85
5.3.3.1 CAS MOYEN ................................................................................................................................ 86
5.3.3.2 PIRE DES CAS.............................................................................................................................. 88
5.4 SYNTHÈSE DE LA RÉALISATION ...............................................................................................89
v
CONCLUSION............................................................................................................................................91
BIBLIOGRAPHIE......................................................................................................................................92
vi
LISTE DES FIGURES
FIGURE 1-1 MODÈLE HIÉRARCHIQUE ................................................................................................................2
FIGURE 1-2 MODÈLE RÉSEAU ...........................................................................................................................2
FIGURE 1-3 MODÈLE RELATIONNEL..................................................................................................................4
FIGURE 4-1 LE T800 ET SES QUATRE LIENS....................................................................................................62
FIGURE 4-2 TOPOLOGIE EN MATRICE 8X8 ......................................................................................................65
FIGURE 4-3 TOPOLOGIE EN ANNEAU ..............................................................................................................66
FIGURE 4-4 TOPOLOGIE EN HYPERCUBE.........................................................................................................67
FIGURE 4-5 TOPOLOGIE DRAGON-NET ..........................................................................................................68
FIGURE 5-1 TOPOLOGIE UTILISÉE...................................................................................................................72
FIGURE 5-2 REPRÉSENTATION GRAPHIQUE DES RÉSULTATS (MULTI-INDEXATION).........................................74
FIGURE 5-3 GAIN DU PARALLÉLISME DANS LE CAS DE LA MULTI-INDEXATION...............................................75
FIGURE 5-4 REPRÉSENTATION GRAPHIQUE DES RÉSULTATS (BALAYAGE SÉQUENTIEL) ..................................78
FIGURE 5-5 GAIN DU PARALLÉLISME DANS LE CAS DU BALAYAGE SÉQUENTIEL.............................................79
FIGURE 5-6 COMPARAISON GRAPHIQUE DES RÉSULTATS................................................................................80
FIGURE 5-7 GAIN DE LA MULTI-INDEXATION .................................................................................................81
FIGURE 5-8 ARBORESCENCE DES PROCESSUS.................................................................................................90
vii
LISTE DES TABLEAUX
TABLEAU 1-1 EXEMPLE D’UTILISATION DES INDEX........................................................................................17
TABLEAU 1-2 TABLE ETUDIANT.................................................................................................................22
TABLEAU 1-3 INDEX DE GROUPEMENT DE LA TABLE ETUDIANT.................................................................22
TABLEAU 1-4 BLOCS DE LA TABLE ETUDIANT............................................................................................23
TABLEAU 1-5 TABLE EMPLOYE ..................................................................................................................30
TABLEAU 1-6 RÉSULTAT DU PRÉDICAT SUR LA TABLE EMPLOYE ...............................................................30
TABLEAU 2-1 INDEX DÉFINI SUR L’ATTRIBUT AGE ........................................................................................35
TABLEAU 2-2 INDEX DÉFINI SUR L’ATTRIBUT SERVICE..................................................................................35
TABLEAU 3-1 EXEMPLE DE BALAYAGE SÉQUENTIEL AVEC UTILISATION DE LISTES........................................54
TABLEAU 5-1 RÉSULTATS OBTENUS AVEC L’APPROCHE DE LA MULTI-INDEXATION.......................................73
TABLEAU 5-2 RÉSULTATS OBTENUS AVEC L’APPROCHE DU BALAYAGE SÉQUENTIEL.....................................77
TABLEAU 5-3 DESCRIPTION DES PROCESSUS..................................................................................................89
viii
INTRODUCTION
De nos jours, la majorité des ordinateurs reposent sur l'architecture de Von Neumann.
Cette architecture est caractérisée par un fonctionnement purement séquentiel, c’est-à-
dire qu'à un instant donné, une seule instruction est exécutée sur une seule donnée
(Single Instruction Single Data) [Flynn 1966]. Toutefois, à notre époque, les applications
informatiques consomment de plus en plus de temps de calcul et exigent des traitements
de plus en plus rapides. À cet égard, on se doit de trouver de nouvelles avenues.
Le parallélisme est une alternative qui satisfait la demande toujours croissante en
puissance de calcul. À travers la duplication d'éléments de calcul, les programmes
peuvent être exécutés sur plusieurs transputers et peuvent accéder à plusieurs plages de
mémoire simultanément. En d'autres termes, le calcul est effectué en parallèle. Bien que
le parallélisme ne soit pas un concept nouveau, il s'avère toujours difficile de le mettre en
oeuvre.
L’introduction du parallélisme dans le domaine des bases de données semble susciter un
certain intérêt depuis l’apparition des ordinateurs à architecture parallèle. En effet,
plusieurs SGBD sont déjà dotés d’une option parallèle qui permet l’exécution en
parallèle des opérations de manipulation de données. Citons comme exemple le SGBD
Oracle [Oracle 1992a].
Une base de données peut être définie comme étant un ensemble intégré de données
modélisant un univers donné. La définition et la manipulation des données sont assurées
par un Système de Gestion de Base de Données (SGBD). Le langage de définition de
données (DDL) permet de créer, modifier et supprimer des objets dans la base de
données (table, index, contrainte) alors que le langage de manipulation de données
(DML) permet de mettre à jour et d’interroger les données. Citons comme exemple SQL
[Limane 1989] qui est un langage de définition et de manipulation de données (DDL et
DML).
On distingue les 4 types de SGBD suivants [Hogan 1990] :
- hiérarchique : le modèle d’un SGBD hiérarchique a la même apparence qu’un
diagramme organisationnel dans lequel chaque noeud représente un enregistrement
particulier. La structure utilisée est un arbre inversé, c’est-à-dire que chaque noeud est
relié à un seul père (sauf la racine) et peut avoir un ou plusieurs fils (descendants)
comme illustré à la Figure 1-1. La racine (root) est un noeud particulier qui n’a pas de
père.
Figure 1-1 modèle hiérarchique
- réseau : ressemble au modèle hiérarchique avec la différence majeure qu’un noeud peut
avoir plusieurs pères comme illustré à la Figure 1-2. (exemples de SGBD réseaux: IDS
II, VAX-DBMS, IDMS).
Figure 1-2 modèle réseau
2
3
- relationnel : dans un SGBD relationnel, les données se présentent sous la forme d'un
ensemble de relations ou tables d'où le nom de ce modèle (exemple de SGBD relationnel
: Oracle). La figure suivante illustre ce modèle:
Figure 1-3 modèle relationnel
- orienté objets : un SGBD orienté objets est composé d’objets élémentaires (atomiques)
lesquels sont agrégés ou composés récursivement, à un niveau plus concret, d’autres
objets dits structurés. Par exemple les cinq objets élémentaires suivants : ‘48’,
‘Boulevard Laurier’, ‘Sainte-Foy’, ‘Québec’, ‘G1X 3D4’ peuvent être regroupés pour
composer l’objet structuré suivant : ‘48 Boulevard Laurier Sainte-Foy Québec G1X
3D4’. Pour chaque objet élémentaire ou structuré, les opérations implicites permises sont
limitées par la nature même de l’objet (exemple de SGBD orienté objets : O2).
L'utilisateur manipule la base de données en adressant une requête au SGBD. Pour
répondre à cette requête, le SGBD procède en 2 phases:
1) Phase d'optimisation: Le SGBD optimise la requête en établissant une stratégie
d'exécution qui consiste à trouver un chemin d’accès aux données recherchées par
l’utilisateur. En général, le SGBD estime le coût de chaque chemin d’accès et choisit
celui qui présente le coût le moins élevé.
2) Phase d'exécution: Le SGBD exécute la requête selon la stratégie qui a été
préalablement établie à la phase d’optimisation et retourne le résultat à l’utilisateur.
4
Le but de ce travail est de déterminer la pertinence d'utiliser simultanément plusieurs
index (multi-indexation) pour établir une stratégie d'exécution de la requête. La
motivation qui a amené les concepteurs de bases de données à s'intéresser à la multi-
indexation comme technique d’accès est d'une part la possibilité d'exploiter les index
pour établir une stratégie d'exécution de la requête et d'autre part l'utilisation des index
pour l'accès aux données sur mémoire secondaire.
La technique de multi-indexation peut dans certains cas s’avérer très bénéfique et en
particulier dans le contexte d'un système à architecture parallèle. Ce travail soulève les
problèmes posés par cette technique pour lesquels nous présentons quelques solutions
possibles d’implantation.
Les solutions présentées sont adaptables (dynamiques) dans le sens où les stratégies
d'exécution établies à la phase d’optimisation peuvent être modifiées à la phase
d'exécution s'il s'avère que les hypothèses faites à la phase d'optimisation ne sont pas
vérifiées. Les opportunités d'exploiter le parallélisme sont également présentées.
Plusieurs systèmes utilisent la multi-indexation [Benameurlaine 1995], [Neil 1987],
[Neil 1989] mais très peu de travaux concernant l'optimisation, l'exécution et les accès
concurrents ont été publiés [Blasgen & Eswaran 1976], [Blasgen & Eswaran 1977],
[Rosenthal & Reiner 1982].
Commençons tout d’abord par illustrer la notion de multi-indexation. Considérons, pour
ce faire, la table EMPLOYE définie sur les attributs (Nas, Nom, Prénom, Age, Service,
Sexe), et supposons que l’on veuille rechercher tous les employés qui sont éligibles pour
la retraite, c’est-à-dire tous les employés âgés de plus de 65 ans ou ayant plus de 30 ans
de service. Cette requête serait formulée comme suit en langage SQL:
SELECT Nom
FROM EMPLOYE
WHERE Age>65 OR Service>30;
5
Si le SGBD ne permet pas l'utilisation de plusieurs index et qu'un index composé des
attributs Age et Service n'existe pas, alors le seul moyen possible pour répondre à la
requête est de parcourir toute la table EMPLOYE en testant le prédicat sur chaque tuple.
Ce type d’accès peut s’avérer très pénalisant surtout si la table est volumineuse, ce qui
est généralement le cas.
Par contre si deux index existent, l'un sur l'attribut Age et l'autre sur l'attribut Service,
alors il est possible d'utiliser le premier index pour trouver tous les employés de plus de
65 ans (Age>65) et le second index pour trouver tous les employés qui ont plus de 30 ans
de service (Service>30). Le résultat final sera alors l'union des deux résultats partiels.
Malgré l’apparente simplicité qui se dégage de l’exemple d’illustration qui précède, la
multi-indexation ne possède pas que des avantages. Parmi ses principaux inconvénients,
nous pouvons citer les suivants:
1. Un index est une structure indépendante des données et par conséquent lors de la
mise à jour des données il faut mettre à jour cette structure. L'utilisation de
plusieurs index implique donc des mises à jour fréquentes des structures d'index.
2. Sur une machine classique, même si plusieurs index existent, un seul peut être
exploité à la fois.
3. Pour une requête donnée se pose le problème du choix des index à utiliser.
4. Il est impossible de connaître à priori les champs de la base de données à indexer.
L'idéal serait de définir un index sur chaque champ de la base de données mais ceci
impliquerait un gaspillage énorme de la mémoire en plus de la dégradation des
performances du système (temps CPU) due aux mises à jour fréquentes des
structures d'index.
5. Si dans le prédicat de la requête, une fonction est appliquée sur un attribut indexé
alors l’index défini sur cet attribut est automatiquement éliminé comme index
éligible.
6
La solution serait de trouver un compromis acceptable entre le nombre d'index et les
performances du système c’est-à-dire de choisir un nombre d'index qui maintiendrait un
niveau de performance acceptable.
Le premier chapitre présente les principaux termes et concepts utilisés dans le domaine
des bases de données. Ces notions sont exploitées dans les chapitres suivants pour
caractériser les différentes approches présentées.
Le second chapitre traite des approches de multi-indexation et du balayage séquentiel. Le
traitement d’une requête donnée est déterminé par la nature du prédicat de la requête et
par les index définis sur les attributs de la requête.
Le chapitre suivant discute des différentes techniques d’implantation. Plus
particulièrement, nous présentons deux techniques basées sur l’utilisation des listes et des
vecteurs de bits. À cet égard, il est question aussi de l’accès aux données et de la gestion
des accès concurrents. L’apport du parallélisme est également abordé.
Le chapitre quatre expose l’environnement d’expérimentation. La plate forme utilisée est
une machine parallèle VOLVOX avec un maximum de 64 transputers.
Le chapitre cinq présente les résultats expérimentaux des deux approches (multi-
indexation et balayage séquentiel). Une analyse détaillée de l’efficacité des algorithmes y
est également présentée.
Pour conclure, nous décrivons les principales limites imposées par la multi-indexation
avant d’énoncer quelques avenues de recherche possibles en guise de perspectives de ce
travail.
7
Chapitre 1
1. TERMINOLOGIE ET DÉFINITIONS
1.1 REQUÊTE
L'utilisateur d'une base de données spécifie les données qu'il désire retrouver à travers
une requête adressée au SGBD. Cette requête est généralement formulée dans un langage
d'interrogation de haut niveau tel que SQL [Oracle 1992c]. Ce langage d'interrogation
joue le rôle d'interface entre l'utilisateur et la base de données. L'optimiseur qui est une
composante du SGBD détermine une stratégie d'exécution de la requête.
1.2 PRÉDICAT
La requête adressée au SGBD doit comporter un prédicat pour identifier les tuples à
retrouver dans la (ou les) table(s). Tous les tuples de la table qui vérifient le prédicat sont
sélectionnés.
On peut spécifier plusieurs prédicats dans une requête en utilisant les opérateurs logiques
AND et OR. Les prédicats connectés par l'opérateur logique AND sont appelés prédicats
conjonctifs alors que ceux qui sont connectés par l'opérateur logique OR sont appelés
prédicats disjonctifs.
Formellement un prédicat peut être défini par la grammaire suivante:
prédicat → <prédicat simple> / <prédicat composé>
prédicat simple → <attribut> <OPR> < valeur > /
<attribut> <OPR> <attribut>
prédicat composé → (<prédicat composé> <OPB> <prédicat composé>) /
NOT (<prédicat composé>) /
<prédicat simple>
8
Avec
OPR : opérateur de comparaison ∈ { =, ≠, ≥,≤, <, > }
OPB : opérateur booléen ∈ { AND, OR }
Les prédicats conjonctifs et les prédicats disjonctifs sont définis par les deux énoncés
génériques suivants:
prédicat conjonctif → (p1) AND (p2) ... AND (pn)
prédicat disjonctif → (p1) OR (p2) ... OR (pn)
où pi est un prédicat pour i=1,...,n.
Exemple
Soit le prédicat suivant défini sur les attributs Age et Service :
(Age=20 OR Age=30) AND (Service=25 OR Service=35)
Ce prédicat conjonctif est lui-même composé des 2 prédicats disjonctifs p1 et p2
suivants:
p1: (Age=20 OR Age=30),
p2: (Service=25 OR Service=35).
Le prédicat p1 est lui même constitué des 2 prédicats simples suivants:
Age=20 et Age=30.
Le prédicat p2 est constitué des 2 prédicats simples suivants:
Service = 25 et Service=35.
9
1.3 RID
Dans une table de données, chaque tuple possède un identificateur unique appelé RID
(Record Identifier). Lors de l’insertion d’un nouveau tuple dans la table de données, le
SGBD lui associe un RID qui constitue une clé physique pour ce tuple. Par la suite lors
de l’accès aux données, le SGBD se sert de ce RID.
Par exemple, dans le SGBD Oracle le RID est appelé ROWID et il constitue un attribut
implicite de la table. Sa syntaxe est la suivante:
xxxxxxxx.yyyy.zzzz
où :
xxxxxxxx est le numéro du bloc physique
yyyy est le numéro séquentiel du tuple à l’intérieur du bloc
zzzz est le numéro du fichier.
La requête SQL suivante retourne les RID de tous les tuples de la table EMPLOYE :
SELECT ROWID, NAS
FROM EMPLOYE;
ROWID NAS
-------------------------- ---------------
000003D7.0000.0007 272-234-567
000003D7.0001.0007 273-456-178
000003D7.0002.0007 272-234-569
000003D7.0003.0007 272-234-167
000003D7.0004.0007 272-229-534
000003D7.0005.0007 272-769-567
6 rows selected.
SQL>
10
Remarque Dans tout ce qui suit, seul le numéro séquentiel du tuple dans le bloc sera utilisé dans les
exemples par souci de simplification des notations.
1.4 INDEX
Les index , à l'image de ceux que l'on retrouve couramment à la fin de la plupart des
ouvrages, permettent de localiser l'information recherchée plus rapidement. Ils sont
physiquement indépendants des données et peuvent ainsi être supprimés et recréés à tout
moment. Formellement, un index est une structure de données associée à une table de
données permettant d'accélérer la recherche des données. Associé à une table, un index
permet un accès direct aux tuples. Chaque entrée d'un index contient la valeur d'un
champ d'indexation et une liste de pointeurs sur tous les blocs contenant un tuple dont le
champ d'indexation possède cette valeur. Quelle que soit sa nature, tout index est trié, ce
qui en permet un parcours dichotomique pour la recherche d'une valeur de champ
d'indexation.
On distingue trois classes d'index : primaire, secondaire et de groupement.
1) Index primaire : index créé sur une table de données suivant les valeurs d'un champ
clé (clé primaire) qui constitue le champ d'indexation.
2) Index secondaire : index créé sur une table de données suivant les valeurs d’un
champ non clé qui constitue le champ d'indexation.
3) Index de groupement : index créé sur une table de données suivant les valeurs d'un
champ qui constitue le champ de groupement.
La technique d'accès la plus couramment utilisée dans les SGBD est l'accès basé sur
l’utilisation d’un index. Un index est généralement implanté en utilisant une variante du
B-arbre. Un B-arbre est un arbre de recherche permettant de localiser rapidement les
valeurs clés. L’utilisation des RID permet par la suite d’accéder directement aux blocs de
données.
11
1.4.1 CHOIX DES ATTRIBUTS À INDEXER
Avant d’indexer un attribut, on doit considérer les points suivants:
a)
b)
En général, si une requête retourne moins que 4% des tuples de la table (sélectivité
inférieure à 4%) alors il est souhaitable d'indexer les attributs appropriés du prédicat.
Les tuples sélectionnés par une requête sont en principe distribués de façon uniforme
sur les blocs de données alloués à la table. Cependant si les tuples sélectionnés sont
concentrés sur quelques blocs de données alors l'utilisation des index peut améliorer
les performances des requêtes dont la sélectivité est grande.
. . . . .
Bloc 0 Bloc 1 Bloc 2 Bloc 3 Bloc 99
Supposons que 100 blocs de données sont alloués à la table. Si les données
recherchées sont concentrées dans les blocs 1 et 2 alors l’utilisation des index peut
améliorer considérablement les performances. En effet si on utilise le balayage
séquentiel de la table, on doit accéder aux 100 blocs de données alors qu’en utilisant
les index, on accède à seulement 2 blocs de données.
c) Chaque bloc de données alloué à la table devrait en principe contenir un minimum de
tuples. Cependant si les blocs contiennent moins que ce minimum alors l'utilisation
des index peut améliorer les performances des requêtes dont la sélectivité est grande.
d) Indexer les attributs dont les valeurs sont distribuées uniformément sur la table de
données. On peut estimer le pourcentage de tuples ayant des valeurs distinctes pour
un attribut donné à l’aide de l’indice suivant:
12
indice (A) = TV
où : A est l’attribut dont on calcule l’indice
T est le nombre total de tuples
V est le nombre de valeurs distinctes de l’attribut A.
Dans ce qui suit, nous présentons une méthode utilisée par Oracle pour calculer cet
indice. Cette méthode est basée sur l’utilisation des deux tables système user_tables
et user_indexes. [Oracle 1992d]
SELECT num_rows/distinct_keys "Rapport tuples/valeurs de l'attribut Age"
FROM user_tables, user_indexes
WHERE user_tables.table_name='EMPLOYE' AND index_name=‘Index_Age';
Rapport tuples/valeurs de l'attribut Age
----------------------------------------------
1
Par exemple, il faut éviter d’indexer des attributs comme sexe qui possède seulement
deux valeurs distinctes. En effet chaque tuple de la table a une chance sur deux d’être
sélectionné donc l’utilisation d’un index dans ce cas précis n’apporte pas de gain
significatif au niveau des performances.
e) Éviter d'indexer un attribut qui est fréquemment modifié car ceci entraînerait la mise
à jour fréquente de l’index. Une astuce consiste à créer l’index après l’insertion des
données.
f) Indexer les clés étrangères (contraintes d'intégrité référentielle). Par exemple, si on
considère les deux tables DEPARTEMENT (No_dept, Nom_dept) et EMPLOYE 13
(No_emp, Nom_emp, No_dept) on peut alors définir une contrainte d’intégrité
référentielle de la table EMPLOYE vers la table DEPARTEMENT sur l’attribut
No_dept (clé étrangère). Il est préférable dans ce cas d’indexer l’attribut No_dept de
la table EMPLOYE car dans le cas où un département existant est modifié ou
supprimé dans la table DEPARTEMENT, le SGBD vérifie si ce département est
référencé dans la table EMPLOYE. Dans ce cas l’existence de l’index évite le
balayage complet de la table EMPLOYE
Un index est dit simple s’il est défini sur un seul attribut et composé s’il est défini sur
plusieurs attributs.
Un index est dit unique s’il est défini sur un attribut clé.
Un index composé présente les avantages suivants:
1) combiner plusieurs attributs dans un index permet d'augmenter le nombre de valeurs
distinctes pour cet index.
2) augmente les performances des requêtes qui sélectionnent les attributs composant
l'index, car il n'est pas nécessaire d'accéder à la table.
Par exemple si on considère la requête suivante:
SELECT x
FROM table
WHERE x>20
où x est un attribut indexé, le SGBD répond à la requête en effectuant un seul accès index
et n’a pas besoin d’accéder aux blocs alloués à la table de données car l’attribut
recherché dans la requête est un attribut indexé.
La commande suivante nous donne le plan d’exécution de la requête, c’est-à-dire la
méthode d’accès qui a été choisie par l’optimisieur:
14
SQL> EXPLAIN PLAN FOR
2 SELECT Age
3 FROM EMPLOYE
4 WHERE Age > 30;
Explained.
OPERATION OPTIONS OBJECT_NAME
------------------------------------- ------------------ --------------------
SELECT STATEMENT Cost =
INDEX RANGE SCAN INDEX_AGE
Par contre, si on considère la requête suivante:
SELECT y
FROM table
WHERE x>20
où y est un attribut non indexé, le SGBD utilise l’index pour retrouver tous les RID des
tuples qui satisfont le prédicat. À partir de ces RID, il accède aux tuples qui se trouvent
dans les blocs alloués à la table de données. En conclusion, cette requête a nécessité un
accès index et un accès aux données alors que la précédente n’a nécessité qu’un accès à
l’index.
15
Plan d’exécution :
SQL> EXPLAIN PLAN FOR
2 SELECT Nom
3 FROM EMPLOYE
4 WHERE Age = 30;
Explained.
OPERATION OPTIONS OBJECT_NAME
------------------------------------- -------------------- --------------------
SELECT STATEMENT Cost =
TABLE ACCESS BY ROWID EMPLOYE
INDEX RANGE SCAN INDEX_AGE
1.4.2 CHOIX DES ATTRIBUTS D'UN INDEX COMPOSÉ
Avant de créer un index composé, on doit considérer les deux points suivants et ceci afin
de réduire l’accès aux données sur disque :
1) Considérer les attributs qui sont souvent référencés ensemble dans les requêtes.
2) Considérer les attributs qui sont souvent sélectionnés ensemble dans les requêtes.
Remarque
Pour qu’un index soit utilisé dans le traitement d’une requête, il est nécessaire que
l’attribut sur lequel l’index est défini soit référencé dans la requête. De plus, aucune
fonction ne doit être définie sur cet attribut.
16
Exemple
Soient les attributs A1, A2, A3, A4 et les index I1, I2 définis sur les attributs A1 et A2
respectivement. On a alors:
Prédicat Index utilisés A4=30 aucun A2>40 I2 Log(A2)>40 aucun A1=30 OR A2<20 I1, I2 A4=29 AND A2=3 I2
Tableau 1-1 Exemple d’utilisation des index
1.5 FONCTION DE HASHING
Le hashing est une méthode optionnelle pour stocker les tables de données afin
d'améliorer les performances lors de l'accès à ces données. À chaque clé logique est
associée une adresse physique (pointeur vers un bloc). Une fonction souvent utilisée est
la division entière telle que définie par la fonction h de l’exemple suivant :
h(Age) = Age mod M = pointeur vers un bloc physique
qui retourne le reste de la division de Age par M.
• La fonction de hashing peut être appliquée sur un ou plusieurs attributs.
• Les tuples sont stockés suivant la valeur de la fonction de hashing.
• Cette approche permet de réduire le nombre d'entrées/sorties sur disque lors de l'accès
aux blocs de données. Elle est utilisée si l’objectif visé est la performance. Cependant
si on adopte cette approche, on doit tenir compte des restrictions suivantes:
• L'espace pour stocker la table est pré-alloué (allocation statique).
• Dans le prédicat de la requête, on ne doit retrouver que des conditions d’égalité
sur les attributs sur lesquels la fonction de hashing est définie.
17
• La table doit appartenir à un groupement (cluster).
• Au début, un seul bloc est alloué à une ou plusieurs valeurs de la clé logique; dès qu'il
est rempli, il est alors chaîné à un bloc de débordement.
• L’utilisation d’une fonction de hashing permet une distribution maximum des tuples
sur les valeurs de la clé logique.
• Une bonne fonction de Hashing doit minimiser le nombre de collisions.
Exemple
SELECT Nom
FROM EMPLOYE
WHERE Service = 7;
fonction de hashing : h(7) = 7 mod 3
h(7)= 7 mod 3 = 1
les tuples recherchés se trouvent dans le bloc 1.
clé de hashing
clé de groupement
(Service)
tuples
0 0 3 6
.
.
. 1 1
4 7
.
.
. 2 2
5 8
.
.
. L’utilisation du hashing comme chemin d’accès aux données nécessite un seul accès
bloc.
18
1.5.1 COLLISION
Une collision se produit lorsque une valeur de clé correspondant à un nouveau tuple à
insérer donne après hashing une valeur d’adresse (pointeur de bloc) déjà occupée par une
autre valeur de clé. C’est-à-dire si:
h( valeur1 ) = h( valeur2 )
Le but d’une fonction de hashing est d’aboutir à une distribution uniforme des tuples
d’une table sur les blocs alloués à cette table de afin de à minimiser le risque de collision.
Si les collisions sont fréquentes, il se peut que les blocs correspondant aux valeurs clé
deviennent saturés. Dans ce cas, le SGBD crée des blocs de débordement qui sont
chaînés aux blocs saturés. Ceci implique évidemment une augmentation du nombre
d’entrées/sorties sur disque donc une baisse de la performance.
Par exemple, si on insère un nouveau tuple qui a la clé 2 ou la clé 4, il est
automatiquement chaîné au bloc de débordement.
entête clé 0
clé 1
bloc 0 pour les valeurs 0, 1
entête entête clé 2 clé 2
clé 3 clé 4
bloc 1 pour les valeurs 2, 3 bloc de débordement
entête clé 4
clé 5
bloc 2 pour les valeurs 4,5
19
1.6 TÂCHES DE L'OPTIMISEUR
Les principales tâches de l’optimiseur des requêtes sont les suivantes:
1. évaluer les expressions et les conditions.
2. transformer les instructions en instructions équivalentes qui sont plus rapides à
exécuter.
3. choisir le chemin d'accès aux données.
4. établir une stratégie pour exécuter les jointures (lorsqu’il y a plusieurs tables).
Lorsqu’il existe plusieurs stratégies possibles, il choisit la plus efficace.
1.7 JOINTURE
L’opération de jointure consiste à mettre en relation deux ou plusieurs tables suivant un
attribut commun. Il existe trois façons différentes pour exécuter une opération de jointure
qui sont les suivantes: boucle imbriquée, tri-fusion et groupement.
1) boucle imbriquée : pour chaque tuple de la table, le SGBD recherche tous les
tuples des autres tables qui satisfont la condition de jointure.
a) l'optimiseur choisit une des tables comme table interne. Les autres tables
sont appelées tables externes.
b) pour chaque tuple dans la table externe, rechercher tous les tuples de la
table interne qui satisfont la condition de jointure.
c) combiner les données de chaque paire de tuples qui satisfont la condition
de jointure et retourner les tuples résultats.
2) tri-fusion : fusionner les tuples triés de chaque table. La jointure basée sur le tri-
fusion est appliquée seulement si la condition de jointure est une égalité.
20
a) trier chaque ensemble de tuples sur lesquels la jointure s'appliquera. Les
tuples sont triés sur les attributs utilisés dans la condition de jointure.
b) fusionner les deux ensembles de tuples et retourner le résultat. Si les tuples
sont déjà triés, il n'est pas nécessaire de les trier de nouveau.
3) jointure de groupement : jointure basée sur une boucle imbriquée dans laquelle les
attributs clé du groupement sont comparés à la condition de jointure.
a) choisir une des tables comme table externe. Les autres tables deviennent
des tables internes.
b) pour chaque tuple dans la table externe, rechercher tous les tuples de la
table interne qui satisfont la condition de jointure. Les tuples
correspondant dans la table interne sont stockés dans le même bloc de
données.
c) retourner le résultat.
1.8 GROUPEMENT(CLUSTERING)
L'opération de groupement (clustering) a pour objectif de rapprocher physiquement des
données qui sont logiquement souvent accédées ensemble. Il s’agit de sous-ensembles de
tuples qui partagent la même valeur d’un attribut donné (appelé champ de groupement).
Ceci présente les avantages suivants:
• Réduire le temps d'accès car les données sont physiquement rapprochées.
• Réduire l'espace de stockage car les données communes à plusieurs tables sont
stockées une seule fois.
21
Exemple
Soit la table ETUDIANT ci-dessous définie sur les attributs (Section, Nom, Prénom,
Matricule).
Section Nom Prénom Matricule A Gauvin Lucien 7805623 A Carrier Juliette 5724904 A Arcand Yves 9823423 B Marceau Richard 8989433 B Amand Michel 9842367 C Collin Marie 6755345 C Cannon Charles 8965654 C Auclair Éric 5456775 C Aubin Adrien 7677675 C Allard Mario 9665634 D Belleau Nicole 8786755 D Berger Vézina 7675554 D Benoît Alain 4345768 D Bernardin Marie 6567443 D Déry Charles 6568796 D Furois Jean 6568796
Tableau 1-2 Table ETUDIANT
Un index de groupement peut être défini sur l'attribut Section car plusieurs étudiants
peuvent se trouver dans la même section. L’attribut Section est appelé champ de
groupement.
L'index et la table de données sont alors représentés comme suit:
Valeur du champ de groupement Pointeur de bloc A 0 B 0 C 1 D 2
Tableau 1-3 Index de groupement de la table ETUDIANT
22
TABLE DE DONNÉES (en supposant un facteur de blocage de 4):
Bloc section Nom Prénom Matricule 0 A Gauvin Lucien 7805623 0 A Carrier Juliette 5724904 0 A Arcand Yves 9823423 0 B Marceau Richard 8989433 1 B Amand Michel 9842367 1 C Colin Marie 6755345 1 C Cannon Charles 8965654 1 C Auclair Éric 5456775 2 C Aubin Adrien 7677675 2 C Allard Mario 9665634 2 D Belleau Nicole 8786755 2 D Berger Vézina 7675554 3 D Benoît Alain 4345768 3 D Bernardin Marie 6567443 3 D Déry Charles 6568796 3 D Furois Jean 9554566
Tableau 1-4 Blocs de la table ETUDIANT
Les tables d'un même groupement possèdent des attributs en commun, sont souvent
utilisées ensemble et sont stockées dans les mêmes blocs de données.
la clé du groupement est définie sur un ou plusieurs attributs des tables qui appartiennent
à ce groupement et l'index de groupement est crée sur la clé du groupement.
Un groupement peut réduire :
• le nombre entrées/sorties sur disque lors de l'accès aux données.
• le temps des opérations de jointure entre les tables du groupement.
• l'espace nécessaire pour stocker les tables du groupement.
23
Remarques
1. Un groupement peut améliorer les performances des requêtes mais peut les réduire
lors des opérations de mise à jour (insertion, suppression, modification) et du balayage
complet de la table.
2. L'index de groupement stocke les tuples ayant les mêmes valeurs de clé de
groupement dans le même bloc de données.
3. Un balayage de l'index de groupement permet d'obtenir les RID des tuples
sélectionnés. Par la suite, en utilisant les RID, on accède aux données.
1.8.1 TABLES CANDIDATES AU GROUPEMENT
Les groupements sont utilisés pour accélérer l’accès aux données. Cependant ils doivent
être utilisés avec précaution car ils pourraient aussi dégrader les performances au lieu de
les améliorer. Les tables à mettre dans le groupement doivent être choisies de façon
judicieuse. Parmi ces tables on peut citer les suivantes:
• les tables qui servent pour la consultation et dont les clés de groupement sont rarement
modifiées.
• les tables liées par des contraintes d’intégrité référentielle. Par exemple, si on
considère les deux tables DEPARTEMENT (No_dept, Nom_dept) et EMPLOYE
(No_emp, Nom_emp, No_dept), on peut alors définir une contrainte d’intégrité
référentielle de la table EMPLOYE vers la table DEPARTEMENT sur l’attribut
No_dept (clé étrangère).
• les tables sur lesquelles des opérations de jointure sont fréquemment exécutées.
• Un index de groupement est utilisé pour accélérer la recherche des valeurs clés de
groupement. Il pointe directement sur le bloc de données de la valeur clé de
groupement correspondante.
• Il permet l'accès aux données avec un minimum de deux accès disque. 24
25
1.8.2 INDEX DE GROUPEMENT VERSUS INDEX DE TABLE
Un index de groupement se distingue d’un index ordinaire par les points suivants:
• Impossible d’accéder aux données dans le groupement sans l'index du groupement.
• l'index doit exister avant l'insertion des données.
Il faut éviter d’accéder aux données en utilisant le balayage séquentiel de la table s'il
existe:
• un index
• une fonction de hashing
• un index de groupement
1.9 CHEMINS D'ACCÈS AUX DONNÉES
Le SGBD retrouve physiquement les données en utilisant la stratégie d'accès choisie. Il
existe principalement quatre chemins d’accès aux données : l’utilisation des RID,
l’application d’une fonction de Hashing, l’utilisation d’index et le balayage séquentiel.
À titre d’illustration, nous allons présenter comment le SGBD Oracle gère ces stratégies
d’accès et comment il informe l’utilisateur sur demande par l’intermédiaire de la
commande EXPLAIN PLAN qui permet d’obtenir le plan d’exécution de la requête
considérée [Oracle 1992a].
Le résultat fourni par le SGBD en réponse à cette commande est indiqué en caractères
gras dans les exemples d’illustration ci-après.
Les différents chemins d’accès que les SGBD utilisent sont les suivants :
26
1) RID : Si le prédicat d'une requête est basé sur le RID, le SGBD utilise ce RID pour
accéder directement au tuple. C’est le chemin d’accès le moins coûteux car il
nécessite un seul accès bloc. Dans l’exemple ci-dessous, le SGBD utilise l’accès
par le ROWID de la table EMPLOYE (ligne "TABLE ACCESS BY ROWID
EMPLOYE").
Plan d’exécution :
SQL>EXPLAIN PLAN FOR
2 SELECT *
3 FROM EMPLOYE
4 WHERE ROWID='000003D7.0002.0007';
Explained.
OPERATION OPTIONS OBJECT_NAME
------------------------------------- -------------- --------------------
SELECT STATEMENT Cost =
TABLE ACCESS BY ROWID EMPLOYE
2) fonction de hashing : En utilisant la fonction de hashing, on peut accéder
directement au bloc de données dans lequel se trouvent les données recherchées.
Plan d’exécution :
SQL> EXPLAIN PLAN FOR
2 SELECT *
3 FROM EMPLOYE
4 WHERE Service = 30 OR Service = 40;
Explained.
OPERATION OPTIONS OBJECT_NAME
------------------------------------- -------------- --------------------
SELECT STATEMENT Cost =
TABLE ACCESS HASH EMPLOYE
27
3) index : En utilisant l’index approprié à la requête, on peut avoir les RID des tuples
recherchés. Un accès aux blocs de données est peut être nécessaire si les données
recherchées ne se trouvent pas dans l’index.
Plan d’exécution :
SQL> EXPLAIN PLAN FOR
2 SELECT *
3 FROM EMPLOYE
4 WHERE Age = 30;
Explained.
OPERATION OPTIONS OBJECT_NAME
------------------------------------- -------------------- --------------------
SELECT STATEMENT Cost =
TABLE ACCESS BY ROWID EMPLOYE
INDEX RANGE SCAN INDEX_AGE
4) balayage séquentiel de la table : Le SGBD effectue un balayage séquentiel
complet de la table si aucun autre chemin d’accès n’est disponible. C’est le chemin
d’accès le plus coûteux car on doit accéder à tous les blocs de la table.
Plan d’exécution :
SQL> EXPLAIN PLAN FOR
2 SELECT *
3 FROM EMPLOYE
4 WHERE Sexe='M';
Explained.
OPERATION OPTIONS OBJECT_NAME
------------------------------------- -------------- --------------------
SELECT STATEMENT Cost =
TABLE ACCESS FULL EMPLOYE
28
1.10 INDEX ÉLIGIBLE
Pour une requête donnée, un index est dit éligible si parmi les attributs qui le composent,
il existe au moins un attribut qui soit référencé dans le prédicat associé à la requête.
Plusieurs index éligibles peuvent exister pour un même prédicat mais un seul est utilisé à
la fois pour générer le résultat. Donc l'un des problèmes à résoudre est de déterminer
parmi tous les index éligibles celui qui sera utilisé.
Exemple
Soit la table EMPLOYE définie sur les attributs suivants: (Nas, Nom, Prénom, Age,
Service, Sexe) et soient les index suivants:
I1: défini sur l'attribut Service,
I2: défini sur les attributs Age et Service,
I3: défini sur l'attribut Nas,
I4: défini sur les attributs Age, Service et Sexe,
Dans cet exemple on constate que :
I1 est un index éligible pour le prédicat : Service<3,
I2 est un index éligible pour le prédicat : Age>20,
I4 est un index éligible pour les prédicats : Age>20, Service<3, Sexe=M.
Remarque
Un index peut être éligible pour plusieurs prédicats et un prédicat peut avoir plusieurs
index éligibles.
1.11 SÉLECTIVITÉ D'UN PRÉDICAT
On définit la sélectivité d'un prédicat comme étant le pourcentage de tuples qui satisfont
ce prédicat. Évaluer un prédicat revient à trouver sa sélectivité.
29
Exemple
Soit la table EMPLOYE de l'exemple précédent, un exemple d’occurrence de cette table
pourrait être le suivant:
RID Nas Nom Prénom Age Service Sexe 0000 272-234-567 Lebel Michel 29 8 M 0001 273-456-178 Caron Luc 55 15 M 0002 272-234-569 Fortin Alyne 50 25 F 0003 272-234-167 Bélanger Marc 34 5 M 0004 272-229-534 Poulin Pierre 49 28 F 0005 272-769-567 Wang Lynda 40 21 F
Tableau 1-5 Table EMPLOYE
On veut rechercher les employés dont l'âge est supérieur à 45 ans. Cette requête est
formulée comme suit en langage SQL. SELECT Nom
FROM EMPLOYE
WHERE Age>45;
Le prédicat associé à la requête est : Age>45. L'évaluation de ce prédicat pour chaque
tuple donne les résultats suivants:
RID Nas Nom Prénom Age Service Sexe Prédicat 0000 272-234-567 Lebel Michel 29 8 M Faux 0001 273-456-178 Caron Luc 55 15 M Vrai 0002 272-234-569 Fortin Alyne 50 25 F Vrai 0003 272-234-167 Bélanger Marc 34 5 M Faux 0004 272-229-534 Poulin Pierre 49 28 F Vrai 0005 272-769-567 Wang Lynda 40 21 F Faux
Tableau 1-6 Résultat du prédicat sur la table EMPLOYE
Sélectivité(Age>45)= 36
=50%. Ceci signifie que la moitié des tuples de la table
de données satisfont le prédicat de la requête.
30
1.11.1 MÉTHODE DE CALCUL DE LA SÉLECTIVITÉ
Dans ce qui suit, nous présentons une méthode employée par le SGBD Oracle pour
calculer la sélectivité d’un prédicat. Cette méthode est utilisée par la version 7 du SGBD
Oracle [Oracle 1992b].
Supposons que l’on désire calculer la sélectivité du prédicat de la requête suivante: SELECT Nom
FROM EMPLOYE
WHERE Age>40;
C’est-à-dire que l’on désire calculer le pourcentage de tuples qui satisfont le prédicat
Age>40. Pour calculer cette sélectivité, le SGBD procède en deux étapes.
Étape 1 : il détermine le nombre total de tuples de la table EMPLOYE en utilisant la
table système USER_TABLES.
SELECT table_name, num_rows
FROM user_tables
WHERE table_name='EMPLOYE’;
TABLE_NAME NUM_ROWS
------------------ ---------------
EMPLOYE 6
Étape 2 : il détermine le pourcentage de tuples retournés par la requête (sélectivité).
SELECT COUNT(*)/6 "Sélectivité"
FROM EMPLOYE
WHERE Age>40;
Sélectivité
-----------
.5
31
1.12 SÉLECTIVITÉ D'UN INDEX
La sélectivité d’un index est le pourcentage de prédicats simples qui peuvent être testés
par cet index (prédicats pour lesquels cet index est éligible).
Exemple
Considérons encore la même table EMPLOYE sur laquelle sont définis les index
suivants:
I1: défini sur l'attribut Service,
I2: défini sur les attributs Age et Service,
I3: défini sur l'attribut Nas,
I4: défini sur les attributs Age, Service et Sexe,
et la requête suivante:
Age>20 AND (Service<3 OR Sexe=M)
Le calcul de la sélectivité de chaque index se fait comme suit:
Prédicats simples: { Age>20, Service<3, Sexe=M }
Sélectivité(I1)= 13
⇒I1 éligible pour 33% des prédicats simples de la requête,
Sélectivité(I2)= 23
⇒ I2 éligible pour 67% des prédicats simples de la requête,
Sélectivité(I3)=0 ⇒ I3 éligible pour aucun des prédicats simples de la requête,
Sélectivité(I4)=1 ⇒ I4 éligible pour tous les prédicats simples de la requête.
32
1.13 TRANSACTION
Un SGBD veille à ce que tout ensemble d'opérations de mise à jour de la base de données
constituant une unité logique de traitement soit exécuté dans sa totalité ou pas du tout
(principe de tout ou rien). Cette unité logique de traitement est appelée transaction.
Une transaction peut donc être vue comme un ensemble d'instructions qui n'ont de
signification que si elles sont exécutées dans leur totalité. Ce concept permet de garantir
la cohérence et l'intégrité des données.
L'exécution des différentes transactions doit garder la base de données dans un état
cohérent. Pour assurer cette cohérence, il est nécessaire d'utiliser des mécanismes de
contrôle d'accès (verrous, sémaphores) lors de l'accès aux données.
Les verrous sont utilisés pour contrôler l'accès aux données qui sont partageables par
plusieurs utilisateurs afin de garantir la cohérence de ces données suite aux opérations de
mise à jour.
1.14 GRANULARITÉ
Le verrouillage peut être appliqué au niveau du tuple, du bloc de données, de la table de
données ou de toute la base de données. Ce niveau d'application du verrouillage est
appelé granularité.
Dans ce qui suit on suppose que la granularité est de niveau tuple, c’est-à-dire que le
verrouillage est appliqué au niveau des tuples.
33
Chapitre 2
2. TRAITEMENT DES REQUÊTES
Le traitement d’une requête est fonction de la nature du prédicat et des index définis sur
les attributs du prédicat de cette requête. L’existence d’un ou de plusieurs index induit la
possibilité de pouvoir utiliser l’approche de la multi-indexation [Mohan & al 1990].
Dans le cas contraire (absence d’index), l’approche du balayage séquentiel est la seule
alternative possible.
2.1 CAS DES PRÉDICATS CONJONCTIFS
2.1.1 INTERSECTION DES INDEX
Pour évaluer un prédicat composé de prédicats conjonctifs simples, on utilise une
technique appelée: "intersection des index". Cette technique peut se résumer en deux
étapes:
a) Pour chaque prédicat conjonctif simple, utiliser l'index éligible correspondant pour
générer la liste de RID qui satisfont le prédicat.
b) Faire l'intersection des différentes listes de RID trouvées précédemment. La liste
résultante contient les RID des tuples qui satisfont le prédicat. On utilise cette liste
pour accéder aux données sur mémoire secondaire.
2 EXEMPLE
Soit toujours la même table EMPLOYE et s
SELECT Nom
FROM EMPLOYE
WHERE Age>40 AND Service>20;
.1.1.1
oit la requête suivante:
34
Le prédicat associé à cette requête est composé des 2 prédicats conjonctifs simples :
Age>40 et Service>20.
Supposons que deux index index_age et index_service aient été définis respectivement
sur les attributs Age et Service.
Age RID 29 0000 34 0003 40 0005 49 0004 50 0002 55 0001
Tableau 2-1 Index défini sur l’attribut Age
Service RID 5 0003 8 0000 15 0001 21 0005 25 0002 28 0004
Tableau 2-2 Index défini sur l’attribut Service
Dès lors, on peut utiliser le premier index pour avoir la liste de RID qui vérifient la
première condition du prédicat (Age>40), ce qui donne: liste_Age>40={ 0001, 0002,
0004 },
et le deuxième index pour avoir la liste de RID qui vérifient la deuxième condition du
prédicat (Service>20), ce qui donne: liste_Service>20={ 0002, 0004, 0005 }.
Le résultat final sera l'intersection des deux résultats partiels, soit:
liste_résultat = liste_Age>40 ∩ liste_Service>20
={ 0001, 0002, 0004 } ∩ { 0002, 0004, 0005 }
={ 0002, 0004 }.
35
Pour obtenir la réponse à la requête, on accède aux données sur mémoire secondaire en
utilisant la liste de RID finale, ce qui donne les noms suivants: { Fortin , Poulin }.
Le chemin d’accès aux données est le suivant:
SQL> EXPLAIN PLAN FOR
2 SELECT *
3 FROM EMPLOYE
4 WHERE Age > 40 AND Service > 20;
Explained.
OPERATION OPTIONS OBJECT_NAME
------------------------------------- ------------------ --------------------
SELECT STATEMENT Cost =
TABLE ACCESS BY ROWID EMPLOYE
AND-EQUAL
INDEX RANGE SCAN INDEX_AGE
INDEX RANGE SCAN INDEX_SERVICE
Tel que mentionné précédemment, on utilise la technique de l'intersection des index pour
évaluer un prédicat composé de prédicats conjonctifs. Pour ce faire, le SGBD procède en
deux phases:
a)
b)
Phase d'optimisation.
Phase d'exécution.
La technique de l'intersection des index réduit de façon significative le nombre
d'entrées/sorties sur mémoire secondaire ainsi que le temps CPU pour les raisons
suivantes:
a) L'index est plus petit que la table de données, par conséquent l'utilisation d'un index
éligible pour générer la liste de RID nécessite moins d'entrées/sorties sur mémoire
secondaire et moins de temps CPU.
36
b) La liste de RID qui résulte de l'intersection des différentes listes originales est plus
petite que chaque liste originale; par conséquent, l'utilisation de cette liste pour
accéder aux données nécessitera un nombre minimum d'accès sur mémoire
secondaire.
c) En utilisant la technique du tri-fusion (décrite dans le chapitre 1) pour calculer
l'intersection des différentes listes, on obtient une liste de RID ordonnée. Ceci
permet un accès groupé aux données et par conséquent une diminution du nombre
d'entrées/sorties sur mémoire secondaire.
2.1.2 PHASE D'OPTIMISATION
Dans cette phase, le SGBD établit une stratégie d'exécution pour la requête en
sélectionnant les index qui vont servir pour l'intersection. Cette phase est constituée des
étapes suivantes:
a) Déterminer les index éligibles, par exemple en utilisant la méthode de System R
[Selinger & al 1979]. Pour chaque index éligible par rapport à un prédicat
conjonctif simple, évaluer la sélectivité et le coût d'utilisation de cet index.
b) Pour chaque prédicat disjonctif faisant partie d'un prédicat conjonctif, utiliser la
méthode d'union des index (section 2.2.1) pour les prédicats disjonctifs afin de
chercher la meilleure stratégie à appliquer.
c) Les stratégies mono-index de l'étape (a) et les stratégies de l'union des index de
l'étape (b) sont ordonnées selon leur sélectivité. La stratégie qui correspond à la
sélectivité maximale et au coût minimal est choisie comme première stratégie.
d) La stratégie qui, lorsque combinée avec les stratégies déjà choisies, qui produit une
plus grande sélectivité à un coût moindre est choisie comme prochaine stratégie.
37
e) L'étape (d) est répétée jusqu'à l'épuisement de tous les index ou jusqu’à ce que
l'utilisation d'un index additionnel n'apporte aucune amélioration de la performance
ou conduise à une dégradation des performances. Ceci est le cas lorsque, par
exemple, le coût d'utilisation d'un index additionnel pour évaluer un prédicat est
plus grand que le coût d'utilisation de la liste de RID déjà trouvée pour évaluer ce
même prédicat.
Remarques
1. Noter qu'il n’y a aucune relation directe entre la sélectivité d'un index et son coût
d'utilisation. Si l'index I1 est plus sélectif que l'index I2, cela ne signifie pas
nécessairement que le coût d'utilisation de I1 est inférieur à celui de I2. Par exemple,
supposons que l'index I1 soit défini sur les attributs (A1, A2, A3), que l'index I2 soit
défini sur l'attribut A2 seulement, et que le prédicat considéré est (A2=39 AND
A3=28).
On a deux prédicats simples : {A2=39, A3=28}.
• Déterminer les index éligibles:
I1 est éligible pour les prédicats {A2=39, A3=28},
I2 est éligible pour le prédicat {A2=39}.
• Calculer la sélectivité de chaque index:
Sélectivité(I1)= 22
= 100% ⇒I1 est éligible pour tous les prédicats simples de la
requête.
Sélectivité(I2)= 12
= 50% ⇒I2 est éligible pour 50% des prédicats simples de la
requête.
On a donc Sélectivité(I1) > Sélectivité(I2).
38
La sélectivité de I1 est donc meilleure que celle de I2 car, avec l'index I1, les deux
conditions qui forment le prédicat peuvent être testées alors qu'avec l'index I1, on ne
peut tester qu'une seule condition. Par contre, le coût d'utilisation de I2 est inférieur à
celui de I1 car l'index I1 est composé de 3 attributs qui doivent tous être testés alors
que I1 est composé d'un seul attribut.
2. Le coût d’utilisation d’un index repose essentiellement sur le nombre de tests à
effectuer dans l’utilisation de ce dernier mais aussi sur d’autres facteurs secondaires.
Notons que l’étude des coûts qui est un problème complexe est hors des limites de
notre travail.
39
2.1.3 PHASE D'EXÉCUTION
Dans cette phase le SGBD exécute la stratégie établie pendant la phase d'optimisation,
c’est-à-dire qu'il applique la technique de l'intersection sur les index sélectionnés. Cette
phase est constituée des étapes suivantes:
a) Chaque liste de RID est générée suivant les stratégies définies à la phase
d'optimisation.
b) Si, pendant la génération (construction) d'une liste de RID, la taille de la liste
excède une certaine borne supérieure déterminée par l'optimiseur de requêtes alors
abandonner cette liste et retourner à l'étape (a) pour la prochaine stratégie sinon
passer à l'étape (c).
c) Calculer l'intersection de la nouvelle liste de RID générée avec la liste courante
pour générer une nouvelle liste courante.
d) Si la taille de la nouvelle liste courante est inférieure à une certaine borne inférieure
déterminée par l'optimiseur de requêtes alors arrêter sinon aller à l'étape (a) pour la
prochaine stratégie.
Remarques
1. La borne supérieure et la borne inférieure sont déterminées par l'optimiseur de
requêtes. Ces valeurs dépendent de plusieurs facteurs dont:
• les statistiques sur la taille de la table,
• le nombre de pages transférées par opération d'entrée/sortie,
• le coût du balayage séquentiel de la table,
• le coût d'évaluation des prédicats en utilisant les pages de données (table de données)
versus les pages d'index (index),
40 • le coût de l'algorithme de tri utilisé,
• le nombre de pages de données occupées par la table.
2. Si la cardinalité de la table contenant les données est n, alors la borne inférieure et la
borne supérieure peuvent avoir les valeurs suivantes: borne inférieure = 1 et borne
supérieure = n.
2.1.3.1 EXEMPLE (avec des prédicats conjonctifs)
Soit le prédicat:
P1(A1) AND P2(A2) AND P3(A3) AND P4(A4) AND P5(A5) AND P6(A6)
et les index suivants:
I1 défini sur les attributs A1, A2,
I2 défini sur les attributs A1, A3, A4,
I3 défini sur l'attribut A6,
I4 défini sur les attributs A1, A3, A4, A5,
I5 défini sur les attributs A7, A8,
prédicats conjonctifs simples: {P1, P2, P3, P4, P5, P6}.
Phase d’optimisation:
Étape a)
Index éligibles pour les prédicats conjonctifs simples:
I1 éligible pour P1, P2,
I2 éligible pour P1, P3, P4,
I3 éligible pour P6,
I4 éligible pour P1, P3, P4, P5,
I5 non éligible.
index éligibles = {I1, I2, I3, I4}.
Calcul de la sélectivité:
Sélectivité(I1)= 26
= 13
,
41
Sélectivité(I2)= 36
= 12
,
Sélectivité(I3)= 16
,
Sélectivité(I4)= 46
= 23
Étape b)
Index éligibles pour les prédicats disjonctifs: pas de prédicats disjonctifs.
Étape c)
ordre = {I4, I2, I1, I3},
stratégie1={I4}.
Étape d)
stratégie2={I4, I2} ?
Sélectivité(I4, I2) = 46
= Sélectivité(I4) ⇒I2 rejeté,
stratégie2={I4, I1} ?
Sélectivité(I4, I1)= 56
> Sélectivité(I4) ⇒I1 accepté,
stratégie3={I4, I1, I3} ?
Sélectivité(I4, I1, I3)= 66
>Sélectivité(I4, I1) ⇒I3 accepté,
Sélectivité(I4, I1, I3)=1 (100%)⇒arrêter,
donc stratégie choisie : {I4, I1, I3}.
42
2.1.3.2 EXEMPLE (avec des prédicats conjonctifs et disjonctifs)
Soit le prédicat:
P1(A1) AND (P2(A2) OR P3(A3)) AND P4(A4) AND P6(A6) AND P7(A7) AND
P8(A8)
Prédicats conjonctifs simples : {P1, P4, P6, P7, P8}.
Prédicats disjonctifs simples : {P2, P3}.
Phase d’optimisation:
Étape a)
Index éligibles pour les prédicats conjonctifs simples:
I1 éligible pour P1,
I2 éligible pour P1, P4,
I3 éligible pour P6,
I4 éligible pour P1, P4,
I5 éligible pour P7, P8,
index éligibles: {I1, I2, I3, I4, I5}.
Calcul de la sélectivité:
Sélectivité(I1)= 27
,
Sélectivité(I2)= 37
,
Sélectivité(I3)= 17
,
Sélectivité(I4)= 37
,
Sélectivité(I5)= 27
,
Étape b) 43
Index éligibles pour les prédicats disjonctifs simples:
I1 éligible pour P2,
I2 éligible pour P3,
I3 non éligible,
I4 éligible pour P3,
I5 non éligible,
index éligibles: {I1, I2}.
Calcul de la sélectivité:
Sélectivité(I1)= 27
,
Sélectivité(I2)= 37
,
Sélectivité(I1, I2) = 47
,
stratégie = {I1, I2}.
Étape c)
ordre = { {I1, I2}, I2, I4, I1, I5, I3},
stratégie1={I1, I2}.
Étape d)
stratégie2={I1, I2, I2}={I1, I2}= stratégie1,
stratégie2={I1, I2, I4},
Sélectivité(I1, I2, I4)= 47
= Sélectivité(I1, I2),
stratégie2={I1, I2, I1}={I1, I2}= stratégie1,
stratégie2={I1, I2, I5},
Sélectivité(I1, I2, I5)= 67
>Sélectivité(I1, I2) ⇒I5 accepté,
44
stratégie3={I1, I2, I5, I3},
Sélectivité(I1, I2, I5, I3)= 77
= 1 arrêter,
Donc stratégie choisie : {I1, I2, I5, I3}.
2.1.4 ÉVALUATION D'UNE NÉGATION
Si dans le prédicat on trouve une condition qui exprime une négation, par exemple NOT
(Service=20) et si un index est défini sur l'attribut Service, alors l'évaluation de cette
condition peut se faire de la façon suivante.
1)
2)
En utilisant l'index défini sur l'attribut Service, générer la liste de RID des tuples qui
satisfont la condition Service=20.
Éliminer dans les autres listes les RID obtenus dans l'étape précédente.
2.1.4.1 EXEMPLE
Soient la table EMPLOYE et l'exemple d’occurrence de cette table de la page 30 et soit
la requête suivante:
SELECT Nom
FROM EMPLOYE
WHERE (Nas='272-2%' AND NOT(Service<18));
Le prédicat P de la requête est le suivant:
P : (Nas='272-2%' AND NOT(Service<18))
on a:
I1 est un index éligible pour le prédicat simple : Service<18.
I3 est un index éligible pour le prédicat simple : Nas='272-2%'.
Pour évaluer le prédicat P on procède comme suit:
45
1) En utilisant l'index I1, générer la liste des RID qui satisfont le prédicat simple
Service<18.
Liste_Service<18={0000, 0001, 0003}.
2) En utilisant l'index I3, générer la liste des RID qui satisfont le prédicat simple
Nas='272-2%' : Liste_Nas='272-2%' = {0000, 0002, 0003, 0004}.
3) Éliminer dans Liste_Nas='272-2%' les RID qui appartiennent à Liste_Service<18, ce
qui donne :
Liste_résultat = Liste_Nas='272-2%' - Liste_Service<18
= {0000, 0002, 0003, 0004} - {0000, 0001, 0003}
= {0002, 0004}.
Donc Liste_résultat={0002, 0004}.
2.2 CAS DES PRÉDICATS DISJONCTIFS
2.2.1 UNION DES INDEX
Pour évaluer un prédicat composé de prédicats disjonctifs simples, on utilise une
technique appelée : "union des index". Cette technique peut se résumer en deux étapes:
a) Pour chaque prédicat disjonctif simple, utiliser l'index éligible correspondant pour
générer la liste de RID qui satisfont le prédicat.
b) Faire l'union des différentes listes de RID trouvées précédemment. La liste résultante
contient les RID des tuples qui satisfont le prédicat. On utilise cette liste pour accéder
aux données sur mémoire secondaire.
46
2.2.1.1 EXEMPLE
Soit la table EMPLOYE de l'exemple précédent, et soit la requête suivante: SELECT Nom
FROM EMPLOYE
WHERE Age>50 OR Service>25;
Le prédicat associé à cette requête est composé des 2 prédicats disjonctifs simples:
Age>50 et Service>25. On peut utiliser le premier index pour avoir la liste de RID qui
vérifient la première condition du prédicat (Age>50), ce qui donne:
liste_Age>50={0001}, et le deuxième index pour avoir la liste de RID qui vérifient la
deuxième condition du prédicat (Service>25), ce qui donne: liste_Service>25={0004}.
Le résultat final sera l'union des deux résultats partiels, soit:
liste_résultat =liste_Age>50 ∪ liste_Service>25
={ 0001 } ∪ { 0004 }
= { 0001, 0004 }.
Pour obtenir la réponse à la requête, on accède aux données sur mémoire secondaire en
utilisant la liste de RID finale, ce qui donne les noms suivants: { Caron, Poulin }.
Plan d’exécution :
SQL> EXPLAIN PLAN FOR
2 SELECT Nom
3 FROM EMPLOYE
4 WHERE Age > 50 OR Service > 25;
Explained.
OPERATION OPTIONS OBJECT_NAME
SELECT STATEMENT Cost =
TABLE ACCESS BY ROWID EMPLOYE
OR-EQUAL
INDEX RANGE SCAN INDEX_AGE
INDEX RANGE SCAN INDEX_SERVICE
47
Remarques
1
2
Pour ces deux techniques (intersection et union des index), à l'étape a) il se peut qu'il
existe plusieurs index éligibles; par conséquent, l'un des problèmes à résoudre est de
déterminer quel est l'index éligible à utiliser.
Pour une requête (prédicat) contenant à la fois des prédicats conjonctifs et disjonctifs,
ces deux techniques sont généralement utilisées de façon combinée.
Comme pour les prédicats conjonctifs, l'évaluation des prédicats disjonctifs se fait en 2
phases: phase d'optimisation et phase d'exécution.
Si tous les prédicats disjonctifs peuvent être testés efficacement en utilisant un ou
plusieurs index éligibles, alors il est préférable d'appliquer la technique de l'union des
index pour ensuite accéder aux données à partir de la liste de RID résultante. Cette
approche évite d'avoir à effectuer un balayage séquentiel de la table.
2.2.2 PHASE D'OPTIMISATION
Dans cette phase, le SGBD sélectionne les index qui vont servir à l'union. Celle-ci est
constituée des étapes suivantes:
a) Pour chaque prédicat disjonctif simple, rechercher le meilleur index éligible. Si
aucun index éligible n'existe pour ce prédicat alors l'utilisation de cette technique
doit être exclue. Cependant, la technique du balayage séquentiel de la table avec
liste de RID [section 3.1] pourra être utilisée. Dans le cas contraire, une stratégie
mono-index est déterminée pour chaque prédicat simple (atomique).
48
b) Pour chaque prédicat disjonctif composé de prédicats conjonctifs, utiliser la
technique de l'intersection des prédicats conjonctifs présentée à la section 2.1.1.
Si la technique de l'intersection des index ne peut être utilisée pour ce prédicat alors
cette méthode basée sur l'union des index ne peut être appliquée et par conséquent
l’utilisation de la méthode du balayage séquentiel de la table avec liste de RID
devient inévitable.
c) Les stratégies mono-index de l'étape (a) et les stratégies basées sur l'intersection
des index de l'étape (b) sont ordonnées selon leur sélectivité.
La stratégie ayant la plus grande sélectivité et le plus faible coût est choisie comme
première stratégie pour l'exécution. La prochaine stratégie sera choisie parmi les
stratégies qui restent.
d) Toutes les stratégies sont utilisées ensemble pour générer la liste finale formée de
l'union de toutes les listes.
2.2.3 PHASE D'EXÉCUTION
Dans cette phase, le SGBD applique la technique de l'union sur les index sélectionnés
pendant la phase d'optimisation. Cette phase est constituée des étapes suivantes.
a) Chaque liste de RID est générée suivant les stratégies définies à la phase
d'optimisation.
b) Si pendant la génération (construction) d'une liste de RID, la taille de la liste
dépasse une certaine borne supérieure déterminée par l'optimiseur de requêtes,
alors la stratégie basée sur l'union des index ne peut être appliquée et par
conséquent il faut arrêter le processus et choisir une autre méthode (par exemple le
balayage séquentiel de la table).
49
c) Faire l'union de la nouvelle liste de RID générée avec la liste courante.
d) Si la taille de la nouvelle liste courante dépasse une certaine borne supérieure alors
arrêter le processus sinon aller à l'étape (a) pour la prochaine stratégie.
2.2.3.1 EXEMPLE
Soit le prédicat P1(A1) OR P2(A2) OR ( P3(A3) AND P4(A4) ) et les index suivants:
I1 défini sur l'attribut A1,
I2 défini sur l'attribut A2,
I3 défini sur les attributs A3, A4,
prédicats disjonctifs simples : {P1, P2},
prédicats conjonctifs simples : {P3, P4},
index éligibles : {I1, I2, I3}.
Phase d’optimisation:
a) Recherche des index éligibles pour les prédicats disjonctifs simples:
index_éligible(P1) = {I1},
index_éligible(P2) = {I2},
Sélectivité(I1)= 14
= 25%,
Sélectivité(I2)= 14
= 25%,
b) Cas des prédicats conjonctifs:
index éligibles : {I3},
Sélectivité(I3)= 24
= 50%,
stratégie={I3},
50
c) ordre={I3, I1, I2},
- stratégie1= {I3},
- stratégie2= {I3, I1} ?
Sélectivité(I3,I1)= 34
=75% >Sélectivité(I3)⇒ I1 accepté,
- stratégie3= {I3, I1, I2}= 44
= 100%⇒arrêter,
donc la stratégie choisie est : {I3, I1, I2}.
51
Chapitre 3
3. TECHNIQUES D’IMPLANTATION
3.1 BALAYAGE SÉQUENTIEL AVEC UTILISATION DE LISTES
Si au moins un prédicat conjonctif ne peut être testé par aucun index (il n’existe pas
d’index éligible pour ce prédicat) alors le balayage séquentiel de la table est inévitable,
car ce prédicat doit être testé pour chaque tuple de la table et par conséquent il est inutile
d'utiliser les index pour tester les autres prédicats. Néanmoins, dans certains cas, il est
avantageux d'utiliser les index pour tester ces prédicats.
Par exemple, si on considère la requête suivante:
SELECT Nom
FROM EMPLOYE
WHERE Age>40 AND Service>20;
Si un index est défini sur l'attribut Age seulement et si on suppose qu'un faible
pourcentage des tuples de la table satisfont les prédicats (i.e. constituent la réponse à la
requête), alors la stratégie qui suit améliore grandement les performances en temps CPU.
Cette stratégie appelé balayage séquentiel de la table avec utilisation des listes de RID
est décrite par les 3 étapes suivantes:
1)
2)
3)
En utilisant l'index défini sur l'attribut Age, construire la liste de RID des tuples
qualifiés et trier cette liste.
En accédant séquentiellement à la table, examiner seulement les tuples dont les RID
n'apparaissent pas dans la liste trouvée à l'étape (1) et tester le prédicat sur l'attribut
Service.
52
Retrouver les attributs demandés dans la requête à partir des tuples qualifiés dans
l'étape (1) et (2).
L'avantage de l'utilisation de la technique du balayage séquentiel de la table avec
utilisation des listes de RID plutôt que d'utiliser un balayage séquentiel de la table (sans
listes de RID) réside dans le fait qu'avec le balayage séquentiel de la table, on doit
nécessairement tester les deux conditions qui forment le prédicat sur tous les tuples de la
table.
Si les sélectivités sont bonnes, le coût pour identifier les tuples qui satisfont le prédicat
sur l'attribut Age en utilisant l'index est plus faible que de tester ce prédicat sur chaque
tuple qui ne satisfait pas le prédicat sur Service. Ceci se justifie par les raisons suivantes:
1)
2)
Gain d'accès sur l'attribut Service qui peut être très coûteux si cet attribut se trouve à la
suite d’attributs de longueurs variables.
Les index permettent de stocker et de manipuler les valeurs doubles très efficacement
(ils maintiennent dans une page une seule instance de clé suivie par la liste de RID qui
ont la même valeur de clé). Ainsi, après une seule opération de comparaison, un grand
nombre de RID est retrouvé. Ceci est bien entendu vrai si on suppose qu'il existe un
nombre important de valeurs doubles pour les clés.
3.1.1 EXEMPLE
Soit l’occurrence de la table EMPLOYE de la page 30 et soit la requête suivante:
SELECT Nom
FROM EMPLOYE
WHERE Age>45 OR Service>30;
On considère qu'un seul index existe, soit I sur l'attribut Age.
a) Construction de la liste:
Liste_Age>45={0001, 0002, 0004}.
b) Accès séquentiel à la table de données:
c)
53
TABLE (RID) % Liste_Age>45 Examiner tuple 0000 Non Oui 0001 Oui Non 0002 Oui Non 0003 Non Oui 0004 Oui Non 0005 Non Oui
Tableau 3-1 Exemple de balayage séquentiel avec utilisation de listes
En parcourant séquentiellement la table, on examine seulement les tuples dont les RID
n'apparaissent pas dans Liste_Age>45, c’est-à-dire : {0000, 0003, 0005}. Ceci est un
gain appréciable par rapport à l'approche classique où il faut examiner tous les tuples de
la table.
3.2 ACCÈS AUX DONNÉES
La liste finale obtenue à partir des opérations d'union et d'intersection est une liste
candidate qui inclut la réponse à la requête. Par conséquent, la réponse peut être
seulement un sous-ensemble de la liste car il peut exister des prédicats conjonctifs qui
n'ont pas été testés en utilisant les index.
Il est possible aussi qu'une liste de RID n'ait pas été produite (abandonnée) car elle a
dépassé la borne supérieure permise; dans ce cas, un balayage séquentiel de la table est
inévitable.
Avant d'accéder aux données, il est préférable de trier la liste finale de RID pour
permettre un accès groupé aux données.
Les opérations d'union et d'intersection sont exécutées seulement si elles sont profitables
et, par conséquent, il n'est pas nécessaire d'exploiter tous les index candidats, c’est-à-dire
qu'il n'est pas nécessaire de tester tous les prédicats simples.
Les prédicats simples qui n'ont pas été testés le seront pendant l'accès aux données via la
liste de RID finale qui est assez courte.
54
Si tous les prédicats simples ont des index éligibles, alors tous les prédicats seraient
testés en utilisant les index pendant l'exécution. On utilise la technique RR locking
[section 3.4.2] pour éviter de tester les mêmes prédicats.
3.3 VECTEURS DE BITS
La plupart des langages de programmation ne permettent pas une manipulation efficace
des listes (par exemple, absence des opérateurs d'union et d'intersection), obligeant ainsi
l'utilisateur à définir ces opérateurs. Afin de pallier à cet inconvénient, on peut utiliser
une autre structure de données plus souple à manipuler. Il s'agit des vecteurs. En effet, un
vecteur de bits remplace avantageusement une liste de RID. À chaque tuple (RID) de la
table de données est associé un bit dans le vecteur de bits et par conséquent la taille du
vecteur de bits n'est autre que la cardinalité de la table de données. L'évaluation d'un
prédicat simple se fait de la façon suivante:
Pour chaque tuple qui vérifie le prédicat, positionner le bit correspondant dans le vecteur
de bits. Le résultat final regroupe tous les tuples dont le bit correspondant est positionné
dans le vecteur de bits.
• Pour l'évaluation d'un prédicat composé de prédicats disjonctifs simples, un seul
vecteur de bits est utilisé. Pour chaque accès à l'index, les bits correspondants aux
tuples sélectionnés sont positionnés.
• Pour l'évaluation d'un prédicat composé de prédicats conjonctifs simples, un vecteur
de bits est généré pour chaque accès à l'index. Le résultat final sera alors le vecteur
résultant de l'opération logique AND entre les différents vecteurs de bits trouvés
précédemment.
Soient V1, V2, V3,..., Vn les vecteurs de bits correspondant aux n prédicats simples qui
composent le prédicat associé à la requête. Le vecteur de bits résultant est alors obtenu
comme suit:
V= V1 AND V2 AND V3 ... AND Vn.
55
3.3.1 EXEMPLE
S ccurrence de la table
SELECT Nom
FROM EMPLOYE
WHERE (Age>45 OR Service>30) AND Sexe=‘M’; oit l’o EMPLOYE de la page 30 et soit la requête suivante:
La condition de la requête considérée est composée des deux prédicats conjonctifs
(Age>45 OR Service>30) et Sexe=‘M’ et des deux prédicats disjonctifs Age>45 et
Service>30. Par conséquent on a :
V1 vecteur de bits pour évaluer les deux prédicats disjonctifs Age>45 et
Service>30. L’évaluation se fait de la façon suivante:
Pour chaque tuple qui vérifie l’un des deux prédicats, positionner le bit
correspondant dans le vecteur de bits V1. Le résultat obtenu est le suivant:
1 2 3 4 5 6 V1 0 1 1 1 1 1
V2 vecteur de bits pour évaluer le prédicat conjonctif Sexe=‘M’. L’évaluation se
fait de la façon suivante:
Pour chaque tuple qui vérifie ce prédicat, positionner le bit correspondant dans le
vecteur de bits V2. Le résultat obtenu est le suivant:
1 2 3 4 5 6 V2 1 1 0 1 0 0
Le vecteur de bits résultant Vr est obtenu comme suit:
Vr = V1 AND V2 = (0,1,1,1,1,1) AND (1,1,0,1,0,0) = (0,1,0,1,0,0), c’est-à-dire le
deuxième et le quatrième tuple de la table EMPLOYE.
56
3.4 GESTION DES ACCÈS CONCURRENTS
Un SGBD permet à plusieurs utilisateurs d'accéder simultanément aux mêmes données
grâce aux techniques de verrouillage. Le verrouillage est un mode de réservation qui
consiste à interdire l'accès à une partie des données pendant que celle-ci est utilisée par
une unité de traitement. Il permet ainsi de protéger les données contre des opérations de
mise à jour incorrectes ou affectant les structures (effectuées par plusieurs utilisateurs
concurrents). Comme conséquence de cette technique de verrouillage, deux utilisateurs
peuvent se trouver dans un état où chacun attend la libération d'une partie des données en
cours d'utilisation par l'autre. Cette situation est appelée interblocage. Ce problème sort
du cadre de cette étude et par conséquent il ne sera pas traité ici. Disons simplement
qu'un SGBD doit disposer de mécanismes de détection d'interblocage qui permettent
d'éviter une telle situation en débloquant l'un des utilisateurs selon certaines règles.
Lors de l'accès aux données sur mémoire secondaire à partir de la liste de RID, il est
possible qu'avant la fin de la transaction, un des tuples déjà accédé soit effacé ou modifié
par une autre transaction. Dans ce cas, le résultat obtenu sera erroné. Ce problème peut
être évité en utilisant des mécanismes de verrouillage.
Suivant que le verrouillage est appliqué sur seulement le tuple accédé (courant) ou sur
l'ensemble des tuples déjà accédés, on distingue deux techniques de verrouillage: partiel
et total.
3.4.1 VERROUILLAGE PARTIEL (CURSOR STABILITE)
Dans ce cas, le verrouillage n'est appliqué que sur le tuple courant (en cours d'accès) qui
est libéré lors du passage au tuple suivant. C’est-à-dire qu'à tout moment, un seul tuple
est verrouillé. Aucun verrouillage n'est nécessaire pendant l'accès aux pages d'index.
Lorsque la liste finale de RID est obtenue, un accès aux pages de données est nécessaire
pour retrouver les tuples sélectionnés. C'est à cette étape que le verrouillage partiel est
appliqué et que les prédicats sont réévalués si le tuple fait encore partie de la table. Les
57
tuples supprimés seront ignorés. Les prédicats sont réévalués, car il se peut que l'un des
tuples sélectionné ait été modifié ou supprimé.
3.4.2 VERROUILLAGE TOTAL (REPEATABLE READ)
Avant d'accéder à un tuple, le verrouillage est appliqué sur celui-ci. Le passage au tuple
suivant se fait sans libérer le tuple courant. C’est-à-dire que les tuples déjà accédés
restent verrouillés jusqu'à la fin de la transaction.
3.4.2.1 PRÉDICAT DISJONCTIF
Pour un prédicat disjonctif et avec l'utilisation d'un vecteur de bits, les verrouillages
inutiles peuvent être évités en verrouillant un tuple seulement si le bit correspondant à ce
tuple sélectionné n'a pas été déjà positionné (c’est-à-dire seulement si le tuple n'a pas été
accédé par un autre index).
La même optimisation peut être faite avec les listes de RID.
Si la granularité est de niveau bloc, il est souhaitable d'avoir un vecteur de bits pour le
verrouillage des blocs où chaque bit correspondra à un bloc de données.
3.4.2.2 PRÉDICAT CONJONCTIF
Il est suffisant d'appliquer le verrouillage seulement pendant l'utilisation du premier
index car les index suivants vont utiliser la liste obtenue par le premier accès index et
générer une sous-liste de cette liste dont les RID sont déjà verrouillés par le premier
accès index.
Cette optimisation permet aux autres transactions de modifier les tuples qui ne satisfont
pas le prédicat sur le premier index et qui satisfont les autres prédicats.
58
3.4.2.2.1 EXEMPLE
Soit le prédicat conjonctif suivant: A1=C1 AND A2=C2 AND ... Ak=Ck
où les Ai sont des attributs et les Ci des constantes.
On suppose que sur chaque attribut est défini un index et que le prédicat sur l'attribut A1
est le plus restrictif.
Pendant l'accès index sur l'attribut A1, le verrouillage est appliqué sur les RID
référencés. Ceci permet aux autres transactions de modifier les tuples qui ne satisfont pas
le prédicat sur A1 mais qui satisfont les autres prédicats. Ceci n'aurait pas été possible si
le verrouillage avait été appliqué pendant les autres accès index.
3.5 APPORTS DU PARALLÉLISME
Présentement, les systèmes monoprocesseurs sont à leur apogée. Les applications
informatiques exigent de plus en plus de ressources et doivent toujours être plus
performantes. On prévoit donc une certaine stagnation dans les performances des
systèmes monoprocesseurs. Une solution à ce problème est le parallélisme.
Les ingénieurs conçoivent des systèmes parallèles de plus en plus puissants mais le
développement du logiciel parallèle correspondant ne suit pas toujours à la même vitesse.
Les recherches vont bon train mais les applications concrètes sont encore quasi
inexistantes.
Nous avons vu précédemment, que pendant la phase d'optimisation, le SGBD établit une
stratégie d'exécution pour la requête. En l'absence d'une stratégie d'exécution, c’est-à-dire
si le SGBD n'arrive pas à trouver une stratégie pour optimiser la requête ou bien que la
stratégie trouvée est impraticable, alors il parcourt toute la base de données pour obtenir
la réponse à la requête, ce qui peut être très pénalisant si on tient compte de l'important
volume d'une base de données. Ceci a amené les concepteurs des bases de données à
s'intéresser de plus en plus au traitement parallèle de façon à accéder aux données en un
minimum de temps et par conséquent améliorer les performances d'accès aux données.
59
Même dans le cas où le SGBD arrive à trouver une stratégie d'exécution acceptable, le
parallélisme peut être exploité afin d'améliorer les performances. En effet, on peut
associer un processus à chaque accès basé sur un index (index éligible) de telle façon que
la génération des listes de RID se fasse en parallèle.
Or, dans le cadre de ce projet, les machines VOLVOX à base de transputers avec
mémoire distribuée sont disponibles, ce qui nous permet de tester les algorithmes qui ont
été présentés et de s'assurer qu'ils améliorent de façon significative les performances du
système.
Nous avons vu précédemment que pour répondre à une requête, deux approches
différentes sont utilisées:
a) Approche des index qui suppose l'existence d'un certain nombre d'index :
l'inconvénient de cette méthode est qu'elle est contraignante dans le sens où elle
suppose l'existence de plusieurs index mais elle réduit les coûts de façon
considérable par rapport à l'approche classique.
b) Balayage séquentiel de la table de données (approche classique): l'avantage de cette
méthode est qu'elle n'est pas contraignante (peut être utilisée dans tous les cas),
mais elle est caractérisée par un coût assez élevé.
60
Chapitre 4
4. ENVIRONNEMENT D’EXPÉRIMENTATION
Un des sujets les plus chauds attaché à la recherche sur le parallélisme est celui des bases
de données. On connaît depuis toujours la lenteur inacceptable des SGBD lorsque la
quantité de données dépasse la dizaine de Mega-octets.
Les tests expérimentaux décrits plus loin ont été réalisés sur la machine VOLVOX de la
compagnie ALEX [Alex 1991a], [Alex 1991b]. Son architecture à base de transputers
T800 la rend facilement configurable et facile à utiliser. Les 64 transputers à l’intérieur
du VOLVOX peuvent être organisés suivant une topologie de réseau quelconque,
assurant ainsi une communication fiable et rapide d’un transputer à un autre. Le
problème est le choix de la meilleure topologie à utiliser pour un problème donné.
Dans le développement de systèmes parallèles, une phase critique est la communication
entre les processus qui s’exécutent sur un même transputer ou sur plusieurs transputers.
La communication entre processus et entre transputers est fiable et rapide. Mais la
transmission de messages se fait exclusivement par rendez-vous (i.e. le transmetteur et le
receveur doivent s’attendre l’un l’autre). Ceci permet la synchronisation des processus.
4.1 LES T800 ET LA MACHINE VOLVOX
Le transputer (trans- à travers, puter- computer) est un ordinateur complet sur une seule
puce. Ses liens de communication intégrés lui permettent de transmettre et de recevoir
des messages de ses quatre voisins immédiats (Figure 4-1). Ceci constitue une limite
physique du transputer. Si le besoin se fait sentir de communiquer avec un voisin non-
immédiat, il faudra passer par un ou plusieurs intermédiaires, d’où l’utilité d’un réseau de
communications. Ces liens bidirectionnels sont numérotés de 0 à 3.
La machine VOLVOX se compose de 64 transputers T800, possédant chacun 4 Mo de
mémoire. Au départ, les transputers sont dits flottants ou non-connectés. La première
étape dans la réalisation d’un réseau de communications est de connecter physiquement
61
les transputers à l’aide du langage de configuration. Il faut ensuite écrire à l’aide du
langage Inmos C les codes source nécessaires au bon fonctionnement du réseau et au
routage efficace des trames d’information.
En plus des 64 transputers compris dans la machine VOLVOX, un 65è transputer est mis
à notre disposition sur une carte d’interface située dans une station SUN, qui joue le rôle
de front-end à la machine parallèle. Ce transputer en surplus est appelé racine, ou root
transputer, alors que la station de travail est appelée hôte (host). Comme le transputer
racine est le seul à être relié physiquement à la station de travail, nous ne pouvons
effectuer d’opérations d’entrée/sortie qu’à partir de lui.
Un transputer est un micro-ordinateur contenant un processeur, de la mémoire locale (4
Mo) et quatre liens de communication bidirectionnels. Ces liens servent à la
communication entre les transputers. La machine VOLVOX contient 64 transputers qui
peuvent être utilisés seul ou en réseau pour construire des systèmes parallèles selon
différentes topologies.
CPU
Links T800
RAM
Memory Interface
1
0 2
3
Figure 4-1 Le T800 et ses quatre liens
62
4.2 PROCESSUS
La notion de processus a été introduite dans les systèmes en vue de décrire l’exécution de
programmes. L’exécution d’un programme peut être représentée comme une suite
d’actions élémentaires c’est-à-dire atomiques. La propriété d’atomicité traduit le fait que
cette opération apparaît comme instantanée à un observateur donné. On peut donc décrire
le déroulement d’un calcul en observant les états correspondant aux débuts et fins
d’actions atomiques; ces instants sont appelés points d’observations et les états observés
à ces instants sont appelés événements. Ainsi un processus peut être vu comme une
succession d’événements.
Le transputer fournit un excellent support pour la concurrence. Un céduleur microcodé
permet l’exécution de plusieurs processus en partageant le temps CPU. Donc sur un
même transputer, il y a simulation de concurrence c’est-à-dire à un moment donné un
seul processus est en train de s’exécuter.
Chaque processus peut prendre l’un des deux états suivants:
- Actif : - En train de s’exécuter.
- Dans la liste d’attente d’exécution.
- Inactif : - Prêt à recevoir sur un canal.
- Prêt à transmettre sur un canal.
- Attend qu’un délai se soit écoulé.
Le céduleur est conçu de façon à ce qu’un processus inactif ne consomme aucun temps
CPU. Les processus actifs sont conservés dans une liste d’espace de travail. Cette liste est
implantée à l’aide de deux registres, un pointeur sur le premier processus de la liste et
l’autre, sur le dernier. Un processus actif devient passif si l’un des événements suivants
survient :
• En attente sur un canal pour la réception ou la transmission. 63
• En attente d’un TIMER.
Chaque processus actif possède un temps d’exécution limité ( environ 25 ms).
Lorsqu’un processus n’est plus en exécution (son temps est expiré ou devient inactif),
son pointeur d’instruction est sauvegardé dans son espace de travail et le prochain
processus est exécuté. Le changement de contexte est donc presque instantané.
Il existe deux niveaux de priorité (haute 0 et basse 1) pour l’exécution des processus. Un
processus prioritaire (niveau 0) doit être de courte durée d’exécution car il ne peut pas
partager le CPU avec un autre processus. Il ne perd le contrôle du CPU que lors d’une
opération sur un canal EMPTY ou l’attente d’un TIMER. Un processus de priorité basse
est inactif pendant l’exécution d’un processus prioritaire.
Tous les processus partagent le même espace global de mémoire. Toutes les variables
statiques ou externes sont partagées par les autres processus actifs. Les seules variables
privées sont celles déclarées "auto". Les processus partagent aussi la même pile, les
appels malloc() et free() allouent de la mémoire à partir du même espace pile.
4.3 LANGAGE DE CONFIGURATION INMOS
Pour relier les transputers entre eux dans le but de former un réseau, il faut utiliser le
langage de configuration fourni par la compagnie Inmos (qui fabrique les T800). Ce
langage, qui se rapproche en certains points du langage C, nous permet de raccorder
physiquement et logiquement les transputers en une topologie choisie pour faciliter la
connexion des transputers entre eux, comme par exemple:
REP i = n TO m Répéter le bloc d’instructions qui suit pour i variant de n à m
(similaire à l’instruction for en C)
A noter: toutes les commandes du langage de configuration doivent se terminer par un
point-virgule (;).
64
Les principales topologies sont les suivantes: matrice, anneau, hypercube, dragon-net et
arborescence. Nous présentons chacune d’elles brièvement ci-dessous.
• Matrice 8x8 : les transputers sont disposés en matrice de 64 éléments. Chaque
transputer de la matrice est relié à tous ses voisins immédiats comme illustré à la
figure 4-2.
0 1 2 3 4 5 6 7
8
16
24
32
40
48
56
9 10 11 12 8 8 8
17 18 19 20 21 22 23
25 26 27 28 29 30 31
33 34 35 36 37 38 39
41 42 43 44 45 46 47
49 50 51 52 53 54 55
57 58 59 60 61 62 63
RS
Transputer Transputer Transputer Transputer Transputer Transputer Transputer Transputer
Transputer
Transputer
Transputer
Transputer
Transputer
Transputer
Transputer
Transputer Transputer Transputer Transputer Transputer Transputer Transputer
Transputer Transputer Transputer Transputer Transputer Transputer Transputer
Transputer Transputer Transputer Transputer Transputer Transputer Transputer
Transputer Transputer Transputer Transputer Transputer Transputer Transputer
Transputer Transputer Transputer Transputer Transputer Transputer Transputer
Transputer Transputer Transputer Transputer Transputer Transputer Transputer
Transputer Transputer Transputer Transputer Transputer Transputer Transputer
Figure 4-2 Topologie en matrice 8x8
Sur la figure, le R représente le transputer racine (root) et le S représente la station Sun.
65
• Anneau : les transputers sont disposés en anneau et chaque transputer est relié
à son successeur et à son prédécesseur comme illustré à la figure 4-3. L’anneau
est doublement connecté et ceci afin de ne pas gaspiller deux des quatre liens
par transputer. Ceci doit en théorie augmenter la capacité du réseau. En effet ,
si l’un des canaux est occupé, alors l’autre peut être utilisé pour la
communication. Un autre avantage du lien double serait de dédier un lien pour
émettre et l’autre pour recevoir.
48 47 46
63
62
34
17
50
18
49
RS
33
160 1 2 14 15
30
31
32
.
.
.
.
.
.
. . .
. . .
Transputer Transputer Transputer
Transputer
Transputer
Transputer
Transputer
Transputer
Transputer
Transputer
Transputer
TransputerTransputer Transputer Transputer Transputer Transputer
Transputer
Transputer
Transputer
Figure 4-3 Topologie en anneau
Sur la figure, le R représente le transputer racine (root) et le S représente le Sun.
66
• Hypercube : un hypercube est un cube de dimension n comportant 2n noeuds,
où chaque noeud est relié à n voisins comme illustré à la figure 4-4. Il y a
plusieurs avantage à cette topologie:
• elle est extensible. En effet, avec deux cubes de dimension n, on peut
passer à un cube de dimension n+1; il suffit pour cela de relier deux à
deux les noeuds correspondants de chacun des cubes de dimension n.
• la distance moyenne entre deux noeuds n’est que de n2
et la distance
maximale est n, où n représente la dimension du cube. Chaque noeud
peut donc être accédé en un petit nombre de transmissions de message.
• de nombreuses architectures (chaînes, anneaux, ...) peuvent être décrites
sur cette topologie.
Figure 4-4 Topologie en hypercube
67
• DragonNet : le Dragon Network présente un attrait particulier à cause de son
architecture spéciale qui rend toutes collisions impossibles. Le Dragon est
composé de trois parties:
◊ Les émetteurs E (les 16 transputers de la rangée du haut).
◊ Les communicateurs C (les 32 transputers du centre).
◊ Les récepteurs R (les 16 transputers de la rangée du bas).
Cette topologie est illustrée à la figure 4-5 ci-dessous.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
16 17 18 19 20 21 22 23
24 25 26 27 28 29 30 31
32 33 34 35 36 37 38 39
40 41 42 43 44 45 46 47
48 49 50 52 545351 55 56 57 58 59 60 6261 63
Figure 4-5 Topologie Dragon-Net
Le DragonNet est coûteux car 32 transputers sont dédiés à la communication seulement,
ce qui représente la moitié du nombre total de transputers. L’idéal est de pouvoir
effectuer du traitement sur les transputers communicateurs sans sacrifier la rapidité du
transfert.
• Arbre : les transputers sont disposés en forme d’arbre comme illustré à la
figure 4-6.
68
4.4 LE LANGAGE INMOS C
Le langage Inmos C [Inmos 1990a], [Inmos 1990b] est l’outil de programmation
employé pour implanter les réseaux à concevoir. Ce langage offre diverses fonctions de
gestion du parallélisme et des structures de données adaptées à ce genre de travail.
Le langage Inmos C a été conçu spécifiquement pour gérer le parallélisme sur les
transputers et fonctionner de pair avec le langage de configuration brièvement décrit plus
haut.
Les outils Inmos demandent des soins particuliers. S’ils ne sont pas très difficiles à
utiliser, leur nombre rend cependant le procédé long à mémoriser.
69
Chapitre 5
5. RÉSULTATS EXPÉRIMENTAUX ET ANALYSE
5.1 APPROCHE EXPÉRIMENTALE MULTI-INDEXATION
L'idée de base est d'associer un processus à chaque accès index. Si chaque transputer
exécute un processus, la génération des listes de RID se fait en parallèle. Cette approche
est difficile à réaliser car il faut que le nombre d'index soit inférieur ou égal au nombre de
transputers. Dans le cas des machines VOLVOX, une difficulté supplémentaire vient
s'ajouter: la topologie dépend du nombre d'index car l'ajout d'un index signifie l'ajout
d'un transputer dans la topologie.
Par souci de généralité et de simplicité, dans la partie réalisation, une variante de
l'approche des index est utilisée. L'idée de base de cette nouvelle approche consiste à
distribuer les index sur les transputers.
Si on dispose de m index et d'une machine à base de n transputers avec mémoire
distribuée, alors les index peuvent être fractionnés en n morceaux plus petits distribués
sur les n mémoires des transputers. Chaque transputer évaluera la requête en utilisant les
m morceaux d’index.
Cette approche a été réalisée sur un échantillon de 30 000 tuples de la table EMPLOYE
définie sur les attributs (Nas, Nom, Prénom, Age, Service, Sexe). Nous avons considéré
que cet échantillon est assez représentatif pour obtenir des résultats significatifs. Les
tuples de l’échantillon sont générés de façon aléatoire par le processus data.c (Tableau 4-
3) et ceci afin de s’assurer que les valeurs des tuples sont distribuées uniformément.
Nous avons utilisé deux index (m=2) index_age et index_service définis sur les attributs
Age et Service respectivement.
70
L ête considérée est la
SELECT *
FROM EMPLOYE
WHERE (Age>26 AND Service<8); a requ suivante :
Enfin le nombre de transputers utilisé est 27 (n=27).
5.1.1 TOPOLOGIE
La topologie utilisée est un arbre de 41 noeuds (Figure 4-6). Chaque noeud représente un
transputer et à chaque transputer est associé un processus. La racine (processus root)
envoie les données au noeud master (processus master) qui les envoie à son tour aux
noeuds intermédiaires. Les noeuds intermédiaires (processus dispatch) jouent le rôle de
distributeurs de données, c’est-à-dire que chaque noeud intermédiaire reçoit les données
de son père et les distribue de façon uniforme à ses fils. Chaque feuille (processus slave)
de l’arbre attend de recevoir les données pour pouvoir exécuter l’approche des index,
puis retourne les résultats au noeud père.
Chaque noeud père attend de recevoir les résultats de tous ses fils pour exécuter une
opération d’union ou d’intersection de listes suivant que le prédicat est disjonctif ou
conjonctif puis envoie à son tour les résultats à son noeud père. Ce traitement se répète
de façon récursive jusqu’à ce que la racine ait reçu tous les résultats pour les afficher sur
la machine hôte (Sun).
Le nombre de transputers ayant contribué dans l’implantation de cette approche est 27
(n=27). En effet parmi les 41 qui ont été utilisés 14 ont joué un rôle exclusif de
distribution des données (Figure 4-6).
71
��������������
Host
Master
P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12 P13 P14 P15 P16 P17 P18 P19 P20 P21 P22 P23 P24 P25 P26 P27
Root
Figure 5-1 Topologie utilisée
Remarque Dans la partie réalisation, on n’a pas tenu compte du temps de transmission des données
du transputer root aux transputers feuilles car l’objectif est d’évaluer le temps
d’exécution de l’approche considérée et non du temps de communication.
72
5.1.2 RÉSULTATS
Les résultats obtenus sont énoncés dans le tableau 4-1 ci-dessous.
Nbre Transputers Temps (ms) %Gain 1 124160 2 63168 49 3 42176 66 4 31680 74 5 25344 80 6 21184 83 7 18176 85 8 15936 87 9 14144 89 10 12736 90 11 11648 91 12 10624 91 13 9856 92 14 9152 93 15 8576 93 16 8000 94 17 7552 94 18 7168 94 19 6848 94 20 6464 95 21 6144 95 22 5888 95 23 5632 95 24 5376 96 25 5184 96 26 4992 96 27 4800 96
Tableau 5-1 Résultats obtenus avec l’approche de la multi-indexation
Remarque Dans le tableau ci-dessus ainsi que dans le tableau 5-2, les valeurs de la colonne gain ont
été arrondies à leurs plus proches valeurs entières pour en améliorer la lisibilité.
73
1 3 5 7 9 11 13 15 17 19 21 23 25 270
20000
40000
60000
80000
100000
120000
140000
1 3 5 7 9 11 13 15 17 19 21 23 25 27
N bre transputers
M ulti-index
Figure 5-2 Représentation graphique des résultats (multi-indexation)
Ce graphique illustre les résultats obtenus en utilisant l’approche de la multi-indexation.
Le temps d’exécution est inversement proportionnel au nombre de transputers car la
charge de traitement est répartie sur les différents transputers. On constate que cette
charge est uniformément répartie sur les transputers. Par exemple en passant de 1 à 2
transputers le temps d’exécution a diminué de moitié. Le gain est quasi optimal.
Cette représentation graphique démontre clairement que le parallélisme améliore
grandement les performances dans le cas de la multi-indexation. En effet sur un
échantillon de 30 000 tuples de la table EMPLOYE, le temps d’exécution passe de
124160 ms sur 1 transputer à 4800 ms sur 27 transputers. C’est-à-dire que le temps
d’exécution a été divisé par presque 27, ce qui est très intéressant.
74
Le graphique suivant illustre le pourcentage de gain apporté par le parallélisme dans le
cas de la multi-indexation. Par exemple en passant de 1 à 2 transputers le pourcentage de
gain apporté par le parallélisme est de 50%.
1 3 5 7 9 11 13 15 17 19 21 23 25 270
102030405060708090
100
% G
ain
1 3 5 7 9 11 13 15 17 19 21 23 25 27
Nbre transputers
% Gain par rapport à un seul transputer (multi-indexation)
Figure 5-3 Gain du parallélisme dans le cas de la multi-indexation
Nous avons utilisé la formule suivante pour calculer le pourcentage de gain:
% Gain (n) = 100 - TTn
1 * 100
où :
n est le nombre de transputers,
T1 le temps d’exécution de l’approche de la multi-indexation avec un transputer,
Tn le temps d’exécution de l’approche de la multi-indexation avec n transputers.
On constate que le gain du parallélisme croît avec le nombre de transputers. En effet le
gain passe de 49% avec 2 transputers à 96% avec 27 transputers.
75
5.2 BALAYAGE SÉQUENTIEL DE LA TABLE DE DONNÉES
5.2.1 DESCRIPTION
Si on dispose d'une machine à base de n transputers avec mémoire distribuée, la table de
données peut être fractionnée en n morceaux plus petits distribués sur les n mémoires des
transputers. Chaque transputer exécutera la requête sur le morceau de la table de données
qui se trouve dans sa mémoire. La réponse finale à la requête sera l'union des n résultats
obtenus par les n transputers. Le temps d'exécution sera ainsi divisé par n dans le cas d'un
traitement parallèle.
À chaque transputer est associée une partie de la table de données. Chaque transputer
exécute un balayage séquentiel sur la partie qui lui est associée. Le résultat final sera
constitué de l'union des résultats partiels obtenus par les transputers.
Dans notre cas précis, le nombre de transputers est 27 (n=27) et le nombre de tuples est
30 000 (cardinalité de la table EMPLOYE = 30 000).
5.2.2 TOPOLOGIE
La topologie utilisée est la même que dans le cas de la multi-indexation, c’est-à-dire un
arbre de 41 noeuds (Figure 4-6). Chaque noeud représente un transputer et à chaque
transputer est associé un processus. La racine (processus root) envoie tous les tuples de la
table au noeud master (processus master) qui, à son tour, les distribue sur les trois
processus dispatch. Chaque noeud intermédiaire (processus dispatch) joue le rôle de
distributeur de données, c’est-à-dire qu’il reçoit une partie de la table de son père et la
distribue de façon uniforme à ses fils. Chaque feuille (processus slave) de l’arbre attend
de recevoir les données pour pouvoir exécuter un balayage séquentiel sur la partition de
la table qui lui est associée, puis retourne les résultats au noeud père. Chaque noeud père
attend de recevoir les résultats de tous ses fils pour exécuter une opération d’union de
listes puis envoie à son tour le résultat à son noeud père. Ce traitement se répète de façon
récursive jusqu’à ce que la racine ( processus root ) ait reçu tous les résultats pour les
afficher sur un terminal.
76
Comme dans le cas de la multi-indexation, le nombre de transputers ayant contribué dans
l’implantation de cette approche est 27 (n=27). En effet parmi les 41 qui ont été utilisés,
14 ont joué un rôle exclusif de distribution des données (Figure 4-6).
5.2.3 RÉSULTATS
Les résultats obtenus sont énoncés dans le tableau 4-2 ci-dessous.
Nbre transputers Temps (ms) % Gain 1 168576 2 84416 50 3 56256 67 4 42304 75 5 33856 80 6 28224 83 7 24256 86 8 21184 87 9 18880 89 10 17024 90 11 15488 91 12 14208 92 13 13120 92 14 12224 93 15 11392 93 16 10688 94 17 10048 94 18 9536 94 19 9088 95 20 8576 95 21 8192 95 22 7808 95 23 7488 96 24 7168 96 25 6912 96 26 6592 96 27 6400 96
Tableau 5-2 Résultats obtenus avec l’approche du balayage séquentiel
77
1 3 5 7 9 11 13 15 17 19 21 23 25 270
20000
40000
60000
80000
100000
120000
140000
160000
180000
1 3 5 7 9 11 13 15 17 19 21 23 25 27
N bre transputers
Balayage
Figure 5-4 Représentation graphique des résultats (balayage séquentiel)
Ce graphique illustre les résultats obtenus en utilisant l’approche du balayage séquentiel.
Le temps d’exécution est inversement proportionnel au nombre de transputers car la
charge de traitement est répartie sur les différents transputers. On constate que cette
charge est uniformément répartie sur les transputers. Par exemple, en passant de 1 à 2
transputers, le temps d’exécution a diminué de moitié. Le gain est quasi optimal.
Cette représentation graphique démontre clairement que le parallélisme améliore
grandement les performances dans le cas du balayage séquentiel. En effet, sur un
échantillon de 30 000 tuples de la table EMPLOYE, le temps d’exécution passe de
168576 ms sur 1 transputer à 6400 ms sur 27 transputers, c’est-à-dire que le temps
d’exécution a été divisé par presque 27, ce qui est très intéressant.
78
Le graphique suivant illustre le pourcentage de gain apporté par le parallélisme dans le
cas du balayage séquentiel. Par exemple, en passant de 1 à 2 transputers, le pourcentage
de gain apporté par le parallélisme est de 50%.
1 3 5 7 9 11 13 15 17 19 21 23 25 270
102030405060708090
100
% G
ain
1 3 5 7 9 11 13 15 17 19 21 23 25 27
Nbre transputers
% Gain par rapport à un seul transputer (balayage)
Figure 5-5 Gain du parallélisme dans le cas du balayage séquentiel
Nous avons utilisé la formule suivante pour calculer le pourcentage de gain:
% Gain (n) = 100 - TTn
1 * 100
où :
n est le nombre de transputers,
T1 le temps d’exécution de l’approche du balayage séquentiel avec un transputer,
Tn le temps d’exécution de l’approche du balayage séquentiel avec n transputers.
On constate que le gain du parallélisme croît avec le nombre de transputers. En effet le
gain passe de 50% avec 2 transputers à 96% avec 27 transputers.
79
1 3 5 7 9 11 13 15 17 19 21 23 25 270
20000
40000
60000
80000
100000
120000
140000
160000
180000
1 3 5 7 9 11 13 15 17 19 21 23 25 27
N bre transputers
M ulti-index
Balayage
Figure 5-6 Comparaison graphique des résultats
Ce graphique illustre les résultats obtenus en utilisant l’approche du balayage séquentiel
versus l’approche de la multi-indexation. Dans les deux cas, le temps d’exécution est
inversement proportionnel au nombre de transputers. Ceci s’explique par le fait que la
charge de traitement est répartie sur les différents transputers.
On constate aussi que l’approche de la multi-indexation est plus performante que
l’approche du balayage séquentiel. En passant du balayage séquentiel à la multi-
indexation, le gain moyen est de 25% environ.
Le gain en performance apporté par le parallélisme est beaucoup plus important que le
gain apporté par la multi-indexation (50% en passant de 1 à 2 transputers versus 25% en
passant du balayage séquentiel à la multi-indexation).
80
Le graphique suivant illustre le pourcentage de gain apporté par la multi-indexation.
1 3 5 7 9 11 13 15 17 19 21 23 25 27
N bre de transputers
0
5
10
15
20
25
30
% G ain de la m ulti-indexation
Figure 5-7 Gain de la multi-indexation
Nous avons utilisé la formule suivante pour calculer le pourcentage de gain:
% Gain (n) = 100 - TmTb
* 100 ≈ 25 = constante
où :
n est le nombre de transputers,
Tb le temps d’exécution de l’approche du balayage séquentiel avec n transputers,
Tm le temps d’exécution de l’approche du balayage séquentiel avec n transputers.
On constate que le gain apporté par la multi-indexation par rapport au balayage
séquentiel est constant et est de l’ordre de 25% environ. C’est-à-dire que quel que soit le
nombre de transputers, le gain apporté par la multi-indexation est le même (25%).
En comparant les figures 4-8, 4-10 et 4-12 on constate que le gain du parallélisme croît
avec le nombre de transputers alors que le gain de la multi-indexation est constant.
81
5.3 ANALYSE DE L’EFFICACITÉ DES ALGORITHMES
5.3.1 DESCRIPTION
Lorsqu’on considère un problème, il peut être intéressant de trouver plusieurs
algorithmes pour le résoudre, afin d’utiliser le meilleur d’entre eux. Une question se pose
alors : comment déterminer lequel est préférable ? L’approche empirique consiste à
programmer ces algorithmes et à les essayer sur divers échantillons à l’aide d’un
ordinateur. L’approche théorique consiste à déterminer mathématiquement la quantité de
ressources (temps dans notre cas) nécessaire aux algorithmes en fonction de la taille des
échantillons considérés. Cette dernière approche a l’avantage de ne dépendre ni de
l’ordinateur, ni du langage de programmation, ni même de l’astuce du programmeur. Elle
permet d’éviter l’effort de programmer inutilement un algorithme inefficace. Elle permet
aussi de connaître l’efficacité des algorithmes étudiés quelle que soit la taille des
exemplaires sur lesquels ils auront à travailler, alors qu’on aurait peut-être tendance, avec
l’approche empirique, à ne comparer les algorithmes que sur des échantillons de taille
relativement modeste. Ce dernier point est particulièrement important puisqu’il est
fréquent de trouver un nouvel algorithme qui ne surclasse son prédécesseur que sur des
échantillons de taille substantielle.
Une question se pose naturellement : quelle unité utilise-t-on pour exprimer l’efficacité
théorique d’un algorithme ? Il n’est évidemment pas question d’exprimer le temps en
secondes, puisque nous ne disposons pas d’un ordinateur de référence. Une solution à
cela réside dans le principe d’invariance impliquant que deux implantations différentes
du même algorithme ne peuvent différer en efficacité que par une constante
multiplicative. Plus précisément, si deux implantations différentes prennent
respectivement t1(n) et t2(n) secondes pour résoudre un exemplaire de taille n, il y a
toujours une constante positive c telle que, pour tout n suffisamment grand, t1(n) ≤ ct2(n)
[Brassard 1987], [Akl 1989]. Ce principe reste valable quels que soient les ordinateurs
utilisés, indépendamment des langages de programmation et même de l’astuce des
programmeurs.
82
Nous dirons qu’un algorithme prend un temps dans l’ordre de n , c’est-à-dire t(n) ∈O(n),
s’il existe une constante positive c ainsi qu’une implantation de l’algorithme capable de
résoudre chaque exemplaire du problème en un temps borné supérieurement par cn
secondes, où n est la taille de l’exemplaire considéré. Par le principe d’invariance, toutes
les implantations de l’algorithme ont la même propriété, toutefois la constante
multiplicative peut varier d’une implantation à l’autre.
Nous nous proposons ci-après de procéder à une analyse des performances en distinguant
le cas moyen et le pire des cas et ce pour chacune des deux approches implantées (multi-
indexation et balayage séquentiel).
5.3.2 BALAYAGE SÉQUENTIEL
Dans tous les cas, le balayage séquentiel signifie un balayage linéaire de la table de
données. Avant de procéder à l’analyse de cette approche, commençons d’abord par
définir de façon formelle les données du problème à analyser.
Soient:
T: une table de données de cardinalité n,
P: le prédicat correspondant à la requête, composé de k prédicats simples,
P1..PN: les N transputers.
L’approche du balayage séquentiel implique un balayage séquentiel de toute la table de
données. Cette opération se traduit par une recherche linéaire et implique le coût suivant:
coût(balayage_séquentiel)=coût(recherche_linéaire) ∈ O(n),
car, avec cette approche, le prédicat P est testé pour chaque tuple de la table de données
T, c’est-à-dire pour les n tuples.
83
L’algorithme de recherche utilisé est le suivant:
Recherche_sequentiel_parallele (valeur, base[1..n])
1- Transmettre valeur aux N transputers ⇒ O(lg N)
2- La base de données base est subdivisée en N sous-bases de longueur nN
basei = base[(i-1) nN
+1..inN
]
basei est assignée au transputer Pi , 1 ≤ i ≤ N
Transmettre basei au transputer Pi ⇒ O(lg N)
3- La procédure de recherche séquentielle est appliquée à chaque sous-base basei par le
transputer Pi ⇒ O(nN
)
4- Puisque les éléments des sous-bases basei ne sont pas distincts, au plus les N
transputers trouvent valeur et retournent les résultats ⇒ O(lg N)
t(n) ∈ O(lg N+ nN
)
∴ t(n) ∈ O(n)
L'algorithme correspondant sera donc linéaire c’est-à-dire dans l’ordre de n.
84
5.3.3 MULTI-INDEXATION
L’algorithme correspondant à l’approche de la multi-indexation est plus complexe que
l’algorithme du balayage séquentiel. Le comportement de l’algorithme dépend des index
et de la requête considérée. Par conséquent, nous distinguons le cas moyen et le pire des
cas.
Commençons d’abord par définir de façon formelle les données du problème à analyser:
Soient:
T: une table de données de cardinalité n et sur laquelle sont définis m index,
P: le prédicat correspondant à la requête, composé de k prédicats simples,
P1..PN: les N transputers,
index1..indexm: les m index.
L’algorithme de recherche utilisé est le suivant:
Recherche_dichotomique_parallele (valeur, indexi[1..n])
1- Transmettre valeur aux N transputers. ⇒ O(lg N)
2- Les index sont subdivisés en N parties de longueur nN
indexij = indexi[(i-1) nN
+1..inN
]
indexij est assignée au transputer Pi, 1 ≤ i ≤ N
Transmettre indexij au transputer Pi ⇒ O(lg N)
3- La procédure de recherche dichotomique est appliquée à chaque indexij par le
transputer Pi ⇒ O(lgnN
)
4- Puisque les éléments des indexij ne sont pas distincts, au plus les N transputers
trouvent valeur et retournent les résultats ⇒ O(lg N)
t(n) ∈ O(lg N+ lgnN
)
∴ t(n) ∈ O(lg n)
85
5.3.3.1 CAS MOYEN
Dans le cas où l’algorithme est utilisé maintes fois, il pourrait être intéressant d’en
connaître le temps d’exécution en moyenne. C’est-à-dire qu’on exclut le cas où
l’algorithme requiert le plus de temps.
Avant de pouvoir utiliser les index, il faut d’abord les sélectionner et calculer leur
sélectivité. Donc, pour le calcul des coûts, on doit tenir compte des opérations suivantes:
1) Sélection des index éligibles: O(k x m). car on possède k prédicats simples de m index.
2) Calcul de la sélectivité des index : O(m). car on possède m index.
3) Calcul du coût d'utilisation des index : O(m). car on possède m index.
On a vu précédemment que cette approche n’est pas toujours applicable. Donc avant de
pouvoir l’utiliser il faut d’abord s’assurer qu’elle est effectivement possible. Et on doit
alors tenir compte du coût de cette opération.
coût(multi_indexation)=coût(si_applicable)+coût(recherche),
où :
• coût(si_applicable) est le coût nécessaire pour déterminer si l'approche de la
multi-indexation peut être appliquée. Ce coût englobe les coûts induits par les
opérations suivantes:
• Sélection des index éligibles.
• Calcul de la sélectivité des index éligibles.
• Calcul du coût des index éligibles.
• coût(recherche): est le coût nécessaire pour la recherche des RID des
tuples sélectionnés.
Si l'approche des index peut être appliquée, l'algorithme de recherche dichotomique est
choisi car la structure d'index est triée par rapport au champ d'indexation, sinon c'est
l'algorithme de recherche linéaire qui est choisi.
86
L'algorithme correspondant à une recherche linéaire sur une table de taille n est d'ordre n,
alors que celui correspondant à une recherche dichotomique est d'ordre log n, ceci
constitue un gain appréciable par rapport à la recherche linéaire.
Puisqu'il existe m index, l'approche de la multi-indexation nécessitera au pire m
recherches dichotomiques et par conséquent l'algorithme correspondant sera d'ordre m
log n avec m«n.
m peut être considérée comme une constante (facteur multiplicatif)
on aura alors: lim mn
loglog
n = m (constante positive)
n→∞
ceci implique que O(m log n) = O(log n)
L'algorithme est donc d'ordre logarithmique: O(log n)
87
Remarque
Ceci n'inclut évidemment pas le coût induit par l'évaluation du coût d'utilisation de
chaque index éligible. De plus on a considéré que les opérations booléennes OR et AND
sur les listes sont élémentaires (d'ordre constant).
5.3.3.2 PIRE DES CAS
Dans l’analyse en pire cas, on ne considère que le cas où l’algorithme requiert le plus de
temps. L’analyse en pire cas est parfaitement adéquate pour un algorithme dont le temps
de réponse est critique. S’il s’agit, par exemple, de contrôler une centrale nucléaire, il est
crucial de connaître une borne supérieure sur son temps de réponse.
coût(multi_indexation)=coût(si_applicable)+coût(recherche_linéaire).
Dans le pire des cas, l’utilisation de la multi-indexation n'est pas pertinente et l’approche
classique (balayage séquentiel) lui est préférable. Par exemple si on considére la requête
suivante: SELECT *
FROM EMPLOYE
WHERE Age=30 OR Service=20;
Si un index est défini sur l'attribut Age seulement, alors l’utilisation de la multi-
indexation est plus coûteuse que le balayage séquentiel. En effet, avec la première
approche, le SGBD utilise l’index défini sur l’attribut Age pour évaluer le prédicat
Age=30 et un balayage séquentiel de la table pour évaluer le prédicat Service=20 alors
qu’avec la seconde approche, il utilise seulement un balayage séquentiel de la table
EMPLOYE. Dans le cas de la première approche, il y a donc une perte de performance
due à une utilisation inutile de l’index.
88
5.4 SYNTHÈSE DE LA RÉALISATION
Dans le tableau ci-dessous sont présentés les processus ainsi que leurs principales tâches.
Le nom de chaque processus correspond au nom du programme. Tous les programmes
ont été réalisés en langage C Inmos.
Nom du processus
Principales tâches Nbre lignes
data.c Générer un échantillon de 30000 tuples de la table EMPLOYE 132 service.c Générer l’index index_service défini sur l’attribut Service 94
age.c Générer l’index index_age défini sur l’attribut Age 94
root.c
Lire index_service Lire index_age Envoyer les données lues au master.c Recevoir les résultats du master.c Afficher les résultats
120
master.c
Recevoir les données du root.c Distribuer les données aux dispatcha1.c à dispatcha3.c Recevoir les résultats des dispatcha1.c à dispatcha3.c Envoyer les résultats au root.c
115
dispatcha1.c à
dispatcha3.c
Recevoir les données du master.c Distribuer les données aux dispatchb1.c à dispatchb9.c Recevoir les résultats des dispatchb1.c à dispatchb9.c Envoyer les résultats au master.c
106
dispatchb1.c à
dispatchb9.c
Recevoir les données des dispatcha1.c à dispatcha3.c Distribuer les données aux slave1.c à slave27.c Recevoir les résultats des slave1.c à slave27.c Envoyer les résultats aux dispatcha1.c à dispatcha3.c
126
slave1.c à
slave27.c
Recevoir les données des dispatchb1.c à dispatchb9.c Exécuter l’approche de la multi-indexation Envoyer les résultats aux dispatchb1.c à dispatchb9.c
232
Tableau 5-3 Description des processus
89
Dans la figure ci-dessous est présentée l’arborescence des processus. Chaque processus
est exécuté sur un transputer.
Les processus slave1.c à slave27.c sont exécutés sur les transputers T1 à T27.
Les processus dispatchb1.c à dispatchb9.c sont exécutés sur les transputers T28 à T36.
Les processus dispatcha1.c à dispatcha3.c sont exécutés sur les transputers T37 à T39.
Le processus master.c est exécuté sur le transputer T40.
Le processus root.c est exécuté sur le transputer T41.
Les processus data.c, service.c et age.c sont exécutés sur la machine hôte (Sun).
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 25 262422 23 27
28 29 30 31 32 33 34 35 36
38 39
40
41
������������ Host
master.c
root.c
dispatcha1.c dispatcha2.c dispatcha3.c
dispatchb1.c dispatchb4.c dispatchb5.cdispatchb3.cdispatchb2.c dispatchb6.c dispatchb7.c dispatchb8.c dispatchb9.c
(Sun)
slave1.c àslave3.c
slave4.c àslave6.c
slave7.c àslave9.c
slave10.c àslave12.c
slave13.c àslave15.c
slave16.c àslave18.c
slave19.c àslave21.c
slave22.c àslave24.c
slave25.c àslave27.c
37
Figure 5-8 Arborescence des processus
90
CONCLUSION
Parmi les principales approches utilisées pour accéder à une base de données, nous en
avons étudiées et comparées deux : le balayage séquentiel et la multi-indexation.
La première (balayage séquentiel) est coûteuse, en particulier dans le cas où les tables de
données sont volumineuses mais elle peut être utilisée sans aucune restriction. De plus,
elle est facilement réalisable sur le plan pratique (algorithme de recherche linéaire).
La seconde (multi-indexation) est performante mais son utilisation est contraignante car
elle suppose l'existence d'un ou plusieurs index. Une autre limite importante de cette
approche est que l’utilisation d’une fonction sur un attribut du prédicat élimine
automatiquement la possibilité d’utiliser l’index défini sur cet attribut. L'algorithme
correspondant à cette approche est récursif et heuristique et, par conséquent, plus
complexe que le précédent. Avec cette approche, on augmente la complexité de
l'algorithme mais on diminue de façon significative le coût (de O(n) à O(log n)), c’est-à-
dire que le gain réalisé sur le coût est obtenu au prix d’une forte augmentation de la
complexité de l'algorithme.
En guise de perspective à ce travail, il serait intéressant d’étudier la possibilité d’estimer
le taux d’utilisation de chaque attribut référencé dans les prédicats des requêtes. En fixant
un seuil critique judicieux pour ce taux (dont les modalités de détermination resteraient à
explorer), l’idée serait alors de créer automatiquement un index sur l’attribut dont le taux
d’utilisation dépasserait ce seuil.
91
BIBLIOGRAPHIE
[Akl 1989] Selim G. Akl, The Design and Analysis of Parallel Algorithms, Prentice-Hall
Inc., New Jersey, USA, 1989.
[Alex 1991a] VOLVOX Machine User’s Manual, Alex Informatique Inc., Montréal,
Canada, 1991.
[Alex 1991b] Transputer Architecture, Alex Informatique Inc., Montréal, Canada, 1991.
[Benameurlaine 1995] Hakim Benameurlaine, Oracle et la Multi-indexation. Oracle
User Group of Eastern Canada, Vol. 15(4) (1995), 15-16.
[Blasgen & Eswaran 1976] Blasgen, M., and Eswaran, K., On the Evaluation of Queries
in a Relational Data Base System. IBM Research Report RJ1745, IBM San Jose
Research Laboratory, (1976).
[Blasgen & Eswaran 1977] Blasgen, M., and Eswaran, K., Storage and Access in
Relational Databases. IBM Systems Journal, Vol. 16(4) (1977), 363-377.
[Brassard 1987] G. Brassard et P. Bratley., Algorithmique : Conception et Analyse. Les
Presses de l’Université de Montréal, Canada, 1987.
[Flynn 1966] M. J. Flynn, Very High-Speed Computing Systems, Proceedings of the
IEEE, 54 (1966), 1901-1909.
[Hogan 1990] Rex Hogan. A Practical Guide to Data Base Design, Prentice Hall, New
Jersey, 1990.
[Inmos 1990a] ANSI C toolset reference manual, D0214-DOCA, Inmos limited, Bristol,
Royaume-Uni, 1990.
[Inmos 1990b] ANSI C toolset user manual, D0214-DOCA, Inmos limited, Bristol,
Royaume-Uni, 1990.
[Limane 1989] A. Abdellatif, J. Le Bhan et Mohamed Limane. Oracle le Système de
Gestion de Bases de Données Relationnel, Les Éditions Eyrolles, Paris, 1989.
92
[Mohan & al 1990] Mohan, C., Haderle, D., Wang Y., & Cheng, J., Single Table Access
Using Multiple Indexes: Optimisation, Execution, and Concurrenty Control
Techniques, in Advances in Database Technology-EDBT’90 International
Conference on Extending Database Technology, Goos et al., (Eds.), Venise,
Italy, 1990, pp.29-43.
[Neil 1987] O'Neil, P. MODEL 204 Architecture and Performance, Proc. 2nd
International Workshop on High Performance Transaction Systems, Asilomar,
September 1987. Also in Lecture Notes In computer Science Vol. 359, D.
Gawlick, M. Haynie, A. Reuter (Eds.), Springer-Verlag, 1989.
[Neil 1989] O'neil, P. A set Query Benchmark for large Databases, Proc. CMG
Conference, Reno, December 1989.
[Oracle 1992a] Application Developer’s Guide, Oracle Corporation, Redwood City,
California USA, 1992.
[Oracle 1992b] Server Administrator’s Guide, Oracle Corporation, Redwood City,
California USA, 1992.
[Oracle 1992c] SQL Langage Reference Manual, Oracle Corporation, Redwood City,
California USA, 1992.
[Oracle 1992d] Concepts Manual, Oracle Corporation, Redwood City, California USA,
1992.
[Rosenthal & Reiner 1982] Rosenthal, A.,and Reiner, D. An Architecture For Query
Optimization, Proc. ACM-SIGMOD Iternational Conference on Management of
Data, Orlando, June 1982.
[Selinger & al 1979] Selinger, P., Astrahan, M., Chamberlin, D., Lorie, R., Price, T.
Access Path Selection in a Relational Database Management System, Proc,
ACM-SIGMOD International Conference on Management of Data, Boston, June
1979.
93