Data Vault Modellierung anhand eines Kassenbons


Projektarbeit, 2018

21 Seiten, Note: 1,0


Leseprobe

Inhalt

I. Inhaltsverzeichnis

II. Abbildungsverzeichnis

III. Tabellenverzeichnis

IV. Abkürzungsverzeichnis

1 Projektziele und Vorbereitungen

2 Projektgrundlage Beispiel-Kassen-Bon und Begriffsdefinition Warenkorbanalyse

3 Vorbereitende Aktivitäten und Projektplanung

4 Star-Schema
4.1 Das Star-Schema
4.2 Modellierung der Aufgabenstellung im Star-Schema
4.3 Faktentabelle Bon_Bonposition
4.4 Dimensionstabellen
4.4.1 Dimensionstabelle DimOrt
4.4.2 Dimensionstabelle DimProdukt
4.4.3 Dimensionstabelle DimZeit

5 Data Vault
5.1 Begriffsklärung Data Vault – Data Vault 2
5.2 Was ist Data Vault?
5.3 Hubs
5.4 Links
5.5 Satelliten
5.6 Zusammenfassung Data Vault
5.7 Modellierung eines Kassen-Bon Data Vault Modells
5.7.1 Vorgehensweise
5.7.2 Datenmodell
5.7.3 Hubs
5.7.4 Link
5.7.5 Satelliten und Referenztabelle

6 Vor- und Nachteile der eingesetzten Modellierungstechniken und Fazit
6.1 Vor- und Nachteile Star-Schema
6.2 Vor- und Nachteile Data Vault
6.3 Fazit

V. Verzeichnis der Anhänge

VI. Anhänge und Materialien
Anhang 1. Kassenbon Aldi Süd
Anhang 2. Original-Text Definition Data Vault von Linstedt und Graziano
Anhang 3. BI-Architektur mit Data Vault
Anhang 4. Klassisches Data Vault Datenmodell
Anhang 5. Vorgehensweise Modellierung Data Vault Modell (Steps to modeling with Data Vault)
Anhang 6. Entity Naming Conventions
Anhang 7. Verworfenes Data Vault Datenmodell

7 Literaturverzeichnis

II. Abbildungsverzeichnis

Abbildung 1- Datenschema Kassen-Bon nach dem Star-Schema

Abbildung 2 - Data Vault Datenmodell eines Kassen-Bons

Abbildung 3- Kassen-Bon Aldi Süd

Abbildung 4 - BI-Architektur mit Data Vault - Angelehnt an "Building a Scalable Data Warehouse with Data Vault 2.0" Figure 2.2 (Linstedt und Olschimke 2016, S. 22)

Abbildung 5 - Darstellung eines klassischen Data Vault Datenmodells mit Hub, Links und Satelliten (Hultgren 2015, S. 6)

Abbildung 6 - Vorgehen zur Modellierung eines Data Vault Modells (Hultgren 2015, S. 9)

Abbildung 7 - Verworfenes Data Vault Datenmodell

III. Tabellenverzeichnis

Tabelle 1 - Data Vault Naming Conventions aus Data Vault Modeling Guide 2.0. 2(Linstedt 2018, S. 16)

IV. Abkürzungsverzeichnis

ETL Extract, Transform, Load

IUBH IUBH University of Applied Sciences Bad Honnef S. Seite

1 Projektziele und Vorbereitungen

Das Projektziel und der Projektzweck des auf den nächsten Seiten folgenden Projektberichts stammen aus Aufgabenbeschreibung der IUBH für das Fach Business Intelligence (IWBI02). Diese möchte ich als Einstieg zunächst kurz zitieren:

Agile Softwareentwicklung hat sich in vielen BI-Projekten etabliert. Immer häufiger wird dabei „Data Vault“ als geeignete Technik für die Datenmodellierung genannt. Die Befürworter der Technik sehen darin die ideale Vorgehensweise für ein effizient erweiterbares Data Warehouse. Kritiker sind diesbezüglich skeptisch und befürchten unnötige Komplexität.

