[sql] relationales datenbankdesign u. normalisierung

[Dario Linsky]

beim datenbankdesign ist in erster linie das ziel, die daten möglichst kompakt zu speichern, ohne dass irgendwo redundanzen auftreten. redundanzen sind grob gesagt wiederholungen, die sich durch bestimmte techniken vermeiden lassen und dadurch kann speicherplatz gespart werden.

wenn man beispielsweise eine tabelle hat, bei der ein feld als varchar(255) definiert ist, dann macht es wenig sinn, in jedem datensatz erneut den kompletten string in die tabelle zu schreiben. das ist nicht platzsparend und erhöht die fehleranfälligkeit (falls man sich bei einem datensatz vertippt).
um dieses problem zu lösen, kann man eine zweite tabelle anlegen, in der man ein einziges mal diesen string speichert. aus der haupttabelle erstellt man dann eine verknüpfung auf die sog. lookup-tabelle und holt sich von da die daten. dadurch werden eventuelle tippfehler schonmal ausgeschlossen, und das problem der redundanz ist auch beseitigt.

erzeugt lieber eine tabelle mehr und benutzt beziehungen zwischen den tabellen, dann seid ihr nachher auf der sicheren seite.

 

[Arne Buchwald]

Hallo asphyxia,

das ist normalerweise auch richtig, nur, wenn du zum Beispiel eine (Web-)Anwendung hast, wo es primär auf die Performance ankommt, kann es sinnvoller sein, ein paar mehr Felder zu erstellen, damit nicht alle Werte beim Aufrufen neu berechnet werden müssen.

 

[squeaker]

Dann schreibe ich hier mal kurz ein paar Normalisierungskriterien auf. Prinzipiell kann man sagen eine Datenbank ist besser designt je mehr Normalisierungskriterien sie erfüllt (wobei zu beachten ist, dass für die zweite Normalform das Kriterium für die erste enthalten ist).

1. Normalform:
Eine Relation ist in der 1.NF, wenn keines der Attribute eine untergeordnete Relation darstellt und alle Attribute nur atomare Werte besitzen.

Das bedeutet, dass keine zusammengesetzten Attribute in der Tabelle stehen und die eingetragenen Werte keine eigene "Tabelle" bilden dürfen. Dies erreicht man meist durch geschicktes aufspalten in mehrere Tabellen. Ich finde eine DB sollte sich mind. in der 1.NF befinden um gut handhabbar zu sein.

2.Normalform:
Eine Relation ist in der 2.NF, wenn sie in der 1.NF ist und alle nicht zum Schlüssel gehörenden Attribute voll von diesem abhängig sein.

3. Normalform:
Eine Relation ist in der 3.NF, wenn sie in der 2.NF ist und alle Attribute die nicht Teil des Schlüssels sind, von diesem transitiv abhängen.

d.h. alle nicht-Schlüssel Attribute sind vom Schlüssel abhängig und nur vom Schlüssel abhängig. Wenn sich eine DB in der 3ten NF befindet, ist sie eigentlich schon ganz ordentlich designt.

Für mehr zum Thema NF:

http://www.little-idiot.de/mysql/mysql-256.html#normalisierung
http://ffm.junetz.de/members/reeg/DSP/node6.html#SECTION03241000000000000000

 

[Christian Fein]

Original geschrieben von squeaker
Dann schreibe ich hier mal kurz ein paar Normalisierungskriterien auf. Prinzipiell kann man sagen eine Datenbank ist besser designt je mehr Normalisierungskriterien sie erfüllt (wobei zu beachten ist, dass für die zweite Normalform das Kriterium für die erste enthalten ist).

leichte Korrektur an diesem, grundsätzlich richtigen, Satz.

Eine Datenbank ist besser designt je mehr Normalisierungskriterien sie,sinnvoll erüllt!
Es macht kein Sinn eine Datenbank in der 2. Normalform auf Teufel komm raus auf die 4. Normalform umzubasteln wenn sie dadurch zu kryptisch wird.

Aber Datenbankadministratoren sind ein seltsames Völkchen die mich für diesen Satz am liebsten hängen sehen würden

 

[Thomas Darimont]

Hallo!

Das schöne an diesen Normalformen ist ja, dass wenn man mal ein Datenmodell in die dritte Normalform gebracht hat man feststellt das die teuren Joins die Performance so zerhastückeln, dass wieder eine Denormalisierung stattfinden muss um das wieder gerade zu biegen. Normalisierung ist ein gutes Beispiel dafür, dass manchmal eine Theorie in ihrer vollen Bandbreite nicht für die Praxis taugt. Damit will ich nicht sagen, dass Normalisierung schlecht ist, jedoch macht ein Datenmodell nach einer Normalisierung exzessiven Gebrauch von join Operationen welche nun mal mitunter das teuerste sind was man in einer Datenbank tun kann... ;-)

Aber Datenbankadministratoren sind ein seltsames Völkchen die mich für diesen Satz am liebsten hängen sehen würden

Wohl eher nicht, die werden wahrscheinlich verhalten nicken ... ^^

Gruß Tom