Heute sind Janine Ellner, Thomas Kopp, Fabian Hardt und ich nicht zum Kunden gefahren, sondern zur TH Köln (Campus Gummersbach). Wir haben dort eine Übung zu der Veranstaltung Betriebliche Anwendungssysteme 1 (BA1) gehalten.

Begonnen haben wir die Übung mit dem folgenden Architekturbild eines Data Warehouses:

DWH-Architektur.png

Der Sinn eines Data Warehouses ist die Konsolidierung und Aufbereitung verschiedener Datenquellen. Dies können hierbei ERP-Systeme, Flat Files, externe Schnittstellen und vieles mehr sein. Diese werden zunächst „“ in der Regel „“ 1:1 in die Staging Area geladen. Im Core-Data Warehouse werden die Daten aus der Staging Area klassicher Weiser in einem 3NF-Modell abgebildet. 3NF steht für die 3. Normalform und entspricht einem Normalisierungsgrad der Datenbank, welcher Redundanzen und Anomalien vermeidet.
Im Data Mart des Data Warehouses liegt der Fokus auf der Abbildung der fachlichen Welt. Hier bewegen wir uns im multidimensionalen Raum. Im Data Mart werden Dimensionen und Fakten aufgespannt, um so die Abfrageperformance für den Endanwender zu optimieren und eine einfache Auswertung der Daten zu ermöglichen.

Bevor die tatsächliche Modellierung beginnen konnte, haben wir Begriffe Dimensionen und Fakten noch einmal kurz erläutert. Dimensionen beschreiben ein Objekt, typische Beispiele hierfür sind Produkt, Kunde und die Zeit. Solche oder so ähnliche Dimensionen befinden sich in den meisten multidimensionalen Data Marts. Dimensionen enthalten Attribute, welche die Eigenschaften eines Objektes beschreiben. Dimensionen verändern sich über die Zeit und wenn man diese Veränderungen auch im Nachhinein betrachten möchte, benötigt man hierfür ein Historisierungskonzept. Dabei wird sehr häufig das Prinzip der „Slowly Changing Dimensions“ genutzt, insbesondere der Typ 2. In diesem Fall werden Gültigkeitsstempel beispielsweise „GÜLTIG_VON“ und „GÜLTIG BIS“ verwendet. Allerdings gibt es auch Data Warehouse-Systeme die stets nur den aktuellen Stand anzeigen und keine Historisierung benötigen.
Fakten hingegen enthalten Kennzahlen, also numerische und meist additive Werte.
Beispiele hierfür sind Anzahlen, Kosten und Mengen.  Der Primärschlüssel einer Faktentabelle setzt sich üblicherweise aus den Fremdschlüsseln zu den verknüpften Dimensionen zusammen. Wichtig bei Fakten ist die Granularität. Je atomarer die Faktentabelle aufgebaut wird, desto mehr Flexibilität hat der Anwender bei der Auswertung. Allerdings hat die Faktentabelle dadurch einen größeren Umfang und kann somit zu Performanceproblemen führen. Hier gilt es zwischen der fachlichen Notwendigkeit des Detailgrades und dem technischen Gegebenheiten abzuwägen.

Ziel der Übung war die Überführung eines Core-Datenmodells in ein Data Mart-Datenmodell.

Basierend auf dem folgenden Core-Datenmodell sollten die Studenten unter anderem folgende Fragestellungen mit einem Data Mart-Datenmodell abbilden:

  • Wie viele Buchungen gab es im letzten Monat?
  • Wie viele Buchungen gab es pro Agent im letzten Jahr?
  • Wie viele Stornierungen gab es im letzten Monat?

Core-Modell.png

Die Fragestellungen sind bewusst sehr unspezifisch gehalten, damit rege Diskussionen entstehen können.
Außerdem haben wir offen gelassen, ob ein Star- oder Snowflake Modell für den Data Mart entworfen werden soll. Allerdings sollten die Studenten Ihre Entscheidungen begründen können.

Bei einem Star Modell steht eine Faktentabelle im Zentrum und ist mit den dazugehörigen Dimensionen direkt verknüpft.

Star_Schema.png

Das Star-Modell ist dementsprechend ein denormalisiertes Modell. Es sind Redundanzen vorhanden und diese erzeugen einen etwas höheren Wartungsaufwand. Diesen nimmt man aber gern in Kauf, da die Queries eines Star-Modells weniger komplex sind als die eines Snowflake-Modells.

Das Snowflake-Modell ist eine Weiterentwicklung des Star-Modells. Hier werden die Dimensionen normalisiert, das heißt falls möglich in verschiedene Tabellen hinunter gebrochen.

Hier ein Beispiel für ein Snowflake-Modell:

Snowflake Schema.png

Dadurch, dass das Snowflake-Modell mehr Tabellen als das Star-Schema enthält, werden je nach fachlicher Fragestellung mehr Joins benötigt, um eine Query abzubilden.

Nach ungefähr einer Stunde Diskussionen, Austausch und Modellierungsarbeit haben wir gemeinsam die Ergebnisse besprochen. Wir haben bereits zu Beginn angekündigt, dass es vollkommen legitim ist, wenn die Gruppen unterschiedliche Ergebnisse hervorbringen. Auch unsere Lösung ist lediglich eine Beispiellösung, die auf verschiedenen Annahmen basiert.

Mart Modell.png

Mit dem obigen Datenmodell für den Data Mart können wir die Frage, wie viele Buchungen es im letzten Monat gab mit Hilfe der Tabelle Fact Booking (Booking Count) und der Dim Time (Month) abbilden. Um herauszufinden, wie viele Buchungen die jeweiligen Agenten im vergangenen Jahr getätigt haben, benötigen wir erneut die Fact Booking (Booking Count), die Dim Agent (Last Name) und die Dim Time (Year).

Damit wir die Anzahl der Stornierungen im letzten Monat berechnen können, benötigen wir den Cancellation Count aus der Fact Booking und dazu das Cancellation Date aus der Dim Booking.

Auch bei den Kennzahlen haben die Gruppen verschiedene Definitionen und Annahmen getroffen. In der Praxis würde man die Kennzahlendefinition mit dem Fachbereich des jeweiligen Unternehmens besprechen.

Wir hoffen, dass wir mit unserer Übung den Studenten unseren Alltag in der Praxis näher bringen konnten und der ein oder andere so viel Spaß an der Datenmodellierung hatte, dass er sich seine berufliche Zukunft in der BI-Welt vorstellen kann.

Clarissa

 

Alle Beiträge von clarissamoeller

Schreibe einen Kommentar