Datenfehler, die bei Migrationen auffallen

[kroerig]

Hier kann eine Sammlung von Fehlerquellen entstehen, die u.a. zu Abbrüchen oder Unvollständigen Migrationen nach SchILD3 führen. Dazu gehören auch falsch befüllte Felder:

- Telefonnummern in E-Mailfeldern
- Notizen in Funktionsfeldern (Telefon, E-Mail)

Vielleicht findet sich ja jemand, der das dann auch in eine Programmlogik gießen kann/ will.

[T.Hagel]

Es geht nicht nur um eine Sammlung von Fehlern die zu einer unvollständigen Migration führen, sondern vor allem/eigentlich, um Datenfelder, in denen falsche Einträge vorgenommen worden sind, wie z.B. Telefonnummern in eMail-Feldern, etc.

[kroerig]

Ich habe das mal noch ergänzt. Allerdings ist das die Kür. Wenn die Schule das so will, verbaut sie sich zwar ggf. ein paar Funktionen (s.u), die Datenbank wird den Inhalt aber klaglos aufnehmen, da es sich um Datenfelder vom Typ VARCHAR(100) handelt.
Auf Github gibt es einen Vorschlag die Felder in SchILD3 (und dann müsste das auch in den SVWS) mit Eingabemasken zu versehen.
https://github.com/SVWS-NRW/Schild3-Bet ... ssues/1056

[Frodermann]

Die Realität ist ein schrecklicher Ort.

Was wäre denn grundsätzlich eine Lösung? Wenn ein Eintrag in einem Feld wirkliche Probleme macht, werden diese mit eindeutig zuordnenbaren Daten (bei SuS etwa Name, Vorname, Geburtsdatum) und dem Feldnamen mit den falschen Einträgen in eine eigene csv geschrieben, jedes Problemfeld eine eigene csv, so dass man im Nachgang der Migration überlegen kann, wie diese Daten wieder in die neue Datenbank in sinnvollerer Weise aufgenommen werden können?

Vermutlich gibt es zu viele kreative Einzellösungen, um wirklich alles abzufangen.

[T.Hagel]

Ehrlich gesagt, möchte ich weder als Fachanwendungsbetreuer im Nachgang einer Migration überlegen, wie die Daten in die neue Datenbank kommen, noch möchte ich, dass sich das irgendwer in einer Schule fragen muss...

Das Migrationsscript ist ja schon recht fortgeschritten und stellt die Daten größtenteils auch zur Verfügung. Aber, hier geht es um die Möglichkeit, vor der Migration bereits die Schild2-Datenbank aufzuräumen, damit sowohl mögliche Fehler, die zu einem Nichtimport führen könnten, abgefangen werden können . Zum anderen, um zu gewährleisten, dass ein fehlerhafte Einträge nicht nach Schild3 rübergeschleppt werden. Dazu zähle ich z.B. Telefonnummern oder Hinweistexte im eMail-Feld, aber auch eMails mit Schreibfehlern (ohne @-Zeichen, ohne Länderkennung am Ende, etc.). Oder Texte in den Feldern für Telefon-/Faxnummern. Oft sind es Hinweise, Ergänzungen, die dann wiederum gesondert auszulisten sind, um diese Informationn dann bei den betroffenen Schülern im richtigen Feld nachtragen zu können.

Sehr hübsch wäre dann auch, wenn vorhandene Telefonnummern in den unterschiedlichsten Schreibweisen auf eine Schreibweise reduziert würden. Es gibt aber auch Schüler, die im Vornamenfeld entweder den oder die gleichen Namen stehen haben, wie beim Zusatznamen. Möglicherweise wurde hier und da das Zusatzfeld als Rufnamensfeld interpretiert, ich weiß es nicht. Vornamensdopplungen machen dann auf Zeugnissen und Anschreiben halt eine ungünstige Figur.

[Frodermann]

Dem stimme ich zu.

Hier müsste eventuell eine Migration begonnen werden und bei zu vielen Fehler/einem Abbruch die Schule ihre Datenbank in Ordnung bringen.

Ich fürchte, die echten Problem sind auch gar nicht Formate von Telefonnummern oder Telefonnummern an Orten, wo sie nicht hingehören, sondern noch viel kreativere Lösungen. "Nicht-korrekte Emailadressen" usw. wären zu filtern.

Es empfiehlt sich auch eventuell, DSGVO-konform zu handeln und vor dem Import auf Löschfristen zu prüfen: alles, was ohnehin unter die Löschfristen fällt, wäre damit für die Migration schon nicht mehr relevant und entfernt.

[Uli Dierkes]

müsste eventuell eine Migration begonnen werden und bei zu vielen Fehler/einem Abbruch die Schule ihre Datenbank in Ordnung bringen.

