Datenintegration von polystrukturierte Daten in ein Data Vault Modell

INHALTSVERZEICHNIS

i thesis

1 einleitung
1.1 Motivation
1.2 Zielsetzung
1.3 Abgrenzung
1.4 Aufbau der Arbeit

2 grundlagen
2.1 Die Welt der Daten
2.1.1 Daten, Informationen, Wissen
2.1.2 Dimensionen von Daten
2.1.3 Datenmodell
2.2 Modellierungstechniken
2.2.1 Strukturierte Daten
2.2.2 Halbstrukturierte Daten
2.2.3 Unstrukturierte Daten
2.3 Data Vault Modell
2.3.1 Motivation für Data Vault
2.3.2 Data Vault Grundlagen
2.3.3 Regeln der Data Vault Modellierung
2.3.4 Architektur
2.3.5 Data Vault 1.0 und 2.0

3 stand der technik und forschung
3.1 Integration halbstrukturierter Daten
3.1.1 JavaScript Object Notation
3.1.2 Extensible Markup Language
3.2 Integration unstrukturierter Daten

4. konzeption
4.1 Erweiterungen zur Integration halbstrukturierter Daten
4.1.1 Abflachen eines eingebetteten JSON-Dokuments
4.1.2 JSON-Array Daten im Data Vault Modell
4.1.3 Modellierung von XML-Dokumenten in das Data Vault Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Integration unstrukturierter Daten

5. entwurf
5.1 Anwendungsfall
5.2 Zielsetzung
5.3 Analyse der Quelldaten
5.3.1 Stammdaten
5.3.2 Bewegungsdaten
5.4 Planung .
5.4.1 Erstellung der ETL-Prozesse
5.4.2 Gesamtarchitektur
5.4.3 Source
5.4.4 Staging
5.4.5 Core
5.4.6 Mart
5.5 Mehrwert des Entwurfs

6. implementierung
6.1 Eingesetzte Technologien
6.2 Beschreibung der Implementierung
6.2.1 Extraktion
6.2.2 Integration
6.2.3 Data Mart
6.3 Bereitstellung von Dashboards

7. evaluierung
7.1 Überprüfung des Core-Datenmodells
7.1.1 Flexibilität und Erweiterbarkeit
7.1.2 Historisierung
7.2 Validierung der Daten
7.3 Optimierung des Dashboards
7.4 Bewertung der Implementierung

8. schlussbetrachtung
8.1 Zusammenfassung
8.2 Ausblick

ii anhang

a anhang
a.1 Beigelegte CD
a.2 Datenmodell
a.3 Gespeicherte Prozedur
a.4 Dashboard

literaturverzeichnis

ERKLÄRUNG

Ich versichere hiermit, dass ich die vorliegende Arbeit selbständig verfasst und keine anderen als die im Literaturverzeichnis angegebenen Quellen be-nutzt habe.

Alle Stellen, die wörtlich oder sinngemäß aus veröffentlichten oder noch nicht veröffentlichten Quellen entnommen sind, sind als solche kenntlich gemacht.

Die Zeichnungen oder Abbildungen in dieser Arbeit sind von mir selbst erstellt worden oder mit einem entsprechenden Quellennachweis versehen.

Diese Arbeit ist in gleicher oder ähnlicher Form noch bei keiner anderen Prüfungsbehörde eingereicht worden.

Darmstadt, 21. März 2021

Jie Xin

DANKSAGUNG

An dieser Stelle möchte ich mich bei allen Personen bedanken, die mich bei der Erstellung dieser Masterarbeit unterstützt haben.

Zunächst gilt mein ausdrücklicher Dank meinen betrieblichen Betreuern bei der MT AG1. Johannes Lin, der mit seinem Blick für Details konzeptionelle und inhaltliche Diskussion mit mir führte und der durch seine kritischen Fragen zur Entstehung dieser Masterarbeit beigetragen hat. Aike Sass, der immer ein offenes Ohr für verschiedene technische Fragestellungen hatte und mir mit wichtigen Tipps zur Seite stand. Außerdem möchte ich Svenja Küppers für das Korrekturlesen meiner Masterarbeit und Jürgen Günter, der mir ausführliche Informationen zur Verfügung gestellt hat, ganz herzlich be-danken.

Weiterhin möchte ich mich bei Prof. Dr. Peter Muth bedanken, der als Re-ferent während der Erstellung meiner Arbeit als Ansprechpartner zur Dis-kussion struktureller und inhaltlicher Fragestellungen zur Verfügung stand. Gleichzeitig hat er mir den notwendigen Freiraum und das Vertrauen ge-geben, diese Masterarbeit nach meinen eigenen Vorstellungen zu gestalten. Auch möchte ich Prof. Dr. Uta Störl meinen Dank aussprechen, die sich als Korreferentin die Zeit nahm mich zu betreuen.

Abschließend möchte ich mich besonders bei meiner Eltern bedanken, die mir während meiner gesamten Studienlaufbahn den nötigen Rückhalt gege-ben hat und mir in allen Lebenslagen unterstützend zur Seite stand.

ABSTRACT

Nowadays, data is significantly increasing in terms of volume, speed and diversity. This data comes as both structured and unstructured data. Struc-tured data could be transaction data from classic, relational systems such as a data warehouse system. Due to the increase in data volume in recent years, the amount of unstructured data such as text documents, images, videos or Internet of Things (IoT) has become more significant.

Companies are thus confronted with an increasing volume of data supplied by a variety of internal and external sources. The challenge here is to com-bine polystructured data, which does not conform to a system defined re-lational or tabular form link with traditional, structured data to carry out analysis. This data must be stored efficiently and integrated to derive useful business insights.

Traditional modelling techniques such as the Kimball approach and Inmon approach focus on modelling structured data. Due to the increasing amount of data collected and the agile project execution, scalability and flexibility are becoming more important characteristics of data modelling. Especially in terms of flexibility, traditional data modelling approaches face certain lim-its. Therefore, data vault modelling has been developed to overcome these limitations. But the data vault model was originally designed for structured data. In order to use this structured data combined with polystructured data, the data must be properly integrated.

This thesis focuses on the further development of different integration ap-proaches combining polystructured data with structured data into the data vault model. Based on a use case, some approaches are implemented and their preliminary and disadvantages are discussed. Furthermore, the result of these approaches are evaluated to ascertain whether they fulfil the char-acteristics of the data vault model.

ZUSAMMENFASSUNG

Heutzutage nehmen die Daten in Bezug auf Volumen, Geschwindigkeit und Vielfalt enorm zu. Diese Daten kommen sowohl als strukturierte Daten als auch als unstrukturierte Daten vor. Zu den strukturierten Daten zählen un-ter anderem Transaktionsdaten aus klassischen, relationalen Systemen wie beispielsweise ein Data Warehouse. Durch den Zuwachs des Datenvolumens in den vergangenen Jahren ist die Anzahl an unstrukturierten Daten wie z.B. Textdokumente, Bilder, Videos oder Internet of Things (IoT) stark gestiegen.

Unternehmen sehen sich somit mit dem steigenden Volumen an Daten kon-frontiert, welche aus einer Vielzahl von internen und externen Quellen ge-liefert werden. Hierbei besteht die Herausforderung darin, polystrukturier-te Daten mit traditionellen, strukturierten Daten zu verknüpfen, um diese analysieren zu können. Dabei müssen diese Daten effizient gespeichert und integriert werden, um daraus nützliche Geschäftserkenntnisse abzuleiten.

Die traditionellen Modellierungstechniken wie der Kimball-Ansatz und der Inmon-Ansatz konzentrieren sich auf die Modellierung strukturierter Daten. Aufgrund der zunehmenden Datenmengen, die gesammelt werden, und der agilen Projektausführung werden Skalierbarkeit und Flexibilität zu immer wichtigeren Merkmalen der Datenmodellierung. Insbesondere im Hinblick auf die Flexibilität stoßen traditionelle Datenmodellierungsansätze an ihre Grenzen. Um diese Einschränkungen zu überwinden, wurde die Data Vault Modellierung entwickelt. Das Data Vault Modell wurde jedoch für struk-turierte Daten konzipiert. Um strukturierten Daten mit polystrukturierten Daten zu kombinieren, müssen Integrationsprozesse entwickelt werden, um das Zusammenführen von Daten aus verschiedenen Datenbeständen mit un-terschiedlichen Strukturen in das Data Vault Modell zu ermöglichen.

Diese Arbeit konzentriert sich auf die Weiterentwicklung verschiedener In-tegrationsansätze, um polystrukturierte Daten zusammen mit strukturierten Daten in das Data Vault Modell zu integrieren. Anhand von einem Anwen-dungsfall werden verschiedene Ansätze implementiert und ihre Vor- und Nachteile diskutiert. Darüber hinaus wird das Resultat diese Ansätze evalu-iert, um zu prüfen, ob es die Merkmale des Data Vault Modells weiterhin erfüllt.

ABBILDUNGSVERZEICHNIS

Abbildung 1.1 Prognose zum Volumen der jährlich generierten digi- talen Datenmenge [IDC]

Abbildung 1.2 Fokus der Arbeit

Abbildung 2.1 Begriffshierarchie Zeichen, Daten, Information, Wis- sen [Ack15]

Abbildung 2.2 Verschiedene Arten von Daten [Gri]

Abbildung 2.3 Datenherkunft [KHG10]

Abbildung 2.4 Beispiel für ein ER-Modell [Che76]

Abbildung 2.5 Beispiel für ein dimensionales Modell [RK13]

Abbildung 2.6 Beispiel einer S3-Graph [Lin05]

Abbildung 2.7 Beispiel eines CM-Hypergraph [Lin05]

