Kategorie:Business Intelligence Analysen-Dokumentation
Kategorie:HISinOne-Dokumentation
Die Installation des SOS-Moduls unterscheidet sich zwischen HISinOne und SuperX. Daher gibt es zu jedem System eine eigene Installationsseite:
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.
Bei Studierenden-Daten (Tab. sos) müssen folgende Felder gepflegt sein:
Bei Fachbelegungen müssen mindestens folgende Daten gepflegt sein:
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:
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.
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:
"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.
Zunächst müssen die Rohdaten aus SOS entladen werden. Danach wird die Umgebung eingerichtet, und das Modul kann installiert werden.
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:
Für das Entladen gibt es ferner zwei Modi: Das "Pull"-Verfahren und das "Push"-Verfahren.
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.
Eine Übersicht über die Entladeparameter finden Sie hier: Entladeparameter Studierende / Prüfungen
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 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 bei Tabelle student in HISinOne-STU ). 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 to_number(S.registrationnumber,repeat('9',length(S.registrationnumber)))::integer > 100000 Dieser Filter sorgt dafür, dass nur Studierende mit Matrikelnummern größer als 100000 geladen werden. | ||
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). |
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:
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 <>
Es gibt zwei Unterladeroutinen, die jeweils aus EXA, POS und CO laden können. So kann z.B. das gängige Szenario abgebildet werden, dass einige Prüfungen von neuen Prüfungsordnungen aus EXA kommen, und ältere Prüfungen aus POS.
Beachten Sie bitte dafür folgende Vorannahmen:
... de.his.edustore.modules.WebFrontendForModuleUpdate sos:trans_pruefungen_1_hisinone ... ) Beim kombinierten Laden von Prüfungen aus EXA und POS kann es leicht zu Duplikaten in der BI kommen, wenn Prüfungen auch im Vorsystem von POS nach EXA migriert werden oder umgekehrt. Hier muss also eine Abstimmung mit der jew. Abteilung der Prüfungsverwaltung getroffen werden. Ein häufiges Szenario ist, dass Hauptprüfungen nach POS nach EXA migriert werden, Einzelprüfungen aber nicht. Wenn sichergestellt ist, dass alle Hauptprüfungen von POS nach EXA migriert werden, können Sie den Entladeparameter LAB_FILTER auf "and pnr != 9000" (wenn die 9000 bei Ihnen in POS für Hauptprüfung steht, ggf. ändern Sie das) setzen. Das klappt ganz gut, weil damit generell die Hauptprüfungen aus POS nicht geladen werden, egal ob HLR oder ULR.
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:
--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"/>
<!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));
--soll überhaupt geändert werden? select count(*) from mtknr_ldsg where mtknr=mtknr_ldsg;
<#if anzahl_echte_mtknr=0<#if anzahl_echte_mtknr=0>
create schema tmp_backup_mtknr;
begin work;
<#foreach feld in tabellen<#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);
commit; --wird die Tabelle mtknr_ldsg direkt ent-peudonymisiert begin work; update mtknr_ldsg set mtknr_ldsg = mtknr; commit;
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:
----