Besuchen Sie www.wiley.com/go/eula, um Wiley's E-Book-EULA einzusehen.
Data-Warehouse-Systeme für Dummies
Schummelseite
»Hilfe, ich habe morgen eine Prüfung mit dem Thema Data Warehouse und habe alles vergessen«! Vielleicht beruhigt und hilft die folgende kurze Zusammenstellung einiger »Basics«. Aber bitte nicht mit zur Klausur nehmen; es sei denn, die Schummelseite ist als Hilfsmittel erlaubt.
Was ist ein Data Warehouse
Ein Data Warehouse ist eine spezielle Datenbank zur Unterstützung betrieblicher Analyse- und Entscheidungsaufgaben, die eine einheitliche Sicht auf ursprünglich heterogene und verteilte Datenbestände ermöglicht. Inmon definiert ein Data Warehouse als eine
themenorientierte (subject-oriented),
integrierte (integrated),
chronologisch (time-variant) und
dauerhaft gespeicherte (nonvolatile)
Datensammlung zur Unterstützung von Management-Aufgaben. Kimbal sieht ein Data Warehouse als ein System, das operative Daten nach einem Extraktions-, Transformations- und Ladeprozess (ETL) konsistent und leicht zugänglich den Anwendern zu Analyse- und Auswertungszwecken zur Verfügung stellt, wobei es aus den zwei Komponenten ETL-System und Präsentationsbereich (für die Data-Warehouse-Daten) besteht.
Der ETL-Prozess ist ein grundsätzliches Merkmal für ein Data Warehouse. ETL steht für Extract – Transform – Load; damit werden die Daten (üblicherweise nur die geänderten) in mehr oder weniger kleinen Zeitabständen von den operativen Informationssystemen (Quellsysteme) in das Data Warehouse geladen:
Extract: Bereitstellung der zu ladenden Daten aus den Quellsystemen
Transform: Analyse, Bereinigung und Integration dieser Daten
Load: Speichern der Daten in den Datenstrukturen des Data Warehouse.
Datenmodell eines Data Warehouse
Anwenderseitig kann man sich ein Data Warehouse als eine Sammlung von (multidimensionalen) Datenwürfeln vorstellen.
Die Dimensionen, beispielsweise Kunden, Artikel, Datum, spannen den Datenwürfel auf. Das Innere des Datenwürfels sind die Fakten wie etwa der Absatz, die den Dimensionswerten zugeordnet sind. Dazwischen besteht ein funktionaler Zusammenhang, etwa
1000 = Absatz(Kunde x, Artikel y, 2018).
Modellierung eines Data Warehouse
Zur Modellierung eines Data Warehouse gibt es spezielle Methoden, etwa
Data Vault und
ADAPT.
Ein Data-Vault-Diagramm besteht aus Hubs, Satelliten und Links. Über Hubs werden den logischen Schlüsselattributen (business key) eines Entitätstyps (Kunden, Artikel usw.) systeminterne Schlüssel zugeordnet. Mit Links werden zwischen Hubs bestehende Beziehungen realisiert; dabei handelt es sich immer um M:N-Beziehungen. Satelliten enthalten beschreibende Attribute für Hubs und Links. Dabei besteht der Primärschlüssel aus dem systeminternen Schlüssel des Hubs bzw. Links und dem Ladedatum. Damit sind Datenänderungen nachvollziehbar.
Speziell auf die Modellierung multidimensionaler Datenstrukturen (hier: Datenwürfel) zugeschnitten ist ADAPT (Application Design for Analytical Processing Technologies). Es ermöglicht die Darstellung von Dimensionen mit Hierarchien und Hierarchiestufen, eventuell vorhandenen speziellen, vorgegebenen Werteausprägungen sowie von Fakten und deren Zuordnungen zu Dimensionen in einem Datenwürfel. Die wichtigsten, grundlegenden Modellierungselemente von ADAPT sind:
Cube
Dimension
Hierarchie
Hierarchiestufe (Level)
Relationale Modellierung eines Datenwürfels
Ein Datenwürfel kann mithilfe des Star-Schemas oder des Snowflake-Schemas auf eine relationale Datenbank abgebildet werden. Beim Star-Schema gibt es eine zentrale Faktentabelle, die über Fremdschlüsselbeziehungen mit den einzelnen Dimensionstabellen verknüpft ist. Diese Faktentabelle ist auch beim Snowflake-Schema vorhanden; der Unterschied zwischen Star- und Snowflake-Schema kommt zum Tragen, wenn eine Dimension mehrere Hierarchieebenen hat, wie beispielsweise Artikel und Artikelgruppe bei der Artikeldimension. Beim Star-Schema gibt es pro Dimension genau eine Tabelle; bei mehreren Hierarchieebenen ist dann die 3. Normalform relationaler Datenbanken verletzt. Das Snowflake-Schema sieht für jede Hierarchieebene eine eigene Tabelle vor. Sonderformen sind das Fact-Constellation-Schema, das Fullfact-Schema sowie das bei mehreren Datenwürfeln einsetzbare Galaxy-Schema.
Anwendungsgebiete für ein Data Warehouse
Die Anwendungsgebiete für ein Data Warehouse sind
Reporting,
Online Analytical Processing (OLAP) und
Data Mining.
Reports, auch in Form eines Dashboards, stellen die klassische Anwendungsform dar. Unter OLAP versteht man die explorative Ad-hoc-Analyse multidimensionaler Daten, die dabei nach verschiedenen Gesichtspunkten interaktiv und individuell aus dem zugrunde liegenden Datenbestand extrahiert, analysiert und aufbereitet werden können. Spezielle OLAP-Operatoren sind Roll-up, Drill-down sowie Slice und Dice. Beim Data Mining geht es darum, neue Erkenntnisse aus großen, bereits gespeicherten Datenmengen zu gewinnen. Gängige Methoden dabei sind die Assoziationsanalyse, Clusteranalyse, Klassifikation mit der Diskriminanzanalyse sowie Entscheidungsbaumverfahren.
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
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:
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?
Kapitel 1
Ein Beispiel zur Einführung
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.
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.
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.
Häufig zu finden ist die Darstellung von Kennzahlen in Ampel- oder Tachometerform
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).
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.
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.
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.
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.
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.
In Kapitel 7 kommen wir noch einmal auf dieses Thema zurück.