Beschreibung SuperX-SOS-Modul

SuperX-Admin-Handbuch SOS-Modul

w w w . M e m T e x t . d e • Daniel Quathamer danielq@memtext.de   • Meikel Bisping mbisping@memtext.de         Supportadresse support@superx-projekt.de Supportadresse speziell für Baden-Württemberg: support-bw@superx-projekt.de

http://www.superx-projekt.de

Lehrfilm zur Installation des SOS-Moduls

Sun, Sun Microsystems, Solaris, Java, JavaServer Web Development Kit, JDBC und JavaServer Pages sind eingetragene Warenzeichen von Sun Microsystems, Inc. UNIX ist ein eingetragenes Warenzeichen von X/Open Company, Ltd. Windows, WindowsNT, Win32, VBScript und Office 2000 sind eingetragene Warenzeichen von Microsoft Corp. Linux ist eingetragenes Warenzeichen von Linus Torvalds. Alle weiteren Produktnamen sind Warenzeichen der jeweiligen Hersteller.

Dieses Produkt beinhaltet Software, die von der Apache Software Foundation ( http://www.apache.org/ ) entwickelt wurde.

SuperX wird unter der deutschen Variante der GPL-Lizenz von dem Land Nordrhein-Westfalen, vertreten durch die FernUniversität Hagen, diese wiederum vertreten durch die Geschäftsstelle der Initiative CampusSource bei der FernUniversität Hagen, Feithstraße 142, D-58084 Hagen vertrieben ( www.campussource.de ). Details zu den Lizenzbedingungen finden Sie im Kernmodul-Archiv (/lizenz.txt) oder unter http://www.campussource.de/lizenz/ . Ergänzende Hinweise finden Sie auf der Projekthomepage unter http://www.superx-projekt.de .

Inhaltsverzeichnis

1 Einführung

Das Berichtssystem SuperX ist ein sog. Data Warehouse, d.h. beiliebig viele Datenquellen werden unter einer einheitlichen Auswertungsschnittstelle zur Verfügung gestellt. Da jede Hochschule unterschiedliche Datenquellen besitzt und in SuperX übernehmen will, bereiten wir für jede Datenquelle ein Modul vor, z.B. ein COB-Modul oder ein SOS-Modul.

Die Module enthalten die wichtigsten Prozeduren, Tabellen und Abfragen für die jeweilige Datenquelle. Folgende Tabellen sind generell zu unterscheiden:

• • Datentabellen enthalten die entladenen Basisdaten aus dem SOS 

• • Hilfstabellen enthalten aggregierte Datentabellen und werden von den Abfragen genutzt. Durch Hilfstabellen wird die Performance der Abfragen besser. 

• • Schlüsseltabellen enthalten Schlüssel und Metadaten, z.B. Semester, Abschlüsse etc. 

Das SOS-Modul besteht im Endzustand aus Tabellen, Prozeduren und Abfragen. Da die SOS-Datenbank der HIS-GmbH an den meisten Hochschulen eingesetzt wird, und da Studierendenstatistiken hochschulweit benötigt werden, ist das SOS-System einer der ersten Kandidaten für die Übernahme nach SuperX. Das SOS-Modul ist auch das komplexeste Modul mit den meisten Abfragen.

Das SOS-Modul bietet folgende Features:

• • Vorgefertigte Auswertungen im Bereich der Studierenden- und Prüfungsstatistik 

• • Übernahme und Vorhaltung von Daten, die in HISSOS archiviert und nicht mehr zugänglich sind 

• • Stichtagsbezogene Auswertungen 

Neuigkeiten zu dieser Version finden Sie im Abschnitt Versionshistorie . Das neue SOS-Modul kann vorhandene ältere Versionen der SOS-Module updaten.

Falls es bei der Implementation des SOS-Moduls zu Problemen kommt, können Sie sich unter www.superx-projekt.de informieren. Oder mailen Sie uns direkt:

Supportadresse allgemein:
support@superx-projekt.de
Supportadresse für Baden-Württemberg:

support-bw@superx-projekt.de

2 Installation des SOS-Moduls

2.1 Voraussetzungen

Das SOS-Modul läuft serverseitig unter folgenden Voraussetzungen:

• • Informix Dynamic Server 7.31 oder höher bzw. Postgres 7.3 oder höher 

• • Betriebssystem Linux   oder Cygwin mit Bourne Again Shell (bash).  

• • Das SuperX-Kernmodul 4.1 oder höher 1  

• • Als Datenquelle sind Scripte für HISSOS 5.x oder höher unter Informix bzw. Postgres mitgeliefert. Die Schnittstelle kann aber auch aus anderen Datenquellen bedient werden. 

   

Zur Lehreinheitszuordnung empfehlen wir die vorherige Installation des SuperX-COB-Moduls 0.6 oder höher.

Auf der Seite des Clients sind keine besonderen Anforderungen über die des Kernmoduls 4.1 hinaus zu erfüllen.

2.1.1 Konventionen und Schnittstellenspezifikation

Das SOS-Modul von SuperX setzt voraus, dass die Daten bei der Datenquelle SOSPOS   HIS-konform gepflegt sind. Eine Vielzahl von Schlüsseln und Stammdaten sind in HISSOS sehr flexibel zu pflegen und können daher zu Problemen bei der Übernahme nach SuperX führen.

2.1.1.1 Stammdaten Studierende

Bei Studierenden-Daten (Tab. sos) müssen folgende Fehler gepflegt sein:

• • Geschlecht 

• • KFZ-Kennzeichen Heimat/Semesterwohnsitz / Hochschulzugangsberechtigung 

• • Geburtsdatum 

• • Nationalität 

Bei Fachbelegungen müssen mindestens folgende Daten gepflegt sein:

• • Matrikel-Nr. 

• • Fachkennzeichen 

• • Studiengang-Nummer / Fach-Nr. 

• • Rückmeldestatus 

• • Abschluss 

• • Studienfach 

• • Fachsemesterzahl 

• • Endedatum bei Exmatrikulation in dem jeweiligen Studiengang 

Darüberhinaus gilt, dass eine Belegung pro Semester mit gleicher Fach-Nr. und gleicher Studiengang-Nr. nur einmal auftreten darf (Unique Index auf matrikel_nr, fach_nr, studiengang_nr und Semester).

Bei Prüfungssätzen müssen folgende Felder belegt sein:

• • Matrikel-Nr. 

• • Fach 

• • Abschluss 

• • Semester der Prüfung  

• • Prüfungsnummer 

SuperX wertet bei tagesaktuellen und stichtagsbezogenen Auswertungen wie die amtliche Statistik das Prüfungsdatum mit höherer Priorität aus als das in POS eingetragene Semester, d.h. wenn das Prüfungsdatum gesetzt ist, dann wir das Semester der Prüfung entsprechend überschrieben. Bei der "semesterbezogenen Zählung" (Button "Stichtag Prüfungen") wird das zugewiesene Semester in POS gewertet (Feld psem in lab ).

Das Prüfungsdatum wird für stichtagsbezogene Auswertungen genutzt. Je nach Art des Stichtags werden die Prüfungen jeweils gezählt oder nicht. Für valide Auswertungen sollte natürlich das Prüfungsdatum in der Regel gepflegt sein. Bei Vorprüfungen ist dies nach unserer Erfahrung in der Regel aber nicht der Fall.

Das gleiche gilt für Prüfungsnoten: Sie sollten, müssen aber nicht gepflegt sein.

Auch die Felder Studiengang- und Fach-Nummer sind häufig nicht gepflegt bzw. es ist sogar möglich, dass Studierende die Prüfung in einem Fach absolvieren, für das sie gar nicht mehr eingeschrieben sind. SuperX versucht dann nachträglich, mit Hilfe des Fächer-Satzes diese zu ermitteln. Dabei gilt die Regel, dass eine Prüfung nur dann gezählt wird, wenn der Studierende irgendwann einmal das Fach und den Abschluss, in dem die Prüfung absolviert wurde, belegt hat. Bei der Übernahme sucht SuperX das letzte Semester, zu dem der Studierende in dem Fach eingeschrieben war, und übernimmt die Fachsemesterzahl für die Prüfung.

Hinweis zu Promotionen: SuperX geht davon aus, dass Promotionen in POS gepflegt sind. Promovenden, die nicht eingeschrieben waren, werden "künstlich" über Status "Y" eingeschrieben. Dies ist der HIS-konforme Weg.

2.1.1.2 Schlüssel

Viele Schlüsseltabellen aus SOS werden von SuperX übernommen; teilweise werden Tabellen mit internen und amtlichen Schlüsseln übernommen, die amtlichen Schlüssel müssen also auch gepflegt sein:

• • k_stg (inkl. der Felder astat, astfr, astgrp) 

• • k_abint 

• • k_stgext 

• • k_abext 

• • k_astgrp 

• • k_astfr 

• • k_kzfa [hier lautet das Schlüsselfeld nicht astat, sondern his_kzfa, und muss mit "H" für Hauptfach oder "N" für Nebenfach belegt sein] 

• • k_status 

• • k_hzbart 

"Gepflegt" bedeutet nicht nur, dass die Schlüssel der aktuellen Semester vorhanden sind, sondern auch die älteren Semester. SuperX bietet Zeitreihen dar, in denen auch die Vergangenheit ausgewertet wird. Daher sollten die meisten Schlüssel gepflegt und auf "A" wie aktiv gesetzt sein (nicht auf "inaktiv", diese Schlüssel werden teilweise nicht übernommen, weil sonst die Gefahr von Duplikaten besteht). Bei Fächern und Abschlüssen werden auch die inaktiven Schlüssel übernommen. Hier gilt außerdem, dass nur der deutschsprachige Schlüssel übernommen wird, und dass "Deutschsprachig" in der Tabell k_stg bzw k_abint mit der Ausprägung " sprache='D' " bzw. " sprache is null " codiert ist. Schlüssel mit Sprache "E" oder "F" werden hier nicht übernommen.

Wichtig ist auch die Pflege der Semester-Tabelle in SOS, es sei den sie wird in SuperX gepflegt.

Wenn die Schlüssel für ältere Semester nicht mehr in SOS vorhanden sind, können Sie entweder in SuperX manuell nachgetragen werden, oder das Entladesemester wird hochgesetzt auf das Semester, seitdem alle Schlüssel vorhanden sind.

Für die SuperX- Sichten im Bereich Studierende ist es unerlässlich, dass die Fächer in der Tabelle k_stg in SOS den jeweiligen amtlichen Fächern, den Fachrichtungen der Gasthörerstatistik, Fächergruppen und Fachbereichen zugeordnet sind. Die Zuordnung der Lehreinheiten kann auch aus HISCOB übernommen werden.

Die Studiengangtabellen k_abstgv und parstg werden für studiengangsspezifische Informationen genutzt, z.B. die Lehreinheiten und Regelstudienzeiten aus k_abstgv (in SOS 5 wird das Feld " frist2 " benutzt), oder die Prüfungszeiträume in parstg .

Bei den Prüfungszeiträumen in parstg wird immer jweils nur der erste Zeitraum des Studiengangs pro Semester für den Stichtagsbezug genutzt. Der erste Zeitraum definiert sich durch das Minimum des Anfangsdatums.

2.2 Kurzanleitung

Folgende Arbeitsschritte sind in der typischen Umgebung (SOS läuft unter Informix / Unix) notwendig:

1. 1. Zunächst entpacken Sie das Archiv sos_modul0.6.tar.gz als User superx (nicht als root) an der Stelle $SUPERX_DIR. .Die Locale beim Entpacken sollte eine deutsche mit mindestens Zeichensatz LATIN-1 oder de_DE@euro sein. 

2. 2. Einrichtung der SOS-bezogenen Umgebungsvariablen - Prüfen Sie ob in Ihrer $SUPERX_DIR/db/bin/SQL_ENV alle Einträge aus SQL_ENV.sos.sam vorhanden sind, ggfs. rüberkopieren ). Aktivieren Sie die Umgebung mit
   . $SUPERX_DIR/db/bin/SQL_ENV  

3. 3. Benennen Sie die Datei $SUPERX_DIR/db/module/sos/rohdaten/SOS_ENV.sam nach SOS_ENV um und passen Sie die Umgebungsvariablen für den SOSPOS-Rechner an.  

4. 4. Entscheiden Sie sich zunächst für ein "Push"- oder "Pull"-Verfahrne beim Entladen. Die häufigsten Modi sind erfahrungsgemäß: "Push" bei SOSPOS unter Inofrmix (Unix), "Pull" bei allen andere Systemen.
   Beim Entladen aus SOSPOS unter Informix im "Push"-Modus: Kopieren sie den Verzeichnisinhalt unter $SUPERX_DIR/db/module/sos/rohdaten zum SOS-Rechner, bzw. mounten Sie das Verzeichnis auf dem SuperX-Rechner 2 . Laden und testen Sie dann die Umgebung in SOS_ENV.
   Beim Entladen aus SOSPOS unter Postgres im "Pull"-Modus: Laden Sie die Umgebung in SOS_ENV und richten Sie mit dem propadmin.x die Datenbankverbindung zum SOSPOS-Rechner ein. 

5. 5. Führen Sie (bei SOS-Informix und SOS-Postgres) einmal in der SOS-Datenbank das Script
   superx_sos_install.x aus.  

6. 6. Ausführen des Entladescripts $SUPERX_DIR/db/module/sos/rohdaten/sos_unload.x für die Basisdaten (ältere SOS-Versionen unter Informix: sos5_unl_ids.x )  

7. 7. Ggf. Kopieren des Rohdaten-Verzeichnis der entladenen SOS-Daten nach $SUPERX_DIR/db/module/sos/rohdaten
   Ein Scripte dafür heißt sos_copy.x  

8. 8. Laden Sie für die folgenden Schritte die Umgebung für SuperX
   . $SUPERX_DIR/db/bin/SQL_ENV
   Erzeugen des SOS-Moduls in der SuperX-Datenbank:
   $SUPERX_DIR/db/module/sos/sos_modul_erzeugen.x
   Falls ein Fehler auftritt, versuchen Sie die Ursache zu beheben, starten Sie dann
   $SUPERX_DIR/db/module/sos/sos_modul_entfernen.x
   (etwaige Fehler können normalerweise ignoriert werden)
   und anschließend erneut
   $SUPERX_DIR/db/module/sos/sos_modul_erzeugen.x
    

9. 9. Nur wenn Sie Tomcat auf einem separaten Rechner betreiben: Fügen Sie den Inhalt der Datei
   $SUPERX_DIR/webserver/tomcat/webapps/superx/WEB-INF/sos_dbforms_config_<<pg für Postgres oder ids für Informix)>>.xml vom Kommentar "<!--Hier beginnt Moduldefinition-->" bis zum Kommentar "<!--Hier endet Moduldefinition-->" in Ihre dbforms-config.xml ein.
   Danach starten Sie Tomcat neu. 

10. 10. Übernahme der entladenen SOS-Daten nach SuperX:
    $SUPERX_DIR/db/module/sos/sos_update.x
    Wenn Sie die Lehreinheits - oder Fachbereichszuordnung in SOS pflegen, sollten Sie beim ersten Update schreiben:
    $SUPERX_DIR/db/module/sos/sos_update.x   --mit-lehreinheiten  

11. 11. Ggf. Anpassen der Schlüsseltabellen , insbes. der lehr_stg_ab  

12. 12. Prüfen des Update, Testen der Abfragen 

13. 13. Schritt 10 kann jede Nacht wiederholt werden. Dazu muss der Entladerhythmus geplant werden, und die Cronjobs werden eingerichtet.  

2.3 Installation des SOS-Moduls

Zunächst müssen die Rohdaten aus SOS entladen werden. Danach wird die Umgebung eingerichtet, und das Modul kann installiert werden.

2.3.1 Entladen der SOS-Daten

2.3.1.1 Allgemeines

Beim Entladen der SOS-Daten werden Datentabellen und Schlüsseltabellen entladen, um sie nach SuperX zu übernehmen. Grundsätzlich werden fast alle Stammdaten und die zugehörigen Schlüsseltabellen übernommen. Bei den Prüfungen gilt noch die Einschränkung, dass nur "echte" Prüfungen (also keine anerkannten Prüfungsleistungen) übernommen werden.

Im Regelbetrieb werden alle für SuperX relevanten SOS-Daten immer komplett entladen. Es ist aber auch möglich, bei einigen Stammdaten der SOS -Datenbank nur die geänderten Sätze zu entladen (s.u.). Dazu ist es allerdings erforderlich, dass die Protokolltabellen von SOS ordentlich geflegt sind, und dass der SuperX-Rechner entweder direkt auf die SOS-Datenbank zugreift, oder zumindest das Entladeverzeichnis des SOS-Rechners auf dem SuperX-Rechner gemounted ist. Wir empfehlen gerade in der Installationsphase, immer komplett zu entladen.

Aus Datenschutzgründen wurde die Möglichkeit zur Pseudonymisierung von Matrikelnummern implementiert. Das bedeutet: In HISSOS wird eine Tabelle erzeugt, in der die tatsächlichen Matrikelnummern zu einer arbiträren Laufnummer dauerhaft zugeordnet werden, und beim Entladen nur die arbiträre Laufnummer nach SuperX übernommen wird.

Diese "erweiterten" Funktionen wurden für den Betrieb von HISSOS unter Informix (ab Version 7.3) und Postgres (ab Version 7.2) implementiert. Bei Betrieb von HISSOS unter Ac cess kann die Pseudonymisierung nicht genutzt werden. Außerdem werden bei Access immer alle Rohdaten entladen, also nicht nur die geänderten Sätze.

Für das Entladen gibt es ferner zwei Modi : Das "Pull"-Verfahren und das "Push"-Verfahren.

• • Beim "Pull"- Verfahren wird einer Benutzerkennung auf dem SuperX-Rechner Zugriffsrecht auf die SOSPOS-Datenbank gegeben, und die Daten werden via TCP/IP aus dem Basissystem entladen. 

• • Beim "Push"- Verfahren werden die Entladescripte auf den SOSPOS-Rechner kopiert und dort von einer Benutzerkennung auf dem SOSPOS-Rechner ausgeführt. Die Rohdaten müssen dann auf den SuperX-Rechner kopiert werden. Dieses Verfahren klappt bei Informix unter Unix problemlos, bei Entladen aus Postgres müsste das komplette SuperX-Kernmodul installiert werden. 

Am einfachsten ist immer das "Pull"-Verfahren, das mit fast allen Quellsystemen funktioniert und wenig Konfiguration auf dem Quellsystem erfordert. Aufgrund von Sicherheitsvorkehrungen oder Netz-Infrastrukturen wählen aber viele Hochschulen das "Push"-Verfahren. Da derzeit Informix /Unix die gängigste Plattform an Hochschulen ist, ist dies auch kein Problem.

2.3.1.2 Einrichtung der Entladescripte

Das Entladescript für die SOS-Tabellen liegt im Verzeichnis $SUPERX_DIR/db/module/sos/rohdaten   und lautet sos_unload.x.

2.3.1.2.1 Entladen unter Postgres oder Informix / UNIX

Am einfachsten ist es, wenn Sie als User superx vom SuperX-Server direkt auf den SOS-Datenbankserver zugreifen und entladen können ("Pull"-Verfahren). Dann ist es sogar egal ob Sie SOS unter Informix f. Win., Informix f. Unix oder Postgres einsetzen; außerdem brauchen Sie die Dateien dann nicht vom SOS-Rechner nach SuperX kopieren.

Für Postgres ist dies auch deshalb die einfachste Lösung, weil zum Entladen aus Postgres die Bibliotheken des SuperX-Kernmoduls vorhanden sein müssen.

Für Informix ist auch das Entladen im "Push"-Verfahren möglich: kopieren Sie den gesamten Verzeichnisinhalt ab $SOS_PFAD/rohdaten auf den SOS-Rechner, geben Sie dem Script Ausführungsrechte. Die Scripte laufen nur, wenn die entsprechenden Umgebungsvariablen in der Datei SOS_ENV (im gleichen Verzeichnis, ein Muster liegt vor in SOS_ENV.sam) korrekt gesetzt sind, benennen Sie die Musterdatei um nach SOS_ENV und tragen die richtigen Umge bungsvariablen ein, z.B. den Pfad für $INFORMIXDIR , und das Semester, ab wann Sie entladen wollen ( start_stud_sem bzw. start_pruef_sem ).

Am besten nehmen Sie für den Testbetrieb nur ein paar Semester, denn wenn Sie weiter in die Vergangenheit zurückgehen, dann laufen die Scripte recht lange.

In der   SOS_ENV müssen   folgende Umgebungsvariablen gesetzt werden (defaults sind bereits vorbelegt, aber hier und da müssen Sie sicher ran):

