Satzmengenverwaltung

Satzmengenverwaltung
Kapitel 8 Satzmengenverwaltung

Gegenstand des Kapitels
Datenmodell Performanz Datentypen: Satzmengen Operatoren: Operatoren auf Mengen Mengenorientiertes Datenmodell Anfragebearbeitung Optimaler Einsatz der logischen Ressourcen Datentypen: Sätze und Satzmengen Operatoren: Operatoren auf Sätzen Satzorientiertes Datenmodell Satz- u. Satzmengenverwaltung Vorschau auf zukünftig benötigte Daten Datentypen: phys. Zugriffsstrukturen auf Sätze Operatoren: seq. Durchlauf, gezielte Suche Satzzugriffsstrukturen Zugriffsschicht Vermeiden nicht aktuell benötigter Daten Transparenter homogener Speicher Datentypen: Seite = feste Anzahl von Bytes Segment = var. Anzahl von Seiten Operatoren: Anforderung/Freigabe von Seiten Segmente anlegen/öffnen/schließen Hauptspeicherseiten u. Segmente Segment- u. Pufferverwaltung Bevorratung von Daten im Hauptspeicher (rechtzeitige Bereitstellung vor Benutzung) Dateien Datentypen: Block = feste Anzahl von Bytes Datei = variable Anzahl v. Blöcken Operatoren: Dateien anlegen/öffnen/schließen Lesen/Schreiben von Blöcken Dateiverwaltung Schneller Transport zwischen Haupt- und Hintergrundspeicher Geräteschnittstelle Speicherstruktur Geräte-E/A

Kapitel 8.1 Interne Dateien

