🎅 🕗 🚚 Denormalisierung von ERP-Datenbanksystemen und ihre Auswirkungen auf die Softwareentwicklung: Eröffnung einer Taverne auf Tortuga 🔝 ☕️ 👩🏾‍🔬

Hallo! Mein Name ist Andrey Semenov, ich bin Senior Analyst bei Sportmaster. In diesem Beitrag möchte ich das Problem der Denormalisierung von ERP-Datenbanksystemen ansprechen. Wir werden die allgemeinen Bedingungen sowie ein konkretes Beispiel betrachten - sagen wir, es wird eine wunderbare Monopol-Taverne für Piraten und Seeleute sein. In denen Piraten und Seeleute unterschiedlich bedient werden müssen, weil die Vorstellungen über die schönen und Konsummuster dieser guten Meister erheblich unterschiedlich sind.

Wie macht man alle glücklich? Wie kann man nicht verrückt werden, wenn man ein solches System entwirft und wartet? Was tun, wenn nicht nur bekannte Piraten und Seeleute in die Taverne kommen? Alles ist unter dem Schnitt. Aber lass uns in Ordnung gehen.

1. Einschränkungen und Annahmen

All dies gilt nur für relationale Datenbanken. Gut beleuchtet, auch im Internet, werden die Auswirkungen der Denormalisierung in Form von Anomalien der Modifikation, Löschung und Einfügung nicht berücksichtigt. Über den Umfang der Veröffentlichung hinaus gibt es noch Fälle, in denen eine Denormalisierung mit klassischen Beispielen an der Tagesordnung ist: Serien- und Passnummer, Datum und Uhrzeit usw.

Der Beitrag verwendet intuitive und praktisch anwendbare Definitionen von Normalformen ohne Bezugnahme auf mathematische Begriffe. In der Form, in der sie zur Untersuchung realer Geschäftsprozesse (BP) und zum Entwurf industrieller Software eingesetzt werden können.

Es besteht die Ansicht, dass sich der Entwurf von Data Warehouses, Berichterstellungstools und Integrationsvereinbarungen (die eine tabellarische Darstellung von Informationen verwenden) vom Entwurf von ERP-Datenbanksystemen darin unterscheidet, dass die Benutzerfreundlichkeit und die Anwendung einer bewussten Denormalisierung Vorrang vor dem Integritätsschutz haben können Daten. Ich teile diese Meinung und die folgende Beschreibung gilt ausschließlich für Stammdatenmodelle und Transaktionsdaten von ERP-Systemen.

Die Erklärung normaler Formen wird anhand eines Beispiels gegeben, das für die meisten Leser auf Haushaltsebene verständlich ist. Zur Veranschaulichung wurde in den Absätzen 4 bis 5 jedoch bewusst die hervorgehobene „erfundene“ Aufgabe verwendet. Wenn Sie dies nicht tun und ein Lehrbuchbeispiel nehmen, beispielsweise dasselbe Modell der Auftragsspeicherung aus Abschnitt 2, befinden Sie sich möglicherweise in einer Situation, in der die Aufmerksamkeit des Lesers von der vorgeschlagenen Zerlegung des Prozesses in ein Modell auf die persönliche Erfahrung und Wahrnehmung dessen verlagert wird Prozesse und Modelle der Datenspeicherung in IP sollten erstellt werden. Mit anderen Worten, nehmen Sie zwei qualifizierte IT-Analysten, lassen Sie einen Dienstleistungen für Logistiker erbringen, die Passagiere transportieren, und den anderen für Logistiker, die Maschinen für die Herstellung von Mikrochips transportieren. Bitten Sie sie, ohne über vorautomatisierte BP zu sprechen, ein Datenmodell zum Speichern von Informationen über den Eisenbahnflug zu erstellen.

Es besteht eine Wahrscheinlichkeit ungleich Null, dass Sie in den vorgeschlagenen Modellen nicht nur einen merklich unterschiedlichen Satz von Attributen finden, sondern auch unterschiedliche Sätze von Entitäten, da sich jeder Analyst auf seine üblichen Prozesse und Aufgaben verlässt. Und in einer solchen Situation zu sagen, welches Modell „richtig“ ist, ist unmöglich, weil es kein Bewertungskriterium gibt.

2. Normalformen

