Warning: include_once(/var/www/html/pmwiki-2.2.86/cookbook/soap4pmwiki/soap4pmwiki.php): failed to open stream: No such file or directory in /var/www/html/fields/dbp13/local/config.php on line 4

Warning: include_once(): Failed opening '/var/www/html/pmwiki-2.2.86/cookbook/soap4pmwiki/soap4pmwiki.php' for inclusion (include_path='.:/opt/php/lib/php') in /var/www/html/fields/dbp13/local/config.php on line 4

Warning: Cannot modify header information - headers already sent by (output started at /var/www/html/fields/dbp13/local/config.php:4) in /var/www/html/pmwiki-2.2.86/pmwiki.php on line 1250
Datenbankpraktikum SS 2013 - Datenvisualisierung - Studenten

Migration der Studenten

Swen Wenzel

Die Queries

Um alle Studenten zu bekommen, die in der Datenbank vorhanden sind, muss man die beiden Tabellen FKT_STUDIENGAENGE und FKT_LAB mit einander verknüpfen.
Da man aber nur den aktuellsten Eintrag jedes Studenten haben möchte, geht man so vor, dass man die Matrikelnummern gruppiert, über die MAX-Funktion das höchste Semester auswählt und zudem noch die anderen benötigten Daten selektiert.
Das Problem hierbei ist, dass es dem Server freigestellt ist, welchen Eintrag er für die "anderen benötigten Daten" innerhalb einer Gruppe auswählt.
"The server is free to choose any value from each group, so unless they are the same, the values chosen are indeterminate." [1]

Also muss man so vorgehen wie es in der Dokumentation von MySQL empfohlen wird [2]:

  1. Auswahl der Matrikelnummern und des zugehörigen höchsten semesters.
  2. Join mit der Kompletten Tabelle um nur aktuellste Einträge pro Tabelle zu erhalten.
  3. Tabellen vereinigen.
  4. Erneut die Matrikelnummern und das zugehörige höchste Semester auswählen.
  5. Mit der ursprünglichen Vereinigung der Tabellen joinen.


Hierbei ist der letzte Schritt das Problem, denn dort wird versucht zwei Tabellen mit jeweils ~80000 Einträgen zu verbinden.
Das ist für den Server zu viel, wenn man alles in einer Query zusammenfasst.
Die Lösung sind temporäre Tabellen. Diese existieren nur so lange wie der Client die Verbindung zum Server hält, können aber sonst wie normale Tabellen behandelt werden und daher auch Indizes enthalten. Mit Hilfe der Indizes klappt der Letzte Join innerhalb von Sekunden. Der Programmablauf ist nun folgender:
(Zum besseren Verständnis sind fiktive Tabellennamen hervorgehoben)

  1. Erstelle Tabellen für FKT_LAB und FKT_STUDIENGAENGE die nur aktuelle Einträge enthalten.
  2. Erstelle Tabelle als Vereinigung der oberen beiden.
  3. Lösche die ersten beiden Tabellen.
  4. Erstelle Index für die Felder Matrikelnummer und Semester der Vereinigung.
  5. Erstelle Abbild der Tabelle Vereinigung als Auswahl des aktuellsten Semesters pro Matrikelnummer.
    Hier muss eine weitere Tabelle angelegt werden, da die gleiche temporäre Tabelle nicht zwei mal in einer Query aufgerufen werden kann [3]
  6. Erstelle Index für die Felder Matrikelnummer und Semester der Tabelle Auswahl.
  7. Erstelle Tabelle als Ergebnis des Join der Tabellen Verinigung und Auswahl.
  8. Lösche Vereinigung und Auswahl.
  9. Bearbeite Datensätze aus Ergebnis in Gruppen zu 10000
  10. Lösche die Tabelle Ergebnis.

Bearbeiten der Datensätze

Bevor alle Studenten bearbeitet werden, werden alle Orte geladen, damit diese nicht für jeden Studenten einzeln aus der Datenbank abgerufen werden müssen. Es wird ein Hash angelegt, über den jeder Ort anhand seiner warehouse_id schnell gefunden werden kann.
Dann wird wie oben beschrieben vorgegangen und jede Gruppe von Datensätzen wird durchlaufen. Für jeden Datensatz wird ein Student angelegt, falls für die entsprechende Matrikelnummer noch keiner existiert.
Dem Studenten werden dann seine Eigenschaften (Matrikelnummer, Geburtsjahr, Geschlecht und Nationalität) zugewiesen und er wird anhand seines Fremdschlüssels, der auf DIM_HZBORT zeigt, dem Ort zugewiesen in dem er seine Hochschulzugangsberechtigung erworben hat.
Alle Studenten, die angelegt werden, kommen in ein Array, damit sie am Ende der Bearbeitung einer Gruppe gemeinsam, innerhalb einer Transaktion abgespeichert werden können.

