Normalisierung in Unternehmen

[Unbegabt]

Hallo zusammen,

ich mache aktuell eine Umschulung zum FIAE und habe fast das erste Lehrjahr hinter mich gebracht.
Zum üben für die AP2 habe ich mir in der Urlaubszeit ein Projekt rausgesucht bei dem ich die AP2 einfach mal durchspiele.
Sprich ich mache alles wie ich es dann auch machen werde, planen, umsetzen und Dokumentieren grob vereinfacht ausgedrückt, nur mit einem anderen Projekt.

Ziel ist ein Inventory Managment System (IMS) zur Verwaltung der Hardware im Unternehmen (Wir haben natürlich schon eines, ich will nur üben)

Mein Ausbilder meinte es wäre good practice mit der Datenbankstruktur anzufangen, also habe ich mich hingesetzt und habe aufgeschrieben was soll es alles geben,
habe das unter Einhaltung der Normalisierungsregeln angefangen runterzubrechen und, zu übungszwecken, in Access angelegt.
Beziehungen eingetragen und dann einfach mal mit Daten gefüllt um zu schauen ob das so klappen würde.

Funktionierte Prima also ab an die App.

Mittlerweile habe ich festgestellt, war mir zwar klar aber irgendwie nicht bewusst, wenn ich bis in Normalform 3 gehe,
habe ich entweder extrem viele Anfragen an die DB um mir zum Beispiel die Nutzer zu ziehen oder aber ich erstelle Views
die ich als Datenquelle nutze oder aber ich gehe eben nicht bis N3 und es ist weniger Wartbar und neigt zu Redudanzen und inkonsitenzen.

Nach Rücksprache mit einem Kollegen meinte dieser
"Normailisierung ist halt eher so ein Akademiker Kram. Ich glaube nicht das es Unternehmen gibt die bis NF3 gehen"

Nun meine Frage an euch

Quelle: https://de.wikipedia.org/wiki/Normalisierung_(Datenbank)

[0x00]

Ich habe bis zur "3. NF" angekreuzt, aber es kommt drauf an.

Bei einem Inventory Management System oder generell jedem System wo Datenintegrität die höchste Priorität hat würde ich immer zur 3. NF greifen - deswegen auch meine Antwort.

Wenn statt der Integrität z.B. die Performance im Vordergrund stehen soll (und daraus schlussfolgernd auch kleine Inkonsistenzen akzeptiert sind), dann kann man die Normalisierung auch mal vernachlässigen. Dann benutzt man aber i.d.R. auch keine relationalen Datenbanken mehr.

Für so kleine Datenmengen wie bei dir würde ich zwecks der Konsistenz immer die 3. NF nehmen. Die komplexeren Queries sind ja mit etwas Übung auch schnell erstellt. Aus Faulheit hier auf die 3. NF zu verzichten halte ich für fatal.

Generell sollte man keine Regel einfach nur immer stumpf anwenden sondern stets hinterfragen welches Problem die Regel lösen will.

Bearbeitet 28. Juni 2022 von 0x00

[pr0gg3r]

Wie @Whiz-zarD beschrieben hat, ist eine Datenbank nur ein Aspekt einer Anwendung. Es greift auch irgendwie alles ineinander (UI, Prozessmodelle, Datenbankmodelle, Business Cases, ...) und jeder einzelne Aspekt deckt nur einen Teil der Anwendung ab, der aber mit anderen verzahnt ist. Es gibt ja nicht Umsonst den Begriff "overengineering" und so kann auch eine Datenbank so ausgeklügelt sein, dass jede noch so in Frage kommende Eventualität abgedeckt wird, um ja auf alles gewappnet zu sein. Dann mag zwar das Datenbankmodell astrein (=3. NF) sein, aber die Entwicklung wird zur Katastrophe wenn man mal über 5 Tabellen joinen und gruppieren und distincten muss, nur weil eine Eventualität (die vermutlich überhaupt nicht eintritt) im Datenbankmodell berücksichtigt wurde. Der nächste Punkt ist dann natürlich auch die Performance. Ein Twitter, wo ein Tweet bei zig hunderttausend Followern angezeigt werden muss, baut man nicht in der 3. NF (und auch garnicht mit relationalen Datenbanke, aber nur mal so als Beispiel), aber deshalb kann man dann z. B. halt nicht seinen Usernamen ändern.

vor 8 Stunden schrieb Unbegabt:

"Normailisierung ist halt eher so ein Akademiker Kram. [...]"

