Data-Warehouse-Systeme für Dummies - Wolfgang Gerken - E-Book

Data-Warehouse-Systeme für Dummies E-Book

Wolfgang Gerken

0,0
23,99 €

-100%
Sammeln Sie Punkte in unserem Gutscheinprogramm und kaufen Sie E-Books und Hörbücher mit bis zu 100% Rabatt.

Mehr erfahren.
Beschreibung

Jede Business-Intelligence-Anwendung beruht letzten Endes auf einem Data Warehouse. Data Warehousing ist deshalb ein sehr wichtiges Gebiet der Angewandten Informatik, insbesondere im Zeitalter von Big Data. Das vorliegende Buch beleuchtet das Data Warehouse aus zwei Perspektiven: der des Entwicklers und der des Anwenders. Der zukünftige Entwickler lernt, ein Data Warehouse mit geeigneten Methoden selbst zu entwickeln. Für den zukünftigen Anwender geht der Autor auf die Themen Reporting, Online Analytical Processing und Data Mining ein. Das Lehrbuch ist auch zum Selbststudium geeignet. Kenntnisse über Datenbanksysteme sollten allerdings vorhanden sein.

Sie lesen das E-Book in den Legimi-Apps auf:

Android
iOS
von Legimi
zertifizierten E-Readern

Seitenzahl: 328

Veröffentlichungsjahr: 2018

Bewertungen
0,0
0
0
0
0
0
Mehr Informationen
Mehr Informationen
Legimi prüft nicht, ob Rezensionen von Nutzern stammen, die den betreffenden Titel tatsächlich gekauft oder gelesen/gehört haben. Wir entfernen aber gefälschte Rezensionen.



Titelei

WILEY-VCH Verlag GmbH & Co. KGaA

Data-Warehouse-Systeme für Dummies

Wolfgang Gerken

Data-Warehouse-Systeme

Fachkorrektur von Dr. Martin Schäfer

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

1. Auflage 2018

© 2018 WILEY-VCH Verlag GmbH & Co. KGaA, Weinheim

All rights reserved including the right of reproduction in whole or in part in any form. This book published by arrangement with John Wiley and Sons, Inc.

Alle Rechte vorbehalten inklusive des Rechtes auf Reproduktion im Ganzen oder in Teilen und in jeglicher Form. Dieses Buch wird mit Genehmigung von John Wiley and Sons, Inc. publiziert.

Wiley, the Wiley logo, Für Dummies, the Dummies Man logo, and related trademarks and trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries. Used by permission.

Wiley, die Bezeichnung »Für Dummies«, das Dummies-Mann-Logo und darauf bezogene Gestaltungen sind Marken oder eingetragene Marken von John Wiley & Sons, Inc., USA, Deutschland und in anderen Ländern.

Das vorliegende Werk wurde sorgfältig erarbeitet. Dennoch übernehmen Autoren und Verlag für die Richtigkeit von Angaben, Hinweisen und Ratschlägen sowie eventuelle Druckfehler keine Haftung.

Coverfoto: Cybrain/stock.adobe.com

Korrektur: Claudia Lötschert

Satz/ePub: Reemers Publishing Services GmbH, Krefeld

Print ISBN: 978-3-527-71447-6

ePub ISBN: 978-3-527-81303-2

Inhaltsverzeichnis

Cover

Titelei

Einleitung

Über dieses Buch

Konventionen in diesem Buch

Was Sie nicht lesen müssen

Törichte Annahmen über den Leser

Wie dieses Buch aufgebaut ist

Teil I: Was ist ein Data Warehouse?

Teil II: Architektur eines Data-Warehouse-Systems

Teil III: Anwendungsbereiche für ein Data Warehouse

Teil IV: Modellierung eines Data-Warehouse-Systems

Teil V: Zugriff auf ein Data Warehouse

Teil VI: Speicherung und Optimierung auf Datenbankebene

Teil VII: Der Top-10-Teil

Symbole, die in diesem Buch verwendet werden

Wie es weitergeht

Teil I: Was ist ein Data Warehouse?

Kapitel 1: Ein Beispiel zur Einführung

Daten und ihre Verarbeitung

Daten und Datenbanken

Die Verarbeitung von Daten

Analyse von Absatzmengen und Planzahlen als Beispiel

Besonderheiten analytischer Aufgabenstellungen

Wenn personenbezogene Daten ins Spiel kommen

Kapitel 2: Das Data Warehouse im Umfeld der betrieblichen Informationssysteme

Hierarchie betrieblicher Informationssysteme

Zusammenfassung: Analytische Informationssysteme

Beispiele für analytische Informationssysteme

Beispiel 1: Analytische Informationssysteme im CRM

Beispiel 2: Kennzahlen-Analysesysteme im Rechnungswesen

Beispiel 3: Website-Analysesysteme

Fazit: Data Warehouse und analytische Informationssysteme

Kapitel 3: Definition und Abgrenzung des Begriffs »Data Warehouse«

Die 3-Schichten-Architektur analytischer Informationssysteme

Definitionen des Begriffs Data Warehouse

Definition von Inmon

Definition von Kimball

Vergleich der beiden Definitionen

Anwendungsfall: Das Data Warehouse und Business Intelligence

Teil II: Architektur eines Data-Warehouse-Systems

Kapitel 4: Überblick über die Architektur eines Data-Warehouse-Systems

Die Phasen des Data Warehousing

Ein allgemeines Data-Warehouse-Architekturmodell

Vorgehensweisen bei der Erstellung eines Data Warehouse

Projektdefinition und Machbarkeitsstudie

Analyse, Entwurf und Einführung für einen Anwendungsbereich

Kapitel 5: Der ETL-Prozess

Überblick

Ein einführendes Beispiel

Extraktion

Das Pull-Prinzip

Das Push-Prinzip

Beispiele

Transformation

Datenbestandsanalyse

Datenbereinigung

Datenintegration

Laden

Kapitel 6: Die Basisdatenbank

Merkmale der Basisdatenbank

Unterschied zwischen operativen Datenbanken und der Basisdatenbank

Die operativen Quellsysteme des Beispiels

Die Basisdatenbank des Beispiels

Kapitel 7: Das Analyse-Subsystem

Dimensionen und Fakten

Dimension oder Metrik?

Metriken als Dimension

Dimensionen als Metrik

Klassifizierung von Dimensionen

Fachliche Dimensionen

Kategorische Dimensionen

Strukturelle Dimensionen

Hierarchien von Dimensionswerten

Parallele Hierarchien

Unausgeglichene Hierarchiebäume

Strukturänderungen in Hierarchien

Slowly Changing Dimensions

Typ 1: Überschreiben

Typ 2: Neue Zeile

Typ 3: Spalten mit altem und neuem Wert

Typ 4: Mini-Dimension

