Konfiguration Studierende, Pruefungen

Konfigurationshandbuch Studierende, Prüfungen

Das SOS-Modul besteht im Endzustand aus Tabellen, Prozeduren und Abfragen. Da die SOS-Datenbank der HIS eG 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 Infosystem. 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

Einführung

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.

Installation des SOS-Moduls

Die Installation des SOS-Moduls unterscheidet sich zwischen HISinOne und SuperX. Daher gibt es zu jedem System eine eigene Installationsseite:

Hinweis: Zum Upgrade auf HISinOne-BI 2018.12 bzw. SuperX-Studierende 1.1: Falls Sie den Entladeparameter "STUDENT_FILTER" bei Datenquelle sospos genutzt haben, müssen Sie den Inhalt nach "STUDENT_SOSPOS_FILTER" verschieben.

Konventionen und Schnittstellenspezifikation

Das SOS-Modul von Infosystem 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 Infosystem führen.

Stammdaten Studierende

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

Geschlecht
KFZ-Kennzeichen Heimat-/Semesterwohnsitz / Hochschulzugangsberechtigung
Geburtsdatum
Nationalität

Bei Fachbelegungen müssen mindestens folgende Daten gepflegt sein:

MatrikelNr.
Fachkennzeichen
StudiengangsNr. / FachNr.
Rückmeldestatus
Abschluss
Studienfach
Fachsemesterzahl
Enddatum bei Exmatrikulation in dem jeweiligen Studiengang

Darüberhinaus gilt, dass eine Belegung pro Semester mit gleicher FachNr. und gleicher StudiengangNr. 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:

MatrikelNr.
Fach
Abschluss
Semester der Prüfung
Prüfungsnummer

