Umělé vs Přirozené klíče v DWH

Klíče jsou jedním ze základních prvků relačních databázových modelů. Tím, že identifikují konkrétní záznam v dané tabulce (například ID zákazníka, IČO apod.) nám také umožňují se na tento záznam jednoduše odvolat, třeba z tabulky budov a tím říct, kdo kde bydlí. Celá teorie je pěkně shrnuta zde.

Příběh a úvod do problematiky

Některé identifikátory se vedle naší tabulky, vyskytují i v reálném světě – například to IČO. Takové identifkátory označujeme jako přirozené (-> lze s jejich pomocí přirozeně dorozumívat i mezi lidmi). Ano, situace se mění. Kdysi dávno se firma identifikovala podle jména, ale ukázalo se to jako složité – někdo ho napsal bez diakritiky, někdo ho přeložil do angličtiny a někde si svou provozovnu nazval jinak než svou firmu..v této situaci se těžko vybírají třeba daně. Proto někoho napadlo začít používat pro jednoznačnou identifikaci nějaké celkem náhodné číslo – pokud budou mít dva různé názvy shodné toto IČO bude jasné, že jde o jeden subjekt. Toto číslo zlidovělo a dnes o něm můžeme nečesky mluvit jako o znaturalizovaném klíči (zpřírodněném??).

Proč se to stalo?

A teď zpět databázím, proč název firmy dlouhodobě neuspěl a byl doplněn číslem?

  • Otázky, které napovídají o kvalitě identifikátoru:
    • Is the primary key unique?
    • Does it apply to all rows?
    • Is it minimal?
    • Is it stable over time?

(přebráno od sqlmag.com)

Název firmy:
Název firmy nebyl zcela unikátní -> pletl se s názvem provozovny, měl více variant zápisu apod.
Všechny firmy měly názvy.
Byl minimální.
Nebyl stabilní v čase.

IČO:
Je unikátní (neplete se s jiným číslem)
Mají ho všechny firmy (dokonce dnes platí, že kdo ho nemá, není firma)
Je minimální
Je stabilní v čase (jednou vydané číslo už žádná nová firma nedostane)

Diskuze o klíčích a datovém skladu

Jaké klíče má používat DWH?
Realita ve firmě je zpravidla následující – přirozený klíč, tj. IČO nebo název firmy nejsou dostatečně unikátní (občas se pracuje s firmami na úrovni oddělení, fyzické osoby IČO nemají, občas číslo prostě neznáme apod.), business klíč (id_firmy – jde o původně umělý klíč nějakého systému, který ale ve firmě zlidověl úplně stejně, jako IČO zlidovělo v reálném světě) a někdy je ještě umělý klíč DWH (tento klíč je zcela bezvýznamový, v primárních systémech je ignorován a díky tomu si drží výhody umělého klíče). A tím se dostáváme k předmětu článku – umělé klíče v DWH – co zvažovat?

Otázka č.1. – chci se chovat jednotně ke všem tabulkám?
Ano -> Musím si vybrat z těchto dvou variant
Ne -> Otázku elegantně odkládám a věřím si, že ve skladu udržím pořádek i bez jasného pravidla (všimněte si, že ve světě primárních systémů už od toho upustili všichni 🙂 )

Otázka č.2 – věřím business identifikátorům?
Pokud jste výše zvolili mix obou přítupů, řešíte tuto otázku na každé tabulce

Ano -> V situaci, kdy zdrojem pro DWH je jen jeden systém, to bývá tato odpověď. S přibývajícím počtem systémů (a jejich stáří) je to více a více o víře. Pokud jste v předchozí otázce volili Ano, je pravděpodobné, že budete donuceni ke změně.

Ne -> Čím více systémů a čím déle má DWH sloužit, tím spíše zvítězí nedůvěra.

  • Správná implementace umělých klíčů.

    • Skripty pro jejich generaci se řídí centrálně
      • jedna sekvence pro SCD2 tabulky, pro transakční tabulky jich může být více
      • Existuje jeden generátor merge skriptu (jeden generátor lze zkontrolovat, že funguje správně, 1000 ručních skriptů je těžší)
    • Business klíče a přirozené klíče (které jsou hlavním vstupem pro tvorbu klíčů umělých) jsou transparentně popsány v modelu a jsou využity generátorem výše
    • V DWH je jednoduchý systém, jak business a přirozené klíče zobrazit (v reportu není nutné ukazovat klíče umělé)

Tím, že tvorbu umělých klíčů řídíte centrálně, lze říct, že automaticky na otázky v úvodu článku odpovídáte ano.

Správná implementace business klíčů

  • Moc jich neznám, berte to prosím jako úvahu k diskuzi.
    • Doplnění business a přirozených klíčů atributem zdrojového systému.
    • Správný výběr klíčů a jejich důkladný profiling
      • viz otázky na začátku článku
    • Možnost korigovat primární systém při porušení pravidel práce s klíči

 

______
Poznámka pro vývojáře transformací Stage -> Core

V této fázi umělé klíče teprve vytváříte -> pro transformace se musíte spolehnout na business a přirozené klíče. Při dotazu do jádra, tak děláte „lookupy“.





Leave a Comment

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *