Raffenberg hat geschrieben: Montag 4. August 2025, 12:04
Hier die Datei für das Schild-Hauptverzeichnis zum entpacken und testen.
Nach langer Zurückhaltung dann doch noch mal ein Kommentar meinerseits, da ich ohnehin noch Tickets in Bezug auf die Schild3-Migrationen offen habe. Bei SchildZentral führen diese "Automatischen Prozesse" bei uns erst mal dazu, dass sich bei uns in den Testschulen das Programm aufhängt ("Keine Rückmeldung"). Die besagte SQL-Datei fehlt (zum Glück) auch bei uns im Hauptverzeichnis.
Denn ich habe mir mal diese SQL-Anweisungen mal näher angeschaut ... es wird ja einiges ohne Rückfrage gelöscht, bzw. Werte auf NULL gesetzt, von denen ich zumindest den Eindruck habe, dass hiermit faktisch wichtige Informationen verloren gehen. Daher zunächst die Frage, ob diese Aufräumfunktion eigentlich auch eine vorherige Datensicherung bedacht hat ? Bei einigen Informationen müssten doch eigentlich die Schulen zumindest die Möglichkeit eingeräumt bekommen, diese entweder zu aktualisieren oder als lösch-/überschreibbar zu markieren.
Denn auch bei anderen Schild3-Migrationsscripten gehen sonst faktisch Informationen verloren, die zwar aus Schild3-Sicht für einen problemloseren Import sorgen sollten, aber letztlich vielleicht doch problematisch sein dürften, wenn sie nicht mehr vorliegen.
Hier im Script sind mir aufgefallen:
1. PLZ auf NULL setzen, wenn diese nicht im Katalog Ort vorliegen:
update Schueler set PLZ=Null where PLZ is not null and not exists(select K_Ort.ID from K_Ort where K_Ort.PLZ=Schueler.PLZ)
update SchuelerErzAdr set ErzPLZ=Null where ErzPLZ is not null and not exists(select K_Ort.ID from K_Ort where K_Ort.PLZ=SchuelerErzAdr.ErzPLZ)
Hier habe ich die meisten Bedenken, denn so gehen faktisch Informationen verloren. Es zeigt so auch ein bisschen eins der Probleme mit der Adressverwaltung. Da ist auf der einen Seite die fehlende Plausibilitätsprüfung in den jeweilgen Eingabeformularen, zum anderen ein fehlender Abgleich mit der hier nun als Referenz gezogenen Tabelle K_Ort. Mir erklärt sich dieser Katalog Ort aber auch generell nicht und warum der so umständlich zu pflegen ist, aber das soll jetzt nicht Thema sein. Wie auch immer, jedenfalls gibt es Schüler, Elternteile, Lehrer, Personen, etc., die in PLZ beheimatet sind, die sich nicht im Katalog Ort wiederfinden. (Weil eben kein Abgleich zu dieser Tabelle stattfindet). Z.B. Berufsschüler oder getrennt lebende Erziehungsberechtigte, etc. Deren bisherigen PLZ-Einträge würden mit der SQL-Anweisung aus der Datei entsprechend verloren gehen.
Das Script ist eigentlich unvollständig, da in dem Zuge eigentlich alle Tabellen, in denen PLZ auftreten auf gültige PLZ geprüft werden müssten ... (bei Schildzentral komme ich auf 15 Tabellen)...
Problematisch ist dieses Script aber auch in allen Fällen, wo die PLZ inhaltlich zwar vorliegt, aber in einem (nicht nur für Schild3) unerwarteten Format. Sei es mit voran- oder nachgestelltem Leerzeichen oder einem Leerzeichen nach 2 Stellen, sei es wegen Tippfehlern die zu mehr als 5-stelligen Nummern führen, oder Zahlen mit Sonderzeichen, weil die Hochstelltaste aktiviert war, oder weil die PLZs in Klammern oder anderen Zeichen eingebunden/impotiert wurden, etc.. In allen Fällen müsste m.E. auf plausible PLZ geprüft werden und im Zweifelsfall den Schulen die Möglichkeit eingeräumt werden, diese Einträge zu korrigieren. Mit dem Script werden diese jedoch einfach mit NULL "weggebügelt".
Wie wirken sich dann Reports gegen Postleitzahlen mit dem Wert NULL aus ? Anschreiben wären damit jedenfalls postalisch nicht mehr zustellbar. Mit einer PLZ a la "(50 827)", etc. hingegen schon.
2. Löschen aller Schülervermerke ohne Vermerkart:
delete from SchuelerVermerke where Vermerkart_ID is null
Ich mag mich täuschen, aber müssten hier nicht auch die Schulen die Möglichkeit haben, zu entscheiden, ob diese Vermerke einfach gelöscht werden, oder ob man denen noch eine Vermerkart zuweist ? Bzw. müsste hier nicht zusätzlich geprüft werden, ob im Feld Bemerkung ein Eintrag vorliegt und dann entscheidden, ob der Eintrag gelöscht werden kann ?
3. Klassenlehrer und Fachlehrer auf NULL setzen, wenn sich die Kürzel nicht mehr im Katalog Lehrer finden lassen:
update SchuelerLernabschnittsdaten set Klassenlehrer=null where Klassenlehrer is not null and not exists (select K_Lehrer.ID from K_Lehrer where K_Lehrer.Kuerzel=SchuelerLernabschnittsdaten.Klassenlehrer)
update SchuelerLeistungsdaten set Fachlehrer=null where Fachlehrer is not null and not exists (select K_Lehrer.ID from K_Lehrer where K_Lehrer.Kuerzel=SchuelerLeistungsdaten.Fachlehrer)
Was ist mit Lehrern, die wegen Heirat oder Trennung als Lehrer weiterhin an der Schule tätig sind, aber ein neues Kürzel erhalten haben ? Was ist mit den Pensionären oder anderen Abgängern, die im Kürzel ein "X_" oder andere Zeichenfolgen vorangestellt bekommen ? Oder in Bezug auf die Fachlehrer, was ist mit Datenbankeinträgen, in denen durch Komma getrennt, mehrere Kürzel aufgeführt sind ? Mir ist zugegebenermaßen aber auch unklar, welche Auswirkungen diese Kürzelüberschreibung auf den Wert NULL hier bei den Lernabschnittsdaten haben und ich mir hier nicht einfach zu viele Gedanken mache.
4. SchuelerLernAbschnittsdaten in denen die Jahrgang_ID = 0 oder NULL, bzw. das Jahr NULL sind:
delete from SchuelerLernabschnittsdaten where Jahrgang_ID is null
delete from SchuelerLernabschnittsdaten where Jahrgang_ID=0
delete from SchuelerLernabschnittsdaten where Jahr is null
Hier fehlen mir auch die Zusammenhänge und das Wissen, ob man diese Daten tatsächlich bedenkenlos löschen kann. Denn bei mir drängt sich da die Frage auf, wie diese NULL- oder 0-Werte entstehen. Ob diese Fälle absichtlich auftreten (Tests), tatsächlicher Datenmüll sind oder ob diese auch versehentlich auftreten können oder in Folge anderer Abhängigkeiten, weil andere Parameter gelöscht oder geändert wurden. Sowie ob diese Abschnittsdaten noch doch noch irgendwie verwendet werden.
Schöne Grüße aus Köln
Thomas Hagel
Stadt Köln
12/Digitalisierung und Informationstechnik
Fachanwendungsentwicklung und -betreuung für Schulen
