Tere! Minu nimi on Andrei Semjonov, olen Sportmasteri vanemanalüütik. Selles postituses tahan ma tõstatada ERP-süsteemide andmebaaside denormaliseerimise küsimuse. Käsitleme üldisi tingimusi ning toome näiteks — ütleme, et see on suurepärane monopoolne kõrts, kus teenindatakse mereröövreid ja meremeestele. Nende arusaamad kaunist ja tarbimismustrid erinevad oluliselt.
Kuidas tagada, et kõik oleksid rahul? Kuidas mitte hulluks minna sellise süsteemi projekteerimisel ja hooldamisel? Mis siis, kui kõrtsi hakkavad tulema mitte ainult tuttavad mereröövlid ja meremehed?
Kõik on allpool. Kuid liigume järjestikku.
1. Piirangud ja eeldused
Kõik ülaltoodud kehtib ainult relatsiooniliste andmebaaside kohta. Hästi valgustatud, sealhulgas Internetis, on denormaliseerimise tagajärjed, nagu muudatuste, kustutamise ja sisestamise anomaaliad, arvesse võtmata. Avaldamise raames jäävad välja juhtumid, kus denormaliseerimine on tavaline, klassikaliste näidetega: passiseeria ja -number, kuupäev ja kellaaeg ning muud sarnased.
Postituses kasutatakse intuitiivseid ja praktiliselt rakendatavaid määratlusi normaalvormidest, ilma viidatud matemaatiliste terminoloogia kasutamiseta. Nõnda, nagu neid saab rakendada reaalse äritegevuse (BP) uurimisel ja tööstusliku tarkvara projekteerimisel.
On arvamus, et andmesalvestuslahenduste, aruandlustööriistade ja integratsioonilepingute (milles kasutatakse teavet tabelisarjana) projekteerimine erineb ERP-süsteemide andmebaaside projekteerimisest selles osas, et tarbimise mugavus ja selle saavutamiseks kasutatav teadlik denormaliseerimine võivad olla prioriteediks andmete terviklikkuse kaitse üle. Ma jagan seda arvamust ning allpool kirjeldatu kehtib ainult ERP-süsteemide meistrite andmete ja tehingute andmete mudelite kohta.
Normvormide selgitus on esitatud igapäevaelus mõistetaval näitel enamikule lugejatest. Siiski on punktides 4-5 teadlikult kasutatud väga 'väljamõeldud' ülesannet kui visuaalset illustreerimist. Vastasel juhul, kui võtta mingi klassikaline näide, näiteks sama tellimuse salvestamise mudel punktis 2, võib juhtuda, et lugeja tähelepanu fookus nihkub pakutud protsessi mudeli ja isikliku kogemuse ning arusaama peale selle kohta, kuidas andmete ja süsteemide salvestamise protsessid ja mudelid peaksid välja nägema. Teisisõnu, võtke kaks kvalifitseeritud IT-analüütikut, laske ühel osutada teenust logistikaekspertidele, kes transpordivad reisijaid, teisel aga logistikaekspertidele, kes transpordivad mikroskeemide tootmiseks vajalikke masinaid. Paluge neil, ilma eelnevalt arutamata automatiseeritavaid äri protsesse, koostada andmemudel teabe salvestamiseks raudtee reiside kohta.
On olemas märkimisväärne tõenäosus, et ettepanekud mudelid sisaldavad mitte ainult selgelt erinevaid atribuutide komplekte, vaid ka erinevaid entiteetide kogumeid, kuna iga analüütik tugineb tuttavatele protsessidele ja ülesannetele. Sellises olukorras on võimatu öelda, milline mudel on „õige“, kuna puudub hindamiskriteerium.
2. Normaalsed vormid
Esimene normaalsusvorm andmebaasis nõuab kõikide atribuutide aatomilisust.
Eelkõige, kui objekt A-l on mittevõtmeatribuutide a ja b, nii et c=f(a,b) ja objekti A kirjeldavas tabelis hoitakse atribuutide väärtust c, siis on andmebaasis esimese normaalsusvormi põhimõtte rikutud. Näiteks, kui tellimusspecifikatsioonis näidatakse kogust, mille mõõtühikud sõltuvad sissetoodud kauba tüübist: ühes juhul võivad need olla tükid, teises liitrid, kolmandas tükist koosnevates pakkides (ülemises mudelis Good_count_WR), siis on andmebaasis atribuutide aatomilisus rikutud. Antud juhul, et öelda, millisena peaks tellimuse specifikatsiooni tabeli kopse välja nägema, on vajalik protsessi sihtkirjeldus infotsüsteemis, ja kuna protsessid võivad olla erinevad, võivad olla ka palju "õigeid" versioone.
Teine normaalne andmebaasi vorm nõuab esimese vormi järgimist ja iseseisvat tabelit iga osakonna jaoks, mis on seotud infosüsteemi tööprotsessiga. Kui ühes tabelis on sõltuvused с=f1(a) ja d=f2(b) ning ei ole sõltuvust с=f3(b), siis on tabelis teine normaalne vorm rikku. Ülaltoodud näites ei ole tabelis 'Tellimus' sõltuvust tellimuse ja aadressi vahel. Muutke tänava või linna nime, ja see ei mõjuta tellimuse olulisi atribuute.
Kolmas normaalne andmebaasi vorm nõuab teise normaalse vormi järgimist ja funktsionaalsete sõltuvuste puudumist erinevate osakondade atribuutide vahel. Seda reeglit saab formuleerida nii: "kõik, mida saab arvutada, tuleb arvutada". Teisisõnu, kui on olemas kaks objekti A ja B. Tabelis, mis salvestab objekti A atribuute, esindatakse attribuuti C, siis objektil B on atribuut b, nii et on olemas c=f4(b), siis on rikku kolmas normaalne vorm. Allpool toodud näites pretendeerib atribuudi 'Tükihulk' (Total_count_WR) tellimuse kirjes selgelt kolmanda normaalse vormi rikkumisele.
3. Minu lähenemine normaliseerimise rakendamisele
1. Ainult sihitud automatiseeritav äri protsess suudab pakkuda analüütikale kriteeriume objektide ja atribuutide tuvastamiseks andmemudeli loomisel. Protsessi mudeli loomine on vajalik tingimus normaalse andmemudeli loomiseks.
2. Kolmanda normaalse vormi saavutamine rangelt võib osutuda praktikas ebapraktiliseks ERP-süsteemide loomisel, kui kehtivad osaliselt või täielikult järgmised tingimused:
- automatiseeritavad protsessid reeglina ei muutu,
- uurimis- ja arenduse tähtajad on lühikesed,
- andmete terviklikkuse nõuded on tingimuslikult madalad (potentsiaalsed vead tööstuslikus tarkvaras ei too kaasa raha või klientide kaotust tarkvaraarendaja jaoks)
- jne.
Kirjeldatud tingimuste korral võivad kulud teatud objektide ja nende atribuutide elu tsükli tuvastamiseks ja kirjeldamiseks olla majanduslikult põhjendamatud.
3. Andmemudeli denormaliseerimise tagajärjed juba loodud infosüsteemis võivad olla ohustatud põhjaliku koodi eelneva uurimise ja testimisega.
4. Denormaalimine on viis, kuidas edasilükata töökoormust andmeallikate uurimise ja äri protsessi projekteerimise etapilt arendusetapile, teisest rakendamisest süsteemi arendamise perioodi.
5. Kolmanda normaalvormi poole püüdlemine on põhjendatud, kui:
- Automatiseeritavate äri protsesside muutumise suundumus on keeruliselt prognoositav.
- Rakendamise ja/või arendamise meeskonnas on tugev perifeerne tööjaotus.
- Integreerimisringi kuuluvad süsteemid arenevad oma plaanide järgi.
- Andmete ebakõla võib kaasa tuua klientide või raha kaotuse ettevõttest.
6. Andmemudeli projekti peab analüütik koostama ainult sihitud äri protsessi ja süsteemi protsesside kontekstis. Kui andmemudeli projekteerimisega tegeleb arendaja, peab ta süvenema teema valdkonda nii palju, et mõista atribuutide väärtuste vahelisi erinevusi — vajalik tingimus atomaarsete atribuutide eristamiseks. Seega võtab ta endale omaseid funktsioone.
4 Ülesanne illustreerimiseks
Kujutage ette, et teil on väike automatiseeritud tavern sadamas. Teie sihtrühm on meremehed ja piraadid, kes tulevad sadamasse ja vajavad puhkust. Meremeestele müüte te tüümiani teed ning piraatidele rummu ja luust kammid habeme kohendamiseks. Teenindust osutab tavernis robot-kelner ja robot-baarmen. Tänu kõrgele kvaliteedile ja madalatele hindadele olete te kõik konkurendid välja tõrjunud, nii et iga laeva pealt maha astuv inimene suundub teie tavernisse, mis on sadama ainus.
Taverna infotehnoloogilise süsteemi kompleks koosneb järgmistest tarkvara osadest:
- Kliendi varajase teavitamise süsteem, mis tuvastab tema kategooria iseloomulikest tunnustest
- Robot-kelnerite ja robot-baarmeeste juhtimisse süsteem
- Laohaldus- ja müügipunkti tarne juhtimisse süsteem
- Tarnijate suhtlemise juhtimisse süsteem (TSJS)
Protsess:
Varajane teavitamise süsteem tuvastab laeva pealt väljuvad inimesed. Kui inimene on siledalt habetunud, määratletakse ta meremehena; kui inimesel on habeme, määratletakse ta piraadina.
Taverna sisenedes kuulab külaline robot-teenindaja tervitust vastavalt oma kategooriale, näiteks: „Ho-ho-ho, austatud piraat, tulge lauda nr…“
Külaline läbib määratud lauda, kus robot-baarmen on juba tema kategooriale vastavad kaubad ette valmistanud. Robot-baarmen edastab lao süsteemi teabe, et järgmine tarnimine peaks suurenema, lao infosüsteem, tuginedes säilitamise reservidele, koostab SOUP-is ostupakkumise.
Olgu varajase hoiatamise süsteem loodud teie sisemise IT poolt, baarrobotite haldusprogramm loodud välistöövõtja poolt spetsiaalselt teie äri jaoks. Laohaldus- ja tarnijasuhete süsteemid on kohandatud kastilahendused turult.
5. Denormaliseerimise näidised ja selle mõju tarkvaraarendusele
Äriprotsessi projekteerimisel on küsitletud valdkonna eksperdid üheselt väitnud, et kogu maailmas joovad piraadid rummi ja kammivad habemeid luust kammidega, samas kui meremehed joovad teed oreganoga ja on alati korralikult raseeritud.
Kliendi tüüpide juhend ilmub kahes väärtuses: 1 - piraadid, 2 - meremehed, mis on ühiselt kogu ettevõtte teabealal.
Kliendi teavitussüsteem salvestab kohe pilditöötluse tulemuse tuvastatud kliendi ID-na (ID) ja tema tüübi: meremees või piraat.
Tuvastatud objekti ID
Kliendi kategooria
100500
Piraat
100501
Piraat
100502
Meremees
Kordan veel kord, et
1. Meie meremehed on tegelikult raseeritud inimesed
2. Meie piraadid on tegelikult habemega inimesed
Milliseid probleeme tuleb sel juhul lahendada, et meie struktuur püüdleks kolmanda normaalkujundi poole:
- atribuutide aatomaaruse rikkumine - Kliendi kategooria
- analüüsitava fakti ja järelduse segamine ühes tabelis
- fikseeritud funktsionaalne sõltuvus erinevate entiteetide atribuutide vahel.
Normeeritud kujul oleks meil kaks tabelit:
- tuvastamise tulemus tuntud tunnuste kogumina,
Tuvastatud objekti ID
Näo karv
100500
Jah
100501
Jah
100502
Ei
- kliendi tüübi määramise tulemus, rakendades IS-s sisseehitatud loogikat määratud tunnuste tõlgendamiseks
Tuvastatud objekti ID
Tuvastamise ID
Kliendi kategooria
100500
100001
Piraat
100501
100002
Piraat
100502
100003
Meremees
Kuidas võivad andmete normaliseerimise organisatsioon aidata infotehnoloogia süsteemide arendamist? Kujutage ette, et teil tekivad äkitselt uued kliendid. Olgu need näiteks jaapani piraadid, kellel võib puududa habe, kuid kes liiguvad koos papagoiga õlal, ja keskkonnaalased piraadid, keda tunnete ära Greta sinise profiili järgi vasakus rinnas.
Keskkonnaalased piraadid ei saa loomulikult kasutada luust kamme ja nõuavad nende asemele ümbertöödeldud mereplastikust toodet.
Te peate kohandama programmide tööalgoritme vastavalt uutele sisenditele. Kui normaliseerimise reeglid oleksid täidetud, piisaks osade süsteemide puhul vaid mõnede protsesside harude sisendite täiendamisest ja uute harude loomisest vaid neis infotehnoloogia süsteemides, kus on oluline näo karvakasv. Kuid kuna reegleid ei ole järgitud, peate analüüsima kogu koodi, igas kontuuris, kus kasutatakse klienditüübi määratlemise väärtusi, ja selgelt määrama, et ühes olukorras peab algoritm arvesse võtma kliendi ametialast tegevust, samas kui teises tuleb arvestada füüsiliste omadustega.
Selles vormis püüdleb normaliseeritud, saaksime kaks tabelit operatiivandmetega ja kaks katalooge:
- tuvastamise tulemus tuntud tunnuste kogumina,
Tuvastatud objekti ID
Greta vasakul rinnal
Lind õlal
Näo karv
100510
1
1
1
100511
0
0
1
100512
1
0
- tulemused kliendi tüübi määramisel (võtame näiteks kasutajaliidese, kus väljastatakse kirjeldused kataloogidest)
Kas tuvastatud denormaliseerimine tähendab, et süsteemi ei saa uute tingimuste järgi kohandada? Muidugi mitte. Kui kujutada ette, et kõik infosüsteemid on loodud ühe meeskonna poolt nulli töötajatega, arendused on hästi dokumenteeritud ja teave tiimi sees väljastatakse kaotusteta, siis vajalikud muudatused võivad toimuda väheste jõupingutustega. Kuid kui me naaseme algsete probleemitingimuste juurde, siis ainult koosoleku protokollide väljastamise peale kulub 1,5 klaviatuuri ja veel 0,5 ostumenetluste vormistamisele.
Ülaltoodud näites on rikutud kõiki kolme normaalvormi, proovime neid rikkuda ükshaaval.
Esimese normaali rikkumine:
Kujutage ette, et teie lao tooted toimetatakse tarnijate ladudest iseteeninduse kaudu, kasutades 1,5-tonnist Gazelli, mis kuulub teie tavernale. Teie tellimuste suurus on tarnijate käivetega võrreldes nii väike, et need täidetakse alati täpselt ilma tootmise ootamiseta. Kas sellise äritegevuse jaoks on vajalikud eraldi tabelid: transport, transpordivahendid, kas peaksite tellimuste plaani ja tegelikkuse jagama?
Kujutage ette, kui palju „ülemääraseid“ ühendusi peavad teie programmeerijad kirjutama, kui programmi arendamiseks kasutada allolevat mudelit.
Kujutage ette, et oleme otsustanud, et pakutud struktuur on liiga keeruline; meie puhul tellimuse plaani ja tegelikkuse jagamine on liigsete andmete esitamine ning koostatud tellimuse spetsifikatsioon kirjutatakse ümber vastavalt saabunud kauba vastuvõtu tulemusele; harvad valeartiklid ja ebakvaliteetsed kaubasaated lahendatakse süsteemist väljaspool.
Ja ühel päeval näete, kuidas kogu taverni saal on täis rahutute ja hoolimatute mereröövlite. Mis siis juhtus?
Selgus, et koos teie äri kasvuga kasvas ka tarbimine. Kunagi tehti juhtimisotsus, et kui gaasiiseeruv tõstuk osutus koormusest ülekõrgeks ja/või kaalult, mis juhtus äärmiselt harva, prioriseeriti tarnija koormust jookide kasuks.
Puudulikud kaubad kanti järgmisse tellimusse ja läksid uue reisi käigus, samas kui tavernas oli püsiv varude saldo, lubades tähelepanuta jätta ebakorrapäraseid juhtumeid.
Sadamas suleti viimane konkurent ja ebakorrapärane juhtum gaasiiseeruva koormuse ülekohust, mis toodi prioriseerimise kaudu, mis põhines oletusel piisavusest püsiva varu osas ja perioodisest ebakõnormaalsusest transpordivahendi koormuses, sai tavapäraseks praktikaks. Loodud süsteem töötab ideaalselt vastavalt süsteemi sisestatud algoritmidele ja on vaba igasugusest võimalusest jälgida süsteemset kavandatud tellimuste mittetäitmist. Ainult rikutud reputatsioon ja rahulolematud kliendid suudavad probleemi avastada.
Hoolikas lugeja on tõenäoliselt märganud, et tellimuse spetsifikatsioonis (T_ORDER_SPEC) osades 2 ja 5 olev tellitud kogus võib osutuda esimese normaalkuju nõudmistele vastavaks või mitte. See sõltub sellest, kas valitud kaubavalikus võivad samasse väljasse sattuda erinevad mõõtühikud.
Teise normaalkuju rikku mine:
Teie vajaduste kasvades soetate veel paar erineva suurusega transpordivahendit. Ülaltoodud kontekstis on transpordivahendite register liigseks osutunud, mistõttu kõik andmete töötluse algoritmid, mis teenindavad ladustamis- ja kohaletoimetamistegevusi, käsitlevad laste toimetamist tarnijalt lattu kui ühe 1,5-tonnise kaubiku reisi. Seega, koos uute transpordivahendite ostmisega loote siiski transpordivahendite registri, kuid selle täiendamise käigus peate analüüsima kogu koodi, mis viitab kauba liikumisele, et välja selgitada, kas igas konkreetses kohas viidatakse just sellele autole, mille põhjal äri algas.
Kolmanda normaalvormi rikkumine:
Mingil hetkel hakkate looma lojaalsusprogrammi ja tekib regulaarse kliendi rekord. Miks raisata aega füüsiliste esinduste loomisele, mis hoiavad kokkuvõtlikke müügandmeid konkreetse kliendi kohta, et neid kasutada aruandluses ja edastada analüütilistesse süsteemidesse, kui lojaalsusprogrammi käivitamise etapis on kõik, mis kliendi jaoks oluline, võimalik paigutada kliendi enda rekordisse? Ja tõepoolest, esmapilgul ei tundu sellel mõtet olevat. Kuid iga kord, kui teie ettevõte ühendab näiteks uusi müügikanaleid, peaks teie analüütikute seas olema keegi, kes meenutab, et selline agregatsioon atribuudi olemasolu on oluline.
Iga uue protsessi kavandamisel, näiteks Internetis müük, müük kaudu jaotajaid, mis on seotud ühiselt lojaalsussüsteemiga, peab keegi meeles pidama, et kõik uued protsessid peavad koodi tasandil tagama andmete terviklikkuse. Tuhande tabeliga tööstusliku andmebaasi puhul tundub see peaaegu saavutatmatu ülesanne.
Kogenud arendaja teab muidugi, kuidas lahendada kõik eespool mainitud probleemid, kuid minu arvates on kogenud analüüsiülesanne neid vältida.
Soovin tänada väärtusliku tagasiside eest väljaande ettevalmistamise käigus juhtarendajat Jevgeni Jaruhinit.
Kirjandus
Connolly Thomas, Begg Caroline. Andmebaasid. Kavandamine, rakendamine ja hooldus. Teooria ja praktika.
Allikas: habr.com
