Dateiorganisation und Zugriffsstrukturen

KAPITEL 3 

DATEIORGANISATION UND 

ZUGRIFFSSTRUKTUREN 

h_da Prof. Dr. Uta Störl Architektur von DBMS SoSe 2013 Kapitel 3: Dateiorganisation und Zugriffsstrukturen 1

Dateiorganisation und Zugriffsstrukturen 

Inhalte des Kapitels 

• Seiten, Sätze und Adressierung 

• Klassifikation der Speichertechniken 

• Baumverfahren 

• Hash-Verfahren 

• Klassifikation von Zugriffspfaden 

• Cluster-Bildung 

• Physische Datendefinition in relationalen DBMS 

• Spaltenorientierte Datenbanken 

Lernziele 

• Verstehen des internen Aufbaus von Seiten und Sätzen sowie deren 

Adressierung 

• Kenntnis der wichtigsten Dateiorganisationsformen und Arten von 

Zugriffspfaden wann sollte welche Art verwendet werden? 

• Kennenlernen von Möglichkeiten zur physischen Datendefinition in konkreten 

relationalen DBMS 


Einordnung in die 5-Schichten-Architektur 

Mengenorientierte Schnittstelle 

Datensystem 

Satzorientierte Schnittstelle 

Zugriffssystem 

Speichersystem 

Interne Satzschnittstelle 

Systempufferschnittstelle 

Pufferverwaltung 

Dateischnittstelle 

Betriebssystem 

Externspeicher 

Geräteschnittstelle 


Einordnung in die 5-Schichten-Architektur 

• Speichersystem fordert über Systempufferschnittstelle Seiten an 

• interpretiert diese als interne Datensätze 

• interne Realisierung der logischen Datensätze mit Hilfe von Zeigern, 

speziellen Indexeinträgen und weiteren Hilfsstrukturen 

• Zugriffssystem abstrahiert von der konkreten Realisierung 


Seitenzugriff als Flachenhals 

• Maß für die Geschwindigkeit von Datenbankoperationen: 

– Anzahl der Seitenzugriffe auf dem Sekundärspeicher (wegen 

Zugriffslücke) 

– aber auch Hauptspeicheroperationen nicht beliebig 

vernachlässigbar 

Geschwindigkeit des Zugriffs abhängig von der Qualität des 

Zugriffspfades, d.h. der Anzahl der benötigten Seitenzugriffe 

Seitenzugriff als Flaschenhals ist wichtige Randbedingung für die 

Implementierung aller darüber liegenden Strukturen und Schichten! 


Seiten, Sätze, Adressierung 

• Struktur der Seiten: doppelt verkettete Liste 

• Header, u.a. 

– Informationen über Vorgänger- und Nachfolger-Seite 

– Informationen über Typ der Sätze 

– Zeitstempel (für Recovery) 

– Angabe über freien Platz 

• Adressierung eines Satzes: 

– Beispielsweise durch Seitennummer und Offset (relative Adresse in Bytes 

vom Seitenanfang) - Beispiel: (115, 142) 


Einpassen von Datensätzen in Seiten 

• Nichtspannsätze: jeder Datensatz in maximal einer Seite 

• Spannsätze: Datensatz eventuell in mehreren Seiten 

• Standard: Nichtspannsätze (nur im Falle von BLOBs oder CLOBs Spannsätze 

üblich) 


Speichervarianten für Sätze variabler Länge 

n 1 

• Vorteil Strategie b): leichtere Navigation innerhalb des Satzes 


TID-Konzept: Motivation 

• Bisher: Adressierung eines Satzes durch Seitennummer und Offset, 

wobei der Offset die relative Adresse in Bytes vom Seitenanfang ist – 

z.B. (115, 142) 

• Diese Adresse wird in Verweisen von außen, z.B. in Index-Einträgen etc. 

verwendet. 

• Was passiert beim Verschieben eines Satz? 

Konzept notwendig, welches beim Verschieben eines Satzes innerhalb 

der Seite nicht zum Anpassen der Verweise führt. 

Tupel Identifier (TID) (oft auch als Record Identifier (RID) bezeichnet) 

in relationalen Datenbanksystemen heute Stand der Technik 


TID-Konzept – 1(3) 

• Tupel-Identifier (TID) ist Datensatz-Adresse bestehend aus Seitennummer und 

Offset 

• Offset verweist innerhalb der Seite bei einem Offset-Wert von i auf den i-ten 

Eintrag in einer Liste von Tupel-Zeigern, die am Anfang der Seite stehen 

• Jeder Tupel-Zeiger enthält Offsetwert innerhalb der Seite 

Verschiebung auf der Seite: sämtliche Verweise von außen bleiben 

unverändert 



• Verschiebungen auf eine andere Seite: statt altem Datensatz neuer TID-Zeiger 

• mehrstufige Referenz (> 2) aus Effizienzgründen nicht wünschenswert - 

Lösungsvariante? 

• außerdem: Reorganisation in regelmäßigen Abständen 



• Alternative: fester, logischer TID – in der Literatur auch Data Base Key genannt 

bzw. im objektobjektorientierten und objektrelationalem Kontext: Object 

Identifier (OID) 

