Përshëndetje! Më quajnë Andrey Semenov, unë jam analisti i lartë në Sportmaster. Në këtë post, dua të ngrej një çështje mbi denormalizimin e bazave të të dhënave të sistemeve ERP. Do të shqyrtojmë kushtet e përgjithshme, si dhe një shembull të veçantë - le të themi, do të jetë një tavernë e mrekullueshme monopoliste për piratët dhe marinaret. Në të, piratët dhe marinaret duhet të shërbehen ndryshe, pasi paraqitjet për bukurinë dhe modelet e konsumit të këtyre zotërinjve ndryshojnë ndjeshëm.
Si ta bĂ«jmĂ« qĂ« tĂ« gjithĂ« tĂ« jenĂ« tĂ« kĂ«naqur? Si tĂ« mos çmendem duke projektuar dhe mbĂ«shtetur njĂ« sistem tĂ« tillĂ«? ĂfarĂ« tĂ« bĂ«jmĂ« nĂ«se nĂ« tavernĂ« fillojnĂ« tĂ« vijnĂ« jo vetĂ«m piratĂ«t dhe marinaret e njohur?
Të gjitha nën kat. Por le të shkojmë me radhë.
1. Kufizimet dhe supozimet
E gjithë kjo përmbajtje iu referohet vetëm bazave të të dhënave relacional. Pasojat e denormalizimit, të cilat janë të miratuara edhe në internet, në formën e anomali modifikimi, eliminimi dhe ndihmës, nuk diskutohen. Rastet ku denormalizimi është i zakonshëm, me shembuj klasikë: numri dhe seria e pasaportës, data dhe koha etj., janë lënë jashtë publikimit.
Në postin e përdorur janë definicionet intuitivisht kuptimplotë dhe praktikisht të aplikueshme të formave normale, pa referenca në terma matematikorë. Në atë formë, siç mund të aplikohen në shqyrtimin e realiteteve të proceseve të biznesit (BP) dhe projektimin e softuerit industrial.
Ekziston një mendim se projektimi i skllevërve të të dhënave, mjeteve për krijimin e raportimit dhe marrëveshjeve integruese (ku përdoret përfaqësimi tabelar i informacionit), dallon nga projektimi i bazave të të dhënave të sistemeve ERP në atë që lehtësia e konsumit dhe zbatimi për të arritur denormalizimin e vetëdijshëm mund të ketë përparësi mbi ruajtjen e integritetit të të dhënave. Unë e ndajem këtë mendim, dhe ajo që do të përshkruhet më poshtë lidhet ekskluzivisht me modelet e të dhënave kryesore dhe të dhënat transaksionale të sistemeve ERP.
PĂ«rshkrimi i formave normale Ă«shtĂ« dhĂ«nĂ« nĂ« njĂ« shembull tĂ« kuptueshĂ«m nĂ« nivelin e zakonshĂ«m pĂ«r shumicĂ«n e lexuesve. MegjithatĂ«, si njĂ« ilustrim i dukshĂ«m nĂ« pikat 4-5, Ă«shtĂ« pĂ«rdorur qĂ«llimisht njĂ« detyrĂ« theksuar "e shpikur". NĂ«se nuk e bĂ«ni kĂ«tĂ« dhe merrni njĂ« shembull tĂ« njohur, pĂ«r shembull, modelin e ruajtjes sĂ« porosisĂ« nga p. 2, mund tĂ« pĂ«rfundoni nĂ« njĂ« situatĂ« ku fokusi i vĂ«mendjes sĂ« lexuesit do tĂ« kalojĂ« nga pĂ«rshkrimi i ofruar i procesit nĂ« model, nĂ« pĂ«rvojĂ«n dhe perceptimin personal tĂ« asaj si duhet tĂ« ndĂ«rtohen proceset dhe modelet e ruajtjes sĂ« tĂ« dhĂ«nave nĂ« IS. Me fjalĂ« tĂ« tjera, merrni dy analistĂ« tĂ« kualifikuar IT, le tĂ« japĂ« njĂ«ri shĂ«rbim logjistikĂ«ve qĂ« transportojnĂ« pasagjerĂ«, tjetri â logjistikĂ«ve qĂ« transportojnĂ« makina pĂ«r prodhimin e mikroçipave. KĂ«rkoni prej tyre, pa diskutuar paraprakisht proceset e automatizueshme, tĂ« hartojnĂ« njĂ« model tĂ« dhĂ«nash pĂ«r ruajtjen e informacionit mbi njĂ« udhĂ«tim hekurudhor.
Ekziston një probabilitet i konsiderueshëm që në modelet e propozuara ju do të gjeni jo vetëm një grup të ndryshëm atributesh, por edhe grupe entitete të papajtueshme, sepse çdo analist do të mbështetet në proceset dhe detyrat e njohura për të. Dhe për të thënë në një situatë të tillë, se cila model është "e saktë", është e pamundur, sepse nuk ka një kriter vlerësimi.
2. Formate normale
Forma e parë normale e DB kërkon atomizimin e të gjitha atributeve.
Në veçanti, nëse një objekti A i ekzistojnë atribute jështore a dhe b, të tilla që c=f(a,b) dhe në tabelën që përshkruan objektin A ju ruani vlerën e atributit c, atëherë në DB është shkelur forma e parë normale. Për shembull, nëse në specifikimin e porosisë tregohet sasia, njësi të cilat varen nga lloji i produktit: në një rast mund të jenë copë, në tjetrin litra, në të tretin paketa që përbëhen nga copa (në modelin e mësipërm Good_count_WR), atëherë në DB është shkelur atomizmi i atributeve. Në këtë rast, për të thënë se si duhet të duket grupi i tabelave në specifikimin e porosisë, nevojitet një përshkrim i qartë i procesit të punës në IS, dhe pasi proceset mund të jenë të ndryshme, atëherë edhe versionet "e sakta" mund të jenë të shumta.
Forma e dytë normale e DB kërkon respektimin e formes së parë dhe një tabele të veçantë për çdo entitet që lidhet me procesin e punës në IS. Nëse në një tabelë ekzistojnë varësi me =f1(a) dhe d=f2(b) dhe nuk ekziston varësi me =f3(b), atëherë tabela shkel formën e dytë normale. Në shembullin e mësipërm, në tabelën "Porosi" nuk ekziston një varësi mes porosisë dhe adresës. Ndryshoni emrin e rrugës ose qytetit, dhe nuk do të merrni ndonjë ndikim në atributet thelbësore të porosisë.
Forma e tretë normale e DB kërkon respektimin e formës së dytë normale dhe mungesën e varësive funksionale midis atributeve të entiteteve të ndryshme. Kjo rregull mund të formulohet kështu: "gjithçka që mund të llogaritet, duhet të llogaritet". Në terma të tjerë, nëse ekzistojnë dy objekte A dhe B. Në tabelën që mban atributet e objektit A, shfaqet atributi C, dhe për objektin B ekziston një atribut b, të tillë që ekziston c=f4(b), atëherë është shkelur forma e tretë normale. Në shembullin e mëposhtëm, atributi "Numri i copave" (Total_count_WR) në regjistrimin e porosisë qartë pretendohet se shkel formën e tretë normale.
3. Qasja ime ndaj përdorimit të normalizimit
1. Vetëm procesi i automatikshën me qëllim të biznesit mund të ofrojë analistin kriteret për identifikimin e entiteteve dhe atributeve gjatë krijimit të modelit të ruajtjes së të dhënave. Krijimi i modelit të procesit është një kushte e domosdoshme për krijimin e një model normal të të dhënave.
2. Arritja e formës së tretë normale në kuptimin e saktë mund të mos jetë e arsyeshme në praktikën reale të krijimit të sistemeve ERP kur përmbushen disa ose të gjitha kushtet e mëposhtme:
- proceset automatizues shpesh nuk i nënshtrohen ndryshimeve,
- koha për hulumtim dhe zhvillim është e shpejtë,
- kërkesat për integritetin e të dhënave janë relativisht të ulëta (gabime të mundshme në programin industrial nuk çojnë në humbje të parave ose klientëve nga ana e blerësit të softuerit)
- NĂ« mekanizmin e lidhjes sĂ« tabelave tĂ« jashtme Foreign Data Wrapper (postgres_fdw) Ă«shtĂ« realizuar mbĂ«shtetje pĂ«r autentikimin e bazuar nĂ« certifikata. Kur pĂ«rdoret autentikimi SCRAM, klientĂ«ve u lejohet tĂ« kĂ«rkojnĂ« â
Nën kushtet e përshkruara, shpenzimet për identifikimin, përshkrimin e ciklit të jetës së disa objekteve dhe atributeve të tyre mund të mos justifikohen nga këndvështrimi i efikasitetit ekonomik.
3. Ădo pasojĂ« denormalizimi e modelit tĂ« tĂ« dhĂ«nave nĂ« njĂ« IS tĂ« krijuar tashmĂ« mund tĂ« kurohet me hulumtim tĂ« kujdesshĂ«m tĂ« kodit dhe testimit.
4. Denormalizimi është një metodë për të transferuar ngarkesën e punës nga faza e hulumtimit të burimeve të të dhënave dhe projektimit të procesit të biznesit në fazën e zhvillimit, nga periudha e zbatimit në periudhën e zhvillimit të sistemit.
5. Së bashku me formën e tretë normale të DB është e arsyeshme të synohet kur:
- Korrigjimi i proceseve të biznesit përkatëse është i papërshkrueshëm.
- Brenda ekipit të zbatimit dhe/ose zhvillimit ka një ndarje të dobët të punës.
- Sistemet që bëjnë pjesë në konturin integrues zhvillohen sipas planeve të tyre.
- Mosqartësia e të dhënave mund të çojë në humbje të klientëve ose parave për kompaninë.
6. Projektimi i modelit të të dhënave duhet të realizohet nga analisti vetëm në lidhje me modelet e procesit të biznesit të synuar dhe procesit në IS. Nëse projektimi i modelit të të dhënave merret nga zhvilluesi, ai do të duhet të thellojë njohuritë e tij në fushën e temës deri në atë masë sa të kuptojë veçanërisht ndryshimin midis vlerave të atributëve - kushti themelor për të nxjerrë atributet atomike. Kështu, ai merr përsipër funksione që nuk i përkasin.
4 Detyra për ilustrim
Supozoni se keni një tavernë të vogël robotike në port. Segmenti juaj i tregut: marinaret dhe pirate që hyjnë në port dhe kanë nevojë për pushim. Marinaret ju blejnë çaj me majdanek, ndërsa pirateve ju shisni rum dhe kocka për dhëmbë për të shfryrë mjekrën. Shërbimi brenda tavernës ofrohet nga një robot-hostes dhe një robot-barman. Falë cilësisë së lartë dhe çmimeve të ulta keni eliminuar të gjithë konkurentët, kështu që çdo njeri që zbret nga anija vjen në tavernën tuaj, e cila është e vetmja në port.
Kompleksi i sistemeve informative të tavernës përbëhet nga programet e mëposhtme:
- Sistemi i parandalimit të hershëm për klientët, që njeh kategorinë e tyre sipas karakteristikave dalluese.
- Sistemi i menaxhimit të robotëve-hostes dhe robotëve-barmanë.
- Sistemi i menaxhimit të magazinës dhe shpërndarjes në pikën e shitjes.
- Sistemi i menaxhimit të marrëdhënieve me furnizuesit (SUMP)
Procesi:
Sistemi i parandalimit të hershëm njeh njerëzit që zbresin nga anija. Nëse një person është i rruar mirë, ai e identifikon si marinar, ndërsa nëse një person i është zbuluar një mjekër, ai identifikohet si pirate.
Duke hyrë në tavernë, vizitori dëgjon nga robot-hostesi një përshëndetje në përputhje me kategorinë e tij, për shembull: "Ho-ho-ho, i nderuari pirate, kaloni te tavolina nr..."
Ekipi kalon në tryezën e caktuar, ku roboti-barman ka përgatitur tashmë produktet për të sipas kategorisë. Roboti-barman i dërgon informacionin sistemit të magazinimit se sasia tjetër e dërgesës duhet të rritet, ndërsa sistemi i informacionit të magazinës formon një kërkesë për blerje në SUMP në bazë të stoqeve në magazinë.
Le të thoni se sistemi i paralajmërimit të hershëm është krijuar nga IT-ja juaj e brendshme, ndërsa programi i menaxhimit të robotëve barmen është zhvilluar nga një kontraktor i jashtëm, saktësisht për biznesin tuaj. Sistemët për menaxhimin e magazinës dhe marrëdhënieve me furnitorët janë zgjidhje të personalizuara të paketuar nga tregu.
5. Shembuj të denormalizimit dhe ndikimi i tij në zhvillimin e softuerit
Gjatë projektimit të procesit të biznesit, ekspertët e pyetur në fushë thanë njëzëri se në të gjithë botën piratët pijnë rum dhe shpëlarin mjekrën me tharëse kockash, ndërsa marinarët pijnë çaj me xhaxh dhe janë gjithmonë të rruajtur mirë.
Shfaqet njĂ« katalog i tipeve tĂ« klientĂ«ve me dy vlera: 1- piratĂ«t, 2 â marinarĂ«t, i pĂ«rgjithshĂ«m pĂ«r gjithĂ« kufirin informativ tĂ« kompanisĂ«.
Sistemi i paralajmërimit për klientin menjëherë ruan rezultatin e përpunimit të imazhit si identifikues (ID) të klientit të njohur dhe lloji i tij: marinar ose pirat.
ID e objektit të njohur
Kategoria e klientit
100500
Pirate
100501
Pirate
100502
Marinar
Të kthejmë vëmendjen, që
1. Marinaret tanë në të vërtetë janë njerëz të rruar
2. Pirate tanë në të vërtetë janë njerëz me mjekër
Cilat probleme duhet të zgjidhen në këtë rast, për të arritur që struktura jonë të ketë formën e tretë normale:
- shkelja e atomizmit tĂ« atributit â Kategoria e klientit
- përzierja e faktit të analizuar dhe përfundimit në një tabelë
- varësia funksionale e regjistruar midis atributeve të subjekteve të ndryshme.
Në formën e normalizuar, do të kishim dy tabela:
- rezultati i njohjes si një grup i karakteristikave të caktuara,
ID e objektit të njohur
Mjekra
100500
Po.
100501
Po.
100502
Jo
- rezultati i përcaktimit të llojit të klientit si aplikimi i logjikës së vendosur në sistemin e informacionit për interpretimin e karakteristikave të caktuara
ID e objektit të njohur
ID e identifikimit
Kategoria e klientit
100500
100001
Pirate
100501
100002
Pirate
100502
100003
Marinar
Si organizimi i normalizuar i ruajtjes së të dhënave mund ta lehtësojë zhvillimin e kompleksit të sistemeve informacionit? Le të supozojmë se papritur keni klientë të rinj. Le të jenë ata piratë japonezë, të cilët mund të mos kenë mjekër, por ecin me një papagal mbi supin, dhe piratët ekologjistë, me profilin blu të Gretës në gjoksin e majtë, që do t'i njihni lehtësisht.
Piratët ekologjistë, natyrisht, nuk mund të përdorin krehra nga kocka dhe kërkojnë një alternativë nga plastika e ricikluar detare.
Ju nevojitet të rregulloni algoritmet e funksionimit të programeve sipas inputeve të reja. Po të ishin zbatuar rregullat e normalizimit, do t'ju duhej vetëm të plotësonit disa hyrje për disa dega të proceseve në disa sisteme dhe të krijonit dega të reja vetëm për rastet dhe në sistemet ku mbulimi i fytyrës ka rëndësi. Por, pasi rregullat nuk u zbatuan, ju duhet të analizoni të gjithë kodin, në të gjithë konturin ku përdoren vlerat e referencës për llojet e klientëve dhe të përcaktoni qartë se në një rast algoritmi duhet të marrë parasysh aktivitetin profesionist të klientit, ndërsa në një rast tjetër karakteristikat fizike.
Në formën e tillë, po synojnë në normalizimin e saj, do të kishim dy tabela me të dhëna operative dhe dy referenca:
- rezultati i njohjes si një grup i karakteristikave të caktuara,
ID e objektit të njohur
Greta në gjoksin e majtë
Pteza mbi sup
Mjekra
100510
1
1
1
100511
0
0
1
100512
1
0
- rezultati i përcaktimit të llojit të klientit (le të jetë kjo një paraqitje përdoruesi, në të cilën shfaqen përshkrimet nga referencat)
A do të thotë denormalizimi i zbuluar se sistemet nuk do të mund të përmirësohen për kushtet e reja? Sigurisht që jo. Nëse e imagjinoni se të gjitha sistemet informacionit ishin krijuar nga një ekip me flukse të zeros, zhvillimet janë dokumentuar mirë dhe informacioni brenda ekipit kalon pa humbje, atëherë ndryshimet e nevojshme mund të realizohen me përpjekje minimale. Por, nëse kthehemi në kushtet fillestare të detyrës, vetëm për të printuar protokollet e diskutimeve të përbashkëta do të fshihen 1.5 tastiera dhe një tjetër 0.5 për formatin e procedurave të blerjeve.
Në shembullin e mësipërm, janë shkelur të tri format normale, le të provojmë t'i shkelim ato një e nga një.
Shkelja e formës së parë normale:
Supozoni se që mallrat në magazinën tuaj dërgohen nga magazinat e furnizuesve me vetë-marrje duke përdorur një Gazelë prej 1.5 tonësh që i takon tavernës tuaj. Madhësia e porosive tuaja është aq e vogël në raport me qarkullimin e furnizuesve, sa që ato realizohen gjithmonë një për një pa pritur për prodhimin. A nevojiten tabelat e veçanta për këtë BP: mjete transporti, lloje mjete transporti, a duhet të ndahen planin dhe faktin në porositë tuaja të dërguara te furnizuesit?
Mendojeni sa shumĂ« âkoneksione tĂ« tepĂ«rtaâ do tĂ« duhet tĂ« shkruajnĂ« programuesit tuaj, nĂ«se pĂ«r zhvillimin e programit pĂ«rdoret modeli mĂ« poshtĂ«.
Supozoni se ne morëm vendimin se struktura e propozuar është tepër e komplikuar, për rastin tonë ndarja e planit dhe faktit në rekordet e porosisë është informacion i tepërt, dhe specifikimi i formuar i porosisë rishkruhet sipas rezultateve të pranuara të mallrave të mbërritura, raste të rralla të humbjes dhe dorëzimit të mallrave të cilësisë së pamjaftueshme rregullohen jashtë SIS.
Dhe njĂ« ditĂ« e shihni sallĂ«n e tavernĂ«s plot me pirate tĂ« zemĂ«ruar dhe tĂ« paushqyer. ĂfarĂ« ndodhi?
Doli që me rritjen e biznesit tuaj, rritet edhe konsumimi. Disa herë, ishte marrë një vendim menaxherial, që nëse gazela ishte e ngarkuar tej kapacitetit sipas vëllimit dhe/ose peshës, gjë që ndodhte jashtëzakonisht rrallë, furnizuesi prioritizonte ngarkesën në favor të pijeve.
Malli i papërfunduar kalonte në porosinë e ardhshme dhe ishte dërguar në një fluturim të ri, prania e një mbetjeje të pakapërcyeshme në magazinë pranë tavernës e lejonte të mos vërehej rastet e humbura.
Në port u mbyll konkurrenti i fundit, dhe rasti i humbur i ngarkesës së gazelës, i anashkaluar nga prioritizimi i bazuar në supozimin e mjaftueshmërisë së mbetjeve të pakapërcyeshme dhe ngarkesës periodike të mjeteve, u bë praktikë e zakonshme. Sistemi i krijuar do të punojë perfekt në përputhje me algoritmet e vendosura brenda tij dhe do të jetë i privuar nga çdo mundësi për të ndjekur mosrealizimin sistematik të porosive të përcaktuara. Vetëm reputacioni i prishur dhe klientët e pakënaqur do të jenë në gjendje të zbulojnë problemin.
Një lexues i vëmendshëm me siguri e ka vënë re se sasia e porositur në specifikimin e porosisë (T_ORDER_SPEC) në seksionet 2 dhe 5 mund të përmbushë dhe ndonjëherë nuk përmbush kërkesën e normës së parë normale. E gjithë kjo varet nga nëse, për shasshin e mallrave të zgjedhura, mund të bien në të njëjtin fushë njësi matëse të ndryshme në thelb.
Shkelja e normës së dytë normale:
Me rritjen e kërkesave tuaja, blini disa mjete transporti me përmasa të ndryshme. Në kontekstin e paraqitur më lart, krijimi i një udhëzuesi për mjetet e transportit u konsiderua i tepruar, duke bërë që të gjithë algoritmet e punës me të dhënat që shërbejnë nevojave të shpërndarjes dhe magazinimit të perceptojnë lëvizjen e mallrave nga furnizuesi në magazinë si një fluturim ekskluzivisht me furgonin 1.5-ton. Pra, së bashku me blerjen e mjeteve të reja, ju gjithsesi krijoni një udhëzues për mjetet e transportit, por gjatë ripunimit do t'ju duhet të analizoni të gjithë kodin që referohet në lëvizjen e mallrave për të zbuluar nëse në çdo rast të caktuar ka lidhje me karakteristikat e atij automobili me të cilin filloi biznesi.
Shkelja e normës së tretë normale:
Në një moment, ju filloni të krijoni një program besnikërie, duke u shfaqur regjistrimi i një klienti të rregullt. Pse, për shembull, të humbni kohë në krijimin e prezantimeve materiale që ruajnë të dhënat e agreguara për shitjet e një klienti për t'u përdorur në raportim dhe për t'u dërguar në sistemet analitike, nëse në fazën fillestare të programit të besnikërisë, gjithçka që shqetëson blerësin mund të vendoset në regjistrin e vet klientit? Dhe, me të vërtetë, fillimisht duket se nuk ka kuptim. Por sa herë që biznesi juaj do të lidhet, për shembull, me kanale të reja shitjesh, duhet të jetë dikush midis analistëve tuaj që të kujtojë se ekziston një atribut agregues.
Duke projektuar çdo proces të ri, le të themi, shitjet në internet, shitjet përmes distributorëve të lidhur me sistemin e përbashkët të besnikërisë, dikush duhet të mbajë mend se të gjithë proceset e reja duhet të garantojnë integritetin e të dhënave në nivelin e kodit. Për një DB industrial me mijëra tabela, kjo duket si një detyrë e papërmbushshme.
Një zhvillues i përparuar, sigurisht që di si të menaxhojë të gjitha problemet e përmendura më lart, por, sipas mendimit tim, detyra e një analisti të përvojës është që të mos i lejojë ato.
Dua të shpreh mirënjohjen time për feedback-un e çmuar gjatë përgatitjes së publikimit për zhvilluesin e njohur Evgenij Yaruhinin.
Literatura
Connolly Thomas, Begg Caroline. Bazat e të dhënave. Projektimi, implementimi dhe mbështetjes. Teoria dhe praktika
Burimi: habr.com
