3NF Überführung einer Relation (konkretes Beispiel)

Hallo, ich hoffe mir kann jemand helfen.

Gegeben sei diese Ausgangsrelation:
Abteilung(Abt, AbtNr, Amg, Astandort)

Wobei
Abt die Abteilungsaufgabe beschreibt (Administration, Logistik, Führung, etc)
AbtNr eindeutige Werte aufweist
Amg einen Verweis auf eine Relation namens 'Mitarbeiter' verweist, dieser Leitet die Abteilung
Astandort den Standort einer Abteilung wiedergibt.

Die Relation möchte ich nun in die 3NF bringen.
In der jetzigen Relation wäre Astandorte nicht atomar, da es zum Beispiel diesen Datensatz gibt:
Logistik, 3, 0001, {Wien, Graz, München}

Also muss das Feld Astandort zusammen mit dem PK(AbtNr) in eine neue Relation und das Modell sieht so aus:
Abteilung(Abt, AbtNr, Amg), Standort(AbtNr, Astandort)

Nun die Frage: habe ich mit dieser Lösung nicht auch noch Redundanzen in der Relation Standort? Denn dort kommt dann ja z.B. durch einen zweiten Datensatz in 'Abteilung', die auch auf München verweist, zu doppelten Einträgen. Also verstoß gegen 1NF ?
Um die Redundanz zu lösen brauche ich also noch eine Relation, die zwischen Abteilung und Standort korreliert?
Meine Lösung sieht dann so aus:
Abteilung(AbtNr, Abt, Amg), Abt_St(AbtNr, StandNr), Standort(StandNr, Name)


Ich habe Zweifel, dass das ganze richtig und sinnvoll ist.

 

Du liegst aber völlig richtig. Solange Standort nur aus einer Stadt besteht ist das ganze in der Praxis natürlich nicht sinnvoll. Aber sobald du eine komplette Adresse pflegst macht das ganze auch mehr Sinn.

Theoretisch verstößt du ja schon mit einer Tabelle PLZ + Ort gegen das relationale Modell, da es mehrere PLZ pro Ort geben kann.

 

Danke, bei mehreren Feldern in Standort macht das dann Sinn.

Du meinst weil PLZ von Stadt transitiv abhängig ist?

 

Ich bin nicht so der Mann der Theorie, habe das nur in der Berufsschule gehabt Aber so meinte ich das.

Man muss einfach sehen das zwischen Theorie und Praxis doch häufig Unterschiede bestehen. Natürlich kann ich alles durchnormalisieren, das macht aber auch häufig Dinge komplizierter. Alternativ entstehen auch häufig sehr "unkonventionelle" Modelle dadurch, das irgendwelche Software erweitert wird und den Umbau der DB scheut oder dadurch das Programierer häufig einfach keine Ahnung von Datenbanken haben.