Datenredundanz und Normalisierungswahn

Was bedeutet Datenredundanz ?

  • Einzelne Felder weisen gleiche Werte auf

    Stimmen: 0 0,0%
  • Ein ganzer Datensatz ist mehrfach vorhanden

    Stimmen: 0 0,0%

  • Umfrageteilnehmer
    0

Leistkamm2015

Neuer Benutzer
Beiträge
2
Mal Grundsätzlich...
Habe ich das wirklich richtig verstanden?
Wo liegt die Grenze?
Ist es Sinnvoll keine Werte mehr als einmal zu Speichern auch wenn Abfragen dadurch sehr kompliziert werden können?
Speicherplatz bedarf Versus Performence?
 
Werbung:
Hier ein Konkretes Beispiel:
Ich möchte ein Gebäude mit all seinen Eigenschaften darstellen
Gehen wir davon aus dass dieses Gebäude aus 10 verschieden benannten Teilen besteht und dieses Gebäude 8 Stockwerke hat.
Jedes dieser Stockwerke verfügt dann noch über 2x18 Räume also 36.
Nennen wir nun Teil 1 Darwin erhalten wir 8x36 Darwin ( in jedem Stockwerk hat es eine Raumnummer welche dem Gebäudetrakt Darwin zugehört)
Dementsprechend müsste ich Darwin 288 mal speichern was 4608Byte an Speicherplatz benötigt.
Im Vergleich dazu die Erstellung einer Tabelle welche Gebäudeteile beinhaltet und mit Raum und Stockwerk via FK bzw. PK verbunden sind.
Dan bräuchte ich nur noch 1x 6+10=16 Byte und dazu noch 2Byte für den Key, ergibt zusammen 36x18 Byte = 648Byte richtig?

Und nun zur eigentlichen Frage:
Ist diese Denkweise in Bezug auf das ERM richtig?

Auf eure Antwort bin ich schon sehr gespannt, ich hoffe dass ich euch mit dieser Frage nicht langweile..

LG stefan
 
Die Grenze liegt dort, wo die Performance deiner Anwendung den Bach runtergeht, Speicherplatz ist normalerweise billiger als Performance.
Normalisierung ist gut, wichtig und meistens sinnvoll, allerdings gibt es auch Fälle wo man teilweise oder ganz darauf verzichten kann.
In der Realität gibt es nur eine einzige Größe die zählt: Reaktionszeit.
"...ja ich weiss die Abfrage dauert 3min statt 3s. Aber dafür ist alles bis in die 3. NF normalisiert..."
Meinen die User die Performance deiner App ist schlecht, hast du meistens schon verloren.
Im Endeffekt ist es abhängig von den Anforderungen. Solche Diskussionen sind aber eher in der Kategorie "gehört Businesslogik in die DB..", also Religionsfragen.

Zu dem Beispiel, falls ich das jetzt richtig verstanden habe:
(Gebäude, falls es mehrere geben soll), Gebäudeteil, Stockwerk, Raum sind Tabellen, dann noch eine Tabelle für die Relation dazwischen.
Macht schon Sinn so.
 
Es geht bei der Normalisierung nicht mehr um Speicherplatz, sieht man von Spezialfällen ab. Der Sinn der Normalisierung ist ein anderer: Du rennst in vielfältige Probleme, wenn Du nicht normalisierst. Als Beispiel: Hast Du ein normalisiertes DB-Schema, dann kannst Du mit eleganten Querys alle Daten passend abfragen. Im anderen Fall, werden die Querys schmutziger und komplexer. Oder Formular-Generatoren funktionieren nicht wie gewollt, weil sie eben auf ein normalisiertes Modell geeicht sind. Solche Probleme, an die Du jetzt noch gar nicht denkst, tauchen irgendwann auf, wenn Du schon lange begonnen hast und dann werden Umstrukturierungen notwendig.

Ich habe jeden Fall, bei dem ich gedacht habe, "ach, ich häng da einfach noch eine Spalte an, statt der neuen Tabelle.", bereut und später wieder geändert.

Normalisierung ist in der Regel auch keine Frage der Performance. Zumindest in brauchbaren Datenbank-Management-Systemen hast Du Materialized Views, womit sich komplexe (Teil-)Abfragen vorbereiten lassen.
 
Werbung:
Zurück
Oben