Referenzarchitektur Externes Datenmodell Anfragebearbeitung Internes Datenmodell Satz- u. Satzmengenverwaltung Physische Datenstrukturen Zugriffsschicht.

Präsentation zum Thema: "Referenzarchitektur Externes Datenmodell Anfragebearbeitung Internes Datenmodell Satz- u. Satzmengenverwaltung Physische Datenstrukturen Zugriffsschicht."—  Präsentation transkript:

1 Referenzarchitektur Externes Datenmodell Anfragebearbeitung Internes Datenmodell Satz- u. Satzmengenverwaltung Physische Datenstrukturen Zugriffsschicht Hauptspeicherseiten u. Segmente Dateien Dateiverwaltung Geräteschnittstelle Scheduler Recovery-Verwalter Segment- u. Pufferverwaltung

2 Lesestruktur (1) Betrachte –FLUG(flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung) –BUCHUNG(flugNr, ticketNr, platzCode, datum) Angenommenes Leseprofil: –Die Mehrzahl der Benutzer beginnt zunächst mit einer Kurzinformation (Strecke, Verkehrstage) über die Flüge. –Geschäftsreisende interessieren sich nur für Flüge, die spätestens bis 10 Uhr abgehen. –Die Disponenten in Frankfurt haben nur die von Frankfurt abgehenden Buchungen im Auge. Ergebnis: Die drei internen Dateien –FLUGKURZ(flugNr, von, nach, wochentage) –FRÜHFLUG (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung) –FRA_FLÜGE(flugNr, nach, abflugszeit, ankunftszeit, ticketNr, datum)

3 Lesestruktur (2) Ergebnis: Die drei internen Dateien –FLUGKURZ(flugNr, von, nach, wochentage) –FRÜHFLUG (flugNr, von, nach, ftypId, wochentage, abflugszeit, ankunftszeit, entfernung) –FRA_FLÜGE(flugNr, nach, abflugszeit, ankunftszeit, ticketNr, datum) Relationsalgebraische Ausdrücke hierzu: –FLUGKURZ flugNr,von,nach,wochentage (FLUG) –FRÜHFLUG := abflugszeit 12:00 (FLUG) –FRA_FLÜGE flugNr,nach,abflugszeit,ankunftszeit,ticketNr,datum ( von = "FRA" (BUCHUNG FLUG) )

4 Allgemeine Relationen- Abbildung Im Prinzip können interne Dateien beliebige Transformationen der externen Relationen darstellen interne Dateien sind materialisierte Sichten auf Ausgangsrelationen. –Interne Dateien können nur Teile von Relationen umfassen. –Interne Dateien können sich aus mehreren Relationen zusammensetzen. Anfragebearbeitung führt dann auf inverses Sichtenproblem: Gegeben materialisierte Sichten auf die Ausgangsrelationen, wie können die Ausgangsrelationen rekonstruiert werden? Bei beliebigen algebraisch definierten Sichten unentscheidbar!

5 Zerlegungsmöglichkeiten in der Praxis (3) Direktspeicherung: Eineindeutige Zuordnung einer typgleichen internen Datei zu jeder Relation. –FLUG(flugNr, von, nach, ftypId, wochentage, abflugszeit,ankunftszeit, entfernung) –BUCHUNG(flugNr, ticketNr, platzCode, datum) wären also die internen Dateien zu den beiden Ausgangsrelationen. Vertikale Fragmentierung: Verlustfreie Zerlegung in mehrere Relationen. Der Schlüssel der Ausgangsrelation muss also in jeder Datei vorkommen. Im Beispiel gewinnt man aus FLUG u.a. –FTYP(flugNr, ftypId) –FLUGKURZ(flugNr, von, nach, wochentage) –Im Extremfall: Für jedes Nichtschlüsselattribut eigene Datei.

6 Zerlegungsmöglichkeiten in der Praxis (4) Horizontale Fragmentierung: Zerlegung in mehrere Relationen durch Selektion. –Mit Selektionsbedingungen B 1, B 2,..., B n muss B 1 B 2... B n true sein, d.h. die Vereinigung der Dateien muss wieder die Ausgangsrelation ergeben. –Ein Beispiel wäre FRÜHFLUG zusammen mit einer zweiten Datei mit den restlichen Flügen. Hinzukommen können noch Indexdateien. –Beispiel: FLUG_INDEX(flugNr,flugTid )