PĂ«rshĂ«ndetje! MĂ« quajnĂ« Andrei Semenov, unĂ« jam analist senior nĂ« Sportmaster. NĂ« kĂ«tĂ« postim do tĂ« diskutoj mbi çështjen e denormalizimit tĂ« bazave tĂ« tĂ« dhĂ«nave ERP. Do tĂ« shqyrtojmĂ« kushtet e pĂ«rgjithshme dhe gjithashtu njĂ« shembull konkret â le tĂ« themi se do tĂ« jetĂ« njĂ« tavernĂ« monopolit pĂ«r pirate dhe detarĂ«. NĂ« tĂ«, pirate dhe detarĂ«t duhet tĂ« trajtohen ndryshe, sepse konceptet mbi tĂ« bukurĂ«n dheæšĄćŒt e konsumit tĂ« kĂ«tyre zotĂ«rinjve ndahen nĂ« mĂ«nyrĂ« tĂ« rĂ«ndĂ«sishme.
Si tĂ« bĂ«jmĂ« qĂ« tĂ« gjithĂ« tĂ« jenĂ« tĂ« kĂ«naqur? Si tĂ« mos çmendem kur projektoj dhe mbaj njĂ« sistem tĂ« tillĂ«? ĂfarĂ« tĂ« bĂ«jmĂ« nĂ«se nĂ« tavernĂ« fillojnĂ« tĂ« vijnĂ« jo vetĂ«m pirate dhe detarĂ« tĂ« zakonshĂ«m?
T gjithçka është më poshtë. Por le të ecim në radhë.
1. Kufizimet dhe supozimet
Ădo gjĂ« e shkruar i referohet vetĂ«m bazave tĂ« tĂ« dhĂ«nave relacionale. Pasojat e denormalizimit, tĂ« cilat janĂ« mirĂ« tĂ« njohura, pĂ«rfshirĂ« ato nĂ« internet, si anomalitĂ« e modifikimit, fshirjes dhe inserimit, nuk diskutohen. Rastet ku denormalizimi Ă«shtĂ« i zakonshĂ«m, me shembuj klasikĂ«, si serie dhe numri i pasaportĂ«s, data dhe ora etj., lihen jashtĂ« kĂ«tij publikimi.
Në postim përdoren definita intuitivisht të kuptueshme dhe praktikisht të aplikueshme për format normale, pa referenca në terma matematikorë. Në formën se si ato mund të aplikohen në shqyrtimin e proceseve të vërtetë të biznesit (BP) dhe projektimin e softuerëve industrialë.
Ekziston një mendim se projektimi i depozitave të të dhënave, mjeteve për prodhimin e raporteve dhe marrëveshjeve integruese (në të cilat përdoret paraqitja tabelare e informacionit), ndryshon nga projektimi i bazave të të dhënave ERP në kuptimin që lehtësia e konsumit dhe aplikimi për të arritur atë, denormalizimi i vetëdijshëm mund të ketë prioritet ndaj mbrojtjes së integritetit të të dhënave. Unë e ndaj këtë mendim, dhe ajo që do të përshkruhet më poshtë i përket ekskluzivisht modeleve të të dhënave kryesore dhe të dhënave transaksionale të sistemeve ERP.
Shpjegimi i formave normale jepet me një shembull që shumica e lexuesve e kuptojnë në nivelin e zakonshëm të përditshëm. Megjithatë, si një ilustrim vizual në pikat 4-5, është përdorur me vetëdije një detyrë theksueshëm "e shpikur". Nëse nuk e bëni këtë dhe merrni ndonjë shembull klasikor, si modeli i depozitimit të porosive nga pika 2, mund të përfundoni në një situatë ku fokusi i vëmendjes së lexuesit do të zhvendoset nga propozimi i ndarjes së procesit në model, në përvojën personale dhe perceptimin e asaj si duhet ndërtuar proceset dhe modelet e depozitimit të të dhënave në IS. Me fjalë të tjera, merrni dy analistë IT të kualifikuar, le të thoni se njëri ofron shërbim logjistikë për ata që transportojnë pasagjerë, tjetri për ata që transportojnë makina për prodhimin e mikroçipave. Kërkoni nga ata, pa e diskutuar paraprakisht procesin e automatizueshëm, të hartojnë një model të dhënash për ruajtjen e informacionit mbi transportin hekurudhor.
Ekziston një probabilitet jo zero se në modelet e propozuara do të gjeni jo vetëm një grup të dukshëm atributesh të ndryshme, por gjithashtu grupe entitetesh që nuk përputhen, sepse çdo analist do të mbështetet në proceset dhe detyrat që i ka mësuar. Dhe të thuash në një situatë të tillë se cila model është "e saktë" është e pamundur, sepse nuk ka kriter vlerësimi.
2. Format normale
Forma normale e parë të BD kërkon atomikë të çdo atribute.
Në veçanti, nëse një objekti A i përkasin atribute jo kryesore a dhe b, të tilla që c=f(a,b) dhe në tabelën që përshkruan objektin A ruani vlerën e atributeve c, atëherë BD e ka shkelur formën normale të parë. Për shembull, nëse në specifikimin e porosisë jepet sasia, njësitë e matjes së së cilave varen nga lloji i mallrave: në një rast ato mund të jenë copa, në rastin tjetër litra, në të tretin pako që përbëhen nga copa (në modelin më sipër Good_count_WR), atëherë BD ka shkelur atomikën e atributeve. Në këtë rast, për të thënë si duhet të duket grupi i tabelave në specifikimin e porosisë, nevojitet një përshkrim shënjestër të procesit të punës në IS, dhe për sa kohë që proceset mund të jenë të ndryshme, ka shumë versione "të sakta".
Forma normale e dytë të BD kërkon përmbushjen e formës së parë dhe një tabelë të vetme për çdo entitet që lidhet me procesin e punës në IS. Nëse në një tabelë ekzistojnë varësi me s=f1(a) dhe d=f2(b) dhe nuk ekziston varësi me s=f3(b), atëherë tabela e ka shkelur formën normale të dytë. Në shembullin më sipër në tabelën "Porosi" nuk ekziston varësi midis porosisë dhe adresës. Ndryshoni emrin e rrugës ose të qytetit, dhe nuk do të merrni ndonjë ndikim në atributet thelbësore të porosisë.
Forma normale e tretë të BD duhet të përmbushë formën e dytë normale dhe të mos ketë varësi funksionale midis atributeve të entiteteve të ndryshme. Ky rregull mund të formullohet kështu: «gjithçka që mund të llogaritet, duhet të llogaritet». Në fjalë të tjera, nëse ekzistojnë dy objekte A dhe B. Në tabelën që ruan atributet e objektit A, shfaqet atributi C, ndërsa në objektin B ekziston një atribut b, i tillë që ka një c=f4(b), atëherë është shkelur forma e tretë normale. Në shembullin e mëposhtëm, atributi «Numri i disa artikujve» (Total_count_WR) në regjistrin e porosisë qartë pretendon të shkelë formën e tretë normale.
3. Qasja ime për aplikimin e normalizimit
1. Vetëm procesi i qëllimshëm dhe i automatizueshëm i biznesit mund të sigurojë analistin me kritere për identifikimin e entiteteve dhe atributeve gjatë krijimit të modelit të ruajtjes së të dhënave. Krijimi i modelit të procesit është një kusht i detyrueshëm për krijimin e një modeli normal të të dhënave.
2. Arritja e formes së tretë normale në kuptimin e saktë mund të mos jetë e arsyeshme në praktikën e vërtetë të krijimit të sistemeve ERP nëse plotësohen disa ose të gjitha kushtet e mëposhtme:
- proceset e automatizueshme rrallë ndryshojnë,
- koha për hulumtim dhe zhvillim është e kufizuar,
- kërkesat për integritetin e të dhënave janë relativisht të ulëta (gabimet potenciale në softuerin industrial nuk çojnë në humbje parash apo klientësh për blerësin e softuerit)
- etj.
Në këto kushte, shpenzimet për identifikimin dhe përshkrimin e ciklit të jetës së disa objekteve dhe atributeve të tyre mund të mos justifikohen nga pikëpamja e efikasitetit ekonomik.
3. Cdo pasojë e denormalizimit të modelit të të dhënave në një SI të krijuar tashmë mund të menaxhohet përmes një hulumtimi të kujdesshëm të kodit dhe testimit.
4. Denormalizimi është një mënyrë për të transferuar punën e nevojshme 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. ĂshtĂ« e arsyeshme tĂ« synohet forma e tretĂ« normale tĂ« DB nĂ«se:
- Direksioni i ndryshimit të proceseve të automatizuar të biznesit është i paparashikueshëm
- Brenda ekipit të zbatimit dhe/ose zhvillimit ekziston një ndarje e dobët e punës
- Sistemet që janë pjesë e konturit integrues të zhvillohen sipas planeve të tyre
- Inkoherenca e të dhënave mund të çojë në humbjen e klientëve ose parave për kompaninë
6. Projektimi i modelit tĂ« tĂ« dhĂ«nave duhet tĂ« kryhet nga analisti vetĂ«m nĂ« lidhje me modelet e procesit tĂ« biznesit dhe procesit nĂ« SI. NĂ«se projektimin e modelit tĂ« tĂ« dhĂ«nave e bĂ«n zhvilluesi, ai duhet tĂ« pĂ«rfshihet nĂ« fushĂ«n e subjektit nĂ« mĂ«nyrĂ« qĂ«, nĂ« veçanti, tĂ« kuptojĂ« ndryshimin midis vlerave tĂ« atributeve â njĂ« kusht i nevojshĂ«m pĂ«r identifikimin e atributeve atomike. KĂ«shtu, ai merr pĂ«rsipĂ«r funksione jo tĂ« zakonshme.
4 Detyra për ilustrim
Supozoni se keni një tavernë të vogël robotizuese në port. Segmenti juaj i tregut: marinarët dhe piratët, të cilët hyjnë në port dhe kanë nevojë për pushim. Marinart i shisni çaj me rigon, dhe pirateve rum dhe brushat kockore për të pastruar mjekrën. Shërbimi në taverna vetë ofrohet nga një robot-hostes dhe një robot-barman. Falë cilësisë së lartë dhe çmimeve të ulëta, keni dëbuar të gjithë konkurrentët, duke u bërë që çdo njeri që zbret nga anija të vijë në tavernën tuaj, e cila është e vetme në port.
Kompleksi i sistemeve informacioni të tavernës përbëhet nga programet e mëposhtme:
- Sistemi i njoftimit të hershëm për klientin, i cili e njeh kategorinë e tij 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 njoftimit të hershëm njeh ata që zbresin nga anija. Nëse një person është rruajtur, ai e përcakton si marinar, nëse personi ka një mjekër, atëherë ai përcaktohet si pirat.
Duke hyrĂ« nĂ« tavernĂ«, mysafiri dĂ«gjon nga robot-hostes njĂ« pĂ«rshĂ«ndetje nĂ« pĂ«rputhje me kategorinĂ« e tij, pĂ«r shembull: «Ho-ho-ho, i nderuar pirat, kaloni te tavolina nr.âŠÂ»
Mysafiri kalon te tavolina e caktuar, ku robot-barmani tashmë ka përgatitur për të produktet sipas kategorisë. Robot-barmani i dërgon informacionin në sistemin e magazinës se sasia tjetër e shpërndarjes duhet të rritet, sistemi i magazinës duke u bazuar në rezervat në magazinë formon një kërkesë për blerje në SUMP.
Le të jetë sistemi i paralajmërimit të hershëm i zhvilluar nga IT-ja juaj e brendshme, ndërsa programin për menaxhimin e robotëve të barit e krijoi një kontraktor i jashtëm specifikisht për biznesin tuaj. Sistemët për menaxhimin e magazinës dhe marrëdhënieve me furnitorët janë zgjidhje kutish të personalizuara nga tregu.
5. Shembuj të denormalizimit dhe ndikimi i tij në zhvillimin e softuerit
Gjatë projektimit të procesit të biznesit, ekspertët e anketuar të fushës deklaruan me një zë se në të gjithë botën piratët pijnë rum dhe shqetësohen me mjekra me krehra prej kocke, ndërsa detarët pijnë çaj me tym dhe janë gjithmonë të rruar mirë.
Krijohet njĂ« katalog i tipeve tĂ« klientĂ«ve me dy vlera: 1- piratĂ«t, 2 â detarĂ«t, e pĂ«rbashkĂ«t pĂ«r gjithĂ« informacionin nĂ« kontur 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 tipit të tij: detar ose pirat.
ID e objektit të njohur
Kategoria e klientit
100500
Pirat
100501
Pirat
100502
Detar
Le të theksojmë përsëri që
1. Detarët tanë janë në të vërtetë njerëz të rruar
2. Piratët tanë janë në të vërtetë njerëz me mjekra
ĂfarĂ« problemeve duhet t'i zgjidhim nĂ« kĂ«tĂ« rast, nĂ« mĂ«nyrĂ« qĂ« struktura jonĂ« tĂ« synojĂ« formĂ«n e tretĂ« normale:
- shkelja e atomizimit 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ë entiteteve të ndryshme.
Në formën e normalizuar do të kishim dy tabela:
- rezultati i njohjes në formën e një grupi të tipareve të përcaktuara,
ID e objektit të njohur
Përkatësia e qimeve në fytyrë
100500
Po
100501
Po
100502
Jo
- rezultati i përcaktimit të tipit të klientit si aplikim i logjikës të integruar në IS për interpretimin e tipareve të përcaktuara
ID e objektit të njohur
ID e identifikimit
Kategoria e klientit
100500
100001
Pirat
100501
100002
Pirat
100502
100003
Detar
Si mund të lehtësojë organizimi i normalizuar i ruajtjes së të dhënave zhvillimin e kompleksit të IS? Le të themi se papritur ju shfaqen klientë të rinj. Le të jenë këta piratë japonezë të cilët nuk kanë mjekra, por ndajnë zogun në sup, dhe piratët ekologjikë, i njihni lehtësisht nga profili blu i Gretës në gjoksin e majtë.
Piratët ekologjikë, natyrisht, nuk mund të përdorin krehra prej kocke dhe kërkojnë një alternativë nga plastika detare e ricikluar.
Ju nevojitet të rishikoni algoritmet e punës së programeve për t'iu përshtatur inputeve të reja. Po të ishin zbatuar rregullat e normalizimit, do t'ju duhej vetëm në disa sisteme të shtoni hyrjet për disa degë të proceseve dhe të krijoni dega të reja vetëm për ato raste dhe në ato IS, ku ka rëndësi përkatësia e qimeve në fytyrë. Por, duke qenë se rregullat nuk u zbatuan, do t'ju duhej të analizoni të gjithë kodin, në të gjithë konturët ku përdoren vlerat e katalogut të tipeve të klientëve dhe të përcaktoni qartë se në një rast algoritmi duhet të marrë parasysh veprimtarinë profesionale të klientit, ndërsa në një tjetër veçoritë fizike.
Në formën që synon në formën e normalizuar, do të kishim dy tabela me të dhëna operative dhe dy kataloge:
- rezultati i njohjes në formën e një grupi të tipareve të përcaktuara,
ID e objektit të njohur
Greta në gjoksin e majtë
Zogu në sup
Përkatësia e qimeve në fytyrë
100510
1
1
1
100511
0
0
1
100512
1
0
- rezultati i përcaktimit të tipit të klientit (le të jetë një paraqitje përdoruese, ku do të shfaqen përshkrimet nga katalogët)
Nënkupton denormalizimi i zbuluar se sistemet nuk do të mund të përmirësohen për kushtet e reja? Sigurisht që jo. Nëse imagjinojmë se të gjitha IS janë krijuar nga një ekip me fluks të papërmbajtur, zhvillimet janë dokumentuar mirë dhe informacioni në ekip kalon pa humbje, atëherë ndryshimet e kërkuara mund të realizohen me përpjekje të papërfillshme. Por, po të kthehemi tek kushtet fillestare të problemit, vetëm për të printuar protokollet e diskutimeve të përbashkëta do të fshihen 1.5 tastierë dhe edhe 0.5 për formimin e procedurave të blerjes.
Në shembullin e mësipërm, janë shkelur të tri format normale, le të provojmë t'i shkelim ato në mënyrë të veçantë.
Shkelja e formës së parë normale:
Le të themi, mallrat në magazinën tuaj dërgohen nga magazinat e furnitorëve me vetëmbledhje duke përdorur një furgon 1.5-ton që i përket tavernës tuaj. Sasia e porosive tuaja është kaq e vogël në krahasim me qarkullimin e furnitorëve, saqë ato realizohen gjithmonë një për një pa pritur prodhimin. A janë të nevojshme tabela të veçanta për këtë BPr?: mjete transporti, llojet e mjeteve të transportit, a duhet të ndani planin dhe faktin në porositë tuaja të dërguara te furnitorët?
Mendoni se sa shumë 'koneksione' të tepërta do t'u duhej të shkruanin programuesit tuaj, nëse për zhvillimin e programit do të përdoret modeli më poshtë.
Supozoni se kemi marrë vendimin se struktura e propozuar është tepër e ndërlikuar, për rastin tonë ndarja e planit dhe faktit në regjistrimin e porosisë është informacion i tepruar, dhe specifikimi i formuar i porosisë ri-shkruhet sipas rezultateve të pranimit të mallrave të mbërritur, rasti i rrallë i gabimit dhe ardhja e mallrave të papërshtatshëm rregullohen jashtë sistemit informacionit.
Dhe njĂ« ditĂ« shihni se e gjithĂ« salla e tavernĂ«s Ă«shtĂ« mbushur me piratĂ« tĂ« zemĂ«ruar dhe tĂ« papastĂ«r. ĂfarĂ« ndodhi?
Doli se me rritjen e biznesit tuaj është rritur edhe konsumimi. Njëherë ishte marrë një vendim menaxherial, që nëse furgoni ishte i ngarkuar mbipeshë dhe/ose mbi kapacitetin, që ndodhte jashtëzakonisht rrallë, furnizuesi prioritetonte ngarkesën në favor të pijes.
Mallrat e munguar kalonin në porosinë tjetër dhe shkonin me një fluturim të ri, prania e një sasie minimale në depo në tavernë lejonte që të kaloheshin rastet e humbjes.
Në port, konkurenti i fundit u mbyll, dhe rasti i mbingarkesës së furgonit, që ishte anashkaluar për shkak të prioritizimit të bazuar në supozimin për mjaftueshmërinë e sasive minimale dhe ngarkesën periodike të pamjaftueshme të mjeteve, u bë praktikë e zakonshme. Sistemi i krijuar do të funksionojë në përputhje me algoritmet e ndërtuara dhe do të jetë pa mundësinë për të ndjekur mosrespektimin sistematik të porosive plane. Vetëm një reputacion i prishur dhe klientë të pakënaqur do të mund të zbulojnë problemin.
Lexuesi i vëmendshëm me siguri e ka vënë re se sasia e porositur në specifikimin e porosisë (T_ORDER_SPEC) në seksionin 2 dhe në seksionin 5 mund të përputhet ose jo me kërkesat e normales së parë. Kjo varet nga nëse, përzgjedhja e asortimentit të mallrave lejon që në të njëjtën fushë të bien njësitë e ndryshme matës.
Shkelja e normales së dytë:
Me rritjen e nevojave tuaja blini edhe disa mjete transporti me përmasa të ndryshme. Në kontekstin e përmendur më sipër, krijimi i një katalogu të mjeteve të transportit u shpall i tepërt, si rezultat, të gjitha algoritmet e punës me të dhënat që shërbejnë nevojat e dërgesës dhe depozitës, perceptojnë lëvizjen e mallrave nga furnizuesi në depo si një fluturim ekskluzivisht të furgonit të 1.5 tonëve. Pra, ndërsa blini mjete të reja transporti, ju gjithashtu krijoni një katalog të mjeteve të transportit, por në përmirësim do t'ju duhet të analizoni të gjithë kodin që referohet në lëvizjen e mallrave për të kuptuar nëse çdo vend i veçantë ka referenca për karakteristikat e atij automjeti, me të cilin filloi biznesi.
Shkelja e normales së tretë:
Në një moment ju filloni të krijoni një program besnikërie, dhe shfaqet një regjistrim i klientit të rregullt. Pse, për shembull, duhet të humbisni kohë duke krijuar përfaqësime materiale që ruajnë të dhëna të agreguara mbi shitjet për klientë të veçantë për t'u përdorur në raportim dhe transmetim në sistemet analitike, nëse në fazën fillestare të programit të besnikërisë, gjithçka që intereson blerësin mund të vendoset në regjistrin e vet të klientit? Dhe me të vërtetë, në dukje nuk ka kuptim. Por çdo herë që biznesi juaj do të lidhë, për shembull, kanale të reja shitjeje, midis analistëve tuaj duhet të ketë dikë që të kujtohet se ekziston një atribut agregues i tillë.
Duke projektuar çdo proces të ri, supozoni, 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ë gjitha proceset e reja duhet të garantojnë integritetin e të dhënave në nivelin e kodit. Për një bazë të dhënash industriale me mijëra tabela, kjo duket si një detyrë e realizueshme.
Një zhvillues i përvojshëm, sigurisht, e di se si të zgjidhë të gjitha problemet e lartpërmendura, por, sipas mendimit tim, detyra e një analisti të përvojshëm është të mos i lejojë ato.
Dëshiroj të shpreh mirënjohjen time për feedback-un e vlefshëm gjatë përgatitjes së publikimit për zhvilluesin kryesor Evgeny Yarukhin.
Literatura
Connolly Thomas, Begg Caroline. Databases. Design, Implementation and Maintenance. Theory and Practice.
Burimi: habr.com
