Temporale Daten in objekt-relationalen Datenbanksystemen

Temporale Daten in objekt-relationalen Datenbanksystemen Carsten Kleiner Universität Hannover Institut für Informatik FG Datenbanken und Informationssysteme (dbis) 30159 Hannover 13.Workshop Grundlagen von Datenbanken 05. - 08.06.2001

Gliederung 1. Motivation für temporale Daten und Attributzeitstempel 2. Konzeptionelles Modell für Attributzeitstempel 3. Logisches Modell für die Realisierung des Konzepts auf Basis eines objekt-relationalen Datenbanksystems (ORDBS) 4. Physische Realisierung in Oracle 8i 5. Ausblick

Motivation: Temporale Daten Viele Informationen sind zeitbehaftet Kategorien temporaler Informationen: Zeitpunkte (Zeitreihen), Zeitintervalle (temporale Elemente), Funktionen der Zeit Unterscheidung temporaler Informationen in DBS: Gültigkeitszeit und/oder Transaktionszeit Attribut- oder Tupelzeitstempel Bisher: relationale DBS mit Tupelzeitstempeln Jetzt: objekt-relationale DBS mit Attributzeitstempeln elegante und realitätsnahe Modellierung

Konzeption Bitemporale Tupelzeitstempel: BCDM (Snodgrass, 1995) Lineare, diskrete, beschränkte Zeit Chronons als unteilbare elementare Zeiteinheit ( abzählbar) Zeitstempel auf Attributen Temporale Versionen aller Datentypen: statt Domain D nun Domain D D V T D T T Domain für Gültigkeitszeit D V T : Menge von Chronons Domain für Transaktionszeit D T T : Menge von Chronons {UC} (UC = until changed)

Semantik des Konzepts Jeder bitemporale Attributwert bekommt eine Teilmenge von D V T als Gültigkeitsinformation. Jedes Chronon dieser Menge bekommt eine Teilmenge von D T T als Transaktionszeit. Form der Tupel mit i nicht-temporalen und n i temporalen Attributen: t = (a 1,..., a i, {a i+1, {c vt, {c tt }}},..., {a n, {c vt, {c tt }}}) c vt D V T sind dabei Gültigkeitszeitchronons, c tt D T T Transaktionszeitchronons

Update-Semantik insert: 1. Einfügen eines Tupels mit angegebenen nicht-temporalen Informationen und Gültigkeitszeiten 2. Transaktionszeit wird initial auf UC gesetzt 3. Nach Ende einer Transaktionszeiteinheit: Update aller UC-Tupel in der Datenbank automatisch update und delete ähnlich Beachte: delete löscht nie physisch Tupel, entfernt lediglich UC- Einträge!

Beispiel 70 60 50 40 30 20 10 VT 5000 4000 3000 Scott Miller 10 20 30 40 50 60 Miller TT ID Name Salary Miller: 3000: {(10,10),...,(10,24), {(10,10),...,(10,29),...,..., (19,10),...,(19,24), (29,10),...,(29,29)} (50,60),...,(50,75), 4000:..., {(30,30),...,(30,49), (69,60),...,(69,75),..., 1 (50,UC),...,(69,UC)} (49,30),...,(49,49), (50,30),..., (50,39),..., (64,30),...,(64,39)} Scott: 5000: {(20,25),...,(20,59), {(50,50),...,(50,75), (49,25),...,(49,59)}..., (74,50),...,(74,75), (50,UC),...,(74,UC)}

