🥇Denormalisering av databaser i ERP-system och dess påverkan på programvaruutveckling: öppnar en taverna på Tortuga

Hej! Jag heter Andrey Semyonov, jag är senioranalytiker på Sportmaster. I det här inlägget vill jag ta upp frågan om denormalisering av databaser i ERP-system. Vi kommer att titta på allmänna förutsättningar samt ett specifikt exempel — låt oss säga, det kommer att vara en underbar tavernamonopol för pirater och sjömän. Där pirater och sjömän måste betjänas på olika sätt, eftersom deras syn på det vackra och konsumtionsmönster skiljer sig avsevärt åt.

Hur gör man så att alla är nöjda? Hur undviker man att bli galen när man designar och underhåller ett sådant system? Vad gör man om tavernan börjar ta emot inte bara de vanliga piraterna och sjömännen?

Allt finns nedan. Men låt oss gå tillväga steg för steg.

1. Begränsningar och antaganden

Allt som anges gäller endast relationella databaser. De välkända konsekvenserna av denormalisering i form av modifierings-, borttagnings- och insättningsanomalier som beskrivs på internet beaktas inte. Utanför publiceringen lämnas fall där denormalisering är ett allmänt fenomen, med klassiska exempel: serienummer och passnummer, datum och tid med mera.

Inlägget använder intuitivt begripliga och praktiskt tillämpbara definitioner av normala former, utan hänvisningar till matematiska termer. I den form de kan tillämpas på undersökning av verkliga affärsprocesser (BP) och design av industriell programvara.

Det finns en åsikt om att design av datalager, verktyg för rapportering och integrationsavtal (i vilka tabulär informationsrepresentation används), skiljer sig från design av ERP-databaser i det att bekvämligheten i konsumtionen och tillämpligheten för att uppnå detta genom medveten denormalisering kan ha prioritet över skyddet av dataintegriteten. Jag delar denna åsikt, och det som beskrivs nedan gäller uteslutande modeller för masterdata och transaktionsdata i ERP-system.

Förklaringen av normala former presenteras med ett exempel som många läsare kan förstå på en vardaglig nivå. Men för att ge en tydlig illustration används medvetet en "uppfunnen" uppgift i punkterna 4-5. Om detta inte görs och ett klassiskt exempel tas, som till exempel samma modell för lagring av beställningar från punkt 2, kan läsarens fokus flyttas från den föreslagna nedbrytningen av processen till den personliga erfarenheten och uppfattningen av hur processer och datalagringsmodeller bör byggas i informationssystem. Med andra ord, ta två kvalificerade IT-analytiker, låt en betjäna logistikföretag som transporterar passagerare och den andra de som transporterar maskiner för att producera mikrochip. Be dem, utan att i förväg diskutera automatiserbara affärsprocesser, skapa en datamodell för att lagra information om en järnvägstransport.

Det finns en icke-noll sannolikhet att ni i de föreslagna modellerna hittar inte bara märkbart olika uppsättningar av attribut, utan även icke överensstämmande uppsättningar av entiteter, eftersom varje analytiker kommer att basera sig på sina egna kända processer och uppgifter. Att säga vilken modell som är "rätt" i en sådan situation är omöjligt, eftersom det inte finns något bedömningskriterium.

2. Normala former

Första normala formen av databasen kräver atomär struktur för alla attribut.
Specifikt, om objekt A har icke-nyckelattribut a och b, sådana 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 i beställningsspecifikationen anges en mängd vars enheter beror på produkttypen: i vissa fall kan det vara stycken, i andra liter, och i tredje förpackningar bestående av stycken (i modellen ovan Good_count_WR), så överträder det atomäriteten för attributen i databasen. I detta fall, för att säga hur tabellstrukturen för beställningsspecifikationen bör se ut, behövs en målspecifikation av arbetsprocessen i informationssystemet, och eftersom processerna kan vara olika, kan det finnas många "rätta" versioner.

Andra normala formen av databasen kräver att den första formen beaktas och att varje entitet som hör till processarbetet i informationssystemet har sin egen tabell. Om det i en tabell finns beroenden med=f1(a) och d=f2(b) och det inte finns något beroende med=f3(b), är den andra normala formen bruten i tabellen. I exemplet ovan finns det inget beroende mellan beställningen och adressen i tabellen "Beställning". Ändra gatunamnet eller staden, och du påverkar inte några väsentliga attribut av beställningen.

