Hallo! Mein Name ist Andrej Semenov, ich bin Senior Analyst bei Sportmaster. In diesem Beitrag möchte ich die Frage der Denormalisierung von Datenbanken in ERP-Systemen aufwerfen. Wir werden die allgemeinen Bedingungen sowie ein konkretes Beispiel betrachten – sagen wir, es wird eine großartige Taverne sein, die Monopolist für Piraten und Seefahrer ist. In dieser Taverne müssen Piraten und Seefahrer unterschiedlich bedient werden, da ihre Vorstellungen von dem, was schön ist, und ihre Konsummuster erheblich voneinander abweichen.
Wie kann man sicherstellen, dass alle zufrieden sind? Wie behält man den Verstand, wenn man ein solches System entwirft und unterstützt? Was tun, wenn in die Taverne nicht nur die gewohnten Piraten und Seefahrer kommen?
Alles Weitere im Folgenden. Aber lassen Sie uns der Reihe nach vorgehen.
1. Einschränkungen und Annahmen
Alles, was hier ausgeführt wird, gilt nur für relationale Datenbanken. Die gut dokumentierten, auch im Internet verfügbaren Folgen der Denormalisierung in Form von Modifikations-, Lösch- und Einfügeanomalien werden nicht betrachtet. Fälle, in denen Denormalisierung alltäglich ist, bleiben ebenfalls außerhalb dieses Beitrags, mit klassischen Beispielen wie: Passserie und -nummer, Datum und Uhrzeit und so weiter.
Der Beitrag verwendet intuitive und praktisch anwendbare Definitionen von Normalformen, ohne auf mathematische Begriffe Bezug zu nehmen. So, wie sie auf die Untersuchung realer Geschäftsprozesse (BP) und das Design industrieller Software angewendet werden können.
Es wird angenommen, dass das Design von Data Warehouses, Reporting-Tools und Integrationsvereinbarungen (in denen tabellarische Darstellungen von Informationen verwendet werden) sich vom Design von ERP-Datenbanken dadurch unterscheidet, dass der Benutzerkomfort und die bewusste Denormalisierung potenziell Vorrang vor dem Schutz der Datenintegrität haben können. Ich teile diese Auffassung, und das Folgende bezieht sich ausschließlich auf Modelle von Stammdaten und Transaktionsdaten von ERP-Systemen.
Die Erklärung der Normalformen wird anhand eines für die meisten Leser verständlichen Alltagsbeispiels gegeben. Um jedoch eine anschauliche Illustration zu bieten, wurde in den Punkten 4-5 bewusst eine stark "erfundenen" Aufgabe verwendet. Andernfalls, wenn man ein gängiges Beispiel wie das in Punkt 2 genannte Speicherungsmodell für eine Bestellung heranzieht, kann die Aufmerksamkeit des Lesers von der vorgeschlagenen Zerlegung des Prozesses in ein Modell auf persönliche Erfahrungen und Wahrnehmungen gelenkt werden, wie Prozesse und Datenmodelle in Informationssystemen gestaltet werden sollten. Mit anderen Worten, nehmen Sie zwei qualifizierte IT-Analysten: Der eine unterstützt Logistiker, die Passagiere transportieren, der andere Logistiker, die Maschinen zur Herstellung von Mikrochips transportieren. Bitten Sie sie, ohne vorherige Diskussion über automatisierbare Geschäftsprozesse, ein Datenmodell für die Speicherung von Informationen über einen Zugtransport zu erstellen.
Es besteht eine nicht unerhebliche Wahrscheinlichkeit, dass Sie in den vorgeschlagenen Modellen nicht nur deutlich unterschiedliche Attributsätze finden, sondern auch nicht übereinstimmende Entitätsmengen. Jeder Analyst wird sich auf ihm vertraute Prozesse und Aufgaben stützen. In einer solchen Situation lässt sich nicht sagen, welches Modell 'richtig' ist, da es kein Bewertungskriterium gibt.
2. Normale Formen
Die erste normale Form der Datenbank fordert die Atomarität aller Attribute.
Insbesondere wenn ein Objekt A nicht-schlüssel Attribute a und b hat, so dass c=f(a,b) ist und in der Tabelle, die Objekt A beschreibt, der Wert des Attributs c gespeichert wird, ist die erste normale Form in der Datenbank verletzt. Zum Beispiel, wenn in der Bestellung eine Menge angegeben wird, deren Maßeinheit vom Produkttyp abhängt: In einem Fall können es Stücke sein, im anderen Litern, im dritten Verpackungen, die aus Stückzahlen bestehen (im obigen Modell Good_count_WR), dann ist die Atomarität der Attribute in der Datenbank verletzt. Um zu bestimmen, wie der Tabellenbaum der Bestellspezifikation aussehen sollte, ist eine zielgerichtete Beschreibung des Arbeitsprozesses im Informationssystem erforderlich. Da die Prozesse unterschiedlich sein können, können es auch viele 'richtige' Versionen geben.
Die zweite normale Form einer Datenbank erfordert die Einhaltung der ersten Normalform und eine eigene Tabelle für jede Entität, die zum Arbeitsprozess im Informationssystem gehört. Wenn in einer Tabelle Abhängigkeiten zwischen f1(a) und d=f2(b) bestehen und keine Abhängigkeit zu f3(b) existiert, ist die zweite normale Form verletzt. Im obigen Beispiel gibt es zwischen der Bestellung und der Adresse keine Abhängigkeit. Ändern Sie den Straßennamen oder die Stadt, so hat dies keinen Einfluss auf die wesentlichen Attribute der Bestellung.
Die dritte normale Form einer Datenbank erfordert die Einhaltung der zweiten normalen Form und die Abwesenheit funktionaler Abhängigkeiten zwischen Attributen verschiedener Entitäten. Diese Regel kann so formuliert werden: „Alles, was berechnet werden kann, sollte berechnet werden“. Anders ausgedrückt, wenn es zwei Objekte A und B gibt. In der Tabelle, die die Attribute von Objekt A speichert, tritt das Attribut C auf, und bei Objekt B existiert ein Attribut b, sodass es c=f4(b) gibt, dann ist die dritte normale Form verletzt. Im folgenden Beispiel beansprucht das Attribut „Anzahl der Stücke“ (Total_count_WR) im Bestellposten eindeutig eine Verletzung der dritten normalen Form.
3. Mein Ansatz zur Anwendung der Normalisierung
1. Nur ein zielgerichteter automatisierbarer Geschäftsprozess kann die Kriterien für die Identifizierung von Entitäten und Attributen bei der Erstellung eines Datenspeichermodells bereitstellen. Die Erstellung eines Prozessmodells ist eine Voraussetzung für die Schaffung eines normalen Datenmodells.
2. Das Erreichen der dritten Normalform kann im strengen Sinne in der realen Praxis der Erstellung von ERP-Systemen unpraktisch sein, wenn eines oder mehrere der folgenden Bedingungen erfüllt sind:
- automatisierbare Prozesse sind selten Änderungen unterworfen,
- die Fristen für Forschung und Entwicklung sind eng,
- die Anforderungen an die Datenintegrität sind bedingt niedrig (potenzielle Fehler in industrieller Software führen nicht zum Verlust von Geld oder Kunden für den Softwareauftraggeber)
- usw.
Unter den beschriebenen Bedingungen können die Kosten für die Identifizierung und Beschreibung des Lebenszyklus bestimmter Objekte und ihrer Attribute aus wirtschaftlicher Sicht nicht gerechtfertigt sein.
3. Alle Folgen der Denormalisierung eines Datenmodells in bereits bestehenden Informationssystemen können durch sorgfältige Voruntersuchungen des Codes und Testing abgeschwächt werden.
4. Denormalisierung ist ein Ansatz, um den Arbeitsaufwand von der Phase der Datenquellenrecherche und dem Design von Geschäftsprozessen auf die Entwicklungsphase zu übertragen, von der Implementierungszeit auf die Entwicklungszeit des Systems.
5. Es ist sinnvoll, die dritte Normalform der Datenbank anzustreben, wenn:
- Die Richtung der Veränderung der automatisierbaren Geschäftsprozesse schwer vorhersehbar ist.
- Innerhalb des Implementierungs- und/oder Entwicklungsteams besteht eine schwache Trennung der Arbeit.
- Die Systeme, die Teil des Integrationskontexts sind, entwickeln sich nach eigenen Plänen.
- Inkonsequenten Daten können zu Kunden- oder Geldverlusten für das Unternehmen führen.
6. Die Modellierung von Daten sollte nur von einem Analysten im Zusammenhang mit den Modellen des Zielgeschäftsprozesses und des Prozesses im Informationssystem erfolgen. Wenn ein Entwickler die Datenmodellierung durchführt, muss er sich so tief in das Fachgebiet einarbeiten, dass er insbesondere den Unterschied zwischen den Attributwerten versteht – eine notwendige Voraussetzung für die Identifizierung atomarer Attribute. Damit übernimmt er Aufgaben, die ihm nicht zugewiesen sind.
4 Aufgabe zur Veranschaulichung
Stellen Sie sich vor, Sie betreiben eine kleine robotergestützte Taverne im Hafen. Ihre Zielgruppe sind Seeleute und Piraten, die in den Hafen kommen und eine Auszeit benötigen. Den Seeleuten verkaufen Sie Thymiantee, während die Piraten Rum und knochenähnliche Kämme zur Bartpflege erhalten. Der Service in der Taverne wird von einem Roboter-Hostess und einem Roboter-Barkeeper übernommen. Dank hoher Qualität und niedriger Preise haben Sie alle Mitbewerber verdrängt, sodass jeder, der von einem Schiff kommt, in Ihre Taverne geht, die die einzige im Hafen ist.
Das Informationssystem der Taverne besteht aus folgender Software:
- Ein Frühwarnsystem für Kunden, das ihre Kategorie anhand charakteristischer Merkmale erkennt.
- Ein System zur Steuerung der Roboter-Hostessen und Roboter-Barkeeper.
- Ein System zur Verwaltung des Lagers und der Auslieferung an den Verkaufsort.
- Ein System zur Verwaltung der Lieferantenbeziehungen (VMS).
Prozess:
Das Frühwarnsystem erkennt die von den Schiffen kommenden Personen. Wenn jemand glatt rasiert ist, wird er als Seemann identifiziert, während eine Person mit Bart als Pirat erkannt wird.
Beim Betreten der Taverne hört der Gast von dem Roboter-Hostess ein Begrüßung entsprechend seiner Kategorie, zum Beispiel: „Ho-ho-ho, geschätzter Pirat, bitte nehmen Sie Platz an Tisch Nr.…“
Der Gast geht zu dem angegebenen Tisch, an dem der Roboter-Barkeeper bereits Produkte entsprechend seiner Kategorie vorbereitet hat. Der Roboter-Barkeeper übermittelt Informationen an das Lagerverwaltungssystem, dass die nächste Lieferung erhöht werden soll. Basierend auf den Beständen erstellt das Lagerverwaltungssystem eine Beschaffungsanfrage im ERP.
Ob das Frühwarnsystem nun von Ihrer internen IT entwickelt wurde oder das Programm zur Verwaltung der Barkeeper-Roboter von einem externen Dienstleister speziell für Ihr Geschäft erstellt wurde – die Systeme zur Lagerverwaltung und Lieferantenbeziehungen sind maßgeschneiderte, kaufbare 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 Experten des Fachgebiets einstimmig, dass Piraten weltweit Rum trinken und ihre Bärte mit knochengreben kämmen, während Seeleute Tee mit Thymian trinken und immer glatt rasiert sind.
Es erscheint ein Verzeichnis von Kundentypen mit zwei Werten: 1 - Piraten, 2 - Seeleute, das für den gesamten Informationskreis des Unternehmens gilt.
Das Benachrichtigungssystem über Kunden speichert sofort das Ergebnis der Bildverarbeitung als Identifikator (ID) des erkannten Kunden und seinen Typ: Seemann oder Pirat.
ID des erkannten Objekts
Kundengruppe
100500
Pirat
100501
Pirat
100502
Seemann
Wir möchten nochmals darauf hinweisen, dass
1. Unsere Seeleute tatsächlich rasiert sind
2. Unsere Piraten tatsächlich bärtig sind
Welche Probleme müssen in diesem Fall gelöst werden, um unsere Struktur in die dritte Normalform zu bringen:
- Verletzung der Atomarität des Attributs - Kundengruppe
- Vermischung der analysierten Tatsache und der Schlussfolgerung in einer Tabelle
- Festgestellte funktionale Abhängigkeit zwischen Attributen verschiedener Entitäten.
In normalisierter Form hätten wir zwei Tabellen erhalten:
- Ergebnis der Erkennung in Form einer Menge festgelegter Merkmale.
ID des erkannten Objekts
Gesichtsbehaarung
100500
Ja
100501
Ja
100502
Nein
- Ergebnis der Bestimmung des Kundentyps als Anwendung der in der Informationssystemlogik festgelegten Merkmale zur Interpretation der festgelegten Merkmale.
ID des erkannten Objekts
ID der Identifizierung
Kundengruppe
100500
100001
Pirat
100501
100002
Pirat
100502
100003
Seemann
Wie kann eine normalisierte Datenlagerorganisation die Entwicklung eines Informationssystems erleichtern? Stellen Sie sich vor, plötzlich gewinnen Sie neue Kunden. Nehmen wir an, es handelt sich um japanische Piraten, die vielleicht keinen Bart tragen, aber einen Papagei auf der Schulter haben. Und dann gibt es umweltbewusste Piraten, die man leicht an dem blauen Profil von Greta auf der linken Brust erkennt.
Umweltbewusste Piraten können natürlich keine Knochenkämme benutzen und fordern eine Alternative aus recyceltem Meeresplastik.
Sie müssen die Algorithmen der Software an die neuen Anforderungen anpassen. Wenn die Normalisierungsregeln befolgt worden wären, hätten Sie nur für einige Systembereiche die Eingaben für bestimmte Prozesszweige ergänzen und neue Zweige nur dort schaffen müssen, wo das Gesichtshaar relevant ist. Aber da die Regeln nicht eingehalten wurden, müssen Sie den gesamten Code analysieren, in dem die Werte des Referenzverzeichnisses für Kundentypen verwendet werden, und klar festlegen, dass in einem Fall der Algorithmus die berufliche Tätigkeit des Kunden berücksichtigen muss, während er im anderen Fall physische Merkmale beachten sollte.
In einer Form, die danach normalisiert wäre, hätten wir zwei Tabellen mit Betriebsdaten und zwei Verzeichnisse erhalten:
- Ergebnis der Erkennung in Form einer Menge festgelegter Merkmale.
ID des erkannten Objekts
Greta auf der linken Brust
Ein Vogel auf der Schulter
Gesichtsbehaarung
100510
1
1
1
100511
0
0
1
100512
1
0
- das Ergebnis der Kundenklassifikation (lassen Sie es eine benutzerdefinierte Darstellung sein, die Beschreibungen aus den Verzeichnissen anzeigt)
Bedeutet die festgestellte Denormalisierung, dass die Systeme nicht an neue Bedingungen angepasst werden können? Natürlich nicht. Wenn man sich vorstellt, dass alle Informationssysteme von einem Team mit null Fluktuation erstellt wurden, die Entwicklungen gut dokumentiert sind und die Informationen im Team ohne Verluste übertragen werden, könnten die erforderlichen Änderungen mit vernachlässigbar geringem Aufwand durchgeführt werden. Aber wenn wir zu den ursprünglichen Bedingungen der Aufgabe zurückkehren, würde allein das Drucken von Protokollen gemeinsamer Diskussionen 1,5 Tastaturen und weitere 0,5 für die Ausarbeitung von Beschaffungsverfahren abnutzen.
Im obigen Beispiel sind alle drei Normalformen verletzt, lassen Sie uns versuchen, sie einzeln zu verletzen.
Verletzung der ersten Normalform:
Stellen Sie sich vor, dass Waren zu Ihrem Lager von den Lieferanten per Selbstabholung mit einem 1,5-Tonnen-Gaslieferwagen gebracht werden, der Ihrer Taverne gehört. Die Größe Ihrer Bestellungen ist im Vergleich zu den Umsätzen der Lieferanten so gering, dass sie immer eins zu eins ohne Wartezeiten ausgeführt werden. Brauchen Sie bei einem solchen Geschäftsprozess separate Tabellen: Fahrzeuge, Fahrzeugtypen, und sollte man Plan und Ist in Ihren Bestellungen an die Lieferanten trennen?
Stellen Sie sich nur vor, wie viele "überflüssige" Verbindungen Ihre Programmierer schreiben müssten, wenn das folgende Modell zur Entwicklung der Software verwendet wird.
Angenommen, wir haben entschieden, dass die vorgeschlagene Struktur übermäßig kompliziert ist. In unserem Fall ist es überflüssig, Plan und Ist in der Bestellung zu trennen, und die erstellte Bestellspezifikation wird nach den Ergebnissen der Annahme der angelieferten Ware neu geschrieben. Seltene Fehlbestellungen und Ankünfte von mangelhafter Ware werden außerhalb des Informationssystems geregelt.
Und eines Tages sehen Sie, wie der ganze Saal der Taverne mit empörten und unfrisierten Piraten gefüllt ist. Was ist passiert?
Mit dem Wachstum Ihres Unternehmens stieg auch der Verbrauch. Früher wurde in der Geschäftsführung entschieden, dass, falls ein Transporter über seine Kapazität und/oder Gewicht ausgelastet war – was sehr selten vorkam – der Lieferant die Beladung zugunsten von Getränken priorisierte.
Nicht gelieferte Waren wurden in die nächste Bestellung aufgenommen und in einer neuen Lieferung weitergeleitet. Das Vorhandensein eines nicht reduzierbaren Bestands im Lager bei der Taverne erlaubte es, die nicht gelieferten Fälle zu ignorieren.
Im Hafen schloss der letzte Konkurrent, und die nicht gelieferte Lieferung aufgrund einer Überladung des Transporters, die durch eine Priorisierung auf Basis der Annahme über ausreichende Bestände und gelegentliche Unterbeladung des Fahrzeugs umgangen wurde, wurde zur gängigen Praxis. Das geschaffene System wird perfekt nach den darin implementierten Algorithmen funktionieren und wird jede Möglichkeit ausschließen, systematische Planabweichungen zu verfolgen. Nur ein beschädigter Ruf und unzufriedene Kunden können das Problem aufdecken.
Aufmerksame Leser haben sicher bemerkt, dass die bestellte Menge in der Bestellungsspezifikation (T_ORDER_SPEC) in Abschnitt 2 und Abschnitt 5 möglicherweise den Anforderungen der ersten Normalform entspricht oder auch nicht. Dies hängt davon ab, ob bei der gewählten Produktpalette unterschiedliche Maßeinheiten in dasselbe Feld gelangen können.
Verletzung der zweiten Normalform:
Mit dem Wachstum Ihrer Anforderungen erwerben Sie weitere Transportmittel in unterschiedlichen Größen. Im oben beschriebenen Kontext wurde die Erstellung eines Verzeichnisses der Transportmittel als überflüssig erachtet. Infolgedessen interpretieren alle Datenverarbeitungsalgorithmen, die den Bedürfnissen von Lieferung und Lager dienen, den Transport von Waren vom Lieferanten ins Lager ausschließlich als eine Fahrt eines 1,5-Tonnen-Fahrzeugs. Somit erstellen Sie mit dem Kauf neuer Transportmittel dennoch ein Verzeichnis der Transportmittel, jedoch müssen Sie bei der Nachbearbeitung den gesamten Code analysieren, der auf den Transport von Waren verweist, um festzustellen, ob an jedem bestimmten Punkt auf die Eigenschaften jenes Fahrzeugs Bezug genommen wird, mit dem das Geschäft begonnen hat.
Verletzung der dritten Normalform:
Irgendwann beginnen Sie mit der Erstellung eines Loyalitätsprogramms, und es gibt einen Datensatz für einen Stammkunden. Warum sollten Sie beispielsweise Zeit investieren, um materielle Vorstellungen zu erstellen, die aggregierte Verkaufsdaten für einen einzelnen Kunden speichern, nur um diese für Berichte und die Übertragung in analytische Systeme zu nutzen, wenn zu Beginn des Loyalitätsprogramms alles, was den Kunden interessiert, im Datensatz selbst platziert werden kann? Auf den ersten Blick scheint dies keinen Sinn zu machen. Doch immer wenn Ihr Unternehmen beispielsweise neue Vertriebskanäle anschließt, sollte unter Ihren Analysten jemand daran denken, dass es ein solches aggregiertes Attribut gibt.
Wenn Sie jeden neuen Prozess entwerfen, etwa den Online-Verkauf oder den Verkauf über Distributoren, die mit dem gemeinsamen Loyalitätssystem verbunden sind, muss jemand im Hinterkopf behalten, dass alle neuen Prozesse sicherstellen müssen, dass die Datenintegrität auf Codeebene gewährleistet ist. Für eine industrielle Datenbank mit tausenden von Tabellen scheint dies eine kaum umsetzbare Aufgabe zu sein.
Ein erfahrener Entwickler weiß natürlich, wie man all die genannten Probleme behebt, aber meiner Meinung nach besteht die Aufgabe eines erfahrenen Analysts darin, diese Probleme erst gar nicht entstehen zu lassen.
Ich möchte mich für das wertvolle Feedback bei der Vorbereitung der Veröffentlichung bei dem leitenden Entwickler Jewgeni Jaruchin bedanken.
Literatur
Connolly, Thomas; Begg, Caroline. Datenbanken. Gestaltung, Implementierung und Wartung. Theorie und Praxis.
Quelle: habr.com
