Co je link v Data Vaultu?

Huby vám řeknou, kteří zákazníci, jaké produkty a které objednávky existují. Neříkají nic o tom, jak k sobě tyto věci patří. To je úkol linku.

Řečeno jazykem klasického modelování: ze vztahu se stane link. Zjednodušeně je cizí klíč v modelu ve třetí normální formě základem linku. Tam, kde tabulka Order obsahuje customer_id, má Data Vault link mezi hubem objednávek a hubem zákazníků.

Klasický link

Link zaznamenává vztah mezi business klíči: tato objednávka patří tomuto zákazníkovi, tato smlouva se vztahuje na tento produkt. Stejně jako hub neukládá žádná popisná data.

Tabulka linku obsahuje:

• Hash klíč linku. Primární klíč, hash přes business klíče všech hubů, které propojuje.
• Hash klíče hubů. Jeden sloupec za každý zúčastněný hub.
• Load Date. Kdy byl vztah poprvé zaznamenán.
• Record Source. Který systém ho dodal.

Do linků se stejně jako do hubů pouze vkládá. Vztah, který se jednou objevil, v linku zůstane. Zda platí i dnes, je otázkou pro effectivity satelit, kterému se věnuje jeden z dalších článků této série.

Učebnicový Data Vault modeluje každý link jako n:m, aby se nemusel přestavovat, když se po fúzi nebo zavedení nového systému ze vztahu 1:n stane n:m. To, že je struktura n:m, ale neznamená, že taková jsou i data. Když se objednávka přesune k jinému zákazníkovi, nepatří najednou dvěma zákazníkům: nový zákazník nahradí původního. Abyste link četli správně, musíte znát jeho řídicí stranu.

V Datavault Builderu je klasický link binárním linkem mezi dvěma huby a nese svou kardinalitu: 1:1, n:1, 1:n nebo n:m. Kardinalita určuje, která strana je ve vztahu řídicí, takže změna na řídicí straně se čte jako nahrazení, a ne jako další vztah.

Pokud znáte klasické datové modelování, link už znáte

Transakční link

Pro transakce přidává Datavault Builder druhý druh linku. Transakce, například řádek objednávky, platba nebo řádek dodávky, souvisí s několika huby zároveň a konvenční Data Vault ji často ukládá přímo do linku, někdy do nehistorizovaného linku se závislými podřízenými klíči (dependent child keys). Granularita je pak implicitní: je to jakákoli kombinace klíčů, která náhodou dělá řádek jedinečným. Pokud zdroj později přesune řádek objednávky k jinému zákazníkovi, obsahuje link pro tentýž řádek dva záznamy a nic v modelu neříká, který z nich transakci popisuje.

Transakční link určuje granularitu explicitně. Nejjemnější granularita transakce dostane vlastní hub, grain hub (Hub_Sales_Order_Line, Hub_Payment_Transaction), a link je na něm ukotven. Tím získá transakční link čtyři vlastnosti, každou z určitého důvodu:

• Pevná granularita. Na každý řádek objednávky připadá jeden záznam v linku a granularita se nemůže posunout.

• Definovaná řídicí strana. Řídicí stranou vztahu je grain hub. Pokud řádek objednávky dostane nový produkt, nový produkt nahradí původní; řádek objednávky pak neukazuje na dva produkty současně.

• Identifikující a neidentifikující vztahy. Grain hub je identitou transakce. Zákazník, produkt a prodejna se účastní jako reference, což je stejné rozlišení, jaké dělá klasické ER modelování.

  „Klíč, celý klíč a nic než klíč, tak mi pomáhej Codd.“ Klasické shrnutí Coddovy třetí normální formy platí i zde: grain hub je klíčem transakce a vše ostatní ji buď popisuje, nebo odkazuje na jiný pojem.

• Atributy na hubu. Množství, cena a stav patří do běžného satelitu na grain hubu. Lze je načítat inkrementálně jako jakýkoli jiný satelit a další atributy lze později přidat bez přemodelování. Data Vault pro tento účel umožňuje i satelity linků; podle naší zkušenosti je lepším místem hub. Totéž platí pro vazební tabulku s atributy, například roli nebo procentní podíl u přiřazení zákazníka ke smlouvě.

Řešení problému link na link

Prvním pravidlem Data Vaultu je, že linky propojují huby. Link nesmí odkazovat na jiný link.

Skutečné transakce přitom na jiné transakce odkazují neustále: řádek faktury odpovídá řádku dodávky, platba vyrovnává fakturu, vratka odkazuje na řádek objednávky. Konvenčním řešením je zploštit vše do jednoho složeného linku se šesti nebo více klíči hubů, který se špatně čte a z každého načtení dělá velkou jednotku práce (unit of work).

S transakčními linky tento problém mizí. Každá transakce už má grain hub, takže vztah mezi dvěma transakcemi je běžný link mezi dvěma huby:

Hub_Delivery_Line ↔ Link_Delivery_To_Invoice ↔ Hub_Invoice_Line

Žádný odkaz z linku na link, žádné obcházení přes závislé podřízené klíče a každý link zůstane dost malý na to, aby se dal přečíst.

Tento vzor sahá do roku 2017, kdy jsem ho poprvé popsal v článku „O Linkách“, včetně srovnání se standardem Data Vault 2.0.

Co se mění s Datavault Builderem

• Oba druhy linků v jednom modelu. Binární linky pro vztahy mezi kmenovými daty, transakční linky tam, kde je vztahem transakce.
• Kardinalita a granularita se rozhodují v modelu. Určíte kardinalitu binárního linku, nebo co je jedna transakce, a nástroj z toho sestaví link i jeho načítací procesy.
• Kód se generuje. Hash klíče, unit of work a načítání pouhým vkládáním se řídí stejným vzorem u každého linku, na Snowflake, Databricks, BigQuery, SQL Server, Fabric, Oracle nebo PostgreSQL.

Co rozhodnout

Vezměte své tři nejdůležitější transakce a u každé zapište, co je jeden její výskyt. Pokud je odpovědí kombinace zákazníka, produktu a data, a ne číslo řádku nebo dokladu, je granularita implicitní. Právě tam transakční link model stabilizuje.