Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Universität Karlsruhe (TH) © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Kapitel 8 Satzmengenverwaltung.

Ähnliche Präsentationen


Präsentation zum Thema: "Universität Karlsruhe (TH) © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Kapitel 8 Satzmengenverwaltung."—  Präsentation transkript:

1 Universität Karlsruhe (TH) © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Kapitel 8 Satzmengenverwaltung

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

3 3 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Kapitel 8.1 Interne Dateien

4 4 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Ausgangslage Physische DB (satzorientiert) Zugriffs- struktur Kl.Physischer Datensatz enthält enthält Physische DB (seitenorientiert SegmentSeite repräsentiert durch repräsentiert durch enthält enthält Externe DBAusprägung des externen Datenmodells enthält Menge externer Objekte, mengenorientierte Anfragesprache Satzmenge, Zugriffspfad Performanzwahrende Umsetzung

5 5 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Ausgangslage Physische DB (satzorientiert) Zugriffs- struktur Kl.Physischer Datensatz enthält enthält Physische DB (seitenorientiert SegmentSeite repräsentiert durch repräsentiert durch enthält enthält Externe DBAusprägung des externen Datenmodells enthält Menge externer Objekte, mengenorientierte Anfragesprache Satzmenge, Zugriffspfad Satzmenge, mengeninterne und -übergreifende Zugriffspfade Direkte Zuordnung Abbildung Materialisierung Logische Zugriffspfade

6 6 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 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 7 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Zusammenhänge Interne DBInt. DateiInt. Datensatz enthält enthält Physische DB Zugriffs- struktur Physischer Datensatz repräsentiert durch repräsentiert durch 1 ? 1 1 enthält enthält Physische DB SegmentSeite repräsentiert durch repräsentiert durch enthält enthält Externe DBInstanzen des externen Datenmodells enthält Satzmenge, Zugriffspfad Satzmenge, mengeninterne und - übergreifende Zugriffspfade Menge externer Objekte, mengenorientierte Anfragesprache Gegenstand des Kapitels

8 8 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 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 9 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Sort-Operator (1) Externes Sortieren: Sortieren unter Zuhilfenahme des Hintergrundspeichers. Vorherrschende Technik: Sortieren durch Mischen (Sort- merge).

10 10 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Sort-Operator (2) Gunter42 Andreas24 Dieter4 Chris7 Berta77 Elle36 Tamara99 Dieter2 Mario9 Peer43 Dieter11 Andreas21 Andreas21 Andreas24 Berta77 Chris7 Dieter Elle36 Gunter42 Mario9 Peer43 Tamara99 Gunter42 Andreas24 Dieter4 Chris7 Berta77 Elle36 Tamara99 Dieter2 Mario9 Peer43 Dieter11 Andreas21 Andreas24 Dieter4 Gunter42 Berta77 Chris7 Elle36 Dieter2 Mario9 Tamara99 Andreas21 Dieter11 Peer43 Andreas24 Berta77 Chris7 Dieter4 Elle36 Gunter42 Andreas21 Dieter2 11 Mario9 Peer43 Tamara99 partitioninternal sortmerge

11 11 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Sort-Operator (3) Gunter42 Andreas24 Dieter4 Chris7 Berta77 Elle36 Tamara99 Dieter2 Mario9 Peer43 Dieter11 Andreas21 Andreas21 Andreas24 Berta77 Chris7 Dieter Elle36 Gunter42 Mario9 Peer43 Tamara99 Gunter42 Andreas24 Dieter4 Chris7 Berta77 Elle36 Tamara99 Dieter2 Mario9 Peer43 Dieter11 Andreas21 Andreas24 Dieter4 Gunter42 Berta77 Chris7 Elle36 Dieter2 Mario9 Tamara99 Andreas21 Dieter11 Peer43 Andreas24 Berta77 Chris7 Dieter4 Elle36 Gunter42 Andreas21 Dieter2 11 Mario9 Peer43 Tamara99 Sortierung von Stellvertretern zur Einsparung von E/A! Partition ~ Pufferkachelgröße Allgemein: m- Wege-Mischen Sequentieller Durchlauf: 1 Pufferkachel pro beteiligter Partition genügt (hier: 3)

12 12 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Sort-Operator (3) Gunter42 Andreas24 Dieter4 Chris7 Berta77 Elle36 Tamara99 Dieter2 Mario9 Peer43 Dieter11 Andreas21 Andreas21 Andreas24 Berta77 Chris7 Dieter Elle36 Gunter42 Mario9 Peer43 Tamara99 Gunter42 Andreas24 Dieter4 Chris7 Berta77 Elle36 Tamara99 Dieter2 Mario9 Peer43 Dieter11 Andreas21 Andreas24 Dieter4 Gunter42 Berta77 Chris7 Elle36 Dieter2 Mario9 Tamara99 Andreas21 Dieter11 Peer43 Andreas24 Berta77 Chris7 Dieter4 Elle36 Gunter42 Andreas21 Dieter2 11 Mario9 Peer43 Tamara99 Partition ~ Pufferkachelgröße Sequentieller Durchlauf: 1 Pufferkachel pro beteiligter Partition genügt Alternativen: n Nutzung der Pufferverwaltung (bequem, aber keine Kontrolle!) n Eigener Puffer

13 13 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Sort-Operator (4) Gunter42 Andreas24 Dieter4 Chris7 Berta77 Elle36 Tamara99 Dieter2 Mario9 Peer43 Dieter11 Andreas21 Andreas21 Andreas24 Berta77 Chris7 Dieter Elle36 Gunter42 Mario9 Peer43 Tamara99 Gunter42 Andreas24 Dieter4 Chris7 Berta77 Elle36 Tamara99 Dieter2 Mario9 Peer43 Dieter11 Andreas21 Andreas24 Dieter4 Gunter42 Berta77 Chris7 Elle36 Dieter2 Mario9 Tamara99 Andreas21 Dieter11 Peer43 Andreas24 Berta77 Chris7 Dieter4 Elle36 Gunter42 Andreas21 Dieter2 11 Mario9 Peer43 Tamara99 n: Seitenzahl, n B Kachelzahl E/A-Aufwand: 2 nE/A- Aufwand: 2 n log nB-1 (n/n B ) falls Seitengröße=Kachelgröße

14 14 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Kapitel 8.2 Relationales Datenmodell

15 15 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 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 R 1.X 1 nach R 2.X 2. Die Werte unter R 1.X 1 kommen unter R 2.X 2 vor X 2 Schlüssel von R 2 X 1 Fremdschlüssel in R 1.

16 16 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Kapitel Materialisierung

17 17 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Schema-beschriebene Strukturrepräsentation: N ist die Anzahl der Felder, Offs i ist der Offset innerhalb des Datensatzes, an der Wert von Feld i 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. Struktur von Datensätzen (1) LFeld Feld N N Offs Offs N

18 18 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Selbstbeschreibende Strukturrepräsentation: Ergänzung der vorhergehenden Struktur um F i = 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. Struktur von Datensätzen (2) L Feld Feld N N F 1 Offs F N Offs N

19 19 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Beispiel-Relationen OIDGeoIdMatValueColorV1V2…V7V8 id id redid 11 ….id 18 id id blueid 21 ….id 28 id id yellowid 31 ….id 38 Cuboid OIDNameSpecWeight id 77 Iron7.86 id 99 Gold19.0 Material OIDXYZ id id id id id id …. Vertex id i sind Schlüssel

20 20 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Direkte Materialisierung (1) Externe DBRelationTupel Interne DBInt. DateiInt. Datensatz repräsentiert durch repräsentiert durch enthält enthält enthält enthält Eineindeutige Zuordnung: N-ary Storage Model

21 21 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Direkte Materialisierung (2) OIDGeoIdMatValueColorV1V2…V7V8 id id redid 11 ….id 18 id id blueid 21 ….id 28 id id yellowid 31 ….id 38 Cuboid OIDNameSpecWeight id 77 Iron7.86 id 99 Gold19.0 Material OIDXYZ id id id id id id …. Vertex

22 22 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Direkte Materialisierung (3) 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.

23 23 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Materialisierte Projektion (1) Externe DBRelationTupel Interne DBDateiInt. Datensatz repräsentiert durch repräsentiert durch enthält enthält enthält enthält 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.

24 24 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Materialisierte Projektion (2) OIDGeoIdMatValueColorV1V2…V7V8 id id redid 11 ….id 18 id id blueid 21 ….id 28 id id yellowid 31 ….id 38 Cuboid OIDNameSpecWeight id 77 Iron7.86 id 99 Gold19.0 Material OIDXYZ id 11 0,00.0 id 18 0, id 21 0,00.0 id 28 0, id 31 0,00.0 id 38 0, …. Vertex

25 25 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 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 26 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 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 27 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 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 28 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Materialisierte Projektion (6) OIDGeoIdMatValueColorV1V2…V7V8 id id redid 11 ….id 18 id id blueid 21 ….id 28 id id yellowid 31 ….id 38 Cuboid OIDNameSpecWeight id 77 Iron7.86 id 99 Gold19.0 Material OIDXYZ id id id id id id …. Vertex...

29 29 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 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 30 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Materialisierte Selektion (1) Externe DBRelationTupel Interne DBDateiInt. Datensatz repräsentiert durch repräsentiert durch enthält enthält enthält enthält Die Tupel der Relation werden auf mehrere Dateien aufgeteilt (horizontale Fragmentierung). Als Kriterium dienen Wertebereiche unter einer Attributkombination.

31 31 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Materialisierte Selektion (2) OIDGeoIdMatValueColorV1V2…V7V8 id id redid 11 ….id 18 id id blueid 21 ….id 28 id id yellowid 31 ….id 38 Cuboid OIDNameSpecWeight id 77 Iron7.86 id 99 Gold19.0 Material OIDXYZ id id id id id id …. Vertex Cub_Iron Cub_Gold OIDGeoIdMatValueColorV1V2…V7V8 id id redid 11 ….id 18 id id blueid 21 ….id 28 OIDGeoIdMatValueColorV1V2…V7V8 id id yellowid 31 ….id 38

32 32 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Materialisierte Selektion (3) Gut für Range Queries. Schlecht bei Zugriff auf sämtliche Datensätze der Relation: Vereinigungsoperation erforderlich.

33 33 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Materialisierter Join (1) Externe DBRelationTupel Interne DBDateiInt. Datensatz repräsentiert durch repräsentiert durch enthält enthält enthält enthält 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.

34 34 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Materialisierter Join (2) OIDGeoIdMatValueColorV1V2…V7V8 id id redid 11 ….id 18 id id blueid 21 ….id 28 id id yellowid 31 ….id 38 Cuboid OIDNameSpecWeight id 77 Iron7.86 id 99 Gold19.0 Material OIDXYZ id id id id id id …. Vertex Cub_Mat OIDGeoIdMatNameSpecWeightValueColorV1V2…V7V8 id id 77 Iron redid 11 ….id 18 id id 77 Iron blueid 21 ….id 28 id id 99 Gold yellowid 31 ….id 38

35 35 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Kapitel Logische Zugriffspfade

36 36 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Navigierende Zugriffspfade AnforderungUmsetzungBewertung LISTBevorzugter, schneller, sequentieller Zugriff Geballte ListeEffizienter 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. CHAINNicht bevorzugter, sequentieller Zugriff Meist Verkettung als eingebetteter Zugriffspfad Änderungen an beliebiger Stelle, aber langsamer Zugriff.

37 37 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Wertbasierte Zugriffspfade (1) AnforderungUmsetzungBewertung Primär- index Eindeutiger Schlüssel: Exact Match Query schnell, Range Query anspruchslos B*-BaumKeine Kontrolle über interne Datei. Sekundär -index Mehrdeutiger Schlüssel: Exact Match Query schnell, Range Query anspruchslos B*-BaumKeine Kontrolle über interne Datei. Cluster- index Wie Primärindex, aber schnelle Range Query B + -BaumInterne Datei als geballte Liste.

38 38 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Umsetzung wertbasierter Zugriffspfade (1) Primärindex Sekundärindex

39 39 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Wertbasierte Zugriffspfade (2) AnforderungUmsetzungBewertung Mehrattri- butindex (Partial) Exact Match Query und Range Query auf mehr- dimensionalem Schlüssel mehr- dimensionaler Index Wenn Schneiden von Einzelindexen gewünscht, nur solche Zugriffspfade angeben! HashExact Match Query auf ein- oder mehrdeutigem Schlüssel Hash- verfahren Gestreute Speicherung der internen Datei.

40 40 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Umsetzung wertbasierter Zugriffspfade (2) Mehrdimensionaler Index über (GeoId, Value)

41 41 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 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. Join-unterstützender Zugriffspfad

42 42 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Navigierender Zugriffspfad für Join (1) Schlüssel-Satz Fremdschlüssel- Satz 1 LIST: Fremdschlüssel- Satz 2 Fremdschlüssel- Satz 3 Fremdschlüssel- Satz 4

43 43 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Navigierender Zugriffspfad für Join (2) Schlüssel-Satz CHAIN: Fremdschlüssel- Satz 1 Fremdschlüssel- Satz 2 Fremdschlüssel- Satz 3

44 44 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Navigierender Zugriffspfad für Join (3) Schlüssel-Satz POINTERARRAY: Fremdschlüssel- Satz 1 Fremdschlüssel- Satz 2 Fremdschlüssel- Satz 3

45 45 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 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. CH-Baum (1) 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 Gemeinsamer Schlüsselwert Datensätze nach Dateizugehörigkeit gruppiert

46 46 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 CH-Baum (2) Nicht-Blattseiten wie im B-Baum 102F1 F3 id1id8 303F1 F2 id2id9id7F3 702F1 F4 id3id12 902F2 F4 id11id4 401F2 id6 502F2 F3 id10id5 303F1F2id2id9id7F3 Detaildarstellung eines Blattseiten- records Blattseite (ohne Längenfeld) Blattseiten- Records F1 F2 F3 F4 Beispiel

47 47 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Kapitel Spezielle Scan-Operatoren

48 48 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 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 49 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 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. Startbedingung Stoppbedingung Suchrichtung Suchbedingung

50 50 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 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. Startbedingungbeginof Cuboid Stoppbedingungendof Cuboid Suchrichtungforward Suchbedingungall | Color=red

51 51 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Index-Scan (1) 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. StartbedingungCuboid 20 StoppbedingungCuboid > 75 Suchrichtungforward SuchbedingungColor=red

52 52 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Index-Scan (2) Beispiel: Clusterindex (B + -Baum): StartbedingungCuboid 20 StoppbedingungCuboid > 75 Suchrichtungforward SuchbedingungColor=red

53 53 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Link-Scan (1) 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. Startbedingungbeginof Material Stoppbedingungendof Material Suchrichtungforward SuchbedingungName=IronGeoId 3000

54 54 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Link-Scan (2) OIDGeoIdMatValueColorV1V2…V7V8 id id redid 11 ….id 18 id id blueid 21 ….id 28 id id yellowid 31 ….id 38 Cuboid OIDNameSpecWeight id 77 Iron7.86 id 99 Gold19.0 Material

55 55 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 k-d-Scan 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. StartbedingungGeoId 3000Value StoppbedingungGeoId > 8000Value > Suchrichtungforward SuchbedingungColor=red

56 56 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Kapitel 8.3 Objektorientiertes Datenmodell

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

58 58 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Kapitel Materialisierung von Objekten

59 59 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Materialisierungsstrategie Objekte des selben Typs bilden Satzmenge. Materialisierung dieser Satzmengen nach den selben Strategien wie bei Relationen.

60 60 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Objekte mit großen Anteilen (1) 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. class Product { Name: string; Price: float; Cmps: setof Part; Image: BLOB }

61 61 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Objekte mit großen Anteilen (2) DB DB2 File Manager Datei 1 Datei 2 Datei 3 Datei 4 SQL AnfrageDatei-Anfrage Autorisierungsprüfung Ü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.

62 62 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Materialisierung der Vererbung (1) Typhierarchie: GeoPrimitive Cylinder Cuboid Pipe {} {id 1,id 2,id ´3 }{id 4,id 5 } {id 6,id 7 } 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 }

63 63 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Materialisierung der Vererbung (2) 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.

64 64 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Materialisierung der Vererbung (2) GeoPrimitive CylinderCuboid Pipe {id 1,id 2,id ´3 } {} {id 4,id 5 } {id 6,id 7 }

65 65 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Materialisierung der Vererbung (3) 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.

66 66 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Materialisierung der Vererbung (3) GeoPrimitive CylinderCuboid Pipe {id 1,id 2,id ´3 } {} {id 4,id 5 } {id 6,id 7 }

67 67 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Materialisierung der Vererbung (4) 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.

68 68 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Kapitel Logische Zugriffspfade für Verzeigerung: Pfad-Indexe

69 69 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Pfade Modell: Pfade in objektorientierten Datenbanken Eine Objektbank enthält explizite Verweise zwischen Objekten: Zwischen einem Objekt o 1 und einem Objekt o 2 besteht eine Referenz (von o 1 nach o 2 ), wenn o 1 den Identifikator von o 2 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.

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

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

72 72 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Pfadausdrücke Typisierung: P= t 0.A 1..A i..A n t1t1 titi tntn R0R0 R1R1 R2R2 v A1A1 A2A2 ovov t2t2 t0t0 t1t1 Beispiel: P=Product.Cmps.Geo.Mat.Name Part Cuboid Material string

73 73 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 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.

74 74 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Binäre Pfadrelationen (1) Fall 1: Fall2: id1 id2 id1 id3 id4

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

76 76 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Access Support Relations (1) Formale Definition von ASRs ASRs werden über den Join mehrerer binärer Pfadrelationen definiert.

77 77 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Access Support Relations (2) Vollständige ASR-Extension Die vollständige Extension enthält alle vollständigen und partiellen Pfade. Definition: t 0.A 1..A i..A n full := t 0.A 1 t n-1.A n Partielle Pfade beginnen und/oder enden daher mit NULL- Werten. Exkurs: Äußerer Join (full outer join) =

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

79 79 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Access Support Relations (3) 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: t 0.A 1..A i..A n left := t 0.A 1 t n-1.A n Exkurs: Linker äußerer Join (left outer join) =

80 80 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Beispiel-Objektbank

81 81 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Access Support Relations (4) 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: t 0.A 1..A i..A n right := t 0.A 1 t n-1.A n Exkurs: Rechter äußerer Join (right outer join) =

82 82 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Beispiel-Objektbank

83 83 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Access Support Relations (5) 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: t 0.A 1..A i..A n can := t 0.A 1 t n-1.A n Exkurs: Equi-Join =

84 84 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Beispiel-Objektbank

85 85 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Anfragebearbeitung mit ASR Anfragearten: Rückwärts-Anfrage select o from o in t i where predicate (o.A i+1.···.A j ) Vorwärts-Anfrage select o.A i+1.···.A j from o in t i where predicate (o)

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

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

88 88 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Zugriff auf Access Support Relations (1) Unterstützung von Vorwärtsanfragen der Form select = o.A i+1.···.A j from o in t i where predicate (o) Es wird ein zusätzlicher Zugriffspfad auf der i-ten Spalte der ASR t 0.A 1.···.A n 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.

89 89 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Zugriff auf Access Support Relations (2) Unterstützung von Rückwärtsanfragen der Form select o from o in t i where predicate (o.A i+1.···.A j ) 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).

