Konzepte temporaler Datenbanken

Konzepte temporaler Datenbanken
Taoufik Saissi Hassani

Konzepte temporaler DB
Agenda Motivation Temporale Datenbanken Temporale Daten im Data Warehouse Zusammenfassung Konzepte temporaler DB

Motivation Aktuelle Datenbanken bieten nur eine Momentaufnahme der Daten Zeitliche Entwicklung wird nicht unterstützt Analyse von Zeitdaten erschwert: „Alle Wochen in denen keine Termine vorliegen“ Konzepte temporaler DB

Agenda Motivation Temporale Datenbanken Begriffsdefinition Merkmale der Zeitdimension Temporale Datenmodelle Das Datenmodell BCDM TSQL2 & SQL/Temporal Datentypen für Zeitangaben Ansätze temporaler Datenbanken Temporale Daten im Data Warehouse Zusammenfassung Da muss man etwas davon erzählen Konzepte temporaler DB

Temporale Datenbanken
Erweitern relationale DB um eine Zeitdimension Temporale Datenbanken (TDB bzw. DBMS würden eine umfassendere Zeitunterstützung als dies derzeitige herkömmliche Datenbanksysteme tun bieten. Inzwischen existiert eine Vielzahl von Vorschlägen, wie eine solche Zeitunterstützung auf Basis von herkömmlichen relationalen DBMS realisiert werden kann. Vereinfachend lassen sich Relationen in TDB als dreidimensionale Objekte betrachten. Die ersten beiden Dimensionen, Attribute und Werte, werden um eine dritte Dimension Zeit erweitert. D.h. jedem Tupel einer Relation wird eine bestimmte Zeit zugeordnet in der es existiert bzw. gültig ist. Abb. 1: Temporale Relation als ein dreidimensionales Objekt Konzepte temporaler DB

Temporale Datenbanken
Arten temporaler Datenbanken (TDB): Transaktionszeit (transaction time) Zu jeder Transaktion wird die aktuelle Serverzeit gespeichert Reine Vergangenheitsbetrachtung Gültigkeitszeit (valid time) Ergänzend gibt der Nutzer bei Anfragen einen Gültigkeitszeitraum an bi-temporale Datenbanken Unterstützung beider Zeitarten Bei der Betrachtung der Zeit spielt das Bezugssystem eine entscheidende Rolle. Es kann bspw. die Uhr des Datenbankservers als Bezugspunkt genutzt werden, genauso gut kann aber auch eine fiktive Zeit des Nutzers als Bezugspunkt verwendet werden. Daher wird in TDB zwischen folgenden Arten der Zeit unterschieden. Transaktionszeit (transaction time) bezeichnet den (physischen) Zeitpunkt an dem eine Relation der DB hinzugefügt bzw. verändert wurde. Dieses von dem DBMS automatisch gepflegte Zeitprotokoll, wird meist durch ein bzw. zwei Attribute realisiert, um entweder den Zeitpunkt der Zustandsänderung bzw. das Zeitintervall, in dem dieser Zustand existierte, zu speichern. Die Protokollierung der Transaktionszeit bietet somit eine Historie der Aktivitäten auf der DB. Die alleinige Betrachtung dieser reicht meist für die Abbildung sämtlicher temporaler Aspekte nicht aus. Zum einen werden nur die Zeiten der Datenbankaktivitäten nicht aber die Zeiten der Anwendung bzw. der Gültigkeit in der realen Welt erfasst zum anderen ist nur eine reine Vergangenheitsbetrachtung möglich. Gültigkeitszeit (valid time) beschreibt auf logischer Ebene, zu welcher Zeit assoziierte Daten in einer gegebenen Anwendung bzw. in der realen Welt Gültigkeit haben. Im Gegensatz zu den Transaktionszeiten werden diese Zeiten nicht automatisch vom Datenbanksystem gepflegt, sondern vom Nutzer bzw. der Anwendung bei Operationen auf den betreffenden Daten angegeben. Dementsprechend werden TDB hinsichtlich der Unterstützung von Transaktionszeit, Gültigkeitszeit bzw. beide Zeitarten (bi-temporale) unterschieden. Bi-temporale Systeme bieten optional die automatische Protokollierung von mit einzelnen Datenobjekten assoziierten Zeiten. Zu dem kann der Nutzer nach belieben Relationen durch die Angabe einer Gültigkeitszeit ergänzen. Konzepte temporaler DB

Agenda Motivation Temporale Datenbanken Begriffsdefinition Merkmale der Zeitdimension Temporale Datenmodelle Das Datenmodell BCDM TSQL2 & SQL/Temporal Datentypen für Zeitangaben Ansätze temporaler Datenbanken Temporale Daten im Data Warehouse Zusammenfassung Zur näheren Betrachtung von TDB werden zunächst im folgenden Abschnitt der Begriff der Zeit und seine merkmale näher beleuchtet. Konzepte temporaler DB

„Zeit ist eine kontinuierliche Veränderliche,
Definition der Zeit „Zeit ist eine kontinuierliche Veränderliche, auf die die Veränderung von Zuständen oder eine Ereignisfolge bezogen werden kann...“ „Zeit ist eine Existenzform der Materie in der alle ihre Änderungen und Bewegungen ablaufen“ Im Mittelpunkt TDB steht der Begriff Zeit. Hier wird unter Zeit „…eine kontinuierliche Veränderliche, auf die die Veränderung von Zuständen oder eine Ereignisfolge bezogen werden kann…“ verstanden. „Zeit ist eine Existenzform der Materie in der alle ihre Änderungen und Bewegungen ablaufen“ Konzepte temporaler DB

Modelle der Zeit Stetiges Modell der Zeit isomorph zur Menge R dichtes Modell der Zeit isomorph zur Menge Q diskretes Modell der Zeit isomorph zur Menge Z Im Allgemeinen werden folgende drei Modelle der Zeit unterschieden: Das stetige Modell bzw. dichte Modell betrachtet die Zeit als isomorph zur Menge der reellen Zahlen bzw. zur Menge der rationalen Zahlen Q. TDB hingegen beschränken sich meist aus Praktikabilität auf ein diskretes Modell der Zeit, wobei die Zeit wiederum als isomorph zur Menge der natürlichen bzw. ganzen Zahlen betrachtet wird. Konzepte temporaler DB

Modelle der Zeit Funktionale Zusammenhänge bilden überabzählbar unendlich viele Tupel (t,y) Nicht Aufgabe temporaler Datenbanken Betrachtet man bspw. eine Funktion f(t) mit t R, welche zu jedem Zeitpunkt den zugehörigen Wert liefert, so repräsentiert dieser funktionale Zusammenhang unendlich überabzählbar viele Tupel (t, y) , welche z.B. über die endliche Repräsentation durch Constraints innerhalb einer Relation gespeichert werden können. Konzepte temporaler DB

Zielsetzung von temporalen Datenbanken
Aufzeichnung eine endliche Menge von charakteristischen Aussagen als nicht-temporale Attribute zugehörigen (unendlichen, überabzählbaren) Zeitpunkten t als temporale Attribute als Relation Die Zielsetzung ist die Aufzeichnung einer endlichen Menge von charakteristischen Aussagen A(i) und den dazugehörigen Zeitpunkten t(i) als Relation R={( t(i) ), ( A(i) ) }. Die Bestandteile einer Relation mit Zeitbezug werden als temporale Attribute, und die ohne Zeitbezug als nicht-temporale Attribute bezeichnet. Konzepte temporaler DB

Granularität Eine Granularität wird bestimmt durch eine Länge
und einen Ausgangspunkt. Die Länge wie auch der Ausgangspunkt werden in Chronons der zugrunde liegenden Uhr angegeben. Eine Granularität wird bestimmt durch eine Länge und einen Ausgangspunkt. Die Länge wie auch der Ausgangspunkt werden in Chronons der zugrunde liegenden Uhr angegeben. Denkt man sich die durch eine Uhr messbare Zeit als Gerade, kann diese Gerade mit Hilfe von Granularitäten in verschiedene Abschnitte unterteilt werden. Die Unterteilung beginnt am Ausgangspunkt und wird von dort aus in beide Richtungen fortgesetzt. Die Größe der Abschnitte richtet sich nach der benutzten Granularität. Eine wichtige Funktion in temporalen Datenbanken ist der Vergleich verschiedener Zeitpunkte oder Zeitintervalle. Sind diese in verschiedenen Granularitäten angegeben, bieten sich verschiedene zusammengestellte Lösungsmöglichkeiten an. Konzepte temporaler DB

Merkmale der Zeitdimension
Datentypen temporaler Attribute: Zeitpunkte􀂄 Zeitintervalle􀂄 Zeitfolgen􀂄 Zeitdauer Temporale Attribute einzelner Aussagen bestehen entweder aus einzelnen Zeitpunkten, Zeitintervallen, Zeitfolgen, oder Zeitdauer. Konzepte temporaler DB

Zeitpunkt: bezieht sich auf einen Zustand, dessen zeitliche Ausdehnung: Vernachlässigbar kleiner als die zugrunde liegende Granularität Zeitpunkte beschreiben einen Zustand, dessen zeitliche Ausdehnung vernachlässigt werden kann bzw. kleiner ist als die zugrunde liegende Granularität bei einem diskreten Modell der Zeit. Beispiel für einen Zeitpunkt ist das Belegdatum einer Rechnung oder der Zeitpunkt der Bestätigung einer Transaktion. Bei der Betrachtung mehrer Zeitpunkte interessiert ihre zeitliche Abfolge. Konzepte temporaler DB

Zeitintervall: Ein Kontinuum von Zeitpunkten: Beschreibung durch die Eckpunkte: Den Abstand zweier Zeitpunkte beschreibt ein Zeitintervall, welches als eine zusammenhängende Teilmenge I ⊆TU des Zeituniversum TU definiert ist. Ein Zeitintervall besteht also aus einer beliebigen Menge von benachbarten Zeitpunkten Ein Zeitintervall I wird durch seine Eckpunkte beschrieben Zeitintervalle können geschlossene, halboffene, offene und unendliche Intervalle sein. Konzepte temporaler DB

Zeitfolgen: bestehen entweder aus einzelnen: Zeitpunkten􀂄 Zeitintervallen Unterscheidung von: linearen Zeitfolgen „jeden Dienstag wird der Müll abgeholt“ nicht-linearen Zeitfolgen „jeden 1. Freitag im Monat“ Zeitfolgen wiederum bestehen aus einzelnen Zeitpunkten und / oder Zeitintervallen. Dabei lassen sich Zeitfolgen in lineare und nicht lineare Folgen unterscheiden. Lineare Zeitfolgen haben einen konstanten Abstand zwischen einzelnen Zeitpunkten bzw. -intervallen, wie bspw. die Aussage „jeden Dienstag wird der Müll abgeholt“ eine Zeitspanne von 7 Tage zwischen den einzelnen Ereignissen hat. Hingegen kann die Aussage „jeden 1. Freitag in Monat“ nicht durch eine lineare Zeitfolge beschrieben werden, da die Abstände zwischen den einzelnen Zeitpunkten nicht homogen sind. Konzepte temporaler DB

Zeitdauer: beschreibt in absoluter Größe die Anzahl der Zeitpunkte für ein bestimmtes Kontinuum bzw. Intervall immer in Bezug auf eine Granularität Eine weitere Betrachtungsgröße der Zeitdimension im diskreten Modell der Zeit ist die Zeitdauer. Sie beschreibt in absoluter Größe die Anzahl der Zeitpunkte, die innerhalb eines Intervalls bzw. zwischen zwei Zeitpunkten liegen. Die Zeitdauer d(t) ist immer in Abhängigkeit der zugrunde liegenden Granularität zu betrachten. Bspw. kann d(t)=7 eine Zeitdauer von 7 Jahren oder 7 Sekunden beschreiben, je nach gewählter Granularität. Zusammenfassend lassen sich die vier Datentypen Zeitpunkt, Zeitintervall, lineare Zeitfolge und Zeitdauer für temporale Datenbanken identifizieren. Konzepte temporaler DB

Ein Beispiel Obiges Beispiel enthält eine zustandsstabile Zeitfolge, das Zeitgranulat für das Gehalt ist der Monat. Wir haben zur besseren Lesbarkeit hier Tag gewählt. In einer Tabelle werden die Gehälter von Beschäftigten geführt. Dazu wird eine Beispielrelation PERSONAL betrachtet. Ein Mitarbeiter namens Meier wird mit einem Gehalt von 3000 am eingetragen. Am gleichen Jahres wird Meier mit einem Gehalt von 3500 hinzugefügt. Am wird ergänzt, dass Meier bereits seit Mai 1993 ein Gehalt von 2800 bekam. Am des Jahres wird schließlich das aktuelle Gehalt von Meier auf 3600 rückwirkend korrigiert. Konzepte temporaler DB

Ein Beispiel Abb. 3 beinhaltet sämtliche Zeitfolgen, in der letzten Zeile steht die aktuelle Zeitfolge. Konzepte temporaler DB

Agenda Motivation Temporale Datenbanken Begriffsdefinition Merkmale der Zeitdimension Temporale Datenmodelle Das Datenmodell BCDM TSQL2 & SQL/Temporal Datentypen für Zeitangaben Ansätze temporaler Datenbanken Temporale Daten im Data Warehouse Zusammenfassung Konzepte temporaler DB

Temporale Datenmodelle
Temporale Datenmodelle basieren auf dem relationalen Datenmodell. Wichtigste Konzepte: Erweiterung der Tabellen um temporale Attribute Erweiterung der Anfragesprache um temporale Operationen Das Temporale Datenmodell TDM von A Segev und A Shoshani. Temporale Datenmodelle unterscheiden sich weiterhin in den unterstützten Zeitdimensionen und in der Art der Repräsentation temporaler Daten. Die Zeitstempel sind entweder: Explizit, d.h. von außen sichtbar Implizit mit den Aussagen verbunden Temporale Datenmodelle basieren auf dem relationalen Datenmodell dessen wichtigste Konzepte z.B.: Erweiterung der Tabellen um temporale Attribute Erweiterung der Anfragesprache um temporale Operationen Es existieren aber auch vollständig neu entwickelte temporale Datenmodelle wie das Temporale Datenmodell TDM von A Segev und A Shoshani. Dieses basiert auf Zeitsequenzen, die die Geschichte von Objekten repräsentieren und zusätzlich bestimmte temporale Eigenschaften wie Granularität oder Definitionsbereich der Gültigkeitszeit, besitzen. Temporale Datenmodelle unterscheiden sich weiterhin in den unterstützten Zeitdimensionen und in der Art der Repräsentation temporaler Daten. Aussagen werden mit Hilfe von Zeitstempeln zeitlich eingeordnet. Die Zeitstempel sind entweder explizit d.h. von außen sichtbar oder implizit mit den Aussagen verbunden. Konzepte temporaler DB

Das Datenmodell BCDM Ein Datenmodell ist ein formaler Rahmen zur Beschreibung von Datenstrukturen und Operationen auf Daten. Es wird angenommen, dass die abzuspeichernde Information mit Hilfe von Objekten und Beziehungen zwischen Objekten modelliert werden kann. Das Datenmodell BCDM ist Teil und Grundlage des Sprachvorschlages TSQL2. Das BCDM ist ein erweitertes relationales Datenmodell Das Datenmodell BCDM (bitemporal conceptual data model) ist Teil und Grundlage des Sprachvorschlages TSQL2. Als konzeptionelles Datenmodell soll es die Semantik temporaler Daten möglichst einfach und deutlich darstellen können. Das BCDM ist ein erweitertes relationales Datenmodell, d.h. die Konzepte des relationalen Modells werden übernommen und erweitert. Konzepte temporaler DB

Das Datenmodell BCDM Bsp.: Abb.4: Temporale Relation mit Tupelstempelverfahren: a) in erster Normalform b) Gemäß BCDM (nicht in erster Normalform) In einer Gültigkeits- bzw. Transaktionszeitrelation existieren keine zwei Tupel, deren Werte für die Attribute (Name, Lohn) übereinstimmen. Wiederholt sich ein Zustand bzw. Ereignis wird kein neues Tupel erzeugt sondern der Zeitstempel des bereits vorhandenen Tupels entsprechend erweitert. Der Primarschlüssel muss nicht um die Gültigkeits- bzw. Aufzeichnungszeit erweitert werden. Zum Vergleich zeigt Abb.4.a) eine Gültigkeitszeitzustandstabelle in erster Normal form ist. Die Gültigkeitszeitintervalle werden in den Attributen Vs und Ve durch ihre Anfangs- und Endpunkte beschrieben. Weil diese Attribute atomar sind, beinhaltet ein Tupel stets nur ein Zeitintervall. Wiederholt sich ein Zustand bzw. ein Ereignis in der jeweiligen Zeitdimension, muss ein neues Tupel eingefügt werden. Im gezeigten Beispiel ist das bei dem Gehalt von 1500 Mark der Fall. Konzepte temporaler DB