Tredje normala formen av databasen kräver att den andra normala formen beaktas och att det inte finns några funktionella beroenden mellan attributen för olika entiteter. Denna regel kan formuleras som: "allt som kan beräknas, ska beräknas". Med andra ord, om det finns två objekt A och B. I tabellen som lagrar attributen för objekt A visas attributet C, och objekt B har ett attribut b, sådant att det finns c=f4(b), då bryts den tredje normala formen. I det nedanstående exemplet påstår attributet "Antal bitar" (Total_count_WR) i beställningsposten att det bryter mot den tredje normala formen.

3. Min metod för tillämpning av normalisering

1. Endast den målorienterade automatiserbara affärsprocessen kan ge analytikern kriterier för att identifiera entiteter och attribut vid skapandet av datalagringsmodellen. Skapandet av processmodellen är en förutsättning för att skapa en normal datamodell.

2. Att uppnå den tredje normala formen i strikt mening kan vara orealistiskt i praktiken vid skapandet av ERP-system under den del av eller alla följande villkor:

automatiserbara processer är sällan utsatta för förändringar,
tidsramarna för forskning och utveckling är snäva,
kraven på dataintegritet är relativt låga (potentiella fel i industriprogramvara leder inte till förlust av pengar eller kunder för programvarukunden)
och så vidare.

Under de angivna förhållandena kan kostnaderna för att identifiera, beskriva livscykeln för vissa objekt och deras attribut vara oekonomiska.

3. Eventuella konsekvenser av denormalisering av datamodellen i ett redan skapat informationssystem kan mildras genom noggrann förundersökning av koden och testning.

4. Denormalisering är en metod för att överföra arbetsinsatser från forsknings- och datakällstegen, samt affärsprocessdesign, till utvecklingssteget, från implementeringsperioden till systemutvecklingsperioden.

5. Det är rimligt att sträva efter den tredje normalformen för databaser om:

Förändringarna i de automatiserade affärsprocesserna är svåra att förutsäga.
Det finns en svag djupindelning av arbetsuppgifter inom implementerings- och/eller utvecklingsteamet.
Systemen som ingår i integrationskonturen utvecklas enligt egna planer.
Oenigheter i data kan leda till kund- eller intäktsförluster för företaget.

6. Designen av datamodellen ska utföras av en analytiker endast i samband med modeller av den avsedda affärsprocessen och processen i informationssystemet. Om datamodellen designas av en utvecklare, måste denne fördjupa sig i ämnesområdet i sådan grad att denne särskilt kan förstå skillnaden mellan värdena för attribut - en nödvändig villkor för att identifiera atomära attribut. På så sätt tar man på sig funktioner som inte är typiska.

4 Uppgift för illustration.

Anta att du har en liten robotiserad krog i hamnen. Din målmarknad: sjömän och pirater som går in i hamnen och behöver vila. Till sjömän säljer du te med timjan, och till piraterna rom och benkam för att kamma sin skägg. Servicen i krogen utförs av en robotvärdinna och en robotbartender. Tack vare hög kvalitet och låga priser har du trängt ut alla konkurrenter, så varje person som går iland går till din krog, som är den enda i hamnen.

Komplexet av informationssystem för krogen består av följande programvara:

Ett tidigt varningssystem för kunder som känner igen deras kategori efter karakteristiska drag.
Ett system för att hantera robotvärdinnor och robotbartenders.
Ett system för att hantera lager och leveranser till försäljningsställen.
Ett system för att hantera relationer med leverantörer (SRM).

Process:

Det tidiga varningssystemet känner igen personer som går iland från båten. Om en person är slätbarberad klassas de som sjömän, medan en person med skägg klassas som pirat.

När gästen går in i krogen hör de ett välkomnande från robotvärdinnan i enlighet med sin kategori, exempelvis: "Ho-ho-ho, ärade pirat, gå till bordet nr..."

Gästen går till den angivna stationen där robotbaren redan har förberett varor för dem enligt kategori. Robotbaren överför information till lagersystemet om att nästa leverans bör ökas, och lagersystemet utifrån lagret formar en inköpsansökan i systemet.