90 90 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Kapitel Kombinierte Materialisierung von Objekten und Zugriffspfaden

91 91 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 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.

92 92 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Beispiel (1) Geold: 1 Mat: id77 Cuboid Geold: 8 Mat: id99 id8 Geold: 5 Mat: id77 id5 Geold: 7 Mat: id99 id7 Geold: 6 Mat: id88 id6 Geold:3 Mat: id99 id3 Geold: 2 Mat: id77 id2 Geold:4 Mat: id77 id4 Geold: 9 Mat: - id9 Name: Iron SpecWght: 7.86 Name: Gold SpecWght: 19.0 id99 Name: Alu SpecWght: 3.02 id88 id77 Id: 3000 Geo: {} Part Id: 6700 Geo:{id9} id150 Id: 1001 Geo: {id6} id130 Id: 2010 Geo:{} id140 Id: 1002 Geo: {id7} id131 Id: 4712 Geo: {id3} id121 Id: 4711 Geo: {id1,id2} id120 Id: 4713 Geo: {id4,id5} id122 Name: Gripper Price: Cmps:{id120,id121,id122} Image:... Name: Bolt Price: Cmps: {id140} Image:... id102 Name: Wheel Price: Cmps: {id130,id131} Image:... id101 id100 Material id110 id1 Product