Abbildung 2.8 Schema Tree [Lin05]

Abbildung 2.9 Beispiel eines ORA-SS-Modells [GD00]

Abbildung 2.10 Beispiel des Generierungsverfahrens [ESB15]

Abbildung 2.11 Beispiel eines RDF-Tripels [KG16]

Abbildung 2.12 Verwendete Datenmodelle - Heutiger Stand [Gü14]

Abbildung 2.13 Verwendete Datenmodelle mit Data Vault [Gü14]

Abbildung 2.14 Data Vault - Grundlegende Elemente [Gü14]

Abbildung 2.15 3NF-Entität: Vermischte Grundbestandteile [Gü14]

Abbildung 2.16 Hub-Entität und -Beispiel

Abbildung 2.17 Beispiel für ein Link

Abbildung 2.18 Struktur der Link-Entität

Abbildung 2.19 Link als N:M-Beziehung [KG11]

Abbildung 2.20 Beispiel eines erweiterten Links [KG11]

Abbildung 2.21 Struktur der Satellit-Entität

Abbildung 2.22 Data Vault Architektur [KG11]

Abbildung 2.23 Data Vault 1.0 - Ladeprozess mit Sequenz-ID [DL16]

Abbildung 2.24 Data Vault 2.0 - Ladeprozess mit Hash-Key [DL16]

Abbildung 3.1 Vergleich der Struktur zwischen JSON und XML

Abbildung 3.2 Heterogene Dokumentstruktur

Abbildung 3.3 JSON-Struktur

Abbildung 3.4 Eingebettetes JSON-Dokument

Abbildung 3.5 Referenziertes JSON-Dokument

Abbildung 3.6 Hub-Entität wird gemäß MR1 erstellt

Abbildung 3.7 Satellit-Entität wird gemäß MR2 erstellt

Abbildung 3.8 Link-Entität wird gemäß MR3 erstellt

Abbildung 3.9 Satellit-Entität wird gemäß MR4 erstellt

Abbildung 3.10 Beispiel für ein JSON-Array

Abbildung 3.11 XML-Schema für einen Hub

Abbildung 3.12 XML-Schema für einen Link

Abbildung 3.13 XML-Schema für einen Satelliten

Abbildung 3.14 Architektur des Erweiterungskonzepts [SG14]

Abbildung 3.15 Beispiel für eine Verbindung [SG14]

Abbildung 4.1 Abflachung des JSON-Dokuments

Abbildung 4.2 Abflachung des JSON-Arrays

Abbildung 4.3 Ausgangslage für JSON-Array Daten

Abbildung 4.4 JSON-Array: Hub-Entität wird gemäß MR1 erstellt

Abbildung 4.5 JSON-Array: Satellit-Entität wird gemäß MR2 erstellt

Abbildung 4.6 JSON-Array: Link-Entität wird gemäß MR3 erstellt

Abbildung 4.7 JSON-Array: Multi-Active-Satellit wird gemäß MR5 erstellt

Abbildung 4.8 Prozess zur Modellierung von XML-Dokumenten in das Data Vault Modell

Abbildung 4.9 Beispiel - Hub-Entität wird erstellt

Abbildung 4.10 Beispiel - Satellit-Entität wird erstellt

Abbildung 4.11 Beispiel - Multi-Activen-Satelliten wird erstellt

Abbildung 4.12 Übersicht der Ansätze

Abbildung 4.13 Hub Image wird mithilfe eines Links erweitert

Abbildung 4.14 Bilddateien werden unter Verwendung eines externen Systems gespeichert

Abbildung 5.1 Eingesetzte Technologien

Abbildung 5.2 Datenschema zu den Firmenstammdaten

Abbildung 5.3 Datenschema zu den Kundenstammdaten

Abbildung 5.4 Beispiel einer Kundenaktivität in Form eines JSON- Dokuments

Abbildung 5.5 Beispiel einer Logdatei im XML-Dateiformat

Abbildung 5.6 Reihenfolge der Verarbeitungsprozesse

Abbildung 5.7 Gesamtarchitektur

Abbildung 5.8 Tabellenschemata von JSON-Daten

Abbildung 5.9 Tabellenschemata von XML-Daten

Abbildung 5.10 Company - Beladung der Data Vault-Konstrukte

Abbildung 5.11 Customer - Beladung der Data Vault-Konstrukte

Abbildung 5.12 Activity - Beladung der Data Vault-Konstrukte

Abbildung 5.13 Email und Phonecall - Beladung der Data Vault-Konstrukte

Abbildung 5.14 Logfile - Beladung der Data Vault-Konstrukte

Abbildung 5.15 Session - Beladung des Data Vault-Konstrukts

Abbildung 5.16 Ableitung der Dimensionstabelle [Mü]

Abbildung 5.17 Firmendimension

Abbildung 5.18 Kundendimension

Abbildung 5.19 Aktivitätendimension

Abbildung 5.20 Logdateiendimension

Abbildung 5.21 Ableitung der Faktentabelle [Mü]

Abbildung 5.22 Sternschema - E-Mail

Abbildung 5.23 Sternschema - Telefonat

Abbildung 5.24 Sternschema - Websitzung

Abbildung 6.1 Join-Operation von Company und Customer

Abbildung 6.2 JSONPath

Abbildung 6.3 Java-Code - XMLtoJSON

Abbildung 6.4 Generierung der ETL_CONTROL-Einträge

Abbildung 6.5 SQL-Abfrage - Tabelle Company

Abbildung 6.6 Hub-Mapping

Abbildung 6.7 Java-Code - MD5-Funktion

Abbildung 6.8 Link-Mapping - Talend Komponente

Abbildung 6.9 Link-Mapping Prozedur

Abbildung 6.10 Satellite-Mapping - Neue Daten

Abbildung 6.11 Satellite-Mapping - Geänderte Daten

Abbildung 6.12 Beladungsprozess der Faktentabelle

Abbildung 6.13 Verbindungsaufbau

Abbildung 6.14 Struktur des Dashboards

Abbildung 6.15 Verteilung des E-Mail-Betreffs von Unternehmen

Abbildung 6.16 Flächenkartogramm

Abbildung 6.17 Verteilung der Websitzungen von Unternehmen

Abbildung 6.18 Säulendiagramm

Abbildung 7.1 Neues Geschäftskonzept

Abbildung 7.2 Hinzufügen von neuen Attributen

Abbildung 7.3 Auszug aus neues Satellit-Konstrukt

Abbildung 7.4 3NF - Flexibilität

Abbildung 7.5 Granularität ändern

Abbildung 7.6 Erweiterung durch neuen Geschäftsobjekten

Abbildung 7.7 Auszug aus neues Link-Konstrukt

Abbildung 7.8 3NF - Erweiterbarkeit

Abbildung 7.9 Auszug von Sat_Company

Abbildung 7.10 Auszug von Sat_Customer

Abbildung 7.11 3NF - Historisierung

Abbildung 7.12 SQL-Befehl zur Duplikatsprüfung

Abbildung 7.13 Ergebnisvergleich der Duplikatsprüfung

Abbildung 7.14 SQL-Statements zum Testfall 1

Abbildung 7.15 Auszug der Ergebnisse für Testfall 1

Abbildung 7.16 SQL-Statements zum Testfall 2

Abbildung 7.17 Auszug der Ergebnisse für Testfall 2

Abbildung 7.18 Abfrage-Performance des ersten Dashboards

Abbildung 7.19 Abfrage-Performance des zweiten Dashboards

Abbildung A.1 Data Mart - Fact_Email

Abbildung A.2 Data Mart - Fact_Phonecall

Abbildung A.3 Data Mart - Fact_Session

Abbildung A.4 Data Vault Repräsentation

Abbildung A.5 CRM Analytics Dashboard -1

Abbildung A.6 CRM Analytics Dashboard -2

TABELLENVERZEICHNIS

Tabelle 2.1 DWH-Schichten und deren Anforderungen [Hul12]

Tabelle 3.1 Gegenüberstellung der relationalen sowie der doku- mentorientierten Datenbank

Tabelle 4.1 Zusammengesetzte Schlüssel für Produktbild

Tabelle 5.1 Überblick der Ladeketten

Tabelle 5.2 Beispielhafter Auszug aus der Tabelle ETL_CONTROL

Tabelle 7.1 Datenmengen der Faktentabellen

ABKÜRZUNGSVERZEICHNIS

CMS Content Management System

CRM Customer Relationship Management

DBMS Data Base Management System

DWH Data Warehouse

ERM Entity Relationship Modell

ERP Enterprise Resource Planning

ETL Extract Transform Load

IDC International Data Corporation

IoT Internet of Things

JPEG Joint Photographic Experts Group

JSON JavaScript Object Notation

MP3 MPEG-1 Audio Layer 3

NLP Natural Language Processing

NoSQL Not only SQL

OLAP Online Analytical Processing

OLTP Online Transaction Processing

ORA-SS Object-Relationship-Attribute Model for Semi-Structured Data

OWL Web Ontology Language

POS-Tagging Part-of-Speech-Tagging

RDF Resource Description Framework

SQL Structured Query Language

UML Unified Modeling Language

WWW World Wide Web

XML Extensible Markup Language

XSD XML Schema Definition

3NF Third Normal Form

Teil I

THESIS

EINLEITUNG

Im Folgenden werden die Motivation und die Zielsetzung dieser Arbeit dar-gelegt. Weiterhin wird das Thema der Arbeit abgegrenzt und der Aufbau der Arbeit erläutert, um dem Leser einen Überblick zu verschaffen.

1.1 motivation

