Note

Gestion de Fichiers
Hachage (suite et fin)
Plan du cours d’aujourd’hui




Utilisation des “buckets”
Effacements dans des fichiers hachés
Autres méthodes de résolution de collision: “double
hashing”, débordement progressif chainé;
enchainement avec une aire de débordement
séparée; “scatter tables”
Patrons d’accès aux enregistrements
2
Stockage de plus d’un enregistrements
par adresse: “bucket”




Nous allons maintenant voir une éthode de hachage
qui stocke plus d’un enregistrement par adresse
physique.
Un “bucket” est un bloc d’enregistrements
partageant la même adresse h(k); il est recupéré
dans un même accès au disque.
Lorsqu’un enregistrement va être mis en stockage ou
recupéré du stockage, son adresse de bucket est
déterminée par la fonction de hachage.
Lorsqu’un bucket est remplit, on doit toujours
résoudre le problème de débordement d’enreg.s.
3
Stockage de plus d’un enregistrements
par adresse: “bucket”

Exemple pour un bucket de 3 enregistrements
Clé
Green
Hall
Jenks
King
Land
Marx
Nutt
Adresse
30
30
32
33
33
33
33
30
31
32
33
34
|Green …|Hall … |
|
|
|
|
|
|Jenks … |
|
|
|King … |Land …|Marx …|
|Nutt …. |
|
|
4
Effet des buckets sur la performance

La formule de calcul de la densité d’enregistrement
d’un fichier change un peu:
PD = r/(b*N)
N = # d’adresses disponibles
r = # d’enreg.s dans le fichier
b = # d’enreg.s par adresse

Bien que PD ne change pas lorsque l’on réduit de
moitié le nombre d’adresses et que l’on double la
taille des buckets, le nombre de débordements
attendu diminue dramatiquement.
5
Effet des buckets sur la performance



Pour illustrer l’effet des buckets sur la performance,
Considerons le deux alternatives suivantes:
1. Stocket 750 enreg.s dans un fichier haché de 1000
adresses, chacune contenant un enregistrement.
2. Stocket 750 enreg.s dans un fichier haché de 500
adresses, chacune contenant 2 enregistrements.
Alternative 1: PD = r/(b*N) = 750/(1*1000) = 0.75 = 75%
Alternative 2: PD = r/(b*N) = 750/(2*500) = 0.75 = 75%
Alternative 1: r/N = 750/1000 = 0.75
Alternative 2: r/N = 750/500 = 1.50
6
Effet des buckets sur la performance

L’estimation des probabilités de collision se fait comme avant:
Alt. 1: r/N = 0.75:
Alt. 2: r/N = 1.50

p(0)
0.472
0.223
(p1)
0.354
0.335
p(2)
0.133
0.251
p(3)
0.033
0.126
p(4)
0.006
0.047
p(5) …
0.001
0.014
Pourcentage de collision pour différentes taille de buckets:
Alt. 1: (r/N = 0.75):
# de débordements = r – N * (1 – p(0)) (Voir dernier cours)
= 750 – 1000 * (1 – 0.472) = 750 – 528 = 222  29.6% de déb.s
Alt. 2: (r/N = 1.50): # de débordements
= 1 * [1*p(3) + 2*p(4) + 3.p(5)+ …)]
= r – N*p(1) – 2*N*[p(2) + p(3) + p(4) + …]
= r – N * [p(1) + 2*[1 – p(0) – p(1)]]
= r – N * [2 – 2* p(0) – p(1)]
= 750 – 500 * (2 – 2 * 0.223 – 0.335) = 140.5  18.7% de déb.s
7
Effet des buckets sur la performance

Avec l’estimation des probabilités des collisions en main, on
peut faire une estimation du pourcentage de collision pour
différentes tailles de buckets (Voir table 11.4):
Pourcentage par taille des buckets
PD (%)
1
2
5
10
100
…
10
20
30
50
75
100
4.8
9.4
13.6
21.3
29.6
36.8
0.6
0.0
2.2
0.1
4.5
0.4
11.4 2.5
18.7 8.6
27.1 17.6
0.0
0.0
0.0
0.4
4.0
12.5
0.0
0.0
0.0
0.0
0.0
4.0
8
Implémentation des buckets



