Kaixo! Nire izena Andrey Semenov da, Sportmaster-en analista seniorra naiz. Post honetan ERP sistemaren datu-baseen desnormalizazioaren gaia planteatu nahi dut. Baldintza orokorrak aztertuko ditugu, baita adibide zehatz bat ere: demagun pirata eta marinelentzako monopolio-taberna zoragarria izango litzatekeela. Piratak eta marinelak modu ezberdinean zerbitzatu behar dira, jaun on horien edertasunaren ideiak eta kontsumo ereduak nabarmen desberdinak direlako.
Nola egin denak zoriontsu? Nola saihestu zoro bihurtzea horrelako sistema bat diseinatzen eta mantentzen? Zer egin ohiko pirata eta marinelak tabernara etortzen hasten ez badira?
Dena mozketa azpian dago. Baina goazen ordenan.
1. Mugak eta hipotesiak
Aurreko guztia datu-base erlazionalei bakarrik aplikatzen zaie. Ez dira kontuan hartzen aldaketa, ezabaketa eta txertatze anomaliak moduko desnormalizazioaren ondorioak, ondo estalita daudenak, Interneten barne. Argitalpen honen esparrutik kanpo daude desnormalizazioa ohikoa den kasuak, adibide klasikoekin: pasaportearen seriea eta zenbakia, data eta ordua, etab.
Postak forma arrunten definizio intuitiboak eta praktikoki aplikagarriak erabiltzen ditu, termino matematikoei erreferentziarik egin gabe. Negozio-prozesu errealen (BP) azterketan eta software industrialaren diseinuan aplika daitezkeen moduan.
Datu-biltegien, txostenak egiteko tresnen eta integrazio-akordioen diseinua (informazioaren taulen irudikapenak erabiltzen dituztenak) ERP sistemaren datu-baseen diseinutik desberdina dela esaten da, kontsumo-erraztasuna eta hori lortzeko desnormalizazio kontzientea erabiltzeak osotasuna baino lehen har dezakeela. babes datuak. Iritzi hau partekatzen dut, eta behean deskribatzen dena ERP sistemen datu nagusiei eta datu transakzionalei soilik aplikatzen zaie.
Forma arrunten azalpena irakurle gehienentzat eguneroko mailan ulergarria den adibide bat erabiliz ematen da. Hala ere, ikusizko ilustrazio gisa, 4-5 paragrafoetan, nahita "fikziozko" zeregina nahita erabili zen. Hau egiten ez baduzu eta testu-liburuen adibideren bat hartzen baduzu, adibidez, 2. puntuko ordena biltegiratze eredu bera, irakurlearen arreta prozesuaren deskonposiziotik eredu batera aldatuko den egoera batean aurki zaitezke. ISn datuak gordetzeko prozesuak eta ereduak eraiki behar diren esperientzia pertsonalari eta pertzepzioari. Beste era batera esanda, hartu bi analista informatiko kualifikatu, batak bidaiariak garraiatzen dituzten logistikoei zerbitzuak eskain diezazkieke, bestea mikrotxipak ekoizteko makinak garraiatzen dituzten logistikoei. Eskatu, aldez aurretik BP automatizatuei buruz eztabaidatu gabe, trenbide-bidai bati buruzko informazioa gordetzeko datu-eredu bat sortzeko.
Proposatzen diren ereduetan ez da probabilitate nulua aurkitzea atributu multzo nabarmen desberdina ez ezik, entitate multzo dibergenteak ere aurkitzea, analista bakoitza ezagutzen dituen prozesu eta zereginetan oinarrituko delako. Eta egoera horretan ezin da esan zein den βzuzenaβ eredua, ez dagoelako ebaluazio irizpiderik.
2. Forma arruntak
Datu-basearen lehen forma normala atributu guztien atomotasuna eskatzen du.
Bereziki, A objektuak a eta b ez-gako-atributuak baditu, hala nola, c=f(a,b) eta A objektua deskribatzen duen taulan c atributuaren balioa gordetzen baduzu, orduan lehen forma normala urratzen da datu-basean. . Adibidez, eskaeraren zehaztapenak kantitate bat adierazten badu, neurketa-unitateak produktu motaren araberakoak dira: kasu batean piezak izan daitezke, beste litro batean, piezaz osatutako hirugarren paketeetan (Goiko ereduan Good_count_WR) , orduan atributuen atomotasuna urratzen da datu-basean. Kasu honetan, eskaeraren zehaztapenaren taula multzoa zein izan behar den esateko, ISn lan-prozesuaren deskribapen bideratua behar duzu, eta prozesuak desberdinak izan daitezkeenez, bertsio "zuzen" asko egon daitezke.
Datu-basearen bigarren forma normala Lehen inprimakia eta bere taula betetzea eskatzen du ISn lan-prozesuarekin lotutako entitate bakoitzarentzat. Taula batean c=f1(a) eta d=f2(b) menpekotasunak badaude eta ez badago menpekotasunik c=f3(b), orduan bigarren forma normala urratzen da taulan. Goiko adibidean, ez dago ordenaren eta helbidearen arteko menpekotasunik Eskaera taulan. Aldatu kalearen edo hiriaren izena eta ez duzu eraginik izango ordenaren funtsezko ezaugarrietan.
Hirugarren forma arrunteko datu-basea Bigarren forma normala betetzea eta entitate ezberdinen atributuen arteko menpekotasun funtzionalak ez izatea eskatzen du. Arau hau honela formula daiteke: βkalkula daitekeen guztia kalkulatu behar daβ. Bestela esanda, bi objektu A eta B badaude. A objektuaren atributuak gordetzen dituen taulan, C atributua ageri da, eta B objektuak b atributua du, hala nola c=f4(b) existitzen den, hirugarren forma normala. urratzen da. Beheko adibidean, Pieza-kopurua atributuak (Total_count_WR) eskaera-erregistroan argi eta garbi adierazten du hirugarren forma normala urratzen duela.
3. Normalizazioa aplikatzeko nire ikuspegia
1. Helburuko negozio-prozesu automatizatu batek soilik eman diezaioke analistari entitateak eta atributuak identifikatzeko irizpideak datuak biltegiratzeko eredu bat sortzean. Prozesu-eredu bat sortzea ezinbesteko baldintza da datu-eredu normal bat sortzeko.
2. Hirugarren forma arrunta zentzu hertsian lortzea agian ez da praktikoa ERP sistemak sortzeko benetako praktikan, baldin eta baldintza hauetako batzuk edo guztiak betetzen badira:
- prozesu automatizatuak oso gutxitan aldatzen dira,
- ikerketa eta garapenerako epeak estuak dira,
- Datuen osotasunerako eskakizunak nahiko baxuak dira (software industrialaren balizko akatsek ez dute software bezeroak dirua edo bezeroak galtzea eragiten).
- eta abar.
Deskribatutako baldintzetan, baliteke objektu batzuen bizi-zikloa eta haien atributuak identifikatu eta deskribatzearen kostuak eraginkortasun ekonomikoaren ikuspuntutik justifikatzea.
3. Dagoeneko sortutako IS batean datu-ereduaren desnormalizazioaren ondorioak arin daitezke kodearen eta probaren aurretiazko azterketa sakon baten bidez.
4. Desnormalizazioa datu-iturriak ikertzeko eta negozio-prozesu bat diseinatzeko fasetik lan-kostuak transferitzeko modu bat da, ezarpen-alditik sistemaren garapen-aldira.
5. Komeni da datu-base baten hirugarren forma arrunta lortzeko ahalegina egitea, baldin:
- Negozio prozesu automatizatuetan aldaketaren norabidea zaila da aurreikustea
- Inplementazio- eta/edo garapen-taldearen barruan lan banaketa ahula dago
- Integrazio-zirkuituan sartutako sistemak beren planen arabera garatzen dira
- Datuen koherentzia ezak enpresa batek bezeroak edo dirua galtzea eragin dezake
6. Datu-eredu baten diseinua analista batek egin behar du helburuko negozio-prozesuaren eta IS-eko prozesuaren ereduekin soilik lotuta. Garatzaile bat datu-eredu bat diseinatzen ari bada, gai-eremuan murgildu beharko du, bereziki, atributuen balioen arteko aldea ulertzen duen neurrian, atributu atomikoak isolatzeko beharrezko baldintza. Horrela, ezohiko funtzioak hartuz.
4 Ilustraziorako problema
Demagun portuan robotiko taberna txiki bat duzula. Zure merkatu-segmentua: portura sartu eta atseden bat behar duten marinelak eta piratak. Tea ezkaiarekin saltzen diezu marinelei, eta rona eta hezur-orraziak piratei bizarra orrazteko. Tabernan bertan zerbitzua azafata robot batek eta tabernari robot batek ematen dute. Zure kalitate handiari eta prezio baxuei esker, lehiakideak kanporatu dituzu, ontzitik ateratzen diren guztiak zure tabernara etor daitezen, hau da, portuan dagoen bakarra.
Tabernaren informazio sistemen konplexuak honako software hauek ditu:
- Bezero bati buruzko abisu goiztiarreko sistema bat, bere kategoria ezaugarri ezaugarrietan oinarrituta ezagutzen duena
- Robot azafata eta robot tabernarien kontrol-sistema
- Biltegia eta salmenta puntura bidalketak kudeatzeko sistema
- Hornitzaileen Harremanak Kudeatzeko Sistema (SURP)
Prozesu:
Alerta goiztiarreko sistemak ontzitik irteten diren pertsonak ezagutzen ditu. Pertsona bat garbi-bizarra bada, marinel gisa identifikatzen du; pertsona bat bizarra duela aurkitzen bada, pirata gisa identifikatuko da.
Tabernan sartuta, gonbidatuak bere kategoriaren araberako azafata robotaren agurra entzuten du, adibidez: βHo-ho-ho, pirata maitea, zoaz mahaira No...β
Gonbidatua zehaztutako mahaira doa, non robot tabernariak dagoeneko prestatu dituen ondasunak kategoriaren arabera. Robot tabernariak biltegiko sistemari informazioa transmititzen dio hurrengo entrega-zatia handitu behar dela; biltegiko IS, biltegiratze geratzen diren saldoetan oinarrituta, erosketa-eskaera bat sortzen du kudeaketa-sisteman.
Abisu goiztiarreko sistema zure barneko informatikak garatu izana izan daitekeen arren, baliteke barra-robotak kudeatzeko programa zure negoziorako bereziki kanpoko kontratista batek sortu izana. Eta biltegiak kudeatzeko eta hornitzaileekiko harremanak kudeatzeko sistemak merkatuko ontziratutako soluzio pertsonalizatuak dira.
5. Desnormalizazioaren adibideak eta softwarearen garapenean duen eragina
Negozio-prozesu bat diseinatzerakoan, elkarrizketatutako gaietako adituek aho batez adierazi zuten mundu osoan piratek rona edaten dutela eta bizarra hezur-orraziz orrazten dutela, eta marinelek tea ezkaiarekin edaten dutela eta beti garbi-garbi daudela.
Bezero moten direktorio bat agertzen da bi baliorekin: 1 - piratak, 2 - marinelak, ohikoa konpainiaren informazio zirkuitu osorako.
Bezeroaren jakinarazpen-sistemak berehala gordetzen du irudien tratamenduaren emaitza aitortutako bezeroaren identifikatzaile (ID) eta bere mota: marinel edo pirata gisa.
Objektu ID aitortua
Bezero kategoria
100500
pirata
100501
pirata
100502
Marinela
Kontuan izan dezagun berriro ere
1. Gure marinelak benetan bizarrak dira
2. Gure piratak benetan bizardunak dira
Kasu honetan zein arazo ezabatu behar diren gure egiturak hirugarren forma normala lortzeko ahalegina egin dezan:
- atributuaren atomismo-urraketa - Bezero-kategoria
- aztertutako gertakaria eta ondorioa taula batean nahastuz
- entitate ezberdinen atributuen arteko erlazio funtzional finkoa.
Forma normalizatuan, bi taula lortuko genituzke:
- aitorpenaren emaitza ezarritako ezaugarri multzo baten moduan,
Objektu ID aitortua
Aurpegiko ilea
100500
Bai
100501
Bai
100502
No
- bezero-mota zehaztearen emaitza, ISan txertatutako logikaren aplikazio gisa, ezarritako ezaugarriak interpretatzeko
Objektu ID aitortua
Identifikazio ID
Bezero kategoria
100500
100001
pirata
100501
100002
pirata
100502
100003
Marinela
Nola erraztu dezake datuak biltegiratzeko erakunde normalizatu batek IP konplexu baten garapena? Demagun bat-batean bezero berriak lortzen dituzula. Izan bedi pirata japoniarrak bizarra ez dutenak, baina loro bat sorbaldan ibiltzen direnak, eta pirata ekologistak, erraz antzeman ditzakezu Gretaren profil urdinaren ezkerreko bularrean.
Ingurumen piratek, jakina, ezin dituzte hezur-orraziak erabili eta itsasoko plastiko birziklatuz egindako analogo bat behar dute.
Programaren algoritmoak berritu behar dituzu sarrera berrien arabera. Normalizazio-arauak jarraituz gero, sistema batzuetan prozesu-adar batzuen sarrerak osatu eta adar berriak sortu besterik ez zenituzke kasu horietan eta aurpegiko ilea garrantzitsua den IS horietan. Baina, arauak bete ez zirenez, kode osoa aztertu beharko duzu, zirkuitu osoan zehar, non bezero motaren direktorioaren balioak erabiltzen diren eta argi eta garbi ezarriko duzu kasu batean algoritmoak profesionala kontuan hartu behar duela. bezeroaren jarduera, eta gainerako ezaugarri fisikoetan.
Inprimaki batean bilatzen du normalizatzeko, bi taula lortuko genituzke datu operatiboekin eta bi direktoriorekin:
- aitorpenaren emaitza ezarritako ezaugarri multzo baten moduan,
Objektu ID aitortua
Greta ezkerreko bularrean
Txoria sorbaldan
Aurpegiko ilea
100510
1
1
1
100511
0
0
1
100512
1
0
- bezero mota zehaztearen emaitza (izan dadila direktorioetako deskribapenak bistaratzen diren ikuspegi pertsonalizatua)
Antzemandako desnormalizazioak esan nahi al du sistemak ezin direla aldatu baldintza berriak betetzeko? Noski ezetz. Imajinatzen badugu informazio-sistema guztiak langile-boluketarik gabeko talde batek sortu zituela, garapenak ondo dokumentatuta daudela eta informazioa taldean galerarik gabe transferitzen dela, orduan beharrezkoak diren aldaketak egin daitezke esfortzu gutxirekin. Baina arazoaren jatorrizko baldintzetara itzultzen bagara, 1,5 teklatu ezabatu egingo dira eztabaida bateratuen protokoloak inprimatzeko eta beste 0,5 kontratazio prozedurak prozesatzeko.
Goiko adibidean, hiru forma normalak urratzen dira, saia gaitezen bereizita urratzen.
Lehenengo forma arruntaren urratzea:
Demagun salgaiak zure biltegira hornitzaileen biltegietatik jasotzen direla zure tabernari dagokion 1.5 tonako gazela bat erabiliz. Zure eskaeren tamaina hain da txikia hornitzaileen negozio-bolumenarekin alderatuta, ezen beti banan-banan betetzen direla ekoizpenaren zain egon gabe. Taula bereiziak behar dituzu horrelako negozio prozesu batekin: ibilgailuak, ibilgailu motak, beharrezkoa al da plan eta egitate bereiztea utzitako hornitzaileei egindako eskaeretan?
Imajinatu zenbat konexio "gehigarri" idatzi beharko dituzten zure programatzaileek beheko eredua programa bat garatzeko erabiltzen baduzu.
Demagun proposatutako egitura alferrikako konplexua dela erabaki dugula; gure kasuan, plana eta eskaera-erregistroan gertakaria bereiztea informazio erredundantea da, eta sortutako eskaeraren zehaztapena berridatzi egiten da, iritsitako ondasunen onarpenaren emaitzetan oinarrituta. -Kalitate desegokiko ondasunen kalifikazioa eta etorrera IStik kanpo finkatzen dira.
Eta orduan ikusten duzu nola taberna-areto osoa pirata suminduta eta zaindugabez betetzen den. Zer gertatu da?
Gertatzen da zure negozioa hazi ahala, zure kontsumoa ere hazi zela. Garai batean, kudeaketa erabakia hartzen zen: gazela bat bolumenez edo/eta pisuz gainkargatzen bazen, oso arraroa zena, hornitzaileak kargari lehentasuna emango zion edarien alde.
Entregatu gabeko salgaiak hurrengo eskaeran amaitzen ziren eta hegaldi berri batean irten ziren; tabernako biltegian saldo minimo bat egoteak posible egin zuen falta ziren kasuak ez antzematea.
Azken lehiakidea portuan itxi zen, eta gazela gainkargaren kasu zulatua, ibilgailuaren gutxieneko saldoaren eta aldizkako kargaren askitasunaren suposapenean oinarritutako lehentasunak saihestuta, ohikoa bihurtu zen. Sortutako sistemak ezin hobeto funtzionatuko du bertan txertatutako algoritmoen arabera eta aurreikusitako eskaerak betetzeko huts sistematikoa jarraitzeko aukerarik gabe geratuko da. Kaltetutako ospea eta pozik ez dauden bezeroek bakarrik detektatu ahal izango dute arazoa.
Irakurle adi batek ohartu izana 2. eta 5. ataleko eskaeraren zehaztapenean (T_ORDER_SPEC) agindutako kantitateak lehen forma arruntaren eskakizuna bete dezakeela edo ez. Aukeratutako ondasun-sorta kontuan hartuta, funtsean, neurri-unitate desberdinak eremu berean sartu daitezkeen ala ez araberakoa da.
Bigarren forma normalaren urratzea:
Zure beharrak hazten diren heinean, tamaina ezberdinetako pare bat ibilgailu gehiago erosten dituzu. Aurreko testuinguruan, ibilgailuen direktorioa sortzea erredundantetzat jo zen; ondorioz, entrega eta biltegirako beharrei erantzuten dieten datuak prozesatzeko algoritmo guztiek hornitzailetik biltegira kargaren joan-etorria 1,5 tonako hegaldi gisa hautematen dute. gazela. Beraz, ibilgailu berriak erostearekin batera, ibilgailuen direktorio bat sortzen jarraitzen duzu, baina hura amaitzean, zamaren mugimenduari erreferentzia egiten dion kode guztia aztertu beharko duzu leku zehatz bakoitzean ezaugarriekin erreferentziak inplikatuta dauden jakiteko. negozioa abiatu zen ibilgailuaren beraren.
Hirugarren forma normalaren urraketa:
Uneren batean leialtasun programa bat sortzen hasten zara, ohiko bezero baten erregistroa agertzen da. Zergatik, adibidez, denbora eman bezero indibidual bati salmentei buruzko datu agregatuak gordetzen dituzten ikuspegi materialak sortzen, txostenak egiteko eta sistema analitikoetara transferitzeko, leialtasun-programa baten hasieran bezeroari interesatzen zaion guztia bezeroaren erregistroan jar badaiteke? ? Eta, egia esan, lehen begiratuan, ez du ezertarako balio. Baina zure negozioak, adibidez, salmenta-kanal berriak konektatzen dituen bakoitzean, zure analisten artean batuketa-atributu hori existitzen dela gogoratuko duen norbait egon beharko litzateke.
Prozesu berri bakoitza diseinatzerakoan, adibidez, Internet bidezko salmentak, leialtasun sistema komun batera konektatutako banatzaileen bidezko salmentak, norbaitek kontuan izan behar du prozesu berri guztiek datuen osotasuna ziurtatu behar dutela kode mailan. Mila taula dituen datu-base industrial baterako, ezinezko lana dirudi.
Esperientziadun garatzaile batek, noski, badaki arestian aipatutako arazo guztiak geldiarazten, baina, nire ustez, esperientziadun analista baten zeregina ez da horiek argitaraztea.
Nire esker ona adierazi nahi nioke Evgeniy Yarukhin garatzaile nagusiari argitalpena prestatzerakoan emandako iritzi baliotsuagatik.
Literatura
Connolly Thomas, Begg Caroline. Datu-basea. Diseinua, ezarpena eta laguntza. Teoria eta praktika
Iturria: www.habr.com