– Zuordnungstabelle mit OID und phys. Adresse (Page Pointer PP) 

– in Indexen etc. wird OID verwendet 

keine Änderungen in Indexen bei Verschieben des Datensatzes notwendig 

aber: immer 2 Seitenzugriffe 

außerdem: Hotspot beim Locking 

Modifikation: Verwenden eines Probable Page Pointer (PPP) 

– in Indexen etc. wird sowohl die OID als auch der PPP gespeichert 

– Bei Änderungen (erstmal) nur Anpassung des PP in Zuordnungstabelle 

(nicht PPP in Indexen) 

– Zugriff: normalerweise über PPP (nur 1 Seitenzugriff) 

– falls Datensatz an Position des PPP nicht gefunden wird → „langer“ Weg 

über OID und PP (3 Seitenzugriffe) – außerdem Anpassung PPP 


Seitenstruktur in IBM DB2 

• Datensatzadressen als 

relative Byteadresse 

auf der jeweiligen 

Seite 

• Gelöschte Datensätze 

werden durch -1 

repräsentiert 

• Freispeicher: nur der 

zusammenhängende 

Bereich nach dem 

Satzverzeichnis 

Quelle: Saake/Heuer/Sattler:2005 


Oracle: Seitenaufbau und Parameter 

• Mit den Parametern pctfree und pctused kann die 

Speicherplatzausnutzung in den Seiten (Database Block) beeinflusst werden 

Auswirkungen auf die Performance von Änderungsoperationen 

Quelle: Oracle Database Administrator's Guide 10g:2004 


Oracle: Storage Parameter 

• Weitere Storage Parameter für Oracle-Tabellen: 

create table tabelle ( ...) 

pctfree 20 pctused 40 

storage ( 

initial 10MB, next 2MB, 

minextents 1, maxextents 20, 

pctincrease 0, freelists 3 ) 

tablespace USER_TBLSPACE; 

• pctfree: Seitenanteil, der nicht für insert-Operationen genutzt werden 

soll (Reservebereich für update); Default 10 

• pctused: Grenze, bei der eine zuvor bis zu pctfree gefüllte Seite wieder 

für insert genutzt werden darf; Default 40 

• freelists: Anzahl der Freispeicherlisten (insb. für paralleles Einfügen) 



Seiten, Sätze und Adressierung 

• Klassifikation der Speichertechniken 








Speichertechniken 

• Motivation: Ablage von Datensätzen in Seiten 

– technische Sicht (wie): voriger Abschnitt 

– Zuordnung (welche Datensätze in welchen Seiten) noch nicht 

diskutiert – ist aber entscheidend für die Effizienz des Zugriffs! 

(Stichwort: Seitenzugriff als Flaschenhals) 

– außerdem: zusätzliche Strukturen (Indexdateien, Zugriffspfade) für 

effizienten Zugriff 

• Speichertechniken (insbesondere Zugriffspfade) waren und sind eines 

DER Themen in der Datenbankforschung und -literatur, da ihre 

effiziente Umsetzung – abhängig vom jeweiligen Anwendungskontext – 

einer der entscheidenden Faktoren für die Datenbank-Performance ist. 


• Kriterien 

Klassifikation der Speichertechniken 

– wird interne Relation selbst organisiert (Dateiorganisationsform) 

oder zusätzliche Zugriffsmöglichkeit auf bestehende interne 

Relation realisiert (Zugriffspfad) 

– Art der Zuordnung von gegebenen Attributwerten zu Datensatz- 

Adressen 

– Arten von Anfragen, die durch Dateiorganisationsformen und 

Zugriffspfade effizient unterstützt werden können 


Anforderungen an Speichertechniken 

• dynamisches Verhalten 

• Effizienz beim Einzelzugriff (Schlüsselsuche beim Primärindex) 

• Effizienz beim Mehrfachzugriff (Schlüsselsuche beim Sekundärindex) 

• Ausnutzung für sequentiellen Durchlauf (Sortierung, geclusterter Index) 

• Clustering 

• Anfragetypen: exact-match, partial-match, range queries 

(Bereichsanfragen) 


Dateiorganisation vs. Zugriffspfad 

• Dateiorganisationsform: Form der Speicherung der internen Relation 

– unsortierte Speicherung von internen Tupeln: Heap-Organisation 

– sortierte Speicherung von internen Tupeln: sequenzielle 

Organisation 

– gestreute Speicherung von internen Tupeln: Hash-Organisation 

– (Speicherung von internen Tupeln in mehrdimensionalen Räumen: 

mehrdimensionale Dateiorganisationsformen) 

• üblich: zusätzliche sortierter Zugriffspfad über Primärschlüssel 


Dateiorganisation vs. Zugriffspfad 

• Zugriffspfad: über grundlegende Dateiorganisationsform 

hinausgehende Zugriffsstruktur, etwa Indexdatei mit Einträgen (K, K↑): 

• K: Suchschlüssel, genauer: Zugriffsattribute und Zugriffsattributwerte 

• K↑: 

– ist Datensatz selbst Zugriffspfad wird Dateiorganisationsform 

– ist Adresse genau eines internen Tupels Primärschlüssel 

