{"id":456,"date":"2014-07-13T17:35:33","date_gmt":"2014-07-13T15:35:33","guid":{"rendered":"http:\/\/konsilium.de\/blog\/?p=456"},"modified":"2022-07-06T22:01:17","modified_gmt":"2022-07-06T20:01:17","slug":"data-vault-buch-von-hans-hultgren-review","status":"publish","type":"post","link":"https:\/\/konsilium.de\/blog\/2014\/07\/13\/data-vault-buch-von-hans-hultgren-review\/","title":{"rendered":"Rezension: Hans Hultgren, „Modeling the agile Data Warehouse with Data Vault“"},"content":{"rendered":"\n


Es gibt wenig Literatur zum Thema „Data Vault“ – und noch weniger von der Art, die das Thema im Ganzen und in sich schl\u00fcssig darstellt. Daher bin ich vor ein paar Jahren mit gro\u00dfem Interesse auf dieses Buch von Herrn Hultgren gesto\u00dfen. „Endlich mal ein komplettes Buch zum Thema“, dachte ich. Ich wurde nicht entt\u00e4uscht, wenn auch Fragen offen blieben – so viel vorab. Aber nun zum Buch im Detail.<\/p>\n\n\n\n

Hultgren unterscheidet sich in angenehmerweise von den sehr technisch orientierten Ausf\u00fchrungen, die es bis dato von Dan Linstedt gab. Mein Einstieg in die Data Vault Thematik waren die „Series 1 – 5“, die Dan damals im Web ver\u00f6ffentlichte. Das Buch von Hultgren erl\u00e4utert in den ersten Kapiteln, was ein Data-Vault (DV) ausmacht, die drei Kern-Entit\u00e4tstypen werden erkl\u00e4rt – das sind nat\u00fcrlich die Grundlagen, die in ein solches Buch geh\u00f6ren. Insbesondere f\u00fcr Data-Vault-Beginners wird im Kapitel „The colours of Data-Vault“ das Prinzip der De-Komposition erkl\u00e4rt – von Hultgren auch „Ensemble Modeling“ genannt. Mit Hilfe von 3-farbig eingef\u00e4rbten Entit\u00e4ten wird anschaulich der Zerlegungsprozess erkl\u00e4rt. Somit erschlie\u00dfen sich dem Leser schnell die Unterschiede zur 3NF-Modellierung.<\/p>\n\n\n\n

Hultgren erkl\u00e4rt weniger mit welcher SQL-Syntax welcher Entit\u00e4tstyp beladen wird. Er erl\u00e4utert vielmehr die grunds\u00e4tzliche Herangehensweise der Enterprise-Data-Warehouse-Modellierung. Mir hat das Buch damals geholfen, auf meine Frage, „wie fange ich es grunds\u00e4tzlich an?“. Als Beispiel nenne ich die HUB-Modellierung. Man k\u00f6nnte denken, dies sei die am einfachsten zu modellierende DV-Komponente. Hultgren erkl\u00e4rt, warum oftmals genau das Gegenteil der Fall ist. Was genau ist ein „natural“ (ein echter) Business-Key? Wie finde ich dies heraus? Gut gefallen haben mir dabei klare Statements zu den Fragen, ob bzw. wie weit man in der Modellierung von Hubs Super-Typing betreiben sollte oder nicht.<\/p>\n\n\n\n

Analog stellt sich gleiche Frage f\u00fcr die Link-Modellierung. Hultgren erkl\u00e4rt das Prinzip der „Unit-of-work“ zur Validierung von „natural relationships“. Erkl\u00e4rt werden auch der „Same-As-Link“ und der „Hierachical-Link“, beides rekursive Beziehungen. Zum Thema LINK gibt es mehrere Anwendungsbeispiele, erstmalig habe ich hier den Terminus „Unit-of-work“ kennengelernt. Es geht darum, die „korrekten“ (natural) Links zu modellieren. Er empfiehlt auf rawVault Ebene alle Links der Sourcen aufzunehmen (Auditierbarkeit) und f\u00fcr das businessVault die „nat\u00fcrlichen“ Beziehungen im Kontext eines unternehmensweiten Zielbildes f\u00fcr die Datenintegration vorzugeben. Er pl\u00e4diert daf\u00fcr, sich an den betrieblichen Prozessen zu orientieren, um die „echten“, „nat\u00fcrlichen“ Beziehungen zu identifizieren.<\/p>\n\n\n\n

Ebenfalls anschaulich erkl\u00e4rt – die korrekte Modellierung von transaktionalen Events: „An Event always requires a Hub“. Die Erkl\u00e4rung hierzu hat mich sehr an die Ausf\u00fchrungen von Kimble („The Data Warehouse Toolkit“) erinnert, in dem er erkl\u00e4rt, dass der Bon-Key einer Sales-Transaction als De-Generated-Key in die Faktentabelle mit aufzunehmen ist.<\/p>\n\n\n\n

Ein weiteres Kapitel lautet „Key-Alignment“. Ziemlich spannendes Thema, leider nur ein paar kurze Erl\u00e4uterungen. Diese gaben mir in einem Projekt jedoch entscheidene Impulse, bestimmte Modellierungsgrunds\u00e4tze nochmal zu \u00fcberdenken und entsprechende Richtlinien f\u00fcr die Modellierung abzuleiten. Das Bespiel Person (im rawVault) und Customer (im busVault) erkl\u00e4rt die Problematik sehr anschaulich – und passte zuf\u00e4llig gerade zum aktuellen Projekt. Auch gut, die Idee, einen „Layer-Connecting-Link“ zu erzeugen zwecks Data-Lineage-Analysen.<\/p>\n\n\n\n

Im Kapitel „Reference-Tables“ erl\u00e4utert der Autor seine Definition von Reference-Tables. Sehr gut gefallen hat mir dabei der Design-Ansatz der „Hub-based“-Reference-Tables. D.h. auch f\u00fcr Lookup-Tables werden Data-Vault-Standard-Kostrukte verwendet, um einheitliche Ladeprozesse verwenden zu k\u00f6nnen und das Modell konsistent zu halten im Sinne der „Lesbarkeit“. Im rawVault wird Redundanz vermieden und die Dimensionen k\u00f6nnen unterschiedliche zeitliche Sichtweisen abbilden (AS-WAS, AS-OF).
Hultgren erkl\u00e4rt, warum den Relationships im Data Vault grunds\u00e4tzlich eine m:n Kardinalit\u00e4t zugrunde liegt. Auch dies ist ein Effekt der Dekomposition – jenes Grundprinzip des Data Vault, das urs\u00e4chlich ist f\u00fcr die Robustheit des Datenmodells gegen\u00fcber Re-Engineering-Anf\u00e4lligkeiten.<\/p>\n\n\n\n

In den „Special Topics“ widmet sich Hultgren typischen Fragestellungen der Modellierung f\u00fcr den jeweiligen Entit\u00e4tstyp. Diese Kapitel empfand ich damals als sehr hilfreich. Als Beispiel nenne ich die HUB-Modellierung. Im Modellierungsprozess steht die Identifizierung von „Core-Business-Concepts“, wie Hans Hultgren die fachlichen Gesch\u00e4ftsobjekte der realen Welt nennt, an erster Stelle. Werden diese „falsch“ modelliert, so ist der Rest des Modells in Folge nat\u00fcrlich auch nicht zu gebrauchen oder muss bald einem Re-Engineering unterworfen werden. Ein Beispiel f\u00fcr die Schwierigkeiten der HUB-Modellierung: Angenommen ein unternehmensweit akzeptierter Business-Key, der einen „Kunden“ repr\u00e4sentiert, wird ben\u00f6tigt f\u00fcr die Modellierung des HUBs „KUNDE“. Was, wenn \u00fcber diesen Key im Unternehmen kein Konsens besteht? M\u00f6glicherweise verwenden verschiedene Abteilungen unterschiedliche Keys, um einen Kunden (in der jeweiligen Abteilungssicht) zu identifizieren. Fachanwender m\u00fcssen Ihre fachlichen Objekte mit „Ihren“ Keys identifizieren k\u00f6nnen, sonst sind die Daten f\u00fcr sie nicht auswertbar. Hultgren beschreibt hierf\u00fcr verschiedene L\u00f6sungsans\u00e4tze, drei davon m\u00f6chte ich kurz vorstellen.<\/p>\n\n\n\n

L\u00f6sung 1): Ein Business-Key wird als „Central-Business-Key“ bestimmt und ein entsprechender Hub nach „Schema F“ modelliert. Die „alternativen Business-Keys“ werden in einem separaten SAT modelliert, der keine Historie speichert (Type-1). Historie wird hier nicht ben\u00f6tigt. Ein Business-Key ist unver\u00e4nderlich – sonst ist er als solcher nicht zu gebrauchen.<\/p>\n\n\n\n

L\u00f6sung 2): Alle Business-Keys werden in der einen Business-Key-Spalte eines HUBs als eigene Instanzen gespeichert. Es wird einmalig festgelegt, dass alle Kontext-Informationen der SATs nur auf einen Typ der Business-Keys referenzieren („Central-Business-Key“). Die logische Verbindung dieses Business-Keys zu den alternativ gespeicherten Business-Keys erfolgt \u00fcber einen Same-As-Link.<\/p>\n\n\n\n

