Ein Referenzmodell zur Erstellung eines Data Warehouse mit Data Vault unter Berücksichtigung der Informationssicherheit des Systems


Bachelorarbeit, 2017

75 Seiten, Note: 1,3


Gratis online lesen

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

1 Einleitung
1.1 Ziel dieser Arbeit
1.2 Begriffsabgrenzung Referenzmodell
1.3 Data-Warehouse-Referenzmodell
1.4 Aufbau der Arbeit

2 Grundlagen eines Data Warehouse
2.1 Architektur
2.1.1 Data Warehouse Design nach Bill Inmon
2.1.2 Data Warehouse Design nach Ralph Kimball
2.2 Die Verwendung von Data Warehouse im betriebswirtschaftlichen Kontext
2.3 Kritik an bestehenden Systemarchitekturen
2.3.1 Die Verwendung von Rollenkonzepten
2.3.2 Entwicklung in time and budget
2.3.3 Verbesserungsansätze bei der Entwicklung von Data Warehouse Systemen
2.4 Data Vault
2.4.1 Eigenschaften der Modellierungstechnik
2.4.2 Data-Warehouse-Modellierung mit Data Vault

3 Referenzmodellierung mit Data Vault
3.1 Anforderungsanalyse
3.2 Infrastruktur- und Quellenanalyse
3.2.1 Mock-up der Anforderungsanalyse
3.2.2 Rollenkonzept nach dem Principle of least privilege
3.2.3 Autorisierung und Authentisierung des Informationszugriffs
3.3 Erstellung der ETL-Prozesse
3.4 Staging Area
3.5 Raw Data Vault
3.6 Business Data Vault
3.6.1 Datenbereinigung
3.6.2 Kennzahlensysteme
3.7 Data Mart
3.8 Information Layer
3.8.1 Rechtliche Hintergründe in Bezug auf das Datenschutz- und IT-Sicherheitsgesetz
3.8.2 Aktivitätsmonitoring
3.9 Mehrwert des Referenzmodells

4 Zusammenfassung und Ausblick

Literaturverzeichnis

Zusammenfassung

Zweck dieser Bachelorarbeit ist die Erstellung eines Referenzmodells zur Entwicklung eines Data Warehouse Systems. Im Verlauf der Arbeit werden dazu alle Entwicklungsschritte, ausgehend von der Anforderungsanalyse bis hin zur Gestaltung des Information Layers, beschrieben. Die gesamte Entwicklung erfolgt unter Berücksichtigung der Informationssicherheit des Data Warehouse Systems. Ein Schwerpunkt der Arbeit liegt in der Möglichkeit, Anforderungsänderungen effektiv umsetzen zu können. Dazu wurde der Core mit der Modellierungsmethode Data Vault realisiert. Das entstandene Referenzmodell dient als Grundlage für ein Managed self service Business Intelligence System und soll Unternehmen bei der technischen Umsetzung der digitalen Transformation unterstützen.

Aus Gründen der besseren Lesbarkeit wird in den folgenden Ausführungen an den entsprechenden Stellen immer nur die männliche Form verwendet (z. B. Nutzer, Entwickler oder Mitarbeiter). Gleichwohl sind damit auch weibliche Personen gemeint.

Abstract

The purpose of this bachelor thesis is to create a reference model to develop a data warehouse system. In the thesis, all necessary development steps are described, beginning with the requirements analysis and ending with the design of the information layer. The development in general takes into account considerations of information security throughout the data warehouse system. While creating the reference model, one focus area was the possibility to implement changed requirements efficiently. Therefore, the Data Vault was used to design the core. The resulting reference model can be used as a foundation for a managed self-service business intelligence system. This should support companies while they realize their digital transformations.

For reasons of simplicity and improved legibility, only the masculine form has been used to describe categories of people (Nutzer, Entwickler oder Mitarbeiter). However, female individuals are also included in these references.

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Bestandteile der digitalen Transformation datenverarbeitender Systeme und deren Verhältnis zueinander

Abbildung 2: Die Grundarchitektur eines Data Warehouse

Abbildung 3: Strategieansätze (Top-down, Bottom-up)

Abbildung 4: Datenzugriff nach Bill Inmons Design

Abbildung 5: Der Aufbau des Sternschemas

Abbildung 6: Der Aufbau des Schneeflockenschemas am Beispiel einer Buchung

Abbildung 7: Betriebswirtschaftliche Anforderungen an Data-Warehouse-Systeme

Abbildung 8: Langzeitkosten eines Data-Warehouse-Systems

Abbildung 9: Risikofaktoren in Entwicklungsprojekten

Abbildung 10: Grundlegender Aufbau eines Data Vault

Abbildung 11: Raw und Business Data Vault in der Data-Warehouse-Architektur

Abbildung 12: Bestandteile eines Hubs

Abbildung 13: Bestandteile eines Link

Abbildung 14: Bestandteile eines Satellites

Abbildung 15: Aufbau einer BEAM-Tabelle am Beispiel einer Kundenbestellung

Abbildung 16: BEAM-Tabelle der Stakeholder

Abbildung 17: Eine durch Entwickler ergänzte BEAM-Tabelle

Abbildung 18: Eine um weitere Informationen zur How/Wie-Frage ergänzte BEAM-Tabelle 28

Abbildung 19: Zeitbasierte Darstellung des Bestellprozesses

Abbildung 20: Hierarchische Darstellung des Bestellprozesses

Abbildung 21: Systemlandschaft bestehend aus Quellsystemen, ETL und Data Warehouse

Abbildung 22: Änderungskosten im Projektverlauf

Abbildung 23: Mock-up für das Ereignis ,Rohstoffe wurden bestellt‘

Abbildung 24: Bestimmung der Zugriffsberechtigung

Abbildung 25: Transformationsprozesse in der ETL Pipeline

Abbildung 26: ETL Coding STAGE.Rohst_bestellt_art

Abbildung 27: Aufbau der Staging Area

Abbildung 28: Staging Datenbanktabelle

Abbildung 29: Datensätze der Staging-Tabelle Bestellart

Abbildung 30: Raw Data Vault für das Ereignis ,Rohstoffe wurden bestellt‘

Abbildung 31: Historisierung der Maßeinheit Unze

Abbildung 32: Business Data Vault im Kontext des Datenflusses

Abbildung 33: Berechnung der Lieferkosten in der entsprechenden Landeswährung

Abbildung 34: Historisierte Wechselkurse der Landeswährungen

Abbildung 35: Data Mart für das Ereignis ,Rohstoffe wurden bestellt‘

Abbildung 36: Dashboard für das Ereignis ,Rohstoffe wurden bestellt‘

Abbildung 37: Ablauf und Prozess des Aktivitätsmonitorings

Abbildung 38: Geeks and the repetitive tasks

Abbildung 39: Die Rolle des Anwenders in der Informationsverteilung

1 Einleitung

Weltweit erleben Unternehmen die digitale Transformation. Dieser Veränderungsprozess ist auf die Entwicklung technologischer Systeme und den daraus resultierenden Möglichkeiten zurückzuführen. Im betrieblichen Kontext gewinnt diese Entwicklung nun zunehmend an Bedeutung, da vor allem die Kundenerwartungen durch diese Veränderungen geprägt werden. Die mit der fortschreitenden Technologisierung einhergehende Steigerung der Informationskanäle bleibt auch Kunden nicht verborgen, sodass sie geänderte, mitunter höhere, Anforderungen an neue Produkte und Dienstleistungen stellen. Das Ziel vieler Unternehmen ist es daher, die angepassten Kundenanforderungen zu erfüllen und die digitale Transformation in diesem Rahmen für sich zu nutzen. Der Einsatz digitaler Technologien ist in diesem Umfeld von existenzieller Bedeutung, um den Anschluss an potenzielle Wachstumsmärkte nicht zu verpassen. Die Entwicklung von Systemen, die eine effektive Verarbeitung vorhandener und zu erfassender Daten ermöglicht, ist daher in den Fokus vieler Unternehmer gerückt (vgl. [Cole 2015, S. 13-28]). Die Folge dieser Entwicklung ist eine Anpassung der Unternehmenslandschaft, um die Kundenanforderungen zu erfüllen und diese gegebenenfalls sogar zu übertreffen. Mögliche Handlungsfelder zur Erreichung dieses Ziels sind vielfältig, sodass sich diese Arbeit auf Veränderungen der informationsverarbeitenden Systeme beschränkt.

Unternehmen verfügen über Nutzungspotenziale, die in der Ausgestaltung digitaler Geschäftsmodelle liegen. Informationsverarbeitende Systeme integrieren Daten aus verschiedenen Quellsystemen. Der unkomplizierte Zugang zu diesen Daten führt zu einem besseren Verständnis der Kundenerwartungen. Änderungen an bestehenden Geschäftsmodellen oder neue Kundenanforderungen können infolge dessen zeitnah adaptiert werden. Die Planung und Anpassung von Informationssystemen erfolgt idealtypisch unter Berücksichtigung bekannter Anforderungen und Technologien. Unstetige Anforderungen der Kunden und sich weiterentwickelnde Technologien führen zu Unsicherheiten im Planungsprozess der IT-Strategie.

Führende Vertreter der deutschen Wirtschaft sehen, mit 32 Prozent, eine Umsatzsteigerung durch neue Produkte als ein erstrebenswertes Unternehmensziel an (vgl. [Roland Berger Strategy Consultants 2015]). Hierfür bedarf es des Einsatzes digitaler Technologien und neuer Geschäftsmodelle. Im Idealfall berücksichtigen diese Neuentwicklungen unbewusste Kundenbedürfnisse. Aber bereits die vorgelagerte Frage, ob bekannte Kundenerwartungen in einem angemessenen Zeitrahmen umgesetzt werden können, ist von zentraler Bedeutung für den Verlauf des digitalen Transformationsprozesses.

Demnach ist es nicht verwunderlich, dass im Bereich Software Engineering in den Jahren 2011 bis 2015 39 Prozent der agilen Projekte unter Einhaltung des Kosten- und Zeitplans erfolgreich abgeschlossen wurden. Die Quote der erfolgreich abgeschlossenen wasserfallartigen Projekte lag im Vergleich dazu bei 11 Prozent (vgl. [Hastie und Wojewoda 2015]). Das könnte daran liegen, dass durch die Verwendung agiler Methoden innerhalb der Entwicklung die Trennung zwischen Planung und Ausführung zunehmend verschwimmt.

Das führt dazu, dass Mitarbeiter, die in diesen Prozess involviert sind, Wissen über neue Potenziale und Technologien benötigen. Durch dieses Wissen können Mitarbeiter digitale Geschäftsmodelle und deren Potenzial frühzeitig erkennen und so können neue Schnittstellen, Produkte und Dienstleistungen für den Kunden entwickelt werden. Diese gemäß den Kundenanforderungen geänderten Produkte und Dienstleistungen entsprechen den Marktanforderungen, führen zu Umsatzsteigerungen und bilden demnach auch ein erstrebenswertes Unternehmensziel.

Abbildung 1 beschreibt den Einfluss digitaler Geschäftsmodelle auf die digitale Transformation.

Abbildung in dieser Leseprobe nicht enthalten

Die digitale Transformation führt zur Implementierung neuer Projekte und realisierte Projekte wiederum ermöglichen die Herstellung und Anpassung bestehender Produkte und Dienstleistungen. Erfolgreich abgeschlossene Projekte liefern ihrerseits Informationen und Wissen über ungenutzte Potenziale. Dieses Wissen wird von Mitarbeitern gefordert und in neuen Projekten, die eine ähnliche Zielsetzung verfolgen, angewendet. Zweck dieser Veränderung ist es, die Anforderungen und Erwartungen des Kunden an neue Dienstleistungen und Produkte zu erfüllen.

Änderungen der Marktbedingungen werden frühzeitig erkannt, Methoden und Technologien kurzfristig adaptiert und der Kundennutzen sowie die Kundenzufriedenheit werden gesteigert (vgl. [Sattelberger 2015, S. 57-77]).

Um herausragende Werte für den Kunden zu schaffen, haben Mitarbeiter demnach eine definierte Menge an Interaktionspunkten. Die Optimierung von Geschäftsprozessen kann durch eine integrative Rolle der Informationstechnologie erfolgen. Fachübergreifende Abteilungen werden in die Lage versetzt, neue Informationen zu gewinnen, ohne bereits bestehende Berichtswege zu verfolgen. Die Konsequenzen daraus sind weitreichende Veränderungen in der Ablauforganisation zukunftsorientierter Unternehmen.

1.1 Ziel dieser Arbeit

Das Ziel dieser Arbeit liegt in der Beschreibung eines Referenzmodells, das die Erstellung eines Data Warehouse Systems ermöglicht. Das entstehende Data Warehouse System bildet die Voraussetzungen zum Ablegen und Auswerten von Datenbeständen aus verschiedenen Datenquellen. Die Aufgabenstellungen in diesem Anwendungsbereich sind vielfältig, etwa ist die Implementierung von betriebswirtschaftlichen Aufgabenstellungen ebenso möglich wie die Darstellung wissenschaftlicher Auswertungen und technischer Analysen (vgl. [Bauer und Günzel 2013, S. 14-33]).

Auswertungsorientierte Anwendungsfälle, in denen Nutzer mithilfe definierter Ad-hoc-Berichte Informationen erhalten, werden von individuell erstellten Informationsmodellen abgelöst. Charakterisiert werden diese Informationsmodelle über komplexe Abfragestrukturen, die sich auf verschiedene Datenquellen und Funktionsbereiche beziehen. Ad-hoc-Analysen, die Kennzahlen zyklisch berechnen, werden angepasst, sodass Anwender Kennzahlen individuell auf Basis verschiedener Dimensionen erstellen können. Die dafür benötigte Grundlage ergibt sich aus additiven, semiadditiven und nicht additiven Kennzahlen.

Unter Berücksichtigung der Sicherheit des Informationssystems unterstützt dieses Referenzmodell die Implementierung eines Data Warehouse Systems.

1.2 Begriffsabgrenzung Referenzmodell

Referenzmodelle können objektiv verglichen werden. Sie umfassen den gesamten zu modellierenden Prozess und alle steuernden Funktionen. Die Modelle beinhalten die Beschreibung aller für die Modellierung erforderlichen Bestandteile. Eine Beschreibung des Modells erfolgt unter Verwendung eines spezifischen Beispiels.

Ein zentrales Charakteristikum des Referenzmodells ist die Wiederverwendbarkeit. Referenzmodelle werden damit zur Wiederverwendung empfohlen und faktisch zur Implementierung eingesetzt (vgl. [Fettke und Loos 2004]).

Die Absicht hinter der Entwicklung eines Referenzmodells lautet:

- Das Modell in der Implementierung wiederzuverwenden.
- Das Modell zur Konstruktion weiterführender Modelle zu verwenden.

Ein Referenzmodell ist nicht zwingend ein Common Practice Model. Die deskriptive Beschreibung zur effektiven Lösungsentwicklung ist das primäre Ziel eines Referenzmodells (vgl. [Fettke 2007]).

Der Ausgangspunkt für die Entwicklung des hier dargestellten Referenzmodells basiert auf allgemeinen Theorien und Prinzipien. Dabei wird die Referenzmodellierung im Entwicklungsprozess zunehmend detaillierter, also eine Top-Down-Entwicklung.

1.3 Data-Warehouse-Referenzmodell

Ein Referenzmodell für die Architektur von Data-Warehouse-Systemen sollte das Konzept der Datenhaltung im betriebswirtschaftlichen Kontext erläutern. Die Referenzarchitektur des Modells gibt dabei die Realität möglichst exakt wieder, sodass auch Umwelteinflüsse und Faktoren, die das Modell beeinflussen, abgebildet werden (vgl. [Bauer und Günzel 2013, S. 37-86]).

Die metaphorische Darstellung der Verwendungsmöglichkeit ist dabei genauso ein Teil des Modellbegriffs wie das zu definierende Maß an Anschaulichkeit für ausgewählte Sachverhalte. Der Begriff Veranschaulichungsmodell ist eine alternative Bezeichnung des Modellbegriffs (vgl. [Wedekind et al. 1998, S. 265-272]).

Eine Referenzarchitektur ist daher stets funktionsorientiert Aktivitäten und durchgeführte Operationen werden in diesem Verlauf konzeptionell beschrieben. Der Daten- und Kontrollfluss wird abgebildet und diese Beschreibung grenzt sowohl das Referenzmodell als auch den Anwendungskontext ab. Letzterer bildet die Voraussetzung zur Wiederverwendung des Referenzmodells in einem betriebswirtschaftlichen Umfeld.

