Projektgruppe Business Intelligence Applications and Evaluation ...

Projektgruppe Business Intelligence Applications and Evaluation 

Projektdokumentation 

Abteilung Wirtschaftsinformatik 1: 

Very Large Business Applications 

Betreuer: 

Prof. Dr.-Ing. Jorge Marx Gómez 

Benjamin Wagner vom Berg 

Andreas Solsbach

Projektgruppe Cuberunner 

Einleitung 

2


Einleitung 

Inhaltsverzeichnis 

Einleitung ................................................................................................................................... 5 

Jinengo ....................................................................................................................................... 9 

Fachkonzept ........................................................................................................................... 9 

DV-Konzept ........................................................................................................................ 43 

Dokumentation .................................................................................................................. 117 

CeWe ...................................................................................................................................... 187 

Fachkonzept ....................................................................................................................... 187 

DV-Konzept ...................................................................................................................... 203 

Machbarkeitsanalyse ......................................................................................................... 239 


Smart Wind Farm Control ...................................................................................................... 371 

Fachkonzept ....................................................................................................................... 371 

DV-Konzept ...................................................................................................................... 411 


Technischer Vergleich ............................................................................................................ 637 

Fazit ........................................................................................................................................ 673 

Anhang ................................................................................................................................... 677 

Protokolle .......................................................................................................................... 679 

Seminararbeiten ................................................................................................................. 841 

3


Einleitung 

Tabellenverzeichnis 

Tabelle 1: Mitglieder und Rollen ............................................................................................... 5 

Tabelle 2: Zuordnung Seminararbeitsthemen ............................................................................ 6 

Tabelle 3: Kleingruppenaufteilung ............................................................................................. 7 

4


Einleitung 

Einleitung 

Im Rahmen des Masterstudiums der Wirtschaftsinformatik an der Carl von Ossietzky Universität 

Oldenburg ist vorgesehen, dass jeder Studierende dieses Studiengangs innerhalb einer Projektgruppe 

eine Aufgabenstellung bearbeitet. Die Projektgruppe Business Intelligence Applications and Evaluation 

(Projektgruppe Business Intelligence (BI)) wurde von Prof. Dr. Jorge Marx Gómez initiiert. Diese 

Projektgruppe ist am 01. April 2012 gestartet und endet nach zwei Semestern Laufzeit am 31. März 

2013. Die Projektgruppe ist mit einem wöchentlichen Arbeitsaufwand von 16-20 Stunden pro Studierenden 

über die gesamte Projektzeit sowie drei Wochen Urlaubsanspruch definiert. 

Die Projektgruppe BI besteht aus 13 Studierenden der Universität Oldenburg, die in dieser verschiedene 

Rollen wahrnehmen. Bereits zu Projektbeginn wurden einige Rollen verteilt. Im Laufe der Projektzeit 

hat sich jedoch die Rollenverteilung verschoben bzw. erweitert, insbesondere aufgrund der Einteilung 

in Klein- bzw. Teilgruppen. Manche Rollen haben an Bedeutung verloren oder sich in die Teilgruppen 

verlagert, wie etwa Projektleitung, Pressesprecherin, Technologie- sowie 

Test/Qualitätsmanagement (QM)-Beauftragter. Die Rolle des Teilgruppenleiters hingegen kam dazu. 

Nachfolgend werden die Studierenden und ihre Rollen aufgeführt. 

Benjamin Weinert 

Björn Kreye 

Christopher Grünhäuser 

Deyan Stoyanov 

Fatih Mehmet Inel 

Henning Tomann 

Lars Schüttemeyer 

Marcel Severith 

Michael Schumann 

Patrick Böwe 

Ronja Queck 

Thees Gieselmann 

Wiebke Meyer 

Homepagebeauftragter 

Sozialbeauftragter 

Technologiebeauftragter MS 

Projektleiter 

Technologiebeauftragter SAP, Teilgruppenleiter Analytical 

CRM 

Test/QM-Beauftragter 

Homepagebeauftragter, Vertretung des Projektleiters 

Teilgruppenleiter Jinengo 

Finanzbeauftragter 

Server-Beauftragter, Teilgruppenleiter Smart Wind Farm 

Control 

Pressesprecherin 

Dokumentationsverwalter 

Test/QM-Beauftragte 

Tabelle 1: Mitglieder und Rollen 

Neben den Studierenden wird die Projektgruppe von einer Anzahl fachlich versierter Personen betreut. 

Diese stammen zum einen aus dem universitären Umfeld und zum anderen aus der freien Wirtschaft. 

In den ersten Monaten wurde die Projektgruppe durch Jennifer Osmers (BTC AG), Benjamin Wagner 

vom Berg und Oliver Norkus (beide Universität Oldenburg) sowie Dr. Joachim Marz (CEWE Color 

5


Einleitung 

AG und Co. OHG (CEWE)) unterstützt. Im weiteren Verlauf der Projektgruppe sind Jennifer Osmers 

und Oliver Norkus durch Andreas Solsbach (Universität Oldenburg) ersetzt worden. 

Die Projektgruppe hat sich den Eigennamen Cuberunner gegeben. Der Name basiert auf der Erstellung 

von Datenwürfeln, sogenannten Cubes, welche in BI Projekten wesentliche Bestandteile sind. Im 

fachlichen Umfeld soll mit dem Namen Cuberunner die unmittelbare Assoziation mit BI hergestellt 

werden. 

Über einen Zeitraum von einem Jahr hat sich die Projektgruppe in drei wesentliche Phasen organisiert. 

Zu diesen zählen die Findungsphase, die Interview- und Seminararbeitsphase und die Projektphase. 

In der Findungsphase haben sich die Studierenden in ihren jeweiligen Rollen organisiert und mit Hilfe 

der Betreuer eine grobe Abgrenzung von insgesamt drei Anwendungsfällen vorgenommen. Die jeweiligen 

Anwendungsfälle werden voneinander unabhängig in Klein- bzw. Teilgruppen bearbeitet. 

In der nachfolgenden Interview- und Seminararbeitsphase wurden relevante Themen der BI durch die 

Studierenden bearbeitet. Die Seminararbeiten sind im Anhang zu finden. Das erarbeitete Wissen der 

Seminararbeiten wurde in die gesamte Projektgruppe hineingetragen. Die nachfolgende Tabelle zeigt 

die von den jeweiligen Studierenden bearbeiteten Seminararbeiten. 


Analytical Customer Relationship Management (CRM) 

Björn Kreye Neuerungen in SAP NW BW 7.3 und SAP BO 4.0 

Christopher Grünhäuser Stammdatenmanagement und Konsolidierung 


Vergleich MS und SAP BI 


MS SQL Server 2012 und MS BI-Tools 


BI mit Excel, PowerPivot, Power View 


Mobile BI 


Anforderungsanalyse und Konzeptarbeit 

Michael Schumann In Memory 

Patrick Böwe 

Testen und Dokumentieren von BI Applikationen 

Ronja Queck 

Data Mining 


Nachhaltigkeit und BI 

Wiebke Meyer 

Management von BI Projekten 

Tabelle 2: Zuordnung Seminararbeitsthemen 

Zum anderen wurden in dieser Phase Interviews zur Spezifizierung der Anwendungsfälle mit fachkompetenten 

Personen durchgeführt. Weiterhin wurde diese Phase genutzt, um die Projektteilnehmer 

hinsichtlich ihrer Präferenzen den einzelnen Anwendungsfällen zuzuordnen. Die folgende Tabelle 

zeigt die Aufteilung der Projektgruppe in die spezifischen Kleingruppen. 

6


Einleitung 

Analytical CRM 

Nachhaltige Mobilität 

Smart Wind Farm 


Björn Kreye 



Wiebke Meyer 

Christopher Grünhäuser 





Michael Schumann 

Patrick Böwe 

Ronja Queck 

Tabelle 3: Kleingruppenaufteilung 

In der Projektphase bearbeiten die Kleingruppen ihre Anwendungsfälle separat. Damit ein teilprojektübergreifender 

Austausch sowie eine mögliche Unterstützung untereinander erfolgen kann, werden 

wöchentliche Treffen der gesamten Projektgruppe inklusive Betreuer durchgeführt und protokolliert 

(siehe Anhang). Die Treffen teilen sich in externe und interne Diskussionsrunden auf, wobei die externen 

Treffen mit den Betreuern stattfinden. 

Das Ziel der Gruppe Nachhaltige Mobilität ist es, die im Vorjahr stattgefundene universitäre Projektgruppe 

Jinengo fortzusetzen. Es soll mit Hilfe analytischer Methoden der BI das Mobilitätsverhalten 

der Anwender analysiert und dargestellt werden (S. 9 - 187). Weiterhin sollen Anreize für ein nachhaltigeres 

Verhalten der Anwender geschaffen werden. 

Die Analytical CRM Gruppe beschäftigt sich mit dem Projekt „gestochen scharfe Fragen stellen“ bei 

CEWE (S. 187 - 371). Das Projekt behandelt die systematische Erfassung, Historisierung und Analyse 

von Kundenumfragen auf Basis einer einheitlichen Datengrundlage. Als Ansprechpartner für die Teilgruppe 

fungiert seitens CEWE Herr Dr. Joachim Marz, Leiter der IT. 

Im Rahmen der Gruppe Smart Wind Farm Control wird die Problematik des erhöhten Wartungsaufwandes 

von Windenergieanlagen im Offshore-Bereich thematisiert. Ziel ist die Entwicklung einer 

Windpark-Maintenance-Plattform auf Basis des In-Memory Systems SAP HANA. Hiermit soll das 

gesamte Datenaufkommen von Windenergieanlagen erfasst werden können. Zudem sollen unter Verwendung 

von Data Mining Methoden Fehlerketten innerhalb der Daten aufgezeigt und für eine vorausschauende 

Wartung genutzt werden (S. 371 -636). 

Mit Hilfe eines Technologievergleiches sollen die in den drei Teilprojekten verwendeten Softwarelösungen 

projektübergreifend bewertet und verglichen werden. 

7


Einleitung 

Diese Dokumentation beinhaltet die ausgearbeiteten Dokumente der einzelnen Kleingruppen und den 

Technologievergleich. Im Anhang befinden sich alle Seminararbeiten und Protokolle die im Laufe der 

Projektzeit erstellt wurden. 

8


Jinengo - Fachkonzept 

Projektgruppe Business Intelligence 


Gruppe: Jinengo 

Fachkonzept 

9



10



Inhaltsverzeichnis Jinengo Fachkonzept 

Abbildungsverzeichnis ............................................................................................................. 12 

Tabellenverzeichnis .................................................................................................................. 12 

Abkürzungsverzeichnis ............................................................................................................ 13 

1. Einleitung .......................................................................................................................... 14 

2. Vision und Ziele ................................................................................................................ 14 

2.1 Nachhaltige Mobilität ................................................................................................... 14 

2.2 Projektziele ................................................................................................................... 15 

3. Rahmenbedingungen ......................................................................................................... 17 

3.1 Vorgaben aus der BI-Strategie ..................................................................................... 17 

3.2 Projektspezifische technische & organisatorische Bedingungen ................................. 18 

3.3 Stakeholder-Definition ................................................................................................. 18 

3.3.1 Projektstakeholder ............................................................................................. 19 

3.3.2 Jinengo-Stakeholder .......................................................................................... 19 

4. Business Questions und Business Needs .......................................................................... 20 

5. Analytische Anforderungen .............................................................................................. 21 

5.1 Reports & Dashboards .................................................................................................. 21 

5.1.1 Dashboards für Endanwender ............................................................................ 22 

5.1.2 Reporting für Management, Mobilitätsanbieter & Wissenschaftler .................. 23 

5.1.3 Self-Service BI für das Jinengo-Management ................................................... 25 

5.2 Data Mining .................................................................................................................. 26 

5.2.1 Eigenschaften Raten .......................................................................................... 26 

5.2.2 Newsletter & Reporting ..................................................................................... 26 

5.2.3 Ökologische Alternativen Vorschlagen ............................................................. 27 

5.2.4 Warnung vor ungewöhnlichem Verhalten ......................................................... 27 

6. Kennzahlen ....................................................................................................................... 27 

7. Semantische Modellierung ................................................................................................ 29 

7.1 Messgrößen................................................................................................................... 29 

7.2 Dimensionen ................................................................................................................. 30 

8. Nichtfunktionale Anforderungen ...................................................................................... 31 

9. Literaturverzeichnis .......................................................................................................... 32 

Anhang ..................................................................................................................................... 34 

A. 

B. 

Projektmanagement ........................................................................................................... 34 

Kennzahlensteckbriefe ...................................................................................................... 35 

11



Abbildungsverzeichnis 

Abbildung 7.1: Semantische Modellierung .............................................................................. 29 

Abbildung A.1: GANTT-Diagramm des Projektablaufs ......................................................... 34 


Tabelle 6.1: Übersicht über die Kennzahlen ............................................................................ 28 

Tabelle B.1: Kennzahlensteckbrief J01 .................................................................................... 35 



Tabelle B.4: Kennzahlensteckbrief M01 .................................................................................. 36 






Tabelle B.10: Kennzahlensteckbrief M07 ................................................................................ 39 





12



Abkürzungsverzeichnis 

BI Business Intelligence 

CRM Customer Relationship Management 

ÖPNV Öffentlicher Personennahverkehr 

SPARQL Protocol And RDF Query Language (Abfragesprache für RDF) 

13



1. Einleitung 

Die Softwareplattform Jinengo bietet Endanwendern die Möglichkeit, Reiserouten unter Einbeziehung 

verschiedener Verkehrsträgern und Beachtung ökologischer Aspekte zu planen (Wagner vom Berg & 

Stamer 2012; Wagner vom Berg et al. 2012). Jinengo fehlt allerdings bislang eine analytische Aufbereitung 

und Darstellung der im Rahmen der operativen Nutzung anfallenden Daten. Ziel dieses Projektes 

ist es daher, mit Methoden der Business Intelligence (BI) das Mobilitätsverhalten der Anwender zu 

analysieren und darzustellen. Zudem sollen Rückschlüsse gezogen werden, wie das Angebot von 

Jinengo zielgruppenspezifischer und damit attraktiver gemacht werden kann. Auf diese Weise sollen 

neue Anreize für ein nachhaltigeres Reiseverhalten geliefert werden. 

Die Projektgruppe soll daher festgelegte analytische Anwendungsfälle mit Methoden der Business 

Intelligence exemplarisch umsetzen, um so eine zukünftige BI-Architektur von Jinengo aufzuzeigen. 

2. Vision und Ziele 

2.1 Nachhaltige Mobilität 

Nachhaltigkeit im Sinne der Brundtland-Definition meint die Befriedigung heutiger Bedürfnisse, ohne 

zukünftige Generationen dabei in ihren Entwicklungsmöglichkeiten zu behindern (United Nations 

1987). Das Dreisäulenmodell der Nachhaltigkeit versucht ökonomische, soziale und ökologische Anforderungen 

miteinander in Einklang zu bringen (Deutscher Bundestag 1998). Da die natürliche Umwelt 

jedoch letztendlich den begrenzenden Rahmen für alle gesellschaftlichen und damit auch ökonomischen 

Tätigkeiten setzt, kann die Ökologie auch als bedeutendste der drei Dimension angesehen 

werden. 

Jinengo hat es sich zum Ziel gesetzt, nachhaltige Mobilität mithilfe einer attraktiven 1 Plattform zu 

fördern. Die Plattform schafft Anreize, um definierte Strecken mit Start und Zielpunkt auf möglichst 

nachhaltige Weise zurückzulegen. Dazu werden dem Endanwender verschiedene Alternativen vorgeschlagen, 

die Wegstrecke intermodal (mit verschiedene Verkehrsträgern) zurückzulegen. Dabei werden 

insbesondere ökologischer Aspekte betrachtet, allerdings ist auch die Integration sozialer Aspekte 

grundsätzlich denkbar. 

1 Motivation zur Nutzung der Plattform kann so beispielsweise eine Verbesserung der Nachhaltigkeit im eigenen 

Verhalten, die Erhöhung der nutzbaren Reisezeit (z.B. im Zug), die Kommunikation des eigenen Verhaltens 

(z.B. über soziale Netzwerke) oder auch eine Zeitersparnis bei der Reiseorganisation sein. 

14



Um einen Beitrag zu einer nachhaltigen Mobilität zu leisten, ist eine rege Benutzung von Jinengo notwendig. 

Dies liegt zum einen in der Annahme begründet, dass sich nur mit der Verwendung von 

Jinengo das eigene Mobilitätsverhalten optimal planen lässt. Zum anderen entsteht durch die intensive 

Nutzung der Plattform eine quantitative Datenbasis, durch die sich die Qualität von Datenanalysen 

steigern lässt. Durch diese Analyseergebnisse lässt sich die operative Jinengo-Plattform verbessern 

und damit die Wirksamkeit im Rahmen einer nachhaltigen Mobilität erhöhen. Attraktivität und Nutzung 

der Plattform sind daher von zentralem Interesse für die Anwendung von BI-Methoden vor dem 

Hintergrund nachhaltiger Mobilität. Gleichzeitig sind die Methoden der Business Intelligence aber 

auch geeignet, ihren Teil zur Steigerung der Attraktivität der Plattform beizutragen. 

2.2 Projektziele 

Im Rahmen des vorliegenden BI-Projekts werden die folgenden Ziele für die weitere Entwicklung von 

Jinengo identifiziert. 

Ziel 1: Analyse des Mobilitätsverhaltens der Endanwender 

Vor dem Hintergrund der Förderung einer nachhaltigen Mobilität durch Anbieten einer attraktiven 

Plattform zielt Jinengo auf die Beeinflussung des Mobilitätsverhaltens der Endanwender. Mit den Methoden 

der Business Intelligence sollen Muster im Mobilitätsverhalten der Endanwender entdeckt 

werden. Angestrebt wird ein größtmögliches Verständnis, warum sich Endanwender für eine entsprechende 

Routenalternative entschieden haben. 

Ziel 2: Visualisierung des Mobilitätsverhaltens der Endanwender 

Business Intelligence soll das tatsächliche Mobilitätsverhalten der Endanwender visualisieren. Endanwender 

sollen sich über ihr bisheriges Verhalten informieren und graphisch die wichtigsten Mobilitätsdaten 

ablesen können. Auf diese Weise erhalten Anwender die Möglichkeit, den Grad ihrer Nachhaltigkei 

zu bewerten. Die Darstellung dient zudem der Motivation eines nachhaltigeren Verhaltens. 

Die Fokussetzung auf mobile Anwendungen soll zudem die Attraktivität der Jinengo-Plattform steigern. 

15



Auch für das Jinengo-Management und andere externe Interessenten sollen Mobilitätsdaten auf adäquate 

Art dargestellt werden. So haben beispielsweise Anbieter von E-Autos & ÖPNV, aber auch Car- 

Sharing-Anbieter ein großes Interesse an entsprechenden Daten. Auf diese Weise ließe sich die finanzielle 

Tragfähigkeit der Plattform sichern, die sich langfristig selbst finanzieren können soll. 2 

Ziel 3: Verbesserung der durch Jinengo getroffenen Mobilitätsvorschläge 

Die Datenbasis der in der Vergangenheit gewählten Routen sowie endanwenderbezogene Attribute 

werden bei der Berechnung von Mobilitätsvorschlägen 3 bislang noch nicht berücksichtigt. Stattdessen 

werden diese Daten bisher lediglich gesammelt und gespeichert. Methoden, um diese Datenbasis zu 

analysieren, Wissen zu generieren und Entscheidungen abzuleiten, fehlen jedoch bislang. Die Speisung 

von analytisch gewonnenem Wissen in die operativen Prozesse realisiert den sogenannten 

Closed-Loop des CRM (Helmke et al. 2003). Dadurch verbessert sich die Leistungsfähigkeit von 

Jinengo, zielgruppengerechte Mobilitätsalternativen vorzuschlagen. Für den Fahrer eines besonders 

spritverbrauchenden Autos erscheint so unter Umständen der Wechsel auf den ÖPNV nicht als wirkliche 

Alternative. Die Empfehlung eines spritsparenden Autos wäre unter diesen Umständen unter Umständen 

die bessere Alternative. Dafür müssen vorhandene Daten mit Methoden des Data Minings auf 

Ähnlichkeiten und Muster hin überprüft werden. Bezogen auf das Beispiel kann so eine Gruppe von 

Autofahrern mit ähnlichen Eigenschaften identifiziert werden. Es lassen sich dann Mobilitätsalternativen 

anbieten, die bei ähnlichen Anwendern zuvor bereits Anklang gefunden haben. Ziel der Projektgruppe 

ist es, Ansätze zur Datenanalyse mit BI-Methoden aufzuzeigen und exemplarisch darzustellen. 

Die Integration dieses neu gewonnenen Wissens in das operative System ist hingegen nicht Teil dieses 

Ziels. 

2 Die Visualisierung der Daten für externe Verwendung stellt dabei jedoch eine besondere Herausforderung dar. 

So muss insbesondere die Unabhängigkeit der Jinengo-Plattform gewährleistet bleiben. Die Glaubwürdigkeit 

Jinengos würde stark darunter leiden, würde es von Mobilitätsanbietern selbst finanziert werden. Dies könnte 

suggerieren, der Mobilitätsanbieter habe einen Einfluss auf die Darstellung der Suchergebnisse und das eigene 

Mobilitätsverhalten werde von Jinengo aus rein monetären Gründen beeinflusst. 

3 Die Leistung von Jinengo liegt insbesondere in der Generierung von Routenvorschlägen. Gleichzeitig werden 

jedoch auch andere Methoden genutzt, um Einfluss auf das Mobilitätsverhalten des Endanwenders zu nehmen. 

So können insbesondere durch Marketingmaßnahmen Verhaltensmuster allgemein verändert werden, 

z.B. die Unterbreitung eines Angebots für ein E-Bike. 

16



3. Rahmenbedingungen 

3.1 Vorgaben aus der BI-Strategie 

Die Projektgruppe Cuberunner der Carl von Ossietzky Universität Oldenburg beschäftigt sich mit der 

Entwicklung von Anwendungen im Umfeld der Business Intelligence. Vorab wurden dabei drei zu 

bearbeitende Anwendungsfälle definiert: Analytisches CRM (in Kooperation mit der CeWe Color), 

Sustainability CRM für nachhaltige Mobilität (Jinengo) & SmartWindFarm. Abseits eines gemeinsamen 

Aufbaus und Transfers von Knowhow (u.a. durch die Seminararbeiten) erfolgt die Bearbeitung 

der einzelnen Anwendungsfälle in personell getrennten Kleingruppen. Die Absprache der einzelnen 

Kleingruppen erfolgt durch regelmäßige Treffen. Folgende Rahmenbedingungen wurden auf Ebene 

der übergeordneten Projektgruppe vereinbart und sind daher auch für die Jinengo-Kleingruppe von 

Bedeutung. 

Die übergeordnete Projektgruppe hat sich auf ein Vorgehensmodell für die Softwareentwicklung geeinigt, 

das in allen Kleingruppen verwendet werden soll. Als zentrale Artefakte werden Fachkonzept 

und DV-Konzept erstellt. Inhalte und Gliederung von Fachkonzept und DV-Konzept sind innerhalb 

der übergeordneten Projektgruppe abgestimmt. Die Realisierung erfolgt dabei angelehnt an agile Modelle. 

Zu Beginn wird daher ein vorläufiges Fachkonzept verfasst und auch formal abgenommen. Im 

Laufe des Projekts wird dieses Fachkonzept weiter ausgearbeitet und dient so anschließend auch dokumentarischen 

Zwecken. Die Fertigstellung des DV-Konzepts erfolgt gegen Mitte der Realisierungsphase. 

Über alle Anwendungsfälle hinweg wird ein Vergleich der verschiedenen eingesetzten BI- 

Technologien angestrebt. Dazu wird begleitend zur Realisierung ein Kriterienkatalog für diesen Technologievergleich 

entwickelt. Der Vergleich der verschiedenen Technologien auf Grundlage des Katalogs 

erfolgt gegen Projektende. 

17



3.2 Projektspezifische technische & organisatorische 

Bedingungen 

Die Routenplanungssoftware Jinengo wurde im Rahmen einer Projektgruppe der Wirtschaftsinformatik 

an der Carl von Ossietzky Universität Oldenburg entwickelt. Endanwender können sich mithilfe 

unterschiedlicher Endgeräte am System anmelden und erhalten Routenvorschläge für angefragte Reiseziele. 

Die Software ist grundsätzlich funktionstüchtig, wurde einer breiteren Öffentlichkeit allerdings 

bislang nicht aktiv vorgestellt. Die Konzeption und Entwicklung analytischer Anwendungen im 

Kontext der Business Intelligence ist bisher noch nicht erfolgt. 

Für eine erfolgreiche Anwendung von Methoden der Business Intelligence fehlt zum jetzigen Stand 

eine quantitativ sowie qualitativ ausreichende Datenbasis. So werden viele, für umfangreiche analytische 

Auswertungen benötigte, Daten bislang nicht erhoben. Zudem fehlt es Jinengo an der kritischen 

Masse an regelmäßigen Anwendern, um aus ihrem Mobilitätsverhalten auch adäquate Schlüsse ziehen 

zu können. Die Entwicklung einer BI-Anwendung auf Basis realer Daten erscheint aufgrund dieser 

Ausgangslage derzeit nicht praktikabel. 

Für die Erweiterung von Jinengo um Methoden der Business Intelligence wird daher stattdessen eine 

für diesen Zweck vollständige Datenbasis angenommen. Auf Basis der analytischen Anforderungen 

wird dafür zunächst eine idealtypische Datenstruktur entworfen und geeignete Testdaten generiert. 

Auf Basis dieser theoretischen Ausgangslage kann dann die Realisierung der BI-Anwendungen idealtypisch 

und losgelöst von den bisherigen operativen Hemmnissen erfolgen. 

Nach Fertigstellung der BI-Anwendung kann die Beeinflussung des operativen durch das analytische 

BI-System realisiert werden. Zudem muss die eigentliche Anbindung des operativen Systems an die 

idealtypisch entworfene Datenstruktur erfolgen, damit sich diese zukünftig auch aus dem operativen 

System speist. Zu diesem Zweck muss das operative System angepasst und weiterentwickelt werden. 

Diese Anpassung des operativen Systems ist allerdings nicht Aufgabe dieses Projekts. 

3.3 Stakeholder-Definition 

Die Stakeholder des Jinengo-Projekts lassen sich in zwei Gruppen einteilen. Zum einen lassen sich 

direkte Projektstakeholder identifizieren. Zum anderen sind bei der (gedanklichen) Überführung von 

Jinengo in einen operativen Betrieb weitere Stakeholder denkbar. Da diese für die Identifizierung von 

späteren Berechtigungsrollen für das BI-System von besonderer Bedeutung sind, werden auch diese 

Stakeholder im Folgenden ermittelt. 

18



3.3.1 Projektstakeholder 

Jinengo-Kleingruppe / Entwickler: Die Jinengo-Kleingruppe der Projektgruppe Cuberunner besteht 

aus den Studenten Lars Schüttemeyer, Thees Gieselmann, Christopher Grünhäuser und Marcel Severith. 

Auftraggeber: Der Auftraggeber wird repräsentiert durch Benjamin Wagner vom Berg. 

Projektgruppe Cuberunner: Die Projektgruppe besteht einerseits aus den studentischen Mitgliedern 

der Projektgruppe und andererseits aus der Gruppe der Betreuer. Neben den Mitgliedern der Teilgruppe 

Jinengo haben auch die anderen Teilnehmer der Projektgruppe ein Interesse an der Umsetzung der 

Teilgruppe. Die Betreuer beraten die Teilgruppe und stehen mit ihrem Wissen zur Verfügung. Ursprünglich 

wurde die Projektgruppe von Oliver Norkus, Jennifer Osmers & Benjamin Wagner vom 

Berg betreut. Durch personelle Veränderung übernahm Andreas Solsbach die Rolle von Oliver Norkus 

und Jennifer Osmers. Insbesondere die Betreuer haben ein Interesse an den Ergebnissen der Teilgruppe, 

mit deren Hilfe Jinengo weiterentwickelt werden soll. Beide Teile dieses Stakeholders unterstützen 

Jinengo und beeinflussen das Teilprojekt durch bspw. die Festlegung von Rahmenbedingungen. 

Ehemalige Projektgruppe Jinengo: Die Mitglieder der ehemaligen Jinengo-Projektgruppe stehen für 

konkrete Rückfragen zum Teil weiterhin zur Verfügung und liefern externes Knowhow in Form von 

Masterarbeiten, etc. 

3.3.2 Jinengo-Stakeholder 

Jinengo-Endanwender: Zentraler Stakeholder und ein maßgeblicher Indikator für Erfolg bzw. Misserfolg 

der Plattform ist der Nutzer der Jinengo-Plattform. Die Endanwender von Jinengo interagieren 

mit dem System und generieren dabei verschiedene Daten. Erst auf Basis einer umfangreichen Datengrundlage 

können die diversen Methoden der BI gewinnbringend eingesetzt werden. Des Weiteren 

sind die Endanwender Adressaten von Vorschlägen und Maßnahmen, die im Rahmen der Anwendung 

von BI generiert werden. 

Jinengo-Management: Die strategische Ausrichtung von Jinengo ist für dessen Zukunftsfähigkeit 

wichtig. Dazu gehört auch, die stetige Anpassung an Veränderungen und daraus resultierende Anpassung 

der Strategie. Die Führungskräfte von Jinengo brauchen für die Erfüllung dieser Aufgabe vollständige 

Analysen über die Endanwender des Systems sowie deren Nachhaltigkeitsperformance. Das 

Management benötigt diese Daten dafür sinnvoll aggregiert und bspw. in Reports und Dashboards 

sinnvoll aufbereitet. 

Mobilitätsanbieter: Mobilitätsanbieter haben ein Interesse an der Jinengo-Datenbasis, um diese im 

Rahmen eigener Kampagnen und dem gezielten Marketing zu verwenden. Des Weiteren bietet sich so 

19



für Mobilitätsanbieter die Möglichkeit ihr eigenes Angebot zu verfeinern. Ein Car-Sharing-Anbieter 

der bspw. feststellt, dass in einem Stadtteil, in dem er keine Autostellplätze besitzt, viele potentielle 

Car-Sharer leben, könnte diese Information nutzen, um die Geschäftstätigkeit in eben diesem Bereich 

auszubauen. Zudem sind die Mobilitätsanbieter eine mögliche Finanzierungsquelle für Jinengo, wobei 

hier unter Betracht der in Kapitel 1 genannten Probleme, vorsichtig vorgegangen werden muss. Die 

Mobilitätsanbieter sollten folglich auf keinen Fall einen direkten Zugriff auf das System erhalten, oder 

dessen Daten frei lesen können. Stattdessen ist eine gezielte Übergabe von Datenpaketen sowie Reports 

sinnvoll. Diese Pakete können entweder vordefiniert von Jinengo bereitgestellt werden, oder in 

Kommunikation mit dem Mobilitätsanbieter ausgehandelt werden. 

Wissenschaftler: Wissenschaftler die in dem Bereich Mobilität forschen und ein Interesse an umfangreichen 

Nutzungsstatistiken haben. Diesen werden, auf Anfrage, anonymisierte Daten zur Verfügung 

gestellt. 

4. Business Questions und Business Needs 

Die Business Questions und Business Needs ergeben sich analog zu den zuvor identifizierten Jinengo- 

Stakeholdern. 

Jinengo-Endanwender: Wie nachhaltig ist das eigene Mobilitätsverhalten? Wie ist das Verhalten im 

Vergleich zu anderen Personengruppen zu bewerten? Gibt es sinnvolle Alternativen zu meiner jetzigen 

Mobilität? 

Jinengo-Management: Wie ist der Erfolg der Jinengo-Plattform zu bewerten? Wird sie regelmäßig 

genutzt? Wie lässt sich die Nachhaltigkeitsperformance der Jinengo-Endanwender bewerten? Wie 

lassen sich Endanwender zu einem nachhaltigeren Verhalten motivieren? Welche Anreize kann die 

Plattform für ein nachhaltigeres Verhalten geben? 

Mobilitätsanbieter: Welche Personen sind für welche Verkehrsträger empfänglich? Was sind die 

Gründe für ein Interesse an einem Verkehrsträger? Welche Vorzüge einzelner Verkehrsträger müssen 

gezielt hervorgehoben werden, um eine Person zur Nutzung zu bewegen? Wie muss für ein konkretes 

Angebote geworben werden? Wo gibt es Nachfrage nach dem eigenen Angebot, dass im Moment 

nicht abgedeckt wird? 

Wissenschaftler: Was motiviert Menschen sich nachhaltig zu verhalten? Welche Hindernisse gibt es? 

Welche Anreize benötigen verschiedene Zielgruppen für eine Veränderung ihrer Gewohnheiten? 

20



5. Analytische Anforderungen 

Die zuvor in Kapitel 2 thematisierten Ziele lassen sich in analytischen Anforderungen näher konkretisieren. 

Mobilitätsverhalten lässt sich durch Methoden des Data Minings analysieren, zur Visualisierung 

dienen Reports & Dashboards. 

5.1 Reports & Dashboards 

Reports stellen eine detaillierte, komplexe und statische Darstellung von Daten sowie Kennzahlen dar. 

Im Gegensatz dazu sind Dashboards in ihrem Detailierungsgrad beschränkt und erlauben eine interaktive 

Zusammenstellung der dargestellten Daten (Urban 2012). 

Ziel des Projektes ist es, ein festes Set exemplarischer Reports & Dashboards zur Verfügung zu stellen. 

Die Reports und Dashboards sollen dabei den Anforderungen und Berechtigungen der unterschiedlichen 

Stakeholder gerecht werden. Unterschieden wird dabei zwischen den Reportinganforderungen 

von Endanwender auf der einen, sowie den Reportinganforderungen von Jinengo-Management, Mobilitätsanbietern 

und Wissenschaftlern auf der anderen Seite. Die Darstellung der Daten kann dabei jeweils 

wie folgt unterschieden werden: 

 

 

 

Reports: detaillierte, umfassende, meist zahlenbasierte Reports. Schwerpunkt liegt auf einem 

tiefen Informationsgehalt (bspw. hohe Anzahl wählbarer Dimensionen). 

Dashboards: einfache, prägnante Abbildung von relevanten Kennzahlen. Schwerpunkt liegt 

auf der visuellen Gestaltung (bspw. Übersichtlichkeit) des Services. 

Self-Service BI: flexible Darstellung von Informationen. Der Stakeholder bestimmt dabei 

größtenteils selbst, welche Informationen auf welche Weise dargestellt werden sollen. 

Im Folgenden werden die Anforderungen der Stakeholder beschrieben. Bei Endanwendern liegt der 

Fokus auf Dashboards, da diese Daten aggregiert und damit besonders verständlich darstellen. Reports 

und Self-Service BI hingegen werden nicht benötigt und würden eine Überforderung des Anwenders 

bedeuten. Für das Jinengo-Management hingegen werden aufgrund der mitunter tiefgreifenden Analyseanforderungen 

Dashboards, Reports und Self-Service BI als Darstellungsformen definiert. Die Reportinganforderungen 

von Wissenschaftlern und Mobilitätsanbietern sind nicht von zentralem Projektinteresse 

und lassen sich zum jetzigen Zeitpunkt noch nicht endgültig definieren. Ihre Anforderungen 

an Reports & Dashboards werden daher zunächst zusammen mit denen des Jinengo-Managements 

definiert. Die Darstellungsart Self-Service BI wird für Mobilitätsanbieter und Wissenschaftler nicht 

definiert, da dies insbesondere den hohen Ansprüchen an den Datenschutz widersprechen würde. 

21



5.1.1 Dashboards für Endanwender 

Der Endanwender hat ein Interesse an Informationen über das eigene Fahrverhalten. Ein optisch ansprechendes 

Dashboard soll diesem Anspruch gerecht werden. Die dargestellten Graphen und Diagramme 

sollen nicht nur das Nachhaltigkeitsdenken des Benutzers fördern, sondern auch die Attraktivität 

und den Nutzen der Plattform erhöhen. 

Eine übersichtliche Darstellung wird durch Aggregation und Reduktion auf wenige, relevante Daten 

erreicht. Die Auswahl der Kennzahlen und deren Darstellung erfolgt durch interaktive Dashboards, in 

welchen der Anwender eigenständig navigieren kann. Die Navigation und Interaktion soll dabei so 

intuitiv wie möglich realisiert werden. Die Oberfläche sollte fast keiner Eingewöhnungszeit bedürfen 

und leicht von jeder Person, unabhängig vom technischen Vorwissen, bedienbar sein. Im Vordergrund 

steht zudem die Möglichkeit der Nutzung über ein mobiles Endgerät. Sowohl die verwendete Technik, 

als auch die Beschaffenheit der Oberfläche sollte eine mobile Nutzung ermöglichen. Dies bedingt 

unter anderem eine Optimierung für berührungssensitive Oberflächen. Hierbei sollte die Anwendung 

sowohl für Gesten, als auch bezüglich der Größe und Anpassbarkeit an mobile Anforderungen angepasst 

werden. Hierzu zählt zum Beispiel die automatische Anpassung der Chart-Größe an unterschiedliche 

Auflösungen der Endgeräte. Zudem sollten sich Navigationselemente an gewohnten Stellen befinden 

und auch bei kleineren Auflösungen leicht bedienbar sein. 

Inhalte der Dashboards 

Zentrales Element der Dashboards ist die Darstellung verschiedener Kennzahlen. So lassen sich die 

absoluten CO 2 -Emissionen, Reisezeit, Reisekosten und die zurückgelegte Strecke über die Dimension 

Zeit betrachten. Zudem werden die relativen CO 2 -Emission sowie Reisekosten pro Kilometer dargestellt. 

Zudem können die Kennzahlen nach Verkehrsmitteln aufgeschlüsselt werden. 

Durch die Darstellung von Vergleichswerten kann das eigene Verhalten in Relation zu anderen Personen 

gesetzt werden können. Referenz können dabei entweder befreundete Personen oder Durchschnittswerte 

der Plattform sein. Dem Anwender wird es so ermöglicht, sein eigenes Verhalten im 

Vergleich zu anderen Anwendern zu bewerten und ihm so eine neue Motivation für ein verändertes 

Verhalten zu geben. 

Vor dem Hintergrund nachhaltiger Mobilität ist insbesondere die Betrachtung des individuellen CO 2 - 

Ausstoßes relevant. Der CO2-Ausstoß wird daher in Vergleich gesetzt zu den Alternativen, die bei 

Reiseantritt zur Verfügung standen hatte. Je nach Wahl der Route ergibt sich eine CO 2 -Differenz in 

Bezug auf die best- bzw. die schlechtmöglichste Alternative. Diese Differenz wird innerhalb der Graphen 

zur Visualisierung der CO 2 -Emissionen abgebildet. Zudem dient ein Nachhaltigkeitstacho zur 

Visualisierung des CO 2 -Einsparpotentials des Endanwenders. 

22



Zusammenfassend lassen sich folgende Inhalte für die Dashboards definieren: 

 

 

 

 

Absolute CO 2 -Emission, Reisekosten, Reisezeit und zurückgelegte Strecke pro Jahr aggregiert 

auf Monatsbasis. Vergleichsmöglichkeit zum Durchschnitt oder einer Referenzperson. 

Relative CO 2 -Emission und Reisekosten pro Kilometer pro Jahr aggregiert auf Monatsbasis. 

Vergleichsmöglichkeit zum Durchschnitt oder einer Referenzperson. 

CO 2 -Emission, Reisekosten, Reisezeit und zurückgelegte Strecke aufgeschlüsselt nach Verkehrsmitteln 

im Vergleich zum Durchschnitt oder einer Referenzperson. 

CO 2 -Einsparpotential dargestellt durch einen Nachhaltigkeitstacho und einen Graphen, welcher 

die CO 2 -Emmision des Anwenders in Relation zu den höchst- bzw. geringstmöglichen 

Emissionen setzt. 

5.1.2 Reporting für Management, Mobilitätsanbieter & Wissenschaftler 

Das Management muss vor allem mittel- und langfristig ausgerichtete Entscheidungen treffen um den 

Erfolg der Plattform zu sichern. Hieraus begründet sich ihr Informationsbedarf an Jinengo. Dashboard 

& Reports sollen den Zeitaufwand für die Informationsbeschaffung verringern und die Informationsgrundlage 

vergrößern. Dabei kann der Inhalt der Dashboards & Reports variieren, je nachdem welches 

Ziel gerade genau verfolgt wird. Auch Mobilitätsanbieter haben ein großes Interesse an den von 

Jinengo gesammelten Daten. Ziel entsprechender Anbieter ist es, ihr Angebot besser an die aus den 

Daten erkennbaren Bedürfnisse anzupassen sowie potentielle Kunden für ihre Angebote zu finden. 

Diese Ziele verlaufen aber unter Umständen konträr zu den Interessen von Jinengo. Daher ist die Weitergabe 

von Daten aus Gründen der Glaubwürdigkeit und des Datenschutzes nur beschränkt möglich. 

Durch die Anonymisierung bzw. Aggregation der Daten werden die Anwender so unter vor ungewollten 

Marketing-Kampagnen geschützt. Nicht zuletzt haben auch Wissenschaftler einen Bedarf an authentischen 

Mobilitätsdaten sowie deren Nachhaltigkeitsbewertung. Diese Daten können bzw. müssen 

anonymisiert sein, benötigen aber eine hohe Granularität. Schwerpunkt bei dieser Stakeholder-Gruppe 

liegt auf der Vielfalt und Relevanz der Daten anstatt auf der graphischen Aufbereitung. Dieser Stakeholdergruppe 

reicht daher die Bereitstellung von Reports in einem leicht zu verarbeitenden Datenformat. 

Dashboards können optional rudimentär umgesetzt werden. 

Trotz unterschiedlicher verfolgter Ziele lassen sich die genauen Inhalte für Reports & Dashboards 

dieser drei Stakeholder nicht genau voneinander trennen. Im Folgenden werden daher Anwendungsfälle 

mit hohem Anonymisierungs- und Aggregationsgrad beschrieben, die sich somit für alle drei Stakeholder 

verwenden lassen. Die Reports & Dashboards sollen dabei jeweils per Weboberfläche zugreifbar 

sein und auch per Mail verschickt werden können (z.B. als PDF). Die Reports & Dashboards müssen 

zwar verständlich und einfach bedienbar sein, insgesamt ist die Benutzerfreundlichkeit allerdings 

23



von nicht so großer Bedeutung wie bei den Endanwendern. Insbesondere ist den Stakeholdern die 

Nutzung gängiger BI-Software zuzumuten. 

Inhalte der Reports & Dashboards 

Im Folgenden werden drei Reports und drei Dashboards beschrieben, die einen möglichst großen 

Querschnitt über mögliche Darstellungsformen analytischer Informationen liefern: 

 

 

 

 

 

 

Nutzung der Plattform: Dieser Report gibt einen Überblick über verschiedene ausgewählte 

Kennzahlen zur Bewertung der Nutzungsintensität von Jinengo im Laufe des Jahres. Dies 

dient insbesondere dem Jinengo-Management zur Erfolgsanalyse, lässt sich aber bei Bedarf 

aber auch für Mobilitätsanbieter und Wissenschaftler verwenden. 

Nutzung verschiedener Verkehrsmittel: Dieser Report dient der Analyse der Nutzung verschiedener 

Verkehrsmittel über den Zeitverlauf. Die Dimensionen Zeit und Verkehrsmittel 

sollen dabei ein interaktives Drill-Through ermöglichen. 

Reiseverhalten nach Endanwenderpräferenzen: Dieser Report dient der Analyse, wie sich verschiedene 

Endanwenderpräferenzen bezüglich Nachhaltigkeit, Kosten, Komfort und Zeit auf 

das Reiseverhalten von Personen auswirken. 

Kennzahlen-Überblick: Dieses Dashboard soll einen Überblick über besonders relevante 

Kennzahlen der Jinengo-Nutzung und des Reiseverhaltens liefern. Im Gegensatz zum Report 

„Nutzung der Plattform“ liegt der Schwerpunkt hier auf einer übersichtlichen graphischen 

Darstellung. 

Überblick über eine Region: Dieses Dashboard gibt einen Überblick über Reiseaktivitäten einer 

Region. Dazu gehört neben der Visualisierung von Start- und Zielpunkten auf einer Karte 

auch die Darstellung ausgewählter Reisekennzahlen, die sich auf Routen in der Region beziehen. 

Dieses Dashboard stellt ein Beispiel dar, wie es insbesondere für Mobilitätsanbieter von 

Interesse ist. Ein lokaler Car-Sharing-Anbieter kann auf diese Weise so bspw. neue lukrative 

Stellplätze für seine Autos identifizieren. 

Clusteranalyse: Stellt das Reiseverhalten der einzelnen Endanwendercluster dar, die im Rahmen 

des Data Mining identifiziert wurden. 

Zusammenfassend lassen sich für Jinengo-Management, Mobilitätsanbieter und Wissenschaftler die 

folgenden Reporting-Inhalte definieren: 

 

 

 

 

 

Entwicklung der Anwenderzahlen und der Nutzung der Jinengo-Plattform über die Zeit 

Anteil der Verkehrsmittel an CO 2 -Ausstoß und Reiseaufkommen über die Zeit 

Entwicklung der Nachhaltigkeitsperformance der Endanwender über die Zeit 

Darstellung von Routen bezogen auf ihre Geokoordinaten 

Darstellung der Nachhaltigkeitsperformance bezogen auf Endanwendercluster 

24



5.1.3 Self-Service BI für das Jinengo-Management 

Um flexibel auf Veränderungen reagieren und eigene Analysen erstellen zu können, wird dem Management 

die Möglichkeit gegeben, Reports und Dashboards zu konfigurieren bzw. selbst zu erstellen. 

Dies verkürzt die Reaktionszeit, bevor Entscheidungen getroffen werden können. Auf der anderen 

Seite setzt dies jedoch auch ein Grundverständnis der Datenzusammenhänge voraus, um sinnvolle 

Schlüsse aus den Daten ziehen zu können. Eine vorherige Schulung ist daher von wichtiger Bedeutung. 

Dieses notwendige Wissen ist neben dem Datenschutz ein weiterer Grund, warum Mobilitätsanbietern 

und Wissenschaftlern der Zugang zum Self-Service BI zunächst versperrt bleibt. 

Self-Service BI ist für die Analyseanforderungen des Jinengo-Managements besonders wichtig. Die 

Zugriffsmöglichkeiten auf die Daten sollten daher so umfangreich wie möglich ausfallen. Die genauen 

Anforderungen werden im Folgenden, angelehnt an das Schema in Severith (2012, S. 19), definiert. 

Anforderungen an die Benutzerfreundlichkeit: Das Management interagiert, im Vergleich zu Endanwendern, 

mit einer umfangreicheren Datengrundlage. Die Anforderungen liegen weniger auf visueller 

Aufbereitung, sondern im schnellen Auffinden der richtigen Parameter. Die Priorität liegt stärker 

auf einem vollständigen Funktionsumfang, als auf der Benutzerfreundlichkeit. Dennoch dürfen die 

Aspekte Verständlichkeit, Ergonomie, Kontext und Struktur natürlich nicht vollständig außer Acht 

gelassen werden. 

Modifikation von Reports und Dashboards: Die zuvor beschriebenen Reports & Dashboards sehen 

neben den beschriebenen Interaktions- und Parametrisierungsmöglichkeiten keine weitere Modifikation 

vor. Eine nachträgliche Änderung der Reports & Dashboards lässt sich daher lediglich mit entsprechendem 

Know-How über die Entwicklungsumgebungen der eingesetzten BI-Tools erreichen. 

Ad-Hoc-Erstellung von Berichten und Dashboards: Jinengo-Manager können mithilfe der installierten 

BI-Tools Berichte und Dashboards auch selber erstellen. Dafür sollen sowohl vorkonfigurierte 

Datenquellen als auch die gesamte umfangreiche Datenbasis verwendet werden können. Das ermöglicht 

dem Management nicht nur die Anpassung der Dimensionen, sondern auch das Darstellen völlig 

individueller Kennzahlen. Darstellungsform und Exportformate sollen dabei möglichst frei wählbar 

sein. 

Integration privater, lokaler Daten: Das Management kann eigene Daten in die eigenen Reports und 

Dashboards importieren, dies wird allerdings nur in Excel unterstützt. Dementsprechend müssen die 

Inputdaten ein für Excel gängiges Format aufweisen. 

25



5.2 Data Mining 

Die Generierung neuen Wissens aus der vorhandenen Datenbasis ist zentrales Ziel des Projekts. Diese 

Aufgabe erfüllt das Data Mining. Es werden vier Data-Mining-Anwendungsfälle betrachtet: Eigenschaften 

Raten, Newsletter & Reporting, Ökologische Alternativen, sowie Warnung vor ungewöhnlichem 

Verhalten. Die Ergebnisse dieser Analyse, sollen das Wissen über den Endanwender vertiefen, 

Verhaltensmuster aufdecken und mögliche Potentiale für ein nachhaltigeres Verhalten aufdecken. 

5.2.1 Eigenschaften Raten 

Nicht jeder Endanwender gibt alle Informationen über sich preis. Der Endanwender könnte entweder 

vergessen, seine personenbezogenen Informationen im System zu hinterlegen oder entscheidet sich 

aus Gründen der Privatsphäre und des Datenschutzes dagegen. Analyseergebnisse werden mit der 

Menge an vorhandenem Wissen über den Nutzer besser bzw. schlechter, wenn zu viele Informationen 

fehlen. Während Jinengo mit mehr Informationen besser planen kann, ist es für den Endanwender 

ebenfalls vorteilhaft, wenn Jinengo viel über ihn weiß. Routen können besser auf die persönlichen 

Ansprüchen zugeschnitten werden und Angebote personalisiert werden. Trotzdem ist es weder möglich 

noch sinnvoll jede Information zu erzwingen. Data Mining bietet mithilfe von Ähnlichkeitsanalysen 

die Möglichkeit, Eigenschaften des Users zu schätzen. Anhand ähnlicher Personen, die ein gesuchtes 

Merkmal angegeben haben, kann das Merkmal für eine bestimmte Person mit einer gewissen 

Wahrscheinlichkeit prognostiziert werden und somit der fehlende Wert ergänzt werden. 

5.2.2 Newsletter & Reporting 

Um den Endanwender möglichst individualisiert ansprechen zu können und den Erfolg von bspw. 

Newsletterkampagnen zu erhöhen, werden die Endanwender in Gruppen mit ähnlichem Verhalten 

oder Interessen unterteilt. Neben der Personalisierung von Newslettern ist so auch ein verfeinertes 

internes Reporting möglich. Als Dimension können Cluster die Verhaltensstrukturen spezifischer Personengruppen 

aufdecken und verbesserte Maßnahmen durch das Management ermöglichen. 

Die Unterteilung in Gruppen erfolgt dabei auf zwei verschiedene Arten. Auf der einen Seite erfolgt 

eine Unterteilung gemäß der persönlichen Attribute der Endanwender. Auf diese Weise lassen sich 

ähnliche gesellschaftliche Gruppen identifizieren und direkt ansprechen. Auf der anderen Seite erfolgt 

die Unterteilung nach dem Verhalten der Endanwender. Auf diese Weise lassen sich bspw. Gruppen 

mit besonders hohem Interesse an nachhaltigen Produkten und Dienstleistungen identifizieren. 

26



5.2.3 Ökologische Alternativen Vorschlagen 

Ziel von Jinengo ist es, den Anwender zur Nutzung nachhaltigerer Verkehrsmittel zu bewegen. Auf 

Basis von Assoziationsregeln werden dem Endanwender Vorschläge zum Kauf bzw. zur Nutzung 

anderer Verkehrsmittel gemacht. Endanwender die bspw. regelmäßig mit dem Auto zur Arbeit fahren, 

für die aber auch der Zug eine Option wäre, können so identifiziert und gezielt angesprochen werden. 

Assoziationen werden für nachhaltige Verkehrsmittel hergestellt; als Input werden sowohl Bewegungsdaten 

als auch personenbezogene Daten verwendet. Wird ein Endanwender als potentieller Kandidat 

für bspw. den Kauf eines E-Bikes eingeschätzt, kann dieser mit einer personalisierten Email 

gezielt angesprochen werden. 

5.2.4 Warnung vor ungewöhnlichem Verhalten 

Das Mobilitätsverhalten der Endanwender zu kennen und verstehen ist Kernbestandteil von Jinengo. 

Genauso wichtig ist es daher Endanwender zu identifizieren, die sich nicht wie erwartet verhalten. 

Diesen können dann entsprechende Alternativen vorgeschlagen werden. Diese Analyse basiert dabei 

nicht alleine auf den durch Jinengo gesammelten Daten, sondern auch auf Grundlage der Erkenntnisse 

des Data Mining. 

6. Kennzahlen 

Die im Rahmen von Jinengo relevanten Kennzahlen lassen sich in zwei Systeme einordnen. Die einen 

Kennzahlen geben Aufschluss über die Nutzung der Plattform an sich, die anderen beschreiben Mobilitätsverhalten. 

Aufgrund des Projektschwerpunkts liegt der Fokus auf den Mobilitätskennzahlen, es 

werden jedoch auch einige Nutzungskennzahlen definiert. 

Tabelle 6.1 gibt eine Übersicht über alle im Rahmen des Projekts definierten Kennzahlen. Die Beschreibung 

der Kennzahlen erfolgt – wie bereits in Severith (2012, S. 9-15) empfohlen – auf Basis der 

Steckbriefe nach Kütz (2011, S. 45-48). Diese Kennzahlensteckbriefe finden sich im Anhang b. 

27



System ID Bezeichnung 

J01 Anzahl aktiver Endanwender 

Jinengo-Nutzung J02 Anzahl registrierter Endanwender 

J03 Anteil aktiver Endanwender 

M01 Anzahl der Routen 

M02 Anzahl der Subrouten 

M03 Reisestrecke 

M04 Reisekosten 

M05 Reisekosten pro Kilometer 

Mobilitätsverhalten M06 Reisezeit 

M07 Nutzbare Reisezeit 

M08 Anteil nutzbarer Reisezeit 

M09 CO 2 -Emissionen 

M10 CO 2 -Emissionen pro Kilometer 

M11 Ausgeschöpftes CO 2 -Reduktionspotential 

Tabelle 6.1: Übersicht über die Kennzahlen 

Die Kennzahlen zur Jinengo-Nutzung sind primär für das Jinengo-Management von Relevanz. Aber 

auch Mobilitätsanbieter und Wissenschaftler können ein Interesse an diesen Daten haben. Endanwender 

hingegen haben lediglich ein eingeschränktes Interesse an den Daten und bekommen nur die für 

sie interessanten und relevanten Daten zu sehen. Dabei handelt es sich zum einen um ihr eigenes Reiseverhalten, 

aber auch um dasjenige von Freunden und vom Jinengo-Durchschnitt. Da der Fokus des 

Projektes auf Nachhaltigkeitsaspekten liegt, wird nur eine Auswahl von drei entsprechenden Kennzahlen 

definiert. Denkbar ist jedoch, die Nutzung der operativen Jinengo-Plattform zu tracken und dabei 

auch eine Erweiterung um weitere interessante Nutzungskennzahlen vorzunehmen, z.B. Summe der 

Suchanfragen, Nutzungsdauer der Plattform. 

Die Kennzahlen zum Mobilitätsverhalten sind sowohl für Jinengo-Management, Mobilitätsanbieter, 

Wissenschaftler, als auch für Endanwender von Interesse. Die Granularität und Filterung der Daten ist 

dabei vom Adressaten abhängig. So bekommen Mobilitätsanbieter aus Gründen des Datenschutzes nur 

aggregierten Daten zu sehen. Endanwender bekommen lediglich ihre Daten zu sehen. 

28



7. Semantische Modellierung 

Die semantische Modellierung spiegelt die analytischen Anforderungen und die Kennzahlen aus den 

vorherigen Kapiteln wieder. Dabei werden hier sowohl Messgrößen, die aufgrund ihrer eher geringen 

Bedeutung nicht als Kennzahlen eingestuft werden, als auch dimensionale Attribute beschrieben. 

Aufgrund des agilen Vorgehens der Projektgruppe kann und soll an dieser Stelle noch keine endgültige 

Modellierung erfolgen. Stattdessen werden hier zunächst die wesentlichen Entitäten und Attribute 

als Gestaltungsvorschrift für das dimensionale Datenmodell definiert. 

Abbildung 7.1: Semantische ModellierungMessgrößen 

Während die zuvor beschriebenen Kennzahlen sich zum größten Teil aus summierenden Aggregationen 

(SUM) ergeben, sind für gewisse Anwendungsfälle unter Umständen auch andere Aggregationsfunktionen 

von Relevanz 4 . Für die Messgrößen Reisestrecke, Reisekosten, Reisezeit, nutzbare Reisezeit 

& CO 2 -Emissionen sollen daher neben der Summe (SUM) stets folgende Aggregationsfunktionen 

unterstützt werden: 

MIN (für den niedrigsten Wert eines gegebenen Datenausschnitts) 

MAX (für den größten Wert eines Ausschnitts) 

AVG (für den Durchschnitt eines Ausschnitts) 

Mögliche Anwendung finden diese Aggregationen insbesondere in der Self-Service-BI, für die sie 

bereits entsprechend vorgehalten werden sollen. 

4 Aufgrund ihrer weniger starken Bedeutung werden sie nicht als Kennzahlen bezeichnet, der Vollständigkeit 

halber hier allerdings noch einmal exemplarisch genannt. 

29



7.2 Dimensionen 

Zur Darstellung der zuvor definierten Kennzahlen und weiteren Messgrößen dienen die folgenden 

Dimensionen: 

 

 

 

 

 

 

Zeit: Zeitbezogene Analysen sind ein Kernbestandteil von BI-Anwendungen. 

Route: Reisedaten stehen bei Jinengo immer in Bezug zu einer Route somit und den spezifischen 

Reiseumständen. 

Raum: Mobilität zielt auf die Überwindung physischer Distanzen. Die Analyse, wie sich 

räumliche Aspekte auf Mobilitätsverhalten auswirken, ist daher von großem Interesse. 

Verkehrsmittel: Ein zentrales Element intermodaler Mobilität sind die verschiedenen Verkehrsmittel 

und deren spezifische Vor- und Nachteile. Eine Analyse bezogen auf einzelne 

Verkehrsmittel ist daher von besonderem Interesse. 

Endanwender: Mobilitätsverhalten ist nicht alleine durch Erreichung konkreter Ziele begründet. 

Vielmehr beeinflussen auch soziale und kulturelle Bedürfnisse die individuellen Mobilitätsgewohnheiten. 

Mobilitätsstudien berücksichtigen daher in der Regel auch den gesellschaftlichen 

Kontext der Probanden (z.B. Hunecke 2008; InnoZ 2007). In Jinengo wird deshalb 

auch der Endanwender als Dimension vorgesehen. Dies ermöglicht zum einen die Analyse des 

Mobilitätsverhaltens einzelner Personen über einen Zeitraum hinweg. Zum anderen lässt sich 

so auch das Verhalten unterschiedlicher gesellschaftlicher Milieus analysieren. Zentrale Angaben 

sind daher insbesondere: Alter, Geschlecht, Bildungsgrad, Einkommen, Wohnort, Familienstatus 

sowie Angaben zu verfügbaren Verkehrsmitteln (Auto, Fahrrad, ÖPNV- 

Monatskarte, Carsharing-Kunde). 

Reisezweck: Nach Paech (2007) stellt nicht die ökologische Optimierung bestehender, Bedarfe, 

sondern stattdessen die Bedarfssubstitution die größte Chance im Rahmen einer nachhaltigen 

Entwicklung dar. Grundlage für die Substitution ist die Erkennung und Berücksichtigung 

des Bedarfes, hier: dem Reisezweck. 

30



8. Nichtfunktionale Anforderungen 

Folgende nichtfunktionale Anforderungen sollten bei der Auswahl von Standardsoftware und bei der 

Entwicklung von Individualsoftware (Datengenerator, Reporting-API, Endanwender Reports) beachtet 

werden: 

Benutzerfreundlichkeit 

Da besonders die Endanwender nur über wenig Erfahrung im Umgang mit BI-Lösungen verfügen, gilt 

es das Webinterface so intuitiv wie möglich zu gestalten. Der Anwender sollte sich innerhalb kürzester 

Zeit zurechtfinden und durch die leichte Handhabung zur intensiven Nutzung der Anwendung motiviert 

werden. 

Die Reports gilt es so zu gestalten, dass ihr Inhalt schnell erfasst und leicht in den Kontext eingeordnet 

werden kann. Hierzu trägt die Nutzung von Charts, Balken- und Kuchendiagrammen bei, die einen 

kompakten Überblick ermöglichen. 

Datensicherheit 

Das System beinhaltet sensible, personenbezogene Daten. Es muss sichergestellt werden, dass nur 

autorisierte Personen auf diese Daten Zugriff erhalten. Wenn Daten für die Weitergabe an Drittsysteme 

aufbereitet werden, müssen diese vorher anonymisiert werden. 

Bei der Darstellung von Endanwender Reports muss zudem garantiert werden, dass Nutzer nur ihre 

eigenen oder die Daten von autorisieren Freunden einsehen können. 

Wiederverwendbarkeit 

Das Projekt ist darauf ausgelegt exemplarische Anwendungsfälle für BI Projekte aufzuzeigen. Die 

Wiederverwendung und Erweiterung der entwickelten Lösungen ist daher gewünscht und sollte zu 

jedem Zeitpunkt Anwendungsentwicklung beachtet werden. Gefördert werden kann dies durch einen 

modularen Aufbau der einzelnen Softwarekomponenten und durch die Verwendung von Standards 

und Frameworks die eine Integrierbarkeit einzelner Komponenten in neue Systeme erleichtern. 

Skalierbarkeit 

Das Projekt muss sich leicht an neue Anforderungen anpassen lassen. Sowohl die Datenbank, als auch 

die verwendeten Softwarekomponenten sollten dabei auf den Einsatz im Enterprise Umfeld ausgelegt 

sein und auch bei steigender Intensität der Nutzung stabil und zuverlässig arbeiten. Ein Modularer 

Aufbau einzelner Komponenten soll zudem die Erweiterbarkeit fördern und Abhängigkeiten reduzieren. 

31



9. Literaturverzeichnis 

Deutscher Bundestag (1998): Konzept Nachhaltigkeit - Vom Leitbild zur Umsetzung. Abschlussbericht 

der Enquete-Kommission „Schutz des Menschen und der Umwelt“ des 13. Deutschen Bundestages. 

Bonn. 

Helmke, S. & Uebel, M. & Dangelmaier, W. (2003): Effektives Customer Relationship Management. 

Instrumente - Einführungskonzepte - Organisation. Wiesbaden: Gabler. 

Hunecke, M. (2008): MOBILANZ. Möglichkeiten zur Reduzierung des Energieverbrauchs und der 

Stoffströme unterschiedlicher Mobilitätsstile durch zielgruppenspezifische Mobilitätsdienstleistungen. 

Endbericht. University of Bochum, University of Lüneburg, Wuppertal Institut. 

InnoZ (2007): DB Mobility. Beschreibung und Positionierung eines multimodalen Verkehrsdienstleisters. 

URL: http://www.innoz.de/fileadmin/INNOZ/pdf/Bausteine/innozbaustein-01.pdf, (Zugriff am: 

17.09.2012). 

Kütz, M. (2011): Kennzahlen in der IT. Werkzeuge für Controlling und Management. 4. Aufl., 

Heidelberg: DPunkt Verlag. 

Multicity o.J.: Multicity Citroen. URL: http://www.multicity.citroen.de, (Zugriff am: 22.03.2013). 

Paech, N. (2007): Unternehmerische Nachhaltigkeit und die ungelöste Wachstumsfrage. Von der 

Funktionsorientierung zur Bedarfssubstitution. UmweltWirtschaftsForum Jg. 15, Nr. 2, 8-91. 

Severith 2012: Anforderungsanalyse und Konzeptarbeit in BI-Projekten. Hausarbeit im Rahmen der 

Projektgruppe „Business Intelligence“ (CubeRunner). Abteilung Wirtschaftsinformatik 1: Very Large 

Business Applications. 

United Nations (1987): Report of the World Commission on Environment and Development: Our 

Common Future. 

Urban, M. (2012): Reports vs. Dashboards What’s the Difference. URL: 

http://www.gooddata.com/blog/reports-vs-dashboards-whats-the-difference. (Zugriff am: 22.03.2013). 

Wagner vom Berg, B. & Stamer, D. (2012): Sustainability CRM. A casestudy in the mobility sector. 

In: Ghoneim, A. & Klischewski, R. & Schrödl, H. & Kamal, M. (2012): Proceedings of the European, 

Mediterranean & Middle Eastern Conference on Information Systems 2012, München. 

32



Wagner vom Berg, B. & Stamer, D. & Marx Gómez, J. (2012): Förderung nachhaltiger Mobilität 

durch den Einsatz eines Sustainability CRM. In: Wolgemuth, V. & Lang, C.V. & Marx Gómez, J. 

(Hrsg.) Konzepte, Anwendungen und Entwicklungstendenzen von betrieblichen Umweltinformationssystemen. 

Aachen: Shaker Verlag. 

33



Anhang 

A. Projektmanagement 

Abbildung A.1: GANTT-Diagramm des Projektablaufs (eigene Abbildung) 

34



B. Kennzahlensteckbriefe 

ID: J01 

Anzahl aktiver Endanwender 

Bedeutung Kennzahlensystem Jinengo-Nutzung 

Beschreibung 

Dimensionen 

Exemplarische 

Analysefragen 

Anzahl der Endanwender, die Jinengo in der betrachteten 

Zeitperiode für die Planung einer Reise genutzt haben. 

- Zeit 

- Raum (Startort sowie Zielort) 

- Verkehrsmittel 

- Endanwenderattribute 

- Reisezweck 

Berechnung Datenquellen Data Warehouse 

Berechnung 

Wie viele Endanwender haben Jinengo im April 2012 für 

Reiseplanungen genutzt? Wie viele Endanwender fuhren 

im April 2012 mit dem Zug? 

Kennzahl ist eine Messgröße (SUM-Aggregation) 

Anwendung Reports & Dashboards Relevant für das Management 

Self-Service-BI 

Data Mining 

Relevant 

Nicht relevant 

Tabelle B.1: Kennzahlensteckbrief J01 

ID: J02 

Anzahl registrierter Endanwender 


Beschreibung 

Dimensionen 

Exemplarische 

Analysefragen 

Anzahl der Endanwender, die bei Jinengo registriert sind. 

Vormals registrierte aber mittlerweile gelöschte Anwender 

fallen aus der Betrachtung heraus. 

- Zeit 


Berechnung 

Wie viele Endanwender waren im April 2012 bei Jinengo 

registriert? 




Data Mining 

Relevant 



35



ID: J03 

Anteil aktiver Endanwender 


Beschreibung 

Dimensionen 

Exemplarische 

Analysefragen 

Prozentualer Anteil der aktiven an den registrierten Endanwendern 

in einer betrachteten Zeitperiode. 

- Zeit 


Berechnung 

Wie viel Prozent der registrierten Endanwender haben 

Jinengo im April 2012 für Reiseplanungen genutzt? 


Self-Service-BI Relevant 

Data Mining 



ID: M01 

Anzahl der Routen 

Bedeutung Kennzahlensystem Mobilitätsverhalten 

Beschreibung 

Dimensionen 

Exemplarische 

Analysefragen 

Anzahl der mit Jinengo geplanten Routen. 

- Zeit 




- Reisezweck 


Berechnung 

Für wie viele Routen wurde im April 2012 Jinengo für die 

Planung genutzt? Wie viele Routen im April 2012 wurden 

(zum Teil) mit dem E-Bike zurückgelegt? 


Anwendung Reports & Dashboards Relevant für alle Stakeholder 


Data Mining 

Relevant 

Relevant 

Tabelle B.4: Kennzahlensteckbrief M01 

36



ID: M02 

Anzahl der Subrouten 


Beschreibung 

Dimensionen 

Exemplarische 

Analysefragen 

Anzahl der Subrouten, aus denen sich eine gegebene 

Menge von Routen zusammensetzt. 

- Zeit 




- Reisezweck 


Berechnung 

Aus wie vielen Subrouten setzten sich die Routen im April 

2012 zusammen? Wie viele Subrouten wurden 2012 

mit dem E-Bike zurückgelegt? 


Anwendung Reports & Dashboards Für Management, Wissenschaftler & Mobilitätsanbieter 


Data Mining 

Relevant 

Relevant 


ID: M03 

Reisestrecke 


Beschreibung 

Dimensionen 

Exemplarische 

Analysefragen 

Summierte Reisestrecke in Kilometern. 

- Zeit 




- Reisezweck 


Berechnung 

Wie viele Kilometer wurden im April 2012 unter Zuhilfenahme 

von Jinengo zurückgelegt? Wie viele Kilometer 

wurden 2012 mit dem Elektroauto zurückgelegt? 


Anwendung Reports & Dashboards Für alle Stakeholder relevant 


Data Mining 

Relevant 

Relevant 


37



ID: M04 

Reisekosten 


Beschreibung 

Dimensionen 

Exemplarische 

Analysefragen 

Summierte Reisekosten in EUR. 

- Zeit 



- Reisezweck 


Berechnung 

Wie viel Geld gaben Endanwender im April 2012 insgesamt 

für ihr Reiseverhalten aus? Wie viel Geld steckten 

Endanwender 2012 insgesamt in Autoreisen? 




Data Mining 

Relevant 



ID: M05 

Reisekosten pro Kilometer 


Beschreibung 

Dimensionen 

Exemplarische 

Analysefragen 

Reisekosten in EUR je zurückgelegten Kilometer. 

- Zeit 



- Reisezweck 


Berechnung 

Wie viel Geld gaben Endanwender im April je Kilometer 

für ihr Reiseverhalten aus? Wie viel Geld gaben Endanwender 

2012 bei Autoreisen je Kilometer aus? 



Data Mining 



38



ID: M06 

Reisezeit 


Beschreibung 

Dimensionen 

Exemplarische 

Analysefragen 

Summierte Reisezeit in Minuten (inklusive Umstiegs- und 

Wartezeit). 

- Zeit 



- Reisezweck 


Berechnung 

Wie viel Zeit wurde im April 2012 für Reiseaktivitäten 

aufgebracht? Wie viel Zeit wurde 2012 auf dem E-Bike 

verbracht? 




Data Mining 

Relevant 

Relevant 


ID: M07 

Nutzbare Reisezeit 


Beschreibung 

Dimensionen 

Exemplarische 

Analysefragen 

Summierte nutzbare Reisezeit in Minuten. 

Nutzbar ist die Reisezeit lediglich in ausgewählten Verkehrsträgern. 

Zeit auf dem Fahrrad oder im Auto ist generell 

nicht nutzbar. Auch der öffentliche Nahverkehr wird 

aufgrund des beschränkten Platzangebots nicht positiv 

bewertet. Lediglich im Fernverkehr (Bahn) ist die Zeit 

nutzbar (potentiell auch im Flugzeug, was bislang nicht 

berücksichtigt wird). Umstiegs- und Wartezeiten sind 

generell nicht nutzbar. 

- Zeit 



- Reisezweck 


Berechnung 

Wie viel Zeit war im April 2012 bei Reiseaktivitäten aktiv 

nutzbar? 




Data Mining 

Relevant 

Relevant 


39



ID: M08 

Anteil nutzbarer Reisezeit 


Beschreibung 

Dimensionen 

Exemplarische 

Analysefragen 

Prozentualer Anteil der nutzbaren Reisezeit. 

- Zeit 



- Reisezweck 


Berechnung 

Wie groß war der Anteil der nutzbaren Reisezeit bei Reiseaktivitäten 

im April 2012? 



Data Mining 



ID: M09 

CO 2 -Emissionen 


Beschreibung 

Dimensionen 

Exemplarische 

Analysefragen 

Summierte Umweltwirkung in CO 2 (-Äquivalenten). 

- Zeit 



- Reisezweck 


Berechnung 

Wie viel CO 2 -Emissionen wurden im April 2012 bei Reiseaktivitäten 

emittiert? 




Data Mining 

Relevant 

Relevant 


40



ID: M10 

CO 2 -Emissionen pro Kilometer 


Beschreibung 

Dimensionen 

Exemplarische 

Analysefragen 

Umweltwirkung in CO 2 (-Äquivalenten) je Kilometer. 

- Zeit 



- Reisezweck 


Berechnung 

Wie viele CO 2 -Emissionen fielen bei Autoreisen in 2012 

pro Kilometer an? 



Data Mining 

Relevant 


ID: M11 

Ausgeschöpftes CO 2 -Reduktionspotential 


Beschreibung 

Dimensionen 

Exemplarische 

Analysefragen 

Ausgeschöpftes prozentuales CO 2 -Reduktionspotential. 

Dabei werden die tatsächlich getroffenen Routenentscheidungen 

der Endanwender in Relation zu den von Jinengo 

vorgeschlagenen Reisealternativen gesetzt. Berücksichtigt 

werden dabei jeweils die Alternativroute mit den niedrigsten 

(minCO2) sowie die mit den höchsten CO 2 -Emissionen 

(maxCO2). 

- Zeit 


- Reisezweck 


Berechnung 

Zu wie viel Prozent schöpften Endanwender ihr CO 2 - 

Reduktionspotential im Jahr 2012 aus? 

Anwendung Reports & Dashboards Relevant für Endanwender (und Management) 


Data Mining 



41


Jinengo - DV Konzept 

42


Jinengo – DV Konzept 




DV-Konzept 

43



44



Inhaltsverzeichnis Jinengo DV-Konzept 

Abbildungsverzeichnis ............................................................................................................. 46 

Tabellenverzeichnis .................................................................................................................. 47 

1. Einleitung .......................................................................................................................... 48 

2. Ist-Zustand ........................................................................................................................ 49 

2.1 Entwicklungsstand von Jinengo ................................................................................... 49 

2.2 Software- & Hardwarearchitektur ................................................................................ 50 

2.3 Daten............................................................................................................................. 50 

3. Soll-Zustand ...................................................................................................................... 51 

3.1 BI-Systemarchitektur & Softwaretechnologien ........................................................... 51 

3.2 Datenmodellierung ....................................................................................................... 54 

3.2.1 Operative Datenbank ......................................................................................... 54 

3.2.2 Relationales Data Warehouse ............................................................................ 57 

3.2.3 Multidimensionales Data Warehouse ................................................................ 61 

3.3 Datenflüsse ................................................................................................................... 65 

3.3.1 Prozess zur Füllung der operativen Datenbank mit generierten Daten ............. 65 

3.3.2 ETL-Prozess zur Füllung des relationalen Data Warehouse ............................. 66 

3.3.3 Aggregation von Daten im Data Warehouse ..................................................... 68 

3.4 Data Mining .................................................................................................................. 68 

3.4.1 Klassifizierung ................................................................................................... 69 

3.4.2 Clustering........................................................................................................... 70 

3.4.3 Assoziation ........................................................................................................ 71 

3.4.4 Warnen vor „ungewöhnlichem“ Verhalten ....................................................... 72 

3.5 Reports & Dashboards .................................................................................................. 74 

3.5.1 Reporting für Endanwender............................................................................... 74 

3.5.2 Reporting für Management, Wissenschaftler & Mobilitätsanbieter .................. 78 

3.5.3 Self-Service BI für Management, Wissenschaftler & Mobilitätsanbieter ......... 86 

4. Realisierung ...................................................................................................................... 90 

4.1 Datengenerator ............................................................................................................. 90 

4.1.1 Stammdaten ....................................................................................................... 91 

4.2 Reporting-API (Webservice) ........................................................................................ 97 

4.3 Reporting-Frontend für Endanwender ........................................................................ 102 

4.4 Programmierrichtlinien............................................................................................... 105 

5. Literaturverzeichnis ........................................................................................................ 106 

Anhang ................................................................................................................................... 107 

A. 

B. 

Tabellen der operativen Datenbank ................................................................................ 107 

Tabellen des Data Warehouse ......................................................................................... 111 

45




Abbildung 2.1: Jinengo-Systemarchitektur .............................................................................. 50 

Abbildung 2.2: Bisheriges Datenmodell von Jinengo .............................................................. 51 

Abbildung 3.1: BI-Systemarchitektur ...................................................................................... 51 

Abbildung 3.2: Datenmodell der operativen Datenbank .......................................................... 56 

Abbildung 3.3: Datenmodell des Data Warehouse .................................................................. 59 

Abbildung 3.4: Datenmodell des aggregierten Data Warehouse ............................................. 60 

Abbildung 3.5: Semantische Modellierung des Subroute-Cube .............................................. 64 

Abbildung 3.6: Entscheidungsbaum UseCase OwnsEbike ...................................................... 73 

Abbildung 3.7: Mockup des Dashboards „Endanwender-Kennzahlen über die Zeit“ ............. 75 

Abbildung 3.8: Mockup des Dashboards „Endanwender-Kennzahlen nach 

Verkehrsmittel“ ........................................................................................................................ 76 

Abbildung 3.9: Mockup des Dashboards „CO 2 -Einsparpotential des Anwenders“ ................. 77 

Abbildung 3.10: Mockup des Dashboards „Jinengo-Überblick“ ............................................. 79 

Abbildung 3.11: Mockup des Dashboards "Clusteranalyse" ................................................... 80 

Abbildung 3.12: Mockup des Dashboards "Orte in Oldenburg" ............................................. 81 

Abbildung 3.13: Mockup des Reports „Nutzung der Plattform“ ............................................. 82 

Abbildung 3.14: Mockup des Reports „Reisekennzahlen nach Zeit & Verkehrsmittel“ ......... 83 

Abbildung 3.15: Mockup des Reports „Reisekennzahlen nach Zeit & Präferenz“ ................. 84 

Abbildung 3.16: Mockup des QlikView-Dashboards zur Plattformnutzung ........................... 85 

Abbildung 3.17: Mockup zur Self-Service-BI-Lösung für allgemeine 

Plattforminformationen ............................................................................................................ 87 

Abbildung 3.18: Mockup zur Self-Service BI-Lösung für detaillierte 


Abbildung 3.19: Mockup zur Self-Service BI-Lösung für detaillierte 

Nachhaltigkeitsinformationen .................................................................................................. 89 

Abbildung 4.1: Sequenzdiagramm des Datengenerators ......................................................... 97 

Abbildung 4.2: Sequenzdiagramm Reporting-API .................................................................. 99 

Abbildung 4.3: Sequenzdiagramm Reporting-Frontend ........................................................ 103 

46




Tabelle 3.1: Systembestandteile, ihre Funktion & eingesetzte Technologien ......................... 52 

Tabelle 3.2: Verdichtungsebenen der aggregierten Tabellen im Data Warehouse .................. 58 

Tabelle 3.3: Kennzahlen und Messgrößen des Subroute-Cubes .............................................. 62 

Tabelle 3.4: Beschreibung der Schritte des ETL-Prozess ........................................................ 68 

Tabelle 3.5: Zuordnung der Data-Mining-Methoden zu den Anwendungsfällen .................... 69 

Tabelle 3.6: Charakteristika des Dashboards „Endanwender-Kennzahlen über die Zeit“ ....... 75 

Tabelle 3.7: Charakteristika des Dashboards „Endanwender nach Verkehrsmittel“ ............... 77 

Tabelle 3.8: Charakteristika des Dashboards „CO 2 -Einsparpotential des Anwenders“ ........... 78 

Tabelle 3.9: Charakteristika des Dashboards „Jinengo-Überblick“ ......................................... 79 

Tabelle 3.10: Charakteristika des Dashboards „Clusteranalyse“ ............................................. 80 

Tabelle 3.11: Charakteristika des Reports „Orte in Oldenburg“ .............................................. 81 

Tabelle 3.12: Charakteristika des Reports „Nutzung der Plattform“ ....................................... 82 

Tabelle 3.13: Charakteristika des Reports „Reisekennzahlen nach Zeit & Verkehrsmittel“ ... 83 

Tabelle 3.14: Charakteristika des Reports „Reisekennzahlen nach Zeit & Präferenz“ ........... 84 

Tabelle 3.15: Charakteristika des Dashboards „Plattformnutzung“......................................... 85 

Tabelle 3.16: Charakteristika zur Self-Service-BI-Lösung für allgemeine 


Tabelle 3.17: Charakteristika zur Self-Service-BI-Lösung für detaillierte 


Tabelle 3.18: Charakteristika zur Self-Service-BI-Lösung für detaillierte 

Nachhaltigkeitsinformationen .................................................................................................. 89 

Tabelle 4.1: Im Datengenerator unterschiedene Datenarten .................................................... 90 

Tabelle 4.2: Erläuterung der Attribut-Abhängigkeiten ............................................................ 92 

Tabelle 4.3: Zuordnung der Arbeitspakete zu den Programmkomponenten ........................... 93 

Tabelle 4.4: Erläuterung der Berechnung für die Routeneigenschaften .................................. 95 

Tabelle 4.5: Allgemeine Schnittstellenspezifikation Webservice .......................................... 100 

Tabelle 4.6: Nutzerspezifische Schnittstellenspezifikation Webservice ................................ 101 

Tabelle 4.7: Entwicklungsinfrastruktur .................................................................................. 101 

Tabelle 4.8: Programmierrichtlinien ...................................................................................... 105 

Tabelle A.1: Entität JinengoUser der operativen Datenbank ................................................. 107 

Tabelle A.2: Entität Route der operativen Datenbank ........................................................... 108 

Tabelle A.3: Entität Suboute der operativen Datenbank ........................................................ 109 

Tabelle A.4: Entität Preferences der operativen Datenbank .................................................. 110 

Tabelle A.5: Entität Transportation der operativen Datenbank ............................................. 110 

Tabelle B.1: Entität UserHistoric des Data Warehouse ......................................................... 112 

Tabelle B.2: Entität JinengoUser des Data Warehouse .......................................................... 112 

Tabelle B.3: Entität AggrUserFigure des Data Warehouse ................................................... 114 

Tabelle B.4: Entität AggrUserFigurePerTransportation des Data Warehouse....................... 115 

Tabelle B.5: Entität AggrPlatformFigure des Data Warehouse ............................................. 116 

47



1. Einleitung 

Die Mobilitätsplattform Jinengo bietet Endanwendern die Möglichkeit, Reiserouten unter Einbeziehung 

verschiedener Verkehrsträgern und Beachtung ökologischer Aspekte zu planen. Jinengo ist damit 

eine nachhaltigkeitsorientierte Anwendung eines Customer Relationship Managements (CRM). Das 

System wurde im Rahmen einer Projektgruppe der Wirtschaftsinformatik an der Carl von Ossietzky 

Universität Oldenburg entwickelt. Die Softwarearchitektur besteht aus einem CRM, das als Datenbasis 

einen Microsoft SQL Server 2008 nutzt, sowie der eigentlichen Anwendung in Java und .net, die dem 

Anwender die Nutzung der Software über Webtechnologien ermöglicht. 

Aufgabe der Projektgruppe ist die Erweiterung des bestehenden operativen Systems um Elemente der 

Business Intelligence. Dabei werden die folgenden Ziele verfolgt. 

Analyse des Mobilitätsverhaltens: Jinengo zielt auf die Beeinflussung des Mobilitätsverhaltens der 

Anwender. Allerdings erfordert die Veränderung des eigenen Verhaltens auch eine Hinterfragung und 

Anpassung eigener gewohnter Entscheidungen (Routinen) und Vorlieben. Hinter dem bisherigen Mobilitätsverhalten 

eines Anwenders stecken jedoch verschiedene individuelle Gründe, die es zunächst zu 

verstehen und zu berücksichtigen gilt. Mit den Methoden der Business Intelligence sollen Muster im 

Mobilitätsverhalten der Anwender entdeckt werden. Angestrebt wird ein größtmögliches Verständnis, 

warum sich Anwender für eine entsprechende Routenalternative entschieden haben. 

Darstellung des Mobilitätsverhaltens: Die Visualisierung des Mobilitätsverhaltens der Anwender 

dient der Bewusstseinsbildung zu Nachhaltigkeitsaspekten des eigenen Reiseverhaltens. Die Darstellung 

von Mobilitätsverhalten ist des Weiteren für das Jinengo-Management zur Bewertung der Attraktivität 

von Jinengo von Interesse. Zudem haben auch Dritte, wie beispielsweise Wissenschaftler und 

Mobilitätsanbieter ein Interesse an entsprechend aufbereiteten Daten. 

Verbesserung von Jinengo: Die Analyse vergangener Reisedaten ermöglicht die Erkennung von 

Ähnlichkeiten und Mustern und damit die Generierung neuen Wissens. Die Speisung von analytisch 

gewonnenem Wissen in die operativen Prozesse realisiert den sogenannten Closed-Loop des CRM. 

Auf diese Weise lassen sich neue Erkenntnisse über das Reiseverhalten generieren und die operativen 

Prozesse von Jinengo dementsprechend verbessern. Dadurch verbessert sich die Leistungsfähigkeit 

von Jinengo, zielgruppengerechte Mobilitätsalternativen vorschlagen zu können. 

48



2. Ist-Zustand 

2.1 Entwicklungsstand von Jinengo 

Jinengo wurde im Rahmen einer Projektgruppe der Wirtschaftsinformatik an der Carl von Ossietzky 

Universität Oldenburg entwickelt. Die Softwarearchitektur besteht aus einem CRM, das als Datenbasis 

einen Microsoft SQL Server 2008 nutzt, sowie der eigentlichen Anwendung in Java und .net, die dem 

Anwender die Nutzung der Software über Webtechnologien ermöglicht. 

Die Mobilitätsanwendung Jinengo ist grundsätzlich funktionstüchtig. Endanwender können sich mithilfe 

unterschiedlicher Endgeräte am System anmelden und erhalten Routenvorschläge für angefragte 

Reiseziele. Die ausgewählten Routen werden in einer Datenbank auf dem Microsoft SQL Server 2008 

abgespeichert. Diese Datenbank enthält zudem die persönlichen Daten aller registrierten Endanwender. 

Eine Verwendung der Daten im Sinne der Business Intelligence findet bislang allerdings nicht 

statt. Eine Erweiterung um entsprechende Funktionen ist daher Ziel dieser Projektgruppe. 

Die bestehende Realisierung von Jinengo lässt bislang jedoch einige wesentliche Funktionen vermissen, 

die aus Sicht der Anwendung von Business Intelligence sinnvoll sind. Dazu gehören bspw. persönliche 

Attribute wie Alter, Geschlecht und die Angabe, welche Verkehrsmittel einem Endanwender 

zur Verfügung stehen. Neben einem Testbetrieb fand zudem bislang noch kein operativer Betrieb des 

Systems statt. Die Datenbasis ist daher bezüglich Quantität sowie Qualität nicht ausreichend. Für das 

Projekt stellt sich daher die Herausforderung, Methoden der Business Intelligence bei Jinengo anzuwenden, 

ohne sich zu sehr durch den noch nicht vollständig ausreichenden Entwicklungsstand von 

Jinengo behindern zu lassen 5 . 

Die derzeitige Systemarchitektur ist zudem nicht besonders stabil und auf verschiedene manuelle Eingriffe 

angewiesen. Die Lizenz des verwendeten CRM-Systems von Microsoft in der Cloud muss regelmäßig 

manuell verlängert werden und die eingebundenen universitären Server fallen gelegentlich 

aus und müssen dann manuell neugestartet werden. Zudem ist die Vertragszeit der Domain 

www.jinengo.com mittlerweile ausgelaufen. 

Die funktionale Weiterentwicklung von Jinengo im Zuge des „Schaufensters Elektromobilität“ steht in 

Aussicht. Für die durch die Projektgruppe zu implementierenden BI-Anwendungen stellt sich daher 

die Anforderung einer flexiblen Einbindung in ein sich dynamisch veränderndes System. 

5 Eine funktionale Weiterentwicklung des operativen Jinengo-Systems ist nicht Aufgabe der Projektgruppe. 

49



2.2 Software- & Hardwarearchitektur 

Jinengo basiert auf der in Abbildung 2.1 dargestellten Systemarchitektur. Ein Java-Programm dient als 

eigentlicher Anwendungskern. Darauf setzt ein .NET-Framework für die Entwicklung der Frontends 

auf. Über dieses Framework lässt sich Jinengo mithilfe von Webtechnologien für beliebige Endgeräte 

verfügbar machen. Die Datenhaltung für die Java-Anwendung erfolgt über ein Microsoft Dynamics 

CRM, welches eine relationale Datenbank des Microsoft SQL Server 2008 als Grundlage nutzt. Die 

Synchronisation von CRM und relationaler Datenbank erfolgt über manuell angestoßene Prozeduren. 

Abbildung 2.1: Jinengo-Systemarchitektur 

Die SQL-Datenbank, das Java-Programm sowie das .NET-Framework liegen auf verschiedenen universitären 

Servern der VLBA. Das CRM ist in der Microsoft-Cloud gehostet. 

2.3 Daten 

Bislang fand noch kein operativer Betrieb der Jinengo-Plattform statt. Die bestehende Datenbasis 

speist sich daher bislang ausschließlich aus Daten, die im Testbetrieb nach und nach angefallen sind. 

Die Menge der Daten in der relationalen Datenbank kann daher als quantitativ nicht ausreichend für 

die Anwendung von Business Intelligence bezeichnet werden. Auch qualitativ genügt das bestehende 

Datenmodell noch nicht den Ansprüchen der Business Intelligence. So verfügt das Datenmodell (siehe 

Abbildung 2.2) bislang noch nicht über die notwendige Komplexität, um für BI-Anwendungen sinnvoll 

geeignet zu sein. Aufgabe des Projektes ist es daher auch, ein für die analytischen Anforderungen 

erweitertes Datenmodell zu definieren und die fehlenden Daten zu generieren. 

50



Quelle: Huang (2011), S.143 

Abbildung 2.2: Bisheriges Datenmodell von Jinengo 

3. Soll-Zustand 

3.1 BI-Systemarchitektur & Softwaretechnologien 

Abbildung 3.1: BI-Systemarchitektur 

Die zukünftige Systemarchitektur wird in Abbildung 3.1 dargestellt. Die einzelnen Bestandteile der 

BI-Systemarchitektur erfüllen die in Tabelle 3.1 aufgeführten Funktionen. 

51



Bestandteil Funktion Technologien 

Datengenerator 

Operative 

Datenbank 

Data 

Warehouse 

ETL- 

Prozess 

Data 

Mining 

Reporting 

Self- 

Service BI 

Web- 

Reporting 

Web-API 

Die Daten des operativen Systems werden hier generiert und 

damit die bislang fehlende Endanwenderaktivität von Jinengo 

simuliert. 

Die relationale Datenbank speichert die vom Datengenerator 

(bzw. dem Endanwender) generierten Stamm- und Bewegungsdaten. 

Im Data Warehouse werden die Daten aus der operativen 

Datenbank für analytische Zwecke abgelegt. Die Datenstruktur 

ist an die spezifischen analytischen Anforderungen angepasst. 

Insbesondere findet hier eine Historisierung der Daten 

statt. 

Der ETL-Prozess zwischen operativer Datenbank und Data 

Warehouse sorgt für den kontinuierlichen Datenstrom zwischen 

den beiden Datenbanken. 

Das Data Mining analysiert die Daten im Data Warehouse 

und speist gewonnene Erkenntnisse in das Data Wareouse. 

Zielgruppengerechte Dashboards und Reports ermöglichen 

dem Jinengo-Management, Wissenschaftlern und Mobilitätsanbietern 

eine individuelle Datenanalyse. 

Self-Service BI ermöglicht insbesondere dem Jinengo- 

Management eine detaillierte und individuelle Sicht auf die 

analytischen Daten. 

Endanwender von Jinengo bekommen die Möglichkeit, ihr 

eigenes Reiseverhalten durch verschiedene Web-Dashboards 

zu analysieren. 

Die Web-API dient als Schnittstelle zwischen Web- 

Anwendungen (Web-Reporting) und dem Data-Warehouse. 

Java, TSQL 

Microsoft SQL Server 

2012 Database 

Microsoft SQL Server 

2012 Database 

SQL Server Analysis 

Services 2012 (SSAS) 

SQL Server Integration 

Services 2012 

(SSIS) 

IBM SPSS Modeler 

15.0 

SQL Server Reporting 

Services (SSRS) 

QlickView 11 

Microsoft Excel 2012 

Java, HTML, CSS, 

JavaScript, 

Java, JSON 

Tabelle 3.1: Systembestandteile, ihre Funktion & eingesetzte Technologien 

Um die Anschlussfähigkeit an die bisherige Jinengo-Infrastruktur zu gewährleisten, wird – analog zu 

der operativen Anwendung – auch für die Business Intelligence als technische Grundlage ein Microsoft 

SQL-Server genutzt. Dabei wird jedoch statt wie bisher der 2008er-Version nun die 2012er- 

Version verwendet. Der SQL Server 2012 wurde von den Betreuern der Projektgruppe, als zu verwendende 

Technologie, festgelegt. 

Neben der eigentlichen relationalen Datenbankanwendung kommen die SQL Server Analysis Services 

(SSAS) für OLAP, die SQL Server Integration Services (SSIS) für ETL, die SQL Server Reporting 

Services (SSRS) sowie Microsoft Excel für das Reporting zum Einsatz. Für das Reporting mit dem 

SQL Server 2012 ist zwar SharePoint aufgrund von Nutzungskomfort und Design das zu bevorzugende 

Tool, in dem Fall der Projektgruppe allerdings aufgrund der Systemarchitektur keine Option gewesen. 

Reporting mit dem SharePoint setzt voraus, dass SharePoint und Reporting Services auf demselben 

Server installiert sind. Dies ist durch die Cloud-Lösung des SharePoints in der Projektgruppe allerdings 

nicht möglich. 

52



Neben den Microsoft-Produkten kommen weitere Softwareprodukte zum Einsatz. Für das Data Mining 

wird der IBM SPSS Modeler 15.0 verwendet; für das Reporting kommt zudem QlikView 11 zum 

Einsatz. Der SPSS Modeler von IBM ist insbesondere im Punkt Algorithmen besser ausgestattet als 

SSIS und daher das zu bevorzugende Data-Mining-Tool. QlikView ist ein weiteres Reporting Tool 

und soll beispielhaft zeigen, wie Reporting alternativ realisiert werden kann. 

Für die Entwicklung individueller, funktionaler Anforderungen wird die Programmiersprache Java 

verwendet. So wird mittels Java und dem Spring MVC Framework die Grundlage für das Web- 

Reporting geschaffen. Für die Kommunikation zwischen Web-Reporting und dem Data-Warehouse 

wird eine REST-Schnittstelle implementiert (Web-API). Das Web-Reporting selbst basiert hauptsächlich 

auf den Webtechnologien JavaScript, HTML und CSS und nutzt die Web-API zur Abfrage der 

benötigten Kennzahlen. 

Operative Datenbank und Data Warehouse liegen auf einem virtuellen Server der Abteilung VLBA an 

der Universität Oldenburg. Dieser Server verantwortet auch den ETL-Prozess sowie das Reporting. 

Teile der BI-Systemarchitektur werden jedoch von den Entwickler-Computern ausgeführt. Der Java- 

Datengenerator wird lokal ausgeführt, da er kein dauerhafter Bestandteil der Architektur ist und nur 

bei Bedarf gestartet wird. Ferner werden der IBM SPSS Modeler sowie Qlikview lokal verwendet. 

Aufgrund fehlender Lizenzen für beide Programme können keine Servervarianten aufgesetzt werden. 

Die Web-API und das Web-Reporting können lokal genutzt werden; zudem wird eine Testumgebung 

auf einem virtuellen Server aufgesetzt. 

Die im Rahmen der Projektgruppe erarbeiteten Lösungen sind als exemplarische Anwendungsfälle zu 

verstehen. Produktiv zu überführende Projektbestandteile sind daher zu übertragen, sobald die notwendige 

IT-Infrastruktur dauerhaft vorhanden ist. Die Dokumentation soll daher insbesondere auch 

die Schritte zur Übertragung der Projektergebnisse auf eine andere Systemumgebung beschreiben. 6 

6 Hierbei ist auch die Besonderheit von QlikView zu erwähnen, dass in der Personal Edition nur dem Ersteller 

das Öffnen der Dokumente erlaubt. Skript sowie Screenshots werden bei Abgabe übergeben, allerdings müssen 

die erstellten Reports & Dashboards bei einer endgültigen Realisierung des Prototyps noch einmal neu 

gebaut werden. 

53



3.2 Datenmodellierung 

Um den Anforderungen an eine zeitgemäße BI-Architektur gerecht zu werden gliedert sich das Datenmodell 

in drei Teile. Auf der einen Seite wird die operative Datenbank von Jinengo weiterentwickelt, 

die sowohl Stamm- als auch Bewegungsdaten für den operativen Betrieb enthält. Auf der anderen 

Seite wird das System um ein Data Warehouse erweitert, auf dem neben Stamm- und Bewegungsdaten 

auch historische und aggregierte Daten gespeichert werden. Ein Cube stellt die Mobilitätsdaten 

des relationalen Data Warehouse zudem multidimensional dar. 

Die Trennung von operativer Datenbank und Data Warehouse ermöglicht die Anpassung der Datenstruktur 

gemäß den spezifischen Anforderungen der analytischen Anwendungen. Zudem hat dies den 

Vorteil, dass die Performance des operativen Systems nicht durch analytische Abfragen negativ beeinflusst 

wird. 

3.2.1 Operative Datenbank 

Die operative Datenbank ist direkt an das laufende Jinengo-System angebunden und beinhaltet die 

Datengrundlage für den operativen Betrieb. Die Datenbank speichert dabei im Wesentlichen die Endanwenderstammdaten 

sowie deren in der Vergangenheit zurückgelegten Routen mit den zugehörigen 

Subrouten. 

Von zentraler Bedeutung sind die Eigenschaften eines Endanwenders, die in der Tabelle JinengoUser 

abgelegt werden. Neben Attributen wie dem Namen sowie dem Geburtsdatum werden hier insbesondere 

Informationen zum Familienstand (FamilyStatus), dem Einkommen (IncomeRange), den Mitgliedschaften 

bei CarSharing-Anbietern (CarSharingMembership), den Bahncard-Besitz (RailMembership) 

sowie den individuellen Präferenzen (Preferences) gespeichert. 7 

Für den Vergleich des Reiseverhaltens von einzelnen Endanwendern untereinander soll es zudem die 

Möglichkeit für die Bildung von Freundschaften geben. Hierfür wird die Tabelle JinengoUserFriend 

verwendet. Aufgrund der Tatsache, dass beidseitige Freundschaftsbeziehungen in relationalen Datenbanken 

durch zwei Tabelleneinträge je Freundschaft abgebildet werden sind pro Freundschaft sowohl 

die Identifikationsnummer des Anwenders als auch die Identifikationsnummer dessen Freundes (eines 

weiteren Anwenders) hinterlegt. Dies bedeutet zum einen zwar eine gewisse Redundanz, ermöglicht 

7 Ein Teil der Eigenschaften wird dabei als freies Attribut definiert, ein anderer Teil wird über Fremdschlüsselbeziehungen 

zu entsprechenden Stammdatentabellen definiert. Auf diese Weise werden fehlerhafte und nicht 

zuzuordnende Angaben vermieden und damit die Datenqualität erhöht. 

54



durch die zweifache Richtung allerdings auch einen besonders leichten lesenden Zugriff (Explain Extended 

2009). 

Verknüpft mit dem Endanwender sind die von ihm gefahrenen Routen (Tabelle Route). Für jede Route 

werden hier die spezifischen Fahrtinformationen gespeichert. So z.B. Start und Ziel (departureAddress 

& destinationAddress), die Anzahl der mitgefahrenen Passagiere (passengers) sowie die Zeit (totalTime). 

Für jede Route werden zudem die Vor- und Nachteile (advantage & disadvantage) der Route im 

Vergleich zur besten und schlechtesten von Jinengo vorgeschlagenen Alternative quantifiziert. Dies 

passiert in Bezug auf die Aspekte CO 2 -Emissionen (ecoImpact), Kosten (costs), Reisezeit (time) sowie 

nutzbare Reisezeit (effectiveTime). 8 

Jede Route verfügt über mindestens eine zugeordnete Subroute. Gespeichert werden hier detaillierte 

Informationen zum jeweiligen Streckenabschnitt. Dies beinhaltet neben den speziellen Start- und Zielorten 

(departureAddress & destinationAddress) auch die Angaben bezüglich Entfernung (distance), 

Reisezeit (time), nutzbare Reisezeit (timeUsable), Kosten (costs) und CO2-Emissionen (ecoImpact). 

Zudem wird über eine Fremdschlüsselbeziehung zur Tabelle Transportation angegeben, mit welchem 

Verkehrsmittel die Subroute zurückgelegt wurde. Jedes Verkehrsmittel verfügt über einen Klartextnamen 

(classOrProviderName), eine Komfortbewertung sowie eine Referenz auf einen übergeordneten 

Verkehrsmitteltyp (Tabelle TransportationType). 

Eine schematische Darstellung des beschriebenen Datenmodells ist in Abbildung 3.2 abgebildet. Anhang 

a listet zudem alle Attribute der erwähnten Tabellen auf und beschreibt diese näher. Der Datengenerator 

zur Füllung der operativen Datenbank wird in Kapitel 4.1 beschrieben. 

8 Die eigentlichen Werte der Route in Bezug auf CO 2 -Emissionen, Kosten, Reisezeit und nutzbare Reisezeit 

werden nicht in der Tabelle Route, sondern lediglich auf Ebene der Subroute festgehalten. Dies vermeidet die 

Haltung redundanter Daten in der operativen Datenbank. Die entsprechenden Werte lassen sich durch eine 

einfache Summierung der Subrouten-Daten bestimmen. 

55



Abbildung 3.2: Datenmodell der operativen Datenbank 

56



3.2.2 Relationales Data Warehouse 

Das Data Warehouse bildet die Grundlage für alle datenbezogenen Analysen. Im Data Warehouse 

werden ein historisiertes sowie ein aggregiertes Datenmodell unterschieden. Die doppelte Datenhaltung 

ermöglicht dabei die exemplarische Darstellung von zwei Einsatzbereichen eines Data Warehouse. 

Während die aggregierten Daten einen schnellen und unkomplizierten Zugriff auf Informationen 

insbesondere für übersichtliche Dashboards bereitstellen, ermöglichen die historisierten Daten 

eine detaillierte Datensicht. 

Im Folgenden soll auf die wesentlichen Aspekte eingegangen werden. Ergänzend enthalten die Tabellen 

in Anhang b eine detaillierte Beschreibung der im Vergleich zur operativen Datenbank neuen und 

veränderten Attribute. 

Historisiertes Datenmodell 

Für das historisierte Modell wurde das Datenmodell der operativen Datenbank größtenteils übernommen 

und an den relevanten Stellen angepasst (siehe Abbildung 3.3). 

Eine der relevantesten Änderung ist die Historisierung der Endanwender. Die Tabelle JinengoUser der 

operativen Datenbank wird im Data Warehouse aufgeteilt in zwei Tabellen. Die (verkleinerte) Tabelle 

JinengoUser beinhaltet die (nahezu) unveränderlichen persönlichen Attribute, wie z.B. Name, Geschlecht 

und Geburtsdatum. Die persönlichen Lebensumstände, die Zugänge zu Verkehrsmitteln sowie 

die Präferenzen der Endanwender werden in der Tabelle UserHistoric gespeichert. Die entsprechenden 

Attribute können sich im Laufe der Zeit mehr oder weniger schnell ändern und haben dabei einen wesentlichen 

Einfluss auf das Mobilitätsverhalten. Die entsprechenden Attribute müssen daher zwingend 

historisiert werden. Nur so können auch nach einer Änderung des Attributs die zum Zeitpunkt des 

Reiseantritts gültigen Werte des Attributs nachvollzogen werden. Sobald ein Endanwender eine, oder 

mehrere Attribute verändert, wird ein neuer historisierter Endanwender angelegt, der über eine Fremdschlüsselbeziehung 

mit dem eigentlichen Endanwender (JinengoUser) verbunden ist. Je Endanwender 

existiert daher in der Regel mehr als ein historisierter Datensatz, zu einem Zeitpunkt ist dabei jedoch 

jeweils nur einer dieser Sätze gültig. Die Gültigkeit wird jeweils über einen Zeitraum definiert (valid- 

From & validTill). 

Die Routendaten beziehen sich im Data Warehouse daher auch auf eben diesen historisierten Endanwender. 

Somit ist sichergestellt, dass für jede gefahrene Strecke auch die zum Zeitpunkt der Reise 

gültigen Endanwendereigenschaften gespeichert sind. Ohne diese Historisierung der Eigenschaften 

eines Anwenders wäre hingegen später nicht mehr nachvollziehbar, warum ein Endanwender sich in 

der Vergangenheit für genau diese Routenalternative entschieden hat. Schließlich kann er zum Zeitpunkt 

der Analyse bereits durch ganz andere Eigenschaften und Präferenzen repräsentiert werden. 

57



Das historisierte Datenmodell bietet eine vollständige und damit detaillierte Sicht auf die von Jinengo 

gesammelten Daten. Es dient damit als direkte Datengrundlage für eine Vielzahl von Reportinganforderungen. 

Des Weiteren bedient es das Reporting auch indirekt, indem es für die Bereitstellung von 

Cubes, also einer multidimensionalen Aufbereitung der Daten genutzt werden kann (siehe Kapitel 

3.2.3). 

Aggregiertes Datenmodell 

Im Data Warehouse sind des Weiteren drei aggregierte Tabellen vorgesehen. Sie beinhalten die aufsummierten 

Informationen zur Plattformnutzung (AggrPlatformFigure), den Endanwenderaktivitäten 

(AggrUserFigure) sowie den Endanwenderaktivitäten je Verkehrsmittel (AggrUserFigurePerTranportation). 

Die Tabellen ermöglichen im Gegensatz zu den granular vorliegenden Daten des historisierten 

Data Warehouse einen schnellen Zugriff auf eine aggregierte Datensicht. 

Dies reduziert die notwendige Logik für gängige Anwendungsfelder, die eine entsprechende Datensicht 

vorsehen. Insbesondere trifft dies für das Endanwender-Reporting zu (siehe Kapitel 3.5.1). Da 

dieses Reporting auf Webtechnologien zurückgreift, sind die Reduktion von Programmlogik und Datenumfang 

von besonderer Bedeutung. 

Tabelle 3.2 stellt die einzelnen Aggregationsebenen der Tabellen im Detail dar. Das Datenmodell der 

aggregierten Daten wird in Abbildung 3.4 dargestellt. 

Tabelle 

AggrPlatformFigure 

(Informationen zur Plattformnutzung ) 

AggrUserFigure 

(Informationen zu den Endawenderaktivitäten) 

AggrUserFigurePerTranportation 

(Informationen zu den Endanwenderaktivitäten 

je Verkehrsmittel) 

Aggregationsebene 

Jahr und Monat 

Jahr, Monat, Endanwender und Reisebedürfnis 

Jahr, Monat, Endanwender, Reisebedürfnis und 

Verkehrsmittel 

Tabelle 3.2: Verdichtungsebenen der aggregierten Tabellen im Data Warehouse 

58



Abbildung 3.3: Datenmodell des Data Warehouse 

59



Abbildung 3.4: Datenmodell des aggregierten Data Warehouse 

60



3.2.3 Multidimensionales Data Warehouse 

Neben dem relationalen soll auch ein multidimensionales Data Warehouse aufgebaut werden. Anwendungsfelder 

sind das Reporting mit SQL Server Reporting Services (SSRS) sowie insbesondere Self- 

Service BI mit Microsoft Excel. Die Erstellung des multidimensionalen Data Warehouses geschieht 

mithilfe der SQL Server Analysis Services (SSAS) auf Basis der Daten des relationalen Data Warehouse. 

Das multidimensionale Data Warehouse soll dabei zunächst lediglich aus einem Cube (Subroute) bestehen. 

Dieser Cube soll dazu befähigt werden, nahezu alle zuvor im Fachkonzept definierten Kennzahlen 

und Messgrößen darzustellen 9 . Tabelle 3.3 listet die insgesamt 26 Werte (Kennzahlen und 

Messgrößen) auf, die der Cube umfassen soll. 

9 Lediglich die Kennzahlen „Ausgeschöpftes CO2-Reduktionspotential“ (M11), „Anzahl registrierter Endanwender“, 

(J02) und „Anteil aktiver Endanwender“ (J03) werden nicht abgedeckt. Die Kennzahl M11 ist jedoch 

weniger für das SSRS-Reporting und Self-Service-BI, als vielmehr für das Endanwender-Reporting von 

Relevanz, so dass die entsprechende Kennzahl hier nicht berücksichtigt werden muss. Die Kennzahlen J02 

und J03 lassen sich hingegen aus datentechnischen Gründen leichter durch eine relationale SQL-Abfrage gewinnen. 

61



Sachverhalt 

Anzahl 

der Werte 

Berechnung 

Referenz zum 

Fachkonzept 

Anzahl aktiver Endanwender (Reisende) 1 SUM Kennzahl J01 

Anzahl der Routen 1 SUM Kennzahl M01 

Anzahl der Subrouten 1 SUM Kennzahl M02 

Reisestrecke 

Reisekosten 

4 

4 

SUM 

MIN/MAX/AVG 

SUM 

MIN/MAX/AVG 

Kennzahl M03 

Messgrößen 

Kennzahl M04 

Messgrößen 

Reisekosten pro Kilometer 1 SUM Kennzahl M05 

Reisezeit 

Nutzbare Reisezeit 

4 

4 

SUM 

MIN/MAX/AVG 

SUM 

MIN/MAX/AVG 

Kennzahl M06 

Messgrößen 

Kennzahl M07 

Messgrößen 

Anteil nutzbarer Reisezeit 1 «Formel» Kennzahl M08 


4 

SUM 

MIN/MAX/AVG 

Kennzahl M09 

Messgrößen 

CO 2 -Emissionen pro Kilometer 1 «Formel» Kennzahl M10 

Tabelle 3.3: Kennzahlen und Messgrößen des Subroute-Cubes 

Die Cubedaten sollen durch verschiedene Dimensionen multidimensional dargestellt werden. Im Folgenden 

werden die Dimensionen mitsamt ihren Attributen und Hierarchien 10 dargestellt: 

 

 

 

Zeit: Subrouten verfügen über einen Zeitpunkt der Abreise sowie einen der Ankunft. Beide 

Zeiten sollen durch entsprechende Dimensionen abgebildet werden können. SSAS unterstützt 

die Anlage von Zeitdimensionen. Von Relevanz sind die Attribute Tag, Woche, Monat, Quartal 

und Jahr. Es sind die standardmäßig definierten Hierarchien beizubehalten. 

Verkehrsmittel: Jede Subroute wird mit einem Verkehrsmittel gefahren. Relevante Attribute 

sind die Klasse / der Anbieter (classOrProviderName, z.B. „Fernverkehr“), der Verkehrsmitteltyp 

(transportationType, z.B. „ICE“) sowie der Komfort des Verkehrsmittels (comfort- 

Rating). Zwischen Verkehrsmitteltyp und Klasse/Anbieter ist eine Hierarchie zu erstellen. 

Endanwender: Der Endanwender mitsamt seinen Eigenschaften, der die Subroute gefahren 

ist. Von Relevanz sind alle in den Tabellen UserHistoric und JinengoUser definierten Attribute 

(siehe Tabellen in Abbildung 3.3). Zudem sind die beiden Clusterzuordnungen SustainabilityCluster 

und AttributeCluster von Relevanz. Hierarchien zwischen diesen sehr unterschiedlichen 

Attributen lassen sich nicht definieren. 

10 Hierarchien definieren den Zusammenhang zwischen einzelnen Attributen im Rahmen des Drill-Downs. 

62



 

Route: Jede Subroute gehört zu einer Route mit weiteren spezifischen Eigenschaften. Im Cube 

sollen zunächst die Attribute des Reisebedürfnisses (need), die Angabe zu mitgeführtem 

Gepäck (luggage) sowie die Anzahl der Passagiere (passengers) berücksichtigt werden. Hierarchien 

zwischen den einzelnen Attributen lassen sich nicht definieren. 

Anders als im Fachkonzept dargestellt, erfolgt im Subroute-Cube keine Berücksichtigung der Raum- 

Dimension. Dies ist darin begründet, dass SSAS-Cubes den Geokoordinaten-Datentyp des SQL- 

Servers nicht unterstützen. Die Funktionen des vergleichsweise neuen Datenformats (Katibah & Stojic 

2011) bleiben daher relationalen Abfragen vorbehalten. Der in Kapitel 3.5.2 beschriebene Report mit 

der geographischen Darstellung der Kennzahlen wird daher auch mithilfe des relationalen Data Warehouse 

realisiert. 

63



Abbildung 3.5 gibt einen zusammenfassenden Überblick über die zuvor beschriebene semantische 

Modellierung des Subroute-Cubes 11 . 

Abbildung 3.5: Semantische Modellierung des Subroute-Cube 

11 Die Zeit-Dimension weicht bezüglich der deutschsprachigen Attributbenennungen von der englischsprachigen 

Projektkonvention ab. Dies liegt darin begründet, dass die Zeitdimension von SSAS unterstützt angelegt wird 

und die Benennung aufgrund der eingesetzten Softwareversion deutschsprachig erfolgt. 

64



3.3 Datenflüsse 

Die folgenden Datenflüsse dienen der Übertragung von Daten zwischen verschiedenen Datenbanken 

und Tabellen. Zum Einsatz sollen dabei jeweils die SQL Server Integration Services (SSIS) kommen, 

die integraler Bestandteil des SQL-Servers von Microsoft sind. 

Im Folgenden werden die Charakteristika der im Rahmen des Projektes relevanten Integrationsprozesse 

beschrieben. Da die Daten im Projekt durch einen Datengenerator künstlich und einmalig erzeugt 

werden, ist die regelmäßige Einplanung der einzelnen Prozesse als automatisch ablaufender Job zunächst 

nicht von Interesse. Stattdessen ist die manuelle Ausführung der Integrationsprozesse noch 

ausreichend. Dies erleichtert auch das Monitoring von Erfolg bzw. Misserfolg der einzelnen Prozessausführungen. 

Langfristig ist jedoch insbesondere für den ETL- sowie den Aggregationsprozess eine 

Einplanung als automatischer Job von Relevanz 12 . 

3.3.1 Prozess zur Füllung der operativen Datenbank mit generierten Daten 

Die Füllung der operativen Datenbank erfolgt im Rahmen der Projektarbeit durch generierte Daten 

und nicht durch die Interaktion von Endanwendern. Die Stammdaten der operativen Datenbank werden 

durch den Datengenerator (siehe Kapitel 4.1) direkt gefüllt. Die verkehrsbezogenen Bewegungsdaten 

(Route und Subroute) werden vom Generator hingegen zunächst in die temporären Tabellen 

A_SOURCE_Route und A_SOURCE_Subroute gespeichert. Ein Integration-Service muss daher die 

folgenden Verarbeitungsschritte durchlaufen: 

1. Selektierung aller neu generierten Routendaten (A_SOURCE_Route) und Einfügung dieser in 

die operative Datenbanktabelle Route. 

2. Selektierung aller zugehörigen Subroutendaten (A_SOURCE_Subroute) und Einfügung dieser 

in die operative Datenbanktabelle Subroute. 

3. Kennzeichnung der soeben verarbeiteten Routen (Attribut isProcessed in 

A_SOURCE_Route), so dass sie beim nächsten Durchlauf nicht erneut berücksichtigt werden. 

Der Prozess wird manuell gestartet, da der Datengenerator ebenfalls manuell gestartet wird und daher 

nur sporadisch mit neuen Daten zu rechnen ist. Auf längere Sicht sind die Endanwender und nicht 

mehr der Datengenerator für die Generierung von Datensätzen zuständig. 

12 Die automatische Ausführung von Integrationsprozessen wird vom SQL Server unterstützt und im Rahmen 

der Jinengo-Dokumentation auch angeleitet. 

65



3.3.2 ETL-Prozess zur Füllung des relationalen Data Warehouse 

Die operative Datenbank und das historisierte relationale Data Warehouse haben eine nahezu identische, 

in Teilen aber dennoch abweichende Struktur. Ein ETL-Prozess soll die Füllung des Data Warehouses 

vornehmen und die dabei notwendigen Transformationen vornehmen. 

Die meisten Schritte des ETL-Prozesses befassen sich mit der Verarbeitung von Stammdaten. Dabei 

wird das Data Warehouse mit der operativen Datenbank gleichgezogen, eine Historisierung findet 

nicht statt. Eine Ausnahme stellt insbesondere die Endanwender-Tabelle (JinengoUser) dar, bei der 

ein Großteil der Attribute im Data Warehouse in der Tabelle UserHistoric historisiert wird. Ein kleinerer 

Teil der Attribute wird auch hier hingegen nicht historisiert und verbleibt in der Tabelle JinengoUser. 

Die Zweiteilung der Endanwenderattribute in zwei Tabellen führt dazu, dass die Fremdschlüssel 

in allen abhängigen Tabellen angepasst werden müssen. Statt der JinengoUser-ID muss im Data Warehouse 

flächendeckend die UserHistoric-ID verwendet werden. Der ETL-Prozess muss daher jeweils 

die aktuell gültige Identifikationsnummer für den historisierten Anwender bestimmen und alle Fremdschlüssel 

entsprechend umschreiben. 

In den Tabellen Route und Subroute finden zudem einige weitere Transformationen statt: 

 

 

 

Für den einfacheren Zugriff sollen im Data Warehouse auf Ebene der Route auch Umweltwirkung 

(ecoImpactTotal), nutzbare Zeit (effectiveTimeTotal), Kosten und Reisestrecke (distanceTotal) 

der zugehörigen Subrouten aggregiert werden. 

Die Streckenattribute in Route und Subroute sollen von Meter in Kilometer umgerechnet werden, 

da dies die Handhabung mit größeren Werten erleichtert. 

Alle sonstigen Messwerte (Kosten & Umweltwirkungen) sollen auf zwei Nachkommastellen 

gerundet werden. Diese Detailierungsebene ist für Analysen ausreichend und vereinfacht die 

Darstellung der Werte in Reports und Dashboards. 

Tabelle 3.4 fasst die hier beschriebenen Anforderungen an den ETL-Prozess noch einmal aus Sicht der 

einzelnen Tabellen zusammen. Dabei werden zusätzlich auch die gegenseitigen Abhängigkeiten definiert, 

die sich durch die Fremdschlüsselbeziehungen der einzelnen Tabellen ergeben. Im Anschluss an 

die Verarbeitung aller Tabellen müssen die Cubes des Analysis-Services aktualisiert werden, damit die 

neu eingespielten Daten auch im multidimensionalen Data Warehouse zur Verfügung stehen. 

Der gesamte Prozess wird zunächst manuell angestoßen, da aufgrund des sporadischen Starts des Datengenerators 

zunächst nicht dauerhaft mit neuen Daten zu rechnen ist. Auf längere Sicht ist für den 

operativen Betrieb von Jinengo jedoch eine regelmäßige automatische Einplanung des ETL-Prozesses 

denkbar. Das entsprechende Vorgehen wird daher bereits in der Jinengo-Dokumentation beschrieben. 

66



# Tabelle Beschreibung des Schritte Vorgänger 

1 Transportation- 

Type 

Neue & geänderte Datensätze werden im Data Warehouse 

nachgezogen (keine Historisierung). Eine Löschung findet nicht 

statt. 

2 Transportation Neue & geänderte Datensätze werden im Data Warehouse 


statt. 

3 FamilyStatus Neue & geänderte Datensätze werden im Data Warehouse 


statt. 

4 IncomeRange Neue & geänderte Datensätze werden im Data Warehouse 


statt. 

5 Need Neue & geänderte Datensätze werden im Data Warehouse 


statt. 

6 Rail-Membership Neue & geänderte Datensätze werden im Data Warehouse 


statt. 

7 JinengoUser 

(als Datenquelle) 

JinengoUser & 

UserHistoric 

(als Datenziel) 

8 JinengoUser- 

Friend 

9 CarSharing- 

Membership 

Berücksichtigt werden neue Datensätze und Änderungen. Anwender 

werden nicht gelöscht, sondern ungültig gestempelt. 

Die Entität wird im Data Warehouse zweigeteilt in JinengoUser 

und UserHistoric. JinengoUser enthält lediglich die Attribute, 

die die physische Identität eines Anwenders ausmachen (z.B. 

Name, Geburtsdatum). Änderungen dieser Attribute werden 

(ohne Historisierung) im Data Warehouse nachgezogen. 

UserHistoric hingegen enthält die Attribute, die historisiert 

(Neuanlage & Ungültigstempelung) nachverfolgt werden sollen. 

Neue Datensätze und Löschungen werden nachgezogen, Änderungen 

finden nicht statt (keine Historisierung). 

Umschreibung des Anwender-Fremdschlüssels (UserHistoric) 

Neue Datensätze werden im Data Warehouse hinzugefügt. Gelöschte 

Datensätze werden historisch nachverfolgt (Neuanlage 

& Ungültigstempelung). Änderungen finden nicht statt. 


10 Route Neue Datensätze werden in das Data Warehouse übertragen. 

Nachträgliche Änderungen und Löschungen finden nicht statt. 

Umweltwirkung (ecoImpactTotal), nutzbare Zeit (effectiveTimeTotal), 

Kosten und Reisestrecke (distanceTotal) der zugehörigen 

Subrouten werden auf Routenebene aggregiert. 

Streckenattribute werden von Metern in Kilometer umgerechnet, 

alle Messwerte auf 2 Nachkommastellen gerundet. 


11 Subroute Neue Datensätze werden in das Data Warehouse übertragen. 

Nachträgliche Änderungen und Löschungen finden nicht statt. 

Streckenattribute werden von Metern in Kilometer umgerechnet, 

alle Messwerte auf 2 Nachkommastellen gerundet. 

- 

1 

- 

- 

- 

- 

3, 4, 6 

7 

2, 7 

5, 7 

2, 10 

67




Tabelle 3.4: Beschreibung der Schritte des ETL-Prozess 

3.3.3 Aggregation von Daten im Data Warehouse 

Zusätzlich zu den historisierten Tabellen verfügt das Data Warehouse auch über drei aggregierte Tabellen, 

die den Zugriff auf eine verdichtete Sicht der Reisedaten vereinfachen. Die Verdichtung erfolgt 

dabei gemäß der in Tabelle 3.2 dargestellten Ebenen. 

Der Prozess zur Aktualisierung der drei Tabellen erfolgt durch die folgenden Schritte: 

1. Bestimmung der Jahr-Monat-Konstellationen, bei denen Routen noch nicht in die Aggregation 

einbezogen wurden (Attribut isAggregatedInDW), da sie seit der letzten Verdichtung 

hinzugekommen sind. Für diese Konstellationen müssen die aggregierten Daten neu berechnet 

werden. 

2. Löschung der veralteten Jahr-Monat-Konstellationen in den drei Aggregationstabellen. 

3. Erneute Datenaggregation und Einfügung der entsprechenden Datensätze in die drei Aggregationstabellen. 

Die Verdichtung erfolgt dabei für jede Tabelle spezifisch entsprechend ihrer 

Aggregationsebene. 

4. Kennzeichnung der aggregierten Routen mithilfe des Attributs isAggregatedInDW. 

Der Prozess wird zunächst manuell nach Abschluss des ETL-Prozesses angestoßen. Auf längere Sicht 

ist jedoch analog zum ETL-Prozess eine regelmäßig automatische Einplanung des Prozesses denkbar. 


Ziel des Data Mining ist es, aus den Daten des Data Warehouse neue Erkenntnisse zu ziehen und Zusammenhänge 

in den Daten zu entdecken. Um diese Aufgabe bewerkstelligen zu können wird es zwischen 

der operativen Datenbank und dem Data Warehouse eingeordnet (siehe Abbildung 3.1). 

Das Data Mining wird im Projekt mit dem SPSS Modeler 15 umgesetzt. Das Tool bietet umfangreiche 

Modellierungsmöglichkeiten. Daten lassen sich sowohl aus dem SQL Server als auch, falls notwendig, 

aus CSV-Dateien auslesen. Im Modeler können die Daten so vorbereitet werden, wie sie für das Data 

Mining benötigt werden. Die alternative Lösung mit den Data-Mining-Tools von SSAS bietet nicht 

denselben Umfang und Komfort. Der SPSS Modeler ist sowohl in der Datenintegration, -extraktion 

und Data-Mining-Fähigkeit umfangreicher und komfortabler als SSAS. 

Der in den einzelnen Methoden angewandte Algorithmus hat sich während der Tests als am stabilsten 

herausgestellt. Es ist allerdings nicht aus zu schließen, dass sich dieser mit einer realen Datenbasis 

ändern könnte. 

68



In der Tabelle 3.5 werden die in dem Fachkonzept formulierten Anwendungsfälle und die für die Lösung 

verwendeten Methoden miteinander in Beziehung gebracht. 

Anwendungsfall aus Fachkonzept verwendete Data-Mining-Methode 

Eigenschaften raten 

Klassifizierung 

Newsletter & Reporting 

Clustering 

Ökologische Alternativen vorschlagen Assoziation 

Warnung vor ungewöhnlichem Verhalten eigene Logik auf Basis der Data-Mining-Ergebnisse 

Tabelle 3.5: Zuordnung der Data-Mining-Methoden zu den Anwendungsfällen 

3.4.1 Klassifizierung 

Ziel der Klassifizierung ist es, Eigenschaften von Endanwendern – z.B. Besitz eines Elektroautos 

(ownsPEV) – zu ermitteln, die mit einer gewissen Konfidenz (z.B. >98%) vorliegen, aber bislang vom 

Benutzer nicht angegeben wurden (Besitz Elektroauto bislang NULL). Der Schwellenwert für die 

Konfidenz-Akzeptanz sollte von Fall zu Fall angepasst werden. Einen Richtwert liefert der im SPSS 

Modeler ausgegebene Wert „always correct above“. 

Input: 

 

 

 

 

Anzahl der gefahrenen Strecken pro Verkehrsmittel 

Persönliche Attribute (Geschlecht, etc.) 

Besitz von Verkehrsmittel (ownsPEV, ownsEbike, etc.) 

Endanwenderpräferenzen 

Algorithmus: 

 

 

CHAID 

Der Algorithmus muss mit sich ändernden Daten überprüft und angepasst werden, da verschiedene 

Algorithmen mit fehlenden Datensätzen besser / schlechter umgehen können. 

Output: 

Die Ergebnisse werden in das Data Warehouse geschrieben (jinengoData- 

Warehouse.dbo.ClassificationPrediction). 

Spalten der Tabelle: jinengoUserID, userHistoricID, attribute, attributeValue, attributePrediction, 

predictionConfidence, predictionDate und predictionAcception. 

Die Attribut-Spalte speichert den Namen des Attributs (Bspw.: ownsPEV, ownsEbike, etc), in der 

Spalte attributeValue wird der angegebene Wert abgespeichert. Vergleichend dazu wird in der Spalte 

attributePrediction der durch DataMining ermittelte Konfidenzwert festgehalten. 

69



3.4.2 Clustering 

Clustering zielt auf zwei Fälle ab. Zum einen sollen Newsletter personalisiert zugestellt werden können 

und zum anderen Reports und Dashboards eine zusätzliche Dimension zur Unterteilung von Endanwendern 

erhalten. 

Dabei werden zwei Cluster definiert. Das Sustainability-Cluster gruppiert Endanwender in Bezug auf 

ihr Reiseverhalten. Das Personen-Cluster hingegen ordnet Anwender entsprechend ihrer persönlichen 

Attribute in Gruppen ein. 

Personen-Cluster 

Input: 

 

 

 

Personenattribute (Geschlecht, Alter, etc) 

Besitz von Verkehrsmitteln oder ÖPNV (owns-Attribute) 

Userpräferenzen 

Algorithmus: 

 

K-Means 

Output: 


Warehouse.dbo.UserAttributeClustering) 

Spalten der Tabelle: jinengoUserID, userHistoricID, cluster, clusterdescription, date 

Sustainability-Cluster 

Input: 

 

 

 

 

 

 

CO 2 -Emissionen je Kilometer 

Absolute CO 2 -Emissionen 

Gefahrene Kilometer 

Genutzte Verkehrsmittel 

Summe der Strecken 

Km pro Strecke 

70



Algorithmus: 

 

Two-Step 

Output: 


Warehouse.dbo.UserSustainabilityClustering) 

Spalten: userHistoricID, cluster, clusterdescription, date 

3.4.3 Assoziation 

Durch einen Assoziationsalgorithmus sollen Konsummuster und damit mögliche Veränderungspotentiale 

bei Endanwender aufgedeckt werden. Die Daten werden auf Regeln hin untersucht, die zu einer 

gewissen Sicherheit vermuten lassen, dass ein Endanwender Interesse an einem nachhaltigen Verkehrsmittel 

hat. Trifft diese Regel zu, wird das Ergebnis in das Data Warehouse geschrieben. Der Anwendungsfall 

wird beispielhaft an dem Attribut zum Besitz eines Autos mit Verbrennungsmotor 

(ownsGasCar) umgesetzt. Um akzeptiert zu werden, sollte eine Regel über 10% Support und 90% 

Konfidenz liegen. Allerdings hängen diese Werte stark von den untersuchten Daten ab und sollten 

daher bei Bedarf, sowohl nach oben als auch unten, angepasst werden. 

Input: 

 

 

 

 

 

 

Genutzte Verkehrsmittel 

persönliche Attribute 

Besitz von Verkehrsmitteln 

Routen Attribute 

Cluster 

CO 2 -Emissionen / Vor- und Nachteile der gewählten Routen 

Alle Input-Attribute, die keinen kleinen diskreten Wertebereich haben, werden in Quartile eingeteilt. 

Die Grenzen der Quartile werden anhand des minimalen und des maximalen Wertes gesetzt. 

Algorithmus: 

 

Apiori 

71



Output: 

 

 

Die ermittelten Regeln werden mit einem Entscheidungsbaum auf den Datensatz angewandt. 

In die Datenbank werden nur die Datensätze zurückgeschrieben, bei denen das Zielattribut 

(ownsGasCar) NULL oder 0 als Ausprägung besitzt. 

Die Zieltabelle ist jinengoDataWarehouse.dbo.AssociationResults 

3.4.4 Warnen vor „ungewöhnlichem“ Verhalten 

Während die oberen drei Anwendungsfälle jeweils eine Methode des Data Mining verwenden, um 

Erkenntnisse aus den Daten zu gewinnen zielt dieser Anwendungsfall darauf ab, durch eine Verbindung 

der Data-Mining-Ergebnisse und den vorhandenen Endanwender- und Routendaten neue Erkenntnisse 

zu gewinnen. 

Anwender die bspw. ein E-Bike besitzen, es aber nie nutzen, werden mit Hilfe dieser Daten identifiziert. 

Daraus lässt sich ein Entscheidungsbaum entwickeln, der auf Basis der gefahrenen Routen und 

angegebenen Präferenzen eine Konsequenz ableitet. Da es sehr viele Möglichkeiten gibt Verhalten von 

Endanwender zu analysieren werden hier die Potentiale dieser Methode anhand des Beispiels E-Bike 

aufgezeigt. 

USE-CASE: ownsEBike 

Wie in der Abbildung 3.6 zu sehen, kann es zwei Ausgangssituationen geben. Zum einen kann der 

Anwender angegeben haben, dass er ein E-Bike besitzt (Angabe = 1), laut Data Mining verhält er sich 

aber nicht so (Prediction = 0). Anders herum kann er angegeben haben, dass er kein E-Bike besitzt 

(Angabe = 0), er verhält sich aber laut Data-Mining so (Predicition = 0). Selbstverständlich kann es 

analog dazu auch noch die Fälle geben in denen der Anwender keine wahrheitsgemäße Aussage getroffen 

hat. Im Folgenden soll das Hauptaugenmerk aber auf wahrheitsgemäße Angaben gelegt werden. 

Der Vollständigkeit halber seien die anderen Fälle aber auch noch erwähnt: 

 

 

Laut Angabe hat der Anwender kein E-Bike (Angabe = 0), er besitzt aber eins (korrekte Angabe 

wäre demnach 1). Das Data-Mining erkennt den Endanwender als eine Person die ein E- 

Bike besitzen (Predicition = 1) und das ist korrekt. 

Laut Angabe hat der Anwender ein E-Bike (Angabe = 1), er besitzt aber keins (Korrekte Angabe 

wäre demnach 0). Das Data-Minig erkennt den Endanwender als eine Person die kein 

eBike besitzen (Predicition = 0) und das ist korrekt. 

Bei diesen zwei Fällen müsste nichts weiter geschehen als den Anwender auf die Vermutung aufmerksam 

zu machen. 

72



In den zwei Fällen, die in der Abbildung 3.6 dargestellt sind muss die Schätzungen anschließend überprüft 

werden. Nutzt der User das E-Bike bzw. das Bike oft, so kann darauf reagiert werden mit Meldungen, 

Abfragen, oder zielgerichteter Werbung. 

eBike Szenario 

Angabe: 1 

Predicition: 0 

Angabe: 0 

Predicition: 1 

Prüfen ob eBike 

oft genutzt 

Prüfen ob viel 

Bike gefahren 

Nutzung hoch 

Nutzung niedrig 

Nutzung gering 

Nutzung hoch 

Schätzung falsch, 

keine Meldung 

Meldung: User 

fragen, warum. 

Keine Meldung 

da Schätzung 

„falsch“ 

Weitere 

Prüfung* 

Abbildung 3.6: Entscheidungsbaum UseCase OwnsEbike 

Sollte die Überprüfung zum Beispiel ergeben haben, dass die Schätzungen falsch waren, so ist dies zu 

dokumentieren und nach außen keine weitere Meldung zu erstatten. War die Schätzung laut Überprüfung 

korrekt, sollte der Dialog mit dem Anwender gesucht werden. Für den Fall, dass gegen die Angabe 

des Endanwenders der Besitz eine E-Bikes vermutet wurde und die Prüfungen ergeben haben, 

dass dieser viel Fahrrad fährt wäre es natürlich nicht ökologisch diesem Anwender ein E-Bike vorzuschlagen. 

Schließlich fährt er mit seinem Fahrrad ohne Elektrounterstützung deutlich umweltfreundlicher. 

So könnten an dieser Stelle weitere Prüfungen angebracht sein. Zum Beispiel könne geprüft werden 

ob der Endanwender auch viel Auto auf kurzen Strecken fährt. Dann könnte man ihm vorschlagen, 

diese Strecken mit einem E-Bike zu bewältigen. 

Ein solches Vorgehen zur Wissensgewinnung ist auch mit den anderen Endanwender-Attributen möglich: 

 

 

 

 

Bahncard Mitgliedschaft (RailMembershipID) 

Besitz eines Autos mit Verbrennungsmotor (ownsGasCar) 

Besitz einer Monatskarte (publicTransportMember) 

Besitz eines Elektroautos (ownsPEV) 

Sinn macht es aber nur, wenn die Reaktion des Nutzers auf die Werbung bzw. den Vorschlag dokumentiert 

werden kann. 

73



3.5 Reports & Dashboards 

Im Folgenden werden die Reports und Dashboards definiert, die die zuvor im Fachkonzept thematisierten 

Reportinganforderungen der verschiedenen Stakeholder 13 abdecken. Dabei sollen unterschiedliche 

Softwarelösungen für die Realisierung verwendet werden: 

 

 

 

Das Endanwender-Reporting erfolgt über eine Eigenentwicklung auf Basis von Webtechnologien 

und Java. Dies liegt insbesondere darin begründet, dass der Microsoft SQL Server keine 

entsprechende Software vorsieht, die auch von externen Stakeholdern gut benutzt werden 

kann. Nicht zuletzt ermöglicht die Eigenentwicklung im Anschluss an das Projekt eine bessere 

Integration in die Jinengo-Plattform. 

Das Reporting für Management, Wissenschaftler und Mobilitätsanbieter hingegen erfolgt 

über gängige BI-Standardsoftware. Zum Einsatz kommen sollen dafür sowohl die SQL Server 

Reporting Services (SSRS) als auch QlikView, um auf diese Weise auch einen Vergleich verschiedener 

Softwarelösungen zu ermöglichen. 

Die Self-Service BI für Management, Wissenschaftler und Mobilitätsanbieter wird 

exemplarisch anhand von Microsoft Excel exerziert. 

3.5.1 Reporting für Endanwender 

Für das Reporting der Endanwender-Kennzahlen gilt es ein Webinterface zu erstellen. Dieses soll als 

leichtgewichtige Webanwendung realisiert werden, die alle notwendigen Daten über eine Web- 

Schnittstelle erhält. Ziel des Webinterface ist es, die wesentlichen Kennzahlen kompakt aufbereitet 

und graphisch ansprechend dem Nutzer darzustellen. 

Das Webinterface soll dabei unterschiedliche Möglichkeiten der Kennzahlendarstellung für Endanwender 

aufzeigen und diese beispielhaft implementieren. Durch die Verwendung von Webstandards 

soll eine allgemeingültige Vorlage geschaffen werden, die in Zukunft leicht in anderen Webanwendungen 

integriert oder als eigenständige Anwendung weiterentwickelt werden kann. 

13 Management, Wissenschaftler und Mobilitätsanbieter werden im Folgenden nicht mehr streng voneinander 

getrennt. Trotz unterschiedlicher Motive und Zielsetzungen sind ihre Anforderungen vergleichsweise ähnlich 

und lassen sich insbesondere auf der exemplarischen Ebene des Projekts nicht trennscharf voneinander trennen. 

74



Aus dem Fachkonzept ergeben sich eine Reihe an Anforderungen für die Implementierung der Web- 

Oberfläche. Das folgende Mockup (Abbildung 3.7) stellt den geplanten Aufbau und Inhalt des Dashboards 

für Endanwender dar. 

Inhalt & Zweck 

Abbildung 3.7: Mockup des Dashboards „Endanwender-Kennzahlen über die Zeit“ 

Dargestellte Kennzahlen 

Abgebildete Dimension 

Parameter 

Interaktionsmöglichkeiten 

Eine vom Endanwender über das Menü gewählte Kennzahl wird auf 

Monatsbasis aggregiert über die Zeit als Kurvenverlauf darstellt. Die 

dunkle Kurve steht für das Fahrverhalten des Anwenders, die helle für 

das Fahrverhalten einer Vergleichsperson. 

M03 – Reisestrecke 

M04 – Reisekosten 

M05 – Reisekosten pro Kilometer 

M06 – Reisezeit 

M07 – Nutzbare Reisezeit 

M09 – CO 2 -Emissionen 

M10 – CO 2 -Emissionen pro Kilometer 

Zeit (Verlauf eines definierten Jahres, Granularität: Monat). 

Endanwender-ID (Indirekt ausgelesen über eingeloggten Nutzer). 

Wechseln zwischen den dargestellten Kennzahlen über Navigationsmenü. 

Auswahl einer befreundeten Referenzperson für Vergleichskurve. 

Mouseover über Chart für detaillierte Monatskennzahl. 

Tabelle 3.6: Charakteristika des Dashboards „Endanwender-Kennzahlen über die Zeit“ 

Zentrale Einheit des Webinterfaces bildet die graphische Darstellung der Kennzahlen. Neben dem 

Chart beinhaltet das Webinterface zwei weitere wesentliche Bereiche: 

75



 

 

Eine individuelle Überschrift, welche den aktuell angemeldeten Anwender namentlich begrüßt 

und durch einen begleitenden Satz zur Nutzung des Dashboards motiviert. 

Eine Navigationsleiste die eine Interaktion mit dem Dashboard ermöglicht. Diese beinhaltet: 

o Ein Drop-Down-Menü mit welchem der Anwender durch die Anwendung navigieren 

und sich die vier Kennzahlen CO2-Emission, Kosten, Reisezeit und Reisetrecke in unterschiedlichen 

Darstellungsformen dynamisch anzeigen lassen kann. 

o Ein Drop-Down-Menü über welches der Anwender auswählen kann, mit welchen seiner 

Freunde er sich vergleichen möchte. Ist kein Freund gewählt, wird der Plattformdurchschnitt 

als Vergleich dargestellt. 

o Ein Logout-Button der es dem Anwender ermöglicht sich von der Anwendung abzumelden. 

Eine weitere Darstellungsform ist die der Aufschlüsselung der Kennzahlen nach den genutzten Verkehrsmitteln 

in Form von Kuchendiagrammen (siehe Abbildung 3.8). 

Abbildung 3.8: Mockup des Dashboards „Endanwender-Kennzahlen nach Verkehrsmittel“ 

76






Parameter 


Die beiden Kuchendiagramme zeigen den Anteil der Verkehrsmittel an 

der gewählten Kennzahl. 

Das linke Kuchendiagramm zeigt hierbei die Anteile des aktuellen Anwenders, 

während das rechte Diagramm die Anteile einer Referenzperson 

abbildet. In diesem Beispiel die im Drop-Down-Menü gewählte 

Freundin Christina. 

M03 – Reisestrecke 

M04 – Reisekosten 

M06 – Reisezeit 

M09 – CO 2 -Emissionen 

Verkehrsmittel (Aggregiert auf ein Jahr). 

Endanwender-ID (Indirekt ausgelesen über eingeloggten Nutzer). 

Wechseln zwischen den dargestellten Kennzahlen über Navigationsmenü. 

Auswahl der Referenzperson für Vergleichsdiagramm. 

Tabelle 3.7: Charakteristika des Dashboards „Endanwender nach Verkehrsmittel“ 

Eine weitere Darstellungsform ist die Visualisierung des CO 2 -Einsparpotentials des Anwenders. Hierdurch 

soll aufgezeigt werden, wie viel nachhaltiger sich ein Anwender verhalten könnte, wenn er 

CO2-emissionsärmere Verkehrsmittel wählen würde (siehe Abbildung 3.9). 

Abbildung 3.9: Mockup des Dashboards „CO 2 -Einsparpotential des Anwenders“ 

77






Parameter 


Das Dashboard beinhaltet zwei unterschiedliche Diagramme. 

Im linken Chart wird dargestellt wie sich der CO 2 -Ausstoß des Anwenders 

im Vergleich zu seinem maximal und minimal möglichen CO 2 - 

Ausstoß verhält. Der Kurvenverlauf des Anwenders bewegt sich dabei 

im Bereich zwischen der minimalen und maximalen CO 2 -Emission. 

Auf der rechten Seite wird ein Nachhaltigkeitstacho dargestellt, welcher 

den Inhalt des linken Charts kompakt zusammenfasst. Ziel ist es, dem 

Anwender aufzuzeigen, wie viel Prozent seines CO 2 -Einsparpotentials er 

ausgeschöpft hat und wie viel nachhaltiger er sich noch verhalten könnte. 

M09 – CO 2 -Emission 

M11 – Ausgeschöpftes CO 2 -Reduktionspotential 

Verkehrsmittel (Aggregiert auf ein Jahr). 

Endanwender-ID (Indirekt ausgelesen über eingeloggten Nutzer) 

Keine 

Tabelle 3.8: Charakteristika des Dashboards „CO 2 -Einsparpotential des Anwenders“ 

3.5.2 Reporting für Management, Wissenschaftler & Mobilitätsanbieter 

Für Management, Wissenschaftler und Mobilitätsanbieter werden die folgenden Dashboards und Reports 

definiert. Mithilfe des SQL Server Reporting Services (SSRS) sollen umgesetzt werden: 

 

 

 

 

 

 

SSRS1: Jinengo-Überblick 

SSRS2: Clusteranalyse 

SSRS3: Orte in Oldenburg 

SSRS4: Nutzung der Plattform 

SSRS5: Reisekennzahlen nach Zeit & Verkehrsmittel 

SSRS6: Reisekennzahlen nach Zeit & Präferenz 

Diese Dashboards und Reports lassen sich einzeln über das SSRS-Webportal aufrufen. Zudem ermöglichen 

Verknüpfungen die einfache Navigation zwischen den einzelnen Elementen. So soll es möglich 

sein, alle Reporting-Elemente über die Navigation des SSRS1-Dashboards zu erreichen. Von allen 

anderen Elementen lässt es sich zu SSRS1 zurücknavigieren. Die technische Einheitlichkeit der einzelnen 

Elemente wird durch einen einheitlichen graphischen Stil komplettiert. 

Mithilfe von QlikView sollen umgesetzt werden: 

 

QV1: Dashboard zur Plattformnutzung 

78



SSRS1: Jinengo-Überblick 

Tabelle 3.9 und Abbildung 3.10 beschreiben Inhalt und Aufbau des Dashboards „Jinengo-Überblick“. 



Abgebildete Dimensionen 

Datengrundlage 

Zugriffsmöglichkeit 

Parameter 


Das Dashboard gibt einen Überblick über die Nutzung der Plattform 

und ausgewählte Kennzahlen. Dargestellt werden: Anzahl der Routen 

und der aktiven Endanwender, die beliebtesten Abfahrtsorte (Top 10), 

sowie der Streckenanteil der Verkehrsmittel und der Anteil der unterschiedlichen 

Endanwendergruppen (Attributscluster des Data Minings). 

Das Dashboard ist von besonderer Bedeutung für das Jinengo- 

Management. Aber auch Wissenschaftler & Mobilitätsanbieter können 

sich unter Umständen für eine solche Darstellung interessieren. 

- J01 – Anzahl aktiver Endanwender 

- M01 – Anzahl der Routen 

- M03 – Reisestrecke 

- Zeit (Quartal des ausgewählten Jahres) für die Kennzahlen J01 und 

M01 

- Raum (Abfahrtsort) für die Kennzahl M01 

- Verkehrsmittel sowie Attributscluster (Endanwender) für Kennzahl 

M03 

Relationales sowie multidimensionales Data Warehouse 

Per Internet Explorer über das SSRS-Webportal 

Jahr, für welches das Mobilitätsverhalten dargestellt werden soll 

Keine 

Tabelle 3.9: Charakteristika des Dashboards „Jinengo-Überblick“ 

Abbildung 3.10: Mockup des Dashboards „Jinengo-Überblick“ 

79



SSRS2: Clusteranalyse 

Tabelle 3.10 und Abbildung 3.11 beschreiben Inhalt und Aufbau des Dashboards „Clusteranalyse“. 






Parameter 


Das Dashboard stellt das Verhalten eines angenommenen durchschnittlichen 

Endanwenders dar. Die Durchschnittsbildung erfolgt dabei 

zweimal, jeweils auf Grundlage eines der beiden Cluster (Attribut- und 

Nachhaltigkeitscluster). 

Das „Durchschnittsverhalten“ der beiden Cluster wird dabei jeweils mit 

den gesamten Reisekosten, den gesamten CO 2 -Emissionen und den 

CO 2 -Emissionen pro Kilometer beschrieben. 

- M04 – Reisekosten 

- M09 – CO 2 -Emissionen 

- M10 – CO 2 -Emissionen 

Attributscluster sowie Nachhaltigkeitscluster der Endanwender 

Multidimensionales Data Warehouse 



Keine 

Tabelle 3.10: Charakteristika des Dashboards „Clusteranalyse“ 

Abbildung 3.11: Mockup des Dashboards "Clusteranalyse" 

80



SSRS3: Orte in Oldenburg 

Tabelle 3.11 und Abbildung 3.12 beschreiben Inhalt und Aufbau des Dashboards „Orte in Oldenburg“. 






Parameter 


Das Dashboard gibt Einblick in das Mobilitätsverhalten in Oldenburg. 

Es steht damit exemplarisch für eine regionale Analyse von Verkehrsverhalten. 

Beliebte Abfahrtsorte bzw. Zielorte von Routen werden auf einer 

Landkarte visualisiert. Die Orte werden entsprechend ihrer Attraktivität 

auf der Karte eingefärbt. 

Das Dashboard ist insbesondere für in der Region ansässige Mobilitätsanbieter 

von Interesse. So könnte beispielsweise ein CarSharing- 

Unternehmen lukrative neue Standorte für Parkplätze evaluieren. 

M01 – Anzahl der Routen 

Raum (auf Landkarte) 

Relationales Data Warehouse 



Keine 

Tabelle 3.11: Charakteristika des Reports „Orte in Oldenburg“ 

Abbildung 3.12: Mockup des Dashboards "Orte in Oldenburg" 

81



SSRS4: Nutzung der Plattform 

Tabelle 3.12 und Abbildung 3.13 beschreiben den Report „Nutzung der Plattform“. 






Parameter 


Der Report gibt einen Überblick über die Entwicklung und Nutzung 

der Plattform im Laufe des Jahres. Diese Übersicht ist von besonderer 

Bedeutung für das Jinengo-Management. Aber auch Wissenschaftler 

& Mobilitätsanbieter können sich unter Umständen für eine solche 

Darstellung interessieren. 

- J01 – Anzahl aktiver Endanwender 

- J02 – Anzahl registrierter Endanwender 

- J03 – Anteil aktiver Endanwender 




- M09 – CO2-Emissionen 

- M11 – Ausgeschöpftes CO2-Reduktionspotential 

Zeit (Verlauf eines definierten Jahres, Granularität: Monat) 

Relationales Data Warehouse 


Jahr, für welches die Kennzahlen dargestellt werden sollen 

Keine 

Tabelle 3.12: Charakteristika des Reports „Nutzung der Plattform“ 

Abbildung 3.13: Mockup des Reports „Nutzung der Plattform“ 

82



SSRS5: Reisekennzahlen nach Zeit & Verkehrsmittel 

Tabelle 3.13 und Abbildung 3.14 beschreiben den Report „Reisekennzahlen nach Zeit & Verkehrsmittel“. 






Parameter 


Der Report schlüsselt ausgewählte Reisekennzahlen mithilfe der beiden 

Dimensionen Zeit und Verkehrsmittel zweidimensional auf. Beide 

Dimensionen ermöglichen ein Drilldown. 




- M06 – Reisezeit 


Verkehrsmittel und Zeit 



Zeitraum, für welchen die Kennzahlen dargestellt werden sollen 

Drilldown der Dimensionen – Beim Verkehrsmittel kann vom allgemeinen 

Typ auf die genaue Instanz gewechselt werden, bei der Zeit 

kann von Jahresebene auf Quartalsebene gewechselt werden. 

Der Report ermöglicht über einen Link den schnellen Sprung zu Report 

SSRS6. 

Tabelle 3.13: Charakteristika des Reports „Reisekennzahlen nach Zeit & Verkehrsmittel“ 

Abbildung 3.14: Mockup des Reports „Reisekennzahlen nach Zeit & Verkehrsmittel“ 

83



SSRS6: Reisekennzahlen nach Zeit & Präferenz 

Tabelle 3.14 und Abbildung 3.15 beschreiben den Report „Reisekennzahlen nach Zeit & Präferenz“. 






Parameter 


Der Report schlüsselt ausgewählte Reisekennzahlen mithilfe der beiden 

Dimensionen Zeit und Präferenzen (des Anwenders, der die Reise unternommen 

hat) zweidimensional auf. Die Präferenzen Kosten, Komfort, 

Nachhaltigkeit und Zeit werden entsprechend ihrer Wertausprägungen 

in Gruppen eingeteilt. Die Zeitdimension ermöglicht ein Drilldown. 

Nutzer können mithilfe dieses Reports analysieren, ob und wie die Reisekennzahlen 

von den eingestellten Präferenzen der Endanwender abhängig 

sind. 




- M06 – Reisezeit 


Anwenderpräferenzen und Zeit 



Zeitraum, für welchen die Kennzahlen dargestellt werden sollen 

Drilldown der Dimension Zeit – Es kann von der Jahresebene auf die 

Quartalsebene gewechselt werden. Der Report ermöglicht über einen 

Link den schnellen Sprung zu Report SSRS5. 

Tabelle 3.14: Charakteristika des Reports „Reisekennzahlen nach Zeit & Präferenz“ 

Abbildung 3.15: Mockup des Reports „Reisekennzahlen nach Zeit & Präferenz“ 

84



QV1: Dashboard zur Plattformnutzung 






Parameter 


Das Dashboard gibt auf Jahres- und Monatsebene Auskunft über die 

Nutzung der Plattform Jinengo. Dem Jinengo-Management soll dieses 

Dashboard ermöglichen, die Entwicklung der wichtigsten Leistungskennzahlen 

der Plattform mittel- und langfristig im Blick zu behalten. 

Außerdem geben zwei graphische Skalen Auskunft über die kurzfristige 

Entwicklung der Plattform. 

J01 - Anzahl aktiver Endanwender 

M01 - Anzahl der Routen 

M10 - CO2-Emissionen pro Kilometer 

Zeit (Verlauf mehrere Jahre und der Monate eines gewählten Jahres) 

Relationales sowie multidimensionales Data Warehouse 

Über die entsprechende QlikView-Datei mittels QlikView selbst. 

Jahr, für das der Verlauf dargestellt werden soll 

Einkommensgruppe, für die der Verlauf dargestellt werden soll 

Wählen der abzubildenden Einkommensgruppe und des Jahres indem 

diese in den jeweiligen Diagrammen angeklickt wurden (Zeit in „Gewählte 

Routen“ und „CO 2 -Emissionen pro Kilometer“). Außerdem können 

über die Listen „Jahreseinkommen“ und „Familienstand“ die angezeigten 

Daten weiter eingeschränkt werden. Hierfür muss nur der gewünschte 

Wert in der Liste angeklickt werden. Sowohl Mehrfachauswahl, 

als auch die Kombination von Auswahlen in beiden Listen ist 

möglich. 

Tabelle 3.15: Charakteristika des Dashboards „Plattformnutzung“ 

Abbildung 3.16: Mockup des QlikView-Dashboards zur Plattformnutzung 

85



3.5.3 Self-Service BI für Management, Wissenschaftler & Mobilitätsanbieter 

Bei der Bereitstellung der Möglichkeiten zur Self-Service-BI für das Jinengo-Management geht es 

primär darum, den größtmöglichen Zugriff auf Informationen zu gewähren. Entgegen den Anforderungen 

bei vorgefertigten Dashboards und Reports, soll Self-Service BI dem Nutzer die Möglichkeit 

geben, selbst zu entscheiden, welche Daten er sich wie darstellen lassen möchte. Dabei sollen sich 

diese Wahlmöglichkeiten nicht nur auf die Veränderung von Parametern wie der zeitlichen Dimension 

der Daten beschränken. Er soll stattdessen aus den vorhandenen Daten des Systems frei wählen können. 

Je nach verwendeter Darstellungssoftware soll bei der Bereitstellung der Daten also darauf geachtet 

werden, dass diese möglichst untransfomiert und ungefiltert zur Verfügung stehen. Für Excel wird 

darum exemplarisch ein Cube zur Verfügung gestellt, während QlikView den vollen Zugriff auf die 

Daten des Data Warehouse erhält. Dabei hat QlikView nicht nur durch die Datenbasis die größeren 

Möglichkeiten der Darstellung. Auch im Bereich der Visualisierung weist QlikView einige Vorteile 

gegenüber Excel auf. QlikView wurde daher auch als Anwendung für die Erstellung eines Dashboards 

gewählt. In diesem Abschnitt soll der Fokus daher auf die Möglichkeiten von Excel gelegt werden. 

Excel bietet insbesondere die Möglichkeit zur Einbindung von multidimensionalen Daten (Cubes). Für 

diesen Bereich sollen mit Hilfe von Excel folgende Self-Service BI-Lösungen umgesetzt werden: 

 

 

 

MSEx1: Self-Service BI-Lösung für allgemeine Plattforminformationen 

MSEx2: Self-Service BI-Lösung für detaillierte Plattforminformationen 

MSEx3: Self-Service BI-Lösung für detaillierte Nachhaltigkeitsinformationen 

86



MSEx1: Self-Service BI-Lösung für allgemeine Plattforminformationen 

Inhalt & Zweck Angelehnt an das „Dashboard zur Plattformnutzung“ (vgl. Kap. 1.1) 

soll diese Übersicht einen ersten, aber dennoch detaillierten Einblick 

in die Nutzung der Plattform geben. 





Parameter 


J01- Anzahl aktiver Endanwender 

J02- Anzahl registrierter Endanwender 

J03- Anteil aktiver Endanwender 

M01- Anzahl der Routen 

M10- CO2-Emissionen pro Kilometer 

Zeit (in Jahren und Monaten (ja nach gewählter Software)) 

Analysis Service Cube 

Die erstellte Datei lässt sich über Microsoft Excel aufrufen. 

Zeit (Jahr, Monat) 

In den Diagrammen lassen sich über die Schaltflächen „Monat“ 

(rechts neben den Diagrammen) die angezeigten Daten nach Monaten 

selektieren. Außerdem kann man sich die 10 höchsten dargestellten 

Monate anzeigen lassen. Dies funktioniert in allen Diagrammen deren 

Dimension eine zeitliche ist. 

Tabelle 3.16: Charakteristika zur Self-Service-BI-Lösung für allgemeine Plattforminformationen 

Abbildung 3.17: Mockup zur Self-Service-BI-Lösung für allgemeine Plattforminformationen 

87



MSEx2: Self-Service BI-Lösung für detaillierte Plattforminformationen 






Parameter 


In dieser Lösung sollen dem Betrachter detaillierte Informationen zur 

Plattformnutzung gegeben werden. Dabei sind hier insbesondere die 

die Vielzahl an variablen Dimensionen wichtig um die Daten nicht 

nur in der Gesamtheit betrachten zu können, sondern gezielt und anforderungsspezifische 

Eingrenzungen vorzunehmen. 

J01 – Anzahl aktiver Endanwender 

J02 – Anzahl registrierter Endanwender 

M01– Anzahl der Routen 

M02 – Anzahl der Subrouten 

Zeit, Verkehrsmittel, Reisezweck, Einkommen des Nutzers 



Excel: Zeit (Jahr, Monat) 

QlikView: Verkehrsmittel, Reisezweck und Einkommensbereich 

In den Diagrammen lassen sich über die Schaltflächen „Monat“ 

(rechts neben den Diagrammen) die angezeigten Daten nach Monaten 

selektieren. Außerdem kann man sich die 10 höchsten dargestellten 

Monate anzeigen lassen. Dies funktioniert in allen Diagrammen deren 

Dimension eine zeitliche ist. 

Mit QlikView wäre es außerdem möglich die Auswahl nach Verkehrsmittel, 

Reisezweck oder Einkommensbereich des Nutzers einzuschränken. 

Tabelle 3.17: Charakteristika zur Self-Service-BI-Lösung für detaillierte Plattforminformationen 

Abbildung 3.18: Mockup zur Self-Service BI-Lösung für detaillierte Plattforminformationen 

88



MSEx3: Self-Service BI-Lösung für detaillierte Nachhaltigkeitsinformationen 






Parameter 


In dieser Lösung sollen dem Betrachter detaillierte Informationen zur 

Plattformnutzung gegeben werden. Dabei sind hier insbesondere die 

Vielzahl an variablen Dimensionen wichtig um die Daten nicht nur in 

der Gesamtheit betrachten zu können, sondern gezielt und anforderungsspezifische 

Eingrenzungen vorzunehmen. 

M10- CO 2 -Emissionen pro Kilometer 

Zeit, Verkehrsmittel, Einkommensgruppen, Personencluster 



Zeit (Monat, Jahr), Verkehrsmittel, Einkommensgruppe, Personencluster 

In den Diagrammen lassen sich über die enthaltenen Schaltflächen 

(weiter eingrenzen. 

Mit QlikView wäre es außerdem möglich die Auswahl nach Verkehrsmittel, 

Reisezweck oder Einkommensbereich auf alle angezeigten 

Diagramme anzuwenden. 

Tabelle 3.18: Charakteristika zur Self-Service-BI-Lösung für detaillierte Nachhaltigkeitsinformationen 

Abbildung 3.19: Mockup zur Self-Service BI-Lösung für detaillierte Nachhaltigkeitsinformationen 

89



4. Realisierung 

4.1 Datengenerator 

Bei der bisherigen Umsetzung der Plattform Jinengo handelt es sich um eine Software, die bislang 

noch nicht im operativen Betrieb eingesetzt wurde. Aufgrund der bislang unzureichenden Nutzung der 

Plattform sind derzeit nicht genügend reale Daten verfügbar. Ein Kernbestandteil dieses BI-Projekts 

ist jedoch die Analyse und Visualisierung von Daten. Eine hinreichend große Datenmenge soll daher 

mithilfe eines Datengenerators künstlich geschaffen werden. Ziel des Generators ist es, auf Basis von 

künstlich angelegten Endanwender und der vorhandenen Jinengo-Schnittstelle 14 Routendaten zu generieren. 

Primäres Augenmerk bei der Datengenerierung liegt auf der Schaffung einer Datenbasis mit 

gewissen „plausiblen“ Mustern, die nachträglich z.B. im Rahmen des Data Mining erkannt werden 

sollen. 

In Tabelle 4.1 sind die Datenarten, ihre Erstellungsreihenfolge, die dazu genutzte Technologie, sowie 

die davon betroffenen Entitäten übersichtlich aufgeführt. Ein Schwerpunkt liegt dabei auf den Mobilitätsdaten 

(Bewegungsdaten). Die Stammdaten werden hingegen lediglich einmalig zu Beginn eingespielt. 

Die Einspielung der Geokoordinaten sowie der Freundschaften geschieht nach Bedarf manuell. 

da diese Anforderungen erst nachträglich hinzukamen und im Falle der Geokoordinaten die Google- 

Maps-API zudem bezüglich der Anfragen limitiert ist. 

Reihenfolge 

Klassifikation Entitäten Technologie 

1 Stammdaten JinengoUser, FamilyStatus, IncomeRange, 

Preferences, RailMembership, Car- 

SharingMembership, Need, Transportation 

und TransportationType 

2 Mobilitätsdaten 

(Bewegungsdaten) 

Route, Subroute 

TSQL 

3 Geokoordinaten Route TSQL 

4 Freundschaften JinengoUserFriend TSQL 

Tabelle 4.1: Im Datengenerator unterschiedene Datenarten 

Java 

14 Die REST-API von Jinengo ist funktional und liefert für gegebene Start- und Zielpunkte eine Menge von Reisealternativen. 

90



4.1.1 Stammdaten 

Die Stammdaten bilden die Grundlage der operativen Datenbank. Die entsprechenden Daten sollen 

daher über ein TSQL-Skript einmalig in die Datenbank eingespielt werden. 

Zunächst müssen die essentiellen Stammdatentabellen gefüllt werden, die als Referenz für verschiedene 

Wertelisten dienen. Dazu zählen die folgenden Tabellen: 

Familienstand (FamilyStatus) – Ausprägungen „ledig“, „verheiratet“, „geschieden“, „verwitwert“ 

Bahncard-Mitgliedschaft (RailMembership) – Ausprägungen „keine“ sowie „BC25“, „BC50“ 

und „BC100“ (jeweils erste und zweite Klasse) 

Einkommen (IncomeRange) – Ausprägungen „0 – 20.000”, „20.000 – 40.000”, „40.000 – 

70.000”, „70.000 – 100.000”, „100.000 – 200.000” sowie „200.000 und mehr” (jeweils EUR) 

Verkehrsmittel und übergeordneter Verkehrsmitteltyp: 

o „Human Powered“ – Ausprägungen „zu Fuß“, „konventionelles Fahrrad“ & „E-Bike“ 

o „PKW-Privat“ – Ausprägungen „Klein-„, „Mittelklasse-„ und „Oberklassewagen“ 

sowie „Elektroauto“ 

o „Car Sharing“ – Ausprägungen „Flinkster“, „Cambio“, „Car2Go“ & „BMW iDrive” 

o “ÖPNV” – Ausprägungen „Bus”, „Oberleitungsbus” & „Straßenbahn” 

o „Fernverkehr“ – Ausprägungen „RE“, „REx“, „ME“, „MEr“, „NWB“, „IC“ & „ICE“ 

Von besonderer Bedeutung sind die fiktiven Endanwender in der Tabelle JinengoUser. Um halbwegs 

plausible Muster in den Daten bezüglich Familienstand, Einkommen, Bahncard-Mitgliedschaft sowie 

verfügbare Verkehrsmittel zu erhalten, stehen die einzelnen persönlichen Anwenderattribute in Beziehung 

zueinander. Tabelle 4.2 stellt die gegenseitigen Abhängigkeiten detailliert dar 15 . Auch die Präferenzen 

der Endanwender (Tabelle Preferences) werden analog in Abhängigkeit der Endanwenderattribute 

bestimmt. 

Nach der Generierung der Präferenzen sollen die Endanwenderattribute vereinzelt dann wieder auf 

NULL gesetzt werden, um unvollständige Angaben (z.B. aus Datenschutzbedenken) zu simulieren. 

15 Attribute ohne besondere Relevanz, die lediglich der Vollständigkeit halber aufgeführt werden, sind unabhängig 

von den anderen Attributen. So ist zum Beispiel die Adresse aller Endanwender dieselbe, da diese in den 

späteren exemplarischen Anwendungsfeldern keine Rolle spielt. Entsprechende Attribute werden daher in der 

Tabelle 4.2 auch nicht aufgeführt. 

91



Die Wahrscheinlichkeit einer Zurücksetzung der Daten korreliert dabei mit der Sensibilität der Information 

und ist daher beim Einkommen am höchsten. 

Attribut Abhängig von Erklärung 

name gender In Abhängigkeit vom vergebenen Geschlecht des zu erstellenden 

Endanwenders wird einer von 10 männlichen oder 

weiblichen Namen gewählt. 

incomeRangeID - Das Einkommen wird den Anwendern über eine Zufallszahl 

zugewiesen. Dabei ist die Wahrscheinlichkeit für ein niedriges 

bis mittleres Einkommen höher, als für ein hohes Einkommen. 

familyStatusID incomeRangeID Der Familienstand eines Anwenders wird vom Einkommen 

beeinflusst. Hinzu kommt ein Verrauschungsfaktor in Form 

einer Zufallszahl, welche dafür sorgt, dass nicht jeder Endanwender 

mit einem guten Einkommen eine Familie hat. 

ownsPEV incomeRangeID Umso höher das Einkommen eines Anwenders umso größer 

ist die Wahrscheinlichkeit, dass er ein Plug-In Electric Vehicle 

(PEV) besitzt. Die Wahrscheinlichkeit für diesen Fall 

ist dennoch sehr gering gehalten. 

ownsGasCar incomeRangeID Umso höher das Einkommen eines Anwenders umso größer 

ist die Wahrscheinlichkeit, dass er ein Auto besitzt. Die 

Wahrscheinlichkeit für diesen Fall ist deutlich höher als für 

den Besitz des PEV. 

ownsEBike - Der Besitz eines eBikes wird über eine Zufallszahl bestimmt. 

Da eBikes heut zu Tage noch nicht sonderlich verbreitet 

sind, liegt die Wahrscheinlichkeit für diesen Fall bei 

20%. 

publicTransport- 

Member 

railMembership 

maxDistance- 

ToWalk 

- Hier wird dem Anwender ein rein zufälliger Wert zugewiesen. 

maxDistance- 

ToBike 

ownsGasCar, 

ownsPEV, 

ownsEBike 

incomeRangeID, 

ownsGasCar 

In Abhängigkeit von den Fahrzeugen, die der modellierte 

Anwender besitzt wird Ihm eine Monatskarte zugeteilt. 

Dabei erhöhen der Besitzt von PEV und eBike die Wahrscheinlichkeit, 

während der Besitz eines Autos die Wahrscheinlichkeit 

verringert. 

Das Einkommen beeinflusst ob und welche Bahncard der 

Anwender hat. Desto Wahrscheinlicher ist es, dass der Endanwender 

eine teurere Bahncard besitzt. Außerdem erhöht 

sich die Wahrscheinlichkeit für eine Bahncard 100, wenn 

die abgebildete Person kein Auto besitzt. 

ownsEBike 

Im ersten Schritt erhält der Endanwender eine rein zufällig 

gewählte Zahl für diese Eigenschaft. Anschließend wird 

allerdings überprüft ob der Anwender ein eBike besitzt. 

Sollte dies der Fall sein, wird seine minimale Distanz auf 10 

Kilometer gesetzt. 

Tabelle 4.2: Erläuterung der Attribut-Abhängigkeiten 

92



Mobilitätsdaten (Bewegungsdaten) 

Das Ziel der möglichst realistischen Generierung von unterschiedlichen Routendaten soll mit Hilfe 

eines mehrstufigen Java-Programms umgesetzt werden. Die einzelnen Stufen der Datenerzeugung 

werden dabei anhand des Sequenzdiagrammes in Abbildung 4.1 dargestellt. Dies dient dem besseren 

Verständnis der Zusammenhänge und der Interaktion der einzelnen Komponenten. 

Als Grundlage für die Generierung der Routendaten werden die zuvor angelegten Anwenderdaten 

verwendet. Dabei gliedert sich der Ablauf in fünf wesentliche Schritte, die in Tabelle 4.3 mit samt 

ihrer zugehörigen Methode aufgeführt sind. 

Schritte 

beteiligte Programmkomponenten 

1. Anwenderliste generieren Hauptcontroller, Anwendermodellierer 

2. Routenmodell anlegen Routencontroller, Routenmodellierer 

3. Berechnung der ergänzenden Eigenschaften 

Routenerweiterer 

4. Validierung der Routen Routenvaliderer 

5. Auswahl der Route Routenentscheider 

1. Anwenderliste generieren 

Tabelle 4.3: Zuordnung der Arbeitspakete zu den Programmkomponenten 

Zuerst werden für jeden Anwender die Daten aus der Tabelle JinengoUser der operativen Datenbank 

geladen. Diese Daten werden im selben Schritt in ein Java-Modell übertragen. Die Eigenschaften des 

Java-Anwender-Modells entsprechen dabei in etwa denen der Endanwendertabelle aus der operativen 

Datenbank. Auf Eigenschaften, welche die Routenwahl nicht beeinflussen, wird hingegen verzichtet. 

Abgebildet wurden in dem Modell: Identifikationsnummer, Einkommen, Familienstand, Auskunft 

über den Besitzt eines Elektroautos (PEV), Auskunft über den Besitz eines Autos, Auskunft über eine 

CarSharing-Mitgliedschaft, Auskunft über den Besitz eines E-Bike, Auskunft über den Besitz einer 

Monatskarte, Auskunft zur Wegstrecke die der Anwender zu Fuß zurücklegen würde, Auskunft zur 

Wegstrecke die der Anwender mit dem Fahrrad zurücklegen würde sowie die Präferenzen. 

All diese Informationen werden zur Routenvalidierung und zur Routenauswahl benötigt um eine möglichste 

realistische Auswahl für den jeweiligen fiktiven Anwender treffen zu können. Nachdem die 

Daten zu jedem Anwender an das Java-Programm übergeben wurden und alle Anwender in einer Liste 

gespeichert wurden, wird diese Liste nun schrittweise durchgearbeitet um für jeden Endanwender 

Routendaten zu generieren. 

93



2. Routenmodell anlegen 

Im zweiten Schritt wird für den erstellten Anwender ein Start- und Zielort aus einer separat hinterlegten 

Datei gewählt. Die Anwendung hat darauf zu achten, dass sich Start- und Zielort unterscheiden. 

Mit diesen Orten als Eigenschaften, soll eine Routenanfrage an die Jinengo-Schnittstelle (REST-API) 

gestellt werden. 

Die Routen- und Subrouten-Ergebnisse der Abfrage werden anschließend in zwei Java-Modellen abgelegt. 

Dabei enthält jedes Routenmodel zusätzlich zu den Eigenschaften eine Liste, welche auf die 

zugehörigen Subrouten verweist. Die Eigenschaften beider Modelle sollen hierbei denen der entsprechenden 

Datenbanktabellen (Anhang a) gleichen. 

3. Berechnung der ergänzenden Eigenschaften 

Die Datengrundlage, welche die Jinengo-Schnittstelle für die Routen per REST-API liefert ist für die 

definierten Anforderungen nicht ausreichend und muss daher durch den Routengenerator ergänzt werden. 

Hierfür wird ein Modul entwickelt, welches die Routen und Subrouten um benötigte Eigenschaften 

erweitert. 

Dabei werden die Routen um die Eigenschaften aus Tabelle 4.4 erweitert. Da die REST-API von 

Jinengo zudem nur drei verschiedene Verkehrsmittel zurückgibt, werden die Subrouten zudem zufällig 

den zuvor angelegten Verkehrsmitteln (insgesamt 21) zugeordnet. Dabei wirkt sich jedoch das Einkommen 

auf die Entscheidung aus. Einkommensstärkere Personen tendieren daher eher zu Oberklassewagen 

und ICE als Kleinwagen und NWB. 

94



Eigenschaft Attribut Berechnung 

ID ID Für jede Route wird eine eindeutige Routen- 

ID berechnet. Dies entspricht der maximalen 

Routen-ID in der Datenbank + 1. 

Start- und Zielort 

sowie -zeit 

departureAdress, 

destinationAdress, 

departureTime, 

destinationTime 

Die Jinengo REST-API liefert Start und 

Zielort nur auf Subrouten-Ebene. Diese Eigenschaften 

werden auch auf die übergeordnete 

Gesamtroute übertragen. Gleiches gilt 

für die Start- und Endzeit der Reise. 

Gepäck luggage Mit 25% Wahrscheinlichkeit hat der Endanwender 

Gepäck dabei. Bei verheirateten 

Personen steigt die Wahrscheinlichkeit auf 

50%. 

Anzahl der Reisenden passengers 25% der Fahrten werden von Gruppen getätigt. 

Außerdem gelten verheiratete Personen 

als Familien. Gruppen und Familien fahren 

tendenziell mit mehr Personen (1-6). 


(im Vergleich zur 

besten und schlechtesten 

Routenalternative) 

Zeit 




Nutzbare Zeit 




Gesamtkosten 




ecoImpactAdvantage, 

ecoImpactDisadvantage 

timeAdvantage, 

timeDisadvantage 

effectiveTimeAdvantage, 

effectiveTimeDisadvantage 

costsAdvantage, 

costsDisadvantage 

Die einzelnen EcoImpact Werte der Subrouten 

werden aufaddiert und abschließend im 

Verhältnis zur besten und schlechtesten Variante 

als Vor- und Nachteil in der Datenbank 

gespeichert. 

Die Zeiten der Subrouten werden zusammengerechnet 

und daraus werden später 

Vor- und Nachteile im Vergleich zu den 

anderen Routenalternativen gebildet und 

gespeichert. 

Sollte eine oder mehrere Subrouten mit dem 

Zug zurückgelegt werden, wird diese Nutzbare 

Zeit aggregiert auf Routenebene gespeichert 

und für die weitere Nutzung in 

Vor- und Nachteil gegenüber den nicht gewählten 

Routen gewandelt. 

Die Gesamtkosten der Reise werden abhängig 

von den Subroutenkosten neu berechnet, 

da sich durch Bahn Card die Kosten für 

Zugfahrten senken können Abschließend 

werden diese Kosten in Vor- und Nachteile, 

also in Abhängigkeit von der schlechtest 

möglichen und bestmöglichen Option gespeichert. 

Tabelle 4.4: Erläuterung der Berechnung für die Routeneigenschaften 

95



4. Validierung der Routen 

Die erweiterten Routen müssen im Anschluss auf ihre Realisierbarkeit hin validiert werden. So sollte 

beispielweise geprüft werden: 

 

 

Ist die Strecke zu Fuß oder mit dem Fahrrad mit der maximalen Entfernung, die ein Anwender 

zu fahren bzw. laufen bereit ist, vereinbar? 

Besitzt der Endanwender das benötigte Verkehrsmittel? 

Dafür wird die Liste mit Routenalternativen durch den Routenvalidierer überprüft. Sollte sich bei der 

Validierung eine Route als nicht realisierbar herausstellen, wird diese aus der Liste der potentiellen 

Routenalternativen entfernt. 

5. Auswahl der Route 

Ausgehend von der validierten und um spezifische Eigenschaften erweiterten Routenliste muss die 

Anwendung (bzw. der Endanwender) sich für eine Routenalternative entscheiden. Diese Entscheidung 

sollte von einer Reihe von Faktoren abhängig sein. 

Zu Grunde wird die Annahme gelegt, dass sich ein Anwender mit einer Wahrscheinlichkeit von 75% 

für eine Route entscheidet, die seinen Präferenzgewichtungen entspricht. Die Gewichtung entspricht 

einem Zahlenwert zwischen 0 (=unwichtig) und 1 (=wichtig). 

Im ersten Schritt sollen die für den Endanwender wichtigsten Präferenzen ermittelt werden. Hiervon 

ausgehend kann im zweiten Schritt eine Sortierung der validen Routen erfolgen und die am besten 

geeignete Route gewählt werden. Bei den Präferenzen handelt es sich um die persönliche Gewichtung 

der folgenden vier Aspekte: Komfort, Nachhaltigkeit, Zeit und Kosten. 

Um für eine realistische Streuung in den gespeicherten Routendaten zu sorgen wählt der Routenentscheider 

in 25% der Fäll eine zufällige Route. Schließlich können unvorhersehbare Faktoren in der 

Realität einen Anwender ebenfalls so beeinflussen, dass dieser nicht die ansonsten präferierte Route 

wählen würde. 

Abschließend wird die gewählte Route mit ihren Subrouten in die operative Datenbank geschrieben. 

96



Abbildung 4.1: Sequenzdiagramm des Datengenerators 

4.2 Reporting-API (Webservice) 

Ziel des Webservice ist es, eine leichtgewichtige Schnittstelle zu schaffen, die Anwendungen den Zugriff 

auf definierte Datensätze aus dem Data Warehouse ermöglicht. 

Der Webservice bietet den Vorteil, dass eine Anwendung nicht den direkten Zugriff auf das Data Warehouse 

erhält, sondern alle Abfragen über eine Schnittstelle gekapselt werden. Die Entscheidung welche 

Daten welchen Anwendungen verfügbar gemacht werden liegt damit beim Webservice. Dieser 

verfügt über einen Rollen- und Authentifizierungsmechanismus. Ein weiteres Ziel ist es, dass hierdurch 

die Webanwendungen vom Microsoft SQL Server entkoppelt werden und dieser so leichter 

angepasst oder ausgetauscht werden kann. 

Neben dem Aspekt der Entkopplung und der erhöhten Sicherheit erleichtert die Schnittstelle zudem 

den Datenzugriff für Reporting-Anwendungen, da nur relevante und für das Reporting optimierte Daten 

über den Webservice ausgeliefert werden. 

Zur flexiblen und plattformunabhängigen Darstellung der Nutzerdaten und Analyseergebnisse müssen 

die Daten vom Webservice über ein festgelegtes und an die Anforderungen angepasstes Format gelie- 

97



fert werden. Als Format zum Datenaustausch wird sich für die JavaScript Object Notation (JSON) 

entschieden. 

Anmerkung: Die ausführliche Begründung einzelner Technologieentscheidungen findet sich in der 

Dokumentation im Kapitel „Begründung eingesetzter Webtechnologien“. 

Die Datenabfrage über den Webservice soll möglichst leichtgewichtig sein, so dass Frontend- 

Anwendungen ohne größeren Implementationsaufwand den Webservice zur Darstellung von Daten 

nutzen können. Dies erleichtert nicht nur die eigene Anwendungsentwicklung, sondern liefert auch ein 

Werkzeug, um die Daten potentiellen Drittanbietern zugänglich zu machen. 

Die Schnittstelle soll hierfür gemäß dem RESTful-Prinzip implementiert werden (REST-API). Diese 

Art der Implementierung bietet eine Reihe von Vorteilen und erfüllt die Anforderungen die im Rahmen 

des Projektes an die Schnittstelle gestellt werden. 

Ein weiteres Ziel bei der Entwicklung des Webservices soll die Verwendung von Standards sein. Dies 

erhöht die Stabilität und fördert die zukünftige Erweiter- und Wiederverwendbarkeit der Anwendung. 

Softwareentwicklung 

Für die Realisierung des Webservices wird sich für Java als Programmiersprache und Spring 16 als 

Framework entschieden. Bei Spring handelt es sich um ein weit verbreitetes Framework, mit dem 

bereits eine Vielzahl von Enterprise-Anwendungen entwickelt wurden. Besonders in Hinblick auf 

Sicherheit, Geschwindigkeit und Wiederverwendbarkeit hat das Framework seine Stärken. Eine standardisierte 

Struktur erleichtert zudem neuen Entwicklern die Einarbeitung in das Projekt. Für die Anforderung 

der REST-Schnittstelle bietet Spring das MVC-Modul an, welches sich genau an die Bedürfnisse 

des Projektes anpassen lässt. 

16 Für weitere Informationen siehe: http://www.springsource.org/ 

98



Aufbau der Anwendung 

Für den Webservice müssen vor allem drei Arten von Java-Objekten entwickelt werden: Controller-, 

Model- und Service-Klassen. Die Controller ordnen eine eingehende Ressourcen-Anfrage eindeutig 

einem Datenmodell zu. Die Datenmodelle werden dabei ebenfalls in Java implementiert und bilden die 

in der Datenbank angelegten Tabellen für Kennzahlen und Nutzereigenschaften in der Anwendung ab. 

Die Service-Klassen regeln den Zugriff auf die Datenbank und füllen ein angefragtes Model mit Daten. 

Das nachfolgende Sequenzdiagramm (Abbildung 4.2) gibt einen Überblick, wie der Webservice 

auf eine Anfrage einer Anwendung reagiert und welche Klassen beteiligt sind. 

Abbildung 4.2: Sequenzdiagramm Reporting-API 

Eingehende API-Anfragen werden von einem allgemeinen Servlet Controller an einen spezifischen 

API-Controller weitergeleitet. Dieser delegiert die Datenabfrage an die entsprechenden Service- 

Klassen, die das passende Model durch eine Abfrage an die Datenbank füllen. Das Model wird dann 

an den API-Controller zurückgegen, in das JSON-Format umgewandelt und an die anfragende Anwendung 

ausgeliefert. 

99



Schnittstellenspezifikation 

Aufgrund der Anforderungen für das Endanwender Reporting gilt es folgende REST-Schnittstellen 

durch den Webservice zu realisieren- 

URI Parameter Rückgabewert (JSON-Array) 

/api/user/figures 

/api/user/averages 

keyFigure – Betrachtete Kennzahl 

year – Jahreszeitraum 

friendId – Anwender- ID eines 

Freundes 



friendId – Anwender-ID eines 

Freundes 

/api/user/transportation keyFigure – Betrachtete Kennzahl 


month – Monatszeitraum 

friendId – Anwender-ID eines 

Freundes 

Tabelle 4.5: Allgemeine Schnittstellenspezifikation Webservice 

Die betrachtete Kennzahl für ein gegebenes 

Jahr auf Monatsbasis summiert. 

Bei Angabe der friendId werden die 

Kennzahlen auf einen Freund, ansonsten 

auf den eingeloggten Anwender 

bezogen 

Die betrachtete Kennzahl für ein gegebenes 

Jahr auf Monatsbasis als Durchschnittswert. 




bezogen. 

Die betrachtete Kennzahl anteilig je 

Verkehrsmittel. Aggregiert auf Jahres 

oder Monatsbasis. 




bezogen. 

Die Tabelle 4.5 stellt die allgemeinen Anforderungen an die Schnittstelle für Anwenderdaten dar. Diese 

Spezifikation lässt sich äquivalent auf die Abfrage von Kennzahlen bezogen auf den Plattformdurchschnitt 

übertragen. Zur Abfrage der Plattform Daten muss der URI-Prefix von „/api/user“ auf 

„/api/plattform“ geändert werden. 

Neben den allgemeinen Kennzahlen, die sowohl für den Anwender, als auch für die gesamte Plattform 

Gültigkeit haben, gibt es eine Reihe an nutzerspezifischen Anforderungen an die Schnittstelle: 

100



URI Parameter Rückgabewert 

/api/user/balance 



friendId – Nutzer ID eines Freundes 

Die betrachtete Kennzahl, deren Maximum 

und Minimum für ein gegebenes 

Jahr auf Monatsbasis summiert. 



auf den eingeloggten Nutzer bezogen 

/api/user/details keine Liefert Details des aktuell eingeloggten 

Nutzers. Hierzu zählen Nutzer-ID, E- 

Mail, Name, Geschlecht, Registrierungszeitpunkt, 

Geburtsdatum. 

/api/user/friends keine Liefert eine detaillierte Liste aller 

Freunde des aktuell eingeloggten Nutzers. 

Die Details beinhalten mindestens 

Namen, E-Mail und Nutzer-ID des 

Freundes. 

Tabelle 4.6: Nutzerspezifische Schnittstellenspezifikation Webservice 

Entwicklungsinfrastruktur 

Um den Webservice zu betreiben und entwickeln sind neben Java und Spring folgenden Infrastruktur- 

Komponenten zu nutzen: 

Webserver 

Build Tool 

Revisionskontrolle 

Die Anwendung soll in einem Apache Tomcat Webserver laufen. Hierbei 

handelt es sich um einen leicht konfigurierbaren, stabil laufenden und 

weit verbreiteten Server. 

Zum Bauen der Anwendung wird sich für Maven entschieden. 

Es wird sich für Git als Revisionskontrolle entschieden. 

Entwicklungsumgebung Das Team nutzt zur besseren Unterstützung der Softwareentwicklung mit 

Java und der verwendeten Frameworks die STS Entwicklungsumgebung. 

Alternative kann auch Eclipse als Umgebung empfohlen werden. 

VPN 

Authentifizierung 

Aus Sicherheitsgründen ist der Zugriff auf die Datenbank nur aus dem 

Netzwerk der Uni Oldenburg oder über eine gesicherte VPN Verbindung 

zur Uni Oldenburg möglich (vpn.uni-oldenburg.de). 

Tabelle 4.7: Entwicklungsinfrastruktur 

Da der Webservice sensible, personengebundene Daten liefert, muss sich ein Anwender vor der Nutzung 

eindeutig authentifizieren. Anwender sollen sich dabei mit ihrer eindeutigen E-Mail-Adresse 

beim Webservice anmelden können. Das zugehörige Passwort soll vom Anwender selbst festgelegt 

und im Anschluss verschlüsselt in einer Datenbank hinterlegt werden. Die Verschlüsselung erfolgt 

über die in Spring implementierte Hashfunktionen der SHA-2-Familie (SHA-224). Der Algorithmus 

101



garantiert, dass selbst bei unbefugten Zugriffen auf die Datenbank, dass Passwort des Anwender nicht 

rückwirkend in Klartext entschlüsselt werden kann. 

Ein Rollenmanagement legt fest, welche Bereiche des Webservice von einem Account genutzt werden 

können. Hierdurch wird es auch möglich, den Webservice externen Dienstleistern bereitzustellen, da 

der Datenzugriff fein granular gesteuert werden kann. Jeder URI des Webservices werden hierzu Rollen 

zugeordnet und nur authentifizierte Anwender mit passender Rolle erhalten den Zugriff auf die 

Daten. 

4.3 Reporting-Frontend für Endanwender 

Das Reporting Frontend für Endanwender realisiert eine interaktive Weboberfläche über welche Anwender 

Informationen zu ihrem Fahrverhalten erhalten können. Hierbei werden die Informationen in 

Form von anschaulichen Charts, Kuchendiagrammen und Tachos dargestellt. Die gesamte Anwendung 

basiert auf Webstandards und nutzt als Datengrundlage den Webservice der Reporting-API. Durch das 

asynchrone Laden der Daten sollen Wartezeiten verkürzt und dem Anwender ein besonders interaktives 

Erlebnis geboten werden. 

Das Reporting-Frontend wird als Single-Page-Anwendung implementiert. Ein HTML-Dokument gibt 

das Anwendungsgerüst vor. Dieses wird mit Hilfe von CSS gestaltet und über JavaScript dynamisch 

mit Inhalt gefüllt. 

Datenabfrage 

Die Datenübertragung zwischen Webservice und Reporting-Interface erfolgt ausschließlich frontendseitig 

mittels Ajax-Anfragen. Dies bietet den großen Vorteil, dass für die Darstellung der Charts kaum 

Backend-Technologien benötigt werden und die Charts mit geringem Aufwand prinzipiell auf jeder 

Webseite integriert werden können. 

HTML-Gerüst 

Die HTML-Seite bildet beim Webinterface nur ein grobes Grundgerüst und wird in das Spring- 

Framework der Reporting-API integriert und durch dieses ausgeliefert. Das eigentliche Zeichnen der 

Charts, sowie das Hinzufügen von dynamischen Inhalten, wie Anwendername und Freundeslisten, 

erfolgt asynchron und clientseitig über JavaScript. Der Großteil der Anwendung wird daher in JavaScript 

realisiert. 

102



Charts 

Für das Zeichnen der Charts wird sich für den SVG-Standard entschieden. Mit Hilfe der JavaScript- 

Bibliothek „Highcharts“ 17 und selbst entwickelten Modulen sollen die Charts in dem Grafikformat 

SVG live im Browser gezeichnet werden. 

Navigationsmenü 

Das Navigationsmenü soll gemäß den Anforderungen in HTML und CSS gestaltet werden. Dabei wird 

versucht auf Grafiken verzichten und das Menü weitestgehend mit modernen CSS3 Techniken zu gestalten, 

um die Performance der Anwendung zu verbessern. Das Untermenü soll sich dabei bei Mouse- 

Over öffnen und animiert auffahren. Sobald eine Chart-Variante gewählt wird, soll der entsprechende 

Chart gezeichnet und das Untermenü wieder geschlossen werden. 

JavaScript-Anwendung 

Zur besseren Übersicht wir der Aufbau der JavaScript-Anwendung in Abbildung 4.3 dargestellt. Die 

grau eingefärbten Module entsprechen JavaScript-Klassen. 

Abbildung 4.3: Sequenzdiagramm Reporting-Frontend 

Zu Beginn erfragt das Hauptmodul Anwender- und Freundesdaten vom Webservice und nutzt diese, 

um die Webseite mit der Freundesliste und einem individuellen Begrüßungstext zu initialisieren. 

Die Interaktion zwischen Nutzer und Anwendung wird ebenfalls über das Hauptmodul realisiert. Es 

erstellt Event-Listener, welche in der Lage sind auf Klick-Ereignisse des Nutzers zu reagieren. Jedem 

17 Für weitere Informationen siehe: http://www.highcharts.com 

103



Button im Navigationsmenü werden dazu ein Listener sowie eine eindeutige Chartdarstellung zugeordnet. 

Nach dem Auslösen eines Events ist das Chartmodul dafür verantwortlich die benötigten Daten vom 

Webservice über einen Ajax-Request abzufragen. Bei erfolgreicher Abfrage werden die Daten an den 

Charthandler weitergegeben. Dieser bereitet je nach Anfrage die Daten spezifisch auf und zeichnet den 

Chart im Browser des Nutzers. 

104



4.4 Programmierrichtlinien 

Programmierrichtlinien tragen maßgeblich dazu bei, den Code lesbarer und weniger fehleranfällig zu 

gestalten. Zudem erleichtern einheitliche Richtlinien die Einarbeitung neuer Entwickler und sind daher 

bei der Arbeit in Teams wichtiger Bestandteil der Softwareentwicklung. Die wichtigsten Richtlinien 

sollen nachfolgend tabellarisch aufgeführt werden: 

Richtlinie 

Englisch als Entwicklungssprache 

Dokumentation 

Bezeichner 

Globale Variablen 

Modularisierung 

Kodierung 

Repository 

Formatierung 

Beschreibung 

Sowohl für Funktions-, Klassen- und Variablennamen, als auch 

für die Inline-Dokumentation wird durchgehend die englische 

Sprache verwendet. 

Jede Funktion und Klasse wird mit einer kurzen Dokumentation 

zu versehen. Dazu gehört neben einer kurzen Beschreibung 

auch die Auflistung der Übergabeparameter und Rückgabewerte. 

Klassen sind zudem mit dem jeweiligen Autor zu kennzeichnen. 

Klassen-, Funktions- und Variablennamen sind, sobald sie aus 

mehreren Wörtern bestehen in der „CamelCase“-Notation zu 

schreiben. Hierbei beginnt jedes Folgewort mit einem Großbuchstaben 

gefolgt von Kleibuchstaben. Beispiel: getUserData(). 

Funktionen und lokale Variablen beginnen dabei immer 

mit Kleinbuchstaben, Klassen mit Großbuchstaben. Die jeweiligen 

Namen sind dabei so sprechend wir möglich zu wählen, 

um die Verständlichkeit des Codes zu erhöhen. 

Generell gilt es die Verwendung von globalen Variablen zu 

verhindern und auf ein Minimum zu reduzieren. 

Die Entwicklung soll so modular wie möglich erfolgen. Dies 

bedeutet vor allem kurze, übersichtliche Klassen und Methoden 

die möglichst wenig indirekte Abhängigkeit zueinander besitzen. 

Es wird UTF-8 als einheitlicher Standard zur Zeichencodierung 

genutzt und auf allen Entwicklungsumgebungen als Standardwert 

eingestellt. 

Jeder Entwickler hat das gemeinsame Git-Repository zu nutzen 

und alle Änderungen am Quellcode noch am gleichen Tag in 

das Repository zu laden. Zudem ist bei jedem Hochladen ein 

kurzer Kommentar, der die Änderungen beschreibt, zu verfassen. 

Es gilt den Code einheitlich zu formatieren. Hierzu zählt insbesondere 

eine einheitliche Einrückung und Klammerung des 

Codes. Entwickler die später in das Projekt einsteigen haben 

sich an bestehende Konventionen zu halten. 

Tabelle 4.8: Programmierrichtlinien 

105




Explain Extended (2009): Selecting friends. URL: http://explainextended.com/2009/03/07/selectingfriends, 

(Zugriff am: 22.03.2013). 

Huang, X. & Kölpin, S. & Mahnke, C.; Temgoua, A. M. N. & Petersen, M. & Rummel, D. & Schnieders 

D. & Spennemann, A. & Stamer, D. & Dovenmühle, T. v.d. & Wei, Y. (2011): Sustainable CRM 

für E-Mobility Services mit SOA. Projektgruppendokumentation. Universität Oldenburg. 

Katibah, E. & Stojic, M. (2011): New Spatial Features in SQL Server Code-Named “Denali”. SQL 

Server Technical Article. URL: http://go.microsoft.com/fwlink/?LinkId=226407, (Zugriff am: 

22.03.2013). 

106



Anhang 

A. Tabellen der operativen Datenbank 

Tabelle: JinengoUser 

Attribut Beschreibung & ggf. Einheit Datenformat 

ID (PS) 

Eine ganzzahlige Identifikationsnummer, die den jeweiligen 

Nutzer repräsentiert. 

BigInt 

timeInactive 

Datum der letzten Aktion bzw. Routenwahl des Nutzers, da er 

danach als inaktiv gilt, bis erneut eine Route gewählt wird. 

gender Angabe des Geschlechts in „True“ = weiblich und „False“ = 

männlich. 

timeRegistered Datum der Registration des Nutzers an der Jinengo-Plattform. DateTime 

DateTime 

name Vorname und Nachname des Nutzers. varChar 

email Email-Adresse des Nutzers. varChar 

street Straße der vom User angegebenen Adresse. varChar 

zipcode Postleitzahl der Nutzer Adresse. varChar 

city Stadt der Adresse des Nutzers. varChar 

country Land zur vom Nutzer angegebenen Adresse. varChar 

birthdate Geburtsdatum des Nutzers date 

incomeRangeID (FS) 

familyStatusID (FS) 

ownsPEV 

ownsGasCar 

ownsEbike 

publicTransportMember 

railMembershipID 

(FS) 

maxDistanceToWalk 

maxDistanceToBike 

Ein Int Wert, der Schlüssel des gewünschten Eintrags der Entität 

IncomeRange ist. 


FamilyStatus ist. 

Auskunft über den Besitz eines Elektrischen Vehikels durch 

Angabe in „True“, oder „False“. 

Auskunft über den Besitz eines Autos mit Verbrennungsmotor 

durch Angabe in „True“, oder „False“. 

Auskunft über den Besitz eines e-Bikes durch Angabe in 

„True“, oder „False“. 

Auskunft über den Besitz einer Monatskarte für den Öffentlichen 

Personen Nahverkehr durch Angabe in „True“, oder „False“. 


RailMembership ist. 

Auskunft über die maximale Distanz, die der Nutzer bereit ist 

zu Laufen. Angabe in Kilometern. 

Auskunft über die maximale Strecke, die der Nutzer bereit 

wäre mit dem Fahrrad zurück zu legen. Angabe in Kilometern. 

Bit 

BigInt 

BigInt 

Bit 

Bit 

Bit 

Bit 

BigInt 

Int 

Int 

Tabelle A.1: Entität JinengoUser der operativen Datenbank 

107



Tabelle: Route 


userID (PS, FS) 

108 

Identifikationsnummer, des Nutzers, der diese Route gefahren 

ist. 

BigInt 

ID (PS) Systeminterne Identifikationsnummer der Route. BigInt 

timeSelected 

departureGeography 

Binärdaten zur digitalen Speicherung der Geographie- 

Informationen des Abfahrortes. 

Datum mit Uhrzeit, die den Zeitpunkt der Routenwahl definiert. 

DateTime 

geography 

departureAddress Adresse des Abfahrortes. varChar 

departureTime Datum und Uhrzeit der Abfahrt. DateTime 

destinationGeography 


Informationen des Zielortes. 

geography 

destinationAdress Adresse des Zielortes. varChar 

destinationTime Datum und Uhrzeit der Ankunft. DateTime 

totalTime Gesamte Fahrtzeit in Minuten Int 

needID (FS) 

luggage 

Wurde während des Projektes nicht genutzt, sollte aber abbilden, 

welcher Zweck hinter einer Reise stand (Geschäftsreise, 

Urlaub etc.). In diesem Feld würde sich dann die Identifikationsnummer 

des Zwecks finden, dem die entstandenen Daten 

zuzurechnen sind 

Angabe ob die Reise mit Gepäck (=“True“) oder ohne Gepäck 

(=“False“) angetreten wurde. 

BigInt 

passengers Anzahl der Personen, die diese Fahrt angetreten sind. TinyInt 

ecoImpactAdvantage 

ecoImpactDisadvantage 

timeAdvantage 

timeDisadvantage 

effectiveTimeAdvantage 

Nutzbare Zeit in Minuten im Vergleich zur schlechtesten Alternative. 

effectiveTimeDisadvantage 

costsAdvantage 

costsDisadvantage 

CO2-Emissionsunterschied total in Abhängigkeit von der 

schlechtest möglichen Routenalternative. 

CO2-Emissionsunterschied total in Abhängigkeit von der 

bestmöglichen Routenalternative. 

Zeit-Ersparnis in Minuten in Abhängigkeit von der langsamsten 

Routenalternative. 

Zeit-Verlust in Minuten in Abhängigkeit von der schnellsten 

Routenalternative. 

Nicht Nutzbare Zeit in Minuten im Vergleich zur besten Alternative 

Kostenersparnis in Euro und Cent im Vergleich zur teuersten 

Alternative 

Mehrkosten in Euro und Cent im Vergleich zur günstigsten 

Alternative. 

Tabelle A.2: Entität Route der operativen Datenbank 

Bit 

Real 

Real 

Int 

Int 

Int 

Int 

Real 

Real



Tabelle: Subroute 


userID (PS, FS) ID des Nutzers der diese Subrouten gefahren ist. BigInt 

routeID(PS, FS) ID der Route zu der diese Subroute gehört. BigInt 

ID (PS) ID der Subroute. BigInt 

transportationID (FS) 

departureGeography 

ID des verwendeten Transportmittels. Dieser Wert entspricht 

einem Schlüssel der Entität Transportation und repräsentiert 

den dazugehörigen Wert. 


Informationen des Abfahrortes. 

BigInt 

geography 

departureAddress Adresse des Abfahrortes. varChar 

departureTime Datum und Uhrzeit der Abfahrt. DateTime 

destinationGeography 


Informationen des Zielortes. 

geography 

destinationAddress Adresse des Zielortes. varChar 

destinationTime Datum und Uhrzeit der Ankunft. DateTime 

distance Entfernung von Start- zu Zielort in Metern. Real 

time Benötigte Zeit von Start- zu Zielort in Minuten. Int 

timeUsable Nutzbare Zeit während der Reise in Minuten. Int 

costs Kosten der Teilstrecke in Euro und Cent. Real 

ecoImpact CO2-Emissionen die diese Strecke verursachen. Real 

contextInformation 

Tabelle A.3: Entität Suboute der operativen Datenbank 

varChar 

109



Tabelle: Preferences 


userID (PS, FS) ID des Nutzers zu dem diese Präferenzen gehören. BigInt 

validFrom (PS) Datum an dem die hinterlegten Angaben gemacht wurden. DateTime 

sustainabilityPreference 

comfortPreference 

costsPreference 

timePreference 

Nachhaltigkeits-Präferenz des Nutzers mit einer möglichen 

Gewichtung zwischen 0(=unwichtig) und 1(=wichtig). 

Komfort-Präferenz des Nutzers mit einer möglichen Gewichtung 

zwischen 0(=unwichtig) und 1(=wichtig). 

Kosten-Präferenz des Nutzers mit einer möglichen Gewichtung 


Zeit-Präferenz des Nutzers mit einer möglichen Gewichtung 


Tabelle A.4: Entität Preferences der operativen Datenbank 

Real 

Real 

Real 

Real 

Tabelle: Transportation 


ID (PS) ID des Transportmittels. BigInt 

transportationTypeID 

(FS) 

ID die dem speziellen Transportmittel eine Kategorie zuteilt. In 

einer weiteren Entität sind diese IDs mit den Klartextnamen 

der Kategorie hinterlegt. Diese reichen von HumanPowered 

über CarSharing bis hin zum Fernverkehr. 

BigInt 

classOrProviderName Klartextname des Transportmittels. varChar 

comfortRating 

Rating, dass den Komfort eines Transportmittels mit einem 

Wert zwischen 0 (=niedrig) und 1 (=hoch) versieht. 

Tabelle A.5: Entität Transportation der operativen Datenbank 

Real 

110



B. Tabellen des Data Warehouse 

Tabelle: UserHistoric 


ID (PS, FS) 


Nutzer für einen Zeitraum repräsentiert. 

BigInt 

validFrom Datum und Uhrzeit ab dem dieser abgebildete Nutzer gültig ist. DateTime 

validTill Datum und Uhrzeit bis zu dem dieser Nutzer gültig war. DateTime 

jinengoUserID (FS) 

street 

Ganzzahlige Identifikationsnummer des repräsentierten Nutzers. 

Straße der vom User angegebenen Adresse im Gültigkeitszeitraum. 

zipcode Postleitzahl der Nutzer Adresse im Gültigkeitszeitraum. char 

BigInt 

varChar 

city Stadt der Adresse des Nutzers im Gültigkeitszeitraum. varChar 

country 

incomeRangeID (FS) 

familyStatusID (FS) 

ownsPEV 

ownsGasCar 

ownsEbike 

publicTransportMember 

railMembershipID 

(FS) 

maxDistanceToWalk 

maxDistanceToBike 

carSharingMembership 

sustainabilityPreference 

Land zur vom Nutzer angegebenen Adresse im Gültigkeitszeitraum. 


IncomeRange ist. 


FamilyStatus ist. 

Auskunft über den Besitz eines Elektrischen Vehikels durch 

Angabe in „True“, oder „False“. 

Auskunft über den Besitz eines Autos mit Verbrennungsmotor 

durch Angabe in „True“, oder „False“. 

Auskunft über den Besitz eines e-Bikes durch Angabe in 

„True“, oder „False“. 

Auskunft über den Besitz einer Monatskarte für den Öffentlichen 

Personen Nahverkehr durch Angabe in „True“, oder „False“. 


RailMembership ist. 

Auskunft über die maximale Distanz, die der Nutzer bereit ist 

zu Laufen. Angabe in Kilometern. 


wäre zu Fuß zurück zu legen. Angabe in Kilometern. 


wäre mit dem Fahrrad zurück zu legen. Angabe in Kilometern. 

Nachhaltigkeits-Präferenz des Nutzers mit einer möglichen 

Gewichtung zwischen 0(=unwichtig) und 1(=wichtig). 

varChar 

BigInt 

BigInt 

Bit 

Bit 

Bit 

Bit 

BigInt 

comfortPreference Komfort-Präferenz des Nutzers mit einer möglichen Gewich- Real 

Int 

Int 

Int 

Real 

111



costsPreference 

timePreference 

tung zwischen 0(=unwichtig) und 1(=wichtig). 

Kosten-Präferenz des Nutzers mit einer möglichen Gewichtung 


Zeit-Präferenz des Nutzers mit einer möglichen Gewichtung 


Tabelle B.1: Entität UserHistoric des Data Warehouse 

Real 

Real 

Tabelle: JinengoUser 


ID (PS) 


Nutzer repräsentiert. 

BigInt 

timeInactive 

Datum der letzten Aktion bzw. Routenwahl des Nutzers, da er 

danach als inaktiv gilt, bis erneut eine Route gewählt wird. 

name Angabe des Geschlechts in „True“ = weiblich und „False“ = 

männlich. 

gender Vorname und Nachname des Nutzers. Bit 

timeRegistered Datum der Registration des Nutzers an der Jinengo-Plattform. DateTime 

DateTime 

varChar 

email Email-Adresse des Nutzers. varChar 

birthdate Geburtsdatum des Nutzers. Date 

Tabelle B.2: Entität JinengoUser des Data Warehouse 

112



Tabelle: AggrUserFigure 


ID (PS) 

JinengoUserID (FS) 

year 

Eine ganzzahlige Identifikationsnummer, die den entsprechenden 

aggregierten Datensatz repräsentiert. 

Identifikationsnummer des Anwenders dem die aufsummierten 

Daten im Zeitraum eines Monats zurechenbar sind. 

Ganzzahliger Wert, der das Jahr in dem die aggregierten Daten 

gültig sind repräsentiert. 

month Der Gültigkeitsmonat der Daten als ganzzahliger Wert. Int 

needID (FS) 

countRoutes 

countSubroutes 

sumDistance 

sumTime 

sumTimeBestOption 

sumTimeWorstOption 

sumTimeUsable 

sumTimeUsableBestOption 

sumTimeUsableWorstOption 

sumCosts 

sumCostsBestOption 

sumCostsWorstOption 

sumEcoImpact 


welcher Zweck hinter einer Reise stand (Geschäftsreise, 

Urlaub etc.). In diesem Feld würde sich dann die Identifikationsnummer 

des Zwecks finden, dem die entstandenen Daten in 

einem Monat zuzurechnen sind. 

Anzahl der gewählten Routen aller Nutzer für einen Zeitraum 

eines Monats. 

Anzahl der gefahrenen Subrouten aller Nutzer für einen Zeitraum 

eines Monats. 

Summer der insgesamt von allen Nutzern gefahrenen Distanz 

im Zeitraum eines Monats in Kilometern. 

Gesamtzeit, die die Anwender bei der Absolvierung von Routen 

mit Jinengo in einem Monat verbracht haben. Angabe in 

Minuten. 

Summe der Zeit, die alle gefahrenen Routen im Zeitraum eines 

Monats verursacht hätten, wenn immer die schnellsten Routenalternativen 

gewählt worden wären. 

Summe der Zeit, die alle gefahrenen Routen im Zeitraum eines 

Monats verursacht hätten, wenn immer die langsamste Routenalternativen 

gewählt worden wären. 

Summe der nutzbaren Zeit aller Fahrten in einem bestimmten 

Monat. 

Summe der nutzbaren Zeit die im Falle der besten Routenalternativen 

im Zeitraum eines Monats möglich gewesen wäre. 

Summe der nutzbaren Zeit die im Falle der schlechtesten Routenalternativen 

im Zeitraum eines Monats möglich gewesen 

wäre. 

Summe der Fahrtkosten aller zurückgelegten Routen für den 

Zeitraum eines Monats in Euro und Cent. 

Summe der entstandenen Kosten der günstigsten Routenalternativen 

im Zeitraum eines Monats. 

Summe der entstandenen Kosten der teuersten Routenalternativen 


Summe des EcoImpacts, den alle gefahrenen Routen im Zeitraum 

eines Monats verursacht haben. Angabe in Gramm CO2. 

BigInt 

BigInt 

Int 

BigInt 

Int 

Int 

Real 

Int 

Int 

Int 

Int 

Int 

Int 

Real 

Real 

Real 

Real 

113



sumEcoImpactBestOption 

sumEcoImpactWorstOption 

cluster 

Summe des EcoImpacts der umweltfreundlichsten Routenalternativen 


Summe des EcoImpacts der umweltschädlichsten Routenalternativen 


Klartext Bezeichnung des Clusters in welches sich die gespeicherten 

Daten einordnen lassen. 

Tabelle B.3: Entität AggrUserFigure des Data Warehouse 

Real 

Real 

varChar 

114



Tabelle: AggrUserFigurePerTransportation 


ID (PS) 

JinengoUserID (FS) 

year 

Eine ganzzahlige Identifikationsnummer, die den entsprechenden 

aggregierten Datensatz repräsentiert. 

Identifikationsnummer des Anwenders dem die aufsummierten 

Daten im Zeitraum eines Monats zurechenbar sind. 



month Der Gültigkeitsmonat der Daten als ganzzahliger Wert. Int 

transportationTypeID 

(FS) 

needID (FS) 

countRoutes 

countSubroutes 

sumDistance 

sumTime 

sumTimeUsable 

sumCosts 

sumEcoImpact 

cluster 

Die Identifikationsnummer des Verkehrsmittel, dem diese Daten 

im angegebenen Zeitraum zurechenbar sind. 


welcher Zweck hinter einer Reise stand (Geschäftsreise, Urlaub 

etc.). In diesem Feld würde sich dann die Identifikationsnummer 

des Zwecks finden, dem die entstandenen Daten in einem Monat 

zuzurechnen sind. 


eines Monats, aggregiert nach Verkehrsmittel. 

Anzahl der gefahrenen Subrouten aller Nutzer für einen Zeitraum 

eines Monats, aggregiert nach Verkehrsmittel. 

Summer der insgesamt von allen Nutzern gefahrenen Distanz im 

Zeitraum eines Monats in Kilometern, aggregiert nach Verkehrsmittel. 

Gesamtzeit, die die Anwender bei der Absolvierung von Routen 

mit Jinengo in einem Monat verbracht haben. Angabe in Minuten. 

Summe der nutzbaren Zeit aller Fahrten in einem bestimmten 

Monat. 

Summe der Fahrtkosten aller zurückgelegten Routen für den Zeitraum 

eines Monats in Euro und Cent, aggregiert nach Verkehrsmittel. 


eines Monats verursacht haben, aggregiert nach Verkehrsmittel. 

Angabe in Gramm CO2. 

Klartext Bezeichnung des Clusters in welches sich die gespeicherten 

Daten einordnen lassen. 

Tabelle B.4: Entität AggrUserFigurePerTransportation des Data Warehouse 

BigInt 

BigInt 

Int 

BigInt 

BigInt 

Int 

Int 

Real 

Int 

Int 

Real 

Real 

varChar 

115



Tabelle: AggrPlatformFigure 

year (PS) 



month (PS) Der Gültigkeitsmonat der Daten als ganzzahliger Wert. Int 

countActiveUsers Summe der Aktiven Nutzer für einen Zeitraum eines Monats. Int 


countRegisteredUders 

countRoutes 

sumDistance 

sumCosts 

sumEcoImpact 

sumEcoImpactBestOption 

sumEcoImpactWorstOption 

Summe der registrierten Nutzer für einen Zeitraum eines Monats. 


eines Monats. 

Summer der insgesamt von allen Nutzern gefahrenen Distanz im 

Zeitraum eines Monats in Kilometern. 

Summe der Fahrtkosten aller zurückgelegten Routen für den 

Zeitraum eines Monats in Euro und Cent. 


eines Monats verursacht haben. Angabe in Gramm CO2. 

Summe des EcoImpacts der umweltfreundlichsten Routenalternativen 


Summe des EcoImpacts der umweltschädlichsten Routenalternativen 


Tabelle B.5: Entität AggrPlatformFigure des Data Warehouse 

Int 

Int 

Real 

Real 

Real 

Real 

Real 

Real 

116


Jinengo - Dokumentation 




Dokumentation 

117



118



Inhaltsverzeichnis Jinengo Dokumentation 

Abbildungsverzeichnis ........................................................................................................... 120 

Tabellenverzeichnis ................................................................................................................ 121 

1. Ergebnisdarstellung & Technische Dokumentation ....................................................... 123 

1.1 BI-Architektur ............................................................................................................ 123 

1.2 Datenbanken ............................................................................................................... 124 

1.2.1 Operative Datenbank (JinengoOperationalCRM) ........................................... 125 

1.2.2 Relationales Data Warehouse (JinengoDataWarehouse) ................................ 125 

1.3 Subroute-Cube ............................................................................................................ 128 

1.4 Datenflüsse ................................................................................................................. 130 

1.4.1 Prozess zur Füllung der operativen Datenbank mit generierten Daten ........... 131 

1.4.2 ETL-Prozess zur Füllung des relationalen Data Warehouse ........................... 132 

1.4.3 Aggregation von Daten im Data Warehouse ................................................... 133 

1.5 Data Mining ................................................................................................................ 135 

1.5.1 Klassifizierung ................................................................................................. 137 

1.5.2 Clustering......................................................................................................... 141 

1.5.3 Assoziation ...................................................................................................... 144 

1.6 Endanwender-Reporting Frontend ............................................................................. 146 

1.6.1 Aufbau der Weboberfläche .............................................................................. 146 

1.6.2 Verwendete Technologien ............................................................................... 149 

1.7 Reporting-API ............................................................................................................ 151 

1.7.1 Controller und Service Klassen ....................................................................... 152 

1.7.2 Datenmodel ...................................................................................................... 156 

1.7.3 Konfiguration der Anwendung ........................................................................ 160 

1.8 Reporting mit SSRS ................................................................................................... 161 

1.8.1 Aufbau der Reports & Dashboards .................................................................. 162 

1.8.2 Administration der Reports & Dashboards ..................................................... 166 

1.9 Reporting mit QlikView ............................................................................................. 167 

1.10 Self-Service-BI mit Excel........................................................................................... 169 

2. Installationshandbuch ..................................................................................................... 172 

2.1 Datenbank, Cube, Datenflüsse und SSRS-Reports einrichten ................................... 172 

2.2 Datengenerator ........................................................................................................... 173 

2.3 Reporting API und Frontend für Endanwender.......................................................... 176 

3. Begründung eingesetzter Webtechnologien.................................................................... 178 

3.1 Frontend ...................................................................................................................... 178 

3.2 Backend ...................................................................................................................... 180 

4. Fazit ................................................................................................................................. 183 

Literaturverzeichnis ................................................................................................................ 186 

119




Abbildung 1.1: Dialog zum Herstellen einer Verbindung mit dem Datenbankmodul ........... 124 

Abbildung 1.2: Projektmappen-Explorer des Visual Studio für SSAS .................................. 128 

Abbildung 1.3: Dialog zum Anlegen eines neuen Cube-Measures ....................................... 129 

Abbildung 1.4: Dialog zum Anlegen einer neuen Cube-Berechnung .................................... 130 

Abbildung 1.5: Projektmappen-Explorer des Visual Studio für SSIS ................................... 130 

Abbildung 1.6: Prozessablauf zur Füllung der operativen Datenbank ................................... 131 

Abbildung 1.7: Prozessablauf zur Füllung des Data Warehouse ........................................... 133 

Abbildung 1.8: Prozessablauf zur Datenaggregation im Data Warehouse ............................ 134 

Abbildung 1.9: Datenfluss zur Neuaggregation im Data Warehouse .................................... 134 

Abbildung 1.10: Beispiel Stream aus dem SPSS Modeler 15 ................................................ 135 

Abbildung 1.11: Daten importieren & aufbereiten ................................................................ 136 

Abbildung 1.12: Daten im SPSS Modeler 15 analysieren ..................................................... 136 

Abbildung 1.13: Daten exportieren im SPSS Modeler 15 ..................................................... 137 

Abbildung 1.14: Typzuordnung im SPSS Modeler 15 (eigene Abbildung) .......................... 140 

Abbildung 1.15: Daten aufbereiten Sustainability Clustering ............................................... 142 

Abbildung 1.16: Daten aufbereiten Personen Cluster ............................................................ 143 

Abbildung 1.17: Daten analysieren Sustainability Cluster .................................................... 143 

Abbildung 1.18: Daten analysieren Personen Cluster ............................................................ 144 

Abbildung 1.19: Daten aufbereiten Assoziationsanalyse ....................................................... 145 

Abbildung 1.20: Daten analysieren Assoziation .................................................................... 145 

Abbildung 1.21: Daten exportieren Assoziationsanalyse ...................................................... 146 

Abbildung 1.22: Screenshot CO2-Emission Endanwender ................................................... 147 

Abbildung 1.23: Screenshot Verteilung Verkehrsmittel ........................................................ 148 

Abbildung 1.24: Screenshot C02-Einsparpotential ................................................................ 148 

Abbildung 1.25: Aufbau einer Spring MVC Anwendung ..................................................... 152 

Abbildung 1.26: UML User Controller API .......................................................................... 154 

Abbildung 1.27: UML Platform Controller API .................................................................... 155 

Abbildung 1.28: UML Authentication Controller API .......................................................... 156 

Abbildung 1.29: UML Model Klassen API ........................................................................... 157 

Abbildung 1.30: Anmeldung zu den Reporting-Services mit dem Internet Explorer ............ 162 

Abbildung 1.31: Anmeldung zu den Reporting-Services mit dem Internet Explorer ............ 163 

Abbildung 1.32: Screenshot des SSRS-Dashboards „Jinengo-Überblick“ ............................ 164 

Abbildung 1.33: Screenshot des SSRS-Dashboards „Clusteranalyse“ .................................. 164 

Abbildung 1.34: Screenshot des SSRS-Dashboards „Orte in Oldenburg“ ............................ 164 

Abbildung 1.35: Screenshot des SSRS-Reports „Nutzung der Plattform“ ............................ 165 

Abbildung 1.36: Screenshot des SSRS-Reports „Reisekennzahlen (Zeit & 

Verkehrsmittel)“ ..................................................................................................................... 165 

Abbildung 1.37: Screenshot des SSRS-Reports „Reisekennzahlen (Zeit & Präferenz)“ ...... 166 

Abbildung 1.38: Projektmappen-Explorer des Visual Studio für SSRS ................................ 167 

Abbildung 1.39: Beispiel für spezifische Berichtsdaten im Visual Studio ............................ 167 

Abbildung 1.40: QlikView Basisansicht ................................................................................ 168 

Abbildung 1.41: Auszug aus dem "Load-Skript" in QlikView .............................................. 168 

Abbildung 1.42: Beispiel für die Umsetzung eines Dashbaords ............................................ 169 

Abbildung 1.43: Dialog zur Datenverbindungs-Konfiguration in Excel ............................... 170 

Abbildung 1.44: Dialog zur Auswahl des Cubes in Excel ..................................................... 170 

Abbildung 1.45: Dialog zum Speichern der Authentifizierungseinstellungen in Excel ........ 171 

Abbildung 1.46: Beispiel für die Visualisierung von Reportdaten ........................................ 172 

Abbildung 2.1: Verbindungseinrichtugn des SQL Server Management Studios ................... 173 

Abbildung 2.2: Importdialog in eclipse.................................................................................. 175 

120



Abbildung 2.3: ProjectExplorer aus eclipse für den Routengenerator ................................... 176 


Tabelle 1.1: Tabellen der operativen Datenbank ................................................................... 125 

Tabelle 1.2: Tabellen des relationalen Data Warehouse ........................................................ 126 

Tabelle 1.3: Views des relationalen Data Warehouse ............................................................ 127 

Tabelle 1.4: Ablaufbeschreibung zur Füllung des Data Warehouse ...................................... 133 

Tabelle 1.5: JavaScript Module Endanwender Frontend ....................................................... 150 

Tabelle 1.6: API Datenmodell aggregierte Nutzerkennzahlen ............................................... 158 

Tabelle 1.7: API Datenmodell aggregierte Verkehrsmittelkennzahlen ................................. 159 

Tabelle 1.8: API Datenmodell Nutzerauthentifizierung ........................................................ 159 

Tabelle 1.9: API Datenmodell Nutzerdetails ......................................................................... 160 

Tabelle 1.10: API Datenmodell Freundesliste ....................................................................... 160 

Tabelle 3.1: Eingesetzte Java Technologien .......................................................................... 181 

121



Das vorliegende Dokument stellt die Ergebnisse der Jinengo-Teilgruppe der Projektgruppe Cuberunner 

vor und dokumentiert das Ergebnis aus technischer Sicht (siehe Kapitel 1). Zudem 

werden Hinweise gegeben, wie sich die Projektergebnisse auf einem anderen, als auf dem von 

der Projektgruppe verwendeten, Server installieren lassen (siehe Kapitel 2). Umfang und Inhalt 

der einzelnen Abschnitte in den Kapiteln 1 und 2 variieren dabei zum Teil, um den spezifischen 

Anforderungen des Konzeptes Rechnung zu tragen. So wird das Ergebnis des Datengenerators 

nicht mehr dokumentiert, da der entsprechende Teil im Rahmen einer Produktivsetzung von 

Jinengo seine Relevanz verliert 18 . Zudem erfordern die selbstentwickelten Systembestandteile 

nach einer detaillierteren Dokumentation als diejenigen, die mithilfe der BI-Standardsoftware 

entwickelt wurden. Kapitel 3 begründet daher auch noch einmal ausführlicher die Wahl der 

eingesetzten Webtechnologien für die Reporting-API sowie das Endanwender-Reporting. Die 

Dokumentation schließt in Kapitel 4 mit einem Fazit der Ergebnisse der Jinengo-Teilgruppe. 

18 Stattdessen sei auf die Spezifikation des Datengenerators im DV-Konzept sowie auf den Quellcode verwiesen. 

122



1. Ergebnisdarstellung & Technische Dokumentation 

1.1 BI-Architektur 

Im Projektverlauf wurde ein virtueller Server mit dem Betriebssystem Windows Server 2008 eingerichtet 

(nachfolgend PGBI-Server genannt). Als Datenbank wurde der Microsoft SQL Server 2012 

installiert. Der Computer mitsamt seinen SQL-Serveranwendungen lässt sich über eine Remotedesktopverbindung 

administrieren. 

Der SQL-Server lässt sich zudem ebenfalls über lokal installierte Anwendungen (SQL Server Management 

Studio und Visual Studio) administrieren. Der Zugang zum PGBI-Server sowie der Datenbank 

wird in der gesamten Dokumentation an den entscheidenden Stellen beschrieben. Die relevanten 

Hinweise sollen hier allerdings der Übersichtlichkeit halber bereits vorab gegeben werden. 

Für den Zugriff zum PGBI-Server per Remotedesktopverbindung sind die folgenden Zugangsdaten 

relevant: 

 

 

 

Computer: pg-bi.informatik.uni-oldenburg.de 

Benutzer: PGBI\PBoewe (Windows-Benutzer) 

Passwort: pgbi32! 

Um den Server mit den lokal installierten Serveranwendungen (insbesondere SQL Server Management 

Studio) zu administrieren, ist eine VPN-Verbindung zur Universität Oldenburg herzustellen. Folgenden 

Zugangsdaten sind zu verwenden: 

Servername (IP-Adresse): 134.106.13.63 

Authentifizierung: SQL-Server-Authentifizierung 

Benutzer: jinengo (DB-Benutzer) 

Passwort: pgbi32! 

123



1.2 Datenbanken 

Anmerkung: Zur Betrachtung und Administration der Datenbanken ist das „Microsoft SQL Server 

Management Studio“ zu verwenden. Dieses kann entweder lokal oder über eine Remotedesktopverbindung 

auf dem PGBI-Server ausgeführt werden. Die lokale Version erfordert dabei einen VPN- 

Tunnel zur Universität Oldenburg. Als Servertyp sind das „Datenbankmodul“ und der Servername 

„PGBI“ zu wählen. Die Authentifizierung kann mit dem Windows-Benutzer erfolgen (siehe Abbildung 

1.1). 

Abbildung 1.1: Dialog zum Herstellen einer Verbindung mit dem Datenbankmodul 

Auf dem PGBI-Server wurden zwei Datenbanken eingerichtet. Die Datenbank JinengoOperational- 

CRM enthält die Tabellen, die für den operativen Systembetrieb vorgesehen sind. Die Datenbank 

JinengoDataWarehouse enthält hingegen die Tabellen, die für die Analyse der Daten verwendet werden. 

124



1.2.1 Operative Datenbank (JinengoOperationalCRM) 

Die Tabellen der operativen Datenbank sind in Tabelle 1.1 aufgeführt. Sie sind dabei nach Kontext 

getrennt, in dem sie verwendet werden. 

Kontext 

Tabelle 

Datengenerator 

A_SOURCE_GeoLocation 

A_SOURCE_JinengoUser 

A_SOURCE_Route 

A_SOURCE_Subroute 

Operatives System CarSharingMembership 

FamilyStatus 

IncomeRange 

JinengoUser 

JinengoUserFriend 

Need 

Preferences 

RailMembership 

Route 

Subroute 

Transportation 

TransportationType 

Endanwender-Reports UserAuthentication 

Tabelle 1.1: Tabellen der operativen Datenbank 

1.2.2 Relationales Data Warehouse (JinengoDataWarehouse) 

Die Tabellen des relationalen Data Warehouse sind in Tabelle 1.2 aufgeführt. Sie sind dabei nach 

Kontext getrennt, in dem sie verwendet werden. 

125



Kontext 

ETL-Prozess 

Aggregiertes 

Data Warehouse 

Tabelle 

A_Temp_CarSharingMembership 

AggrPlatformFigures 

AggrUserFigures 

AggrUserFiguresPerTransportation 

Historisiertes 

Data Warehouse 

Data Mining 

CarSharingMembership 

FamilyStatus 

IncomeRange 

JinengoUser 


Need 

RailMembership 

Route 

Subroute 


TransportationType 

UserHistoric 

AssociationResults 

ClassificationPrediction 

UserAttributeClustering 

UserSustainabilityClustering 

Tabelle 1.2: Tabellen des relationalen Data Warehouse 

Zudem wurden einige Sichten (Views) definiert, die den Zugriff auf die Daten erleichtern sollen. Nach 

Möglichkeit erfolgt jeglicher analytischer Datenzugriff über diese Views. Vorteil von Views für den 

analytischen Datenzugriff ist insbesondere die Komplexitätsreduzierung durch bereits vorab vorgenommene 

Joins. Zudem wird durch die Views die genaue Logik des Data Warehouse gekapselt. Analytische 

Anwendungen wie Reports und Dashboards werden dadurch unabhängiger von der tatsächlichen 

Implementierung des Data Warehouse. Nachträgliche Änderungen können so leichter vorgenommen 

werden. Tabelle 1.3 gibt einen Überblick über Name und Funktion der Views im relationalen 

Data Warehouse. 

126



Kontext View Funktion 

Data 

Mining 

DataMining 

Zählt pro Endanwender welche Verkehrsmittel wie 

oft genutzt wurden. 

Cubes SSAS_DIM_Route Bereitet die Tabelle Route zur Verwendung als 

Dimension in Cubes auf. Es findet ein Join mit der 

Tabelle Need statt, um das Bedürfnis hinter der 

Route zu selektieren. Zudem findet eine Reduzierung 

auf die für die dimensionale Verwendung relevanten 

Attribute statt. 

SSAS_DIM_Transportation 

SSAS_DIM_UserHistoric 

SSAS_FACT_Subroute 

Bereitet die Tabelle Transportation (Verkehrsmittel) 

zur Verwendung als Dimension in Cubes auf. 

Es findet ein Join mit der Tabelle Transportation- 

Type statt, um den übergeordneten Verkehrsmitteltyp 

zu selektieren. Zudem findet eine Reduzierung 

auf die für die dimensionale Verwendung relevanten 

Attribute statt. 

Bereitet die Tabelle UserHistoric (historisierter 

Endanwender) zur Verwendung als Dimension in 

Cubes auf. Dafür werden die Fremdschlüsselbeziehungen 

zu den Stammdatentabellen FamilyStatus, 

IncomeRange, RailMembership und JinengoUser 

per Join aufgelöst. Auch die Clustering-Ergebnisse 

aus den Tabellen UserAttributeClustering und 

UserSustainabilityClustering werden mit einbezogen. 

Es findet eine Reduzierung auf die für die dimensionale 

Verwendung relevanten Attribute statt. 

Bereitet die Tabelle Subroute zur Verwendung als 

Faktentabelle eines Cubes auf. Dafür werden die 

Attribute entfernt, die sich nicht als Messgröße 

bzw. Verweis auf eine Dimension interpretieren 

lassen. 

Reporting V_AggrPlatformFigure Berechnet zu den in der Tabelle AggrPlatformFigure 

dargestellten Kennzahlen zusätzlich die abgeleiteten 

Kennzahlen „Ausgeschöpftes CO 2 - 

Reduktionspotential“ (M11) sowie „Anteil aktiver 

Endanwender“ (J03). 

V_AggrUserFigure 

V_AggrUserFigurePer- 


Löst die Fremdschlüsselbeziehung zur Tabelle Need 

auf, die das Bedürfnis eines Anwenders hinter seinen 

Reisen darstellt. 

Löst die Fremdschlüsselbeziehung zur Tabelle Need 

auf, die das Bedürfnis eines Anwenders hinter seinen 

Reisen darstellt. Zudem wird analog die 

Fremdschlüsselbeziehung zur Tabelle TransportationType 

aufgelöst, um den Verkehrsmitteltyp der 

Reisen zu bestimmen. 

Tabelle 1.3: Views des relationalen Data Warehouse 

127



1.3 Subroute-Cube 

Anmerkung: Zur Betrachtung und Administration des Cubes ist das „Microsoft Visual Studio“ auf 

dem PGBI-Server zu starten und das Projekt „JinengoAnalysisCube.sln“ zu öffnen. Dieses findet sich 

unter dem Dateipfad: „C:\Users\PBoewe\Documents\Visual Studio 

2010\Projects\JinengoAnalysisCube“. 

Auf dem PGBI-Server wurde mithilfe der SQL Server Analysis Services (SSAS) der Cube Subroute 

eingerichtet, der die entsprechenden Daten des relationalen Data Warehouse multidimensional aufbereitet. 

Wie im DV-Konzept vorgesehen, verfügt der Cube über die vier Dimensionen Zeit, Verkehrsmittel, 

Endanwender und Route. Der Cube dient als Grundlage für verschiedene SSRS-Reports und 

kann im Rahmen der Self-Service BI zudem per Microsoft Excel abgerufen werden 

Abbildung 1.2: Projektmappen-Explorer des Visual Studio für SSAS 

Das Vorgehen zur Erstellung des Cubes im Microsoft Visual Studio (siehe Abbildung 1.2) wird im 

Folgenden kurz beschrieben: 

1. Zunächst wurde eine Verbindung zu einer Datenbank als Datenquelle definiert. In diesem Fall 

handelt es sich um eine Verbindung zum JinengoDataWarehouse. 

2. Anschließend wurden die zuvor in Tabelle 1.3 definierten Views durch die Datenquellensicht 

mit in die Betrachtung eingeschlossen. Die Beziehungen zwischen den einzelnen Views wurden 

manuell definiert 19 . 

19 Die automatische Erkennung von Fremdschlüsselbeziehungen funktioniert nur bei eingebundenen Tabellen. 

Die Beziehungen von Views müssen hingegen manuell gezogen werden. 

128



3. Anschließend wurden die Dimensionen angelegt. 

a. Die Anlage der Verkehrsmittel-Dimension erfolgt auf Basis der bestehenden gleichnamigen 

View. Es wurde eine Attributhierarchie definiert, die ein Drill-Down in den 

späteren Reports ermöglicht. Das Komfort-Attribut des Verkehrsmittels wird in drei 

gleichgroße Gruppen eingeteilt (Discretization). Auf diese Weise erfolgt die Filterung 

und Aggregation der Daten nicht mehr auf Ebene einzelner Werte, sondern auf der 

Ebene von Wertebereichen. 

b. Die Anlage der Endanwender-Dimension erfolgt auf Basis der bestehenden gleichnamigen 

View. Auch hier werden die Präferenz-Attribute für Komfort, Kosten, Nachhaltigkeit 

und Zeit in drei gleichgroße Gruppen eingeteilt. 

c. Die Anlage der Route-Dimension erfolgt auf Basis der bestehenden gleichnamigen 

View. Weitere spezifische Einstellungen werden nicht vorgenommen. 

d. Für die Zeit-Dimension wurde ein entsprechender Assistent verwendet. Attribute und 

Hierarchien wurden dafür für die Ebenen Jahr, Quartal, Monat, Woche und Tag definiert. 

4. Im Anschluss wurde der Cube Subroute angelegt, der auf der entsprechenden View basiert. 

a. Dem Cube werden die Dimensionen zugewiesen. Die Zuordnung zu den drei Dimensionen 

Verkehrsmittel, Endanwender und Route erfolgt automatisch auf Basis der zuvor 

definierten Beziehungen. Die Zeit-Dimension musste hingegen manuell mit dem 

Abfahrts- sowie Endzeitpunkt verbunden werden. 

b. Die im Fachkonzept definierten Kennzahlen lassen sich als Measures anlegen, solange 

sie durch einfache Aggregationsfunktionen aus den Tabellendaten generiert werden 

können (siehe Beispiel in Abbildung 1.3). Abgeleitete Kennzahlen lassen sich durch 

Berechnungen definieren. Für den Cube Subroute war das für die Kennzahlen „Reisekosten 

pro Kilometer“ (M05) und „CO 2 -Emissionen pro Kilometer“ (M10) notwendig 

(siehe Beispiel in Abbildung 1.4). 

Abbildung 1.3: Dialog zum Anlegen eines neuen Cube-Measures 

129



Abbildung 1.4: Dialog zum Anlegen einer neuen Cube-Berechnung 

1.4 Datenflüsse 

Anmerkung: Zur Betrachtung und Administration der Datenflüsse ist das „Microsoft Visual Studio“ 

auf dem PGBI-Server zu starten und das Projekt „JinengoIntegration1.sln“ zu öffnen. Dieses findet 

sich unter dem Dateipfad „C:\Users\PBoewe\Documents\Visual Studio 

2010\Projects\JinengoIntegration1“. 

Auf dem PGBI-Server wurden mit den SQL Server Integration Services (SSIS) drei Datenflüsse erstellt. 

Der erste füllt die operative Datenbank mit den Daten des Datengenerators, der zweite füllt das 

Data Warehouse aus der operativen Datenbank und der dritte aggregiert die Daten im Data Warehouse. 

Diese Flüsse wurden im Projekt „JinengoIntegration1“ als einzelne SSIS-Pakete angelegt 

(siehe Abbildung 1.5). 

Abbildung 1.5: Projektmappen-Explorer des Visual Studio für SSIS 

Die drei Pakete lassen sich dabei auf zwei Wegen ausführen; manuell sowie automatisch. Die manuelle 

Ausführung ist bislang der favorisierte Weg, da aufgrund des manuell angeworfenen Datengenerators 

nur zu definierten Zeiten mit neuen Daten zu rechnen ist. Für die Ausführung ist im Visual Studio 

auf das SSIS-Paket rechts zu klicken, anschließend sind „Als Startobjekt festlegen“ sowie „Paket ausführen“ 

zu wählen. Der Prozess läuft dann im Debugging-Modus ab und kann von dort aus auch 

überwacht werden. 

130



Üblicherweise werden Pakete allerdings auf dem Server abgelegt und von dort aus – in der Regel automatisiert 

– gestartet. Für die Überspielung auf den Server ist im Visual Studio im Menü „Erstellen“ 

und dann „JinengoIntegration1 erstellen“ zu wählen. Anschließend mit dem „SQL Server Management 

Studio“ bei den „Integration Services“ anmelden (Programm dafür unbedingt als Administrator 

starten). Unter „Gespeicherte Pakte“, „MSDB“, „Paket importieren“ kann dann das SSIS-Paket vom 

Dateisystem in die Datenbank importiert werden. Die Speicherung des Paktes in der Systemdatenbank 

MSDB hat den Vorteil, dass so auch die Sicherung der Pakete gemeinsam mit der Datenbank erfolgt. 

Das SSIS-Paket lässt sich über das Kontextmenü nun lokal ausführen. Für eine Automatisierung ist 

der Ast „SQL Server-Agent“ des „SQL Server Management Studio“ aufzuklappen. Hier kann dann ein 

neuer Auftrag angelegt werden. Innerhalb dieses Auftrags dann einen Schritt vom Typ „SSIS-Paket“ 

anlegen, als Paketquelle den SSIS-Paketspeicher auswählen, den Server angeben und das entsprechende 

Paket auswählen. Unter „Zeitpläne“ lässt sich ein neuer Plan zur automatischen Einplanung des 

Pakets wählen. 

1.4.1 Prozess zur Füllung der operativen Datenbank mit generierten Daten 

Der Prozess zur Füllung der operativen Datenbank mit den Daten aus dem Datengenerator (Jinengo- 

DataGenerator) besteht aus drei hintereinander ausgeführten Tasks (siehe Abbildung 1.6): 

1. „Process Routes“: Übertragt zuvor noch nicht übertragene Routen aus der temporärer Tabelle 

des Datengenerators in die Tabelle Route der operativen Datenbank. 

2. „Process Subroutes“: Überträgt die zu den Routen gehörige Subrouten aus der temporären 

Tabelle des Datengenerators in die Tabelle Subroute der operativen Datenbank. 

3. Set Routes as processed“: Markiert alle Routen als bereits übertragen. 

Abbildung 1.6: Prozessablauf zur Füllung der operativen Datenbank 

131



1.4.2 ETL-Prozess zur Füllung des relationalen Data Warehouse 

Der Prozess zur Füllung des relationalen Data Warehouse (JinengoETL) besteht aus verschiedenen 

parallel sowie hintereinander ausgeführten Tasks (siehe Abbildung 1.7). Tabelle 1.4 fasst die einzelnen 

Tasks der Übersicht halber zu verschiedenen Sinnabschnitten zusammen. 

Aufgabe Beteiligte Tasks Beschreibung 

Stammdaten 

Nichthistorisierte 

Endanwenderdaten 

Historisierte 

Endanwenderdaten 

Mobilitätsdaten 

CarSharing- 

Mietgliedschaften 

Cube 

aktualisieren 

132 

„Process FamilyStatus” 

„Process IncomeRange” 

„Process Need” 

„Process RailMembership” 

„Process TransportationType” 

„Process Transportation” 

„Process JinengoUser” 

„Delete f. JinengoUserFriend” 

„Process JinengoUserFriend” 

„Process UserHistoric“ 

„Get maxRouteTimeSelected” 

„Process Routes” 

„Process Subroutes” 

„Delete from A_TEMP_ 

CarSharingMembership” 

„Process A_TEMP_ 

CarSharingMembership” 

“Process CarSharing- 

Membership” 

“Process Subroute-Cube” 

Diese Stammdaten werden ohne Historisierung 

in das Data Warehouse übertragen bzw. bei 

Bedarf aktualisiert. Zentrales Element dieser 

Tasks ist die Transformation „Langsam veränderliche 

Dimension” (jeweils mit Typ-1- 

Änderung), die SSIS für die Verarbeitung von 

Stammdaten vorsieht. 

Aktualisiert die nicht-historisierten Endanwenderdaten 

(„Langsam veränderliche Dimension”, 

Typ-1) und bringt die Freundschaften auf 

den neusten Stand. 

Neben der Verarbeitung neuer Anwender werden 

hier insbesondere Änderungen an den 

Endanwenderdaten historisiert in das Data 

Warehouse übertragen. Dafür werden die Tabellen 

UserHistoric und Preferences der operativen 

Datenbank per Join zusammengeführt. 

Bei Abweichung eines oder mehrerer Attribute 

vom bisherigen Wert wird ein neuer Datensatz 

für den Anwender angelegt („Langsam veränderliche 

Dimension” des Typs 2). 

Übertragt diejenigen Daten aus den Tabellen 

Routen und Subrouten, die im vorherigen ETL- 

Durchlauf noch nicht übertragen wurden. Dabei 

wird die jinengoUserID durch userHistoricID 

überschrieben, indem die aktuell gültige 

Anwenderinstanz ermittelt wird. 

CarSharing-Mitgliedschaften werden mit einem 

Gültigkeitsdatum historisiert im Data 

Warehouse abgelegt. Die Transformation 

„Langsam veränderliche Dimension” kann hier 

nicht verwendet werden, da die Tabelle lediglich 

aus ihrem Primärschlüssel besteht. Daher 

werden neue und geänderte Datensätze manuell 

ermittelt. Um die Mitgliedschaften aus operativer 

Datenbank und Data Warehouse miteinander 

zu vergleichen, wird dabei eine temporäre 

Tabelle verwendet. Zudem wird die 

jinengoUserID durch userHistoricID überschrieben, 

indem die aktuell gültige Anwenderinstanz 

ermittelt wird. 

Nach Abschluss des ETL-Prozesses muss nun 

auch die Aktualisierung des Subroute-Cubes 

angestoßen werden, damit die Änderungen



anschließend auch dort verfügbar sind. 

Tabelle 1.4: Ablaufbeschreibung zur Füllung des Data Warehouse 

Abbildung 1.7: Prozessablauf zur Füllung des Data Warehouse 

1.4.3 Aggregation von Daten im Data Warehouse 

Der Ablauf zur Aggregation der Daten im Data Warehouse (JinengorDWAggregation) wird in Abbildung 

1.8 dargestellt. Zunächst werden die Jahr-Monat-Konstellationen ermittelt, bei denen seit dem 

letzten Durchlauf neue Routen hinzugekommen sind und die deshalb aktualisiert werden müssen. Anschließend 

läuft eine Schleife durch diese Jahr-Monat-Konstellationen, löscht die veralteten Datensätze 

und legt neue an. Den Ablauf zur Neuaggregation der Datensätze zeigt Abbildung 1.9. Für die neu 

zu berechnenden Jahr-Monat-Konstellationen werden dabei alle relevanten Daten zusammengesammelt 

und anschließend auf den drei definierten Ebenen erneut aggregiert. 

133



Abbildung 1.8: Prozessablauf zur Datenaggregation im Data Warehouse 

Abbildung 1.9: Datenfluss zur Neuaggregation im Data Warehouse 

134




Anmerkung: Die Projektdatei ist in der beigefügten DVD in dem Ordner „SPSS“ zu finden. In dem 

Ordner befindet sich, neben den einzelnen Streams, auch eine gesamte Projektdatei „JinengoDataMining“. 

Diese Datei kann mit dem SPSS Modeler 15 ausgeführt werden. Die Projektdatei fasst alle 

Streams übersichtlich zusammen. 

In Jinengo werden drei verschiedene Data Mining Techniken als Hauptanalysemethode angewandt, 

um den Kreis zwischen analytischer und operationaler Datenbank zu schließen. Diese Techniken sind 

Clustering, Klassifizierung und Assoziation. Jeder dieser drei Fälle wird mit dem Tool „SPSS Modeler 

15.0“ von IBM umgesetzt. Der SPSS Modeler wird in Jinengo in der kleinsten Personal Edition ohne 

Server Unterstützung umgesetzt. Daher stehen viele Funktionen, wie bspw. Automatisierungsfunktionen 

nicht zur Verfügung. Durch den Einsatz zusätzlicher Module der Produktfamilie SPSS von IBM 

können diese Funktionen aber leicht nachträglich umgesetzt werden. Die Projektgruppe hat sich auf 

die Entwicklung der sogenannten „Streams“ im SPSS Modeller konzentriert. Streams stellen den Datenfluss 

vom Input bis zum Output dar. Zwischen diesen beiden Schnittstellen werden grundsätzlich 

drei Aufgaben durchgeführt. 

1. Daten aufbereiten 

2. Daten analysieren 

3. Daten exportieren 

Unabhängig von dem Anwendungsfall ist die Reihenfolge der Schritte sehr ähnlich, obwohl sie inhaltlich 

unterschiedlich sind. Ein zentrales Element im SPSS Modeller sind Nodes (dt. Knoten). Jeder 

Stream besteht aus einer Anzahl an verketteten Nodes. Ein Node kann sowohl Algorithmus als auch 

Datentraformation sein. Im- und Export werden ebenfalls über Nodes abgebildet. 

Abbildung 1.10: Beispiel Stream aus dem SPSS Modeler 15 

Im ersten Schritt werden die Daten aus den Quellsystemen geladen und über einen "Merge" zusammengefasst. 

Im Anschluss werden den Daten Spaltentypen zugewiesen und notwendige Aggregatio- 

135



nen bzw. Transformationen ausgeführt. Das Ergebnis ist eine fertige Tabelle, die als Input für den 

Data Mining Algorithmus fungiert. Ein hilfreiches Tool zur Kontrolle der Input Daten ist der Node 

„Data Audit“. In diesem können fehlende Werte oder problematische Attribute schnell identifiziert 

und behoben werden. 

Daten aufbereiten 

Abbildung 1.11: Daten importieren & aufbereiten 

In der Abbildung 1.11 wird der Schritt der Datenaufbereitung detailliert dargestellt. Die beiden Symbole 

links stellen Datenbankimport-Schnittstellen dar. Der „Merge“-Node joint die beiden Inputdatenbanken 

und im Node „Type“ werden den einzelnen Spalten ihre, für das Data Mining notwendigen 

Typen zugeordnet (Bspw. input, target, none). 

Daten analysieren 

Der zweite Schritt, die Datenanalyse, besteht aus dem Algorithmus-Node und den Kontroll-Nodes, die 

das Ergebnis des Algorithmus kontrollieren. Jedes Data Mining Ergebnis sollte mit Hilfe der Nodes 

„Graphen“ und „Analysis“ auf seinen Validität überprüft werden, bevor die Ergebnisse mit dem dritten 

Schritt in die Datenbank zurückgeschrieben werden. 

136 

Abbildung 1.12: Daten im SPSS Modeler 15 analysieren



Der „Partition“ Node gruppiert die Daten in Test und Training Data. Im Node „incomeRangeID“ werden 

die notwendigen Einstellungen für den Algorithmus vorgenommen. Die beiden rechten Nodes 

dienen der Überprüfung des Ergebnisses. 

Daten exportieren 

Während des dritten Schrittes werden die Data Mining Ergebnisse für das Schreiben in die Datenbank 

vorbereitet. Dabei werden Daten angefügt, unnötige Spalten herausgefiltert und Ergebnisse umbenannt. 

Der letzte Knoten im Stream stellt den Export in die Datenbank dar. Hier ist besonders darauf 

zu achten, dass alle Felder richtig eingestellt wurden, da durch das Ausführen dieses Nodes die Daten 

in der externen Datenbank überschrieben werden könnten. 

Abbildung 1.13: Daten exportieren im SPSS Modeler 15 

Die „Select“ & „Filter“ Nodes reduzieren die Datenmenge auf die benötigten Werte und der letzte 

Node schreibt diese in die Datenbank. 

Zur Überprüfung der Zwischenschritte lässt sich der Stream bis zu jedem Node manuell ausführen. 

Erreicht er den ausgewählten Node stoppt der Prozess. So können aktuelle Fortschritte überprüft und 

korrigiert werden. 

Aktuell müssen alle Data Mining Prozesse noch manuell umgesetzt werden. Es gibt allerdings Möglichkeiten 

diese in den SSIS Service von Microsoft zu integrieren oder durch weitere Module von IBM 

zu automatisieren. 

Im Folgenden wird die konkrete Umsetzung der vier Anwendungsfälle aus dem DV-Konzept beschrieben. 

Dabei werden neben realisierten Konzepten auch Ideen und mögliche Zukunftsszenarien 

beschrieben. Die Streams des SPSS Modeler sind gesammelt in einer Projektdatei gesichert und der 

Dokumentation beigefügt. 

1.5.1 Klassifizierung 

Ziel der Klassifizierung ist es Attribute von Usern zu ermitteln, die entweder nicht vorliegen oder deren 

Klassifizierung von der tatsächlichen Angabe abweicht. 

137



Für diejenigen Attribute, deren Originalwert nicht in der Datenbank vorhanden ist, gibt die Klassifizierung 

einen Hinweis, welche Ausprägung dem User entsprechend wäre. So bietet die Klassifizierung 

eine Möglichkeit fehlende Werte in der Datenbank zu ergänzen. 

Ist der klassifizierte Wert anders als angegeben, ist dies ein Hinweis darauf, dass User unter umständen 

einen anderen Wert präferieren würden. Dies ist insbesondere in Bezug auf Attribute interessant, 

die sich auf den Besitz von Produkten beziehen. So könnte es zum Beispiel dabei helfen User zu identifizieren, 

die aktuell zwar noch kein E-Bike besitzen, potentiell aber zur Gruppe der Interessenten 

gehören. 

Da viele Angaben durch den User freiwillig sind, können bestimmte Attribute durch alle Daten hindurch 

lückenhaft sein. Sowohl für die Darstellung im Rahmen der BI als auch in der Analyse sind 

lückenhafte Datensätze problematisch und es kann daher sinnvoll sein, sie mit den wahrscheinlichsten 

Werten aufzufüllen. 

Es wurden insgesamt sechs Streams gebaut, die für je ein Attribut die Werte schätzen. Die Streams 

sind untereinander fast identisch. Hauptunterscheidung stellt das unterschiedliche „Target Attribut“ 

dar. 

Im Folgenden wird ein Stream beispielhaft für alle dokumentiert: 


Mit den beiden folgenden SQL Statements werden die User und die Routendaten aus der Datenbank 

abgefragt: 

User: 

SELECT 

FROM 

WHERE 

j.ID AS jinengoUserID, u.ID AS userHistoricID, 

u.incomeRangeID, u.familyStatusID, u.ownsPEV, 

u.ownsGasCar, u.ownsEbike, u.publicTransportMember, 

u.railMembershipID, u.carSharingMemberships, 

u.maxDistanceToWalk, u.maxDistanceToBike, 

u.sustainabilityPreference, u.comfortPreference, 

u.costsPreference, j.gender, j.birthdate 

dbo.JinengoUser j, dbo.UserHistoric u 

u.jinengoUserID = j.ID AND u.ID = ( SELECT MAX(ID) FROM 

UserHistoric WHERE jinengoUserID = j.ID) 

Routen: 

SELECT 

userHistoricID, 

138



COUNT(CASE WHEN transportationID = 1 THEN transportationID 

……… 

COUNT(CASE WHEN transportationID = 21 THEN transportationID 

END) AS ICE 

FROM 

GROUP BY 

dbo.Subroute AS q 

userHistoricID 

Das erste SQL-Statement (User) lädt den aktuellsten User aus dem Datawarehouse. Der gleiche User 

kann unter verschiedenen "userHistoric"-Keys mehrfach abgelegt sein. Für die Klassifizierung soll 

aber jeder User nur einmal verwendet in der aktuellsten Ausprägung werden. User die oft ihre Attribute 

ändern und dadurch in mehreren Versionen vorhanden sind, würden ansonsten automatisch einen zu 

hohen Einfluss auf das Ergebnis haben. 

Das zweite Statement (Routen) zählt die Anzahl der Routen pro Verkehrsmittel auf Subroutenebene. 

Über ein "Join" verbunden ergeben die beiden Tabellen den Input für den Algorithmus. Hierbei können 

noch die Typen (Role) zu den einzelnen Attributen zugewiesen (siehe folgende Abbildung) und 

die Partition für das Data Mining erstellt werden. 

139



Abbildung 1.14: Typzuordnung im SPSS Modeler 15 (eigene Abbildung) 

Die Spalte Field repräsentiert die einzelnen Attribute. In der Spalte Measurement wird der Datentyp 

zugewiesen und kann ggf. angepasst werden. In der Spalte Role steht Input für die Input-Parameter. 

Das mit "Target" ausgezeichnete Attribut wird als Ziel für die Klassifizierung verwendet. Mit "None" 

gekennzeichnete Attribute werden ignoriert und "Key" dient der Identifikation der Daten. 


Der Algorithmus für die Klassifizierung ist „exhaustive CHAID“. Um die Stablität des Modells zu 

erhöhen ist Bagging aktiviert. Nach ausprobieren ergab sich ein Wert von 150 Models (tab: Build Options 

Ensembles) als ausreichend um die Aussagekraft des Modells zu maximieren. Dieser Werte 

passte für alle sechs Streams. Muss aber evtl. bei sich ändernden Datenvolumen angepasst werden. 

140



Das gebaute Modell sollte auf jeden Fall mit dem Analyse-Node und dem Evaluation-Node überprüft 

werden. Die genauen Einstellungen können in der Projektdatei eingesehen werden. 

Für die Klassifizierung wird der „exhaustive CHAID“ Algorithmus genutzt. Um die Stabilität des 

Modells zu erhöhen ist "Bagging" aktiviert. Nach ausprobieren ergab sich ein Wert von 150 Models 

(tab: Build Options Ensembles) als ausreichend um die Aussagekraft des Modells zu maximieren. 

Dieser Werte konnte für alle sechs Streams genutzt werden, muss aber evtl. bei sich ändernden Datenvolumen 

angepasst werden. Das gebaute Modell sollte auf jeden Fall mit dem Analyse-Node und dem 

Evaluation-Node überprüft werden. Die genauen Einstellungen können in der Projektdatei eingesehen 

werden. 


Nachdem das Target-Attribut klassifiziert wurde, wird der aktuelle Timestamp als Datum angefügt, 

um in Zukunft feststellen zu können, wann die Prediction durchgeführt wurde. Außerdem wird die 

Beschriftung des Target-Attributs (in diesem Fall „ownsEbike“) in die Spalte „attribut“ geschrieben. 

Dies ist relevant, da alle sechs Streams in dieselbe Tabelle in der Datenbank geschrieben werden. Um 

die einzelnen Predictions auseinander zu halten, dient die Spalte „attribut“ als Indikator. 

Zum Schluss werden unnötige Felder heraus gefiltert und nur die Einträge ausgewählt, bei denen die 

Attribut Ausprägung ursprünglich weder "NULL" noch gleich dem „ValuePredicted“ ist. Zusätzlich 

muss die PredictionConfidence größer als ein zu definierender Grenzwert sein. Dieser Grenzwert kann 

aus der obigen Analyse der Data Mining Ergebnisse ermittelt werden. 

Die Zieltabelle besteht aus folgenden Spalten: „userHistoricID, jinengoUserID, attribut, attributValue, 

attributPrediction, predictionConfidence, predictionDate“. 

1.5.2 Clustering 

Im Rahmen des Clustering werden User zu Gruppen zugeordnet. Mit Hilfe dieser Gruppen können 

User gezielter angesprochen werden und dadurch ihre Response Rate auf bspw. Newsletter Kampagnen 

erhöht werden. Zur Realisierung wurden zwei Typen von Clustern definiert: zum einen ein 

Sustainability Cluster und ein Personen Cluster. Personen Cluster gruppieren User nach ihren persönlichen 

Eigenschaften wie Alter, Geschlecht etc. Diese Gruppen sind insbesondere Hilfreich um die 

User von Jinengo selbst zu analysieren. Fragen wie „Wer nutzt Jinengo und wie oft“ lassen sich mit 

Hilfe dieser Cluster genauer umschreiben. So könnten bestimmte Einkommens und Altersgruppen 

identifiziert werden, die Jinengo besonders häufig oder weniger häufig nutzen. Diese Segmente lassen 

sich im Anschluss z.B. für zielgruppenspezifische Werbung nutzen. 

141



Sustainability Cluster ermöglichen eine trennscharfe Visualisierung der gefahrenen Routen in Bezug 

auf Nachhaltigkeitsaspekte. So lassen sich bspw. Usergruppen mit individuellen Eigenschaften identifizieren, 

die besonders oft nachhaltige Routen wählen. Ein weiterer Anwendungsfall für dieses Custer 

ist die Visualisierung des Fahrverhaltens der Sustainability Cluster in Reports und Dashboards. 

Datenaufbereiten 

Abbildung 1.15: Daten aufbereiten Sustainability Clustering 

Die Datenaufbereitung für die Sustainability Cluster ist etwas umfangreicher, da personenbezogene 

Daten mit Routendaten in Verbindung gebracht werden müssen. Der Node „Data Mining“ spricht den 

gleichnamige View im Datawarehouse an. Dieser View zählt alle von einem User benutzten Verkehrsmittel. 

Die Daten entsprechen dem zweiten SQL Skript (Routen) in dem obigen Abschnitt „Klassifizierung“. 

Der Node „jinen-go@jinengoDataW...“ Liest mit folgendem SQL Statement nachhaltigkeitsbezogene 

Daten des Users aus. 

SELECT 

FROM 

GROUP BY 

r.userHistoricID, sum(r.ecoImpact) as sumEcoImpact, 

sum(r.distance) as sumDistance 

dbo.Subroute r 

userHistoricID 

Zusätzlich zu den Daten auf Subrouten Ebene werden die Daten auf Routen Ebene geladen und über 

die "userHistoricID" gejoint. Im letzten Schritt der Datenaufbereitung werden noch die Typen zugewiesen. 

142



Abbildung 1.16: Daten aufbereiten Personen Cluster 

Die Personencluster sind weniger aufwendig zu importieren. Die User werden mit Informationen aus 

den Tabellen "JinengoUser" und "userHistoric" geladen. Einzige Besonderheit ist, dass in dem sternförmigen 

Node fehlende Werte mit Hilfe eines C/RT Algorithmus ergänzt werden. Eine Analyse der 

Quelldaten hatte ergeben, dass zu viele User ihr Einkommen nicht angegeben haben. Daher war es 

nötig, das Einkommen mit Hilfe eines Klassifizierungsalgorithmus zu schätzen. 


Abbildung 1.17: Daten analysieren Sustainability Cluster 

Der verwendete Algorithmus heißt TwoStep. Mit diesem Algorithmus konnte auf unseren Daten das 

robusteste Ergebnis erzielt werden, wie in der obigen Abbildung zu sehen ist. Der große Nachteil des 

Algorithmus ist jedoch, dass in Bezug auf Nachhaltigkeitsaspekte nicht mehr als zwei Cluster gefunden 

werden konnten. 

143



Im Gegensatz dazu wurde für den Personencluster der Algorithmus K-Means verwendet. Das Ergebnis 

ist zwar nicht so Robust (zu vergleichen ist die Cluster Quality in den beiden Abbildungen), allerdings 

bietet es eine höhere Heterogenität der Cluster. 


Abbildung 1.18: Daten analysieren Personen Cluster 

Der Export ist in beiden Clustern identisch. In einem Node können die Cluster beschriftet und beschrieben 

werden. Ein Timestamp wird hinzugefügt und alle überflüssigen Felder werden gefiltert. Die 

Ergebnisse des Personenclusters werden in der Tabelle "dbo.UserAttributeClustering" in dem Data- 

Warehouse gespeichert, während die Sustainability Cluster mit derselben Struktur in der Tabelle 

"dbo.UserSustainabilityClustering" gespeichert werden. 

1.5.3 Assoziation 

Ziel der Assoziationsanalyse ist es Regeln in den Daten zu entdecken, die ein Verhalten der User beschreiben. 

Die Regeln können für verschiedene Zwecke genutzt werden. 

Ein Anwendungsfall könnte sein, dass Interesse an einem Ebike für unterschiedliche Nutzer zu schätzen, 

je nachdem welche Bedingungen sie erfüllen. Hierfür werden sowohl personenbezogene Daten, 

Routendaten als auch ökologische Inputparameter für den Algorithmus gewählt. Die gefundenen Regeln 

werden dann auf den gesamten Datensatz angewandt und für jeden gefundenen Fall in die Datenbank 

zurückgeschrieben. 


144



Abbildung 1.19: Daten aufbereiten Assoziationsanalyse 

Neben den normalen Operationen, die schon aus den Schritten Klassifizierung und Clustering bekannt 

sind, ist eine besondere Bedingung für den Assoziationsalgorithmus, dass dieser nur boolesche Attribute 

oder Attribute mit wenigen distinkten Werten akzeptiert. Größere Wertespektren in einem Attribut 

sind nicht möglich. Daher werden im Node „Binning“ diese Attribute in Quartile zusammengefasst. 


Abbildung 1.20: Daten analysieren Assoziation 

Dieses Schaubild enthält zwei Analyse Nodes. Der erste entdeckt mit Hilfe des Apiori-Algorithmus 

Regeln in den Daten. Auf Basis dieser Regeln wird ein zweiter Analyse Node erstellt der einen Entscheidungsbaum 

basierend auf den gefunden Regeln darstellt. Der zweite Node (ownsGasCar) ist, bei 

sich ändernden Regeln (bspw. durch ein neues Zielattribut), neu aus dem Menu des Apiori-Nodes zu 

erstellen. Dies ist aus dem Kontext Menu unter „Generate -> Rule Set“ möglich. 

145




Abbildung 1.21: Daten exportieren Assoziationsanalyse 

Die zu den Regeln passenden Datensätze werden im Beispiel „ownsGasCar“ auf diejenigen reduziert, 

bei denen die Regel für den Besitz eines GasCar vorhanden sind, die akute Ausprägung bei dem User 

aber 0 oder null ist. Folglich entweder nicht angegeben oder tatsächlich nicht vorhanden sind. Mit 

einem Datum werden die Ergebnisse dann in das Data Warehouse (dbo.AssociationResults) geschrieben. 

1.6 Endanwender-Reporting Frontend 

Im nachfolgenden Kapitel wird der Aufbau und die Realisierung des Endanwender Frontends erläutert. 

Anhand von Screenshots werden hierzu die einzelnen Komponenten der Web-Oberfläche dargestellt 

und inhaltlich beschrieben. Darauf aufbauend wird die technische Realisierung unter Einbeziehung 

der verwendeten Technologien erläutert. Hierbei wird insbesondere auf den Aufbau der JavaScript 

Anwendung eingegangen. 

1.6.1 Aufbau der Weboberfläche 

Anmerkung: Die Weboberfläche lässt sich live unter der Adresse http://reporting.js-developer.de/ 

betrachten. Mit den folgenden Anmeldeinformationen kann man sich zu Testzwecken am System anmelden. 

(User: beccy@brinckmann.com / Passwort: beccy32) 

Die nachfolgenden Screenshots zeigen die fertig entwickelte Weboberfläche zur Darstellung von Endanwender 

Reports. 

146



Abbildung 1.22: Screenshot CO2-Emission Endanwender 

In der obigen Abbildung 1.22 wird dem Nutzer seine monatliche CO2-Emission über ein Jahr in Form 

eines Charts (blaue Linie) dargestellt. Neben der CO2-Emission kann der Nutzer in der grünen Menüleiste 

auch drei weitere Kennzahlen (Reisekosten, Reisestrecke und Reisezeit) zur Betrachtung auswählen. 

Sobald mit der Maus über einen der Menüpunkte gefahren wird, klappt animiert ein Untermenü 

aus. In diesem können bis zu vier verschiedene, kennzahlenspezifische Darstellungsvarianten gewählt 

werden: die monatlichen CO2-Emissionen, die durchschnittlichen CO2-Emission, die CO2- 

Bilanz (Darstellung des Einsparpotentials) und der Anteil der Verkehrsmittel. 

In der oberen rechten Ecke der Abbildung 1.22 sieht man in blau, das Kristina als Vergleichsperson 

ausgewählt wurde. Kristinas CO2-Emission wird zusammen mit dem Chart des aktiven Nutzers als 

roter Graph dargestellt. 

147



Abbildung 1.23: Screenshot Verteilung Verkehrsmittel 

Die Abbildung 1.23 stellt die CO2-Emission des Nutzers verteilt auf alle genutzten Verkehrsmittel 

dar. Deutlich sieht man auf der linken Seite in Rot, dass die Nutzerin Becca einen Großteil ihrer Strecken 

mit dem PKW zurücklegt, während ihre Freundin Korinna (rechts abgebildet) deutlich mehr 

Bahn und öffentlich Verkehrsmittel nutzt. Beccas häufige Autonutzung führt zu einem schlechten 

Wert in ihrer CO2-Bilanz (vgl. Abbildung 1.24) 

Abbildung 1.24: Screenshot C02-Einsparpotential 

Die Abbildung 1.24 zeigt die CO2-Bilanz von Becca. Der linke Graph stellt dabei ihre CO2-Emission 

über die Zeit dar, wobei die blaue Kurve die tatsächlichen CO2-Emission von Becca abbildet. Die 

gepunktete rote Linie zeigt den höchst möglichen Wert (wäre sie immer Auto gefahren). Die gepunk- 

148



tete grüne Linie den kleinsten möglichen Wert, wenn sie also immer das Verkehrsmittel mit der geringsten 

Emission gewählt hätte. Man erkennt deutlich, dass sich ihre Kurve fast immer am oberen 

roten Rand befindet, sie also relativ viel CO2 im Vergleich zu ihren möglichen Alternativrouten verbraucht. 

Die rechte Grafik fasst die Bilanz noch einmal kompakt in Form eines animierten Nachhaltigkeitstachos 

zusammen. Dieser zeigt, dass Becca nur gut 25 Prozent ihres Einsparpotentials nutzt und 

sie sich daher noch deutlich nachhaltiger fortbewegen könnte. 

Sollte der Nutzer genügend Information über sein Fahrverhalten gesammelt haben, kann er sich über 

den oberen rechten „Abmelden“-Button wieder aus der Anwendung ausloggen. 

1.6.2 Verwendete Technologien 

Bei den verwendeten Technologien für die Weboberfläche wurden ausschließlich die drei Webstandards 

JavaScript, HTML und CSS verwendet. Die Charts werden zudem, im vom W3C empfohlenen 

SVG Format, live im Browser gezeichnet. 

Hervorzuheben ist, dass durch den Einsatz dieser Technologien alle grafischen Elemente der Weboberfläche, 

also Navigation und Chart vollständig ohne Bilder auskommen. Dies verbessert nicht nur 

die Ladezeiten, sondern sorgt auch dafür, dass die Charts auf hochauflösenden Retina-Displays stets 

scharf und in optimaler Auflösung dargestellt werden. 

Das animiert aus- und einklappende Navigationsmenüs, sowie die Farbverläufe der Buttons wurden 

ausschließlich mit CSS3 realisiert und entsprechen den neuesten Standards der Webentwicklung. 

Aufbau der JavaScript Anwendung 

Ein Großteil der Anwendung basiert auf JavaScript. Während HTML nur ein grobes Gerüst für den 

Aufbau vorgibt, wird der weitere Inhalt dynamisch über JavaScript geladen. Dabei steuert JavaScript 

unter anderem die Menüinteraktion, das Laden der Nutzer- und Kennzahlendaten und sowie das 

Zeichnen der Charts. Die Anwendung wird hierfür in drei Module unterteilt. Diese Dreiteilung sorgt 

für eine Trennung von Logik, Datenmanagement und Zeichnung der Charts. 

Großgeschriebene JavaScript Dateien entsprechen Klassen. Für unterschiedliche Aufgaben existieren 

verschiedene Klassen die von einer zentralen „logic.js“ Datei durch „new Klassenname“ instanziiert 

werden. Die Verwendung von Klassen ermöglicht es Techniken der objektorientierten Programmierung 

auf JavaScript zu übertragen. Hierdurch wird unter anderem eine Modularisierung ermöglicht, 

die den Austausch- und die Wiederverwendung einzelner Anwendungskomponenten erleichtert. 

149



Folgende Dateien wurden für die Realisierung der Webanwendung entwickelt (Vgl. Tabelle 1.5). Die 

Tabelle entspricht dabei den Anforderungen des Fachkonzeptes (Vgl.: Fachkonzept 5.1.1). 

Anmerkung: Die nachfolgenden Dateien können auch online in dem von der Projektgruppe genutzten 

Git-Repository betrachtet werden. Für die Ansicht der JavaScript Dateien einfach folgende URL im 

Browser 

eingeben: 

https://github.com/lars2510/reportingservice/tree/master/src/main/webapp/resources/js 

Dateiname 

logic.js 

JinengoChart.js 

GraphHandler.js 

PieHandler.js 

BalanceHandler.js 

Beschreibung 

Das Hauptmodul ist für das initiale Laden der Nutzerdetails und Freundeslisten 

über den Webservice zuständig. Zudem erzeugt es die Instanzen aller 

notwendigen JavaScript Klassen und bindet diese an die jeweiligen Event- 

Listener. 

Die Listener sorgen dafür, dass bei einem Klick auf das Navigationsmenü 

oder die Freundesliste das entsprechende Handler-Objekt die Datenabfrage 

und das Zeichnen der angefragten Charts übernimmt. 

Das Chartmodul übernimmt die Kommunikation mit dem Webservice und 

erfragt die für den jeweiligen Chart benötigten Daten. 

Bei erfolgreicher, asynchroner Datenabfrage der Nutzer- und Vergleichsdaten 

übergibt das Modul die Daten an den zuständigen Charthandler. 

Die Charthandler übernehmen die Zeichnung der Charts anhand der übermittelten 

Daten. Die drei Handler unterscheiden sich hauptsächlich in der 

Art der zu zeichnenden Charts (Graph, Kuchendiagramm, Nachhaltigkeitsbilanz). 

Die Klassen sind zudem für die Aufbereitung der Daten verantwortlich, so 

dass diese optimal für die Konfiguration des Charts genutzt werden können. 

So werden Monate von den Zahlen 1-12 in die passenden Monatskürzel 

Jan-Dez umgewandelt. Zudem erfolgt im „BalanceHandler“ die Berechnung 

des Wertes für den Nachhaltigkeitstacho, da dieser nur indirekt in der Datenbank 

vorhanden ist. 

Für die finale Zeichnung des Charts wird die Bibliothek Highcharts genutzt, 

welche mit dem konfigurierten Chart Objekt instanziiert wird. 

Tabelle 1.5: JavaScript Module Endanwender Frontend 

Die Daten erhält die Weboberfläche über JavaScript gesteuerter Ajax-Anfragen an den Webservice. 

Nach erfolgreicher Abfrage erhält die Weboberfläche die Daten im JSON-Format. Auf Grundlage 

dieser Daten werden dynamisch die Charts auf der Webseite dargestellt. Ajax ermöglicht es dabei, nur 

die Charts neu zu zeichnen, ohne den Inhalt der gesamten Seite neu laden zu müssen. 

Wie bereits erläutert werden die Daten zur Darstellung der Charts über eine Ajax-Anfrage an den 

Webservice geladen. Ajax ermöglicht es dabei, parallele Anfragen an den Webservice zu stellen und 

so Zeit bei der Datenübertragung zu sparen. Ein kurzer Ausschnitt aus dem JavaScript Code soll dies 

verdeutlichen: 

$.when( 

$.ajax({ 

150



url: graphData.handler.userApiUrl, 

data: requestData 

}), 

$.ajax({ 

url: graphData.handler.compareApiUrl, 

data: friendData 

}) 

).done(function(dataUser, dataFriend){ 

graphData.handler.draw(dataUser, dataFriend); 

}).fail(function(err) { 

console.log("Es konnte keine Verbindung zur Jinengo API aufgebaut 

werden. Statuscode " + err.status); 

}); 

Das Codebeispiel zeigt wie Daten parallel sowohl für den Nutzer, als auch für seinen Freund über die 

API abgefragt werden. Hierzu wartet die mit „$.when“ gekennzeichnete Funktion darauf, dass die 

beiden gleichzeitig an den Webservice gestellten Ajax-Anfragen erfolgreich waren. Ist dies der Fall 

wird der durch „$.done“ gekennzeichnete Code-Bereich aufgerufen und der Chart auf Basis der Daten 

gezeichnet, kam es zu einem Fehler wird der Bereich „$.fail“ aufgerufen und eine Fehlermeldung auf 

der Konsole des Browsers ausgegeben. 

Die durch das $-Zeichen gekennzeichneten Funktionen werden durch die Bibliothek jQuery bereitgestellt. 

Neben Ajax-Anfragen lässt sich über jQuery auch der Inhalt der HTML-Seite dynamisch aktualisieren. 

JavaScript bietet zwar auch native Funktionen, die dies übernehmen könnten, jedoch wäre 

bedeutend mehr Code hierfür erforderlich und die Eigenarten unterschiedlichster Browserhersteller 

müssten durch zahlreiche Ausnahmen berücksichtigt werden. 

1.7 Reporting-API 

Zur Realisierung der Reporting API als Webservice wurde das Spring MVC Framework verwendet. 

Das Kürzel MVC beschreibt die Dreiteilung der Anwendung in „Model“, „View“ und „Controller“. 

Der Controller übernimmt dabei den Kontrollfluss zwischen einer Ressource, die ein Nutzer über 

HTTP abfragt, und den bereitzustellenden Datenobjekten (Model), die der Abfrage zugeordnet sind. 

151



Quelle: Springsource.org (o.J.) 

Abbildung 1.25: Aufbau einer Spring MVC Anwendung 

Der Anwendungsaufbau und Funktionsfluss der Spring MVC Anwendung ist in Abbildung 1.25 dargestellt. 

Eine Anfrage an die Anwendung startet dabei immer mit einem eindeutigen HTTP-Request, 

welcher von dem Java-Servlet (Front-Controller) an den zuständigen Controller weitergeleitet wird. 

Der zuständige Controller hat die Verantwortung, ein Datenmodell mit den vom Request angeforderten 

Daten zu erstellen und diese auszuliefern. 

Für die Darstellung der Daten ist das View-Template verantwortlich. Dieser Schritt wird bei der Erstellung 

einer REST-API übersprungen, da das Ziel der Schnittstelle nicht die Darstellung, sondern die 

Auslieferung der benötigten JSON-Daten liegt. 

Da es sich bei dem Webservice um eine reine Schnittstelle zur Datenbereitstellung handelt lag der 

Großteil des Entwicklungsaufwandes bei Model und Controller. Die View Komponente wurde lediglich 

für die Bereitstellung eines HTML-Grundgerüstes für das Web-Reporting Frontend genutzt. 

1.7.1 Controller und Service Klassen 

Die Controller Klassen der Anwendung sind dafür zuständig eingehende HTTP-Requests eindeutig 

einer Ressource zuzuordnen. Hierfür werden mit Hilfe von Java-Annotationen die Zuständigkeiten der 

Controller eindeutig definiert. Eine Beispiel-Annotation aus der Anwendung sieht wie folgt aus: 

@RequestMapping("/api/user/transportation") 

Wird eine Klasse oder eine Funktion mit dieser Annotation gekennzeichnet, werden alle eingehenden 

Anfragen die der URI http://anwendungsname/api/user/transportation entsprechen, der Funktion mit 

152



dieser Annotation zugeordnet. Die Funktion übernimmt dann die Aufgabe mit Hilfe von Service Klassen 

mit der Datenbank zu kommunizieren und die angefragte Ressource bereitzustellen. 

Folgende Controller (Vgl. Abbildung 1.26 & Abbildung 1.27) wurden für die API implementiert. Sie 

entsprechen den Anforderungen der Schnittstellenspezifikation aus dem DV-Konzept. 

UserApiController 

Dieser Controller ordnet die Anfrage nach nutzerspezifischen Kennzahlen den entsprechenden Funktionen 

zu. Zur Abfrage der Daten aus der Datenbank nutzt der Controller die beiden Service Klassen 

„UserDao“ für Nutzerdetails und „UserFiguresDao“ für Kennzahlen. Das Suffix Dao der Service 

Klassen steht konventionell für „DataAccesObject“, also ein Objekt, welches für den Datenbankzugriff 

verantwortlich ist. 

Die Service Klassen sind für die Kommunikation mit der Datenbank verantwortlich. Sie beinhalten die 

SQL-Abfragen und füllen das zugehörige Model mit Daten. Zudem berechnen sie Kennzahlen, die nur 

indirekt in der Datenbank vorhanden sind wie Beispielsweise das CO2-Einsparpotential des Nutzers. 

UserDao 

Diese Service-Klasse ist für den Zugriff auf nutzerspezifische Details wie Name, E-Mail und Freundeslisten 

zuständig. Zudem regelt sie den Zugriff und die Speicherung der Authentifizierungsdaten des 

Nutzers. 

UserFiguresDao 

Diese Service Klasse ist für den Zugriff auf die Nutzerrelevanten Kennzahlen aus der Datenbank verantwortlich. 

153



Abbildung 1.26: UML User Controller API 

Die Abbildung 1.26 stellt die Architektur und die Funktionen des UserApiControllers und der beiden 

Service Klassen dar. Die Funktionen sind ausführlich im Quellcode dokumentiert. Ein kurzer Auszug 

aus dem Programm soll jedoch einen Eindruck über den Aufbau der Controller Funktionen vermitteln: 

Im Folgenden ist beispielhaft die Implementierung der Funktion im Controller aufgeführt, die alle 

Kennzahlen aufgeschlüsselt nach Verkehrsmitteln liefert: 

@RequestMapping(value = "/transportation", method = RequestMethod.GET) 

public @ResponseBody List getTransportation( 

@RequestParam(value="keyFigure") String keyFigure) { 

return userFiguresDao.getTransportation(keyFigure)); 

} 

Die erste Zeile Ordnet der URI „/transportation“ die Funktion in Zeile 2 „getTransportation“ zu. Als 

Parameter wird die Art der Kennzahl (Zeile 3) übergeben. Die Service-Klasse „userFiguresDao“ ist 

dann für das Abfragen der Daten und erstellen des Datenmodels verantwortlich. Das Ergebnis wird 

vom Controller zurückgegeben. Der Zusatz „@ResponseBody“ in Zeile 2 konvertiert dabei das Model 

in ein JSON Objekt, so dass die Rückgabe direkt von der JavaScript Anwendung für Endanwender 

Reports weiterverarbeitet werden kann. 

154



PlatformApiController 

Dieser Controller ordnet die Anfrage plattformspezifischer Kennzahlen den entsprechenden Funktionen 

zu. Der Funktionsumfang des PlatformApiController ist eine Teilmenge des „UserApiController“, 

jedoch wird eine andere Service Klasse für den Datenzugriff genutzt, da die Kennzahlen andere Datenbanktabellen 

benötigen. 

PlatformFiguresDao 

Diese Service Klasse ist für den Zugriff auf aggregierte Durchschnittswerte der Jinengo Plattform 

verantwortlich. Abbildung 1.27 zeigt den Aufbau: 

AuthenticationController 

Abbildung 1.27: UML Platform Controller API 

Vor Nutzung der API muss sich jeder Nutzer am System authentifizieren. Die Umsetzung entspricht 

dabei den konzeptionellen Vorgaben des Konzeptes und wurde in großen Teilen durch Spring Komponenten 

umgesetzt. Die „security-context.xml“ beinhaltet alle notwendigen Konfigurationen. 

Damit sich neue Nutzer registrieren und ihr eigenes Passwort festlegen können, wurde ein entsprechender 

Controller für die API implementiert. Der Aufbau ist in Abbildung 1.28 dargestellt: 

155



Abbildung 1.28: UML Authentication Controller API 

Die Funktion „savePassword“ des „AuthenticationController“ sorgt dafür, dass das Passwort verschlüsselt, 

zusammen mit der eindeutigen E-Mail Adresse des Nutzers in der Datenbank abgelegt 

wird. Zusätzlich wird jedem Nutzer beim Anlegen eine Rolle zugewiesen. Über die Rollte lässt sich 

durch den Administrator festlegen, auf welche Bereiche des Webservices der Nutzer Zugriff erhält. 

1.7.2 Datenmodel 

Die Datenbankmodelle die eine Webanwendung zur Darstellung von Kennzahlen benötigen, werden 

mit Hilfe der Java Persistence Api (JPA) in Java abgebildet. Eine Tabelle wird dabei durch die Annotation 

@Entity gekennzeichnet. 

Folgende Datenbanktabellen wurden als Java-Model implementiert: 

156



Abbildung 1.29: UML Model Klassen API 

Nachfolgend eine Erläuterung der einzelnen Modelle und ihrer Kennzahlen. 

AggrUserFigure 

Modell der aggregierten Nutzer Kennzahlen. Aggregiert auf Monatsbasis und mit Erweiterung der 

jeweils besten oder schlechtesten, möglichen Routenalternative bezogen auf die jeweilige Kennzahl. 

157



Eigenschaft Wertebereich Beschreibung 

id Integer Eindeutiger Primärschlüssel 

jinengoUserID Integer Eindeutige Nutzer ID 

year Integer Jahr der aggregierten Kennzahl 

month Integer Monat der aggregiert Kennzahl 

need String Grund der Reise 

countRoutes Integer Anzahl der Routen im jeweiligen Monat 

countSubroutes Integer Anzahl der Subrouten im jeweiligen Monat 

sumDistance Float Summe der zurückgelegten Strecke 

sumTime Integer Summe der benötigten Zeit 

sumTimeBestOption Integer Summe der benötigten Zeit bei Betrachtung 

der jeweils schnellsten Routenalternative 

sumTimeWorstOption Integer Summe der benötigten Zeit bei Betrachtung 

der jeweils langsamsten Routenalternative 

sumTimeUsable Integer Summe der nutzbaren Zeit (z.B. bei Fahrt 

mit dem Zug) 

sumTimeUsableBestOption Integer Summe der nutzbaren Zeit bei Betrachtung 

der jeweils maximalen Routenalternative 

sumTimeUsableWorstOption Integer Summe der nutzbaren Zeit bei Betrachtung 

der jeweils minimalen Routenalternative 

sumCosts Float Summe der Routenkosten 

sumCostsBestOption Float Summe der Routenkosten bei Betrachtung 

der jeweils günstigsten Routenalternative 

sumCostsWorstOption Float Summe der Routenkosten bei Betrachtung 

der jeweils teuersten Routenalternative 

sumEcoImpact Float Summe der CO-Emission 

sumEcoImpactBestOption Float Summe der CO-Emission bei Betrachtung 

der jeweils geringsten Emission unter den 

Routenalternativen 

sumEcoImpactWorstOption Float Summe der CO-Emission bei Betrachtung 

der jeweils höchsten Emission unter den 

Routenalternativen 

cluster String Routencluster, erstellt über Data-Mining 

AggrUserFigurePerTransportation 

Tabelle 1.6: API Datenmodell aggregierte Nutzerkennzahlen 

Model der aggregierten Kennzahlen auf Monatsbasis und aufgeschlüsselt nach Verkehrsmittel. 

158





jinengoUserID Integer Eindeutige Nutzer ID 

year Integer Jahr der aggregierten Kennzahl 

month Integer Monat der aggregierten Kennzahl 

transportation String Verkehrsmittel 

need String Grund der Reise 

countRoutes Integer Anzahl der Routen 

countSubroutes Integer Anzahl der Subrouten 

sumDistance Float Summe der zurückgelegten Strecke 

sumTime Integer Summe der benötigten Zeit 

sumTimeUsable Integer Summe der nutzbaren Zeit 

sumCosts Float Summe der Reisekosten 

sumEcoImpact Float Summe der CO2-Emission 

cluster String Routencluster, erstellt über Data-Mining 

Tabelle 1.7: API Datenmodell aggregierte Verkehrsmittelkennzahlen 

UserAuthenticationModel 

Model der relevanten Authentifizierungsdaten eines Jinengo Nutzers. Das Model wird zur Speicherung 

der Nutzerdaten in der Datenbank benötigt. Die Daten werden genutzt um den Anwender später 

bei der Nutzung des Webservice authentifizieren zu können. 

Ein mit E-Mail und Passwort authentifizierter Nutzer kann eindeutig seiner Nutzer ID zugeordnet 

werden. Dies stellt sicher, dass ein Nutzer nur die für ihn relevanten Daten angezeigt bekommt und 

keinen Zugriff auf Bereiche erhält die nicht seiner Rolle/Berechtigung entsprechen. 


userEmail String Eindeutige E-Mail Adresse 

userPassword String Vom Nutzer festgelegtes Passwort. Wird beim Speichern in 

der Datenbank in ein sicher verschlüsseltes Passwort konvertiert 

(SHA-224 Hash). 

userRole String Nutzerrolle. Steuert die Zugriffsrechte auf den Webservice. 

JinengoUser 

Tabelle 1.8: API Datenmodell Nutzerauthentifizierung 

Das Jinengo User Model enthält relevante Nutzerinformationen, die, nach der Authentifizierung über 

E-Mail und Passwort, eindeutig dem Nutzer zugeordnet werden können. Die Nutzer ID kann dabei die 

159



Verbindung zu den relevanten Routendaten herstellen. Die Daten werden unter anderem vom Webinterface 

genutzt. 


id Integer Eindeutige Nutzer ID 

timeRegistered Date Registrierungsdatum 

timeInactive Date Zeit seit dem Nutzer inaktiv ist 

name String Name des Nutzers 

gender Integer Geschlecht 

email String Eindeutige E-Mail des Nutzers 

birthdate Date Geburtsdatum 

Tabelle 1.9: API Datenmodell Nutzerdetails 


Die Tabelle enthält eine eindeutige Zuordnung zwischen Nutzer ID und Freundes ID. So kann für 

einen eingeloggten Nutzer eine Ausgabe der aktuellen Freunde erfolgen. Das Webinterface ermöglicht 

zudem den Vergleich der eigenen Kennzahlen, mit denen der eingetragenen Freunde. 



jinengoUserID_user Integer ID des Nutzers 

jinengoUserID_friend Integer ID des Freundes 

Tabelle 1.10: API Datenmodell Freundesliste 

1.7.3 Konfiguration der Anwendung 

Die Webservice Anwendung läuft in einem Tomcat Container. Damit dieser mit eingehenden HTTP 

Anfragen umgehen kann, müssen einige Einstellungen getroffen werden. Die Standard Tomcat Konfiguration 

befindet sich in der web.xml Datei. Daneben werden noch drei weitere, Spring-spezifische 

XML Dateien verwendet. Diese sind unter anderem für die Weiterleitung der Anfragen, die Sicherheit 

und die Datenbankkonfiguration verantwortlich. Die XML-Dateien werden nachfolgend erläutert: 

web.xml 

Die Standardkonfiguration für den Tomcat Web-Container. Alle eingehenden Anfragen werden durch 

die web.xml an die verantwortlichen Ressourcen weitergeleitet. Hierfür wird unter anderem der Ort 

der servlet-context.xml angegeben, die den zentralen Spring Servlet Container definiert. Alle eingehenden 

Anfragen werden an diese Datei weitergeleitet. 

160



Sollte eine Anfrage an keine passende Ressource weitergeleitet werden können, wird zudem eine 

Standard 404 JSP-Seite definiert, welche dem Nutzer eine entsprechende Fehlermeldung liefert. 

Neben der web.xml werden drei Spring-spezifische Kontext-Dateien definiert: 

Servlet Context 

 

 

 

Definiert den Ort der Java Controller-Klassen die für eingehende Anfragen verantwortlich 

sind. Controller-Klassen werden durch die Annotation @Controller gekennzeichnet. 

Definiert den Ordner der Views, die für die Darstellung der vom Controller zugeordneten Modelldaten 

verantwortlich sind. 

Definiert das Ressourcen Verzeichnis, in welchem sich die JavaScript und CSS Dateien befinden. 

Database Context 

 

 

 

Definiert das Verzeichnis in dem nach Datenbankmodellen, die durch die Java Annotation 

@Components gekennzeichnet sind, gesucht werden soll. 

Definiert den Ort der „Properties“-Datei. Diese beinhaltet Login Information zur Datenbankauthentifizierung. 

Definiert die Spring-Objekte, welche die Verbindungen zu den jeweiligen Datenbanksystemen 

verwalten. 

Security Context 

 

 

Authentifiziert einen Nutzer bei der Anmeldung. Dabei wird geprüft, ob Passwort und E-Mail 

mit den in der Datenbank hinterlegten Daten übereinstimmen. Hierfür wird eine SQL Anfrage 

an die operationale Datenbank definiert. 

Definiert die Zugriffsrechte für den Webservice. Dabei können unterschiedlichen URLs unterschiedlichen 

Rollen zugeordnet werden. 

1.8 Reporting mit SSRS 

Auf dem PGBI-Server wurden mit den SQL Server Reporting Services (SSRS) sechs verschiedene 

Dashboards sowie Reports erstellt, die unterschiedliche Anforderungen abdecken. Im Folgenden werden 

der Aufbau sowie die Administration dieser Dashboards und Reports dokumentiert. 

161



1.8.1 Aufbau der Reports & Dashboards 

Anmerkung: Die Reports und Dashboards lassen sich über den Internet Explorer aufrufen. Befindet 

man sich mit einer Remotedesktopverbindung auf dem PGBI-Server, ist die Adresse 

„http://localhost/Reports“ aufzurufen. Alternativ lässt sich – unter der Voraussetzung eines VPN- 

Tunnels zur Universität Oldenburg – auch der lokal installierte Internet Explorer verwenden. Die 

aufzurufende Adresse lautet dann „http://134.106.13.63/Reports“. Das Login erfolgt dann mit einem 

Windowsbenutzer des PGBI-Servers, z.B. Benutzer „PGBI\PBoewe“ und Passwort „pgbi32!“ (siehe 

Abbildung Abbildung 1.30). 

Die Reporting-Anwendung läuft vergleichsweise langsam. Während der Nutzung ist daher zum Teil 

mit größeren Wartezeiten zu rechnen. 

Abbildung 1.30: Anmeldung zu den Reporting-Services mit dem Internet Explorer 

Nach der Anmeldung und einem Klick auf „Reports und Dashboards“ werden die 6 angelegten Elemente 

aufgelistet (siehe Abbildung 1.31). Zu Beginn bietet sich der Start von „Dashboard Überblick“ 

an, da von diesem Dashboard auf alle anderen Elemente verlinkt wird. 

162



Abbildung 1.31: Anmeldung zu den Reporting-Services mit dem Internet Explorer 

Die Abbildungen auf den kommenden Seiten stellen die einzelnen Dashboards und Reports dar. Alle 

Reports und Dashboards mit Ausnahme des Überblick-Dashboards lassen sich durch die Angabe von 

Parametern steuern. Diese sind im Internet Explorer allerdings zunächst ausgeblendet und können über 

den Button am oberen Bildschirmrand eingeblendet werden. 

163



Abbildung 1.32: Screenshot des SSRS-Dashboards „Jinengo-Überblick“ 

Abbildung 1.33: Screenshot des SSRS-Dashboards „Clusteranalyse“ 

Abbildung 1.34: Screenshot des SSRS-Dashboards „Orte in Oldenburg“ 

164



Abbildung 1.35: Screenshot des SSRS-Reports „Nutzung der Plattform“ 

Abbildung 1.36: Screenshot des SSRS-Reports „Reisekennzahlen (Zeit & Verkehrsmittel)“ 

165



Abbildung 1.37: Screenshot des SSRS-Reports „Reisekennzahlen (Zeit & Präferenz)“ 

1.8.2 Administration der Reports & Dashboards 

Anmerkung: Zur Administration der Reports und Dashboards ist das „Microsoft Visual Studio“ auf 

dem PGBI-Server zu starten und das Projekt „JinengoReports.sln“ zu öffnen. Dieses findet sich unter 

dem Dateipfad „C:\Users\PBoewe\Documents\Visual Studio 2010\Projects\JinengoReports“. 

Über den Projektmappen-Explorer der Reporting Services lassen sich die einzelnen Reports und 

Dashboards administrieren. Alle Reporting-Elemente können dabei auf die global definierten Datenquellen 

„JinengoSQL“ (relationales Data Warehouse) und „JinengoSSAS“ (multidimensionales Data 

Warehouse), sowie auf zwei global definierte Datensätze, zurückgreifen (siehe Abbildung 1.38). Spezifische 

Attribute (u.a. Parameter, Datenquellen und Datensätze) wurden des Weiteren auf Berichtsebene 

angelegt (siehe Abbildung 1.39). 

166



Abbildung 1.38: Projektmappen-Explorer des Visual Studio für SSRS 

Abbildung 1.39: Beispiel für spezifische Berichtsdaten im Visual Studio 

1.9 Reporting mit QlikView 

Bei der Software QlikView handelt es sich um eine Business-Discovery-Plattform mit der eine Verbindung 

zu nahezu jeder Datenquelle aufgebaut werden kann. So lassen sich die Daten in gewünschte 

Zusammenhänge bringen und Visualisieren. Die Software ist als Personal Edition kostenlos unter folgendem 

Link erhältlich: http://www.qlikview.com/de/explore/experience/free-download 

Nach der Installation kann die Software direkt genutzt werden. Nach dem Start drückt man in der Navigationsleiste 

des Programms auf den Neuanlage Knopf . Falls dann ein Dialog zur Datenquellenauswahl 

auftaucht beendet man diesen durch das Betätigen der „Abbrechen“ Schaltfläche. Anschließend 

sollte das Programm wie in Abbildung 1.40 aussehen. 

167



Abbildung 1.40: QlikView Basisansicht 

Nun wählen sie in der Navigationsleiste „Datei“ und dort dann „Skript bearbeiten …“. Zur Verbindung 

mit dem Datenbankserver müssen in das Skript folgende Zeilen eingefügt werden: 

OLEDB CONNECT32 TO [Provider=SQLOLEDB.1;Persist Security Info=True;User 

ID=jinengo;Initial Catalog=JinengoOperationalCRM;Data Source=134.106.13.63;Use Procedure 

for Prepare=1;Auto Translate=True;Packet Size=4096;Workstation ID=THEES- 

LAPTOP;Use Encryption for Data=False;Tag with column collation when possible=False] 

(XPassword is HEKLJYdMCLaGDZEEMH); 

OLEDB CONNECT32 TO [Provider=SQLOLEDB.1;Persist Security Info=True;User 

ID=jinengo;Initial Catalog=JinengoDataWarehouse;Data Source=134.106.13.63;Use Procedure 

for Prepare=1;Auto Translate=True;Packet Size=4096;Workstation ID=THEES- 

LAPTOP;Use Encryption for Data=False;Tag with column collation when possible=False] 

(XPassword is dKYZKYdMCLaGDZEESA); 

Der Rechner, von dem aus auf die Datenbank zugegriffen werden soll, muss im Netzwerk der Universität 

Oldenburg direkt angemeldet sein oder über einen VPN Tunnel dazu verbunden werden. 

Anschließend muss im Skript bestimmt werden, welche Daten auszulesen sind und wie diese unter 

QlikView benannt werden. Exemplarisch ist eine solche Definition in der Abbildung 1.41 für die Tabelle 

„Subroute“ dargestellt. 

Abbildung 1.41: Auszug aus dem "Load-Skript" in QlikView 

Die aufgeführten Attribute nach dem Schlüsselwort „LOAD“ entsprechen den Spaltenbezeichnungen 

in der gewünschten Datenbanktabelle, während die Ausdrücke hinter dem Schlüsselwort „as“ die Be- 

168



zeichnungen sind, welche die Spalten unter QlikView tragen. Der auf das Schlüsselwort „SQL“ folgende 

Code bestimmt aus welcher Tabelle die Daten zu laden sind. 

Anschließen werden die Daten mit der Zeile „Store tempSubrout into [..\Subroute.qvd]“ gespeichert. 

Mit QlikView lassen sich auf diese Weise mit den Daten anschließend unzählige Berechungen durchführen 

und die Ergebnisse können graphisch aufbereitet werden. Wie so ein solches Dashboard aussehen 

kann wird in Abbildung 1.42 gezeigt. 

Abbildung 1.42: Beispiel für die Umsetzung eines Dashbaords 

1.10 Self-Service-BI mit Excel 

Für die Erstellung von Self-Service-BI Lösungen ist in Excel ein Cube bereitgestellt. Um auf diesen 

zugreifen zu können, sollte wie folgt vorgegangen werden. 

Datenverbindung herstellen 

Um Zugriff auf den PGBI Server zu haben, muss sich, wie schon oben erwähnt, der PC entweder im 

Netzwerk der Uni Oldenburg befinden oder via VPN zu diesem verbunden sein. Ist dies sichergestellt 

wählt man in der Navigationsleiste von Excel den Reiter „Daten“. Hier nun die Schaltfläche „Aus 

anderer Quelle“ und darin den Eintrag „Von Analysis Services“. Daraufhin erscheint das in Abbildung 

1.43 dargestellte Fenster. Hier ist der Servername „pg-bi.informatik.uni-oldenburg.de“ zu verwenden 

169



und darauf mit den Daten des Nutzers „PBoewe“ zu verbinden. Sind alle Daten eingetragen kann die 

Schaltfläche „Weiter >“ betätigt werden. 

Abbildung 1.43: Dialog zur Datenverbindungs-Konfiguration in Excel 

Daraufhin erscheint der Datenverbindungs-Assistent (Abbildung 1.44) in dem der gewünschte Cube 

ausgewählt werden kann. Die meisten relevanten Daten werden durch den Subrouten-Cube abgebildet, 

weshalb es sich empfiehlt diesen auszuwählen. Anschließend muss wieder die Schaltfläche „Weiter >“ 

betätigt werden. 

Abbildung 1.44: Dialog zur Auswahl des Cubes in Excel 

Es empfiehlt sich das Häkchen bei „Kennwort in Datei speichern“ (Abbildung 1.45) zu setzen, um 

dieses nicht bei jeder Änderung oder Neuauswahl der Daten erneut eingeben zu müssen. Außerdem 

170



sollte in den Authentifizierungseinstellungen (Schaltfläche „Authentifizierungseinstellungen…“) 

„Keine“ angewählt werden. Ist das erledigt muss die Schaltfläche „Fertig stellen“ betätigt werden. Nun 

ist die Datenquelle konfiguriert und sie können auf die Cube-Daten zugreifen. 

Abbildung 1.45: Dialog zum Speichern der Authentifizierungseinstellungen in Excel 

Arbeiten mit Cube-Daten und Pivot-Tabellen 

Nachdem die Datenquelle eingerichtet wurde erscheint auf der rechten Seite des Excel-Fensters der 

Pivot-Tabellen Bereich. Hier sind alle Felder, die Werte beinhalten, sowie eine Auswahl an einstellbaren 

Dimensionen aufgelistet. Zur Auswahl dieser klickt man in das kleine Kästchen links daneben. So 

lassen sich schnell individuelle Reports erstellen und über die gängigen Excel Diagrammtypen visualisieren. 

Ein Visualisierungsbeispiel der Daten ist in Abbildung 1.46 zu sehen. 

171



Abbildung 1.46: Beispiel für die Visualisierung von Reportdaten 

2. Installationshandbuch 

2.1 Datenbank, Cube, Datenflüsse und SSRS-Reports einrichten 

Der Projektabgabe liegt eine Sicherung der beiden Datenbanken bei. Die beiden .bak-Dateien können 

über die Wiederherstellen-Funktion in eine beliebige Installation des Microsoft SQL Servers überführt 

werden. 

Auch die Dateien für den Cube (Analysis Services), die Datenflüsse (Integration Services) sowie die 

Reports (Reporting Services) liegen der Projektabgabe bei. Hierbei handelt es sich um insgesamt drei 

Projektdateien für das Microsoft Visual Studio. Die Dateien lassen sich mit dem Visual Studio auf 

einem beliebigen System öffnen. Anschließend sind die jeweils angegeben Datenquellen zu ändern. 

Statt einer Verbindung zu dem, im Projektverlauf genutzten, PGBI-Server ist stattdessen eine Verbindung 

zu dem neu installierten Server einzutragen. Anschließend lassen sich alle drei Visual-Studio- 

Projekte erstellen und bereitstellen. Auf diese Weise werden sie in die Datenbank geschrieben und 

lassen sich verwenden. Aufgrund gegenseitiger Abhängigkeiten empfiehlt sich die folgende Reihenfolge 

der Bereitstellung: 

1. Analysis Services (JinengoAnalysisCube) 

2. Integration Services (JinengoIntegration1) 

3. Reporting Services (JinengoReports) 

172



2.2 Datengenerator 

Als Vorbereitung auf die Nutzung des Datengenerators muss auf einem gewünschten Rechner der 

Microsoft SQL Server 2012 installiert sein. Nachdem die Software installiert und das SQL Server 

Management Studios gestartet wurde muss die sie mit einem Server verbunden werden. Dies kann ein 

lokaler Server auf demselben Rechner, oder ein Server der auf einer anderen Maschine gehostet wird, 

sein. Dafür muss nur der Servertyp, der Servername sowie die gewünschte Authentifizierungsmethode 

ausgewählt und eingerichtet werden(Siehe Abbildung 2.1). 

Abbildung 2.1: Verbindungseinrichtugn des SQL Server Management Studios 

Um nun das gewünschte Datenmodell unter der eingerichteten Verbindung zu erstellen werden zwei 

Dateien benötigt. Die SQL-Dateien „Create_DB“ und „Import_Stammdaten“. Die erste Datei ist für 

die Erstellung der Datenbank mit allen dazugehörigen Tabellen zuständig und die zweite Datei befüllt 

die gewünschten Tabelle mit Daten. Wichtig ist es, sofern die Datenbank „JinengoOperationalCRM“ 

noch nicht existiert, das „Create_DB“-Skript zuerst aufzurufen. Dafür wird die entsprechende Datei 

doppelt angeklickt. Daraufhin wird sie im Zentrum des SQL Server Management Studios angezeigt. 

An dieser Stelle könnte das Skript nun verändert oder um weitere Parameter ergänzt werden. Für den 

hier beschrieben Fall reicht es, in der Navigationsleiste auf die Ausführen Schaltfläche ( ) zu 

klicken. Während das Skript durchläuft erscheint unter dem Fensterabschnitt in dem es angezeigt wird 

ein Fensterabschnitt „Meldungen“ hierin lässt sich der Fortschritt des Skripts verfolgen. Nachdem es 

komplett durchgelaufen ist erscheint unter dem „Meldungen“-Fenster, mit einem grünen Häkchen 

versehen, der Status „Die Abfrage wurde erfolgreich ausgeführt.“. Damit wurde das gewünscht Skript 

nun auf die eingerichtete Datenbank-Server-Verbindung angewandt. Anschließend ist der Vorgang mit 

den „Import_Stammdaten“-Dateien zu wiederholen. Daraufhin verfügt der gewählte Datenbankserver 

173



über das Datenmodell der operativen Datenbank und über die nötigen Nutzerdaten, um auf dieser Basis 

den Datengenerator laufen zu lassen. 

Der Datengenerator selbst lässt sich auf jedem Rechner, der über die Java-Version 7 verfügt, ausführen. 

Eine weitere optionale Voraussetzung wäre es, wenn Git bereits auf dem Rechner installiert wäre, 

um den weiteren Vorgang komfortabler zu gestalten. 

Projekt kopieren 

Zur Anwendung muss das Projekt zuerst in das gewünschte Verzeichnis des Zielrechners kopiert werden. 

Der einfachste Weg hierfür ist die Konsole. Mit dieser in das gewünschte Verzeichnis wechseln 

und dort folgenden Befehl aufrufen: 

git clone https://github.com/j2b4y/routgenerator.git 

Dieser bewirkt, dass Git ein Verzeichnis mit dem Namen „routengenerator“ unter dem gewünschten 

Pfad erstellt. Dabei werden alle relevanten Dateien und Verzeichnisstrukturen des Java-Projektes automatisch 

angelegt. 

Verfügt der genutzte Rechner nicht über Git, so ist es möglich das Java-Projekt unter dem angegebenem 

Link (https://github.com/j2b4y/routgenerator.git) als Zip-File herunter zu laden. Anschließend 

muss es noch an der gewünschten Stelle entpackt werden. 

Projekt in Entwicklungsumgebung importieren 

Der nächste Schritt besteht darin das Java Projekt in eine Entwicklungsumgebung zu importieren. 

Hierfür wird Eclipse verwendet. Eine Version zum kostenlosen downloaden befindet sich unter folgendem 

Link: 

http://www.eclipse.org/downloads/packages/eclipse-ide-java-ee-developers/junosr2 

Sollte eclipse bereits auf dem Rechner installiert sein, kann dieser Schritt übergangen werden. 

Nachdem eclipse gestartet wurde Rechtsklicken Sie in den ProjectExplorer und wählen „Import > 

Import…“. Anschließend muss im folgenden Dialog unter dem Pfad „General“ der Eintrag „Existing 

Projects into Workspace“ gewählt werden (Abbildung 2.2). Daraufhin erscheint ein weiterer Dialog. 

An dieser Stelle wird unter „Select root directory“ der Pfad des Projektes „…/routengenerator“ ausgewählt 

und auf „Finish“ gedrückt. 

174



Abbildung 2.2: Importdialog in eclipse 

Ausführungsvorbereitungen 

Bevor der Datengenerator gestartet werden kann, muss man sich aus sicherheitstechnischen Gründen 

im Netzwerk der Universität Oldenburg befinde. Bevor nun auf Start gedrückt werden kann, sollten 

Sie sicher gehen, dass die angegebenen Anzahlen der zu simulierenden Endanwender und aktiven 

Endanwendern korrekt gewählt ist. Diese Einstellungen können in der Datei „RoutenGenerator.java“ 

des Paketes „com.jinengo.routengenerator“ vorgenommen werden. Anschließend kann das Programm 

ausgeführt werden. 

Ändern der Datenbank Anbindung 

Für den Fall dass der Routengenerator auf eine andere, als der vorkonfigurierten Datenbank schreiben 

soll, ist zum einen sicher zu stellen, dass die Zieldatenbank die benötigten Tabelle inklusive der 

Stammdaten beinhaltet, die der Beschreibung des Datenmodels der operativen Datenbank (Kapitel 

3.2.1 des DV-Konzepts) entnommen werden können. Anschließend sind die neuen Verbindungsparameter 

in den Dateien „MSSQLConnectionHandler.java“ des Paketes 

„com.jinengo.routengenerator.service.helper“ (Siehe Abbildung 2.3) einzutragen. 

175



Abbildung 2.3: ProjectExplorer aus eclipse für den Routengenerator 

2.3 Reporting API und Frontend für Endanwender 

Die Reporting API und das Frontend für Endanwender lassen sich leicht auf dem eigenen lokalen 

Rechner oder Server installieren. Am einfachsten ist die Installation wenn auf dem Entwicklungsrechner 

bereits Git 20 und Maven 21 installiert sind. Beispielsweise ist auf neueren Unix Systemen Git und 

Maven bereits standardmäßig installiert. 

Projekt kopieren 

Zur Entwicklung der Anwendung muss das Projekt zuerst in das Entwicklungsverzeichnis des eigenen 

Rechners kopiert werden. Am einfachsten lässt sich dies über die Konsole realisieren. Hierzu einfach 

in der Konsole in das gewünschte Arbeitsverzeichnis navigieren und folgenden Befehl ausführen: 

git clone https://github.com/lars2510/reportingservice.git 

Git erstellt daraufhin ein neues Verzeichnis „reportingservice“ und kopiert alle notwendigen Dateien 

in dieses Verzeichnis. Sollte Git nicht auf dem Rechner installiert sein, kann auch einfach die Webseite 

https://github.com/lars2510/reportingservice.git aufgerufen, das Projekt als Zip-File heruntergeladen 

und an gewünschter Stelle entpackt werden. 

Maven vorbereiten 

20 Vergleiche: https://github.com/ 

21 Vergleiche: http://maven.apache.org/ 

176



Für das Bauen der Anwendung wird Maven genutzt. Maven bietet den Vorteil, dass alle notwendigen 

Bibliotheken und Abhängigkeiten aus dem Internet geladen und an richtiger Stelle in das Projekt kompiliert 

werden. 

Aus Lizenzgründen stellt Microsoft seine aktuellen JDBC Treiber nicht für Maven zum Download 

bereit. Sie müssen daher manuell hinzugefügt werden. Hierzu kann über die Konsole in das „reportingservice“ 

Verzeichnis gewechselt und dort in den Ordner „lib“ navigiert werden. Hier befinden sich 

die JDBC Treiber und können mit folgendem Konsolen-Befehl dem Maven Projekt zugefügt werden: 

mvn install:install-file -Dfile=sqljdbc4.jar -DgroupId=com.microsoft.sqlserver -DartifactId=sqljdbc4 

-Dversion=3.0 -Dpackaging=jar 

Projekt installieren 

Um das Projekt zu installieren kann aus der Entwicklungsumgebung oder über die Konsole der Befehl 

„mvn clean install“ im Hauptverzeichnis ausgeführt werden. Bei erstmaliger Ausführung des Befehls 

kann beobachtet werden, wie eine Reihe an Abhängigkeiten aus dem Internet geladen werden. Definiert 

werden diese Abhängigkeiten über die pom.xml Datei im Hauptverzeichnis der Anwendung. Die 

Installation sollte nach ca. 30 Sekunden mit der Nachricht „Build Success“ enden. Die Anwendung ist 

jetzt fertig gebaut und kann mit einem Apache Tomcat Server der Version 6 oder 7 gestartet werden. 

Alternativ kann auch das von Maven erstellte War-File aus dem „target“-Verzeichnis der Anwendung 

auf einen Tomcat Server ausgeführt werden. Das War-File beinhaltet sowohl die Reporting API als 

auch das Frontend für Endanwender und muss einfach im Web-Verzeichnis eines Tomcat Servers 

entpackt werden und ist sofort lauffähig. Das Entpacken übernehmen viele Tomcat Server bereits automatisch. 

Anwendung nutzen 

Das Reporting Frontend kann bei laufendem Server unter „localhost:8080/reportingservice/“ erreicht 

werden. Für die Authentifizierung kann der Testnutzer „beccy@brinckmann.com“ mit dem Passwort 

„beccy32“ genutzt werden. 

Die API ist bei laufendem Server unter „localhost:8080/reportingservice/api“ zu erreichen. Nutzerkennzahlen 

lassen sich beispielsweise über „localhost:8080/reportingservice/api/user/figures“ abfragen. 

Projektstruktur 

Die Projektdateien zur Entwicklung befinden sich im Hauptverzeichnis im Ordner „src“. Nachdem der 

Befehl „mvn install“ ausgeführt wurde, werden zudem die kompilierten Dateien im Ordner „target“ 

177



abgelegt. Unter „doc“ ist zudem eine Java-Doc Dokumentation abgelegt, die alle Klassen des Projektes 

beinhaltet. 

Die für die API relevanten Java-Klassen befinden sich unter „src/main/java/com/jinengo/reporting“ 

und sind wie bereits im Konzept beschrieben in die drei Bereich controller, model und service aufgeteilt. 

Alle für die Webanwendung relevanten Dateien befinden sich unter „src/main/webapp“. Hier existieren 

zwei Ordner: 

 

 

Der „resources“-Ordner enthält alle JavaScript und CSS Dateien des Reporting Frontends. 

Der „WEB-INF“-Ordner ist das Tomcat Webverzeichnis und enthält unter „views“ alle relevanten 

JSP-HTML Seiten. Zusätzlich befinden sich im Ordner „spring“ die XML-Dateien zur 

Konfiguration der Anwendung. Hier wird z.B. die Datenbankverbindung konfiguriert. Die 

Zugangsdaten zur Datenbank werden in einer separaten „database.properties“ Datei gespeichert. 

Sie ist unter „src/main/resources“ zu finden. 

3. Begründung eingesetzter Webtechnologien 

3.1 Frontend 

JavaScript 

JavaScript ermöglicht es, dem Nutzer ein interaktives Erlebnis bei der Nutzung des Web-Frontends zu 

ermöglichen. Dies geschieht durch Interaktionsmöglichkeiten und das dynamische Laden von Inhalten. 

Die Nutzung von JavaScript stellt jedoch auch eine Herausforderung dar, da die Sprache nur rudimentäre 

Grundpfeiler der Softwareentwicklung unterstützt und es bei größeren Projekten einiger Erfahrung 

bedarf eine geeignete Struktur zu finden. Um die Struktur zu verbessern wurde der JavaScript Teil in 

verschiedene Module gekapselt. 

Anmerkung: Mehrere JavaScript Dateien sind für die Entwicklung ein gutes Vorgehen. Diese sollten 

jedoch beim Deployment der finalen Anwendung minifiziert und zu einer einzigen Datei zusammengefasst 

werden. Hierbei unterstützen Tools wie der YUI-Compressor 22 . 

22 Vergleiche: http://yui.github.com/yuicompressor/ 

178



Das JavaScript wurde dabei nach gängigen Konventionen implementiert. So werden die einzelnen 

Schritte wie Initialisierung der EventHandler, Ajax Request an die API, Vorbereitung der Daten, 

Zeichnung des Charts in Modulen gekapselt. Groß geschriebene JavaScript Dateien entsprechen dabei 

der Konvention nach Klassen von denen mehrere Instanzen erzeugt werden können. 

SVG 

Die Verwendung von SVG hat eine Reihe von Vorteilen für den aktuellen Anwendungsfall: 

 

 

 

Die Charts werden dynamisch erzeugt und können so live die, über die Rest-API angefragten, 

Daten darstellen. 

SVG ist in allen modernen Browsern verfügbar. Dies bietet insbesondere für mobile Endgeräte 

einen Vorteil gegenüber Flash, da SVG keine Plug-Ins benötigt und auch auf IOS Geräte darstellbar 

ist. 

Es handelt sich bei SVG um Vektorgrafiken. Diese sind beliebig auf unterschiedlichste Auflösungen 

skalierbar und ermöglichen auch auf hochauflösenden Retina Displays optimale Darstellungsqualität. 

179



CSS3 

Durch die Verwendung moderner CSS3 Elemente konnte für die Darstellung der Buttons und des Navigationsmenüs 

auf Grafiken verzichtet werden. Dies bietet eine Reihe von Vorteilen: 

 

 

 

 

CSS-Elemente können sich dynamisch verschiedenen Auflösungen anpassen. 

Die Buttons wirken auch auf Hochauflösenden Displays scharf. 

Geräte mit geringer Internetbandbreite können die Anwendung problemlos nutzen, da keine 

Grafiken übertragen werden müssen. 

Für Änderungen von Schrift, Farbe und Größe müssen keine neuen Grafiken erstellt werden, 

sondern es reichen geringe Anpassungen im CSS. 

Ajax und JSON 

Asynchrone Datenübertragung bietet den Vorteil, dass mehrere Anfragen an den Webservice parallel 

gestellt werden können. Dies spart Zeit bei der Datenübertragung und ermöglicht zudem das dynamische 

Nachladen von Inhalten, etwa zur Darstellung weiterer Charts. Asynchrone Anfragen ermöglichen 

zudem das Ändern von Seiteninhalten, ohne dass das Browserfenster neu geladen werden muss. 

So kann das gesamte Webinterface mit allen Chart-Varianten als „Single-Page“ Anwendung betrieben 

werden 

Da die Web-API die Daten bereits im JSON-Format liefert bietet uns dies den großen Vorteil, die Daten 

direkt aus JavaScript heraus interpretieren und verarbeiten zu können. Würden wir beispielsweise 

XML Verwenden wäre noch ein zusätzlicher Parser notwendig, dieser Schritt entfällt durch JSON. 

Dies spart Zeit und reduziert zudem mögliche Fehlerquellen. 

3.2 Backend 

Java 

Zur Entwicklung des REST Webservices wurde sich für Java als Programmiersprache entschieden. 

Durch eine breite Tool und Framework Unterstützung und mehrjährige Etablierung im Enterprise Umfeld 

ist Java besonders für daten- und rechenintensive Anwendungen eine gute Wahl. Zudem wird die 

Sprache vom bestehenden Jinengo System verwendet, so dass Komponenten des Webservice leicht in 

bestehende Systeme integriert werden können. 

Ein weiterer wichtiger Faktor beim Auswahlprozess der Programmiersprache ist dabei die Möglichkeit 

mit dem SQLServer 2012 kommunizieren zu können. Hierfür existieren entsprechende JDBC Bibliotheken 

die Verbindung und Interaktion mit der Datenbank ermöglichen. 

180



Spring Framework 

Die klare Trennung der Darstellung, Datenhaltung und Anwendungslogik bringt eine Reihe von Vorteilen. 

So erleichtert es einzelne Komponenten auszutauschen oder anzupassen. Aber auch die Arbeit 

im Team wird verbessert. So können Frontendentwickler (View) weitgehend unabhängig von Backenentwicklern 

in der Datenhaltung (Model) und in der Anwendungslogik (Controller) arbeiten. 

Das Spring Framework selbst bringt zudem eine Reihe vorgefertigter Bausteine mit sich. So erleichtert 

es beispielweise die Verbindung zwischen angeforderter URL und zugehöriger Ressource herzustellen. 

Auch kann die Umwandlung der angeforderten Ressourcen durch den Controller bereits implizit 

in das benötigte JSON Ausgabeformat erfolgen. Dies erleichtert die Entwicklung und macht die Anwendung 

stabiler und weniger Fehleranfällig. 

Die Spring Webservice Anwendung verwendet neben Hibernate unter anderem folgende Technologien: 

Servlets 

JSP 

Depency Injection 

Annotations 

Servlets nehmen Anfragen des Clients entgegen und leiten sie an den zuständigen 

Controller weiter. 

Java Server Pages dienen zur dynamischen Erzeugung von HTML Ausgaben 

des Webservice. 

Regelt Abhängigkeiten zwischen Java Objekten. Für Variablen die durch 

@Autowired gekennzeichnet sind übernimmt Spring die Instanziierung und 

Referenzierung des Objektes. Die Definition erfolgt über XML-Dateien. 

Annotations werden durch das @-Zeichen gekennzeichnet und ermöglichen 

es Zusatzinformationen zu codieren. So wird beispielsweise über @Entity 

spezifiziert, welcher Datenbanktabelle ein Java Model zugeordnet ist. 

Tabelle 3.1: Eingesetzte Java Technologien 

REST 

Das REST-Prinzip zeichnet sich dadurch aus, dass eine Anfrage über HTTP an einen Web-Server 

gestellt wird, wobei die benötigte Ressource eindeutig durch eine URI kodiert ist. Dies ermöglicht das 

einfache und elegante Abrufen von Ressourcen auch von reinen JavaScript basierten Webanwendungen 

heraus, da sich Anfragen über Ajax realisieren lassen. Dies bietet einen klaren Vorteil gegenüber 

vergleichbaren Protokollen, wie beispielsweise SOAP. 

REST fördert die Entwicklung leichtgewichtiger Webanwendungen durch eine lose Kopplung zwischen 

Datenzugriff und Datendarstellung. Die Schnittstelle ermöglicht auch das Bereitstellen der Daten 

für Drittanbieter und erleichtert die Anbindung von externen Anwendungen. (Fielding 2000, S. 

116) 

181



JSON 

Für das Datenformat der Ressource wird das JSON-Format gewählt. Dies bietet für Webanwendungen 

eine Reihe von Vorteilen. So müssen Datensätze nicht wie beispielsweise bei XML durch einen Parser 

vorverarbeitet werden, sondern die Daten sind direkt in, auf JavaScript basierenden, Webanwendungen 

zugreifbar. Auch reduziert das schlankere JSON Format die Menge an zu übertragenen Datensätzen 

und erhöht somit die Geschwindigkeit der Anwendung, was besonders im mobilen Bereich ein 

entscheidender Vorteil ist. 

Hibernate / JPA 

Zum besseren Umgang mit den Datenbanksystemen wird neben dem JDBC-Treiber das Framework 

Hibernate und die Java Persistence API (JPA) eingesetzt. Der Einsatz des Frameworks bietet eine Reihe 

von standardisierten Zugriffsmöglichkeiten und ermöglicht eine datenbankunabhängige Abfrage 

der Datensätze. Durch einmalige Definition des Datenbankdialektes können die Zugriffe auf die Datensätze 

aus Java heraus erfolgen und in der plattformneutralen JPA Notation formuliert werden. Dies 

bietet den Vorteil, dass die Anwendung nicht fest an den SQL2012 Dialekt gebunden und daher nur 

lose mit der Datenbank gekoppelt ist. Bei Bedarf kann daher leicht eine Migration der SQL Datenbank 

auf die Datenbank eines CRM-Systems erfolgen. 

Ein weiterer wichtiger Faktor, der für den Einsatz von Hibernate und JPA spricht, ist die Sicherheit. 

Für den Zugriff auf sensible Daten der Datenbank können standardisierte Funktionen genutzt werden. 

Diese beinhalten bereits grundlegende Sicherheitsaspekte und schützen die Anwendung vor unbefugten 

Zugriffen. 

Für die Entwicklung bietet Hibernate und JPA den Vorteil, dass die Datenbanktabellen direkt in Form 

von Java Modellen erstellt werden können. Dies ermöglicht ein automatisiertes „Mapping“ bei welchem 

die einzelnen Spalten der abgefragten SQL-Objekte auf Java-Objekte zugewiesen werden. Da 

dieser Schritt automatisiert erfolgt, erhöht dies die Stabilität und Übersichtlichkeit der Anwendung 

und macht sie leichter auf veränderte Datenbestände anpassbar. Auch eine Iteration über alle Ergebnisse 

der SQL-Abfrage ist nicht mehr nötig und wird von der Anwendung übernommen. Dies erleichtert 

den Zugriff auf die Datensätze und reduziert den Implementationsaufwand. 

Maven 

Maven bietet den Vorteil, dass Abhängigkeiten zu Bibliotheken automatisch geladen und korrekt in 

die Anwendung integriert werden. Zudem ist Maven bereits in Spring integriert und ermöglicht es die 

Anwendung in optimaler Struktur für die spätere Verwendung auf dem Webserver vorzubereiten. 

182



Git 

Bei der Entwicklung von Software im Team ist die Verwendung einer geeigneten Revisionskontrolle 

eine essentielle Grundlage und bietet eine Reihe an Vorteilen: 

 

 

 

 

Ein zentrales Repository in der Cloud bei dem alle Teammitgliedern Zugriff auf den aktuellen 

Entwicklungsstand der Software erhalten. 

Ein eigenes lokales Repository, das Versionskontrolle auch ohne Internetanbindung erlaubt 

(Das Team arbeitet oft im Zug). 

Da die Software vorwiegend auf OSX Systemen entwickelt wird, bieten Tools wie 

„SourceTree“ 23 hervorragende Integrationsmöglichkeiten und unterstützen bei Softwareentwicklung. 

Git bietet nicht nur zentralen Zugriff auf den Quellcode, sondern ermöglicht auch die Sicherung 

und Versionierung der unterschiedlichen Entwicklungsstände. So kann leicht zwischen 

unterschiedlichen Version der Software gewechselt oder bei Parallelentwicklung verschiedene 

Stände der Software zu einer einheitlichen Version zusammengefasst werden. 

4. Fazit 

Aufgabe der Teilgruppe war es, eine Business-Intelligence-Umgebung für die bestehende Jinengo- 

Plattform zu entwickeln, um so das Mobilitätsverhalten von Endanwendern zu analysieren und für 

verschiedene Zielgruppen aufzubereiten. Die Ergebnisse unterstützen unter anderem das Management 

dabei, die Erfolge und Schwächen der Plattform verstehen und Potentiale besser erkennen zu können. 

Dem Endanwender wird zudem durch geeignete Visualisierung seines Mobilitätsverhaltes aufgezeigt, 

wie er sich noch nachhaltiger verhalten könnte. Zudem können interaktive Reports dazu beitragen, die 

Attraktivität der Plattform zu steigern und sie von vergleichbaren Lösungen positiv abzugrenzen. 

Aufgrund des bislang ausstehenden operativen Betriebs stellte sich zu Beginn die qualitative und 

quantitative Erweiterung der Datenbasis als notwendige und bedeutende Vorbedingung heraus. Der 

Kern des Projektes basierte im Wesentlichen auf den drei BI-Kernelementen: Data Warehouse & ETL, 

Data Mining und Reporting. 

Data Warehouse & ETL 

Um die Daten aus dem operativen Jinengo-System historisiert zu sichern, wurde ein Data Warehouse 

entworfen. Die entwickelten ETL-Prozesse stellen sicher, dass die Daten aus dem operativen System 

23 Vergleiche: http://www.sourcetreeapp.com/ 

183



historisiert sowie bei Bedarf aggregiert im Data Warehouse abgespeichert werden. Zudem wurde ein 

Cube erstellt, der die relevanten Mobilitätskennzahlen aus multidimensionaler Sicht darstellt. Auf 

diese Weise stehen die Daten für analytische Zwecke unabhängig von der eigentlichen operativen 

Datenbank zur Verfügung. 

Data Mining 

Unter Verwendung verschiedener Data Mining Methoden werden die Routen- und Nutzerdaten analysiert. 

Die Analysen werden in vier Anwendungsfälle unterteilt: „Eigenschaften raten“, „Newsletter & 

Reporting“, „Ökologische Alternativen vorschlagen“ und „Warnen vor ungewöhnlichem Verhalten. 

Die Ergebnisse aus jedem Anwendungsfall werden abgespeichert und können bspw. für Marketingkampagnen 

oder erweitertes Reporting verwendet werden. 

Reporting 

Die Projektgruppe hat unter Einsatz verschiedener Reporting-Tools eine Grundlage für zielgruppenspezifisches 

Reporting geschaffen. 

Für die Zielgruppen Jinengo-Management, Wissenschaftler und Mobilitätsanwender wurden exemplarische 

Reports und Dashboards auf Grundlage von QlikView, Microsoft SSRS und Microsoft Excel 

erstellt. Dabei wiesen die Tools unterschiedliche Vor- und Nachteile auf. So zeigte sich, dass Microsoft 

SSRS vielfach sehr statisch und in der Funktionalität eingeschränkt ist. Microsoft Excel hingegen 

ist als bekannte Office-Anwendung sehr gut bedienbar, kann jedoch nur auf multidimensionale und 

nicht auf relationale Daten zugreifen. Neben der homogenen Microsoft Landschaft bietet QlikView 

eine interessante Alternative und ist bezüglich Filterung und Darstellung der Daten sehr flexibel einsetzbar, 

hat jedoch begrenzte Integrationsmöglichkeiten bezüglich bestehender Systeme. 

Für die Zielgruppe der Endanwender wurde eine eigene Anwendung auf Basis aktueller Webtechnologien 

entwickelt. Die hierfür eigens entwickelte REST-API in Verbindung mit der Webanwendung 

macht die Softwarearchitektur sehr flexibel und ermöglicht eine einfache Integration des Endanwender-Reportings 

in unterschiedliche Kontexte. So lässt sich das Reporting zukünftig sowohl in die 

Jinengo-Plattform als auch in Apps für mobile Endgeräte einbinden. 

Ausblick 

Da die Arbeit der Projektgruppe als prototypische Umsetzung zu verstehen ist, die Möglichkeiten und 

Grenzen aufzeigt, werden im Folgenden zukünftige Aufgaben aufgezeigt. 

Sobald Jinengo System in Betrieb genommen wird und größere Mengen an operativen Daten anfallen, 

können die vorbereiteten ETL-Prozesse die Daten regelmäßig und automatisiert in das Data- 

Warehouse übertragen. 

184



Mit Hilfe der Data-Mining Technologien lassen sich automatisierte Analysen durchführen, die 

Schrittweise die Qualität des operativen Systems verbessern. Dabei können nicht nur die Routenempfehlungen, 

sondern auch marketingtechnische Entscheidungen optimiert werden. 

Im Rahmen des Reporting sollte eine Entscheidung bezüglich der endgültig einzusetzenden Technologie 

getroffen werden. Darauf aufbauend können die bereits umgesetzten Reports und Dashboards in 

das bestehende System integriert und ggf. erweitert werden. Hierbei ist darauf zu achten, dass das 

Design der Reports dem der Plattform entspricht und einheitlich umgesetzt wird. Je besser das Reporting 

in das operative System integriert ist, desto größer ist der Mehrwert der für einen Anwender entsteht. 

185



Literaturverzeichnis 

Fielding, R. T. (2000): Architectural Styles and the Design of Network-based Software Architectures. 

Dissertation. University of California, Irvine. 

Springsource o.J., MVC Framework, URL: 

http://static.springsource.org/spring/docs/2.0.x/reference/images/mvc.png, (Zugriff am: 20.03.2013). 

186

Projektbericht Cuberunner 

CEWE „gestochen scharfe Fragen stellen“ – Fachkonzept 



Gruppe: CEWE 

Fachkonzept 

187



188



Inhaltsverzeichnis CEWE Fachkonzept 



Abkürzungsverzeichnis .......................................................................................................... 190 

1. Ziele und Visionen ........................................................................................................... 191 

2. Rahmenbedingungen ....................................................................................................... 191 

2.1 Organisation und Vorgehen der BI-Projektgruppe..................................................... 192 

2.2 Projektspezifische technische & organisatorische Bedingungen ............................... 192 

2.2.1 Team ................................................................................................................ 193 

2.2.2 Kommunikation ............................................................................................... 193 

2.2.3 Technologien ................................................................................................... 193 

2.2.4 Stakeholder-Definitionen ................................................................................. 194 

3. Technologien ................................................................................................................... 194 

4. Fragestellungen und unternehmerischer Nutzen ............................................................. 195 

5. Analytische Anforderungen ............................................................................................. 196 

5.1 Arbeitspaket 1: Umfrageerstellung ............................................................................. 196 

5.2 Arbeitspaket 2: Ergebnisdatenlagerung ...................................................................... 198 

5.3 Arbeitspaket 3: Berichtswesen ................................................................................... 198 

5.4 Arbeitspaket 4: Prognose ............................................................................................ 199 

5.5 Arbeitspaket 5: Fragenpoolgenerierung ..................................................................... 201 

6. Kennzahlen ...................................................................................................................... 201 

7. Scores ............................................................................................................................... 201 

8. Semantische Modellierung .............................................................................................. 202 

9. Nichtanalytische Anforderungen ..................................................................................... 202 

189




Abbildung 5.1: Anforderungsbereiche ................................................................................... 196 

Abbildung 5.2: Aktueller Freigabeprozess ............................................................................. 197 

Abbildung 5.3:Gewünschter Freigabeprozess ....................................................................... 198 

Abbildung 5.4: Aktuelle Struktur ........................................................................................... 200 


Tabelle 6.1: Kennzahlen ......................................................................................................... 201 

Tabelle 7.1: Scores ................................................................................................................. 202 


Closed-Loop 

KPI 

Marketing im geschlossenen Kreislauf 

Kennzahlen anhand wichtiger Erfolgsfaktoren 

190



1. Ziele und Visionen 

Die computergestützte Erfassung, Aufbereitung und Analyse von Daten, zur Unterstützung der Entscheidungsfindung 

in einem Unternehmen, ist zu einem relevanten Thema in der Informationstechnik 

geworden. Die Methoden dieser Business Intelligence (BI) können in verschiedenen Bereichen von 

Unternehmen zum Einsatz kommen und auch im Customer Relationship Management (CRM) nutzenbringend 

angewandt werden. 

Das Kundenverhalten lässt sich mittels CRM-Methoden erfassen, analysieren und durch gezielte Aktionen 

fördern und lenken, um neue Kunden zu gewinnen oder ein bereits bestehendes Kundenverhältnis 

durch angepasste Maßnahmen zu festigen. 

Unter dem Arbeitstitel gestochen scharfe Fragen stellen befasst sich eine Gruppe von Studierenden 

der Carl von Ossietzky Universität Oldenburg mit dem Projekt Analytisches CRM in Kooperation mit 

der CEWE COLOR AG & Co. OHG (CEWE). Ziel dieses Projektes ist eine Vereinheitlichung der 

computergestützten Prozesse und Systeme zur gezielten Umfrageerstellung. Der derzeitige Ablauf zur 

Erstellung einer Umfrage enthält mehrere systemübergreifende, manuelle Arbeitsschritte. Durch Einbeziehung 

vorhandener Analyseergebnisse in die Umfrageerstellung, soll eine Vereinfachung der Arbeitsabläufe 

durch unmittelbare Verfügbarkeit relevanter Daten ohne Medienbrüche erreicht werden. 

Die zentrale Lagerung historischer und zukünftiger Umfragen und Ergebnisse in lokalen Datenbanken 

soll die derzeitige dezentrale Lagerung der vorhandenen Datenbestände ablösen. Ferner soll die Möglichkeit 

bestehen, neue Fragen über eine Eingabemaske in die Datenbank zu integrieren. Die Implementierung 

einer Funktion zur Suche nach Attributen und Parametern von bereits vorhandenen Fragen 

ist ebenfalls Teil des Projekts. Aufbauend auf diesem Prozess sollen die gesammelten Daten für grundlegende 

Analysen und Prognosen ausgewertet werden. 

In Absprache mit CEWE wird dieses Projekt unter anderem mit dem Umfragetool QuestionPro und 

den Technologien SAP CRM, IBM Cognos und IBM SPSS realisiert. 


Im Folgenden werden die Rahmenbedingungen für das Projekt erläutert. Hierbei werden insbesondere 

die projektspezifischen Bedingungen berücksichtigt, welche sich auf das gesamte Projekt und das 

Thema BI im Umfeld der Projektgruppe beziehen. 

191



2.1 Organisation und Vorgehen der BI-Projektgruppe 

Die Projektgruppe beschäftigt sich mit der Entwicklung von Anwendungen im Umfeld BI. Vorab 

wurden dabei drei zu bearbeitende Anwendungsfälle definiert: Analytisches CRM (in Kooperation mit 

CEWE), Sustainability CRM für nachhaltige Mobilität (Jinengo) & SmartWindFarm (in Kooperation 

mit ForWind). Abseits eines projektgruppeninternen Aufbaus und Transfers von Knowhow (unter 

anderem durch die Seminararbeiten) erfolgt die Bearbeitung der einzelnen Anwendungsfälle in personell 

getrennten Teilgruppen. Die Absprache der einzelnen Teilgruppen erfolgt durch regelmäßige 

Treffen. Folgende Rahmenbedingungen wurden auf Ebene der übergeordneten Projektgruppe vereinbart 

und sind daher auch für die CEWE-Teilgruppe von Bedeutung. 

Die übergeordnete Projektgruppe hat sich auf ein sequenzielles Vorgehensmodell für die Softwareentwicklung 

geeinigt, das in allen Teilgruppen verwendet werden soll. Als zentrale Artefakte werden 

ein Fachkonzept und ein DV-Konzept erstellt. Inhalte und Gliederung von Fachkonzept und DV- 

Konzept sind innerhalb der übergeordneten Projektgruppe abgestimmt. Die Realisierung erfolgt dabei 

im klassischen Sinne, ist jedoch in Bezug auf die Dokumentation und anderen Teilaspekten angelehnt 

an agile Modelle. Zu Beginn wird daher ein vorläufiges Fachkonzept verfasst und auch formal abgenommen. 

Im Laufe des Projekts wird dieses Fachkonzept weiter ausgearbeitet und dient auch dokumentarischen 

Zwecken. Die Fertigstellung des DV-Konzepts erfolgt gegen Mitte der Realisierungsphase. 

Über alle Anwendungsfälle hinweg wird ein Vergleich der verschiedenen eingesetzten BI- 

Technologien angestrebt. Dazu wird begleitend zur Realisierung ein Kriterienkatalog für diesen Technologievergleich 

entwickelt. Der tatsächliche Vergleich der verschiedenen Technologien auf Grundlage 

des Katalogs erfolgt gegen Projektende. 

2.2 Projektspezifische technische & organisatorische 

Bedingungen 

In den folgenden Abschnitten werden die technischen und organisatorischen Rahmenbedingungen für 

die CEWE-Teilgruppe beschrieben. Dazu zählen die Vorstellung des Teams, die verfügbaren Technologien, 

das gegebene Arbeitsumfeld sowie die Kommunikation innerhalb der CEWE-Teilgruppe und 

den Ansprechpartnern seitens CEWE. 

192



2.2.1 Team 

Das Projektteam besteht aus fünf Studierenden der Universität Oldenburg, welche der Projektgruppe 

Cuberunner angehören, die im Sommersemester 2012 gegründet wurde. Die Projektgruppe besteht in 

der Zeit vom 1. April 2012 bis zum 31. März 2013. 

Zum Projektteam gehören folgende Mitglieder: 

- Wiebke Meyer 

- Benjamin Weinert 

- Björn Kreye 

- Henning Tomann 

- Fatih-Mehmet Inel (Teilgruppenleiter) 

Als Ansprechpartner seitens der CEWE stehen Dr. Joachim Marz, Eugen Neigel und Anton Byvshev 

zur Verfügung. Themenspezifische Ansprechpartner für die jeweiligen definierten Arbeitspakete im 

Laufe der Projektphase sind Manfred Neugebauer, Mike Dettmann, Karin Wehmeyer und Thomas 

Grunewald. 

2.2.2 Kommunikation 

Die Teilgruppe trifft sich während der Projektzeit in regelmäßigen Abständen mindestens einmal wöchentlich 

mit allen Mitgliedern. Es wurden Arbeitsplätze, Notebooks sowie Token und Transponder 

für die Zugriffs- bzw. Zutrittsberechtigung seitens CEWE zur Verfügung gestellt. 

Einzelne Aufgaben werden von den Teammitgliedern nach eigenem Ermessen im Rahmen der gegebenen 

Fristen selbstständig bearbeitet. Die interne Kommunikation findet hierbei, über gemeinsame 

Treffen hinaus, mittels technischer Hilfsmittel wie Skype oder E-Mail statt. 

Es finden bei Bedarf Treffen zwischen der Teilgruppe und den Ansprechpartnern seitens CEWE statt. 

Die grundsätzliche Kommunikation mit Vertretern der CEWE erfolgt über einen eigens eingerichteten 

E-Mail-Verteiler. 

Ferner werden wöchentliche Treffen mit der gesamten Projektgruppe und den zuständigen Betreuern 

von der Universität Oldenburg abgehalten. 

2.2.3 Technologien 

Das Unternehmen CEWE ermöglicht der Projektgruppe Zugang zu bereits vorhandene Technologien, 

die für die Umsetzung des Projekts relevant sind. Zu folgenden Systemen wird ein Zugang bereitgestellt: 

193



- SAP Business Information Warehouse (BW) 

- SAP Customer Relationship Management (CRM) 

- IBM Cognos 

- IBM SPSS 

- QuestionPro 

Auf Basis eines Kriterienkatalogs wurde ein umfassender Vergleich diverser Umfragetools durchgeführt. 

Die bereits von CEWE eingesetzten Systeme QuestionPro und SurveyMonkey sollten dem neu 

eingeführten SAP CRM Survey Tool gegenübergestellt und anhand von Anforderungen bewertet werden. 

Als weitere Alternative wurde das Tool SurveyGizmo für den Vergleich hinzugezogen, da es von 

allen Anwendungen die meisten Anforderungen erfüllte. 

In einer abschließenden Abstimmung mit den Verantwortlichen von CEWE wurde QuestionPro als 

zukünfigtes Umfragetool priorisiert, da die Vorteile von SurveyGizmo nicht ausschlaggebend genug 

waren. Die Technologien IBM Cognos und IBM SPSS sind derzeit bei CEWE in Betrieb und sollen 

für das Berichtswesen und die Prognosen eingesetzt werden. Das erlangte Wissen in der Teilprojektgruppe 

zu diesen Tools wird durch einen abschließenden Technologievergleich innerhalb der gesamten 

Projektgruppe genutzt. 

Als Voraussetzung für die Arbeit mit diesen Technologien sind gewisse Grundkenntnisse notwendig. 

Ein umfangreiches Wissen zu dieser Vielzahl von Anwendungen und Tools ist in der Teilgruppe nicht 

bzw. nur teilweise gegeben, daher werden die Gruppenmitglieder durch zuständige Mitarbeiter von 

CEWE instruiert. Besonders anspruchsvolle Aufgaben in dem Projekt werden in Zusammenarbeit mit 

den Spezialisten aus dem Unternehmen bearbeitet. 

2.2.4 Stakeholder-Definitionen 

Die primären Stakeholder des Projekts gestochen scharfe Fragen stellen sind CEWE und die Universität 

Oldenburg. Insbesondere der Bereich des Marketings von CEWE ist an den Projektergebnissen 

interessiert, da durch das Projekt die Arbeitsabläufe im Marketing verbessert werden sollen. Seitens 

der Universität Oldenburg werden die Projektgruppe Cuberunner und der Bereich Very Large Business 

Applications (VLBA) als Stakeholder betrachtet. Die Ergebnisse aus der Zusammenarbeit fließen in das 

Gesamtprojekt ein und können weiterhin in zukünftige wissenschaftliche Arbeiten verwendet werden. 

3. Technologien 

Das Unternehmen CEWE ermöglicht der Projektgruppe Zugang zu bereits vorhandene Technologien, 

die für die Umsetzung des Projekts relevant sind. Zu folgenden Systemen wird ein Zugang bereitgestellt: 

194



- SAP Business Information Warehouse (BW) 

- SAP Customer Relationship Management (CRM) 

- IBM Cognos 

- IBM SPSS 

- QuestionPro 

Auf Basis eines Kriterienkatalogs wurde ein umfassender Vergleich diverser Umfragetools durchgeführt. 

Die bereits von CEWE eingesetzten Systeme QuestionPro und SurveyMonkey sollten dem neu 

eingeführten SAP CRM Survey Tool gegenübergestellt und anhand von Anforderungen bewertet werden. 

Als weitere Alternative wurde das Tool SurveyGizmo für den Vergleich hinzugezogen, da es von 

allen Anwendungen die meisten Anforderungen erfüllte. 

In einer abschließenden Abstimmung mit den Verantwortlichen von CEWE wurde QuestionPro als 

zukünfigtes Umfragetool priorisiert, da die Vorteile von SurveyGizmo nicht ausschlaggebend genug 

waren. 

Die Technologien IBM Cognos und IBM SPSS sind derzeit bei CEWE in Betrieb und sollen für das 

Berichtswesen und die Prognosen eingesetzt werden. Das erlangte Wissen in der Teilprojektgruppe zu 

diesen Tools wird durch einen abschließenden Technologievergleich innerhalb der gesamten Projektgruppe 

genutzt. 

Als Voraussetzung für die Arbeit mit diesen Technologien sind gewisse Grundkenntnisse notwendig. 

Ein umfangreiches Wissen zu dieser Vielzahl von Anwendungen und Tools ist in der Teilgruppe nicht 

bzw. nur teilweise gegeben, daher werden die Gruppenmitglieder durch zuständige Mitarbeiter von 

CEWE instruiert. Besonders anspruchsvolle Aufgaben in dem Projekt werden in Zusammenarbeit mit 

den Spezialisten aus dem Unternehmen bearbeitet. 

4. Fragestellungen und unternehmerischer Nutzen 

Im folgenden Abschnitt werden unternehmensrelevante Fragestellungen zu dem Projekt und dessen 

Mehrwert erläutert. Ziel von CEWE ist es, im Rahmen von Umfragen auf unterschiedlichen Kommunikationskanälen 

- die richtigen Fragen 

- zum richtigen Zeitpunkt 

- an die richtigen Adressaten 

zu stellen, um möglichst aussagekräftige Ergebnisse zu erhalten. Von besonderer Relevanz sind die 

Qualität bzw. Güte von Fragen, die Anzahl der zu befragenden Adressaten, um eine fundierte Aussage 

treffen zu können, sowie die hierfür benötigte Rücklaufmenge vollständig beantworteter Umfragen. 

195



Weiterhin ist die Umfrageaffinität der Befragten, also die Bereitschaft Umfragen akkurat und vollständig 

zu beantworten, ein wesentlicher Faktor. Diese soll mit den Analysen beleuchtet werden, um sie 

bei der Auswahl der Adressaten einfließen zu lassen. Weiterhin sind die Anzahl geöffneter, begonnener, 

abgeschlossener und abgebrochener Umfragen sowie die Frage nach dem geeigneten Zeitpunkt 

einer Umfrage von Bedeutung. Ein ebenso wichtiger Aspekt ist die Erkenntnis, welche Kunden auf 

Incentives wie Gutscheinaktionen am ehesten angesprochen und stärker gebunden werden können. 

Anhand der erlangten Antworten auf diese Fragen kann gezielter auf das Kundenverhalten eingegangen 

werden. Umfassendere Prognosen werden somit zusätzlich ermöglicht. Der Abwanderung von 

Kunden (Churning) kann ebenfalls entgegen gewirkt werden. 


Im folgenden Abschnitt werden die Anforderungen an das Projektteam in Form von Arbeitspaketen 

dargestellt. Die Arbeitspakete beinhalten die für das Projekt drei wesentlichen Anforderungsbereiche: 

die Umfragen, die Fragen und die Konsumenten (Abbildung 5.1). 

Abbildung 5.1: Anforderungsbereiche 

Die Umsetzung der Arbeitspakete wird mit Hilfe einer in Oracle implementierten Ergebnisdatenbank, 

sowie den Tools QuestionPro, SAP CRM, IBM Cognos und IBM SPSS erfolgen. 

5.1 Arbeitspaket 1: Umfrageerstellung 

Das Arbeitspaket 1 umfasst die Umfrageerstellung sowie den Vergleich und die Analyse des Funktionsumfangs 

der Tools. Für dieses Paket sollen neben der Umfrageerstellung auch die Möglichkeiten 

für eine Genehmigung und Freigabe untersucht werden. 

196



Es soll eine Übersicht erstellt werden, die kalendarisch darstellt, welche Umfragen zu welchem Key 

Account (Saturn, dm, etc.) wann datiert wurden. Mit diesen Daten sollen Metadaten, wie Zeitpunkt, 

Zielsetzung, Feldzeit (ein Richtwert für den Zeitraum von der ersten Antwort bis zur Erreichung einer 

ausreichenden Rücklaufquote), Umfrageart, Land, Anhänge (wie z.B. der Fragebogen), Incentives und 

weitere gespeichert werden. 

Bestehende Stammdaten vorhandener Konsumenten sollen durch die genannten Metadaten angereichert 

werden. Eine weitergehende Segmentierung der Kunden anhand dieser Daten ist wünschenswert. 

KPIs wie send rate (Anzahl versendeter Umfragen nach brutto und netto), open rate (geöffnete Umfrage), 

click through rate (Umfragelink geklickt/ Umfrage gestartet) und completion rate (Umfrage 

durchgeführt und abgeschickt), average-cancelled-rate (Durchschnitt abgebrochener Umfragen) sollen 

definiert werden. Weitere Kennzahlen können im Laufe des Projektes folgen. 

Eine Schnittstelle zum aktuell eingesetzten eCRM-System ist ebenfalls notwendig. eCRM ist ein Tool 

für ein elektronisches Customer Relationship Management der Firma hmmh. Die Schnittstelle existiert 

bereits, jedoch ist ein Abgleich der transportierten Daten notwendig um zu garantieren, dass die richtigen 

personalisierten Daten und die bereits genannten Kennzahlen der Kunden in das Projekt eingehen. 

Ferner soll der Prozess zur Freigabe des Fragebogens durch das Key Account Management und das 

Newsletter-Team als unterstützende operative Einheit zur Erstellung des Newsletters integriert werden. 

Die minimale Anforderung an das Projektteam ist hier die Berücksichtigung des aktuellen Prozesses. 

Dieser beinhaltet als ersten Schritt die Erstellung der Umfrage durch die Marktforschung (Herr Anton 

Byvshev). Darauf folgt das Verfassen des Newsletters durch das Newsletter Team in Rücksprache mit 

der Marktforschung und zuletzt die Prüfung und Freigabe durch das Key Account Management 

(Abbildung 5.2). 

Abbildung 5.2: Aktueller Freigabeprozess 

Dieser Prozess kann nach Absprache mit dem Marktforschungsbereich geändert oder nach Gegebenheit 

verbessert werden, sodass dieser wie in Abbildung 5.3 gezeigt, abläuft. 

197



Abbildung 5.3:Gewünschter Freigabeprozess 

Im Optimalfall soll für die zu erstellenden Umfragen ein Fragenkatalog verwendet werden können, der 

in Arbeitspaket 5 erläutert wird. 

Alle Funktionen sind zu untersuchen und zu dokumentieren. Anhand eines Kriterienkatalogs wurde 

die Nutzbarkeit von QuestionPro überprüft. 

5.2 Arbeitspaket 2: Ergebnisdatenlagerung 

In diesem Arbeitspaket wird auf die Lagerung der vom Kunden beantworteten Fragebögen näher eingegangen. 

Die Fragebogenergebnisse werden aktuell auf den internen Datenbanken von QuestionPro 

und SurveyMonkey gespeichert und werden dort direkt zur Visualisierung und Auswertung verwendet. 

Ein regelmäßiger Export der Daten zur Sicherung der Ergebnisse wird derzeit manuell durchgeführt. 

Das Projektteam hat die Aufgabe, die Ergebnisdatenlagerung zu zentralisieren. Der Extraktionsprozess 

der Daten aus den bisherigen Systemen soll nach Möglichkeit vereinfacht und lückenlos sein. Als Datensenke 

wird ein Data Warehouse auf Oracle Basis zum Einsatz kommen. 

Für dieses Arbeitspaket werden historische Daten bereitgestellt, diese sind notwendig, um aussagekräftige 

Auswertungen und Prognosen für die folgenden Arbeitspakete (siehe Abschnitte 4.3 und 4.4) 

erstellen zu können. 

Anforderungen an die zu erstellende Oracle-Datenbank sind neben einer hohen Datenintegrität, Redundanzvermeidung, 

ein Mehrbenutzerbetrieb, eine zentrale Kontrolle der Datenbank, eine hohe Datensicherheit 

(Backups- und Prüfmechanismen) und ein entsprechender Datenschutz (Rechtesystem 

mit Zugriffskontrolle). Weiterhin sollte der Aufbau der Datenbank den in CEWE vorliegenden Standards 

genügen. 

5.3 Arbeitspaket 3: Berichtswesen 

Im Arbeitspaket 3 soll das Berichtswesen auf Basis der im Arbeitspaket 2 zentralisierten Daten angepasst 

werden. Derzeit ist eine einheitliche und vielfältige Erstellung von Berichten nicht möglich, da 

198



die verschiedenen Datensätze der unterschiedlichen Umfragetools eine Vereinheitlichung nicht zulassen. 

Die aktuell gegebenen Möglichkeiten sollen durch das Projekt abgedeckt und sinnvoll erweitert 

werden. 

Berichte sollen ad-hoc erstellbar und modifizierbar sein und müssen Ansprüchen der intuitiven Bedienbarkeit 

sowie der Aussagekraft genügen, weiterhin müssen sie unmittelbares Navigieren zwischen 

den Daten (Data Surfing) zulassen. Selbiges gilt für Dashboards und Benchmarking, welche die aus 

Arbeitspaket 1 definierten Kennzahlen verwenden. 

Auf Basis eines Berechtigungssystems sollen sowohl entsprechend der Governance eine Trennung 

nach Handelspartnern als auch eine differenzierte Darstellung nach Rollen (Führungsebene, Marketing, 

Produktenwicklung) und den jeweils relevanten Daten möglich sein. Für das Berichtswesen wird 

IBM Cognos zum Einsatz kommen. 

Zu den in dem Oracle Data Warehouse liegenden Daten stellt der IBM Framework Manager eine Verbindung 

her und ermöglicht die Erstellung von Cognos Cubes auf Basis dieser. Im Falle großer Datenmengen 

können mit Hilfe des Cognos Transformer Kits Offline-Cubes erstellt werden. Die Offline- 

Cubes würden eine lokale Verfügbarkeit voraussetzen, bieten jedoch kürzere Zugriffszeiten. Der Entscheidung, 

ob der Cognos Transformer Kits eingesetzt wird, liegt bei der Teilgruppe. 

5.4 Arbeitspaket 4: Prognose 

Im Arbeitspaket 4 geht es um die Erstellung von Prognosen auf Basis der Umfrageergebnisse. Aktuell 

werden keine IT-gestützten Prognosen auf Basis der Umfragewerte durchgeführt. Es erfolgt lediglich 

eine Auswertung im Bereich der deskriptiven Statistik mit QuestionPro. Die Marktforschung wertet 

diese Daten bisher manuell aus. 

Die Prognosen sollen in Zukunft mit Hilfe von IBM SPSS Modeler erstellt werden. Hierbei werden 

Data Mining Funktionen auf Basis der Daten bereits durchgeführter Umfragen verwendet, um so ein 

Performance Measurement durchzuführen. 

Der Vorteil von IBM SPSS ist, dass die Daten über den Modeler-Server aus Datenquellen wie Cognos, 

dem Data Warehouse oder SAP BW importiert und mit Ausnahme von SAP BW nach erfolgter Analyse 

mit neuen Scores basierend auf der Analyse auch wieder zurück exportiert werden können (siehe 

Abbildung 5.4). 

199



Abbildung 5.4: Aktuelle Struktur 

Durch die Analysen in IBM SPSS soll unter anderem untersucht werden, ob eine Frage von Bedeutung 

ist, wie groß der Rücklauf von Antworten sein muss, um diese sinnvoll auswerten zu können oder wie 

viele Kunden befragt werden müssen, um eine bestimmte Rücklaufmenge zu erhalten. Die Güte der 

Response soll anhand eines Scorings für Kunden ermittelt werden, um unter anderem zu identifizieren 

ob ein Kunde zu einem bestimmten Zeitpunkt für Umfragen empfänglich oder wie es generell um die 

Umfrageaffinität des Kunden bestellt ist. 

Die jeweils anzuwendenden Data-Mining Methoden für die verschiedenen Untersuchungen werden 

mit Herrn Eugen Neigel abgestimmt. 

Im Sinne des Closed-Loops sollen die erlangten Daten zum Zweck von Verbesserungsvorschlägen für 

die jeweiligen Abteilungen wie F&E oder Produktmarketing aufbereitet werden. Schließlich sollen 

etwaige Neuerungen mit den Kunden kommuniziert werden. Auf die von Handelspartnern gesetzten 

Einschränkungen ist hierbei besonders zu achten. 

Es ist eine angemessene Benutzerführung und Automatisierung in dem System zur zukünftigen Aufbereitung 

von Daten erforderlich. 

200



5.5 Arbeitspaket 5: Fragenpoolgenerierung 

Das Arbeitspaket 5 umfasst die Generierung eines Fragenpools, hat jedoch keine hohe Priorität. Auf 

Grund dessen ist dieses Arbeitspaket als optional bezeichnet worden und bildet eine zusätzliche Funktionalität, 

die im Rahmen des Projektes umgesetzt werden kann. 

Im Bereich der Fragenpoolgenerierung soll ein Katalog in Form einer Datenbank zur Ablage aller 

Fragen aus vergangenen, laufenden und zukünftigen Umfragen erstellt werden. Die Lagerung der Daten 

sieht zum aktuellen Zeitpunkt kein fixes System vor. Je nach Wahl des Systems (vorhandenes System 

oder neues System) ist der Arbeitsvorgang unterschiedlich. Ziel ist es, Fragen aus diesem Katalog 

zur Umfrageerstellung bereitzustellen, sodass Mitarbeiter von CEWE nicht für jede Umfrage neue 

Fragen generieren müssen, sondern auf bereits vorhandene Frage zurückgreifen können. 

Das Dialogsystem muss Funktionen zur Erfassung und Speicherung von Fragen beinhalten. Die Kategorisierung 

der Fragen ist ebenso wie eine eindeutige Kennzeichnung wünschenswert. 

6. Kennzahlen 

Im Folgenden werden gewünschte Kennzahlen aufgezeigt. Das Projektteam soll diese definieren und 

mit IBM Cognos in geeigneter Form darstellen. 

Bezeichnung Beschreibung Herkunft 

Send-Rate Anzahl der gesendeten Umfragen SAP CRM 

Open-Rate 

Anzahl geöffneter Umfragen 

(Landing-Page gesehen) 

QuestionPro 

Click-Through-Rate Anzahl gestarteter Umfragen QuestionPro 

Completion-Rate Anzahl abgeschlossener Umfragen QuestionPro 

Average-Cancelled-Rate 

Durchschnitt abgebrochener Umfragen, 

evtl. an welcher Frage 

Tabelle 6.1: Kennzahlen 

QuestionPro 

7. Scores 

Scores haben einen ähnlichen Charakter wie KPIs und werden zur Quantifizierung von Gegebenheiten 

in IBM SPSS eingesetzt. Sie werden entsprechend der Möglichkeiten in SPSS durch Prädiktoren und 

Indikatoren konstruiert und erweitert. 

201



Bezeichnung 

Prognostizierte Antwort 

Prognostizierter Rücklauf 

Umfrageaffinität 

Umfragezeitpunkt 

Beschreibung 

Erwarteter Antwortbereich auf Erfahrungsbasis 

Anteil erwarteter vollständig ausgefüllter Fragebögen 

Bereitschaft des Adressaten die Umfrage abzuschließen 

Wie lange liegt die vorige Umfrage zurück, wann kann dem 

Konsument wieder eine Umfrage zugesendet werden? 

Tabelle 7.1: Scores 


Eine semantische Modellierung ist zum aktuellen Stand nicht durchführbar, denn diese ist an die abzubildenden 

Systeme gebunden. Abhängig von der Bewertung und der Entscheidung für die einzusetzenden 

Technologien werden individuelle Modelle erarbeitet. 

Für das präferierte Dialogsystem im Rahmen des Arbeitspaketes 5 wird ein Datenmodell basierend auf 

den Anforderungen von CEWE zur Umsetzung des Fragenkatalogs erstellt. 

Ferner wird ein weiteres Datenmodell für das Arbeitspaket 2 zur Lagerung der Ergebnisse abgeschlossener 

Umfragen, welches in der Oracle Datenbank realisiert wird, erstellt. 

Schließlich ist für den IBM SPSS Modeler eine semantische Modellierung für Prognosen auf Basis der 

historischen Umfrageergebnisse notwendig, um neue Erkenntnisse zu gewinnen. 

9. Nichtanalytische Anforderungen 

Anforderungen an die Benutzerfreundlichkeit, wie etwa die intuitive Bedienbarkeit sowie die Vermeidung 

unnötiger „Klicks“ und Tastatureingaben sollen berücksichtigt werden. Weiterhin ist eine konsistente 

Menüführung und eine Verwendung sinnvoller Vorgabewerte umzusetzen. Die Benutzerfreundlichkeit 

steht bei der Erarbeitung stets im Vordergrund. Sollte das Dialogsystem mit entsprechenden 

Eingabemasken umgesetzt werden, steht in jedem Fall die Wahrung der Effizienz, der vom Anwender 

genutzten Arbeitsabläufe im Fokus. 

202


CEWE „gestochen scharfe Fragen stellen“ – DV-Konzept 



Gruppe: CEWE 

DV-Konzept 

203


CEWE „gestochen scharfe Fragen stellen“ – DV Konzept 

204



Inhaltsverzeichnis CEWE DV-Konzept 




1. Gesamtüberblick .............................................................................................................. 208 

2. Ist-Zustand ....................................................................................................................... 209 

2.1 Software ...................................................................................................................... 209 

2.2 Prozess ........................................................................................................................ 209 

2.3 Architektur .................................................................................................................. 209 

3. Soll-Zustand ..................................................................................................................... 211 

3.1 Software ...................................................................................................................... 211 

3.2 Prozess ........................................................................................................................ 216 

3.3 Architektur .................................................................................................................. 216 

3.4 Verfügbarkeit .............................................................................................................. 217 

3.5 Voraussetzungen......................................................................................................... 217 

3.5.1 Software ........................................................................................................... 217 

3.5.2 Hardware ......................................................................................................... 217 

3.5.3 Daten ................................................................................................................ 217 

4. Realisierung ..................................................................................................................... 218 

4.1 Arbeitspaket 1: Umfrageerstellung ............................................................................. 218 

4.1.1 Auswahl des Umfragetools .............................................................................. 218 

4.1.2 Erfassung von Umfragen im CRM .................................................................. 218 

4.1.3 Genehmigungs- und Freigabeprozess .............................................................. 221 

4.2 Arbeitspaket 2: Ergebnisdatenlagerung ...................................................................... 221 

4.3 Arbeitspaket 3: Berichtswesen ................................................................................... 223 

4.4 Arbeitspaket 4: Prognose ............................................................................................ 226 

4.5 Arbeitspaket 5: Fragenpoolgenerierung ..................................................................... 227 

5. Literaturverzeichnis ......................................................................................................... 229 

Anhang ................................................................................................................................... 230 

A. Ist-Prozess ........................................................................................................................ 230 

B. Soll-Prozess ..................................................................................................................... 232 

C. Kriterienkatalog ............................................................................................................... 236 

D. ER-Modell ....................................................................................................................... 237 

E. Star-Schema ..................................................................................................................... 237 

205




Abbildung 1.1: Projektüberblick ............................................................................................ 208 

Abbildung 2.1: Aktuelle Verfahrensweise ............................................................................. 210 

Abbildung 3.1: Marketingkalender im SAP CRM ................................................................. 211 

Abbildung 3.2: OWB Komponenten ...................................................................................... 213 

Abbildung 3.3: Zu realisierendes erweitertes Entity Relationship Modell (ERM)-Schema .. 215 

Abbildung 3.4: Angeforderte Verfahrensweise ..................................................................... 216 

Abbildung 4.1: Export-Funktion in QuestionPro ................................................................... 219 

Abbildung 4.2: Umfrage als PDF-Dokument für ein Kampagnenelement hochladen .......... 219 

Abbildung 4.3: Angehängtes PDF-Dokument ....................................................................... 220 

Abbildung 4.4: Umfrage als URL für ein Kampagnenelement hinterlegen .......................... 220 

Abbildung 4.5: Direkter Link zum Bearbeiten der Umfrage, mit ID ..................................... 220 

Abbildung 4.6: Angehängte URL .......................................................................................... 221 

Abbildung 4.7: Datenwege ..................................................................................................... 221 

Abbildung 4.8: Klassendiagramm .......................................................................................... 222 

Abbildung 4.9: ERM Schema ................................................................................................ 223 

Abbildung 4.10: Vorlage der Berichte ................................................................................... 225 

Abbildung 4.11: Tab01: Umfrage erstellen ............................................................................ 227 

Abbildung 4.12: Tab02: Fragen kategorisieren ...................................................................... 228 

Abbildung 4.13: Tab03: Kategorien erstellen ........................................................................ 228 

Abbildung 4.14: Tab04: Anzeige kategorisierter Fragen ....................................................... 228 

Abbildung 4.15: Tab05: Anzeige hierarchisierter Kategorien ............................................... 228 

Abbildung A.1: Grafik Ist-Prozess ......................................................................................... 231 

Abbildung B.1: Grafik Soll-Prozess ....................................................................................... 235 

Abbildung C.1: Machbarkeitsanalyse .................................................................................... 236 

Abbildung C.2: Ergebnis Machbarkeitsanalyse ..................................................................... 236 

Abbildung D.1: Erstes ER-Model .......................................................................................... 237 

Abbildung E.1: Erstes Star-Schema ....................................................................................... 237 


Tabelle 4.1: Kennzahlen ......................................................................................................... 226 

Tabelle 4.2: Scores ................................................................................................................. 227 

206




AG 

B2C 

BI 

BW 

CRM 

DB 

ERM 

ETL 

GUI 

ID 

IT 

KPI 

OHG 

PL/SQL 

REST 

SKM 

SOAP 

SQL 

URL 

XML 

Aktiengesellschaft 

Business to Customer 

Business Intelligence 

Business Warehouse 

Customer Relationship Management 

Datenbank 

Entity Relationship Modell 

Extraktion, Transformation, Laden 

Graphical User Interface 

eindeutige Identifikationsnummer 

Informationstechnologie 

Key Performance Indicator 

Offene Handelsgesellschaft 

Procedural Language/ SQL 

Representational state transfer 

Standard-Kosten-Modell 

Simple Object Access Protocol 

Structured Query Language 

Uniform Ressource Locator 

Extensible Markup Language 

207



1. Gesamtüberblick 

Die computergestützte Erfassung, Aufbereitung und Analyse von Daten zur Unterstützung der Entscheidungsfindung 

in einem Unternehmen ist zu einem relevanten Thema in der Informationstechnik 

geworden. Die Methoden der Business Intelligence (BI) können in verschiedenen Bereichen von Unternehmen 

zum Einsatz kommen und auch im Customer Relationship Management (CRM) nutzenbringend 

angewandt werden. Das Kundenverhalten lässt sich mittels CRM-Methoden erfassen, analysieren 

und durch gezielte Aktionen fördern und lenken, um neue Kunden zu gewinnen oder ein bereits 

bestehendes Kundenverhältnis durch angepasste Maßnahmen zu festigen. 

Unter dem Arbeitstitel „gestochen scharfe Fragen stellen“ befasst sich eine Gruppe von Studierenden 

der Carl von Ossietzky Universität Oldenburg mit dem Teilprojekt Analytisches CRM in Kooperation 

mit der CEWE COLOR AG & Co. OHG (CEWE). Ziel dieses Projektes ist eine Vereinheitlichung der 

computergestützten Prozesse und Systeme zur gezielten Umfrageerstellung. Der derzeitige Ablauf zur 

Erstellung einer Umfrage enthält mehrere systemübergreifende, manuelle Arbeitsschritte. Durch Einbeziehung 

vorhandener Analyseergebnisse in die Umfrageerstellung soll eine Vereinfachung der Arbeitsabläufe 

durch unmittelbare Verfügbarkeit relevanter Daten ohne Medienbrüche erreicht werden. 

Das Projekt reicht von der Umfrageerstellung über die Ergebnisdatenlagerung aus den Umfragen bis 

hin zu der Auswertung der Ergebnisse, mit Hilfe des Berichtswesens und mögliche Prognosen, die aus 

den Ergebnisdaten gewonnen werden können. Optional ist die Generierung eines Fragenpools, in welchem 

Mitarbeiter von CEWE Fragen erstellen, die wiederum für Umfragen genutzt werden können. 

Das gesamte Projekt ist auf sechs Monate verteilt. Den Grundgedanken des Projektes spiegelt Abbildung 

1.1 wider. 

Abbildung 1.1: Projektüberblick 

208



2. Ist-Zustand 

Dieses Kapitel beinhaltet die zur technischen Umsetzung des Projekts notwendigen Basisinformationen 

zum aktuellen Stand der CEWE. Hierbei wird zunächst ein Überblick zu dem Projekt gegeben, 

sowie der aktuell vorherrschende Prozess gezeigt, die derzeitige Architektur beschrieben, bestimmte 

Voraussetzungen erläutert und Ziele festgelegt. 

2.1 Software 

QuestionPro ist ein Produkt von Survey Analytics, ein 2002 gegründetes amerikanisches Unternehmen 

(vgl. QuestionPro 2012), welches eine Online-Plattform zur Erstellung und Auswertung von Umfragen 

bereitstellt. CEWE verwendet QuestionPro im Bereich Marketing zur Erstellung von Umfragen, zur 

Speicherung der Ergebnisse und zur Ad-hoc-Analyse der Ergebnisse. Neben QuestionPro setzt CEWE 

SurveyMonkey ein. Das gleichnamige Unternehmen stammt ebenfalls aus Amerika und wurde 1999 

gegründet (SurveyMonkey 2012). Das Unternehmen stellt wie QuestionPro eine Online-Plattform zur 

Verfügung, auf der Umfragen erstellt, bearbeitet, versendet und ausgewertet werden können. CEWE 

nutzt das Tool im Vertrieb, plant jedoch dies abzulösen. Weiterhin wird von CEWE die Software e- 

CRM der Firma hmmh eingesetzt. Das elektronische Customer Relationship Management erstellt individuelle 

Links zu den Umfragen, dabei werden in dem Link Informationen zu einem Kunden mittransportiert. 

Das eCRM wird vom Newsletterteam zum Versenden der Umfrage per Newsletter verwendet, 

um die Umfrage an die entsprechenden Kunden zu versenden. Im SAP CRM werden die 

Kundendaten verwaltet. 

2.2 Prozess 

Der aktuelle Umfrageprozess (siehe Anhang Ist-Prozess) sieht keine Anwendung von Business Intelligence 

vor und ist in Bezug auf die Verwendung des Umfragetools manuell gesteuert. Seitens CEWE 

findet lediglich eine manuell gesteuerte Anwendung des Systems durch die Marktforschung statt. Das 

Marketing führt dabei Ad-hoc-Analysen auf Basis der auf der Onlineplattform QuestionPro gespeicherten 

Daten (Umfrageergebnisse) durch. 

2.3 Architektur 

Die aktuelle, für den Umfrageprozess relevante Systemarchitektur, sieht lediglich eine Speicherung 

der Umfragen und deren Ergebnisse in einer Datenbank vor. Die Datenbank ist hierbei Eigentum von 

QuestionPro. Zwischen CEWE und QuestionPro findet kein Datenaustausch statt sondern ein reiner 

Business-to-Consumer (B2C) Service, bei dem CEWE als Kunde und QuestionPro als Anbieter fungiert. 

CEWE nutzt lediglich den Service von QuestionPro und arbeitet auf der zur Verfügung gestellten Onlineplattform, 

um die entsprechenden Umfragen zu erstellen und zu bearbeiten (siehe Abbildung 2.1). 

209



Abbildung 2.1: Aktuelle Verfahrensweise 

210



3. Soll-Zustand 

Im Folgenden wird auf die für das Projekt definierten Ziele eingegangen, welche von der Projektgruppe 

erreicht werden sollen. 

3.1 Software 

Nach einer von der Projektgruppe durchgeführten Analyse von verschiedenen Umfragetools, die anhand 

eines Kriterienkatalogs (siehe Anhang Kriterienkatalog) bewertet wurden, wurde QuestionPro als 

primäres Umfragetool ausgewählt. Das im Vertrieb genutzte Umfragetool SurveyMonkey wird somit 

in Zukunft von QuestionPro abgelöst werden. QuestionPro bietet die Möglichkeit, mit Hilfe von Representational 

State Transfer (REST) alle Daten zu Umfragen in ein Drittsystem zu laden. 

Das eCRM wird weiterhin so verwendet, wie es bisher eingesetzt wurde. Lediglich an den im Link 

versteckten Variablen können sich Änderungen durch CEWE ergeben. 

Das SAP CRM wird ebenfalls weiterhin verwendet, um dort die Kundendaten zu speichern. Neben der 

Speicherung von Daten wird der Marketingkalender im SAP CRM verwendet. In diesem gibt es die 

Möglichkeit alle bevorstehenden und vergangenen Marketing-Kampagnen zu pflegen (siehe Abbildung 

3.1), wodurch eine übersichtliche Ansicht zu aktuellen Kampagnen entsteht. Zu jeder Kampagne 

können weitere Notizen sowie Anhänge gespeichert werden. 

Quelle: Screenshot aus SAP CRM 

Abbildung 3.1: Marketingkalender im SAP CRM 

Neben den bisher verwendeten Technologien werden neue Technologien eingesetzt. Nachdem die 

Umfrage gestartet wird und bevor die Ergebnisse mit Hilfe von IMB Cognos und IBM SPSS analysiert 

werden können, werden die Daten in ein Oracle Datawarehouse bzw. in den Oracle Warehouse Builder 

(OWB) transportiert, denn Oracle ist bei der CEWE das führende System zur Datenhaltung. Der 

Transport der Daten findet hierbei über REST statt. 

REST ist ein Paradigma der Software-Architektur für Web-Applikationen. Im Gegensatz zum Simple 

Object Access Protocol (SOAP) ist es kein Protokoll zur Datenübertragung. REST hat die Zielsetzung, 

ein architektonisches Vorbild für die Funktionalität des Webs zu sein. Es soll als Grundlage für die 

211



Standardisierung von Web-Protokollen dienen. Eine Web-Applikation bzw. ein Webservice, die den 

Richtlinien von REST entsprechen, gelten als RESTful. 

REST dient der Verständigung zwischen Lokal- und Remote-Server. Anfrage und Bearbeitung von 

Web-Ressourcen des Remote-Systems wird dabei lediglich durch standardisierte HTTP-Methoden 

realisiert. Zwischen Remote- und Lokal-Server müssen keine Protokolle genutzt werden (Bayer 2002, 

Rodriguez 2008). 

Die zu verwendeten HTTP-Methoden sind: 

- GET: Erlaubt das Abrufen von bereits existierenden Objekten wie etwa Umfragen oder Umfrageergebnisse 

auf dem Remote-Server 

- POST: Erlaubt eine Bearbeitung von bereits existierenden Objekten auf dem Remote-Server 

- PUT: Erlaubt das Hinzufügen wie etwa Umfragen oder Fragen auf dem Remote-Server 

- DELETE: Erlaubt das Löschen von existierenden Objekten auf dem Remote-Server 

Die Darstellung der abgerufenen Daten bzw. der existierenden Objekte erfolgt allgemein über die 

leicht verständliche Repräsentation durch Extensible Markup Language (XML), kann aber auch in 

anderen Formaten erfolgen. 

Mittels REST werden die Daten dann aus QuestionPro in OWB geladen. OWB wird primär zur Konsolidierung 

von heterogenen Daten aus verschiedenen Datenquellen in ein Data Warehouse eingesetzt 

und ist als umfassendes Tool zur Datenintegration bekannt. Der Warehouse Builder bietet die Möglichkeit 

relationale und mehrdimensionale Modelle zu erstellen. Funktionen wie data profiling (Datenformungsfunktionen), 

data cleansing (Datenbereinigungsfunktionen) und data auditing (Datenprüfungsfunktionen) 

sind ebenfalls mit OWB einsetzbar. Durch Nutzung dieser Funktionen bietet OWB 

eine hohe Datenqualität und ermöglich ein Lifecycle-Management von Daten und Metadaten (vgl. 

Oracle 2009). 

Die nachfolgende Abbildung zeigt den Data Warehouse Builder und die zu dazu gehörenden Komponenten. 

212



Quelle: Oracle 2009 

Abbildung 3.2: OWB Komponenten 

Im Folgenden werden die einzelnen Komponenten und ihre Funktionen erläutert. 

Auf der Client-Seite der Komponenten zum OWB gibt es das Design Center und den Repository 

Browser. Das Design Center ist ein Graphical User Interface (GUI). Diese Benutzeroberfläche wird 

zum Import von Quellobjekten, zum Design des Extraction, Transformation, Load (ETL)-Prozesses 

z.B. von Mappings, zur Definition des Integrationsprozesses und zum Ansehen und Erstellen von Berichten 

verwendet. Ein Mapping im OWB-Kontext bedeutet das Festlegen des Datenflusses von der 

Quelle bis zum Ziel in einem Objekt. Basierend auf dem Mapping setzt OWB den ETL-Prozess um. In 

dem Mapping wird das Data Warehouse als Ziel definiert. Nachdem das Mapping erfolgt ist, wird ein 

Deployment vorgenommen, um das Zielschema/ die Datenbank zu erstellen. Das Deployment beinhaltet 

das Kopieren der Metadaten und des Codes in das Zielschema. Die Schnittstelle zwischen dem 

Zielschema und dem Design Center bildet der Control Center Manager, welcher mit der Datenbank 

(Zielschema) über den Control Center Service kommuniziert. Diese Schnittstelle ist wesentlich, um 

die Objekte zu implementieren und den Code auszuführen. Eine weitere GUI, die ebenso verwendet 

werden kann wie das Design Center ist der Repository Browser, eine webbasierte GUI. Zu den Komponenten 

der Server-Seite gehören das Control Center und die in der Oracle-Datenbank enthaltene 

Warehouse Builder Repository sowie das Target Schema. Das Control Center wird als Kommunikationsschnittstelle 

zwischen dem Design Center und der Datenbank verwendet. Die Datenbank beinhaltet 

den im Design Center generierten Code, Cubes, Dimensionen, Tabellen, Views, Mappings und Pakete 

zum Ausführen des ETL-Prozesses. Der Warehouse Builder Repository beinhaltet bestimmte Einstellungen 

sowie alle Daten aus dem Control Center (vgl. Oracle 2009). 

213



Folgende Merkmale bietet Oracle mit dem Warehouse Builder in Bezug auf die ETL-Funktionalitäten 

an (vgl. Oracle 2009): 

- Metadaten-basiertes Tool, erstellt Metadaten über 

o Systeme und deren innere Struktur (Tabellen, Views, Prozeduren…) 

o ETL-Datenflüsse (Mappings) 

- Diverse Quellsysteme und –formate nutzbar 

o Sowohl Oracle-Datenbanken als auch Datenbanken von Fremdanbietern 

o Trennzeichen-basierte Dateien 

o Applikationen wie SAP R/3 und Peoplesoft 8/9 

- Export in unterschiedliche Zielformate und -systeme 

o Oracle-Datenbanken 

o Trennzeichen-basierte Dateien und XML-Dateien 

o Business Intelligence Tools (BI Beans, Discoverer) 

o Prozessflusstools und Scheduler (Oracle Workflow) 

- Unterstützung von PL/SQL 

o Bereitstellung vordefinierter PL/SQL-Transformationen 

o Unterstützung und Erstellung individueller PL/SQL-Prozeduren, -Funktionen und - 

Packages 

- Erstellen von diversen Datenobjekten (Tabellen, Views, Materialized Views, externen Tabellen) 

Erstellen von dimensionalen Objekten (Dimensionen, Cubes) Bereitstellung und Steuerung von 

Prozessflüssen 

- Integration von performancesteigernden Funktionalitäten und Generierung von effizientem 

PL/SQL-Code 

o Parallele Prozessverarbeitung und mengenbasierter Datenimport (set based) 

o Partitionierung und Erstellung von Indizes 

o Nutzung des SQL2003-Standards mit neuen Operationen (z. B. Merge-Kommando) 

Die mit OWB im ETL Prozess bearbeiteten Daten, welche in einem Oracle Data Warehouse abgelegt 

werden, befinden sich in einem Datenschema, welches die Umfragen mit ihren Fragen, den entsprechenden 

Antworten und den im Umfragelink mitversendeten Kundenvariablen enthält. Jede Umfrage 

entspricht einem bestimmten Umfragetypen, etwa wie eine Sofortumfrage bezogen auf eine Bestellung 

oder eine in bestimmten Zeitabständen getätigte Umfrage in einem der von CEWE unterstützten Unternehmen, 

wie etwa Saturn oder dem dm drogerie markt. Jede Umfrage enthält verschieden viele 

Fragen, die in der Relation Frage abgelegt werden. In dieser Tabelle werden auf Grund der vorangestellten 

ID zu jeder Frage, Fragen wiederholt abgelegt. Zu jeder Frage werden Unterabfragen gespeichert. 

214



Als Unterabfrage wird die Auswahl zu einer Frage verstanden, z. B. die Frage: „Wie gefallen Ihnen 

die folgenden Produkte?“ hat die folgenden Unterabfragen: „a) Fotobuch b) Fotokalender c) Fototasse“. 

Jede Antwort auf die Fragen des Fragebogens wird mit der Fragen ID zusammen abgespeichert. 

Die Kundenvariablen, wie Kunden ID, Email-Adresse, etc. werden mit jeder Antwort abgespeichert, 

sodass eine Antwort eindeutig zu einem Kunden zugeordnet werden kann (siehe Abbildung 3.3). Die 

Anonymität wird insofern bewahrt, dass die persönlichen Daten eines Kunden in die Auswertung nicht 

mit einbezogen werden. 

Abbildung 3.3: Zu realisierendes erweitertes Entity Relationship Modell (ERM)-Schema 

Nachdem die Daten im Data Warehouse liegen, werden diese mittels IBM Cognos analysiert und mit 

Hilfe des Statistiktools IBM SPSS Modeler auf Basis von Algorithmen Prognosen erstellt. Cognos ist 

ein kanadischer Softwareanbieter, welcher von IBM gekauft wurde (vgl. Fournier & Miller 2012). 

IBM Cognos bietet unter anderem Softwarelösungen für Business Intelligence, Performance Management 

und Unternehmenskonsolidierung an (Cognos 2012). SPSS ist eine amerikanische Softwarefirma, 

die Statistik- und Analyse-Software entwickelt und vermarktet. Die Firma wurde von IBM übernommen 

(vgl. SPSS Inc. 2009). Der von CEWE eingesetzte IBM SPSS Modeler greift auf die in IBM 

Cognos erstellten Cubes zu und analysiert auf Basis dieser die Daten aus QuestionPro. 

215



3.2 Prozess 

Ziel ist es mit dem Projekt eine Optimierung des aktuellen Umfrageprozesses zu erreichen (siehe Anhang 

Soll-Prozess). Die manuellen Tätigkeiten, die aktuell Bestandteil des Prozesses sind, sollen mit 

Hilfe der entsprechenden Software unterstützt beziehungsweise auf ein Minimum beschränkt werden. 


Seitens der Architektur wird der neue Umfrageprozess in die bestehende Systemlandschaft integriert. 

Dazu werden die Umfrageergebnisse mittels Webservice in ein neues auf Oracle basierendes Data 

Warehouse transportiert. Das Data Warehouse wird von der Projektgruppe implementiert. Die dort 

gelagerten Daten werden mit IBM Cognos und IBM SPSS Modeler bearbeitet, um entsprechende Analysen 

und Prognosen aus den Ergebnissen zu erzeugen. 

Das Data Warehouse beinhaltet die Daten aus dem SAP CRM, welche für die Umfragen benötigt werden. 

Einige der in dem SAP CRM nachgehaltenen Daten werden bereits bei der Versendung der Umfragen 

benötigt und gehen in die per E-Mail versendete URL zur Umfrage ein. 

Die daraus resultierende Architektur wird in Abbildung 3.4 dargestellt. 

Abbildung 3.4: Angeforderte Verfahrensweise 

216



3.4 Verfügbarkeit 

Der von der Projektgruppe definierte neue Prozess ist im Punkt Verfügbarkeit abhängig von der verwendeten 

Software. Das Data Warehouse als solches soll, wie auch andere Systeme, zu 99,9% verfügbar 

sein, dies entspricht einer Ausfallzeit von max. 15 Stunden im Jahr. Der Prozess ist solange anwendbar, 

wie die Systeme und die verantwortlichen Mitarbeiter vorhanden sind. 

3.5 Voraussetzungen 

In dem Projekt müssen bestimmte Voraussetzungen zur Umsetzung bezüglich Software, Hardware 

und Daten gegeben sein und beachtet werden. Diese Voraussetzungen werden im Folgenden erläutert. 

3.5.1 Software 

Seitens der Software müssen die Zugriffe auf die jeweiligen Systeme gegeben sein. Ein Zugriff auf die 

Kundendaten im SAP CRM und SAP BW, sowie entsprechende Zugriffe auf IBM Cognos und IBM 

SPSS Modeler müssen für das Projektteam seitens CEWE eingerichtet werden. Weiterhin muss es 

dem Projektteam ermöglicht werden auf die bisher bestehenden QuestionPro-Daten zuzugreifen, um 

mit diesen Arbeiten zu können. 

3.5.2 Hardware 

Die von CEWE zur Verfügung gestellte Hardware in Form von Laptops und VPN-Token, müssen so 

ausgestattet sein, dass die genannte Software auf diesen ausgeführt werden kann. Ist dies nicht möglich, 

ist CEWE angehalten andere Lösungen anzubieten. 

3.5.3 Daten 

Aus QuestionPro werden Daten zu Umfragen über REST exportiert und mittels WSDL in einen 

Webservice des OWBs importiert. Bei den Daten handelt es sich um Datumswerte, textuelle und numerische 

Werte. 

Zurzeit existiert ein Datenvolumen von 100.000 Datensätzen pro Jahr, zukünftig wird mit 250.000 

Datensätzen pro Jahr gerechnet. Diese Schätzung beruht auf Erfahrungswerten des Marketingbereiches. 

Durch eine Timestamp-Abfrage und eine Prüfung der Question-Identifier werden mögliche Redundanzen 

eliminiert und die zu transportierenden Datensätze auf die noch nicht in der Oracle- 

Datenbank existierenden limitiert. 

Die aus QuestionPro exportierten Daten sind teilweise personalisiert. Die Vorschriften des Datenschutzgesetzes 

werden jedoch in der Projektarbeit nicht verletzt, da die personalisierten Daten nicht 

für die Auswertungen verwendet sondern lediglich in dem Data Warehouse gelagert werden. 

217



4. Realisierung 

Das Kapitel Realisierung beinhaltet die technische Umsetzung des Projekts. Die Realisierung wird wie 

schon im Fachkonzept auf Basis der Arbeitspakete erläutert. 

4.1 Arbeitspaket 1: Umfrageerstellung 

Das Arbeitspaket 1 umfasst die Umfrageerstellung sowie den Vergleich und die Analyse des Funktionsumfangs 

der Tools. Weiterhin ist in dem Arbeitspaket die kalendarische Erfassung von Umfragen 

enthalten sowie die Untersuchung für einen Genehmigungs- und Freigabeprozess. 

4.1.1 Auswahl des Umfragetools 

Die Auswahl des Umfragetools ist der primäre Schritt für den Start des Projektes. Es werden vier Umfragetools 

auf Funktionalität und Preis-/ Leistungsverhältnis anhand eines Kriterienkatalogs geprüft 

und ausführlich analysiert. Der Kriterienkatalog (siehe Anhang Kriterienkatalog) basiert auf Funktionen 

die vom Marketingbereich der CEWE als wichtig erachtet werden. Diese Funktionen werden nach 

Notwendigkeit gewichtet und anschließend bewertet. Die Untersuchungsergebnisse werden in einem 

Dokument (Machbarkeitsanalyse) festgehalten und dem Auftraggeber vorgestellt. Gemeinsam mit 

CEWE wird ein Umfragetool ausgewählt. 

4.1.2 Erfassung von Umfragen im CRM 

Die Aufgabe der Projektgruppe sieht es vor, ein Vorgehen für das Einpflegen von Surveys als Kampagnenelemente 

in den Marketingkalender zu erarbeiten. Dazu sind folgende Anforderungen zu erfüllen: 

- Die bestehende Hierarchie (Marketingplan Marketingplanelement Kampagne Kampagnenelement) 

muss beibehalten werden. 

- Eine übersichtliche Darstellung aller Umfragen muss ermöglicht werden. 

- Es ist notwendig, dass die Umfragen in irgendeiner Weise an die Kampagnenelemente (Umfrage 

oder Umfragen-Kampagne) angehängt werden, sodass Leser die Umfrage einsehen können 

und Bearbeiter die Möglichkeit haben, Änderungen direkt an der Umfrage vorzunehmen. 

Unter Einbehaltung der bereits erwähnten Hierarchieordnung ist es möglich, die Umfragen als Kampagne 

unter bereits vorhandenen Marketingplanelementen einzufügen (z.B. könnte eine Umfrage im 

Auftrag des Handelspartners dm dem Marketingplanelement KA – dm untergeordnet werden). Es ist 

weiterhin möglich unter dieser Kampagne die auszuführende Umfrage als Kampagnenelement einzutragen. 

An das Kampagnenelement können darüber hinaus Anhänge in Form von physisch vorhandenen Dateien 

bzw. URLs hinterlegt werden. 

218



Die Umfrage kann somit sowohl für Leser (als PDF-Datei) als auch für Bearbeiter (mittels Direktlink 

und einer eindeutigen ID) zur Verfügung gestellt werden. 

Damit ein Benutzer mit Leserechten die Möglichkeit hat innerhalb der Kampagnenelemente die Umfragen 

einzusehen, wird diese als PDF-Dokument hochgeladen. Somit ist eine reine Lesefunktion gewährleistet. 

Um dies zu ermöglichen muss die jeweilige Umfrage als PDF exportiert werden. QuestionPro 

bietet dafür einen unkomplizierten Weg an, in dem die jeweilige Umfrage geöffnet und per 

Export-Funktion als Adobe PDF-Dokument lokal abgespeichert wird (siehe Abbildung 4.1). 

Quelle: Screenshot aus QuestionPro 

Abbildung 4.1: Export-Funktion in QuestionPro 

Die lokal abgespeicherte Version der Umfrage kann als Anhang für das Kampagnenelement hochgeladen 

werden (siehe Abbildung 4.2). 


Abbildung 4.2: Umfrage als PDF-Dokument für ein Kampagnenelement hochladen 

Weiterhin kann das PDF-Dokument mit einem Klick auf den zugewiesenen Namen im Browser (notwendige 

Adobe PDF Reader-Plug-Ins vorausgesetzt) eingesehen werden (siehe Abbildung 4.3). 

219




Abbildung 4.3: Angehängtes PDF-Dokument 

Um Benutzern mit den notwendigen Rechten (Zugangsdaten zu QuestionPro) einen komfortablen Weg 

zur Bearbeitung der Umfrage zu gewährleisten, kann als Anhang neben dem PDF-Dokument auch die 

URL zur direkten Bearbeitung der Umfrage hinterlegt werden. 


Abbildung 4.4: Umfrage als URL für ein Kampagnenelement hinterlegen 

Dazu ist es notwendig, dass die URL zum Bearbeiten der Umfrage und nicht der Link zum Ausfüllen 

der Umfrage hinterlegt wird. Es ist somit erforderlich , die Umfrage im QuestionPro-Account aufzurufen 

und die URL aus der Adresszeile des Browsers zu kopieren. Die korrekte URL wird anhand 

der jeweiligen ID am Ende des Links erkannt (siehe Abbildung 4.5). 


Abbildung 4.5: Direkter Link zum Bearbeiten der Umfrage, mit ID 

Sobald die URL als Anhang hinterlegt wurde, kann sie mit einem Klick auf den Namen aufgerufen 

werden. 

220




Abbildung 4.6: Angehängte URL 

Falls die URL mit der korrekten ID hinterlegt wurde und eine Anmeldung bei QuestionPro vorgenommen 

wurde, wird die jeweilige Umfrage direkt per Klick geöffnet und kann bearbeitet werden. 

4.1.3 Genehmigungs- und Freigabeprozess 

Auf Grund der Projektumsetzung ohne SAP Technologien wird der Genehmigungs- und Freigabeprozess 

der Umfragen von dem Projekt nicht beeinflusst. Diese Arbeitsabläufe werden daher nicht im 

Laufe des Projektes angepasst sondern bleiben wie sie sind. 

4.2 Arbeitspaket 2: Ergebnisdatenlagerung 

Für die Ergebnisdatenlagerung werden die bereits vorhandenen bzw. historischen Daten aus Question- 

Pro mit Hilfe des Webservice REST in die CEWE Welt transportiert. Die Daten werden dabei nicht in 

OWB gehalten und bearbeitet, Grund hierfür ist, dass die Realisierung einer Webservice Anbindung 

mit REST und OWB nicht möglich. Die Daten werden daher mittels eines Java-Programmes und 

REST aus QuestionPro gelesen und anschließend mit SQL-Statements in dem Java-Quellcode in die 

Oracle-Datenbank geschrieben. 

Abbildung 4.7: Datenwege 

Der Quellcode besteht aus zwei Klassen: OracleDB.java und QPApi.java. Erstere beinhaltet die Verbindung 

zur Datenbank und Methoden zum Schreiben der Daten in die jeweiligen Tabellen. Die QPApi.java 

ist ein Beispielcode von QuestionPro, womit die Daten aus der REST-Schnittstelle abgerufen 

werden können. Die Klasse wurde angepasst und um eine weitere Methode ergänzt, die für das Herausladen 

der Daten und das direkte Schreiben in die Datenbank notwendig ist (siehe Abbildung 4.8). 

221



Abbildung 4.8: Klassendiagramm 

Die OracleDB.java beinhaltet mehrere Methoden, die im Folgenden näher beschrieben werden: 

- selektiereTabelle 

Diese Methode wird einen SELECT-Befehl auf die Datenbank ausführen. 

- aktualisiereTabelle 

Mit Hilfe dieser Methode wird es möglich sein Werte einer Tabelle zu aktualisieren. 

- pruefeWert 

Wird eine Boolean-Funktion sein, die überprüft, ob der jeweilige Wert in der Tabelle vorhanden 

ist oder nicht. 

Die Methoden schreibeInUmfrage, schreibeInFrage, schreibeInAntwortStammdaten, schreibeInAntwort, 

schreibeInCvar und schreibeInUmfrageFrage übergeben Parameter in die dafür vorgesehenen 

Tabellen der Oracle-Datenbank. 

Die Klasse GeneriereDatum.java soll dazu dienen, immer das aktuelle Datum und ein Datum, was 

einen Tag in der Vergangenheit liegt zu erhalten. Soll vor allem dem Abruf der Daten dienen und ist 

für Timestamps geeignet. 

222



Die QuestionPro Daten sind bei CEWE in dem folgenden Datenbankschema enthalten. 

Abbildung 4.9: ERM Schema 

Das Datenschema wird wie vorher gedacht umgesetzt jedoch ohne eine separate Relation für die Unterfragen. 

In das zu realisierende Modell werden außerdem die Ergebnissätze aufgenommen, welche 

von QuestionPro mitgeliefert werden und für Analysen interessant sein könnten. Weiterhin werden zur 

Umsetzung des fünften Arbeitspakets Relationen zur Kategorisierung der Fragen aufgenommen. 

Das Verfahren wird zunächst mit historischen, in QuestionPro vorhandenen Daten getestet und anschließend 

mit neuen Umfragedaten durchgeführt, um so einer Beschädigung aktueller beziehungsweise 

neuer Daten zuvorzukommen. 

4.3 Arbeitspaket 3: Berichtswesen 

Mit IBM Cognos Framework Manager werden die Cubes für die späteren Berichte und mit IBM SPSS 

durchzuführenden Analysen erstellt. Die für die Cubes relevanten Dimensionen müssen hierfür zunächst 

definiert werden. CEWE verfügt bereits über einige vorgefertigte Dimensionen, die für den aus 

den QuestionPro-Daten generierten Cube verwendet werden können. 

Die vorhandenen Dimensionen sind: 

223



- Produkt (CEWE Produkte wie Fotobuch, Kalender, etc.) 

- Handelspartner (Handelspartner wie Saturn, dm, etc.) 

- Konsumentenklassifikation (Einstufung der Kunden in Gold, Silber, Bronze etc.) 

- Zeit 

Neben diesen Dimensionen müssen weitere Dimension für z.B. Fragen und Antworten erstellt werden, 

damit die entsprechenden Daten-Cubes für Berichte und Analysen verwendet werden können. Mit 

IBM Cognos wird ein Bericht erstellt, der entsprechend gefiltert werden kann. Die Berichte umfassen 

neben den genannten Kennzahlen auch die Ad-hoc Analysen der Fragen in den jeweiligen Umfragen. 

Die einzelnen Fragen werden hierbei separat ausgewertet. 

Zu einer Auswertung gehören einerseits die Darstellung der einzelnen Fragen und andererseits die 

dazugehörigen Antwortmöglichkeiten. Die Antwortmöglichkeiten werden mit der Anzahl der gegebenen 

Antworten sowohl prozentual als auch statisch angezeigt. 

224



Abbildung 4.10: Vorlage der Berichte 

225



Die folgende Tabelle (Tabelle 4.1) sagt aus, wie die Kennzahlen berechnet werden und welche Variablen 

aus QuestionPro für die Berechnung benötigt werden. 

Bezeichnung Beschreibung Herkunft Berechnung Wert BSP 

Viewed 

Started 

Completed 

Send-Rate 

Open-Rate 

Click-Through- 

Rate 

Completion-Rate 

Average- 

Cancelled-Rate 

226 

Anzahl geöffneter Umfragen 

QuestionPro 

Anzahl gestarteter Umfragen 

QuestionPro 

Anzahl abgeschlossener 

QuestionPro 

Umfragen 

Anzahl der gesendeten 

SAP CRM 

Umfragen 

Anteil geöffneter Umfragen 

(Landing-Page IBM Cognos 

gesehen) 

Anteil gestarteter Umfragen 

IBM Cognos 

Anteil abgeschlossener 

IBM Cognos 

Umfragen 

Durchschnitt abgebrochener 

IBM Cognos 

Umfragen 

Tabelle 4.1: Kennzahlen 

keine 

keine 

keine 

keine 

(Viewed / Send- 

% 

Rate) 

(Started / Open- 

% 

Rate) 

Completed / 

% 

Open-Rate 

1-(Completed / 

% 

Open-Rate) 

Absolute 

Zahl 

Absolute 

Zahl 

Absolute 

Zahl 

Absolute 

Zahl 

2.000 

1.700 

1.500 

10.000 

2.000/ 

10.000 = 

20% 

1.700/ 

2.000 = 

85% 

1.500 / 

2.000 = 

75% 

1 – (1.500 / 

2.000) = 

25% 

Auf Grund der Priorisierung des 5. Arbeitspaketes von CEWE wurde die Arbeit am Berichtswesen 

eingestellt. Die Arbeiten im Framework-Manager werden weitestgehend fertiggestellt, einige kleiner 

Anpassungen oder Korrekturen müssten jedoch vorgenommen werden. Ein Bericht wird ebenfalls 

provisorisch angelegt, dieser befindet sich noch in der Rohfassung und müsste ebenfalls bearbeitet 

werden. Die weiterführenden Änderungen werden nach Ablauf der Projektgruppenzeit von CEWE 

übernommen. 

4.4 Arbeitspaket 4: Prognose 

Der von CEWE eingesetzte IBM SPSS Modeler greift auf die in IBM Cognos erstellten Cubes zu und 

analysiert auf Basis dieser die Daten aus QuestionPro. Die in IBM SPSS zu entwickelnden Streams 

werden von der Fachabteilung der CEWE erstellt. 

Die für Analysen mit IBM SPSS Modeler verantwortlichen Mitarbeiter erarbeiten hierbei ohne die 

Projektgruppe die Anforderungen und setzen diese mit IBM SPSS Modeler um. 

Die folgende Tabelle 4.2 beschreibt die geforderten Scores, die aus den Analysen mit IBM SPSS Modeler 

ermittelt werden sollen.



Bezeichnung 

Prognostizierte Antwort 

Prognostizierter Rücklauf 

Umfrageaffinität 

Umfragezeitpunkt 

Beschreibung 

Erwarteter Antwortbereich auf Erfahrungsbasis 

Anteil erwarteter, vollständig ausgefüllter und somit verwertbarer Fragebögen 

Bereitschaft des Adressaten die Umfrage abzuschließen 

Wie lange liegt die vorige Umfrage zurück, wann kann dem Konsument 

wieder eine Umfrage zugesendet werden? 

Tabelle 4.2: Scores 

4.5 Arbeitspaket 5: Fragenpoolgenerierung 

Arbeitspaket fünf beinhaltet die Fragenpoolgenerierung, hierbei wird ein Interface entwickelt mit dessen 

Hilfe Fragen in die Datenbank geschrieben und im Zuge dessen kategorisiert werden können. Fehler! 

Verweisquelle konnte nicht gefunden werden. zeigt einen ersten Entwurf, wie das Interface 

aussehen soll. Das Interface wird mit ExpressionWeb 4.0 in ASP.NET umgesetzt, welches mit der 

Datenbank über das in Arbeitspaket 2 erwähnte Java Programm kommuniziert. Mittels Qracle SQL 

werden die Daten aus der Datenbank im Interface angezeigt und vom Interface in die Datenbank hineingeschrieben. 

Die Kategorisierung der Fragen wird dabei mit Hilfe von Drop-Down-Feldern zu jeder einzelnen Frage 

einer Umfrage vorgenommen. Die Kategorisierung ist deshalb wichtig, weil ohne das versehen von 

Fragen mit Attributen eine umfrageübergreifende Analyse oder Berichterstattung nicht möglich bzw. 

nur über Text-Mining möglich ist. Text-Mining wird bei CEWE aktuell jedoch nicht eingesetzt, daher 

wird eine Kategorisierung der Fragen vorzunehmen. 

Das Interface liefert weiterhin eine Übersicht über die bestehenden Fragen und Kategorien und steuert 

das Schreiben von Fragen aus QuestionPro in die Datenbank mit dem Eintrag der UmfrageID im Interface 

(Abbildung 4.11). 

Abbildung 4.11: Tab01: Umfrage erstellen 

227



Abbildung 4.12: Tab02: Fragen kategorisieren 

Abbildung 4.13: Tab03: Kategorien erstellen 

Abbildung 4.14: Tab04: Anzeige kategorisierter Fragen 

Abbildung 4.15: Tab05: Anzeige hierarchisierter Kategorien 

228




Bayer, T. (2002): REST Web Services (PDF). URL: http://www.oio.de/public/xml/restwebservices.htm, 

(Zugriff am: 14.11.2012). 

Cognos (2012) Why Cognos software?. URL: http://www-01.ibm.com/software/analytics/cognos/, 

(Zugriff am: 07.11.2012). 

Fournier, C. & Miller, M. A. (2012): IBM to Buy Cognos for $4.9 Billion to Gain Software (Update6). 

URL: http://www.bloomberg.com/apps/news?pid=newsarchive&sid=aTUvC2z6S8MY, (Zugriff am: 

07.11.2012). 

Oracle (2009): Oracle® Warehouse Builder - User's Guide 11g Release 1 (11.1). URL: 

http://docs.oracle.com/cd/B31080_01/doc/owb.102/b28223.pdf, (Zugriff am: 12.11.2012) 

QuestionPro (2012): About Us. URL: http://www.questionpro.com/info/aboutUs.html, (Zugriff am: 

05.11.2012). 

Rodriguez, A. (2008): RESTful Web services: The basics. URL: 

http://www.ibm.com/developerworks/webservices/library/ws-restful/, (Zugriff am: 14.11.2012) 

SPSS Inc. (2009): About SPSS Inc. URL: http://www.spss.com.hk/corpinfo/history.htm, (Zugriff am: 

07.11.2012). 

SurveyMonkey (2012): About Us. URL: http://de.surveymonkey.com/mp/aboutus/directors/, (Zugriff 

am: 05.11.2012). 

229



Anhang 

A. Ist-Prozess 

230



Abbildung A.1: Grafik Ist-Prozess 

231



B. Soll-Prozess 

232



233



234



Abbildung B.1: Grafik Soll-Prozess 

235



C. Kriterienkatalog 

Quelle: Screenshot Machbarkeitsanalyse 

Abbildung C.1: Machbarkeitsanalyse 

Quelle: Screenshot Machbarkeitsanalyse 

Abbildung C.2: Ergebnis Machbarkeitsanalyse 

236



D. ER-Modell 

Abbildung D.1: Erstes ER-Model 

E. Star-Schema 

Abbildung E.1: Erstes Star-Schema 

237


CEWE „gestochen scharfe Fragen stellen“ – Machbarkeitsanalyse 

238





Gruppe: CEWE 

Machbarkeitsanalyse 

239



240



Inhaltsverzeichnis CEWE Machbarkeitsanalyse 



1. Kriterienkatalog ............................................................................................................... 248 

2. Survey Tool ..................................................................................................................... 250 

2.1 Design ......................................................................................................................... 250 

2.1.1 Buttons an CI anpassbar .................................................................................. 250 

2.1.2 Farben an CI anpassbar .................................................................................... 250 

2.1.3 Benutzerdefiniertes Layout.............................................................................. 250 

2.2 Fragenarten ................................................................................................................. 250 

2.2.1 Fragenart: Einfach-Nennung ........................................................................... 251 

2.2.1.1 Entscheidungsfrage ..................................................................................... 251 

2.2.1.2 Skalafrage .................................................................................................... 252 

2.2.1.3 Multiple-Choice: Choose ............................................................................ 252 

2.2.1.4 Tabelle ......................................................................................................... 252 

2.2.1.5 Offene Fragen .............................................................................................. 253 

2.2.2 Fragenart: Mehrfach-Nennung ........................................................................ 254 

2.2.2.1 Multiple-Choice: Check .............................................................................. 254 

2.2.2.2 Spreadsheet .................................................................................................. 254 

2.2.3 Umfrage-Templates ......................................................................................... 255 

2.2.4 Rating von Fragen ........................................................................................... 255 

2.3 Umfragefunktionen..................................................................................................... 256 

2.3.1 Willkommenstext............................................................................................. 256 

2.3.2 Branching/ Skip Logic ..................................................................................... 256 

2.3.3 Show/ Hide ...................................................................................................... 256 

2.3.4 Finish Options.................................................................................................. 257 

2.3.5 Pagebreak ......................................................................................................... 257 

2.3.6 Einbinden von Bildern als Antwortmöglichkeit .............................................. 257 

2.3.7 Alerting bei Kontaktanfrage ............................................................................ 257 

2.4 Organisatorisches ....................................................................................................... 258 

2.4.1 Strukturierte Anzeige von Umfragen .............................................................. 258 

2.4.2 Interne Variablen ............................................................................................. 258 

2.4.2.1 Vier frei nutzbare Variablen ........................................................................ 258 

2.4.2.2 Mehr als vier frei nutzbare Variablen ......................................................... 258 

2.4.3 Datenexport ..................................................................................................... 258 

2.4.4 Automatischer Datenexport ............................................................................. 259 

2.4.5 Automatische Auswertung .............................................................................. 259 

2.5 Administratives........................................................................................................... 259 

2.5.1 Status der Umfrage änderbar ........................................................................... 259 

2.5.2 Text bei Aufruf einer inaktiven Umfrage anpassbar ....................................... 259 

2.5.3 Generierung eines Links für Newsletter-/ Web-Umfragen ............................. 259 

2.5.4 Net Promoter Score Umsetzbar ....................................................................... 260 

2.6 Sonstiges ..................................................................................................................... 260 

2.6.1 Erweiterbarkeit durch Apps ............................................................................. 260 

2.6.2 Mobiler Zugang ............................................................................................... 260 

2.6.3 Support............................................................................................................. 260 

2.6.4 Dynamische Inhalte/ Möglichkeiten ................................................................ 260 

2.6.5 Dokumentation und andere Hilfsmittel ........................................................... 261 

241



3. QuestionPro ..................................................................................................................... 261 

3.1 Design ......................................................................................................................... 261 




3.2 Fragenarten ................................................................................................................. 262 



3.2.1.2 Skalafrage .................................................................................................... 263 

3.2.1.3 Multiple Choice: Choose ............................................................................. 264 

3.2.1.4 Tabelle ......................................................................................................... 264 

3.2.1.5 Offene Fragen .............................................................................................. 265 


3.2.2.1 Multiple Choice: Check .............................................................................. 266 

3.2.2.2 Spreadsheet .................................................................................................. 266 






3.3.3 Show/ Hide ...................................................................................................... 268 


3.3.5 Pagebreak ......................................................................................................... 269 







3.4.2.2 Mehr als vier nutzbare Variablen ................................................................ 271 

3.4.3 Datenexport ..................................................................................................... 272 






3.5.3 Generierung eines Links für Newsletter-/ Web-Umfragen ............................. 273 

3.5.4 Net Promoter Score umsetzbar ........................................................................ 274 

3.6 Sonstiges ..................................................................................................................... 274 



3.6.3 Support............................................................................................................. 274 



4. SurveyMonkey ................................................................................................................. 275 

4.1 Design ......................................................................................................................... 275 




4.2 Fragenarten ................................................................................................................. 276 

4.2.1 Fragenart: Einfachnennung .............................................................................. 277 

242




4.2.1.2 Skalafrage (hart/ weich) .............................................................................. 277 

4.2.1.3 Multiple Choice: Choose (eine Antwort) .................................................... 278 

4.2.1.4 Tabelle ......................................................................................................... 278 

4.2.1.5 Offene Fragen .............................................................................................. 278 


4.2.2.1 Multiple Choice: Check (mehrere Antworten) ............................................ 280 

4.2.2.2 Spreadsheet .................................................................................................. 280 






4.3.3 Show/ Hide ...................................................................................................... 282 


4.3.5 Pagebreak ......................................................................................................... 283 







4.4.2.2 Mehr als vier nutzbare Variablen ................................................................ 284 

4.4.3 Datenexport ..................................................................................................... 284 






4.5.3 Generierung eines Links für Newsletter-/ Web-Umfrage ............................... 285 

4.5.4 Net Promoter Score umsetzbar ........................................................................ 285 

4.6 Sonstiges ..................................................................................................................... 285 



4.6.3 Support............................................................................................................. 286 



5. SurveyGizmo ................................................................................................................... 287 

5.1 Design ......................................................................................................................... 287 




5.2 Fragenarten ................................................................................................................. 289 



5.2.1.2 Skalafrage .................................................................................................... 290 

5.2.1.3 Multiple-Choice: Choose ............................................................................ 291 

5.2.1.4 Tabelle ......................................................................................................... 291 

5.2.1.5 Offene Fragen .............................................................................................. 292 


5.2.2.1 Multiple-Choice: Check (mehrere Antworten) ........................................... 292 

243



5.2.2.2 Spreadsheet .................................................................................................. 292 






5.3.3 Show/ Hide ...................................................................................................... 294 


5.3.5 Pagebreak ......................................................................................................... 295 






5.4.2.1 Vier Frei Nutzbare Variablen ...................................................................... 297 

5.4.2.2 Mehr als Vier Frei Nutzbare Variablen ....................................................... 297 

5.4.3 DatenExport ..................................................................................................... 297 

5.4.4 Automatischer DatenExport ............................................................................ 298 





5.5.3 Generierung eines links für Newsletter- / Web-Umfragen .............................. 300 

5.5.4 Net Promoter Score Umsetzbar ....................................................................... 300 

5.6 Sonstiges ..................................................................................................................... 301 

5.6.1 Erweiterbarkeit durch apps .............................................................................. 301 


5.6.3 Support............................................................................................................. 301 



6. Ergebnis ........................................................................................................................... 303 

Anhang ................................................................................................................................... 304 

A. Supportanfrage SurveyMonkey 10.Oktober 2012 ........................................................... 304 

244




Abbildung 1.1: Kriterienkatalog ............................................................................................ 248 

Abbildung 1.2: Legende ......................................................................................................... 249 

Abbildung 1.3: Ergebnis ........................................................................................................ 249 

Abbildung 2.1: Fragetext ........................................................................................................ 250 

Abbildung 2.2: Antworttext ................................................................................................... 251 

Abbildung 2.3: Antwortoptionen ........................................................................................... 251 

Abbildung 2.4: Entscheidungsfrage ....................................................................................... 251 

Abbildung 2.5: Auswahl des Layouts .................................................................................... 252 

Abbildung 2.6: Skalafrage ...................................................................................................... 252 

Abbildung 2.7: Multiple Choice mit einer Antwort ............................................................... 252 

Abbildung 2.8: Tabellen-Frage .............................................................................................. 253 

Abbildung 2.9: Hinzufügen einer offenen Frage ................................................................... 253 

Abbildung 2.10: Offene Frage ............................................................................................... 254 

Abbildung 2.11: Multiple Choice mit mehreren Antworten .................................................. 254 

Abbildung 2.12: Spreadsheet ................................................................................................. 254 

Abbildung 2.13: Umfrage-Templates .................................................................................... 255 

Abbildung 2.14: Rating von Fragen ....................................................................................... 255 

Abbildung 2.15: Rating von Antworten ................................................................................. 256 

Abbildung 2.16: Willkommenstext ........................................................................................ 256 

Abbildung 2.17: Finish Options ............................................................................................. 257 

Abbildung 2.18: Anzeige von Umfragen ............................................................................... 258 

Abbildung 2.19: Statusänderung ............................................................................................ 259 

Abbildung 2.20: Linkgenerierung .......................................................................................... 260 

Abbildung 3.1: Anpassungen zu einer Umfrage .................................................................... 262 

Abbildung 3.2: Hinzufügen einer Frage ................................................................................. 263 


Abbildung 3.4: Bewertung ..................................................................................................... 264 

Abbildung 3.5: Kundenzufriedenheit ..................................................................................... 264 



Abbildung 3.8: Offene Fragen ............................................................................................... 265 

Abbildung 3.9: Freitextfläche ................................................................................................ 265 



Abbildung 3.12: Side-by-Side-Matrix.................................................................................... 266 



Abbildung 3.15: Branching/ Skip Logic ................................................................................ 268 

Abbildung 3.16: Show/ Hide .................................................................................................. 268 

Abbildung 3.17: Finish Options ............................................................................................. 269 

Abbildung 3.18: Pagebreak .................................................................................................... 269 

Abbildung 3.19: Datei hochladen ........................................................................................... 270 

Abbildung 3.20: Dateien als Antwortmöglichkeit ................................................................. 270 

Abbildung 3.21: Kontaktanfrage ............................................................................................ 270 

Abbildung 3.22: Alarmierungseinstellungen ......................................................................... 270 

Abbildung 3.23: Umfrageübersicht ........................................................................................ 271 

Abbildung 3.24: Automatische Auswertung .......................................................................... 272 

Abbildung 3.25: Statusänderung ............................................................................................ 273 

Abbildung 3.26: Linkgenerierung .......................................................................................... 273 

245



Abbildung 3.27: App-Erweiterung ......................................................................................... 274 

Abbildung 4.1: Buttonanpassbarkeit ...................................................................................... 275 

Abbildung 4.2: Farbenanpassbarkeit ...................................................................................... 276 

Abbildung 4.3: Layout-Anpassbarkeit ................................................................................... 276 

Abbildung 4.4: Fragentypen ................................................................................................... 277 

Abbildung 4.5: Fragentext ...................................................................................................... 277 





Abbildung 4.10: Offene Fragen ............................................................................................. 279 

Abbildung 4.11: Einstellungen zu offenen Fragen ................................................................. 279 

Abbildung 4.12: Freitext in verschiedenen Fragetypen ......................................................... 279 



Abbildung 4.15: Templates .................................................................................................... 281 


Abbildung 4.17: Branching/ Skip Logic ................................................................................ 282 

Abbildung 4.18: Bildanhang in Antworten ............................................................................ 283 

Abbildung 5.1: Code für Buttons ........................................................................................... 287 

Abbildung 5.2: GUI und Quellcode zur Farbanpassung ........................................................ 288 

Abbildung 5.3: Beispielhaftes Design 1 ................................................................................. 288 

Abbildung 5.4: Beispielhaftes Design 2 ................................................................................. 289 

Abbildung 5.5: Auswahl möglicher Fragen ........................................................................... 289 



Abbildung 5.8: Skalafrage: Vergabe von Sternen .................................................................. 291 

Abbildung 5.9: Multiple-Choice: Choose .............................................................................. 291 

Abbildung 5.10: Tabellen-Frage ............................................................................................ 291 

Abbildung 5.11: Offene Frage ............................................................................................... 292 

Abbildung 5.12: Multiple-Choice: Check .............................................................................. 292 




Abbildung 5.16: Logik-Editor bei Verzweigungen ................................................................ 294 

Abbildung 5.17: Logik-Editor zum Ein-/ Ausblenden von Fragen ........................................ 295 

Abbildung 5.18: Pagebreak .................................................................................................... 295 

Abbildung 5.19: Verschieben von Fragen und Seiten ............................................................ 296 

Abbildung 5.20: Mögliche Fragen mit Bildern (Screenshot aus SurveyGizmo) ................... 296 

Abbildung 5.21: Aktion Send Email mit Antwort der vorigen Frage verknüpft .................... 296 

Abbildung 5.22: Umfrageverwaltung .................................................................................... 297 

Abbildung 5.23: Exportmöglichkeiten ................................................................................... 298 

Abbildung 5.24: Beispiel für zusammenfassenden Bericht ................................................... 299 

Abbildung 5.25: Wahl des Umfragestatus ............................................................................. 299 

Abbildung 5.26: Text bei inaktiver Umfrage ......................................................................... 300 

Abbildung 5.27: Generierung von URL ................................................................................. 300 

Abbildung 5.28: Fragetyp NPS im Market Place ................................................................... 300 

Abbildung 5.29: Vorschau einer Umfrage auf Smartphones ................................................. 301 

Abbildung 6.1: Gegenüberstellung ........................................................................................ 303 

246




CI 

NPS 

Corporate Identity 

Net Promoter Score 

247



1. Kriterienkatalog 

Der abgebildete Kriterienkatalog wurde mit dem Marketing-Bereich der CEWE abgestimmt und auf 

Basis der Anforderungen an ein Umfragetool erstellt. Schwerpunkte der Anforderungen liegen in den 

Bereichen Design, Fragenarten, Umfragefunktionen, Organisatorisches und Administratives. 

Der Katalog wurde von der Teilgruppe, die keines der Systeme zuvor kannte und somit objektiv bewertet 

hat, ausgefüllt. Die Gewichtung der Kriterien wurde durch die verantwortlichen Mitarbeiter des 

Marketings ergänzt. 

Anforderung Gew. QuestionPro SurveyMonkey SurveyTool SurveyGizmo 

1 Design 

1.1 Buttons an CI anpassbar 1 2 1 1 3 

1.2 Farben an CI anpassbar 1 2 3 1 3 

1.3 Benutzerdefiniertes Layout 1 2 2 1 3 

2 Fragenarten 

2.1 Fragenart: Einfach-Nennung 

2.1.1 Entscheidungsfrage 5 3 3 3 3 

2.1.2 Skalafrage 5 3 3 3 3 

2.1.3 Multiple Choice: Choose 5 3 3 3 3 

2.1.4 Tabelle 5 3 3 3 3 

2.1.5 Offene Fragen 5 3 3 3 3 

2.2 Fragenart: Mehrfach-Nennung 

2.2.1 Multiple Choice: Check 5 3 3 3 3 

2.2.2 Spreadsheet 5 3 2 2 3 

2.3 Umfrage-Templates 1 3 3 2 3 

2.4 Rating von Fragen 1 0 0 3 0 

3 Umfragefunktionen 

3.1 Willkommenstext 5 3 3 2 3 

3.2 Branching/ Skip Logic 5 3 3 0 3 

3.3 Show/ Hide 5 3 1 0 3 

3.4 Finish Options 5 3 3 1 3 

3.5 Pagebreak 5 3 3 0 3 

3.6 Einbinden von Bildern als Antwortmöglichkeit 1 3 1 0 3 

3.7 Alerting bei Kontaktanfrage 5 3 0 3 3 

4. Organisatorisches 

4.1 Strukturierte Anzeige von Umfragen 5 3 2 2 3 

4.2 Interne Variablen 

4.2.1 Vier frei nutzbare Variablen 5 2 3 0 3 

4.2.2 Mehr als vier frei nutzbare Variablen 1 0 3 0 3 

4.3 Datenexport 5 3 3 3 3 

4.4 Automatischer Datenexport 5 2 0 3 3 

4.5 Automatische Auswertung 5 3 1 0 3 

5. Administratives 

5.1 Status der Umfrage änderbar 5 3 3 1 3 

5.2 Text bei Aufruf einer inaktiven Umfrage anpassbar 5 3 3 0 3 

5.3 Generierung eines Links für Newsletter-/ Web-Umfragen 5 3 1 3 3 

5.4 Net Promoter Score umsetzbar 5 3 0 3 3 

6. Sonstiges 

6.1 Erweiterbarkeit durch Apps 1 2 3 0 3 

6.2 Mobiler Zugang 1 0 1 0 3 

6.3 Support 5 3 2 3 2 

6.4 Dynamische Inhalte/ Möglichkeiten 1 0 0 0 1 

6.5 Dokumentation und andere Hilfsmittel 1 2 2 1 2 

Abbildung 1.1: Kriterienkatalog 

248



Legende 

Gewichtung: Wichtigkeit der Anforderung 

Punkteverteilung: 

0 = nicht unterstützt 

1 = ansatzweise unterstützt 

2 = teils unterstützt 

3 = umfassend unterstützt 

Abbildung 1.2: Legende 

QuestionPro SurveyMonkey Survey Tool SurveyGizmo 

Design 6 6 3 9 

Fragenarten 108 103 105 108 

Umfragefunktionen 90 66 30 90 

Organisatorisches 65 48 40 78 

Administratives 60 35 35 60 

Sonstiges 19 16 16 19 

Gesamt 348 274 229 364 

400 

350 

19 

19 

Sonstiges 

300 

60 

60 

Administratives 

Organisatorisches 

Umfragefunktionen 

Fragenarten 

250 

200 

150 

65 

90 

16 

35 

48 

66 

16 

35 

40 

30 

78 

90 

Design 

100 

50 

108 103 105 

108 

0 

6 6 3 9 

QuestionPro SurveyMonkey Survey Tool SurveyGizmo 

Abbildung 1.3: Ergebnis 

249



2. Survey Tool 

Der folgende Abschnitt stellt die Funktionen des Survey Tools der SAP AG dar und bewertet sie anhand 

der Anforderungen des Kriterienkataloges. Es handelt sich dabei um eine ins SAP CRM-System 

integrierte Anwendung zur Erstellung von Umfragen. Das Tool ist bisher nicht im Einsatz und müsste 

in den entsprechenden Bereichen eingeführt und geschult werden. 

2.1 Design 

2.1.1 Buttons an CI anpassbar 

CSS-Stylesheets könnten dementsprechend angepasst werden. 

Bewertung: 1 (ansatzweise unterstützt) 

2.1.2 Farben an CI anpassbar 



2.1.3 Benutzerdefiniertes Layout 



2.2 Fragenarten 

Ein Abschnitt kann einen Fragetext beinhalten, in dem die Fragen verfasst werden (siehe Abbildung 

2.1). 

Quelle: Screenshot aus Survey Tool 

Abbildung 2.1: Fragetext 

Eine Auswahl der Fragenart (Antwortkategorie) ist erst beim Hinzufügen von Antworttexten möglich 


250




Abbildung 2.2: Antworttext 

Um die Frage zu vervollständigen, müssen Antwortoptionen angelegt werden (siehe Abbildung 2.3). 


Abbildung 2.3: Antwortoptionen 

2.2.1 Fragenart: Einfach-Nennung 

2.2.1.1 Entscheidungsfrage 

Wenn die Antwortoption Ankreuzknopfgruppe ausgewählt und mit zwei Antwortoptionen ausgestattet 

wird, sind Entscheidungsfragen problemlos möglich (siehe Abbildung 2.4). 

Bewertung: 3 (umfassend unterstützt) 


Abbildung 2.4: Entscheidungsfrage 

251



2.2.1.2 Skalafrage 

Zum Erstellen von Skalafragen muss im ersten Schritt ein Unterabschnitt mit dem Layout Tabelle 

erstellt werden, um die horizontale Darstellung zu gewährleisten (siehe Abbildung 2.5). 


Abbildung 2.5: Auswahl des Layouts 

Daraufhin können Fragetexte im Unterabschnitt angelegt und im Antworttext die Antwortkategorie 

Ankreuzknopfgruppe mit vier (harte Skalafrage) bzw. fünf (weiche Skalafrage) Antwortoptionen ausgewählt 




Abbildung 2.6: Skalafrage 

2.2.1.3 Multiple-Choice: Choose 

Eine Frage mit der Antwortkategorie Ankreuzknopfgruppe und mehreren Antwortoptionen ermöglicht 

es, Multiple-Choise: Choose umzusetzen (siehe Abbildung 2.7). 



Abbildung 2.7: Multiple Choice mit einer Antwort 

2.2.1.4 Tabelle 

Zuerst ist ein Unterabschnitt mit dem Layout Tabelle notwendig (siehe Abbildung 2.5). 

252



Daraufhin können Fragetexte im Unterabschnitt angelegt und im Antworttext die Antwortkategorie 

„Ankreuzknopfgruppe“ mit der Anzahl gewünschter Antwortoptionen erstellt werden. 

Für jeden weiteren Fragetext in der Tabelle werden die Antwortoptionen des ersten Fragetextes übernommen. 



Abbildung 2.8: Tabellen-Frage 

2.2.1.5 Offene Fragen 

Wird eine Frage mit der Antwortkategorie Text angelegt, ist die Umsetzung einer offenen Frage mit 

Textfeld möglich. Die Maße des Feldes können anhand von numerischen Ziffern anhand der Pixel 

eingestellt werden (siehe Abbildung 2.9). 


Abbildung 2.9: Hinzufügen einer offenen Frage 

Wird in der Antwortoption ein Text eingepflegt, wird er als beschreibender Text neben dem Textfeld 

angezeigt. Unter Antwortvorbelegung kann ein bereits im Textfeld vorhandener Text eingegeben werden 


253




Abbildung 2.10: Offene Frage 

2.2.2 Fragenart: Mehrfach-Nennung 

2.2.2.1 Multiple-Choice: Check 

Auch dieser Fragentyp ist umsetzbar, dazu wird als Antwortkategorie Ankreuzfeldgruppe mit der Anzahl 

gewünschten Antwortoptionen angelegt (siehe Abbildung 2.11). 



Abbildung 2.11: Multiple Choice mit mehreren Antworten 

2.2.2.2 Spreadsheet 

Für Spreadsheets muss ein Unterabschnitt mit dem Layout Tabelle erstellt werden (siehe Abbildung 

2.5). 

Danach können je nach gewünschter Anzahl an Fragen, Fragetexte hinzugefügt werden. Der Antworttext 

wird mit der Antwortkategorie Listenfeld mit Einfachauswahl und den gewünschten Antwortoptionen 

angelegt. Es ist nicht möglich, Überschriften für die jeweiligen Spalten zu erstellen. 


Abbildung 2.12: Spreadsheet 

254



Bewertung: 2 (teils unterstützt) 

2.2.3 Umfrage-Templates 

Sofern eine Umfrage als Umfrage-Vorlage erstellt wird, die daraufhin kopiert wird, sind Umfrage- 

Templates umsetzbar (siehe Abbildung 2.13). Eine umfassende Unterstützung von Templates ist darüber 

hinaus nicht gegeben. 



Abbildung 2.13: Umfrage-Templates 

2.2.4 Rating von Fragen 

Es besteht die Möglichkeit beim Erstellen eines Fragetextes einen Bewertungsfaktor anzugeben (siehe 



Abbildung 2.14: Rating von Fragen 

Es ist darüber hinaus ebenfalls möglich, Antwortoptionen mit Bewertungen auszustatten (siehe Abbildung 

2.15). 

255




Abbildung 2.15: Rating von Antworten 


2.3 Umfragefunktionen 

2.3.1 Willkommenstext 

Ein Willkommenstext wird als solches nicht unterstützt. Es ist jedoch möglich einen Fragetext ohne 

Antworttexte und –optionen zu erstellen und darin den Willkommenstext zu hinterlegen. 



Abbildung 2.16: Willkommenstext 

2.3.2 Branching/ Skip Logic 

Möglichkeiten zur Weiterleitung bzw. Verzweigung werden nicht angeboten und müssten einprogrammiert 

werden. 

Bewertung: 0 (nicht unterstützt) 

2.3.3 Show/ Hide 

Ein- bzw. Ausblenden von Fragen wird nicht unterstützt. Auch hier wäre eine Programmierung im 

Nachhinein notwendig. 


256



2.3.4 Finish Options 

Mit Hilfe von Fragetexten kann ein Abschluss-Text verfasst und mit zwei vordefinierten Buttons zum 

Abschicken und Zurücksetzen der Umfrage ausgestattet werden. Darüber hinaus ist eine Unterstützung 

von Abschlusstexten nicht gegeben und wäre von der Landing-Page abhängig. 


Abbildung 2.17: Finish Options 

Weiterhin ist es nicht möglich, von der Abschlussseite auf bestimmte Seite zu verlinken, nach dem die 

Umfrage abgeschlossen wurde. 


2.3.5 Pagebreak 

Seitenumbrüche werden nicht angeboten, die Umfrage ist stets auf einer Seite. 


2.3.6 Einbinden von Bildern als Antwortmöglichkeit 

Bilder oder andere Multimedia-Dateien können nicht ohne weiteres in den Fragebogen integriert werden. 


2.3.7 Alerting bei Kontaktanfrage 

Mit Mike Dettmann abgesprochen. 


257



2.4 Organisatorisches 

2.4.1 Strukturierte Anzeige von Umfragen 

Es ist eine umfassende Suche nach Surveys im System möglich, die wiederum in einer Liste mit wesentlichen 

Attributen dargestellt werden. Es ist keine Baumstruktur o.ä. vorhanden (siehe Abbildung 

2.18). 



Abbildung 2.18: Anzeige von Umfragen 

2.4.2 Interne Variablen 

2.4.2.1 Vier frei nutzbare Variablen 

Der Einsatz von Variablen ist nicht möglich und wäre von einer davor geschalteten Landing-Page 

abhängig. 


2.4.2.2 Mehr als vier frei nutzbare Variablen 

Siehe vorigen Abschnitt. 


2.4.3 Datenexport 

Über einen Standard-Extraktor können die Daten im BW lokal gelagert werden. 


258



2.4.4 Automatischer Datenexport 

Über einen Standart-Extraktor können die Daten automatisiert ins BW geladen werden. 


2.4.5 Automatische Auswertung 

Für automatisierte Auswertungen werden ergänzende Produkte vorausgesetzt. Sämtliche Funktionen 

müssten entweder über SAP BW oder IBM Cognos laufen. 


2.5 Administratives 

2.5.1 Status der Umfrage änderbar 

Eine Umfrage kann über den „Aktivieren“-Button geöffnet werden. Bislang ist nicht bekannt, wie die 

Umfrage wieder geschlossen wird, da der Button daraufhin ausgegraut und nicht erneut betätigt werden 

kann. Möglicherweise sind umfassendere Benutzerrechte notwendig oder ein Schließen nur über 

festgelegte Termine möglich. 



Abbildung 2.19: Statusänderung 

2.5.2 Text bei Aufruf einer inaktiven Umfrage anpassbar 

Es besteht keine Möglichkeit einen Text für inaktive Umfragen anzupassen, diese Funktion ist abhängig 

von der Landing-Page. 


2.5.3 Generierung eines Links für Newsletter-/ Web-Umfragen 

Der Button zum „URL generieren“ ist nach Aktivierung der Umfrage bedienbar. Es öffnet sich ein 

Webseitendialog, wo anhand einiger Angaben eine URL erstellt wird. 

259





Abbildung 2.20: Linkgenerierung 

2.5.4 Net Promoter Score Umsetzbar 

Mit Mike Dettmann abgesprochen. 


2.6 Sonstiges 

2.6.1 Erweiterbarkeit durch Apps 

Es besteht keine Möglichkeit externe Applikationen ohne weiteres zu nutzen, da alle gewünschten 

Erweiterungen einprogrammiert werden müssten. 


2.6.2 Mobiler Zugang 

Ein mobilen Zugang wird nicht angeboten und wäre nur über IBM Cognos auf die Auswertungen 

möglich. Die Umfragen können nicht mobil eingesehen bzw. bearbeitet werden. 


2.6.3 Support 

Der Support wird intern über Mike Dettmann ablaufen 


2.6.4 Dynamische Inhalte/ Möglichkeiten 

Hier fehlen sämtliche Funktionen. 


260



2.6.5 Dokumentation und andere Hilfsmittel 

Es werden rudimentäre Dokumentationen seitens SAP angeboten, die übers Internet abgerufen werden 

können. Es wäre zudem möglich, dass SAP Help Center und das Forum für Fragen und Probleme zu 

nutzen. 

Bewertung: 1 (ansatzweise unterstützt 

3. QuestionPro 

Der folgende Abschnitt stellt die Funktionen des Umfragetools QuestionPro dar. Das Tool wird bereits 

von CEWE genutzt und von den Mitarbeitern als bevorzugtes Tool bewertet. 

3.1 Design 


Die Buttons in QuestionPro sind standardmäßig vorgegeben und passen sich dem ausgewählten Thema 

(Layout) an. Es bestehen Anpassungsmöglichkeiten bezüglich des Schriftzugs auf dem Button, die 

in einem Menü geändert werden können. Weiterhin besteht die Möglichkeit zu entscheiden ob bestimmte 

Buttons in der Umfrage eingeblendet werden sollen. Eine Anpassung durch HTML und CSS 

im Layout ist ebenfalls möglich (siehe Abbildung 3.1). 



QuestionPro verwaltet einige vordefinierte Farben und Themenkategorien für Umfragen. Neben einer 

Auswahl aus diesen ist mittels HTML-Code auch eine benutzerdefinierte Anpassung möglich. (siehe 

Abbildung 3.1) 


261




Eine benutzerdefinierte Anpassung der Umfrage an die vom Unternehmen definierte CI ist über den 

bereits erwähnten HTML-Code möglich (siehe Abbildung 3.1). 

Quelle: Screenshot aus Question Pro 

Abbildung 3.1: Anpassungen zu einer Umfrage 



QuestionPro unterstützt verschiedene Fragenarten. Die Fragen werden hierbei als autonome Objekte in 

die Umfrage hinzugefügt. Die verschiedenen Fragetypen können über Add question im Umfrageeditor 

ausgewählt und hinzugefügt werden. Die verschiedenen Fragenarten sind nach Auswahl im linken 

Bildschirmrand aufgelistet und können im rechten Bildschirmbereich bearbeitet werden (siehe Abbildung 

3.2). 

Bereits erstellte Fragen können aus einem Fragenkatalog ausgewählt und der aktuellen Umfrage hinzugefügt 

werden. Bereits vorhandene Fragen können inhaltlich verändert werden. Ein Wechsel zu 

einer neuen Frageart ist hier nicht gegeben. 

262




Abbildung 3.2: Hinzufügen einer Frage 

Im Folgenden werden die für die Entscheidungsfindung des richtigen Umfragetools relevanten Fragenarten 

nach einfach und mehrfach Nennung unterschieden. 



Mit der Auswahl einer Multiple-Choice-Frage mit nur einer Antwortmöglichkeit können Entscheidungsfragen 

über Add Question in den Einstellung unter Multiple Choice - >Select one in die Umfrage 

eingebunden werden (siehe Abbildung 3.3). 





Zur Erstellung einer Skalafrage bietet das Tool verschiedenen Möglichkeiten. Zwei der Varianten sind 

im Folgenden dargestellt. Die erste Variante zeigt eine Bewertung des Kunden im Schulnotensystem 

263



(siehe Abbildung 3.4), welcher unter dem Menüpunkt Add Question -> Matrix table -> Ordering/ 

Rating im Umfrageeditor zu finden ist. 


Abbildung 3.4: Bewertung 

Die zweite Variante zweigt eine Bewertung auf einer Skala von 0-10 (Abbildung 3.5), welches in 

QuestionPro unter dem Menüpunkt Customer Satisfaction angesiedelt ist. 


Abbildung 3.5: Kundenzufriedenheit 

Neben diesen Varianten ist es ebenfalls möglich ein solches Verfahren über eine Tabelle zu lösen. 


3.2.1.3 Multiple Choice: Choose 

Dieser Fragetyp ist über Add Question -> Multiplce Choice auswählbar. Die folgende Abbildung 

zeigt eine solche Frage (Abbildung 3.6). Die Zahl der Antwortmöglichkeiten ist hierbei nicht begrenzt. 





Eine Abfrage mehrerer Elemente kann im Stil einer Tabelle erfolgen, dabei ist pro Zeile nur eine Antwortmöglichkeit 

zugelassen. 

264







Die Möglichkeit offene Fragen zu stellen besteht mit QuestionPro, das Tool bietet auch hier verschiedene 

Möglichkeiten an. Neben der Comment Box (siehe Abbildung 3.8) gibt es weitere Darstellungsoptionen. 

Dazu zählt die Option Single Row Text welche nur eine Zeile für den Antworttext zuzulassen 

oder Numeric Input für die Eingabe eines nummerischen Wertes sowie die Möglichkeit über 

Email Address eine E-Mail Adresse abzufragen. Weiterhin besteht die Möglichkeit eine Freitextfläche 

in andere Fragenarten einzubinden (siehe Abbildung 3.9) 


Abbildung 3.8: Offene Fragen 



Abbildung 3.9: Freitextfläche 

265




3.2.2.1 Multiple Choice: Check 

Neben den Multiple-Choice-Fragen mit einfacher Nennung gibt es auch Fragen mit mehreren Antwortmöglichkeiten, 

die von QuestionPro unterstützt werden, wie Abbildung 3.10 zeigt. Eine solche 

Checkbox kann über Add Question -> Matrix Table -> Checkbox / Multi-Select eingerichtet werden. 

Die Fragen und Antwortmöglichkeiten können in unterschiedlich vielen Zeilen und Spalten eingerichtet 

werden. 





Weiterhin erlaubt QuestionPro neben der Tabellenfunktion mit nur einer Antwortmöglichkeit auch 

eine Funktion mit mehreren Antworten in einer Tabelle. QuestionPro unterscheidet hierbei zwischen 

Tabellen mit Checkboxen, Auswahlfeldern (siehe Abbildung 3.11), einer Side-by-Side-Matrix (siehe 

Abbildung 3.12) und einem Skale-Slider, die in Tabellen eingebunden werden können. Ein Spreadsheet 

wird über Add Question -> Matrix Table -> Spreadsheet der Umfrage hinzugefügt. 




Abbildung 3.12: Side-by-Side-Matrix 

266





Bevor eine neue Umfrage angelegt wird, kann auf ein bereits bestehendes Umfragetemplate zugegriffen 

werden. Weiterhin besteht die Möglichkeit Umfragen aus Microsoft Word zu integrieren oder in 

der Umfrage auf bereits bestehende Fragen aus der Fragenbibliothek zuzugreifen. 





Es ist möglich, den verschiedenen Antwortmöglichkeiten einzelner Fragen eine Wertung zu geben. 

Die Gesamtauswertung der Antworten kann später über die allgemeine Auswertung der Umfrage vorgenommen 

bzw. eingesehen werden. 




Ein Willkommenstext inklusive der Einrichtung einer Checkbox für etwaige AGB kann in Question- 

Pro erstellt werden (siehe Abbildung 3.14). 




267




Das Umfragetool bietet die Möglichkeit für jede einzelne Frage individuelle Logikeinstellungen vorzunehmen 

(siehe Abbildung 3.15). Es ist möglich ein Branching für jede Frage im Umfrageeditor separat 

zu definieren. Es kann ausgewählt werden, bei welcher Antwortmöglichkeit der Frage was passieren 

soll. Dafür stehen mehrere Jump-Funktionen wie Survey Questions, Terminate Survey, Go To 

Thank You page oder Chain Survey zur Verfügung. 



Abbildung 3.15: Branching/ Skip Logic 


Neben verschiedenen Logikeinstellungen bietet QuestionPro auch die Möglichkeit einzelne Fragen je 

nach gegebener Antwort ein- oder auszublenden. 



Abbildung 3.16: Show/ Hide 

268




Nach dem individuell erstellten Willkommenstext bietet QuestionPro auch die Möglichkeit einen individuellen 

Abschlusstext zu verfassen, welcher die Umfrage beendet. Ebenso sind weitere Einstellungen 

wie u.a. eine direkte Weiterleitung zu einer bestimmten Webseite, zu weiteren Umfragen oder der 

Anzeige eines Spotlight Reports über die gegebenen Antworten möglich. 



Abbildung 3.17: Finish Options 


In einer Umfrage kann nach jeder Frage ein Seitenumbruch eingestellt werden (siehe Abbildung 3.18), 

dies bietet sich an, da QuestionPro ein auf Seitenbasis angelegtes Umfragetool ist. Neben der Möglichkeit 

eines Seitenumbruchs, gibt es die Variante eine bestimmte Anzahl an Fragen pro Seite anzeigen 

zu lassen. Zur nächsten Frage wird über den „Weiter“-Button navigiert. 



Abbildung 3.18: Pagebreak 


QuestionPro unterstützt das Hochladen von Bild-, Video- und Audiodateien mit der Funktion Upload 

unter weitere Fragenarten. 

269




Abbildung 3.19: Datei hochladen 

Nicht nur der Kunde kann Dateien als eine Antwortmöglichkeit auf eine Frage hochladen, es ist weiterhin 

möglich Bilder als Antwortmöglichkeit anzugeben, aus welchem der Kunde seine Antwort wählen 

kann, etwa bei der Zahlungsart (siehe Abbildung 3.20). 



Abbildung 3.20: Dateien als Antwortmöglichkeit 


QuestionPro stellt standardmäßig alle E-Mail Benachrichtigungen, wie auch Alarmierungen aus, sind 

solche Funktionen gewünscht, so müssen sie entsprechend aktiviert werden (siehe Abbildung 3.21). 


Abbildung 3.21: Kontaktanfrage 

Sollte eine Alarmierung gewünscht sein, so kann diese wie Abbildung 3.22 zeigt entsprechend konfiguriert 

werden. 

270 


Abbildung 3.22: Alarmierungseinstellungen






Eine strukturierte Anzeige aller Umfragen stellt QuestionPro unter dem Punkt „Surveys“ zur Verfügung. 

Alle angelegten Fragen werden hier als Liste dargestellt (siehe Abbildung 3.23). 



Abbildung 3.23: Umfrageübersicht 



Die Möglichkeit in einer E-Mail definierte Variablen zur Personalisierung der Umfrageergebnisse zu 

verwenden ist gegeben. Die Anzahl der Variablen ist jedoch beschränkt. Die Erweiterung dieser Anzahl 

von Variablen wäre über eine Veränderung des Quellcodes beim Senden der E-Mail möglich. 


3.4.2.2 Mehr als vier nutzbare Variablen 

Die Möglichkeit mehr als vier Variablen einzubinden ist gegebenenfalls über ein entsprechendes 

Coding zu erreichen. 


271




QuestionPro ermöglicht einen Datenexport der Umfragen und der Analysen in verschiedenen Dateiformaten, 

darunter fallen: 

- *.xlsx 

- *.csv 

- *.docx 

- *.sav (IBM SPSS File) 

- *.pptx 



Ein automatischer Datenexport der Ergebnisse ist nur mit einer entsprechenden Lizenz möglich. 



Es besteht die Möglichkeit eine Vielzahl an automatischen Auswertungsmöglichkeiten direkt in QuestionPro 

zu nutzen. Dazu zählen sowohl tabellarische Auswertungen als auch Diagramme. Eine Übersicht 

über alle Möglichkeiten zeigt Abbildung 3.24. 



Abbildung 3.24: Automatische Auswertung 

272





QuestionPro bietet die Möglichkeit eine Umfrage aktiv oder geschlossen zu setzten. Ist die Umfrage 

aktiv, so kann jeder auf diese zugreifen. Im Fall einer geschlossenen Umfrage wäre ein entsprechender 

Zugriff nicht möglich. 



Abbildung 3.25: Statusänderung 


Im Fall eines Aufrufes einer bereits geschlossenen Umfrage, bietet das Tool die Möglichkeit einen 

individuellen Text einzublenden, welcher den Kunden darauf hinweist, dass diese Umfrage bereits 

geschlossen ist und somit nicht bearbeitet werden kann. 


3.5.3 Generierung eines Links für Newsletter-/ Web-Umfragen 

Ein Link für Newsletter-/ Web-Umfragen kann mit QuestionPro automatisch generiert werden. Es 

besteht weiterhin die Möglichkeit den Link über das Customizing (siehe Abbildung 3.26) entsprechend 

anzupassen. Das Tool bietet ebenfalls die Möglichkeit, den Link direkt über verschiedene soziale 

Netzwerke sowie über E-Mail und QR-Code zu verbreiten. 



Abbildung 3.26: Linkgenerierung 

273



3.5.4 Net Promoter Score umsetzbar 

Die Möglichkeit einen NPS zu definieren ist in QuestionPro gegeben. Jeder Antwortmöglichkeit kann 

eine Bewertung zugeordnet werden, wodurch sich ein NPS gengerieren lässt. Je nach Fragenart ist 

eine solche Bewertung automatisch hinterlegt oder muss noch angegeben werden. 


3.6 Sonstiges 


QuestionPro bietet einige Erweiterungsmöglichkeiten durch Apps (siehe Abbildung 3.27). Das Tool 

unterscheidet hierbei zwischen Custom Apps und Feedback Apps. Die Apps sind frei verfügbar. 



Abbildung 3.27: App-Erweiterung 


Ein mobiler Zugang zu QuestionPro ist bisher nicht vorgesehen. Über die App SurveyPocket kann 

allerdings auf den QuestionPro Account zugegriffen werden. 


3.6.3 Support 

QuestionPro bietet einen umfassenden Support mittels Telefon, E-Mai und Live-Chat an. Innerhalb 

einer Umfrage können ebenfalls Hilfestellungen in Form einer grafisch aufbereiteten Anleitung inkl. 

Videos durch den Frageersteller genutzt werden. 

274





Die Möglichkeit dynamische Inhalte oder Möglichkeiten in einer QuestionPro Umfrage einzusetzen 

gibt es bisher nicht. 

Bewertung: 0 (nicht unterstüzt) 


Neben der in der Anwendung integrierten Hilfe besteht die Möglichkeit die ausreicheichend dokumentierten 

FAQs zu nutzen. 


4. SurveyMonkey 

Der folgende Abschnitt stellt die Funktionen von SurveyMonkey dar. Das Umfragetool wird bereits 

von CEWE verwendet. 

4.1 Design 


Buttons sind zunächst vorgegebene Standardobjekte, die nicht unmittelbar bearbeitet werden können. 

Durch zugeschalteten HTML-Modus ließe sich eine Lösung durch benutzerdefinierte Elemente finden. 


Quelle: Screenshot aus SurveyMonkey 

Abbildung 4.1: Buttonanpassbarkeit 


Das Umfragedesign kann über einen elementbezogenen Editor angepasst werden. Jedes Element der 

Umfrage, wie der Hintergrund, die Schriftart und die Schriftgröße von allen vorkommenden Texten 

und die Farbe der vorgegebenen grafischen Objekte kann im 24-bit Web-Farbspektrum eingestellt 

werden. Benutzerdefinierte Designs können gespeichert und für weitere Umfragen verwendet werden. 

Die Einbindung eines Logos ist ebenfalls möglich. Der Editor ist eine Benutzeroberfläche für den unterliegenden 

HTML-Code, welcher auch direkt bearbeitet werden kann. Dies setzt Kenntnisse im Umgang 

mit HTML voraus, ermöglicht jedoch umfassendere Anpassungen (siehe Abbildung 4.2). 

275





Abbildung 4.2: Farbenanpassbarkeit 


Soweit keine weiteren Einstellungen vorgenommen wurden, legt SurveyMonkey Fragen in einem 

Standardlayout an. Alternativ ist es möglich, die Anordnung zu beeinflussen indem maximale Breite 

und das Abstandsverhältnis zwischen Fragetext und Antwortfeldern in Relation zur Fenstergröße justiert 

werden. Der absolute Abstand in Pixeln zu den Rändern der Frage und die Platzierung neben oder 

unter der vorigen Frage, erlauben weitere Formatierungsmöglichkeiten (siehe Abbildung 4.3). 


Abbildung 4.3: Layout-Anpassbarkeit 

Außerdem ist ein Einsatz von HTML möglich, um die Seite individueller zu gestalten. Es können weder 

JavaScript noch -Tags verwendet werden. 



Fragen werden als in sich geschlossene Objekte zu Seiten hinzugefügt. Der Typ kann nachträglich 

verändert werden, wobei bereits eingegebene Informationen erhalten bleiben (siehe Abbildung 4.4). 

276




Abbildung 4.4: Fragentypen 

Zuvor gestellte Fragen sind im Stil einer Eingabevervollständigung umfrageübergreifend vollständig 

wieder abrufbar. Es wird der gesamte Fragetext nach dem eingegebenen Begriffen durchsucht (siehe 



Abbildung 4.5: Fragentext 

4.2.1 Fragenart: Einfachnennung 


Per Multiple Choice (nur eine Antwort) werden Entscheidungsfragen umgesetzt (siehe Abbildung 4.6). 




4.2.1.2 Skalafrage (hart/ weich) 

Der Fragetyp Bewertungsskala bietet bis zu 16 Abstufungen und benutzerdefinierte Gewichtungen. So 

können angepasste Skalenfragen sowohl in harter (gerade Anzahl Antwortmöglichkeiten) als auch 

weicher Form (ungerade Anzahl Antwortmöglichkeiten) umgesetzt werden (siehe Abbildung 4.7). 

277






4.2.1.3 Multiple Choice: Choose (eine Antwort) 

Einfache Multiple-Choice-Fragen können wie Entscheidungsfragen als Multiple Choice (nur eine 

Antwort) mit entsprechenden Antwortmöglichkeiten erstellt werden (siehe Abbildung 4.8). 





Mehrere Elemente samt Antwortmöglichkeiten im Stil einer Tabelle können als Multiple Choice 

(mehrere Antworten pro Zeile) umgesetzt werden (siehe Abbildung 4.9). 





Offene Fragen können auf unterschiedliche Arten eingebunden werden. Zunächst kann der eigenständige 

Fragetyp Kommentar-/Artikelfeld genutzt werden. Die Größe dieses Felds kann zwischen 10 und 

100 Zeichen in der Breite und 2 bis 20 Zeilen in der Höhe betragen und eignet sich daher für frei formulierte 

Sätze oder Texte (siehe Abbildung 4.10). 

278




Abbildung 4.10: Offene Fragen 

Für Eingaben mit vorgegebenem Inhalt wie E-Mail-Adresse, Geburtstag oder Zahlenfolgen mit 

bestimmter Länge können die Fragetypen Einzelnes Textfeld, Mehrere Textfelder oder für bestimmte 

Summen Numerisches Textfeld mit entsprechender Validierung verwendet werden (siehe Abbildung 

4.11). 


Abbildung 4.11: Einstellungen zu offenen Fragen 

Schließlich ist es auch möglich, freie Textfelder als Antwortmöglichkeit in verschiedenen Fragetypen 

auszuwählen (siehe Abbildung 4.12). 



Abbildung 4.12: Freitext in verschiedenen Fragetypen 

279




4.2.2.1 Multiple Choice: Check (mehrere Antworten) 

Es können sowohl Fragen mit einer einzelnen Zeile mit dem Fragetyp Multiple Choice (mehrere Antworten 

pro Zeile) als auch eine Matrix mit mehreren Zeilen mit Checkboxen per Fragetyp Auswahlmatrix 

(mehrere Antworten pro Zeile) eingebunden werden (siehe Abbildung 4.13). 





Es ist kein Spreadsheet mit freien Eingabefeldern vorgesehen, jedoch können im Stil von Dropdown- 

Menüs Antwortmöglichkeiten vorgegeben werden. Theoretisch wäre es mit einigem Aufwand möglich, 

auch ein Spreadsheet aus einzelnen numerischen Textfeldern zu konstruieren um freie Eingaben 

zu ermöglichen (siehe Abbildung 4.14). 





Bei der Erstellung einer neuen Umfrage kann eine bestehende Umfrage kopiert oder ein vorgegebenes 

Template aus verschiedenen Fachbereichen ausgewählt werden. Diese können jedoch nicht ersetzt 

werden, um ein zusätzliches Vorlageverzeichnis zu erstellen (siehe Anhang A, Frage 1) 

280





Abbildung 4.15: Templates 


Abgesehen von Gewichtungen bei Skalafragen ist kein Rating möglich. 

Bewertung: 0 (nicht möglich) 



Durch die Nutzung des Fragetyps Beschreibender Text kann ein freier Text als Willkommenstext eingefügt 

werden. Ebenso ist die Darstellung eines Bildes wie etwa das Firmenlogo umsetzbar. 




281




SurveyMonkey unterstützt Verzweigung als Teil der Fragen- und Seitenlogik. Hierbei wird der Nutzer 

abhängig von seiner Antwort gezielt auf unterschiedliche Seiten oder zu bestimmten Fragen weitergeleitet. 

Sie unterliegt gewissen Einschränkungen, die sich jedoch aus der Natur der Frage ergeben und 

die Funktionalität nicht beeinträchtigen. 



Abbildung 4.17: Branching/ Skip Logic 


Ein explizites Ausblenden von Fragen ist nicht vorgesehen, kann jedoch durch passendes Weiterleiten 

abhängig von Antworten nachgestellt werden. Die Logik wird somit nicht aus Sicht der zu versteckenden 

Frage erstellt, sondern von der Frage, die die Bedingungen zum Verstecken enthält. Daher kann 

etwa in späteren Teilen einer Umfrage nicht auf früheren Teilen Bezug genommen werden, ohne stark 

angepasste, teils redundante Zweige zu erstellen oder die Umfrage von vornherein auf diese Einschränkungen 

auszulegen. Da somit mit zunehmender Komplexität der Aufwand zur Umsetzung 

steigt, die Übersicht leiden kann und es zu schnell Konflikten mit anderen Verzweigungen kommt, ist 

dies nur als Workaround anzusehen. 



Nach Abschluss der Umfrage kann der Nutzer auf eine Seite in SurveyMonkey verwiesen werden, 

welche mit den bekannten Optionen gestaltet werden kann. Alternativ kann eine beliebige URL, wie 

die des Unternehmens, angegeben werden, etwa um einen generierten Gutschein anzuzeigen. 


282




Die Umfrage ist auf Seitenbasis strukturiert. Der konkrete Inhalt kann je Seite ausgewählt werden, 

wodurch ein Pagebreak entsteht. Die entstehenden Seitenzahlen können ebenso wie ein Fortschrittsbalken 

wahlweise ein- oder ausgeblendet werden. 



Bilder können zwar eingebunden werden, sind jedoch nicht als markierbare Antwortmöglichkeit vorgesehen. 

Mit einigem Aufwand lässt sich eine Notlösung konstruieren, jedoch müssen die Bilder passend 

skaliert vorbereitet sein. Das Layout wird so jedoch sehr fehleranfällig (siehe Abbildung 4.18). 


Abbildung 4.18: Bildanhang in Antworten 

Bessere Kontrolle erlaubt wiederum die Verwendung von HTML, entsprechende Kenntnisse vorausgesetzt. 



Eine spezielle Kontakt-Funktion ist nicht verfügbar. SurveyMonkey enthält zudem keine Form von 

Alerting, durch welches eine Kontaktanforderung umgesetzt werden könnte und auch die Benachrichtigung 

bei ausgefüllten Umfragen wird explizit nicht unterstützt. Es sollte zwar möglich sein, im Rahmen 

der anschließenden Auswertung angegebene E-Mail-Adressen mit Kontaktwunsch zu manuell zu 

kontaktieren, jedoch entsteht so zwangsläufig ein gewisser zeitlicher Abstand. 

(Vgl.http://help.surveymonkey.com/app/answers/detail/a_id/167/kw/alert?q=alert) 


283





Es können Ordner angelegt und Umfragen einsortiert werden. Unterordner sind hingegen nicht erstellbar. 

Bewertung: 2 (teilweise unterstützt) 



Es können beliebige Variablen mit der URL der Umfrage versendet werden um sie zu personalisieren 

oder um beliebige zusätzliche Informationen zu übermitteln. 

(vgl. http://help.surveymonkey.com/app/answers/detail/a_id/6749/kw) 


4.4.2.2 Mehr als vier nutzbare Variablen 

Der Anzahl der nutzbaren Variablen ist nur durch Einschränkungen der Maximallänge von URLs eine 

Grenze gesetzt. Diese kann 2048 Zeichen nicht überschreiben, welche jedoch vollständig für Variablen 

genutzt werden können. 



Es stehen die Formate PDF, HTML, XML, CSV, XLSX und ein Export in IBM SPSS zur Verfügung. 



Es gibt weder einen Scheduler für automatisierten Export der Daten noch einen Web-Service für direkten 

Datenabruf. Der Export muss jedes Mal von Hand erfolgen (siehe Anhang A, Frage 4). 



Es stehen einige Basisberichte und einfache Diagramme zur Auswahl, für weitere Auswertungen wird 

auf Excel verwiesen (siehe Anhang A, Frage 2). Diese sind für die Teilgruppe nicht relevant, da in 

jedem Fall IBM Cognos für das Reporting verwendet wird. 

284






Die Erfassung der Ergebnisse läuft über einen Collector, welcher geöffnet und geschlossen werden 

kann. Bereits laufende Umfragen können zudem bei Bedarf geändert werden, siehe: 

http://hilfe.surveymonkey.com/app/answers/detail/a_id/737/kw/%C3%A4nderungen. 



Es kann ein benutzerdefinierter Text eingeblendet werden, falls ein Link zu einer inaktiven Umfrage 

aufgerufen wird, siehe: 

http://hilfe.surveymonkey.com/app/answers/detail/a_id/1252/kw/geschlossen 


4.5.3 Generierung eines Links für Newsletter-/ Web-Umfrage 

Es werden kompakte Links generiert, welche als Premium-Kunde auch angepasst werden können. Sie 

enthalten jedoch in jedem Fall die Domains www.surveymonkey.com oder www.research.net, welche 

auch in der Adressleiste beim Ausfüllen des Fragebogens angezeigt wird. 


4.5.4 Net Promoter Score umsetzbar 

Ein Net Promoter Score ist nicht Teil der Basisfunktionen. Es können keine Berechnungen durchgeführt 

werden, daher ist er auch nicht konstruierbar. (siehe Anhang A, Frage 2) 


4.6 Sonstiges 


Es besteht eine Anbindung zu einigen Partnern, welche die Funktionalität erweitern können. Dabei 

steht die Integration in E-Mail-Kampagnen via MailChip, Mad Mimi, Active Campaign und Clever 

Reach im Vordergrund. Per GroSocial kann zudem der Zugang zu Facebook erleichtert werden. 

Weitere Kontakte lassen sich finden, etwa umfassendere Analysefunktionen via MarketSight. 

285



(vgl. http://www.marketsight.com/SurveyMonkey-data-analysis.htm) 



SurveyMonkey ist nicht auf die Nutzung durch mobile Geräte ausgelegt oder optimiert, jedoch sollte 

der Zugang durch den Browser eines mobilen Geräts möglich sein. 


4.6.3 Support 

Der Kundendienst in Form eines Ticket-Systems ist Wochentags, 9-17 Uhr in Deutsch erreichbar. 

Englischsprachiger Support ist ganzjährlich, 24 Stunden am Tag möglich. Ein Live-Chat gibt es nicht, 

für Premium-Kunden steht jedoch ein Telefonkontakt zur Verfügung. 



Es ist keine unmittelbare Möglichkeit dynamische Inhalte einzubinden vorhanden. Dies muss über 

einen externen Dienst realisiert werden. 



Die Webseite enthält ein FAQ mit nach Themen sortierten, häufig gestellten Fragen und mit Suchfunktion. 

Bewertung: 2 (teilweise unterstützt 

286



5. SurveyGizmo 

SurveyGizmo ist ein Tool, das bislang nicht von CEWE genutzt wird. Die Teilgruppe hat aufgrund 

einiger Anforderungen nach einer weiteren Alternative zu den bisher vorgestellten Systemen gesucht. 

Dabei hat sich SurveyGizmo als durchaus denkbare Möglichkeit herauskristallisiert und wurde demnach 

in den Kriterienkatalog und somit in den Vergleich aufgenommen. 

5.1 Design 


SurveyGizmo erlaubt das unmittelbare Bearbeiten des unterliegenden Codes, sowohl HTML als auch 

CSS wird unterstützt. Somit kann mit gewissem Aufwand praktisch jedes Element bis ins Detail bearbeitet, 

entfernt oder hinzugefügt werden. Die Änderungen können in Vorlagen gespeichert und in der 

Zukunft weiter verwendet werden (siehe Abbildung 5.1). 


Quelle: Screenshot aus SurveyGizmo 

Abbildung 5.1: Code für Buttons 


Auch die Farben jeglicher Elemente können angepasst werden. Die Anpassung wird anhand vordefinierter 

Elemente (Style Options) über eine GUI realisiert. Alternativ liegt wiederum der Code vollständig 

offen und kann bis ins Detail angepasst werden (siehe Abbildung 5.2). 

287





Abbildung 5.2: GUI und Quellcode zur Farbanpassung 


Die Offenlegung des CSS- und HTML-Codes ermöglicht umfangreiche Anpassungen des Layouts an 

individuelle Anforderungen, erfordert jedoch einen gewissen Arbeitsaufwand. Dieser sollte nur einmalig 

beim Anlegen der Templates und bei eventuellen Änderungen anfallen (siehe Abbildung 5.3 & 



Abbildung 5.3: Beispielhaftes Design 1 

288




Abbildung 5.4: Beispielhaftes Design 2 



Die Umfrage ist modular aufgebaut und in Seiten und Fragen unterteilt. Seiten können Fragen aus 

einem Schnellmenü mit denen am häufigsten verwendeten oder aus einem detaillierten Menü mit Vorschau 

hinzugefügt werden. Dieses Menü enthält auch eine Verknüpfung zu einer Fragenbibliothek, 

welche vorgegebene Beispielfragen enthält und gezielt mit eigenen Fragen gefüllt werden kann. Anschließend 

ist es möglich, die einzelnen Elemente, Logiken und weitere Attribute einzustellen (siehe 



Abbildung 5.5: Auswahl möglicher Fragen 

289





Einfache Entscheidungsfragen werden als Basic > Single Select bzw. Multiple Choice > Radio Button 

eingebunden (siehe Abbildung 5.6). 





Skalafragen können ohne Einschränkung möglicher Antworten eingebunden werden. Dabei kann eine 

benutzerdefinierte Bewertung im Hintergrund angegeben werden, um die Analyse zu ermöglichen 




Alternativ können zu vergebende Sterne als Darstellungsform verwendet werden (siehe Abbildung 

5.8). 

290





Abbildung 5.8: Skalafrage: Vergabe von Sternen 

5.2.1.3 Multiple-Choice: Choose 

Einfache Multiple-Choice-Fragen können mit unbegrenzter Anzahl möglicher Einträge als Likert- 

Scale umgesetzt werden (siehe Abbildung 5.9). 



Abbildung 5.9: Multiple-Choice: Choose 


Jede Darstellungsform kann einzeln oder in Tabellenform abgebildet werden (siehe Abbildung 5.10). 




291




Offene Fragen können als freie Textfelder platziert werden, deren Dimensionen und maximale Anzahl 

an Zeichen und Wörtern festgelegt werden können (siehe Abbildung 5.11). 



Abbildung 5.11: Offene Frage 


5.2.2.1 Multiple-Choice: Check (mehrere Antworten) 

Multiple-Choice-Fragen können ebenfalls einzeln oder als Tabelle gruppiert eingebunden werden (siehe 



Abbildung 5.12: Multiple-Choice: Check 



Spreadsheets können sowohl mit freier Texteingabe als auch über Dropdown-Menüs mit vorgegebenen 

Werten oder Intervallen umgesetzt werden (siehe Abbildung 5.13). 

292







Es können sowohl bestehende Umfragen als auch definierte Vorlagen, Importe aus Word als auch eine 

spezielle Brainstorming-Hilfe bei der Erstellung neuer Umfragen genutzt werden (siehe Abbildung 

5.14). 





Es ist kein spezielles Rating von Fragen vorgesehen. 




Mit dem Elementtyp Instructions/ Text kann eine Seite als Willkommensseite genutzt werden (siehe 


293







Durch einen umfangreichen Logik-Editor mit logischer Verknüpfung von Konditionen können komplexe 

Verzweigungen gestaltet werden (siehe Abbildung 5.16). 



Abbildung 5.16: Logik-Editor bei Verzweigungen 


Ähnlich der Verzweigungslogik können auch Bedingungen zum Aus- und Einblenden von Fragen 

oder Seiten eingesetzt werden (siehe Abbildung 5.17). 

294





Abbildung 5.17: Logik-Editor zum Ein-/ Ausblenden von Fragen 


Zum Abschluss der Umfrage oder an jedem beliebigen Punkt können an Bedingungen geknüpfte Aktionen 

durchgeführt werden. Darunter ist die automatische Weiterleitung auf eine andere URL nach 

einer gewünschten Zeit, das Versenden von E-Mails, Anzeigen der Ergebnisse oder Aktivierung individueller 

Skripte. 



Die Umfrage basiert auf einzelnen Seiten, entsprechend können weitere Seiten an jeder Stelle eingefügt 

und per Drag & Drop verschoben werden (siehe Abbildung 5.18 & Abbildung 5.19). 


Abbildung 5.18: Pagebreak 

295





Abbildung 5.19: Verschieben von Fragen und Seiten 


Bilder können sowohl einzeln als auch über mehrfache Auswahl anhand eines speziellen Fragentyps 

als Antwortmöglichkeiten genutzt werden (siehe Abbildung 5.20). 

Abbildung 5.20: Mögliche Fragen mit Bildern (Screenshot aus SurveyGizmo) 



Über die Aktion Send Email kann an jeder beliebigen Stelle eine E-Mail an eine Kontaktadresse, wie 

den Kundendienst, inkl. vorhandener Antworten gesendet werden (siehe Abbildung 5.21). 


Abbildung 5.21: Aktion Send Email mit Antwort der vorigen Frage verknüpft 


296





Auf der Startseite kann der Nutzer ein Dashboard aufrufen, welches die zugänglichen Umfragen anzeigt. 

Diese können wahlweise nach Status, Typ oder Ordnern gefiltert werden. Durch ein Rollen- und 

Berechtigungsystem bekommt der Nutzer nur Zugriff auf die für ihn vorgesehenen Elemente (siehe 




Abbildung 5.22: Umfrageverwaltung 


5.4.2.1 Vier Frei Nutzbare Variablen 

Es können freie Variablen über die URL der Umfrage versendet werden, welche der ausgefüllten Umfrage 

zugeordnet werden und beim Export als Teil des Datensatzes erhalten bleiben. 

(Anleitung siehe: https://support.surveygizmo.com/entries/21433006-pushing-values-into-the-surveythrough-the-query-string-part-1) 


5.4.2.2 Mehr als Vier Frei Nutzbare Variablen 

Der Anzahl der nutzbaren Variablen ist theoretisch keine Grenze gesetzt. 


5.4.3 DatenExport 

Der Datenexport umfasst die Excel-Formate XLS und CSV, den Download eventuell von Nutzern bei 

entsprechenden Fragen hochgeladener Dateien sowie die nötigen Dateien zur Nutzung in IBM SPSS. 

Die zu exportierenden Daten können zudem angepasst werden, bestimmte Fragen ausgeschlossen oder 

297



wahlweise der Fragentext oder die Fragennummer in der ersten Zeile ausgewählt werden. Wurden 

Fragen mit Piping verwendet, kann zudem der Export dieser Daten genutzt werden, welcher sich zurzeit 

im Beta-Status befindet (siehe Abbildung 5.23). 



Abbildung 5.23: Exportmöglichkeiten 

5.4.4 Automatischer DatenExport 

SurveyGizmo verfügt zudem über eine umfassend dokumentierte REST API zwecks externem Zugriff, 

wodurch Daten in den Formaten XML, JSON, PSON abgerufen werden können. 

(vgl. http://developer.surveygizmo.com/). 



Berichte können strukturell gespeichert und auf Knopfdruck mit aktualisierten Daten versehen werden. 

Es ist möglich sie stark zu modifizieren und bei Bedarf in Word, Excel oder als PDF zu exportieren. 

Ebenfalls kann eine URL generiert werden, um auf den Bericht zuzugreifen und ein automatisierter E- 

Mail-Versand ist nach Wunsch zu festgelegten Zeiten (z. B. jeden Montag um 8 Uhr, immer am Ersten 

des Monats, täglich um 14 Uhr, etc.) möglich. Zu den Berichtsformen gehören unter anderem auch 

Fall-Off-Reports, welche darstellen, auf welcher Seite die Umfrage abgebrochen wurde sowie Kreuztabellen 


298




Abbildung 5.24: Beispiel für zusammenfassenden Bericht 




Der Status der Umfrage kann jederzeit geändert werden und bietet neben dem Öffnen und Schließen 

der Umfrage auch einen Test-Modus, in welchem gegebene Antworten als Test markiert werden. 

Dieser Modus kann genutzt werden, um die Funktionalität und das Datenformat der Umfrage vor 

Veröffentlichung zu prüfen. Zur Generierung von Testdaten ist ebenfalls eine Funktion enthalten, 

welche bis zu 1000 Datensätze pro Durchlauf erstellt (siehe Abbildung 5.25). 


Abbildung 5.25: Wahl des Umfragestatus 


299




Der Text kann individuell angepasst werden (siehe Abbildung 5.26). 



Abbildung 5.26: Text bei inaktiver Umfrage 

5.5.3 Generierung eines links für Newsletter- / Web-Umfragen 

Es können sowohl URLs über www.surveygizmo.com oder www.surveygizmo.co.uk, verkürzte URLs 

als auch benutzerdefinierte Domains wie umfrage.beispiel.de verwendet werden. Die benutzerdefinierten 

Variablen können in einer weiteren Option an dieser Stelle eingebunden werden (siehe Abbildung 

5.27). 



Abbildung 5.27: Generierung von URL 

5.5.4 Net Promoter Score Umsetzbar 

Die NPS gehört nicht zum Basisumfang, kann jedoch über den Market Place für $3,99 zusätzlich gebucht 


300 


Abbildung 5.28: Fragetyp NPS im Market Place




5.6 Sonstiges 

5.6.1 Erweiterbarkeit durch apps 

Zahlreiche Produkte von Drittanbietern können mit SurveyGizmo genutzt werden. Dazu zählen Marketing-Tools, 

wie ExactTarget und MailChimp, Integration von Umfragen in Twitter und Facebook 

sowie Salesforce, FreshBooks, Eventbrite, Ready Talk und Google Docs. 

Zudem kann SurveyGizmo durch seine API umfassend erweitert und angepasst werden. So enthält der 

Market Place sowohl besondere Fragetypen als auch Funktionen. 



Durch die flexible Anpassung des Layouts können Umfragen einfach für mobile Geräte optimiert werden. 

Die Vorschau der Umfrage kann neben Bildschirmen mit voller Größe auch Tablets, Smartphones 

und kleine Mobiltelefone simulieren (siehe Abbildung 5.29). 



Abbildung 5.29: Vorschau einer Umfrage auf Smartphones 

5.6.3 Support 

SurveyGizmo ist vollständig in Englisch gehalten, entsprechend ist auch der Support nur in Englisch 

verfügbar. Anfragen können über ein Ticket-System oder per Telefon über eine (unklar ob auch aus 

Deutschland) kostenlose Rufnummer 12 Stunden Wochentags bearbeitet werden. Die Ostküstenzeit 

entspricht 14 bis 2 Uhr deutscher Zeit. Für Notfälle steht ein Techniker über eine separate Rufnummer 

auch außerhalb der Geschäftszeiten zur Verfügung. 

301





Zwar können Umfragen durch Variablen personalisiert werden und es können diverse Medien eingebunden 

werden, doch besondere Funktionen wie das Abrufen von Gutscheincodes ist nicht vorgesehen. 

Jedoch sollten die API sowie Javascript mit gewissem Aufwand die Programmierung und Einbindung 

zusätzlicher Funktionen zumindest ermöglichen. 



Der ebenfalls ausschließlich englische Help Desk enthält eine große Anzahl thematisch sortierter Hilfeseiten 

und voll bebilderte Tutorials. Zudem werden kostenpflichtige Trainingskurse angeboten, welche 

neben dem Umgang mit SurveyGizmo auch Tricks aus der Marketing-Branche enthalten sollen. 

(vgl. https://appv3.sgizmo.com/training) 


302



6. Ergebnis 

Es wurde entschieden, dass die Teilgruppe das Projekt mit QuestionPro als Frontend-Tool für die Erstellung 

von Umfragen arbeiten wird. Die Vorteile von SurveyGizmo waren nicht ausschlaggebend 

genug, um die wenigen Defizite von QuestionPro auszugleichen. 

Abbildung 6.1 zeigt eine Gegenüberstellung der zur Auswahl stehenden Tools mit den markantesten 

Kriterien für oder gegen das entsprechende Umfragetool. QuestionPro, welches ohnehin bereits im 

Einsatz ist, hat den wesentlichen Vorteil, dass es den Funktionsumfang bis auf wenige Ausnahmen 

komplett darstellt. Die wenigen Ausnahmen die bestehen, werden mit der neuen Team-Edition von 

QuestionPro fast gänzlich beseitigt. 

Einziges Problem, welches noch besteht und für die weitere Arbeit geklärt werden muss, ist die Frage 

der Schnittstelle zum Datenexport. 

Abbildung 6.1: Gegenüberstellung 

303



Anhang 

A. Supportanfrage SurveyMonkey 10.Oktober 2012 

Hallo Herr Tomann, 

danke für Ihre Anfrage. Zu Ihren Fragen: 

1. Ist es möglich die „Umfragevorlagen für Experten“ zu ersetzen um einen eigenen Katalog von Vorlagen zu erstellen? 

Ja und nein. Ihre Umfragen können Ihnen als Vorlagen dienen. Sie können ganz leicht eine Kopie jedes Umfragebogens 

erstellen und so eine neue Umfrage ohne Antworten generieren. Kopieren Sie eine Umfrage, um eine neue Version zu erstellen. 

Antwort-Link: http://hilfe.surveymonkey.com/app/answers/detail/a_id/722 

2. Welche Arten von Reporting sind möglich? (Graphen/Diagramme, benutzerdefinierte KPIs, besonders mit Hinsicht 

auf die Möglichkeit einer Net Promoter Score) 

Wir bieten sechs Exportoptionen zum Senden Ihrer Daten im Rohformat oder im zusammengefassten Format an. Kommentare 

mit unbestimmtem Ende sind in den meisten Formaten ebenfalls enthalten. 

http://help.surveymonkey.com/app/answers/detail/a_id/1687 

Erstellen Sie im Bereich „Analysieren“ benutzerdefinierte Berichte, um die Datenverwaltung und -analyse zu vereinfachen. 


Mithilfe des Diagrammfeatures können Sie benutzerdefinierte Diagramme für Ihre Daten erstellen. 


Exportieren Sie die Daten nach Excel und erstellen Sie benutzerdefinierte Diagramme mit zusätzlichen Erweiterungen. 


3. Können in der Umfrageverwaltung Unterordner angelegt werden? 

Ja: http://hilfe.surveymonkey.com/app/answers/detail/a_id/1072/kw/ordner 

4. Können Daten automatisiert/per Scheduler exportiert werden? Besser: besteht ein WebService zur direkten Extraktion 

in eine lokale fi? 

Nein, leider nicht. Dies muss jedes Mal "manuell" geschehen. Für solche Fragen lege ich Ihnen auch unser umfangreiches 

Hilfecenter ans Herz. Hier finden Sie häufig gestellte Fragen, eine praktische Suchfunktion und die Antwort auf die meisten 

Fragen direkt: 

http://hilfe.surveymonkey.com/app/home/ 

Weiterhin viel Erfolg bei Ihren Umfragen mit SurveyMonkey! 

304


CEWE „gestochen scharfe Fragen stellen“ – Dokumentation 



Gruppe: CEWE 

Dokumentation 

305



306



Inhaltsverzeichnis CEWE Dokumentation 



1. Einleitung ......................................................................................................................... 309 

2. QuestionPro ..................................................................................................................... 310 

3. ETL-Anwendung ............................................................................................................. 311 

3.1 Automatische Prozesse ............................................................................................... 314 

3.2 Manueller Prozess ...................................................................................................... 314 

3.3 Parameter anpassen .................................................................................................... 314 

3.4 Risiken ........................................................................................................................ 315 

4. Datenbankmodell ............................................................................................................. 315 

5. Fragenpool ....................................................................................................................... 318 

5.1 Benutzerspezifische Beschreibung ............................................................................. 318 

5.1.1 Umfrage ID ...................................................................................................... 318 

5.1.2 Fragenkategorisierung ..................................................................................... 321 

5.1.3 Kategorien erstellen ......................................................................................... 322 

5.1.4 Fragenübersicht ............................................................................................... 323 

5.1.5 Kategorienübersicht ......................................................................................... 324 

5.2 Technische Beschreibung ........................................................................................... 324 

5.2.1 Umfrage ID ...................................................................................................... 325 

5.2.2 Fragenkategorisierung ..................................................................................... 326 

5.2.3 Kategorien erstellen ......................................................................................... 328 

5.2.4 Fragenübersicht ............................................................................................... 331 

5.2.5 Kategorienübersicht ......................................................................................... 332 

6. Fazit ................................................................................................................................. 332 

Anhang ................................................................................................................................... 335 

A. Protokolle ......................................................................................................................... 335 

307




Abbildung 1.1: Projektphasenübersicht ................................................................................. 310 

Abbildung 1.2: Gesamtüberblick ........................................................................................... 310 

Abbildung 3.1: Sequenzdiagramm Ablauf beim automatischen Prozess .............................. 312 

Abbildung 3.2: Sequenzdiagramm vereinfachter Ablauf beim Schreiben von Ergebnissen . 313 

Abbildung 3.3: Auszug aus der datum.txt-Datei .................................................................... 314 

Abbildung 3.4: Auszug aus der connection.txt-Datei ............................................................ 315 

Abbildung 4.1: Datenbankmodell .......................................................................................... 318 

Abbildung 5.1: QuestionPro MySurvey-Site ......................................................................... 319 

Abbildung 5.2: QuestionPro Umfrage ID ermitteln ............................................................... 319 

Abbildung 5.3: Umfrage ID ................................................................................................... 320 

Abbildung 5.4: Fragenkategorisierung ................................................................................... 321 

Abbildung 5.5: Neue Kategorien anlegen .............................................................................. 322 

Abbildung 5.6: Fragenübersicht ............................................................................................. 323 

Abbildung 5.7: Kategorienübersicht ...................................................................................... 324 

Abbildung 5.8: Umfrage ID ................................................................................................... 325 

Abbildung 5.9: Fragenkategorisierung ................................................................................... 326 

Abbildung 5.10: Kategorien erstellen .................................................................................... 328 

Abbildung 5.11: Fragenübersicht ........................................................................................... 331 

Abbildung 5.12: Kategorienübersicht .................................................................................... 332 

Abbildung 6.1: Pop-Up .......................................................................................................... 334 


AP Arbeitspaket 

API Application Programming Interface 

BI Business Intelligence 

DB Datenbank 

ETL Extract, Transform, Load 

OWB Oracle Warehouse Builder 

308



1. Einleitung 

Im Rahmen der Projektgruppe Business Intelligence Applications and Evaluation der Carl von Ossietzky 

Universität Oldenburg ist im Sommer 2012 in Zusammenarbeit mit der CEWE COLOR AG & 

Co. OHG (CEWE) das Projekt „gestochen scharfe Fragen stellen“ entstanden. 

Nach einer ersten Interviewphase mit Dr. Joachim Marz von der CEWE haben sich die Studierenden 

Björn Kreye, Benjamin Weinert, Fatih Inel, Henning Tomann und Wiebke Meyer für die Bearbeitung 

des Projektes „gestochen scharfe Fragen stellen“ entschieden. Nach einer weiteren Interviewphase 

mit den Vertretern der involvierten Fachbereiche von CEWE, in welcher die spezifischen Anforderungen 

für das Projekt „gestochen scharfe Fragen stellen“ ermittelt wurden, hat die Arbeit im August 

2012 begonnen. Weitere Interviews zur Klärung von Vorgehensweisen wurden im Rahmen des Projektes 

geführt. Die Protokolle zu den Besprechungen sind im Anhang (siehe Anhang A Protokolle) zu 

finden. 

Ziel des Projektes gestochen scharfe Fragen stellen ist eine Vereinheitlichung der computergestützten 

Prozesse und Systeme zur gezielten Umfrageerstellung. Der derzeitige Ablauf zur Erstellung einer 

Umfrage enthält mehrere systemübergreifende, manuelle Arbeitsschritte. Durch Einbeziehung vorhandener 

Analyseergebnisse in die Umfrageerstellung soll eine Vereinfachung der Arbeitsabläufe durch 

unmittelbare Verfügbarkeit relevanter Daten ohne Medienbrüche ermöglicht werden. Das Projekt 

reicht von der Umfrageerstellung über die Fragenkategorisierung, die Ergebnisdatenlagerung bis hin 

zu der Auswertung der Ergebnisse. 

Nach einer umfangreichen Analysephase, in welcher eine Machbarkeitsanalyse verschiedener Umfragetools 

durchgeführt wurde, begann die Projektgruppe CEWE Ende Oktober mit der Umsetzung der 

ermittelten Anforderungen. Anfang Februar 2013 wurde den Mitwirkenden von CEWE der aktuelle 

Stand des Projektes demonstriert. Bis zu diesem Zeitpunkt wurde der Datentransfer von dem Umfragetool 

zu der CEWE eigenen Oracle 11g Datenbank (DB) durch eine Java-Applikation realisiert, sowie 

erste Reports in IBM Cognos erstellt. Analysen in IBM SPSS wurden zu diesem Zeitpunkt noch nicht 

gestartet, da bei der ersten Absprache zwischen der Projektgruppe und dem Fachbereich ein Problem 

aufgetreten ist. Die Fragen verschiedener Umfragen konnten nicht umfrageübergreifend analysiert 

werden, wodurch ein Mehrwert durch Analyse der Daten mittels IBM SPSS für CEWE nicht gegeben 

war. Es wurde daher bei der Präsentation des aktuellen Standes mit den Entscheidungsträgern von 

CEWE entschieden, den bereits während der Anforderungen um im Fachkonzept erläuterten Fragenpool 

zur Kategorisierung von Fragen zu realisieren, damit für CEWE eine Umfragen übergreifende 

Analyse möglich ist. Aufgabe der Projektgruppe war es nun, eine Basis für weitere Reports und Analysen 

durch den Fachbereich zu schaffen und nicht selbstständig Reports und Analysen zu erstellen. 

Der Fragenpool zur Kategorisierung von Fragen verschiedener Umfragen durch den Fachbereich wur- 

309



de bis Mitte März 2013 erstellt. Am 19. März 2013 wurde die Arbeit der Projektgruppe den auf CEWE 

Seite verantwortlichen Personen übergeben. 

Abbildung 1.1: Projektphasenübersicht 

Das folgende Dokument geht detailliert auf den im Rahmen des Projektes „gestochen scharfe Fragen 

stellen“ installierten Prozess sowie die für dessen Ablauf relevanten Anwendungen ein. Der realisierte 

Prozess zur Kategorisierung von Fragen und Lagerung von Fragen und Antworten zu verschiedenen 

Umfragen verwendet: 

- QuestionPro zur Erstellung von Umfragen. 

- Eine auf Java basierende ETL-Anwendung zum Abrufen der Daten aus der QuestionPro Datenbank 

und Ablage in der betriebsinternen Datenbank. 

- Oracle Database 11g zur Lagerung der abgefragten Daten aus QuestionPro und zur Speicherung 

der durch den Benutzer angegebenen Kategorien. 

- Eine Benutzeranwendung zur Kategorisierung von Fragen in einem Pool mit zusätzlicher 

Funktion zur Erfassung der in QuestionPro vorhandenen Umfragen. 

Abbildung 1.2: Gesamtüberblick 

2. QuestionPro 

Im Rahmen der Projektarbeit wurde durch eine vorangegangene Analyse, in Abstimmung mit dem 

Verantwortlichen des Fachbereichs, QuestionPro für die geplante Umsetzung ausgewählt (siehe Kriterienkatalog 

bzw. Machbarkeitsanalyse im Datenverarbeitungskonzept). QuestionPro ist ein Produkt 

des gleichnamigen, amerikanischen Unternehmens QuestionPro. Es dient der Umfrageerstellung und 

wurde bereits vor Start des Projektes von CEWE mit einer Einzellizenz eingesetzt. Für die Ausweitung 

der Nutzung war das Upgrade auf die Team Edition von QuestionPro erforderlich, welche die Voraussetzung 

für die Nutzung der Schnittstelle zum Datenabruf ist. 

310



3. ETL-Anwendung 

Die auf Java basierende ETL-Anwendung wird als solche bezeichnet, weil sie mit Hilfe des Question- 

Pro Application Programming Interface (API) aus QuestionPro, einige Transformationen vornimmt 

und die Umfragedaten in die modellierte Oracle Datenbank schreibt. 

Zum Starten des Schreibvorganges der QuestionPro-Daten in die Oracle Datenbank wird die Umfrage 

ID, die von QuestionPro vergeben wird, über die Benutzeranwendung in die Tabelle SR_Umfrage der 

Datenbank geschrieben. Das entwickelte Java-Programm ruft in einem festgelegten zeitlichen Intervall 

automatisch die Daten aller erfassten Umfragen mit der Methode „schreibe Ereignisse“ ab. Ist der 

Ladeprozess für eine Umfrage abgeschlossen, wird in der Tabelle SR_Umfrage für die ETL_Load_ID 

eine 1 gesetzt und anschließend in die Tabelle SR_ETL_LOG übertragen. Sind alle ETL_Load_IDs 

der gesamten Tabelle SR_ETL_LOG auf 1 gesetzt, wird das Programm beendet. Dies impliziert, dass 

der ETL-Vorgang vollständig abgeschlossen wurde. 

Die Anwendung schreibt bei jedem Durchlauf stets die Ergebnisse des Vortags in die Datenbank. 

(Beispiel: Heute ist der 13.03., dann holt das Programm die Ergebnisse vom 12.03.) und schreibt diese 

in die Datenbank. 

Die in dem Java-Programm verwendeten Methoden sind wie folgt aufgebaut: 

- selektiereTabelle(String table) 

Diese Methode führt einen SELECT-Befehl auf die Datenbank aus, dazu wird der 

Tabellenname als String übergeben. 

- aktualisiereTabelle(String table, String column, String value, String column2, String value2) 

Mit Hilfe dieser Methode ist es möglich, Werte einer Tabelle zu aktualisieren. Dafür müssen 

der Tabellenname, die Spalte und der anzupassende Wert übergeben werden. Die Variablen 

column2 und value2 sind für den WHERE-Teil notwendig. 

- pruefeWert(String table, String column, String value) 

Eine Boolean-Funktion, die überprüft, ob der jeweilige Wert in der Tabelle vorhanden ist oder 

nicht. 

Die der Methoden schreibeInUmfrage, schreibeInFrage, schreibeInAntwortStammdaten, schreibeInAntwort, 

schreibeInCvar und schreibeInUmfrageFrage übergebenen Parameter werden in die 

dafür vorgesehenen Tabellen der Oracle-Datenbank geschrieben, sie setzen den INSERT INTO SQL- 

Befehl um. 

Der Ablauf des Programms ist in den folgenden Diagrammen dargestellt. 

311



Abbildung 3.1: Sequenzdiagramm Ablauf beim automatischen Prozess 

312



Abbildung 3.2: Sequenzdiagramm vereinfachter Ablauf beim Schreiben von Ergebnissen 

313



3.1 Automatische Prozesse 

Die ETL-Anwendung startet automatisch und führt den gesamten Extraktions-, Lade- und Transformationsprozess 

aus den Datenbanken von QuestionPro bis in die Datenbanken bei CEWE durch. Der 

Prozess startet jeden Morgen vor der Arbeitszeit. 

Nach dem herkömmlichen Laden der Daten vom Vortag führt die ETL-Anwendung selbstständig einen 

Korrekturprozess aus. Fehlerhafte Ladevorgänge (ETL_LOAD_ID = 0 in SR_ETL_LOG) werden 

identifiziert und für den Zeitraum erneut ausgeführt. Somit wird ein hohes Maß an Sicherheit gewährleistet, 

da selbst bei temporärem Ausfall der QuestionPro API oder anderer Verbindungen der Korrekturprozess 

täglich nach dem automatischen Prozess durchgeführt wird und eine Bereinigung vornimmt. 

3.2 Manueller Prozess 

Sollte es aus unbekannten Gründen doch zu fehlenden Daten kommen, besteht die Möglichkeit einen 

manuellen Prozess mit modifizierbarem Zeitraum unabhängig vom automatischen Prozess und dem 

Korrekturprozess zu starten. 

Dazu liegt eine Datei datum.txt der Manuell_QP.jar bei. In dieser Text-Datei kann ein beliebiges 

Start- und Enddatum eingegeben werden. Einzige Restriktion ist die Reihenfolge des Datums (Erst das 

Startdatum, dann das Enddatum) und das Format (MM/DD/YYYY). Ist beides angepasst, kann die 

Datei Manuell_QP.jar gestartet werden, die für den eingegebenen Zeitraum einen erneuten Datenextrakt 

durchführt. 

Abbildung 3.3: Auszug aus der datum.txt-Datei 

3.3 Parameter anpassen 

Sollte die Notwendigkeit bestehen die Verbindungsparameter für die Datenbank anzupassen (möglicherweise 

bei einem Datenbankumzug), kann dies mit Hilfe der beiliegenden connection.txt-Datei vorgenommen 

werden. 

In die connection.txt-Datei werden die Parameter für die Verbindung wie unter anderem Server- 

Adresse, Port, Service-Name oder die Benutzerdaten eingegeben werden. Die Reihenfolge kann der 

Datei entnommen werden. 

314



Abbildung 3.4: Auszug aus der connection.txt-Datei 

3.4 Risiken 

Das bislang einzige identifizierte Risiko stellt eine fehlerhafte Umfrage ID innerhalb der 

SR_UMFRAGE-Tabelle dar. Sobald die Umfrage ID nicht korrekt eingegeben und bis zum automatischen 

Start der ETL-Anwendung nicht entfernt wurde, werden der automatische Datenextrakt und der 

Korrekturprozess nicht vollständig ausgeführt. 

Daher gilt es, dass fehlerhafte Umfrage IDs möglichst sofort und notwendigerweise vor dem Start der 

ETL-Anwendung erkannt und über die Benutzeranwendung zur Verwaltung des Fragenpools aus der 

Datenbank entfernt werden müssen (siehe Abschnitt 5.1.1). 

Ist dies nicht der Fall und die ETL-Anwendung startet mit einer fehlerhaften Umfrage ID, so wird der 

laufende Prozess abgebrochen, da bei Anfrage der Daten von QuestionPro ein Fehler entsteht. Die 

einzige mögliche Lösung ist das Löschen der fehlerhaften Umfrage ID aus der SR_UMFRAGE- 

Tabelle und der SR_ETL_LOG-Tabelle. Ersterer Löschvorgang ist notwendig, damit der automatische 

Prozess wieder reibungslos funktioniert. Der zweite Löschvorgang lässt auch den Korrekturprozess 

wieder vollständig ablaufen. 

4. Datenbankmodell 

Das Datenbankmodell wurde im CEWE-Schema (olrac.cewe.lan) angelegt. Die einzelnen Relationen 

beginnen immer mit dem Kürzel SR für Survey um die Zuordnung zu erleichtern. Das Modell beinhaltet 

insgesamt elf Relationen, von der zwei als Hilfs- oder Zwischenrelation (bzw. Hilfs- oder Zwischentabelle) 

verwendet werden. Die Relationen und wozu diese verwendet werden, wird im Folgenden 

beschrieben. 

- SR_ETL_Log 

Die ETL-Logs werden in der Relation SR_ETL_Log behandelt. Die Log-Tabelle dient dazu, 

Fehler beim Schreiben der QuestionPro-Daten in die Datenbank zu erkennen bzw. zu erkennen, 

wann der Ladeprozess abgeschlossen oder wo dieser evtl. unterbrochen wurde. War der 

Ladeprozess erfolgreich, wird die Load_ID auf 1 gesetzt, falls nicht bleibt die Load_ID auf 0 

stehen. Die Load_ID ist in allen Relationen, die Daten von QuestionPro beziehen mit Ausnahme 

der Kategorientabellen, enthalten und zeigt an, ob ein Datensatz erfolgreich (1) oder 

nicht erfolgreich (0) geladen wurde. Ein ETL-Log gehört zu genau einer Umfrage. Des Weite- 

315



ren kann dieser Tabelle entnommen werden, wie viele Ergebnisse von QuestionPro abgerufen 

wurden, zu welcher Zeit der Abruf stattfand und wie lange der Vorgang angedauert hat. 

- SR_Umfragetyp 

Die Relation speichert den Umfragetypen einer Umfrage, etwa ob es sich bei der Umfrage um 

eine NPS-Umfrage, eine Key-Account-Umfrage, eine Mitarbeiterumfrage oder eine Kundenzufriedenheitsumfrage 

handelt. Die Relation ist mit SR_Umfrage verbunden. Ein Umfragetyp 

kann zu einer oder mehreren Umfragen gehören. 

- SR_Umfrage 

SR_Umfrage beinhaltet alle Umfragen mit ihrer von QuestionPro vergebenen Umfrage_ID. 

Die Umfragen sind mit dem Ergebnissatz, der ETL_Log Tabelle und mit der Frage über die 

Hilfstabelle SR_Umfrage_Frage verbunden. Eine Umfrage ist immer genau einem Umfragetyp 

sowie einem oder mehreren Ergebnissätzen, ETL-Logs und Fragen zuzuordnen. 

- SR_Umfrage_Frage 

Die Hilfstabelle SR_Umfrage_Frage löst die n-m-Beziehung zwischen SR_Umfrage und 

SR_Frage auf. Die Tabelle beinhaltet lediglich die Primärschlüssel der beiden Tabellen 

SR_Umfrage und SR_Frage. 

- SR_Frage 

Die Relation SR_Frage enthält alle Fragen der verschiedenen Umfragen. Zu jeder Frage können 

mehrere Antworten, sowie Oberkategorien, Unterkategorien01 und Unterkategorien02 

gespeichert werden. Die Verbindung zu den Kategorien erfolgt über die Hilfstabelle 

SR_Frage_Kategorie. 

- SR_Antwort 

SR_Antwort ist eine Relation in der alle Antworten gespeichert werden. Jede Antwort gehört 

dabei zu genau einer Frage und zu genau einem Ergebnissatz. 

- SR_Ergebnissatz 

Die Relation zu den Ergebnissätzen beinhaltet die Eckdaten zu einer Umfrage, etwa aus welchem 

Land die Antworten zu einer Umfrage kommen, welche Zeit für das Ausfüllen der Umfrage 

benötigt oder wann die Umfrage bearbeitet wurde. Neben diesen Daten speichert die Tabelle 

fünf Custom_Variablen. Ein Ergebnissatz gehört zu einer oder mehreren Antworten und 

genau einer Umfrage. 

- SR_Frage_Kategorie 

Die Hilfstabelle SR_Frage_Kategorie löst die n-m-Beziehung zwischen SR_Frage und den 

Tabellen SR_Oberkategorie, SR_Unterkategorie01 und SR_Unterkategorie02 auf. Die Tabelle 

beinhaltet die Primärschlüssel der genannten Tabellen, sowie einen eigenen Primärschlüssel. 

- SR_Oberkategorie 

Die Oberkategorien werden in der Relation SR_Oberkategorie gespeichert. Jede Oberkategorie 

kann einer oder mehreren Fragen zugeordnet sein und kann mehrere Unterkategorien der 

ersten Ebene (Unterkategorie01) besitzen. 

316



- SR_Unterkategorie01 

Eine Unterkategorie der ersten Ebene wird in der Relation SR_Unterkategorie01 (in der physikalischen 

Datenbank SR_Unterkategorie genannt) beschrieben. Jede Unterkategorie01 kann 

einer oder mehreren Fragen zugeordnet sein und kann mehrere Unterkategorien der zweiten 

Ebene (Unterkategorie02) enthalten. 

- SR_Unterkategorie02 

Die Unterkategorie der zweiten Ebene wird in der Relation SR_Unterkategorie02 (in der physikalischen 

Datenbank SR_Gruppe genannt) abgelegt. Jede Unterkategorie02 kann einer oder 

mehreren Fragen zugeordnet sein. 

Besonderheiten an dem Datenbankmodell sind die Mehrfach-Beziehungen im Bereich der Kategorien. 

Diese Beziehungen sind notwendig, weil einer Frage sowohl eine Oberkategorie, wie auch eine Unterkategorie01 

und auch eine Unterkategorie02 zugeordnet werden kann und diese Kategorien hierarchisiert 

sind (Oberkategorie Unterkategorie01 Unterkategorie02). Während die Tabelle 

SR_Frage_Kategorie somit die Zuordnung von Fragen und Kategorien darstellt, stellen die einzelnen 

Tabellen und deren Verknüpfung untereinander die Hierarchien der Kategorien dar. 

Die folgende Abbildung zeigt das Datenbankmodell, die für die Kategorisierung relevanten (rot markierten) 

Relationen, wie diese zueinander in Beziehung stehen und wie diese in das Datenbankmodell 

integriert sind. 

Für den Fragenpool sind die Umfrage_ID aus der Tabelle SR_Umfrage, die Frage_ID und der Fragetext 

aus der Tabelle SR_Fragen, sowie die Daten aus den Tabellen SR_Oberkategorie, 

SR_Unterkategorie01 und SR_Unterkategorie02 wesentlich. 

317



Abbildung 4.1: Datenbankmodell 

5. Fragenpool 

Der erstellte Fragenpool sorgt dafür, dass Daten mit Hilfe des erstellten Java-Programms in die Datenbank 

geschrieben werden und dass Fragen einer Umfrage durch die Benutzer kategorisiert werden. In 

diesem Kapitel wird der Fragenpool aus benutzerspezifischer und technischer Sicht beschrieben. 

5.1 Benutzerspezifische Beschreibung 

In diesem Kapitel wird auf die benutzerspezifische Sicht des Fragenpools eingegangen. Es wird erläutert, 

wie der Fragenpool durch die Benutzer anzuwenden ist. 

5.1.1 Umfrage ID 

In der Registerkarte „Umfrage ID“ wird die Umfrage ID von in QuestionPro neu erstellten Umfragen 

eingetragen. Mit dem Eintragen der Umfrage ID wird die jeweilige Umfrage von der ETL-Anwendung 

erkannt in dem Prozess des Programmes bearbeitet und die Daten beim nächsten Schreibvorgang in 

die Datenbank übertragen. Am folgenden Tag sind die Daten in der Datenbank verfügbar. Die Umfra- 

318



ge ID wird von QuestionPro vergeben und muss aus der Webanwendung entnommen werden, z. B. 

Umfrage_ID (z. B. 3391589). 

Um die gewünschte Umfrage ID zu finden ist eine Anmeldung bei QuestionPro mit einem gültigen 

Account auf der QuestionPro Webseite (http://www.questionpro.com/) nötig. Anschließend muss die 

entsprechende Umfrage unter Surveys My Surveys per Klick auf ihren Namen ausgewählt werden. 


Abbildung 5.1: QuestionPro MySurvey-Site 

Die Umfrage ID befindet sich in der Adresszeile des Browsers. Es handelt sich um eine siebenstellige 

Nummer am Ende der Webddresse hinter surveyID=. Beispielsweise lautet bei der Adresse 

www.questionpro.com/a/editSurvey.do?surveyID=3391589 die Umfrage ID 3391589. 


Abbildung 5.2: QuestionPro Umfrage ID ermitteln 

319



Ist die siebenstellige Umfrage ID ermittelt worden, muss das CEWE Intranet aufgerufen werden. Die 

Seite, auf der die Benutzeranwendung dem Fachbereich zur Verfügung gestellt wird, wird durch den 

IT-Bereich der CEWE bekannt gegeben. 

Wird die entsprechende Seite des CEWE Intranets aufgerufen, öffnet sich die Benutzeranwendung zur 

Verwaltung der Umfragedaten. In der Registerkarte „Umfrage ID“ wird im gleichnamigen Textfeld 

die ermittelte Umfrage ID eingetragen und mit dem Button Umfrage erfassen bestätigt. Die Umfrage 

ist vom System erfasst und wird bei dem nächsten Datenabruf geladen. 

Quelle: Screenshot aus Benutzeranwendung 

Abbildung 5.3: Umfrage ID 

Es wird dringend geraten, die Umfrage ID per Kopierfunktion (Strg-C) aus der Adresse der Umfrage 

zu übernehmen und in das Eingabefeld einzufügen (Strg-V). Das Eingabefeld akzeptiert ausschließlich 

exakt siebenstellige Zahlen, um dem Erfassen von falschen Umfrage IDs vorzubeugen. Kommt es 

jedoch zu einem Zahlendreher bei manueller Eingabe, verursacht der Versuch, die falsche Umfrage 

abzurufen, zwangsläufig Konflikte. Durch das Kopieren und Einfügen der ID kann diesem Problem 

entgegen gewirkt werden. 

Sollte es dennoch zu einer Falscheingabe gekommen sein, so kann in der Übersichtstabelle „Vorhandene 

Umfragen“ der Eintrag wieder gelöscht werden. Dies sollte unverzüglich passieren um den ein- 

320



wandfreien Ablauf des Datenabrufs zu sichern. Weitere Informationen hierzu sind in Kapitel 5.2.1 

gegeben. 

5.1.2 Fragenkategorisierung 


Abbildung 5.4: Fragenkategorisierung 

In der Rubrik „Fragenkategorisierung“ können Fragen von Umfragen kategorisieren werden. Hierzu 

wird im Fragenpool in die Fragenkategorisierung navigiert. Zunächst wird die Umfrage ausgewählt in 

der die Frage, welche bearbeitet werden soll, enthalten ist. Anschließend wird in der Zeile Frage die 

gewünschte Frage ausgewählt und zu dieser eine Oberkategorie, Unterkategorie 1 und Unterkategorie 

2 in den entsprechenden Drop-Down-Feldern angegeben. Falls keine genauere Kategorisierung über 

Unterkategorien gewünscht ist, kann die Kategorie „(leer)“ verwendet werden. Sobald die gewünschten 

Kategorien ausgewählt wurden, muss die Eingabe mit dem Button „Kategorien zuweisen“ bestätiget 

werden. Einer Frage können grundsätzlich mehrere Kategorien zugwiesen werden, wenn sie sich 

auf mehrere Sachverhalte bezieht, die nicht von einer einzelnen Kategorie abzudecken sind. 

321



5.1.3 Kategorien erstellen 


Abbildung 5.5: Neue Kategorien anlegen 

Kann eine Frage nicht durch die bestehenden Kategorien beschrieben werden, können neue Kategorien 

angelegt werden. Um eine neue Kategorie hinzuzufügen, ist die Registerkarte „Neue Kategorien anlegen“ 

zu wählen. In der Registerkarte können neue Oberkategorien, neue Unterkategorien der ersten 

Ebene (Unterkategorie 1) und neue Unterkategorien der zweiten Ebene (Unterkategorie 2) erstellt 

werden. 

Im Falle einer neuen Oberkategorie muss lediglich den Name der neuen Oberkategorie in das Textfeld 

„Neue Oberkategorie“ eingegeben und mit dem Button „Oberkategorie einfügen“ bestätigt werden. 

Zum Erstellen einer neuen Unterkategorie der ersten Ebene muss zunächst die Oberkategorie gewählt 

werden, zu welcher die Unterkategorie der ersten Ebene angelegt werden soll. Hierzu wird im Drop- 

Down-Feld „Oberkategorie auswählen“ die Oberkategorie ausgewählt und anschließend im Textfeld 

„Neue Unterkategorie 1“ der gewünschte Name der neuen Unterkategorie eingegeben. Die Eingabe 

muss mit dem Button „Unterkategorie 1 einfügen“ bestätigt werden. 

Das Anlegen einer neuen Unterkategorie der zweiten Ebene verläuft ähnlich. Hierfür werden die gewünschte 

Oberkategorie und die Unterkategorie 1 aus den entsprechenden Drop-Down-Feldern ausgewählt 

und anschließend die Unterkategorie der zweiten Ebene in das Textfeld „Neue Unterkategorie 

2“ eingegeben. Die Eingabe wird gespeichert, indem der Button „Unterkategorie 2 einfügen“ geklickt 

wird. 

Bei der Anlage von neuen Kategorien ist zu beachten, dass diese nicht gelöscht werden können. 

322



5.1.4 Fragenübersicht 


Abbildung 5.6: Fragenübersicht 

Eine Übersicht über alle Fragen und die zu diesen zugewiesenen Kategorien sowie eine Option zum 

Löschen einer Zuordnung von Kategorien zu einer Frage ist unter der Rubrik „Fragenübersicht“ zu 

finden. In dieser Übersicht können die Spalten Fragentext, Oberkategorie, Unterkategorie01 und Unterkategorie02 

mit einem Klick auf den Spaltennamen der Tabelle sortiert werden. Der erste Klick 

sortiert die Tabelle von A-Z, bei einem weiteren Klick von Z-A. Ein Eintrag aus dieser Tabelle bzw. 

eine Zuordnung von Kategorien zu einer Frage kann mit einem Klick auf den Button 

in der entsprechenden 

Zeile gelöscht werden. 

323



5.1.5 Kategorienübersicht 


Abbildung 5.7: Kategorienübersicht 

Die Registerkarte „Kategorienübersicht“ enthält eine Übersicht über die bisher vorhandenen Kategorien 

und deren Hierarchie. Die Übersicht dient lediglich der Information und enthält somit keine Funktionen. 

Die Kategorien können durch einen Klick auf die jeweiligen Spaltennamen von A-Z, durch 

einen zweiten Klick von Z-A sortiert werden. 

5.2 Technische Beschreibung 

In diesem Kapitel wird auf die technische Sicht der Benutzeranwendung eingegangen. Es wird erläutert, 

wie durch Benutzereingaben die Daten in die vorgesehenen Tabellen der Datenbank des Fragenpools 

geschrieben werden. Da sich SQL-Befehle und Trigger häufig sehr ähnlich sind, werden sie 

nicht bei jedem Vorkommen im Detail aufgeführt sondern entsprechend verwiesen. Es wird außerdem 

beschrieben, wo und wie die ETL-Anwendung (siehe Kapitel 3) angestoßen wird. 

324



5.2.1 Umfrage ID 

Abbildung 5.8: Umfrage ID 

In der Registerkarte „Umfrage ID“ werden in QuestionPro neu angelegte Umfragen dem System hinzugefügt. 

In das Textfeld wird die von QuestionPro vergebene Umfrage_ID (z. B. 3351683) eingegeben. 

Die Eingabe wird durch den Button „Umfrage erfassen“ bestätigt, welcher die Umfrage_ID mit 

folgendem Insert-Befehl in die Datenbanktabelle SR_Umfrage schreibt: 

INSERT INTO 

VALUES 

SR_UMFRAGE (UMFRAGE_ID) 

(:UMFRAGE_ID_TEXTBOX) 

Die Tabelle SR_Umfrage wird von der erstellten ETL-Anwendung verwendet, um die Daten der jeweiligen 

Umfragen abzurufen. Beim nächsten Durchlauf des Datenabrufs werden die Daten der zur 

neu hinzugefügten Umfrage_ID zugehörigen Fragen, Antworten und Eckdaten aus QuestionPro abgerufen 

und somit die Datenbank gefüllt. 

Bei dem Schreibvorgang in die Datenbank wird auf die folgenden Tabellen zugegriffen: 

- SR_Umfragetyp 

- SR_Umfrage 

- SR_Umfrage_Frage 

- SR_Frage 

- SR_Antwort 

- SR_Ergebnissatz 

- SR_ETL_Log 

In der Registerkarte ist weiterhin eine Übersicht enthalten, welche das Löschen von Umfrage_ID zulässt. 

Diese Funktion ist notwendig, damit der Mitarbeiter, welche die Umfrage_ID eingibt, bei einer 

Fehleingabe die entsprechende Umfrage_ID wieder löschen kann. Die Übersicht wird gefüllt durch 

folgendes SQL-Statement: 

325



SELECT 

FROM 

UMFRAGE_ID, BEZEICHNUNG 

SR_UMFRAGE 

Zum Löschen wird dieses Statement verwendet: 

DELETE FROM 

WHERE 

SR_UMFRAGE 

(UMFRAGE_ID = :UMFRAGE_ID) 

ACHTUNG: Bei empfohlener Bedienung ist es nahezu ausgeschlossen eine fehlerhafte Umfrage ID 

einzutragen. Für den Fall dass dies dennoch passiert, kann sie manuell gelöscht werden. Wird jedoch 

eine fehlerhafte Umfrage_ID nicht gelöscht, bricht der nächste Durchlauf der ETL-Anwendung ab und 

schreibt keine Daten mehr aus QuestionPro in die CEWE Datenbank. 

5.2.2 Fragenkategorisierung 

Abbildung 5.9: Fragenkategorisierung 

In der Registerkarte „Fragenkategorisierung“ werden Attribute an eine Frage angehängt und die Frage 

somit kategorisiert. Die zu vergebenden Attribute sind hierarchisch aufgebaut. Es gibt eine Oberkategorie, 

eine Unterkategorie01 und eine Unterkategorie02 (in der realisierten Datenbank „Gruppe“ genannt). 

In der Maske wird zunächst in einem Drop-Down-Menü der Name einer zuvor erfassten Umfrage 

aus der Tabelle SR_Umfrage ausgewählt. Der Inhalt des Drop-Down-Menüs ist definiert durch: 

SELECT 

FROM 

BEZEICHNUNG, UMFRAGE_ID 

SR_UMFRAGE 

Im nächsten Menü können die zur gewählten Umfrage gehörenden Fragen ausgewählt werden. Die 

passenden Fragen werden durch folgendes Statement selektiert: 

326



SELECT 

FROM 

JOIN 

ON 

WHERE 

SR_UMFRAGE_FRAGE.UMFRAGE_ID, SR_FRAGE.FRAGE_ID, 

SR_FRAGE.TEXT 

SR_FRAGE 

SR_UMFRAGE_FRAGE 

SR_UMFRAGE_FRAGE.FRAGE_ID = SR_FRAGE.FRAGE_ID 

UMFRAGE_ID = :UMFRAGE_ID_DDL 

In den drei folgenden Menüs werden nun nach Bedarf Oberkategorie mit oder ohne Unterkategorien 

ausgewählt. Das Statement zum Füllen der Drop-Down-Menüs erfolgt durch diese Statements: 

- Drop-Down-Menü der Oberkategorie 

SELECT 

FROM 

ORDER BY 

OBERKATEGORIE_ID, BEZEICHNUNG 

SR_OBERKATEGORIE 

BEZEICHNUNG 

- Drop-Down-Menü der Unterkategorie01 

SELECT 

FROM 

JOIN 

SR_OBERKATEGORIE.OBERKATEGORIE_ID, 

SR_UNTERKATEGORIE.UNTERKATEGORIE_ID, 

SR_UNTERKATEGORIE.BEZEICHNUNG 


SR_UNTERKATEGORIE 

ON SR_OBERKATEGORIE.OBERKATEGORIE_ID = 

SR_UNTERKATEGORIE.OBERKATEGORIE_ID 

WHERE SR_OBERKATEGORIE.OBERKATEGORIE_ID = 

:OBERKATEGORIE_DDL 

ORDER BY 

BEZEICHNUNG 

- Drop-Down-Menü der Unterkategorie02 

SELECT 

FROM 

JOIN 

SR_UNTERKATEGORIE.UNTERKATEGORIE_ID, 

SR_GRUPPE.GRUPPE_ID, SR_GRUPPE.BEZEICHNUNG 


SR_GRUPPE 

ON SR_UNTERKATEGORIE.UNTERKATEGORIE_ID = 

SR_GRUPPE.UNTERKATEGORIE_ID 

JOIN 


327





WHERE SR_UNTERKATEGORIE.UNTERKATEGORIE_ID = 

:UNTERKATEGORIE_DDL 

AND SR_OBERKATEGORIE.OBERKATEGORIE_ID = 

:OBERKATEGORIE_DDL 

ORDER BY 

BEZEICHNUNG 

Die ausgewählten Kategorien werden über den Button „Kategorien zuweisen“ bestätigt. Dies löst einen 

aus den Drop-Down-Menüs zusammengesetzten Insert-Befehl aus, welcher in der Tabelle 

SR_Frage_Kategorie einen Datensatz anlegt, der der jeweiligen Frage_ID eine Oberkategorie, Unterkategorie01 

und Unterkategorie02 zuweist. Der Schreibvorgang erfolgt durch dieses Statement: 

INSERT INTO SR_FRAGE_KATEGORIE (FRAGE_ID, OBERKATEGORIE_ID, UN- 

TERKATEGORIE_ID, GRUPPE_ID) 

VALUES 

(:FRAGE_ID_DDL, :OBERKATEGORIE_ID_DDL, 

:UNTERKATEGORIE_ID_DDL, :GRUPPE_ID_DDL) 

5.2.3 Kategorien erstellen 

Abbildung 5.10: Kategorien erstellen 

Um eine neue Kategorie hinzuzufügen ist die Registerkarte „Kategorie erstellen“ vorgesehen. Hier 

können neue Oberkategorien, neue Unterkategorien der ersten Ebene (Unterkategorie01) und neue 

Unterkategorien der zweiten Ebene (Unterkategorie02) angelegt werden. 

Soll eine neue Oberkategorie angelegt werden, muss lediglich der gewünschte Name eingegeben und 

bestätigt werden. Die neue Oberkategorie wird mittels Insert-Befehl in die Tabelle SR_Oberkategorie 

geschrieben. Der Befehl lautet: 

INSERT INTO 

328 

SR_OBERKATEGORIE (BEZEICHNUNG)



VALUES 

(:OBERKATEGORIE_ID) 

Dabei bekommt sie über den Trigger TR_SR_Oberkategorie und die Sequenz SQ_SR_Oberkategorie 

eine fortlaufende ID, analog zur Frage_Kategorie_ID im vorigen Abschnitt, zugewiesen. Zusätzlich 

wird über den Trigger TR_SR_Oberkategorie_Leer in der Tabelle SR_Unterkategorie eine zu der neuen 

Oberkategorie gehörige Unterkategorie namens „ (leer)“ angelegt, welche genutzt werden kann um 

einer Frage nur eine Oberkategorie ohne weitere Detaillierung zuzuweisen. Zu beachten ist hier die 

Leerstelle, welche genutzt wird um die alphabetische Sortierung in den Drop-Down-Menüs zu erleichtern. 

Der verwendete Trigger ist definiert durch: 

CREATE OR REPLACE 

TRIGGER 

TR_SR_OBERKATEGORIE_LEER 

AFTER INSERT 

ON 


BEGIN 

INSERT INTO 

VALUES 

SR_UNTERKATEGORIE (OBERKATEGORIE_ID, BEZEICHNUNG) 

(SQ_SR_OBERKATEGORIE.currval, ' (leer)'); 

END; 

Eine Unterkategorie der ersten Ebene zu erstellen erfolgt wird im zweiten Abschnitt des Tabs. Zunächst 

wird in einem Drop-Down-Menü die Oberkategorie ausgewählt, zu der die neue Unterkategorie01 

gehören soll. Das Drop-Down-Menü wird dabei per folgenden Select-Befehl gefüllt: 

SELECT 

FROM 

ORDER BY 

OBERKATEGORIE_ID, BEZEICHNUNG 


BEZEICHNUNG 

Anschließend wird der Name der neuen Unterkategorie01 eingegeben und gespeichert. Die neue Unterkategorie01 

wird mit einem entsprechenden Verweis auf die Oberkategorie in die Tabelle 

SR_Unterkategorie geschrieben. Das Insert-Statement lautet: 

INSERT INTO 

VALUES 

SR_UNTERKATEGORIE (OBERKATEGORIE_ID, BEZEICHNUNG) 

(:OBERKATEGORIE_ID, :BEZEICHNUNG) 

Dabei wird wiederum über den Trigger TR_SR_Unterkategorie mit der verbundenen Sequenz 

SQ_SR_Unterkategorie ein fortlaufender Primärschlüssel erstellt. Analog zum Anlegen einer Oberka- 

329



tegorie wird auch in diesem Fall in der nächst tieferen Ebene ein Datensatz mit der Bezeichnung „ 

(leer)“ angelegt. Zuständig ist in diesem Fall der Trigger TR_SR_Unterkategorie_Leer, welcher analog 

zu TR_SR_Oberkategorie_Leer funktioniert. Da diese Kategorie immer dann angelegt wird, wenn 

eine neue Unterkategorie erstellt wurde, kommt es beim Anlegen einer Oberkategorie zu einer Verkettung 

der Trigger. Beim Anlegen der Oberkategorie wird also die Unterkategorie01 „ (leer)“ erstellt, 

was wiederrum das Anlegen der Unterkategorie02 „ (leer)“ auslöst. So wird sichergestellt, dass in 

jeder hierarchischen Stufe die leere Kategorie zur Verfügung steht. 

Eine Unterkategorie der zweiten Ebene wird schließlich im dritten Abschnitt des Tabs angelegt. Hier 

wird zunächst die zugehörige Oberkategorie ausgewählt. Diese gibt durch einen entsprechenden Select-Befehl 

die möglichen Unterkategorie01 im nächsten Drop-Down-Menü vor. Es wird der folgende 

Befehl genutzt: 

SELECT 

FROM 

SR_OBERKATEGORIE.OBERKATEGORIE_ID, UNTERKATEGORIE_ID 



JOIN SR_OBERKATEGORIE ON SR_UNTERKATEGORIE.OBERKATEGORIE_ID = 

SR_OBERKATEGORIE.OBERKATEGORIE_ID 

WHERE 

ORDER BY 

SR_OBERKATEGORIE.OBERKATEGORIE_ID = :SELECTED_OK 

BEZEICHNUNG 

Als nächstes wird eine Unterkategorie01 ausgewählt, ein Name für die Unterkategorie02 angegeben 

und bestätigt. Mit der Speicherung wird der Name der neuen Unterkategorie02 mit dem entsprechenden 

Verweis auf die Oberkategorie und Unterkategorie01 in die Tabelle SR_Gruppe geschrieben und 

bekommt über den Trigger TR_SR_Gruppe und die Sequenz SQ_SR_Gruppe einen fortlaufenden 

Primärschlüssel zugewiesen. Das Insert-Statement zum Schreiben der Unterkategorie lautet: 

INSERT INTO 

VALUES 

SR_GRUPPE UNTERKATEGORIE_ID, BEZEICHNUNG 

(:UNTERKATEGORIE_ID, :BEZEICHNUNG) 

330



5.2.4 Fragenübersicht 

Abbildung 5.11: Fragenübersicht 

In der Registerkarte „Fragenübersicht“ ist ein Überblick über alle Fragen aus allen Umfragen und ihrer 

zugewiesenen Kategorien gegeben, welche per folgendem Join aus der Datenbank abgerufen werden: 

SELECT 

FROM 

JOIN 

ON 

JOIN 

SR_FRAGE_KATEGORIE:FRAGE_KATEGORIE_ID, SR_FRAGE.TEXT, 

SR_OBERKATEGORIE.BEZEICHNUNG, SR_GRUPPE.BEZEICHUNG, 


SR_FRAGE_KATEGORIE 

SR_FRAGE 

SR_FRAGE.FRAGE_ID = SR_FRAGE_KATEGORIE.FRAGE_ID 



SR_FRAGE_KATEGORIE.OBERKATEGORIE_ID 

LEFT JOIN SR_UNTERKATEGORIE 


SR_FRAGE_KATEGORIE.UNTERKATEGORIE_ID 

LEFT JOIN SR_GRUPPE 

ON 

ORDER BY 

SR_GRUPPE.GRUPPE_ID = SR_FRAGE_KATEGORIE.GRUPPE_ID 

SR_GRUPPE.BEZEICHNUNG,SR_UNTERKATEGORIE.BEZEICHNUNG, 

SR_OBERKATEGORIE.BEZEICHNUNG, TEXT 

Zugewiesene Kategorien können aus der Tabelle SR_Frage_Kategorie gelöscht werden. Hierzu ist in 

jeder Zeile ein entsprechender Button vorhanden, welcher folgenden Delete-Befehl ausführt: 

DELETE FROM 

WHERE 

SR_FRAGE_KATEGORIE 

FRAGE_KATEGORIE_ID = :FRAGE_KATEGORIE_ID 

331



5.2.5 Kategorienübersicht 

Abbildung 5.12: Kategorienübersicht 

Ähnlich wie die vorherige Registerkarte dient die Registerkarte „Kategorienübersicht“ dazu einen 

Überblick zu geben, in diesem Fall über die vorhandenen Kategorien. Die Übersicht wird aus einem 

Join der Ober- und Unterkategorien gefüllt. Da diese Kategorien bereits Fragen zugeordnet sein können, 

ist es nicht möglich sie nachträglich wieder zu löschen. Die Tabelle wird mit folgendem Select- 

Befehl gefüllt: 

SELECT * 

FROM 


LEFT JOIN SR_UNTERKATEGORIE 



LEFT JOIN SR_GRUPPE 


SR_GRUPPE.UNTERKATEGORIE_ID 

ORDER BY 

SR_OBERKATEGORIE.BEZEICHNUNG, 

SR_UNTERKATEGORIE.BEZEICHNUNG, SR_GRUPPE.BEZEICHNUNG 

6. Fazit 

Nach Abschluss des Projektes hat CEWE von der Projektgruppe einen automatisierten, softwaregestützten 

Prozess zur Kategorisierung und Lagerung von Fragen und deren Ergebnissen von Umfragen 

erhalten. Nach dem Beschluss, die Benutzeranwendung zur Verwaltung des Fragenpools zu realisieren, 

sind die analytischen Aufgaben von Business Intelligence (BI) Projekten entfallen. An deren Stelle 

wurde der gesamte funktionale BI Anteil umgesetzt bzw. die Basis für den analytischen BI Anteil 

geschaffen. 

332



Herausforderungen des Projektes „gestochen scharfe Fragen stellen“ gab es für die Projektgruppe 

insbesondere bei der Schnittstelle bzw. dem Erstellen eines Programms, welches die Fragen und Ergebnisse 

zu einer Umfrage aus QuestionPro exportiert und in das DataWarehouse von CEWE importiert. 

Die im DV-Konzept angestrebte Variante (siehe Soll-Zustand) des Datentransports mittels REST 

und Oracle Warehouse Builder (OWB) konnte nicht realisiert werden, da festgestellt wurde, dass 

REST und OWB nicht kompatibel sind. OWB und SOAP, das von QuestionPro bis Ende 2012 eingesetzte 

API hätten nach Informationen der Projektgruppe gut miteinander kommuniziert, aber die Umstellung 

von QuestionPro auf REST hat die ursprünglichen Pläne der Projektgruppe verworfen. Das 

Erkennen dieser Problematik hat aufgrund der Informationspolitik des Anbieters der Projektgruppe 

viel Zeit geraubt, ebenso wie die Suche nach einer alternativen Lösung. Es wurde nach einiger Zeit 

entschieden, die Programmierung einer eigenen auf Java basierenden ETL-Anwendung zum Datentransport 

vorzunehmen, da eine Umsetzung mit SOAP nicht zukunftsorientiert schien. Für den Datenexport 

mittels REST war eine ständige Kommunikation mit den QuestionPro Entwicklern notwendig, 

da sich die REST API von QuestionPro noch im Beta- bzw. Entwicklungsstadium befand. Ende Dezember 

2012 hatte die ETL-Anwendung einen Entwicklungsstand erreicht, der es ermöglichte, erste 

Daten in die von der Projektgruppe angelegte Datenbank im CEWE Schema zu schreiben. Erste provisorische 

Reports waren im Januar möglich. Anfang Februar wurde dann mit CEWE die Entscheidung 

getroffen, eine Benutzeranwendung zur Kategorisierung von Fragen zu erstellen. Der Fragenpool inklusive 

Benutzeranwendung war laut Fachkonzept als gewünschtes AddOn zu dem Projekt bzw. als 

optional gekennzeichnet worden. Die Feststellung, dass ein Fragenpool für umfrageübergreifende 

Analysen unumgänglich ist, hat das Projekt umgestoßen und erforderte eine Neustrukturierung. Die 

transportierten Daten mit IBM Cognos und IBM SPSS genauer zu betrachten ist für die Projektgruppe 

in den Hintergrund gerückt, denn das Bestreben eine für CEWE weiterverwendbare Basis bereitzustellen 

bzw. etwas zu schaffen, was CEWE verwenden kann, hatte nun höchste Priorität. Bis Mitte März 

hat die Projektgruppe den Fragenpool inklusive der Benutzeranwendung erstellt und den automatisierten 

und softwaregestützten Prozess mehrfach getestet. 

Die auf den von CEWE fundierten Anforderungen entstandene Basis ist eine funktionierende Grundlage, 

mit der CEWE arbeiten kann, jedoch noch ausbaufähig ist. Welche Funktionen die Benutzeranwendung 

zur Verwaltung der Umfragen und deren Fragen hat und wie sich die Datenströme zwischen 

den verschiedenen Elementen verhalten (siehe insbesondere Kapitel 5.1 und 5.2), wurde in den Kapiteln 

dieser Dokumentation bereits ausführlich beschrieben. 

Im Folgenden werden einige Vorschläge gemacht, welche die Projektgruppe noch eingebaut hätte, 

wäre am Ende die Zeit noch gewesen. 

Vorschläge für die Benutzeranwendung: 

333



- Aktuell erhält der Anwender keine Informationen darüber, ob eine Eingabe erfolgreich in der 

Datenbank gespeichert bzw. gelöscht wurde. Ein Pop-Up wäre hier aus Anwendersicht hilfreich. 

Abbildung 6.1: Pop-Up 

- In dem Bereich der Umfrage ID wird das Löschen von Umfrage_IDs in der Datenbank zugelassen. 

An dieser Stelle sollen nur Umfrage_IDs gelöscht werden können, welche fehlerhaft 

sind. Der Löschvorgang ist notwendig, damit das Java Programm nicht durch eine nicht existierende 

Umfrage_ID gestoppt wird. Eine Prüfung wäre hier hilfreich oder eine einfache Abfrage, 

ob diese Umfrage_ID aus der Datenbank entfernt werden soll. 

Ein der Projektgruppe bekanntes Risiko soll an dieser Stelle ebenfalls erwähnt werden. Das Java Programm 

holt aktuell die Daten zu Umfragen in die CEWE Datenbank, welche innerhalb der letzten 24h 

auf QuestionPro eingegangen sind. Bei einem Ausfall z. B. von den QuestionPro Servern, der mehr als 

24h anhält, könnten hierbei für CEWE kostbare Daten verloren gehen. Das Risiko ist aktuell vorhanden 

und sollte CEWE bewusst sein. QuestionPro garantiert nach eigener Aussage eine Ausfallsicherheit 

von 100%, sodass ein Systemausfall unwahrscheinlich ist, jedoch nicht ausgeschlossen werden 

kann. 

Insgesamt ist somit durch das Projekt „gestochen scharfe Fragen stellen“ eine Basis für weiterführende 

Analysen und Reports entstanden. Das zunächst definierte Projektziel die Arbeitspakete (AP) 1-4 

(Umfrageerstellung (AP1), Ergebnisdatenlagerung (AP2), Berichtswesen (AP3), Prognose (AP4)) zu 

realisieren wurde nicht in Gänze erreicht. Jedoch wurde mit der Realisierung des AP5 (Fragenpool) 

ein zu Beginn nicht geplanter Bereich des gesamten Projektes „gestochen scharfe Fragen stellen“ 

abgedeckt, wodurch eine bessere Ausgangslage und Datenbasis für die weiteren Arbeitspakete entstanden 

ist. 

Mit dem abgelieferten Ergebnis ist die Projektgruppe CEWE zufrieden. 

334



Anhang 

A. Protokolle 

335



336



337



338



339



340



341



342



343



344



345



346



347



348



349



350



351



352



353



354



355



356



357



358



359



360



361



362



363



364



366



367



368



369



370


Smart Wind Farm Control – Fachkonzept 



Gruppe: Smart Wind Farm Control 

Fachkonzept 

371



372



Inhaltsverzeichnis Fachkonzept Smart Wind Farm Control 



1. Ziele und Visionen .......................................................................................................... 376 

2. Rahmenbedingungen ....................................................................................................... 376 

2.1 Vorgabe aus der Business Intelligence-Strategie ....................................................... 377 

2.2 Projektspezifische technische und organisatorische Bedingungen ............................ 377 

2.2.1 Team ................................................................................................................ 377 

2.2.2 Kommunikation ............................................................................................... 378 

2.2.3 Technologien ................................................................................................... 378 

2.2.4 Stakeholder-Definition .................................................................................... 379 

3. Fragestellungen und unternehmerischer Nutzen ............................................................. 379 

4. Analytische Anforderungen ............................................................................................ 380 

4.1 Arbeitspaket 1: Windenergieanlagen und SAP Hana Know-how Aufbau ................. 380 

4.2 Arbeitspaket 2: Analyse und Übernahme der Windpark-Datenstruktur .................... 381 

4.3 Arbeitspaket 3: Simulation eines Windparks ............................................................. 382 

4.4 Arbeitspaket 4: Analyse und Reporting ..................................................................... 382 

4.5 Arbeitspaket 5: Technologievergleich ........................................................................ 383 

5. Kennzahlen ..................................................................................................................... 383 

6. Semantische Modellierung .............................................................................................. 386 

7. Nichtanalytische Anforderungen .................................................................................... 386 

8. Literaturverzeichnis ........................................................................................................ 387 

Anhang. .................................................................................................................................. 388 

A. Kennzahlen ..................................................................................................................... 388 

373




Tabelle 5.1: Kennzahlen-Steckbrief ....................................................................................... 384 

Tabelle A.1: Kennzahl Anzahl WEA ..................................................................................... 388 

Tabelle A.2: Kennzahl Größe des Windparks ........................................................................ 388 

Tabelle A.3: Kennzahl Standort des Windparks .................................................................... 389 

Tabelle A.4: Kennzahl Längengrad des Windparks ............................................................... 389 

Tabelle A.5: Kennzahl Breitengrad des Windparks ............................................................... 390 

Tabelle A.6: Kennzahl Soll-Leistung des Windparks ............................................................ 390 

Tabelle A.7: Kennzahl Wassertiefe des Windparks ............................................................... 391 

Tabelle A.8: Kennzahl Vorhersage Windgeschwindigkeit .................................................... 392 

Tabelle A.9: Kennzahl Vorhersage Luftfeuchtigkeit ............................................................. 392 

Tabelle A.10: Kennzahl Vorhersage Wellenhöhe .................................................................. 393 

Tabelle A.11: Kennzahl Vorhersage Temperatur .................................................................. 394 

Tabelle A.12: Kennzahl Vorhersage Luftdruck ..................................................................... 394 

Tabelle A.13: Kennzahl Vorhersage Niederschlag ................................................................ 395 

Tabelle A.14: Kennzahl Vorhersage Windrichtung ............................................................... 395 

Tabelle A.15: Kennzahl Vorhersage Wahrscheinlichkeit ...................................................... 395 

Tabelle A.16: Kennzahl Hersteller ......................................................................................... 396 

Tabelle A.17: Kennzahl Nabenhöhe ...................................................................................... 396 

Tabelle A.18: Kennzahl Rotorblattlänge ................................................................................ 397 

Tabelle A.19: Kennzahl Anzahl Rotorblätter ......................................................................... 397 

Tabelle A.20: Kennzahl Einschaltgeschwindigkeit ............................................................... 398 

Tabelle A.21: Kennzahl Abschaltgeschwindigkeit ................................................................ 399 

Tabelle A.22: Kennzahl Leistung ........................................................................................... 399 

Tabelle A.23: Kennzahl Windgeschwindigkeit ..................................................................... 400 

Tabelle A.24: Kennzahl Betriebsstatus .................................................................................. 400 

Tabelle A.25: Kennzahl Leistungsabgabe .............................................................................. 401 

Tabelle A.26: Kennzahl Windrichtung .................................................................................. 401 

Tabelle A.27: Kennzahl Blatteinstellwinkel .......................................................................... 402 

Tabelle A.28: Kennzahl Außentemperatur ............................................................................. 402 

Tabelle A.29: Kennzahl Luftdichte ........................................................................................ 403 

Tabelle A.30: Kennzahl Luftfeuchtigkeit ............................................................................... 403 

Tabelle A.31: Kennzahl Ölstand-Turbine .............................................................................. 404 

Tabelle A.32: Kennzahl Öldruck-Turbine ............................................................................. 404 

Tabelle A.33: Kennzahl Öltemperatur-Turbine ..................................................................... 405 

Tabelle A.34: Kennzahl Spannung-Turbine ........................................................................... 405 

Tabelle A.35: Kennzahl Stromstärke-Turbine ....................................................................... 406 

Tabelle A.36: Kennzahl Frequenz-Turbine ............................................................................ 406 

Tabelle A.37: Kennzahl Ölstand-Generator ........................................................................... 407 

Tabelle A.38: Kennzahl Öldruck-Generator .......................................................................... 407 

Tabelle A.39: Kennzahl Öltemperatur-Generator .................................................................. 408 

Tabelle A.40: Kennzahl Drehzahl-Generator ......................................................................... 408 

Tabelle A.41: Kennzahl Ölstand-Getriebe ............................................................................. 409 

Tabelle A.42: Kennzahl Öldruck-Getriebe ............................................................................ 409 

Tabelle A.43: Kennzahl Öltemperatur-Getriebe .................................................................... 410 

374




BI 

BO 

DV 

ETL 

HANA 

SPSS 

SQL 

SWF 

VLBA 

WEA 


Business Objects 

Datenverarbeitung 

Extract, Transform, Load 

High Performance Analytic Appliance 

Statistical Package for the Social Sciances 


Smart Wind Farm Control 


Windenergieanlage 

375



1. Ziele und Visionen 

Seit den siebziger Jahren hat das Thema „Nachhaltigkeit und erneuerbare Energien“ weltweit an Bedeutung 

zugenommen. Von den verschiedenen erneuerbaren Energiequellen wie Wind, Sonne, Wasser 

usw. ist die Windenergie derzeit die günstigste und effektivste Lösung. Die Anzahl der aufgebauten 

Windenergieanlagen (WEA) ist daher in den letzten Jahren stark angestiegen. Die Fläche für WEA ist 

jedoch begrenzt, weswegen es zunehmend weniger Möglichkeiten gibt, neue Windparks Onshore, d. 

h. auf dem Land, aufzubauen (bezogen auf Deutschland). Aus diesem Grund werden Windparks verstärkt 

Offshore, d. h. auf dem offenen Meer, errichtet. Um dennoch mehr Energie aus der bestehenden 

Fläche zu erwirtschaften, investieren viele Betreiber in die Optimierung der Prozessabläufe, des Managements 

und der Software-Lösungen. Aufgrund der erhöhten Betriebskosten bei einem Offshore- 

Windpark, die vor allem durch Wartung entstehen, sind auch Offshore-Windparkbetreiber an diesem 

Thema interessiert. Ziel der Windparkbetreiber ist insbesondere die Reduzierung der Kosten durch 

eine optimierte Betriebsführung. 

Die Vision der Projektgruppe ist die Entwicklung und Implementierung einer Lösung für ein besseres 

Windpark-Management. Der Fokus des Projekts liegt auf der Wartung von WEA. Für die Umsetzung 

der Vision werden die Ziele in Arbeitspakete aufgeteilt. Im ersten Arbeitspaket soll grundlegendes 

Wissen über die Windenergie im Allgemeinen und dem vom Auftraggeber gewünschten In-Memory 

Datenbanksystem SAP HANA (High Performance Analytic Appliance) erworben werden. Anschließend 

soll im zweiten Arbeitspaket eine Strukturanalyse der zur Verfügung gestellten WEA-Daten 

durchgeführt werden. Dabei sollen die wesentlichen Zusammenhänge aufgeführt sowie die relevanten 

Kennzahlen herausgearbeitet werden. Anschließend gilt es die Daten in SAP HANA zu importieren. 

Im dritten Arbeitspaket soll ein virtueller Windpark implementiert werden. Dieser kann genutzt werden, 

um einen Datenstrom zu erzeugen, der das Verhalten eines Windparks simuliert. In diesem virtuellen 

Windpark werden jedoch nicht alle Funktionen, Sensoren, etc. implementiert, sondern nur die für 

die Projektgruppe relevanten Parameter. Im Anschluss sollen Business Intelligence (BI) Tools eingesetzt 

werden, um diverse Analysen, Reports sowie Monitoring zu realisieren. Für die Durchführung 

der Vision wird die Projektgruppe mit ForWind und Prof. Peinke kooperieren. 


Im Folgenden werden die Rahmenbedingungen für das Projekt erläutert. Hierbei werden insbesondere 

die projektspezifischen Bedingungen berücksichtigt, welche sich auf das gesamte Projekt und das 

Thema BI im Umfeld der Projektgruppe beziehen. 

376



2.1 Vorgabe aus der Business Intelligence-Strategie 

Die Projektgruppe Cuberunner der Carl von Ossietzky Universität Oldenburg beschäftigt sich mit der 

Entwicklung von Anwendungen im Umfeld der BI. Vorab wurden dabei drei zu bearbeitende Anwendungsfälle 

definiert: Analytisches Customer Relationship Management (in Kooperation mit der CEWE 

Color), Sustainability Customer Relationship Management für nachhaltige Mobilität (Jinengo) und 

Smart Wind Farm Control (SWF) (in Kooperation mit ForWind). Abseits eines projektgruppeninternen 

Aufbaus und Transfers von Know-how (u.a. durch die Seminararbeiten) erfolgt die Bearbeitung 

der einzelnen Anwendungsfälle in personell getrennten Teilgruppen. Die Absprache der einzelnen 

Teilgruppen erfolgt durch regelmäßige Treffen. Folgende Rahmenbedingungen wurden auf Ebene der 

übergeordneten Projektgruppe vereinbart und sind daher auch für die Teilgruppe SWF von Bedeutung. 

Die übergeordnete Projektgruppe hat sich auf ein sequenzielles Vorgehensmodell für die Softwareentwicklung 

geeinigt, das in allen Teilgruppen verwendet werden soll. Als zentrale Artefakte werden 

ein Fachkonzept und ein Datenverarbeitungs (DV)-Konzept erstellt. Inhalte und Gliederungen der 

Konzepte wurden innerhalb der übergeordneten Projektgruppe abgestimmt. Die Realisierung erfolgt 

dabei angelehnt an agile Modelle. Zu Beginn wird daher ein vorläufiges Fachkonzept verfasst und 

formal abgenommen. Im Laufe des Projekts wird dieses Fachkonzept weiter ausgearbeitet und dient so 

anschließend auch dokumentarischen Zwecken. Die Fertigstellung des DV-Konzepts erfolgt gegen 

Mitte der Realisierungsphase. 

Über alle Anwendungsfälle hinweg wird ein Vergleich der verschiedenen eingesetzten BI Technologien 

angestrebt. Dazu wird begleitend zur Realisierung ein Kriterienkatalog für diesen Technologievergleich 

entwickelt. Der tatsächliche Vergleich der verschiedenen Technologien auf Grundlage des 

Katalogs erfolgt gegen Projektende. 

2.2 Projektspezifische technische und organisatorische 

Bedingungen 

In den folgenden Abschnitten werden die technischen und organisatorischen Rahmenbedingungen für 

die Teilgruppe SWF beschrieben. Dazu zählen die Vorstellung des Teams, die verfügbaren Technologien, 

das gegebene Arbeitsumfeld und die Kommunikation innerhalb der Teilgruppe SWF und den 

Ansprechpartnern. 

2.2.1 

Team 

Das Projektteam besteht aus vier Studierenden der Carl von Ossietzky Universität Oldenburg und ist 

eine Teilgruppe der Projektgruppe Cuberunner, welche im Sommersemester 2012 gegründet wurde. 

Die Projektgruppe besteht in der Zeit vom 1. April 2012 bis zum 31. März 2013. 

377



Zum Projektteam gehören folgende Mitglieder: 

• Patrick Böwe 

• Ronja Queck 

• Michael Schumann (Teilgruppenleiter) 

• Deyan Stoyanov 

Der themenspezifische Hauptansprechpartner ist Prof. Peinke von ForWind, dem Zentrum für Windenergieforschung 

der Universitäten Oldenburg, Hannover und Bremen. 

2.2.2 

Kommunikation 

Die interne Kommunikation findet primär über technische Hilfsmittel wie SharePoint, Skype oder E- 

Mail und in Form von gemeinsamen Treffen statt. Diese gemeinsamen Treffen finden während der 

Projektzeit in regelmäßigen Abständen mindestens einmal wöchentlich im gesamten Team statt. Zusätzlich 

werden wöchentliche Treffen mit der gesamten Projektgruppe und den zuständigen Betreuern 

seitens der Carl von Ossietzky Universität Oldenburg abgehalten. Ergänzend werden nach Absprache 

zusätzliche Treffen mit Herrn Prof. Peinke stattfinden. 

2.2.3 

Technologien 

Eine detailliertere Beschreibung der Technologien für die Umsetzung des Projekts wird im DV- 

Konzept beschrieben. Vorweggreifen werden bereits folgende Technologien in den Fokus gesetzt: 

• SAP HANA (In-Memory Technologie) 

• SAP BO (BusinessObjects) 

• Microsoft Excel mit PowerPivot 

Das übergreifende Ziel der gesamten Projektgruppe ist ein Technologievergleich. Im Rahmen der 

Teilgruppe soll daher, falls realisierbar, in Arbeitspaket 5 die In-Memory Technologien SAP HANA 

und Microsoft SQL Server Tabular Mode sowie Analysen mit Data Mining verglichen werden. Neben 

den genannten Systemen werden gegebenenfalls weitere BI-Tools eingesetzt. 

378



2.2.4 

Stakeholder-Definition 

In diesem Abschnitt werden die verschiedenen Stakeholder aus unterschiedlichen Bereichen beschrieben. 

Die primären Stakeholder des Teilprojektes sind die Carl von Ossietzky Universität Oldenburg 

und ForWind (vertreten durch Prof. Peinke). 

Seitens der Carl von Ossietzky Universität Oldenburg wird die Projektgruppe Cuberunner und der 

Bereich Very Large Business Applications (VLBA) als Stakeholder betrachtet. Die Ergebnisse aus der 

Zusammenarbeit fließen in das Gesamtprojekt ein und können weiterhin in zukünftigen wissenschaftlichen 

Arbeiten verwendet werden. 

3. Fragestellungen und unternehmerischer Nutzen 

Die Hauptaufgabe der Gruppe SWF besteht darin, Daten von verschiedenen Sensoren mehrerer WEA 

in eine In-Memory Datenbank zu übertragen und die Daten anschließend zu analysieren. Die Analysen 

werden zum Teil von ForWind zur Verfügung gestellt, wodurch eine Vergleichbarkeit zu dem aktuell, 

nicht auf In-Memory Technologie basierenden Datenbanksystem gewährleistet wird. 

Durch die Verwendung von In-Memory Technologien entsteht für Unternehmen ein potenzieller 

Mehrwert: Auf diese Weise können komplexere Analysen auf einem größeren Datenbasis durchgeführt 

werden. Aktuell basieren die Analysen auf 10-Minuten-Mittelwerten. In-Memory Technologien 

ermöglichen eine Steigerung der Granularität, z. B. könnten die Analysen auf Sekunden-Basis durchgeführt 

oder über einen längeren Zeitraum betrachtet werden. 

Der Fokus der Teilgruppe SWF liegt im Wesentlichen auf dem Bereich der Wartung, da ca. 20 bis 30 

Prozent der Kosten für Windenergie durch Wartung entstehen. Ein mögliches Anwendungsszenario ist 

die Ermittlung der Lebensdauer einer Komponente der WEA. Falls rechtzeitig vor dem Ausfall einer 

Komponente ermittelt werden könnte, dass diese demnächst ausfallen würde, könnte diese bereits bei 

einer Routinewartung getauscht werden. Hierdurch sollen zusätzliche Wartungsarbeiten vermieden 

bzw. reduziert werden, die besonders bei Offshore-Anlagen durch die Wartung per Schiff oder Hubschrauber 

entstehen und hohe Kosten verursachen. 

Ein weiteres Anwendungsszenario stellt das Alerting dar, dies ist ebenfalls in den Bereich der Wartung 

von WEA einzugliedern. Ein Alerting soll in dringenden Fällen ausgelöst werden, beispielsweise 

wenn eine existentielle Komponente ausfällt oder Feuermelder ausgelöst werden. Datenfehler undausfälle 

müssen hierbei berücksichtigt werden. Weiterhin sollen nur dann Alerts ausgelöst werden, 

wenn es sich mit einer hohen Wahrscheinlichkeit um einen schwerwiegenden Fall handelt. 

379




Im folgenden Abschnitt werden die Anforderungen an das Projektteam in Arbeitspaketen dargestellt. 

Diese sind voneinander abhängig und sollen sequentiell bearbeitet werden. 

Zunächst muss eine theoretische Grundlage geschaffen werden, indem sich die Teilgruppe SWF in die 

Themen WEA sowie SAP HANA einarbeitet. Das zweite Arbeitspaket sowie primäre Ziel für die 

Teilgruppe wird es sein, die Rohdaten (auf Sekundenbasis) in das HANA-System zu übertragen. Hierzu 

ist die Implementierung eines ETL-Prozesses (Extract, Transform, Load) angedacht. Anschließend 

sollen die Besonderheiten von Windparks herausgearbeitet und ein Windpark simuliert werden. Mit 

Hilfe des simulierten Windparks soll es möglich sein, verschiedene Analysen auf Basis der Sensordaten 

zu entwerfen und auszuführen. Falls zeitlich möglich, soll im Anschluss ein Technologievergleich 

für die Gesamt-Projektgruppe stattfinden. 

4.1 Arbeitspaket 1: Windenergieanlagen und SAP Hana Know-how 

Aufbau 

Im ersten Arbeitspaket machen sich die Mitglieder der Teilgruppe SWF mit den Themenbereichen 

WEA und der Technologie SAP HANA vertraut. Dieses Arbeitspaket schafft die Basis für die nachfolgenden 

Arbeitspakete. Alle Ergebnisse dieses Arbeitspakets bilden eine Entscheidungsgrundlage 

und Voraussetzung, um einen Windpark zu simulieren und dessen Daten auszuwerten. 

Für das Thema Windenergie sollen die im SharePoint vorliegenden Dateien sowie die von Prof. Peinke 

zur Verfügung gestellten Präsentationen und Informationen analysiert und zusammengefasst werden. 

Zudem sollen weitere Informationen einfließen (Offshore und Onshore), um ein Grundverständnis 

für das Themengebiet der WEA aufzubauen. 

Ergänzend sollen sich die Mitglieder der Teilgruppe SWF in das vorgegebene In-Memory Datenbanksystem 

SAP HANA und die grundlegenden Funktionen dieses SAP Produktes einarbeiten. HANA 

steht für High Performance Analytic Appliance und ist eine 2010 von SAP vorgestellte Datenbanktechnologie. 

Die Besonderheit von SAP HANA liegt in der Verwendung von In-Memory- 

Technologien für den Datenzugriff, welche die Daten im Arbeitsspeicher statt auf der Festplatte vorhalten. 

Die Technologie ermöglicht eine wesentliche Performancesteigerung. 

Ziel ist es neben den allgemeinen Bedienung zu ermitteln, wie das Datenhandling in SAP HANA erfolgt, 

welche Schnittstellen zu anderen Systemen verfügbar sind und welche neuen Funktionen und 

Möglichkeiten angeboten werden. Für das gesamt Thema SWF sollen ins Besondere alle relevanten 

Funktionen und Beschreibungen aus den SAP Dokumenten extrahiert und in der Projektdokumentation 

aufgeführt sowie gekennzeichnet werden. Dabei dient das bereits aufgebaute Wissen über WEA als 

380



Grundlage. Durch die Betrachtung des Themas Windenergie aus dem Blickwinkel von SAP HANA 

könnten unteranderem weitere Wissenslücken ersichtlich werden. Dieses Wissen soll anschließend 

aufgebaut werden und zurück in die Untersuchung von SAP HANA einfließen. 

4.2 Arbeitspaket 2: Analyse und Übernahme der Windpark- 

Datenstruktur 

In diesem Arbeitspaket sollen die vorgegebenen Windpark-Daten analysiert und anschließend in komprimierter 

Form in SAP HANA übernommen werden. Grundlage hierfür ist das in Arbeitspaket 1 aufgebaute 

Grundlagenverständnis. 

Prof. Peinke wird der Teilgruppe Daten zur Verfügung stellen. Es ist offen, ob es sich hierbei um Realdaten 

eines Unternehmens oder um simulierte Daten handelt. Das erste Ziel dieses Arbeitspakets ist 

es, auf Basis der zur Verfügung gestellten Daten eine Datenstrukturanalyse durchzuführen, sowie eine 

grundlegende dokumentierte Datenstruktur zu erarbeiten. Hierbei gilt es, alle Daten klar zu definieren, 

die Datenintegrität zu überprüfen und mögliche Unklarheiten oder Redundanzen im Vorfeld zu identifizieren. 

Weiterhin sollen die Zusammenhänge zwischen den Daten dargestellt werden. 

Basierend auf der erarbeiteten Übersicht sollen alle relevanten Kennzahlen für die SWF Management 

Lösung herausgearbeitet werden. Die Relevanz der Kennzahlen kann im Hinblick auf die zu entwickelnden 

Anwendungsfälle, Reports und Analysen bestimmt werden. Hierfür werden auch externe 

Informationsquellen verwendet, z. B. die Masterarbeit von Oliver Norkus über Windpark Kennzahlen 

und Kennsysteme. Zudem muss beachtet werden, dass der Fokus der Teilgruppe auf dem Thema Wartung 

liegt und nur diese Kennzahlen betrachtet werden sollen. Durch die Bestimmung von Kennzahlen 

kann der Umfang der Daten, die in SAP HANA übernommen werden, wesentlich reduziert werden. 

Im Anschluss gilt es, das zweite Ziel dieses Arbeitspakets zu erreichen, die Migration der ermittelten 

Datenstruktur und der vorhandenen Daten in das SAP HANA System. Basierend auf den durch Prof. 

Peinke zur Verfügung gestellten Daten und den ausgewählten Kennzahlen soll eine neue Datenstruktur 

in SAP HANA erstellt werden, die diese optimal abbildet. Anschließend sollen die vorgegebenen Daten 

in diese Datenstruktur in SAP HANA übernommen werden. Im Gegensatz zu Arbeitspaket 3, in 

dem die Daten wie im realen Leben als Sensordaten zeitlich versetzt in HANA eintreffen (Datenstrom), 

sollen in diesem Arbeitspaket die Daten auf einmal, d. h. als Bulk Load geladen werden. 

Nach Fertigstellung dieses Arbeitspakets sollen die dokumentierte Datenstruktur sowie importierte 

Daten in SAP HANA vorliegen. 

381



4.3 Arbeitspaket 3: Simulation eines Windparks 

Im dritten Arbeitspaket erfolgt die Entwicklung einer Simulation für einen Windparkdatenstrom. Im 

Gegensatz zu Arbeitspaket 2, bei dem die Daten auf einmal in SAP HANA geladen werden, soll dieses 

Arbeitspaket realitätsnäher sein, indem die Daten als Sensordaten kontinuierlich im System eintreffen. 

Auf Grundlage der in Arbeitspaket 2 erzeugten Datenstrukturanalyse und Zufallsalgorithmen kann 

eine Simulation dieser Daten erfolgen. Diese agiert somit als virtueller Windpark und simuliert im 

Sekundentakt zufällige Messdaten der Sensoren. Die Zufallswerte werden dabei durch die jeweiligen 

ermittelten Grenzwerte der von Prof. Peinke bereitgestellten Testdaten eingegrenzt und orientieren 

sich an der bisherigen Datenverteilung. Eventuell können hierfür durch Prof. Peinke zur Verfügung 

gestellte Algorithmen eingesetzt werden. 

Die zu entwickelnde Simulationsanwendung fungiert als Standalone Lösung, um neben SAP HANA 

auch mit anderen möglichen Datenbanken kommunizieren zu können. Weiterhin stellt die Konfigurierbarkeit 

der Datenströme hinsichtlich des Umfangs und zeitlicher Faktoren eine zentrale Anforderung 

dar. 

Das Ziel dieses Arbeitspakets ist einerseits das Testen der Belastbarkeit von SAP HANA sowie andererseits 

die Schaffung einer Basis für Ad hoc-Analysen und -reports (siehe Arbeitspaket 4). 

4.4 Arbeitspaket 4: Analyse und Reporting 

Das Ziel des vierten Arbeitspakets ist die Analyse und visuelle Ausgabe der in SAP HANA gespeicherten 

Daten. Übergreifend ergibt sich somit eine klare Trennung zwischen Dateninput (Bulk Load 

oder Datenstrom), Datenspeicherung (SAP HANA) und Datenoutput (Analyse und Reporting). Alle 

drei Teilbereiche sind auf Grund der vollständigen Abgrenzung dieser jederzeit austauschbar bzw. 

individualisierbar. 

Im Rahmen des Reportings steht die schnelle und umfangreiche Visualisierung von Daten im Vordergrund. 

Hierfür sollen beispielsweise Excel PowerPivot oder SAP BO genutzt werden. Der Fokus des 

Reportings liegt auf der Nutzung des Geschwindigkeitsvorteils, der durch SAP HANA erzeugt wird. 

Daher sollen die Daten und Analysen Ad hoc verändert werden können. Ein möglicher Report könnte 

z. B. eine Übersicht über die Restlaufzeiten aller WEA eines Windparks sein, die durch Umwelteinflüsse 

wie etwa Stürme beeinflusst werden. 

Für die vorausschauende Wartung soll Data Mining eingesetzt werden. Hierbei können durch Anwendung 

von Methoden auf vorhandene Daten (Fehlermeldungen, Erfahrungswerte, historische Analysen) 

neue Muster erkannt werden. Beispielsweise kann die aus den alten Daten ermittelte Klassifikation 

„Wenn Sensor A einen Wert höher 15, Sensor B einen Wert kleiner 0 und Sensor C den Wert TRUE 

382



melden dann fällt Windradbauteil X innerhalb von 2 Monaten aus“ auf neue Daten für Prognosen angewendet 

werden. Diese Analysen können durchgeführt werden, wenn es sich bei den von Prof. Peinke 

zur Verfügung gestellten Daten um Echtdaten handelt. 

Für komplexere Analysen, die Erstellung von Dashboards, das Berichtswesen, usw. werden im Rahmen 

der Teilgruppe SWF BI Tools eingesetzt. Der Fokus liegt auf Microsoft und SAP Anwendungen, 

nach Bedarf werden auch Tools von anderen Anbietern verwendet. Eine genaue Beschreibung der 

Tools findet erst im DV-Konzept statt. 

4.5 Arbeitspaket 5: Technologievergleich 

Das fünfte und letzte Arbeitspaket ist ein Technologievergleich. Dieses optionale Arbeitspaket betrifft 

primär die Ziele der gesamten Projektgruppe Cuberunner, in der die Teilgruppe SWF eingegliedert ist. 

Beim Technologievergleich kann beispielsweise der ETL-Prozess von Sensordaten auf verschiedenen 

In-Memory Datenbanken miteinander verglichen werden. Für die Datenspeicherung können beispielsweise 

Excel mit PowerPivot und SAP BO genutzt werden. Zudem können die Analysen und 

Reports vergleichen werden, wie beispielsweise Data Mining mit IBM SPSS oder Microsoft SQL 

Server. 

5. Kennzahlen 

Eine Kennzahl ist eine Maßzahl, die „quantitativ messbare Sachverhalte in aussagekräftiger, komprimierter 

Form wiedergibt“ (Wöhe 2005, S. 239). Kennzahlen sind von großer Bedeutung für das Projekt 

SWF. Ein wesentliches Ziel des Projekts ist es, Kennzahlen für die Wartung von WEA zu bestimmen. 

Basis für die Auswahl der betrachteten Kennzahlen ist Norkus (2012). Diese Kennzahlen 

sollen im Zuge der Praxisgespräche und nach dem Erhalt von Realdaten erweitert werden. Die Kennzahlen 

sind Basis für die zu entwickelnde Datenstruktur. 

Die in Kapitel 3.2 beschriebenen Kennzahlen sollen im Folgenden für das Projekt SWF festgelegt und 

erläutert werden. Die Kennzahlen basieren, soweit nicht anders gekennzeichnet, auf Norkus (2012). 

Zudem wurden weitere Kennzahlen aus der Zusammenarbeit mit den Projektpartnern abgeleitet, beispielsweise 

Wassertiefe und Rotorblattlänge. Für eine bessere Übersichtlichkeit werden die einzelnen 

Kennzahlen anhand eines Kennzahlen-Steckbriefs dargestellt, dessen Struktur in Tabelle 5.1 definiert 

wird. 

383



ID: {ID} 

Bezeichnung: {Bezeichnung} 

Bedeutung Kennzahlensystem: {Zuordnung zum entsprechenden Kennzahlen-system} 

Beschreibung: 

Dimensionen: 

Exemplarische Analysefragen: 

Berechnung Datenquellen: 

Berechnung: 

Aktualität: 

Eskalationsregeln: 

Anwendung Reports & Dashboards: 

Self-Service-BI: 

Data Mining: 

{Ausführlicherer Beschreibungstext} 

{Auflistung der Dimensionen mit Angabe ihrer Granularität} 

{Beispiele für mögliche Analysefragen} 

{Messgrößen bzw. untergeordnete Kenn-zahlen} 

{Formel} 

{Angabe, wie oft eine Neuberechnung erfolgt} 

{Umgang mit Sollabweichungen, etc.} 

{Verweis auf abhängige Reports & Dash-boards} 

{Beschreibung, ob, wem & wie die Kennzahl für Self- 

Service-BI zur Verfügung steht} 

{Bedeutung der Kennzahl für das Data Mining} 

Sonstiges Verantwortlichkeiten: {Ansprechpartner für weitere Rückfragen} 

Verschiedenes: 

{Weitere Besonderheiten} 

Quelle: Norkus 2012, S. 21 

Tabelle 5.1: Kennzahlen-Steckbrief 

Die Kennzahlen können für leichtere Handhabbarkeit in vier Gruppen eingeteilt werden: Windpark-, 

Wetter, Anlagen- sowie Sensordaten. Die einzelnen Kennzahlen-Steckbriefe befinden sich im Anhang 

A. 

Windparkdaten: 

• Anzahl WEA 

• Größe des Windparks 

• Standort des Windparks 

• Längengrad des Windparks 

• Breitengrad des Windparks 

• Soll-Leistung des Windparks 

• Wassertiefe des Windparks 

Wetterdaten: 

• Vorhersage Windgeschwindigkeit 

• Vorhersage Luftfeuchtigkeit 

• Vorhersage Wellenhöhe 

• Vorhersage Temperatur 

• Vorhersage Luftdruck 

384



• Vorhersage Niederschlag 

• Vorhersage Windrichtung 

• Vorhersage Wahrscheinlichkeit 

Anlagendaten: 

• Hersteller 

• Nabenhöhe 

• Rotorblattlänge 

• Anzahl Rotorblätter 

• Einschaltgeschwindigkeit 

• Abschaltgeschwindigkeit 

• Leistung 

Sensordaten: 

• Timestamp 

• Windgeschwindigkeit 

• Betriebsstatus 

• Leistungsabgabe 

• Windrichtung 

• Blatteinstellwinkel 

• Außentemperatur 

• Luftdichte 

• Luftfeuchtigkeit 

• Ölstand-Turbine 

• Öldruck-Turbine 

• Öltemperatur-Turbine 

• Spannung-Turbine 

• Stromstärke-Turbine 

• Frequenz-Turbine 

• Ölstand-Generator 

• Öldruck-Generator 

• Öltemperatur-Generator 

• Drehzahl-Generator 

• Ölstand-Getriebe 

• Öldruck-Getriebe 

• Öltemperatur-Getriebe 

385




Eine semantische Modellierung ist derzeitig nicht vorstellbar, da für diese die Vorarbeit der ersten 

zwei Arbeitspakete geleistet werden muss und insbesondere WEA Daten vorliegen müssen. Die semantische 

Modellierung wird daher erst im DV-Konzept vorgenommen 

7. Nichtanalytische Anforderungen 

Die wesentlichen nichtanalytischen (oder auch nichtfunktionalen) Anforderungen des Projekts SWF 

sind Leistung und Effizienz sowie Änderbarkeit. Es muss beachtet werden, dass diese Anforderungen 

an die eingesetzte Software gebunden sind und je nach Anwendungsfall durch die Teilgruppe nur in 

begrenztem Rahmen modifizierbar sind. Diese werden im Folgenden näher erläutert. 

Leistung und Effizienz 

Die Anforderungen an die Leistung und Effizienz sind in erster Linie kurze Antwortzeiten und ein 

optimaler Einsatz von Ressourcen. Während der konzeptuellen Einarbeitung in die einzusetzende 

Software sollen daher Faktoren ermittelt und festgelegt werden, wie diese Anforderungen bestmöglich 

realisiert werden können. 

Änderbarkeit 

Da in dem Projekt SWF verschiedene Software Tools eingesetzt werden und die genaue Aufgabenstellung 

von den Praxispartnern und den von ihnen übermittelten Daten abhängen und somit flexibel angepasst 

werden müssen, ist die Änderungsmöglichkeit der Software sehr wichtig. Zudem muss sichergestellt 

sein, dass das System stabil ist und damit Änderungen nicht zu unerwünschten Nebeneffekten 

führen. 

386




Norkus, O. (2012): Entwicklung eines Kennzahlensystems zur Windparksteuerung, Masterarbeit, Universität 

Oldenburg. 

Wöhe, G. (2005): Einführung in die allgemeine Betriebswirtschaftslehre, 22. Auflage, Vahlen Verlag. 

387



Anhang 

A. Kennzahlen 

Gruppe – Windpark (A) 

ID: A001 

388 

Bezeichnung: Anzahl WEA 

Bedeutung Kennzahlensystem: - 

Beschreibung: 

Dimensionen: - 



Berechnung: 

Aktualität: - 

Eskalationsregeln: - 

Anwendung Reports & Dashboards: - 

Self-Service-BI: - 

Data Mining: - 

Sonstiges Verantwortlichkeiten: - 

ID: A002 


Anzahl der installierten Windanlagen 

Wie viele Anlagen sind in dem Windpark installiert? 

Errichtungskonzept 

In Stück (St) 

Darstellung als Wert 

Tabelle A.1: Kennzahl Anzahl WEA 

Bezeichnung: Größe des Windparks 


Beschreibung: 



Größe des Windparks 

Berechnung Datenquellen: Errichtungskonzept 

Berechnung: 








Wie viel Quadratmeter werden für den Windpark 

benötigt? 

In qm (Quadratmeter) 


Tabelle A.2: Kennzahl Größe des Windparks



ID: A003 

Bezeichnung: Standort des Windparks 


Beschreibung: 




Berechnung: - 







Verschiedenes: - 

Koordinaten des Errichtungsortes des Windparks 

Wie lauten die Koordinaten des Errichtungs-ortes 

eines Windparks? 


Tabelle A.3: Kennzahl Standort des Windparks 

ID: A004 

Bezeichnung: Längengrad des Windparks 


Beschreibung: 




Längengrad des Errichtungsortes des Windparks 

Wie lautet der Längengrad des Errichtungs-ortes eines 

Windparks? 


Berechnung: In Grad (°) 








Tabelle A.4: Kennzahl Längengrad des Windparks 

389



ID: A005 

Bezeichnung: Breitengrad des Windparks 


Beschreibung: 



Berechnung Datenquellen: Errichtungskonzept 

Berechnung: In Grad (°) 








Tabelle A.5: Kennzahl Breitengrad des Windparks 

Breitengrad des Errichtungsortes des Windparks 

Wie lautet der Breitengrad des Errichtungsortes 

eines Windparks? 

ID: A006 

Bezeichnung: Soll-Leistung des Windparks 


Beschreibung: 




Berechnung: 








Maximale Leistung, die vom Windpark in Volllast 

produziert werden kann 

Wie viel ist die Gesamtleistung eines Windparks? 

Hersteller 

In MW (Megawatt) 

Betriebsführer 


Tabelle A.6: Kennzahl Soll-Leistung des Windparks 

390



ID: A006 

Bezeichnung: Wassertiefe des Windparks 


Beschreibung: 




Berechnung: 








Durchschnittliche Wassertiefe des gesamten Windparks 

Wie lautet die durchschnittliche Wassertiefe eines 

Windparks? 


In Meter (M) 


Tabelle A.7: Kennzahl Wassertiefe des Windparks 

391



Gruppe – Wetterdaten (B) 

ID: B001 

392 

Bezeichnung: Vorhersage Windgeschwindigkeit 


Beschreibung: 




Berechnung: 






Die Windgeschwindigkeit und die Luftdichte beeinflussen 

die Rotordrehzahl. 

- 

Meteorologie 

Meteorologisches Mess- und Prognoseverfahren. Geschwindigkeit 

[m/s] 

Frühzeitiges Hochfahren oder Abschalten der Anlage 


Sonstiges Verantwortlichkeiten: Betriebsführer, Meteorologie 

ID: B002 



Tabelle A.8: Kennzahl Vorhersage Windgeschwindigkeit 

Bezeichnung: Vorhersage Luftfeuchtigkeit 


Beschreibung: 


Exemplarische Analysefragen: - 

Berechnung Datenquellen: Meteorologie 

Berechnung: 






Hohe Luftfeuchtigkeit und negative Außentemperatur 

sind Indizien für die Möglichkeit des 

Einfrierens der Rotorblätter. 

Meteorologisches Mess- und Prognoseverfahren. 

Prozent [%] 

Bei eingefrorenen Rotorblättern muss die Anlage 

herunter gefahren werden. 





Tabelle A.9: Kennzahl Vorhersage Luftfeuchtigkeit



ID: B003 

Bezeichnung: Vorhersage Wellenhöhe 


Beschreibung: 




Berechnung: 






Hohe Wellenhöhe kann destruktiv für die Anlagen 

sein. Die Wellenhöhe ist der Faktor, ob eine 

Anlage per Hubschrauber, Schiff, oder überhaupt 

erreicht werden kann. Schlechte Wetterbedingungen 

beeinflussen stark die Wartungsarbeit. 

In Meter (M) 

Bei hohen Wellenhöhe muss die Anlage herunter 

gefahren werden. 




Tabelle A.10: Kennzahl Vorhersage Wellenhöhe 

ID: B004 

Bezeichnung: Vorhersage Temperatur 


Beschreibung: 




Berechnung: 







sind Indizien für die Möglichkeit 

des Einfrierens der Rotorblätter 


Temperatur [C°] 

Bei eingefrorenen Rotorblättern muss die Anlage 

herunter gefahren werden. 


393






Tabelle A.11: Kennzahl Vorhersage Temperatur 

ID: B005 

Bezeichnung: Vorhersage Luftdruck 


Beschreibung: 




Berechnung: 






Ein hoher Luftdruck ist ein Indiz für ein guten 

Leistungsertrag 


Luftdruck [Bar] 




Tabelle A.12: Kennzahl Vorhersage Luftdruck 

ID: B006 

Bezeichnung: Vorhersage Niederschlag 


Beschreibung: 



Vorhersage Niederschlag 


Berechnung: 







Niederschlag 


394




ID: B007 


Tabelle A.13: Kennzahl Vorhersage Niederschlag 

Bezeichnung: Vorhersage Windrichtung 


Beschreibung: 



Vorhersage Windrichtung 


Berechnung: 







Richtung [N, O, S, W] 

Frühzeitiges in den Wind drehen 



ID: B008 



Tabelle A.14: Kennzahl Vorhersage Windrichtung 

Bezeichnung: Vorhersage Wahrscheinlichkeit 


Beschreibung: 




Berechnung: 






Vorhersage Wahrscheinlichkeit 


Prozent [%] 




Tabelle A.15: Kennzahl Vorhersage Wahrscheinlichkeit 

395



Gruppe – Anlagendaten (C) 

ID: C001 Bezeichnung: Hersteller 


Beschreibung: 

Name des Herstellers 


Exemplarische Analysefragen: Wer ist der Hersteller? 

Berechnung Datenquellen: Hersteller 

Berechnung: - 






Sonstiges Verantwortlichkeiten: Hersteller 



Tabelle A.16: Kennzahl Hersteller 

ID: C002 

Bezeichnung: Nabenhöhe 


Beschreibung: 




Berechnung: 








Höhe der Nabe und somit auch Höhe der gesamten 

Anlage 

in Meter 



Tabelle A.17: Kennzahl Nabenhöhe 

396



ID: C003 Bezeichnung: Rotorblattlänge 


Beschreibung: 

Länge der Rotorblätter 




Berechnung: 

in Meter 









Tabelle A.18: Kennzahl Rotorblattlänge 

ID: C004 

Bezeichnung: Anzahl Rotorblätter 


Beschreibung: 




Berechnung: - 









Anzahl der Rotorblätter 

Tabelle A.19: Kennzahl Anzahl Rotorblätter 

Darstellung als Wert, graphische Visualisierung 

der Anlage 

397



ID: C005 

Bezeichnung: Einschaltgeschwindigkeit 


Beschreibung: 



Zu geringe Windgeschwindigkeiten reichen 

nicht aus, um die Rotorblätter zu drehen. Die 

Einschaltgeschwindigkeit stellt die Windgeschwindigkeit 

dar, ab dieser eine WEA gestartet 

werden kann. Dieser Wert ist vom Anlagentyp 

abhängig. 

Berechnung Datenquellen: Vorgabe vom Hersteller, Parametrisierung 

durch Betriebsführer 

Berechnung: 






In M/S (Meter per Sekunde) 


Sonstiges Verantwortlichkeiten: Betriebsführer 



Tabelle A.20: Kennzahl Einschaltgeschwindigkeit 

Je nach Anlagentyp zwischen 2 und 8 m/s 

ID: C006 

Bezeichnung: Abschaltgeschwindigkeit 


Beschreibung: 



Bei sehr großen Windgeschwindigkeiten 

muss die WEA zur Schadenvermeidung 

abgeschaltet werden. Die Abschaltwindgeschwindigkeit 

stellt die Windgeschwindigkeit 

dar, ab dieser eine WEA heruntergefahren 

werden muss. Dieser Wert ist vom Anlagentyp 

abhängig. 

Berechnung Datenquellen: Vorgabe vom Hersteller, Parametrisierung 

durch Betriebsführer 

Berechnung: 



In m/s (Meter per Sekunde) 

398









Je nach Anlagentyp zwischen 25 und 35 m/s 


Tabelle A.21: Kennzahl Abschaltgeschwindigkeit 

ID: C007 

Bezeichnung: Leistung 


Beschreibung: 




Berechnung: 








Maximale Leistung, die von der Anlage in 

Volllast produziert werden kann 

In MW (Megawatt) 




Tabelle A.22: Kennzahl Leistung 

399



Gruppe – Sensordaten (D) 

ID: D001 

Bezeichnung: Windgeschwindigkeit 


Beschreibung: 



An der WEA vorherrschende Windgeschwindigkeit. 

Bei Überschreiten der Einschaltwindgeschwindigkeit 

startet die WEA. Bei Überschreiten 

der Abschaltwindgeschwindigkeit 

wird die WEA heruntergefahren. 

Berechnung Datenquellen: Betriebswindmesssystem an der Gondel 

Berechnung: 

Aktualität: 





Windgeschwindigkeitsmessung (m/s) 

10-min, Stunde, Tag 





Tabelle A.23: Kennzahl Windgeschwindigkeit 

ID: D002 Bezeichnung: Betriebsstatus 


Beschreibung: 

Betriebsstatus einer Windanlage 



Berechnung Datenquellen: Betriebssystem 

Berechnung: 

Nummerische Zahl 









Tabelle A.24: Kennzahl Betriebsstatus 

400



ID: D003 Bezeichnung: Leistungsabgabe 


Beschreibung: 

Leistung des erzeugten Stroms 



Berechnung Datenquellen: Strommessung an der Turbine 

Berechnung: 

Messung der Stromspannung (W) 

Aktualität: 



Inspektion und Wartung 







Maximaler Wert des Anlagentyps 


Tabelle A.25: Kennzahl Leistungsabgabe 

ID: D004 

Bezeichnung: Windrichtung 


Beschreibung: 



Richtung, aus der der Wind weht. Im Betrieb 

wird die WEA dem Wind hinterher gedreht. Je 

höher die Windgeschwindigkeit, desto höher 

die Drehgeschwindigkeit. 


Berechnung: 

Aktualität: 





Windrichtungsmessung 






Beeinflusst den Gierwinkel 

Tabelle A.26: Kennzahl Windrichtung 

401



ID: D005 

Bezeichnung: Blatteinstellwinkel 


Beschreibung: 



Berechnung Datenquellen: Messung 

Berechnung: 






Blatteinstellwinkel für jedes Rotorblatt 

Messung des Blatteinstellwinkels an der Blattaufhängung 

in der Nabe 

Inspektion und Wartung Blattverstellmechanismus 





Tabelle A.27: Kennzahl Blatteinstellwinkel 

ID: D006 Bezeichnung: Außentemperatur 


Beschreibung: 

Temperatur an der WEA 




Berechnung: 

Temperaturmessung (C°) 

Aktualität: 









Indiz für das Einfrieren der Rotorblätter 


Tabelle A.28: Kennzahl Außentemperatur 

402



ID: D007 

Bezeichnung: Luftdichte 


Beschreibung: 




Berechnung: 

Aktualität: 





Eine hohe Luftdichte ist ein Indiz für ein guten 

Leistungsertrag 

Luftmessung (kg/m³) 






Tabelle A.29: Kennzahl Luftdichte 

ID: D008 

Bezeichnung: Luftfeuchtigkeit 


Beschreibung: 




sind Indizen für die Möglichkeit 

des Einfrierens der Rotorblätter. 


Berechnung: Luftmessung (%) 

Aktualität: 










Tabelle A.30: Kennzahl Luftfeuchtigkeit 

403



ID: D009 

Bezeichnung: Ölstand-Turbine 


Beschreibung: 



Stand des Schmiermittels in der Turbine 

Berechnung Datenquellen: Messsystem an der Turbine 

Berechnung: 

Aktualität: 





Ölstandmessung (Liter) 

10-min-Durchschnitt, Stunde, Tag 

Ölwechsel 





Tabelle A.31: Kennzahl Ölstand-Turbine 

Ziel-, Soll- und Toleranz-Werte: Je nach Anlagentyp 

ID: D010 

404 

Bezeichnung: Öldruck-Turbine 


Beschreibung: 



Druck des Schmieröls in der Turbine 


Berechnung: 

Aktualität: 





Druckmessung (bar / kPa) 

10-min-Durchschnitt 

Ölwechsel 





Tabelle A.32: Kennzahl Öldruck-Turbine 

Ziel-, Soll- und Toleranz-Werte: Je nach Anlagentyp



ID: D011 

Bezeichnung: Öltemperatur-Turbine 


Beschreibung: 



Temperatur des Schmiermittels in der Turbine 


Berechnung: 

Aktualität: 







Ölwechsel 





Tabelle A.33: Kennzahl Öltemperatur-Turbine 


ID: D012 

Bezeichnung: Spannung-Turbine 


Beschreibung: 



Stromspannung des erzeugten Stroms 


Berechnung: 

Aktualität: 





Messung der Stromspannung (V) 







Tabelle A.34: Kennzahl Spannung-Turbine 

Toleranz-Werte: Maximaler Wert des Anlagentyps 

405



ID: D013 

Bezeichnung: Stromstärke-Turbine 


Beschreibung: 



Stromstärke des erzeugten Stroms 


Berechnung: 

Aktualität: 





Messung der Stromstärke (A) 







Tabelle A.35: Kennzahl Stromstärke-Turbine 

Toleranz-Werte: Maximaler Wert des Anlagentyps 

ID: D014 

406 

Bezeichnung: Frequenz-Turbine 


Beschreibung: 



Frequenz des erzeugten Stroms an der Turbine 

in der WEA 


Berechnung: 

Aktualität: 





Messung der Frequenz (Hz) 







Tabelle A.36: Kennzahl Frequenz-Turbine 

Ziel-, Soll-Werte: Netzvorgabeparameter Frequenz



ID: D015 

Bezeichnung: Ölstand-Generator 


Beschreibung: 



Stand des Schmiermittels im Generator 

Berechnung Datenquellen: Messsystem am Generator 

Berechnung: 

Aktualität: 







Ölwechsel 





Tabelle A.37: Kennzahl Ölstand-Generator 


ID: D016 

Bezeichnung: Öldruck-Generator 


Beschreibung: 



Druck des Schmieröls im Generator 


Berechnung: 

Aktualität: 







Ölwechsel 





Tabelle A.38: Kennzahl Öldruck-Generator 


407



ID: D017 

Bezeichnung: Öltemperatur-Generator 


Beschreibung: 



Temperatur des Schmiermittels im Generator 


Berechnung: 

Aktualität: 







Ölwechsel 





Tabelle A.39: Kennzahl Öltemperatur-Generator 


ID: D018 

408 

Bezeichnung: Drehzahl-Generator 


Beschreibung: 




Berechnung: 

Aktualität: 





Drehzahl des Generators 

Messung der Drehbewegung der Generatorachse 

(rpm/h) 


Wartungs- bzw. Instandsetzungsmaßnahme 





Tabelle A.40: Kennzahl Drehzahl-Generator 

Ziel-, Soll- und Toleranz-Werte: Je nach 

Anlagentyp



ID: D019 

Bezeichnung: Ölstand-Getriebe 


Beschreibung: 



Stand des Schmiermittels im Getriebe 

Berechnung Datenquellen: Messsystem am Getriebe 

Berechnung: 

Aktualität: 







Ölwechsel 





Tabelle A.41: Kennzahl Ölstand-Getriebe 


ID: D020 

Bezeichnung: Öldruck-Getriebe 


Beschreibung: 



Druck des Schmieröls im Getriebe 

Berechnung Datenquellen: Messsystem am Getriebe 

Berechnung: 

Aktualität: 







Ölwechsel 





Tabelle A.42: Kennzahl Öldruck-Getriebe 


409



ID: D021 

Bezeichnung: Öltemperatur-Getriebe 


Beschreibung: 



Temperatur des Schmiermittels im Getriebe 


Berechnung: 

Aktualität: 







Ölwechsel 





Tabelle A.43: Kennzahl Öltemperatur-Getriebe 


410


Smart Wind Farm Control – DV-Konzept 




DV-Konzept 

411



412



Inhaltsverzeichnis DV-Konzept Smart Wind Farm Control 




Versionshistorie ...................................................................................................................... 416 

1 Gesamtüberblick ............................................................................................................. 417 

2 Ist-Zustand ...................................................................................................................... 419 

2.1 Datenmanagement ...................................................................................................... 419 

2.2 Software ...................................................................................................................... 420 

2.3 Architektur .................................................................................................................. 420 

3 Soll-Zustand .................................................................................................................... 422 

3.1 Software ...................................................................................................................... 422 

3.1.1 SAP HANA ..................................................................................................... 422 

3.1.2 Pentaho Data Integration ................................................................................. 423 

3.1.3 R....................................................................................................................... 424 

3.1.4 Microsoft Excel ............................................................................................... 424 

3.1.5 SAP BusinessObjects ...................................................................................... 425 

3.1.6 Smart Wind Farm Control Toolbox................................................................. 425 

3.2 Datenmodell ............................................................................................................... 426 

3.3 Architektur .................................................................................................................. 426 

3.4 Technische Voraussetzungen ..................................................................................... 428 

3.4.1 Software und Hardware ................................................................................... 428 

3.4.2 Daten ................................................................................................................ 428 

4 Realisierung .................................................................................................................... 430 

4.1 Analyse und Übernahme des Windpark-Datenmodells ............................................. 430 

4.1.1 Datenmodell..................................................................................................... 430 

4.1.2 ETL-Prozess .................................................................................................... 432 

4.2 Simulation eines Windparks ....................................................................................... 435 

4.3 Analyse und Reporting ............................................................................................... 439 

4.3.1 Data Mining mit R ........................................................................................... 439 

4.3.2 Analysen und Reporting – Microsoft Excel .................................................... 442 

4.3.3 Analysen und Reporting – SAP UI5................................................................ 443 

5 Ansprechpartner .............................................................................................................. 446 

5.1 Fachliche Ansprechpartner ......................................................................................... 446 

5.2 Technische Ansprechpartner ...................................................................................... 447 

6 Literaturverzeichnis ........................................................................................................ 448 

Anhang ................................................................................................................................... 450 

A. Datenmodell .................................................................................................................... 450 

413




Abbildung 2.1: Datenfluss im Windparkmanagement ........................................................... 421 

Abbildung 3.1: Geplante Architektur des Smart Wind Farm Control Projekts ..................... 427 

Abbildung 4.1: Logisches Datenmodell ................................................................................. 431 

Abbildung 4.2: Phasen des ETL-Prozesses in Pentaho Data Integration CE ......................... 433 

Abbildung 4.3: SWF Toolbox Klassenübersicht .................................................................... 436 

Abbildung 4.4: SWF Toolbox Übersicht ............................................................................... 437 

Abbildung 4.5: SWF Toolbox Generator ............................................................................... 438 

Abbildung 4.6: SWF Toolbox Streamer ................................................................................ 438 

Abbildung 4.7: Zwei Ansätze für die Integration von R und HANA .................................... 439 

Abbildung 4.8: Hauptkomponenten des Inside Out Ansatzes ................................................ 441 

Abbildung 4.9: Mockup SAP UI5 - Startseite ........................................................................ 443 

Abbildung 4.10: Mockup SAP UI5 - Monitor ....................................................................... 444 

Abbildung 4.11: Mockup SAP UI5 - Log .............................................................................. 444 

Abbildung 4.12: Mockup SAP UI5 - Reporting .................................................................... 445 

Abbildung A.1: Datenmodell ................................................................................................. 450 


Tabelle 4.1: Pentaho Data Integration CE Funktionen .......................................................... 434 

Tabelle 5.1: Fachliche Ansprechpartner ................................................................................. 446 

Tabelle 5.2: Technische Ansprechpartner .............................................................................. 447 

414




AG 

BI 

BO 

CE 

CPU 

CSV 

DLR 

DNS 

EE 

ETL 

GB 

GmbH 

GPL 

HANA 

HPI 

HTML 

IP 

JDBC 

JSON 

KW 

MS 

ODBC 

OLAP 

RAM 

SQL 

SWF 

SWT 

TCP 

UI 

UMTS 

VLBA 

VPN 

WEA 

WEC 

WIS 

XML 

Aktiengesellschaft 


BusinessObjects 

Community Edition 

Central Processing Unit 

Comma-separated values 

Deutsche Luft- und Raumfahrt 

Domain Name System 

Enterprise Edition 


Gigabyte 

Gesellschaft mit beschränkter Haftung 

General Public License 


Hasso-Plattner-Institut 

Hypertext Markup Language 

Internetprotokoll 

Java Database Connector 

JavaScript Object Notation 

Kilowatt 

Microsoft 

Open Database Connectivity 

Online Analytical Processing 

Random-Access Memory 



Standard Widget Toolkit 

Transmission Control Protocol 

User Interface 

Universal Mobile Telecommunications System 


Virtual Private Network 


Wind Energy Conversion 

Windenergie-Informations-System 


415



Versionshistorie 

Datum Änderungsgrund Geänderte Kapitel 

15.12.2012 Das neue Strategiepaper wurde integriert, Ziel ist ab sofort 

eine Plattform. 

28.01.2013 Nach Gesprächen mit SAP und HPI wurde das Wissen über 

Datendefekte mit aufgenommen. 

04.02.2013 Nach Gesprächen mit der Availon GmbH wurde der Fokus 

von den Sekundendaten auf das Data Mining verschoben. 

Zudem wurden neue technische Lösungen eingefügt. Insbesondere 

wurde SAP HANA SPS 05 veröffentlicht und 

damit die Nutzung der SAP UI5 Funktionalität ermöglicht. 

1, 3.1 

5.1 

2.1, 2.2, 2.3, 3.1.1, 3.3, 

3.4.2, 4.1.1, 4.3, 4.3.3, 

5.1 

Da sich das Projektziel der Teilgruppe Smart Wind Farm Control zwei Mal wesentlich geändert hat 

(siehe Dokumentation, Kapitel 1.1), wurden diese Änderungen nachträglich in das Datenverarbeitungskonzept 

aufgenommen. Hierbei wurde das bestehende Konzept ergänzt bzw. geändert, es wurden 

keine vorhandenen Kapitel entfernt. Die Änderungen werden an den entsprechenden Stellen im Text 

kenntlich gemacht. 

416



1 Gesamtüberblick 

Die Vorkommen an fossilen Energieträgern sind begrenzt und die Gewinnung der verbleibenden Rohstoffe 

wird immer teurer. Um den Energiebedarf auch langfristig decken zu können, wird Energie aus 

regenerativen Quellen benötigt. In Deutschland nimmt die Windenergie hierfür eine zentrale Rolle ein. 

Diese Energie wird mit Hilfe von Windenergieanlagen (WEA) gewonnen, welche in der Regel in 

Windparks von mindestens drei Anlagen positioniert sind. Hierbei wird zwischen Windparks, welche 

auf dem Binnenland (Onshore) stehen und Windparks, welche auf der offenen See (Offshore) platziert 

sind, unterschieden. Insbesondere Offshore Windparks besitzen ein hohes Zukunftspotenzial, aufgrund 

der großen verfügbaren Fläche und dem erhöhten Windvorkommen auf See. Die Entwicklung und 

Forschung in diesem Bereich befindet sich noch in der Anfangsphase und wird stetig vorangetrieben. 

Ein zentraler Forschungsschwerpunkt liegt in der Reduzierung der Wartungskosten für Offshore 

Windparks. Im Vergleich zu Onshore Windparks sind diese signifikant höher, was unter anderem auf 

logistische Herausforderungen, erhöhte technische Belastungen und Abhängigkeiten vom Wetter zurück 

zu führen ist. 

Änderung 15.12.12: Im Rahmen des Projekts Smart Wind Farm Control (SWF) wird die Problematik 

des erhöhten Wartungsaufwandes im Offshore-Bereich als Rahmenbedingung für die Entwicklung 

einer Windpark-Maintenance-Plattform herangezogen. Als zentraler Ausgangspunkt dient das vom 

Hasso-Plattner-Institut (HPI) bereitgestellte In-Memory Datenbanksystem SAP HANA (High Performance 

Analytic Appliance), an welchem sich alle weiteren Schritte orientieren. In-Memory Datenbanksysteme 

nutzen im Gegensatz zu traditionellen Datenbanksystemen den Arbeitsspeicher als Datenspeicher, 

was zu einem erheblichen Performancegewinn führt. Diese Technologie eröffnet somit 

neue Lösungswege bzw. Ansätze, die es zu ermitteln gilt. Weiterhin sollen neue wissenschaftliche 

Erkenntnisse aus verschiedenen Bereichen der Windenergie in die Entwicklung einfließen. Die daraus 

resultierenden Lösungswege sollen aufgezeigt und abgewägt werden. Übergreifend soll somit eine 

grundlegende Plattform geschaffen werden, um den benötigten Funktionsumfang in verschiedenen 

Szenarien bestmöglich abzubilden. Die Aufgabenbereiche erstrecken sich dabei über die folgenden 

drei Felder: Proaktive Maintenance-Plattform, Exakte Vorhersagen für Wartungsfenster im Offshore 

Betrieb sowie Schnelle Datenauswertung für wissenschaftliche Analysen. 

Proaktive Maintenance-Plattform 

Die Proaktive Maintenance-Plattform dient zur Erfassung aller relevanten physikalischen Daten des 

Offshore Windparks. Zusätzlich soll das System eine automatische Fehlererkennung 

und -klassifizierung der Daten bereitstellen. Darauf aufbauend sollen mit Hilfe von Data Mining Methoden, 

wie beispielsweise Regressionsanalysen, Muster in den Daten erkannt werden, welche für 

verschiedene Anwendungsszenarien genutzt werden können. 

417



Exakte Vorhersagen für Wartungsfenster im Offshore Betrieb 

Im Rahmen der Instandhaltung bzw. Wartung von Offshore WEA gilt es, auf Basis der gesammelten 

Echtzeitdaten Prognosen über die Lebenserwartungen und evtl. Anlagenausfälle automatisch zu generieren. 

Diese Prognosen sind Ergebnisse aus verschiedensten Algorithmen, welche sowohl auf wissenschaftlichen 

Erkenntnissen als auch Data Mining Methoden basieren. Zusätzlich werden Sekundärdaten 

hinzugezogen, um die Genauigkeit dieser Prognosen zu erhöhen und mögliche Warnungen frühzeitig 

auszulösen. Zu den Sekundärdaten zählen unter anderem Wetterdaten, Ressourcendaten, Betriebsdaten 

sowie Wartungshistorien. 

Schnelle Datenauswertung für wissenschaftliche Analysen 

Im Zuge von neuen Datenbanktechnologien (In-Memory Datenbanken) können komplexere Datenanalysen 

auf einem größeren Datenbestand ausgeführt werden. Die Datenerfassung erfolgt als Datenstrom 

und soll alle Parameter pro Sekunde und Anlage erfassen. Den Einsatz von möglichen Mittelwerten 

gilt es zu vermeiden. Insbesondere die Möglichkeit, Analysen auf diesen nicht aggregierten Daten 

durchzuführen, stellt einen großen Vorteil gegenüber bisherigen Lösungen dar. Des Weiteren verkürzen 

sich die Antwort- bzw. Berechnungszeiten signifikant. Übergreifend führt dies zu einer Verbesserung 

und Beschleunigung der Arbeitsabläufe im Forschungsumfeld und ermöglicht neue Lösungswege 

speziell bei der Entwicklung von komplexen Algorithmen und Diagrammen. Als Voraussetzung dient 

die Bereitstellung von Datenschnittstellen für verschiedenste Programme im Forschungsumfeld seitens 

der Proaktiven Maintenance-Plattform. 

418



2 Ist-Zustand 

In diesem Kapitel werden die technischen Gegebenheiten des Projekts SWF aufgeführt. Nachdem 

bereits in Kapitel 1 ein theoretischer Überblick über die Problematik des erhöhten Wartungsaufwandes 

im Offshore-Bereich erfolgte, gilt es nun, dessen technische Rahmenbedingungen zu erläutern. Im 

Fokus liegen insbesondere das Datenmanagement, die eingesetzte Software sowie die technischen 

Eigenheiten bzw. Einschränkungen der einzelnen Typen von WEA. 

Das Projekt konnte auf keine vorhandenen Forschungsergebnisse oder Strukturen seitens der Very 

Large Business Applications (VLBA) zugreifen, da diese Thematik dort erstmalig behandelt wird. 

Daher wurden zunächst im Zuge zahlreicher Gespräche mit Projektpartnern Vorwissen aufzubauen 

und die unterschiedlichen Ansätze zu einer gemeinsamen Ausgangsbasis zu vereinen. 

2.1 Datenmanagement 

Das Datenmanagement von WEA besitzt branchenbezogene Eigenheiten, die es von einem normalen 

Business Intelligence (BI) Projekt unterscheidet. Diese sollen im Folgenden näher erläutert werden. 

Neben der generellen Datenverfügbarkeit und -beschaffenheit soll die momentan erfolgende Datenübertragung 

bzw. Datenerfassung seitens der Windparkbetreiber und Forschungseinrichtungen beschrieben 

werden. 

In Gesprächen mit ForWind, dem gemeinsamen Zentrum für Windenergieforschung der Universitäten 

Oldenburg, Hannover und Bremen, wurden insbesondere die Bereiche Datenverfügbarkeit und 

-beschaffenheit erörtert (siehe Dokumentation, Kapitel 1.1). WEA sind in der Lage, im Sekundenrhythmus 

Werte zu erfassen und auf diese zu reagieren. Jedes Windrad besitzt bis zu 200 Sensoren, 

welche kontinuierlich Messdaten erfassen. Diese Daten liegen ForWind aus Gründen der Datenhaltung 

in einem aggregierten Umfang in Form von 10-Minuten-Mittelwerten vor. Ferner ist die Beschaffung 

und Weitergabe dieser firmeninternen Daten problematisch, da eine Partnerschaft bzw. Agreement mit 

einem Anlagenbetreiber benötigt wird. Andererseits haben die Anlagenbetreiber aus Imagegründen 

generell keinerlei Interesse, Daten für Forschungszwecke bereitzustellen. Dies ist darin begründet, 

dass hierbei Schwachstellen in den Anlagen aufgedeckt werden könnten und dies die Kunden negativ 

beeinflussen könnte. Insbesondere die Verfügbarkeit von Daten im Offshore Bereich ist aktuell nicht 

gegeben. Es besteht jedoch die Möglichkeit, dass ForWind aus einem Forschungsprojekt mit der Deutschewindtechnik 

AG Bremen der Teilgruppe Testdaten in Form von Sekundendaten für einen Onshore 

Windpark zur Verfügung zu stellen. 

Änderung 04.02.2013: Bei Gesprächen mit der Availon GmbH, einem Serviceanbieter für WEA, 

konnten neben den bisherigen Erkenntnissen neue Einsichten im Bereich der Datenübertragung 

und -erfassung erlangt werden (siehe Dokumentation Kapitel 1.1). Dabei hat sich herausgestellt, dass 

419



die Art der Datenübertragung von einer WEA zum Anlagenbetreiber bzw. Wartungsdienstleister stark 

vom Alter der Anlagen abhängt. 

Während die älteren Modelle über eine Modem-Verbindung verfügen, welche einen geringfügig umfangreichen 

Datenausgleich ermöglicht, sind die neuen Anlagen mit einer Breitband- oder UMTS- 

Anbindung somit einer schnelleren Datenübertragung ausgestattet. Obwohl viele neue Anlagen mit der 

schnelleren Datenanbindung ausgestattet sind, werden bei allen Verbindungsarten die Daten auf Seite 

der WEA zu 10 Minuten Mittelwerten aggregiert und anschließend versendet. Die Daten werden somit 

bereits bei der Datenquelle aggregiert und nicht, wie sonst üblich, innerhalb des Data Warehouse. Zu 

Testzwecken können laut Availon GmbH auch Sekundendaten abgerufen werden, in diesem Fall muss 

ein Laptop und ggf. eine neue Steuereinheit direkt an das WEA angeschlossen werden. Aufgrund von 

Repowering kann davon ausgegangen werden, dass in Zukunft schnellere Datenverbindungen zur 

Verfügung stehen werden und somit Sekundendaten statt aggregierten Werten übertragen werden 

können. Vor allem im Offshore Bereich wäre dies bereits jetzt möglich. 

2.2 Software 

Nachfolgend soll die eingesetzte Software für die Datenhaltung und -analyse im Bereich Windenergie 

aufgeführt werden. Wie bei der Datenbeschaffung ist es sehr schwierig, Informationen über die eingesetzte 

Software der Windparkdienstleister, -betreiber und -hersteller zu erhalten. Im Folgenden werden 

die aus den Gesprächen hervorgegangen Softwarelösungen aufgeführt. 

Bei ForWind erfolgt die Datenhaltung in Dateiform, es wird keine Datenbank verwendet. Hinsichtlich 

der Datenanalyse wird R als Statistik-Tool verwendet, um die Daten zu beschreiben, auszuwerten und 

zu visualisieren. Ergänzend werden selbstentwickelte Algorithmen für die Datenanalyse eingesetzt. 

Änderung 04.02.2013: Die Availon GmbH nutzt die Software Windenergie-Informations-System 

(WIS) von softEnergy. Diese umfasst die Kommunikation bzw. Datenbeschaffung, Auswertung, 

Überwachung und Verwaltung der WEA Daten. In Bezug auf die Datenanalyse konnte am Beispiel 

der Availon GmbH festgestellt werden, dass insbesondere einfache, statische Analysen durchgeführt 

werden. Weiterführende Analysen und insbesondere Data Mining erfolgen bisher nicht, könnten laut 

Herrn Kleesch von der Availon GmbH aber zu wesentlichen Vorteilen führen. Der Teilgruppe liegen 

keine Informationen über die Analysetiefe seitens der Windparkhersteller vor. 


Die grundlegende Architektur des Datenflusses im Rahmen des Windparkmanagements inklusive aller 

beteiligten Komponenten wird in Abbildung 2.1 dargestellt. Diese orientiert sich an den in Kapitel 2.1 

und 2.2 beschriebenen Erkenntnissen und dient als abschließende Gesamtübersicht. 

420



Abbildung 2.1: Datenfluss im Windparkmanagement 

Wie in Abbildung 2.1 dargestellt, enthalten die WEA je nach Anlagentyp bis zu 200 Sensoren, im 

Falle von Forschungs-WEA sogar bis zu 400 Sensoren. Innerhalb der WEA werden die Sensoren sekündlich 

erfasst und ausgewertet. Auf diese Weise kann die WEA direkt auf Umwelteinflüsse, wie 

beispielsweise Windböen, reagieren. 

Änderung 04.02.2013: Die Sekundendaten werden auf Seiten der WEA zu 10 Minuten Mittelwerten 

aggregiert und versendet. Die Geschwindigkeit der Datenübertragung hängt wesentlich vom Alter der 

WEA und somit der eingebauten Übertragungsart ab. Anschließend werden die Daten lokal in der 

Wartungsfirma bereinigt, gespeichert und ausgewertet. 

421



3 Soll-Zustand 

In diesem Kapitel sollen die Zielzustände des Projekts SWF beschrieben werden. Neben den Voraussetzungen 

des Projekts soll die einzusetzende Software, das Datenmodell und die Architektur beschrieben 

werden. Die genaue Umsetzung dieser Zielzustände folgt in Kapitel 4. 

3.1 Software 

Änderung 15.12.2012: Für die Umsetzung einer Plattform werden verschiedene Programme für die 

einzelnen Bauteile der Plattform benötigt. Im Folgenden soll die eingesetzte Software kurz erörtert 

werden. Zudem soll angegeben werden, für welchen Bereich der Plattform die Software eingesetzt 

wird und warum sie für diesen Zweck ausgewählt wurde. 

3.1.1 SAP HANA 

Für die Durchführung des Projekts wurde der Teilgruppe durch das HPI das In-Memory Datenbanksystem 

SAP HANA der SAP AG zur Verfügung gestellt. Ein Überblick über die Bestandteile und 

Funktionen des HANA Systems lässt sich durch die Aufschlüsselung des Namens erreichen. So wird 

die High Performance (hohe Leistung) durch die Verwendung von vielen CPUs und dem Arbeitsspeicher 

als hauptsächlichem Speicherort für die Daten erreicht. Hierfür werden verschiedene Verfahren 

wie beispielsweise spaltenorientierte Datenhaltung, Partitionierung und verschiedene Kompressionsverfahren 

verwendet. SAP HANA wird von SAP als linear skalierende Datenbank beworben. Dies 

bedeutet, dass durch den Verbund mehrerer physikalischer Server zu einer logischen Datenbank eine 

lineare Steigerung der Leistungsfähigkeit pro hinzugefügten physikalischen Server erreicht werden 

soll. 

Analytic (analytisch) deutet bereits die Fokussierung auf den BI Bereich an. Das System ermöglicht 

die Ausführung komplexer Anfragen mit besonders kurzen Antwortzeiten. Diese komplexen Anfragen 

müssen weder auf aggregierten bzw. summierten Daten ausgeführt werden, noch müssen vordefinierte 

Abfragen ausgeführt werden. Stattdessen können freie Abfragen auf den ursprünglichen Daten durchgeführt 

werden. Um Prozeduren auszuführen, verwendet HANA die Sprache SQLScript. Dabei handelt 

es sich um eine Abwandlung der SQL Stored Procedures, die um einige Funktionen erweitert 

wurden, damit sie leistungsfähiger und flexibler sind (Word 2012, S. 17,45). 

Appliance bezieht sich auf die Partnerschaft, die SAP im Jahre 2011 mit einigen Hardware- 

Lieferanten, unter anderem HP, Dell, IBM und Fujitsu eingegangen ist. Zurzeit sind sieben Hardwarelieferanten 

in dieser Partnerschaft mit SAP. Indem die Software des SAP HANA Systems nur auf festgelegter 

Hardware ausgewählter Anbieter ausgeführt wird, soll ein besonders stabil funktionierendes 

System erreicht werden (Word 2012, S. 97-103). 

422



Da bei der proaktiven Instandhaltung die verbleibende Lebensdauer der verschiedenen Komponenten 

von essentieller Bedeutung ist, muss diese bestimmt werden. Die Analysen hierzu werden derzeit auf 

aggregierten Daten ausgeführt, wodurch eine genaue Bestimmung des Verschleißes nicht möglich ist. 

Bei der Verwendung von Sekundendaten anstelle der 10 Minuten Mittelwerte muss das 600-fache 

Datenvolumen gespeichert werden. Um diese Datenmenge in einer akzeptablen Zeit berechnen zu 

können, wird eine In-Memory Datenbank wie SAP HANA benötigt. Neben der wesentlich höheren 

Geschwindigkeit ist die Simplizität ein weiterer Vorteil von SAP HANA, denn hierbei kann auf das 

Erstellen von Online Analytical Processing (OLAP)-Würfeln verzichtet werden und somit die Komplexität 

für den Entwickler reduziert werden. Zudem können die Fachanwender ihre Analysen direkt 

ausführen und die Ergebnisse auswerten ohne die erwähnten OLAP-Würfel erstellen bzw. anpassen zu 

müssen. 

Zur Administration von SAP HANA und Entwicklung von SAP HANA Anwendungen, wird die 

Software SAP HANA Studio verwendet. Die Software basiert auf der Eclipse-Umgebung, ist durch 

Plug-Ins erweiterbar und bietet drei verschiedene Sichten. Dazu zählt eine Administrations-Konsole, 

mit der die Funktionen der Datenbank überwacht bzw. kontrolliert und konfiguriert werden können. 

Zudem können hiermit Backups erstellt bzw. wiederhergestellt werden. Die zweite Sicht ist der information 

modeler. Dieser wird benötigt, um Datenmodelle und Views zu erstellen bzw. bestehende zu 

verändern. Die dritte Sicht das lifecycle management mittels welcher eine aktualisieren der Software 

möglich ist (Word 2012, S. 48). 

Änderung 04.02.13: Seit einem Update des SAP HANA Systems auf Version SPS05 besteht die Möglichkeit, 

das User Interface Development Toolkit für HTML (Hypertext Markup Language) 5 (SAP 

UI5) innerhalb des SAP HANA Studio zu nutzen. SAP UI5 ist eine Client-seitige HTML5-Rendering- 

Bibliothek welche die Entwicklung von JavaScript-basierten Weboberflächen in Verbindung mit SAP 

HANA ermöglicht. Dabei werden unteranderem Technologien bzw. Standards wie jQuery, OpenAjax, 

XML und Cascading Style Sheets 3 unterstützt (SAP AG – HANA 2012). 

3.1.2 Pentaho Data Integration 

Pentaho Data Integration, auch bekannt unter dem Namen Kettle, ist eine grafische Anwendung zur 

Unterstützung des ETL (Extract, Transform, Load)-Prozesses von Daten. Pentaho Data Integration ist 

sowohl als kostenfreie Community Edition (CE) als auch als kostenpflichte Enterprise Edition (EE) 

verfügbar, welche zusätzlich technischen Support, verwaltete Aktualisierungen und Enterprise Funktionen 

bereitstellt. Die Anwendung basiert auf Java, ist modular aufgebaut und kann bei Bedarf leicht 

erweitert werden. Grundlegend erfolgt die Erstellung der Prozesskette über eine Art Baukastenprinzip, 

indem der Anwender auf eine bestehende ETL Modulbibliothek zurückgreifen kann und anschließend 

diese Module auf einer grafischen Arbeitsfläche per Drag & Drop frei ablegen, konfigurieren und 

verknüpfen kann. Das Tool ermöglicht somit einen hohen Grad an individuellen Modellierungsmög- 

423



lichkeiten des Datenstroms, welche zusätzlich per Jobs automatisiert werden können. Weiterhin stehen 

zahlreiche Monitoring und Logging Funktionalitäten für die Identifizierung von Fehler bereit (Pentaho 

Corporation 2012). 

Im Zuge des Projektes SWF wird die Open Source CE Version zum Einsatz kommen, welche kostenlos 

durch die Pentaho Community bereitgestellt wird. Diese wird benötigt, um bestehende Windparkdaten 

zu erfassen, zu bereinigen, ggf. zu ergänzen und an das neue Datenmodell anzupassen bzw. zu 

transformieren. Dabei waren einerseits die freie Verfügbarkeit, die Verbreitung im universitären Bereich 

und anderseits die umfangreiche Dokumentation und der große Funktionsumfang ausschlaggebend 

für die Entscheidung für Pentaho. 

3.1.3 R 

R ist eine Open Source Programmiersprache und Softwareumgebung für statistisches Rechnen und 

Grafiken. Die Softwareumgebung ist Teil des GNU’s Not Unix (GNU) Projekts und auf vielen Plattformen 

(UNIX, Windows, MacOS) verfügbar (Wirtschaftsuniversität Wien 2012). Der Funktionsumfang 

von R kann durch eine Vielzahl von Paketen erweitert und an spezifische statistische Problemstellungen 

angepasst werden. Viele Pakete können direkt aus einer über die R-Console abrufbaren 

Liste ausgewählt und automatisch installiert werden. Zentrales Archiv für diese Pakete ist das Comprehensive 

R Archive Network. Neben rein statistischen Algorithmen bietet R eine Vielzahl an Data 

Mining Algorithmen (Pyrke 2007). 

Die Teilgruppe SWF hat sich für die Datenanalyse mit Data Mining für R entscheiden. Begründet ist 

diese Entscheidung einerseits darin, dass SAP aktiv die Nutzung von R für diese Zwecke empfiehlt. 

Andererseits setzen die Physiker von ForWind bereits R für Datenanalysezwecke ein, bereits existierende 

Algorithmen können somit problemlos übernommen werden. 

3.1.4 Microsoft Excel 

Bei Microsoft Excel handelt es sich um eine Software für die Erstellung von Tabellen sowie die Berechnung 

und Analyse von Daten. Für die Analyse können neben Tabellen in klar strukturierten Layouts 

einfache Diagramme erstellt werden (Microsoft 2013). 

Im Projekt SWF wird Excel als Front-End Tool für die Datenanalyse und das Reporting eingesetzt. 

Dies ist vor allem durch die gute Integration in SAP HANA und die schnelle und einfache Datenübertragung 

begründet. Weiterhin ist Excel ein sehr verbreitetes Reporting-Werkzeug und dem Standardbenutzer 

im BI Umfeld bekannt. Zudem erlaubt Excel mit PowerView ein interaktives Reporting sowie 

Datenvisualisierung. Mit dem Einsatz von Excel steht somit eine bekannte und vertraute Anwendungsumgebung 

für das Reporting zur Verfügung. 

424



3.1.5 SAP BusinessObjects 

Die SAP-BusinessObjects-Lösungen (SAP BO) werden zum Aufrufen, Auswerten und Analysieren 

von Daten verwendet. Für die unterschiedlichen Ansprüche der verschiedenen Benutzergruppen an die 

SAP BO-Lösung bietet SAP verschiedene Werkzeuge. Im Bereich Berichtswesen und Analyse stellt 

SAP Crystal Reports und Web Intelligence zur Verfügung. Die SAP Crystal Reports ermöglichen die 

Herstellung von Verbindungen zu verschiedenen Datenquellen, die Erstellung von interaktiven Berichten 

und die interne bzw. externe Verbreitung der Berichte. Mit SAP BO Web Intelligence kann der 

Benutzer Ad-hoc-Abfragen und intuitive Analysen über heterogene Datenquellen hinweg online oder 

offline ausführen. 

SAP BO bietet zudem mit SAP BO Dashboards die Möglichkeit zur Erstellung von interaktiven Dashboards, 

um komplexe Daten schnell zu visualisieren. Für den ETL-Prozess kann SAP BO Integration 

zur Anbindung externer und interner Datenquellen eingesetzt werden. 

Im Rahmen des Projektes SWF sollen als Front-End Lösung SAP BO Crystal Reports, Web Intelligence 

und Dashboards eingesetzt werden. Für die Datenbeschaffung wird SAP BO Integration eingesetzt. 

Um den Zugriff auf SAP HANA zu ermöglichen, steht eine spezielle HANA-Schnittstelle zur 

Verfügung, die für die Realisierung verwendet wird. 

Die Teilgruppe SWF entschied sich für den Einsatz von SAP BO mit dem Hauptgrund, komplexe und 

spezialisierte Reports mit Crystal Reports und Web Intelligence zu erstellen. Diese können beispielsweise 

in Microsoft Word, Excel, per Email oder im Internet publiziert werden und sind somit für alle 

Anwendergruppen geeignet. Dabei sollen SAP BO Dashboards eingesetzt werden, da es eine große 

Menge an Komponenten für das Design von Dashboards bietet. Falls benötigt, können mehrere erstellte 

Berichte in einem Dashboard kombiniert werden (SAP AG – BusinessObjects 2013). 

3.1.6 Smart Wind Farm Control Toolbox 

Die Smart Wind Farm Control Toolbox (SWF Toolbox) ist eine von der Teilgruppe selbst zu entwickelnde 

Software auf Basis der Programmiersprache Java. Diese soll sowohl WEA Daten generieren 

können, als auch einen kontinuierlichen Datenstrom dieser in das SAP HANA System simulieren. Ziel 

ist es, neben der generellen Möglichkeit WEA Daten zu generieren, die Belastbarkeit sowie die funktionalen 

Gegebenheiten des SAP HANA System hinsichtlich eines kontinuierlichen Datenstroms eines 

produktiven Windparks zu testen. 

Für das Generieren von WEA Daten werden im Vorfeld Wetterdaten benötigt, welche mindestens eine 

zeitliche Dimension und die vorherrschende Windgeschwindigkeit beinhalten. Darauf aufbauend werden 

die ermittelten Grenzwerte und Datenverteilungen der von den Projektpartnern zur Verfügung 

425



gestellten WEA Daten herangezogen. Diese dienen als Rahmen bzw. Konfiguration für die zu generierenden 

Daten unter Verwendung der Wetterdaten. 

Nach erfolgter Generierung der Daten soll seitens der SWF Toolbox die Möglichkeit bestehen, diese 

direkt in das SAP HANA System zu übertragen. Dafür gilt es zunächst, eine Möglichkeit zu schaffen, 

um eine Virtual Private Network (VPN) Verbindung zum SAP HANA System aufzubauen sowie unter 

Verwendung einer SAP Java Bibliothek eine Schnittstelle zur SWF Toolbox zu implementieren. Anschließend 

kann durch die Eingabe der gewünschten WEA die Datenübertragung erfolgen. 

Während der weiteren Projektphasen sollen weiterführend neue Erkenntnisse in die Entwicklung der 

SWF-Toolbox einfließen und ggf. den Funktionsumfang erweitern. Übergreifend steht dabei die Funktionalität 

des Programmes im Fokus. Andere Aspekte wie beispielsweise Endbenutzer-Tauglichkeit 

und Szenarien zur Fehlervermeidung, Fehleingaben oder fehlerhafter Anwendung durch den Benutzer, 

sind sekundär einzuordnen. 

3.2 Datenmodell 

Die Windpark-Maintenance-Plattform benötigt ein Datenmodell, in der alle benötigten Attribute gespeichert 

werden können. Dieses Modell muss beliebig erweiterbar sein, damit zusätzliche Attribute 

z. B. aus den Forschungsanlagen mit in die Datenbank aufgenommen werden können. Um Inkonsistenzen 

zu vermeiden sollte das Datenmodell nach der dritten Normalform aufgebaut werden. 

Für die Erstellung eines solchen allgemein gültigen Datenmodells, in dem mehrere Anlagen unterschiedlicher 

Typen inklusive ihrer Wartungsprotokolle gespeichert werden können, müssen mehrere 

Tabellen angelegt werden. Die dabei betrachteten Entitäten sind Windparks, Anlagen, Anlagetypen, 

Sensordaten sowie Wartung. Zusätzlich werden weitere Tabellen für externe Datenquellen, wie beispielsweise 

Wetterdienste, benötigt. 


Für die Windpark-Maintenance-Plattform werden die in dem vorherigen Kapitel beschriebenen verschiedenen 

Softwarelösungen in Form einer zusammenhängenden Architektur umgesetzt. Diese Architektur 

ist in die drei Ebenen ETL, Datenhaltung und Data Mining sowie Reporting unterteilt (siehe 


426



Abbildung 3.1: Geplante Architektur des Smart Wind Farm Control Projekts 

Die ETL-Ebene dient übergreifend der Datenerfassung, -bereinigung und -transformation. Die Daten 

liegen vorwiegend in Form von historischen und generierten WEA Daten vor. Zusätzlich können ergänzende 

Daten wie z. B. Wetterdaten oder Wartungsdaten erfasst werden. Für den möglichen produktiven 

Einsatz ist zusätzlich die Erfassung eines kontinuierlichen Datenstroms von verschiedenen WEA 

aufgeführt. Als native ETL-Software kommt Pentaho Data Integration CE (Kettle) zum Einsatz, um 

die historischen und ergänzenden Daten zu bereinigen und auf das richtige Datenmodell zu transformieren. 

Von dieser getrennt agiert die SWF Toolbox, welche sowohl WEA Daten generiert als auch 

einen möglichen Datenstrom simuliert. 

Die Datenhaltung und Data Mining Ebene ist unterteilt in die Bestandteile SAP HANA und R. Innerhalb 

von SAP HANA operiert der Data Entry Layer als Schnittstelle zwischen den verschiedenen 

Datenquellen und der HANA-Datenbank. Mittels verschiedener Views können die Auswertungstools 

auf die, ggf. durch SQL Scripts angepassten, Daten zugreifen und diese ausgeben. Nebenstehend wird 

R, welches auf einem separaten Suse Linux Server ausgeführt wird, an das SAP HANA System angebunden, 

um Data Mining auf Basis der Daten in SAP HANA zu ermöglichen. 

Änderung 04.02.2013: Abschließend können die Daten aus SAP HANA in der Reporting Ebene unter 

Verwendung von SAP BO, SAP UI5 und Microsoft Excel 2010 für den Endbenutzer anschaulich publiziert 

werden. 

427



3.4 Technische Voraussetzungen 

Für das Projekt SWF gibt es einige zwingende technische Voraussetzungen, um die Realisierung der 

Architektur aus Kapitel 3.3 zu gewährleisten. Diese sollen in den folgenden Kapiteln definiert und 

beschrieben werden. 

3.4.1 Software und Hardware 

Für den Einsatz von SAP HANA werden neben dem eigentlichen System mehrere Benutzerzugänge 

sowie eine entsprechende Verbindungsmöglichkeit zum System in Form einer VPN Verbindung benötigt. 

Es muss sichergestellt sein, dass ausreichende Ressourcen für die Teilgruppe SWF im SAP HA- 

NA System reserviert sind, um eine unterbrechungsfreie Arbeit zu ermöglichen. Für die initiale Projektphase 

werden voraussichtlich mindestens 50 GB an Datenbankspeicher benötigt. Weiterhin muss 

die von SAP bereitgestellte Software für SAP HANA, dazu zählen das SAP HANA Studio, die Microsoft 

Open Database Connectivity (ODBC) Plug-Ins und die Java Database Connector (JDBC) Bibliothek, 

einen fehlerfreien Einsatz gewährleisten. 

Seitens des Suse Linux Servers für R wird ein eigenständiger oder virtueller Server, auf dem Open 

Suse 12.x installiert ist, benötigt. Die Teilgruppe muss über Root-Rechte verfügen oder einen Root- 

Zugang erhalten. Zudem soll die öffentliche Erreichbarkeit mittels einer statischen Internetprotokoll 

(IP)-Adresse oder einem Domain Name Service (DNS)-Eintrag sichergestellt sein. 

Abschließend werden für die Realisierung des Reporting eine lizensierte Version von Microsoft Excel 

und eine lizensierte SAP BO Umgebung mit einer permanenten Verbindung zum SAP HANA System 

benötigt. 

3.4.2 Daten 

Die Beschaffung von Daten ist die größte Herausforderung für die Teilgruppe SWF. Damit ein sinnvolles 

Data Mining durchgeführt werden kann, werden Echtdaten von WEA benötigt. Mit verrauschten 

Daten können probeweise Reportings und auch Data Mining durchgeführt werden, jedoch besitzen 

diese nur geringe Aussagekraft und dienen lediglich als Grundlage für zukünftige Projekte. 

Durchschnittliche WEA besitzen ca. 150 Sensoren pro Maschine. Bei angenommenen 10 Byte pro 

Datensatz ergibt sich pro Jahr – falls die Anlage Sekundendaten versenden kann – eine Datenmenge 

von 47,2 GB. Da HANA die Daten komprimiert, wird weniger Speicherplatz benötigt als errechnet. 

Dabei muss jedoch bedacht werden, dass SAP HANA noch weiteren Arbeitsspeicher für die Berechnungen 

benötigt. 

428



Änderung 04.02.2013: Durch die Gespräche mit der Availon GmbH hat sich herausgestellt, dass Daten 

auf Sekundenbasis in dem beschriebenen Umfang zurzeit nicht beschaffbar sind. 

429



4 Realisierung 

In diesem Kapitel sollen die Maßnahmen beschrieben werden, wie der in Kapitel 3 beschriebene 

Soll-Zustand realisiert wird. Hierfür orientiert sich dieses Kapitel an den im Fachkonzept definierten 

Arbeitspaketen. Das erste Arbeitspaket Windenergieanlagen und SAP Hana Know-how Aufbau wurde 

bereits erfolgreich bearbeitet. Die daraus gewonnenen Erkenntnisse sind daher Ausgangpunkt des 

aktuellen DV-Konzeptes. 

4.1 Analyse und Übernahme des Windpark-Datenmodells 

Ziel dieses Arbeitspakets ist die Analyse der vorgegebenen Windparkdaten und Extraktion eines umfassenden 

Datenmodells, das offen für zukünftige Änderungen ist. Zudem soll der ETL-Prozess für 

das Füllen der SAP HANA Datenbank mit diesen Daten beschrieben werden. 

4.1.1 Datenmodell 

Um das im Kapitel 3.2 beschriebene allgemeingültige Datenmodell in SAP HANA erstellen zu können, 

müssen die benötigten Tabellen und Attribute angelegt werden. Die Attribute der Tabellen wurden 

neben den aus Norkus (2012) übernommenen Kennzahlen um Erkenntnisse aus den Praxisgesprächen 

erweitert. Hierfür wurden die WEA Attribute um die von ForWind übergebenen Daten erweitert. 

Diese enthielten fünf Kennzahlen von 12 Anlagen eines Onshore Windparks. 

 

 

 

 

 

Unix Timestamp 

Windgeschwindigkeit in m/s 

WEC 

Elektrische Leistungsabgabe im KW 

Generator Drehzahl 

Zusätzlich konnte das Datenmodell um den WEC Status erweitert werden. Dieser gibt den Betriebsstatus 

der jeweiligen Anlage wieder. Dabei wird zwischen 42 Betriebsstatus unterschieden, deren genaue 

Bedeutung der Teilgruppe jedoch nicht bekannt ist. 

Hinsichtlich der zu verwendenden Datentypen sind die vorhandenen Beispieldaten herangezogen und 

deren Datentypen ggf. unter Berücksichtigung der Erweiterbarkeit angepasst worden. Dabei wurde 

berücksichtigt, dass SAP HANA intern keine kleinen Datentypen verwendet, sondern automatisch 

z. B. ein Int in ein Long und ein Float in ein Double umwandelt. Die vorläufige Datenbankstruktur 

ohne Attribute wird in Abbildung 4.1 dargestellt, die vollständige Ausführung inklusive aller Attribute 

wird in Anhang A aufgeführt. 

430



Wetterdaten 

Wartung 

von bauteil 

Betrifft_Wartung_Bauteil 

betrifft 

Bauteil 

gehören zu 

von 

Windpark 

gehört zu 

Anlage 

hat 

Sensordaten 

gehört zu 

Anlagentyp 

Abbildung 4.1: Logisches Datenmodell 

Ausgangsbasis des Datenmodells ist ein Windpark, d. h. eine Ansammlung von WEA. Zu einem 

Windpark können mehrere Wetterdaten gespeichert werden, für die unterschiedliche Zeitpunkte und 

Anbieter gespeichert werden. 

Ein Windpark besteht aus mehreren Anlagen, den WEA. Die WEA können über ihren Anlagentyp 

charakterisiert werden, beispielsweise Nordex N90. Laut bisherigem Kenntnisstand sind alle Anlagen 

innerhalb eines Windparks vom gleichen Anlagentyp. Da zukünftige Windparks jedoch unterschiedliche 

Anlagen enthalten können, wurde mit Blick auf die Erweiterbarkeit des Schemas der Anlagentyp 

in Beziehung zur Anlage gesetzt. 

Eine Anlage verfügt über mehrere Sensoren, die über verschiedene Zeitpunkte in der Tabelle Sensordaten 

gespeichert sind. Die verschiedenen Sensoren basieren auf den Ausführung in Kapitel 3.2. 

Zudem können einer Anlage mehrere Wartungen zugeordnet sein. Über die Hilfsrelation Betrifft_Wartung_Bauteil 

ist diese mit der Entität Bauteil verbunden, da innerhalb einer Wartung mehrere 

Bauteile gewartet werden können, ein Bauteil aber auch in mehreren Wartungen enthalten sein 

kann, beispielsweise wenn ein Bauteil wiederholt ausfällt und repariert werden muss. 

Die Daten werden mithilfe des in Abbildung 3.1 dargestellten ETL-Prozesses in die Datenbank geladen. 

Nachdem die historischen Daten als Ganzes übertragen wurden, können die neuen Daten sekündlich 

oder in beliebigen Intervallen an das System versendet werden. Sobald neue Datenquellen vorliegen, 

müssen das gesamte Schema sowie die einzelnen Attribute überprüft werden, um zu ermitteln, ob 

sie den neuen Anforderungen entsprechen oder erweitert werden müssen. 

431



Änderung 04.02.13: Im Gespräch mit Availon wurde bekannt, dass stets mehrere Wetteranbieter miteinander 

verglichen werden, da es zu Unterschieden kommen kann. Diese Option wird mit dem oben 

genannten Modell bereits ermöglicht. 

4.1.2 ETL-Prozess 

Für die Realisierung des ETL Prozesses wird, wie in Kapitel 3.3 beschrieben, die ETL-Softwarelösung 

Pentaho Data Integration CE eingesetzt. Dabei gilt es zu beachten, dass diese ausschließlich für die 

Extraktion und Transformation der Daten vorgesehen ist. Das Laden der Daten in die SAP HANA 

Datenbank wird mit Hilfe des SAP HANA Studios durchgeführt, da bislang keine Schnittstellen seitens 

Pentaho Data Integration CE verfügbar sind. Bei der Extraktion und Transformation muss zwischen 

den verschiedenen Datenarten unterschieden werden. Die historischen WEA Daten und ergänzenden 

Daten (z. B. Wetterdaten) durchlaufen diese beiden Prozessschritte. Für die generierte Daten 

bedarf es keiner weiteren Extraktion und Transformation, da diese direkt oder per SAP HANA Studio 

in die SAP HANA Datenbank geladen werden. Hinsichtlich eines ETL- Prozesses für die Erfassung 

eines kontinuierlichen Datenstroms sind bedingt durch die fehlenden konzeptuellen Rahmenbedingungen 

keine weiterführenden Maßnahmen erfolgt. 

Im Zuge der Datenbeschaffung der WEA Daten durch die Teilgruppe SWF ist absehbar, dass die Datenqualität 

und -formate stark variieren werden. Daher müssen in Hinblick auf die Datenqualität primär 

folgende Kriterien im Vorfeld erfüllt sein (Mertens 2011): 

1. Vollständigkeit: Eine Vollständigkeit der Daten wird erlangt, wenn wichtige identifizierende 

Attribute wie z.B. Zeit oder Anlagennummer vorhanden sind, bzw. sich der Datensatz eindeutig 

identifizieren lässt. Zudem muss die Frage geklärt werden, ob der Datensatz Null-Werte enthält, 

und falls ja ob die eigentlichen Werte an anderer Stelle existieren oder sich diese Null-Werte generieren 

bzw. von anderen Werten ableiten lassen. 

2. Gültigkeit: Der Wertebereich ist gültig bzw. vergleichbar mit bestehenden Daten oder bisherigen 

Annahmen, beispielweise liegt die Temperatur innerhalb eines festgelegten Wertebereichs. 

3. Genauigkeit: Genauigkeit liegt vor, wenn eine ausreichende Definition des Attributes vorhanden 

und die semantische Genauigkeit gewährleistet ist. 

4. Konsistenz: Bestimmte Schlüsselabhängigkeiten wurden eingehalten, beispielsweise kann keine 

Wartung ohne die dazugehörige Anlage existieren. 

5. Dichte: Die Dichte gibt das Verhältnis der Attribute ohne Null-Werte zur Gesamtanzahl der Attribute 

an. Diese muss für analytische Zwecke entsprechend den jeweiligen Bedürfnissen ausreichend 

sein. 

Ergänzend muss der Umgang mit Null-Werten im Vorhinein festgelegt werden. Dieser kann je nach 

Datenbasis unterschiedlich gestaltet sein. Sollte keine Möglichkeit bestehen, eine Korrektur dieser 

432



Null-Werte durchzuführen, muss entschieden werden, ob diese belassen bzw. ignoriert werden oder 

eine Löschung der jeweiligen Spalte oder Zeile durchgeführt werden soll. 

Hinsichtlich der Datenformate, in denen die WEA Daten zur Verfügung gestellt werden, muss sichergestellt 

sein, dass die ETL-Tools diese unterstützen. Daher gilt es im Vorfeld, dem Datenlieferanten 

mögliche Datenformate für den Datenaustausch zu unterbreiten. Sollte dies nicht möglich sein und die 

vorliegenden Datenformate inkompatibel sein, wird seitens der Teilgruppe ein möglicher Lösungsweg 

erarbeitet. 

Pentaho Data Integration CE 

Für die Realisierung des ETL Prozesses in Pentaho Data Integration CE wird im Folgenden der grundlegende 

Prozess beschrieben inklusive der voraussichtlich benötigten Funktionen. Der abzubildende 

Prozess sieht sechs Phasen vor und wird in Abbildung 4.2 dargestellt. 

Abbildung 4.2: Phasen des ETL-Prozesses in Pentaho Data Integration CE 

In der ersten Phase Data-sources (Datenquellen) werden die im Regelfall bereitgestellten Datenquellen 

in Form von Dateiformaten und einer direkten Datenbankanbindung der WEA Daten aufgeführt. 

Die Datenbankanbindung sieht die Verwendung einer renommierten Datenbank vor, wie bspw. MS 

SQL, Oracle etc.. Die einzelnen Dateiformate können in Form einer einzelnen Datei oder mehrerer 

Dateien vorliegen. 

433



Die zweite Phase Data-input (Dateneingabe) betrifft die Import-Funktionen, welche auf Basis der 

aufgeführten Datenformate seitens Pentaho Data Integration CE zur Verfügung gestellt werden. Diese 

lassen sich allesamt sehr umfangreich konfigurieren, bspw. bietet die Funktion „Table input“ die Möglichkeit, 

nahezu alle bekannten Datenbanken einzubinden. 

Die anschließenden Phasen Data-aggregation (Datenaggregation), Data-cleaning (Datenbereinigung) 

und Data-supplementation (Datenergänzung) spiegeln die Transformation der Daten wider. Diese 

wird in Form einer Prozesskette in Pentaho Data Integration CE abgebildet. Hierbei können die einzelnen 

aufgeführten Funktionen auch mehrfach verwendet werden. Diese werden in Tabelle 4.1 näher 

erläutert. 

Abschließend sollen die transformierten Daten in der Phase Data-output (Datenausgabe) in Form von 

Text-Dateien, CSV-Dateien oder SQL-Dateien exportiert, sodass diese im Anschluss per SAP HANA 

Studio problemlos importiert werden können. 

Funktion 

Add Sequence 

Add a checksum 

Sort rows 

Merge Join 

Multiway Merge 

Join 

Split Fields 

Select Values 

Filter rows 

Replace in 

string 

String cut 

Add constants 

Calculator 

Beschreibung 

Hinzufügen einer Sequenz von inkrementierten Werten, z. B. zur Nummerierung 

der eingelesenen Datensätze. 

Generierung einer Checksumme des Datensatzes, bspw. zu Testzwecken oder für 

eine bessere Vergleichbarkeit der Datensätze. 

Sortierung der Datensätze, diese Option wird primär bei mehreren Datenquellen 

für die anschließende Zusammenführung benötigt. 

Zusammenführung zweier Datenquellen anhand eines anzugebenden sortierten 

Schlüssels. 

Zusammenführung mehrerer Datenquellen anhand eines anzugebenden sortierten 

Schlüssels. 

Teilung einer Spalte in mehrere Spalten, unter der Voraussetzung dass die Werte 

Trennzeichen enthalten. 

Selektion und Entfernung von kompletten Spalten. 

Filterung von Spaltenwerten anhand von bestimmten Bedingungen, z.B. um 

Spalten mit Null-Werten zu entfernen. 

Ersetzung eines bestimmten Strings. 

Ausschneiden einer bestimmten Stringsequenz. 

Hinzufügen einer oder mehrerer Konstanten, z.B. Angabe der Anlage für alle 

Sensordatensätze dieser Anlage. 

Auf Grundlage von mehreren Datenspalten eine berechnete Datenspalte generieren. 

Quelle: Pentaho Corporation 2013 

Tabelle 4.1: Pentaho Data Integration CE Funktionen 

434



4.2 Simulation eines Windparks 

Im Rahmen des Arbeitspaketes Simulation eines Windparks erfolgt die Entwicklung der im Kapitel 

3.1.6 beschriebenen SWF Toolbox. Aufbauend auf den dort genannten Rahmenbedingungen wird im 

Folgenden die geplante Realisierung dieser Software erläutert. Für die SWF Toolbox kommt die Programmiersprache 

Java in Verbindung mit der Entwicklungsumgebung Eclipse IDE zum Einsatz. Um 

eine verteilte sowie gleichzeitige Entwicklung zu ermöglichen werden das Versionskontrollsystem 

Mercurial und das Online-Repository Bitbucket eingesetzt. Weiterhin werden folgende Java- 

Bibliotheken für die Realisierung eingesetzt: 

 

 

 

 

Standard Widget Toolkit (SWT): Im Vergleich zur nativen Java Swing Oberfläche ermöglicht die 

Standard Widget Toolkit Bibliothek eine komfortablere und umfangreichere Umsetzung der Benutzeroberfläche 

sowie die Nutzung des Designs des zugrundeliegenden Betriebssystems (Eclipse 

Foundation 2012). 

SAP HANA Java Database Connector (JDBC): Die SAP HANA JDBC Bibliothek schafft die 

Voraussetzung für die Herstellung einer Verbindung zwischen SAP HANA und Java. 

JGoodies Common & Looks: Die JGoodies Bibliotheken sind eine Erweiterung der SWT Bibliothek 

durch neue Designs für die Benutzeroberfläche (JGoodies Software GmbH 2012). 

log4j: Bei der log4j Bibliothek handelt es sich um ein Java Logging- Application programming 

interface, welches die Steuerung der Logausgaben sowie die Speicherung dieser in Textdateien 

ermöglicht (Scherer Informatik GmbH 2012). 

Aus funktioneller Sicht sollen in erster Linie die Funktionen Wetterdaten laden, WEA Daten generieren 

und WEA Daten übertragen realisiert werden. Im Anschluss erfolgt die Realisierung der Benutzeroberfläche 

und die Integration der VPN Verbindung. 

Die Funktion Wetterdaten laden sieht vor, mit Hilfe eines Dateidialogs die Auswahl einer Text- oder 

CSV-Datei, in der die Wetterdaten strukturiert vorliegen, zu ermöglichen. Nach erfolgter Auswahl 

sollen diese in das Programm importiert, ggf. korrigiert oder ergänzt und in Form einer Tabelle auf der 

Benutzeroberfläche dargestellt werden. Anschließend sollen die Angaben zur Konfiguration für die zu 

generierenden Daten durch den Benutzer in der Benutzeroberfläche erfolgen, sodass die Funktion 

WEA Daten generieren ausgeführt werden kann. Diese generiert unter Verwendung eines Java Zufallsalgorithmus 

auf Basis der Wetterdaten und der erfolgten Konfigurationen WEA Daten. Die Ausgabe 

erfolgt ebenfalls in einer Tabelle auf der Benutzeroberfläche. Final soll mit der Funktion WEA Daten 

übertragen eine Verbindung per JDBC zum SAP HANA Datenbanksystem aufgebaut und die Daten 

intervallweise übertragen werden. Die dafür eingeplanten Klassen sowie deren Operationen und Beziehungen 

untereinander werden in Abbildung 4.3 veranschaulicht und beschrieben. 

435



Abbildung 4.3: SWF Toolbox Klassenübersicht 

Für die Benutzeroberfläche sind insgesamt drei Klassen bzw. Benutzeroberflächen vorgesehen. Nach 

erfolgtem Programmaufruf wird zunächst eine Übersicht der Programmfunktionalitäten dargestellt 


436



Abbildung 4.4: SWF Toolbox Übersicht 

Durch Betätigen der Schaltfläche Generator starten wird die Benutzeroberfläche des Generators erstellt. 

Diese beinhaltet die Funktionen Wetterdaten laden und WEA Daten generieren sowie die tabellarische 

Ausgabe der Wetterdaten und die editierbare Konfigurationen (siehe Abbildung 4.5). Über die 

Schaltfläche VPN-Verbindung erfolgt der Verbindungsaufbau zum SAP HANA System. Anschließend 

kann mittels der Schaltfläche Streamer starten die Benutzeroberfläche des Streamers aufgerufen werden. 

Sind bereits Daten generiert worden, werden diese dort in tabellarischer Form ausgegeben. Nun 

kann der Benutzer die gewünschte WEA Nummer eingeben und die Funktion WEA Daten übertragen 

starten (siehe Abbildung 4.6). Wie bereits beschrieben, überträgt diese die Daten in das SAP HANA 

System und bestätigt abschließend die erfolgreiche Übertragung der WEA Daten. 

437



Abbildung 4.5: SWF Toolbox Generator 

Abbildung 4.6: SWF Toolbox Streamer 

438



4.3 Analyse und Reporting 

Änderung 04.02.13: Ein wesentliches Ziel der Teilgruppe SWF ist die Analyse und das Reporting der 

Windenergiedaten. Neben Data Mining mit R sollen Microsoft Excel 2010 und SAP UI5 genutzt werden, 

um die Daten zu visualisieren und auf diese Weise wesentliche Zusammenhänge kenntlich zu 

machen. 

4.3.1 Data Mining mit R 

Für das Data Mining mit SAP HANA empfiehlt SAP die Nutzung von R. Die Begründung dafür ist 

einfach: Wie in SAP HANA werden die Daten in R im Memory oder RAM vorgehalten. Für das Open 

Source Tool R existieren über 4000 Packages. Somit wird die Benutzeroberfläche mit In-Memory 

Verarbeitung für schnelle Datenoperationen auf großen Datenmengen mit den Vorteilen von R kombiniert 

(Aswani & Doerpmund 2011). 

R wird nicht standardmäßig mit SAP HANA ausgeliefert, da R Open Source und unter der General 

Public License (GPL) lizensiert ist. Zudem bietet SAP keinen Support für R (SAP AG 2012, S. 3). 

Falls die Integration von R mit HANA gewünscht ist, gibt es zwei gegensätzliche Ansätze: Outside-In 

und Inside-Out (siehe Abbildung 4.7). 

Quelle: Aswani & Doerpmund (2011) 

Abbildung 4.7: Zwei Ansätze für die Integration von R und HANA 

Inside Out 

Beim Inside Out Zugriff wird R Code in den Stored Procedures von HANA eingefügt. Durch einen 

effizienten Datenaustauschmechanismus wird der Transfer von Datenbanktabellen direkt in die vektororientierte 

Datenstruktur von R ermöglicht. Die Performance wird hierbei gegenüber Standard SQL 

439



Schnittstellen gesteigert, da diese tupelbasiert arbeiten und damit eine zusätzliche Datenkopie in R 

benötigen. 

Für die Inside Out Variante wird R sowie Rserve benötigt. Rserve ist ein TCP/IP Server, der es anderen 

Programmen erlaubt, R zu nutzen, ohne es zu initialisieren bzw. eine R Library einzubinden. R 

und Rserve müssen auf einem separaten System installiert werden, sie können nicht auf dem gleichen 

System wie SAP HANA laufen. Aktuell wird hierfür das Linux System SUSE Linux verwendet. Das 

System muss vom SAP HANA Host-Server erreichbar sein. Um eine High Availability zu unterstützen, 

können R/Rserve auf mehreren unabhängigen Hosts installiert werden. Wenn eines der Systeme 

nicht erreichbar ist, kann ein anderes übernehmen. 

Der Prozess der Installation besteht aus drei Schritten (SAP AG 2012, S. 3). 

1. Installiere R (auf einem eigenen System) 

2. Installiere Rserve (auf einem eigenen System) 

3. SAP HANA Parameter anpassen 

Der genaue Ablauf wird sehr detailliert von Galindo (2012c) beschrieben. 

Anschließend kann R Code direkt in der SAP HANA Datenbank ausgeführt werden, indem R Code in 

SQL Skripte in Form einer RLANG Prozedur eingebettet wird. Die SAP HANA Datenbank nutzt die 

externe R Umgebung, um den R Code auszuführen, ähnlich zu nativen Datenbankoperationen wie 

Join und Aggregation. Dadurch können Entwickler sehr einfach R Funktionsdefinitionen und -aufrufe 

in SQL Skripte einbetten und den gesamten Code als Teil einer Anfrage an die Datenbank senden. 

Um diese Option zu ermöglichen, wurde die Calculation Engine (CalcEngine) der SAP HANA Datenbank 

erweitert. Die CalcEngine unterstützt Datenflussgraphen (calcModels), welche die logische 

Datenbankausführung beschreiben. In diesem Datenflussgraph können Knoten jede native Datenbankoperation 

umfassen, jedoch auch selbstdefinierte Operationen. Eine dieser selbstdefinierten Operationen 

ist der R Operator. Wie jeder andere Operator im CalcModel kann der R Operator eine Anzahl 

von Inputobjekten einlesen und eine Ergebnistabelle zurückgeben (SAP AG 2012, S. 6). 

440



Quelle: SAP AG (2012) S.7 

Abbildung 4.8: Hauptkomponenten des Inside Out Ansatzes 

Abbildung 4.8 beschreibt die drei Hauptkomponenten des Inside Out Ansatzes: Die auf SAP HANA 

basierende Anwendung, die SAP HANA Datenbank, und die R Umgebung. 

Sobald der calcModel Ausführungsplan einen R Operator erreicht, sendet der R Client der CalcEngine 

eine Anfrage über den Rserve Mechanismus, um einen zugeordneten R Prozess auf dem R Host zu 

starten. Anschließend sendet der R Client den R Funktionscode sowie Input Tabellen an diesen R Prozess 

und startet die R Ausführung. Sobald der R Prozess die Funktionsausführung beendet hat, wird 

das Ergebnis an die CalcEngine zurückgesendet, welche das Ergebnis konvertiert. Da die interne spaltenbasierte 

Datenstruktur von SAP HANA jener vektororientierten Struktur des R Ergebnisses sehr 

ähnlich ist, ist diese Konvertierung sehr effizient. 

Indem sich der gesamte Kontrollfluss in der Datenbank befindet, entsteht ein wesentlicher Vorteil: Die 

Ausführungspläne der Datenbank sind von Natur aus parallel, daher können mehrere R Prozesse 

gleichzeitig gestartet werden, welche ohne gegenseitige Beeinflussung parallel verlaufen (SAP AG 

2012, S. 7). 

Outside-In 

Beim Outside-In Zugriff wird von außen über eine Schnittstelle auf HANA zugegriffen. Für den Zugriff 

kann zum einen auf JDBC/ODBC zurückgegriffen werden, welche von HANA nicht empfohlen 

441



werden, oder auf das spezielle RHANA Package (siehe Abbildung 4.8). Das Problem am 

JDBC/ODBC Zugriff ist, dass hierbei Row Tables statt der von HANA empfohlenen Column Tables 

verwendet werden (siehe Kapitel 3.1.1). Beim Zugriff über das RHANA Package können die Datenmengen 

spaltenweise gelesen und geschrieben werden (Aswani & Doerpmund 2011). 

Für Anleitungen für den Zugriff per ODBC wird auf Aswani & Doerpmund (2011), Galindo (2012a) 

und Galindo (2012b) verwiesen, für den Zugriff per RHANA auf Aswani & Doerpmund (2011). 

Entscheidung für Inside-Out 

Die Outside In-Variante mit RHANA wurde intern von SAP genutzt, wurde jedoch nie veröffentlicht 

und wird laut Galindo (2012c) auch nicht weiterentwickelt. Stattdessen wurde die Variante mit einem 

R Server, auf dem RServe läuft, ermöglicht. Daher hat sich die Teilgruppe für die Inside-Out Variante 

entschieden. 

4.3.2 Analysen und Reporting – Microsoft Excel 

Wie bereits in Kapitel 3.1.4 erwähnt, wird Microsoft Excel zur Darstellung der Analysen, welche in 

SAP HANA ausgeführt werden genutzt. Dies ermöglicht es, einen besonders großen Benutzerkreis zu 

erreichen, da Microsoft Excel in vielen Unternehmen eingesetzt wird und die Mitarbeiter mit dieser 

Software dementsprechend vertraut sind. Die geplante Realisierung, sieht dabei folgende drei Bereiche 

vor: Systemvorbereitung, Datenbeschaffung und Datenvisualisierung. 

Im ersten Bereich, der Systemvorbereitung wird die ODBC-Schnittstelle zwischen SAP HANA und 

Excel eingerichtet. Hierfür wird unter Windows die ODBC-Verbindung im ODBC-Datenquellen- 

Administrator definiert. Anschließend kann der Benutzer die Schnittstelle direkt in Excel nutzen. 

Der nächste Bereich, die Datenbeschaffung beinhaltet die Datenextraktion aus SAP HANA und das 

Laden der Daten in Excel. Hierfür wird die im ersten Schritt definierte Schnittstelle benötigt. Anschließend 

an eine erfolgreiche Authentifizierung werden in Excel alle verfügbaren HANA Datenbanken 

angezeigt. Der Benutzer kann somit die für das Reporting gewünschten Daten auswählen. Diese 

Abfragen lassen sich in Excel speichern und wiederverwenden. Zusätzlich können die Anfragen dynamisch 

geändert werden um neue Daten zu laden. Anschließend werden die extrahierten Daten in 

Form einer Tabelle in Excel geladen. Diese Daten können offline benutzt werden, für aktuelle Daten 

wird jedoch eine Synchronisation mit SAP HANA benötigt. 

In dem letzten Bereich, der Datenvisualisierung werden mit Hilfe durch von Excel zur Verfügung 

gestellte Visualisierungsformen die Daten dargestellt, beispielsweise als Diagramm, Bericht, Tabelle 

oder Pivot-Tabelle. 

442



4.3.3 Analysen und Reporting – SAP UI5 

Änderung 04.02.13: Entgegen des im Soll-Konzept beschriebenen Vorhabens erfolgt kein Einsatz von 

SAP BO, da hierfür keine gültige Lizenz zur Verfügung steht. Alternativ hat sich die Teilgruppe für 

den Einsatz von SAP UI5 entschieden. 

Für die Realisierung einer webbasierten Anwendung zur Analyse und Reporting von Windenergiedaten 

mit SAP HANA besteht seit der Version SPS05 die Möglichkeit, SAP UI5 zu nutzen. SAP UI5 

ermöglicht die Entwicklung dieser Anwendung mit Hilfe des SAP HANA Studios innerhalb des SAP 

HANA Systems. Hierbei soll eine dynamische und betriebssystemunabhängige Webanwendung entwickelt 

werden, welche u.a. verschiedene Eigenschaften der einzelnen WEA sowie zahlreiche Reports 

auf Basis der aktuellen Daten im SAP HANA System darstellt. 

SAP UI5 unterschützt dabei drei verschiedene Arten von Views bzw. Ansichten: JSview basierend auf 

JavaScript, XMLview basierend auf der Extensible Markup Language (XML) sowie JSONview basierend 

auf der JavaScript Object Notation (JSON). Für die zu entwickelnde UI5-Anwendung wird die 

JSview View zum Einsatz kommen. Die Entscheidung für JSview beruht primär auf bereits vorhandener 

Erfahrung in der JavaScript Anwendungsentwicklung. Für die Datenübertragung wird das Open 

Data Protocol (OData) verwendet (SAP AG – HANA 2012). 

Die Webanwendung soll eine Übersicht über die Hauptfunktionsbereiche bieten. Hierzu zählen die 

Bereiche Monitor, Log, Reporting und Datamining (siehe Abbildung 4.9). Weiterhin werden auf einer 

oberen Statusleiste verschiedene aktuelle Parameter angezeigt. 

Abbildung 4.9: Mockup SAP UI5 - Startseite 

443



Die Funktion Monitor bietet eine Übersicht über die einzelnen Anlagen. Durch eine farbliche Hervorhebung 

defekter bzw. möglicherweise beschädigter Analgen können diese schnell erkannt und aufgerufen 

werden. Mittels eines Mausklicks auf eine bestimmte Anlage kann eine detailliertere Ansicht 

aufgerufen werden (siehe Abbildung 4.10). 

Abbildung 4.10: Mockup SAP UI5 - Monitor 

Mittels des Menü-Knopfes LOG kann, wie in Abbildung 4.11 dargestellt, eine Error-Tabelle der Datenbank 

angezeigt werden, in der alle Fehlermeldungen der verschiedenen Anlagen inklusive einer 

Beschreibung des Fehlers sowie des Zeitpunktes des Auftretens angezeigt wird. 

444 

Abbildung 4.11: Mockup SAP UI5 - Log



Eine Auflistung der verschiedenen Reports soll mittels der Reporting-Funktion aufrufbar sein. Initial 

sollen vier Reports bzw. Berichte beispielhaft aufgeführt werden. Hiervon beziehen sich zwei auf den 

Betriebsstatus und zwei auf die generierte Leistung. Bei den auf den Betriebsstatus bezogenen Berichten 

handelt es sich um die durchschnittliche Leistungsabgabe sowie Generatordrehzahl und Windgeschwindigkeit 

je Betriebsstatus. Bei den leistungsbezogenen Berichten handelt es sich um durchschnittliche 

Leistungsabgaben sowie Windgeschwindigkeiten je WEA. Die Reporting-Funktion kann 

je nach Anforderung um neue Berichte ergänzt werden. In Abbildung 4.12 wird exemplarisch ein solcher 

Bericht mit verschiedenen dynamischen Diagrammen dargestellt. 

Abbildung 4.12: Mockup SAP UI5 - Reporting 

Optional soll die UI5-Anwendung eine Data Mining-Funktion erhalten, mittels derer verschiedene 

Data Mining-Algorithmen zur Analyse der Daten gestartet werden können. 

445



5 Ansprechpartner 

In den folgenden zwei Kapiteln sollen die wesentlichen Ansprechpartner des Projekts SWF sowie eine 

kurze Beschreibung der Unternehmen, in denen diese tätig sind, vorgenommen werden. 

5.1 Fachliche Ansprechpartner 

Name Position Firma Bereich 

Prof. Dr. Joachim Peinke 

Professor an der Uni-Oldenburg ForWind Windenergie 

Patrick Milan Wissenschaftlicher Mitarbeiter ForWind Windenergie 

Änderung 28.01.13: 

Dr.-Ing. Felix Salfner 

Änderung 04.02.13: 

Olaf Kleesch 

Senior Research Developer 

Director Global Technical Support 

& Engineering 

HPI / SAP 

AG 

Availon 

GmbH 

Tabelle 5.1: Fachliche Ansprechpartner 

Fehlerkettenerkennung 

Windenergie 

Der Teilgruppe stehen für das Projekt mehrere hochqualifizierte Ansprechpartner zur Verfügung (siehe 

Tabelle 5.1). Für den Bereich Windenergie sind die Hauptansprechpartner der Teilgruppe 

Prof. Dr. Joachim Peinke und Patrick Milan von ForWind. ForWind ist ein Zentrum für Windenergieforschung, 

das 2003 gegründet wurde. Das zentrale Forschungsgebiet von ForWind ist die Nutzung 

der Offshore-Windenergie. ForWind ist ein Verbund der Universitäten Oldenburg, Bremen und Hannover. 

Demnächst ist auch der Eintritt der Deutschen Luft- und Raumfahrt (DLR) geplant. In Oldenburg 

wird vor allem das Thema Windphysik behandelt. 

Änderung 28.01.13: Im Themenbereich Fehlerkettenerkennung ist Dr. Ing. Felix Salfner Ansprechpartner 

für die Teilgruppe. Er ist am SAP Innovation Center Potsdam tätig. Hierbei handelt es sich um 

ein Innovationszentrum mit den Schwerpunkten HANA, mobile Anwendungen für Smartphone und 

Tablets sowie Cloud Computing. 

Änderung 04.02.13: Die Teilgruppe hat für den Themenbereich Windenergie neben ForWind einen 

weiteren Ansprechpartner: Olaf Kleesch von der Availon GmbH. Das Unternehmen Availon GmbH 

ist ein Serviceanbieter für WEA, das den kompletten Service rund um WEA bietet. Der Service beinhaltet 

die Gebiete Wartung, Reparaturen sowie eine ständige Fernüberwachung. Zudem werden Schulungen 

und technische Beratungen gegeben. 

446



5.2 Technische Ansprechpartner 

Name Firma Position Bereich 

Andre Pansani HPI / SAP AG SAP Technical Operations Expert SAP HANA 

Henning Schmitz HPI / SAP AG Development Project Manager SAP HANA 

Tabelle 5.2: Technische Ansprechpartner 

Für die Appliance SAP HANA stehen Andre Pansani sowie Henning Schmitz vom HPI als Ansprechpartner 

zur Verfügung (siehe Tabelle 5.2). Hierbei handelt es sich um ein An-Institut der Universität 

Potsdam, das vom SAP-Mitbegründer Hasso Plattner gegründet wurde. Für weitere fachliche Fragen 

steht der Teilgruppe das SAP Forum zur Verfügung. 

447



6 Literaturverzeichnis 

INTERNETQUELLEN 

Aswani, H. & Doerpmund, J. (2011): Advanced Analytics with R and SAP HANA, URL: 

http://datatable.r-forge.r-project.org/randsaphana-dkom.pdf, (Zugriff am: 03.12.2012). 

Eclipse Foundation (2012): SWT: The Standard Widget Toolkit, URL: http://www.eclipse.org/swt/, 

(Zugriff am: 12.12.2012). 

Galindo, A. T. (2012a): HANA meets R, URL: http://scn.sap.com/community/hana-inmemory/blog/2012/01/26/hana-meets-r, 

(Zugriff am: 05.12.2012). 

Galindo, A. T. (2012b): R meets HANA, URL: http://scn.sap.com/community/hana-inmemory/blog/2012/01/29/r-meets-hana, 

(Zugriff am: 05.12.2012). 

Galindo, A. T. (2012c): When SAP HANA met R – First kiss, URL: 

http://scn.sap.com/community/developer-center/hana/blog/2012/05/21/when-sap-hana-met-r--firstkiss, 

(Zugriff am: 05.12.2012). 

JGoodies Software GmbH (2012): Professional Java Desktop, URL: http://www.jgoodies.com/, (Zugriff 

am: 12.12.2012). 

Microsoft – Excel (2013): Neuerungen in Excel 2013, URL: http://office.microsoft.com/de-de/excelhelp/neuerungen-in-excel-2013-HA102809308.aspx, 

(Zugriff am: 04.02.2013). 

Microsoft (2013): Was ist Excel?, URL: http://office.microsoft.com/de-de/novice/was-ist-excel- 

HA010265948.aspx , (Zugriff am: 04.02.2013). 

Pentaho Corporation (2012): Pentaho Kettle Project, URL: http://kettle.pentaho.com/, (Zugriff am: 

15.11.2012). 

Pentaho Corporation (2013): Latest Pentaho Data Integration Documentation, URL: 

http://wiki.pentaho.com/display/EAI/Latest+Pentaho+Data+Integration+%28aka+Kettle%29+Docume 

ntation, (Zugriff am: 05.01.2013). 

Pyrke, A. (2007): Introducing R, URL: 

http://www.andypryke.com/twiki/pub/Andypublic/R/Introducing_R.ppt, (Zugriff am: 03.12.2012). 

SAP AG – BusinessObjects (2013): SAP-BusinessObjects-Lösungen für BI, URL: 

http://www.sap.com/germany/solutions/sapbusinessobjects/large/business-intelligence/index.epx, 

(Zugriff am: 04.02.2013). 

448



SAP AG – HANA (2012): SAP HANA Developer Guide, URL: 

http://help.sap.com/hana/hana_dev_en.pdf, (Zugriff am: 04.02.2013). 

SAP AG (2012): SAP HANA R Integration Guide, URL: 

http://help.sap.com/hana/hana_dev_r_emb_en.pdf, (Zugriff am: 02.12.2012). 

Scherer Informatik GmbH (2012): log4j – Einführung, URL: http://schererit.ch/opensource/log4j.html, 

(Zugriff am: 12.12.2012). 

Wirtschaftsuniversität Wien (2012): R Project, URL: http://www.r-project.org/, (Zugriff am: 

05.12.2012). 

BÜCHER 

Mertens, M (2011): Datenqualitätsmanagement im Gesundheitswesen, Vorlesung, Universität Oldenburg 

– OFFIS-Institut für Informatik. 

Norkus, O. (2012): Entwicklung eines Kennzahlensystems zur Windparksteuerung, Masterarbeit, Universität 

Oldenburg. 

Word, J. (2012): SAP HANA Essentials: Epistemy Press LLC. 

449



Anhang 

A. Datenmodell 

Abbildung A.1: Datenmodell 

450


Smart Wind Farm Control – Dokumentation 




Dokumentation 

451



452



Inhaltsverzeichnis – Dokumentation 





1 Einleitung ........................................................................................................................ 459 

2 Projektverlauf .................................................................................................................. 460 

3 Ergebnisdarstellung & Technische Dokumentation ....................................................... 464 

3.1 Architektur .................................................................................................................. 464 

3.2 Datenbankmodell ........................................................................................................ 465 

3.2.1 Struktur ............................................................................................................ 465 

3.2.2 Beschreibung der Tupel ................................................................................... 466 

3.2.3 Bestandsaufnahme ........................................................................................... 470 

3.3 ETL-Prozesse ............................................................................................................. 471 

3.3.1 Daten von ForWind ......................................................................................... 471 

3.3.2 Daten von Availon ........................................................................................... 477 

3.4 SWF Toolbox ............................................................................................................. 479 

3.4.1 Unterstützende Software .................................................................................. 479 

3.4.2 Programmstruktur ............................................................................................ 480 

3.4.3 Programmdaten ................................................................................................ 493 

3.4.4 Projektordnerstruktur ....................................................................................... 494 

3.5 Data Mining ................................................................................................................ 494 

3.6 Reporting .................................................................................................................... 499 

3.6.1 Microsoft Excel ............................................................................................... 499 

3.6.2 SAP UI5 ........................................................................................................... 504 

4 Benutzerhandbücher........................................................................................................ 510 

4.1 SAP HANA Studio ..................................................................................................... 510 

4.1.1 HANA Studio einrichten ................................................................................. 510 

4.1.2 Datenbank anlegen .......................................................................................... 512 

4.1.3 Tabelle anlegen ................................................................................................ 512 

4.1.4 Spalten umbenennen ........................................................................................ 513 

4.1.5 Tabelle befüllen ............................................................................................... 514 

4.1.6 Analysen erstellen ............................................................................................ 514 

4.1.7 Trigger anlegen ................................................................................................ 519 

4.1.8 SAP UI5 ........................................................................................................... 519 

4.2 Durchführung des ETL-Prozesses der ForWind Daten .............................................. 521 

4.2.1 Voraussetzungen und Anforderungen ............................................................. 521 

4.2.2 Durchführung................................................................................................... 521 

4.3 SWF Toolbox ............................................................................................................. 532 


4.3.2 Installation ....................................................................................................... 532 

4.3.3 Daten ................................................................................................................ 533 

4.3.4 Betrieb ............................................................................................................. 535 

4.4 R/Rserve ..................................................................................................................... 545 

4.4.1 Einführung in R ............................................................................................... 545 

4.4.2 Installation ....................................................................................................... 546 

4.4.3 Beispiele .......................................................................................................... 550 

453



4.5 SAP UI5 Reporting..................................................................................................... 556 


4.5.2 Betrieb ............................................................................................................. 556 

4.6 Microsoft Excel Reporting ......................................................................................... 563 


4.6.2 Betrieb ............................................................................................................. 563 

5 Fazit ................................................................................................................................. 567 

6 Literaturverzeichnis ........................................................................................................ 569 

Anhang ................................................................................................................................... 571 

A.1. Interviewfragen Smart Wind Farm Control .................................................................... 571 

A.2. Protokoll BTC 23.05.2012 .............................................................................................. 572 

A.3. Protokoll Prof. Peinke 06.08.2012 .................................................................................. 577 

A.4. Paper Future Soc Lab Day .............................................................................................. 586 

A.5. Plakat Future Soc Lab Day ............................................................................................. 590 

A.6. Präsentation Future Soc Lab Day 14.11.2012................................................................. 591 

A.7. Protokoll ForWind 29.11.2012 ....................................................................................... 601 

A.8. Strategieänderung 03.12.2012 ........................................................................................ 606 

A.9. Protokoll COWS 17.12.2012 .......................................................................................... 607 

A.10. Paper 5. BUIS Tagung ............................................................................................... 611 

A.11. Protokoll HPI/SAP 24.01.2013 .................................................................................. 620 

A.12. Protokoll Availon 31.01.2013 .................................................................................... 628 

A.13. Protokoll Wind Energy Workshop 13.02.2013 .......................................................... 633 

A.14. Datenbankmodell ....................................................................................................... 636 

454




Abbildung 3.1: Architektur .................................................................................................... 464 

Abbildung 3.2: Logisches Datenmodell ................................................................................. 465 

Abbildung 3.3: Übersicht Datensätze der Tabelle SENSORDATEN .................................... 471 

Abbildung 3.4: Pentaho Data Integration CE - Transformationskette ................................... 474 

Abbildung 3.5: Pentaho Data Integration CE – Job ............................................................... 476 

Abbildung 3.6: Pentaho Data Integration CE – Zusammenführung ...................................... 476 

Abbildung 3.7:Klassenmodell - „Two_Dimension_Arraylist“ .............................................. 482 

Abbildung 3.8: Klassenmodell - Programmaufruf ................................................................. 482 

Abbildung 3.9: Klassenmodell - Grafische Benutzeroberfläche erzeugen ............................ 483 

Abbildung 3.10: SWF Toolbox - Grafische Oberfläche ........................................................ 484 

Abbildung 3.11: Klassenmodell – OpenVPN starten ............................................................. 485 

Abbildung 3.12: Klassenmodell - Datengenerator aufrufen .................................................. 485 

Abbildung 3.13: SWF Toolbox - Grafische Oberfläche des Datengenerators ....................... 486 

Abbildung 3.14: Klassenmodell - XML-Konfiguration und Wetterdaten laden ................... 487 

Abbildung 3.15: Klassenmodell - Daten generieren .............................................................. 488 

Abbildung 3.16: SWF Toolbox - Grafische Oberfläche der generierten Daten ..................... 488 

Abbildung 3.17: Klassenmodell - Generierte Daten speichern .............................................. 489 

Abbildung 3.18: Klassenmodell - Daten-Streamer öffnen ..................................................... 489 

Abbildung 3.19: SWF Toolbox - Grafische Oberfläche des Data-Streamer .......................... 490 

Abbildung 3.20: Klassenmodell - WEA-Übersicht und generierte Daten laden ................... 491 

Abbildung 3.21: Klassenmodell - Datenübertragung starten ................................................. 492 

Abbildung 3.22: Timeout Fehlermeldung .............................................................................. 495 

Abbildung 3.23: Entscheidungsbaum für Status für 200 Datensätze ..................................... 496 

Abbildung 3.24: Entscheidungsbaum Windgeschwindigkeit ................................................ 498 

Abbildung 3.25: ODBC Data Source Administrator – SAP HANA Verbindung ................. 499 

Abbildung 3.26: Excel Verbindung zu SAP HANA herstellen ............................................. 500 

Abbildung 3.27: Excel - Tabellen- und Spaltenauswahl ........................................................ 500 

Abbildung 3.28: Excel - Abfrage-Assistent ........................................................................... 501 

Abbildung 3.29: Excel – SAP HANA Verbindung (Query zum Report 1) ........................... 501 

Abbildung 3.30: Excel – SAP HANA Ergebnistabelle .......................................................... 502 

Abbildung 3.31: Excel – Bericht ............................................................................................ 503 

Abbildung 3.32: SAP UI5 - Hauptseite .................................................................................. 507 

Abbildung 3.33: SAP UI5 - Monitor ...................................................................................... 508 

Abbildung 3.34: SAP UI5 - Log ............................................................................................ 509 

Abbildung 4.1: HANA Studio - System hinzufügen .............................................................. 511 

Abbildung 4.2: HANA Studio - Add System ......................................................................... 511 

Abbildung 4.3: HANA Studio - neues Schema anlegen ........................................................ 512 

Abbildung 4.4: HANA Studio - neue Tabelle anlegen .......................................................... 513 

Abbildung 4.5: HANA Studio - Spalten anlegen ................................................................... 513 

Abbildung 4.6: HANA Studio - Tabelle befüllen .................................................................. 514 

Abbildung 4.7: HANA Studio - neues Package erstellen ...................................................... 515 

Abbildung 4.8: HANA Studio - Anlegen einer View ............................................................ 515 

Abbildung 4.9: Analytic View - Namen auswählen .............................................................. 516 

Abbildung 4.10: Analytic View - Tabellen auswählen .......................................................... 516 

Abbildung 4.11: Analytic View – Ergebnis ........................................................................... 517 

Abbildung 4.12: Analytic View - Attribute festlegen ............................................................ 517 

Abbildung 4.13: Attribute View – Name ............................................................................... 518 

Abbildung 4.14: Eclipse IDE – Installation von Software Dialog ......................................... 520 

Abbildung 4.15: Eclipse DIE – Repository hinzufügen ......................................................... 520 

455



Abbildung 4.16: Geöffnete Rdata2ASCII.R Datei ................................................................. 522 

Abbildung 4.17: Ausführung einer R Prozedur in RGUI ....................................................... 522 

Abbildung 4.18: Fortschrittskontrolle in RGui ...................................................................... 523 

Abbildung 4.19: Extrahierte ForWind Textdateien ................................................................ 523 

Abbildung 4.20: Geöffnete „ForWind_Transformation.ktr“ Tranformation ......................... 524 

Abbildung 4.21: Änderung des Dateipfads der „Text file input“ Elemente .......................... 525 

Abbildung 4.22: Änderung des Dateipfads des „Text file output“ Elementes ....................... 525 

Abbildung 4.23: Geöffneter „ForWind_Job_Transformation.kjb“ Job ................................. 525 

Abbildung 4.24: E-Mail Konfiguration in Pentaho Data Integration..................................... 526 

Abbildung 4.25: ForWind Tranformations Job ausführen ..................................................... 526 

Abbildung 4.26: Ausgeführte Prozesskette des ForWind Job ................................................ 527 

Abbildung 4.27: „ForWind_ Nummerierung_Alle.ktr“ - Dateipfade ändern ........................ 528 

Abbildung 4.28: „ForWind_ Nummerierung_Alle.ktr“ - Ausgabepfad anpassen ................. 528 

Abbildung 4.29: „ForWind_ Nummerierung_Alle.ktr“ – Ausgabegröße anpassen .............. 528 

Abbildung 4.30: SAP HANA Studio Import Funktion .......................................................... 529 

Abbildung 4.31: SAP HANA Studio – File Import Wizard Schritt 1 .................................... 530 

Abbildung 4.32: SAP HANA Studio – File Import Wizard Schritt 2 .................................... 530 

Abbildung 4.33: SAP HANA Studio – Import Vorgang überwachen ................................... 531 

Abbildung 4.34: SWF Toolbox - Dateieigenschaften ............................................................ 533 

Abbildung 4.35: SWF Toolbox - Hauptfenster ...................................................................... 535 

Abbildung 4.36: SWF Toolbox – VPN Verbindung aufbauen .............................................. 536 

Abbildung 4.37: Open VPN – Verbindungsstatus ................................................................. 536 

Abbildung 4.38: SWF Toolbox – Daten Generator ............................................................... 537 

Abbildung 4.39: SWF Toolbox – Auswahl der Wetterdaten ................................................. 538 

Abbildung 4.40: SWF Toolbox – Tabelle Wetterdaten ......................................................... 538 

Abbildung 4.41: SWF Toolbox – Konfigurationstabelle Teil 1 ............................................. 539 



Abbildung 4.44: SWF Toolbox – Richtige Konfiguration ..................................................... 540 

Abbildung 4.45: SWF Toolbox – Generierte Daten .............................................................. 541 

Abbildung 4.46: SWF Toolbox – Daten Streamer ................................................................. 542 

Abbildung 4.47: SWF Toolbox – WEA Übersicht laden ....................................................... 543 

Abbildung 4.48: SWF Toolbox – Generierte Daten öffnen ................................................... 543 

Abbildung 4.49: SWF Toolbox – Konfigurationsleiste des Daten Streamers ....................... 544 

Abbildung 4.50: SWF Toolbox – Protokoll der Datenübertragung ....................................... 544 

Abbildung 4.51: SWF Toolbox – Dialog für erfolgreiche Datenübertragung ....................... 545 

Abbildung 4.52: SAP HANA Studio - Administration .......................................................... 549 

Abbildung 4.53: SAP HANA Studio - CAM ......................................................................... 549 

Abbildung 4.54: Ergebnis der Klassifikation ......................................................................... 554 

Abbildung 4.55: Kreuzvalidierung der Klassifikation ........................................................... 555 

Abbildung 4.56: VPN-Verbindung ........................................................................................ 556 

Abbildung 4.57: VPN-Verbindung - Benutzer ...................................................................... 557 

Abbildung 4.58: SAP UI5 – Home - Übersicht ..................................................................... 557 

Abbildung 4.59: SAP UI5 – Home - Monitor ........................................................................ 558 

Abbildung 4.60: SAP UI5 – Monitor ..................................................................................... 558 

Abbildung 4.61: SAP UI5 – Monitor - Erweitert ................................................................... 559 

Abbildung 4.62: SAP UI5 – Log ............................................................................................ 559 

Abbildung 4.63: SAP UI5 – Reporting - Übersicht ............................................................... 560 

Abbildung 4.64: SAP UI5 – Reporting – Report 1 ................................................................ 560 



456




Abbildung 4.68: SAP UI5 – Data Mining .............................................................................. 562 

Abbildung 4.69: VPN-Verbindung ........................................................................................ 563 

Abbildung 4.70: VPN-Verbindung - Benutzer ...................................................................... 564 

Abbildung 4.71: Benutzerhandbuch Excel - Menü ................................................................ 564 

Abbildung 4.72: Benutzerhandbuch Excel - Reiter ............................................................... 564 

Abbildung 4.73: Benutzerhandbuch Excel – Charts 1 ........................................................... 565 



Abbildung A.1: Datenbankmodell ......................................................................................... 636 


Tabelle 3.1: Tupel Tabelle Wetterdaten ................................................................................. 466 

Tabelle 3.2: Tupel Tabelle Windpark .................................................................................... 467 

Tabelle 3.3: Tupel Tabelle Anlage ......................................................................................... 467 

Tabelle 3.4: Tupel Tabelle Anlagentyp .................................................................................. 467 

Tabelle 3.5: Tupel Tabelle Wartung ...................................................................................... 468 

Tabelle 3.6: Tupel Tabelle Betrifft_Wartung_Bauteil ........................................................... 468 

Tabelle 3.7: Tupel Tabelle Bauteil ......................................................................................... 468 

Tabelle 3.8: Tupel Tabelle Sensordaten ................................................................................. 469 

Tabelle 3.9: Zusätzliche Tupel durch Availon-Daten ............................................................ 470 

Tabelle 3.10: Attribute der ForWind Daten ........................................................................... 472 

Tabelle 3.11: Erläuterung der Transformationskette .............................................................. 475 

Tabelle 3.12: Attribute Availon WP GE ................................................................................ 478 

Tabelle 3.13: Attribute Availon WP Vestas ........................................................................... 478 

Tabelle 3.14: Unterstützende Software der SWF Toolbox .................................................... 479 

Tabelle 3.15: Paketstruktur der SWF Toolbox....................................................................... 481 

Tabelle 3.16: Projektstruktur SAP UI5 Webanwendung ....................................................... 505 

Tabelle 4.1: Voraussetzungen ................................................................................................ 510 

Tabelle 4.2: SAP UI5 – Voraussetzungen und Anforderungen ............................................. 556 

Tabelle 4.3: Excel – Voraussetzungen und Anforderungen ................................................... 563 

457




AFL 

BI 

BO 

CE 

COAST 

COWS 

CRAN 

CRM 

CSS 

CSV 

DV 

EE 

ETL 

GB 

GCC 

GUI 

HANA 

HPI 

HTML 

IDE 

IP 

JDBC 

JSON 

kPa 

MB 

OData 

ODBC 

OLAP 

PAL 

SQL 

SWF 

SWT 

TCP 

UI 

VPN 

WEA 

XML 

Application Function Libraries 


BusinessObjects 

Community Edition 

Center for Environment and Sustainability 

Coordination of Offshore Windpark Servicing 

Comprehensive R Archive Network 

Customer Relationship Management 

Cascading Style Sheets 

Comma-separated values 

Datenverarbeitung 

Enterprise Edition 


Gigabyte 

Gnu Compiler Collection 

Graphical User Interface 


Hasso-Plattner-Institut 

Hypertext Markup Language 

Integrated Development Environment 

Internetprotokoll 

Java Database Connector 

JavaScript Object Notation 

Kilopascal 

Megabyte 

Open Data Protocol 

Open Database Connectivity 

Online Analytical Processing 

Predictive Analytics Library 



Standard Widget Toolkit 

Transmission Control Protocol 

User Interface 

Virtual Private Network 



458



1 Einleitung 

Das vorliegende Dokument enthält die Dokumentation der Teilgruppe Smart Wind Farm Control, 

welche übergreifend zu der Projektgruppe Business Intelligence Applications and Evaluation gehört. 

Ziel dieser Dokumentation ist es, ergänzend zum Fach- und DV-Konzept, alle erfolgten Tätigkeiten 

sowie Ergebnisse der Teilgruppe niederzulegen und ein abschließendes Fazit zu ziehen. Die Dokumentation 

gliedert sich in vier Bereiche. 

Zunächst dem Projektverlauf (siehe Kapitel 2), der eine Zusammenfassung aller wichtigen Ereignisse, 

wie strategische Änderungen, Meetings mit Projektpartnern und ergänzende Tätigkeiten chronologisch 

aufführt und beschreibt. 

Darüber hinaus der Ergebnisdarstellung und Technischen Dokumentation (siehe Kapitel 3), in der alle 

Ergebnisse der im DV-Konzept aufgeführten Arbeitspakete Analyse und Übernahme der Windpark- 

Datenstruktur, Simulation eines Windparks und Analyse und Reporting aus technischer Sicht, sowie 

deren Entstehungsgeschichte beschrieben werden. 

Außerdem den Benutzerhandbüchern (siehe Kapitel 4), die dem Leser die Verwendung der zuvor in 

Kapitel 3 beschriebenen, Applikationen und Verfahren aus Benutzersicht beschreiben. Diese dienen 

einerseits als Anleitungsfunktion und andererseits als Nachschlagewerk. 

Das abschließende Fazit (siehe Kapitel 5) basiert auf der ursprünglichen Fragestellung und spiegelt die 

gesamte Projektphase wieder. Dabei stehen insbesondere die erfolgten Tätigkeiten und deren 

wichtigsten Erkenntnisse sowie Problematiken im Fokus. Weiterhin wird ein Ausblick auf die weitere 

Nutzung der Projektergebnisse und dessen potenzielle Chancen gegeben. 

459



2 Projektverlauf 

Da sich die Projektziele aufgrund von externen Faktoren während der Projektlaufzeit mehrmals geändert 

haben, soll im Folgenden der chronologische Ablauf dargestellt werden. 

Im Rahmen der Projektgruppe Business Intelligence Applications and Evaluation stellt Smart Wind 

Farm Control (SWF) ein Teilprojekt neben den Projekten Analytisches Customer Relationship Management 

(CRM) und Nachhaltige Mobilität dar. Das ursprüngliche, vorgegebene Ziel der Projektgruppe 

bestand darin, einen virtuellen Windpark unter Beachtung von vorgegebenen Algorithmen, 

Daten und Know-How aufzubauen. Hierfür war bereits festgelegt, dass die Projektgruppe die aktuelle 

In-Memory Technologie SAP HANA (High Performance Analytic Appliance) für die Datenhaltung 

und -analyse einsetzen sollte. 

Für die Bestimmung der Rahmenbedingungen entwarf die Projektgruppe einen Interviewfragebogen, 

(siehe Anhang A.1). Darauf aufbauend führte die Projektgruppe am 23.05.2012 ein Interview mit 

Markus Seyfert von dem Unternehmen BTC AG (siehe Anhang A.2). Hierbei stellte sich heraus, dass 

die BTC AG bisher keine konkreten Vorstellungen hinsichtlich der Kooperation besaß. Die Projektgruppe 

schlug daraufhin als mögliches Thema vor, Analysen über große Datenmengen (Big Data) 

prototypisch mit SAP HANA umzusetzen. Zudem könnte Data Mining von Relevanz sein. 

Aufgrund von personalen Veränderungen bei dem Projektpartner BTC konnte das zweite Interview 

nicht stattfinden und wurde ersatzweise am 30.05.2012 durch die Projektgruppenbetreuerin Jennifer 

Osmers durchgeführt. Hierbei erlangte die Projektgruppe die folgenden Erkenntnisse: Die genauen 

Anforderungen seitens der BTC blieben weiterhin unklar, da Markus Seyfert lediglich kurzfristig als 

Ersatz eingesprungen war. Laut Aussage von Jennifer interessierte die BTC an der Kooperation vor 

allem der Bereich Fehlerkettenerkennung und Data Mining. Als mögliches Ziel der Projektgruppe 

wurde daher genannt, einen Algorithmus zu wählen und – ohne diesen zu evaluieren – exemplarisch 

anzuwenden. Zudem wurde als mögliches Ziel ein Technologievergleich zwischen SAP HANA und 

Microsoft In-Memory angedacht. 

Ein für Juni in Aussicht gestellter Termin mit der BTC AG fand nicht statt. Am 13.06.2012 berichtete 

Deyan Stoyanov im Projektgruppenmeeting, dass anfangs über 50% der Projektgruppe das Thema 

SWF behandeln wollten, das Interesse aufgrund der häufigen Terminverschiebungen jedoch deutlich 

gesunken sei. Professor Marx Gomez versprach daher, sich um eine baldige Entscheidung zu kümmern, 

wie und ob die Kooperation weiterlaufen sollte. 

Die endgültigen Teilnehmer der einzelnen Teilgruppen wurden am 24.06.2012 festgelegt. Die Teilgruppe 

SWF besteht seitdem aus den Mitgliedern Deyan Stovanov, Patrick Böwe, Michael Schumann 

sowie Ronja Queck. Da im darauffolgenden Monat fraglich blieb, ob die Teilgruppe mit der BTC oder 

einem anderen Partner kooperiert, erarbeiteten die Projektgruppenmitglieder Seminararbeiten. Hierfür 

460



erhielt Michael Schumann eine Secure ID Karte für SAP HANA und hatte somit erstmals Zugang zu 

der In-Memory Technologie. 

Am 01.08.2012 gab Benjamin Wagner vom Berg bekannt, dass als neuer Praxispartner Herr Prof. Dr. 

Peinke von ForWind zur Verfügung steht. Fünf Tage später, am 06.08.2012, fand ein sehr informatives 

Gespräch mit diesem statt (siehe Anhang A.3). 

Neben einer generellen Einführung in das Thema Windenergie wurden mögliche Fragestellungen für 

eine Kooperation diskutiert. Hierbei ergab sich als ein großes Thema die Dimension Zeit. Obwohl die 

Windenergieanlagen (WEA) im Sekundenrhythmus Werte erfassen und darauf reagieren, werden bei 

ForWind 10-Minuten-Mittelwerte für Berechnungen eingesetzt. Aufgrund der höheren Geschwindigkeit 

einer In-Memory Datenbank könnte es möglich sein, genauere Berechnungen anzustellen. Prof. 

Peinke versprach der Teilgruppe, entweder anonymisierte Realdaten oder stochastisch berechnete Daten 

zur Verfügung zu stellen. 

Anschließend wurde der folgende grobe Ablauf für den Rest des Projekts festgelegt: 

1. SAP Hana initialisieren 

2. Testdaten analysieren und evtl. reduzieren bzw. aufbereiten und dokumentieren 

3. Testdaten in SAP HANA modellieren (u.a. ETL). Dies sollte das primäre Ziel der Teilgruppe 

sein. 

4. Durchführung verschiedener Analysen (diese werden z.T. von Prof. Peinke zur Verfügung gestellt). 

Ein mögliches Anwendungsszenario ist die Ermittlung der Lebensdauer einer Komponente, 

um eine proaktive Wartung zu veranlassen. Hierfür soll im HANA-System ein Alerting 

genutzt werden: Bei Über-/Unterschreitung von vorher definierten Schwellwerten soll ein 

Alarm und damit ein Wartungseinsatz ausgelöst werden. Gegebenenfalls kann das Alerting 

um ein lernendes System erweitert werden, um die regelmäßigen Wartungen zu verbessern 

und so zusätzliche Wartungsarbeiten zu vermeiden. 

5. SAP HANA Feedback erstellen 

Die Erkenntnisse aus dem Gespräch mit Prof. Peinke flossen in das Fach- und Datenverarbeitungs 

(DV)-Konzept ein. 

Ab dem 16.08.2012 starteten die zweiwöchentlichen Telefonkonferenzen mit dem Hasso-Plattner- 

Institut (HPI). In diesen konnten offene Fragen bzw. Probleme besprochen werden. Zudem konnten 

Anregungen für die Verbesserung das SAP HANA Beta Systems genannt werden. Während dem 

03.09.2012 und 30.10.2012 nahm Michael Schumann erfolgreich an einer Open-HPI Schulung zum 

Thema In-Memory teil. 

461



Die bisherigen Erfahrungen und Projektziele wurden anschließend am 14.11.2012 beim Future Soc 

Lab Day am HPI in Potsdam vorgestellt. Hierfür wurde im Vorhinein ein Paper, Plakat und eine Präsentation 

erstellt (siehe Anhang A.4, A.5 und A.6). Die Teilgruppe konnte dort viele neue Erkenntnisse 

erlangen. Neben den Rückfragen zu ihrer eigenen Präsentation lernte die Teilgruppe vergleichbare 

Projekte, neue Funktionen bzw. Meilensteine hinsichtlich SAP HANA sowie die zuständigen Personen 

persönlich kennen. Insbesondere durch eine Präsentation der Universität Mannheim konnte viel 

neues Wissen aufgebaut werden. Diese Erkenntnisse wurden anschließend in das DV-Konzept übernommen. 

Am 29.11.2012 fand ein weiterer Meilenstein des Projektablaufs statt: In einem Treffen mit Patrick 

Milan von ForWind wurden sechs Attribute von WEA-Daten besprochen, die der Teilgruppe anschließend 

zur Verfügung gestellt werden sollten (siehe Anhang A.7). Bereits vorher hatte die Teilgruppe 

aufgrund der noch nicht vorhandenen Daten eine Strategieänderung ausgearbeitet, die an diesem 

Nachmittag mündlich mit Benjamin Wagner vom Berg sowie Andreas Solsbach besprochen und 

am 03.12.2012 finalisiert wurde (siehe Anhang A.8). Das neue Ziel der Teilgruppe wurde es somit, 

eine grundlegende Systemlandschaft bzw. Plattform umzusetzen, um den Funktionsumfang für weiterführende 

Projekte zu demonstrieren. Hierfür sollten verschiedene mögliche Technologien recherchiert 

sowie Lösungswege aufgezeigt werden. Insgesamt sollte ein einheitliches System für die Nutzung von 

Echtdaten, Algorithmen und Data Mining vorbereitet werden. Dabei sollten insbesondere die möglichen 

Schnittstellen und Systemkomponenten für ein zukünftiges proaktives Wartungssystem aufgezeigt 

werden. 

Die Testdaten wurden am 10.12.2012 in verrauschter Form durch Patrick Milan übergeben. Sie befanden 

sich auf zwei DVDs und waren komprimiert ca. 5,5 GB groß. Somit standen der Teilgruppe erstmals 

Daten zur Verfügung. In der darauf folgenden Woche begann die Teilgruppe, die Daten zu analysieren, 

zu bereinigen und in das SAP HANA System zu importieren. 

Am 17.12.2012 fand ein Treffen mit der Projektgruppe Coordination of Offshore Windpark Servicing 

(COWS) statt (siehe Anhang A.9). Diese Projektgruppe plante, eine Simulations- und Planungsumgebung 

für Wartungseinsätze in Offshore-Windfarmen zu erstellen. Neben einer realitätsgetreuen Modellierung 

der Windfarmen, ihrer Wartungs-Infrastruktur sowie der Wetterverhältnisse sollte eine Planungskomponente 

entwickelt werden, die auf Grundlage von Wetterdaten, Betreibervorgaben und 

Bedarfsprognosen Entscheidungen trifft (bzw. Entscheidungsalternativen vorschlägt) über Zeitpunkt, 

Ort und Art von anstehenden Wartungseinsätzen. 

Anschließend reichte die Teilgruppe zum 31.12.2012 ein Paper für die fünfte BUIS-Tagung ein. Dieses 

wurde jedoch aufgrund des Themenschwerpunktes, welcher nicht direkt die Nachhaltigkeit, sondern 

die Kostenreduzierung anstrebt, abgelehnt, (siehe Anhang A.10). 

462



Das Jahr 2013 begann mit zwei sehr aufschlussreichen Treffen: Während bei einem Treffen mit dem 

HPI bzw. SAP die Technologie SAP HANA sowie die Fehlerkettenerkennung im Vordergrund standen, 

erlangte die Teilgruppe im Gespräch mit Olaf Kleesch von der Availon GmbH neue Erkenntnisse 

im Bereich der Windenergie. 

Am 24.01.2013 fand ein Treffen mit Dr. Felix Salfner von SAP sowie Henning Schmitz vom HPI statt 

(siehe Anhang A.11). Hierbei wurden einerseits generelle Neuerungen seitens SAP HANA präsentiert, 

andererseits stellte Felix Salfner das Thema Fehlerkettenerkennung genauer dar. Unter dem Oberbegriff 

„Proactive Failure Avoidance, Recovery and Maintenance“ (PFARM) fasste er Methoden wie 

beispielsweise Monitoring, Diagnose, Vorhersage, Wiederherstellung und präventive Wartung, die 

sich mit der proaktiven Fehlerbehandlung beschäftigen, zusammen. Wenn das System im Vorhinein 

eine kritische Situation erkennt, können entweder vorab Gegenmaßnahmen eingeleitet werden, damit 

der Fehler nicht eintreten kann oder Reparaturmechanismen vorbereitet werden, damit der anstehende 

Fehler schnell behoben werden kann. Im Falle der Windenergieanlagen kann beispielsweise proaktiv 

die WEA abgeschaltet oder ein Technikereinsatz geplant werden. 

Eine Woche später, am 31.01.2013, traf die Projektgruppe Herrn Olaf Kleesch von der Availon 

GmbH, einem Serviceanbieter für WEA (siehe Anhang A.12). Hierbei stellte sich heraus, dass viele 

ältere WEA noch über Modemverbindungen verfügen und daher standardmäßig alle WEA zehnminütige 

Mittelwerte versenden. Die Hauptbegründung der Projektgruppe für die Nutzung von SAP HANA 

mit Sekundendaten ist somit nicht möglich. Bisher setzt Availon lediglich statische Auswertungen ein, 

daher ist vor allem der Bereich Data Mining für das Unternehmen von Interesse. Olaf Kleesch verspricht, 

der Teilgruppe baldmöglichst reale 10-Minuten-Daten zur Verfügung zu stellen. 

Für eine allgemeine Diskussion des Themas Windenergie nahm die Teilgruppe am 13.02.2013 am 

Wind Energy Workshop veranstaltet vom Center for Environment and Sustainability (COAST) der 

Universität Oldenburg sowie dem Hansa Energy Corridor (hec) teil (siehe Anhang A.13). Hierbei berichteten 

Mitarbeiter des Windenergie Teams der BTC, dass auch sie versucht hätten, die proaktive 

Wartung von WEA zu ermöglichen, dies jedoch daran gescheitert sei, dass jede Turbine individuell ist 

und der Algorithmus somit für jede Turbine angepasst werden muss. 

Wie am 31.01.2013 besprochen, konnte die Teilgruppe am 26.02.2013 anonymisierte Realdaten von 

der Availon GmbH entgegen nehmen. Um die Daten in SAP HANA zu laden, mussten die Attribute 

wesentlich erweitert werden. Anschließend wurden auf die Daten prototypisch Data Mining Methoden 

angewendet, aufgrund der Kürze der restlichen Projektlaufzeit konnten dabei jedoch keine wesentlichen 

Erkenntnisse erzielt werden. Ein Zugang zu SAP BO, der am 11.03.2013 ermöglicht wurde, 

wurde ebenfalls nicht mehr weiterverfolgt. Beide Bereiche sind für zukünftige Projekte jedoch sehr 

vielversprechend. 

463



3 Ergebnisdarstellung & Technische Dokumentation 


Für die Windpark-Maintenance-Plattform ist eine Architektur mit den verschieden eingesetzten Softwarelösungen 

und deren Verbindungen untereinander modelliert worden. Konzeptuell ist diese im 

DV-Konzept detailliert erläutert und im weiteren Verlauf des Projekts einer geringfügigen Änderung 

unterzogen worden, welche im Folgenden begründet werden. 

Die finale Architektur der Plattform ist in Abbildung 3.1 aufgeführt und nach wie vor in die drei Ebenen 

ETL, Datenhaltung und Data-Mining sowie Reporting unterteilt. 

Abbildung 3.1: Architektur 

Innerhalb der ETL-Ebene ist die Erfassung eines kontinuierlichen Datenstroms von verschiedenen 

WEA, aufgrund des fehlenden konzeptionellen Rahmens, ausgegraut worden. Weiterhin ist das SAP 

HANA Studio als Importschnittstelle ergänzt worden, da für Pentaho Data Integration CE aktuell keine 

SAP HANA Schnittstelle verfügbar ist. In der Datenhaltung und Data Mining Ebene ist die Rserve 

Applikation nachgetragen worden, weil diese die Kommunikation zwischen dem SAP HANA System 

und R steuert. Abschließend wurde SAP BO, aufgrund der nicht verfügbaren Lizenzen während der 

Realisierungsphase ebenfalls ausgegraut. 

464



3.2 Datenbankmodell 

Um ein allgemeingültiges Datenmodell zu erstellen, welches leicht erweiterbar ist und den Anforderungen 

der Plattform genügt, ist die im folgenden Kapitel beschriebene Struktur im SAP HANA System, 

spaltenbasierend umgesetzt worden. Die Attribute, die Datentypen und die jeweilige Bedeutung, 

der einzelnen Tabellen sind im Kapitel 3.2.2 beschrieben. Im letzten Unterkapitel befindet sich eine 

Übersicht über den Umfang der sich im System befindenden Daten. 

3.2.1 Struktur 

Die Struktur des Datenbankmodells, welches bereits im DV-Konzepte beschrieben und erarbeitet wurde, 

wurde unverändert übernommen. Daher umfasst das Datenmodell im SAP HANA System folgende 

acht Haupttabellen: Wetterdaten, Windpark, Anlage, Anlagentyp, Wartung, Betrifft_Wartung_Bauteil, 

Bauteil und Sensordaten. Die einzelnen Tabellen sind, wie auf dem logischen 

Datenmodell auf Abbildung 3.2 zu sehen, miteinander verbunden. So können z. B. mehrere Anbieter 

von Wetterdaten einem bestimmten Windpark zugeordnet werden, welcher sich in die einzelnen Anlagen 

mit den verschiedenen Sensoren zerteilen lässt. Die Struktur des Datenmodells wurde bewusst 

minimalistisch gehalten, um nur für die Wartung nötige Daten zu speichern und zu analysieren. 

Wetterdaten 

Wartung 

von bauteil 

Betrifft_Wartung_Bauteil 

betrifft 

Bauteil 

gehören zu 

von 

Windpark 

gehört zu 

Anlage 

hat 

Sensordaten 

gehört zu 

Anlagentyp 

Abbildung 3.2: Logisches Datenmodell 

465



3.2.2 Beschreibung der Tupel 

Die Tupel der verschiedenen Tabellen wurden anhand der Daten von ForWind und der Masterarbeit 

von Oliver Norkus erstellt und anschließend mit Hilfe der Daten von der Availon GmbH erweitert. 

In den folgenden Tabellen sind alle Tupel der einzelnen Tabellen inklusive der jeweiligen Datentypen 

und einer Beschreibung aufgelistet, die vor Erhalt und Analyse der Daten von der Availon GmbH 

bekannt waren. Die zusätzlichen Tupel, die anhand der Daten der Availon GmbH erstellt wurden, sind 

in Tabelle 3.9 aufgeführt und beschrieben. Insgesamt umfasst die Sensordaten-Tabelle des Datenmodells 

60 verschiedene Sensoren. Das gesamte Modell ist im Anhang A.14 aufgeführt. 

Tabelle Wetterdaten 

Attributname Datentyp Beschreibung 

Anbieter_ID Integer ID 

Wetterdaten_Timestamp Timestamp Zeitstempel 

Ort Char Ort 

Windgeschwindigkeit Double Windgeschwindigkeit in m/s 

Luftfeuchtigkeit Double Relative Luftfeuchtigkeit in % 

Wellenhoehe Double Höhe der Wellen in Meter 

Temperatur Double Temperatur in Grad Celsius (°C) 

Luftdruck Double Luftdruck in kPa 

Niederschlag Double Menge des Regens in mm pro qm 

Windrichtung Double Richtung des Windes in Grad 

Wahrscheinlichkeit Double Wahrscheinlichkeit mit der die Vorhersage 

eintrifft in % 

WindparkWindpark_ID Integer Fremdschlüssel 

Tabelle Windpark 

Tabelle 3.1: Tupel Tabelle Wetterdaten 


Windpark_ID Integer ID 

Bezeichnung Char Name des Windparks 

Betreiber Char Name des Betreibers 

Wartungsdienst Char Name des Wartungsdienst 

Anzahl_WEA Integer Zahl der Windenergieanlagen 

Groesse Double Ausmaße in qm 

Standort Char Bezeichnung des Standorts 

Laengengrad Double Längengrad des Standortes 

466



Breitengrad Double Breitengrad des Standortes 

Datum_der_Genehmigung Date Tag der Genehmigung des Windparks 

Gesamt_Soll_Leistung Double Leistung des Windparks 

Wassertiefe Double Durchschnittliche Wassertiefe in Meter 

Tabelle 3.2: Tupel Tabelle Windpark 

Tabelle Anlage 


Anlagen_ID Interger ID 

Bezeichnung Char Name der einzelnen Anlage 

Standort Char Standortbezeichnung der Anlage 

WetterdatenAnbieter_ID Integer Fremdschlüssel 

WetterdatenTimestamp Timestamp Fremdschlüssel 

AnlagentypAnlagentyp_ID Integer Fremdschlüssel 

WindparkWindpark_ID Integer Fremdschlüssel 

Tabelle 3.3: Tupel Tabelle Anlage 

Tabelle Anlagentyp 


Anlagentyp_ID Integer ID 

Bezeichnung Char Bezeichnung des Anlagentyps 

Hoehe Double Höhe in Metern 

Leistung Double Soll-Leistung des Anlagentyps 

Rotorblattlaenge Double Länge der Rotorblätter in Metern 

Hersteller Char Name des Herstellers 

Anzahl_der_Rotorblaetter Tinyint Anzahl der Rotorblätter 

Einschaltgeschwindigkeit Double Einschaltgeschwindigkeit in m/s 

Abschaltwindgeschwindigkeit Double Abschaltwindgeschwindigkeit in m/s 

Tabelle 3.4: Tupel Tabelle Anlagentyp 

Tabelle Wartung 


Wartungs_ID Integer ID 

Von Timestamp Datum mit Uhrzeit 

Bis Timestamp Datum mit Uhrzeit 

AnlageAnlagen_ID Integer Fremdschlüssel 

AnlageWindparkWindpark_ID Integer Fremdschlüssel 

AnlageWindparkWindpark_ID2 Integer Fremdschlüssel 

467





Tabelle Betrifft_Wartung_Bauteil 

Tabelle 3.5: Tupel Tabelle Wartung 


Grund Char Grund der Wartung 

WartungWartungs_ID Integer Fremdschlüssel 

BauteilBauteil_ID Integer Fremdschlüssel 

Tabelle Bauteil 

Tabelle 3.6: Tupel Tabelle Betrifft_Wartung_Bauteil 


Bauteil_ID Integer ID 

Bezeichnung Char Technische Bezeichnung des Bauteils 

Tabelle Sensordaten 

Tabelle 3.7: Tupel Tabelle Bauteil 


Sensor_ID Integer ID 

Sensor_Timestamp Timestamp Timestamp aus Unix 

Windgeschwindigkeit Double Windgeschwindigkeit m/s 

Betriebsstatus Tinyint Aktueller Status der Anlage 

Leistungsabgabe Double Aktuelle Leistungsabgabe der Anlage in MW/h 

Windrichtung Double Windrichtung in Grad 

Blatteinstellwinkel Double Einstellwinkel der Rotorblätter in Grad 

Aussentemperatur Double Außentemperatur Grad Celsius (°C) 

Luftdichte Double Dichte der Umgebungsluft 

Luftfeuchtigkeit Double Relative Luftfeuchtigkeit in % 

Schwingung Double Schwingungen der Anlage 

Turbine_Oelstand Double Ölstand der Turbine 

Turbine_Oeldruck Double Öldruck der Turbine 

Turbine_Oeltemperatur Double Temperatur des Öls in der Turbine in Grad Celsius 

(°C) 

Turbine_Spannung Double Elektrische Spannung der Turbine 

Turbine_Stromstaerke Double Stromstärke der Turbine in Ampere 

Turbine_Frequenz Double Frequenz der Turbine in Herz 

Generator_Temperatur Double Temperatur des Generators in Grad Celsius (°C) 

468



Generator_Drehzahl Double Drehzahl des Generators in Umdrehung pro 

Minute 

Generator_Oelstand Double Ölstand des Generators 

Generator_Oeltemperatur Double Temperatur des Öls im Generator in Grad Celsius 

(°C) 

Generator_Oeldruck Double Druck des Öls im Generator 

Getriebe_Oelstand Double Ölstand des Getriebes 

Getriebe_Oeltemperatur Double Temperatur des Öls im Getriebe in Grad Celsius 

(°C) 

Getriebe_Oeldruck Double Druck des Öls im Getriebe 

Fulldate Timestamp Datum im SAP Format 

AnlageAnlagen_ID Integer Fremdschlüssel 

AnlageWindparkWindpark_ID Integer Fremdschlüssel 




Tabelle Sensordaten nach Availon 

Attributname 

Tabelle 3.8: Tupel Tabelle Sensordaten 

Datentyp Beschreibung 

Turbine_Name Char Name der Turbine 

Leistungs_Mittl Double Durchschnittliche Leistungsabgabe (MW/h) 

Blindleistung_Kapazitiv Double Leistung, die nicht in das Stromnetz eingespeist werden 

kann. 

Gondelposition Double Position der Gondel (grad °) 

Temp_Gondel Double Gemessene Temperatur bei der Gondel (C°) 

Temp_HSS_Generatorseite Double Gemessene Temperatur des Generators (C°) 

Temp_Wellenlager Double Gemessene Temperatur beim Wellenlager (C°) 

Temp_Rotorlager Double Gemessene Temperatur des Rotorlager (C°) 

Temp_Getriebeoelsumpf Double Temperatur des Getriebeölsumpfs (C°) 

Temp_Getriebelager_A Double Gemessene Temperatur des Getriebelager A (C°) 

Temp_Getriebelager_B Double Gemessene Temperatur des Getriebelager (C°) 

Temp_Generator_1 Double Gemessene Temperatur des Generator 1 (C°) 

Temp_Generator_2 Double Gemessene Temperatur des Generator 2 (C°) 

Temp_Generator_Kuehlluft Double Gemessene Temperatur der Kühl-Luft des Generators 

(C°) 

Temp_Generatorlager_A Double Gemessene Temperatur des Generatorlagers A (C°) 

Temp_Generatorlager_B Double Gemessene Temperatur des Generatorlagers B (C°) 

Temp_Transformator_Phase_1 Double 

Gemessene Temperatur der Phase 1 des Transforma- 

469





tors (C°) 

Gemessene Temperatur der Phase 1 des Transformators 

(C°) 

Gemessene Temperatur der Phase 1 des Transformators 

(C°) 

Blattwinkel_1 Double Blatteinstellwinkel für das erste Rotorblatt 

Blattwinkel_2 Double Blatteinstellwinkel für das zweite Rotorblatt 

Blattwinkel_3 Double Blatteinstellwinkel für das dritte Rotorblatt 

Cosphi Double Wirkfaktor 

Cosphi_soll Double Wirkfaktor soll 

Spannung_L1R Double Spannung beim L1R in Volt 

Spannung_L2S Double Spannung beim L2S in Volt 

Spannung_L3T Double Spannung beim L3T in Volt 

Generatorfrequenz Double Frequenz des Generators in Herz 

Generatordrehzahl_Mittl Double Durchschnittliche Generatordrehzahl 

Rotordrehzahl_Mittl Double Durchschnittliche Rotordrehzahl 

Leistungsschalter_Schaltspiele Double Anzahl an Schaltzyklen des Leistungsschalter 

Hydraulischer_Druck Double Druck des hydraulische-Systems (bar) 

Leistungsreduzierung Double Grad der Leistungsreduzierung 

Metallpartikel Double Anzahl 

Tabelle 3.9: Zusätzliche Tupel durch Availon-Daten 

3.2.3 Bestandsaufnahme 

Die Datenbank bzw. die verschiedenen Tabellen enthalten Daten aus verschiedenen Quellen, wie 

ForWind, der Availon GmbH, unterschiedlichen Anbietern für Wetterdaten und dem Datengenerator. 

Ein Überblick über die vorhandene Datenmenge ist, unterteilet nach den verschiedenen Anlagen, denen 

sie zugeordnet sind, in Abbildung 3.3 zu sehen. Die Tabelle enthält zu den Anlagen 1 bis 11 je 

über 11 Millionen Datensätze. Während die Anlage mit der ID 30 nur ca. 150.000 Datensätze enthält. 

Die unterschiedlichen Datenmengen entstehen vor allem durch die Granularität mit der die Daten aufgenommen 

wurden. So stammen die Daten für die Anlagen 30 und 31 von der Availon GmbH und 

wurden mit einem 10-minütigem Abstand aufgenommen, während die Daten der Anlagen 1 bis 12 von 

ForWind stammen und im nahezu Sekundentakt gespeichert wurden. Dabei ist die Zeitspanne der 

Daten von Availon (12Monate) um ca. 30% größer als bei den Daten von ForWind (8 Monate). 

470



Abbildung 3.3: Übersicht Datensätze der Tabelle SENSORDATEN 

3.3 ETL-Prozesse 

Im Zuge des Projektverlaufs (siehe Kapitel 2) sind der Projektgruppe verrauschte WEA-Sensordaten 

von Seiten ForWind und anonymisierte Realdaten von der Availon GmbH zur Verfügung gestellt 

worden. Im weiteren Verlauf werden die einzelnen Phasen der jeweiligen Daten innerhalb des ETL- 

Prozesses aus technischer Sicht beschrieben. Eine Anwenderbeschreibung in Form eines Benutzerhandbuches 

des ETL-Prozesses für die ForWind Daten ist in Kapitel 4.2 zu finden. 

3.3.1 Daten von ForWind 

Anmerkung: Die im Folgenden beschriebenen Projektdateien sind in der beigefügten DVD in dem 

Ordner „01_ForWind_Phentaho“ zu finden. Dazu zählen die Dateien „ForWind_ Transformation.ktr“, 

„ForWind_Job_Transformation.kjb“ und „ForWind_Nummerierung_Alle.ktr“. Des Weiteren 

befinden sich die ForWind Daten im Ordner „ForWind_WEA_Daten“. 

Im Rahmen des ETL-Prozesses, ist eine Analyse sowie eine anschließend Extraktion und Transformation 

der von ForWind gestellten Daten mit Hilfe der Software Pentaho Data Integration CE durchgeführt 

worden. Dieses Vorgehen hat zum Ziel gehabt, die im DV-Konzept beschriebenen Kriterien zur 

Datenqualität zu erfüllen und einen fehlerfreien Import der Daten in das SAP HANA System zu ermöglichen. 

471



Analyse der Daten 

Die Übergabe der Daten ist in Form einer DVD erfolgt mit insgesamt 5,5 GB Daten. Diese haben aus 

72 Dateien im Rdata Format und einer Beschreibung der Daten bestanden. Der Beschreibung konnte 

entnommen werden, dass es sich um Sekundendaten von zwölf WEA mit sechs erfassten Attributen, in 

einem Zeitraum von ca. acht Monaten handelt. Die Definition der Attribute ist, wie in Tabelle 3.10 

aufgeführt, vorgenommen worden. 

Name Beschreibung laut ForWind Zielformat 

A is the wind direction in º (0º ~ North, 90º ~ East) Windrichtung in Grad 

G is the rotational speed of the generator in RPM Generator Drehzahl in RPM 

P 

is the electrical power output normalized to the 

rated power output 

T is the timestamp (Unix time) Unix Timestamp 

Elektrische Leistungsabgabe in 

kW 

U is the wind speed measured on the nacelle in m/s Windgeschwindigkeit in m/s 

S is the WEC status WEC (Betriebsstatus) 

Tabelle 3.10: Attribute der ForWind Daten 

Die jeweiligen Daten der Attribute sind wie folgt, jeweils pro WEA, in einer einzelnen Rdata Datei 

überreicht worden. 

Randomized_1_a.Rdata ............ RDATA-Datei ..................... 114.287 KB 

Randomized_1_g.Rdata ............ RDATA-Datei ..................... 101.813 KB 

Randomized_1_p.Rdata ............ RDATA-Datei ..................... 101.077 KB 

Randomized_1_t.Rdata ............ RDATA-Datei ..................... 15.607 KB 

Randomized_1_u.Rdata ............ RDATA-Datei ..................... 38.278 KB 

Randomized_1_s.Rdata ............ RDATA-Datei ..................... 114.726 KB 

Randomized_2_a.Rdata ............ RDATA-Datei ..................... 115.182 KB 

…. 

… … 

Weiterhin ist beschrieben worden, dass die Daten mit einer Frequenz von ca. 1Hz gemessen und je 

Attribut ca. 20,10^6 Datenpunkte erfasst worden sind. Hierbei haben ca. 25% der Datenpunkte aufgrund 

von technischen Problemen gefehlt, wodurch ca. 15,10^6 Datenpunkte vollständig gewesen 

sind. 

Extraktion der Rdata-Dateien 

Um eine Transformation der Daten in Pentaho Data Integration CE zu ermöglichen, sind die Daten 

zunächst in ein kompatibles Dateiformat extrahiert worden. Das Rdata Format ist ein, vom Data Mining 

Tool R genutztes, Format zur Datenhaltung und nur aus R direkt aufrufbar. Daher ist zunächst R 

installiert und folgendes Script ausgeführt worden, um die Daten als ASCII-Textdatei zu extrahieren. 

# set the folder where the Rdata files are located 

data_folder="/folder/Rdata" 

# set the folder where the ASCII files will be saved 

472



ASCII_folder="/folder/ASCII" 

for(m in 1:12) 

{ 

print(m) 

load(paste(data_folder,"/Randomized_",m,"_a.Rdata",sep="")) 

load(paste(data_folder,"/Randomized_",m,"_g.Rdata",sep="")) 

load(paste(data_folder,"/Randomized_",m,"_p.Rdata",sep="")) 

load(paste(data_folder,"/Randomized_",m,"_s.Rdata",sep="")) 

load(paste(data_folder,"/Randomized_",m,"_t.Rdata",sep="")) 

load(paste(data_folder,"/Randomized_",m,"_u.Rdata",sep="")) 

write.table(a,file=paste(ASCII_folder,"/Randomized_",m,"_a.txt",sep=""),dec 

=".",row.names=FALSE,col.names=FALSE) 

write.table(g,file=paste(ASCII_folder,"/Randomized_",m,"_g.txt",sep=""),dec 


write.table(p,file=paste(ASCII_folder,"/Randomized_",m,"_p.txt",sep=""),dec 


write.table(s,file=paste(ASCII_folder,"/Randomized_",m,"_s.txt",sep=""),dec 


write.table(t,file=paste(ASCII_folder,"/Randomized_",m,"_t.txt",sep=""),dec 


write.table(u,file=paste(ASCII_folder,"/Randomized_",m,"_u.txt",sep=""),dec 


} 

Nach erfolgreicher Ausführung des Scripts sind alle Rdata Dateien in 72 Textdateien umgewandelt 

worden, dabei hat sich das Dateivolumen aufgrund der fehlenden Komprimierung von 5.5GB auf 

15.9GB erhöht. 

Randomized_1_a.txt .............. Textdokument .................... 290.232 KB 

Randomized_1_g.txt .............. Textdokument .................... 262.543 KB 

Randomized_1_p.txt .............. Textdokument .................... 275.804 KB 

Randomized_1_s.txt .............. Textdokument .................... 81.898 KB 

Randomized_1_t.txt .............. Textdokument .................... 201.885 KB 

Randomized_1_u.txt .............. Textdokument .................... 289.879 KB 

Transformation der Daten 

Um die bestehenden Daten in das SAP HANA System importieren zu können, mussten folgende Faktoren 

durch die Transformation in Pentaho Data Integration CE erfüllt werden: 

1. Ausgabe aller Daten in einer Textdatei, dessen Werte per Semikolon getrennt sind. 

2. Ein einheitlich beginnender Timestamp für alle 12 WEA. 

3. Löschung der kompletten Datensätze, welche Null oder 0 Werte enthalten. 

4. Erweiterung der beschriebenen Attribute, um die fehlenden Attribute der SENSORDATEN Datenbanktabelle. 

5. Setzen der jeweiligen Anlagennummer. 

6. Durchgängige Nummerierung über alle Datensätze hinweg. 

473



7. Splittung der finalen Ausgabedatei in 400MB Pakete, um eventuelle Timeouts während des 

Imports in SAP HANA zu vermeiden. 

Die Realisierung dieser Faktoren hat sich dabei in drei Phasen unterteilt: Der Transformationskette, 

die Ausführung aller Transformationen mit Hilfe eines Jobs und die anschließende Zusammenführung 

der jeweiligen Dateien. 

Pentaho Data Integration CE – Transformationskette 

Die realisierte Transformationskette wird in Abbildung 3.4 dargestellt und dessen Vorgänge in Tabelle 

3.11 näher erläutert. 

474 

Abbildung 3.4: Pentaho Data Integration CE - Transformationskette 

Vorgang Bezeichnung Funktion Beschreibung 

1 Einlesen_...._Txt Text file 

input 

2 Timestamp 1-5 Get Value 

From 

Sequence 

Einlesen der sechs Textdateien, unter der Verwendung 

einer Umgebungsvariablen für die WEA 

Nummer. Diese muss bei Aufruf der Transformation 

gesetzt werden und vermeidet die jeweilige 

Änderung des Dateinamens je Transformation. 

Beispiel: 

Randomized_${sensor}_a.txt 

Inkrementelle Nummerierung der Datensätze mit 

einem neuen Timestamp. Dieser dient als Voraussetzung 

für die anschließende Zusammenführung. 

3 Sortieren 1-5 Sort rows Sortierung der Datensätze, welche von Seiten Pentaho 

Data Integration CE verlangt wird um den



4 Zusammenführen 1-4 Merge 

Join 

5 Nummerierung entfernen 

Select / 

Rename 

values 

anschließenden Merge Join auszuführen. 

Zusammenführung aller Datensätze anhand des 

zuvor generierten Timestamp auf eine Datenbasis. 

Löschung der Timestamp Duplikate, sodass nur 

noch ein Timestamp vorhanden ist. 

6 Sortieren Final Sort rows Erneute Sortierung der Datensätze anhand des 

Timestamp, dieses dient als Sicherheit um Fehler 

in den Folgeschritten auf Grund einer fehlerhaften 

Sortierung zu vermeiden. 

7 Null / 0 Filter Filter 

rows 

Löschung der kompletten Datensätze, welche Null 

oder 0 Werte enthalten. Die Filterung erfolgt auf 

Basis von Bedingungen bspw.: (Windrichtung 

CONTAINS [NA] OR Windrichtung = [0]) 

Alle Werte, welche diese Bedingung nicht erfüllen, 

werden an Vorgang 9 weitergegeben und sonst 

an Vorgang 8. 

8 Papierkorb Dummy Dient als Dummy um die zuvor gefilterten Null 

oder 0 Werte aufzunehmen bzw. zu löschen. 

9 Tabelle erweitern Add 

constant 

values 

10 Nummerierung Final Get Value 

From 

Sequence 

11 Anlagen ID Setzen Replace in 

String 

12 Datei Output Text file 

output 

Pentaho Data Integration CE – Job 

Erweiterung der Datensätze um alle aktuell im 

Datenmodell enthaltene Attribute bspw. Anlagen_ID, 

Blatteinstellwinkel. Diese Werte werden 

mit dem Wert 0 gefüllt, somit enthalten die Datensätze 

nach dem späteren Import in das SAP 

HANA System keine Null Werte. Eventuelle Fehler 

durch Null Werte in z.B. Reports werden damit 

im Vorfeld vermieden. 

Finale inkrementelle Nummerierung der Datensätze. 

Setzen der aktuellen Anlagen_ID in allen Datenzeilen, 

diese wird der Umgebungsvariable ${sensor} 

entnommen. 

Export der Daten in eine Textdatei. Die einzelnen 

Werte werden dabei durch Semikolons getrennt. 

Tabelle 3.11: Erläuterung der Transformationskette 

Insbesondere die große Datenmenge führte zu einer langen Bearbeitungszeit der beschriebenen Transformationskette 

je WEA. Um diese auch unbeaufsichtigt durchzuführen, ist ein Job angelegt worden, 

mit dessen Hilfe alle Transformationen hintereinander ausgeführt werden können, (siehe Abbildung 

3.5). Die dort aufgeführten Transformationen rufen jeweils die beschriebene Transformationskette auf 

und übergeben die zu transformierende WEA Nummer, in diesem Fall die Nummern 1 bis 12. Weiterhin 

werden insgesamt drei E-Mails über den aktuellen Status des Jobs an die hinterlegte E-Mailadresse 

versendet. 

475



Abbildung 3.5: Pentaho Data Integration CE – Job 

Nach erfolgter Durchführung des Jobs ergibt sich folgende Datenstruktur: 

file_sensor_1.txt ............... Textdokument ....................... ~1.7 GB 









file_sensor_10.txt .............. Textdokument ....................... ~1.7 GB 



Pentaho Data Integration CE – Zusammenführung 

Abschließend wurden die aufgeführten Textdateien file_sensor_1.txt bis file_sensor_12.txt zusammengeführt 

und durch eine durchgängige, inkrementelle Nummerierung der Sensor_ID ergänzt, (siehe 

Abbildung 3.6). Der Export der Daten ist mit Hilfe einer CSV-Datei realisiert worden, welche in mehrere 

kleinere 400MB Pakete gesplittet worden ist. 

Abbildung 3.6: Pentaho Data Integration CE – Zusammenführung 

Die finale Dateistruktur ist wie folgt aufgebaut worden und hat aus insgesamt 45 Dateien bestanden. 

Datensatz_ID2;timestamp;Windgeschwindigkeit;Betriebsstatus;Leistungsabgabe; 

Windrichtung;Blatteinstellwinkel;Aussentemperatur;Luftdichte; 

Luftfeuchtigkeit;Schwingungssensoren;Turbine_Oelstand;Turbine_Oeldruck; 

476



Turbine_Oeltemperatur;Turbine_Spannng;Turbine_Stromstaerke; 

Turbine_Frequenz;Generator_Temperatur;Generator_Drehzahl; 

Generator_Oeldruck;Generator_Oelstand;Generator_Oeltemperatur; 

Getriebe_Oeldruck;Getriebe_Oelstand;Getriebe_Oeltemperatur;Anlagen_ID2 

1; 1325372402; 10.983094885; 24; 0.071375474; 9.838724343; 0; 0; 0; 0; 0; 

0; 0; 0; 0; 0; 0; 0; 2.593182187; 0; 0; 0; 0; 0; 0; 1 

2; 1325372404; 10.489847487; 26; 0.031822627; 355.985781837; 0; 0; 0; 0; 0; 

0; 0; 0; 0; 0; 0; 0; 11.800325198; 0; 0; 0; 0; 0; 0; 1 

… 

Die Dateien sind anschließende mit Hilfe des SAP HANA Studio in das SAP HANA System importiert 

worden. Eine Beschreibung des Importvorgangs ist in Kapitel 4.2 des Benutzerhandbuches zu 

finden. 

3.3.2 Daten von Availon 

Anmerkung: Die im Folgenden beschriebenen Daten sind in der beigefügten DVD in dem Ordner 

„05_Daten_Availon“ zu finden. 

Im Rahmen dieses ETL-Prozesses ist eine Analyse und eine geringfügige Anpassung der Daten von 

der Availon GmbH vorgenommen worden. Da es sich bei den Daten um einen direkten Datenbankexport 

handelt, ist auf eine Extraktion und Transformation mit Hilfe der Software Pentaho Data Integration 

CE verzichtet. worden 

Analyse der Daten 

Die Übergabe der anonymisierten Realdaten ist in Form einer CD erfolgt, mit insgesamt 44 MB Daten. 

Diese haben aus zwei CSV-Dateien mit der Bezeichnung Daten WP GE und Daten WP Vestas 

bestanden. Die CSV-Dateien sind von der Struktur her gleich aufgebaut gewesen, haben jedoch Unterschiede 

in der Anzahl der Attribute sowie des erfassten Zeitraums aufgewiesen. 

Die Datei Daten WP GE beinhaltet 45 Attribute (siehe Tabelle 3.12), dessen Werte aus einem Zeitraum 

vom 01.01.2012 bis zum 31.12.2012 gestammt haben. Dagegen hat die Datei Daten WP Vestas 

36 Attribute (siehe Tabelle 3.13) in einem kürzeren Zeitraum vom 01.03.2012 bis zum 31.12.2012 

aufgewiesen. Alle Werte sind dabei in einem Fünfminutentakt erfasst worden. 

Attribute der Datei Daten WP GE 

WEA Zeitstempel Zeitstempel Original 

Windrichtung [°] 

Windgeschwindigkeit mittl. Leistung mittl. [kW] 

[m/s] 

Blindleistung kapazitiv [kvar] Gondelposition [°] Temp. Gondel [°C] 

Temp. Außen [°C] Temp. HSS Generatorseite [°C] Temp. Wellenlager [°C] 

Temp. Rotorlager [°C] Temp. Getriebeölsumpf [°C] Temp. Getriebelager A [°C] 

Temp. Getriebelager B [°C] Temp. Generator 1 [°C] Temp. Generator 2 [°C] 

Temp. Gen. Kühlluft [°C] Temp. Generatorlager A [°C] Temp. Generatorlager B [°C] 

Temp. Transformator Phase 1 Temp. Transformator Phase 2 Temp. Transformator Phase 3 

477



[°C] [°C] [°C] 

Blattwinkel 1 [°] Blattwinkel 2 [°] Blattwinkel 3 [°] 

Blattwinkel 1 Soll [°] Blattwinkel 2 Soll [°] Blattwinkel 3 Soll [°] 

CosPhi CosPhi soll Spannung L1R [V] 

Spannung L2S [V] Spannung L3T [V] Strom L1R [A] 

Strom L2S [A] Strom L3T [A] Generatorfrequenz [Hz] 

Generatordrehzahl mittl. Rotordrehzahl mittl. [min-1] Leistungsschalter Schaltspiele 

[min-1] 

Hydraulischer Druck [bar] Leistungsreduzierung Metallpartikel 

Tabelle 3.12: Attribute Availon WP GE 

Attribute der Datei Daten WP Vestas 

WEA Zeitstempel Windrichtung [°] 

Windgeschwindigkeit min. 

[m/s] 

Windgeschwindigkeit mittl. 

[m/s] 

Windgeschwindigkeit max. 

[m/s] 

Leistung min. [kW] Leistung mittl. [kW] Leistung max. [kW] 

Produktionszähler Generator 1 Produktionszähler Generator 2 Bezugszähler [kWh] 

[kWh] 

[kWh] 

Betriebsstundenzähler [h] Gondelposition [°] Temp. Gondel [°C] 

Temp. Außen [°C] Temp. Generatorlager A [°C] Temp. Generatorlager B [°C] 

Blattwinkel 1 [°] Blattwinkel 2 [°] Blattwinkel 3 [°] 

CosPhi Spannung L1R [V] Spannung L2S [V] 

Spannung L3T [V] Strom L1R [A] Strom L2S [A] 

Strom L3T [A] Generatorfrequenz [Hz] Generatordrehzahl min. 

[min-1] 

Generatordrehzahl mittl. 

[min-1] 

Generatordrehzahl max. 

[min-1] 

Rotordrehzahl min. 

[min-1] 

Rotordrehzahl mittl. [min-1] Rotordrehzahl max. [min-1] Leistungsreduzierung 

Anpassung der Daten 

Tabelle 3.13: Attribute Availon WP Vestas 

Um die Daten in das SAP HANA System importieren zu können, ist zunächst das Datenmodell erweitert 

worden, (siehe Kapitel 3.2). Zusätzlich ist in jeder Datei eine Timestamp Spalte ergänzt worden. 

Der Timestamp lässt sich anhand des Zeitstempels (DD.MM.YYYY HH:MM) mit folgender Formel in 

Microsoft Excel errechnen. 

=( (“Zeitstempel”-25569)*86400)-3600 

Weiterführend sind mit Hilfe eines Texteditors, bspw. Notepad++, alle enthaltenden Kommas durch 

Punkte ersetzt worden. Andernfalls würde das SAP HANA Studio die jeweiligen Attribute, welche 

Kommas enthalten, nicht als Zahl sondern als Text erfassen. Ein Import aufgrund der inkompatiblen 

Datentypen wäre dementsprechend nicht möglich. 

Abschließend ist der Import der beiden Dateien mit Hilfe des SAP HANA Studios erfolgt. 

478



3.4 SWF Toolbox 

Anmerkung: Die im Folgenden beschriebenen Projektdateien sind in der beigefügten DVD, in dem 

Ordner „03_SWF_Toolbox_Source“, zu finden. 

Im nachfolgenden Kapitel wird die technische Struktur und die Realisierung der SWF Toolbox erläutert. 

Ergänzend ist im Kapitel 4.3 das Benutzerhandbuch zur SWF Toolbox zu finden, welches die 

Oberfläche der Software und dessen Bedienung beschreibt. Zur besseren Verständlichkeit der folgenden 

Abschnitte empfiehlt es sich, diese vor ab zu lesen. 

Ziel ist es gewesen, eine Software auf Basis der Programmiersprache Java in der Entwicklungsumgebung 

Eclipse IDE zu entwickeln, welche sowohl WEA-Daten generieren als auch einen kontinuierlichen 

Datenstrom bzw. -transfer dieser in das SAP HANA System simulieren soll. 

Auf Grundlage des im DV-Konzept beschriebenen Realisierungskonzepts zur Simulation eines Windparks, 

ist die Entwicklung der SWF Toolbox erfolgt. Es wurden alle beschriebenen Funktionen bzw. 

Anforderungen realisiert. Hierzu zählen die Funktionen Wetterdaten laden, WEA-Daten generieren 

und WEA-Daten übertragen sowie die Realisierung einer Benutzeroberfläche und die Integration einer 

VPN Verbindung. Des Weiteren ist insbesondere die Konfigurierbarkeit der zu generierenden Daten in 

einem umfangreicheren Rahmen realisiert worden. 

3.4.1 Unterstützende Software 

Während der Entwicklung ist folgende unterstützende Software verwendet worden: 

Name Version Beschreibung 

Jave JRE 7 Update 17 - 

Eclipse IDE for Java Developers 

Juno Service 

Release 1 

Entwicklungsumgebung für Java. 

Mercurial 2.3.1 Versionskontrollprogramm um eine verteilte 

Entwicklung zur ermöglichen. 

TortoiseHg 2.5 Grafische Oberfläche für Mercurial. 

SAP HANA Studio Revision 48 Administrationssoftware für das SAP HANA 

System. 

OpenVPN Client v1.0.3 VPN-Client zur Verbindung mit dem SAP HA- 

NA System. 

Tabelle 3.14: Unterstützende Software der SWF Toolbox 

479



3.4.2 Programmstruktur 

In diesem Kapitel erfolgt die Beschreibung der Programmstruktur der SWF Toolbox, dafür 

werden zunächst die Pakete beschrieben und deren Klassen aufgelistet. Danach erfolgt zur 

allgemeinen Übersicht eine funktionsorientierte Beschreibung des Klassenmodells. Abschließend 

wird ein Überblick über die verwendeten Java Bibliotheken gegeben. 

Paketstruktur 

Das Programm gliedert sich in 12 Pakete, (siehe Tabelle 3.15). Die Strukturierung der Pakete ist unter 

dem Gesichtspunkt der späteren Erweiterbarkeit des Programmes erfolgt. Aus diesem Grund beinhalten 

alle Pakete eine allgemeingültige Beschreibung, ungeachtet davon, dass diese vereinzelnd nur eine 

Klasse beinhalten. 

Paket Beschreibung Klassen 

data_streamer 

data_generator 

vpn_connector 

sql_statements 

main 

gui_layout 

gui_tools 

480 

Dieses Paket beinhaltet alle Klassen, welche 

zur Steuerung und Aufbereitung der 

zu übertragenden Daten an das SAP HA- 

NA System notwendig sind. 

Dieses Paket enthält Klassen, welche zum 

Laden, Speichern und Verarbeiten der 

Daten des Datengenerators benötigt werden. 

Dieses Paket enthält die benötigten Klassen, 

zum Aufbau einer VPN-Verbindung. 

Dieses Paket ist dafür zuständig, alle zum 

Einsatz kommenden SQL-Klassen aufzunehmen. 

In diesem Paket werden alle Klassen abgelegt, 

welche für den Programmstart 

notwendig sind. 

Die Klassen in diesem Paket beinhalten 

den Aufbau der Benutzeroberfläche. 

Dieses Paket umschließt alle Klassen für 

die Interaktion innerhalb der Benutzeroberfläche 

und dient als Ergänzung zu 

den Klassen im Paket gui_layout. 

Data_Streamer.class 

Data_Generator.class 

Data_Load_Weather.class 

Data_Save.class 

Data_Textfile_Output.class 

Start_Vpn.class 

Sql_Insert.class 

Sql_Select.class 

Init_Console.class 

Init_Logger.class 

Main.class 

JPanel_Data_Generator.class 

JPanel_Datastreamer.class 

Panel_Generated_Data.class 

JPanel_Status.class 

JPanel_Web_Browser.class 

JTree_Left_Content.class 

SWT_Main_Window.class 

JTable_Column_Adjuster 

JTable_Operations.class 

JTable_Row_Transfer_Handler 

JToolbar_Button 

JTree_Left_Action_Handler



sql_data_handling Dieses Paket beinhaltet Klassen, welche 

statische SQL-Interaktionen ausführen. 

data_tools 

file_handlings 

xml_handlings 

sql_connect 

Dieses Paket enthält Klassen zur Speicherung 

von internen Daten. 

Dieses Paket enthält die benötigten Klassen 

für den Dateiauswahl-Dialog. 

In diesem Paket werden alle Klassen für 

das Einlesen von XML-Dateien abgelegt. 

Diese Paket beinhaltet alle Klassen mit 

dessen Hilfe eine Datenbankverbindung 

aufgebaut wird. 

Tabelle 3.15: Paketstruktur der SWF Toolbox 

Get_Column_List_Sensor.class 

Two_Dimension_Arraylist.class 

File_Importer 

File_Soucre_Chooser.class 

File_Target_Chooser.class 

XML_Importer_JModel.class 

XML_Interface_Reorderable.class 

Jdbc_hana_connect.class 

Funktionsorientierte Klassenbeschreibung 

Das Programm untergliedert sich in folgende Hauptfunktionen: 

 

 

 

 

 

 

 

 

 

 

Programmaufruf 

Grafische Benutzeroberfläche erzeugen 

OpenVPN Client starten 

Datengenerator aufrufen 

XML-Konfiguration und Wetterdaten laden 

Daten generieren 

Generierte Daten speichern 

Daten-Streamer öffnen 

WEA-Übersicht und generierte Daten laden 

Datenübertragung starten 

Nachfolgend wird die Beschreibung dieser Funktionen anhand der verwendeten Klassen innerhalb des 

Funktionsszenarios und deren Beziehungen untereinander. Eine ausführliche Beschreibung der Funktionen 

ist im Quellcode dokumentiert. 

Des Weiteren wird auf die wiederholte Aufführung der Array-Klasse namens 

Two_Dimension_Arraylist (siehe Abbildung 3.7) zur programminternen Datenhaltung verzichtet. Diese 

wurde eingesetzt um dynamisch erweiterbare sowie zweidimensionale Arrays zu erzeugen und sind 

als Ersatz für die statischen Java-Arrays verwendet worden. 

481



Abbildung 3.7:Klassenmodell - „Two_Dimension_Arraylist“ 

Programmaufruf 

Abbildung 3.8: Klassenmodell - Programmaufruf 

Der Programmaufruf ist durch Aufruf der Klasse Main erfolgt. Diese ruft zunächst die Klassen 

Init_Logger und Init_Console auf. 

Die Init_Logger Klasse initialisiert die log4j Bibliothek, welche die Protokollierung der Programmereignisse 

übernimmt und sie in einer Textdatei im Ordner logs abspeichert. Weiterhin wird dessen hinterlegte 

Konfiguration in der Datei log4j-3.properties ausgelesen. Jene beschreibt wie die Protokollierungseinträge 

(Logs) aufgebaut werden sollen, bspw. den Aufbau der Zeitangabe zu Beginn jedes Eintrags. 

Im Folgenden ist ein beispielhafter Auszug aus der Log-Datei zusehen. 

482



2013-03-10 00:55:25,552 INFO [main] main.Init_Logger: Logger wird gestartet 

2013-03-10 00:55:25,553 DEBUG [main] main.Init_Logger: Meine Debug-Meldung 

2013-03-10 00:55:25,553 INFO [main] main.Init_Logger: Meine Info-Meldung 

2013-03-10 00:55:25,553 WARN [main] main.Init_Logger: Meine Warn-Meldung 

2013-03-10 00:55:25,554 ERROR [main] main.Init_Logger: Meine Error-Meldung 

2013-03-10 00:55:25,554 FATAL [main] main.Init_Logger: Meine Fatal-Meldung 

Je Programmaufruf oder nach einem Tag, wird jeweils eine neue Log-Datei angelegt und die alte 

Log-Datei mit Angabe des Datums separat abgespeichert. 

Die Init_Console initialisiert eine separate Konsole in einem eigenen Fenster, welches zunächst ausgeblendet 

wird. Die Konsole überschreibt dabei die Standard Java-Konsole und greift dessen Ausgaben 

ab. Das Einblenden der Konsole erfolgt im späteren Verlauf unter der Funktion Datenübertragung 

starten. 

Abschließend wird die Klasse SWT_Main_Window aufgerufen, welche die grafische Benutzeroberfläche 

erzeugt. 

Grafische Benutzeroberfläche erzeugen 

Abbildung 3.9: Klassenmodell - Grafische Benutzeroberfläche erzeugen 

Die Klasse SWT_Main_Window erzeugt unter Verwendung der Smart Widget Toolkit (SWT) Bibliothek 

die grafische Benutzeroberfläche. Ergänzend werden die Jgoodies Bibliotheken für das Oberflächendesign 

genutzt, (siehe Abbildung 3.10). 

483



Abbildung 3.10: SWF Toolbox - Grafische Oberfläche 

Die Benutzeroberfläche setzt sich grundlegend aus einem links liegenden TabbedPane (Punkt 1), einem 

breiteren rechten TabbedPane (Punkt 2) und einer oberhalb rahmenden Toolbar zusammen 

(Punkt 3). 

Im linken TabbedPane wird dauerhaft eine Liste der Funktionen in Form eines Tree angezeigt. Im 

rechten TabbedPane werden alle funktionsabhängigen Oberflächen in Form von neuen Registerkarten 

(im Folgenden als Tabs bezeichnet) angezeigt. 

Ferner erfolgt die Integration eines Webbrowser mit Hilfe der Klasse JPanel_Web_Browser im rechten 

TabbedPane, die Füllung des linken Tree durch die Klasse JTree_Left_Content und die Erzeugung 

der Verbinden Schaltfläche durch die Klasse JToolbar_Button Toolbar. 

Der Webbrowser ruft wiederum die HTML-Seite start.html im internen resources Ordner des Programmes 

auf. Die Funktionalitäten dieser Seite sind dem Benutzerhandbuch zu entnehmen. 

Abschließend wird unter Verwendung der Klasse JTree_Left_Action_Handler im linken Tree ein action 

handler hinterlegt, welcher durch einen Doppelmausklick die hinterlegten Funktionen Generator 

öffnen oder Streamer starten aufruft. 

484



OpenVPN starten 

Abbildung 3.11: Klassenmodell – OpenVPN starten 

Wird die Schaltfläche Verbinden (siehe Abbildung 3.10, Punkt 3) betätigt, so wird durch die Klasse 

SWT_Main_Window die Klasse Start_Vpn aufgerufen. Start_VPN startet anschließend die Anwendung 

OpenVPNPortable.exe, welche sich im Programmordner tools\OpenVPNPortable befindet. Diese ist 

für den Aufbau der VPN-Verbindung zum SAP HANA Netzwerk zuständig. 

Datengenerator aufrufen 

Abbildung 3.12: Klassenmodell - Datengenerator aufrufen 

485



Wird die Funktion Generator öffnen (siehe Abschnitt „Grafische Benutzeroberfläche erzeugen“) aufgerufen, 

erzeugt die Klasse JTree_Left_Action_Handler einen neuen Tab im rechten TabbedPane und 

initialisiert die Klasse JPanel_Data_Generator. 

Die Klasse JPanel_Data_Generator ruft wiederum die Klasse Get_Column_List_Sensor auf, welche 

eine JDBC-Verbindung unter Verwendung der Klasse Jdbc_hana_connect zum SAP HANA System 

aufbaut. Wurde die JDBC-Verbindung erfolgreich aufgebaut, werden alle verfügbaren Attributnamen 

der Datenbanktabelle SENSORDATEN abgefragt und an die Klasse JPanel_Data_Generator übergeben. 

Im Anschluss erfolgt der Aufruf der XML_Importer_JModel Klasse, durch die die Standard Konfigurationsdaten 

für den Datengenerator aus der Datei generator_config.xml im Programmordner extrahiert 

und an die Klasse JPanel_Data_Generator übergeben werden. 

Abschließend erfolgt die Erzeugung der Benutzeroberfläche für den Datengenerator durch die Klasse 

JPanel_Data_Generator im zuvor erzeugten Tab, (siehe Abbildung 3.13). 

Abbildung 3.13: SWF Toolbox - Grafische Oberfläche des Datengenerators 

Die Benutzeroberfläche des Datengenerators setzt sich aus einer, oberhalb liegenden, Schaltflächenleiste 

(Punkt 1), einem Bereich, in dem im späteren Verlauf die Wetterdatentabelle integriert wird 

486



(Punkt 2) und einer Fläche, in der die geladenen Konfigurationsdaten in Form einer Tabelle dargestellt 

werden (Punkt 3). 

Die Bereiche 2 und 3 sind dabei durch einen sogenannten Splitpane getrennt, welcher eine horizontale 

Größenänderung dieser durch den Benutzer ermöglicht. 

Die Attributnamen der Datenbanktabelle SENSORDATEN werden in einem Auswahlmenü direkt in 

den Tabellenzellen der ersten beiden Spalten, der Konfigurationstabelle hinterlegt. 

XML-Konfiguration und Wetterdaten laden 

Abbildung 3.14: Klassenmodell - XML-Konfiguration und Wetterdaten laden 

Durch Betätigen der Schaltflächen Wetterdaten laden oder XML Konfiguration öffnen, (siehe Abbildung 

3.13 Punkt 1) wird jeweils durch die Klasse JPanel_Data_Generator ein Dateiauswahldialog mit 

Hilfe der Klasse File_Source_Chooser hervorgerufen. 

Ist die Auswahl der jeweiligen Datei erfolgt, sind die Klassen Data_Load_Weather und File_Importer 

dafür zuständig, die Wetterdaten aus der Datei zu extrahieren und aufzubereiten. Dabei erfolgt unter 

anderem die Berechnung eines Timestamps aus den enthaltenen Zeitangaben in den Wetterdaten. Das 

Einspielen der XML-Konfiguration geschieht analog zum beschriebenen Vorgang unter Abschnitt 

„Datengenerator aufrufen“. 

Sind die jeweiligen Daten erfolgreich geladen, erfolgt die Ausgabe dieser in der Benutzeroberfläche 

innerhalb der dafür vorgesehenen Tabelle, (siehe Abbildung 3.13 Punkt 1 und 2) 

Weiterführende Informationen zur Struktur und Aufbau der Dateien sind dem Abschnitt „Ein- und 

Ausgabedaten“ sowie der Benutzerdokumentation zu entnehmen. 

487




Abbildung 3.15: Klassenmodell - Daten generieren 

Für die Generation der Daten wird die Schaltfläche Daten generieren betätigt, (siehe Abbildung 3.13 

Punkt 1). Daraufhin gibt die Klasse JPanel_Data_Generator die Konfigurationsdaten und Wetterdaten 

an die Klasse Data_Generator weiter. In dieser wird die Generierung der Daten und die anschließende 

Übergabe an die Klasse JPanel_Generated_Data durchgeführt. Resultierend wird ein neuer Tab im 

rechten TabbedPane erzeugt sowie eine Tabelle innerhalb dieses Tabs, in welcher die Daten ausgeben 

werden, (siehe Abbildung 3.16). Zusätzlich wird die Funktion „Generierte Daten speichern“ in Form 

einer Schaltfläche hinterlegt. 

Abbildung 3.16: SWF Toolbox - Grafische Oberfläche der generierten Daten 

488



Generierte Daten speichern 

Abbildung 3.17: Klassenmodell - Generierte Daten speichern 

Zur Speicherung der bereits generierten Daten, wird die dortige Schaltfläche Speichern betätigt. Resultierend 

veranlasst die Klasse JPanel_Generated_Data, die Daten an die Klasse Data_Save zu übergeben, 

welche wiederum die Daten für die Speicherung in einer Textdatei aufbereitet und an die Klasse 

File_Target_Chooser weiterleitet. 

Die Klasse File_Target_Chooser ruft einen Dateiauswahldialog auf, indem die Auswahl des Zielpfades 

der Textdatei durch den Benutzer erfolgt. Abschließend erzeugt die Klasse Data_Textfile_Output 

im Zielpfade die Textdatei und füllt sie mit den Daten. 

Daten-Streamer öffnen 

Abbildung 3.18: Klassenmodell - Daten-Streamer öffnen 

489



Wird die Funktion Streamer öffnen (siehe Abschnitt „Grafische Benutzeroberfläche erzeugen“) aufgerufen, 

erzeugt die Klasse JTree_Left_Action_Handler einen neuen Tab im rechten TabbedPane und 

initialisiert die Klasse JPanel_Datastreamer. 

Diese erzeugt die Benutzeroberfläche für den Daten-Streamer, (siehe Abbildung 3.19). 

Abbildung 3.19: SWF Toolbox - Grafische Oberfläche des Data-Streamer 

Die Benutzeroberfläche des Daten-Streamers setzt sich aus vier Teilen zusammen. Einer, oberhalb 

liegenden, Schaltflächenleiste (Punkt 1), einem Bereich, in dem im späteren Verlauf die aktuelle 

WEA-Übersicht angezeigt wird (Punkt 2), einen Bereich, der die zu übertragenden Daten beinhalten 

wird (Punkt 3) und eine Konfigurationsleiste für die Datenübertragung (Punkt 4). 

490



WEA-Übersicht und generierte Daten laden 

Abbildung 3.20: Klassenmodell - WEA-Übersicht und generierte Daten laden 

Durch Betätigen der Schaltfläche Übersicht laden (siehe Abbildung 3.19 Punkt 1) wird durch die 

Klasse JPanel_Datastreamer eine JDBC-Verbindung unter Verwendung der Klasse 

Jdbc_hana_connect zum SAP HANA System aufgebaut. Ist die JDBC-Verbindung erfolgreich aufgebaut 

worden, erfolgt eine SQL Anfrage mit Hilfe der Klasse Sql_Select. Diese wird im Folgenden 

beispielhaft dargestellt: 

Sql_Select.select_query_rs(con, 

"SELECT TOP 200 ANLAGEN_ID , COUNT( ANLAGEN_ID ) 

AS ZEILEN_ANZAHL , Min (SENSOR_TIMESTAMP) as 

MIN_TIMESTAMP MAX (SENSOR_TIMESTAMP) as 

MAX_TIMESTAMP, Min(FULLDATE) as MIN_ZEITRAUM, max(FULLDATE) as 

MAX_ZEITRAUM 

FROM (SELECT * FROM SMARTWINDFARM . SENSORDATEN ) 

GROUP BY ANLAGEN_ID ORDER BY ANLAGEN_ID ASC" ); 

Als Ergebnis wird eine Liste der aktuell in der Datenbanktabelle SENSORDATEN enthaltenen WEA, 

deren jeweilige Anzahl an Zeilen und deren abgebildeter Zeitraum in Form einer Tabelle ausgegeben, 

(siehe Abbildung 3.19 Punkt 2). 

Wird die Schaltfläche Daten öffnen betätigt, erfolgt zunächst der Aufruf der Klasse File_Source_Chooser. 

Diese erzeugt einen Dateiauswahldialog für die Auswahl der Textdatei, in der die 

zu übertragenden Daten enthalten sind. Ist die Auswahl der Textdatei erfolgt, wird diese durch die 

Klasse File_Importer ausgelesen und in Form einer Tabelle ausgegeben, (siehe Abbildung 3.19 Punkt 

3). 

491



Datenübertragung starten 

Abbildung 3.21: Klassenmodell - Datenübertragung starten 

Nach erfolgter Eingabe der Ziel WEA-Nummer und der zu übertragenden Datenzeilen in der Konfigurationsleiste 

des Daten-Streamers, kann die Betätigung der Schaltfläche Start durch den Benutzer erfolgen. 

Ist dies geschehen, leitet die Klasse JPanel_Datastreamer die zu übertragenden Daten sowie 

die Konfigurationen an die Klasse Data_Streamer weiter. 

Diese baut eine JDBC-Verbindung, unter Verwendung der Klasse Jdbc_hana_connect, zum SAP 

HANA System auf. Wurde die JDBC-Verbindung erfolgreich aufgebaut, erfolgt die direkte Datenübertragung. 

Der aktuelle Status der Übertragung wird dabei durch die, im Abschnitt „Programmaufruf“ 

genannte, Konsole realisiert. 

Bibliotheken 

Name 

Standard Widget 

Toolkit 

Version Funktion 

3.65 Bereitstellung von Modulen für die Benutzeroberfläche 

Ngdbc 1.00.32 Java Datenbankschnittstelle zum SAP HANA System 

JGoodies Common 

1.6.0 Gestaltung der Benutzeroberfläche 

JGoodies Looks 2.5.3 Gestaltung der Benutzeroberfläche 

log4j 1.2.17 Steuerung und Speicherung der Log-Ausgaben 

Google Core 

Libraries 

rs2xml (JDOM 

Project) 

14.0 Bereitstellung von zahlreichen unterstützenden Funktionen für die 

interne Datenverarbeitung. 

k.A. 

Nutzung der enthaltenen Funktion resultSetToTableModel, weiterer 

Funktionsumfang ist nicht ersichtlich. 

Tools 1.7 Entstammt der Java JRE Bibliothek, diese musste zur Verwendung 

des WEB-Browser direkt eingebunden werden. 

492



3.4.3 Programmdaten 

Wetterdaten 

Die Wetterdaten dienen als Basis der zu generierenden Daten und müssen in Form einer CSV- oder 

Textdatei vorliegen. Diese muss folgende acht, per Semikolon getrennte, Attributnamen in erster Reihe 

aufweisen: 

Datum; Zeit; Temp. A.; Feuchte A.; Luftdruck; Regen; Wind; Richtung 

Nach einem Zeilenumbruch folgt die Angabe der dazugehörigen Werte. Diese sind ebenfalls per Semikolon 

zu trennen und mit einem Zeilenumbruch abzuschließen. Die Angabe des Datums und der 

Uhrzeit muss erfolgen und folgendes Schema aufweisen: 

TT.MM.JJJJ ; HH:MM 

Attribute ohne Werte sind mit einer 0 in den jeweiligen Datenzeilen zu hinterlegen. Zum Beispiel: 


01.01.2007;00:00;7.6;94;0;0;15.6;285 

XML-Konfiguration 

Die XML-Konfiguration dient der permanenten Konfiguration des Datengenerators und muss folgendem 

XML-Schema entsprechen: 

 

 

 

… 

… 

… 

… 

… 

… 

 

 

… 

 

Eine ausführlichere Beschreibung zum Aufbau der XML ist der Benutzerdokumentation zu entnehmen. 

Generierte Daten 

Die generierten Daten werden in Form einer Textdatei ausgegeben, dessen Grundstruktur ist äquivalent 

zur Wetterdaten-Textdatei. Die angegebenen Attributnamen müssen gleich der Attributnamen in 

der Datenbanktabelle sein. Zum Beispiel: 

SENSOR_ID;SENSOR_TIMESTAMP;AUSSENTEMPERATUR;LUFTFEUCHTIGKEIT; 

493



3.4.4 Projektordnerstruktur 

Die Ordnerstruktur des Projektes ist wie folgt gegliedert: 

SWF_Toolbox Ordner 

-.settings Ordner Eclipse IDE Einstellungen 

-bin Ordner Class-Dateien 

-icons Ordner Verwendete Icons 

-lib Ordner Bibliotheken 

-logs Ordner Log-Dateien 

-- MeineLogDatei.log Datei Aktuelle Log-Datei 

-resources Ordner 

--images Ordner Bilder für die Willkommensseite 

--reports Ordner SWF Microsoft Excel Reports 

--start.html Datei Willkommens-HTML-Seite 

-src Ordner Java Klassen 

-tools Ordner 

-- OpenVPNPortable Ordner VPN Client Applikation 

-.classpath Datei Klassenpfade 

-.project Datei Projekteinstellungen 

-generator_config.xml Datei XML-Konfigurationsdatei 

-log4j-3.properties Datei Log4j Konfiguration 


Für das Data Mining setzt die Teilgruppe das SAP HANA System in Kombination mit R ein. Diese 

Entscheidung ist darin begründet, dass SAP bisher für Data Mining Zwecke R empfahl und die Physiker 

von ForWind bereits Erfahrungen im Umgang mit R besitzen und somit evtl. Algorithmen übernommen 

werden können. 

Für die Umsetzung des DV-Konzepts wurden zunächst einfache Data Mining Beispiele unabhängig 

von den Windenergiedaten getestet (siehe Kapitel 4.4). Anschließend wurde innerhalb der Windenergiedaten 

nach Mustern gesucht. Zunächst lagen der Projektgruppe lediglich die Daten von ForWind 

mit sechs Attributen vor: Timestamp, Windgeschwindigkeit (in m/s), Windrichtung, Leistungsabgabe, 

Generator Drehzahl sowie Betriebsstatus. Da der genaue Inhalt des Betriebsstatus unbekannt war und 

lediglich bekannt, dass die Werte zwischen 0 und 25 liegen, wurde zunächst eine Regression für das 

Attribut Betriebsstatus durchgeführt. Hierfür wurden die folgenden zwei Prozeduren in SAP HANA 

angelegt: 

DROP PROCEDURE smartwindfarm.classification; 

CREATE PROCEDURE smartwindfarm.classification(IN windfarm_data SMARTWIND- 

FARM.sensordaten, OUT result SMARTWINDFARM.results) 

LANGUAGE RLANG AS 

BEGIN 

#Workspace festlegen 

setwd("/tmp/rtest") 

494 

#Variablendefinition 

Sensor_timestamp = as.numeric(windfarm_data$SENSOR_TIMESTAMP)



Windgeschwindigkeit = as.numeric(windfarm_data$WINDGESCHWINDIGKEIT) 

Windrichtung = as.numeric(windfarm_data$WINDRICHTUNG) 

Leistungsabgabe = as.numeric(windfarm_data$LEISTUNGSABGABE) 

Generator_Drehzahl = as.numeric(windfarm_data$GENERATOR_DREHZAHL) 

Betriebsstatus = as.numeric(windfarm_data$BETRIEBSSTATUS) 

#Nutze Package Cairo zur Darstellung der Ergebnisse 

require(Cairo) 

# Nutze Package rpart für Data Mining 

require(rpart) 

#Baum erzeugen. Als method wurde "class", dh Klassifikation gewählt 

fit



Daher wurden unterschiedlich große Datenmengen getestet. Bei 200 Datensätzen wird zwar ein Diagramm 

erstellt wird (siehe Abbildung 3.23), dieses ist jedoch aufgrund der geringen Datenmenge nicht 

aussagekräftig. Bei größeren Datenmengen wird ebenfalls primär über den Sensor_timestamp zugeordnet. 

Da dieser keine Aussagekraft über den Status besitzt sondern nur die aktuelle Zeit angibt, wurde 

das Attribut aus der Regression entfernt. Anschließend war es nicht mehr möglich, ein gültiges 

Modell zu erstellen. Der Status kann somit nicht über die vier Attribute Windgeschwindigkeit, Windrichtung, 

Leistungsabgabe und Generator_Drehzahl vorhergesagt werden. 

Abbildung 3.23: Entscheidungsbaum für Status für 200 Datensätze 

Seit dem 26.02.2013 liegen der Projektgruppe weitere WEA-Daten von der Availon GmbH vor. Zunächst 

wurde ein triviales Beispiel getestet: Die Vorhersage der durchschnittlichen Leistung über die 

Windgeschwindigkeit. Hierfür wurden obigen Prozeduren folgendermaßen angepasst: 

DROP PROCEDURE smartwindfarm.classification; 

CREATE PROCEDURE smartwindfarm.classification(IN windfarm_data SMARTWIND- 

FARM.sensordaten, OUT result SMARTWINDFARM.results) 


496



BEGIN 

#Workspace festlegen 

setwd("/tmp/rtest") 

#Variablendefinition 

Windgeschwindigkeit = as.numeric(windfarm_data$WINDGESCHWINDIGKEIT) 

Leistung_mittl = as.numeric(windfarm_data$LEISTUNG_MITTL) 





#Baum erzeugen. Als method wurde "class", dh Klassifikation gewählt 

fit



Abbildung 3.24: Entscheidungsbaum Windgeschwindigkeit 

In weiteren testweisen Analysen wurden keine relevanten Ergebnisse ermittelt. In zukünftigen Projekten 

ist dieser Bereich daher stark ausbaubar. 

Seit der Version SPS 05 bietet SAP HANA Data Mining innerhalb des Tools selbst an. Hierfür steht 

die Predictive Analytics Library (PAL) zur Verfügung. Diese bietet die gängigsten Data Mining Methoden, 

welche innerhalb der SQL Skripte aufgerufen werden können. Bisher werden sechs Data Mining 

Kategorien unterstützt: Clusterig, Klassifikation, Assoziation, Zeitreihen, Vorverarbeitung und 

Sonstiges. Um PAL nutzen zu können, werden die Application Function Libraries (AFL) benötigt 

(SAP 2013). Da diese der Projektgruppe nicht zur Verfügung standen und erst gegen Ende der Projektphase 

veröffentlicht wurde und somit nicht beantragt werden konnte, wurde PAL von der Projektgruppe 

nicht eingesetzt. Für zukünftige Projekte ist diese Library jedoch sehr interessant und könnte 

dem gewünschten Data Mining Umfang entsprechen. Vorteil der PAL im Gegensatz zu R sind zum 

einen die Geschwindigkeit, da die Daten nicht transferiert werden müssen, und zum anderen die direkte 

Anzeigbarkeit der Ergebnisse, was das Darstellungsproblem aus R löst. Zudem treten vermutlich 

keine Timeout Probleme auf, sodass alle Daten untersucht werden können. Die Nachteile von PAL 

sind ein geringerer Funktionsumfang und niedrigere Anpassbarkeit. Die Vor- und Nachteile müssen 

daher für zukünftige Projekte abgewogen werden. 

498



3.6 Reporting 

Im nachfolgenden Kapitel wird die technische Realisierung der Reporting-Lösungen der Windenergiedaten, 

in Verbindung mit SAP HANA, beschrieben. Ergänzend sind im Kapitel 4 die jeweiligen 

Benutzerhandbücher zu finden, welche die Oberfläche der Applikationen und dessen Bedienung beschreibt. 

3.6.1 Microsoft Excel 

Anmerkung: Die im Folgenden beschriebene Microsoft Excel Datei namens SmartWindFarm.xlsx, ist 

in der beigefügten DVD in dem Ordner „04_Excel_Reporting“ zu finden. 

Microsoft Excel bietet in Kombination mit SAP HANA eine schnelle und komfortable Lösung Reports 

in Form von Diagrammen, Tabellen und Pivot-Tabellen umzusetzen. 

Auf Grundlage des im DV-Konzept beschriebenen Konzepts Analysen und Reporting – Microsoft 

Excel, ist die Realisierung mehrerer Reports innerhalb einer Excel-Datei erfolgt. Die Realisierung ist 

in die drei Bereiche Systemvorbereitung, Datenbeschaffung und Datenvisualisierung aufgeteilt worden, 

welche im Folgenden aus technischer Sicht erläutert werden. 

Systemvorbereitung 

Um eine Verbindung zwischen Microsoft Excel und SAP HANA zu ermöglichen, ist eine ODBC- 

Verbindung in Microsoft Excel eingerichtet worden. Dies ist durch Anlegen einer Verbindung im 

ODBC Data Source Administrator von Microsoft Windows erfolgt, (siehe Abbildung 3.25). 

Abbildung 3.25: ODBC Data Source Administrator – SAP HANA Verbindung 

499



Datenbeschaffung 

Die Datenbeschaffung aus SAP HANA ist durch Aufruf des jeweiligen SQL-Befehls in Microsoft 

Excel erfolgt. Hierzu ist, wie auf folgender Abbildung zu sehen, im Reiter Daten die Schaltfläche Aus 

andern Quellen betätigt und dort der Eintrag Von Microsoft Query ausgewählt worden. Im sich öffnenden 

Menü ist die erstellte ODBC-Verbindung aufgelistet. Nach erfolgreicher Auswahl konnten, 

wie auf Abbildung 3.27 zu sehen, die verschiedenen Spalten der unterschiedlichen Tabellen des SAP 

HANA Systems ausgewählt und eine SQL-Abfrage mittels GUI erstellt werden (siehe Abbildung 

3.28). 

Abbildung 3.26: Excel Verbindung zu SAP HANA herstellen 

Abbildung 3.27: Excel - Tabellen- und Spaltenauswahl 

500



Abbildung 3.28: Excel - Abfrage-Assistent 

Die mittels des SQL-Befehls angefragten Daten sind im SAP HANA System verarbeitet worden und 

ausschließlich die Ergebnisse der Analyse sind an Microsoft Excel zurückgegeben worden. Die SQL- 

Anfrage konnte, wie in Abbildung 3.29 zu sehen, auch nachträglich angepasst oder durch eine andere 

ersetzt werden. Diese Ergebniswerte sind dann, wie auf Abbildung 3.30 zu sehen, als Tabelle dargestellt 

worden. 

Abbildung 3.29: Excel – SAP HANA Verbindung (Query zum Report 1) 

501



Abbildung 3.30: Excel – SAP HANA Ergebnistabelle 

Datenvisualisierung 

Die Datenvisualisierung ist in Form von drei Berichten realisiert worden, welche unteranderem, Pivot- 

Tabellen und verschiedene Diagramme genutzt haben. In Abbildung 3.31 wird beispielhaft der Bericht 

zur „Durchschnittliche Leistungsabgabe, Windgeschwindigkeit und Generatordrehzahl der Anlage 30 

für Mai 2012“ dargestellt. 

502



Abbildung 3.31: Excel – Bericht 

Alle Berichte basieren auf einer in der Microsoft Excel Datei hinterlegten SQL-Abfrage, beispielhaft 

wird im Folgenden die SQL-Abfrage für den unter Abbildung 3.31 gezeigten Bericht aufgeführt. 

SELECT 

TO_DATE(ADD_SECONDS(TO_TIMESTAMP ('1970-01-01 00:00:00'), "SEN- 

SOR_TIMESTAMP")) 

as "Monat", 

round(avg("GENERATORDREHZAHL_MITTL"),2) 

as "Generatordrehzahl", 

round(avg("LEISTUNG_MITTL"),2) as "Leistungsabgabe", 

round(avg("WINDGESCHWINDIGKEIT"),2) as "Windgeschwindigkeit" 

FROM "SMARTWINDFARM"."SENSORDATEN" 

WHERE "ANLAGEN_ID" = 30 and MONTH(TO_DATE(ADD_SECONDS(TO_TIMESTAMP ('1970- 

01-01 00:00:00'), "SENSOR_TIMESTAMP"))) = 5 

GROUP BY TO_DATE(ADD_SECONDS(TO_TIMESTAMP ('1970-01-01 00:00:00'), "SEN- 


ORDER BY TO_DATE(ADD_SECONDS(TO_TIMESTAMP ('1970-01-01 00:00:00'), "SEN- 


Weiterhin ist ein Bericht über die durchschnittliche Leistungsabgabe und Windgeschwindigkeit pro 

Monat und die durchschnittliche Leistungsabgabe und Windgeschwindigkeit nach Gondelposition 

angelegt worden. Diese sind in der Benutzerdokumentation in Form einer Abbildung aufgeführt. 

503



3.6.2 SAP UI5 

Anmerkung: Das im Folgenden beschriebene Projekt ist in der beigefügten DVD in dem Ordner 

„02_SAP_UI5_Webanwendung“ zu finden. 

Mit Hilfe von SAP UI5 ist eine webbasierte Anwendung zur Analyse und Reporting von Windenergieanlagen 

durch die Teilgruppe realisiert worden. 

Ziel ist es gewesen, eine dynamische und betriebssystemunabhängige Webanwendung zu entwickeln, 

wodurch u.a. verschiedene Eigenschaften der einzelnen WEA sowie zahlreiche Reports auf Basis der 

aktuellen Daten im SAP HANA System dargestellt werden können. 

Auf Grundlage des Kapitels Analyse und Reporting – SAP UI5 im DV Konzept ist die Realisierung 

der Hauptkomponenten Monitor, Log und Reporting erfolgt. Die Data-Mining ist nicht realisiert worden. 

Zu Anfang erfolgte zunächst die Einarbeitung in UI5 und die damit verbundenen Technologien, wozu 

HTML/HTML5, Cascading Stylesheets (CSS/CSS3), JavaScript und OData zählen. Das SAP HANA 

Studio hat dabei als Entwicklungsumgebung fungiert, in der eine Repository für die Projektdateien 

angelegt worden ist. Diese Repository stellt ein Versionskontrollsystem dar, dessen aktuellster Versionsstrang 

immer automatisch produktiv gesetzt worden ist, d.h. direkt per Webadresse erreichbar ist. 

Nachstehend werden die Projektstruktur, die eingesetzten Bibliotheken sowie eine funktionsorientierte 

Beschreibung der Webanwendung erläutert. Weiterhin sind im Quelltext die jeweiligen Funktionen 

und deren Aktionen kommentiert bzw. dokumentiert. 

Alle Elemente der grafischen Oberfläche werden in der Benutzerdokumentation im Kapitel 4.5 ausführlich 

beschrieben. 

504



Projektstruktur 

Das Projekt trägt den Namen swfm_ui5, besteht aus mehreren Komponenten und ist mit mehreren 

Technologien implementiert worden. Folgende Tabelle gibt die Projektstruktur und dessen Inhalte 

wieder. 

Ordner Beschreibung Inhalt 

Css Dieser Ordner beinhaltet CSS/CSS3 Dateien swf_layout.css 

für die Gestaltung der Webanwendung 

elements 

Imgs 

services 

javascript 

Bibliotheken 

In diesem Ordner sind alle dynamischen 

HTML-Inhalte in Form von Textdatei hinterlegt. 

In diesem Ordner sind alle verwendeten Bilder 

innerhalb der Webanwendung hinterlegt. 

Dieser Ordner enthält alle definierten OData-Services. 

In diesem Ordner werden alle JavaScript 

Funktionen abgelegt. 

Tabelle 3.16: Projektstruktur SAP UI5 Webanwendung 

content_datamining.txt 

content_home.txt 

content_repo.txt 

filter.txt 

Alarm-Error-icon.png 

Alarm-Tick-icon.png 

Alarm-Warning-icon.png 

Apps-clock-icon.png 

Apps-kchart-icon.png 

Apps-kformula-icon.png 

… 

log1.xsodata 

reporting1.xsodata 




chart1.js 

chart2.js 

chart3.js 

chart4.js 

extrafunctions.js 

menu.js 

monitor_detail.js 

reporting.js 

sapui5_log.js 

spin.js 

Neben den bereits nativen integrierten Bibliotheken, bspw. die JQuery JavaScript-Bibliothek, ist für 

die grafische Darstellung von Diagrammen die JavaScript-Bibliothek der Firma Highcharts in der 

Version 3.0.0 verwendet worden. 

505



Funktionsorientierte Beschreibung 

Der Aufruf der SAP UI5 Webanwendung erfolgt über die index.html. Die Struktur der index.html entspricht 

der einer Standard HTML-Seite. Im die CSS-Datei, die JavaScript-Funktionen und – 

Bibliotheken eingebunden bzw. definiert. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Im anschließenden body-Tag wird das Layout der Webanwendung beschrieben, das sich in die drei 

Hauptelemente Top-Leiste, Menü und Content-Block unterteilt. 

 

 

… 

 

 

… 

 

 

… 

 

 

Innerhalb der Hauptelement wird der Aufbau der grafischen Oberfläche definiert sowie die jeweiligen 

aufzurufenden JavaScript Funktionen bei einer Interaktion durch den Benutzer. Abbildung 3.32 zeigt 

die aufgerufene index.html, dabei wird Punkt 1 durch das Element Top-Leiste beschrieben, Punkt 2 

durch das Element Menü und Punkt 3 durch das Element Content-Block. 

506



Abbildung 3.32: SAP UI5 - Hauptseite 

Im Element Top-Leiste wird die Funktion updateClock() genutzt, um die aktuelle Zeit zu berechnen. 

Weiterhin dient die Funktion dimmenu(obj, status) der Darstellung von aktiven bzw. inaktiven Schaltflächen, 

bspw. MONITOR. inaktive Schaltflächen werden mit einer Undurchsichtigkeit von 70% dargestellt. 

Wird eine der vier Schaltflächen im Element Content-Block betätigt, erfolgt mit Hilfe der Funktion 

selmenu(obj) die dynamische Generierung des Inhalts. Dabei werden die, für die Schaltfläche definierten, 

Funktionen ausgeführt und der Inhalt im Content-Block generiert. 

Durch betätigen der Schaltfläche MONITOR wird der bisherige Inhalt im Content-Block durch eine 

Liste von Anlagen des Windparks incl. deren aktuellen Status (OK, WARNING, ERROR) ersetzt (siehe 


Weiterhin wird das Element Menü um die zuvor im Content-Block enthaltenden Schaltflächen ergänzt. 

507



Abbildung 3.33: SAP UI5 - Monitor 

Erfolgt die Auswahl einer der Anlagen in der Liste, wird die Funktion filter(obj) ausgeführt, um den 

passenden Inhalt für das ausgewählte Windrad im zentralen Content-Block zu laden. Der neue Inhalt 

besteht dabei aus einer Übersicht von aktuellen Attributen des WEA, bspw. Windrichtung oder Status. 

Der Aufruf der Schaltfläche LOG (Lupe + Blatt Icon) in der linken Leiste ruft die Funktion sapui5_log() 

auf. Dessen Aufgabe ist die Generierung einer Log-Tabelle mit Hilfe eines SAP UI5 

Widget. Die Log-Tabelle enthält alle aktuellen Fehlermeldungen der abgebildeten WEA, (siehe Abbildung 

3.34). 

508



Abbildung 3.34: SAP UI5 - Log 

Wird die Reporting Schaltfläche (Diagramm Icon) betätigt, wird eine Liste der aktuell verfügbaren 

Berichte im Content-Block angezeigt. Durch Auswahl einer der Berichte, setzt die Funktion reporting(obj) 

einen Filter, um die passende Chart-Funktion (chart1(), chart2(), chart3() oder chart4()) zu 

starten. 

Die Funktionen chart1(), chart2(), chart3() und chart4() dienen zur Darstellung der einzelnen Berichte. 

Zunächst wird das Ladefenster angezeigt und der Abruf der Daten aus SAP HANA gestartet. Sobald 

die Daten geladen sind, wird die Darstellung generiert und im zentralen Content-Block geladen. 

Die jeweiligen Diagramme werden mit Hilfe der JavaScript-Bibliothek der Firma Highcharts dargestellt. 

509



4 Benutzerhandbücher 

In diesem Kapitel sind die Benutzerhandbücher zu den verschieden Programmen und Tools des dritten 

Kapitels aufgeführt. In den Benutzerhandbüchern sind die einzelnen Funktionen der betreffenden Programme 

erläutert, um den Lesern die Verwendung zu erleichtern. 

4.1 SAP HANA Studio 

Das HANA Studio Benutzerhandbuch gibt Ihnen einen Überblick über die Grundfunktionen von HA- 

NA und deren Bedienung. Es umfasst unter anderem grundlegende Dinge, wie das Einrichten der 

Software selbst, das Erstellen von Datenbanken und Datenbanktabellen ebenso wie speziellere Funktionen 

wie dem Erstellen der verschiedenen Views und Trigger. Außerdem enthält es eine Beschreibung 

wie das HANA Studio zum SAP UI5 Developer-Studio erweitert werden kann. 

Voraussetzungen und Anforderungen 

Element 

Betriebssystem: 

Sonstiges: 

Mindestanforderungen 

Windows 

Administratorrechte 

SAP HANA VPN Anmeldedaten 

Tabelle 4.1: Voraussetzungen 

4.1.1 HANA Studio einrichten 

Nach der Installation müssen Sie das HANA System hinzufügen. Hierzu muss, wie in folgender Abbildung 

zu sehen, mit der Maus im Navigator-Feld das Kontext-Menü geöffnet werden. Dort können 

Sie mittels Mausklick auf den Add System… ein System hinzufügen (siehe Abbildung 4.1). 

510



Abbildung 4.1: HANA Studio - System hinzufügen 

In dem auf Abbildung 4.2 zu sehenden Fenster müssen noch die benötigten Daten, wie z. B. Hostname 

und Instanz-Nummer des HANA Systems eingegeben werden. Anschließend erfolgt die Eingabe des 

Benutzername und des Passworts. 

Abbildung 4.2: HANA Studio - Add System 

511



4.1.2 Datenbank anlegen 

Neben der Möglichkeit, eine Datenbank mittels SQL-Befehls zu erstellen, kann auch eine Datenbank 

erstellt werden, indem Sie mittels des Kontextmenüs die Funktion neue Tabelle anlegen auswählen, 

siehe Kapitel 4.1.3. Während des Anlegens der Tabelle kann, wie auf folgender Abbildung zu sehen, 

ein neues Schema angelegt werden. 

Der SQL-Befehl könnt wie folgt aussehen: 

Abbildung 4.3: HANA Studio - neues Schema anlegen 

create schema "SWF_PLATTFORM"; 

4.1.3 Tabelle anlegen 

Eine Tabelle kann ebenfalls entweder mit Hilfe eines SQL-Create-Befehls oder mittels GUI angelegt 

werden. 

SQL 

CREATE COLUMN TABLE "SWF_PLATTFORM"."Anlage" ("ANLAGEN_ID" INTEGER NOT 

NULL, 

"ANLAGENTYP_ID" INTEGER, 

"ANBIETER_ID" INTEGER, 

"ANLAGE_TIMESTAMP" Timestamp, 

"BEZEICHNUNG" VARCHAR(30), 

"STANDORT" VARCHAR(200), 

PRIMARY KEY ("ANLAGEN_ID")); 

GUI 

Hierzu müssen Sie mit der rechten Maustaste die Datenbank auswählen, in der die neue Tabelle angelegt 

werden soll. Anschließend muss, wie auf folgender Abbildung zu sehen, „New Table“ ausgewählt 

werden. 

512



Abbildung 4.4: HANA Studio - neue Tabelle anlegen 

Nun öffnet sich ein Fenster, in dem der Name der Tabelle eingegeben werden kann. Dabei kann auch 

die Datenbank, in der die Tabelle angelegt werden soll, noch geändert werden. Für die Tabelle muss 

einer der folgenden drei verschiedenen Typen ausgewählt werden: Row Store, Column Store und Table 

Type. Der Row Store entspricht der traditionellen Datenbank-Modellierung, während der Column 

Store die neue spaltenbasierende Datenhaltung implementiert. Table Type ist speziell für selten genutzte 

Daten. Die Daten werden bei diesem Typ nicht im Arbeitsspeicher vorgehalten, sondern auf der 

Festplatte gespeichert. Für die beste Performance sollte daher an dieser Stelle der Typ Column Store 

gewählt werden. 

Das Anlegen der einzelnen Spalten erfolgt analog zu traditionellen Datenbanken (siehe Abbildung 

4.5). 

Abbildung 4.5: HANA Studio - Spalten anlegen 

Zum Ausführen des Create-Statements müssen Sie den Button Execute bzw. F8 drücken. 

4.1.4 Spalten umbenennen 

Das umbenennen von bereits erstellten Tabellen ist mittels der GUI zurzeit nicht möglich. Hierzu 

muss ein SQL-Befehl genutzt werden. Der SQL-Befehl hat folgenden Aufbau: 

RENAME COLUMN “Tabellenname”.”Alter_Spalten_Name“ TO „Neuer_Spalten_Name“; 

513



Beim Umbenennen muss jedoch beachtet werden, dass sofern der Datentyp oder die Größe verändert 

werden soll, einige Einschränkungen bestehen, sofern die Spalte bereits Daten enthält. So kann kein 

NOT NULL eingefügt werden sofern leere-Felder vorhanden sind. Des Weiteren kann, um Datenverlust 

vorzubeugen, die Größe eines Datentyps nicht reduziert werden. 

4.1.5 Tabelle befüllen 

Zum Füllen der Tabelle gibt es, wie auf folgender Abbildung zu sehen, zwei verschiedene Möglichkeiten. 

Zum einen können Sie die Daten mittels SQL-Insert-Statement zum anderen mit Hilfe eines Daten-Imports 

in die Datenbanktabelle laden. 

Abbildung 4.6: HANA Studio - Tabelle befüllen 

4.1.6 Analysen erstellen 

Die Analysen werden mittels Views implementiert. Bevor eine View erstellt werden kann, muss ein 

Package angelegt werden, in dem die Views abgespeichert werden können. Zum Erstellen eines Package 

muss mit rechter Maustaste auf Content geklickt werden. Anschließend kann unter New ein neues 

Package angelegt werden (siehe Abbildung 4.7). 

514



Abbildung 4.7: HANA Studio - neues Package erstellen 

Es gibt drei Arten von Views: Analytic View, Attribute View und Calculation View. Um eine der 

Views anzulegen, muss auf das jeweilige Package geklickt werden. Danach kann, wie in folgender 

Abbildung zu sehen, im Kontextmenü unter New die gewünschte View Art ausgewählt werden. 

Abbildung 4.8: HANA Studio - Anlegen einer View 

Die Unterschiede der verschiedenen Views werden im Folgenden erläutert. 

Analytic View 

Im Analytic View können Berechnungen und Aggregationen durchgeführt werden. Analytic Views 

basieren auf der Struktur eines Star Schemas und können auf Dimensionstabellen zugreifen. Analytic 

Views werden unter anderem dafür genutzt, um mehrere Attribute Views per Join miteinander zu verbinden. 

Analytic Views nutzen die Rechenleistung von SAP HANA, um aggregierte Daten zu berechnen. Sie 

werden auf mindestens einem Fact Table definiert, d.h. einer Tabelle, die Daten in Form von Geschäftsfällen 

(Transaktionen) beinhaltet. Analytic Views können wahlweise auf einer einzelnen oder 

mehreren Tabellen erstellt werden. Innerhalb von Analytic Views sind zwei Arten von Attributen 

(Spalten) erlaubt: Measures und Key Figures. Measures sind Attribute, für die eine Aggregation definiert 

werden muss (z.B. in SQL SUM, MIN, MAX). Key Figures sind konkrete Zahlen, z.B. Typen, 

Einheiten oder Größen (SAP Database – Development Guide 2012). 

515



Zuerst kann ein Name und eine Beschreibung für die View eingegeben werden (siehe Abbildung 4.9). 

Danach müssen die verschiedenen Tabellen, auf welche die View zugreifen soll, ausgewählt werden 

(siehe Abbildung 4.10). Anschließend können noch zusätzliche Attribute Views angegeben werden 

(siehe Abbildung 4.11). Die Tabellen und Attribute Views können auch nach dem Erstellen der View 

mittels Drag and Drop in die View gezogen werden. 

Abbildung 4.9: Analytic View - Namen auswählen 

516 

Abbildung 4.10: Analytic View - Tabellen auswählen



Abbildung 4.11: Analytic View – Ergebnis 

Nachdem die View angelegt worden ist, müssen die benötigten Attribute ausgewählt und festgelegt 

werden. Dies geschieht wieder mit Hilfe des Kontext Menüs (siehe Abbildung 4.12). 

Abbildung 4.12: Analytic View - Attribute festlegen 

Bevor eine View genutzt werden kann muss diese gespeichert, überprüft und aktiviert werden. 

Attribute View 

Der Attribute View wird für alle Arten von Joins zwischen Tabellen eingesetzt. Attribute Views können 

auch genutzt werden, um eine Untermenge von Spalten oder Zeilen einer Tabelle zu selektieren. 

Die meistgenutzte Anwendung von Attribute Views ist der Join von mehreren Tabellen, um innerhalb 

eines Starschemas eine einzelne Dimensionstabelle zu erstellen. Die resultierende Dimensions- 

Attribute View kann in einem Analytic View mit einem Fact Table verbunden werden. Es könnte beispielsweise 

Mitarbeiter mit Organisationseinheit verbunden werden, um diese anschließend in einem 

Analytic View mit Verkaufstransaktionen zu verbinden (SAP Database – Development Guide 2012) . 

517



Um eine Attribute View anzulegen, muss ähnlich wie bei Analytic View zuerst ein Name und eine 

Beschreibung eingegeben werden (siehe Abbildung 4.13). 

Abbildung 4.13: Attribute View – Name 

Calculation View 

Der Calculation View wird für komplexe Berechnungen eingesetzt, die nicht mit dem Attribute oder 

Analytic View durchgeführt werden können. Sie werden genutzt, um Zusammenfassungen von anderen 

Views zu erstellen. Die basieren erstens auf einem Join oder Union zwischen zwei oder mehr Datenflüssen 

oder zweitens dienen sie dem Aufruf von eingebauten oder generischen SQL Funktionen. 

Calculation Views können auf die gleiche Art wie Analytic Views genutzt werden, es ist jedoch im 

Gegensatz dazu möglich, mehrere Fact Tables in einem Calculation View per Join zu verbinden. Calculation 

Views haben immer mindestens einen Wert. 

Bei den Calculation Views unterscheidet man zwei Arten, Graphical Views und Scripted Views. Graphical 

Views werden mit der grafischen Modellierungssicht von SAP HANA Modeler erstellt. 

Scripted Views hingegen werden als SQL Statements definiert. Calculation Views werden normaler- 

518



weise nicht mit SQLScript erstellt, es gibt jedoch Ausnahmen. SQLScript kann dann eingesetzt werden 

wenn es a) keine Inputparameter gibt, b) nur lesend auf die Datenbank zugegriffen wird und c) es 

keine Seiteneffekte gibt (SAP Database – Development Guide 2012). 

4.1.7 Trigger anlegen 

Die Trigger-Funktionalität ist erst mit dem neuen Release hinzugefügt worden und ist nicht vollständig 

ausgereift. Ein Trigger kann zurzeit nur mit Hilfe eines SQL –Befehls angelegt werden. Außerdem 

funktioniert das Löschen und Verändern von Tiggern noch nicht vollständig. 

Die Trigger können wie folgt aufgebaut sein: 

CREATE TRIGGER "Name" AFTER/BEFORE INSERT/UPDATE/DELETE 

ON "Schema"."Tabelle" FOR EACH ROW 

BEGIN 

“FUNKTION” 

END; 

4.1.8 SAP UI5 

Bevor die SAPUI5 Tools verwendet werden können müssen einige Vorbedingungen erfüllt werden. 

So wird als Betriebssystem: Microsoft Windows XP, Microsoft Windows Vista and Microsoft 

Windows 7 benötigt. Als Java Laufzeitumgebung wird die Version JRE 1.6 als 32-Bit bzw. 64-Bit 

vorausgesetzt. Wenn diese Vorbedingungen erfüllt sind, können die UI5 Funktionen installiert werden. 

Dazu muss die HTML5Evaluation_complete.zip an einen beliebigen Ort entpackt werden. Anschließend 

muss in Eclipse oben in der Funktionsleiste unter dem Menüpunkt Help die Funktion Install New 

Software gewählt werden. In dem, in Abbildung 4.14 zu sehendem neuen Fenster muss auf Add… 

geklickt werden. 

519



Abbildung 4.14: Eclipse IDE – Installation von Software Dialog 

Anschließend muss im auf Abbildung 4.15 zu sehenden Fenster Local… ausgewählt werden, um dort 

den Pfad zur local update site aus dem eben entpackten Archive anzugeben. 

Abbildung 4.15: Eclipse DIE – Repository hinzufügen 

Nach der Installation aller Pakete muss Eclipse neu gestartet werden. Anschließend kann mit dem 

Erstellen eines UI5 Projektes begonnen werden. 

520



4.2 Durchführung des ETL-Prozesses der ForWind Daten 

Anmerkung: Die im Folgenden beschriebenen Projektdateien sind in der beigefügten DVD in dem 

Ordner „01_ForWind_Phentaho“ zu finden. Dazu zählen die Dateien „ForWind_ Transformation.ktr“, 

„ForWind_Job_Transformation.kjb“ und „ForWind_Nummerierung_Alle.ktr“. 

Nachfolgend werden die Vorgänge für eine erneute Durchführung eines ETL-Laufs der, von ForWind 

erhaltenen, WEA-Daten beschrieben. 

4.2.1 Voraussetzungen und Anforderungen 

Element 

Betriebssystem: 

Java: Ab 1.4 

Festplatte: 

Mindesanforderungen 

Windows, Mac, Linux 

Mindestens 70 GB freien Speicherplatz 

Programme: Pentaho Data Integration CE 4.x 

Daten: 

R 2.x 

SAP HANA Studio Revision 48 

Open Vpn Client 1.x incl. SAP HANA HPI Konfiguration 

Rdata ForWind Dateien 

(siehe Ordner „ForWind_WEA_Daten“ auf der DVD der Dokumentation) 

ForWind_Transformation.ktr (siehe Ordner „ForWind_Phentaho“) 

ForWind_Job_Transformation.kjb (siehe Ordner „ForWind_Phentaho“) 

ForWind_ Nummerierung_Alle.ktr (siehe Ordner „ForWind_Phentaho“) 

4.2.2 Durchführung 

1. Legen Sie eine lokale Kopie des Ordners ForWind_WEA_Daten an. Der Ordner ist auf der DVD 

zu der Dokumentation zu finden. 

2. Starten Sie das Programm R und öffnen Sie die Datei Rdata2ASCII.R im kopierten Ordner mit R, 


521



Abbildung 4.16: Geöffnete Rdata2ASCII.R Datei 

3. Ergänzen Sie Zeilen 3 und 7 wie folgt, um den eigenen lokalen Dateipfad zu ergänzen bzw. anzupassen 

und ggf. den ASCII_folder „Ordner“ anzulegen: 

# set the folder where the Rdata files are located 

data_folder="C:/ForWind_Daten/" 

# set the folder where the ASCII files will be saved 

ASCII_folder="C:/ForWind_Daten/ASCII/" 

4. Markieren Sie alle Zeilen innerhalb von R und betätigen Sie die Schaltfläche Ausführung Zeile 

oder Auswahl, (siehe Abbildung 3.17). 

Abbildung 4.17: Ausführung einer R Prozedur in RGUI 

5. Führen Sie das R Script in der R Konsole aus, dabei wird der aktuelle Fortschritt durch die blauen 

Zeilen [1] 1, [1] 2 …. -[1] 12 gekennzeichnet, (siehe Abbildung 4.18). Der Vorgang kann einige 

Stunden in Anspruch nehmen. 

522



Abbildung 4.18: Fortschrittskontrolle in RGui 

6. Sind alle zwölf Schritte erfolgreich durchgeführt worden, so befinden sich insgesamt 72 Textdokumente 

im Ausgabeordner, welcher im Vorgang 3 im Element ASCII_folder definiert worden ist, 


Abbildung 4.19: Extrahierte ForWind Textdateien 

523



7. Konfigurieren Sie die Pentaho Data Integration CE. Hierbei muss zunächst die heruntergeladene 

Zip-Datei entpackt werden. Öffnen Sie anschließend die im Ordner data-integration auf erster 

Ebene enthaltende Spoon.bat. Das Öffnen der Datei erfolgt per Rechtsklick auf die Datei und 

Auswahl des Menüpunktes Bearbeiten. Ändern Sie im Bearbeitungsmodus in dem If-Statement, 

welches hier angezeigt wird, den Wert für Xmx512m auf die verfügbare Arbeitsspeichermenge ab, 

z. B. Xmx2048m entspricht zwei GB an freiem Arbeitsspeicher. 

if "%PENTAHO_DI_JAVA_OPTIONS%"=="" set PENTAHO_DI_JAVA_OPTIONS="- 

Xmx2048m" "-XX:MaxPermSize=1024m" 

Durch diese Anpassung steht Pentaho Data Integration CE mehr Arbeitsspeicher zur Verfügung, 

mit welchem die Transformationen schneller durchgeführt werden können. Des Weiteren muss der 

Wert für XX:MaxPermSize um die Hälfte des angebenden Xmx Wertes erhöht werden. 

8. Starten Sie die Spoon.bat und öffnen Sie anschließend das Transformationsprojekt For- 

Wind_Transformation.ktr, (siehe Abbildung 4.20). 

Abbildung 4.20: Geöffnete „ForWind_Transformation.ktr“ Tranformation 

9. Öffnen Sie in dem Transformationsprojekt, mit Hilfe eines Doppelklicks, den Konfigurationsdialog 

der jeweiligen Text file input Elemente (Einlesen_Windrichtung_Txt, Einlesen_Generator_Drehzahl_Txt 

etc.). Ändern Sie für jedes Element den Dateipfad, wie in der folgenden 

Abbildung 4.21 gezeigt, auf den aktuellen Dateipfad des ASCII_folder Ordners ab. 

524



Abbildung 4.21: Änderung des Dateipfads der „Text file input“ Elemente 

10. Die nächste Änderung betrifft den Ausgabepfad. Ändern Sie mit Hilfe eines Doppelklicks den 

Ausgabepfad im Element Text file output (Datei Output) im dortigen Feld Filename ab, (siehe 


Abbildung 4.22: Änderung des Dateipfads des „Text file output“ Elementes 

11. Schließen und speichern Sie das geöffnete ForWind_Transformation.ktr Projekt, Öffnen Sie im 

Anschluss den Job ForWind_Job_Transformation.kjb,(siehe Abbildung 4.23), der sich im gleichen 

Ordner wie das ForWind_Transformation.ktr Projekt befinden muss. 

Abbildung 4.23: Geöffneter „ForWind_Job_Transformation.kjb“ Job 

525



12. Um E-Mail Notifikationen zu erhalten, passen Sie die Elemente Job mail details (Start Mail, Zwischenstand 

Mail und Finale Mail) an. Öffnen Sie durch einen Doppelklick auf die jeweiligen 

Elemente deren Konfigurationsdialog. Dort wird eine E-Mail- Adresse und der zugehörige SMTP 

Server etc. hinterlegt, (siehe Abbildung 4.24). 

Abbildung 4.24: E-Mail Konfiguration in Pentaho Data Integration 

13. Starten Sie die Transformation durch das Betätigen des Startsymboles sowie der Launch Schaltfläche 

im anschließenden Execute a job Dialog, (siehe Abbildung 4.25). 

526 

Abbildung 4.25: ForWind Tranformations Job ausführen



14. Ist der Start der Transformation erfolgt, wird eine E-Mail über den erfolgreichen Start an die hinterlegte 

E-Mail-Adresse gesendet. Der aktuelle Status wird direkt in der Prozesskette angezeigt, 

detaillierte Information oder evtl. Fehler werden im Logging Fenster dokumentiert, (siehe Abbildung 

4.26). 

Abbildung 4.26: Ausgeführte Prozesskette des ForWind Job 

Anmerkung: Der Durchlauf des Jobs nimmt ca. vier oder mehr Stunden in Anspruch! 

15. Nach erfolgreicher Ausführung des Jobs ergibt sich folgende Dateistruktur, des im Vorgang 10 

angegebenen Dateipfades. 

file_sensor_1.txt ............ Textdokument ....................... ~1.7 GB 









file_sensor_10.txt ........... Textdokument ....................... ~1.7 GB 



16. Öffnen Sie das Transformationsprojekt ForWind_ Nummerierung_Alle.ktr. Passen Sie durch Doppelklick 

auf das Element Text file input (Datei einlesen) die dort aufgeführten Dateipfade, welche 

dem im Vorgang 10 angegebenen Dateipfad entsprechen müssen an, (siehe Abbildung 4.27). 

527



Abbildung 4.27: „ForWind_ Nummerierung_Alle.ktr“ - Dateipfade ändern 

17. Passen Sie den Ausgabepfad an. Dies entspricht dem Vorgehen, welches im Vorgang 10 bereits 

erläutert worden ist, (siehe Abbildung 4.28). 

Abbildung 4.28: „ForWind_ Nummerierung_Alle.ktr“ - Ausgabepfad anpassen 

18. Konfigurieren Sie die gewünschte Ausgabegröße der Dateien im Untermenü des Text file output 

(Daten Output) Elementes, (siehe Abbildung 4.29). Die Voreinstellung ist auf 3.000.000 Datenzeilen 

pro Datei gesetzt, welches in dem gegebenen Szenario ca. 400 MB pro Datei entspricht. 

528 

Abbildung 4.29: „ForWind_ Nummerierung_Alle.ktr“ – Ausgabegröße anpassen



19. Starten Sie die Transformation, wie im Vorgang 13 beschrieben. Anschließend ergibt sich folgende 

Dateistruktur, in dem in Vorgang 17 angegebenen Dateipfad: 

alle_20130120_0.csv .......... Textdokument ....................... ~400 MB 






… ....... .................... Textdokument ....................... ~400 MB 

alle_20130120_44.csv ......... Textdokument ....................... ~400 MB 

20. In diesem Schritt soll der Import der Daten das SAP HANA System erfolgen. Bauen Sie hierfür 

zunächst eine VPN-Verbindung zum SAP HANA Netzwerk auf und starten Sie das SAP HANA 

Studio. Nach erfolgreichem Aufrufen des SAP HANA Studios rufen Sie die Funktion Import…im 

Quick Launch Dialog auf, (siehe Abbildung 4.30). 

Abbildung 4.30: SAP HANA Studio Import Funktion 

21. Nehmen Sie im geöffneten File Import Wizard/ Define Import Properties Dialog nun die Konfiguration 

vor, die in folgenden Abbildung aufgeführt wird und bestätigen Sie durch Weiter. 

529



Abbildung 4.31: SAP HANA Studio – File Import Wizard Schritt 1 

22. Legen Sie im nächsten Dialog namens File Import Wizard / Manage Table Definition and Data 

Mappings zunächst die Zuordnung der Dateiattribute zu den jeweiligen Attributen der Datenbanktabelle 

SENSORDATEN an. Wie auf Abbildung 4.32 zu sehen müssen Sie im Registerfeld Source 

File das Organigramm Symbol betätigt und anschließend die Funktion one to one ausführen. Dieses 

verbindet die Source File mit der Target Table und stellt das Ergebnis grafisch dar. 

530 

Abbildung 4.32: SAP HANA Studio – File Import Wizard Schritt 2



23. Durch das Betätigen der Schaltfläche Finish erfolgt der Import Vorgang. Der Fortschritt kann im 

Job Log nachvollzogen werden. Mit Hilfe eines Rechtsklicks auf einen Job und anschließender 

Ausführung der Funktion Open Job Details, können Sie den aktuellen Status in Prozent einsehen, 


Abbildung 4.33: SAP HANA Studio – Import Vorgang überwachen 

24. Wiederholen Sie die Vorgänge 21 bis 23 um die Anzahl der zu importierenden Dateien. Zur Überprüfung 

der Vollständigkeit sollten Sie die jeweiligen Job Log File Dateien speichern. Diese sind 

im geöffneten Kontextmenü in Abbildung 4.33 unter dem Punkt Open Job Log File zu finden. 

Anmerkung: Seit dem 01.02.2013 steht ein FTP Server mit direkter Verbindung zu SAP HANA für die 

Datenübertragung bereit. Beim Vorgang 18 sollten Sie daher auf die Begrenzung verzichten, sodass 

nur eine große Datei erzeugt wird. Die Zugangsdaten für den FTP Server und der genaue Verlauf des 

Importvorgangs werden vom HPI zur Verfügung gestellt bzw. sind zu beantragen. 

531



4.3 SWF Toolbox 

Anmerkung: Die im Folgenden aufgeführte „SWF_Toolbox.zip“ ist in der beigefügten DVD, in dem 

Ordner „03_SWF_Toolbox_Source“, zu finden. 

In diesem Benutzerhandbuch wird die Oberfläche der Software SWF Toolbox und dessen Bedienung 

beschrieben. Die SWF Toolbox ist eine Java-basierte Eigenentwicklung der SWF Projektgruppe. 

Die Software ermöglicht die Generierung von WEA-Daten sowie die Simulation eines kontinuierlichen 

Datenstroms bzw. -transfer dieser in das SAP HANA System. Dabei stehen dem Benutzer umfangreiche 

Konfigurationsmöglichkeiten zur Verfügung sowie eine integrierte Verbindung zum SAP 

HANA System. Folglich kann die Software eigenständig agieren und ist auf keine weiteren Programme 

angewiesen. 


Element 


Betriebssystem: Windows 

Java: Ab 1.6 

Sonstiges: 

Administratorrechte 

SAP HANA VPN Anmeldedaten 

Daten: 

SWF_Toolbox.zip 

4.3.2 Installation 

1. Entpacken Sie die Datei SWF_Toolbox.zip. 

2. Führen Sie die Anwendung SWF_Toolbox.exe als Administrator aus, um eine VPN Verbindung 

durch die SWF Toolbox zu ermöglichen. Gehen Sie dafür wie folgt vor: 

a. Öffnen Sie durch einen Rechtsklick auf die Datei SWF_Toolbox.exe das Kontextmenü und 

wählen Sie dort Eigenschaften aus. 

b. Aktivieren Sie im erscheinenden Eigenschaften-Dialog unter dem Reiter Kompatibilität im 

Feld Berechtigungsstufe „Programm als Administrator ausführen“, (siehe Abbildung 4.34). 

Anschließend bestätigen Sie den Vorgang mit OK. 

532



Abbildung 4.34: SWF Toolbox - Dateieigenschaften 

4.3.3 Daten 

Nachfolgend wird ein Überblick über die Daten gegeben, welche während der Benutzung der SWF 

Toolbox zum Einsatz kommen. 

Wetterdaten 

Die Wetterdaten dienen als Grundlage der zu generierenden Daten und sind für die Ausführung des 

Datengenerators notwendig. Aktuelle oder historische Wetterdaten können aus dem Internet bezogen 

werden. Beispielhaft sind im Ordner beispiel_daten einige Wetterdaten hinterlegt. 

Die Daten müssen als CSV- oder Text-Datei vorliegen und folgende per Semikolon getrennte Spalten 

aufweisen: 


01.01.2007;00:00;7.6;94;1017;0.000;15.6;285 

01.01.2007;00:05;7.7;95;1017;0.000;15.6;285 

01.01.2007;00:10;7.8;95;1017;0.000;19.4;235 

Sollte es nicht möglich sein eine oder mehrere Spalten mit Werten zu füllen, so müssen diese mit dem 

Wert 0 belegt werden. 

533



XML- Konfigurationsdatei 

Für die permanente Konfiguration des Datengenerators wird eine XML-Konfigurationsdatei verwendet. 

Standardmäßig wird die Datei generator_config.xml durch die SWF Toolbox geladen, diese befindet 

sich auf der Ebene der SWF_Toolbox.exe. Es besteht die Möglichkeit, diese im Vorfeld zu ändern 

oder eine andere XML-Konfigurationsdatei nach dem Programmaufruf zu laden. 

Die XML-Konfigurationsdatei muss dabei folgende Struktur aufweisen: 

 

 

 

LEISTUNGSABGABE 

WINDGESCHWINDIGKEIT 

0 

0.99 

-50 

-20 

 

 

… 

 

Das dargestellte XML Schema ist so aufgebaut, dass innerhalb der semantischen Auszeichnung (Im 

weiteren Verlauf als Tag bezeichnet) namens … beliebig viele Tags namens 

… angelegt werden können. Diese müssen wiederum die nachfolgenden 

Tags beinhalten: 

 

 

 

 

 

 

 

 

 

 

 

 

Im Tag Name wird die Bezeichnung des zu generierenden Attributes angeben, z.B. die Leistungsabgabe. 

Der Tag Abhaengigkeit spiegelt die Bezeichnung des Attributes wieder, dessen Werte als Basis für 

die Generierung fungieren. Bspw. soll die Leistungsabgabe der WEA auf Basis der vorherrschenden 

Windgeschwindigkeit generiert werden. 

Die Tags und grenzen dabei den zu erfassenden nummerischen Wertebereich 

des abhängigen Attributes ein, z.B. eine vorherrschende Windgeschwindigkeit von 0 bis 0,99 

m/s. 

Entspricht ein Wert während der Generierung diesem Wertebereich, so wird ein Zufallswert innerhalb 

des angegebenen Wertebereichs der Tags und generiert. Das heißt in 

534



diesem Fall, sollte eine Windgeschwindigkeit von 0,5 anliegen, so wird bspw. eine Leistungsabgabe 

zwischen -50 und -20 generiert. 

Weitere Information und einzuhaltende Regeln bzgl. der Konfiguration, werden in den folgenden Kapiteln 

gegeben. 

4.3.4 Betrieb 

Starten Sie die Applikation indem Sie die Datei SWF_Toolbox.exe ausführen. Nach erfolgtem Start 

wird das Hauptfenster der SWF Toolbox angezeigt. Dort finden Sie auf der linken Seite die Hauptfunktionen 

Generator öffnen und Streamer öffnen, (siehe Abbildung 4.35 Punkt 1). Im mittleren und 

rechten Arbeitsbereich befindet sich die Willkommensseite, in der Sie die Funktionen Report UI5 und 

Report Excel aufrufen können, (siehe Abbildung 4.35 Punkt 2). Abschließend finden Sie in der rechten 

oberen Ecke die Schaltfläche Verbinden, (siehe Abbildung 4.35 Punkt 3). 

Abbildung 4.35: SWF Toolbox - Hauptfenster 

Durch Aufruf der Funktionen Report UI5 können Sie die SWF UI5 Reporting Webseite im Internet 

Explorer öffnen. Weiterhin besteht die Möglichkeit durch Aufruf der Funktion Report Excel die 

Microsoft Excel Reporting-Datei zu öffnen, eine Beschreibung dieser finden Sie in den jeweiligen 

Benutzerhandbüchern. Im Folgenden werden die, unter Punkt 1 und 3 in Abbildung 4.35 aufgeführten, 

Funktionen nach dem vorgesehenen Ablauf beschrieben. 

535



VPN Verbindung aufbauen 

1. Betätigen Sie die Verbinden Schaltfläche. 

2. Der Aufruf des VPN Clients erfolgt. Die Eingabe sowie Bestätigung der SAP HANA VPN Anmeldedaten 

muss anschlie0end von Ihnen erfolgen, (siehe Abbildung 4.36). 

Abbildung 4.36: SWF Toolbox – VPN Verbindung aufbauen 

3. Der erfolgreiche Aufbau der VPN Verbindung wird durch den Status Initialization Sequence 

Completed innerhalb des VPN Clients gekennzeichnet, (siehe Abbildung 4.37). 

Abbildung 4.37: Open VPN – Verbindungsstatus 

4. Sie sind nun mit dem Netzwerk des SAP HANA Systems verbunden und ermöglichen somit den 

Datentransfer zwischen der SWF Toolbox und des SAP HANA Systems. 

536




1. Durch einen Doppelklick auf die Funktion Generator öffnen initialisieren Sie den Generator. Dieser 

ermittelt zunächst alle verfügbaren Spalten in der SAP HANA Datenbanktabelle SENSORDA- 

TEN. Je nach Verbindungsgeschwindigkeit kann dieser Vorgang etwas Zeit in Anspruch nehmen. 

Anschließend wird ein neues Registerfeld namens Daten Generator erzeugt, (siehe Abbildung 

4.38). 

Abbildung 4.38: SWF Toolbox – Daten Generator 

In der oberen Abbildung finden Sie unter Punkt 1 die Funktionsleiste. Unter Punkt 2 werden im 

weiteren Verlauf die Wetterdaten in Form einer Tabelle angezeigt. Unter Punkt 3 finden Sie die 

aktuelle Konfiguration des Generators. Die Konfigurationsdaten entsprechen den Daten der beschriebenen 

generator_config.xml-Datei. 

2. Um Anhand der Konfiguration, unter Punkt 3 in Abbildung 4.38, Daten generieren zu können, 

benötigen Sie Wetterdaten. Hierfür betätigen Sie die Schaltfläche Wetterdaten laden. 

3. Wählen Sie die zu verwendende Wetterdaten-Datei im erscheinenden Dateiauswahldialog aus, 

(siehe Abbildung 4.39). Beachten Sie dabei die Anforderungen an die Struktur der Wetterdaten- 

Datei. 

537



Abbildung 4.39: SWF Toolbox – Auswahl der Wetterdaten 

4. Der Inhalt der ausgewählten Wetterdaten-Datei wird nun geladen und, wie unter Vorgang 1 erwähnt, 

in einer Tabelle dargestellt, (siehe Abbildung 4.40). 

538 

Abbildung 4.40: SWF Toolbox – Tabelle Wetterdaten



5. Durch Betätigen der Schaltfläche XML Konfiguration öffnen können Sie eine andere XML- 

Konfigurationsdatei laden. Dessen Inhalt ersetzt die bestehende Konfiguration aus Punkt 3 in Abbildung 

4.38. Die Schaltfläche Aktualisieren können Sie betätigen, sofern Sie die geladene XML- 

Konfigurationsdatei während der Programmlaufzeit geändert haben. 

6. Bevor Sie die Schaltfläche bzw. Funktion Daten generieren aufrufen, besteht die Möglichkeit die 

bestehende Konfiguration zu editieren. Dafür stehen Ihnen folgende Möglichkeiten zur Verfügung: 

a. Klicken Sie mit dem Cursor in der Konfigurationstabelle innerhalb der Spalten Name oder 

Abhaengigkeit, auf eine Tabellenzelle. Anschließend wird Ihnen eine zur Auswahl stehende 

Liste von verfügbaren Spaltennamen angezeigt, (siehe Abbildung 4.41). 

Abbildung 4.41: SWF Toolbox – Konfigurationstabelle Teil 1 

b. In den weiteren Spalten können Sie die Tabellenzellen durch einen Doppelmausklick editieren 

und nach erfolgter Änderung durch Betätigen der Taste Enter diese bestätigen, (siehe Abbildung 

4.42). 


c. Durch Rechtsklicks auf eine beliebige Tabellenzeile wird Ihnen ein Kontextmenü angezeigt. 

Das Kontextmenü bietet die Möglichkeit Tabellenzeilen hinzuzufügen, zu duplizieren oder zu 

löschen, (siehe Abbildung 4.43). 

539




d. Wie aus bekannten Tabellenkalkulations-Programmen können Sie die einzelnen Tabellenzeilen 

per Drag&Drop verschieben. 

Anmerkung: Die Konfiguration ist so anzulegen, dass die jeweilige Abhängigkeit bereits vorhanden 

bzw. zuvor generiert worden ist. Bspw. kann die Rotorgeschwindigkeit, welche von 

Leistungsabgabe abhängig ist, erst generiert werden wenn die Leistungsabgabe vollständig 

generiert worden ist. Dementsprechend müssen alle Tabellenzeilen mit dem Namen „Leistungsabgabe“ 

vor der Tabellenzeile „Rotorgeschwindigkeit“ aufgelistet werden. Weiterhin 

dürfen sich die Wertebereiche, sowohl von „Input_min“ und „Input_max“ als auch von 

„Output_min“ und „Output_max“, einer zu generierenden Spalte nicht überschneiden. Spalten 

ohne Abhängigkeiten, wie z.B. der in Abbildung 4.44 aufgeführte Betriebsstatus, werden 

ohne Abhängigkeit und „Input“ Wertebereiche angelegt. Folgende Abbildung erläutert die 

genannten Kriterien grafisch. 

Abbildung 4.44: SWF Toolbox – Richtige Konfiguration 

7. Sind alle Konfigurationen getätigt worden, können Sie durch Betätigen der Schaltfläche Daten 

generieren die Daten generieren. 

8. Die generierten Daten werden Ihnen in Form einer Tabelle innerhalb eines neuen Registerfeldes 

angezeigt, (siehe Abbildung 4.45). 

540



Abbildung 4.45: SWF Toolbox – Generierte Daten 

9. Durch Betätigen der, in Abbildung 4.45 gezeigten, Schaltfläche Speichern, können Sie die generierten 

Daten als Textdatei abspeichern. Diese Textdatei dient anschließend als Datenbasis für die 

im Folgenden erklärte Streamer Funktionalität. 

541



Datenübertragung an das SAP HANA System 

1. Durch einen Doppelklick auf die Funktion Streamer öffnen, öffnen Sie den Daten-Streamer und 

ein neues Registerfeld, namens Daten Streamer, wird angezeigt, (siehe Abbildung 4.46). 

Abbildung 4.46: SWF Toolbox – Daten Streamer 

In obiger Abbildung finden Sie unter Punkt 1 die Funktionsleiste. Unter Punkt 2 werden im weiteren 

Verlauf eine Auswertung der aktuellen WEA Anlagen in der Datenbank, in Form einer Tabelle, 

angezeigt. Unter Punkt 3 werden ebenfalls im Folgenden die zu übertragenden Daten, in Form 

einer Tabelle, angezeigt. Abschließend können Sie unter Punkt 4 Einstellungen zur Datenübertragung 

vornehmen und diese starten. 

2. Wenn Sie die Schaltfläche Übersicht laden betätigen, erhalten Sie unter Punkt 2 der Abbildung 

4.46 eine Übersicht über die aktuell vorhanden WEA in der Datenbank, (siehe Abbildung 4.47). 

542



Abbildung 4.47: SWF Toolbox – WEA Übersicht laden 

3. Betätigen Sie die Schaltfläche Daten öffnen und öffnen Sie mit Hilfe des erscheinenden Dateidialogs, 

die im vorherigen Abschnitt generierten Daten in Form der Textdatei. Diese werden anschließend 

unter Punkt 3 der Abbildung 4.46 angezeigt, (siehe Abbildung 4.48). 

Abbildung 4.48: SWF Toolbox – Generierte Daten öffnen 

543



4. Um die Datenübertragung der zuvor geladenen Daten zu veranlassen, müssen Sie in der unteren 

Funktionsleiste, (siehe Abbildung 4.46 Punkt 4) im Feld Windrad ID, die Nummer des Windrads 

dem die Daten zugordnet werden sollen, definieren. Weiterhin können Sie nach Bedarf im Feld 

Zeilenanzahl für Übertragung einer Reduzierung der zu übertragenden Zeilen vornehmen. Diese 

wird standartmäßig auf die Zeilenanzahl der geladenen Textdatei gesetzt, (siehe Abbildung 4.49). 

Abbildung 4.49: SWF Toolbox – Konfigurationsleiste des Daten Streamers 

5. Tragen Sie beispielhaft den Wert 10 im Feld Zeilenanzahl für Übertragung ein und starten Sie die 

Übertragung durch Betätigen der Schaltfläche Start. 

6. Die Datenübertragung wird initialisiert und der aktuelle Status bzw. die einzelnen Vorgänge werden 

Ihnen in Form eines aufkommenden Protokollfensters dargestellt, (siehe Abbildung 4.50). 

Abbildung 4.50: SWF Toolbox – Protokoll der Datenübertragung 

7. Nach erfolgter Datenübertragung wird das Protokollfenster automatisch geschlossen und ein aufkommender 

Dialog informiert Sie abschließend über die erfolgreiche Datenübertragung, (siehe 


544



Abbildung 4.51: SWF Toolbox – Dialog für erfolgreiche Datenübertragung 

8. Beenden Sie die Anwendung durch betätigen der X Schaltfläche im rechten oberen Eck. 

Anmerkung: Die beschriebenen Funktionalitäten der SWT Toolbox können Sie unabhängig voneinander 

nutzen. Bei Aufruf des „Datengenerators“ ohne VPN Verbindung erfolgt zwar eine Fehlermeldung 

über die fehlende Verbindung, bis auf die Auswahl der Datenbankspalten innerhalb der Konfigurationstabelle, 

stehen Ihnen alle Funktionen zur Verfügung. Der „Datenstreamer“ ist ebenfalls aufrufbar, 

eine Datenübertragung kann jedoch ohne VPN Verbindung nicht erfolgen. Des Weiteren kann 

der Aufbau einer VPN Verbindung auch mit einem separaten VPN Programm erfolgen. 

4.4 R/Rserve 

Ziel dieses Benutzerhandbuchs ist eine Einführung in die Programmiersprache und Softwareumgebung 

R. Ein besonderer Fokus liegt hierbei auf der Kombination aus R mit der In-Memory Technologie 

SAP HANA (High Performance Analytic Appliance). Hierfür soll zunächst R beschrieben werden. 

Danach soll die Installation eines Rserve Suse Linux Servers ausführlich dokumentiert werden. Abschließend 

sollen Beispiele für das Data Mining mit SAP HANA und R beschrieben werden. 

4.4.1 Einführung in R 

R ist eine Open Source Programmiersprache und Softwareumgebung für statistisches Rechnen und 

Grafiken. Diese ist Teil des GNU Projekts und auf vielen Plattformen (UNIX, Windows, MacOS) 

verfügbar. R ist in Anlehnung an die Programmiersprache S entstanden und dieser sehr ähnlich. Standardmäßig 

läuft R in einer Kommandozeilenumgebung, es stehen jedoch auch mehrere GUIs zur Verfügung. 

R bietet ein breites Spektrum an statistischen (lineare und nichtlineare Modellierung, klassische statistische 

Tests, Zeitreihen Analysen, Klassifikation, Clustering etc.) und graphischen Methoden und ist in 

hohem Maße erweiterbar. Es handelt sich um eine integrierte Softwarelösung für Datenmanipulation, 

Berechnungen und graphische Ausgaben. Neben einer effektiven Datenverarbeitung und -speicherung 

bietet R eine breite Palette an Operatoren für die Berechnung auf Arrays, graphische Hilfsmittel für 

545



die Datenanalyse und Anzeige am Bildschirm oder Ausdruck, sowie eine einfache und effektive Programmiersprache, 

welche Bedingungen, Schleifen, benutzerdefinierte rekursive Funktionen enthält 

(Wirtschaftsuniversität Wien 2012). 

Der Funktionsumfang von R kann durch eine Vielzahl von Paketen erweitert und an spezifische statistische 

Problemstellungen angepasst werden. Viele Pakete können direkt aus einer über die R-Console 

abrufbaren Liste ausgewählt und automatisch installiert werden. Zentrales Archiv für diese Pakete ist 

das Comprehensive R Archive Network. Für Data Mining stehen unter anderem die folgenden Packagess 

für R zur Verfügung (Pyrke 2007): 

RandomForest 

Party 

E1071 

nnets 

BayesTree 

gafit & rgenoud 

varSelRF 

arules 

Rweka 

Dprep 

Bioconductor 

Eine Übersicht der speziellen Packages für bestimmte Data Mining Methoden (beispielsweise Frequent 

Pattern Mining, Clustering, Klassifikation) kann bei Wikibooks (2012) eingesehen werden. 

Zudem bietet das R Package for Data Mining von Zhao (2012) ein Bündel unterschiedlicher Data Mining 

Algorithmen von verschiedenen Benutzern. Die bekannteste GUI für das Data Mining mit R 

heißt Rattle. 

4.4.2 Installation 

R wird nicht standardmäßig mit SAP HANA ausgeliefert, da R Open Source und unter der GPL lizensiert 

ist. Zudem bietet SAP keinen Support für R (SAP AG 2012 S. 3). In dem Projekt Smart Wind 

Farm Control (SWF) wird R als Inside-Out Variante, d.h. als Stored Procedure direkt innerhalb von 

SAP HANA ausgeführt (siehe Datenverarbeitungs (DV)-Konzept, Kapitel 4.3.1). Hierfür wird R sowie 

Rserve benötigt. Rserve ist ein TCP/IP Server, der es anderen Programmen erlaubt, R zu nutzen, 

ohne es zu initialisieren oder ein R Package einzubinden. R und Rserve müssen auf einem separaten 

System installiert werden, sie können nicht auf dem gleichen System wie SAP HANA laufen. Daher 

wird ein zusätzlicher Suse Linux Server als TCP/IP-Server benötigt (aktuell unterstützt SAP nur dieses 

Betriebssystem). Die Installation des Servers und die Anpassungen innerhalb von SAP HANA sollen 

im Folgenden beschrieben werden. 

546



Zunächst wird ein Suse Linux Server benötigt. Wichtig ist hierbei, dass es sich um eine 32 bit Version 

handelt. Die Projektgruppe nutzt die Version OpenSuse 12.2 auf dem Server hanasuse.informatik.uni-oldenburg.de 

mit dem Benutzer ruser. Dieser besitzt für den Befehl sudo root- 

Rechte (wichtig, da sonst keine Installationen vorgenommen werden können). Zudem wird der Compiler 

namens Gnu Compiler Collection (GCC) benötigt. Dieser kann mit dem folgenden Befehl auf Konsolenebene 

installiert werden: 

sudo zypper install gcc gcc-c++ gcc-fortran 

Der Prozess der Installation besteht aus drei Schritten (SAP AG 2012 S. 3): 

4. Installiere R (auf einem eigenen System) 

5. Installiere Rserve (auf einem eigenen System) 

6. SAP HANA Parameter anpassen 

Der genaue Ablauf wird sehr detailliert von Galindo (2012) beschrieben und ist für die Installation 

genutzt worden. Da bei der tatsächlichen Installation jedoch teilweise von der Anleitung abgewichen 

wurde, wird die Installation im Folgenden detailliert beschrieben. 

Anschließend kann mit dem ersten Schritt begonnen werden: Der Installation von R auf dem System. 

Hierfür muss der Source Code von R heruntergeladen, extrahiert und kompiliert werden. Dafür müssen 

auf Konsolenebene die folgenden Befehle ausgeführt werden: 

wget http://cran.r-project.org/src/base/R-2/R-2.13.0.tar.gz 

tar zxf R-2.13.0.tar.gz && cd R-2.13.0 

./configure --enable-R-shlib --with-readline=no --with-x=no 

make clean 

make 

make install 

Falls es hierbei während des make Befehls zu Fehlermeldungen kommt, ist make nicht automatisch 

mit GCC zusammen installiert worden. In diesem Fall hilft der folgende Befehl: 

sudo zypper install make 

Hinweis: Die Befehle make und make install können sehr lange dauern. 

Dann kann der zweite Schritt begonnen werden, die Installation von Rserve. Für den Download wird 

auf Konsolenebene folgender Befehl benötigt: 

wget http://www.rforge.net/Rserve/snapshot/Rserve_0.6-5.tar.gz 

Nun kann Rserve installiert und getestet werden: 

547



R 

install.packages("/PATH_TO_FILE/Rserve.tar.gz", repos = NULL) 

library("Rserve") #To test the installation. If there's no output, then 

it's working fine 

q() 

Falls dies nicht funktioniert, muss Rserve auf anderem Wege installiert werden: 

R CMD INSTALL Rserve_XXX.tar.gz 

Anschließend wird die Konfigurationsdatei für Rserve erstellt: 

vi /etc/Rserv.conf 

i 

maxinbuf 10000000 

Maxsendbuf 0 

remote enable 

#Press ESC key 

:wq 

Nun muss der Rserve Server nur noch gestartet werden: 

R CMD Rserve --RS-port 6311 --no-save --RS-encoding "utf8" 

Damit SAP HANA später auf R zugreifen kann, muss innerhalb des Linux Servers ein Port freigegeben 

werden. Die Projektgruppe nutzt hierfür den Port 6311. Falls ein anderer Port genutzt werden soll 

muss der obige Befehl entsprechend angepasst werden. 

Der Port kann folgendermaßen freigegeben werden: 

vi /etc/sysconfig/SuSEfirewall2 

/FW_SERVICES_EXT_TCP 

#Den obigen Befehl (Suche nach dem String FW_SERVICES_EXT_TCP) so 

#lange wiederholen bis man nicht in einem Kommentar sondern der realen 

#Eingabe steht. Anschließend mit den Pfeiltasten auf die Stelle hinter 

#dem „=“ Zeichen wechseln 

i #Eingabe 

ssh 6311 #gewünschten Port angeben 

#Anschließend mit den Pfeiltasten zu dem nächsten Punkt 

#FW_SERVICES_EXT_UDP wechseln und dort Cursor hinter das „=“ Zeichen 

6311 


:wq 

Abschließend beginnt der dritte Schritt, die Anpassung innerhalb von SAP HANA. Hierfür müssen 

innerhalb von SAP HANA Studio die folgenden Befehle ausgeführt werden: 

1. Klicken Sie mit der rechten Maustaste auf den Systemknoten im Navigatortab wählen Sie Administration 


548



Abbildung 4.52: SAP HANA Studio - Administration 

2. Wählen Sie den Configuration Tab aus. 

3. Wählen Sie anschließend die indexserver.ini aus. 

4. Danach wählen Sie bitte die calcengine aus. 

Abbildung 4.53: SAP HANA Studio - CAM 

5. Dann können Sie folgende Parameter eingeben: 

a. cer_rserve_addresses – IP-Adresse der Rserve Servers inklusive Port. Wichtig: Es 

muss die IP-Adresse sein und keine Domain! 

b. cer_rserve_maxsendsize - 0 

c. cer_timeout - 300 

Nun steht die Verbindung zwischen SAP HANA und R. Da über die Rserve Verbindung jedoch keine 

grafischen Ausgaben angezeigt werden können, die für das Data Mining benötigt werden, müssen 

549



zwei weitere Installationen auf dem Suse Linux Server vorgenommen werden. Um die erstellten Modelle 

in Bildern speichern zu können, wird das Software Package Cairo benötigt. 

sudo zypper install cairo-devel 

Anschließend kann das Package Cairo in R installiert werden. Zusätzlich sollte an dieser Stelle rpart 

installiert werden, das für das Data Mining genutzt wird. 

R 

>install.packages("Cairo") 

>install.packages("rpart") 

Falls HANA nicht auf die Packages zugreifen kann muss der Rserve Server neu gestartet werden. 

Die durch Cairo erstellten Dateien müssen in einem Verzeichnis gespeichert werden. Hierfür ist im 

Projekt SWF das Verzeichnis /tmp/rtest angelegt worden. Zudem ist ein Standard-Emailinhalt in der 

Datei mailinhalt.txt erstellt worden. 

cd /tmp 

mkdir rtest 

chmod 777 rtest 

cd rtest 

vi mailinhalt.txt 

i 

Guten Tag, 

anbei finden Sie die aktuelle Auswertung. 

Mit freundlichen Gruessen, 



:wq 

Damit die auf diese Weise erstellten Grafiken betrachtet werden können, wird ein Emailclient benötigt, 

über den die Datei per Email zugesendet wird. Es ist nicht möglich, die Grafik direkt an SAP 

HANA zu übergeben oder anzuzeigen, daher wird dieser Workaround genutzt. Die Projektgruppe 

SWF setzt für das Versenden der Emails mutt ein. 

sudo zypper install mutt 

4.4.3 Beispiele 

Im Folgenden sollen zunehmend komplexere Beispiele für das Data Mining mit R und SAP HANA 

beschrieben werden. Die hierfür benötigten Beispieltabellen werden ebenfalls beschrieben. 

Anlegen von Beispiel-Tabellen 

Als einfaches Beispiel für Data Mining soll der klassische Entscheidungsbaum 

darüber, ob ein Tennisspiel stattfindet oder nicht, erstellt werden. 

Für dieses Beispiel ist der finale Entscheidungsbaum bereits bekannt (siehe 

Hüppe 2010). 

CREATE TABLE rtest( 

550



vorhersage VARCHAR(20), 

temperatur VARCHAR(20), 

luftfeuchtigkeit VARCHAR(20), 

windig VARCHAR(20), 

spiel VARCHAR(20) 

); 

INSERT INTO rtest(vorhersage, temperatur, luftfeuchtigkeit, windig, spiel) 

VALUES('sonnig', 'heiß', 'hoch', 'nein', 'nein'); 


VALUES('sonnig', 'heiß', 'hoch', 'ja', 'nein'); 


VALUES('bewölkt', 'heiß', 'hoch', 'nein', 'ja'); 


VALUES('regen', 'mild', 'hoch', 'nein', 'ja'); 


VALUES('regen', 'kalt', 'normal', 'nein', 'ja'); 


VALUES('regen', 'kalt', 'normal', 'ja', 'nein'); 


VALUES('bewölkt', 'kalt', 'normal', 'ja', 'ja'); 


VALUES('sonnig', 'mild', 'hoch', 'nein', 'nein'); 


VALUES('sonnig', 'kalt', 'normal', 'nein', 'ja'); 


VALUES('regen', 'mild', 'normal', 'nein', 'ja'); 


VALUES('sonnig', 'mild', 'normal', 'ja', 'ja'); 


VALUES('bewölkt', 'mild', 'hoch', 'ja', 'ja'); 


VALUES('bewölkt', 'heiß', 'normal', 'nein', 'ja'); 


VALUES('regen', 'mild', 'hoch', 'ja', 'nein'); 

Zudem wird eine Tabelle für die Data Mining Ergebnisse anlegt. 

CREATE TABLE MINING_RESULT( 

ERGEBNIS VARCHAR(200) 

) 

Da die Ergebnisse aus R zurück an HANA übergeben werden müssen, wird das Übergabeobjekt als 

Typ T_MINING_RESULT angelegt. 

DROP TYPE T_MINING_RESULT; 

CREATE TYPE T_MINING_RESULT AS TABLE ( 

MININGRESULT VARCHAR(200) 

); 

Beispiel 1: Multiplikation in R 

Als erste Einführung in die Nutzung von SAP HANA mit R soll eine einfache Multiplikation durchgeführt 

werden. Hierfür wird zunächst die gewünschte R Funktionalität als Prozedur multiplikation() in 

SAP HANA angelegt. Falls die Prozedur bereits existiert, muss sie mittels des DROP-Befehls gelöscht 

551



werden. Es ist in HANA nicht möglich, Prozeduren der Sprache RLANG zu erstellen, die keinen 

Übergabeparameter erhalten. Daher wird an dieser Stelle bereits die Tabelle RTEST übergeben, obwohl 

sie für dieses Beispiel nicht benötigt wird. Innerhalb der Prozedur werden die Zahlen 2, 3, 4 und 

5 miteinander multipliziert und als Ergebnis zurückgegeben. 

DROP PROCEDURE multiplikation; 

CREATE PROCEDURE multiplikation(IN spiele RTEST, OUT result 

T_MINING_RESULT) 


BEGIN 

a = 2*3*4*5 

result



Temperatur = as.character(spiele$TEMPERATUR) 

Luftfeuchtigkeit = as.character(spiele$LUFTFEUCHTIGKEIT) 

Windig = as.character(spiele$WINDIG) 

Spiel = as.character(spiele$SPIEL) 





#Baum erzeugen. “minsplit” wird hier auf 1 gesetzt (nur 1 Element 

#pro Knoten benoetigt), da nur so wenige Daten vorhanden sind, dass 

#R andernfalls keinen Baum erzeugen würde. 

#Als method wurde "class", dh Klassifikation gewählt 

fit



Als Ergebnis wird eine E-Mail an die oben angegebene Emailadresse gesendet. Diese enthält den im 

Abschnitt Anlegen von Beispiel-Tabellen erstellten Emailtext. Zudem enthält sie zwei Attachments: 

Einen Entscheidungsbaum und das Ergebnis der Kreuzvalidierung. 

Abbildung 4.54: Ergebnis der Klassifikation 

In Abbildung 4.54 wird der durch R erstelle Entscheidungsbaum dargestellt. Dieser entspricht nicht 

dem in Hüppe (2010) dargestellten Entscheidungsbaum, da rpart nur binäre Splits vornehmen kann. 

Der Baum ist jedoch für alle im Abschnitt Anlegen von Beispiel-Tabellen dargestellten Datensätze 

gültig und somit ebenfalls korrekt. 

554



Abbildung 4.55: Kreuzvalidierung der Klassifikation 

Rpart führt automatisch eine 10-fache Kreuzvalidierung durch, um die Gültigkeit des Modells zu 

überprüfen. Bei der Kreuzvalidierung werden die Modelldaten in zwei sich gegenseitig ausschließende 

Mengen aufgeteilt. Die sog. Trainingsmenge wird dazu verwendet, ein Modell zu erstellen, die sog. 

Testmenge dient der Bestätigung des Modells, indem das erstellte Modell auf diese Daten angewendet 

wird und die Ergebnisse mit den tatsächlichen Werten verglichen werden. Die in Abbildung 4.55 dargestellten 

CP (Complexity Parameter) können für das Pruning genutzt werden, d.h. dem Abschneiden 

von Zweigen, um Überanpassung vorzubeugen. 

555



4.5 SAP UI5 Reporting 

Dieses Benutzerhandbuch verschafft einen Überblick über die Funktionen und Bedienung der, von der 

Teilgruppe realisierten, UI5-Reporting Webanwendung. 


Element 


Betriebssystem Windows, Mac, Linux 

Webbrowser Internet Explorer 10.X 

Opera 12.X 

Chrome 25.X 

Programme Open Vpn Client 1.X 

Authentifizierung SAP HANA HPI VPN Config, HPI VPN Login Daten (Benutzername 

und Passwort), SAP HANA Login Daten (Benutzername und Passwort) 

4.5.2 Betrieb 

Tabelle 4.2: SAP UI5 – Voraussetzungen und Anforderungen 

1. Starten Sie den Open VPN Client mit Administrator-Rechte und erstellen Sie, wie auf Abbildung 

4.56 zu sehen, eine Verbindung mit dem VPN-Netzwerk von HPI (FSOC-Lab). 

Abbildung 4.56: VPN-Verbindung 

2. Melden Sie sich mit Ihrem korrekten Benutzernamen und Passwort an (siehe Abbildung 4.57). 

556



Abbildung 4.57: VPN-Verbindung - Benutzer 

3. Öffnen Sie einen beliebigen Webbrowser und rufen Sie die Webseite 

http://hana-2.fsoc.hpi.uni-potsdam.de:8003/swf/smartwindfarmcontrol/WebContent/index.html 

auf. 

4. Die Webanwendung besteht aus einer Top-Leiste (oben), einer Menü-Leiste auf der linken Seite 

und einem zentralen Content-Block (siehe Abbildung 4.56). Auf der Top-Leiste sind der angemeldete 

Benutzer, die Kennzahlen Temperatur, Windgeschwindigkeit und Leistungsabgabe sowie das 

Datum und die Uhrzeit zu sehen. Auf der Menü-Leiste ist nur die Home-Taste eingeblendet. Der 

zentrale Content-Block stellt die Verknüpfungen zu den vier Komponenten bzw. Seiten wie, Monitoring, 

Log, Reporting und Datamining zur Verfügung. 

Abbildung 4.58: SAP UI5 – Home - Übersicht 

557



4.1. Durch betätigen der Verknüpfung Monitor rufen Sie die Monitoring Webseite auf (siehe Abbildung 

4.59). 

Abbildung 4.59: SAP UI5 – Home - Monitor 

4.2. Auf der linken Menü-Leiste sind nun alle Funktionen der Startseite eingeblendet. Der Inhalt des 

zentralen Content-Blockes ist durch das Monitoring-Content ersetzt worden. Die Anlagen des 

Windparks sind in Form einer Liste dargestellt. Um genauere Informationen zu einer bestimmten 

Anlage zu erhalten, müssen Sie diese in der Liste auswählen. Alternativ können Sie das 

Dropdown-Menü, welches sich in der rechten oberen Ecke befindet, verwenden, um zu der detaillierteren 

Ansicht einer Anlage zu gelangen (siehe Abbildung 4.60). 

558 

Abbildung 4.60: SAP UI5 – Monitor



4.3. Sobald Sie eine Anlage ausgewählt haben, wird eine detaillierte Sicht dieser Anlage dargestellt 

(siehe Abbildung 4.61). Die wichtigsten Kennzahlen sind in tabellarischer Form angezeigt. Links 

neben der Tabelle befindet sich eine visuelle Darstellung der Anlage und eine Verknüpfung zu 

der Log-Tabelle (Maintenance History) (siehe 4.2). 

Abbildung 4.61: SAP UI5 – Monitor - Erweitert 

4.4. Nach dem betätigen des Log-Buttons wird eine Tabelle mit allen Fehlermeldungen dargestellt. 

Die Spalten können sortiert oder gefiltert werden (siehe Abbildung 4.62). 

Abbildung 4.62: SAP UI5 – Log 

4.5. Durch das Auswählen der Reporting-Verknüpfung gelangen Sie zu einer Liste mit bereits vorbereiteten 

Reports (siehe Abbildung 4.63). 

559



Abbildung 4.63: SAP UI5 – Reporting - Übersicht 

4.5.1. Der erste Bericht, Average Performance per Turbine zeigt die durchschnittliche Leistungsabgabe 

der einzelnen Anlagen der gesamten Periode an (siehe Abbildung 4.64). 

Abbildung 4.64: SAP UI5 – Reporting – Report 1 

4.5.2. Beim zweiten Bericht, Average Performance and Wind Speed per Turbine werden die durchschnittliche 

Leistungsabgabe und die durchschnittliche Windgeschwindigkeit der einzelnen Anlagen 

für die Gesamtperiode angezeigt (siehe Abbildung 4.65). 

560




4.5.3. Der dritte Report, Average Performance per Status zeigt die durchschnittliche Leistungsabgabe 

des Windparks für den jeweiligen Betriebsstatus an (siehe Abbildung 4.66). 


4.5.4. Während der letzte Report, Average Generator and Wind Speed per Status die durchschnittliche 

Generatordrehzahl und Windgeschwindigkeit des Windparks den unterschiedlichen Betriebsstatus 

gegenüberstellt (siehe Abbildung 4.67). 

561




4.6. Die Datamining-Funktion ist im Rahmen der Projektgruppe nicht realisiert worden (siehe Abbildung 

4.68). 

Abbildung 4.68: SAP UI5 – Data Mining 

562



4.6 Microsoft Excel Reporting 

Anmerkung: Die im Folgenden beschriebene Microsoft Excel Datei namens SmartWindFarm.xlsx, ist 

in der beigefügten DVD in dem Ordner „04_Excel_Reporting“ zu finden. 

Das Microsoft Excel Reporting Handbuch verschafft den Lesern einen Überblick über die Grundfunktionen 

von Microsoft Excel als Reporting-Tool. Zuerst werden die Voraussetzungen und die Anforderungen 

für die Nutzung von Excel und nachfolgend die Tätigkeiten bzw. Workflows beschrieben. Zur 

Unterstützung und einer besseren Übersichtlichkeit werden diese zusätzlich anhand von Abbildungen 

dargestellt. 


Element 

Betriebssystem 

Programme 

Authentifizierung 


Windows, Mac 

Open Vpn Client 1.X, Microsoft Excel 2013, SAP HANA Studio Revision 

48, SAP HANA Client Revision 48, ODBC Data Source Administrator 

SAP HANA HPI VPN Config, HPI VPN Login Daten (Benutzername 

und Passwort), SAP HANA Login Daten (Benutzername und Passwort) 

Tabelle 4.3: Excel – Voraussetzungen und Anforderungen 

4.6.2 Betrieb 

1. Starten Sie den Open VPN Client mit Administrator-Rechte und erstellen Sie, wie auf Abbildung 

4.69 zu sehen, eine Verbindung mit dem VPN-Netzwerk von HPI (FSOC-Lab). 

Abbildung 4.69: VPN-Verbindung 

2. Melden Sie sich mit Ihrem korrekten Benutzernamen und Passwort an (siehe Abbildung 4.70). 

563



Abbildung 4.70: VPN-Verbindung - Benutzer 

3. Starten Sie Microsoft Excel oder öffnen Sie die Datei SmartWindFarm.xlsx. 

4. Das Menü DATA stellt viele Funktionen zur Datenverarbeitung zur Verfügung. Mit den Gruppen 

Get External Data und Connections verwalten Sie die vordefinierten Verbindungen bzw. SQL- 

Abfragen, Sie können jedoch auch eigene anlegen (siehe Abbildung 4.71). 

Abbildung 4.71: Benutzerhandbuch Excel - Menü 

5. Die Projektgruppe hat drei Berichte vordefiniert. Diese können Sie über den Reiter im unteren 

Bereich finden und auswählen (siehe Abbildung 4.72). 

Abbildung 4.72: Benutzerhandbuch Excel - Reiter 

5.1. AVAILON_REPO1 stellt den Bericht Durchschnittliche Leistungsabgabe und Windgeschwindigkeit 

pro Monat für das Jahr 2012 zur Verfügung (siehe Abbildung 4.73). 

564



Abbildung 4.73: Benutzerhandbuch Excel – Charts 1 

5.2. AVAILON_REPO2 stellt den Bericht Durchschnittliche Leistungsabgabe und Windgeschwindigkeit 

pro Gondelposition für das Jahr 2012 zur Verfügung (siehe Abbildung 4.74). 


565



5.3. AVAILON_REPO3 stellt den Bericht Durchschnittliche Leistungsabgabe, Windgeschwindigkeit 

und Generatordrehzahl der Anlage 30 für Mai 2012 zur Verfügung (siehe Abbildung 4.75). 


566



5. Fazit 

Rückblickend ist das finale Anliegen der Teilgruppe gewesen, die Problematik des erhöhten Wartungsaufwandes 

von Windenergieanlagen im Offshore-Bereich aus verschiedenen Blickwinkeln zu 

thematisieren und einen informationstechnischen Lösungsweg aufzuzeigen. Neben dem Erlangen von 

Wissen im Themengebiet der Wartung von Windenergieanlagen, insbesondere im Offshore Bereich, 

hat die Entwicklung einer unterstützenden Windpark-Maintenance-Plattform auf Basis des In-Memory 

Systems SAP HANA im Vordergrund gestanden. Dessen Ziel sollte es sein, das gesamte Datenaufkommen 

von Windenergieanlagen erfassen zu können, sowie unter Verwendung von Data Mining 

Methoden Fehlerketten innerhalb dieser Daten aufzuzeigen und für eine vorausschauende Wartung zu 

nutzen. 

Der Projektablauf, angefangen von der Definition der Aufgabenstellung über die Erstellung des Fachund 

DV-Konzepts bis hin zur abschließenden Projektdokumentation, ist durch zahlreiche strategische 

Anpassungen und Rückschläge geprägt worden. Dies spiegelt jedoch das Bild vieler Projekte in der 

Realität wieder und hat eine der größten Herausforderungen für die Teilgruppe dargestellt. Weiterhin 

war die Durchführung eines Projektes im Rahmen der Forschung, welches auf Basis einer Vision entstanden 

ist, für alle Projektmitglieder neu. Die vorgesehene klassische Projektvorgehensweise hat sich 

im Laufe des Projektes, aufgrund der veränderten Ziele und Erwartungen, zu einer agilen Vorgehensweise 

entwickelt. Dabei ist allen Projektmitgliedern klar geworden, dass die vollständige Realisierung 

aller Ziele nicht ausschlaggebend für den Erfolg des Projektes ist. Vielmehr sollten der Weg bis zum 

angestrebten Ziel und die dabei gewonnenen Erkenntnisse sowie Errungenschaften den Erfolg widerspiegeln. 

Nachdem die Partnerschaft mit der BTC AG nicht zustande gekommen ist, hat sich die Suche nach 

einem neuen geeigneten Projektpartner schwieriger gestaltet als vorerst angenommen. Einer der ausschlaggebenden 

Gründe ist der Aspekt gewesen, dass bspw. Windenergieanlagenhersteller, dem Aufdecken 

von Fehlerketten aus Imagegründen eher negativ gegenüberstehen. Dementsprechend ist die 

Beschaffung der benötigten Sensordaten einer Windenergieanlage ebenso schwierig gewesen. Das 

Zentrum für Windenergieforschung der Universitäten Oldenburg, Hannover und Bremen, namens 

ForWind, ist als erster Partner in Erscheinung getreten und hat den ersten großen Meilenstein dargestellt. 

Im späteren Verlauf des Projektes ist es der Teilgruppe von Seiten ForWinds gelungen, Daten 

auf Sekundenbasis zu bekommen. Diese sind zwar anonymisiert gewesen und haben nicht den erhofften 

Umfang an Attributen aufgewiesen, haben jedoch trotzdem eine gute Ausgangsbasis für die geplanten 

Tätigkeiten ermöglicht. Weiterhin ist unerwartet eine weitere Partnerschaft mit der Availon 

GmbH kurz vor Ende des Projektes geschlossen worden. Aus diesem ernsthaften wirtschaftlichen Interesse 

an den Zielen der Projektgruppe, ist erstmals die Stellung realer Daten resultiert. Diese sind, 

soweit es zeitlich möglich war, noch mit in die Projektarbeit eingeflossen. 

Die Idee, die anfangs noch unvollständigen Projektziele in vier Arbeitspakete mit differenzierten Zielen 

aufzuteilen, stellte sich als sehr hilfreich heraus. Dadurch ist vorausschauend sichergestellt wor- 

567



den, dass bei den erfolgten Strategieanpassungen nicht zwangsläufig alle Ziele überarbeitet werden 

mussten. 

Auf diese Weise hat sich das erste Arbeitspaket, bei dem sich die Projektmitglieder erfolgreich mit den 

Themenbereichen WEA und SAP HANA vertraut gemacht haben, zusätzlich um Aufgaben zur Propagierung 

des Themas erweitert. Dahingehend ist nicht nur Wissen durch Teilnahme an einem einmonatigen 

Seminar zur In-Memory Technologie oder der COAST Tagung aufgebaut worden, sondern auch 

das Thema aktiv, in Form von Präsentationen, Papers und einem Plakat, nach außen getragen worden. 

Bspw. ist eine Präsentation beim HPI und die Erstellung eines mehrseitigen Papers für die BUIS Tagung 

erfolgt. Weiterhin sind von Seiten der Teilgruppe einige Verbesserungenvorschläge und Fehler, 

für das SAP HANA System, an das HPI kommuniziert worden. 

Im zweiten Arbeitspaket, mit dem Aufgabenschwerpunkt der Analyse und Übernahme der Windpark- 

Datenstruktur, ist auf Basis von recherchierten Kennzahlen, eigenen Erkenntnissen und den zur Verfügung 

gestellten Windparkdaten erfolgreich ein umfangreiches und dynamisches Datenbankmodell für 

die Windpark-Maintenance-Plattform entstanden. Darüber hinaus ist ein ausgereifter ETL-Prozess 

unter Verwendung der Software Pentaho Data Integration CE für die durch ForWind zur Verfügung 

gestellten Daten entwickelt worden. 

Während des dritten Arbeitspakets, der Simulation eines Windparks, ist die vollständige Realisierung 

der auf Java basierenden SWF Toolbox erfolgt. Diese ermöglicht die Generierung von WEA-Daten 

sowie die Simulation eines kontinuierlichen Datenstroms bzw. -transfers dieser in das SAP HANA 

System. 

Abschließend ist im vierten Arbeitspaket für die Analyse der Daten die generelle Möglichkeit Data 

Mining mit R in SAP HANA zu betreiben, mit Hilfe eines gesonderten Servers, geschaffen worden. 

Darauf aufbauend sind die ersten Data Mining Prozeduren unter Verwendung der von der Availon 

GmbH zur Verfügung gestellten Realdaten entstanden. Für das Reporting ist sowohl eine anschauliche 

Lösung in Microsoft Excel, also auch eine Webanwendung mit Hilfe von der verspätet Verfügbaren 

SAP UI5 Umgebung umgesetzt worden. 

Im Gesamten ist die Teilgruppe mit den Ergebnissen dieses Projektes sehr zufrieden. Trotz der zahlreichen 

strategischen Anpassungen, der erschwerten Datenbeschaffung, der fehlenden SAP BO Lizenzen 

sowie der späten Verfügbarkeit der SAP HANA Zugänge und weiteren Problemen, ist die Teilgruppe 

der Überzeugung, eine zufriedenstellenden Grundlage für eine Windpark-Maintenance- 

Plattform erschaffen zu haben. Insbesondere die vorliegende Dokumentation zeigt, dass viele Aktivitäten 

erfolgt sind und eine gute Basis, mit Hilfe der detaillierten technischen Beschreibungen und Handbüchern, 

für darauf aufbauende Projekte geschaffen worden ist. Vorausblickend kann sich die Teilgruppe 

vorstellen, dass das Thema sowohl technisch als auch thematisch von Interesse ist. Zum einen 

können in weiteren Anwendungsfeldern mit der In-Memory Technology von SAP HANA Mehrwerte 

geschaffen werden und zum anderen kann das Data Mining für die vorausschauende Wartung in Zusammenarbeit 

mit der Availon GmbH erforscht werden. 

568



6 Literaturverzeichnis 

INTERNETQUELLEN 

Galindo, A. T. (2012): When SAP HANA met R – First kiss, URL: 

http://scn.sap.com/community/developer-center/hana/blog/2012/05/21/when-sap-hana-met-r--firstkiss, 

(Zugriff am: 05.12.2012) 

Hüppe, C. (2010): ID3, URL: http://www-ai.cs.unidortmund.de/SOFTWARE/ADT/DOC/diplomarbeit/node48.html.de, 

(Zugriff am: 01.02.2013) 

Kiani-Kreß, R. & Stölzel, T. (2013): Wirtschaftswoche - Das Mogelgeschäft mit den Bonusmeilen. 

URL: http://www.wiwo.de/unternehmen/dienstleister/fluggesellschaften-das-mogelgeschaeft-mit-denbonusmeilen/7822644.html, 

(Zugriff am: 28.02.2013). 

Lohninger, H. (2012): Kreuzvalidierung, URL: 

http://www.statistics4u.com/fundstat_germ/cc_cross_validation.html, (Zugriff am: 03.02.2013) 

Pyrke, A. (2007): Introducing R, URL: 

http://www.andypryke.com/twiki/pub/Andypublic/R/Introducing_R.ppt, (Zugriff am: 03.12.2012) 

SAP (2012): SAP HANA Predictive Analytics Library (PAL Reference – SAP HANA Appliance 

Software SPS 05, URL: https://help.sap.com/hana/hana_dev_pal_en.pdf, (Zugriff am: 10.03.2013) 

SAP AG (2012): SAP HANA R Integration Guide, ULR: 

http://help.sap.com/hana/hana_dev_r_emb_en.pdf, (Zugriff am: 02.12.2012) 

SAP Database – Development Guide (2012): SAP HANA Database Developer Guide, URL: 

http://www.saphana.com/servlet/JiveServlet/downloadBody/1253-102-1- 

1665/20111021%20SAP%20HANA%20Database%20Development%20Guide%20- 

%20Beta%20Preview.pdf (Zugriff am 18.03.2013) 

SAP UI5 (2013): UI Development Toolkit für HTML5 (SAPUI5) (neu), URL: 

https://help.sap.com/saphelp_nw73ehp1/helpdata/de/e2/bc731ab39b4057a6fcee46ccb64034/content.ht 

m?frameset=/de/a3/721c134fdb4f1fbe774cfbfa9be66d/frameset.htm (Zugriff am 18.03.2013) 

Selfhtml (2007): Stylesheets und HTML, URL: http://de.selfhtml.org/css/intro.htm, (Zugriff am 

18.03.2013) 

Wikibooks (2012): Data Mining Algorithms in R, URL: 

http://en.wikibooks.org/wiki/Data_Mining_Algorithms_In_R, (Zugriff am: 03.12.2012) 

569



Wikipedia o.J., Benedikt XVI, URL: http://de.wikipedia.org/wiki/Benedikt_XVI., (Zugriff am: 

28.02.2013). 

Wirtschaftsuniversität Wien (2012): R Project, URL: http://www.r-project.org/, (Zugriff am: 

05.12.2012) 

Zhao, Y. (2012): R Package for Data Mining, URL: http://www.rdatamining.com/package, (Zugriff 

am: 05.12.2012) 

BÜCHER 

Ende, M. (1979): Die unendliche Geschichte, 3. Aufl., Stuttgart: Thienemann Verlag. 

Witten, I. H. & Frank, E. & Hall, M. A. (2011): Data Mining – Practical Machine Learning Tools and 

Techniques, 3. Aufl., Burlington: Elsevier. 

JOURNALS 

Conley, T. G. & Galeson, D. W. (1998): Nativity and wealth in mid-nineteenth century cities, Journal 

of Economic History 98(58), S. 468-493. 

570



Anhang 

A.1. Interviewfragen Smart Wind Farm Control 

571



A.2. Protokoll BTC 23.05.2012 

572



573



574



575



576



A.3. Protokoll Prof. Peinke 06.08.2012 

577



578



579



580



581



582



583



584



585



A.4. Paper Future Soc Lab Day 

586



587



588



589



A.5. Plakat Future Soc Lab Day 

590



A.6. Präsentation Future Soc Lab Day 14.11.2012 

591



592



593



594



595



596



597



598



599



600



A.7. Protokoll ForWind 29.11.2012 

601



602



603



604



605



A.8. Strategieänderung 03.12.2012 

606



A.9. Protokoll COWS 17.12.2012 

607



608



609



610



A.10. Paper 5. BUIS Tagung 

611



612



613



614



615



616



617



618



619



A.11. Protokoll HPI/SAP 24.01.2013 

620



621



622



623



624



625



626



627



A.12. Protokoll Availon 31.01.2013 

628



629



630



631



632



A.13. Protokoll Wind Energy Workshop 13.02.2013 

633



634



635



A.14. Datenbankmodell 

Abbildung A.1: Datenbankmodell 

636


Technischer Vergleich 




637



Inhaltsverzeichnis Technischer Vergleich 




1. Einleitung ......................................................................................................................... 641 

2. Vorstellung der Anwendungsfälle ................................................................................... 642 

2.1 Teilgruppe Analytisches CRM ................................................................................... 642 

2.2 Teilgruppe Jinengo ..................................................................................................... 643 

2.3 Teilgruppe Smart Wind Farm ..................................................................................... 643 

3. Methodik .......................................................................................................................... 644 

3.1 Nichtfunktionale Anforderungen ................................................................................ 645 

3.2 Funktionale Anforderungen ........................................................................................ 647 

3.2.1 Database ........................................................................................................... 647 

3.2.2 ETL .................................................................................................................. 647 

3.2.3 Analytical Services .......................................................................................... 648 

3.2.4 Reporting ......................................................................................................... 649 

3.2.5 Data Mining ..................................................................................................... 649 

4. Database ........................................................................................................................... 650 

4.1 SAP HANA ................................................................................................................ 650 

4.2 Microsoft SQL Server 2012 ....................................................................................... 651 

4.3 Oracle Database 11g ................................................................................................... 652 

4.4 Vergleich Databases ................................................................................................... 653 

5. ETL .................................................................................................................................. 654 

5.1 Pentaho Data Integration CE ...................................................................................... 654 

5.2 Microsoft SQL Server Integration Services ............................................................... 656 

5.3 Vergleich ETL ............................................................................................................ 657 

6. Analytical Services .......................................................................................................... 658 

6.1 Microsoft SQL Server Analysis Services ................................................................... 658 

6.2 IBM Cognos Framework Manager ............................................................................. 659 

6.3 SAP HANA ................................................................................................................ 660 

6.4 Vergleich Analytical Services .................................................................................... 661 

7. Reporting ......................................................................................................................... 662 

7.1 Microsoft SQL Reporting Services ............................................................................ 662 

7.2 Qlikview ..................................................................................................................... 663 

7.3 IBM Cognos Report Studio ........................................................................................ 664 

7.4 Microsoft Excel .......................................................................................................... 665 

7.5 Vergleich Reporting ................................................................................................... 667 

8. Data Mining ..................................................................................................................... 668 

8.1 IBM SPSS Modeler .................................................................................................... 668 

8.2 R ................................................................................................................................. 669 

8.3 Vergleich Data Mining ............................................................................................... 670 

9. Fazit ................................................................................................................................. 671 

638




Abbildung 2.1: Prozessübersicht analytisches CRM ............................................................. 642 


Tabelle 3.1: Bewertungsskala ................................................................................................ 644 

Tabelle 3.2: Übergreifende nichtfunktionale Anforderungen ................................................ 646 

Tabelle 3.3: Database spezifische funktionale Anforderungen .............................................. 647 

Tabelle 3.4: ETL spezifische funktionale Anforderungen ..................................................... 648 

Tabelle 3.5: Analytical Services spezifische funktionale Anforderungen ............................. 648 

Tabelle 3.6: Reporting spezifische funktionale Anforderungen ............................................ 649 

Tabelle 3.7: Data Mining spezifische funktionale Anforderungen ........................................ 650 

Tabelle 4.1: Bewertung Database SAP HANA ...................................................................... 651 

Tabelle 4.2: Bewertung Database Microsoft SQL Server 2012 ............................................. 652 

Tabelle 4.3: Bewertung Database Oracle Database 11g ........................................................ 653 

Tabelle 4.4: Vergleich Databases ........................................................................................... 653 

Tabelle 5.1: Bewertung ETL Pentaho Data Integration CE ................................................... 655 

Tabelle 5.2: Bewertung ETL Microsoft SQL Integration Services ....................................... 657 

Tabelle 5.3: Vergleich ETL .................................................................................................... 657 

Tabelle 6.1: Bewertung Analytical Services Microsoft SQL Analysis Services ................... 659 

Tabelle 6.2: Bewertung Analytical Services Microsoft IBM Cognos Framework Manager . 660 

Tabelle 6.3: Bewertung Analytical Services SAP HANA ..................................................... 661 

Tabelle 6.4: Vergleich Analytical Services ............................................................................ 661 

Tabelle 7.1: Bewertung Reporting Microsoft SQL Reporting Services ................................ 663 

Tabelle 7.2: Bewertung Reporting Qlikview ......................................................................... 664 

Tabelle 7.3: Bewertung Reporting IBM Cognos Reporting Studio ....................................... 665 

Tabelle 7.4: Bewertung Reporting Microsoft Excel .............................................................. 666 

Tabelle 7.5: Vergleich Reporting ........................................................................................... 667 

Tabelle 8.1: Bewertung Data Mining IBM SPSS Modeler .................................................... 668 

Tabelle 8.2: Bewertung Data Mining R ................................................................................. 669 

Tabelle 8.3: Vergleich Data Mining ....................................................................................... 670 

639




ASP Active Server Pages 

CRM Customer Relationship Management 

DB Database 

ERP Enterprise Resource Planning 

ETL Extract, Transform, Load 

FTP File Transfer Protocol 

GUI Graphical User Interface 

IT Information Technology 

MS Microsoft 

ODBC Open Database Connectivity 

OLAP Online Analytical Processing 

OLE DB Object Linking and Embedding Database 

PL/SQL Procedural Language/ Structured Query Language 

RSS Rich Site Summary 

SQL Structured Query Language 

T-SQL Transact-SQL 

XML Extensible Markup Language 

640



1. Einleitung 

Die in der Business Intelligence (BI) verortete Projektgruppe Cuberunner der Carl von Ossietzky 

Universität Oldenburg bearbeitet in drei Teilgruppen verschiedene Anwendungsfälle. Um eine 

Vergleichbarkeit zwischen den in den Anwendungsfällen verwendeten Technologien herzustellen, soll 

ein teilgruppenübergreifender Technologievergleich erstellt werden. 

Zu Beginn der Projektgruppe war geplant, dass gleiche Anwendungen von mehreren Gruppen bzw. 

gleiche Anwendungsfelder in den Gruppen mit unterschiedlichen Technologien bearbeitet werden. 

Eine Schnittmenge beruhte so zum Beispiel darauf, dass Lösungen von SAP in zwei Gruppen 

eingesetzt werden sollten. Eine weitere Schnittmenge fand sich in der Analyse von Kundendaten über 

zwei Teilgruppen, die eine Vergleichbarkeit herstellen sollte. 

Mit der Konkretisierung der Anwendungsfälle während der Projektphase haben sich diese 

Überschneidungen teilweise aufgelöst, während andere neu entstanden sind. Am Ende setzte jede 

Teilgruppe verschiedene Technologien ein, weswegen sich der Technologievergleich zu einer 

Bewertung und Darstellung verschiedener Anwendungen im BI Umfeld gewandelt hat. 

Die Projektgruppe BI ist durch ihre zwar thematisch verwandten, in ihrer Ausgestaltung und 

Durchführung jedoch sehr verschiedenen Teilprojekte charakterisiert. In jeder der drei Teilgruppen 

liegen die Schwerpunkte der Arbeit in unterschiedlichen Bereichen. Differenzen sind unter anderem 

bei den Zielsetzungen, den Adressaten und Nutzern der Ergebnisse, als auch bei den zu beherrschenden 

Datenmengen zu finden. So steht im einen Fall der Umgang mit einem enormen Datenvolumen im 

Vordergrund. In einem anderen Fall stellt hingegen die aussagekräftige Prognose auf Basis einer 

vergleichsweise geringen Anzahl von Datensätzen die Herausforderung dar. Entsprechend lassen sich 

Unterschiede in der Herangehensweise an die Anwendungsfälle und in den Bedürfnissen an die zur 

Arbeit benötigte Software erkennen. Die Unterschiede spiegelt sich in einem vielfältigen Portfolio an 

eingesetzten Technologien der BI wider. Um die Eignung der Programme zum Bewältigen der 

individuellen Herausforderungen in Relation setzen zu können, sollen in diesem Technologievergleich 

die wichtigsten Softwarelösungen anhand von ausgearbeiteter Kriterien beurteilt und verglichen 

werden. 

Das vorliegende Dokument stellt den Technologievergleich dar, der nach Bearbeitung der 

Anwendungsfäll gegen Ende des Bearbeitungszeitraums durchgeführt wurde. 

641



2. Vorstellung der Anwendungsfälle 

Das Themenfeld der Business Intelligence umfasst ein sehr breites Spektrum an verschiedenen 

Einsatzgebieten, Aufgaben und Methoden rund um den Umgang mit Daten aus der gesamten 

Unternehmensumwelt zum Wissensgewinn und zur fundierten Unterstützung des Entscheidungsprozesses. 

Die Anzahl an möglichen Anwendungsfällen ist entsprechend enorm, die Auswahl eines 

einzelnen Betrachtungsgegenstands nicht einfach. Statt sich also auf ein einzelnes Thema zu 

beschränken, bearbeitet die Projektgruppe Cuberunner drei ausgewählte Anwendungsfälle in drei 

Teilgruppen. 

2.1 

Teilgruppe Analytisches CRM 

Unter dem Arbeitstitel gestochen scharfe Fragen stellen befasst sich eine Teilgruppe mit einem 

Projekt im Bereich des analytischen Customer Relationship Management in Kooperation mit der 

CEWE COLOR AG & Co. OHG (CEWE). Ziel dieses Projektes ist eine zentrale, lokale Lagerung der 

Daten von Kundenumfragen um eine übergreifende, zeitbezogene Analyse und Prognose zu 

ermöglichen. Zu diesem Zweck ist ein unterbrechungsfreier IT-gestützter Prozess von der 

Umfrageerstellung, dem Datentransfer, der Datenlagerung und der Datenanalyse erforderlich, der es 

erlaubt, die gewonnen Erkenntnisse zur Verbesserung von Umfragen zu nutzen um zukünftig 

gestochen scharfe Fragen stellen zu können. 

Zur Umsetzung des Projektes werden diverse Anwendungen eingesetzt. Die zu archivierenden und 

analysierenden Umfragedaten stammen aus dem Online-Umfragetool QuestionPro. Diese Daten 

werden regelmäßig mit einer in Java realisierten ETL-Anwendung per REST-Protokoll aus den 

Datenbanken des externen Anbieters QuestionPro ausgelesen, aufbereitet und in eine in der IT- 

Infrastruktur von CEWE verorteten Oracle DB 11g Datenbank geschrieben. Der so ständig wachsende 

Pool an in Umfragen verwendeter Fragen kann über eine ASP-Benutzeroberfläche verwaltet werden, 

welche per SQL mit der Datenbank kommuniziert. Über diese Benutzeroberfläche können Fragen 

kategorisiert werden um die spätere Analyse zu erleichtern. Mit dem IBM Cognos Framework 

Manager können die Daten für das anschließende Berichtswesen mit IBM Cognos Report Studio und 

die Analyse mit IBM SPSS weiter aufbereitet werden. 

QuestionPro 

Datenabfrage 

 

Anwendung 

Umfrageverzeichnis 

 

Oracle DB 

Daten 

verwalten 

 

Fragenpool 

ETL- 

(Benutzer- 

Datenexport 

aufbereitete 

Daten schreiben 

Daten 

darstellen 

oberfläche) 

Abbildung 2.1: Prozessübersicht analytisches CRM 

642



2.2 

Teilgruppe Jinengo 

Eine weitere Teilgruppe befasst sich mit der Analyse intermodaler Verkehrsdaten vor dem 

Hintergrund nachhaltiger Mobilität. Als Datengrundlage dient die Routenplanungssoftware Jinengo, 

die zuvor im Rahmen einer anderen Projektgruppe an der Universität Oldenburg entwickelt wurde. 

Diese Cuberunner-Teilgruppe befasst sich mit der Analyse des Mobilitätsverhaltens, welches sich aus 

der Nutzung der Jinengo-Plattform ableiten lässt. Neben der Darstellung des Verhaltens der Anwender 

sollen auf diese Weise auch Erkenntnisse gewonnen werden, die der Verbesserung des operativen 

Systems dienen. Damit wird das bestehende operative System um Elemente der Business Intelligence 

erweitert. 

Die technische Grundlage des Projekts bildet ein Microsoft SQL Server 2012. Verwendet werden die 

(relationale) Datenbank, die SQL Server Integration Services für ETL-Prozesse, die SQL Server 

Analysis Services für die Datenanalyse sowie SQL Reporting Services für das Reporting. Für das 

Reporting kommt zudem zusätzlich Microsoft Excel und Qlikview zum Einsatz. Das Data Mining 

erfolgt mit dem IBM SPSS Modeler. 

2.3 

Teilgruppe Smart Wind Farm 

Im Rahmen des Teilprojekts Smart Wind Farm wird die Problematik des erhöhten Wartungsaufwandes 

von Windkraftanlagen im Offshore-Bereich als Rahmenbedingung für die Entwicklung einer 

Windpark-Management-Plattform herangezogen. Als zentraler Ausgangspunkt dient das vom Hasso- 

Plattner-Institut bereitgestellte In-Memory Datenbanksystem SAP HANA (High Performance Analytic 

Appliance), an welchem sich alle weiteren Schritte orientieren. In-Memory Datenbanksysteme nutzen 

im Gegensatz zu traditionellen Datenbanksystemen den Arbeitsspeicher als Datenspeicher, was zu 

einem erheblichen Performancegewinn führt. Diese Technologie eröffnet somit neue Lösungswege 

bzw. Ansätze, die es zu ermitteln gilt. Weiterhin sollen neue wissenschaftliche Erkenntnisse aus 

verschiedenen Bereichen der Windenergie in die Entwicklung einfließen. Die daraus resultierenden 

Lösungswege sollen aufgezeigt und abgewägt werden. Übergreifend ist es das Ziel somit eine 

grundlegende Plattform zu schaffen um den benötigten Funktionsumfang in verschiedenen Szenarien 

bestmöglich abzubilden. 

Das zentrale System für die Datenhaltung und -analyse ist SAP HANA. Für den ETL-Prozess setzt die 

Projektgruppe Pentaho Data Integration (Kettle) ein. Es besteht die Möglichkeit, über einen R Server 

auf R zuzugreifen, um Data Mining durchzuführen. Für das Reporting wird neben Microsoft Excel die 

XS-Engine mit SAP UI5 eingesetzt. 

643



3. Methodik 

Grundlegend wird der technische Vergleich im Stil einer Nutzwertanalyse durchgeführt. Um zunächst 

die Vergleichbarkeit zwischen den eingesetzten Anwendungen herzustellen, wurden funktionale 

Zusammengehörigkeiten identifiziert und die jeweiligen Vertreter eingeordnet. Es ergeben sich so fünf 

Anwendungsfelder: 

- Database 

- ETL 

- Analytical Services 

- Reporting 

- Data Mining 

Dabei unterscheidet sich die Anzahl der Anwendungen je Gruppe, da teilweise mehrere Teilgruppen 

des Projekts dieselbe Software einsetzen oder mehrere funktional verwandte Anwendungen parallel 

zum Einsatz kommen. 

Zur Bewertung wurden die sich aus der konkreten Arbeit mit der Software ergebenden Anforderungen 

gesammelt und in inhaltlich zusammenhängende Bewertungskriterien gruppiert. Diese Anforderungen 

werden ferner in für Software allgemein gültige, nichtfunktionale Anforderungen (siehe Kapitel 3.1) 

und in für die jeweilige Gruppe von Anwendungen spezifische funktionale Anforderungen (siehe 

Kapitel 0) unterteilt und enthalten eine Identifikationsnummer, eine inhaltliche Beschreibung sowie 

eine Gewichtung mit der der jeweils erzielte Punktwert verrechnet wird. 

Für die zu erzielenden Punkte wurde eine Bewertungsskala nach dem Forced Choice Verfahren 

gewählt. Die Bewertung der Kriterien erfolgt demnach über eine vierstufige Skala und somit eine 

gerade Anzahl von Kategorien. Ziel ist es, dass die Mittelposition nicht als neutrale Ausweichfläche 

benutzt werden kann. Die Befragten werden somit gezwungen, zumindest eine Tendenz im Urteil 

abzugeben. Für Personen, die die Fragen tatsächlich neutral beantworten wollen bzw. keine eindeutige 

Antwort geben können, gibt es die Möglichkeit, „n. b.“ (nicht bewertbar) als Antwortmöglichkeit 

einzutragen, um Auslassungen vorzubeugen. Ein entsprechendes Kriterium geht dann neutral (2,5) in 

die Bewertung ein. 

4 sehr gut 

3 Gut 

2 Schlecht 

1 sehr schlecht 

n. b. keine Angabe / Bewertung 

Tabelle 3.1: Bewertungsskala 

644



Die Gewichtung der Kriterien erfolgt nach einer prozentualen Aufschlüsselung. Da die Funktionalität 

der Software als das wesentliche Kriterium für die Bewertung erachtet wird, können über die je 

Anwendungsgruppe individuellen, funktionalen Anforderungen 60% der Gesamtbewertung erzielt 

werden. Da jedoch nichtfunktionale Aspekte ebenfalls die praktische Einsatztauglichkeit und 

Produktivität im Umgang beeinflussen, entfallen die verbleibenden 40% der Punkte auf diesen 

Bereich. Innerhalb der Anforderungsarten findet eine weitere Gewichtung statt, die sich teils durch 

eine subjektiv vorgenommene Abstufung der Relevanz des Kriteriums und andererseits aus der im 

Rahmen der Projektgruppe praktischen Beurteilbarkeit ergibt. So erhält etwa das Kriterium nf7: 

Geschwindigkeit den geringen Bewertungsanteil von 3%, da die Performanz von Software mit denen 

der Projektgruppe zur Verfügung stehenden Möglichkeiten nicht aussagekräftig gemessen oder 

verglichen werden können. Des Weiteren variieren die verarbeiteten Datenmengen zwischen den 

Teilgruppen stark, was eine übergreifende Vergleichbarkeit in dieser Hinsicht weiter erschwert. Um 

die Auswirkung dieser eingeschränkten Beurteilungsfähigkeit zu mindern, den prinzipiell aber 

durchaus relevanten Aspekt dennoch zu berücksichtigen, wird eine entsprechende Gewichtung 

gewählt. Die Gewichtung der für die Gesamtbewertung besonders ausschlagkräftigen funktionalen 

Anforderungen erfolgt ebenfalls anhand subjektiv diskutierter und festgelegter Rangordnung, wie sie 

sich im Umgang mit den jeweiligen Anforderungen herausgestellt hat. 

3.1 

Nichtfunktionale Anforderungen 

Die Anforderungen in dieser Gruppe beziehen sich auf Eigenschaften der Anwendungen, in welcher 

Art und Weise sie arbeitet und welche Rahmenbedingungen vorliegen. Für den Nutzer sind hier die 

Benutzerfreundlichkeit und die Dokumentation besonders interessant, die einen reibungslosen 

Arbeitslauf gewährleisten. Beim Einsatz im Unternehmen spielt auch die Zuverlässigkeit der 

Anwendung eine wichtige Rolle, denn fehleranfällige Lösungen können schwerwiegende Probleme 

und Kosten verursachen. Die Installationsanforderungen an vorhandene Hard- und Software von 

manchen Anwendungen schränken ihre praktischen Einsatzgebiete ein, weswegen die Integrierbarkeit 

in die IT-Landschaft ebenfalls betrachtet wird. Standardsoftware deckt üblicherweise die Hauptaufgaben 

in einem Anwendungsumfeld bereits ab. Gehen die Anforderungen jedoch über dieses Spektrum 

hinaus, ist Flexibilität hinsichtlich der Erweiterbarkeit durch Plugins oder individuelle Anpassungen 

gefragt; dies kann dabei den Unterschied zwischen einer für die jeweilige Aufgabe geeigneten und 

untauglichen Lösung machen. Die Unabhängigkeit vom Hersteller hinsichtlich Hosting und Offenheit 

des Programmcodes ist ebenfalls ein ausschlaggebendes Auswahlkriterium, insb. wenn Fortbetrieb 

und Wartung der Software bei Marktaustritt des Herstellers gewährleistet sein müssen. Da dies jedoch 

im Falle der wirtschaftlichen Situation des Anbieters von der Projektgruppe nur anhand öffentlich 

zugänglicher Informationen geschätzt werden kann, wird in dieser Stelle eine geringere Gewichtung 

gewählt. Die Performanz der Anwendungen spielt ebenfalls eine Rolle für den Anwender und kann die 

645



Produktivität bei wachsenden Datenmengen stark beeinträchtigen, erhält jedoch aufgrund der eingangs 

dargelegten stark eingeschränkten Bewertbarkeit den geringsten Gewichtungsanteil. 

Nr. Kriterium Beschreibung Gew. 

nf-1 Unabhängigkeit vom 

Hersteller 

Mit welchen Konsequenzen ist zu rechnen, wenn der 

Softwareanbieter insolvent wird oder die Vertragsbeziehung 

anderweitig endet. Kann die Software im 

Haus gehostet werden? Lassen sich selbstständig 

Änderungen an der Software vornehmen? 

4% 

nf-2 Support & Dokumentation Welche Hilfestellungen werden bei der Bedienung der 

Software angeboten (Tooltips, Kurzhilfe, Dokumentation, 

Mailsupport, Hotline)? 

nf-3 Benutzerfreundlichkeit Wie bedienbar ist die Software? Wie hilfreich ist die 

GUI? Lässt sich die Software an individuelle 

betriebliche Gegebenheiten anpassen? Welche 

Einarbeitungszeit ist zum Erlernen der Software 

notwendig? 

nf-4 Integrierbarkeit Wie passt die Software in heterogene IT- 

Landschaften? Dabei wird die Frage nach den 

Schnittstellen explizit ausgeklammert, sondern 

stattdessen bei Bedarf als funktionale Anforderung 

abgefragt. 

nf-5 Erweiterbarkeit Lassen sich individuelle Anpassungen vornehmen? 

Gibt es Plugins, die die Funktionalität erweitern? 

nf-6 Zuverlässigkeit Wie fortgeschritten ist die Systemreife? Wie stabil 

und fehlertolerant ist die Anwendung? Lassen sich 

verlorengegangene Daten wiederherstellen? Gibt es 

Möglichkeit zum Debugging? 

nf-7 Geschwindigkeit Wie performant ist die Software? Skaliert die 

Software? 

6% 

6% 

7% 

7% 

7% 

3% 

Tabelle 3.2: Übergreifende nichtfunktionale Anforderungen 

646



3.2 

Funktionale Anforderungen 

Diese Anforderungen beziehen sich auf die funktionalen Aspekte, die Anwendungen leisten sollen. 

Für jede der fünf Gruppen wurden individuelle Anforderungen identifiziert und zu drei bis vier 

sinnvoll bewertbaren Kriterien verdichtet. Eine höhere Granularität wurde an dieser Stelle gemieden, 

da eine höhere Detaillierung nicht von dem subjektiven Bewertungsfahren auf Basis von Erfahrungswerten 

und der teils sehr unterschiedlich ausgelegten Anwendungen angemessen vorgenommen 

werden kann. Die Software wird im Arbeitseinsatz in den Teilgruppen betrachtet und bewertet, 

inwieweit die Anforderungen im praktischen Einsatz erfüllt werden. 

3.2.1 Database 

In der Gruppe der Datenbanken wird der Schwerpunkt im Umfang der Kernfunktionen gesehen. So 

können die verfügbaren SQL-Standards die Arbeitsweise ebenso beeinflussen wie unterstützte 

Programmiersprachen oder die Nutzbarkeit von Subroutinen. Für den reibungslosen Betrieb der 

Datenbank ist ebenfalls die Form von möglichen Backups und der Wiederherstellung nach 

verschiedenen Fehlern oder Ausfällen relevant. Schließlich wird mit steigender Benutzerzahl das 

Berechtigungsmanagement ein zu beachtendes Thema um möglichen Fehleingaben vorzubeugen. 


db-1 Funktionsumfang Welchen Funktionsumfang bietet die Datenbank: 

SQL-Standard, integrierte Programmiersprache, 

Transaktionen, Stored Procedures, Datenformate, … 

30% 

db-2 Berechtigungsmanagement Wie erfolgen die Identifizierung von Benutzern und 

die Zugriffssteuerung? Lassen sich gestaffelte 

Berechtigungen definieren (Berechtigungsrollen)? 

db-3 Backup & Recovery Wie lassen sich Daten sichern und wieder 

einspielen? Welche Backupformen werden 

unterstützt? 

10% 

20% 

Tabelle 3.3: Database spezifische funktionale Anforderungen 

3.2.2 ETL 

Beim Auslesen, Umwandeln und Laden von Daten steht die Aufbereitung im Vordergrund. Falls es 

Probleme Beim In- oder Output gibt, können an den verbundenen Stellen Änderungen vorgenommen 

werden, ist jedoch der Kernprozess der Anwendung unzureichend, stellt dies die Tauglichkeit der 

gesamten Anwendung in Frage. Die Datenquellen und –ziele sind entsprechend das nächstwichtigste 

Kriterium, da sie das Einsatzgebiet der Anwendung maßgeblich vorgeben. Als ähnlich relevant wird 

das Prozesskettenmanagement gesehen, denn Einschränkungen in diesem Bereich können sich auf die 

Ergebnisqualität auswirken. Die Überwachung der laufenden Prozesse zum frühzeitigen Eingreifen im 

647



Fehlerfall und der Fehlersuche beeinflusst indes das Ergebnis nicht unmittelbar, sollte aber dennoch 

berücksichtig werden. 

Nr. Kriterien Beschreibung Gew. 

etl-1 Datenquellen & -ziele Welche Datenquellen werden als Quelle und Ziel 

unterstützt: Datenbanken, Dateisysteme, 

mehrdimensionale Quellen, Business Software (ERP 

& CRM), …? Welche Möglichkeiten der 

Datenübertragung (FTP, BS-copy, etc.) sind 

möglich? 

15% 

etl-2 Transformation 

Welchen Funktionen stehen für die Datentransformation 

und das Cleansing bzw. die Validation von 

Daten zur Verfügung? 

20% 

etl-3 Monitoring Wie lassen sich laufende ETL-Prozesse überwachen? 10% 

etl-4 Prozesskettenmanagement 

Wie lassen sich ETL-Prozessketten gestalten 

(sequentiell / parallel) und steuern (manuell / 

automatisiert)? 

15% 

Tabelle 3.4: ETL spezifische funktionale Anforderungen 

3.2.3 Analytical Services 

Da das Produkt der Datenanalyse der Gewinn neuer Informationen und Erkenntnisse ist, steht in 

diesem Bereich die Bildung der Kennzahlen inklusive ihrer gesamten Herleitung im Vordergrund. Die 

Modellierung der Dimensionen ist als vorgelagerter Schritt zu verstehen und hat aufgrund ihrer 

Auswirkung auf die Ergebnisqualität ebenfalls einen hohen Stellenwert. Schließlich muss auch die 

Auswahl möglicher Datenquellen und ihre Integrierbarkeit in den Datenmodellen berücksichtigt 

werden. 

Nr. Kriterien Beschreibung Gew. 

as-1 Datenquellen Welche Datenquellen werden unterstützt? Werden 

mehrere Datenquellen in einem Datenmodell 

unterstützt? 

15% 

as-2 Kennzahlenmodellierung Wie lassen sich Kennzahlen bilden (u.a. durch 

Formeln)? 

as-3 Dimensionsmodellierung Wie werden Dimensionen modelliert? Gibt es 

vorgefertigte Dimensionen (Zeitdimension)? 

25% 

20% 

Tabelle 3.5: Analytical Services spezifische funktionale Anforderungen 

648



3.2.4 Reporting 

Die Aufbereitung der Daten in aussagekräftigen Darstellungsformen, die durch Interaktionsmöglichkeiten 

zum besseren Verständnis beitragen können, wird im Bereich des Reporting mit einer hohen 

Gewichtung versehen. Da die gewonnenen Informationen jedoch auch bei den entsprechenden 

Adressaten in der passenden Form ankommen müssen, wird den Report-Assistenten der gleiche 

Stellenwert zugemessen. Kann der Fachanwender die benötigten Berichte mit Unterstützung der 

Software ohne spezielle Kenntnisse selber erstellen, fällt die unter Umständen aufwändige 

Kommunikation mit dem Reporting-Spezialisten weg. Dieser kann sich somit anderen Aufgaben 

zuwenden während der Fachanwender unmittelbar auf die gewünschten Informationen zugreifen kann. 

Besonders regelmäßig erfolgende Standardberichte eignen sich zur zentralen Bereitstellung über ein 

eigenes Portal. Die Kopplungsfähigkeit mit solchen Plattformen wird daher ebenfalls in diesem 

Bereich berücksichtigt. Ebenso ist die Nutzbarkeit verschiedener Datenquellen relevant, etwa die 

Unterstützung von sowohl relationaler als auch multidimensionaler Formen. 


r-1 Datenquellen Welche Datenquellen werden unterstützt (z.B. 10% 

relationale und multidimensionale Daten)? 

r-2 Darstellungsform Wie werden Daten in Reports graphisch dargestellt? 

Welche Formen der Interaktion (z.B. OLAP- 

Funktionalitäten) sind möglich? 

r-3 Report-Assistenten Lassen sich Bedarfsberichte vom Endanwender durch 

Assistenten / Dialogsysteme interaktiv zusammenstellen? 

Wie wird die Erstellung der Berichte 

unterstützt? Wird eine Vorschau während der 

Erstellung angeboten? 

r-4 Bereitstellung Können Reports automatisch verschickt werden? 

Gibt es ein eigenes Portal zum Zugriff auf die 

Reports? Lassen sich Reports in (Drittanbieter-) 

Anwendungen integrieren (z.B. Sharepoint, Lotus 

Notes, …)? 

20% 

20% 

10% 

Tabelle 3.6: Reporting spezifische funktionale Anforderungen 

3.2.5 Data Mining 

Bei Anwendungen für das Data Mining liegt der Fokus auf den möglichen Methoden zur Gewinnung 

von Informationen. Diese sind maßgeblich an der Ergebnisqualität beteiligt und erhalten daher den 

größten Anteil der Gewichtung. Ähnlich wichtig werden die unterstützenden Funktionen gesehen, 

anhand derer die Datenverarbeitung gesteuert, überwacht und auf ihre Eignung zum Erreichen des 

gewünschten Ziels hin evaluiert werden. Eine Vielzahl möglicher Datenquellen ist Vorteilhaft für die 

möglichen Einsatzfelder der Anwendung, wird jedoch nicht als zentrales Kriterium verstanden. Da 

zudem die ansprechende Darstellung der Informationen nicht zwangsläufig zu den Aufgaben einer 

649



Anwendung für das Data Mining zählt, wird ebenso die Möglichkeit des Exports in gängige Formate 

und Anwendungen betrachtet. 


dm-1 Datenquellen & -ziele Welche Datenquellen werden für die Quelldaten 

unterstützt? Welche Möglichkeiten des Exportes gibt 

es? 

15% 

dm-2 Unterstützte Methoden 

dm-3 Prozessmanagement, 

Datenvisualisierung & 

Evaluierung 

Welche Data-Mining-Methoden werden mitgeliefert? 

Lassen sich bestehende ändern bzw. eigene 

definieren? 

Wie werden Data-Mining-Prozesse gestartet und 

gesteuert? Wie werden Daten visualisiert? Wie lässt 

sich die Qualität der angewendeten Methode bezogen 

auf die eigenen Daten evaluieren? 

25% 

20% 

Tabelle 3.7: Data Mining spezifische funktionale Anforderungen 

4. Database 

In den Teilgruppen kommen die Datenbanken von drei verschiedenen Anbietern zum Einsatz. 

Während Smart Wind Farm die In-Memory-Technologie von SAP HANA nutzt, verwendet Jinengo 

den Microsoft SQL Server 2012. Die Teilgruppe Analytisches CRM verwendet indes die Oracle 

Database 11g zur Lagerung der Daten. 

4.1 

SAP HANA 

Nr. Kriterium Bew. Begründung 

nf-1 Unabhängigkeit 1 Die Datenbank kann nicht separat erworben werden, sondern 

vom Hersteller 

nur zusammen mit dem restlichen HANA Komponenten. 

nf-2 

nf-3 

Support & 

Dokumentation 


3 Es werden Schulungen und Dokumente zu dem System 

angeboten. Außerdem stehen Support-Foren zur Verfügungen. 

3 Die Benutzerfreundlichkeit ist mit anderen SQL Datenbanken 

zu vergleichen und bietet einen strukturierten Aufbau. Einige 

benötigte Funktionen sind jedoch in Untermenüs versteckt und 

nicht sofort ersichtlich. 

nf-4 Integrierbarkeit 2 Die HANA-Datenbank ist ein Teil des HANA-Systems und 

damit bereits integriert. Bestehende SAP Systeme können an 

das HANA System angebunden werden um die Vorteile zu 

nutzen. 

Allerdings funktioniert die Software nur mit einem Suse 

Linux 11 System auf spezieller zertifizierter Hardware von 

ausgewählten Herstellern. 

650



nf-5 Erweiterbarkeit 4 Es gibt verschiedene Versionen des HANA-Systems. 

Außerdem ist das gesamte HANA-System linear-skalierbar 

und kann somit durch weitere Server um ein vielfaches an 

Speicherplatz und Rechenleistung erweitert werden. 

nf-6 Zuverlässigkeit 2 Die Datenbank hat ebenso wie das gesamte HANA-System 

noch keinen finalen Systemstand erreicht. 

nf-7 Geschwindigkeit 4 Aufgrund der Verwendung von In-Memory Technologie 

bietet das System eine hohe Arbeitsgeschwindigkeit, die bei 

Bedarf durch weitere Server erweitert werden kann. 

db-1 Funktionsumfang 4 Da das HANA-System eine komplettes System ist und nicht 

nur eine reine Datenbank, bietet es zusätzlich zu den 

Datenbankfunktionen und der In-Memory auch Analyse, ETL 

und Reporting-Funktionen. 

db-2 

Berechtigungsmanagement 

4 Das System ist Mandantenfähig und bietet einer rollenbasierende 

Rechteverteilung. 

db-3 Backup & Recovery 4 Zusätzlich zu möglichen Vollbackups, wird der DB-Log 

kontinuierlich und der gesamte Datenbestand regelmäßig 

gesichert. 

Tabelle 4.1: Bewertung Database SAP HANA 

4.2 

Microsoft SQL Server 2012 


nf-1 Unabhängigkeit 


3 Microsoft ist als großer etablierter Anbieter von Standardsoftware 

wenig insolvenzgefährdet. Die Datenbank kann im 

Unternehmen gehostet werden, lässt sich aber nicht 

eigenständig weiterentwickeln. 

nf-2 

nf-3 

Support & 

Dokumentation 


4 Es werden zahlreiche Hilfestellungen von Seiten Microsofts 

geboten (sowohl produktintegriert als auch online). 

Insbesondere stellt Microsoft auch einen technischen Support 

bereit. Zudem gibt es durch die große Verbreitung des 

Produkts viel externe Hilfestellung, z.B. in Blogs und Foren. 

4 Die Software ist in den meisten Teilen mit einer graphischen 

Oberfläche intuitiv bedienbar, die Fensteranordnung lässt sich 

an individuelle Bedürfnisse anpassen. Aufbau und Begriffe 

orientieren sich weitgehend an den Standardkonventionen für 

Datenbankanwendungen. 

nf-4 Integrierbarkeit 3 Die Software lässt sich insbesondere in Microsoft- 

Umgebungen gut integrieren. Die Software setzt den Einsatz 

von Windows auf dem Server allerdings zwingend voraus. 

nf-5 Erweiterbarkeit 3 Es gibt verschiedene Versionen des SQL Servers, die 

unterschiedlichen Ansprüchen gerecht werden. 

nf-6 Zuverlässigkeit 4 Die Software ist in ihrer Systemreife sehr weit fortgeschritten. 

nf-7 Geschwindigkeit 3 Die Datenbank zeichnet sich subjektiv durch eine hohe 

Geschwindigkeit im Vergleich zu frei erhältlichen Open- 

Source-Produkten aus. 

651



db-1 Funktionsumfang 4 Die Software verfügt über einen sehr hohen Funktionsumfang. 

Die Abfragesprache basiert weitgehend auf dem SQL- 

Standard. Eine integrierte Programmiersprache (T-SQL) 

sowie erweiterte Datenbankfunktionalitäten (Stored 

Procedures, Funktionen, Trigger) werden angeboten. Es 

werden zahlreiche Datenformate unterstützt. In der Enterprise- 

Version ist xVelocity, die In-Memory-Technologie von 

Microsoft, unterstützt. 

db-2 


4 Berechtigungen lassen sich durch Rollen und Gruppen 

feingranular vergeben. 

db-3 Backup & Recovery 4 Backups können auf verschiedene Arten (verschiedene 

Datenformate, Drittdatenbanken, inkrementell/vollständig) 

erstellt und wieder eingespielt werden. 

Tabelle 4.2: Bewertung Database Microsoft SQL Server 2012 

4.3 

Oracle Database 11g 




3 Durch die Möglichkeit, die Software im Haus zu hosten ist 

eine gewisse Unabhängigkeit vom Hersteller gegeben. 

Allerdings lassen sich selbstständig keine Änderungen am 

Quellcode der Software vornehmen. Prinzipiell ist das 

Unternehmen Oracle Corporation als großer Softwarehersteller 

wenig insolvenzgefährdet. 

nf-2 

nf-3 

Support & 

Dokumentation 


4 Auf der Webseite von Oracle ist eine umfangreiche 

Webdokumentation und Schulungsmaterialien verfügbar. 

Ebenfalls ist Support durch Oracle in Form einer kostenpflichtigen 

Lifetime Support Policy möglich. Zusätzlich ist 

kostenloser Support in diversen Diskussionsplattformen wie 

z.B. Nutzerforen möglich. 

3 Hier wird der SQL Developer bewertet. Der Aufbau orientiert 

sich weitgehend an den Standardkonventionen für 

Datenbankanwendungen. Er bietet zwar grundlegende 

Funktionalitäten zur Erstellung, Versionisierung und Backups 

oder auch Erweiterbarkeit durch Plugins, ist allerdings 

langsam und enthält einige Fehler wie den Absturz des Tools 

bei Verlust der Datenbankverbindung. 

652 

nf-4 Integrierbarkeit 4 Oracle DB 11g ist seit Release 2 unabhängig von der 

verwendeten IT-Landschaft nutzbar. 

nf-5 Erweiterbarkeit 3 Es gibt verschiedene Versionen wie etwa Standard Edition, 

Standard Edition One oder Enterprise Edition der Oracle DB, 

die unterschiedlichen Ansprüchen gerecht werden. 

nf-6 Zuverlässigkeit 4 Die Oracle DB befindet sich durch umfangreiche Weiterentwicklungen 

bereits in der elften Version und ist daher in der 

Systemreife sehr weit fortgeschritten 

nf-7 Geschwindigkeit 3 Eine Oracle DB zeichnet sich subjektiv durch eine hohe 

Geschwindigkeit im Vergleich zu frei erhältlichen Open- 

Source Produkten aus.



db-1 Funktionsumfang 4 Oracle DB besitzt einen großen Funktionsumfang für die 

Erstellung und Verwaltung von Datenbanken. Es wird das 

volle Spektrum an SQL- und PL/SQL-Befehlen sowie Java als 

integrierte Programmiersprache unterstützt. Dem Nutzer 

stehen unter anderem benutzerdefinierte Prozeduren, 

Funktionen, sowie Trigger und Sequenzen zur Verfügung. Es 

kann aus einer großen Anzahl an Datenformaten gewählt 

werden. Zur Beschleunigung der Datenbank kann die In- 

Memory-Technologie TimesTen eingesetzt werden. 

db-2 


4 Das Berechtigungsmanagement der Oracle DB bzw. im SQL 

Developer bei Verwendung der Oracle DB ist sehr 

umfangreich. Im SQL Developer ist es u.a. möglich, 

Benutzern individuell verschiedene Rollen und Rechte bei 

verschiedenen Projekten zu geben. 

db-3 Backup & Recovery 4 Die Software unterstützt eine umfangreiche Versionierung zur 

Wiederherstellung verschiedener Entwicklungsstände der 

Datenbank. 

Tabelle 4.3: Bewertung Database Oracle Database 11g 

4.4 

Vergleich Databases 

Nr. Kriterium Gew. SAP HANA 

nicht funktional 

Microsoft SQL 

Server 2012 

Oracle DB 11g 

nf-1 Unabhängigkeit vom Hersteller 4% 1 3 3 

nf-2 Support & Dokumentation 6% 3 4 4 

nf-3 Benutzerfreundlichkeit 6% 3 4 3 

nf-4 Integrierbarkeit 7% 2 3 4 

nf-5 Erweiterbarkeit 7% 4 3 3 

nf-6 Zuverlässigkeit 7% 2 4 4 

nf-7 Geschwindigkeit 3% 4 3 3 

funktional 

db-1 Funktionsumfang 30% 4 4 4 

db-2 Berechtigungsmanagement 10% 4 4 4 

db-3 Backup & Recovery 20% 4 4 4 

Bewertung 3,48 3,79 3,8 

Tabelle 4.4: Vergleich Databases 

Der Vergleich zeigt ein klares Unentschieden zwischen den etablierten Datenbanken von Microsoft 

und Oracle. Die Unterschiede in der Bewertung sind minimal und daher zu vernachlässigen. Die 

Verwandtschaft der beiden seit geraumer Zeit in Entwicklung befindlichen relationalen Datenbanken 

wird hier sehr deutlich. Die funktionalen Anforderungen werden von beiden Produkten auf hohem 

Niveau erfüllt, geringfügige Unterschiede lassen sich lediglich bei den nichtfunktionalen Anforderun- 

653



gen finden. Hier wurde der SQL Server 2012 als etwas benutzerfreundlicher empfunden, da der 

während des Projekts zur Datenbankverwaltung verwendete Oracle SQL Developer in seltenen Fällen 

bei Verlust der Verbindung zum Server abstürzte. Oracle DB 11g punktet hingegen bei der etwa 

besseren Integrierbarkeit, da bei der Auswahl des Betriebssystems ein gewisser Spielraum vorhanden 

ist, während der SQL Server 2012 zwingend auf einer Windows-Plattform installiert werden muss. 

Unterschiede lassen sich hingegen zu SAP HANA sehen. Dessen großes Argument ist die konsequente 

Nutzung von In-Memory-Technologien, welche bei den anderen betrachteten Datenbanken in Form 

von Microsofts xVelocity und Oracles TimesTen nur optional sind. Aufgrund der Umstände unter 

denen dieser Vergleich stattfindet und der geringen Gewichtung der schwierig messbaren Geschwindigkeit, 

kann SAP HANA den Trumpf in diesem Fall nicht ausspielen. Stattdessen sind klare Defizite 

bei den nichtfunktionalen Anforderungen zu sehen, welche auch mit der nicht abgeschlossenen 

Entwicklung des Produkts zu begründen sind. So sind Abstriche bei der Zuverlässigkeit im Vergleich 

mit den etablierten Mitbewerbern hinzunehmen. Eine weitere Einschränkung findet sich bei der 

Integrierbarkeit, denn die Anforderungen an Hard- und Software sind sehr spezifisch und bieten nur 

wenig Spielraum. 

5. ETL 

Im Bereich ETL wird von der Teilgruppe Smart Wind Farm die Open-Source-Lösung Pentaho Data 

Integration CE verwendet. Sie wird mit den kommerziellen Microsoft SQL Server Integration Services 

(SSIS) verglichen, welche von Jinengo genutzt wird. Die Teilgruppe Analytisches CRM nutzt eine 

selbstprogrammierte Java-Applikation zur Datenextraktion, -aufbereitung und dem Transfer zum 

Datenziel, welche nicht sinnvoll mit den spezialisierten Lösungen verglichen werden kann. 

5.1 

Pentaho Data Integration CE 




4 Pentaho Data Integration ist sowohl als Community Edition 

(CE) und als kommerzielle Enterprise Edition (EE) welche 

nicht Gegenstand dieser Bewertung ist verfügbar. Die 

eingesetzte CE Version wird von einer großen Community 

unterstützt, ist eine Open Source Software und ist somit vor 

einer Insolvenz sehr gut abgesichert. Weiterhin ist der Java 

Quellcode der Software frei verfügbar und kann selber 

gehostet und leicht angepasst werden. 

654



nf-2 

nf-3 

Support & 

Dokumentation 


3 Die Basisinstallation kommt einher mit einer ausführlichen 

Dokumentation sowie einer Online-Dokumentation, welche 

von der Community bereitgestellt wird. Weitere Informationen 

sind auf der Community-Webseite verfügbar z.B. in Form 

von Anleitungen, FAQs oder Forenbeiträgen. Zusätzlich gibt 

es zahlreiche Foren, Blogs oder Videos von privaten 

Anbietern. Ein direkter technischer Support ist der 

kostenpflichtigen EE Version vorbehalten. 

2 Die Erstellung der Prozesskette erfolgt über ein Baukastenprinzip, 

indem sich jeder Nutzer die vorgefertigten Module 

(Funktionen) auf einer grafischen Arbeitsfläche per Drag & 

Drop zusammenstellen kann. Die Grundstruktur der Software 

ist klar gegliedert und leicht verständlich. Jedoch sind die 

Dialoge der einzelnen Module teilweise unterschiedlich und 

unübersichtlich aufgebaut, was zu einem sehr hohen 

Einarbeitungsaufwand führt. 

nf-4 Integrierbarkeit 3 Aufgrund von Java lässt sich die Software auf vielen 

Plattformen integrieren und kann individuell angepasst 

werden. Der Einsatz im Unternehmen unter Voraussetzung 

der Hochverfügbarkeit ist jedoch fraglich. 

nf-5 Erweiterbarkeit 4 Die Software lässt sich dank Java und des offenen Quellcodes 

sehr leicht erweitern. 

nf-6 Zuverlässigkeit 3 Pentaho Data Integration wird seit 2004 entwickelt und ist 

mittlerweile in der vierten Generation verfügbar. Es stehen 

zahlreiche Monitoring und Logging-Funktionalitäten bereit 

um Fehler zu identifizieren. Die Stabilität der Anwendung ist 

bei großen parallelen Datenmengen stark von den verfügbaren 

Ressourcen der Java Virtuell Maschine abhängig. Diese neigt 

dazu nicht zu reagieren, sobald zu wenig Arbeitsspeicher 

verfügbar ist, der Prozess läuft zwar weiter aber ein Realtime 

Monitoring ist nicht mehr möglich. 

nf-7 Geschwindigkeit 0 Nicht bewertbar. 

etl-1 

Datenquellen 

& -ziele 

4 Es wird eine Fülle von Systemen, Datentypen und Protokollen 

als Datenquelle sowie Datenziel unterstützt. Neben 

Datenbanken, Flatfile & Excel werden dabei auch 

„unkonventionellere“ Quellen wie bspw. RSS, Google 

Analytics, etc. unterstützt. 

etl-2 Transformation 4 Das Angebot an Transformationen ist sehr umfangreich und 

kann leicht individualisiert bzw. erweitert werden, teilweise ist 

jedoch eine hohe Einarbeitungszeit von Nöten. 

etl-3 Monitoring 3 Es stehen verschiedene Logging-Tiefen zur Verfügung, jeder 

Schritt kann sowohl grafisch als auch textuell überwacht 

werden. Die Performance lässt sich grafisch auswerten. 

etl-4 

Prozesskettenmanagement 

4 Die ETL-Prozessketten können sowohl sequentiell als auch 

parallel gestaltet werden. Eine oder mehrere Prozessketten 

lassen sich zu einem Job zusammenfügen und manuell oder 

automatisch gestartet werden. Der Job kann beliebig gestaltet 

werden und mit Vor- und Nachbedingungen verknüpft 

werden. 

Tabelle 5.1: Bewertung ETL Pentaho Data Integration CE 

655



5.2 

Microsoft SQL Server Integration Services 





wenig insolvenzgefährdet. Die Software lässt sich im 

Unternehmen verwenden, lässt sich aber nicht eigenständig 

weiterentwickeln. 

nf-2 

nf-3 

Support & 

Dokumentation 



geboten (sowohl produktintegriert als auch online). 

Insbesondere stellt Microsoft auch einen technischen Support 

bereit. Zudem gibt es durch die große Verbreitung des 

Produkts viel externe Hilfestellung, z.B. in Blogs und Foren. 

3 Die Software ist in den meisten Teilen mit einer graphischen 

Oberfläche intuitiv bedienbar, die Fensteranordnung lässt sich 

an individuelle Bedürfnisse anpassen. Fortgeschrittene 

Integrationsanforderungen sind dabei jedoch zum Teil nur 

durch großen Aufwand implementierbar. Die Prozesskette 

wird graphisch zusammengestellt (Baukastenprinzip). Es 

müssen vereinzelt softwarespezifische Begriffe erlernt 

werden. 


Umgebungen mit einer MSSQL-Datenbank gut integrieren. 

Die Software setzt allerdings den Einsatz von Windows 

zwingend voraus. 

nf-5 Erweiterbarkeit 3 Die Software verfügt bereits über einen großen Funktionsumfang. 

Sollten die vorgefertigten Module für einen ETL- 

Prozess nicht ausreichen, lässt sich mithilfe von Visual C# 

individueller Code entwickeln. 

nf-6 Zuverlässigkeit 3 Die Software ist in ihrer Systemreife weit fortgeschritten. 

Während der Projektphase kam es auf unserem (ressourcenschwachen) 

Testsystem zu gelegentlichen Systemabstürzen. 

Die Möglichkeiten des Monitorings und insbesondere des 

Debuggings sind beschränkt. 


etl-1 

Datenquellen 

& -ziele 

3 Es werden die in einem Unternehmen relevanten Systeme als 

Datenquelle und Datenziel unterstützt (verschiedene DB- 

Systeme, Flatfile, Excel). 

etl-2 Transformation 4 Die Software verfügt über eine Vielzahl an vorgefertigten 

Funktionen für die Transformation und das Cleansing von 

Daten. Zudem lassen sich durch T-SQL, .NET und Ausdrücke 

eigene Transformationen erstellen. 

etl-3 Monitoring 2 Die Prozesse lassen sich sowohl in SSIS als auch auf der 

Datenbank monitoren. Die Funktionen (insbesondere zum 

Debugging) sind dabei allerdings beschränkt. 

656



etl-4 

Prozesskettenmanagement 

4 ETL-Prozesse können sowohl sequentiell als auch parallel 

gestaltet werden. Die eigentliche Abarbeitung der Daten 

verläuft allerdings auf Ebene einzelner Datensätze (und damit 

sequentiell). Die ETL-Prozesse lassen sich in die SQL-Server- 

Datenbank laden und von dort manuell sowie automatisiert 

starten. 

Tabelle 5.2: Bewertung ETL Microsoft SQL Integration Services 

5.3 

Vergleich ETL 

Nr. Kriterium Gew. 


Pentaho Data Integration 

CE 

Microsoft SSIS 

nf-1 Unabhängigkeit vom Hersteller 4% 4 3 

nf-2 Support & Dokumentation 6% 3 4 

nf-3 Benutzerfreundlichkeit 6% 2 3 

nf-4 Integrierbarkeit 7% 3 2 

nf-5 Erweiterbarkeit 7% 4 3 

nf-6 Zuverlässigkeit 7% 3 3 

nf-7 Geschwindigkeit 3% n. b. n. b. 

funktional 

etl-1 Datenquellen & -ziele 15% 4 3 

etl-2 Transformation 20% 4 4 

etl-3 Monitoring 10% 3 2 

etl-4 Prozesskettenmanagement 15% 4 4 

Bewertung 3,535 3,225 

Tabelle 5.3: Vergleich ETL 

Unter Betrachtung der bewerteten ETL-Tools gilt es hervorzuheben, dass ein kommerzielles Produkt 

mit einem Open Source Produkt verglichen wurde. Dies führt zwangsläufig bei einigen Kriterien zu 

sehr differenzierten Ausgangspunkten. Folglich ist einerseits die Unabhängigkeit vom Hersteller 

seitens der Open-Source-Lösung Pentaho Data Integration CE geringer bzw. kaum vorhanden und 

anderseits der Support für die kommerzielle Lösung Microsoft SSIS besser. Beide Anwendungen sind 

hinsichtlich des Aufbaus und der allgemeinen Funktionsweise sehr ähnlich ausgelegt. Pentaho Data 

Integration CE hebt sich durch seine Plattformunabhängigkeit und der guten Erweiterbarkeit dank der 

Implementierung in Java hervor. Weiterhin ist die hohe Anzahl der zur Verfügung stehender 

Datenquellen sehr positiv anzumerken. Neben den üblichen Datenquellen fallen hier insbesondere 

unkonventionellere Quellen wie bspw. RSS und Google Analytics positiv auf. Microsoft SSIS 

hingegen sticht durch seine Benutzerfreundlichkeit, die sich insbesondere durch die übersichtliche und 

657



intuitive graphische Oberfläche ergibt. Zudem ergibt sich in einer bestehenden Microsoft-Landschaft 

eine nahtlose Integration. 

In Summe erlangt Pentaho Data Integration CE eine bessere Bewertung, liegt jedoch eine bestehende 

Microsoft-Landschaft vor so empfiehlt es sich Microsoft SSIS in Betracht zu ziehen. 

6. Analytical Services 

Die Teilgruppe Jinengo setzt zur Datenanalyse die zum Microsoft SQL Server 2012 gehörenden SQL 

Server Analysis Services (SSAS) ein. Diese werden mit der Analysefunktion von SAP HANA der 

Gruppe Smart Wind Farm und dem von Analytisches CRM genutzten IBM Cognos Framework 

Manager verglichen. 

6.1 

Microsoft SQL Server Analysis Services 







weiterentwickeln. 

nf-2 

nf-3 

Support & 

Dokumentation 



geboten (sowohl produktintegriert als auch online). Zudem 

gibt es durch die große Verbreitung des Produkts viel externe 

Hilfestellung, z.B. in Blogs und Foren. 

3 Die Software lässt sich nicht individuell an eigene Bedürfnisse 

anpassen, ist allerdings in den meisten Teilen intuitiv 

bedienbar. Die Modellierung erfolgt weitgehend gestützt 

durch graphische Elemente. Es müssen vereinzelt 

softwarespezifische Begriffe erlernt werden. 


Umgebungen gut integrieren. Die Software setzt allerdings 

den Einsatz von Windows zwingend voraus. 

nf-5 Erweiterbarkeit 1 Die Software verfügt bereits über einen großen Funktionsumfang, 

lässt sich allerdings nicht eigenständig erweitern. 



as-1 Datenquellen 3 Als Datenquellen werden insbesondere Microsoft- und 

Oracle-Datenbanken unterstützt. Innerhalb eines Datenmodells 

werden auch mehrere Datenquellen unterstützt. 

as-2 

Kennzahlenmodellierung 

3 Kennzahlen lassen sich auf Grundlage von Attributen sowie 

Berechnungen (eigene Syntax) bilden. Dabei können auch 

Trend- und Zielausdrücke definiert werden. 

658



as-3 

Dimensionsmodellierung 

3 Dimensionen lassen sich auf Basis bestehender Datenbanktabellen 

erstellen. Zudem werden Hilfestellungen für die 

Erstellung gängiger Dimensionen gegeben, die nicht direkt auf 

Tabellen basieren (insbesondere für den Fall der Zeitdimension). 

Es gibt keine verpflichtend zu verwendenden 

Dimensionen. 

as-4 Cube-Funktionalität 0 Die Darstellung der Cubes erfolgt (außer zu Zwecken der 

Vorschau) nicht in SSAS. Das Kriterium ist daher nicht 

bewertbar. 

Tabelle 6.1: Bewertung Analytical Services Microsoft SQL Analysis Services 

6.2 

IBM Cognos Framework Manager 




3 Durch die Möglichkeit, die Software im Haus zu hosten, 

besteht eine gewisse Unabhängigkeit von der Verfügbarkeit 

des Herstellers IBM. Als großes IT-Unternehmen ist IBM 

derzeit wenig insolvenzgefährdet. Allerdings lassen sich 

selbstständig keine Änderungen am Quellcode der Software 

vornehmen. 

nf-2 

nf-3 

Support & 

Dokumentation 


4 Es existiert eine umfangreiche Webdokumentation und 

Schulungsmaterialien auf der Firmenwebseite. Support durch 

IBM ist sowohl über die umfangreiche frei verfügbare 

firmeneigene Webdokumentation für Installation, Einrichtung 

und Nutzung als auch kostenpflichtig für eine individuelle 

Problemlösung möglich. 

3 Es existiert ein übersichtliches Interface. Erstellen von 

Modellen benötigt jedoch tiefergehende Anwenderkenntnisse 

über den Umgang mit IBM Cognos Framework Manager. 

nf-4 Integrierbarkeit 3 Cognos Framework Manager kann auf verbreiteten 

Betriebssystemen wie Linux, Unix und Windows installiert 

werden. Die Zusammenarbeit mit den Datenbanken Oracle 

DB, DB2, MS SQL Server, Sybase und Informix wird 

unterstützt. 

nf-5 Erweiterbarkeit 1 Es sind keine Plugins oder Vergleichbares zur Erweiterung 

des Funktionsumfangs verfügbar. Dem Nutzer steht lediglich 

die Kernfunktionalität der Anwendung zur Verfügung. 

nf-6 Zuverlässigkeit 3 Das Tool läuft in den meisten Fällen sehr stabil. Abstürze oder 

dergleichen sind im Rahmen der Projektgruppe keine 

vorgekommen. Möglichkeiten zum Debugging sind so nicht 

vorhanden, anhand der überwiegend klaren Fehlermeldungen 

sind diese schnell ausgemacht. Packages können anhand von 

fortlaufenden Versionen angelegt werden, wodurch eine 

Wiederherstellung einer älteren Revision durchgeführt werden 

kann. 

nf-7 Geschwindigkeit 3 In den überwiegenden Fällen war die Performanz des Tools 

sehr gut. Nur selten kam es bei größeren Joins zu verlängerten 

Wartezeiten. 

659



as-1 Datenquellen 4 Die Auswahl an anbindbaren Datenquellen ist sehr groß. An 

relationalen Datenbanken lassen sich zahlreiche verbreitete 

Anbieter einpflegen. Außerdem können weitere Datenquellen 

in Form von Cognos-Modell, Cognos Architect, Cognos 

Impromptu, Cognos Decision Steam, Cognos Data Manager 

und weitere Metadatenquellen eingebunden werden. 

as-2 

as-3 

4 Kennzahlen können anhand eines sehr umfangreichen 

Cognos-Editors mit zahlreichen Formeln und Methoden 

erstellt werden und werden u.a. in Cognos Report Studio 

verwendet. 

3 Die Dimensionsmodellierung verläuft normalerweise über vier 

Ebenen (von IBM empfohlen) in dem die Informationen aus 

den Datenquellen über mehrere Stufen stetig angepasst 

werden können. Es sind soweit keine vorgefertigten 

Dimensionen vorhanden und auch die Intuitivität lässt zu 

wünschen übrig. Cognos Framework Manager verfügt über 

einen umfangreichen Funktionsumfang. 

as-4 Cube-Funktionalität 0 Cognos Framework Manager unterstützt keine Funktionen 

zum Erstellen von Cubes. Dazu muss Cognos Transformer zur 

Hilfe genommen werden. 

Tabelle 6.2: Bewertung Analytical Services Microsoft IBM Cognos Framework Manager 

6.3 

SAP HANA 


nf-1 Unabhängigkeit 2 Die Software kann nicht einzeln Verwendet werden. Es 


besteht somit eine starke Abhängigkeit vom Hersteller. 

nf-2 

nf-3 

Support & 

Dokumentation 




4 Es werden Schulungen und Dokumente zu dem System 

angeboten. Außerdem stehen Support-Foren zur Verfügungen. 

Da sich das HANA System noch in der Entwicklung befindet, 

wird die Dokumentation stetig erweitert und der Support 

ausgebaut. 

3 Die Bedienung ist aufgrund der Eclipse-Basis für die meisten 

Entwickler bekannt und daher intuitiv. Allerdings ist HANA 

noch in der Entwicklung, daher kann sich das Design noch 

verändern. 

nf-4 Integrierbarkeit 1 Die Software wird als komplettes System vertrieben und der 

Analytical Service kann nicht alleine verwendet oder integriert 

werden. Eine Verbindung mit einem bestehenden SAP System 

ist jedoch möglich. 

nf-5 Erweiterbarkeit 0 Nicht bewertbar da die Software nicht komplett fertiggestellt 

ist. Grundsätzlich sind Erweiterungen der Eclipse-Plattform 

mit Plugins möglich. 

nf-6 Zuverlässigkeit 2 Die Datenbank hat ebenso wie das gesamte HANA-System 

noch keinen finalen Systemstand erreicht. 

nf-7 Geschwindigkeit 4 Aufgrund der In-Memory Technologie ist die Geschwindigkeit 

viel höher als bei konventionellen Systemen. 

660



as-1 Datenquellen 2 Als Datenquelle für Analysen steht nur die HANA Datenbank 

zur Verfügung, diese kann jedoch Daten aus verschiedenen 

Datenquellen aufnehmen. 

as-2 

as-3 



3 Es können Kennzahlen definiert werden, die mittels frei 

erstellbaren mathematischen Formeln aus den Daten berechnet 

werden. 

0 Die Dimensionen werden bei der Erstellung von Views 

automatisch generiert. 

as-4 Cube-Funktionalität 0 Aufgrund der In-Memory-Technologie werden zurzeit keine 

Cubes benötigt. 

Tabelle 6.3: Bewertung Analytical Services SAP HANA 

6.4 

Vergleich Analytical Services 

Nr. Kriterium Gew. SAP HANA Microsoft SSAS 


IBM Cognos 

Framework 

Manager 

nf-1 Unabhängigkeit vom Hersteller 4% 2 3 3 

nf-2 Support & Dokumentation 6% 4 4 4 

nf-3 Benutzerfreundlichkeit 6% 3 3 3 

nf-4 Integrierbarkeit 7% 1 2 3 

nf-5 Erweiterbarkeit 7% n. b. 1 1 

nf-6 Zuverlässigkeit 7% 2 3 3 

nf-7 Geschwindigkeit 3% 4 n. b. 3 

funktional 

as-1 Datenquellen 15% 2 3 4 

as-2 Kennzahlenmodellierung 25% 3 3 4 

as-3 Dimensionsmodellierung 20% n. b. 3 3 

Bewertung 2,55 2,835 3,32 

Tabelle 6.4: Vergleich Analytical Services 

Bei dem Vergleich der Anwendungen der verschiedenen Anbieter für Analytical Services ist zu 

berücksichtigen, dass die Entwicklung im Fall von SAP HANA noch nicht abgeschlossen ist und 

Änderungen möglich sind. Zudem kann HANA seine beworbenen Geschwindigkeitsvorteile aufgrund 

des Bewertungsmaßstabs und der verwendeten Datenmengen nicht zur Geltung bringen. Zusätzlich ist 

die Integrierbarkeit bei SAP HANA kaum gegeben, da lediglich eine Integration mit bestehenden 

SAP-Systemen möglich ist. Im Gegensatz dazu ist SSAS zwar für den Einsatz mit Microsoft- 

Produkten optimiert, setzt jedoch die Verwendung von Windows zwingend voraus. IBM Cognos 

Framework Manager besitzt umfangreiche Integrationsmöglichkeiten. Die Anwendung kann auf den 

661



gängigen Betriebssystemen Linux, Unix und Windows installiert werden. Die Zusammenarbeit mit 

den Datenbanken Oracle DB, DB2, MS SQL Server, Sybase und Informix wird unterstützt. Allen drei 

Fällen ist gemein, dass keine funktionalen Erweiterungen vorgesehen sind und dem Nutzer die 

Basisfunktionalität zur Verfügung gestellt wird. Dokumentation und Support sind bei allen drei 

betrachteten Anwendungen positiv aufgefallen. SSAS und Cognos unterstützen im Gegensatz zu 

HANA unterschiedliche Datenbanken als Quelle. HANA kann hingegen nur auf die eigene Datenbank 

zugreifen. 

Abschließend ist zu sagen, dass IBM Cognos Framework Manager gemäß der Bewertungsgrundlage 

mit geringem Vorsprung vor SSAS am positivsten bewertet wird. SAP fällt auch aufgrund der 

eingangs genannten Gründe eher negativ auf. Allerdings ist das Ergebnis als subjektives Empfinden 

durch die Verwendung der Anwendungen in den Teilgruppen zu interpretieren. 

7. Reporting 

Das Reporting erfolgt in der Teilgruppe Analytisches CRM über IBM Cognos. Jinengo verwendet 

sowohl die Komplettlösung Qlikview von Qliktech als auch die Microsoft SQL Server Reporting 

Services (SSRS). Smart Wind Farm nutzt die SAP HANA XS-Engine in Kombination mit Microsoft 

Excel. Excel wiederum findet in allen Teilgruppen Anwendung. 

7.1 

Microsoft SQL Reporting Services 







anpassen. 

nf-2 

nf-3 

Support & 

Dokumentation 






2 Die Software lässt sich nicht individuell an eigene Bedürfnisse 

anpassen, ist allerdings in den meisten Teilen intuitiv 

bedienbar (insbesondere durch Assistenten & GUI). 

Fortgeschrittene Reporting-Anforderungen sind dabei jedoch 

zum Teil nur durch großen Aufwand implementierbar. Es 

müssen vereinzelt softwarespezifische Begriffe erlernt 

werden. 


Umgebungen gut integrieren. Die Software setzt allerdings 

den Einsatz von Windows zwingend voraus. 

662



nf-5 Erweiterbarkeit 1 Die Software verfügt bereits über einen großen Funktionsumfang, 

lässt sich allerdings nicht eigenständig erweitern. 



r-1 Datenquellen 3 Als Datenquellen werden insbesondere die relationale sowie 

Datenbank sowie multidimensionale Quellen (SSAS) 

unterstützt. Zudem lassen sich auf Drittanbieterdatenbanken, 

XML-Dateien sowie SAP NetWeaver BI zugreifen. 

r-2 Darstellungsform 2 Reports werden mithilfe von Webtechnologien oder PDF 

dargestellt. Die graphische Gestaltung ist dabei überwiegend 

rudimentär und unästhetisch. Interaktive Reports mit Drill- 

Drown, Roll-Up, etc. sind möglich. 

r-3 Report-Assistenten 3 Die Erstellung individueller Berichte ist über die Software 

sowie über ein Webportal möglich. Die Erstellung verläuft 

dabei auf Wunsch über einen Assistenten mit Vorschaufunktion. 

r-4 Bereitstellung 3 Reports können automatisiert per Mail verschickt, per 

Webportal aufgerufen und in SharePoint integriert werden. 

Tabelle 7.1: Bewertung Reporting Microsoft SQL Reporting Services 

7.2 

Qlikview 




2 Mit QlikView erstellte Reports, Dashboards oder Self- 

Service-BI Lösungen sind ausschließlich mit QlikView zu 

öffnen. Es lassen sich eigenständige Server einrichten und 

selbstständig warten. 

nf-2 

nf-3 

Support & 

Dokumentation 


4 Für QlikView gibt es von Seiten des Herstellers eine 

ausführliche und verständliche Dokumentation in den 

gängigsten Sprachen. Für weitere Fragen kann die sehr belebte 

QlikView Community konsultiert werden. 

2 Durch seine Dokumentation und die allseits bekannten 

Symbole für gängige Funktionalitäten ist QlikView recht 

benutzerfreundlich. Komplexere Datentransformationen 

lassen sich mit einer eigenen Skriptsprache implementieren 

sind aber nicht trivial und ohne Vorkenntnisse umsetzbar. 

nf-4 Integrierbarkeit 1 QlikView Applikationen lassen sich sowohl über mobile 

Geräte darstellen, als auch in Browsern aufrufen. Für Benutzer 

der kostenlosen Personal Edition ist eine Weitergabe von 

Applikationen nur an lizenzierte Nutzer möglich. QlikView 

funktioniert nur unter aktuellen Windows Betriebssystemen. 

nf-5 Erweiterbarkeit 4 Mit JavaScript und HTML ist es möglich beliebige Extension- 

Objekte zu schreiben. Diese Objekte können Daten beliebig 

aus QlikView abfragen und transformieren. 

663



nf-6 Zuverlässigkeit 3 Die Software ist für den betrieblichen Kontext gut ausgereift 

und weist eine sehr geringe Fehlerhäufigkeit auf. Debugging 

ist möglich aber der Funktionsumfang bei diesem sehr stark 

eingeschränkt. Rücksetzung auf alte Zustände funktioniert nur 

mit Unterstützung durch eine Servervariante. Nicht bei rein 

lokalen Installationen. 

nf-7 Geschwindigkeit 0 QlikView verfolgt einen In-Memory Ansatz. Die Geschwindigkeit 

der Anwendung hängt daher stark von Art und 

Verfügbarkeit des Arbeitsspeichers ab. Allerdings ist eine 

korrekte Einschätzung im Rahmen unserer technischen 

Möglichkeiten nicht sinnvoll. 

r-1 Datenquellen 3 Daten können sowohl aus statischen Dateien (Flatfile, Excel, 

XML), als auch aus Datenbanken mit Hilfe von ODBC / 

OLEDB Treibern eingelesen werden. 

r-2 Darstellungsform 4 QlikView ermöglicht durch die flexible Anpassbarkeit nahezu 

jegliche vorstellbare Form der Datendarstellung, -kombination 

und –aufbereitung. 

r-3 Report-Assistenten 3 Reports zu erstellen ist umständlich und die Ergebnisse sind 

visuell nicht ansprechend. In Abgrenzung dazu sind die 

Analyse Dashboards Pixel-Genau und sehr umfangreich 

konfigurierbar. Eine graphische Oberfläche ermöglich das 

Einstellen aller Parameter. 

r-4 Bereitstellung 0 Unter Verwendung der Server Variante von QlikView lassen 

sich Reports/Dashboards bereitstellen und mit einem 

Rechtesystem abrufbar machen. Eine Darstellung ist, neben 

QlikView selbst, über mobile Geräte und Browser möglich. 

Kam in unserem Fall nicht zum Tragen kam. 

Tabelle 7.2: Bewertung Reporting Qlikview 

7.3 

IBM Cognos Report Studio 




3 Die Software ist nach Erwerb im Hause einsetzbar. Eine 

Abhängigkeit bzgl. der Verfügbarkeit der Software vom 

Hersteller existiert daher nicht. Allerdings lassen sich 

selbstständig keine Änderungen am Quellcode der Software 

vornehmen. Bei Insolvenz des Unternehmens ist mit etwaigen 

Updates nicht zu rechnen. Das Unternehmen IBM ist derzeit 

wenig insolvenzgefährdet. 

nf-2 

nf-3 

Support & 

Dokumentation 


4 Support durch IBM ist sowohl über die umfangreiche frei 

verfügbare firmeneigene Webdokumentation für Installation, 

Einrichtung und Nutzung als auch kostenpflichtig für eine 

individuelle Problemlösung möglich. 

3 Die Oberfläche ist klar strukturiert und nach geringer 

Einarbeitungszeit lassen sich die meisten gewünschten 

Funktionen mit wenig Zeitaufwand finden und einsetzen. Für 

Anfänger und Einsteiger in die Berichtsentwicklung dürften 

die Möglichkeiten überfordern. 

664



nf-4 Integrierbarkeit 3 IBM Cognos Report Studio kann auf gängigen Betriebssystemen 

wie AIX, HP Itanium, HP-UX, Linux, Solaris, Windows 

verwendet werden. 

nf-5 Erweiterbarkeit 1 Es sind keine Plugins oder Vergleichbares zur Erweiterung 

des Funktionsumfangs verfügbar 

nf-6 Zuverlässigkeit 3 Für eine reine Web-Applikation bietet Cognos Report Studio 

eine ungemein hohe Zuverlässigkeit an. Es läuft überwiegend 

stabil und Abstürze sind meist nur durch Auswahl des 

Internetbrowsers hinzunehmen. 

nf-7 Geschwindigkeit 4 Das Erstellen und Aufrufen der Berichte in der Entwicklungsumgebung 

läuft schnell und flüssig. Es konnten in keiner 

Weise Einschränkungen festgestellt werden. Das Ausführen 

der Berichte nimmt selbstverständlich je nach Datenmenge 

etwas Zeit in Anspruch. 

r-1 Datenquellen 1 Cognos Report Studio kann nur mit zuvor vom Framework 

Manager erstellten und veröffentlichten Packages oder Cubes 

vom Cognos Transformer arbeiten. Zwar besteht darüber die 

Anbindung an zahlreiche Datenquellen, aber auch eine 

Abhängigkeit des vorgelagerten Tools. 

r-2 Darstellungsform 4 Daten im Bericht können auf sämtlichen Wegen dargestellt 

werden, Cognos Report Studio setzt fast keine Grenzen. Es 

sind zahlreiche Diagramm- und Tabellentypen auswählbar, die 

wiederum viele individuelle Anpassungen zulassen. Innerhalb 

von OLAP-Datenquellen lassen sich auch Drill-Downs in 

Diagrammen oder Tabellen umsetzen. 

r-3 Report-Assistenten 2 Da das Report Studio für Ad-hoc bzw. schnell erstellte 

Berichte nicht geeignet ist, sind dementsprechende Vorlagen 

nur sehr rudimentär vorhanden. Einige Kernobjekte wie 

Diagramme oder Tabellen können zwar auch mit einem 

einfachen Wizard angelegt werden, darin liegt aber nicht die 

Kernfunktion vom Report Studio. 

r-4 Bereitstellung 4 Mit Cognos Report Studio einher geht die Einrichtung eines 

Web-Portal (bei CEWE das VIS) worüber das Tool gestartet 

wird. Das Portal lässt sich fast vollständig individuell 

anpassen und stellt die Berichte zur Verfügung. Berichte 

können auch zeitlich getriggert an gewünschte Adresse 

versendet werden. Berichte können als HTML-, PDF-, Excel-, 

CSV- oder XML-Datei exportieren und ermöglichen somit 

auch eine umfangreiche Integration in andere Tools. 

Tabelle 7.3: Bewertung Reporting IBM Cognos Reporting Studio 

7.4 

Microsoft Excel 





wenig insolvenzgefährdet. Excel lässt sich nur als 

Teil des Office-Pakets von Microsoft erwerben. 

665



nf-2 

nf-3 

Support & 

Dokumentation 






3 Excel zählt mit zu den benutzerfreundlicheren Microsoft- 

Produkten. Durch zahlreiche Online-Hilfen und Anleitungen, 

sowie das gewohnte Microsoft Look-And-Feel ist der Nutzer 

schnell in der Lage Ergebnisse zu erzielen. 

nf-4 Integrierbarkeit 4 Als Teil der Office Lösung von Microsoft braucht man sich 

bei der Integrierbarkeit von Microsoft Excel keine Sorgen 

machen. Nahezu jeder kennt es, oder hat es schon mal genutzt. 

Durch das typische Microsoft Look-and-Feel wird dem Nutzer 

diese Integration sehr leicht gemacht. 

nf-5 Erweiterbarkeit 4 Excel lässt sich über Plug-Ins und gegebenenfalls mittels 

.NET (Visual Basic bzw. C#) um diverse benötigte 

Funktionalitäten erweitern. Die letzten Versionen (2010 und 

2013) erlauben die Entwicklung von Custom-Ribbons und 

Plug-Ins. 

nf-6 Zuverlässigkeit 3 Seit dem ersten Auftreten von Excel im Jahr 1987 (davor 

unter anderem Namen) wurde es permanent weiterentwickelt 

und verbessert, was für die Reife des Programms stehen sollte. 

Es verfügt auch über rudimentäre Daten Wiederherstellungsfunktionalitäten. 

nf-7 Geschwindigkeit 3 Bei den Datenmengen mit denen wir zu tun hatten, zeigte sich 

Excel sehr performant. Die Skalierung nimmt man selbst über 

die Auswahl der Daten vor. 

r-1 Datenquellen 3 Excel ist in der Lage Daten aus verschiedensten Quellen 

abzurufen. Über die entsprechenden ODBC-Treiber oder OLE 

DB-Provider lässt sich mit Excel auf alle gängigen 

Datenbanken zugreifen. Leider stellt sich das Zusammenspiel 

von Excel mit neueren Webservices problematisch dar. 

r-2 Darstellungsform 3 Excel verfügt über diverse Darstellungsformen zur 

Visualisierung und Analyse von Daten, bleibt dabei aber 

hinter anderen Programmen zurück, da es einfach nicht die 

Interaktivität im Umgang mit den Daten liefert, die andere 

Programme liefern. Die Bewertung bezieht sich auf die letzte 

Version 2013 mit der PowerView-Funktion. 

r-3 Report-Assistenten 2 In Excel ist man bei der Erstellung seiner Reports und der 

Darstellung der gewünschten Daten weitestgehend auf sich 

allein gestellt. 

r-4 Bereitstellung 1 Mit Excel selbst ist es nicht möglich die Reports automatisch 

zu verschicken oder bereitzustellen. 

Tabelle 7.4: Bewertung Reporting Microsoft Excel 

666



7.5 

Vergleich Reporting 

Nr. Kriterium Gew. QlikView 

nf-1 


Unabhängigkeit vom 

Hersteller 

Microsoft 

Excel 

Microsoft 

SSRS 

IBM 

Cognos 

Report 

Studio 

4% 2 3 3 3 

nf-2 Support & Dokumentation 6% 4 4 4 4 

nf-3 Benutzerfreundlichkeit 6% 2 3 2 3 

nf-4 Integrierbarkeit 7% 1 4 2 3 

nf-5 Erweiterbarkeit 7% 4 4 1 1 

nf-6 Zuverlässigkeit 7% 3 3 3 3 

nf-7 Geschwindigkeit 3% n. b. 3 n. b. 4 

funktional 

r-1 Datenquellen 10% 3 3 3 1 

r-2 Darstellungsform 20% 4 3 2 4 

r-3 Report-Assistenten 20% 3 2 3 2 

r-4 Bereitstellung 10% n. b. 1 3 4 

Bewertung 3,025 2,8 2,575 2,85 

Tabelle 7.5: Vergleich Reporting 

Die Anforderungen der einzelnen Teilgruppen an ihre für das Reporting genutzten Tools variierten. 

Dies sieht man daran, dass sich die „nicht bewertbaren“ Kategorien in wenigen Fällen decken. In 

anderen Bereichen liegen die Tools nah beieinander. IBM Cognos Report Studio hat als einzigen 

richtigen Kritikpunkt die Tatsache, dass als Datenquellen der Cognos Transformer bzw. der Cognos 

Framework Manager genutzt werden müssen. Microsofts SSRS hat dabei Defizite bei den zur 

Verfügung stehenden Darstellungsformen, sowie der Erweiterbarkeit und Benutzerfreundlichkeit. 

Anhand der Nutzwertanalyse lässt sich feststellen, dass MS Excel wenige Möglichkeiten zur 

automatisierten Bereitstellung der Reports gibt. 

Alle vier Tools wurden als gut bzw. sehr gut bei den Kriterien „Support & Dokumentation“, 

„Zuverlässigkeit“ und „Darstellungsform“ bewertet. Microsoft Excel und IBM Cognos sammeln viele 

Punkte in den nicht-funktionalen Kriterien während QlikView und Microsoft SSRS bei einigen 

Kriterien sehr schlecht bewertet wurden. Umgekehrt ist es bei den funktionalen Kriterien. Dort haben 

Microsoft SSRS und QlikView konsistent gute Noten während Microsoft Excel und IBM Cognos 

durchwachsene Bewertungen erhalten. 

667



8. Data Mining 

IBM SPSS Modeler wird hauptsächlich von der Teilgruppe Jinengo und in begrenztem Umfang von 

Analytisches CRM eingesetzt. Die Anwendung wird mit dem von Smart Wind Farm genutzten R 

verglichen. 

8.1 

IBM SPSS Modeler 




1 Es sind nur die vom Hersteller angebotenen Funktionen 

verfügbar. Zusätzliche Pakete werden vom Anbieter 

angeboten. Eigenprogrammierung ist im System nicht 

möglich. 

nf-2 

nf-3 

Support & 

Dokumentation 


4 Umfangreiche Dokumentation, Hilfe-Fenster und White Paper 

von IBM . 

3 Ohne Programmierkenntnisse anwendbar. Übersichtliche 

Darstellung des Programms und seiner Optionen. Keine 

versteckten Menüs etc. 

nf-4 Integrierbarkeit 2 Lokale Installation auf Windows OS als auch Server Variante 

möglich. 

nf-5 Erweiterbarkeit 2 Addons werden nur von IBM vertrieben. 

nf-6 Zuverlässigkeit 2 Debugging nicht möglich, in dem Anwendungsfall aber nicht 

sehr sinnvoll. Die Fehlermeldungen geben ausreichend 

Aufschluss über die Ursache, so dass viele Fehler schnell 

behoben werden können. 

nf-7 Geschwindigkeit 0 Abhängig von den Daten und der Systemumgebung. In 

unserer Anwendung keine relevante Aussage möglich. 

dm-1 Datenquellen & -ziel 4 Alle Standard Datenquellen können angebunden werden. 

dm-2 Unterstützte 

Methoden 



& Evaluierung 

3 Die Algorithmen werden in 3 Kategorien unterteilt 

(Clustering, Assoziation, Classification). Jede Kategorie 

beinhaltet gängige Algorithmen zur Analyse. Ändern oder 

hinzufügen von Algorithmen ist nicht einfach möglich. 

4 Es stehen sowohl graphische als auch Auswertungen in 

Tabellenform zur Verfügung. Die Ergebnisse sind exportierund 

speicherbar. Der Algorithmus ist über ein graphisches 

Interface kalibrierbar. 

Tabelle 8.1: Bewertung Data Mining IBM SPSS Modeler 

668



8.2 

R 


nf-1 Unabhängigkeit 4 Es handelt sich um Open Source Software, die beliebig 


verändert werden darf (in Form neuer Libraries) 

nf-2 

nf-3 

Support & 

Dokumentation 


3 Es existieren umfangreiche Dokumentationen und eine große 

Community, die Hilfestellung leistet. Die Dokumentation 

bezieht sich jedoch oft nur auf einzelne Libraries und ist daher 

teilweise schwierig zu finden. 

2 Es stehen zwar GUIs für R zur Verfügung, allerdings sind 

diese nicht für alle Zwecke einsetzbar. Für das Data Mining 

muss mit Konsoleneingaben gearbeitet werden. Nach einer 

gewissen Einarbeitungszeit ist die Software sehr einfach 

bedienbar. 

nf-4 Integrierbarkeit 3 R kann auf allen Plattformen eingesetzt werden. 

nf-5 Erweiterbarkeit 4 Aufgrund der Möglichkeit, eigene Libraries zu schreiben, 

bzw. fremde Libraries einzubinden, ist R beliebig erweiterbar. 

nf-6 Zuverlässigkeit 3 Das System besitzt eine sehr fortgeschrittene Systemreife. 

Debugging steht nur für die Eigenentwicklung von Libraries 

zur Verfügung, wird sonst jedoch auch nicht benötigt. 

nf-7 Geschwindigkeit 0 Abhängig von den Daten und der Systemumgebung. In 

unserer Anwendung keine genaue Aussage möglich. 

dm-1 Datenquellen & -ziel 4 Alle Standard Datenquellen können angebunden werden. Als 

Datenziel stehen beispielsweise Objekte oder Dateien zur 

Verfügung, es kann nicht direkt in eine Datenbank 

geschrieben werden. 

dm-2 Unterstützte 

Methoden 



& Evaluierung 

4 Für R existieren tausende zusätzliche Libraries für spezielle 

Anwendungszwecke. Auch für das Data Mining stehen viele 

Libraries zur Verfügung. Es können sowohl Methoden 

geändert als auch neue definiert werden. 

4 Es stehen sowohl graphische als auch Auswertungen in 

Tabellenform zur Verfügung. Die Ergebnisse sind exportierund 

speicherbar. Die Qualität der Methoden kann evaluiert 

werden, beispielsweise durch Kreuzvalidierung. 

Tabelle 8.2: Bewertung Data Mining R 

669



8.3 

Vergleich Data Mining 

Nr. Kriterium Gew. R IBM SPSS Modeler 


nf-1 Unabhängigkeit vom Hersteller 4% 4 1 

nf-2 Support & Dokumentation 6% 3 4 

nf-3 Benutzerfreundlichkeit 6% 2 3 

nf-4 Integrierbarkeit 7% 3 2 

nf-5 Erweiterbarkeit 7% 4 2 

nf-6 Zuverlässigkeit 7% 3 2 

nf-7 Geschwindigkeit 3% n. b. n. b. 

funktional 

dm-1 Datenquellen & -ziele 15% 4 4 

dm-2 Unterstützte Methoden 25% 4 3 

dm-3 Prozessmanagement, Datenvisualisierung 

& Evaluierung 

20% 4 4 

Bewertung 3,635 3,105 

Tabelle 8.3: Vergleich Data Mining 

SPSS Modeler und R sind zwei umfassende Tools zur Lösung von Data Mining Anwendungsfällen. 

Da Data Mining ein sehr komplexes Thema ist, und tiefgreifendes Vorwissen zur korrekten 

Anwendung der Algorithmen notwendig ist, sind auch die Tools dementsprechend komplex. Während 

SPSS Modeler von IBM eine lizensierte Software ist, wird R unter den Open Source Richtlinien 

bereitgestellt und ist für jedermann zugänglich. Daraus begründen sich auch die Hauptunterschiede der 

beiden Produkte. Während R sehr offen konfigurierbar und erweiterbar ist, wird SPSS Modeler als 

fertiges Produkt vertrieben, welches nur durch zusätzliche Kosten erweiterbar ist. Um R sinnvoll 

einsetzen zu können braucht man mehr Ressourcen und Know-how, das im Unternehmen aufgebaut 

werden muss. SPSS Modeler kann relativ zügig installiert werden und erste Ergebnisse sind schneller 

erzielt, allerdings nur im Rahmen der vorgegeben Möglichkeiten. Zudem bietet es Garantie- und 

Supportleistungen, die bei R nicht gegeben sind. Auf der anderen Seite besitzt R eine große Online 

Community für die Beantwortung von Fragen und Neuentwicklungen. Zusammenfassend lässt sich 

sagen, dass keines der beiden Tools als „besser“ bezeichnet werden kann, da dies vom jeweiligen 

Anwendungszweck und Unternehmenseigenheiten abhängig ist. Beide Tools bieten eine sehr große 

Auswahl an Data Mining Methoden und sind beide beliebte und sehr ausgereifte Produkte. 

670



9. Fazit 

Ziel dieser Dokumentation war es, einen Technologievergleich in Bezug auf die eingesetzten 

Anwendungen in den jeweiligen Teilgruppen durchzuführen. Zu diesem Zweck wurden folgende BI 

Komponenten definiert: 

- Database 

- ETL 

- Analytical Services 

- Reporting 

- Data Mining 

Die im Rahmen der Projektgruppe eingesetzten Softwarelösungen wurden anschließend diesen 

Feldern zugeteilt. Die Einordnung von SAP HANA in diesen Rahmen erwies sich als schwierig. 

HANA versteht sich als integriertes Komplettsystem, es wurde daher mehreren der oben genannten 

Komponenten zugeordnet. Der Microsoft SQL Server ist ein ähnlich integriertes System wie HANA, 

lässt sich jedoch auf Grund der Gliederung in Subsysteme, wie SSIS, SSAS und SSRS, eindeutig den 

einzelnen Komponenten zuordnen. 

Zu den Komponenten wurden verschiedene Kriterien als Bewertungsgrundlage der Anwendungsfelder 

herausgearbeitet. Die Bewertungskategorien sind jeweils in übergreifend gültige nichtfunktionale 

Anforderungen sowie komponentenspezifische funktionale Anforderungen unterteilt. Bei der Auswahl 

der Kriterien wurde eine gemeinsame Schnittmenge aus den spezifischen Anforderungen gebildet. Die 

einzelnen Gewichtungen der Kriterien wurden über die Teilgruppen hinweg abgestimmt. 

Auf Grund der zur Bewertung der Softwarelösungen herangezogenen Methode der Nutzwertanalyse, 

erfolgt die Beurteilung der Kriterien auf subjektiver Basis. Die Anwendungsfälle sind thematisch 

voneinander abgegrenzt; die Kriterien können daher nicht gleichwertig bewertet werden. Zudem 

wurde in den Teilgruppen nicht der gesamte Funktionsumfang der Softwarelösungen genutzt; er kann 

somit auch nicht vollständig in die Bewertung einfließen. Die einzelnen Bewertungen entstanden 

somit subjektiv aus den einzeln gesammelten Erfahrungen der Teilgruppen, sind jedoch anschließend 

diskutiert und reflektiert worden. Ein unumstößliches Ergebnis hätte die Projektgruppe nur dann 

erhalten können, wären alle Softwarelösungen im gleichen Anwendungsfall eingesetzt worden. 

Die Bewertung der einzelnen Komponenten lässt erkennen, dass die untersuchten Softwarelösungen 

voneinander abweichende Schwerpunkte haben. So ist etwa Microsoft Excel im Gegensatz zu 

QlikView kein auf Reporting ausgelegtes Werkzeug, kann jedoch als solches verwendet werden. Der 

Bekanntheitsgrad und die leichte Integrierbarkeit in bestehende IT-Landschaften ermöglichen den 

vielfältigen Einsatz von Microsoft Excel u. a. als Reporting-Tool. QlikView hingegen ist mit Aufwand 

bei der Integration und Einrichtung sowie Schulungsaufwand verbunden. Die aus dem Technologie- 

671



vergleich gewonnene Erkenntnis ist daher, dass keine der bewerteten 

einzelnen Komponenten als universell einsetzbar zu bezeichnen ist. 

Softwarelösungen in den 

Schlussfolgernd ist dem Technologievergleich zu entnehmen, dass jede in den Teilprojekten 

eingesetzte Anwendung den gewünschten Verwendungszweck erfüllt hat. Da die Anforderungen und 

Schwerpunkte in den Teilprojekten jedoch nicht einheitlich sind, ist es nicht unmittelbar möglich, die 

Bewertung auf andere Anwendungsfälle zu übertragen. 

Insgesamt kann festgehalten werden, dass sich die verwendeten Technologien in BI Projekten 

durchaus verwenden lassen. Jedoch hat die Erfahrung der Projektgruppe gezeigt, dass die Auswahl 

von Softwarelösungen für einen bestimmten Einsatzzweck im Vorfeld kritisch hinterfragt werden 

muss. Die unterschiedlichen Schwerpunkte der Anwendungen haben gezeigt, dass nicht jede 

Softwarelösung für jedes Einsatzgebiet uneingeschränkt geeignet ist. Es empfiehlt sich daher, in der 

Vorbereitungsphase eines BI Projektes eine umfangreiche Analyse der zur Auswahl stehenden 

Anwendungen durchzuführen. Es kann dadurch einem später erforderlichen, mit viel Aufwand 

verbundenen Wechsel vorgebeugt werden. 

672


Fazit Projektgruppe 



Fazit 

673



674



Fazit 

Rückblickend lässt sich festhalten, dass die Organisation der Projektgruppe eine besondere Herausforderung 

darstellte. Die Gruppengröße von 13 Personen sowie die Aufteilung der Studierenden in drei Projekte 

erforderten ein hohes Maß an Koordinations- und Kommunikationsaufwand. Durch regelmäßige Treffen 

und das Engagement aller Projektteilnehmer konnten diese Herausforderungen gemeistert werden. 

Die Zielsetzungen der einzelnen Teilgruppen waren durch wechselnde Ansprechpartner, unterschiedliche 

Vorstellungen und äußere Einflüsse einem stetigen Wandel ausgesetzt. Die wechselnden Anforderungen, 

mit denen die Studierenden konfrontiert waren, machten eine hohe Flexibilität erforderlich. 

In den Projekten konnten die Studierenden sowohl Erfahrungen mit bestehenden Softwarelösungen sowie 

mit Eigenentwicklungen sammeln. In der Projektzeit wurden neben den technologischen auch die organisatorischen 

Kenntnisse der Studierenden erweitert. 

Bezüglich der Ergebnisse der Projektgruppen lässt sich festhalten, dass diese auch in Zukunft Verwendung 

finden werden. CEWE wird die Projektergebnisse des Projektes „gestochen scharfe Fragen stellen“ 

betrieblich einsetzen und weiterführen. Die Ergebnisse des Projektes Jinengo werden von der Abteilung 

Very Large Business Applications (VLBA) der Universität Oldenburg als wissenschaftliches Projekt fortgesetzt. 

Das Projekt der Smart Wind Farm Control Gruppe wird einerseits aus thematischer Sicht als wissenschaftliches 

Projekt der Abteilung VLBA fortgesetzt und andererseits aus technischer Sicht als Grundlange 

für eine weiterführenden Projektgruppe genutzt. Der Technologievergleich stellt eine Entscheidungsbasis 

für andere Anwendungsfälle dar. Der Vergleich beantwortet unter anderem folgende, grundlegende 

Fragestellungen: 

- Wie gut ist ein Tool für den Einsatz im BI-Umfeld geeignet? 

- Wozu kann ein Tool im BI-Umfeld verwendet werden? 

- Welche Funktionen gibt es und wie gut oder schlecht sind diese? 

Zusammenfassend lässt sich festhalten, dass von der Projektgruppe aussagekräftige Ergebnisse erarbeitet 

worden sind. Viele der Ergebnisse werden daher Anwendung in zukünftigen Einsatzbereichen finden. Es 

zeigt sich weiterhin, dass die Studierenden in den praxisnahen Anwendungsfällen sowohl inhaltlich als 

auch methodisch dazugelernt haben. Die Erkenntnisse des letzten Jahres haben den Studierenden geholfen, 

zukünftig kompetenter auf komplexe Aufgabenstellungen im Umfeld von Projekten reagieren zu 

können. 

675

Projektgruppe Business Intelligence Applications and Evaluation ...

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?