Die Menge an Daten und Informationen, die sowohl im wirtschaftlichen und wissenschaftlichen als auch im privaten Umfeld täglich neu entsteht und meist langfristig gespeichert wird, nimmt stetig zu. Das Marktforschungs-unternehmen International Data Corporation (IDC) schätzt die Menge der im Jahr 2020 weltweit neu erzeugten Daten auf über 58 Zettabyte (entspricht ca. 58 Milliarden Terabyte) und prognostiziert für das Jahr 2025 neu erzeugte Datenmengen in einer Größenordnung von mehr als 175 Zettabyte pro Jahr [IDC].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.1: Prognose zum Volumen der jährlich generierten digitalen Daten-menge [IDC]

Dies führt immer häufiger dazu, dass nicht nur die Speicherung, Verarbei-tung und Analyse, sondern auch die Zusammenführung von Daten aus verschiedenen Quellen zu einem wichtigen Bestandteil vieler heutiger IT-Projekte wird [Bet08] [Sch09b] [Sch09a]. Diese Daten werden als eine Samm-lung von Informationen betrachtet und der Verarbeitungsprozess umfasst die Aufnahme, die Bereinigung, das Mapping und die Transformation der Daten gemäß dem Zielsystem sowie schließlich die Bereitstellung aussage-kräftiger und wertvoller Informationen.

Angesichts der Flut an Informationen stehen Unternehmen somit vor dem Problem der Datenverarbeitung aus unterschiedlichen Quellen. Um nützli-che Geschäftserkenntnisse zu gewinnen, wie z. B. Kundenpräferenzen oder Kundenverhalten, werden diese Daten verarbeitet. Die Daten können z. B.

von Enterprise Resource Planning (ERP)-Systemen, Customer Relationship Management (CRM)-Systemen oder dem IoT erzeugt werden.

Beim traditionellen Ansatz werden die Daten im Data Warehouse (DWH) ge-sammelt und organisiert. Das Data Warehouse gilt als Lager für historische Daten und wird hauptsächlich für strukturierte Daten konzipiert. Nach Bill Inmon [Inm02] wird das Data Warehouse wie folgt definiert:

„A data warehouse is a subject-oriented, integrated, time-variant and non-volatile collection of data to enable the decision-making process. “1

Data Warehouses können mit verschiedenen Modellierungstechniken darge-stellt werden. Dabei haben sich die Konzepte von Bill Inmon und Ralph Kim-ball als zwei Standards in diesem Bereich etabliert [Bre04] [ARP12]. Ralph Kimballs Konzept wird als dimensionale Modellierung bezeichnet, während der Ansatz von Bill Inmon als Third Normal Form (3NF) oder dritte Nor-malform bekannt ist. Diese beiden Modellierungstechniken waren für ein Data Warehouse lange Zeit vorherrschend. Durch die Zunahme an Volumen und Vielfalt von Daten haben sich jedoch Einschränkungen in den Aspekten wie Reengineering, Flexibilität und Skalierbarkeit herausgestellt. Um diese Einschränkungen zu überwinden, wurde das Data Vault Modell von Dan Linstedt et al. entwickelt [DL16]. Ein Data Vault Modell ist eine Kombinati-on aus der dritten Normalform und der dimensionalen Modellierung. Der Ansatz ist besonders geeignet für Data Warehouses, bei denen häufig Struk-turerweiterungen vorgenommen werden müssen.

Im Laufe der letzten Jahre wurde der Umgang mit der Datenflut in Un-ternehmen zum zentralen Erfolgsfaktor [Bet08]. Innerhalb kürzester Zeit ändern sich in einer dynamischen Umwelt die Anforderungen an die ver-schiedenen Fachabteilungen. Darauf müssen Data Warehouses schnell und flexibel reagieren [Bet08] [Sch09b]. Zusätzlich nimmt nicht nur die Menge der Daten, sondern auch ihre Komplexität zu. Verschiedenen Quellen kön-nen strukturierte, halb- und unstrukturierte Daten produzieren. Laut Statis-tiken der Gartner Group sind 80 Prozent der heutigen Daten unstrukturiert [XL11]. Daher müssen neben den strukturierten Daten auch die halb- und unstrukturierten Daten gespeichert und integriert werden. Das Data Vault Modell wurde ursprünglich für strukturierten Daten entworfen. Es unter-stützt noch nicht die Integration von halb- und unstrukturierten Daten. Eine Herausforderung ist das Zusammenführen halb- und unstrukturierter Da-ten mit strukturierten Daten in ein Data Vault Modell, um die Bereitstellung wertvoller Informationen zu verwirklichen [Sti14].

1.2 zielsetzung

Das Data Vault Modell eignet sich gut für die Modellierung strukturierter Daten. Die Frage, wie halb- und unstrukturierte Daten in das Data Vault Modell integriert werden können, ohne dessen Konsistenz und Integrität zu beeinträchtigen, ist jedoch nur teilweise beantwortet [KC18] [CK13].

Ziel dieser Arbeit ist es, auf Basis bestehender Konzepte, die Integration halb- und unstrukturierte Daten in das Data Vault Modell zu untersuchen. Es werden aktuell bestehende Konzepte diskutiert und Erweiterungsmög-lichkeiten sowohl für halb- als auch für unstrukturierte Daten entwickelt. Das erweiterte Konzept wird auf einen beispielhaften Anwendungsfall aus der realen Welt angewandt. Zudem wird ein Prototyp implementiert, um die Funktionalität des Konzeptes nachzuweisen. Auf dessen Ergebnis wird die Implementierung evaluiert, um zu prüfen, ob die Merkmale des Data Vault weiterhin erfüllt sind.

1.3 abgrenzung

Obwohl sich die vorliegende Arbeit mit der Datenintegration von polystruk-turierten Daten in das Data Vault Modell (Quellsystemnahe Raw Vault) be-schäftigt, liegt der Fokus jedoch auf der Integration halbstrukturierter Daten wie z. B JavaScript Object Notation (JSON)2-basierter Datenstrukturen und Extensible Markup Language (XML)3-basierter Datenstrukturen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.2: Fokus der Arbeit

Die Integration von unstrukturierten Daten wird allerdings konzeptionell dargelegt. Die prototypische Implementierung dient dazu, die Machbarkeit der vorhandenen Konzepte zu überprüfen und sie in einer praktischen Form zu demonstrieren.

1.4 aufbau der arbeit

Diese Arbeit gliedert sich inklusive dieser Einleitung in acht Kapitel. Im zweiten Kapitel werden relevante Eigenschaften und Begrifflichkeiten zu Daten geklärt sowie verschiedene Datenmodelle vorgestellt. Zudem werden die verschiedenen Modellierungstechniken für strukturierte, halb- und un-strukturierte Daten diskutiert. Darüber hinaus wird das Data Vault Modell mit seinen grundlegenden Entitäten vorgestellt, sowie die Regeln für die Modellierung erörtert. Im dritten Kapitel geht es um die Vorstellung beste-hender Ansätze zur Integration von halb- und unstrukturierten Daten in das Data Vault Modell. Es werden die vorhandenen Ansätze zur Integration der JavaScript Object Notation (JSON) und des XML-Schemas in das Data Vault Modell erläutert. Auf deren Basis werden in Kapitel vier Erweiterungs-möglichkeiten für die Integration halb- und unstrukturierter Daten in das Data Vault Modell vorgestellt. Im fünften Kapitel wird einen beispielhafter Anwendungsfall aus der realen Welt konzipiert, um die Erweiterungsmög-lichkeiten zu überprüfen. Die praktische Implementierung wird im sechsten Kapitel gezeigt. Im siebten Kapitel wird die umgesetzte Implementierung anhand verschiedener Faktoren zur Überprüfung des Data Vault Modells evaluiert. Im Anschluss wird in Kapitel acht ein Fazit sowie ein Ausblick zu dieser Arbeit gegeben.

GRUNDLAGEN

Dieses Kapitel führt in die Grundlagen der Datenmodellierung ein. Dabei werden die gängigen Modelle für strukturierte, halbstrukturierte und un-strukturierte Daten sowie die Techniken zur Modellierung dieser Daten er-läutert. Anschließend wird auf das Data Vault Modell vertiefend eingegan-gen.

2.1 die welt der daten

Im folgenden Abschnitt werden die Begriffe Daten, Information und Wissen definiert, sodass die Unterschiede deutlich und Verwechslungen vermieden werden. Es wird zudem auf die verschiedenen Dimensionen von Daten ver-tiefend eingegangen. Schließlich werden die verbreitetsten Modelle zur Dar-stellung und Verarbeitung von Daten präsentiert.

2.1.1 Daten, Informationen, Wissen

Die Begriffe Daten, Information und Wissen sind nach Auffassung von Ackoff Russell [Ack15] hierarchisch miteinander verbunden. Die Abbildung 2.1 vi-sualisiert den Zusammenhang zwischen Daten, Informationen und Wissen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Begriffshierarchie Zeichen, Daten, Information, Wissen [Ack15]

Die Hierarchie wird durch die pyramidale Darstellung verdeutlicht. Die brei-te Basis bildet die Gesamtmenge der Zeichen. Diese Menge umfasst Ziffern, Buchstaben, Satzzeichen sowie die Sonderzeichen. Die Anreihung der Zei-chen in einer festgelegten Anordnung wird als Syntax bezeichnet und er-

zeugt die Daten (z.B. 0.99). Die Daten allein ergeben jedoch für den Men-schen keinen Sinn. Die Sinngebung der Daten entsteht durch die Zuordnung eines Zusammenhanges oder Kontextes. Sobald diese Zuordnung erfolgt ist, handelt es sich nicht mehr um Daten, sondern um Informationen. Das Bei-spiel der Zeichenkette 0.99 kann vielerlei bedeuten. Beispielsweise könnte es sich um den aktuellen Preis für ein Kilogramm Tomaten handeln. Durch Vernetzung von Informationen entsteht Wissen. Dem Beispiel folgend könn-te die Information der letzten Woche lauten, dass ein Kilogramm Tomaten 1.99 kostete. Die Verknüpfung aus der Information von letzter Woche, mit der aus dieser Woche führt zu dem Wissen, dass der Preis gesunken ist und die Tomaten gerade preisgünstig angeboten werden.

