Cahier des charges - DbManager

DB Manager
Duvert Alexandre
Lefebvre Thomas
Pieters Aimeric
18 novembre 2005
Levens Jérémy
Table des matières
1 Le groupe
1.0.1
1.0.2
1.0.3
1.0.4
3
Duvert Alexandre - Dudu
Lefebvre Thomas - Leus .
Levens Jérémy - Matt . .
Pieters Aimeric - Papy . .
. . . . . . . . . . . . . . . . . . . . . . .
3
. . . . . . . . . . . . . . . . . . . . . . .
3
. . . . . . . . . . . . . . . . . . . . . . .
3
. . . . . . . . . . . . . . . . . . . . . . .
3
2 DB Manager
2.1
2.2
5
Présentation du logiciel
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.1.1
Qu'est qu'un système de gestion de bases de données ? . . . . . . . .
5
2.1.2
Techniques de stockage . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.1.3
L'indexation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.1.4
Evaluation de requêtes . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.1.5
Pour nir...
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
Pourquoi un SGBD ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
3 Les fonctionnalités du logiciel
7
3.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.2
La création d'une nouvelle base . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.3
L'utilisation d'une base existante
3.3.1
3.4
. . . . . . . . . . . . . . . . . . . . . . . .
8
Utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
Importation/exportation d'une base
. . . . . . . . . . . . . . . . . . . . . .
3.4.1
Importation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.4.2
Exportation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
4 Les besoins algorithmiques
4.1
4.2
9
10
La gestion chiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
4.1.1
Avant-propos ! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
4.1.2
Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
4.1.3
Pourquoi notre organisation de chier ? . . . . . . . . . . . . . . . . .
11
4.1.4
La répartition des données sur le disque
. . . . . . . . . . . . . . . .
12
Structures de données pour l'indexation
4.2.1
4.2.2
. . . . . . . . . . . . . . . . . . . .
13
Indexation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
4.2.1.1
Introduction
13
4.2.1.2
Index non-dense
. . . . . . . . . . . . . . . . . . . . . . . .
14
4.2.1.3
Index dense . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
4.2.1.4
Index multi-niveaux
17
Les arbres-B
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.2.1
Présentation
. . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.2.2
Pourquoi les arbres-B ?
1
. . . . . . . . . . . . . . . . . . . .
18
18
18
DB Manager par Nomdegroupe
Info-Spé
18.11.2005
Promo 2009
4.2.3
4.3
4.2.2.3
Fonctions à implémenter
. . . . . . . . . . . . . . . . . . .
19
4.2.2.4
Aspect technique . . . . . . . . . . . . . . . . . . . . . . . .
19
Les tables de hachage
. . . . . . . . . . . . . . . . . . . . . . . . . .
20
4.2.3.1
Présentation
. . . . . . . . . . . . . . . . . . . . . . . . . .
20
4.2.3.2
Pourquoi les tables de hachage ?
. . . . . . . . . . . . . . .
20
4.2.3.3
Fonctions à implémenter
. . . . . . . . . . . . . . . . . . .
21
4.2.3.4
Aspect technique . . . . . . . . . . . . . . . . . . . . . . . .
21
L'optimisation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
4.3.1
Algorithmes utlisés . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
4.3.2
Algorithmes de base
22
4.3.3
Sélection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
4.3.4
Tri externe
23
4.3.5
Les algorithmes de jointure
4.3.6
En bref
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
23
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
5 Les Ressources matérielles
25
5.1
Nos congurations
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
5.2
Le Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
6 Le Site web : dbmanager.free.fr
6.1
6.2
Présentation du site
26
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
6.1.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
6.1.2
Accueil / News . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
6.1.3
Le groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
6.1.4
Présentation du logiciel
. . . . . . . . . . . . . . . . . . . . . . . . .
26
6.1.5
Planning et répartition des tâches . . . . . . . . . . . . . . . . . . . .
26
6.1.6
Les soutenances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
6.1.7
Téléchargements
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
Les Ressources
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
6.2.1
Logiciels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
6.2.2
Hébergement
27
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 Le Planning des soutenances
28
2
Chapitre 1
Le groupe
1.0.1
Duvert Alexandre - Dudu
Pour ma part, le projet de cette année sera l'occasion de me familiariser avec la programmation sous système UNIX. Ce qui constituera pour moi une expérience de développement
autre que celle sous windows. De plus, cette année sera l'occasion de mener le projet à
son terme, ce qui n'était pas le cas l'année dernière. Ce projet a, à mon avis, un intérêt
certain par le fait qu'il met en application des concepts vus en cours d'algorithmique. Cela
sera également une opportunité d'améliorer mes conaissances qui n'ont pas pu être très
consolidées l'année précédente en raison de la relative diculté que l'on a eu à mener tant
bien que mal notre projet.L'étude des bases de données est également un point positif pour
la suite de nos études. Enn, l'ambiance dans le groupe sera nettement plus propice au
travail cette année.
1.0.2
Lefebvre Thomas - Leus
Je suis content de faire partie de ce groupe de projet parce qu'après un an passé à
EPITA on connaît beaucoup mieux les personnes avec lesquelles on travaille et on a de
grandes chances de passer une bonne année en travaillant. Pour ce qui est des bases de
données j'ai commencé à m'y intéresser en sup où je me suis fait un logiciel en delphi pour
classer ma médiathèque avec une base de données Paradox 7 sans, à l'époque, regarder
tout ce qu'il y a derrière.
1.0.3
Levens Jérémy - Matt
Pour ma part, j'ai déjà eu l'occasion de travailler en groupe, avec des professionnels,
pour le développement d'un projet. C'est donc pour moi une chance de pouvoir appliquer ce
que j'ai pu apprendre durant cette expérience. J'ai comme tout le monde le niveau SUP+1
et j'ai développé pendant l'été un logiciel (gestionnaire dynamique de contenu) actuellement
en vente (déjà quelques exemplaires vendus !). Enn, j'ai, pendant les 5 dernières années,
mis en place un holding accessible à l'adresse : http ://www.groupceltec.com. Pour nir
cette présentation, je suis très heureux de me retrouver avec des mecs super sympas cette
année...
1.0.4
Pieters Aimeric - Papy
Bien le bonjour, braves gens ! Mon cv est loin d'être glorieux. Niveau SPE, ma seule
expèrience de travail en groupe se résume au projet développé en SUP. Ce projet n'a pas
3
DB Manager par Nomdegroupe
Info-Spé
18.11.2005
Promo 2009
abouti et s'est plutôt mal passé (conits au sein du groupe...). Je n'ai donc pas ou peu
d'expérience en travail de groupe et développement de projets.
Malgré cela, je suis très heureux de faire partie de ce groupe, il me semble que cela va
bien mieux se passer que l'année dernière, je suis, enn, tombé avec des gens travaileurs.
Je suis donc particulièrement heureux de participer à cette aventure avec des camarades
aussi sympas et rigolards.
4
Chapitre 2
DB Manager
2.1 Présentation du logiciel
2.1.1 Qu'est qu'un système de gestion de bases de données ?
Qu'est-ce qu'une donnée ? C'est une information quelconque comme, par exemple :
voici une personne, elle s'appelle Jean. C'est aussi une relation entre des informations :
Jean enseigne les bases de données. Des relations de ce genre dénissent des structures.
Une base de données est un ensemble, en général volumineux, de telles informations, avec
une caractéristique essentielle : on souhaite les mémoriser de manière permanente.
Un ensemble de chiers ne présentant qu'une complexité assez faible, il n'y aurait pas
là matière à longue dissertation. Malheureusement l'utilisation directe de chiers soulève
de très gros problèmes, comme par exemple : lourdeur d'accès aux données. En pratique,
pour chaque accès, même le plus simple, il faudrait écrire un programme.
D'où le recours à un logiciel chargé de gérer les chiers constituant une base de données, de prendre en charge les fonctionnalités de protection et de sécurité et de fournir les
diérents types d'interface nécessaires à l'accès aux données. Une des tâches principales du
SGBD est de masquer à l'utilisateur les détails complexes et fastidieux liés à la gestion de
chiers.
Pour faire simple, un Système de Gestion de Bases de Données (SGBD) est un logiciel de
haut niveau qui permet de manipuler les informations stockées dans une base de données.
La complexité d'un SGBD est essentiellement issue de la diversité des techniques mises
en oeuvre, de la multiplicité des composants intervenant dans son architecture, et des
diérents types d'utilisateurs (administrateurs, programmeurs, non informaticiens, ...) qui
sont confrontés, à diérents niveaux, au système.
Voici les diérentes structures qui seront prises en charge par notre sgbd :
Les techniques de stockage : sur disque (optique).
L'organisation des chiers : index, arbre-B, hachage, ...
Les techniques d’évaluation et d'optimisation de requêtes.
2.1.2 Techniques de stockage
Une base de données est constituée, matériellement, d'un ou plusieurs chiers volumineux stockés sur un support non volatile. Le support le plus couramment employé est le
disque magnétique (disque dur).
L'accès à des données stockées sur un périphérique, par contraste avec les applications
qui manipulent des données en mémoire centrale, est une des caractéristiques essentielles
d'un SGBD. Elle implique notamment des problèmes potentiels de performance puisque le
5
DB Manager par Nomdegroupe
Info-Spé
18.11.2005
Promo 2009
temps de lecture d'une information sur un disque est considérablement plus élevé qu'un
accès en mémoire principale.
L'organisation des données sur un disque : un bon système se doit d'utiliser au mieux
les techniques disponibles an de minimiser les temps d’accès. Il doit aussi orir à l'administrateur des outils de paramétrage et de contrôle qui vont lui permettre d'exploiter au
mieux les ressources matérielles et logicielles d'un environnement donné. Cette gestion de
la mémoire et des accès disque sera un des points clés de Dbmanager car c'est de cette
gestion et de ses relations avec les systèmes d'indexation, de recherche, de suppression...
que dépend le bon rapport qualité prix de l'utilisation du logiciel, c'est-à-dire sa rapidité
et son confort d'utilisation.
De ce point nous pouvons poursuivre notre présentation en abordant le système d'indexation du logiciel.
2.1.3 L'indexation
les structures d'indexation mises en oeuvre et les algorithmes de recherche utilisés
constituent donc des aspects très importants des SGBD. En eet, à partir des structures
d'index on organise la prise en charge des données et donc des critères de recherche, suppresion, insertion ... et de leur optimisation.
Les index rangent les chiers au mieux des attentes de l'utilisateur et de là on en déduit
les principes des diérents alogorithmes de gestion des chiers.
La principale caractéristique d'un sgbd est d'évaluer les demandes de l'utilisateur.
2.1.4 Evaluation de requêtes
Lorsque l'utilisteur va utiliser le logiciel, celui-ci va analyser ses demandes et y répondre
de la façon la plus ecace possible. De cette évaluation dépend la qualité des relations entre
le logiciel et son hôte.
De cette structure découle toutes les relations entre les diérentes parties du programme. De là on construit une toile d'araignée où le centre est représenté par l'utilisateur.
Une part importante de ce sytème résulte dans la gestion de l'optimisation.
2.1.5 Pour nir...
Nous venons donc de vous présenter Dbmanager : ce qu'il sera, son rôle, sa fonctionnalité
et sa composition.
Le détail de sa structure sera développé plus loin dans le cahier des charges.
2.2 Pourquoi un SGBD ?
Pour notre année d'info Spe, nous avons pris la décision de nous attaquer à un projet
colossal qui implique la maîtrise de plusieurs algorithmes, certains étant vus en cours,
d'autres pas. Aussi, le fait de vouloir coder un Système de Gestion de Bases de Données
Relationnelles (SGBDR) s'inscrit dans l'optique des services fréquemment demandés en
entreprise, à savoir l'utilisation et la réorganisation de bases de données existantes, ou bien
la création de nouvelles BDD performantes. C'est pourquoi il nous a paru intéressant de
concevoir, sans prétention, notre SGBDR.
6
Chapitre 3
Les fonctionnalités du logiciel
3.1 Introduction
Les sections suivantes vont vous présenter les diérentes fonctionnalités de Dbmanager.
Pour ce faire, nous avons pris l'exemple de Phpmyadmin étant donné que le logiciel n'existe
pas encore.
3.2 La création d'une nouvelle base
Db manager aura bien évidemment une fonctionnalité permettant de créer une base de
données. C'est à se moment précis que l'utilisateur créé des champs qui composeront notre
future base. Voici un exemple d'interface permettant de crée une base.
L'utilisateur a le choix entre plusieurs types de données pour chaque champ (entier,
char, etc...). Etant donné que, par exemple, les entiers et les charactères n'occupent pas
le même espace mémoire ces types de données seront importants car ils détermineront la
taille nécessaire à un enregistrement de la base de données.
7
DB Manager par Nomdegroupe
Info-Spé
18.11.2005
Promo 2009
3.3 L'utilisation d'une base existante
3.3.1 Utilisation
Pour cette partie,nous ferons une interface aussi sobre que possible. Aussi, nous élaborerons une interface utilisateur qui regroupe ce dont a besoin l'utilisateur sans le submerger d'options. Ainsi,l'interface regroupera les fonctionnalités nécessaires à la création,la
suppression,le renommage d'éléments ou de bases,la migration de données d'une base à
l'autre.Le but étant ici de mettre l'accent sur une utilisation immédiate et intuitive.
8
DB Manager par Nomdegroupe
Info-Spé
18.11.2005
Promo 2009
Nous procéderons également à la mise en oeuvre d'une fenêtre qui permettra à l'utilisateur de lancer des commandes SQL.Il est vraisemblable que cette fenêtre contiendra des
requêtes prédénies dont il sera possible de changer les paramètres en fonction de l'usage
désiré.Il sera également possible d'acher le contenu de la base dans une fenêtre an de
voir ce qui est contenu dans celle-ci.
3.4 Importation/exportation d'une base
3.4.1 Importation
L'importation de bases de données se découpera en deux options :
importation dans une base existante ;
importation basique d'une base propre à elle-même ;
Bien sûr on ne pourra importer que des bases dont l'extention est gérée par Dbmanager.
3.4.2 Exportation
L'exportation d'une base de données se fera avec les formats suivant :
SQL ;
Latex ;
XML ;
Nous avons choisi ces formats car ce sont ceux qui nous seront le plus utiles et que ce
sont des formats standarts trés utilisés en informatique.
Le choix des formats sera amené à être modié suivant les besoins et les diérents
problèmes rencontrés lors du développement du logiciel.
9
Chapitre 4
Les besoins algorithmiques
4.1 La gestion chiers
4.1.1 Avant-propos !
Avant de parler de comment et de pourquoi un module de gestion de chier il convient
de se demander avec quoi on va travailler pour bien comprendre le but de ce module. Une
base de données n'étant rien d'autre qu'un ensemble de données stockées sur un support
persistant prennons comme base de départ un disque dur sur lequel seront stockées les
données de notre base.
Un disque est une surface circulaire magnétisées capable d'enregistrer des valeurs numériques. Il se constitue d'un axe, autour duquel tourne plusieurs disques, et d'un bras xe
portant la tête de lecture qui permet de récupérer les données du disque et d'en insérer
des nouvelles. Le disque est découpé en pistes qui elles-mêmes le sont en secteurs dont la
taille est généralement 512 octets. Les données sont repérés sur un disque par une adresse
qui permet à la tête de lecture de déterminer exactement où cela se trouve sur le disque.
Le disque n'a pas toutes s'est données d'un seul tenant sinon il serait plus compliqué de
trouver les données. Il y a tout d'abord les pistes comme indiqués sur le schéma. Ensuite
sur ces pistes les données sont découpées en secteurs qui correspondent à la taille minimale que va pouvoir lire une tête de lecture (le plus souvent 512 octets). Cela étant le
10
DB Manager par Nomdegroupe
Info-Spé
18.11.2005
Promo 2009
système d'exploitation peut choisir, au moment de l'initialisation du disque, de xer une
unité d'entrée/sortie supérieure à la taille d'un secteur, et multiple de cette dernière. On
obtient des blocs, dont la taille est typiquement 512 octets (un secteur), 1024 octets (deux
secteurs) ou 4096 octets (huit secteurs). Chaque piste est donc divisée en blocs (ou pages)
qui constituent l'unité d'échange entre le disque et la mémoire principale.
Maintenant que nous savons avec quoi nous allons travailler nous pouvons passer à la
présentation de notre futur module de gestion de chiers. Au travail !
4.1.2 Présentation
Du point de vue du SGBD un chier est une liste de blocs répartient sur le disque. Le
SGBD a besoin d'accéder le plus rapidement possible à la donnée qu'il demande. Le rôle
principal du module de gestion de chers va être d'organiser au mieux les données sur le
disque de telles sortes qu'il limite l'utilisation de ressources :
En espace : La situation optimale est celle où la taille d'un chier est la somme des
tailles des enregistrements du chier. Cela implique qu'il y ait peu, ou pas, d'espace
vide dans le chier.
En temps : Une bonne organisation doit favoriser les opérations sur un chier. En
pratique, on s'intéresse plus particulièrement à la recherche d'un enregistrement,
notamment parce que cette opération conditionne l'ecacité de la mise à jour et de
la destruction. Il ne faut pas pour autant négliger le coût des insertions.
L'idéal est de trouver un bon compromis permettant de réaliser les opérations suivantes
de la manières la plus économiques en ressources (espace et temps) :
Ajout d'une nouvelle donnée
Recherche d'une donnée
Suppression d'une donnée présente
Modication d'une donnée
Un module de gestion de chiers s'occupe de l'organisation des données à l'intérieur
de notre chiers. Un disque étant une mémoire à accès direct il est possible d'accéder à
un information située n'importe où sur le disque sans avoir à parcourir séquentiellement
tout le support. L'accès direct est fondé sur une adresse donnée à chaque bloc au moment
de l'initialisation du disque par le système d'exploitation. Cette adresse est généralement
composée des trois éléments suivants :
Le numéro du disque dans la pile ou le numéro de la surface si les disques sont à
doubles-faces
Le numéro de la pistes
Le numéro du bloc sur la piste
Il ne faut pas oublier qu'un système d'exploitation (Unix par hasard) possède son
propre système de chier donc en théorie le SGBD pourrait utiliser la gestion de chier du
système d'exploitation. On pourrait donc se demander pourquoi on n'utilise pas la gestion
de chiers du système d'exploitation...
4.1.3 Pourquoi notre organisation de chier ?
Il y a un problème qui fait que l'on ne peut pas utiliser cette gestion pour notre SGBD.
Partons du principe qu'un chier (lorsqu'il dépasse d'un bloc) est fragmenté. En clair il est
coupé en petit bout qui se retrouve plus ou moins chacun à un bout du disque (windows
power). Je vais essayer d'expliquer en quoi cela nous chagrine pour notre SGBD.
Rapellons tout d'abord que la lecture d'un bloc, étant donné son adresse, se décompose
en trois étapes :
11
DB Manager par Nomdegroupe
Info-Spé
18.11.2005
Promo 2009
Positionnement de la tête de lecture sur la piste contenant le bloc
Rotation du disque pour attendre que le bloc passe sous la tête de lecture (rappelons
que les têtes sont xe, c'est le disque qui tourne)
Transfert du bloc
Ainsi pour lire une donnée il faut additionner les temps consacrés à ces trois opérations.
On considère que le temps de transfert est négligeable pour un bloc mais qu'il peu devenir
important dans la mesure où on demande une grande quantité de données.
Pour ce qui est du temps d'accès à la données par rotation une fois sur la bonne piste
il faut prendre en compte le fait que la quantité de bloc par piste n'est pas constante.
Prennons pour exemple un disque dur ayant les caractéristiques suivantes :
Capacité
Performance
Capacité
9.1 Go
Taux de transfert
80Mo/s
Cache
1Mo
Nombre de disques
3
Nombre de tête
6
Nombre total de secteurs (512 octets
17 783 438
Nombre de cylindre
9 772
Vitesse de rotation
10000 tours/min
Délai de latence
3ms en moyenne
Temps de positionnement moyen
5.2 ms
Déplacement de piste à piste
0.6 ms
Sachant que le temps d'accès à la mémoire vive est de l'ordre du nanoseconde on
remarque que l'accès disque est énorme et plus particulièrement le temps de positionnement
sur la piste. Le travail du module de gestion de chier va être de diminuer au maximum le
nombre de changements de pistes. Pour cela il va falloir répartir les données d'une certaine
manière pour que la tête de lecture reste sur la même piste : l'allocation contiguë.
4.1.4 La répartition des données sur le disque
Pour que la lecture de donnée soit la plus rapide possible il faut que les données soit
les plus proches possibles et dans le cas idéal sur la même piste. Pour que cela soit possible
il va falloir organiser nos données par une allocation contiguë. Cette technique a pour
but qu'il n'y ai aucun bloc de vide entre deux blocs. C'est à dire que la tête de lecture
pourra lire toutes les données de notre base de données tout en optimisant un maximum
les changements de pistes et les temps de latence.
Pour commencer le programme se réserve un espace sur le disque dont il s'occupera de
la gestion. Ensuite il existe plusieurs méthode d'allocation contiguë.
Le ramasse-miettes :
0
5
1
1
Durand
4
1
2
Dupond
/
1
3
Duroc
1
1
4
Dufour
2
1
5
12
DB Manager par Nomdegroupe
Info-Spé
18.11.2005
Promo 2009
Pour utiliser cette structure on garde un pointeur sur le premier élément (ici 3). Le
champ situé après le nom correspond au 'Suivant'. Lorsque l'on veut allouer il faut rechercher le premier libre, y insérer l'élément et placer l'indicateur d'occupation à 1. Pour
désallouer il sut de mettre à 0 le champ d'occupation. On n'appel le ramasse-miettes
(régénération du tableau ou du chier) que l'orsque qu'il y saturation de l'espace. Cela
rend cette méthode peu ecace car elle entraine de très nombreux accès disque ce qui est
à éviter dans notre cas.
La table d'occupation
0
Durand
3
1
Dupond
/
2
Duroc
0
3
Dufour
1
4
Table d'occupation :
1
1
1
1
Cete méthode est beaucoup plus adaptée car en réunissant la table d'occupation dans
un autre chier on peut facilement la charger en mémoire centrale avant l'utlisation du
chier. On évite ainsi de nombreux accès disque pour allouer et désallouer. Ainsi pour
allouer il sut simplement de parcourir la table d'allocation en cherchant le premier 0.
C'est donc pour l'instant la meilleur méthode qui a été trouvée.
4.2 Structures de données pour l'indexation
4.2.1 Indexation
4.2.1.1 Introduction
Quand une table est volumineuse, un parcours séquentiel est une opération relativement
lente et pénalisante pour l'exécution des requêtes, notamment dans le cas des jointures où
ce parcours séquentiel doit parfois être eectué répétitivement. La création d'un index
permet d'améliorer considérablement les temps de réponse en créant des chemins d'accès
aux enregistrements beaucoup plus directs. Un index permet de satisfaire certaines requêtes
(mais pas toutes) portant sur un ou plusieurs attributs (mais pas tous). Il ne s'agit donc
jamais d'une méthode universelle qui permettrait d'améliorer indistinctement tous les types
d'accès à une table.
L'index peut exister indépendamment de l'organisation du chier de données, ce qui
permet d'en créer plusieurs si on veut être en mesure d'optimiser plusieurs types de requêtes.
En contrepartie la création sans discernement d'un nombre important d'index peut être
pénalisante pour le SGBD qui doit gérer, pour chaque opération de mise à jour sur une
table, la répércussion de cette mise à jour sur tous les index de la table. Un choix judicieux
des index, ni trop ni trop peu, est donc un des facteurs essentiels de la performance d'un
système.
13
DB Manager par Nomdegroupe
Info-Spé
18.11.2005
Promo 2009
Le principe de base d'un index est de construire une structure permettant d'optimiser
les recherches par clé sur un chier. Le terme de clé doit être compris ici au sens de critère
de recherche, ce qui dière de la notion de clé primaire d'une table. Les recherches par clé
sont typiquement les sélections de lignes pour lesquelles la clé a une certaine valeur. Par
exemple :
SELECT *
FROM Film
WHERE titre = Vertigo
La clé est ici le titre du lm, que rien n'empêche par ailleurs d'être également la clé
primaire de la table. En pratique, la clé primaire est un critère de recherche très utilisé.
Outre les recherches par valeur, illustrées ci-dessus, on veut fréquemment optimiser des
recherches par intervalle. Par exemple :
SELECT *
FROM Film
WHERE annee BETWEEN 1995 AND 2002
Ici la clé de recherche est l'année du lm, et l'existence d'un index basé sur le titre ne
sera d'aucune utilité. Enn les clés peuvent être composées de plusieurs attributs, comme,
par exemple, les nom et prénom des artistes.
SELECT *
FROM Artiste
WHERE nom = Alfred AND prenom=Hitchcock
Pour toutes ces requêtes, en l'absence d'un index approprié, il n'existe qu'une solution
possible : parcourir séquentiellement le chier (la table) en testant chaque enregistrement.
Un index permet d'éviter ce parcours séquentiel. La recherche par index d'eectue en
deux étapes :
le parcours de l'index doit fournir l'adresse de l'enregistrement ;
par accès direct au chier en utilisant l'adresse obtenue précédemment, on obtient
l'enregistrement (ou le bloc contenant l'enregistrement, ce qui revient au même en
terme de coût).
4.2.1.2 Index non-dense
Nous commençons par considérer le cas d'un chier trié sur la clé primaire (il n'y
a donc qu'un seul enregistrement pour une valeur de clé). Dans ce cas restreint il est
possible d'eectuer une recherche par dichotomie qui s'appuie sur une division récursive du
chier, avec des performances théoriques très satisfaisantes. En pratique la recherche par
dichotomie suppose que le chier est constitué d'une seule séquence de blocs, ce qui permet
à chaque étape de la récursion de trouver le bloc situé au mileu de l'espace de recherche.
Si cette condition est facile à satisfaire pour un tableau en mémoire, elle l'est beaucoup moins pour un chier occupant plusieurs dizaines, voire centaines de mégaoctets. La
première structure que nous étudions permet d'eectuer des recherches sur un chier triés,
même si ce chier est fragmenté.
L'index est lui-même un chier, contenant des enregistrements [valeur, Adr] où valeur
désigne une valeur de la clé de recherche, et Adr l'adresse d'un bloc. On utilise parfois le
terme d'entrée pour désigner un enregistrement dans un index.
Toutes les valeurs de clé existant dans le chier de données ne sont pas représentées
dans l'index : on dit que l'index est non-dense. On tire parti du fait que le chier est trié sur
14
DB Manager par Nomdegroupe
Info-Spé
18.11.2005
Promo 2009
la clé pour ne faire gurer dans l'index que les valeurs de clé des premiers enregistrements
de chaque bloc.
La gure montre un index non-dense sur le chier des 16 lms, la clé étant le titre du
lm.
On suppose que chaque bloc du chier de données contient 4 enregistrements, ce qui
donne un minimum de 4 blocs. Il sut alors de quatre paires [titre, Adr] pour indexer
le chier. Les titres utilisés sont ceux des premiers enregistrements de chaque bloc, soit
respectivement Annie Hall, Greystoke, Metropolis et Smoke.
Supposons que l'on recherche le lm Shining. En consultant l'index on constate que ce
titre est compris entre Metropolis et Smoke. On en déduit donc que Shining se trouve dans
le même bloc que Metropolis. Il sut de lire ce bloc et d'y rechercher l'enregistrement. Le
même algorithme s'applique aux recherches basées sur un préxe de la clé (par exemple
tous les lms dont le titre commence par 'V').
Le coût d'une recherche dans l'index est considérablement plus réduit que celui d'une
recherche dans le chier principal. D'une part les enregistrements dans l'index sont beaucoup plus petits que ceux du chier de données puisque seule la clé (et un pointeur) y
gurent. D'autre part l'index ne comprend qu'un enregistrement par bloc.
Autre exemple : supposons que l'on recherche tous les lms dont le titre commence par
une lettre entre J et P. On procède comme suit :
on recherche dans l'index la plus grande valeur strictement inférieure à J : pour
l'index de la gure c'est Greystoke ;
on accède au bloc du chier de données, et on y trouve le premier enregistrement
avec un titre commençant par J, soit Jurassic Park ;
on parcourt la suite du chier jusqu'à trouver Reservoir Dogs qui est au-delà de l'intervalle de recherche, tous les enregistrements trouvés durant ce parcours constituent
le résultat de la requête.
4.2.1.3 Index dense
Que se passe-t-il quand on veut indexer un chier qui n'est pas trié sur la clé de recherche ? On ne peut tirer parti de l'ordre des enregistrements pour introduire seulement
15
DB Manager par Nomdegroupe
Info-Spé
18.11.2005
Promo 2009
dans l'index la valeur de clé du premier élément de chaque bloc. Il faut donc baser l'index sur toutes les valeurs de clé existant dans le chier, et les associer à l'adresse d'un
enregistrement, et pas à l'adresse d'un bloc. Un tel index est dense.
La gure montre un chier contenant seize lms, trié sur le titre, et indexé maintenant
sur l'année de parution des lms. On constate d'une part que toutes les années du chier de
données sont reportées dans l'index, ce qui accroît considérablement la taille de ce dernier,
et d'autre part que la même année apparaît autant qu'il y a de lms parus cette année là.
Un index dense peut coexister avec un index non-dense. On peut envisager de trier un
chier sur la clé primaire et de créer un index non-dense, puis d'ajouter des index dense
pour les attributs qui servent fréquemment de critère de recherche.
Il est possible en fait de créer autant d'index denses que l'on veut puisqu'ils sont indépendants du chier de données. Cette remarque n'est plus vraie dans le cas d'un index
non-dense puisqu'il s'appuie sur le tri du chier et qu'un chier ne peut être trié que d'une
seule manière.
La recherche par clé ou par préxe avec un index dense est similaire à celle déjà présentée
pour un index non-dense. Si la clé n'est pas unique (cas des années de parution des lms),
il faut prendre garde à lire dans l'index toutes les entrées correspondant au critère de
recherche. Par exemple, pour rechercher tous les lms parus en 1992 dans l'index de la
gure , on trouve d'abord la première occurence de 1992, pointant sur Jurasic Park, puis on
lit en séquence les entrées suivantes dans l'index pour accéder successivement à Impitoyable
puis Reservoir Dogs. La recherche s'arrête quand on trouve l'entrée 1995 : l'index étant
trié, aucun lm paru en 1992 ne peut être trouvé en continuant.
Notez que rien ne garantit que les lms parus en 1992 sont situés dans le même bloc :
16
DB Manager par Nomdegroupe
Info-Spé
18.11.2005
Promo 2009
on dit que l'index est non-plaçant. Cette remarque a surtout un impact sur les recherches
par intervalle, comme le montre l'exemple suivant.
Voici l'algorithme qui recherche tous les lms parus dans l'intervalle (1950, 1979).
on recherche dans l'index la première valeur comprise dans l'intervalle : pour l'index
de la gure c'est 1958 ;
on accède au bloc du chier de données pour y prendre l'enregistrement Vertigo ;
on parcourt la suite de l'index, en accèdant à chaque fois à l'enregistrement correspondant dans le chier de données, jusqu'à trouver une année supérieure à 1979 :
ontrouve successivement Psychose, Easy rider, Annie Hall et Manathan.
Pour trouver 5 enregistements, on a dû accéder aux quatre blocs. Le coût d'une recherche par intervalle est, dans le pire des cas, égale à r où r désigne le nombre d'enregistrements du résultat (soit une lecture de bloc par enregistrement).
4.2.1.4 Index multi-niveaux
Il peut arriver que la taille du chier d'index devienne elle-même si grande que les
recherches dans l'index en soit pénalisées. La solution naturelle est alors d”indexer le
chier d'index lui-même. Rappelons qu'un index est un chier constitué d'enregistrements
[clé, Adr]
, trié sur la clé : ce tri nous permet d'utiliser, dès le deuxième niveau d'indexation, un index
non-dense.
Reprenons l'exemple de l'indexation des lms sur l'année de parution.
On peut alors créer un deuxième niveau d'index, comme illustré sur la gure. On a
supposé, pour la clarté de l'illustration, qu'un bloc de l'index de premier niveau ne contient
que quatre entrées
[date,Adr]
. Il faut donc quatre blocs (marqués par des traits gras) pour cet index.
L'index de second niveau est construit sur les valeurs de clés des premiers enregistrements des quatre blocs. Il sut donc d'un bloc pour ce second niveau. S'il y avait deux
blocs (par exemple parce que les blocs ne sont pas complètement pleins) on pourrait envisager de créer un troisième niveau, avec un seul bloc contenant deux entrées pointant vers
les deux blocs du second niveau, etc.
17
DB Manager par Nomdegroupe
Info-Spé
18.11.2005
Promo 2009
Tout l'intérêt d'un index multi-niveaux est de pouvoir passer, dès le second niveau,
d'une structure dense à une structure non-dense. Si ce n'était pas le cas on n'y gagnerait
rien puisque tous les niveaux auraient la même taille que le premier.
Une recherche, par clé ou par intervalle, part toujours du niveau le plus élevé, et reproduit d'un niveau à l'autre les procédures de recherches présentées précédemment. Pour
une recherche par clé, le coût est égal au nombre de niveaux de l'arbre.
Exemple : on recherche le ou les lms parus en 1990. Partant du second niveau d'index,
on sélectionne la troisième entrée correspondant à la clé 1984. L'entrée suivante a en eet
pour valeur 1992, et ne pointe donc que sur des lms antérieurs à cette date.
La troisième entrée mène au troisième bloc de l'index de premier niveau. On y trouve
une entrée avec la valeur 1990 (il pourrait y en avoir plusieurs). Il reste à accéder à l'enregistrement.
Les index multi-niveaux sont très ecaces en recherche, et ce même pour des jeux de
données de très grande taille. Le problème est, comme toujours, la diculté de maintenir
des chiers triés sans dégradation des performances. L'arbre-B, étudié dans la section qui
suit, représente l'aboutissement des idées présentées jusqu'ici, puisqu'à des performances
équivalentes à celles des index en recherche, il ajoute des algorithmes de réorganisation
dynamique qui garantissent que la structure reste valide quelles que soient les séquences
d'insertion et suppression subies par les données.
4.2.2 Les arbres-B
4.2.2.1 Présentation
L'arbre-B est une structure d'index qui ore un excellent compromis pour les opérations de recheche par clé et par intervalle, ainsi que pour les mises à jour. Ces qualités
expliquent qu'il soit systématiquement utilisé par tous les SGBD, notamment pour indexer
la clé primaire des tables relationnelles. Dans ce qui suit nous supposons que le chier des
données stocke séquentiellement les enregistrements dans l'ordre de leur création et donc
indépendamment de tout ordre lexicographique ou numérique sur l'un des attributs. Notre
présentation est essentiellement consacrée à la variante de l'arbre-B dite l'arbre-B+ .
4.2.2.2 Pourquoi les arbres-B ?
Voici la liste des avantages et inconvénients des arbres-B.
Avantages
Permet une grande dynamicité ;
Facile à mettre en oeuvre ;
Couvre davantage d'opérations que les tables de hachage ;
Ore un excellent compromis pour les opérations de recherches par clé et par intervalle, ainsi que pour les mises à jour.
Inconvénients
Espace disque inutilisé (certains noeuds ne sont que partiellement utilisés) ;
Accès en temps logarithmique (donc plus long que le temps constant des tables de
hachage).
18
DB Manager par Nomdegroupe
Info-Spé
18.11.2005
Résumé
Promo 2009
Les arbres-B sont à la fois simples, très performants et propre à optimiser
plusieurs types de requêtes : recherche par clé, recherche par intervalle, et recherche avec
un préxe de la clé. Le B vient de balanced en anglais, et signie que l'arbre est équilibré :
tous les chemins partant de la racine vers une feuille ont la même longueur. L'arbre B
est utilisé dans tous les SGBD relationnels. Une structure concurrente de l'arbre B est
le hachage qui ore, dans certains cas, des performances supérieures, mais ne couvre pas
autant d'opérations.
4.2.2.3 Fonctions à implémenter
Voici la liste des fonctions à implémenter pour la première soutenance :
p_btree create_btree ();
Création d'un B-arbre vide. Renvoie 0 si tout c'est bien passé, le code d'erreur sinon.
int add_btree (p_b-tree *root, t_element x);
Ajoute un élément x à l'arbre-B accessible depuis la racine root. Renvoie 0 si tout c'est
bien passé, le code erreur sinon.
int modify_btree (p_btree *root, t_element x, t_element new);
Modie un élément x par new dans le B-arbre. Renvoie 0 si tout c'est bien passé, le code
d'erreur sinon.
int exists_btree (p_btree *root, t_element x);
Vérie si l'élément x est présent dans le B-arbre ou pas. Renvoie 1 si il est présent, 0 sinon.
p_internalnode search_btree (p_btree *root, t_element x);
Recherche l'élément x dans le B-arbre et retourne le pointeur vers cet élément.
int delete_btree (p_b-tree *root, t_element x);
Supprime un élément x du B-arbre avec réorganisation de l'arbre. Renvoie 0 si tout c'est
bien passé, le code d'erreur sinon.
int destroy_btree (p_btree **root);
Détruit le B-arbre passé en paramètre. Renvoie 0 si tout c'est bien passé, le code d'erreur
sinon.
4.2.2.4 Aspect technique
Ordre de l'arbre Comment
devons-nous déterminer l'ordre de l'arbre-B ? En eet,
l'ordre de l'arbre-B aura un impact sur le temps de recherche d'une information, sur le
temps d'ajout d'une information, sur le temps de traitement d'intervalles. En fait, on le
xe souvent selon la taille des secteurs du disque et selon les caractéristiques et besoins de
l'application.
Dans un arbre-B (ou B+) tous les éléments résident dans les feuilles. Les niveaux supérieurs
constituent un index réduit aux clés permettant de localiser les articles. Les noeuds et les
feuilles ont des formats diérents et l'ordre de l'arbre-B+ donne le minimum de clés d'un
noeud (excepté la racine). En supposant des noeuds et feuilles de 4 Ko, des éléments de 128
octets, des clés de 10 octets, des pointeurs codés sur 2 octets calculer les nombres minimum
et maximum d'éléments d'un arbre-B+ de hauteur 3, son ordre et ses tailles minimum et
maximum.
19
DB Manager par Nomdegroupe
Info-Spé
18.11.2005
Promo 2009
Format d'un noeud d'un arbre-B
Un arbre B d'ordre m est une arborescence telle
que :
Chaque chemin depuis la racine vers une feuille est de même longueur h appelée
hauteur (à 1 près) ;
Chaque noeud contient k clés triées de gauche à droite. k est tel que
sauf pour la racine où
m ≤ k ≤ 2m
1 ≤ k ≤ 2m ;
Un noeud est : soit terminal, soit possède (k+1) ls tels que les clés du i
ème
des valeurs comprises entre les valeurs des (i-1)
ème
et i
ème
ls ont
clé du père (i > 1).
Format d'un noeud : Un noeud non racine contient au maximum 2m (clé) et k+1
pointeurs de ls (2m + 1). La taille est fonction des éléments et des pointeurs (taille xée).
On essaye qu'un noeud corresponde à un bloc physique au maximum (une unité d'E/S).
2 ∗ m ∗ (taillecle) + (k + 1) ∗ taillepointeur ≤ taillebloc
4.2.3 Les tables de hachage
4.2.3.1 Présentation
Les tables de hachage sont des structures très couramment utilisées en mémoire centrale
pour organiser des ensembles et fournir un accès peformant à ses éléments. Nous commençons par rappeler les principes du hachage avant d'étudier les spécicités apportées par le
stockage en mémoire secondaire. L'idée de base du hachage est d'organiser un ensemble
d'éléments d'après une clé, et d'utiliser une fonction (dite de hachage) qui, pour chaque
valeur de clé
c, donne l'adresse f (c) d'un espace de stockage où l'élement doit être placé. En
mémoire principale cet espace de stockage est en général une liste chaînée, et en mémoire
secondaire un ou plusieurs blocs sur le disque.
4.2.3.2 Pourquoi les tables de hachage ?
Voici la liste des avantages et inconvénients par rapport aux arbres-B.
Avantages
Recherche par accès direct, en temps constant ;
N'occupe pas d'espace disque.
Inconvénients
Pas de recherche par intervalle ;
Pas de dynamicité.
Résumé
Il n'est pas inutile de rappeler qu'en pratique la hauteur d'un arbre-B est de
l'ordre de 2 ou 3 niveaux, ce qui relativise l'avantage du hachage. Une recherche avec le
hachage demande une lecture, et 2 ou 3 avec l'arbre B, ce qui n'est pas vraiment signicatif.
Cette considération explique que l'arbre-B, plus généraliste et presque aussi ecace, soit
employé par défaut pour l'indexation dans tous les SGBD relationnels. Enn signalons que
le hachage est une structure plaçante, et qu'on ne peut donc créer qu'une seule table de
hachage pour un ensemble de données, les autres index étant obligatoirement des arbres B+.
Nous présentons dans ce qui suit des techniques plus avancées de hachage dit dynamique
qui permettent d'obtenir une structure plus évolutive. La caractéristique comune de ces
méthodes est d'adapter le nombre d'entrées dans la table de hachage de manière à ce
que le nombre de blocs corresponde approximativement à la taille nécessaire pour stocker
l'ensemble des enregistrements. On doit se retrouver alors dans une situation où il n'y
20
DB Manager par Nomdegroupe
Info-Spé
18.11.2005
Promo 2009
a qu'un bloc par entrée en moyenne, ce qui garantit qu'on peut toujours accéder aux
enregistrements avec une seule lecture.
4.2.3.3 Fonctions à implémenter
unsigned adressage_hach (t_element x)
Calcule et renvoie la valeur de hachage pour l'élément x passé en paramètre.
void create_hach (p_hachtable *th);
Crée et initialise la table de hachage avec chaînage externe.
int add_hach (p_hachtable *th, t_element x)
Ajoute un élément x à la table avec gestion des collisions. L'élément est inséré selon un
ordre croissant. Renvoie 0 si tout c'est bien passé, le code d'erreur sinon.
int modify_hach (p_hachtable *th, t_element x, t_element new)
Modie un élément x par new dans la table. Renvoie 0 si tout c'est bien passé, le code
d'erreur sinon.
int etat_hach (p_hachtable *th, t_element x, t_etat etat)
Vérie si l'élément x est à l'état etat dans la table ou pas. Renvoie 1 si c'est le cas, 0 sinon.
p_element search_hach (p_hachtable *th, t_element x)
Recherche l'élément x dans la table et retourne le pointeur vers cet élément.
int delete_hach (p_hachtable *th, t_element x)
Supprime un élément x de la table. Renvoie 0 si tout c'est bien passé, le code d'erreur
sinon.
int destroy_hach (p_hachtable **th)
Détruit la table de hachage ainsi que tous ses tableaux dynamiques. Renvoie 0 si tout c'est
bien passé, le code d'erreur sinon.
unsigned busyrate_hach (p_hachtable *th)
Retourne le taux d'occupation de la table de hachage.
4.2.3.4 Aspect technique
Dénition de la fonction de hachage
La fonction de hachage, ou d'adressage, doit être
rapide à calculer car elle sera appelée à chaque ajout, suppression, recherche ou modication
d'un élément. Elle doit également être uniforme et surjective : uniforme car il faut éviter que
certaines valeurs de hachage subissent une accumulation d'éléments alors que d'autres ne
correspondent à aucune entrée ; surjective pour que chaque élément puisse avoir une valeur
de hachage qui lui correspond. La fonction de hachage doit également être déterministe
puisqu'il est absolument nécessaire de pouvoir retrouver un élément connaissant sa première
valeur de hachage. Enn, si la division (vue en cours) est utilisée dans la fonction de
hachage, le modulo doit être calculé en fonction d'un nombre premier pour éviter, une fois
encore, l'accumulation de clé pour une même valeur de hachage.
21
DB Manager par Nomdegroupe
Info-Spé
18.11.2005
Résolution des collisions
Promo 2009
Les collisions sont gérées grâce à l'utilisation de listes chaînées
dynamiques triées pour chaque valeur de hachage de la table. Ainsi, l'ajout et la suppression
de l'un des éléments pour une valeur de hachage spécique sont facilités. Le fait de trier
ces listes est un atout majeur surtout lors de la recherche d'un élément puisque l'on pourra
stopper la recherche à partir du moment où l'élément comparé est supérieur à l'élément
recherché. Enn, il n'y a pas de gestion de collisions secondaires puisque le fait de gérer les
collisions primaires de façon dynamique empêche tout simplement la possibilité pour deux
éléments ayant des valeurs de hachage diérentes de rentrer en collision.
4.3 L'optimisation
4.3.1 Algorithmes utlisés
L'accès et la manipulation de données constitue le réel intérêt algorithmique de cette
partie. Nous aurons l'occasion d'y aborder bon nombre de concepts relatifs à l'algèbre
relationnel tels que la jointure, le tri et la sélection, qui une fois combinées de diverses
manières permettent l'élaboration de plans d'exécution multiples, ce qui permet d' apporter
des solutions plus ou moins appropriées à chaque problème.
4.3.2 Algorithmes de base
Chaque opération peut être traitée de manières diérentes selon des conditions d'utilisation (utilisation ou non d'un index, sélectivité des attributs, etc...) qui vont entrainer
des choix algorithmiques diérents. Ainsi, on utilisera selon les cas une recherche dans un
chier (par balayage ou par accès direct), une fonction de tri externe (par exemple pour
éliminer les doubles dans une procédure d'union de tables) ou bien des jointures de divers
types. Les jointures des procédés sont ecaces à condition d'en faire usage à bon escient.
Elles sont en eet très coûteuses et on se doit de les évaluer correctement pour en faire le
meilleure usage. Les types de jointure utilisées seront la jointure par boucles imbriquées,
par tri-fusion et par hachage.
4.3.3 Sélection
Comme dit précédemment, on utilisera deux types de sélection :
par balayage,
-par accès direct.
Le balayage peut se révéler utile lorsque l'on voudra parcourir une table an de récupérer
des éléments qui satisfont à des critères précis. En revanche son utilisation peut se révéler
contraignante pour des tables de taille conséquente de par le grand nombre de lectures
qu'elle induit.
Lorsqu'il s'agira de récupérer une valeur dont on connait l'adresse, on essaiera autant
que possible d'y accéder directement pour que cela ne nous coûte qu'une seule lecture.
Par contre dans le cas où on lance une recherche sur plusieurs éléments, les choses se
compliquent et on devra pour cela utiliser des moyens quelque peu détournés comme l'utilisation d'un index. En ce qui concerne l'utilisation de cet index, nous déterminerons au fur
et à mesure de l'avancement du projet les cas les plus propices à son utilisation en fonction
des situations rencontrées. Ces cas seront d'ailleurs analysés par l'usage de statistiques tels
que la sélectivité d'un élément.
22
DB Manager par Nomdegroupe
Info-Spé
18.11.2005
Promo 2009
4.3.4 Tri externe
Le but ici est de mettre en oeuvre cette formule chère aux algorithmiciens : diviser
pour régner. On utilise le tri-fusion pour diviser le problème en sous-problèmes. Ce tri se
décompose en deux phases : le découpage de la table de telle sorte que chaque partie de
cette table tienne en mémoire centrale et le tri des parties en mémoire. Pour ce la on utlise
principalement le quicksort.
Pour la phase de tri, on prend chaque fragment des pages du chier, on les charge en
mémoire puis on les tri sur le disque.On eectue cette opération pour chaque page du chier
jusqu'à ce qu'on ait parcouru toute la partie désirée.
Le but est ici de fusionner récursivement toutes les partitions obtenues par le tri précédent. On obtient à chaque tour de boucle une partition plus grosse et cette étape s'achève
lorsque la dernière fusion délivre la relation toute entière.
Le tri-fusion se révélera utile et ecace à condition que l'on gère la mémoire susamment
bien pour avoir un espace mémoire susant et à condition de connaitre par avance la taille
de la table à trier.
4.3.5 Les algorithmes de jointure
On séparera les algorithmes de jointure en deux catégories selon la présence ou non
d'un index sur les attributs.
Dans le cas des algos de jointure utilisés sans index on aura le choix entre plusieurs
méthodes présentant chacune des avantages et des inconvénients :
Par boucles imbriquées, qui est une méthode simple à mettre en oeuvre mais qui montre
ses limites sur des table qui commencent à être volumineuses. Cette technique consiste à
réunir les paires issues des deux tables qui satisfont un prédicat déterminé. Pour chaque
enregistrement d'une table, on balaie l'autre table pour trouver les éléments correspondant
au prédicat. Ensuite on concatène les 2 listes dans un tampon que l'on vide sur disque dès
qu'il est plein.Lorsque cette technique sera utilisée l'optimiseur devra par avance déterminer
la plus grande des deux tables, qui devra être retenue comme table externe pour eectuer
les comparaisons. On peut malheuresement lui reprocher de couter cher en Entrée/Sortie.
D' où l' usage plus courant des methodes suivantes.
Par tri-fusion, qui constitue le principal outsider des boucles imbriquées, face auxquelles
il démontre son avantage sur des tables qui dépasent la taille de la mémoire. Ce tri facilite
grandement le regroupement des paires d' enregistrement partageant le même attribut de
jointure. Une fois ce tri achevé, on dispose de 2 chiers stockés temporairement sur le disque
dur, triés de telle sorte que lors de la phase de fusion, chaque page ne sera lue qu' une seule
fois. La deuxième (la fusion) qui intervient ensuite consiste à balayer parallèlement les deux
chiers pour déterminer les paires à joindre. On balaie la deuxième table tant que l'attribut
de jointure est inférieur à celui de la première. Dès qu' il y a égalité, on eectue la jointure.
Cette méthode est relativement ecace en terme de coût.
23
DB Manager par Nomdegroupe
Info-Spé
18.11.2005
Promo 2009
Par hachage, dont l' usage ne se prête qu' en cas d' équijointure (qui ne combine que
le enregistrements dont les champs joints sont égaux). Cette méthode se décompose en 2
phases : une phase de partitionnement des deux relations en un certain nombre de partitions
par la fonction de hachage. Celle-ci ayant pour but de réduire le cout de la jointure.
Puis une phase de jointure à proprement parler intervient. Au lieu de comparer tous les
enregistrements de la table, on ne comparera que les enregistrements de chaque partition
résultante. Il existe de multiples variantes d'algorithmes de hachage. Aussi, il faudra inclure
dans l'optimiseur de requêtes une partie qui détermine selon les cas la méthode la plus
appropriée.
Dans le cas d' une jointure avec un index, elle consiste en une sorte de variante de la
méthode par boucles imbriquées. Elle fait un accès séquentiel sur la relation non indexée.
La traversée de l' autre relation (indexée) donne les adresses des éléments à joindre. La
jointure est ensuite eectuée par adresse, ce qui évite de parcourir la première relation dans
son entièreté. On obtient ainsi un algorithme avec un coût logarithmique.
4.3.6 En bref
Pour résumer on peut dire que la partie évaluation constitue une sorte de petit système
décisionnel qui devra eectuer des analyses statistiques sur les données à traiter, tenir
compte de l' état de la mémoire, an de déterminer au mieux les algos et les opérations
relationnelles à utiliser. Il faudra également que ce système soit capable d'eectuer une
analyse syntaxique des requêtes SQL an d' apprécier leur validité et les traiter au mieux.
Enn cette partie du projet devra être capable autant que possible d' optmiser elle même
les requêtes en limitant les opérations et en limitant les accès disques.
24
Chapitre 5
Les Ressources matérielles
5.1 Nos congurations
Conguration technique du matériel utilisée par le groupe
critère
élève :
→
↓
LEFEBVRE Thomas
LEVENS Jérémy
Processeur
RAM
Distribution Linux
Pentium 4 HT : 3.4GHz
512 Mo
Slackware 10.1
Centrino 1.7GHz
512 Mo
Kernel 2.6.10
Athlon 64 3200+ : 2GHz
512 Mo
Slackware 10.1
Pentium 4 HT : 3.06GHZ
512 Mo
Kernel 2.6.10
Athlon 64 3200+
1024 Mo
Slackware 10.1
Centrino 1.73 Ghz
1024 Mo
Kernel 2.4.29
Centrino Sonoma : 1.73 Ghz
1024 Mo
Slackware 10.1
AthlonXp 2600+
512 Mo
Kernel 2.4.29
DUVERT Alexandre
PIETERS Aimeric
5.2 Le Budget
Type de matériel
Quantité
Prix
Abonnement Internet
4
120 e par mois
Livre Langage C
2
Distribution Slackware
4
Encre Imprimante Noir
5
Encre Imprimante Couleur
2
Packet de 500 feuilles
3
35 e par livre
0e
75 e
70 e
10 e
1305 e
TOTAL
25
Chapitre 6
Le Site web : dbmanager.free.fr
6.1 Présentation du site
6.1.1 Introduction
Dans cette partie, nous allons vous décrire le site web du projet et en expliquer l'organisation. Le site web sera développé en php.
Le but de ce site est de présenter le projet en lui même mais également son développement.
La description du site s'organisera dans l'ordre de lecture de celui-ci. Chaque titre
correspond à celui de la page web décrite.
6.1.2 Accueil / News
Cette page est destinée à fournir une brève introduction dont le but est de présenter le
projet et son environnement (école, groupe, but du projet...).
On y trouvera également la partie news du projet. Cette partie fournira, le plus fréquemment possible, l'état d'avencement du projet. Elle est importante car elle permet la
mise en place d'un agenda très utile pour l'élaboration des rapports de soutenance.
La mise à jours des news se fera directement sur le site, il faudra fournir un mot de
passe : en l'occurence ce sera celui utilisé avec le client ftp.
6.1.3 Le groupe
Dans cette page ci, chaque membre du groupe fera une brève description de sa personne.
Cette page sera accompagnée d'un bref paragraphe introductif sur le groupe.
6.1.4 Présentation du logiciel
Dans cette partie nous établirons une che descriptive du logiciel.
6.1.5 Planning et répartition des tâches
Le planning et la répartion des tâches, présents dans ce cahier des charges, seront
reproduis dans cette page.
6.1.6 Les soutenances
Ici on établira un rapport détaillé sur les soutenances. Nous y décrirons leur déroulement
et ce que nous y avons présenté, le tout accompagné de captures d'écrans.
26
DB Manager par Nomdegroupe
Info-Spé
18.11.2005
Promo 2009
6.1.7 Téléchargements
Sur cette page, nous fournirons les diérents éléments du projet téléchargeables : cahier
des charges, rapports de soutenances, les diérents exécutables que l'on aura présentés, les
sources...
Cette page sera organisée sous forme de tableau.
6.2 Les Ressources
6.2.1 Logiciels
Pour développer le site un simple éditeur de texte fera l'aaire. Dans le cas présent se
sera emacs.
6.2.2 Hébergement
Le site est hébergé par free, qui nous met a notre disposition un FTP de 100 mégas ce
qui comble très largement nos besoins. L'adresse du site est donc http ://dbmanager.free.fr
et nous avons jugé inutile la location d'un nom de domaine.
27
Chapitre 7
Le Planning des soutenances
Site web :
Le site internet du groupe disponible en ligne http ://dbmanager.free.fr sera
régulièrement mis à jour par l'ensemble des membres du groupe. Pour le reste :
28
Info-Spé
DB Manager par Nomdegroupe
Promo 2009
18.11.2005
élève :
période
→
↓
Lefebvre Thomas
Levens Jérémy
Duvert Alexandre
Pieters Aimeric
1
soutenance
3 soutenance
Optimisations
Soutenance nale
e
2 soutenance
Importation BDD
Interface utilisateur
Exportation BDD
Optimisations
Ajouts de fonctions
Optimisations
Optimisations
Exportation SQL
Interface utilisateur
Exportation BDD
Interface SQL/C
Traitement des
Importation BDD
Interface SQL/C
Gestion chiers
e
Tableau de la répartition des charges par soutenance
re
Gestion chiers
Indexation (Arbres-B
et Tables de hachage)
Opérations exprimées
requêtes SQL
Interface utilisateur
Site Web
par SQL
Index multi-niveaux
dense et Index dense)
Indexation (Index non
Site web
29