Co je hub v Data Vaultu?

Každý datový sklad musí ještě před vším ostatním odpovědět na jednu otázku: o jakých věcech tato firma mluví a jak je od sebe rozlišuje? V Data Vaultu je odpovědí hub.

Co je hub

Hub představuje jeden klíčový obchodní pojem: zákazníka, produkt, účet, smlouvu. Není to kopie tabulky ze zdrojového systému. Hub zákazníků obsahuje každý klíč zákazníka, který datový sklad kdy obdržel, z jakéhokoli zdroje, a každý právě jednou.

Hub ukládá identitu, ne stav. O zákazníkovi nic neříká: jméno, adresa a popisné atributy jsou uloženy v satelitech a objednávky a smlouvy zákazníka jsou připojeny přes linky. Hub pouze zaznamenává, že tento klíč existuje, kdy ho datový sklad poprvé obdržel a odkud přišel.

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

Data Vault nenahrazuje to, co jste se o datovém modelování naučili. Využívá to. Vyjděte z konceptuálního modelu, který byste tak jako tak nakreslili: z obchodních pojmů a jejich vzájemných vztahů. Každý pojem, tedy každá entita ve vašem ER diagramu, se stane hubem.

Vezměme klasickou tabulku Customer ve třetí normální formě:

Nic se neztratí a nic nového se nevymýšlí. Entita se rozdělí podle hranic, které už znáte: co ji identifikuje, co ji popisuje a s čím souvisí. Hub je prvním z těchto tří prvků, a proto je hledání hubů stejná práce, jakou byste odvedli u každého dobrého konceptuálního modelu: shodnout se na obchodních pojmech a na tom, jak se každý z nich identifikuje.

Anatomie hubu

Hub má čtyři sloupce, nic víc:

• Hash klíč. Primární klíč: deterministický náhradní klíč, vypočtený jako hash (MD5 nebo SHA-256) z business klíče, případně doplněný o kód kolize tam, kde by dva zdroje mohly stejný klíč používat pro různé věci. V Datavault Builderu se tento kód kolize nazývá Business Key Prefix. Každá tabulka, která na hub odkazuje, vypočte stejnou hodnotu bez vyhledávání.
• Business klíč. Klíč, který entitu identifikuje v obchodním světě: číslo zákazníka, VIN, IBAN. Jeden sloupec, nebo několik u složeného klíče, například kód společnosti plus číslo zákazníka.
• Load Date. Kdy byl business klíč poprvé zaregistrován v Data Vaultu.
• Record Source. Který provozní systém klíč dodal jako první.

Business Key Prefix: stejné číslo, jiná objednávka

Švýcarská i německá dceřiná společnost provozují každá vlastní ERP systém a v obou existuje objednávka 1018. Jsou to dvě různé objednávky od různých zákazníků. Kdyby se hashovalo pouze číslo objednávky, skončily by obě na stejném řádku hubu a vše, co o nich oba systémy vědí, by se smíchalo.

Business Key Prefix je od sebe oddělí. Každý zdroj přidá před hashováním ke klíči svůj prefix, CH|1018 a DE|1018, takže hub objednávek obsahuje dva řádky, jak má. Používejte ho jen tam, kde stejný klíč skutečně může znamenat různé věci. Pokud dva systémy sdílejí klíč se stejným významem, například celoskupinové číslo zákazníka, mají se tyto klíče bez prefixu mapovat na stejný řádek hubu.

Proč u business klíče neodstraňujeme mezery ani ho nepřevádíme na velká písmena

Běžně se doporučuje u business klíče před hashováním odstranit okrajové mezery a převést ho na velká písmena. My to nedoporučujeme. Z c-10442 a C-10442 se tak stane tentýž zákazník a zmizí i mezera na konci, a to i tehdy, když je rozdíl překlepem ve zdroji. Vault pak bez povšimnutí sloučí dva záznamy a jejich vztahy do jednoho. Hub má uchovávat to, co zdroj dodal. Rozhodnutí, že dva klíče znamenají totéž, je obchodní pravidlo a patří na viditelné místo, například do same-as linku.

