Normalisierung einer Datenbank

[Rumpelator]

Hallo,

hier mal eine Frage zu meinem ER-Modell:

Es geht grob darum Wohnungen verwalten zu können

Um eine Wohnung möglichst gut zu beschreiben, muss neben den ganzen Details über die Ausstattung etc. ja auch die Lage beschrieben werden. Sprich unter welcher Adresse, in welchem Hauseingang und in welcher Etage befindet sie sich.

Um Redundanzen zu vermeiden, würde ich diese Attribute nicht in der Entität Wohnung abspeichern, sondern wie im beigefügten ER-Modell zerlegen.

Ist das ERM in der 3. Normalform?

Meines erachtens gibts jetzt keine unnötige Redundanz mehr. Was jetzt noch bleibt ist, bei der Entity Ort evtl. doch statt des zusammengesetzten Primärschlüssels eine Ort _ID als PK zu nehmen und die Einzigartigkeit einer PLZ & Ort Kombination über eine unique constraint sicher zu stellen.

Macht es evtl. auch Sinn in der Entity Strasse auch eine Unique-Constraint für Strassenbezeichnung und die FK´s von Ort zu erstellen?

Hab ich für die Einhaltung der 3. Normalform etwas übersehen?

Danke in Voraus,

Stefan

[baba007]

Hi,

meiner Meinung nach ist deine "Normalisierung" etwas übertrieben.

Was mir sofort auffällt:

- ETAGE ist unsinn, Etage ist ein Attribut einer Wohnung und soll es auch sein

- ein GEBAEUDE hat immer nur eine Addresse, also würde ich Str + Nr + Ort + PLZ einbauen.

- STRASSE und ORT sind aus abfrage-technischen Gründen nicht auszugliedern

- GEBAEUDE braucht Anzahl von Wohnungseinheiten, Baujahr usw.

[Der Kleine]

Hi,

meiner Meinung nach ist deine "Normalisierung" etwas übertrieben.

Einspruch.

Die Stärk der Normalisierung hängt ganz stark vom Einsatzzeck ab. Für eine große Immobilienfirma (Wohnungsverwaltung) kann es viel zu einfach sein. Für jemanden, für den es ausreicht, kann es schon überdimensioniert sein.

- ETAGE ist unsinn, Etage ist ein Attribut einer Wohnung und soll es auch sein

Das kann wiederum falsch sein. Orientieren sollte man sich sicher nach der Arbeitsweise des Auftraggebers, also seine internen Prozesse. Für meinen Vermieter wird über die Etage die Wohnungsnummer und damit die eindeutige Identifizierung der Wohnung geregelt. Ebenso ist die erste Etage meist gewerblich vermietet, so daß der Wohnungswert erst in höheren Etagen annehmbar wird (unten liegt eine Pizzeria).

- ein GEBAEUDE hat immer nur eine Addresse, also würde ich Str + Nr + Ort + PLZ einbauen.

Ups, ich wohne in einem großen Haus mit ganz vielen Eingängen und somit unterschiedlichen Adressen (äh, Hausnummern). Vorstellbar ist sogar, dass das gleiche Gebäude mit unterschiedlichen Hausnummern unterschiedliche Postleitzahlen (ist halt Berlin) hat.

- STRASSE und ORT sind aus abfrage-technischen Gründen nicht auszugliedern

Warum?

Je nach Zweck der Datenbank ist vorstellbar, dass Hausnummer und Straße in getrennten Tabellen, genauso wir PLZ und Ort in getrennten Tabellen verwaltet werden. dass Straße und PLZ nicht das gleiche sein muss, ist bei ca. 14 Bahnhofsstraßen in Berlin logisch.

- GEBAEUDE braucht Anzahl von Wohnungseinheiten, Baujahr usw.

