Ahoj! Volám sa Andrey Semenov, som senior analytik v Sportmaster. V tomto príspevku chcem nastoliť problém denormalizácie databáz ERP systémov. Pozrieme sa na všeobecné podmienky, aj na konkrétny príklad – povedzme, že by to bola nádherná monopolná krčma pre pirátov a námorníkov. V ktorej treba inak obsluhovať pirátov a námorníkov, pretože predstavy o kráse a konzumných vzoroch týchto dobrých pánov sa výrazne líšia.
Ako urobiť radosť všetkým? Ako sa môžete zblázniť pri navrhovaní a údržbe takéhoto systému? Čo robiť, ak do krčmy začnú prichádzať nielen obyčajní piráti a námorníci?
Všetko je pod rezom. Ale poďme pekne po poriadku.
1. Obmedzenia a predpoklady
Všetko uvedené platí len pre relačné databázy. Dôsledky denormalizácie vo forme anomálií modifikácie, vymazania a vloženia, ktoré sú dobre pokryté, a to aj na internete, sa neberú do úvahy. Mimo rozsahu tejto publikácie sú prípady, kedy je denormalizácia bežným miestom, s klasickými príkladmi: séria a číslo pasu, dátum a čas atď.
Príspevok používa intuitívne a prakticky použiteľné definície normálnych foriem bez odkazu na matematické pojmy. V takej podobe, v akej ich možno aplikovať pri skúmaní reálnych podnikových procesov (BP) a návrhu priemyselného softvéru.
Tvrdí sa, že návrh dátových skladov, nástrojov na podávanie správ a integračných dohôd (ktoré využívajú tabuľkové znázornenie informácií) sa líši od návrhu databáz systému ERP v tom, že jednoduchosť spotreby a použitie vedomej denormalizácie na jej dosiahnutie môže mať prednosť pred integritou. údaje o ochrane. Stotožňujem sa s týmto názorom a to, čo je popísané nižšie, platí výlučne pre kmeňové dáta a transakčné dátové modely ERP systémov.
Vysvetlenie normálnych foriem je uvedené na príklade, ktorý je pre väčšinu čitateľov zrozumiteľný na každodennej úrovni. Ako vizuálna ilustrácia však v odsekoch 4 – 5 bola zámerne použitá „fiktívna“ úloha. Ak to neurobíte a vezmete si nejaký učebnicový príklad, napríklad rovnaký model ukladania objednávok z bodu 2, môžete sa dostať do situácie, keď sa pozornosť čitateľa presunie z navrhovaného rozkladu procesu na model, na osobnú skúsenosť a vnímanie toho, ako treba budovať procesy a modely ukladania dát v IS. Inými slovami, vezmite si dvoch kvalifikovaných IT analytikov, nech jeden poskytuje služby logistikom prepravujúcim cestujúcich, druhý logistikom prepravujúcim stroje na výrobu mikročipov. Požiadajte ich bez toho, aby vopred diskutovali o automatizovaných BP, aby vytvorili dátový model na ukladanie informácií o ceste vlakom.
Je nenulová pravdepodobnosť, že v navrhovaných modeloch nájdete nielen výrazne odlišnú množinu atribútov, ale aj divergentné množiny entít, pretože každý analytik sa bude spoliehať na procesy a úlohy, ktoré sú mu známe. A v takejto situácii nie je možné povedať, ktorý model je „správny“, pretože neexistuje žiadne hodnotiace kritérium.
2. Normálne formy
Prvá normálna forma databázy vyžaduje atomicitu všetkých atribútov.
Najmä ak má objekt A nekľúčové atribúty a a b, takže c=f(a,b) a v tabuľke popisujúcej objekt A máte uloženú hodnotu atribútu c, potom je v databáze porušená prvá normálna forma . Napríklad, ak špecifikácia objednávky uvádza množstvo, ktorého merné jednotky závisia od typu produktu: v jednom prípade to môžu byť kusy, v inom litre, v treťom balenia pozostávajúce z kusov (v modeli vyššie Good_count_WR) , potom je v databáze narušená atomicita atribútov. V tomto prípade, aby ste povedali, aký má byť tabuľkový zhluk špecifikácie zákazky, potrebujete cielený popis pracovného procesu v IS a keďže procesy môžu byť rôzne, „správnych“ verzií môže byť veľa.
Druhá normálna forma databázy vyžaduje súlad s prvým formulárom a vlastnou tabuľkou pre každý subjekt súvisiaci s pracovným procesom v IS. Ak sú v jednej tabuľke závislosti c=f1(a) a d=f2(b) a nie je tam žiadna závislosť c=f3(b), potom je druhá normálna forma v tabuľke porušená. Vo vyššie uvedenom príklade neexistuje žiadna závislosť medzi objednávkou a adresou v tabuľke Objednávka. Zmeňte názov ulice alebo mesta a nebudete mať žiadny vplyv na podstatné atribúty objednávky.
Databáza tretej normálnej formy vyžaduje súlad s druhou normálnou formou a absenciu funkčných závislostí medzi atribútmi rôznych entít. Toto pravidlo možno formulovať takto: „všetko, čo sa dá vypočítať, sa musí vypočítať“. Inými slovami, ak existujú dva objekty A a B. V tabuľke s atribútmi objektu A sa prejavuje atribút C a objekt B má atribút b, takže existuje c=f4(b), potom tretia normálna forma je porušené. V nižšie uvedenom príklade atribút Množstvo kusov (Total_count_WR) v zázname objednávky jasne tvrdí, že porušuje tretiu normálnu formu
3. Môj prístup k uplatňovaniu normalizácie
1. Iba cieľový automatizovaný obchodný proces môže poskytnúť analytikovi kritériá na identifikáciu entít a atribútov pri vytváraní modelu ukladania údajov. Vytvorenie procesného modelu je predpokladom pre vytvorenie normálneho dátového modelu.
2. Dosiahnutie tretej normálnej formy v užšom zmysle nemusí byť praktické v skutočnej praxi vytvárania ERP systémov, ak sú splnené niektoré alebo všetky z nasledujúcich podmienok:
- automatizované procesy len zriedka podliehajú zmenám,
- termíny pre výskum a vývoj sú krátke,
- požiadavky na integritu dát sú relatívne nízke (potenciálne chyby v priemyselnom softvéri nevedú k strate peňazí alebo klientov zo strany zákazníka softvéru)
- atď
Za popísaných podmienok nemusia byť náklady na identifikáciu a popis životného cyklu niektorých objektov a ich atribútov opodstatnené z hľadiska ekonomickej efektívnosti.
3. Akékoľvek následky denormalizácie dátového modelu v už vytvorenom IS je možné zmierniť dôkladným predbežným štúdiom kódu a testovaním.
4. Denormalizácia je spôsob, ako preniesť mzdové náklady z fázy prieskumu dátových zdrojov a navrhovania podnikového procesu do fázy vývoja, z obdobia implementácie do obdobia vývoja systému.
5. Odporúča sa usilovať sa o tretiu normálnu formu databázy, ak:
- Smer zmien v automatizovaných podnikových procesoch je ťažké predpovedať
- V rámci implementačného a/alebo vývojového tímu je slabá deľba práce
- Systémy zahrnuté v integračnom okruhu sa vyvíjajú podľa vlastných plánov
- Nekonzistentnosť údajov môže viesť k tomu, že spoločnosť stratí zákazníkov alebo peniaze
6. Návrh dátového modelu by mal vykonávať analytik len v spojení s modelmi cieľového podnikového procesu a procesu v IS. Ak vývojár navrhuje dátový model, bude sa musieť ponoriť do predmetnej oblasti do takej miery, aby najmä pochopil rozdiel medzi hodnotami atribútov - nevyhnutná podmienka na izoláciu atómových atribútov. Preberá teda nezvyčajné funkcie.
4 Problém pre ilustráciu
Povedzme, že máte v prístave malú robotickú krčmu. Váš segment trhu: námorníci a piráti, ktorí prichádzajú do prístavu a potrebujú prestávku. Námorníkom predávate čaj s tymianom a pirátom rum a hrebene z kostí na česanie fúzov. Obsluhu v samotnej krčme zabezpečuje robotická hosteska a robot barman. Vďaka svojej vysokej kvalite a nízkym cenám ste všetkých vyhnali z konkurencie, takže každý vystupujúci z lode prichádza do vašej krčmy, ktorá je jediná v prístave.
Komplex krčmových informačných systémov pozostáva z nasledovného softvéru:
- Systém včasného varovania o klientovi, ktorý rozpoznáva svoju kategóriu na základe charakteristických znakov
- Riadiaci systém pre robotické hostesky a robot barmanov
- Systém riadenia skladu a dodávky na miesto predaja
- Systém riadenia vzťahov s dodávateľmi (SURP)
postup:
Systém včasného varovania rozpozná ľudí opúšťajúcich loď. Ak je človek hladko oholený, identifikuje ho ako námorníka, ak sa zistí, že má bradu, identifikuje ho ako piráta.
Pri vstupe do krčmy si hosť vypočuje pozdrav od hostiteľky robota podľa svojej kategórie, napríklad: „Ho-ho-ho, milý pirát, choď k stolu č...“
Hosť ide k určenému stolu, kde mu robot barman už pripravil tovar podľa kategórie. Robotický barman odošle do skladového systému informáciu, že ďalšia časť dodávky sa má zvýšiť, IS skladu na základe zostatkov na sklade vygeneruje požiadavku na nákup v systéme riadenia.
Zatiaľ čo systém včasného varovania môže byť vyvinutý vaším interným IT, program riadenia barového robota môže byť vytvorený externým dodávateľom špeciálne pre vaše podnikanie. A systémy na riadenie skladov a vzťahov s dodávateľmi sú prispôsobené balené riešenia z trhu.
5. Príklady denormalizácie a jej vplyv na vývoj softvéru
Pri navrhovaní obchodného procesu opýtaní odborníci na túto tému jednomyseľne uviedli, že piráti na celom svete pijú rum a česajú si fúzy hrebeňmi na kosti a námorníci pijú čaj s tymianom a sú vždy hladko oholení.
Objaví sa adresár typov klientov s dvomi hodnotami: 1 - piráti, 2 - námorníci, spoločné pre celý informačný okruh spoločnosti.
Systém upozornení klienta okamžite uloží výsledok spracovania obrazu ako identifikátor (ID) rozpoznaného klienta a jeho typ: námorník alebo pirát.
Identifikátor rozpoznaného objektu
Kategória klienta
100500
Pirát
100501
Pirát
100502
Námorník
Všimnime si to ešte raz
1. Naši námorníci sú vlastne oholení ľudia
2. Naši piráti sú vlastne bradatí ľudia
Aké problémy je v tomto prípade potrebné odstrániť, aby sa naša štruktúra snažila o tretiu normálnu formu:
- porušenie atomicity atribútu - Kategória klienta
- zmiešanie analyzovanej skutočnosti a záveru do jednej tabuľky
- pevný funkčný vzťah medzi atribútmi rôznych entít.
V normalizovanej forme by sme dostali dve tabuľky:
- výsledok rozpoznávania vo forme súboru zavedených znakov,
Identifikátor rozpoznaného objektu
Fúzy
100500
Да
100501
Да
100502
Nie
- výsledok určenia typu klienta ako aplikácia logiky vloženej do IS na interpretáciu stanovených charakteristík
Identifikátor rozpoznaného objektu
Identifikačné ID
Kategória klienta
100500
100001
Pirát
100501
100002
Pirát
100502
100003
Námorník
Ako môže normalizovaná organizácia ukladania údajov uľahčiť vývoj komplexu IP? Povedzme, že zrazu získate nových klientov. Nech sú to japonskí piráti, ktorí síce nemajú bradu, ale chodia s papagájom na pleci a ekologickí piráti, ktorých ľahko spoznáte podľa Gretinho modrého profilu na ľavej strane hrudi.
Environmentálni piráti, prirodzene, nemôžu používať kostené hrebene a požadujú analóg vyrobený z recyklovaného morského plastu.
Musíte prepracovať programové algoritmy v súlade s novými vstupmi. Ak by boli dodržané normalizačné pravidlá, potom by ste v niektorých systémoch museli len doplniť vstupy pre niektoré vetvy procesov a nové vetvy vytvárať len pre tie prípady a v tých IS, kde záleží na ochlpení tváre. Keďže však pravidlá neboli dodržané, budete musieť analyzovať celý kód v celom okruhu, kde sa používajú hodnoty adresára typu klienta, a jasne stanoviť, že v jednom prípade by mal algoritmus brať do úvahy profesionála. aktivity klienta a v iných telesných vlastnostiach.
Vo forme, ktorá hľadá po normalizácii by sme dostali dve tabuľky s prevádzkovými údajmi a dva adresáre:
- výsledok rozpoznávania vo forme súboru zavedených znakov,
Identifikátor rozpoznaného objektu
Gréta na ľavej strane hrudníka
Vták na ramene
Fúzy
100510
1
1
1
100511
0
0
1
100512
1
0
- výsledok určenia typu klienta (nech je to vlastný pohľad, v ktorom sa zobrazujú popisy z adresárov)
Znamená zistená denormalizácia, že systémy nemožno upraviť tak, aby spĺňali nové podmienky? Samozrejme, že nie. Ak si predstavíme, že všetky informačné systémy vytvoril jeden tím s nulovou fluktuáciou zamestnancov, vývoj je dobre zdokumentovaný a informácie sa v rámci tímu prenášajú bez strát, potom je možné požadované zmeny vykonať so zanedbateľne malým úsilím. Ak sa ale vrátime k pôvodným podmienkam problému, vymaže sa 1,5 klávesnice len na tlač protokolov zo spoločných rokovaní a ďalších 0,5 na spracovanie obstarávacích konaní.
Vo vyššie uvedenom príklade sú porušené všetky tri normálne formy, skúsme ich porušiť samostatne.
Porušenie prvej normálnej formy:
Povedzme, že tovar je doručený do vášho skladu zo skladov dodávateľov vyzdvihnutím pomocou jednej 1.5-tonovej gazely, ktorá patrí vašej krčme. Veľkosť vašich objednávok je v porovnaní s obratom dodávateľov taká malá, že sa vždy vybavia individuálne bez čakania na výrobu. Potrebujete samostatné tabuľky s takýmto obchodným procesom: vozidlá, typy vozidiel, je potrebné oddeliť plán a skutočnosť v objednávkach na odchádzajúcich dodávateľov?
Len si predstavte, koľko „dodatočných“ spojení budú musieť vaši programátori napísať, ak použijete na vývoj programu nižšie uvedený model.
Povedzme, že sme sa rozhodli, že navrhovaná štruktúra je zbytočne zložitá, v našom prípade je oddelenie plánu a skutočnosti v zázname objednávky nadbytočná informácia a vygenerovaná špecifikácia objednávky sa prepíše na základe výsledkov prijatia došlého tovaru, ojedinelé chyby -triedenie a príchod tovaru neadekvátnej kvality sa rieši mimo IS.
A potom jedného dňa uvidíte, ako je celá sála krčmy plná rozhorčených a zanedbaných pirátov. Čo sa stalo?
Ukázalo sa, že s rastom vášho podnikania rástla aj vaša spotreba. Kedysi padlo rozhodnutie vedenia, že ak bude gazela objemovo a/alebo váhovo preťažená, čo bolo extrémne zriedkavé, dodávateľ uprednostní náklad v prospech nápojov.
Nedodaný tovar skončil v ďalšej objednávke a odišiel novým letom, prítomnosť minimálneho zostatku v sklade v krčme umožnila nevšimnúť si chýbajúce prípady.
Posledný konkurent zavrel v prístave a prepichnutý prípad preťaženia gazelou, obídený uprednostňovaním na základe predpokladu dostatku minimálneho zostatku a periodického podťažovania vozidla, sa stal bežnou praxou. Vytvorený systém bude v ideálnom prípade fungovať v súlade s algoritmami v ňom zabudovanými a bude zbavený možnosti sledovať systematické neplnenie plánovaných zákaziek. Problém odhalí iba poškodená povesť a nespokojní zákazníci.
Pozorný čitateľ si mohol všimnúť, že objednané množstvo v špecifikácii objednávky (T_ORDER_SPEC) v časti 2 a časti 5 môže, ale nemusí spĺňať požiadavku prvej normálnej formy. Všetko závisí od toho, či vzhľadom na vybraný sortiment tovaru môžu do toho istého odboru spadať v podstate rôzne merné jednotky.
Porušenie druhej normálnej formy:
Ako vaše potreby rastú, kupujete si niekoľko ďalších vozidiel rôznych veľkostí. V uvedenom kontexte bolo vytvorenie adresára vozidiel považované za nadbytočné, v dôsledku čoho všetky algoritmy spracovania dát slúžiace potrebám dodávky a skladu vnímajú pohyb nákladu od dodávateľa do skladu ako let výlučne 1,5-tonovej gazela. Takže spolu s nákupom nových vozidiel stále vytvárate adresár vozidiel, ale pri jeho finalizácii budete musieť analyzovať všetok kód, ktorý odkazuje na pohyb nákladu, aby ste zistili, či na každom konkrétnom mieste sú odkazy na vlastnosti. samotného vozidla, z ktorého podnikanie začalo.
Porušenie tretej normálnej formy:
V určitom okamihu začnete vytvárať vernostný program, objaví sa záznam o pravidelnom zákazníkovi. Prečo napríklad tráviť čas vytváraním materiálových pohľadov, ktoré uchovávajú agregované údaje o predaji jednotlivému klientovi na použitie pri reportovaní a prenose do analytických systémov, ak na začiatku vernostného programu je možné do záznamov klienta umiestniť všetko, čo zákazníka zaujíma ? A veru, na prvý pohľad to nemá zmysel. Ale zakaždým, keď vaša firma prepojí napríklad nové predajné kanály, medzi vašimi analytikmi by mal byť niekto, kto si zapamätá, že takýto atribút agregácie existuje.
Pri navrhovaní každého nového procesu, napríklad predaj na internete, predaj cez distribútorov napojených na spoločný vernostný systém, musí mať niekto na pamäti, že všetky nové procesy musia zabezpečiť integritu dát na úrovni kódu. Pre priemyselnú databázu s tisíckami tabuliek sa to javí ako nemožná úloha.
Skúsený vývojár samozrejme vie, ako zastaviť všetky vyššie uvedené problémy, ale podľa môjho názoru nie je úlohou skúseného analytika vyniesť ich na svetlo.
Rád by som poďakoval poprednému vývojárovi Evgeniyovi Yarukhinovi za jeho cennú spätnú väzbu počas prípravy publikácie.
Literatúra
Connolly Thomas, Begg Caroline. Databáza. Návrh, implementácia a podpora. Teória a prax
Zdroj: hab.com