Hallo! Myn namme is Andrey Semenov, ik bin in senior analist by Sportmaster. Yn dizze post wol ik it probleem ophelje fan denormalisaasje fan ERP-systeemdatabases. Wy sille sjen nei algemiene betingsten, en ek in spesifyk foarbyld - lit ús sizze dat it soe wêze in prachtige monopoalje taverne foar piraten en seelju. Yn hokker piraten en seelju moatte wurde tsjinne oars, omdat de ideeën fan skientme en konsumint patroanen fan dizze goede hearen binne gâns oars.
Hoe meitsje elkenien bliid? Hoe kinne jo foarkomme dat jo gek wurde mei it ûntwerpen en ûnderhâlden fan sa'n systeem? Wat te dwaan as net allinnich de gewoane piraten en seelju begjinne te kommen ta de taverne?
Alles is ûnder de snie. Mar litte wy yn oarder gean.
1. Beheinings en oannames
Al it boppesteande jildt allinnich foar relasjonele databases. De gefolgen fan denormalisaasje yn 'e foarm fan modifikaasje, wiskjen en ynfoegje anomalies, dy't goed behannele binne, ynklusyf op it ynternet, wurde net beskôge. Bûten it ramt fan dizze publikaasje binne d'r gefallen wêr't denormalisaasje in gewoan plak is, mei klassike foarbylden: paspoartrige en nûmer, datum en tiid, ensfh.
De post brûkt yntuïtive en praktysk tapassing definysjes fan normale foarmen, sûnder ferwizing nei wiskundige termen. Yn 'e foarm wêryn se kinne wurde tapast op it ûndersyk fan echte saaklike prosessen (BP) en it ûntwerp fan yndustriële software.
It wurdt beweare dat it ûntwerp fan datapakhuzen, rapportaazjeark en yntegraasje-ôfspraken (dy't tabelfoarmige foarstellings fan ynformaasje brûke) ferskilt fan it ûntwerp fan ERP-systeemdatabases yn dat gemak fan konsumpsje en it brûken fan bewuste denormalisaasje om it te berikken foarrang krije oer yntegriteit beskerming gegevens. Ik diel dizze miening, en wat hjirûnder beskreaun is, jildt allinich foar de mastergegevens en transaksjegegevensmodellen fan ERP-systemen.
In útlis fan normale foarmen wurdt jûn mei in foarbyld dat foar de measte lêzers op it deistich nivo begryplik is. As fisuele yllustraasje waard lykwols yn paragrafen 4-5 bewust in "fiktyf" taak brûkt. As jo dit net dogge en wat learboekfoarbylden nimme, bygelyks itselde folchoarder opslachmodel fan punt 2, kinne jo josels yn in situaasje fine wêr't de fokus fan 'e lêzer sil wurde ferpleatst fan' e foarstelde ûntbining fan it proses yn in model, oan persoanlike ûnderfining en belibbing fan hoe't prosessen en modellen foar it opslaan fan gegevens yn IS boud wurde moatte. Mei oare wurden, nim twa kwalifisearre IT-analisten, lit ien tsjinsten leverje oan logistiken dy't passazjiers ferfiere, de oare oan logistiken dy't masines ferfiere foar de produksje fan mikrochips. Freegje se, sûnder fan tefoaren automatisearre BP's te besprekken, om in gegevensmodel te meitsjen foar it bewarjen fan ynformaasje oer in spoarreis.
D'r is in net-nul kâns dat jo yn 'e foarstelde modellen net allinich in merkber ferskillende set fan attributen sille fine, mar ek ôfwikende sets fan entiteiten, om't elke analist sil fertrouwe op' e prosessen en taken dy't him bekend binne. En yn sa'n situaasje is it ûnmooglik om te sizzen hokker model "korrekt" is, om't der gjin evaluaasjekriterium is.
2. Normale foarmen
Earste normale foarm fan de databank fereasket atomiteit fan alle attributen.
Benammen as objekt A net-kaai-attributen a en b hat, sa dat c=f(a,b) en yn 'e tabel dy't objekt A beskriuwt de wearde fan attribút c opslaan, dan wurdt de earste normale foarm yn' e databank skend . Bygelyks, as de bestelling spesifikaasje oanjout in kwantiteit, de ienheden fan mjitting dêrfan binne ôfhinklik fan it type produkt: yn ien gefal kin it stikken wêze, yn in oar liter, yn in tredde pakket besteande út stikken (yn it model boppe Good_count_WR) , dan wurdt de atomiteit fan attributen yn 'e databank skeind. Yn dit gefal, om te sizzen wat it tabelkluster fan 'e oarderspesifikaasje moat wêze, moatte jo in rjochte beskriuwing fan it wurkproses yn' e IS hawwe, en om't de prosessen oars kinne wêze, kinne d'r in protte "korrekte" ferzjes wêze.
Twadde normale foarm fan de databank fereasket neilibjen fan de earste foarm en in eigen tabel foar eltse entiteit yn ferbân mei it wurk proses yn de IS. As der yn ien tabel ôfhinklikens c=f1(a) en d=f2(b) binne en der is gjin ôfhinklikens c=f3(b), dan wurdt de twadde normale foarm yn 'e tabel skeind. Yn it foarbyld hjirboppe is d'r gjin ôfhinklikens tusken oarder en adres yn 'e Order tabel. Feroarje de strjitte- of stêdnamme en jo sille gjin effekt hawwe op de essensjele attributen fan 'e bestelling.
Tredde normale foarm databank fereasket neilibjen fan twadde normale foarm en it ûntbrekken fan funksjonele ôfhinklikens tusken attributen fan ferskate entiteiten. Dizze regel kin as folget formulearre wurde: "alles wat berekkene wurde kin, moat berekkene wurde." Mei oare wurden, as d'r twa objekten A en B binne. Yn 'e tabel dy't de attributen fan objekt A opslacht, wurdt attribút C manifestearre, en objekt B hat attribút b, sadat c=f4(b) bestiet, dan is de tredde normale foarm wurdt skeind. Yn it foarbyld hjirûnder beweart it Quantity of Pieces-attribút (Total_count_WR) op 'e oarderrekord dúdlik dat it tredde normale foarm skeine
3. Myn oanpak foar it tapassen fan normalisaasje
1. Allinne in doel automatisearre saaklike proses kin foarsjen de analist mei kritearia foar it identifisearjen fan entiteiten en attributen by it meitsjen fan in gegevens opslach model. It meitsjen fan in proses model is in betingst foar it meitsjen fan in normaal gegevens model.
2. It berikken fan tredde normale foarm yn 'e strikte sin kin net praktysk wêze yn' e eigentlike praktyk fan it meitsjen fan ERP-systemen as guon of alle folgjende betingsten foldien wurde:
- automatisearre prosessen binne selden ûnderwurpen oan feroaring,
- deadlines foar ûndersyk en ûntwikkeling binne strak,
- easken foar gegevensintegriteit binne relatyf leech (potinsjele flaters yn yndustriële software liede net ta it ferlies fan jild of kliïnten troch de softwareklant)
- en sa.
Under de beskreaune betingsten kinne de kosten foar it identifisearjen en beskriuwen fan 'e libbenssyklus fan guon objekten en har attributen miskien net rjochtfeardige wurde út it eachpunt fan ekonomyske effisjinsje.
3. Eltse gefolgen fan denormalization fan de gegevens model yn in al makke IS kin mitigated troch in yngeande foarriedige stúdzje fan de koade en testen.
4. Denormalisaasje is in manier om arbeidskosten oer te setten fan 'e poadium fan ûndersiik fan gegevensboarnen en it ûntwerpen fan in saaklik proses nei it ûntwikkelingsstadium, fan' e útfieringsperioade oant de perioade fan systeemûntwikkeling.
5. It is oan te rieden om te stribjen nei de tredde normale foarm fan in databank as:
- De rjochting fan feroaring yn automatisearre saaklike prosessen is lestich te foarsizzen
- Der is in swakke wurkferdieling binnen it útfierings- en/of ûntwikkelingsteam
- Systemen opnommen yn 'e yntegraasjesirkwy ûntwikkelje neffens har eigen plannen
- Data-ynkonsistinsje kin resultearje yn in bedriuw ferliest klanten of jild
6. It ûntwerp fan in gegevensmodel moat allinich troch in analyst útfierd wurde yn ferbân mei de modellen fan it doelbedriuwproses en it proses yn 'e IS. As in ûntwikkelder in gegevensmodel ûntwerpt, sil hy him yn it ûnderwerpgebiet sadwaande moatte ferdjipje dat hy benammen it ferskil tusken attribútwearden begrypt - in needsaaklike betingst foar it isolearjen fan atoomattributen. Sa, nimme op ûngewoane funksjes.
4 Probleem foar yllustraasje
Litte wy sizze dat jo in lytse robotyske taverne yn 'e haven hawwe. Jo merksegment: seelju en piraten dy't yn 'e haven komme en in skoft nedich binne. Jo ferkeapje tee mei tijm oan seelju, en rom- en bonkekammen foar it kammen fan burden oan piraten. De tsjinst yn de taverne sels wurdt fersoarge troch in robothostess en in robotbarman. Mei tank oan jo hege kwaliteit en lege prizen hawwe jo jo konkurrinten ferdreaun, sadat elkenien dy't fan it skip komt nei jo taverne komt, dat is de ienige yn 'e haven.
It kompleks fan ynformaasjesystemen foar taverne bestiet út de folgjende software:
- In betiid warskôgingssysteem oer in kliïnt dy't syn kategory erkent op basis fan karakteristike funksjes
- Control systeem foar robot hostesses en robot bartenders
- Warehouse en levering behear systeem nei punt fan ferkeap
- Supplier Relationship Management System (SURP)
Procesje:
It iere warskôgingssysteem herkent minsken dy't it skip ferlitte. As in persoan skjin is, identifisearret se him as in seeman; as in persoan in burd hat, dan wurdt hy identifisearre as in piraat.
By it yngean fan 'e taverne heart de gast in groet fan 'e robothostess yn oerienstimming mei syn kategory, bygelyks: "Ho-ho-ho, leave piraat, gean nei tafel No ..."
De gast giet nei de oantsjutte tafel, dêr't de robot bartender hat al klearmakke guod foar him yn oerienstimming mei de kategory. De robot bartender stjoert ynformaasje nei it pakhússysteem dat it folgjende diel fan levering moat wurde ferhege; it pakhús IS, basearre op de oerbleaune saldo's yn opslach, genereart in oankeapfersyk yn it behearsysteem.
Wylst it iere warskôgingssysteem mooglik is ûntwikkele troch jo ynterne IT, kin it barrobotbehearprogramma makke wurde troch in eksterne oannimmer spesifyk foar jo bedriuw. En systemen foar it behearen fan pakhuzen en relaasjes mei leveransiers binne oanpaste ferpakte oplossingen fan 'e merk.
5. Foarbylden fan denormalisaasje en har ynfloed op softwareûntwikkeling
By it ûntwerpen fan in saaklik proses stelden de ynterviewde saakkundigen unanym dat oer de hiele wrâld piraten rum drinke en har burd kammen mei bonkekammen, en seelju drinke tee mei tijm en binne altyd skjinskeen.
In triemtafel fan client types ferskynt mei twa wearden: 1 - piraten, 2 - seelju, mienskiplik foar de hiele ynformaasje circuit fan it bedriuw.
It klantnotifikaasjesysteem bewarret it resultaat fan byldferwurking fuortendaliks as de identifier (ID) fan 'e erkende kliïnt en har type: seeman of piraat.
Erkend objekt ID
Client kategory
100500
Piraat
100501
Piraat
100502
Seaman
Lit ús dat nochris opmerke
1. Us seelju binne eins skeare minsken
2. Us piraten binne eins burd minsken
Hokker problemen yn dit gefal moatte wurde eliminearre sadat ús struktuer stribbet nei de tredde normale foarm:
- attribút atomity violation - Client Category
- it mingjen fan it analysearre feit en de konklúzje yn ien tabel
- fêste funksjonele relaasje tusken attributen fan ferskate entiteiten.
Yn normalisearre foarm soene wy twa tabellen krije:
- erkenning resultaat yn 'e foarm fan in set fan fêststelde funksjes,
Erkend objekt ID
Facial hier
100500
dat
100501
dat
100502
gjin
- it resultaat fan it bepalen fan it type klant as in tapassing fan 'e logika ynbêde yn' e IS om de fêststelde skaaimerken te ynterpretearjen
Erkend objekt ID
Identifikaasje ID
Client kategory
100500
100001
Piraat
100501
100002
Piraat
100502
100003
Seaman
Hoe kin in normalisearre organisaasje foar gegevensopslach de ûntwikkeling fan in IP-kompleks fasilitearje? Litte wy sizze dat jo ynienen nije kliïnten krije. Lit it wêze Japanske piraten dy't miskien gjin burd, mar se rinne mei in papegaai op it skouder, en miljeufreonlike piraten, kinne jo maklik werkenne se troch Greta syn blauwe profyl op de linker boarst.
Miljeupiraten kinne fansels gjin bonkammen brûke en hawwe in analoog nedich makke fan recycled seeplestik.
Jo moatte de programmaalgoritmen opnij bewurkje yn oerienstimming mei de nije yngongen. As de normalisearringsregels waarden folge, dan soene jo allinich de ynputen moatte oanfolje foar guon prosestûken yn guon systemen en allinich nije tûken meitsje foar dy gefallen en yn dy IS's wêr't gesichtshaar fan belang is. Mar, om't de regels net waarden folge, sille jo de heule koade moatte analysearje, troch it heule circuit, wêr't de wearden fan 'e map fan clienttype wurde brûkt en dúdlik fêststelle dat yn ien gefal it algoritme de profesjonele moat rekken hâlde mei aktiviteit fan 'e kliïnt, en yn' e oare fysike funksjes.
Yn in foarm dat siket om te normalisearjen, soene wy twa tabellen krije mei operasjonele gegevens en twa mappen:
- erkenning resultaat yn 'e foarm fan in set fan fêststelde funksjes,
Erkend objekt ID
Greta op lofter boarst
Fûgel op it skouder
Facial hier
100510
1
1
1
100511
0
0
1
100512
1
0
- it resultaat fan it bepalen fan it klanttype (lit it in oanpaste werjefte wêze wêryn beskriuwingen út mappen wurde werjûn)
Betsjut de ûntdutsen denormalisaasje dat de systemen net kinne wurde wizige om oan nije betingsten te foldwaan? Fansels net. As wy ús yntinke dat alle ynformaasjesystemen makke binne troch ien team mei nul personielsomset, de ûntwikkelingen binne goed dokumintearre en ynformaasje wurdt oerdroegen binnen it team sûnder ferlies, dan kinne de fereaske feroarings makke wurde mei ferwaarleaze bytsje muoite. Mar as wy weromgean nei de orizjinele betingsten fan it probleem, sille 1,5 toetseboerden gewoan wurde wiske foar it printsjen fan protokollen fan mienskiplike diskusjes en in oare 0,5 foar it ferwurkjen fan oankeapprosedueres.
Yn it boppesteande foarbyld binne alle trije normale foarmen skeind, litte wy besykje se apart te skeinen.
Skeining fan earste normale foarm:
Litte wy sizze dat guod wurdt levere oan jo pakhús fan leveransiers 'pakhuzen troch pick-up mei ien 1.5-ton gazelle dy't heart by jo taverne. De grutte fan jo bestellingen is sa lyts relatyf oan 'e omset fan' e leveransiers dat se altyd ien-op-ien wurde foltôge sûnder te wachtsjen op produksje. Binne jo aparte tabellen nedich mei sa'n saaklik proses: auto's, soarten auto's, is it nedich om plan en feit te skieden yn jo oarders oan ôfreizge leveransiers?
Stel jo gewoan foar hoefolle "ekstra" ferbiningen jo programmeurs sille moatte skriuwe as jo it model hjirûnder brûke om in programma te ûntwikkeljen.
Litte wy sizze dat wy besletten hawwe dat de foarstelde struktuer ûnnedich kompleks is; yn ús gefal is it skieden fan it plan en it feit yn 'e bestellingsrecord oerstallige ynformaasje, en de generearre oarderspesifikaasje wurdt opnij skreaun op basis fan' e resultaten fan akseptaasje fan it oankommen guod, seldsume mis -grading en oankomst fan guod fan ûnfoldwaande kwaliteit wurde regele bûten de IS.
En dan sjogge jo op in dei hoe't de hiele kroeghal fol is mei ferûntrêste en ûnfersoarge piraten. Wat is bard?
It docht bliken dat as jo bedriuw groeide, jo konsumpsje ek groeide. Eartiids waard der in behearsbeslút nommen dat as in gazelle yn folume en/of gewicht tefolle beladen wie, wat tige seldsum wie, de leveransier de lading foarrang jaan soe yn it foardiel fan dranken.
It net levere guod kaam yn 'e folgjende bestelling telâne en liet op in nije flecht; de oanwêzigens fan in minimum lykwicht yn it pakhús by de taverne makke it mooglik om ûntbrekkende gefallen net op te merken.
De lêste konkurrint sletten yn 'e haven, en it punctured gefal fan gazelle overload, omjûn troch prioritization basearre op de oanname fan it foldwaan fan it minimum lykwicht en periodike underloading fan it reau, waard gewoane praktyk. It oanmakke systeem sil by útstek wurkje yn oerienstimming mei de algoritmen dy't dêryn ynbêde binne en sil gjin kâns wêze om it systematyske mislearjen fan plande oarders te folgjen. Allinich in skansearre reputaasje en ûntefreden klanten sille it probleem kinne ûntdekke.
In oandachtige lêzer kin hawwe opfallen dat de bestelde kwantiteit yn 'e oarder spesifikaasje (T_ORDER_SPEC) yn seksje 2 en seksje 5 meie of net foldogge oan de eask fan earste normale foarm. It hinget allegear ôf oft, jûn it selektearre assortiment fan guod, yn essinsje ferskillende mjittingsenheden yn itselde fjild falle kinne.
Skeining fan twadde normale foarm:
As jo behoeften groeie, keapje jo in pear mear auto's fan ferskate grutte. Yn 'e boppesteande kontekst waard it oanmeitsjen fan in automap as oerstallich beskôge; as gefolch, alle gegevensferwurkingsalgoritmen dy't de behoeften fan levering en pakhús tsjinje, sjogge de beweging fan fracht fan 'e leveransier nei it pakhús as de flecht fan in eksklusyf 1,5-ton gazelle. Dat, tegearre mei de oankeap fan nije auto's, meitsje jo noch in automap oan, mar as jo it finalisearje, moatte jo alle koade analysearje dy't ferwiist nei de beweging fan lading om út te finen oft op elk spesifyk plak ferwizings wurde ymplisearre nei de skaaimerken fan it auto dêr't it bedriuw begûn.
Skeining fan 'e tredde normale foarm:
Op in stuit begjinne jo in loyaliteitsprogramma te meitsjen, in rekord fan in reguliere klant ferskynt. Wêrom, bygelyks, tiid besteegje oan it meitsjen fan materiële werjeften dy't aggregearre gegevens oer ferkeap oan in yndividuele klant opslaan foar gebrûk yn rapportaazje en oerdracht nei analytyske systemen, as oan it begjin fan in loyaliteitsprogramma alles dat de klant ynteresseart kin wurde pleatst op it rekord fan 'e klant ? En, yndie, op it earste each, der is gjin punt. Mar elke kear as jo bedriuw ferbynt, bygelyks nije ferkeapkanalen, soe d'r ien wêze moatte ûnder jo analisten dy't sil ûnthâlde dat sa'n aggregaasje-attribút bestiet.
By it ûntwerpen fan elk nij proses, Bygelyks, ferkeap op it ynternet, ferkeap fia distributeurs ferbûn oan in mienskiplik loyaliteit systeem, immen moat der rekken mei dat alle nije prosessen moatte soargje gegevens yntegriteit op de koade nivo. Foar in yndustriële databank mei tûzen tabellen liket dit in ûnmooglike taak.
In betûfte ûntwikkelder wit fansels hoe't jo alle hjirboppe neamde problemen kinne stopje, mar, nei myn miening, is de taak fan in betûfte analist net om se oan it ljocht te bringen.
Ik wol myn tankberens útdrukke oan 'e liedende ûntwikkelder Evgeniy Yarukhin foar syn weardefolle feedback by de tarieding fan' e publikaasje.
Literatuer
Connolly Thomas, Begg Caroline. Databank. Untwerp, ymplemintaasje en stipe. Teory en praktyk
Boarne: www.habr.com