Die Prozesssteuerung beschreibt den Kontrollfluss. Die Gestaltung des Datenflusses bezeichnet alle Ebenen der Datenmodellierung, ausgehend von den Datenquellen bis hin zu den vom Nutzer verwendeten Auswertungssystemen. Diese Ebenen sollten unabhängig voneinander betrieben werden. Das bedeutet, dass Verfügbarkeit und Belastungsgrenzen in laufenden Änderungen frei von Auswirkungen auf die Quellsysteme sind. Diese Eigenschaft muss auch für die Möglichkeit der Ver- und Bearbeitung von Datenbeständen im Data Warehouse gelten.

Durch die Anwendung von Referenzmodellen ist eine höhere Effektivität zu erzielen.

Zu nennen sind dabei folgende Aspekte:

- Kosten

Finanzielle Belastungen für die Modellerstellung können durch die Wiederverwendung bestehender Referenzarchitekturen reduziert werden.

- Zeit

Die Wiederverwendung führt zu einer beschleunigten Implementierung der Modelle.

- Risiko

Die Verwendung eines Referenzmodells verringert das Risiko, dass ein Projekt außerhalb des Kosten- und Zeitplans fertiggestellt wird oder gar scheitert.

- Wettbewerbsposition

Der Einsatz des Referenzmodells und die damit einhergehenden Kosten-, Zeit- und Risikoverschiebungen können die Wettbewerbsposition stärken.

(vgl. [Becker und Knackstedt 2003, S. 415-432]).

Die vermeintlich allgemeine Gültigkeit eines Referenzmodells ist kein definitorisches Merkmal für diesen speziell gewählten Fall. Der Zweck dieser Referenzarchitektur liegt vornehmlich darin, betriebswirtschaftlichen Anforderungen an datenverarbeitende Systeme gerecht zu werden und Raum für unternehmensinterne Anpassungen zu schaffen (vgl. [Schütte 1998, S. 111-175]).

1.4 Aufbau der Arbeit

Die hier vorgestellte Architektur zur Data-Warehouse-Erstellung besteht aus acht Teilschritten:

- Anforderungsanalyse
- Infrastruktur- und Quellenanalyse
- Erstellung der ETL-Prozesse
- Staging Area
- Raw Data Vault
- Business Data Vault
- Data Mart
- Information Layer

Im Anschluss an diese Einleitung soll im Abschnitt 2 ein Einblick in die Grundlagen eines Data-Warehouse-Systems gegeben werden. Dort werden die beiden traditionellen Architekturansätze von Bill Inmon und Ralph Kimball beleuchtet. Eine Betrachtung von betriebswirtschaftlichen Anwendungsfallen sowie möglichen Kritikpunkten an bestehenden Systemarchitekturen erfolgt anschließend. Die Grundlagen eines Data Warehouse werden mit dem Ausblick auf die Modellierung mit Data Vault abgeschlossen.

Im Mittelpunkt des Abschnitts 3 stehen Methoden und Gestaltungsmerkmale der Referenzmodellierung. Auf den dargestellten Methoden und Eigenschaften basiert die Core Modellierung mit Data Vault und die Mehrwertbestimmung des Referenzmodells.

Schließlich erfolgt in Abschnitt 4 die Zusammenfassung der Ergebnisse sowie ein Ausblick auf die Verwendung des Referenzmodells als Datengrundlage für Self Service Business Intelligence Systeme.

2 Grundlagen eines Data Warehouse

Seit Beginn der Entwicklung von Informationssystemen in den 1960er Jahren gibt es eine Vielzahl von Modellierungstechniken, Methoden zur Anforderungsanalyse, Maßnahmen zur Datensparsamkeit und Verfahren zur Performanceoptimierung.

Seit 1988 wird bei IBM vom Information Warehouse gesprochen. Diese Systeme hatten die Aufgabe, den Informationsbedarf zahlender Kunden zu decken. Der Ausdruck Business Data Warehouse wurde erstmals von Barry Devlin und Paul Murphy verwendet (vgl. [Devlin und Murphy 1988, S. 60-82]).

Seitdem gibt es unterschiedliche Auffassungen in Bezug auf den Funktionsumfang und die Architektur von Data-Warehouse-Systemen, sodass dieser Begriff bis heute nicht einheitlich definiert ist. Die wahrscheinlich bekanntesten Vertreter dieser Bewegung, Bill Inmon und Ralph Kimball, stehen jeweils für andere Auffassungen bezüglich der Architekturgestaltung von Data-Warehouse-Systemen. Während Kimball sein Datenmodell mit einem Stern- oder Schneeflockenschema abbildet, setzt Inmon auf Data Marts, die, voneinander physisch getrennt, Organisationseinheiten und Geschäftsprozesse abbilden. Trotz dieser Differenzen verfolgten Kimball und Inmon beide das Ziel, ein Informationssystem zu entwickeln, das auf Grundlage eines konsistenten Datenbestands eine globale Sicht auf die Daten verschiedener Quellsysteme ermöglicht. Beide Architekturmodelle werden heute vielfach produktiv eingesetzt. Die Voraussetzungen für eine flächendeckende Verwendung im betriebswirtschaftlichen Kontext lag vor allem im Einsatz und in der Existenz von:

- Kommunikationstechnologien

Diese mussten schnell und flächendeckend einsetzbar sein.

- Datenspeicher

Sie mussten Anforderungen an Durchsatz, Kapazität, Zuverlässigkeit und Kosten erfüllen.

- Prozessoren

Sie mussten kostengünstig und leistungsfähig sein.

- Datenbasis

Eine Datenbasis, bestehend aus einer Vielzahl von Quellsystemen, die historisiert werden konnten, war im Jahr 1990 noch nicht flächendeckend gegeben.

(vgl. [Bauer und Günzel 2013, S. 12]).

Unter Voraussetzung dieser Gegebenheiten bilden Relationen die Basis für die Grundarchitektur eines Data-Warehouse-Systems. Relationen bestehen in allen Ebenen der Data-Warehouse-Architektur und werden in zwei Schritten modelliert.

Zuerst erfolgt die Erstellung des konzeptionellen Datenmodells, das die Beziehungen zwischen Entitäten beschreibt. Diese wirtschaftliche Sicht wird meist als Entity Relationship Model abgebildet. Der Entwickler dieses Modells ist der Informatiker Peter Chen (vgl. [Chen 1976]). Im zweiten Schritt wird das physische Datenmodell erstellt. Die Modellierung beginnt, sobald das konzeptionelle Datenmodell fertiggestellt ist. Konkret werden Relationen mit Attributen auf der Datenbankebene erstellt und Eigenschaften wie Primär- und Fremdschlüssel werden gepflegt. Auf dieser Basis lässt sich eine Grundarchitektur für den Aufbau von Data-Warehouse-Systemen bestimmen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Die Grundarchitektur eines Data Warehouse

Abbildung 2 beschreibt den Datenfluss innerhalb der Grundarchitektur eines Data Warehouse, ausgehend von den Quellsystemen. ETL steht für den Prozess der Extraktion, Transformation und des Ladens der Datenbestände durch die einzelnen Ebenen der Data-Warehouse-Architektur.

Die vier beschriebenen Schichten umfassen:

- Staging Area

Sie bildet die Datengrundlage für das Data Warehouse, denn in der Staging Area werden Daten aus verschiedenen Quellsystemen integriert. Dies erfolgt in Form einer Initialladung und beliebig vieler Teilladungen. Vor der Inbetriebnahme des Data Warehouse erstellt die Initialladung eine identische Kopie der Quellsysteme. Im laufenden Betrieb des Data Warehouse wird diese Initialladung durch Teilladungen ergänzt. Diese beinhalten Datensätze, die zum Zeitpunkt der Initialladung noch nicht vorhanden waren.

- Cleansing Area

Die über ETL-Prozesse aus der Staging Area geladenen Daten werden in dieser Ebene angepasst. Diese Angleichung der Datensätze umfasst die Korrektur und das Ersetzen von falschen Attributen durch Standardwerte.

- Core

Zweck der Core-Ebene ist die Integration von Daten aus der Cleansing Area. Erfasste Daten werden strukturiert und über einen langen Zeitraum, meist mehrere Jahre, persistiert.

- Marts

Benutzer senden ihre Anfragen an Data Marts, die Teilmengen der Daten aus dem Core beinhalten. Die Struktur der Daten wird an die Bedürfnisse der Benutzerabfragen angepasst. Das heißt, es bestehen viele Data Marts für unterschiedliche Benutzergruppen und Business- Intelligence-Applikationen.

Die in Abbildung 2 beschriebenen Metadaten enthalten fachliche, technische und operative Informationen zu den verwalteten Daten. Sie beschreiben und bilden die Infrastruktur des Data- Warehouse-Systems.

Quellsysteme sind Anwendungen und Systeme, die Ressourcen verwalten und steuern. Unter diese Kategorie fallen Enterprise-Ressource-Planning-Systeme, Customer-Relationship-Management- Systeme, Produktionsplanungs- und Steuerungssysteme, Content-Management-Systeme und weitere externe Datenquellen, die zur Erfüllung der Geschäftstätigkeit erforderlich sind (vgl. [Schnider et al. 2016, S. 7-8]). Erweiterte Definitionen des Data Warehouse umfassen dessen Rolle als zentrale Informationsquelle für Datenanalysen und Berichte, die durch Business-Intelligence-Anwendungen erstellt werden. Das Data Warehousing beinhaltet Anwendungen zur Analyse, Extraktion, Transformation und Verwaltung der gespeicherten Datenbestände.

2.1 Architektur

Konzepte der Architektur von Data-Warehouse-Systemen fokussieren sich auf Komponenten, beginnend bei den Quellsystemen bis hin zur Auswertungsebene. Diese Maßnahmen beruhen auf einer Datenbank und einem Datenbankmanagementsystem (vgl. [Bauer und Günzel 2013, S. 143-180]).

Zwischen diesen Ebenen, die Schichten genannt werden, verlaufen Datenflüsse. Über ETL-Prozesse werden Daten zwischen Ebenen verteilt, wobei die Flussrichtung typischerweise einseitig ist. Bei der Entwicklung eines neuen Data-Warehouse-Systems gibt es zwei zentrale Vorgehensweisen, nämlich den Top-down- und Bottom-up-Ansatz.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Strategieansätze (Top-down, Bottom-up)

Der Top-down-Ansatz beginnt mit und orientiert sich an der Unternehmensvision. Abgeschlossen wird er mit der Analyse bestehender Infrastrukturkomponenten. Im Vergleich dazu richtet sich der Bottom-up-Ansatz nach bestehenden Komponenten und Entwicklungszielen, sodass die Unternehmensvision abschließend mit der geplanten Umsetzung verglichen wird.

Allgemein wird ein Data Warehouse Design durch folgende Qualitätsanforderungen charakterisiert:

- Konsistenz (Widerspruchsfreiheit)
- Korrektheit (Übereinstimmung mit der Realität)
- Vollständigkeit (keine fehlenden Ausprägungen in den Attributen)
- Verwendbarkeit
- Relevanz
- Aktualität

Die Einhaltung der Qualitätsanforderungen stellt das Ziel eines jeden Data-Warehouse-Systems dar, unabhängig davon, ob die Entwicklung auf dem Top-down- oder Bottom-up-Ansatz basiert.

2.1.1 Data Warehouse Design nach Bill Inmon

Bei der Konstruktion einer Data-Warehouse-Architektur ist ein heuristisches Vorgehen angebracht. Die Anforderungen an das zu erstellende System sind zu Beginn des Planungsprozesses nicht zwangsläufig vollständig vorhanden oder entwickeln sich erst zu einem frühen Zeitpunkt. Das Feedback von Anwendern kann die aufgenommenen Anforderungen im Entwicklungsprozess beeinflussen (vgl. [Inmon 2002, S. 81-101]).

Die Data-Warehouse-Architektur sollte eine unveränderliche Datensammlung, gemäß vom Anwender definierter Anforderungen, ermöglichen. Dabei ist die Datensammlung themen- und zeitorientiert, sodass eine Auswertung der Daten für Managemententscheidungen möglich ist.

Die Top-down-Entwicklungsorientierung führt dazu, dass Data Marts erst nach der fachlichen Fertigstellung des Core erstellt werden können (vgl. [Inmon 2002, S. 6-28]). Das Ziel von Data Marts ist es, den Informationsbedarf von Anwendern zu befriedigen. Sie beschreiben spezifische Informationen aus Sicht der erfassten Kundenanforderungen. Mithilfe mehrerer Dimensionen wird ein Data Mart erstellt, worin ausgewählte Informationen abgebildet werden. Data Marts werden dezentral, in Gruppen oder Bereichen, gebildet und verwendet. Ihre Lebenszeit ist an die Verwendung oder Projektlaufzeit geknüpft, sodass nicht verwendete Data Marts nicht zyklisch aktualisiert oder nur bei Bedarf aus dem Core geladen werden.

Inmons Core-Modellierung basiert auf drei Schritten:

1. Die Erstellung des Entity-Relationship-Modells

Dort werden Informationsobjekte, deren Attribute und bestehende Beziehungen abgebildet.

2. Die Definition des Mid-Level-Modells

In diesem Schritt werden Daten, entsprechend der Anforderungen, iterativ gruppiert.

3. Die Implementierung des physischen Datenmodells

Die vorher erstellten Datenmodelle werden auf der Datenbankebene implementiert.

(vgl. [Inmon 2002, S. 348-354]).

Das Core ist die einzige Datenquelle für Data Marts. Ein direkter Zugriff von Anwendern auf die Datenstrukturen des Core sollte vermieden werden (vgl. [Schnider et al. 2016, S. 7]).

Die empfohlene Realisierung von Anfragen ist in Abbildung 4 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Datenzugriff nach Bill Inmons Design

Diese Darstellung beschreibt den Datenzugriff in Bill Inmons Data Warehouse Design. Anwendern wird der Zugriff auf Data Marts ermöglicht. Die Data Marts beinhalten Daten für definierte Anwendungsfälle und Funktionen, wie z. B. Analysen und Auswertungen.

2.1.2 Data Warehouse Design nach Ralph Kimball

Der Bottom-Up-Ansatz von Kimballs Data Warehouse Design verfolgt, anders als das Design von Inmon, eine Modellierung ausgehend von den Data Marts. Erstellte Data Marts verwenden uniforme Dimensionen, wie z. B. Zeit und Produkt, gemeinsam.

Data Marts werden nach der Erstellung verknüpft und bilden das Data Warehouse. Die verknüpften Data Marts beziehen ihre Datensätze dabei über ETL-Prozesse entweder direkt aus den Quellsystemen oder der Staging Area (vgl. [Kimball und Ross 2013, S. 18-23]).

Ziel ist es, agile Anforderungen von Anwendern berücksichtigen zu können. Nachdem Data Marts definiert und geladen sind, ist es möglich, sie zu verwenden. Anpassungen innerhalb bestehender Data Marts führen zu Änderungen der ETL-Prozesse. Die Änderungskomplexität hängt vom Umfang der Anpassungen ab.

Die Modellierung der Data Marts kann in einem Stern- oder Schneeflockenschema erfolgen.

Eine Klassifikation der Hierarchie innerhalb des Sternschemas wird in Abbildung 5 allgemein dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Der Aufbau des Sternschemas

Das Sternschema ist denormalisiert, was eine schnellere Anfragebearbeitung ermöglicht. Diese Performancesteigerung entsteht durch die Reduktion von Verbundoperationen (Join). Für jede Dimension des Sternschemas ergibt sich exakt eine Dimensionstabelle. Eine zentrale Faktentabelle beinhaltet die Schlüsselattribute aller referenzierten Dimensionen (vgl. [Bauer und Günzel 2013, S. 242-249]).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Der Aufbau des Schneeflockenschemas am Beispiel einer Buchung

Eine Normalisierung der Struktur erfolgt über die Konkatenation aller Fremdschlüssel. Die Kenngrößen werden zentral in der Faktentabelle verwaltet. Der zusammengesetzte Primärschlüssel besteht aus den Fremdschlüsseln der referenzierten Dimensionen. Abfragen auf diese Struktur sind komplexer und weniger performant als Abfragen auf dem Sternschema.

Das Schneeflockenschema wird mit einer beschränkten Hierarchietiefe auch zur Versionierung von Bestandsdaten eingesetzt. Dazu wird nach der Änderung eines Datensatzes ein Gültigkeitsintervall für den betroffenen Datensatz erstellt. Für Ableitungs- und Auswertungsdatenbanken wird aus Performancegründen das Sternschema verwendet (vgl. [Bauer und Günzel 2013, S. 242-252]).

2.2 Die Verwendung von Data Warehouse im betriebswirtschaftlichen Kontext

Die Anforderungen betrieblicher Anwender eines Data-Warehouse-Systems liegen in der Bereitstellung konsistenter Datenbestände zu Auswertungszwecken. Diese Datenbestände müssen dazu bereinigt und geprüft werden.

