Datenhaltungs-Problem

[Philipp Hasenfratz]

Halihallo Andreas

Du musst erkennen, dass "Einfamilienhäuser", "Wohnungen" und "Ferienhäuser" Subtypen von
"Immobilien" sind; sie stehen also in einer ISA (is-a => "ist ein") Beziehung.
Ja, wenn ich es so betrachte, hast DU eigentlich Recht. Das problem war, das die Verschiedenen Regionen firmenintern anders behandelt wurden, und so EIn Ferinhaus in Land 1 eine minimal andere Daten-Struktur aufweist, als in Land 2, udn es gibt tatsächlich Unterschiede. Es geht um die Länder Deutschland(regional, keine Ferienhäuser), Holland(nur Ferienhäuser) und Spanien(nur Ferienhäuser). Das Problem ist, in Spanien gibt es andere Arten von Ferienhäusern, ("Villa", "Finca"...), außerdem haben die Immobilien teilweise andere Attribute, so kommt es z.B. in Spanien öfter vor das ein Haus ein Schwimmbad hat, in Holland dagagan nie. Außerdem ist das noch bei der Eingabe ein problem, z.B. sie Ferienregion, die ist ebenfalls Länderspezifisch, das heißt das müßte ich auch extern in einer oder mehreren Tabellen speichern. Was nach Relationalitäts-GEsichtspunkten auch vernünftig ist, nur bringt das wieder eine gute Vermischung der Daten, wenn ich alle Regionen in einer Tabelle speichere.

Wenn das _SO_ kompliziert und verschachtelt ist, dann würde ich eine Zwischenlösung
vorschlagen. Die Haupttypen getrennt, jedoch kleinere Unterschiede in eine
"Datentyp-Tabelle" auslagern; denn die explizite Aufschlüsselung in einzelne Relationen
wäre zu komplex und würde zuviele Relationen entstehen lassen (was auch nicht Sinn der
Modellierung sein kann).

oder die andere Möglichkeit: Für jedes Objekt eine Relation, welche alle möglichen
Attribute/Spalten enthält (was du vorschlägst).

Das ist mit im Augenblick die sympathischere Variante, da unabghängiger. Wenn ich(oder jemand anders) die Daten aus der Datenbank extrahieren will, wofür auch immer, geht das so mit einer Tabelle recht einfach, mit x Untertabellen die nicht untereinander Kompatibel sind schon schwieriger.

Jein. Du kriegst ja alle Daten mit einem simplen NATURAL JOIN der Tabellen. Und
unabhängiger möchte ich bezweifeln; was wenn ein Attribut dazukommt? - Speicher weg
und zwar für _alle_ Immobilientypen und -arten, auch wenn das Attribut für andere gar
nicht relevant ist.

Mit der ersten Variante bräuchte ich dann nicht eine Tabelle für Ferienhaus, sondern eine pro Typ pro Land.

Hm. Ja, was du nun in eine ISA-Beziehung steckst und somit syntaktisch Trennst, kannst
du entscheiden; das mit den Häusertypen war eine Möglichkeit, da ich dort den meisten
Unterschied vermutete; wenn jedoch die Unterschiede der Länder grösser sind, macht dort
eine Aufsplittung der Schematas mehr Sinn. Die Aufsplittung hat nur einen Zweck:
Redundanz zu vermeiden und macht folglich dort am meisten Sinn, wo die Daten
unterschiedlicher sind.

Das ist zumindest das, was ich dir aus der Modellierung beitragen kann, was du dann
verwendest und der kleinste Aufwand darstellt, muss ich dir überlassen. Ich hoffe das
hilft dir etwas.
Danke das hilft mir, und veranschaulicht das Problem sehr schön.

Mich interessieren vor allem auch Eure Meinungen, wie Ihr das machen würdet, bzw. welche Risiken die beiden Wege bergen.

Meine Meinung hab ich kundgetan. Probleme sehe ich dabei, dass Datenbanken für die
Speicherung statischer Informationen geeignet sind, deine Anwendung jedoch dynamische
Informationen verwaltet, welche besser in einer XML-Datei aufgehoben wären.

Viele Grüsse

Philipp