Data Vault – Perfekte Konsistenz auch ohne referentielle Integrität

Die Überwachung der referentiellen Integrität ist ein Sicherheitsnetz in Datenbank Management Systemen. Oft wird in Data Vault 2.0 Systemen diese Funktion zugunsten einer schnellen Datenbereitstellung deaktiviert. Eine einfache Möglichkeit, wie die Konsistenz im Data Vault trotzdem vollautomatisch überwacht und sichergestellt werden kann, zeigt Ihnen dieser Artikel.

Das Hashkey-Konzept von Data Vault 2.0 ermöglicht es, dass Entitäten vollständig unabhängig voneinander und zur selben Zeit geladen werden können. Dies bringt Vorteile beim Integrieren mehrerer Systeme und bei der schnelleren Bereitstellung der integrierten Daten in Analysen und Berichten.

Dies kann aber nur erreicht werden, wenn die Referentielle Integrität (RI) zwischen den Tabellen im Datenbank Management System deaktiviert wird. Ansonsten wäre es nicht möglich, eine Link-Tabelle zu befüllen, ohne dass die referenzierten Hub-Datensätze bereits im Data Vault vorhanden sind. Die Referentielle Integrität hat natürlich ihre Daseinsberechtigung wenn es um die technische Sicherstellung der Konsistenz und damit der Qualität der Daten geht. Denn Referenzen, die ins Nichts zeigen, haben in einer vertrauenswürdigen Datenquelle nichts verloren. ​

Anstatt nun selbst einen Housekeeping-Prozess zu entwickeln, der die Konsistenz prüft und sicherstellt, bringt die Data Quality Automation Suite BiG EVAL eine effiziente und flexible Standardlösung für dieses Problem mit. Dabei versucht BiG EVAL die Relationen aufzulösen und diejenigen Hashkeys zu protokollieren, welche nicht aufgelöst werden können. Mit Hilfe eines einfachen Skripts, wird dieser Testfall vollautomatisch auf alle im Data Vault vorhandenen Links (Link zu Hub) und Satelliten (Satellit zu Hub) angewendet. Einmal aktiviert, erweitert sich die Testabdeckung also ohne manuelles Zutun auf alle neu hinzugefügten Relationen.

Umsetzung der Konsistenzprüfung mit BiG EVAL

Sie benötigen zwei neue Testfälle. Einen für die Link zu Hub Relationen, und einen für die Satellit zu Hub Relationen. Wir beschränken uns nachfolgend auf den Testfall für die Link zu Hub Relationen. Die Skripte für den anderen Testfall können Sie am Ende dieses Artikels einsehen.

Testfälle für die Konsistenzprüfung in DV 2.0

Im ersten Schritt beschränken wir uns zudem auf eine einzige Fremdschlüssel - Primärschlüssel Beziehung einer LINK-Tabelle. Im nachfolgenden Abschnitt wird dann erklärt, wie die automatische Ausbreitung des Testfalls auf alle LINK-Tabellen und darin enthaltene Fremdschlüssel erreicht wird.

Erstellen Sie einen neuen Testfall und wählen Sie die Testmethode "Exactly Equal Probes".

Neuer Testfall mit der Exactly Equal Testmethode

Erste dynamische Probe

Dem Testfall wird nun eine dynamische Probe hinzugefügt. Diese enthält eine SQL Abfrage auf die Data Vault Datenbank, welche über einen LEFT OUTER JOIN die LINK-Tabelle mit der zugehörigen HUB-Tabelle verknüpft. Dabei werden über die WHERE-Bedingung nur diejenigen Datensätze herausgefiltert, bei welchen der JOIN nicht aufgelöst werden kann. 

SELECT DISTINCT
    L.hk_h_customer AS hk_h
FROM
    dv.l_customerorder AS L
LEFT OUTER JOIN dv.h_customer AS H ON
    H.hk_h_customer = L.hk_h_customer
WHERE
    H.hk_h_customer IS NULL

Zweite dynamische Probe

