Hallo! Mijn naam is Andrey Semenov, ik ben senior analist bij Sportmaster. In dit bericht wil ik de kwestie van de denormalisatie van ERP-systeemdatabases aan de orde stellen. We zullen kijken naar de algemene voorwaarden, maar ook naar een specifiek voorbeeld - laten we zeggen dat het een prachtige monopolie-taverne zou zijn voor piraten en matrozen. Waarin piraten en matrozen anders moeten worden bediend, omdat de ideeën over schoonheid en consumptiepatronen van deze goede heren aanzienlijk verschillen.
Hoe maak je iedereen blij? Hoe voorkom je dat je gek wordt bij het ontwerpen en onderhouden van zo’n systeem? Wat te doen als niet alleen de gebruikelijke piraten en matrozen naar de taverne komen?
Alles is onder de maat. Maar laten we in volgorde gaan.
1. Beperkingen en aannames
Al het bovenstaande is alleen van toepassing op relationele databases. Er wordt geen rekening gehouden met de gevolgen van denormalisatie in de vorm van wijzigings-, verwijderings- en invoegafwijkingen, die goed worden behandeld, ook op internet. Buiten het bestek van deze publicatie zijn er gevallen waarin denormalisatie gebruikelijk is, met klassieke voorbeelden: paspoortserie en -nummer, datum en tijd, enz.
De post maakt gebruik van intuïtieve en praktisch toepasbare definities van normale vormen, zonder verwijzing naar wiskundige termen. In de vorm waarin ze kunnen worden toegepast op het onderzoeken van echte bedrijfsprocessen (BP) en het ontwerpen van industriële software.
Er wordt betoogd dat het ontwerp van datawarehouses, rapportagetools en integratieovereenkomsten (die gebruik maken van tabellarische representaties van informatie) verschilt van het ontwerp van ERP-systeemdatabases doordat het gebruiksgemak en het gebruik van bewuste denormalisatie om dit te bereiken voorrang kunnen hebben op integriteit. bescherming gegevens. Ik deel deze mening, en wat hieronder wordt beschreven geldt uitsluitend voor de masterdata en transactionele datamodellen van ERP-systemen.
Een uitleg van normale vormen wordt gegeven aan de hand van een voorbeeld dat voor de meeste lezers op het alledaagse niveau begrijpelijk is. Ter visuele illustratie werd in de paragrafen 4-5 echter opzettelijk een ‘fictieve’ taak gebruikt. Als u dit niet doet en een schoolvoorbeeld neemt, bijvoorbeeld hetzelfde orderopslagmodel uit punt 2, kunt u in een situatie terechtkomen waarin de aandacht van de lezer wordt verlegd van de voorgestelde ontleding van het proces naar een model. op persoonlijke ervaring en perceptie van hoe processen en modellen voor het opslaan van gegevens in IS moeten worden gebouwd. Met andere woorden, neem twee gekwalificeerde IT-analisten, laat de één diensten verlenen aan logistieke dienstverleners die passagiers vervoeren, en de andere aan logistieke dienstverleners die machines vervoeren voor de productie van microchips. Vraag hen, zonder vooraf over geautomatiseerde BP’s te praten, een datamodel te maken voor het opslaan van informatie over een treinreis.
De kans is niet nul dat u in de voorgestelde modellen niet alleen een merkbaar verschillende reeks attributen zult aantreffen, maar ook uiteenlopende reeksen entiteiten, omdat elke analist zal vertrouwen op de processen en taken die hem bekend zijn. En in zo’n situatie is het onmogelijk om te zeggen welk model ‘juist’ is, omdat er geen evaluatiecriterium is.
2. Normale vormen
Eerste normale vorm van de database vereist atomiciteit van alle attributen.
In het bijzonder, als object A niet-sleutelattributen a en b heeft, zodat c=f(a,b) en je in de tabel die object A beschrijft de waarde van attribuut c opslaat, dan wordt de eerste normaalvorm in de database geschonden. . Als de bestelspecificatie bijvoorbeeld een hoeveelheid aangeeft, waarvan de maateenheden afhankelijk zijn van het type product: in het ene geval kunnen het stuks zijn, in een ander liter, in een derde pakket bestaande uit stukjes (in het model hierboven Good_count_WR) , dan wordt de atomiciteit van attributen in de database geschonden. Om te zeggen wat het tabelcluster van de orderspecificatie zou moeten zijn, heeft u in dit geval een gerichte beschrijving van het werkproces in het IS nodig, en aangezien de processen verschillend kunnen zijn, kunnen er veel “correcte” versies zijn.
Tweede normale vorm van de database vereist naleving van het eerste formulier en een eigen tabel voor elke entiteit die verband houdt met het werkproces in de IS. Als er in één tabel afhankelijkheden c=f1(a) en d=f2(b) zijn en er is geen afhankelijkheid c=f3(b), dan wordt de tweede normaalvorm in de tabel geschonden. In het bovenstaande voorbeeld is er geen afhankelijkheid tussen bestelling en adres in de Besteltabel. Wijzig de straat- of plaatsnaam en u heeft geen invloed op de essentiële kenmerken van de bestelling.
Derde normaalvormdatabase vereist naleving van de tweede normaalvorm en de afwezigheid van functionele afhankelijkheden tussen attributen van verschillende entiteiten. Deze regel kan als volgt worden geformuleerd: “alles wat kan worden berekend, moet worden berekend.” Met andere woorden, als er twee objecten A en B zijn. In de tabel waarin de attributen van object A zijn opgeslagen, wordt attribuut C gemanifesteerd en heeft object B attribuut b, zodat c=f4(b) bestaat, dan is de derde normaalvorm wordt geschonden. In het onderstaande voorbeeld beweert het kenmerk Aantal stuks (Total_count_WR) in de orderrecord duidelijk de derde normale vorm te schenden
3. Mijn benadering van het toepassen van normalisatie
1. Alleen een geautomatiseerd doelbedrijfsproces kan de analist voorzien van criteria voor het identificeren van entiteiten en attributen bij het creëren van een gegevensopslagmodel. Het maken van een procesmodel is een voorwaarde voor het maken van een normaal datamodel.
2. Het bereiken van de derde normaalvorm in strikte zin kan in de praktijk van het creëren van ERP-systemen niet praktisch zijn als aan enkele of alle van de volgende voorwaarden wordt voldaan:
- geautomatiseerde processen zijn zelden aan verandering onderhevig,
- deadlines voor onderzoek en ontwikkeling zijn krap,
- vereisten voor data-integriteit zijn relatief laag (potentiële fouten in industriële software leiden niet tot verlies van geld of klanten door de softwareklant)
- etc.
Onder de beschreven omstandigheden zijn de kosten van het identificeren en beschrijven van de levenscyclus van sommige objecten en hun attributen mogelijk niet gerechtvaardigd vanuit het oogpunt van economische efficiëntie.
3. Eventuele gevolgen van de denormalisatie van het datamodel in een reeds gecreëerde IS kunnen worden verzacht door een grondige voorafgaande studie van de code en testen.
4. Denormalisatie is een manier om arbeidskosten over te dragen van de fase van het onderzoeken van databronnen en het ontwerpen van een bedrijfsproces naar de ontwikkelingsfase, van de implementatieperiode naar de periode van systeemontwikkeling.
5. Het is raadzaam om te streven naar de derde normaalvorm van een database als:
- De richting van verandering in geautomatiseerde bedrijfsprocessen is moeilijk te voorspellen
- Er is sprake van een zwakke taakverdeling binnen het implementatie- en/of ontwikkelteam
- Systemen die deel uitmaken van het integratiecircuit ontwikkelen zich volgens hun eigen plannen
- Inconsistentie van gegevens kan ertoe leiden dat een bedrijf klanten of geld verliest
6. Het ontwerp van een datamodel mag alleen door een analist worden uitgevoerd in verband met de modellen van het beoogde bedrijfsproces en het proces in de IS. Als een ontwikkelaar een datamodel ontwerpt, zal hij zich zodanig in het vakgebied moeten verdiepen dat hij met name het verschil tussen attribuutwaarden begrijpt – een noodzakelijke voorwaarde voor het isoleren van atomaire attributen. Dus ongebruikelijke functies op zich nemen.
4 Probleem ter illustratie
Laten we zeggen dat je een kleine robottaverne in de haven hebt. Jouw marktsegment: matrozen en piraten die de haven binnenkomen en een pauze nodig hebben. Je verkoopt thee met tijm aan zeelieden, en rum- en bottenkammen voor het kammen van baarden aan piraten. De bediening in de taverne zelf wordt verzorgd door een robothostess en een robotbarman. Dankzij je hoge kwaliteit en lage prijzen heb je je concurrenten verdreven, zodat iedereen die van het schip komt naar jouw taverne komt, de enige in de haven.
Het taverne-informatiesystemencomplex bestaat uit de volgende software:
- Een systeem voor vroegtijdige waarschuwing over een cliënt dat zijn categorie herkent op basis van karakteristieke kenmerken
- Besturingssysteem voor robothostesses en robotbartenders
- Magazijn- en leveringsbeheersysteem naar verkooppunt
- Leveranciersrelatiebeheersysteem (SURP)
proces:
Het vroegtijdige waarschuwingssysteem herkent mensen die het schip verlaten. Als een persoon gladgeschoren is, identificeert ze hem als een zeeman; als blijkt dat iemand een baard heeft, wordt hij geïdentificeerd als een piraat.
Bij het binnenkomen van de taverne hoort de gast een groet van de robot-gastvrouw in overeenstemming met zijn categorie, bijvoorbeeld: "Ho-ho-ho, beste piraat, ga naar tafel Nee..."
De gast gaat naar de aangegeven tafel, waar de robotbarman al goederen voor hem heeft klaargemaakt in overeenstemming met de categorie. De robotbarman geeft informatie door aan het magazijnsysteem dat het volgende deel van de levering moet worden verhoogd; het magazijn IS genereert, op basis van de resterende saldi in de opslag, een aankoopaanvraag in het managementsysteem.
Hoewel het systeem voor vroegtijdige waarschuwing mogelijk door uw interne IT is ontwikkeld, kan het beheerprogramma voor de barrobot speciaal voor uw bedrijf door een externe contractant zijn gemaakt. En systemen voor het beheer van magazijnen en relaties met leveranciers zijn maatwerkpakketoplossingen uit de markt.
5. Voorbeelden van denormalisatie en de impact ervan op softwareontwikkeling
Bij het ontwerpen van een bedrijfsproces stelden de geïnterviewde vakexperts unaniem dat piraten over de hele wereld rum drinken en hun baard kammen met bottenkammen, en zeelieden thee drinken met tijm en altijd gladgeschoren zijn.
Er verschijnt een lijst met klanttypen met twee waarden: 1 - piraten, 2 - matrozen, gebruikelijk voor het gehele informatiecircuit van het bedrijf.
Het cliëntmeldingssysteem slaat het resultaat van de beeldverwerking onmiddellijk op als identificatiemiddel (ID) van de herkende cliënt en zijn type: zeeman of piraat.
Herkende object-ID
Klantcategorie
100500
Piraat
100501
Piraat
100502
zeeman
Laten we dat nog eens opmerken
1. Onze matrozen zijn eigenlijk geschoren mensen
2. Onze piraten zijn eigenlijk bebaarde mensen
Welke problemen moeten in dit geval worden geëlimineerd, zodat onze structuur streeft naar de derde normaalvorm:
- attribuut atomiciteitsschending - Klantcategorie
- het combineren van het geanalyseerde feit en de conclusie in één tabel
- vaste functionele relatie tussen attributen van verschillende entiteiten.
In genormaliseerde vorm zouden we twee tabellen krijgen:
- herkenningsresultaat in de vorm van een reeks gevestigde kenmerken,
Herkende object-ID
Gezichtshaar
100500
Ja
100501
Ja
100502
Geen
- het resultaat van het bepalen van het type cliënt als een toepassing van de logica die in de IS is ingebed om de vastgestelde kenmerken te interpreteren
Herkende object-ID
Identificatie-ID
Klantcategorie
100500
100001
Piraat
100501
100002
Piraat
100502
100003
zeeman
Hoe kan een genormaliseerde dataopslagorganisatie de ontwikkeling van een IP-complex faciliteren? Stel dat u plotseling nieuwe klanten krijgt. Laat het Japanse piraten zijn die misschien geen baard hebben, maar wel met een papegaai op hun schouder lopen, en milieuactivisten, je herkent ze gemakkelijk aan Greta’s blauwe profiel op de linkerborst.
Milieupiraten kunnen uiteraard geen bottenkammen gebruiken en eisen een analoog gemaakt van gerecycled zeeplastic.
U moet de programma-algoritmen herwerken in overeenstemming met de nieuwe invoer. Als de normalisatieregels zouden worden gevolgd, zou u in sommige systemen alleen de invoer voor sommige procestakken hoeven aan te vullen en alleen nieuwe vertakkingen hoeven te maken voor die gevallen en in die IS's waar gezichtshaar ertoe doet. Maar omdat de regels niet zijn gevolgd, zul je de hele code moeten analyseren, door het hele circuit, waar de waarden van de clienttypedirectory worden gebruikt, en duidelijk moeten vaststellen dat het algoritme in één geval rekening moet houden met de professionele activiteit van de cliënt, en in de andere fysieke kenmerken.
In een vorm die zoekt om te normaliseren zouden we twee tabellen krijgen met operationele gegevens en twee mappen:
- herkenningsresultaat in de vorm van een reeks gevestigde kenmerken,
Herkende object-ID
Greta op de linkerborst
Vogel op de schouder
Gezichtshaar
100510
1
1
1
100511
0
0
1
100512
1
0
- het resultaat van het bepalen van het clienttype (laat het een aangepaste weergave zijn waarin beschrijvingen uit mappen worden weergegeven)
Betekent de gedetecteerde denormalisatie dat de systemen niet kunnen worden aangepast om aan nieuwe omstandigheden te voldoen? Natuurlijk niet. Als we ons voorstellen dat alle informatiesystemen zijn gecreëerd door één team zonder personeelsverloop, de ontwikkelingen goed gedocumenteerd zijn en informatie binnen het team zonder verlies wordt overgedragen, dan kunnen de vereiste veranderingen met verwaarloosbaar weinig moeite worden doorgevoerd. Maar als we terugkeren naar de oorspronkelijke omstandigheden van het probleem, zullen 1,5 toetsenborden worden gewist alleen voor het afdrukken van protocollen van gezamenlijke besprekingen en nog eens 0,5 voor het verwerken van aanbestedingsprocedures.
In het bovenstaande voorbeeld worden alle drie de normale vormen geschonden, laten we proberen ze afzonderlijk te schenden.
Overtreding van de eerste normaalvorm:
Stel dat goederen bij uw magazijn worden afgeleverd vanuit de magazijnen van de leverancier door ze op te halen met behulp van een gazelle van 1.5 ton die bij uw taverne hoort. De omvang van uw orders is zo klein in verhouding tot de omzet van de leveranciers, dat deze altijd één-op-één worden afgehandeld zonder te wachten op productie. Heeft u bij zo’n bedrijfsproces aparte tabellen nodig: voertuigen, typen voertuigen, is het nodig om plan en feit gescheiden te houden in uw bestellingen aan vertrekkende leveranciers?
Stelt u zich eens voor hoeveel “extra” verbindingen uw programmeurs zullen moeten schrijven als u onderstaand model gebruikt om een programma te ontwikkelen.
Laten we zeggen dat we hebben besloten dat de voorgestelde structuur onnodig complex is; in ons geval is het scheiden van het plan en het feit in het orderrecord overbodige informatie, en wordt de gegenereerde orderspecificatie herschreven op basis van de resultaten van de acceptatie van de aangekomen goederen, zeldzame fouten. -sortering en aankomst van goederen van onvoldoende kwaliteit worden buiten de IS afgehandeld.
En dan zie je op een dag hoe de hele herbergzaal gevuld is met verontwaardigde en onverzorgde piraten. Wat is er gebeurd?
Het blijkt dat naarmate uw bedrijf groeide, uw verbruik ook groeide. Er was eens een managementbeslissing dat als een gazelle te veel volume en/of gewicht had, wat uiterst zeldzaam was, de leverancier voorrang zou geven aan de lading ten gunste van dranken.
De niet-geleverde goederen kwamen in de volgende bestelling terecht en vertrokken op een nieuwe vlucht; de aanwezigheid van een minimaal saldo in het magazijn van de taverne maakte het mogelijk om ontbrekende gevallen niet op te merken.
De laatste concurrent sloot de haven af, en het lekke geval van overbelasting van de gazelle, omzeild door prioriteiten te stellen op basis van de veronderstelling dat het minimumevenwicht en de periodieke onderbelasting van het voertuig toereikend waren, werd een gangbare praktijk. Het gecreëerde systeem zal idealiter werken in overeenstemming met de algoritmen die erin zijn ingebed en zal elke mogelijkheid worden ontnomen om de systematische mislukking van de uitvoering van geplande bestellingen te volgen. Alleen een beschadigde reputatie en ontevreden klanten zullen het probleem kunnen ontdekken.
Het is een oplettende lezer wellicht opgevallen dat de bestelde hoeveelheid in de orderspecificatie (T_ORDER_SPEC) in sectie 2 en sectie 5 al dan niet voldoet aan de eis van eerste normaalvorm. Het hangt er allemaal van af of, gegeven het geselecteerde goederenassortiment, wezenlijk verschillende meeteenheden in hetzelfde veld kunnen vallen.
Overtreding van de tweede normaalvorm:
Naarmate uw behoeften toenemen, koopt u nog een paar voertuigen van verschillende groottes. In de bovenstaande context werd het aanmaken van een voertuiggids als overbodig beschouwd; als gevolg daarvan beschouwen alle gegevensverwerkingsalgoritmen die de behoeften van de levering en het magazijn dienen, de verplaatsing van vracht van de leverancier naar het magazijn als de vlucht van een exclusief 1,5 ton wegende vrachtauto. gazelle. Dus, samen met de aankoop van nieuwe voertuigen, maakt u nog steeds een voertuiglijst aan, maar wanneer u deze voltooit, zult u alle code moeten analyseren die verwijst naar de vrachtbeweging om erachter te komen of er op elke specifieke plaats verwijzingen naar de kenmerken worden geïmpliceerd. van het voertuig waarmee het bedrijf begon.
Overtreding van de derde normaalvorm:
Op een gegeven moment begin je met het maken van een loyaliteitsprogramma, er verschijnt een record van een vaste klant. Waarom bijvoorbeeld tijd besteden aan het creëren van materiële overzichten waarin geaggregeerde gegevens over verkopen aan een individuele klant worden opgeslagen voor gebruik bij rapportage en overdracht naar analytische systemen, als aan het begin van een loyaliteitsprogramma alles wat de klant interesseert in het dossier van de klant kan worden geplaatst? ? En inderdaad, op het eerste gezicht heeft het geen zin. Maar elke keer dat uw bedrijf bijvoorbeeld nieuwe verkoopkanalen verbindt, moet er iemand onder uw analisten zijn die zich zal herinneren dat een dergelijk aggregatie-attribuut bestaat.
Bij het ontwerpen van elk nieuw proces, bijvoorbeeld verkoop op internet of verkoop via distributeurs die zijn aangesloten op een gemeenschappelijk loyaliteitssysteem, moet iemand in gedachten houden dat alle nieuwe processen de gegevensintegriteit op codeniveau moeten garanderen. Voor een industriële database met duizend tabellen lijkt dit een onmogelijke opgave.
Een ervaren ontwikkelaar weet natuurlijk alle bovengenoemde problemen te stoppen, maar naar mijn mening is het niet de taak van een ervaren analist om ze aan het licht te brengen.
Ik wil mijn dank uitspreken aan de toonaangevende ontwikkelaar Evgeniy Yarukhin voor zijn waardevolle feedback tijdens de voorbereiding van de publicatie.
Literatuur
Connolly Thomas, Begg Caroline. Database. Ontwerp, implementatie en ondersteuning. Theorie en praktijk
Bron: www.habr.com