2.1.2 Dimensionen von Daten

Daten lassen sich anhand ihrer Strukturierung klassifizieren. Dabei ist zwi-schen strukturierten und unstrukturierten Daten zu unterscheiden. Zudem gibt es Daten, die Eigenschaften von strukturierten und unstrukturierten Daten aufweisen. Diese werden als halb- oder semistrukturierte Daten bezeichnet. Tre-ten diese drei Datenarten in Kombinationen auf, dann entsteht eine vierte Datenstrukturklasse, nämlich die polystrukturierten Daten [Kra08].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Verschiedene Arten von Daten [Gri]

Die strukturierten Daten geben vollständig Aufschluss darüber, welchen In-halt sie transportieren und wie sie mit anderen Daten verbunden sind. Diese Datenklasse eignet sich für die relationalen Datenbanken. Unstrukturierte Daten geben keine Auskunft über ihre Struktur und Verbindungen zu an-deren Daten. Zu der Datenklasse gehören Texte, Bilder, Videos und Audios. Die Ordnungsauskunft zu unstrukturierten Daten befindet sich auf einer darüberliegenden Abstraktionsebene [Rü] [Gri]. Beispielsweise besteht ein Text aus Kapiteln, Paragrafen und Sätze. Sätze werden auf der Grundlage, der durch eine Sprache vorgegebenen Struktur geformt. Sie folgen somit ei-ner internen Regel, nämlich der Grammatik. Fehlen die Metadaten oder ein Zusatzschema, beispielsweise der Hinweis auf die Sprache, in der ein Text verfasst wurde, dann wird die Verarbeitung von Text verkompliziert [Gri]. Halbstrukturierte Daten unterliegen keiner allgemeinen Struktur. Sie tragen nur einen Teil der Strukturinformation mit sich. Beispiele für diesen Daten-typ sind Daten im Format der Extensible Markup Language (XML) sowie der JavaScript Object Notation (JSON).

Daten lassen sich je nach Verwendungszweck als operative oder dispositive Daten klassifizieren. Unter operativen Daten werden üblicherweise sämtli-che Daten zusammengefasst, die an der Wertschöpfungskette von Unterneh-men beteiligt sind. In der Regel handelt es sich dabei um Daten, die an bei-den Enden von Transaktionsprozessen stehen [KHG10]. Daher ist für diesen Daten auch der Begriff Online Transaction Processing (OLTP)-Daten geläufig. Zur Verdeutlichung wird das Beispiel eines Logistikunternehmens betrach-tet. In diesem werden durch Transaktionsprozesse Daten generiert und ver-waltet, die sich mit Gütern, Mengen und ähnlichem befassen [KHG10].

Dispositive Daten laufen auch unter dem Begriff Online Analytical Proces-sing (OLAP)-Daten. Im Unternehmensalltag verstehen sich darunter die Da-ten, die das Management bei Entscheidungen zur Steuerung oder strategi-schen Ausrichtung des Unternehmens unterstützen. Sie sind die Grundlage für Entscheidungsprozesse und Berichtslegungen [KHG10].

Des Weiteren können Daten nach ihrer Herkunft klassifiziert werden. Da-bei wird die Betrachtung des Datenumfelds auf ein Unternehmen begrenzt. Davon ausgehend lassen sich extern und intern erzeugte Daten unterschei-den (s. Abbildung 2.3).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: Datenherkunft [KHG10]

Die internen Daten werden danach getrennt, ob sie durch Menschen oder Maschinen produziert werden. Zur Gruppe der maschinengenerierten Da-ten gehören sämtliche Daten, die von Maschinen, Geräten, Anlagen und Ähnlichem als Teil der Arbeitsroutine hervorgebracht werden [KHG10]. Log-daten, die beispielsweise von Produktionsmaschinen oder Telekommunikati-onsgeräten angelegt werden, gehören zu dieser Art von Daten. Dazu kommt, dass in zunehmendem Maße Daten zwischen Geräten oder Maschinen aus-getauscht werden. Diese Datenkommunikation wird als Internet of Things (IoT) bezeichnet [KHG10]. Es wird davon ausgegangen, dass das Datenvo-lumen welches zwischen Geräten entsteht und ausgetauscht wird in den kommenden Jahren enorm zunehmen wird [Lad] [KHG10].

Menschen produzieren unter anderem Dokumente, versenden E-Mails, er-stellen Chat-Protokolle und beteiligen sich in betriebsinternen Foren. Die Liste der externen Datenquellen ist unendlich lang. Von zunehmender Wich-tigkeit sind Daten, die aus dem Web 2.0 hervorgehen. Zu erwähnen sind hier die Daten, die uneingeschränkt und zu einer Vielfalt von Themen kostenlos zur Verfügung stehen. Im Internet produzieren Menschen eine Vielzahl von Daten. Sie werden über die sozialen Netze, Internetforen, Blogs oder Bewer-tungsportalen in den Umlauf gebracht. Hierbei handelt es sich unter ande-rem um Daten, die Erfahrungen, Meinungen oder Interessen von Menschen beinhalten [Lad].

2.1.3 Datenmodell

Ein Datenmodell dient der strukturellen Beschreibung von Daten. Der Be-schreibungsprozess dafür wird als Datenmodellierung bezeichnet [Gad17]. Mit Datenmodellen wird eine hohe Datenqualität gewährleistet. Dies gelingt durch die Vordefinierung der zu erfüllenden Bedingungen bei der Eingabe der Daten. Zudem werden durch ein Datenmodell Operationen wie der Aus-tausch und die Zusammenlegung von Daten ermöglicht [Gad17]. Die drei fundamentalen Funktionen des Datenmodells sind nach [Jan17]:

- Die Gewährleistung der Datenqualität
- Der Datentransfer
- Das Zusammenbringen der unterschiedlichen Daten

Bei der Datenmodellierung wird in vier Schritten vorgegangen, welche in der Literatur beschrieben und in der Praxis ausgeführt werden [Jan17]. Zu-nächst gilt es, die Daten bzw. die Anforderungen an das zu entwickelnde System (z.B. eine Datenbank) zu analysieren. Wenn eine präzise Definition der Anforderungen an die Datenbank erfolgt ist, kann ein konzeptionelles Mo-dell entwickelt werden. Dieses wird in einem nächsten Schritt in ein logisches Datenmodell transferiert, welches mehr Details enthält. Als letztes kommt es zu einer physischen Produktion der Datensätze, welche in eine Datenbank ein-gespeist werden [Jan17]. Konzeptionelle Modelle beschreiben meist mithilfe einer grafischen Modellierung, wie z. B. Entity Relationship Modell (ERM)-Diagramm oder Unified Modeling Language (UML)-Diagramm, die Wirklich-keit. Im Gegensatz zu den konzeptionellen Modellen, welche keinen Bezug zu einem bestimmten Data Base Management System (DBMS) aufweisen, fo-kussiert sich das logische Modell auf das Zielsystem. Das heißt, dass je nach angewandtem DBMS1 ein konzeptioneller Vorschlag ins logische Modell über-setzt wird. Das logische Modell kann auch als logisches Schema bezeichnet werden [SG18] [ER11].

Die letzte Phase der Datenmodellierung bildet die Instanziierung der Ob-jekte anhand des logischen Modells. Mithilfe des physischen Modells bzw. dem physischen oder internen Schema wird näher auf die physische Struk-tur der zu speichernden Daten eingegangen [SG18]. Je nach DBMS werden im physischen Entwurf folgende Faktoren festgehalten:

- Dateiformat
- Bezeichnungen des Objektes, der Tabellen und Spalten
- Datentypen
- Indexauswahl
- Primär- sowie Fremdschlüssel
- Constraints etc.

Nachdem in diesem Abschnitt die Datenmodellierung erläutert wurde, be-schäftigt sich der nächste Abschnitt mit den für die Modellierung vorhande-nen Techniken.

2.2 modellierungstechniken

Wie im vorherigen Abschnitt beschrieben, dient die Datenmodellierung als ein Kommunikationswerkzeug, um die erfassten Informationen für die ge-schäftlichen Endbenutzer zu präsentieren. Das Ziel eines Datenmodells ist die vollständige und genaue Darstellung aller Datenobjekte, die für den ent-sprechenden Geschäftsfall relevant sind. Beispielsweise können mit Hilfe des Datenmodells die Schlüsselelemente wie Tabellen und Schlüssel (Primär-und Fremdschlüssel), die für den Entwurf der Datenstruktur notwendig sind, leicht beschrieben werden [CB16]. Nachfolgend werden die verschie-denen Modellierungstechniken für strukturierte, halb- und unstrukturierte Daten vorgestellt.

2.2.1 Strukturierte Daten

Die dritte Normalform, die Dimensionsmodellierung und das Data Vault Modell sind einige der Datenmodellierungstechniken für strukturierte Da-ten, die auf den folgenden Referenzen basieren [ARP12] [LY16] [RK13].

- Dritte Normalform - Die dritte Normalform wurde in den 1960er Jah-ren von Codd und Date begründet [RK13]. Diese hat das Ziel eine Nor-malisierung in einem relationalen Datenbankmodell zu gewährleisten. Sie verhindert einerseits Anomalien und Redundanzen in Datensätzen und bietet andererseits genügend Performance für Structured Query Language (SQL)-Abfragen [RK13].