Solche "Bestrafung" von Datensündern bringt für die Sache vermutlich weniger als erhofft. Hauptsächlich würde Ärger erzeugt, in der Folge Verzweiflung, wüstes Fluchen und/oder fortgeschrittener Wahnsinn.
Für erfolgreicher würde ich halten, wenn bei der Migration ein Fehlerprotokoll geschrieben würde, das im Nachgang abgearbeitet werden kann.
plausible bzw. formalfehlerfreie Daten werden ohne Kommentar migriert. Jedes fehlerhafte Datenfeld wird nicht migriert, im Fehlerprotokoll wird eine Zeile erzeugt, Beispieltext:
Klasse 06a, Schüler/in Ahmed Khan, Datenfeld Schüler-E-Mail-Adresse: Feldinhalt ungültig, enthält Leerzeichen oder @ fehlt, Dateninhalt wurde nicht übernommen.
Klasse 06b, Schüler/in Anke Müller, Datenfeld Schüler-Faxnummer: Feldinhalt ungültig, enthält Leerzeichen oder nichtnumerische Zeichen, Dateninhalt wurde nicht übernommen.
Klasse 08c, Schüler/in Zoe Schmitt, Datenfeld Erzieher-E-Mail-Adresse: Feldinhalt ungültig, nicht identifizierter Fehler, bitte überprüfen, Dateninhalt wurde nicht übernommen.
Undsoweiter.
Mit einem solchen Fehlerprotokoll in Gestalt einer txt-Datei würde die Fehlerbeseitigung zwar (selbstverursachte) Arbeit bedeuten, aber der Ärger- und Wahnsinnsfaktor würde erheblich kleiner sein. Zudem hätte das Verfahren eine gewisse erzieherische Wirkung.
Programmiertechnisch sollte die Implementierung eines Migrationsfehlerprotokolls ein überschaubarer Aufwand sein.

[kroerig]

Da kann man sich jetzt streiten, ob man vorher eine möglichst saubere Datenbasis haben will, oder später nacharbeiten.
Wenn die Daten nicht mitgenommen werden, muss man später nacharbeiten. Das ist dann die "Strafarbeit".

Was ist jetzt für wen mehr oder weniger Aufwand? Geflucht wird so oder so.

Die Frage, die sich aber hauptsächlich stellt: Welche Felder kommen für eine solche Prüfung in Frage? Und wird später in SchILD3 und dem SVWS Client verhindert, dass man den Blödsinn von vorher nicht wieder eintragen kann?

[Frodermann]

Das Problem ist hier: Ist der Datenbestand akzeptabel, kann man ihn migrieren. Eventuell mit einer Regel oder Konversation der Daten, aber das geht. Ist ein Datenbestand nicht akzeptabel... dann was?

Die Daten sind einfach weg und werden nicht migriert? Der Müll taucht auch in SchILD3 auf, obwohl das Feld eigentlich diese Daten nicht mehr nehmen würde? Gibt es einen Log-Eintrag? Werden die nicht-migrierten Daten irgendwo nachgehalten? Wie dem auch sei: Kreativität erzeugt in allen Fällen Arbeit.

Hier ist zum Beispiel für Kreativität: in einer Schule wurden in ein Lehrerfeld (Klassenlehrer) einfach beide KL eingepflegt. Aus der Dropdown-Liste kann nur eine Lehrkraft gewählt werden. Steht aber eine drin, kann man etwas freies eintragen, also wurde "KÜRZEL1; KÜRZEL2" eingetragen, damit man beide KL einfach über ein Reportfeld abrufen kann. Gegen sowas dürfte man kaum mit Migrationsregeln ankommen.

Das tatsächliche Ausmaß wird die Praxis zeigen müssen.

[T.Hagel]

Da kann man sich jetzt streiten, ob man vorher eine möglichst saubere Datenbasis haben will, oder später nacharbeiten.
Wenn die Daten nicht mitgenommen werden, muss man später nacharbeiten. Das ist dann die "Strafarbeit".

Was ist jetzt für wen mehr oder weniger Aufwand? Geflucht wird so oder so.

Die Frage, die sich aber hauptsächlich stellt: Welche Felder kommen für eine solche Prüfung in Frage? Und wird später in SchILD3 und dem SVWS Client verhindert, dass man den Blödsinn von vorher nicht wieder eintragen kann?

Es dürfte auf der Hand liegen, dass eine möglichst bereinigte Datenbankgrundlage eine Migration vereinfacht. Es dürfte auch auf der Hand liegen, dass es den Schulen kaum zugemutet werden kann, nach der Datenmigration auf die Suche zu gehen, wo jetzt welche Daten zwischen Schild2 und Schild3 auf der Strecke geblieben sind.

Wenn es die Möglichkeit gibt, z.B. über die Gruppenprozesse abzufragen, ob die in den eMail-Adress-Feldern vorliegenden Inhalte einer regulären eMailadresse entsprechen oder nicht, wäre das etwas, was man jederzeit vor der Datenmigration durchführen kann (und beibehalten sollte, solange diese Datenfelder nicht in Schild3 auf Plausibilität geprüft werden). Oder abfragen, ob ein Datenfeld leer ist (also in der Datenbank nicht den Wert NULL hat, sondern schlichtweg leer ist) und dieses dann durch NULL zu ersetzen. Oder Geburtstage, die nicht plausibel sind, wie 1850 oder 2019 auflisten und dann durch die Schule korrigieren lassen.

Oder aber Lehrer-Personalnummern oder andere Nummern, die doppelt vorkommen oder schlicht ein falsches Format haben (einstellig zB). Etc.

Hierzu wäre ja eine Sammlung von Datenfeldern interessant, die z.B. durch frühere Importe Informationen an falsche Stellen geschrieben haben, oder Felder, die Daten enthalten, die dort eigentlich nicht hingehören.

Ob Schild3 dann den Blödsinn verhindern wird ... schön wäre es