Die erforderliche Flexibilität, nachfolgende Auswertungen beliebig zu gestalten, wird durch die Mehrfachverwendbarkeit gewährleistet. In Data-Warehouse-Systemen ist diese Systemeigenschaft gegeben, da einmal geschriebene Daten nicht verändert oder gelöscht werden. Der Zugriff durch den Anwender erfolgt ausschließlich lesend (vgl. [Bauer und Günzel 2013, S. 14-33]).

Weitere betriebswirtschaftliche Anforderungen sind in Abbildung 7 beschrieben.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Betriebswirtschaftliche Anforderungen an Data-Warehouse-Systeme

2.3 Kritik an bestehenden Systemarchitekturen

Künstliche Grenzen zwischen Abteilungen, Funktionsbereichen und Prozessen innerhalb einer Organisationsstruktur führen zu Streuverlusten bei der Informationsverarbeitung.

Die Verarbeitung von Informationen über Systemgrenzen hinweg führt aufgrund redundanter Bezeichnungen einzelner Attribute häufig zu Datenanomalien. Eine nachträgliche Anpassung der betroffenen Datensätze erfordert manuelle Eingaben von fachlich geschulten Anwendern. Diese Korrekturmaßnahmen führen zu Verzögerungen in der Informationsverarbeitung und schränken eine Echtzeitintegration der Datensätze weitgehend ein (vgl. [Mertens 2013, S. 23-35]).

Die allgemeine Fokussierung hin zur Automation von gut verstandenen Teilprozessen ist allgegenwärtig. Maßnahmen dafür stoßen jedoch an Grenzen, sobald ein einheitlich standardisiertes Vorgehen nicht Teil des bisherigen Architekturansatzes ist. Die Entwicklung, weg von Insellösungen einzelner Funktionsbereiche hin zu einem funktionsübergreifenden System, muss folgende Herausforderungen lösen:

1. Die Zugriffskomplexität steigt, daraus resultieren Anpassungen bestehender Anwendungsschnittstellen.
2. Berücksichtigung der Diskrepanz zwischen dem objektiven und subjektiven Informationsbedarf der Anwender.
3. Zugriffsberechtigungen müssen vollständig implementiert werden. Sie sind eine notwendige Voraussetzung für die Entwicklung von Fach- und Funktionsbereich übergreifenden Informationssystemen.

Rollenkonzepte, die fachliche Anwender in der Verwendung von funktionsüb ergreifenden Informationssystemen ausschließen, provozieren Engpässe in der Informationsgewinnung und -Verarbeitung.

Eine zentrale Anforderung an Informationssysteme ist, Informationen, über z. B. Marktveränderungen, zeitnah gewinnen zu können. Unterstützt durch diesen Sachverhalt entwickelte sich die Forderung nach Self-Service-Business-Intelligence-Anwendungen. Sie sind Bestandteil einer engpasskonzentrierten Strategie (vgl. [Schön 2016, S. 131-176]).

2.3.1 Die Verwendung von Rollenkonzepten

Rollenkonzepte definieren eine Gruppe von Personen mit gleichen oder ähnlichen Eigenschaften. Diese können auf Abteilungs-, Qualifikations- oder Funktionsebene gebildet werden. Durch Rollenkonzepte wird der Zugriff von Anwendern auf ein System oder auf eine Systemkomponente realisiert.

Berechtigungs- und Sicherheitskonzepte sollten in der Designphase entwickelt werden. Die dazu erforderlichen Entwurfsmaßnahmen ergeben sich innerhalb der Analysephase des Entwicklungsprojekts (vgl. [Bauer und Günzel 2013, S. 415-423]). Weiterführende Einflussfaktoren sind datenschutzrechtliche Vorgaben, wie die Pseudonymisierung personenbezogener Daten. Konkrete datenschutzrechtliche Vorgaben müssen frühzeitig in den Anforderungen fixiert werden. Anpassungen implementierter Komponenten gemäß rechtlicher Vorgaben im fortgeschrittenen Projektverlauf durchzuführen, ist aufwendig und kann zu Verschiebungen in der Zeit- und Kostenplanung führen. Eine revisionssichere Erfassung von Zugriffsstatistiken wird durch ein Berechtigungskonzept ermöglicht. Dabei ist jedoch zu beachten, dass ungewöhnliche Ereignisse und Vorkommnisse im Betrieb des Systems oder der Systemkomponente einer Gruppe fachlich verantwortlicher Mitarbeiter gemeldet werden muss. Die Ereignisdefinition kann über eine Mustererkennung realisiert werden. Ein unvollständiges Berechtigungskonzept schränkt Maßnahmen zur Steigerung der Informationssicherheit datenverarbeitender Systeme ein. Audits und IT-Prüfungen, die betroffene Systeme analysieren, gelten in Folge dessen als nicht bestanden. Die darauffolgende Implementierung notwendiger Anpassungen im laufenden Systembetrieb führt zu Änderungen der Ablauforganisation, sodass weitere Entwicklungskosten entstehen.

2.3.2 Entwicklung in time and budget

Die Produkt- und Projektentwicklung in vorgegebenen Zeit- und Kostenplänen betrifft die Entstehung von Data-Warehouse-Systemen. Ein konventionelles Vorgehen gemäß dem Wasserfallmodell ohne Iterationen ist unflexibel, denn wechselnde Anforderungen und Anpassungen der Entwicklungsziele können nur bedingt geplant werden. Das Risiko einer Fehlplanung ist demnach dabei stark erhöht. Die Fertigstellung innerhalb der Zeit- und Kostenplanung ist nur in 40 Prozent der Entwicklungsprojekte gegeben (vgl. [Forrester Research 2013, S. 2-5]).

Um Kosten, die in der Entwicklung von Data-Warehouse-Systemen entstehen, inhaltlich zu gliedern, können folgenden Kategorien erstellt werden:

1. Implementierungs- und Beratungskosten
2. Persistente Datenspeicher- und Speicher-Infrastrukturkosten
3. ETL-Kosten
4. Datenbank-Management-System und andere Infrastrukturkosten

Das Überschreiten von Zeit- und Kostenplänen in der Entwicklung kann zum vorzeitigen Abbruch des Projektes führen (vgl. [Gartner 2005]). Eine solche Entscheidung erfolgt unter Abwägung weiterer Entwicklungskosten, nämlich der dadurch entstehenden Folgekosten. Eine Darstellung der Entwicklungs- und Folgekosten findet sich in Abbildung 8. Diese beschreibt exemplarisch Betriebskosten von ETL-Prozessen, Beratungsleistungen, Datenbank-Management-Systemen und Speicherkosten. Abbildung 8 bietet eine Orientierungsgröße bei einem durchschnittlichen Datenwachstum über einen Zeitraum von zehn Jahren.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Langzeitkosten eines Data-Warehouse-Systems

Diese Darstellung ist normativ und zeigt eine Zunahme der Speicherkosten im Lebenszyklus. Die Kosten für ETL-Prozesse, Beratungsleistungen und Datenbank-Management-Systeme sinken auf den Anteil der Fixkosten für Softwarelizenzen sowie Energie- und Personalkosten.

2.3.3 Verbesserungsansätze bei der Entwicklung von Data Warehouse Systemen

Das Minimieren von Risikotreibern im Entwicklungsverlauf ist von zentraler Bedeutung bei der Implementierung informationsverarbeitender Systeme. In Abbildung 9 werden vier Einflussfaktoren dargestellt, die zu einer Verschiebung der Zeit- und Kostenplanung innerhalb des Projektverlaufs führen können.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Risikofaktoren in Entwicklungsprojekten

In agil durchgeführten Entwicklungsprojekten ist eine Anpassung der erfassten Anforderungen auch noch in einem späten Entwicklungsstadium möglich. Diese Anpassungen führen allerdings zu steigenden Entwicklungskosten. Wird versucht, diese zu kompensieren, leidet entweder die Qualität der Entwicklung oder aber die geänderten Anforderungen werden unvollständig dokumentiert. Daher ist es von Bedeutung, bereits im Vorfeld den Entwicklungshintergrund des Data-Warehouse-Projekts eindeutig zu bestimmen und diesen unternehmensweit zu kommunizieren. Auf die Entwicklungsziele im Kontext der bestehenden Infrastruktur muss dabei explizit eingegangen werden. Ein allgemein gut verstandener Nutzen einer technischen Neuentwicklung schafft Transparenz über den Umfang von Funktionen und Prozessen. Die konkrete Implementierung der einzelnen Ebenen, gemäß dem definierten Zweck, komplementiert das Vorgehen. Durch die Berücksichtigung dieser Maßnahmen kann die Eintrittswahrscheinlichkeit von Kostenüberschreitungen, Qualitätsmängeln und Anforderungsänderungen durch eine mangelhafte Anforderungsanalyse reduziert werden (vgl. [Wallmüller 2014, S. 23-58]).

Die transparente Entwicklung eines Data-Warehouse-Projekts umfasst die kontinuierliche Kommunikation zwischen Business-Analysten, technischen Analysten, Entwicklern, Architekten, Projektleitern und Stakeholdern, um die Erfassung und Berücksichtigung impliziter Anforderungen aller Beteiligten zu ermöglichen. Die strategische Folge daraus ist eine Engpasskonzentration, sodass einzelne Optima dem globalen Optimum entsprechen. Soll-Abweichungen innerhalb des Projekts werden zeitnah aufgedeckt, damit Maßnahmen für deren Behebung eingeleitet werden können.

Die Summe dieser Maßnahmen verringert die Wahrscheinlichkeit, dass die Entwicklung eines Data-Warehouse-Systems außerhalb der definierten Zeit- und Kostenplanung abgeschlossen wird.

2.4 Data Vault

Data Vault ist eine Modellierungsmethode zur Gestaltung von Data-Warehouse-Architekturen. Die spezifischen Stärken von Data Vault zeigen sich vor allem bei häufigen Strukturänderungen (vgl. [Hultgren 2012, S. 19-33]).

Data Vault ist eine detailorientierte Methode, um mehrere normalisierte Tabellen zu verbinden. Relationale Tabellen werden in drei verschiedenen Strukturtypen implementiert, nämlich Hubs, Satellites und Links.

Hubs beinhalten ausschließlich Business-Schlüssel der Entität sowie einen oder mehrere Schlüssel, die Links und Satellites referenzieren. Satellites bestehen aus beschreibenden Attributen. Sie modellieren Entitäten in einer historisierten Form. Die Zuordnung zwischen Satellites und den zu referenzierenden Links oder Hubs wird über eine Fremdschlüsselbeziehung realisiert. Links definieren Beziehungen zwischen mehreren, also mindestens zwei, Entitätstypen (Hubs).

Das in Abbildung 10 veranschaulichte Datenmodell umfasst Hubs (blau), Satellites (gelb) und Links (rot).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10: Grundlegender Aufbau eines Data Vault

In dieser Struktur werden beschreibende Attribute nie innerhalb eines Hubs gespeichert. Attribute, die Entitäten beschreiben, werden in Satellites persistiert. Die fachliche Abbildung der Kardinalitäten 1:1, 1:n und n:m entfällt. Für einen Link oder Hub können stets ein oder mehrere Satellites definiert werden. Die Unterscheidung zwischen dynamischen oder statischen Attributen ist durch zusätzliche Satellites möglich (vgl. [Schnider et al. 2016, S. 34-37]).

Die hohe Flexibilität innerhalb der Datenmodellierung entsteht durch die Beziehung zwischen mehreren Satellites und einem Hub. Durch dieses Konzept können in Satellites fachliche Attribute, Historisierungsstände und Quellsysteme zusammengefasst dargestellt werden.

Änderungen der Struktur können jederzeit durch zusätzliche Satellites realisiert werden. Eine anschließende Migration oder Änderungen an der bestehenden Struktur entfallen vollständig (vgl. [Linstedt und Olschimke 2015, S. 33-88]).

2.4.1 Eigenschaften der Modellierungstechnik

Die Modellierung mit Data Vault erfordert die zielgerichtete Zusammenarbeit von Entwicklern, Business-Analysten und Stakeholdern, daher eignet sich Data Vault für die agile Data-Warehouse-Entwicklung. Die kontinuierliche Implementierung und die daran anschließende Verteilung ermöglichen selbst im fortgeschrittenen Projektverlauf die Berücksichtigung geänderter Anforderungen, wie etwa Marktveränderungen oder Anpassungen des Informationsbedarfs (vgl. [Maxwell 2016]).

Mit der steigenden Anzahl von Tabellen, die durch Erweiterungen und Anpassungen entstehen, wächst die Komplexität des Datenmodells, da die Anzahl der Tabellen die Ladezyklen und -Zeiten beeinflusst. Davon betroffen sind vor allem die Dimensionen der Data Marts (vgl. [Schnider et al. 2016, S. 34-38]).

Die Vorteile der Möglichkeit zur Erweiterung liegen in der langfristigen Wartbarkeit und dem zukunftsorientierten Betrieb des Data-Warehouse-Systems. Die Wartung und der Betrieb umfassen zukünftige Formatänderungen, die Steigerung der Verarbeitungsgeschwindigkeit, eine wachsende Anzahl von Quellsystemen und sinkende Kosten in der Implementierung von Erweiterungen und Änderungen.

Die Core-Modellierung mit Data Vault ermöglicht den flexiblen Einsatz von Anwendungen zur Analyse- und Auswertung von Datenbeständen. Auf dieser Basis können Anwender von vorgegebenen Berichtswegen abweichen. Das heißt, sie können Informationen aus eigenen Analysen und Auswertungen entnehmen und sind weniger abhängig von verfügbaren Kapazitäten der Data-Warehouse-Einheit.

Einmal bestehende Datenstrukturen werden nicht mehr verändert. So entsteht kein Anpassungsbedarf innerhalb bereits existierender Auswertungen, Analysen und Anwendungen. Anpassungen werden durch das Hinzufügen von neuen Relationen gelöst. Durch die Struktur bestehend aus Hubs, Links und Satellites entfällt eine daran anschließende Datenmigration.

Tabellen und ETL-Prozesse lassen sich prinzipiell automatisiert generieren. Diese Eigenschaft ist in Entwicklungsprojekten von Vorteil, unabhängig davon, ob sie agil oder anderweitig durchgeführt werden, da die Code-Qualität standardisiert ist. Ermöglicht wird dies durch einheitliche Regeln für die Gestaltung von Ladestrecken und die darunterliegende Modellierung der Architektur (vgl. [Hultgren 2012, S. 167-175]).

2.4.2 Data-Warehouse-Modellierung mit Data Vault

Der Core des Data Warehouse wird durch die Verbindung von Raw und Business Data Vault gebildet. Abbildung 11 zeigt in diesem Zusammenhang die Position des Data Vault im Rahmen dieses Referenzmodells.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11: Raw und Business Data Vault in der Data-Warehouse-Architektur

Die Modellierung des Raw und Business Data Vault besteht aus drei Komponenten.

Die Tabellenstruktur eines Hubs beinhaltet einen Hashkey als Primärschlüssel, einen fachlichen Schlüssel, einen Zeitstempel, der den Ladezeitpunkt bestimmt, und die Ursprungsangabe des fachlichen Schlüssels. Abbildung 12 visualisiert die Struktur eines Hubs (vgl. [Hultgren 2012, S. 83-87]).

Abbildung 12: Bestandteile eines Hubs

Die Tabellenstruktur einer Link-Tabelle umfasst einen Hashkey, vorhandene Fremdschlüssel (mindestens zwei), einen Zeitstempel zur Bestimmung des Ladezeitpunkts und eine Quellenangabe über den Ursprung der Relation. Die Struktur eines Link ist in Abbildung 13 dargestellt (vgl. [Hultgren 2012, 93-107]).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 13: Bestandteile eines Link

Die Tabellenstruktur einer Satellite-Tabelle umfasst einen Fremdschlüssel zum referenzierten Hub, einen Primärschlüssel, bestehend aus dem Fremdschlüssel und dem Zeitstempel zur Bestimmung des Ladezeitpunkts, beschreibenden Attributen und einer Quellenangabe zum Ursprung der Relation. Der Fremdschlüssel referenziert exakt einen Hub oder Link. Zur Historisierung des Datensatzes kann mithilfe des Zeitstempels ein Gültigkeitszeitraum berechnet werden. Die Verbindung eines Satellites zu einem Link wird dann eingesetzt, wenn eine Beziehung zweier Hubs dies erforderlich macht. Ein praktisches Beispiel dafür ist die Beziehung zwischen den Hubs Abteilung und Stelle, denn diese wird durch einen Link realisiert und durch die Verbindung eines zusätzlichen Satellites-Angestellten am Link sinnvoll ergänzt. Abbildung 14 zeigt die Struktur eines Satellites (vgl. [Hultgren 2012, S. 113-117]).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 14: Bestandteile eines Satellites

3 Referenzmodellierung mit Data Vault

