Ich hatte gerade bei einem neuen Kunden angefangen und war Teil des Data-Warehouse-Teams, das für den Aufbau des Data Warehouse mit Data Vault verantwortlich war. Wir hatten einen Data Vault-Generator entwickelt. Damals verwendeten wir ein Enddatum für die 'business timeline'. Ich erinnere mich, wie kompliziert es war, die alten Datensätze zu aktualisieren, und wie viel Zeit das den Server kostete. Vor allem, wenn man zwischendurch Datensätze hinzufügen wollte. Zum Beispiel um die Historie aus alten Quellen zu laden.
Die erste Session auf der Data Modeling Zone Europe 2018 in Düsseldorf war eine Session über bitemporale Daten von Dirk Lerner. Die Session war und ist ein Auszug aus seinem aktuellen Training Temporal Data in a Fast-Changing World, das weltweit als offenes und in-house Training - in Deutsch oder Englisch - verfügbar ist.
In sehr kleinen Gruppen von zwei oder drei Personen machten wir einige Übungen zu Timelines und Allen-Beziehungen. Er erklärte den Unterschied zwischen der technischen Timeline und der Business Timeline. Dirk lieferte auch einige schöne Synonyme dafür. Während des Projekts hatten wir manchmal Kommunikationsprobleme mit diesen beiden Begriffen. Als ich zurück im Büro war, habe ich sofort eine Namensänderung für die Business Timeline eingeführt. Wir haben uns für state_date für das fachliche Datum und load_date für das technische Datum (Zeitpunkt des Eintreffens der Daten im Data Warehouse) entschieden.
Auch die Theorie wurde von Dirk sehr anschaulich erklärt. Er führte uns in die Welt der Allen-Beziehungen ein und erklärte die Begriffe für die verschiedenen Zeitformen, die es gibt, wie nontemporal, unitemporal und bitemporal. Mit seiner Präsentation konnte ich mein Team davon überzeugen, unseren Ansatz zu ändern. Die Theorie von Dirk half mir bei der Einführung einer reinen Insert-Only-Architektur. Mit den Übungen, die ich gemacht habe, konnte ich das Team davon überzeugen, die Spalte mit dem Enddatum zu entfernen. Diese Spalte kann berechnet werden und ist daher noch nicht notwendig.
Im weiteren Verlauf des Projekts erwies sich diese Entscheidung als entscheidend für das Laden sehr alter Daten in unser Data Warehouse. Wir mussten 120 Backup-Datenbanken in das Data Warehouse laden. Ich wurde mit dieser Aufgabe betraut, die aufgrund der geringfügigen Unterschiede in den Schemata zwischen den verschiedenen Backups viel Arbeit erforderte, so dass ich bereits viel damit zu tun hatte, die Daten korrekt zuzuordnen und in das Data Warehouse zu laden. Letzteres war dank der Insert-only-Architektur, die wir verwendet haben, viel einfacher. Wir haben 1,5 Terabyte teuren Plattenplatz gespart und das Data Warehouse auf 400 Gigabyte verkleinert. Die alten Backups konnten gelöscht werden und wir haben jederzeit Zugriff auf alle Daten. Vor der Umstellung hat der Kunde bei Bedarf einfach ein Backup zurückgespielt.
Die Präsentation von Dirk im DMZ Europe hat mir geholfen, temporale Daten richtig zu verstehen und die Konzepte den Business Analysten und Datenspezialisten zu erklären. Ich habe die Beispiele von Dirk benutzt, um ihnen den Unterschied zwischen NowNow, ThenThen und ThenNow zu zeigen. Es ist immer noch schwierig für mich, das Konzept zu verstehen, aber zumindest fühle ich mich sicherer mit dem Wissen, das ich in Dirks Bitemporal-Session erworben habe.
Abschließend kann ich Dirks Schulung nur weiterempfehlen. Wenn Sie über bitemporale Daten in Ihrem Data Warehouse nachdenken oder Probleme damit haben, sollten Sie sich unbedingt an Dirk wenden.
Tijs van Rinsum, Qvada
Autor des Buches De Data Gastronoom: Es geht um Daten, nicht um Technik. Für Manager und Leute außerhalb unserer Branche. Zwei Männer in einem Restaurant, die über Daten sprechen. Zum Beispiel darüber, wie man mit Historie umgeht. Etwas über Scrum. Und vieles mehr. Ein lesenswertes Buch für alle.
Link: https://dedatagastronoom.nl