– ist Liste von Tupeladressen Sekundärschlüssel 

mit (K, K↑ 1 ), ... , (K, K↑ n ) für denselben Zugriffsattributwert 












Wiederholung 

DB (Bachelor) 

Baumverfahren 

• Stufenanzahl dynamisch verändern 

• wichtigste Baumverfahren: B-Bäume und ihre Varianten 

• B-Baum-Varianten sind allgegenwärtig in heutigen Datenbanksystemen 

(egal ob relational, objektrelational, objektorientiert, …) 

B-Bäume 

• ausgeglichener, balancierter Suchbaum 

• Ausgeglichen oder balanciert: alle Pfade von der Wurzel zu den Blättern 

des Baumes gleich lang 

• Hauptspeicher-Implementierungsstruktur: binäre Suchbäume, 

beispielsweise AVL-Bäume von Adelson-Velskii und Landis 

• Datenbankbereich: Knoten der Suchbäume zugeschnitten auf 

Seitenstruktur des Datenbanksystems 

• mehrere Zugriffsattributwerte auf einer Seite = Mehrwegbäume 


Wiederholung 

DB (Bachelor) 

Prinzip des B-Baumes 

• B-Baum von Bayer (B für balanciert, breit, Bayer, NICHT: binär) 

• dynamischer, balancierter Indexbaum, bei dem jeder Indexeintrag auf eine 

Seite der Hauptdatei zeigt 

• Mehrwegbaum völlig ausgeglichen, wenn 

– 1. alle Wege von Wurzel bis zu Blättern gleich lang 

– 2. jeder Knoten gleich viele Indexeinträge 

• vollständiges Ausgleichen zu teuer, deshalb B-Baum-Kriterium: 

– Jede Seite außer der Wurzelseite enthält zwischen m und 2m Einträge. 


Wiederholung 

DB (Bachelor) 

Seitenformat des B-Baums 

• Seitenformat: 

Z 0 S 1 Z 1 D 1 S 2 Z D 2 S … S m Z D 

2 

3 

m 

m 

frei 

Z i = Zeiger auf Seite der nächsten Stufe 

S i = Schlüssel (Zugriffsattributwert) 

D i = Daten des Satzes oder Verweis auf den Satz (bzw. die Sätze) 

d.h. materialisiert oder referenziert 

• B-Baum als Primär- und Sekundärindex geeignet 

• Datensätze direkt in die Indexseiten Dateiorganisationsform 


Wiederholung 

DB (Bachelor) 

Definition B-Baum 

• Ordnung eines B-Baumes ist minimale Anzahl der Einträge auf den 

Indexseiten außer der Wurzelseite 

• Bsp.: B-Baum der Ordnung 8 faßt auf jeder inneren Indexseite zwischen 

8 und 16 Einträgen 

• Def.: Ein Indexbaum ist ein B-Baum der Ordnung m, wenn er die 

folgenden Eigenschaften erfüllt: 

1. Jede Seite, außer der Wurzelseite, enthält mindestens m Elemente. 

Jede Seite enthält höchstens 2m Elemente. 

2. Alle Blattseiten liegen auf der gleichen Stufe. 

3. Die Elemente werden in allen Seiten sortiert gespeichert. Jede 

Seite ist entweder eine Blattseite ohne Nachfolger oder 

hat i + 1 Nachfolger, falls i die Anzahl ihrer Elemente ist. 

4. Für einen Element E i gilt, dass die Werte zwischen E i-1 und E i im 

linken Teilbaum und die Werte zwischen E i und E i+1 im rechten 

Teilbaum gespeichert werden. 


Wiederholung 

DB (Bachelor) 

Suchen in B-Bäumen 

lookup 

• startend auf Wurzelseite Eintrag im B-Baum ermitteln, der den 

gesuchten Zugriffsattributwert w überdeckt Zeiger verfolgen, Seite 

nächster Stufe laden 

• Beispiel: Suchen: 38, 20, 6 


Wiederholung 

DB (Bachelor) 

Einfügen in B-Bäumen 

• Beispiel (m = 1) 


Wiederholung 

DB (Bachelor) 


• Beispiel (Fortsetzung) 


Wiederholung 

DB (Bachelor) 


insert: Einfügen eines Wertes w 

• mit lookup entsprechende Blattseite suchen 

– passende Seite n < 2m Elemente w einsortieren 

– passende Seite n = 2m Elemente neue Seite erzeugen, 

ersten m Werte auf Originalseite 

letzten m Werte auf neue Seite 

mittleres Element auf entsprechende Indexseite nach oben 

– ggf. diesen Prozess rekursiv bis zur Wurzel wiederholen 


Wiederholung 

DB (Bachelor) 

Löschen in B-Bäumen 

bei weniger als m Elementen auf Seite: Unterlauf 

delete: Löschen eines Wertes w 

• mit lookup entsprechende Seite suchen 

– w auf Blattseite gespeichert Wert löschen; ggf. Unterlauf behandeln 

– w nicht auf Blattseite gespeichert Wert löschen, durch lexikographisch 

nächstkleineres Element von einer Blattseite ersetzen; ggf. Unterlauf auf 

Blattseite behandeln 

