Temporale Aspekte Data Vault Volkmann

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/314446630
Temporale Aspekte in Data Vault
Thesis · September 2015

DOI: 10.13140/RG.2.2.32171.85289
CITATIONS READS
0 555
1 author:
Stephan Volkmann
Universität Paderborn
2 PUBLICATIONS 0 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
Research Fact-Oriented Modeling View project
Research Bitemporal Historization View project
All content following this page was uploaded by Stephan Volkmann on 10 March 2017.
The user has requested enhancement of the downloaded file.

Universität Paderborn
Fakultät Wirtschaftswissenschaften
Fachgebiet Wirtschaftsinformatik
Analytische Informationssysteme und Business Intelligence
Bachelorarbeit
Temporale Aspekte in Data Vault
von
Stephan Volkmann
Matrikelnummer 7000521
Grevestraße 8 33102 Paderborn
stevolkm@mail.uni-paderborn.de
vorgelegt bei
Jun.-Prof. Dr. Artus Krohn-Grimberghe
Prof. Dr. Leena Suhl
in Kooperation mit
Dirk Lerner
ITGAIN GmbH
12. September 2015

Sperrvermerk
Die Bachelorarbeit wurde in Kooperation mit der Firma ITGAIN Consulting Gesell-
schaft für IT-Beratung mbH durchgeführt. In Absprache mit meinen Betreuern Herrn
Dirk Lerner und Herrn Jun.-Prof. Dr. Artus Krohn-Grimberghe kann trotz Zusammen-
arbeit auf den Sperrvermerk verzichtet werden, da keine vertraulichen Informationen
aus der Firma verwendet oder in die Bachelorarbeit eingearbeitet wurden.
Die Bachelorarbeit kann daher zur Einsicht und Ausleihe in der Bibliothek der Uni-
versität Paderborn aufgenommen werden. Ebenso sind Veröffentlichungen der Bache-
lorarbeit oder ihres wesentlichen Inhalts von der Fakultät Wirtschaftswissenschaften
der Universität Paderborn erlaubt.
Eidesstaatliche Erklärung
Hiermit erkläre ich an Eides statt, dass ich die vorliegende Arbeit selbständig und
ohne unerlaubte fremde Hilfe angefertigt, andere als die angegebenen Quellen und
Hilfsmittel nicht benutzt und die den benutzten Quellen und Hilfsmitteln wörtlich
oder inhaltlich entnommenen Stellen als solche kenntlich gemacht habe.
Paderborn, 12. September 2015
——————————————
(Stephan Volkmann)
Abstract - deutsch
Die vorliegende Bachelorarbeit beschäftigt sich mit temporalen Aspekten in Data
Vault. Das Ziel der Arbeit ist es, die Probleme der bi-temporalen Historisierung ei-
nerseits theoretisch darzustellen, andererseits in der praktischen Umsetzung der Data
Vault Modellierung zu lösen.
Zunächst gibt die Arbeit einen Überblick über die bisherigen Entwicklungen zum
temporalen Datenmanagement. In diesem Abschnitt werden die wichtigsten Veröf-
fentlichungen zu diesem Thema miteinander verglichen. Es wird eine Einschätzung
gegeben, welche Ziele zukünftige Entwicklungen mit Fokus auf das temporale Daten-
management verfolgen sollten.
Anschließend werden die theoretischen Grundlagen zur bi-temporalen Modellierung
erläutert. Die zentralen Aspekte, die bei der Umsetzung eines bi-temporalen Daten-
modells beachtet werden müssen, werden schrittweise eingeführt.
Aktuell wird der Data Vault Ansatz von Dan Linstedt als eine weitere Modellierungs-
technik für das core data warehouse betrachtet. Aufgrund der Aktualität der Diskus-
sionen zu diesem Thema sollen die theoretisch beschriebenen Grundlagen praktisch
am Beispiel eines data warehouse mit Data Vault Modellierung angewandt werden.
Dazu wird zunächst erklärt, welche Elemente in einem Data Vault Modell existieren
und wie diese aus Quelldaten aufgebaut werden. Der Data Vault Ansatz wird mit
normalisierten Datenmodellen und der dimensionalen Modellierung verglichen. Eine
Bewertung des Ansatzes findet durch Analyse von Anwenderberichten und Literatur
statt.
Der praktische Teil der Arbeit stützt sich auf ein selbst erstelltes Testmodell. Zu-
nächst wird erläutert, wie ein Quelldatenmodell in ein Data Vault Modell transfor-
miert wird. Anschließend folgt eine Beschreibung vom ETL-Prozess, der die Daten
vom Quellsystem in das data warehouse lädt. Die dafür erstellten SQL-Skripte die-
nen als Musterbeispiele für die Umsetzung der bi-temporalen Historisierung in Data
Vault. Abschließend wird ein Generator in Java implementiert, der durch Analyse von
Metadaten die SQL-Skripte automatisiert erstellen kann.
Stichworte: Bi-temporale Historisierung, Core Data Warehouse, Data Vault

Abstract - englisch
This bachelor thesis deals with temporal aspects in Data Vault. The aim of this work
is on the one hand to present the problems of bi-temporal historization theoretically,
on the other solving these problems in a practical implementation of the Data Vault
modeling approach.
First, the paper gives an overview of the latest developments on temporal data
management. The section describes and compares the most important publications on
this subject. It is given an assessment on the objectives which the developments with
a focus on the temporal data management should follow.
Then the theoretical basics for bi-temporal modeling are explained. The key aspects
that need to be taken into account in the implementation of a bi-temporal data model
are introduced gradually.
Currently the Data Vault approach of Dan Linstedt is considered as another mo-
deling technique for the core data warehouse. Due to the current relevance of the
discussions on this subject the temporal aspects are applied in practice by the ex-
ample of a data warehouse with Data Vault modeling. For this purpose it will be
explained what elements exist in a Data Vault model and how it is filled with the
source data. The Data Vault approach is compared to normalized data models and
dimensional modeling. An assessment of the approach takes place through analysis of
case studies and literature.
The practical part of the work is based on a self-created test model. First is explai-
ned how to transform a source data model to a Data Vault model. Subsequently, the
ETL process which loads the data from the source system to the data warehouse is
described. The SQL scripts serve as examples for the implementation of bi-temporal
historization in Data Vault. Finally a generator in Java is implemented, which can
create the SQL scripts automated by analyzing metadata.
Keywords: Bitemporal historization, Core Data Warehouse, Data Vault

Inhaltsverzeichnis
1. Einleitung 1
1.1. Problematik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Historie des temporalen Datenmanagements 3

2.1. Beginn der Entwicklungen in den 1980er Jahren . . . . . . . . . . . . . 3
2.2. Erweiterungen für SQL, Entwicklungen zu data warehouse und data
mart in den 1990er Jahren . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Neueste Entwicklungen zum temporalen Datenmanagement seit 2000 . 5
2.4. Anforderungen zukünftiger Entwicklungen . . . . . . . . . . . . . . . . 7
3. Theorie zur bi-temporalen Modellierung 9

3.1. Definition einer Zeitperiode . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Unterschied von nicht-, uni- und bi-temporalen Daten . . . . . . . . . . 10
3.3. Unterschiedliche Bezeichnungen für logische und physische Zeit . . . . . 14
3.4. Die Beziehungen nach Allen . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5. Konzept der temporalen Integrität . . . . . . . . . . . . . . . . . . . . . 20
3.6. Bi-temporale Entitätsintegrität . . . . . . . . . . . . . . . . . . . . . . 23
3.7. Bi-temporale referentielle Integrität . . . . . . . . . . . . . . . . . . . . 28
4. Theorie zur Modellierung mit Data Vault 33

4.1. Modellierung von Geschäftsobjekten: der Hub . . . . . . . . . . . . . . 33
4.2. Modellierung von Beziehungen: der Link . . . . . . . . . . . . . . . . . 34
4.3. Modellierung von Kontext: der Satellit . . . . . . . . . . . . . . . . . . 36
4.4. Grundsätzliche Unterschiede zu bisherigen Modellierungstechniken . . . 38
4.5. Bewertung der Modellierung mit Data Vault . . . . . . . . . . . . . . . 39
5. Praktische Entwicklungen zur bi-temporalen Historisierung in Data Vault 41

5.1. Das Datenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2. Der ETL-Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3. Testen des ETL-Prozesses . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.4. Implementierung des SQL-Generators . . . . . . . . . . . . . . . . . . . 51
6. Schlussteil 55
6.1. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
i
Inhaltsverzeichnis
6.2. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.3. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Literaturverzeichnis 57
A. Informationen zur Firma ITGAIN 61
B. Datenmodelle von Quellsystem und data warehouse 63

B.1. Datenmodell der Quelldatenbank . . . . . . . . . . . . . . . . . . . . . 63
B.2. Datenmodell des Data Vault data warehouse . . . . . . . . . . . . . . . 65
C. Testdaten 67
D. Inhalt der DVD 69
ii
Abbildungsverzeichnis
3.1. Nicht-temporale, uni-temporale und bi-temporale Tabellenstruktur . . . 11

3.2. Taxonomie der Beziehungen nach Allen . . . . . . . . . . . . . . . . . . 19
3.3. Dreidimensionaler Raum einer bi-temporalen Kundentabelle . . . . . . 21
3.4. Kleinste bi-temporale Einheit . . . . . . . . . . . . . . . . . . . . . . . 22
3.5. Zusammengefügte bi-temporale Zellen . . . . . . . . . . . . . . . . . . . 23
3.6. Bi-temporale Fläche für Beispieldatensatz zu K1 . . . . . . . . . . . . . 24
3.7. Bi-temporale Flächen nach Einfügen von neuem Datensatz . . . . . . . 26
3.8. Bi-temporale Flächen nach Änderung eines Datensatzes . . . . . . . . . 27
4.1. Beispiele für einen Hub . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2. Beispiel für einen Link . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3. Beispiele für einen Satellit . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.4. Beispiel für ein Data Vault Modell . . . . . . . . . . . . . . . . . . . . . 37
5.1. Der ETL-Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.2. Erste Daten in der Staging-Datenbank . . . . . . . . . . . . . . . . . . 48
5.3. Das Laden der ersten Daten in das data warehouse . . . . . . . . . . . 48
5.4. Neue Daten in der Staging-Datenbank . . . . . . . . . . . . . . . . . . 49
5.5. Der Satellit Sat_Cust_Prem nach dem Laden der neuen Datensätze . . 50
5.6. Funktionsweise des SQL-Generators . . . . . . . . . . . . . . . . . . . . 52
5.7. Beispiel für Metadaten . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
iii
Tabellenverzeichnis
3.1. Eine uni-temporale Tabelle . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2. Eine bi-temporale Tabelle . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3. Terminologie zu bi-temporaler Modellierung . . . . . . . . . . . . . . . 15
3.4. Ein Beispiel für eine bi-temporale Fremdschlüsselbeziehung . . . . . . . 28
B.1. Abkürzungen des DataVaultDWH-Modells . . . . . . . . . . . . . . . . 66
v
1. Einleitung
Die temporalen Aspekte von Daten sind seit Beginn der Datenbankmodellierung ein
wichtiger Bestandteil von Entwicklungen im Datenmanagement. Es gibt sehr viele ver-
schiedene Möglichkeiten Daten mit Zeitbezug zu speichern, jedoch hat sich bisher kein
Standard durchgesetzt. Damit die Datenbankmodellierer und Anwender diese Kon-
zepte effektiv nutzen können, brauchen sie ein grundlegendes Verständnis der Theorie.
Dies ist notwendig, um Anforderungen an temporale Daten durch ein Geschäftsmodell
sinnvoll zu formulieren und in der Datenbank umsetzen zu können.
Diese Bachelorarbeit soll zunächst eine fundierte Wissensgrundlage zur Theorie der
temporalen Modellierung mit Fokus auf die bi-temporale Historisierung liefern. An-
schließend wird in einem praktischen Teil diese Theorie genutzt, um in Kooperation
mit der Firma ITGAIN1 die bi-temporale Historisierung in Data Vault umzusetzen.
Zusätzlich soll ein Konstrukt entwickelt werden, welches das Laden von Daten in ein
data warehouse durch Analyse von Metadaten automatisiert.
1.1. Problematik
Die wissenschaftliche Untersuchung von temporalen Aspekten wurde in den 1980er
Jahren intensiviert. Um einen Zeitbezug der Daten in einer Datenbank definieren zu
können, wurden die Daten zunächst mit einer Zeit-Dimension verknüpft. So wurde
es möglich, Daten in Tabellen uni-temporal zu speichern. Eine uni-temporale Tabelle
speichert Daten in Bezug zur logischen oder physischen Zeit. Die logische Zeit wird als
die Zeit definiert, in der Fakten oder Daten in der realen Welt wahr sind. Eine Tabel-
le, welche Angaben zur logischen Zeit nutzt, wird als „historical relation“ [JDB+ 98]
bezeichnet, da die Daten mit ihr historisiert werden können. Die physische Zeit wird
als die Zeitangabe definiert, zu der die Fakten bzw. die Daten in der Datenbank prä-
sent sind. Eine Tabelle, welche die physische Zeit nutzt, wird als „rollback relation“
[JDB+ 98] bezeichnet, da mit dieser Zeitangabe eine Versionierung eingeführt wird und
die Tabelle zu alten Versionen wiederhergestellt werden kann.
Eine bi-temporale Datenbank soll die Vorteile beider Zeitdimensionen vereinen und
speichert sowohl logische als auch physische Zeit zu den Daten. Bei dieser Modellierung
können jedoch einige Fragen auftauchen: Wie wird mit Aktualisierungen der Daten
umgegangen, so dass weiterhin alte Daten verfügbar und jederzeit einsehbar sind?
Was passiert bei fehlerhaften Eingaben von Zeitangaben, können sie ohne Probleme
abgeändert werden? Wie können Abhängigkeiten zwischen den Zeitangaben realisiert
1
Informationen zur Firma ITGAIN sind in Anhang A zu finden.
1
1. Einleitung
werden? Sollte die physische Zeit immer nach oder gleichzeitig mit der logischen Zeit
beginnen? Und wie müssen Anfragen angepasst werden, die beide Zeitdimensionen
berücksichtigen?
Diesen Fragestellungen haben sich Wissenschaftler im Bezug zu bi-temporalen Da-
tenmodellen und damit verbundenen Abfragesprachen bereits angenommen. Es gibt
jedoch eine Vielzahl an verschiedenen Modellierungsansätzen und keinen einheitlichen
Standard zur bi-temporalen Historisierung.
Eine neue Art der Modellierung eines data warehouse ist die Umsetzung mit Data
Vault. Für diesen Modellierungsansatz existiert noch kein standardisiertes Konzept
zur Modellierung von bi-temporalen Daten.
1.2. Zielsetzung
Das erste Ziel dieser Bachelorarbeit ist es, die bi-temporale Historisierung in Data
Vault zu beschreiben. Dem Leser sollen auf verständliche Art die Theorie und die
Probleme der bi-temporalen Historisierung vermittelt werden. Das Ergebnis der Arbeit
soll es Außenstehenden ermöglichen, die bi-temporale Historisierung in der Data Vault
Modellierung umzusetzen. Als zweites Ziel soll ein Generator entwickelt werden, der
aus Metadaten die nötigen Informationen ausliest um SQL-Skripte zu erstellen, welche
Daten automatisiert in ein data warehouse laden.
1.3. Vorgehensweise
Der erste Schritt in der Bachelorarbeit ist eine Literaturrecherche zum Thema tempo-
rale Datenbanken, Bi-Temporalität und Data Vault, um grundlegende Begrifflichkei-
ten kennenzulernen. Anschließend wird die Arbeit zum Erreichen der Zielsetzung in
folgende Abschnitte eingeteilt:
Zunächst wird im Kapitel 2 die historische Entwicklung des temporalen Datenma-
nagements vorgestellt. Anschließend werden in Kapitel 3 die theoretischen Grundlagen
zur bi-temporalen Modellierung erläutert. In Kapitel 4 wird der Data Vault Ansatz
erklärt und von anderen Modellierungstechniken abgegrenzt.
Im Praxisteil der Arbeit wird in Kapitel 5 erläutert, wie die bi-temporale Histori-
sierung in der Data Vault umgesetzt werden kann. Ebenso wird die Implementierung
des Generators vorgestellt.
Im abschließenden Kapitel 6 wird eine Zusammenfassung der Arbeit erstellt und ein
Fazit gezogen. Zuletzt wird ein Ausblick auf zukünftige Entwicklungsmöglichkeiten
gegeben.
2
2. Historie des temporalen Datenmanagements
Die Historie der Entwicklung von temporalem Datenmanagement reicht bis zu den An-
fängen der Datenbanksysteme zurück. Mit Sicherungen und Protokoll-Dateien wurden
die ersten Historien zu den Daten aufgebaut. Auf den Daten ausgeführte Transaktionen
wurden in einer Protokoll-Datei mitgeschrieben. Die Daten selbst wurden periodisch
auf externen Datenträgern gesichert. Somit konnte man für eine beliebige Periode in
der Vergangenheit die Daten rekonstruieren. Allerdings haben weder die Datenbank-
Management-Systeme (DBMS), noch die Datenstrukturen, welche diese verwalten,
einen Mechanismus oder eine Struktur geliefert, um Daten der Vergangenheit, der
Gegenwart oder der Zukunft zu trennen [JW10]. Solange keine selbst-entworfene Da-
tenstruktur oder eigenhändig geschriebener Code verwendet wurde, wurde ein Objekt
genau durch eine Zeile einer Datenbanktabelle repräsentiert.
Die großen Änderungen und Entwicklungen in der Vergangenheit wurden mit dem
Ziel durchgeführt, temporale Daten zugänglicher zu machen [JW10]. In der heutigen
Zeit ist der Speicherplatz günstiger als früher, die Rechenleistungen sind gestiegen und
durch die neuen Möglichkeiten wird weniger Aufwand und Zeit benötigt, um temporale
Daten zu nutzen.
Dieses Kapitel fasst relevante Entwicklungen der Vergangenheit zusammen, um
einen Überblick über den aktuellen Stand der Technik zu geben.
2.1. Beginn der Entwicklungen in den 1980er Jahren

In den 1980ern sind die Kosten für den Speicherplatz gesunken, und somit wurde es
für Unternehmen möglich, ihre Daten zusätzlich auf externen Medien zu sichern. In
dieser Zeit haben Unternehmer den Nutzen erkannt, nicht nur eine Sicherung ihrer
Daten zu besitzen, sondern auch die Möglichkeit zu haben, mehrere Datensicherungen
zu verschiedenen Zeitpunkten miteinander zu vergleichen [JW10]. Jede Sicherung war
somit ein „snapshot“[JDB+ 98] zu einem bestimmten Zeitpunkt. Durch die Betrachtung
der snapshots in ihrer zeitlichen Abfolge konnte die Veränderung von Objekten über
einen bestimmten Zeitraum beobachtet werden. Diese Betrachtungsweise wurde als
„data warehouse“ nach Devlin und Murphy [DM88] benannt. Das Konzept führte das
temporale Datenmanagement auf der Datenbankebene ein.
Zwei weitere Entwicklungen in dieser Zeit waren die „history tables“ und die „version
tables“ [JW10]. Die history tables speichern nur historische Daten. Wurde beispielswei-
se ein Objekt in der Ursprungstabelle geändert oder gelöscht, wurde dieser Datensatz
mit Hilfe von „Triggern“ in die history table eingefügt. In einer version table werden
historische und aktuelle Daten gleichzeitig gespeichert.
3
Außerdem wurde in dieser Zeit begonnen, sogenannte „on-line transaction tables“

zu entwickeln [JW10]. In diesen Tabellen wurden nicht nur aktuelle Transaktionen
gespeichert, die auf den Daten ausgeführt wurden. Es wurden auch Transaktionen
gespeichert, die für die aktuelle Periode der Buchhaltung nicht mehr relevant waren.
Der Unterschied von history und version tables zu transaction tables ist, dass history
und version tables den Zustand von Objekten zu unterschiedlichen Zeiten speichern,
während die transaction tables die Ereignisse speichern, welche die Zustände der Ob-
jekte verändern.
2.2. Erweiterungen für SQL, Entwicklungen zu data warehouse