L\u00f6sung 3): F\u00fcr jeden alternativen Business-Key werden separate HUBs und LINKs modelliert. Diese Hubs sind „weak“, sie haben keinerlei Kontext-Information. Die zus\u00e4tzlichen Enit\u00e4ten erzeugen einen gewissen Overhead (zus\u00e4tzliche Tabellen und Beladeprozesse und verl\u00e4ngerte Join-Pfade) und z\u00e4hlt daher nicht zu Hultgren’s pr\u00e4ferierten L\u00f6sungen.<\/p>\n\n\n\n

Wie eine Data-Mart-Schicht vom Data-Vault aus beladen wird, ist aus meiner Sicht, eine sehr spannende Frage, \u00fcber die ich bisher noch \u00fcberhaupt keine Lekt\u00fcre irgendwo gefunden habe. Leider behandelt auch Hultgren diesen Thema nur oberfl\u00e4chlich. In meinem aktuellen Data-Vault-Projekt setzen wir eine bi-temporale Historisierung im businessVault um. Die „Best\u00fcckung“ der historisierten Dimensionen muss unterschiedlichen Anforderungen des Business gen\u00fcgen. Ich habe hierzu Use-Cases definiert f\u00fcr die zeitlichen Sichtweisen auf Fakten im multidimensionalen Kontext, also AS-WAS, AS-IS, AS-OF. Einen \u00e4hnlichen „Input“ w\u00fcrde ich in jedem Buch, das Data Vault im Detail erkl\u00e4ren will, erwarten.
Bez\u00fcglich Didaktik, Layout und Schreibstil gibt es sicherlich bessere B\u00fccher – nicht aber im Themenbereich Data Vault. Insgesamt empfehle ich dieses Buch f\u00fcr jeden, der einen Einstieg in das Thema „Data Vault“ sucht. Der Leser erh\u00e4lt viele Antworten auf typische Fragen, die sich w\u00e4hrend des Modellierungsprozesses stellen. Prima!<\/p>\n\n\n\n

\"\"
Hans Hultgren<\/figcaption><\/figure>\n","protected":false},"excerpt":{"rendered":"

Es gibt wenig Literatur zum Thema „Data Vault“ – und noch weniger von der Art, die das Thema im Ganzen und in sich schl\u00fcssig darstellt. Daher bin ich vor ein paar Jahren mit gro\u00dfem Interesse auf dieses Buch von Herrn Hultgren gesto\u00dfen. „Endlich mal ein komplettes Buch zum Thema“, dachte ich. Ich wurde nicht entt\u00e4uscht,… Weiterlesen »Rezension: Hans Hultgren, „Modeling the agile Data Warehouse with Data Vault“<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":842,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"neve_meta_sidebar":"","neve_meta_container":"","neve_meta_enable_content_width":"","neve_meta_content_width":0,"neve_meta_title_alignment":"","neve_meta_author_avatar":"","neve_post_elements_order":"","neve_meta_disable_header":"","neve_meta_disable_footer":"","neve_meta_disable_title":"","footnotes":""},"categories":[8,3,4,123],"tags":[37,93,36,122],"_links":{"self":[{"href":"https:\/\/konsilium.de\/blog\/wp-json\/wp\/v2\/posts\/456"}],"collection":[{"href":"https:\/\/konsilium.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/konsilium.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/konsilium.de\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/konsilium.de\/blog\/wp-json\/wp\/v2\/comments?post=456"}],"version-history":[{"count":12,"href":"https:\/\/konsilium.de\/blog\/wp-json\/wp\/v2\/posts\/456\/revisions"}],"predecessor-version":[{"id":2578,"href":"https:\/\/konsilium.de\/blog\/wp-json\/wp\/v2\/posts\/456\/revisions\/2578"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/konsilium.de\/blog\/wp-json\/wp\/v2\/media\/842"}],"wp:attachment":[{"href":"https:\/\/konsilium.de\/blog\/wp-json\/wp\/v2\/media?parent=456"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/konsilium.de\/blog\/wp-json\/wp\/v2\/categories?post=456"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/konsilium.de\/blog\/wp-json\/wp\/v2\/tags?post=456"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}