Hallo! Mein Name ist Andrey Semenov, ich bin Senior Analyst bei Sportmaster. In diesem Beitrag möchte ich das Problem der Denormalisierung von ERP-Systemdatenbanken ansprechen. Wir werden uns die allgemeinen Bedingungen sowie ein konkretes Beispiel ansehen – sagen wir, es wäre eine wunderbare Monopol-Taverne für Piraten und Seeleute. Dabei müssen Piraten und Matrosen unterschiedlich bedient werden, denn die Schönheitsvorstellungen und Konsumgewohnheiten dieser braven Herren unterscheiden sich erheblich.
Wie kann man alle glücklich machen? Wie können Sie vermeiden, bei der Entwicklung und Wartung eines solchen Systems verrückt zu werden? Was tun, wenn nicht nur die üblichen Piraten und Seeleute in die Taverne kommen?
Alles ist unter dem Schnitt. Aber gehen wir der Reihe nach vor.
1. Einschränkungen und Annahmen
Alle oben genannten Punkte gelten nur für relationale Datenbanken. Die Folgen der Denormalisierung in Form von Änderungs-, Lösch- und Einfügungsanomalien, über die auch im Internet ausführlich berichtet wird, werden nicht berücksichtigt. Außerhalb des Rahmens dieser Veröffentlichung gibt es Fälle, in denen eine Denormalisierung häufig vorkommt, mit klassischen Beispielen: Passserie und -nummer, Datum und Uhrzeit usw.
Der Beitrag verwendet intuitive und praktisch anwendbare Definitionen von Normalformen, ohne Bezug auf mathematische Begriffe. In der Form, in der sie auf die Untersuchung realer Geschäftsprozesse (BP) und die Gestaltung industrieller Software anwendbar sind.
Es wird argumentiert, dass sich das Design von Data Warehouses, Reporting-Tools und Integrationsvereinbarungen (die tabellarische Darstellungen von Informationen verwenden) vom Design von ERP-Systemdatenbanken dadurch unterscheidet, dass die einfache Nutzung und der Einsatz bewusster Denormalisierung zu ihrer Erreichung Vorrang vor der Integrität haben können Schutzdaten. Ich teile diese Meinung und das, was im Folgenden beschrieben wird, gilt ausschließlich für die Stammdaten- und Transaktionsdatenmodelle von ERP-Systemen.
Die Erläuterung der Normalformen erfolgt anhand eines Beispiels, das für die meisten Leser auf Alltagsebene verständlich ist. Zur visuellen Veranschaulichung wurde jedoch in den Absätzen 4-5 bewusst eine bewusst „fiktive“ Aufgabe verwendet. Wenn Sie dies nicht tun und ein Lehrbuchbeispiel verwenden, zum Beispiel das gleiche Auftragsspeichermodell aus Punkt 2, geraten Sie möglicherweise in eine Situation, in der der Fokus des Lesers von der vorgeschlagenen Zerlegung des Prozesses in ein Modell verlagert wird. auf persönliche Erfahrung und Wahrnehmung, wie Prozesse und Modelle zur Datenspeicherung im IS aufgebaut sein müssen. Mit anderen Worten: Nehmen wir zwei qualifizierte IT-Analysten, der eine erbringt Dienstleistungen für Logistiker, die Passagiere befördern, der andere für Logistiker, die Maschinen zur Herstellung von Mikrochips transportieren. Bitten Sie sie, ohne vorher über automatisierte BPs zu sprechen, ein Datenmodell zum Speichern von Informationen über eine Bahnfahrt zu erstellen.
Es besteht eine Wahrscheinlichkeit ungleich Null, dass Sie in den vorgeschlagenen Modellen nicht nur einen deutlich unterschiedlichen Satz von Attributen finden, sondern auch divergierende Sätze von Entitäten, da sich jeder Analyst auf die ihm vertrauten Prozesse und Aufgaben verlässt. Und in einer solchen Situation ist es unmöglich zu sagen, welches Modell „richtig“ ist, da es kein Bewertungskriterium gibt.
2. Normalformen
Erste Normalform der Datenbank erfordert Atomizität aller Attribute.
Insbesondere wenn Objekt A Nicht-Schlüsselattribute a und b hat, also c=f(a,b) und Sie in der Tabelle, die Objekt A beschreibt, den Wert des Attributs c speichern, dann ist die erste Normalform in der Datenbank verletzt . Wenn beispielsweise in der Bestellspezifikation eine Menge angegeben ist, deren Maßeinheiten von der Art des Produkts abhängen: In einem Fall können es Stücke sein, in einem anderen Fall Liter, in einem dritten Pakete, die aus Stücken bestehen (im Modell oben Good_count_WR) , dann wird die Atomizität der Attribute in der Datenbank verletzt. Um in diesem Fall sagen zu können, wie der Tabellencluster der Auftragsspezifikation aussehen soll, bedarf es einer gezielten Beschreibung des Arbeitsprozesses im IS, und da die Prozesse unterschiedlich sein können, kann es viele „richtige“ Versionen geben.
Zweite Normalform der Datenbank erfordert die Einhaltung des ersten Formulars und einer eigenen Tabelle für jede Entität, die sich auf den Arbeitsprozess im IS bezieht. Wenn es in einer Tabelle Abhängigkeiten c=f1(a) und d=f2(b) gibt und es keine Abhängigkeit c=f3(b) gibt, dann ist die zweite Normalform in der Tabelle verletzt. Im obigen Beispiel besteht keine Abhängigkeit zwischen Bestellung und Adresse in der Tabelle „Bestellung“. Wenn Sie den Straßen- oder Ortsnamen ändern, haben Sie keinen Einfluss auf die wesentlichen Merkmale der Bestellung.
Dritte Normalformdatenbank erfordert die Einhaltung der zweiten Normalform und das Fehlen funktionaler Abhängigkeiten zwischen Attributen verschiedener Entitäten. Diese Regel lässt sich wie folgt formulieren: „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, ist Attribut C manifestiert, und Objekt B hat Attribut b, sodass c = f4 (b) existiert, dann die dritte Normalform wird verletzt. Im folgenden Beispiel behauptet das Attribut „Stückzahl“ (Total_count_WR) im Bestelldatensatz eindeutig, dass es gegen die dritte Normalform verstößt
3. Mein Ansatz zur Anwendung der Normalisierung
1. Nur ein gezielter automatisierter Geschäftsprozess kann dem Analysten Kriterien zur Identifizierung von Entitäten und Attributen bei der Erstellung eines Datenspeichermodells liefern. Die Erstellung eines Prozessmodells ist Voraussetzung für die Erstellung eines normalen Datenmodells.
2. Das Erreichen der dritten Normalform im engeren Sinne ist in der tatsächlichen Praxis der Erstellung von ERP-Systemen möglicherweise nicht praktikabel, wenn einige oder alle der folgenden Bedingungen erfüllt sind:
- automatisierte Prozesse unterliegen selten Änderungen,
- Die Fristen für Forschung und Entwicklung sind knapp,
- Die Anforderungen an die Datenintegrität sind relativ gering (potenzielle Fehler in Industriesoftware führen nicht zum Verlust von Geld oder Kunden beim Softwarekunden)
- usw.
Unter den beschriebenen Bedingungen sind die Kosten für die Identifizierung und Beschreibung des Lebenszyklus einiger Objekte und ihrer Eigenschaften unter dem Gesichtspunkt der Wirtschaftlichkeit möglicherweise nicht gerechtfertigt.
3. Alle Folgen einer Denormalisierung des Datenmodells in einem bereits erstellten IS können durch eine gründliche Vorstudie des Codes und Tests abgemildert werden.
4. Denormalisierung ist eine Möglichkeit, Arbeitskosten von der Phase der Datenquellenforschung und der Gestaltung eines Geschäftsprozesses auf die Entwicklungsphase, von der Implementierungsphase auf die Phase der Systementwicklung zu übertragen.
5. Es empfiehlt sich, die dritte Normalform einer Datenbank anzustreben, wenn:
- Die Richtung der Veränderung automatisierter Geschäftsprozesse ist schwer vorherzusagen
- Es gibt eine schwache Arbeitsteilung innerhalb des Implementierungs- und/oder Entwicklungsteams
- In den Integrationskreis eingebundene Systeme entwickeln sich nach eigenen Plänen
- Dateninkonsistenzen können dazu führen, dass ein Unternehmen Kunden oder Geld verliert
6. Der Entwurf eines Datenmodells sollte von einem Analysten nur in Verbindung mit den Modellen des Zielgeschäftsprozesses und des Prozesses im IS durchgeführt werden. Wenn ein Entwickler ein Datenmodell entwirft, muss er sich so weit in das Themengebiet vertiefen, dass er insbesondere den Unterschied zwischen Attributwerten versteht – eine notwendige Voraussetzung für die Isolierung atomarer Attribute. So übernehmen sie ungewöhnliche Funktionen.
4 Problem zur Veranschaulichung
Nehmen wir an, Sie haben eine kleine Roboter-Taverne im Hafen. Ihr Marktsegment: Seeleute und Piraten, die in den Hafen kommen und eine Pause brauchen. Sie verkaufen Tee mit Thymian an Seeleute und Rum und Knochenkämme zum Kämmen der Bärte an Piraten. Der Service in der Taverne selbst wird von einer Roboter-Hostess und einem Roboter-Barkeeper übernommen. Dank Ihrer hohen Qualität und niedrigen Preise haben Sie Ihre Konkurrenten verdrängt, sodass jeder, der das Schiff verlässt, in Ihre Taverne kommt, die die einzige im Hafen ist.
Der Wirtshausinformationssystemkomplex besteht aus folgender Software:
- Ein Frühwarnsystem für einen Kunden, das seine Kategorie anhand charakteristischer Merkmale erkennt
- Steuerungssystem für Roboterhostessen und Roboterbarkeeper
- Lager- und Lieferverwaltungssystem zur Verkaufsstelle
- Lieferantenbeziehungsmanagementsystem (SURP)
Prozess:
Das Frühwarnsystem erkennt Personen, die das Schiff verlassen. Ist eine Person glattrasiert, identifiziert sie sie als Seemann; wird bei einer Person festgestellt, dass sie einen Bart hat, wird sie als Pirat identifiziert.
Beim Betreten der Taverne hört der Gast eine seiner Kategorie entsprechende Begrüßung der Roboterwirtin, zum Beispiel: „Ho-ho-ho, lieber Pirat, geh an Tisch Nr.“
Der Gast geht zum angegebenen Tisch, wo der Roboter-Barkeeper bereits Waren entsprechend der Kategorie für ihn vorbereitet hat. Der Roboter-Barkeeper übermittelt die Information an das Lagersystem, dass die nächste Lieferungsmenge erhöht werden sollte; der Lager-IS generiert auf der Grundlage der verbleibenden Lagerbestände eine Kaufanfrage im Verwaltungssystem.
Während das Frühwarnsystem möglicherweise von Ihrer internen IT entwickelt wurde, wurde das Barroboter-Managementprogramm möglicherweise von einem externen Auftragnehmer speziell für Ihr Unternehmen erstellt. Und Systeme zur Verwaltung von Lagern und Lieferantenbeziehungen sind maßgeschneiderte Paketlösungen vom Markt.
5. Beispiele für Denormalisierung und ihre Auswirkungen auf die Softwareentwicklung
Bei der Gestaltung eines Geschäftsprozesses stellten die befragten Fachexperten übereinstimmend fest, dass auf der ganzen Welt Piraten Rum trinken und ihre Bärte mit Knochenkämmen kämmen, und Matrosen Tee mit Thymian trinken und immer glatt rasiert sind.
Es erscheint ein Verzeichnis von Kundentypen mit zwei Werten: 1 – Piraten, 2 – Seeleute, gemeinsam für den gesamten Informationskreislauf des Unternehmens.
Das Kundenbenachrichtigungssystem speichert sofort das Ergebnis der Bildverarbeitung als Kennung (ID) des erkannten Kunden und seinen Typ: Seemann oder Pirat.
Erkannte Objekt-ID
Kundenkategorie
100500
Pirat
100501
Pirat
100502
Seemann
Das wollen wir noch einmal festhalten
1. Unsere Matrosen sind eigentlich rasierte Menschen
2. Unsere Piraten sind eigentlich bärtige Menschen
Welche Probleme müssen in diesem Fall beseitigt werden, damit unsere Struktur die dritte Normalform anstrebt:
- Verletzung der Attributatomizität – Clientkategorie
- Mischen der analysierten Tatsache und der 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 festgelegter Merkmale,
Erkannte Objekt-ID
Gesichtsbehaarung
100500
Ja
100501
Ja
100502
Nein
- das Ergebnis der Bestimmung des Kundentyps als Anwendung der im IS eingebetteten Logik zur Interpretation der festgelegten Merkmale
Erkannte Objekt-ID
Identifikations-ID
Kundenkategorie
100500
100001
Pirat
100501
100002
Pirat
100502
100003
Seemann
Wie kann eine normalisierte Datenspeicherorganisation die Entwicklung eines IP-Komplexes erleichtern? Nehmen wir an, Sie bekommen plötzlich neue Kunden. Seien es japanische Piraten, die vielleicht keinen Bart haben, aber mit einem Papagei auf der Schulter gehen, und Umweltpiraten, die man leicht an Gretas blauem Profil auf der linken Brust erkennen kann.
Umweltpiraten können natürlich keine Knochenkämme verwenden und fordern ein Analogon aus recyceltem Meeresplastik.
Sie müssen die Programmalgorithmen entsprechend den neuen Eingaben überarbeiten. Wenn die Normalisierungsregeln befolgt würden, müssten Sie in einigen Systemen nur die Eingaben für einige Prozesszweige ergänzen und neue Zweige nur für die Fälle und in den ISs erstellen, in denen Gesichtsbehaarung 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 Client-Typverzeichnisses verwendet werden, und klar feststellen, dass der Algorithmus in einem Fall den Profi berücksichtigen sollte Aktivität des Klienten und in den anderen körperlichen Merkmalen.
In einer Form, die sucht Zur Normalisierung würden wir zwei Tabellen mit Betriebsdaten und zwei Verzeichnisse erhalten:
- Erkennungsergebnis in Form einer Reihe festgelegter Merkmale,
Erkannte Objekt-ID
Greta auf der linken Brust
Vogel auf der Schulter
Gesichtsbehaarung
100510
1
1
1
100511
0
0
1
100512
1
0
- das Ergebnis der Bestimmung des Client-Typs (es sei eine benutzerdefinierte Ansicht, in der Beschreibungen aus Verzeichnissen angezeigt werden)
Bedeutet die festgestellte Denormalisierung, dass die Systeme nicht an neue Bedingungen angepasst werden können? Natürlich nicht. Wenn wir uns vorstellen, dass alle Informationssysteme von einem Team ohne Personalfluktuation erstellt wurden, die Entwicklungen gut dokumentiert sind und Informationen innerhalb des Teams ohne Verluste weitergegeben werden, dann können die erforderlichen Änderungen mit vernachlässigbar geringem Aufwand durchgeführt werden. Wenn wir jedoch zu den ursprünglichen Bedingungen des Problems zurückkehren, werden 1,5 Tastaturen allein für das Drucken von Protokollen gemeinsamer Diskussionen und weitere 0,5 für die Bearbeitung von Vergabeverfahren gelöscht.
Im obigen Beispiel werden alle drei Normalformen verletzt. Versuchen wir, sie separat zu verletzen.
Verletzung der ersten Normalform:
Nehmen wir an, Waren werden von den Lagern der Lieferanten durch Abholung mit einer 1.5 Tonnen schweren Gazelle, die zu Ihrer Taverne gehört, in Ihr Lager geliefert. Der Umfang Ihrer Aufträge ist im Verhältnis zum Umsatz der Lieferanten so gering, dass sie immer eins zu eins erledigt werden, ohne auf die Produktion warten zu müssen. Benötigen Sie bei einem solchen Geschäftsprozess separate Tabellen: Fahrzeuge, Fahrzeugtypen, ist eine Trennung von Plan und Fakt in Ihren Bestellungen an ausgeschiedene Lieferanten erforderlich?
Stellen Sie sich vor, wie viele „zusätzliche“ Verbindungen Ihre Programmierer schreiben müssen, wenn Sie das folgende Modell zur Entwicklung eines Programms verwenden.
Nehmen wir an, wir haben entschieden, dass die vorgeschlagene Struktur unnötig komplex ist. In unserem Fall handelt es sich bei der Trennung von Plan und Tatsache im Bestelldatensatz um redundante Informationen, und die generierte Bestellspezifikation wird basierend auf den Ergebnissen der Annahme der angekommenen Waren neu geschrieben, was selten vorkommt -Die Einstufung und der Eingang von Waren mangelhafter Qualität werden außerhalb des IS abgewickelt.
Und dann sieht man eines Tages, wie der gesamte Wirtshaussaal voller empörter und ungepflegter Piraten ist. Was ist passiert?
Es stellt sich heraus, dass mit dem Wachstum Ihres Unternehmens auch Ihr Konsum wuchs. Es gab einmal eine Zeit, in der das Management die Entscheidung traf, dass, wenn eine Gazelle in Bezug auf Volumen und/oder Gewicht überladen war, was äußerst selten vorkam, der Lieferant der Ladung Vorrang vor Getränken geben würde.
Die nicht gelieferte Ware landete in der nächsten Bestellung und wurde auf einen neuen Flug geschickt; das Vorhandensein eines Mindestguthabens im Lager der Taverne ermöglichte es, fehlende Kisten nicht zu bemerken.
Der letzte Wettbewerber schloss im Hafen, und der punktuelle Fall einer Gazellenüberladung, der durch eine Priorisierung auf der Grundlage der Annahme, dass das Mindestguthaben ausreichte, und einer periodischen Unterbeladung des Fahrzeugs umgangen wurde, wurde zur gängigen Praxis. Das geschaffene System arbeitet idealerweise nach den darin eingebetteten Algorithmen und hat keine Möglichkeit, die systematische Nichterfüllung geplanter Aufträge zu verfolgen. Nur ein beschädigter Ruf und unzufriedene Kunden können das Problem erkennen.
Einem aufmerksamen Leser ist möglicherweise aufgefallen, dass die bestellte Menge in der Bestellspezifikation (T_ORDER_SPEC) in Abschnitt 2 und Abschnitt 5 möglicherweise die Anforderung der ersten Normalform erfüllt oder nicht. Es hängt alles davon ab, ob bei gegebenem Warensortiment grundsätzlich unterschiedliche Maßeinheiten in ein und dasselbe Feld fallen können.
Verletzung der zweiten Normalform:
Wenn Ihr Bedarf wächst, kaufen Sie ein paar weitere Fahrzeuge unterschiedlicher Größe. In diesem Zusammenhang wurde die Erstellung eines Fahrzeugverzeichnisses als überflüssig angesehen, da alle Datenverarbeitungsalgorithmen, die die Bedürfnisse der Lieferung und des Lagers bedienen, die Bewegung der Fracht vom Lieferanten zum Lager als Flug eines ausschließlich 1,5 Tonnen schweren Fahrzeugs wahrnehmen Gazelle. Beim Kauf neuer Fahrzeuge erstellen Sie also immer noch ein Fahrzeugverzeichnis, aber bei der Fertigstellung müssen Sie alle Codes analysieren, die sich auf die Bewegung der Ladung beziehen, um herauszufinden, ob an den einzelnen Stellen Verweise auf die Merkmale impliziert sind des Fahrzeugs, mit dem das Unternehmen seinen Anfang nahm.
Verletzung der dritten Normalform:
Irgendwann beginnen Sie mit der Erstellung eines Treueprogramms und es erscheint die Aufzeichnung eines Stammkunden. Warum beispielsweise Zeit damit verschwenden, Materialansichten zu erstellen, in denen aggregierte Daten zu Verkäufen an einen einzelnen Kunden gespeichert werden, um diese in Berichten zu verwenden und an Analysesysteme weiterzuleiten, wenn zu Beginn eines Treueprogramms alles, was den Kunden interessiert, in die Kundenakte aufgenommen werden kann? ? Und tatsächlich hat es auf den ersten Blick keinen Sinn. Aber jedes Mal, wenn Ihr Unternehmen beispielsweise neue Vertriebskanäle verbindet, sollte es jemanden unter Ihren Analysten geben, der sich daran erinnert, dass ein solches Aggregationsattribut vorhanden ist.
Bei der Gestaltung jedes neuen Prozesses, zum Beispiel beim Verkauf im Internet oder beim Verkauf über Vertriebshändler, die an ein gemeinsames Treuesystem angeschlossen sind, muss jemand bedenken, dass alle neuen Prozesse die Datenintegrität auf Codeebene gewährleisten müssen. 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 ans Licht zu bringen.
Ich möchte dem führenden Entwickler Evgeniy Yarukhin meinen Dank für sein wertvolles Feedback während der Vorbereitung der Veröffentlichung aussprechen.
Literatur
Connolly Thomas, Begg Caroline. Datenbank. Design, Implementierung und Support. Theorie und Praxis
Source: habr.com