Dimension (Data Warehouse)

Eine Dimension ist eine Struktur, die Fakten und Kennzahlen kategorisiert , um Nutzern die Beantwortung geschäftlicher Fragestellungen zu ermöglichen. Häufig verwendete Dimensionen sind Personen, Produkte, Ort und Zeit. ^{[ 1 ] [ 2 ]} (Anmerkung: Personen und Zeit werden manchmal nicht als Dimensionen modelliert.)

In einem Data Warehouse liefern Dimensionen strukturierte Kennzeichnungsinformationen für ansonsten ungeordnete numerische Messwerte. Eine Dimension ist ein Datensatz, der aus einzelnen, sich nicht überschneidenden Datenelementen besteht . Die Hauptfunktionen von Dimensionen sind dreifach: Filtern, Gruppieren und Kennzeichnen.

Diese Funktionen werden oft als „ Slicing und Dice “ bezeichnet. Ein gängiges Beispiel für ein Data Warehouse verwendet den Umsatz als Kennzahl, wobei Kunde und Produkt als Dimensionen dienen. Bei jedem Verkauf erwirbt ein Kunde ein Produkt. Die Daten können zunächst segmentiert werden, indem alle Kunden bis auf eine bestimmte Gruppe entfernt werden, und anschließend nach Produkt gruppiert und weiter unterteilt werden.

Ein dimensionales Datenelement ist vergleichbar mit einer kategorialen Variable in der Statistik.

Typischerweise sind Dimensionen in einem Data Warehouse intern in einer oder mehreren Hierarchien organisiert. „Datum“ ist eine gängige Dimension mit mehreren möglichen Hierarchien:

• „Tage werden in Monate (die in Jahre) gruppiert werden.“
• „Tage werden in Wochen (die wiederum in Jahre) unterteilt.“
• „Tage werden in Monate unterteilt, die wiederum in Quartale unterteilt sind, die wiederum in Jahre unterteilt sind.“
• usw.

Eine sich langsam ändernde Dimension ist eine Menge von Datenattributen, die sich im Laufe der Zeit langsam ändern, anstatt sich regelmäßig zu ändern, z. B. Adresse oder Name. Diese Attribute können sich im Laufe der Zeit ändern und werden dann zu einer sich langsam ändernden Dimension zusammengefasst. Diese Dimensionen können in verschiedene Typen klassifiziert werden:

• Typ 0 (Original beibehalten) : Attribute ändern sich nie. Keine Historie.
• Typ 1 (Überschreiben) : Alte Werte werden durch neue Werte für das Attribut überschrieben. Keine Historie.
• Typ 2 (Neue Zeile hinzufügen) : Es wird eine neue Zeile mit einem Start-/Enddatum oder einer Version für einen neuen Wert erstellt. Dadurch wird ein Verlauf erzeugt.
• Typ 3 (Neues Attribut hinzufügen) : Für einen neuen Wert wird eine neue Spalte erstellt. Der Verlauf ist auf die Anzahl der für die Speicherung historischer Daten vorgesehenen Spalten beschränkt.
• Typ 4 (Verlaufstabelle hinzufügen) : In einer Tabelle wird der aktuelle Wert gespeichert, während der Verlauf in einer zweiten Tabelle gespeichert wird.
• Typ 5 (Kombinierter Ansatz 1 + 4) : Kombination aus Typ 1 und Typ 4. Die Historie wird über eine zweite Historientabelle erstellt.
• Typ 6 (Kombinierter Ansatz 1 + 2 + 3) : Kombination aus Typ 1, Typ 2 und Typ 3. Die Historie wird über separate Zeilen und Attribute erstellt.
• Typ 7 (Hybridansatz) : Es werden sowohl ein Ersatzschlüssel als auch ein natürlicher Schlüssel verwendet. ^{[ 3 ]}

Eine konforme Dimension ist ein Satz von Datenattributen, die in mehreren Datenbanktabellen physisch referenziert werden, indem derselbe Schlüsselwert verwendet wird, um auf dieselbe Struktur, dieselben Attribute, Domänenwerte, Definitionen und Konzepte zu verweisen. Eine konforme Dimension umfasst viele Fakten.

