Sveiki! Mano vardas Andrejus Semenovas, esu „Sportmaster“ vyresnysis analitikas. Šiame įraše noriu iškelti ERP sistemos duomenų bazių denormalizavimo problemą. Pažiūrėsime į bendras sąlygas, taip pat pateiksime konkretų pavyzdį – tarkime, tai būtų nuostabi piratų ir jūreivių monopolija. Kuriuose piratai ir jūreiviai turi būti aptarnaujami skirtingai, nes šių gerų džentelmenų grožio idėjos ir vartojimo modeliai gerokai skiriasi.
Kaip padaryti visus laimingus? Kaip neišprotėti kuriant ir prižiūrint tokią sistemą? Ką daryti, jei į taverną pradeda ateiti ne tik įprasti piratai ir jūreiviai?
Viskas yra po pjūviu. Bet eikime eilės tvarka.
1. Apribojimai ir prielaidos
Visa tai, kas išdėstyta pirmiau, taikoma tik reliacinėms duomenų bazėms. Denormalizavimo pasekmės modifikavimo, ištrynimo ir įterpimo anomalijų, kurios yra gerai aprašytos, įskaitant internete, pavidalu, neatsižvelgiamos. Už šio leidinio ribų yra atvejų, kai denormalizacija yra įprasta vieta, pateikiami klasikiniai pavyzdžiai: paso serija ir numeris, data ir laikas ir kt.
Įraše naudojami intuityvūs ir praktiškai pritaikomi normaliųjų formų apibrėžimai, nenurodant matematinių terminų. Tokia forma, kuria jie gali būti taikomi realių verslo procesų (BP) tyrimui ir pramoninės programinės įrangos projektavimui.
Teigiama, kad duomenų saugyklų, ataskaitų teikimo įrankių ir integravimo sutarčių (kuriose naudojamos lentelės formos informacijos atvaizdavimas) dizainas skiriasi nuo ERP sistemos duomenų bazių dizaino tuo, kad naudojimo paprastumas ir sąmoningo denormalizavimo naudojimas tam pasiekti gali būti svarbesnis už vientisumą. apsaugos duomenis. Pritariu šiai nuomonei, ir tai, kas aprašyta toliau, taikoma tik ERP sistemų pagrindinių duomenų ir operacijų duomenų modeliams.
Įprastų formų paaiškinimas pateikiamas naudojant pavyzdį, kuris yra suprantamas daugumai skaitytojų. Tačiau, kaip vaizdinę iliustraciją, 4–5 dalyse buvo sąmoningai panaudota „išgalvota“ užduotis. Jei to nepadarysite ir paimsite kokį nors vadovėlį, pavyzdžiui, tą patį užsakymų saugojimo modelį iš 2 punkto, galite atsidurti situacijoje, kai skaitytojo dėmesys bus perkeltas nuo siūlomo proceso skaidymo į modelį, į asmeninę patirtį ir suvokimą, kaip turi būti kuriami procesai ir duomenų saugojimo IS modeliai. Kitaip tariant, paimkite du kvalifikuotus IT analitikus, tegul vienas teikia paslaugas logistikams, vežantiems keleivius, kitas – logistikams, vežantiems mašinas mikroschemų gamybai. Paprašykite jų, iš anksto neaptarę automatinių BP, sukurti duomenų modelį informacijos apie kelionę geležinkeliu saugojimui.
Yra ne nulinė tikimybė, kad siūlomuose modeliuose rasite ne tik pastebimai skirtingą atributų rinkinį, bet ir skirtingus esybių rinkinius, nes kiekvienas analitikas remsis jam pažįstamais procesais ir užduotimis. Ir tokioje situacijoje neįmanoma pasakyti, kuris modelis yra „teisingas“, nes nėra vertinimo kriterijaus.
2. Normalios formos
Pirmoji įprasta duomenų bazės forma reikalauja visų požymių atomiškumo.
Visų pirma, jei objektas A turi neraktinius atributus a ir b, tokius, kad c=f(a,b) ir objektą A aprašančioje lentelėje saugote atributo c reikšmę, tada duomenų bazėje pažeidžiama pirmoji normalioji forma. . Pavyzdžiui, jei užsakymo specifikacijoje nurodytas kiekis, kurio matavimo vienetai priklauso nuo prekės tipo: vienu atveju tai gali būti vienetai, kitu litrai, trečiu – pakuotės, susidedančios iš vienetų (modelyje aukščiau Good_count_WR) , tada duomenų bazėje pažeidžiamas atributų atomiškumas. Tokiu atveju, norint pasakyti, koks turi būti užsakymo specifikacijos lentelių klasteris, reikalingas tikslingas darbo proceso aprašymas IS, o kadangi procesai gali būti įvairūs, gali būti daug „teisingų“ versijų.
Antroji įprasta duomenų bazės forma reikalauja laikytis pirmosios formos ir savo lentelės kiekvienam subjektui, susijusiam su darbo procesu IS. Jeigu vienoje lentelėje yra priklausomybės c=f1(a) ir d=f2(b) ir nėra priklausomybės c=f3(b), tai lentelėje pažeidžiama antroji normalioji forma. Aukščiau pateiktame pavyzdyje užsakymo lentelėje nėra priklausomybės tarp užsakymo ir adreso. Pakeiskite gatvės ar miesto pavadinimą ir neturėsite įtakos esminiams užsakymo atributams.
Trečioji normalios formos duomenų bazė reikalauja atitikties antrajai normaliajai formai ir funkcinių priklausomybių tarp skirtingų subjektų atributų nebuvimo. Šią taisyklę galima suformuluoti taip: „viskas, ką galima apskaičiuoti, turi būti apskaičiuota“. Kitaip tariant, jei yra du objektai A ir B. Lentelėje, kurioje saugomi objekto A atributai, pasireiškia atributas C, o objektas B turi atributą b, kad egzistuoja c=f4(b), tada trečioji normalioji forma. yra pažeidžiamas. Toliau pateiktame pavyzdyje užsakymo įrašo atributas Vienetų kiekis (Total_count_WR) aiškiai teigia, kad pažeidžia trečią įprastą formą
3. Mano požiūris į normalizavimo taikymą
1. Tik tikslinis automatizuotas verslo procesas gali pateikti analitikui subjektų ir atributų identifikavimo kriterijus kuriant duomenų saugojimo modelį. Proceso modelio sukūrimas yra būtina sąlyga norint sukurti įprastą duomenų modelį.
2. Pasiekti trečiąją normaliąją formą griežtąja prasme gali būti nepraktiška realiai kuriant ERP sistemas, jei tenkinamos kelios arba visos toliau nurodytos sąlygos:
- automatizuoti procesai retai keičiasi,
- mokslinių tyrimų ir plėtros terminai yra griežti,
- duomenų vientisumo reikalavimai yra palyginti žemi (dėl galimų pramoninės programinės įrangos klaidų programinės įrangos klientas nepraranda pinigų ar klientų)
- ir tt
Esant aprašytoms sąlygoms, kai kurių objektų ir jų atributų gyvavimo ciklo nustatymo ir aprašymo išlaidos gali būti nepateisinamos ekonominio naudingumo požiūriu.
3. Bet kokias duomenų modelio denormalizavimo pasekmes jau sukurtoje IS galima sušvelninti atlikus išsamų išankstinį kodo tyrimą ir testavimą.
4. Denormalizacija – tai būdas perkelti darbo sąnaudas iš duomenų šaltinių tyrimo ir verslo proceso projektavimo etapo į kūrimo etapą, iš diegimo laikotarpio į sistemos kūrimo laikotarpį.
5. Patartina siekti trečios normalios duomenų bazės formos, jei:
- Automatizuotų verslo procesų pokyčių kryptį sunku numatyti
- Diegimo ir (arba) kūrimo komandoje yra silpnas darbo pasidalijimas
- Į integravimo grandinę įtrauktos sistemos vystosi pagal savo planus
- Dėl duomenų nesuderinamumo įmonė gali prarasti klientų ar pinigų
6. Duomenų modelio projektavimą turėtų atlikti analitikas tik kartu su tikslinio verslo proceso ir proceso modeliais IS. Jei kūrėjas kuria duomenų modelį, jis turės pasinerti į dalykinę sritį tiek, kad visų pirma suprastų skirtumą tarp atributų verčių – būtina sąlyga atskirti atominius atributus. Taigi, prisiima neįprastas funkcijas.
4 Iliustracijos uždavinys
Tarkime, uoste turite mažą robotizuotą taverną. Jūsų rinkos segmentas: jūreiviai ir piratai, kurie atvyksta į uostą ir kuriems reikia pertraukos. Jūreiviams parduodate arbatą su čiobreliais, o piratams – romo ir kaulų šukas barzdoms šukuoti. Pačioje tavernoje paslaugą teikia šeimininkė robotė ir barmenas robotas. Aukštos kokybės ir žemų kainų dėka išstūmėte konkurentus, todėl visi, išlipę iš laivo, ateina į jūsų smuklę, kuri yra vienintelė uoste.
Tavernos informacinių sistemų kompleksas susideda iš šios programinės įrangos:
- Ankstyvojo įspėjimo apie klientą sistema, kuri atpažįsta savo kategoriją pagal būdingus požymius
- Valdymo sistema robotų šeimininkėms ir robotų barmenams
- Sandėlio ir pristatymo į pardavimo vietą valdymo sistema
- Tiekėjų santykių valdymo sistema (SURP)
Procesas:
Ankstyvojo įspėjimo sistema atpažįsta žmones, paliekančius laivą. Jei žmogus yra švariai nusiskutęs, ji identifikuoja jį kaip jūreivį, o jei žmogus turi barzdą, jis identifikuojamas kaip piratas.
Įėjęs į smuklę, svečias išgirsta roboto šeimininkės sveikinimą pagal savo kategoriją, pavyzdžiui: „Ho-ho-ho, mielas piratas, eik prie stalo Nr...“
Svečias eina prie nurodyto staliuko, kur robotas barmenas jam jau paruošė prekes pagal kategoriją. Barmenas robotas perduoda informaciją į sandėlio sistemą, kad kitą pristatymo porciją reikia padidinti, sandėlio IS, remdamasi likusiais sandėlyje esančiais likučiais, valdymo sistemoje sugeneruoja pirkimo užklausą.
Nors ankstyvojo įspėjimo sistemą galėjo sukurti jūsų vidinė IT, baro roboto valdymo programą galėjo sukurti išorinis rangovas, skirtas būtent jūsų verslui. O sistemos, skirtos valdyti sandėlius ir santykius su tiekėjais, yra pritaikyti supakuoti sprendimai iš rinkos.
5. Denormalizavimo pavyzdžiai ir jo įtaka programinės įrangos kūrimui
Kurdami verslo procesą kalbinti dalyko ekspertai vienbalsiai teigė, kad visame pasaulyje piratai geria romą ir barzdas šukuoja kaulinėmis šukomis, o jūreiviai geria arbatą su čiobreliais ir visada yra švariai nusiskutę.
Atsiranda klientų tipų katalogas su dviem reikšmėmis: 1 - piratai, 2 - jūreiviai, bendras visai įmonės informacinei grandinei.
Klientų pranešimų sistema iš karto išsaugo vaizdo apdorojimo rezultatą kaip atpažinto kliento identifikatorių (ID) ir jo tipą: jūreivis ar piratas.
Atpažintas objekto ID
Kliento kategorija
100500
Piratas
100501
Piratas
100502
Jūreivis
Dar kartą atkreipkime dėmesį į tai
1. Mūsų jūreiviai iš tikrųjų yra skusti žmonės
2. Mūsų piratai iš tikrųjų yra barzdoti žmonės
Kokias problemas šiuo atveju reikia pašalinti, kad mūsų struktūra siektų trečios normalios formos:
- atributo atomiškumo pažeidimas – Kliento kategorija
- sumaišius analizuojamą faktą ir išvadą vienoje lentelėje
- fiksuotas funkcinis ryšys tarp skirtingų subjektų atributų.
Normalizuota forma gautume dvi lenteles:
- atpažinimo rezultatas nustatytų savybių rinkinio forma,
Atpažintas objekto ID
Veido plaukai
100500
Taip
100501
Taip
100502
Ne
- kliento tipo nustatymo rezultatas kaip IS įterptos logikos taikymas aiškinant nustatytas charakteristikas
Atpažintas objekto ID
Identifikavimo ID
Kliento kategorija
100500
100001
Piratas
100501
100002
Piratas
100502
100003
Jūreivis
Kaip normalizuota duomenų saugojimo organizacija gali palengvinti IP komplekso kūrimą? Tarkime, staiga sulaukiate naujų klientų. Tebūnie japonų piratai, kurie gal ir neturi barzdos, bet vaikšto su papūga ant peties, o aplinkosaugininkai piratai, juos nesunkiai atpažinsite iš mėlynos Gretos profilio kairėje krūtinėje.
Aplinkosaugos piratai, žinoma, negali naudoti kaulų šukų ir reikalauja analogo, pagaminto iš perdirbto jūros plastiko.
Turite perdaryti programos algoritmus pagal naujus įvestis. Jei būtų laikomasi normalizavimo taisyklių, kai kuriose sistemose tektų tik papildyti kai kurių proceso šakų įvestis ir sukurti naujas šakas tik tais atvejais ir tose IS, kur veido plaukai yra svarbūs. Tačiau, kadangi taisyklių nebuvo laikomasi, turėsite išanalizuoti visą kodą visoje grandinėje, kurioje naudojamos kliento tipo katalogo reikšmės, ir aiškiai nustatyti, kad vienu atveju algoritmas turėtų atsižvelgti į profesionalą. kliento aktyvumas ir kitos fizinės savybės.
Tokia forma, kuri siekia Norėdami normalizuoti, gautume dvi lenteles su operaciniais duomenimis ir du katalogus:
- atpažinimo rezultatas nustatytų savybių rinkinio forma,
Atpažintas objekto ID
Greta ant kairės krūtinės
Paukštis ant peties
Veido plaukai
100510
1
1
1
100511
0
0
1
100512
1
0
- kliento tipo nustatymo rezultatas (tebūnie tai pasirinktinis rodinys, kuriame rodomi aprašai iš katalogų)
Ar aptiktas denormalizavimas reiškia, kad sistemų negalima modifikuoti, kad jos atitiktų naujas sąlygas? Žinoma ne. Jeigu įsivaizduotume, kad visas informacines sistemas sukūrė viena komanda, kurioje nėra darbuotojų kaitos, įvykiai yra gerai dokumentuojami ir informacija komandos viduje perduodama be nuostolių, tuomet reikiamus pakeitimus galima padaryti su nežymiai mažai pastangų. Bet jei grįšime prie pradinių problemos sąlygų, 1,5 klaviatūros bus ištrinta vien bendrų diskusijų protokolams spausdinti ir dar 0,5 – pirkimo procedūroms apdoroti.
Aukščiau pateiktame pavyzdyje pažeidžiamos visos trys normalios formos, pabandykime pažeisti jas atskirai.
Pirmosios normalios formos pažeidimas:
Tarkime, prekės pristatomos į jūsų sandėlį iš tiekėjų sandėlių paimant vieną 1.5 tonos gazelę, kuri priklauso jūsų smuklei. Jūsų užsakymų dydis yra toks mažas, palyginti su tiekėjų apyvarta, kad jie visada atliekami vienas prieš vieną, nelaukiant gamybos. Ar reikia atskirų lentelių su tokiu verslo procesu: transporto priemonės, transporto priemonių rūšys, ar reikia atskirti planą ir faktą savo užsakymuose išvykusiems tiekėjams?
Įsivaizduokite, kiek „papildomų“ jungčių turės parašyti jūsų programuotojai, jei programai kurti naudosite toliau pateiktą modelį.
Tarkime, nusprendėme, kad siūloma struktūra yra be reikalo sudėtinga, mūsų atveju plano ir fakto atskyrimas užsakymo įraše yra perteklinė informacija, o sugeneruota užsakymo specifikacija perrašoma pagal atvežtų prekių priėmimo rezultatus, reta klaida -neadekvačios kokybės prekių rūšiavimas ir atvežimas atsiskaitomas už IS ribų.
Ir tada vieną dieną pamatai, kaip visa smuklės salė prisipildo pasipiktinusių ir netvarkingų piratų. Kas nutiko?
Pasirodo, kad augant verslui augo ir vartojimas. Kažkada buvo priimtas vadovybės sprendimas, kad jei gazelė buvo perkrauta tūriu ir/ar svoriu, o tai pasitaikydavo itin retai, tiekėjas pirmenybę teiks kroviniui gėrimų naudai.
Nepristatytos prekės atsidūrė kitame užsakyme ir iškeliavo į naują skrydį, minimalaus likučio buvimas smuklės sandėlyje leido nepastebėti dingusių atvejų.
Paskutinis konkurentas užsidarė uoste, o pradurta gazelės perkrova, apeinama pagal prioritetų nustatymą, remiantis prielaida, kad pakanka minimalaus likučio ir periodinės transporto priemonės perkrovos, tapo įprasta praktika. Sukurta sistema idealiai dirbs pagal joje įdėtus algoritmus ir bus atimta bet kokia galimybė sekti sistemingą planuotų užsakymų nevykdymą. Tik sugadinta reputacija ir nepatenkinti klientai galės aptikti problemą.
Dėmesingas skaitytojas galėjo pastebėti, kad užsakytas kiekis užsakymo specifikacijoje (T_ORDER_SPEC) 2 ir 5 skyriuose gali atitikti arba neatitikti pirmosios normalios formos reikalavimo. Viskas priklauso nuo to, ar, atsižvelgiant į pasirinktą prekių asortimentą, į tą patį lauką gali patekti iš esmės skirtingi matavimo vienetai.
Antrosios normalios formos pažeidimas:
Augant jūsų poreikiams, perkate dar porą skirtingų dydžių transporto priemonių. Šiame kontekste transporto priemonių katalogo kūrimas buvo laikomas pertekliniu, todėl visi pristatymo ir sandėlio poreikius aptarnaujantys duomenų apdorojimo algoritmai krovinio judėjimą iš tiekėjo į sandėlį suvokia kaip išskirtinai 1,5 tonos sveriančio lėktuvo skrydį. gazelė. Taigi kartu su naujų transporto priemonių pirkimu vis tiek kuriate transporto priemonių katalogą, tačiau jį užbaigdami turėsite išanalizuoti visą kodą, nurodantį krovinio judėjimą, kad išsiaiškintumėte, ar kiekvienoje konkrečioje vietoje yra numanomos nuorodos į charakteristikas. pačios transporto priemonės, nuo kurios prasidėjo verslas.
Trečiosios normalios formos pažeidimas:
Kažkuriuo momentu pradedi kurti lojalumo programą, pasirodo nuolatinio kliento įrašas. Kam, pavyzdžiui, gaišti laiką kuriant materialinius rodinius, kuriuose saugomi apibendrinti duomenys apie pardavimą individualiam klientui, kad jie būtų naudojami rengiant ataskaitas ir perkeliami į analitines sistemas, jei lojalumo programos pradžioje viskas, kas domina klientą, gali būti įtraukta į kliento įrašą ? Ir iš tiesų, iš pirmo žvilgsnio, nėra prasmės. Tačiau kiekvieną kartą, kai jūsų verslas susieja, pavyzdžiui, naujus pardavimo kanalus, tarp jūsų analitikų turėtų būti žmogus, kuris prisimins, kad toks agregavimo požymis egzistuoja.
Kuriant kiekvieną naują procesą, pavyzdžiui, pardavimą internetu, pardavimą per platintojus, prijungtus prie bendros lojalumo sistemos, kažkas turi turėti omenyje, kad visi nauji procesai turi užtikrinti duomenų vientisumą kodo lygiu. Pramoninei duomenų bazei su tūkstančiais lentelių tai atrodo neįmanoma užduotis.
Patyręs kūrėjas, žinoma, žino, kaip sustabdyti visas aukščiau paminėtas problemas, tačiau, mano nuomone, patyrusio analitiko užduotis nėra jas iškelti į dienos šviesą.
Norėčiau padėkoti pirmaujančiam kūrėjui Jevgenijui Yaruchin už vertingus atsiliepimus rengiant leidinį.
Literatūra
Connolly Thomas, Begg Caroline. Duomenų bazė. Projektavimas, įgyvendinimas ir palaikymas. Teorija ir praktika
Šaltinis: www.habr.com