Die erste Normalform der Datenbank erfordert die Atomizität aller Attribute.
Insbesondere wenn Objekt A Nichtschlüsselattribute a und b hat, so dass c = f (a, b) und in der Tabelle, die Objekt A beschreibt, Sie den Wert von Attribut c speichern, wird die erste Normalform in der Datenbank verletzt. Wenn in der Auftragsspezifikation beispielsweise die Menge angegeben ist, deren Maßeinheiten von der Art des Produkts abhängen: In einem Fall können es Teile sein, in den anderen Litern im dritten Paket, die aus Teilen bestehen (im Modell über Good_count_WR), wird die Atomizität der Attribute in der Datenbank verletzt. In diesem Fall benötigen Sie eine gezielte Beschreibung des Arbeitsprozesses in der IP, um zu sagen, wie der Busch der Tabellen für die Auftragsspezifikation aussehen soll. Da die Prozesse unterschiedlich sein können, kann es viele „richtige“ Versionen geben.

Die zweite Normalform der Datenbankerfordert die Einhaltung des ersten Formulars und einer eigenen Tabelle für jede Entität, die sich auf den Prozess der Arbeit in IP bezieht. Wenn in einer Tabelle Abhängigkeiten c = f1 (a) und d = f2 (b) vorhanden sind und keine Abhängigkeit c = f3 (b) vorliegt, wird die zweite Normalform in der Tabelle verletzt. Im obigen Beispiel besteht in der Tabelle "Bestellung" keine Beziehung zwischen der Bestellung und der Adresse. Wenn Sie den Namen der Straße oder Stadt ändern, erhalten Sie keinen Einfluss auf die wesentlichen Attribute der Bestellung.

Die dritte Normalform der Datenbankerfordert die Einhaltung der zweiten Normalform und das Fehlen funktionaler Abhängigkeiten zwischen Attributen verschiedener Entitäten. Diese Regel kann wie folgt formuliert werden: "Alles, was berechnet werden kann, muss berechnet werden." Mit anderen Worten, wenn es zwei Objekte A und B gibt. In der Tabelle, in der die Attribute von Objekt A gespeichert sind, wird Attribut C angezeigt, Objekt B hat Attribut b, so dass c = f4 (b) existiert, dann wird die dritte Normalform verletzt. Im folgenden Beispiel behauptet das Attribut "Anzahl der Teile" (Total_count_WR) im Auftragsdatensatz eindeutig, die dritte Normalform zu verletzen

3. Mein Ansatz zur Anwendung der Normalisierung

1. Nur der automatisierte Zielgeschäftsprozess kann Analysen mit Kriterien zum Identifizieren von Entitäten und Attributen beim Erstellen eines Datenspeichermodells bereitstellen. Das Erstellen eines Prozessmodells ist eine Voraussetzung für das Erstellen eines normalen Datenmodells.

2. Das Erreichen der dritten Normalform im engeren Sinne kann in der tatsächlichen Praxis der Erstellung von ERP-Systemen unpraktisch sein, wenn einige oder alle der folgenden Bedingungen erfüllt sind:

automatisierte Prozesse können sich nur selten ändern.
Forschungs- und Entwicklungsfristen sind eng,
Die Anforderungen an die Datenintegrität sind relativ gering (potenzielle Fehler in industrieller Software führen nicht zum Verlust von Geld oder Kunden durch den Softwarekunden).
usw.

Unter den beschriebenen Bedingungen sind die Kosten für die Identifizierung, eine Beschreibung des Lebenszyklus einiger Objekte und ihrer Eigenschaften unter dem Gesichtspunkt der Wirtschaftlichkeit möglicherweise nicht gerechtfertigt.

3. Alle Konsequenzen der Denormalisierung des Datenmodells in der bereits erstellten IP können durch eine gründliche vorläufige Untersuchung des Codes und Tests gestoppt werden.

4. Denormalisierung ist eine Möglichkeit, die Arbeitskosten von der Recherche nach Datenquellen und der Gestaltung eines Geschäftsprozesses in die Entwicklungsphase von der Implementierungsphase bis zur Entwicklungsphase des Systems zu übertragen.

5. Es ist ratsam, nach der dritten Normalform der Datenbank zu streben, wenn:

Die Richtung der Änderung in automatisierten Geschäftsprozessen ist schwer vorherzusagen
Innerhalb des Implementierungs- und / oder Entwicklungsteams besteht eine durchlässige Arbeitsteilung
Die in der Integrationsschaltung enthaltenen Systeme entwickeln sich nach ihren eigenen Plänen.
Dateninkonsistenzen können zum Verlust von Kunden oder Geld durch das Unternehmen führen

