Tere! Minu nimi on Andrei Semenov, olen Sportmasteri vanemanalüütik. Selles postituses tahan tõstatada ERP süsteemi andmebaaside denormaliseerimise teema. Vaatame üldisi tingimusi, aga ka konkreetset näidet – oletame, et see oleks imeline piraatide ja meremeeste monopolikõrts. Milles tuleb piraate ja meremehi erinevalt serveerida, sest nende tublide härrasmeeste ilu- ja tarbimismustrid on oluliselt erinevad.
Kuidas kõiki õnnelikuks teha? Kuidas vältida hulluks minemist sellise süsteemi kavandamisel ja hooldamisel? Mida teha, kui kõrtsi ei hakka tulema mitte ainult tavalised piraadid ja meremehed?
Kõik on lõike all. Aga lähme järjekorras.
1. Piirangud ja eeldused
Kõik eelnev kehtib ainult relatsiooniandmebaaside kohta. Arvesse ei võeta denormaliseerimise tagajärgi muutmise, kustutamise ja sisestamise anomaaliate näol, mis on hästi kaetud, sealhulgas Internetis. Väljaspool selle väljaande ulatust on juhtumeid, kus denormaliseerimine on tavaline koht, koos klassikaliste näidetega: passi seeria ja number, kuupäev ja kellaaeg jne.
Postituses on kasutatud intuitiivseid ja praktiliselt rakendatavaid normaalvormide määratlusi, viitamata matemaatikaterminitele. Sellisel kujul, nagu neid saab rakendada reaalsete äriprotsesside (BP) uurimisel ja tööstustarkvara projekteerimisel.
Väidetakse, et andmeladude, aruandlustööriistade ja integratsioonilepingute kujundus (mis kasutavad teabe tabelikujulisi esitusi) erineb ERP-süsteemi andmebaaside ülesehitusest selle poolest, et tarbimise lihtsus ja teadliku denormaliseerimise kasutamine selle saavutamiseks võib olla ülimuslik terviklikkusest. kaitse andmed. Jagan seda arvamust ja allpool kirjeldatu kehtib ainult ERP-süsteemide põhiandmete ja tehinguandmete mudelite kohta.
Tavavormide seletus on toodud enamiku lugejate jaoks igapäevasel tasandil arusaadava näite abil. Kuid visuaalse illustratsioonina kasutati lõigetes 4–5 teadlikult „väljamõeldud” ülesannet. Kui te seda ei tee ja võtate mõne õpiku näite, näiteks sama tellimuse säilitamise mudeli punktist 2, võite leida end olukorrast, kus lugeja fookus nihkub protsessi pakutud dekomponeerimiselt mudeliks, isiklikule kogemusele ja arusaamale, kuidas tuleb üles ehitada IS-i andmete salvestamise protsesse ja mudeleid. Ehk siis võtta kaks kvalifitseeritud IT-analüütikut, üks osutagu reisijaid vedavaid logistikuid, teine mikrokiipide tootmise masinaid transportivaid logistikuid. Paluge neil luua andmemudel raudteereisi teabe salvestamiseks, ilma automaatsete BP-de üle eelnevalt arutlemata.
On nullist erinev tõenäosus, et pakutud mudelites ei leia mitte ainult märgatavalt erinevat atribuutide komplekti, vaid ka lahknevaid olemikomplekte, sest iga analüütik tugineb talle tuttavatele protsessidele ja ülesannetele. Ja sellises olukorras on võimatu öelda, milline mudel on “õige”, sest puudub hindamiskriteerium.
2. Normaalvormid
Andmebaasi esimene tavavorm nõuab kõigi atribuutide atomaalsust.
Täpsemalt, kui objektil A on mittevõtmeatribuudid a ja b, nii et c=f(a,b) ja objekti A kirjeldavasse tabelisse salvestate atribuudi c väärtuse, siis rikutakse andmebaasis esimest normaalvormi. . Näiteks kui tellimuse spetsifikatsioonis on märgitud kogus, mille mõõtühikud sõltuvad toote tüübist: ühel juhul võib see olla tükid, teisel liitrid, kolmandal tükkidest koosnevad pakendid (mudel ülal Good_count_WR) , siis rikutakse atribuutide atomaalsust andmebaasis. Sel juhul on selleks, et öelda, milline peaks olema tellimuse spetsifikatsiooni tabeliklaster, tööprotsessi sihipärane kirjeldus IS-is ja kuna protsessid võivad olla erinevad, siis võib olla palju “õigeid” versioone.
Andmebaasi teine tavavorm nõuab IS-is iga tööprotsessiga seotud olemi puhul esimese vormi ja oma tabeli järgimist. Kui ühes tabelis on sõltuvused c=f1(a) ja d=f2(b) ning puudub sõltuvus c=f3(b), siis on tabelis rikutud teine normaalvorm. Ülaltoodud näites ei ole tellimuse ja tabelis Tellimuse aadressi vahel sõltuvust. Muutke tänava või linna nime ja te ei mõjuta tellimuse olulisi atribuute.
Kolmas normaalvormi andmebaas nõuab teise normaalvormi järgimist ja funktsionaalsete sõltuvuste puudumist erinevate olemite atribuutide vahel. Selle reegli võib sõnastada järgmiselt: "kõik, mida saab arvutada, tuleb arvutada." Teisisõnu, kui on kaks objekti A ja B. Objekti A atribuute salvestavas tabelis avaldub atribuut C ja objektil B on atribuut b, nii et c=f4(b) on olemas, siis kolmas normaalvorm on rikutud. Allolevas näites väidab tellimuse kirje atribuut tükkide kogus (Total_count_WR) selgelt kolmandat tavavormi rikkumist
3. Minu lähenemine normaliseerimise rakendamisele
1. Ainult sihtmärgiks olev automatiseeritud äriprotsess suudab andmesalvestusmudeli loomisel anda analüütikule kriteeriumid olemite ja atribuutide tuvastamiseks. Tavalise andmemudeli loomise eelduseks on protsessimudeli loomine.
2. Kolmanda normaalvormi saavutamine ranges mõttes ei pruugi olla otstarbekas ERP-süsteemide loomise tegelikus praktikas, kui on täidetud mõned või kõik järgmistest tingimustest:
- automatiseeritud protsessid muutuvad harva,
- teadus- ja arendustegevuse tähtajad on kitsad,
- nõuded andmete terviklikkusele on suhteliselt madalad (võimalikud vead tööstustarkvaras ei too kaasa raha või klientide kaotust tarkvara kliendi poolt)
- jne
Kirjeldatud tingimustel ei pruugi mõnede objektide ja nende atribuutide elutsükli tuvastamise ja kirjeldamise kulud olla majandusliku efektiivsuse seisukohalt õigustatud.
3. Andmemudeli denormaliseerimise tagajärgi juba loodud IS-is saab leevendada koodi põhjaliku eeluuringu ja testimisega.
4. Denormaliseerimine on viis tööjõukulude ülekandmiseks andmeallikate uurimise ja äriprotsessi kavandamise etapist arendusfaasi, juurutamise perioodist süsteemi arendamise perioodi.
5. Andmebaasi kolmanda normaalvormi poole püüdlemine on soovitatav, kui:
- Automatiseeritud äriprotsesside muutumise suunda on raske ennustada
- Rakendus- ja/või arendusmeeskonna sees on nõrk tööjaotus
- Integratsiooniahelasse kuuluvad süsteemid arenevad vastavalt oma plaanidele
- Andmete ebaühtluse tõttu võib ettevõte kaotada kliente või raha
6. Andmemudeli kavandamist peaks läbi viima analüütik ainult seoses sihtäriprotsessi ja IS-is oleva protsessi mudelitega. Kui arendaja kavandab andmemudelit, peab ta teemavaldkonda niivõrd süvenema, et ta mõistaks eelkõige atribuutide väärtuste erinevust - see on vajalik tingimus aatomiatribuutide eraldamiseks. Seega omandades ebatavalisi funktsioone.
4 Ülesanne illustreerimiseks
Oletame, et teil on sadamas väike robotkõrts. Teie turusegment: meremehed ja piraadid, kes tulevad sadamasse ja vajavad puhkust. Meremeestele müüte teed tüümianiga ning piraatidele habeme kammimiseks mõeldud rummi- ja luukammi. Kõrtsis endas osutavad teenust robotperenaine ja robotbaarmen. Tänu oma kõrgele kvaliteedile ja madalatele hindadele olete kõik konkurentsist välja tõrjunud, nii et kõik laevalt tulijad tulevad teie kõrtsi, mis on sadamas ainuke.
Kõrtsi infosüsteemide kompleks koosneb järgmisest tarkvarast:
- Varajane hoiatussüsteem kliendi kohta, mis tuvastab oma kategooria iseloomulike tunnuste põhjal
- Juhtimissüsteem robotperemeestele ja robotbaarmenidele
- Lao- ja tarnehaldussüsteem müügikohta
- Tarnijasuhete haldussüsteem (SURP)
Protsess:
Varajane hoiatussüsteem tunneb ära laevalt lahkuvad inimesed. Kui inimene on puhtalt raseeritud, identifitseerib ta teda meremehena; kui inimesel avastatakse habe, siis piraadina.
Kõrtsi sisenedes kuuleb külaline robotperenaise tervitust vastavalt tema kategooriale, näiteks: “Ho-ho-ho, kallis piraat, mine lauda nr...”
Külaline läheb määratud lauda, kus robotbaarmen on talle juba vastavalt kategooriale kaubad valmistanud. Robotbaarmen edastab laosüsteemi info, et järgmist tarneportsjonit tuleks suurendada, ladu IS genereerib laos olevate jääkide põhjal ostusoovi haldussüsteemis.
Kuigi varajase hoiatamise süsteemi võis välja töötada teie sisemine IT, võis baariroboti haldusprogrammi luua väline töövõtja spetsiaalselt teie ettevõtte jaoks. Ladude ja tarnijatega suhete haldamise süsteemid on turult pärit kohandatud pakitud lahendused.
5. Näiteid denormaliseerimisest ja selle mõjust tarkvaraarendusele
Intervjueeritud aineeksperdid väitsid äriprotsessi kavandades üksmeelselt, et kõikjal maailmas joovad piraadid rummi ja kammivad habet luukammidega ning meremehed joovad teed tüümianiga ja on alati puhtalt habetunud.
Ilmub klienditüüpide kataloog kahe väärtusega: 1 - piraadid, 2 - meremehed, mis on levinud kogu ettevõtte teabeahela jaoks.
Kliendi teavitamise süsteem salvestab pilditöötluse tulemuse koheselt tuvastatud kliendi identifikaatoriks (ID) ja selle tüübiks: meremees või piraat.
Tuvastatud objekti ID
Kliendi kategooria
100500
Piraat
100501
Piraat
100502
Meremees
Märgime veel kord seda
1. Meie meremehed on tegelikult raseeritud inimesed
2. Meie piraadid on tegelikult habemega inimesed
Millised probleemid tuleb sel juhul kõrvaldada, et meie struktuur püüdleks kolmanda normaalvormi poole:
- atribuudi atomaarsuse rikkumine – kliendi kategooria
- analüüsitud fakti ja järelduse segamine ühte tabelisse
- fikseeritud funktsionaalne seos erinevate olemite atribuutide vahel.
Normaliseeritud kujul saame kaks tabelit:
- äratundmise tulemus väljakujunenud tunnuste kogumi kujul,
Tuvastatud objekti ID
Näokarvad
100500
Jah
100501
Jah
100502
ei
- kliendi tüübi määramise tulemus kui IS-i manustatud loogika rakendus kindlaksmääratud omaduste tõlgendamiseks
Tuvastatud objekti ID
Identifitseerimistunnus
Kliendi kategooria
100500
100001
Piraat
100501
100002
Piraat
100502
100003
Meremees
Kuidas saab normaliseeritud andmesalvestusorganisatsioon hõlbustada IP-kompleksi arendamist? Oletame, et saate ootamatult uusi kliente. Olgu need Jaapani piraadid, kellel ei pruugi olla habet, aga nad kõnnivad, papagoi õlal, ja keskkonnakaitsjad piraadid, kelle tunnete kergesti ära Greta sinise profiili järgi vasakul rinnal.
Keskkonnapiraadid ei saa loomulikult kasutada luukammi ja nõuavad ringlussevõetud mereplastist valmistatud analoogi.
Peate programmi algoritmid ümber töötama vastavalt uutele sisenditele. Kui järgitaks normaliseerimisreegleid, siis tuleks mõnes süsteemis täiendada ainult mõne protsessiharu sisendeid ja luua uued harud ainult nendel juhtudel ja nendes IS-des, kus näokarvad on olulised. Kuid kuna reegleid ei järgitud, peate analüüsima kogu koodi kogu ahela ulatuses, kus kasutatakse kliendi tüüpi kataloogi väärtusi, ja selgelt kindlaks tegema, et ühel juhul peaks algoritm võtma arvesse professionaali. kliendi aktiivsus ja muud füüsilised omadused.
Sellisel kujul, mis otsib normaliseerimiseks saame kaks tabelit tööandmetega ja kaks kataloogi:
- äratundmise tulemus väljakujunenud tunnuste kogumi kujul,
Tuvastatud objekti ID
Greta vasakul rinnal
Lind õlal
Näokarvad
100510
1
1
1
100511
0
0
1
100512
1
0
- kliendi tüübi määramise tulemus (olgu see kohandatud vaade, milles kuvatakse kataloogide kirjeldused)
Kas tuvastatud denormaliseerimine tähendab, et süsteeme ei saa uutele tingimustele vastavaks muuta? Muidugi mitte. Kui kujutada ette, et kõik infosüsteemid on loonud üks null kaadri voolavusega meeskond, arendused on hästi dokumenteeritud ja info liigub meeskonnasiseselt kadudeta, siis saab vajalikud muudatused tehtud tühise vaevaga. Kui aga naasta probleemi algtingimuste juurde, kustutatakse 1,5 klaviatuuri ainult ühiste arutelude protokollide printimiseks ja veel 0,5 hankemenetluste töötlemiseks.
Ülaltoodud näites on kõik kolm normaalvormi rikutud, proovime neid rikkuda eraldi.
Esimese normaalvormi rikkumine:
Oletame, et kaubad toimetatakse teie lattu tarnijate ladudest ühe teie kõrtsile kuuluva 1.5-tonnise gaselliga. Teie tellimuste suurus on tarnijate käibega võrreldes nii väike, et need täidetakse alati üks-ühele, ilma tootmist ootamata. Kas vajate sellise äriprotsessiga eraldi tabeleid: sõidukid, sõidukitüübid, kas lahkuvate tarnijate tellimustes on vaja eraldada plaan ja fakt?
Kujutage vaid ette, mitu "lisa" ühendust peavad teie programmeerijad kirjutama, kui kasutate programmi arendamiseks allolevat mudelit.
Oletame, et otsustasime, et pakutud struktuur on tarbetult keeruline, meie puhul on plaani ja fakti eraldamine tellimuse kirjes üleliigne teave ning genereeritud tellimuse spetsifikatsioon kirjutatakse ümber saabunud kauba vastuvõtmise tulemuste põhjal, harv viga - ebapiisava kvaliteediga kauba liigitamine ja saabumine arveldatakse väljaspool IS-i.
Ja siis ühel päeval näed, kuidas terve kõrtsisaal on täis nördinud ja kasimatud piraate. Mis juhtus?
Selgub, et äri kasvades kasvas ka tarbimine. Kunagi tehti juhtkonna otsus, et kui gasell on mahult ja/või kaalult ülekoormatud, mis oli üliharva, eelistab tarnija koormat jookide kasuks.
Tarnimata kaubad sattusid järgmisse tellimusse ja läksid uuele lennule, minimaalse saldo olemasolu kõrtsi laos võimaldas puuduvaid juhtumeid mitte märgata.
Viimane võistleja sulges sadamas ja torgatud gasellide ülekoormuse juhtum, millest möödus prioritiseerimisega, mis põhines eeldusel, et piisav on minimaalse tasakaalu ja perioodilise sõiduki alakoormamine, muutus tavapäraseks. Loodud süsteem töötab ideaalis vastavalt sellesse sisseehitatud algoritmidele ja jääb ilma igasugusest võimalusest jälgida plaanitud tellimuste süstemaatilise täitmatajätmist. Ainult kahjustatud maine ja rahulolematud kliendid suudavad probleemi tuvastada.
Tähelepanelik lugeja võis märgata, et tellitud kogus tellimuse spetsifikatsioonis (T_ORDER_SPEC) jaotises 2 ja jaotises 5 võib vastata või mitte vastata esimese tavavormi nõudele. Kõik oleneb sellest, kas valitud kaubasortimenti arvestades võivad samasse valdkonda sattuda sisuliselt erinevad mõõtühikud.
Teise normaalvormi rikkumine:
Teie vajaduste kasvades ostate veel paar erineva suurusega sõidukit. Eeltoodud kontekstis peeti üleliigseks sõidukikataloogi loomist, mistõttu tajuvad kõik tarne- ja laovajadusi teenindavad andmetöötlusalgoritmid veose liikumist tarnijalt lattu kui eranditult 1,5-tonnise lendu. gasell. Seega koos uute sõidukite ostmisega loote ikkagi sõidukite kataloogi, kuid selle vormistamisel peate analüüsima kogu lasti liikumisele viitavat koodi, et teada saada, kas igas konkreetses kohas on viited omadustele. sellest sõidukist, millest äri sai alguse.
Kolmanda normaalvormi rikkumine:
Ühel hetkel hakkad lojaalsusprogrammi looma, ilmub püsikliendi kirje. Miks kulutada aega näiteks materjalide vaadete loomisele, mis salvestavad koondandmed üksikkliendile müükide kohta aruandluses kasutamiseks ja analüütilistesse süsteemidesse ülekandmiseks, kui lojaalsusprogrammi käivitamisel saab kliendi registrisse kanda kõik, mis klienti huvitab. ? Ja tõepoolest, esmapilgul pole mõtet. Kuid iga kord, kui teie ettevõte ühendab näiteks uusi müügikanaleid, peaks teie analüütikute seas olema keegi, kes mäletab, et selline koondamisatribuut on olemas.
Iga uue protsessi kavandamisel, näiteks müük Internetis, müük ühise lojaalsussüsteemiga ühendatud edasimüüjate kaudu, peab keegi meeles pidama, et kõik uued protsessid peavad tagama andmete terviklikkuse koodi tasemel. Tuhande tabeliga tööstusliku andmebaasi jaoks tundub see võimatu ülesanne.
Kogenud arendaja muidugi teab, kuidas kõik ülalmainitud probleemid peatada, kuid minu arvates pole kogenud analüütiku ülesanne neid päevavalgele tuua.
Tahaksin avaldada tänu juhtivale arendajale Jevgeni Jaruhhinile väärtusliku tagasiside eest väljaande ettevalmistamisel.
Kirjandus
Connolly Thomas, Begg Caroline. Andmebaas. Disain, teostus ja tugi. Teooria ja praktika
Allikas: www.habr.com