und data mart in den 1990er Jahren
Zu Beginn der 1990er Jahren beschäftigten sich die Wissenschaftler zunehmend mit
dem Bereich der Bi-Temporalität. Diese wurde verstanden als die Trennung der Zeit-
angabe in logische Zeit und physische Zeit [JW10]. Die logische Zeit beschrieb einen
Zeitpunkt oder ein Zeitintervall, in dem bestimmte Informationen über ein Objekt
als wahr angenommen wurden. Die physische Zeit beschrieb die Zeit, in welcher ein
Datensatz in der Datenbank physisch existierte.
Mit seiner Veröffentlichung im Jahr 1992 forderte Snodgrass, dass im Bereich der
Bi-temporalität eine Erweiterung der Sprache SQL entwickelt werden müsste [Sno92].
Eine Gemeinschaft von Datenbankspezialisten organisierte daher einen Workshop zu
diesem Thema im Jahr 1993, durch dem deutlich wurde, dass großes Interesse an
der Entwicklung solcher Erweiterungen bestand. Nach mehreren Veröffentlichungen
und Überarbeitungen mündete die Diskussion in einer Spezifikation einer Sprache, der
Temporal Structured Query Language (TSQL2) [SAA+ 94]. Die Erweiterungen wurden
als Vorschlag an das SQL Standard Komitee übermittelt, allerdings wurden sie bis 2011
nicht offiziell anerkannt.
Die zweite große Entwicklung in den 90ern war die Übernahme vom Konzept des
data warehouse und die Erweiterung dessen von Bill Inmon [Inm92]. Durch seine Ver-
öffentlichungen wurde die IT-Industrie aufmerksam auf diese Möglichkeit der Daten-
sicherung [JW10]. Das data warehouse speichert eine Historie als Folge von snapshots
der nicht-transaktionalen Tabellen. Wichtig in diesem Konzept ist die Betrachtungs-
weise von persistenten Objekten zu verschiedenen Zeitpunkten [JW10].
Kurze Zeit später wurde von Ralph Kimball [Kim96] ein weiterer Ansatz zur Da-
tenbankmodellierung entwickelt. Er beschreibt eine Methode, wie man eine Historie
als Sammlung von Transaktionen speichern kann. In diesem Konzept ändert sich der
Fokus von den Objekten selbst zu ihren Beziehungen untereinander. Der Zustand ei-
nes Objektes kann durch die chronologische Abfolge von auf das Objekt bezogenen
Transaktionen zu jedem Zeitpunkt wiederhergestellt werden.
Durch die gleichzeitige Entwicklung dieser beiden Konzepte entstand eine lang an-
dauernde Diskussion, welcher Ansatz besser geeignet wäre. Diese Diskussion soll nicht
4
2.3. Neueste Entwicklungen zum temporalen Datenmanagement seit 2000
näher betrachtet werden, da der Fokus dieser Arbeit auf der bi-temporalen Modellie-
rung mit Data Vault liegt.
Auf Grund von unterschiedlicher Kritiken an den Modellen entwickelten beide Wis-
senschaftler ihre Ansätze weiter. Inmon entwickelte eine übergreifende Architektur
zur Sammlung von Daten aus unterschiedlichen Quellen [Inm02]. Kimball hingegen
definiert mehrere kleine Datenbanken als sogenannte „data marts“, die je einen Ge-
schäftsprozess abbilden [KR02]. Durch das Konzept der „conformed dimensions“ sollen
die Informationen in den Dimensionstabellen der data marts konform gehalten werden.
2.3. Neueste Entwicklungen zum temporalen Datenmanagement

seit 2000
Im Jahr 2000 beschreiben Gabbay et al. in ihrem Buch [GRF00] ein logisches Frame-
work für Datenbanken, in dem sowohl statische als auch dynamische Objekte verwaltet
werden können. Dieses Framework besteht aus einem zwei-dimensionalen temporalen
Modell. Die erste Dimension beschreibt die statische Sicht auf ein Objekt, welche für
Abfragen und Sichten benötigt wird. Die zweite Dimension definiert eine dynamische
Sicht auf die Objekte, welche für die Aktualisierung der Objekte benötigt wird. Das
Modell charakterisiert formal den Unterschied zwischen der logischen und physischen
Zeit.
Eine weitere Entwicklung waren die „slowly changing dimensions (SCD´s)“ von
Kimball [KR02]. Bei dieser Art der Modellierung von Dimensionstabellen können Än-
derungen an einem Objekt zusammen mit dem aktuellen Stand in der Tabelle gespei-
chert werden, um eine Historisierung des Objektes zu ermöglichen. Es gibt bei dieser
Methode verschiedene Typen, wie mit den Änderungen an Objekten umgegangen wer-
den soll. Relevant für Bi-temporalität sind die Typen 2 und 3, da bei diesen Typen
zusätzliche Zeitintervalle zu den Objekten benötigt werden. Allerdings sind laut John-
ston et al. [JW10] diese Tabellen nur uni-temporal, da sie nicht zwischen Veränderung
und Korrektur eines Objekts unterscheiden können. Außerdem wird von ihnen kriti-
siert, dass bei dieser Modellierung zu viel Arbeitsaufwand beim Anwender liege, da
dieser bei speziellen Anfragen nicht vom Datenbanksystem unterstützt werden könn-
te. Dadurch würden sich durch erhöhten Zeitbedarf und geringere Zuverlässigkeit die
Kosten für die Nutzung eines solchen Systems erhöhen.
Da Anfang der 2000er keine temporalen Erweiterungen in SQL umgesetzt worden
sind, entwickelten Date, Darwen und Lorentzos [DDL03] einen eigenen Ansatz, um
temporale Daten in einem Datenbanksystem korrekt verwalten zu können. Dabei fo-
kussierten sich die Autoren auf die Erweiterung einer relationalen Datenbank um zu-
sätzliche Operatoren, die mit Zeitangaben in Form von Intervallen umgehen können.
Diese Operatoren werden dazu genutzt, die Integritätsbedingungen der Datenbank bei
Einfügen, Ändern und Entfernen von temporalen Daten zu erfüllen.
Zusätzlich zu diesen Entwicklungen wurde eine neue Form des data warehouse be-
5
trachtet, das „Real-Time Data Warehouse“ [Lan04]. Bei dieser neuen Form werden
statt regelmäßiger snapshots der Tabellen die entsprechenden Zeilen vor einer Ände-
rung als Abbild gesichert. Diese Änderung war nötig, da die periodischen snapshots
keine Änderungen gespeichert haben, die von nachträglichen Änderungen in der glei-
chen Periode überschrieben wurden. Außerdem wurden keine neu eingefügten Objekte
gesichert, die in der gleichen Periode wieder gelöscht wurden. Laut Johnston et al.
wird diese Modellierungsart allerdings in der Praxis missverstanden und somit auch
falsch umgesetzt [JW10].
Im Jahr 2010 veröffentlichen Johnston et al. aufgrund der Kritiken an den bisherigen
Entwicklungen das „Asserted Versioning Framework“ [JW10], um temporale Daten zu
verwalten. Das Ziel war die Entkapselung der Komplexität von temporalen Daten aus
der Datenbank heraus. Der Vorteil dieses Frameworks ist, dass die Transaktionen zu
Objekten und Abfragen sehr ähnlich zu denen von nicht-temporalen Datenbanken
sind, und somit Anwender dieser Datenbanken einen leichten Einstieg haben. Die
Autoren stellen das Framework nicht nur für einzelne Prozesse bereit, sondern auch
als komplette Unternehmenslösung.
Durch die steigende Relevanz von temporalen Aspekten in Datenbanken wurden
schließlich auch im SQL-Standard Erweiterungen vorgenommen. 2008 wurden die
„system-versioned tables“ und 2010 die „application-time period tables“ in den Stan-
dard aufgenommen und im Jahr 2011 durch SQL:2011 (ISO/IEC 9075:2011) veröffent-
licht [KM12]. Neben weiteren Neuerungen steht mit dieser Veröffentlichung die Un-
terstützung von temporalen Daten im Fokus. Dies wird unter anderem durch folgende
Modifikationen ermöglicht: Zur Festlegung eines Zeitintervalls werden zwei Spalten in
einer Tabelle für Start- und Endzeit des Intervalls definiert. Die application-time pe-
riod tables werden eingeführt, um die logische Zeit eines Objektes zu repräsentieren.
Die system-versioned tables werden eingeführt, um die physische Zeit eines Objek-
tes zu repräsentieren. Letztere werden automatisch vom Datenbanksystem verwaltet.
Die Primärschlüssel der Tabellen können nun temporal verwaltet werden, indem ein
nicht-temporaler Primärschlüssel um ein Zeitintervall erweitert wird. Das Zeitintervall
ist somit Teil des Primärschlüssels. Durch die gemeinsame Nutzung von system-time
und application-time in einer Tabelle als Primärschlüssel können bi-temporale Tabel-
len unterstützt werden. Durch spezielle Operatoren können trotz der Komplexität der
Bi-temporalität die Entitätsintegrität und die referenzielle Integrität erhalten werden.
Allerdings sind im Vergleich zur Veröffentlichung von Darwen et al. [DDL03] einige
Probleme nicht mit dem neuen Standard lösbar: In SQL:2011 gibt es keine Operato-
ren, die mit leeren Intervallen umgehen können. Außerdem wird keine Lösung für das
sogenannte „circumlocution problem“ unterstützt. Bei diesem Problem existieren zwei
zeitlich direkt aufeinanderfolgende Datensätze, welche die gleiche Information reprä-
sentieren. Diese Datensätze müssen laut Darwen [Dar13] zusammengeführt werden,
um fehlerhafte Abfragen und Berichte auszuschließen.
6
2.4. Anforderungen zukünftiger Entwicklungen
2.4. Anforderungen zukünftiger Entwicklungen

Johnston [JW10] beschreibt die Ziele aktueller Forschung in folgender Weise: Das
Hauptziel der aktuellen Entwicklungen sei, temporale Daten jederzeit verfügbar zu
machen. Historische Daten sollten zu jedem Zeitpunkt wiederhergestellt werden kön-
nen. Diese Anforderung wird von ihm als „seamless, real-time access“ bezeichnet und
wird in folgende zwei Teile unterteilt:
Einerseits sei die Benutzbarkeit wichtig. Die temporalen Daten müssen genauso
zugänglich sein wie nicht-temporale Daten. Außerdem müssen Anfragen zu temporalen
Daten genauso einfach zu schreiben sein wie für nicht-temporale Daten.
Andererseits spiele die zeitliche Ausführung eine große Rolle. Die Anfragen zu tem-
poralen Daten müssen Ergebnisse in ähnlicher Zeit wie für nicht-temporale Daten
liefern können.
Das Problem heutiger Datenbanksysteme sei, dass diese weiterhin spezialisiert auf
aktuelle Daten sind und keine integrierte Unterstützung für die temporalen Strukturen
historischer Daten liefern. Daher müssten Entwickler diese Strukturen erst eigenhändig
entwickeln und verwalten. Temporale Transaktionen und Abfragen seien zu komplex,
um diese fehlerfrei in angemessener Zeit zu definieren.
Daher gibt es laut Johnston noch viel Potenzial in der Entwicklung von Datenbank-
systemen im Bereich des temporalen Datenmanagements, vor allem im Bereich der
Bi-temporalität.
7
3. Theorie zur bi-temporalen Modellierung
Dieses Kapitel beschreibt die theoretischen Grundlagen der bi-temporalen Modellie-
rung. Im ersten Abschnitt wird zunächst definiert, was eine Zeitperiode ist. Im zweiten
Kapitel werden anschließend die Unterschiede von nicht-, uni- und bi-temporalen Da-
ten erklärt und was diese Daten semantisch ausdrücken. Anschließend wird im dritten
Abschnitt eine einheitliche Begriffsgrundlage für die unterschiedlichen Zeitbegriffe de-
finiert, da diese Begriffe in der Literatur oft geändert wurden. Im vierten Abschnitt
werden die Beziehungen nach Allen [All83] erklärt, da diese eine zentrale Bedeutung in
der temporalen Modellierung haben. Weiterhin werden im fünften Abschnitt zunächst
allgemein die temporalen Integritätskonzepte dargestellt. Diese werden in Abschnitt
sechs und sieben mit der temporalen Entitätsintegrität und der temporalen referenti-
ellen Integrität auf bi-temporale Daten spezialisiert.
Voraussetzungen für dieses Kapitel sind die Mathematik und die Logik des relatio-
nalen Paradigmas sowie SQL als Datenbanksprache. Diese Inhalte können aufgrund
des Umfangs und des Fokus der Arbeit auf die temporalen Aspekte an dieser Stelle
nicht erläutert werden. Eine Erklärung dieser Themen kann in [Joh14] und [DD97]
nachgelesen werden.
3.1. Definition einer Zeitperiode

In der Historisierung von Daten wird der Zustand einer Entität über verschiedene
Zeitperioden betrachtet. Eine Zeitperiode ist eine fortlaufende Aneinanderreihung von
mehreren einzelnen Zeitpunkten. Die kleinste Einheit, die einen Zeitpunkt im Daten-
banksystem beschreibt, wird als „chronon“ bezeichnet [Joh14]. Eine Zeitperiode wird
durch ihren ersten und letzten Zeitpunkt repräsentiert. Bei dieser Darstellung gibt
es vier mögliche Sichtweisen welcher Zeitpunkt in der Zeitperiode enthalten ist: „clo-
sed/closed“, „open/closed“, „closed-open“ und „open/open“ [Joh14]. Diese Sichtweisen
sollen an dem Beispielintervall [Juni 2014 - August 2014] veranschaulicht werden. Im
Theorie-Teil dieser Arbeit wird als Zeitgranularität der Monat eines Jahres gewählt,
um die Beispiele zu vereinfachen. Alle Konzepte treffen jedoch auf jede Granularitäts-
stufe der Zeit gleichermaßen zu.
In der closed/closed-Sichtweise sind in diesem Intervall die Monate Juni, Juli und
August vollständig im Intervall enthalten, da sowohl Start- als auch Endzeitpunkt
enthalten sind. In der open/closed-Sichtweise ist der Startzeitpunkt nicht enthalten,
der Endzeitpunkt jedoch schon. Daher sind hier die Monate Juli und August ent-
halten. In der closed/open-Sichtweise ist der Startzeitpunkt enthalten, der Endzeit-
punkt hingegen nicht mehr. Daher sind hier die Monate Juni und Juli enthalten. In
9
der open/open-Sichtweise ist keiner der beiden Zeitpunkte enthalten. Die Zeitperiode
würde daher nur den Monat Juli enthalten.
Jede dieser Sichtweisen kann ein beliebiges nicht-leeres Zeitintervall darstellen. Die
open/closed- und die closed/open-Sichtweise haben jedoch einen entscheidenden Vor-
teil: Mit Ihnen kann man direkt feststellen, ob zwei Zeitperioden direkt aufeinander-
folgen. Dies bedeutet, dass kein Zeitpunkt zwischen den Intervallen existiert. Bei zwei
Zeitintervallen z1 und z2 kann dies einfach überprüft werden, indem der Endzeitpunkt
der früheren Periode mit dem Anfangszeitpunkt der späteren Periode verglichen wird.
Sind beide Zeitpunkte identisch, so liegen z1 und z2 zeitlich direkt nacheinander. Ein
Beispiel für zwei Zeitperioden, die in der closed/open Sichtweise aufeinanderfolgen,
sind die Intervalle [Juni 2014 - August 2014] und [August 2014 - Juni 2015].
Die closed/open-Sichtweise wurde gegenüber der open/closed-Sichtweise von der
Wissenschaft als de-facto-Standard anerkannt [Joh14]. Dies wird von Johnston da-
durch erklärt, dass die natürliche Aufzählung in einem Zeitintervall immer mit dem
ersten Zeitpunkt im Intervall startet, und nicht mit dem Zeitpunkt direkt vor dem
Anfangszeitpunkt. In SQL:2011 sowie in der TSQL2-Spezifikation [SAA+ 94] wurde
diese Sichtweise als de-jure-Standard festgelegt [Joh14]. In dieser Arbeit wird daher
die closed/open-Sichtweise für angegebene Zeitintervalle übernommen.
In der Praxis müssen häufig Zeitperioden eingetragen werden, deren Endzeitpunkte
zum Zeitpunkt der Transaktion nicht bekannt sind. Diese Zeitperioden werden daher
mit dem spätesten Zeitpunkt, der im Datenbanksystem möglich ist, als Endzeitpunkt
eingetragen. Im SQL-Server wäre dies beispielsweise der 31. Dezember 9999. Durch die-
se Modellierung ist es möglich, die offenen Zeitperioden in der closed/open-Sichtweise
in die Datenbank zu integrieren.
3.2. Unterschied von nicht-, uni- und bi-temporalen Daten

In diesem Abschnitt wird der Unterschied zwischen nicht-, uni- und bi-temporalen
Daten erläutert. In Abbildung 3.1 wird eine Datenzeile einer relationalen Tabelle in
den drei verschiedenen Modellierungen dargestellt. Die id steht für ein Feld, welches
ein Objekt eindeutig identifiziert. PK steht für den Primärschlüssel (primary key)
der Tabelle. bt und et stehen für Anfangs- und Endzeit (begin time, end time) einer
Zeitperiode. bt1 und et1 markieren dabei eine Zeitperiode, bt2 und et2 markieren
eine zweite Zeitperiode. Mit data werden alle Spalten zusammengefasst, die nicht zum
Primärschlüssel gehören.
In einer nicht-temporalen Tabelle ist die id gleichzeitig der Primärschlüssel. So-
mit steht jede Zeile genau für eine Entität. Dies wird durch die Entitätsintegrität
sichergestellt. Enthält die Tabelle beispielsweise Produkte und besitzt jedes Produkt
einen eindeutigen Identifizierer (zum Beispiel eine Nummer), so kann die Datenbank
garantieren, dass ein Produkt nicht zweimal in der Tabelle enthalten ist. Eine nicht-
temporale Tabelle enthält implizit bi-temporale Zeitbezüge, der Nutzer kann diese
10
jedoch weder angeben noch verändern. Da die Daten in dieser Tabellenart immer den
Stand zum aktuellen Zeitpunkt repräsentieren, wird dieser Zeitpunkt implizit für bei-
de Zeitdimensionen angenommen. Nicht-temporale Tabellen werden daher auch als
„implicitly bitemporal tables“ [Joh14] bezeichnet.
Abbildung 3.1.: Nicht-temporale, uni-temporale und bi-temporale Tabellenstruk-

tur1
In einer uni-temporalen Tabelle hingegen können wir mehrere Zeilen haben, welche
die gleiche Entität beschreiben. Jede Zeile beschreibt eine Entität in einer bestimmten
Zeitperiode, die durch die Anfangs- und Endzeit definiert wird. Die Zeitperiode wird in
den Primärschlüssel integriert. Diese Zeitperiode definiert entweder die logische oder
die physische Zeit. In dem vorliegenden Beispiel kann ein Produkt mehrmals in der
Tabelle auftauchen, jeweils definiert über die id und die Zeitperiode. Jede dieser Zeilen
ist eine Version des Produktes.
Die Tabelle 3.1 zeigt eine uni-temporale Produkttabelle. Die unterstrichenen Spalten
definieren den Primärschlüssel. Zu sehen ist, dass das Produkt mit der id p1 zweimal
in der Tabelle auftaucht. Von Juni 2014 bis Juli 2014 hat es den Preis 1.99, von August
2014 bis Mai 2015 den Preis 1.69.
id bt1 et1 preis

p1 Jun14 Aug14 1.99
p1 Aug14 Jun15 1.69
p2 Jan14 Mai15 2.40
Tabelle 3.1.: Eine uni-temporale Tabelle
1
Übernommen von Johnston, [Joh14], S.3
11
Um aus einer uni-temporalen Tabelle eine bi-temporale Tabelle zu konstruieren,

wird wie in Abbildung 3.1 gezeigt eine weitere Zeitperiode in den Primärschlüssel
integriert. Dies geschieht über die Spalten bt2 und et2. Mit dieser Erweiterung können
nicht nur mehrere Entitäten mit der gleichen id in der Tabelle enthalten sein, sondern
auch Entitäten mit gleicher id und gleichzeitig übereinstimmender erster bzw. zweiter
Zeitperiode. Insgesamt können somit sehr viele ähnliche Datensätze zu einer Entität
in der Tabelle stehen, solange sie sich jeweils in einer der Zeitspalten unterscheiden.
Der bi-temporale Primärschlüssel besteht aus drei Komponenten: Als erstes enthält
der Primärschlüssel mit der id den eindeutigen Identifizierer der Entität. Als zweites
enthält er mit bt1 und et1 die Zeitperiode, in der die Entität mit den angehängten Da-
ten existiert. Als dritter Teil des Primärschlüssels ist mit bt2 und et2 die Zeitperiode
enthalten, in der die Benutzer der Datenbank die Datenzeile als korrekt und aktuell
ansehen. Somit enthält der Primärschlüssel sowohl die logische als auch die physische
Zeitperiode. Die zweite Zeitperiode wird ergänzt, um fehlerhafte Daten nachträglich
ändern zu können ohne das Original zu verlieren. Durch zwei Zeitperioden kann man
sowohl die fehlerhaften Daten für die Wirtschaftsprüfung speichern, als auch deren
Korrektur. Sollten somit zwei Datensätze in der Tabelle enthalten sein, deren id und
logische Zeitperiode gleich ist, so ist der gültige Datensatz der mit der späteren phy-
sischen Zeitperiode.
In der Tabelle 3.2 ist eine bi-temporale Tabelle zu sehen. Der Wert 9999 in der
Spalte et2 stellt den höchsten Wert dar, den das Zeitattribut annehmen kann. Diese
Schreibweise repräsentiert, dass die Endzeit der Zeitperiode noch nicht bekannt ist
und diese somit als aktuell angesehen wird. Der vierte Datensatz stellt eine Korrektur
zum zweiten Datensatz dar: Im Januar 2015 wurde die Korrektur eingetragen, dass
p1 von Aug14 bis Jun15 nicht den Preis 1.69 hat, sondern den Preis 1.79.
id bt1 et1 bt2 et2 preis

