Schulverwaltungssoftware NRW

Woran kann es liegen, wenn SchILD-IDs nur dreistellig und nicht vierstellig sind?

Lassen sich die IDs irgendwo neu schreiben?

Nicht-vierstellige IDs habe ich bislang noch nie gesehen.

Ich nehme an, Sie meinen die interne ID-Nr., also die Spalte ID der Schueler-Tabelle. In der Datenbank ist das Attribut (welches gleichzeitig der Primärschlüssel der Tabelle ist) einfach mit dem Datentyp Zahl versehen und wenn ich das richtig beobachte, wird die Nummer einfach inkrementiert. In einer leeren Datenbank dürfte der erste Schüler somit die interne ID 0 oder 1 bekommen. In unserer Datenbank gibt es immerhin die ID 6, also einstellig. Die meisten Schulen, die Schild schon jahrelang nutzen dürften nur inzwischen so viele Schüler in der Verwaltung haben, dass die aktiven Schüler i. d. R. vier- oder gar fünfstellige IDs haben.

Ah, ärgerlich. Ich hatte bislang immer angenommen, der beginne bei 1000 und gehe dann bis 9999 und rollt schließlich zu 1000 über, damit die IDs immer vierstellig sind. Wenn der bei 0 anfängt...

Das Problem hier ist, dass Pedav für das "digitale Klassenbuch" wohl vierstellige IDs fordert, die halt, wie es nun scheint, SchILD im Regelfall rein zufällig liefert, da Schulen erst nachdem schon 1000 Schüler einmal durch das System gelaufen ist zu deren Produkt wechselt.

Hat wer eine gute Idee, was hier zu tun sein könnte?

Vielleicht hilft es, beim Export zu jeder SchILD-ID die Zahl 1000 zu addieren?

An so etwas dachte ich auch schon - ich habe erst einmal die Schule gebeten bei Pedav zu erfragen, ob führende Nullen auch gingen, dann könnte ich mit einer Tabellenkalkulation aus 123 halt 0123 machen.

1000 zu addieren finde ich auch gut, erzeugt aber ab 9000 in ein paar Jahren - sofern noch dieses Produkt mit seinen ungeschickt designten Voraussetzungen verwendet wird - mit IDs >9999 neue Probleme. Tut mir etwas weh, da ich ja gerne an Randbedingungen denke.

Frodermann hat geschrieben: Mittwoch 27. November 2024, 19:52 Hat wer eine gute Idee, was hier zu tun sein könnte?

Pedav informieren, dass sie von einer falschen Prämisse ausgegangen sind und ein Update bereitstellen müssen...

Der Fall zeigt - meiner Meinung nach - aber ein großes Problem des SchILD-Universums, das immer wieder für Probleme sorgt (z. B. auch beim Reporting): Die Datenbasis ist einfach nicht vernünftig dokumentiert! Es gibt für die zugrundeliegende Datenbank kein hinreichendes Datenmodell in Form eines ER-Diagramms, dem die Entitätsmengen, deren Attribute und Beziehungsmengen vernünftig und übersichtlich zu entnehmen sind. Gleichsam steht keine Übersicht für die Attribute bereit, der man entnehmen könnte, welchen Wertebereich einzelne Attribute besitzen und was in welcher Weise codiert wird etc.
Ich weiß als Informatiker natürlich, wie lästig das ist, aber leider ist es gerade bei komplexen Strukturen unerlässlich und würde vielen Problemen vorbeugen.

Zur Dokumentation. Das ist in Teilen richtig, aber etwas hat sich daran auch getan. Schauen Sie sich mal die Schild-3-Maria-DBs an. Da sind viele Infos zu den Feldern bereits ergänzt worden. Und der Wertebereich von IDs ergibt sich aus dem Type der Spalte.

Wie ein Software-Unternehmen wie die Untis-AG auf die Idee kommen kann, dass die ID mindestens/genau (?) vierstellig sein muss, erschließt sich mir nicht. Das ist ein Support-Fall.

Frodermann hat geschrieben: Mittwoch 27. November 2024, 19:52Das Problem hier ist, dass Pedav für das "digitale Klassenbuch" wohl vierstellige IDs fordert,

Woher stammt denn diese Information?

Wir synchronisieren Schild mit Untis und WebUntis (und mehr) über die Schild-ID, und benutzen dazu in WebUntis das Feld "externe Id".

WebUntis (als Grundlage für das digitale Klassenbuch) kann in diesem Feld auch einen Schlüssel wie "ABC-1234-def" haben,
oder eine Sozialversicherungsnummer.

Zitat Untis-Doku:
"Die empfohlene Art der Schüleridentifikation ist es, einen 'externen Schlüssel' zu verwenden. Idealerweise haben Sie bereits beim letzten Schülerimport einen solchen Schlüssel mit importiert und können diesen nun wieder zur Identifikation verwenden. Dieser 'externe Schlüssel' ist eine eindeutige Nummer die einen Schüler eindeutig identifiziert (z.B. eine Matrikelnummer, fortlaufende Nummer in der Schülerverwaltung). Vergeben wird diese in der Regel von der Schülerverwaltung. Zusätzlich zum externen Schlüssel kann auch eine nationale Id (z.B. bPK, Sozialversicherungsnummer) für Schüler gespeichert und somit für die Identifkation verwendet werden. Diese verhält sich ähnlich wie der externe Schlüssel und muss eindeutig sein."
Quelle: https://help.untis.at/hc/de/articles/36 ... chüerdaten

Im Beispiel dort (etwas runterscrollen) ist als Externe Id (Überschrift: "Schlüssel (extern)") eine dreistellige Nummer angegeben.
(Die bunte Tabelle über dem Hauptpunkt "Löschen von Schülerdaten")

Die Schild-ID ist bei uns der eindeutige Schlüssel zur Schüleridentifikation, das klappt in Lupo, Untis, WebUntis etc.

M. Plümper hat geschrieben: Donnerstag 28. November 2024, 07:48 Zur Dokumentation. Das ist in Teilen richtig, aber etwas hat sich daran auch getan. Schauen Sie sich mal die Schild-3-Maria-DBs an. Da sind viele Infos zu den Feldern bereits ergänzt worden. Und der Wertebereich von IDs ergibt sich aus dem Type der Spalte.

Das werde ich sehr gerne tun. Die Anmerkung mit dem Wertebereich bezog sich allerdings weniger auf IDs als auf andere Felder, die z. B. als Text ausgeführt sind (z. B. Versetzungsmerkmal). Hier musste ich mal für einen Report ausprobieren, mit welchen Zeichenketten das denn im Datenfeld codiert ist (z. B. "Nicht versetzt" als "N" und nicht als "NV" und so weiter), weil das einfach nirgendwo zu finden war.

GE Schwerte hat geschrieben: Donnerstag 28. November 2024, 08:46 Die Schild-ID ist bei uns der eindeutige Schlüssel zur Schüleridentifikation, das klappt in Lupo, Untis, WebUntis etc.

Das machen wir (leider) auch so, man muss sich aber klar machen, dass das kein stabiler eindeutiger Schlüssel ist.
Wir hatten das Problem, dass bei einer Datenmigration zu SchildZentral eine neue Datenbank angelegt werden musste und entsprechend die Primärschlüssel (Schild-ID) beim Datenimport neu vergeben wurden. Da ist es dann blöd, wenn daran andere Systeme hängen. Das hat uns einige Probleme bereitet.

Die Frage wäre zum Beispiel auch, was bei der Datenmigration auf Schild3 passieren wird.