HZBOrt als Heimatort

Um den Studenten einen Heimatort zuweisen zu können haben wir zunächst versucht den Geburtsort auszulesen, aber dann schnell festgestellt, dass von diesem nur der Name, nicht aber die Postleitzahl bekannt ist. Wegen den vielen unterschiedlichen Orten in Deutschland, die den gleichen Namen tragen, war hier also keine Eindeutigkeit gegeben.
Somit haben wir den HZBOrt als Heimatort ausgewählt, da hier z.B. auch Bundesland und Staat eingetragen sind. Wir mussten allerdings dafür hinnehmen, dass die Einträge in DIM_HZBORT und damit auch der Heimatort in den meisten Fällen ein Landkreis ist.

Das Immatrikulationssemester

Es gibt Studenten, deren Einträge vermeintlich vor ihrer Immatrikulation erstellt wurden.
Hier wird auf zwei verschiedene Arten vorgegangen:

  1. Neuere Einträge bei denen vermutlich Immatrikulationssemester falsch eingetragen wurde
    • Wenn die Differenz zwischen Immatrikulations- und Datenaufzeichungssemester -1 beträgt, geht man davon aus, dass nur ein Eintrag existiert, da die EDV die Fehler im jeweiligen Folgesemester zu berichtigen scheint und weil immer mit dem aktuellsten Eintrag gerechnet wird wäre dann mindestens eine 1 herausgekommen.
    • Existiert nur ein Eintrag, vermuten wir, dass der Fehler beim Eintragen des Immatrikulationssemesters auftrat, da das Datenaufzeichnungssemester von der Software ausgefüllt werden kann und hoffentlich auch wird.
    • Es wird also das Immatrikulationssemester mit dem Datenaufzeichnungssemester überschrieben und es resultiert eine 0
    • Die zugehörigen Studenten haben demnach bereits im ersten Semester das Studium an der Uni-Osnabrück abgebrochen. Dass hier dennoch als Exmatrikulationsgrund XX (nicht exmatrikuliert) steht, wird ignoriert, da es in dem Fall noch weitere Einträge geben müsste.
  2. Ältere Einträge bei denen vermutlich die Spalten für Immatrikulations- und Erfassungssemester vertauscht wurden.
    • Wenn die Differenz kleiner als -1 ist, geht man davon aus, dass die Einträge aus der Zeit vor der EDV stammen und beim übertragen die Spalten Immatrikulationssemester und Erfassungssemester vertauscht wurden.
    • Hier werden die beiden Werte also zurückgetauscht

Allerdings kann es dabei passieren, dass ältere Einträge von Studenten, die nur ein Semester studierten und eigentlich unter den Punkt 2 fallen müssten, wie neue Beiträge berichtigt werden und dann auch so behandelt werden, als hätten sie im ersten Semester gewechselt, obwohl sie eigentlich ein ganzes semester studiert haben. Ein weiteres Problem ist, dass es für die Einträge in FKT_LAB, die keine Pendant in FKT_STUDIENGAENGE haben, gar kein Immatrikulationssemester (im folgenden Immatsem) gibt.

Dass kein Pendant existiert, kann entweder daran liegen, dass sie aus den Jahren 1992 - 1994 kommen und nur eingetragen wurden, damit beim ersten Auswerten der Statistik genug Einträge in FKT_LAB vorhanden waren oder es liegt daran, dass eine Person lediglich zum Promovieren an die Universität kam ohne sich einschreiben zu müssen.
Für jeden der beiden Fälle wird als Immatsem das Semester des ersten Eintrags über die MIN-Funktion ermittelt, da andere Daten fehlen.
Es wäre auch möglich gewesen das Immatsem anhand der Fachsemester zurückzurechnen, aber dabei werden die Urlaubssemester nicht berücksichtigt und es geht in unserer Anwendung ohnehin nur darum, einen Zeipunkt zu haben, ab dem eine Person etwas an der Universität Osnabrück studiert hat und das in dem Fall gegeben.


Page last modified on August 23, 2013, at 06:59 PM