Ahoj! Jmenuji se Andrej Semjonov, jsem seniorní analytik ve Sportmasteru. V tomto příspěvku chci vznést otázku denormalizace databází ERP systémů. Podíváme se na obecné podmínky a také na konkrétní příklad — řekněme, že to bude skvělá monopolní taverny pro piráty a námořníky. Kde je třeba obsluhovat piráty a námořníky rozdílně, neboť představy o krásném a spotřebitelské vzorce těchto dobrých pánů se výrazně liší.
Jak zajistit, aby byly všechny strany spokojené? Jak se nezbláznit při návrhu a údržbě takového systému? Co dělat, když do taverny začnou přicházet nejen obvyklí piráti a námořníci?
Všechny informace jsou níže. Ale postupujme v pořádku.
1. Omezení a předpoklady
Vše, co bylo řečeno, se vztahuje pouze na relační databáze. Dobře osvětlené, včetně internetu, důsledky denormalizace ve formě anomálií při modifikaci, vymazání a vkládání nejsou zvažovány. Mimo rámec publikace zůstávají případy, kdy je denormalizace běžná, s klasickými příklady: sériové a číslo pasu, datum a čas a další.
V příspěvku jsou použity intuitivně pochopitelné a prakticky použitelné definice normálních forem, bez odkazu na matematické termíny. Tak, jak mohou být aplikovány na analýzu skutečných obchodních procesů (BPs) a projektování průmyslového softwaru.
Existuje názor, že návrh datových skladů, nástrojů pro tvorbu reportů a integračních dohod (v nichž se používá tabulkové zobrazení informací), se liší od návrhu databází ERP systémů tím, že pohodlí spotřeby a vědomá denormalizace pro jeho dosažení může mít prioritu nad ochranou integrity dat. Tento názor sdílím, a níže popsané se týká výhradně modelů hlavních dat a transakčních dat ERP systémů.
Vysvětlení normálních forem je uvedeno na příkladu, který je většině čtenářů srozumitelný na běžné úrovni. Jako názorná ilustrace byla však úmyslně použita zdůrazně „vymyšlená“ úloha v bodech 4-5. Pokud to neuděláte a vezmete nějaký příklad z učebnice, například stejný model ukládání objednávky z bodu 2, můžete se ocitnout v situaci, kdy se zaměření čtenáře přesune z navrženého rozložení procesu v modelu na osobní zkušenosti a vnímání toho, jak by měly být procesy a modely ukládání dat v IS. Jinými slovy, vezměte si dva kvalifikované IT analytiky, ať jeden poskytuje služby logistikům, kteří přepravují pasažéry, a druhý logistikům, kteří přepravují stroje pro výrobu mikro čipů. Požádejte je, aby bez předchozí dohody o automatizovatelných BPs vytvořili datový model pro ukládání informací o železničním přepravním spoji.
Existuje nenulová pravděpodobnost, že v navržených modelech najdete nejen znatelně odlišné sady atributů, ale také nesouhlasící sady entit, protože každý analytik se bude opírat o jemu známé procesy a úkoly. A říci v takové situaci, který model je „správný“, není možné, protože chybí kritérium hodnocení.
2. Normální formy
První normální forma DB vyžaduje atomaritu všech atributů.
Pokud například objekt A má nektyčové atributy a a b, takové že c=f(a,b) a v tabulce popisující objekt A ukládáte hodnotu atributu c, pak je v DB porušena první normální forma. Například, pokud ve specifikaci objednávky uvádíte množství, jehož jednotky měření závisí na typu zboží: v jednom případě to mohou být kusy, v druhém litrech, v třetím balení složené z kusů (v výše uvedeném modelu Good_count_WR), pak je v DB porušena atomarita atributů. V tomto případě, abyste řekli, jaký by měl být keř tabulek u specifikace objednávky, potřebujete cílový popis procesu práce v IS, a protože procesy mohou být různé, může být také mnoho „správných“ verzí.
Druhá normální forma DB vyžaduje dodržení první formy a vlastní tabulky pro každou entitu vztahující se k procesu práce v informačním systému. Pokud v jedné tabulce existují závislosti s=f1(a) a d=f2(b) a neexistuje závislost s=f3(b), pak je v tabulce porušena druhá normální forma. V uvedeném příkladu v tabulce „Objednávka“ neexistuje závislost mezi objednávkou a adresou. Změňte název ulice nebo města a nebude mít žádný vliv na podstatné atributy objednávky.
Třetí normální forma DB vyžaduje dodržení druhé normální formy a absenci funkčních závislostí mezi atributy různých entit. To lze formulovat takto: „všechno, co může být vypočítáno, by mělo být vypočítáno“. Jinými slovy, pokud existují dva objekty A a B. V tabulce, která uchovává atributy objektu A, je zobrazen atribut C, u objektu B existuje atribut b, takový, že existuje c=f4(b), pak je třetí normální forma porušena. V následujícím příkladu atribut „Počet kusů“ (Total_count_WR) v záznamu objednávky zjevně naznačuje porušení třetí normální formy.
3. Můj přístup k aplikaci normalizace
1. Pouze cílený automatizovatelný obchodní proces může poskytnout analytikovi kritéria pro identifikaci entit a atributů při vytváření modelu ukládání dat. Vytvoření modelu procesu je nutnou podmínkou pro vytvoření normálního datového modelu.
2. Dosáhnout třetí normální formy v přísném smyslu nemusí být v praxi vytváření ERP systémů účelné za splnění části nebo všech následujících podmínek:
- automatizované procesy jsou zřídka podrobeny změnám,
- termíny pro výzkum a vývoj jsou stlačené,
- požadavky na integritu dat jsou relativně nízké (potenciální chyby v průmyslovém softwaru nevedou k ztrátě peněz nebo klientů pro zákazníka přizpůsobeného softwaru)
- atd.
Za popsaných podmínek náklady na identifikaci, popis životního cyklu některých objektů a jejich atributů nemusí být ekonomicky efektivní.
3. Jakékoliv důsledky denormalizace datového modelu v již vytvořeném informačním systému mohou být zmírněny důkladným předchozím výzkumem kódu a testováním.
4. Denormalizace je způsob, jak přesunout pracovní náklady z fáze výzkumu zdrojů dat a návrhu obchodního procesu do fáze vývoje, z období zavádění do období rozvoje systému.
5. K dosažení třetí normální formy databáze je vhodné usilovat, pokud:
- Směr změny automatizovaných obchodních procesů je obtížně předvídatelný.
- V rámci týmu pro implementaci a/nebo rozvoj je patrné slabé oddělení práce.
- Systémy, které jsou součástí integračního obvodu, se vyvíjejí podle vlastních plánů.
- Nesoulad dat může vést ke ztrátě klientů nebo peněz pro společnost.
6. Návrh modelu dat by měl být prováděn analytikem pouze ve vztahu k modelům cílového obchodního procesu a procesu v informačním systému. Pokud návrh modelu dat provádí vývojář, bude se muset ponořit do oboru natolik, aby například rozuměl rozdílům mezi hodnotami atributů — což je nezbytné pro vymezení atomárních atributů. Takže si bere na sebe neobvyklé funkce.
4 Úkol pro ilustraci
Představte si, že máte malou robotizovanou tavernu v přístavu. Váš tržní segment: námořníci a piráti, kteří přicházejí do přístavu a potřebují odpočinek. Námořníkům prodáváte čaj s tymiánem, zatímco pirátům rum a kostěné hřebeny pro česání vousů. Službu v taverně zajišťují robotická hosteska a robotický barman. Díky vysoké kvalitě a nízkým cenám jste vytlačili všechny konkurenty, takže každý, kdo vystoupí z lodi, přichází do vaší taverny, která je jediná v přístavu.
Komplex informačních systémů taverny se skládá z následujícího softwaru:
- Systém časného varování o zákazníkovi, který rozpoznává jeho kategorii podle charakteristických znaků.
- Systém řízení robotů-hostes a robotů-barmanů.
- Systém řízení skladu a dodávky na místo prodeje.
- Systém řízení vztahů s dodavateli (SRVD).
Proces:
Systém časného varování rozpoznává osoby sestupující z lodi. Pokud je člověk hladce oholen, určuje ho jako námořníka; pokud je u něj zjištěn vous, určuje ho jako piráta.
Při vstupu do taverny slyší host od robotické hostesky pozdrav podle své kategorie, například: „Ho-ho-ho, vážený piráte, prosím, jděte k stolu č. ...“
Host prochází k určenému stolu, kde robot-barmanka již připravila zboží podle kategorie. Robot-barmanka předává informaci do skladového systému, že další dávka dodávky by měla být zvýšena, skladová IS na základě skladových zbytků vytváří žádost o zásobování v SUOP.
Ať už systém včasného varování vyvinulo vaše interní IT, program pro řízení barmanských robotů vytvořil externí dodavatel speciálně pro vaše podnikání. A systémy pro řízení skladu a vztahů s dodavateli jsou přizpůsobenými krabicovými řešeními z trhu.
5. Příklady denormalizace a její vliv na vývoj SW
Při projektování podnikového procesu se dotazovaní odborníci v oboru jednomyslně shodli, že po celém světě piráti pijí rum a česají si vousy kostěnými hřebeny, zatímco námořníci pijí čaj s tymiánem a jsou vždy hladce oholeni.
Objevuje se rejstřík typů klientů ze dvou hodnot: 1 - piráti, 2 - námořníci, společný pro celé informační obrysy společnosti.
Systém varování o klientovi okamžitě ukládá výsledek zpracování obrázku jako identifikátor (ID) rozpoznaného klienta a jeho typ: námořníka nebo piráta.
ID rozpoznaného objektu
Kategorie klienta
100500
Pirátský
100501
Pirátský
100502
Námořník
Ještě jednou upozorníme, že
1. Naši námořníci jsou ve skutečnosti oholení lidé
2. Naši piráti jsou ve skutečnosti vousatí lidé
Jaké problémy je třeba v tomto případě odstranit, aby naše struktura směřovala k třetí normální formě:
- narušení atomárnosti atributu - Kategorie klienta
- směs analyzovaného faktu a závěru v jedné tabulce
- zafixovaná funkční závislost mezi atributy různých entit.
V normalizovaném tvaru bychom získali dvě tabulky:
- výsledek rozpoznání ve formě sady stanovených znaků,
ID rozpoznaného objektu
Vlasový porost na obličeji
100500
Ano
100501
Ano
100502
Ne
- výsledek určení typu klienta jako aplikace vložené v IS logiky pro interpretaci stanovených znaků
ID rozpoznaného objektu
ID identifikace
Kategorie klienta
100500
100001
Pirátský
100501
100002
Pirátský
100502
100003
Námořník
Jak normalizovaná organizace ukládání dat může usnadnit rozvoj komplexu IS? Představte si, že nečekaně získáte nové klienty. Nechť to budou japonské piráty, které mohou být bez vousů, ale nosí papouška na rameni, a ekologické piráty, které snadno poznáte podle modrého profilu Grety na levé hrudi.
Ekologičtí piráti samozřejmě nemohou používat kostěné hřebeny a požadují alternativu z recyklovaného mořského plastu.
Je nezbytné přepracovat algoritmy fungování programů v souladu s novými vstupy. Kdyby byla pravidla normalizace dodržena, museli byste pouze u některých systémů doplnit vstupy pro některé větve procesů a vytvořit nové větve pouze pro ty případy a v těch IS, kde má význam porost na obličeji. Ale protože pravidla nebyla dodržena, budete muset analyzovat celý kód ve všech obrysích, kde se používají hodnoty referenčního typu klientů, a jednoznačně určit, že v jednom případě by měl algoritmus brát v úvahu profesní činnost klienta, a v jiném fyzické vlastnosti.
V podobě, která se snaží o normalizaci, bychom získali dvě tabulky s operačními daty a dva rejstříky:
- výsledek rozpoznání ve formě sady stanovených znaků,
ID rozpoznaného objektu
Greta na levé hrudi
Pták na rameni
Vlasový porost na obličeji
100510
1
1
1
100511
0
0
1
100512
1
0
- výsledek určení typu klienta (nechť je to uživatelské zobrazení, ve kterém jsou zobrazeny popisy z rejstříků)
Znamená zjištěná denormalizace, že systémy nebude možné upravit podle nových podmínek? Samozřejmě, že ne. Pokud si představíme, že všechny IS byly vytvořeny jedním týmem s nulovou fluktuací zaměstnanců, vývoj je dobře dokumentovaný a informace v týmu jsou předávány bez ztrát, pak mohou být požadované změny provedeny s nepatrnými náklady na úsilí. Ale pokud se vrátíme k výchozím podmínkám úkolu, pouze na tisk protokolů společných jednání se utře 1,5 klávesnic a ještě 0,5 na zpracování nákupních procedur.
V uvedeném příkladu jsou porušeny všechny tři normální formy, zkusme je porušit jednotlivě.
Porušení první normální formy:
Předpokládejme, že zboží je na váš sklad dodáváno z dodavatelských skladů vyzvednutím pomocí jedné 1,5tunové dodávky, která patří vaší taverně. Velikost vašich objednávek je tak malá ve srovnání s objemy dodavatelů, že se vždy vykonávají přesně bez čekání na výrobu. Jsou v takovém obchodním procesu potřeba samostatné tabulky: vozidla, typy vozidel, je nutné rozlišovat plán a skutečnost ve vašich objednávkách odeslaných dodavatelům?
Jen si představte, kolik "zbytečných" spojení bude muset napsat váš programátor, pokud pro vývoj programu použije níže uvedený model.
Předpokládáme, že jsme se rozhodli, že navržená struktura je příliš složitá, pro naši situaci je rozdělení plánu a skutečnosti v zápise objednávky přebytečné a sestavená specifikace objednávky se přepisuje na základě výsledků převzetí doručeného zboží, vzácné nesrovnalosti a dodání nekvalitního zboží se vyřizují mimo informační systém.
A jednou vidíte, jak je celý sál taverny zaplněn rozhořčenými a neučesanými piráty. Co se stalo?
Ukázalo se, že spolu s růstem vašeho podnikání rostla i spotřeba. Kdysi bylo přijato manažerské rozhodnutí, že pokud byla dodávka přeplněná objemem a/nebo hmotností, což se stávalo velmi zřídka, dodavatel upřednostnil nakládku ve prospěch nápojů.
Nedodaný zboží se dostalo do další objednávky a odešlo při novém výjezdu, přítomnost minimálního zůstatku na skladu u taverny umožnila nevšimnout si vynechaných případů.
V přístavu zanikl poslední konkurent a vynechaný případ přeplnění dodávky, který byl zaslepen prioritizací založenou na předpokladu dostatečnosti minimálního zůstatku a občasného nedonášení vozidla, se stal běžnou praxí. Vytvořený systém bude dokonale fungovat podle zakotvených algoritmů a bude zcela zbaven možnosti sledovat systematické neplnění plánovaných objednávek. Pouze poškozená pověst a nespokojení zákazníci mohou odhalit problém.
Pozorný čtenář si jistě všiml, že objednané množství ve specifikaci objednávky (T_ORDER_SPEC) v oddíle 2 a v oddíle 5 může vyhovovat nebo nemusí vyhovovat požadavku první normální formy. Vše závisí na tom, zda mohou do stejného pole spadat různé jednotky měření podle vybraného sortimentu zboží.
Narušení druhé normální formy:
S rostoucími potřebami si pořizujete ještě několik dopravních prostředků různých velikostí. V uvedeném kontextu bylo vytvoření katalogu dopravních prostředků považováno za nadbytečné, a proto všechny algoritmy práce s daty, které slouží potřebám dopravy a skladu, vnímají pohyb zboží od dodavatele na sklad jako přepravu výhradně 1,5tunového dodávkového vozidla. Takže spolu s nákupem nových dopravních prostředků skutečně vytváříte katalog dopravních prostředků, ale při úpravě budete muset analyzovat celý kód, který se odkazuje na pohyb zboží, abyste zjistili, zda v každém konkrétním místě odkazujete na vlastnosti toho automobilu, se kterým podnikání začalo.
Narušení třetí normální formy:
V určitém okamžiku začnete vytvářet program loajality, objevuje se záznam stálého klienta. Proč například ztrácet čas na vytváření materiálních reprezentací, které uchovávají agregované údaje o prodeji jednotlivému klientovi pro využití v reportingu a předávání do analytických systémů, pokud na startu programu loajality vše, co zákazník zajímá, lze umístit do záznamu samotného klienta? A vskutku, na první pohled to smysl nedává. Ale pokaždé, když vaše podnikání připojí například nové prodejní kanály, mezi vašimi analytiky by měl být někdo, kdo si vzpomene, že existuje takový agregovaný atribut.
Při navrhování každého nového procesu, dejme tomu prodeje přes internet, prodeje prostřednictvím distributorů připojených ke společnému loajalitnímu systému, by si někdo měl pamatovat, že všechny nové procesy musí zajišťovat integritu dat na úrovni kódu. Pro průmyslovou databázi s tisíci tabulkami se toto jeví jako málo realizovatelný úkol.
Zkušený vývojář samozřejmě ví, jak eliminovat všechny zmíněné problémy, ale podle mého názoru úkolem zkušeného analytika je k nim nedovolit dojít.
Chtěl bych poděkovat za cennou zpětnou vazbu při přípravě publikace hlavnímu vývojáři Jevgeniji Jarušinovi.
Literatura
Connolly Thomas, Begg Caroline. Databáze. Návrh, implementace a údržba. Teorie a praxe.
Zdroj: habr.com
