Wiederverwendete Business Keys in Data Vault 2.0 mit dem Business Vault auflösen

Einführung

In der Welt der Datenmodellierung besteht eine der Herausforderungen für Unternehmen in der Verwaltung von Tabellen mit Business Keys (BKs), die im Laufe der Zeit wiederverwendet werden. Dieses Problem tritt in der Regel auf, wenn ein Unternehmen aufgrund technischer Einschränkungen im Quellsystem Primärschlüssel oder "eindeutige Bezeichner" im Laufe der Zeit wiederverwendet. Diese Praxis kann zu Mehrdeutigkeit führen, insbesondere wenn historische Daten die für analytische Zwecke benötigt werden. In diesem Blogbeitrag erfahren Sie, wie Sie mit Data Vault 2.0 wiederverwendete BKs auflösen können, indem Sie den Business Vault nutzen.

Verstehen der Data Vault 2.0 Architektur

Data Vault 2.0 wird oft als eine Modellierungstechnik angesehen, aber es handelt sich um eine vollständige Lösung, die Methodik, Architektur, Implementierung und Modellierung umfasst.

Werfen wir einen Blick auf die untenstehende Architektur:

 

1. Der erste Schritt besteht darin, die Daten aus den Quellsystemen zu extrahieren und die Daten in ihrem Rohformat in einen Staging-Bereich zu laden.
2. Als Nächstes können Sie bei Bedarf harte Regeln anwenden, z. B. Datentypänderungen.
3. Dann laden Sie die Daten in den Raw Vault und modellieren die Daten in Hubs, Links, Satellites usw.
4. Wenn Sie Geschäftslogik auf Ihre Daten in mehr als einem Anwendungsfall anwenden müssen, können Sie den Raw Vault erweitern, indem Sie einen Business Vault erstellen.
5. Der letzte Schritt ist die Erstellung der Information Marts (IMs), die für Berichte/Dashboarding-Zwecke verwendet werden. Die IM-Tabellen oder -Ansichten werden mit Raw Vault/Business Vault erstellt und können z.B. mit der Dimensionsmodellierung von Kimball modelliert werden. Lesen Sie diesen anderen Blog als Referenz: https://xebia.com/blog/kimball-dimensional-modelling/ .

Schauen wir uns ein Beispiel an

Nehmen wir an, wir sind ein E-Commerce-Unternehmen und möchten die Daten unserer Bestellungen analysieren. Der Bestellcode wird im Laufe der Zeit immer wieder verwendet. In diesem Szenario haben wir normalerweise eine Quelltabelle für den Bestellkopf und eine weitere für die Bestellpositionen.

Auftragskopf:

auftrag_code	auftrag_datum	kunde _code	ship_to_city
1111	10/10/2024	A	Almere
1112	11/10/2024	B	Amsterdam
1111	12/11/2024	D	Breda

Artikel bestellen:

auftrag_code	zeilen_code	artikel_code	Menge	Betrag
1111	1	AB	1	32
1111	2	BC	2	34.99
1111	3	DF	10	56
1112	1	BC	5	70
1112	2	XS	1	5
1111	1	DE	20	251.95

 

Das Business Intelligence (BI)-Team erwartet, dass sie zwei Information Mart-Tabellen haben, eine für den Auftragskopf und eine für die Auftragspositionen, und sie müssen in der Lage sein, diese für Berichtszwecke zu verbinden. Außerdem möchten sie die gesamten historischen Änderungen verfolgen können.

Um festzustellen, welche Auftragspositionen mit den einzelnen Auftragsköpfen verknüpft sind, würden wir normalerweise den Fremdschlüssel zu order_code in der Tabelle order items überprüfen und so den kompletten Auftrag rekonstruieren.

Wenn wir uns jedoch die Auftragskopftabelle genauer ansehen, stellen wir fest, dass der order_code "1111" an einem anderen Datum wiederverwendet wurde. Dadurch wird es kompliziert zu bestimmen, welche Artikelcodes im Laufe der Zeit mit jedem order_code verbunden sind.