93 93 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Beispiel (2) OIDGeoIdMatValueColorV1V2…V7V8 id id redid 11 ….id 18 id id blueid 21 ….id 28 id id yellowid 31 ….id 38 Cuboid OIDNameSpecWeight id 77 Iron7.86 id 99 Gold19.0 Material OIDXYZ id id id id id id …. Vertex

94 94 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Nachteile der Gruppierung Nachteile: 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.

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

96 96 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Modell der Gruppierung: NF 2 -Datensätze Datenmodell der NF 2 -Relation (Non First Normal Form): Geschachtelte Relation durch Zulassen mengenwertiger Attribute (Unterrelationen). Die Elemente einer Unterrelation können ebenfalls wieder Unterrelationen besitzen. NF 2 -Tupel: Tupel mit mengenwertigen Attributen.

97 97 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Materialisierung Grundsatz: NF 2 -Datensätze werden in ihre Nicht-NF 2 - 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 NF 2 -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.

98 98 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Freie Speicherung (1) id 1 red39.99id 77 8id id Kardinalität der Menge (=Länge der Zeigerreihung)

99 99 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Freie Speicherung (2) id 1 red39.99id 77 8 id 2 blue19.95id 77 8 id 3 yellow89.90id 99 8 id id id id id id

100 100 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Freie Speicherung (3) Vorteile: Wachsen und Schrumpfen des Datensatzes bzw. der Unterrelationen wird gut unterstützt. Nachteile: Die Teile eines NF 2 -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.