• Unterlaufbehandlung 

– Ausgleichen mit der benachbarten Seite (benachbarte Seite n Elemente 

mit n > m) 

– oder Zusammenlegen zweier Seiten zu einer (Nachbarseite n = m 

Elemente), das „mittlere“ Element von Indexseite darüber dazu; auf 

Indexseite ggf.Unterlauf behandeln 


Wiederholung 

DB (Bachelor) 

Löschen in B-Bäumen 

• Beispiel (m = 2) : Löschen von 22 


B-Bäume: Komplexität der Operationen 

• n Datensätze in der Hauptdatei 

Aufwand beim Einfügen, Suchen und Löschen im B-Baum immer 

O(log m (n)) Operationen 

• Konkretes Beispiel: 

– Seiten der Größe 4 KB, Zugriffsattributwert 32 Bytes, 8-Byte-Zeiger 

zwischen 50 und 100 Indexeinträge pro Seite 

Ordnung dieses B-Baumes 50 

– 1.000.000 Datensätze 

log 50 (1.000.000) = 4 Seitenzugriffe im schlechtesten Fall 

– Wurzelseite jedes B-Baumes normalerweise im Puffer 

3 Seitenzugriffe 

– Wieviel Seitenzugriffe würde der Zugriff ohne Index benötigen? 


Varianten 

• B + -Bäume: Daten nur auf den Blattseiten 

• B*-Bäume: Aufteilen von Seiten vermeiden durch „Shuffle“ 

• Präfix-B-Bäume: Zeichenketten als Zugriffsattributwerte, nur Präfix 

indexieren 


B + -Baum: Prinzip 

• in der Praxis am häufigsten eingesetzte Variante des B-Baumes: 

effizientere Änderungsoperationen, Verringerung der Baumhöhe 

• Daten nur auf den Blattseiten – innere Knoten enthalten nur Schlüssel 

und Zeiger auf nachfolgenden Seite der nächsten Stufe: 

• Seitenformat innere Knoten: 

Z 0 S 1 Z 1 S 2 Z 2 S 3 … S m Z m 

frei 

Z i = Zeiger auf Seite der nächsten Stufe 

S i = Schlüssel 

• Seitenformat Blattknoten: 

V S 1 D 1 S 2 D 2 S … S m D frei 3 m 

N 

S i = Schlüssel 

D i = Daten des Satzes oder Verweis auf den Satz 

V = Vorgänger-Zeiger N = Nachfolger-Zeiger 


Beispiel: B-Baum vs. B + -Baum 

13 Schulz … 

14 Meier … 

• keine Daten in den inneren Knoten 

es passen mehr Einträge auf eine Seite 

Reduktion der Höhe des Baumes 

weniger Seitenzugriffe bei lookup, insert, delete (aber jetzt immer log m (n)) 


Variante des B + -Baum 

• Speicherung der Datensätze(!) in den Blattseiten 

schnelle fortlaufende Verarbeitung aller Datensätze in auf- oder 

absteigender Sortierreihenfolge! 

Verschmelzen von Zugriffsstruktur und Dateiorganisation 


B*-Baum 

• Problem beim B-Baum bzw. B + -Baum: häufiges Aufspalten von Seiten 

und geringe Speicherplatzausnutzung von nahe 50% 

• B*-Baum: 

– statt Aufteilen von Seiten bei Überlauf zunächst Neuverteilen der 

Datensätze auf eventuell nicht voll ausgelastete Nachbarseiten 

– falls nicht möglich: zwei Seiten in drei aufteilen ohne Verschiebung 

eines Elements nach oben (ermöglicht durchschnittliche 

Speicherplatzausnutzung von 66% statt 50%) 


Speicherbedarf für B-Baum 

• Wie kann der maximale Speicheraufwand für einen B-Baum 

abgeschätzt werden? 





Baumverfahren 







Hash-Verfahren: Grundprinzip 

• Basis-Hash-Funktion: h(k) = k mod m mit m möglichst Primzahl 

• Überlauf-Behandlung 

– Überlaufseiten als verkettete Liste 

– lineares Sondieren h i (k) = (h(k) + i) mod m 

– quadratisches Sondieren h i (k) = (h(k)+ i 2 ) mod m 

