Hallo! My naam is Andrey Semenov, ek is 'n senior ontleder by Sportmaster. In hierdie pos wil ek die kwessie van denormalisering van ERP-stelseldatabasisse opper. Ons sal kyk na algemene voorwaardes, sowel as 'n spesifieke voorbeeld - kom ons sê dit sal 'n wonderlike monopolie-taverne vir seerowers en matrose wees. Waarin seerowers en matrose anders bedien moet word, want die idees van skoonheid en verbruikerspatrone van hierdie goeie here verskil aansienlik.
Hoe om almal gelukkig te maak? Hoe kan jy vermy om mal te word om so 'n stelsel te ontwerp en in stand te hou? Wat om te doen as nie net die gewone seerowers en matrose na die taverne begin kom nie?
Alles is onder die knie. Maar kom ons gaan in volgorde.
1. Beperkings en aannames
Al die bogenoemde is slegs van toepassing op relasionele databasisse. Die gevolge van denormalisering in die vorm van wysigings-, skrap- en invoeg-anomalieë, wat goed gedek word, insluitend op die internet, word nie oorweeg nie. Buite die bestek van hierdie publikasie is daar gevalle waar denormalisering 'n algemene plek is, met klassieke voorbeelde: paspoortreeks en -nommer, datum en tyd, ens.
Die pos gebruik intuïtiewe en prakties toepaslike definisies van normale vorme, sonder verwysing na wiskundige terme. In die vorm waarin dit toegepas kan word op die ondersoek van werklike besigheidsprosesse (BP) en die ontwerp van industriële sagteware.
Daar word aangevoer dat die ontwerp van datapakhuise, verslagdoeningsinstrumente en integrasie-ooreenkomste (wat tabelvormige voorstellings van inligting gebruik) verskil van die ontwerp van ERP-stelseldatabasisse deurdat gemak van verbruik en die gebruik van bewuste denormalisering om dit te bereik voorrang bo integriteit kan geniet. beskermingsdata. Ek deel hierdie mening, en wat hieronder beskryf word, is uitsluitlik van toepassing op die meesterdata en transaksionele datamodelle van ERP-stelsels.
'n Verduideliking van normale vorme word gegee deur 'n voorbeeld te gebruik wat vir die meeste lesers op die alledaagse vlak verstaanbaar is. As 'n visuele illustrasie, in paragrawe 4-5, is 'n doelbewuste "fiktiewe" taak egter doelbewus gebruik. As jy dit nie doen nie en een of ander handboekvoorbeeld neem, byvoorbeeld dieselfde ordebergingsmodel vanaf punt 2, kan jy jouself in 'n situasie bevind waar die leser se fokus verskuif sal word van die voorgestelde ontbinding van die proses na 'n model, tot persoonlike ervaring en persepsie van hoe prosesse en modelle vir die stoor van data in IS gebou moet word. Met ander woorde, neem twee gekwalifiseerde IT-ontleders, laat een dienste lewer aan logistieke wat passasiers vervoer, die ander aan logistieke wat masjiene vir die vervaardiging van mikroskyfies vervoer. Vra hulle, sonder om vooraf outomatiese BP's te bespreek, om 'n datamodel te skep vir die stoor van inligting oor 'n spoorwegreis.
Daar is 'n nie-nul waarskynlikheid dat jy in die voorgestelde modelle nie net 'n merkbaar verskillende stel eienskappe sal vind nie, maar ook uiteenlopende stelle entiteite, want elke ontleder sal staatmaak op die prosesse en take wat aan hom bekend is. En in so 'n situasie is dit onmoontlik om te sê watter model "korrek" is, want daar is geen evalueringskriterium nie.
2. Normale vorme
Eerste normale vorm van die databasis vereis atomiteit van alle eienskappe.
In die besonder, as objek A nie-sleutelkenmerke a en b het, sodanig dat c=f(a,b) en in die tabel wat objek A beskryf stoor jy die waarde van kenmerk c, dan word die eerste normale vorm in die databasis geskend . Byvoorbeeld, as die bestelspesifikasie 'n hoeveelheid aandui, waarvan die maateenhede afhang van die tipe produk: in een geval kan dit stukke wees, in 'n ander liter, in 'n derde pakkette wat uit stukke bestaan (in die model hierbo Good_count_WR) , dan word die atomiteit van eienskappe in die databasis geskend. In hierdie geval, om te sê wat die tabelgroep van die bestellingspesifikasie moet wees, benodig jy 'n doelgerigte beskrywing van die werkproses in die IS, en aangesien die prosesse verskillend kan wees, kan daar baie "korrekte" weergawes wees.
Tweede normale vorm van die databasis vereis voldoening aan die eerste vorm en sy eie tabel vir elke entiteit wat verband hou met die werkproses in die IS. As daar in een tabel afhanklikhede c=f1(a) en d=f2(b) is en daar is geen afhanklikheid c=f3(b), dan word die tweede normaalvorm in die tabel geskend. In die voorbeeld hierbo is daar geen afhanklikheid tussen bestelling en adres in die Order-tabel nie. Verander die straat- of stadnaam en jy sal geen effek hê op die noodsaaklike eienskappe van die bestelling nie.
Derde normale vorm databasis vereis voldoening aan tweede normale vorm en die afwesigheid van funksionele afhanklikhede tussen eienskappe van verskillende entiteite. Hierdie reël kan soos volg geformuleer word: "alles wat bereken kan word, moet bereken word." Met ander woorde, as daar twee voorwerpe A en B is. In die tabel wat die eienskappe van voorwerp A stoor, word kenmerk C gemanifesteer, en voorwerp B het kenmerk b, sodanig dat c=f4(b) bestaan, dan is die derde normaalvorm geskend word. In die voorbeeld hieronder beweer die Quantity of Pieces-kenmerk (Total_count_WR) op die bestelrekord duidelik dat dit derde normale vorm oortree
3. My benadering tot die toepassing van normalisering
1. Slegs 'n teiken outomatiese besigheidsproses kan die ontleder voorsien van kriteria vir die identifisering van entiteite en eienskappe wanneer 'n databergingsmodel geskep word. Die skep van 'n prosesmodel is 'n voorvereiste vir die skep van 'n normale datamodel.
2. Die bereiking van derde normale vorm in die streng sin is dalk nie prakties in die werklike praktyk van die skep van ERP-stelsels as daar aan sommige of al die volgende voorwaardes voldoen word nie:
- outomatiese prosesse is selde onderhewig aan verandering,
- sperdatums vir navorsing en ontwikkeling is kort,
- vereistes vir data-integriteit is relatief laag (potensiële foute in industriële sagteware lei nie tot die verlies van geld of kliënte deur die sagteware-kliënt nie)
- ens.
Onder die beskryfde toestande is die koste van die identifisering en beskrywing van die lewensiklus van sommige voorwerpe en hul eienskappe moontlik nie geregverdig vanuit die oogpunt van ekonomiese doeltreffendheid nie.
3. Enige gevolge van denormalisering van die datamodel in 'n reeds geskepte IS kan versag word deur 'n deeglike voorlopige studie van die kode en toetsing.
4. Denormalisering is 'n manier om arbeidskoste oor te dra vanaf die stadium van navorsing oor databronne en die ontwerp van 'n besigheidsproses na die ontwikkelingstadium, vanaf die implementeringsperiode tot die tydperk van stelselontwikkeling.
5. Dit is raadsaam om na die derde normale vorm van 'n databasis te streef indien:
- Die rigting van verandering in geoutomatiseerde besigheidsprosesse is moeilik om te voorspel
- Daar is 'n swak arbeidsverdeling binne die implementering- en/of ontwikkelingspan
- Stelsels wat by die integrasiekring ingesluit is, ontwikkel volgens hul eie planne
- Data inkonsekwentheid kan daartoe lei dat 'n maatskappy kliënte of geld verloor
6. Die ontwerp van 'n datamodel moet slegs deur 'n ontleder uitgevoer word in verband met die modelle van die teikenbesigheidsproses en die proses in die IS. As 'n ontwikkelaar 'n datamodel ontwerp, sal hy hom in so 'n mate in die vakgebied moet verdiep dat hy veral die verskil tussen eienskapwaardes verstaan - 'n noodsaaklike voorwaarde om atoomkenmerke te isoleer. Dus, neem ongewone funksies aan.
4 Probleem ter illustrasie
Kom ons sê jy het 'n klein robottaverne in die hawe. Jou marksegment: matrose en seerowers wat in die hawe kom en 'n blaaskans nodig het. Jy verkoop tee met tiemie aan matrose, en rum- en beenkamme om baarde aan seerowers te kam. Die diens in die taverne self word verskaf deur 'n robotgasvrou en 'n robotkroegman. Danksy jou hoë gehalte en lae pryse het jy jou mededingers verdryf, sodat almal wat van die skip afkom na jou taverne kom, wat die enigste een in die hawe is.
Die taverne-inligtingstelselkompleks bestaan uit die volgende sagteware:
- 'n Vroeë waarskuwingstelsel oor 'n kliënt wat sy kategorie herken op grond van kenmerkende kenmerke
- Beheerstelsel vir robotgasvroue en robotkroegmanne
- Pakhuis en afleweringsbestuurstelsel tot verkoopspunt
- Verskaffersverhoudingbestuurstelsel (SURP)
proses:
Die vroeë waarskuwingstelsel herken mense wat die skip verlaat. As 'n persoon gladgeskeer is, identifiseer sy hom as 'n matroos; as daar gevind word dat 'n persoon 'n baard het, word hy as 'n seerower geïdentifiseer.
Die gas wat die taverne binnegaan, hoor 'n groet van die robotgasvrou in ooreenstemming met sy kategorie, byvoorbeeld: "Ho-ho-ho, liewe seerower, gaan tafel toe Nee ..."
Die gas gaan na die gespesifiseerde tafel, waar die robotkroegman reeds goedere vir hom voorberei het in ooreenstemming met die kategorie. Die robotkroegman stuur inligting na die pakhuisstelsel dat die volgende gedeelte van aflewering verhoog moet word; die pakhuis IS, gebaseer op die oorblywende saldo's in berging, genereer 'n aankoopversoek in die bestuurstelsel.
Terwyl die vroeë waarskuwingstelsel moontlik deur u interne IT ontwikkel is, is die kroegrobotbestuursprogram moontlik deur 'n eksterne kontrakteur spesifiek vir u besigheid geskep. En stelsels vir die bestuur van pakhuise en verhoudings met verskaffers is pasgemaakte verpakte oplossings uit die mark.
5. Voorbeelde van denormalisering en die impak daarvan op sagteware-ontwikkeling
Met die ontwerp van 'n besigheidsproses, het die onderwerpkundiges wat ondervra is, eenparig verklaar dat seerowers oor die hele wêreld rum drink en hul baarde met beenkamme kam, en matrose drink tee met tiemie en is altyd skoongeskeer.
'n Gids van tipes kliënte verskyn met twee waardes: 1 - seerowers, 2 - matrose, algemeen vir die hele inligtingkring van die maatskappy.
Die kliëntkennisgewingstelsel stoor onmiddellik die resultaat van beeldverwerking as die identifiseerder (ID) van die erkende kliënt en sy tipe: matroos of seerower.
Herkende voorwerp-ID
Kliënt kategorie
100500
seerower
100501
seerower
100502
Matroos
Laat ons weereens daarop let
1. Ons matrose is eintlik geskeerde mense
2. Ons seerowers is eintlik bebaarde mense
Watter probleme in hierdie geval moet uitgeskakel word sodat ons struktuur streef na die derde normale vorm:
- kenmerk atomiteitskending - Kliëntkategorie
- die ontleedde feit en die gevolgtrekking in een tabel te meng
- vaste funksionele verhouding tussen eienskappe van verskillende entiteite.
In genormaliseerde vorm sal ons twee tabelle kry:
- herkenningsresultaat in die vorm van 'n stel gevestigde kenmerke,
Herkende voorwerp-ID
Gesigshare
100500
Ja
100501
Ja
100502
Geen
- die resultaat van die bepaling van die tipe kliënt as 'n toepassing van die logika wat in die IS ingebed is om die gevestigde kenmerke te interpreteer
Herkende voorwerp-ID
Identifikasie ID
Kliënt kategorie
100500
100001
seerower
100501
100002
seerower
100502
100003
Matroos
Hoe kan 'n genormaliseerde databergingsorganisasie die ontwikkeling van 'n IP-kompleks fasiliteer? Kom ons sê jy kry skielik nuwe kliënte. Laat dit Japannese seerowers wees wat dalk nie 'n baard het nie, maar hulle loop met 'n papegaai op hul skouer, en omgewingsbewuste seerowers, jy herken hulle maklik aan Greta se blou profiel op die linkerbors.
Omgewingsseerowers kan natuurlik nie beenkamme gebruik nie en eis 'n analoog gemaak van herwonne seeplastiek.
Jy moet die programalgoritmes herwerk in ooreenstemming met die nuwe insette. As die normaliseringsreëls gevolg is, sou jy net die insette vir sommige prosesvertakkings in sommige stelsels hoef aan te vul en nuwe takke te skep net vir daardie gevalle en in daardie IS'e waar gesighare saak maak. Maar aangesien die reëls nie gevolg is nie, sal u die hele kode deur die hele stroombaan moet ontleed waar die waardes van die kliënttipe gids gebruik word en duidelik vasstel dat die algoritme in een geval die professionele in ag moet neem aktiwiteit van die kliënt, en in die ander fisiese kenmerke.
In 'n vorm wat soek om te normaliseer, sal ons twee tabelle met operasionele data en twee gidse kry:
- herkenningsresultaat in die vorm van 'n stel gevestigde kenmerke,
Herkende voorwerp-ID
Greta op linkerbors
Voël op die skouer
Gesigshare
100510
1
1
1
100511
0
0
1
100512
1
0
- die resultaat van die bepaling van die kliënttipe (laat dit 'n pasgemaakte aansig wees waarin beskrywings van gidse vertoon word)
Beteken die bespeurde denormalisering dat die stelsels nie aangepas kan word om aan nuwe voorwaardes te voldoen nie? Natuurlik nie. As ons ons voorstel dat al die inligtingstelsels deur een span geskep is met geen personeelomset, die ontwikkelings goed gedokumenteer is en inligting sonder verlies binne die span oorgedra word, dan kan die vereiste veranderinge met weglaatbaar min moeite aangebring word. Maar as ons terugkeer na die oorspronklike toestande van die probleem, sal 1,5 sleutelborde uitgevee word net vir die druk van protokolle van gesamentlike besprekings en nog 0,5 vir die verwerking van verkrygingsprosedures.
In die voorbeeld hierbo word al drie normale vorms geskend, kom ons probeer om dit afsonderlik te skend.
Oortreding van eerste normale vorm:
Kom ons sê goedere word by jou pakhuis afgelewer vanaf verskaffers se pakhuise deur af te haal met een 1.5-ton-gazelle wat aan jou taverne behoort. Die grootte van jou bestellings is so klein relatief tot die verskaffers se omset dat dit altyd een-tot-een afgehandel word sonder om vir produksie te wag. Met so 'n besigheidsproses, het jy aparte tabelle nodig: voertuie, tipes voertuie, is dit nodig om plan en feit te skei in jou bestellings aan verlate verskaffers?
Stel jou net voor hoeveel "ekstra" verbindings jou programmeerders sal moet skryf as jy die model hieronder gebruik om 'n program te ontwikkel.
Kom ons sê ons het besluit dat die voorgestelde struktuur onnodig kompleks is; in ons geval is die skeiding van die plan en die feit in die bestellingsrekord oortollige inligting, en die gegenereerde bestellingspesifikasie word herskryf op grond van die resultate van aanvaarding van die goedere wat aangekom het, seldsame mis -gradering en aankoms van goedere van onvoldoende kwaliteit word buite die IS vereffen.
En dan sien jy eendag hoe die hele tavernesaal gevul is met verontwaardigde en onversorgde seerowers. Wat het gebeur?
Dit blyk dat soos jou besigheid gegroei het, jou verbruik ook toegeneem het. Eens op 'n tyd is 'n bestuursbesluit geneem dat indien 'n gasel in volume en/of gewig oorlaai word, wat uiters skaars was, die verskaffer die vrag ten gunste van drankies sou prioritiseer.
Die onafgelewerde goedere het in die volgende bestelling beland en op 'n nuwe vlug vertrek; die teenwoordigheid van 'n minimum balans in die pakhuis by die taverne het dit moontlik gemaak om nie vermiste gevalle raak te sien nie.
Die laaste mededinger het by die hawe gesluit, en die deurboor geval van gaselleoorlading, omseil deur prioritisering gebaseer op die aanname van die voldoende minimum balans en periodieke onderlading van die voertuig, het algemene praktyk geword. Die geskepte stelsel sal ideaal werk in ooreenstemming met die algoritmes wat daarin ingebed is en sal ontneem word van enige geleentheid om die sistematiese versuim om beplande bestellings uit te voer, op te spoor. Slegs 'n beskadigde reputasie en ontevrede kliënte sal die probleem kan opspoor.
'n Oplettende leser het dalk opgemerk dat die bestelde hoeveelheid in die bestelspesifikasie (T_ORDER_SPEC) in afdeling 2 en afdeling 5 dalk aan die vereiste van eerste normale vorm voldoen, al dan nie. Dit hang alles af of, gegewe die geselekteerde verskeidenheid goedere, wesenlik verskillende maateenhede in dieselfde veld kan val.
Oortreding van tweede normale vorm:
Soos jou behoeftes groei, koop jy nog 'n paar voertuie van verskillende groottes. In bogenoemde konteks is die skepping van 'n voertuiggids as oorbodig beskou; gevolglik beskou alle dataverwerkingsalgoritmes wat die behoeftes van aflewering en pakhuis dien die beweging van vrag van die verskaffer na die pakhuis as die vlug van 'n uitsluitlik 1,5 ton gasel. Dus, saam met die aankoop van nuwe voertuie, skep jy steeds 'n voertuiggids, maar wanneer jy dit finaliseer, sal jy al die kode wat na die beweging van vrag verwys moet ontleed om uit te vind of in elke spesifieke plek verwysings na die kenmerke geïmpliseer word. van die einste voertuig waaruit besigheid begin het.
Oortreding van die derde normale vorm:
Op 'n stadium begin jy 'n lojaliteitsprogram skep, 'n rekord van 'n gereelde kliënt verskyn. Hoekom, byvoorbeeld, tyd spandeer om wesenlike sienings te skep wat saamgestelde data oor verkope aan 'n individuele kliënt stoor vir gebruik in verslagdoening en oordrag na analitiese stelsels, as aan die begin van 'n lojaliteitsprogram alles wat die kliënt interesseer op die kliënt se rekord geplaas kan word ? En inderdaad, met die eerste oogopslag is daar geen sin nie. Maar elke keer as jou besigheid byvoorbeeld nuwe verkoopskanale koppel, behoort daar iemand onder jou ontleders te wees wat sal onthou dat so 'n samevoegingskenmerk bestaan.
Wanneer elke nuwe proses ontwerp word, byvoorbeeld verkope op die internet, verkope deur verspreiders wat aan 'n gemeenskaplike lojaliteitstelsel gekoppel is, moet iemand in gedagte hou dat alle nuwe prosesse data-integriteit op kodevlak moet verseker. Vir 'n industriële databasis met 'n duisend tabelle, lyk dit na 'n onmoontlike taak.
'n Ervare ontwikkelaar weet natuurlik hoe om al die probleme wat hierbo genoem is uit te skakel, maar na my mening is die taak van 'n ervare ontleder nie om dit aan die lig te bring nie.
Ek wil graag my dank uitspreek teenoor die voorste ontwikkelaar Evgeniy Yarukhin vir sy waardevolle terugvoer tydens die voorbereiding van die publikasie.
Letterkunde
Connolly Thomas, Begg Caroline. Databasis. Ontwerp, implementering en ondersteuning. Teorie en praktyk
Bron: will.com