Change Data Capture erkennt Änderungen an Daten. Im Falle von gelöschten Daten stellt sich die Frage: Wie sollten wir Löschungen in Data Vault verwalten?
Das Data Management Center of Excellence (DMCE) Team von FastChangeCoTM arbeitet derzeit an der Anbindung eines neuen operativen Systems. Dieses System liefert bereits Delta-Datensätze, die bei der Erfassung von Änderungen entstehen.
Das Team erörtert derzeit ein Problem, das genau diese Deltas betrifft. Es ist nicht immer klar, was mit Daten im Falle eines angelieferten Löschdatensatzes im Data Vault geschehen soll: Die Daten logisch (nicht physisch) löschen oder nicht?
Zalika Okoro, Werkstudentin im DMCE-Team, kämpft im Moment mit diesem Problem..
Sie stellt dem Team fragen, wie z. B. „Was ist ein Änderungsdatensatz? Und warum genau haben wir damit Probleme?“
Amal Leyla Kasim, eine Datenmodelliererin im Team, erklärt Zalika gerne, was ein Change Data Capture (CDC) ist und wofür es gut ist.
Was ist ein CDC?
Ein CDC-Mechanismus eines operativen Systems (native CDC) identifiziert und erfasst kontinuierlich Änderungen an Daten. Darunter verstehen wir die Einfügungen, Aktualisierungen und Löschen von Daten, im Folgenden zusammenfassend als Änderungen, als ein ‘change’, bezeichnet werden.
Der CDC-Mechanismus erkennt Änderungen, indem er, vereinfacht gesagt, den alten und den neuen Datensatz anhand eines definierten Schlüssels vergleicht. In den Datenstrukturen des operativen Systems ist dies in der Regel der physische Primärschlüssel einer Tabelle. Sind die Daten der Nichtschlüsseldatenelemente geändert, stellt das CDC einen ‘change’ fest und übermittelt den geänderten Datensatz vollständig mit allen Datenelementen.
Bei einem gelöschten Datensatz, ein ‘delete’, übermittelt das native CDC oft nur das Datenelement des Schlüssels, anhand dessen die Änderung erkannt wurde. Die Information, welche Daten außer dem Schlüssel gelöscht wurden, ist für das native CDC nicht relevant. Einige CDC-Systeme liefern nicht nur den Schlüssel des gelöschten Datensatzes, sondern einen vollständigen Datensatz mit allen Informationen.
Beide Varianten können bei einem Data Vault Datenmodell als Ziel zu Problemen führen. Was darf oder muss gelöscht werden? Schließlich haben sich die Datenmodelliererinnen viel Mühe gegeben, die Daten fachlich nach Geschäftsobjekten zu gliedern.
„Aber warum verwenden wir ein CDC, wenn es dann zu Problemen führt?“, wirft Zalika ein. „Das ist eine gute Frage, Zalika!“ Also erklärt Amal ihr, warum FastChangeCoTM gerne CDCs einsetzt.
Was ist der Nutzen eines CDC?
Vor einigen Jahrzehnten führte Jeff Jones (IT-Manager) die ersten CDC-Systeme bei FastChangeCoTM ein.
Für Jeff war es nicht mehr akzeptabel, dass operative Systeme verlangsamt oder manchmal sogar durch analytische Abfragen blockiert wurden. Die ersten Data Warehouses zur Datenanalyse wurden nicht zuletzt deshalb in dieser Zeit bei FastChangeCoTM aufgebaut.
Dazu mussten Daten allerdings auf andere Plattformen kopiert werden.
Diese für die Analysesysteme notwendigen Full- oder Delta-Loads und bei Bedarf auch (Full-) Reloads mit den aktuellsten Daten waren für alle beteiligten Systeme zeitaufwändig. Außerdem verbrauchten sie eine Menge Rechenleistung.
Die von Jeff eingeführten neuen CDC-Funktionen ermöglichten eine wesentlich effizientere Datenübertragung. Nur die tatsächlichen Änderungen wurden von nun an zwischen den operativen und analytischen Systemen ausgetauscht, wodurch die Belastung der operativen Systeme deutlich reduziert wurde.
Aus heutiger Sicht werden CDC-Mechanismen als wichtig erachtet, um Skalierbarkeit, Effizienz und Anforderungen an die Datenverfügbarkeit in Echtzeit zu ermöglichen, ohne die beteiligten Systeme zu beeinträchtigen.
Von der CDC-Schnittstelle zum Data Vault
Zur Analyse des Problems, wie Daten im Data Vault im Falle eines gelöschten Datensatzes zu verwalten sind, erstellt das DMCE-Team eine beispielhafte CDC-Eingangsschnittstelle (Abb. 1). Diese enthält sowohl Daten über die Mitarbeitenden als auch über die Abteilung, in der sie arbeiten. Anhand des Schlüssels ‘Employee Number’ vergleicht der CDC-Mechanismus die Datenelemente.
Abb. 1: Struktur der Eingangsschnittstelle mit Spaltennamen und Datentypen.
Die Beispieldatensätze in Abb. 2 zeigen, dass die Mitarbeiter Jack, Terence und Amal den verschiedenen Abteilungen zugeordnet sind, in diesem Fall Vertrieb (Sales) und DMCE. Da zum Zeitpunkt (Inscription Time) alle Datensätze im Quellsystem neu angelegt wurden, haben diese den Change Data Indicator ‘insert’ durch das CDC erhalten.
Anmerkung: Zum besseren Verständnis habe ich in den Abbildungen ‘insert’ statt ‘I’, ‘change’ statt ‘C’, ‘delete’ statt ‘D’ verwendet. Ich empfehle die Verwendung von I’,’C’ und ‘D’, um Speicherplatz zu sparen.
Abb. 2: CDC Eingangsschnittstelle mit Beispieldatensätzen über einen bestimmten Zeitraum.
Ausgehend von dieser beispielhaften CDC Eingangsschnittstelle entwickelt das DMCE-Team zunächst ein fachliches Datenmodell. Auf der Grundlage des Geschäftsdatenmodells wird ein physisches Data Vault-Datenmodell instanziiert.
Um zu zeigen, wie die Daten auf die verschiedenen Data Vault-Datenobjekte verteilt werden sollen, veranschaulicht Amal dies dies mit dem folgenden Diagramm (Abb. 3).
Abb. 3: Zuordnung der CDC Eingangsschnittstelle zu Data Vault.
Amal erklärt Zalika anhand von Abb. 4. das entstandene Data-Vault-Datenmodell und wie die Daten aus dem CDC-Datensatz verteilt und geladen werden.
Abb. 4: Data Vault Datenmodell mit beispielhaften Daten.
Anschließend erläutert Amal die beiden Varianten eines Löschdatensatzes, die der CDC-Mechanismus erzeugen kann. Zum einen einen leeren Datensatz, in dem nur der Schlüssel geliefert wird (Abb. 5) und einen Datensatz, der neben dem Schlüssel alle gelöschten Werte enthält (Abb. 6).
Abb. 5: CDC Incoming Interface mit einem Beispiel für einen leeren Datensatz zum Löschen.
Abb. 6: CDC Eingangsschnittstelle mit einem Beispiel für einen gelöschten Datensatz, der (vermeintlich) gelöschte Werte enthält.
Das DMCE-Team diskutiert, ob es notwendig ist, alle Daten im Ziel, die der Löschdatensatz liefert, im Data Vault-Datenmodell zu löschen. Insbesondere wenn man die vorherige Verteilung beim Laden der Daten in den Data Vault berücksichtigt. Schließlich wird aus dem operativen System ein Löschdatensatz für alle Attribute erzeugt (Change Data Indicator = Delete, Abb. 7).
Abb. 7: CDC Eingangsschnittstelle mit einem Beispiel für einen zu löschenden Datensatz und dessen Zuordnung zu den Data Vault-Objekten.
Wenn unter dieser Annahme tatsächlich alle Daten im Data Vault logisch gelöscht würden, würde dies bedeuten, dass nicht nur Jack Jogger logisch gelöscht würde, sondern auch die Verkaufsabteilung (Sales). Amal veranschaulicht Zalika die beschriebenen Konsequenzen dieser Diskussion mit dem folgenden Diagramm (Abb. 8). 
Abb. 8: Data Vault Datenmodell mit beispielhaften logisch gelöschten Daten.
Zalika versteht nun das Problem des Löschdatensatzes und die Frage, die sich daraus ergibt:
Was soll im Data Vault (logisch) gelöscht werden? Sollen Daten in beiden Satelliten ‘Sat Employee’ und ‘Sat Department’ gelöscht werden? Also genau wie beim Laden der Daten aus der Schnittstelle in das Data Vault Datenmodell?
Die 3. Normalform als Lösung!
Um eine Lösung zu finden, wendet sich das DMCE-Team an ihren Coach Diego Pasión und schildert ihm das Problem. Diego schlägt vor, die Normalform auf die Schnittstelle anzuwenden, um herauszufinden, welche Daten/Spalten tatsächlich von dem Schlüssel ‘Employee Number’ abhängen, der verwendet wurde, um die Änderungen zu identifizieren, und welche nicht.
„Each data element must provide a fact about the key (1.NF), a fact about the whole (minimal) key (2.NF), and a fact about nothing but the key (3.NF).“ gibt Diego ein bekanntes Zitat von Edgar F. Codd in leicht abgewandelter Form wieder.
„Die beispielhafte CDC Eingangsschnittstelle (Abb. 1 und 2) ist in der ersten Normalform. Dies ist für das Laden von Daten in einen Data Vault völlig in Ordnung, da die Methoden und Konzepte des Data Vault (Trennung von Geschäftsschlüssel, Relation und beschreibendem Kontext) genau damit sehr gut umgehen können. Beim Löschen von Daten hingegen kann eine Struktur in der 1. Normalform zu falschen Annahmen verleiten (Abb. 5 und Abb. 6.), was zu erheblichen Konsequenzen führen kann, wenn man nicht kurz darüber nachdenkt!“, stellt Diego fest.Das DMCE-Team diskutiert mit Diego, ob es notwendig ist, alle Daten im Ziel, die der Löschdatensatz liefert, im Data Vault-Datenmodell zu löschen. Insbesondere wenn man die vorherige Verteilung beim Laden der Daten in den Data Vault berücksichtigt. Schließlich wird aus dem operativen System ein Löschdatensatz für alle Attribute erzeugt (Change Data Indicator = Delete, Abb. 7).
Anhand des Beispiels, welches das DMCE-Teams erstellt hat, lässt sich recht einfach und nachvollziehbar erkennen, dass das Löschen des Departments im Data Vault nicht zielführend ist. Sicherlich arbeiten im Sales Department bei FastChangeCo mehr Personen als nur Jack Jogger. Bei vielen anderen nativen CDC-Schnittstellen ist dies nicht ohne weiteres erkennbar.
„Um das zu lösen, ist es von Vorteil, die CDC Schnittstelle von der 1. Normalform in die 3. Normalform zu überführen“, empfiehlt Diego dem Team. Einer der Schritte, um die Schnittstelle von der 1. Normalform in die 3. Normalform zu überführen, ist zu erkennen, welches Datenelement von welchem Schlüssel abhängt. Die Datenelemente ‘Employee First Name’ und ‘Employee Last Name’ sind vom Schlüssel ‘Employee Number’ abhängig bzw. beschreiben diesen als Fakt. Die Datenelemente ‘Department Name’ und ‘Department Address’ sind dagegen vom Schlüssel ‘Department Number’ und nicht vom Schlüssel ‘Employee Number’ abhängig (Abb. 9).
Abb. 9: Analyse, welche Datenelemente von welchem Schlüssel abhängig sind.
Mit dieser Analyse kann die CDC-Schnittstelle in eine imaginäre 3. Normalform überführt werden. Das DMCE-Team veranschaulicht dies, indem es die Beispieldaten direkt in der dritten Normalform darstellt (Abb. 10).
Abb. 10: Überführung der CDC Eingangsschnittstelle in ein imaginäres / angenommenes Datenmodell der 3. Normalform.
Anhand dieser Darstellung kann das DMCE-Team erkennen, welche Daten im 3NF-Datenmodell gelöscht werden, da nur die Datenelemente ‘Employee’ vom Schlüssel ‘Employee Number’ abhängig sind.
Abb. 11: Der Löschdatensatz betrifft ausschließlich die 3. Normalformtabelle ‘Employee’ und den Datensatz mit der ‘Employee Number’ 4711.
Daraus leitet das Team zusammen mit Diego ab, welche Daten genau im Data Vault gelöscht werden müssen: Nämlich nur die Daten des ‘Sat Employee’ und nicht die aller Satelliten (Abb. 12).
Abb. 12: Der Löschdatensatz hat nur Auswirkungen auf Satelliten ‘Sat Employee’.
Aus dem Datenmodell der 3. Normalform (Abb. 11) lässt sich ableiten, dass auch die Relation (der Fremdschlüssel) gelöscht werden könnte und somit ein End-Dating-Satellite am Link benötigt wird (Abb. 13). Da der Link im Data Vault dem Fremdschlüssel der Tabelle ‘Employee’ in der 3. Normalform entspricht.
Abb. 13: Der Lösch-Datensatz wirkt sich auf die Satelliten ‘Sat Employee’ und ‘Sat End-Dating’ aus.
Diego Pasión empfiehlt, dies nicht zu tun. Die Information über die Beziehung zwischen ‘Employee’ und ‘Department’ ist im Falle eines Löschdatensatzes nicht zuverlässig (der Schlüssel, der zu einer Löschung im CDC führt, ist ein anderer als das Schlüsselpaar (‘Employee Number’, ’Department Number’) für die Beziehung). Die Information, dass der Mitarbeiter nicht mehr der Abteilung zugeordnet ist bzw. dort nicht mehr arbeitet, wird durch den ‘Sat Employee’ festgehalten.
Natürlich gibt es Situationen, in denen genau dieser Satellit benötigt wird, um eine Relation zu beenden, aber das ist eine andere Diskussion und nicht Teil dieses Blogposts.
Es gibt aber noch eine ganze Reihe anderer Erfahrungen, die Diego Pación gemacht hat. Mehr dazu in einem der nächsten Artikel dieser Serie. Schaut doch mal wieder vorbei.
Bis dahin
Euer Dirk