TSQL2 & SQL/Temporal: geschichtlich
Seit Mitte der 80er Jahre wurde eine Vielzahl von Sprachvorschlägen vorgestellt, z.B.: IXSQL, TSQL2, SQL/TP Zwei Vorschläge sind bis heute noch wichtig: TSQL2: als SQL-Spracherweiterung. SQL/Temporal: als siebter Teil von SQL3. SQL-86 und SQL-89 beinhalteten noch keine Möglichkeit temporale Daten zu verwalten. Mit SQL-92 (SQL2) wurden die Datentypen DATETIME und INTERVAL eingeführt.  erste Schritt in Richtung Zeitunterstützung Im Juni 1993 formte sich nach einem “Workshop on an Infrastructure for Temporal Databases” in Arlinton, Texas ein TSQL2 Komitee mit dem Ziel, eine Sprachspezifikation einer temporalen Anfragesprache zu verfassen. Im Januar 1993 wurde eine erste Version veröffentlicht und die endgültige Version folgte im September 1994. Konzepte temporaler DB

TSQL2 & SQL/Temporal TSQL2: - In dieser Sprache ist ein Zeitstempelattribut hinzugefügt, das Mengen von bitemporalen Chronons enthält, und zwar die Zeitpunkte, wann ein Fakt gültig war und wann er eingetragen wurde. - TSQL2 unterstützt die Evolution der relevanten Objekte und damit der ihnen zugeordneten Daten im Zeitablauf. SQL/Temporal: - SQL/Temporal orientiert sich an den Forschungspapieren von TSQL2. - Die Konzepte von TSQL2 wurden jedoch nicht vollständig übernommen. - Danach entstand die Diskussion, die Unterstützung von Gültigkeitszeit (valid time) und Transaktionszeit (transaction time) in SQL/Temporal zu integrieren. Konzepte temporaler DB