Das Ziel der Arbeit ist die Darstellung der Data Vault Modellierungstechnik am Beispiel der Warenkorbanalyse mithilfe des Kassenbons. Der Schwerpunkt liegt in der Entwicklung der Datenmodelle. Zunächst mithilfe des bekannten „Star-Schema“, anschließend mit der Modellierungstechnik „Data Vault“. Hierzu gilt es zunächst die Grundlagen der Data Vault Modellierung zu recherchieren. Abschließend sind die Vor- und Nachteile der eingesetzten Techniken darzustellen.(IUBH 2018)

Aus der wiedergegebenen Aufgabenstellung ergeben sich diese vier Teilziele:

- Entwicklung eines Datenmodells für einen Kassen-Bon nach dem Star-Schema mit einer Fakt- (Bon- bzw. Bonposition) und drei Dimensionstabellen (Produkt, Zeit, Ort)
- Recherche der Grundlagen von Data Vault
- Entwicklung eines Datenmodells für einen Kassen-Bon mit Data Vault
- Dartstellen der Vor- und Nachteile von Star-Schema und Data Vault

2 Projektgrundlage Beispiel-Kassen-Bon und Begriffsdefinition Warenkorbanalyse

Grundlage für die in den Datenmodellen gewählten Attribute eines Kassen-Bons ist ein Standard-Kassen-Bon der Discounter-Kette Aldi-Süd. Ein Beispiel-Kassen-Bon ist in Anhang 1 dieses Dokuments beigefügt. Dieser Kassenbon weist, neben klassischen Inhalten wie Datum, Uhrzeit und Filiale noch diese Merkmale auf:

- Wird ein Artikel häufiger als einmal gekauft, wird er mehrfach als einzelne Bon-Position mit der Menge 1 aufgeführt.
- Im Datenmodell werde ich dennoch eine Mengenangabe je Bon-Position vorsehen, um gleiche Artikel mit dem gleichen Preis zusammenfassen zu können.
- Jeder Artikel wird mit einer Artikelnummer und einer Artikelbezeichnung beschrieben.
- Manche Informationen des Kassen-Bons, wie etwa die Zahlungsart, werden zunächst nicht berücksichtigt.

Die zu modellierenden Datenmodelle sollen für den Zweck einer Warenkorbanalyse verwendet werden. Der Kassen-Bon mit seinen Metadaten und den auf dem Kassen-Bon aufgeführten Artikeln repräsentieren einen Warenkorb, den es zu analysieren gilt.

3 Vorbereitende Aktivitäten und Projektplanung

Aufgrund der Überschaubarkeit der Projektgröße wurde bewusst auf eine detaillierte Meilensteinplanung und Zeitplanung verzichtet. Da die Projektaufgabe im Rahmen eines Teilzeit-Studiums bearbeitet wird, wurde ebenfalls auf eine detaillierte Terminplanung verzichtet. Berufliche und familiäre Verpflichtungen, die häufig ungeplant hohe Zeit beanspruchen können, lassen dies auch nicht zu. Eine aufwändige Terminplanung für das Projekt wäre somit nur vage und ohne Zusatznutzen gewesen.

Vorbereitend zur Bearbeitung der Projektaufgabe wurden diese Aktivitäten identifiziert:

- Sichten und analysieren der Bestandteile eines realen Kassen-Bons anhand eines Kassen-Bons von Aldi Süd, um anhand eines realen Beispiels ein besseres Verständnis für die Ausgangslage der gegebenen Daten zu erhalten.
- Auswahl eines geeigneten Tools zur Literaturverwaltung um eine effiziente Dokumentation zu unterstützen. Hier wurde das Tool Citavi 6 gewählt. Für das Tool wird den Studierenden der IUBH eine Lizenz bereitgestellt. In einer vergangenen Hausarbeit wurde von mir Zotero genutzt, jedoch war das Handling etwas umständlich.
- Recherche und Beschaffung geeigneter Literatur zur Entwicklung des Datenmodells nach dem Star-Schema.
- Recherche und Beschaffung geeigneter Literatur zur Entwicklung des Datenmodells nach dem Data Vault Ansatz.
- Auswahl eines geeigneten Tools zur Erstellung von Datenmodellen. Die Wahl fiel auf das Tool Visual Paradigm, das bereits aus dem Kurs IOBP (Objektorientierte Programmierung) bekannt war.
- Modellierung des Datenmodells nach dem Star-Schema.
- Dokumentation der Grundlagen zum Star-Schema und des entwickelten Datenmodells.
- Recherche der Grundlagen von Data Vault in der ausgewählten Literatur und mittels Online-Recherche.
- Dokumentation der recherchierten Informationen zu Data Vault.
- Modellierung eines Datenmodells nach dem Data Vault Ansatz. Gleichzeitig vertiefende Recherchen zu Data Vault um Fragen, die während der Modellierung entstehen, zu klären.
- Dokumentation des erstellten Datenmodells und der recherchierten Erkenntnisse.
- Bewertung der beiden Ansätze.

4 Star-Schema

4.1 Das Star-Schema

Zunächst wird ein Kassenbon mit den in der Aufgabenstellung beschriebenen Fakten- und Dimensionstabellen als Star-Schema modelliert. In seinem „A Dimensional Modeling Manifesto“ beschreibt Ralph Kimball, welche Anforderungen von einem Datenmodell, das nach dem Star-Schema aufgebaut ist, unter anderem erfüllt sein müssen:

- Jedes Datenmodell besteht aus einer Fakten-Tabelle mit einem zusammengesetzten Schlüssel und einer Menge an kleineren Tabellen, den Dimensions-Tabellen
- Jede Dimensions-Tabelle hat einen Nicht-Zusammengesetzten Primärschlüssel der exakt zu einer der Komponenten des zusammengesetzten Schlüssels der Fakten-Tabelle gehört
- Die Fakten-Tabelle enthält eine oder mehrere Fakten, die nummerisch und additiv sind.
- Dimensions-Tabellen enthalten meist beschreibende Text-Informationen. (Kimball 1997)

4.2 Modellierung der Aufgabenstellung im Star-Schema

Das dargestellte Datenschema zeigt die Struktur eines Kassenbons nach dem Star-Schema:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1- Datenschema Kassen-Bon nach dem Star-Schema

4.3 Faktentabelle Bon_Bonposition

Grundsätzlich treffe ich bei dem Datenschema die Annahme, dass eine BonID Unique, also einmalig und eindeutig, ist. Die BonID kommt in der Gesamtmenge aller Kassen-Bons nur einmal vor. Dies kann zum Beispiel sichergestellt werden, indem jeder physisch vorhandene Kassenbon tatsächlich eine eindeutige ID besitzt. Die BonID kann somit als echter Schlüssel verwendet werden. Alternativ kann auch durch vorgelagerte ETL-Prozesse je Kassenbon eine eindeutige ID über einen künstlichen Schlüssel erzeugt werden.

Da ein Produkt mehrfach, mit zum Teil auch unterschiedlichen Preisen, auf einem Kassen-Bon erscheinen kann (ein gekaufter Artikel ist im Preis reduziert der zweite identische Artikel nicht), habe ich mich dagegen entschieden, die Kombination BonID und Produktnummer als zusammengesetzten Primärschlüssel einzusetzen. Mir erschien es als sinnvoller, die BonID zusammen mit der BonPosID (Bon-Positions-ID) als zusammengesetzten Primärschlüssel zu verwenden, da diese Kombination ganz sicher eindeutig ist.

Die Option, ohne die BonID auszukommen und stattdessen einen zusammengesetzten Primärschlüssel aus der Bon-Position, dem Ort und dem Datum inkl. Uhrzeit zu bilden, wurde ebenfalls geprüft, jedoch verworfen. Es kann passieren, dass an einem Ort gleichzeitig zwei oder mehr Bons erstellt werden, wenn zwei oder mehr Kassen geöffnet sind. Die sicherste Variante, Datensätze eindeutig zu identifizieren ist deshalb die gewählte Variante: Eine eindeutige BonID und eine eindeutige BonPosID.

