Überblick
Was canon ist, wer es nutzt und wie weit die Umstellung der Produkte reicht.
canon ist die gemeinsame Datenschicht von drei Produkten für Schulen:
| Produkt | Aufgabe | Form |
|---|---|---|
| roster | Schülerakte: Stammdaten, Sorgeberechtigte, Laufbahn, Schulwechsel, Förderplanung | Webanwendung |
| score | Noten, Zeugnisse, Abschlüsse | Webanwendung |
| timbra | Stundenplanung, Vertretungen | Desktop-Anwendung |
Der Name kommt vom Canonical Data Model: ein Datenmodell, nach dem alle Beteiligten arbeiten, statt Daten zwischen eigenen Modellen zu übersetzen.
Was canon enthält
- Das Datenmodell als SQL-Migrationen: der gemeinsame Kern (Schema
kern) und je ein Schema für die Fachdaten von roster, score und timbra. - Rechte und Mandantentrennung in der Datenbank, für alle Produkte gleich.
- Ein Go-Modul, das score und roster einbinden: Verbindung, Migration, Rechtekontext je Anfrage.
- Die Kern-API für timbra, als Teil von score und roster, kein eigener Dienst.
- Synthetische Demo-Schulen, die alle drei Produkte gemeinsam nutzen.
canon ist kein eigenes Produkt mit Oberfläche. Eine Schule betreibt score, roster oder beide; canon kommt mit ihnen.
Allein oder im Verbund
Jedes Produkt läuft allein. Ob eine Schule ein Produkt oder mehrere einsetzt, ist ihre Entscheidung und lässt sich später ändern:
- Allein: score und roster haben ihre eigene Datenbank, aber nach demselben Modell. timbra speichert lokal in einer Datei.
- Im Verbund: score und roster teilen sich eine Datenbank, timbra liest und schreibt über die Kern-API. Jede Angabe wird nur an einer Stelle geführt; es gibt keinen Import zwischen den Produkten.
Warum diese drei Produkte zusammengehören: Warum ein Verbund.
Stand
| Produkt | Stand im Verbund |
|---|---|
| score | arbeitet auf canon, bietet die Kern-API an |
| roster | arbeitet auf canon, pflegt Personen, Klassen und Schülerakte, bietet die Kern-API an |
| timbra | Kern-API steht bereit; der Verbund-Anschluss in timbra ist geplant, timbra arbeitet heute allein |
Datenmodell, Rechte und Kern-API sind gegen PostgreSQL 16 getestet. Alle Daten in Entwicklung, Tests und Vorführung sind synthetisch.
Grundsätze
- Betrieb in Deutschland: in deutschen Rechenzentren oder auf Servern der Schule bzw. ihres Trägers.
- Keine anbieterspezifischen Dienste: PostgreSQL ohne Erweiterungen, die nur verwaltete Angebote haben; dasselbe Modell trägt eine Schule und ein ganzes Land.
- Kein Produktwissen im Kern: In
kernsteht nur, was mindestens zwei Produkte brauchen. Länderrecht steht in den Regelpaketen der Produkte, nicht im Datenmodell. - Keine KI-Dienste mit Fach- oder Personendaten.