Agenda Motivation Temporale Datenbanken Begriffsdefinition Merkmale der Zeitdimension Temporale Datenmodelle TSQL2 & SQL/Temporal Datentypen für Zeitangaben Ansätze temporaler Datenbanken Temporale Daten im Data Warehouse Zusammenfassung Konzepte temporaler DB

Datentypen für Zeitangaben
In SQL2 werden bereits einige zeitorientierte Datentypen angeboten: DATE TIME TIMESTAMP als Kombination der beiden erstgenannten INTERVAL ist für die Zeitdauer (nicht zu Verwechseln mit Zeitintervallen, die durch zwei Zeitpunkte begrenzt sind !) PERIOD für den Zeitintervall-Datentyp. PERIOD  [datetime1-datetime2]  PERIOD(datetime1, datetime2) INTERVAL(PERIOD) : Unwandlung einer Periodenangabe in eine Zeitdauer. In konventionellen Datenbanksysteme gibt es beschränkte Möglichkeiten, Zeitprobleme in die vorhandenen Modelle und Datenbanksprachen zu integrieren. In SQL2 werden bereits einige zeitorientierte Datentypen angeboten. Dazu gehören DATE, TIME, TIMESTAMP als Kombination der beiden erstgenannten. Die Zeitdauer in SQL2 ist mit dem Datentyp INTERVAL festgelegt (nicht zu Verwechseln mit Zeitintervallen, die durch zwei Zeitpunkte begrenzt sind !). Handelt es sich nur um die Abspeicherung aktueller Zeitfolgen, können konventionelle Datenbanksysteme eventuell ausreichend sein. Bestimmte SQL-Anfragen können allerdings komplex werden. Neben der Zeitdauer (INTERVAL, nach SQL2) existiert PERIOD zur Abbildung von zeitlich verankerte Intervalle. Eine Periode läßt sich als Konstante ‘[datetime1-datetime2]’ angeben, jedoch auch durch die Funktion PERIOD(datetime1, datetime2) aus atomaren Zeitangaben konstruieren; im letzteren Fall kann ‘datetime’ auch eine zu bestimmende Variable sein. Mit INTERVAL(period) läßt sich eine Periodenangabe in eine Zeitdauer umwandeln. Konzepte temporaler DB