101 101 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Gesteuerte Speicherung (1) Beispiel DASDBS (Darmstadt Datenbanksystem): Die Menge der Seiten, die ein NF 2 -Datensatz belegt (Adressraum des Datensatzes), sind exklusiv dem Datensatz zugeordnet. Spezielle Adressen sind möglich. Ballen ist möglich. Ein NF 2 -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.

102 102 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Gesteuerte Speicherung (2) U 3 3 V 12 3 ABC W W W DEDEDE 10 G 11 G 12 G F F 7 F U ABC D 123 V EF W G Kardinalität der Unterrelation

103 103 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Gesteuerte Speicherung (3) U 3 3 V ABC DEDE DE WWW 7 F 10 G 11 G 8 F 12 G 9 F P204 P123 P316 Ballen der Blätter in depth-first Reihenfolge Ballen der internen Knoten in breadth-first Reihenfolge

104 104 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Gesteuerte Speicherung (4) 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.

105 105 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Gesteuerte Speicherung (5) Hierarchische TIDs für die externe Referenzierung: Ein hierarchischer TID ist eine Folge: Die erste Komponente ist die (externe) Seitennummer der Wurzel des NF 2 -Datensatzes. Die restlichen Komponenten beschreiben einen Pfad in dem NF 2 -Datensatz. Hierarchische TIDs müssen bei Verschiebungen von internen Datensätzen auf den Seiten des NF 2 -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.

