Kategorie:Business Intelligence Analysen-Dokumentation
Kategorie:HISinOne-Dokumentation
Einladen der Studierenden- und Prüfungsdaten
Die Laderoutinen eines Moduls unterscheiden sich zwischen HISinOne und Superx. Daher gibt es zu jedem System eine eigene Anleitungsseite:
Generell gilt: Vor dem Start der Laderoutine sollten Sie die Entladeparameter und weitere Einstellungen (z.B. Konstanten) konfigurieren.
Nach dem ersten Update sollten Sie stichprobenartig die Gültigkeit der Studierenden- und Absolventenstatistik prüfen. Das erste Ziel sollte sein die Gesamtzahlen möglichst ohne spezielle Filter zu vergleichen, damit Sie die potentiellen Fehlerquellen möglichst gering halten.
Im Folgenden wird gezeigt, wie Sie einzelne Suchanfragen aus HISinOne-STU, SOS-GX und POS-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
Wählen Sie z.B. die BI-Maske " Studierende nach Alter" mit
In der ersten Zeile in der Spalte "Gesamtzahl" erhalten Sie die Gesamtsumme.
Um diese Zahl in HISinOne zu reproduzieren, führen Sie folgende Selektion aus:
SELECT count(*)
FROM period P,
term_type T,
degree_program_progress DP,
degree_program D,
student S
WHERE T.id=P.term_type_id
and D.id=DP.degree_program_id
and DP.period_id=P.id
and S.id=D.student_id
--Ab HISinOne 6.0: keine vorläufigen Studierenden:
and 0=(select count(*) from orgrole O, role R
where R.id=O.role_id
and S.person_id=O.person_id
and R.hiskey_id = 6)
--SoSe 2018:
AND to_number( ' ' || P.term_year || T.termnumber,'99999') = 20181
--Köpfe:
and DP.studynumber=1
and DP.subjectnumber=1
;
Wenn es Differenzen gibt, können Sie auch einzelne Matrikelnr. abgleichen:
SELECT S.registrationnumber
FROM period P,
term_type T,
degree_program_progress DP,
degree_program D,
student S
WHERE T.id=P.term_type_id
and D.id=DP.degree_program_id
and DP.period_id=P.id
and S.id=D.student_id
--Ab HISinOne 6.0: keine vorläufigen Studierenden:
and 0=(select count(*) from orgrole O, role R
where R.id=O.role_id
and S.person_id=O.person_id
and R.hiskey_id = 6)
--SoSe 2018:
AND to_number( ' ' || P.term_year || T.termnumber,'99999') = 20181
--Köpfe:
and DP.studynumber=1
and DP.subjectnumber=1
order by 1
;
Diese Liste können Sie im Studierenden-Datenblatt reproduzieren:
Diese Liste können Sie dann mit dem "Tabelle editieren"-Button sortieren und z.B. nach Excel ausgeben.
Sie können auch die Studierenden nach Studienfach (Schlüssel) ausgeben:
SELECT F.uniquename,
count(*)
FROM period P,
term_type T,
degree_program_progress DP,
degree_program D,
student S,
course_of_study C ,
subject F
WHERE T.id=P.term_type_id
and D.id=DP.degree_program_id
and DP.period_id=P.id
and S.id=D.student_id
and DP.course_of_study_id=C.id
and F.lid=C.subject_lid
and (F.valid_from <= C.valid_from
or F.valid_from is null
or ( F.valid_from is null and C.valid_from is null)
)
and (F.valid_to >= C.valid_to
or F.valid_to is null
or ( F.valid_from is null and C.valid_from is null)
)
--Ab HISinOne 6.0 keine vorläufigen Studierenden:
and 0=(select count(*) from orgrole O, role R
where R.id=O.role_id
and S.person_id=O.person_id
and R.hiskey_id = 6)
--SoSe 2018:
AND to_number( ' ' || P.term_year || T.termnumber,'99999') = 20181
--Köpfe:
and DP.studynumber=1
and DP.subjectnumber=1
group by 1
order by 1
Die Liste können Sie im Studierenden-Datenblatt reproduzieren, indem Sie im Feld "Weitere Tabellen" die Tabelle "Studiengänge" wählen und im Feld "Felder" dann die Felder Fach und Summe wählen. Das Ergebnis müssen Sie dann noch nach dem Fach (Schlüssel) sortieren.
Abschnitt ist in Überarbeitung !
Das System wertet den Status von Studierenden bei tagesaktueller Zählung wie folgt aus:
Alle anderen Stati werden unverändert aus der Tabelle degree_program_progress übernommen.
Die folgende Selektion ermittelt den Status der Studierenden (eingeschrieben, rückgemeldet etc.) nach der gleichen Logik wie es unten für SOSPOS beschrieben ist.
--nicht exmatrikuliert im akt. Semester:
SELECT K.astat,K.defaulttext,
count(*)
FROM period P,
term_type T,
degree_program D,
student S,
degree_program_progress DP
left outer join k_studystatus K
on (K.id=DP.k_studystatus_id)
WHERE T.id=P.term_type_id
and D.id=DP.degree_program_id
and DP.period_id=P.id
and S.id=D.student_id
AND to_number( ' ' || P.term_year || T.termnumber,'99999') = 20181 --Semester
and DP.studynumber=1 --Köpfe
and DP.subjectnumber=1 --Köpfe
--nicht exmatrikuliert:
and (DP.finished is null
or DP.finished > current_date --oder nach Ladedatum exmatrikuliert
--der Studi ist ein Wechsler,d.h. das Semester des DP-Satzes ist höher:
or (DP.finished is not null and 0< (select count(*) from degree_program_progress DP2,degree_program D2, period P2, term_type T2
where D2.student_id=D.student_id
and DP2.period_id=P2.id
and T2.id=P2.term_type_id
and D2.id=DP2.degree_program_id
and to_number( ' ' || P2.term_year || T2.termnumber,'99999') > to_number( ' ' || P.term_year || T.termnumber,'99999'))
)
--Das Enddatum liegt am Ende des Sem. oder höher, d.h. er hat bis Semesterende studiert
or DP.finished >=P.enddate
)
and current_date <= P.enddate --Bedingung für akt. Semester
group by 1,2
union
--nicht exmatrikuliert in früheren Semestern:
SELECT K.astat,K.defaulttext,
count(*)
FROM period P,
term_type T,
degree_program D,
student S,
degree_program_progress DP
left outer join k_studystatus K
on (K.id=DP.k_studystatus_id)
WHERE T.id=P.term_type_id
and D.id=DP.degree_program_id
and DP.period_id=P.id
and S.id=D.student_id
AND to_number( ' ' || P.term_year || T.termnumber,'99999') = 20181
and DP.studynumber=1
and DP.subjectnumber=1
and (DP.finished is null
or DP.finished > current_date --oder nach Ladedatum exmatrikuliert
--der Studi ist ein Wechsler,d.h. das Semester des DP-Satzes ist höher:
or (DP.finished is not null and 0< (select count(*) from degree_program_progress DP2,degree_program D2, period P2, term_type T2
where D2.student_id=D.student_id
and DP2.period_id=P2.id
and T2.id=P2.term_type_id
and D2.id=DP2.degree_program_id
and to_number( ' ' || P2.term_year || T2.termnumber,'99999') > to_number( ' ' || P.term_year || T.termnumber,'99999'))
)
)
--nur für alte Semester
and current_date > P.enddate
group by 1,2
--exmatrikuliert im akt. Sem.:
union
SELECT '5','Exmatrikuliert',
count(*)
FROM period P,
term_type T,
degree_program D,
student S,
degree_program_progress DP
left outer join k_studystatus K
on (K.id=DP.k_studystatus_id)
WHERE T.id=P.term_type_id
and D.id=DP.degree_program_id
and DP.period_id=P.id
and S.id=D.student_id
AND to_number( ' ' || P.term_year || T.termnumber,'99999') = 20181
and DP.studynumber=1
and DP.subjectnumber=1
and DP.finished is not null --exmatrikuliert
and DP.finished <= current_date --Wenn jemand erst nach dem Ladedatum exm. wird
--and S.k_reason_of_finishing_id is not null
and DP.finished < P.enddate
--nur fürs akt. Sem. oder zukünftige
and current_date <= P.enddate
group by 1,2
--examtrikuliert im früheren Sem.:
union
SELECT '5','Exmatrikuliert',
count(*)
FROM period P,
term_type T,
degree_program D,
student S,
degree_program_progress DP
left outer join k_studystatus K
on (K.id=DP.k_studystatus_id)
WHERE T.id=P.term_type_id
and D.id=DP.degree_program_id
and DP.period_id=P.id
and S.id=D.student_id
AND to_number( ' ' || P.term_year || T.termnumber,'99999') = 20181
and DP.studynumber=1
and DP.subjectnumber=1
--Das Endedatum liegt vor dem Ende des Sem.., d.h. er hat nicht bis Semesterende studiert:
and DP.finished < P.enddate
--vor dem Ladedatum exm:
and DP.finished <= current_date
--nur für alte Semester
and current_date > P.enddate
--Keine Wechsler rein ,d.h. das Semester des DP-Satzes ist das letzte:
and 0=(select count(*) from degree_program_progress DP2,degree_program D2, period P2, term_type T2
where D2.student_id=D.student_id
and DP2.period_id=P2.id
and T2.id=P2.term_type_id
and D2.id=DP2.degree_program_id
and to_number( ' ' || P2.term_year || T2.termnumber,'99999') > to_number( ' ' || P.term_year || T.termnumber,'99999'))
group by 1,2
order by 1
;
Dies ergibt z.B: bei den Musterdaten HISinOne 2018.06.10537
| Status (Amtlich) | Status (Bezeichnung) | Anzahl | |||
|---|---|---|---|---|---|
1 | Ersteinschreibung | 65 | |||
2 | Neueinschreibung | 12 | |||
3 | Rückmeldung | 382 | |||
4 | Beurlaubung | 8 | |||
5 | Exmatrikuliert | 4 |
Die gleiche Tabelle können Sie mit dem Studierenden-Datenblatt reproduzieren:
In der Rolle STU-Seniormanager/-in erreichen Sie über Startseite > Studierendenmanagement > Studierende den Dialog "Studierendendaten bearbeiten". Im Fieldset "Studiengänge suchen" unten links können zahlreiche Selektionsparameter eingetragen werden, um eine Suche nach Fachfällen oder Köpfen (z.B. Fachnummer=1 und Studiengangnummer=1 ) analog zum BI-Datenblatt durchzuführen.
Je nachdem was hier eingegeben wird, verhält sich der Export völlig unterschiedlich. Mit HISinOne-BI vergleichbar ist nur die Option, dass "erst ab Stichtag"+ dem Wert, der in der Tabelle sossys im Feld stistat angegeben wird, gewählt wird. Im Folgenden ein Beispiel:
Admin-Komponente Studierende-Datenvalidierung SOSPOS-GX-HISinOne-BI
Um die Statistikgenerierung aus SOSPOS mit den von HISinOne-BI bei stichtagsbezogenen Daten abzugleichen, nutzen Sie in eine beliebige Studierenden-Abfrage und schränken Sie ein auf
Insgesamt zeigen sich ein paar kleine Unterschiede in den Formeln zur Statistikberechnung. Da BSOS die Felder Status und Datum der Exmatrikulation in der Tabelle sos auswertet, können die Statistiken nur für das jeweils aktuelle Semester ausgeführt werden, denn die Felder in der SOS-Tabelle werden ggf. überschrieben (z.B. wenn sich eine Studentin/ein Student ein zweites Mal exmatrikuliert oder wenn sie/er sich nur für eine Belegung exmatrikuliert). Wenn vergangene Semester nachträglich ausgewertet werden, können einheitliche Zahlen nur dann garantiert werden, wenn der Datenstand "eingefroren" wird wie es z.B. in SuperX mit der Archivierung getan wird.
Zusammenfassend: Um eine größtmögliche Übereinstimmung zwischen dem BSOS-Export und HISinOne-BI zu erreichen, müssen folgende Maßnahmen getroffen werden:
Die Zahl der Hauptprüfungen lässt sich in EXA mit folgendem SQL ermitteln, z.B. für das SoSe 2018 (Fälle):
set search_path to hisinone;
SELECT S.registrationnumber,
DP.studynumber as studiengang_nr,
DP.subjectnumber as fach_nr
FROM
unit_studies US,
course_of_study C,
degree_program_progress DP,
degree_program D,
period P,
student S,
examplan E,
term_type T,
unit U ,
examrelation R
left outer join examresult N on (N.examrelation_id=R.id)
WHERE U.id=US.unit_id
and C.lid=US.course_of_study_lid
and E.unit_id=U.id
and E.default_examrelation_id=R.id
and D.id=DP.degree_program_id
and DP.course_of_study_id=C.id
and DP.period_id=P.id
and D.student_id=S.id
and P.term_type_id=E.term_type_id
and P.term_year=E.term_year
and S.person_id=E.person_id
and T.id=E.term_type_id
and U.official_statistics =1 --Hauptprüfung
and (to_number(' ' || E.term_year || T.termnumber,'99999') ) = 20181
order by 1,2,3;
Sie erhalten eine Liste von Matrikelnr., Studiengang-Nr. und Fach-Nr. für das jew. Semester. Diese Liste können Sie in der Maske "Prüfungen im Detail Datenblatt" reproduzieren , indem Sie filtern auf:
Im Ergebnis können Sie noch über das normale "Tabelle editieren" Menü die Sortierung nach Matrikelnr. (aufsteigend), Studiengang-Nr. und Fach-Nr. einstellen. Die Spalte Summe können Sie ignorieren, weil die immer =1 ist. Damit haben Sie eine Liste, die mit dem Ergebnis aus obiger SQL-Abfrage übereinstimmen sollte.
Die Absolvierende nach Stichtag lassen sich wie folgt validieren: Nehmen wir als Beispiel die 15 bestandenen Hauptprüfungen im SoSe 2018:
Nun kann man im Prüfprotokoll Studium im Link "Weitere Einstellungen"->"Semester" den Datumswert für den Semesterbeginn ermitteln:
Ebenso kann man im Prüfprotokoll Studium im Link "Weitere Einstellungen"->"Stichtage"->Amtl. Stat. Land (Prüf.) den Stichtag Prüfungen ermitteln:
Ein zentrales Leistungsmerkmal des SuperX-SOS-Moduls ist es, die Brücke von der Studierendenverwaltung zur organisatorischen Struktur der Hochschule zu schlagen. Dazu hat sich in einigen Bundesländern das Konzept der "Lehreinheit" entwickelt, also der organisatorischen Einrichtung, der die Studiengänge zugeordnet sind. Bitte verwechseln Sie dies nicht mit der kapazitätsmäßigen Zuordnung, die an anderer Stelle (in HISCOB oder dem SuperX-Kennzahlen-Modul) und in erheblich komplexeren Ausmaß gepflegt wird. Für das SOS-Modul reicht es den Studiengang der organisatorischen Einrichtung zuzuordnen, die hauptsächlich dafür verantwortlich ist, unabhängig von der Lehrverflechtung oder der tatsächlichen Lehrleistung der Lehreinheit.
Wenn Sie vor Ablaufen des 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 vorgenommen werden.
Komponente Studierende inkrementell Laden - HISinOne-BI
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.
: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 Ladeprozeß 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.
Das SuperX-SOS-Modul benötigt teilweise Daten oder Schlüssel, die nicht in SOS vorhanden sind. In Ergebnistabellen werden solche Fälle mit "nicht zugeordnet" kenntlich gemacht. Doch es gibt auch Tabellen, die nicht direkt "sichtbar" sind und in speziellen Fällen benötigt werden. Die Maske "Prüfprotokoll Studium" gibt entsprechende Warnungen aus:
Ladeprotokoll Studium: Bei Warnungen werden je nach Tabelle in SOS/SuperX Semester und Matrikelnummern ausgegeben.
:
Wenn Sie Pseudonymisierung beim Entladen eingeschaltet haben, dann hilft die obige "Matrikelnummer" natürlich nicht viel. Die SOS-Betreuer/-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.
: 
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:
: 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.).
siehe Komponenten Update-HISinOne-BI
Business-Intelligence|Admin-Komponente Studierende|Admin-Komponent Studierende Installation|Admin-Komponente Studierende Konfiguration|Admin-Komponente Studierende Bestandteile|Admin-Komponente Studierende Maskenentwicklung