p1 Jun14 Jul14 Jun14 9999 1.99
p1 Aug14 Jun15 Aug14 Jan15 1.69
p2 Jan14 Mai15 Jan14 9999 2.40
p1 Aug14 Jun15 Jan15 9999 1.79
Tabelle 3.2.: Eine bi-temporale Tabelle
Durch die bi-temporale Modellierung können wir nun zwei Arten von Berichten
erstellen: Den „as-was“ und den „as-is“ Bericht [JW10]. Sollte unser Bericht eine Zeit
in der Periode von August 2014 bis Dezember 2014 abfragen, wird er nur die ersten 3
Zeilen der Tabelle anzeigen. Als as-was Bericht wird abgefragt, welche Daten zu der
angegebene Zeit korrekt waren. Liegt die Zeit der Abfrage allerdings in einem Zeitraum
ab Januar 2015, so wird der Bericht alle Zeilen außer der zweiten Zeile liefern. Dieser
12
as-is Bericht zeigt, welche Daten zum aktuellen Zeitpunkt korrekt sind. Beide Berichte
zeigen die Historie von Produkt p1 von Juni 2014 bis Juni 2015. Liegt der aktuelle
Zeitpunkt bei einer Abfrage in der zweiten Zeitperiode, so ist sichergestellt, dass immer
die aktuellen Daten zu den abgefragten Datensätzen angezeigt werden [JW10].
Für die temporale Modellierung ist es möglich, nur jeweils einen Teil der Zeitanga-
ben in den Primärschlüssel zu integrieren. In der Praxis werden für die bi-temporale
Modellierung laut Johnston häufig nur die Anfangszeiten der logischen und physischen
Zeit in den Primärschlüssel aufgenommen [Joh14]. Dies ist für die Umsetzung in SQL
vorteilhaft, da man so über eine Aktualisierung der Endzeit der physischen Zeit einen
zuvor gültigen Datensatz als ungültig markieren kann.
Laut Johnston [JW10] muss bei dieser Modellierung ein hohes Maß an Komplexität
verwaltet werden. Im Folgenden werden einige dieser komplexen Probleme aufgezeigt:
In der Tabelle 3.2 wird durch das Datenbankmanagementsystem erlaubt, einen Da-
tensatz anzulegen, dessen Spalten bis auf die Beginn-Zeit bt1 identisch zu einem exis-
tierenden Datensatz sind. Dieser Datensatz könnte beispielsweise so aussehen:
id bt1 et1 bt2 et2 preis

p1 Sep14 Jun15 Jan15 9999 2.50
Wird dieser Datensatz in die Tabelle eingefügt, führt dies zu einem Fehler. Das
Produkt p1 hätte beispielsweise zum Zeitpunkt April 2015 zwei unterschiedliche Prei-
se, es kann nicht geprüft werden, welcher der korrekte Preis ist. Diese Fehlerart wird
als „overlapping versions“ [JW10] bezeichnet. Um diesen Fehler verhindern zu kön-
nen, müssen temporale Erweiterungen an den Integritätsbedingungen der Datenbank
vorgenommen werden.
Eine weitere Vielzahl an Bedingungen müsse laut Johnston bei Einfügen, Ändern
oder Löschen von bi-temporalen Daten beachtet werden. Beispielsweise seien die Be-
dingungen für kaskadierende Löschvorgänge sehr komplex, wenn Zeilen in temporalen
Tabellen betroffen sind. Ebenso entstehen komplexe Probleme bei Einfügen von Da-
tensätzen mit referentieller Integrität zu temporalen Daten. Weiterhin würden beim
Schreiben von Anfragen, bei denen sich die Zeitperioden überschneiden, häufig Pro-
bleme auftreten. Weitere Probleme gäbe es beim Zusammenführen von bi-temporalen
Tabellen, oder beim Zusammenführen von temporalen und nicht-temporalen Tabellen.
Johnston ist der Meinung, die aktuellen Entwicklungen „adressieren nur die Spitze des
Eisbergs der Komplexität vom temporalen Datenmanagement“2 .
2
Eigene Übersetzung: „adresses only the tip of the iceberg of temporal data management
complexities“[JW10],S.8
13
3.3. Unterschiedliche Bezeichnungen für logische und physische

Zeit
In der Historie wurden unterschiedliche Entwicklungen im Bereich des temporalen Da-

tenmanagements veröffentlicht. Die Unterschiede beziehen sich nicht nur auf die Art
der Modellierung der Datenbanksysteme, sondern auch auf die benutzte Terminolo-
gie. Dieser Abschnitt soll die unterschiedlichen Bezeichnungen für die logische und
physische Zeit aufzeigen und eine einheitliche Begriffsgrundlage für bi-temporale Mo-
dellierung schaffen.
Im Jahr 1992 wurde erstmals ein standardisiertes Glossar über temporale Daten-
modellierung verfasst [JCG+ 92], welches 1998 erweitert wurde [JDB+ 98]. In diesen
Standards werden die zwei Dimensionen von bi-temporalen Daten als „valid time“
und „transaction time“ bezeichnet. Die valid time ist die Zeitangabe, „in der ein Fakt
wahr in der modellierten Realität ist“. Sie bezeichnet somit die logische Zeit. Ein Fakt
beschreibt den Zustand eines Sachverhaltes in der Realität. Die transaction time be-
zeichnet die Zeit, „in der ein Fakt in der Datenbank gespeichert wird“. Sie definiert
daher die physische Zeit eines Datensatzes. Beide Zeiten werden als Zeitperioden mo-
delliert. Der Anfangszeitpunkt der transaction time wird mit Einfügen eines Datensat-
zes in die Datenbank gespeichert. Bei Änderung oder Löschen eines Datensatzes wird
der Originaldatensatz nicht überschrieben oder gelöscht, sondern der Endzeitpunkt
der transaction time wird auf den Zeitpunkt der Aktion gesetzt. Bei einer Änderung
wird eine Kopie des Originaldatensatzes mit der vollzogenen Änderung als neuer Da-
tensatz angelegt. Dieser erhält den Zeitpunkt der Aktion als Anfangszeitpunkt für die
transaction time.
Die Entwickler von IBM haben 2010 [BGK+ 10] eine andere Terminologie für diese
Zeiten gewählt. In diesem Standard wird die logische Zeit als „business time“ und
die physische Zeit als „system time“ bezeichnet. Beide Zeiten werden ebenfalls als
Zeitperioden angegeben.
Im aktuellen SQL-Standard (ISO 9075:2011) wird die Bezeichnung der physischen
Zeit aus dem IBM-Standard übernommen. Die logische Zeit wird mit „application
time“ benannt.
Johnston und Weis führen in ihrem Buch [JW10] zwei weitere Begriffe für diese
Zeiten ein. Für die logische Zeit wählen sie den Begriff der „effective time“, für die
physische Zeit die „assertion time“. Mit der assertion time wird erstmals eine Erwei-
terung der bisherigen Terminologie geschaffen. Mit system time und transaction time
war es möglich Datensätze zu erstellen, deren Aussage zum aktuellen Zeitpunkt entwe-
der wahr oder falsch ist. Mit der assertion time können nun auch Datensätze eingefügt
werden, deren Aussage erst in der Zukunft als wahr angenommen wird [JW10].
Im Jahr 2014 ändert Johnston mit seiner Veröffentlichung [Joh14] die Terminologie
ein weiteres Mal. Er wählt nun statt der effective time den Begriff der „state time“
für die logische Zeit. Seiner Meinung nach wäre dies der Begriff, der am wenigstens
14
3.4. Die Beziehungen nach Allen
missverstanden werden könne.

Um eine einheitliche Begriffsgrundlage in dieser Arbeit zu erhalten, werden logische
und physische Zeit mit state time und assertion time bezeichnet. Diese Wahl wird
aufgrund der Aktualität, des besseren Verständnisses und der erweiterten Modellie-
rungsmöglichkeit getroffen.
Die folgende Tabelle 3.3 zeigt die Terminologie noch einmal im Überblick:
TSQL2 SQL ISO SQL IBM Stan- MTRD Bitemporal

Standard Standard dard [JW10] Data [Joh14]
application
valid time business time effective time state time
time
transaction
system time system time assertion time assertion time
time
application-
valid-time effective-time state-time
— period
relation table table
temporal table
transaction- system-period system-period assertion-time assertion-time
time relation temporal table temporal table table table
Tabelle 3.3.: Terminologie zu bi-temporaler Modellierung3
Alle Terminologien stimmen in der Definition von nicht-, uni- und bi-temporalen
Tabellen überein. Nicht-temporale Tabellen enthalten keine Zeitdimension. Sie werden
häufig auch als konventionelle Tabellen bezeichnet [Joh14]. Eine uni-temporale Tabelle
enthält entweder die physische oder die logische Zeit. Die Zeilen 3 und 4 in der Tabelle
3.3 zeigen die Bezeichnung für eine solche Tabelle je nach verwendeter Zeitdimension.
Eine bi-temporale Tabelle enthält genau eine Zeitperiode aus beiden Zeitdimensionen.

Eine Zeitperiode z1 kann länger oder kürzer als eine andere Zeitperiode z2 sein, oder sie
können beide gleich lang sein. Die eine Zeitperiode kann vor der anderen beginnen oder
enden, oder ihr Anfangs- oder Endzeitpunkt ist der gleiche. Die Zeitperioden können
eine zeitliche Lücke zwischen sich haben oder direkt aufeinanderfolgen. Um alle diese
Beziehungen komplett ausdrücken zu können, werden die Beziehungen nach Allen
[All83] verwendet. Allen hat bereits 1983 eine Liste von Operatoren angelegt, die je
zwei Zeitperioden z1 und z2 in ihrer zeitlichen Beziehung darstellen. Die Liste deckt alle
möglichen Fälle ab und eine Beziehung wird von genau einem Operator ausgedrückt.
3
geänderte Abbildung aus [Joh14] S. 32
15
Ein logischer Beweis dafür kann in [JW10] nachgelesen werden. Die Operatoren sind
für die temporale Integrität der Datenbanken von zentraler Bedeutung und werden
daher in diesem Abschnitt erläutert.
Die grundlegenden Beziehungen nach Allen sind [starts], [finishes], [equals], [during],
[overlaps], [before] und [meets]. Insgesamt gibt es 13 Beziehungen, da es für alle Bezie-
hungen außer [equals] eine gegenseitige Beziehung gibt, die mit einem „-1“ ausgedrückt
wird. Für die Beziehung [starts] ist dies beispielsweise [starts−1 ].
Im Folgenden werden diese Beziehungen erläutert. Anschließend werden sie in eine
Taxonomie eingeordnet. Zur Illustration der grundlegenden Beziehungen werden zwei
Datensätze für einen Kunden als Beispiel gezeigt. Die Datensätze haben die Form:
[Anfangszeitpunkt | Endzeitpunkt | Kundennummer | Name | Wohnort]
Die Beziehung [starts] drückt aus, dass beide Zeitperioden z1 und z2 den gleichen
Anfangszeitpunkt haben, aber z1 vor z2 endet. Diese Beziehung ist daher nur zwischen
Zeitperioden möglich, welche eine ungleiche Dauer haben.
Ein Beispiel für die Beziehung [starts]:
[ Jan15 | Mär15 | K1 | Müller | Paderborn ]
[ Jan15 | Jun15 | K1 | Müller | Bielefeld ]
In diesem Beispiel beginnen z1 und z2 gleichzeitig, z1 endet 3 Zeiteinheiten vor z2 . Da
die Datensätze die gleiche Entität beschreiben (K1), ist ein gleichzeitiges Auftreten
der Beziehung [starts] in der Datenbank nicht erlaubt. Ansonsten würde das Problem
der overlapping versions entstehen, da beide gegensätzliche Aussagen über die Entität
treffen. Die gegensätzliche Beziehung [starts−1 ] drückt aus, dass z1 und z2 gleichzeitig
beginnen, z2 allerdings vor z1 endet.
Die Beziehung [finishes] drückt aus, dass zwei Zeitperioden z1 und z2 gleichzeitig
enden, aber z1 früher als z2 beginnt. Auch diese Beziehung ist daher nur zwischen
ungleich langen Zeitperioden möglich.
Ein Beispiel für die Beziehung [finishes]:
[ Nov14 | Mai15 | K2 | Meier | Berlin ]
[ Dez14 | Mai15 | K2 | Meier | München ]
Hier beginnt z1 eine Zeiteinheit vor z2 , beide Zeitperioden enden gleichzeitig. Auch
der Eintrag dieser beiden Datensätze würde zu overlapping versions führen, diese Be-
ziehung wird für die gleiche Entität ebenfalls nicht in der Datenbank erlaubt. Die
gegensätzliche Beziehung [finishes−1 ] steht für zwei Zeitperioden z1 und z2 , die gleich-
zeitig enden, z2 allerdings vor z1 beginnt.
Die Beziehung [during] beinhaltet zwei Zeitperioden z1 und z2 für die gilt, dass die
Zeiteinheiten aus z1 komplett in z2 enthalten sind. Dabei muss z2 früher als z1 beginnen
und später als z1 enden. Der Anfangs- und Endzeitpunkt beider Zeitperioden darf nicht
identisch sein.
16
Ein Beispiel für die Beziehung [during]:

[ Mai14 | Sep14 | K3 | Friedrich | Dresden ]
[ Jan14 | Dez14 | K3 | Friedrich | Frankfurt ]
Bei diesen Datensätzen liegt die Zeitperiode z1 komplett in der Zeitperiode z2 . Z2
beginnt 4 Zeiteinheiten vor z1 und endet 3 Zeiteinheiten nach z1 . Da beide Datensätze
gegensätzliche Aussagen über die gleiche Entität (K3) treffen, ist auch diese Beziehung
für gleiche Entitäten mit unterschiedlichen Aussagen in der Datenbank untersagt. Die
Beziehung [during−1 ] drückt das genaue Gegenteil aus: z2 findet komplett während z1
statt.
Die Beziehung [equals] steht für zwei Zeitperioden z1 und z2 , die den gleichen
Anfangs- und Endzeitpunkt haben. Diese Zeitintervalle müssen somit gleich lang sein,
da Zeitperioden als durchgängig definiert wurden und keine zeitlichen Lücken enthal-
ten.
Zwei Beispieldatensätze, die die Beziehung [equals] erfüllen:
[ Jan14 | Mai15 | K4 | Meister | Aachen ]
[ Jan14 | Mai15 | K4 | Meister | Hamburg ]
Beide Datensätze enthalten die gleichen Zeitpunkte. Erneut ist diese Beziehung bei
widersprüchlichen Aussagen zur gleichen Entität verboten. Für [euqals] gibt es keine
gegensätzliche Beziehung, da diese exakt die gleiche Bedeutung haben würde.
In der Beziehung [overlaps] enthält jede der Zeitperioden z1 und z2 Zeitpunkte,

die in der jeweils anderen nicht enthalten sind. Gleichzeitig haben die zwei Zeitpe-
rioden mindestens einen Zeitpunkt gemeinsam. Die Zeitperioden können gleich oder
unterschiedlich lang sein.
Dieses Beispiel zeigt Datensätze, die in [overlaps]-Beziehung stehen:
[ Feb14 | Mär15 | K5 | Peters | Bremen ]
[ Jan15 | Jul15 | K5 | Peters | Düsseldorf ]
Die Zeitperioden z1 und z2 enthalten beide die Monate Januar und Februar 2015.
z1 enthält die Monate Februar bis Dezember 2014, die nicht in z2 enthalten sind. z2
hingegen beinhaltet die Monate März bis Juni 2015, die nicht in z1 enthalten sind.
Da beide Datensätze gegensätzliche Aussagen über den gleichen Kunden (K4) in den
Monaten Januar und Februar treffen, führt diese Überschneidung zu overlapping ver-
sions und muss als Beziehung in der Datenbank verhindert werden. Die gegensätzliche
Beziehung [overlaps−1 ] dreht die Bedeutung für zwei Zeitperioden um: z2 beginnt vor
z1 , z1 beginnt während z2 und endet später als z2 .
Die Beziehung [before] drückt aus, dass die Zeitperiode z1 komplett vor der Zeit-
periode z2 stattfindet. Dabei existiert eine zeitliche Lücke zwischen dem Endzeitpunkt
17
von z1 und dem Anfangszeitpunkt von z2 . Durch diese Bedingung haben beide Zeit-
perioden keinen gemeinsamen Zeitpunkt. Die Länge der Zeitperioden ist für diese
Beziehung nicht relevant.
Folgendes Beispiel zeigt zwei Datensätze in der [before]-Beziehung:
[ Jan14 | Mär14 | K6 | Schmidt | Hameln ]

[ Mai14 | Aug15 | K6 | Schmidt | Dortmund ]
Die Datensätze sagen aus, dass der Kunde K6 mit Namen Schmidt von Januar
bis März 2014 in Hameln wohnte, und von Mai 2014 bis August 2015 in Dortmund
wohnte. Es wird keine Aussage darüber getroffen, wo Herr Schmidt in den Monaten
März und April 2014 gewohnt hat. Bei diesen Datensätzen liegt z1 zeitlich vor z2 .
Zwischen beiden Zeitperioden gibt es eine zeitliche Lücke von 2 Monaten. Für die
[before]-Beziehung ist eine Zeitlücke von mindestens einem Zeitpunkt notwendig. Der
zweite Datensatz dürfte somit erst im April 2014 beginnen. Diese Beziehung ist in einer
Datenbank erlaubt, da die Datensätze Aussagen zum gleichen Kunden zu verschiede-
nen Zeitpunkten treffen. Durch die voneinander getrennten Zeitperioden werden keine
gegensätzlichen Aussagen getroffen. Die Beziehung [before−1 ] spiegelt die Bedeutung:
Hier findet z2 komplett vor z1 statt.
Die letzte Beziehung [meets] ist die wichtigste Beziehung. Bei ihr wird die zeitliche
Lücke aus der [before]-Beziehung verboten. Bei [meets] findet die Zeitperiode z1 vor
z2 statt und der Endzeitpunkt von z1 liegt zeitlich exakt vor dem Anfangszeitpunkt
von z2 . Es ist keine zeitliche Lücke zwischen z1 und z2 erlaubt.
Dieses Beispiel verdeutlicht die [meets]-Beziehung:
[ Jan15 | Mär15 | K7 | König | Bonn ]

[ Mär15 | Aug15 | K7 | König | Paderborn ]
In diesem Beispiel wohnte Herr König (K7) von Januar bis Februar 2015 in Bonn,
und anschließend von März bis August 2015 in Paderborn. Durch die closed/open-
Sichtweise kann sofort erkannt werden, dass der Endzeitpunkt von z1 direkt vor dem
Anfangszeitpunkt von z2 liegt, da beide die gleichen Werte (März 2015) aufweisen.
Die Historie von Herrn König hat somit keine zeitliche Lücke im betrachteten Zeit-
raum. Diese Beziehung wird in der Datenbank erlaubt, da beide Datensätze Aussagen
zur gleichen Entität über unterschiedliche Zeitperioden treffen. Diese Beziehung wird
meistens sogar gewünscht, um eine komplette Historie der Entität sicherzustellen. Die
gegensätzliche Beziehung [meets−1 ] vertauscht die Zeitperioden: Hier findet z2 vor z1
statt und der Endzeitpunkt von z2 liegt zeitlich exakt vor dem Anfangszeitpunkt von
z1 .
Für jede der Beziehungen nach Allen wurde von Johnston [Joh14] eine allgemeine
Form der Beziehung erstellt. Er definiert für jede Beziehung eine Form, welche die
18
grundsätzliche und die gegensätzliche Bedeutung vereint. Er entwickelte diese Defi-

nition, da es in der Praxis meist nicht relevant sei, welche der beiden Beziehungen
zutrifft. Folgendes Beispiel dient der Illustration: Für die Beziehungen [during] und
[during−1 ] definiert er die allgemeine Form [During]. Diese drückt aus, dass entweder
[during] oder [during−1 ] für zwei Zeitperioden z1 und z2 gilt. Das bedeutet, dass ent-
weder z1 während z2 oder z2 während z1 stattfindet.
Um abschließend einen zusammenfassenden Überblick aller Beziehungen zu erhalten,