6. Der Entwurf des Datenmodells sollte vom Analysten nur in Verbindung mit den Modellen des Zielgeschäftsprozesses und des Prozesses in IP durchgeführt werden. Wenn ein Entwickler ein Datenmodell entwirft, muss er so weit in den Themenbereich eintauchen, dass er insbesondere den Unterschied zwischen Attributwerten verstehen muss - eine notwendige Bedingung für die Unterscheidung atomarer Attribute. So übernehmen ungewöhnliche Funktionen.

4 Aufgabe zur Veranschaulichung

Angenommen, Sie haben eine kleine Robotertaverne im Hafen. Ihr Marktsegment: Seeleute und Piraten, die im Hafen anrufen und eine Pause brauchen. Für Seeleute verkaufen Sie Tee mit Thymian und für Piraten, Rum und Knochenkämme zum Kämmen Ihres Bartes. Der Service in der Taverne selbst wird von einem Hostessenroboter und einem Barkeeper-Roboter erbracht. Aufgrund der hohen Qualität und der niedrigen Preise haben Sie alle Ihre Konkurrenten verdrängt, sodass jeder, der das Schiff verlässt, zu Ihrer Taverne kommt, die die einzige im Hafen ist.

Der Komplex der Taverneninformationssysteme besteht aus folgender Software:

Client-Frühwarnsystem, das seine Kategorie anhand charakteristischer Merkmale erkennt
Managementsystem für Hostessenroboter und Barkeeperroboter
Lager- und Lieferortverwaltungssystem
Supplier Relationship Management System (SMSS)

Prozess:

Das Frühwarnsystem erkennt Personen, die das Schiff verlassen. Wenn eine Person glatt rasiert ist, definiert sie sie als Seemann. Wenn in einer Person ein Bart gefunden wird, wird sie als Pirat definiert.

Beim Betreten der Taverne hört der Gast eine Begrüßung des Hostessenroboters gemäß seiner Kategorie, zum Beispiel: „Ho-ho-ho, lieber Pirat, gehe zu Tisch Nr. ...“ Der

Gast geht zu dem angegebenen Tisch, auf den sich der Roboter-Barkeeper bereits vorbereitet hat ihm Waren nach Kategorie. Der Barkeeper-Roboter überträgt Informationen an das Lagersystem, dass der nächste Teil der Lieferung erhöht werden soll. Der Lager-IS bildet basierend auf dem verbleibenden Speicher eine Anwendung für den Kauf im Steuerungssystem.

Lassen Sie Ihre interne IT ein Frühwarnsystem entwickeln, einen externen Auftragnehmer, der speziell für Ihr Unternehmen entwickelt wurde, um ein Barroboter-Managementprogramm zu erstellen. Und Systeme für die Lagerverwaltung und Lieferantenbeziehungen sind maßgeschneiderte Box-Lösungen vom Markt.

5. Beispiele für Denormalisierung und ihre Auswirkungen auf die Softwareentwicklung

Bei der Gestaltung eines Geschäftsprozesses erklärten befragte Fachexperten einstimmig, dass Piraten auf der ganzen Welt Rum trinken und ihre Bärte mit Knochenkämmen kämmen, und Seeleute Tee mit Thymian trinken und immer glatt rasiert werden.

Ein Verzeichnis von Kundentypen wird aus zwei Werten angezeigt: 1 - Piraten, 2 - Seeleute, die dem gesamten Informationskreis des Unternehmens gemeinsam sind.

Das Kundenbenachrichtigungssystem speichert das Bildverarbeitungsergebnis sofort als Kennung (ID) des erkannten Kunden und dessen Typ: Seemann oder Pirat.

Erkannte Objekt-ID	Kundenkategorie
100500	Pirat
100501	Pirat
100502	Seemann

Wir stellen noch einmal fest, dass

1. unsere Seeleute tatsächlich rasierte Menschen sind
2. unsere Piraten tatsächlich bärtige Menschen sind

Welche Probleme in diesem Fall müssen angegangen werden, damit unsere Struktur nach einer dritten Normalform strebt:

Attribut Atomverletzung - Client-Kategorie
Mischen der analysierten Tatsache und Schlussfolgerung in einer Tabelle
feste funktionale Beziehung zwischen Attributen verschiedener Entitäten.

In normalisierter Form würden wir zwei Tabellen erhalten:

Erkennungsergebnis in Form einer Reihe von etablierten Merkmalen,

