Pflichtenheft aktuell (2)

Alexander Dubielczyk Alexander.Dubielczyk at gmx.de
Thu May 15 20:18:02 CEST 2003


Am Don, 2003-05-15 um 17.29 schrieb Hans-Dietrich Kirmse:

Hallo Hans-Dietrich,

> > Die eindeutige Zuordnung eines Benutzer zu einem realen Schüler wird
> > über Vorname+Nachname+Geburtsdatum erledigt? Wenn man immer komplett den
> > ganzen Schülerstamm jedes Jahr drüberbügelt, muss ja sicher sein, dass
> > der gleiche User auch immer an den selben Schüler vergeben wird. 
> 
> Dieses Problem hatte ich zwar noch nicht soweit bedacht, aber es ist
> richtig, daß das Programm, welches den Abgleich macht (also die
> BW-lösung realisiert) den Schülers zweifelsfrei zuordnen kann. Ich
> war eigentlich nicht der Meinung, das das unbedingt 
> Vorname+Nachname+Geburtsdatum sein muß (aber kann), es sollte einzig 
> die Forderung sein, das mit den exportierten Daten diese Zuordnung
> gemacht werden kann.

Richtig. Dafür müssen aber auf dem Server alle Informationen (inkl. z.B.
Geburtsdatum [oder Alternative]) gespeichert sein, um beim nächsten
Abgleich auch den schon vorhandenen Benutzer richtig dem Schüler in der
Schülerliste zuordnen zu können. 

> > Nehmen
> > wir mal 2 Schüler mit gleichem Namen. Es könnte doch sein, dass Schüler
> > 1 die Schule verlässt und die Bildungsvorschrift für den Benutzernamen
> > für Schüler 2 nun im neuen Schuljahr den (nun nicht mehr vorhandenen)
> > alten User von Schüler 1 vorschlägt. 
> 
> Ausgangspunkt war doch, das das Programm mit den bereitgestellten
> Daten eindeutig einen User zuordnen kann, wenn nicht wird er angelegt.
> bedeutet aber, da das Login einmalig ist, das die Umkehrung auch gilt.
> Nur dadurch ist gewährleistet, das überhaupt gelöscht werden kann,
> wenn in den Datensätzen durch das Programm ein vorhandener Account
> nicht identifiziert werden kann.

Also die bisher beschriebenen Wege erzeugen eindeutig einen Benutzer aus
der Schülerliste, aber der umgekehrte Weg ist nicht eindeutig, wie ich
das sehe. Beispiel:

1. Schüler: Michael Mustermann Geb. 01.01.2001
2. Schüler: Michael Mustermann Geb. 02.02.2002

Nr.1 wird zuerst angelegt. Eine Regel erzeugt den Benutzer

	MMustermann (Michael Mustermann).

Nun kommt der nächste dran und da MMustermann schon existiert erzeugt
eine zweite Regel z.B.

	MiMustermann (Michael Mustermann).

Du kannst nun nicht alleine durch Username+Vorname+Nachname eindeutig
auf einen der beiden Schüler zurückschließen, was imo aber nötig wäre.


> > Ich glaube ich hatte das schon mal
> > gefragt: Gibt es da Datenschutzbedenken das Geburtsdatum mit auf dem
> > Server zu speichern? 
> 
> So wie ich Siegfried verstanden habe, werden die Daten auf dem Server
> gar nicht gespeichert. Man holt diese, bearbeitet die Accounts und
> dann werden diese Daten gelöscht (müßte jedenfalls so gehen).
> Damit existiert diese Problem nicht.
> 
>   :
>  
> > Naja, so weit brauchst Du ja noch nicht mal gehen. Es wäre ja schon
> > praktisch eine Liste von mehreren hundert Usern nicht nur einfach
> > alphabetisch zu ordnen sondern zu Klassen/Jahrgängen gruppieren zu
> > können. Egal, was Du nun konkret mit den Usern bzw. der Userliste
> > vorhast.
> 
> So war das nicht gemeint. Es geht um das Bilden von Projektgruppen.
> Nehmen wir mal eine Projektwoche. Es werden 4 Gruppen gebildet, wobei
> die 1. Gruppe aus der Klassenstufe 5 und 6, die zweite aus 7 und 8,
> die dritte aus 9 und 10 und die vierte aus 11 und 12 besteht.
> 
> Der verantwortliche Lehrer für die 7 und 8 müßte insgesamt 6 Klassen
> aufnehmen. Es würde ihm recht wenig Arbeit ersparen, wenn er die
> Schüler zwar sortiert bekäme, aber er diese einzeln in die 
> Projektgruppe aufnehmen müßte.

Klar ist das ein Vorteil der Gruppierung. Aber selbst wenn Du nicht
ganze Klassen/Gruppen in eine neue Gruppe packst, ist es doch einfacher,
wenn Du z.B. für einen Oberstufenkurs in Klasse 11 die Benutzer
zusammenstellen willst und Du nur die Liste der Jahrgangsstufe 11
durchforsten mußt.

> > Also ich find eine Art von Archivierung besser. Ich möchte nicht wissen
> > wieviele Leute (hier insbesondere auch Lehrer...) es nicht hinkriegen
> > ihre Daten rechtzeitig in Sicherheit zu bringen und nacher anfangen zu
> > jammern. Da können die noch so oft belehrt worden sein :-/
> 
> Prinzipiell richtig. Aber mit dem von mir angegebenen 
> vollautomatischen Backup dürfte auch das nicht problematisch sein.
> (denke ich mal). Vor allem könnte jeder draufzugreifen ohne den
> Admin zu belästigen. Leider hat auf dieses Backuplösung noch keiner
> reagiert. - Das was im Wiki zu Backup steht wäre m.E. hinfällig.

Hmm, möchtest Du jetzt, dass der Admin damit belästigt wird, oder dass
alle darauf zugreifen können? ;-)

Man könnte das Archiv ja z.B. in das Homeverzeichnis des zugehörigen
Gruppenverantwortlichen schieben. Der kann es dann löschen oder
weiterverwenden.

Gruß,
		Alex

-- 

Alexander Dubielczyk <Alexander.Dubielczyk at gmx.de>

Public PGP/GPG Key: http://www.rep-intern.de/keys/alexdu.gpg
Key fingerprint = 61BA 2C78 3503 B7ED 9B00 61DA D8D8 6C8F 3F2B 1302





More information about the SAN mailing list