werden diese in Abbildung 3.2 als Taxonomie dargestellt. Die Taxonomie ist gleichzei-
tig eine binäre Aufteilung in Baumdarstellung, wobei die Beziehungen nach Allen die
Blätter sind.
Abbildung 3.2.: Taxonomie der Beziehungen nach Allen4
Zunächst wird zwischen den Fällen [Includes] und [Excludes] unterschieden: [Inclu-
des] beinhaltet alle Beziehungen, deren Zeitperioden sich mindestens einen Zeitpunkt
teilen. [Excludes] enthält alle Beziehungen, in denen Zeitperioden keine gemeinsamen
Zeitpunkte haben.
Bei [Includes] wird unterschieden zwischen [Overlaps] und [Contains]. [Overlaps]
enthält Zeitperioden, bei denen beide Zeitperioden Zeitpunkte besitzen, die das andere
4
Johnston, [Joh14], S.113
19
Zeitintervall nicht beinhaltet. [Contains] fasst die Beziehungen zusammen, bei denen
eine Zeitperiode mindestens alle Zeitpunkte der anderen enthält.
[Equals] ist der Fall, bei dem alle Zeitpunkte der Zeitperioden identisch sind. Die
Beziehung [Encloses] enthält die Fälle, bei denen mindestens eine Zeiteinheit nicht in
beiden Zeitperioden enthalten ist.
Diese Fälle sind einerseits mit [AlignsWith] Zeitperioden, bei denen Anfangs- oder
Endzeitpunkt gleich ist. Andererseits gibt es den Fall, dass eine Zeitperiode komplett
in einer anderen enthalten ist: die [During]-Beziehung.
In [AlignsWith] sind die Beziehungen [Starts] und [Finishes] enthalten, also entweder
Anfangszeitpunkt oder Endzeitpunkt der Zeitperioden sind identisch.
Die Beziehungen, die [Excludes] enthält, sind [Before] und [Meets]. [Before] enthält
Zeitperioden, die zeitlich durch eine Lücke getrennt sind. [Meets] enthält die Zeitperi-
oden, die direkt aufeinanderfolgen.
3.5. Konzept der temporalen Integrität

Zwei der Grundbedingungen für korrekte Datenspeicherung in relationalen Datenban-
ken sind die Entitätsintegrität und die referentielle Integrität. Die Entitätsintegrität
fordert die Eindeutigkeit eines Datensatzes in einer Tabelle. Dies wird durch Setzen
von eindeutigen und einzigartigen Primärschlüsseln garantiert. Die referentielle Inte-
grität fordert, dass ein Datensatz nur auf einen existierenden Datensatz verweisen darf.
Diese Eigenschaft wird durch die korrekte Deklaration von Fremdschlüsseln erfüllt.
Diese zwei Bedingungen treffen gleichermaßen auf temporale Tabellen zu. Die En-
titätsintegrität muss erzwungen werden, um gegensätzliche Aussagen zu einer Entität
in der Datenbank zu verhindern. Die referentielle Integrität wird dazu eingesetzt, Be-
ziehungen zu Entitäten in einer Datenbank so lange zu verhindern, bis diese auch in
der Datenbank existieren. Im Folgenden sollen diese Bedingungen für bi-temporale
Tabellen näher erläutert werden.
Zur Erklärung ist eine Darstellung von bi-temporalen Daten in einem dreidimen-
sionalen Raum hilfreich. Eine relationale Tabelle stellt in diesem Raum einen Würfel
dar, jede Zeile in der Tabelle ist eine Scheibe in diesem Würfel. Der drei-dimensionale
Raum ist in Abbildung 3.3 anhand einer Kundentabelle dargestellt. Jede Scheibe re-
präsentiert einen Kunden. In einer nicht-temporalen Tabelle würde jede Scheibe genau
eine Zeile enthalten. In einer temporalen Tabelle hingegen kann jede Scheibe mehrere
Zeilen enthalten, solange diese dieselbe Entität beschreiben. Die X-Achse des Raumes
repräsentiert die state time, die Y-Achse die assertion time.
Entscheidend für die Umsetzung der Integritätsbedingungen ist, dass die Zeiteinhei-
ten der Zeitdimensionen vergleichbar sind. Daher muss eine einheitliche Granularitäts-
stufe gewählt werden. Dies wird benötigt, damit jede Koordinate einer Scheibe den
gleichen Zeitpunkt beschreibt, wie die gleiche Koordinate auf einer anderen Scheibe.
Wenn die Zeitpunkte nicht vergleichbar sind, kann keine Integritätsbedingung imple-
20
3.5. Konzept der temporalen Integrität
Abbildung 3.3.: Dreidimensionaler Raum einer bi-temporalen Kundentabelle5
mentiert werden [Joh14].

Die kleinste bi-temporale Einheit, die in diesem dreidimensionalen Raum definiert
werden kann, ist eine einzelne Zelle mit einer Zeiteinheit in der Breite und einer Zeit-
einheit in der Höhe. In Abbildung 3.4 wird diese kleinste Einheit in einer Scheibe des
Würfels dargestellt. Die assertion time wird mit A markiert, die state time mit S. Der
Datensatz hat in beiden Zeitdimensionen eine Zeitdauer von einem Monat. Im Beispiel
beginnt die Zeitrechnung beider Dimensionen im Januar 2014. Die bi-temporale Zelle
repräsentiert mit Kunde K2 folgenden beispielhaften Datensatz:
[ Mai14 | Jun14 | Jan15 | Feb15 | K2 | König | Bonn ]
Wenn bi-temporale Daten lediglich in einzelnen Zellen repräsentiert werden würden,

dann könnte die bi-temporale Entitätsintegrität mit den gleichen Mechaniken wie bei
konventioneller Entitätsintegrität realisiert werden, nämlich mit der Einzigartigkeit
des Primärschlüssels.
Allerdings werden bi-temporale Daten nicht als einzelne Zellen gespeichert, dies
würde den Speicherbedarf für die Tabellen um ein hohes Maß erhöhen. Effizientere
Speicherung ist möglich, wenn zwei Zeilen zu einer einzelnen Zeile zusammengefügt
werden können. Für das Zusammenfügen müssen zwei Zeilen folgende fünf Bedingun-
gen einhalten: Sie müssen in derselben Tabelle und in derselben Scheibe stehen, das
heißt sie repräsentieren die gleiche Entität. Weiterhin muss die Aussage über die En-
5
geänderte Abbildung aus Johnston, [Joh14], S.118
21
Abbildung 3.4.: Kleinste bi-temporale Einheit6
tität in Form der Daten identisch sein. Letztendlich müssen die assertion time sowie
die state time beider Zeilen in der [Meets]-Beziehung zueinander stehen.
Nehmen wir im Beispiel an, der Kunde K2 heißt im folgenden Monat weiterhin
König und wohnt in Bonn. Damit enthält die Tabelle folgende zwei Datensätze:
[ Mai14 | Jun14 | Jan15 | Feb15 | K2 | König | Bonn ]
[ Mai14 | Jun14 | Feb15 | Mär15 | K2 | König | Bonn ]
Diese Datensätze halten alle fünf Bedingungen ein und können daher zusammenge-
fügt werden:
[ Mai14 | Jun14 | Jan15 | Mär15 | K2 | König | Bonn ]
In Abbildung 3.5 wird der zusammengefügte Datensatz grafisch dargestellt. Durch

das Zusammenfügen von den zwei Datensätzen entsteht ein Rechteck. Die horizontale
Seite des Rechtecks beschreibt die Zeitperiode der assertion time. Die vertikale Seite
beschreibt die Zeitperiode der state time.
6
22
3.6. Bi-temporale Entitätsintegrität
Abbildung 3.5.: Zusammengefügte bi-temporale Zellen7
In den folgenden zwei Abschnitten werden Entitätsintegrität und referentielle Inte-

grität mit dem Fokus auf bi-temporale Daten näher erläutert.

Die bi-temporale Entitätsintegrität in einer Datenbank ist die Forderung, dass jede
bi-temporale Tabelle folgende Eigenschaft erfüllt: Es existiert kein Zustand, in dem
zwei oder mehr Zeilen mit der selben ID in der selben bi-temporalen Zelle stehen.
Jede Zeile in einer bi-temporalen Tabelle beschreibt eine Fläche, die das kartesi-
sche Produkt aus den Zeitperioden der assertion time und der state time ist [Joh14].
Aktuelle Datenbankmanagementsysteme garantieren, dass die assertion time einer bi-
temporalen Transaktion immer mit dem Zeitpunkt der Transaktion beginnt. Die as-
sertion time wird standardmäßig als offene Zeitperiode implementiert, sie wird vom
System ohne Zugriff des Anwenders automatisch zugewiesen. Die state time wird,
wenn keine Angabe in der Transaktion getätigt wird, ebenfalls automatisch auf den
aktuellen Zeitpunkt gesetzt. Es ist jedoch möglich, einen abweichenden Wert für die
state time anzugeben.
7
23
Anhand von Beispieltransaktionen soll die temporale Entitätsintegrität erklärt wer-

den. Wir nehmen an, unsere Kundentabelle enthält folgenden Datensatz:
abt aet sbt set K-ID Name Wohnort

Mai15 9999 Mai15 9999 K1 Baumann Steinheim
Der Datensatz wurde zum Zeitpunkt Mai 2015 eingefügt. Sowohl assertion time als
auch state time sind als offene Zeitperioden implementiert, da noch nicht bekannt ist,
wann sich die Informationen des Kunden ändern werden. In Abbildung 3.6 wird dieser
Datensatz grafisch dargestellt. Die Pfeile oben und rechts an der Fläche zeigen eine
offene Zeitperiode an.
Abbildung 3.6.: Bi-temporale Fläche für Beispieldatensatz zu K18
Es wird nun der Fall betrachtet, dass eine zusätzliche Zeile für den Kunden K1 einge-
fügt werden soll, unabhängig von den angegebenen Daten. Dazu nehmen wir Juli 2015
als aktuellen Zeitpunkt an. Eine Zeile darf nicht rechts oder oberhalb der bisherigen
Fläche in Abbildung 3.6 eingefügt werden, da ansonsten die temporale Entitätsinte-
grität verletzt werden würde. Ebenfalls kann auch keine Zeile in den unteren linken
oder unteren rechten Quadranten eingefügt werden, da der jetzige Zeitpunkt später als
Januar 2015 ist. Das Einfügen eines neuen Datensatzes mit vergangener assertion time
8
24
ist nicht möglich. Die einzige Möglichkeit einen neuen Datensatz für K1 einzufügen ist
im oberen linken Quadranten, somit für eine state time früher als Mai 2015.
Die assertion time des neuen Datensatzes wird vom Datenbanksystem automatisch
auf [Jul15-9999] gesetzt. Da der bisherige Datensatz die assertion time [Mai15-9999]
hat, steht er in [Contains]-Beziehung zum neuen Datensatz. Daher können neuer und
existierender Datensatz nur über die state time verglichen werden [Joh14]. Durch die
temporale Entitätsintegrität gibt es Einschränkungen für die Zeitperiode der state
time. Dies soll anhand folgender Beispiele verdeutlicht werden. Die erste Zeitperiode
steht für die assertion time, die zweite für eine beispielhafte state time. In der letzten
Spalte wird gezeigt, in welcher Beziehung die state time von neuem zu existierendem
Datensatz stehen würden.
[Jul15-9999] [Mai15-9999] [Equals]

[Jul15-9999] [Mai15-Aug16] [Starts]
[Jul15-9999] [Mai15-9999] [Finishes]
[Jul15-9999] [Jan13-9999] [Finishes]
[Jul15-9999] [Jul15-Aug15] [During]
[Jul15-9999] [Mär14-Sep15] [Overlaps]
[Jul15-9999] [Feb14-Mai15] [Meets]

[Jul15-9999] [Dez12-Feb13] [Before]
[Jul15-9999] [Feb14-Apr15] [Before]
Die Beziehungen der ersten sechs Datensätze sind [Includes]-Beziehungen. Dadurch

beschreiben diese Datensätze zu mindestens einem Zeitpunkt eine gegensätzliche Aus-
sage zum existierenden Datensatz. Das Einfügen dieser Datensätze würde somit die
temporale Entitätsintegrität verletzen.
Die Beziehungen der letzten drei Datensätze hingegen sind [Excludes]-Beziehungen.
Ein Einfügen eines solchen Datensatzes ist erlaubt. Als Beispiel wird nun ein Da-
tensatz für Kunde K1 eingefügt, mit den Werten der Zeitperioden vom letzten oben
angegebenen Beispiel. Er hatte in dieser Zeit seinen Wohnsitz in Höxter. Dies wird in
Abbildung 3.7 grafisch dargestellt.
25
Abbildung 3.7.: Bi-temporale Flächen nach Einfügen von neuem Datensatz9
Nach dem Einfügen des neuen Datensatzes hat die Kundentabelle nun diese Form:

Mai15 9999 Mai15 9999 K1 Baumann Steinheim
Jul15 9999 Feb14 Apr15 K1 Baumann Höxter
Weiterhin wird nun der Fall betrachtet, dass eine Änderung des ersten Datensatzes
im Oktober 2015 getätigt werden muss. Der Kunde K1 soll nun den Namen Baumann-
Ludwig tragen und in Rietberg wohnen. Es wird erneut eine offene Zeitperiode ange-
nommen.
Bei dieser Transaktion muss beachtet werden, dass der neue Datensatz keine Aus-
sage über Zeitpunkte vor Oktober 2015 tätigt. Da der zweite Datensatz in [Before]-
Beziehung zur Änderung steht, ist er von der Transaktion nicht betroffen und bleibt
unverändert in der Datenbank. Der erste Datensatz hingegen muss verändert werden,
da ansonsten die temporale Entitätsintegrität verletzt werden würde. Da der erste Da-
tensatz ab Oktober 2015 eine falsche Aussage macht, wird die Endzeit der assertion
time auf Oktober 2015 gesetzt. Die closed/open-Sichtweise ermöglicht eine vereinfach-
te Änderung, da nur der Zeitpunkt der Änderungs-Transaktion übernommen werden
muss. Es muss ein zusätzlicher Datensatz für die Zeit zwischen Mai und Oktober
2015 eingefügt werden, da in dieser Zeit die Aussage des ersten Datensatzes wahr
9
26
gewesen ist. Die assertion time dieses Datensatzes ist der Zeitpunkt der Änderungs-
Transaktion. Abschließend wird ein Datensatz eingefügt, der die neuen Informationen
beinhaltet. Die Kundentabelle sieht nach Ausführen der Transaktion so aus:

Mai15 Okt15 Mai15 9999 K1 Baumann Steinheim
Jul15 9999 Feb14 Apr15 K1 Baumann Höxter
Okt15 9999 Mai15 Okt15 K1 Baumann Steinheim
Okt15 9999 Okt15 9999 K1 Baumann-Ludwig Rietberg
Die Abbildung 3.8 zeigt die Auswirkungen der Änderung grafisch. Die Bezeichnung
R* steht für die jeweilige Reihe in der Tabelle.
Abbildung 3.8.: Bi-temporale Flächen nach Änderung eines Datensatzes10
Das Löschen von Informationen eines Datensatzes in einer bestimmten Zeitperiode

ist lediglich ein Spezialfall der Änderung und kann daher weniger ausführlich erläutert
werden. Beim Löschen eines Datensatzes wird der Endzeitpunkt der assertion time
auf den Zeitpunkt der Transaktion gesetzt. Hier muss analog zur Änderung beachtet
werden, dass Informationen von Zeitpunkten, die nicht vom Löschen betroffen sind,
weiterhin gültig bleiben. Wird ein Datensatz zeitlich gesehen nur teilweise gelöscht,
10
27
so wird wie bei der Änderung ein zusätzlicher Datensatz mit den weiterhin gültigen
Informationen eingefügt.
Beachtet der Anwender bei Erstellung von Anfragen diese Regeln bei Einfügen,
Ändern und Löschen von Datensätzen in bi-temporalen Tabellen, so kann durch die
temporale Entitätsintegrität garantiert werden, dass keine gegensätzlichen Aussagen
zur selben Entität im selben Zeitraum in der Tabelle enthalten sind.
3.7. Bi-temporale referentielle Integrität

Die bi-temporale referentielle Integrität ist die Forderung, dass eine Fremdschlüssel-
Beziehung zu einer Entität nur dann möglich ist, wenn die referenzierte Entität E über
die gesamte Zeitdauer der referenzierenden Entität K existiert. Dies ist nur möglich,
wenn die bi-temporale Fläche der Entität K vollständig in der bi-temporalen Fläche
von E enthalten ist, somit in [contains]-Beziehung zu ihr steht [Joh14].
Um die bi-temporale referentielle Integrität näher erläutern zu können, werden zu-
nächst zwei wichtige Konzepte erklärt: Temporale Fremdschlüssel und Episoden.
Konventionelle Fremdschlüssel beschreiben eine Beziehung von ein oder mehreren

Zeilen der referenzierenden „child table“ zu genau einer Zeile in der referenzierten
„parent table“ [Joh14]. Bi-temporale Fremdschlüssel hingegen verweisen von der child
table zu einer oder mehreren Zeilen in der parent table.
Als Beispiel wählen wir die zuvor erstellte Kundentabelle und eine neu erstellte
Vertragstabelle, in der Informationen zu Verträgen in Verbindung mit den jeweiligen
Kunden gespeichert werden. Die Spalte esbt beschreibt die „episode state begin time“
und wird erst später verwendet.
Kundentabelle
abt aet sbt set K-ID Name Wohnort esbt
Mai15 Okt15 Mai15 9999 K1 Baumann Steinheim Mai15
Jul15 9999 Feb14 Apr15 K1 Baumann Höxter Feb14
Okt15 9999 Mai15 Okt15 K1 Baumann Steinheim Mai15
Okt15 9999 Okt15 9999 K1 Baumann-Ludwig Rietberg Mai15
Vertragstabelle
abt aet sbt set V-ID F_K-ID V-Typ Rate esbt
Mai15 9999 Mai15 9999 V1 K1 Pacht 380.00 Mai15
Tabelle 3.4.: Ein Beispiel für eine bi-temporale Fremdschlüsselbeziehung
Der Vertrag V1 verweist in der Spalte F_K-ID auf den Kunden K1 in der Kun-
dentabelle. Dieser Wert zeigt jedoch nicht auf eine einzigartige Zeile in der Kundenta-
belle, wie es bei konventionellen Fremdschlüsseln der Fall ist. Die Beziehung verweist
28
auch nicht auf einen Primärschlüssel, sondern nur auf den eindeutigen Identifizierer
zu Kunde K1. Eine bi-temporale Fremdschlüsselbeziehung ist daher nicht wie bei der
konventionellen eine „one-to-one-Beziehung“, sondern eine „one-to-many-Beziehung“
[Joh14].
Die Semantik der beiden Fremdschlüsselarten bleibt gleich: Die referenzierende En-
tität kann nicht existieren, solange die referenzierte Entität nicht existiert. Im Beispiel
kann kein Vertrag zu Kunde K1 bestehen, solange es keinen Kunden K1 gibt. Für die
Beziehung von V1 zu K1 ist nicht relevant, wie viele Einträge es zu K1 gibt. Es ist
lediglich relevant, dass eine kontinuierliche Beziehung zu K1 über die gesamte Lebens-
dauer von V1 existiert.
In einer one-to-many-Beziehung stellen die Entitäten der parent table eine Samm-
lung an Zeilen dar, die von der child table referenziert wird. Diese Sammlung wird von
Johnston als Episode bezeichnet [Joh14]. Eine Episode ist das zeitliche Intervall von
Entität E, in dem die Entität K auf E referenziert. Die bi-temporale Integritätsinte-
grität fordert, dass alle bi-temporalen Zellen von K in der bi-temporalen Fläche von
E enthalten sind. Somit muss K in [contains]-Beziehung zu E stehen.
Die formale Definition einer Episode einer bi-temporalen Tabelle hat folgende Be-
dingungen:
• Alle Zeilen einer Episode müssen die gleiche Entität beschreiben.