Im Jahr 1976 wurde das ERM von Chen zur Modellierung von logi-schen Datenbankbeziehungen eingeführt. Später adaptierte Bill Inmon die dritte Normalform in seine Data Warehouse Architektur [Inm02]. Ein ER-Modell wird durch Entitäten, Beziehungen und Attribute de-finiert. Die Entität repräsentiert das Objekt der realen Welt und wird durch ein Rechtecksymbol gekennzeichnet. Die Beziehung beschreibt die Verbindung, die zwischen zwei oder mehreren Entitäten besteht. Beispielsweise definiert Order (s. Abbildung 2.4), die Beziehung zwi-schen der Entität Customer und der Entität Product. Die Beziehung wird durch das Rautensymbol gekennzeichnet. Das Attribut repräsentiert die Eigenschaften, die die Entitäten definieren, und wird durch das ovale Symbol gekennzeichnet [Che76]. Zum Beispiel sind Product Na-me und Product Price Attribute der Entität Product.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.4: Beispiel für ein ER-Modell [Che76]

- Dimensionsmodellierung - Die Dimensionsmodellierung wurde von Ralph Kimball eingeführt, um ein Data Warehouse zu entwerfen [RK13]. Sie umfasst eine Faktentabelle und eine oder mehrerer Dimensionsta-bellen. Die Faktentabelle speichert die numerischen Maße über den jeweiligen Geschäftsprozess, wie z. B. den Umsatz oder den Profit. Die Dimensionstabelle stellt die Kontexte dar, die entlang verschiedener Dimensionen aggregiert werden können.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.5: Beispiel für ein dimensionales Modell [RK13]

Wie in Abbildung 2.5 dargestellt, stellt Fact_Sales beispielsweise die Faktentabelle mit Maßen wie Sales oder Profit dar und speichert die Fremdschlüssel (FK) wie Customer ID und Product ID, welche auf die Primärschlüssel der Dimensionstabellen verweisen. Die Dimensionen wiederum enthalten beschreibende Informationen wie beispielsweise Customer Name und Customer Phone.

- Data Vault Modell - In der agilen Projektausführung werden Erweiter-barkeit und Flexibilität zu immer wichtigeren Erfolgsfaktoren. Dabei stoßen die genannten traditionellen Modellierungstechniken an ihre Grenzen. Trotz der vielen Lösungen, die zur Überwindung dieser Ein-schränkungen, insbesondere für die dimensionale Modellierung, vor-geschlagen werden, neigen diese Lösungen dazu, dass diese in der Praxis schwer umzusetzen sind [ZN16]. Um all diese Einschränkun-gen zu überwinden, mit denen traditionelle Modellierungstechniken konfrontiert sind, und um das Data Warehouse agil zu implementie-ren, wurde das Data Vault Modell als eine alternative Lösung [ZN16] [BB13] entwickelt. In Abschnitt 2.3 wird das Data Vault Modell konkre-ter behandelt.

2.2.2 Halbstrukturierte Daten

Halb- oder semistrukturierte Daten sind aufgrund der rasanten Entwicklung des Internets populär geworden. Diese Art von Daten haben eine gewis-se Struktur, weisen aber kein vordefiniertes Format oder Schema auf, um die Daten zu repräsentieren [Lin05]. Beispiele für halbstrukturierte Daten sind Extensible Markup Language (XML) oder JavaScript Object Notation (JSON). Es gibt verschiedene Modellierungstechniken für halbstrukturierte Daten, wie z. B. Semi-Structured Schema Graph (S3-Graph), Conceptual-Model (CM) Hypergraph & Schema Tree und Object-Relationship-Attribute Model for Semi-Structured Data (ORA-SS). Nachfolgend werden auf Ba- sis bestehender Literatur die erwähnten Modellierungstechniken vorgestellt [SYL99] [XW02].

- Nach [SYL99] wurde der S 3 -Graph2 vorgeschlagen, um das Problem der Datenredundanz in halbstrukturierten Daten zu lösen. Dieser ist definiert als ein Graph mit Knoten und Pfeilen. Dabei kann jeder Kno-ten eine Entität oder eine Referenz auf eine Entität sein. Ein Entitäts-knoten stellt eine Entität mit atomarem oder komplexem Datentyp dar, während ein Referenzknoten einen Knoten darstellt, der auf einen an-deren Entitätsknoten verweist. Jeder Pfeil hat eine Kennzeichnung, um die Beziehung zwischen den Knoten zu repräsentieren. Grundsätzlich gibt es drei Arten von Pfeilen: Attributspfeil, Referenzpfeil und Wur-zelpfeil. Der Attributspfeil wird durch eine durchgezogene Pfeillinie dargestellt, während der Referenzpfeil durch eine gestrichelte Pfeillinie dargestellt wird. Der Wurzelpfeil hat keine Quellen und wird durch ei-ne durchgezogene Pfeillinie dargestellt [Lin05] [SYL99].

Der S3-Graph stellt eine hierarchische Struktur dar. Mit diesem ist es möglich, binäre Beziehungsmengen wie 1:1- und 1:N-Beziehung dar-zustellen [Lin05]. Wie Abbildung 2.6 zeigt, stellt Knoten #1 einen Enti-tätsknoten dar, der die Entität Customer darstellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.6: Beispiel einer S3-Graph [Lin05]

Knoten #2 und Knoten #3 stellen weitere Entitätsknoten dar, welche ei-ne Zahlenfolge enthalten. Sie bilden die id des Kunden (#2) sowie den Namen des Kunden (#3) ab. Die gerichteten Pfeile zwischen Knoten

#1 und Knoten #2 sowie zwischen Knoten #1 und Knoten #3 besagen, dass jeder Kunde höchstens eine ID und einen Namen hat. Knoten #4’ stellt einen Referenzknoten dar und verweist auf den Entitätsknoten Phone.

In diesem Fall drückt Knoten #4’ das gleiche wie der Entitätsknoten #4 aus. Der Pfeil, welche die Knoten #1 und Knoten #4’ verbindet, reprä-sentiert, dass ein Kunde mehrere Telefonnummern haben kann.

- Embley et. al. definierten den CM-Hypergraph 3 & Schema Tree für den Entwurf eines Schemas für halbstrukturierte Daten im Jahr 2001 [Lin05]. Der CM-Hypergraph besteht aus einer Menge von Entitäten, die in ei-nem Rechteck mit einem Label gekennzeichnet sind. Die Kardinalitä-ten werden durch Pfeile wie folgt dargestellt:

– 1:1-Beziehungen werden durch zwei Pfeilspitzen an beiden En-den bezeichnet.
– 1:N-Beziehungen werden durch eine Pfeilspitzen angezeigt.
– N:M-Beziehungen werden eine durchgezogene Pfeillinie darge-stellt.
– Optional wird mit dem Symbol ’o’ am Rand gekennzeichnet.

In Abbildung 2.7 sind Customer, Id und Name als eine Menge von Enti-täten dargestellt. Customer hat eine eindeutige Id, die als 1:1-Beziehung dargestellt wird. Ebenso kann Customer ein- oder mehrere Phone(s) ha-ben, die als 1:N-Beziehung dargestellt sind. Der Pfeil zwischen Custo-mer und Title, die die Beziehung darstellt, ist optional. Mithilfe des CM-Hypergraph ist es möglich, verschiedene Kardinalitäten auszudrücken. Im CM-Hypergraph werden aber die Attribute einer Entität und die Entitäten selbst nicht unterschieden [Lin05].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.7: Beispiel eines CM-Hypergraph [Lin05]

Im CM-Hypergraph ist es schwierig, die hierarchische Beziehung dar-zustellen. Sie wird mithilfe des Schema Tree ausgedrückt [Lin05]. Der Schema Tree wird verwendet, um die hierarchische Struktur der Entitä-ten zu beschreiben, wobei die Linien die Beziehungen zwischen Entität und Sub-Entität darstellen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.8: Schema Tree [Lin05]

In Abbildung 2.8 steht Customer an der Wurzel. Id, Name, Phone und Address sind innerhalb von Customer verschachtelt. Street und City sind innerhalb Address verschachtelt und bilden dadurch die hierarchische Struktur.

- Nach [XW02] ist es schwierig, die Semantik für die halbstrukturier-ten Daten darzustellen. Zur Überwindung dieser Einschränkung ha-ben Wu et. al. das Object-Relationship-Attribute Model for Semi-Structured Data (ORA-SS) eingeführt [XW02]. Die Entitäten, Beziehungen und Attri-bute sind die drei grundlegenden Elemente des ORA-SS-Datenmodells [GD00]. Im ORA-SS-Modell kennzeichnet ein beschriftetes Rechteck ei-ne Entität und der beschriftete Kreis zeigt Attribute mit ihrem Wert an. Das ORA-SS-Modell [Lin05] wurde entworfen, um den Unterschied zwischen Entitäten und deren Attributen besser darzustellen. Darüber hinaus wird den Grad der Beziehungen, ob ein Attribut zur Beziehung oder zu einer Entität gehört verdeutlicht, wie in Abbildung 2.9 zeigt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.9: Beispiel eines ORA-SS-Modells [GD00]

Attribute können ein- oder mehrwertig sein, und können für die Enti-täten oder den Beziehungstyp graphisch erstellt werden [Lin05]:

– Der ausgefüllte Kreis zeigt an, dass das Attribut ein eindeutiger Bezeichner ist (Beispiel: Id).
– Der Kreis mit einem ’?’ bedeutet, dass das Attribut optional ist (Beispiel: Title).
– Der leere Kreis bedeutet, dass das Attribut obligatorisch und ein-wertig ist (Beispiel: Name).
– Der Kreis mit einem ’*’ bedeutet, dass das Attribut optional und mehrwertig ist (Beispiel: Job).
– Das beschriftete Rechteck stellt die Entität dar (Beispiel: Custo-mer).
– Der Bezeihungstyp zwischen zwei Entitäten wird durch [Bezie-hungsname, Beziehungsgrad, Kardinalität der Entitäten] an den Pfei-len definiert (Beispiel: ad, 2, 1:N).

Nachdem in diesem Abschnitt die Modellierungstechniken für halbstruktu-rierte Daten vorgestellt wurden, beschäftigt sich der nächste Abschnitt mit einpaar ausgewählten Modellierungstechniken für unstrukturierte Daten.

2.2.3 Unstrukturierte Daten

Unstrukturierte Daten sind digitalisierte Informationen, die in einer nicht formalisierten Struktur vorliegen [NV14]. Betrachtet man eine E-Mail, so liegt diese in einer gewissen Struktur vor: Sie enthält einen Empfänger, einen Absender und eventuell einen Betreff. Damit gehört die E-Mail zu den halb-strukturierten Daten. Der Inhalt der E-Mail selbst ist jedoch unstrukturiert oder strukturlos. Daten wie Textdateien, Audio, Video, Bilder, IoT4-Daten oder Social Media Feeds haben keine Struktur, daher ist es schwierig, sie oh-ne Vorarbeit direkt zu verwenden. Die Nutzbarkeit unstrukturierter Daten ist eingeschränkt, weil kein Datenmodell und meist auch keine Metadaten vorliegen [NV14]. Auch in Textdokumenten sind oft Metadaten mit Inhalts-daten vermischt. Um hieraus Strukturen zu gewinnen, ist eine Modellierung erforderlich.

Unstrukturierte Daten können in textuelle unstrukturierte Daten und nicht-textuelle unstrukturierte Daten unterteilt werden [NV14]. Nicht-textuelle un-strukturierte Daten sind z. B. Joint Photographic Experts Group (JPEG)-Bilder, MPEG-1 Audio Layer 3 (MP3)-Audiodateien oder Videodateien. Sie können mit Hilfe von Bilderkennung, künstlicher Intelligenz oder Deep Learning modelliert werden. Die textuellen unstrukturierten Daten können mit Hilfe von Modellierungstechniken wie Text Mining, Natural Language Processing (NLP) oder Semantic Web modelliert werden, auf welche im nachfolgenden Ab-schnitt näher eingegangen wird.

- Text Mining wurde von [YHL15] als Modellierungstechnik eingesetzt, um unstrukturierte Daten effizient zu handhaben. Text Mining wird verwendet, um die nützlichen Merkmale aus dem Text zu extrahie-ren und den Computern die Bedeutung verständlich darzustellen. Die-se Modellierung eignet sich gut für textuelle unstrukturierte Daten wie Textdokumente oder Inhalte von E-Mails. Datenaufbereitung so-wie Textverarbeitung gehören zu den wichtigsten Schritten, um Text Mining durchzuführen. Zu der Textverarbeitung gehören Arbeitsschrit-te wie Satzsegmentierung, Tokenisierung, Stoppwort-Entfernung oder Klas-sifikation [YHL15].
- NLP 5 wird als Modellierungstechnik verwendet, um die Informatio-nen automatisch aus unstrukturierten Daten zu extrahieren, welche im natürlichsprachlichen Text gespeichert sind. Die Idee von [ESB15] ist die automatische Generierung der Elemente des ERM6 wie Entitäten, Beziehungen und Attribute aus natürlichsprachlichen Spezifikationen mithilfe eines heuristikbasierten Ansatzes, wie Abbildung 2.10 zeigt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.10: Beispiel des Generierungsverfahrens [ESB15]

Nach diesem Ansatz sind Entitäten die Substantive (Nomen), die in den Systemanforderungen spezifiziert sind. Verben stellen die Bezie-hungen dar. Satzsegmentierung, Part-of-Speech-Tagging (POS-Tagging), To-kenisierung, Chunking and Parsing sind einige der Prozesse, die an der Generierung von ERM aus NLP beteiligt sind.

- Informationsextraktion ist ein automatischer Prozess um nützliche und strukturierte Informationen aus unstrukturierten Datenquellen zu ex-trahieren [KG16]. Dabei ist es eine anspruchsvolle Aufgabe, Informa-tionen aus textuellen Daten zu extrahieren, ohne ihre Bedeutung zu verändern. Semantic Web eignet sich als eine der möglichen Lösungen für diese Aufgabe [KG16]. Die Technik des Semantic Web ist die Er- weiterung des World Wide Web (WWW). Sie wird verwendet, um den Daten aus verschiedenen Webquellen eine wohldefinierte Bedeutung zu geben. Semantic Web verwendet ein graphenbasiertes Modell zur Darstellung der Daten. Dabei sind das Resource Description Frame-work (RDF) und die Web Ontology Language (OWL) die Standardforma-te der Darstellungen [QKQ13]. RDF7 wird verwendet, um die verschie-denen Arten von Daten, die im Web verfügbar sind, mit eigenen Vo-kabularien zu beschreiben. Die Grundbausteine von RDF sind Subjekt, Prädikat und Objekt, die kollektiv als RDF-Tripel bekannt sind [KG16]. Ein RDF-Tripel wird in Form eines gerichteten Graphen dargestellt, wobei die Ellipse das Subjekt und das Objekt repräsentieren, während die gerichteten Pfeile die Prädikate (Beziehung) darstellen (s. Abbil-dung 2.11). OWL8 wird verwendet, um die Art der Ressourcen und ihre Beziehungen zu identifizieren. Es benutzt eine eigene Ontologie, um die Informationen des semantischen Webs auszudrücken [KG16].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.11: Beispiel eines RDF-Tripels [KG16]

Die Datenmodellierung dient der struktuellen Beschreibung von Daten. Im nächsten Abschnitt wird eine Vorstellung des Data Vault Modells gegeben sowie die Grundlagen des Data Vault Modells inkl. der Architektur näher erörtert.

2.3 data vault modell

Dieser Abschnitt befasst sich mit dem Data Vault Modell. Zunächst werden die Gründe beschrieben, die zur Entwicklung des Data Vault Modell für die DWH9-Core Schicht geführt haben. Anschließend erfolgt eine Einführung in die Theorie und die Architektur des Data Vault Modells. Abgeschlossen wird dieser Abschnitt mit einem Vergleich des Data Vault 1.0 und 2.0.

2.3.1 Motivation für Data Vault

Codd und Date gelten als die Erfinder des Normalisierungsverfahrens nach der dritten Normalform, welches in den 1960 Jahren eingeführt wurde. Die Methode hat sich als robust im Umgang mit OLTP-Daten erwiesen. OLTP-Systeme sind vor allem in den operativen Anwendungen (Controlling, Finan-zierung, Produktion, etc.) von Unternehmen weit verbreitet [Inm02] [Dev97]. Die Normalisierung der Daten mittels der dritten Normalform sorgt dafür, Redundanzen, Inkonsistenzen und Anomalien in komplexen Datenbanken auszuschließen. Das Verfahren dient auch dazu, solche Defizite bereits beim Anlegen einer Datenbank aufzudecken. Dadurch wird die Datenbank effizi-enter, da die Belegung von unnötigem Speicherplatz vermieden wird. Das Verfahren ist zudem wichtig, wenn eine Vielzahl von Nutzern gleichzeitig in einer Datenbank arbeitet, da es zur Inkonsistenzen der Daten führt [Dev97].

Bill Inmon gilt als der Begründer des Data Warehousing Konzeptes, dessen Theorie er in den achtziger Jahren des 20. Jahrhunderts formulierte. Parallel fand eine Weiterentwicklung in der Datenbanktechnologien statt. Es begann die Trennung der auf operative Anwendungen ausgerichteten OLTP-Systeme von den analytischen Datenbanksystemen, kurz OLAP-Systemen. Die Spal-tung in zwei grundlegend unterschiedliche Anforderungsklassen für Daten-banken, beförderte die zweigleisige Weiterentwicklung von Datenbanken-systemen. Inmon befürwortete diesen Werdegang mit den folgenden Argu-menten [Inm02]:

- Operative Daten haben eine andere inhaltliche Zusammensetzung, die-nen einem anderen Zweck und müssen andere Ergebnisse liefern als die Daten, die für komplexe, analytische Fragestellungen verwendet werden.
- Die Datenbankinfrastrukturen unterscheiden sich und sind genau auf die Bedürfnisse der beiden Grundtypen der Datenbanken (OLTP- und OLAP-Daten) zugeschnitten.
- Für die beiden Anforderungsklassen gibt es zwei eindeutig voneinan-der abgrenzbare Nutzergruppen.

Inmon greift das Verfahren der dritten Normalform auf und integriert es in die DWH-Modellierung [Inm02]. Aus seiner Sicht eignet sich dieses Daten-modell am besten für die Aufgaben, die das DWH-Modell zu bewältigen hat. Er begründet die Nutzung dieses Datenmodells wie folgt:

„Data warehouse design is decidedly a world in which a normalized or rela-tional approach is the proper one. There are several very good reasons why normalization and a relational approach produces the optimal design for a data warehouse“10

Das DWH-Modell integriert sämtliche Einheiten, die für die operative Steue-rung in Unternehmen relevant sind, beispielsweise Kunde, Produkt oder Lie-ferant [Inm02]. Für jede dieser Entitäten, wird ein logisches Modell erstellt, welches alle Parameter inhaltlich und in ihrer Verknüpfung zueinander fi-xiert. Inmons DWH-Konzept ist inzwischen in den meisten Unternehmen zum Standard geworden. Dieser Standard bildet die Grundlagen für Analy-sen der Business Intelligence, aber auch für zahlreiche Endnutzeranwendun-gen, wie zum Beispiel Datenabfragen im Berichtswesen.

