In einem Datenprojekt treffen oft verschiedene Endnutzer mit unterschiedlichen Bedürfnissen aufeinander. Dies betrifft auch die Bereitstellung historischer Daten.
Während für die Fachabteilung, die die Unternehmensbilanzen erstellt, unveränderliche Bilanzen ein Muss sind, benötigt ein Vertriebsmitarbeiter für Kundentermine eine aktuelle 360-Grad-Sicht des Kunden mit allen relevanten rückwirkenden Änderungen. Alte, nicht mehr gültige Informationen sind für das Kundengespräch irrelevant.
Jede Abteilung hat also spezifische Anforderungen an die Datenhistorie, die oft als selbstverständlich angesehen werden. Es ist wichtig, diese unterschiedlichen Bedürfnisse zu berücksichtigen, um effektive Datenlösungen zu entwickeln.
Wie kann ein DataWarehouse für alle Anwendergruppen die erforderliche Historie gleichzeitig bereitstellen?
Die Antwort auf diese Frage ist eine bitemporale Historie.
Dabei wird jede Information mit zwei Zeiten gespeichert:
- technische Historie: Wann habe ich von dieser Information Kenntnis erhalten?
- fachliche Historie: Ab wann gilt die Informationen fachlich? (z.B. ab sofort, rückwirkende Meldung eines Versicherungsschadens, künftige Preisanpassungen, rückwirkende Korrektur von Fehleingaben)
In einem bitemporalen Kontext ist es möglich, die unveränderte Bilanz der Vorjahre mit dem damaligen Kenntnisstand abzurufen. Gleichzeitig hat der Vertriebsmitarbeiter Zugriff auf den aktuellen Kenntnisstand, der alle bisherigen und zukünftigen fachlichen Anpassungen enthält.
Data-Scientisten können die Leistung ihrer KI-Modelle einfach überprüfen, indem sie die Frage stellen: "Was sagt meine KI mit dem Kenntnisstand von vor 4 Wochen für heute voraus und wie gut stimmt dies mit der Realität überein?" Dieser Ansatz ermöglicht eine effektive Bewertung und Anpassung der KI-Modelle für präzisere Vorhersagen.
Die bitemporale Historie hat leider mehrere unangenehme Eigenschaften:
- Wenn sich die Zeit nicht mehr auf einem Zeitstrahl bewegt, sondern in einer zweidimensionalen Ebene, sind sämtliche Fragestellungen viel komplexer. Dies führt zu Verständnisproblemen.
- Der zu erzeugende Programmcode wird deutlich komplizierter.
- Entwicklungs- und Testaufwände und damit Kosten steigen spürbar.
- Die Usability sinkt. Datenauswertungen, die bitemporale Daten nicht sauber mit komplexen Bedingungen abfragen, liefern falsche Ergebnisse. Dies betrifft insbesondere Endanwender mit hervorragenden fachlichen, aber nur grundlegenden technischen Kenntnissen.
In der Folge wird in Projekten, welche eigentlich eine bitemporale Historie benötigen, oft darauf verzichtet und man lebt mit Kompromissen und Workarounds.
Der DVG vermeidet diese unangenehmen Effekte vollständig.
Mit nur wenigen Konfigurationen kann das gesamte DWH bitemporal gemacht werden, wobei der benötigte Code automatisch erzeugt wird. Sogar Tests werden bitemporal korrekt durchgeführt, während die bitemporale Historie nahtlos im Hintergrund des DWH abläuft.
Für Anwender stehen verschiedene Zugriffsschichten zur Verfügung, die jeweils die "richtige" Historie bereitstellen. Tatsächlich bemerkt jeder Anwender möglicherweise nicht einmal, dass das DWH eine bitemporale Historie hat, sondern erhält einfach das für ihn "richtige" Ergebnis.
Dieses Konzept ähnelt der GPS-Ortung in Mobiltelefonen, bei der man den gewünschten Standort erhält, ohne unbedingt zu verstehen, wie die zugrunde liegende Relativitätstheorie von Einstein funktioniert. Es ist faszinierend zu sehen, wie Technologie uns nahtlos und effizient unterstützt, ohne dass wir alle technischen Details verstehen müssen.
Wie genau dies im DVG implementiert ist, habe ich auf der 14. Frühjahrstagung der DDVUG vorgestellt.
Falls Sie einen Blick unter die Motorhaube des DVG wagen wollen, werfen Sie einen Blick in meinen Vortrag.
