Im Datenmodell und in den Daten sind typische Probleme für ein Data Vault Warehouse hinterlegt. Die Fälle erstrecken sich von Stage über Raw und Business Vault bis zum Data Mart.
Genereller Funktionalitätstest der Raw Vault Beladung
Die Funktionalität von Stage und Raw Vault kann einfach mit dem sogenannten Yedi Test überprüft werden. Hierzu müssen lediglich die Ursprungsdaten aus dem Raw Vault wiederhergestellt werden und gegen die Ursprungslieferung aus der Stage verglichen. Dieser Test stellt sicher, dass alle Daten korrekt geladen wurden.
Hierachical Link
Die Kategorie zum Produkt ist ein klassischer Hierarchical Link.
Multi-Active Satellite
Die Entität Wohnorte hat asl Primärschlüssel die KundeID und die Zeit und ist damit prädestiniert für einen multi-active Satelliten.
Identifying Relationship und driving Key Patterns
Zwischen Bestellung und Position kann sich die Beziehung nicht ändern. Die Schlüsselsituation macht aus jeder Änderung eine Löschung und eine Neuanlage.
Bei allen anderen Beziehungen können sich die Beziehungen ändern. Die Testfälle sind alle auf dem Fremdschlüssel im Kunden zum Vereinspartner implementiert. Hier kommt es zu folgenden Situationen:
- der Fremdschlüssel ist optional und somit auch NULL
- der Fremdschlüssel wechselt zwischen Vereinspartnern
- der Fremdschlüssel wechselt von gültig auf ungültig und in einigen Fällen dann wieder zurück auf gültig
m:n Tabelle ohne eigenen Key
Die Tabelle der Lieferungen hat keinen eigenen Primärschlüssel und erfolgt in der Regel auch nur einmal, da nur die erfolgreichen Lieferungen an das dwh übermittelt werden.
Das lässt sich auf mehrere mögliche Arten lösen: keyed instance, transactional link, dependend child link, …
Integration der Bestellung
Wir haben 2 Quellen. Diese sollen integriert in die Hubs Bestellung und Position geladen werden. Die Primärschlüssel beider Systeme werden einfach nur hochgezählt. Die Roadshow hat zusätzlich ein ‚RS‘ zur sicheren Unterscheidung.
Man könnte argumentieren, dass die Integration im Business Vault stattfinden soll. Weil die Schlüssel nicht wirklich gleich sind, die Mengen disjunkt, es viel sicherer ist. Das sind alles valide Argumente. Hier geht es darum, die Fähigkeit zur frühen Integration zu präsentieren.
Referenztabelle
Für den Produkttyp gibt es eine Liste von Referenzwerten:
Testfälle in den Daten
Wir bekommen 3 komplette Lieferungen. Die Auswertung der Daten erfolgt auf diesen 3 Lieferungen und muss jeweils die korrekten Daten liefern.
Dubletten in den Ladedaten
Im Produkt sind 2 Arten von Dubletten. Im ersten Fall handelt es sich um eine tatsächliche Dublette, alle Attribute sind gleich. Im zweiten Fall widersprechen sich die Attribute. Die Daten sind in Testcases/Dubletten.sql:
- ProduktID 20 ist die tatsächliche Dublette
- ProduktID 21 ist ein ganz anderes Produkt
Hier wollen wir nur sehen, wie damit umgegangen wird.
Sätze ohne Business Key
In der Tabelle Lieferdienst gibt es Datensätze mit gültigen Werten ohne Schlüssel. Auch hier nur die Frage, wie damit umgegangen wird.
In testcases/Missing-BusinessKey.sql sind zwei Lieferdienste ohne Business Key.
Änderungen in den Kundendaten
Ein ganz einfacher Testfall, die Daten im Kunden ändern sich in Lieferung 2 auf einen Wert und bekommen in Lieferung 3 wieder die Werte aus Lieferung 1. Der Testfall liegt auf der KundedID 107
Löschungen im Kunden
Im Kunden gibt es Fälle, bei denen der Kunde in der zweiten Lieferung gelöscht wurde und in der dritten Lieferung wieder auftaucht. Ein Testfall ist Kunde 70.
Lieferadressen ohne Kunde
In der ersten Lieferung sind Lieferadressen enthalten, für die es im Kunden keinen Satz mit gleicher KundeID gibt. Die Sätze haben die KundeID 999, 998 und 997.
Löschungen von Bestellungen
Die Bestellungen sind zählungsrelevant und werden zwischen den Lieferungen gelöscht.
Gelöschte Lieferungen:
- zwischen 1 und 2 die BestellungID 99, 220 und 465.
- zwischen 2 und 3 die BestellungID 1470 und die 1288.
Änderungen in den Dimensionen
Die Hierarchie der Produktkategorie ändert sich komplett mit beiden Lieferungen. Wir haben also 3 unterschiedliche Produkthierachien. Diese sollen als as-was zum jeweiligen Berichtszeitpunkt angezeigt werden.