Dimensionen gelten als konform, wenn sie entweder exakt übereinstimmen (einschließlich der Schlüssel) oder eine eine echte Teilmenge der anderen ist. Am wichtigsten ist, dass die Zeilenüberschriften zweier verschiedener Ergebnissätze derselben konformen Dimension(en) perfekt übereinstimmen müssen.

Konforme Dimensionen sind entweder identisch oder exakte mathematische Teilmengen der detailliertesten Dimension. Dimensionstabellen sind nicht konform, wenn die Attribute unterschiedlich bezeichnet sind oder unterschiedliche Werte enthalten. Konforme Dimensionen gibt es in verschiedenen Ausführungen. Im einfachsten Fall bedeuten konforme Dimensionen mit jeder möglichen Faktentabelle, mit der sie verknüpft sind, exakt dasselbe. Die Datumsdimension, die mit den Verkaufsdaten verknüpft ist, ist identisch mit der Datumsdimension, die mit den Lagerdaten verknüpft ist. ^{[ 4 ]}

Eine Junk-Dimension ist eine praktische Gruppierung von Flags und Indikatoren mit typischerweise geringer Kardinalität. Durch die Erstellung einer abstrakten Dimension werden diese Flags und Indikatoren aus der Faktentabelle entfernt und in ein sinnvolles Dimensionsgerüst überführt. ^{[ 5 ]} Eine Junk-Dimension ist eine Dimensionstabelle, die Attribute enthält, die weder in die Faktentabelle noch in eine der bestehenden Dimensionstabellen gehören. Diese Attribute sind üblicherweise Text oder verschiedene Flags, z. B. nicht-generische Kommentare oder einfache Ja/Nein- bzw. Wahr/Falsch-Indikatoren. Solche Attribute bleiben typischerweise übrig, nachdem alle offensichtlichen Dimensionen im Geschäftsprozess identifiziert wurden. Der Entwickler steht dann vor der Herausforderung, diese Attribute, die nicht in die anderen Dimensionen passen, sinnvoll zu platzieren.

Eine Lösung bestünde darin, für jedes der verbleibenden Attribute eine neue Dimension zu erstellen. Aufgrund ihrer Beschaffenheit könnte dies jedoch eine große Anzahl neuer Dimensionen erfordern, was zu einer Faktentabelle mit sehr vielen Fremdschlüsseln führen würde. Alternativ könnte der Entwickler die verbleibenden Attribute in der Faktentabelle belassen. Dies könnte jedoch die Zeilenlänge der Tabelle unnötig vergrößern, beispielsweise wenn es sich bei einem Attribut um eine lange Textzeichenfolge handelt.

Die Lösung für diese Herausforderung besteht darin, alle Attribute zu identifizieren und sie anschließend in einer oder mehreren Hilfsdimensionen zusammenzufassen. Eine Hilfsdimension kann mehrere Indikatoren vom Typ „wahr/falsch“ oder „ja/nein“ enthalten, die nicht miteinander korreliert sind. Daher ist es sinnvoll, die Indikatoren in ein aussagekräftigeres Attribut umzuwandeln. Ein Beispiel wäre ein Indikator, der angibt, ob ein Paket angekommen ist: Anstatt dies als „ja“ oder „nein“ anzugeben, würde er in der Hilfsdimension in „angekommen“ oder „ausstehend“ umgewandelt. Der Entwickler kann die Dimensionstabelle so erstellen, dass sie alle Indikatoren enthält, die mit jedem anderen Indikator vorkommen, sodass alle Kombinationen abgedeckt sind. Dadurch ergibt sich eine feste Tabellengröße von 2^{^x} Zeilen, wobei x die Anzahl der Indikatoren ist. Diese Lösung eignet sich für Situationen, in denen der Entwickler mit vielen verschiedenen Kombinationen rechnet und die Anzahl der möglichen Kombinationen auf ein akzeptables Maß begrenzt ist. Wenn die Anzahl der Indikatoren groß ist und dadurch eine sehr große Tabelle entsteht oder wenn der Entwickler nur mit wenigen möglichen Kombinationen rechnet, ist es sinnvoller, jede Zeile in der Junk-Dimension bei Auftreten neuer Kombinationen zu erstellen. Um die Tabellengröße zu begrenzen, können in anderen Situationen, abhängig von der Korrelation zwischen den verschiedenen Indikatoren, mehrere Junk-Dimensionen sinnvoll sein.

Junk-Dimensionen eignen sich auch zur Speicherung von Attributen wie nicht-generischen Kommentaren aus der Faktentabelle. Solche Attribute können Daten aus einem optionalen Kommentarfeld enthalten, das beim Aufgeben einer Bestellung durch einen Kunden verwendet wird und daher in vielen Fällen leer ist. Die Junk-Dimension sollte daher eine einzelne Zeile enthalten, die die leeren Werte als Ersatzschlüssel repräsentiert. Dieser Schlüssel wird in der Faktentabelle für jede Zeile verwendet, die mit einem leeren Kommentarfeld zurückgegeben wird. ^{[ 6 ]}

Eine degenerierte Dimension ist ein Schlüssel, wie beispielsweise eine Transaktionsnummer, Rechnungsnummer, Ticketnummer oder Frachtbriefnummer, der keine Attribute besitzt und daher keiner tatsächlichen Dimensionstabelle zugeordnet werden kann. Degenerierte Dimensionen sind sehr häufig, wenn die Granularität einer Faktentabelle einen einzelnen Transaktionsposten oder eine einzelne Position darstellt, da die degenerierte Dimension den eindeutigen Identifikator des übergeordneten Elements repräsentiert. Degenerierte Dimensionen spielen oft eine wichtige Rolle im Primärschlüssel der Faktentabelle. ^{[ 7 ]}

Dimensionen werden häufig für mehrere Anwendungen innerhalb derselben Datenbank wiederverwendet. Beispielsweise kann eine „Datum“-Dimension sowohl für das „Verkaufsdatum“ als auch für das „Lieferdatum“ oder das „Einstellungsdatum“ verwendet werden. Dies wird oft als „Rollenspieldimension“ bezeichnet. Die Implementierung erfolgt über eine Ansicht derselben Dimensionstabelle.

Dimensionstabellen verweisen üblicherweise nicht über Fremdschlüssel auf andere Dimensionen. In diesem Fall wird die referenzierte Dimension als Auslegerdimension bezeichnet. Auslegerdimensionen gelten als Anti-Pattern im Data Warehouse: Es empfiehlt sich, Faktentabellen zu verwenden, die die beiden Dimensionen miteinander verknüpfen. ^{[ 8 ]}

Eine angepasste Dimension wird als verkleinerte Dimension bezeichnet, wenn sie eine Teilmenge der Zeilen und/oder Spalten der ursprünglichen Dimension enthält. ^{[ 9 ]}

Eine spezielle Dimension kann verwendet werden, um Datumsangaben mit einer Granularität von einem Tag darzustellen. Datumsangaben werden in einer Faktentabelle als Fremdschlüssel einer Datumsdimension referenziert. Der Primärschlüssel der Datumsdimension kann ein künstlicher Schlüssel oder eine Zahl im Format JJJJMMTT sein.

Die Datumsdimension kann weitere Attribute wie die Kalenderwoche oder Kennzeichnungen für Arbeitstage, Feiertage usw. enthalten. Sie kann auch spezielle Zeilen für unbekannte oder noch zu definierende Daten umfassen. Die Datumsdimension sollte mit allen benötigten Daten initialisiert werden, beispielsweise mit den Daten der nächsten 10 Jahre oder mehr, falls erforderlich, oder mit vergangenen Daten, wenn Ereignisse in der Vergangenheit berücksichtigt werden.

Zeitangaben werden üblicherweise am besten als Zeitstempel in der Faktentabelle dargestellt . ^{[ 10 ]}

Bei der Referenzierung von Daten aus einem Metadatenregister wie ISO/IEC 11179 werden Darstellungsbegriffe wie „Indikator“ (ein boolescher Wert, wahr/falsch) und „Code“ (eine Menge sich nicht überschneidender Aufzählungswerte) typischerweise als Dimensionen verwendet. Beispielsweise würde im National Information Exchange Model (NIEM) der Name des Datenelements „PersonGenderCode“ lauten, und die Aufzählungswerte könnten „männlich“, „weiblich“ und „unbekannt“ sein.

Im Data Warehousing ist eine Dimensionstabelle eine der Begleittabellen zu einer Faktentabelle .

Die Faktentabelle enthält Geschäftsfakten (oder Kennzahlen) und Fremdschlüssel , die auf Kandidatenschlüssel (normalerweise Primärschlüssel ) in den Dimensionstabellen verweisen.

Im Gegensatz zu Faktentabellen enthalten Dimensionstabellen beschreibende Attribute (oder Felder), die typischerweise Textfelder (oder diskrete Zahlen, die sich wie Text verhalten) sind. Diese Attribute dienen zwei wichtigen Zwecken: der Einschränkung und/oder Filterung von Abfragen sowie der Kennzeichnung von Abfrageergebnissen.

Dimensionsattribute sollten wie folgt lauten:

• Ausführlich (Beschriftungen bestehen aus vollständigen Wörtern)
• Beschreibend
• Vollständig (ohne fehlende Werte)
• Diskret bewertet (mit nur einem Wert pro Dimensionstabellenzeile)
• Qualitätssicherung (ohne Rechtschreibfehler oder unmögliche Werte)

Die Zeilen einer Dimensionstabelle werden eindeutig durch ein einzelnes Schlüsselfeld identifiziert. Es wird empfohlen, für das Schlüsselfeld eine einfache Ganzzahl zu verwenden, da ein Schlüsselwert sonst bedeutungslos ist und nur zum Verknüpfen von Feldern zwischen Fakten- und Dimensionstabelle dient. Dimensionstabellen verwenden häufig Primärschlüssel, die gleichzeitig als Ersatzschlüssel fungieren. Ersatzschlüssel werden oft automatisch generiert (z. B. eine „Identitätsspalte“ in Sybase oder SQL Server, eine Serialisierung in PostgreSQL oder Informix, eine Oracle-Sequenz oder eine mit AUTO_INCREMENT in MySQL definierte Spalte).

Die Verwendung von Ersatzdimensionsschlüsseln bietet mehrere Vorteile, darunter:

• Leistung . Die Join-Verarbeitung wird durch die Verwendung eines einzigen Feldes (des Ersatzschlüssels ) wesentlich effizienter gestaltet.
• Pufferung von betrieblichen Schlüsselverwaltungspraktiken. Dies verhindert Situationen, in denen entfernte Datensätze wieder auftauchen könnten, wenn ihre natürlichen Schlüssel nach einer längeren Inaktivitätszeit wiederverwendet oder neu zugewiesen werden.
• Kartierung zur Integration unterschiedlicher Quellen
• Umgang mit unbekannten oder nicht anwendbaren Verbindungen
• Verfolgung von Änderungen der Werte von Dimensionsattributen

Obwohl die Verwendung von Ersatzschlüsseln eine Belastung für das ETL- System darstellt, kann die Pipeline-Verarbeitung verbessert werden, und ETL-Tools verfügen über eine integrierte verbesserte Verarbeitung von Ersatzschlüsseln.

Ziel einer Dimensionstabelle ist es, standardisierte, einheitliche Dimensionen zu erstellen, die im gesamten Data-Warehouse -Umfeld des Unternehmens gemeinsam genutzt werden können und die Verknüpfung mit mehreren Faktentabellen ermöglichen, welche verschiedene Geschäftsprozesse repräsentieren.

Konforme Dimensionen sind für den unternehmensweiten Charakter von DW/BI-Systemen wichtig, weil sie Folgendes fördern:

• Konsistenz. Jede Faktentabelle wird konsistent gefiltert, sodass die Abfrageergebnisse einheitlich gekennzeichnet werden.
• Integration. Abfragen können verschiedene Prozessfaktentabellen separat durchsuchen und die Ergebnisse anschließend über gemeinsame Dimensionsattribute verknüpfen.
• Verkürzte Entwicklungszeit bis zur Markteinführung. Die gängigen Abmessungen sind verfügbar, ohne sie neu erstellen zu müssen.

Im Laufe der Zeit können sich die Attribute einer bestimmten Zeile in einer Dimensionstabelle ändern. Beispielsweise kann sich die Lieferadresse eines Unternehmens ändern. Kimball bezeichnet dieses Phänomen als langsam veränderliche Dimension . Strategien zum Umgang mit dieser Art von Änderung lassen sich in drei Kategorien einteilen:

• Typ eins: Überschreiben Sie einfach den/die alten Wert(e).
• Typ zwei: Fügen Sie eine neue Zeile mit dem/den neuen Wert(en) hinzu und unterscheiden Sie die Zeilen mithilfe von Tupel-Versionierungstechniken .
• Typ drei: Fügen Sie der bestehenden Zeile ein neues Attribut hinzu.

Quelle: ^{[ 11 ]}

Da viele Faktentabellen in einem Data Warehouse Zeitreihen von Beobachtungen darstellen, sind häufig eine oder mehrere Datumsdimensionen erforderlich. Ein Grund für Datumsdimensionen ist die Speicherung von Kalenderinformationen im Data Warehouse anstatt deren fester Codierung in einer Anwendung. Ein einfacher SQL- Datums-/Zeitstempel liefert zwar genaue Informationen über den Zeitpunkt der Datenerfassung, kann aber keine Informationen über Feiertage, Geschäftsjahre usw. liefern. Dennoch kann ein SQL-Datums-/Zeitstempel in der Faktentabelle nützlich sein, da er präzise Berechnungen ermöglicht.

Die gleichzeitige Speicherung von Datum und Uhrzeit in derselben Dimension kann schnell zu einer sehr großen Dimension mit Millionen von Zeilen führen. Bei hohem Detailgrad empfiehlt es sich, Datum und Uhrzeit in zwei oder mehr separate Dimensionen aufzuteilen. Eine Zeitdimension mit einer Auflösung von Sekunden pro Tag umfasst beispielsweise nur 86.400 Zeilen. Die Auflösung von Datums- und Zeitdimensionen kann je nach Bedarf feiner oder feiner gewählt werden. So können Datumsdimensionen beispielsweise auf Jahr, Quartal, Monat oder Tag genau sein, während Zeitdimensionen auf Stunden, Minuten oder Sekunden genau sein können.

Als Faustregel gilt, dass die Dimension „Tageszeit“ nur dann erstellt werden sollte, wenn hierarchische Gruppierungen erforderlich sind oder wenn es aussagekräftige Textbeschreibungen für Zeiträume innerhalb des Tages gibt (z. B. „Abendverkehr“ oder „Frühschicht“).

Wenn die Zeilen einer Faktentabelle aus verschiedenen Zeitzonen stammen, kann es sinnvoll sein, Datum und Uhrzeit sowohl in lokaler Zeit als auch in Standardzeit zu speichern. Dies lässt sich realisieren, indem man für jede benötigte Datums-/Uhrzeitdimension zwei Dimensionen verwendet – eine für die lokale Zeit und eine für die Standardzeit. Die Speicherung von Datum und Uhrzeit in beiden Zeitzonen ermöglicht die Analyse, wann Fakten lokal und global erstellt werden. Als Standardzeit kann eine globale Standardzeit (z. B. UTC ), die lokale Zeit des Unternehmenssitzes (z. B. MEZ ) oder eine andere sinnvolle Zeitzone gewählt werden.

• Kategorische Variable
• Data Warehouse
• Entartete Dimension
• Sich langsam ändernde Dimension
• Faktentabelle
• ISO/IEC 11179
• Messung (Data Warehouse)
• Metadaten