Entwerfen eines Data Warehouse-Schemas
Wie alle relationalen Datenbanken enthält ein Data Warehouse Tabellen, in denen die zu analysierenden Daten gespeichert werden. Am häufigsten werden diese Tabellen in einem Schema organisiert, das für mehrdimensionale Modellierung optimiert ist, wobei numerische Measures, die mit Ereignissen verknüpft sind, die als Fakten bezeichnet werden, durch die Attribute zugeordneter Entitäten über mehrere Dimensionen hinweg aggregiert werden können. Beispielsweise können Measures, die einer Bestellung zugeordnet sind (z. B. der bezahlte Betrag oder die Menge der bestellten Artikel), nach Attributen des Datums aggregiert werden, an dem der Verkauf stattgefunden hat, dem Kunden, der Filiale usw.
Tabellen in einem Data Warehouse
Ein gängiges Muster für relationale Data Warehouses ist, ein Schema zu definieren, das zwei Arten von Tabellen enthält: Dimensionstabellen und Faktentabellen.
Dimensionstabellen
Dimensionstabellen beschreiben Geschäftsentitäten wie Produkte, Personen, Orte und Datumswerte. Dimensionstabellen enthalten Spalten für Attribute einer Entität. Beispielsweise kann eine Kundenentität einen Vornamen, einen Nachnamen, eine E-Mail-Adresse und eine Postadresse haben (die aus einer Straßenadresse, einer Stadt, einer Postleitzahl und einem Land oder einer Region bestehen kann). Zusätzlich zu Attributspalten enthält eine Dimensionstabelle eine eindeutige Schlüsselspalte, die jede Zeile in der Tabelle eindeutig identifiziert. In der Tat ist es üblich, dass eine Dimensionstabelle zwei Schlüsselspalten enthält:
- Einen für das Data Warehouse spezifischen Ersatzschlüssel, der jede Zeile in der Dimensiontabelle im Data Warehouse eindeutig identifiziert – in der Regel eine inkrementierende Ganzzahl.
- Ein alternativer Schlüssel, häufig ein natürlicher oder geschäftlicher Schlüssel, der verwendet wird, um eine bestimmte Instanz einer Entität im Transaktionsquellsystem zu identifizieren, aus dem der Entitätsdatensatz stammt – z. B. einen Produktcode oder eine Kunden-ID.
Hinweis
Warum zwei Schlüssel? Es gibt einige gute Gründe:
- Das Data Warehouse kann mit Daten aus mehreren Quellsystemen gefüllt werden, was das Risiko doppelter oder inkompatibler Geschäftsschlüssel mit sich bringen kann.
- Einfache numerische Schlüssel funktionieren im Allgemeinen besser in Abfragen, die viele Tabellen verbinden – ein häufiges Muster in Data Warehouses.
- Attribute von Entitäten können sich im Laufe der Zeit ändern – z. B. kann ein Kunde seine Adresse ändern. Da das Data Warehouse verwendet wird, um historische Berichte zu unterstützen, können Sie für jede Instanz einer Entität einen Datensatz zu mehreren Zeitpunkten aufbewahren. So werden z. B. Bestellungen für einen bestimmten Kunden für die Stadt gezählt, in der er zum Zeitpunkt der Bestellung gelebt hat. In diesem Fall würden mehrere Kundendatensätze denselben Geschäftsschlüssel aufweisen, der dem Kunden zugeordnet ist, aber verschiedene Ersatzschlüssel für jede separate Adresse, unter der der Kunde zu verschiedenen Zeiten lebte.
Ein Beispiel für eine Dimensionstabelle für Kunden könnte die folgenden Daten enthalten:
| CustomerKey | CustomerAltKey | Name | Straße | Stadt | PostalCode | CountryRegion | |
|---|---|---|---|---|---|---|---|
| 123 | I-543 | Navin Jones | navin1@contoso.com | 1 Main St. | Seattle | 90000 | USA |
| 124 | R-589 | Mary Smith | mary2@contoso.com | 234 190. Ave | Buffalo | 50001 | USA |
| 125 | I-321 | Antoine Dubois | antoine1@contoso.com | 2 Rue Jolie | Paris | 20098 | Frankreich |
| 126 | I-543 | Navin Jones | navin1@contoso.com | 24 125. Ave. | New York | 50000 | USA |
| ... | ... | ... | ... | ... | ... | ... | ... |
Hinweis
Beachten Sie, dass die Tabelle zwei Datensätze für Navin Jones enthält. Beide Datensätze verwenden denselben alternativen Schlüssel, um diese Person (I-543) zu identifizieren, aber jeder Datensatz hat einen anderen Ersatzschlüssel. Daraus können Sie ableiten, dass der Kunde von Seattle nach New York gezogen ist. Verkäufe an den Kunden, während er in Seattle lebte, sind mit dem Schlüssel 123 verknüpft, während Einkäufe nach dem Umzug nach New York in Datensatz 126 erfasst sind.
Zusätzlich zu Dimensionstabellen, die Geschäftsentitäten darstellen, enthält ein Data Warehouse üblicherweise eine Dimensiontabelle, die Zeit darstellt. Mit dieser Tabelle können Data Analysts Daten über zeitliche Intervalle aggregieren. Je nach Art der zu analysierenden Daten kann die niedrigste Granularität (als Aggregationsintervall bezeichnet) einer Zeitdimension Zeiten (stunden-, sekunden-, millisekunden-, nanosekundengenau oder noch genauer) oder Datumsangaben darstellen.
Ein Beispiel für eine Zeitdimensionstabelle mit einem Aggregationsintervall auf der Datumsebene könnte die folgenden Daten enthalten:
| DateKey | DateAltKey | DayOfWeek | DayOfMonth | Wochentag | Month | MonthName | Quarter | Year |
|---|---|---|---|---|---|---|---|---|
| 19990101 | 01-01-1999 | 6 | 1 | Freitag | 1 | January | 1 | 1999 |
| ... | ... | ... | ... | ... | ... | ... | ... | ... |
| 20220101 | 01-01-2022 | 7 | 1 | Samstag | 1 | January | 1 | 2022 |
| 20220102 | 02-01-2022 | 1 | 2 | Sonntag | 1 | January | 1 | 2022 |
| ... | ... | ... | ... | ... | ... | ... | ... | ... |
| 20301231 | 31-12-2030 | 3 | 31 | Tuesday | 12 | Dezember | 4 | 2030 |
Der Zeitbereich, der von den Datensätzen in der Tabelle abgedeckt wird, muss die frühesten und neuesten Punkte in der Zeit für alle zugeordneten Ereignisse enthalten, die in einer verknüpften Faktentabelle aufgezeichnet wurden. Normalerweise gibt es einen Datensatz für jedes Intervall im entsprechenden Aggregationsintervall dazwischen.
Faktentabellen
In Faktentabellen werden Details der Beobachtungen oder Ereignisse gespeichert. Dabei kann es sich beispielsweise um Bestellungen, Lagerbestände, Wechselkurse oder Temperaturaufzeichnungen handeln. Eine Faktentabelle enthält Spalten für numerische Werte, die nach Dimensionen aggregiert werden können. Zusätzlich zu den numerischen Spalten enthält eine Faktentabelle Schlüsselspalten, die auf eindeutige Schlüssel in verknüpften Dimensionstabellen verweisen.
Beispielsweise kann eine Faktentabelle, die Details von Bestellungen enthält, folgende Daten enthalten:
| OrderDateKey | CustomerKey | StoreKey | ProductKey | OrderNo | LineItemNo | Quantity (Menge) | UnitPrice (Stückpreis) | Tax (Steuern) | ItemTotal |
|---|---|---|---|---|---|---|---|---|---|
| 20220101 | 123 | 5 | 701 | 1001 | 1 | 2 | 2,50 | 0.50 | 5.50 |
| 20220101 | 123 | 5 | 765 | 1001 | 2 | 1 | 2.00 | 0,20 | 2,20 |
| 20220102 | 125 | 2 | 723 | 1002 | 1 | 1 | 4,99 | 0.49 | 5.48 |
| 20220103 | 126 | 1 | 823 | 1003 | 1 | 1 | 7,99 | 0.80 | 8.79 |
| ... | ... | ... | ... | ... | ... | ... | ... | ... | ... |
Die Dimensionsschlüsselspalten einer Faktentabelle bestimmen ihr Aggregationsintervall. Die Faktentabelle für Bestellungen enthält beispielsweise Schlüssel für Datumsangaben, Kunden, Filialen und Produkte. Eine Bestellung könnte mehrere Produkte enthalten, sodass das Aggregationsintervall Rechnungspositionen für einzelne Produkte darstellt, die an bestimmten in Filialen Tagen an Kunden verkauft werden.
Data Warehouse-Schemaentwürfe
In den meisten in Geschäftsanwendungen verwendeten Transaktionsdatenbanken werden die Daten normalisiert, um die Duplizierung zu verringern. In einem Data Warehouse werden die Dimensionsdaten jedoch im Allgemeinen denormalisiert, um die Anzahl der Verknüpfungen zu verringern, die zum Abfragen der Daten erforderlich sind.
Häufig wird ein Data Warehouse als Sternschema organisiert, in dem eine Faktentabelle direkt mit den Dimensionstabellen verknüpft ist. Beispiel:
Die Attribute einer Entität können verwendet werden, um Measures in Faktentabellen über mehrere Hierarchieebenen zu aggregieren – z. B., um den Gesamtumsatz nach Land oder Region, Stadt, Postleitzahl oder individuellem Kunden zu finden. Die Attribute für jede Ebene können in derselben Dimensionstabelle gespeichert werden. Wenn eine Entität jedoch eine große Anzahl hierarchischer Attributebenen aufweist, oder wenn einige Attribute von mehreren Dimensionen gemeinsam genutzt werden können (z. B. haben Kunden und Filialen eine gemeinsame geografische Adresse), kann es sinnvoll sein, eine Normalisierung auf die Dimensionstabellen anzuwenden und ein Schneeflockenschema zu erstellen, wie im folgenden Beispiel gezeigt:
In diesem Fall wurde die DimProduct-Tabelle normalisiert, um separate Dimensionstabellen für Produktkategorien und Lieferanten zu erstellen, und eine DimGeography-Tabelle wurde hinzugefügt, um geografische Attribute für Kunden und Filialen darzustellen. Jede Zeile in der DimProduct-Tabelle enthält Schlüsselwerte für die entsprechenden Zeilen in den Tabellen DimCategory und DimSupplier; und jede Zeile in den Tabellen DimCustomer und DimStore enthält einen Schlüsselwert für die entsprechende Zeile in der DimGeography-Tabelle.