INTERSECT(PERIOD_1, PERIOD_2) : Ermittlung der Schnittmenge zweier Perioden BEGIN(PERIOD) für den Anfangszeitpunkt einer Periode END(PERIOD) für den Endzeitpunkt einer Periode ALTER TABLE : Zeitdimensionen nachträglich einzufügen, oder zu entfernen. Spezielle Werte zur Definition Periodenbegrenzung - ‘beginning’ steht für unendlich weit zurückliegende Vergangenheit. - ‘forever’ steht für unendlich weit entfernte Zukunft. - ‘now’ steht für die aktuelle Zeit. - PERIOD‘[beginning,- forever]’ stellt den maximal in einem System abbildbaren Zeitraum dar. Ein weiterer wichtiger Konstruktor ist INTERSECT(period1, period2), der als Ergebnis die Schnittmenge zweier Perioden ermittelt. Mit BEGIN(period) wird der Anfangszeitpunkt, mit END(period) der Endzeitpunkt einer Periode bestimmt. Mit ALTER TABLE ist es möglich, die erforderlich Zeitdimensionen auch nachträglich einzufügen, oder zu entfernen. Konzepte temporaler DB

[CAST | SCALE ] (<operand> AS <granularity>) Zeitangaben werden durch die beiden Operatoren CAST und SCALE in andere Granularitäten umgewandelt. CAST liefert immer ein konkretes Ergebnis. SCALE liefert unbestimmte Ausdrücke, wenn eine Umwandlung in ein feineres Granulat vorgenommen werden soll. Bsp.: (CAST & SCALE) CAST(PERIOD ’[ ]’ AS DAY) → [ ] SCALE(PERIOD ’[ ]’ AS DAY) → [ ∼ ∼ ] Zeitangaben werden durch die beiden Operatoren CAST und SCALE in andere Granularitäten umgewandelt. CAST liefert immer ein konkretes Ergebnis, SCALE liefert unbestimmte Ausdrücke, wenn eine Umwandlung in ein feineres Granulat vorgenommen werden soll. Konzepte temporaler DB

Vergleichs-Operatoren Gleichheits-Operator : (=) PRECEDES : die Vorzeitigkeit einer Periode gegenüber einer anderen Periode ausdrücken. Bsp.: X PRECEDES Y, dann ist END(X)< BEGIN(Y); MEETS ist ein Spezialfall von PRECEDES, bei dem END(X) und BEGIN(Y) genau ein Chronon auseinander liegen. OVERLAPS : da wird ermittelt, ob die Schnittmenge zweier Perioden nicht leer ist. CONTAINS ist wiederum ein Spezialfall, bei dem eine Periode vollständig in einer anderen Periode enthalten sein muss. Ein Chronon ist eine Zeitangabe, die den kleinsten in einem gegebenen Kontext betrachteten Zeitraum repräsentiert und nicht weiter zerlegt werden kann. Konzepte temporaler DB

Agenda Motivation Temporale Datenbanken Begriffsdefinition Merkmale der Zeitdimension Temporale Datenmodelle TSQL2 & SQL/Temporal Datentypen für Zeitangaben Ansätze temporaler Datenbanken Temporale Daten im Data Warehouse Zusammenfassung Konzepte temporaler DB

Ansätze temporaler Datenbanken
Datendefinition (CREATE) Datenmodifikation (INSERT, UPDATE, DELETE) Datenabfragen (SELECT) Konzepte temporaler DB

Datendefinition (CREATE)
Der zugehörige TSQL-Befehl ist CREATE TABLE <table> ( ...) [AS [ VALID [STATE | EVENT] [AND]] TRANSACTION] Abb.4 Syntaxdiagramm für das Anlegen einer Relation Konzepte temporaler DB