• Sie müssen eine gemeinsame assertion time-Periode haben.
• Ihre state time-Perioden müssen in chronologischer Reihenfolge in [Meets]-
Beziehung stehen.
• Es gibt keine Zeile, die folgende Bedingungen erfüllt:
– Sie beschreibt ebenfalls die selbe Entität,
– sie hat mindestens einen Zeitpunkt in der assertion time-Periode mit den
anderen Zeilen gemeinsam
– und ihre state time-Periode steht in [Meets]-Beziehung zum frühesten oder
spätesten Eintrag der übrigen Zeilen oder beinhaltet mindestens einen glei-
chen Zeitpunkt in der state time-Periode.
Durch die Definition einer Episode steht eine Entität K in der child table in one-
to-one-Beziehung zur referenzierten Episode in der parent table. Da wir durch die
bi-temporale Entitätsintegrität wissen, dass es keine Zeilen gibt, die in [Includes]-
Beziehung zueinander stehen und die selbe Entität beschreiben, können wir folgern,
dass die state time-Perioden aller Zeilen einer Episode in [meets]-Beziehung zur nach-
folgenden Zeile der Episode stehen. Das bedeutet, dass es keine zeitliche Lücke in
der state time der Episode gibt. Würde diese Lücke existieren, so würde die Episode
durch oben genannte Bedingung in zwei Episoden unterteilt werden. Eine geschlos-
sene Episode endet mit dem spätesten Endzeitpunkt der state time der enthaltenen
29
Zeilen. Eine offene Episode enthält mindestens eine Zeile, deren state time als offene
Zeitperiode definiert ist. Die Anfangszeit einer Episode ist gleich der Anfangszeit der
frühesten state time aller Zeilen der Episode. Die Endzeit der Episode wird durch den
spätesten state-time Eintrag aller Zeilen der Episode definiert.
Eine Angabe der Episode in einer temporalen Tabelle ist nicht erforderlich, da diese
jederzeit mit oben genannten Bedingungen berechnet werden könnte. Da die Anfangs-
zeit der Episode über alle Zeilen der Episode identisch ist, reicht diese Deklaration als
Spalte in einer Tabelle um die komplette Zeitperiode der Episode berechnen zu kön-
nen. Johnston ist der Meinung, dass die Kosten für den Performance-Verlust durch die
ständige Berechnung die Kosten für den Speicherplatzbedarf einer zusätzlichen Spalte
übersteigen und somit die Aufnahme der episode state begin time in eine temporale
Tabelle nötig ist [Joh14].
In der Beispieltabelle 3.4 ist diese Spalte hinzugefügt worden. Die Historie zu Kunde
K1 besteht aus zwei Episoden, da zwischen den Episoden [Feb14-Apr15] und [Mai15-
9999] eine zeitliche Lücke von zwei Zeiteinheiten existiert. Der Vertrag V1 referenziert
auf den Kunden K1, durch den Vergleich der episode state begin time kann dieser
Vertrag der zweiten Episode des Kunden zugeordnet werden. Die bi-temporale refe-
rentielle Integrität ist erfüllt, da die komplette Episode von V1 in der zweiten Episode
von K1 enthalten ist. In diesem Beispiel stehen die Episoden in [equals]-Beziehung zu-
einander, eine [contains]-Beziehung würde für die bi-temporale referentielle Integrität
ausreichen.
Die Voraussetzung für die bi-temporale referentielle Integrität ist die bi-temporale
Entitätsintegrität. Um die bi-temporale referentielle Integrität in der gesamten Daten-
bank sichern zu können, müssen bei den Transaktionen Einfügen, Ändern und Löschen
einige Bedingungen beachtet werden. Es werden nur Änderungen an den Datensätzen
betrachtet, die zu einer Änderung der Episode führen, da für eine Fremdschlüssel-
beziehung irrelevant ist, welche Daten an referenzierter oder referenzierender Entität
angehängt sind. Die Regeln bei diesen Transaktionen sollen im Folgenden erläutert
werden.
Beim Einfügen eines neuen Datensatzes in einer parent table muss die referentielle
Integrität nicht beachtet werden, da die Integrität durch Erweiterung der Episode in
der parent table nicht verletzt wird. Wenn ein neuer Datensatz in einer child table hin-
zugefügt werden soll, muss das Datenbanksystem folgendes prüfen: In der parent table
muss sich eine Episode zur referenzierten Entität befinden, die in [contains]-Beziehung
zum einzufügenden Datensatz steht. Kann die Bedingung nicht erfüllt werden, so darf
der Datensatz nicht eingefügt werden. Wenn ein Datensatz auf mehrere parent tables
verweist, muss die Bedingung für jede parent table erfüllt sein. Zu beachten ist, dass
eine Tabelle sowohl parent table als auch child table sein kann.
Bei einer Änderungs-Transaktion müssen Regeln in beiden Tabellenarten beach-
tet werden. In einer parent table ist eine Änderung an einem Datensatz nur erlaubt,
wenn weiterhin eine Episode existiert, welche die Episode der referenzierenden Enti-
30
täten enthält. In einer child table ist eine Änderung nur möglich, wenn analog zur
Einfügen-Transaktion eine referenzierte Entität in der parent table existiert, welche
die veränderte Episode enthält.
Beim Löschen eines Datensatzes in einer child table ist keine Regel zu beachten, da
hiermit nur eine zuvor gültige Fremdschlüsselbeziehung beendet wird. Die vergangene
Beziehung bleibt im System weiterhin gültig. Das Löschen eines Datensatzes in einer
parent table kann nur durchgeführt werden, wenn weiterhin die referenzierten Episo-
den in der parent table enthalten sind. Auf eine Löschanfrage, die diese Bedingung
nicht erfüllt, kann mit drei Optionen reagiert werden:
1. Die Löschen-Transaktion wird verboten und nicht ausgeführt.

2. Alle referenzierenden Datensätze werden in zwei Datensätze aufgeteilt: Der erste
Datensatz beschreibt die Fremdschlüsselbeziehung für die Zeitperiode, in der die
Beziehung weiterhin gültig ist. Der zweite Datensatz beschreibt den Rest der
ursprünglichen Zeitperiode, das Attribut in der Fremdschlüsselspalte wird jedoch
auf NULL gesetzt.
3. Alle Datensätze einer child table, die nach der Löschen-Transaktion eine ungül-
tige Fremdschlüsselbeziehung haben, werden aus der Datenbank gelöscht. Die
Datensätze werden wie bei Option 2 aufgeteilt, es werden anschließend nur die
Datensätze gelöscht, die ein NULL-Attribut in der Fremdschlüsselspalte haben.
Die Entscheidung über die zu implementierende Option muss bei der Implementie-
rung einer Fremdschlüsselbeziehung getroffen werden. Sie sollte konstant beibehalten
werden, damit die Bedeutung der Beziehung im Verlauf der Zeit nicht geändert wird.
Wenn diese Bedingungen für die Transaktionen Einfügen, Ändern und Löschen von
Datensätzen einer Fremdschlüsselbeziehung eingehalten werden, so kann in der Da-
tenbank die bi-temporale referentielle Integrität garantiert werden.
31
4. Theorie zur Modellierung mit Data Vault
Data Vault ist ein Modellierungsansatz zum Aufbau der zentralen Integrationsschicht
im data warehouse. Entwickelt wurde der Ansatz von Dan Linstedt seit den 90er
Jahren, einer der ersten Artikel wurde von ihm im Jahr 2002 veröffentlicht [Lin02].
„Die zugrundeliegende Prämisse von Data Vault ist die Unified Decomposition“1 .
Die Kombination von Dekomposition und Zusammenfügen ist das zentrale Konzept
des Ansatzes: Die Dekomposition von Teilen des data warehouse wird durchgeführt,
um eine flexible, anpassbare und agile Datenhaltung zu gewährleisten. Das Zusammen-
führen der einzelnen Teile wird eingesetzt, um eine integrierte Sicht auf die Daten zu
erhalten und die Daten präsentieren zu können. Um die einzelnen Teile in Verbindung
zu halten wird ein einheitlicher Schlüssel verwendet.
In den nachfolgenden Abschnitten werden zunächst die grundlegenden Elemente in
der Data Vault Modellierung erklärt. Diese sind „Hub“, „Link“ und „Satellit“. Weiter
werden die Unterschiede zu bisherigen Modellierungstechniken aufgezeigt. Abschlie-
ßend wird eine Bewertung des Data Vault Ansatzes durchgeführt.
4.1. Modellierung von Geschäftsobjekten: der Hub

Die Modellierung eines data warehouse mit dem Konzept Data Vault beginnt mit
der Identifikation und der Modellierung der Hubs [Hul12]. Ein Hub ist eine Tabelle,
welche Geschäftsobjekte wie zum Beispiel Kunden oder Produkte repräsentiert. Für
jede Instanz eines Geschäftsobjektes wird ein einzelner Eintrag im Hub eingefügt. Der
Hub enthält folgende Attribute:
• Den „natural business key“

• Die „data warehouse sequence ID“
• Den „load date time stamp„
• Informationen zur Quelle des Datensatzes
Der natural business key muss die Instanz des Geschäftsobjektes im gesamten Ge-
schäftsbereich eindeutig identifizieren. Der Schlüssel ist nicht von Quell-Systemen ab-
hängig, sondern wird geschäftsbasiert gebildet. Dies ist notwendig, um Daten aus meh-
reren unterschiedlichen Quellen in integrierter Form speichern zu können. Die sequence
ID wird vom data warehouse gebildet und stellt den Primärschlüssel eines Hubs dar.
1
Eigene Übersetzung: „The underlying premise behind data vault is Unified Decomposition“,
[Hul12], S. 21
33
Sie wird zur Verknüpfung von Beziehungen genutzt. Die sequence ID steht in eins-zu-
eins-Beziehung zum natural business key und ist „eine einheitlich erstellte, verwaltete
und kontrollierte Version des business keys“2 . Der load date time stamp wird zur
Speicherung der Zeit verwendet, an dem der Datensatz in das data warehouse geladen
wurde. Dieser Zeitstempel dient lediglich diesem einen Zweck und stellt kein spezielles
Attribut dar, welches zur Umsetzung von temporalen Aspekten genutzt werden kann.
Er ist somit Teil der Metadaten. Ein weiteres Attribut enthält Informationen zu den
Datenquellen als Teil der Metadaten. Hier ist auch eine größere Menge an Attributen
möglich, falls dies zur Beschreibung der Quelle nötig sein sollte. Jedoch empfiehlt sich
dann die Verwendung eines Metadatenmodells, in dem die Informationen gespeichert
werden. Es dürfen nur Attribute hinzugefügt werden, die zusätzliche Daten darstellen
und keine Bedeutung für den Geschäftsbetrieb haben. Die beiden letzten Attribute
sind technisch nicht relevant für die Funktion des Hubs, werden aber aus Komfort-
gründen hier abgespeichert [Hul12]. Der Hub enthält keine weiteren beschreibenden
Informationen und keine Fremdschlüssel.
In Abbildung 4.1 sind beispielhaft die Geschäftsobjekte Kunde und Vertrag als Hubs
modelliert. Die Attribute Kunde_Key bzw. Vertrag_Key sind natural business keys.
Sie werden aus den bisher genutzten Beispieltabellen mit K-ID und V-ID übernommen.
Die sequence ID wird jeweils vom data warehouse erstellt.
Abbildung 4.1.: Beispiele für einen Hub
4.2. Modellierung von Beziehungen: der Link

In einem Datenmodell gibt es fast immer Beziehungen zwischen den Geschäftsobjek-
ten. Diese werden in Data Vault durch die Links repräsentiert. Jeder Link beschreibt
die Existenz einer eindeutigen Beziehung. Analog zum Hub enthält der Link keine be-
schreibenden Informationen. Er besitzt keinen eigenen business key. Ein Link enthält
folgende Attribute:
• Die sequence ID von jedem an der Beziehung beteiligten Elemente

2
Eigene Übersetzung: „a consistently created, managed and controlled version of the key“, [Hul12],
S. 88
34
4.2. Modellierung von Beziehungen: der Link
• Eine eigene data warehouse sequence ID

• Den load date time stamp
Jede sequence ID der beteiligten Elemente wird als Fremdschlüssel modelliert. Ein
Link stellt nicht nur Beziehungen zwischen den Hubs dar, auch Beziehungen zwischen
Link und Link sind möglich. Der Link selbst besitzt als Primärschlüssel eine eigene
sequence ID. Diese steht in eins-zu-eins-Beziehung zur Instanz einer Geschäftsobjekt-
Beziehung. Die beiden letzten Attribute werden analog wie im Hub eingesetzt. Der
Link speichert eine Beziehung, sobald sie das erste Mal im data warehouse auftaucht.
Es müssen mindestens zwei Elemente an der Beziehung teilnehmen, eine Obergrenze
für Beziehungsteilnehmer existiert nicht.
Die Abbildung 4.2 zeigt beispielhaft die Beziehung zwischen Kunde und Vertrag.
Die sequence IDs der beiden beteiligten Hubs sind als Fremdschlüssel deklariert. Die
sequence ID wird wie beim Hub vom data warehouse erstellt.
Abbildung 4.2.: Beispiel für einen Link
Die Beziehungen in Datenmodellen haben Kardinalitäten. Beispielsweise ist ein Ver-

trag genau einem Kunden zugeordnet, ein Kunde kann mehrere Verträge haben. Die
Beziehung zwischen diesen beiden Geschäftsobjekten hätte somit die Kardinalität 1:M.
Das besondere an Data Vault ist, dass durch den reinen Link nur N:M-Beziehungen
abgebildet werden können. Dies ist an der Form des Links erkennbar: Da mindestens
zwei Geschäftsobjekte in einem Link als Fremdschlüssel deklariert werden, ist nur eine
N:M-Abbildung möglich. Die Kardinalität einer Beziehung kann durch eine Abfra-
ge zu den beteiligten Hubs sichtbar gemacht werden [Hul12]. Mit einem sogenannten
„enddating satellite“ [LG11] kann die Kardinalität eines Links sichergestellt werden.
So können auch 1:1- und 1:M-Kardinalitäten modelliert werden.
Mit dem Link werden auch rekursive Beziehungen modelliert. Dabei handelt es sich
um Geschäftsobjekte, die mit gleichen Objekten in Beziehung stehen. Diese Beziehung
wird modelliert, in dem zwei Fremdschlüssel in einem Link auf den selben Hub zei-
gen. Ein Link einer rekursiven Beziehung hat eine von zwei Arten: Entweder es ist
ein „Same-as-Link“ (SAL) oder ein „Hierarchical Link“(HAL). Ein SAL sagt aus, dass
35
beide Objekte vom selben Typ sind. Der HAL beschreibt eine hierarchische Bezie-
hung, zum Beispiel eine Eltern-Kind-Beziehung. Die Fremdschlüssel müssen dement-
sprechend benannt werden, um die jeweilige hierarchische Ebene erkennen zu können
(z.B. wer ist das Elternteil, wer ist das Kind). Eine Bezeichnung des Links mit HAL
oder SAL ist wichtig, da beide technisch eine identische Darstellung besitzen [Hul12].
4.3. Modellierung von Kontext: der Satellit

Das dritte Konstrukt in Data Vault ist der Satellit. In ihm werden alle beschreibenden
Informationen und die komplette Historie in einem Geschäftsprozess gespeichert. Der
Satellit speichert diese Informationen entweder zu einem Geschäftsobjekt oder zu einer
Beziehung, kann also sowohl zum Hub als auch zum Link in Verbindung stehen. Die
Tabelle, die einen Satellit repräsentiert, enthält keinen eigenen business key oder eine
sequence ID. Ein Satellit enthält folgende Attribute:
• Die sequence ID des zu beschreibenden Elements

• Den load date time stamp
• Die beschreibende Attribute selbst (beliebige Anzahl)
Der Primärschlüssel eines Satelliten wird aus der sequence ID des zu beschreibenden
Elements und dem load date time stamp zusammengesetzt. Die sequence ID zeigt
als Fremdschlüssel auf ein Element eines Hubs oder eines Links. Der Satellit nutzt als
einziges Konstrukt im Data Vault Ansatz eine Zeitangabe als Teil des Primärschlüssels.
Damit ist er als einziger Teil des Datenmodells in der Lage eine Historisierung zu
ermöglichen. Die Informationen zur Quelle des Datensatzes werden analog wie im Hub
oder Link verwendet. Weiterhin enthält der Link Attribute, die das Geschäftsobjekt
beschreiben sollen. Es ist eine beliebige Anzahl an Attributen möglich. Die Attribute
müssen abhängig vom zu beschreibenden Element sein, genau wie in einer Tabelle
in dritter Normalform [Hul12]. Optional kann im Satelliten das Attribut des load
end date time stamp stehen. Dieses Attribut repräsentiert die assertion end time und
markiert den Zeitpunkt, an dem der Datensatz ungültig wird bzw. wurde.
In der Abbildung 4.3 sind beispielhaft die Satelliten zu den Geschäftsobjekten Kun-
de und Vertrag abgebildet. Die sequence IDs der beteiligten Entitäten werden als
Fremdschlüssel in den Primärschlüssel des Satelliten integriert.
Es können mehrere Satelliten den selben Hub oder Link beschreiben. Die Entschei-
dung, welche Attribute in welchem Satelliten gespeichert werden, kann vom Daten-
bankmodellierer getroffen werden. Diese Entscheidungsfreiheit ermöglicht ein hohes
Maß an Flexibilität. Die Attribute könnten zum Beispiel nach folgenden Kriterien
aufgeteilt werden [Hul12]: Häufigkeit der Änderung, Informationsbereich oder Quelle
der Informationen.
36
4.3. Modellierung von Kontext: der Satellit
Abbildung 4.3.: Beispiele für einen Satellit
Ein Satellit speichert die beschreibenden Informationen nicht nur beim ersten Laden
in das data warehouse, sondern auch bei jeder Änderung eines Attributs. Jede Ände-
rung resultiert somit in einer neuen Zeile in der Satelliten-Tabelle. Dies ist analog zu
der von Kimball entwickelten SCD Typ 2 [KR02].
Die gesamte Struktur des Beispiels ist in dem Data Vault Modell in Abbildung 4.4
zusammengefasst. Eine gestrichelte Verbindung stellt eine non-identifying Beziehung,
die durchgezogene eine identifying Beziehung dar. Identifying bedeutet: ein referenzie-
render Datensatz kann ohne die referenzierte Entität nicht existieren.
Abbildung 4.4.: Beispiel für ein Data Vault Modell
37
4.4. Grundsätzliche Unterschiede zu bisherigen

Modellierungstechniken
Die Modellierung eines data warehouse mit Data Vault hat grundsätzliche Unter-
schiede zu bisherigen Modellierungsansätzen. Im Vergleich zur Modellierung in dritter
Normalform oder dem dimensional modeling werden die Tabellen strikt in business
key, Beziehungen und Kontext getrennt.
Im dimensional modeling oder der dritten Normalform würde eine Aufteilung von
Kontext-Attributen einer Entität in mehrere Tabellen zu einer Integritätsverletzung
führen: Wird ein Attribut aus einer Tabelle in dritter Normalform entfernt und in eine
andere Tabelle eingefügt, so behält die ursprüngliche Tabelle nicht mehr die dritte
Normalform. Im dimensional modeling können durch diese Umverteilung die Dimen-
sionen nicht mehr konform gehalten werden [KR02]. In der Data Vault Modellierung
spielt es hingegen für die Integrität keine Rolle, in welchem Satellit sich ein Attribut
befindet oder wie viele Satelliten an einem Element hängen. Data Vault ändert so-
mit die Sichtweise, dass alle Kontext-Attribute zu einer Entität in derselben Tabelle
stehen müssen [Hul12]. Ein weiterer Unterschied ist die Repräsentation einer Entität.
In bisherigen Modellierungsansätzen wurde eine Entität immer in genau einer Tabelle
gespeichert. In der Data Vault Modellierung werden die Informationen zu einer En-
tität auf die verschiedenen Konstrukte aufgeteilt. Somit sind sie nicht mehr in einer
Tabelle, sondern in einer Sammlung von Tabellen gespeichert [Hul12].
Im Unterschied zu anderen Modellierungen müssen laut Hultgren [Hul12] folgende
drei Eigenschaften der Konstrukte Satellit und Link beachtet werden:
Erstens definieren die Satelliten in Data Vault keine eigene Entität. Sie beschreiben
eine Entität durch ihre Attribute. Ein Satellit und somit beliebige beschreibende In-
formationen können ohne das referenzierte Element nicht existieren. Zweitens werden
alle Beziehungen durch Links modelliert. In Satelliten existieren außer dem zu be-
schreibenden Element keine Fremdschlüssel. Drittens können in Data Vault durch die
Links lediglich N:M-Beziehungen abgebildet werden. In anderen Modellierungen sind
1:M-Beziehungen hingegen möglich. Die Data Vault Modellierung erhält durch diese
Vorgehensweise jedoch keine Nachteile, da Data Vault zur Modellierung der Integrati-
onsschicht des data warehouse genutzt wird und somit lediglich eine Kopie aller Daten
darstellt, die bereits von anderen Systemen aufgenommen wurden. Das data ware-
house sei nicht dafür zuständig, Geschäftsregeln im Datenmodell abzubilden, hierfür
seien die operationalen Systeme dem data warehouse vorgelagert. Um die Kardinalität
eines Links herauszufinden, müssen Abfragen über die in Beziehung gesetzten Daten
ausgeführt werden.
Durch die Unterschiede zu bisherigen Modellierungen muss eine neue Sichtweise
eingenommen werden, um das data warehouse mit der Data Vault Modellierung auf-
zubauen. Die Vor- und Nachteile des neuen Modellierungsansatzes werden im nächsten
Abschnitt aufgeführt.
38
4.5. Bewertung der Modellierung mit Data Vault
4.5. Bewertung der Modellierung mit Data Vault

In diesem Abschnitt wird eine Bewertung der Data Vault Modellierung vorgenommen3 .
Es werden die Vor- und Nachteile von Data Vault genannt. Anschließend wird jeweils
eine Einschätzung gegeben, in welchen Fällen bzw. bei welchen Vorbedingungen die
Data Vault Modellierung Sinn macht.
Der Data Vault Modellierungsansatz ermöglicht eine schnelle Implementierung und
agile Entwicklung des data warehouse. Durch zuvor definierte Prozesse sowie Genera-
toren für ETL-Prozeduren kann ein Großteil des Systems bereits automatisch generiert
werden.
Die Architektur von Data Vault ist sehr flexibel und kann mit der Zeit ausgebaut
oder verändert werden. Einzelne Elemente können schnell angepasst werden.
Ein mit Data Vault modelliertes data warehouse bietet den Anwendern vollständig
nachvollziehbare Informationen. Die gesamten Daten im data warehouse sind einer-
seits historisiert und andererseits im Rohdatenformat abgelegt. Die Daten aus den
Quellsystemen werden über den business key konsistent integriert.
Außerdem ist der Data Vault Ansatz leicht skalierbar. Eine Umsetzung kann auf
beliebiger Infrastruktur, beliebiger Plattform und zu einem beliebigen Zeitpunkt statt-
finden.
Diese Vorteile führen insgesamt zur Reduktion der Komplexität der Datenmodellie-
rung und zur Reduktion von Kosten für die Implementierung.
Die Data Vault Modellierung eignet sich in folgenden Fällen:
• Bei Integration mehrerer Quellsysteme und bei Fällen, in denen Quellsysteme

nachträglich hinzugefügt oder verändert werden.
• Wenn vollständige Historisierung benötigt wird, um beispielsweise die Auditfä-
higkeit zu gewährleisten.
• Wenn eine flexible data warehouse Architektur benötigt wird.
• Für Lösungen von Problemen, die durch bisherige Ansätze nicht gelöst werden
können.
• Bei agilem Projektvorgehen.
Im Vergleich zu bisherigen Modellierungstechniken ist ein Nachteil an Data Vault,

dass das Datenmodell aus mehr Tabellen und die Anfragen somit aus mehr Joins be-
stehen. Dadurch erhöht sich der Aufwand für die Pflege eines solchen Systems. Das
Data Vault Modell beabsichtigt nicht den direkten Zugriff von Anwendern, da hier-
für komplexe und wenig performante Abfragen notwendig sind. Dieser Nachteil kann
durch erweiterte Konstrukte in Data Vault ausgebessert werden, diese sind allerdings
sehr komplex und müssen manuell implementiert werden. Für den Direktzugriff sollte
3
Informationen für die Bewertung stammen aus folgenden Quellen: [Hul12],[ITG]
39
das data warehouse in ein dimensional model oder in ein data mart model übersetzt
werden. Ein weiterer Nachteil ist, dass die Modellierer die Technik von Data Vault
zunächst verstehen und die Umsetzung erlernen müssen, da Data Vault eine andere
Sichtweise auf das Datenmodell beinhaltet.
In folgenden Fällen eignet sich die Data Vault Modellierung weniger:
• Bei stabilen Quellsystemen.

• Bei begrenztem Projektumfang.
• Wenn keine Enterprise-Sicht auf die Daten benötigt wird.
• Historisierung oder Auditfähigkeit wird nicht benötigt.
Die beste Vorgehensweise der Modellierung eines data warehouse hängt somit von
verschiedenen Faktoren ab. Vor- und Nachteile müssen je nach Projekt gegeneinander
abgewogen und für die spezielle Situation bewertet werden.
40
5. Praktische Entwicklungen zur bi-temporalen
Historisierung in Data Vault
Dieses Kapitel befasst sich mit der praktischen Anwendung der theoretischen Grund-
lagen. Das erste Ziel der Entwicklungen ist die Umsetzung der bi-temporalen Histori-
sierung in Data Vault. Dazu wird ein Datenmodell entwickelt, welches die Grundlage
für alle weiteren Entwicklungen bildet. Das Modell wird für Quellsystem und Staging-
Datenbank erstellt und in ein Data Vault Modell transformiert. Anschließend wird der
ETL-Prozess zum Integrieren der Quelldaten in das data warehouse modelliert und
ausführlich getestet. Im letzten Abschnitt soll als zweites Ziel ein Generator für SQL-
Befehle implementiert werden, der durch Analyse bestimmter Metadaten die Quell-
daten automatisiert in das Data Vault data warehouse integrieren kann. Die Schritte,
die für die Entwicklungen notwendig sind, werden im Folgenden in den einzelnen Ab-
schnitten genauer erläutert.
5.1. Das Datenmodell

Um die SQL-Skripte für den ETL-Prozess und den Generator später an existierenden
Daten testen zu können, wird zunächst ein Testmodell entwickelt. Als Beispiel wird ei-
ne fiktive Firma modelliert, die sich auf das Verkaufen von Zweirädern spezialisiert hat.
Die Firma nutzt eine Datenbank zum Speichern der wichtigsten Informationen. Die
Quelldatenbank enthält Kundendaten, Filialdaten, Produktdaten und die Verkäufe.
Die Modellierung dient zur Veranschaulichung und zur Visualisierung von verschie-
densten Testfällen, es wird daher kein Anspruch auf ein vollständiges bzw. optimales
Geschäftsmodell erhoben.
Das Modell der Quelldatenbank ist im Anhang B.1 dargestellt1 . Die Quelldatenbank
wurde mit dem SQL Server Management Studio2 erstellt. Die Modellform ähnelt dem
Star Schema von Kimball in Verbindung mit der dritten Normalform. Die Dimensio-
nen Produkte, Filialen und Kunden werden in der Faktentabelle Verkäufe referenziert.
Eine Ausnahme der dritten Normalform stellt der Wohnort in der Tabelle Adressen
dar. Diese Abweichung ist beabsichtigt, um ein realitätsnahes und übersichtliches Da-
tenmodell zu erhalten. Eine Abweichung vom Star Schema ist die Auslagerung der
Adressen von Filialen und Kunden in eine extra Dimension sowie die Preistabelle.
Die Preise der Produkte wurden in einer eigenen Tabelle modelliert, damit sowohl
1
Alle Abbildungen der Modelle sind auf der DVD in voller Größe abgespeichert (Anhang D).
2
SQL Server 2012, Microsoft SQL Server Management Studio Version 11.0.5058.0
https://www.microsoft.com/en-US/download/details.aspx?id=29062
41
5. Praktische Entwicklungen zur bi-temporalen Historisierung in Data Vault
aktuelle Preise, als auch Preise für die Zukunft bereits in die Datenbank eintragen
werden können und der jeweilige Tagespreis nicht vor Öffnung einer Filiale in der
Produkttabelle aktualisiert werden muss. Jede Dimensionstabelle verfügt über einen
eindeutigen Primärschlüssel. Die ID´s der Tabellen werden automatisch vom Daten-
banksystem vergeben. Der Primärschlüssel der Faktentabelle Verkäufe setzt sich aus
den referenzierenden Fremdschlüsseln zusammen. Ein Datensatz der Preistabelle stellt
kein eigenes Geschäftsobjekt dar. Somit erhält diese Tabelle keinen eigenen business
key und der Primärschlüssel wird aus dem Fremdschlüssel zur Produkttabelle und
dem Gültigkeitsbeginn zusammengesetzt. Die Datentypen und die Bedingung, ob ein
Attribut NULL sein darf, wurden je nach Attribut sinnvoll vergeben. Bei den verwen-
deten Datentypen wurde kein Wert auf die Effizienz der Speicherauslastung gelegt,
da es sich bei den Testfällen lediglich um anschauliche Minimalbeispiele handelt und
die Betrachtung der Performance an dieser Stelle eine untergeordnete Rolle spielt. Die
Namen der Attribute wurden im Quellmodell nachträglich geändert, so dass keine Um-
laute und Sonderzeichen enthalten sind. Diese führten im Schritt der Implementierung
des Generators zu Fehlern beim Einlesen von Quelldateien.
Die Staging-Datenbank ist für das Laden der Daten aus den Quellsystemen zu-
ständig. Aus ihr werden die Daten anschließend in das data warehouse integriert. Im
Testbeispiel wird als Quellsystem vereinfacht lediglich eine Quelldatenbank verwendet.
Daher besitzt die Datenbank im Staging-Bereich dasselbe Datenmodell wie die Quell-
datenbank. Zusätzlich wurde in jeder Tabelle das Attribut Load Date Time Stamp
(LDTS) hinzugefügt. Dieses Attribut gibt an, zu welchem Zeitpunkt die Daten aus
der Quelldatenbank in die Staging-Datenbank geladen wurden. Diese Modellierung ist
bereits vorbereitend für die bi-temporale Historisierung in Data Vault, da anhand die-
ses Attributes, der assertion end time und des state time-Intervalls die bi-temporale
Entitätsintegrität geprüft wird.
Das data warehouse wurde als Data Vault Modell umgesetzt und ist in Anhang
B.2 dargestellt. Das Abkürzungsverzeichnis des Modells befindet sich auf der darauf
folgenden Seite in Tabelle B.1. Die Modellierung wurde mit der Software CA ERwin
Data Modeler3 durchgeführt. Der Vorteil dieser Software ist, dass die spezielle Nota-
tion für Data Vault Modelle integriert werden kann. Für große Projekte besteht die
Möglichkeit Vorlagen für Hubs, Satelliten und Links anzulegen. Mit diesen Vorlagen
lassen sich große Datenmodelle effizienter anlegen. Weiterhin kann die Software das
Modell auf Integritätsbedingungen und Namenskonflikte prüfen. Aus dem erstellten
Modell kann ein SQL-Skript4 generiert werden, mit dem das komplette Datenmodell
inklusive der Datentypen, Beziehungen und nicht-temporalen Integritätsbedingungen
in einer SQL-Datenbank aufgebaut werden kann. Mit diesem Skript wurde das Data
Vault data warehouse im SQL Server Management Studio als Datenbank erstellt. Die
3
CA ERwin Data Modeler r9.6 in der kostenlosen Community Edition
http://erwin.com/products/data-modeler/community-edition
4
Alle verwendeten Skripte sind auf der DVD gespeichert. Siehe Anhang D.
42
5.1. Das Datenmodell
Begriffe für die speziellen Zeitangaben zu assertion time und state time wurden aus
dem Theorie-Teil übernommen. Für den load date time stamp wurde der Begriff der
assertion begin time eingesetzt, um eine konsistente Benennung der Zeitangaben zu
erhalten. Im Folgenden sollen die Designentscheidungen für das Data Vault Modell
erläutert werden:
Die Verkaufstabelle wurde als Link modelliert. Dieser Link referenziert über Fremd-
schlüsselattribute die Hubs Kunde, Produkt und Filiale. Ein Datensatz im Link stellt
einen Verkauf dar. Die Informationen zu Verkaufszeitpunkt und Menge werden im Sa-
telliten des Links gespeichert. Die Kontext-Informationen zum Kunden wurden in zwei
Satelliten aufgeteilt: In die Personendaten und die Informationen über den Premium-
Status. Diese Modellierung ist aus folgenden Gründen sinnvoll: Der Premium-Status
bzw. der Rabatt eines Kunden ändert sich im Zeitverlauf voraussichtlich häufiger als
seine Personendaten. Somit ist es sinnvoll, diese selten geänderten Daten separat zu
speichern und nicht bei jeder Änderung des Premium-Status als zusätzliche Attribu-
te zu historisieren. Dadurch existiert ein Datensatz zu Personendaten nur einmal im
Personendaten-Satelliten und nicht mehrfach im Premium-Satelliten. Außerdem ist die
Abfrage, ob ein Kunde Premium-Status hat, über die Premium-Tabelle schneller als
über alle Kunden, da der Anteil an Premiumkunden sehr gering ist. Der Satellit für die
Premium-Informationen wurde bi-temporal modelliert. Das state time-Intervall dieses
Satelliten drückt die Zeit aus, in welcher der Kunde den Premium-Status besitzt. Die
Satelliten zu Preis, Produkt und Filiale wurden ebenfalls bi-temporal modelliert. Die
state time des Preises drückt aus, wann der Preis für das jeweilige Produkt gültig ist.
Für das Produkt drückt die state time aus, in welchem Zeitraum das Produkt verkauft
wird. Die state time der Filiale beschreibt das Zeitintervall von Öffnung bis Schließung
der Filiale. Das assertion time-Intervall drückt in jeder Tabelle aus, in welchem Zeit-
raum der Datensatz in der Datenbank als gültig angesehen wird. Die Satelliten zu
Verkauf, Kunde und Adresse wurden uni-temporal modelliert, da für deren Informa-
tionen keine state time-Angabe existiert. Durch die uni-temporale Modellierung wird
auch in diesen Tabellen eine vollständige Historisierung ermöglicht. Der Satellit für die
Adresse wurde bewusst nicht aufgeteilt, da die enthaltenen Informationen semantisch
stark zusammenhängen.
Nach der Erstellung des data warehouse wurden mit einem SQL-Skript die Default-
Werte für die assertion time, die state end time und die Quellinformationen in allen
Tabellen geändert. Der Default-Wert für das Attribut der assertion begin time ist der
Zeitpunkt der Transaktion, die den Datensatz in das data warehouse lädt. Im SQL
Server kann dies mit der Funktion getDate() umgesetzt werden. Für die assertion end
time und die state end time wird standardmäßig der maximale Wert für das datetime-
Attribut eingesetzt. Im SQL Server ist dies der Wert 9999-12-31 23:59:59.997. Mit
dieser Implementierung wird angenommen, dass Informationen von neu eingetragenen
Datensätzen, welche keine state end time-Angabe besitzen, auf unbestimmte Zeit gül-
tig bleiben. Der Default-Wert für die Quellinformationen wird auf die Quelle der Daten
eingestellt. Für das data warehouse ist dies im Testbeispiel die Staging-Datenbank.
43
Der Einsatz dieser Default-Werte dient zur Vereinfachung der Anfragen zum Laden
der Daten in das data warehouse. In einem System mit mehreren Quelldatenbanken
müssen diese Informationen dynamisch je nach Quelle eingetragen werden.
Nach der Erstellung der Datenbanken konnten erste Beispieldaten in das System
eingepflegt werden. Die Daten wurden manuell lediglich in die Quelldatenbank ein-
gefügt. Für die Staging-Datenbank und das data warehouse sollen die Daten über
SQL-Anfragen automatisch geladen und in das jeweilige System eingefügt werden. Die
Daten sind fiktiv und als Testbeispiele erstellt worden, ein Bezug zu realen Personen,
Firmen, Adressen oder sonstigen Informationen wird ausgeschlossen.
5.2. Der ETL-Prozess

Um die Daten aus der Quelldatenbank zu extrahieren und über die Staging-Datenbank
in das Data Vault data warehouse zu integrieren, wird in diesem Abschnitt der dazu
verwendete ETL-Prozess erläutert. Ein ETL-Prozess besteht aus mehreren Schritten,
je nach Prozess unterschiedlich fein strukturiert. Die drei wichtigsten Schritte sind die
Extraktion der Daten aus den Quellsystemen (extract), das Transformieren der Daten
in das Format der Zieldatenbank (transform) und das anschließende Laden der Daten
in die Zieldatenbank (load) [KC04]. Das Transformieren beinhaltet unter anderem
auch die Bereinigung der Daten und die Einhaltung einer konformen Datenhaltung.
In Abbildung 5.1 wird der ETL-Prozess für das Testbeispiel schematisch dargestellt:
Abbildung 5.1.: Der ETL-Prozess
Die Staging-Datenbank wird dazu genutzt, die Daten aus den Quellsystemen zu
sammeln. Da im Testbeispiel nur eine Quelldatenbank der Firma existiert, können
die Quelldaten über ein SQL-Skript aus der Quelldatenbank direkt in die Staging-
Datenbank eingefügt werden. Wichtig bei diesem Schritt ist, dass vor dem Einfügen
von referenzierenden Datensätzen zuerst die referenzierten Datensätze in der Daten-
bank enthalten sein müssen, da ansonsten die referentielle Integrität verletzt wird und
kein referenzierender Datensatz eingefügt werden kann. Da die Staging-Datenbank
dasselbe Datenmodell wie die Quelldatenbank nutzt, muss keine syntaktische oder
semantische Transformation stattfinden. Der Ladeprozess wird asynchron durch den
Start des Skripts durchgeführt, um die manuellen Veränderungen an den Quelldaten
44
5.2. Der ETL-Prozess
direkt nachvollziehen zu können. Im Testbeispiel wird vereinfacht nur von einer Quell-
datenbank und von bereits korrekten Daten ausgegangen, um sich voll auf die Trans-
formation in ein Data Vault Modell und die Integration der bi-temporalen Aspekte
konzentrieren zu können.
Die Schritte transform und load sollen in einem SQL-Skript zusammengefasst wer-
den. Ein Transformieren der Daten muss stattfinden, da das Datenmodell des data
warehouse mit der Data Vault Modellierung eine andere Form als in der Staging-
Datenbank besitzt. Die Daten werden wie in der Theorie beschrieben in die Elemente
Hub, Link und Satellit aufgeteilt. Im Ladeprozess wird das Prinzip des „Integrity
Load“ genutzt: Beim Laden von Satelliten und Links können referenzierte Datensätze
im data warehouse erstellt werden (falls sie noch nicht existieren), damit die referen-
tielle Integrität eingehalten wird. Dadurch ist die Reihenfolge, in der die Elemente
geladen werden, sehr flexibel.
In dieser Arbeit wird nur eines der SQL-Skripte erläutert, da eine Erklärung aller
Skripte sehr viel Platz in Anspruch nehmen würde. Für das Laden von Hub, Link und
uni-temporalem Satellit wurde jeweils ein ausführlich kommentiertes Beispiel-Skript
erstellt5 . Eine Dokumentation in Kommentar-Form ist in jedem Skript vorhanden. Als
Beispiel für ein SQL-Skript, welches Daten von der Staging-Datenbank in das data
warehouse lädt, wurde das Skript zum Laden der Kundendaten ausgewählt6 . Dieses
Skript wurde ausgewählt, da es alle in der Theorie beschriebenen Inhalte praktisch
umsetzt. Dies sind die Transformation in das Data Vault Modell, das Einfügen von
Hub-, Link- und Satelliten-Datensätzen sowie die uni- und bi-temporale Historisierung.
Für ein besseres Verständnis wird empfohlen für den folgenden Abschnitt das Skript
zu öffnen, um die referenzierten Schritte direkt nachverfolgen zu können.
Der erste Schritt (Schritt 1) im Ladeprozess ist die Erstellung der Hub-Datensätze,
da sowohl Links als auch Satelliten auf diese referenzieren. Die erste Insert-Anfrage
legt daher neue Datensätze im Kunden-Hub an. Um die Entitätsintegrität einhalten zu
können, wird ein neuer Hub-Datensatz nur erstellt, wenn das abgebildete Geschäftsob-
jekt noch nicht im data warehouse gespeichert ist. Dies wird über den natural business
key abgefragt. Die sequence ID wird automatisch von der Datenbank inkrementell ver-
geben. Die Quellinformation wird durch den Default-Wert initialisiert.
Um die Integritätsbedingungen auch für die Kontext-Informationen sicherzustellen,
wurde im nächsten Schritt (Schritt 2) ein spezieller bedingter Ausdruck definiert. Für
den Satellit Sat_Cust_Prem wird geprüft, ob eine Verletzung der bi-temporalen En-
titätsintegrität zwischen einzufügenden Daten aus der Staging-Datenbank und den
existierenden Daten im data warehouse besteht. Diese Überprüfung wird auf die gül-
tigen Datensätze im data warehouse eingeschränkt, da ungültige Datensätze für die
5
Diese wurden gekennzeichnet mit „Example-Load-“.
6
Das Skript ist als SQL-Datei auf der DVD unter „Load-customer-data-to-DWH.sql“ zu finden. Die
Datei wurde außerdem als PDF-Datei gespeichert, falls kein Programm zum Öffnen von SQL-
Dateien zur Verfügung steht.
45
Integrität nicht mehr relevant sind. Die Gültigkeit wird über die assertion end time
abgefragt. Anschließend werden alle Daten auf die in Abschnitt 3.4 beschriebenen
[Includes]-Beziehungen geprüft. Eine Überprüfung der [Excludes]-Beziehungen muss
nicht stattfinden, da diese keine Verletzung der Entitätsintegrität erzeugen. Im spe-
ziellen Fall der [equals]-Beziehung müssen alle Kontext-Informationen in die Abfrage
miteinbezogen werden. Im Beispielskript ist dies das Attribut Rabatt. Exakt gleiche
Datensätze sollen keine Verletzung der Integritätsbedingung verursachen. Es wird wäh-
rend der nachfolgenden bi-temporalen Historisierung bereits sichergestellt, dass gleiche
Informationen nicht erneut in das data warehouse geladen werden. Liegt als Ergeb-
nis eine Verletzung der Entitätsintegrität vor, wird eine Fehlermeldung ausgegeben
und der Ladeprozess wird abgebrochen. Diese Umsetzung wird gewählt, da ansons-
ten die problembehafteten Datensätze als neue Datensätze erkannt und somit in das
data warehouse geladen werden würden. Eine weitere Möglichkeit mit diesen Fehlern
umzugehen wäre das Laden aller Datensätze in das data warehouse und das anschlie-
ßende Lösen der Problemfälle mit speziell angepassten „business rules“. Diese Regeln
müssen für jeden Fall einzeln bewerten, welcher der sich gegenseitig ausschließenden
Datensätze als gültig angesehen werden soll. In einem Standard-Ladeprozess werden
die business rules allerdings nicht definiert.
Liegt keine Verletzung der Entitätsintegrität vor, kann der Ladeprozess der Kontext-
Informationen beginnen (Schritt 3a & 3b). Zunächst werden die Daten für den Sa-
telliten Sat_Cust geladen (Schritt 3a). Dieser Satellit ist uni-temporal modelliert.
Die uni-temporale Historisierung besteht aus zwei Teilschritten: Zunächst werden al-
le Datensätze, die durch nachträgliche Änderungen in der Quelle ungültig werden,
historisiert. Dazu wird deren assertion end time auf den load date time stamp des
aktualisierten Datensatzes der Quelle geändert, da der alte Datensatz bis zum Laden
des neuen Datensatzes gültig war. Anschließend werden in den Satelliten alle geän-
derten und neuen Kontext-Informationen eingefügt. Somit befinden sich alte (nicht
mehr gültige) und neue oder geänderte (gültige) Daten gleichermaßen im Satelliten.
Durch Abfragen über die assertion time kann der Anwender zu jeder Zeit den gültigen
Datensatz ermitteln.
Der Satellit Sat_Cust_Prem ist bi-temporal modelliert und soll im nächsten Schritt
beladen werden (Schritt 3b). Eine bi-temporale Historisierung besteht aufgrund der
Komplexität aus deutlich mehr Teilschritten als eine uni-temporale Historisierung.
Zunächst wird für jedes Geschäftsobjekt, in diesem Fall also für jeden Kunden, ein
kompletter bi-temporaler Zeitraum7 im Satelliten angelegt. Der Zeitraum beginnt im
Beispiel am 01.01.1999 und endet am 31.12.9999. Das Beginn-Datum liegt beispiel-
haft ein Jahr vor der Gründung der Firma, das Ende-Datum ist das maximale Datum
in SQL. Die Kontext-Information wird mit NULL initialisiert. Diese Modellierung
beschreibt, dass für den kompletten Zeitraum, in dem Kontext-Informationen für Pre-
miumkunden existieren können, für diesen Kunden keine Informationen existieren. In
7
Siehe Abbildung 3.3.
46
5.3. Testen des ETL-Prozesses
den nächsten vier Teilschritten werden die bi-temporalen Zeiträume wie in Kapitel 3.6
aufgebaut. Erst wird der Zeitraum links vom neuen Datensatz aufgebaut8 . Der Zeit-
raum stellt alle Datensätze dar, die vor dem neuen Datensatz gültig waren. Zweitens
wird der Zeitraum rechts vom neuen Datensatz aufgebaut, wenn der neue Datensatz
nicht bis zum maximalen Datum gültig sein sollte9 . Der Datensatz dieses Zeitraumes
sagt aus, dass in diesem Zeitraum noch keine Informationen über den Premiumstatus
des Kunden existieren. Die nächsten beiden Anfragen im Skript aktualisieren die as-
sertion end time der nicht mehr gültigen Datensätze. Diese können über die state time
und die assertion time des neuen Datensatzes ermittelt werden. Im letzten Schritt der
bi-temporalen Historisierung wird der neue bzw. geänderte Datensatz in den Satelliten
eingefügt und füllt somit den letzten verbliebenen Zeitraum10 .
Im letzten Schritt des Skripts (Schritt 4) ist der Ladeprozess für Beziehungen mo-
delliert. Im Beispielmodell hat jeder Kunde eine Adresse als Fremdschlüsselbeziehung.
Die Beziehung zwischen den zwei Tabellen wird durch den Link Link_Cust_Adress
ausgedrückt. Zunächst werden per Integrity Load nicht-vorhandene Hub-Datensätze
der referenzierten Adressen angelegt. Mit einem Look-Up über den natural business
key kann überprüft werden, ob die referenzierte Adresse bereits im data warehouse
gespeichert ist. Anschließend wird geprüft, ob im Kundendatensatz das Fremdschlüs-
selattribut geändert wurde, der Kunde also umgezogen ist. In diesem Fall wird der
Link-Datensatz, der die Beziehung zwischen Kunde und Adresse darstellt, auf die
neue Beziehung aktualisiert. Mit der letzten Anfrage werden alle neuen Beziehungen
als Link-Datensätze eingefügt. Die sequence ID´s von Kunde und Adresse können in
jedem Schritt über den natural business key selektiert werden.
Der gesamte Ladeprozess für das data warehouse wurde in mehrere Teilskripte aufge-
teilt, um eine bessere Übersichtlichkeit und Wartbarkeit zu ermöglichen. Diese Teilbe-
reiche sind das Laden der Adressdaten, Produkt- und Preisdaten, Kundendaten, Fili-
aldaten und Verkaufsdaten. Jedes Skript kann separat ausgeführt werden. Im nächsten
Abschnitt wird beschrieben, wie der Prozess mit Testdaten verifiziert wurde.

Alle Skripte wurden zunächst mit den bereits existierenden Daten des Quellmodells ge-
testet. Alle Geschäftsobjekte, Beziehungen und Kontext-Informationen wurden korrekt
in das data warehouse geladen. Anschließend wurden Änderungen an den Quelldaten
vorgenommen, um die uni- und bi-temporale Historisierung zu testen. Im Testvorgang
wurde jedes SQL-Skript einzeln auf Korrektheit geprüft. Bei den Änderungen an den
Quelldaten wurde darauf geachtet, dass die Fälle der in der Theorie beschriebenen
8
In Abbildung 3.3 ist dies Fläche 3
9
In Abbildung 3.3 würde diese Fläche rechts neben der Fläche 4 liegen.
10
In Abbildung 3.3 ist dieser Zeitraum Fläche 4.
47
Taxonomie in Abbildung 3.2 vollständig abgedeckt wurden.

Am Beispiel des bereits erläuterten Skripts zum Laden der Kundendaten werden
nun einige Testfälle beschrieben. Diese Testfälle sollen einerseits die Korrektheit des
Skripts zeigen, andererseits auch die Funktionsweise der bi-temporalen Historisierung
verdeutlichen. Für die Testfälle wird zunächst angenommen, dass bisher kein Datensatz
im data warehouse existiert. In der Staging-Datenbank wurden die zwei Datensätze in
Abbildung 5.2 aus dem Quellsystem geladen. Die Datensätze wurden farbig markiert,
um die Zugehörigkeit in späteren Tabellen einfacher zu erkennen.
Abbildung 5.2.: Erste Daten in der Staging-Datenbank
Diese Datensätze sollen nun im data warehouse gespeichert werden. Dazu wird das
Skript load-customer-data-to-DWH.sql ausgeführt. Die Auswirkungen der bi-tempo-
ralen Historisierung auf den Satelliten Sat_Cust_Prem sind in Abbildung 5.3 abge-
bildet. Alle weiteren betroffenen Elemente des Ladeprozesses Hub_Cust, Sat_Cust,
Hub_Adress und Link_Cust_Adress wurden korrekt beladen.
Abbildung 5.3.: Das Laden der ersten Daten in das data warehouse
Betrachten wir zunächst den einfachen Fall für die Kundin mit ID 2 (Nachfolgend
Kundin 2 genannt): Für diese Kundin wird im Satelliten ein Datensatz angelegt, der
sich über den komplett möglichen Zeitraum von Jahr 1999 bis 9999 erstreckt. In diesem
Zeitraum ist ihr Rabatt NULL. Der Datensatz wurde korrekt angelegt, denn die Kun-
din ist momentan noch keine Premiumkundin und erhält somit zu keinem Zeitpunkt
einen Rabatt. Nun wird die Historisierung für den Kunden mit ID 1 (nachfolgend
48
Kunde 1 benannt) betrachtet: Der erste Datensatz stellt analog wie bei Kundin 2 den
gesamten Zeitraum dar. Dieser Datensatz wird für jeden Kunden angelegt, daher ist er
auch für Kunde 1 eingefügt worden. Dieser erste Datensatz wurde am 22.03.2000 un-
gültig. Dies ist der Zeitpunkt, an dem die Daten für Kunde 1 in die Staging-Datenbank
geladen wurden. Zum gleichen Zeitpunkt werden die Datensätze zwei bis vier als gül-
tig erklärt. Der zweite und der vierte Datensatz decken korrekt den Zeitraum ab, in
der Kunde 1 nicht Premiumkunde ist. Daher ist in diesem Zeitraum sein Rabatt auch
NULL. Der dritte Datensatz stellt den Zeitraum dar, in dem der Kunde Premium-
kunde ist und einen Rabatt von 5% erhält. Die ersten Daten wurden somit korrekt
historisiert gespeichert.
Nun wird angenommen, dass im Jahr 2013 der Kunde 1 so viel gekauft hat, dass er
einen neuen Premiumstatus mit 8% Rabatt erhält. Da dieser Kunde ein sehr loyaler
Kunde ist, soll sein Premiumstatus auf unbestimmte Zeit gelten. Auch die Kundin 2
erhält durch mehrere kleinere Einkäufe einen Premiumstatus mit 3,5% Rabatt. Der
Status wird allerdings zunächst auf 3 Jahre begrenzt. Diese Daten existieren wie in
Abbildung 5.4 in der Staging-Datenbank. Sie wurden am 05.05.2013 geladen. Da keine
Änderungen an Personen- oder Adressdaten vorgenommen wurden, sind keine weiteren
Elemente des data warehouse von der Änderung betroffen.
Abbildung 5.4.: Neue Daten in der Staging-Datenbank
Um diese Datensätze korrekt bi-temporal historisiert im data warehouse zu spei-

chern, wird erneut das Skript zum Laden der Kundendaten ausgeführt. Die Prüfung
der bi-temporalen Entitätsintegrität ergibt keine Verletzung, da beide Datensätze eine
[Excludes]-Beziehung zu den bereits gespeicherten Datensätzen haben. Der komplette
Satellit Sat_Cust_Prem wird in Abbildung 5.5 abgebildet. Nicht farblich markiert
sind die bereits existierenden Datensätze, die weiterhin gültig bleiben und somit keine
Änderung erhalten. Die Datensätze in Zeile 4 und 7 müssen geändert werden, da sie ab
dem Ladezeitpunkt der neuen Daten ungültige Informationen enthalten würden. Ihre
assertion end time wird auf das Ladedatum der neuen Datensätze aktualisiert, da Sie
bis zu diesem Zeitpunkt als gültig angesehen werden. Für Kunde 1 wird der Datensatz
in Zeile 5 angelegt, um den Zeitraum zwischen dem alten und neuen Premiumstatus
zu füllen. In diesem Zeitraum ist Kunde 1 nicht als Premiumkunde deklariert und
sein Rabatt daher NULL. Der Datensatz in Zeile 6 enthält die neuen Informationen
aus der Staging-Datenbank. Der Kunde 1 erhält 8% Rabatt bis zum Jahre 9999. Der
49
Datensatz ist bis zum Jahr 9999 gültig. Für Kundin 2 wurden aufgrund des begrenz-
ten Premiumstatus drei neue Datensätze angelegt. Dies ist analog zu der Erstellung
der Datensätze für Kunde 1 beim ersten Ausführen des Skriptes. Die Daten wurden
somit korrekt bi-temporal historisiert. Zu jedem Kunden kann zu jedem Zeitpunkt
herausgefunden werden, ob und wieviel Rabatt der Kunde erhält oder erhalten hat.
Abbildung 5.5.: Der Satellit Sat_Cust_Prem nach dem Laden der neuen
Datensätze
Diese Testfälle haben gezeigt, dass die bi-temporale Historisierung korrekt durch-
geführt wird. Damit keine Datensätze in das data warehouse geladen werden, die zu
einer Verletzung der bi-temporalen Entitätsintegrität führen, wurden zusätzlich für
jedes Skript die bedingten Anfragen getestet, die neue Datensätze auf diese Verletzun-
gen überprüfen. In Anhang C sind zwei Tabellen mit Beispieldaten dargestellt, deren
Datensätze beim Laden in das data warehouse eine Verletzung der Entitätsintegrität
verursachen würden. In jedem Fall wird das Skript zum Laden der Kundendaten nicht
ausgeführt, da ansonsten die fehlerhafte Daten im data warehouse abgelegt werden
würden.
Die Einhaltung der bi-temporalen referentiellen Integrität wurde analog zu diesen
Testfällen überprüft. Alle SQL-Skripte wurden mit mehreren Testdaten in verschie-
denster Kombination und in mehreren Testschritten verifiziert. Jedes Skript lädt alle
Datensätze, die zu keiner Integritätsverletzung führen, korrekt in das data warehouse.
Die Datensätze, welche zu einer Verletzung der Integrität führen, werden von jedem
Skript erkannt und nicht in das data warehouse geladen.
Durch den Test des gesamten Ladeprozesses konnte sichergestellt werden, dass die
50
5.4. Implementierung des SQL-Generators
Datensätze im data warehouse zu jeder Zeit vollständig historisiert sind und keine
Integritätsbedingung verletzt wird.
Im nächsten Abschnitt wird eine Möglichkeit beschrieben, wie die Erstellung der
SQL-Anfragen zum Laden in ein data warehouse in Data Vault Modellierung automa-
tisiert werden kann.

In diesem Abschnitt soll die Implementierung eines SQL-Generators beschrieben wer-
den. Das Ziel des Generators ist es, aus Metadaten automatisch SQL-Skripte zu gene-
rieren, die das Laden von Daten aus einer Staging-Datenbank in ein Data Vault data
warehouse ermöglichen.
Für die Implementierung des Generators wurde die Programmiersprache Java11 in
Verbindung mit der Entwicklungsumgebung Eclipse12 genutzt. Die Sprache und die
Software wurden einerseits aufgrund guter Vorkenntnisse und Erfahrungen ausgewählt.
Andererseits eignet sich die Modularisierung durch separate Klassen in Java sehr gut,
um zunächst kleine Elemente für den Generator zu implementieren, die jederzeit um
komplexere Konstrukte erweitert werden können. In Abbildung 5.6 wird der Ablauf
der SQL-Generierung schematisch dargestellt.
Die benötigten Metadaten stellen eine Verknüpfung zwischen den Quelltabellen in
der Staging-Datenbank und den Zieltabellen im data warehouse dar. Es wird daher ge-
speichert, wohin die Inhalte der Attribute aus der Quelltabelle geladen werden sollen.
Diese Informationen werden in Form einer Datei im CSV-Format gespeichert. Dieses
Format wurde aufgrund der weiten Verbreitung und einfachen Lesbarkeit für Parser
gewählt. In Abbildung 5.7 ist eine Datei13 , die diese Metadaten enthält, dargestellt.
Die Farben stehen für die Art des Inserts, der je nach Art der Zieltabelle erstellt werden
muss. Sie wurden lediglich zur Illustration hinzugefügt. Die Informationen stammen
aus den bereits genutzten Datenmodellen. In der CSV-Datei, die vom Generator ge-
lesen wird, werden die Datensätze durch Zeilenumbrüche getrennt. Die Informationen
der Spalten werden durch ein Semikolon getrennt. Die erste Spalte enthält den Namen
der Quelltabelle. In der zweiten Spalte werden die Attribute der Quelltabelle einge-
tragen. Die dritte und vierte Spalte enthalten Namen und Attribute der Zieltabelle.
Die fünfte Spalte wird für das Eintragen von Fremdschlüssel oder natural business key
der Quelltabelle genutzt. Diese Angabe muss erfolgen, um die Kontext-Informationen
korrekt zu den Hubs verknüpfen zu können. Die letzte Spalte sagt aus, ob das Attribut
der Quelltabelle NULL sein kann. Diese Information wird für die Überprüfung in einer
Where-Klausel benötigt.
11
Java™ SE Development Kit 8, Update 45
12
Eclipse IDE for Java Developers, Version: Luna Service Release 2 (4.4.2)
13
Diese Datei ist im Projektordner des SQL-Generators vorhanden. Sie wurde mit
„CSV_Example.csv“ benannt.
51
Abbildung 5.6.: Funktionsweise des SQL-Generators
Zu Beginn der Implementierung wurde im Java-Projekt zunächst eine Klasse ange-

legt, die für das korrekte Einlesen der CSV-Datei zuständig ist. Jede Spalte der CSV-
Datei wird in eine separate Liste gespeichert. Die Listen haben einen dynamischen
Typ, um auf Veränderungen der Zeilenanzahl in der Quelldatei reagieren zu können.
Anschließend wurden die Ladeprozesse der Elemente Hub, Link und Satellit als jeweils
eigene Klasse implementiert. Aufgrund dieser Modularisierung ist es möglich, nachträg-
lich für einzelne Elemente erweiterte Konstrukte in den Generator aufzunehmen, ohne
unbeteiligte Module verändern zu müssen. Die Umsetzung der Informationen aus den
Metadaten in eine SQL-Anfrage erwies sich als sehr komplex und zeitaufwändig. Die
zuvor erstellten Muster-Ladeprozesse konnten als Schema für diese Implementierung
genutzt werden und erleichterten somit die Umsetzung in Programmcode.
52
Abbildung 5.7.: Beispiel für Metadaten
Der Generator setzt eine korrekt erstellte Metadaten-Datei voraus. Fehleingaben in

der Input-Datei können vom Generator nicht als solche identifiziert werden. Grund
dafür ist, dass der Generator das Datenmodell nicht kennt und somit nicht verifizieren
kann, ob Tabellen- oder Attributnamen korrekt verwendet wurden. Eine fehlerhafte
Metadaten-Datei würde daher zwar vom Generator verarbeitet werden, das erstellte
SQL-Skript würde allerdings Fehler enthalten.
Zum Testen des Generators wurde eine eigene Klasse erstellt. Diese übergibt dem
Generator als Argumente die Dateipfade der Input- und Output-Datei. Die Input-
Datei ist die CSV-Datei mit den Metadaten. In die Output-Datei werden die erstellten
Insert-Befehle geschrieben. Getestet wurde der Generator anhand der bereits vorlie-
genden Beispieldaten im Quellsystem. Nach der Generierung der SQL-Datei wurde
diese im SQL Server Management Studio geöffnet und ausgeführt. Die vom Skript
betroffenen Elemente wurden korrekt in das data warehouse geladen. Somit konnte
gezeigt werden, dass der Generator das SQL-Skript korrekt erstellt.
Abschließend wurde eine vollständige Dokumentation14 des Java-Projektes ange-
legt.
14
Die Dokumentation befindet sich im Ordner SQLGenerator\doc.
53
6. Schlussteil
In diesem Kapitel werden zunächst die Ergebnisse der Arbeit zusammengefasst und ein
Fazit gezogen. Abschließend wird ein Ausblick auf weitere Entwicklungsmöglichkeiten
gegeben.
6.1. Zusammenfassung
Bereits die historischen Entwicklungen haben gezeigt, dass temporale Aspekte beim
Speichern von Daten eine zentrale Rolle spielen. Allerdings wurde bisher kein entspre-
chender Standard zur bi-temporalen Datenmodellierung entwickelt. Es wurde beschrie-
ben, warum die zwei Zeitangaben für logische und physische Zeit benötigt werden,
um eine vollständige Historisierung zu ermöglichen. Die Bedeutung und die theore-
tischen Grundlagen zu bi-temporaler Datenmodellierung wurden anhand von Defini-
tionen und Beispielen erläutert. Die verschiedenen Beziehungen zwischen zwei Zeitin-
tervallen wurden anhand der Beziehungen nach Allen [All83] definiert. Anschließend
wurde erläutert, welche Probleme und Komplexität die Entitätsintegrität und die re-
ferentielle Integrität im Fall von bi-temporalen Daten beinhalten. Um die temporalen
Aspekte in der Data Vault Modellierung beschreiben zu können, wurden zunächst die
theoretischen Grundlagen dieser Modellierungstechnik beschrieben. Die einzelnen Ele-
mente von Data Vault wurden anhand von Beispielen erläutert. Anschließend wurde
die Modellierung mit bisherigen Techniken zur Modellierung eines core data warehouse
verglichen und bewertet.
Im praktischen Teil der Arbeit wurde zunächst ein Testdatenmodell für alle weiteren
Entwicklungen aufgestellt. Das Modell wurde in einer SQL-Datenbank implementiert
und mit Beispieldaten gefüllt. Anhand dieses Datenmodells wurde die Transformation
in ein Data Vault Modell gezeigt. Anschließend wurde der ETL-Prozess modelliert,
der die Daten von der Quelldatenbank über eine Staging-Datenbank in das data ware-
house lädt. Dafür wurden mehrere SQL-Skripte geschrieben. Diese Skripte enthalten
die in der Theorie beschriebene uni- und bi-temporale Historisierung in Data Vault.
Der ETL-Prozess wurde ausführlich getestet und erfolgreich auf die Einhaltung aller
Integritätsbedingungen geprüft. Um die Generierung von SQL-Skripten für den ETL-
Prozess automatisieren zu können, wurde ein SQL-Generator in der Programmier-
sprache Java implementiert. Dieser Generator kann mit Hilfe einer Metadaten-Datei
die Insert-Befehle für Hub, Satellit und Link erstellen. Die Metadaten enthalten In-
formationen darüber, welche Attribute aus der Quelltabelle in welche Attribute der
Zieltabelle geladen werden sollen. Der Generator wurde ebenfalls erfolgreich an dem
bereits vorliegenden Datenmodell getestet.
55
6. Schlussteil
6.2. Fazit
Die Ziele der Bachelorarbeit konnten in vollem Umfang erreicht werden. Durch die
praktischen Entwicklungen wurde gezeigt, wie die Umsetzung der bi-temporalen His-
torisierung in Data Vault durchgeführt werden kann. Mit dem SQL-Generator wurde
eine Möglichkeit präsentiert, wie das Erstellen von SQL-Anfragen, die Daten in ein
Data Vault data warehouse laden, automatisiert werden kann. Durch die Kombina-
tion dieser beiden Entwicklungen können die Vorteile von Data Vault und der bi-
temporalen Datenmodellierung miteinander vereint werden. Durch das automatisch
generierte SQL-Skript müssen die SQL-Anfragen nicht mehr eigenhändig geschrieben
werden. Dadurch können Kosten durch fehlerhaft erstellte Anfragen reduziert werden.
Das Erstellen der Muster-SQL-Skripte erwies sich als sehr komplex. Bei dieser Ent-
wicklung mussten sehr viele Feinheiten und Spezialfälle beachtet werden. Für eigene
Entwicklungen wird daher empfohlen, die Skripte in kleinen Schritten zu entwickeln
und diese möglichst nach jeder Änderung zu testen, da ansonsten ein Fehler nur noch
schwer gefunden werden kann. Die bereits erstellten und getesteten Skripte haben die
Implementierung des Generators erleichtert. Das Schema einer Insert-Anfrage für Hub,
Satellit und Link konnte eins-zu-eins in die Implementierung übertragen werden.
Da es bisher keinen Standard zur bi-temporalen Historisierung in Data Vault gibt,
wird das in dieser Arbeit vorgestellte Vorgehen empfohlen. Es konnte gezeigt wer-
den, dass durch dieses Vorgehen die Daten im Data Vault data warehouse vollständig
historisiert und mit Einhaltung aller Integritätsbedingungen gespeichert sind.
6.3. Ausblick
Für das temporale Datenmanagement gibt es im Bereich der Automatisierung und Be-
nutzerfreundlichkeit ein hohes Entwicklungspotential. Der Generator könnte zur voll-
ständigen Automatisierung um die temporalen Aspekte erweitert werden. Dazu muss
der Prozess zum Erstellen von Satelliten-Inserts angepasst werden. Für eine höhere Be-
nutzerfreundlichkeit könnte für den Generator eine grafische Benutzeroberfläche imple-
mentiert werden. Es ist denkbar, dass mit dieser Oberfläche auch die Metadaten-Datei
nur durch Drag&Drop erstellt wird. Dies würde Schreibfehler in der Datei vorbeugen.
Weiterhin spielt in der Praxis auch die Betrachtung der Performance eine wich-
tige Rolle, wenn die bi-temporale Historisierung bei einer sehr großen Datenmenge
durchgeführt werden soll. Dazu könnten die Skripte an reale Datensätze angepasst
und getestet werden.
In der Zukunft sollten Datenbankhersteller in Betracht ziehen, die bi-temporale His-
torisierung durch das Datenbanksystem vollständig zu unterstützen. Hierfür könnten
beispielsweise Konstrukte entwickelt werden, welche für bi-temporale Relationen die
Integritätsbedingungen als automatisch generierte Constraints in die Datenbank inte-
grieren.
56
Literaturverzeichnis
[All83] James F Allen. Maintaining knowledge about temporal intervals. Commu-

nications of the ACM, 26(11):832–843, 1983.
[BGK+ 10] P. Bruni, R. Garcia, S. Kaschta, J. Klitsch, R. Kumar, A. Lurie, M. Parbs,

R. Ramachandran, and IBM Redbooks. DB2 10 for z/OS Technical Over-
view. IBM redbooks. IBM Redbooks, 2010.
[CT05] Jan Chomicki and David Toman. Temporal databases. Foundations of

Artificial Intelligence, 1:429–467, 2005.
[Dar98] Hugh Darwen. Valid time and transaction time proposals: Language design
aspects. In Temporal Databases: Research and Practice, pages 195–210.
Springer, 1998.
[Dar13] Hugh Darwen. Temporal data and the relational model. Document from
website http://www.dcs.warwick.ac.uk/~hugh/ (accessed 2015-05-08), pu-
blished 2013.
[DD97] Chris J Date and Hugh Darwen. A Guide To Sql Standard, volume 3.
Addison-Wesley Reading, 1997.
[DDL03] Christopher John Date, Hugh Darwen, and Nikos A Lorentzos. Temporal
data and the relational model: a detailed investigation into the application
of interval and relation theory to the problem of temporal database mana-
gement. Morgan Kaufmann, 2003.
[DL+ 02] Hugh Darwen, Nikos Lorentzos, et al. Temporal data & the relational model.
Elsevier, 2002.
[DM88] Barry A. Devlin and Paul T. Murphy. An architecture for a business and
information system. IBM systems Journal, 27(1):60–80, 1988.
[GRF00] Dov Gabbay, Mark Reynolds, and Marcelo Finger. Temporal Logic: Mathe-
matical Foundations and Computational Aspects Volume 2. Oxford Logic
Guides 40, 2000.
[Hul12] Hans Hultgren. Modeling the Agile Data Warehouse with Data Vault. New
Hamilton, 2012.
57
[Inm92] William H Inmon. Building the Data Warehouse. John Wiley & Sons, Inc.,
1992.
[Inm02] William H Inmon. Building the Data Warehouse. John Wiley & Sons, Inc.,
third edition, 2002.
[ITG] Firma ITGAIN. Daten-modellierung mit data vault. Information from web-
site http://www.itgain.de/leistungen/informationsmanagement/daten-
modellierung/data-vault/ (accessed 2015-06-09).
[JCG+ 92] Christian S Jensen, James Clifford, Shashi K. Gadia, Arie Segev, and Ri-
chard Thomas Snodgrass. A glossary of temporal database concepts. ACM
Sigmod Record, 21(3):35–43, 1992.
[JDB+ 98] Christian S Jensen, Curtis E Dyreson, Michael Böhlen, James Clifford,
Ramez Elmasri, Shashi K Gadia, Fabio Grandi, Pat Hayes, Sushil Jajo-
dia, Wolfgang Käfer, et al. The consensus glossary of temporal database
concepts - february 1998 version. Springer, 1998.
[Joh14] Tom Johnston. Bitemporal Data: Theory and Practice. Morgan Kaufmann,
2014.
[JS99] Christian S Jensen and Richard T Snodgrass. Temporal data manage-

ment. Knowledge and Data Engineering, IEEE Transactions on, 11(1):36–
44, 1999.
[JSS94] Christian S Jensen, Michael D Soo, and Richard T Snodgrass. Unify-

ing temporal data models via a conceptual model. Information Systems,
19(7):513–547, 1994.
[JW10] Tom Johnston and Randall Weis. Managing time in relational databases:
how to design, update and query temporal data. Morgan Kaufmann, 2010.
[KC04] Ralph Kimball and Joe Caserta. The data warehouse ETL toolkit. John
Wiley & Sons, 2004.
[Kim96] Ralph Kimball. The data warehouse toolkit: practical techniques for buil-
ding dimensional data warehouse. NY: John Willey & Sons, 248:4, 1996.
[KM01] Gerhard F Knolmayer and Thomas Myrach. Concepts of bitemporal da-

tabase theory and the evolution of web documents. In System Sciences,
2001. Proceedings of the 34th Annual Hawaii International Conference on,
pages 10–pp. IEEE, 2001.
[KM12] Krishna Kulkarni and Jan-Eike Michels. Temporal features in sql: 2011.
ACM Sigmod Record, 41(3):34–43, 2012.
58
[KR02] Ralph Kimball and Margy Ross. The Data Warehouse Toolkit: The Com-
plete Guide to Dimensional Modeling. John Wiley & Sons, Inc., 2002.
[Lan04] Justin Langseth. Real-time data warehousing: Challenges and solutions.

DSSResources. com, 2(08):2004, 2004.
[LG11] Dan Lindstedt and Kent Graziano. Super Charge Your Data Warehouse:
Invaluable Data Modeling Rules to Implement Your Data Vault. Create-
Space, 2011.
[LGH08] Dan Linstedt, Kent Graziano, and Hans Hultgren. The new business su-
permodel, the business of data vault modeling. Lulu. com, 2008.
[Lin02] Dan Linstedt. Data vault series 1 - data vault overview. TDAN. com, 2002.
[Lin12] Dan Lindstedt. The Official Data Vault Standards Document. Amazon
Media EU S.Ã r.l., 2012.
[OS95] Gultekin Ozsoyoglu and Richard T Snodgrass. Temporal and real-time

databases: A survey. Knowledge and Data Engineering, IEEE Transactions
on, 7(4):513–532, 1995.
[SAA+ 94] Richard Thomas Snodgrass, Ilsoo Ahn, Gad Ariav, Don S Batory, James
Clifford, Curtis E Dyreson, Ramez Elmasri, Fabio Grandi, Christian S Jen-
sen, Wolfgang Käfer, et al. Tsql2 language specification. Sigmod Record,
23(1):65–86, 1994.
[Sno86] Richard Thomas Snodgrass. Temporal databases. In IEEE computer. Ci-

teseer, 1986.
[Sno92] Richard T Snodgrass. Temporal databases. In Theories and methods of

spatio-temporal reasoning in geographic space, pages 22–64. Springer, 1992.
59
Anhang A.
Informationen zur Firma ITGAIN
ITGAIN Consulting Gesellschaft für IT-Beratung mbH
Ansprechpartner Herr Dirk Lerner
Essener Straße 1
D-30173 Hannover
Telefon: +49 511 51 51 – 3700

Fax: +49 511 51 51 – 3800
Email: info@itgain.de
Internetadresse: www.itgain.de
61
Anhang B.
Datenmodelle von Quellsystem und data warehouse
B.1. Datenmodell der Quelldatenbank
% # # &' (#
% # # &' (#
! "#$
* / '
2 )
% # # &' (#
+ ,,,
-
% # # &' (#
- . / ,,,
0.
1 ,,,
)
*
*
% # # &' (#
% # # &' (#
) **
) **
3 &
63
Anhang B. Datenmodelle von Quellsystem und data warehouse
64
B.2. Datenmodell des Data Vault data warehouse
B.2. Datenmodell des Data Vault data warehouse
65
Anhang B. Datenmodelle von Quellsystem und data warehouse
Folgende Tabelle enthält die Bedeutung der Abkürzungen, die im Data Vault Da-
tenmodell verwendet wurden:
Abkürzung Bedeutung
ABDTS Assertion Begin Date Time Stamp
AEDTS Assertion End Date Time Stamp
Cust Customer
DTS_Sale Date Time Stamp of Sale
House_No House number
House_No_Add Addition to the house number
RecordSRC Record Source
SBDTS State Begin Date Time Stamp
SEDTS State End Date Time Stamp
SID Sequence ID
Tabelle B.1.: Abkürzungen des DataVaultDWH-Modells
66
Anhang C.
Testdaten
Die folgenden zwei Tabellen enthalten Testdaten, die durch den Ladeprozess im da-
ta warehouse zu einer Verletzung der bi-temporalen Entitätsintegrität führen wür-
den. Die Beziehungen sind analog zu Kapitel 3.4 aufgebaut worden. Es werden nur
[Includes]-Beziehungen betrachtet, da [Excludes]-Beziehungen keine Integritätsverlet-
zung verursachen. Verglichen wurden die neuen Datensätze mit der Tabelle, die in
Abbildung 5.5 dargestellt ist.
FK_
verletzende Kunde_ Premiumkunde_ Premiumkunde_
Geschlecht Vorname Nachname Titel Adresse_ Rabatt LDTS
Beziehung ID seit bis
ID
2000-02-03 2001-05-25 2007-04-01
[starts] 1 True Peter Müller Dr. 3 4,55
00:00:00.000 00:00:00.000 00:00:00.000
Erklärung starts: steht in Konflikt mit Rabatt 5% von 2000 bis 2012
2005-01-03 2012-02-03 2007-04-01

[finishes] 1 True Peter Müller Dr. 3 5,55
00:00:00.000 00:00:00.000 00:00:00.001
Erklärung finishes: steht in Konflikt mit Rabatt 5% von 2000 bis 2012
2014-02-03 2014-05-05 2007-04-01

[during] 1 True Peter Müller Dr. 3 9,00
00:00:00.000 00:00:00.000 00:00:00.002
Erklärung during: steht in Konflikt mit Rabatt 8% von 2013 bis 9999
2008-01-08 2017-09-03 2007-04-01

[overlaps] 1 True Peter Müller Dr. 3 7,50
00:00:00.000 00:00:00.000 00:00:00.003
Erklärung overlaps: steht in Konflikt mit Rabatt 8% von 2013 bis 9999
2000-02-03 2012-02-03 2007-04-01

[equals] 1 True Peter Müller Dr. 3 3,00
00:00:00.000 00:00:00.000 00:00:00.004
Erklärung equals: steht in Konflikt mit Rabatt 5% von 2000 bis 2012
67
Anhang C. Testdaten
FK_
verletzende Kunde_ Premiumkunde_ Premiumkunde_
Geschlecht Vorname Nachname Titel Adresse_ Rabatt LDTS
Beziehung ID seit bis
ID
2013-05-04 2018-05-04 2014-04-01
[starts -1] 2 False Else Schneider NULL 4 4,50
09:00:00.000 09:00:00.000 00:00:00.006
Erklärung starts -1: steht in Konflikt mit Rabatt 3,5% von 2013 bis 2016
2011-04-03 2016-05-04 2014-04-01

[finishes -1] 2 False Else Schneider NULL 4 4,25
09:00:00.000 09:00:00.000 00:00:00.007
Erklärung finishes -1: steht in Konflikt mit Rabatt 3,5% von 2013 bis 2016
2012-08-11 2018-11-23 2014-04-01

[during -1] 2 False Else Schneider NULL 4 5,50
09:00:00.000 09:00:00.000 00:00:00.008
Erklärung during -1: steht in Konflikt mit Rabatt 3,5% von 2013 bis 2016
2014-03-04 2019-05-04 2014-04-01

[overlaps -1] 2 False Else Schneider NULL 4 3,00
09:00:00.000 09:00:00.000 00:00:00.009
Erklärung overlaps -1: steht in Konflikt mit Rabatt 3,5% von 2013 bis 2016
2013-05-04 2016-05-04 2014-04-01

[equals] 2 False Else Schneider NULL 4 3,25
09:00:00.000 09:00:00.000 00:00:00.010
Erklärung equals: steht in Konflikt mit Rabatt 3,5% von 2013 bis 2016
68
Anhang D.
Inhalt der DVD
Die DVD befindet sich auf der Innenseite des hinteren Buchdeckels.
• Abbildungen/ enthält alle verwendeten Abbildungen.
• Dokument/ enthält die Bachelorarbeit als Latex-Projekt.
• Praxis/ enthält folgende Elemente des Praxis-Teils:
– Datenbanken und DWH-Modell/ enthält die Datenbanken als Backups

sowie das ERwin-Modell des data warehouse.
– JavaProjectSQLGenerator/ enthält den in Java programmierten SQL-

Generator, die Beispiel-CSV-Datei für die Metadaten sowie die Dokumen-
tation der Implementierung.
– SQL-Skripte/ enthält alle programmierten SQL-Skripte.
• Bachelorarbeit.pdf ist dieses Dokument im PDF-Format.
69
View publication stats

Temporale Aspekte Data Vault Volkmann

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Temporale Aspekte Data Vault Volkmann

Originaltitel:

Hochgeladen von

Copyright:

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

Temporale Aspekte in Data Vault

Thesis · September 2015

Research Fact-Oriented Modeling View project

Research Bitemporal Historization View project

The user has requested enhancement of the downloaded file.

Temporale Aspekte in Data Vault

12. September 2015

Paderborn, 12. September 2015

Stichworte: Bi-temporale Historisierung, Core Data Warehouse, Data Vault

Keywords: Bitemporal historization, Core Data Warehouse, Data Vault

2. Historie des temporalen Datenmanagements 3

3. Theorie zur bi-temporalen Modellierung 9

4. Theorie zur Modellierung mit Data Vault 33

5. Praktische Entwicklungen zur bi-temporalen Historisierung in Data Vault 41

A. Informationen zur Firma ITGAIN 61

B. Datenmodelle von Quellsystem und data warehouse 63

D. Inhalt der DVD 69

3.1. Nicht-temporale, uni-temporale und bi-temporale Tabellenstruktur . . . 11

4.1. Beispiele für einen Hub . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.1. Der ETL-Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.1. Eine uni-temporale Tabelle . . . . . . . . . . . . . . . . . . . . . . . . . 11

B.1. Abkürzungen des DataVaultDWH-Modells . . . . . . . . . . . . . . . . 66

2.1. Beginn der Entwicklungen in den 1980er Jahren

Außerdem wurde in dieser Zeit begonnen, sogenannte „on-line transaction tables“

2.2. Erweiterungen für SQL, Entwicklungen zu data warehouse

2.3. Neueste Entwicklungen zum temporalen Datenmanagement

2.4. Anforderungen zukünftiger Entwicklungen

3.1. Definition einer Zeitperiode

3.2. Unterschied von nicht-, uni- und bi-temporalen Daten

Abbildung 3.1.: Nicht-temporale, uni-temporale und bi-temporale Tabellenstruk-

id bt1 et1 preis

Tabelle 3.1.: Eine uni-temporale Tabelle

Um aus einer uni-temporalen Tabelle eine bi-temporale Tabelle zu konstruieren,

id bt1 et1 bt2 et2 preis

Tabelle 3.2.: Eine bi-temporale Tabelle

id bt1 et1 bt2 et2 preis

3.3. Unterschiedliche Bezeichnungen für logische und physische

In der Historie wurden unterschiedliche Entwicklungen im Bereich des temporalen Da-

missverstanden werden könne.

TSQL2 SQL ISO SQL IBM Stan- MTRD Bitemporal

Tabelle 3.3.: Terminologie zu bi-temporaler Modellierung3

3.4. Die Beziehungen nach Allen

Ein Beispiel für die Beziehung [during]:

In der Beziehung [overlaps] enthält jede der Zeitperioden z1 und z2 Zeitpunkte,

[ Jan14 | Mär14 | K6 | Schmidt | Hameln ]

[ Jan15 | Mär15 | K7 | König | Bonn ]

grundsätzliche und die gegensätzliche Bedeutung vereint. Er entwickelte diese Deﬁ-

Um abschließend einen zusammenfassenden Überblick aller Beziehungen zu erhalten,

Abbildung 3.2.: Taxonomie der Beziehungen nach Allen4

3.5. Konzept der temporalen Integrität

Abbildung 3.3.: Dreidimensionaler Raum einer bi-temporalen Kundentabelle5

mentiert werden [Joh14].

[ Mai14 | Jun14 | Jan15 | Feb15 | K2 | König | Bonn ]

Wenn bi-temporale Daten lediglich in einzelnen Zellen repräsentiert werden würden,

Abbildung 3.4.: Kleinste bi-temporale Einheit6

[ Mai14 | Jun14 | Jan15 | Mär15 | K2 | König | Bonn ]

In Abbildung 3.5 wird der zusammengefügte Datensatz graﬁsch dargestellt. Durch

Abbildung 3.5.: Zusammengefügte bi-temporale Zellen7

In den folgenden zwei Abschnitten werden Entitätsintegrität und referentielle Inte-

3.6. Bi-temporale Entitätsintegrität

Anhand von Beispieltransaktionen soll die temporale Entitätsintegrität erklärt wer-

abt aet sbt set K-ID Name Wohnort

Abbildung 3.6.: Bi-temporale Fläche für Beispieldatensatz zu K18

[Jul15-9999] [Mai15-9999] [Equals]