Ahoj! Volám sa Andrej Semenov, som senior analytik v Sportmaster. V tomto príspevku chcem zdvihnúť otázku denormalizácie databáz ERP systémov. Preskúmame všeobecné podmienky a taktiež konkrétny príklad — povedzme, že to bude úžasná monopolná krčma pre pirátov a námorníkov. V tejto krčme musíme obsluhovať pirátov a námorníkov rôznymi spôsobmi, pretože predstavy o kráse a spotrebiteľské zvyky týchto vážených pánov sa podstatne líšia.
Ako dosiahnuť, aby boli všetci spokojní? Ako nezblázniť sa pri navrhovaní a podpore takého systému? Čo robiť, ak do krčmy začnú prichádzať nielen známi piráti a námorníci?
Všetko je pod katom. Ale poďme z poriadku.
1. Obmedzenia a predpoklady
Všetko, čo je uvedené, sa týka iba relačných databáz. Dobré, aj na internete dobre osvetlené, následky denormalizácie vo forme anomálií úprav, odstraňovania a vkladania nie sú skúmané. Mimo publikácie ostávajú prípady, keď je denormalizácia samozrejmou záležitosťou s klasickými príkladmi: séria a číslo pasu, dátum a čas a ďalšie.
V príspevku sú použité intuitívne zrozumiteľné a prakticky použiteľné definície normálnych foriem, bez odkazu na matematické pojmy. V takej forme, v akej ich možno aplikovať na prieskum skutočných obchodných procesov (OBP) a navrhovanie priemyselných softvérov.
Existuje názor, že návrh úložiska dát, nástrojov na tvorbu reportov a integračných dohôd (v ktorých sa používa tabuľkové zobrazenie informácií), sa líši od návrhu databáz ERP systémov tým, že pohodlie spotreby a aplikácia pre jeho dosiahnutie vedomou denormalizáciou môže mať prednosť pred ochranou integrity údajov. Zdieľam tento názor a nižšie uvedené sa týka výlučne modelov master dát a transakčných údajov ERP systémov.
Vysvetlenie normálnych foriem je uvedené na príklade, ktorý je väčšine čitateľov zrozumiteľný z bežného života. Avšak ako názorná ilustrácia sú v bodoch 4-5 zámerne použité doplnkovými fiktívnymi úlohami. Ak by sme to neurobili a vzali by sme nejaký učebnicový príklad, ako je model skladovania objednávok z bodu 2, mohli by sme sa ocitnúť v situácii, kedy bude pozornosť čitateľa presunutá z navrhnutého rozloženia procesu na osobnú skúsenosť a vnímanie toho, ako by mali byť procesy a modely skladovania dát v IS postavené. Inými slovami, vezmite dvoch kvalifikovaných IT analytikov, nech jeden poskytuje služby logistikom pre prepravu cestujúcich a druhý logistikom pre prepravu strojov na výrobu mikročipov. Požiadate ich, aby bez predchádzajúceho dohovoru o automatizovateľných BP vytvorili model údajov na uchovávanie informácií o železničnom lete.
Existuje nenulová pravdepodobnosť, že v navrhnutých modeloch nájdete nielen výrazne odlišný súbor atribútov, ale aj nezhodujúce sa množiny entít, pretože každý analytik sa opiera o jemu známe procesy a úlohy. A v takej situácii je nemožné povedať, ktorý model je „správny“, pretože neexistuje kritérium hodnotenia.
2. Normálne formy
Prvá normálna forma DB vyžaduje atomickosť všetkých atribútov.
Konkrétne, ak objekt A má nekľúčové atribúty a a b, tak že c=f(a,b) a v tabuľke popisujúcej objekt A uchovávate hodnotu atribútu c, tak v DB je porušená prvá normálna forma. Napríklad, ak sa v špecifikácii objednávky uvádza množstvo, ktorého jednotky závisia od typu tovaru: v jednom prípade to môžu byť kusy, v druhom litry, v treťom balenia pozostávajúce z kusov (v hore uvedenom modeli Good_count_WR), tak je v DB porušená atomickosť atribútov. V tomto prípade, aby sme mohli povedať, aký by mal byť tvar tabuľky v špecifikácii objednávky, potrebujeme cieľové opísanie procesu práce v IS, a keďže procesy môžu byť rôzne, môžu existovať aj „správne“ verzie.
Druhá normálna forma DB vyžaduje dodržiavanie prvej formy a vlastnej tabuľky pre každý entitu, ktorá sa týka pracovného procesu v IS. Ak v jednej tabuľke existujú závislosti s=f1(a) a d=f2(b) a neexistuje závislosť s=f3(b), potom je v tabuľke porušená druhá normálna forma. V uvedenom príklade v tabuľke „Objednávka“ neexistuje závislosť medzi objednávkou a adresou. Zmeňte názov ulice alebo mesta a neovplyvníte žiadne podstatné atribúty objednávky.
Tretia normálna forma DB vyžaduje dodržiavanie druhej normálnej formy a absenciu funkčných závislostí medzi atribútmi rôznych entít. Toto pravidlo sa dá vyjadriť takto: „všetko, čo môže byť vypočítané, by malo byť vypočítané“. Inými slovami, ak existujú dva objekty A a B. V tabuľke, ktorá uchováva atribúty objektu A, sa prejavuje atribút C, u objektu B existuje atribút b, taký, že existuje c=f4(b), potom je porušená tretia normálna forma. V nasledujúcom príklade atribút „Počet kusov“ (Total_count_WR) v zázname objednávky jasne vykazuje pokus o porušenie tretej normálnej formy.
3. Môj prístup k aplikácii normalizácie
1. Iba cieľový automatizovateľný obchodný proces môže poskytnúť analytikovi kritériá na identifikáciu entít a atribútov pri vytváraní modelu ukladania dát. Vytvorenie modelu procesu je povinnou podmienkou na vytvorenie normálneho modelu dát.
2. Dosiahnutie tretej normálnej formy v prísnom zmysle nemusí byť v reálnej praxi vytvárania ERP systémov účelné, ak sú splnené niektoré alebo všetky nasledujúce podmienky:
- automatizovateľné procesy sú zriedka vystavené zmenám,
- lehoty na výskum a vývoj sú stlačené,
- požiadavky na integritu dát sú podmienečne nízke (potenciálne chyby v priemyselných softvérových riešeniach nevedú k strate peňazí alebo zákazníkov zo strany dodávateľa softvéru)
- a podobne.
Pod uvedenými podmienkami náklady na identifikáciu, popis životného cyklu niektorých objektov a ich atribútov nemusia byť odôvodnené z hľadiska ekonomickej efektivity.
3. Akékoľvek následky denormalizácie modelu dát už vytvorenej IS môžu byť obmedzené dôkladným predbežným preskúmaním kódu a testovaním.
4. Denormalizácia je spôsob, ako preniesť prácu z fázy skúmania zdrojov dát a projektovania obchodného procesu do fázy vývoja, z obdobia implementácie do obdobia rozvoja systému.
5. K tretej normálnej forme DB je rozumné smerovať, ak:
- Zmena automatizovateľných obchodných procesov je ťažko prognózovateľná.
- V rámci tímu pre implementáciu a/alebo rozvoj je zjavné slabé prenikanie rozdelenia práce.
- Systémy zapojené do integračného okruhu sa vyvíjajú podľa vlastných plánov.
- Nezhoda v údajoch môže viesť k strate zákazníkov alebo peňazí pre spoločnosť.
6. Navrhnutie modelu dát by mal vykonávať analytik len v súvislosti s modelmi cieľového obchodného procesu a procesu v IS. Ak model dát navrhuje vývojár, bude sa musieť hlboko zaoberať predmetnou oblasťou, aby najmä pochopil rozdiel medzi hodnotami atribútov — čo je nevyhnutná podmienka na vyčlenenie atomárnych atribútov. Týmto spôsobom prevezme nevhodné funkcie.
4 Úloha na ilustráciu.
Predpokladajme, že máte malú robotizovanú tavernu v prístave. Vaša trhová segmentácia zahŕňa námorníkov a pirátov, ktorí prichádzajú do prístavu a potrebujú odpočinok. Námorníkom predávate čaj s tymianom, zatiaľ čo pirátom rom a kostiakové hrebeň na česanie brady. Službu v tavernu vykonáva robot-hosteska a robot-barman. Vďaka vysokej kvalite a nízkym cenám ste vytlačili všetkých konkurentov, takže každý, kto zostúpi z lode, prichádza do vašej taverny, ktorá je jediná v prístave.
Kombinácia informačných systémov taverny pozostáva z nasledujúceho softvéru:
- Systém včasného varovania o zákazníkovi, ktorý rozpoznáva jeho kategóriu podľa charakteristických znakov.
- Systém riadenia robotov-hostesiek a robotov-barmanov.
- Systém riadenia skladu a dodávky na predajné miesto.
- Systém riadenia vzťahov s dodávateľmi (CRM).
Proces:
Systém včasného varovania rozpoznáva ľudí, ktorí zostupujú z lode. Ak je osoba hladko oholená, určí ju ako námorníka, ak má osoba bradu, určuje sa ako pirát.
Keď vstúpi do taverny, hosť počuje od robota-hostesky pozdrav podľa svojej kategórie, napríklad: „Ho-ho-ho, vážený pirát, prejdite k stolu č.…“
Hosť prechádza k určenému stolu, kde robot-barman už pripravil pre neho tovar v súlade s kategóriou. Robot-barman odosiela informácie do skladového systému o tom, že nasledujúca zásielka by mala byť zväčšená, skladový IS na základe zostatkov v úložisku vytvára objednávku na nákup v SUOP.
Nech systém včasného upozornenia vyvinul váš interný IT tím, program na riadenie barových robotov vytvoril externý dodávateľ špeciálne pre váš biznis. Systémy pre riadenie skladu a vzťahov s dodávateľmi sú prispôsobenými riešeniami z trhu.
5. Príklady denormalizácie a jej vplyv na rozvoj softvéru
Pri projektovaní obchodného procesu oslovovaní odborníci z oblasti jednomyseľne uviedli, že po celom svete piráti pijú rum a česajú si brady kostennými hrebeňmi, zatiaľ čo námorníci pijú čaj s tymiánom a sú vždy hladko oholenými.
Objavuje sa zoznam typov klientov so žiadosťami: 1- piráti, 2 - námorníci, spoločný pre celý informačný obvod spoločnosti.
Systém upozornenia na klienta ihneď ukladá výsledok spracovania obrazu ako identifikátor (ID) rozpoznaného klienta a jeho typ: námorník alebo pirát.
ID Rozpoznaného objektu
Kategória klienta
100500
Pirátsky
100501
Pirátsky
100502
Námorník
Ešte raz upozorníme, že
1. Naši námorníci sú v skutočnosti oholení muži
2. Naši piráti sú v skutočnosti bradatí muži
Aké problémy je potrebné v tomto prípade odstrániť, aby sa naša štruktúra usilovala o tretí normálny tvar:
- porušenie atomarity atribútu - Kategória klienta
- zmiešanie analyzovaného faktu a výstupu v jednej tabuľke
- zaznamenaná funkčná závislosť medzi atribútmi rôznych entít.
V normalizovanej podobe by sme dostali dve tabuľky:
- výsledok rozpoznania vo forme súboru stanovených charakteristík,
ID Rozpoznaného objektu
Porasty na tvári
100500
Áno
100501
Áno
100502
Nie
- výsledok určenia typu klienta ako aplikácia zabudovanej logiky v IS na interpretáciu stanovených charakteristík
ID rozpoznaného objektu
ID identifikácie
Kategória klienta
100500
100001
Pirátsky
100501
100002
Pirátsky
100502
100003
Námorník
Ako môže normalizovaná organizácia ukladania dát uľahčiť rozvoj komplexu IS? Predpokladajme, že náhle získate nových zákazníkov. Nech sú to japonskí piráti, ktorí môžu mať chýbajúcu bradu, ale nosia papagája na pleci, a ekologickí piráti, ktorých ľahko spoznáte podľa modrého profilu Greta na ľavej hrudi.
Ekologickí piráti samozrejme nemôžu používať kostné hrebeň a požadujú analóg z recyklovaného morského plastu.
Je potrebné prepracovať algoritmy programov v súlade s novými vstupmi. Keby boli pravidlá normalizácie dodržané, museli by ste iba v časti systémov doplniť vstupy pre niektoré vetvy procesov a vytvoriť nové vetvy iba pre tie prípady a v tých IS, kde má význam ochlpenie na tvári. Ale pretože pravidlá neboli dodržané, budete musieť analyzovať celý kód vo všetkých obvodoch, kde sa používajú hodnoty referenčného typu klientov, a jednoznačne stanoviť, že v jednom prípade musí algoritmus brať do úvahy profesionálnu činnosť klienta, zatiaľ čo v inom fyzické vlastnosti.
V podobe, ktorú usiluje sa k normalizovanému, získali by sme dve tabuľky s prevádzkovými dátami a dva referenčné zdroje:
- výsledok rozpoznania vo forme súboru stanovených charakteristík,
ID rozpoznaného objektu
Greta na ľavej hrudi
Pták na pleci
Porasty na tvári
100510
1
1
1
100511
0
0
1
100512
1
0
- výsledok určenia typu klienta (nech je to užívateľské zobrazenie, v ktorom sú uvedené popisy z referenčných zdrojov)
Znamená zistená denormalizácia, že systémy nebude možné prispôsobiť novým podmienkam? Samozrejme, že nie. Ak si predstavíme, že všetky IS boli vytvorené jedným tímom s nulovou fluktuáciou zamestnancov, vývoj je dobre zdokladovaný a informácie sú v tíme prenášané bez strát, požadované zmeny môžu byť vykonané s nezanedbateľnými nákladmi. Ale ak sa vrátime k pôvodným podmienkam úlohy, iba vytlačenie protokolov spoločných diskusií zničí 1,5 klávesníc a ďalších 0,5 na vybavenie obstarávacích procedúr.
V uvedenom príklade sú porušené všetky tri normálne formy, poďme sa pokúsiť porušovať ich osobitne.
Porušenie prvej normálnej formy:
Predpokladajme, že tovar na vašu skladovú základňu je dodávaný zo skladov dodávateľov osobným vyzdvihnutím pomocou jedného 1,5-tonového dodávkového vozidla, ktoré patrí vašej krčme. Veľkosť vašich objednávok je tak malá v porovnaní s objemmi dodávateľov, že sú vždy vykonávané presne bez čakania na výrobu. Potrebujú sa pri takomto prevádzkovom modeli samostatné tabuľky: vozidlá, typy vozidiel, alebo je potrebné rozdeliť plán a fakt v vašich objednávkach odoslaných dodávateľom?
Len si predstavte, koľko "zbytočných" spojení budú musieť napísať vaši programátori, ak na vývoj programu použijú nižšie uvedený model.
Predpokladajme, že sme sa rozhodli, že navrhnutá štruktúra je zbytočne zložitá, pre náš prípad je rozdeľovanie plánu a skutočnosti v zázname objednávky zbytočná informácia a vytvorená špecifikácia objednávky sa prepisuje na základe výsledkov prijatia doručeného tovaru, zriedkavé prehozy a doručenie nekvalitného tovaru sa riešia mimo informačného systému.
A raz vidíte, ako je celý sál krčmy zaplnený rozhorčenými a neupravenými pirátmi. Čo sa stalo?
Ukázalo sa, že s rastom vášho podnikania rástlo aj spotrebovanie. Niekedy bolo prijaté manažérske rozhodnutie, že ak bol dodávkový automobil preťažený objemom a/alebo hmotnosťou, čo sa stávalo veľmi zriedka, dodávateľ uprednostnil načítanie v prospech nápojov.
Nedodaný tovar sa dostal do nasledujúcej objednávky a odišiel v novom lete, existencia minimálneho zostatku na sklade pri krčme umožnila ignorovať prehliadané prípady.
V prístave sa uzavrel posledný konkurent a prehliadaný prípad preťaženia dodávkového vozidla, ktorý bol obídený prioritizáciou založenou na predpoklade dostatočnosti minimálneho zostatku a občasnom nedorozumení prepravného vozidla, sa stal bežnou praxou. Vytvorený systém bude ideálne fungovať v súlade s algorithmy, ktoré sú v ňom zakotvené, a nebude mať žiadnu možnosť sledovať systematické nevykonávanie plánovaných objednávok. Iba poškodená povesť a nespokojní zákazníci môžu odhaliť problém.
Pozorný čitateľ si určite všimol, že objednané množstvo v špecifikácii objednávky (T_ORDER_SPEC) v sekcii 2 a v sekcii 5 môže zodpovedať alebo nemusí zodpovedať požiadavke prvej normálnej formy. Všetko závisí od toho, či môžu pri vybranom sortimente tovarov do jedného a toho istého poľa prísť rôzne podstatne jednotky merania.
Porušenie druhej normálnej formy:
S rastom vašich potrieb si zakúpite niekoľko dopravných prostriedkov rôznych rozmerov. V uvedenom kontexte bolo vytvorenie referenčného zoznamu dopravných prostriedkov považované za nadbytočné, a všetky algoritmy spracovania údajov, ktoré podporujú potreby dodávky a skladu, považujú presun nákladu od dodávateľa na sklad, za prepravu výlučne 1,5-tonovej dodávky. A tak, spolu s nákupom nových dopravných prostriedkov, vytvoríte referenčný zoznam dopravných prostriedkov, avšak pri úpravách budete musieť analyzovať celý kód, ktorý sa odvoláva na presun nákladu, aby ste zistili, či sa v každom jednotlivom prípade nepredpokladajú charakteristiky toho vozidla, s ktorým sa začínalo.
Porušenie tretej normálnej formy:
V nejakom momente začnete vytvárať program lojality a vznikne záznam stálych zákazníkov. Prečo, napríklad, strácať čas na vytváranie materiálnych reprezentácií, ktoré uchovávajú agregované údaje o predajoch konkrétnemu zákazníkovi na účely reportovania a odovzdania analytickým systémom, ak v štádiu spustenia programu lojality môže byť všetko, čo zaujíma zákazníka, uvedené priamo na zázname samotného klienta? A skutočne, na prvý pohľad, to dáva zmysel. Ale zakaždým, keď vaša firma pripojí nové predajné kanály, mal by medzi vašimi analytikmi byť niekto, kto si spomenie, že existuje taký agregovaný atribút.
Pri návrhu každého nového procesu, povedzme predaja cez internet, predaja cez distribútorov pripojených k spoločnej systéme lojality, niekto musí mať na pamäti, že všetky nové procesy musia zabezpečiť na úrovni kódu integritu údajov. Pre priemyselnú databázu s tisíckami tabuliek sa to zdá byť ťažko realizovateľnou úlohou.
Skúsený vývojár určite vie, ako eliminovať všetky vyššie uvedené problémy, ale domnievam sa, že úlohou skúseného analytika je zabrániť ich vzniku.
Chcem vyjadriť vďaku za cennú spätnú väzbu pri príprave publikácie hlavnému vývojárovi Jevgenijovi Jaruchinovi.
Literatúra
Connolly Thomas, Begg Caroline. Databázy. Návrh, implementácia a údržba. Teória a prax.
Zdroj: habr.com
