Verwendung von PIT und Bridge Tables in Business Vault-Entitäten

PIT und Bridge Tables

Willkommen zu einer weiteren aufschlussreichen Sitzung des Data Vault Friday. In diesem Blogbeitrag werden wir eine häufig gestellte Frage beantworten:

Ist es in der Data Vault-Architektur zulässig, erstellte PIT- und Bridge-Tabellen im Code der Business Vault-Geschäftsregeln zu verwenden/wiederzuverwenden?

Die kurze Antwort ist ja, aber lassen Sie uns in die Details eintauchen, um das Grundprinzip und die Funktionsweise von PIT-Tabellen (Point-In-Time) und Bridge-Tabellen im Kontext von Business Vault-Entitäten zu verstehen.

Zum Verständnis von PIT und Bridge Tables

Bevor wir ihre Verwendung erläutern, wollen wir kurz erklären, was PIT- und Bridge-Tabellen in der Data Vault-Architektur sind:

• PIT-Tabellen: Sie liefern eine Momentaufnahme von Daten zu einem bestimmten Zeitpunkt. Sie helfen dabei, Deltas und beschreibende Daten zu kombinieren, um Berechnungen oder Geschäftslogik zu ermöglichen, die einen bestimmten Schnappschuss erfordern.
• Bridge Tables: Diese werden in erster Linie verwendet, um Many-to-Many-Beziehungen aufzulösen und die Abfrageleistung bei großen Datensätzen zu verbessern.

Anwendung der Geschäftslogik in Business Vault

Bei der Data Vault fließen die Daten von der Roh Data Vault (RDV) zum Business Vault (BV) und schließlich an die Informationsmarkt (IM). Der Hauptunterschied liegt in der Granularität der Daten:

• Ladedatum: Im Raw Data Vault werden die Datenbatches durch ein Ladedatum identifiziert, das angibt, wann die Daten eingelesen wurden.
• Snapshot-Datum: Im Information Mart werden Daten häufig als Snapshots dargestellt, wobei jeder Snapshot die Daten zu einem bestimmten Zeitpunkt repräsentiert.

Der Business Vault befindet sich zwischen dem Raw Data Vault und den Information Marts. Bei der Anwendung von Geschäftsregeln in der BV gibt es zwei Haupttypen von Granularitäten zu berücksichtigen:

1. Granularität auf der Grundlage eingehender Deltas

In diesem Fall wird die Geschäftslogik auf alle eingehenden Deltas angewendet, die durch das Ladedatum identifiziert werden. Die Bereinigung von Telefonnummern ist beispielsweise ein typischer Anwendungsfall, bei dem jedes Delta (Update) verarbeitet werden muss, auch wenn am Ende nur die letzte Version benötigt wird.

Die resultierenden Daten werden in einem berechneten Satelliten in der Unternehmensdatenbank gespeichert. Der Primärschlüssel bleibt der Hash-Schlüssel der übergeordneten Entität und das Ladedatum.

2. Granularität auf Basis des Snapshot-Datums

Einige Geschäftslogiken erfordern Berechnungen für bestimmte Zeitpunkte. Zum Beispiel die Berechnung des Lebenszeitwerts eines Kunden:

• Der Lebenszeitwert steigt, wenn ein Kunde einen Kauf tätigt.
• Der Lebenszeitwert sinkt schrittweise, wenn im Laufe der Zeit keine Käufe getätigt werden.

In diesem Szenario muss der Wert auch dann täglich neu berechnet werden, wenn kein neues Delta eingeht. Diese Granularität stimmt mit dem Snapshot-Datum überein, das bereits in der PIT-Tabelle definiert ist. Indem Sie die PIT-Tabelle nutzen, können Sie den Lebensdauerwert in einem berechneten Satelliten mit einem Primärschlüssel aus dem übergeordneten Hash-Schlüssel und dem Snapshot-Datum berechnen und speichern.

Wiederverwendung von PIT-Tabellen

Beim Wechsel vom Ladedatum (Deltas) zum Snapshot-Datum (Snapshots) spielen die PIT-Tabellen eine entscheidende Rolle:

• PIT-Tabellen helfen bei der Verknüpfung von beschreibenden Daten aus Satelliten, um eine auf Momentaufnahmen basierende Ansicht der Daten zu erhalten.
• Sie ermöglichen die Anwendung von Geschäftsregeln auf die Granularität der ausgehenden Informationen (Snapshot-Datum).

Wenn Sie beispielsweise eine bestimmte Kennzahl wie den Lifetime Value eines Kunden berechnen möchten, bietet die PIT-Tabelle die erforderliche Granularität, um die Werte für jeden Tag, jede Stunde oder jede Minute zu berechnen, je nach Ihren Anforderungen.

Wiederverwendung von Bridge Tables

Brückentabellen können auch in Business Vault-Entitäten wiederverwendet werden, allerdings mit einer wichtigen Einschränkung:

Vermeiden Sie das Laden eines Bridge Table von einem anderen Bridge Table.

Warum? Die Kaskadierung von Bridge Tables kann zu sequentiellen Abhängigkeiten führen, die die Parallelisierung behindern. Die parallele Verarbeitung ist für die Leistung unerlässlich, insbesondere in Umgebungen mit hohem Datenaufkommen. Um diese Einschränkung zu umgehen, verwenden Sie Computed Aggregate Links.

Was ist eine berechnete Gesamtverbindung?

Ein Computed Aggregate Link ist im Wesentlichen ein Link mit vorberechneten Aggregationen. Dieses Konzept wird in der Data Vault-Methodik beschrieben und ermöglicht die effiziente Wiederverwendung von Aggregaten, ohne Bridge Tables miteinander zu verketten.

Wenn Sie z.B. eine neue Kennzahl auf der Grundlage der in einer Bridge Table gespeicherten Fakten berechnen wollen:

• Verwenden Sie die Bridge Table als VON Quelle für einen berechneten Satelliten.
• Hängen Sie die neue Maßnahme an die Bridge Table als Teil der Business Vault-Einheit an.

Dieser Ansatz vermeidet kaskadierende Abhängigkeiten und ermöglicht es Ihnen, Fakten zu erweitern oder komplexe Berechnungen durchzuführen.

Zusammenfassung der besten Praktiken

Im Folgenden finden Sie die wichtigsten Informationen zur Verwendung von PIT- und Brückentabellen in Business Vault-Entitäten:

• Ja, Sie können PIT-Tabellen wiederverwenden: Sie werden in der Regel verwendet, um Snapshot-Granularität für berechnete Satelliten bereitzustellen.
• Ja, Sie können Bridge-Tabellen wiederverwenden: Verwenden Sie sie sorgfältig, um kaskadierende Abhängigkeiten zu vermeiden.
• Verwenden Sie Computed Aggregate Links: Wenn Sie eine Bridge Table erweitern müssen, ist dies der empfohlene Ansatz, um Effizienz und Parallelisierung zu erhalten.
• Wechsel der Granularität: Achten Sie bei der Anwendung der Geschäftslogik auf den Übergang vom Ladedatum (deltagesteuert) zum Snapshot-Datum (snapshotgesteuert).

Abschließende Überlegungen

Zusammenfassend lässt sich sagen, dass PIT- und Bridge-Tabellen leistungsstarke Werkzeuge in der Data Vault-Architektur sind, insbesondere innerhalb des Business Vault. Sie ermöglichen komplexe Geschäftslogik, wie z. B. Snapshot-basierte Berechnungen, und sorgen gleichzeitig für Effizienz und Leistung. Durch die Einhaltung von Best Practices wie die Vermeidung von kaskadierenden Bridge Table-Lasten können Sie sicherstellen, dass Ihre Implementierung skalierbar und robust bleibt.

Das Video ansehen

Über den Vortragenden