Modelování datového trezoru

Jednoduchý model datového trezoru se dvěma uzly (modrá), jedním spojením (zelená) a čtyřmi satelity (žlutá)

Datový trezor se pokouší řešit problém řešení změn v prostředí oddělením obchodních klíčů (které nemutují tak často, protože jednoznačně identifikují obchodní subjekt) a asociace mezi těmito obchodními klíči od popisných atributů těchto klíčů.

Obchodní klíče a jejich asociace jsou strukturální atributy, které tvoří kostru datového modelu. Metoda datového trezoru má jako jeden ze svých hlavních axiomů, že skutečné obchodní klíče se mění pouze při změnách v podnikání, a proto jsou nejstabilnějšími prvky, z nichž lze odvodit strukturu historické databáze. Pokud tyto klíče použijete jako páteř datového skladu, můžete kolem nich uspořádat zbytek dat. To znamená, že volba správných klíčů pro uzly má pro stabilitu vašeho modelu prvořadý význam. Klíče jsou uloženy v tabulkách s několika omezeními struktury. Tyto tabulky klíčů se nazývají huby.

HubyUpravit

Huby obsahují seznam jedinečných obchodních klíčů s nízkou náchylností ke změně. Huby také obsahují náhradní klíč pro každou položku Hubu a metadata popisující původ obchodního klíče. Popisné atributy informací o hubu (jako je popis klíče, případně ve více jazycích) jsou uloženy ve strukturách nazývaných satelitní tabulky, o kterých bude pojednáno níže.

Hub obsahuje alespoň tato pole:

• náhradní klíč, který se používá k připojení ostatních struktur k této tabulce.
• obchodní klíč, ovladač pro tento hub. Obchodní klíč se může skládat z více polí.
• zdroj záznamu, pomocí kterého lze zjistit, který systém načetl ten který obchodní klíč jako první.
• volitelně můžete mít také pole metadat s informacemi o ručních aktualizacích (uživatel/čas) a datum vytěžení.

Hub nesmí obsahovat více obchodních klíčů, s výjimkou případů, kdy dva systémy dodávají stejný obchodní klíč, ale s kolizemi, které mají různý význam.

Huby by měly mít obvykle alespoň jeden satelit.

Příklad hubuEdit

Toto je příklad pro tabulku hubu obsahující automobily, nazvanou „Car“ (H_CAR). Řídicím klíčem je identifikační číslo vozidla.

LinksEdit

Asociace nebo transakce mezi obchodními klíči (týkající se například uzlů pro zákazníka a produkt navzájem prostřednictvím nákupní transakce) se modelují pomocí tabulek odkazů. Tyto tabulky jsou v podstatě spojovací tabulky typu many-to-many s určitými metadaty.

Odkazy mohou odkazovat na jiné odkazy, aby bylo možné řešit změny v granularitě (například přidání nového klíče do databázové tabulky by změnilo zrno databázové tabulky). Například pokud máte spojení mezi zákazníkem a adresou, můžete přidat odkaz na spojení mezi uzly pro produkt a dopravní společnost. Mohl by to být odkaz s názvem „Dodávka“. Odkazování na odkaz v jiném odkazu je považováno za špatný postup, protože zavádí závislosti mezi odkazy, které znesnadňují paralelní načítání. Vzhledem k tomu, že odkaz na jiný odkaz je totéž jako nový odkaz s náboji z jiného odkazu, je v těchto případech preferovaným řešením vytváření odkazů bez odkazování na jiné odkazy (více informací naleznete v části o postupech nakládání).

Odkazy někdy odkazují na náboje s informacemi, které samy o sobě nestačí k vytvoření náboje. K tomu dochází, když jeden z obchodních klíčů přidružených odkazem není skutečným obchodním klíčem. Jako příklad si vezměme objednávkový formulář s „číslem objednávky“ jako klíčem a řádky objednávky, které jsou klíčovány polonáhodným číslem, aby byly jedinečné. Řekněme „jedinečné číslo“. Tento druhý klíč není skutečným obchodním klíčem, takže se nejedná o žádný náboj. Musíme jej však použít, abychom zaručili správnou granularitu odkazu. V tomto případě nepoužijeme rozbočovač s náhradním klíčem, ale přidáme do odkazu samotný obchodní klíč „jedinečné číslo“. To se provádí pouze v případě, že není možné obchodní klíč někdy použít pro jiný odkaz nebo jako klíč pro atributy v satelitu. Tuto konstrukci nazval Dan Linstedt na svém (dnes již zaniklém) fóru „peg-legged link“

