Warum ein Verbund

Schülerakte, Notenverwaltung und Stundenplanung sprechen über dieselben Menschen und dieselben Klassen. Laufen sie als getrennte Programme, führt jedes seine eigene Liste der Schüler, der Lehrkräfte und der Klassen, und jemand muss diese Listen abgleichen. canon dreht das um: Jede Angabe wird nur an einer Stelle geführt, und jedes Produkt arbeitet mit seinem Teil davon.

Drei Aufgaben, dieselben Daten

Jede der drei Aufgaben braucht, was die anderen pflegen:

Daten	roster	score	timbra
Schüler, Sorgeberechtigte	pflegt	liest für Noten und Zeugnisse	nur Anzahl je Klasse, pseudonyme Belegung
Lehrkräfte	pflegt die Person	liest Lehraufträge	pflegt Kürzel und Lehraufträge
Schuljahr, Klassen	pflegt	liest	liest
Fächer, Kurse, Stundentafel	liest	liest (pflegt sie ohne timbra)	pflegt
Belegungen	liest	pflegt	pseudonym
Förderung, Nachteilsausgleich, Notenschutz	pflegt	liest das Kennzeichen	–

Der Weg eines Schülers durch die Schule geht durch alle drei: Aufnahme und Klasse (roster), Unterricht und Kurse (timbra), Leistungen und Zeugnis (score), Abgang und Aufbewahrung (roster). Das sind die drei Bereiche, die fast jede Schule digital führt und die am engsten aneinander hängen. Ein weiteres Produkt, das dieselben Personen braucht, hängt sich an denselben Kern.

Gründe

Keine doppelte Datenhaltung

Ohne Verbund ändert das Sekretariat einen Namen in der Akte, und das Zeugnis zeigt den alten, bis der nächste Export läuft. Eine Lehrkraft wechselt die Klasse, und der Stundenplan weiß es erst nach dem nächsten Import. Jeder Abgleich ist eine Fehlerquelle und eine weitere Kopie personenbezogener Daten.

Im Verbund gibt es zwischen roster, score und timbra keinen Import und keinen Export. Ein Importweg bleibt nur für fremde Systeme, etwa die Schulverwaltung eines Landes.

Ein gemeinsamer Personenkreis

Jeder Mensch ist eine Person, genau einmal. Was er an der Schule tut, sind Verknüpfungen: eine Lehrkraft hat eine Mitgliedschaft an der Schule, ein Kürzel im Stundenplan, Lehraufträge für die Noten und vielleicht eine Klassenleitung für die Akte. Ein Schüler gehört einer Klasse an, belegt Kurse und hat Sorgeberechtigte. Neue Aufgaben fügen neue Verknüpfungen hinzu, keine neue Kopie der Person.

Das trägt auch über die Schule hinaus: Wechselt ein Schüler zwischen zwei Schulen im selben Verbund, übernimmt die neue Schule die vorhandene Person, statt sie neu zu erfassen.

Ein Rechtesystem

Die Datenbank selbst trennt die Schulen voneinander. Jede Anfrage sieht nur die Schulen, an denen die angemeldete Person eine Rolle hat; das gilt für jedes Produkt gleich und auch dann, wenn ein Produkt einen Fehler hat. Die Rolle kommt aus den Mitgliedschaften in der Datenbank, nicht aus der Anfrage und nicht aus dem Anmeldetoken.

Im Verbund melden sich alle Produkte über dieselbe Anmeldung an (Keycloak, ein Bereich für alle). Eine Lehrkraft hat ein Konto, und die Schulleitung vergibt Rollen an einer Stelle. Für besonders schutzbedürftige Daten wie Förderung, Gesundheit oder Kinderschutz legt roster zusätzliche Bereichsrechte darüber, ebenfalls in der Datenbank.

Genau ein Schreiber je Datenart

Für jede Datenart legt die Schule fest, welches Produkt sie pflegt; alle anderen lesen nur. Das prüft die Datenbank bei jedem Schreiben. Zwei Programme, die denselben Datensatz verschieden ändern, gibt es damit nicht.

Daten	mit roster	ohne roster
Schüler und Sorgeberechtigte	roster	score
Lehrkräfte und Personal	roster	score
Schuljahr, Klassen, Zugehörigkeit	roster	score
Fächer, Kurse, Lehraufträge, Stundentafel	timbra, wenn eingesetzt	score
Belegungen	score	score

Ein Protokoll

Änderungen aller Produkte landen in einem gemeinsamen, verketteten Protokoll je Schule und Monat, mit Angabe, welches Produkt geändert hat. Auf die Frage, wer wann an den Daten eines Schülers gearbeitet hat, gibt es eine Antwort aus einer Quelle, nicht drei Teilantworten.

Datensparsamkeit, die nicht an der Oberfläche hängt

Für einen Stundenplan reicht es zu wissen, wie viele Schüler in einer Klasse sind und wer welchen Kurs belegt; Namen braucht es nicht. timbra bekommt deshalb nur Anzahlen und pseudonyme Kennungen. Das regelt die Datenbankrolle, mit der timbra liest: Sie hat auf Namen und Stammdaten von Schülern gar keinen Zugriff.

Weniger zu betreiben

Im Verbund betreibt eine Schule eine Datenbank und eine Anmeldung statt je einer pro Produkt. Die Schnittstelle für timbra ist kein weiterer Dienst, sondern Teil von score und roster. Sicherung, Aufbewahrung und Auskunft beziehen sich auf einen Datenbestand.

Allein bleibt möglich

Der Verbund ist ein Angebot, keine Voraussetzung. Eine Schule, die nur Noten digital führen will, betreibt nur score. score und roster arbeiten auch allein nach dem canon-Modell, nur in einer eigenen Datenbank. timbra arbeitet allein vollständig ohne Server.

Kommt später ein zweites Produkt dazu, ist das ein Wechsel des Betriebs, kein Umbau der Daten. Für Daten aus fremden Systemen und für timbra ohne Verbund gibt es Import und Export als Dateien.

Was noch offen ist

• Löschen einer Person, auf die mehrere Produkte verweisen: Die Fristen der Schülerakte und die Aufbewahrung von Zeugnissen enden zu verschiedenen Zeiten. Heute löscht jedes Produkt nur in seinem eigenen Bereich, nie im gemeinsamen Kern.
• timbra ohne Netz im Verbund: Annahme ist, dass Stammdaten dann nur lesend aus einem Zwischenspeicher kommen.
• Sorgeberechtigte: score und roster führen die Beziehung heute je für sich; ein gemeinsamer Teil im Kern ist vorgesehen.
• timbra im Verbund: Die Schnittstelle steht, der Anschluss in timbra ist geplant.

Technische Einzelheiten: Datenmodell, Rechte und Protokoll, Kern-API.