Erkannte Objekt-ID	Gesichtsbehaarung
100500	Ja
100501	Ja
100502	Nein

das Ergebnis der Bestimmung des Client-Typs als Anwendung der im IS eingebetteten Logik zur Interpretation etablierter Zeichen

Erkannte Objekt-ID	Identifikations-ID	Kundenkategorie
100500	100001	Pirat
100501	100002	Pirat
100502	100003	Seemann

Wie kann eine normalisierte Speicherorganisation die Entwicklung eines IP-Komplexes erleichtern? Nehmen wir an, Sie haben plötzlich neue Kunden. Lassen Sie es japanische Piraten sein, die vielleicht keinen Bart haben, aber mit einem Papagei auf den Schultern laufen, und Umweltpiraten, die Sie leicht am blauen Profil von Greta auf der linken Brust erkennen können.

Umweltpiraten können natürlich keine Knochenkämme verwenden und benötigen ein Analogon aus recyceltem Meereskunststoff.

Sie müssen die Algorithmen der Programme gemäß der neuen Einführung überarbeiten. Wenn die Normalisierungsregeln erfüllt wären, müssten Sie nur Eingaben für einige Prozesszweige hinzufügen und neue Zweige nur für die Fälle und in den IPs erstellen, in denen der Haaransatz im Gesicht wichtig ist. Da die Regeln jedoch nicht befolgt wurden, müssen Sie den gesamten Code in der gesamten Schaltung analysieren, in der die Werte des Verzeichnisses der Clienttypen verwendet werden, und eindeutig festlegen, dass der Algorithmus in einem Fall die beruflichen Aktivitäten des Clients und in den anderen physischen Merkmalen berücksichtigen sollte.

In einer Ansicht, die zur Normalisierung neigt , würden wir zwei Tabellen mit Betriebsdaten und zwei Verzeichnisse erhalten:

Erkennungsergebnis in Form einer Reihe von etablierten Merkmalen,


100510	1	1	1
100511	0	0	1
100512		1	0

( , )

Bedeutet die festgestellte Denormalisierung, dass die Systeme unter neuen Bedingungen nicht modifiziert werden können? Natürlich nicht. Wenn Sie sich vorstellen, dass alle IPs von einem Team ohne Fluktuation erstellt wurden, die Entwicklungen gut dokumentiert sind und die Informationen im Team ohne Verlust übertragen werden, können die erforderlichen Änderungen Produkte mit vernachlässigbar geringem Aufwand sein. Wenn wir jedoch zu den Anfangsbedingungen der Aufgabe zurückkehren, werden nur 1,5 Tastaturen und weitere 0,5 für die Registrierung von Beschaffungsverfahren nur zum Drucken von Protokollen gemeinsamer Diskussionen gelöscht.

Im obigen Beispiel werden alle drei Normalformen verletzt. Versuchen wir, sie einzeln zu verletzen.

Verletzung der ersten Normalform:

Angenommen, die Waren werden auf eigene Kosten aus den Lagern der Lieferanten mit einer 1,5-Tonnen-Gazelle, die zu Ihrer Taverne gehört, in Ihr Lager geliefert. Die Größe Ihrer Bestellungen ist im Verhältnis zum Umsatz der Lieferanten so gering, dass sie immer eins zu eins ausgeführt werden, ohne auf die Produktion zu warten. Benötigen Sie separate Tabellen für ein solches Netzteil: Fahrzeuge, Fahrzeugtypen, müssen Sie den Plan und die Tatsache in Ihren Bestellungen an abgereiste Lieferanten trennen?

Stellen Sie sich vor, wie viele zusätzliche Verbindungen Ihre Programmierer schreiben müssen, wenn Sie das folgende Modell zum Entwickeln eines Programms verwenden.

Angenommen, wir haben die Entscheidung getroffen, dass die vorgeschlagene Struktur unnötig kompliziert ist. In unserem Fall sind die Trennung des Plans und die Tatsache im Auftragsdatensatz redundante Informationen, und die generierte Auftragsspezifikation wird durch die Ergebnisse der Annahme der angekommenen Waren überschrieben. Seltenes Umsortieren und Eintreffen von Waren von unzureichender Qualität werden außerhalb des IP abgewickelt.
Und dann sehen Sie eines Tages, wie die gesamte Tavernenhalle voller empörter und ungepflegter Piraten ist. Was ist passiert?

