ER-Modell
-
Hallo.
Ich beschäftige mich gerade mit den Grundlagen der ER-Modellierung und bin immer wieder auf folgendes Beispiel gestoßen:
Ein Schüler besucht eine Klasse.
Eine Klasse wird von mehreren Schülern besucht.Abgebildet wird das in den Beispielen durch eine 1:n-Beziehung.
Nun ist es ja so, dass die Schüler in der Realität ihre KLasse wechseln können.
Nehmen wir einmal an, der Wechsel der Klasse aus zB persönlichen Gründen ist nicht möglich und kein Schüler kann sitzenbleiben, schreitet aber jedes Jahr eine Jahrgangsstufe voran.
So besucht Schüler A vlt die Klasse 11a im Jahr 2020 und im Jahr 2021 die KLasse 12a.
Schüler B kommt von der 11a im Jahr 2020 in die KLasse 12b im Jahr 2021.Wie kann ich so etwas modellieren?
-
Ich verstehe die Frage nicht, denn meiner Meinung nach gibst du die Antwort beim Stellen deiner Frage schon. Wo siehst du ein Problem?
Das Versetzen in andere Klassen ist eine höhere Logikstufe, die Änderungen am konkreten Inhalt vornimmt, aber das grundlegende Modell dass ein Schüler eine Klasse besucht, und eine Klasse von mehreren Schülern besucht wird, ist weiterhin gültig.
-
Gar nicht, das gehört nicht zur Modellierung, weil das sind ja konkrete Daten. In deinem Modell gehört zu einer Entität "Klasse" mehrere Entitäten "Schüler". Mehr modellierst du ja nicht. In deiner konkreten Datenbank hast du dann vlt. Klasse 10, 11, 12 und Schüler A, B, C. Wenn Schüler A plötzlich zu einer andere Klasse gehörst, dann änderst du halt die Zuordnung. An deinem Modell ändert das nix: Schüler A gehört immer noch zu einer Klasse ... nur halt jetzt zu einer anderen konkreten "Instanz" einer Klasse.
Ein einfacheres Beispiel: Ein Schüler hat ein alter ... im Er Modell modellierst dur nur, dass er ein Alter hat ggf. legst du noch einen Wertebereich fest (nur ganzzahlige Zahlen, nur zwischen 0 und 120). Aber der konkrete Schüler A mit seinem konkreten Alter xyz wird nicht im Modell abgebildet, sonst wäre es ja kein Modell mehr
-
Vielleicht hat die Klasse ja auch ein Attribut "Startjahr", sodass du nur "a" speichern musst und das 11a / 12a / 13a immer on the fly berechnest? Dann brauchst du nur etwas in den Daten ändern, wenn jemand sitzenbleibt.
-
Ich möchte später vlt mal wissen, in welcher Klasse ein Schüler im Schuljahr 20/21 war.
Für so einen Fall muss ich dann wahrscheinlich eine n:m Beziehung wählen, oder?
-
@ravenheart_ggg sagte in ER-Modell:
Ich möchte später vlt mal wissen, in welcher Klasse ein Schüler im Schuljahr 20/21 war.
Für so einen Fall muss ich dann wahrscheinlich eine n:m Beziehung wählen, oder?oder
Vielleicht hat die Klasse ja auch ein Attribut "Startjahr", sodass du nur "a" speichern musst und das 11a / 12a / 13a immer on the fly berechnest? Dann brauchst du nur etwas in den Daten ändern, wenn jemand sitzenbleibt.
-
Das klingt nicht solide gegenüber naheliegenden Erweiterungen wie Sitzenbleiben, Schulwechsel, etc.
Stattdessen sollte eine Klasse mehr Information über sich selbst führen als nur ihren Namen. -> Klasse 11a des Jahres 2017 an der Max Mustermann Realschule in Musterhausen
-
Stattdessen sollte eine Klasse mehr Information über sich selbst führen als nur ihren Namen. -> Klasse 11a des Jahres 2017 an der Max Mustermann Realschule in Musterhausen
Ja?
Die Schule wäre für mich eine eigentständige Entität. Da auch Schüler während eines Jahres neu dazukommen können oder die Schule verlassen können (z.B. bei Umzug nach "Weit-Weg-Dorf") muss man für jeden Schüler eh Eintritts- und Austrittsdatum speichern.
-
Man muss sich hier auf jeden Fall überlegen was "die Klasse" ist. mMn. ist das beste eine Klasse so zu definieren dass in üblichen Fällen ein Schüler der nie sitzen bleibt und nie "versetzt" wird immer in der selben Klasse bleibt.
D.h. die Klasse ist dann vielleicht "2017,3" (unveränderlicher Primärschlüssel).
Diese hat dann verschiedene Attribute wie z.B. "Schuljahr=7" und "Suffix=B" die sich ändern können und aus denen der "Display-Name" gebastelt wird wenn man ihn braucht ("7B"). (Bzw. wenn man will kann man den "Display-Name" auch als persistiertes Attribut abspeichern, aber ich würde das vermeiden so lange es nicht notwendig wird.)Ein Schüler hat dann ein Attribut "Klasse" wo seine aktuelle Klasse drinnen steht, also in diesem Beispiel "2017,3".
Änderungen kann man dann mit eigenen Tables tracken. Man kann z.B. für jeden Table einen History-Table anlegen. Der sieht aus wie der primäre Table, bloss dass er zusätzlich noch ein Attribut "Änderungsdatum" hat welches mit zum Primärschlüssel zählt (composite key).
Damit lässt sich für jedes beliebige Datum rekonstruieren ob es einen bestimmten Schüler (aus Sicht der Schule) zu diesem Zeitpunkt schon gegeben hat, in welcher Klasse er damals war, wie die Klasse damals geheissen hat etc.
Bis hierher geht das mit vielen DBMS noch automatisch, z.B. über Trigger die sich darum kümmern dass die nötigen History-Einträge erzeugt werden ohne dass man es überall immer wieder ausprogrammieren muss.
Zusätzlich kann man in solche History-Tables auch weitere Attribute aufnehmen wenn man möchte. z.B. kann man einen Grund für die Änderung reinschreiben. Entweder einfach als Text oder wenn es Sinn macht auch als Verweis auf eine andere Tabelle. Wenn ein Schüler versetzt wird könnte man z.B. eine Tabelle haben wo diese Versetzung als Entity erfasst wird. Die Schüler-History-Tabelle könnte dann ein (nullable) Attribut Versetzungs-ID haben, wo die entsprechende Versetzung verlinkt wird wenn man die Versetzung "manifestiert" (die Klassen-ID der Schüler-Zeile ändert + den dazugehörigen History-Eintrag erzeugt).
Das kann man dann allerdings nicht mehr einfach über Trigger machen.