Datendefinition (CREATE)
Beim Kreieren der Tabellen werden mit STATE und EVENT zustandsstabile bzw. ereignisorientierte Zeitfolgen definiert. Es ist ein Zeitstempelattribut hinzugefügt, das Mengen von bitemporalen Chronons enthält, und zwar die Zeitpunkte, wann ein Fakt gültig war und wann er eingetragen wurde. Bsp.: CREATE TABLE personal ( name CHAR(20), gehalt FLOAT ) AS VALID STATE AND TRANSACTION Für die Gültigkeitszeit kann zudem in der Datendefinition eine gewünschte Granularität angegeben werden, für die Transaktionszeit ist die Granularität systemabhängig und nicht vom Benutzer zu beeinflussen. Konzepte temporaler DB

Datenmodifikation (INSERT, UPDATE, DELETE)
temporalen Datenmodifikationen unterscheiden sich vom herkömmlichen SQL durch die optionale VALID-Klausel. Ohne Eingabe der Gültigkeitszeit-Bereiche, so gilt VALID PERIOD ‘[now-forever]’ Datenmodifikationsoperationen (Insert,Update,Delete) haben automatisch einen Zeitbezug, wenn sie auf temporale Tabellen angewandt werden. Die temporalen Datenmodifikationen unterscheiden sich vom herkömmlichen SQL durch die optionale VALID-Klausel für die von der Modifikation betroffenen Gültigkeitszeit-Bereiche. Ohne Eingabe der Gültigkeitszeit-Bereiche, so gilt VALID PERIOD ‘[now-forever]’ , d.h. von der augenblicklichen Zeit bis zur größtmöglichen Zeitangabe. Konzepte temporaler DB

Datenmodifikation (INSERT)
Der zugehörige TSQL-Befehl für die Insert-Operation ist: INSERT INTO <tabellen_name> VALUES (...) VALID PERIOD ’[ ]’ Die Abb.5 zeigt das Syntaxdiagramm einer INSERT-Operation, durch die ein neues Tupel mit der durch die VALID-Klausel festgelegten Gültigkeitszeit in die Datenbank eingefügt wird. Eine Besonderheit betrifft die Eingabe eines Tupels, das bezüglich der expliziten Attribute wertegleich zu einem schon vorhandenen Tupel ist. In diesem Fall werden beide Tupel verschmolzen (coalescing), was zu einer Vereinigung ihrer Gültigkeitszeiten führt. Abb Syntaxdiagramm für die INSERT-Operation Konzepte temporaler DB

Bsp.: Der deutsche Staatsbürger ‘Meier’ reist 1994 in die Schweiz ein und bekommt den Status eines Jahresaufenthalters, er erhält damit eine Aufenthaltsgenehmigung von jeweils nur einem Jahr. Die Gültigkeit des entsprechenden Tupels ist dementsprechend anzugeben als (1) INSERT INTO person VALUES (‘Meier’,‘D’,‘Bern’) VALID PERIOD ‘[ ]’ (2) übersichtlichere Darstellung INSERT INTO person VALUES (‘Meier’,‘D’,‘Bern’) VALID PERIOD CAST(PERIOD ‘[ ]’AS DAY) Aus Gründen der übersichtlichen Darstellbarkeit wird hier und im folgenden die unrealistisch grobe Granularität „Jahr“ angenommen. Eine Periode ‘[ ]’umfaßt das ganzes Jahr; die Operation CAST(PERIOD ‘[ ]’AS DAY) würde also auf ‘[ ]’ führen. Erfolgt die Eingabe im selben Jahr wie die Gültigkeitszeit, so ergibt sich für die bitemporale Relation eine Situation wie in Tabelle 1a: Während die Gültigkeitszeit vollständig bestimmt ist, wird für das Ende der Transaktionszeit ein unbestimmter Wert angenommen; dieser symbolisiert, daß das durch das Tupel abgebildete Faktum bis auf weiteres als korrekt angesehen wird. ‘[ ]’ Konzepte temporaler DB

Die Aufenthaltsgenehmigung wird um ein weiteres Jahr verlängert: INSERT INTO person SELECT (name,nation,ort) VALID PERIOD ‘[ ]’ FROM person WHERE name=‘Meier’ AND VALID(person) OVERLAPS TIMESTAMP ‘1994’ In der betroffenen Relation sind nach der zweiten Einfügung nicht etwa zwei aktuelle Tupel (‘Meier’,‘D’,‘Bern’) mit den jeweiligen Gültigkeitszeiten enthalten, sondern das schon vorhandene Tupel wird durch die Schließung der Transaktionszeit als fehlerhaft markiert und ein neues Tupel mit einer Gültigkeit von ‘[ ]’ eingefügt (Tabelle 1b). Konzepte temporaler DB

Datenmodifikation (UPDATE)
Der zugehörige TSQL-Befehl für die Update-Operation ist: UPDATE <tabellen_name> VALID PERIOD ’[ ]’ SET ... = ... WHERE ... = ... Die im Syntaxdiagramm in Abb. 6 beschriebene UPDATE-Operation bewirkt eine Modifikation der expliziten Attribute bereits vorhandener Tupel im Rahmen ihrer Gültigkeitszeiten. Die spezifizierte VALID-Klausel gibt den Gültigkeitszeitbereich an, für den die Änderung durchgeführt werden soll. Eine effektive Änderung wird jedoch nur für die Schnittmenge aus den Gültigkeitszeiten der selektierten Tupel und des angegebenen Bereichs vorgenommen. Beim Fortschreiben einer Wertevolution wirkt sich eine Änderung üblicherweise nicht auf die gesamte Gültigkeit eines Tupels aus, sondern nur auf Teilbereiche davon. Abb Syntaxdiagramm für die UPDATE-Operation Konzepte temporaler DB

Datenmodifikation (UPDATE)
Bsp.: Die Person ‘Meier’ hat Ende 1995 die Schweizer Staatsbürgerschaft angenommen, was 1996 durch folgende UPDATE-Operation abgebildet werden soll: UPDATE person VALID PERIOD ‘[1995-forever]’ SET nation=‘CH’WHERE name=‘Meier’ Diese Operation bewirkt, daß nach dem Update der neue Wert nur für das Jahr 1995 gültig ist. Diese Operation bewirkt, daß nach dem Update der neue Wert nur für das Jahr 1995 gültig ist (Tabelle 1c). Obwohl die Schweizer Staatsbürgerschaft auch in Zukunft Gültigkeit hat und damit auch der Aufenthalt prinzipiell unbeschränkt ist, wird dies in der Datenbank nicht festgehalten, da der Gültigkeitszeitbereich des vorher aktuellen Tupels für ‘Meier’ 1995 endete. Um den eingetretenen Sachverhalt auch in seiner zeitlichen Implikation korrekt abzubilden, ist hier also ein Update nicht geeignet. Stattdessen sollte zuerst der nicht mehr gültige Sachverhalt (‘Meier’,‘D’,‘Bern’) für den Zeitraum ab 1995 entfernt werden. Dies ist mit der im Syntaxdiagramm in Abb. 7 veranschaulichten DELETE-Operation möglich. Konzepte temporaler DB

