DWH42 Das Business Vault: Definition, Regeln und Architektur 5.

DWH42 Das Business Vault: Definition, Regeln und Architektur 5. Tagung der DDVUG am 30.03.2017, Frankfurt

23. - 24. Oktober 2017 Düsseldorf Maritim Hotel am Flughafen DWH4 2 Die jährlich in Europa und den USA stattfindende Konferenz zur Datenmodellierung Interessante Reden und Workshops Über 20 Sessions, die über vier Tracks laufen. Tauschen Sie sich mit den führenden Datenexperten der Welt aus den Bereichen data science, NoSQL, facilitation und enterprise architecture. Weitere Informationen: www.datamodelingzon e.eu 06/28/2024 2

Vault Definitionen Dan Linstedt: „Ein Quellsystem Vault - ein Data Vault Modell, welches 1:1 mit dem Quellsystem übereinstimmt. Es fehlt die Integration über die Geschäftsschlüssel, davon wird hochgradig abgeraten. Solange es keinen Grund gibt, Daten zu restrukturieren, landet man einfach alle Daten in einem Data Vault Modell.“ DWH4 2 Dan Linstedt: „Rohes Data Vault oder "Data Vault", ein Data Vault Modell, mit rohen Daten, einziger Zweck, die Integration über die Geschäftsschlüssel. Geschäftsschlüssel sind das Bindeglied zu den Geschäftsprozessen, sie beinhalten die gleiche Granularität und die gleiche semantische Definition über die gesamte Organisation / Unternehmen (horizontale Definition). Sie sind das direkte Bindeglied zum Geschäftsglossar.“ https://decisionlab.net/2015/05/22/universal-data-vault-a-hyper-generalized-data-vault-review-of-a-case-study-by-john-

Verantwortungsbereiche Datenqualität und Geschäftsregeln liegen in der Verantwortung des Fachbereiches. Das Enterprise Data Warehouse muss für eine klare Trennung dieser Verantwortlichkeiten sorgen. Daten und Datenquellen werden erst dann integriert, wenn der Fachbereich sie benötigt. Hier gelten zwei Prinzipien: DWH4 2 Geschäftsregeln werden nachgelagert implementiert. Sie werden in Richtung des Endbenutzers verschoben. Es wird zwischen Fakten und Wahrheit unterschieden.

Separation of Concerns Das wichtigste Prinzip im Bereich der Softwareentwicklung ist die "Trennung der Belange": Die Idee, dass Softwaresysteme in Bereiche aufgeteilt werden müssen, in denen sich Funktionalitäten kaum oder gar nicht überschneiden. Dieses Prinzip ist so zentral, dass es in so vielen Formen bei der Evolution von Methodologien, Programmiersprachen und Best Practices wiederfindet. DWH4 2 Dijkstra hat es 1974 erwähnt: “separation of concerns even if not perfectly possible is yet the only available technique for effective ordering of one’s thoughts”. https://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html

Das Business Vault DWH4 2 Dan Linstedt: „Das Business Data Vault sind weitere Data Vault Strukturen, jedoch auf einer höheren Granularitätsebene (Fokussiert auf Masterdaten, Konsolidierung, zusammengeführter Information, verschmolzener, aggregierter und geänderter Informationen)“. Es trifft die geschäftlichen Anforderungen und beinhaltet Daten, auf die nachgelagerte weiche Regeln angewendet wurden. https://decisionlab.net/2015/05/22/universal-data-vault-a-hyper-generalized-data-vault-review-of-a-case-study-by-john-

Unbekanntes Land: The BIG T Wie sieht die Struktur aus? Was sind die Treiber? Verwaltbarkeit DWH4 2 Wartbarkeit Erweiterbarkeit Nachvollziehbarkeit Skalierbarkeit http://prudenza.typepad.com/files/damhof dbm1108 eng2.pdf

Unbekanntes Land: The BIG T Transparenz, klare Strukturen, eine klare etablierte Position innerhalb der Prozesskette für jegliche Komponente. DWH4 2 Wiederverwendbarkeit von Funktionalität (Verhinderung von Duplikaten) http://prudenza.typepad.com/files/damhof dbm1108 eng2.pdf

Unbekanntes Land: The BIG T DWH4 2 Einfachheit der Prozesse: Lieber drei simple Prozeduren als eine komplexe Prozedur. Modularisierung von Funktionalität. Anzumerken ist, dass die Einfachheit eines Objektes oder einer Prozedur die Wiederverwendbarkeit bestimmt - wir haben dieses aus dem Bereich der Objektorientierung gelernt. http://prudenza.typepad.com/files/damhof dbm1108 eng2.pdf

Unbekanntes Land: The BIG T DWH4 2 Standardisierung: Nicht nur bei den Prozessschritten, sondern auch gerade im darunterliegenden Modell Nachvollziehbarkeit: Die gleichen Nachvollziehbarkeitund Historisierungsanforderungen müssen für die Ergebnisse von Datenableitungen (Anwendung von Geschäftsregeln) und Integrationsprozesse gelten http://prudenza.typepad.com/files/damhof dbm1108 eng2.pdf

