Hallo,
On Fri, 19 Feb 2010 18:08:15 +0100 Robert Großkopf wrote:
> > Am 19.02.2010 16:53, schrieb Robert Großkopf:
> > > Ich habe die Relationentabelle meiner Vereinsdatenbank (speziell
> > > gemünzt auf einen Kanusportverein mit Vereinsheim, also incl.
> > > Bootsständer- und Schlüsselverwaltung) einmal online zugänglich
> > > gemacht. Ich transportiere gerade diese Datenbank von
> > > MySQL/PHP/Apache auf OpenOffice Base.
> > >
> > > /robert.familiegrosskopf.de/download/Verein_Relationen.png
> >
> > die Aufteilung der Mitgliedsdaten in eigene Tabellen für Mitglied,
> > Adresse, Postleitzahl und Ort gibt mir Rätsel auf.
> > Sind das nicht eindeutige Zuordnungen? Die gehören dann als
> > 1:1Beziehungen wohl eher nicht in getrennte Tabellen. Die
> > Aufteilung von Ort und Plz ist für die Adresse doch kaum sinnvoll,
> > da beides eindeutig zugeordnet ist. Es wird keinen Fall geben, wo
> > für eine Adresse einem Ort eine andere Plz zugeordnet werden kann.
>
> Ich drösel das einmal von hinten auf:
> Wenn Du in einer etwas größeren Stadt wohnst gibt es für die Stadt
> gleich mehrere Postleitzahlen. Für meinen Heimatort mit 70000
> Einwohnern sind das 3 Postleitzahlen zuzüglich der Postleitzahl, die
> an die Postfächer geht (steht nicht im Postleitzahlenbuch...)
> Die Ort - Postleitzahlen-Zuordnung ist also eine 1:n-Zuordnung -
> zumindest aus der Sicht der Post, der die Vorortsnamen egal sind.
Das kann man so aufsetzen, wenn man die Orte für die Adressen wirklich
trennt. Gibt es einen Fall, wo dies sinnvoll ist? Ansonsten kann man
eine Adresse als einen Datensatz behandeln und schreibt diese Daten
in eine Tabelle in eine Zeile.
Die getrennte Abbildung von Orten und PLZen hat den Nachteil, dass man
nicht sehr gut Stadtteile oder ähnliches abbilden kann, erst Recht
nicht, wenn man die von der Post gelieferten Magnetbanddaten zu Grunde
legt.
> Straßen sind von den Orten und Postleitzahlen recht unabhängig, da
> gleiche Bezeichnungen in unterschiedlichen Orten auftauchen. Also
> gehören die nicht in diese Reihe.
Die eigentliche Frage ist: will ich Orte, Straßen und Hausnummern
getrennt ansprechen? Oder will ich Adressen speichern. Beim zweiten
Fall würde sich nämlich folgendes Problem von alleine erledigen:
> Die Adressen werden separat erfasst, weil zumindest in unserem Verein
> zwar 500 Mitglieder, aber nur ca. 270 anzuschreibende Adressen
> existieren. Liegt einfach daran, dass natürlich Ehepaare und Familien
> mit gleichen Adressen auftauchen.
Wenn ich die Adresse als Datensatz speichere, verweise ich auf genau
einen Datensatz. Dann ist dieses Problem keines mehr. Außerdem:
> Deswegen will ich natürlich die Adressen nicht zweimal schreiben und
> auch beim Umzug nicht doppelt korrigieren.
Doppelte Adressen gäbe es dann nicht mehr, das würde ein
Unique-Constraint verhindern. Bei einem Umzug entscheidet man entweder,
ob die Adresse geändert wird oder ob eine neue Adresse angelegt und die
Verknüpfung geändert wird. Beides ist möglich
> Wenn nur Teile der Familie umziehen, muss ich hier eine
> Abfrage einbauen "Sollen alle Adressen der Familie geändert werden?".
Der aktuelle Aufbau lässt aber imho auch keine sauberen "Umzüge" eines
Teils der Familie zu.
So, genug Datenbanktheorie ;-)
Es ist immer ein Abwägen zwischen der reinen Lehre der Normalisierung
und dem praktischen Einsatz. Stark normalisierte Datenbanken sind in
der Regel sehr performant ansprechbar, brauchen aber auch
administrativ mehr Platz (zusätzliche Indexes ect) und verkomplizieren
das Erklären des Datenmodells.
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
