Wenn Sie die Installationsdatei heruntergeladen und entpackt haben, gehen Sie wie folgt vor:
cat $SUPERX_DIR/db/bin/SQL_ENV_costage.sam >>$SUPERX_DIR/db/bin/SQL_ENV
Danach laden Sie die SQL_ENV neu und starten die Installation:
. $SUPERX_DIR/db/bin/SQL_ENV cd $COSTAGE_PFAD module_install.x costage .
Wenn Sie die Installationsdatei heruntergeladen und entpackt haben, gehen Sie wie folgt vor:
. $SUPERX_DIR/db/bin/SQL_ENV cd $COSTAGE_PFAD/upgrade costage_upgrade.x
Zum Bereitstellen der Rohdaten aus CAMPUSonline gibt es zwei Wege:
Beide Wege werden im folgenden beschrieben. Vorab eine Bemerkung zu Schemata.
Unter Oracle ist der Name des Schema auch die Zugangskennung, es hängt also von der Zugangskennung ab, welche Views Sie sehen.
In der CAMPUSonline Datenbank unter Oracle gibt es verschiedene Schemata, die teilweise noch aus der Vergangenheit stammen. Hier eine Übersicht:
Kurz gesagt: Hochschulen mit SuperX sollten ab Version COSTAGE 0.6 das Schema unter 1. nutzen.
Wenn Sie aus CAMPUSonline entladen, müssen die Views der DWH-Schnittstelle nach CSV exportiert werden.
Auf der Seite
http://www.superx-projekt.de/doku/costage_modul/costage_unload.html
finden Sie die aktuellen Views in der Spalte "Kurztitel". Beachten Sie, dass alle Spalten in der von CAMPUSonline vorgesehenen Reihenfolge vorliegen.
Der CSV "Dialekt" muss wahrscheinlich an SuperX angepaßt werden. Dazu wird ein Script mitgeliefert, das
Das Script liegt im Verzeichnis $COSTAGE_LOAD_PFAD. Es geht davor aus dass die CSV-Dateien im Unterverzeichnis unl liegen. Der Aufruf lautet
costage_prepare_unlfiles.xHEADER "
Beispiel:
costage_prepare_unlfiles.x , HEADER
Damit werden CSV Daten mit "," getrennt und Spaltenüberschriften eingelesen. Danach werden sie im UNL-Format mit den richtigen Dateinamen für SuperX gespeichert.
Wenn Sie neben der Umformatierung auch Transformationen benötigen, wird auch ein Script mitgeliefert
rohdaten/csv_unloads2unl.sql
Sie können das Script anpassen an Ihre CSVs und dann mit DOSQL ausführen.
Beim Entladen aus CAMPUSonline (CO) wird ist der Entladeparameter DATABASE ohne Belang, denn das DMBS in CO ist in der Regel Oracle. Daher müssen Sie dem Tomcat-Server in .../webapps/superx/WEB-INF/lib den JDBC-Treiber von Oracle (Dateiname z.B. ojdbc6.jar) mitgeben.
Die Konfiguration wird in den Dateien
rohdaten/COSTAGE_ENV rohdaten/db-co.properties
vorgenommen, für beide Dateien gibt es Musterdateien mit der Endung ".sam".
Bis Version 0.5: Mit der Variablen
connectionName=CO_INTERFACE_PX_SUPERX
definieren Sie das gewählte Schema.
Ab Version 0.6 hat die Variable den Wert
connectionName=CO_INTERFACE_PUBLIC_EXTERNAL
Details zur Konfiguration finden Sie im Kernmodul-Handbuch.
Das Entladen starten Sie mit
costage_unload.x
Logmeldungen finden Sie in der Datei
costage_unload.err
Nur für den Unload aus CO per JDBC: In der Datei $COSTAGE_LOAD_PFAD/COSTAGE_ENV können Sie folgende Variablen nutzen:
| Parametername | Beschreibung | Defaultwert | Wertebereich | ab Version | Parametergruppe | Priorität | Vorsystem | Komponente | |
|---|---|---|---|---|---|---|---|---|---|
VERSION | Version des Vorsystems. Wird derzeit nicht ausgewertet. | 2 | 2 | Systemparameter | style="text-align:right;" | 0 | CO-Basisdaten | |||
COSTAGE_start_st_sem | Startsemester Studierende Ab welchem Semester sollen Studierende entladen werden? z.B. 20011 für SS 2001 | 19911 | SEMESTER | 0.3 | Systemparameter | 1 | 0 | CO-Basisdaten | |
COSTAGE_start_leistungen_sem | Startsemester Prüfungen Ab welchem Semester sollen Prüfungen entladen werden? z.B. 20021 für SS 2002 | 19911 | SEMESTER | 0.3 | Systemparameter | 1 | 0 | CO-Basisdaten | |
COSTAGE_start_bw_sem | Startsemester Bewerbungen Ab welchem Semester sollen Bewerbungen entladen werden? z.B. 20021 für SS 2002 | 19911 | SEMESTER | 0.3 | Systemparameter | 1 | 0 | CO-Basisdaten | - |
Für das Entladen der CO-Basisdaten für die Studierenden Komponente können Sie über den neuen Entladeparameter EXTERNAL_SUBJECTS steuern, ob externe Fächer ins Studierenden Modul zu übergeben sind oder nicht.
Externe Fächer sind Teilstudiengänge, die nicht an der eigenen Hochschule studiert werden. Standardmäßig sollten diese nicht in der Statistik der jew. Hochschule auftauchen, es gibt aber Anwendungsfälle wo dies von Interesse sein könnte.
Außerdem können sie die Anzahl der zu entladenen Semester steuern mit den Entladeparametern
Hier ein Screenshot:
Es werden alle Semester seit 19911 (SoSe 1991) geladen.
Der Parameter EXTERNAL_SUBJECTS wird auch im Bewerbungsmodul ausgewertet. Weitere Parameter gibt es derzeit nicht.
Mit der Konstante "COSTAGE_TSG_GENERATE" können Sie geschlossene Teilstudiengänge für einzelne Semester generieren und den Status aus dem MSG übernehmen. Dies betrifft wahrscheinlich nur Hochschulen in Deutschland, die in CO sog. "Mehrfachstudiengänge" (MSG) nutzen, z.B. im Lehramt. Wir wollen das an einem Beispiel illustrieren. Wenn ein/e Studierende/r z.B. Lehramt Sonderpädagogik mit 5 Fächern studiert:
Dabei werden die einzelnen Teilstudiengänge (TSG) ggf. zu unterschiedlichen Semestern beendet. Am längsten läuft der TSG, in dem dann auch die Abschlussarbeit geschrieben wird. Hier ein Screenshot:
Die rot umrandeten Zellen sind Semester, in denen in CO kein Datensatz mehr vorhanden ist. Nehmen wir das WiSe 2022/2023: Nur im rechten Fach "Bildungswissenschaft" sowie "Ästhetische Erziehung" (jeweils grün umrandet) zählt das Semester bzw. Fachsemester noch hoch. Wenn wir die Datensätze für eine Fallstatistik zählen würden, dann wären die Studierenden in den rot umrandeten Semester gar nicht mehr vorhanden, obwohl die Studierenden im MSG noch eingeschrieben sind.
Für Statistiken auf Fallebene wäre es aber korrekter, wenn die Studierenden im rot umrandeten Semester mit dem jeweiligen Status des MSG und dem letzten Fachsemester des TSG gezählt würden. Um dies zu erreichen, kann SuperX die rot umrandeten Datensätze künstlich generieren. Im Datenblatt wären solche Datensätze auch als "Automatisch generiert" erkennbar. Hier ein Screenshot aus SuperX, wenn die Konstante "COSTAGE_TSG_GENERATE"=1 gesetzt ist:
Es gibt neben dem Rückmeldestatus (amtlich)=3 (-> Rückgemeldet) auch einen Studienstatus im TSG, der separat betrachtet werden kann.
In CampusOnline werden Studiengänge und deren Bewegungsdaten zu einem "UNIKEY" zugeordnet. Dies ist in der Regel der amtliche Schlüssel einer anderen Hochschule, wo z.B. Studierende in mehreren Fächern parallel studieren. Bei Hochschulen mit Standorten ist hier der amtliche Schlüssel des jew. Standortes hinterlegt.
In den Auswertungen des COSTAGE-Moduls sind die jeweiligen Einschränkungen über das Maskenfeld "Hochschule/Standort" auswählbar. Um die Daten externer Fächer bzw. von Standorten ins Studierenden-Modul zu laden müssen Sie dies explizit erlauben, indem Sie die Konstante "SOS_CO_allow_external" auf 1 (=ja) setzen.
Es werden folgende Repository-Variablen vorgegeben:
Im folgenden eine Erläuterung.
Am Anfang der Inbetriebnahme ist es nützlich, auf einzelne Studierenden/Gruppen einzuschränken. Sie müssen dabei Matrikelnummern oder andere Personmerkmale mit dem Alias "S." für die Tabelle Studierendenstammdaten verwenden. Beispiele für COSTAGE_STUDENT_FILTER:
S.matrikelnummer in ('1234567','7654321')
S.personentyp_kb != "TEST'
Die Voreinstellung ist "1=1", d.h. kein Filter.
Die Variable COSTAGE_STORT enthält bei Hochschulen mit Standorten den jew. Namen und den amtlichen Schlüssel des Standorts. Beispiel Hochschule Esslingen:
Hochschulen ohne Standort lassen die Variable leer.
Die Variable COSTAGE_LEISTUNGSSTATUS_MAP erlaubt es, eine für deutsche Hochschulen sinnvolle Gruppierung von Leistungs-Stati zu erstellen. Nach einer Formel, die uns von der TU Graz mitgeteilt wurde, werden bestandene bzw. nicht bestandene Leistungen identifiziert. Die Hochschulen müssen diese Variable in der Regel nicht anpassen.
Wenn die Rohdaten im Ordner
$SUPERX_DIR/db/module/costage/rohdaten/unl/
vorhanden sind, können Sie den Konnektor starten mit
cd $SUPERX_DIR/db/module/costage/ module_etl.x costage .
Die Logausgabe ist Superx-typisch in mehrere Abschnitte eingeteilt, Details siehe Kernmodul-Handbuch.
Wenn Studierende pro Semester mehrere Studiengänge belegen, werden diese in Deutschland in der amtl. Statistik in Studiengangnummern und Fachnummern sortiert. CampusOnline kennt die Fachnummern, aber keine Studiengangnummern. Daher müssen letztere ermittelt werden.
Für die Ermittlung des ersten Studiengangs wird das sog. "Primärflag" ausgewertet (im DWH-View der View px_st_studien_v.hauptstudium_flag). Wenn es weitere Studiengänge gibt, werden diese nach Studienidentifikator aufsteigend sortiert. Dabei muss man die Studiumstypen unterscheiden. In CampusOnline gibt es drei Studiumstypen:
Bei Einfachstudiengängen ist die Ermittlung der wie ein normales Studium modelliert, zusätzlich gibt es eine Zuordnung zu einem Mehrfachstudiengang (MSG). Außerdem kann ein TSG ein "Primärflag" haben, das das 1. Fach im 1. Studiengang (nach deutscher Studierendenstatistik) kennzeichnet.
In COStage werden die Studiengangnr. und Fachnr. ermittelt und ausgegeben. Im folgenden ein Beispiel:
CampusOnline führt 3 Studiengänge auf, wobei die Studiengänge 2 und 3 das gleiche Abschlussziel, aber unterschiedliche Teilstudiengänge haben.
In COStage werden die 3 Studiengänge aufsteigend nach Primärflag und Identifikator sortiert. Bitte beachten Sie dass ein TSG, der in mehreren MSG zugeordnet ist, in COStage nur 1x gezählt wird.
Hier noch ein komplizierteres Beispiel: es gibt 2 MSG mit gleichem Abschlussziel, und einer davon hat das Primärflag:
In COStage wird der MSG mit dem Primärflag mit höherer Priorität genutzt. Daher landet "Bildungswissenschaft" im 1. MSG.
Der Studienstatustyp definiert, ob eine Belegung in SuperX statistisch gezählt wird oder nicht. Dazu werden die Statustypen in CampusOnline zu dem amtlichen Rückmeldestatus in der BRD zugeordnet:
| STUDIEN-STATUSTYP | STUDIENSTATUSTYP (Bedeutung) | Status amtlich | Kommentar |
|---|---|---|---|
E | Ersteinschreibung | 1 | |
B | Neueinschreibung | 2 | |
I | gemeldet | 3 | |
U | beurlaubt | 4 | |
V | Verzicht auf Studienplatz | Wird nicht gezählt | |
R | Rücktritt von der Immatrikulation | 5 | |
X | geschlossen (Abschluss und/oder keine Fortsetzung möglich) | 5 | |
Z | geschlossen | 5 | |
a | Studienplatz angenommen | Wird nicht gezählt | |
o | Studium offen (noch keine Weitermeldung erfolgt) | Wird nicht gezählt | |
z | wieder einzuschreiben | Wird nicht gezählt |
Pro Semester können in CAMPUSonline bis zu drei Studienstatuseinträge vorhanden sein
(Beispiel: "a >> E >> X" = Studienplatzannahme, Ersteinschreibung und Schließung). Eine Schließung setzt eine Ersteinschreibung, Neueinschreibung, Weitermeldung oder Beurlaubung im gleichen Semester voraus.
Fall 1: ein Statuseintrag im Semester (Beispiele "I", "U")
Es gilt der jeweilige Statuseintrag.
Fall 2: zwei oder drei Statuseinträge im Semester (Beispiele "a >> B", "I >> X", "a >> B >> X")
Wesentlich für die Auswertung ist das Datum "Gültig ab" des letzten Statuseintrags im jeweiligen Semester. Hierbei unterscheiden wir zwischen Semesterbeginn und Semesterende im Sommer- oder Wintersemester.
Prüfung des letzten Statuseintrags im Semester:
Die Daten für Semesterbeginn und Semesterende können der oberen Grafik für Sommer- und Wintersemester entnommen werden.
Geschlossene Teilstudiengänge TSG werden seitens CAMPUSonline nicht geliefert. Diese müssen in SuperX erzeugt werden, solange der zugehörige Mehrfachstudiengang (MSG) aktiv ist. In SuperX sind diese gekennzeichnet als „Automatisch generierter Datensatz - tsg_generated“.
Geschlossene TSG können folgende Status aufweisen:
Der in SuperX „Automatisch generierter Datensatz - tsg_generated“ übernimmt den letzten übermittelten Status eines TSG aus CAMPUSonline.
Zusätzlich wird die „Art/der Grund der Abmeldung“ übernommen:
Sie können mit den SuperX-Modulen
die aus CampusOnline erstellte amtliche Studierendenstatistik in SuperX hochladen und dann mit dem Tabellen-Abgleich im QA-Modul die Studierenden abgleichen. Eine Dokumentation finden Sie im Handbuch Qualitätssicherung.
Wenn die Daten in COSTAGE geladen sind, können sie als Datenquelle für das Studierenden Modul in SuperX genutzt werden. Dazu gehen Sie wie folgt vor:
Setzen Sie in Ihrer SQL_ENV den Wert von SOS_LOAD_PFAD auf COSTAGE:
SOS_LOAD_PFAD=$COSTAGE_PFAD/rohdaten_sos export SOS_LOAD_PFAD
Im Unterverzeichnis "costage/rohdaten_sos" führen Sie dann das Entladescript
sos_costage_unload.x
aus.
Es werden Rohdaten im Unterordner "unl" erzeugt. Diese dienen als Datenquelle für das Studierenden Modul:
cd $SOS_PFAD sos_update.x
Wenn die Daten in COSTAGE geladen sind, können sie als Datenquelle für das Bewerbungs-Modul in SuperX genutzt werden. Dazu gehen Sie wie folgt vor:
Setzen Sie in Ihrer SQL_ENV den Wert von ZUL_LOAD_PFAD auf COSTAGE:
ZUL_LOAD_PFAD=$COSTAGE_PFAD/rohdaten_zul export ZUL_LOAD_PFAD
Im Unterverzeichnis "costage/rohdaten_zul" führen Sie dann das Entladescript
zul_costage_unload.x
aus.
Es werden Rohdaten im Unterordner "unl" erzeugt. Diese dienen als Datenquelle für das Bewerbungs-Modul:
cd $ZUL_PFAD zul_update.x