Propojení obsahují zástupné klíče pro propojované rozbočovače, vlastní zástupný klíč pro propojení a metadata popisující původ spojení. Popisné atributy pro informace o asociaci (jako je čas, cena nebo částka) jsou uloženy ve strukturách nazývaných satelitní tabulky, které jsou popsány níže.

Příklad propojeníUpravit

Toto je příklad pro tabulku propojení mezi dvěma uzly pro automobily (H_CAR) a osoby (H_PERSON). Odkaz se nazývá „Řidič“ (L_DRIVER).

SatelityEdit

Huby a odkazy tvoří strukturu modelu, ale nemají časové atributy a neobsahují žádné popisné atributy. Jsou uloženy v samostatných tabulkách nazvaných satelity. Ty se skládají z metadat, která je spojují s jejich nadřazeným uzlem nebo odkazem, metadat popisujících původ asociace a atributů a také z časové osy s daty začátku a konce atributu. Tam, kde uzly a odkazy poskytují strukturu modelu, satelity poskytují „maso“ modelu, kontext pro obchodní procesy, které jsou zachyceny v uzlech a odkazech. Tyto atributy jsou uloženy jak s ohledem na podrobnosti záležitosti, tak i na časovou osu a mohou se pohybovat od poměrně složitých (všechna pole popisující kompletní profil klienta) až po zcela jednoduché (satelit na odkazu pouze s ukazatelem platnosti a časovou osou).

Obvykle jsou atributy seskupeny v satelitech podle zdrojového systému. Popisné atributy, jako je velikost, cena, rychlost, množství nebo barva, se však mohou měnit různou rychlostí, takže i tyto atributy můžete rozdělit do různých satelitů podle rychlosti jejich změny.

Všechny tabulky obsahují metadata, minimálně popisující alespoň zdrojový systém a datum, kdy se tato položka stala platnou, což poskytuje úplný historický pohled na data, jak vstupují do datového skladu.

Příklad satelituUpravit

Toto je příklad pro satelit na propojení řidičů mezi uzly pro automobily a osoby s názvem „Pojištění řidičů“ (S_DRIVER_INSURANCE). Tento satelit obsahuje atributy, které jsou specifické pro pojištění vztahu mezi vozidlem a osobou, která jej řídí, například ukazatel, zda se jedná o hlavního řidiče, název pojišťovny pro toto vozidlo a osobu (mohl by to být také samostatný rozbočovač) a přehled počtu nehod zahrnujících tuto kombinaci vozidla a řidiče. Součástí je také odkaz na vyhledávací nebo referenční tabulku s názvem R_RISK_CATEGORY obsahující kódy pro kategorii rizika, do které se má tento vztah zařadit.

.

.

(*) alespoň jeden atribut je povinný(**) pořadové číslo se stává povinným, pokud je potřeba vynutit jedinečnost pro více platných satelitů na stejném uzlu nebo spoji.

Referenční tabulkyUpravit

Referenční tabulky jsou běžnou součástí zdravého modelu datového trezoru. Jejich účelem je zabránit nadbytečnému ukládání jednoduchých referenčních dat, na která se často odkazuje. Formálněji definuje Dan Linstedt referenční data takto:

Jakékoli informace, které jsou považovány za nezbytné pro vyřešení popisů z kódů nebo pro překlad klíčů do (sic) konzistentního způsobu. Mnohá z těchto polí mají „popisný“ charakter a popisují specifický stav jiných důležitějších informací. Referenční údaje jako takové žijí v oddělených tabulkách od tabulek surového datového trezoru.

Referenční tabulky jsou odkazovány ze satelitů, ale nikdy nejsou svázány fyzickými cizími klíči. Pro referenční tabulky neexistuje žádná předepsaná struktura: použijte to, co ve vašem konkrétním případě nejlépe vyhovuje, od jednoduchých vyhledávacích tabulek až po malé datové trezory nebo dokonce hvězdy. Mohou být historické nebo bez historie, ale doporučuje se držet se přirozených klíčů a nevytvářet v takovém případě náhradní klíče. Obvykle mají datové trezory spoustu referenčních tabulek, stejně jako jakýkoli jiný datový sklad.

Referenční příkladUpravit

Toto je příklad referenční tabulky s kategoriemi rizika pro řidiče vozidel. Lze na ni odkazovat z libovolného satelitu v datovém skladu. Prozatím na ni odkazujeme ze satelitu S_DRIVER_INSURANCE. Referenční tabulka je R_RISK_CATEGORY.

(*) alespoň jeden atribut je povinný.