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“.

Druhý pilíř – (Skoro)Neustálé inkrementální dodávky vyvíjeného produktu

Každou vývojovou iteraci se musí dodat inkrement výsledného produktu. Rámcově se může jednat o část automatizovaných test case, část prototypu nebo část výsledného řešení. Postupuje se od nejdůležitějších částí k těm méně důležitým s cílem maximalizovat využití paretova pravidla.

Během jiných než vývojových iterací se musí také něco dodat, typicky je to solution design (nebo jiná neproduktová specifikace vývoje), dokumentace, analýza ve wordu (to je totiž dokumentace prototypu) a další formality, které jsou důležité, ale nejsou produkt. Definici produktu je nutné si odladit hned na začátku. Na produkt by se měl zákazník těšit, pokud je mu to jedno, zpravidla je to formalita. Projekty, které jsou celé formalita neděláme, ty odkládáme, pokud jsou regulatory a nikdo interní o ně nemá zájem, doporučil bych watterfall a schopného dodavatele s referencí na implementaci této regulace.

Délka jedné iterace by měla být cca 14 dní. Ve firmách, kde se nasazuje jednou měsíčně, by tak měla dobře vycházet vždy jedna vývojová a jedna nevývojová iterace.

 

Proč oddělovat inkrementy produktu a ostatních částí dodávky?

Postup prací v incremental BI se definuje postupem na produktu, postup na formalitách je druhotný (protože nezajímají zákazníka). Tato kategorizace je zásadní pro rozkrytí neefektivit vývojového procesu. Má to zásadní vliv na uvažování o projektu – nikdo totiž není schopný vám zbytečnými specifikacemi, analýzami apod. uměle nafukovat dodávku a spoléhat se na to, že se to ztratí.

U větších projektů, kde jsou specializované role (developer, tester, analytik, solution architect, data architect, atd), je možné mít více inkrementů najednou, jejich řešitelské týmy jsou ale jasně odděleny.

Inkrement by měl vždy končit na produkci (ať už je jím cokoliv). Toto by mělo bavit a hlavně zapojit zákazníka. Pro fázi analýzy (=prototypu) jde zpravidla zajistit nějakou omezenou databázi na produkčním prostředí / reportserveru apod. Standardizace už není tak zajímavá (zákazník je zpravidla vyžaduje jen nepřímo), tuto poslední fázi zpravidla dotáhneme interně (zákazník už má tou doubou prototyp na produkci).

 

 

 

Cílem je koncentrace – jakmile se jednou člověk nebo tým zakousne do kódu (a komentářů v něm) měl by v něm zůstat co nejdéle. Těkat mezi Wordem, kódem a modelem je zpravidla dost neefektivní. Toto jednoduché pravidlo má za následek dva klíčové stavy – jednoduché řízení očekávání do okolí. (například při nevývojové iteraci je jasné, že nebude nic nasazovat, je zřejmé, že budete spíš komunikovat s architekturou apod., řešit formality a nebudete tolik vytěžovat zákazníka), a druhý stav je komunikace postupu prací – velmi dobře dokážete oddělit, kolik času trávíte dodávkou vlastního produktu a kolik práce vám přidělává okolí. Je to velmi dobře komunikovatelné na statusech a steeringu.

 

V tří-vrstevné architektuře (DEV,TEST,PROD) nelze za 14 dní dodat na produkci. Ano, iBI je vždy nutné zasadit do kontextu konkrétního zákazníka. Někomu stačí dodat do UAT (test) prostředí (a to už se stihnout dá).

Také je možnost odladit dostatečně prototyp a dohodnout se, že se celý standardizuje do výsledné podoby BI řešení jedním nebo několika většími inkrementy. Aby to fungovalo, musí se splnit několik předpokladů – businessově je prototyp zcela v pořádku a je závazně akceptován zákazníkem, chybí jen technicistní standardizace (správný typ historizace, podoba cizích klíčů, ssis balíčky apod., dokumentace) a tato standardizace je jasně zadaná a provádí se nad stejnými daty jako prototyp. Čím lepší máte automatizované testy tím lépe, můžete je použít pro ověření standardizace. Tato část má totiž nejmenší riziko change requestu a zároveň je tu sporná role zákazníka.

Při určitém zjednodušení lze říct, že čím více je organizace vodopádově zaměřená, tím více mají smysl prototypy. Některé firmy budou mít řešení sestavené třeba z 60% z protototypů. Aby to bylo udržetelné je nutné vědět, co je produkčně provozovatelný prototyp a co není a jaké má na sobě SLA.