Die logische Lösung in diesem Fall besteht darin, einen Primärschlüssel (PK) in der Tabelle Auftragskopf zu erstellen, der jeden Auftrag im Laufe der Zeit eindeutig identifiziert. Derselbe Wert sollte als Fremdschlüssel (FK) in die Tabelle der Auftragspositionen eingefügt werden. Indem wir das Bestelldatum als Teil des Primärschlüssels einfügen, können wir die Eindeutigkeit sicherstellen und erhalten eine Tabelle mit den erwarteten Ergebnissen, wie unten gezeigt:

im_order_header:

pk_bestellung_code	auftrag_code	auftrag_datum	kunden_code	ship_to_city
1111 || 10/10/2024	1111	10/10/2024	A	Almere
1112 || 11/10/2024	1112	11/10/2024	B	Amsterdam
1111 || 12/11/2024	1111	12/11/2024	D	Breda

 

im_order_items:

pk_bestellung_linie_code	fk_bestellung_code	auftrag_code	zeilen_code	Artikel_code	Menge	Betrag
1111 || 10/10/2024 || 1	1111 || 10/10/2024	1111	1	AB	1	32
1111 || 10/10/2024 || 2	1111 || 10/10/2024	1111	2	BC	2	34.99
1111 || 10/10/2024 || 3	1111 || 10/10/2024	1111	3	DF	10	56
1112 || 11/10/2024 || 1	1112 || 11/10/2024	1112	1	BC	5	70
1112 || 11/10/2024 || 2	1112 || 11/10/2024	1112	2	XS	1	5
1111 || 12/11/2024 || 1	1111 || 12/11/2024	1111	1	DE	20	251.95

 

In den nächsten Abschnitten erfahren Sie, wie Sie Data Vault 2.0 verwenden können, um diese Ausgabe zu erhalten.

Der rohe Tresor

Gehen wir davon aus, dass Ihre Daten bereits extrahiert und im Staging-Bereich verfügbar sind. Der nächste Schritt besteht darin, die Daten in den Raw Vault zu laden. In diesem Blog werden wir nicht im Detail auf die verschiedenen Strukturen eingehen, die im Data Warehouse nach den Prinzipien von Data Vault 2.0 erstellt werden können, wie z.B. Hubs, Links und Satelliten. Nachfolgend finden Sie eine mögliche Lösung für die Modellierung der Auftragsdaten.

 

Nachdem Sie Ihre Satelliten erstellt haben, sehen Sie die unten stehenden Informationen. In Data Vault 2.0 wird empfohlen, Hash Keys (HK) zu verwenden, um Datensätze eindeutig zu identifizieren und konsistente Verknüpfungen zwischen Tabellen sicherzustellen. Hash Keys bieten eine bessere Leistung bei Joins im Vergleich zu textbasierten Datentypen.

rv_sat__order_header:

hk_order	auftrag_code	auftrag_datum	kunden_code	ship_to_city	load_date	end_date
MD5(1111)	1111	10/10/2024	A	Almere	10/10/2024	12/11/2024
MD5(1112)	1112	11/10/2024	B	Amsterdam	11/10/2024	NULL
MD5(1111)	1111	12/11/2024	D	Breda	12/11/2024	NULL

rv_sat__order_items:

hk_order	hk_order_line	auftrag_code	zeilen_code	artikel_code	Menge	Betrag	load_date	end_date
MD5(1111)	MD5(1111 || 1)	1111	1	AB	1	32	10/10/2024	12/11/2024
MD5(1111)	MD5(1111 || 2)	1111	2	BC	2	34.99	10/10/2024	12/11/2024
MD5(1111)	MD5(1111 || 3)	1111	3	DF	10	56	10/10/2024	12/11/2024
MD5(1112)	MD5(1112 || 1)	1112	1	BC	5	70	11/10/2024	NULL
MD5(1112)	MD5(1112 || 2)	1112	2	XS	1	5	11/10/2024	NULL
MD5(1111)	MD5(1111 || 1)	1111	1	DE	20	251.95	12/11/2024	NULL

 

Jetzt müssen wir also Folgendes bedenken:

1. Derselbe Bestellcode ist nur einmal im Satelliten aktiv (mit end_date gleich NULL).
2. Wenn Sie diese Satelliten verwenden, um Ihre Information Marts-Tabellen oder -Ansichten zu erstellen, müssen Sie unbedingt darauf achten, dass nur die aktiven Datensätze berücksichtigt werden und historische Daten ausgeschlossen werden. Wenn Sie nicht nach aktiven Datensätzen filtern, führt dies zu nicht eindeutigen Primärschlüsseln, so dass es unmöglich ist, die Kopf- und Artikelmodelle korrekt zu verknüpfen.

Das Unternehmen muss historische Daten analysieren, um fundierte Entscheidungen zu treffen. Wenn wir uns das erwartete Ergebnis ansehen, sehen wir, dass die eindeutige Zuordnung des Primärschlüssels die Anwendung von Geschäftslogik erfordert. Beide Tabellen müssen eine Kombination aus order_code und order_date als eindeutigen Bezeichner verwenden. Die Rohdaten für die Bestellpositionen enthalten jedoch keine Datumsangaben. In diesem Szenario haben wir die folgenden Möglichkeiten:

1. Bitten Sie den Datenanbieter, die Datumsinformationen in die Quelltabelle der Auftragspositionen aufzunehmen. Dies kann sehr zeitaufwendig sein und ist manchmal nicht möglich.
2. Nachdem Sie die Daten in den Raw Vault geladen haben, erstellen Sie eine Geschäftslogik, um die Kombination aus Bestellcode und Bestelldatum in die Artikelinformationen aufzunehmen. Dies kann mit Hilfe des Business Vault geschehen.
3. Das Zusammenführen der Kopf- und Elementtabelle vor dem Laden der Daten in den Raw Vault ist keine Option, da dies gegen die Data Vault 2.0-Standards verstoßen würde, die besagen, dass Sie im Staging Layer nur harte Regeln anwenden sollten.
4. Das Zusammenführen der Kopf- und Artikeldaten nach dem Laden der Daten in den Raw Vault im Information Mart ist ebenfalls nicht ideal, da es die Berichtsebene komplexer und redundanter macht. Die Geschäftslogik zur Kombination von Bestellcode und Bestelldatum müsste für jeden Anwendungsfall neu erstellt werden, was zu Inkonsistenzen führen würde.

Der Business Tresor

Der Business Vault ist eine Erweiterung des Raw Vault, die besonders nützlich ist, wenn Sie eine Geschäftslogik anwenden müssen, die für mehrere Anwendungsfälle benötigt wird. Er muss so implementiert werden, dass Sie denselben Ersatzschlüssel sowohl für den Bestellkopf als auch für die Bestellpositionen haben.

bv__order_header:

Der bv__order_header ist eine Erweiterung des rv_sat__order_header. Um sie zu erstellen, müssen Sie einen Ersatzschlüssel generieren und das Enddatum auf der Grundlage des vorherigen load_date-Werts für jeden Ersatzschlüssel neu berechnen. Dieser Ansatz ermöglicht es Ihnen, Fälle zu behandeln, in denen zwei order_code-Werte, wie z.B. "1111", gleichzeitig gültig sind. Nachfolgend sehen Sie ein Beispiel für den Code und wie die Business Vault Auftragskopftabelle aussehen würde:

with
  unique_key as (
    select
      order_code,
      order_date,
      concat (bk_order_code, ' || ', order_date) as bk_order_code,
      customer_code,
      ship_to_city,
      load_date
    from
      rv_sat__order_header
  ),
  end_date_calculation as (
    select
      *,
      lead (load_date) over (
        partition by
          bk_order_code
        order by
          load_date
      ) as end_date
    from
      unique_key
  )
select
  bk_order_code,
  order_date,
  customer_code,
  ship_to_city,
  load_date,
  coalesce(end_date, '9999-12-31') as end_date
from
  end_date_calculation

 

auftrag_code	auftrag_datum	bk_bestellung_code	kunden_code	ship_to_city	load_date	end_date
1111	10/10/2024	1111 || 10/10/2024	B	Almere	10/10/2024	11/10/2024
1111	10/10/2024	1111 || 10/10/2024	A	Almere	11/10/2024	31/12/9999
1112	11/10/2024	1112 || 11/10/2024	B	Amsterdam	11/10/2024	12/10/2024
1112	11/10/2024	1112 || 11/10/2024	B	Amsterdam	12/10/2024	31/12/9999
1111	12/11/2024	1111 || 12/11/2024	D	Breda	12/11/2024	31/12/9999

 

bv__order_items:

Eine ähnliche Logik gilt für die Erstellung der Business Vault-Tabelle für rv_sat__order_items, aber zuerst müssen Sie denselben Surrogatschlüssel aus dem zuvor erstellten Business Vault-Bestellkopf hinzufügen. Hier noch einmal ein Codebeispiel und wie die Business Vault-Tabelle für Auftragspositionen aussehen würde:

with
  sat_order_items as (
    select
      order_code,
      line_code,
      item_code,
      quantity,
      amount,
      load_date
    from
      rv_sat__order_items
  ),
  bv_order_header as (
    select
      *
    from
      bv__order_header
  ),
  add_unique_key as (
    select
      sat_order_items.*,
      bv_order_header.bk_order_code,
      concat (
        bv_order_header.bk_order_code,
        "||",
        sat_order_items.line_code
      ) as bk_order_line_code
    from
      sat_order_items
      left join bv_order_header on sat_order_items.order_code = bv_order_header.bk_order_code
      and sat_order_items.load_date between bv_order_header.load_date and bv_order_header.end_date
  ),
  end_date_calculation as (
    select
      *,
      lead (load_date) over (
        partition by
          bk_order_line_code
        order by
          load_date
      ) as end_date
    from
      add_unique_key
  )
select
  *,
  coalesce(end_date, '9999-12-31') as end_date
from
  end_date_calculation

 

auftrag_code	bk_bestellung_code	bk_order_line_code	zeilen_code	artikel_code	Menge	Betrag	load_date	end_date
1111	1111 || 10/10/2024	1111 || 1 || 10/10/2024	1	AB	1	32	11/10/2024	31/12/9999
1111	1111 || 10/10/2024	1111 || 2 || 10/10/2024	2	BC	2	34.99	11/10/2024	31/12/9999
1111	1111 || 10/10/2024	1111 || 3 || 10/10/2024	3	DF	10	56	11/10/2024	31/12/9999
1112	1112 || 11/10/2024	1112 || 1 || 11/10/2024	1	BC	5	70	12/10/2024	31/12/9999
1112	1112 || 11/10/2024	1112 || 2 || 11/10/2024	2	XS	1	5	12/10/2024	31/12/9999
1111	1111 || 12/11/2024	1111 || 1 || 12/11/2024	1	DE	20	251.95	12/11/2024	31/12/9999

 

Mit dem Business Vault können Sie jetzt Information Marts erstellen, die die BI-Anforderungen vollständig erfüllen.

Indem Sie den Information Mart als Ansicht materialisieren, die direkt aus dem Business Vault abgerufen wird, können Sie die Duplizierung von Daten auf mehreren Ebenen vermeiden und den Bedarf an Berechnungen auf der Information Mart-Ebene reduzieren. Dieser Ansatz verbessert die Geschwindigkeit, mit der BI-Tools auf die Daten zugreifen und sie analysieren können, erheblich.

Da durch die Anwendung von Geschäftslogik ein neuer Geschäftsschlüssel erstellt wurde, müssen Sie auch den Order Hub rekonstruieren und Verknüpfungen zwischen dem neuen Geschäftsschlüssel und den Customer und Item Hubs im Business Vault herstellen. Dies gewährleistet eine konsistente Integration und Nachvollziehbarkeit im gesamten Modell.

Fazit

Die Verwaltung von wiederverwendeten Geschäftsschlüsseln in einer Data Vault 2.0-Implementierung kann eine Herausforderung sein, aber der Business Vault bietet eine robuste Lösung, um die historische Integrität zu erhalten und die Eindeutigkeit der Daten zu gewährleisten.

Brauchen Sie Hilfe bei der Bewältigung komplexer Data Vault 2.0 Herausforderungen? Unsere Data Vault 2.0-zertifizierten Analysetechniker bei Xebia unterstützen Sie dabei, Ihr Data Vault effektiv zu nutzen. Kontaktieren Sie uns noch heute, um das volle Potenzial Ihrer Daten zu erschließen!