Hallo! Mein Name ist Andrei Semenov, ich bin Senior Analyst bei Sportmaster. In diesem Beitrag möchte ich das Thema der Denormalisierung von Datenbanken in ERP-Systemen ansprechen. Wir werden die allgemeinen Bedingungen sowie ein konkretes Beispiel betrachten — nehmen wir eine großartige Monopol-Taverne für Piraten und Seeleute. In dieser Taverne müssen Piraten und Seeleute unterschiedlich bedient werden, da sich ihre Vorstellungen von Schönheit und ihr Konsumverhalten erheblich unterscheiden.
Wie kann man alle zufriedenstellen? Wie bleibt man bei der Gestaltung und Wartung eines solchen Systems psychisch stabil? Was ist zu tun, wenn in die Taverne nicht nur die gewohnten Piraten und Seeleute kommen?
Alles weiter unten. Aber lassen Sie uns der Reihe nach vorgehen.
1. Einschränkungen und Annahmen
Alles hier Gesagte bezieht sich nur auf relationale Datenbanken. Die im Internet gut dokumentierten Folgen der Denormalisierung in Form von Anomalien bei Modifikationen, Löschungen und Einfügungen werden nicht behandelt. Aus diesem Beitrag ausgeschlossen sind Fälle, in denen Denormalisierung eine gängige Praxis ist, mit klassischen Beispielen wie Serien- und Ausweisnummern, Datum und Uhrzeit usw.
Im Beitrag werden intuitive und praktisch anwendbare Definitionen der Normalformen verwendet, ohne auf mathematische Begriffe zu verweisen. In der Form, wie sie auf die Untersuchung realer Geschäftsprozesse (BP) und die Entwicklung industrieller Software angewendet werden können.
Es gibt die Meinung, dass das Design von Data Warehouses, Tools für die Berichtserstellung und Integrationsvereinbarungen (in denen eine tabellarische Darstellung von Informationen verwendet wird) sich von der Gestaltung von ERP-Datenbanken dadurch unterscheidet, dass der Nutzungskomfort und die Anwendung bewusster Denormalisierung Priorität vor dem Schutz der Datenintegrität haben können. Ich teile diese Ansicht und das Folgende bezieht sich ausschließlich auf Modelle für Master-Daten und Transaktionsdaten in ERP-Systemen.
Die Erklärung der Normalformen wird anhand eines Beispiels gegeben, das für die meisten Leser auf alltäglichem Niveau verständlich ist. Als anschauliche Illustration wurde jedoch in den Punkten 4-5 bewusst eine betont „erfundene“ Aufgabe verwendet. Andernfalls, wenn man ein gängiges Beispiel wie das im Punkt 2 genannte Bestellmodell heranzieht, kann man in eine Situation geraten, in der der Fokus der Aufmerksamkeit des Lesers von der vorgeschlagenen Zerlegung des Prozesses in ein Modell auf persönliche Erfahrungen und Wahrnehmungen verschoben wird, wie Prozesse und Datenmodelle in Informationssystemen aufgebaut sein sollten. Mit anderen Worten, nehmen Sie zwei qualifizierte IT-Analysten: Der eine bietet Dienstleistungen für Logistiker, die Passagiere transportieren, der andere für Logistiker, die Maschinen für die Mikrochipherstellung transportieren. Bitten Sie sie, ohne vorherige Absprache automatisierbare Geschäftsprozesse, ein Datenmodell zur Speicherung von Informationen über einen Zugfahrt zu erstellen.
Es besteht eine nicht unerhebliche Wahrscheinlichkeit, dass Sie in den vorgeschlagenen Modellen nicht nur deutlich unterschiedliche Attributsammlungen finden, sondern auch nicht übereinstimmende Entitätssammlungen, weil jeder Analyst sich auf die für ihn gewohnten Prozesse und Aufgaben stützt. Und in einer solchen Situation zu sagen, welches Modell „richtig“ ist, ist unmöglich, da es kein Bewertungskriterium gibt.
2. Normalformen
Die erste Normalform einer Datenbank verlangt die Atomarität aller Attribute.
Insbesondere, wenn ein Objekt A nicht-Schlüsselattribute a und b hat, sodass c=f(a,b) und in der Tabelle, die Objekt A beschreibt, der Wert des Attributs c gespeichert wird, dann ist die erste Normalform in der Datenbank verletzt. Zum Beispiel, wenn in der Auftragspezifikation die Menge angegeben wird, deren Maßeinheit vom Warentyp abhängt: In einem Fall kann es sich um Stücke handeln, im anderen um Liter, im dritten um Verpackungen, die aus Stückzahlen bestehen (in dem obigen Modell Good_count_WR), dann ist die Atomarität der Attribute in der Datenbank verletzt. Um zu sagen, wie die Tabelle in der Auftragspezifikation aussehen sollte, benötigt man eine zielgerichtete Beschreibung des Arbeitsprozesses im Informationssystem, und da die Prozesse unterschiedlich sein können, kann es also viele „richtige“ Versionen geben.
Die zweite Normalform einer Datenbank erfordert die Einhaltung der ersten Normalform und eine eigene Tabelle für jede Entität, die zum Arbeitsprozess im IS gehört. Wenn in einer Tabelle Abhängigkeiten mit f1(a) und d=f2(b) vorhanden sind und es keine Abhängigkeit mit f3(b) gibt, dann ist die zweite Normalform in der Tabelle verletzt. Im obigen Beispiel gibt es in der Tabelle „Bestellung“ keine Abhängigkeit zwischen der Bestellung und der Adresse. Ändern Sie den Straßennamen oder die Stadt, und es hat keine Auswirkungen auf die wesentlichen Attribute der Bestellung.
Dritte Normalform der DB erfordert die Einhaltung der zweiten Normalform und das Fehlen funktionaler Abhängigkeiten zwischen Attributen verschiedener Entitäten. Diese Regel kann so formuliert werden: „Alles, was berechnet werden kann, sollte berechnet werden“. Mit anderen Worten, wenn zwei Objekte A und B existieren. In der Tabelle, die die Attribute des Objekts A speichert, ist das Attribut C vorhanden, und das Objekt B hat ein Attribut b, sodass c=f4(b) existiert, dann ist die dritte Normalform verletzt. Im folgenden Beispiel strebt das Attribut „Anzahl der Stücke“ (Total_count_WR) im Bestellposten offensichtlich an, die dritte Normalform zu verletzen.
3. Mein Ansatz zur Anwendung der Normalisierung
1. Nur der zielgerichtete automatisierbare Geschäftsprozess kann den Analysten mit Kriterien zur Identifizierung von Entitäten und Attributen bei der Erstellung eines Datenmodell-Storage-Systems versorgen. Die Erstellung eines Prozessmodells ist eine notwendige Bedingung für die Schaffung eines Normalen Datenmodells.
2. Das Erreichen der dritten Normalform im strengen Sinne kann in der realen Praxis der Erstellung von ERP-Systemen unpraktisch sein, wenn teilweise oder vollständig die folgenden Bedingungen erfüllt sind:
- automatisierte Prozesse selten Veränderungen unterliegen,
- die Fristen für Forschung und Entwicklung eng sind,
- die Anforderungen an die Datenintegrität bedingt niedrig sind (potentielle Fehler in kommerzieller Software führen nicht zum Verlust von Geld oder Kunden für den Softwareauftraggeber).
- Zertifikate mit kubeadm
Unter den beschriebenen Bedingungen können die Kosten für die Identifizierung und Beschreibung des Lebenszyklus bestimmter Objekte und deren Attribute aus wirtschaftlicher Sicht möglicherweise nicht gerechtfertigt sein.
3. Jedes Ergebnis der Denormalisierung eines bereits erstellten Datenmodells im IS kann durch sorgfältige Voruntersuchung des Codes und Tests abgemildert werden.
4. Denormalisierung ist ein Weg, um den Arbeitsaufwand von der Phase der Datenquellenforschung und der Geschäftsprozessgestaltung in die Entwicklungsphase zu verlagern, vom Implementierungszeitraum in die Entwicklungsphase des Systems.
5. Es ist sinnvoll, auf die dritte normale Form der Datenbank hinzuarbeiten, wenn:
- Die Richtung der zu automatisierenden Geschäftsprozesse ist schwer vorhersehbar.
- Innerhalb des Implementierungs- und/oder Entwicklungsteams gibt es eine schwache Arbeitsteilung.
- Die Systeme im Integrationskreis entwickeln sich nach eigenen Plänen.
- Diskrepanzen in den Daten können dazu führen, dass das Unternehmen Kunden oder Geld verliert.
6. Die Datenmodellierung sollte nur im Zusammenhang mit den Modellen des Zielgeschäftsprozesses und des Prozesses in der IS durch einen Analysten durchgeführt werden. Wenn die Datenmodellierung von einem Entwickler vorgenommen wird, muss dieser sich so intensiv mit dem Fachbereich auseinandersetzen, dass er unter anderem die Unterschiede zwischen den Werten der Attribute versteht – eine notwendige Bedingung für die Identifizierung atomarer Attribute. Damit übernimmt er Funktionen, die ihm nicht zukommen.
4 Aufgabe zur Veranschaulichung
Angenommen, Sie haben eine kleine robotergestützte Taverne im Hafen. Ihr Marktsegment: Seeleute und Piraten, die in den Hafen kommen und eine Auszeit benötigen. Den Seeleuten verkaufen Sie Thymiantee, den Piraten Rum und Knochenschnäbel zum Kämmen ihres Bartes. Der Service in der Taverne wird von einem Roboter-Hostess und einem Roboter-Barkeeper übernommen. Durch die hohe Qualität und die niedrigen Preise haben Sie alle Konkurrenten verdrängt, sodass jeder, der von Bord kommt, in Ihre Taverne kommt, die die einzige im Hafen ist.
Das Informationssystem der Taverne besteht aus folgender Software:
- Ein System zur Früherkennung von Kunden, das deren Kategorie anhand charakteristischer Merkmale erkennt.
- Ein System zur Steuerung der Roboter-Hostess und Roboter-Barkeeper.
- Ein System zur Verwaltung von Lager und Lieferung an den Verkaufsort.
- Ein System zur Verwaltung der Beziehungen zu Lieferanten (SRM).
Prozess:
Das Früherkennungssystem erkennt Personen, die von Bord gehen. Wenn eine Person glatt rasiert ist, wird sie als Seemann identifiziert; wenn eine Person einen Bart hat, wird sie als Pirat erkannt.
Beim Betreten der Taverne hört der Gast ein begrüßendes Wort vom Roboter-Hostess, das seiner Kategorie entspricht, zum Beispiel: „Ho-ho-ho, geschätzter Pirat, bitte setzen Sie sich an Tisch Nr....“
Der Gast geht zu dem angegebenen Tisch, an dem der Roboter-Barkeeper bereits die Waren entsprechend der Kategorie vorbereitet hat. Der Roboter-Barkeeper überträgt Informationen an das Lagerverwaltungssystem, dass die nächste Lieferung erhöht werden soll, und das Lagerverwaltungssystem erstellt basierend auf den Vorräten einen Beschaffungsantrag im ERP-System.
Angenommen, das Frühwarnsystem wurde von Ihrer internen IT-Abteilung entwickelt, das Programm zur Verwaltung von Barkeeper-Robotern wurde von einem externen Auftragnehmer speziell für Ihr Unternehmen erstellt. Die Systeme zur Lagerverwaltung und für die Lieferantenbeziehungen sind angepasst, kommerzielle Lösungen vom Markt.
5. Beispiele für Denormalisierung und deren Einfluss auf die Softwareentwicklung
Bei der Gestaltung des Geschäftsprozesses erklärten die befragten Fachexperten einstimmig, dass Piraten weltweit Rum trinken und sich mit Knochenschnäuzern die Bärte kämmen, während Seefahrer Tee mit Thymian trinken und immer glatt rasiert sind.
Ein Verzeichnis von Kundentypen erscheint mit zwei Werten: 1- Piraten, 2 - Seefahrer, das für den gesamten Informationsbereich des Unternehmens gilt.
Das Benachrichtigungssystem über Kunden speichert sofort das Ergebnis der Bildverarbeitung als Identifikator (ID) des erkannten Kunden und seines Typs: Seefahrer oder Pirat.
ID des erkannten Objekts
Kundekategorie
100500
Pirat
100501
Pirat
100502
Seefahrer
Lassen Sie uns noch einmal darauf hinweisen, dass
1. Unsere Seefahrer tatsächlich rasierte Menschen sind
2. Unsere Piraten tatsächlich bärtige Menschen sind
Welche Probleme in diesem Fall gelöst werden müssen, damit unsere Struktur zur dritten Normalform strebt:
- Verstoß gegen die Atomarität des Attributes – Kundekategorie
- Vermischung von analysierten Fakten und Ergebnissen in einer Tabelle
- Funktionale Abhängigkeiten zwischen Attributen verschiedener Entitäten sind festgelegt.
In normalisierter Form hätten wir zwei Tabellen erhalten:
- Ergebnis der Erkennung in Form eines Sets von festgelegten Merkmalen,
ID des erkannten Objekts
Gesichtsbehaarung
100500
Ja
100501
Ja
100502
Nein
- Ergebnis der Bestimmung des Kundentyps als Anwendung der in der Informationssystemlogik eingebetteten Logik zur Interpretation der festgelegten Merkmale
ID des erkannten Objekts
ID der Identifikation
Kundekategorie
100500
100001
Pirat
100501
100002
Pirat
100502
100003
Seefahrer
Wie kann eine normierte Datenorganisation die Entwicklung eines Informationssystems erleichtern? Angenommen, plötzlich haben Sie neue Kunden. Nehmen wir an, es handelt sich um japanische Piraten, die vielleicht keinen Bart haben, aber mit einem Papagei auf der Schulter herumlaufen, und um umweltbewusste Piraten, die Sie leicht an dem blauen Profil von Greta auf der linken Brust erkennen werden.
Umweltbewusste Piraten dürfen natürlich keine Kämme aus Knochen verwenden und fordern eine Alternative aus recyceltem Meeresplastik.
Sie müssen die Arbeitsalgorithmen der Programme gemäß den neuen Vorgaben überarbeiten. Wenn die Normalisierungsregeln umgesetzt worden wären, müssten Sie lediglich in einigen Systemen die Eingaben für bestimmte Prozesszweige ergänzen und nur dann neue Zweige schaffen, wenn es um Gesichtshaare in bestimmten Informationssystemen geht. Da die Regeln jedoch nicht umgesetzt wurden, müssen Sie den gesamten Code analysieren, wo Werte aus dem Verzeichnis der Kundentypen verwendet werden, und eindeutig feststellen, dass in einem Fall der Algorithmus die berufliche Tätigkeit des Kunden und im anderen Fall die körperlichen Merkmale berücksichtigen muss.
In der Form, die verstehen wollen normiert ist, hätten wir zwei Tabellen mit Betrieb Daten und zwei Verzeichnisse erhalten:
- Ergebnis der Erkennung in Form eines Sets von festgelegten Merkmalen,
ID des erkannten Objekts
Greta auf der linken Brust
Vogel auf der Schulter
Gesichtsbehaarung
100510
1
1
1
100511
0
0
1
100512
1
0
- Ergebnis der Typbestimmung des Kunden (nehmen wir an, es handelt sich um eine Benutzeransicht, in der Beschreibungen aus den Verzeichnissen angezeigt werden)
Bedeutet die festgestellte Denormalisierung, dass die Systeme nicht an neue Bedingungen angepasst werden können? Nein, natürlich nicht. Wenn man sich vorstellt, dass alle Informationssysteme von einem Team mit null Mitarbeiterfluktuation erstellt wurden, die Entwicklungen gut dokumentiert sind und die Informationen im Team ohne Verlust weitergegeben werden, können die erforderlichen Änderungen mit vernachlässigbaren Arbeitsaufwendungen durchgeführt werden. Aber wenn wir zu den ursprünglichen Bedingungen der Aufgabe zurückkehren, dann würden allein für den Druck der Protokolle gemeinsamer Diskussionen 1,5 Tastaturen draufgehen und weitere 0,5 für die Erstellung der Beschaffungsverfahren.
Im obigen Beispiel wurden alle drei Normalformen verletzt; lassen Sie uns versuchen, sie einzeln zu verletzen.
Verstoß gegen die erste Normalform:
Angenommen, Waren werden mit einem 1,5-Tonnen-Transporter, der Ihrer Taverne gehört, von den Lagern der Lieferanten abholt. Die Größe Ihrer Bestellungen ist im Vergleich zu den Lieferantenumsätzen so gering, dass sie immer eins zu eins ohne Wartezeit auf die Herstellung ausgeführt werden. Sind bei einer solchen Geschäftspraxis separate Tabellen erforderlich: Fahrzeuge, Fahrzeugtypen? Ist es notwendig, Plan und Ist in Ihren an die Lieferanten gesendeten Bestellungen zu trennen?
Stellen Sie sich nur vor, wie viele "überflüssige" Verbindungen Ihre Programmierer schreiben müssten, wenn sie das Modell unten für die Programmentwicklung verwenden.
Angenommen, wir haben beschlossen, dass die vorgeschlagene Struktur übermäßig kompliziert ist. Für unseren Fall ist es überflüssig, Plan und Ist bei der Bestellung zu trennen, und die erstellte Bestellspezifikation wird nach den Ergebnissen der Warenannahme überschrieben. Seltene Nachsortierung und das Eintreffen von mangelhafter Ware werden außerhalb des Informationssystems geregelt.
Und eines Tages sehen Sie, dass der gesamte Saal der Taverne mit empörten und ungepflegten Piraten gefüllt ist. Was ist passiert?
Es stellte sich heraus, dass mit dem Wachstum Ihres Unternehmens auch der Verbrauch gestiegen ist. Früher gab es eine Managemententscheidung, dass wenn der Transporter bei Volumen und/oder Gewicht überlastet war, was sehr selten vorkam, der Lieferant die Beladung zugunsten der Getränke priorisierte.
Unterbeladene Ware gelangte in die nächste Bestellung und wurde in einer neuen Fahrt verschickt. Das Vorhandensein eines nicht reduzierbaren Bestandes im Lager bei der Taverne erlaubte es, die ausgebliebenen Fälle nicht zu bemerken.
Im Hafen hat der letzte Konkurrent geschlossen, und der ausgebliebene Fall der Überlastung des Transporters, der bei der Priorisierung umgangen wurde, beruhte auf der Annahme ausreichender nicht reduzierbarer Bestände und der gelegentlichen Unterladung des Fahrzeugs, wurde zur gängigen Praxis. Das erstellte System wird perfekt entsprechend den darin implementierten Algorithmen arbeiten und wird völlig unfähig sein, die systematische Nichterfüllung der Bestellungen nachzuvollziehen. Nur ein beschädigter Ruf und unzufriedene Kunden können das Problem aufdecken.
Aufmerksame Leser haben wahrscheinlich bemerkt, dass die bestellte Menge in der Bestellungsspezifikation (T_ORDER_SPEC) in Abschnitt 2 und Abschnitt 5 möglicherweise den Anforderungen der ersten normalen Form entspricht oder auch nicht. Das hängt davon ab, ob bei der gewählten Produktpalette unterschiedliche Maßeinheiten im selben Feld eingetragen werden können.
Verstoß gegen die zweite normale Form:
Mit wachsendem Bedarf erwerben Sie ein paar Transportmittel verschiedener Größen. Im oben genannten Kontext wurde festgestellt, dass die Erstellung eines Verzeichnisses der Transportmittel überflüssig ist. Daher betrachten alle Algorithmen, die den Liefer- und Lagerbedürfnissen dienen, den Transport von Waren vom Anbieter zum Lager als einen einzigen 1,5-Tonnen-Lieferfahrzeug-Fahrt. Also erstellen Sie zusammen mit dem Kauf neuer Transportmittel dennoch ein Verzeichnis der Transportmittel, aber bei der Nachbearbeitung müssen Sie den gesamten Code, der auf den Gütertransport verweist, analysieren, um herauszufinden, ob an jedem bestimmten Ort auf die Eigenschaften des Fahrzeugs verwiesen wird, von dem das Geschäft ursprünglich gestartet wurde.
Verstoß gegen die dritte normale Form:
Irgendwann beginnen Sie, ein Loyalitätsprogramm zu erstellen, und es gibt einen Eintrag für einen Stammkunden. Warum, zum Beispiel, Zeit darauf verwenden, materielle Darstellungen zu erstellen, die aggregierte Verkaufsdaten für einen einzelnen Kunden aufbewahren, um sie für Berichterstattung und Übertragung an Analysesysteme zu nutzen, wenn zum Zeitpunkt des Starts des Loyalitätsprogramms alles, was den Kunden interessiert, im Eintrag des Kunden selbst untergebracht werden kann? Und in der Tat scheint es auf den ersten Blick keinen Sinn zu machen. Aber jedes Mal, wenn Ihr Unternehmen beispielsweise neue Vertriebskanäle anschließt, sollte einer Ihrer Analysten daran denken, dass es ein solches Aggregationsattribut gibt.
Beim Entwerfen jedes neuen Prozesses, sagen wir im Online-Verkauf, beim Verkauf über Distributoren, die mit dem gemeinsamen Loyalitätssystem verbunden sind, sollte jemand im Hinterkopf behalten, dass all diese neuen Prozesse auf Code-Ebene die Datenintegrität gewährleisten müssen. Für eine industrielle Datenbank mit tausend Tabellen erscheint dies wie eine kaum umsetzbare Aufgabe.
Ein erfahrener Entwickler weiß natürlich, wie man all die genannten Probleme umgehen kann, aber meiner Meinung nach ist es die Aufgabe eines erfahrenen Analysts, sie gar nicht erst entstehen zu lassen.
Ich möchte mich für das wertvolle Feedback bedanken, das der leitende Entwickler Juri Jaruhin bei der Veröffentlichung gegeben hat.
Literatur
Connolly Thomas, Begg Caroline. Datenbanken. Entwurf, Implementierung und Wartung. Theorie und Praxis.
Quelle: habr.com