La structure des buckets: maintenir un compteur d’enreg.s
stockés dans le bucket, et marquer les entrées vides par
une suite de symbole spéciaux (p.ex. “//////// …/”); un
exemple de bucket est: |2|JONES |BRICE |//////// |////////|
Initialiser le fichier avant le hachage:
1. Fixer la taille logique (= # d’adresses disponible) du
fichier ainsi que le # de buckets par adresses.
2. Créer a fichier de buckets vides devant contenir
des enregistrements à venir dont les buckets ont la
forme suivante: |0|////////|////////|////////|////////|
Pour charger un fichier haché, faire attention à revenir au
début du fichier lors de la recherche d’espace vide ainsi
qu’au problème de boucle infini lorsque le fichier est plein.
9
Effacer des enregistrements



L’effacement d’un enregistrement d’un fichier haché est
plus compliqué que l’addition d’enreg.s pour 2 raisons:
 L’espace dans lequel l’effacement s’est fait ne doit pas
deranger les recherches futures.
 Il devrait être possible de re-utiliser les espaces liberes
dans des additions futures.
Pour illustrer le type de dérangements qui apparaissent
dans ce contexte, nous utilisons le débordement
progressif. Ici un enreg. effacé peut interrompre de
manière invalide la recherche pour un autre enreg. qui se
trouverait dans le fichier après l’emplacement de l’enreg.
effacé (Fig. 11.9).
La solution à ce problème consiste à utilser des pierre
tombales (“tombstones”).
10
Effacer des enregistrements



Une pierre tombale est un marqueur indiquant qu’un
enregistrement était à un emplacement donnée
auparavant mais n’y est plus. Les pierres tombales
résolvent les 2 problèmes causés par l’effacement:
 L’espace dans lequel l’effacement s’est fait
n’interrompt plus les recherches futures.
 Il est possible de re-utiliser les espaces libérés pour
des additions futures.
N’inserez une pierre tombale que si le prochain enreg.
Est occupé ou est une pierre tombale, car sinon on reintroduit les problème que l’on vient juste de résoudre.
L’insertion d’enregistrements est un petit peu différente
lorsque l’on utilise des pierres tombales: inserez un
nouvel enreg. lorsque vous rencontrez soit un espace
vide ou une piere tombale.
11
Effets des effacements et des
additions sur la performance



Une fois qu’un large nombre d’effacements et
d’additions ont pris place, il y aura beaucoup de
pierres tombales occuppant des emplacements qui
pourraient être occuppés par des enregistrements
dont l’adresse précède ces pierres tombales, mais qui
sont mises en stockages plus loin.
Ceci détériore la longueur de recherche moyenne.
Il y a 3 solutions possibles à ce problème:
1. réorganisation locale pendant les effacements
2. réorganisation globale lorsque la longueur de
recherche moyenne est trop grande
3. utilisation d’une diff. techn. de résolution de collision
12
Autres techniques de résolution de
collisions: double hachage



Il y a quelques variations sur le hashing au hasard qui peut
ameliorer la performance.
Double Hashing: lorsqu’un débordement se produit,
utiliser une séconde fonction de hachage pour trouver la
location de débordement de l’ enregistrement débordant.
Exemple:
k
h1(k)
h2(k)
ADAMS
5
2
adresse … 4
enreg.s
JONES
6
3
MORRIS
6
4
5
6
7
ADAMS JONES
SMITH
5
3
8
9
SMITH
10 …
MORRIS
Note: h2(k) et N (= # d’adresses disponibles) sont
relativement premiers l’un à l’autre; l’adresse définitive
est obtenu en prenant h1(k)+h2(k). On ajoute autant de
fois h2(k) à h1(k) que nécessaire jusqu’à ce qu’on trouve
un espace libre.
13
Autres techniques de résolution:
débordement progressif chainé



Le débordement progressif chainé est comme le
débordement progressif mis à part le fait que les
synonymes sont liés l’un à l’autre avec des pointeurs
(Fig. 11.13). Cela réduit la longueur de la recherche
dans un regroupement d’enreg.s.
Problème: Supposez que DEAN a en fait 22 comme
adresse et que COLE est déjà à sa place. Nous ne
pourrions plus avoir un pointeur de vers DEAN à
partir de son adresse domiciliaire.
Solution: “two pass loading”:
1. Premier passage: charger seulement les enreg.s
qui entrent dans leur adresse domiciliaire.
2. Deuxième passage: charger les enreg.s
débordants.
14
Autres techniques de résolution de
collisions



Enchainement avec une aire de debordement
separée: Comme le débordement progressif chainé
mis a part le fait que les adresses de debordement
n’occuppe pas les adresses normales (de nondébordement)
Scatter Tables: Le fichier hash ne contient pas
d’enregistrements, mais seulement des pointeurs à
ces enregistrements. Autrement dit, c’est un un
index.
Voir les figures appropriées dans le livre.
15
Patron d’accès aux enregistrements



Si on a des informations sur les enregistrements
qui sont accédés le plus souvent, on peut optimiser
leur location de facon à ce que ces enregistrements
aient des longueurs de recherche courtes.
On fait cela pour diminuer la longueur effective
moyenne de recherche même si la longueur
nominale moyenne de recherche reste la même.
Ce principe est similaire à celui utilisé dans
l’encodage Huffman.
16