Notizen zur dimensionalen Modellierung

2020-05-14

In einem anderen Beitrag über Coronavirus-Berichte haben wir kurz das Thema Dimensionen angesprochen. Insbesondere haben wir über die temporale Dimension diskutiert. Da das dimensionale Modellieren ein grundlegendes Konzept im Data-Warehouse-Design ist, verdient es einen eigenen Beitrag.

Die temporale Dimension wird häufig verwendet und kommt praktisch in jedem Geschäfts- und Wissenschaftsbereich vor. Zeit/Datum wird häufig als Beispiel für eine übereinstimmende Dimension betrachtet. Am Ende wird der 7. November immer der 7. November sein und nicht der 25. Oktober, unabhängig vom Kontext [1].

In der Realität haben wir es in der Regel mit mehreren verschiedenen Zeit-/Datumsdimensionen zu tun – das Bestelldatum unterscheidet sich normalerweise vom Lieferdatum und vom Zahlungsdatum. Der Versuch, diese drei Fakten in einem Drill-across-Bericht mit einer einzigen „Datums“-Dimension zu kombinieren, wird zwangsläufig Unsinn erzeugen. Es handelt sich um drei verschiedene, übereinstimmende Dimensionen. In der Praxis ist es äußerst wichtig, verschiedene Arten von Daten oder Zeitstempeln klar zu unterscheiden.

Verstehen Sie Ihren Prozess

In einigen Fällen ist diese Unterscheidung relativ einfach, da der Unterschied aus dem Geschäftsprozess stammt. Im obigen Beispiel ist es für jeden leicht verständlich, dass die Lieferung nicht vor der Bestellung erfolgen kann und zwischen diesen beiden Ereignissen eine bemerkenswerte Verzögerung auftreten kann. Es ist offensichtlich, dass das Lieferdatum und das Bestelldatum zwei verschiedene Dinge sind. Dies ist ein grundlegendes Merkmal eines Geschäftsprozesses, den wir mit analytischen Tools beschreiben.

In anderen Fällen – die oft schwieriger zu handhaben sind – ergibt sich der Unterschied daraus, wie wir bestimmte Größen messen oder über Ereignisse berichten. Im zuvor beschriebenen Coronavirus-Beispiel waren wir wirklich daran interessiert, das Infektionsdatum zu kennen. Aber dies war kein Ereignis, das wir direkt überwachen oder messen konnten. Das Ereignis, das wir leicht überwachen konnten, war die Einreichung des Berichts über den identifizierten Fall. Zwischen den beiden Ereignissen besteht eine erhebliche Verzögerung. Darüber hinaus ist diese Verzögerung nicht konstant und kann von Fall zu Fall variieren. Sie hängt stark von den Details des gesamten Diagnose- und Meldeverfahrens ab. Diese Details und ihr Einfluss auf die Ergebnisse sollten einem Insider offensichtlich sein, sind dem Endnutzer der auf der Basis der gesammelten Daten erstellten Analyse jedoch sehr wahrscheinlich unbekannt.

Wie man online kauft, ohne eine Website zu besuchen

Betrachten wir einen Prozess des Kaufs in einem Online-Shop. In der Regel besucht ein Nutzer die Website, fügt einige Produkte zum Warenkorb hinzu, startet den Checkout, schließt diesen ab und bezahlt. Natürlich gibt es viele verschiedene Szenarien, aber der Einfachheit halber beschränken wir uns auf diese fünf Schritte. In einer idealen Welt können wir die Ereignisse, die jedem Schritt entsprechen, registrieren und mit einem Zeitstempel versehen. Sehr wahrscheinlich wird jeder der Schritte von einem anderen (Micro-)Service oder sogar von einem externen Anbieter verarbeitet. Die Daten über die Website-Besuche würden anders erfasst und gespeichert als die Daten über Zahlungen. Und natürlich könnte man über die Anzahl der Website-Besuche pro Tag und unabhängig davon über die Anzahl der Transaktionen pro Tag berichten.

Es ist nicht schwer herauszufinden, dass es einige Zeit vom Website-Besuch bis zur Zahlung dauert. Daher wird der Zeitstempel des Besuchsereignisses niemals derselbe wie der Zeitstempel des Zahlungsvorgangs sein. Es bedarf nicht viel, um zu erkennen, dass ein Nutzer viele Stunden auf der Website surfen, dann Produkte in den Warenkorb legen, diesen Warenkorb für weitere Stunden oder sogar Tage liegen lassen und erst dann mit dem Checkout fortfahren kann.

Offensichtlich gibt es keine einzige „Datums“-Dimension. Es gibt mehrere: Besuchsdatum, Transaktionsdatum usw. Wir können die Zahlen nach Besuchsdatum oder nach Transaktionsdatum berichten, aber wir können sie nicht austauschbar verwenden und sollten sie nicht miteinander vermischen. Logischerweise sollten wir die verschiedenen Arten von Daten und Zeitstempeln durch klare und konsistente Benennung im Data Warehouse eindeutig unterscheiden. Aber die Benennung ist ein Thema für sich, das wir eines Tages gesondert behandeln könnten.

Was ist mit anderen Dimensionen?

Während Zeit und Datum wichtig sind, sind sie nicht die einzigen Dimensionen, die typischerweise verwendet werden. Ein weiteres häufiges Beispiel für eine Dimension ist „Kunde“. Jedes Unternehmen hat Kunden. Aber „ein Kunde“ kann je nach Gesprächspartner eine unterschiedliche Bedeutung haben. In einem CRM-System speichert man oft sowohl aktuelle Kunden als auch potenzielle Kunden. Spricht man mit einem Vertriebsmitarbeiter oder einem Account Manager, würde er das Wort „Kunde“ für beide Gruppen verwenden. Für die Finanzabteilung ist „ein Kunde“ sehr wahrscheinlich jemand, dem sie eine Rechnung ausstellen können (oder in der Vergangenheit ausgestellt haben). Für die Rechtsabteilung ist „ein Kunde“ möglicherweise jemand, mit dem wir einen gültigen Vertrag haben – also keine potenziellen und keine ehemaligen Kunden. Eine andere Abteilung könnte ihn sogar definieren als „jemand, der in den letzten 3 Monaten bei uns gekauft hat“.

In diesem Fall können wir jedoch ein Superset aller „Kunden“ definieren. Dieses Superset wird alle potenziellen Kunden, aktuellen Kunden, ehemaligen Kunden usw. enthalten. Wenn es uns gelingt, alle relevanten Attribute für eine solche Kundendimension zu sammeln und wir einen einzigen Primärschlüssel zur Identifizierung eines Eintrags haben, haben wir eine übereinstimmende Dimension. Trotz der Tatsache, dass wir „Kunde“ in vielen verschiedenen Kontexten verwenden, haben wir eine einzige übereinstimmende Dimension, die wir verwenden können, um kohärente Drill-Across-Berichte zu erstellen.

Das Problem mit „Kunde“ ist nicht, dass er unterschiedliche Bedeutungen haben kann, sondern dass die Daten über Kunden in vielen verschiedenen Systemen vorhanden sind. Generell benötigen unterschiedliche Abteilungen – und folglich die Systeme, die sie verwenden – verschiedene Datensätze. Die Daten eines bestimmten Systems können unvollständig, veraltet oder schlicht falsch sein. Einige Daten in System A können den Daten in System B widersprechen. Daher benötigen wir neben einer einzigen Definition im Data Warehouse, was ein Kunde ist, auch eine einzige Quelle der Wahrheit über dessen Attribute. Aber das ist ein separates Thema des Master Data Managements.

1. 

Genauer gesagt ist der Zeitpunkt absolut und kontextunabhängig, aber seine Interpretation als (lokale) Zeit oder Datum ist es nicht. Insbesondere kann derselbe Zeitpunkt je nach verwendetem Kalendersystem als der 7. November oder der 25. Oktober interpretiert werden.

Read More