Die Faktentabelle enthält die Werte BonPosUmsatz und BonPosMenge. BonPosUmsatz zeigt den Gesamtumsatz je Bon-Position. BonPosMenge enthält die Menge des gekauften Produkts je Bon-Position. Enthält ein Kassen-Bon einen Artikel mit demselben Preis mehrfach, könnten Menge und Preis der Bon-Position im vorgelagerten ETL-Prozess bereits aggregiert werden. Wird auf eine Aggregation innerhalb einzelner Kassen-Bons verzichtet, so beträgt die Menge immer 1.

Als Fremdschlüssel werden in der Faktentabelle die Schlüssel OrtLocationID, ZeitTimestampID und und ProduktProduktnummer geführt. Sie stellen das Bindeglied zu den angegliederten Dimensionstabellen dar, die im nächsten Abschnitt näher beschrieben werden.

Um die Anforderungen an das Star-Schema zu erfüllen, sind in der Faktentabelle keine Attribute enthalten.

4.4 Dimensionstabellen

4.4.1 Dimensionstabelle DimOrt

Die Dimensionstabelle DimOrt enthält als Primärschlüssel eine LocationID, welche den Ort eindeutig identifizierbar macht. Die LocationID entspricht der Filialnummer des Kassen-Bons, ist also ein natürlicher Primärschlüssel. Im Attribut Ort wird der Name des Orts in Klartext dargestellt.

4.4.2 Dimensionstabelle DimProdukt

In der Dimensionstabelle DimProdukt wird die Produktnummer als natürlicher Primärschlüssel verwendet. Weitere Attribute sind die Produktbezeichnung, der Steuersatz und die Produktgruppe. Die Produktgruppe ist eine Information, die nicht direkt aus dem Kassen-Bon extrahiert wird, sondern im Rahmen der ETL-Prozesse angereichert wird. Der Produktpreis ist in der Dimensionstabelle Produkt nicht enthalten, da der tatsächliche Preis der einzelnen Bon-Position des Kassen-Bons bereits in der Faktentabelle enthalten ist. Der Preis in der Dimensionstabelle Produkt könnte nur den allgemein gültigen Produktpreis darstellen und würde sich auf sämtliche Kassen-Bons auswirken. Dies sehe ich für den Zweck einer Warenkorbanalyse als nicht sinnvoll an und würde zudem den Benutzer verwirren, wenn er sich bei der Datenanalyse zwischen zwei Produktpreisen entscheiden müsste.

4.4.3 Dimensionstabelle DimZeit

Die Dimensionstabelle DimZeit enthält verschiedene Zeiteinheiten, nach denen die einzelnen Kassen-Bons sowie die Bon-Positionen vom Benutzer ausgewertet werden können. Als Primärschlüssel dient die TimestampID die auch auf dem Kassen-Bon als Datum-/Zeitstempel zu finden ist.

5 Data Vault

5.1 Begriffsklärung Data Vault – Data Vault 2.0

Im weiteren Verlauf des Projektes wird der Begriff Data Vault häufig genannt werden. Wann immer Data Vault verwendet wird, beziehe ich mich dabei auf den aktuellen Standard Data Vault 2.0.

5.2 Was ist Data Vault?

Die Forschungen, um den Data Vault Ansatz zu entwickeln, begannen in den frühen 90ern. Dan Linstedt ist der Erfinder von Data Vault(Linstedt und Graziano 2011, 2 & 14).

Data Vault ist ein Konstrukt aus detaillierten, historisierten, normalisierten Tabellen. Es ist ein Ansatz, der das Beste aus der dritten Normalform und dem Star-Schema vereint. Das Design sei flexibel, skalierbar, konsistent und an die Anforderung eines Unternehmens anpassbar. Es ist ein Datenmodell, das speziell entwickelt wurde, um die Anforderungen eines modernen Data Warehouse zu treffen. Das Data Vault Modell folgt allen Definitionen eines klassischen Data Warehouse, wie es von Bill Inmon definiert wurde. Mit einer Ausnahme: Data Vault ist funktionsbasiert (im Original: functionally-based), nicht themenorientiert.(Linstedt und Graziano 2011, S. 1)Ungekürzter Originaltext in Anhang 2.