106 106 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Gesteuerte Speicherung (6) U 3 3 V AB C DEDE DE WWW 7 F 10 G 11 G 8 F 12 G 9 F P123 (P123,2,1,0) (P123,2,2,1,1) 3 Seitennummer 2. Unterrelation( V ) Element Nr. 1 Nicht-mengenwertige Feldwerte (angezeigt durch die 0 ) Seitennummer 2. Unterrelation( V ) Element Nr Unterrelation( W ) Element Nr. 1

107 107 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Gesteuerte Speicherung (7) U 3 3 V AB C DEDE DE WWW 7 F 10 G 11 G 8 F 12 G 9 F (P123,0) P123 Seitennummer (P123,2,1,0) (P123,1,2) (P123,2,2,1,1) 2. Unterrelation( V ) Element Nr. 1 Nicht-mengenwertige Feldwerte (angezeigt durch die 0 ) (P123,2,2) Seitennummer 2. Unterrelation( V ) 3 Element Nr. 1 Element Nr Unterrelation( W )

108 108 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Gesteuerte Speicherung (8) 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.

109 109 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Kapitel 8.4 XML-Datenmodell

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

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

112 112 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Dokument als Volltext (1) Materialisierung von XML-Dokumenten Materialisierung als Volltext Dateispei- cherung: Dateien Datenbank- speicherung: CLOB Abbildung auf konventionelle Datenbankstrukturen Struktur- bewahrende Abbildung Struktur- zerstörende Abbildung Materialisierung als Graphstruktur Generische Graphspei- cherung Document Object Model (DOM) Zugriff wie bei Information Retrieval: Volltextindex Umsetzung auf Relationen Umsetzung relational / objektrelational SchreddernNative Lösung