Datenmodifikation (DELETE)
Der zugehörige TSQL-Befehl für die Delete-Operation ist: DELETE FROM <tabellen_name> WHERE ... = ... VALID PERIOD ’[ ]’ Wie das Update wirkt sich die Lösch-Operation nur auf die überlappten Gültigkeitszeiträume der selektierten Tupel aus, die aus dem Zeitstempel eines betroffenen Tupels entfernt werden. Abb Syntaxdiagramm für die DELETE-Operation Konzepte temporaler DB

Datenmodifikation (DELETE)
Bsp.: DELETE FROM person WHERE name=‘Meier’ VALID PERIOD ‘[1995-forever]’ Einfügen des gültigen Faktums: INSERT INTO person VALUES (‘Meier’,‘CH’,‘Bern’) Bsp.: Die Person ‘Meier’ erhält 1994 eine Niederlassungsbewilligung. Die Gültigkeitsdauer ihres Aufenthalts ist damit prinzipiell nicht beschränkt: INSERT INTO person VALUES (‘Meier’,‘D’,‘Bern’) VALID PERIOD ‘[1994-forever]’ Dabei ist anzumerken, dass diese Einfügung auch ohne die vorherige Löschung erfolgen könnte. Dies hätte allerdings eine unsinnige Aussage zur Folge, da ‘Meier’ – zumindest im Beispiel – nicht gleichzeitig die deutsche und die schweizerische Staatsbürgerschaft besitzen kann. Die angeführten Schwierigkeiten mit der Update-Operation treten nicht auf, wenn bei Einfügungen unbeschränkte Gültigkeitszeitenden verwendet werden. Dabei wird die (vorläufige) zeitliche Unbeschränktheit des Faktums durch das „forever“ ausgedrückt. Nimmt nun die Person „Meier“ die Schweizer Staatsbürgerschaft an, so führt die Update-Operation diesmal zum erwünschten Resultat. Konzepte temporaler DB

Datenabfragen (SELECT)
Der zugehörige TSQL-Befehl für die Select-Operation ist: SELECT * FROM <tabellen_name> WHERE <Bedingung> Mit einer Standardanfrage der Form SELECT * FROM <tabellen_name> werden alle zur Anfragezeit gültigen Tupel ausgegeben. Abb Syntaxdiagramm für die SELECT-Operation Konzepte temporaler DB

Datenabfragen (SELECT)
Bsp.: Ist in der PERSONAL-Tabelle die aktuelle Gehaltszeitfolge von Meier auszugeben, lautet die Anweisung: SELECT * FROM personal WHERE name=’Meier’ Zur Eingrenzung der Gültigkeitszeit SELECT * FROM personal AS p AND VALID(p) OVERLAPS PERIOD ’[<zeit_1>-<zeit_2>]’ Zur Abschließung der angegebenen Zeitgrenzen VALID INTERSECT PERIOD ’[<zeit_1>-<zeit_2>]’ Anzeigen der nichtaktueller Zeitfolgen WHERE TRANSACTION(p) OVERLAPS TIMESTAMP ’<zeit>’ Sind Tupel hinsichtlich der Gültigkeitszeit einzugrenzen, kann das im Rahmen der WHERE-Klausel mittels Zeitintervall-Vergleichsoperatoren, vorzugsweise mit OVERLAPS erreicht werden: ... VALID(<tupel_variable>) OVERLAPS PERIOD ’[<zeit_1>-<zeit_2>]’ Sollen die im Ergebnis ausgewiesenene Zeitstempel die Periodengrenzen nicht überschreiten, so muss man dafür eine Gültigkeitszeit-Projektion benutzen: SELECT ... VALID INTERSECT ’[<zeit_1>-<zeit_2>]’ Ist der Zustand nichtaktueller Zeitfolgen anzuzeigen, kann die WHERE-Klausel wie folgt erweitert werden: ... TRANSACTION(<tupel_variable>) OVERLAPS TIMESTAMP ’<zeit>’ Konzepte temporaler DB

Agenda Motivation Temporale Datenbanken Temporale Daten im Data Warehouse Der Begriff Data Warehouse Definition Konzept Architektur Zeitbezogene Daten im Data Warehouse Zusammenfassung Konzepte temporaler DB

Data Warehouse: Definition
Ein Data Warehouse ist eine themenorientierte, integrierte, historisierte, nicht flüchtige (d.h. dauerhafte) Sammlung von Daten, um Manager bei Entscheidungsprozessen zu unterstützen. (Inmon,W.H.; Hackethorn,R.D.) Ein Data Warehouse ist eine physische Datenbank, die eine integrierte Sicht auf (beliebige) Daten darstellt, um Analysen zu ermöglichen. (Bauer,A., Günzel,H.) Ein Data Warehouse ist ein physischer Datenbestand, der eine integrierte Sicht auf die zugrundeliegenden Datenquellen ermöglicht. (Zeh,T.) Es gibt derzeit keine einheitliche Definition für den Data-Warehouse-Begriff. Da habe ich einpaar Definition nach der Sicht von manchen Autoren. Konzepte temporaler DB

Data Warehouse: Konzept
Das Data Warehouse ist ein unternehmensweites Konzept zur effizienten Bereitstellung und Verarbeitung entscheidungsorientierten Daten. Das Data Warehouse ist ein unternehmensweites Konzept zur effizienten Bereitstellung und Verarbeitung entscheidungsorientierten Daten. Diese Daten weisen im Gegensatz zu den transaktionsorientierten Daten einen hohen Aggregationsgrad auf, haben einen Zeitraumbezug und sind den Bedürfnissen der Entscheidungsträger zur Durchführung ihrer Aufgaben angepasst. Konzepte temporaler DB

