Kapitel 8

1. Kapitel 8 Satzmengenverwaltung

2. 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 Schneller Transport zwischen Haupt- und Hintergrundspeicher Dateiverwaltung Speicherstruktur Geräteschnittstelle Geräte-E/A

3. Kapitel 8.1 Interne Dateien

4. enthält Externe DB Ausprägung des externen Datenmodells Performanzwahrende Umsetzung Ausgangslage Menge externer Objekte, mengenorientierte Anfragesprache 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..

5. enthält Externe DB Ausprägung des externen Datenmodells Logische Zugriffspfade Materialisierung Direkte Zuordnung Abbildung Ausgangslage Menge externer Objekte, mengenorientierte Anfragesprache Satzmenge, mengeninterne und -übergreifende Zugriffspfade 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..

6. 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.

7. enthält Externe DB Instanzen des externen Datenmodells Gegenstand des Kapitels Zusammenhänge 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..

8. 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//

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

10. Sort-Operator (2) partition internal sort merge merge

11. Sequentieller Durchlauf: 1 Pufferkachel pro beteiligter Partition genügt (hier: 3) Sort-Operator (3) Sortierung von Stellvertretern zur Einsparung von E/A! Allgemein: m-Wege-Mischen Partition ~ Pufferkachelgröße

12. Alternativen: • Nutzung der Pufferverwaltung (bequem, aber keine Kontrolle!) • Eigener Puffer Sequentieller Durchlauf: 1 Pufferkachel pro beteiligter Partition genügt Sort-Operator (3) Partition ~ Pufferkachelgröße

13. Sort-Operator (4) E/A-Aufwand: 2n E/A- Aufwand: 2nlognB-1(n/nB)falls Seitengröße=Kachelgröße n: Seitenzahl, nB Kachelzahl

14. Kapitel 8.2 Relationales Datenmodell

15. 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.

16. Kapitel 8.2.1 Materialisierung

17. 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 Offs1 ..... OffsN Feld1 ..... FeldN

18. 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. F1 Offs1 ..... FN OffsN L N Feld1 ..... FeldN

19. Beispiel-Relationen Cuboid Vertex Material idi sind Schlüssel

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

21. Direkte Materialisierung (2) Cuboid Vertex Material

22. Direkte Materialisierung (3) • Gut für relationaleAnfragen, 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.

23. 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. Materialisierte Projektion (1) enthält enthält Externe DB Relation Tupel 1 0.. 1 0.. 1 1 repräsentiert durch ▼ repräsentiert durch ▼ 1.. 1.. enthält enthält Interne DB Datei Int. Datensatz 1 0.. 1 0..

24. Materialisierte Projektion (2) Cuboid Vertex Material

25. Materialisierte Projektion (3) • 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.

26. Materialisierte Projektion (4) • 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.

27. Materialisierte Projektion (5) • 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.

28. ... Materialisierte Projektion (6) Cuboid Vertex Material

29. Materialisierte Projektion (7) • 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.

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

31. Cub_Iron Cub_Gold Materialisierte Selektion (2) Cuboid Vertex Material

32. Materialisierte Selektion (3) • Gut für Range Queries. • Schlecht bei Zugriff auf sämtliche Datensätze der Relation: Vereinigungsoperation erforderlich.

33. 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. Materialisierter Join(1) enthält enthält Externe DB Relation Tupel 1 0.. 1 0.. 2 2 repräsentiert durch ▼ repräsentiert durch ▼ 1 1 enthält enthält Interne DB Datei Int. Datensatz 1 0.. 1 0..

34. Cub_Mat Materialisierter Join(2) Cuboid Vertex Material

35. Kapitel 8.2.2 Logische Zugriffspfade

36. Navigierende Zugriffspfade

37. Wertbasierte Zugriffspfade (1)

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

39. Wertbasierte Zugriffspfade (2)

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

41. 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.

42. 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

43. Navigierender Zugriffspfad für Join (2) CHAIN: Schlüssel-Satz Fremdschlüssel-Satz 1 Fremdschlüssel-Satz 2 Fremdschlüssel-Satz 3

44. Navigierender Zugriffspfad für Join (3) POINTERARRAY: Schlüssel-Satz Fremdschlüssel-Satz 2 Fremdschlüssel-Satz 1 Fremdschlüssel-Satz 3

45. 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

46. Detaildarstellung eines Blattseiten-records 30 3 F1 F2 F3 id2 id7 id9 F4 F3 F1 F2 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 40 1 F2  id6 Blattseiten-Records 50 2 F2  F3  id5 id10 Blattseite (ohne Längenfeld)

47. Kapitel 8.2.3 Spezielle Scan-Operatoren

48. 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.

49. Scan-Operator (2) Abfolge: • open scan: • 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.

50. Relationen-Scan • 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.