Përshëndetje! Emri im është Andrey Semenov, unë jam një analist i lartë në Sportmaster. Në këtë postim dua të ngre çështjen e denormalizimit të bazave të të dhënave të sistemit ERP. Ne do të shikojmë kushtet e përgjithshme, si dhe një shembull specifik - le të themi se do të ishte një tavernë e mrekullueshme monopole për piratët dhe marinarët. Në të cilën piratët dhe marinarët duhet të shërbehen ndryshe, sepse idetë e bukurisë dhe modelet e konsumatorit të këtyre zotërinjve të mirë janë dukshëm të ndryshme.
Si t'i bëni të gjithë të lumtur? Si mund të shmangni çmendurinë duke projektuar dhe mirëmbajtur një sistem të tillë? Çfarë duhet të bëni nëse jo vetëm piratët dhe marinarët e zakonshëm fillojnë të vijnë në tavernë?
Gjithçka është nën prerje. Por le të shkojmë me radhë.
1. Kufizimet dhe supozimet
Të gjitha sa më sipër zbatohen vetëm për bazat e të dhënave relacionale. Pasojat e denormalizimit në formën e modifikimit, fshirjes dhe anomalive të futjes, të cilat janë të mbuluara mirë, përfshirë edhe në internet, nuk merren parasysh. Jashtë objektit të këtij botimi ka raste ku denormalizimi është një vend i zakonshëm, me shembuj klasikë: seria dhe numri i pasaportave, data dhe ora, etj.
Postimi përdor përkufizime intuitive dhe praktikisht të zbatueshme të formave normale, pa iu referuar termave matematikore. Në formën në të cilën ato mund të aplikohen për ekzaminimin e proceseve reale të biznesit (BP) dhe dizajnimin e softuerit industrial.
Argumentohet se dizajni i depove të të dhënave, mjeteve të raportimit dhe marrëveshjeve të integrimit (të cilat përdorin paraqitje tabelare të informacionit) ndryshon nga dizajni i bazave të të dhënave të sistemit ERP në atë lehtësinë e konsumit dhe përdorimin e denormalizimit të vetëdijshëm për ta arritur atë mund të ketë përparësi mbi integritetin. të dhënat e mbrojtjes. Unë ndaj këtë mendim dhe ajo që përshkruhet më poshtë vlen vetëm për modelet kryesore të të dhënave dhe të dhënave transaksionale të sistemeve ERP.
Një shpjegim i formave normale jepet duke përdorur një shembull që është i kuptueshëm në nivelin e përditshëm për shumicën e lexuesve. Megjithatë, si një ilustrim vizual, në paragrafët 4-5, qëllimisht u përdor një detyrë "fiktive". Nëse nuk e bëni këtë dhe merrni një shembull teksti shkollor, për shembull, të njëjtin model të ruajtjes së porosisë nga pika 2, mund të gjendeni në një situatë ku fokusi i lexuesit do të zhvendoset nga zbërthimi i propozuar i procesit në një model. në përvojën personale dhe perceptimin se si duhet të ndërtohen proceset dhe modelet për ruajtjen e të dhënave në IS. Me fjalë të tjera, merrni dy analistë të kualifikuar IT, njëri le t'u ofrojë shërbime logjistëve që transportojnë pasagjerë, tjetri logjistëve që transportojnë makineri për prodhimin e mikroçipëve. Kërkojuni atyre, pa diskutuar paraprakisht PB-të e automatizuara, të krijojnë një model të dhënash për ruajtjen e informacionit rreth një udhëtimi hekurudhor.
Ekziston një probabilitet jo zero që në modelet e propozuara të gjeni jo vetëm një grup dukshëm të ndryshëm atributesh, por edhe grupe entitetesh divergjente, sepse secili analist do të mbështetet në proceset dhe detyrat e njohura për të. Dhe në një situatë të tillë është e pamundur të thuhet se cili model është "i saktë", sepse nuk ka asnjë kriter vlerësimi.
2. Format normale
Forma e parë normale e bazës së të dhënave kërkon atomicitet të të gjitha atributeve.
Në veçanti, nëse objekti A ka atribute jo kyçe a dhe b, të tilla që c=f(a,b) dhe në tabelën që përshkruan objektin A ruani vlerën e atributit c, atëherë forma e parë normale shkelet në bazën e të dhënave. . Për shembull, nëse specifikimi i porosisë tregon një sasi, njësitë matëse të së cilës varen nga lloji i produktit: në një rast mund të jenë copa, në një tjetër litra, në një të tretë pako të përbërë nga copa (në modelin e mësipërm Good_count_WR) , atëherë atomiciteti i atributeve është shkelur në bazën e të dhënave. Në këtë rast, për të thënë se cili duhet të jetë grupi i tabelës së specifikimit të porosisë, ju duhet një përshkrim i synuar i procesit të punës në IS, dhe duke qenë se proceset mund të jenë të ndryshme, mund të ketë shumë versione "korrekte".
Forma e dytë normale e bazës së të dhënave kërkon respektimin e formularit të parë dhe tabelës së tij për çdo subjekt që lidhet me procesin e punës në SI. Nëse në njërën tabelë ka varësi c=f1(a) dhe d=f2(b) dhe nuk ka varësi c=f3(b), atëherë në tabelë shkelet forma e dytë normale. Në shembullin e mësipërm, nuk ka asnjë varësi midis rendit dhe adresës në tabelën Rendit. Ndryshoni emrin e rrugës ose qytetit dhe nuk do të keni asnjë efekt në atributet thelbësore të porosisë.
Baza e të dhënave e formës së tretë normale kërkon pajtueshmëri me formën e dytë normale dhe mungesën e varësive funksionale ndërmjet atributeve të entiteteve të ndryshme. Ky rregull mund të formulohet si më poshtë: "gjithçka që mund të llogaritet duhet të llogaritet". Me fjalë të tjera, nëse ka dy objekte A dhe B. Në tabelën që ruan atributet e objektit A, atributi C manifestohet dhe objekti B ka atributin b, i tillë që ekziston c=f4(b), atëherë forma e tretë normale është shkelur. Në shembullin më poshtë, atributi Sasia e pjesëve (Total_count_WR) në regjistrimin e porosisë pretendon qartë se shkel formën e tretë normale
3. Qasja ime ndaj aplikimit të normalizimit
1. Vetëm një proces i automatizuar biznesi i synuar mund t'i sigurojë analistit kritere për identifikimin e entiteteve dhe atributeve kur krijon një model të ruajtjes së të dhënave. Krijimi i një modeli procesi është një parakusht për krijimin e një modeli normal të të dhënave.
2. Arritja e formës së tretë normale në kuptimin e ngushtë mund të mos jetë praktike në praktikën aktuale të krijimit të sistemeve ERP nëse plotësohen disa ose të gjitha kushtet e mëposhtme:
- proceset e automatizuara rrallëherë janë subjekt i ndryshimit,
- afatet për kërkimin dhe zhvillimin janë të ngushta,
- kërkesat për integritetin e të dhënave janë relativisht të ulëta (gabimet e mundshme në softuerin industrial nuk çojnë në humbjen e parave ose klientëve nga klienti i softuerit)
- etj
Në kushtet e përshkruara, kostot e identifikimit dhe përshkrimit të ciklit jetësor të disa objekteve dhe atributeve të tyre mund të mos justifikohen nga pikëpamja e efikasitetit ekonomik.
3. Çdo pasojë e denormalizimit të modelit të të dhënave në një SI të krijuar tashmë mund të zbutet nga një studim paraprak i plotë i kodit dhe testimi.
4. Denormalizimi është një mënyrë për të transferuar kostot e punës nga faza e kërkimit të burimeve të të dhënave dhe e projektimit të një procesi biznesi në fazën e zhvillimit, nga periudha e zbatimit në periudhën e zhvillimit të sistemit.
5. Këshillohet që të përpiqeni për formën e tretë normale të bazës së të dhënave nëse:
- Drejtimi i ndryshimit në proceset e automatizuara të biznesit është i vështirë të parashikohet
- Ekziston një ndarje e dobët e punës brenda ekipit të zbatimit dhe/ose zhvillimit
- Sistemet e përfshira në qarkun e integrimit zhvillohen sipas planeve të tyre
- Mospërputhja e të dhënave mund të rezultojë në humbjen e klientëve ose parave nga një kompani
6. Hartimi i një modeli të dhënash duhet të kryhet nga një analist vetëm në lidhje me modelet e procesit të biznesit të synuar dhe procesin në SI. Nëse një zhvillues po harton një model të dhënash, ai do të duhet të zhytet në fushën e temës në atë masë që, në veçanti, të kuptojë ndryshimin midis vlerave të atributeve - një kusht i domosdoshëm për izolimin e atributeve atomike. Kështu, duke marrë funksione të pazakonta.
4 Problem për ilustrim
Le të themi se keni një tavernë të vogël robotike në port. Segmenti juaj i tregut: marinarët dhe piratët që vijnë në port dhe kanë nevojë për pushim. Ju shes çaj me trumzë marinarëve, dhe rum dhe krehër kockash për krehjen e mjekrës piratëve. Shërbimi në vetë tavernë ofrohet nga një zonjë robot dhe një banakier robot. Falë cilësisë tuaj të lartë dhe çmimeve të ulëta, ju keni dëbuar konkurrentët tuaj, në mënyrë që të gjithë që zbresin nga anija të vijnë në tavernën tuaj, e cila është e vetmja në port.
Kompleksi i sistemeve të informacionit të tavernës përbëhet nga programet e mëposhtme:
- Një sistem paralajmërimi i hershëm për një klient që njeh kategorinë e tij bazuar në karakteristikat karakteristike
- Sistemi i kontrollit për mikpritësit robotë dhe banakierët robotë
- Sistemi i menaxhimit të magazinës dhe dërgesës në pikën e shitjes
- Sistemi i Menaxhimit të Marrëdhënieve me Furnizuesit (SURP)
procesi:
Sistemi i paralajmërimit të hershëm njeh njerëzit që largohen nga anija. Nëse një person është i rruar, ajo e identifikon atë si një marinar; nëse një person zbulohet se ka mjekër, atëherë ai identifikohet si pirat.
Duke hyrë në tavernë, i ftuari dëgjon një përshëndetje nga zonja robot në përputhje me kategorinë e tij, për shembull: "Ho-ho-ho, i dashur pirat, shko në tryezën nr..."
I ftuari shkon në tryezën e specifikuar, ku banakieri robot ka përgatitur tashmë mallra për të në përputhje me kategorinë. Roboti barist transmeton informacion në sistemin e magazinës se pjesa tjetër e dorëzimit duhet të rritet; IS i magazinës, bazuar në bilancet e mbetura në ruajtje, gjeneron një kërkesë blerjeje në sistemin e menaxhimit.
Ndërsa sistemi i paralajmërimit të hershëm mund të jetë zhvilluar nga IT-ja juaj e brendshme, programi i menaxhimit të robotit të barit mund të jetë krijuar nga një kontraktues i jashtëm posaçërisht për biznesin tuaj. Dhe sistemet për menaxhimin e depove dhe marrëdhëniet me furnitorët janë zgjidhje të paketuara të personalizuara nga tregu.
5. Shembuj të denormalizimit dhe ndikimi i tij në zhvillimin e softuerit
Gjatë projektimit të një procesi biznesi, ekspertët e subjektit të intervistuar deklaruan njëzëri se piratët në të gjithë botën pinë rum dhe krehin mjekrën e tyre me krehër kockash, dhe marinarët pinë çaj me trumzë dhe janë gjithmonë të rruar.
Shfaqet një direktori e llojeve të klientëve me dy vlera: 1 - piratë, 2 - marinarë, të përbashkëta për të gjithë qarkun e informacionit të kompanisë.
Sistemi i njoftimit të klientit ruan menjëherë rezultatin e përpunimit të imazhit si identifikues (ID) të klientit të njohur dhe llojin e tij: marinar ose pirat.
ID e objektit të njohur
Kategoria e klientit
100500
pirat
100501
pirat
100502
Detar
Le ta vërejmë edhe një herë këtë
1. Detarët tanë janë në fakt njerëz të rruar
2. Piratët tanë janë në fakt njerëz me mjekër
Cilat probleme në këtë rast duhet të eliminohen në mënyrë që struktura jonë të përpiqet për formën e tretë normale:
- shkelje e atributit të atomicitetit - Kategoria e klientit
- duke përzier faktin e analizuar dhe përfundimin në një tabelë
- marrëdhënie fikse funksionale ndërmjet atributeve të entiteteve të ndryshme.
Në formë të normalizuar, do të merrnim dy tabela:
- rezultati i njohjes në formën e një grupi karakteristikash të vendosura,
ID e objektit të njohur
Mjekërr
100500
Po
100501
Po
100502
Jo
- rezultati i përcaktimit të llojit të klientit si një aplikim i logjikës së ngulitur në IS për të interpretuar karakteristikat e vendosura
ID e objektit të njohur
ID e identifikimit
Kategoria e klientit
100500
100001
pirat
100501
100002
pirat
100502
100003
Detar
Si mundet një organizatë e normalizuar e ruajtjes së të dhënave të lehtësojë zhvillimin e një kompleksi IP? Le të themi se papritmas merrni klientë të rinj. Le të jenë piratët japonezë që mund të mos kenë mjekër, por ata ecin me një papagall në supe, dhe piratët ambientalistë, mund t'i dalloni lehtësisht nga profili blu i Gretës në gjoksin e majtë.
Piratët mjedisorë, natyrisht, nuk mund të përdorin krehër kockash dhe kërkojnë një analog të bërë nga plastika e ricikluar e detit.
Ju duhet të ripunoni algoritmet e programit në përputhje me hyrjet e reja. Nëse do të ndiqen rregullat e normalizimit, atëherë do t'ju duhet vetëm të plotësoni inputet për disa degë procesi në disa sisteme dhe të krijoni degë të reja vetëm për ato raste dhe në ato IS ku kanë rëndësi qimet e fytyrës. Por, meqenëse rregullat nuk u respektuan, do të duhet të analizoni të gjithë kodin, në të gjithë qarkun, ku përdoren vlerat e drejtorisë së tipit të klientit dhe të përcaktoni qartë se në një rast algoritmi duhet të marrë parasysh profesionistin aktivitetin e klientit, dhe në karakteristikat e tjera fizike.
Në një formë që kërkon për t'u normalizuar, do të merrnim dy tabela me të dhëna operacionale dhe dy drejtori:
- rezultati i njohjes në formën e një grupi karakteristikash të vendosura,
ID e objektit të njohur
Greta në gjoksin e majtë
Zog mbi supe
Mjekërr
100510
1
1
1
100511
0
0
1
100512
1
0
- rezultati i përcaktimit të llojit të klientit (le të jetë një pamje e personalizuar në të cilën shfaqen përshkrimet nga drejtoritë)
A do të thotë denormalizimi i zbuluar se sistemet nuk mund të modifikohen për të përmbushur kushte të reja? Sigurisht që jo. Nëse imagjinojmë që të gjitha sistemet e informacionit janë krijuar nga një ekip me qarkullim zero stafi, zhvillimet janë të dokumentuara mirë dhe informacioni transferohet brenda ekipit pa humbje, atëherë ndryshimet e kërkuara mund të bëhen me përpjekje të papërfillshme. Por nëse kthehemi në kushtet fillestare të problemit, 1,5 tastiera do të fshihen vetëm për printimin e protokolleve të diskutimeve të përbashkëta dhe 0,5 të tjera për përpunimin e procedurave të prokurimit.
Në shembullin e mësipërm, të tre format normale janë shkelur, le të përpiqemi t'i shkelim ato veç e veç.
Shkelja e formës së parë normale:
Le të themi se mallrat dërgohen në magazinë tuaj nga magazinat e furnitorëve duke marrë duke përdorur një gazelë 1.5 ton që i përket tavernës tuaj. Madhësia e porosive tuaja është aq e vogël në krahasim me xhiron e furnitorëve, saqë ato përfundohen gjithmonë një për një pa pritur për prodhimin. A keni nevojë për tabela të veçanta me një proces të tillë biznesi: automjetet, llojet e automjeteve, a është e nevojshme të ndani planin dhe faktin në porositë tuaja për furnitorët e larguar?
Vetëm imagjinoni sa lidhje "shtesë" do të duhet të shkruajnë programuesit tuaj nëse përdorni modelin e mëposhtëm për të zhvilluar një program.
Le të themi se vendosëm që struktura e propozuar është komplekse e panevojshme; në rastin tonë, ndarja e planit dhe faktit në regjistrin e porosisë është informacion i tepërt, dhe specifikimi i porosisë së gjeneruar rishkruhet në bazë të rezultateve të pranimit të mallrave të mbërritur, gabim i rrallë - klasifikimi dhe ardhja e mallrave me cilësi joadekuate vendosen jashtë IS.
Dhe pastaj një ditë ju shihni se si e gjithë salla e tavernës është e mbushur me piratë të indinjuar dhe të çrregullt. Cfare ndodhi?
Rezulton se me rritjen e biznesit tuaj, u rrit edhe konsumi juaj. Njëherë e një kohë, u mor një vendim i menaxhimit që nëse një gazelë mbingarkohej në vëllim dhe/ose peshë, gjë që ishte jashtëzakonisht e rrallë, furnizuesi do t'i jepte përparësi ngarkesës në favor të pijeve.
Mallrat e padërguara përfunduan në porosinë tjetër dhe u larguan me një fluturim të ri; prania e një bilanc minimal në magazinë në tavernë bëri të mundur që të mos viheshin re rastet e munguara.
Konkurrenti i fundit u mbyll në port dhe rasti i shpuar i mbingarkesës së gazelës, i anashkaluar nga prioritizimi bazuar në supozimin e mjaftueshmërisë së bilancit minimal dhe nënngarkimit periodik të mjetit, u bë praktikë e zakonshme. Sistemi i krijuar në mënyrë ideale do të funksionojë në përputhje me algoritmet e ngulitura në të dhe do të privohet nga çdo mundësi për të gjurmuar dështimin sistematik për të përmbushur porositë e planifikuara. Vetëm një reputacion i dëmtuar dhe klientët e pakënaqur do të jenë në gjendje ta zbulojnë problemin.
Një lexues i vëmendshëm mund të ketë vënë re se sasia e porositur në specifikimin e porosisë (T_ORDER_SPEC) në seksionin 2 dhe seksionin 5 mund ose nuk mund të përmbushë kërkesat e formës së parë normale. E gjitha varet nga fakti nëse, duke pasur parasysh asortimentin e zgjedhur të mallrave, në thelb njësi të ndryshme matëse mund të bien në të njëjtën fushë.
Shkelja e formës së dytë normale:
Ndërsa nevojat tuaja rriten, ju blini disa automjete të tjera të madhësive të ndryshme. Në kontekstin e mësipërm, krijimi i një direktorie automjetesh u konsiderua i tepërt; si rezultat, të gjitha algoritmet e përpunimit të të dhënave që i shërbejnë nevojave të dorëzimit dhe magazinës e perceptojnë lëvizjen e ngarkesave nga furnizuesi në magazinë si fluturim ekskluzivisht 1,5 ton. gazelë. Pra, së bashku me blerjen e automjeteve të reja, ju ende krijoni një drejtori automjetesh, por kur ta finalizoni atë, do t'ju duhet të analizoni të gjithë kodin që i referohet lëvizjes së ngarkesës për të zbuluar nëse në secilin vend specifik referenca nënkuptohet për karakteristikat. të vetë automjetit nga i cili filloi biznesi.
Shkelja e formës së tretë normale:
Në një moment filloni të krijoni një program besnikërie, shfaqet një rekord i një klienti të rregullt. Pse, për shembull, të shpenzoni kohë duke krijuar pamje materiale që ruajnë të dhëna të grumbulluara mbi shitjet tek një klient individual për përdorim në raportim dhe transferim në sistemet analitike, nëse në fillim të një programi besnikërie gjithçka që i intereson klientit mund të vendoset në rekordin e klientit ? Dhe, me të vërtetë, në shikim të parë, nuk ka asnjë pikë. Por sa herë që biznesi juaj lidh, për shembull, kanale të reja shitjesh, duhet të ketë dikë mes analistëve tuaj që do të kujtojë se ekziston një atribut i tillë grumbullimi.
Kur dizajnoni çdo proces të ri, për shembull, shitjet në internet, shitjet përmes shpërndarësve të lidhur me një sistem të përbashkët besnikërie, dikush duhet të ketë parasysh se të gjitha proceset e reja duhet të sigurojnë integritetin e të dhënave në nivelin e kodit. Për një bazë të dhënash industriale me një mijë tabela, kjo duket si një detyrë e pamundur.
Një zhvillues me përvojë, natyrisht, di të eliminojë të gjitha problemet e përmendura më lart, por, për mendimin tim, detyra e një analisti me përvojë nuk është t'i nxjerrë ato në dritë.
Dëshiroj të shpreh mirënjohjen time për zhvilluesin kryesor Evgeniy Yarukhin për komentet e tij të vlefshme gjatë përgatitjes së botimit.
Letërsi
Connolly Thomas, Begg Caroline. Baza e të dhënave. Projektimi, zbatimi dhe mbështetja. Teoria dhe praktika
Burimi: www.habr.com