113 113 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Dokument als Volltext (2) Foundations of Databases Serge Abiteboul 1997 Addison Wesley … Foundations of Databases Serge Abiteboul 1997 Addison Wesley … XML Bibliography BibIDPaperList DBLP Fo undations of Databases Serg e Ab iteboul 1997 Addison Wesley … DBLP.xml Zusätzlicher Volltextindex

114 114 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Dokument als Volltext (3) 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.

115 115 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Dokument als Graphstruktur Materialisierung von XML-Dokumenten Materialisierung als Volltext Dateispei- cherung: Dateien Datenbank- speicherung: CLOB Abbildung auf konventionelle Datenbankstrukturen Struktur- bewahrende Abbildung Struktur- zerstörende Abbildung Materialisierung als Graphstruktur Generische Graphspei- cherung Document Object Model (DOM) Zugriff wie bei Information Retrieval: Volltextindex Umsetzung auf Relationen Umsetzung relational / objektrelational SchreddernNative Lösung

116 116 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 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.

117 117 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Generischer Dokumentgraph (2) Foundations of Databases Serge Abiteboul 1997 Addison Wesley … Foundations of Databases Serge Abiteboul 1997 Addison Wesley … XML bib paper o12 id Foundations… title 4 4 author Serge firstname Abiteboul 1997 year Addison… publisher lastname

118 118 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI bib paper o12 id Foundations… title 4 4 author Serge firstname Abiteboul 1997 year Addison… publisher lastname Kanten Generischer Dokumentgraph (3) Name BeginnZiel/WertIstText bib paper id title author firstname lastname year publisher nein ja nein ja 2 3 o12 Foundations… 4 Serge Abiteboul 1997 Addison… Reihenf Bei Bedarf zusätzliches Attribut, um XML-Attribut und XML-Element unterscheiden zu können

119 119 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Document Object Model (1) DOM: API mit Klassenstruktur DOMImplementationNodeNodeListNamedNodeMap Attr CharacterData Document DocumentType Element Entity EntityReference Notation getChildren() getFirstChild() getNextSibling() getParentNode() getPreviousSibling() hasChildren() insertBefore(node,node) removeChild(node) replaceChild(node) getChildren() getFirstChild() getNextSibling() getParentNode() getPreviousSibling() hasChildren() insertBefore(node,node) removeChild(node) replaceChild(node) getAttributes() getElementsByTagName(string) getTagName() setAttribute(attribute) setAttribute(attributelist) setTagName(string) getAttributes() getElementsByTagName(string) getTagName() setAttribute(attribute) setAttribute(attributelist) setTagName(string) getName() getSpecified() getValue() setName(string) setSpecified(boolean) setValue(nodelist) toString() getName() getSpecified() getValue() setName(string) setSpecified(boolean) setValue(nodelist) toString()