Data Warehouse: Architektur
Abfrage- und Analysewerkzeuge Data Warehouse Benutzungsschnittstelle Datenbank Archivierungs- system Metadaten Basisdaten Ein Data Warehouse besteht wie in Abb.10 dargestellt, aus einer Datenschnittstelle, einer Datenbank, und einer Benutzungsschnittstelle. Die zentrale Komponente der Datenbank sind die Basisdaten. Diese umfassen die aus den transaktionsorientierten Vorsystemen importierten Daten und dienen der Versorgung eines Unternehmens mit entscheidungsorientierten Daten. Darüber hinaus sind in der Datenbank aus Metadaten enthalten, welche den in einem Data Warehouse vorhandenen Datenbestand beschreibe. Das Archivierungssystem hat die Aufgabe, die in einem Data Warehouse abgelegten Daten zu speichern und regelmäßig zu sichern. Die Datenschnittstelle dient der Versorgung eines Data Warehouse mit Daten. Dabei werden in regelmäßigen Zeitabständen oder aufgrund definierter Datenveränderungen in den Datenquellen festgelegte Mengen unternehmnesinterner und unternehmensenxterner transaktionsorientierter Daten durch eine Transformation in entscheidungsorientierte Daten überführt werden. Die Benutzungsschnittstelle ermöglicht einen direkten Zugriff der Abrage- und Analysewerkzeuge auf den im Data Warehouse vorhandenen Datenbestand. Datenschnittstellen Unternehmensinterne und –externe Transaktionsorientierte Daten Konzepte temporaler DB

Agenda Motivation Temporale Datenbanken Temporale Daten im Data Warehouse Der Begriff Data Warehouse Zeitbezogene Daten im Data Warehouse Entity- Relationship-Modelle Zeitbezogene Entity-Relationship-Modelle Entity- Relationship-Modelle im Data Warehouse Zeitbezogene Entity-Relationship-Modelle im Data Warehouse Zusammenfassung Konzepte temporaler DB

Entity- Relationship-Modelle
Das Entity-Relationship-Modell, kurz ER-Modell oder ERM, dient dazu, im Rahmen der Datenmodellierung die reale Welt semantisch präzise zu beschreiben, um sie in Tabellen und Beziehungen innerhalb einer Datenbank abbilden zu können. Das ER-Modell besteht aus drei charakteristischen Komponenten: Gegenstand (Entity): Bezeichnung für die Objekte der realen Welt, sprich Entitäten (z. B. Angestellter, Artikel, Rechnungsdatum). Beziehung (Relationship): Bezeichnung für die Beziehungen von verschiedenen Gegenständen zueinander (z. B. kaufen, arbeiten, bezahlen). Attributen: Nähere Beschreibung der Entitäten und die Beziehungen. Konzepte temporaler DB

Symbole des ER-Diagramms Attribut Entitätsmenge Schlüsselattribut Scwache Entitätsmenge Abgeleitetes Attribut Beziehungsmenge Die graphische Darstellung des Entity- Relationship-Modelles ist das Entity- Relationship-Diagramm. Schwache Beziehungsmenge Konzepte temporaler DB