Zusammenfassung

Verknüpfung von Dimensionen über Metriken

Aggregationstypen von Fakten

Die Themen Datenqualität und Datenschutz

Datenqualität

Datenschutz

Architekturvarianten für ein Analyse-Subsystem

Möglichkeiten für die Architektur

Die Hub-and-Spoke-Architektur

Auswertungen und Analysen

Kapitel 8: Metadaten

Was sind Metadaten?

Metadaten im Data-Warehouse-Kontext

Das Metadaten-Management in einem Data-Warehouse-System

Standards für Data-Warehouse-Metadaten

Ein kleines Beispiel

Teil III: Anwendungsbereiche für ein Data Warehouse

Kapitel 9: Reporting

Das Berichtswesen eines Unternehmens

Überblick und Definition

Erzeugung und Verteilung von Reports

Arten von Berichtssystemen

Was sich Anwender vom Reporting wünschen und wie die Wirklichkeit oft aussieht

Einige Tipps für die Report-Gestaltung

Graphische Darstellungen im Report

Die Hichert-Success-Regeln

Grundformen für Reports

Ist-Ist-Vergleiche

Plan-Ist-Vergleiche

Plan-Wird-Vergleiche

Berücksichtigung dynamischer Dimensionsstrukturen

Report as-is

Report as-of

Report as-posted

Ein praktisches Beispiel

Kapitel 10: Online Analytical Processing

Motivation und Definition

Charakteristika von OLAP

Abgrenzung OLAP und OLTP

Die Coddschen Regeln

FASMI

Spezielle OLAP-Operatoren

Pivotierung bzw. Rotation

Roll-up und Drill-down

Slice und Dice

Beispiel

Kapitel 11: Data Mining

Einführung

CRISP-DM

Methoden und Verfahren beim Data Mining

Assoziationsanalyse

Clusteranalyse

Klassifikation mit der Diskriminanzanalyse

Entscheidungsbaumverfahren

Spezielle Data-Mining-Fragestellungen im Kontext von Data-Warehouse-Daten

Welche Artikel werden gemeinsam gekauft?

Unterscheiden sich gute, normale und schlechte Kunden?

Welche Kunden besitzen eine bestimmte Produktaffinität?

Praxisbeispiel »Predictive Analytics«

Kollaboratives Filtern

Teil IV: Modellierung eines Data-Warehouse-Systems

Kapitel 12: Data Vault

Einführung

Hubs, Satelliten und Links

Hubs

Links

Satelliten

Beispiel

Kapitel 13: Semantischer Entwurf eines Data Warehouse

Zur Wiederholung: das Entity-Relationship-Modell

Drei Schritte bei der Modellierung einer Datenbank

Das ER-Modell: Entitätstypen, Attribute und Beziehungen

Das multidimensionale ER-Modell

ADAPT

Kapitel 14: Relationale Modellierung der Datenwürfel

Einführung

Das Star-Schema

Beispiel

Besondere Merkmale des Star-Schemas

Das Snowflake-Schema

Vergleich von Star- und Snowflake-Schema

Das Galaxy-Schema

Teil V: Zugriff auf ein Data Warehouse

Kapitel 15: Multidimensionale Abfragen mit SQL

Zugriff auf ein Data Warehouse mit SQL

Erzeugen der Tabellen

Typische analytische Fragestellungen

OLAP-Erweiterungen von SQL

Die WINDOW-Klausel

Erweiterungen der GROUP-BY-Option

Statistische Funktionen

Kapitel 16: Die Abfragesprache MDX

Einführung

Spezielle OLAP-Operatoren und Funktionen

Tupel und Sets

Member und Children

Kreuzprodukt mittels Crossjoin

Der WITH-Operator

Häufige Fragestellungen

Kapitel 17: Zusammenspiel von MDX und SQL

OLAP-Server

Der OLAP-Server Mondrian

MDX-Schema von Mondrian

Mondrian-Frontend-Tools

Teil VI: Speicherung und Optimierung auf Datenbankebene

Kapitel 18: ROLAP, MOLAP und anderes

ROLAP und MOLAP

Spaltenorientierte und In-Memory-Speicherung

NoSQL-Datenbanksysteme

Typen von NoSQL-Systemen

NoSQL-Datenbanken bei einem Data Warehouse

Beurteilung

Kapitel 19: Optimierungsmöglichkeiten bei relationalen Datenbanken

Einführung

Partitionierung

Partition by List

Partition by Range

Partition by Hash

Partition by Reference

Materialized Views

Klassische Views vs. Materialized Views

Materialized Views bei einem Data Warehouse

Indizierung

Klassischer Index

Bitmap-Index

Mehrdimensionale Indizes

Teil VII: Der Top-10-Teil

Kapitel 20: 10 Schritte auf dem Weg zu Ihrem ersten Dashboard

Und so wird es gemacht …

Festlegung der Datenquellen

Vorbereitung der Daten

Erstellung eines Dashboards

Daten aus mehreren Quellen

Integration von Landkarten

Kapitel 21: 10 Schritte, die helfen, die richtige Data-Warehouse-Software zu finden

Marktanalyse für BI-Software

Definition der eigenen Anforderungen

Einbindung des Managements, Projektplan

Marktanalyse der infrage kommenden BI-Anbieter

Einholung von Angeboten

Durchführung von Testinstallationen

Bewertung der Systeme

Ermittlung der Kosten

Einholung von Referenzen, Anbieterqualifikation

Überprüfung der Lizenzvereinbarung

Kapitel 22: 10 Übungsaufgaben zur Wiederholung

Aufgaben

Aufgabe 1: Assoziationsanalyse

Aufgabe 2: Diskriminanzanalyse

Aufgabe 3: Data Vault

Aufgabe 4: ADAPT

Aufgabe 5: MDX

Aufgabe 6: Star-Schema

Aufgabe 7: OLAP mit SQL

Aufgabe 8: Snowflake-Schema

Aufgabe 9: Optimierung

Aufgabe 10: Multidimensionale Datenbank

Lösungen

Lösung von Aufgabe 1

Lösung von Aufgabe 2

Lösung von Aufgabe 3

Lösung von Aufgabe 4

Lösung von Aufgabe 5

Lösung von Aufgabe 6

Lösung von Aufgabe 7

Lösung von Aufgabe 8

Lösung von Aufgabe 9

Lösung von Aufgabe 10

Literaturverzeichnis

Stichwortverzeichnis

Wiley End User License Agreement

Abbildungsverzeichnis

Kapitel 1

Abbildung 1.1: Ampel- und Tachometerdarstellung

Abbildung 1.2: Beispiel für Dashboard © 2017 MicroStrategy Incorporated. All Rights Reserved

Abbildung 1.3: Datenanalyse mit mehreren Datenquellen