Es stellte sich heraus, dass mit dem Wachstum Ihres Unternehmens auch der Verbrauch zunahm. Einmal wurde eine Managemententscheidung getroffen, dass der Lieferant bei einer Überladung einer Gazelle in Bezug auf Volumen und / oder Gewicht, was äußerst selten war, die Verladung zugunsten von Getränken priorisierte.

Nicht gelieferte Waren fielen in die nächste Bestellung und flogen zu einem neuen Flug ab. Das Vorhandensein eines nicht reduzierbaren Guthabens im Lager der Taverne ermöglichte es, durchstochene Fälle nicht zu bemerken.

Der letzte Konkurrent, der im Hafen geschlossen wurde, und der durchstochene Gazellenüberlastungsfall, der durch Priorisierung umgangen wurde, basierend auf der Annahme, dass das Mindestgleichgewicht und die periodische Unterladung des Fahrzeugs ausreichen, wurden zur gängigen Praxis. Das erstellte System funktioniert idealerweise in Übereinstimmung mit den darin festgelegten Algorithmen und es wird ihm keine Möglichkeit genommen, die systematische Nichterfüllung geplanter Aufträge zu verfolgen. Nur ein beschädigter Ruf und unzufriedene Kunden können das Problem erkennen.

Ein aufmerksamer Leser muss bemerkt haben, dass die bestellte Menge in der Bestellspezifikation (T_ORDER_SPEC) in Abschnitt 2 und Abschnitt 5 möglicherweise die Anforderungen der ersten Normalform erfüllt oder nicht. Es hängt alles davon ab, ob für ein ausgewähltes Warensortiment wesentlich unterschiedliche Maßeinheiten in dasselbe Feld fallen können.

Verletzung der zweiten Normalform:

Wenn Ihre Bedürfnisse wachsen, erhalten Sie ein paar weitere Fahrzeuge unterschiedlicher Größe. In diesem Zusammenhang wurde die Erstellung eines Fahrzeugverzeichnisses als redundant angesehen. Infolgedessen empfinden alle Datenmanipulationsalgorithmen, die den Anforderungen der Lieferung und des Lagers entsprechen, den Warenverkehr vom Lieferanten zum Lager als ausschließlich 1,5-Tonnen-Gazellenflug. Zusammen mit dem Kauf neuer Fahrzeuge erstellen Sie also immer noch ein Fahrzeugverzeichnis. Bei der Fertigstellung müssen Sie jedoch den gesamten Code analysieren, der sich auf die Bewegung der Ladung bezieht, um herauszufinden, ob Verweise auf die Merkmale des Fahrzeugs, aus dem das Fahrzeug stammt Geschäft begann.

Verletzung der dritten Normalform:

Irgendwann beginnen Sie mit der Erstellung eines Treueprogramms. Ein regulärer Kundendatensatz wird angezeigt. Warum zum Beispiel Zeit damit verbringen, Materialdarstellungen zu erstellen, in denen aggregierte Verkaufsdaten für einen einzelnen Kunden gespeichert werden, um sie für die Berichterstellung und Übertragung an Analysesysteme zu verwenden, wenn zu Beginn des Treueprogramms alles, was den Kunden interessiert, in die eigenen Unterlagen des Kunden aufgenommen werden kann? Und tatsächlich macht es auf den ersten Blick keinen Sinn. Aber jedes Mal, wenn Ihr Unternehmen beispielsweise neue Vertriebskanäle verbindet, sollte sich unter Ihren Analysten jemand befinden, der sich daran erinnert, dass es ein solches Aggregationsattribut gibt.

Bei der Gestaltung jedes neuen Prozesses, z. B. beim Verkauf im Internet oder beim Verkauf über Distributoren, die mit einem gemeinsamen Loyalitätssystem verbunden sind, sollte jemand berücksichtigen, dass alle neuen Prozesse die Datenintegrität auf Codeebene sicherstellen sollten. Für eine industrielle Datenbank mit tausend Tabellen scheint dies eine unmögliche Aufgabe zu sein.

Ein erfahrener Entwickler weiß natürlich, wie er alle oben genannten Probleme stoppen kann, aber meiner Meinung nach besteht die Aufgabe eines erfahrenen Analysten nicht darin, sie darauf aufmerksam zu machen.

Ich möchte dem führenden Entwickler Evgeny Yarukhin für das wertvolle Feedback während der Vorbereitung der Veröffentlichung meinen Dank aussprechen.

Literatur

https://habr.com/de/post/254773/
Connolly Thomas, Begg Carolyn. Datenbank. Design, Implementierung und Wartung. Theorie und Praxis