1:n Beziehung relational umsetzen

[smirk_mirkin]

Angenommen man möchte Daten zu Häusern mit mehreren Räumen speichern.
Zwischen Haus und Raum besteht eine 1:n Beziehung.
Nun kommt man auf die Idee, die Häuser doch noch in Funktionsbereiche zu unterteilen:
Haus -> Funktionsbereich -> Raum
Dabei soll jeder Raum nur genau einem Funktionsbereich angehören, also auch wieder 1:n.
Eine Tabelle für mögliche Funktionsbereiche existiert schon, die Tabelle FUNKTION.
Welche Variante ist wann besser und warum?

Tabellen:

HAUS
id
...

FUNKTION
id
beschreibung



+Variante 1:

FUNKTIONSBEREICH
id
hausid
funktionsid

RAUM
id
...
funktionsbereichid



+Variante 2:

RAUM
id
hausid
funktionsid

 

[Tom.S]

Hmm, so spontan würde ich sagen: Es müsste erst der genau Zusammenhang von Funktion und Funktionszusammenhang erläutert werden. Ist das eine 1-zu-1-Beziehung? Und die Funktionstabelle könnte eigentlich auch in die Funktionsbereichs-Tabelle gezogen werden?
Möchtest Du eine klare Hierarchie Haus -> Funktionsbereich -> Raum haben und das auch in dem Datenmodell ausdrücken, dann ist Variante 1 klar vorzuziehen. Wenn es nicht nur ein Beispiel ist, könnte ich mir aber vorstellen, dass es mit einer solchen Hierarchie schnell Probleme gibt: Gehört ein Studio-Raum dem Wohn- oder dem Schlaffunktionsbereich an? Was ist mit einer offenen Wohnküche im Wohnzimmer? Um solche Probleme zu vermeiden, würde ich die Hierarchie auf Haus -> Raum beschränken und dem Raum 1-n Funktionsbereiche zuordnen.
Ich hätte dann:

HAUS
id

RAUM
id
hausid

FUNKTION
id
beschreibung

FUNKTIONSBEREICH_RAUM_zu_FUNKTION
id
raumid
funktionsid

 

[smirk_mirkin]

Danke für deine Antwort!

Funktionsbereich zu Funktion sei wirklich nur eine 1:1 Beziehung.
Von daher wäre dein Vorschlag schon zu kompliziert
Die FUNKTION-Entität wird auch an anderer Stelle in der Modellierung benötigt.
Außerdem soll so definiert werden, welche Funktionen für einen Funktionsbereich überhaupt möglich sind.

 

[Tom.S]

Funktionsbereich zu Funktion sei wirklich nur eine 1:1 Beziehung.

Dann würde ich zu Deiner zweiten Variante greifen. Einfach aus dem Gedanken heraus, dass die Funktion eher eine Eigenschaft des Raumes ist und keine zwingende Hierarchie. Sprich, es wird auch ganz oft nur Abfragen nach dem Raum geben, und nicht nach dem Funktionsbereich. In Variante 1 müsstest Du diesen dennoch reinjoinen. Eine hierarchische Anordnung macht nur dann Sinn, wenn sie auch in den Abfragen so verwendet würde: Ein Kunde sucht sich erst das Haus aus, dann den Funktionsbereich und dann das Zimmer. So wird es aber wahrscheinlich nicht sein, sondern es werden alle Zimmer eines Hauses in der ersten Etage abgefragt oder alle Zimmer mit gelber Wandfarbe etc. Das heißt Dinge wie Wandfarbe, Etage oder eben Funktion würde ich als Eigenschaften ansehen, die außerhalb der Hierarchie stehen sollten, entsprechend der Variante 2.

 

[smirk_mirkin]

Ich muss zugeben, ich habe das Beispiel nur so gewählt, da es einfach zu verstehen ist.
In meinem praktischen Problem muss ich analog Prüfungen modellieren.
Eine Prüfung besteht aus Fragen, diese bestehen aus Antworten.

EXAM
id
date
focus_id

EXAMQUESTION
id
exam_id
questiontext
answertext
...

EXAMQUESTIONRESULT
id
examquestion_id
student_id
iscorrect
...

FOCUS // ist ein Themenkomplex
id
title

Bisher war Themenkomplex "gleich" Prüfung wie oben.
Nun soll es Prüfungen geben, die aus mehreren Themenkomplexen bestehen.
Es stellt sich also dieselbe Frage wie oben: hierarchisch anordnen oder einfach als Attribut von EXAMQUESTION speichern?
Rahmenbedingung: Da die Themen einer Prüfung als Titel fungieren, werden dauernd die zu einer Prüfung gehörenden Fokusse abgefragt.
Demzufolge liegt der Vorteil wieder bei hierarchisch, denn sonst muss man ja alle Fragen durchgehen, oder?