Post on 24-Aug-2019
CEUSHB - Ein Data-Warehouse-System für die bayerischen HochschulenArchitektur - Vorgehensweise - Modellierung
Dipl.-Wirtsch.Inf. Michael Böhnlein / Dipl.-Inf. Achim Ulbrich-vom Ende
2
Überblick
1. Motivation
2. Das CEUSHB -Projekt
3. Architektur von CEUSHB
4. Vorgehensweise
5. Realisierungsstand und weitere Schritte
3
1. Motivation
CEUSHB
Computerbasiertes Entscheidungsunterstützungssystem für dieHochschulen in Bayern
• Motivation:• Sowohl die Hochschulen als auch das Bayerische Staatsministerium für Wissenschaft,
Forschung und Kunst benötigen für eine zielorientierte Prozeßlenkung aktuelle und konsistenteInformationen über Prozesse.
• Um der erhöhten Autonomie und permanenten Gestaltung der Hochschulen Rechnung zutragen, müssen diese Informationen flexibel auswertbar sein.
• Idee: Entwicklung eines Data Warehouse Systems für alle Hochschulen in Bayern
• Projektauftrag: „Entwicklung eines Data Warehouse System-Prototypen als Kern eines Entscheidungs-
unterstützungssystems für die Bereiche Studium und Lehre, Personal undMittelbewirtschaftung an der Otto-Friedrich-Universität Bamberg und der TechnischenUniversität München“
4
2. CEUSHB-Projekt
• Auftraggeber: Bayerisches Staatsministerium für Wissenschaft,
Forschung und Kunst
• Durchführung:• Bayerisches Staatsinstitut für Hochschulforschung und
Hochschulplanung (Prof. Dr. Küpper, G. Tropp, M. Nusselein)• Informationsbedarfsanalyse• Systemeinführung
• Lehrstuhl für Wirtschaftsinformatik, insbes. Systementwicklung undDatenbankanwendung der Universität Bamberg(Prof. Dr. E. J. Sinz, M. Böhnlein, A. Ulbrich-vom Ende)
• Fachliche Analyse• Konzeption der Anwendungsarchitektur• Systementwicklung
• Projektbeginn: Anfang 1999
5
3. Architektur von CEUSHB
• Einflußfaktoren auf die Architektur von CEUSHB:• Geschäftsprozeßgefüge einer Universität• Potentielle Nutzer von CEUSHB
• Managementebenen einer Universität• Autonomie der Universitäten
• Resultierende Architektur:• Hierarchisch verteilte Data Warehouse Architektur• Geographische Verteilung• Trennung zwischen Base-Layer und Aggregation-Layer
6
3. Geschäftsprozeßgefüge einer Universität
Mittelbewirtschaftung:HIS-MBS
SAP R/3 (HER)
Forschung
Studium + LehreMittelbewirtsch.
Personalwirtsch.
Studentenverwaltung:HIS-SOSPersonalverwaltung:
DIAPERS SAP R/3 (HER)
Prozesse
Anwendungen
Prüfungsverwaltung:HIS-POSFlexNow!
Prozesse mit zugehörigen operativen Systemen:Prozesse mit zugehörigen operativen Systemen:
7
3. Potentielle Nutzer von CEUSHB
Nutzer von CEUSHB:• Staatsministerium für Wissenschaft, Forschung und Kunst :
Ziel ist es, dem Ministerium eine geeignete Informationsgrundlage für Planungund Entscheidung zur Verfügung zu stellen.
• Führungsverantwortliche der Universitäten(Prozeß-Owner, Studiendekan, Dekan, Hochschulleitung):Ziel ist es, durch Bereitstellung aktueller und aussagekräftiger Informationeneine permanente Prozeßverbesserung anzuregen und zu ermöglichen.
• Interessierte Öffentlichkeit:Ziel ist es, die Öffentlichkeitsarbeit der Hochschulen zu unterstützen und zuverbessern.
Verfahrensumfeld:• Informationsanbieter sind gleichzeitig interne Informationsnachfrager
• Vertrauen zwischen Informationsanbietern und Informationsnachfragern
• flexibles, computergestütztes Berichtssystem
8
3. Managementebenen einer Universität
Hochschulmanagement
Wissenschaftsministerium
Fakultätsmanagement
Mittelbewirtschaftung
Personalwirtschaft Studium und Lehre
Forschung
Ziele
Berichte
Berichte
Ziele
Fakultät
Hochschule
Ber
icht
e
Ziel
e
Beric
hte
Ziele
Ziel
e
Berichte
Ziel
e
Beric
hte
Studierende
Forschungs-partner
9
3. Architektur von CEUSHB
DWH
Lehre + Studium
Forschung
Fakultät 1
Fakultätsebene
Mittelbewirtsch.
Personalwirtsch.
u.s.w.
DWH der Universität
Universität A
Universitätsebene
DWH
Lehre + Studium
Forschung
Fakultät 1
Fakultätsebene
DWH des Ministeriums
ExterneDatenquellenz.B. Statistisches
Landesamt
Daten von allen Hochschulen in Bayern
HochschuldatenVergleichsdaten
Mittelbewirtsch.
Personalwirtsch.
u.s.w.
DWH der Universität
Universität A
Universitätsebene
DWH
Lehre + Studium
Forschung
Fakultät 1
Fakultätsebene
Hierarchisch verteiltes Data Warehouse System:Hierarchisch verteiltes Data Warehouse System:
10
Interne Statistik (Hochschulstatistik)• Daten stehen nur innerhalb der jeweiligen
Universität zur Verfügung• Daten orientieren sich an den Gegebenheiten der
jeweiligen Universität (z.B. Organisationsstruktur /Schlüssel)
• Keine Einschränkungen hinsichtlich der analytischenMöglichkeiten
• Individuelle Schlüssel der Universität werdenberücksichtigt
• Hoher Detailierungsgrad
Externe Statistik (Amtliche Statistik)• Daten stehen sowohl dem Ministerium als auch
(ein Teil der Daten) allen Universitäten fürVergleichsanalysen zur Verfügung
• Daten entsprechen den bisherigen Vorgaben desstatistischen Landesamts für die Hochschulstatistik:
• Aspekte des Datenschutzes sind bereits geklärt• Vorgeschriebene Datenstrukturen führen zu einem
einheitlichen Schema für alle Universitäten in Bayern
• Aggregierte Daten der Hochschulstatistik
3. Architektur von CEUSHB
Externe Statistik aller Hochschulen +zusätzl. Daten
DWH der Universität
DWH des Ministeriums
InterneStatistik
ExterneStatistik
Dat
en d
er
ande
ren
Hoc
hsch
ulenD
aten zur am
tlichenS
tatistik
11
Universität Bamberg
Universität Bayreuth
Technische UniversitätMünchenLudwig-Maximilan
Universität München
Universität Passau
UniversitätErlangen-Nürnberg
Universität Regensburg
UniversitätAugsburg
Stat. Landesamt /Ministerium
München
Katholische UniversitätEichstätt
3. Architektur von CEUSHB
Universität Würzburg
Universität der BundeswehrMünchen
UNI DWH
Laden / AktualisierenKonsolidierung
BereinigungExtraktion
Operative Quellen
Universität Würzburg
12
3. Architektur von CEUSHB
Vorteile:• Base-Layer als standardisierte
Schnittstelle zu den operativenSystemen
• Base-Layer als Schnittstelle zumData Warehouse der nächstniedrigeren bzw. der nächst höherenEbene
• Berücksichtigung unterschiedlicherKonsistenzniveaus
• Vermeidung von View MaintenanceAnomalien
• Dynamische Anpaßbarkeit• hinsichtlich verschiedener
Informationsanforderungen an denunterschiedlichen Hochschulen
• hinsichtlich steigenderAnforderungen der Nutzer
• hinsichtlich der Integrationzusätzlicher Domänen
Nachteile:• Erhöhter Speicherbedarf (vernachl.)• Erhöhter Aktualisierungsaufwand
Base-Layer
Aggregation-Layer
Operative Daten
Laden / AktualisierenKonsolidierung
BereinigungExtraktion
Schnittstellezum Data Ware-house der nächsthöheren Ebene
12
3. Architektur von CEUSHB
Vorteile:• Base-Layer als standardisierte
Schnittstelle zu den operativenSystemen
• Base-Layer als Schnittstelle zumData Warehouse der nächstniedrigeren bzw. der nächst höherenEbene
• Berücksichtigung unterschiedlicherKonsistenzniveaus
• Vermeidung von View MaintenanceAnomalien
• Dynamische Anpaßbarkeit• hinsichtlich verschiedener
Informationsanforderungen an denunterschiedlichen Hochschulen
• hinsichtlich steigenderAnforderungen der Nutzer
• hinsichtlich der Integrationzusätzlicher Domänen
Nachteile:• Erhöhter Speicherbedarf (vernachl.)• Erhöhter Aktualisierungsaufwand
Base-Layer
Aggregation-Layer
Operative Daten
Laden / AktualisierenKonsolidierung
BereinigungExtraktion
Schnittstellezum Data Ware-house der nächsthöheren Ebene
12
3. Architektur von CEUSHB
Vorteile:• Base-Layer als standardisierte
Schnittstelle zu den operativenSystemen
• Base-Layer als Schnittstelle zumData Warehouse der nächstniedrigeren bzw. der nächst höherenEbene
• Berücksichtigung unterschiedlicherKonsistenzniveaus
• Vermeidung von View MaintenanceAnomalien
• Dynamische Anpaßbarkeit• hinsichtlich verschiedener
Informationsanforderungen an denunterschiedlichen Hochschulen
• hinsichtlich steigenderAnforderungen der Nutzer
• hinsichtlich der Integrationzusätzlicher Domänen
Nachteile:• Erhöhter Speicherbedarf (vernachl.)• Erhöhter Aktualisierungsaufwand
Base-Layer
Aggregation-Layer
Operative Daten
Laden / AktualisierenKonsolidierung
BereinigungExtraktion
Schnittstellezum Data Ware-house der nächsthöheren Ebene
13
4. Arbeitspakete
Aufbau der Metadatenbank
Entwicklung der DWH Systemarchitektur
Evaluierung von Data Warehouse Werkzeugen
Do
män
enn
eutr
ale
Arb
eits
pak
ete
Do
män
ensp
ezif
isch
eA
rbei
tsp
aket
eD
om
änen
neu
tral
eA
rbei
tsp
aket
e
AnalyseDesign
ImplementierungBetriebStudenten
Bamberg München
AnalyseDesign
ImplementierungBetriebPrüfungen
Bamberg München
AnalyseDesign
ImplementierungBetriebStudenten
Bamberg München
Aufbau der Metadatenbank
AnalyseDesign
ImplementierungBetriebPersonal
Bamberg München
DesignImplementierung
BetriebPrüfungen
Bamberg München
ImplementierungBetrieb
Bamberg München
Aufbau der Metadatenbank
. . .
Mittelbewirt-schaftung+
14
4. Vorgehensweise
Universitäre Ausbildung (L)
EDV-Leistun-gen (L)
Rechen-zentrum
Personal-bereich
Mittelverwal-tung (L)
Bereitstellen Arbeitsleistung (L) Forschungs-
leistung (L)Forschung
HauptbereichServicebereich
Universität
Studium/Lehre
Mittelbewirt-schaftung
Arbeits-leistung (L)
Student
Arbeits-markt Forschungs-
partner
...
Staat Staats-finanzen (L)
Bibliothek Bereitstellen Literatur (L)
Informationsbedarfermittelt aus denGeschäftsprozeß-
modellen
sdfh sdf slfj sdfuls sdlfulasisdfs sieru seselsese 9se seisdkseaeas ehsie a sersaesekaseuraekasas asdzfku skdfhhasdfashdfkjahsd bsjd askdhaskdfhas fasdiu aslffaiushsadfaksenia bliuase asliduuaskfhaskehae isaeukjahs skersakuzfaskeh suerk skiuzeaseuaseh asieuruseialioesaudfiseriweröase seruiezzoiseruiuiwueri asiur aiouw ser
KlassischeInformationsbedarfs
-analyse
IST-Analyse
SOLL-Analyse
Informationsangebotder operativenQuellsysteme
DataWarehouse
Schema
15
4.1. Informationsangebot der operativen Quellen
Reengineering
country state city airport stage
flight interval
fare
flightaircraft
airline
aircraft type
booking class
passenger
aircraft - booking class
start
destination
booking
KonzeptuellesDatenmodell im Strukturierten
Entity RelationshipDiagramm (SERM)
PhysischeDatenstrukturender operativenQuellsysteme
1. Phase: Konstruktion von konzeptuellen Datenmodellen für die operativenDatenquellen
• Relationale Tabellen• Flat-Files• Excel-Tabellen
16
4.1. Informationsangebot der operativen Quellen
2. Phase: Ableitung von Data Warehouse Strukturen aus den konzeptuellenSchemata der operativen Quellen (DOLAP‘1999)
Student
Studien-gang
Vertiefung
HeimatLand
HeimatOrtHeimat-Bundesland
Studien-Verlauf
FakultätUniversität
Geschlecht
Studien-abschluß
Exmatrikula-tionsgrund
Student-Stg. - Vert.
Immatri-kulationsart
Studiengang- Vertiefung
InlandAusland
Semester
16
4.1. Informationsangebot der operativen Quellen
2. Phase: Ableitung von Data Warehouse Strukturen aus den konzeptuellenSchemata der operativen Quellen (DOLAP‘1999)
Student
Studien-gang
Vertiefung
HeimatLand
HeimatOrtHeimat-Bundesland
Studien-Verlauf
FakultätUniversität
Geschlecht
Studien-abschluß
Exmatrikula-tionsgrund
Student-Stg. - Vert.
Immatri-kulationsart
Studiengang- Vertiefung
InlandAusland
Semester
Anzahl derExmatrikulationen
Studien-abschluß
16
4.1. Informationsangebot der operativen Quellen
2. Phase: Ableitung von Data Warehouse Strukturen aus den konzeptuellenSchemata der operativen Quellen (DOLAP‘1999)
Student
Studien-gang
Vertiefung
HeimatLand
HeimatOrtHeimat-Bundesland
Studien-Verlauf
FakultätUniversität
Geschlecht
Studien-abschluß
Exmatrikula-tionsgrund
Student-Stg. - Vert.
Immatri-kulationsart
Studiengang- Vertiefung
InlandAusland
Semester
Anzahl derExmatrikulationen
Studien-abschluß
Anzahl eingeschriebener
Studenten
Studien-Verlauf
Semester
16
4.1. Informationsangebot der operativen Quellen
2. Phase: Ableitung von Data Warehouse Strukturen aus den konzeptuellenSchemata der operativen Quellen (DOLAP‘1999)
Student
Studien-gang
Vertiefung
HeimatLand
HeimatOrtHeimat-Bundesland
Studien-Verlauf
FakultätUniversität
Geschlecht
Studien-abschluß
Exmatrikula-tionsgrund
Student-Stg. - Vert.
Immatri-kulationsart
Studiengang- Vertiefung
InlandAusland
Semester
Anzahl derExmatrikulationen
Studien-abschluß
Anzahl eingeschriebener
Studenten
Studien-Verlauf
Semester
Anzahl derImmatrikulationen
Student-Stg. - Vert.
16
4.1. Informationsangebot der operativen Quellen
2. Phase: Ableitung von Data Warehouse Strukturen aus den konzeptuellenSchemata der operativen Quellen (DOLAP‘1999)
Student
Studien-gang
Vertiefung
HeimatLand
HeimatOrtHeimat-Bundesland
Studien-Verlauf
FakultätUniversität
Geschlecht
Studien-abschluß
Exmatrikula-tionsgrund
Student-Stg. - Vert.
Immatri-kulationsart
Studiengang- Vertiefung
InlandAusland
Semester
Anzahl derExmatrikulationen
Studien-abschluß
Anzahl eingeschriebener
Studenten
Studien-Verlauf
Semester
Anzahl derImmatrikulationen
Student-Stg. - Vert.
Hülle der Existenz-voraussetzungen
Student
Studien-gang
Vertiefung
HeimatLand
HeimatOrtHeimat-Bundesland
Studien-
FakultätUniversität
Geschlecht
Anzahl derImmatrikulationen
Student-Stg. - Vert.
Immatri-kulationsart
Studiengang- Vertiefung
InlandAusland
16
4.1. Informationsangebot der operativen Quellen
2. Phase: Ableitung von Data Warehouse Strukturen aus den konzeptuellenSchemata der operativen Quellen (DOLAP‘1999)
Student
Studien-gang
Vertiefung
HeimatLand
HeimatOrtHeimat-Bundesland
Studien-Verlauf
FakultätUniversität
Geschlecht
Studien-abschluß
Exmatrikula-tionsgrund
Student-Stg. - Vert.
Immatri-kulationsart
Studiengang- Vertiefung
InlandAusland
Semester
Anzahl derExmatrikulationen
Studien-abschluß
Anzahl eingeschriebener
Studenten
Studien-Verlauf
Semester
Anzahl derImmatrikulationen
Student-Stg. - Vert.
DimensionHeimatGeographie
Student
HeimatLand
HeimatOrtHeimat-Bundesland
InlandAusland
16
4.1. Informationsangebot der operativen Quellen
2. Phase: Ableitung von Data Warehouse Strukturen aus den konzeptuellenSchemata der operativen Quellen (DOLAP‘1999)
Student
Studien-gang
Vertiefung
HeimatLand
HeimatOrtHeimat-Bundesland
Studien-Verlauf
FakultätUniversität
Geschlecht
Studien-abschluß
Exmatrikula-tionsgrund
Student-Stg. - Vert.
Immatri-kulationsart
Studiengang- Vertiefung
InlandAusland
Semester
Anzahl derExmatrikulationen
Studien-abschluß
Anzahl eingeschriebener
Studenten
Studien-Verlauf
Semester
Anzahl derImmatrikulationen
Student-Stg. - Vert.
DimensionHeimatGeographie
Student
HeimatLand
HeimatOrtHeimat-Bundesland
InlandAusland
DimensionGeschlecht
Geschlecht
16
4.1. Informationsangebot der operativen Quellen
2. Phase: Ableitung von Data Warehouse Strukturen aus den konzeptuellenSchemata der operativen Quellen (DOLAP‘1999)
Student
Studien-gang
Vertiefung
HeimatLand
HeimatOrtHeimat-Bundesland
Studien-Verlauf
FakultätUniversität
Geschlecht
Studien-abschluß
Exmatrikula-tionsgrund
Student-Stg. - Vert.
Immatri-kulationsart
Studiengang- Vertiefung
InlandAusland
Semester
Anzahl derExmatrikulationen
Studien-abschluß
Anzahl eingeschriebener
Studenten
Studien-Verlauf
Semester
Anzahl derImmatrikulationen
Student-Stg. - Vert.
DimensionHeimatGeographie
Student
HeimatLand
HeimatOrtHeimat-Bundesland
InlandAusland
DimensionGeschlecht
Geschlecht
DimensionImmatrikulationsart
DimensionGeschlecht
Immatri-kulationsart
16
4.1. Informationsangebot der operativen Quellen
2. Phase: Ableitung von Data Warehouse Strukturen aus den konzeptuellenSchemata der operativen Quellen (DOLAP‘1999)
Student
Studien-gang
Vertiefung
HeimatLand
HeimatOrtHeimat-Bundesland
Studien-Verlauf
FakultätUniversität
Geschlecht
Studien-abschluß
Exmatrikula-tionsgrund
Student-Stg. - Vert.
Immatri-kulationsart
Studiengang- Vertiefung
InlandAusland
Semester
Anzahl derExmatrikulationen
Studien-abschluß
Anzahl eingeschriebener
Studenten
Studien-Verlauf
Semester
Anzahl derImmatrikulationen
Student-Stg. - Vert.
DimensionHeimatGeographie
Student
HeimatLand
HeimatOrtHeimat-Bundesland
InlandAusland
DimensionGeschlecht
Geschlecht
DimensionImmatrikulationsart
DimensionGeschlecht
Immatri-kulationsart
DimensionFachbereich
Studien-gang
Vertiefung
FakultätUniversität
Exmatrikula-
Studiengang- Vertiefung
16
4.1. Informationsangebot der operativen Quellen
2. Phase: Ableitung von Data Warehouse Strukturen aus den konzeptuellenSchemata der operativen Quellen (DOLAP‘1999)
Student
Studien-gang
Vertiefung
HeimatLand
HeimatOrtHeimat-Bundesland
Studien-Verlauf
FakultätUniversität
Geschlecht
Studien-abschluß
Exmatrikula-tionsgrund
Student-Stg. - Vert.
Immatri-kulationsart
Studiengang- Vertiefung
InlandAusland
Semester
Anzahl derExmatrikulationen
Studien-abschluß
Anzahl eingeschriebener
Studenten
Studien-Verlauf
Semester
Anzahl derImmatrikulationen
Student-Stg. - Vert.
DimensionHeimatGeographie
Student
HeimatLand
HeimatOrtHeimat-Bundesland
InlandAusland
DimensionGeschlecht
Geschlecht
DimensionImmatrikulationsart
DimensionGeschlecht
Immatri-kulationsart
DimensionFachbereich
Studien-gang
Vertiefung
FakultätUniversität
Exmatrikula-
Studiengang- Vertiefung
Exmatrikula-tionsgrund
DimensionExmatrikulationsgrund
Exmatrikula-tionsgrund
17
Vorgehen: Kombination induktiver und deduktiver Elemente Vorgehen: Kombination induktiver und deduktiver Elemente
Laufende Abstimmung mit den Beteiligtenam Ministerium und an den Pilot-Hochschulen
Informationsbedarfsanalyse
Organisations-
undAufgabenanalyse
Inter-views
deduktiv-logische Analyse
Frage-bögen
Work-shops
4.2. Klassische Informationsbedarfsanalyse
18
4.3. Analyse der Geschäftsprozeßmodelle
Universitäre Ausbildung (L)
EDV-Leistun-gen (L)
Rechen-zentrum
Personal-bereich
Mittelverwal-tung (L)
Bereitstellen Arbeitsleistung (L) Forschungs-
leistung (L)Forschung
HauptbereichServicebereich
Universität
Studium/Lehre
Mittelbewirt-schaftung
Arbeits-leistung (L)
Student
Arbeits-markt Forschungs-
partner
...
StaatStaats-finanzen (L)
Bibliothek Bereitstellen Literatur (L)
1. Phase: Konstruktion eines Geschäftsprozeßmodells für dieUniversität im Semantischen Objekt Modell (SOM)
PAR D: SemAusbild (L)
Studium/Lehre
D: V
orbe
ratIn
tere
ssen
t (L)
D: ExmatrStudent (L)
D: vorberatInterStuPlaV (L)
Vorberatung
StudPlatzVereinbarung
Student
AusbildPrfBeratSystem
A: Vorberatung
V: StudPlatzVereinb
SEQ D: Exmatrikulation
V: Rueckmeldung
Kultusministerium
Uni-Leitung
Zielvorgaben
Zielvorgaben
D: Zahlungsmeldung
D: Z
ahlungStudW
erkBetrag (L)
Studentenwerk / Kasse
AusbildungsSystem
RückmeldeSystem
D: Rueckgemeldeter Student (L)
AusbildSyst
ExmatrikulationsSystem
AusbildPrfSystem
Beratung
SemAusbildSystem
PrüfungsSystem
D: Überprf Ausbilderfolg (L)
D: beratStudent(L)
PAR D: Prüfung (L)
PAR D: Beratung (L)
19
4.3. Analyse der Geschäftsprozeßmodelle
SemAusbildSystem
Vorberatung
Student
StudPlatzVereinbarung
RückmeldeSystem
StudentenwerkKasse
Vorberatung
vorberatInteressent
vorberatInterStuPlaV
StuPlatzVereinb ImmatrStudent
SemesterAusbildung
Rückmeldung
ZahlungStudWerkbeitrag
Zahlungsmeldung
ExmatrikulationsSystem
RückgemeldeterStudent Exmatrikulation ExmatrStudent
PrüfungsSystem
Beratung StudienbegleitendeBeratung
beratStudent
Prüfung ÜberprüfungAusbilderfolg
Legende:
objektspezifischer Objekttyp
transaktionsspezifischer ObjekttypName
N a m e
Beziehungstyp interacts with
Vorberatung>
Vorberatung
Vorberatung
Student
StudPlatzVereinbarung
AusbildPrfBeratSystem
StudWerk / Kasse
RückmeldeSystem
ExmatrikulationsSystem
>Vorberatung
Student
vorberatInterStudPlaV>
Vorberatung
vorberatInteressent>
Vorberatung
>vorberatInterStuPlaV
StudPlatzVereinb
>vorberatInteressent
AusbildPrfBeratSys
StudPlatzVereinbarung>
Student
>StudPlatzVereinbarung
StudPlatzVereinb
ImmatrStudent>
StudPlatzVereinb
>ImmatrStudent
AusbildPrfBeratSys
AusbildPrfBerat>
AusbildPrfBeratSys
>AusbildPrfBerat
Student
ZahlungStudWerkbeitrag>
Student
>ZahlungStudWerkbeitrag
StudWerk / Kasse
Zahlungsmeldung>
StudWerk / Kasse
>Zahlungsmeldung
RückmeldeSystem
>Rückmeldung
RückmeldeSystem
RückgemeldeterStudent>
RückmeldeSystem
>RückgemeldeterStudent
AusbildPrfBeratSys
Exmatrikulation>
Student
>Exmatrikulation
ExmatrSystem
ExmatrStudent>
ExmatrSystem
>ExmatrStudent
AusbildPrfBeratSys
Rückmeldung>
RückmeldeSystem
A: Vorberatung
D: vorberatInterStuPlaV
D:
vorb
erat
Inte
ress
ent
V: S
tudP
latz
Ver
einb
D: Z
ahlu
ngSt
udW
erkb
eitra
g
D: ImmatrStudent
D:
Rüc
kmel
dung
D: A
usbi
ldPr
fBer
at
D: R
ückg
emel
dete
r Stu
dent
D:
Exm
atri
kula
tion
D: E
xmat
rStu
dent
D: Zahlungsmeldung
Aufgabe
Objekt
Legende:
Vorgangstyp
internes Ereignisexternes Ereignis
Vorgangs-Ereignis-Schema
KonzeptuellesObjektschema
PAR D : SemAusb i l d ( L )
S t u d i u m / L e h r e
D: V
orbe
ratIn
tere
ssen
t (L)
D : E x m a t rS tuden t ( L )
D : v o r b e r a t I n t e r S t u P l a V ( L )
V o r b e r a t u n g
S t u d P l a t z V e r e i n b a r u n g
S t u d e n t
A u s b i l d P r f B e r a t S y s t e m
A : V o r b e r a t u n g
V : S t u d P l a t z V e r e i n b
S E Q D : E x m a t r i k u l a t i o n
V : R u e c k m e l d u n g
K u l t u s m i n i s t e r i u m
U n i - L e i t u n g
Zie lvorgaben
Zie lvorgaben
D : Z a h l u n g s m e l d u n g
D: ZahlungS
tudWerkB
etrag (L)
S t u d e n t e n w e r k / K a s s e
A u s b i l d u n g s S y s t e m
R ü c k m e l d e S y s t e m
D : R u e c k g e m e l d e t e r S tuden t ( L )
A u s b i l d S y s t
E x m a t r i k u l a t i o n s S y s t e m
A u s b i l d P r f S y s t e m
B e r a t u n g
S e m A u s b i l d S y s t e m
P r ü f u n g s S y s t e m
D : Überp r f A u s b i l d e r f o l g ( L )
D : b e r a t S t u d e n t (L)
P A R D : P r ü f u n g ( L )
P A R D : B e r a t u n g ( L )
Interaktions-Schema
2. Phase: Ableitung von Data Warehouse Strukturen ausdem Geschäftsprozeßmodell
20
4.3. Analyse der Geschäftsprozeßmodelle
immatr.Studenten
Heimatwohnsitz
Land
KFZ-Kennzeichen
Bundesland
Kontinent EG-Mitglied In-/Ausland
InlandAusland Fachbereich
Vertiefungs-fach
Studiengang
Fakultät
Geschlecht
Geschlecht
Exmatr. Grund
Exmatrikulat.Grund
Studien-abschluß
exmatr.Studenten
Immat. Art
Immatrikulat.Art
Output/Input-Flow:exmatr. Stud. / immatr. Stud.
Quote [Heimatwohnsitz]:X [KFZKennz.] / X [Bundesland]
Filter {Geschlecht}:X {Geschlecht=weiblich}
Gesamt
Gesamt
Gesamt
Gesamt
Gesamt
KonzeptuellesData Warehouse
Schema
SemAusbildSystem
Vorberatung
Student
StudPlatzVereinbarung
RückmeldeSystem
StudentenwerkKasse
Vorberatung
vorberatInteressent
vorberatInterStuPlaV
StuPlatzVereinb ImmatrStudent
SemesterAusbildung
Rückmeldung
ZahlungStudWerkbeitrag
Zahlungsmeldung
ExmatrikulationsSystem
RückgemeldeterStudent Exmatrikulation ExmatrStudent
PrüfungsSystem
BeratungStudienbegleitende
Beratung
beratStudent
Prüfung ÜberprüfungAusbilderfolg
Legende:
objektspezifischer Objekttyp
transaktionsspezifischer ObjekttypName
Name
Beziehungstyp interacts with
KonzeptuellesObjektschema
1. Bestimmen derLeistungenund Ziele desSystemsZieleLeistungen
2. Analyse desGeschäfts-prozeßmodellsAbgrenzen der betrachteten Prozesse
3. Ableitendes konzeptuellenObjektschemasBestimmen derrelevanten Attribute
4. Identifiziereninitialer DataWarehouseStrukturena) Metrikenb) Dimensionenc) Constraints
feedback loop
21
4. Resultierendes Konzeptuelles Datenmodell
21
4. Resultierendes Konzeptuelles Datenmodell
Immatrikulations-art
Heimatwohnsitz Fachbereich
Immatrikulations-Art
Gesamt
Kontinent EG-Mitglied In-/Ausland
Heimat-Land
Gesamt
Heimat-Bundesland
Heimat-Ort
Vertiefungs-fach
Studiengang
Fakultät
Gesamt
Anzahl derImmatrikulationen
Aus
land
Inland
21
4. Resultierendes Konzeptuelles Datenmodell
Immatrikulations-art
Heimatwohnsitz Fachbereich
Immatrikulations-Art
Gesamt
Kontinent EG-Mitglied In-/Ausland
Heimat-Land
Gesamt
Heimat-Bundesland
Heimat-Ort
Vertiefungs-fach
Studiengang
Fakultät
Gesamt
Anzahl derImmatrikulationen
Aus
land
Inland
Immatrikulations-art
Heimatwohnsitz Fachbereich
Immatrikulations-Art
Gesamt
Kontinent EG-Mitglied In-/Ausland
Heimat-Land
Gesamt
Heimat-Bundesland
Heimat-Ort
Vertiefungs-fach
Studiengang
Fakultät
Gesamt
Anzahl derImmatrikulationen
Anzahleingeschriebener
Studenten
Aus
land
Inland
21
4. Resultierendes Konzeptuelles Datenmodell
Immatrikulations-art
Heimatwohnsitz Fachbereich
Immatrikulations-Art
Gesamt
Kontinent EG-Mitglied In-/Ausland
Heimat-Land
Gesamt
Heimat-Bundesland
Heimat-Ort
Vertiefungs-fach
Studiengang
Fakultät
Gesamt
Anzahl derImmatrikulationen
Aus
land
Inland
Immatrikulations-art
Heimatwohnsitz Fachbereich
Immatrikulations-Art
Gesamt
Kontinent EG-Mitglied In-/Ausland
Heimat-Land
Gesamt
Heimat-Bundesland
Heimat-Ort
Vertiefungs-fach
Studiengang
Fakultät
Gesamt
Anzahl derImmatrikulationen
Anzahleingeschriebener
Studenten
Aus
land
Inland
Immatrikulations-art
Heimatwohnsitz Fachbereich
Immatrikulations-Art
Gesamt
Kontinent EG-Mitglied In-/Ausland
Heimat-Land
Gesamt
Heimat-Bundesland
Heimat-Ort
Vertiefungs-fach
Studiengang
Fakultät
Gesamt
Exmatr. Grund
Exmatrikulat.Grund
Studien-abschluß
Gesamt
Anzahl derImmatrikulationen
Anzahl derExmatrikulationen
Anzahleingeschriebener
Studenten
Aus
land
Inland
21
4. Resultierendes Konzeptuelles Datenmodell
Immatrikulations-art
Heimatwohnsitz Fachbereich
Immatrikulations-Art
Gesamt
Kontinent EG-Mitglied In-/Ausland
Heimat-Land
Gesamt
Heimat-Bundesland
Heimat-Ort
Vertiefungs-fach
Studiengang
Fakultät
Gesamt
Anzahl derImmatrikulationen
Aus
land
Inland
Immatrikulations-art
Heimatwohnsitz Fachbereich
Immatrikulations-Art
Gesamt
Kontinent EG-Mitglied In-/Ausland
Heimat-Land
Gesamt
Heimat-Bundesland
Heimat-Ort
Vertiefungs-fach
Studiengang
Fakultät
Gesamt
Anzahl derImmatrikulationen
Anzahleingeschriebener
Studenten
Aus
land
Inland
Immatrikulations-art
Heimatwohnsitz Fachbereich
Immatrikulations-Art
Gesamt
Kontinent EG-Mitglied In-/Ausland
Heimat-Land
Gesamt
Heimat-Bundesland
Heimat-Ort
Vertiefungs-fach
Studiengang
Fakultät
Gesamt
Exmatr. Grund
Exmatrikulat.Grund
Studien-abschluß
Gesamt
Anzahl derImmatrikulationen
Anzahl derExmatrikulationen
Anzahleingeschriebener
Studenten
Aus
land
Inland
Immatrikulations-art
Heimatwohnsitz Fachbereich
Immatrikulations-Art
Gesamt
Kontinent EG-Mitglied In-/Ausland
Heimat-Land
Gesamt
Heimat-Bundesland
Heimat-Ort
Vertiefungs-fach
Studiengang
Fakultät
Gesamt
Exmatr. Grund
Exmatrikulat.Grund
Studien-abschluß
Gesamt
Anzahl derImmatrikulationen
Anzahl derExmatrikulationen
Immatrikulationsquote:Immatrikulationen / eingeschr. Stud.
Anzahleingeschriebener
Studenten
Aus
land
Inland
Exmatrikulationsquote:Exmatrikulationen / eingeschr. Stud.
22
5. Realisierungsstand und weitere Vorgehensweise
• Aktueller Projektstand:• Bereich Studentenverwaltung abgeschlossen:
• 10 Basiskennzahlen• ca. 40 Auswertungshierarchien• Unterscheidung zwischen amtlicher und hochschulinterner Statistik• Weitgehende Automatisierung des Aktualisierungsprozesses
• WWW-Interface (Personalisiertes Informationsportal)
• Weitere Vorgehensweise:• Bereiche Prüfungsverwaltung und Personalverwaltung (2000)• Bereich Mittelbewirtschaftung (2001)
22
5. Realisierungsstand und weitere Vorgehensweise
• Aktueller Projektstand:• Bereich Studentenverwaltung abgeschlossen:
• 10 Basiskennzahlen• ca. 40 Auswertungshierarchien• Unterscheidung zwischen amtlicher und hochschulinterner Statistik• Weitgehende Automatisierung des Aktualisierungsprozesses
• WWW-Interface (Personalisiertes Informationsportal)
• Weitere Vorgehensweise:• Bereiche Prüfungsverwaltung und Personalverwaltung (2000)• Bereich Mittelbewirtschaftung (2001)
23
Literaturhinweise
• Sinz, E.J.; Böhnlein, M.; Ulbrich-vom Ende, A.: Konzeption eines Data Warehouse-Systemsfür Hochschulen, Workshop "Unternehmen Hochschule" (Informatik '99, 29. Jahrestagung derGesellschaft für Informatik, Paderborn, 5.-9. Oktober),1999, S. 111-124
• Böhnlein, M.; Ulbrich-vom Ende, A.: Using the Conceptual Data Models of the OperationalInformation Systems for the Construction of Initial Data Warehouse Structures, Modellierungbetrieblicher Informationssysteme (MobIS'1999, Bamberg, 14.-15. Oktober), 1999, S. 66-82
• Böhnlein, M.; Ulbrich-vom Ende, A.: Deriving Initial Data Warehouse Structures from theConceptual Data Models of the Underlying Operational Information Systems, Proceedings ofthe ACM Second International Workshop on Data Warehousing and OLAP (DOLAP'1999,Kansas City, 6. November), 1999, S. 15-21
• Böhnlein, M.; Ulbrich-vom Ende, A.: Grundlagen des Data Warehousing: Modellierung undArchitektur, Bamberger Beiträge zur Wirtschaftsinformatik Nr. 55, Bamberg, Februar 2000