Cover

Titelblatt

WILEY END USER LICENSE AGREEMENT

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

image themenorientierte (subject-oriented),

image integrierte (integrated),

image chronologisch (time-variant) und

image 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:

image Extract: Bereitstellung der zu ladenden Daten aus den Quellsystemen

image Transform: Analyse, Bereinigung und Integration dieser Daten

image 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

image Data Vault und

image 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:

image Cube

image Dimension

image Hierarchie

image 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

image Reporting,

image Online Analytical Processing (OLAP) und

image 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.

image Sie besuchen eine Vorlesung oder einen Fortbildungskurs zu diesem Thema?

image 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?

image 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.

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

image 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.

image 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 …

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

image eine Vorlesung zu diesem Thema besuchen,

image 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:

image 10 wichtige Schritte zu Ihrem ersten Dashboard

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

image 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?

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.

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

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

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

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

image 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.

image Welche Artikel wurden von welchen Kunden gekauft?

image 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:

image Tabellenkalkulation

image Relationale Datenbank

image NoSQL-Datenbank

image 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:

image 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.

image Es gibt unterschiedliche Bezeichnungen für dieselben Daten.

image Es gibt gleiche Bezeichnungen für unterschiedliche Daten.

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

image 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:

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

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

image 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:

image 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,

image 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

image 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:

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

image 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.