Bsp.: Wohnort Geburtsdatum Srtaße Alter m n Mitarbeiter Bearbeitung Projekte Hiezu werden Mitarbeiter betrachtet, die ein Projekt bearbeiten. Ein Mitarbeiter kann mehrere Projekte bearbeiten und ein Projekt kann von mehreren Mitarbeitern bearbeitet werden. Die Entitätsmenge Mitarbeiter kann z.B. durch die Attribute Name, Vorname, Straße, Wohnort, Telefonnummer, und Geburtsdatum beschrieben werden. Das Alter des Mitarbeiters kann dann aus aktuellen Datum und Geburtsdatum ermittelt werden, was durch ein Abgeleitetes Attribut dargestellt wird. Weiterhin wird eine eindeutige Personalnummer (P#) eingeführt, die als Schlüsselattribut dient. Die Entitätsmenge Projekte kann beispielsweise durch den Projektnamen und die Projektnummer (Projekt#), die als Schlüssel dient, beschrieben werden. P# Telefonnummer Projekt# Projektname Name Vorname Konzepte temporaler DB

Zeitbezogene Entity-Relationship-Modelle
(0,*) (1,*) Bearbeitung Projekte Mitarbeiter Projekt# P# Name Geburtsdatum Besitz Mitarbeiter Version# Name P# Geburtsdatum (1,*) (1,1) Mitarbeiter- versionen Hierzu werden aus Gründen der Übersichtlichkeit für die Entitätsmenge Mitarbeiter nur das Schlüsselattribut Personalnummer (P#), das zeitabhängige Attribut Name und das zeitunabhängige Attribut Geburtsdatum sowie für die Entitätsmenge Projekte lediglich das Schlüsselattribut Projektnummer (Projekt#) betrachtet. (Abb.12) Im ER-Modell wird zunächst ein Zeitbezug für die Bewegungsdaten modelliert. Zur expliziten Modellierung der Entwicklung der Entitäten werden die zeitunabhängigen Attribute einer „Grund-Entitätsmenge“ zugeordnet, die über eine Beziehungsmenge mit einer schwachen Entitätsmenge verbunden ist, welche die zeitabhängigen Attribute enthält. Hierbei unterscheiden sich die einzelnen Versionen durch einen zeitunabhängigen Schlüssel. Wie z.B. der Versionsnummer (Version#). (Abb.13) Die Zeitabhängigkeit der Entitätsmenge lässt sich auch durch eine zusätzliche Entitätsmenge Zeit modellieren. Dann werden die Mitarbeiterversionen als Beziehungsmenge dargestellt. Die einzelnen Versionen unterscheiden sich durch die Zeitattribute voneinander. (Abb.14) Mitarbeiter- versionen Mitarbeiter Datum Name P# Geburtsdatum (1,*) (0,*) Zeit Konzepte temporaler DB

Zeitbezogene Entity-Relationship-Modelle
Geburtsdatum (0,*) (1,*) Mitarbeiter Bearbeitung Projekte (1,*) (0,*) Projekt# Eine Möglichkeit der Versionierung der Beziehungsmenge besteht darin, eine schwache Beziehungsmenge, analog zur schwachen Entitätsmenge aus Abb.13, zu verwenden. In diesem Falle muss die Beziehungsmenge um eine weitere Entitätsmenge erweitert werden, welche die Versionsidentifikation erlaubt. Dafür muss eine Entitätsmenge Zeit verwendet werden. Somit liegt es nahe, die Versionierung der Entitätsmenge durch eine zusätzliche Entitätsmenge Zeit zu modellieren. Die Entitätsmenge Zeit kann auch zur Versionierung der Beziehungsmenge verwendet werden. (Abb.15) (0,*) Mitarbeiter- versionen Zeit Name Datum Konzepte temporaler DB

Entity-Relationship-Modelle im Data Warehouse
Das Extended-Entity-Relationship-Modell (EER-Modell) stellt eine Erweiterung des Entity- Relationship-Modells dar. Die zentrale Erweiterung des Entity-Relationship-Modells ist in einer Klassifikation, d.h. einer Gruppierung von Entitätsmengen in neuen Mengen zu sehen. Hierbei wird zwischen Untermengen und Obermengen unterschieden. Die Obermenge und die Untermenge stehen zueinander in Beziehung, in sofern, dass jede Entität der Untermenge zugleich auch Element der Obermenge ist. Die Eignung des Entity-Relationship-Modells zur Modellierung von multidimensionalen Daten wird zur Zeit intensiv diskutiert. Die Datenstruktur eines Data Warehouse unterscheidet sich nicht grundlegend von der Datenstruktur eines operativen Systems, das in der Mehrzahl der Fälle auf einer relationalen Datenbank aufbaut. Aus diesem Grund erfolgt zunächst die Modellierung multidimensionaler Konstrukte mit dem Extended-Entity-Relationship-Modell. Zur Darstellung multidimensionale Strukturen im EER-Modell wird zunächst dieses Modell erläutert. Beispielhaft kann der Fall auftreten, dass einer Entitätsmenge in mehreren Untermengen aufgeteilt werden kann. So kann die Entitätsmenge Mitarbeiter in die Entitätsmengen Abteilungsleiter und Sekretärin aufgeteilt werden. Diese beiden Entitätsmengen sind dann die Untermengen, die Entitätsmenge Mitarbeiter ist die Obermenge. Konzepte temporaler DB

Entity-Relationship-Modelle im Data Warehouse
Produktklasse Produktion Produktionsmenge Jahr Verdichtung Quartal Monat Gesellschaft Teilgesellschaft Betrieb Produkthauptgruppe Produktuntermenge Produkt Vertriebsgebiet (1,*) (1,1) Vertriebsstruktur Produktstruktur In Abb.17 ist das EER-Diagramm mit den zugehörigen Klassifikationshierarchien dargestellt. Die Verdichtung zwischen zwei Entitätsmengen erfolgt durch eine Beziehungsmenge. Parallele Hierarchien werden durch die Spezialisierung dargestellt. Hierdurch bedingt muss eine Obermenge eingeführt werden, die zu der parallelen Hierarchie spezialisiert werden kann. Um sicherzustellen, dass jedes untergeordnete Element genau einem übergeordneten Element zugeordnet ist, wird eine Hierarchie durch Beziehungen mit den Kardialitäten (1:1) und (1:*) verbunden. Problematisch bei dieser Darstellung jedoch, dass es sehr schnell bei größeren Modellen zu Inkonsistenzen kommen kann. Konzepte temporaler DB

Zeitbezogene Entity-Relationship-Modelle im Data Warehouse
Entity-Relationship-Modelle kann zur Modellierung zeitbezogener Daten im Data Warehouse eingesetzt werden. Aus diesem Grund werden die in letzten Abschnitt vorgestellten Entity-Relationship-Modelle zur Modellierung eines Data Warehouse um eine geeignete Art der Zeitunterstützung erweitert. Im Folgenden wird das Extended-Entity-Relationship-Modell um eine Methode zur Zeitstempelung erweitert. Ausgehend von Abb.17 wird eine zusätzliche Entitätsmenge Gültigkeitszeit eingeführt, die zwei Schlüsselattribute, den Anfangszeitpunkt (tGZA) und den Endzeitpunkt (tGZE) des Gültigkeitszeitintervalls, enthält. Die Gültigkeitszeit besitzt die Granularität der Dimension ZEIT. Daher besteht eine Ist-Beziehung zwischen der Entitätsmenge Monat und der Entitätsmenge Gültigkeitszeit. Für die Fakten wird die Gültigkeitszeit aufbaubedingt durch das Data Warehouse unterstützt. Wird jedoch ein zeitbezogener Metadatenraum (ZMDR) verwendet, um die Ursachen der fehlenden Fakten bestimmt zu können, so müssen alle nicht zur Zeitdimension gehörenden Dimensionselemente aller Dimensionen mit einem Zeitstempel versehen werden. Daher wird in Abb.18 eine Beziehungsmenge ZMDR eingeführt, die eine Beziehung zwischen der Entitätsmenge Gültigkeitszeit und sowohl der Entitätsmenge Produkt als auch der Entitätsmenge Betrieb hergestellt. Wird zusätzlich zur Gültigkeitszeit die Transaktionszeit zur Zeitstempelung im Data Warehouse berücksichtigt, so muss im zeitbezogenen EER-Diagramm eine weitere Entitätsmenge Transaktionszeit modelliert werden, die mindestens ein Schlüsselattribut, den Anfangszeitpunkt bzw. den Endzeitpunkt der Transaktionszeit, enthält. Konzepte temporaler DB

Was wären die Kompromisse die eingegangen werden müssten?
Zusammenfassung Temporale Datenbanken versprechen eine umfassendere Unterstützung der Zeitdomäne. es hat sich gezeigt, dass eine Beschränkung der Zeitdomäne auf ein diskretes Modell der Zeit und der alleinige Verwendung von Zeitpunkten, unter Vernachlässigung von Zeitintervallen und Zeitfolgen, praktikabler erscheint. Fragen In wieweit komplexere Zeitdomänen sowie die Berücksichtigung von Zeitfolgen zu realisieren sind? Was wären die Kompromisse die eingegangen werden müssten? nicht vollständig geklärt, wie Abfragen mit Duplikaterhaltung behandelbar sind. Konzepte temporaler DB

Vielen Dank für Ihre Aufmerksamkeit
Konzepte temporaler DB

Konzepte temporaler Datenbanken

Ähnliche Präsentationen

Präsentation zum Thema: "Konzepte temporaler Datenbanken"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

Konzepte temporaler Datenbanken

Ähnliche Präsentationen

Präsentation zum Thema: "Konzepte temporaler Datenbanken"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback