Zdravo! Moje ime je Andrej Semenov, sem višji analitik pri Sportmasterju. V tej objavi želim izpostaviti vprašanje denormalizacije baz podatkov sistema ERP. Ogledali si bomo splošne pogoje, pa tudi konkreten primer - recimo, da bi bila to čudovita monopolna gostilna za pirate in mornarje. V kateri je treba piratom in mornarjem streči drugače, saj so predstave o lepoti in potrošniški vzorci teh dobrih gospodov bistveno drugačne.
Kako osrečiti vse? Kako se lahko izognete norosti pri načrtovanju in vzdrževanju takega sistema? Kaj storiti, če v gostilno ne začnejo prihajati le običajni pirati in mornarji?
Vse je pod rezom. A pojdimo po vrsti.
1. Omejitve in predpostavke
Vse zgoraj navedeno velja le za relacijske baze podatkov. Posledice denormalizacije v obliki anomalij spreminjanja, brisanja in vstavljanja, ki so dobro pokrite, tudi na internetu, niso upoštevane. Zunaj obsega te publikacije so primeri, kjer je denormalizacija pogosta, s klasičnimi primeri: serija in številka potnega lista, datum in čas itd.
Objava uporablja intuitivne in praktično uporabne definicije normalnih oblik, brez sklicevanja na matematične izraze. V obliki, v kateri jih je mogoče uporabiti pri pregledu realnih poslovnih procesov (BP) in oblikovanju industrijske programske opreme.
Trdi se, da se zasnova podatkovnih skladišč, orodij za poročanje in sporazumov o integraciji (ki uporabljajo tabelarične predstavitve informacij) razlikuje od zasnove podatkovnih baz sistema ERP v tem, da ima lahko enostavnost uporabe in uporaba zavestne denormalizacije za njeno doseganje prednost pred celovitostjo. podatke o zaščiti. Strinjam se s tem mnenjem in to, kar je opisano spodaj, velja izključno za modele glavnih podatkov in transakcijskih podatkov sistemov ERP.
Razlaga normalnih oblik je podana na primeru, ki je večini bralcev razumljiv na vsakdanji ravni. Vendar je bila kot vizualna ilustracija v odstavkih 4–5 namenoma uporabljena »izmišljena« naloga. Če tega ne storite in vzamete kakšen učbeniški primer, na primer isti model shranjevanja naročila iz točke 2, se lahko znajdete v situaciji, ko bo bralčev fokus premaknjen s predlagane dekompozicije procesa na model, na osebne izkušnje in dojemanje, kako morajo biti zgrajeni procesi in modeli shranjevanja podatkov v IS. Z drugimi besedami, vzemite dva usposobljena IT analitika, eden naj opravlja storitve logistov, ki prevažajo potnike, drugi pa logistov, ki prevažajo stroje za proizvodnjo mikročipov. Prosite jih, ne da bi vnaprej razpravljali o avtomatiziranih BP, naj ustvarijo podatkovni model za shranjevanje informacij o potovanju z železnico.
Obstaja neničelna verjetnost, da boste v predlaganih modelih našli ne le opazno drugačen nabor atributov, temveč tudi različne nabore entitet, saj se bo vsak analitik zanašal na procese in naloge, ki jih pozna. In v takšni situaciji je nemogoče reči, kateri model je "pravilen", ker ni merila za ocenjevanje.
2. Normalne oblike
Prva običajna oblika baze podatkov zahteva atomičnost vseh atributov.
Še posebej, če ima objekt A neključna atributa a in b, tako da je c=f(a,b) in v tabeli, ki opisuje objekt A, shranite vrednost atributa c, potem je prva normalna oblika v bazi podatkov kršena . Na primer, če je v specifikaciji naročila navedena količina, katere merske enote so odvisne od vrste izdelka: v enem primeru so lahko kosi, v drugem litri, v tretjem paketi, sestavljeni iz kosov (v zgornjem modelu Good_count_WR) , potem je atomičnost atributov v bazi podatkov kršena. V tem primeru, da bi povedali, kakšna naj bo gruča tabele specifikacije naročila, potrebujete ciljani opis delovnega procesa v IS, in ker so procesi lahko različni, je lahko "pravilnih" različic veliko.
Druga običajna oblika baze podatkov zahteva skladnost s prvim obrazcem in svojo tabelo za vsako entiteto, ki se nanaša na proces dela v IS. Če sta v eni tabeli odvisnosti c=f1(a) in d=f2(b) in ni odvisnosti c=f3(b), potem je druga normalna oblika v tabeli kršena. V zgornjem primeru ni odvisnosti med naročilom in naslovom v tabeli naročil. Spremenite ime ulice ali mesta in ne boste imeli vpliva na bistvene lastnosti naročila.
Tretja običajna baza podatkov zahteva skladnost z drugo normalno obliko in odsotnost funkcionalnih odvisnosti med atributi različnih entitet. To pravilo lahko formuliramo takole: "vse, kar je mogoče izračunati, mora biti izračunano." Z drugimi besedami, če obstajata dva objekta A in B. V tabeli, ki shranjuje atribute objekta A, se manifestira atribut C, objekt B pa ima atribut b, tako da c=f4(b) obstaja, potem tretja normalna oblika je kršena. V spodnjem primeru atribut Količina kosov (Total_count_WR) v zapisu naročila jasno trdi, da krši tretjo običajno obliko
3. Moj pristop k uporabi normalizacije
1. Samo ciljni avtomatizirani poslovni proces lahko analitiku zagotovi merila za prepoznavanje entitet in atributov pri ustvarjanju modela shranjevanja podatkov. Ustvarjanje modela procesa je predpogoj za ustvarjanje običajnega podatkovnega modela.
2. Doseganje tretje normalne oblike v strogem pomenu morda ne bo praktično v dejanski praksi ustvarjanja sistemov ERP, če so izpolnjeni nekateri ali vsi naslednji pogoji:
- avtomatizirani procesi se redko spreminjajo,
- roki za raziskave in razvoj so kratki,
- zahteve za celovitost podatkov so relativno nizke (morebitne napake v industrijski programski opremi ne povzročijo izgube denarja ali strank s strani kupca programske opreme)
- itd
V opisanih pogojih stroški identifikacije in opisa življenjskega cikla nekaterih predmetov in njihovih lastnosti morda niso upravičeni z vidika ekonomske učinkovitosti.
3. Morebitne posledice denormalizacije podatkovnega modela v že izdelanem IS lahko omilimo s temeljito predhodno študijo kode in testiranjem.
4. Denormalizacija je način prenosa stroškov dela iz faze raziskovanja podatkovnih virov in oblikovanja poslovnega procesa v razvojno fazo, iz obdobja implementacije v obdobje razvoja sistema.
5. Priporočljivo je, da si prizadevamo za tretjo normalno obliko baze podatkov, če:
- Smer sprememb avtomatiziranih poslovnih procesov je težko napovedati
- Obstaja šibka delitev dela znotraj izvajalske in/ali razvojne ekipe
- Sistemi vključeni v integracijsko vezje se razvijajo po lastnih načrtih
- Zaradi nedoslednosti podatkov lahko podjetje izgubi stranke ali denar
6. Zasnovo podatkovnega modela naj izvaja analitik le v povezavi z modeli ciljnega poslovnega procesa in procesa v IS. Če razvijalec načrtuje podatkovni model, se bo moral poglobiti v predmetno področje do te mere, da bo še posebej razumel razliko med vrednostmi atributov - nujen pogoj za izolacijo atomskih atributov. Tako prevzame nenavadne funkcije.
4 Problem za ilustracijo
Recimo, da imate v pristanišču majhno robotsko gostilno. Vaš tržni segment: mornarji in pirati, ki pridejo v pristanišče in potrebujejo oddih. Mornarjem prodajaš čaj s timijanom, piratom pa glavnike iz kosti in kosti za česanje brade. Za postrežbo v sami konobi skrbita robot hostesa in robot natakar. Zahvaljujoč visoki kakovosti in nizkim cenam ste pregnali konkurenco, tako da vsi, ki prihajajo z ladje, prihajajo v vašo gostilno, ki je edina v pristanišču.
Informacijski sistem gostilne sestavlja naslednja programska oprema:
- Sistem zgodnjega opozarjanja na stranko, ki prepozna njeno kategorijo na podlagi značilnih lastnosti
- Nadzorni sistem za robote hostese in robote barmane
- Sistem upravljanja skladišča in dostave do prodajnega mesta
- Sistem za upravljanje odnosov z dobavitelji (SURP)
Proces:
Sistem zgodnjega opozarjanja prepozna ljudi, ki zapuščajo ladjo. Če je oseba gladko obrita, jo identificira kot mornarja, če se najde oseba z brado, potem je prepoznana kot pirat.
Ko vstopi v taverno, gost sliši pozdrav robotske hostese v skladu z njegovo kategorijo, na primer: "Ho-ho-ho, dragi gusar, pojdi k mizi št ..."
Gost gre do navedene mize, kjer ima robot natakar že pripravljeno blago v skladu s kategorijo. Robot natakar skladiščnemu sistemu posreduje informacijo, da je treba naslednji obrok povečati, skladiščni IS na podlagi preostalih stanj v skladišču generira povpraševanje po nakupu v sistemu vodenja.
Medtem ko je sistem zgodnjega opozarjanja morda razvil vaš interni IT, je program za upravljanje paličnih robotov morda ustvaril zunanji izvajalec posebej za vaše podjetje. Sistemi za vodenje skladišč in odnosov z dobavitelji pa so prilagojene paketne rešitve s trga.
5. Primeri denormalizacije in njen vpliv na razvoj programske opreme
Pri snovanju poslovnega procesa so intervjuvani strokovnjaki soglasno trdili, da pirati po vsem svetu pijejo rum in si češejo brade s kostnimi glavniki, mornarji pa pijejo čaj s timijanom in so vedno čisto obriti.
Pojavi se imenik vrst strank z dvema vrednostma: 1 - pirati, 2 - mornarji, skupni za celoten informacijski krog podjetja.
Sistem obveščanja odjemalca takoj shrani rezultat obdelave slike kot identifikator (ID) prepoznanega odjemalca in njegov tip: mornar ali pirat.
ID prepoznanega predmeta
Kategorija stranke
100500
Gusar
100501
Gusar
100502
Mornar
Naj še enkrat opozorimo, da
1. Naši mornarji so pravzaprav obriti ljudje
2. Naši pirati so pravzaprav bradati ljudje
Katere težave je treba v tem primeru odpraviti, da naša struktura stremi k tretji normalni obliki:
- kršitev atomičnosti atributa – Kategorija odjemalca
- mešanje analiziranega dejstva in zaključka v eni tabeli
- fiksno funkcionalno razmerje med atributi različnih entitet.
V normalizirani obliki bi dobili dve tabeli:
- rezultat prepoznave v obliki nabora uveljavljenih lastnosti,
ID prepoznanega predmeta
Obrazne dlake
100500
Da
100501
Da
100502
Št
- rezultat določanja vrste odjemalca kot aplikacije logike, vgrajene v IS, za interpretacijo uveljavljenih značilnosti
ID prepoznanega predmeta
Identifikacijski ID
Kategorija stranke
100500
100001
Gusar
100501
100002
Gusar
100502
100003
Mornar
Kako lahko normalizirana organizacija shranjevanja podatkov olajša razvoj kompleksa IP? Recimo, da nenadoma dobite nove stranke. Naj bodo to japonski pirati, ki morda nimajo brade, a hodijo s papigo na rami, in pirati okoljevarstveniki, ki jih zlahka prepoznate po Gretinem modrem profilu na levem prsnem košu.
Okoljski pirati seveda ne morejo uporabljati kostnih glavnikov in zahtevajo analog iz reciklirane morske plastike.
Programske algoritme morate predelati v skladu z novimi vhodi. Če bi upoštevali pravila normalizacije, bi morali dopolniti samo vnose za nekatere procesne veje v nekaterih sistemih in ustvariti nove veje samo za tiste primere in v tistih IS, kjer so dlake na obrazu pomembne. Ker pa pravila niso bila upoštevana, boste morali analizirati celotno kodo, skozi celotno vezje, kjer se uporabljajo vrednosti imenika tipov strank in jasno ugotoviti, da mora algoritem v enem primeru upoštevati strokovno dejavnosti stranke in v drugih telesnih lastnostih.
V obliki, ki išče normalizirani bi dobili dve tabeli z operativnimi podatki in dva imenika:
- rezultat prepoznave v obliki nabora uveljavljenih lastnosti,
ID prepoznanega predmeta
Greta na levi prsi
Ptica na rami
Obrazne dlake
100510
1
1
1
100511
0
0
1
100512
1
0
- rezultat določanja tipa odjemalca (naj bo to pogled po meri, v katerem se prikazujejo opisi iz imenikov)
Ali zaznana denormalizacija pomeni, da sistemov ni mogoče spremeniti, da bi ustrezali novim pogojem? Seveda ne. Če si predstavljamo, da je vse informacijske sisteme ustvarila ena ekipa brez fluktuacije osebja, da je razvoj dobro dokumentiran in da se informacije znotraj ekipe prenašajo brez izgub, potem lahko zahtevane spremembe izvedemo z zanemarljivo malo truda. Če pa se vrnemo k prvotnim pogojem problema, bo izbrisanih 1,5 tipkovnice samo za tiskanje protokolov skupnih razprav in še 0,5 za obdelavo postopkov javnih naročil.
V zgornjem primeru so vse tri normalne oblike kršene, poskusimo jih kršiti ločeno.
Kršitev prve normalne oblike:
Recimo, da je blago dostavljeno v vaše skladišče iz dobaviteljevih skladišč s prevzemom z eno 1.5-tonsko gazelo, ki pripada vaši gostilni. Velikost vaših naročil je tako majhna glede na promet dobaviteljev, da so vedno dokončana ena na ena brez čakanja na proizvodnjo. Ali potrebujete ločene tabele s takšnim poslovnim procesom: vozila, tipi vozil, ali je treba pri naročilih odhodnim dobaviteljem ločiti plan in fakt?
Samo predstavljajte si, koliko "dodatnih" povezav bodo morali napisati vaši programerji, če boste za razvoj programa uporabili spodnji model.
Recimo, da smo se odločili, da je predlagana struktura po nepotrebnem zapletena; v našem primeru je ločevanje načrta in dejstva v zapisu naročila odvečna informacija, generirana specifikacija naročila pa se prepiše na podlagi rezultatov prevzema prispelega blaga, redkih napak. -razvrščanje in dovoz blaga neustrezne kakovosti se poravnava izven IS.
In potem nekega dne vidite, kako je vsa dvorana gostilne napolnjena z ogorčenimi in neurejenimi pirati. Kaj se je zgodilo?
Izkazalo se je, da se je z rastjo vašega podjetja povečala tudi vaša potrošnja. Nekoč je bila sprejeta odločitev vodstva, da v primeru preobremenitve gazele po volumnu in/ali teži, kar je bilo izjemno redko, dobavitelj prednostno naloži tovor v korist pijač.
Nedostavljeno blago je končalo v naslednjem naročilu in odšlo na nov let; prisotnost minimalnega stanja v skladišču v gostilni je omogočila, da ni bilo opaziti manjkajočih zabojev.
V pristanišču se je zaprl še zadnji konkurent in preluknjani primer preobremenitve gazele, ki ga je zaobšlo prioriteta na podlagi predpostavke zadostnosti minimalne bilance in periodične podobremenitve vozila, je postal običajna praksa. Ustvarjeni sistem bo idealno deloval v skladu z algoritmi, ki so vanj vgrajeni, in bo prikrajšan za kakršno koli možnost sledenja sistematičnemu neizpolnjevanju načrtovanih naročil. Le okrnjen ugled in nezadovoljne stranke bodo lahko odkrile težavo.
Pozoren bralec je morda opazil, da naročena količina v specifikaciji naročila (T_ORDER_SPEC) v razdelku 2 in razdelku 5 lahko ali pa tudi ne izpolnjuje zahteve prve normalne oblike. Vse je odvisno od tega, ali lahko glede na izbrani asortiman blaga v isto področje spadajo bistveno različne merske enote.
Kršitev druge normalne oblike:
Ko vaše potrebe rastejo, kupite še nekaj vozil različnih velikosti. V zgornjem kontekstu se je izdelava imenika vozil štela za odveč, posledično vsi algoritmi za obdelavo podatkov, ki služijo potrebam dostave in skladišča, dojemajo gibanje tovora od dobavitelja do skladišča kot let izključno 1,5-tonskega vozila. gazela. Torej ob nakupu novih vozil še vedno ustvarite imenik vozil, vendar boste morali pri njegovem dokončanju analizirati vso kodo, ki se sklicuje na gibanje tovora, da bi ugotovili, ali so na vsakem konkretnem mestu reference implicirane na značilnosti vozila, s katerim se je posel začel.
Kršitev tretje normalne oblike:
Na neki točki začnete ustvarjati program zvestobe, pojavi se zapis stalne stranke. Zakaj bi na primer porabili čas za ustvarjanje materialnih pogledov, ki hranijo agregirane podatke o prodaji posameznemu naročniku za uporabo pri poročanju in prenosu v analitične sisteme, če pa se na začetku programa zvestobe vse, kar zanima kupca, da v evidenco naročnika. ? In res, na prvi pogled ni smisla. Toda vsakič, ko vaše podjetje poveže, na primer, nove prodajne kanale, bi moral biti med vašimi analitiki nekdo, ki se bo spomnil, da tak atribut združevanja obstaja.
Pri snovanju vsakega novega procesa, na primer pri prodaji na internetu, prodaji prek distributerjev, povezanih v skupni sistem zvestobe, mora nekdo upoštevati, da morajo vsi novi procesi zagotavljati celovitost podatkov na ravni kode. Za industrijsko bazo podatkov s tisoč tabelami se to zdi nemogoča naloga.
Izkušen razvijalec seveda ve, kako odpraviti vse zgoraj omenjene težave, vendar po mojem mnenju naloga izkušenega analitika ni, da jih razkrije.
Rad bi izrazil svojo hvaležnost vodilnemu razvijalcu Evgeniyu Yarukhinu za njegove dragocene povratne informacije med pripravo publikacije.
Literatura
Connolly Thomas, Begg Caroline. Baza podatkov. Oblikovanje, izvedba in podpora. Teorija in praksa
Vir: www.habr.com