Damit am Ende der Testfall erfolgreich und somit die Relation konsistent ist, darf diese Abfrage also keine Datensätze zurückgeben. Wir vergleichen die Probe also gegen eine zweite dynamische Probe, die immer ein leeres Datenset zurückgibt

SELECT TOP 0 CAST(NULL as binary(20)) AS hk_h

Testfall ausführen und Review des Ergebnisses

Nun kann der Testfall bereits ausgeführt werden. Ist die geprüfte Relation in Ihrem Data Vault konsistent, so endet der Testfall erfolgreich. Ansonsten schlägt er natürlich fehl und zeigt genau die betreffenden Fremdschlüssel-Hashkeys an.

Results of a Data Vault consistency check

Automatisieren der Testabdeckung

Nun können wir uns um die Automatisierung des Testfalls kümmern. So dass er für jede vorhandene Fremdschlüssel-Beziehung in allen LINK-Tabellen des Data Vaults ausgeführt wird. Hierzu kommen die Skripting-Möglichkeiten von BiG EVAL zum Einsatz.

Snippet zur Metadaten-Abfrage erstellen

Dazu müssen wir als Erstes die Metadaten des Data Vaults abfragen. Wir benötigen eine Liste aller Fremdschlüssel-Hashkeys in allen LINK-Tabellen. Erstellen Sie hierzu das folgende neue Snippet. Es wird anschliessend im Steuerungs-Skript des Testfalls verwendet.

Snippet zur Abfrage aller Fremdschlüssel in Link-Tabellen

Code zum kopieren

Testfall Steuerung über Skript

Mit Hilfe des Steuerungs-Skripts (Reiter CONTROL im Testfall-Editor) kann der Testfall mehrfach ausgeführt werden. Dazu wird im Steuerungs-Skript zuerst die Metadaten-Abfrage des Snippets ausgeführt und anschliessend über jeden davon zurückgegebenen Fremdschlüssel iteriert. In jedem Durchgang wird dann die SQL-Abfrage der Probe über die Parameter angepasst und der Testfall ausgeführt.

Steuerung des Testfalls

Code zum kopieren

Proben-Abfragen dynamisch gestalten

Die im Steuerungs-Skript gesetzten Parameter können wir nun in der SQL-Abfrage der ersten dynamischen Probe anwenden. Dadurch wird die SQL-Abfrage dynamisch. Nachfolgend in Gelb markiert sind die dynamischen Teile der Abfrage. Also die Parameter, welche auch mit Standard-Werten versehen werden, um die Probe validieren zu können.

Dynamisch parametrisierte Probe

Code zum kopieren

Testfall ausführen und Review des Ergebnisses

Wird der Testfall nun ausgeführt, so erweitert er sich dynamisch auf alle Fremdschlüssel aller LINK-Tabellen. Sprich, ein und der selbe Testfall wird mehrfach ausgeführt, wie im folgenden Testergebnis-Graphen erkennbar ist.

Testergebnisse

Bei Punkt (1) wurden neue Entitäten im Data Vault hinzugefügt, was zu einer automatischen Ausweitung der Testabdeckung geführt hat. Konkret sind automatisch vier neue Testfallausführungen dazugekommen.

Bei Punkt (2) sind aufgrund eines Fehlers im Datenintegrationsprozess Inkonsistenzen aufgetreten. Drei fehlerhafte Testfallausführungen und somit drei fehlerhafte Relationen sind erkennbar. Einer davon konnte bei Punkt (3) behoben werden. Die zwei übrigen stellen sich in der Detailansicht wie folgt dar:

Detaillierte Testergebnisse

Bei einem Drilldown in den Testergebnissen sind dann auch die Hashkeys der betroffenen Datensätze sichtbar.

Results of a Data Vault consistency check

Anhang - Skripte für Satellit zu Hub Testfall

Mit den folgenden Skripten setzen Sie den zweiten Testfall einfach um.

Probe 1

Probe 2

Steuerungs-Skript

No comments
Thomas BoltData Vault – Perfekte Konsistenz auch ohne referentielle Integrität