Abbildung 1.4: Datenanalyse mit Data Warehouse

Kapitel 2

Abbildung 2.1: Klassische Hierarchie der Informationssysteme

Abbildung 2.2: Operative und analytische Informationssysteme

Abbildung 2.3: Return on Investment

Abbildung 2.4: Würfel mit Werten von Kennzahlen

Abbildung 2.5: ER-Diagramm für Website-Analyse

Kapitel 3

Abbildung 3.1: Zugriff auf die Daten der operativen Informationssysteme

Abbildung 3.2: Trennung der Analysedaten von den operativen

Abbildung 3.3: Data-Warehouse-Architektur nach Inmon

Abbildung 3.4: Data Warehouse Architektur nach Kimball

Abbildung 3.5: Data Warehouse, Business Intelligence und analytische Informationssysteme

Abbildung 3.6: Prozess bei Einsatz von Data Warehouse und ­Business Intelligence

Kapitel 4

Abbildung 4.1: Phasen beim Data Warehousing

Abbildung 4.2: Data-Warehouse-Referenzarchitektur, in Anlehnung an (Bauer/Günzel 2013, S. 42)

Abbildung 4.3: Data-Warehouse-Subsysteme (angelehnt an die Referenzarchitektur)

Abbildung 4.4: Data-Warehouse-Entwicklungsplan

Abbildung 4.5: Modellhafte Skizze für Data-Warehouse-Projekte

Kapitel 5

Abbildung 5.1: ETL beim Data Warehousing

Abbildung 5.2: Push-/Pull-Prinzip

Abbildung 5.3: Laden in die Basisdatenbank

Abbildung 5.4: Laden in das Data Warehouse

Abbildung 5.5: Unabhängiges Laden in dezentrale Data Marts

Abbildung 5.6: Gemeinsames Laden in dezentrale Data Marts

Kapitel 7

Abbildung 7.1: Faktenwürfel »Absatz«

Abbildung 7.2: Umsatz als Kennzahl und Dimension

Abbildung 7.3: Zwei zweidimensionale Datenwürfel

Abbildung 7.4: Äquivalenter Datenwürfel mit Kennzahl-Dimension

Abbildung 7.5: Kundenhierarchie nach Regionen

Abbildung 7.6: Parallele Hierarchien beim Datum

Abbildung 7.7: Kundenhierarchie nach Typen

Abbildung 7.8: Unausgeglichener Hierarchiebaum

Abbildung 7.9: Beispiel für Strukturänderungen bei Hierarchiebäumen

Abbildung 7.10: Verknüpfung von Dimensionen durch Fakten

Abbildung 7.11: Mehrere Analyse-Subsysteme mit je einem ETL-Subsystem

Abbildung 7.12: Ein ETL-Subsystem und mehrere Data Marts

Abbildung 7.13: Ein ETL-Subsystem und ein zentrales Data Warehouse

Abbildung 7.14: Ein ETL-Subsystem mit einem zentralen Data Ware­house und mehreren nachgelagerten Data Marts

Abbildung 7.15: Hub-and-Spoke-Architektur

Kapitel 8

Abbildung 8.1: Metadaten und Data-Warehouse-Tools

Abbildung 8.2: Einheitliches Metadaten-Management

Abbildung 8.3: Metadatenaustausch zwischen Data-Warehouse-Tools

Abbildung 8.4: UML Klassendiagramm für die Metadaten eines Cubes

Kapitel 9

Abbildung 9.1: Zwei Reports im Vergleich

Abbildung 9.2: Beispiel: Plan-Ist-Vergleich zwischen Filialen, Umsatz in Mio. Euro; nach (Chartisan 2015)

Abbildung 9.3: Kreis- und Balkendiagramm

Abbildung 9.4: Landkarte mit Umsätzen nach Ländern und Städten © 2017 MicroStrategy Incorporated. All rights reserved

Abbildung 9.5: Zeitlicher Ist-Ist-Vergleich

Abbildung 9.6: Plan-Ist-Vergleich

Abbildung 9.7: Plan-Wird-Vergleich

Abbildung 9.8: Architektur des Data Warehouse von Eventim

Abbildung 9.9: Beispiel-Dashboard

Kapitel 10

Abbildung 10.1: OLAP-Datenwürfel

Abbildung 10.2: Beispiel zur OLAP-Datenbasis

Abbildung 10.3: Absatz pro Kunde und Produktgruppe am 28.02.2018

Abbildung 10.4: Pivotierung

Abbildung 10.5: Drill-down

Abbildung 10.6: Drill-down für Tee

Abbildung 10.7: Roll-up

Abbildung 10.8: Slice und Dice

Abbildung 10.9: Ausgangsdaten

Abbildung 10.10: Ergebnis nach Anwendung von Slice auf Neukunden

Abbildung 10.11: Zweifache Anwendung des ­Slice-Operators (Neukunden am 28.02.)

Abbildung 10.12: Ergebnis nach Anwendung von Dice

Abbildung 10.13: Screenshot für OLAP © 2008–2018 Hitachi Vantara Corporation. All rights reserved (mit eigenen Erläuterungen)

Kapitel 11

Abbildung 11.1: Vorgehensweise Data Mining vs. OLAP

Abbildung 11.2: CRISP-DM

Abbildung 11.3: Clusterbildung

Abbildung 11.4: Dendrogramm

Abbildung 11.5: Stichprobe mit Hütchen

Abbildung 11.6: Kontingenztafel

Abbildung 11.7: Mitarbeiterzufriedenheit mit dem Gehalt ☺ bedeutet zufrieden, ☹ bedeutet unzufrieden.

Abbildung 11.8: Entscheidungsbaum

Abbildung 11.9: Erster Entscheidungsknoten

Abbildung 11.10: Entscheidungsbaum

Abbildung 11.11: Data-Warehouse-Daten für Assoziationsanalyse

Abbildung 11.12: Data-Warehouse-Daten für Clusteranalyse

Abbildung 11.13: Data-Warehouse-Daten für Diskriminanzanalyse und Entscheidungsbaumverfahren

Kapitel 12

Abbildung 12.1: Hub für Prüfungstermine

Abbildung 12.2: Link für Prüfungsteilnahme

Abbildung 12.3: Satellit für Prüfungstermine

Abbildung 12.4: ER-Diagramm für Prüfungswesen

Abbildung 12.5: Data-Vault-Datenmodell für das Prüfungswesen

Abbildung 12.6: Beispieldaten für Data-Vault-Tabellen

Kapitel 13

Abbildung 13.1: ER-Diagramm: ein Entitätstyp mit Attributen

Abbildung 13.2: ER-Diagramm: Entitätstypen mit Beziehung

Abbildung 13.3: MC-Notation

Abbildung 13.4: Grafische Notation der mER-Konstruktionselemente

Abbildung 13.5: Beispiel für mERM

Abbildung 13.6: Grundlegende Modellierungselemente von ADAPT

Abbildung 13.7: Beispiel mit ADAPT

Kapitel 14

Abbildung 14.1: Beispiel für Star-Schema

Abbildung 14.2: Typische Struktur von OLAP-Abfragen

Abbildung 14.3: Beispiel für Snowflake-Schema

Abbildung 14.4: Beispiel für Galaxy auf Basis des Star-Schemas

Abbildung 14.5: Beispiel für Galaxy auf Basis des Snowflake-Schemas

Kapitel 15

Abbildung 15.1: SQL im Kontext eines Data Warehouse

Kapitel 16

Abbildung 16.1: MDX-Abfrage

Kapitel 17

Abbildung 17.1: OLAP-Tool mit direktem Zugriff auf das Data ­Warehouse

Abbildung 17.2: OLAP-Tool mit OLAP-Server

Abbildung 17.3: Mondrian

Abbildung 17.4: MDX-Ergebnis mit JPivot © Tonbeller AG

Kapitel 18

Abbildung 18.1: Multidimensionale Speicherung eines Datenwürfels

Abbildung 18.2: Zeilenorientierte Speicherung

Abbildung 18.3: Spaltenorientierte Speicherung

Abbildung 18.4: Komprimierte Speicherung der Wohnorte

Abbildung 18.5: Fakten als externe Tabelle

Kapitel 19

Abbildung 19.1: Beispiel für Partitionierung

Abbildung 19.2: Index für das Attribut ArtID der Faktentabelle

Abbildung 19.3: Bitlisten-Index für das Attribut ArtID der Faktentabelle

Abbildung 19.4: Logisches UND zweier Index-Tabellen

Kapitel 20

Abbildung 20.1: Aufbau MicroStrategy Desktop Startbildschirm © 2018 MicroStrategy Incorporated. All Rights Reserved (mit eigenen Erläuterungen)

Abbildung 20.2: Vorschau auf importierte Daten, © 2018 MicroStrategy Inc

Abbildung 20.3: Datenumbau (nur das Jahr 2018) © 2018 MicroStrategy Inc

Abbildung 20.4: Ergebnis des Datenimports, © 2018 MicroStrategy Inc

Abbildung 20.5: Tabellarisches Dashboard mit den Verkaufszahlen, © 2018 MicroStrategy Inc.

Abbildung 20.6: Zwei Datenquellen, © 2018 MicroStrategy Inc

Abbildung 20.7: Tabellarisches Dashboard mit zwei Datenquellen, © 2018 MicroStrategy Inc.

Kapitel 22

Abbildung 22.1: ADAPT-Diagramm für den Cube Prüfungen

Abbildung 22.2: Star-Schema

Abbildung 22.3: Galaxy-Schema

Seitenverzeichnis

Einleitung

Offensichtlich interessieren Sie sich für das Thema »Data Warehouse«, denn sonst hätten Sie dieses Buch nicht in die Hand genommen.

Sie besuchen eine Vorlesung oder einen Fortbildungskurs zu diesem Thema?

Sie wollen – oder müssen – beruflich ein Data Warehouse aufbauen oder in einem Data-Warehouse-Projekt mitarbeiten, fühlen sich aber noch nicht fit auf diesem Gebiet?

Oder Sie möchten Ihre Kenntnisse auf diesem Gebiet einfach aus persönlichem Interesse erweitern?

Dann ist dieses Lehrbuch genau das Richtige für Sie! Der Inhalt basiert auf den Erfahrungen, die ich als Hochschullehrer über viele Jahre bei Vorlesungen über Data-Warehouse-Systeme gesammelt habe.

Über dieses Buch

Das Ziel dieses Lehrbuchs über Data-Warehouse-Systeme ist es, Ihnen zum einen genügend Wissen zu vermitteln, damit Sie bei diesem Thema mitreden oder eine Prüfung bestehen können, und zum anderen Ihr Interesse zu wecken, sich weiterhin praktisch damit zu beschäftigen.

Man kann sich dem Thema »Data Warehouse« von zwei Seiten nähern. Einmal aus Entwickler- und einmal aus Anwendersicht. Für beide Herangehensweisen ist dieses Buch geeignet. Dabei kommen theoretische Konzepte und Definitionen nur soweit vor, wie es für das Verständnis notwendig ist. Der Schwerpunkt liegt auf praktischen Aspekten in den Bereichen Entwurf und Betrieb eines Data Warehouse, die durch viele Beispiele untermauert werden. Und am Ende, wenn Sie alles durchgearbeitet haben, finden Sie in Kapitel 22 zehn Übungsaufgaben samt Lösungen zum Wiederholen. Damit können Sie überprüfen, ob Sie alles verstanden haben. Falls dies nicht der Fall sein sollte, empfehle ich Ihnen, die verbliebenen Schwächen oder Unsicherheiten durch Wiederholung der jeweiligen Kapitel auszumerzen.

An dieser Stelle möchte ich nicht versäumen, mich bei allen zu bedanken, die zum Gelingen dieses Buchs beigetragen haben. Mein besonderer Dank gilt dabei Herrn Thomas Denker und Herrn Prof. Dr. Reinhard Völler für die kritische Durchsicht des Manuskripts und die fach­lichen Hinweise. Nicht zuletzt gilt mein Dank Herrn Marcel Ferner vom Verlag Wiley-VCH, der mich verlagsseitig betreut hat.

Konventionen in diesem Buch

Im Text gibt es einige Konventionen, die Sie kennen sollten:

1.An einigen Stellen finden Sie Beispiele für SQL, MDX und XML-Definitionen. Diese werden in einer anderen Schriftart wiedergegeben.

2.Die hier genannten Bezeichnungen für Software usw. sind in der Regel eingetragene Warenzeichen der jeweiligen Hersteller; zum Beispiel:Oracle® ist eingetragenes Warenzeichen der Oracle Corporation, USA.MS Excel® und SQL Server® sind eingetragene Warenzeichen der Microsoft Corporation, USA.MicroStrategy® Desktop ist eingetragenes Warenzeichen der MicroStrategy Inc. (US).Pentaho® ist eingetragenes Warenzeichen der Hitachi Vantara Corporation.Nicht an jeder Stelle im Text wird jeweils explizit darauf hingewiesen.

3.Liebe Leserinnen, um den Lesefluss nicht zu beeinträchtigen, werden bei Anreden nicht an allen Stellen im Buch die männliche und die weibliche Form nebeneinander verwendet. Seien Sie also nachsichtig, wenn im weiteren Verlauf nicht immer von Kunden und Kundinnen, Lesern und Leserinnen usw. die Rede ist. Natürlich ist die weibliche Form immer mit gemeint.

4.Übrigens: Zitate werden im Harvard-Stil angegeben. Das heißt, im Text finden Sie in Klammern den Nachnamen des Autors, das Erscheinungsjahr und, falls erforderlich, die Seitenzahl. Im Literaturverzeichnis steht dann der komplette Nachweis.

Was Sie nicht lesen müssen

Was meinen Sie denn, müssen Sie lesen? Von »müssen« kann schon mal nicht die Rede sein. Die Bücher der »… für Dummies«-Reihe zeichnen sich dadurch aus, dass sie modular aufgebaut sind. Sie könnten sich also auch – bei entsprechendem Vorwissen – einzelne Teile gezielt herauspicken, die Sie besonders interessieren.

Die ersten beiden Teile über analytische Informationssysteme, die Definition eines Data ­Warehouse sowie deren Architektur sollten Sie immer lesen; zumindest, wenn Data Warehousing »Neuland« für Sie ist. Das ist der Zugang zum Thema. Wie es dann weitergeht, hängt ganz von Ihren bereits vorhandenen persönlichen Kenntnissen und Erwartungen ab.

Wenn Sie Data-Warehouse-Anwendungen programmieren wollen, sind die Teile IV bis VI besonders wichtig.

Wenn Sie als Nicht-Informatiker nur beim Modellieren einer Datenbank mitreden und den Informatikern die richtigen Fragen stellen wollen, ist Teil IV das Richtige für Sie.

Wenn Sie besonders an den Anwendungen eines Data Warehouse interessiert sind, sollten Sie den Teil III, Anwendungen, besonders genau lesen.

Aber eigentlich bin ich der Meinung, dass es sich lohnt, das gesamte Buch zu lesen. Außerdem lassen sich Querbezüge nicht immer vermeiden.

Törichte Annahmen über den Leser

Ich gehe davon aus, dass Sie dem Thema »Data Warehouse« ein gewisses Interesse entgegenbringen. Die meisten Leser wissen wahrscheinlich schon etwas darüber oder haben eine wage, intuitive Vorstellung davon. Außerdem können Sie vermutlich schon ganz routiniert mit PCs bzw. Laptops umgehen und zur Not auch Software installieren. Wenn Sie …

sich beruflich mit Data-Warehouse-Systemen auseinandersetzen müssen,

eine Vorlesung zu diesem Thema besuchen,

sich über den Entwurf, die Implementierung und die Anwendung eines Data Warehouse informieren wollen,

ohne gleich eine Promotion darüber anzustreben, dann sollten Sie ruhig weiterlesen.

Da ein Data-Warehouse-System eine besondere Form eines Datenbanksystems ist, sollten Sie zumindest grundlegende Kenntnisse über Datenbanksysteme mitbringen. Diese werden an einigen Stellen vorausgesetzt. Denn das Buch heißt ja nicht Datenbank- und Data-Warehouse-Systeme. Dann wäre es auch erheblich dicker.

Wie dieses Buch aufgebaut ist

Dieses Buch hat sieben Teile, die wiederum aus mehreren Kapiteln bestehen. Hier erfahren Sie, worum es bei diesem Lehrbuch geht und welche Inhalte die einzelnen Teile haben. Damit können Sie sich schon einen kleinen Überblick darüber verschaffen, was Sie beim Weiterlesen erwartet. Falls Sie jetzt noch nicht alle Fachbegriffe verstehen, lernen Sie diese sukzessive in den einzelnen Kapiteln.

Teil I: Was ist ein Data Warehouse?

Der erste Teil soll Sie für das Thema begeistern. Hier erfahren Sie Grundlegendes über Data-Warehouse-Systeme. Dazu gehören auch Beispiele für analytische Informationssysteme, denn ein Data Warehouse ist für die Datenhaltung bei analytischen Fragestellungen zuständig.

Teil II: Architektur eines Data-Warehouse-Systems

Wenn Sie wissen wollen, wofür ein Data Warehouse gut ist und wie man es aufbauen kann, müssen Sie dessen Architektur kennen. Es gibt für ein Data Warehouse zwar keine einheitlich anerkannte Definition, aber die Ansätze von Inmon und Kimball sind weit verbreitet. Außerdem werden in diesem Teil wichtige Begriffe wie Basisdatenbank und Data Mart vorgestellt; nicht zu vergessen den ETL-Prozess (Extract, Transform, Load) zum Laden von Daten in ein Data Warehouse.

Teil III: Anwendungsbereiche für ein Data Warehouse

Sehr oft, wenn von einem Data Warehouse gesprochen wird, fällt der Begriff »Online Analytical Processing«, kurz OLAP. Hier erfahren Sie, was das ist. Außerdem werden die beiden anderen Anwendungsbereiche vorgestellt: Reporting und Data Mining. Beim letztgenannten wird es dabei etwas mathematisch.

Teil IV: Modellierung eines Data-Warehouse-Systems

In diesem Teil lernen Sie, ein Data Warehouse zu modellieren. Das erfolgt auf mehreren Abstraktionsebenen, mehr fachlich orientiert oder mehr implementierungsorientiert. Also gibt es auch verschiedene Methoden: von Data Vault über ADAPT bis zur relationalen Modellierung in Form eines Star- oder Snowflake-Schemas.

Teil V: Zugriff auf ein Data Warehouse

Beim Zugriff auf ein Data Warehouse werden zwei bekannte Abfragesprachen vorgestellt: SQL und MDX. Während Sie SQL wahrscheinlich schon aus dem Datenbankumfeld kennen, dürfte MDX neu sein. Bei SQL erfahren Sie vor allem etwas über die Data-Warehouse-spezifischen Erweiterungen, die in einem normalen SQL-Lehrbuch im Allgemeinen nicht vorkommen.

Teil VI: Speicherung und Optimierung auf Datenbankebene

In den meisten Fällen wird ein Data Warehouse mithilfe einer relationalen Datenbank aufgebaut, man nennt das »relational OLAP«, also ROLAP. Aber auch andere Speicherungs­formen werden hier vorgestellt: etwa mit einem NoSQL-System oder die Kopplung beider ­Datenhaltungssysteme. Hinzu kommt die Diskussion von Optimierungsmöglichkeiten, denn ein Data Warehouse kann sehr groß werden. Wenn Sie ein Data Warehouse selbst implementieren wollen, sollten Sie hier besonders aufpassen.

Teil VII: Der Top-10-Teil

Zum Schluss kommt der Top-10-Teil, der Tipps für besondere Lebenslagen enthält; zumindest, was Data-Warehouse-Systeme betrifft:

10 wichtige Schritte zu Ihrem ersten Dashboard

10 Schritte, die helfen, die richtige Data-Warehouse-Software zu finden

10 Übungsaufgaben zur Wiederholung

Sie können das letzte Kapitel auch als abschließende Zusammenfassung sehen: Wenn Sie bei diesen Fragen sagen »ist ja klar«, dann können Sie sich mit gutem Gewissen auf Ihr erstes/nächstes Data-Warehouse-Projekt stürzen.

Symbole, die in diesem Buch verwendet werden

Immer, wenn besondere Aufmerksamkeit erforderlich ist, sehen Sie eines der folgenden Symbole:

Kleiner Tipp gefällig? Die Beachtung dieses hilfreichen Hinweises macht Ihnen das Data-Warehouse-Leben leichter.

Wenn Sie dieses Symbol sehen, könnte daneben etwas stehen, was wirklich wichtig ist und nicht einfach überlesen werden sollte. Eine gute Stelle, um über das bisher Gelesene einmal nachzudenken.

Achtung, hier steht eine Warnung! Wenn Sie diese nicht beachten, kann etwas gehörig schiefgehen.

Hier meldet sich der Techniker zu Wort und gibt beispielsweise einen Hinweis, wenn Sie mal nicht weiterkommen. Gelegentlich finden Sie hier auch einen Tipp für Insider, der über das Grundlagenwissen hinausgeht.

Das dürfte eigentlich klar sein.

Hier steht eine Definition. Fachbegriffe erleichtern das Leben, weil sie ein einheitliches Begriffsverständnis schaffen. Sie sollten sie parat haben.

Wie es weitergeht

Am besten, Sie werfen jetzt einmal einen Blick in das Inhaltsverzeichnis und überlegen, an welcher Stelle Sie mit dem Lesen beginnen möchten. Wenn Ihnen die einzelnen Kapitelüberschriften noch nicht viel sagen, fangen Sie einfach ganz klassisch und traditionell mit dem 1. Kapitel an.

Sie sollten aber nicht vergessen, gelegentlich persönliche Breakpoints zu setzen, um das bisher Gelesene zu reflektieren, praktisch auszuprobieren oder auch etwas ganz anderes zu machen – selbst wenn Sie das Thema gerade höchstspannend finden.

Viel Spaß beim Lesen und Lernen!

Teil I

Was ist ein Data Warehouse?

In diesem Teil …

In diesem Teil lernen Sie zwei unterschiedliche Definitionen des Begriffs »Data Warehouse« kennen. Sie sehen schon, man ist sich also nicht ganz einig, was ­darunter zu verstehen ist.

Sie werden am Ende dieses Teils wissen, worum es bei einem Data Warehouse geht.

Sie erfahren, wie sich ein Data Warehouse in die Struktur der betrieblichen Informationssysteme einfügt und was der Unterschied zwischen einem Data Warehouse und dem Begriff »Business Intelligence« ist.

In den folgenden Teilen dieses Buchs erfahren Sie dann darauf aufbauend mehr über die Architektur und ­Modellierung eines Data Warehouse sowie den Zugriff darauf, seine grundsätzlichen Anwendungsbereiche und Möglichkeiten zur Optimierung.

Kapitel 1

Ein Beispiel zur Einführung

In diesem Kapitel

Was sind Daten?

Auswertungen von Dateien und Datenbanken ohne Data Warehouse

Reporting-Tools und analytische ­Informationssysteme

Warum ein Data Warehouse sinnvoll ist

Vereinfacht formuliert ist ein Data Warehouse eine spezielle Datenbank zur Unterstützung betrieblicher Analyse- und Entscheidungsaufgaben, die eine einheitliche Sicht auf ursprünglich unterschiedliche (heterogene) und verteilte Datenbestände ermöglicht. Dieses Kapitel soll dazu dienen, den Sinn und Zweck eines Data Warehouse klarzumachen. Anhand eines Beispiels wird erläutert, wie in einem Unternehmen Datenbestände ausgewertet und analysiert werden und woher diese Daten kommen.

Daten und ihre Verarbeitung

Daten und Datenbanken

Daten, also gespeicherte Fakten über uns selbst, andere und unser Umfeld, begleiten uns unser ganzes Leben. Sie dienen – nach entsprechender Verarbeitung – als Grundlage von Entscheidungen und beeinflussen unser Handeln. Ein Beispiel hierfür ist die Kaufentscheidung für ein Smartphone anhand technischer Kenndaten und Nutzerbewertungen. Insbesondere für Firmen sind Daten immens wichtig, nicht nur bei den täglich anfallenden Geschäftsprozessen, sondern auch bei unternehmerischen Entscheidungen. Daten stellen eine besondere Ressource dar, die gepflegt werden muss. Ohne sie könnten zum Beispiel keine Kundenaufträge bearbeitet, keine Rechnungen geschrieben und keine Gehälter gezahlt werden.

Aber auch für unternehmerische Analysen und Entscheidungen sind Daten notwendig.

Wie hoch waren im letzten Monat der Absatz und Umsatz der Produkte in den einzelnen Vertriebsregionen oder bei den einzelnen Kunden?

Welche Unterschiede im Kaufverhalten gibt es zwischen den weiblichen und männlichen Kunden?

Welche Absatzchancen ergeben sich in den einzelnen Vertriebsregionen im kommenden Jahr?

Erhöht sich der Deckungsbeitrag, wenn bei Produkt X der Preis um 5 % gesenkt wird?

Welche Merkmale zeichnen die umsatzstärksten 10 % aller Kunden aus?

Daten werden in Dateien oder in Datenbanken gespeichert. Letztlich unterscheidet sich das darin, dass man mit Datenbanken versucht, etwas Ordnung in die gespeicherten Daten zu bringen. Meist wird von den Anwendungsprogrammen nicht direkt auf die gespeicherten Daten zugegriffen, sondern über eine Zwischenschicht, das Datenbankmanagementsystem – kurz DBMS. Ein DBMS zusammen mit einer Datenbank wird Datenbanksystem genannt. Der am häufigsten verwendete Typ dabei sind die relationalen Datenbanksysteme, bei denen alle Daten und ihre Beziehungen untereinander in Tabellen, den Relationen, gespeichert sind.

Sie wollen Ihr Wissen über Datenbanksysteme, insbesondere relationale, auffrischen? Kein Problem. Sie können alles Notwendige zu diesem Thema im Buch »Datenbanksysteme für Dummies« genauer nachlesen (Gerken 2018).

Die Verarbeitung von Daten

Die Speicherung von Daten ist kein Selbstzweck. Daten sind eine notwendige Ressource zur Durchführung einerseits operativer und andererseits dispositiver, analytischer betrieblicher Aufgaben. Doch was unterscheidet diese beiden Aufgabengruppen? Zum Beispiel eine Auftragsbearbeitung (operative Aufgabe) von einer Absatzanalyse (dispositive Aufgabe)? Die Bearbeitung eines Auftrags ist ein wohldefinierter Geschäftsprozess, der immer gleich abläuft und Daten auch verändert. Dagegen kann eine Absatzanalyse unterschiedlich ablaufen und ­erfordert je nach Zielrichtung der Analyse unterschiedliche Daten, eventuell auch in unterschiedlichem Detaillierungsgrad, und greift nur lesend auf die Dateien und Datenbanken zu. Siehe dazu auch die Tabelle 1.1.

Operative Aufgaben findet man vor allem im täglichen Routinegeschäft eines Unternehmens; man nennt das aus Informatik-Sicht Online Transaction Processing, kurz OLTP. Dispositive Aufgaben werden als Online Analytical Processing (OLAP) bezeichnet. Doch dazu mehr in Kapitel 10.

Aufgabentyp

operativ

dispositiv, analytisch

Aufgabenstruktur

fest

flexibel

Zugriff auf Daten

lesend und verändernd

nur lesend

Umfang der benötigten Daten

bekannt und fest

variabel

Tabelle 1.1: Bedarf an Daten für operative und dispositive, analytische Aufgaben

Diese Unterscheidung legt nahe, die Daten für operative und dispositive, analytische betriebliche Aufgaben zu trennen. Fällt Ihnen in diesem Zusammenhang der Begriff »Data Warehouse« ein? Der folgende Abschnitt beschreibt, wie eine klassische analytische Aufgabenstellung aussieht.

Analyse von Absatzmengen und Planzahlen als Beispiel

Nehmen wir einmal an, im Datenbestand eines Unternehmens gibt es eine Tabelle mit Verkaufszahlen, aus der ersichtlich ist, welche Kunden wo und wann etwas gekauft haben.

KundenNr

Name

Ort

ArtikelNr

Datum

Menge

1001

Clara

Hamburg

1010

01.10.2017

200

101

Clara

Berlin

1010

20.06.2018

300

100

Klaus

Hamburg

1010

23.02.2018

200

100

Klaus

Hamburg

2005

17.04.2018

100

101

Clara

Berlin

1010

19.04.2018

500

102

Julia

Hannover

2005

10.10.2018

100

Tabelle 1.2: Tabelle mit Verkaufszahlen

Ferner soll es eine Tabelle mit den Planzahlen für die geplanten jährlichen Absätze geben.

ArtikelNr

Jahr

Planabsatz

1010

2018

2500

1011

2018

2000

2005

2018

1000

Tabelle 1.3: Tabelle mit Planabsatzzahlen

Für das Jahr 2018 sollen jetzt die Verkaufszahlen ausgewertet werden.

Welche Artikel wurden von welchen Kunden gekauft?

Wie sieht die Gegenüberstellung der Ist- und Planabsätze bei den einzelnen Artikeln aus?

Bei sehr kleinen Unternehmen mag es noch möglich sein, die Auswertungen mit einem Tabellenkalkulationsprogramm zu machen. Wenn ein Unternehmen wächst, stößt man damit aber schnell an die Grenzen. Für die Planzahlen mag das noch gehen, denn Controller lieben EXCEL; die Absatzzahlen werden aber in der Datenbank des Onlineshops oder der Verkaufssoftware gespeichert sein.

Für die Auswertung kann man dann eines der auf dem Softwaremarkt verfügbaren Analysetools verwenden. Diese Werkzeuge können auf unterschiedliche Datenbanken und Dateien zugreifen und diese analysieren; natürlich auch auf ein Data Warehouse, wie Sie später noch sehen werden. Damit lassen sich unter anderem sogenannte Dashboards zur übersichtlichen, oft mit Grafiken versehenen Darstellung von Informationen erzeugen, die die gewünschten Auswertungen beinhalten.

Derartige Tools werden als Business-Intelligence-Tools (BI-Tool) bezeichnet. Die genaue Einführung des Begriffs erfolgt in Kapitel 3. Hier belassen wir es erst einmal bei dieser knappen Erläuterung.

In einem Dashboard werden hochaggregierte Unternehmenskennzahlen, die oft aus unterschiedlichen Quellen kommen, in übersichtlicher Form dargestellt. Damit kann man zum Beispiel sehen, wie hoch der gestrige Umsatz war oder wie oft der Onlineshop besucht worden ist.

Häufig zu finden ist die Darstellung von Kennzahlen in Ampel- oder Tachometerform

Abbildung 1.1: Ampel- und Tachometerdarstellung

Damit kann man sehr schnell erkennen, ob noch alles »im grünen Bereich« ist. Wir werden später erneut darauf zurückkommen, wenn wir die grundsätzlichen Analysemöglichkeiten von Data-Warehouse-Daten betrachten (Teil III).

Abbildung 1.2: Beispiel für Dashboard © 2017 MicroStrategy Incorporated. All Rights Reserved

Das Dashboard für die Absatzanalyse soll aus vier Bereichen bestehen:

1.Der Gesamtabsatz 2018 für alle Artikel zusammen

2.Der Absatz pro Verkaufsort, dargestellt auf einer Landkarte

3.Ein Vergleich zwischen dem Ist- und dem Planabsatz durch ein Balkendiagramm

4.Eine tabellarische Detaildarstellung der Absatzmengen je Artikel, Kunde und Datum.

Das Beispiel in Abbildung 1.2, welches auf den Tabellen 1.2 und 1.3 basiert, wur­de mit dem BI-Tool MicroStrategy Desktop® erzeugt; siehe dazu das Kapitel 20, »10 Schritte auf dem Weg zu Ihrem ersten Dashboard« im Top-10-Teil. Damit können Sie dieses Beispiel selbst nachvollziehen, was ich Ihnen empfehle.

Besonderheiten analytischer Aufgabenstellungen

Das obige Beispiel war insofern sehr einfach, weil alle Daten als EXCEL-Tabelle vorliegen, was bei sehr kleinen Unternehmen noch zutreffen mag. In der Praxis gibt es aber viele ­Datenquellen, die eventuell übergreifend ausgewertet werden müssen. Für Produktempfehlungen benötigt man zum Beispiel Absatzzahlen aus der Auftragsbearbeitung und zusätzlich Tracking-Daten aus dem Webserver des Onlineshops. Vielleicht hat das Unternehmen ja auch mehrere ausländische Tochtergesellschaften mit unterschiedlicher Software. Das macht es nur noch komplizierter. Generell sind in einem Unternehmen Daten auf viele verschiedene Arten gespeichert; insbesondere in folgenden Datenhaltungssystemen:

Tabellenkalkulation

Relationale Datenbank

NoSQL-Datenbank

Sonstige Dateien

Damit ergibt sich für ein BI-Tool, das auf Verkaufsdaten (eventuell mehrerer Filialen), Planungsdaten, Stammdaten von Kunden und Lieferanten usw. zugreifen muss, beispielsweise das in Abbildung 1.3 zu sehende Bild.

Die Integration der Daten erfolgt im BI-Tool, und dabei kann es viele Probleme geben:

Die Schnittstelle zur Datenbank muss zur Verfügung stehen, insbesondere müssen die Berechtigungen zum Lesen der Daten vorhanden sein. Eventuell muss eine eigene Benutzersicht (VIEW) bereitgestellt werden.

Es gibt unterschiedliche Bezeichnungen für dieselben Daten.

Es gibt gleiche Bezeichnungen für unterschiedliche Daten.

Daten sind unterschiedlich und teilweise nicht vollständig verschlüsselt, zum Beispiel das Geschlecht einmal als (1, 2) einmal als (m, w, i).

Es sind inkonsistente Werte vorhanden.

Abbildung 1.3: Datenanalyse mit mehreren Datenquellen

In der Abbildung 1.2 sehen Sie, dass ein Artikel überhaupt nicht verkauft worden ist. Das kann möglich sein. Wie sieht es aber aus, wenn es Artikel ohne Planzahl gibt? Und was ist, wenn sich Daten, die aus verschiedenen Quellen kommen, widersprechen?

Natürlich kann man es den einzelnen Anwendern unter dem Stichwort »Self Service Business Intelligence« überlassen, die Daten aus verschiedenen Quellsystemen zu lesen, zu harmonisieren und auszuwerten. Es stellt sich aber dann die Frage, ob das in einem Unternehmen zu einem einheitlichen Verständnis der Unternehmensdaten führt. Hinzu kommt, dass die Anwender sehr kreativ mit ihren Anforderungen und Analysewünschen sind:

Vielleicht wollen sie zusätzlich die Absatzzahlen pro Kunde nach Verkaufsort aufsummieren?

Vielleicht sollen die Ist- und Planabsätze nicht nur je Artikel, sondern auch je Artikelgruppe gegenübergestellt werden?

Vielleicht sollen die Istabsätze für die folgenden Monate prognostiziert werden, wozu man die Absatzhistorie benötigt?

Zum einen sind solche zusätzlichen Fragestellungen insbesondere für Mitarbeiter in Führungspositionen teilweise nur mit großem Detailwissen über das Tool und die zur Verfügung stehenden Daten zu beantworten, und zum anderen müssen eventuell weitere Datenquellen eingebunden werden, wodurch die Komplexität des Systems steigt. Und was ist, wenn das Unternehmen im Ausland eine Tochtergesellschaft gründet, die eine andere Software mit anders strukturierter Datenbank verwendet, und deren Daten in die Auswertung integriert werden sollen?

Zusammenfassend lässt sich festhalten, dass es sicherlich sinnvoll wäre, wenn:

die Daten nur aus einer Datenquelle (in Abbildung 1.4 als Data Warehouse bezeichnet) vom BI-Tool gelesen werden müssen und keine Attributverknüpfungen durch Endan­wender mehr notwendig sind,

die Datenquelle so strukturiert ist, dass Analysen mit unterschiedlichem Detaillierungsgrad problemlos möglich sind, zum Beispiel Umsätze pro Kunde oder Kundengruppe und pro Artikel oder Artikelgruppe, und

auch historische Daten bei Bedarf für Analysen zur Verfügung stehen.

Prägen Sie sich die Abbildung 1.4 gut ein, denn davon handelt letztendlich dieses Buch.

Abbildung 1.4: Datenanalyse mit Data Warehouse

Hier kommt jetzt das Data Warehouse ins Spiel. Dort werden die Daten der operativen Informationssysteme wie zum Beispiel der Auftragsverwaltung eines Onlineshops, des User-Tracking-Systems der Website, des Warenwirtschaftssystems, des Personalmanagements und der Finanzbuchhaltung gesammelt, für Auswertungen und Analysen vielfältiger Art angemessen strukturiert und stehen dann den Anwendern eines BI-Tools für ihre analytischen Aufgabenstellungen zur Verfügung.

Vielleicht fragen Sie sich an dieser Stelle, wie denn die Daten der MySQL-Datenbank, Oracle-Datenbank usw. in das Data Warehouse gelangen. Das ist Aufgabe des Prozesses »Extraktion, Transformation, Laden«, auf den in Kapitel 5 detailliert eingegangen wird.

Ohne Data-Warehouse-Systeme sind die Steuerung betrieblicher Geschäftsprozesse und die Durchführung dispositiver und strategischer Entscheidungsprozesse in einem Unternehmen kaum noch denkbar.

Self-Service-BI-Lösungen auf Desktop-Ebene sind für prototypische oder begrenzte Auswertungen durchaus vertretbar. Belastbare, unternehmensweite Lösungen sollten aber auf Basis eines serverbasierten Data Warehouse implementiert werden.

Oder wollen Sie wirklich EXCEL-Tabellen zur Grundlage Ihrer unternehmerischen Entscheidungen machen?

Wenn personenbezogene Daten ins Spiel kommen

Die Notwendigkeit und wirtschaftliche Bedeutung von Datenanalysen mithilfe eines BI-Tools ist unbestritten. Dies gilt sowohl für die primären wertschöpfenden als auch für die sekundären unterstützenden Geschäftsprozesse in einem Unternehmen.

Wenn bei den Datenanalysen kein Personenbezug zum Beispiel zu Kunden, Lieferanten oder Mitarbeitern hergestellt werden kann, ist das alles unproblematisch. Wenn dieser Personenbezug allerdings gegeben ist, muss einiges beachtet werden:

Zum einen muss der/die Betroffene der Nutzung zugestimmt haben bzw. muss es ­Vereinbarungen oder Verträge geben, die das zulassen,

und zum anderen muss die Datenanalyse einem vordefinierten Zweck dienen und somit »erforderlich« sein.

Helfen kann in diesem Fall eine Pseudonymisierung oder besser Anonymisierung der Daten, damit keine Rückschlüsse auf die tatsächlich betroffenen Personen mehr bzw. nur mit hohem Aufwand möglich sind. Allerdings können pseudonymisierte Daten eventuell via statistischer Verfahren zurückgerechnet werden.

Beachten Sie bei Ihren Datenanalysen die Regelungen der EU-Datenschutzgrundverordnung (DSGVO) und das neue Bundesdatenschutzgesetz.

In Kapitel 7 kommen wir noch einmal auf dieses Thema zurück.

Kapitel 2

Das Data Warehouse im Umfeld der betrieblichen Informationssysteme

In diesem Kapitel

Hierarchie der betrieblichen ­Informationssysteme

Analytische Informationssysteme im Besonderen

Beispiele für analytische Informationssysteme

Bevor es in Kapitel 3 richtig mit dem Thema Data Warehouse losgeht, schauen wir in diesem Kapitel ein bisschen über den Tellerrand und betrachten diejenigen betrieblichen Informationssysteme