Jednou zapsat, nikdy neaktualizovat

Huby se pouze doplňují. Každé načtení porovná příchozí klíče s klíči, které už v hubu jsou, a vloží ty nové. Jakmile je business klíč jednou v hubu, zůstane tam navždy: žádné aktualizace, žádná mazání.

Toto pravidlo má dva důsledky. Načtení hubu nezávisí na ničem jiném v modelu, takže se všechny huby mohou načítat paralelně. A neúspěšné načtení lze jednoduše spustit znovu, protože vložit tytéž nové klíče dvakrát není možné.

Kde zanikají datová sila zdrojových systémů

Hub je integračním bodem modelu. Pokud CRM i ERP identifikují zákazníka stejným business klíčem z reálného světa, oba se mapují na stejný řádek hubu a vše, co o tomto zákazníkovi oba systémy vědí, se setká právě tam.

Proto je skutečným návrhovým rozhodnutím volba business klíče. Nejlepší volbou je klíč, který firma používá napříč systémy. Ne vždy je k dispozici v použitelné podobě: zdroj může nést jen své vlastní technické ID, nebo klíč, který se recykluje, je jinak formátovaný nebo u starších záznamů chybí. Jak s tím naložit, je tématem dalšího článku této série: technické versus business klíče. Pokud dva systémy používají pro stejného zákazníka různé klíče, same-as link zaznamená, že k sobě patří.

Co do hubu nikdy nepatří

• Popisný kontext. Jména, adresy, stavy a částky patří do satelitů. Hub, který sbírá atributy, je převlečený satelit a přestává být stabilní.
• Cizí klíče. Store_ID v hubu zákazníků je vztah a vztahy patří do linků.
• Atributy vydávané za pojmy. Stav, kategorie nebo kód měny něco popisují, nejsou to samostatné obchodní pojmy. U transakcí je to jinak: v Datavault Builderu dostane řádek objednávky nebo platba vlastní grain hub, jak vysvětluje článek o linku.
• Jeden hub pro každý zdroj. Tři huby zákazníků, po jednom pro CRM, ERP a e-shop, znovu vytvoří datová sila, která měl datový sklad odstranit.
• Náhradní klíče zdrojových systémů, pokud se jim lze vyhnout. Hodnota IDENTITY nebo AUTO_INCREMENT z jedné databáze nemá v dalším systému žádný význam, takže ji vynechte, pokud existuje business klíč. Někdy je to však nejlepší klíč, jaký je k dispozici, například pro verze tabulky, kterou už zdroj historizoval, nebo pro nejnižší granularitu transakce, na kterou nic jiného neodkazuje. Tam může být správnou volbou. Kdy tomu tak je, rozebírá článek o technických versus business klíčích.

Co se mění s Datavault Builderem

V Datavault Builderu definujete obchodní pojem jednou a každý zdroj k němu přiřadíte tím, že určíte jeho business klíč. Tabulka, práce s klíči a načítací kód se z toho vygenerují a běží nativně na vaší databázi, ať už je to Snowflake, Databricks, BigQuery, SQL Server, Fabric, Oracle nebo PostgreSQL.

• Klíč je rozhodnutím v modelu, ne vzorem v kódu. Vy rozhodujete, co identifikuje zákazníka. Psaní výpočtu hashe a logiky vkládání do tohoto rozhodnutí nepatří.
• Nové zdroje se mapují na stejný hub. Přidat e-shop znamená namapovat jeho číslo zákazníka na existující hub zákazníků, ne stavět nový.
• Vzor je pokaždé stejný. Ručně psané načítání hubu se s každým novým zdrojem kopíruje, upravuje a mírně mění. Vygenerované se od vzoru neodchyluje.

Co rozhodnout

Sepište pět až deset obchodních pojmů, o kterých vaše reporty skutečně mluví, a ke každému zapište klíč, kterým ho firma identifikuje. Tam, kde vám dvě oddělení dají různé odpovědi nebo kde zdroj nemá vůbec žádný použitelný klíč, jste našli nejcennější integrační práci celého projektu.