Würde ich so nicht sagen. Ich als Akademiker (endlich kann ichs mal heraushängen lassen ;) habe eher gelernt, Dinge zu hinterfragen. In diesem Fall z. B., welche Datenbankart Sinn macht oder ob eine 3. NF überhaupt Sinn macht. Es ist dann eher so, dass ich in Unternehmen gehe und sehe, was die alles so mit relationalen Datenbanken machen, weil es halt schon immer so gemacht wurde und nicht weil es für den Zweck nützlich ist. Datenbank: relational. Was anderes trifft man selten an. Und es wird auch selten hinterfragt. Liegt denke ich daran, dass sowohl in der Ausbildung als auch im Studium meistens relationale Datenbanken gelehrt werden. Und oft machen sie ja auch Sinn.

vor 8 Stunden schrieb Unbegabt:

Ich glaube nicht das es Unternehmen gibt die bis NF3 gehen

Alles schon gesehen. Wobei man ja nicht sagen kann, "nur NF3 ist richtig" oder "NF3 braucht niemand".

vor 8 Stunden schrieb Unbegabt:

Mittlerweile habe ich festgestellt, war mir zwar klar aber irgendwie nicht bewusst, wenn ich bis in Normalform 3 gehe,
habe ich entweder extrem viele Anfragen an die DB um mir zum Beispiel die Nutzer zu ziehen oder aber ich erstelle Views
die ich als Datenquelle nutze oder aber ich gehe eben nicht bis N3 und es ist weniger Wartbar und neigt zu Redudanzen und inkonsitenzen.

Wilkommen in der Welt der Komplexität. Man hat es in der IT oft so, dass man zwar ein Problem löst, dann aber an anderen Stellen weitere Probleme schafft. Die Kunst ist dann garnicht, alle Probleme zu verhindern sondern zu wissen, welche man lieber in Kauf nehmen möchte und dabei gleichzeitig die Komplexität überschaubar hält. Allerdings löst du ja erst mal kein Problem, wenn du die 3. NF anwendest, aber schaffst dir andere. Das ist nur mit Menschenverstand zu lösen.

@Unbegabt: du stellst die richtigen Fragen, für die Ausbildung bzw. die Prüfung wird aber so gut wie immer die 3. NF verlangt. Da gehts ja auch eher um Abstraktionsvermögen. 

[MartinSt]

Lass die Finger von Access, wenn Du was mit DB machen willst.

Der SQL Standard ist aus den 90er Jahren und die Performance grottig.

Eine Software die Fehler-Meldungen wie "Abfrage ist zu komplex" ausgibt, hat mit Datenbank nix zu tun.

[SR2021]

Ich bin da voll bei @0x00 und das mit dem gesunden Menschenverstand lassen wir mal so dahingestellt...
Es kann immer Situationen geben, in denen Änderungen an einem System nötig werden, die bei der ursprünglichen Konzipierung nicht bedacht oder als nicht relevant betrachtet wurden. Daher lieber direkt richtig machen.

[allesweg]

Je nach Arbeitgeber bzw. teils sogar je nach Ownership schwankte es zwischen "was ist Normalisierung?" über "Normalisierung mit gesundem Menschenverstand" bis 3. NF. 

[MartinSt]

Kein Kunde kauft (d)ein Produkt weil die DB in der 3. NF ist. Der Kunde will seine Arbeit effizient erledigen und du bist genau auf den Widerspruch zwischen Theorie und Praxis gestossen.

Wie schon gesagt: Normalisierung mit gesundem Menschenverstand. Wissen, welche Abfragen wie häufig passieren und wie dabei das erwartete Antwortverhalten ist und am aller Wichtigsten: Im Live-Betrieb monitoren, welche Abfragen Zeitfresser sind und dort optimieren.

Zur Inventarisierung selbst würde ich dazu tendieren, eine JSON-fähige DB einzusetzen, also wieder ein Punkt gegen Access.

 

[Whiz-zarD]

vor 3 Stunden schrieb Unbegabt:

Mein Ausbilder meinte es wäre good practice mit der Datenbankstruktur anzufangen, also habe ich mich hingesetzt und habe aufgeschrieben was soll es alles geben,

Sehe ich persönlich inzwischen anders. Die Datenbank sollte nur ein Detail der Anwendung sein. Sie ist ja nur dazu da, um die Daten zu persistieren. Sie sollte daher nicht im Mittelpunkt der Anwendung stehen und das tut sie, wenn man damit anfängt, weil man sein Datenmodell so baut, wie es die Datenbank haben will.