Ein wesentliches Merkmal des Data Vault Modells sind die drei verschiedenen Entitäts-Typen, die darin zum Einsatz kommen: Hubs, Links und Satelliten. Sie werden in den nachfolgenden Abschnitten detailliert beschrieben. Die Flexibilität des Data Vault Modells wird mit der starken Normalisierung oder Separierung der Datenfelder in den einzelnen Tabellen begründet.(Linstedt und Graziano 2011, S. 3)Data Vault speichert, entgegen anderer Ansätze zur Data Warehouse Modellierung, Schlüssel, deskriptive Attribute und Beziehungsinformationen konsequent in getrennten Tabellen.(Trahasch und Zimmer 2016, S. 74)

Die im Anhang 3 dargestellte Grafik gibt nochmals einen kurzen Überblick über die Stellung von Data Vault als Modell für ein Data Warehouse innerhalb der BI-Referenzarchitektur. Data Vault kommt zwischen der Schicht der vorgelagerten Staging Area und der darauffolgenden Informationsbereitstellungs-Schicht zum Einsatz.

5.3 Hubs

Ein Hub bezeichnet eine Tabelle mit eindeutigen, natürlichen Schlüsseln. Diese werden Business Keys genannt. Beispiele hierfür sind Rechnungsnummer, Artikelnummer oder Kundennummer. Zusätzlich werden als Werte das Ladedatum (Load Date), die Datenquelle (Data Source) und ein Hash-Key gespeichert. Im Load Date wird das Ladedatum des Business Keys im Data Warehouse nachvollzogen. Im Feld Datenquelle wird nachvollzogen, aus welchem Quellsystem der Business Key kommt.(Linstedt 2018, 4 ff.) Ein Hub enthält keine weiteren beschreibenden Daten, also keine Attribute außer den erwähnten Pflichtfeldern.(Hultgren 2015, S. 5)

Linstedt definiert weitere Regeln für einen Hub in seiner Data Vault Data Modeling Specification 2.0.2 (Auszug):

- Ein Hub muss mindestens einen Business Key enthalten.
- Der Business Key eines Hubs muss 1:1 dem künstlichen Schlüssel (Hash Key) entsprechen, wenn dieser verwendet wird.
- Ein Hub darf keine Mischung aus verschiedenen Business Keys enthalten, die eigentlich für sich alleinstehen. Zum Beispiel sind Kundennummer und Rechnungsnummer zwei eigenständige Business Keys, die als zwei verschiedene Hubs zu definieren sind.
- Ein Hub sollte mindestens einen Satelliten bedienen. Hubs ohne Satelliten zeugen von einer schlechten Quelldaten-Qualität. Hubs ohne Satelliten haben keinen Kontext.
- Der Business Key eines Hubs muss in seiner Umgebung alleinstehend sein. Das heißt er ist die eindeutige Grundlage für den Benutzer, um Informationen im Quellsystem zu finden.
- Die Pflichtfelder Load Date Time Stamp und Record Source (Datenquelle) dürfen kein Teil des Primärschlüssels sein. (Linstedt 2018, S. 11–12)

5.4 Links

Links sind die flexible Komponente des Data Vault Models. Sie halten alle Beziehungen von zwei oder mehr zusammengehörenden Business Keys (also von Hubs) zusammen. Dort, wo Business Keys miteinander interagieren, wird ein Link erstellt. Links können zum Beispiel auf Transaktionen, Beziehungen oder Interaktionen zwischen Geschäftsobjekten (Business Keys) beruhen. Ein Link ist also ein Kreuzungspunkt von Business Keys.(Linstedt und Graziano 2011, S. 7–9)

Weitere Regeln für einen Link sind nach Linstedt wie folgt definiert (Auszug):

