Normalisierung

[Cubic]

Hallo,

kann mir bitte jemand erklären, warum eine Normalisierung wie folgt gemacht wird:

tabelle_mitarbeiter(M-ID, Vorname, Nachname, Tätigkeits-ID)

tablle_tätigkeiten(Tätigkeits-ID, Tätigkeitsbezeichnung)

Über solche Beispiele bin ich häufiger gestolpert. Mir ist schon klar, dass normalisiert werden müsste (wenn z.B. zur Tätigkeit immer ein bestimmtes Gehalt gehört). Da in den Beispielen aber nur die Tätigkeitsbezeichnung gespeichert werden soll, könnte ich mir den Aufwand mit der separaten Tabelle doch sparen. Denn über den den Fremdschlüssel habe ich ja sowieso Schlüsselredundanz? Und Abfragen o.ä. über zwei Tabellen sind doch eher langsamer? Oder hat es da irgendwelche Performance-Gründe oder andere Vorteile, die ich übersehe?

Vielen Dank schonmal!

[dr.dimitri]

Wenn mehrer Mitarbeiter die gleiche Tätigkeit machen sollen, bekommen alle die gleiche TätigkeitsID. Würdest Du hier den tatsächlichen Wert speichern wäre das Redundanz von fachlichen Informationen.

oder andere Vorteile, die ich übersehe?

Es ist kein "verschreiben" bei den Tätigkeitsbezeichnungen möglich, ändere ich den Namen einer Tätigkeit wirkt sich das auch automatische auf alle Mitarbeiter aus, die die entsprechende ID eingetragen haben. Ich muss mich um nichts weiteres kümmern.

Dim

[Crash2001]

Sollte ein Mitarbeiter mehrere Tätigkeiten zugeordnet bekommen können, so würde es sich zudem auch noch empfehlen, eine tabelle id_name(M-ID, Vorname, Name) zu benutzen, statt diesen direkt in der tabelle_mitarbeiter zu schreiben.

Die Grösse der Datenbank schrumpft durch Vermeidung von Datenredundanzen, sie wird evtl schneller bei Abfragen, weil die einzelnen Tabellen kleiner werden, du kannst dir z.B. ohne probleme anzeigen lassen, welche Tätigkeiten alle möglich sind, ohne dass die Felder mit den Namen in der abzufragenden Tabelle auftauchen.

Der, wie du es nennst "Aufwand mit der seperaten Tabelle" ist bei der Einrichtung erst einmal höher, dafür aber beim einpflegen der Daten dann wieder einiges geringer und verbraucht weniger Speicherplatz.

Zudem könnten mit der seperaten Tabelle evtl noch andere Tabellen einfach verknüpft werden.

[Cubic]

Wenn mehrer Mitarbeiter die gleiche Tätigkeit machen sollen, bekommen alle die gleiche TätigkeitsID. Würdest Du hier den tatsächlichen Wert speichern wäre das Redundanz von fachlichen Informationen.

Die Redundanz ist doch trotzdem vorhanden, egal ob ich als Wert z.B. 1 für alle Techniker speichere oder eben den tatsächlichen Wert "Techniker"?

Es ist kein "verschreiben" bei den Tätigkeitsbezeichnungen möglich, ändere ich den Namen einer Tätigkeit wirkt sich das auch automatische auf alle Mitarbeiter aus, die die entsprechende ID eingetragen haben. Ich muss mich um nichts weiteres kümmern.

Dim

OK, das leuchtet ein. Obwohl ich mir mit einer Update-/Aktualisierungsabfrage behelfen könnte.

[Crash2001]

Die Redundanz ist doch trotzdem vorhanden, egal ob ich als Wert z.B. 1 für alle Techniker speichere oder eben den tatsächlichen Wert "Techniker"?[...]

Klar kommt die ID1 dann z.B. öfter vor - diese abzuspeichern ist aber doch einiges kleiner, als zum Beispiel "Fachinformatiker Fachrichtung Anwendungsentwicklung", oder um die längste mir bekannte Berufsbezeichnung den Straßenpferdeeisenbahnschienenritzenreinigungsgerätschaftslagerverwaltungsschuppenangestelltengehilfen zu nehmen.

Daher braucht man auch nur eine kleinere Variable pro Eintrag, was Speicherplatz spart.

Bearbeitet 29. Januar 2009 von Crash2001

[dr.dimitri]

Die Grösse der Datenbank schrumpft durch Vermeidung von Datenredundanzen, sie wird evtl schneller bei Abfragen, weil die einzelnen Tabellen kleiner werden

Das die DB evtl. kleiner wird - ok kann sein. Der Aussage, dass die Performance durch Normalisierung schneller wird kann ich mich nicht anschließen. Es ist ganz im Gegenteil so, dass es praktisch keine umfangreicheren Datenbanken gibt, die sich 100%ig in der 3. NF befinden, da die vielen Joins die Abfragen extrem unperformant machen. Daher wird auch gezielt wieder denormalisiert. Normalisierung macht man nicht aus perforancegründen.

OK, das leuchtet ein. Obwohl ich mir mit einer Update-/Aktualisierungsabfrage behelfen könnte.

Man kann vieles tun, aber wenn man eine relationale Datenbank verwendet, dann sollte man sie auch richtig verwenden. Bei 2 Tabellen und einer handvoll Datensätzen mag das noch überschaubar sein wenn man ein bissl schlampig arbeitet. Wenn du ein DB-Modell mit 40,50 oder 200 Tabellen und zig Millionen Einträgen hast, dann wirst Du das anders sehen.

Dim

[Crash2001]

Das die DB evtl. kleiner wird - ok kann sein. Der Aussage, dass die Performance durch Normalisierung schneller wird kann ich mich nicht anschließen. Es ist ganz im Gegenteil so, dass es praktisch keine umfangreicheren Datenbanken gibt, die sich 100%ig in der 3. NF befinden, da die vielen Joins die Abfragen extrem unperformant machen. Daher wird auch gezielt wieder denormalisiert. Normalisierung macht man nicht aus perforancegründen.[...]

Ich habe nirgends geschrieben, dass sie in der 3ten Normalform sein muss.

Und ich habe auch nicht geschrieben, dass sie dadurch IMMER schneller wird. Aber bestimmte Abfragen werden schneller, da weniger Daten transportiert werden müssen dabei.

Klar brauchen Joins immer etwas Zeit, aber evtl dennoch weniger Zeit, als das über eine unnormalisierte Tabelle zu gehen. Das kommt ganz auf die Tabelle und die Abfrage an.

Stell dir z.B. einmal vor, du willst die Abfrage machen, welche Berufe alle vorkommen.

1.) komplett unnormalisiert: Du müsstest jede Zeile der Datenbank durchgehen und sie mit allen vorhergehenden vergleichen, um die Berufe auflisten zu können

2.) normalisierte Datenbank: Du gibst einfach die Tabelle "tablle_tätigkeiten" aus.

Na, welche Abfrage ist wohl schneller?

Ach ja - Normalersierung kann man durchaus aus Performancegründen machen - es ist jedoch nicht das Allheilmittel für Performance, sondern es hängt immer von den Tabellen und den Abfragen ab.