Welche Normalform angebracht ist, ist auch immer vom Fall zu Fall unterschiedlich. Im DWH benutzen wir zwar auch die 3. Normalform (alles darüber macht wenig Sinn) aber um die Daten besser analysieren zu können, haben wir daneben noch ein Datenmodell in 1. Normalform, weil die Zugriffe schneller und die SQL-Queries einfacher sind.

Das Problem bei relationalen Datenbanken ist auch, dass ihre Darstellung der Daten nicht zur Objektorientierung passen und man erstmal wieder umständlich zwischen beiden Darstellungen wandeln muss. Das ist dann die Aufgabe von einem sog. O/R-Mapper. Dokumentenbasierte Datenbanken passen eher zur Objektorientierung, sodass ein O/R-Mapper sogar überflüssig ist.

Bearbeitet 28. Juni 2022 von Whiz-zarD

[SoL_Psycho]

Ich bin ganz ehrlich: 3te NF haben viele nicht mal gehört.
Vieles in großen Firmen wird auch noch über Excel und / oder Access gelöst. Und das nicht mal schlecht, da es einfach das gewünschte Ergebnis bringt.

Man muss halt verstehen, dass der ganze Krams kein Selbstzweck ist, sondern ein Werkzeug. Und dann nimmt man das Werkzeug, was am Besten geeignet ist für den spezifischen Zweck.
Sei es nun Excel, Access, rel. DB mit 3ter NF oder was auch immer. Hauptsache das Ergebnis passt (und das Tool in die Landschaft)

[allesweg]

Wer 3. NF noch nicht einmal gehört hat, möge bitte weiterhin Access als Datenbank verwenden.

[Whiz-zarD]

vor 23 Minuten schrieb SoL_Psycho:

Man muss halt verstehen, dass der ganze Krams kein Selbstzweck ist, sondern ein Werkzeug. Und dann nimmt man das Werkzeug, was am Besten geeignet ist für den spezifischen Zweck.
Sei es nun Excel, Access, rel. DB mit 3ter NF oder was auch immer. Hauptsache das Ergebnis passt (und das Tool in die Landschaft)

"Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel."

[Unbegabt]

@allesweg Also für Azubis finde ich das (Access) gar nicht mal schlecht. Man sieht alles Microsoft mäßig übersichtlich und versteht zusammenhänge wie Beziehungen vielleicht schneller als wenn man direkt in einer PLSQL oder was weiß ich Datenbank rumwerkelt.
Und für den Datenbankzugriff muss man sein Hirn mal verwenden oder richtig suchen. Beides Fähigkeiten die bei der Ausbildung richtig helfen sollen

Für Produktiv System bin ich ganz klar der gleichen Meinung.

@pr0gg3r Vielen Dank für deine Ausführung, wichtige Aspekte die ich so noch nicht auf dem Schirm hatte.

Unterm Strich, ich warte mal weitere Antworten ab, werde ich das Projekt aber definitv nochmal bauen alleine schon weil ich es in diversen Sprachen umsetzen kann und, vor allem für mich nach der Ausbildung, auch mal mit Front- und Backend.


Danke das Ihr euch die Zeit genommen habt für die Antworten. Tolle Community!

 

Bearbeitet 29. Juni 2022 von Unbegabt

[allesweg]

vor 20 Minuten schrieb Unbegabt:

Microsoft mäßig übersichtlich

🤣

 

 

Visualisierung eines Datenbankschemas geht mit den entsprechenden Tools auch mit echten Datenbanken. Teils sind diese Visualisierungstools bereits enthalten...

[SoL_Psycho]

"Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel."

...stimme ich zu.

Es gibt aber andersherum genauso viele ITler die Probleme unbedingt mit dem neuesten heißen Trend lösen wollen. Egal, ob es besser passt, als bisherige Tools

[JimTheLion]

vor 17 Stunden schrieb Unbegabt:

Nach Rücksprache mit einem Kollegen meinte dieser
"Normailisierung ist halt eher so ein Akademiker Kram. Ich glaube nicht das es Unternehmen gibt die bis NF3 gehen"

Den Kollegen würde ich in Zukunft nichts mehr fragen.

 

Ich bin da bei 0x00, in der Regel werden die Daten bei uns in 3. NF gehalten. Wenn es Sinn macht wird das Schema aber abweichend von den Normalformen angepasst, z.B. wenn absehbar ist, dass an gewissen Stellen mit einer gewissen (und realistischen) Datenmenge die Performance leiden wird.

[daluqi]

Mir hat bei der Datenbankvisualisierung bisher Schemacrawler sehr gute Dienste geleistet. Bei Datenbanken, die zu alt / wenig verbreitet waren, musste ich eben mit Mysql Workbench manuell Hand anlegen.