Zur Erstellung der fachlichen Data-Warehouse-Architektur mit Data Vault gibt es keine einheitlichen Modellierungsstandards. Dieses Referenzmodell soll einen Ansatz und eine Orientierung zur fachlichen Modellierung der Data-Warehouse-Architektur mit Data Vault bieten.

Das hier vorgestellte Referenzmodell wird in einer mehrschichtigen Architektur realisiert und anhand eines Ereignisses durch alle Schritte der Modellierung beschrieben. Der Aufbau erfolgt in mehreren Abschnitten (engl. Layer oder Area). Die unterste Ebene bildet die Staging Area, die als Schnittstelle mit den verwendeten Quellsystemen dient. Die Beschreibung des Core Layer, bestehend aus Raw und Business Data Vault, wird mit der Modellierungsmethode Data Vault abgebildet und basiert auf den Datenbeständen der Staging Area. Das Core Layer bildet die bereinigte Datenbasis für die Data Marts. Auswertungen und Analysen, die von Business-Intelligence-Anwendungen ausgehen, basieren auf den vorher erstellten Data Marts (vgl. [Bauer und Günzel 2013, S. 37-141]).

In Abschnitt 3.1 und 3.2 wird die Anforderungs- sowie die Infrastruktur- und Quellenanalyse beschrieben. Die Erläuterung der Modellierung und Implementierung der ETL-Prozesse und Ladestrecken folgt in Abschnitt 3.3. Eine Beschreibung des potenziellen Information Layer sowie eine Mehrwertanalyse des Referenzmodells schließen Abschnitt 3 ab.

Ziel der einzelnen Abschnitte ist die vollständige Referenzmodellierung eines Enterprise-Data-Warehouse, unter Berücksichtigung der Informationssicherheit des zu entwickelnden Systems.

3.1 Anforderungsanalyse

Die detaillierte Erfassung von Geschäftsprozessen und Anwendungsfällen ist zentraler Bestandteil eines j eden Entwicklungsproj ekts und zugleich Grundlage für nachfolgende Überlegungen bezüglich der Architektur und Implementierung der Systemkomponenten. Dieses Referenzmodell umfasst die funktionale Anforderungsanalyse. Damit enthält dieses Modell die Anforderungsspezifikation, Bedarfsanalyse und Aufzeichnung aller elementaren Anforderungen an das zu entwickelnde System. Eine Erfassung der Geschäftsprozesse und Anforderungen durch vom Nutzer zu definierende Ereignisse bietet einen umfassenden Einblick in funktionskritische Eigenschaften und Aufgaben des betroffenen Fachbereichs. Durch die gezielte Unterstützung eines Business-Analysten werden mündlich formulierte Anforderungen in fachliche Spezifikationen übertragen.

Ein Modell, das diesen Vorgang beschleunigt, Anwender und Entwickler entlastet und eine Reduktion des Arbeitsaufwands erreicht, ist das Business-Event-Analysis-Modell (BEAM). Eine Vorlage dieses Modells ist in Abbildung 15 dargestellt.

Ein vollständiges Template des BEAM-Modells kann unter (vgl. [Thoma 2017]) als .xlsx Datei abgerufen werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 15: Aufbau einer BEAM-Tabelle am Beispiel einer Kundenbestellung

Business Event Analysis and Modeling (BEAM) unterstützt die Ermittlung von Geschäftsereignissen. Diese werden analysiert, um Informationen über die Modellierung des Datenbankdesigns zu gewinnen. Dafür benötigte Attribute werden in Tabellenform erfasst und mithilfe von sieben W-Fragen beschrieben.

Dieses Format unterstützt Stakeholder und Entwickler. Stakeholder erhalten detaillierte, allgemein verständliche Informationen über die ermittelten Anforderungen und Data-Warehouse-Entwickler können diese Anforderungen anschließend in logischen und physischen Datenmodellen implementieren (vgl. [Corr und Stagnitto 2011, S. 21-29]).

BEAM-Tabellen enthalten spaltenorientierte Daten zu einzelnen Attributen. Die tabellarische Struktur der Ereignisse ermöglicht einen ganzheitlichen Überblick über den Verlauf des Ereignisses und dessen Einfluss auf vor- und nachgelagerte Teilprozesse. Stakeholdern dient diese Übersicht als Ausblick auf die zu erstellende Datenstruktur.

Die sieben W-Fragen zur Erstellung der BEAM-Tabellen beziehen sich auf messbare Details der Geschäftsaktivitäten. Messbar sind etwa Informationen, die sich aus folgenden Fragen ergeben:

- Who/Wer ist in den Verlauf des Ereignisses involviert?

(Beispiel: Lieferant, Kunde, Mitarbeiter, Unternehmen, Abteilung etc.)

- What/Was wird durch das Ereignis beschrieben?

(Beispiel: Dienstleistung, Produkt, Gegenstand, System etc.)

- When/Wann tritt das Ereignis ein?

(Beispiel: Datum, Uhrzeit etc.)

- Where/Wo tritt das Ereignis ein?

(Beispiel: Filiale, Online Shop, Ort, Adresse, Land etc.)

- How many/Wie viele Einheiten betrifft das Ereignis?

(Beispiel: 100 €, 50 Stück, 1 Container, 2 Europoolpaletten etc.)

- Why/Warum trat das Ereignis auf?

(Beispiel: Kunde erstellt Bestellung, Fehlerzustand in einem System etc.)

- How/Wie wirkt sich das Ereignis aus?

(Beispiel: Die neue Bestellung erhält eine Bestell_ID etc.)

Die dadurch ermittelten Informationen sollten mit den Anforderungen der Stakeholder übereinstimmen. Die BEAM-Tabelle ermöglicht auch die Dokumentation eines Ereignisses. Abbildung 16 zeigt eine von Stakeholdern erstellte BEAM-Tabelle für die Bestellung von Rohstoffen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 16: BEAM-Tabelle der Stakeholder

Entwicklern bietet die tabellarische Darstellung Informationen zur Komplexität der Datenstruktur. Eine vollständige BEAM-Tabelle beschreibt Attributwerte und deren Datentyp, Aggregationen und Historisierungsregeln der einzelnen Dimensionen. Entwickler vervollständigen die erhaltene Darstellung mit technischen Informationen zu den Dimensionen, wie z. B. Primär- und Fremdschlüssel, Constraints, Kommentare und Schnittstellendefinitionen der Quellsysteme. Abbildung 17 zeigt die vollständige BEAM-Tabelle für das Ereignis ,Rohstoffe wurden bestellt‘.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 17: Eine durch Entwickler ergänzte BEAM-Tabelle

Aus Gründen der Übersichtlichkeit beschränkt sich Abbildung 17 auf ein Attribut je Fragestellung. Umfangreiche Ereignisse umfassen mehrere Attribute je Fragestellung. Abbildung 18 visualisiert alle Attribute der Fragestellung how/wie für die Bestellung von Rohstoffen. Diese umfassen ergänzende Informationen zur Bestellart.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 18: Eine um weitere Informationen zur How/Wie-Frage ergänzte BEAM-Tabelle

Zur weiteren Beschreibung der zu erstellenden Datenstruktur können hierarchische Darstellungen einzelner Teilprozesse herangezogen werden. Eine zeitbasierte Sicht der Teilprozesse beschreibt Veränderungen im Lauf der Transformation. In Abbildung 19 ist dies für das Beispiel des Bestellprozesses ersichtlich.

Abbildung 19: Zeitbasierte Darstellung des Bestellprozesses

Eine hierarchische Darstellung des Bestellprozesses ist in Abbildung 20 modelliert.

Abbildung in dieser Leseprobe nicht enthalten

Beide Diagramme ermöglichen eine exakte Erfassung von Teilprozessen. Alternativ können beide Diagrammtypen verwendet werden, um Quellsysteme und deren Umfang abzubilden.

Eine systemweite Beschreibung des Informationszugriffes ist ebenfalls Teil der Anforderungsanalyse. Bestimmungen für das Zugriffsmanagement sind von einer Vielzahl Faktoren abhängig. Im Rahmen dieses Referenzmodells wird ein Rollenkonzept nach POLP, Principle of least privilege, verwendet.

Zur Einhaltung der Zeit- und Kostenplanung sollten die fachlichen Anforderungen gemäß der Zielsetzung erfasst werden. Mögliche Schwierigkeiten im Entwicklungsverlauf lassen sich durch diese Modellierung auf ein Minimum reduzieren. Gemeint sind etwa Interessenskonflikte, also unterschiedliche Ziele seitens der Nutzer, unbekannte technische Rahmenbedingungen oder sich ändernde Anforderungen und Prioritäten schon während des Entwurfsprozesses.

Die Modellierung der Anforderungen mit BEAM-Tabellen bietet Vorteile bei der Erstellung oder Evaluation von Self-Service-Business-Intelligence-Anwendungen. Zukünftige

Business-Intelligence-Anwender sind in der Phase der Anforderungsanalyse involviert, was die Akzeptanz der Neuentwicklung innerhalb der betroffenen Fach- und Funktionsbereiche erhöht.

3.2 Infrastruktur- und Quellenanalyse

Vorbereitende Maßnahmen der Infrastruktur- und Quellenanalyse ermöglichen ein allgemeines Verständnis der theoretischen Grundlagen, die bei der Modellierung von fachlichen Anforderungen der Data-Warehouse-Architektur von Vorteil sind. Wenn derartige Maßnahmen vor dem Projektbeginn abgeschlossen sind, verkürzt sich die Spezifikationsphase des Entwicklungsprojekts.

Bestehende informationsverarbeitende Systeme, die zur Planung und Steuerung von Ressourcen, Produktionskapazitäten, Kunden und Lieferanten dienen, zählen dazu. Sie bilden die Datenquellen für das Data Warehouse System. Sofern keine Abbildungen oder Aufzeichnungen zur IT-Infrastruktur vorhanden sind, sollten diese vor der Entwicklung des Data-Warehouse-Systems erstellt werden.

Abbildung 21 zeigt eine Systemlandschaft, bestehend aus Quellsystemen, ETL-Prozessen und dem Data Warehouse. Eine angereicherte Darstellung der Systemlandschaft enthält Informationen zur Lizenzform und Version der einzelnen Quellsysteme sowie eine Beschreibung des verwendeten Datenbank-Management-Systems und der geplanten Kapazität des Data Warehouse.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 21: Systemlandschaft bestehend aus Quellsystemen, ETL und Data Warehouse

Informationen zu Datenschnittstellen werden zur Definition der ETL-Prozesse benötigt, da Datenschnittstellen Daten und Datenformate beschreiben, die von einem System erfasst und übermittelt werden können. Die Syntax der Daten wird in erster Linie durch das Datenmodell des Quellsystems definiert. Eine spätere Transformation des Datenformats ist im Data Warehouse System möglich.

3.2.1 Mock-up der Anforderungsanalyse

Ein Veranschaulichungsmodell bietet Stakeholdern, also Anwendern, Fach- und Funktionsbereichen, die Möglichkeit, Anforderungen zu verifizieren. Die Erstellung des Modells ist mit finanziellem und zeitlichem Aufwand verbunden. Die Verwendung von Veranschaulichungsmodellen ermöglicht gleichzeitig ein umfangreiches Testmanagement. Qualitätssichernde Maßnahmen, die im frühen Entwicklungsstadium ausgeführt werden, sichern im Projektverlauf den Kosten- und Zeitplan. Spät erkannte Qualitätsmängel innerhalb der Datenstruktur führen zu inhaltlich falschen Auswertungen und Analysen. Eine nachträgliche Fehlerbehebung ist mit hohem Aufwand verbunden und Maßnahmen zur Fehlerbehebung führen zwangsläufig zu Abweichungen von der bestehenden Kosten- und Zeitplanung (vgl. [Bauer und Günzel 2013, S. 423-427]).

Die Zehnerregel der Fehlerkosten, eine Erfahrungsregel aus dem Qualitätsmanagement, sagt aus, dass sich die Kosten zur Behebung von Fehlern in jeder Phase der Wertschöpfung um den Faktor Zehn erhöhen. Daraus ergibt sich die folgende Erkenntnis: Umso früher ein Fehler entdeckt und beseitigt wird, desto weniger Kosten werden in diesem Prozess durch ihn verursacht (vgl. [Schmitt und Pfeifer 2015, S. 13-38]).

Diese Erkenntnis lässt sich auf die Data-Warehouse-Entwicklung übertragen, denn der beschriebene Faktor Zehn ist kein exakter Messwert, sondern vielmehr eine Beschreibung für die Ungleichverteilung der bei der Fehlerbeseitigung entstehenden Kosten. In der Entwicklung informationsverarbeitender Systeme sind es nicht primär Entwicklungsfehler, die zu Verschiebungen der Kostenplanung führen, sondern es sind Änderungen und Anpassungen der Anforderungen, die im fortgeschrittenen Projektverlauf zu Abweichungen von den geplanten Entwicklungskosten führen können.

Das in Abbildung 22 dargestellte Diagramm beschreibt die Kosten für Änderungen und Anpassungen der Datenstruktur in drei Projektphasen. Es ist zu erkennen, dass die Änderungskosten in der letzten Phase, dem Produktivbetrieb, am höchsten sind.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 22: Änderungskosten im Projektverlauf

Stakeholder können notwendige Anpassungen mithilfe von Veranschaulichungsmodellen früher erkennen und den Bedarf entsprechend kommunizieren. Die frühe Erkennung und daran anschließend die Behebung der Problemstellung führen zu Aufwänden, die, verglichen mit den entstehenden Kosten im fortgeschrittenen Projektverlauf, als marginal bezeichnet werden können.

Damit ist die Verwendung von Veranschaulichungsmodellen ein zentraler Bestandteil dieses Referenzmodells. Ein beschreibendes Veranschaulichungsmodell besteht aus zwei Teilen: dem darzustellenden Anwendungsfall oder Ereignis und den betroffenen Attributen. Diese werden in einer grafischen Darstellung abgebildet und durch einen oder mehrere Datensätze beschrieben.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 23 beschreibt die grafische Modelldarstellung für das Ereignis ,Rohstoffe wurden bestellt‘.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 23: Mock-up für das Ereignis ,Rohstoffe wurden bestellť

Diese Darstellung kann erst nach Abschluss der Anforderungsanalyse erstellt werden. Wenn das Modell unvollständig oder fehlerhaft ist, durchläuft die Anforderungsanalyse eine Iteration. Im Anschluss an jede Iteration folgt die Erstellung des Modells. Bestätigen die Stakeholder und Funktionsbereiche ihre Anforderungen, kann das Modell innerhalb der Entwicklung mehrfach Verwendung finden. Auf Basis des Modells können ein Data Mart und nachfolgende Analysen definiert werden. Sollten modellierte Attribute aus mehreren, mindestens zwei, Bestandteilen bestehen, muss diese Information bei der Implementierung der ETL-Prozesse berücksichtigt werden. Die Erfassung der funktionalen Abhängigkeiten durch das erstellte Mock-up senkt auch die Entwicklungskomplexität der Staging Area sowie der darauffolgenden Ladestrecken.

Unter Mitwirkung der Fach- und Funktionsbereiche werden die geforderten Attribute ermittelt. Die Resultate sind schnell verwertbar, robust und verhindern Missverständnisse, die die Erreichung des angestrebten Ziels gefährden könnten (vgl. [Schrade 1996, S. 50-53]).

3.2.2 Rollenkonzept nach dem Principle of least privilege

Die Erstellung datenverarbeitender Systeme ohne die vorherige Definition eines Rollenkonzepts kann weitreichende Konsequenzen haben. Durch externe und interne Angriffe sowie fehlerhafte Eingaben von Anwendern können die Verfügbarkeit, Vertraulichkeit und Integrität des Systems gefährdet werden.

Das Principle of least privilege soll die Eintrittswahrscheinlichkeit dieser Ereignisse senken, denn Anwender erhalten dabei nur die Privilegien, die zur Ausführung ihrer Aufgabe notwendig sind. Sollten dem Anwender im Rahmen einer Aufgabenstellung zusätzliche Rechte gewährt werden, müssen diese sofort nach Beendigung der Arbeiten wieder entzogen werden.

Das Principle of least privilege basiert auf dem Grundsatz:

Wenn der Anwender die Privilegien nicht benötigt, sollte er sie nicht haben.

Zur Rechtevergabe werden Anwender des Systems klassifiziert. Eine Gruppe von Anwendern mit gleichen Eigenschaften hat demnach auch die gleichen Privilegien. Eine Rolle, die Summe mehrerer Privilegien, besitzt die notwendigen Rechte, um definierte Aufgaben zu erfüllen. Alle übrigen Rechte, die zur Erfüllung der Aufgabenstellung nicht benötigt werden, sind daher auch nicht Teil der Rolle. Sollten sich die Anforderungen der Aufgabenstellung ändern, wird die Rolle entsprechend angepasst. Die Änderung einer Rolle betrifft alle Anwender, die dieser Rolle zugeordnet sind, das heißt, alle Anwender benötigen die angepassten Privilegien, um ihre Aufgabe zu erfüllen. Sollten nicht alle Anwender der Gruppe von dieser Änderung betroffen sein, ist es notwendig, eine neue Rolle mit angepassten Privilegien zu erstellen. Die beschriebenen Berechtigungskonzepte gelten für Administratoren, Entwickler, Analysten und Nutzer des Systems. Diese Einschränkung betrifft Administratoren und Entwickler vor allem in den Entwicklungsphasen bis hin zur Modellierung und Ladung der Data Marts. Prinzipiell sollten Business-Intelligence-Anwender ihre Analysen und Auswertungen nur im Information Layer vornehmen können. Das heißt, sie erhalten weder lesenden noch schreibenden Zugriff auf die Datenstrukturen, die als Basis für das Information Layer verwendet werden.

Dieses Vorgehen limitiert den potenziellen Schaden, der aus Fehlerzuständen resultieren kann, denn die Anzahl der Funktionen, die ein Anwender des Systems ausführen kann, ist auf jene begrenzt, die er für seine Aufgabenstellung benötigt. Ungewollte Falscheingaben oder Änderungen werden reduziert, da die Berechtigungen der Rolle diese verhindern. Die Anzahl unsachgemäßer Aktionen, die durch die Vergabe falscher Privilegien entstehen, wird reduziert (vgl. [Saltzer 1975, S. 9]).

Berechtigte Zugriffe werden protokolliert. Dabei wird auch die missbräuchliche Verwendung von Privilegien dokumentiert und an zuständige Administratoren weitergeleitet. Im produktiven Betrieb ist es aufwendig, eine granulare Verteilung der Privilegien vorzunehmen. Um diesen Aufwand zu verringern, bestehen Funktionen und Teilprozesse aus einer definierten Menge an Grundoperationen. In Datenbank-Management-Systemen umfassen diese Grundoperationen das Schreiben, Lesen, Verändern und Löschen von gespeicherten Datensätzen (vgl. [Bishop 2008, S. 340-346]).

Rollenbasierte Zugriffskontrollsysteme definieren die Privilegien einzelner Rollen anhand ausgeführter Funktionen. Die Rechte eines Datenbankentwicklers unterscheiden sich demnach von denen eines Business-Intelligence-Anwenders. Eine Abstimmung der notwendigen Privilegien mit den Anwendern ist essenziell, denn durch ein nicht verstandenes Rollenkonzept fühlen sich Anwender bevormundet und in ihrer täglichen Arbeit eingeschränkt (vgl. [Kriha und Schmitz 2009, S. 99-108]). Die unternehmensweite Akzeptanz und das Verständnis für die Implementierung eines restriktiven Berechtigungskonzepts umfasst das Verständnis über die Schutzbedürftigkeit von Informationen und Daten. Dies wird innerhalb dieses Referenzmodells in vier Stufen dargestellt. Eine Klassifikation sieht folgende Stufen vor:

- Öffentlich

Diese Informationen beschreiben öffentliche Inhalte. Auf Datensätze mit dieser Klassifikation können alle Anwender zugreifen.

- Intern

Informationen, die als intern klassifiziert werden, beschreiben Inhalte, deren Offenlegung zu einem geringen finanziellen Schaden führen kann. Der Zugriff auf diese Daten wird durch eine unterschriebene Verpflichtungs- und Vertraulichkeitserklärung der Anwender erlangt.

- Vertraulich

Der Verlust vertraulicher Informationen kann zu einem erheblichen finanziellen Schaden führen. Rechnungsinformationen, Managementberichte und strategische Informationen werden derart klassifiziert. Der Personenkreis, der auf diese Informationen zugreifen darf, ist eingeschränkt. Die Notwendigkeit der Information zur Erfüllung der Aufgabenstellung führt zum Erlangen der Zugriffsberechtigung.

- Streng vertraulich

Informationen, die als streng vertraulich klassifiziert werden, umfassen Inhalte, deren Offenlegung zu einem hohen finanziellen Schaden führen kann. Solche Informationen enthalten Kundenstammdaten, Zugangsdaten sowie Zahlungs- und Personalinformationen. Die Zugriffsberechtigung für diese Datensätze ist restriktiv. Jeder Datenzugriff wird vollumfänglich erfasst und revisionssicher aufgezeichnet.

Alle in der Anforderungsanalyse erfassten Ereignisse und deren Attribute werden gemäß dieser vier Stufen klassifiziert.

Sollten einzelne Attribute in unterschiedlichen Ereignissen ungleich klassifiziert werden, muss diese Diskrepanz erfasst werden und es muss eine eindeutige Einstufung erfolgen. Ist keine Einigung möglich, ist die Klassifikation der Information oder des Datensatzes durch die jeweils höhere Stufe zu forcieren.

Stakeholder sowie Fach- und Funktionsbereiche können benötigte Datenzugriffe am besten artikulieren, denn sie sind diejenigen, die durch ein mangelhaft erstelltes Berechtigungskonzept direkt betroffen sind. Dieses Vorgehen führt zwar zu umfassenderen Privilegien der einzelnen Rollen, dennoch ist diese Variante effizienter als die Erstellung durch die fachverantwortlichen Mitarbeiter der IT-Abteilung.

Eine wie in Abbildung 24 dargestellte Zugriffsberechtigung sollte im Rahmen der Infrastrukturanalyse für alle Ereignisse der Fach- und Funktionsbereiche erstellt werden. Alle Business-Intelligence-Anwender, die nicht aktiv an der Entwicklung und dem Betrieb des Data- Warehouse-Systems beteiligt sind, erhalten grundsätzlich keine Berechtigung zum Erstellen, Ändern oder Löschen von Datensätzen des Data Warehouse.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 24: Bestimmung der Zugriffsberechtigung

Die einzelnen Rollen werden durch definierte Nutzer ausgefüllt, sodass die Rolle des Einkäufers beispielsweise Elsa Müller zugeordnet wird. Diese Rollenverteilung ermöglicht das Protokollieren von Datenzugriffen auf Basis des Nutzers anstatt auf Basis der unspezifischen Rolle des Einkäufers. Zur Initialisierung und Implementierung kapitaler Änderungen der Systemumgebung ist in Abhängigkeit der Unternehmensgröße ein Mehr-Augen-Prinzip einzuführen.

3.2.3 Autorisierung und Authentisierung des Informationszugriffs

Vor der Verwendung von Analyse- und Auswertungssystemen ist es notwendig, den Nutzer zu authentifizieren und dessen Berechtigungen zu prüfen.

Dieser Schutz vor unbefugten Zugriffen ist in der Architektur sicherer Systeme von essenzieller Bedeutung. Durch die Authentisierung verifiziert der Nutzer seine Identität gegenüber dem System. Umgekehrt prüft das System die Identität des Nutzers. Die verwendeten Merkmale beschränken sich auf einen Benutzernamen und eine Passphrase. Die Verwendung von Single sign-on, einer Einmalanmeldung, die an Betriebssystemen ausgeführt wird, ist komfortabel und weit verbreitet. Der Nutzer meldet sich einmalig an und authentifiziert sich für die Nutzung aller Dienste, für die er die Berechtigungen besitzt (vgl. [Eckert 2006, S. 667-668]).

Anwender sollten im Umgang mit und bei der Erstellung von Passphrasen unterstützt werden, denn durch die unsachgemäße Verwendung von Passphrasen können der Nutzer und das darunterliegende System kompromittiert werden. Die Erstellung einer Veranstaltung, die das Ziel verfolgt, die Wahrnehmung von Anwendern bei der Auswahl von Passphrasen zu erhöhen, sollte ein Teil der Entwicklung sein.

Der Zugriff auf Analyse- und Auswertungssysteme wird im Rahmen dieses Referenzmodells über eine Mehr-Faktor-Authentifizierung realisiert (vgl. [Kriha und Schmitz 2009, S. 363-374]). Die verwendeten Faktoren sind der Benutzername, eine Passphrase, eine Zusatzfrage und die Geräteadresse. Eine Authentifizierung des Nutzers erfolgt in vier Schritten:

1. Eingabe des Benutzernamens
2. Simultan wird die Geräteadresse mit den hinterlegten Daten verglichen. Ist das Resultat dieses Vergleichs negativ, wird die Authentifizierung beendet. Ein positives Resultat des Vergleichs führt zu Schritt drei.
3. Eingabe der Passphrase. Die Eingabe wird mit dem hinterlegten Datensatz verglichen. Fällt der Vergleich negativ aus, kann eine erneute Eingabe erfolgen. Ein positiver Vergleich führt zu Schritt vier.
4. Beantworten einer Zusatzfrage. Diese Frage wird zufällig aus einer Menge von fünf vom Nutzer hinterlegten Fragen ausgewählt. Die korrekte Eingabe schließt die Authentisierung des Nutzers ab.

Diese Authentifizierung schützt das System gegen den Zugriff durch unberechtigte Dritte. Die Eingaben und Anmeldeinformationen werden protokolliert und gespeichert. Die Überwachung und Auswertung der Logdatei nach definierten Mustern kann Anomalien im Nutzerverhalten belegen. Nach erfolgreicher Authentifizierung gibt das System dem Nutzer Funktionen, Analysen und Auswertungen frei, für die er autorisiert ist. Dazu werden die Berechtigungen des Nutzers mit der Klassifikation verwalteter Datensätze verglichen.

In Bezug auf Abbildung 24 bedeutet dies, dass ein Nutzer der Rolle Einkäufer Analysen und Auswertungen für das Ereignis ,Rohstoffe wurden bestellt‘ ausführen kann. Die Basis bildet das Berechtigungskonzept, in dem ein lesender Zugriff für Einkäufer definiert ist. Andere Rollen, wie die des Konstrukteurs, sind nicht autorisiert, Analysen und Auswertungen für das Ereignis einzusehen.

Für alle Rollen, die nicht an der Entwicklung und dem Betrieb des Data-Warehouse-Systems beteiligt sind, erfolgt die Authentisierung und Autorisierung des Informationszugriffs im Information Layer. Auf vorgelagerte Verarbeitungsschritte sollten Anwender keinen Einfluss haben. Das umfasst auch den lesenden Zugriff auf Staging- oder Core-Tabellen. Eine Trennung der Zuständigkeiten für die Verwaltung sensibler Datensätze ist notwendig, um der Omnipotenz einzelner Personengruppen vorzubeugen.

3.3 Erstellung der ETL-Prozesse

ETL ist ein Akronym für Extract, Transform und Load und beschreibt einen dreistufigen Prozess, bei dem Daten aus verschiedenen Quellsystemen zusammengeführt werden. Während der Extraktion werden Teilmengen der Quellsysteme identisch kopiert. Die Transformation verändert die Syntax und Semantik der Daten nach einem definierten Schema. Im letzten Teilschritt des ETL-Prozesses, nämlich dem Laden, werden die aus dem Quellsystem extrahierten und anschließend transformierten Datensätze in eine Zieltabelle übertragen (vgl. [Hultgren 2012, S. 171-173]).

Zweck der ETL-Prozesse ist die Konsolidierung mehrerer Datenquellen, um sie in einem Data Warehouse für Analysen und Auswertungen aufzubereiten. Die Transformation der Datensätze ist vielfältig und durchläuft mehrere Stufen.

Abbildung 25 ist eine eigene Darstellung in Anlehnung an (vgl. [Hultgren 2012, S. 172]). Dort werden die Transformationsprozesse beschrieben, die zwischen der Extraktion und dem Laden der Datensätze auftreten können.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 25: Transformationsprozesse in der ETL Pipeline

Die Anforderungen an ETL-Prozesse steigen simultan mit den Datenbeständen moderner Data-Warehouse-Systeme. Aufgrund aktueller Entwicklungen und der Bestrebung zur Echtzeitintegration von Transaktions- und Bewegungsdaten werden die Ladezyklen in vielen Systemen stark verkürzt. Die Echtzeitintegration führt indes zu sogenannten multi- und microbatches, die wenige Datensätze mit einer hohen Frequenz extrahieren.

Deren Operationszeit ist in Abhängigkeit der Systemkonfiguration synchron zu anderen Prozessen, asynchron oder zeitlich bestimmt. Die erhöhte Frequenz der Ladezyklen bedarf einer effektiven Ressourcenverwaltung für Ein- und Ausgabe-Prozesse. Im Hinblick auf etwaige Service Level Agreements verfolgt dieser Abschnitt den Zweck, zentrale Anforderungen an ETL-Prozesse zu bestimmen und deren ressourcenoptimierte Implementierung zu beschreiben. Die Operationsdauer umfangreicher ETL-Prozesse ist abhängig von zwei wohldefinierten Parametern: erstens der fachlichen Implementierung und zweitens der ETL-Plattform. Der Umfang der Datenladungen ist abhängig vom abzubildenden Zeitraum. Eine initiale Ladung ist demnach umfangreicher als ein zeitgesteuerter microbatch, denn dieser umfasst gegebenenfalls keine neuen Datensätze. ETL-Prozesse beinhalten alle Ebenen der Data-Warehouse-Architektur.

Ein Beispiel für die Initialladung der Bestellart für das Ereignis ,Rohstoffe wurden bestellt‘ findet sich in Abbildung 26. Der abgebildete SQL-Befehl erstellt eine identische Kopie der erforderlichen Attribute des Supplier-Relationship-Management-Systems. Diese Daten werden in die Staging-Tabelle STAGE.Rohst_bestellt_art geladen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 26: ETL Coding STAGE.Rohst_bestellt_art

Sollten einzelne Datensätze der Ladung einen Ausnahmefall hervorrufen (engl. Exception) werden diese in die Tabelle STAGE.etl_Protokoll verschoben. Bei Bedarf können die betroffenen Datensätze angepasst und manuell nachgeladen werden. Alle auf die Initialladung folgenden ETL-Prozesse extrahieren einzig Datensätze, die sich noch nicht in der Staging Area befinden. Dieses Vorgehen wird Delta-Ermittlung genannt (vgl. [Jordan und Schnider 2011, S.89-94]).

Diese Struktur lässt sich auf sämtliche ETL-Prozesse in allen Ebenen der Data-Warehouse-Architektur übertragen. Im Rahmen dieses Referenzmodells erfolgt die Transformation der Datensätze in drei Ebenen. Im ersten Schritt, der fachlichen Modellierung, werden die Datensätze gemäß den Anforderungen verknüpft. Abgebildet wird dieser Schritt im Raw Data Vault. Die Transformation der Daten gemäß der Geschäftslogik erfolgt im Business Data Vault. Der letzte Transformationsprozess findet in den Data Marts statt, wo Analysen und Auswertungen gemäß den aufgenommenen Ereignissen modelliert werden.

Auf eine zusätzliche Ebene, eine Cleansing Area, zwischen der Staging Area und dem Core wurde in diesem Referenzmodell bewusst verzichtet, was aber dazu führt, dass die Nachvollziehbarkeit bei fehlerhaften Transformationen oder bei fachlich von den Anforderungen abweichenden Implementierungen eingeschränkt ist. Dieser Verzicht führt gleichzeitig zu einer schnelleren Anfragebearbeitung, was vor dem Hintergrund der Echtzeitintegration ein erstrebenswertes Ziel ist. Durch die Automation der Ladeprozesse kann eine gleichbleibend hohe Qualität der ETL-Prozesse gewährleistet werden. Aus diesen Bestrebungen resultiert außerdem die Reduktion falscher Transformationen, was den Verzicht auf eine Cleansing Area ebenfalls rechtfertigt.

3.4 Staging Area

Die Data Staging Area wird zur zentralen Datenbeschaffung und als temporärer Zwischenspeicher verwendet. Datensätze, die aus den Quellsystemen geladen werden, sind temporär in der Staging Area abgelegt. Der Zeitraum der Speicherung variiert. Das Ziel der Datenhaltung liegt in einer schnellen Verarbeitung der Datensätze. Dies erfolgt, indem Datensätze über ETL-Prozesse extrahiert, inhaltlich verknüpft und in das Raw Data Vault geladen werden. Aufgrund unbeständiger Datenverarbeitungsgeschwindigkeiten in den Quellsystemen, Engpässen bei der Netzwerkübermittlung oder fehlenden Verarbeitungsressourcen kann der Zeitraum für die Speicherung der Datensätze nicht bestimmt werden.

Tabellen, die in der Staging Area erstellt werden, müssen inhaltlich und fachlich vollständig beschrieben werden. Um Ressourcen zu schonen und Kosten zu reduzieren, beschränkt sich die inhaltliche Beschreibung auf die Historisierung der Parameter, nach denen die Tabelle erstellt wurde. Diese Parameter beschreiben den selektierten Zeitraum, die Anzahl ausgewählter Tupel und den SQL-Befehl zur Erstellung der Relation. Die nachträgliche Bereinigung der Datensätze wird durch das Nachladen ausgewählter Zeiträume ermöglicht (vgl. [Bauer und Günzel 2013, S. 93-112]).

Das Erstellen der microbatches, also Teilladungen der Quellsysteme, erfolgt unter Berücksichtigung technischer Kriterien. Oberste Priorität hat die Bereitstellung der Datensätze für nachfolgende Verarbeitungsschritte. Um den Kommunikationsaufwand zwischen den Quellsystemen und dem Datenbank-Management-System zu reduzieren, wird eine zeitgesteuerte Abfrage der Quellsysteme vorgenommen. Eine Delta-Ermittlung, also die Bestimmung von Datensätzen, die sich in den Quellsystemen befinden und noch nicht in die Staging Area geladen wurden, erfolgt in Intervallen von 30 Sekunden. Zweck solcher Intervalle ist die vollständige Datenintegration in einem Zeitraum von fünf Minuten nach der Erstellung des Datensatzes im Quellsystem. Liegt die Verarbeitungsgeschwindigkeit über alle Verarbeitungsschritte hinweg unter diesem Wert, lässt sich dieses Vorgehen als weiche Echtzeitintegration beschreiben. Diese bildet einen Kompromiss zwischen den Echtzeitanforderungen und der effektiven Datenverarbeitung.

Operative Systeme zur Datenanalyse haben keinen direkten Zugriff auf die Staging Area, denn der direkte Zugriff auf abgeschlossene Teilladungen der Staging Area ist ausschließlich dem Raw Data Vault vorbehalten. Dieses ist Teil des Cores. Eine Teilladung wird aus der Staging Area entfernt, nachdem die Datensätze vollständig in das Raw Data Vault geladen wurden. Die Verwendung einer persistenten Staging Area ist in diesem Referenzmodell nicht vorgesehen. Sollten, zwecks Datenbereinigung oder aufgrund von aufgetretenen Fehlern in der Verarbeitung, einzelne Teilladungen wiederholt benötigt werden, müssen diese erneut aus den Quellsystemen in die Staging Area geladen werden.

Abbildung 27 zeigt den Aufbau der Staging Area und deren Eigenschaften.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 27: Aufbau der Staging Area

Das Laden gleicher Attributbezeichnungen aus verschiedenen Quellsystemen wird über das Hinzufügen eines Prä- oder Suffixes modelliert. Die Identifikation einzelner Teilladungen wird über eine Lade_ID realisiert. Die Vergabe der Kennzeichnung (engl. identifier) erfolgt automatisiert durch eine definierte Prozedur. Eine Kennzeichnung der Quellsysteme als beschreibendes Attribut innerhalb der Datenstruktur ist in allen Teilladungen vorzusehen.

Eine Datenbanktabelle, die erforderliche Ladeinformationen enthält, kann wie in Abbildung 28 dargestellt implementiert werden. Diese Struktur zeigt die Datenladung mit einem eindeutigen Schlüssel die Prozedur, in der die ETL-Implementierung enthalten ist sowie eine Zuordnung des Quellsystems (vgl. [Jordan und Schnider 2011, S. 103-108]).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 28: Staging Datenbanktabelle

Die nach dieser Struktur erstellte Staging-Tabelle Bestellart ist in Abbildung 29 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 29: Datensätze der Staging-Tabelle Bestellart

Der Verzicht auf Transformationen innerhalb der ersten Ladestrecke zwischen den Quellsystemen und der Staging Area führt zu einer optimierten Ressourcenauslastung. Diese ermöglicht den gezielten Einsatz der Ressourcen, um eine Echtzeitintegration der Datensätze im Information Layer zu erreichen. Datenzugriffe der Anwender auf die Staging Area sind nicht vorgesehen. Grund dafür ist die zeitlich eingeschränkte Beständigkeit der Staging Area (vgl. [Saake et al. 2010, S. 29]).

3.5 Raw Data Vault

Das Raw Data Vault besteht aus fachlichen Datenstrukturen. Daten in dieser Struktur sind nicht volatil, themenorientiert und unabhängig von Zeit und Art des Abrufs. Die geladene Struktur integriert die Daten der Staging Area vollständig. Geschäftslogiken, wie die Berechnung von Kennzahlen oder Währungsumrechnungen, werden in diesem Schritt nicht implementiert und folgen im Business Data Vault. Für die hier vorgestellte Referenzarchitektur ist das Raw Data Vault dennoch von zentraler Bedeutung, denn es bildet die einzige Schicht des entstehenden Systems, die vollständig integriert sowie persistent ist und deren Inhalte bis zu den Quellsystemen nachvollziehbar sind. Ein Verzicht auf das Raw Data Vault ist nicht möglich, da es die Basis für eine der zentralen Anforderungen der Stakeholder abbildet: die Datenqualität für den Single Point of Truth.

Eine vollumfängliche Dokumentation aller implementierten Teilmengen des Raw Data Vault ist erforderlich, um allen Anwendern des Data-Warehouse-Systems dessen Umfang und Funktion verständlich vermitteln zu können. Die Erhaltung der Datenqualität wird über Qualitätskriterien gesichert. Innerhalb des Lebenszyklus eines Datensatzes wird das betroffene Attribut bei Änderungen stets aktualisiert, jedoch nicht gelöscht. Qualitätskriterien sind zielgerichtet und beschreiben im ersten Schritt nur die erkannte Abweichung von den definierten Qualitätsanforderungen. In einem zweiten Schritt können die ermittelten Datensätze gemäß den Qualitätskriterien angepasst werden. Die Ermittlung fehlerhafter Ausprägungen erfolgt über technische und fachliche Fragen zur Datenstruktur. Fachliches Verständnis vorausgesetzt, ist es möglich, Fragen zu definieren, die einen kritischen Fehlerzustand erkennen. Beispiele für solche Fragen sind:

- Gibt es negative Umsätze, die nicht durch eine Gutschrift entstanden sind?
- Gibt es Duplikate innerhalb der Stammdaten?
- Entspricht der Inhalt eines Attributs dessen Beschreibung?

Datenprüfungen wie diese werden in den ETL-Prozessen zwischen der Staging Area und dem Business Data Vault implementiert. Der ETL-Prozess des Raw Data Vault umfasst Qualitätsprüfungen, die die Voraussetzung für eine nachfolgende Implementierung der Geschäftslogik bilden (vgl. [Jordan und Schnider 2011, S. 44-54]).

Die Modellierung des Raw Data Vault erfolgt durch die Verwendung der Data Vault Modellierungsmethode. Ein Ausschnitt des Ereignisses ,Rohstoffe wurden bestellt‘ wird in Abbildung 30 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 30: Raw Data Vault für das Ereignis ,Rohstoffe wurden bestellť

Das Datenmodell umfasst die relationale Beschreibung des Ereignisses ,Rohstoffe wurden bestellt‘. Der Hub Rohstoffe wurde dazu mit dem Hub Bestellung verknüpft. Diese Verbindung wird über den Link RDV_Rohstoffe_Bestellung realisiert. Die Satellites Material und Menge referenzieren den Hub Rohstoffe. Die Satellites Auftrag und Bestellart beschreiben den Hub Bestellung. Der Hub Bestellung ist über den Link RDV_Bestellung_Anschrift mit dem Hub Anschrift verknüpft. Die Standortbeschreibung erfolgt über den Hub Anschrift. Die Beschreibung des Ereignisses geschieht über die vorhandenen Satellites. Optional können noch nicht modellierte Informationen durch zusätzliche Satellites ergänzt werden. Dazu wird ein neuer Satellite erstellt, mit den zu speichernden Attributen gefüllt und anschließend mithilfe der H_xxx_ID mit dem entsprechenden Hub verknüpft. Der neu erstellte Satellite referenziert nun den Hub. Ab diesem Zeitpunkt ist es möglich, die Daten über das Business Data Vault in entsprechende Data Marts zu laden, sodass neu angefertigte Abfragen und Analysen, die im Information Layer erstellt wurden, auf die hinzugefügten Daten zugreifen können.

Bei der Aktualisierung des Raw Data Vault wird die Gültigkeit einzelner Attribute geprüft. Ändert sich die Ausprägung eines Attributs, so muss für dieses Attribut ein Gültigkeitsintervall ermittelt werden. Angenommen, die nicht metrische Maßeinheit Unze wird neu definiert und soll ab dem ersten Januar 2018 35 Gramm anstatt der bisher gültigen 28,35 Gramm umfassen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 31: Historisierung der Maßeinheit Unze

Abbildung 31 visualisiert den oben angenommenen Fall. Zu sehen ist die historisierte und ab dem ersten Januar gültige Definition der Maßeinheit Unze. Dieses Vorgehen lässt sich auf alle Attribute übertragen und entspricht den Slowly Changing Dimensions Typ 2. Slowly Changing Dimensions sind Methoden, um Änderungen in Satellite-Tabellen zu erfassen und diese historisiert zu dokumentieren.

Eine Datenstruktur, die durch das Raw Data Vault beschrieben wird, enthält elementare Geschäftsinformationen. Diese sind vollständig strukturiert und logisch verknüpft, sodass Abhängigkeiten, Fremdschlüsselbeziehungen und Einschränkungen dargestellt werden können. Die erstellte Struktur sichert die definierte Datenqualität und ist erweiterbar. Kennzahlen und alle durch eine Berechnung oder Verarbeitung der Datensätze entstehenden Informationen sind nicht Teil des Raw Data Vault. Informationen, die aus Berechnungen abgeleitet werden, sind im Business Data Vault implementiert. Die Verschiebung der Geschäftslogik in eine separierte Teillösung erleichtert die Definition von Kennzahlensystemen und entspricht dem Prinzip des Separation of concerns.

3.6 Business Data Vault

Innerhalb dieses Referenzmodells sind Elemente des Business Data Vault geschäftsorientierte Änderungen und Berechnungen der aus dem Raw Data Vault integrierten Daten. Das Business Data Vault basiert auf den Strukturen des Raw Data Vault und ergänzt dieses durch die Berechnung von Kennzahlen. Die Datenstruktur wird nicht mehrfach vorgehalten, sondern wird durch eine logische Ebene erweitert. Beide Strukturen, sowohl Raw als auch Business Data Vault, werden gemeinsam verwaltet und angepasst (vgl. [Hultgren 2012, S. 349-378]).

Im Business Data Vault werden die durch das Raw Data Vault strukturierten Daten bis zu drei Transformationsschritten unterzogen. Der erste Transformationsschritt ist die Datenbereinigung, währenddessen Plausibilitätsprüfungen durchgeführt werden. Ist das Resultat dieser Prüfung negativ, werden die geprüften Datensätze angepasst. Im zweiten Schritt werden die Datensätze gemäß definierter Zielvorgaben integriert. Diese Transformation beeinflusst Devisenkurse, Maßeinheiten, Namenskonventionen und Datenformate. Solche Anpassungen sind notwendig, um im dritten Schritt erforderliche Kennzahlen fachgemäß berechnen zu können. Die ermittelten Kennzahlen beschreiben eine messbare betriebswirtschaftliche Größe, deren Interpretation durch den Anwender erfolgt. Eine aktive Unterstützung bei der Interpretation und der anschließenden Entscheidungsfindung ist nicht Teil des Referenzmodells.

Um die im Business Data Vault berechneten Kennzahlen einem Nutzen zuzuführen, werden sie von fachlich definierten Data Marts integriert. Dort werden diese Datensätze gemäß dem Analysezweck angepasst und im letzten Schritt dem Information Layer und damit auch dem Anwender zur Verfügung gestellt.

Abbildung 32 zeigt den gesamten Informationsfluss ab der Integration der Datensätze aus der Staging Area in das Raw Data Vault bis hin zur Interpretation des Anwenders im Information Layer.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 32: Business Data Vault im Kontext des Datenflusses

Die Nachvollziehbarkeit der geladenen Daten aus den Quellsystemen endet in der Integration der Datenladung im Business Data Vault. Dies ist auch der Aggregation einzelner Teilmengen geschuldet. Raw und Business Data Vault sind dauerhaft persistent. Die Geschäftslogik wird im Business Data Vault implementiert und in den Data Marts individuell auf den Anwendungszweck angepasst. Im Information Layer können Nutzer des Systems diese Informationen dann für Analysen und Auswertungen abfragen (vgl. [Hultgren 2012, S. 211-217]).

Das Business Data Vault bietet in dieser Struktur die Möglichkeit, Geschäftslogiken persistent zu implementieren. Transformationsprozesse im Business Data Vault sind nachvollziehbar historisiert, was die Historisierung der Berechnungsfaktoren und deren Ausprägung inkludiert. Die Geschäftslogik wird durch Berechnungen bestimmt. Transparenz zur Entstehung der Resultate während und nach der Berechnung wird durch die Dokumentation erforderlicher Teilschritte erlangt.

Abbildung 33 visualisiert die Berechnung der Lieferkosten für das Ereignis ,Rohstoffe wurden bestellt‘. Diese basiert auf den Wechselkursen, die in Abbildung 34 dargestellt sind. Die Notwendigkeit dieser Struktur resultiert aus einer Harmonisierung der Devisenkurse im Quellsystem.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 33: Berechnung der Lieferkosten in der entsprechenden Landeswährung

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 34: Historisierte Wechselkurse der Landeswährungen

Die oben dargestellte Historisierung der Devisenkurse umfasst die Währungen US Dollar, Schweizer Franken und Ägyptisches Pfund. Anhand derer ist es möglich, die Lieferkosten für die Bestellungen der einzelnen Unternehmensbereiche in Brügge, Zürich und Kairo zu berechnen. Die Implementierung dieser Geschäftslogik ermöglicht Analysen und Auswertungen der einzelnen Geschäftsbereiche. Einen Anwendungsfall stellt die Analyse der Lieferhäufigkeit eines einzelnen Lieferanten und der damit verbundenen Gesamtkosten dar. Diese Informationen dienen als Grundlage für Maßnahmen der Kostenoptimierung. Beispiele dafür sind die Einführung eines zentralen Bestellwesens, Mindestbestellmengen, Lieferantenkonzentration, Rahmenverträge oder eine Rückwärtsintegration. Diese Informationen werden dazu als Satellite definiert und in das Data Vault integriert.

3.6.1 Datenbereinigung

Maßnahmen zur Datenbereinigung innerhalb des Business Data Vault sollen zur Sicherung der Datenqualität beitragen und umfassen die Vergabe von Standardwerten sowie die Erstellung von Plausibilitätsprüfungen (vgl. [Schnider et al. 2016, S. 98]).

Ursache für die Anpassungen der Datenbestände sind nicht erfüllte Voraussetzungen bezüglich der Kennzahlensysteme. Um Fehlerzustände in der Berechnung von Kennzahlen zu reduzieren, muss die Vergabe und Verwendung falscher Dateiformate verhindert werden.

Das Ziel des vollständigen Business Data Vault wird durch die Erstellung und Pflege einer für Kennzahlen erforderlichen Attributliste erreicht. Eine solche Aufstellung umfasst die zu ermittelnden Kennzahlen und deren Bestandteile. Erstellte BEAM-Tabellen beinhalten bereits viele dieser Attribute, weshalb sie als Basis verwendet werden. Eine flächendeckende Plausibilitätsprüfung beschreibt Attribute, von denen mindestens ein Tupel nicht den Prüfkriterien entspricht. Eine zu definierende Prozedur bestimmt dann den Anteil der Tupel, die nicht den Prüfkriterien entsprechen. Liegt dieser Anteil unter einem zu definierenden Prozentsatz, ist die Vergabe eines Standardwerts eine mögliche Korrekturmaßnahme. Gemäß der Bedeutung des Attributs kann dieser Prozentwert für jedes Attribut individuell vergeben werden. Die Vergabe eines Standardwerts für einzelne Tupel ist für alle Kennzahlen, deren Definition dieses Vorgehen nicht explizit ausschließt, ein praktikables Vorgehen. Kennzahlen, die z. B. den Umsatz des Geschäftsjahres beschreiben, bilden die Grundlage für weitreichende Management- und Strategieentscheidungen und müssen daher exakt bestimmt werden. Liegt der prozentuale Anteil der nicht den Prüfkriterien entsprechenden Tupel über dem definierten Wert, muss die Fehlerquelle ermittelt werden. Ist die Ursache gefunden, ist der entsprechende Fehlerzustand behoben und sind die erfolgten Änderungen dokumentiert, kann mit einem partiellen Nachladen der betroffenen Datensätze begonnen werden.

Angenommen, der in Abbildung 34 dargestellte Kurs des Schweizer Franken wird aufgrund einer defekten Schnittstelle nicht aktualisiert. Die Ausprägung des Wert Kurs ist am 11.08.2017 nicht existent und daher mit einem NULL-Wert besetzt.

Eine vorübergehende Definition des Attributs Kurs ist notwendig, um die Werte des Kennzahlensystems zu berechnen. Zur Bestimmung der fehlenden Ausprägung gibt es mehrere Möglichkeiten, den fehlenden Wert zu beschreiben, etwa die Auswahl des Mittelwerts, Median oder die Ausprägung des Vortages. Eine Selektion der Standardwerte ist abhängig von den Unternehmenszielen und den Auswirkungen einzelner Anpassungen auf die Wertschöpfung des Unternehmens.

3.6.2 Kennzahlensysteme

Kennzahlen bilden zentrale Funktionen eines Business-Intelligence-Systems ab. In diesem Abschnitt werden die Begriffe Kennzahl und abgeleitete Kennzahl definiert. Anwendung finden spezifische Kennzahlen-Definitionen schon in der Anforderungsanalyse, denn dort beschreiben Stakeholder den Einsatz von Kennzahlen in ihrem Funktionsbereich (vgl. [Krause und Arora 2010, S. 1-11]).

Kennzahlen, unabhängig davon, ob sie eine Basis oder eine abgeleitete Kennzahl darstellen, beschreiben eine oder mehrere spezifische Eigenschaften innerhalb eines Anwendungsfalls. So können Kennzahlen ereignis- oder prozessbezogen sein. Alle Kennzahlen, die in einem produktiven Data Warehouse System Anwendung finden, sind einzigartig. Diese Eigenschaft ist von zentraler Bedeutung und sollte im gesamten Data Warehouse System eingehalten werden. Die Integrität der Kennzahl, unabhängig vom Kontext und den Rahmenbedingungen, worin sie verwendet wird, basiert auf dieser Eigenschaft.

Die Additivität einer Kennzahl, also die Möglichkeit, sie über mehrere Dimensionen hinweg zu nutzen, lässt sich in eine der drei Kategorien verorten:

1. Gänzlich additive Kennzahlen

Sie können ohne Einschränkung über Dimensionsgrenzen verwendet werden.

2. Semiadditive Kennzahlen

Sie können über bestimmte Dimensionsgrenzen verwendet werden.

Implementierte Geschäftslogiken und das Rollenkonzept grenzen die Reichweite und somit auch die Verwendbarkeit ein.

3. Nicht additive Kennzahlen

Diese Kennzahlen können grundsätzlich nicht summiert werden.

Für die Implementierung des Business Data Vault ist die Additivität einer Kennzahl von fundamentaler Bedeutung. Die Möglichkeit, Kennzahlen über mehrere Dimensionen hinweg zu verwenden, setzt die Einzigartigkeit der Kennzahl voraus. Eine konsistente Verwendung vorhandener Kennzahlen ist auch für den Single Point of Truth des Konzepts existenziell. Sollten Kennzahlen die gleiche Bezeichnung tragen, aber je nach Anwendungsfall unterschiedlich definiert werden, ist das Prinzip des Single Point of Truth verletzt.

Der Funktionsbereich einer Kennzahl, deren Beschreibung und die zur Berechnung notwendigen Bestandteile werden in einem Kennzahlensystem einheitlich erfasst und gepflegt. Kennzahlen können von Stakeholdern definiert oder aus den von den Stakeholdern erstellten BEAM-Tabellen entnommen werden. Innerhalb des Business Data Vault sind Kennzahlen durch die Verwendung von Prä- und Suffixen eindeutig definiert.

Kennzahlen werden durch granulare Messwerte beschrieben. Die Länge, Breite und Höhe eines Produkts sind Basis-Kennzahlen. Sie sind atomar und lassen sich nicht durch andere Kennzahlen errechnen. Abgeleitete Kennzahlen werden durch Basis-Kennzahlen berechnet. Das Volumen eines Produkts lässt sich durch die Länge, Breite und Höhe berechnen und sollte nicht als Basis-Kennzahl definiert werden. Die Berechnung einer abgeleiteten Kennzahl kann mehrere Iterationen durchlaufen. Um Nutzern des Systems den Zugang zu Auswertungen und Analysen zu erleichtern, werden innerhalb der Data Marts die abgeleiteten Kennzahlen durch vordefinierte Abfragen auf das Business Data Vault ermöglicht. Diese Struktur gibt dem Nutzer die Möglichkeit, Analysen und Auswertungen selbstständig, gemäß seiner Anforderungen, aufzubauen. Die Berechnung abgeleiteter Kennzahlen erfolgt parallel zur Anfrage des Nutzers. Berechnete abgeleitete Kennzahlen entsprechen den aktuellsten Datenbeständen des Business Data Vault.

3.7 Data Mart

Für jedes in der Anforderungsanalyse erfasste Ereignis gibt es einen Data Mart. Dieser Data Mart enthält spezifische Informationen, die den Anwendungsfall betreffen. Ein Nutzer des Data-Warehouse-Systems kann auf Basis dieser Informationen Analysen, Auswertungen und Informationsmodelle erstellen.

Die Datenbestände in den Data Marts sind granular und historisiert. Datensätze werden themenorientiert in Dimensionen abgelegt. Theoretisch kann ein Data Mart aus einer isolierten Dimension bestehen. Eine allgemeingültige Obergrenze oder einen Mittelwert für die Anzahl der Dimensionen gibt es nicht. Die Anzahl der Dimensionen je Data Mart bestimmt jedoch die Abfragekomplexität und diese hat einen direkten Einfluss auf die Antwortzeiten des Data-Warehouse-Systems. Eine inhaltliche Beschränkung des Data Marts auf einen Anwendungsfall führt zu einer Separation der Datensätze. Werden die Data Marts noch physisch oder virtuell auf mehreren Instanzen abgelegt, führt diese Lastverteilung zu einer Performancesteigerung bei Anfragen (vgl. [Hultgren 2012, S. 136-143]).

Das Business Data Vault bildet indes die Datengrundlage für alle Data Marts. Innerhalb der einzelnen Data Marts gibt es keine Redundanzen. Beschreibt ein Attribut mehrere Ereignisse, wird dieses in alle davon betroffenen Data Marts aus dem Business Data Vault geladen. Die Abhängigkeit der Data Marts von den im Business Data Vault enthaltenen Datenbeständen ist von Bedeutung für die Informationssicherheit. Eine alternative Datenladung aus der Staging Area ist innerhalb dieses Referenzmodells nicht zulässig. Diese Abhängigkeit sichert den Einsatz des Berechtigungskonzepts durch alle Ebenen der Datenverarbeitung.

Anfragen des Information Layers werden auf dem betroffenen Data Marts ausgeführt. Ausgewählte Data Marts werden nicht persistent vorgehalten. Andere werden persistiert und bei Bedarf aktualisiert. Data Marts, die Managementinformationen enthalten, werden zyklisch aktualisiert, um Daten in Echtzeit zur Verfügung stellen zu können. Die Bestimmung, welcher Data Mart wie und wann beladen und vorgehalten werden muss, ist in Abhängigkeit des Anwendungskontextes zu entscheiden.

Der Data Mart für das Ereignis ,Rohstoffe wurden bestellt‘ ist in Abbildung 35 dargestellt. Dieser wird von verschiedenen Funktionsbereichen verwendet. Die enthaltenen Attribute sind in allen Themenbereichen gleich. Eine Selektion der angezeigten Attribute gemäß der Berechtigung des Nutzers findet im Information Layer statt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 35: Data Mart für das Ereignis ,Rohstoffe wurden bestellť

Der in Abbildung 35 dargestellte Data Mart wurde aus dem Business Data Vault geladen. Innerhalb des ETL-Prozesses wurden dazu die Hubs Rohstoffe, Bestellung und Anschrift verknüpft, was alle zugehörigen Satellites beinhaltet. Das Datenmodell kann in der dritten Normalform relational modelliert werden. Der hier dargestellte Data Mart fasst die Entitäten Besteller und Rohstoff­Bestellung in jeweils einer Tabelle zusammen. Diese Modellierung entspricht der ersten Normalform und erleichtert den Informationszugriff im Information Layer.

Erstellte Data Marts entsprechen stets den in den BEAM-Tabellen erfassten Ereignissen. Das Information Layer greift zwecks der Erstellung einer Auswertung auf die verknüpften Data Marts zu. Diese im Data Mart vorhandenen Datenbestände sind von hoher Qualität, feingranular und ermöglichen die Erstellung individueller Informationsmodelle, sodass eine performante Abfrage der Daten im Information Layer gewährleistet ist.

3.8 Information Layer

Das Information Layer bildet den operativen Arbeitsbereich für Anwender von Business-Intelligence-Anwendungen. Alle eingesetzten Analyse- und Auswertungssysteme werden im Information Layer zusammengefasst. Ziel dieser Ebene ist die weitgehend selbstständige Erstellung von Analysen, Auswertungen und Informationsmodellen durch den Anwender.

Die dazu verwalteten Business-Intelligence-Anwendungen ermöglichen bei Bedarf eine unterstützte Erstellung von komplexen Anfragen. Dies erfolgt durch Mitarbeiter der Data-Warehouse-Einheit. In der englischen Sprache wird dieser Ansatz ,Managed self service Business Intelligence System‘ genannt. Hintergrund ist die Verlagerung der Analysetätigkeiten in Funktions- und Fachbereiche. Die entstehende Verschiebung der Arbeitsaufwände entlastet bestehende Berichtswege und führt zu mehr Transparenz bei der Erstellung von Informationsmodellen.

Diese Arbeitsverschiebung, hin zu den Funktionsbereichen und weg von den IT-Abteilungen, führt zu einem besseren Verständnis der Datensätze auf der Anwenderseite. Die kooperative Arbeitsweise zwischen den Fachbereichen und der IT-Abteilung stärkt vorhandene Schnittstellen und führt zu einer effektiveren Kommunikation. Die Beschreibung des Information Layers beinhaltet auch den Zweck der darstellbaren Information. Handlungsempfehlungen zum korrekten Umgang mit personenbezogenen oder internen Daten sind ebenfalls in dieser Beschreibung enthalten.

Abbildung 36 zeigt eine Instrumententafel (engl. Dashboard) für das Ereignis ,Rohstoffe wurden bestellt‘. Diese Darstellung visualisiert, wie ein grafisches Aufbereiten der Datensätze realisiert werden kann. Enthaltene Dimensionen ermöglichen die Darstellung von Bestellmengen je Standort, die Abnahmemenge, die entstandenen Kosten sowie eine anteilige Verteilung aller Rohstoffe. Anwender können die aufbereiteten Daten als Grundlage für Entscheidungen bezüglich des Ereignisses ,Rohstoffe wurden bestellt‘ verwenden. Mittelfristig sollte es Anwendern möglich sein, Anwendungsfälle gemäß den Ereignissen selbst zu definieren und mithilfe der Data-Warehouse-Einheit in Form eines Informationsmodells zu implementieren.

Abbildung in dieser Leseprobe nicht enthalten

Das Entwicklungsziel liegt in einer Systemlandschaft, die allen Nutzern die Aussicht und Fähigkeiten einräumt, vorhandene Datensätze auszuwerten. Resultierende Informationsgewinne sind allgemein verständlich, beschreiben eine vorhandene Problemstellung und wurden unabhängig von bestehenden Berichtswegen erstellt.

3.8.1 Rechtliche Hintergründe in Bezug auf das Datenschutz- und IT-Sicherheitsgesetz

Bei der Entwicklung datenverarbeitender Informationssysteme sind weitreichende Vorschriften und Rechtsnormen einzuhalten. Das Aufgabenfeld umfasst den Informationszugriff, aber auch die Pseudonymisierung personenbezogener Daten. Das Bundesdatenschutzgesetz schreibt dazu folgende Maßnahmen vor:

1. Eine Erhebung, Verarbeitung und Nutzung von personenbezogenen Daten ist unzulässig. Zulässig ist eine Datenverarbeitung nur dann, wenn die betroffene Person ausdrücklich zustimmt. Diese Zustimmung wird innerhalb einer Geschäftsbeziehung häufig über die allgemeinen Geschäftsbedingungen abgedeckt.

2. Bei der Konzeption und Entwicklung datenverarbeitender Systeme sollten so wenig personenbezogene Daten wie möglich erfasst und verarbeitet werden. Ist es dennoch nötig, personenbezogene Daten zu erfassen und zu verarbeiten, so müssen diese anonymisiert oder durch die Vergabe synthetischer Ausprägungen pseudonymisiert werden. Dieser Ansatz bildet eine Teilmenge der definitorischen Beschreibung des Bundesdatenschutzgesetzes, nämlich den der Datensparsamkeit und -Vermeidung.

(vgl. [Gola et al. 2015, S. 109-128]).

Personenbezogene Daten beschreiben die persönlichen oder sachlichen Verhältnisse einer natürlichen Person. Der Schutz von Daten, die eine eindeutige Bestimmung einer natürlichen Person zulassen, ist ebenfalls im Bundesdatenschutzgesetz enthalten.

Von der Erfassung, Verarbeitung und Speicherung besonders geschützter Daten innerhalb des Data Warehouse ist grundsätzlich abzusehen, denn personenbezogene Informationen zur ethnischen Herkunft, der politischen Meinung oder religiösen Überzeugung unterliegen strikten Regeln. Dabei rechtfertigt der erzielte Mehrwert nur selten die entstandenen Mehrkosten einer solchen Maßnahme. Zur Gewährung der Betroffenenrechte, die jedem eingeräumt werden, dessen Daten gespeichert oder verarbeitet werden, muss es außerdem jederzeit möglich sein, eine Auskunft, Korrektur, Sperrung oder Löschung von personenbezogener Daten zu veranlassen (vgl. [Laue et al. 2016, S. 83-110]).

Das am 25. Juli 2015 in Kraft getretene IT-Sicherheitsgesetz beschreibt Maßnahmen, die bei sicherheitskritischen Vorfällen mit sensiblen und personenbezogenen Datensätzen durchzuführen sind. Ziel ist die Erhöhung der Sicherheit informationstechnischer Systeme. Betreiber besonders gefährdeter Infrastrukturen, wie Energie, Gesundheit, Telekommunikation und Wasser, werden verpflichtet, ihre datenverarbeitenden Systeme und Netze gemäß dieser Richtlinie zu schützen. Unternehmen sollen dazu Strategien und Vorgehensmodelle entwickeln, die der Prävention von IT-Sicherheitsvorfällen dienen (vgl. [Mucksch 1999, S. 101-124]). Das Aktivitätsmonitoring ist eine Maßnahme, die zur Erkennung von Anomalien im Nutzerverhalten beiträgt. Eine Beschreibung des Aktivitätsmonitoring innerhalb des Data-Warehouse-Systems folgt im nächsten Abschnitt.

3.8.2 Aktivitätsmonitoring

Die Erfassung von Nutzerabfragen und -Verhalten innerhalb des entwickelten Data-Warehouse-Systems bedarf eines Aktivitätsmonitoring. Dieses beinhaltet die Erfassung und Speicherung von Datenzugriffen aller Nutzer. Änderungen der Datenstruktur durch Funktionen und ETL-Prozesse werden ebenfalls in einer Logdatei gesichert.

Ziel ist es, den Urheber einer Änderung oder den Nutzer eines Datenzugriffs eindeutig ermitteln zu können (vgl. [Schneede 2016]). Die Prüfung der Zugriffsberechtigung erfolgt vor dem Informationszugriff. Der Aktivitätsmonitor durchsucht die Logdatei gemäß definierter Filterkriterien. Verletzt ein Eintrag die Filterkriterien, wird er separiert und an ein zuständiges Gremium einer Expertengruppe weitergeleitet, das sicherheitskritische Ereignisse untersucht und Maßnahmen zur Behebung einleitet. Abbildung 37 zeigt den Prozess des Aktivitätsmonitorings.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 37: Ablauf und Prozess des Aktivitätsmonitorings

Das Aktivitätsmonitoring kann über ein unternehmensweites Information Security Management System (ISMS) abgebildet werden. Sollte diese Option nicht verfügbar sein, ist ein Aktivitätsmonitoring für das Data Warehouse System zu forcieren.

Der Betrieb eines Aktivitätsmonitors ermöglicht die langfristige Steuerung und Kontrolle der Informationssicherheit innerhalb des Data-Warehouse-Systems. In Verbindung mit einem unternehmensweiten ISMS ist eine Zertifizierung nach dem ISO 27001 möglich. Im Kontext der Mandantenfähigkeit ist eine Zertifizierung sogar zu empfehlen, denn ein Sicherheitsvorfall, der personenbezogene Kundendaten betrifft, kann innerhalb der Europäischen Union zu hohen Bußgeldern, Strafen und Schadensersatzforderungen führen (vgl. [Kersten et al. 2016, S. 45-108]).

3.9 Mehrwert des Referenzmodells

Die Entwicklung eines Enterprise-Data-Warehouse-Systems gemäß diesem Referenzmodell soll die Datenbasis für ein Managed self service Business Intelligence System bieten. Das Prädikat ,Managed‘ (dt. verwalten) ist für die Implementierung und den Betrieb des Data-Warehouse-Systems von zentraler Bedeutung. Die hier beschriebene Engpasskonzentration in der Neuentwicklung eines Data-Warehouse-Systems kann einen Flaschenhals bei den betroffenen IT-Abteilungen weitgehend auflösen. Anforderungen von Fach- und Funktionsbereichen, die sich im Projektverlauf verändern, können stets berücksichtigt werden. Der intensive Austausch innerhalb des Projektverlaufs führt auch auf Seiten der Anwender zu einem umfassenden Verständnis der Entwicklung, sodass der hier dargestellte Ansatz über die reine Datenmodellierung hinausgeht. Vielmehr werden geeignete Vorgehensmodelle und architekturelle Ansätze beschrieben und bewertet. Die Verwendung von Data Vault im Core dieses Referenzmodells sichert sowohl flexible als auch stabile Business-Intelligence-Anwendungen. Eine single version of truth ist dabei trotz der geforderten Agilität dauerhaft gegeben. Die im Verlauf der Entwicklung beschriebenen Vorgehensweisen zur Klassifikation der Informationen und zur Authentisierung des Informationszugriffs bewahren die Informationssicherheit der verwalteten Datensätze.

Die Summe der beschriebenen Maßnahmen ermöglicht die Konstruktion eines langfristig beständigen Datenbestands für Auswertungen, Analysen und Informationsmodelle.

4 Zusammenfassung und Ausblick

Der Webcomic ,Geeks and the repetitive tasks‘ beschreibt den langfristigen Nutzen von Maßnahmen zur Automation von Prozessen. In Abbildung 38 werden der Webcomic und sein Inhalt dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 38: Geeks and the repetitive tasks

Im Rahmen der Entwicklung eines Data-Warehouse-Systems könnte mit dieser Darstellung die automatisierte Erstellung von ETL-Prozessen und Datenmodellen beschrieben werden. Dabei ist zu beachten, dass sowohl die Erstellung von ETL-Prozessen als auch die Aufwände zur Implementierung der Datenmodelle zeit- und kostenintensiv sind. Beide lassen sich weitgehend automatisieren und sind daher Beispiele für mögliche Maßnahmen zur Automatisierung innerhalb der Data-Warehouse-Entwicklung.

Die Suche nach ,Geeks and the repetitive tasks‘ in der Suchmaschine Google ergibt 19.700 Treffer (Stand August 2017). Diese Einträge umfassen positive und negative Kritiken, einige Interpretationen und emotional vorgetragene Erfahrungsberichte von gescheiterten oder erfolgreich automatisierten Prozessen.

Auch wenn die meisten dieser Einträge bereits fünf Jahre alt sind, stellt sich die Frage:

Ist die Idee hinter dem Comic heute nicht aktueller denn je?

oder

Ist die Idee angesichts sich ständig ändernder Anforderungen überholt?

Die Findung einer allgemeingültigen Antwort, die in allen Bereichen und Anwendungsfällen akzeptiert wird, bleibt diese Arbeit schuldig. Die Auswirkungen der Fragestellungen auf die Neuentwicklung von Data-Warehouse-Systemen ist allerdings ein Teil dieser Arbeit und wird in Form dieser Zusammenfassung und dieses Ausblicks ausgeführt.

Die Fähigkeit, Anpassungen zeitnah zu berücksichtigen, beginnt in der Entwicklung, ist aber auch im Betrieb des Data Warehouse gefragt. Eine langfristige Zeitersparnis durch die Automation von Teilprozessen führt dazu, dass die vorhandenen Kapazitäten genutzt werden können, um die Funktionen des Informationssystems weiterzuentwickeln. Die dazu in Kapitel 3 beschriebenen Maßnahmen erfüllen die betriebswirtschaftlichen Anforderungen der Anwender. Um den Aufwand, vor allem innerhalb des Betriebs, zu reduzieren, wurde Data Vault für die Modellierung des Cores verwendet. Die Vorbereitungen zur Implementierung des Cores mit Data Vault sind aufwendig. Verglichen mit einem dimensionalen oder normalisierten Datenmodell führt die Implementierung mit Data Vault zu mehr Tabellen, höheren Aufwänden bei der ETL-Entwicklung und einer längeren Entwicklungsdauer. Das entstehende Data Vault vereint allerdings drei zentrale Eigenschaften, die einen langfristigen Betrieb des Data Warehouse ermöglichen:

- Erweiterbarkeit

Das Data-Warehouse-System ist durch seine Architektur nicht beschränkt. So entspricht die verfügbare Kapazität stets der verwalteten Datenmenge. Den Begriff Big Data in diesem Kontext zu verwenden, ist allerdings falsch, denn Big Data ist die Summe mehrerer Technologien und Data Warehouse beschreibt verschiedene Architekturen zur Datenhaltung im betriebswirtschaftlichen, wissenschaftlichen und technologischen Kontext.

- Produktivität

Das entstehende Data Warehouse bildet die Grundlage für ein Managed self service Business Intelligence System. Dieses System bietet Anwendern neue Möglichkeiten bei der Erstellung von Analysen, Auswertungen und Informationsmodellen, woraus eine Steigerung der Effektivität resultiert.

- Agilität

Erweiterungen und Anpassungen der Datenstruktur können mit einem geringen Aufwand umgesetzt werden. Diese Eigenschaft gewinnt im Rahmen der digitalen Transformation auch zukünftig an Bedeutung, sodass in der Konzeptionierung und Neuentwicklung datenverarbeitender Systeme Flexibilität und Variabilität als zentrales Entwicklungsziel definiert werden sollten.

Die Summe dieser Eigenschaften rechtfertigt die anfänglich erhöhte Komplexität innerhalb der Entwicklung des Data-Warehouse-Systems. Außerdem sind die Erstellung und der Betrieb eines Enterprise-Data-Warehouse Teil jeder von Erfolg geprägten IT-Strategie. Erfolgreiche Strategie bedeutet in diesem Zusammenhang eine Anpassung der IT-Infrastruktur, um Informationen und Daten unternehmensweit effektiv verteilen zu können. Die in Abbildung 39 dargestellte Informationsverteilung ist als Ziel dieses Referenzmodells anzusehen.

Ste t die Datensätze für das

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 39: Die Rolle des Anwenders in der Informationsverteilung

Die abgebildete Struktur ermöglicht Nutzern des Systems den direkten Zugriff auf Informationsmodelle und Analysen ihres Fach- und Funktionsbereichs. Das darin enthaltene Wissen, über neue Potenziale und Technologien, macht es Mitarbeitern möglich, digitale Geschäftsmodelle und deren Potenzial frühzeitig zu erkennen und so neue Produkte und Dienstleistungen für den Kunden zu entwickeln. Der Umfang und die Art von Analysen und Informationsmodellen können in Abstimmung mit der Data-Warehouse-Einheit angepasst werden, sodass die verfügbaren Informationen stets den Anforderungen des Fachbereichs entsprechen. Das Resultat ist ein zukunftsorientiertes Managed self service Business Intelligence System.

Literaturverzeichnis

Bauer, Andreas; Günzel, Holger (2013):

Data-Warehouse-Systeme. Architektur, Entwicklung, Anwendung.

Heidelberg: dpunkt.verlag.

Becker, Jörg; Knackstedt, Ralf (2003):

Konstruktion und Anwendung fachkonzeptioneller Referenzmodelle im Data Warehousing.

In: Wolfgang Uhr, Werner Esswein und Eric Schoop (Hg.): Wirtschaftsinformatik 2003. Heidelberg: Physica-Verl. (Wirtschaftsinformatik 2003, 02), S. 415-434.

Bishop, Matt (2008):

Computer security. Art and science.

10. print. Boston: Addison-Wesley.

Chen, Peter Pin-Shan (1976):

The entity-relationship model-toward a unified view of data.

In: ACM Trans. Database Syst. 1 (1), S. 9-36. DOI: 10.1145/320434.320440.

Cole, Tim (2015):

Digitale Transformation.

Warum die deutsche Wirtschaft gerade die digitale Zukunft verschläft und was jetzt getan werden muss! ; [Impulse für den Mittelstand].

München: Vahlen.

Corr, Lawrence; Stagnitto, Jim (2011):

Agile data warehouse design. Collaborative dimensional modeling, from whiteboard to star schema.

1. ed. Leeds: DecisionOne Press.

Devlin, B. A.; Murphy, P. T. (1988):

An architecture for a business and information system.

In: IBM Syst. J. 27 (1), S. 60-80. DOI: 10.1147/sj.271.0060.

Eckert, Claudia (2006):

IT-Sicherheit. Konzepte, Verfahren, Protokolle.

4., überarb. Aufl. München: Oldenbourg.

Fettke, Peter (Hg.) (2007):

Reference modeling for business systems analysis.

Hershey Pa. u.a.: Idea Group Publ.

Fettke, Peter; Loos, Peter (2004):

Referenzmodellierungsforschung.

In: Wirtschaftsinf 46 (5), S. 331-340. DOI: 10.1007/BF03250947.

Forrester Research, Inc (2013):

Integrated Thinking: The Answer To Enterprise IT’s Perpetual Struggle.

Forrester Research, Inc. Online verfügbar unter http://www.effectiveui.com/landing- pages/downloads/publications/EffectiveUI_Study_Integrated_Thinking.pdf.

Gartner, Inc. (2005):

More Than 50 Percent of Data Warehouse Projects Will Have Limited Acceptance or Will Be Failures Through 2007.

Hg. v. Gartner Inc. Gartner Inc.

Online verfügbar unter http://www.gartner.com/newsroom/id/492112.

Gola, Peter; Klug, Christoph; Körffer, Barbara (2015):

Bundesdatenschutzgesetz.

BDSG ; Kommentar. 12., überarb. und erg. Aufl.

München: Beck (Beck-online).

Hastie, Shane; Wojewoda, Stéphane (2015):

Standish Group 2015 Chaos Report.

Standish Group.

Online verfügbar unter https://www.infoq.com/articles/standish-chaos-2015.

Hultgren, Hans (2012):

Modeling the agile data warehouse with data vault.

Inmon, W. H. (2002):

Building the Data Warehouse.

3rd ed. Hoboken: John Wiley & Sons Inc.

Jordan, Claus; Schnider, Dani (2011):

Data Warehousing mit Oracle. Business Intelligence in der Praxis.

München: Hanser.

Kersten, Heinrich; Klett, Gerhard; Reuter, Jürgen (2016):

IT-Sicherheitsmanagement nach der neuen ISO 27001. ISMS, Risiken, Kennziffern, Controls.

Kimball, Ralph; Ross, Margy (2013):

The Data Warehouse Toolkit. The Definitive Guide to Dimensional Modeling.

3. Aufl. s.l.: Wiley.

Krause, H. U.; Arora, D. (2010):

Controlling-Kennzahlen - Key Performance Indicators.

Zweisprachiges Handbuch Deutsch/Englisch - Bi-lingual Compendium German/English: de Gruyter.

Kriha, Walter; Schmitz, Roland (2009):

Sichere Systeme. Konzepte, Architekturen und Frameworks.

Berlin: Springer (Xpert.press).

Laue, Philip; Nink, Judith; Kremer, Sascha (2016):

Das neue Datenschutzrecht in der betrieblichen Praxis.

Baden-Baden: Nomos (NomosPraxis).

Linstedt, Dan; Olschimke, Michael (2015):

Building a Scalable Data Warehouse with Data Vault 2.0. Implementation Guide for Microsoft SQL Server 2014.

1. Aufl. s.l.: Elsevier Reference Monographs.

Maxwell, Brent (2016):

Agile Data Warehousing.

Hg. v. THE ICONIC Engineering. THE ICONIC Engineering.

Online verfügbar unter https://theiconic.engineering/agile-data-warehousing-the-luture-is-now- f488ffddfae.

Mertens, Peter (2013):

Operative Systeme in der Industrie.

18., überarb. und aktualisierte Aufl.

Wiesbaden: Springer Gabler (Lehrbuch, ; 1).

Mucksch, Harry (Hg.) (1999):

Das Data Warehouse-Konzept. Architektur, Datenmodelle, Anwendungen; mit Erfahrungsberichten; [Berichte eines Symposiums, gehalten im Juni 1996 auf Schloß Reichartshausen in Oestrich-Winkel]. Ebs European Business School; Debis-Systemhaus DCS GmbH; Symposium. 3., überarb. Aufl., Nachdruck.

Wiesbaden: Gabler.

Roland Berger Strategy Consultants (2015):

DIE DIGITALE TRANSFORMATION DER INDUSTRIE.

Was sie bedeutet. Wer gewinnt. Was jetzt zu tun ist.

Hg. v. Roland Berger Strategy Consultants.

Online verfügbar unter http://bdi.eu/media/user_upload/Digitale_Transformation.pdf, zuletzt geprüft am 10.07.2017.

Saake, Gunter; Sattler, Kai-Uwe; Heuer, Andreas (2010):

Datenbanken. Konzepte und Sprachen.

4. Aufl. Heidelberg, Hamburg: mitp Verl.-Gruppe Hüthig Jehle Rehm (Biber-Buch).

Saltzer, Jerome H. (1975):

Protection and the Control of Information Sharing in Multics. Massachusetts Institute of Technology.

Online verfügbar unter http://www.cs.virginia.edu/~evans/cs551/saltzer/, zuletzt geprüft am 25.07.2017.

Sattelberger, Thomas (Hg.) (2015):

Das demokratische Unternehmen. Neue Arbeits- und Führungskulturen im Zeitalter digitaler Wirtschaft.

1. Aufl. Freiburg u.a.: Haufe.

Schmitt, Robert; Pfeifer, Tilo (2015):

Qualitätsmanagement. Strategien - Methoden - Techniken.

5. aktualisierte Auflage. München [u.a.]: Hanser (Hanser eLibrary).

Schneede, Frank (2016):

Überwachungs- und Analyse-Werkzeuge.

In: Red Stack Magazin 2016 (5), S. 10-15.

Schnider, Dani; Jordan, Claus; Welker, Peter; Wehner, Joachim (2016):

Data Warehouse Blueprints. Business Intelligence in der Praxis.

München: Hanser.

Schön, Dietmar (2016):

Planung und Reporting. Grundlagen, Business Intelligence, Mobile BI und Big-Data-Analytics. 2. überarbeitete Auflage.

Schrade, A. (1996):

Data Warehouse, die strategische Waffe für den Unternehmenserfolg.

In: Office Management 1996 (12), S. 50-53.

Schütte, Reinhard (1998):

Grundsätze ordnungsmäßiger Referenzmodellierung. Konstruktion konfigurations- und anpassungsorientierter Modelle.

Zugl.: Münster, Univ., Diss., 1997.

Wiesbaden: Gabler (Neue betriebswirtschaftliche Forschung, 233).

Thoma, Patrick (2017):

Template Business Event Analysis and Modelling.

Ein Template zur mehrsprachigen Anforderungsanalyse in agilen Data Warehouse Projekten. Online verfügbar unter https://drive.google.com/open?id=0B9bevrhPXUa1NkZkak9pbUR2RFk.

Wallmüller, Ernest (2014):

Risiko- und Chancen-Management für IT- und Software-Projekte.

Ein Leitfaden für die Umsetzung in der Praxis.

1. Aufl. s.l.: Carl Hanser Fachbuchverlag.

Wedekind, Hartmut; Görz, Günter; Kötter, Rudolf; Inhetveen, Rüdiger (1998):

Modellierung, Simulation, Visualisierung. Zu aktuellen Aufgaben der Informatik.

In: Informatik-Spektrum 21 (5), S. 265-272. DOI: 10.1007/s002870050104.

75 von 75 Seiten

Details

Titel
Ein Referenzmodell zur Erstellung eines Data Warehouse mit Data Vault unter Berücksichtigung der Informationssicherheit des Systems
Hochschule
Duale Hochschule Baden Württemberg Mosbach
Note
1,3
Autor
Jahr
2017
Seiten
75
Katalognummer
V382962
ISBN (Buch)
9783668587311
Dateigröße
2877 KB
Sprache
Deutsch
Schlagworte
Data Vault, BEAM, Informationssicherheit, Data Warehouse, Digitale Transformation, Anforderungsanalyse, ETL
Arbeit zitieren
Patrick Thoma (Autor), 2017, Ein Referenzmodell zur Erstellung eines Data Warehouse mit Data Vault unter Berücksichtigung der Informationssicherheit des Systems, München, GRIN Verlag, https://www.grin.com/document/382962

Kommentare

  • Noch keine Kommentare.
Im eBook lesen
Titel: Ein Referenzmodell zur Erstellung eines Data Warehouse mit Data Vault unter Berücksichtigung der Informationssicherheit des Systems



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