HAKIM BENAMEURLAINE ACCÈS À UNE TABLE...

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

- 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 :


2 SELECT Nom

3 FROM EMPLOYE

4 WHERE Age = 30;

Explained.


------------------------------------- -------------------- --------------------


TABLE ACCESS BY ROWID EMPLOYE


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

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").


SQL>EXPLAIN PLAN FOR

2 SELECT *

3 FROM EMPLOYE

4 WHERE ROWID='000003D7.0002.0007';

Explained.


------------------------------------- -------------- --------------------



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.



2 SELECT *

3 FROM EMPLOYE

4 WHERE Service = 30 OR Service = 40;

Explained.


------------------------------------- -------------- --------------------


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.



2 SELECT *

3 FROM EMPLOYE

4 WHERE Age = 30;

Explained.


------------------------------------- -------------------- --------------------




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.



2 SELECT *

3 FROM EMPLOYE

4 WHERE Sexe='M';

Explained.


------------------------------------- -------------- --------------------


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,


⇒ 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:


2 SELECT *

3 FROM EMPLOYE

4 WHERE Age > 40 AND Service > 20;

Explained.


------------------------------------- ------------------ --------------------



AND-EQUAL


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:


= 100% ⇒I1 est éligible pour tous les prédicats simples de la

requête.


= 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,


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é:


= 13

,

41


= 12

,


,


= 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}.


Étape a)

Index éligibles pour les prédicats conjonctifs simples:






index éligibles: {I1, I2, I3, I4, I5}.



,


,


,


,


,

Étape b) 43

Index éligibles pour les prédicats disjonctifs simples:



I3 non éligible,


I5 non éligible,

index éligibles: {I1, I2}.



,


,

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),

stratégie2={I1, I2, I1}={I1, I2}= stratégie1,

stratégie2={I1, I2, I5},


>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


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



2 SELECT Nom

3 FROM EMPLOYE

4 WHERE Age > 50 OR Service > 25;

Explained.




OR-EQUAL


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:




prédicats disjonctifs simples : {P1, P2},

prédicats conjonctifs simples : {P3, P4},

index éligibles : {I1, I2, I3}.


a) Recherche des index éligibles pour les prédicats disjonctifs simples:

index_éligible(P1) = {I1},

index_éligible(P2) = {I2},


= 25%,


= 25%,

b) Cas des prédicats conjonctifs:

index éligibles : {I3},


= 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


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







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


% Gain (n) = 100 - TTn

1 * 100

où :


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


% Gain (n) = 100 - TmTb

* 100 ≈ 25 = constante

où :


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






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,


[Oracle 1992c] SQL Langage Reference Manual, Oracle Corporation, Redwood City,


[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

HAKIM BENAMEURLAINE ACCÈS À UNE TABLE...

Documents

Transcript of HAKIM BENAMEURLAINE ACCÈS À UNE TABLE...