Moin,

kompliziert, kompliziert. Meine Freundin soll im Studium (Medien) eine Datenbank anhand des Beispiels: "Schule" entwerfen. Also habe ich eine Datenbank entworfen . Das ganze soll bewusst einfach gehalten sein und nur als Beispiel dienen.

Jetzt meint sie, ihr Dozent hätte irgendwann mal etwas erwähnt in Richtung "Keine Kreise im Datenbankdesign" So genau erinnern kann sie sich natürlich nicht, allerdings würden wohl auch Kommilitonen meinen, dass da was gewesen sei, blablabla.

Ich besuche ja deren Unterricht nicht und kann daher auch nur spekulieren - oder eben mal sachkundigen Rat einholen: Ist die Verbindung Schüler-Klasse-Lehrer-AG-Schüler irgendwie dramatisch? meiner Meinung nach macht das schon Sinn, schließlich hat jede Klasse einen Klassenlehrer, jede AG einen Betreuer und jede AG/Klasse auch Schüler als Mitglieder.

Falls nicht: Wie sollte man so etwas denn sonst darstellen?

Moin!

Huarg, meine Datenbankvorlesungen sind schon ein paar Jahre her... Mal sehen, ob ich noch was halbwegs sinnvolles hervorwürgen kann.

FinnO hat folgendes geschrieben :

Jetzt meint sie, ihr Dozent hätte irgendwann mal etwas erwähnt in Richtung "Keine Kreise im Datenbankdesign" So genau erinnern kann sie sich natürlich nicht, allerdings würden wohl auch Kommilitonen meinen, dass da was gewesen sei, blablabla.

Ja, "Azyklizismus" ist tatsächlich ein wichtiges Designkriterium für ein Datenbankschema. Man spricht hier auch häufig von "azyklischen Datenbankschemata" (gib das mal in Google ein, aber Vorsicht, die Links, die ich so gesehen habe, gehen auch gleich schnell in die Tiefe). Sowas geht dann in die Richtung Graphentheorie und landet dann bei einem ADG (azyklischer, gerichteter Graph). Warum schaut man da so genau hin? Das hat was mit Optimierungen zu tun, die man bei azyklischen Schemata machen kann (als Voraussetzung). Man kann bei einem zyklischen Schema ja theoretisch in eine Endlos-JOIN-Beziehung laufen. Das wäre dann für ein SELECT nicht so gut, mal praktisch gesprochen.

FinnO hat folgendes geschrieben :

Ist die Verbindung Schüler-Klasse-Lehrer-AG-Schüler irgendwie dramatisch?

Ja, weil sie theoretisch eine Endlosschleife darstellt, die ein DBMS nicht selbst brechen kann.

FinnO hat folgendes geschrieben :

meiner Meinung nach macht das schon Sinn, schließlich hat jede Klasse einen Klassenlehrer, jede AG einen Betreuer und jede AG/Klasse auch Schüler als Mitglieder. Falls nicht: Wie sollte man so etwas denn sonst darstellen?

Tja, wie auch immer, jedenfalls so, dass kein Zyklus drin ist.

cu
Narses

Ich hab mir das jetzt mal nicht als Datenbankmodell, sondern als Klassenmodell gemalt. Und da ist es nicht zyklisch, ich behaupte also mal dass deine Darstellung "falsch" ist. Das Modell passt schon so.

An einigen Stellen hast du hier beidseitige Beziehungen drin, obwohl die "Rückrichtung" eigentlich nur implizit ist. Bestes Beispiel ist Lehrer<->AG. Egal ob man jetzt die "AG"s als Attribute von "Lehrer" speichert oder den "Lehrer" als Attribut der "AG", das ist ein 1:n (oder n:1). Gleiches bei Fächern.

Oder auch "Fach" zu "Unterrichtseinheit". Die UE hat die Attribute "Lehrer" und "Fach", dann ist der Kreis schon weg.

Ich behaupte: das ist exakt dein Modell:

(Ich weiß, falsches Tool. Daher Legende: "Unterknoten" sind Attribute, + vor dem Attribut bedeutet "Ein oder mehrere", also "Liste". Pfeile sind in Foreign Key-Richtung hin zur Bezugstabelle)

Zu überlegen wäre noch, ob eine AG nicht auch nur eine Unterrichtseinheit ohne eindeutiges Fach ist. Aber das wäre dann eine andere Baustelle

Disclaimer: ich hab sowas nie studiert, also keine Ahnung was Dozenten da hören wollen. Mir ist meistens wichtiger, dass es am Ende verlässlich funktioniert


EDIT: Ergänzung zur Grafik: "Lehrer.Fächer" meint Fächer, die der Lehrer unterrichten kann, was er davon dieses Jahr auch macht steht in "UE.Lehrer". Taktisch unklug benannt, das könnte man falsch verstehen Das mit den AGs und Lehrern könnte man auch genau andersrum machen, s.o.

Der Knackpunkt ist die Umsetzung. So wie bei Martok gibt es kein Problem.

Ein Problem gibt es, wenn nicht die Schüler eine Referenz auf eine Liste der AGs haben, sondern es eine Liste von AGs mit Referenzen auf die Schüler gibt. Denn dann ist es ein Kreis, das Ergebnis wurde ja schon beschrieben.

Zu dem Diagramm (also das erste aus der Frage):
Soll das so dargestellt werden? Irgendwie kenne ich ER-Diagramme oder andere ähnliche Diagramme anders.
Dann würde es diese Unklarheiten auch nicht geben.

IMHO fehlen da einfach ein paar n:m Tabellen

Moin,

ich danke für die Zahlreichen Antworten. Das Problem liegt wohl offensichtlich in dieser vereinfachten Darstellung und es ist wohl auch mein Fehler, dass ich die Darstellung mit den m:n-Tabellen nicht hochgeladen habe.

bummi hat folgendes geschrieben:

IMHO fehlen da einfach ein paar n:m Tabellen

Die habe ich hier weggelassen, es existiert noch ein weiteres Diagramm, das mit den Tabellen und den Beziehungen dargestellt ist.

Martok hat folgendes geschrieben:

Ich hab mir das jetzt mal nicht als Datenbankmodell, sondern als Klassenmodell gemalt. Und da ist es nicht zyklisch, ich behaupte also mal dass deine Darstellung "falsch" ist. Das Modell passt schon so. An einigen Stellen hast du hier beidseitige Beziehungen drin, obwohl die "Rückrichtung" eigentlich nur implizit ist. Bestes Beispiel ist Lehrer<->AG. Egal ob man jetzt die "AG"s als Attribute von "Lehrer" speichert oder den "Lehrer" als Attribut der "AG", das ist ein 1:n (oder n:1). Gleiches bei Fächern.

Mit dieser Begründung hat wohl auch der Dozent o.ä. das ganze abgesegnet.

Martok hat folgendes geschrieben:

Disclaimer: ich hab sowas nie studiert, also keine Ahnung was Dozenten da hören wollen. Mir ist meistens wichtiger, dass es am Ende verlässlich funktioniert

Sehr löbliche Einstellung

Narses hat folgendes geschrieben:

Ja, "Azyklizismus" ist tatsächlich ein wichtiges Designkriterium für ein Datenbankschema. Man spricht hier auch häufig von "azyklischen Datenbankschemata" [...]. Sowas geht dann in die Richtung Graphentheorie und landet dann bei einem ADG (azyklischer, gerichteter Graph).

Ich dreh das Rad.