Umsetzung von Stundenplan und Stundenabrechnung

Hallo,
haben das Programmierprojekt Stundenplan und Stundenabrechnung vor der Brust. Dabei gibt es aber ein kleines Problem für die korrekte Modellierung hinsichtlich von Unterricht und dessen Abrechnung (Schülerzahl relevant!):

Üblicherweise wird Unterricht in einer Klasse erteilt (damit ist dort die Schülerzahl klar), dies ist jedoch nicht ausnahmslos der Fall. Immer häufiger kommt es vor, dass auch bunt zusammen gemischte Lerngruppen aus verschiedenen Klassen in einer Unterrichtsstunde unterrichtet werden müssen. Als Beispiel dienen Intensivierungsstunden. Auch im Sportunterricht trifft dies zu: Dort wird nach Geschlecht getrennt unterrichtet, so dass die Lerngruppen häufig aus mehreren Klassen zusammengesetzt sind. Vertretungs- oder Aufsichtsstunden sind meist überhaupt keinen Klassen zuzuordnen.

Wie ist dies nun am besten umzusetzen?

 

Es gibt eigentlich nur zwei Wege daran zu gehen. Entweder

a) Du bildest für diese Gruppen hilfsweise eigene Klassen ab. Eine Lerngruppe kann dann eventuell Zu- und Abgänge haben oder bei jeder neuen Zusammensetzung gibt es auch wieder eine neue (Hilfs)klasse. Wie dein Frontend diese Klassen erstellt, anzeigt, verwaltet etc. ist dann Sache der Programmierung.
b) Du stellst das Datenmodell um von
Schüler <- n:1 -> Klasse <- n:1 -> Unterricht
auf
Schüler <-n:m-> Unterricht und die Zwischentabelle hat dann auch einen Fremdschlüssel n:1 auf die Klasse der aber NULL sein darf.

 

Hmmh, die Entität "Klasse" lässt sich nur leider nicht komplett aufgeben, hängen doch viel zu viele Informationen dran (Klassenleitung; Stammraum einer Klasse; Raum für Elterabend; ...)

Die Entität Klasse muss also beibehalten werden, die neuen Lernzusammenstellungen ergänzen sozusagen den bisherigen Stand. Momentan haben wir einen Favoriten (siehe zip-Datei "stunden-wochenplan.zip"). Aber gänzlich überzeugt sind wir davon noch nicht...

Vllt könnt ihr uns ja bestärken oder begründet abraten.

 

In beiden Varianten würde die Entität Klasse fortbestehen. Ich denke b) ist die bessere Variante, entscheidend ist die Beziehungstabelle zwischen Schüler, Untericht und Klasse. Man könnte die so definieren das der FK auf Untericht NOT NULL ist und ein FK entweder auf Klasse oder Schüler NOT NULL ist (per Constraint). So kann man ganze Klassen oder nur einzelne Schüler zuordnen.

 

OK - das scheint wirklich besser zu sein als unsere Lösung. Vielen Dank

 

Am Ende ist entscheidend wie die Anwendung funktioniert und der User damit valide Datensätze erzeugt. Theoretisch könnten Schüler so ja doppelt (einmal mit der ganzen Klasse, einmal als Person) einem Untericht zugeordnet werden etc. Unterschätze niemals die Idiotie der Anwender...

 

"Theoretisch könnten Schüler so ja doppelt (einmal mit der ganzen Klasse, einmal als Person) einem Untericht zugeordnet werden"
Man sollte halt genau definieren, was "Klasse" bedeutet.
1) Ist "Klasse" die rein verwaltungstechnische Klammer über eine Gruppe von Schülern?
Als wer ist Klassenlehrer usw. ...
Dann sollte man aber auch für die "Klasse" eine Lerngruppe anlegen mit allen Schülern der "Klasse"
2) Ist "Klasse" auch die Gruppen von Schülern, welche sich trifft und z.B. Räumlichkeiten braucht?
Dann muss natürlich funktional sicherstellen, dass es mit Lerngruppen keine Überschneidung gibt.

Ich würde mal schemenhaft die Masken/Oberflächen malen, die der Endanwender sieht und was er damit machen kann/soll.
Wie ukulele schon schreibt, ein DAU bringt fast alles fertig mit dem der Entwickler nicht gerechnet hat

Gruß Ingo

PS:
"Klasse" in Anführungszeichen weil meine graue Masse sonst mit der Modellierungs-Klasse durcheinander kommt
DAU=Dümmster anzunehmender User

 

@i2stiller:
Hinsichtlich der Programmnutzung ist eine Klasse u. a. Container von Schülerobjekten, also eine Lerngruppe. Natürlich ist sie auch eine relevante Größe im Sinne einer Verwaltungseinheit: Alle Klassenleiteraufgaben und schulorganisatorischen Dinge sind mit dieser Größe ja verbunden...

Da wir - [Wir, d. h. die "AG Programmierung", sind alle Programmierer wider Willen - oder aus freien Stücken (je nach Sichtweise ) und alle mit einschlägiger Vergangenheit ...] momentan stark in unserem eigentlichen Hauptberuf eingespannt sind und Personalausfall zu beklagen haben, wird das Projekt derzeit auf Sparflamme betrieben. Witzigerweise sind Entwürfe rund um die Oberfläche jene Dinge die derzeit aktiv laufen ...

Dem Folgenden kann ich nur zustimmen:

Wie interpretiere ich nun die explizit Erklärung zu DAU?

 

Den DAU braucht man nicht zu interpretieren, der ist eine feste physische Konstante und immer gegenwärtig.