Data Science

20 min. lesen

January 26, 2023

Einführung

Willkommen zurück zu unserer Tutorial-Serie über Data Warehousing! Beim letzten Mal haben wir Ihnen die Grundlagen des Data Warehousing vorgestellt, einschließlich Faktentabellen, Dimensionstabellen und Verwaltungstools.

In diesem zweiten Teil der Serie konzentrieren wir uns auf die Darstellung unseres bestehenden OLTP-Schemas, die Auswahl von Fakten- und Dimensionstabellen und die Definition der Busmatrix.

1. OLTP-Schema

In den allermeisten Fällen wird der Inhalt eines Data Warehouse aus einer normalisierten SQL-OLTP-Datenbank stammen. Um den Data Warehousing-Prozess besser zu verstehen, erstellen wir unser eigenes OLTP-Schema, das einer normalen operativen Datenbank eines Bekleidungshändlers ähnelt.

Die Grafik unten zeigt das Schema, wie wir es definiert haben. Für unser Tutorial konzentrieren wir uns auf die Tabellen, die rot markiert sind. Seien Sie sich bewusst, dass das Schema keineswegs perfekt ist, denn wir haben einige Abstriche gemacht, um es für das Tutorial übersichtlich und einfach zu halten.

Wir haben dann einen Generator erstellt, um die Tabellen mit künstlichen Daten zu füllen. Sie finden sowohl den Generator als auch die Ergebnisdateien auf unserem Github. Folgen Sie einfach den Anweisungen im Repository, um die OLTP-Datenbank einzurichten.

2. Aufbau der Bus-Matrix

Wie in unserem ersten Artikel, DataWarehousingLeitfaden - Kernkonzepte, beschrieben, kann die Erstellung des Sternschemas als ein vierstufiger Prozess betrachtet werden.

2.1. Geschäftsprozess auswählen

Unser OLTP-Schema enthält mehrere Prozesse, die potenzielle Kandidaten für Faktentabellen sind. Wir werden den Warehousing-Prozess am Beispiel des Verkaufsprozesses und der dazugehörigen Attribute wie Filialen und Mitarbeiter demonstrieren.

2.2. Deklarieren Sie das Korn

Bei der Deklaration des Grains möchten wir immer eine Faktentabelle mit dem atomarsten Grain haben, damit die Benutzer bei den Fragen, die sie stellen können, nicht eingeschränkt sind. Wir haben drei Hauptkandidaten für das Grain.

2.2.1. Getreide: Pro Verkaufstransaktion

Eine Verkaufstransaktion ist in unserem Fall dadurch definiert, dass ein Kunde ein oder mehrere Produkte kauft und diese in einem Zug bezahlt. Wenn wir das Grain auf dieser Ebene deklarieren, wird die Faktentabelle mit einer Zeile pro Verkaufstransaktion gefüllt. Aber wir können noch atomarer vorgehen.

2.2.2. Getreide: Pro Produkt bei einer Verkaufstransaktion

Wenn wir die Körnung auf Produktebene wählen, erhalten wir eine Zeile pro Produkt, das der Kunde in seiner Verkaufstransaktion gekauft hat. Der klare Vorteil ist, dass wir Informationen über das Produkt mit der Faktentabelle verknüpfen können. Das wäre nicht möglich, wenn unsere Faktentabelle auf der Ebene der Verkaufstransaktion definiert wäre, da die Verkaufstransaktion aus mehreren Produkten mit unterschiedlichen Eigenschaften besteht. Wir befinden uns jedoch noch nicht auf der atomarsten Ebene. Wenn ein Kunde drei Packungen der gleichen Socken kauft, hätten wir in unserem Fall immer noch eine Zeile für die Socken. Wir könnten also noch atomarer vorgehen.

2.2.3. Getreide: Pro Stück bei einer Verkaufstransaktion

Im Vergleich zur Deklaration des Korns auf Produktebene bringt die Definition auf Artikelebene keine Vorteile mit sich. Das könnte der Fall sein, wenn wir die Stücke in unserem Quellsystem verfolgen würden, aber das tun wir nicht.

Unser Zielschema wird durch unser Quellschema eingeschränkt! Da unser Quellschema keine Stücke verfolgt, können wir die Faktentabelle nicht mit zusätzlichen Informationen über sie verknüpfen. Die Deklaration des Grains auf der Ebene der Stücke bringt uns also keine Vorteile und schadet uns sogar, da sie die Anzahl der Zeilen in unserer Faktentabelle in die Höhe treibt.

Die richtige Wahl für uns ist eindeutig, das Korn auf Produktebene zu definieren.

2.3. Identifizierung der Dimensionen

Normalerweise ist ein Gespräch mit dem Unternehmen der richtige Weg, um geeignete Dimensionen für den Geschäftsprozess zu finden. Da wir kein Unternehmen haben, sehen wir uns stattdessen das Quellschema an. Ein Blick auf das Quellschema ergibt die folgenden Dimensionskandidaten:

• Datum

• Produkte

• Anbieter

• Verkauf

• Mitarbeiter

• speichert

• Währungen

Eine Datumsdimension wird fast immer angegeben, da Prozesse in der Regel einige Informationen darüber enthalten, wann sie stattgefunden haben. Da Produkte und Lieferanten voneinander abhängig sind, sollten sie miteinander verbunden werden. Das Gleiche gilt für Filialen und Währungen. Am besten ist es, die Dimensionen völlig unabhängig voneinander zu halten.

Scheuen Sie sich nicht, Tabellen miteinander zu verbinden, auch wenn dadurch die Dimensionstabelle vergrößert wird. Denken Sie daran, dass wir den Aufbau eines Schneeflockenschemas vermeiden wollen, denn Joins sind teuer. Wenn es um den Speicherbedarf geht, ist die Größe der Dimensionen im Vergleich zur Faktentabelle normalerweise vernachlässigbar.

Die Verkaufstabelle ist nichts anderes als die übergeordnete Tabelle oder die Kopfzeile für ein untergeordnetes Element oder eine Zeile, in unserem Fall die Verkaufsartikel. Da die Verkaufspositionen die Grundlage für unsere Faktentabelle sind, werden alle Attribute des Verkaufs an die Verkaufspositionen vererbt. Für die Vertriebsdimension bleibt nur ihre ID übrig, die wir anschließend auch in die Faktentabelle aufnehmen, um eine weitere Dimensionstabelle zu vermeiden. Die Verkaufsdimension ist ein Beispiel für eine degenerierte Dimension.

2.4. Identifizierung der Fakten

Als Fakten können wir die Messungen verwenden, die während des Prozesses, den wir erfassen, vorgenommen werden. Wir können auch Attribute anderer verwandter Tabellen verwenden, die berechnet und mit der Faktentabelle verknüpft werden können. In unserem Fall entscheiden wir uns für die folgenden Fakten:

• Menge

• regulärer Stückpreis

• Rabattierter Stückpreis

• Kauf Stückpreis

• Regulärer Gesamtpreis

• Gesamtrabattpreis

• Gesamtkaufpreis

• Gesamtumsatz

• Umsatzmarge

Unser Sternschema für die atomaren Verkäufe sieht folgendermaßen aus:

2.5. Aggregierte Faktentabellen hinzufügen

Aggregierte Faktentabellen sind keine absolute Notwendigkeit, können aber hinzugefügt werden, um zu einer besseren Leistung beizutragen. In unserem Fall fügen wir eine Faktentabelle für die täglichen Verkäufe hinzu, die als eine periodische Snapshot-Tabelle betrachtet werden kann. Um die täglichen Verkäufe zu erstellen, nehmen wir die atomare Faktentabelle und gruppieren sie nach Datum, Filiale und Produkt. Wir verlieren die Dimension Mitarbeiter, aber sie kann immer noch mit der atomaren Faktentabelle analysiert werden.

2.6. Bus-Matrix

Wenn Sie das Verfahren befolgen, erhalten Sie die folgende Bus-Matrix:

Die Definition der Dimensionen für alle Geschäftsprozesse führt zu einer Matrix, die es dem Data Engineering-Team schließlich ermöglicht, eine Reihe von konformen Dimensionen zu definieren. Dabei handelt es sich um Dimensionen, die von mehreren Faktentabellen gemeinsam genutzt werden und Analysen ermöglichen, die sich über die gesamte Wertschöpfungskette erstrecken. Die einzelnen Zeilen in der Bus-Matrix sollten nach und nach bearbeitet werden, wobei der neue Prozess schrittweise integriert wird und mit jeder Iteration einen greifbaren Mehrwert schafft.

Einpacken

Dieses Mal haben wir das Quellschema kennengelernt, auf dem unsere fiktive OLTP-Datenbank läuft. Außerdem haben wir gelernt, wie wir die Sternschemata und die Bus-Matrix anhand des Vier-Schritte-Prozesses erstellen.

In unserem nächsten Artikel werden wir Ihnen zeigen, wie wir die Tabellen für die Dimensionen und die Verkaufsdaten definieren. Wir sehen uns in Teil 3, DataWarehousingAnleitung - Definieren von Dimensionen und Faktentabellen.

Für den nächsten Teil des Tutorials klicken Sie hier

513

Anteile

131

Ansichten