- Ein Link muss zwei oder mehr Hub Primärschlüssel (Als Fremdschlüssel) enthalten.
- Ein Link kann niemals von einem anderen Link abhängen oder sich auf ihn beziehen.
- Ein Link kann zwei Schlüssel desselben Hubs enthalten um zum Beispiel eine hierarchische Beziehung darzustellen.
- Der Load Date Time Stamp eines Links muss ein Attribut des Links sein und darf niemals Teil des Primärschlüssels sein.
- Der zusammengesetzte Primärschlüssel eines Links muss unique (einzigartig und eindeutig) sein. Er enthält alle Business Keys (oder Hashes) der Ursprungs-Hubs. Ist dieser zu lang, kann aus den Ursprungs-Hubs auch ein Hash-Primärschlüssel erzeugt werden.
- Ein Link kann keinen oder beliebig viele Satelliten haben.
- Ein Link enthält ein Feld mit der Datenquelle, von der seine Informationen stammen (Record Source). (Linstedt 2018, S. 10–14)

5.5 Satelliten

Die Satelliten enthalten beschreibende Informationen zu einem Business Key oder Link. Es kann mehrere Satelliten geben, um ein und denselben Hub oder Link zu beschreiben. Jedoch kann ein Satellit selbst nur einen Hub oder Link beschrieben. Die Pflichtfelder von Satelliten sind der künstliche Schlüssel des Hubs oder Links, den er beschreibt, der Zeitstempel des Ladezeitpunkts sowie die Datenquelle. Zudem enthält der Satellit die betreffenden beschreibenden Informationen des Hubs oder Links.(Hultgren 2015, S. 6)

Die Satelliten werden nur mit neuen Daten beschrieben, wenn es in den Daten mindestens eine Änderung gab. Der zusammengesetzte Primärschlüssel eines Satelliten ergibt sich aus dem Primärschlüssel des Links oder Hubs, den er beschreibt, zusammen mit dem Load Date Timestamp, also dem Zeitstempel des Ladezeitpunkts.(Linstedt und Graziano 2011)

Weitere Regeln für einen Satelliten sind nach Linstedt (Auszug):

- Ein Satellit kann niemals eigene Primärschlüssel, künstliche Schlüssel oder eigene Hash-Keys generieren.
- Ein Satellit muss mindestens ein beschreibendes Element über den Hub oder Link enthalten, dem er zugeordnet ist.
- Ein Satellit kann aggregierte oder systemseitig erstellte Attribute enthalten.
- Der Zweck eines Satelliten ist, Daten im Zeitverlauf zu speichern. (Linstedt 2018, S. 14–15)

5.6 Zusammenfassung Data Vault

Linstedt und Graziano vergleichen das Zusammenspiel von Hubs und Links in einem Data Warehouse mit dem menschlichen Skelett und dem Rückgrat. Ohne dies könnte ein Mensch nicht existieren. Sie geben dem Datawarehouse notwendige Struktur. Sie formen die Grundlagen, wie die Daten zusammenhängen. Danach werden noch Satelliten hinzugefügt, sie werden verglichen mit der Haut, den Muskeln oder den Organen des Menschen. Sie fügen Farben, Frisuren, Augen und all die anderen Attribute hinzu, die benötigt werden um einen Menschen zu beschreiben.(Linstedt und Graziano 2011, S. 5)Die im Anhang 4 dargestellte Abbildung eines klassischen Data Vault Datenmodells zeigt einen zentralen Link, zwei Hubs und drei Satelliten. Mit etwas Phantasie lässt sich erahnen, dass der Link das Rückgrat darstellt und die Hubs weiteren Skelettknochen.

[...]

Ende der Leseprobe aus 21 Seiten

Details

Titel
Data Vault Modellierung anhand eines Kassenbons
Hochschule
Internationale Fachhochschule Bad Honnef - Bonn
Veranstaltung
Business Intelligence
Note
1,0
Autor
Jahr
2018
Seiten
21
Katalognummer
V974189
ISBN (eBook)
9783346329349
ISBN (Buch)
9783346329356
Sprache
Deutsch
Anmerkungen
Projektbericht Projekt Business Intelligence
Schlagworte
data, vault, modellierung, kassenbons, data vault, bi, agile data warehouse, data modeling
Arbeit zitieren
Monika Arbter-Hubrich (Autor), 2018, Data Vault Modellierung anhand eines Kassenbons, München, GRIN Verlag, https://www.grin.com/document/974189

Kommentare

  • Noch keine Kommentare.
Im eBook lesen
Titel: Data Vault Modellierung anhand eines Kassenbons



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden