23,99 €
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:
Seitenzahl: 328
Veröffentlichungsjahr: 2018
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
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
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 Warehouse 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
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 fachlichen 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 Speicherungsformen 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, wurde 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 Endanwender 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