Infosystem 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 wird das Semester der Prüfung entsprechend überschrieben. Bei der "semesterbezogenen Zählung" (Schaltfläche 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 Studiengangs- und Fachnummer 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. Infosystem 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 Infosystem das letzte Semester, in dem der Studierende in dem Fach eingeschrieben war, und übernimmt die Fachsemesterzahl für die Prüfung.

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

Schlüssel

Viele Schlüsseltabellen aus SOS werden von Infosystem ü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. Infosystem stellt 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 denn sie wird in Infosystem gepflegt.

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

Für die Infosystem-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 jeweils nur der erste Zeitraum des Studiengangs pro Semester für den Stichtagsbezug genutzt. Der erste Zeitraum definiert sich durch das Minimum des Anfangsdatums.

Entladen aus dem Vorsystem

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

Allgemeines

Beim Entladen der Studierenden- und Prüfungsdaten werden Datentabellen und Schlüsseltabellen entladen, um sie ins Infosystem 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 das Infosystem relevanten 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 Infosystem-Rechner entweder direkt auf die SOS-Datenbank zugreift, oder zumindest das Entladeverzeichnis des SOS-Rechners auf dem Infosystem-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:

Beim Vorsystem HISSOS wird eine Tabelle "mtknr_ldsg" (steht für "Matrikelnr. nach Landesdatenschutzgesetz") erzeugt, in der die tatsächlichen Matrikelnummern zu einer arbiträren Laufnummer dauerhaft zugeordnet werden, und beim Entladen nur die arbiträre Laufnummer nach Infosystem übernommen wird.
Beim Vorsystem HISinOne wird nicht die Matrikelnr. entladen, sondern die ID des Studierenden. Auch dies ist eine arbitäre Laufnummer.

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

Beim "Pull"-Verfahren wird einer Benutzerkennung auf dem Infosystem-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 Infosystem-Rechner kopiert werden. Dieses Verfahren klappt bei Informix unter Unix problemlos, bei Entladen aus Postgres müsste das komplette Infosystem-Kernmodul installiert werden. Weitere Informationen zum Einrichten des "Push"-Verfahren - Einrichten von Entladroutinen-HISinOne-BI

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.

Entladen in der Bash

In HISinOne werden die Komponenten üblicherweise im Browser entladen und aktualisiert. Wenn dies via Bash stattfinden soll (wegen Cronjob- oder anderen scriptgesteuerten Möglichkeiten), müssen Sie zunächst einige Punkte einrichten:

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

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 unerheblich, ob Sie SOS unter Informix für Win., Informix für Unix oder Postgres einsetzen; außerdem müssen 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 in SOS_ENV und tragen Sie die richtigen Umgebungsvariablen ein, z.B. den Pfad für $INFORMIXDIR sowie das Semester, ab dem Sie entladen wollen (start_stud_sem bzw. start_pruef_sem).

SOS_ENV Die Umgebung für Entladescripte aus SOS (Auszug)

##Pfad für Entladedaten:
SOS_PFAD=.	; export SOS_PFAD  
##hier muss Unterverzeichnis unl existieren!

#ab hier werden Daten ausgewertet:
start_stud_sem = 19881 #sos-studenten und fächer
start_pruef_sem = 19921 #Prüfungen     
SOS_UNL_COMPLETE=true 
export SOS_UNL_COMPLETE

Am besten nutzen Sie für den Testbetrieb nur ein paar Semester, denn wenn Sie weiter in die Vergangenheit zurückgehen, laufen die Scripte recht lange. InSOS_ENV müssen folgende Umgebungsvariablen gesetzt werden (Defaultwerte sind bereits vorbelegt, aber an einigen Stellen werden Sie Änderungen vornehmen müssen):

Nur für Informix gelten:

INFORMIXDIR: Home-Verzeichnis von Informix
INFORMIXSERVER: Name des Informixservers
ONCONFIG: Name der onconfig, wenn auf dem SOS-Rechner mehrere Informix-Instanzen laufen
CLIENT_LOCALE: Sprachumgebung (wichtig fürs Entladen von Datumsformaten)
SERVER_LOCALE: dito

Nur für Postgres gelten:

PGDATESTYLE: Datumsformat "German"
PGPORT: Port vom Postgres-Server, standardmäßig 5432
PGHOST: Hostname oder IP-Adresse vom Postgres-Server
PGUSER: Benutzerkennung für Postgres-Server (nur Datenbank, nicht Betriebssystem)
PGPATH: Installationsverzeichnis von Postgres, z.B. /usr/local/pgsql
DB_PROPERTIES: Pfad zur db-sos.properties-Datei mit den Zugangsparametern für SOSPOS unter Postgres
LOGGING_PROPERTIES: Pfad zur Steuerungsdatei mit den Parametern für das Logging beim Entladen, voreingestellt auf ./logging.properties. Normalerweise müssen Sie hier nichts ändern- wenn beim Entladen Probleme auftauchen, kann man den Level von SEVERE auf INFO oder FINEST ändern, dann werden die konkreten SQLs geloggt. Beachten Sie jedoch: Wenn keine Fehler mehr auftreten, müssen Sie den Level wieder auf SERVERE ändern, sonst kommen Schlüsselworte in die Logdatei sos_unload.err, die dann bei der Übernahme nach SuperX fälschlicherweise zu Fehlermeldungen führen.

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.

Für alle Platformen gelten folgende Variablen:

SX_CLIENT: Entladeprogramm für SOSPOS-DB: dbaccess, psql oder jdbc #unix
ERRORMAIL: An wen solle eine Logmail verschickt werden, wenn das Entladen nicht geklappt hat? (nur Unix).
LOGMAIL: An wen soll immer eine Logmail verschickt werden
MAILPROG: Pfad zum ausführbaren Mailprogramm unter Unix, Vorbelegung ist "mail", manche Unixe haben aber auch "mutt".

Wenn die Rohdaten nach dem Entladen vom SOS-Rechner auf den SuperX-Rechner kopiert werden sollen, dann werden für das Script sos_copy.x folgende Umgebungsvariablen benötigt:

COPY_METHOD: Programm, das die Dateien kopiert; rsync und scp sind wählbar.
REMOTE_DIR: Verzeichnis, in das die Rohdaten auf dem SuperX-Rechner kopiert werden sollen, in der Regel ist dies /home/superx/db/module/sos/rohdaten
REMOTE_USER: Der Unix-Username auf dem SuperX-Rechner, in der Regel superx.
REMOTE_HOST: Der Rechnername bzw. die IP-Nr. des SuperX-Rechners.

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:

Manuelles Anlegen der Pseudonymisierungstabelle

  create table mtknr_ldsg
(
mtknr integer,
mtknr_ldsg serial
);
create unique index i_mtknr_1 on mtknr_ldsg (mtknr);

Wenn "SOS_UNL_COMPLETE=false" gesetzt ist, dann muss darüber hinaus 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 erforderlich, dass das Rohdaten-Verzeichnis auf dem SuperX-Rechner gemounted ist bzw. die Datei superx.datum nach dem Update auf SuperX-Seite regelmäßig rückgeschrieben wird: Falls das Update auf SuperX-Seite mit Fehler beendet wurde, 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 Prozes ist besonders in der Installationsphase recht fehleranfällig, 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. Nach dessen Durchlauf finden Sie die Dateien im unl-Verzeichnis. Prüfen Sie dann, ob dort Dateien mit 0 Bytes stehen. Der Name der Logdatei ist sos_unload.err. Wenn Sie das Verzeichnis nicht gemounted haben, müssen das Verzeichnis unl, die sos_unload.err und die superx.datum dann in das Verzeichnis $SOS_LOAD_PFAD auf dem SuperX-Rechner kopiert werden, ein Script dafür liegt ebenfalls bei (sos_copy.x)1. Das Entladedatum wird danach in der Textdatei $SOS_LOAD_PFAD/superx.datum gespeichert; wenn das Script einen Fehler findet, dann wird das vorherige Datum (in der Datei superx.datum.alt) gesetzt.

Datenbank-Schema

In den meisten Fällen haben die Datenbank und der User den gleichen Namen, wie z.B. hisinone. In diesem Fall greift der default, dass das Schema von einem User den eigenen Namen und public zugeteilt wird. Wenn jedoch die Datenbank einen anderen Namen erhält wie z.B. hisinone_prod oder hisinone_cust muss dieses Schema der Kennung, bzw. der Verbindung zu der Datenbank mitgegeben werden. Ansonsten erhält man Fehlermeldungen wie "relation course_of_study wurde nicht gefunden". Bei SX_CLIENT=psql muss dann in der SOS_ENV der Parameter export JDBC_PARAM="set search_path to hisinone;" oder bei SX_CLIENT=jdbc in der sos_pg.properties bei der connectionURL currentSchema=hisinone ergänzt werden (im ganzen dann z.B. connectionURL=jdbc\:postgresql\://localhost/hisinone?currentSchema=hisinone

Entladeparameter

Eine Übersicht über die Entladeparameter finden Sie hier: Entladeparameter Studierende / Prüfungen

Details zu einzelnen Parametern

SOS_UNL_COMPLETE: Sollen soll immer alles entladen werden (true). False bedeutet, dass nur die jeweils am Vortag geänderten Sätze entladen werden (inkrementelles Entladen). Dieser Schalter ist wichtig für die Übernahme: In SOS archivierte Sätze bleiben in Infosystem erhalten, wenn inkrementell entladen wird. Wenn immer aus SOS komplett entladen wird, und die Archivierung in Infosystem-SOS nicht aktiviert ist, dann werden alle Datenbestände im Infosystem ausgetauscht, d.h in SOS gelöschte oder archivierte Sätze werden auch in Infosystem gelöscht. Generell ist es sicherer, immer komplett zu entladen. Das Update auf Infosystem-Seite dauert allerdings dann auch länger.

TRANSACTION_OFF: Nur für Informix und bei Entladen mit "SOS_UNL_COMPLETE=false": Wenn Transaktionen eingeschaltet sind und die Protokoll-Tabellen groß sind, dann sollte dieses wie folgt belegt sein.TRANSACTION_OFF="SET ISOLATION TO DIRTY READ;"

POS_PNR: Nur bei Datenquelle SOSPOS: Welche Prüfungsnummern außer denen die in der Tabelle hskonst in SOS für Hauptdiplom, Vordiplom und sonstige Prüfungsnummern verzeichnet sind, sollen ebenfalls entladen werden? Setzen Sie hier eine "0", dann werden alle Prüfungen entladen (Vorsicht: viele Daten!). Sie können auch weitere PNRs als Vor- oder Hauptprüfung [#Pruefungsnummern deklarieren].Ein Beispiel für weitere Prüfungen wäre z.B.:POS_PNR='9390,9490,9690,9700'

STUDENT_FILTER: Zusätzlicher Filter für Studierende (SQL-where-Bedingung für Tabelle student in HISinOne-STU bzw. für Tabelle person von HISinOne). Standardmäßig wird hier nicht gefiltert ("and 1=1"). Sie können diesen Filter erweitern, um z.B. Teststudenten zu entfernen (Achtung: SQL-Syntax beachten). Wenn Sie sich auf die Tabelle student in HISinOne-STU beziehen, müssen Sie den Alias "S" benutzen. Beispiel:

 and S.registrationnumber NOT IN (123,456,789)

Dieser Filter sorgt dafür, dass die Studierenden mit den Matrikelnummern 123, 456 und 789 nicht geladen werden.

Eine weitere, häufiger genutzte Variante zur Filterung von Teststudierenden besteht z.B. darin, in HISinOne-STU ein Personenattribut mit dem Namen Teststudierende oder ähnlich anzulegen und allen Teststudierenden dieses Personenattribut zuzuweisen. Sie müssen im Anschluss die ID des Attributes aus der Datenbanktabelle personattribute heraussuchen. Der Parameter STUDENT_FILTER ist dann wie folgt zu ergänzen - "P" ist hier der Alias für die Tabelle person:

 and P.id not in (select person_id from personattribute where personattributetype_id=<<gewünschte ID>>)

STUDENT_SOSPOS_FILTER

Zusätzlicher Filter für Studierende (SQL-where Bedingung bei Tabelle sos in sospos). Standardmäßig wird hier nicht gefiltert ("and 1=1"). Sie können diesen Filter erweitern, um z.B. Teststudenten zu entfernen (Achtung: SQL-Syntax beachten). Wenn Sie sich auf die Tabelle sos in sospos beziehen, müssen Sie den Alias "S" benutzen. Beispiel:

  AND S.MTKNR > 300000 AND S.MTKNR < 900000

Dieser Filter sorgt dafür, dass nur Studierende zwischen den Matrikelnummern 300001 und 899999 geladen werden.

LAB_FILTER: Nur bei Datenquelle SOSPOS: Zusätzliche Filter für Einzelprüfungen (SQL-where Bedingung). Standardmäßig werden anerkannte Prüfungen gefiltert mit dem Ausdruck:AND (lab.panerk is null or lab.panerk != 'J')Sie können diesen Filter erweitern oder entfernen (Achtung: SQL-Syntax beachten).

Entladen aus SOSPOS mit eingeschränkten Datenbankrechten

Wenn Sie die Datenbank-Rechte beim Entladen aus dem Vorsystem sospos so ändern wollen, sodass der Datenbank-User nur für ausgewählte Tabellen Leserechte besitzt, dann müssen Sie folgende Tabellen mit Leserechten 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>>

Prüfungsdaten aus EXA und SOSPOS kombiniert laden

Es gibt zwei Unterladeroutinen, die jeweils aus EXA oder POS laden können. So kann z.B. das gängige Szenario abgebildet werden, dass Prüfungen von neuen Prüfungsordnungen oder aus einigen Fachbereichen aus EXA kommen und alle weiteren Prüfungen aus POS.

Beachten Sie bitte dafür folgende Vorannahmen:

Die Unterladeroutinen setzen voraus, dass jeweils HISinOne und SOSPOS in der databases.xml eingerichtet und aktiv sind.
Es werden immer alle gefundenen Prüfungen gem. Konfigurationen der Hauptladeroutine (Startsemester etc) geladen. Über den Entladeparameter LAB_FILTER können z.B. Prüfungen aus der Übertragung von POS in die BI ausgeschlossen werden, wenn diese bereits in EXA verwaltet werden.
Einige Entladeparameter funktionieren Vorsystem-spezifisch und sind entsprechend separat zu pflegen, z.B.:
- HISinOne-STU: STUDENT_FILTER
- SOSPOS: STUDENT_SOSPOS_FILTER
Beim Laden werden alle Prüfungen abhängig vom jew. Vorsystem ausgetauscht. Es es ist also möglich, dass ein/-e Student/-in einige Prüfungen in POS hat und einige in EXA.
Die Unterladeroutine besteht aus drei Teilen, die zwingend hintereinander ausgeführt werden müssen. Nur in Teil 1 (Entladen aus Vorsystem) unterscheiden sie sich.
Häufigstes Szenario:
- Ihre Hochschule ist mit STU bereits produktiv, dann nutzen Sie die Hauptladeroutine Studierende, Prüfungen mit Vorsystem HISinOne.
- Dann werden die schon in EXA vorliegenden Prüfungen automatisch über die Hauptladeroutine übertragen und zusätzlich müssen die Unterladeroutinen mit Datenquelle SOSPOS ausgeführt werden, um die Prüfungen aus POS zu übertragen.
Alternativ, wenn Sie EXA vor STU einführen:
- Dann nutzen Sie die Hauptladeroutine Studierende, Prüfungen mit Vorsystem SOSPOS. Dabei werden die Prüfungen aus POS automatisch übertragen, zusätzlich benötigen Sie noch die Unterladeroutinen mit der Datenquelle EXA (HISinOne), um die Prüfungen zu übertragen, die schon in EXA verwaltet werden.
Vor dem Lauf der Unterladeroutinen muss die Hauptladeroutine laufen. Die Semester, die bei Prüfungen entladen werden, müssen auch eine Entsprechung in den Studierendendaten der Hauptladeroutine haben.

Stellen Sie sicher, dass im Vorsystem der Hauptladeroutine alle Semester vorhanden sind, andernfalls treten beim Ausführen der Unterladeroutine für Prüfungsdaten aus andren Systemen Probleme auf.

Konfiguration und Start

Konfigurieren Sie in der databases.xml die dbconnections sospos und hisinone.
Klicken Sie auf {{#navigation:connectorStartNeu_standardReportsHisinone_administrate_bia}},
Starten Sie die Hauptladeroutine Studierende, Prüfungen.
Hierbei wird das im Entladeparameter SOURCESYSTEM eingetragene Quellsystem (z.B. hisinone) verwendet.
Starten Sie anschließend die Unterladeroutinen:
1. Lade Prüfungen Teil 1 Datenquelle sospos.
  (bei Aufruf über Quartz-Job oder Shell-Skript/Cron-Job: ... de.his.edustore.modules.WebFrontendForModuleUpdate sos:trans_pruefungen_1_sospos usw.)
2. Danach Lade Prüfungen Teil 2 Datenquelle HISinOne oder sospos
3. Abschließend Lade Prüfungen Teil 3 Datenquelle HISinOne oder sospos.

Vermeidung von Duplikaten

Beim kombinierten Laden von Prüfungen aus EXA und POS kann es zu Duplikaten in der BI kommen, wenn Prüfungen von POS nach EXA migriert wurden oder umgekehrt (der Normalfall bei der STU-Einführung!). Die Einzelprüfungen liegen aber noch in POS vor. Wenn sichergestellt ist, dass alle Hauptprüfungen von POS nach EXA migriert werden, können Sie den Entladeparameter LAB_FILTER auf "and pnr != 9000" setzen (wenn die 9000 bei Ihnen in POS für Hauptprüfungen steht, andernfalls müssen Sie einen anderen Eintrag nutzen). Damit werden generell die Hauptprüfungen aus POS nicht in die BI übertragen, unabhängig davon, ob die Hauptladeroutine ausgeführt wird oder die Unterladeroutinen zur Übertragung von Prüfungsdaten aus SOSPOS.

Statt Pseudonymen echte Matrikelnummern nutzen

Wenn Sie in Zukunft BI nutzen und daher die amtliche Studierendenstatistik aus BI liefern, benötigen Sie die echten Matrikelnummern. Wenn Sie bisher nur Pseudonyme hatten, gehen Sie wie folgt vor:

Machen Sie die sospos-Tabelle mtknr_ldsg in der SuperX/Eduetl-DB verfügbar, indem Sie
- (Besser, da wir auch schreibend darauf zugreifen:) unter Postgres die DBLINK-Funktion nutzen
- die Tabelle kopieren
Machen Sie eine Sicherung der SuperX/Eduetl-DB
- Unter BI: Speichern Sie das folgende Script in der Datei .../webapps/superx/WEB-INF/conf/edustore/db/module/sos/conf/customize.sql (Achtung: wenn sie bereits existiert, erweitern Sie die Datei lediglich am Ende). Danach machen Sie einen Upgrade der Studierenden-Komponente
- Unter SuperX: Führen Sie folgendes Script mit DOSQL aus

--Vorbedingung: 
--1. Tabelle mtknr_ldsg ist verlinkt aus sospos
--2. Sie enthält ausschließlich Pseudonyme
--3. Es gibt genug Plattenplatz für *_backup-Tabellen
 --Diese Datei muss in webapps/superx/WEB-INF/conf/edustore/db/module/sos/conf gespeichert werden, bzw.
--wenn die Datei schon existiert, müssen diese Zeilen hinzugefügt werden:
--Danach wird der Komponentenupgrade Studierende ausgeführt, und, bei Erfolg,
--wird die Tabelle mtknr_ldsg direkt ent-peudonymisiert
--Danach kann das Script wieder entfernt werden.
--Ggf. noch die *_backup-Tabellen droppen
--mit drop schema tmp_backup_mtknr;
<#include "SQL_lingua_franca"/>
<#include "SuperX_general"/>
<sqlvar name='tabellen' type="hashsequence" ><![CDATA[
--welche Tabellefelder sollen geändert werden:
select trim(table_name) as tabelle,trim(name) as feld from sx_fields
where name in ('matrikel_nr','mtknr')
and table_name in (select name from sx_tables where systeminfo_id in (10,7,120,130));
 ]]></sqlvar>
<sqlvar name="anzahl_echte_mtknr">
--soll überhaupt geändert werden?
select count(*) from mtknr_ldsg where mtknr=mtknr_ldsg;
</sqlvar>
</sqlvars>
<#if anzahl_echte_mtknr=0>
create schema tmp_backup_mtknr;
begin work;
<#foreach feld in tabellen>
select * into tmp_backup_mtknr.${feld.tabelle}_backup from ${feld.tabelle};
update ${feld.tabelle} set ${feld.feld}=(select M.mtknr from mtknr_ldsg M where M.mtknr_ldsg=${feld.tabelle}.${feld.feld})
where ${feld.feld} in (select M.mtknr_ldsg from mtknr_ldsg M);
</#foreach>
commit;
--wird die Tabelle mtknr_ldsg direkt ent-peudonymisiert
begin work;
update mtknr_ldsg set mtknr_ldsg = mtknr;
commit;
</#if>

Danach sollten die Pseudonyme weg sein.
Wenn das Script nicht erfolgreich war, gibt es im Schema tmp_backup_mtknr die Originaltabellen
Wenn Sie die Tabelle mtknr_ldsg nicht mit DBLINK verknüpft haben, müssen Sie sie in die sospos-DB zurück kopieren.
Wichtig: danach sollten Sie den Entladeparameter SOS_UNL_ANON von "true" auf "false" setzen
- Unter HISinOne-BI über Administration -> Entladeparameter bearbeiten, jeweils für die Komponenten Studierende und Bewerbungen
- Unter SuperX in der Datei $SOS_LOAD_PFAD/SOS_ENV bzw. $ZUL_LOAD_PFAD/ZUL_ENV
Damit laufen zukünftige Laderoutinen mit echten Matrikelnummern.

Entladen aus CampusOnline

Beim Entladen aus CampusOnline (CO) wird die sog. "SOSPOS"-Schnittstelle von CO genutzt, diese stellt eine Emulation von SOSPOS dar. In Nuancen gibt es Unterschiede zu SOSPOS, daher müssen Sie den Entladeparameter "SOURCESYSTEM" auf "co" stellen. Der Entladeparameter DATABASE ist bei CO 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 und/oder der shell-basierten Entladeroutine den JDBC-Treiber von Oracle mitgeben. Außerdem gilt:

Das Entladen von Prüfungen ist derzeit noch experimentell, daher sollten Sie den Entladeparameter start_pruef_sem auf den Wert 29001 setzen.
Inkrementelles Laden wird nicht unterstützt
Die Hochschulnummer kann nicht direkt aus CampusOnline ermittelt werden, achten Sie daher drauf dass Sie vor dem Laden aus CO die Hochschulnummer manuell auf den richtigen Wert setzen. Die richtige Hochschulnummer wird benötigt, um externe Studiengänge zu erkennen.

Konfiguration nach der Installation

SOS ist nicht gleich SOS, und je nach Größe oder Anforderung der Hochschule sind unterschiedliche Konfigurationen nach der Installation vorzunehmen. Im einfachsten Fall werden nur Schalter in der Konstanten-Tabelle in Infosystem 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 zwischen Studienschwerpunkt und Prüfungsordnungs-Version.

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

Für alle wichtigen Konfigurationstabellen existieren spezielle Bearbeitungsfunktionen; Sie finden ihn als Administrator/-in im XML-Frontend unter Prüfprotokoll Studium unter den Links in der rechten Seitenleiste.

Für Hochschulen in NRW kann die ECTS-Landesstatistik ab 2018.12 geliefert werden. Siehe Konfigurationshandbuch.

Konstanten

Nach der Installation können Sie das Verhalten der Software über Konstanten steuern.

Übersicht: Eine Übersicht über alle Konstanten der Komponente finden Sie hier: BI-Komponente Studierende, Prüfungen

Besonderheiten einzelner Konstanten

Geschlecht und Rückmeldestatus: 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.

SOS_Quellsystem

Die Konstante zeigt an, aus welchem Quellsystem der letzte Konnektorlauf stattgefunden hat.

Für die Hauptladeroutine können Sie diese im Entladescript setzten
Unterladeroutinen gelten jeweils nur für ein Vorsystem, verwenden Sie hier den entsprechenden Konnektor

Filter und Variablen

Eine Anleitung zu den Repository Variablen finden Sie hier: Hochschul-Repository-Studierenden- HISinOne-BI

Hochschulspezifische Anpassungen beim Update

Sie können beliebige hochschulspezifische Scripte nach jedem ETL-Schritt durchlaufen.

Eine Variante ist die Angabe hochschulspezifischer Anpassungen in den Dateien preparation.sql und finalize.sql, die nach dem Laden und der Transformation ausgeführt werden, siehe folgender Abschnitt.

Die andere Variante ist die Anlage von Repository-Variablen in der Datenbank, die nach Laden, Transformation und Aggregation ausgeführt werden können, siehe Allgemeine Repository Filter für Laderoutinen.

Des Weiteren arbeitet HIS daran, über Zentrale Konstanten das Laden flexibel und ohne Programmierkenntnisse steuerbar zu machen.

Allgemein: preparation und finalize

Aus Kompatibilitätsgründen 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 Infosystem-Tabellen) ausgeführt werden, z. B. Matrikelnummern ausfiltern. Die Datei $SOS_PFAD/preparation.sql.sam enthält ein paar Beispiel-Statements.

Hochschulspezifische Einstellungen - jede Nacht aktiv!

preparation.sql

Das Script preparation.sql wird, sofern es existiert, nach dem Laden der Rohdaten ausgeführt. Darin könnte man z.B. alle Schlüssel für Schwerpunkte und Prüfungsordnungsversionen (viele Hochschulen interessieren sich dafür im Berichtswesen nicht) ausfiltern bzw. auf "Leer" setzen. Bei der Installation des SOS-Moduls und der Bildung der Studiengangstabelle würden diese Schlüssel ignoriert werden. Bitte beachten Sie, dass die Einstellung zu einem späteren Zeitpunkt, d.h. wenn in SOS schon archiviert wurde, nicht oder nur durch mühsame Handarbeit rückgängig gemacht werden kann.

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

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

Lehreinheiten und Kostenstellen

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

Lehreinheiten und Kostenstellen in SOSPOS

Die Zuordnung von Lehreinheiten in SOS reicht zur Auswertung meist nicht aus. 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 Infosystem kann ein eigenes "Organigramm" der Hochschule gepflegt werden (siehe Administratorhandbuch Kernmodul).

Es gibt zwar die Möglichkeit, die Lehreinheiten aus SOS zu übernehmen, dies empfiehlt sich allerdings nur, wenn Sie die Tabelle k_abstgv exakt gepflegt haben.

Das Infosystem kann die Tabelle direkt übernehmen und die Lehreinheiten in das Organigramm übertragen, durch die Zentrale Konstante lehr_stg_ab_aus_SOS=1. Details sind bei den Zentrale Konstanten erläutert.

Lehreinheiten und Kostenstellen in HISinOne-STU

Die Lehreinheitszuordnung wird in STU bei der Pflege der Studiengänge vorgenommen unter {{#navigation:searchStudyStudies}}.
Wechseln Sie in die Registerkarte Lehreinheiten.

Das Infosystem kann die Tabelle direkt übernehmen und die Lehreinheiten in das Organigramm übertragen, durch die Zentrale Konstante lehr_stg_ab_aus_SOS=1. Details sind bei der Übernahme erläutert.

Studiengänge und Lehreinheiten Nachbereitung

Wenn Sie das Organigramm aus anderen Quellen füllen wollen (z.B. aus HISCOB), müssen Sie folgende zentrale Vorgaben des Infosystems beachten: 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 Zentrale Konstante lehr_stg_ab_aus_SOS=1 gesetzt wurde. Wenn ein neuer Studiengang vorhanden ist, wird er defaultmäßig der Lehreinheit zugeordnet, 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 im Infosystem stimmen.

Fachbereiche und Kostenstellen

Die Fachbereiche sind in SOS meist gut gepflegt und werden nach Infosystem 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 Benutzerinnen und Benutzern spezielle Fachbereiche zuweisen wollen, müssen Sie dies in der Benutzerverwaltung Kernmodul "{{#navigation:standardReportsHisinone_administrate_bia}} Administration -> Benutzer/-in -> User/-in suchen" tun. Dort Suchen Sie nach der gewünschten Userin/dem User und klicken in der Ergebnistabelle auf bearbeiten. Sie erhalten folgendes Fenster:

Datei:fb zuordnung.png

Hier können Sie nun der Benutzerin spezielle Institutionsrechte zuweisen. Achten Sie darauf, dass Sie beim Zuweisen genau den Schlüssel verwenden, der zum Fachbereich in der Studierendenverwaltung passt (bei Datenquelle sospos sind die Schlüssel max. zweistellig).

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

Datei:fb zuordnung1.png

Wenn die Fachbereiche jedoch für die Einschränkung der Leseberechtigung genutzt werden sollen, muss 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 manchmal nicht der Fall.

Zur Umschlüsselung können Sie eine Datei preparation.sql anlegen, z. B. mit folgendem Inhalt:

 --Freemarker Template
 --Umschlüsselung FBs:
 --z.B. aus SOSPOS FB 92 wird Kostenstelle 1010
 --bitte Variablen hier ergänzen:
 
 <#assign  umschluesselungen = [
   {"fb_sos":"92", "fb_klr":"1010"},
   {"fb_sos":"93", "fb_klr":"1020"}
   ] />
 <#foreach umschluesselung in umschluesselungen>
 
 --ab hier müssen sie nichts mehr ändern:
 --Prüfprotokoll:
 insert into sos_pruefrout
 (
 datum,
 tabelle,
 problem,
 aktion
 )
 select today(),'k_fb',
 'Umschlüsselung FB ${umschluesselung.fb_sos} nach ${umschluesselung.fb_klr}',
 'Info'
 from sos_cifx_neu
 where key=90
 and apnr='${umschluesselung.fb_sos}';
 
 update sos_cifx_neu set apnr='${umschluesselung.fb_klr}',
 sourcesystem_id='${umschluesselung.fb_klr}',
 uniquename='${umschluesselung.fb_klr}'
 where key=90 and apnr='${umschluesselung.fb_sos}';
 update trans_cifx set apnr='${umschluesselung.fb_klr}' where apnr='${umschluesselung.fb_sos}' and key=90;
 update k_stg_neu set fb='${umschluesselung.fb_klr}' where fb='${umschluesselung.fb_sos}';
 update k_abstgv_neu set fb='${umschluesselung.fb_klr}' where fb='${umschluesselung.fb_sos}';
 update lehr_stg_ab set fb='${umschluesselung.fb_klr}' where fb='${umschluesselung.fb_sos}';
 </#foreach>

Dieses Codebeispiel schlüsselt Fachbereiche aus SOS/STU zu Kostenstellen im Ressourcenbereich um, und schreibt einen Eintrag ins Prüfprotokoll. Es wird empfohlen vorher noch die Schlüssel einmalig aus der trans_cifx zu löschen mit:

delete from trans_cifx where key=90;

Lehreinheiten, Fakultäten und Regelstudienzeiten mit Excel nachpflegen

Wenn Sie Lehreinheiten, Fakultäten oder Regelstudienzeiten nicht im Vorsystem pflegen, können Sie diese ab Release HISinOne-BI 2019.12 oder SuperX-Studierendenmodul 1.2 auch in Excel pflegen und dann über eine browserbasierte Maske hochladen. Dies betrifft z. B. Hochschulen mit der Datenquelle CO, weil dort keine Lehreinheiten gepflegt werden (können). Die Importdatei hat eine vorgegebene Struktur, ein Muster liegt hier zum Download: Excel-Muster

Wichtiger Hinweis zur Exceldatei: jede Spalte hat einen speziell definierten Datentyp, einsehbar mit Markieren -> rechte Maustaste -> Zelle formatieren. Diese darf nicht geändert werden. Das ist wichtig, sonst würden ggf. bei Textfeldern mit Zahlen die führenden Nullen entfernt. Außerdem dürfen die Spaltenreihenfolge, die Namen der Spaltenüberschriften und der Registerkarten nicht geändert werden.

Das Beispiel ordnet Studiengänge mit dem Fach 225 und dem Abschluss 84 der Lehreinheit 1234 sowie der Fakultät 01 zu und vergibt eine Regelstudienzeit von 8 Semestern.

Generell gilt:

Mindestens das Fach muss definiert sein, darüber hinaus können Sie auch Abschluss, Vertiefung etc. festlegen und somit die Zuordnung verfeinern.
Es werden nur Lehreinheiten/FBs und Regelstudienzeiten zugewiesen, wenn es noch keine Zuordnung gibt.
Sie können auch nur einen oder zwei Schlüssel zuweisen, z. B. nur Lehreinheiten oder nur Regelstudienzeiten.
Die jeweiligen Schlüssel müssen den internen Schlüsseln im Vorsystem entsprechen.
Lehreinheiten werden, sofern Schlüssel und Name vergeben sind, in das Organigramm eingefügt, sofern sie nicht dort bereits exisitieren.
Im Organigramm werden manuell angelegte Lehreinheiten vor dem Import ergänzt, die Excel-Tabelle muss also nicht immer die gesamte Studiengangzuordnung enthalten.
Wenn Sie Lehreinheiten im Vorsystem gepflegt haben, müssen diese beim Konnektorlauf entfernt werden, beispielsweise durch die preparation-Regel

update k_abstgv_neu set lehreinh=null;

Wenn Sie Fakultät, Regelstudienzeit und Lehreinheit komplett in Excel pflegen, setzen Sie die Konstanten "lehr_stg_ab_aus_SOS" und "lehr_stg_ab_aus_COB" gleich 0 (->Nein)

Der Upload der Excel-Datei befindet sich im Menübaum in Administration -> Ladejob ausführen -> Job="Lehreinheiten, FBs und Regelstudienzeiten einlesen":

In der Maske benötigen Sie sonst nur die Excel-Datei, das Feld "Modus" oder "Sachgebiet" können Sie leer lassen. Dann schicken Sie die Maske ab.

In der Ergebnisanzeige sehen Sie ein Protokoll. Im Prüfprotokoll Studium können Sie zwei Meldungen abrufen:

Wenn Sie bei "Tabelle SuperX" die Tabelle lehr_stg_ab wählen, kommt eine Information wie viele Studiengänge eine Lehreinheit/einen FB/eine RSZ bekommen haben.

Wenn Sie bei "Tabelle SuperX" die Tabelle organigramm wählen, kommt eine Warnung, wenn es Duplikate bei den Lehreinheiten gibt, (d.h. ein Lehreinheitsschlüssel hat in der Excel-Datei mehrere unterschiedliche Namen).

Solche doppelten Lehreinheiten werden nicht übernommen.

Wenn die Zuweisung erfolgreich war, können Sie das Ergebnis nach Lauf der Hauptladeroutine auch in den Berichten bzw. OLAP-Würfeln testen.

Wie geht es weiter? Der Excel-Upload ist nur für den Initial-Import gedacht, langfristig sollten Sie die Maske Studiengangsverzeichnis (lehr_Stg_ab) für diese Angaben nutzen. Alternativ setzen Sie die Lehreinheiten/FBs/RSZ in der lehr_stg_ab nochmal zurück auf NULL, und starten erneut den Upload wie oben beschrieben.

Hochschulzugangsberechtigung

Die Fachhochschulreife berechtigt zum Studium an allen Fachhochschulen, unabhängig vom Studienfach. Universitätsstudiengänge können damit 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. Die Unterscheidung dieser Arten der Hochschulzugangsberechtigung gibt es für das In- und Ausland, um so Bildungsin- und -ausländer/-innen zu ermitteln.

Definition "Bildungsausländer": Wichtig: Seit dem SOS-Modul 0.6rc6 gilt für die Definition von Bildungsin- und -ausländern, dass nicht mehr nur das Merkmal "Hochschulzugangsberechtigung im Ausland/Inland" zugrunde gelegt wird, sondern auch "Staatsangehörigkeit=nicht Deutsch". Gemäß Definition des STBA sind Bildungsin- und ausländer/-in also immer eine Untergruppe von "Ausländerinnen und Ausländern". Konkret:

Bildungsausländer/-innen haben eine ausländische Staatsangehörigkeit, und eine HZB im Ausland erworben.
Bildungsinländer/-innen haben eine ausländische Staatsangehörigkeit, aber eine HZB im Inland

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

Die Tabelle hs_zugangsber:

tid	apnr (Gruppe)	Eintrag
1	hzbart=1	Allg. Hochschulreife
2	hzbart=2	Fachhochschulreife
7	hzbart=5	Sonstige
8	hzbart=6	Fachgeb.HS-Reife
4	hzbart=4	Allg. Hochschulreife im Ausland
6	hzbart in (3,4)	Allg.u.fach(geb.) HSReife im Ausland
3	hzbart in (1,2,5,6)	Allg.u.fach(geb.) HSReife im Inland
5	hzbart=3	Fach(geb.) Hochschulreife im Ausl.

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:

hzbart(astat)	Name	Gruppe
03	Gymnasium (allg.HSReife)	1
06	Gesamtschule(allg.HSR)	1
09	erw.Oberschule(allg.HSR) (Gültig bis 30.09.2016)	1
12	Kollegschule(allg.HSR)NRW (Gültig bis 30.09.2016)	1
18	Fachgymnasium(allg.HSR)	1
21	Berufsoberschule/Fachakademie(aHSR)	1
27	Abendgymnasium/Kolleg(allg.HSR)	1
29	Kolleg(allg.HSR) (Gültig bis 30.09.2016)	1
31	Studienkolleg(allg.HSR)	1 \| 4^*
33	Begabten-/Eignungs-/Externenprüfung(allg.HSR)	1
34	Berufl.Qualifizierte AHSR	1
35	Abschl/Zwischenprfg.(aHR) (Gültig bis 30.09.2016)	1
37	Sonstige Studienberechtigung(allg.HSR)	1
91	EignPrfg.KunstHS(all.HSR) (Gültig bis 30.09.2016)	1
94	Allgem.HS-Reife ohne Ang.	1
53	Berufl.Qualif.Fachbeb.HZB	2
60	Gymnasium FH Reife	2
62	Gesamtschulabg.12.Schulj.	2
64	Fachgymnasium(FHR)	2
65	Berufsoberschule/Fachakademie(FHR)	2
66	Fachoberschule(FHR)	2
68	Kollegschule (FHR) NRW (Gültig bis 30.09.2016)	2
70	Abendgymnasium/Kolleg(FHR)	2
71	Berufl.Qual.FHSReife	2
72	Berufsfachschule(FHR)	2
73	Meister-/Technikers.(FHR)	2
74	Fachakedemie(FHR) (Gültig bis 30.09.2016)	2
75	Kolleg Fachhochschulreife (Gültig bis 30.09.2016)	2
76	Studienkolleg (FHR)	2 \| 3*
77	Begabten-/Eignungsprüfung(FHR)	2
78	sonstige Studienber.(FHR)	2
93	Eign.Prfg.KU-u.MUHO(FH) (Gültig bis 30.09.2016)	2
96	FH-Reife ohne Angaben (Gültig bis 30.09.2016)	2
59	fachgeb.HSReife Ausland	3
79	ausserh.d.BRD erw.FHR	3
39	allg.HSReife Ausland	4
15	Berufsfachschule(aHSR)	5
24	Fachakademie (allg.HSR)	5
30	Eignprfg.Kunst-u.MusikHS.	5
98	Studienber.o.formale HSR.	5
99	ohne Angaben	5
43	Fachgymnasium(fgHSR)	6
44	Berufsoberschule/Fachakademie(fgHSR)	6
45	Fachakademie(fgHSR) (Gültig bis 30.09.2016)	6
46	Abschl/Zwischenp.(fgHSR) (Gültig bis 30.09.2016)	6
49	Abschl.Ing.bzw.Fachschule (Gültig bis 30.09.2016)	6
51	Studienkolleg (fgHSR)	6
52	Begabten-/Eignungsprüfung(fgHSR)	6
53	Berufl.Qualif.Fachbeb.HZB	6
55	sonst.Studienber.(fgHSR)	6
92	Fachgeb.EigPrfg.KU-u.MUHO (Gültig bis 30.09.2016)	6
95	Fachg.HS-Reife ohne Ang. (Gültig bis 30.09.2016)	6

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

Die Gruppierung richtet sich nach einer Vorgabe des STBA. Hier ein Bildschirmausdruck (Auszug):

Datei:hs zugang stba.png

Die Liste finden Sie auf der Website des STBA sowie bei den zuständigen Statistischen Landesämtern bereitgestellt.

Hörerstatus

In den Abfragen der Komponente Studierende ist der Hörerstatus i.d.R. als DropDown-Menü zur Auswahl enthalten. Hierbei werden die Inhalte 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 Zuordnung der hochschulinternen Hörerstatus zu den Konzepten.

Haupthörer/-in
Nebenhörer/-in
Studienkolleg
Gasthörer/-in
Sonstige

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

Der View sos_k_hrst:

apnr	kurz	druck	astat	his_hrst
1	Ord. Stud.	Ordentlicher Student/-in	1	H
2	Zweitimma.	Zweitimmatrikulierte/-r	2	H
3	Doktorand/-in	Doktorand/-in	1	H
4	Zeitstud.	Zeitstudent/-in	1	H
8	Gasthörer/-in	Gasthörer/-in	4	G
9	Prom-Gast	Promotion Gasthörer/-in	1	H

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/-in)
his_hrst ist N wenn 'astat=2' (Nebenhoerer/-in)
his_hrst ist K wenn 'astat=3' (Studienkolle)
his_hrst ist G wenn 'astat=4' (Gasthoerer/-in)

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.

Amtliche Statistik

Zum Nutzen der amtl. Statistik über die BI müssen Sie einige Vorarbeiten ausführen.

Für administrative Vorarbeiten siehe
- Amtliche Statistik Administration.
Weitere Informationen entnehmen Sie der Nutzeranleitung
- Amtliche Statistik

Zeiträume

Trimester, Stichtage und Archivierung

Gewichtung

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 Infosystem-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 Infosystem-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.

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 Infosystem (Auszug aus sos_gew_astat):

Abschluss (amtlich)	kz_fach	text	faktor
02	N	Magister (Nebenfach)	0.25
02	H	Magister (Hauptfach)	0.5
03	H	Lizenziat	1
04	H	kirchliche Prüfung	1
06	H	Promotion mit Abschluss	1
07	H	Prom.ohne Abschl.	1
08	H	Staatsexamen ohn.LAPrfg	1
11	H	Diplom II	1
14	H	Diplom I	1
22	H	LA Grund/Hauptschule	0.5
23	H	LA Realschule	0.5
25	H	LA Gymnasium	0.5
27	H	LA Berufl. Schulen	0.5
42	H	Lehramt Primarstufe	0.5
43	H	Lehramt Sek.I	0.5
44	H	Lehramt Sek. II	0.5
45	H	LA Berufl. Schulen	0.5
49	H	Lehramt Sek. II/I	0.5
50	H	Sonstige Abschlüsse	1
51	H	Diplom (FH)	1
82	H	Bachelor of. Engineering	1
85	H	Master	1
88	H	Master of science	1
94	H	Zertifikat	1
95	H	sonst. Abschlüsse	0
96	H	Abschluß im Ausland	0
97	H	keine Abschl.Prfg.	1

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):

Abschluss (amtlich)	fach_nr	text	faktor
00	1	LA erz. Anteil	0.1
00	2	LA erz. Anteil	0.1
02	3	Magister (Nebenfach)	0.25
02	1	Magister (Hauptfach)	0.5
02	2	Magister (Nebenfach)	0.25
03	1	Lizenziat	1
04	1	kirchliche Prüfung	1
06	1	Promotion mit Abschluss	1
07	1	Prom.ohne Abschl.	1
08	1	Staatsexamen ohn.LAPrfg	1
11	1	Diplom II	1
14	1	Diplom I	1
43	1	Lehramt Sek.I	0.4
43	2	Lehramt Sek.I	0.4
44	1	Lehramt Sek. II	0.4
44	2	Lehramt Sek. II	0.4
45	1	LA Berufl. Schulen	0.4
45	2	LA Berufl. Schulen	0.4
49	1	Lehramt Sek. II/I	0.4
49	2	Lehramt Sek. II/I	0.4
50	1	Sonstige Abschlüsse	1
51	1	Diplom (FH)	1
82	1	Bachelor of. Engineering	1
85	1	Master	1
88	1	Master of science	1
94	1	Zertifikat	1
95	1	sonst. Abschlüsse	1
96	1	Abschluß im Ausland	1
97	1	keine Abschl.Prfg.	1

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):

Abschluss (amtlich)	fach_nr	text	faktor
02	1	Magister (Hauptfach)	1
02	2	Magister (Nebenfach)	0.5
02	3	Magister (Nebenfach)	0.5
03	1	Lizenziat	1
04	1	kirchliche Prüfung	1
06	1	Promotion mit Abschluss	1
07	1	Prom.ohne Abschl.	1
08	1	Staatsexamen ohn.LAPrfg	1
11	1	Diplom II	1
14	1	Diplom I	1
43	1	Lehramt Sek.I	1
43	2	Lehramt Sek.I	1
44	1	Lehramt Sek. II	1
44	2	Lehramt Sek. II	1
45	1	LA Berufl. Schulen	1
45	2	LA Berufl. Schulen	1
49	1	Lehramt Sek. II/I	1
49	2	Lehramt Sek. II/I	1
50	1	Sonstige Abschlüsse	1
51	1	Diplom (FH)	1
82	1	Bachelor of. Engineering	1
85	1	Master	1
88	1	Master of science	1
94	1	Zertifikat	1
95	1	sonst. Abschlüsse	1
96	1	Abschluß im Ausland	1
97	1	keine Abschl.Prfg.	1

Gewichtete Fälle mit HISinOne

In HISinOne wird es möglich sein, komplexe Gewichtungsregeln für Studierende zu hinterlegen. Wenn diese nach einem Konnektorlauf in der BI angekommen sind, gibt es die Möglichkeit, sich eine Vorschau zu den Gewichtungen anzusehen. Gehen Sie dazu unter Studierende/Prüfungen, Administration Studierende/Prüfungen , „Studierende Gewichtungsvorschau“. Es öffnet sich folgende Maske
Datei:sos gewichtungsvorschau.png

Im ersten Feld „Art der Durchführung“ kann man zwischen „Vorschau“ und „Konnektorlauf“ wählen. Der Standard ist erstmal „Vorschau“, damit man sich einen Überblick über die Änderungen durch die im folgenden Feld auswählbare Gewichtungsvariante machen kann.

Zu Testzwecken kann man aber auch „Konnektorlauf“ wählen, dann werden tatsächlich gewichtete Werte in die Tabellen geschrieben und Sie können das Ergebnis direkt in anderen Berichten wie z.B. Studierende nach Alter überprüfen.

Beim nächtlichen Konnektorlauf werden die Daten für alle Gewichtungsvarianten neu berechnet. Im zweiten Feld „Gewichtungsvariante“ kann man wie gesagt eine Gewichtungsvariante auswählen. Wählt man „0-keine“ aus, werden die Daten ohne Gewichtung angezeigt. Im dritten Feld „Regeln“ kann man bei Bedarf einschränken, dass für eine Gewichtungsvariante nicht alle Regeln durchgeführt werden, sondern nur eine oder mehrere, die man auswählt. Man kann ein Semester auswählen – wenn man das Feld leert, werden die Daten für alle verfügbaren Semester angezeigt.

Bei Stichtag kann man zwischen aktuellen Zahlen und amtl. Statistik wählen. Leert man das Feld, werden Werte für beide Stichtagsarten berechnet. Zu Testzwecken kann es sinnvoll sein, auf bestimmte Abschlüsse, Studiengänge, Fachkennzeichen oder sogar eine oder mehrere Matrikelnummern (mehrere mit Komma getrennt) einzugrenzen. Weiterhin kann man testweise auch die Fachanzahl oder Abschlussanzahl mit einer Bedingung versehen, z.B. =2 oder >2.

Wenn Sie derartige Einschränkungen gemacht haben und als Durchführungsart „Konnektorlauf“ gewählt haben, beachten Sie bitte, dass dann auch nur für die ausgewählten Einstellungen Daten in die Tabellen geschrieben werden und auch in anderen Abfragen nur diese verfügbar sind.

In der Ergebnisansicht sieht man die Spalten Stichtag Semester Matrikelnr StudiengangNr Fachnr Fach Fachname Fachkennzeichen Abschluss Abschlussname Stuart Stufrm Stutyp ects gewicht fb. Wenn man „Vorschau“ als Durchführungsart gewählt hat, wird zusätzlich die Spalte „gewicht_ident“ angezeigt, also der vergebene Gewichtungsident, so kann man die Regelverarbeitung im Detail prüfen.

In den einzelnen Abfragen können Sie eine Gewichtungsvariante unter dem Feld „Köpfe oder Fälle“ auswählen. Wenn Sie bei eine Gewichtungsvariante auswerten, bei der auch die Fachbereich/Fakultätszuordnung geändert wurde (z.B. BWL auch unter FB Technik), dann müssen Sie bei Auswertungen die Sicht „Studiengänge nach FB gewichtet“ auswählen.

Datei:sos gewichtung sichtfb.png

Fächer-Sichten

Eine 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 in der Kernmodul-Abfrage "Sicht suchen" auf die Sichtart "Fächer-Sicht" einschränken, die jeweilige Sicht dann bearbeiten und dort die Sortiernummer ändern.

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 hochschulspezifischen 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 einfache html-Seite mit einem Aufrufmenü, das leicht in die 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 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-Seite eingebaut werden müssen, daher bietet es sich an, für diese Funktion eine spezielle "Public"-Kennung mit eingeschränkten Rechten zu erzeugen.

Als Ergebnis können Sie beispielsweise eine html-Seite im CD Ihrer Hochschule erzeugen.

Stichtagsbezug der Auswertungen

Die BI rechnet im Bereich der Studierendenstatistik und Prüfungsstatistik standardmäßig wahlweise mit tagesaktuellen oder 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 und in der BI-Tabelle semester abgelegt ist.

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.

Stichtage in der Studierendenstatistik

Die Frage, ob eine Studentin/ein Student zu dem vorgegebenen Zeitpunkt (ob Stichtag oder "heute") eingeschrieben/rückgemeldet ist oder nicht, richtet sich nach dem Datum der Einschreibung, Rückmeldung oder Exmatrikulation. Neben der reinen Gültigkeit eines Datensatzes wird aus STU/SOS also auch der Zeitbezug der Einschreibung, Rückmeldung oder Exmatrikulation übernommen und ausgewertet. Eine Einschreibung, Rückmeldung oder Exmatrikulation wird in STU/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:

Einschreiber	Eine Studentin/ein Student zählt in dem Studiengang als eingeschrieben, wenn sie/er in der Tabelle stg im Feld status den amtlichen Statistikwert 1 = "Ersteinschreiber/-in" oder 2 = "Neueinschreiber/-in" hat, das Datum der Einschreibung (stg.anfdat) kleiner oder gleich dem jeweiligen Datum ist, bzw. wenn es leer (NULL) ist, das Feld Datum der Exmatrikulation (stg.endedat) leer ist, bzw. wenn das Datum der Exmatrikulation hinter dem jeweiligen Datum liegt.
Rückgemeldet/Beurlaubt	Eine Studentin/ein Student zählt in dem Studiengang als rückgemeldet/beurlaubt, wenn sie/er in der Tabelle stg im Feld status den amtlichen Statistikwert 3 = "Rückgemeldet" oder 4="Beurlaubt" hat, das Datum der Rückmeldung/Beurlaubung (stg.ruebeudat) kleiner oder gleich dem jeweiligen Datum ist, bzw. wenn es leer (NULL) ist, das Feld Datum der Exmatrikulation (stg.endedat) leer ist, bzw. wenn es nicht leer ist, es für den stg-Datensatz einen Folge-Datensatz für das jeweils nächste Semester gibt (die Studentin/der Student hat z.B. das Fach gewechselt) oder das Datum der Exmatrikulation hinter dem jeweiligen Datum liegt.
Exmatrikuliert	Eine Studentin/ein Student zählt in dem Studiengang als exmatrikuliert, wenn das Datum der Exmatrikulation (stg.endedat) kleiner oder gleich dem jeweiligen Datum ist, es für den stg-Datensatz keinen Folge-Datensatz für das jeweils nächste Semester gibt (in diesem Falle ist das Semester des stg-Datensatzes kleiner oder gleich dem zugehörigen sos-Datensatz der jew. Matrikelnummer).

Der Einschreib- oder Rückmeldestatus eines Datensatzes wird also in Abhängigkeit vom Datum des Stichtags gesetzt. Wenn z. B. eine Studentin/ein Student 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 eine Studentin/ein Student 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 Enddatum (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:

Einschreiber/Rückgemeldet/Beurlaubt

Eine Studentin/ein Student zählt in dem Studiengang als eingeschrieben/rückgemeldet/beurlaubt, wenn das Feld Datum der Exmatrikulation (stg.endedat) leer ist, bzw.:

wenn das Datum der Exmatrikulation hinter dem jeweils heutigen Datum liegt oder
wenn es für den Studiengang einen Folge-Datensatz für das jeweils nächste Semester gibt (die Studentin/der Student hat z. B. das Fach gewechselt) oder
das Enddatum am Ende des Semesters oder höher liegt, d. h. sie/er hat bis Semesterende studiert, z. B. im SoSe zum 30.9.

Exmatrikuliert

Eine Studentin/ein Student zählt in dem Studiengang als exmatrikuliert, wenn das Feld Datum der Exmatrikulation (stg.endedat) nicht leer ist und

wenn das Datum der Exmatrikulation vor dem jeweils heutigen Datum liegt und
wenn es für den Studiengang keinen Folge-Datensatz für das jeweils nächste Semester gibt und
wenn das Enddatum vor dem Ende des Semesters liegt, d. h. sie/er hat nicht bis Semesterende studiert, z. B. im SoSe vor dem 30.9.

Stichtag durch Archivierung

Das Prinzip der Archivierung

Die im Folgenden beschriebene Konfiguration ist veraltet, d.h. sie wird in zukünftigen Versionen von HISinOne-BI oder SuperX entfallen. Es gibt daher weiter unten eine Anleitung zum Ausschalten der Archivierung in vorhandenen Systemen.

Es ist möglich, durch Archivierung in der BI 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 der BI in seiner Gültigkeit bis zum aktuellen Datum begrenzt.

In der BI kann 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 der BI jederzeit den Datenstand von SOS zu einem Stichtag auswerten kann. Prinzipiell ist es möglich, direkt mit einem beliebigen Datum auf die Grunddaten zuzugreifen. Diese Funktionalität ist jedoch den Power-Usern vorbehalten.

Wichtig: Am Anfang noch nicht archivieren!

Die Archivierung ist eine Funktionalität, die wir keinesfalls bei der Erstinstallation empfehlen. Deshalb ist die Funktion standardmäßig ausgeschaltet. Sie sollte erst eingeschaltet werden, wenn die Phase der Fehlerbereinigung und der hochschulspezifischen Anpassung der Daten (also nach ca. ½ Jahr) abgeschlossen ist - sonst archivieren Sie die Datenfehler und Schlüsseländerungen auch, was zu unvorhergesehenen Ergebnissen führen kann. Außerdem stellt die Funktionalität relativ hohe Anforderungen an Rechnerkapazität und Datenbank-Speicher (dbspace). Die Archivierungsfunktion verträgt sich z. B. nicht gut mit der Funktion, aus SOS immer alles komplett zu entladen (SOS_UNL_COMPLETE=true).

Sie können die Archivierung 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 in die BI 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 von HISSOS machen.

Archivierung ausschalten

In neueren Versionen des Studierenden-Moduls gibt es einfachere und stabilere Versionen der Archivierung: Sie können die Hilfstabellen der Studierenden- und Absolventenstatistik über sog. "Einfriersemester" archivieren, d.h. es wird ein Startsemester für die Berechnung vergeben, alle vorherigen Semester werden bei den jew. Stichtagen nicht mehr geändert.

Daher bietet es sich an, die Archivierung über Historisierung (s.o.) auszuschalten. Dazu müssen Sie:

zunächst eine Sicherung der Eduetl-/SuperX-Datenbank machen,
die Einfriersemester bzw. Startsemester setzen. Die Wege unterscheiden sich bei den jew. Versionen
- Bis HISinOne-BI 7.1 bzw. SuperX-Studierenden-Modul 0.9
  - Konstante SOS_start_stg_aggr für Studierende und SOS_start_lab_aggr für Absolventen
- Ab HISinOne-BI 8.0 bzw. SuperX-Studierenden-Modul 1.0
  - Konstante SOS_start_stg_aggr für Studierende und SOS_start_lab für Absolventen
- Ab HISinOne-BI 2017.12 bzw. SuperX-Studierenden-Modul 1.1
  - Konstante SOS_start_stg_aggr für den Stichtag Amtl. Statistik Land (Studierende) und SOS_start_lab für den Stichtag Amtl. Statistik Land (Prüf.) (Absolventen)
  - Startsemester für selbst angelegte Stichtage für Studierende für Absolventen
Danach setzen Sie die Konstante SOS Archivierung auf 0.
Wenn Sie ohne Startsemester beim Entladen aus dem Vorsystem arbeiten, also wenn die Entladeparameter start_stud_sem=19911 und start_pruef_sem=19911 sind, können Sie auch die Altdaten der historisierten Datensätze entfernen: in den Tabellen sos_sos, sos_stg und sos_lab alle Datensätze löschen, die vor dem Datum gültig waren, also mit

delete from sos_sos where gueltig_bis < today();
delete from sos_stg where gueltig_bis < today();
delete from sos_lab where gueltig_bis < today();
update sos_sos set gueltig_von=date_val('01.01.1900') where gueltig_von != date_val('01.01.1900');
update sos_stg set gueltig_von=date_val('01.01.1900') where gueltig_von != date_val('01.01.1900');
update sos_lab set gueltig_von=date_val('01.01.1900') where gueltig_von != date_val('01.01.1900');

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

Bei dem (in der BI 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 jedoch einen lohnenswerten Mehrwert bringt; wenn Sie in der aktuellen Version des SOS-Moduls in der BI darauf verzichten wollen und immer tagesaktuelle Daten sehen wollen, müssen Sie

alle Einträge in der Tabelle sos_stichtag löschen, außer denen, 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.

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 im 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 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 Folgesemester, aber vor dem Stichtag:

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

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 Folgesemester, nach dem Stichtag:

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

Das Datum ist erfahrungsgemäß 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 über Stichtag Prüfungen der Zeitbezug ausgewählt.: Datei:stichtag pruefen.png

Wenn Sie die Ausprägung Amtl. Statistik Land (Prüf.) oder Aktuelle Zahlen wählen, wird bei den Abfragen das Datum der Prüfung ausgewertet.

Bei der semesterbezogenen Zählung wird das in der Prüfungsverwaltung (POS oder EXA) zugeordnete Semester gezählt (bei POS das Feld psem in lab).

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 die Gutachterin/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 SoSe 2006, ist aber noch nicht als "bestanden" verbucht. Die Gutachterin/der Gutachter kommt nicht dazu, die Arbeit bis zum Stichtag der Lieferung für das SoSe 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 SoSe 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 SoSe 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 der BI überschrieben. Die Absolventenzahl für das Semester ändert sich also. Im obigen Beispiel würde die Prüfung also nachträglich zum SoSe 2006 gezählt.

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

Die folgende Tabelle zeigt Beispielprüfungen:

Stichtag	Semester	Datum der Prüfung	Gültigkeit der Prüfung (ab)	Zählung zu Semester
31.05.2005	WS 04/05	01.02.2005	01.02.2005	WS 04/05
		01.03.2005	02.06.2005	SS 05
01.12.2005	SS 05	01.05.05	01.05.05	SS 05
		01.07.05	01.07.05	SS 05

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 das 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 SoSe 05 gezählt.

Verwaltung der Stichtage

Bei der Installation der Komponente Studierende werden die Stichtage abhängig vom Vorsystem verwaltet:

GX: Die Stichtage für jedes Semester werden aus SOSPOS übernommen.
HISinOne: Hier gibt es keinen Dialog für Stichtage. Es wird vom Konnektor ein fiktiver Stichtag in der Mitte des Semesters angelegt.

Bearbeitung der Stichtage in der BI

Klicken Sie auf {{#navigation:standardReportsHisinonebi}} Studierende, Prüfungen -> Administration Studierende, Prüfungen -> Prüfprotokoll Studium -> Stichtage
Es werden Ihnen alle Stichtage für den Bereich Studierende, Prüfungen angezeigt.
Stichtagsdatum ändern
1. Klicken Sie auf Bearbeiten.
2. Ändern Sie das Datum.
3. Klicken Sie auf Speichern, um die Änderung zu übernehmen.
4. Klicken Sie auf Datei:delete.gif Löschen, um einen Eintrag zu löschen.
Name oder Art des Stichtags ändern
1. Ändern Sie den Namen oder die Art des Stichtags in dem jeweiligen Feld.
2. Klicken Sie auf Speichern, um die Änderung zu übernehmen.
3. Für die Stichtage Amtl. Statistik Land und Amtl. Statistik Land (prüf.) ist diese Funktion Datei:Editable not.png deaktiviert.
Stichtag löschen
1. Klicken Sie auf Datei:delete.gif Löschen, um einen Eintrag zu löschen.

Datei:sossys.png

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, sodass Prüfungen mit Prüfungsdatum bis zum Semesterende noch dem Semester zugerechnet werden und Prüfungen mit Prüfungsdatum am Folgetag schon dem nachfolgenden Semester.

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

Wenn die Konstante "semester_aus_SOS" = 1" gesetzt ist, wird der Stichtag für die amtliche Studierendenstatistik aus SOS (Tab. sossys.stistat) übernommen. Das gilt nur für das Vorsystem SOSPOS! In diesem Fall werden manuelle Änderungen an den Stichtagen durch die Laderoutine überschrieben.

Bei Vorsystem HISinOne werden die manuellen Änderungen nicht überschrieben. Die Pflege der Stichtagsangaben erfolgt hier ausschließlich in der BI.

Siehe hierzu: Amtliche Statistik Studierende Pruefungen - HISinOne-BI

Datei:Editable not.png Das Speichern für die Stichtage Amtl. Statistik Land und Amtl. Statistik Land (prüf.) wird an dieser Stelle unterbunden, damit das Einfrieren der von uns vordefinierten amtlichen Stichtage für Studierende und Prüfungen nur über die Konstanten gepflegt werden kann. Alle weiteren z.B. selbst angelegten Stichtage können ausschließlich über die Stichtagsverwaltung gepflegt werden.

Eigene Stichtage anlegen

Neben den in in der BI ausgelieferten Stichtagen zur amtlichen Statistik können Sie auch eigene Stichtage festlegen. Dazu muss man zunächst in Prüfprotokoll Studium auf 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 als Beispiel der Studierenden-Stichtag Test angelegt, dem in drei Semestern Stichtage zugeordnet sind:

Datei:stichtage neu.png

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

Alte Semester nachträglich einspielen

Viele Hochschulen haben in der Vergangenheit immer zum jeweiligen Stichtag einen Dump der kompletten SOSPOS-Datenbank angelegt, um stichtagsbezogene Daten zu archivieren. Man kann auch aus dem jeweiligen Dump entladen und den Stand in die BI laden. Man darf dabei aber nicht die Archivierung einschalten, denn die Daten bekommen dann den Gültigkeitszeitraum "heute", nicht rückwirkend.

Es gibt darüber hinaus eine "Low-Cost"-Variante: Sie können ohne Archivierung alle Altdaten laden und für jedes Semester den Konnektor ausführen und dann die Hilfstabelle sos_stg_aggr bzw. sos_lab_aggr für das jeweilige Semester einfrieren. Das geht mit der Konstante SOS_start_stg_aggr bzw. SOS_start_lab in der Konstantenverwaltung.

Wenn dann alle Altdaten übernommen sind, können Sie die Archivierung für zukünftige Semester einschalten. Im Folgenden wird beschrieben, wie Sie die Hilfstabelle archivieren.

Archivierung einzelner Semester in der Hilfstabelle

Normalerweise werden die BI-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 BI-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_lab jeweils ein Startsemester eingeben, damit 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 jeweilige Semester werden immer neu berechnet. Nur so bleiben die tagesaktuellen Werte vergleichbar mit denen im Vorsystem.

Trimester

Es stehen Skripte zur Verfügung, mit deren Hilfe die Komponenten Bewerbung, Zulassung, Studierende, Prüfung und Studienverlauf auf Trimester umgestellt werden können.

Es gibt kein Skript für die entgegengesetzte Richtung, also zur Umstellung von Trimester auf Semester. Die Umstellung auf Trimester kann daher nicht leicht rückgängig gemacht werden.

Beachten Sie den Kommentar zu der zentralen Konstante SOS_Trimester Zentrale Konstanten

Durchführung der Umstellung von Semester auf Trimester

Ändern Sie den Namen der Datei trimester_customize.sql in customize.sql in dem folgenden Verzeichnis:
- tomcat/webapps/superx/WEB-INF/conf/edustore/db/module/sos/conf
Kopieren Sie diese Datei(customize.sql) in die Verzeichnisse
- tomcat/webapps/superx/WEB-INF/conf/edustore/db/module/zul/conf
- tomcat/webapps/superx/WEB-INF/conf/edustore/db/module/erfolg/conf
Führen Sie ein Komponenten-Upgrade der Komponenten Bewerbung, Zulassung, Studierende, Prüfung und Studienverlauf durch.
Führen Sie ein Komponenten-Update der Komponenten Bewerbung, Zulassung, Studierende, Prüfung und Studienverlauf durch.
Aktualisieren Sie im Webanwendungsmanager der HISinOne-BI den Server-Cache.
Melden Sie sich abschließend am System neu an.

Die Umstellung umfasst nicht die Spaltenbezeichner der Datenblätter. Diese können derzeit nicht durch die obigen Skripte umgestellt werden.

Einladen der Studierenden- und Prüfungsdaten

Datenvalidierung

Datenvalidierung Studierende

Nach der ersten Datenübertragung sollten Sie die Übereinstimmung der Studierenden- und Absolventendaten zwischen HISinOne-STU und HISinOne-BI prüfen.

Im Folgenden wird gezeigt, wie Sie einzelne Suchanfragen aus HISinOne-STU und HISinOne-BI vergleichen können.

Diese Anleitung bezieht sich ausschließlich auf das Vorsystem HISinOne. Für die GX-Vorsysteme, lesen Sie bitte hier:

Admin-Komponente Studierende-Datenvalidierung SOSPOS-GX-HISinOne-BI

Vorbedingungen

Rollen und Rechte

Funktion	Rolle	Recht	Hinweis
Zugriff auf alle Standardberichte im Bereich Studierende	STU-Senior-Manager/-in	Standardberichte anzeigen
Zugriff auf die amtliche Studierenden-Statistik	STU-Senior-Manager/-in	Amtliche Statistik für Studentendaten erstellen
Zugriff auf die Bearbeitung der Studierendendaten	STU-Senior-Manager/-in	Studentendaten ändern

Dialogbasierte Datenvalidierung HISinOne-BI und HISinOne-STU

Wenn Sie Personen mit der Rolle Gasthörer/-in in HISinOne verwalten, dann schränken Sie den Hörerstatus beim Abgleich zwischen STU und BI ein, z.B. auf Haupthörer oder Nebenhörer.

Validierung Köpfe gesamt

Das erste Ziel besteht darin die Gesamtzahlen möglichst ohne spezielle Filter zu vergleichen, damit Sie die potentiellen Fehlerquellen bei der Auswahl von Merkmalen möglichst gering halten.

Abfrage in der BI

Klicken Sie auf > Standardberichte > Studierende, Prüfungen > Studierende
Wählen Sie beispielsweise den Standardbericht Studierende nach Fach-/Hochschulsemester
Schränken Sie die Abfrage mit folgenden Parametern ein:
- Köpfe oder Fälle ? : Köpfe
- Stichtag : Aktuelle Zahlen
- Semester : aktuelles Semester
- Status : Alle
- Hörerstatus : alle
- Ausgabe : nach Fach
In der ersten Zeile, in der Spalte Alle erhalten Sie die Gesamtsumme.

Auswertung in STU

Abgleich der Zahlen mit HISinOne

Klicken Sie auf {{#navigation:enrollmentEditDataOfStudent}}
Klicken Sie auf Erweiterte Suche
Schränken Sie die Abfrage im Fieldset Studiengänge suchen folgendermaßen ein:
- Fachnummer : 1
- Studiennummer : 1
- Semester : aktuelles Semester

SQL-Selektion zur Validierung der Anzahl der Köpfe.

Wenn es Differenzen zwischen HISinOne und HISinOne-BI gibt, können Sie auch einzelne Matrikelnummern abgleichen.

Abfrage von Matrikelnummern in der BI

Klicken Sie auf > Standardberichte > Studierende, Prüfungen > Studierende
Wählen Sie das Studierende Datenblatt
Schränken Sie die Abfrage mit folgenden Parametern ein:
- Köpfe oder Fälle ? : Köpfe
- Stichtag : Aktuelle Zahlen
- Seit Semester : aktuelles Semester
- Bis Semester : aktuelles Semester
- Status : Alle
- Hörerstatus : alle
- Bericht : Generisches Standardlayout
- Felder : Matrikel-Nr.
- Schlüssel anzeigen : Ja
- Ausgabeformat : HTML
Die Liste können Sie über Datei:Table pencil.png Tabelle editieren sortieren und z.B. nach Excel ausgeben um sie mit der Liste aus HISinOne zu vergleichen.

SQL-Selektion zur Validierung der Anzahl der Köpfe mit Angabe der Matrikelnummern.

Validierung nach Studienfach

Sowohl in HISinOne, als auch in HISinOne-BI können Sie die Studierenden auch nach Studienfach (Schlüssel) ausgeben.

Abfrage in der BI

Klicken Sie auf > Standardberichte > Studierende, Prüfungen > Studierende
Wählen Sie das Studierende Datenblatt
Schränken Sie die Abfrage mit folgenden Parametern ein:
- Köpfe oder Fälle ? : Köpfe
- Stichtag : Aktuelle Zahlen
- Seit Semester : aktuelles Semester
- Bis Semester : aktuelles Semester
- Status : Alle
- Hörerstatus : alle
- Bericht : Generisches Standardlayout
- Weitere Tabellen : Studiengänge
- Felder :
  - Fach
  - Summe
- Schlüssel anzeigen : Ja
- Ausgabeformat : HTML
Das Ergebnis müssen Sie dann noch nach dem Fach (Schlüssel) sortieren.

Auswertung in STU

Abgleich der Zahlen mit HISinOne

Klicken Sie auf {{#navigation:enrollmentEditDataOfStudent}}
Klicken Sie auf Erweiterte Suche
Schränken Sie die Abfrage im Fieldset Studiengänge suchen folgendermaßen ein:
- Fachnummer : 1
- Studiennummer : 1
- Semester : aktuelles Semester
- Fach : entsprechend angeben

SQL-Selektion zur Validierung der Anzahl je Studienfach

Neben der Suche nach dem Studienfach sind auch weitere Suchkriterien möglich. Grundsätzlich kann die Suche auf alle Suchparameter eingeschränkt werden, die gleichermaßen in HISinOne-BI und in HISinOne-STU zu finden sind. Nachfolgend finden Sie ein paar Beispiele für solche Suchkriterien:

Standort
Fakultät/Fachbereich
Abschluss
Hörerstatus

Datenvalidierung Prüfungen

Nach dem ersten Update sollten Sie, analog zu den Studierendendaten, stichprobenartig die Gültigkeit der Absolventenstatistik prüfen.

Im Folgenden wird gezeigt, wie Sie einzelne Suchanfragen aus HISinOne-STU und SOS-GX vergleichen können.

Diese Anleitung bezieht sich ausschließlich auf das Vorsystem HISinOne. Für die GX-Vorsysteme, lesen Sie bitte hier:

Admin-Komponente Studierende-Datenvalidierung SOSPOS-GX-HISinOne-BI

Vorbedingungen

Rollen und Rechte

Funktion	Rolle	Recht	Hinweis
Zugriff auf alle Standardberichte im Bereich Studierende	STU-Senior-Manager/-in	Standardberichte anzeigen
Zugriff auf die amtliche Studierenden-Statistik	STU-Senior-Manager/-in	Amtliche Statistik für Studentendaten erstellen
Zugriff auf die Bearbeitung der Studierendendaten	STU-Senior-Manager/-in	Studentendaten ändern

Dialogbasierte Datenvalidierung HISinOne-BI und HISinOne-STU

Validierung Abschlussprüfungen je Prüfungssemester

Das erste Ziel besteht darin die Gesamtzahlen möglichst ohne spezielle Filter zu vergleichen, damit Sie die potentiellen Fehlerquellen möglichst gering halten.

Abfrage in der BI

Klicken Sie auf > Standardberichte > Studierende, Prüfungen > Prüfungen > Abschlussprüfungen
Wählen Sie beispielsweie den Standardbericht Prüfungen nach Fachstudiendauer-Durchschnitt
Schränken Sie die Abfrage mit folgenden Parametern ein:

- Köpfe oder Fälle ? : Fälle
- Stichtag Prüfungen : Semesterbezogene Zählung
- Semester : aktuelles Semester
- Prüfungsstatus : bestanden
- Studienabschnitt : Hauptprüfung
In der ersten Zeile, in der Spalte Gesamtzahl erhalten Sie die Gesamtsumme.

Auswertung in STU

Abgleich der Zahlen mit HISinOne

Klicken Sie auf {{#navigation:enrollmentEditDataOfStudent}}
Klicken Sie auf Erweiterte Suche
Schränken Sie die Abfrage im Fieldset STU-relevante Prüfungen folgendermaßen ein:
- Semester : aktuelles Semester und Jahr
- Status : bestanden
- Prüfungsart : Abschlussprüfung

Wenn es Differenzen zwischen HISinOne und HISinOne-BI gibt, können Sie auch einzelne Matrikelnummern abgleichen.

Abfrage von Matrikelnummern in der BI

Klicken Sie auf > Standardberichte > Studierende, Prüfungen > Prüfungen > Abschlussprüfungen
Wählen Sie das Prüfungen im Detail Datenblatt
Schränken Sie die Abfrage mit folgenden Parametern ein:
- Köpfe oder Fälle ? : Fälle
- Stichtag Prüfungen : Semesterbezogene Zählung
- Seit Semester : aktuelles Semester
- Bis Semester : aktuelles Semester
- Prüfungsstatus : bestanden
- Studienabschnitt : Hauptprüfung
- Bericht : Generisches Standardlayout
- Felder :
  - Prüfungen (Detail):Fach-Nr. - fach_nr
  - Prüfungen (Detail):Matrikel-Nr. - matrikel_nr
  - Prüfungen (Detail):Prüfungssemester - sem_der_pruefung
  - Prüfungen (Detail):Studiengang - tid_stg
- Schlüssel anzeigen : Ja
- Ausgabeformat : HTML
Die Liste können Sie über Datei:Table pencil.png Tabelle editieren sortieren und z.B. nach Excel ausgeben um sie mit der Liste aus HISinOne zu vergleichen.

Validierung Abschlussprüfungen nach Prüfungsdatum

Abfrage in der BI

Klicken Sie auf > Standardberichte > Studierende, Prüfungen > Prüfungen > Abschlussprüfungen
Wählen Sie beispielsweie den Standardbericht Prüfungen nach Fachstudiendauer-Durchschnitt
Schränken Sie die Abfrage mit folgenden Parametern ein:
- Köpfe oder Fälle ? : Fälle
- Stichtag Prüfungen : Aktuelle Zahlen
- Semester : aktuelles Semester
- Prüfungsstatus : bestanden
- Studienabschnitt : Hauptprüfung
In der ersten Zeile, in der Spalte Gesamtzahl erhalten Sie die Gesamtsumme.

Auswertung in STU

Abgleich der Zahlen mit HISinOne

Klicken Sie auf {{#navigation:enrollmentEditDataOfStudent}}
Klicken Sie auf Erweiterte Suche
Schränken Sie die Abfrage im Fieldset STU-relevante Prüfungen folgendermaßen ein:
- Datum der Prüfung : tt.mm.jjjj :: tt.mm.jjjj (Hier geben Sie den ersten und letzten Tag des Semesters an)
- Status : bestanden
- Prüfungsart : Abschlussprüfung

Prüfungen ohne eingetragenes Prüfungsdatum werden in der BI automatisch dem hinterlegten Prüfungssemester zugeordnet. Diese Prüfungen sind in der BI in der obigen Abfrage enthalten. In STU lassen sie sich wie folgt finden: Finden von Prüfungen ohne Prüfungsdatum mit HISinOne

Klicken Sie auf {{#navigation:enrollmentEditDataOfStudent}}
Klicken Sie auf Erweiterte Suche
Schränken Sie die Abfrage im Fieldset STU-relevante Prüfungen folgendermaßen ein:
- Semester : aktuelles Semester und Jahr
- Datum der Prüfung : ISNULL
- Status : bestanden
- Prüfungsart : Abschlussprüfung

Wenn es Differenzen zwischen HISinOne und HISinOne-BI gibt, können Sie auch einzelne Matrikelnummern abgleichen.

Abfrage von Matrikelnummern in der BI

Klicken Sie auf > Standardberichte > Studierende, Prüfungen > Prüfungen > Abschlussprüfungen
Wählen Sie das Prüfungen im Detail Datenblatt
Schränken Sie die Abfrage mit folgenden Parametern ein:
- Köpfe oder Fälle ? : Fälle
- Stichtag Prüfungen : Aktuelle Zahlen
- Seit Semester : aktuelles Semester
- Bis Semester : aktuelles Semester
- Prüfungsstatus : bestanden
- Studienabschnitt : Hauptprüfung
- Bericht : Generisches Standardlayout
- Felder :
  - Prüfungen (Detail):Fach-Nr. - fach_nr
  - Prüfungen (Detail):Matrikel-Nr. - matrikel_nr
  - Prüfungen (Detail):Prüfungssemester - sem_der_pruefung
  - Prüfungen (Detail):Studiengang - tid_stg
- Schlüssel anzeigen : Ja
- Ausgabeformat : HTML
Die Liste können Sie über Datei:Table pencil.png Tabelle editieren sortieren und z.B. nach Excel ausgeben um sie mit der Liste aus HISinOne zu vergleichen.

Ü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 aus, 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 Scripts sos_update.x die Konstante lehr_stg_ab_aus_SOS gleich "1" setzen, dann wird die Studiengangstabelle aus der SOS-Tabelle k_abstgv gefüllt. Wenn Studiengänge in k_abstgv nicht verzeichnet sind bzw. keine Lehreinheitszuordnung dort getroffen worden 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 Fachbereichen 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 Schlüsseltabelle lehr_stg_ab vorgenommen werden.

Umgang mit Löschung von Studierenden und Absolventinnen/Absolventen

Verfügbar ab Version

{{{1}}} {{{2}}}

Dies funktioniert folgendermaßen: In der Hauptladeroutine werden die übertragenen Semester komplett neu übernommen, d.h. die geladenen Semester werden zuerst gelöscht und dann neu eingefügt. Die entscheidenden Skripte sind trans_sos_stg_pre.sql und trans_sos_lab_pre.sql.

Außerdem gibt es in HISinOne einen Mechanismus, dass bei Löschung von Studierenden über den Eventlistener von HISinOne die Lösch-Information direkt in die BI-Datenbank (hisinone_deleted_entity) geschrieben wird. Beim nächsten Lauf der Hauptladeroutine Studierende, Prüfungen wird die Person dann aus den Studierendendaten gelöscht.

Bis HISinOne-BI 2021.06 bzw. SuperX-Studierende 0.6 wurden Studierende im DWH teilweise nicht gelöscht, wenn sie im Vorsystem gelöscht wurden. Es wurde

für Absolventinnen/Absolventen ein Workaround genutzt,
der genannte Mechanismus über den Eventlistener von HISinOne kann nicht von allen Hochschulen genutzt werden, weil einige Hochschulen die BI nicht auf allen Cluster-Knoten nutzen bzw. sogar nur in einer komplett vom produktiven HISinOne-System getrennten Umgebung. Bei solchen Konfigurationen kann der Eventlistener nicht in die BI-Datenbank schreiben und die Lösch-Informationen kann nicht an die BI übermittelt werden.
Studierende können Sie einzeln löschen
- indem Sie die Hauptladeroutine Studierende, Prüfungen in mehreren Schritten ausführen:
  1. Aktion "Nur Vorsystem entladen" ausführen
  2. im Dateisystem in der Datei module/sos/rohdaten/unl/sos_stud_loe.unl die zu löschenden Matrikelnummern zeilenweise eintragen. Jede Zeile mit einem "^" beenden und die Datei speichern.
  3. Aktion "Konnektor starten" ausführen
- oder indem Sie folgendes SQL ausführen:

delete from sos_sos where matrikel_nr in (xxx);
delete from sos_stg where matrikel_nr in (xxx);
delete from sos_stg_aggr where matrikel_nr in (xxx)
and (stichtag = (select tid from sos_stichtag I where I.appl_key='0') 
or
(stichtag = (select tid from sos_stichtag I where I.appl_key='1') 
and sem_rueck_beur_ein >= (select I.einfriersemester from sos_stichtag I where I.appl_key='1')
)
);

Inkrementelles Laden

Komponente Studierende inkrementell Laden - HISinOne-BI

Fehlerbehandlung und Regelbetrieb

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.

Zur Fehlerbehandlung: In der Logdatei befindet sich auch die Ausgabe von Prüfroutinen (Stichwort "Warnung"…). Des Weiteren tauchen bei der ersten Übernahme aus SOS oft Datenfehler auf, z.B. Studierende ohne Kennzeichen Geschlecht. Um den Ladeprozess nicht zu unterbrechen, werden die Fehlersätze entladen und gelöscht. Die entladenen Sätze stehen in der Datenbanktabelle sos_pruefrout, die wiederum in der SuperX-Abfrage Prüfprotokoll Studium ausgewertet werden kann.

Warnungen

Das 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. Prüfprotokoll Studium gibt entsprechende Warnungen aus:

Ausrufen unter {{#navigation:standardReportsHisinone_administrate_bia}} -> Studierende, Prüfungen --> Administration Studierende, Prüfungen --> Prüfprotokoll Studium

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

Datei:pruefrout tabelle.png

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

Vom Pseudonym zur echten Matrikelnummer in SOS

select lab.* from lab L, mtknr_ldsg M
 where M.mtknr=L.mtknr
 and M.mtknr_ldsg=<<Pseduoynmisierte Matrikelnr.>>;

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.

Datei:pruefrout probleme.png

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 den Abfragen nicht überein).

Ein erklärungsbedürftiges Problem ist folgendes:

Warnung: Gewichtungsfaktor für Abschluss fehlt; SuperX ermittelt für jeden Abschluss aus dem amtlichen Schlüssel einen Gewichtungsfaktor; normalerweise ermittelt SuperX bei neuen Abschlüssen aus dem amtlichen Statistik-Schlüssel den Gewichtungsfaktor. Wenn nun ein neuer Abschluss hinzukommt, für den noch kein amtlicher Schlüssel existiert, dann wird diese Warnung ausgegeben; sie müssen in der Tabelle sos_gew_astat den betreffenden Abschluss nachtragen, und zwar für alle Gewichtungsarten (einfache Gewichtung, Vollzeitäquivalente etc.).

Regelbetrieb und Einrichten des Cronjob

siehe Komponenten Update-HISinOne-BI

Entfernen des SOS-Moduls

Die Deinstallation des ZUL Moduls unterscheidet sich zwischen HISinOne und SuperX. Daher gibt es zu jedem System eine eigene Installationsseite:

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)

Bestandteile des SOS-Moduls

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

Datei:architektur des sos moduls.png

Die Daten werden aus dem Basissystem extrahiert und die resultierenden Datentabellen werden mit Schlüsseln verknüpft. Teilweise wird auf Schlüsseltabellen 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 Hilfstabellen ist recht aufwändig und dauert erfahrungsgemäß die ganze Nacht; der Vorteil ist aber, dass die Abfragen dadurch erheblich schneller laufen.

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-Moduls 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.

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 Stammdaten und für die Fächer bzw. Prüfungen. Die Felder werden beim Abschnitt [#sossos 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).

Studiengänge

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

Prüfungen

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

Prüfungsnummern

Bei den 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:

Legen Sie zunächst beim Entladen in dem Entladeparameter POS_PNR die jeweiligen [#EntladenunterPostgresoderInformix Prüfungsnummern] an, die Sie überhaupt entladen wollen.
Fügen Sie in der Tabelle cif manuell neue Datensätze hinzu, mit den Feldern:tid=<<Nächsthöherer Wert>>key=9010apnr=<<Die Prüfungsnummer>>druck="Vorprüfung" oder "Hauptprüfung"
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.

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.

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 sos_sos.

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 sos_stg.

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 gilt die 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 im Wertebereich "1" bis "6" bzw "8" für "ohne Note" liegt), wird der Wert ungültig

Weitere Details siehe Tabellenschema sos_lab.

Weitere Datentabellen

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

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.

Schlüsseltabellen 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 aktualisiert. Dabei werden Schlüssel, die in SOS gelöscht werden, in SuperX weitergeführt.

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:

tid	apnr	eintrag
3	studiengang_nr in (1,2,3,4,5,6) and fach_nr in (1,2,3,4,5,6) and 'gew' = 'gew'	gewichtete Fälle
4	studiengang_nr in (1,2,3) and fach_nr =1	1. Fach im 1.-3.Studiengang
1	studiengang_nr = 1 and fach_nr = 1	Köpfe
2	studiengang_nr in (1,2,3,4,5,6) and fach_nr in (1,2,3,4,5,6)	Fälle
5	studiengang_nr = 1 and fach_nr in (1,2,3,4,5,6)	Fälle 1. Stdg.
6	studiengang_nr = 2 and fach_nr in (1,2,3,4,5,6)	Fälle 2. Stdg.
7	studiengang_nr = 3 and fach_nr in (1,2,3,4,5,6)	Fälle 3. Stdg.

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).

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:

Feld	Erläuterung	Typ	Beispiel
lehr	Kennzahl der Lehreinheit gemäß MWF.	char(10)	"0100000" für Philosophie
stg	Studiengang-Kennzahl aus dem SOS-System (stg aus k_stg)	char(3)	"053"
vertfg	Vertiefungsrichtung-Kennzahl aus dem SOS-System	char(3)	"0" (wenn keine Vertiefung vorhanden)
kz_fach	Fachkennzeichen (Haupt / Nebenfach); z.B. beim Abschluss Magister "H" (Hauptfach), "N" (Nebenfach), ansonsten "H"	char(1)	"H"
schwerpunkt	Studienschwerpunkt	char(2)
pversion	Prüfungsordnungs-Version	smallint
abschluss	Amtlicher Schlüssel des Abschlusses aus dem SOS-System (astat aus k_abint)	char(2)	"02"
text	Volltext des Studiengangs	char(200)	LA Sek. I Ev. Theologie
regel	Regelstudienzeit des Studiengangs	smallint	8
fach_zaehler	Maximale Anzahl der Fächer, die für einen Studiengang gezählt werden. Wird nur für die Kapazitätsberechnung verwandt	smallint	2
tid	Primärschlüssel des Studiengangs (Laufnummer)	integer	530043
semester_von	Gültigkeit des Studiengangs: Startsemester	integer	19881
semester_bis	Gültigkeit des Studiengangs: Letztes Semester	integer	29992
stort	Standort	char(4)	ES
anteil	Grad des Anteils, mit dem ein Studiengang einer Lehreinheit zugeordnet wird (wird derzeit noch nicht ausgewertet)	decimal(3,2)	1.00

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.

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 muss 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.

Umgang mit Änderungen im Vorsystem

Wenn die initiale Datenübernahme aus SOS/COB/STU passiert ist, ist nun die Frage wie mit Änderungen umgegangen wird. Wenn die Lehreinheiten/Regelstudienzeiten aus SOS/STU 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 (sospos) bzw. course_of_study (HISinOne-STU) direkt übernommen.
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 angepasst 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, dass 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/STU gelöschte Studiengänge bleiben in SuperX erhalten, damit sie in Zeitreihenstatistiken weiterhin ausgewertet werden können.

Studiengangnamen: Herkunft und Änderung

Die Studiengangnamen werden bei der ersten Übernahme eines Studiengangs aus dem Vorsystem automatisch zusammengesetzt aus den Bezeichnungstexten (Drucktexten) von

Fach
Vertiefung
Schwerpunkt
Abschluss
Fachkennzeichen
Prüfungsordnungs-Version
Schwerpunkt

Diese Namen beschreiben Studiengänge sehr detailliert, ggf. wollen Sie die Namen ändern. Sie können dies mit der unten beschriebenen Maske tun.

Studiengangnamen können im Data Warehouse geändert werden, sie werden nur bei der initialen Übernahme vergeben.

Wenn zum Zeitpunkt der ersten Übernahme eines Studiengangs in den jew. Stammdaten-Tabellen ein Bezeichungstext fehlt, finden Sie im Studiengangnamen den Passus "Unbekannte xxx (yyy)", wobei xxx die obigen Werte Fach, Vertiefung etc. haben kann, und yyy den Schlüssel. Sie können diesen Text dann später ändern. Für Massen-Verarbeitung können Sie auch das mitgelieferte SQL-Script

.../db/module/sos/schluesseltabellen/lehr_stg_ab_text_reset.sql

ausführen. Dieses setzt die Namen auf obiges Namensschema zurück.

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 Studienganges suchen.

Datei:lehr stg ab maske.png

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

Datei:lehr stg ab tabelle.png

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

Datei:lehr stg ab bearbeiten.png

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

Tabelle dim_studiengang (Studiengänge)

Dimensionstabelle Studiengang mit diversen Levels für OLAP und Datenblätter, ist erst ab HISinOne Version 6.0 oder SuperX-SOS-Modul 1.0 verfügbar

Typ: Schlüsseltabelle, Themenbereich: Studierende

Feldname	Feldtyp	Größe	Default	Not Null	Beschreibung	Kommentar	Fremdschlüssel
tid	INTEGER	5		true	Laufnummer
stg	CHAR	10		false	Fach (Schlüssel)
stg_str	VARCHAR	255		false	Fach
stg_ktxt	VARCHAR	255		false	Fach Kurztext
stg_ltxt	VARCHAR	255		false	Fach Langtext
stg_astat	CHAR	10		false	Fach amtlich (Schlüssel)
stg_astat_str	VARCHAR	255		false	Fach amtlich
stg_astgrp	CHAR	10		false	Fächergruppe amtlich (Schlüssel)
stg_astgrp_str	VARCHAR	255		false	Fächergruppe amtlich
vertfg	CHAR	10		false	Vertiefung (Schlüssel)	Leeres Feld= (nicht null)
vertfg_str	VARCHAR	255		false	Vertiefung
schwerpunkt	CHAR	10		false	Schwerpunkt (Schlüssel)	Leeres Feld=
schwerpunkt_str	VARCHAR	255		false	Schwerpunkt
pversion	INTEGER	2		false	Prüfungsordnungsversion	Leeres Feld=-1
kz_fach	CHAR	10		false	Fachkennzeichen (Schlüssel)	Haupt/Nebenfach
kz_fach_str	VARCHAR	255		false	Fachkennzeichen
abschluss	CHAR	10		false	Abschluss (intern) (Schlüssel)
abschluss_str	VARCHAR	255		false	Abschluss (intern)
abschluss_astat	CHAR	10		false	Abschluss amtlich (Schlüssel)
abschluss_astat_str	VARCHAR	255		false	Abschluss amtlich
abschlussart	CHAR	10		false	Abschlussart (Schlüssel)
abschlussart_str	VARCHAR	255		false	Abschlussart
abschluss_grp	CHAR	10		false	Abschluss gruppiert (Schlüssel)	BA, MA, LA
abschluss_grp_str	VARCHAR	255		false	Abschluss gruppiert
text	VARCHAR	255		false	Studiengangstext
regel	DECIMAL	(4,2)		false	Regelstudienzeit
semester_von	INTEGER	4		true	Gültigkeit des Studiengangs: Startsemester	(Das Feld wird derzeit noch nicht ausgewertet.)
semester_bis	INTEGER	4		true	Gültigkeit des Studiengangs: Letztes Semester	(Das Feld wird derzeit noch nicht ausgewertet.)
stort	CHAR	10		false	Standort (Schlüssel)
stort_str	VARCHAR	255		false	Standort
fb	CHAR	10		false	Fakultät/Fachbereich (Schlüssel)
fb_str	VARCHAR	255		false	Fakultät/Fachbereich
lehr	CHAR	10		true	Lehreinheit (Schlüssel)
lehr_str	VARCHAR	255		false	Lehreinheit

Tabellen cif / cifx / sos_cifx

Sie finden eine Übersicht unter Schluesseltabellen cif - HISinOne-BI

semester

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

Feld	Erläuterung	Typ
tid	interne Nummer	integer
eintrag	Semestertext	char(10)
sem_beginn	Datum Semesterbeginn	date
sem_ende	Datum Semesterende	date
stichtag	Datum Stichtag	date

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" (Status = 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 dem Vorsystem ü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 im Vorsystem.

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:

tid	apnr	eintrag
1	hrst='H' and kz_rueck_beur_ein!=4	HH o.Beurl.
2	hrst='H'	HH m.Beurl.
3	1=1	alle
5	hrst='P'	Promovend
6	hrst='G'	Gasthörer

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:

tid	apnr	eintrag
7	hrst !='N' and hrst != 'P'	Alle ohne Nebenhörer und ohne Promovenden

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).

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 Übernahme 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.

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 Status 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).

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.

Konstanten

Die Tabelle Konstanten ist in der Studierenden-Komponente sehr wichtig, denn hier werden verschiedene Parameter gesetzt. Die folgende Abbildung zeigt die Bearbeitungsmaske:

Datei:konstanten.png

Feste Konstanten

Die enthält u.a. das erste Semester, zu dem SOS-Daten vorliegen. Dieses Semester läßt sich wie folgt abrufenSELECT apnr FROM konstanten WHERE beschreibung = 'Start_SOS_Semester';

Die Voreinstellung ist das SoSe 1988. Das Startsemester für POS-Daten lautet entsprechend:SELECT apnr FROM konstanten WHERE beschreibung = 'Start_POS_Semester';

Und das letzte Semester, wo noch keine Lehramtsprüfungen vorlagen, lautet SELECT apnr FROM konstanten WHERE beschreibung = 'Start_LA_Pruef_Semester';

Wichtig ist auch die Kennzeichnung des Attributs Geschlecht:mann = (SELECT apnr FROM konstanten WHERE tid = 1);frau = (SELECT apnr FROM konstanten WHERE tid = 2)

sowie der Nationalität:deutsch = (SELECT apnr FROM konstanten WHERE tid = 3)

und des Kennzeichens für den Rückmeldestatus::

exmat = (SELECT apnr FROM konstanten WHERE tid = 5)rueckmeldung = (SELECT apnr FROM konstanten WHERE tid = 4)

Stichtage

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

Nr.	Name	Art des Stichtags	Gültig von	Gültig bis	Application key
1	Amtl. Statistik Land	Studierende	01.01.00	30.09.99	1
6	Aktuelle Zahlen	Studierende	01.01.00	30.09.99	0
2	Aktuelle Zahlen	Prüfungen	01.01.00	30.09.99	2
4	Amtl. Statistik Land (Prüf.)	Prüfungen	01.01.00	30.09.99	4
5	Semesterbezogene Zählung	Prüfungen	01.01.00	30.09.99	5
6	Studierendenstatistik (Land)	Studierende	01.01.00	30.09.99	6

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)

Wenn Stichtage manuell geändert werden, ist zu prüfen, ob der Stichtag aus dem Vorsystem übertragen wird, also beim Lauf des Konnektor wieder überschrieben wird.

(Konstante 'semester_aus_SOS' ist 1: Daten werden aus Vorsystem übertragen)

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 Basissystem entladen und übernommen. Weitere Schlüsseltabellen für SuperX:

koepfe_oder_faelle	Diese Tabelle spezifiziert, ob nur das Erstfach oder alle weiteren Einschreibungen eines Studierenden gezählt werden.
sos_gewichtung	Wenn in koepfe_oder_faelle gewichtete Fälle gewählt werden, steht hier die Gewichtung der Abschlüsse.
lehreinheit_fb	Diese Tabelle liefert eine Zuordnung von einer Lehreinheitsnummer zum Fachbereich/zur Fakultät.
studienabschnitt	Der Studienabschnitt im Volltext (Grund-/Hauptstudium)
sos_stichtag	Wird in zukünftigen Versionen des SOS-Moduls zur Vorhaltung mehrerer Stichtage pro Semester genutzt.

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.

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.

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

sos_sos
sos_lab
sos_stg

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

Konstanten (das erste Semester, zu dem SOS-Daten vorliegen)
k_hzbart. (Eine Schlüsseltabelle mit den Hochschulzugangsberechtigungen)
lehr_stg_ab (Die Zuordnung der Studiengänge einer Hochschule zu den Lehreinheiten der Hochschule)
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:

sos_lab_aggr

Die Hilfstabelle sos_lab_aggr enthält die aggregierten Prüfungssätze. Sie greift auf die Zwischentabelle sos_lab_stg zu, 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.

Maskenentwicklung im SOS-Modul

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, dass 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":

Ausgabe

Fach
Studiengang

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:

Codebeispiel

Maskenfelder

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:

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:

Datei:rs faecher intern.png

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:

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:

Datei:rs studiengaenge liste.png

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:

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:

Datei:rs studiengaenge fak fach abschl.png

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

Datei:rs studiengaenge fak fach abschl gui.png

Ergebnistabelle

In der Maske Studierende und Studienanfänger/-innen nach Geschlecht wird zunächst die temp. Tabelle mit den Basisdaten erzeugt. Hier werden die 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>

In der Variablen "loopElem" ist entweder der Baum im Button "Fächer" oder im Button "Studiengänge" vorbelegt. Der Name "loopElem" soll andeuten, dass ü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>

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, dass

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 passt 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.).

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.

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:

Datei:btn studiengang liste.png

Kostenstellen-Sichten

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

Ein Standardfall ist die Zuordnung von Benutzerinnen und 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:

Datei:btn studiengang fb fak stg.png

Archivierung

Optionen für Verarbeitung von Daten archivierter Studierender

Verfügbar ab Version

{{{1}}} {{{2}}}

Nachfolgend finden Sie die Dokumentation der Konfigurationsmöglichkeiten in der HISinOne-BI, um auf die Archivierung in STU zu reagieren.

Auslieferungszustand

Im Auslieferungszustand nach dem Update auf die Version 2022.12 werden von HISinOne Informationen gesammelt, welche Studierenden in STU archiviert worden sind. Folgende Möglichkeiten bestehen, um in der HISinOne-BI darauf zu reagieren:

Bei einem Konnektorlauf der Komponente Studierende, Prüfungen werden die Daten in der HISinOne-BI, die zu den in STU archivierten Studierenden gehören,

0 = nicht verändert (Default),
1 = aus der HISinOne-BI-Datenbank gelöscht.

Für die Konfiguration des Verhaltens gibt es eine Konstante SOS_ARCHIVDATA_LOESCHEN, die entsprechend zwei Werte annehmen kann.

0 (default): Informationen zu den in STU archivierten Studierenden werden in der HISinOne-BI protokolliert, die bestehenden HISinOne-BI-Daten zu den Studierenden werden bei einem Konnektorlauf nicht verändert.
1: Informationen zu den in STU archivierten Studierenden werden in der HISinOne-BI protokolliert, die bestehenden HISinOne-BI-Daten zu den Studierenden werden bei einem Konnektorlauf gelöscht!

Verhalten bei nachträglicher Änderung der Konstanten

Zum Ändern der Konstante folgen Sie dieser Beschreibung:

Konstanten

Nachträgliches Aktivieren der Archivierung: Änderung der Konstanten von '0' auf '1'; Haben Sie das System schon einige Zeit in der Konfiguration SOS_ARCHIVDATA_LOESCHEN=0 betrieben und es wurden Studierende in STU archiviert, wurden die entsprechenden Informationen zu diesen Studierenden in die HISinOne-BI übertragen. Ändern Sie nun die Konfiguration der Konstanten von 0 auf 1 und führen den Konnektor Studierende, Prüfungen aus, so werden die Daten aller bisher archivierten Studierenden in der HISinOne-BI gelöscht.

Nachträgliches Deaktivieren der Archivierung: Änderung der Konstanten von '1' auf '0'; Haben Sie das System schon einige Zeit in der Konfiguration SOS_ARCHIVDATA_LOESCHEN=1 betrieben, wurden mit jedem Konnektorlauf der Komponente Studierende, Prüfungen die archivierten Studierenden in der HISinOne-BI gelöscht. Nach Änderung der Konstanten wird in der HISinOne-BI nur noch protokolliert, welche Studierenden in STU archiviert werden. Führen Sie den Konnektor Studierende, Prüfungen aus, so bleiben die Daten der Studierenden unangetastet.

Anhang

Zuordnung von Studienbereichen und Lehr- und Forschungsbereichen

Die Fächer-Sichten "Studienbereich und Fach (intern)" sowie "Lehr- und Forschungsbereich und Fach (intern)" sind nicht in HISSOS enthalten und werden über Zusatztabellen generiert. Die Brücke zu den Studienbereichen und LFBs wird über die Zuordnung der hochschulinternen Studienfächer in k_stg zu den Fachrichtungen der Gasthörerstatistik im Feld astfr geschlagen. Folgende manuell im SOS-Modul vorbereitete Tabelle wird dabei zugrunde gelegt^[1]:

FR	Fachrichtung der Gasthörerstatistik FR Text	StB	StudienbereichStB Text	LuF	Lehr- und ForschungsbereichLuF Text
01	Sprach- und Kulturwissenschaften allgemein	01	Sprach- und Kulturwissenschaften allgemein	10	Sprach- und Kulturwissenschaften allgemein
02	Evang.Theologie -Religionslehre	02	Evang.Theologie -Religionslehre	20	Evang. Theologie
03	Kath. Theologie, -Religionslehre	03	Kath. Theologie, -Religionslehre	30	Kath. Theologie
04	Philosophie	04	Philosophie	40	Philosophie
05	Geschichte	05	Geschichte	50	Geschichte
07	Bibliothekswissenschaft, Dokumentation, Publizistik	06	Bibliothekswissenschaft, Dokumentation, Publizistik	70	Bibliothekswissenschaft, Dokumentation, Publizistik
08	Allgemeine und vergleichende Literatur- und Sprachwissenschaft	07	Allgemeine und vergleichende Literatur- und Sprachwissenschaft	80	Allgemeine und vergleichende Literatur- und Sprachwissenschaft
09	Altphilologie (klass. Philologie), Neugriechisch	08	Altphilologie (klass. Philologie), Neugriechisch	90	Altphilologie (klass. Philologie)
10	Germanistik (Deutsch, germanische Sprachen ohne Anglistik)	09	Germanistik (Deutsch, germanische Sprachen ohne Anglistik)	100	Germanistik (Deutsch, germanische Sprachen ohne Anglistik)
11	Anglistik, Amerikanistik	10	Anglistik, Amerikanistik	110	Anglistik, Amerikanistik
12	Romanistik	11	Romanistik	120	Romanistik
13	Slawistik, Baltistik, Finno-Ugristik	12	Slawistik, Baltistik, Finno-Ugristik	130	Slawistik, Baltistik, Finno-Ugristik
14	Außereuropäische Sprach- und Kulturwissenschaften	13	Außereuropäische Sprach- und Kulturwissenschaften	140	Sonstige/Außereuropäische Sprach- und Kulturwissenschaften
16	Kulturwissenschaften i.e.S.	14	Kulturwissenschaften i.e.S.	160	Kulturwissenschaften i.e.S.
17	Psychologie	15	Psychologie	170	Psychologie
18	Erziehungswissenschaften	16	Erziehungswissenschaften	180	Erziehungswissenschaften
19	Sonderpädagogik	17	Sonderpädagogik	190	Sonderpädagogik
20	Sport, Sportwissenschaft	22	Sport, Sportwissenschaft	200	Sport
22	Wirtschafts- und Gesellschaftslehre allgemein	23	Wirtschafts- und Gesellschaftslehre allgemein	220	Rechts-, Wirtschafts- und Sozialwissenschaften allgemein
21	Regionalwissenschaften	24	Regionalwissenschaften	225	Regionalwissenschaften (soweit nicht einzelnen Lehr- und Forschungsbereichen oder anderen
23	Politikwissenschaften	25	Politikwissenschaften	230	Politikwissenschaften
26	Sozialwissenschaften	26	Sozialwissenschaften	235	Sozialwissenschaften
24	Sozialwesen	27	Sozialwesen	240	Sozialwesen
25	Rechtswissenschaft	28	Rechtswissenschaft	250	Rechtswissenschaften
27	Verwaltungswissenschaft	29	Verwaltungswissenschaft	270	Verwaltungswissenschaft
29	Wirtschaftswissenschaften	30	Wirtschaftswissenschaften	290	Wirtschaftswissenschaften
31	Wirtschaftsingenieurwesen	31	Wirtschaftsingenieurwesen	310	Wirtschaftsingenieurwesen
33	Mathematik, Naturwissenschaften allgemein	36	Mathematik, Naturwissenschaften allgemein	330	Mathematik, Naturwissenschaften allgemein
34	Mathematik	37	Mathematik	340	Mathematik
35	Informatik	38	Informatik	350	Informatik
36	Physik, Astronomie	39	Physik, Astronomie	360	Physik, Astronomie
37	Chemie	40	Chemie	370	Chemie
39	Pharmazie	41	Pharmazie	390	Pharmazie
40	Biologie	42	Biologie	400	Biologie
41	Geowissenschaften (ohne Geographie)	43	Geowissenschaften (ohne Geographie)	410	Geowissenschaften (ohne Geographie)
42	Geographie	44	Geographie	420	Geographie
48	Gesundheitswissenschaften (allgemein)	48	Gesundheitswissenschaften (allgemein)	445	Gesundheitswissenschaften allgemein
44	Humanmedizin (ohne Zahnmedizin)	49	Humanmedizin (ohne Zahnmedizin)	450	Vorklinische Humanmedizin (einschl. Zahnmedizin)
44	Humanmedizin (ohne Zahnmedizin)	49	Humanmedizin (ohne Zahnmedizin)	470	Klinisch-TheoretischeHumanmedizin (einschl. Zahnmedizin)
44	Humanmedizin (ohne Zahnmedizin)	49	Humanmedizin (ohne Zahnmedizin)	490	Klinisch-Praktische Humanmedizin (ohne Zahnmedizin)
52	Zahnmedizin	50	Zahnmedizin	520	Zahnmedizin (klinisch-praktisch)
54	Veterinärmedizin	51	Veterinärmedizin	540	Veterinärmedizin allgemein
54	Veterinärmedizin	51	Veterinärmedizin	550	Vorklinische Veterinärmedizin
54	Veterinärmedizin	51	Veterinärmedizin	560	Klinisch-Theoretische Veterinärmedizin
54	Veterinärmedizin	51	Veterinärmedizin	580	Klinisch-Praktische Veterinärmedizin
61	Agrar-, Forst- und Ernährungswissenschaften allgemein	-99	Außerhalb der Studienbereichsgliederung	610	Agrar-, Forst- und Ernährungswissenschaften allgemein
63	Landespflege, Umweltgestaltung	57	Landespflege, Umweltgestaltung	615	Landespflege, Umweltgestaltung
62	Agrarwissenschaften, Lebensmittel- und Getränketechnologie	58	Agrarwissenschaften, Lebensmittel- und Getränketechnologie	620	Agrarwissenschaften, Lebensmittel- und Getränketechnologie
64	Forstwissenschaft, Holzwirtschaft	59	Forstwissenschaft, Holzwirtschaft	640	Forstwissenschaft, Holzwirtschaft
65	Ernährungs- und Haushaltswissenschaften	60	Ernährungs- und Haushaltswissenschaften	650	Ernährungs- und Haushaltswissenschaften
67	Ingenieurwesen allgemein	61	Ingenieurwesen allgemein	670	Ingenieurwissenschaften allgemein
68	Bergbau, Hüttenwesen	62	Bergbau, Hüttenwesen	680	Bergbau, Hüttenwesen
69	Maschinenbau/Verfahrenstechnik	63	Maschinenbau/Verfahrenstechnik	690	Maschinenbau/Verfahrenstechnik
71	Elektrotechnik	64	Elektrotechnik	710	Elektrotechnik
72	Verkehrstechnik, Nautik	65	Verkehrstechnik, Nautik	720	Verkehrstechnik, Nautik
73	Architektur, Innenarchitektur	66	Architektur, Innenarchitektur	730	Architektur
74	Raumplanung	67	Raumplanung	740	Raumplanung
75	Bauingenieurwesen	68	Bauingenieurwesen	750	Bauingenieurwesen
76	Vermessungswesen	69	Vermessungswesen	760	Vermessungswesen
78	Kunst, Kunstwissenschaft allgemein	74	Kunst, Kunstwissenschaft allgemein	780	Kunst, Kunstwissenschaft allgemein
79	Bildende Kunst	75	Bildende Kunst	790	Bildende Kunst
80	Gestaltung	76	Gestaltung	800	Gestaltung
82	Darstellende Kunst, Film und Fernsehen, Theaterwissenschaft	77	Darstellende Kunst, Film und Fernsehen, Theaterwissenschaft	820	Darstellende Kunst, Film und Fernsehen, Theaterwissenschaft
83	Musik, Musikwissenschaft	78	Musik, Musikwissenschaft	830	Musik, Musikwissenschaft
98	Allgemein (Allg. Zugang zu Lehrveranstaltungen, daher FR nicht bestimmbar)	83	Außerhalb der Studienbereichsgliederung	870	Hochschule insgesamt
98	Allgemein (Allg. Zugang zu Lehrveranstaltungen, daher FR nicht bestimmbar)	83	Außerhalb der Studienbereichsgliederung	880	Zentrale Hochschulverwaltung
98	Allgemein (Allg. Zugang zu Lehrveranstaltungen, daher FR nicht bestimmbar)	83	Außerhalb der Studienbereichsgliederung	900	Zentralbibliothek
98	Allgemein (Allg. Zugang zu Lehrveranstaltungen, daher FR nicht bestimmbar)	83	Außerhalb der Studienbereichsgliederung	920	Zentrale wissenschaftliche Einrichtungen
98	Allgemein (Allg. Zugang zu Lehrveranstaltungen, daher FR nicht bestimmbar)	83	Außerhalb der Studienbereichsgliederung	930	Zentrale Betriebs- und Versorgungseinrichtungen
98	Allgemein (Allg. Zugang zu Lehrveranstaltungen, daher FR nicht bestimmbar)	83	Außerhalb der Studienbereichsgliederung	940	Soziale Einrichtungen
98	Allgemein (Allg. Zugang zu Lehrveranstaltungen, daher FR nicht bestimmbar)	83	Außerhalb der Studienbereichsgliederung	950	Übrige Ausbildungseinrichtungen
98	Allgemein (Allg. Zugang zu Lehrveranstaltungen, daher FR nicht bestimmbar)	83	Außerhalb der Studienbereichsgliederung	960	Mit der Hochschule verbundene sowie hochschulfremde Einrichtungen
98	Allgemein (Allg. Zugang zu Lehrveranstaltungen, daher FR nicht bestimmbar)	83	Außerhalb der Studienbereichsgliederung	970	Kliniken insgesamt, Zentrale Dienste
98	Allgemein (Allg. Zugang zu Lehrveranstaltungen, daher FR nicht bestimmbar)	83	Außerhalb der Studienbereichsgliederung	980	Soziale Einrichtungen der Kliniken
98	Allgemein (Allg. Zugang zu Lehrveranstaltungen, daher FR nicht bestimmbar)	83	Außerhalb der Studienbereichsgliederung	986	Übrige Ausbildungseinrichtungen der Kliniken
98	Allgemein (Allg. Zugang zu Lehrveranstaltungen, daher FR nicht bestimmbar)	83	Außerhalb der Studienbereichsgliederung	990	Mit den Kliniken verbundene sowie klinikfremde Einrichtungen
	Quelle: StBA VI E, WS 2005/06 und SS 2006 (StaLa-Download)		Quelle: StBA-Download, Stand: WS 2004/05		Quelle: StBA, Fachserie 11, R.4.4, 2004

↑ ^{Vielen Dank an Frau Zeller, Uni Freiburg.}

[ftn5-1] {Vielen Dank an Frau Zeller, Uni Freiburg.}

[1]