Anmerkung Hier haben die Tupel die übersichtlichere Form: t = (a 1,..., a i, {a i+1, {(c vt, c tt )}},..., {a n, {(c vt, c tt )}} Ist äquivalent zur semantischen Form: t = (a 1,..., a i, {a i+1, {c vt, {c tt }}},..., {a n, {c vt, {c tt }}} leicht konvertierbar

Umsetzung in ORDBS Realisierung des konzeptionellen Modells in objekt-relationalen Datenbanken: direkte Umsetzung sehr ineffizient wegen: zahlreicher Zeitstempel Asymmetrie Einführung von Intervallen bzw. temporalen Elementen Elegantere Modellierung durch Verwendung einer DB-Spalte pro Attribut (temporal oder nicht-temporal) Einführung von temporalen Versionen der Datentypen (Ausnutzung der objekt-relationalen Funktionalität)

Beispiel Beispiel für Gültigkeitszeit und Standarddatentyp INTEGER: CREATE TYPE chronon (time LONGINT); CREATE TYPE interval (begin chronon, end chronon); CREATE TYPE tempelement SET OF interval; CREATE TYPE vt_integer_base (value INTEGER, time tempelement); CREATE TYPE vt_integer LIST OF vt_integer_base;

Datenintegrität Zur Garantie der Datenintegrität sind Prüfungen vorzusehen: chronon muss Zeitpunkte aus/in die interne Zahldarstellung wandeln können (cast) interval muss der Bedingung begin < end genügen (map function) In einem tempelement müssen Intervalle disjunkt und nicht aneinandergrenzend sein (update trigger o. ä.) Verwendung von vt_integer erfordert Disjunktheit aller temporalen Elemente in einem Tupelattributwert (update trigger)

Beispieltabelle CREATE TABLE employee ( id NUMBER PRIMARY KEY, name vt_string, salary vt_integer); INSERT INTO employee VALUES ( 1, vt_string_base( Miller, {interval(chronon(10),chronon(20))}), vt_integer_base(3000, {interval(chronon(10),chronon(30))}) ) VALIDTIME UPDATE employee SET name=vt_string_base( Scott,{interval(chronon(20),chronon(50))}) WHERE id = 1

Bitemporale Datentypen Beispiel für bitemporale Version des Standarddatentyp INTEGER: CREATE TYPE bt_integer_base (value INTEGER, validtime tempelement, transtime tempelement); CREATE TYPE bt_integer LIST OF bt_integer_base; Realisierung von UC als maxint möglich entsprechende Integritätssicherung erforderlich spezielle Benutzerunterstützung für Transaktionszeit vorsehen!

Physische Realisierung Kollektionen in Oracle 8i: VARRAY: feste Maximalgrösse, Speicherung inline NESTED TABLE: Grösse beliebig, Speicherung als eigene Tabelle keine Schachtelung von Kollektionstypen erlaubt Entwurfsalternativen für physische Realisierung: Auflösung der Schachtelung durch Einführung von Redundanzen anstelle einer Kollektion Verwendung von Referenzen anstelle von temporalen Werten

Geschachtelte Kollektion CREATE TYPE tempelement SET OF interval; CREATE TYPE vt_integer_base (value INTEGER, time tempelement); CREATE TYPE vt_integer LIST OF vt_integer_base;

Realisierungsalternativen (1) Auflösung der äusseren Kollektion (über Werte) durch Verwendung von vt_integer_base: sehr grosse Redundanz durch Vervielfachung ganzer Tupel Aufteilung in Paare bei mehreren temporalen Attributen? Transparenz und Effizienz (multiplikative Vervielfachung)? Effiziente Anfragebearbeitung für temporale Anfragen kaum möglich, da stets alle Tupel zu einem real world object benötigt Veranschaulichung: Ein Tupelattributwert ( a, {[c vt1, c vt2 ]} ) wird zu mehreren Tupelattributwerten (a, {[c vt1, c vt2 ]})

Realisierungsalternativen (2) Auflösung der inneren Kollektion (über temporale Elemente) durch Verwendung von Intervallen: eine geschachtelte Tabelle pro temporalem Attribut benutzer-definierte Zugriffsstruktur leicht realisierbar effiziente Bearbeitung von temporalen Joins (gleiche Attribute) emp id name salary e_name value valid 1 Miller [10,20) 2 Scott [20,50) Miller [50,70) Allen [10,70) e_sal value valid 3000 [10,30) 4000 [30,50) 5000 6000 [50,75) [10,70)

Realisierungsalternativen (3) Veranschaulichung: Ein Tupelattributwert ( a, {[c vt1, c vt2 ]} ) wird zu mehreren Tupelattributwerten a, [c vt1, c vt2 ] ) Bei mehreren temporalen Attributen nur additive Vervielfältigung der Redundanz

Realisierungsalternativen (4) Referenzen auf andere Tabelle mit temporalen Werten: nicht getestet, da Realisierung von REFs bisher sehr ineffizient und instabil; Rest ähnlich zur vorherigen Lösung Verwendung einer globalen Zeitstempeltabelle mit Referenzen in den geschachtelten Tabellen: Lange Antwortzeiten für Anfragen wegen ineffizienter Realisierung der Referenzen, grosser Verwaltungsaufwand Verwendung von Tupelzeitstempeln durch Einführung einer Relation pro temporalem Attribut: Lange Antwortzeiten für Anfragen, da stets grosse Joins erforderlich (trotz Clusterung)

ang chefnr ang_chefnr_nt tsr gehalt 27 13 27 27 ang_gehalt_nt tsr ang_name_nt tsr Muel ler Meier Boss ang_nr_nt tsr t_stamps_nt t_stamps 01.03.2000 01.03.2000 01.10.2000 01.07.2000 01.04.2000 01.04.2000 01.04.2000 01.08.2000 01.11.2000 01.05.2000 01.05.2000 01.09.2000 12 13 27 5000 5500 5300 5400 5200 5700 nr 01.07.2000 01.10.2000 01.08.2000 01.11.2000 01.09.2000 name ts val val vt_begin vt_end val val

ang_nr 12 13 27 1 2 3 01.03.2000 01.04.2000 01.05.2000 ts ang_name Muel ler Meier Boss 1 2 3 ang_gehalt 5000 5500 5300 5400 5200 5700 ang_nr_nt ang_chefnr 27 13 27 27 01.03.2000 01.10.2000 01.07.2000 01.04.2000 01.11.2000 01.05.2000 01.09.2000 01.03.2000 01.04.2000 01.05.2000 ang_name_nt 01.03.2000 01.04.2000 01.08.2000 01.05.2000 ang_chefnr_nt 01.07.2000 01.10.2000 01.11.2000 01.09.2000 01.08.2000 1 2 2 3 ang_gehalt_nt val rwo vt_begin ts ts ts rwo rwo rwo val val val vt_begin vt_begin vt_end vt_begin vt_end vt_end 1 1 2 2 3 3 vt_end

Realisierungsstand Laufzeitvergleiche für die verschiedenen physischen Realisierungen durchgeführt Beste Zeiten bei Auflösung der inneren Kollektion Datenbankschnittstelle für Anfragesprache ähnlich ATSQL2, erweitert um einige Funktionen für Attributzeitstempel, mit automatischer Übersetzung von Anfragen, DDL- und DML-Statements Implementierung von verallgemeinerten Suchbäumen (GiST) als benutzerdefinierte Indexstruktur für Oracle 8i erfolgt verwendbar als Basis für benutzerdefinierte Indexstrukturen auf temporalen Attributen Motivation dafür aus dem Bereich der räumlichen und räumlichzeitlichen Daten

Fazit Konzeptionelles Modell für Attributzeitstempel temporale Versionen aller Datentypen Logische Umsetzung in ORDBS einfach benutzerdefinierte Typen mit Kollektionen verwenden Physische Realisierung noch umständlich Auflösung geschachtelter Kollektionen durch Redundanz Physische Realisierung schwieriger bei bitemporalen Daten ORDBS ermöglichen naheliegende und elegante Modellierung von temporalen Informationen mit Attributzeitstempeln

Ausblick Integration von Transaktionszeit in physische Realisierung und Anfrageschnittstelle Fertigstellung der benutzerdefinierten Indexstrukturen auf temporalen Attributen Erweiterung auf weitere Basisdatentypen: z. B. Geometrien räumlich-zeitliche Daten Temporale Anfragesprache für spezielle Funktionen auf Attributzeitstempeln (erforderlich?) und für Transaktionszeitunterstützung Anpassung der physischen an die logische Realisierung nach Wegfall der Einschränkungen