Unbekanntes Land: The BIG T Effizienz- und Geschwindigkeitsoptimierung: Jedes mögliche Maß muss dem effizienten Gebrauch der vorhandenen Ressourcen unterliegen. Besondere Aufmerksamkeit ist der Abfolge der Prozesse zu schenken. Je effizienter der Datenlogistikprozess ist, desto vielversprechender ist die Geschwindigkeit DWH4 2 Testfähigkeit: Es besteht die ständige Bedrohung der Entflechtung von Datenlogistikprozessen, was sich hinsichtlich der Testbarkeit niederschlagen kann, wenn das Data Warehouse sich erweitert http://prudenza.typepad.com/files/damhof dbm1108 eng2.pdf

Zentrale Logik DWH4 2 Oftmals macht es Sinn nicht nur die Speicherung der Daten zu zentralisieren, sondern auch einige (alle?) der zusätzlichen Logiken, die erforderlich sind, bevor die diese als Information Marts für den Benutzer zur Verfügung gestellt werden. Diese Logiken werden oftmals als Geschäftsregeln, Kalkulationen oder Datenqualitätsregeln klassifiziert. http://dm-unseen.blogspot.de/2013/04/the-rule-raw-business-data-vault-data.html

Was ist eine Geschäftsregel? Aus einer Informationssystemperspektive ist eine formalisierte Geschäftsregel eine Beschränkung, die auf Daten ausgeübt wird. Das bedeutet, dass Schlüssel und Domänendefinitionen ebenfalls Geschäftsregeln sind. DWH4 2 Es gibt zwei Arten von Geschäftsregeln: Strukturelle und Nicht Strukturelle. http://dm-unseen.blogspot.de/2013/04/the-rule-raw-business-data-vault-data.html

Strukturelle Geschäftsregeln Strukturelle Geschäftsregeln sind Regeln, welche elementare Informationen strukturieren. Sie beinhalten Elementarbausteine um Datenmodelle zu erstellen. Es sind Domänen, Schlüssel, Abhängigkeiten, Fremdschlüssel-/Untermengenbeschränkungen und Basisentitäten. DWH4 2 Und Modellableitungs- und Modelltransformationsregeln um neue semantisch/logisch gleiche (elementare) Modellstrukturen zu erstellen. http://dm-unseen.blogspot.de/2013/04/the-rule-raw-business-data-vault-data.html

Nicht strukturelle Geschäftsregeln Nicht strukturelle Geschäftsregeln definieren Kalkulationen/Ableitungen, Beschränkungen und Dataqualitätsregeln, sowie strukturierte Reparaturregeln. DWH4 2 Von diesen sind die strukturellen Reparaturregeln die Interessantesten. Diese sind Regeln, welche auf Grundlage von abgeleiteten Daten und Kalkulationen Datenmodelle ändern beziehungsweise erweitern (sie erzeugen neue strukturelle Geschäftsregeln!). http://dm-unseen.blogspot.de/2013/04/the-rule-raw-business-data-vault-data.html

Abgeleitete Daten und Geschäftsregeln DWH4 2 Es besteht kein großer Unterschied bei der Behandlung von nicht strukturellen Geschäftsregeldaten und rohen (Quellsystem-) Daten. Eine Geschäftsregel ist nur ein kleines (Quellsystem-) Datenmodell, bei dem es passiert, dass es seine Daten von einem Data Vault ableitet und nicht von außerhalb. Es wird (normalerweise) in der gleichen Weise geladen und in dieselbe Art von Objekten geladen wie bei einem (rohen) Data Vault. Das heißt aus einer Metadatenperspektive können wir Informationen über die Nachvollziehbarkeit hinzusteuern und haben so auch eine bessere Kontrolle über die Regel/Daten/Metadaten wie bei einem von Quellsystem von außerhalb, aber das ist auch alles. http://dm-unseen.blogspot.de/2013/04/the-rule-raw-business-data-vault-data.html

Abgeleitete Daten und Geschäftsregeln Dan's "Business Data Vault" suggeriert, dass der Fachbereich die Aufsicht über die Daten (und Geschäftsregeldefinitionen) hat. Während dies oft der Fall ist, haben Geschäftsregeln manchmal eine mehr technische Herkunft wie Performance (Aggregationssatelliten), so ist das ein bisschen suggestiv. Demgemäß präferieren wir eher den Terminus (Business) Rule Vault, um die Wichtigkeit der Anwendung der Regel gegenüber der exakten DWH4 Fachbereichsdefinition, -spezifikation und Namensgebung 2 zu betonen. http://dm-unseen.blogspot.de/2013/04/the-rule-raw-business-data-vault-data.html

