Free Press

Dimensionale Modellierung (DM) ist Teil der von Ralph Kimball entwickelten Business Dimensional Lifecycle-Methodik, die eine Reihe von Methoden, Techniken und Konzepten für den Einsatz im Data Warehouse-Design umfasst. Der Ansatz konzentriert sich darauf, die wichtigsten Geschäftsprozesse innerhalb eines Unternehmens zu identifizieren und diese zuerst zu modellieren und zu implementieren, bevor weitere Geschäftsprozesse hinzugefügt werden, ein Bottom-up-Ansatz.

Was sind die Ziele der Data-Warehouse-Modellierung?

Die Ziele, die von Ross und Kimball dargelegt wurden, sind einfach:

• Informationen leicht zugänglich machen
• Informationen konsistent darstellen
• Anpassungsfähig und aufnahmefähig für Veränderungen
• Informationen zeitnah darstellen
• Informationsbestände schützen
• als maßgebliche und vertrauenswürdige Grundlage für eine bessere Entscheidungsfindung dienen (einzige Quelle der Wahrheit in der Sprache des Data Engineering)
• die VIPs müssen Ihr System akzeptieren

Wenn Sie an einem ETL-System gearbeitet oder es benutzt haben, werden Sie festgestellt haben, dass die Informationskonsistenz durch konforme Maßnahmen erreicht wird, dass die Aktualität durch ETL-Zyklen gewährleistet wird und dass die Anpassungsfähigkeit auch weitgehend vom ETL-Design abhängt.

Warum Modellierung?

Als Dateningenieur kennen Sie SQL sehr gut und können wahrscheinlich den ganzen Tag lang SQL-Abfragen schreiben. Aber Sie können nicht davon ausgehen, dass der typische Endbenutzer ein Experte im Schreiben von SQL-Abfragen ist. Unser Ziel ist es daher, ein DW zu entwickeln, das es Analysten ermöglicht, schnell und effektiv Analyseabfragen zu schreiben.

Das, was Sie nicht wollen, dass Ihre Analysten tun:

• Abfragen basierend auf ID
• Kaskadierende äußere Joins (selbst Sie würden das nicht tun wollen)
• gruppierte oder verbundene mehrfache Unterabfragen
• rekursive Unterabfragen (besuchen Sie einfach Hackerrank SQL und Sie würden die Schmerzen verstehen)
• Unterabfragekorrelation: Abrufen von Daten über mehrere Spalten in verschiedenen Unterabfragen
• Joins ohne PK/FK: selbst für mich (1.5 Jahre DE-Erfahrung), ist es schwer zu visualisieren.

Dinge, die Sie von Ihren Analysten erwarten könnten und sollten:

• einfache Joins
• Spalten mit Namen und umfassendem Text
• einfache Aggregation
• analytische gefensterte Funktionen
• DISTINCT

Beachten Sie, dass die oben genannten Punkte nicht einfach sind und dass Ihr System für all diese Arten von Abfragen ausreichend skalierbar sein sollte.

Die OLTP-Datenbanken werden aufgrund der vorgenannten Ziele in Fakten und Dimensionen umgewandelt.

Umstellung von Transaktionsdatenbanken auf Fakten

Die meisten Unternehmen messen ihren Erfolg und ihre Effizienz anhand bestimmter Datentypen. Diese Daten erfassen die tatsächlichen Geschäftsaktivitäten und den Fortschritt. Diese Daten werden als Fakten bezeichnet.

Die OLTP-orientierten Datenbanken zeichnen Transaktionen zu einem bestimmten Zeitpunkt auf, ähnlich wie Event-Streaming, aber zentralisiert um Transaktionen herum. Die DW ist anders. DW muss keine Details auf der Transaktionsebene aufzeichnen. Die DW muss Fakten über verschiedene Kriterien Ihres Unternehmens enthalten. Das DW muss die Informationen aggregieren (oder von Analysten aggregieren lassen), die zur Verbesserung des Geschäfts erforderlich sind. Redundanz ist also eine unverzeihliche Sünde im DW.

Was sind Kennzahlen und warum sollten Sie Ihre Faktentabellen mit ihnen füllen?

In einem Data Warehouse ist eine Kennzahl eine Eigenschaft, mit der Berechnungen durchgeführt werden können.

Die Fakten, die wir aus den operativen Datenspeichern ableiten, enthalten einige zusätzliche Daten, die in der Regel in unserer Analyse summiert werden. Dies sind die Aspekte eines Fakts, die es dem Analysten oder der Führungskraft, die die Analyse betrachtet, ermöglichen, den Wert des Fakts zu erkennen.

Warum müssen Sie eine konsistente Struktur beibehalten?

Damit Sie sicherstellen können, dass Ihr System Fakten legitim korrelieren und aggregieren kann.

Aber es ist nicht immer möglich, Daten auf atomaren Ebenen zu haben. Um diese Lücke zu schließen, gibt es zwei Methoden:

• Periodische Snapshot-Faktentabellen
• Akkumulierende Snapshot-Faktentabellen

Periodische Snapshot-Faktentabellen

Wie der Name schon sagt, werden sie in regelmäßigen Zeitabständen erhoben. Gasverbrauch, Audit und Inspektionen sind einige Beispiele für die Datenerfassung, für die periodische Snapshots aktiviert sind.

Akkumulierende Snapshot-Faktentabellen

Wenn es sich bei einem Business Performance Indicator um die Abschlussrate eines mehrstufigen Geschäftsprozesses handelt, möchten Sie vielleicht die Gesamtheit des Prozesses erfassen und den Start, den Abschluss und die Schritte dazwischen aufzeichnen. Dies mag zwar transaktionsbezogen sein, aber dazwischen gibt es eine Menge Maßnahmen. Sie verwenden also akkumulierende Snapshot-Faktentabellen, um komplexe Fragen in Business Intelligence zu beantworten, bei denen zwischen den Fakten Zeit vergeht. Ein gutes Beispiel wäre eine Faktentabellenzeile, in der Sie ein Hähnchensandwich bestellen, und die Faktentabellenzeile, in der die Tüte am Drive-Thru von McDonald’s durch das Autofenster gereicht wird.

Fakten über Dimensionen lokalisieren

Sie und Ihre Analysten müssen wissen, wie sie Fakten abfragen und filtern können, um daraus Business Intelligence abzuleiten. Diesem Zweck dienen Dimensionen.

Dimensionen aus Referenz- und Rohdaten ableiten

Dimensionen werden fast immer mit einem Surrogatschlüssel erstellt; der Surrogatschlüssel wird natürlich durch den Fremdschlüssel (oder die Fremdschlüssel) in der Faktentabelle referenziert. Wir durchsuchen die Tabelle, indem wir die Dimensionen suchen, an denen wir interessiert sind. Alle anderen Daten, die unsere Fakten beschreiben, wie z. B. Zeitstempel, Kundenvertreter, Standort des Geschäfts, Produkt und Kunde, werden in Dimensionen umgewandelt.

Das Schöne an der Dimensionsmodellierung ist, dass Fakten nicht durch die Primärschlüssel oder irgendeine Art von eindeutigem Bezeichner definiert werden, sondern durch die Kombination von Dimensionen. Daraus ergibt sich das Star Schema.

Es ist sehr wichtig, dass wir eine Eindeutigkeit in unseren Dimensionen haben. Wenn wir Abfragen über Fakten machen, werden Duplikate zwischen Dimensionskombinationen zu einer Katastrophe. Wenn das nicht möglich ist, fügen Sie Dimensionen hinzu oder aggregieren Sie sie, um sie eindeutig zu machen.

Hierarchie in Dimensionen

Betrachten Sie die folgenden beiden Bilder.

Ein Analytiker wird ein leichtes Leben haben, wenn Sie die zweite Dimensionstabelle für ihn einrichten.

Mit der zweiten Tabelle haben Sie also folgende Hierarchie:

Es gibt alle Arten von Hierarchien – Mehrfachhierarchien, Einfachhierarchie usw. Auf sie gehe ich in diesem Blogbeitrag nicht ein.

Eine Sache, auf die ich hinweisen möchte, ist, dass die Zeitdimension eine echte Qual ist. Man muss sich um die magischen Tage, den Fiskalkalender, die Zeitzonen, die Zyklen (Gewinn über Quartalstypen) kümmern. Und seien Sie in dieser Hinsicht nicht lausig oder übermütig, selbst Zeitreihendatenbanken werden Ihnen bei Hierarchien nicht helfen, wenn Ihr ETL verkorkst ist. Werfen Sie einen Blick auf Outrigger-Dimensionen. Es gibt auch Fälle, in denen eine Dimension natürlich von einer anderen abhängig ist. In einem solchen Fall können die Designer einen Fremdschlüssel von der einen zur anderen Dimension setzen. Dies ist eine „Outrigger-Dimension“. Bei Kalenderdimensionen ist dies sehr häufig der Fall.

Sie können in einer Outrigger-Dimension kein Datum verwenden, das nicht mit dem in der Faktentabelle verwendeten Datum übereinstimmt. Sie können keine Aggregation über Outrigger-Dimensionen zulassen. Wenn nötig, maskieren Sie numerische Werte im Outrigger mit textuellen Präfixen oder Suffixen, um dies zu verhindern.

Slowly Changing Dimensions

So gerne ich auch darüber schreiben würde, so denke ich doch, dass es für meine Leser besser ist, wenn sie dieses Konzept von hier aus gründlich verstehen.

Ich spreche hier nicht über Snowflake-Dimensionen, sondern möchte nur darauf hinweisen, dass sie immer noch in OLAP-Datenbanken verwendet werden.

Integrieren Sie Ihre Big Data in Ihr ETL-System

Sie werden Ihre tabellarischen Big Data so behandeln, als wären sie durch eine Ihrer Standard-Extraktionsphasen gewonnen worden. Sie werden also die gleichen Schritte wie bei der Transformation durchführen:

1. Datenbereinigung
2. Konforme Einheiten und Formate
3. Deduplizierung
4. Umstrukturierung
5. Staging

Zusammenfassung

Ich wollte die theoretischen Aspekte des Datenbankdesigns verstehen, was mich dazu brachte, das Buch von Ross und Kimball zu lesen. Dann wurde ich neugierig, um Unterschiede und Analogien zwischen ihren Methoden und denen der heute führenden datengesteuerten Unternehmen wie Netflix, Airbnb, Uber usw. zu finden.

In diesem Bestreben kann ich mit Fug und Recht behaupten, dass das strukturierte Format der dimensionalen Modellierung einem reinen Hardcore-ETL vorzuziehen ist. Denn auf diese Weise beseitigen Sie die Abhängigkeit von Ihnen, Ihr BI-Team ruft Sie nicht auf Slack an, um für jeden weiteren Einblick eine neue DAG zu erstellen, sondern Sie versetzen es mit der richtigen Modellierung in die Lage, frei zu handeln und zu erforschen, ohne dass Sie es brauchen.

Bitte hinterlassen Sie mir Feedback, wie ich mich verbessern kann, ich bin mir sicher, dass dies nicht Ihre beste Lektüre war. Danke für Ihre Zeit.

Fußnoten

https://en.wikipedia.org/wiki/Dimensional_modeling

https://en.wikipedia.org/wiki/Measure_(data_warehouse)

Ross und Kimball, Kap. 2 und Kap. 18

Kimball/Ross S. 103-109