Unter Postgres muss für das "Pull"-Verfahren beim Entladen die Datenbankverbindung in der Datei db-sos.properties eingetragen werden (Muster für Postgres liegt bei in db- sos_pg.properties ). Dazu laden Sie einmal die Datei SOS_ENV mit den obigen Parameter, starten den SuperX-Propadmin (siehe Administrationshandbuch Kernmodul) und richten die Verbindung zum SOSPOS-Server ein. Das Kennwort wird verschlüsselt gespeichert. Danach sind die Entladescripte für Postgres ausführbar.

Hinweis: Anders als Informix hat Postgres hat eine eigene, vom Basissystem unabhängige Benutzerverwaltung. Daher brauchen Sie den User, den Sie zum Entladen aus Postgres nutzen, nicht auf dem SuperX- oder SOSPOS-Rechner auf Betriebssystem-Ebene einrichten. Sie können also z.B. auf dem SuperX-Rechner zum Entladen aus SOSPOS die Kennung sospos des Postgres- Rechners verwenden. Oder Sie richten in der SOSPOS -Datenbank den Benutzer SuperX ein und geben ihm Leserecht auf die Tabellen sowie das Recht, Tabellen und Stored Procedures anzulegen.

Nach der Konfiguration muss einmal in der SOS-Datenbank das Script superx_sos_install.x ausgeführt werden, es wird eine Tabelle zur Pseudonymisierung von Matrikelnummern installiert.

Wenn Sie Informix oder Postgres unter Windows benutzen, können Sie das Script nicht ausführen. Setzen Sie stattdessen einmalig das SQL-Kommando ab:

Mehr macht das Script superx_sos_install.x   auch nicht.

Wenn " SOS_UNL_COMPLETE=false " gesetzt ist, dann muss darüberhinaus in der Datei
superx.datum der Stichtag des Entladens angegeben werden, d.h. alle Sätze zu Matrikelnummern werden entladen, die in die Protokolltabellen pprot , pro eingetragen werden und nach dem Stichtag aufgetreten sind.

Defaultmäßig entlädt SuperX danach immer nur die Änderungen. Dies macht es aber erforderlicht, dass das Rohdaten-Verzeichnis auf dem SuperX-Rechner gemounted ist bzw. die Datei superx.datum nach dem Update auf SuperX-Seite regelmäßg rückgeschrieben wird. Wenn nämlich der Update auf SuperX-Seite mit Fehler beendet hat, dann wird das Entladedatum auf das vorherige Datum ( superx.datum.alt ) zurückgesetzt, damit beim nächsten Entladen die Sätze erneut übernommen werden.

Dieser Prozeß ist gerade in der Installationsphase recht fehlerträchtig, deshalb gibt es auch die Möglichkeit, die SOS-Daten immer komplett zu entladen. Dazu muss in SOS_ENV die Umgebungsvariable SOS_UNL_COMPLETE auf "true" gesetzt werden.

Dann starten Sie das Script sos_unload.x . Wenn es gelaufen ist, müssten die Dateien im unl -Verzeichnis stehen. Prüfen Sie dann bitte, ob dort Dateien mit 0 bytes stehen. Die Logdatei heisst sos_unload.err .

2.3.1.2.2 Entladeparameter

2.3.1.2.3 Entladen unter Windows

Beim Einsatz von HISSOS unter Windows (Access, Postgres f. Win.   oder Informix f. Win) verweisen wir auf unser Adminstrationshandbuch Kernmodul. Die Rohdaten können dann via "Pull"-Verfahren (s.o.) entladen werden. Bei Systemen außer Informix muss in diesem Falle über jdbc entladen werden. Ansonsten ist die Funktionalität der Übergabe des jeweils letzten Entladedatums ist hier nicht gegeben. Wenn Sie direkt unter Windows entladen (z.B. mit dem SuperX-Clientpaket), dann wird das SOS-Modul immer komplett entladen. Es ist allerdings nicht so, dass die Daten dann auch in SuperX komplett ausgetauscht werden, sondern ggf. nur die Änderungen. In SOS archivierte Sätze bleiben in SuperX erhalten, wenn inkrementell entladen wird. Wenn immer aus SOS komplett entladen wird, dann werden alle Datenbestände in SuperX ausgetauscht.

Wenn Sie aus Access entladen wollen, ist das Vorgehen etwas anders, weil Access keine Serverapplikation ist.

Zunächst müssen sie Java 1.4.x und den SuperX-Client 2.1 auf dem Windows-Rechner installieren. Eine Anleitung findet sich im Administratorhandbuch des Kernmoduls. Wichtig ist, dass auch die sql_env.bat des SuperX-Client einmal durchlaufen wird.

Je nach Server-Konfiguration können Sie auf dem Windows-Rechner aus SOS entladen und die Rohdaten auf den SuperX-Datenbankserver kopieren ("Dateibasiertes Entladen"), oder Sie entladen unter UNIX, indem Sie via RmiJdbc vom SuperX-Rechner auf einen entfernten SOS-Server zugreifen. Wir empfehlen Letzteres, weil dies sich besser automatisieren läßt.

Dateibasiertes Entladen

Wenn Sie den Client installiert haben, dann kopieren Sie das Verzeichnis rohdaten im SOS-Modul in ein Verzeichnis des Windows-Clients, wenn möglich unter Einhaltung der Modulstruktur in SuperX; wenn Sie den Client z.B. nach c:\superxclient\ installiert haben, dann kopieren Sie das Verzeichnis rohdaten aus dem SOS-Modul nach c:\superxclient\db\module\sos

Als nächstes erzeugen Sie im Verzeichnis rohdaten mit Hilfe des Werkzeugs propadmin eine Datenbankverbindung; als properties-Datei für die Datenbankverbindung ist db-sos.properties im Verzeichnis rohdaten vorgegeben.

Der Access-jdbc-Treiber befindet sich automatisch im CLASSPATH, er ist Teil der Java-Runtime von SUN.

Wenn Sie SOS unter Informix/Win betreiben, müssen Sie auch den Informix-Treiber ifxjdbc.jar laden. Außerdem muss die Connection URL hier die Informix-Syntax haben (siehe Adminhandbuch Kernmodul).

Mit "Verbindung testen" können Sie prüfen, ob die Datenbank erreichbar ist, und dann speichern Sie die Datei.

Nun kopieren Sie die Datei sos_env.bat.sam nach sos_env.bat , und passen die Umgebungsvariablen in der Datei an, d.h. die Parameter für die SOS-Datenbank, die SOS-Version und das Startsemester, ab dem Sie aus SOS laden wollen.

Dann starten Sie das Entladen aus der DOS-Box mit " sos_unload.bat ". Wenn alles klappt, dann liegt die Protokolldatei in sos_unload.err , und die Dateien im Unterverzeichnis " unl ".

Prüfen Sie, ob sos_unload.err Fehlermeldungen enthält; wenn nein, dann kopieren Sie das gesamte Verzeichnis $SUPERX_DIR/db/module/sos/rohdaten auf den SuperX-Rechner.

Der ganze Entladevorgang lässt sich unter Windows (je nach Windows-Version) mit dem net -Befehl automatisieren, wichtig ist aber, dass vorher die Dateien sql_env.bat unter db\bin und sos_env.bat unter db\module\sos\rohdaten durchlaufen werden.. Für das Kopieren auf den SuperX-Rechner bietet sich eine Fileserver-Lösung an: Sie mounten das Verzeichnis $SUPERX_DIR/db/module/sos/rohdaten als Samba-Share mit einem Laufwerksbuchstaben auf dem Windows-Rechner, und starten das Programm in diesem Verzeichnis. So braucht man sich nicht um das Kopieren der Dateien zu kümmern.

Entladen via RmiJdbc

Der Rmi-JDBC-Treiber der Firma ObjectWeb, der Teil des Kernmoduls ist, macht aus Access einen Datenbankserver. Zunächst müssen Sie auf dem Windows-Rechner eine Applikation starten, die die ODBC-Verbindung als Serverapplikation verfügbar macht; starten Sie den RMI-Server in der DOS-Box mit $SUPERX_DIR\db\bin\start_rmiodbc_server.bat .

Danach können Sie von einem entfernten Rechner mit dem Propadmin darauf zugreifen, indem Sie den Datenbanktreiber rmiOdbc auswählen; die Verbindungsparameter sind dabei nach dem folgenden Muster anzugeben:
jdbc:rmi://<rmiHostName[:port]>/<jdbc-url>

Wenn Sie zum Beispiel auf den Windows-Rechner mit dem Namen sosserver zugreifen wollen und dort SOS unter Access installiert ist, und die odbc-Quelle dort sospos heisst, dann lautet der Pfad:
jdbc:rmi://sosserver/jdbc:odbc:sospos

Wen der RMI-Server permanent laufen soll, müssen Sie die Sicherheitshinweise der Firma ObjectWeb beachten.

2.3.1.3 Änderung der Einstellung zur Pseudonymisierung im laufenden Betrieb

Wenn Sie die Einstellung zur Pseudoynmisierung nach der Installation und Inbetriebnahme ändern wollen, müssen gewisse Vorkehrungen getroffen werden, damit Studierende nicht doppelt oder fehlerhaft im SuperX-SOS-Modul erscheinen. Bei der Übernahme von SOSPOS nach SuperX identifiziert SuperX die Person nämlich über die Matrikel-Nummer, und wenn genau diese auf einmal pseudonymisiert wird oder auf einmal nicht mehr pseudonymisiert wird, dann kann die Identifikation nicht mehr funktionieren. Die Folge wären entweder viel zu viele Studierende in den danach folgenden Updates des SuperX-SOS-Moduls, oder viel zu wenig Studierende in älteren Semestern. Um dies zu vermeiden, müssen sämtliche Studiernedendaten (nicht Schlüssel und Konfigurationen) zunächst gelöscht werden. Gehen Sie wie folgt vor:

• • Auf SOSPOS-Seite: 

  • • Leeren Sie die Tabelle mtknr_ldsg komplett mit
    delete from mtknr_ldsg;  

  • • Setzen Sie den Schalter SOS_UNL_COMPLETE=true , und den Schalter SOS_UNL_ANON auf Ihren gewünschten Wert. 

  • • Entladen Sie neu mit sos_unload.x , und kopieren Sie ggf. die Daten auf den SuperX-Rechner 

• • Auf SuperX-Seite: 

  • • Gehen Sie in der Shell in das Verzeichnis $SUPERX_DIR/db/module/sos  

  • • Führen Sie das Script aus
    DOSQL sos_purge_ids.sql (für SuperX unter Informix) bzw.
    DOSQL sos_purge_pg.sql (für SuperX unter Postgres)
    [Wenn Sie ein älteres SOS-Modul nutzen (Version 0.6rc4 oder kleiner), müssen Sie dieses Script aus einem aktuellen SOS-Modul besorgen] 

  • • Laden Sie die SOS-Daten wie gehabt mit sos_update.x  

Durch diese Aktionen gehen allerdings alle Informationen zu eventuell archivierten Studierendendaten verloren. Dies liegt leider in der Natur der Sache: Pseudonymisierung bzw. keine Pseudonymisierung kann man nur für den gesamten Datenbestand ausführen, aber das will man ja eigentlich auch erzielen.

2.3.1.4 Entladen aus SOSPOS mit eingeschränkten Datenbankrechten

Wenn Sie die Datenbank-Rechte beim Entladen aus dem Vorsystem sospos so ändern wollen, dass der Datenbank-User nur auf ausgewählte Tabellen Leserechte besitzt, dann müssen Sie folgende Tabellen mit Leserecht versehen:

• • hskonst 

• • sos 

• • k_geschl 

• • k_ikfz 

• • stg 

• • lab 

• • pro 

• • pprot 

• • stgext 

• • anschri 

• • parstg 

• • sossys 

• • k_akfz 

• • k_semgewicht 

• • k_pnr 

• • k_pvers 

• • k_akfz 

• • k_abint 

• • k_stg 

• • k_vert 

• • k_schwp 

• • k_hzbart 

• • k_kzfa 

• • k_hrst 

• • k_stuart 

• • k_astfr 

• • k_astgrp 

• • k_abext 

• • k_pstatus 

• • k_stutyp 

• • k_bland 

• • k_ppruef 

• • k_sperre 

• • k_status 

• • k_minder 

• • k_modulart 

• • k_fb 

• • k_stort 

• • k_le 

• • k_part 

• • k_stg 

• • k_stufrm 

• • k_gdbu 

• • k_gdex 

• • k_abstgv 

• • pord  

• • k_s_var. 

• • k_stgext 

• • porg 

• • dipl 

• • ident 

• • identroll 

• • telefon 

• • minder  

• • pords 

Darüber hinaus benötigt die Entladekennung Schreibrecht auf die Pseudonymisierungstabelle mtknr_ldsg . Bei Postgres wird auch das Schreibrecht auf die zugehörige Sequence benötigt:

grant update on mtknr_ldsg_mtknr_ldsg_seq to <<Kennung>>

2.3.2 Erzeugen des SOS-Moduls

Die entladenen SOS-Daten müssen für die Installation in SuperX im Verzeichnis $SUPERX_DIR/db/module/sos/rohdaten/unl stehen (auf dieses Verzeichnsi zeigt die Umgebungsvariable SOS_LOAD_PFAD. Kopieren Sie die Daten dorthin, oder mounten Sie das Verzeichnis vom SOS-Rechner als NFS- oder Samba-Share.

Die Umgebungsvariablen des SOS-Moduls müssen in der Datei $SUPERX_DIR/db/bin/SQL_ENV eingetragen sein. Im Kernmodul sind bereits sinnvolle Werte enthalten. Prüfen Sie, ob alle Einträge in der Musterdatei $SUPERX_DIR/db/bin/SQL_ENV_SOS.sam auch in Ihrer SQL_ENV vorhanden sind.

Standardmäßig brauchen Sie an diesen Parametern nichts ändern, lediglich der SOS_LOAD_PFAD und die Emailadressen für Logdateien müssen ggf. angepasst werden.

Danach ist das SOS-Modul installationsbereit.

1. 1. Melden Sie sich als Benutzer superx an, laden Sie die Umgebung mit
   . $SUPERX_DIR/db/bin/SQL_ENV  

2. 2. Wechseln Sie ins Verzeichnis
   cd $SOS_PFAD  

3. 3. Starten Sie das Skript sos_modul_erzeugen.x
    

Neben dem Erstellen der Tabellen und Hinzufügen der Prozeduren und Abfragemasken, werden auch Einträge in den Themenbaum und die Tabelle sachgebiete gemacht.

Außerdem erhalten die Administrator-User superx und admin Zugriffsrechte für die neuen Sachgebiete Nr. 16 Studierende/ Prüfungen und 41 (Studierende Administration).

Falls ein Fehler auftritt, versuchen Sie die Ursache zu beheben, starten Sie dann
$SUPERX_DIR/db/module/sos/sos_modul_entfernen.x

(etwaige Fehler können dabei normalerweise ignoriert werden)
und anschließend erneut
$SUPERX_DIR/db/module/cob/sos_modul_erzeugen.x

2.3.3 Konfiguration nach der Installation

SOS ist nicht SOS, und je nach Größe oder Anforderung der Hochschule sind unterschiedliche Konfigurationen nach der Installation vorzunehmen. Im einfachsten Fall werden einfach nur Schalter in der Konstanten-Tabelle in SuperX unterschiedlich eingestellt . Schwieriger, aber gleichzeitig wesentlich flexibler ist die Konfiguration durch Zwischenschaltung beliebiger SQL-Befehle während oder nach dem Update. Wir zeigen dies unten am Beispiel der Unterscheidung nach Studienschwerpunkt und Prüfungsordnungs-Version.

Letztendlich gilt es, eine Strategie beim Sichtagsbezug zu wählen.

Für alle wichtigen Konfigurationstabellen gibt es spezielle Bearbeitungsmasken; diese bekommen Sie, wenn Sie als Administrator im XML-Frontend die Maske Prüfprotokoll Studium aufrufen und von dort einen der Links in der rechten Seitenleiste aufrufen.

2.3.3.1 Zentrale Konstanten

Nach der Installation müssen ein paar Schlüssel kontrolliert bzw. angepasst werden. Vorgegeben sind die Schlüssel in der Tabelle konstanten ; Bitte kontrollieren Sie, ob die Variablen Geschlecht und Rückmeldestatus in SOS (astat-Felder) identisch belegt sind, z.B. männlich=1, weiblich =2 bzw. Rückmeldung = 3 etc.

Die Konstanten aus dem SOS-Modul sind:

Sie sehen in der ersten Spalte der Tabelle die Vorbelegungen. Vor dem ersten Update in SuperX müssen diese Parameter jeweils gesetzt werden. Sie müssen dazu die Tabelle konstanten bearbeiten. Eine Bearbeitungsmaske bekommen Sie, wenn Sie im XML-Frontend die Maske Prüfprotokoll Studium aufrufen und von dort den Link "Konstanten" aufrufen . Alternativ können Sie die Konstanten in der Datenbank direkt bearbeiten, z.B. mit isql, psql, dem Access-Frontend oder einem beliebigen anderen Datenbank-Client.

2.3.3.2 Filter und Variablen

Im Hochschul-Repository lassen sich eigene Filter für Studierende und Prüfungen anlegen bzw. ändern. Beispiel Filter Studierende:

2.3.3.3 Hochschulspezifische Anpassungen beim Update

Da HISSOS sehr flexibel in seiner Datenhaltung ist, können gewisse Grundannahmen von SuperX verletzt werden. Außerdem ist es manchmal sinnvoll, gewisse Hochschulspezifika in SuperX einzubauen.

In früheren Versionen von SuperX wurde dieses Problem dadurch gelöst, dass die Scripte geändert wurden. Dies führte aber dazu, dass die Entwicklung zerfaserte und kein SuperX dem anderen glich.

Mit der Version 2.1 wurden erste Schritte zur Vereinheitlichung vorgenommen, z.B. die feste Unterteilung in spezielle ETL-Schritte, die jeweils von einem kontrollierenden Script ausgeführt wurden. Mit Version 3.0 gibt es weitergehende Möglichkeiten: so können beliebige hochschulspezifische Scripte nach jedem ETL-Schritt ablaufen.

Desweiteren wird versucht, über Konstanten das Laden flexibel und ohne Programmierkenntnisse steuerbar zu machen.

2.3.3.3.1 Nachbereitung des Ladens

Mit dem Kernmodul 3.0 hat die Hochschule die Möglichkeit, nach jedem ETL-Schritt hochschulspezifische Anpassungen einzupflegen. Dazu muss lediglich eine Datei mit einem speziellen Namen im Modulpfad liegen. Der Name setzt sich zusammen aus
<<ETL-Schritt>>_<<Hochschulnummer>>.sql

Die folgende Abbildung zeigt den ETL-Rhythmus, Details dazu erfahren Sie im Adminhandbuch Kernmodul.

So wird zum Beispiel das Script
sos_load_1090.sql
Nach dem Laden ausgeführt, wenn in der Datei $SUPERX_DIR/db/bin/SQL_ENV die Umgebungsvariable MNR (für Mandantennummer) auf 1090 gesetzt ist.

Ein Beispiel: An der Uni XY wird das Fachkennzeichen (Haupt/Nebenfach) nicht über das stg -Feld fachkennzeichen erhoben, sondern über die Fach-Nummer. Damit die Zahlen in SuperX stimmen, muss folgender Update gemacht werden:

Dies ist ein kurzes Beispiel. Die Scripte können beliebig lang sein.

Ein weiteres Beispiel: An der Hochschule XY wird der Schwerpunkt und die Prüfungsordnungsversion auf der Ebene von Studiengängen nicht unterschieden:

Achtung: dies geht nur, wenn sich die Regelstudienzeiten der Studiengänge nicht unterscheiden.

Ein weiteres Beispiel: An der Hochschule XY wird der Schwerpunkt und die Prüfungsordnungsversion auf der Ebene von Studiengängen nicht unterschieden:

Und ein letztes Beispiel: An den Hochschulen in Nordrhein-Westfalen werden die amtlichen Abschlüsse etwas anders zugeordnet als in der Bundesstatistik. Das folgende Script korrigiert die abweichenden Schlüssel; dies ist notwendig, damit der View sos_abint_abgrp korrekte Zahlen liefert (dieser wird z.B. in der Abfrage "Studierende nach Abschlüssen" benutzt).

Das Script befindet sich in der Datei $SOS_PFAD/preparation.sql.sam .

2.3.3.3.2 Allgemein: preparation und finalize

Aus Kompatibilitätsgründen mit Version 2.1 des Kernmoduls ist es auch ohne Mandantennummer möglich, hochschulspezifische Transformationen einzubauen. In der Datei $SOS_PFAD/preparation.sql können Sie beliebige SQL-Statements eintragen, die nach dem Laden der Rohdaten (also vor der eigentlichen Übernahme in die SuperX-Tabellen) ausgeführt werden, z.B. Matrikelnummern ausfiltern.   Die Datei $SOS_PFAD/preparation.sql.sam enthält ein paar Beispiel-Statements.

Durch diesen Schritt zwischen Laden und Weiterverarbeitung der Daten können Hochschulen spezifische Anforderungen einbauen, ohne die zentral erstellten Scripte von SuperX anzurühren. Umgekehrt würden die Scripte bei einem Update des SOS-Moduls nicht überschrieben.

In der Datei $SOS_PFAD/finalize.sql können Sie benutzerspezifische Transformationen ausführen, die nach der Transformation ausgeführt werden.

2.3.3.3.3 Lehreinheiten und Kostenstellen

Die Zuordnung von Lehreinheiten ist in SOS uneinheitlich und meist nicht ausreichend gepflegt, deshalb führen die meisten Hochschulen die Lehreinheiten und Fakultäten in den Basissystemen, die näher an der organisatorischen Struktur der Hochschule angesiedelt sind, z.B. HISMBS oder HISCOB. Auch in SuperX kann ein eigenes "Organigramm" der Hochschule gepflegt werden (siehe Administratorhandbuch Kernmodul).

Es gibt zwar die Möglichkeit, die Lehreinheiten aus SOS zu übernehmen, aber im Grunde gilt das nur, wenn Sie die Tabelle k_abstgv exakt gepflegt haben.

SuperX kann die Tabelle direkt übernehmen und die Lehreinheiten in das Organigramm übertragen, durch die Konstante lehr_stg_ab_aus_SOS=1 . Details sind bei der Übernahme erläutert. Wenn Sie das Organigramm aus anderen Quellen füllen wollen (z.B. aus HISCOB), dann müssen Sie folgende zentrale Vorgaben von SuperX beachten:

• • Lehreinheiten sind (wie in HISCOB) im Organigramm im Feld " orgstruktur " mit "30" gekennzeichnet  

Nach der ersten Übernahme können Sie die lehr_stg_ab manuell nachbereiten, z.B. die automatisch generierten Text-Bezeichnungen der Studiengänge (Feld text ) ändern. Bei späteren Updates wird die lehr_stg_ab automatisch aufgefüllt, vorhandene Einträge werden aber nur entfernt, wenn die Konstante lehr_stg_ab_aus_SOS=1 gesetzt wurde. Wenn ein neuer Studiengang vorhanden ist, wird er defaultmäßig der Lehreinheit zugeodnet, der schon andere Studiengänge mit gleichem Fach zugeordnet sind. Existiert kein Fach, dann wird der Studiengang der lehreinheit " LE nicht zugeordnet " (Schlüssel "-99998") zugeordnet. So ist sichergestellt, dass die Summen in SuperX stimmen.

2.3.3.3.4 Fachbereiche und Kostenstellen

Die Fachbereiche sind in SOS meist gut gepflegt und werden nach SuperX aus k_fb übernommen. Die Zuordnung der Fächer zu Fachbereichen (ebenso wie zu Fächergruppen und Studienbereichen) wird aus k_stg übernommen.

Wenn Sie einzelnen Benutzern spezielle Fachbereiche zuweisen wollen, müssen Sie dies in der Benutzerverwaltung Kernmodul "Administration -> Benutzer -> User suchen" tun. Dort Suchen Sie nach dem gewünschten User und klicken in der Ergebnistabelle auf bearbeiten. Sie erhalten folgendes Fenster:

 

Hier können Sie nun dem Benuter spezielle Institutionsrechte zuweisen. Achten Sie darauf, daß Sie beim Zuweisen genau den Schlüssel verwenden, der zum Fachbereich in der Studierendneverwaltung paßt (bei Datenquelle sospos sind die Schlüssel max. zweistellig).

In den Masken zu Einzelprüfungen werden die Fachebreiche im Feld "Einrichtung" dann gefiltert.

 

Soweit so gut. Wenn die Fachbereiche aber für die Einschränkung der Leseberechtigung genutzt werden sollen, muß geprüft werden, ob die Fachbereichsschlüssel aus SOS (in k_fb) mit den Kostenstellen-Schlüsseln im Organigramm (bzw. mit der inst-Tabelle in COB) übereinstimmen. Da der   FB-Schlüssel nur zweistellig ist, ist dies in der Regel nicht der Fall. Deshalb gibt es die Möglichkeit in SuperX, Fachbereiche aus SOS zu Kostenstellen-Schlüsseln zu transformieren. Dazu gibt es eine browserbasierte Maske im Menü Prüfprotokoll Studium namens "Kostenstellen umschlüsseln". Im folgenden Beispiel wird ein Fachbereich "11" zur Kostenstelle "2900000" umgeschlüsselt.

Wenn die Schlüssel festgelegt sind und Sie die Daten aus SOS geladen haben, lassen sich die Fachbereiche in der SuperX-Userverwaltung einzelnen Usern zuweisen. Dies wiederum hat einen Effekt in den Masken zu Einzelprüfungen: Hier wird im Button "Einrichtung" gefiltert auf die jew. Kostenstelle.

2.3.3.3.5 Hochschulzugangsberechtigung

Die Fachhochschulreife berechtigt zum Studium an allen Fachhochschulen, unabhängig vom Studienfach. Universitätsstudiengänge können nicht ergriffen werden. Die fachgebundene Hochschulreife berechtigt zum Studium an allen Hochschularten, also auch den Universitäten. Die Einschränkung besteht im Studienfach. So kann beispielsweise jemand, der die fachgebundene Hochschulreife an einem Wirtschaftsgymnasium erlangt hat, nur Studiengänge in der Fachrichtung Wirtschaft besuchen. Weitere "Fachbindungen" sind die Abschlüsse an technischen Gymnasien oder ernährungswirtschaftlichen Gymnasien. Diese Arten der Hochschulzugangsberechtigung gibt es für das In- und Ausland, um so Bildungsin- und Ausländer zu ermitteln.

Sie können die Einordnung der Hochschulzugangsberechtigungen ändern. Die in SOS übliche "feine" Unterscheidung nach Hochschulzugangsberechtigungen wird in SuperX generell nicht angezeigt, sondern eine aggregierte Variante, die nur zwischen sechs Ausprägungen unterscheidet:

Die Tabelle hs_zugangsber :

Zum Hintergrund der Zuordnung: Um die HZBs aus SOS dieser Gruppierung zuzuordnen, wird jeweils das ASTAT-Kennzeichen aus der SOS-Tabelle k_hzbart ausgewertet. Dieser Schlüssel sollte den Vorgaben der Bundesstatistik folgen. Wenn dies aus irgendwelchen Gründen nicht der Fall ist, muss in finalize.sql ein entsprechendes Update in SQL erfolgen. Hier die vom STBA vorgegebene Gruppierung:

*bis SOS-Modul 0.6rc6 | ab SOS-Modul 0.6rc7

Die Gruppierung richtet sich nach einer Vorgabe des STBA, hier ein Bildschirmausdruck (Auszug):

Die Liste wird im WWW beim STBA sowie bei den zuständigen Statistischen Landesämtern bereitgestellt.

2.3.3.3.6 Hörerstatus

In den Abfragen des SOS-Moduls ist der Hörerstatus meist als Button vorhanden, und die Inhalte werden direkt aus der SOS-Tabelle k_hrst eingelesen. Die Inhalte der Tabelle sind von der Hochschule frei zu pflegen. Nur die Abfrage Studierende nach Hörerstatus erwartet eine der Zuordnung der hochschulinternen Hörerstati zu den Konzepten

• • Haupthörer 

• • Nebenhörer 

• • Studienkolleg 

• • Gasthörer 

• • Sonstige 

SuperX verwendet dabei HIS-konform die Felder astat und his_hrst . Die folgende Tabelle zeigt ein Beispiel.

Der View sos_k_hrst :

Während das Feld apnr (in SOS-GX hrst )von der Hochschule frei gefüllt sein kann, muss der Wert für die amtliche Statistik wie folgt gefüllt sein:

• • his_hrst ist H wenn 'astat=1' (Haupthoerer)  

• • his_hrst ist N wenn 'astat=2' (Nebenhoerer)  

• • his_hrst ist K wenn 'astat=3' (Studienkolleg,  

• • his_hrst ist G wenn 'astat=4' (Gasthoerer) 

Diese Vorschrift muss in SOS eingehalten werden, sonst liefert die Abfrage Studierende nach Hörerstatus (und ggf. andere Berichte für die amtliche Statistik) falsche Ergebnisse. Wenn dies in SOS nicht möglich ist, muss in finalize.sql ein entsprechender Update in SQL erfolgen.

2.3.3.4 Stichtagsbezug der Auswertungen

SuperX rechnet im Bereich der Studierendenstatistik und Prüfungsstatistik standardmäßig wahlweise mit tagesaktuellen und mit stichtagsbezogenen Auswertungen, in allen Abfragen kann man über einen Dialogbutton zwischen tagesaktuellen und stichtagsbezogenen Auswertungen wählen. Es werden ein oder mehrere Stichtage pro Semester definiert, der erste Stichtag ist in der Regel der Stichtag zur Lieferung an das jeweilige Landesamt. Dieser Stichtag wird aus SOS übernommen, wenn die Konstante semester_aus_sos auf 1 gesetzt ist, und in der SuperX-Tabelle semester abgelegt.

Bei tagesaktuellen Auswertungen ist das Bezugsdatum der jeweils heutige Tag.

Beim Stichtagsbezug gibt es die Möglichkeit, durch Archivierung von Inhalten einen "echten Stichtagsbezug zu erreichen.

2.3.3.4.1 Stichtage in der Studierendenstatistik

Die Frage, ob ein Studierende zu dem vorgebenen Zeitpunkt (ob Stichtag oder "heute") eingeschrieben / rückgemeldet ist oder nicht richtet sich dach dem Datum der Einschreibung, Rückmeldung oder Exmatrikulation. Neben der reinen Gültigkeit eines Datensatzes wird aus SOS also auch der Zeitbezug der Einschreibung, Rückmeldung oder Exmatrikulation übernommen und ausgewertet. Eine Einschreibung, Rückmeldung oder Exmatrikulation wird in SOS mit einem eindeutigen Datum versehen (die Rückmeldung ist allerdings kein Pflichtfeld, daher ist es häufig leer).

  Der Status kann dementsprechend vier Ausprägungen haben. Hier die Regeln für den jeweiligen Status bei stichtagsbezogener Auswertung:

Der Einschreib- oder Rückmeldestatus eines Datensatzes wird also in Abhängigkeit vom Datum des Stichtags gesetzt. Wenn z.B. ein Studierender sich am 4.10.2005 für das WS 2005/2006 exmatrikuliert, und der Stichtag der Auswertung der 15.11.2005 ist, dann wird der Status für diesen Stichtag auf "Exmatrikuliert" gesetzt. Wenn ein Studierender sich hingegen am 17.11.2005 exmatrikuliert, dann bleibt der Status für diesen Stichtag "Rückgemeldet".

Im Bereich der Studierendenstatistik wird für jedes Studienfach aus dem Endedatum (in SOS das Feld " endedat " der Tabelle stg ) ermittelt, wann das Fach beendet wurde. Exmatrikuliert sind die Studierenden dann, wenn dies das letzte Semester ist (sonst wären es Fachwechsler).

Diese Regeln weichen im Detail ein wenig von der Berechnung in HIS-BSOS ab.

Hier die Regeln für den jeweiligen Status bei tagesaktueller Auswertung:

2.3.3.4.2 Stichtag durch Archivierung

Es ist möglich, durch Archivierung in SuperX einen "echten" Stichtagsbezug der Stammdaten zu erreichen, wobei folgende Regeln gelten:

• • Jeder neue Datensatz (Studierenden,- Fächer -und Prüfungssatz) wird zunächst mit dem vorhandenen Datenbestand verglichen.  

• • Wenn der Satz noch nicht existiert, wird er mit maximaler Gültigkeit hinzugefügt. 

• • Wenn sich ein Datensatz geändert hat, wird der alte Datensatz in seiner Gültigkeit begrenzt (bis zum aktuellen Datum), und der neue Datensatz wird mit der Gültigkeit ab dem aktuellen Datum hinzugefügt. 

• • Wenn ein Datensatz in SOS gelöscht wurde, wird er in SuperX in seiner Gültigkeit bis zum aktuellen Datem begrenzt. 

In SuperX kann also also der Datenbestand nicht mehr wie früher komplett ausgetauscht werden, sondern wie in einem Haushaltssystem mit "Storno"-Buchungen additiv ergänzt werden.

Diese Buchungshistorie sorgt dafür, dass man in SuperX jederzeit den Datenstand von SOS zu einem Stichtag auswerten kann. Prinzipiell ist es möglich, direkt mit einem beliebigen Datum auf die Grunddaten zu gehen. Diese Funktionalität ist eher den "Power"-Usern vorbehalten.

Sie können die Archiverung später jederzeit über die Konstante SOS Archivierung=1 einschalten.

Wenn Sie die Archivierung eingeschaltet haben und größere Updates auf der SOS-Datenbank machen (z.B. bei einem Versionswechsel von HISSOS), dann sollten Sie in dieser Zeit das Laden nach SuperX stoppen, sonst werden alle "Zwischenstände" ebenfalls archiviert, und das Datenvolumen steigt unverhältnismäßig an. Das gleiche gilt, wenn Sie größere Updates auf Tabellen des von HISSOS machen.

Wenn Sie die Archivierung eingeschaltet haben und dies später wieder rückgängig machen wollen, müssen Sie in den Tabellen sos_sos , sos_stg und sos_lab alle Datensätze löschen, die vor dem Datum gültig waren,   also mit

Danach setzen Sie die Konstante SOS Archivierung auf 0.

2.3.3.4.3 Stichtagsbezug "klassisch" :nach Datum der Rückmeldung / Immatrikulation / Beurlaubung / Exmatrikulation

Bei diesem (in SuperX fest eingebauten) Stichtagsbezug werden Studierende je nach Datum der Rückmeldung / Immatrikulation / Beurlaubung / Exmatrikulation gezählt oder nicht. Die Hilfstabellen werden dann stichtagsbezogen gefüllt.

Aus Performancegründen und zur Vereinfachung der Anwendung werden ein oder mehrere Stichtage pro Semester definiert (z.B. "Stichtag für die amtliche Statistik"). Diesem Stichtag werden die einzelnen Datumssätze pro Semester zugeordnet; so wird z.B. für den Stichtag der amtlichen Statistik-Lieferung im WS 2005/2006 das Datum 15.11.2005 zugewiesen.

Natürlich bringt die Stichtagsfunktionalität einen gewaltigen Daten-"Overhead" mit sich (der sich unserer Meinung nach aber auch lohnt!); wenn Sie in der aktuellen Version des SOS-Moduls in SuperX darauf verzichten wollen und immer tagesaktuelle Daten sehen wollen, müssen Sie

• • alle Einträge in der Tabelle sos_stichtag löschen außer die, bei denen im Feld name "Aktuelle Zahlen" steht 

• • die Konstante "SOS Archivierung" auf 0 setzen 

• • die Konstante "Semester aus SOS" auf 0 setzen 

• • die Tabelle semester manuell pflegen 

In den Auswertungen ist der Button dann immer leer bzw. steht auf "Aktuelle Zahlen".

2.3.3.4.4 Stichtagsbezug bei Prüfungen

Generell gilt: Stichtagsbezug bei Prüfungen wird nur bei Vor-/Hauptprüfungen und Abschlussarbeiten ausgewertet. Bei Einzelprüfungen (Klausuren, Module etc) werden nur tagesaktuelle Statistiken erzeugt. Die folgenden Ausführungen gelten also nicht für Einzelprüfungen.

Prüfungen werden im Vorsystem in zwei unabhängigen Zeitdimensionen erfasst: das Prüfungssemester ( lab.psem ) und das Prüfungsdatum ( lab.pdatum ). Erfahrungsgemäß weichen die Zeitpunkte manchmal voneinander ab, die Hochschule kann dies über den Eintrag im Feld "Stichtag Prüfungen" steuern: das Prüfungssemester werten Sie bei "semesterbezogene Zählung" aus, bei Stichtag "tagesaktuell" das Prüfungsdatum.

Bei Lieferungen von Abschlussprüfungen an die amtliche Statistik wird über das Prüfungsdatum ( lab.pdatum )   das zugehörige Semester ermittelt. Wenn eine Prüfung in Prüfungssemester aber ein Vorsemester hat, und das Prüfungsdatum vor dem Stichtag liegt, dann wird sie dem Vorsemester zugeordnet.

Dies hat folgenden Hintergrund: Prüfungen werden häufig noch   nach Meldung Semesterende verbucht. Man kann daher für jedes Semester einen Stichtag definieren, der i.d.R. in der Mitte des Folgesemesters liegt.

Beispiele:

Prüfung im Folgesem., aber vor dem Stichtag:

Prüfungssemester = SS 2010, Prüfungsdatum=10.10.2010, Stichtag=1.12.2010 --> Semester der Prüfung=20101

Prüfung im richtigen Sem., vor dem Stichtag:

Prüfungssemester= WS 2010/2011, Prüfungsdatum=10.10.2010, Stichtag=30.6.2011 -> Semester der Prüfung= WS 2010/2011

--Prüfung im Folgesem,, nach dem Stichtag:

Prüfungssemester=SS 2010, Prüfungsdatum=10.01.2011, Stichtag=1.12.2010 -> Semester der Prüfung= WS 2010/2011

  Das Datum ist aber bei Hochschulen häufig bei Vorprüfungen nicht gepflegt. Wenn das Datum der Prüfung nicht erhoben ist, kommt die Prüfung bei der Einschränkung "Stichtag amtl. Statistik)" zu dem Semester in die Statistik, das   im Prüfungssemester ( lab.psem) eingetragen ist.

In den Berichten ist es möglich, jeden Zeitbezug separat auszuwerten, bzw. sogar eigene Stichtage anzulegen.

Bei den Abfragen wird im Button "Stichtag Prüfungen" der Zeitbezug ausgewählt.

Bei den Abfragen wird das Datum der Prüfung ausgewertet, wenn Sie die Ausprägung "Amtl. Statistik Land (Prüf.)" oder "Aktuelle Zahlen" wählen. Bei der "semesterbezogenen Zählung" wird das in zugeordnete Semester gezählt (bei POS Feld psem in lab ).

2.3.3.4.5 Prüfungen und Archivierung : Stichtagsbezug bei Prüfungen bei eingeschalteter Archivierung

Wenn eine Prüfung erst nach dem Stichtag als "Bestanden" verbucht wird (z.B. wenn der Gutachter einer Abschlussarbeit die Bewertung verspätet abliefert), dann wird diese Prüfung bei der jeweiligen   Meldung im Folgesemester nachgemeldet. Das STALA rechnet diese Prüfung dann aber dem Folgesemester zu.

Beispiel:

Eine Abschlussarbeit wird am 25.9.2006 abgegeben. Der Datensatz bekommt das Prüfungsdatum 25.9.2006, die Prüfung fällt in den Zeitraum des Sommersemesters (1.4.2006-30.9.2006). Sie zählt also für das SS 2006, ist aber noch nicht als "bestanden" verbucht. Der Gutachter kommt nicht dazu, die Arbeit bis zum Lieferungsstichtag für das SS 2006, den 1.12.2006, zu bewerten. Die Bewertung trifft erst am 15.2.2007 ein und wird erst dann in POS als "Bestanden" verbucht. Das Prüfungsdatum bleibt der 25.9.2006. Da die STALA-Lieferung für das SS 2006 bereits erfolgt ist, wird die Prüfung erst bei der Lieferung am 1.6.2007, also bei der WS-Lieferung, ans STALA übertragen. Das STALA rechnet die Prüfung zum WS 2006/2007, nicht zum SS 2006, obwohl die Prüfung vom Datum her dorthin gehört.

  Wenn eine Prüfung nach dem Stichtag geändert wird (wie z.B. oben nachträglich auf "Bestanden" gesetzt wird), wird der Datensatz in SuperX überschrieben, die Absolventenzahl für das Semester ändert sich also. Im obigen Beispiel würde die Prüfung also nachträglich zum SS 2006 gezählt.

Bei eingeschalteter Archivierung besteht der Sinn dieses Verfahrens liegt darin, dass bereits gelieferte und veröffentlichte Statistiken nicht nachträglich geändert werden sollen. Um zu vermeiden, dass die Prüfung ganz unter den Tisch fällt, rechnet man sie hier also lieber zum Folgesemester.

Die folgende Tabelle zeigt Beispielprüfungen:

Wenn die Prüfung zum gleichen Zeitpunkt gültig ist wie das Datum der Prüfung selbst, d.h. wenn sie rechtzeitig in POS eingegeben wurde, wird die Prüfung ganz normal zu dem Semester gezählt, in die das Datum fällt.

Interessant ist die fett gesetzte Prüfung: Vom Datum her gehört sie in das WS 04/05. Da die Prüfung aber erst am 02.06.2005 in POS eingegeben wurde, d.h. nach dem Stichtag 31.05.2005 ans STALA geliefert wurde, wird sie zum SS 05 gezählt.

2.3.3.4.6 Verwaltung der Stichtage

Bei der Installation des SOS-Moduls werden die Stichtage für jedes Semester aus SOSPOS übernommen. Die SOS-Tabelle heißt sossys , das Feld heißt stistat :

 

Bei der Studierendenstatistik ist dies in der Regel die Mitte des Semesters (z.B. in NRW der 1.12. für das WS). Bei der Prüfungsstatistik ist der Stichtag für Prüfungen standardmäßig das Datum des Semesterendes +60 Tage, d.h. die Mitte des Folgesemesters.

Sie können den Stichtag für Prüfungen nachträglich ändern, indem Sie in der Maske "Prüfprotokoll Studium" rechts auf den Link "Stichtage (neu)" klicken (s.u.) und dort den Wert in der Spalte "Datum" verändern. Diese Änderung wird   nicht durch die Laderoutine überschrieben.

Der Stichtag für die amtliche Studierendenstatistik wird, wenn die Konstante "semester_aus_SOS"=1 gesetzt ist, aus SOS (Tab. sossys.stistat) übernommen. Den Wert können Sie in den Bearbeitungsformularen nicht überschreiben.

2.3.3.4.7 Eigene Stichtage anlegen

Neben den in SuperX ausgelieferten Stichtagen zur amtlichen Statistik können Sie auch eigene Stichtage festlegen. Dazu muss man zunächst in der Maske Prüfprotokoll Studium auf den Link "Stichtage" klicken und dort einen   Stichtag anlegen, z.B. "1 Monat vor Semesterbeginn". Legen Sie dabei fest ob es sich um einen Stichtag für Studierende oder Prüfungen handelt.

Danach können Sie diesem abstrakten Stichtag einzelne Datumswerte zuordnen. Klicken Sie dazu auf den Link "Stichtage (neu)". Dort können Sie pro Semester einen Stichtag anlegen und speichern. In der folgenden Abbildung ist z.B. der Studierenden-Stichtag "Test" angelegt, dem in drei Semestern Stichtage zugeordnet sind:

 

Das jeweilige Datum wird dann für die Studierenden- oder Absolventenzählung ausgewertet.  

2.3.3.4.8 Alte Semester nachträglich einspielen

Viele Hochschulen haben in der Vergangenheit immer zum jew. Stichtag einen Dump der kompletten SOSPOS-Datenbank angelegt, um stichtagsbezogene Daten zu archivieren. Man kann auch aus dem jew. Dump entladen, und den Stand in SuperX laden. Man darf dabei aber nicht die Archivierung einschalten, denn die Daten bekommen dann den Gültigkeitszeitraum "heute", nicht rückwirkend. Man müßte das SOS-Modul umprogrammieren, daß man Daten rückwirkend einspielt.

Es gibt noch eine "Low-Cost"-Variante: Ohne Archivierung alle Altdaten laden, und für jedes Semester den sos_update.x ausführen, und dann die Hilfstabelle sos_stg_aggr bzw. sos_lab_aggr für das jew. Semester einfrieren. Das geht mit der Konstante SOS_start_stg_aggr bzw. SOS_start_lab_aggr in der Konstantenverwaltung .

Wenn dann alle Altdaten drin sind, kann man die Archivierung für zukünftige Semester einschalten. Im folgenden wird beschrieben wie man die Hilfstabelle archiviert.

2.3.3.5 Archivierung einzelner Semester in der Hilfstabelle

Normalerweise werden die SuperX-Hilfstabellen jede Nacht komplett neu aufgebaut, damit die Abfragen jeweils immer auf die aktuellen Daten zugreifen.

  In der Praxis hat sich gezeigt, dass es sinnvoll sein kann, erst ab einem definierten Semester die Hilfstabelle neu aufzubauen:

• • Wenn Sie auch tagesaktuelle, aber eben ältere Stände, einfrieren wollen, ist dies die einzige Möglichkeit.  

• • Wenn Sie ältere Stände einfrieren wollen,   ohne die aufwändige SuperX-Archivierung zu nutzen, können Sie ältere Semester so unangetastet lassen.  

• • Bei großen Tabellen mit weit zurückliegender Historie kann es außerdem ein Performancegewinn sein. 

Sie können in den Konstanten SOS_start_stg_aggr und SOS_start_stg_aggr jeweils ein Startsemester eingeben, und schon bleiben die Daten von allen vorherigen Semestern unangetastet, die nicht tagesaktuell sind.

Setzen Sie z.B. SOS_start_stg_aggr=20052 , dann werden die stichtagesbezogenen Statistiken   aller Semester vor dem WS 2005/2006 nicht mehr neu berechnet.

Allerdings müssen Sie folgendes beachten: auch die tagesaktuellen Zahlen für das jew. Semester werden immer neu berechnet. Nur so bleiben die tagesaktuellen Werte vergleichbar mit denen im Vorsystem.

2.3.3.6 Gewichtungsfaktoren

Studierendenzahlen lassen sich anhand der Abschlüsse, Fachnummern und Fachkennzeichen unterschiedlich gewichten, die Berechnungsgrundlage wird in der Tabelle sos_gewichtung gelegt. Bitte ändern Sie die Tabelle nicht, sie wird bei jedem SOS-Update neu erzeugt. Unten finden Sie eine genaue Beschreibung der Gewichtung. Vorab ein Hinweis für den Fall, dass Sie die Gewichtung ändern wollen:

Mit dem SuperX-SOS-Modul wird eine Tabelle ausgeliefert, die für amtliche Abschlüsse Gewichtungsfaktoren enthält: sos_gew_astat . Je nach Bundesland werden in SOS aber nicht die Bundesschlüssel benutzt, sondern landesspezifische. Im SuperX-Projekt sind wir bestrebt, die Tabellen für einzelne Bundesländer zu sammeln, aber bei der dynamischen Entwicklung im Bereich der Studienabschlüsse können wir kaum mithalten; die Tabelle muss also auf Gültigkeit und Vollständigkeit der Gewichtungsfaktoren   geprüft werden.

2.3.3.6.1 Gewichtete Fälle

Ein Beispiel für Gewichtungsfaktoren:

Die Dimension "Köpfe oder Fälle" kann auch mit dem folgenden Parameter belegt werden: "Gewichtete Fälle". Dahinter verbirgt sich folgender SQL-Code:

studiengang_nr in (1,2,3,4,5,6) and fach_nr in (1,2,3,4,5,6) and 'gew' = 'gew'

Dieser Code dient als Filter (intern als where-Bedingung) für die Studierendendaten. Die einzelnen Studierenden werden dann nach amtlichem Abschluss und amtlichem Fachkennzeichen bzw. der Fach-Nr. gewichtet.

Für das Merkmal "gewichtete Fälle" existiert z.B. folgende Vorgabe in SuperX (Auszug aus sos_gew_astat ):

2.3.3.6.2 Vollzeitäquivalente

Die Ausprägung "Vollzeitäquivalent" gewichtet anders als die Ausprägung "gewichtete Fälle" nicht über das Fachkennzeichen, sondern über die Fach-Nummer. Die Dimension ist derzeit nicht aktiv, kann aber wie folgt aktiviert werden:

Fügen Sie der Tabelle koepfe_oder_faelle den folgenden Eintrag hinzu (den ersten Wert tid müssen Sie anpassen, wenn Ihre Tabelle eigene Einträge enthält):

INSERT INTO koepfe_oder_faelle (tid,apnr,eintrag,erlaeuterung) VALUES

(10,'studiengang_nr in (1,2) and fach_nr in (1,2,3) and ''vzae = ''vzae''','Vollzeit-Äquivalente','Vollzeit-Äquivalente: gezählt werden die Belegungen in den 1. beiden Studiengängen, bei Diplom-/Bachelor-/Master das 1. Fach (jew. mit 1), bei Lehramt die 1. beiden Fächer (jew. mit 0,4 und zus. mit 0,1 pro Fach bei Lehreinheit Pädagogik), bei Magister die 1. drei Fächer(HA mit 0,5, NF mit 0,25)');

Danach werden folgende Faktoren genutzt (Auszug aus sos_gew_astat ):

2.3.3.6.3 Fachfall-Äquivalente

Die Ausprägung " Fachfall-Äquivalente " gewichtet anders als die Ausprägung "gewichtete Fälle" nicht über das Fachkennzeichen, sondern über die Fach-Nummer. Die Dimension ist derzeit nicht aktiv, kann aber wie folgt aktiviert werden (den ersten Wert tid müssen Sie anpassen, wenn Ihre Tabelle eigene Einträge enthält):

Fügen Sie der Tabelle koepfe_oder_faelle den folgenden Eintrag hinzu:

INSERT INTO koepfe_oder_faelle (tid,apnr,eintrag,erlaeuterung) VALUES

(11,'studiengang_nr in (1,2,3) and fach_nr in (1,2,3) and ''ffaelle'' = ''ffaelle''','Fachfall-Äquivalente','Fachfall-Äquivalente: gezählt werden die Belegungen in den 1. beiden Studiengängen, bei Diplom-/Bachelor-/Master das 1. Fach, bei Lehramt die 1. beiden Fächer, bei Magister die 1. drei Fächer; gew. werden alle Belegungen mit Ausnahme Magister-NF mit 1, diese mit 0,5 ');

Danach werden folgende Faktoren genutzt (Auszug aus sos_gew_astat ):

2.3.3.7 Button Filter Studierende

Die Studierenden-Abfragen des SOS-Moduls haben in den Abfragemasken einen Button namens "Filter Studierende". Dieser Button ist vorbelegt mit Beispieleinträgen, bei denen z.B. nach 1. Hochschulsemester gefiltert wird.

Der Feldinhalt des Buttons kann vom Administrator leicht mit eigenen Werten gefüllt werden. Der Feldinhalt ist in Form einer SQL-Where-Bedingung auf die Tabelle sos_stg_aggr formuliert, die zur Laufzeit in die Abfrage eingefügt wird. Dies ermöglicht eine flexible Anpassung der eigenen Filter.

Die Hochschule kann beliebig viele eigene Filter auf die Tabelle sos_stg_aggr einbauen und sogar kombinieren. Wenn ein Filter eingebaut wird, muss er in die Tabelle sx_repository eingetragen werden (Neue ID vergeben, Feld art ="SOS_STUD_FILTER" ). Sie können dazu die Bearbeitungsmaske Filter Studierende verwenden (Link im XML-Frontend in der Maske Prüfprotokoll Studierende in der rechten Seitenleiste).

2.3.3.8 Fächer-Sichten

Eien der Stärken des SOS-Moduls ist die variable Aggregierung von Ergebnisausgaben und Filtern mit Hilfe von Fächer-Sichten. Im Lieferumfang des SOS-Moduls enthalten sind einige hierarchisch aufgebaute Fächer-Sichten, die jedoch auf gewissen Vorbedingungen der Schlüsselpflege in HISSOS beruhen.

Die Sichten sind (bis auf die Lehreinheits-Sicht) nicht datumsbezogen, und innerhalb der Sichten greifen keine Userrechte.

Die einfachste Sicht ist die Sicht "Fächer (intern)", diese stellt einfach eine Liste der Studienfächer in k_stg bereit. Die anderen Sichten arbeiten mit unterschiedlichen Hierarchien. Wenn Sie eine oder mehrere Sichten nicht benutzen wollen, können Sie sie im Administrationsbereich des XML-Frontends deaktivieren: Rufen Sie die Maske "Sicht suchen" auf (Sicht-Art "Fächer-Sicht"), wählen Sie bei der entsprechenden Sicht den Bearbeiten-Button. Dort können Sie im Bearbeitungsformular ganz unten den Schalter "aktiv" auf 0 setzen, dann wird die Sicht nicht mehr geladen. Danach müssen Sie im Manager den Cache leeren.

Eine manuelle Bearbeitung der Inhalte der Sichten ist generell nicht möglich, Sie müssen dies im entsprechenden Vorsystem HISSOS oder HISCOB (nur Lehreinheitszuordnung) tun. Alternativ können Sie schlüssel über preparation.sql ändern, die setzt aber fundierte Datenbankkenntnisse voraus.

Sie können die Sortierung der Sichten im Button (und damit auch die erste beim Aufruf der Maske aktive Sicht) verändern, indem Sie als Administrator in der Kernmodul-Abfrage "Sicht suchen" auf die Sichtart "Fächer-Sicht" einschränken, die jeweilige Sicht dann bearbeiten und dort die Sortiernummer ändern.

2.3.3.9 Verwendung der Masken für das externe Berichtswesen

Da die Masken des SOS-Moduls sehr viele Parameter für möglichst differenzierte Auswertungen enthalten, sind sie für das externe Berichtswesen nur noch bedingt geeignet. Um dieses Problem zu umgehen, gäbe es einerseits die Möglichkeit, die Masken in den hochschulspezifi schen Bereich zu kopieren und dann zu "entschlacken". Dieses Vorgehen ist allerdings recht aufwändig, und Änderungen bei einem Upgrade müssten manuell nachgezogen werden. Daher gibt es eine einfachere Lösung, die mit ein wenig html-Kenntnissen leicht umgesetzt werden kann:

Im SOS-Modul werden im Verzeichnis $SUPERX_DIR/webserver/tomcat/webapps/superx/xml zwei Vorlagen sos_masken.htm.sam und sos_masken_jsp.sam ausgeliefert, die die Masken über jsp-Seiten aufrufen und in denen flexible Parameter- und Layoutvorlagen umgesetzt werden können; wenn Sie die Funktion nutzen wollen, benennen Sie diese zunächst um, indem Sie das ".sam" aus dem Dateinamen entfernen:

Die Datei sos_masken.htm liefert eine einfach html-Seite mit einem Aufrufmenü, das leicht in vorhandene Website eingebaut werden kann. Im folgenden das Beispiellayout:

Die Datei sos_masken.jsp wird aus der obigen Datei aufgerufen; übergeben wird dabei mindestens die Nummer der Maske, z.B. href="…/xml/sos_masken.jsp?tid=16000" .

Nun können über den Aufruf der Abfragen Parameter übergeben werden, z.B. das Semester mit href="…/xml/sos_masken.jsp?tid=16000&Semester=20061" . Achten Sie darauf, dass die Parameter möglich sind (dass es z.B. das Semester 20061 in SuperX gibt), und dass keine Leerzeichen in der Aufruf-Zeile stehen.

Alle Parameter, die nicht in der URL stehen, werden mit sinnvollen Defaults belegt (siehe Quellcode der jsp-Datei). Leider ist es für diese Funktion unumgänglich, dass Kennung und Passwort im Klartext in die jsp-Seit eingebaut werden müssen, daher bietet es sich an, für diese Funktion eine speziell "Public"-Kennung mit eingeschränkten Rechten zu erzeugen.

2.4 Upgrade einer vorhandenen Installation

Falls Sie sich nicht sicher sind welche Modulversion Sie nutzen: Die Version steht seit der Version 0.6rc1 in der Textdatei $SUPERX_DIR/db/module/sos/VERSION .

2.4.1 Upgrade des SOS-Moduls von Version 0.6 rc*

Entpacken Sie dann die neue Version des SOS-Moduls. Entladen Sie dann neu aus HISSOS mit dem Entladescript sos_unload.x

Starten Sie   im Verzeichnis $SUPERX_DIR/db/module/sos/upgrade , das Skript sos_upgrade.x . Dieses Skript umfasst auch alle Änderungen der vorhergehenden Release Candidates, Sie können also z.B. bei einem installierten SOS-Modul 0.6rc1 mit Hilfe des Scriptes sos_upgrade.x auf die Version 0.6rc6 upgraden.

Ab dem Modul Version 0.6rc6 können Sie nach dem Upgrade automatisch hochschulspezifische Anpassungen am Datenbankschema vornehmen. Legen Sie dazu eine Datei
$SOS_PFAD/conf/customize.sql
an. Die SQL-Befehle, die dort eingegeben werden, werden automatisch nach dem Upgrade ausgeführt. So bleibt sichergestellt, dass hochschulspezifische Änderungen nach dem Upgrade erhalten bleiben. In dem Script können nicht nur SQL-Befehle, sondern auch Bash-Scripte ausgeführt werden, indem Sie am Zeilenanfang ein "! " (für Informix) bzw. ein "\! " (für Postgres) davor setzen. Im folgenden Beispiel werden zwei Stored Procedures durch Spezialvarianten der jew. Hochschule ersetzt:

Sie sollten hochschuleigene Scripte mit einem Kürzel am Ende des Dateinamens (vor dem .sql ) nutzen, um die Übersicht zu behalten und um sicherzustellen, dass die Datei nicht bei einem Upgrade versehentlich überschrieben wird.

Bei mandantenfähigen Installationen funktioniert dies analog, die Datei muss lediglich heißen: customize<<MandantID>>.sql , also z.B. customizePHHD.sql .

2.4.2 Upgrade des SOS-Moduls von Version 0.5

Der Upgrade des SuperX-SOS-Moduls 0.5 ist im Alpha-Stadium verfügbar. Da ältere SOS-Module mitunter sehr unterschiedlich gepflegt sind, ist nicht immer ein reibungloser Upgrade möglich. Wichtig ist es daher, vorher eine Sicherung des Datenbankverzeichnisses und der Datenbank zu machen.

Das neue SOS-Modul wird in der Verzeichnisstruktur des alten SOS-Moduls entpackt (siehe Installationsanleitung). Die Rohdaten werden mit dem neuen Entladescript entladen, hierbei bitte den Parameter sos_unl_complete auf true setzen. Statt sos_modul_erzeugen.x gehen Sie in das Verzeichnis $SOS_PFAD/upgrade und starten das Shellscript
sos_upgrade0.5_to_0.6.x

Die Masken werden eingespielt und in den Themenbaum an die Stelle "Studierende / Prüfungen V. 0.6" gehängt. Wichtige Tabellen werden mit alter table umbenannt (z.B. lehr_stg_ab05 ).

Danach können die neuen SOS-Daten eingeladen werden (s.u.). Die Hilfstabellen des SOS-Moduls 0.5 werden mit sos05_update.x aktualisiert .

2.5 Einladen der SOS-Daten nach SuperX

Zum Übernahme der Basisdaten nach SuperX wird das Script $SOS_PFAD/sos_update.x . gestartet. Darin werden die Datentabellen gefüllt bzw.aktualisiert, und die Hilfstabellen neu erzeugt. Die Syntax:

Nach dem ersten Update können Sie die Lehreinheiten / Fachbereiche manuell in Ihre Organigramm-Hierarchie einbauen, beachten Sie dabei aber unsere Vorgaben .

Beim ersten Update dauert das Script natürlich sehr lange; ein kleiner Richtwert: In einer Umgebung mit ca. 50000 Studierenden-Sätzen, 600000 Fächer-Sätzen und 20000 Prüfungssätzen dauert der Ablauf auf einem UNIX-Rechner mittlerer Leistungsfähigkeit ca. 6 Stunden. Nach dem ersten Update werden nur noch die Änderungen ins SOS-Modul übernommen, die Hilfstabellen werden aber jedesmal neu erzeugt. So benötigt das Script im Regelbetrieb ca. vier Stunden.

Bei der Installation ist es sinnvoll, zuerst einen Testlauf mit nur wenigen Rohdaten zu machen. Geben Sie dazu im Verzeichnis $SOS_PFAD ein:
sos_shrink.x

Die Rohdaten werden auf 100 Sätze pro Tabelle reduziert. Prüfen Sie zunächst, ob das Ladescript ohne Fehler gelaufen ist. Wenn kein Fehler aufgetreten ist, machen Sie die Verkürzung der Rohdaten rückgängig mit
sos_unshrink.x

Danach können Sie den "richtigen" Update starten.

2.5.1 Erste Datenkontrolle

Nach dem ersten Update in SuperX SOS sollten Sie stichprobenartig die Gültigkeit der Studierenden- und Absolventenstatistik prüfen. Das erste Ziel sollte sein, die Gesamtzahlen mög lichst ohne spezielle Filter zu vergleichen, damit Sie die möglichen Fehlerquellen möglichst gering halten.

Im Folgenden wird gezeigt, wie Sie einzelne Suchanfragen aus SOS-GX und POS-GX mit SuperX vergleichen können.

2.5.1.1 Studierendenstatistik

In der Suchen-Funktion von SOS-GX können Sie zum Beispiel die Studierenden (Köpfe) vom SS 2005 ermitteln. Das Ergebnis der Suche können Sie als Statistik anzeigen, z.B. Studierende nach Geschlecht und Fachsemester.

 

Das Ergebnis können Sie mit SuperX vergleichen, indem Sie die Maske "Studierende und Studienanfänger nach Geschlecht" aufrufen.

 

Wählen Sie ebenfalls das Sommersemester 2005 aus, und schränken Sie beim Hörerstatus bzw. Status nicht ein (d.h. "Alle"). Beim Stichtag geben Sie aktuelle Zahlen an, und bei den Fächern sollten Sie die Fächer-Sicht "Fächer (intern)" wählen, denn alle anderen Sichten im SuperX-SOS Modul basieren auf alternativen Hierarchien, die wiederum neue Fehlerquellen enthalten können. Die Sicht "Fächer (intern)" ist im Grunde eine einfache alphabetische Liste der Studienfächer in der SOS-Tabelle k_stg .

Im Ergebnis erhalten Sie in der ersten Zeile die Gesamtsumme.

 

Diese Gesamtsumme sollte mit der obigen SOS-GX-Auswertung übereinstimmen, bei diesem Beispiel ist es ein Studierender weniger.

Um dies zu erklären können Sie z.B. im Prüfprotokoll für dieses Semester nachschauen:

 

Es zeigt sich, dass ein Studierender mit der o.g. Matrikelnummer einen NULL-Wert im Feld Fachkennzeichen hat und daher aus der Statistik rausfällt.

Die Prüfumme, die in der Spalte "Tabelle in SOS" ausgegeben wird, entspricht übrigens genau der oben dargestellten Suchtanfrage, d.h. Studierende (Köpfe) eines Semesters ohne weitere Filter.

2.5.1.2 Abgleich der Stati pro Semester bei Datenquelle SOSPOS

Das System wertet den Status eines Studierenden bei tagesaktueller Zählung wie folgt aus:

• • Studierende im aktuellen Semester werden dann als exmatrikuliert gezählt, wenn das Endedatum vor dem heutigen Tag liegt 

• • Studierende in früheren Semestern werden dann als exmatrikuliert gezählt, wenn das Endedatum vor dem jew. Semesterende liegt, und wenn es kein Folgesemester gibt (dann wäre der Student ein Wechsler).  

Alle anderen Stati werden unverändert aus der Tabelle stg übernommen.

Hier eine Anleitung zur Validierung:

Der folgende Select auf der SOSPOS-Datenbank bildet die Login im System nach (Bitte beachten: das Script wurde für das DBMS Postgres geschrieben, wenn Informix genutzt wird,

muss man "current_date" durch "today()" ersetzen.):

SELECT

F.semester,

  F.status,

count(*) as summe

FROM sos S, stg F

where S.mtknr=F.mtknr

and (F.lfdnr=0 or F.lfdnr is null)

and   (S.fehlerkz not in ('F', 'V') or fehlerkz is null)

--Ohne Exmatrikulierte:

and (F.endedat is null   --Entweder endedat ist leer

or F.endedat > current_date   --oder nach Ladedatum exmatrikuliert

  or (F.endedat is not null and S.semester > F.semester) --der Studi ist ein Wechsler,d.h. das Semester des SOS-Satzes ist höher

  )

--nur fürs akt. Sem. oder zukünftige

and F.semester >= (select aktsem from sossys where current_date between sembg and semende)

group by 1,2

union

SELECT

F.semester,

  F.status,

count(*) as summe

FROM sos S, stg F

where S.mtknr=F.mtknr

and   (S.fehlerkz not in ('F', 'V') or fehlerkz is null)

--Ohne Exmatrikulierte:

and (F.endedat is null   --Entweder endedat ist leer

or F.endedat > current_date   --oder nach Ladedatum exmatrikuliert

  or (F.endedat is not null and S.semester > F.semester) --der Studi ist ein Wechsler,d.h. das Semester des SOS-Satzes ist höher

  or F.endedat >= (select semende from sossys E where E.aktsem=F.semester) --Das Endedatum liegt am Ende des Sem. oder höher, d.h. er hat bis Semesterende studiert

  )

--nur für alte Semester

and (F.semester < (select aktsem from sossys where current_date between sembg and semende)

or 0=(select   count(*) from sossys where current_date between sembg and semende)

)

group by 1,2

union

--nun die exmatrikulierten im akt. Sem.:

SELECT

F.semester,

  'X',

count(*) as summe

FROM sos S, stg F

where S.mtknr=F.mtknr

and   (S.fehlerkz not in ('F', 'V') or fehlerkz is null)

--Exmatrikulierte:

and F.endedat is not null   --exmatrikuliert

and F.endedat <= current_date --Wenn jemand erst nach dem Ladedatum exm. wird

--nur fürs akt. Sem. oder zukünftige

and F.semester >= (select aktsem from sossys where current_date between sembg and semende)

group by 1,2

union

--und nun die exmatrik. in älteren Semestern:

SELECT

F.semester,

  'X',

count(*) as summe

FROM sos S, stg F

where S.mtknr=F.mtknr

and   (S.fehlerkz not in ('F', 'V') or fehlerkz is null)

-- Exmatrikulierte:

and F.endedat is not null   --exmatrikuliert

and F.endedat <= current_date --Wenn jemand erst nach dem Ladedatum exm. wird

--Keine Wechsler rein ,d.h. das Semester des SOS-Satzes ist das letzte

and S.semester <= F.semester

--Das Endedatum liegt vor dem Ende des Sem.., d.h. er hat nicht bis Semesterende studiert

and F.endedat < (select semende from sossys E where E.aktsem=F.semester)

--nur für alte Semester

and (F.semester < (select aktsem from sossys where current_date between sembg and semende)

or 0=(select   count(*) from sossys where current_date between sembg and semende)

)

group by 1,2

order by 1,2

Das Ergebnis ist z.B. im WS 2005/2006:

 

In der Tabelle bedeutet status B=Beurlaubt, E=Ersteinschreiber, N=Neueinschreiber, R=Rückmelder und X=Exmatrikuliert. Diese Zahlen lassen sich wie folgt replizieren (Beispiel 126 Beurlaubte):

 

In der Maske wurden "nur Beurlaubte" ausgewählt. Im Ergebnis erhalten wir die 126 Studierenden:

 

Für die anderen Stati funktioniert der Abgleich analog, d.h. in der Maske wählen Sie z.B. "nur Ersteinschreiber", und Sie erhalten folgende Zahl:

.

Die oben dargestellte Prüfroutine hilft beim Abgleich der tagesaktuellen Zahlen. Ein analoges Beispiel haben wir unten für die stichtagsbezogene Auswertung erstellt. Aber zunächst ein paar Erläuterungen.

2.5.1.3 Abgleich mit der amtlichen Statistik aus BSOS

2.5.1.3.1 Allgemeines

Die HIS-Anwendung BSOS generiert für jedes Semester einen Export für das jeweilige Stat. Landesamt. Der Quellcode zur Erzeugung von BSOS wurde vom SuperX-Projektteam mit der Unterstützung von HIS analysiert, und es wurden einige Regeln festgestellt.

Zunächst ist es wichtig, welcher Parameter der BSOS-Anwendung im Bereich Studentenstatistik mitgegeben wird:

 

Je nachdem was hier eingegeben wird, verhält sich der Export völlig unterschiedlich. Mit SuperX vergleichbar ist nur die Option, dass "erst ab Stichtag"+ dem Wert, der in der Tabelle sossys im Feld stistat angegeben wird, gewählt wird. Im Folgenden ein Beispiel:

Erstellt werden soll eine Statistik das Sommersemester 2008 (Berichtssemester = 20081). Das Semester beginnt am 01.04.und endet am 30.09.2008.

Datum des Statistiklaufes: 21.04.2008

Weitere Hinweise zum Abgleich beider Verfahren:

• • Der Datenexport aus BSOS richtet sich zunächst nach dem in der Tabelle sossys eingetragenen Stichtag für das Semester, i.d.R. die Mitte des Semesters. Außerdem richtet sich der Export nach der in dem Feld "Bedingung" eingegebenen SQL-where-Bedingung. 

• • Wichtig ist außerdem, ob in den Systemschaltern der Wert s_var- Variable 13 (Ausgabeformat u. Steuerparameterf. Amtl. Statistik), Wert4="T" gesetzt ist 

• • Wenn ein Studierender sich nach dem Stichtag einschreibt, wird er anders als in SuperX bei der amtlichen Statistik gezählt, sofern der Export nach dem Stichtag erzeugt wird. In SuperX wird das Datum der Immatrikulation ( stg.anfdat ) ausgewertet. 

• • Wenn ein Student sich einschreibt bzw. (im Vorsemester) zurückmeldet und vor dem Stichtag wieder exmatrikuliert, dann wird er nicht gezählt. Achtung: für die Merkmale "exmatrikuliert" wird das Feld sos.status .ausgewertet. SuperX verwendete bis Version 0.6rc6 das Feld stg.endedat , nur bei eingeschalteter Archivierung werden sos.status und sos.exmdat ausgewertet. 

• • Beurlaubte werden in veröffentlichen Statistiken des jew. LDS i.d.R. nicht veröffentlicht. Das Datum der Beurlaubung wird aber in BSOS nicht berücksichtigt. Dies ist ein Unterschied zu SuperX: hier werden Studierende, die sich nach dem Stichtag beurlauben lassen, als rückgemeldet gezählt. 

• • Der Hörerstatus wird bei BSOS aus dem Feld sos.hrst übernommen, in SuperX aber aus dem Feld stg.hrst  

2.5.1.3.2 Prüfscript für Stichtagsdaten in SOSPOS

Um die Statistikgenerierung aus SOSPOS mit der von SuperX bei stichtagsbezogenen Daten abzugleichen, nutzen Sie in eine beliebige Studierenden-Abfrage und schränken Sie ein auf

• • Stichtag: Amtl. Statistik Land 

• • Köpfe oder Fälle: Köpfe 

• • Hörerstatus: Haupthörer (amtlich) 

• • Status: Alle ohne Beurlaubte, ohne Exmatrikulierte 

In SOSPOS nutzen Sie bitte folgenden SQL, um die Studierenden (ohne vor dem Stichtag exmatrikulierte) für das jew. Semester zu ermitteln (hier am o.g. Beispiel des SS 2008 mit dem Stichtag 21.4.2008, Köpfe und Haupthörer (amtlich)):

select count(*)
from stg F,sos S
where F.mtknr=S.mtknr
and F.semester=20081
and (F.lfdnr=0 or F.lfdnr is null)

and (S.fehlerkz not in ('F', 'V') or fehlerkz is null)

and F.status in ('E','N', 'R')
and (S.status not in ('X') or (S.status in ('X') and S.exmdat >= date('21.04.2008')) )
and F.hrst in (select hrst from k_hrst where astat='1')
and F.stgnr='11' ;

Der Select bezieht sich auf ein älteres Semester.   Die beste Übereinstimmung erhalten Sie, wie im folgenden erläutert wird, wenn es sich um das jeweils aktuelle Semester handelt.  

2.5.1.3.3 Zusammenfassende Betrachtung des Statistikabgleichs

Insgesamt zeigen sich ein paar kleine Unterschiede in den Formeln zur Statistikberechnung. Dadurch, dass BSOS die Felder Status und Datum der Exmatrikulation in der Tabelle sos auswertet, können die Statistiken nur für das jeweils aktuelle Semester ausgeführt werden, denn die Felder in der SOS-Tabelle werden ggf. überschrieben (z.B. wenn sich ein Studierender ein zweites Mal exmatrikuliert, oder wenn er sich nur für eine Belegung exmatrikuliert). Wenn vergangene Semester nachträglich ausgewertet werden, können einheitliche Zahlen nur dann garantiert werden, wenn der Datenstand "eingefroren" wird, wie es z.B. in SuperX mit der Archivierung getan wird.

Zusammenfassend: Um eine größtmögliche Übereinstimmung zwischen dem BSOS-Export und SuperX zu erreichen, müssen folgende Maßnahmen getroffen werden:

• • Die Archivierung muss in SuperX eingeschaltet werden 

• • Beim Export in BSOS muss im Feld "Meldung der Exmatrikulierten" der Wert "erst ab Stichtag ..." eingetragen werden. Der Stichtag muss dann in der Tabelle sossys im Feld stistat eingetragen werden. 

• • Die tatsächliche Erstellung des Exports in BSOS sollte am o.g. Stichtag stattfinden. 

• • Mit obigem Vorgehen ist eine Übereinstimmung nur bei Statistiken "ohne Beurlaubte" und "ohne Exmatrikulierte" zu erwarten.  

• • Wenn Sie stattdessen in BSOS das Feld "Meldung der Exmatrikulierten" leer lassen, müssen Sie in SuperX den Status "ohne Beurlaubte" (also mit Exmatrikulierten) wählen. 

2.5.1.4 Absolventenstatistik tagesaktuell

Wie bei der Studierendenstatistik sollten wir möglichst wenig filtern, um zunächst die Gesamtsumme vergleichen zu können. Wählen Sie in POS-GX zum Beispiel in der Suchen-Funktion die Absolventen (bestandene Hauptprüfungen) im Sommersemester 2005 aus:

 

Für das Ergebnis können Sie eine Statistik erzeugen mit einem eigenen Ausgabeformat, z.B. nach Geschlecht und Studiengang-Nummer.

 

Das Ergebnis in POS-GX sieht so aus:

 

Es erscheinen also 279 Köpfe.

Um diese Gesamtsumme mit SuperX zu vergleichen, gehen Sie z.B. in die Abfrage "Prüfungen nach Fach, Fachsemester und Geschlecht":

 

Wählen Sie Köpfe, den Prüfungsstatus "bestanden" und wie oben bei der Studierendenstatisstik (und aus dem gleichen Grund wie oben) die Fächer-Sicht "Fächer (intern)". Beim Stichtag sollten Sie nicht "aktuelle Zahlen" wählen, denn dieser Stichtag geht nach dem Prüfungsdatum. Wählen Sie die "semesterbezogene Zählung", denn diese selektiert das Feld "Prüfungssemester" ( lab.psem ), das wir auch oben in der POS-GX-Selektion gewählt haben.

Das Ergebnis zeigt die Prüfungen, wie sie auch oben in POS-GX selektiert wurden.

 

Die Summe für Köpfe stimmt exakt überein.

2.5.1.5 Absolventen stichtagsbezogen

Die Absolventen nach Stichtag lassen sich wie folgt validieren: Nehmen wir als Beispiel die 149 bestandenen Hauptprüfungen im WS 2004/2005:

 

Nun kann man im Prüfprotokoll Studium im Link "Weitere Einstellungen"->"Semester" den Datumswert für den Semesterbeginn ermitteln:

 

Ebenso kann man im Prüfprotokoll Studium im Link "Weitere Einstellungen"->"Stichtage"->Amtl. Stat. Land (Prüf.)   den Stichtag Prüfungen ermitteln:

 

Nehmen wir nun an, dass wir in SOSPOS folgende Datenpflege haben:

• • Die Prüfungsnummer für Hauptprüfungen lautet 9000 

• • Anerkannte Prüfungen werden nicht ausgewertet 

• • Ebenso keine Teststudenten oder Fehlerfälle 

Dann würde die Selektion in SOSPOS lauten:

select count(*) from lab L,sos S

where L.mtknr=S.mtknr

and L.psem = 20042

and L.pdatum between date('01.09.2004') and   date('30.05.2005')

and (S.fehlerkz not in ('F', 'V') or fehlerkz is null)

and L.pnr=9000

and L.pstatus='BE'

and (L.panerk is null or L.panerk != 'J')

;

und genau die 149 Fälle ergeben wie oben im Screenshot.  

2.5.1.6 Schlüsseltabellen in SOS-GX

Zentrale Schlüssel aus SOS-GX und POS-GX werden nach SuperX in die Tabellen cifx bzw. sos_cifx übernommen. Bei Datenproblemen können Sie in SOS-GX die Tabellen prüfen.:

 

2.5.1.6.1 Geschlecht und Nationalität

 

2.5.1.6.2 Hochschulzugangsberechtigung und Fachkennzeichen

 

2.5.1.6.3 Status und Hörerstatus

 

siehe auch: STBA-Schlüsselverzeichnis: 12.2 (Hörerstatus) und 12.5 (Status)

2.5.1.6.4 Abschlüsse

 

Die   Abschlüsse werden aufgrund des amtlichen Schlüssels (vgl. Schlüsselverzeichnis STBA Abschnitt 4) zu Abschlussgruppen zugeordnet, die dann wiederum in Auswertungen für Gruppierungen genutzt werden, z.B. die Maske "Studierende nach Abschlüssen". Sie können die Zuordnung der internen Abschlüsse im Prüfprotokoll nachvollziehen, es gibt Info-Einträge wie:

Abschluss 84 wird über astat der Abschlussgruppe Bachelor zugeordnet

Die "84" ist dabei der Schlüssel aus der Tabelle k_abint .

2.5.1.6.5 Studienfächer

 

siehe auch: STBA-Schlüsselverzeichnis: 3.2 - Studienfächer

2.5.1.6.6 Studiengänge (Regelstudienzeiten)

 

2.5.1.6.7 Prüfungsstatus und Studienabschnitt

 

2.5.2 Übernahme von Lehreinheiten

Ein zentrales Leistungsmerkmal des SuperX-SOS-Moduls ist es, die Brücke von der Studierendenverwaltung zur organisatorischen Struktur der Hochschule zu schlagen. Dazu hat sich in einigen Bundesländern das Konzept der "Lehreinheit" entwickelt, also der organisatorischen Einrichtung, der die Studiengänge zugeordnet sind. Bitte verwechseln Sie dies nicht mit der kapazitätsmäßigen Zuordnung, die an anderer Stelle (in HISCOB oder dem SuperX-Kennzahlen-Modul) und in erheblich komplexeren Ausmaß gepflegt wird. Für das SOS-Modul reicht es, den Studiengang der organisatorischen Einrichtung zuzuordnen, die hauptsächlich dafür verantwortlich ist, unabhängig von der Lehrverflechtung oder der tatsächlichen Lehrleistung der Lehreinheit.

Wenn Sie vor Ablaufen des Script sos_update.x die Konstante " lehr_stg_ab_aus_SOS " gleich " 1 " setzen, dann wird die Studiengangstabelle wird aus der SOS-Tabelle k_abstgv gefüllt. Wenn Studiengänge in k_abstgv nicht verzeichnet sind bzw. keine Lehreinheitszuordnung dort getroffen ist, wird der Fachbereich des Studienfachs aus k_stg verwendet. Wenn auch hier keine Zuordnung möglich ist, dann wird die Lehreinheit auf den Schlüssel "-99998" gesetzt ("LE nicht zugeordnet").

Damit die Studiengänge auch den Fachbereiche zugeordnet sind, ist die Voraussetzung natürlich, dass die Fachbereiche die gleichen Schlüssel für den Fachbereich (in SOS nur zweistellig) wie in der inst-Tabelle bzw. dem Organigramm in SuperX haben (z.B. "01" für Fachbereich 01).

Nach der Übernahme von Lehreinheiten können die "Feinheiten" in der Studiengangstabelle lehr_stg_ab vorgenommen werden.

2.5.3 Fehlerbehandlung und Regelbetrieb

2.5.3.1 Logdateien

Eine Fehlerdatei steht in der Umgebungsvariable $SOS_PFAD/$SOS_ERRORDAT , die Vorbelegung ist " sos_update.err ". Das Script sos_update.x ruft mehrere Unterroutinen auf. Wenn in jeweils einem Script ein Fehler auftaucht, wird die Logdatei ausgewiesen.

2.5.3.2 Warnungen

Das SuperX-SOS-Modul benötigt teilweise Daten oder Schlüssel, die nicht in SOS vorhanden sind. In Ergebnistabellen werden solche Fälle mit "nicht zugeordnet" kenntlich gemacht. Doch es gibt auch Tabellen, die nicht direkt "sichtbar" sind und in speziellen Fällen benötigt werden. Die Maske "Prüfprotokoll Studium" gibt entsprechende Warnungen aus:

Ladeprotokoll Studium: Bei Warnungen werden je nach Tabelle in SOS / SuperX Semester und Matrikelnummern ausgegeben.

Wenn Sie Pseudonymisierung beim Entladen eingeschaltet haben, dann hilft die obige "Matrikelnummer" natürlich nicht viel. Die SOS-Betreuer müssen die Nummer erst umsetzen. Dazu muss folgender Select ausgeführt werden:

Hier ein Auszug aus möglichen Problemen beim Laden, auf die Sie auch in der Auswahlmaske einschränken können.

Mögliche Probleme beim Laden aus SOS: Neben Fehlern in Stammdaten können auch Unterschiede bei den Prüfsummen oder in Schlüsseltabellen auftreten.

Bei der Datenbereinigung sollten Sie immer zunächst die Probleme in Stammdaten bereinigen, denn Stammdaten, die in SuperX Probleme bereiten, werden aus SuperX gelöscht (sonst laufen die Abfragen nicht, und selbst wenn sie laufen, dann stimmen die Summen zwischen Abfragen nicht überein).

Ein erklärungsbedürftiges Problem ist folgendes:

2.5.3.3 Regelbetrieb und Einrichten des Cronjob

Im Regelbetrieb wird jede Nacht aus SOS entladen und das Entladedatum gesetzt. Die Daten werden von SuperX geladen, und bei erfolgreichem Laden wird das Datum in $SOS_LOAD_PFAD (Datei superx.datum ) verändert. Bei Ladefehlern in SuperX wird das Datum in $SOS_LOAD_PFAD von SuperX zurückgesetzt auf den vorherigen Stand ( superx.datum.alt ). Dies wiederum führt dazu, dass beim nächsten Entladen aus SOS das Datum des letzten erfolgrei chen Ladens nach SuperX verwendet wird, wenn man SOS_UNLOAD_COMPLETE auf false gesetzt hat.

Aus diesem Grunde müssen sowohl die SOS-Entladeroutine als auch die SuperX-Updateroutine die Datei $SOS_LOAD_PFAD/superx.datum schreiben dürfen. Kein Problem, solange der SuperX-Rechner direkt auf die Datenbank HISSOS zugreift, oder das Verzeichnis $SOS_LOAD_PFAD bei einem der beteiligten Rechner gemounted ist (NFS, Samba).

Aber dies kann bei physisch getrennten Rechnern bzw. Netzen problematisch sein, entweder Sie kopieren die Datei superx.datum nach dem SuperX-Update auf den SOS-Rechner, oder Sie setzen im Entladescript die Umgebungsvariable SOS_UNLOAD_COMPLETE auf true - dann wird standardmäßig immer alles entladen . Dies ist gerade am Anfang bei häufigen Ladefehlern leichter zu administrieren. Der Nachteil ist allerdings, dass das Laden dadurch erheblich länger dauert.

Die Fehlerkorrektur und Schlüsselanpassung ist relativ aufwändig; nach unserer Erfahrung ist folgendes Vorgehen erfolgversprechend:

1. 1. Installieren Sie das SOS-Modul ohne Archivierung (Schalter SOS Archivierung=0) und mit dem Schalter SOS_UNLOAD_COMPLETE=true . Richten Sie noch keinen Cronjob, laden Sie lieber erst einmal manuell, und korrigieren Sie Fehler und Schlüssel in SOS. Die SuperX-Logdateien und Prüfroutinen sind dabei hilfreich.  

2. 2. Geben Sie ausgewählten Usern,w enn möglich aus der Abteilung Controlling oder aus der Studierendenverwaltung, Zugang zu SuperX und prüfen Sie die Ergebnisse anhand von vorhandenen SOS-Berichten. 

3. 3. Wenn alle Warnungen behoben sind und die Statistiken stimmen, mounten Sie das SOS-Verzeichnis für die Rohdaten, oder laden Sie direkt aus SOS, und stellen Sie SOS_UNLOAD_COMPLETE auf false . Laden Sie nun jede Nacht via Cronjob (s.u.), und überwachen Sie den Betrieb einige Tage. 

4. 4. Erst jetzt sollten Sie die Archivierung einschalten (wenn es überhaupt gewünscht ist). Steleln Sie sicher, dass genug Prozessor- und Festplattenkapazität vorhanden ist. 

5. 5. Herzlichen Glückwunsch, Sie haben das komplexeste SuperX-Modul im Regelbetrieb!  

Cronjob-Syntax

Beim regelmäßigen Update wird der SOS-Update über Cronjobs erledigt. Dazu muss ein Script erzeugt werden, dass die Umgebungsvariablen von SuperX lädt, und dann das Script $SUPERX_DIR/db/module/sos_update.x startet. Ein Beispielscript liegt in sos_update_cron.x.sam . Dieses fügen Sie in die Crontab ein. Die Syntax kann z.B. so aussehen:

Der SOS-Update wird Di-Sa morgens um 4:00 Uhr ausgeführt.

2.6 Entfernen des SOS-Moduls

Wenn Sie das SOS-Modul nicht mehr benötigen, starten Sie das Script
$SUPERX_DIR/db/module/sos/sos_modul_entfernen.x.
Dieses Script löscht alle Tabellen, Prozeduren und Abfragen aus der Datenbank, und löscht auch die Einträge im Themenbaum. Danach können Sie den Pfad $SUPERX_DIR/db/module/sos löschen.

Wenn Sie nur die Inhalte der Daten- und Hilfstabellen des SOS-Moduls löschen wollen (z.B. aus Datenschutzgründen), ohne das ganze Modul zu deinstallieren, können Sie dies mit folgendem Befehl tun:

DOSQL $SUPERX_DIR/db/module/sos/sos_purge_pg.sql (für Postgres)
bzw.
DOSQL $SUPERX_DIR/db/module/sos/sos_purge_ids.sql (für Informix)

3 Bestandteile des SOS-Moduls

Im SOS-Modul sind die Komponenten von der Datenextraktion bis zur Präsentation enthalten.   Die folgende Abbildung zeigt den Datenfluss.

 

Die Daten werden aus dem Basissystem extrahiert, und die resultierenden Datentabellen werden mit Schlüsseln verknüpft. Teilweise wird auf Schlüseltabellen des Kernmoduls zugegriffen (z.B. das Organigramm), oder auf Tabellen aus dem SuperX-COB-Modul (für die lehr_stg_ab ).

Aus den Datentabellen werden aggregierte Hilfstabellen erzeugt, die wiederum als Basis für die Abfragen dienen. Die Erzeugung der Hilftabellen ist recht aufwändig und dauert erfahrungsgemäß die ganze Nacht; der Vorteil ist aber, dass die Abfragen dadurch erheblich schneller laufen.

3.1 Ordnerstruktur und Umgebung des SOS-Moduls

Die Ordnerstruktur entspricht den Vorgaben von SuperX V. 2.1 (siehe Administratorhandbuch Kernmodul).

Das Masken-Verzeichnis im SOS-Modul ist nicht zu verwechseln mit dem des Kernmoduls: Im Masken-Verzeichnis des SOS-Modul sind die mitgelieferten SOS-Masken gespeichert; das Masken-Verzeichnis des Kernmoduls dient als Arbeitsbereich für eigene Anpassungen. Diese Trennung ist wichtig, falls Sie Updates oder neue Abfragen zum SOS-Modul installieren wollen.

3.1.1 Studierendendaten: Stammdaten

Aus der Tabelle sos werden Daten übernommen, die für demographische oder geschlechtsspezifische Auswertungen benötigt werden. Die Matrikelnummer ist ein zentraler Schlüssel für die Stammdatun und für die Fächer bzw. Prüfungen. Die Felder werden beim Abschnitt Datentabellen erläutert.

Bis auf das Geschlecht werden alle Schlüssel in ihrer hochschulinternen Variante entladen, die amtlichen Statistik-Schlüssel werden später in SuperX ermittelt (aus den k_*-Tabellen).

3.1.2 Studiengänge

Aus der Tabelle stg werden Daten übernommen, die für studienfachbezogene Auswertungen benötigt werden. Die Felder werden beim Abschnitt Datentabellen erläutert.

3.1.3 Prüfungen

Aus der Tabelle lab   werden Daten übernommen, die für Prüfungsstatistiken benötigt werden. Die Felder werden beim Abschnitt Datentabellen erläutert.

3.1.3.1 Prüfungsnummern

Bei dern Prüfungen wird die Prüfungsnummer (pnr) mit dem Kennzeichen vpnr bzw. hpnr aus der Tabelle hskonst verknüpft, um Vor- und Hauptprüfung zu ermitteln.

In der Tabelle hskonst können Sie nur jeweils eine Prüfungsnummer als Vor- und Hauptprüfung deklarieren. Wenn Sie mehrere Prüfungsnummern zuweisen wollen, müssen Sie diese manuell (und einmalig) in SuperX einrichten:

1. 1. Legen Sie zunächst beim Entladen   in dem Entladeparameter POS_PNR die jeweiligen Prüfungsnummern an, die Sie überhaupt entladen wollen. 

2. 2. Fügen Sie in der Tabelle cif manuell neue Datensätze hinzu, mit den Feldern:
   tid=<<Nächsthöherer Wert>>
   key=9010
   apnr=<<Die Prüfungsnummer>>
   druck="Vorprüfung" oder "Hauptprüfung" 

3. 3. Wiederholen Sie die Laderoutine. Prüfungen in der Tabelle sos_lab bekommen dann im Merkmal "vor_haupt_pruefung" jeweils ein "V" (für Vorprüfung) oder "H" (für Hauptprüfung). 

Sie können die Prüfungsnummern jederzeit kontrollieren, in SuperX gibt es dazu den View sos_vdhdpnr .

Wenn eine PNR früher als Vor- oder Hauptprüfung deklariert war, und es nun nicht mehr ist, kann es sein dass der entsprechende Datensatz in der cif manuell gelöscht werden muss:

delete from cif where key=9010 and apnr = <<PNR>>;

Grund: SuperX behält immer Schlüssel, auch wenn sie im Vorsystem entfernt werden.

3.2 Datentabellen

Die wichtigsten Tabellen des SOS- Moduls sind die Grundtabellen

• • sos_sos 

• • sos_stg 

• • sos_lab 

Aus diesen Tabellen werden die wichtigsten Hilfstabellen vom SOS-Modul erzeugt.

3.2.1 Tabelle sos_sos : Studierende

Die Tabelle sos_sos in SuperX entspricht einer verkürzten Kopie der sos -Tabelle im SOS-System. Teilweise werden die Schlüssel nach amtlichen Werten umgeschlüsselt, z.B. Bundesland und KFZ-Kennzeichen von Wohnorten. Auch der Rückmeldestatus wird auf SuperX-Schlüssel umgeschlüsselt. Details finden Sie im Script $SOS_PFAD/datentabellen/trans_sos_sos*.sql .

Weitere Details siehe Tabellenschema .

3.2.2 Tabelle sos_stg : Fächersätze (Studiengangdaten)

Die Tabelle sos_stg in SuperX entspricht einer verkürzten Kopie der stg -Tabelle im SOS-System.

Studierende, die sich vor dem Stichtag des jeweiligen Semesters exmatrikuliert haben, haben in dieser Tabelle im Feld kz_guelt_exmatr eine 5 (für exmatrikuliert) und ebenso im kz_rueck_beur_ein . Wenn sie sich nach dem Stichtag exmatrikuliert haben, dann steht im Feld kz_upd stattdessen eine 3 – sie werden also noch für das jeweilige Semester gezählt. Wenn sie sich nach dem Stichtag immatrikuliert haben, steht dort eine 0.

Weitere Details siehe Tabellenschema .

3.2.3 Tabelle sos_lab : Prüfungsdaten

Die Tabelle sos_lab in SuperX entspricht einer verkürzten Kopie der lab -Tabelle im SOS-System und enthält die Abschlussprüfungen.

Prüfungsnoten kommen als dreistellige Zeichenketten aus POS und werden bei der Transformation wie folgt umgewandelt:

• • Dreistellige Werte mit Zahlen werden zu Zahlen mit zwei Dezimalstellen transformiert (z.B. "175" wird zur Zahl 1,75). 

• • Wenn keine Note bzw. eine "800"eingetragen ist, dann giltdie Prüfung als "ohne Note" und wird in entsprechenden Abfragen so ausgewiesen. 

• • Wenn in dem ersten Zeichen ein Wert steht, der keine Note bezeichnet (also nicht imWertebereich "1" bis "6"   bzw "8" für "ohne Note" liegt), wird der Wert ungültig  

Weitere Details siehe Tabellenschema .

3.2.4 Weitere Datentabellen

In der Tabelle sos_anschri werden die Semester- und Heimatanschriften der Studierenden übernommen.

3.3 Schlüsseltabellen

Einige Schlüssel werden aus SOS übernommen und in SuperX benötigt. Zum einen handelt es sich dabei um Schlüssel, die ohne Änderung übernommen werden (für die Schlüsseltabelle cif), und um Schlüssel, die manuell nachbearbeitet werden müssen, z.B. die Lehreinheiten und Studiengänge .

3.3.1 Schlüssel tabellen aus dem SOS-Modul

Folgende Tabellen werden aus SOS entladen (Auszug):

• • k_akfz  

• • k_ikfz  

• • ikfz_bland (ein Ausschnitt aus k_ikfz mit den amtlichen Schlüsseln der Bundesländer) 

• • cif  

• • cifx  

• • sos_cifx  

• • k_stg  

• • k_abint  

• • k_hrst  

• • k_akfz  

Die Schlüsseltabellen werden in SOS gepflegt und automatisch geupdated. Dabei werden Schlüsel, die in SOS gelöscht werden, in SuperX weitergeführt.

3.3.2 Die Schlüsseltabelle koepfe_oder_faelle

Die Dimension "köpfe oder Fälle" ist in SuperX ein sog. "SQL"-Feld, d.h. Administratoren können die Dimension durch Bearbeitung der Tabelle koepfe_oder_faelle beliebig bearbeiten. Die folgende Tabelle zeigt einige Möglichkeiten:

Der Inhalt des Feldes apnr wird zur Laufzeit der Abfragen durch den jeweiligen Platzhalter ersetzt; Sie können die Tabelle erweitern und eigene Ausprägungen flexibel hinzufügen.

Sie können dazu die Bearbeitungsmaske Selektionen im Button Köpfe oder Fälle   (Link im XML-Frontend in der Maske Prüfprotokoll Studierende in der rechten Seitenleiste).

3.3.3 Die Schlüsseltabelle lehr_stg_ab

Die Schlüsseltabelle lehr_stg_ab ist für den SOS-Betrieb in SuperX zentral. Sie enthält die Zuordnung der einzelnen Studiengänge einer Hochschule zu den Lehreinheiten. Die Lehreinheitsnummern in dieser Tabelle müssen identisch mit den Nummern der Lehreinheiten im Organigramm sein.

Außerdem werden hier die Regelstudienzeiten für die Studiengänge gespeichert.

Die Tabelle kann manuell und automatisch gepflegt werden. Sie können auch beide Verfahren gleichzeitig betreiben, SuperX fügt neue Studiengänge automatisch der Studiengangstabelle zu. Vorhandene Studiengänge werden von dem Automatismus nicht berührt.

Die Tabelle im Detail:

Wenn Sie die Lehreinheit oder die Regelstudienzeit aus SOS ( k_abstgv ) füllen wollen, müssen Sie die entsprechende Konstante lehr_stg_ab_aus_SOS auf "1" setzen. Wenn Sie die Lehreinheiten in COB pflegen, müssen Sie die Konstante lehr_stg_ab_aus_COB auf "1" setzen.

Selbst wenn Sie die lehr_stg_ab aus SOS importieren, wird in SuperX dennoch geprüft, ob noch weitere Kombinationen aus Fach, Abschluss etc. existieren, d.h. Studierende darin eingeschrieben sind oder waren. Wenn ja, dann wird die Tabelle automatisch ergänzt, der Bezeichnungstext wird dabei automatisch aus Fachname, Abschlussname etc. zusammengesetzt. Die lehr_stg_ab bildet also den tatsächlichen Datenstand ab.

3.3.3.1 Automatische Übernahme aus HIS-System

Die möglichen Fächerkombinationen werden durch das Script

$SUPERX_DIR/db/module/sos/sos_update.x

in die Tabelle lehr_stg_ab gefüllt. Dabei kann man mit einem Parameter festlegen, dass die Lehreinheitszuordnung direkt aus SOS übernommen wird. Dazu muß vor dem Laden aus SOS die Konstante " lehr_stg_ab_aus_SOS " gleich "1" gesetzt werden.

In diesem Fall werden die SOS-Tabellen k_le und k_abstgv benutzt, um die lehr_stg_ab zu füllen. entladen. Die Regelstudienzeiten sind erst seit HISSOS Version 6.x expliziter Teil der k_abstgv.

Wenn ein neuer Studiengang aus SOS übernommen wird, ordnet SuperX diesen defaultmäßig der Lehreinheit zu, der schon andere Studiengänge dieses Faches angehören. Wenn sich keine Lehreinheit identifizieren läßt, dann wird der Studiengang der künstlichen Lehreinheit "LE nicht zugeordnet" (key_apnr "-999998 " im Organigramm) zugeordnet. Sie müssen diese dann manuell in der lehr_stg_ab zuordnen. Außerdem müssen ggf. Parameter wie Regelstudienzeiten und fach_zaehler nachgetragen werden.

Ein weiterer Weg, die lehr_stg_ab zu erzeugen, besteht darin, die Tabellen cob_stug   sowie cob_su_imp_stud_view aus dem COB-Modul für die Zuordnung der Lehreinheiten zu verwenden. Wenn die Konstante " lehr_stg_ab_aus_COB " gleich " 1 " gesetzt ist, werden zusätzlich die COB-Tabellen benutzt.

3.3.3.2 Umgang mit Änderungen im Vorsystem

Wenn die initiale Datenübernahme aus SOS /COB passiert ist, ist nun die Frage wie   mit Änderungen umgegangen wird. Wenn die Lehreinheiten / Regelstudienzeiten aus SOS bzw. COB übernommen werden, sind unterschiedliche Regelwerke aktiv:

• • Wenn die Konstante "lehr_stg_ab_aus_SOS"=1 gesetzt ist, werden auch Änderungen in der k_abstgv direkt nach SuperX überspielt. 

• • Regelstudienzeiten und Lehreinheiten werden nur dann aus COB übernommen, wenn die Konstante "lehr_stg_ab_aus_COB"=1 gesetzt ist. Generell werden Regelstudienzeiten und Lehreinheiten aus COB, sofern sie einmal zugewiesen wurden, auch nicht mehr überschrieben,es sei denn Sie setzen   die Konstante "lehr_stg_ab_aus_SOS"=1.  

• • Dies hat wichtige Auswirkungen auf Änderungen in COB: Wenn hier Lehreinheiten oder Regelstudienzeit von Studiengängen geändert werden, kommt dies nicht automatisch in SuperX an, die Studiengänge müssen manuell angepaßt werden. Grund: in COB gibt es keine Möglichkeit, Studiengänge zu historisieren bzw. zeitabhängig zu speichern. Eine automatische Übernahme von Änderungen der Regelstudienzeiten und Lehreinheiten aus COB würde bedeuten, daß sich Statistiken zu alten Semestern ändern würden.  

• • Wenn neue Studiengänge hinzukommen, zieht sich SuperX die Lehreinheiten und Regelstudienzeit automatisch nach den obigen Regeln. 

• • In SOS / COB gelöschte Studiengänge bleiben in SuperX erhalten, damit sie in Zeitreihenstatistiken weiterhin ausgewertet werden können. 

3.3.3.3 Manuelle Pflege der lehr_stg_ab

Die Tabelle lehr_stg_ab lässt sich auch manuell pflegen. Dazu gibt es im XML-Frontend eine eigene Abfrage.

In der Auswahlmaske können Sie auf das Fach, den Abschluss etc. einschränken. Beim Stichwort können Sie im Volltext des Studiengang suchen.

Die Tabelle zeigt die möglichen Studiengänge im Fach Angewandte Informatik an. Mit dem "Bearbeiten"-Button können Sie den Studiengang bearbeiten.

Die Bearbeitungsmaske zeigt die möglichen Eingaben, die Sie hier ändern und unten mit dem Speichern-Button speichern.

Bitte beachten Sie, dass manuelle Änderungen der lehr_stg_ab erst nach dem nächsten Laden, also in der Regel am Folgetag greifen.

3.3.4 cif

Die Tabelle cif ist eine zentrale Schlüsseltabelle in Superx und Teil des Kernmoduls. Einige Integer-Schlüssel aus SOS werden in SuperX ebenfalls in der cif gepflegt, z.B. Herkunftsländer. Die relevanten Daten werden aus SOS entladen und in der Datei
$SUPERX_DIR/db/module/sos/rohdaten/unl/cif.unl
gespeichert. Beim Erzeugen des SOS-Moduls wird die Tabelle mit relevanten SOS-Daten gefüllt.

3.3.5 cifx

Die Tabelle cifx entspricht in seiner Funktion der cif, enthält aber Schlüssel vom Typ Character. Die relevanten Schlüssel (z.B. Studiengänge, Abschlüsse) werden aus SOS entladen und in der Datei
$SUPERX_DIR/db/module/sos/rohdaten/unl/cifx.unl
gespeichert. Beim Aktualisieren des SOS-Moduls wird die Tabelle mit relevanten SOS-Daten gefüllt.

Für jeden Schlüssel wird ein dummy-Knoten für "Unbekannter Schlüssel" erzeugt (apnr="-999990").

3.3.6 sos_cifx

Die Tabelle sos_cifx enthält wie die cifx alphanumerische Schlüssel aus SOS. Im Unterschied zur cifx ermöglicht diese Tabelle einerseits, amtliche Schlüssel abzuleiten, und andererseits hierarchische Zusammenhänge abzubilden (durch ein Parent-Feld). So ist es z.B. bei der Dimension "Staat" (key=12) möglich, auch den Erdteil als übergeordnetes Element auszulesen. Daraus wiederum werden die "Sichten" für SuperX erzeugt.

Einige Schlüssel sind sowohl in der cif/cifx als auch in der sos_cifx vorhanden. Dies ist notwendig, um SuperX-Abfragen abwärts-kompatibel zu älteren SuperX-Versionen zu halten.

*Ab SOS-Modul 0.6rc7 obsolet

3.3.7 semester

Die Tabelle Semester wird aus SOS übernommen und enthält alle Semester, für die SOS-Daten vorliegen. Die Tabelle hat folgende Struktur:

Der Stichtag wird benutzt, um Studierende je nach Datum der Statusänderung im Einklang mit der amtlichen Statistik zu zählen. Konkret werden folgende Regeln angewandt:

• • Studierende, die sich nach dem Stichtag exmatrikulieren, bleiben weiterhin "rückgemeldet" (Satus = 3). 

• • Studierende, die sich nach dem Stichtag einschreiben, erhalten den Status "0" und werden im aktuellen Semester gezählt. 

Weitere Erläuterungen zum Stichtag finden Sie an anderer Stelle .

Defaultmäßig wird diese Tabelle aus SOS übernommen (siehe Konstante 'semester_aus_SOS'). Wenn Sie die Tabelle selbst pflegen wollen, müssen Sie die Konstante auf 0 setzen und die Tabelle manuell bearbeiten. Sie können dazu die Bearbeitungsmaske Semester/Stichtage   (Link im XML-Frontend in der Maske Prüfprotokoll Studierende in der rechten Seitenleiste). Achtung: Sie müssen in diesem Fall jedes Semester daran denken, einen neuen Satz manuell hinzuzufügen. Wir empfehlen daher die Pflege in HISSOS.

3.3.8 Die Schlüsseltabelle hoererstatus

Die Tabelle hoererstatus enthält die möglichen Auswahlfelder des Feldes "Hörerstatus" in den SuperX-Masken. Wenn Sie in Ihrem SOS-System andere Codierungen gewählt haben, dann müssen Sie entweder die Entladescripte ändern oder, wenn Sie feine Unterscheidungen wollen, die Tabelle hoererstatus eigenständig anpassen. Zur Unterstützung wird die Tabelle k_hrst aus SOS mitentladen.

Weitere Details siehe Tabellenschema .

Wie die Dimension "köpfe oder Fälle" ist die Dimension "Hörerstatus" in SuperX ein sog. "SQL"-Feld, d.h. Administratoren können die Dimension durch Bearbeitung der Tabelle hoererstatus beliebig bearbeiten. Die folgende Tabelle zeigt einige Möglichkeiten:

Der Inhalt des Feldes apnr wird zur Laufzeit der Abfragen durch den jeweiligen Platzhalter ersetzt; Sie können die Tabelle erweitern und eigene Ausprägungen flexibel hinzufügen. Wenn Sie z.B. die Auswertungen auf "Alle ohne Nebenhörer und ohne Promovenden" einschränken wollen, würden Sie folgende Zeile hinzufügen:

Diese Einschränkung wäre in allen Abfragen aktiv, die den Hörerstatus als Button enthalten.

Sie können   also die Tabelle erweitern und eigene Ausprägungen flexibel hinzufügen. Sie können dazu die Bearbeitungsmaske Selektionen im Button Hörerstatus   (Link im XML-Frontend in der Maske Prüfprotokoll Studierende in der rechten Seitenleiste).

3.3.9 Die Schlüsseltabelle sos_k_hzbart

Die Hochschulzugangsberechtigungen in k_hzbart sind ein Sonderfall: sie werden in SuperX nicht einzeln auswertet, sondern nur gruppiert nach

• • Allg. Hochschulreife 

• • Fachhochschulreife    

• • Allg. Hochschulreife i. Ausland  

• • Fachgeb. Hochschulreife i. Ausland      

• • Sonstige 

Bei der Überahme aus HISSOS werden die astat-Werte der Hochschulzugangsberechtigungen geprüft. Wenn eine neue Hochschulzugangsberechtigung existiert, wird sie zunächst zu den "Sonstigen" gezählt. Die Hochschule muss den Schlüssel dann manuell in der Tabelle sos_k_hzbart nachtragen.

3.3.10 Die Schlüsseltabelle sos_status

In der Schlüsseltabelle sos_status können Sie flexibel Einschreib- oder Rückmelde-Stati kombinieren. Da meist eher Kombinationen aus Stati interessieren, wird der jeweilige Status als SQL-Code in die Abfragen eingefügt. Die Bedeutung der Stati ist in der Tabelle konstanten hinterlegt.

Der Inhalt des Feldes apnr wird zur Laufzeit der Abfragen durch den jeweiligen Platzhalter ersetzt; Sie können die Tabelle erweitern und eigene Ausprägungen flexibel hinzufügen.

Sie können dazu die Bearbeitungsmaske Selektionen im Button Status   (Link im XML-Frontend in der Maske Prüfprotokoll Studierende in der rechten Seitenleiste).

3.3.11 Die Schlüsseltabelle sos_gewichtung

Die Tabelle sos_gewichtung liefert die Gewichtungsfaktoren für die Zählung der Studierenden.

Weitere Details siehe Tabellenschema .

Die Gewichtungsfaktoren sind wie folgt vorbelegt:

-gewichtete Fälle:

LA mit 0.5 pro Fach,

Magister HF 0.5, Magister NF 0.25

Alle anderen mit 1

-Vollzeit-Äquivalente:

LA mit 0.4 pro Fach+ 0.1 für EW-Studium,

Magister HF 0.5, Magister NF 0.25

Alle anderen mit 1

-Fachfall-Äquivalente

Magister HF 1, Magister NF 0.5

Alle anderen mit 1

-Fachfaelle (ungewichtet):

Alle mit 1

Gewichtete Fälle sind in vielen SOS-Abfragen abrufbar, die anderen Zählvarianten in der aktuellen Version noch nicht.

Die Tabelle wird bei jedem Update neu aufgebaut, um die Gewichtung zu ändern muss die Tabelle sos_gew_astat manuell gepflegt werden. Diese wird in dem Script $SUPERX_DIR/db/module/sos/schluesseltabellen/sos_gewichtung_fuellen.sql genutzt, um die Tabelle sos_gewichtung zu füllen.

3.3.12 Konstanten

Die Tabelle Konstanten ist im SOS-Modul sehr wichtig, denn hier werden verschiedene Parameter gesetzt. Die folgende Abbildung zeigt die Bearbeitungsmaske im XML-Frontend.

 

3.3.13 Stichtage

Die Tabelle sos_stichtag enthält die in der Studierenden-Komponente vorhandenen Stichtagsarten. In der Auslieferung sind dies:

Die Tabelle wird über die Oberfläche bearbeitet. Die Spalte Application Key   (in der Datenbank appl_key ) wird intern benutzt, um ausgelieferte Stichtage von   durch die Hochschule angelegte zu unterscheiden:

0/2=aktuelle Zahlen Studierende / Prüfungen

1/4=amtlicher Stichtag   Studierende / Prüfungen

5=Prüfungen nach Prüfungssemester

6=Studierendenstatistik nach Landesvorgabe (derzeit nur in BaWue genutzt)

3.3.14 Weitere Schlüsseltabellen

Zwei Schlüsseltabellen werden direkt ohne Änderung aus SOS übernommen:

• • k_ikfz 

• • k_akfz 

Die Tabellen ordnen KFZ-Kennzeichen zu amtlichen Schlüsseln zu, für das Ausland werden Landesschlüssel benutzt. Sie werden in den Abfragen zum Wohnort der Studierenden benutzt.

Die Tabellen werden beim Update aus dem Basisystem entladen und übernommen. Weitere Schlüsseltabellen für SuperX:

  Eine Reihe von zentralen Schlüsseltabellen aus SOS wurden direkt kopiert (z.B. k_stg ), einige Tabellen mit gleichartiger Struktur wurden in die cif/cifx/sos_cifx übernommen und sind als Views mit dem Namen sos_ versehen (z.B. sos_k_fb ). Die Dokumentation zu diesen Tabellen finden Sie in der HISSOS-Dokumentation.

3.4 Hilfstabellen

Hilfstabellen sind aggregierte Datentabellen, z.B. die Tabelle sos_stg_aggr , die aus den Tabellen sos_sos und sos_stg gebildet wird. Sie erhöhen die Performance der Abfragen, da die Tabellen sinnvoll für einige Abfragen summiert werden.

Anders als die Datentabellen werden die Hilfstabellen jede Nacht komplett neu erzeugt. Je nach Datenvolumen und Rechnerkapazität können sehr unterschiedliche Laufzeiten resultieren. Bei der Installation und für erste Tests sollte deshalb vorsorglich ein eigenes Rechnersystem verwandt werden.

3.4.1 sos_stg_aggr

Die SuperX-Datenbank benötigt für die wichtigsten Studierendenstatistiken die Hilfstabelle sos_stg_aggr . Diese wird mit der Prozedur sp_sosstg_aggr ( proc_sos_stg_aggr_*.sql ) erzeugt und gefüllt.

Die Prozedur greift zum Aufbau der sos_stg_aggr auf die SOS-Tabellen

1. 1. sos_sos  

2. 2. sos_lab  

3. 3. sos_stg  

  zu. Außerdem werden folgende Schlüsseltabellen benötigt:

1. 1. Konstanten (das erste Semester, zu dem SOS-Daten vorliegen) 

2. 2. k_hzbart . (Eine Schlüsseltabelle mit den Hochschulzugangsberechtigungen) 

3. 3. lehr_stg_ab (Die Zuordnung der Studiengänge einer Hochschule zu den Lehreinheiten der Hochschule) 

4. 4. Semester (Eine einfache Tabelle mit den Semestern und deren Schlüsseln) 

Achtung: die Prozedur arbeitet bei umfangreichen Stammdaten sehr lange, sie sollte daher am besten über Nacht laufen, oder man schränkt die Semester ein.

Die Hilfstabelle sos_stg_aggr enthält aggregierte Daten aus den SOS-Tabellen sos_sos und sos_stg . Die Tabelle summiert Studiengänge, demographische Attribute sowie Hörerstatus.

Die sos_stg_aggr wird von sehr vielen Abfragen im SOS-Modul SuperX benutzt.

Zur Stichtagsberechnung:

3.4.2 sos_lab_aggr

Die Hilfstabelle sos_lab_aggr enthält die aggregierten Prüfungssätze. Sie greift zu auf die Zwischentabelle sos_lab_stg , die im Wesentlichen die Prüfungssätze aus sos_lab in Verbindung mit den Studiengängen der lehr_stg_ab enthält - hier ist also die in POS nicht vorhandene Verknüpfung vom LAB -Satz zum STG -Satz vorgenommen worden.

4 Maskenentwicklung im SOS-Modul

4.1 Allgemeines Funktionsprinzip

Im SOS-Modul sind viele Masken verfügbar, die nach dem gleichen Schema aufgebaut sind: Zunächst wird eine temp. Tabelle mit den Basisdaten selektiert, und aus dieser Tabelle wird das Layout der gewünschten Ergebnistabelle gefüllt. Dabei wird im Button "Fächer" über die Sichten-Funktionalität eine Schleife über jedes Fach erzeugt, und die Hierarchie der Ergebnistabelle aufgebaut.

Diese Technik hat sich bewährt und wurde im SOS-Modul 0.7rc2 erweitert: Neben dem Fächer-Button enthalten die Masken auch einen Button "Studiengang", der beliebige Hierarchien enthalten kann. Damit wird dem Wunsch von vielen Hochschulen Rechnung getragen, die Ergebnistabelle individuell aufzubauen. So kann man z.B. einen Baum auf Fakultäten, Lehreinheiten und Studiengängen aufbauen. Aber auch ganz andere Bäume sind möglich, z.B. Studiengänge nach Abschluss. Wichtig ist nur, daß auf der untersten Ebene des Baumes die Studiengänge selektiert werden, denn diese bilden die Basis für die Filterung.

Die Studiengänge können dabei zwar selektiert, aber der Übersichtlichkeit halber auch ausgeblendet werden. Dazu machen wir uns ein Feature des Kernmoduls 3.5rc2 oder höher zu nutze: Ein Sichten-Baum kann auch versteckte Knoten enthalten, die zwar wirksam sind, aber nicht sichtbar sind.

Ein weiteres Funktionsprinzip wurde im Feld "Studiengang" implementiert: Studiengänge können zu Organisationseinheiten zugeordnet werden und für individuelle Berechtigungen genutzt werden.

Um zu steuern, ob die fachliche Hierarchie oder die Studiengangs-Hierarchie für die Ergebnistabelle zugrunde gelegt werden soll, gibt es den Button "Ausgabe":

 

Wenn die Ausgabe "nach Fach" gewählt wird, wird die Studienfach-Hierarchie zugrunde gelegt. Wenn die Ausgabe "nach Studiengang" gewählt wird, wird die Studiengang-Hierarchie genutzt. Im folgenden ein Codebeispiel:

4.2 Codebeispiel

4.2.1 Maskenfelder

4.2.1.1 Fächer-Sichten

Im Feld "Fächer" sind die "Fächer-Sichten" verfügbar, z.B. "Facher (intern)". Über das Feld "quelle" wird der Inhalt der Sicht definiert:

<<SQL>> SELECT ltxt,stg,'fach' as parent,1,'Fach (intern)' as struktur_c FROM k_stg union select 'Fach (intern)','fach',null::char(10),1,'Summe Fach (intern)' from xdummy order by 1

Das Ergebnis dieser Selektion liefert eine Tabelle, aus der über die Spalte stg und parent ein Baum aufgebaut wird:

 

4.2.1.2 Studiengang-Sichten

  Im Feld "Studiengang" sind verschiedene Sichten verfügbar. Darüber hinaus können auch eigene Sichten angelegt werden. Die u.g. Beispiele zeigen, wie das geht.

Die Sicht "Studiengänge (Liste)" zeigt eine alphabetische Liste der Studiengänge, d.h. der Baum ist ganz einfach aufgebaut: ein oberster Knoten "Alle" und darunter die Studiengänge. Hier die Quelle:

<<SQL>> select text,'s_' || tid,'_Alle' as parent,'Studiengang'::char(50) as struktur_str from lehr_stg_ab union select 'Alle', '_Alle',null::char(10),'Alle'::char(50) as struktur_str from xdummy order by 1

Das Ergebnis:

 

Die Sicht "FB/Fak, Fach/Abschluss" baut den Baum ganz anders auf: auf oberster Ebene kommt die Summe, darunter die Fakultäten, und darunter die möglichen Kombinationen aus Fach und Abschluss. Die Studiengänge selbst werden der Übersichtlichkeit halber ausgeblendet:

<<SQL>>select druck,apnr,parent,struktur_str,0 as nodeattrib from sos_k_fb_stgabint where struktur_str != 'Studiengang' union select druck,apnr,parent,struktur_str,1 from sos_k_fb_stgabint where struktur_str = 'Studiengang' order by 1'

Da das Feld "quelle" auf max. 255 Zeichen ausgelegt ist, wird ein Großteil der Programmierung auf einen View sos_k_fb_stgabint   ausgelagert.   Der View hat den Quellcode:

select druck,apnr::varchar(255) as apnr,'_Alle'::varchar(255) as parent,'Fachbereich'::char(50) as struktur_str from sos_k_fb

union

select 'Alle Fachbereiche/Fakultäten','_Alle'::char(10), null::char(10),'Alle' from xdummy

union select distinct trim(K.dtxt) || ' ' || A.dtxt,'_' || K.stg || '_' || A.abint,K.fb,'Fach/Abschluss'

from k_stg K,k_abint A,lehr_stg_ab L

where L.stg=K.stg

and L.abschluss=A.abint

union select L.text,'s_'||L.tid,'_' || L.stg || '_' || L.abschluss,'Studiengang' from lehr_stg_ab L

Es werden also auf der Ebene Fachbereich die Fakultätsnamen selektiert. Darunter werden die möglichen Kombinationen aus Fach und Abschluss selektiert, und darunter die Studiengänge. In der o.g. Selektion auf den View   wird über das Feld nodeattrib=1 der Studiengang selbst ausgeblendet. Alle Zeilen mit nodeattrib=0 werden angezeigt.  

Das Ergebnis:

 

Aus dieser Tabelle wird dann folgender Baum in der Oberfläche erzeugt:

 

4.2.2 Ergebnistabelle

In der Maske Studierende und Studienanfänger nach Geschlecht wird zunächst die temp. Tabelle mit den Basisdaten erzeugt. Hier werden sie Studiengänge mit dem Präfix "s_" (um Überlappungen zu anderen Schlüssel zu vermeiden) selektiert. Außerdem sind die beiden Buttons "Fächer" und "Studiengang" als Filter implementiert. Beide Passagen sind fett hervorgehoben:

-- ##################################################

-- ##### Zwischentabelle und Gewichtung #############

-- ##################################################

<@selectintotmp

select=" ('s_' || L.tid)::varchar(255) as tid, L.text, L.lehr, L.stg as ch30_fach, L.vertfg as ch39_vertief, L.kz_fach, fach_nr,L.abschluss as ch35_ang_abschluss,ca12_staat, geschlecht, fach_sem_zahl, kz_rueck_beur_ein,hssem,sum(summe)::decimal(14,2) as summe"

source="sos_stg_aggr S, lehr_stg_ab L"

target="tmp_sosstatistik">

where <<Köpfe oder Fälle ?>>

and <<Hörerstatus>>

and sem_rueck_beur_ein = <<Semester>>

/* and stichtag = <<Stichtag>> */

and S.tid_stg = L.tid

and L.stg in <@printkeys Fächer.allNeededKeysList/>

and 's_' || L.tid in <@printkeys Studiengang.allNeededKeysList/>

/* and fach_sem_zahl <= <<bis Fachsemester>> */

/* and L.abschluss in (<<Abschluss>>) */

/* and <<Hochschulzugangsber.>> */

/* and L.kz_fach = <<Fachkennz.>> */

/* and kz_rueck_beur_ein in(<<Status>>) */

/* and '' || ca12_staat in <@printkeys Staatsangehörigkeit.allNeededKeysList/> --<<Staatsangehörigkeit>> */

/* and <<Filter Studierende>> */

group by 1,2,3,4,5,6,7,8,9,10,11,12,13

</@selectintotmp>

  <@informixnolog/>;

Danach wird die Ergebnistabelle aufgebaut. Zunächst werden mit Freemarker ein paar Variablen gesetzt:

--Vorbereitung Schleife:

--Default: Schleife über Fächer

<#assign loopElem=<<Ausgabe>> />

<#assign filterCol="ch30_fach" />

<#if "<<Ausgabe>>"="Studiengang">

<#assign filterCol="tid" />

</#if>

Im der Variablen "loopElem" ist entweder der Baum im Button "Fächer" oder im Button "Studiengänge" vorbelegt. Der Name "loopElem" soll andeuten, daß über diesen Baum die Schleife für die Zeilen der Ergebnistabelle genutzt wird.

Die Variable filterCol enthält den Namen der Spalte, die für die Filterung genutzt werden soll. Beim Button Fächer wäre dies die Spalte " ch30_fach ", beim Button Studiengänge die Spalte " tid ".  

Dann beginnt de Schleife über das Schleifenelement:

<#foreach einElement in loopElem.elements>

Die temp-Tabelle mit der Ergebnisstruktur wird aufgebaut. Hier ein Beispiel für Studierende (männlich) im 1. FS:

-- ####### start 1. FS Männer #######################

<#if (einElement.level <= maxEbene)>

insert into tmp_rs_base (ebene,struktur,text,   ch30_fach, kz_fach, fach_nr, ch35_ang_abschluss,   sortnr,m_1fs, w_1fs, m_1hs, w_1hs, m_gesamt, w_gesamt)

select ${einElement.level}::smallint,'${einElement.strukturStr}'::char(50),'${einElement.name}'::char(200), '${einElement.key}'::char(10), kz_fach, fach_nr, ch35_ang_abschluss, ${sortnr},sum (summe),0, 0, 0, 0, 0

from tmp_sosstatistik S

where ${filterCol} in ${einElement.subkeys}

and geschlecht = (select apnr from konstanten where tid=1)

and fach_sem_zahl = 1

group by 1,2,3,4,5,6,7;  

</#if>

Je nachdem worüber die Schleife läuft, wird ein Fach, eine Fakultät oder ein Studiengang eingefügt.

Beim Button "Fächer" gibt es noch die Möglichkeit, direkt unter dem Fach die einzelnen Studiengägne aufzulisten. Dies wird mit dem folgenden Insert geleistet:

<#if "<<Ausgabe>>"="Fächer" && einElement.level &lt; maxEbene && einElement.strukturStr="Fach (intern)" >

insert into tmp_rs_base (ebene,struktur,text,   ch30_fach, kz_fach, fach_nr, ch35_ang_abschluss,   sortnr,m_1fs, w_1fs, m_1hs, w_1hs, m_gesamt, w_gesamt)

select (${einElement.level}+1)::smallint,'Studiengang'::char(50),text, '${einElement.key}'::char(10), kz_fach, fach_nr, ch35_ang_abschluss, ${sortnr},sum (summe),0, 0, 0, 0, 0

from tmp_sosstatistik S

where ${filterCol} in ${einElement.subkeys}

and geschlecht = (select apnr from konstanten where tid=1)

and fach_sem_zahl = 1

group by 1,2,3,4,5,6,7;  

</#if>

4.3 Sichten im Feld Fächer

Der Button "Fächer" beinhaltet verschiedene Hierarchien von Studienfächern (siehe Benutzerhandbuch). Damit die Sichten funktionieren ist es eine Voraussetzung, daß

• • die entsprechenden Schlüsseltabellen im Vorsystem gepflegt sind (z.B. im SOSPOS die Tabelle k_stg und k_astgrp ). 

• • ein eindeutiger Bezug vom Fach zum jeweils übergeordneten Element möglich ist.  

Letzteres paßt zwar bei vielen Hochschulen, bei manchen jedoch nicht, z.B. wenn ein Studienfach je nach Abschluss unterschiedlichen Fakultäten zugeordnet ist.   In SOSPOS werden z.B. Studiengänge nicht in der Tabelle k_stg einem Fachbereich zugeordnet, sondern in der Tabelle k_abstgv . Auch bei Lehreinheiten ist manchmal kein eindeutiger Bezug möglich.

Wenn die o.g. Voraussetzungen nicht gegeben sind, müssen Sie die jeweilige Sicht ausblenden, und stattdessen mit dem Button "Studiengang" arbeiten (s.u.).

4.4 Sichten im Feld Studiengang

Im Button Studiengang sind beliebige Sichten implementierbar, die die Art

• • SOS-Kostenstellen-Sicht 

• • SOS-Studiengang-Sicht  

haben. Ein paar Beispiele werden mit dem SOS-Modul ausgeliefert.

4.4.1 Studiengang-Sichten

Die einfachste Sicht im Feld Studiengänge ist die alphabetische Liste der Studiengänge. Hier können über die Mehrfachauswahl verschiedene Studiengänge kombiniert werden.   Anbei ein Screenshot:

 

4.4.2 Kostenstellen-Sichten

  Wenn Sie die Kostenstellen-Sichten nutzen, haben Sie auch die Möglichkeit, Benutzerrechte zu implementieren, d.h.   steuern, welche Benutzer welche Studiengänge sehen dürfen.

Ein Standardfall ist die Zuordnung von Benutzern zu Fakultäten / Fachbereichen. Im SOS-Modul wird daher die Kostenstellen-Sicht Fachbereiche/Fakultäten+Studiengänge ausgeliefert, hier ein Screenshot in der Oberfläche:

5 Versionshistorie des SOS-Moduls

0.8 (03/2012)

Neuerungen:

• • Abfrage "Studierende nach Fach und Wohnort": Ausgabe nach Bundesland ermöglicht 

• • Neue Abfragen "Studierende nach Abschlüssen (intern)", "Studierende Datenblatt", "Prüfungen Datenblatt", Prüfungen im Detail Datenblatt" ; für das Studierenden-Datenblatt wurde ein erster JasperReport erstellt (Studierende nach Semester und Geschlecht).  

• • Neue Studiengang-Sichten "Standort, Fach (intern), Studiengang" und "Standort, Fach (intern)" 

• • Abfrage "Studierende nach Abschlüssen": LA-Bachelor und LA Master erscheinen unter "Lehramt sonstige" 

• • Bugfix: Vermischung von Schlüsseln bei Standorten und Sperrarten 

• • Bei Belegungsdaten ist Fachkennzeichen kein Pflichtfeld mehr 

• • Möglichkeit der Übernahme vom Prüfungsdatum aus Tabelle dipl 

• • Möglichkeit der Übernahme vom Name, Vorname und Telefonnr. der Studierenden (standardmäßig inaktiv) 

• • Übernahme von Minderungsgründen Studiengebühren 

• • Bei Datenquelle HISinOne wird Zuordnung von Studiengang zu Lehreinheit und Fakultät automatisch übernommen 

• • Bei Datenquelle SOSPOS wird Zuordnung von Studiengang zu Fakultät in erster Priorität aus k_abstgv übernommen, und erst in zweiter Priorität aus k_stg 

• • Verbesserte Performance der Laderoutine 

• • Studierenden-Faktentabelle sos_stg_aggr um Spalten Beurlaubungsgrund, Exmatrikulations-Grund und HZB-Note erweitert. 

• • Bei manueller Archivierung &auml;lterer Semester via Konstante SOS_start_stg_aggr werden die tagesaktuellen Werte immer neu berechnet. 

• • Bei Berechnung der "Studierendenstatistik (Land)" wird 'Berechnen'-Häkchen im KENN-Modul ausgewertet. So kann man die Tabelle auch im laufenden Semester "einfrieren" (wird für Semesterberichte nicht-universitärer Hochschulen BaWue benötigt). 

0.7rc2 (02/2011)

Neuerungen:

• • Bei eingeschalteter Archivierung und tagesaktueller Auswertung von zukünftigen Semestern wurden keine Daten angezeigt. Dies wurde korrigiert. 

• • Amtlicher Schlüssel Standort und Studienart werden nun auch übernommen 

• • In der Abfrage "Studierende und Absolventen (Zeitreihe)" die 'Vertiefung' als Selektions-Kriterium aufgenommen 

• • In der Abfrage "Alter der Studierenden" der Button "Trennen nach" als Selektions-Kriterium aufgenommen 

• • Neuer Button "Studiengang" und "Ausgabe Fach/Studiengang", Funktionalität der Implementation von beliebigen Studiengangbäumen. Dokumentation für Entwickler/innen. 

• • Bericht "Berechnung Schwundfaktor" ermöglicht automatisch die Berücksichtigung der Regelstudienzeit des jew. Studiengangs 

• • Übernahme der Matrikelnummer und internen HZB-Art in die Hilfstabelle sos_stg_aggr . 

• • Verbesserte Ladegeschwindigkeit bei Prüfungsdaten 

• • Übernahme des Stichtags für die Semesterberichte des KENN-Moduls  

0.7rc1 (01/2010)

Der Patch korrigiert bzw erweitert das SOS-Modul wie folgt:

• • Vorbereitung Integration mit ZUL-Modul (zentrale Schlüsselverwaltung für SOS/POS/ZUL) 

• • Tabelle k_plz wird nicht mehr geladen. 

• • Hochschulzugangsberechtigung 'Studienkolleg' zählt nicht mehr bei Bildungsinländern, sondern bei Bildungsausländern 

• • Maske Prüfungsnoten nach Studiengängen/Fächern um Button Prüfungsstatus erweitert. 

• • Sicht Fächer und Studienbereiche: Bug in Zuordnungstabelle Studienbereiche zu Fachrichtungen der Gasthörerstatistik korrigiert. Excel hatte beim CSV-Export aus Zahlen mit führender 0 einen einstelligen Wert gemacht, z.B. bei Philosphie (04). So waren also die Schlüssel 0-9 falsch. 

• • Button Staatsangehörigkeit in allen Masken geändert: statt einfacher Liste drei Hierarchien:  

  • • Staaten nach Deutschland / Ausland 

  • • Staaten nach Kontinent 

  • • Staaten nach EU-Mitgliedschaft 

Achtung: vorhandene Lesezeichen im Ajax-Client müssen ggf. neu angelegt werden, wenn "Alle ohne Deutschland" gewählt wurde.

• • ETL-routine ist kompatibel mit Postgres 8.3 

• • Entladeroutine erweitert um Einzelprüfungen: 

• • Tabelle lab:  

  • • pversuch 

  • • ppruef1 

  • • ppruef2 

  • • malus 

  • • bonus 

  • • pordnr 

• • Tabelle sos:  

  • • sperrart1 

  • • sperrart2 

  • • staatkez 

• • Tabelle pord  

  • • Komplett 

• • Tabelle k_ppruef  

  • • Komplett 

• • Tabelle k_sperre  

  • • Komplett 

• • Tabelle k_modulart  

  • • Komplett 

• • Stichtagsart "im Prüfungszeitraum des Stg." im Button Stichtag entfernt 

• • Unnötige Warnungen im Prüfprotokoll entfernt  

  • • doppelter Schlüssel (hs=0 || key _ apnr):... 

  • • "fach_nr (stgnr) unbekannt, Prüfung wird gelöscht" wird nur noch bei Vor- oder Hauptprüfungen moniert, nicht bei Einzelprüfungen 

  • • Unnötige Warnungen "doppelter Schlüssel (hs== () || key || apnr): ..." entfernt. 

• • Möglichkeit der Transformation von Fachbereichsschlüsseln zu Kostenstellen 

   

   

0.6rc5 (02/2008)

Der Patch korrigiert bzw erweitert das SOS-Modul wie folgt:

• • Alle Masken wurden bzgl. Layout für das Kernmodul 3.5 überarbeitet, es wurden auch einige Tooltips eingefügt bzw. aktualisiert. 

• • Der Button "Fächer" in allen Masken bietet nun die Mehrfachauswahl . 

• • Button Köpfe oder Fälle in allen Masken um Zeile 1. Fach im n-ten Stdg. erweitert. 

• • Sortierung der Sichten im Button Fächer läßt sich vom Anwender festlegen, indem in der Sichtenverwaltung die Sortiernummer geändert wird. 

• • Korrektur der Durchschnittsberechnung bei Studiendauern und Prüfungsnoten  

• • Neues Pflegeformular für Stichtage einzelner Semester. Default-Stichtag für Prüfungen ist nicht mehr in der Mitte des Sem., sondern in der Mitte des Folgesemesters, d.h. 60 Tage nach Semesterende 

• • Automatischer Update der Hochschulnummer in der Tabelle hochschulinfo wurde entfernt. 

• • Bei den Tabellen k_stgext und k_abext wurden die Felder für Volltexte vergrößert . 

• • Wenn Schalter lehr_stg_ab_aus_SOS auf 1 gesetzt wird, werden alle Datensätze aus k_abstgv übernommen, nicht nur die mit ausgefüllter Lehreinheit 

• • Abfrage Studierende nach Fach und Wohnort so abgeändert, dass das Feld 'Wohnort in' kein Pflicht-Feld mehr ist. Und: Eine Gesamtsumme ist eingebaut. 

• • Inkompatibilität von Postgres 8.2 mit SuperX-Entladescript beseitigt. 

• • Neues Entladescript für SOSPOS-GX 9 oder 10. 

• • Verbesserung der Archivierung : Studierenden-Fälle, die sich in SOS zurückmelden und dann später wieder exmatrikulieren, werden in SOSPOS gelöscht, und in SuperX bisher nicht. 

• • Neue Konstanten zum "Tuning" der Transformation: 

  • • SOS_stg_deleted_update ermöglicht die Berechnung von Gültigkeiten bei eingeschalteter Archivierung und inkrementellem Laden aus SOS-GX 

  • • matrikelnr_min ermöglich, Nummernbereiche vom Laden in die Hilfstabellen auszuschließen 

  • • SOS_start_stg_aggr bietet die Möglichkeit, die Hilfstabelle Studierendenstatistik nur für neuere Semester neu zu berechnen 

  • • SOS_start_lab_aggr bietet das gleiche für die Prüfungsstatistik 

  • • Die Konstante 'lehr_stg_ab_aus_SOS' läßt sich nunmehr ausschließlich über das Browserformular Konstanten ändern, nicht mehr über einen Parameter '--mit-lehreinheiten' im sos_update.x Script. Dies ist wichtig für Anwender ohne direkten Serverzugriff, z.B. IREMO-Hochschulen in BaWue. 

• • Änderung der Berechnung von Absolventen nach Stichtag: 

  • • Der Stichtag für Prüfungen wird in die Mitte des Folgesemesters gelegt (statt bisher in die Mitte des Prüfungssemesters) 

  • • Prüfungen nach dem Stichtag werden dem Folgesemester zugerechnet, damit sie bei stichtagsbezogener Zählung nicht unter den Tisch fallen 

• • Button Hörerstatus in allen Masken um Status Haupthörer (HIS) erweitert (Status H in k_hrst.his_hrst), sowie um Ausprägungen Haupthörer (Amtl.),Nebenhörer/Zweithörer (Amtl.),Studienkollegiat (Amtl.) 

• • Status "nur Promotion" wird aus Maskenfeld "Status" entfernt, weil dies ohnehin keine Ergebnisse bringt. 

• • Aktualisierung der Gruppierung von Hochschulzugangsberechtigungen an das Schlüsselverzeichnis STBA 2007. Neue Gruppe "Fachgeb. HS-Reife". Die Termini "Bildungsausländer und Bildungsinländer wurden entfernt, weil diese in SuperX-KENN eine Untergruppe von ausl. Studierenden (Staatsangehörigkeit) sind. 

• • Namensänderung : der Themenbaum-Ast 'Studierende Administration' heißt jetzt 'Administration Studierende, Prüfungen', um die Sortierung im Themenbaum an die anderen Module anzugleichen. 

• • Abfrage Studierende nach Abschlüssen wurde an das an das neue Kernmodul 3.5 angepasst: 

  • • Besseres Layout der Buttons 

  • • Der Button "Aggregierung Fach" ist umbenannt nach "Studiengänge" und bietet die Optionen "anzeigen" und "ausblenden". 

  • • Der Button "Filter bis Ebene" ist neu. Sie können damit numerisch auf die Ausgabeebene filtern. 

  • • Beide Buttons sind unabhängig, d.h. Sie können die Studiengänge auch direkt unter den Lehreinheiten einblenden. 

  • • In der Ergebnistabelle gibt es entsprechend zwei Spalten für die Ebene statt eine: Die "Ebene" und die "Art der Ebene".  

  • • Im XML-Frontend ist die Ausgabe nach Ebenen formatiert (siehe Buttons Druckversion, PDF, Excel). Die Filtereinstellungen werden auch nach Excel und PDF übernommen. 

  • • Wenn das Ergebnis Ganzzahlig ist, werden in der Tabelle automatisch die Dezimalstellen entfernt. So sieht die PDF-Ausgabe bei großen Tabelle besser aus. 

• • Verbessertes Administrationshandbuch 

0.6rc5 (02/2007)

• • Erweitertes Entladescript : Auch Postleitzahlen werden entladen. 

• • Merkmal 1. Hochschulsemester wird nicht am Einschreibstatus erhoben, sondern an tatsächlicher Hochschul-Semesterzahl. 

• • Neues Entladescript für SOS Version 9.x 

• • Maske Alter der Studierenden unterscheidet nach feineren Altergruppen. Ausserdem Button Geschlecht hinzugefügt. 

• • Alle Masken haben nur Button zur Filterung auf Staatsangehörigkeit . Im Button Köpfe oder Fälle gibt es mehr Auswahlmöglichkeiten. 

• • Verbesserte Glossare (Spaltenerläuterungen). 

• • Neue Maske Studierende nach Fach/Hochschulsemestern . 

• • Korrektur der Archivierung unter Informix 

• • Unter Informix wurden u.U. keine Prüfungen nach amtl. Statistikdatum ausgewiesen. Dies wurde korrigiert. 

• • Neue Sichten Fächer nach Gasthörerstatistik und Fächer nach Lehr- und Forschungsbereich, alte Sicht Fächer und Studienbereiche wurde korrigiert. Die Zuordnung von Studienfächern zu Lehr- und FOrshcungsbereichen und Studienbereichen erfolgt über die Fachrichtung der Gasthörerstatistik (k_astfr in SOS) und muss dort gepflegt werden. 

• • Ungültige Studienfachschlüssel , die aus einem Leerzeichen bestehen, werden ausgefiltert. 

0.6rc4 (05/2006)

• • Bei den Studierendenabfragen wurde das Maskenlayout verbessert. 

• • Korrektur der Abfragen Prüfungen nach Fach und Abschluss (Zeitreihe) und Prüfungen nach Fachsemestern .  

• • Korrektur der Abfrage Studierende nach Hörerstatus : Button 'bis Fachsem.' wurde nicht ausgewertet..  

• • Prüfungsnoten mit Nachkommastellen .7 bis .9 wurden falsch gerundet  

• • Verbesserung der ETL-Routine bei eingeschalteter Archivierung 

• • Neuer Button auf allen Studierenden-Abfragen: Filter Studierende . Der Button kann flexibel von der Hochschule gefüllt werden. 

• • Verbesserte Dokumentation des Datenmodells, insbes. der Hilfstabellen und deren Fremdschlüssel 

• • Browserbasierte Bearbeitungsformulare für Konstanten, Hörerstati, Rückmeldestati, Semester und Filter sind direkt in der Maske Prüfprotokoll Studium verlinkt. 

0.6rc1 (06/2005)

• • Völlige Überarbeitung des Datenmodells; Stammdaten und Hilfstabellen haben neue Namen und sind jeweils erweitert um Zeitstempel für stichtagsbezogene Auswertungen. Parallelbetrieb vom SOS-Modul 0.5 und 0.6 ist aber möglich. 

• • Anpassung der Entladeschnittstelle an SOS 6.x und 7.x; neue Schnittstelle für Access / Informix Win NT; Möglichkeit des kompletten Entladens im Regelbetrieb (für Hochschulen mit physisch getrennten Hosts); Pseudoymisierung von Matrikelnummern 

• • Bis auf KFZ-Kennzeichen, Bundesland, Rückmeldestatus, Geschlecht und Nationalität werden alle Schlüssel im hochschulinternen Format übernommen; durch die Übernahme der kompletten Schlüsseltabellen aus HISSOS ist es möglich, sowohl hochschulinterne als auch amtliche Statistiken zu erstellen. Außerdem gehen hierarchische Bezüge, sofern in SOS vorhanden, nicht mehr verloren.
  Hier besonders wichtig: Übernahme der hochschulinternen Fächer- und Abschluss-Schlüssel statt der früher üblichen amtlichen Schlüssel. 

• • Tägliche Übernahme der neuen Schlüssel in der allgemeinen ETL-Routine. Umfassendes Entladen von Schlüsseltabellen im Regelbetrieb.    

• • Anpassung an SuperX Kernmodul 3.0 inkl. kompletter Überarbeitung der ETL-Routine -> Einheitlichkeit, Backup 

• • Verbesserte Prüfroutinen (Kontrollsummen aus SOSPOS und SuperX werden verglichen) 

• • Neue Felder bzw. Tabellen aus SOS werden übernommen 

  • • Tabelle sos (Studierende): Mehr Information über Hochschulszugangsberechtigung (z.B. Ort) und Ersthochschule, gewichtete Urlaubssemester. Hörerstati werden komplett aus SOS übernommen (nicht nur Haupt/Nebenhörer) 

  • • Tabelle stg (Fächer): Klinische Semester, Datum der Rückmeldung, Semestergewichtung, Kohortensemester 

  • • Tabelle lab (Prüfungen): Prüfungsart; aus lab können nun alle Prüfungen übernommen werden (Stichtwort Studienkonten), flexiblere Zuordnung von Prüfungsnummern im Entladescript
    Außerdem wird studiengang_nr und fach_nr übernommen, um im Prüfungsbereich Auswertungen nach Köpfe/Fälle zu ermöglichen.
    Außerdem werden auch nicht bestandene Prüfungen übernommen. 

• • Erweiterung der lehr_stg_ab um   einen eindeutigen Zähler ( tid ) und um das Feld stort (für Standort). Automatische Zuordnung neuer Studiengänge in lehr_stg_ab  

• • Verbessertes Installationsscript 

• • XML-Datenbankschema 

• • Vorbereitung für Erzeugung der lehr_stg_ab aus der Tabelle cob_stug (COB-Modul) 

• • Glossare und Erläuterungen 

• • Scripte zur Übernahme archivierter Sätze (Alpha-Status!)  

0.51 (06/2003)

• • Abfrage Studierende nach Abschlüssen  

• • Bugfixes beim Installer 

0.5 (08/2002)

• • Installationsscript für Informix 

• • Implementation von Stichtagsdaten (Exmatrikulation) 

• • Umstellung von numerischen Schlüsseln auf Character  

• • Zuordnung von Studiengängen zu Lehreinheiten (lehr_stg_ab) in allen Abfragen möglich 

SuperX Karlsruhe (1994-2001)

• • Abfragen im Bereich Studierende / Prüfungen 

• • Auswertungen für folgende Merkmale: 

  • • Fachsemesterzahl  

  • • Geschlecht 

  • • Alter 

  • • Hörerstatus  

  • • Semester (inkl. Zeitreihen) 

  • • Studiengang 

  • • Abschluss 

  • • Einschreibung Status (Neueinschreiber, Ersteinschreiber) 

  • • Regelstudienzeit 

  • • Herkunftsland 

  • • Hochschulzugangsberechtigung 

  • • Wohnort 

  • • Prüfungsnote 

  • • Fachstudiendauer