Hej! Mit navn er Andrey Semenov, jeg er senioranalytiker hos Sportmaster. I dette indlæg vil jeg rejse spørgsmålet om denormalisering af ERP-systemdatabaser. Vi vil se på generelle betingelser såvel som et specifikt eksempel - lad os sige, at det ville være en vidunderlig monopolværtshus for pirater og sømænd. Hvor pirater og sømænd skal betjenes forskelligt, fordi disse gode herrers idéer om skønhed og forbrugermønstre er væsentligt forskellige.
Hvordan gør man alle glade? Hvordan kan du undgå at gå amok med at designe og vedligeholde sådan et system? Hvad skal man gøre, hvis ikke kun de sædvanlige pirater og sømænd begynder at komme til værtshuset?
Alt er under snittet. Men lad os gå i rækkefølge.
1. Begrænsninger og antagelser
Alt ovenstående gælder kun for relationelle databaser. Konsekvenserne af denormalisering i form af modifikations-, sletnings- og indsættelsesanomalier, som er godt dækket, herunder på internettet, tages ikke i betragtning. Uden for rammerne af denne publikation er der tilfælde, hvor denormalisering er et almindeligt sted, med klassiske eksempler: passerier og nummer, dato og klokkeslæt osv.
Indlægget bruger intuitive og praktisk anvendelige definitioner af normale former, uden reference til matematiske termer. I den form, hvor de kan anvendes til undersøgelse af reelle forretningsprocesser (BP) og design af industriel software.
Det hævdes, at designet af datavarehuse, rapporteringsværktøjer og integrationsaftaler (som anvender tabelformede repræsentationer af information) adskiller sig fra designet af ERP-systemdatabaser ved, at forbrugsvenligheden og brugen af bevidst denormalisering for at opnå den kan have forrang over integritet beskyttelsesdata. Jeg deler denne opfattelse, og det, der er beskrevet nedenfor, gælder udelukkende for ERP-systemers stamdata- og transaktionsdatamodeller.
En forklaring af normale former gives ved hjælp af et eksempel, der er forståeligt på hverdagsniveau for de fleste læsere. Men som en visuel illustration, i afsnit 4-5, blev en bevidst "fiktiv" opgave bevidst brugt. Hvis du ikke gør dette og tager et lærebogseksempel, for eksempel den samme ordreopbevaringsmodel fra punkt 2, kan du komme i en situation, hvor læserens fokus vil blive flyttet fra den foreslåede nedbrydning af processen til en model, til personlig erfaring og opfattelse af, hvordan processer og modeller til lagring af data i IS skal opbygges. Tag med andre ord to kvalificerede IT-analytikere, lad den ene levere tjenester til logistikere, der transporterer passagerer, den anden til logistikere, der transporterer maskiner til produktion af mikrochips. Bed dem, uden at diskutere automatiserede BP'er på forhånd, om at oprette en datamodel til lagring af information om en jernbanetur.
Der er en ikke-nul sandsynlighed for, at du i de foreslåede modeller ikke kun vil finde et mærkbart anderledes sæt attributter, men også divergerende sæt af enheder, fordi hver analytiker vil stole på de processer og opgaver, han kender. Og i en sådan situation er det umuligt at sige, hvilken model der er "rigtig", fordi der ikke er noget evalueringskriterium.
2. Normale former
Første normale form af databasen kræver atomicitet af alle attributter.
Især hvis objekt A har ikke-nøgle attributter a og b, sådan at c=f(a,b) og i tabellen, der beskriver objekt A gemmer du værdien af attribut c, så er den første normale form overtrådt i databasen . For eksempel, hvis ordrespecifikationen angiver en mængde, hvis måleenheder afhænger af produkttypen: i et tilfælde kan det være styk, i et andet liter, i en tredje pakker bestående af styk (i modellen ovenfor Good_count_WR) , så er atomiciteten af attributter overtrådt i databasen. I dette tilfælde, for at kunne sige, hvad ordrespecifikationens tabelklynge skal være, har du brug for en målrettet beskrivelse af arbejdsprocessen i IS, og da processerne kan være forskellige, kan der være mange "korrekte" versioner.
Anden normalform af databasen kræver overholdelse af den første formular og sin egen tabel for hver enhed relateret til arbejdsprocessen i IS. Hvis der i en tabel er afhængigheder c=f1(a) og d=f2(b), og der ikke er nogen afhængighed c=f3(b), så er den anden normalform overtrådt i tabellen. I eksemplet ovenfor er der ingen afhængighed mellem ordre og adresse i ordretabellen. Skift gade- eller bynavnet, og du vil ikke have nogen indflydelse på de væsentlige egenskaber for ordren.
Tredje normalforms database kræver overholdelse af anden normalform og fravær af funktionelle afhængigheder mellem egenskaber for forskellige enheder. Denne regel kan formuleres som følger: "alt, der kan beregnes, skal beregnes." Med andre ord, hvis der er to objekter A og B. I tabellen, der gemmer attributterne for objekt A, er attribut C manifesteret, og objekt B har attribut b, sådan at c=f4(b) eksisterer, så er den tredje normalform er krænket. I eksemplet nedenfor hævder attributten Quantity of Pieces (Total_count_WR) på ordreposten klart at overtræde tredje normalform
3. Min tilgang til at anvende normalisering
1. Kun en målautomatiseret forretningsproces kan give analytikeren kriterier for at identificere enheder og attributter, når han opretter en datalagringsmodel. Oprettelse af en procesmodel er en forudsætning for at skabe en normal datamodel.
2. At opnå tredje normalform i snæver forstand er muligvis ikke praktisk i praksis med at skabe ERP-systemer, hvis nogle eller alle af følgende betingelser er opfyldt:
- automatiserede processer er sjældent genstand for ændringer,
- deadlines for forskning og udvikling er stramme,
- krav til dataintegritet er relativt lave (potentielle fejl i industriel software fører ikke til tab af penge eller klienter hos softwarekunden)
- etc.
Under de beskrevne forhold er omkostningerne ved at identificere og beskrive nogle objekters livscyklus og deres egenskaber muligvis ikke begrundet ud fra et økonomisk effektivitetssynspunkt.
3. Eventuelle konsekvenser af denormalisering af datamodellen i en allerede oprettet IS kan afbødes ved en grundig forundersøgelse af koden og test.
4. Denormalisering er en måde at overføre lønomkostninger fra stadiet med at undersøge datakilder og designe en forretningsproces til udviklingsstadiet, fra implementeringsperioden til perioden med systemudvikling.
5. Det er tilrådeligt at stræbe efter den tredje normale form for en database, hvis:
- Ændringsretningen i automatiserede forretningsprocesser er svær at forudsige
- Der er en svag arbejdsdeling i implementerings- og/eller udviklingsteamet
- Systemer, der indgår i integrationskredsløbet, udvikler sig efter deres egne planer
- Datainkonsistens kan resultere i, at en virksomhed mister kunder eller penge
6. Designet af en datamodel bør kun udføres af en analytiker i forbindelse med modellerne for målforretningsprocessen og processen i IS. Hvis en udvikler designer en datamodel, bliver han nødt til at fordybe sig i emneområdet i en sådan grad, at han især forstår forskellen mellem attributværdier - en nødvendig betingelse for at isolere atomare attributter. Påtager sig således usædvanlige funktioner.
4 Problem til illustration
Lad os sige, at du har en lille robottavern i havnen. Dit markedssegment: sømænd og pirater, der kommer i havn og har brug for en pause. Man sælger te med timian til sømænd og rom- og benkamme til at rede skæg til pirater. Tjenesten i selve værtshuset leveres af en robotværtinde og en robotbartender. Takket være din høje kvalitet og lave priser har du drevet dine konkurrenter ud, så alle der kommer fra skibet kommer til din værtshus, som er den eneste i havnen.
Værtshusinformationssystemkomplekset består af følgende software:
- Et tidligt varslingssystem om en klient, der genkender sin kategori baseret på karakteristiske træk
- Styresystem til robotværtinder og robotbartendere
- Lager- og leveringsstyringssystem til salgssted
- Supplier Relationship Management System (SURP)
proces:
Det tidlige varslingssystem genkender folk, der forlader skibet. Hvis en person er glatbarberet, identificerer hun ham som en sømand; hvis en person viser sig at have skæg, så identificeres han som en pirat.
Ind i værtshuset hører gæsten en hilsen fra robotværtinden i overensstemmelse med hans kategori, for eksempel: "Ho-ho-ho, kære pirat, gå til bords nr..."
Gæsten går til det angivne bord, hvor robotbartenderen allerede har forberedt varer til ham i overensstemmelse med kategorien. Robotbartenderen sender information til lagersystemet om, at den næste del af leveringen skal øges; lageret IS, baseret på de resterende saldi på lager, genererer en købsanmodning i ledelsessystemet.
Mens det tidlige varslingssystem kan være udviklet af din interne IT, kan barrobotstyringsprogrammet være blevet oprettet af en ekstern entreprenør specifikt til din virksomhed. Og systemer til styring af lagre og relationer til leverandører er skræddersyede pakkeløsninger fra markedet.
5. Eksempler på denormalisering og dens indvirkning på softwareudvikling
Ved udformningen af en forretningsproces udtalte de interviewede emneeksperter enstemmigt, at over hele verden drikker pirater rom og reder deres skæg med benkamme, og sømænd drikker te med timian og er altid glatbarberede.
En mappe over klienttyper vises med to værdier: 1 - pirater, 2 - sømænd, fælles for hele virksomhedens informationskredsløb.
Kundemeddelelsessystemet gemmer øjeblikkeligt resultatet af billedbehandlingen som identifikator (ID) for den genkendte klient og dens type: sømand eller pirat.
Genkendt objekt-id
Kundekategori
100500
Pirate
100501
Pirate
100502
Sømand
Lad os endnu en gang bemærke det
1. Vores sømænd er faktisk barberede mennesker
2. Vores pirater er faktisk skæggede mennesker
Hvilke problemer i dette tilfælde skal elimineres, så vores struktur stræber efter den tredje normale form:
- attribut atomicitetsovertrædelse - Klientkategori
- blande det analyserede faktum og konklusionen i én tabel
- faste funktionelle forhold mellem attributter af forskellige enheder.
I normaliseret form ville vi få to tabeller:
- genkendelsesresultat i form af et sæt af etablerede funktioner,
Genkendt objekt-id
Ansigtshår
100500
Ja
100501
Ja
100502
Nej
- resultatet af at bestemme typen af klient som en anvendelse af logikken indlejret i IS til at fortolke de etablerede karakteristika
Genkendt objekt-id
Identifikations-id
Kundekategori
100500
100001
Pirate
100501
100002
Pirate
100502
100003
Sømand
Hvordan kan en normaliseret datalagringsorganisation lette udviklingen af et IP-kompleks? Lad os sige, at du pludselig får nye kunder. Lad det være japanske pirater, der måske ikke har skæg, men de går med en papegøje på skulderen, og miljøvenlige pirater, du kan sagtens genkende dem på Gretas blå profil på venstre bryst.
Miljøpirater kan naturligvis ikke bruge knoglekamme og efterspørge en analog lavet af genanvendt havplast.
Du skal omarbejde programalgoritmerne i overensstemmelse med de nye input. Hvis normaliseringsreglerne blev fulgt, ville du kun skulle supplere inputs for nogle procesgrene i nogle systemer og kun oprette nye filialer til de tilfælde og i de IS'er, hvor ansigtshår betyder noget. Men da reglerne ikke blev fulgt, bliver du nødt til at analysere hele koden gennem hele kredsløbet, hvor værdierne af klienttypebiblioteket bruges og klart fastslå, at algoritmen i et tilfælde skal tage hensyn til den professionelle klientens aktivitet og i de andre fysiske træk.
I en form, der søger for at normalisere, ville vi få to tabeller med operationelle data og to mapper:
- genkendelsesresultat i form af et sæt af etablerede funktioner,
Genkendt objekt-id
Greta på venstre bryst
Fugl på skulderen
Ansigtshår
100510
1
1
1
100511
0
0
1
100512
1
0
- resultatet af at bestemme klienttypen (lad det være en brugerdefineret visning, hvor beskrivelser fra mapper vises)
Betyder den detekterede denormalisering, at systemerne ikke kan modificeres til at opfylde nye betingelser? Selvfølgelig ikke. Hvis vi forestiller os, at alle informationssystemerne er skabt af ét team med nul personaleomsætning, udviklingen er veldokumenteret og information overføres i teamet uden tab, så kan de nødvendige ændringer foretages med ubetydelig lille indsats. Men hvis vi vender tilbage til de oprindelige betingelser for problemet, slettes 1,5 tastaturer kun for at udskrive protokoller for fælles diskussioner og yderligere 0,5 til behandling af indkøbsprocedurer.
I ovenstående eksempel er alle tre normale former overtrådt, lad os prøve at overtræde dem separat.
Overtrædelse af første normalform:
Lad os sige, at varer bliver leveret til dit lager fra leverandørers lagre ved afhentning ved hjælp af en 1.5-tons gazelle, der tilhører dit værtshus. Størrelsen på dine ordrer er så små i forhold til leverandørernes omsætning, at de altid gennemføres en-til-en uden at vente på produktion. Har du brug for separate tabeller med sådan en forretningsproces: køretøjer, typer af køretøjer, er det nødvendigt at adskille plan og fakta i dine ordrer til afgåede leverandører?
Forestil dig, hvor mange "ekstra" forbindelser dine programmører skal skrive, hvis du bruger modellen nedenfor til at udvikle et program.
Lad os sige, at vi besluttede, at den foreslåede struktur er unødvendigt kompleks; i vores tilfælde er adskillelse af planen og kendsgerningen i ordreposten overflødig information, og den genererede ordrespecifikation omskrives baseret på resultaterne af accept af de ankomne varer, sjældne fejl -sortering og ankomst af varer af utilstrækkelig kvalitet afregnes uden for IS.
Og så en dag ser man, hvordan hele værtshussalen er fyldt med indignerede og uplejede pirater. Hvad skete der?
Det viser sig, at efterhånden som din virksomhed voksede, voksede dit forbrug også. Engang blev der taget en ledelsesbeslutning om, at hvis en gazelle var overbelastet i volumen og/eller vægt, hvilket var yderst sjældent, ville leverandøren prioritere belastningen til fordel for drikkevarer.
De ikke-leverede varer endte i den næste ordre og forlod en ny flyvning; tilstedeværelsen af en minimumsaldo på lageret på værtshuset gjorde det muligt ikke at bemærke manglende sager.
Den sidste konkurrent lukkede i havnen, og det punkterede tilfælde af gazelleoverbelastning, omgået af prioritering baseret på antagelsen om tilstrækkeligheden af minimumsbalancen og periodisk underbelastning af køretøjet, blev almindelig praksis. Det oprettede system vil ideelt set fungere i overensstemmelse med de algoritmer, der er indlejret i det, og vil blive frataget enhver mulighed for at spore den systematiske manglende opfyldelse af planlagte ordrer. Kun et skadet omdømme og utilfredse kunder vil være i stand til at opdage problemet.
En opmærksom læser kan have bemærket, at den bestilte mængde i ordrespecifikationen (T_ORDER_SPEC) i sektion 2 og sektion 5 måske eller måske ikke opfylder kravet om første normalform. Det hele afhænger af, om der, givet det udvalgte varesortiment, væsentligt forskellige måleenheder kan falde inden for samme felt.
Overtrædelse af anden normalform:
Efterhånden som dine behov vokser, køber du et par flere køretøjer i forskellige størrelser. I ovenstående sammenhæng blev oprettelsen af et køretøjsregister anset for at være overflødigt; som følge heraf opfatter alle databehandlingsalgoritmer, der tjener behovene for levering og lager, flytningen af last fra leverandøren til lageret som en flyvning på udelukkende 1,5 tons gazelle. Så sammen med køb af nye køretøjer opretter du stadig et køretøjsregister, men når du færdiggør det, bliver du nødt til at analysere al den kode, der refererer til godsets bevægelse for at finde ud af, om der på hvert specifikt sted er underforstået referencer til egenskaberne af selve det køretøj, hvorfra virksomheden startede.
Overtrædelse af den tredje normalform:
På et tidspunkt begynder du at oprette et loyalitetsprogram, en registrering af en almindelig kunde vises. Hvorfor f.eks. bruge tid på at skabe materialevisninger, der gemmer aggregerede data om salg til en individuel kunde til brug for rapportering og overførsel til analytiske systemer, hvis man ved starten af et loyalitetsprogram kan placere alt, hvad kunden interesserer, på kundens journal. ? Og ved første øjekast er der faktisk ingen mening. Men hver gang din virksomhed forbinder f.eks. nye salgskanaler, bør der være nogen blandt dine analytikere, som vil huske, at sådan en aggregeringsattribut eksisterer.
Når man designer hver ny proces, for eksempel salg på internettet, salg gennem distributører forbundet til et fælles loyalitetssystem, skal nogen huske på, at alle nye processer skal sikre dataintegritet på kodeniveau. For en industriel database med tusind tabeller virker dette som en umulig opgave.
En erfaren udvikler ved selvfølgelig, hvordan man stopper alle de problemer, der er nævnt ovenfor, men efter min mening er opgaven for en erfaren analytiker ikke at bringe dem frem i lyset.
Jeg vil gerne udtrykke min taknemmelighed til den førende udvikler Evgeniy Yarukhin for hans værdifulde feedback under forberedelsen af publikationen.
Litteratur
Connolly Thomas, Begg Caroline. Database. Design, implementering og support. Teori og praksis
Kilde: www.habr.com