Tere! Minu nimi on Andrei Semjonov, olen Sportmasteris vanemanalüütik. Selles postituses soovin tõstatada ERP-süsteemide andmebaaside denormeerimise küsimuse. Vaatame üldisi tingimusi ja toome välja konkreetse näite — oletame, et see on suurepärane monopolistlik tavern piraatidele ja meremeestele. Seal tuleb piraate ja meremehi teenindada erinevalt, kuna nende arusaamad ilust ja tarbimismustrid on oluliselt erinevad.
Kuidas teha nii, et kõik oleksid rahul? Kuidas mitte hulluks minna, projekteerides ja toetades sellist süsteemi? Mida teha, kui tavernisse hakkavad tulema mitte ainult harjunud piraadid ja meremehed?
Kõik on allpool. Kuid alustame järjekorras.
1. Piirangud ja eeldused
Kõik esitatud on seotud ainult relaatsioonsete andmebaasidega. Hästi välja toodud, sealhulgas internetis, denormeerimise tagajärgi muutmise, kustutamise ja lisamise anomaaliate näol ei käsitleta. Välja jäävad juhtumid, kui denormeerimine on tavaline, klassikaliste näidete abil: passi seeria ja number, kuupäev ja kellaaeg jne.
Postituses kasutatakse intuitiivseid ja praktiliselt rakendatavaid määratlusi normaalses vormis, ilma matemaatiliste terminite viidete kasutamiseta. Sellisel kujul, nagu neid saab rakendada reaalsete äri protsesside (AP) ülevaatamisel ja tööstusliku tarkvara projekteerimisel.
On arvamus, et andmehoidlate, aruandluse loomise tööriistade ja integreerimislepingute projekteerimine (milles kasutatakse tabelilist teabeesitust) erineb ERP-süsteemide andmebaaside projekteerimisest sellega, et tarbimise mugavus ja selle saavutamiseks teadlik denormeerimine võivad olla prioriteediks andmete terviklikkuse kaitse üle. Jagasin seda arvamust ja allpool kirjeldatud puudutab ainult meistridataanud ja tehingute andmeid ERP-süsteemide raames.
Normaalvormide selgitus on esitatud näite kaudu, mis on enamikule lugejatest arusaadav igapäevaelus. Kuid selge illustreerimise jaoks on punktides 4-5 teadlikult kasutatud silmapaistvalt 'väljamõeldud' ülesannet. Kui seda ei tehta ja võetakse mingisugune klassikaline näide, näiteks sama tellimuse säilitamise mudel punktis 2, võite sattuda olukorda, kus lugeja tähelepanu fookus nihkub pakutud protsessi mudelilt isiklikule kogemusele ja arusaamale, kuidas peaksid andmete säilitamise protsessid ja mudelid infotehnoloogias olema üles ehitatud. Teisisõnu, võtke kaks kvalifitseeritud IT-analüütikut, laske ühel teenindada reisijate transportimise logistikut, teisel aga masinaid mikrokiipide valmistamiseks transportivate logistikutega. Paluge neil, ilma eelnevalt automaatiseeritavaid äri-protsesse arutamata, koostada andmemudel, et säilitada teavet raudtee reiside kohta.
On olemas mitte-null tõenäosus, et pakutud mudelites leiate mitte ainult märgatavalt erineva atribuute komplekti, vaid ka mittesobivaid üksuste komplekte, sest iga analüütik tugineb talle tuttavatele protsessidele ja ülesannetele. Ja sellises olukorras on võimatu öelda, milline mudel on 'õige', kuna puudub hindamise kriteerium.
2. Normaalvormid
Esimene normaalvorm andmebaasis nõuab kõigi atribuutide aatomilisust.
Eelkõige, kui objekt A-l on mittevõtme atribuudid a ja b, nii et c = f(a,b) ja te tabelis, mis kirjeldab objekti A, salvestate atribuudiväärtuse c, siis andmebaasis on esimene normaalvorm rikutud. Näiteks, kui tellimuse spetsifikatsioonis on näidatud kogus, mille mõõtühikud sõltuvad kauba tüübist: ühes olukorras võivad need olla tükid, teises liitrid, kolmandas tükist koosnevad pakendid (ülemises mudelis Good_count_WR), siis andmebaasis on atribuutide aatomilisus rikutud. Sellisel juhul, et öelda, milline peaks olema tellimuse spetsifikatsiooni tabelite rühm, on vaja sihtprotsessi kirjeldust infotehnoloogias, ja kuna protsessid võivad olla erinevad, võib olla ka palju 'õigeid' versioone.
Teine normaalvorm andmebaasis eeldab esimesse vormi ja iga protsessiga seotud entiteedi jaoks oma tabeli järgimist. Kui ühes tabelis on sõltuvused c=f1(a) ja d=f2(b), kuid puudub sõltuvus c=f3(b), siis on tabelis rikutud teist normaalvormi. Ü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 olulisemaid atribuute.
Andmebaasi kolmas normaalvorm eeldab teise normaalvormi järgimist ning funktsionaalsete sõltuvuste puudumist erinevate entiteetide atribuutide vahel. Seda reeglit saab formuleerida järgmiselt: "kõik, mis saab olla arvutatud, peaks olema arvutatud". Teisisõnu, kui on olemas kaks objekti A ja B. A atribuutide tabelis on nähtav atribuut C, ja B-l on atribuut b, nii et c=f4(b), siis on rikutud kolmandat normaalvormi. Allpooltoodud näites püüab atribuut "Kogus" (Total_count_WR) tellimuse salvestuses selgelt rikkuda kolmandat normaalvormi.
3. Minu lähenemine normaliseerimise rakendamisele
1. Ainult sihitud automatiseeritav äri protsess saab pakkuda analüütikule kriteeriume entiteetide ja atribuutide tuvastamiseks andmete salvestusmudeli loomisel. Protsessi mudeli loomine on andmemudeli normaalse mudeli loomise kohustuslik tingimus.
2. Kolmanda normaalvormi saavutamine rangemas mõttes ei pruugi olla mõistlik ERP-süsteemide loomise praktikas, kui täidetakse osa või kõik järgmistest tingimustest:
- automatiseeritavad protsessid on harva muutustega seotud,
- uurimise ja arenduse ajad on lühikesed,
- andmete terviklikkuse nõuded on tinglikult madalad (potentsiaalsed vead tööstustarkvaras ei too kaasa rahakaotust ega klientide kaotust tarkvara tellijale)
- jne.
Kirjeldatud tingimustes võivad kulud objektide ja nende atribuutide elutsükli identifitseerimiseks ja kirjeldamiseks osutuda majanduslikult mitteotstarbekaks.
3. Andmemudeli denormaliseerimise mis tahes tagajärjed juba loodud infosüsteemis saab pehmendada koodi põhjaliku eeluurimise ja testimisega.
4. Denormalisatsioon on meetod, millega tugevdada töömahtu andmeallikate uurimise ja äriprotsessi projekteerimise etappidelt arenduse etapile, üleminekul rakendamise perioodilt süsteemi arendamise perioodile.
5. Kolmanda normaalvormi poole püüdlemine on mõistlik, kui:
- Automatiseeritavate ärioprotsesside suundumus on keeruliselt prognoositav.
- Sissetuleva ja/või arendustegevuse meeskonnas on nõrk tööjõu jagunemine.
- Integraatsiooniringi süsteemid arenevad vastavalt oma plaanidele.
- Andmete kooskamatuse tõttu võib ettevõte kaotada kliente või raha.
6. Andmemudeli projekteerimist peaks läbi viima analüütik ainult sihitud äriprotsesside ja infosüsteemi protsesside seosest. Kui andmemudeli projekteerimisega tegeleb arendaja, peab ta sukelduma teema valdkonda piisavalt sügavale, et mõista näiteks atribuudi väärtuste erinevusi - see on vajalik eeldus aatomaarsete atribuutide eristamiseks. Seega võtab ta endale mitteomaseid funktsioone.
4 Ülesanne illustratsiooniks
Kujutage ette, et teil on väike robotiseeritud tavern sadamas. Teie turusegment: meremehed ja piraadid, kes tulevad sadamasse ja vajavad puhkust. Meremeestele müüte apteegitilli teed, piraatidele aga rummu ja luust kamme habeme harjamiseks. Teenindus ise taverna sees on robothostess ja robotbaarmen. Tänu väga kõrgele kvaliteedile ja madalatele hindadele olete kõrvaldama kõik konkurendid, nii et igaüks, kes laevast maha astub, tuleb teie taverna, mis on sadamas ainus.
Taverna infotehnoloogia kompleks koosneb järgmisest tarkvarast:
- Varajase klienditeavitussüsteem, mis tuvastab kliendi kategooria iseloomulike tunnuste järgi.
- Robotite hostesside ja baarmenide juhtimissüsteem.
- Laotegevuse ja müügikohta tarnimise juhtimissüsteem.
- Tarnijate suhtehalduse süsteem (SRH).
Protsess:
Varajane teavitussüsteem tuvastab laevast väljuvaid inimesi. Kui inimene on hoolikalt habetunud, määratletakse ta meremehena, kui inimesel on habe, tuvastatakse ta piraadina.
Taverna sisenedes kuuleb külaline robothostessilt oma kategooriale vastavat tervitust, näiteks: "Ho-ho-ho, lugupeetud piraat, palun astuge lauasaali nr...".
Külastaja läbib määratud laua, kus robot-barmani on juba ette valmistanud tooted vastavalt kategooriale. Robot-barman edastab laosüsteemile teabe, et järgmise tarneportsjoni suurust tuleb suurendada, ja laohalduse infotehnoloogia loob varude alusel ostutaotluse.
Oletame, et varajase hoiatamise süsteemi arendas teie sisemine IT, baarrobotite juhtimise programmi lõi välisekspert spetsiaalselt teie ettevõtte vajadustele. Samas on varude ja tarnijate juhtimissüsteemid kohandatud lahendused turult.
5. Denormeerimise näidised ja selle mõju tarkvaraarendusele
Äriprotsessi kavandamisel kinnitasid küsitletud valdkonna eksperdid ühemõtteliselt, et kogu maailmas joovad piraadid rummi ja kammivad oma habet luukammidega, samas kui meremehed joovad teed pune ja on alati siledalt habetunud.
Klienditüüpide kataloog väljub kahe väärtusega: 1- piraadid, 2 — meremehed, mis on ettevõtte kogu infovahetuse jaoks ühine.
Kliendi teavitussüsteem salvestab kohe pilditöötluse tulemuse nagu tuvastatud kliendi identifikaatori (ID) ja tema tüübi: meremees või piraat.
Tuvastatud objekti ID
Kliendi kategooria
100500
Piraat
100501
Piraat
100502
Meremees
Tuletame meelde, et
1. Meie meremehed on tegelikult habemeajatud inimesed
2. Meie piraadid on tegelikult habe-kandvad inimesed
Milliseid probleeme on antud juhul vaja lahendada, et meie struktuur suunaks kolmandasse normaalkujusse:
- atribuutide aatomituks muutmine - kliendi kategooria
- analüüsitava fakti ja järelduse segamine ühes tabelis
- fikseeritud funktsionaalne seos erinevate entiteetide atribuutide vahel.
Normalizeeritud kujul saaksime kaks tabelit:
- tuvastamise tulemus kehtestatud tunnuste kogumina,
Tuvastatud objekti ID
Näokarv
100500
Jah
100501
Jah
100502
Ei
- kliendi tüübi määramise tulemus, mis on rakendatud infotehnoloogia loogika raames kehtestatud tunnuste tõlgendamiseks
Tuvastatud objekti ID
Identifitseerimis-ID
Kliendi kategooria
100500
100001
Piraat
100501
100002
Piraat
100502
100003
Meremees
Kuidas saab andmete normaliseerimise organisatsioon hõlbustada infosüsteemide kompleksi arengut? Oletame, et teil tekivad ootamatult uued kliendid. Olgu need Jaapani piraadid, kellel võib puududa habe, kuid kes käivad papagoiga õlal, ja ökoloogilised piraadid, keda tunnete ära Grete sinise profiili järgi vasakul rinnal.
Ökoloogilised piraadid ei saa loomulikult kasutada luidest kammi ja nõuavad taaskasutatud mereplastikust analooge.
Teil on vaja ümber töötada programmide tööalgoritmid vastavalt uutele sisenditele. Kui normaliseerimise reeglid oleksid järgitud, siis oleksite pidanud vaid mõnes süsteemis täiendasid sisenemisi teatud protsesside harude jaoks ja looma uusi harusid ainult nendes olukordades ja nendes infosüsteemides, kus on oluline näo karvakasv. Kuid kuna reegleid ei järgitud, peate analüüsima kogu koodi, kogu ulatuses, kus kasutatakse kliendi tüübi välistatud väärtusi, ja kindlaks määrama, et ühes juhul peab algoritm arvestama kliendi ametialase tegevusega, teises füüsiliste omadustega.
Sellises vormis, püüab normaliseerituna, saaksime kaks tabelit operatiivandmete ja kaks registrit:
- tuvastamise tulemus kehtestatud tunnuste kogumina,
Tuvastatud objekti ID
Grete vasakul rinnal
Lind õlal
Näokarv
100510
1
1
1
100511
0
0
1
100512
1
0
- kliendi tüübi määramise tulemus (olgu see kasutajate esitus, kus on välja toodud kirjeldused registritest)
Kas avastatud denormaliseerimine tähendab, et süsteeme ei saa uute olude järgi täiendada? Muidugi mitte. Kui kujutada ette, et kõik infosüsteemid loodi ühe meeskonna poolt, kellel ei olnud tööjõu pöörlemist, on arendused hästi dokumenteeritud ja teave meeskonnas edastatakse kaotusteta, siis vajalikud muudatused võivad toimuda mõõtmatult väikeste pingutuste kuludega. Kuid kui me naaseme algsete ülesannete tingimuste juurde, siis ainult protokollide printimise eest kulub 1,5 klaviatuuri ja veel 0,5 ostuprotseduuride vormistamiseks.
Eespool toodud näites on rikutud kõiki kolme normaalvormi, proovime neid rikkuda eraldi.
Esimese normaalvormi rikkumine:
Kujutage ette, et teie varud toimetatakse teie laos tarnijate ladudest omal käel 1,5-tonnise kaubikuga, mis kuulub teie kõrtsile. Teie tellimuste suurus on tarnijate käibega võrreldes nii väike, et neid täidetakse alati täielikult ilma tootmise ooteajata. Kas sellise äri koostöös on vajalikud eraldi tabelid: sõidukid, sõidukitüübid, kas on vajalik eristada plaani ja fakti teie tarnijatele saadetud tellimustes?
Kujutage ette, kui palju "ülemääraseid" sidemeid peavad teie programmeerijad looma, kui arendustegevuses kasutatakse allpool esitatud mudelit.
Kujutage ette, et oleme otsustanud, et soovitatud struktuur on liiga keeruline; meie puhul plaani ja fakti eraldamine tellimuse kirjes on liigset teavet, ja koostatud tellimuse spetsifikatsioon kirjutatakse üle saabunud kaupa vastavalt vastuvõtmisele, harvad erandid ja kehva kvaliteediga kauba vastuvõtmine lahendatakse väljaspool infosüsteemi.
Ja ühel päeval näete, et kogu kõrtsi saal on täis rahutuid ja hoolimatuid piraate. Mis on juhtunud?
Selgus, et koos teie äri kasvuga kasvas ka tarbimine. Kunagi tehti juhtimisotsus, et kui kaubik oli mahtude või kaaluga üle koormatud, mis juhtus äärmiselt harva, eelistas tarnija koormust joogitega.
Alustamata kaup sattus järgmisse tellimusse ja läks uue reisiga, laos õiguslikult nõutava jäägi olemasolu kõrtsi juures võimaldas mitte märgata vahejuhtumeid.
Sadamas sulges oma viimase konkurendi ja kaubiku ülekoormamine, mis jäi prioriseerimise tõttu kahe silma vahele, põhinedes arvamisel piisava nõutava jäägi ja perioodilise alakoormuse korral, sai tavapäraseks praktikaks. Loobitud süsteem toimib ideaalselt vastavalt sisestatud algoritmidele ja ei jäta mingit võimalust jälgida süsteemset plaanitud tellimuste täitmata jätmist. Ainult riknenud maine ja rahulolematud kliendid saavad probleemi avastada.
A careful reader has undoubtedly noticed that the ordered quantity in the order specification (T_ORDER_SPEC) in section 2 and in section 5 may or may not meet the requirements of the first normal form. It all depends on whether different measurement units can fall into the same field with the selected range of goods.
Violation of the second normal form:
As your needs grow, you acquire a couple of transport vehicles of different sizes. In the context described above, creating a vehicle directory was deemed redundant, so all data processing algorithms serving the needs of delivery and warehouse treat the movement of goods from the supplier to the warehouse as a flight of a 1.5-ton Gazelle. Therefore, along with the purchase of new vehicles, you still create a vehicle directory, but during rework, you'll have to analyze all the code that references the movement of goods to determine whether specific references to the characteristics of the very vehicle that started the business are implied in each instance.
Violation of the third normal form:
At some point, you start creating a loyalty program, and a record of a regular customer appears. Why, for example, waste time creating material representations that store aggregated data on sales for individual customers for reporting and transferring to analytical systems, if at the start of the loyalty program all that concerns the customer can be placed in the record of the customer themselves? And indeed, at first glance, there seems to be no point. But every time your business connects new sales channels, there should be someone among your analysts who remembers that there exists an aggregation attribute.
When designing each new process, say, online sales, sales through distributors connected to a common loyalty system, someone must keep in mind that all new processes should ensure data integrity at the code level. For an industrial database with thousands of tables, this seems like an unachievable task.
Kogen arendaja teab, kuidas lahendada kõik eespool nimetatud probleemid, kuid minu arvates on kogenud analüütiku ülesanne neid ära hoida.
Soovin tänada väärtusliku tagasiside eest, mis anti publikatsiooni ettevalmistamisel peaarendaja Jevgeni Jaruhinile.
Kirjandus
Connolly Tom, Begg Caroline. Andmebaasid. Projekteerimine, rakendamine ja hooldus. Teooria ja praktika
Allikas: habr.com