Zeitgleich mit Inmon’s Formulierung des DWH-Modells, entwickelte Ralph Kimball den Ansatz der dimensionalen Modellierung. Dieser Ansatz ver-folgt die Absicht, ein Modell zu entwerfen, welches den Anforderungen an die analytischen Datenverarbeitung besser gerecht wird als Inmon’s Modell [Dev97] [RK13]. Er geht von der Auffassung aus, dass sich die Anforderun-gen der Nutzer von Daten für operative Steuerungen, deutlich von denen der Bearbeiter analytische Aufgabenstellungen unterscheiden [RK13]. Aus seiner Sicht weist das DWH-Modell Grenzen in der Datenlesbarkeit und in der Qualität der Abfrageoptionen für analytische Anwendungen auf [RK13]. Das Kimball-Modell arbeitet dabei mit dem sogenannten Extract Transform Load (ETL)-Instrument, bei dem Daten aus einer Datenbank herausgefiltert, angepasst und in eine andere Datenbank überführt werden. Dieses Werk-zeug kombiniert Kimball mit einer Zwischenablage (Staging Area). Auszü-ge aus den unterschiedlichen, verfügbaren Datenbanken werden dort vor-übergehend zwischengelagert [RK13]. Sind alle benötigten Daten beisam-men, werden diese in das dimensionale Modell überführt. Das dimensionale Modell beruht auf einem sogenannten Sternschema (siehe Abschnitt 2.2.1). Darin wird eine Faktentabelle sternförmig mit Tabellen umgeben, welche die ausgesuchten, relevanten Dimensionen und Fremdschlüssel enthalten. Inmon’s Bewertung des dimensionalen Modells lautet allerdings wie folgt:

„The multidimensional approach applies exclusively to data marts, not data warehouses. [..] Therefore, creating a star join for the data warehouse is a mista-ke because the end result will be a data warehouse optimized for one community at the expense of all other communities.“11

In den vergangenen Jahren und Jahrzehnten könnte sich die von Inmons entwickelte DWH-Architektur als Standard für (Enterprise) Data Warehou-ses etablieren. Kimballs Ansatz wird als eine Konkurrenz aufgefasst. Die Einschätzung nach [Gad17] ist die, dass sich das dimensionale Modell für einige spezialisierte Unternehmen oder kleinere Abteilungen eignet [RK13]. Es wird davon ausgegangen, dass diese Unternehmen parallel dazu, immer auch ein OLTP-System für die operativen Vorgänge aufrechterhalten müs-sen. Das OLAP-System ist nicht normalisiert, sondern auf die Optimierung der Abruffunktionen von Daten aus multiplen Datenquellen ausgerichtet. So wird das Sternschema inzwischen als Standard für anwendungsspezifi-sche Datenbankausschnitte (Data Marts) in der DWH-Architektur verwen-det [RK13]. Dabei ist es ein fester Bestandteil der DWH-Architektur auf der Endnutzerebene sowie in BI-Anwendungen. Die Abbildung 2.12 zeigt den aktuellen Stand in Bezug auf die verwendeten Datenmodelle im Bereich des Data Warehousing aus der Sicht der Fachwelt und der Industrieanwender.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.12: Verwendete Datenmodelle - Heutiger Stand [Gü14]

Im praktischen Einsatz hat sich weder das eine noch das andere Modell durchgesetzt. Vielmehr kommen verschiedene Formen zum Einsatz. In der Industrie werden im operativen Bereich eine angepasste Form der dritten Normalform nach Codd und Date verwendet. Im DWH-Core Schicht fin-det eine von Inmon adaptiere Version der dritten Normalform Verwendung, und im Analyse-Bereich werden die Daten über Data Marts mit Kimballs dimensionaler Modellierung bereitgestellt. Dabei werden nutzerspezifische Datenausschnitte angelegt und verarbeitet.

Zur Millenniumwende erschienen eine Reihe von technischen Veröffentli-chungen von Dan Linstedt und seinem Forschungsteam, in denen ein ande-res Modell vorgeschlagen und detailliert erläutert wurde [DL16]. Die Texte bezeichnen die beiden bisherigen DWH-Konzepte von Inmon und Kimball anerkennend als solide und führend. Doch aus der Sicht der Forschungs-gruppe waren die Grenzen des DWH-Core Schicht erreicht. Es erwies sich als nicht weiter skalierbar und unflexibel im Umgang mit den gewachsenen Anforderungen. Aus diesem Grund ging das Team den Schritt, ein neues Modell zu entwickeln. Dieses wurde unter dem Begriff Data Vault bekannt [Hul12] [Gü14].

Hans Hultgren gilt als einer der Pioniere des Data Vault Ansatzes. In sei-nem Buch greift er die von Dan Linstedt beschriebenen Probleme auf und verdeutlicht die vorherrschenden, spezifischen Anforderungen der verschie-denen DWH-Schichten:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.1: DWH-Schichten und deren Anforderungen [Hul12]

Werden die verschiedenen Anforderungen der Schichten betrachtet, so lässt sich eine große Diskrepanz zwischen operativen, DWH-Core und analyti-schen Systemen feststellen. Dahingehend erscheint Linstedts Motivation für die Entwicklung eines eigenständigen Datenmodells für den DWH-Core Schicht konsequent und nachvollziehbar. Darin ergibt sich durch die Ver-wendung des Data Vault Modells folgende von ihm angestrebte Konstellati-on:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.13: Verwendete Datenmodelle mit Data Vault [Gü14]

Inzwischen findet sich das Data Vault Modell in zunehmendem Umfang in der DWH-Core Schicht wieder. Selbst der Vater des Data Warehousing, Bill Inmon, der über Jahre hinweg die dritte Normalform in der DWH-Core Schicht propagiert hat, tätigte im Jahre 2017 folgende Aussage:

„The Data Vault is the optimal choice for modeling the EDW 12 2. 0 frame-work.“13

Das Data Vault Modell scheint in der Theorie für einen Einsatz in einer DWH-Core Schicht geeignet und attraktiv. Durch die anforderungsspezifi-sche Auslegung ist es für die Datenintegration, Historisierung und für agile Ansätze optimiert.

2.3.2 Data Vault Grundlagen

Das Data Vault Modell wurde von Dan Linstedt et. al. entwickelt und im Jahre 2000 über die Veröffentlichung von Whitepaper publiziert und der Öf-fentlichkeit zugänglich gemacht. Seine Idee und Motivation bei der Entwick-lung des Ansatzes war es, ein Modell zu entwickeln, welches eine bessere Eignung für den Einsatz in einem DWH-Core Schicht als die dritte Normal-form hat [Hul12] [Gü14]. Dabei handelt es sich um einen Modellierungsan-satz für die DWH-Core Schicht, welche den Anforderungen, die Inmon für DWH definiert hat (subject-oriented, time-variant, integrated und non-volatile), entspricht. Der wichtigste Aspekt bei dem Data Vault Modell zur Wahrung der Flexibilität sah Linstedt in der Entkopplung der Grundbestandteile ei-ner Entität, dem Schlüssel, den Beziehungen und des deskriptiven Kontex-tes [DL16] [Gü14]. Ein Data Vault Modell besteht aus drei grundlegenden Elementen, die jeweils für die einzelnen Grundbestandteile stehen:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.14: Data Vault - Grundlegende Elemente [Gü14]

Bei einer 3NF14-Tabelle hingegen sind sämtliche Elemente in einer Entität miteinander vermischt. Folgendes Beispiel illustriert das:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.15: 3NF-Entität: Vermischte Grundbestandteile [Gü14]

Durch diese Entkopplung der Grundbestandteile in separate Komponenten, eine stark schematisierte Modellstruktur und strikte Modellierungsregeln wird eine Erzeugung des Data Vault Modells und eine nachträgliche Bewirt-schaftung begünstigt [DL16]. Da das Data Vault Modell für die DWH-Core Schicht entwickelt wurde, bringt es bereits wichtige Eigenschaften, wie einfa-che Historisierbarkeit, eine gute Erweiterbarkeit und die Möglichkeit einer parallelen Bewirtschaftung mit [DL16] [Hul12]. Im Folgenden werden die einzelnen Data Vault Elemente nacheinander kurz vorgestellt:

2.3.2.1 Hubs

Mit Hubs werden Business Keys eines Unternehmens abgebildet. Unter ei-nem Business Key können dabei Kerngeschäftsobjekte wie z.B. Kunden, Lie-feranten, Verkäufe oder Produkte verstanden werden. Der Business Key Cu-stomer eines Quellsystems könnte z.B. die Customer_Id sein. Wenn eine neue Instanz des Business Key in das EDW15 eingeführt wird, wird ein neuer Hub generiert. Business Keys sind sehr hilfreich, um die Geschäftsinformationen in den Systemen zu integrieren, zu identifizieren und zu verfolgen [DL16]. In Hubs sind nur Business Keys enthalten und es werden keine Kontexte gespeichert. Hubs besitzen keinen Fremdschlüssel und gelten als Elternele-ment für andere Data Vault-Elemente. Ein Hub hat dabei konkret folgenden Aufbau:

- Primary Key: Der Primärschlüssel oder Primary Key eines Hubs ist nicht etwa der Business Key, sondern in der Version 1.0 eine künstliche Seqzenz-ID (Surrogate Key) und ab Version 2.0 ein Hash Key.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.16: Hub-Entität und -Beispiel

- Business Key: Der Business Key spielt in einem Hub eine wichtige Rolle, da dieser der Schlüssel ist, den Unternehmen zur Identifizie-rung von Entitäten verwenden. Es handelt sich dabei nicht um eine laufende Nummer aus einem Quellsystem, sondern um einen nach-vollziehbaren Schlüssel, der ein Kerngeschäftsobjekt repräsentiert. Dar-über hinaus kann der Business Key ein natürlicher Schlüssel oder ein zusammengesetzter Schlüssel sein.
- Load Date: Hier wird der Zeitpunkt, wann der jeweilige Business Key in den Hub aufgenommen wurde, gespeichert.
- Record Source: Im Record Source wird angegeben, aus welchem Quell-system der Datensatz stammt. So kann z. B. unterschieden werden, ob ein Kunde aus dem CRM16- oder dem HR17-Quellsystem stammt.

Ansonsten werden im Hub keinerlei weitere Attribute wie z. B. Kontext ver-wendet. Insbesondere Fremdschlüssel, die andere Tabellen referenzieren, ge-hören nicht in Hubs, da hierdurch die Flexibilitätsvorteile eines Data Vault Modells verloren gehen würden [DL16].

2.3.2.2 Links

Ein Link repräsentiert die Beziehung oder Assoziation zwischen zwei oder mehreren Hubs. Er wird zum ersten Mal erstellt, wenn eine neue eindeutige Beziehung zwischen zwei oder mehreren Hubs in dem Data Warehouse er-scheint [DL16]. Wie in Abbildung 2.17 dargestellt, besteht eine als Link_Order bekannte Beziehung zwischen zwei Hubs. Diese Beziehung verbinden näm-lich Hub_Customer und Hub_Product zusammen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.17: Beispiel für ein Link

Ein Link enthält Primärschlüssel und Fremdschlüssel, aber keine Kontexte.

Nachfolgend wird der Aufbau von Links beschrieben:

- Primary Key: Ebenso wie bei Hubs kommt in der Version 1.0 eine künstliche Sequenz-ID (Surrogate Key) als Primary Key zum Einsatz, während ab 2.0 Hash-Keys verwendet werden.
- Foreign Key: Für jeden einzelnen im Link verknüpften Hub wird der korrespondierende Fremdschlüsseln im Link gespeichert und mit ei-nem FK18-Constraint versehen, die den jeweiligen Hub referenziert.
- Load Date: Hier wird der Zeitpunkt, wann die jeweilige Beziehung im Link aufgenommen wurde, gespeichert.
- Record Source: Im Record Source wird angegeben, aus welchem Quell-system der Datensatz stammt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.18: Struktur der Link-Entität

Ein Link wird als Resultat von Transaktionen, Beziehungen oder Interak-tionen zwischen Business Units, Geschäftsprozessen oder Business Keys er-stellt [Hul12]. Er bietet Flexibilität für das Data Vault Modell, weil er Än-derungen über die Zeit hinweg zulässt. Anders als es bei der dritten Nor- malform der Fall ist, kann bei Links keine spezifische Kardinalität abgebil-det werden [DL16] [Hul12]. Bei den über Links dargestellten Beziehungen handelt es sich immerzu um N:M-Beziehungen. Laut Linstedt sind diese N:M-Beziehungen maßgeblich für die Flexibilität eines Data Vault Modells verantwortlich:

„Many-to-many relationships allow the physical model to absorb data changes and business rule changes with little to no impact to both existing data sets (history) and existing processes (load and query).“19

Um zu erklären, wie ein Link die Flexibilität unterstützt, wird folgende Sze-nario betrachtet: Derzeit wird in einer Geschäftsregel definiert, dass „eine Maschine viele Produkte herstellen kann, aber jedes Produkt von nur einer Maschi-ne produziert werden muss“. Alles läuft reibungslos, bis beschlossen wird, die Geschäftsregel zu ändern: „Zwei oder Drei Maschinen können mehrere Produkte herstellen“. In diesem Fall steht das EDW vor einem Problem, weil die Struk-tur starr bleibt, wenn sie als 1:N-Beziehung modelliert wird [KG11] [DL16]. Um sich an die neuen Geschäftsregeln anzupassen, muss das EDW umge-staltet werden. Dieses Problem kann im Data Vault Modell gelöst werden, indem eine Verknüpfung eingeführt und die Beziehung als N:M-Beziehung modelliert wird. Die Links, die als N:M-Beziehung modelliert werden, hel-fen dem physischen Design, die Änderungen in einer Geschäftsregel und in den Daten so zu handhaben, dass die vorhandenen Datensätze oder Prozes-se nicht beeinträchtigt werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.19: Link als N:M-Beziehung [KG11]

Neben der Flexibilität bieten Links zudem Erweiterbarkeit im Data Vault Modell. Wie in Abbildung 2.20 dargestellt, kann ein neuer Hub, der als Hub_Supplier bezeichnet wird, mithilfe eines neuen Link_Supply zum beste-henden Hub_Product einfach hinzugefügt werden, ohne das bestehende Mo-dell zu ändern. Auf diese Weise wird die Erweiterbarkeit erreicht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.20: Beispiel eines erweiterten Links [KG11]

2.3.2.3 Satellites

Ein Satellit beinhaltet als einziger der drei Kernelemente deskriptive Infor-mationen in Form von Kontext-Attributen. Dabei kann der Satellit mit seinen Kontext-Attributen entweder Business Keys oder Beziehungen beschreiben. Der Zweck eines Satelliten besteht darin, die Änderungen im System zu speichern, indem alle Änderungen in den entsprechenden Kontexten erfasst werden. Somit ist in einem Satelliten eine Historisierung realisiert [Hul12] [DL16]. An einen Hub oder Link können ein bis mehrere Satelliten per FK20-Constraint angehangen werden. Dabei kann ein Satellit nicht mehreren Hubs oder Links gleichzeitig zugeordnet sein. Ein Satellit weist folgenden Aufbau auf:

- Primary Key: Künstliche Hub- oder Link-Sequenz-ID in der Version 1.0 und Hash-Keys in der Version 2.0. Zusätzlich wird noch das Load Date angegeben. Dadurch wird eine Historisierung realisiert.
- Foreign Key: Die künstliche Sequenz-ID oder der Hash-Key fungiert gleichzeitig als FK-Constraint zum jeweiligen Hub oder Link.
- Kontext-Attribute: Sämtliche beschreibenden Kontext-Attribute wer-den eingefügt.
- Record Source: Im Record Source wird angegeben, aus welchem Quell-system der Datensatz stammt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.21: Struktur der Satellit-Entität

Bei dem Design und Modellierung der Satelliten ist eine hohe Flexibilität vorhanden [Hul12]. So lassen sich an Hubs und Links beliebig viele Satel-liten anhängen und die Attribute zwischen den Satelliten können sich z. B. nach folgenden Aspekten aufteilen:

- Subject-Area (z.B. SAT_ADRESSE und SAT_KUNDE)
- Rate of Change (z.B. SAT_TELEFONNUMMER und SAT_NAME)
- Source System (z.B. SAT_HR und SAT_CRM)
- Datentypen (z.B. SAT_VARCHAR und SAT_NUMBER)

Hans Hultgren schreibt über die Modellierung von Satelliten hierzu:

„Common approaches include using the subject area, rate of change, source sys-tem, or type of data to split out context and design the Satellites.“21

Ein Satellit darf nicht mit weiteren Fremdschlüsseln bestückt werden, als von dem jeweiligen verknüpften Hub oder Link. Es dürfen lediglich Kontext-Attribute beliebiger Anzahl hinzugefügt werden.

2.3.3 Regeln der Data Vault Modellierung

Es gibt einige Regelwerke für die Modellierung von Hubs, Links und Satelli-ten, die beim Entwurf des Data Vault Modells berücksichtigt werden müssen. Werden diese Regelwerke nicht eingehalten, so würde ein kompromittiertes Modell entstehen, welches die ursprünglichen Vorteile des Data Vault Mo-dell nicht komplett ausspielen kann. Der Data Vault Urheber Dan Linstedt begründet es wie folgt:

„The Data Vault Model is flexible in its core design. If the design or the archi-tecture is compromised (the standards/rules are broken) then the model becomes inflexible and brittle. By breaking the standards/rules and changing the architec-ture, reengineering becomes necessary in order to handle business change. Once this happens, total cost of ownership over the lifecycle of the Data Warehouse rises, complexity rises, and the entire value proposition of applying the Data Vault concepts breaks down.“22

Einige der unten aufgeführten wichtigen Regelwerke basieren auf verschie-dene Referenzen [Hul12] [KG11] [DL16]:

Hub-Regeln

- Ein Hub besteht aus einer künstlichen Sequenz-ID, dem Business Key, einem Load Date und der Record Source.

„The Hub consists of the business key only, with a warehouse machine sequence id, a load/time stamp and a record source.“23

- Der Hub darf keine anderen Felder wie z. B. deskriptive Informationen oder Beziehungen enthalten.

„The Hub contains no descriptive information and contains no FKs.“24

- Der Primary Key einer Entität wird zum Business Key, da der PK ge-nau wie der BK eindeutig ist.

„The Hub is a business key recording device.“25

- Ein Hub kann nicht direkt mit einem anderen Hub verknüpft werden. Dazu müsste der Hub neben dem Business Key eine FK-Constraint enthalten, was nicht erlaubt ist.

„The Hub entity must NEVER contain foreign keys.“26

- Ein Hub muss mindestens einen Satelliten haben, um als Hub qualifi-ziert zu werden.

„A Hub SHOULD at least support one Satellite to be in existence, Hubs without Satellites usually indicate ‚bad source data‘, or business keys that are missing valuable metadata.“27

[...]