Das (Business) Rule Vault Dazu gehören alle DV Objekte, die alleine/hauptsächlich durch Geschäftsregeln getrieben zum Rule Vault gehören. Hervorzuheben ist, obwohl sich Rule Vault Objekte meist direkt auf DV Entitäten beziehen bzw. abhängig von DV Entitäten sind, dass wir sie nicht als zwei komplett unterschiedliche und unabhängige (Speicher-) Ebenen sehen sollen. Sie befinden sich in DWH4 der derselben Ebene, es sind nur zwei verschiedene 2 logische (Unter-) Schichten innerhalb des Data Vault. http://dm-unseen.blogspot.de/2013/04/the-rule-raw-business-data-vault-data.html

Business (Data) Vault und Business View Perspektiven DWH4 2 Auch mit dem Rule Vault müssen wir die Ergebnisse unserer Geschäftsregeln dem Fachbereich zur Verfügung stellen. Dafür nutzen wir das "Business View" Konzept von Ronald Damhof. Dieses bringt Rule und Raw Vault Objekte zusammen, um eine konsistente "Business View" über alle Daten zu liefern (eine "Wahrheit" im klassischen EDW Denken). Diese "Business Views" können auf verfügbare Unternehmens-, Industrie- oder Quellsysteminformationsmodellen basieren. Dieses Vorgehen reduziert im großen Maßstab Daten und Geschäftsregelkomplexität. http://dm-unseen.blogspot.de/2013/04/the-rule-raw-business-data-vault-data.html

Perspektiven Diese "Business Views" können über verschiedene Perspektiven in verschiedenen Strukturen (Dimensional, Normalisiert und Data Vault) und mit verschiedenen temporalen Aspekten (Jetzt, ein Zeitpunkt, eine Periode) implementiert werden. DWH4 2 Wir definieren ein Business Data Vault als Business View Perspektiven im Data Vault Format http://dm-unseen.blogspot.de/2013/04/the-rule-raw-business-data-vault-data.html

Perspektiven Diese Business Views sitzen zwischen unserem Data Vault und unseren Data Marts als eine entkoppelnde Schicht. Diese Schicht ist durch Informationsmodelle getrieben, welche unsere verschiedenen Wahrheiten als verschiedene Business Views behandeln. Diese Schicht sorgt für eine semantische Abstraktion und passt auch dann noch, wenn es zu einer strukturellen Änderungen vom Data Vault zu der Business View Perspektive kommt. DWH4 Ein Business Data Vault ist eine komplette Data Vault 2 Transformation eines Geschäftsinformationmodells. . http://dm-unseen.blogspot.de/2013/04/the-rule-raw-business-data-vault-data.html

Temporale Hilfstabellen http://tdan.com/data-vault-series-3-end-dates-and-basicjoins/5067 http://www.vertabelo.com/blog/technical-articles/datavault-series-the-business-data-vault http://roelantvos.com/blog/?p 1716 https://danlinstedt.com/allposts/datavaultcat/pit-bridgevalue/ DWH4 2 https://www.wherescape.com/blog/blog-posts/2013/july/ how-to-create-point-in-time-pit-in-wherescape-red/

Praxis Modellierung von Geschäftsregeln DWH4 2

Praxis: Verweise Business Rules http://www.businessrulesgroup.org/theBRG.php http://www.brcommunity.com/ http://tdan.com/business-rules-in-data-warehousing/4883 http://tdan.com/modeling-business-rules-what-data-models-do/5174 http:// tdan.com/modeling-business-rules-what-data-models-cannot-do/5190 http://tdan.com/a-repository-model-business-rules-part-i/4978 DWH4 2 http:// tdan.com/a-repository-model-business-rules-action-assertions/4987 http:// tdan.com/modeling-business-rules-data-driven-business-rules/5227

Praxis: Verweise Business Rules http:// www.sparxsystems.com/enterprise architect user guide/10/domain b ased models/modeling business rules.html http:// www.sparxsystems.com/enterprise architect user guide/9.2/domain based models/business rule modeling.html DWH4 2

Praxis: Business Rule Prinzipien Principles of the Business Rule Approach 1st Edition by Ronald G. Ross (Author) Ronald Ross beschreibt verschiedene Basisprinzipien, die er als "Das Business Rule Verfahren" beschreibt. Er glaubt, dass Regeln: in normaler Sprache ausgedrückt sein unabhängig von Prozeduren und Arbeitsabläufen (beispielsweise in verschiedenen Modellen) sein aufgebaut auf Fakten und diese Fakten auf Konzepten und Kategorien beruhen den Weg aufzeigen und/oder Verhalten in gewünschten Bahnen beeinflussen DWH4 2 Aufgeschrieben und ausdrücklich sein motiviert durch identifizierbare und wichtige Geschäftsfaktoren sein verfügbar für autorisierte Gruppen (beispielsweise durch gemeinsamen Besitz) sein aus einer einzigen Quelle kommen direkt durch die Menschen, die das relevante Wissen haben, definiert werden verwaltet sein sollen.

Praxis VIEWS DWH4 2

Praxis Gespeicherte Prozeduren DWH4 2

Praxis Tabellenwertfunktion en DWH4 2

Praxis DWH4 2 Befüllen von physischen Tabellen per Prozedur oder per ETL

Alles klar? Vielen Dank für die Aufmerksamkeit DWH4 2