120 120 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Document Object Model (2) DOM: Beispiel Abbildung auf Relationen per Split Instance Model DOMImplementationNodeNodeListNamedNodeMap Attr CharacterData Document DocumentType Element Entity EntityReference Notation

121 121 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Document Object Model (3) Foundations of Databases Serge Abiteboul 1997 Addison Wesley … Foundations of Databases Serge Abiteboul 1997 Addison Wesley … node_idnode_typedoc_idparentp_siblingn_sibling 001elementb elementb elementb elementb elementb elementb elementb elementb attributeb node_idtag_nametext 001bib 002paper 003titleFoundations of Databases 004author 005firstnameSerge 006lastnameAbiteboul 007year publisherAddison-Wesley node element

122 122 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 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.

123 123 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Dokument als Relation Materialisierung von XML-Dokumenten Materialisierung als Volltext Dateispei- cherung: Dateien Datenbank- speicherung: CLOB Abbildung auf konventionelle Datenbankstrukturen Struktur- bewahrende Abbildung Struktur- zerstörende Abbildung Materialisierung als Graphstruktur Generische Graphspei- cherung Document Object Model (DOM) Zugriff wie bei Information Retrieval: Volltextindex Umsetzung auf Relationen Umsetzung relational / objektrelational SchreddernNative Lösung

124 124 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 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.

125 125 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Strukturbewahrende Abbildung (2) DTD Foundations of Databases Serge Abiteboul 1997 Addison Wesley … Foundations of Databases Serge Abiteboul 1997 Addison Wesley … XML

126 126 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Strukturbewahrende Abbildung (3) 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

127 127 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Strukturbewahrende Abbildung (4) Im Beispiel wird author+ zu author* Neue DTD beschreibt also eine Obermenge von XML- Dokumenten DTD DTD

128 128 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Strukturbewahrende Abbildung (5) 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.

129 129 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Strukturbewahrende Abbildung (6) id bib paper author year publisher age firstname lastname * * * * title DTD-Graph ? ?

130 130 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Strukturbewahrende Abbildung (7) 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.

131 131 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Strukturbewahrende Abbildung (8) bib paper id author year publisher age firstname lastname * * * * title relation Bib (bibID) relation Author (authorID, paperID, age, firstname, lastname ) ? ? relation Paper (paperID, bibID, id, title, year, publisher)

132 132 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Strukturbewahrende Abbildung (9) 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.

133 133 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Strukturzerstörende Abbildung Grundgedanke: Verwenden einer frei wählbaren Abbildungsvorschrift, die die Elemente so zusammenfasst, dass bestimmte Anfragen besonders effizient beantwortet werden können.


Herunterladen ppt "Universität Karlsruhe (TH) © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 8 Kapitel 8 Satzmengenverwaltung."

Ähnliche Präsentationen


Google-Anzeigen