Don’t repeat yourself
Dieser Satz ist die Quintessenz des „DRY Principle of Software Development“. Eine Beschreibung dazu gibt es hier bei Wikipedia. Es geht dabei darum, dass man in einem System den gleichen Code nicht mehrfach schreibt, sondern, dass es eine Stelle gibt, an der der Code steht und dieser Code im System immer wieder verwendet werden kann.
Auch bei der Data Warehouse Automation geht es darum, den Aufwand für die wiederholte Definition immer gleicher Programmteile (z.B. für Hubs, Links, Satellites und Stages) zu reduzieren, indem man ein Tool wie z.B. dbt verwendet und die DataVault-Objekte wie Hubs, Links und Satellites z.B. mit den dbt-Makros von AutomateDV beschreibt. So eine Lösung habe ich in meinem Beitrag Ein DWH mit git, Linux, Docker, PostgreSQL, dbt und AutomateDV beschrieben.
Doch das ist natürlich noch nicht das Ende der Abstraktion, wie ich schon in meinem Beitrag Die Kraft der Abstraktion beschrieben habe. Man kann sich einen Generator bauen, der den AutomateDV-Code für die Objekte des Raw Vault aus einer noch kleineren Steuerdatei erzeugt. Wie das geht, steht in meinem Beitrag GenRawVault: wie man aus einer Steuerdatei ein ganzes DWH generieren kann.
Bei der Steuerdatei RawVault.xml, die dort beschrieben ist, handelt es sich quasi um eine DSL (domain specific language) für einen RawVault gemäß Data Vault 2.0. Man erkauft sich die Kompaktheit der Darstellung damit, dass man keine individuellen Abweichungen und Ergänzungen mehr in sein System einbringen kann, die in der DSL nicht vorgesehen sind. Aber das ist ja genau das, was Dan Linstedt fordert – dass man sich strikt an das Konzept von DataVault 2.0 halten soll, da nur so die Effizienz von DV2.0 erhalten bleibt.
Convention over Configuration
Und damit sind wir beim zweiten Prinzip der Software-Entwicklung, auf das ich in diesem Beitrag eingehen möchte: Convention over configuration (CoC). Auch hier gibt es eine Beschreibung auf Wikipedia. Man verwendet Festlegungen (Konventionen), aus denen sich das „normale“ Verhalten des Systems ergibt. Nur wenn man Abweichungen von diesem „normalen“ Verhalten benötigt, dann konfiguriert man diese.
Mit diesen beiden Prinzipien im Sinn habe ich die Struktur der RawVault.xml verändert und eine neue Version (schema_version=“2″) erstellt. Der Rest dieses Beitrags beschreibt diese neue Version im Vergleich zur bisherigen.
Die Struktur der DSL, die bisher in der Steuerdatei RawVault.xml verwendet wurde, orientiert sich am Ablauf der Datenübernahme in das DWH:

- Der Abschnitt system enthält Systemparameter und wird hier nicht näher beschrieben.
- Der Abschnitt file_imports beschreibt den Import der CSV-Dateien aus den operativen Systemen in die Source-Schemata der DWH-Datenbank.
- Der Abschnitt db_sources beschreibt die Tabellen der Source-Schemata der DWH-Datenbank.
- Der Abschnitt stages beschreibt die Staging-Tabellen in der DWH-Datenbank mit Feldern, Unique-Keys und den darin enthaltenen NaturalKeys.
- Der Abschnitt dv_tables beschreibt die Objekte des RawVault: Hubs, Links und Satellites.
Obwohl diese Struktur schon einigermaßen kompakt ist, enthält sie doch noch viele Attribute, in denen die Konfigurationen für die RawVault-Objekte angegeben werden. So wird z.B. für jeden Satelliten der Name (name), der Präfix (prefix), die Stage-Tabelle (stage), der Hub (hub)oder Link (link) und eine Beschreibung (description) angegeben. Ähnliches gilt auch für die Hubs und Links.

Wie lässt sich diese Struktur noch weiter vereinfachen, so dass es einfacher wird, einen RawVault zu beschreiben?
- Das Attribut stage wird benötigt, weil angegeben werden muss, aus welcher Stage-Tabelle der Satellit geladen wird. Das wäre nicht nötig, wenn das Element sat innerhalb des Elements stage definiert würde.
- Das Attribut hub wird benötigt, weil angegeben werden muss, auf welchen Hub oder Link sich der Satellit bezieht. Das wäre nicht nötig, wenn das Element sat innerhalb des Elements hub bzw. Link definiert würde.
- Das Attribut prefix hat den gleichen Inhalt wie das Attribut name, nur in Großbuchstaben statt in Kleinbuchstaben. Das wäre nicht nötig, wenn man festlegt, dass das immer so sein soll.
Außerdem werden bei den csv-Dateien im Abschnitt file_imports/import die Felder (fields) und der eindeutige Schlüssel (unique_key) definiert und im Abschnitt stages in der zugehörigen Stage-Tabelle werden die Felder und der eindeutige Schlüssel erneut angegeben. Das wäre nicht nötig, wenn man die Festlegung trifft, dass die Felder in db_source/table und im zugehörigen file_import/imort/file identisch sind.
Es ist also möglich, eine noch kompaktere Darstellung zu erzeugen, wenn man die Struktur der xml-Datei umstellt und zusätzliche Konventionen festlegt.
Die neue Version (schema_version=“2″) von RawVault.xml sieht jetzt so aus:

- Der Abschnitt system enthält Systemparameter und wird hier nicht näher beschrieben.
- Der Abschnitt nat_keys enthält die Definition aller im DataVault verwendeten NaturalKeys.
- Der Abschnitt db_sources beschreibt alles weitere.
Im Abschnitt db_sources werden zunächst die Source-Schemata in der DWH-Datenbank (db_source) definiert.
Für jedes Source-Schema (db_source) wird definiert, aus welchem Übergabeverzeichnis (file_import) die CSV-Dateien für das Source-Schema übernommen werden und welche Tabellen (table) in diesem Source-Schema enthalten sind.

Für jede Tabelle wird beschrieben, welche Felder (fields) sie enthält, und aus welchen Feldern der eindeutige Schlüssel (unique_key) für die Records in der Tabelle besteht. Wenn die Tabelle aus einer CSV-Datei eingelesen werden soll, wird der Name der zugehörigen CSV-Datei angegeben (import). Außerdem wird beschrieben, welche Stage-Tabelle aus dieser Source-Tabelle befüllt wird.

Im Element stage wird definiert, welche Hubs (hub) aus dieser Stage-Tabelle gefüllt werden und damit auch, welche NaturalKeys (hub/nat_key) in dieser Stage-Tabelle enthalten sind und aus welchen Feldern der Source-Tabelle (source_field) sie bestückt werden oder mit welcher SQL-Funktion sie erzeugt werden (definition). Wenn an dem Hub auch ein Satellit aus dieser Stage-Tabelle geladen wird, dann gibt es im Hub noch eine Definition für den Satellite (sat).
Weiter wird definiert, welche Links aus dieser Stage-Tabelle gefüllt werden (link). Hier werden die NaturalKeys aufgeführt, die der Link verbindet (link/nat_key). Wenn an dem Link auch ein Satellit aus dieser Stage-Tabelle geladen wird, dann gibt es im Link noch eine Definition für den Satellite (sat).

Da in dieser Version der RawVault.xml der Name der Satelliten aus dem Stage-Namen und dem Hub- bzw. Link-Namen erzeugt wird, wäre es nicht möglich aus einer Stage für einen Hub mehrere Satelliten zu definieren. Dies ist jedoch notwendig, wenn man z.B. in der inkrementellen Entwicklung einen vohandenen Satelliten durch eine neue Version ersetzen will, oder wenn man die Payload eines Satelliten auf mehrere Satelliten aufteilen will. Dafür wurde in dieser Version das Attribut sat_suffix am Element sat eingeführt. Hier ist ein Beispiel dafür:

Diese neue Version der RawVault.xml (mit schema_version=“2″) benötigt noch 591 Zeilen im Vergleich zu den 919 Zeilen der vorherigen Version RawVault.xml.
In den nächsten Beiträgen werde ich versuchen – ausgehend von diesem Raw Vault – den Business Vault unseres Data Warehouse zu beschreiben.
Schreibe einen Kommentar