MySQL DB-Normalisierung

[Matthiasnet]

Hallo,

lt den DB-Normalisierungsregeln sollte man ja eine Tabelle für jedes "Thema" anlegen.
Haben wir die Tabelle benutzer, dann könnte es eine zusätzliche Tabelle Anschrift, Bankverbindung, Einstellungen geben. (wie gehen mal von eienr 1:1 beziehung aus)

Bin gerade dabei eine DB-Strucktur für ein größeres Projekt zu erstellen, dass später auch viele DS haben wird.
Zwar lassen sich die Daten auch in einzelne Tabellen kapseln (da ca. 60 Attribute vorhanden sind), aber bei fast allen Abfragen würde dann auf allen Tabellen von benutzer ein Join gemacht werden.

Macht es hier überhaupt noch Sinn die Tabelle zu normalisieren?
Die Abfragezeit würde durch viele Joins doch auch sicherlich erhöht werden oder?

Grüße
Matthias

 

[ice-breaker]

lt den DB-Normalisierungsregeln sollte man ja eine Tabelle für jedes "Thema" anlegen.

wer hat denn den Mist erzählt?
Man normalisiert solange bis man die 3. NF erfüllt, mit Erfahrung kann man zwar gleich eine DB in der 3. NF erstellen, aber das ist eine anderes Thema.

Schau dir mal in Wikipedia den Artikel zu den Normalformen an.

 

[Matthiasnet]

Gehen wir mal davon aus ich hab eine Tabelle benutzer mit folgenden Atributten:
id, username, passwort, vorname, nachname, strasse, hausnummer, plz, ort, land, newsletter j/n, rechnung j/n, einstellung3 j/n, anmeldedatum

So wie ich das auf wikipedia verstanden hab hätte ich so 3NF drin?
1. jedes atributt hat einen atomaren wertebereich
2. kein Atributt ist von einem anderen Atributt abhängig (also ich kann jedes einzelne Atributt ändern, ohne das ein anderes dadurch falsch wird) und alle Attribute gehören zu "id"(a gehört zu KC)
3. für mich eig. die gleiche erklärung wie 2 (kein Atributt ist von einem anderen Atributt abhängig)...glaube ich hab NF2 dann etwas zu stark aufgefasst oder?

 

[Darklord]

Nein, du hast das noch falsch vestanden.

Dein Newsletter ist zb nicht von deiner Hausnummer abhängig. Das Passwort hingegen wäre abhängig zum Benutername, da diese konkret zusammen gehören und sich somit ein Benuzer identifizieren lässt.
Kann es leider nicht so gut erklären. :>

Wenn ich es noch recht weis und net vertausche ist so, dass
Die 2 NF sagt das alle Attribute vom einem PK abhängig sein müssen.
Die 3 NF besagt das die Attribute auch untereinander in der Tabelle voneinander abhängig sein müssen.
Für eine höhere NF muss natürlich die niedrigere Ebene erfüllt sein.

Ich machs mal am Beispiel von deinen Attributen (nicht vollständig).
id, username, passwort, vorname, nachname, strasse, hausnummer, plz, ort, land, newsletter j/n, rechnung j/n, einstellung3 j/n, anmeldedatum

userid (PK) username passwort ...

ortid (PK) plz ort ...

PLZ reicht nicht als PK da einige Orte die gleiche PLZ haben, daher noch ein extra PK.

PS.: Wie funktioniert der Table BBCode?!

 

[ice-breaker]

Dein Newsletter ist zb nicht von deiner Hausnummer abhängig.

dazu müsste aber die Hausnummer als PK definiert sein, sonst gilt deine Annahme nicht.

Das Passwort hingegen wäre abhängig zum Benutername, da diese konkret zusammen gehören und sich somit ein Benuzer identifizieren lässt.

Passwort und Benutzername sind in diesem Beispiel von der Userid abhängig

Die 2 NF sagt das alle Attribute vom einem PK abhängig sein müssen.

die 2. NF besagt, dass alle Attribute von allen Schlüsselteilen abhängig sind.
Da sein Schlüssel 1teilig ist, braucht man die nicht beachten.

Die 3 NF besagt das die Attribute auch untereinander in der Tabelle voneinander abhängig sein müssen.

Jedes Attribut, welches kein Schlüssel ist, darf nur von einem Schlüssel abhängig sein.
Bis auf die Angabe der Adresse, ist dies auch völlig korrekt. Denn der Ort ist von der PLZ abhängig, die PLZ aber eigentlich auch vom Land.

 

[Darklord]

Passwort und Benutzername sind in diesem Beispiel von der Userid abhängig

Hab ich so gemeint. Ist ja auch so in meinem Beispiel. Hab mich nur falsch ausgedrückt.

die 2. NF besagt, dass alle Attribute von allen Schlüsselteilen abhängig sind.
Da sein Schlüssel 1teilig ist, braucht man die nicht beachten.

Ich dachte Schlüssel sollten nie zusammengesetzt sein? Bzw hab so hab ich es gelernt.
Zum Rest kann ich nur zustimmen.

PS.: Wäre noch nett wenn mir jemand verraten könnte wie man den Tabellen BBCode benutzt. Der hat bei mir irgendwie net hingehauen.

 

[Snyke]

Also erstmal zu der frage wegen Anfrage-Komplexität: diese normalformen sind rein auf Daten Redundanz optimiert nicht auf querytimes.

Zweitens ist die PLZ viel eher in einer Tabelle anzuordnen in der Orte beschrieben werden und das auch nur solange ein Ort genau eine PLZ hat.