3NF und Data Vault: Kein Grund zur Sorge

Von Zeit zu Zeit erhalten wir eine interessante Frage von Personen, die den Datavault Builder einsetzen möchten: Unterstützt das DWH-Automatisierungstool Datavault Builder 3NF?

Die interessante Antwort lautet: Ja.

Obwohl wir uns bewusst gegen einen 3NF-Core entschieden haben, weil wir der Überzeugung sind, dass die Aufteilung der Daten in einzelne Funktionen wie Schlüssel (Hubs), Beziehungen (Links) und Kontext/Attribute (Satellites) viele Probleme mit 3NF-DWHs löst.

Das umfasst die Erstellung von Modellen, die nun von verschiedenen Ausgangspunkten aus erstellt werden und leicht zusammenwachsen können, eine einfachere Wartung bei Modelländerungen sowie die Unabhängigkeit einzelner Laderouten. Und das sind nur drei von vielen Vorteilen.

Wir fragen daher meist, was die fachliche Anforderung ist, 3NF zu verwenden. Die meisten Antworten lassen sich darauf zusammenfassen, dass die Datenkonsumenten an einen 3NF-Core gewöhnt sind und nicht sicher sind, ob sie Abfragen auch aus einem Data Vault-Modell verarbeiten können.

Interfaces verwenden

Dies ist der Moment, klar zu betonen: Niemand sollte den Core direkt abfragen. Meiner Meinung nach war das bereits bei Inmon-Modellen nicht der Fall und gilt noch expliziter für Data Vault-Cores.

Für die Abfragen müssen klar Interfaces erstellt werden. Diese bringen die Daten in ein Format, das für Abfragen und Reports optimiert ist.

Sehr oft werden diese Interfaces als dimensionales Modell erstellt, da viele moderne Reporting-Tools darauf optimiert sind. Da wir im Data Vault einen höheren Normalisierungsgrad haben, können wir Interfaces jedoch auch auf einer feineren Ebene wie 3NF bereitstellen.

Wie man einen 3NF-Layer erstellt

Wenn Sie die erwarteten Kardinalitäten in der Datenmodellierung des Data Vault erfasst haben (One-to-Many, Many-to-Many usw.), haben Sie sogar alle Informationen, um ein Data Vault-Modell deterministisch in ein 3NF-Interface zu übersetzen:

• Dem Hub-Business Key oder Hash wird der PK zugewiesen

• Alle Many-to-one oder One-to-one verbundenen Hub-Business Keys/Hashes werden zu Foreign Keys

• Alle Felder aus den Satellites werden zu Attributen

Ob Sie das als As-of-Now- oder As-of-Then-Sicht erstellen, spielt keine Rolle. Sie können einfach die Liste der Hubs durchgehen und die 3NF-View pro Hub ohne Benutzereingabe erstellen.

Wenn Sie nun einen Satellite im Data Vault hinzufügen, müssen Sie nur die View für diesen Hub neu generieren. Einfach zu erstellen, einfach anzupassen.

Da wir in Datavault Builder APIs für alle Funktionen anbieten, ist es einfach, diese zu verwenden, um Interface-Views vollständig automatisch nach eigenen Regeln zu erstellen (z. B. haben Foreign Keys ein FK_-Präfix, oder sie heißen exakt wie das Zielfeld, oder sie verwenden den BK oder Hash als PK). Theoretisch werden die Datenkonsumenten nie wissen, dass ihre Daten im Data Vault-Format gespeichert sind.

Data Vault und 3NF?

Unsere Antwort lautet daher: Ja, wir unterstützen 3NF für die Darstellung der Daten, aber verwenden Sie immer einen Data Vault für die Speicherung. Das könnte durchaus die Botschaft sein, um auch Datenkonsumenten zu überzeugen, die die Sicherheit haben möchten, weiterhin mit bestehenden Ansätzen arbeiten zu können.

Und wenn das nicht reicht, kann man sogar verbergen, wie man das Backoffice organisiert. Schließlich besuchen wir beim Einkaufen nicht das Lager des Einkaufszentrums, sondern freuen uns über die gut gefüllten Regale.