Die Anzahl der Wohneinheiten errechnet sich aber aus der Datenbank, so daß die Aufnahme dieses Feldes einfach nur Redudanz erzeugen muss. Und das Baujahr eines Gebäudes kann auch variabel sein, also bei Aufstockung von Stockwerken, bei Anbau am Grundstück, so daß das Baujahr vielleicht eher einer Wohnung zuzuordnen wäre.

Ergo: Ohne den genauen Sinn des Einsatzzweckes der Datenbank integriert in die bestehenden Prozeßabläufe des Auftraggebers kann man wenig über Sinn und Zweck der Datenbank aussagen. Sofern man etwas ganz allgemeines braucht, sollten sämtliche Möglichkeiten in Betracht gezogen werden und eine Normalisierung deutlich umfangreicher erfolgen.

Sofern es einen vordefinierten Zweck dient, kann es sehr einfach gehalten werden (im Extremfall reicht für manchen Auftraggeber eine Tabelle aus).

Folglich: Ja es sieht schön aus. Über den Rest (ob zweckmäßig) kann man pauschal kaum urteilen.

[dr.dimitri]

Ich kann mich baba007 nur anschließen. Unabhängig von den Anforderungen der Application ist dein Datenmodell extrem unhandlich und bei weitem auch nicht vollständig (ich vermisse z.B. ein Attribut in der Entität "Etage" oder anders gefragt wo steckt dort die Information?).

Wie dem auch sei - die Anwendungsentwicklung wird durch so ein Modell erschwert und schnell wird das ganze auch nicht wenn es mal mehr als ein paar tausen Einträge werden.

Ich würde z.B. die ganze Adresse in eine eigene Entität stecken. Über Plausis kann bei der Eingabe das korrekte Format etc. geprüft werden.

Dim

[Rumpelator]

Ich kann mich baba007 nur anschließen. Unabhängig von den Anforderungen der Application ist dein Datenmodell extrem unhandlich und bei weitem auch nicht vollständig (ich vermisse z.B. ein Attribut in der Entität "Etage" oder anders gefragt wo steckt dort die Information?).

Ja da hast du recht. In dem ERM hab ich in Etage die Anzahl der Wohnungen und in Gebäude die Anzahl der Etagen noch nicht eingetragen. Da hab ich noch überlegt aber noch nicht entschieden, beide jeweils mit reinzunehmen, damit in ein Gebäude nicht zu viele Etagen und in eine Etage nicht mehr Wohnungen eingepflegt werden können als in der Realität vorhanden sind.

Sollte diese Überprüfung die DB oder die Aufsetzende Anwendung machen? Ich wär ja für letzteres aber mein Prof. findets besser wenn die DB so gut wie alles prüft, weil sie es schneller kann/könnte als jede Anwendung, welche dazu sowieso die DB braucht.

Wie dem auch sei - die Anwendungsentwicklung wird durch so ein Modell erschwert und schnell wird das ganze auch nicht wenn es mal mehr als ein paar tausen Einträge werden.

Ich würde z.B. die ganze Adresse in eine eigene Entität stecken. Über Plausis kann bei der Eingabe das korrekte Format etc. geprüft werden.

Eben bei vielen Einträgen. Mein Gedankengang war, dass (m)eine Wohnungsgenossenschaft (meist) nur für wenige, wenn nicht sogar nur einen Ort zuständig ist und somit eher viele Datensätze bei Strassen hat.

Die PLZ und der Ort hätten unter diesen Unständen bei einer kompletten Entität Adresse so gut wie immer die gleichen Werte. Dann noch lange Strassen mit mehr als 200 Hauseingängen...

Wenn das mal keine unnötige Redundanz ist.

Wären die Adressen in meinem Anwendungsfall über Deutschland gleichverteilt, muss ich dir und baba007 natürlich recht geben. Dann würde das Modell die Geschwindigkeit im Vergleich zu eurer Lösung extrem senken.

Ich würde trotzdem schrecklich gerne wissen ob die dritte NF denn erfüllt ist. Ich hab da noch nicht so den Blick für.