Låt tidigt varningssystem utvecklas av din interna IT, programmet för att hantera barrobotar skapades av en extern entreprenör specifikt för ditt företag. Lagringsystem och leverantörers relationshanteringssystem är specialanpassade paketlösningar från marknaden.

5. Exempel på denormalisering och dess påverkan på programvaruutveckling

Vid utformningen av affärsprocessen sa de tillfrågade experterna enigt att pirater över hela världen dricker rom och kammar sina skägg med benkammar, medan sjömän dricker te med timjan och alltid är välrakade.

En katalog över kundtyper kommer att skapas med två värden: 1 - pirater, 2 - sjömän, gemensam för hela företagets informationsram.

Kundens varningssystem sparar omedelbart resultatet av bildbehandlingen som identifierare (ID) av den igenkända kunden och dess typ: sjöman eller pirat.

ID för den igenkända objekten
Kundkategori

100500
Pirat

100501
Pirat

100502
Sjöman

Vi noterar återigen att

1. Våra sjömän är faktiskt rakhyvelmänniskor
2. Våra pirater är faktiskt skäggiga personer

Vilka problem måste lösas i detta fall för att vår struktur ska sträva efter den tredje normala formen:

brott mot atomäriteten av attributet - Kundkategori
blandning av den analyserade fakta och slutsatsen i samma tabell
fastställd funktionell beroende mellan attribut av olika entiteter.

I normaliserad form skulle vi få två tabeller:

resultatet av igenkänning i form av en uppsättning fastställda kännetecken,

ID för den igenkända objekten
Hårfäste i ansiktet

100500
Ja

100501
Ja

100502
Ingen

resultatet av att bestämma kundtypen som en tillämpning av den inbyggda systemlogiken för tolkning av de fastställda kännetecknen

ID för den igenkända objekten
ID för identifiering
Kundkategori

100500
100001
Pirat

100501
100002
Pirat

100502
100003
Sjöman

Hur kan en normaliserad lagringsorganisation underlätta utvecklingen av ett informationssystem? Anta att du plötsligt får nya kunder. Låt oss säga att det är japanska pirater som kanske saknar skägg, men de går runt med en papegoja på axeln, samt miljövänliga pirater, som lätt känns igen på Gretas blå profil på vänster bröst.

Miljövänliga pirater kan naturligtvis inte använda benkammar och kräver en motsvarighet av återvunnen havsplast.

Du behöver omarbeta programalgoritmerna enligt de nya förutsättningarna. Om normaliseringsreglerna hade följts, skulle du bara behöva komplettera ingångarna för vissa processgrenar i vissa system och skapa nya grenar endast för de fall och i de informationssystem där ansiktshår är relevant. Men eftersom reglerna inte följdes, måste du analysera hela koden inom hela systemet där värden från kundtypregister används och entydigt fastställa att i ett fall bör algoritmen ta hänsyn till kundens yrkesverksamhet, medan i ett annat fall bör den beakta fysiska egenskaper.

I den form som strävar efter normalisering, skulle vi ha fått två tabeller med operativa data och två register:

resultatet av igenkänning i form av en uppsättning fastställda kännetecken,

ID för den igenkända objekten
Greta på vänster bröst
Fågel på axeln
Hårfäste i ansiktet

100510
1
1
1

100511
0
0
1

100512

1
0

resultatet av att bestämma kundtyp (låt detta vara användarens visning, där beskrivningar från registren visas)

Betyder den upptäckta denormaliseringen att systemen inte kan anpassas till de nya villkoren? Självklart inte. Om vi antar att alla informationssystem skapades av ett team med noll personalomsättning, att utvecklingen är väl dokumenterad och att informationen i teamet överförs utan förluster, kan de nödvändiga förändringarna göras med försumbara insatser. Men om vi återvänder till de ursprungliga förutsättningarna för uppgiften, skulle en och en halv tangentbord gå åt för att skriva protokollen för gemensamma diskussioner och ytterligare ett halvt för att utforma upphandlingsprocesserna.

I exemplet ovan har alla tre normala former bryts, låt oss försöka bryta dem separat.

Brott mot den första normala formen:

Anta att varor levereras till ditt lager från leverantörernas lager via en 1,5 tons skåpbil som tillhör ditt värdshus. Storleken på dina beställningar är så liten i förhållande till leverantörernas omsättning att de alltid utförs exakt utan väntan på tillverkning. Krävs det separata tabeller för detta flöde: fordon, typer av fordon, behöver ni separera plan och verklighet i era beställningar som skickats till leverantörerna?

Tänk bara på hur många "överskott"-anslutningar som dina programmerare måste skriva om ni använder modellen nedan för att utveckla programmet.

Anta att vi har kommit fram till att den föreslagna strukturen är alltför komplicerad, att separera plan och verklighet vid beställningsregistreringen är överflödig information, och att den framtagna beställningsspecifikationen skrivs om baserat på resultatet av mottagningen av den ankommande varan, sällsynta felaktigheter och varor av undermålig kvalitet hanteras utanför informationssystemet.
Och en dag ser du hur hela salen i värdshuset är fylld av upprörda och ovårdade pirater. Vad har hänt?

Det visade sig att när ditt företag växte, växte också konsumtionen. Någon gång fattades det ett ledningsbeslut att om skåpbilen blev överlastad med volym och/eller vikt, vilket hände ytterst sällan, prioriterade leverantören lastningen till fördel för drycker.

Underlevererat gods hamnade i nästa beställning och skickades iväg i en ny tur, medan det tillgängliga underlaget på lagret vid värdshuset möjliggjorde att man kunde ignorera de bortfallna fallen.

I hamnen stängde den sista konkurrenten, och det bortfallna fallet av överlastning av skåpbilen, som undvikits genom prioritering baserad på antagandet om tillräckligt lagersaldo och periodisk underlastning av fordonet, blev en vanlig praxis. Det skapade systemet kommer att fungera perfekt i enlighet med de inlagda algoritmerna och kommer att sakna möjligheten att spåra systematisk misslyckande med planerade beställningar. Endast en skadad rykte och missnöjda kunder kan upptäcka problemet.

Uppmärksam läsare har nog märkt att den beställda kvantiteten i beställningsspecifikationen (T_ORDER_SPEC) i avsnitt 2 och avsnitt 5 kan motsvara eller inte motsvara kraven i den första normalformen. Det beror helt på om olika enheter av mått kan falla in i samma fält med det valda sortimentet av varor.

Överträdelser av den andra normalformen:

När dina behov växer skaffar du ytterligare några transportmedel i olika storlekar. I den beskrivna kontexten har skapandet av en transportmedelsregistrering bedömts som överflödig, vilket gör att alla algoritmer som arbetar med data och stöder leverans- och lagringsbehov uppfattar lastens flyttning från leverantören till lagret som en transport av endast en 1,5 tons skåpbil. Så, tillsammans med köpet av nya transportmedel skapar du ändå en transportmedelsregistrering, men vid vidareutvecklingen måste du analysera all kod som refererar till lastens flyttning för att ta reda på om det i varje specifikt fall syftas på egenskaperna hos just det fordonet som verksamheten började med.

Överträdelser av den tredje normalformen:

Vid något tillfälle börjar du skapa ett lojalitetsprogram, och det skapas en post för en återkommande kund. Varför, till exempel, slösa tid på att skapa materiella representationer som lagrar aggregerade uppgifter om försäljning för en enskild kund för att använda i rapportering och överföring till analytiska system, när allt som intresserar kunden i början av lojalitetsprogrammet kan läggas på själva kundposten? Och, verkligen, verkar det till en början vara meningslöst. Men varje gång ditt företag ansluter till exempel nya försäljningskanaler, bör det finnas någon bland era analytiker som påminner om att det finns en sådan aggregeringsattribut.

När du designar varje ny process, säg, försäljning på internet, försäljning genom distributörer kopplade till det gemensamma lojalitetssystemet, måste någon hålla i åtanke att alla nya processer måste säkerställa dataintegritet på kodnivå. För en industriell databas med tusentals tabeller verkar detta vara en svårgenomförbar uppgift.

En erfaren utvecklare vet såklart hur man åtgärdar de ovan nämnda problemen, men enligt min mening är det en erfaren analytikers uppgift att förhindra att de uppstår.

Jag vill uttrycka mitt tack för den värdefulla feedbacken vid förberedelsen av publikationen till huvudutvecklaren Evgenij Jaruhin.