1.
Aufgabenstellung ^
[1]
Im Umweltbundesamt werden zu unterschiedlichen Themen Daten gesammelt (z.B. Wasser, Boden Luft, …). Die Herausforderung für das Umweltbundesamt ist es jedoch nicht nur Daten zu sammeln, sondern daraus Entscheidungsgrundlagen für Politik, Behörden, Experten und die Öffentlichkeit zu gewinnen.
2.
Problemstellung ^
[2]
Im Umweltbereich ergeben sich oft komplexe fachübergreifende Fragestellungen.
[3]
Eine themenübergreifende Auswertung war und ist mit isolierten Fachdatenbanken nicht einfach möglich. Daten wurden und werden daher oft mühselig exportiert und in andere Systeme importiert.
[4]
Das führt zu doppelter Datenhaltung, zweifelhaften Datenbeständen und redundanten Arbeitsvorgängen: all das ist fehleranfällig undlast but not least kostenintensiv.
3.
Lösungsansatz ^
[5]
Eine Lösung zur Integration unterschiedlicher heterogener Quellsysteme ist ein Datawarehouse (DWH).
3.1.
Was ist also ein Datawarehouse? ^
[6]
Ziel eines Datawarehouse ist es, Benutzer bei Entscheidungen und Analysen zu unterstützen.
Abbildung 1: Bestandteile eines DWH
[7]
Es werden mittels regelmäßig aufgerufener Batchprozesse (=ETL) Daten aus unterschiedlichen Quellsystemen extrahiert. Die Daten werden aufbereitet und qualitätsgesichert, um sie danach unterschiedlichen Clients zur Verfügung stellen zu können.
3.2.
Datenmodell ^
[8]
Das Datenmodell eines DWH ist auf effiziente Auswertung und leichte Endbenutzerverständlichkeit ausgelegt.
Abbildung 2: Dimensionales Datenmodell (Star Schema)
[9]
Es kann zwischen Fakten- und Dimensionstabellen unterschieden werden:
- Faktentabellen: Beinhalten numerische Attribute (sogenannte Measures), mit denen gerechnet wird.
- Dimensionstabellen: Ermöglichen es, die Abfrage einzuschränken, zu aggregieren, Mittelwerte zu berechnen und im Spezialfall der konformen Dimensionen (das sind DWH weit einheitliche Dimensionen, die unabhängig von spezifischen Anwendungsfällen sind, z.B. Datum, Administrative Grenzen, …) unterschiedliche Themen auf der Granularität der jeweiligen Dimension zu verknüpfen.
[10]
Faktentabellen werden mit Dimensionstabellen über eine «Foreign Key» (= Fremdschlüssel) Beziehung verbunden.
3.3.1.
«Drill Down» ^
[11]
Unter Drill Down versteht man das «Hineinzoomen» in die Hierarchie, bei dem die vorhandenen Daten in größerer Detailtiefe betrachtet werden können. Beim Drill Down wird die Datenaggregation reduziert und der Hierarchie wird eine Detailebene hinzugefügt.
[12]
Beispiel für «Drill Down»: Auswahl des Jahresmittelwertes ( Drill Down auf Monatsmittelwert ( Drill Down auf Tagesmittelwert ( Drill Down auf Einzelmesswert.
3.3.2.
«Roll up» ^
[13]
Eine gegenteilige Betrachtungsrichtung ist das Roll Up, ein schrittweises «Herauszoomen» aus der Hierarchie. Beim «Roll Up» steigt die Datenaggregation und Detailebenen der Hierarchie verschwinden.
[14]
Beispiel für «Roll Up»: Einzelwert ( Tagesmittelwert ( Monatsmittelwert ( Jahresmittelwert.
3.3.3.
Drill Across ^
[15]
Drill Across wird verwendet um Daten über unterschiedliche Themenbereiche (=klassische Fachdatenbanken) hinweg analysieren zu können.
[16]
Wird über die DWH einheitlichen «konformen Dimensionen» ermöglicht.
Abbildung 3: «Drill Across» über konforme Dimension
[17]
Beispiel: Fakt «Messewert Emission» wird über die konforme Ortsdimension «Gemeinde x» mit der Faktendimension «Hauptwohnsitz» verbunden.
3.3.4.
Handle Time ^
[18]
Das Data Warehouse kann die Historie abbilden. Beispiel: Ein zu einer bestimmten Zeit durchgeführter Report muss immer wieder das gleiche Ergebnis liefern.
[19]
Im DWH können also (selbst wenn dies im zugrundeliegenden transaktionalen Quellsystemen nicht so implementiert wurde) auch alte Werte behalten werden.
4.
Umsetzung ^
[20]
Im Unterschied zu klassischen Business Intelligence (BI) Lösungen die sehr stark auf Geschäftskennzahlen aufsetzten, gibt es im Umweltbereich folgende zusätzliche Anforderungen:
- Raumbezug: Umweltdaten haben Raum und Zeitbezug. Daher ist die Abfrage und Darstellung nach räumlichen Kriterien notwendig. Z.B. Wann und wo wurde der Ozonwarnstufe überschritten?
- Große Anzahl von WebClients: Das Datawarehouse soll sowohl hausintern als auch extern übers Web genutzt werden können. Z.B.: Fachexperten in den Bundesländern, Öffentlichkeit.
- eGovernement Styleguide: Als Behörde müssen wir uns an den eGovernement Styleguide halten. Z.B. Die Webseiten müssen auch für Blinde zugänglich sein.
[21]
Die Umsetzung im Umweltbundesamt erfolgte bzw. erfolgt nach folgendem Muster: Evaluierung ( Prototyp ( Aufbau der Infrastruktur ( Übergabe an die Linie.
4.1.
Evaluierung ^
[22]
Der Produktenscheidung ging eine Aufgrund der definierten – bereits oben erwähnten – speziellen Anforderungen eine Produktevaluierung voran. Es wurden zwei «Closed Source» und zwei «Open Source» Produkte evaluiert.
[23]
Es gab jeweils eine allgemeine Produktvorstellung und exemplarische Umsetzungen der definierten Anforderungen. Knackpunkt war einerseits die im Haus verwendete Technologie (Java und Oracle als strategische Unternehmensdatenbank) andererseits die Lizenzierungskosten. Typischerweise werden klassische BI Produkte für eine (geringe) Anzahl hausinterner «Named User» lizensiert. Da dies in unserem Fall nicht möglich ist (Auswertungen sollen auch über das Internet angeboten werden können) wurde eine Open Source Variante gewählt. Weiters ist der Source Code bekannt und kann gemäß unseren spezifischen Anforderungen erweitert werden.
4.2.
Prototyp ^
[24]
Nach der Entscheidung wurde ein erster Prototyp zur Überprüfung von Firmenmeldungen für Sachbearbeiter in den Bundesländern umgesetzt.
4.3.
Projekt: Aufbau der Infrastruktur ^
[25]
Aufgrund der positiven Erfahrung wurde hausintern ein Projekt zum operativen Aufbau der entsprechenden Infrastruktur aufgesetzt.
4.3.1.
Konzeption ^
[26]
Da es sich bei einem Datawarehouse um einen langfristigen Prozess handelt, muss dieser sauber aufgesetzt werden. Das bedingt natürlich eine konzeptive Phase, innerhalb derer folgender Punkte zu klären sind.
- Organisatorisch: Da das Datawarehouse nach Projektablauf in die «Linie» übergeben wird, sind Verantwortlichkeiten und Abläufe zu klären.
- Technisch: Die technische Architektur, Technologien, Konventionen (z.B. Tabellennamen, Spaltennamen, Security, Change Management, Qualitätssicherung, …) sind festzulegen.
4.3.2.
Proof of Concept ^
[27]
Da alle Theorie grau ist müssen natürlich die entwickelten Konzepte möglichst früh auf Ihre Praxistauglichkeit überprüft werden. Dies wurde mittels interner Piloten und Friendly User umgesetzt.
[28]
Die Konzepte wurden intern anhand von 3 Pilotprojekten überprüft und entsprechend der «Lessons learned» adaptiert.
5.
Schlussfolgerung ^
[29]
Ein Datawarehouse ermöglicht einen leichteren Zugriff auf Daten zur Entscheidungsfindung und für Analysen.
[30]
Der wesentliche Mehrwert liegt in den mehrfach verwendbaren qualitätsgesicherten Daten (= «Single Point of Truth» im Unternehmen) und in der Ermöglichung von themenübergreifenden Abfragen.
[31]
Es vereinfacht Datenzugriffe und der Möglichkeiten zur Analyse.
[32]
Das Datawarehouse stellt somit ein Tool dar, mittels dem man aus unterschiedlichen Quellsystemen qualitätsgesicherte Entscheidungsgrundlagen für Politik, Behörden, Experten und die interessierte Öffentlichkeit zur Verfügung stellen kann.
Michael Hadrbolec, Kompetenzfeldleiter Datawarehouse, Umweltbundesamt GmbH, Abteilung IT Entwicklung, Spittelauer Lände 5, 1090 Wien, AT,michael.hadrbolec@umweltbundesamt.at ;www.umweltbundesamt.at
Michael Hadrbolec, Kompetenzfeldleiter Datawarehouse, Umweltbundesamt GmbH, Abteilung IT Entwicklung, Spittelauer Lände 5, 1090 Wien, AT,michael.hadrbolec@umweltbundesamt.at ;www.umweltbundesamt.at
