B - Friedrich-Schiller

Datenbank- und Informationssysteme
- Ergänzungsfach B.A. -
Übung
- Speicherstrukturen und Datenzugriff Wintersemester 2011/2012
Institut für Informatik
Lehrstuhl für Datenbanken und Informationssysteme
Dipl.-Inf. Matthias Liebisch
01.11.2011
Datenbank- und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 1
Organisatorisches (1)
Vorlesung "Datenbank- und Informationssysteme"
- Vorlesungszeit im Wintersemester 17.10.2011 – 03.02.2012
- Dienstag, 12-14 Uhr (Vorlesung und Übung im Wechsel)
- Mittwoch, 18-20 Uhr (Vorlesung)
Konkrete Übungstermine:
- 01.11. (Vertiefung Speicherstrukturen und Datenzugriff)
- 15.11. (Übungsblatt 1)
- 29.11. (Übungsblatt 2)
- 13.12. (Übungsblatt 3)
- 23.12. – 31.12. Weihnachten/Silvester (Bergfest)
- 03.01. (Übungsblatt 4)
- 17.01. (Übungsblatt 5)
- 31.01. (Übungsblatt 6)
Datenbank- und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 2
Organisatorisches (2)
Ablauf der Übung
- Übungsblätter werden schrittweise im Netz bereitgestellt, jeweils 1 Woche
vor dem Übungstermin
- URL: http://www.minet.uni-jena.de/dbis/
Lehrveranstaltungen
Datenbank- und Informationssysteme (Ergänzungsfach B.A.)
Material
- Eigenständige Bearbeitung/Lösung der Aufgabe
- Besprechung während der Übung, keine Abgabe/Korrektur
Zielstellung
- Vertiefung und praktische Erprobung der Vorlesungsinhalte
- Vorbereitung auf die Prüfung/Klausur
Datenbank- und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 3
Inhalt
Motivation
B-Baum
B*-Baum
Statisches Hashing
Erweiterbares Hashing
Datenbank- und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 4
deskriptive, mengenorientierte Schnittstelle
(z.B. SQL)
Anfrageübersetzung/-optimierung
Query Optimizer
Zugriffspfadauswahl
Zugriffskontrolle/Integritätskontrolle
WIE
prozedural
FINDE nächsten Satz
SPEICHERE Satz (log.)
Zugriffssystem
satzorientierte
Schnittstelle (log.)
Katalogverwaltung
Sortierkomponente
Sperrverwaltung
SPEICHERE internen Satz
FÜGE Eintrag im B*-Baum ein
Speichersystem
interne Satzschnittstelle (phys.)
Record Manager
Zugriffspfadverwaltung
Logging/Recovery (Fehlerbeh.komp.)
BEREITSTELLEN Seite j
FREIGEBEN Seite j
Pufferverwaltung
Systempufferschnittstelle
Systempufferverwaltung (Buffer Manager)
Betriebssystem/
Dateiverwaltung
Dateischnittstelle
LIES Block k
SCHREIBE Block k
Externspeicherverwaltung/Dateiverwaltung
Härder/Rahm 2001
Datenbank- und Informationssysteme
DB
Friedrich-Schiller-Universität Jena
Datenbank-Verwaltungssystem
SELECT . . .
FROM . . . WHERE
Datensystem
Betriebssystem/
Dateisystem
Anwendungsprogramme/Benutzer
deskriptiv
WAS
Anwendung
Motivation: 5-Schichten-Architektur (DIAM)
Seite 5
Motivation: Grundlagen
Abbildung der Datenbankobjekte auf interne Datensätze?
- 1:1, Aufspalten oder Zusammenfassen von Entities
- Ablage von Datensätzen variabler Länge in Seiten fester Größe
- Zugriff auf Datensätze über Adressen
Randbedingungen
- Große Datenmengen nicht komplett im Hauptspeicher ablegbar
- Mehr Suchanfragen als Änderungen auf Informationen
Wozu Zugriffspfade?
- Schneller und einfacher inhaltsbezogener Zugriff notwendig:
"Gib mir alle Angestellten, die mehr als 3 Kinder haben und vor dem
01.01.2005 in die Firma eingetreten sind."
- Sequentielle Suche über MB/GB/TB an Daten nicht akzeptabel
- Minimierung der Anzahl von Externspeicherzugriffen (Zeitfaktor 105)
- Analogie: wie errät man effektiv eine Zahl zwischen 1 und 1024?
Datenbank- und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 6
Motivation: Klassifikation von Zugriffspfaden
Datenbank- und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 7
B-Baum: Beschreibung
Vorschlag von Rudolf Bayer und Edward McCreight (1970)
Baumknoten werden auf Seiten abgebildet (verwaltet vom DBMS!)
Im Baum der Ordnung n gilt für alle Knoten (außer Wurzel)
- Ein Knoten enthält m Datensätze fester Länge mit n ≤ m ≤ 2n
- Ein Knoten ist Blatt oder hat m+1 Kinder
Datensatz = Schlüsselteil + Datenteil
- Meist nur mit Zeiger auf eigentliche Daten (nicht eingebetteter Index)
- Performance-Abwägung zwischen Zugriff und Reorganisation
Alle Blätter befinden sich auf gleicher Baumebene (vollständig balanciert),
damit konstante Zugriffszeit bis zur Blattebene
Vaterknoten ist Index für seine Nachfolgerknoten aufgrund der beinhalteten
Schlüsselwerte
Datenbank- und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 8
B-Baum: Aufbau
Datenbank- und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 9
B-Baum: Suchen
Suche nach Datensatz d mit Schlüssel s
Lese Wurzelseite k
Suche s in Seite k gefunden?
- Ja: Ausgabe von Datensatz d; fertig!
- Nein: Seite ist Blatt?
• Ja: Schlüssel ist nicht vorhanden; fertig!
• Nein: Existiert ein kleinster Schlüssel si mit s ≤ si?
- Ja: Suche s in Seite k weiter, auf die pi verweist
- Nein: Suche s in Seite k weiter, auf die pm+1 verweist
Beispiel: Suche nach Schlüssel 19 im Baum der vorherigen Folie
- Wurzelknoten mit einem Schlüssel (19 ≤ 32) Verweis p1 (<32) folgen
- Folgeknoten mit Schlüsseln 11 und 17 Verweis p3 (>17) folgen
- Blattknoten (19, 25, 30) enthält die den gesuchten Schlüssel 19
Datenbank- und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 10
B-Baum: Einfügen
Einfügen von Datensatz d mit Schlüssel s
Suche s im Baum gefunden?
- Ja: Fehlermeldung; fertig!
- Nein: Merke Blatt b in dem die Suche endet
Füge (s, d) in Blatt b sortiert ein Ist ausreichend Platz vorhanden?
- Ja: es gilt |b|<2n; fertig!
- Nein: es gilt |b|=2n
• Teile b in zwei Knoten bL und bR
- bL = ((s1, d1), ..., (sn, dn))
- bR = ((sn+2, dn+2), ..., (s2n+1, d2n+1))
• Füge (sn+1, dn+1) in den parent(b) sortiert ein und setze dort
entsprechend die Zeiger auf bL und bR
Datenbank- und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 11
B-Baum: Einfügen (Beispiel)
Datenbank- und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 12
B-Baum: Löschen
Löschen von Datensatz d mit Schlüssel s
Suche s im Baum gefunden?
- Ja: Merke Knoten k in dem s gefunden wurde
- Nein: Fehlermeldung; fertig!
Lösche (s, d) in Knoten k k ist ein Blatt?
- Ja: nach Löschen gilt |k|≥n?
• Ja: fertig!
• Nein: Unterlaufbehandlung(k); fertig!
- Nein:
• Ersetze (s, d) in Knoten k durch größtes (kleinstes) Blattelement b im
linken (rechten) Teilbaum von (s, d)
• Falls nötig Aufruf Unterlaufbehandlung(b)
Datenbank- und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 13
B-Baum: Löschen (Unterlaufbehandlung)
Skizze für die Unterlaufbehandlung in Knoten k
Knoten k hat einen direkten rechten (linken) Bruder ks mit n Einträgen?
- Ja:
• Zusammenfassen von k und ks (inklusive Trenn-Eintrag in parent(k))
• Setzen der Verweise in parent(k)
• Falls nötig Aufruf Unterlaufbehandlung(parent(k)); fertig!
- Nein: k ist Blatt?
• Ja: kleine Rotation über parent(k) nach rechts (links); fertig!
• Nein: große Rotation über parent(k) mit linkem (rechtem) BruderTeilbaum von k; fertig!
Ablauf der kleinen Rotation für Knoten k nach rechts (links)
- Verschiebe Trenn-Eintrag in parent(k) nach k
- Verschiebe das größte (kleinste) Knotenelement im direkten linken
(rechten) Bruder-Teilbaum nach parent(k)
Datenbank- und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 14
B-Baum: Löschen (Beispiel Zusammenfassen)
Datenbank- und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 15
B-Baum: Löschen (Beispiel kleine Rotation)
Datenbank- und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 16
B-Baum: Löschen (Beispiel große Rotation)
Datenbank- und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 17
B-Baum: Fazit
Ordnung n beeinflusst Effizienz
- Je größer n, desto niedrigere Baumhöhe (bei gleicher Anzahl Datensätze)
- Je niedriger die Baumhöhe, desto performanter
• Wurzelknoten möglichst im Hauptspeicher halten
• Jede zusätzliche Seitenanforderung kostet viel Zeit (Pufferverwaltung)
• Bis zu 2n Datensätze pro Seite/Knoten (statt 1 Datensatz pro Knoten
im Binärbaum)
- ABER: n ist durch Seitengröße beschränkt (z.B. 4KB, 8KB, 16KB, 32KB)
B-Baum ist robust gegen Entartung durch (lokale) Reorganisation
Doppelrolle der Schlüsselwerte si
- si bildet ab auf Datensatz di
- si als Weiche zur Suchsteuerung
• Für Suchsteuerung ist der Datenteil nicht erforderlich
• Idee: Datenteile werden nur auf Blattebene gespeichert B*Baum
Datenbank- und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 18
B*-Baum: Beschreibung
Vorschlag von Donald Knuth in "The Art of Programming Vol.3" (1973)
Datensätze nur in den Blättern
- Innere Knoten enthalten (redundant) Schlüssel und Zeiger auf Kinder
- Allgemein flacher als B-Baum, da bei fester Seitengröße mehr Schlüssel
in einem Knoten Platz finden
Blattfolge entspricht sequentieller Datei, üblicherweise mit (doppelter)
Verkettung zwischen den Seiten:
- B*-Baum = sequentielle Datei + Indexbaum (B-Baum)
- Sequentieller sortierter Zugriff und wahlfreier Schlüsselzugriff
- Bereichsanfragen, Extremwertanfragen, Datensätze variabler Länge
Datenbank- und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 19
B*-Baum: Aufbau
Datenbank- und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 20
B*-Baum: Fazit
Zugriffsmethoden analog, Lösch-Vorgang einfacher als im B-Baum
- Daten werden nur in Blättern entfernt
- Schlüssel auf inneren Knoten bleiben als Wegweiser erhalten
Häufigste Art der Index-Implementierung in DBMS (Synonym: B+-Baum)
Typische Zahlen aus der Realität
- Kapazität:
• Blätter mit über 100 Einträgen
• entspricht beispielsweise 320 Byte je Datensatz bei 32KB Pagesize
- Baumhöhe: 3-5 Ebenen bei 105- 107 Datenelementen auf Blattebene
- Auslastung:
• jeder Knoten mindestens zur Hälfte gefüllt (wegen n ≤ m ≤ 2n)
• B*-Baum von Knuth hat garantierte Auslastung von 2/3
Datenbank- und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 21
Statisches Hashing: Beschreibung
Hashtabelle als Indexstruktur ("Von der Ordnung ins Chaos")
Verwendung von Streuspeicherverfahren bzw. Hashfunktionen
- Direkte Abbildung/Berechnung der Speicheradresse eines Datensatzes
über den Schlüssel (Schlüsseltransformation)
- Hashfunktion h(x) liefert die Seite (Bucket) bzw. Speicheradresse mit dem
Dateneintrag zu Schlüssel x
- Beispiel einer Hashfunktion: "Divisionsrestverfahren"
• Geeignete Division des Schlüssels in Bit-/Dezimaldarstellung
• Rest der Division ergibt die relative Adresse in der Hashtabelle
Hashfunktion h: S {1, 2, ..., n}
- S = Schlüsselraum, n = Größe des statischen Hash-Bereichs (Buckets)
- Idealfall: h ist injektiv (keine Kollisionen)
• Nur in Ausnahmefällen möglich ('dichte' Schlüsselmenge)
• Jeder Satz kann mit einem Seitenzugriff referenziert werden
- Ziel: möglichst gute Gleichverteilung einer konkreten Schlüsselmenge
K⊆ S auf n Buckets
Datenbank- und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 22
Statisches Hashing: Operationen
Gegeben:
- Hashfunktion h, Adressraum A
- Datensatz D mit Schlüssel Ki
Einfügen
- Generierung der zukünftigen Speicheradresse: h(Ki) = Ai
- Schlüssel Ki wird auf Adresse Ai gespeichert
Löschen
- Ermittlung der zugehörigen Speicheradresse: h(Ki) = Ai
- Schlüssel Ki wird auf Adresse Ai gelöscht
Direkte Suche
- Ermittlung der zugehörigen Speicheradresse: h(Ki) = Ai
- Bereitstellung von Datensatz D mit Schlüssel Ki von Adresse Ai
Sequentielle Suche
- Sequentieller Durchlauf des Adressraumes A = A1 ... An
- Keine geordnete Schlüsselfolge keine sequentielle Suche möglich!
Datenbank- und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 23
Statisches Hashing: Kollision
Definition:
- Zwei Schlüssel Ki und Kn kollidieren bezüglich einer Hashfunktion h,
wenn gilt: h(Ki) = h(Kn)
- Ki und Kn nennt man dann auch Synonyme, sie gehören zu einer
Kollisionsklasse
- Ki und Kn haben die gleiche Hausadresse
Kollisionsbehandlung umfasst folgende Aufgaben
- Finden einer freien Speicheradresse beim Einfügen
- Auffinden eines Schlüssels, der nicht auf seiner Hausadresse
gespeichert wurde
Alle Operationen werden durch Kollisionsbehandlung komplexer
Viele Hashfunktionen (z.B. Modulo) bilden eine größere Schlüsselmenge in
einen kleineren Wertebereich ab Kollision ist dann zwangsläufig
Datenbank- und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 24
Statisches Hashing: Kollisionsbehandlung
Offenes Hashen
h(Kx) = h(Km)
- Kollisionen werden im Primärbereich untergebracht
Kx
• Suche einer anderen noch nicht belegten
Km
Ki
Adresse in der Hashtabelle
Kx
• Lineares/quadratisches Sondieren,
Ko
Doppeltes Hashen
- Gleiche Strategie beim Wiederauffinden
- Lösch-Problematik: Einträge dürfen nicht einfach gelöscht werden, da
sonst veränderte Voraussetzungen (Lösung: Delete-Flag)
Geschlossenes Hashen
- Kollisionen werden im separaten Überlaufbereich gespeichert
h(Kx) = h(Km)
• Überlaufbereich für alle Kollisionen
• Überlaufbereich pro Adresse
Kx
Km
- Gefahr der Entartung
Ki
• Überlauflisten werden zu lang
• Performance sinkt (Suche in einer Liste!)
Ko
Datenbank- und Informationssysteme
Friedrich-Schiller-Universität Jena
Kx
Seite 25
Statisches Hashing: Fazit
Vorteile:
- Kurze Zeiten beim Zugriff auf Daten (O(1), wenn keine Kollision)
- Schnelles Einfügen von Daten (wenn keine Kollision)
Nachteile:
- Hashfunktion entscheidend für die Qualität des Hashverfahrens
• Es gibt keine optimale Hashfunktion für beliebige Schlüsselmengen!
• Abhängigkeiten: Performance, Berechnungs-Komplexität,
Datenverteilung, Kollisions-Wahrscheinlichkeit
• Kollisionsbehandlung notwendig!
- Kein sortierter, sequentieller Zugriff auf Daten möglich
- Ineffizienz bei unvorhersehbaren bzw. stark wachsenden Datenmengen
• Primärbereich anfangs überdimensioniert, Freihalten von Leerstellen
• Wachsende Überlaufketten verschlechtern Laufzeitverhalten
• Nachträgliche Vergrößerung der Hashtabelle (Re-Hash) mit Entladen
und Neuladen ist teuer bzw. nicht möglich (24h-Dauerbetrieb!)
Übergang zum Erweiterbaren (extendible) Hashing (Fagin et al, 1978)
Datenbank- und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 26
Erweiterbares Hashing: Ziele
Dynamisches Wachsen und Schrumpfen des Hashbereichs
- Buckets werden erst bei Bedarf bereitgestellt
- Hohe/dichte Speicherplatzbelegung möglich
Konstantes Laufzeitverhalten unabhängig vom Umfang des Datenbestands
Auffinden eines Satzes soll nicht mehr als 2 Seitenzugriffe (möglicherweise
auf dem Externspeicher) erfordern
Vermeidung von Überlaufmechanismen und totaler Reorganisation
Problem: dynamische Erweiterung des Hashbereichs
Erweiterung des Wertebereichs der Hashfunktion
Änderung der Hashfunktion (z.B. MOD 100 statt MOD 10)
Änderung der Hashwerte für bereits gespeicherte Daten
Datenbank- und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 27
Erweiterbares Hashing: Beschreibung
Hashtabelle gegliedert in zwei Bereiche
- Directory (Inhaltsverzeichnis)
- Eigentliche Hashbuckets
Zugriff zu den Werten in den Hashbuckets nur über Directory möglich
- Zusätzliche Indirektion (evt. Externspeicherzugriff!)
- Notwendiges Hilfsmittel für die gewünschten Erweiterungseigenschaften
Buckets mit fester Länge (z.B. Seitengröße 4KB) und Kapazität b
- Abhängig von den zu hashenden Daten (Wertlänge)
- Abhängig von Datenintegration (Einbettung vs. Separierung) zusätzlicher
Informationen, z.B. Personaldaten zur Personalnummer
Hashfunktion h generiert Pseudoschlüssel zu einem Satz x
- h(x) = dp mit h: S {0,1}* (binäre Darstellung von h(x))
- Zerlegung in zwei Teile:
• d: Index (Adresse) des Buckets für x im Directory (d = globale Tiefe)
• p: aktuell ungenutzter Teil des Schlüssels
- Directory enthält 2d Einträge, verdoppelt sich mit jedem zusätzlichen Bit
- Bucket enthält nur Sätze, deren Pseudoschlüssel in den ersten d' Bits
übereinstimmen (d' = lokale Tiefe, d = max(d'))
Datenbank- und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 28
Erweiterbares Hashing: Operationen
Gegeben: Hashfunktion h, Buckets Bn mit Kapazität b, Datensatz D mit
Schlüssel K
Suche von D:
- Anwendung der Hashfunktion h(K) ergibt Pseudoschlüssel für Directory
- Ermittlung des zugeordneten Buckets Bi über das Directory
- Durchsuchen von Bucket Bi nach K (z.B. mit binärer Suche)
Einfügen von D:
- Suche von D gefunden?
• Ja: Fehlermeldung, fertig!
• Nein: Ist noch Platz im Bucket Bi, also |Bi|<b?
- Ja: Einfügen von D in Bucket Bi
- Nein: Splitting von Bucket Bi zwei neue Buckets
- Lokale Neuverteilung der Einträge aus Bi und Verweiskorrektur
- Eventuell Verdopplung des Directory wegen Selektivität
Datenbank- und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 29
Erweiterbares Hashing: Beispiel (1)
Schrittweiser Aufbau einer Hashtabelle durch sukzessives Einfügen
(Visualisierung: http://scorpius.informatik.uni-mannheim.de:8080/abast/extHash.jsp)
Ausgangssituation:
- Bucket-Kapazität sei b=4
- h(x) = x MOD 32 (h: S [0, 31]) in Binärdarstellung [00000, 11111]
- Start mit globaler Tiefe d=0
• Ein Bucket B1 (mit 4 Slots)
• Nur 1=2d Directory-Eintrag notwendig, der auf Bucket B1 verweist
- Schlüsselwerte X = {38, 104, 49, 57, 84, 86, 94, 43, 69, 109}, zugehörige
Datensätze werden vernachlässigt
- Hashwerte h(x) = {6, 8, 17, 25, 20, 22, 30, 11, 5, 13}
Zum Vergleich realistische Werte:
- b=100, b=1000 (abhängig von der Seitengröße und den Werten)
- h(x) mit h: S [0, 232-1] (für hinreichend viele Bitpositionen)
Datenbank- und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 30
Erweiterbares Hashing: Beispiel (2)
Ausgangslage
- Directory mit d=0, ein leeres Bucket
- Anzeige im Bucket: x [h(x) binär]
0
Einfügen der Werte {38, 104, 49, 57}
- Differenzierung gemäß "0. Bit" (also
keine) im Hashwert
- Alle Werte in Bucket B1
Einfügen von Wert 84
- Bucket-Überlauf in B1, deswegen
Splitting von B1 mit neuem B2
- Erhöhung der lokalen Tiefe (d'=1) in
Bucket B1 und B2
• Erhöhung globale Tiefe (d=1)
• Directory-Verdopplung
- Differenzierung bei (lokaler) Neuverteilung gemäß 1. Bit im Hashwert
Datenbank- und Informationssysteme
0
1
B1
38 [00110]
104 [01000]
B1
49 [10001]
57 [11001]
B1
38 [00110]
104 [01000]
0...
1...
Friedrich-Schiller-Universität Jena
B2
49 [10001]
84 [10100]
57 [11001]
Seite 31
Erweiterbares Hashing: Beispiel (3)
Einfügen von Wert 86
- Suche des zugehörigen Buckets
ergibt B2 aufgrund 1. Bitposition
- Freie Kapazität in B2
(3 = |B2| < b=4)
Einfügen von Wert 94
- Bucket-Überlauf in B2, deswegen
Splitting von B2 mit neuem B3
- Erhöhung der lokalen Tiefe (d'=2) in
Bucket B2 und B3
• Erhöhung globale Tiefe (d=2)
• Directory-Verdopplung
- Differenzierung bei Neuverteilung
gemäß ersten zwei Bits im Hashwert
- Bucket B1 bleibt unverändert mit
lokaler Tiefe d'=1
Datenbank- und Informationssysteme
1
B1
38 [00110]
104 [01000]
0...
1...
B2
2
B1
49 [10001]
84 [10100]
57 [11001]
86 [10110]
38 [00110]
104 [01000]
00...
01...
10...
B2
11...
Friedrich-Schiller-Universität Jena
B3
49 [10001]
84 [10100]
86 [10110]
57 [11001]
94 [11110]
Seite 32
Erweiterbares Hashing: Beispiel (4)
Einfügen der Werte {43, 69, 109}
- Wert 43 wird in Bucket B1 abgelegt
durch Zuordnung über "01..."
B1
- Wert 69 wird in Bucket B1 abgelegt
durch Zuordnung über "00..."
- Wert 109 würde in Bucket B1 abgelegt
durch Zuordnung über "01..."
• Überlauf in B1
• Splitting von B1 mit neuem B4
- Erhöhung der lokalen Tiefe für Bucket
B1 und B4 (d'=2)
- Keine Directory-Verdopplung, da
weiterhin die globale Tiefe mit d=2
(d=max(d')) bleibt
Datenbank- und Informationssysteme
2
00...
01...
104 [01000]
43 [01011]
B4
109 [01101]
10...
11...
Friedrich-Schiller-Universität Jena
69 [00101]
38 [00110]
B2
B3
49 [10001]
84 [10100]
86 [10110]
57 [11001]
94 [11110]
Seite 33
Erweiterbares Hashing: Fazit
Hashfunktion sollte gut gewählt sein
- Möglichst "zufälliges" Ergebnis liefern
- h(x) sollte an jeder Bitposition den Wert 0/1 mit gleicher
Wahrscheinlichkeit (0.5) generieren
- Hashverfahren reagieren empfindlich auf unausgewogene
Hashfunktionen
Eine Einfügung kann mehrere Directory-Verdopplungen zur Folge haben
- Alle betrachteten b+1 Hashwerte h(x) haben an Position i den gleichen
Wert 0 oder 1
- Bei guter Hashfunktion und großem Bucketkapazität b sehr selten
- Beispiel:
• b=2
• h(x): S [0, 31]
• Einfügereihenfolge: 2 (00010), 3 (00011), 6 (00110)
Datenbank- und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 34