– doppeltes Hashen h i (k) = (h(k) + h'(k)*i) mod m 


Hash-Verfahren für Datenbanken 



Operationen und Zeitkomplexität 

• lookup, modify, insert, delete 

– lookup benötigt maximal 1 + #B(h(w)) Seitenzugriffe 

mit #B(h(w)) Anzahl der Seiten (inklusive der Überlaufseiten) des 

Buckets für Hash-Wert h(w) 

– Untere Schranke 2 (Zugriff auf Hash-Verzeichnis plus Zugriff auf 

erste Seite) 

– Zeitschranke für modify, insert und delete? 

sehr effizient für Suche einzelner Werte (konstante Zugriffskosten - bei 

ausreichendem Speicherplatz und gut streuender Hash-Funktion 

2 Zugriffe!) 

• Bereichsanfragen? 

• sortierte Ausgabe von Datensätzen? 


Probleme bei statischen Hash-Verfahren 

• Hash-Funktion bildet die Schlüsselwerte auf einen festen Bildbereich ab 

• Was passiert, wenn dieser erweitert werden muss? 

– neue Hash-Funktion 

– Reorganisation (Re-Hashing) aller Datensätze! 

Dynamisches Hashen 

– Idee: feste Hash-Funktion, aber dynamisch erweiterbarer 

Bildbereich 

– Verschiedene Realisierungsvarianten 

• Lineares Hashen 

• Erweiterbares Hashen 

• Spiral-Hashen 


Prinzip lineares Hashen 

• Folge von Hash-Funktionen, die wie folgt charakterisiert sind: 

– h i : dom(Primärschlüssel) → { 0, . . . , 2 i × N }: eine Folge von Hash- 

Funktionen mit i ∈ { 0, 1, 2, . . .} und N als Anfangsgröße des Hash- 

Verzeichnisses 

– Wert von i: Level der Hash-Funktion 

• Für diese Hash-Funktionen gelten die folgenden Bedingungen: 

– h i+1 (w) = h i (w) für etwa die Hälfte aller w ∈ dom(Primärschlüssel) 

– h i+1 (w) = h i (w) + 2 i × N für die andere Hälfte 

– Bedingungen sind zum Beispiel erfüllt, 

wenn h i (w) als w mod (2 i × N) gewählt wird 


Realisierung lineares Hashen 

• Zu einem Zeitpunkt: für ein w höchstens zwei Hash-Funktionen 

zuständig, deren Level nur um 1 differiert 

• Entscheidung zwischen diesen beiden durch Split-Zeiger 

– sp Split-Zeiger (gibt an, welche Seite als nächstes geteilt wird) 

– lv Level (gibt an, welche Hash-Funktionen benutzt werden) 

lookup: 

s := h lv (w); 

if s < sp then 

s := h lv+1 (w); 

• zuerst Hash-Wert mit der „kleineren“ Hash-Funktion bestimmen 

• liegt dieser unter dem Wert des Split-Zeigers größere Hash-Funktion 

verwenden 


Beispiel für lineares Hashen 

0 

• Schlüsselwerte (zur Vereinfachung): Bitfolgen 

• Hash-Funktion: die ersten n Bits in umgekehrter Reihenfolge als Zahl, 

d.h. h 1 interpretiert die erste Zahl, h 2 die ersten beiden usw. 



Splitten einer Seite 

1. Die Sätze der Seite (Bucket), auf die sp zeigt, werden mittels h lv+1 neu 

verteilt 

ca. die Hälfte der Sätze wird auf Seite (Bucket) unter Hash-Nummer 

2 lv × N + sp verschoben 

2. Der Split-Zeiger wird weitergesetzt: sp := sp + 1; 

3. Nach Abarbeiten eines Levels wird wieder bei Seite 0 begonnen; der 

Level wird um 1 erhöht 


Beispiel für lineares Hashen 

Beispiel: h 2 (0010000) = 00 < 1 → h 3 (0010000) = 001 



… nach Splitten einer Seite … 



… nach Splitten zweier weiterer Seiten 

Nachteile des 

Verfahrens? 






Baumverfahren 

Hash-Verfahren 






Klassifikation von Zugriffspfaden 

Verschiedene (i.a. orthogonale) Möglichkeiten der Klassifikation: 

• dünnbesetzter vs. dichtbesetzter Index 

• geclusterter vs. nicht-geclusterter Index 

• Ein-Attribut vs. Mehr-Attribut-Index 


Dünn- vs. dichtbesetzter Index 

• dünnbesetzter Index: nicht für jeden Zugriffsattributwert K ein Eintrag 

in Indexdatei 

– interne Relation sortiert nach Zugriffsattributen: im Index reicht ein 

Eintrag pro Seite Index verweist mit (K 1 ,K 1 ↑) auf Seitenanführer, 

nächste Indexeintrag (K 2 ,K 2 ↑) 

– Datensatz mit Zugriffsattributwert K ? mit K 1 < K ? < K 2 ist auf Seite 

von K 1 ↑ zu finden 

• dichtbesetzter Index: für jeden Datensatz der internen Relation ein 

Eintrag in Indexdatei 

indexsequenzielle Datei: sortierte Datei mit dünnbesetztem Index als 

Primärindex 

Primärindex muss dichtbesetzter Index sein, wenn 

Dateiorganisationsform Heap-Datei 


Geclusterter vs. nicht-geclusterter Index – 1(2) 

• geclusterter Index: in der gleichen Form sortiert wie interne Relation 

– Bsp.: interne Relation KUNDEN nach Kundennummern sortiert 

Indexdatei über dem Attribut KNr üblicherweise geclustert 

• nicht-geclusterter Index: anders organisiert als interne Relation 

– Bsp.: über Name ein Sekundärindex, Datei selbst nach KNr sortiert 

jeder dünnbesetzte Index ist auch geclusterter Index, aber nicht 

umgekehrt 

Sekundärindex kann nur dichtbesetzter, nicht-geclusterter Index sein 


Geclusterter vs. nicht-geclusterter Index – 2(2) 



Ein-Attribut- vs. Mehr-Attribut-Index 

• Ein-Attribut-Index (non-composite index): Zugriffspfad über einem 

einzigen Zugriffsattribut 

• Mehr-Attribut-Index (composite index): Zugriffspfad über mehreren 

Attributen 

• Bsp.: Attribute Name und PLZ unterstützen 

– entweder zwei Ein-Attribut-Indexe 

– oder ein Zwei-Attribut-Index über beiden Attributen 

• Vorteil Mehr-Attribut-Index: bei exact-match nur ein Indexzugriff 

(weniger Seitenzugriffe) 

• Mehr-Attribut-Index: Ausführungsart bestimmt, ob neben exact-match 

auch noch partial-match effizient unterstützt wird (eindimensional 

oder mehrdimensional) 


Ein- vs. mehrdimensionale Zugriffsstruktur 

• Ein-Attribut-Index immer eindimensionale Zugriffsstruktur: 

(Zugriffsattributwerte definieren lineare Ordnung in eindimensionalem 

Raum) 

• Mehr-Attribut-Index ist eindimensionale oder mehrdimensionale 

Zugriffsstruktur: 

– eindimensionaler Fall: Kombinationen der verschiedenen 

Zugriffsattributwerte konkateniert als einen einzigen 

Zugriffsattributwert betrachten (wieder lineare Ordnung in 

eindimensionalem Raum) keine partial-match-Anfragen 

– mehrdimensionaler Fall: Menge der Zugriffsattributwerte spannt 

mehrdimensionalen Raum auf bei partial-match bestimmt 

horizontale oder vertikale Gerade im Raum die Treffermenge 

mehrdimensionale Bäume 

mehrdimensionale Hash-Verfahren 

Grid-Files 


Weitere Zugriffsstrukturen 

Spezifische Anforderungen für 

• Geometrische Strukturen in Geoinformationssystemen, CAD-Systemen etc. 

– mehrdimensionale Bäume (insbesondere Quadtrees, R-Bäume, Grid-Files) 

• Multimedia-Daten 

– mehrdimensionale Bäume, hochdimensionale Index für Feature-Vektoren 

• Objektstrukturen 

– hierarchische Indexe für Klassen- und Komponentenhierarchien 

• Information Retrieval 

– invertierte Listen, Signaturindexe 

• XML 

– Pfadindexe 

• Data Warehouse 

– Bitmap-Indexe, UB-Bäume 

• … 

Literatur (Überblick und weitere Referenzen): 

G. Saake, A. Heuer, und K. Sattler: Datenbanken: Implementierungstechniken. 





Baumverfahren 







Cluster-Bildung 

• Ziel: gemeinsame Speicherung von (zusammengehörigen) Datensätzen 

auf Seiten 

• wichtige Spezialfälle: 

– Clusterung nach Schlüsselattributen 

Bereichsanfragen und Gruppierungen unterstützen: 

Datensätze in der Sortierreihenfolge zusammenhängend auf Seiten 

speichern index-organisierte Tabellen 

– Clusterung basierend auf Fremdschlüsselattributen 

Gruppen von Datensätzen, die einen Attributwert gemeinsam 

haben, werden auf Seiten gemeinsam gespeichert 

(Verbundanfragen) 


• Verbundattribut: 

Cluster-Schlüssel 

Cluster für Verbundanfragen 



• Oracle-Notation: 

Definition von Clustern 

create cluster BESTELL_CLUSTER 

(BestellNr int) 

pctused 80 pctfree 5; 

create table BESTELLUNG ( 

BestellNr int primary key, ...) 

cluster BESTELL_CLUSTER (BestellNr); 

create table BESTELL_POSITION ( 

Position int, 

BestellNr int references BESTELLUNG, 

... 

constraint BestellPosKey primary key (Position, BestellNr) 

) 

cluster BESTELL_CLUSTER (BestellNr); 


Organisation von Clustern 

• Indexierte Cluster nutzen einen in Sortierreihenfolge aufgebauten Index 

(z.B. B + -Baum) über den Cluster-Schlüssel zum Zugriff auf die Cluster 

– Speicherung von Cluster-Identifikatoren anstelle von TIDs 

create index BESTELL_CLUSTER_IDX 

on cluster BESTELL_CLUSTER; 

• Hash-Cluster bestimmen den passenden Cluster mit Hilfe einer 

Hashfunktion 

– Abbildung Cluster-Schlüssel → Blockadresse 

create cluster BESTELL_CLUSTER (BestellNr int) 

pctused 80 

pctfree 5 

size 2k 

hash is BestellNr 

hashkeys 100000; 


Oracle: Datenorganisation und Zugriffspfade – 1(2) 

• Standardtabellen als Heap 

• Standard-Index: B+-Baum 

• Anlegen von index-organisierten Tabellen möglich: speichern Tupel 

direkt in den Blättern eines B+-Baums 

• Clusterung mehrerer Relationen möglich; Cluster-Indexe als B+-Baum 

oder als Hash-Index 

• Bitmap-Indexe für Data Warehouse 

• benutzerdefinierte funktions-basierte Indexe 


Oracle: Datenorganisation und Zugriffspfade – 2(2) 

• Index-organisierte Tabelle 

create table tabelle ( ...) 

organization index 

tablespace USER_TBLSPACE, 

pctthreshold 20 

overflow tablespace OVER_TBLSPACE; 

– Ablage der Daten in den Blättern des B+-Baums 

– pctthreshold: Threshold für Speicherung von nicht-indexierten 

Attributen im Überlaufbereich (Wert: 1-50 – Prozentsatz der 

Blockgröße) 

– optional including: Festlegung der im Index aufzunehmenden 

Attribute (alle weiteren → Überlaufbereich) 


DB2: Datenorganisation und Zugriffspfade 

• Standardtabellen als Heap 

• Append-Mode-Tabellen, die für insert-Operationen optimiert sind 

(Einfügen immer am Ende) 

• bereichsgeclusterte Tabellen 

• Multidimensionale Clustering-Tabellen 

• Standard-Index: B+-Baum 

• auch geclusterte Indexe möglich: 

create index name 

on tabelle (attribut) cluster; 

• benutzerdefinierte funktions-basierte Indexe 

• … 


Microsoft SQL Server: 

Datenorganisation und Zugriffspfade 

create [ unique ] 

[ clustered | nonclustered ] index name 

on table-name ( ...) 

[ with fillfactor = value, pad_index, ...] 

• nicht-geclusterter Index: nur Row-IDs in Blattseiten 

• geclusterter Index: Datensätze auf Blattseiten 

• fillfactor: frei zu haltender Platz für Blattseiten beim Aufbau (pad_index auch 

für mittlere Seiten) 

• weitere spezielle Indexstrukturen: 

– Indexe auf berechneten Spalten 

– indexierte Sichten (geclusterter Index auf Sicht) ≡ materialisierte Sicht 


Trend 

Self-tuning DBMS: Indexempfehlungen 

Motivation 

• Indexe erhöhen die Performance beim Zugriff drastisch 

• aber: Indexverwaltung ist zusätzlicher Overhead 

Ziel 

• Basierend auf Workload-Auswertung Empfehlung geeigneter Indexe 

Herausforderungen 

• Wie ermittelt man, ob ein Index etwas bringt (bringen würde)? 

• Komplexität der Ermittlung 

– Menge von Anfragen Q 1 , ..., Q m 

– Indexkandidaten I 1 , ..., I n mit Größe und Verwaltungskosten 

– Profit von I i bzgl. Q k 

– Aufgabe: Finde Indexkonfiguration C ⊆ { I 1 , ..., I n } 

• die Größenbeschränkung einhält und 

• Gesamtprofit (unter Berücksichtigung der Verwaltungskosten) maximiert 

Rucksack-Problem (knapsack) – Komplexität? 


Trend 

Self-tuning DBMS: Indexempfehlungen 

Typische Vorgehensweise (in ähnlicher Form in den neuesten Versionen von DB2, 

Oracle, MS SQL Server implementiert) 

• Input: Workload 

– durch DBA vorgegebenes (gewichtetes) SQL-Statement-Profil 

– teilweise vom DBMS gesammelte Informationen über SQL-Statements 

• Verarbeitung 

– Durchrechnen verschiedener Konfigurationsvarianten mit Hilfe des 

Optimizers („what if“ Index) 

• Output: Vorschläge zum Anlegen bzw. Löschen von 

– Indexen 

– materialisierten Sichten 

– horizontalen Tabellenpartitionierung (siehe Kapitel 7) 





Baumverfahren 



Cluster-Bildung 

Physische Datendefinition in relationalen DBMS 



Trend 

Spaltenorientierte DBMS: Motivation 

• Charakteristika von Operationen in verschiedenen Anwendungsszenarien: 

• OLTP: Lese- und Schreiboperationen auf einzelnen Datensätzen 

– beim kompletten Lesen einer Tabelle werden viele nicht benötigte 

Datensätze gelesen 

– Optimierung des gezielten Zugriffs auf Datensätze mit Indexen 

• OLAP: Leseoperationen auf vielen Datensätzen (wobei i.a. nur einzelne 

Attribute relevant sind) 

– beim kompletten Lesen einer Tabelle werden viele nicht benötigte 

Attributwerte gelesen 

Optimierung durch viele Indexe (ggf. Index auf jedem Attribut) 

Alternative: vertikale Partitionierung (siehe Kapitel 7) 

Neuer Ansatz: 

Column-Oriented Database Systems (Spaltenorientierte DBMS) 


Trend 

Spaltenorientierte DBMS: Idee 

• Fundamentale Veränderung der Art, wie Datensätze gespeichert werden: 

+ Einfaches Insert / Update + Nur Lesen relevanter Daten 

− Lesen nicht benötigter Daten + Bessere Kompressionsmöglichkeiten 

− Insert / Update aufwändig 

− Zusammenfügen versch. Daten aufwändig 

suitable for read-mostly, read-intensive, large data repositories 

Quelle: Harizopoulos/Abadi/Boncz: VLDB2009 


Spaltenorientierte DBMS: 

Historie* und Literatur 

• Erste Papiere mit ähnlichen Ansätzen schon in den 70er Jahren 

• 1985: DSM-Paper: G. P. Copeland and S. Khoshafia: A decomposition storage 

model. SIGMOD Conference 1985 

• 1990er Jahre: Kommerzialisierung durch Sybase IQ 

• bis 2000: Überwiegend im Kontext von Main-Memory-Datenbanken erforscht 

und eingesetzt 

Trend 

• seit 2005: Wiedergeburt Lese-optimierter DBMS als Column Store mit 

Systemen wie C-Store, MonetDB/X100 etc. 

Wichtige Paper: 

– M. Stonebraker, D. J. Abadi, A. Batkin et al.: C-Store: A Column-oriented 

DBMS. VLDB 2005 

– D. J. Abadi, S. Madden, N. Hachem: Column-stores vs. row-stores: how 

different are they really? SIGMOD Conference 2008 

– D. J. Abadi, P. A. Boncz, S. Harizopoulos: Column-oriented Database 

Systems. VLDB Conference 2009 

– Weitere Paper zu vertiefenden Themen rund um Column-oriented 

Database Systems auf allen aktuellen DB-Konferenzen (BTW, SIGMOD, 

VLDB, EDBT) 

*Quelle: Harizopoulos/Abadi/Boncz: VLDB2009 


Trend 

Spaltenorientierte DBMS: Konzepte (1) 

• Kompression 

– Spalten lassen sich besser komprimieren als Zeilen 

– Typische* Kompressionsraten: 1:3 für row-store, 1:10 für columnstore 

– Warum? 

– Diverse Kompressionsalgorithmen (Run-length Encoding, Bit-vector 

Encoding, Differenatial Encoding etc.) 

– Datenbankoperationen: so lange wie möglich auf komprimierten 

Daten arbeiten Anpassung der Implementierung der 

Datenbankoperationen notwendig bzw. Einführung neuer 

Operatoren 

*Quelle: Harizopoulos/Abadi/Boncz: VLDB2009 


Trend 

Spaltenorientierte DBMS: Konzepte (2) 

• Leseoperationen 

– Wann werden Tuple „zusammengesetzt“? 

early materialization vs. late materialization 

(nahezu) alle Datenbankoperationen müssen angepasst werden 

bzw. neue Operatoren eingeführt werden 

• Änderungsoperationen (insert / delete) 

– Problem? 

• I/O für jede Spalte 

• Re-Komprimierung 

Kein update-in-place sondern differential lists mit regelmäßigen 

merge-Operationen 

Anpassung der Lese- und Schreiboperatoren! 

Anpassung des Transaktionskonzepts! 

Vertiefung dieser Themen in Vorlesung „Big Data Technologien“ 


Trend 

Spaltenorientierte DBMS: Systeme 

Kommerziell 

• Sybase IQ 

• Vertica 

• VectorWise 

• 1010data 

• ParAccel 

• Infobright 

• IBM Informix Warehouse Accelarator 

• Exasol 

• SAP HANA 

• …. 

Open Source 

• MonetDB 

• Infobright 

• (C-Store) 

• … 


Trend 

Spaltenorientierte DBMS: Alternativen 

• Alternativen bzw. Simulation des Column-Store in einem Row-based 

Datenbankmanagementsystem: 

Quelle: Harizopoulos/Abadi/Boncz: VLDB2009 


Trend 

Spaltenorientierte DBMS: Alternativen 

• SSBM (Star Schema Benchmark): sehr verbreiteter Data Warehouse 

Benchmark (basiert auf TPC-H Benchmark Datenmodell) 

Quelle: Abadi: 2008 


Trend 

Spaltenorientierte DBMS: Trend 

• Hybride Column-Row-Systeme 

– Row-Store-Systeme um Vorteile eines Column-Stores anreichern? 

• Oracle: erste Ansätze in Oracle 11g Release 2 auf Exadata Systemen 

(Appliance) hybrid columnar compression 

• MS SQL Server (Projekt Apollo, BTW 2013) 

– MS SQL Server 2012: neuer Indextype: COLUMNSTORE 

» Secondary index only, not updateable 

– MS SQL Server vNext 

» Updateable column store index 

» Can be used as base storage (clustered index) 

• SAP HANA (Appliance): Row-Store und Column-Store 

• IBM Smart Analytics Optimizer 

– Column-Store-Systemen Eigenschaften von Row-Store-Systemen 

hinzufügen? 


• Satzadressierung: TID-Konzept 

• Dateiorganisation 

Zusammenfassung 

– Heap-Speicherung als Standard 

– indexsequenzielle Organisation 

– Clusterbildung 

• Zugriffspfade 

– B-Baum und Varianten 

– Hash-Verfahren, insbesondere dynamische Hash-Verfahren 

• Aktuelle Entwicklung für lese-intensive Anwendungen mit sehr großen 

Datenmengen: Spaltenorientierte DBMS (Column-oriented Database 

Systems) 


Architektur von Datenbanksystemen 

Architektur von Datenbanksystemen 

Verwaltung des Hintergrundspeichers 


• Basisalgorithmen für Datenbank-Operationen 

• Anfrageoptimierung 

• Transaktionsverwaltung und Recovery 

• Verteilte Datenbankarchitekturen 

• Aktuelle Entwicklungen

Dateiorganisation und Zugriffsstrukturen

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?