Ausgangslage Externe DB Ausprägung des externen Datenmodells enthält
Menge externer Objekte, mengenorientierte Anfragesprache Performanzwahrende Umsetzung Satzmenge, Zugriffspfad enthält enthält Physische DB (satzorientiert) Zugriffs- struktur Kl.Physischer Datensatz 1 0.. 1 0.. 1.. 1.. repräsentiert durch ▼ repräsentiert durch ▼ 1 1 enthält enthält Physische DB (seitenorientiert Segment Seite 1 0.. 1 0..

Ausgangslage Externe DB Ausprägung des externen Datenmodells enthält
Menge externer Objekte, mengenorientierte Anfragesprache Materialisierung Logische Zugriffspfade Satzmenge, mengeninterne und -übergreifende Zugriffspfade Direkte Zuordnung Abbildung Satzmenge, Zugriffspfad enthält enthält Physische DB (satzorientiert) Zugriffs- struktur Kl.Physischer Datensatz 1 0.. 1 0.. 1.. 1.. repräsentiert durch ▼ repräsentiert durch ▼ 1 1 enthält enthält Physische DB (seitenorientiert Segment Seite 1 0.. 1 0..

Lösungsansatz (2) Materialisierung: Konstruktion einer Satzmenge, die gemeinsam genutzte Elemente der extern gesehenen Datenbasis widerspiegelt. Logischer Zugriffspfad: Beschreibung der Reihenfolge, in der auf die Datensätze einer oder mehrerer interner Dateien zugegriffen wird. Daraus will man Hinweise auf die Gestaltung der Zugriffsstrukturen gewinnen. Interne Datei: Materialisierte Satzmenge samt einem oder mehreren logischen Zugriffspfaden.

Zusammenhänge Externe DB Instanzen des externen Datenmodells enthält
Gegenstand des Kapitels Menge externer Objekte, mengenorientierte Anfragesprache enthält enthält Interne DB Int. Datei Int. Datensatz 1 0.. 1 0.. 1 1 repräsentiert durch ▼ repräsentiert durch ▼ Satzmenge, mengeninterne und -übergreifende Zugriffspfade ? 1 enthält enthält Physische DB Zugriffs- struktur Physischer Datensatz 1 0.. 1 0.. 1.. 1.. Satzmenge, Zugriffspfad repräsentiert durch ▼ repräsentiert durch ▼ 1 1 enthält enthält Physische DB Segment Seite 1 0.. 1 0..

Operatoren auf internen Dateien
OPEN/CLOSE Datei FIND/FETCH Satz //wertbasiert, navigierend// INSERT Satz DELETE Satz UPDATE Satz SCAN //sequentieller Zugriff satzweise// Hilfsoperator SORT //temporäres Sortieren einer Datei//

Sort-Operator (1) Externes Sortieren: Sortieren unter Zuhilfenahme des Hintergrundspeichers. Vorherrschende Technik: Sortieren durch Mischen (Sort-merge).

Sort-Operator (2) partition internal sort merge merge Gunter 42
Andreas 24 Dieter 4 Andreas 24 Dieter 4 Gunter 42 Andreas 24 Berta 77 Chris 7 Dieter 4 Elle 36 Gunter 42 Gunter 42 Andreas 24 Dieter 4 Chris 7 Berta 77 Elle 36 Tamara 99 2 Mario 9 Peer 43 11 21 Andreas 21 24 Berta 77 Chris 7 Dieter 2 4 11 Elle 36 Gunter 42 Mario 9 Peer 43 Tamara 99 Chris 7 Berta 77 Elle 36 Berta 77 Chris 7 Elle 36 Tamara 99 Dieter 2 Mario 9 Dieter 2 Mario 9 Tamara 99 Andreas 21 Dieter 2 11 Mario 9 Peer 43 Tamara 99 Peer 43 Dieter 11 Andreas 21 Andreas 21 Dieter 11 Peer 43

Sort-Operator (3) Sortierung von Stellvertretern zur Einsparung von E/A! Allgemein: m-Wege-Mischen Gunter 42 Andreas 24 Dieter 4 Andreas 24 Dieter 4 Gunter 42 Andreas 24 Berta 77 Chris 7 Dieter 4 Elle 36 Gunter 42 Gunter 42 Andreas 24 Dieter 4 Chris 7 Berta 77 Elle 36 Tamara 99 2 Mario 9 Peer 43 11 21 Andreas 21 24 Berta 77 Chris 7 Dieter 2 4 11 Elle 36 Gunter 42 Mario 9 Peer 43 Tamara 99 Chris 7 Berta 77 Elle 36 Berta 77 Chris 7 Elle 36 Tamara 99 Dieter 2 Mario 9 Dieter 2 Mario 9 Tamara 99 Andreas 21 Dieter 2 11 Mario 9 Peer 43 Tamara 99 Sequentieller Durchlauf: 1 Pufferkachel pro beteiligter Partition genügt (hier: 3) Peer 43 Dieter 11 Andreas 21 Andreas 21 Dieter 11 Peer 43 Partition ~ Pufferkachelgröße

Partition ~ Pufferkachelgröße
Sort-Operator (3) Alternativen: Nutzung der Pufferverwaltung (bequem, aber keine Kontrolle!) Eigener Puffer Gunter 42 Andreas 24 Dieter 4 Andreas 24 Dieter 4 Gunter 42 Andreas 24 Berta 77 Chris 7 Dieter 4 Elle 36 Gunter 42 Gunter 42 Andreas 24 Dieter 4 Chris 7 Berta 77 Elle 36 Tamara 99 2 Mario 9 Peer 43 11 21 Andreas 21 24 Berta 77 Chris 7 Dieter 2 4 11 Elle 36 Gunter 42 Mario 9 Peer 43 Tamara 99 Chris 7 Berta 77 Elle 36 Berta 77 Chris 7 Elle 36 Tamara 99 Dieter 2 Mario 9 Dieter 2 Mario 9 Tamara 99 Andreas 21 Dieter 2 11 Mario 9 Peer 43 Tamara 99 Sequentieller Durchlauf: 1 Pufferkachel pro beteiligter Partition genügt Peer 43 Dieter 11 Andreas 21 Andreas 21 Dieter 11 Peer 43 Partition ~ Pufferkachelgröße

Sort-Operator (4) E/A-Aufwand: 2n
E/A- Aufwand: 2nlognB-1(n/nB) falls Seitengröße=Kachelgröße Gunter 42 Andreas 24 Dieter 4 Andreas 24 Dieter 4 Gunter 42 Andreas 24 Berta 77 Chris 7 Dieter 4 Elle 36 Gunter 42 Gunter 42 Andreas 24 Dieter 4 Chris 7 Berta 77 Elle 36 Tamara 99 2 Mario 9 Peer 43 11 21 Andreas 21 24 Berta 77 Chris 7 Dieter 2 4 11 Elle 36 Gunter 42 Mario 9 Peer 43 Tamara 99 Chris 7 Berta 77 Elle 36 Berta 77 Chris 7 Elle 36 Tamara 99 Dieter 2 Mario 9 Dieter 2 Mario 9 Tamara 99 Andreas 21 Dieter 2 11 Mario 9 Peer 43 Tamara 99 Peer 43 Dieter 11 Andreas 21 Andreas 21 Dieter 11 Peer 43 n: Seitenzahl, nB Kachelzahl

Relationales Datenmodell
Kapitel 8.2 Relationales Datenmodell

Datenmodell Tupel: Folge als zusammengehörig betrachteter atomarer Datenelemente (Tupelkomponente). Die Zahl der Komponenten liegt für das Tupel fest, ihre Anordnung ist beliebig, da jede durch einen Selektor (Attribut) mit Wert aus einer Domäne identifiziert wird. Relation: Menge im mathematischen Sinn aus gleichartigen Tupeln (Übereinstimmung in Attribut/Domäne-Paaren). Schlüsselattribute (kurz: Schlüssel): Attribute(kombination), deren Werte(kombination) (ebenfalls: Schlüssel) zur eindeutigen Identifikation von Tupeln einer Relationen genügt. Referenzielle Konsistenz von R1.X1 nach R2.X2. Die Werte unter R1.X1 kommen unter R2.X2 vor X2 Schlüssel von R2  X1 Fremdschlüssel in R1.

Kapitel 8.2.1 Materialisierung

Struktur von Datensätzen (1)
Schema-beschriebene Strukturrepräsentation: N ist die Anzahl der Felder, Offsi ist der Offset innerhalb des Datensatzes, an der Wert von Feldi gespeichert ist. Die Reihenfolge der Felder entspricht einer vorgegebenen Reihenfolge der Attribute. Die Längen der Feldwerte können dynamisch wachsen und schrumpfen (führt zu Vergrößerung bzw. Verkleinerung des Datensatzes). Feldwerte am Ende der Datensätze, die mit Nullwerten belegt sind, können weggelassen werden. L N Offs OffsN Feld FeldN

Struktur von Datensätzen (2)
Selbstbeschreibende Strukturrepräsentation: Ergänzung der vorhergehenden Struktur um Fi = Bezeichner des Felds (Atttribut) an der i-ten Position im Datensatz. Die explizite Angabe der Feldnamen ermöglicht eine beliebige Reihenfolge bei der Anordnung der Feldwerte im Datensatz. Felder mit Nullwerten können generell weggelassen werden. L N F1 Offs FN OffsN Feld FeldN

Beispiel-Relationen Cuboid Vertex Material OID GeoId Mat Value Color
V2…V7 V8 id1 4711 id77 39.99 “red“ id11 …. id18 id2 5301 19.95 “blue“ id21 id28 id3 8020 id99 89.9 “yellow“ id31 id38 Vertex OID X Y Z id11 0.0 id18 6.694 id21 id28 5.848 id31 id38 4.641 …. Material OID Name SpecWeight id77 “Iron” 7.86 id99 “Gold” 19.0 idi sind Schlüssel

Direkte Materialisierung (1)
enthält enthält Externe DB Relation Tupel 1 0.. 1 0.. 1 1 repräsentiert durch ▼ repräsentiert durch ▼ Eineindeutige Zuordnung: N-ary Storage Model 1 1 enthält enthält Interne DB Int. Datei Int. Datensatz 1 0.. 1 0..

Cuboid OID GeoId Mat Value Color V1 V2…V7 V8 id1 4711 id77 39.99 “red“ id11 …. id18 id2 5301 19.95 “blue“ id21 id28 id3 8020 id99 89.9 “yellow“ id31 id38 Vertex OID X Y Z id11 0.0 id18 6.694 id21 id28 5.848 id31 id38 4.641 …. Material OID Name SpecWeight id77 “Iron” 7.86 id99 “Gold” 19.0

Gut für relationale Anfragen, die viele Tupel selektieren und auf viele Attribute zugreifen. Weitere Vorteile Einfaches Abbildungsschema von der externen auf die interne Ebene. Anfragen und Änderungen auf Relationen können direkt auf die Dateien übertragen werden. Schlecht wenn Zugriff auf nur wenige Attribute erfolgt, da alle Attribute eines Tupels gelesen werden müssen. Weitere Nachteile Je größer die Tupel werden, desto schlechter werden die Möglichkeiten, eine gute Ballung der Datensätze zu erreichen.

Materialisierte Projektion (1)
enthält enthält Externe DB Relation Tupel 1 0.. 1 0.. 1 1 repräsentiert durch ▼ repräsentiert durch ▼ Die Menge der Attribute einer Relation wird in Teilmengen zerlegt, die jeweils einer Datei zugeordnet werden: Partial Decomposition Storage Model (P-DSM). Jede Attribut-Teilmenge enthält den Identifikator der Tupel, damit die Tupel aus den internen Datensätzen rekonstruiert werden können. 1.. 1.. enthält enthält Interne DB Datei Int. Datensatz 1 0.. 1 0..

Cuboid OID GeoId Mat Value Color V1 V2…V7 V8 id1 4711 id77 39.99 “red“ id11 …. id18 id2 5301 19.95 “blue“ id21 id28 id3 8020 id99 89.9 “yellow“ id31 id38 Vertex OID X Y Z id11 0,0 0.0 id18 6.694 id21 id28 5.848 id31 id38 4.641 …. Material OID Name SpecWeight id77 “Iron” 7.86 id99 “Gold” 19.0

Gut bei gemeinsamem Zugriff lediglich auf Teilmenge von Attributen: Vertikale Fragmentierung. Es kann sinnvoll sein, dass sich Teile eines Tupels überlappen; dies führt allerdings zu Redundanz in den internen Datensätzen. Weitere Vorteile Die Datensätze sind i.Allg. kurz, sie können daher gut geballt werden. Große Attributwerte wie Blobs werden immer getrennt von den übrigen Attributen gespeichert; sie „stören“ daher nicht bei der Ballung der übrigen Datensätze. Schlecht wenn auf mehr oder sämtliche Attribute eines Tupels zugegriffen werden soll. Der Datensatz muss erst durch mehrere Joinoperationen „zusammengebaut“ werden.

Extremfall: Für jedes Attribut wird eine eigene Datei definiert (Decomposition Storage Model, DSM ). Vorteil 1: Mengenwertige Attribute: Mengenwertige Attribute können ohne redundante Speicherung anderer Attribute gespeichert werden. Die interne Struktur der Daten ist bei DSM unabhängig davon, ob ein Attribut mengenwertig ist oder nicht. Vorteil 2: Unbekannte Attributwerte: Im DSM werden keine Nullwerte benötigt: Ein unbekannter Attributwert wird einfach durch die Abwesenheit eines internen Datensatzes in der entsprechenden Attributdatei repräsentiert.

Vorteil 3:Schemaevolution: Das Datenbasis-Schema spiegelt die Verhältnisse der realen Welt wider; Änderungen in der realen Welt können zu Anpassungen des Schemas führen (Schemaevolution). Änderungen des Schemas können Anpassungen der externen DB erfordern. Beispiele: Hinzufügen oder Entfernen von Attributen aus logischen Kollektionen. Im DSM wird das Hinzufügen eines neuen Attributs durch das Erzeugen einer neuen, (zunächst) leeren Attributrelation realisiert. Das Entfernen eines Attributs wird durch das Löschen der entsprechenden Attributrelation erreicht.

Cuboid OID GeoId Mat Value Color V1 V2…V7 V8 id1 4711 id77 39.99 “red“ id11 …. id18 id2 5301 19.95 “blue“ id21 id28 id3 8020 id99 89.9 “yellow“ id31 id38 ... Vertex OID X Y Z id11 0.0 id18 6.694 id21 id28 5.848 id31 id38 4.641 …. Material OID Name SpecWeight id77 “Iron” 7.86 id99 “Gold” 19.0

Weitere Nachteile: Die Identifikatoren der Tupel sind redundant gespeichert (einmal für jeden Attributwert). Da sich die Identifikatoren i.Allg. nicht ändern, führt ihre redundante Speicherung jedoch nur zu einem erhöhten Speicherplatzbedarf, nicht aber zu einem erhöhten Änderungsaufwand.

Materialisierte Selektion (1)
enthält enthält Externe DB Relation Tupel 1 0.. 1 0.. 1 1 repräsentiert durch ▼ repräsentiert durch ▼ Die Tupel der Relation werden auf mehrere Dateien aufgeteilt (horizontale Fragmentierung). Als Kriterium dienen Wertebereiche unter einer Attributkombination. 1.. 1 enthält enthält Interne DB Datei Int. Datensatz 1 0.. 1 0..

Cuboid OID GeoId Mat Value Color V1 V2…V7 V8 id1 4711 id77 39.99 “red“ id11 …. id18 id2 5301 19.95 “blue“ id21 id28 id3 8020 id99 89.9 “yellow“ id31 id38 Vertex Cub_Iron Cub_Gold OID X Y Z id11 0.0 id18 6.694 id21 id28 5.848 id31 id38 4.641 …. OID GeoId Mat Value Color V1 V2…V7 V8 id1 4711 id77 39.99 “red“ id11 …. id18 id2 5301 19.95 “blue“ id21 id28 Material OID Name SpecWeight id77 “Iron” 7.86 id99 “Gold” 19.0 OID GeoId Mat Value Color V1 V2…V7 V8 id3 8020 id99 89.9 “yellow“ id31 …. id38

Gut für Range Queries. Schlecht bei Zugriff auf sämtliche Datensätze der Relation: Vereinigungsoperation erforderlich.

Materialisierter Join (1)
enthält enthält Externe DB Relation Tupel 1 0.. 1 0.. 2 2 repräsentiert durch ▼ repräsentiert durch ▼ Spezialfall: Die Tupel zweier Relationen werden gemäß Fremdschlüsselbedingung zusammengeführt. Zu einem Tupel der Relation mit Schlüssel werden alle Tupel der zweiten Relation gruppiert, die diesen Schlüssel als Fremdschlüssel besitzen. 1 1 enthält enthält Interne DB Datei Int. Datensatz 1 0.. 1 0..

Materialisierter Join (2)
Cuboid OID GeoId Mat Value Color V1 V2…V7 V8 id1 4711 id77 39.99 “red“ id11 …. id18 id2 5301 19.95 “blue“ id21 id28 id3 8020 id99 89.9 “yellow“ id31 id38 Vertex OID X Y Z id11 0.0 id18 6.694 id21 id28 5.848 id31 id38 4.641 …. Material OID Name SpecWeight id77 “Iron” 7.86 id99 “Gold” 19.0 Cub_Mat OID GeoId Mat Name SpecWeight Value Color V1 V2…V7 V8 id1 4711 id77 “Iron” 7.86 39.99 “red“ id11 …. id18 id2 5301 19.95 “blue“ id21 id28 id3 8020 id99 “Gold” 19.0 89.9 “yellow“ id31 id38

Logische Zugriffspfade
Kapitel 8.2.2 Logische Zugriffspfade

Navigierende Zugriffspfade
Anforderung Umsetzung Bewertung LIST Bevorzugter, schneller, sequentieller Zugriff Geballte Liste Effizienter Aufbau nur bei Ablage in Eingangsreihenfolge. Ansonsten schlechtes Änderungsverhalten. POINTER-ARRAY Flexible Reihenfolge Aufgeprägter Index Zwar volle Freiheit für die Organisation der Datei, aber 2 Zugriffe pro Satz. CHAIN Nicht bevorzugter, sequentieller Zugriff Meist Verkettung als eingebetteter Zugriffspfad Änderungen an beliebiger Stelle, aber langsamer Zugriff.

Wertbasierte Zugriffspfade (1)
Anforderung Umsetzung Bewertung Primär-index Eindeutiger Schlüssel: Exact Match Query schnell, Range Query anspruchslos B*-Baum Keine Kontrolle über interne Datei. Sekundär-index Mehrdeutiger Schlüssel: Exact Match Query schnell, Range Query anspruchslos Cluster-index Wie Primärindex, aber schnelle Range Query B+-Baum Interne Datei als geballte Liste.

Umsetzung wertbasierter Zugriffspfade (1)
Primärindex Sekundärindex

Wertbasierte Zugriffspfade (2)
Anforderung Umsetzung Bewertung Mehrattri-butindex (Partial) Exact Match Query und Range Query auf mehr-dimensionalem Schlüssel mehr-dimensionalerIndex Wenn Schneiden von Einzelindexen gewünscht, nur solche Zugriffspfade angeben! Hash Exact Match Query auf ein- oder mehrdeutigem Schlüssel Hash-verfahren Gestreute Speicherung der internen Datei.

Umsetzung wertbasierter Zugriffspfade (2)
Mehrdimensionaler Index über (GeoId, Value)

Join-unterstützender Zugriffspfad
Statt einen Equi-Join zu materialisieren, kann man einen speziellen Zugriffspfad (Gruppierung) anlegen. Umsetzung 1: Über navigierenden Zugriffspfad Umsetzung 2: Über einen speziellen Index, z.B. CH-Baum. Dort können auch mehr als 2 Relationen einbezogen werden, sofern es sich um denselben Schlüssel handelt.

Navigierender Zugriffspfad für Join (1)
LIST: Schlüssel-Satz Fremdschlüssel-Satz 1 Fremdschlüssel-Satz 2 Fremdschlüssel-Satz 4 Fremdschlüssel-Satz 3

CHAIN: Schlüssel-Satz Fremdschlüssel-Satz 1 Fremdschlüssel-Satz 2 Fremdschlüssel-Satz 3

POINTERARRAY: Schlüssel-Satz Fremdschlüssel-Satz 2 Fremdschlüssel-Satz 1 Fremdschlüssel-Satz 3

Datensätze nach Dateizugehörigkeit gruppiert Gemeinsamer Schlüsselwert
CH-Baum (1) Basisstruktur: B+-Baum. Sortierte geballte Datei mit speziellem Format. Aufbau der Datensätze auf der Schicht der Satzmengenverwaltung. Falls eine Datenseite größer als die Seitengröße wird, werden zusätzliche Seiten angefordert und in Form einer Überlaufseiten-Liste verwaltet. Länge d. Records Schlüs-selwert Anzahl Dateien Id von Datei 1 Off- set 1 … Id von Datei n Off- set n Datensätze zu Datei 1 … Datensätze zu Datei n Pointer Array Datensätze nach Dateizugehörigkeit gruppiert Gemeinsamer Schlüsselwert

Nicht-Blattseiten wie im B-Baum
CH-Baum (2) Beispiel Nicht-Blattseiten wie im B-Baum 10 2 F1  F3  id1 id8 70 2 F1  F4  id3 id12 30 3 F1  F2  F3  id2 id7 id9 90 2 F2  F4  id4 id11 30 3 F1 F2 id2 id9 id7 F3 Detaildarstellung eines Blattseiten-records 40 1 F2  id6 Blattseiten-Records 50 2 F2  F3  id5 id10 Blattseite (ohne Längenfeld) F1 F2 F3 F4

Spezielle Scan-Operatoren
Kapitel 8.2.3 Spezielle Scan-Operatoren

Scan-Operator (1) SCAN: Tupelweises Aufsuchen, aus externer Sicht definiert, gemäß einer vorgeschriebenen Zugriffsreihenfolge. 4 Grundtypen: Relationen-Scan (Full-table scan) zum Aufsuchen aller Sätze einer Relation. Index-Scan zum Aufsuchen von Sätzen in einer wertabhängigen Reihenfolge. Link-Scan zum Aufsuchen von Sätzen in einer gruppierungsbedingten Reihenfolge. k-d-Scan zum Aufsuchen von Sätzen in einem k-dimensionalen Datenraum. Die Implementierung hängt jeweils von den angelegten logischen Zugriffspfaden und deren Umsetzung auf der Zugriffsschicht ab.

Scan-Operator (2) Abfolge: open scan: fetch tuple:
Richte Scan-Kontrollblock ein. Positioniere auf erstes Tupel gemäß Startbedingung. fetch tuple: Beschaffe Tupel gemäß Position und schalte Position gemäß Suchrichtung weiter. close scan: Aufräumen. Startbedingung Stoppbedingung Suchrichtung Suchbedingung

Relationen-Scan Es werden alle Tupel aufgesucht.
Startbedingung beginof Cuboid Stoppbedingung endof Cuboid Suchrichtung forward Suchbedingung all | Color=“red“ Es werden alle Tupel aufgesucht. Sehr effizient bei geballter Speicherung. Sehr ineffizient bei gestreuter Speicherung (Verkettung, Hash). Stets 2 Seitenzugriffe bei Pointer array. Falls Suchbedingung angegeben, wird sie auf jeden aufgesuchten Datensatz angewendet und über die Weitergabe entschieden.

Index-Scan (1) Startbedingung Cuboid ≥ 20 Stoppbedingung Cuboid > 75 Suchrichtung forward Suchbedingung Color=“red“ Es werden alle Tupel zwischen Start- und Stoppbedingung aufgesucht (Range Query). Sehr effizient bei Clusterindex. 2 Seitenzugriffe bei allen anderen wertbasierten Indexen. In allen anderen Fällen entartet Scan in einen Relationen-Scan. Falls Suchbedingung angegeben, wird sie auf jedes aufgesuchte Tupel angewendet und über die Weitergabe entschieden.

Index-Scan (2)  Beispiel: Clusterindex (B+-Baum): Startbedingung
Cuboid ≥ 20 Stoppbedingung Cuboid > 75 Suchrichtung forward Suchbedingung Color=“red“ Beispiel: Clusterindex (B+-Baum): 25 45 65 75  10 ... 20 ... 30 ... 40 ... 50 ... 60 ... 70 ... 80 ... 90 ...

Link-Scan (1) Startbedingung beginof Material Stoppbedingung endof Material Suchrichtung forward Suchbedingung Name=„Iron“ GeoId ≥ 3000 Es werden alle Schlüssel-Datensätze zwischen Start- und Stoppbedingung aufgesucht. Weiterbehandlung nur, falls Suchbedingung erfüllt ist. Für jeden Schlüssel-Datensatz werden alle zugehörigen Fremdschlüssel-Datensätze aufgesucht  Geschachtelter Scan. Weitergabe nur, falls Suchbedingung erfüllt ist. Effizienz hängt offensichtlich von der Implementierung beider Satzmengen (evtl. einschl. log. Zugriffspfad) ab.

Link-Scan (2) Material Cuboid OID Name SpecWeight id77 “Iron” 7.86
“Gold” 19.0 Cuboid OID GeoId Mat Value Color V1 V2…V7 V8 id1 4711 id77 39.99 “red“ id11 …. id18 id2 5301 19.95 “blue“ id21 id28 id3 8020 id99 89.9 “yellow“ id31 id38

k-d-Scan Annahme: Für Cub_NSM existiert mehrdimensionaler Index.
Startbedingung GeoId ≥ 3000 Value ≥ 20.00 Stoppbedingung GeoId > 8000 Value > 60.00 Suchrichtung forward Suchbedingung Color=“red“ Annahme: Für Cub_NSM existiert mehrdimensionaler Index. Startbedingung liefert Einstiegspunkt. Weiterbehandlung mit geschachteltem Scan, hängt im Detail (z.B. Anordnung der Scans) von Implementierung ab. Typisches Optimierungsproblem.

Objektorientiertes Datenmodell
Kapitel 8.3 Objektorientiertes Datenmodell

Beispiel Herausforderungen: Große Zahl von Objekten
Product Part Cuboid Material id110 id1 Herausforderungen: Große Zahl von Objekten Starke Verzeigerung Geold: 1 Mat: id77 Id: 3000 Geo: {} id2 id120 Geold: 2 Mat: id77 Id: 4711 Geo: {id1,id2} id3 id100 id121 Geold:3 Mat: id99 id77 Name: “Gripper“ Price: Cmps:{id120,id121,id122} Image: ... Id: 4712 Geo: {id3} Name: “Iron“ SpecWght: 7.86 id4 id122 Geold:4 Mat: id77 Id: 4713 Geo: {id4,id5} id88 id5 Geold: 5 Mat: id77 Name: “Alu“ SpecWght: 3.02 id130 id101 Id: 1001 Geo: {id6} Name: “Wheel“ Price: 95.00 Cmps: {id130,id131} Image: ... id6 Geold: 6 Mat: id88 id131 id99 Id: 1002 Geo: {id7} Name: “Gold“ SpecWght: 19.0 id7 Geold: 7 Mat: id99 id102 id140 id8 Name: “Bolt“ Price: 78.05 Cmps: {id140} Image: ... Id: 2010 Geo:{} Geold: 8 Mat: id99 id150 id9 Id: 6700 Geo:{id9} Geold: 9 Mat: -

Materialisierung von Objekten
Kapitel 8.3.1 Materialisierung von Objekten

Materialisierungsstrategie
Objekte des selben Typs bilden Satzmenge. Materialisierung dieser Satzmengen nach den selben Strategien wie bei Relationen.

Objekte mit großen Anteilen (1)
class Product { Name: string; Price: float; Cmps: setof Part; Image: BLOB } BLOB: Binary Large Object für vom DBMS nicht zu interpretierende Objekte (Bilder, Video, Audio). CLOB: Character Large Object für lange Texte. NCLOB: National Character Large Object für Unicode-Texte.

Objekte mit großen Anteilen (2)
Üblich: vom DBMS getrennte (externe) Dateien. Beispiel: Data Links von IBM DB2 für die Domäne BLOB. Zwei autonome Systeme. Satzmengenverwaltung so erweitert, dass die Zusammenhänge berücksichtigt werden. SQL Anfrage Datei-Anfrage Autorisierungsprüfung DB2 DB2 File Manager Datei 1 Datei 2 . Datei 3 Datei 4

Materialisierung der Vererbung (1)
Typhierarchie: GeoPrimitive Cylinder Cuboid Pipe {} {id1,id2,id´3} {id4,id5 } {id6 ,id7} class GeoPrimitive { GeoId: string; Mat: Material; Color: string; Value: float } class Cuboid extends GeoPrimitive { V1, ..., V8: Vertex class Cylinder extends GeoPrimitive { Center1, Center2: Vertex Radius: float class Pipe extends Cylinder { InnerRadius: float

Home Class Model Direkte Materialisierung jedes Typs als interne Datei derart, dass sie alle Attribute einschließlich der ererbten enthält. Ein Objekt wird in genau 1 Datensatz abgebildet in der Datei, die seine sämtlichen Attribute enthält (Verwandtschaft mit horizontaler Fragmentierung!). Beispiel: Objekte, die als spezialisiertesten Typ Cylinder besitzen, werden nur in der Datei zu dem Typ Cylinder gespeichert, nicht jedoch in der Datei zu dem Obertyp GeoPrimitive.

GeoPrimitive Cylinder Cuboid Pipe {id1,id2,id´3} {} {id4,id5 } {id6 ,id7}

Split Instance Model Jedes Objekt eines Typs wird mehrfach gespeichert: einmal in der Datei, die dem spezialisiertesten Typ des Objektes zugeordnet ist, und zusätzlich in den Dateien, die den Obertypen zugeordnet sind. Die Objekte werden dabei vertikal entsprechend der Vererbungshierarchie fragmentiert: Die Datei für einen Typ enthält nur die Attribute, die in dem Typ definiert sind, aber keine geerbten Attribute. Eine Datei zu einem Typ t enthält beim Split Instance Model somit Datensätze zu Objekten, die als spezialisiertesten Typ t oder einen seiner Untertypen besitzen.

GeoPrimitive Cylinder Cuboid Pipe {id1,id2,id´3} {} {id4,id5 } {id6 ,id7}

Repeat Class Model Kombination von Home Class und Split Instance Model: Jedes Objekt eines Typs wird mehrfach gespeichert: einmal in der Datei, die dem direkten Typ des Objektes zugeordnet ist, und zusätzlich in den Dateien, die den Obertypen zugeordnet sind. In jeder Datei sind aber alle Attribute ihres Typs (inklusive aller ererbten) enthalten. Das Repeat Class Model führt somit zu einer redundanten Speicherung von geerbten Attributen.

Logische Zugriffspfade für Verzeigerung: Pfad-Indexe
Kapitel 8.3.2 Logische Zugriffspfade für Verzeigerung: Pfad-Indexe

Pfade Modell: Pfade in objektorientierten Datenbanken
Eine Objektbank enthält explizite Verweise zwischen Objekten: Zwischen einem Objekt o1 und einem Objekt o2 besteht eine Referenz (von o1 nach o2), wenn o1 den Identifikator von o2 enthält. Eine Objektbank bildet somit einen gerichteten Graphen beliebiger Struktur. Ein Pfad ist eine Kette von Objekten, die über Referenzen miteinander verbunden sind. Ein Pfadausdruck beschreibt die an der Kette beteiligten Attribute. Linearer Pfadausdruck: Keines der beteiligten Attribute ist mengenwertig. Mengenwertiger Pfadausdruck: Mindestens eines der beteiligten Attribute ist mengenwertig.

Linearer Pfadausdruck
select c from c in Cuboid where c.Mat.Name = “Gold“ Product Part Cuboid Material id110 id1 Geold: 1 Mat: id77 Id: 3000 Geo: {} id2 id120 Geold: 2 Mat: id77 Id: 4711 Geo: {id1,id2} id3 id100 id121 Geold:3 Mat: id99 id77 Name: “Gripper“ Price: Cmps:{id120,id121,id122} Image: ... Id: 4712 Geo: {id3} Name: “Iron“ SpecWght: 7.86 id4 id122 Geold:4 Mat: id77 Id: 4713 Geo: {id4,id5} id88 id5 Geold: 5 Mat: id77 Name: “Alu“ SpecWght: 3.02 id130 id101 Id: 1001 Geo: {id6} Name: “Wheel“ Price: 95.00 Cmps: {id130,id131} Image: ... id6 Geold: 6 Mat: id88 id131 id99 Id: 1002 Geo: {id7} Name: “Gold“ SpecWght: 19.0 id7 Geold: 7 Mat: id99 id3 id7 id8 id99 id102 id140 Id: 2010 Geo:{} id8 Name: “Bolt“ Price: 78.05 Cmps: {id140} Image: ... Geold: 8 Mat: id99 id150 id9 Id: 6700 Geo:{id9} Geold: 9 Mat: -

Mengenwertiger Pfadausdruck
select [Name: p.Cmps.Geo.Mat.Name] from p in Product where p.Name = “Gripper“ Product Part Cuboid Material id110 id1 Geold: 1 Mat: id77 Id: 3000 Geo: {} id2 id120 Geold: 2 Mat: id77 Id: 4711 Geo: {id1,id2} id3 id100 id121 Geold:3 Mat: id99 id77 Name: “Gripper“ Price: Cmps:{id120,id121,id122} Image: ... Id: 4712 Geo: {id3} Name: “Iron“ SpecWght: 7.86 id4 id122 Geold:4 Mat: id77 Id: 4713 Geo: {id4,id5} id88 id5 Geold: 5 Mat: id77 Name: “Alu“ SpecWght: 3.02 id130 id101 Id: 1001 Geo: {id6} id121 id122 id1 id2 id3 id4 id5 id77 id99 id100 id120 Name: “Wheel“ Price: 95.00 Cmps: {id130,id131} Image: ... id6 Geold: 6 Mat: id88 id131 id99 Id: 1002 Geo: {id7} Name: “Gold“ SpecWght: 19.0 id7 Geold: 7 Mat: id99 id102 id140 Id: 2010 Geo:{} id8 Name: “Bolt“ Price: 78.05 Cmps: {id140} Image: ... Geold: 8 Mat: id99 id150 id9 Id: 6700 Geo:{id9} Geold: 9 Mat: -

Pfadausdrücke t2 Typisierung: t1 P= t0.A1..Ai..An A2 t0 A1 v ov
ti tn Beispiel: P=Product.Cmps.Geo.Mat.Name Part Cuboid Material string

Pfadindexe Anwendungen navigieren durch den Graphen, indem sie gemäß eines Pfadausdrucks Pfade durchlaufen und dabei auf die entlang des Pfades liegenden Objekte zugreifen. Grundidee: Häufig durchlaufene Pfadausdrücke werden vorausberechnet (materialisiert) und als Dateien (Access Support Relations, ASRs) gespeichert.

Binäre Pfadrelationen (1)
Fall 1: Fall2: id1 id2 id3 id4

Beispiel-Objektbank Product Part Cuboid Material Geold: 1 Mat: id77
Geo: {id1,id2} id3 id100 id121 Geold:3 Mat: id99 id77 Name: “Gripper“ Price: Cmps:{id120,id121,id122} Image: ... Id: 4712 Geo: {id3} Name: “Iron“ SpecWght: 7.86 id4 id122 Geold:4 Mat: id77 Id: 4713 Geo: {id4,id5} id88 id5 Geold: 5 Mat: id77 Name: “Alu“ SpecWght: 3.02 id130 id101 Id: 1001 Geo: {id6} Name: “Wheel“ Price: 95.00 Cmps: {id130,id131} Image: ... id6 Geold: 6 Mat: id88 id131 id99 Id: 1002 Geo: {id7} Name: “Gold“ SpecWght: 19.0 id7 Geold: 7 Mat: id99 id102 id140 Name: “Bolt“ Price: 78.05 Cmps: {id140} Image: ... Id: 2010 Geo:{} id8 Geold: 8 Mat: id99 id150 id9 Id: 6700 Geo:{id9} Geold: 9 Mat: -

Access Support Relations (1)
Formale Definition von ASRs ASRs werden über den Join mehrerer binärer Pfadrelationen definiert.

Vollständige ASR-Extension Die vollständige Extension enthält alle vollständigen und partiellen Pfade. Definition: t0.A1..Ai..Anfull := t0.A1  tn-1.An Partielle Pfade beginnen und/oder enden daher mit NULL-Werten. ⋈ ⋈ Exkurs: Äußerer Join (full outer join) =

Beispiel-Objektbank Product Part Cuboid Material Geold: 1 Mat: id77

Links-Vollständige ASR-Extension Die linksvollständige Extension enthält Pfade, die in der ersten Spalte der Access Support Relation beginnen und in einer beliebigen Spalte enden. Definition: t0.A1..Ai..Anleft := t0.A1  tn-1.An ⋈ ⋈ Exkurs: Linker äußerer Join (left outer join) =

Beispiel-Objektbank

Rechts-Vollständige ASR-Extension Die rechts-vollständige Extension enthält Pfade, die in einer beliebigen Spalte beginnen und in der letzten Spalte enden. Definition: t0.A1..Ai..Anright := t0.A1  tn-1.An ⋈ ⋈ Exkurs: Rechter äußerer Join (right outer join) =

Beispiel-Objektbank

Kanonische ASR-Extension Die kanonische Extension enthält nur vollständige Pfade, d.h., Pfade, die in der ersten Spalte der Access Support Relation beginnen und bis zur letzten Spalte reichen. Definition: t0.A1..Ai..Ancan := t0.A1 ⋈  ⋈ tn-1.An Exkurs: Equi-Join =

Beispiel-Objektbank

Anfragebearbeitung mit ASR
Anfragearten: Rückwärts-Anfrage select o from o in ti where predicate (o.Ai+1.···.Aj) Vorwärts-Anfrage select o.Ai+1.···.Aj where predicate (o)

Rückwärts-Anfrage select c from c in Cuboid where c.Mat.Name = “Gold“
Product Part Cuboid Material id110 id1 select c from c in Cuboid where c.Mat.Name = “Gold“ Geold: 1 Mat: id77 Id: 3000 Geo: {} id2 id120 Geold: 2 Mat: id77 Id: 4711 Geo: {id1,id2} id3 id100 id121 Geold:3 Mat: id99 id77 Name: “Gripper“ Price: Cmps:{id120,id121,id122} Image: ... Id: 4712 Geo: {id3} Name: “Iron“ SpecWght: 7.86 id4 id122 Geold:4 Mat: id77 Id: 4713 Geo: {id4,id5} id88 id5 Geold: 5 Mat: id77 Name: “Alu“ SpecWght: 3.02 id130 id101 Id: 1001 Geo: {id6} Name: “Wheel“ Price: 95.00 Cmps: {id130,id131} Image: ... id6 Geold: 6 Mat: id88 id131 id99 Id: 1002 Geo: {id7} Name: “Gold“ SpecWght: 19.0 id7 Geold: 7 Mat: id99 Anfrageergebnis: {id3,id7,id8} Die Anfrage kann nur auf den Extensionen Product.Cmps.Geo.Mat.Nameright Product.Cmps.Geo.Mat.Namefull bearbeitet werden. id102 id140 Id: 2010 Geo:{} id8 Name: “Bolt“ Price: 78.05 Cmps: {id140} Image: ... Geold: 8 Mat: id99 id150 id9 Id: 6700 Geo:{id9} Geold: 9 Mat: -

Vorwärts-Anfrage select q.Geo from q in Part where true
Product Part Cuboid Material id110 id1 select q.Geo from q in Part where true Geold: 1 Mat: id77 Id: 3000 Geo: {} id2 id120 Geold: 2 Mat: id77 Id: 4711 Geo: {id1,id2} id3 id100 id121 Geold:3 Mat: id99 id77 Name: “Gripper“ Price: Cmps:{id120,id121,id122} Image: ... Id: 4712 Geo: {id3} Name: “Iron“ SpecWght: 7.86 id4 id122 Geold:4 Mat: id77 Id: 4713 Geo: {id4,id5} id88 id5 Geold: 5 Mat: id77 Name: “Alu“ SpecWght: 3.02 id130 id101 Id: 1001 Geo: {id6} Name: “Wheel“ Price: 95.00 Cmps: {id130,id131} Image: ... id6 Geold: 6 Mat: id88 id131 id99 Id: 1002 Geo: {id7} Name: “Gold“ SpecWght: 19.0 id7 Geold: 7 Mat: id99 Anfrageergebnis: {id1,id2,id3,id4,id5,id6,id7,id9} Die Anfrage kann nur auf der Extension Product.Cmps.Geo.Mat.Namefull bearbeitet werden. id102 id140 Id: 2010 Geo:{} id8 Name: “Bolt“ Price: 78.05 Cmps: {id140} Image: ... Geold: 8 Mat: id99 id150 id9 Id: 6700 Geo:{id9} Geold: 9 Mat: -

Zugriff auf Access Support Relations (1)
Unterstützung von Vorwärtsanfragen der Form select = o.Ai+1.···.Aj from o in ti where predicate (o) Es wird ein zusätzlicher Zugriffspfad auf der i-ten Spalte der ASR t0.A1.···.An benötigt. Da alle Spalten (bis auf die letzte) OIDs enthalten, und auf OIDs i.Allg. keine Range Queries, sondern nur Exact Match Queries gestellt werden, empfiehlt sich für den Zugriffspfad der Einsatz einer Hashtabelle.

Zugriff auf Access Support Relations (2)
Unterstützung von Rückwärtsanfragen der Form select o from o in ti where predicate (o.Ai+1.···.Aj) Es wird ein zusätzlicher Index auf der j-ten Spalte benötigt. Falls j=n und die letzte Spalte nicht oid-wertig ist, dann können Range Queries vorkommen. In diesem Fall sollte für den Zusatzindex ein B+-Baum eingesetzt werden. Falls die j-te Spalte oid-wertig ist, sollte eine Hashtabelle eingesetzt werden. In wie vielen physischen Datenstrukturen insgesamt eine ASR gespeichert wird, hängt von dem Anfrageprofil ab (Abwägung zwischen Unterstützung von Anfragen und Änderungsaufwand).

Kombinierte Materialisierung von Objekten und Zugriffspfaden
Kapitel 8.3.3 Kombinierte Materialisierung von Objekten und Zugriffspfaden

Gruppierte Objekte Ausgangspunkt: Vermeiden von häufig durchlaufenen Pfaden Ansatz: Composite Object oder Complex Object: Gruppierung eines Objektes gemeinsam mit seinen durch vorgegebene Beziehungen verbundenen (Unter-)Objekten. Vorteile: Durch Ballen der Bestandteile eines komplexen Objektes in einem internen Datensatz werden Zugriffe auf das gesamte komplexe Objekt optimiert. Vermeiden von Join-Operationen. Problem: Der interne Datensatz kann sehr groß werden.

Beispiel (1) Product Part Cuboid Material Geold: 1 Mat: id77 Id: 3000

Beispiel (2) Cuboid Vertex Material OID GeoId Mat Value Color V1 V2…V7
4711 id77 39.99 “red“ id11 …. id18 id2 5301 19.95 “blue“ id21 id28 id3 8020 id99 89.9 “yellow“ id31 id38 Vertex OID X Y Z id11 0.0 id18 6.694 id21 id28 5.848 id31 id38 4.641 …. Material OID Name SpecWeight id77 “Iron” 7.86 id99 “Gold” 19.0

Nachteile der Gruppierung
Nicht-referenzierte Unterobjekte (bspw. Objekte des Typs Part, die in keinem Produkt vorkommen) werden nicht erfasst. Nur durch umständliche Erweiterungen behebbar. Unterobjekte, die von mehreren Objekten referenziert werden, werden mehrfach gespeichert.

Umsetzung Mit großen Datensätzen Mit kurzen Datensätzen
Mengenorientiertes Datenmodell Mengenorientiertes Datenmodell Anfragebearbeitung Anfragebearbeitung Umsetzung gesucht, die die Join-Einsparung nicht aufzehrt Satzorientiertes Datenmodell Objektorientier-tes Datenmodell Satzorientiertes Datenmodell Objektorientier-tes Datenmodell Satz- u. Satzmengen-verwaltung Objekt-verwaltung Satz- u. Satzmengen-verwaltung Objekt-verwaltung Satzzugriffsstrukturen Satzzugriffsstrukturen Zugriffsschicht für kurze Sätze Zugriffsschicht für große Sätze Zugriffsschicht für kurze Sätze Siehe Kapitel 5.4 Hauptspeicherseiten u. Segmente Hauptspeicherseiten u. Segmente Segment- u. Pufferverwaltung Spez. Puf-ferverw. Segment- u. Pufferverwaltung Dateien Dateien Dateiverwaltung Dateiverwaltung Geräteschnittstelle Geräteschnittstelle

Modell der Gruppierung: NF2-Datensätze
Datenmodell der NF2-Relation (Non First Normal Form): Geschachtelte Relation durch Zulassen mengenwertiger Attribute (Unterrelationen). Die Elemente einer Unterrelation können ebenfalls wieder Unterrelationen besitzen. NF2-Tupel: Tupel mit mengenwertigen Attributen.

Materialisierung Grundsatz: NF2-Datensätze werden in ihre Nicht-NF2-Bestandteile zerlegt  Menge „flacher“ Datensätze. Im Grundsatz werden daher die nicht-mengenwertigen Felder in einem eigenen Datensatz zusammengefasst. Führt zu Verweisstrukturen. 1 interne Datei pro NF2-Relation  mehrere Satztypen in einer Datei. Zwei Arten von internen Dateien: für eine freie Speicherung: Externe Satzablage. für eine gesteuerte Speicherung: Interne Satzablage.

Freie Speicherung (1) id1 “red“ 39.99 id77 id11 0.0 8 id18 0.0 6.694
Kardinalität der Menge (=Länge der Zeigerreihung) 8 id18 0.0 6.694

Freie Speicherung (2) id1 “red“ 39.99 id77 id11 0.0 0.0 0.0 8 id18 0.0
6.694 6.694 id2 “blue“ 19.95 id77 id21 0.0 0.0 0.0 8 id28 0.0 5.848 5.848 id3 “yellow“ 89.90 id99 id31 0.0 0.0 0.0 8 id38 0.0 4.641 4.641

Freie Speicherung (3) Vorteile:
Wachsen und Schrumpfen des Datensatzes bzw. der Unterrelationen wird gut unterstützt. Nachteile: Die Teile eines NF2-Datensatzes sind beliebig über Seiten verstreut; im schlimmsten Fall erfordert jeder Zugriff auf eine Unterrelation und auf ein Element einer Unterrelation einen Seitenzugriff. TIDs sind relativ lang (4 Bytes) und können aufgrund von Verschiebungen von Datensätzen auf den Seiten einen Zugriffsfaktor von 2 aufweisen  hoher Aufwand beim Navigieren durch die Unterrelationen eines Datensatzes.

Gesteuerte Speicherung (1)
Beispiel DASDBS (Darmstadt Datenbanksystem): Die Menge der Seiten, die ein NF2-Datensatz belegt (Adressraum des Datensatzes), sind exklusiv dem Datensatz zugeordnet. Spezielle Adressen sind möglich. Ballen ist möglich. Ein NF2-Datensatz wird in flache Datensätze zerlegt: Link Set zum Erfassen der Struktur: Sätze besitzen ausschließlich Verweise auf andere Datensätze Data Set: zum Erfassen der elementaren (nicht-mengenwertigen) Felder. Data Sets bilden daher die Blätter eines Baumes.

4 5 U A B C D 1 2 3 V E F W G 6 7 8 9 10 11 12 — Kardinalität der Unterrelation U 3 V 2 1 W 1 2 3 A B C F 7 8 9 4 5 6 D E 10 G 11 12

Ballen der internen Knoten in breadth-first Reihenfolge U V 3 3 P123 A B C W W W 1 2 3 2 1 P204 D E D E 4 4 5 5 P316 F F G D E 9 8 12 6 6 F G G Ballen der Blätter in depth-first Reihenfolge 7 10 11

Mini-TIDs für die interne Referenzierung: Beschränkung auf den Adressraum des Datensatzes. 2 Bytes für die Repräsentation der internen Seitennummern ausreichend: damit können Seiten adressiert werden. Aufwand 2+1 Bytes gegenüber 3+1 Bytes „normaler“ TIDs. Nutzung der Hierarchie  Zu jedem internen Datensatz existiert genau ein Vaterdatensatz. Bei Verdrängung eines internen Datensatzes wird die Referenz in dem Vaterdatensatz direkt angepasst. Im Kopf der Wurzelseite befindet sich eine Tabelle, die interne Seitennummern auf externe (Segment-) Seitennummern abbildet.

Hierarchische TIDs für die externe Referenzierung: Ein hierarchischer TID ist eine Folge: Die erste Komponente ist die (externe) Seitennummer der Wurzel des NF2-Datensatzes. Die restlichen Komponenten beschreiben einen Pfad in dem NF2-Datensatz. Hierarchische TIDs müssen bei Verschiebungen von internen Datensätzen auf den Seiten des NF2-Datensatzes stabil bleiben. Daher dürfen die Verweise in den Link Sets nicht verschoben werden. Löschen eines Elements einer Unterrelation: Setzen des entsprechenden Slot in dem Link Set auf 0. Einfügen: Am Ende des Link Set oder bei einem 0-Eintrag.

Seitennummer P123 Seitennummer 2. Unterrelation(V) U 2. Unterrelation(V) V 3 3 Element Nr.1 Element Nr.2 A B C 1 2 3 W 1. Unterrelation(W) W W 2 1 D E D E Nicht-mengenwertige Feldwerte (angezeigt durch die „0“) Element Nr.1 4 4 5 5 D E F F G 6 6 9 F G G 8 12 7 10 11 (P123,2,2,1,1) (P123,2,1,0)

V (P123,0) 3 3 A B C 1 2 3 W W W 2 1 D E D E 4 4 5 5 D E F F G 6 6 9 F G G 8 12 (P123,1,2) 7 10 11 (P123,2,2,1,1) (P123,2,1,0) Seitennummer Seitennummer 2. Unterrelation(V) 2. Unterrelation(V) Nicht-mengenwertige Feldwerte (angezeigt durch die „0“) Element Nr.2 1. Unterrelation(W) Element Nr.1 Element Nr.1

Probleme: Referenzen auf interne Datensätze (hierarchische TIDs) haben variable Länge und erfordern ein anderes Format als Referenzen auf „normale“ Datensätze („normale“ TIDs). Die sortierte Speicherung von Unterrelationen ist nicht möglich, da die Position der Elemente – unabhängig von dem Sortierkriterium – durch die hierarchischen TIDs festgelegt ist und bei Änderungen nicht verschoben werden darf.

Kapitel 8.4 XML-Datenmodell

Klassifikation Materialisierung von XML-Dokumenten
Materialisierung als Volltext Materialisierung als Graphstruktur Abbildung auf konventionelle Datenbankstrukturen Dateispei-cherung: Dateien Datenbank-speicherung: CLOB Generische Graphspei-cherung Document Object Model (DOM) Struktur-bewahrende Abbildung Struktur-zerstörende Abbildung Zugriff wie bei Information Retrieval: Volltextindex Umsetzung auf Relationen Umsetzung relational / objektrelational

Architekturerweiterung
Mengenorientiertes Datenmodell Anfragebearbeitung Satzorientiertes Datenmodell XML- Datenmodell Satz- u. Satzmengen-verwaltung Abbildung Satzzugriffsstrukturen Keine Anpassung, Fragmentierung: Schreddern Zugriffsschicht Anpassungs-maßnahmen: Native Lösung Hauptspeicherseiten u. Segmente Segment- u. Pufferverwaltung Dateien Dateiverwaltung Geräteschnittstelle

Dokument als Volltext (1)
Materialisierung von XML-Dokumenten Materialisierung als Volltext Materialisierung als Graphstruktur Abbildung auf konventionelle Datenbankstrukturen Dateispei-cherung: Dateien Datenbank-speicherung: CLOB Generische Graphspei-cherung Document Object Model (DOM) Struktur-bewahrende Abbildung Struktur-zerstörende Abbildung Zugriff wie bei Information Retrieval: Volltextindex Umsetzung auf Relationen Umsetzung relational / objektrelational Native Lösung Schreddern

DBLP.xml <?xml version="1.0" ?> <bib> <paper id = "o12" > <title> Foundations of Databases </title> <author> <firstname> Serge </firstname> <lastname> Abiteboul </lastname> </author> <year> 1997 </year> <publisher> Addison Wesley </publisher> </paper> … </bib> XML Bibliography BibID PaperList DBLP <?xml version="1.0"?><bib> <paper id = "o12" ><title>Fo undations of Databases</titl e><author><firstname>Serge</firstname><lastname>Abiteboul</lastname></author><year>1997</year><publisher> Addison Wesley</publi sher></paper>… Zusätzlicher Volltextindex

Vorteile: Speichern und Auslesen von beliebigen XML-Dokumenten wird unterstützt. Datenbasis kommt ohne Datenbankschema aus Kein Schema für XML-Dokumente benötigt! Nachteile: Datenbanksystem muss spezielle Unterstützung für das Verarbeiten langer Texte bieten. Dokumentstruktur wird nicht berücksichtigt. Lesender oder schreibender Zugriff auf Werte einzelner XML-Elemente nur umständlich möglich.

Dokument als Graphstruktur

Generischer Dokumentgraph (1)
Einbezug der Strukturinformationen, die ein XML-Dokument enthält, in die Speicherung. Interpretation eines XML-Dokuments … …als gerichteter Graph... XML-Elemente und XML-Attribute ergeben die Knoten des Graphen Kanten modellieren die Enthaltensbeziehung Kanten werden mit den Bezeichnern der enthalten Elemente bzw. Attribute gekennzeichnet …und Speichern der Knoten und Kanten in einer Relation.

1 2 3 bib paper o12 id Foundations… title 4 author Serge firstname Abiteboul 1997 year Addison… publisher lastname <?xml version="1.0" ?> <bib> <paper id = "o12" > <title> Foundations of Databases </title> <author> <firstname> Serge </firstname> <lastname> Abiteboul </lastname> </author> <year> 1997 </year> <publisher> Addison Wesley </publisher> </paper> … </bib> XML

1 2 3 bib paper o12 id Foundations… title 4 author Serge firstname Abiteboul 1997 year Addison… publisher lastname Kanten Beginn Reihenf. Name IstText Ziel/Wert 1 2 3 4 1 2 3 4 5 bib paper id title author firstname lastname year publisher nein ja 2 3 o12 Foundations… 4 Serge Abiteboul 1997 Addison… Bei Bedarf zusätzliches Attribut, um XML-Attribut und XML-Element unterscheiden zu können

Document Object Model (1)
DOM: API mit Klassenstruktur DOMImplementation Node NodeList NamedNodeMap Attr getChildren() getFirstChild() getNextSibling() getParentNode() getPreviousSibling() hasChildren() insertBefore(node,node) removeChild(node) replaceChild(node) getName() getSpecified() getValue() setName(string) setSpecified(boolean) setValue(nodelist) toString() CharacterData Document DocumentType Element getAttributes() getElementsByTagName(string) getTagName() setAttribute(attribute) setAttribute(attributelist) setTagName(string) Entity EntityReference Notation

DOM: Beispiel Abbildung auf Relationen per Split Instance Model DOMImplementation Node NodeList NamedNodeMap Attr CharacterData Document DocumentType Element Entity EntityReference Notation

<?xml version="1.0" ?> <bib> <paper id = "o12" > <title> Foundations of Databases </title> <author> <firstname> Serge </firstname> <lastname> Abiteboul </lastname> </author> <year> 1997 </year> <publisher> Addison Wesley </publisher> </paper> … </bib> node_id node_type doc_id parent p_sibling n_sibling 001 element b0001 002 ...... 003 004 007 005 006 008 009 attribute node_id tag_name text 001 bib 002 paper 003 title Foundations of Databases 004 author 005 firstname Serge 006 lastname Abiteboul 007 year 1997 008 publisher Addison-Wesley node element

Dokument als Graphstruktur
Vorteile: Festes Datenbankschema. Kein Schema für XML-Dokumente benötigt! XML-Dokument vollständig rekonstruierbar. DOM-Speicherung auf API zugeschnitten  gute Verarbeitbarkeit (insbesondere auch Änderungen!). Nachteile: Hochgradig fragmentierte Speicherung. Dokumentrekonstruktion aufwändig. Nur einfache Anfragen lassen sich performant beantworten.

Dokument als Relation Native Lösung Schreddern

Strukturbewahrende Abbildung (1)
Grundgedanke: Überführen des XML-Dokuments in Relationen unter Wahrung der Dokumentstruktur. Zwang zu relationalem Datenbankschema. Erfordert auch Datenbankschema für die XML-Dokumente. Ausgehend von der DTD wird ein passendes relationales Schema erzeugt, das die Dokumente aufnehmen kann. Es müssen alle erlaubten Dokumente, die der DTD gehorchen, gespeichert werden können: z.B. muss auch für optionale Unterelemente etc. Speicherplatz vorhanden sein.

<?xml version="1.0" ?> <bib> <paper id = "o12" > <title> Foundations of Databases </title> <author> <firstname> Serge </firstname> <lastname> Abiteboul </lastname> </author> <year> 1997 </year> <publisher> Addison Wesley </publisher> </paper> … </bib> XML <!DOCTYPE bib [ <!ELEMENT bib (paper*)> <!ELEMENT paper (title, author+, year, publisher?)> <!ATTLIST paper id ID #REQUIRED> <!ELEMENT author (firstname,lastname)> <!ATTLIST author age CDATA #IMPLIED> <!ELEMENT firstname (#PCDATA)> <!ELEMENT lastname (#PCDATA)> <!ELEMENT title (#PCDATA)> <!ELEMENT year (#PCDATA)> <!ELEMENT publisher (#PCDATA)> … ]> DTD

Schritt 1: Reduktion der Komplexität einer DTD Geschachtelte Elementdefinitionen entschachteln z.B. (a|b)  a?,b? Folge von Kardinalitäten zusammenfassen z.B. a*?  a* Unterelemente gruppieren z.B. ..., a*, ..., a*, ...  ..., a*, ... Alle „+“ Kardinalitäten werden zu „*“ Die obigen Transformationen bewahren ... 1:1- bzw. 1:n-Elementbeziehungen und Optionale Unterelemente Aber: Informationen über Reihenfolge und genau erlaubte Anzahl der Unterelemente kann verloren gehen

Im Beispiel wird author+ zu author* Neue DTD beschreibt also eine Obermenge von XML-Dokumenten <!DOCTYPE bib [ <!ELEMENT bib (paper*)> <!ELEMENT paper (title, author+, year, publisher?)> <!ATTLIST paper id ID #REQUIRED> <!ELEMENT author (firstname,lastname)> <!ATTLIST author age CDATA #IMPLIED> <!ELEMENT firstname (#PCDATA)> <!ELEMENT lastname (#PCDATA)> <!ELEMENT title (#PCDATA)> <!ELEMENT year (#PCDATA)> <!ELEMENT publisher (#PCDATA)> … ]> DTD <!DOCTYPE bib [ <!ELEMENT bib (paper*)> <!ELEMENT paper (title, author*, year, publisher?)> <!ATTLIST paper id ID #REQUIRED> <!ELEMENT author (firstname,lastname)> <!ATTLIST author age CDATA #IMPLIED> <!ELEMENT firstname (#PCDATA)> <!ELEMENT lastname (#PCDATA)> <!ELEMENT title (#PCDATA)> <!ELEMENT year (#PCDATA)> <!ELEMENT publisher (#PCDATA)> … ]> DTD

Schritt 2: Strukturinformationen extrahieren Die neue DTD dient nun als Grundlage für einen gerichteten DTD-Graphen, der die Struktur dieser DTD repräsentiert: Für jedes XML-Element ergibt sich genau ein Knoten im Graph. Für jedes Vorkommen eines XML-Attributs bei einem Element wird ein Knoten angelegt, der mit dem entsprechenden Element-Knoten verbunden ist. Knoten für Element und erlaubte Unterelemente werden durch Kanten verbunden. Ist als Kardinalität bei einem Unterelement „*“ oder „?“ angegeben oder liegt ein mengenwertiges bzw. optionales XML-Attribut vor, wird die entsprechende Kante mit dem Symbol der Kardinalität markiert. Rekursionen können durch Zyklen im Graph erkannt werden.

<!DOCTYPE bib [ <!ELEMENT bib (paper*)> <!ELEMENT paper (title, author*, year, publisher?)> <!ATTLIST paper id ID #REQUIRED> <!ELEMENT author (firstname,lastname)> <!ATTLIST author age CDATA #IMPLIED> <!ELEMENT firstname (#PCDATA)> <!ELEMENT lastname (#PCDATA)> <!ELEMENT title (#PCDATA)> <!ELEMENT year (#PCDATA)> <!ELEMENT publisher (#PCDATA)> … ]> bib DTD-Graph * paper ? * id title year publisher author age firstname lastname

Schritt 3: Erzeugen der Relationstypen aus dem DTD-Graph Relationstypen erzeugen für… jeden Knoten mit keiner oder mehr als einer Eingangskante, jeden Knoten unterhalb einer „*“-Kante, mindestens einen Knoten innerhalb einer Rekursion … und mit Attributen ergänzen: Jedem Relationstypen werden diejenigen Blattknoten als Attribute zugeschlagen, die direkt vom entsprechenden Knoten aus erreichbar sind. Eine dazwischenliegende „?“-Kante erlaubt NULL-Werte beim Attribut. Jeder Relationstyp erhält künstlichen Schlüssel, der ein dort gespeichertes XML-Element eindeutig identifiziert. Beziehungen werden über Fremdschlüssel modelliert.

relation Bib (bibID) bib * relation Paper (paperID, bibID, id, title, year, publisher) paper ? * id title year publisher relation Author (authorID, paperID, age, firstname, lastname ) author age firstname lastname

Vorteile: Speichert alle XML-Dokumente, die einer DTD folgen. Bewirkt durch die Gruppierung von zusammengehörigen Elementen in einem Relationstyp ein kompakteres relationales Schema. Suche und Navigation innerhalb des Dokuments benötigen wenige Join-Operationen. Ein direkter Zugriff auf die Elemente ist möglich. Nachteile: Trotz Strukturabbildung kann die Struktur der XML-Dokumente nicht mehr vollständig rekonstruiert werden. Das Wissen hierüber steckt in der Abbildungsvorschrift.

Strukturzerstörende Abbildung
Grundgedanke: Verwenden einer frei wählbaren Abbildungsvorschrift, die die Elemente so zusammenfasst, dass bestimmte Anfragen besonders effizient beantwortet werden können.

Satzmengenverwaltung

Ähnliche Präsentationen

Präsentation zum Thema: "Satzmengenverwaltung"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

Satzmengenverwaltung

Ähnliche Präsentationen

Präsentation zum Thema: "Satzmengenverwaltung"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback