Bridge Tables 101: Warum sie nützlich sind

Innerhalb des Data Vault gibt es spezielle Entitäten, die die Abfrageleistung auf dem Weg aus dem Data Vault heraus verbessern. Diese Entitäten werden zwischen dem Data Vault und dem Information Delivery Layer platziert und sind für Fälle notwendig, in denen viele Joins und Aggregationen auf dem Raw Data Vault ausgeführt werden, was Leistungsprobleme verursacht. Dies geschieht häufig beim Entwurf der virtualisierten Faktentabellen in den Information und Data Marts. Um die erforderliche Granularität in den Faktentabellen zu erreichen, ohne die Abfragezeit zu erhöhen, kommen Bridge-Tabellen ins Spiel. Brückentabellen gehören zum Business Vault und haben den Zweck, die Leistung zu verbessern, ähnlich wie die PIT-Tabelle die bereits in einem früheren Newsletter behandelt wurde.

Brückentabellen sind ein Mittel zur Erreichung ihrer Ziele, da sie die im Informationsbereitstellungsprozess häufig erforderliche Granularitätsverschiebung ermöglichen. Bevor wir uns jedoch näher mit den Besonderheiten der Verwendung von Brückentabellen für die Leistungsoptimierung befassen, ist es wichtig, zunächst die Granularität innerhalb einer data warehouse zu definieren.

Körnendefinitionen im Data Warehousing

Die Auflösung innerhalb eines dimensionalen Modells ist die für jede Tabelle verfügbare Detailstufe. So wird der Detaillierungsgrad einer Faktentabelle durch die Anzahl der zugehörigen Dimensionen definiert. Grundsätzlich gibt es drei verschiedene Arten von Granularitäten für Faktenentitäten innerhalb eines dimensionalen Modells.

Die erste ist die Faktentabelle der Transaktion, die einem Messereignis zu einem bestimmten Zeitpunkt in Raum und Zeit entspricht. Die Faktentabellen enthalten einen Fremdschlüssel für jede zugehörige Dimension und optional genaue Zeitstempel sowie degenerierte Dimensionsschlüssel. Es wird deutlich, dass die Struktur der Transaktionstabelle die Struktur der Transaktion selbst ist.

Die zweite ist die Faktentabelle des periodischen Schnappschusses. Die periodische Momentaufnahme ist eine Standardperiode, da sie Messereignisse über einen bestimmten Zeitraum zusammenfasst, der manchmal ein Tag, eine Woche usw. sein kann. Sie wird jedoch häufiger zur Erfassung von Lagerdaten verwendet, z. B. von Produktständen pro Tag. Ein Schnappschuss der Produktfüllstände wird zum Beispiel täglich erstellt, daher der Name.

Drittens sind akkumulierende Snapshot-Faktentabellen den periodischen Snapshot-Tabellen von ihrer Art her ähnlich. Im Gegensatz zur Meldung der Daten innerhalb eines bestimmten Zeitrahmens werden jedoch nur die Abweichungen nach dem ersten Snapshot gemeldet. In einer Faktenentität, die die Lagerbestände beschreibt, würde beispielsweise die erste Erstladung aller Produkte im ersten Snapshot enthalten sein. Nach dieser ersten Momentaufnahme würden in den nachfolgenden Momentaufnahmen nur noch die Deltas, die der ein- und ausgehenden Produkte, zu finden sein. Um die aktuellen Lagerbestände eines bestimmten Tages zu ermitteln, müssten also alle Daten bis zu diesem Tag aggregiert werden.

Vergleich mit Data Vault 2.0

Innerhalb von Data Vault enthalten rohe Data Vault-Link-Entities immer die feinstmögliche Körnung, nämlich die von der Quelle kommende. Dies ist darauf zurückzuführen, dass Data Vault Raw die ursprüngliche Granularität des Quellsystems ohne die beim Laden der Daten vorgenommenen Aggregationen erfasst. Innerhalb der Informationslieferung gibt es oft eine Zielgranularität, die durch Anforderungen des Unternehmens definiert ist. In vielen Fällen ist diese Zielgranularität nicht direkt im Data Vault-Modell zu finden. Daher muss diese Granularität von der Granularität des Data Vault-Modells abgeleitet werden.

Brückentabellen fungieren als übergeordnete faktenlose Faktentabelle und enthalten Hash-Schlüssel von den Knotenpunkten und Verbindungen, die sie überspannen. Eine weitere Leistungsverbesserung kann erreicht werden, indem ressourcenintensive Berechnungen in die Brückentabelle verlagert werden. Dies ist besonders wichtig, wenn virtuelle Information Marts auf dem Data Vault erstellt werden, da diese einige Berechnungen erfordern, die den Zugriff auf die virtualisierten Information Mart Entitäten verlangsamen. Mit Brückentabellen kann die Abfrageleistung drastisch verbessert werden. Brückentabellen müssen nicht die gleiche Körnung haben wie die Links, die sie abdecken. In diesen Fällen kann die Brückentabelle aggregierte Werte enthalten, die der Struktur hinzugefügt und mit GROUP BY-Anweisungen geladen werden. Die resultierende Brückentabelle hat eine höhere Auflösung als die in der Tabelle enthaltenen Links.

Gängige Geschäftsbeispiele für eine Kornverschiebung in einer Transaktionsfaktentabelle basieren auf Rechnungen. In diesem Beispiel benötigt der Geschäftsanwender einen Informationsmarkt, der Rechnungen in der Faktentabelle enthält. In den meisten Fällen bestehen Rechnungen aus Einzelposten (bekannt als abhängiger untergeordneter Schlüssel), und es sind diese Einzelposten, die im Raw Data Vault gespeichert würden, was zu einer feineren Körnung als in der Zielfaktentabelle führen würde. Um jedoch den gewünschten Detaillierungsgrad zu erreichen, müssen die Einzelposten zu Rechnungen aggregiert werden.

Hier ist die nicht-historisierter Link wird sehr hilfreich als Faktentabelle einer Transaktion kann typischerweise aus den nicht-historisierten Verknüpfungen abgeleitet werden. Wenn sie das ursprüngliche Grain der Transaktion speichern und wenn es dem Ziel-Grain entspricht, sind keine weiteren Aggregationen erforderlich. In unserem Beispiel der Rechnungen wird ein höheres Grain für die Transaktionsfaktentabelle benötigt. Um eine bessere Leistung zu erhalten, wäre eine Brückentabelle erforderlich, die die Kornverschiebung realisiert.

Die Körnung der abgebildeten Brückentabelle wird durch die Nabenreferenzen definiert. Zusätzlich wird die Brückentabelle enthält Link-Hash-Schlüssel und mit diesen können Link-Satelliten von der Brücke aus verbunden werden, um auf beschreibende Attribute zuzugreifen. Zusätzliche Attribute zur Messung speichern die Ergebnisse von Aggregationen. Das letzte Attribut der Brückentabelle ist das Snapshot-Datum, das durch das Ladeverfahren hinzugefügt wird. In einigen Fällen können die Snapshot-Daten Teil des Primärschlüssels sein, z. B. bei der kumulativen Umsatzverfolgung. In diesem Fall werden die Verkäufe pro Kunde, pro Filiale und pro (Snapshot-)Tag verfolgt. Das folgende Beispiel zeigt ein Beispiel für eine Bridge-Ladung.

SELECT 

                hk_invoice, 

                hk_Kunde, 

                hk_store,

                ? als SnapshotDate, 

                RechnungsNummer, 

               SUMME(Gesamt) 

FROM Link_Invoice inv

WENN NICHT VORHANDEN (

              SELECT 

                       1 

             VON 

                       DataVault.biz.BridgeInvoice tgt 

             WHERE 

                        inv.hk_invoice = tgt.hk_invoice AND 

                        inv.hk_Kunde = tgt.hk_Kunde AND 

                        inv.hk_store = tgt.hk_store AND

                        inv.SnapshotDate = tgt.SnapshotDate

)

GROUP BY hk_invoice, hk_customer, hk_store,SnapshotDate,InvoiceNumber;

'?' ist ein Parameter, der auf das Snapshot-Datum gesetzt wird. Zum Beispiel auf 6 Uhr morgens bei einer täglichen Brückenlast.

Schlussfolgerung

In diesem Artikel wird eine Data Vault-Entität vorgestellt, die für Kornverschiebungen im Rahmen der Informationsbereitstellung von wesentlicher Bedeutung ist. Mit Brückentabellen können Grain Shifts realisiert werden, um die Leistung für die erforderlichen Aggregationen und Join-Operationen zu steigern. Im Vorangegangenen wurden verschiedene Grain-Definitionen für Faktentabellen behandelt und die transaktionale Faktentabelle ausführlicher besprochen.

Das Geschäftsbeispiel hat gezeigt, wie eine solche Tabelle aussehen wird und wie man sie aufbaut. Da es nach Kimball noch zwei weitere Definitionen von "grain" für Faktentabellen gibt, wird in einem späteren Artikel erörtert, wie die periodischen Snapshot-Faktentabellen und die akkumulierenden Snapshot-Faktentabellen grain sind.

- Marc Winkelmann (Scalefree)

Updates und Support erhalten

Bitte senden Sie Anfragen und Funktionswünsche an [email protected]. 

Für Anfragen zu Data Vault-Schulungen und Schulungen vor Ort wenden Sie sich bitte an [email protected] oder registrieren Sie sich unter www.scalefree.com.

Um die Erstellung von Visual Data Vault-Zeichnungen in Microsoft Visio zu unterstützen, wurde eine Schablone implementiert, die zum Zeichnen von Data Vault-Modellen verwendet werden kann. Die Schablone ist erhältlich bei www.visualdatavault.com.