Ahoj! Jmenuji se Andrey Semenov, jsem senior analytik ve společnosti Sportmaster. V tomto příspěvku chci nastolit problém denormalizace databází ERP systému. Podíváme se na obecné podmínky i na konkrétní příklad – řekněme, že by to byla nádherná monopolní krčma pro piráty a námořníky. Ve kterém se pirátům a námořníkům musí podávat jinak, protože představy o kráse a konzumních vzorech těchto hodných pánů se výrazně liší.
Jak udělat radost všem? Jak se můžete vyhnout šílenství při navrhování a údržbě takového systému? Co dělat, když do hospody začnou chodit nejen obvyklí piráti a námořníci?
Vše je pod řezem. Ale pojďme popořadě.
1. Omezení a předpoklady
Vše výše uvedené platí pouze pro relační databáze. Důsledky denormalizace ve formě anomálií modifikace, mazání a vkládání, které jsou dobře pokryty, a to i na internetu, se neberou v úvahu. Mimo rámec této publikace jsou případy, kdy je denormalizace běžným místem, s klasickými příklady: série a číslo pasu, datum a čas atd.
Příspěvek používá intuitivní a prakticky použitelné definice normálních forem, bez odkazu na matematické pojmy. V podobě, ve které je lze aplikovat na zkoumání reálných podnikových procesů (BP) a navrhování průmyslového softwaru.
Tvrdí se, že návrh datových skladů, nástrojů pro vytváření zpráv a integračních dohod (které využívají tabulkové reprezentace informací) se liší od návrhu databází systému ERP v tom, že snadnost spotřeby a použití vědomé denormalizace k jejímu dosažení může mít přednost před integritou. údaje o ochraně. Sdílím tento názor a to, co je popsáno níže, platí pouze pro kmenová data a transakční datové modely ERP systémů.
Vysvětlení normálních forem je uvedeno na příkladu, který je pro většinu čtenářů srozumitelný na každodenní úrovni. Jako vizuální ilustrace však v odstavcích 4–5 byl záměrně použit „fiktivní“ úkol. Pokud to neuděláte a vezmete si nějaký učebnicový příklad, například stejný model ukládání zakázek z bodu 2, můžete se dostat do situace, kdy se pozornost čtenáře přesune z navrhovaného rozkladu procesu na model, k osobní zkušenosti a vnímání toho, jak je třeba budovat procesy a modely pro ukládání dat v IS. Jinými slovy, vezměte si dva kvalifikované IT analytiky, jeden ať poskytuje služby logistikům přepravujícím cestující a druhý logistům přepravujícím stroje na výrobu mikročipů. Požádejte je, aniž by předem probírali automatizované BP, aby vytvořili datový model pro ukládání informací o cestě vlakem.
Je nenulová pravděpodobnost, že v navrhovaných modelech najdete nejen výrazně odlišnou sadu atributů, ale také divergentní sady entit, protože každý analytik se bude spoléhat na procesy a úkoly, které jsou mu známé. A v takové situaci nelze říci, který model je „správný“, protože neexistuje žádné hodnotící kritérium.
2. Normální formy
První normální forma databáze vyžaduje atomičnost všech atributů.
Konkrétně, pokud má objekt A neklíčové atributy a a b, takže c=f(a,b) a v tabulce popisující objekt A uložíte hodnotu atributu c, pak je v databázi porušena první normální forma . Pokud je například ve specifikaci objednávky uvedeno množství, jehož měrné jednotky závisí na typu produktu: v jednom případě to mohou být kusy, v jiném litry, ve třetím balení skládající se z kusů (v modelu výše Good_count_WR) , pak je v databázi narušena atomičnost atributů. V tomto případě, aby bylo možné říci, jaký by měl být shluk tabulek specifikace zakázky, potřebujete cílený popis pracovního procesu v IS, a protože procesy mohou být různé, může existovat mnoho „správných“ verzí.
Druhá normální forma databáze vyžaduje u každého subjektu souvisejícího s pracovním procesem v IS dodržení prvního formuláře a vlastní tabulky. Pokud jsou v jedné tabulce závislosti c=f1(a) a d=f2(b) a není zde žádná závislost c=f3(b), pak je v tabulce porušena druhá normální forma. Ve výše uvedeném příkladu neexistuje žádná závislost mezi objednávkou a adresou v tabulce Objednávka. Změňte název ulice nebo města a nebudete mít žádný vliv na podstatné atributy objednávky.
Třetí databáze normálního tvaru vyžaduje soulad s druhou normální formou a absenci funkčních závislostí mezi atributy různých entit. Toto pravidlo lze formulovat následovně: „vše, co lze vypočítat, se musí vypočítat“. Jinými slovy, pokud existují dva objekty A a B. V tabulce uchovávající atributy objektu A se projevuje atribut C a objekt B má atribut b, takže existuje c=f4(b), pak třetí normální forma je porušena. V níže uvedeném příkladu atribut Množství kusů (Total_count_WR) v záznamu objednávky jasně tvrdí, že porušuje třetí normální formu
3. Můj přístup k aplikaci normalizace
1. Pouze cílový automatizovaný obchodní proces může poskytnout analytikovi kritéria pro identifikaci entit a atributů při vytváření modelu ukládání dat. Vytvoření procesního modelu je předpokladem pro vytvoření normálního datového modelu.
2. Dosažení třetí normální formy v užším slova smyslu nemusí být ve skutečné praxi vytváření systémů ERP praktické, pokud jsou splněny některé nebo všechny z následujících podmínek:
- automatizované procesy jen zřídka podléhají změnám,
- termíny pro výzkum a vývoj jsou napjaté,
- požadavky na integritu dat jsou relativně nízké (potenciální chyby v průmyslovém softwaru nevedou ke ztrátě peněz nebo klientů ze strany zákazníka softwaru)
- atd.
Za popsaných podmínek nemusí být náklady na identifikaci a popis životního cyklu některých objektů a jejich atributů z hlediska ekonomické efektivnosti oprávněné.
3. Případné důsledky denormalizace datového modelu v již vytvořeném IS lze zmírnit důkladným předběžným studiem kódu a testováním.
4. Denormalizace je způsob, jak přenést mzdové náklady z fáze průzkumu datových zdrojů a návrhu podnikového procesu do fáze vývoje, z období implementace do období vývoje systému.
5. Je vhodné usilovat o třetí normální formu databáze, pokud:
- Směr změn v automatizovaných obchodních procesech je obtížné předvídat
- V rámci implementačního a/nebo vývojového týmu je slabá dělba práce
- Systémy zahrnuté v integračním okruhu se vyvíjejí podle vlastních plánů
- Nekonzistence dat může vést ke ztrátě zákazníků nebo peněz
6. Návrh datového modelu by měl provádět analytik pouze ve spojení s modely cílového podnikového procesu a procesu v IS. Pokud vývojář navrhuje datový model, bude se muset ponořit do předmětné oblasti do takové míry, aby zejména pochopil rozdíl mezi hodnotami atributů – nezbytnou podmínkou pro izolaci atomických atributů. Přebírá tedy neobvyklé funkce.
4 Problém pro ilustraci
Řekněme, že máte v přístavu malou robotickou tavernu. Váš segment trhu: námořníci a piráti, kteří připlouvají do přístavu a potřebují si odpočinout. Námořníkům prodáváte čaj s tymiánem a pirátům rum a hřebeny z kostí na česání vousů. Obsluhu v samotné taverně zajišťuje robotická hosteska a robot barman. Díky své vysoké kvalitě a nízkým cenám jste vyhnali své konkurenty, takže každý vystupující z lodi přichází do vaší krčmy, která je jediná v přístavu.
Komplex krčmových informačních systémů se skládá z následujícího softwaru:
- Systém včasného varování o klientovi, který rozpoznává svou kategorii na základě charakteristických znaků
- Řídicí systém pro robotické hostesky a robotické barmany
- Systém řízení skladů a dodávek na místo prodeje
- Systém řízení vztahů s dodavateli (SURP)
Postup:
Systém včasného varování rozpozná lidi opouštějící loď. Pokud je člověk hladce oholený, identifikuje ho jako námořníka, pokud se zjistí, že má člověk plnovous, identifikuje ho jako piráta.
Při vstupu do hospody host uslyší pozdrav od hostitelky robota podle své kategorie, například: „Ho-ho-ho, milý piráte, jdi ke stolu č...“
Host jde k určenému stolu, kde mu robot barman již připravil zboží podle kategorie. Robotický barman předá skladovému systému informaci, že má být navýšena další část dodávky, IS skladu na základě zbývajících zůstatků na skladě vygeneruje v řídicím systému požadavek na nákup.
Zatímco systém včasného varování mohl být vyvinut vaším interním IT oddělením, program pro správu barových robotů mohl být vytvořen externím dodavatelem speciálně pro váš podnik. A systémy pro řízení skladů a vztahů s dodavateli jsou přizpůsobená balená řešení z trhu.
5. Příklady denormalizace a její vliv na vývoj softwaru
Při navrhování obchodního procesu dotázaní odborníci jednomyslně konstatovali, že piráti po celém světě pijí rum a vousy si česají hřebínky na kosti a námořníci pijí čaj s tymiánem a jsou vždy hladce oholení.
Objeví se adresář typů klientů se dvěma hodnotami: 1 - piráti, 2 - námořníci, společný pro celý informační okruh společnosti.
Systém upozornění klienta okamžitě uloží výsledek zpracování obrazu jako identifikátor (ID) rozpoznaného klienta a jeho typ: námořník nebo pirát.
ID rozpoznaného objektu
Kategorie klienta
100500
Pirát
100501
Pirát
100502
Seaman
Všimněme si toho ještě jednou
1. Naši námořníci jsou ve skutečnosti oholení lidé
2. Naši piráti jsou vlastně vousatí lidé
Jaké problémy je v tomto případě třeba odstranit, aby naše struktura usilovala o třetí normální formu:
- porušení atomicity atributu – kategorie klienta
- smíchání analyzované skutečnosti a závěru v jedné tabulce
- pevný funkční vztah mezi atributy různých entit.
V normalizované podobě bychom dostali dvě tabulky:
- výsledek rozpoznání ve formě souboru zavedených vlastností,
ID rozpoznaného objektu
Vousy
100500
Ano
100501
Ano
100502
Ne
- výsledek určení typu klienta jako aplikace logiky zabudované v IS pro interpretaci stanovených charakteristik
ID rozpoznaného objektu
Identifikační ID
Kategorie klienta
100500
100001
Pirát
100501
100002
Pirát
100502
100003
Seaman
Jak může normalizovaná organizace pro ukládání dat usnadnit vývoj komplexu IP? Řekněme, že najednou získáte nové klienty. Ať jsou to japonští piráti, kteří sice nemají vousy, ale chodí s papouškem na rameni, a ekologičtí piráti, ty snadno poznáte podle Gretina modrého profilu na levé straně hrudi.
Ekologičtí piráti přirozeně nemohou používat kostěné hřebeny a vyžadují analog vyrobený z recyklovaného mořského plastu.
Musíte přepracovat programové algoritmy v souladu s novými vstupy. Pokud by byla dodržena normalizační pravidla, pak byste v některých systémech museli pouze doplnit vstupy pro některé procesní větve a nové větve vytvořit pouze pro ty případy a v těch IS, kde záleží na vousech. Ale protože pravidla nebyla dodržena, budete muset analyzovat celý kód v celém okruhu, kde se používají hodnoty adresáře typu klienta, a jasně stanovit, že v jednom případě by měl algoritmus brát v úvahu profesionální aktivity klienta a dalších fyzických rysů.
V takové podobě hledá k normalizaci bychom dostali dvě tabulky s provozními daty a dva adresáře:
- výsledek rozpoznání ve formě souboru zavedených vlastností,
ID rozpoznaného objektu
Greta na levé straně hrudi
Pták na rameni
Vousy
100510
1
1
1
100511
0
0
1
100512
1
0
- výsledek určení typu klienta (nechť je to vlastní pohled, ve kterém se zobrazují popisy z adresářů)
Znamená zjištěná denormalizace, že systémy nelze upravit tak, aby splňovaly nové podmínky? Samozřejmě že ne. Pokud si představíme, že všechny informační systémy vytvořil jeden tým s nulovou fluktuací zaměstnanců, vývoj je dobře zdokumentován a informace se v rámci týmu přenášejí beze ztrát, pak lze požadované změny provést se zanedbatelně malým úsilím. Pokud se ale vrátíme k původním podmínkám problému, vymaže se 1,5 klávesnice jen pro tisk protokolů společných jednání a dalších 0,5 pro zpracování zadávacích řízení.
Ve výše uvedeném příkladu jsou porušeny všechny tři normální formy, zkusme je porušit samostatně.
Porušení první normální formy:
Řekněme, že zboží je do vašeho skladu dodáváno ze skladů dodavatelů vyzvednutím pomocí jedné 1.5tunové gazely, která patří vaší krčmě. Velikost vašich objednávek je v poměru k obratu dodavatelů tak malá, že jsou vždy realizovány jednotlivě bez čekání na výrobu. Potřebujete samostatné tabulky s takovým obchodním procesem: vozidla, typy vozidel, je nutné v objednávkách oddělovat plán a skutečnost odcházejícím dodavatelům?
Jen si představte, kolik „nadbytečných“ spojení budou muset vaši programátoři napsat, pokud použijete níže uvedený model k vývoji programu.
Řekněme, že jsme se rozhodli, že navrhovaná struktura je zbytečně složitá, v našem případě je oddělení plánu a skutečnosti v záznamu objednávky nadbytečná informace a vygenerovaná specifikace objednávky se přepíše na základě výsledků přejímky došlého zboží, ojedinělé chyby -třídění a příchod zboží nevyhovující kvality se řeší mimo IS.
A pak jednoho dne uvidíte, jak je celý sál hospody plný rozhořčených a neudržovaných pirátů. Co se stalo?
Ukázalo se, že s růstem vašeho podnikání rostla i vaše spotřeba. Kdysi bylo přijato rozhodnutí vedení, že pokud bude gazela přetížena objemem a/nebo hmotností, což bylo extrémně vzácné, dodavatel upřednostní náklad ve prospěch nápojů.
Nedodané zboží skončilo v další objednávce a odešlo novým letem, přítomnost minimálního zůstatku ve skladu v hospodě umožnila nevšimnout si chybějících případů.
Poslední soutěžící zavřel v přístavu a proražený případ přetížení gazel, obešel se upřednostňováním na základě předpokladu dostatku minimálního vyvážení a periodického podtěžování vozidla, se stal běžnou praxí. Vytvořený systém bude v ideálním případě fungovat v souladu s algoritmy v něm zabudovanými a bude zbaven jakékoli možnosti sledovat systematické neplnění plánovaných zakázek. Problém odhalí pouze poškozená pověst a nespokojení zákazníci.
Pozorný čtenář si mohl všimnout, že objednané množství ve specifikaci objednávky (T_ORDER_SPEC) v části 2 a části 5 může, ale nemusí splňovat požadavek první normální formy. Vše závisí na tom, zda při zvoleném sortimentu zboží mohou do stejného oboru spadat v podstatě různé měrné jednotky.
Porušení druhé normální formy:
Jak vaše potřeby rostou, kupujete si několik dalších vozidel různých velikostí. Ve výše uvedeném kontextu bylo vytvoření adresáře vozidel považováno za nadbytečné, v důsledku toho všechny algoritmy zpracování dat sloužící potřebám dodávky a skladu vnímají pohyb nákladu od dodavatele do skladu jako let výhradně 1,5 tuny. gazela. Takže spolu s nákupem nových vozidel stále vytváříte adresář vozidel, ale při jeho finalizaci budete muset analyzovat veškerý kód, který odkazuje na pohyb nákladu, abyste zjistili, zda na každém konkrétním místě jsou odkazy na vlastnosti. samotného vozidla, ze kterého podnikání začalo.
Porušení třetí normální formy:
V určitém okamžiku začnete vytvářet věrnostní program, objeví se záznam běžného zákazníka. Proč například trávit čas vytvářením materiálových pohledů, které ukládají agregovaná data o prodejích jednotlivému klientovi pro použití při reportování a přenosu do analytických systémů, když na začátku věrnostního programu lze do záznamů klienta umístit vše, co zákazníka zajímá ? A skutečně to na první pohled nemá smysl. Ale pokaždé, když vaše firma propojí například nové prodejní kanály, měl by mezi vašimi analytiky být někdo, kdo si bude pamatovat, že takový atribut agregace existuje.
Při navrhování každého nového procesu, například prodeje na internetu, prodeje prostřednictvím distributorů napojených na společný věrnostní systém, musí mít někdo na paměti, že všechny nové procesy musí zajistit integritu dat na úrovni kódu. Pro průmyslovou databázi s tisíci tabulkami se to zdá jako nemožný úkol.
Zkušený vývojář samozřejmě ví, jak všechny výše uvedené problémy zastavit, ale podle mého názoru není úkolem zkušeného analytika je vynést na světlo.
Rád bych vyjádřil svou vděčnost přednímu vývojáři Evgeniy Yarukhinovi za jeho cennou zpětnou vazbu během přípravy publikace.
Literatura
Connolly Thomas, Begg Caroline. Databáze. Návrh, realizace a podpora. Teorie a praxe
Zdroj: www.habr.com