Hallå! Jag heter Andrey Semenov, jag är senioranalytiker på Sportmaster. I detta inlägg vill jag ta upp frågan om denormalisering av ERP-systemdatabaser. Vi kommer att titta på allmänna villkor, såväl som ett specifikt exempel - låt oss säga att det skulle vara en underbar monopolkrog för pirater och sjömän. Där pirater och sjömän måste betjänas annorlunda, eftersom idéerna om skönhet och konsumtionsmönster hos dessa goda herrar är väsentligt olika.
Hur gör man alla glada? Hur kan du undvika att bli galen av att designa och underhålla ett sådant system? Vad ska man göra om inte bara de vanliga piraterna och sjömännen börjar komma till krogen?
Allt är under snittet. Men låt oss gå i ordning.
1. Begränsningar och antaganden
Allt ovanstående gäller endast relationsdatabaser. Konsekvenserna av denormalisering i form av modifierings-, raderings- och infogningsavvikelser, som är väl täckta, inklusive på Internet, beaktas inte. Utanför denna publikations räckvidd finns det fall där denormalisering är en vanlig plats, med klassiska exempel: passserie och nummer, datum och tid, etc.
Inlägget använder intuitiva och praktiskt tillämpbara definitioner av normala former, utan hänvisning till matematiska termer. I den form som de kan tillämpas på undersökning av verkliga affärsprocesser (BP) och design av industriell programvara.
Det hävdas att utformningen av datalager, rapporteringsverktyg och integrationsavtal (som använder tabellformade representationer av information) skiljer sig från utformningen av ERP-systemdatabaser genom att enkel konsumtion och användningen av medveten denormalisering för att uppnå det kan ha företräde framför integritet skyddsdata. Jag delar denna åsikt, och det som beskrivs nedan gäller enbart basdata- och transaktionsdatamodeller i affärssystem.
En förklaring av normala former ges med hjälp av ett exempel som är förståeligt på vardagsnivå för de flesta läsare. Men som en visuell illustration, i punkterna 4-5, användes en medvetet "fiktiv" uppgift medvetet. Om du inte gör detta och tar något läroboksexempel, till exempel samma orderlagringsmodell från punkt 2, kan du hamna i en situation där läsarens fokus kommer att flyttas från den föreslagna nedbrytningen av processen till en modell, till personlig erfarenhet och uppfattning om hur processer och modeller för att lagra data i IS måste byggas. Med andra ord, ta två kvalificerade IT-analytiker, låt den ena tillhandahålla tjänster till logistiker som transporterar passagerare, den andra till logistiker som transporterar maskiner för tillverkning av mikrochips. Be dem, utan att diskutera automatiserade BP:er i förväg, skapa en datamodell för att lagra information om en järnvägsresa.
Det finns en icke-noll sannolikhet att du i de föreslagna modellerna inte bara hittar en märkbart olika uppsättning attribut, utan också olika uppsättningar av enheter, eftersom varje analytiker kommer att förlita sig på de processer och uppgifter som är bekanta för honom. Och i en sådan situation är det omöjligt att säga vilken modell som är "korrekt", eftersom det inte finns något utvärderingskriterium.
2. Normala former
Första normala formen av databasen kräver atomicitet av alla attribut.
Speciellt om objekt A har icke-nyckelattribut a och b, så att c=f(a,b) och i tabellen som beskriver objekt A lagrar du värdet av attribut c, så bryts den första normala formen i databasen . Till exempel, om beställningsspecifikationen anger en kvantitet, vars måttenheter beror på typen av produkt: i ett fall kan det vara stycken, i ett annat liter, i ett tredje paket som består av stycken (i modellen ovan Good_count_WR) , då kränks atomiciteten för attribut i databasen. I det här fallet, för att säga vad orderspecifikationens tabellkluster ska vara, behöver du en riktad beskrivning av arbetsprocessen i IS, och eftersom processerna kan vara olika kan det finnas många "korrekta" versioner.
Andra normala formen av databasen kräver överensstämmelse med det första formuläret och en egen tabell för varje enhet relaterad till arbetsprocessen i IS. Om det i en tabell finns beroenden c=f1(a) och d=f2(b) och det inte finns något beroende c=f3(b), så bryts den andra normalformen i tabellen. I exemplet ovan finns det inget beroende mellan order och adress i ordertabellen. Ändra gatu- eller stadnamnet och du kommer inte att påverka de väsentliga attributen för beställningen.
Tredje normalformens databas kräver överensstämmelse med andra normala formen och frånvaron av funktionella beroenden mellan attribut för olika enheter. Denna regel kan formuleras på följande sätt: "allt som kan beräknas måste beräknas." Med andra ord, om det finns två objekt A och B. I tabellen som lagrar attributen för objekt A, manifesteras attribut C, och objekt B har attribut b, så att c=f4(b) existerar, då den tredje normalformen är kränkt. I exemplet nedan gör anspråk på att attributet Quantity of Pieces (Total_count_WR) på orderposten strider mot tredje normalform
3. Mitt förhållningssätt till att tillämpa normalisering
1. Endast en målautomatiserad affärsprocess kan ge analytikern kriterier för att identifiera enheter och attribut när han skapar en datalagringsmodell. Att skapa en processmodell är en förutsättning för att skapa en normal datamodell.
2. Att uppnå den tredje normala formen i strikt mening kanske inte är praktiskt i praktiken för att skapa ERP-system om några eller alla av följande villkor är uppfyllda:
- automatiserade processer är sällan föremål för förändring,
- deadlines för forskning och utveckling är snäva,
- kraven på dataintegritet är relativt låga (potentiella fel i industriell programvara leder inte till att mjukvarukunden förlorar pengar eller klienter)
- etc.
Under de beskrivna förhållandena kan kostnaderna för att identifiera och beskriva livscykeln för vissa objekt och deras attribut inte vara motiverade ur ekonomisk effektivitetssynpunkt.
3. Eventuella konsekvenser av denormalisering av datamodellen i en redan skapad IS kan mildras genom en grundlig förstudie av koden och testning.
4. Denormalisering är ett sätt att överföra arbetskostnader från stadiet av att undersöka datakällor och designa en affärsprocess till utvecklingsstadiet, från implementeringsperioden till perioden för systemutveckling.
5. Det är tillrådligt att sträva efter den tredje normala formen av en databas om:
- Förändringens riktning i automatiserade affärsprocesser är svår att förutse
- Det finns en svag arbetsfördelning inom implementerings- och/eller utvecklingsteamet
- System som ingår i integrationskretsen utvecklas enligt sina egna planer
- Datainkonsekvens kan resultera i att ett företag förlorar kunder eller pengar
6. Utformningen av en datamodell bör endast utföras av en analytiker i samband med modellerna för målaffärsprocessen och processen i IS. Om en utvecklare designar en datamodell måste han fördjupa sig i ämnesområdet i en sådan utsträckning att han i synnerhet förstår skillnaden mellan attributvärden - ett nödvändigt villkor för att isolera atomattribut. Tar alltså på sig ovanliga funktioner.
4 Problem för illustration
Låt oss säga att du har en liten robotkrog i hamnen. Ditt marknadssegment: sjömän och pirater som kommer i hamn och behöver en paus. Man säljer te med timjan till sjömän, och rom- och benkammar för att kamma skägg till pirater. Tjänsten på själva krogen tillhandahålls av en robotvärdinna och en robotbartender. Tack vare din höga kvalitet och låga priser har du drivit ut dina konkurrenter, så att alla som kommer av fartyget kommer till din krog, som är den enda i hamnen.
Kroginformationssystemkomplexet består av följande programvara:
- Ett tidig varningssystem om en klient som känner igen sin kategori baserat på karakteristiska egenskaper
- Styrsystem för robotvärdinnor och robotbartendrar
- Lager- och leveranshanteringssystem till försäljningsställe
- Supplier Relationship Management System (SURP)
processen:
Systemet för tidig varning känner igen personer som lämnar fartyget. Om en person är renrakad identifierar hon honom som en sjöman, om en person visar sig ha skägg identifieras han som en pirat.
När gästen går in i krogen hör gästen en hälsning från robotvärdinnan i enlighet med hans kategori, till exempel: "Ho-ho-ho, kära pirat, gå till bords nr..."
Gästen går till det angivna bordet, där robotbartendern redan har förberett varor för honom i enlighet med kategorin. Robotbartendern överför information till lagersystemet om att nästa del av leveransen ska ökas, lagret IS, baserat på resterande saldon i lager, genererar en köpförfrågan i ledningssystemet.
Även om systemet för tidig varning kan ha utvecklats av din interna IT, kan hanteringsprogrammet för barrobot ha skapats av en extern entreprenör specifikt för ditt företag. Och system för hantering av lager och relationer med leverantörer är skräddarsydda paketerade lösningar från marknaden.
5. Exempel på denormalisering och dess inverkan på mjukvaruutveckling
När de utformade en affärsprocess sa de intervjuade ämnesexperterna enhälligt att pirater över hela världen dricker rom och kammar skägget med benkammar, och sjömän dricker te med timjan och är alltid renrakade.
En katalog över klienttyper visas med två värden: 1 - pirater, 2 - sjömän, gemensamma för hela företagets informationskrets.
Kundaviseringssystemet lagrar omedelbart resultatet av bildbehandlingen som identifierare (ID) för den erkända klienten och dess typ: sjöman eller pirat.
Identifierat objekt-ID
Kundkategori
100500
Pirat
100501
Pirat
100502
seglare
Låt oss återigen konstatera det
1. Våra sjömän är faktiskt rakade människor
2. Våra pirater är faktiskt skäggiga människor
Vilka problem i det här fallet måste elimineras så att vår struktur strävar efter den tredje normala formen:
- attribut atomicity violation - Klientkategori
- blanda det analyserade faktumet och slutsatsen i en tabell
- fast funktionell relation mellan attribut för olika entiteter.
I normaliserad form skulle vi få två tabeller:
- igenkänningsresultat i form av en uppsättning etablerade egenskaper,
Identifierat objekt-ID
Ansiktshår
100500
Ja
100501
Ja
100502
Ingen
- resultatet av att bestämma typen av klient som en tillämpning av logiken inbäddad i IS för att tolka de etablerade egenskaperna
Identifierat objekt-ID
Identifikations-ID
Kundkategori
100500
100001
Pirat
100501
100002
Pirat
100502
100003
seglare
Hur kan en normaliserad datalagringsorganisation underlätta utvecklingen av ett IP-komplex? Låt oss säga att du plötsligt får nya kunder. Låt det vara japanska pirater som kanske inte har skägg, men de går med en papegoja på axeln, och miljöaktiva pirater, du känner lätt igen dem på Gretas blå profil på vänster bröst.
Miljöpirater kan naturligtvis inte använda benkammar och kräver en analog gjord av återvunnen havsplast.
Du måste omarbeta programalgoritmerna i enlighet med de nya ingångarna. Om normaliseringsreglerna följdes, skulle du bara behöva komplettera indata för vissa processgrenar i vissa system och skapa nya grenar endast för de fall och i de IS:er där ansiktshår spelar roll. Men eftersom reglerna inte följdes, måste du analysera hela koden, genom hela kretsen, där värdena för klienttypskatalogen används och tydligt fastställa att algoritmen i ett fall ska ta hänsyn till den professionella klientens aktivitet och i andra fysiska egenskaper.
I en form som söker för att normaliseras skulle vi få två tabeller med driftsdata och två kataloger:
- igenkänningsresultat i form av en uppsättning etablerade egenskaper,
Identifierat objekt-ID
Greta på vänster bröst
Fågel på axeln
Ansiktshår
100510
1
1
1
100511
0
0
1
100512
1
0
- resultatet av att bestämma klienttypen (låt det vara en anpassad vy där beskrivningar från kataloger visas)
Innebär den upptäckta denormaliseringen att systemen inte kan modifieras för att möta nya villkor? Självklart inte. Om vi föreställer oss att alla informationssystem skapades av ett team med noll personalomsättning, utvecklingen är väl dokumenterad och information överförs inom teamet utan förlust, då kan de nödvändiga förändringarna göras med försumbar liten ansträngning. Men om vi återgår till de ursprungliga förhållandena för problemet kommer 1,5 tangentbord att raderas bara för att skriva ut protokoll för gemensamma diskussioner och ytterligare 0,5 för att bearbeta upphandlingsförfaranden.
I exemplet ovan bryts alla tre normala former, låt oss försöka bryta mot dem separat.
Brott mot den första normala formen:
Låt oss säga att varor levereras till ditt lager från leverantörernas lager genom hämtning med en 1.5-tons gasell som tillhör din krog. Storleken på dina beställningar är så små i förhållande till leverantörernas omsättning att de alltid genomförs en-mot-en utan att vänta på produktion. Med en sådan affärsprocess, behöver du separata tabeller: fordon, typer av fordon, är det nödvändigt att separera plan och fakta i dina beställningar till avgående leverantörer?
Föreställ dig bara hur många "extra" anslutningar dina programmerare kommer att behöva skriva om du använder modellen nedan för att utveckla ett program.
Låt oss säga att vi beslutade att den föreslagna strukturen är onödigt komplex; i vårt fall är att separera planen och faktumet i beställningsposten överflödig information, och den genererade beställningsspecifikationen skrivs om baserat på resultaten av acceptansen av de ankomna varorna, sällsynta misstag -gradering och ankomst av varor av otillräcklig kvalitet avräknas utanför IS.
Och så en dag ser man hur hela krogsalen fylls av indignerade och ovårdade pirater. Vad hände?
Det visar sig att när ditt företag växte, så växte även din konsumtion. En gång i tiden togs ett ledningsbeslut att om en gasell var överbelastad i volym och/eller vikt, vilket var ytterst sällsynt, skulle leverantören prioritera belastningen till förmån för drycker.
De ej levererade varorna hamnade i nästa beställning och åkte iväg på en ny flygning, närvaron av ett minimisaldot i lagret på krogen gjorde det möjligt att inte märka saknade fall.
Den sista konkurrenten stängde i hamnen, och det punkterade fallet med gasellöverbelastning, som förbigicks av prioritering baserad på antagandet om tillräcklig minimibalans och periodisk underbelastning av fordonet, blev vanlig praxis. Det skapade systemet kommer idealiskt att fungera i enlighet med de algoritmer som är inbäddade i det och kommer att berövas alla möjligheter att spåra det systematiska misslyckandet med att uppfylla planerade beställningar. Endast ett skadat rykte och missnöjda kunder kommer att kunna upptäcka problemet.
En uppmärksam läsare kan ha märkt att den beställda kvantiteten i orderspecifikationen (T_ORDER_SPEC) i avsnitt 2 och avsnitt 5 kanske inte uppfyller kravet på första normalform. Allt beror på om, givet det valda sortimentet av varor, väsentligt olika måttenheter kan falla inom samma område.
Brott mot andra normala formen:
När dina behov växer köper du ytterligare ett par fordon i olika storlekar. I ovanstående sammanhang ansågs skapandet av en fordonskatalog vara överflödigt; som ett resultat uppfattar alla databehandlingsalgoritmer som tjänar behoven för leverans och lager förflyttning av last från leverantören till lagret som en flygning av enbart 1,5 ton gasell. Så tillsammans med köpet av nya fordon skapar du fortfarande en fordonskatalog, men när du slutför den måste du analysera all kod som refererar till lastens förflyttning för att ta reda på om det på varje specifik plats antyds referenser till egenskaperna av själva fordonet från vilket verksamheten startade.
Brott mot den tredje normalformen:
Vid något tillfälle börjar du skapa ett lojalitetsprogram, ett register över en vanlig kund dyker upp. Varför till exempel lägga tid på att skapa materialvyer som lagrar aggregerad data om försäljning till en enskild kund för användning i rapportering och överföring till analytiska system, om i starten av ett lojalitetsprogram allt som intresserar kunden kan placeras på kundens register ? Och vid första anblicken är det verkligen ingen mening. Men varje gång ditt företag kopplar upp till exempel nya försäljningskanaler bör det finnas någon bland dina analytiker som kommer ihåg att ett sådant aggregeringsattribut finns.
När man utformar varje ny process, till exempel försäljning på Internet, försäljning genom distributörer kopplade till ett gemensamt lojalitetssystem, måste någon tänka på att alla nya processer ska säkerställa dataintegritet på kodnivå. För en industriell databas med tusen tabeller verkar detta vara en omöjlig uppgift.
En erfaren utvecklare vet naturligtvis hur man stoppar alla ovan nämnda problem, men enligt min mening är uppgiften för en erfaren analytiker inte att ta fram dem.
Jag skulle vilja uttrycka min tacksamhet till den ledande utvecklaren Evgeniy Yarukhin för hans värdefulla feedback under utarbetandet av publikationen.
Litteratur
Connolly Thomas, Begg Caroline. Databas. Design, implementering och support. Teori och praktik
Källa: will.com