Hej! Jeg hedder Andrey Semenov, jeg er senioranalytiker hos Sportmaster. I dette indlæg vil jeg tage spørgsmålet om denormalisering af databaser i ERP-systemer op. Vi vil se på de generelle betingelser samt et konkret eksempel - lad os sige, det bliver en fantastisk monopoltaverna for pirater og sømænd. I hvilken pirater og sømænd skal betjenes på forskellige måder, da deres opfattelser af det smukke og forbrugermønstre er meget forskellige.
Hvordan kan man sikre, at alle er tilfredse? Hvordan undgår man at miste forstanden, mens man designer og vedligeholder et sådant system? Hvad skal man gøre, hvis der begynder at komme andre end de sædvanlige pirater og sømænd til tavernen?
Alt er under katagori. Men lad os tage det i rækkefølge.
1. Begrænsninger og forudsætninger
Alt det, der er nævnt, gælder kun for relationelle databaser. De godt beskrevne, herunder på internettet, konsekvenser af denormalisering i form af modifikations-, sletnings- og indsætningsanomalier overvejes ikke. Uden for publikationen forbliver situationer, hvor denormalisering er almindelig praksis, med klassiske eksempler som serienummer og udløbsdato, dato og tid osv.
Indlægget bruger intuitive og praktisk anvendelige definitioner af normale former uden henvisninger til matematiske termer. I den form, som de kan anvendes til undersøgelse af reelle forretningsprocesser (BP) og design af industriel software.
Der er en opfattelse af, at design af datalagre, værktøjer til rapportering og integrationsaftaler (hvor tabelpræsentation af information anvendes) adskiller sig fra design af ERP-databaser ved, at brugervenlighed og anvendelse af bevidst denormalisering kan have højere prioritet end at beskytte dataintegriteten. Jeg deler denne opfattelse, og det, der er beskrevet nedenfor, gælder udelukkende for modeller af masterdata og transaktionsdata i ERP-systemer.
Forklaringen af normalformer er givet med et eksempel, der er let forståeligt for de fleste læsere. Som en illustrativ demonstration er der imidlertid bevidst brugt en helt "opfundet" opgave i punkterne 4-5. Hvis dette ikke gøres, og man tager et klassisk eksempel, som for eksempel den samme model til opbevaring af en ordre fra punkt 2, kan man befinde sig i en situation, hvor læserens opmærksomhed bliver afledt fra den foreslåede nedbrydning af processen i modellen til deres personlige erfaring og opfattelse af, hvordan processer og datalagringsmodeller i informationssystemer skal konstrueres. Med andre ord, tag to kvalificerede IT-analytikere, lad den ene yde service til logistikere, der transporterer passagerer, mens den anden gør det samme for logistikere, der transporterer maskiner til produktion af mikrochips. Bed dem, uden at diskutere de automatiserbare forretningsprocesser på forhånd, om at udarbejde en datamodel til opbevaring af information om en jernbanerejse.
Der er en ikke-nul sandsynlighed for, at du i de foreslåede modeller vil finde ikke kun markant forskellige sæt af attributter, men også uoverensstemmende sæt enheder, fordi hver analytiker vil basere sig på de processer og opgaver, de er vant til. Og at sige, hvilken model der er "korrekt" i en sådan situation, er umuligt, fordi der ikke findes noget evalueringskriterium.
2. Normalformer
Den første normale form for databasen kræver atomaritet for alle attributter.
Specifikt, hvis objekt A har ikke-nøgleattributter a og b, sådan at c=f(a,b) og i tabellen, der beskriver objekt A, opbevarer du værdien af attributten c, så er den første normale form overtrådt i databasen. For eksempel, hvis en ordrespecifikation angiver mængden, hvis måleenheder afhænger af produkttypen: i ét tilfælde kan det være stykker, i et andet liter, i et tredje pakker, der består af stykker (i den ovenstående model Good_count_WR), så er atomariteten af attributter overtrådt i databasen. I dette tilfælde, for at sige, hvordan tabellerne i ordrespecifikationen skal være, er det nødvendigt med en målspecifik beskrivelse af arbejdsgangen i informationssystemet, og da processerne kan være forskellige, kan der være mange "korrekte" versioner.
Den anden normale form for databasen kræver overholdelse af første normalform og en egen tabel for hver entitet relateret til arbejdet i informationssystemet. Hvis der i én tabel findes afhængigheder med=f1(a) og d=f2(b), og der ikke findes en afhængighed med=f3(b), så er den anden normalform brudt i tabellen. I eksemplet ovenfor findes der ikke nogen afhængighed mellem ordren og adressen i tabellen "Bestilling". Ændrer du gadenavn eller by, vil du ikke få nogen indflydelse på væsentlige attributter for bestillingen.
Tredje normalform for databaser kræver overholdelse af anden normalform og fravær af funktionelle afhængigheder mellem attributter af forskellige enheder. Denne regel kan formuleres sådan: "alt, hvad der kan beregnes, skal beregnes". Med andre ord, hvis der findes to objekter A og B. I tabellen, der opbevarer attributterne for objekt A, vises attribut C, som for objekt B har en attribut b, sådan at der findes c=f4(b), så er den tredje normalform brudt. I nedenstående eksempel ønsker attribut "Antal stk" (Total_count_WR) i ordren åbenlyst at krænke den tredje normalform.
3. Min tilgang til anvendelse af normalisering
1. Kun en målrettet automatiserbar forretningsproces kan give analytikeren kriterier for identifikation af enheder og attributter ved oprettelse af en datamodel. Oprettelse af procesmodellen er en forudsætning for at skabe en normal datamodel.
2. At opnå tredje normalform i strengt forstand kan være urealistisk i praksis ved oprettelse af ERP-systemer under udførelsen af en del eller alle følgende betingelser:
- automatiserede processer sjældent er udsat for ændringer,
- tidsrammerne for forskning og udvikling er stramme,
- kravene til dataintegritet er relativt lave (potentielle fejl i industriel software fører ikke til tab af penge eller kunder for softwarekunden)
- osv.
Under de beskrevne betingelser kan udgifterne til identifikation og beskrivelse af livscyklussen for nogle objekter og deres attributter ikke være økonomisk bæredygtige.
3. Enhver konsekvens af denormalisering af datamodellen i allerede eksisterende informationssystemer kan begrænses ved grundig forundersøgelse af koden og testning.
4. Denormalisering er en metode til at flytte arbejdstimer fra dataindsamlings- og forretningsprocesdesignfasen til udviklingsfasen, fra implementeringsperioden til systemudviklingsperioden.
5. Det er hensigtsmæssigt at stræbe efter den tredje normale form i databasen, hvis:
- Retningen for ændringen af de automatiserede forretningsprocesser er svær at forudsige.
- Inden for implementerings- og/eller udviklingsteamet er der en svag opdeling af arbejdet.
- Systemerne i integrationsrammen udvikler sig efter deres egne planer.
- Uoverensstemmelser i data kan føre til tab af kunder eller penge for virksomheden.
6. Data modellen bør kun designes af analytikeren i forbindelse med modellerne for den målrettede forretningsproces og processen i informationssystemet. Hvis udvikleren beskæftiger sig med design af datamodellen, skal han dykke ned i emnet i en sådan grad, at han specifikt forstår forskellen mellem attributværdierne – en nødvendighed for at udpege atomære attributter. Dermed tager han ansvar for ikke-tilknyttede funktioner.
4 Opgave til illustration
Lad os antage, at du har en lille robotiseret taverna i havnen. Dit markedsegment: sømænd og pirater, der kommer ind i havnen og har brug for hvile. Til sømændene sælger du te med timian, og til piraterne rom og knogler til at rede skægget med. Servicen i tavernaen udføres af en robot-hostess og en robot-bartender. Takket være høj kvalitet og lave priser har du udkonkurreret alle konkurrenter, så alle, der kommer fra skibet, besøger din taverna, som er den eneste i havnen.
Samlingen af informationssystemer i tavernaen består af følgende software:
- System til tidlig kundevarsling, der genkender kundens kategori ud fra karakteristiske træk.
- System til styring af robot-hostess og robot-bartendere.
- System til lagerstyring og levering til salgsstedet.
- System til styring af forholdet til leverandørerne (SRL).
Processen:
Systemet til tidlig varsling genkender personer, der går af skibet. Hvis en person er glatbarberet, identificerer den ham som sømand, hvis en person har skæg, identificeres han som pirat.
Når gæsten træder ind i tavernaen, hører han en hilsen fra robot-hostessen i henhold til sin kategori, for eksempel: "Ho-ho-ho, Ærede pirat, gå til bord nr...."
Gæsten går hen til den angivne bar, hvor robot-bartenderen allerede har forberedt varer til ham i henhold til kategorien. Robot-bartenderen sender information til lagersystemet om, at den næste levering skal øges, lagerets it-system danner en indkøbsanmodning baseret på lagerbeholdningen.
Lad os sige, at advarselssystemet blev udviklet af jeres interne it, programmet til styring af barrobotter blev skabt af en ekstern leverandør specifikt til jeres virksomhed. Og systemerne til håndtering af lager og leverandørrelationer er tilpassede standardløsninger fra markedet.
5. Eksempler på denormalisering og dens indflydelse på softwareudvikling
Ved design af forretningsprocessen sagde de adspurgte eksperter inden for emnet samstemmende, at pirater i hele verden drikker rom og børster deres skæg med knogleskaber, mens sømænd drikker te med timian og altid er glatbarberede.
En kundetypevejledning fremkommer med to værdier: 1- pirater, 2 — sømænd, fælles for hele virksomhedens informationskontur.
Kundens advarselssystem gemmer straks resultatet af billedbehandlingen som et id (ID) for den genkendte kunde og hans type: sømand eller pirat.
ID for den genkendte enhed
Kundekategori
100500
Pirat
100501
Pirat
100502
Sømand
Lad os endnu en gang bemærke, at
1. Våre sømænd er faktisk glatte mennesker
2. Våre pirater er faktisk skæggede mennesker
Hvilke problemer skal løses i dette tilfælde, for at vores struktur stræber mod tredjedel normalform:
- brud på attributternes atomaritet — Kundekategori
- sammenblanding af den analyserede fakta og konklusion i én tabel
- fastlagt funktionel afhængighed mellem attributter af forskellige enheder.
I normaliseret form ville vi have fået to tabeller:
- genkendelsesresultatet i form af et sæt etablerede funktioner,
ID for den genkendte enhed
Ansigtshår
100500
Ja
100501
Ja
100502
Nej
- resultatet af identifikation af kundetypen som anvendelse af den indlagte logik i it-systemet til fortolkning af de etablerede funktioner
ID for den genkendte enhed
ID for identificering
Kundekategori
100500
100001
Pirat
100501
100002
Pirat
100502
100003
Sømand
Hvordan kan en normaliseret dataopbevaringsorganisation lette udviklingen af informationssystemkomplekser? Antag, at du pludselig får nye kunder. Lad os sige, at det er japanske pirater, som måske ikke har skæg, men som går rundt med en papegøje på skulderen, og miljøpirater; du genkender dem let på Greta-profilen, der er tatoveret på deres venstre bryst.
Miljøpirater kan naturligvis ikke bruge knoglekamme og kræver et alternativ lavet af genanvendt havplastik.
Du skal justere programalgoritmerne i henhold til de nye forudsætninger. Hvis normaliseringsreglerne var blevet overholdt, ville du kun skulle supplere nogle systemer med input for visse procesgrene og skabe nye grene kun for de tilfælde og i de informationssystemer, hvor ansigtshår har betydning. Men da reglerne ikke blev overholdt, må du analysere al koden i hele omfanget, hvor værdier fra kundetyperne anvendes og entydigt fastslå, at i ét tilfælde skal algoritmen tage hensyn til kundens professionelle aktivitet, mens den i et andet tilfælde skal overveje fysiske egenskaber.
I den form, der stræber mod normalisering, ville vi have fået to tabeller med operationelle data og to registre:
- genkendelsesresultatet i form af et sæt etablerede funktioner,
ID for den genkendte enhed
Greta på venstre bryst
Fuglen på skulderen
Ansigtshår
100510
1
1
1
100511
0
0
1
100512
1
0
- resultatet af bestemmelsen af kundetypen (lad os sige, at dette er en brugerdefineret visning, der viser beskrivelserne fra registrene)
Betyder den opdagede denormalisering, at systemerne ikke kan tilpasses de nye forhold? Selvfølgelig ikke. Hvis vi antager, at alle informationssystemer blev skabt af et team med nul medarbejderomsætning, at udviklingen er godt dokumenteret, og at informationen overføres uden tab i teamet, kunne de nødvendige ændringer foretages med forsvindende små ressourcer. Men hvis vi vender tilbage til de oprindelige opgaveforhold, ville det alene at udskrive protokoller for fælles drøftelser kræve 1,5 tastaturer og yderligere 0,5 til at håndtere indkøbsprocedurerne.
I det ovenstående eksempel er alle tre normale former blevet overtrådt, lad os forsøge at overtræde dem hver for sig.
Overtrædelse af den første normale form:
Antag, at varer til dit lager bliver leveret fra leverandørernes lagre ved at hente dem med en 1,5 tons varevogn, som tilhører dit værtshus. Størrelsen af dine ordrer er så lille i forhold til leverandørernes omsætning, at de altid bliver udført helt præcist uden ventetid på produktion. Er der behov for separate tabeller for transportmidler, typer af transportmidler, og er det nødvendigt at adskille plan og faktiske ordrer sendt til leverandørerne i denne forretningsmodel?
Forestil dig blot, hvor mange "overflødige" forbindelser dine programmører vil være nødt til at skrive, hvis programmet skal udvikles ved hjælp af modellen herunder.
Lad os antage, at vi har besluttet, at den foreslåede struktur er for komplex til vores tilfælde. At adskille plan og faktum i ordre registrering er overflødig information, og den udformede ordre-specifikation bliver overskrevet baseret på resultaterne af modtagelsen af det ankomne gods; sjældne ombytningsfejl og ankomst af varer af utilfredsstillende kvalitet bliver håndteret uden for informationssystemet.
Og en dag ser du, hvordan hele værelset i værtshuset er fyldt med ophidsede og uskårede pirater. Hvad er der sket?
Det viste sig, at i takt med at din virksomhed voksede, voksede forbruget også. Engang blev der truffet en ledelsesmæssig beslutning om, at hvis varevognen blev overbelastet i henhold til volumen og/eller vægt — hvilket sjældent skete — prioriterede leverandøren lastningen til fordel for drikkevarer.
Underleverede varer gik med i den næste ordre og blev sendt afsted med det nye flyvning, mens tilstedeværelsen af en minimumsbeholdning på lageret ved værtshuset gjorde, at man ikke bemærkede de forsvundne tilfælde.
I havnen lukkede den sidste konkurrent, og det forsvundne tilfælde af overbelastning af varevognen, der blev overset ved prioriteringen baseret på antagelsen om tilstrækkelig minimumsbeholdning og periodisk underbelastning af transportmidlet, blev almindelig praksis. Det skabte system vil fungere perfekt i overensstemmelse med de indbyggede algoritmer og vil være helt ude af stand til at spore systematisk undladelse af planlagte ordrer. Kun en ødelagt rygte og utilfredse kunder vil kunne opdage problemet.
Den opmærksomme læser har sikkert bemærket, at det bestilte antal i bestillingsspecifikationen (T_ORDER_SPEC) i sektion 2 og i sektion 5 kan opfylde og måske ikke opfylde kravet til den første normale form. Det afhænger alt sammen af, om forskellige måleenheder kan falde ind i det samme felt for det valgte sortiment af varer.
Overtrædelse af den anden normale form:
I takt med at dine behov vokser, anskaffer du endnu et par transportmidler i forskellige størrelser. I den ovenstående kontekst blev det anset for overflødigt at oprette en transportmidelsregister, hvilket resulterede i, at alle algoritmer, der arbejder med data og betjener behovene til levering og lager, opfatter transporten af gods fra leverandøren til lageret, som en rute udelukkende for en 1,5 tons Gazelle. Så sammen med købet af nye transportmidler opretter du stadig et transportmidelsregister, men under implementeringen skal du analysere al den kode, der henviser til transport af gods, for at finde ud af, om der på hvert specifikt sted henvises til egenskaberne for det køretøj, som virksomheden startede med.
Overtrædelse af den tredje normale form:
På et tidspunkt begynder du at oprette et loyalitetsprogram, og der opstår en optegnelse for en fast kunde. Hvorfor skulle man for eksempel bruge tid på at oprette materielle repræsentationer, der gemmer aggregerede data om salget til en enkelt kunde til brug i rapportering og overførsel til analytiske systemer, hvis alt, hvad kunden interesserer sig for på starttrinnet for loyalitetsprogrammet, kan placeres i selve kundens optegnelse? Og der er faktisk ikke nogen mening i det ved første øjekast. Men hver gang din virksomhed f.eks. tilslutter nye salgskanaler, skal der blandt dine analytikere være nogen, der husker, at der findes en sådan aggregeringsattribut.
Når du designer hver ny proces, for eksempel salg på internettet, salg gennem distributører tilsluttet det fælles loyalitetssystem, skal nogen have i tankerne, at alle nye processer skal sikre dataintegritet på kode niveau. For en industriel database med tusinder af tabeller virker det som en vanskelig opgave.
En erfaren udvikler ved selvfølgelig, hvordan man kan minimere de nævnte problemer, men efter min mening er det en erfaren analytikers opgave at forhindre dem i at opstå.
Jeg vil gerne takke for den værdifulde feedback under forberedelsen af publikationen til den ledende udvikler Evgenij Yarukhins.
Litteratur
Connolly Thomas, Begg Caroline. Databaser. Design, implementering og vedligeholdelse. Teori og praksis
Kilde: habr.com
