Danksagung. Je mühsamer der Aufstieg, desto befreiter erreichen wir das Ziel. Angelika Mack

Größe: px
Ab Seite anzeigen:

Download "Danksagung. Je mühsamer der Aufstieg, desto befreiter erreichen wir das Ziel. Angelika Mack"

Transkript

1

2 Danksagung Mein Dank geht an dieser Stelle an Alle, die mich im Laufe meiner Studienzeit unterstützt, gefördert und gefordert haben. Ein ganz besonderer Dank geht an Prof. Dr. Uwe Haneke, der mich in der Wahlpflichtveranstaltung Business Intelligence für diese Thematik begeistern konnte und ohne den diese Master-Thesis sicherlich nie entstanden wäre. Bedanken möchte ich mich auch bei der Jedox AG, die mir im vergangenen halben Jahr ermöglicht hat, meine Abschlussarbeit zu schreiben und mir auch viele interessante Einblicke gewährt hat. Und wenn ich nun auch allen Korrekturlesern danke sagen möchte, dann gilt dies ganz besonders für Dr. Tobias Lauer, durch den das Thema dieser Arbeit erst zustande kam und der mir über die gesamte Dauer ein kritischer und engagierter Ansprechpartner war. Nicht zuletzt danke ich auch meiner Familie und speziell meinen Eltern, die mir es letztlich doch immer ermöglicht haben, dass ich meinen Weg gehen konnte. Auch in schwierigen Zeiten konnte ich mir eurer Unterstützung immer sicher sein und ich weiß, dass ich es eigentlich viel zu selten sage: Danke! Je mühsamer der Aufstieg, desto befreiter erreichen wir das Ziel. Angelika Mack

3 Eigenständigkeitserklärung Hiermit versichere ich, dass ich die vorliegende Arbeit selbständig und ohne andere als die angegebenen Quellen und Hilfsmittel verfasst habe. Die aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche gekennzeichnet. Freiburg im Breisgau, den 28. Oktober 2010

4 Kurzzusammenfassung Business-Intelligence-Systeme haben sich als wichtiger Teil der modernen Unternehmenssteuerung etabliert und längst nutzen nicht mehr nur große Konzerne, sondern zunehmend auch kleine und mittelständische Unternehmen die sich bietenden Möglichkeiten. Trotzdem hat die Business Intelligence die Massen noch nicht erreicht [FMB + 10, Seite 14]. Mittelfristig geht der Trend dahin, nicht nur dem Top-Management, sondern auch dem mittleren Management sowie den Sachbearbeitern den Zugang zu BI-Lösungen zu ermöglichen. Die Performance spielt dabei gleich in doppelter Hinsicht eine Rolle. Zum Einen ist für die Akzeptanz durch den Endnutzer ein ausreichend schnelles System nötig, zum Anderen benötigt eine solche Erweiterung des Anwenderkreises auch ein entsprechend skalierendes System, wobei die Skalierbarkeit ihrerseits eng mit der Performance korreliert. Auch wenn im BI Survey 9 die Datenqualität erstmals größtes Problem von BI- Anwendungen ist, so bleibt die Performance auch weiterhin das mit Abstand dringendste produktbezogene Problem. Für Anwender ist es aber in Ermangelung eines herstellerübergreifenden Vergleichs aufgrund der Unterschiede der Systeme sowie unüblicher Proof-of-Concepts unter Realbedingungen nahezu unmöglich, Alternativen im hinsichtlich der Performance miteinander zu vergleichen. Diese Master-Thesis versucht, eine objektive Vergleichbarkeit zu schaffen und mehrere OLAP-Server Kern und zentraler Datenspeicher jeder BI-Anwendung einander gegenüberzustellen. Betrachtet werden nur Produkte, die auf die In- Memory-Technologie setzen. Diese letzte Revolution [Com06] im BI-Bereich sorgt für die Datenhaltung im Hauptspeicher. Mit den schnelleren Zugriffszeiten lässt sich den aufgrund wachsender Datenvolumen und höherer Ansprüche der Benutzer stetig steigenden Performance-Anforderungen begegnen. Dabei gibt es signifikante Unterschiede der OLAP-Server in den Bereichen ETL, Analyse und Planung.

5 Abstract Business Intelligence systems established itself as an important part of modern corporate management. Both huge and small or medium-sized companies are using the provided possibilities. Nevertheless business intelligence has not reached the masses yet [FMB+10, page 14]. One of the current trends is to provide access on BI systems not only to the top management but also to the middle management and the clerks. Performance thereby is an issue in two different ways. On the one hand a sufficiently fast system is necessary to be accepted by the users and on the other hand the system has to scale very well to expand to new user groups. That means scalability and performance are related very tight. Even if data quality has become the biggest problem of BI applications in BI Survey 9, performance still is the most urgent product-related problem. However it is very difficult for end-users to compare different systems regarding the performance because there is no cross-vendor benchmark. Unfortunately proof-of-concepts under real conditions are unusual yet. This Master s Thesis tries to create an objective comparability of different OLAP servers which are core and central data storage of every BI application. Only products that are using In-Memory technology are regarded within this benchmark. In-Memory technology has been the latest big revolution [Com06] in business intelligence and means, that all data is stored in the main memory. Thereby faster access times are possible to face the growing performance requirements and higher claims of the users. As the results will show, there are significant differences between the OLAP servers in the areas of ETL, analysis and planning. 5

6 Inhaltsverzeichnis 1 Entwicklung und Bedeutung von Business-Intelligence-Systemen Begriffsdefinition Entwicklung von Business-Intelligence-Systemen Status quo Ausblick Technische Innovationen Fachliche und betriebswirtschaftliche Entwicklungen Organisatorische Strukturen OLAP und Einordnung in die BI-Referenzarchitektur Begriffsdefinition OLAP Varianten von OLAP Typische Operationen Abgrenzung zu OLTP Einordung von OLAP in die BI-Referenzarchitektur Die BI-Referenzarchitektur nach Bauer und Günzel In-Memory-Technologie Vergleichbarkeit von OLAP-Systemen Analytic Processing Benchmark Testumfang und -ablauf Veröffentlichung der Testergebnisse Bewertung Transaction Processing Performance Council Benchmark H Testumfang und -ablauf Veröffentlichung der Testergebnisse Bewertung

7 Inhaltsverzeichnis Rückschlüsse für die eigene Arbeit Typische Szenarien im OLAP-Einsatz Analyse von Kundenanwendungen aus der Praxis Kunde 1: Debitoren-Controlling und Umsatzanalyse Kunde 2: Umsatzanalyse und -planung, Finanzcontrolling Kunde 3: Kreditcontrolling Kunde 4: Komplette Unternehmenssteuerung Kunde 5: Debitoren-Controlling Kunde 6: Projektabrechnung Kunde 7: Analyse von Umsatz, Projekten und Personal Die typischen Szenarien Entwicklung des OLAP-Benchmarks Marktübersicht und Auswahl der Testkandidaten Die Hardware Testszenarien und Datenmodelle Datenmodell für die Umsatzanalyse Datenmodell der Personalplanung Datengenerierung Abfragen innerhalb der Umsatzanalyse Aktionen innerhalb der Personalplanung Durchführung des OLAP-Benchmarks Palo Benchmark des ETL-Prozesses Benchmark der Umsatzanalyse Benchmark der Personalplanung Infor PM Benchmark des ETL-Prozesses Benchmark der Umsatzanalyse Benchmark der Personalplanung Cognos TM Benchmark des ETL-Prozesses Benchmark der Umsatzanalyse

8 Inhaltsverzeichnis Benchmark der Personalplanung Zusammenfassung und Bewertung ETL-Prozess Umsatzanalyse Personalplanung Drei Teilbereiche, drei OLAP-Server, drei unterschiedliche Gewinner Fazit 92 A Statistiken der Kundenanwendungen 94 A.1 Kunde 1 aus Kapitel A.2 Kunde 2 aus Kapitel A.3 Kunde 3 aus Kapitel A.4 Kunde 4 aus Kapitel A.5 Kunde 5 aus Kapitel A.6 Kunde 6 aus Kapitel A.7 Kunde 7 aus Kapitel B Ergebnisse der Performancemessung 101 B.1 Palo OLAP-Server B.1.1 Umsatzanalyse B.1.2 Personalplanung B.2 Infor PM B.2.1 Umsatzanalyse B.2.2 Personalplanung B.3 Cognos TM B.3.1 Umsatzanalyse B.3.2 Personalplanung Literaturverzeichnis 118

9 Abbildungsverzeichnis 1.1 Enges, analyseorientiertes oder weites BI-Verständnis? Informationspyramide Historie von entscheidungsunterstützenden Systemen n-dimensionaler Hyperwürfel Slicing und Dicing in einem multidimensionalen Datenwürfel Drill-Down und Roll-Up - Aggregation und Aufschlüsselung der Daten Neue Sicht auf die Daten durch Pivotierung Ein OLAP-Join verbindet Datenwürfel mit gleichen Dimensionen Referenzmodell für die Architektur von Data-Warehouse-Systemen Struktur und Zusammenhänge zwischen den vom APB-1 generierten Dateien Das Datenmodell des APB-1 als Snowflake-Schema Datenschema des Benchmarks TPC-H Die Anwendungszwecke der Jedox-Kunden Datenfluss von der Datenintegration über die -aufbereitung bis hin zur -analyse Datenmodell der Umsatzanalyse Datenmodell des Szenarios Personalplanung Entwicklung der Ladeperformance des OLAP-Servers Palo Performance des OLAP-Servers Palo bei der Umsatzanalyse Performance des OLAP-Servers Palo bei der Umsatzanalyse mit 4 GPUs im Vergleich zur Umsatzanalyse ohne GPU-Unterstützung Performance des OLAP-Servers Palo im Planungsszenario

10 Abbildungsverzeichnis Entwicklung der Ladeperformance von Infor PM Performance des OLAP-Servers Infor PM 10 bei der Umsatzanalyse Performance des OLAP-Servers Infor PM 10 im Planungsszenario Entwicklung der Ladeperformance von IBM Cognos TM Performance des OLAP-Servers IBM Cognos TM1 bei der Umsatzanalyse Performance des OLAP-Servers IBM Cognos TM1 im Planungsszenario Die Performance der OLAP-Server beim ETL-Prozess im direkten Vergleich Die Performance der OLAP-Server in der Analyse im direkten Vergleich Die Performance der OLAP-Server bei der Planung im direkten Vergleich

11 Tabellenverzeichnis 2.1 Unterschiede zwischen OLTP und OLAP Die Anwendungszwecke von BI-Lösungen bei Kunden der Jedox AG Zusammenfassung der Kundenanwendungen mit Umsatzanalyse Personalplanung aus der analysierten Kundenanwendung Größe der Dimensionen innerhalb der Umsatzanalyse Größe der Dimensionen innerhalb der Personalplanung Benötigte Zeit zum Laden der Daten in den OLAP-Server Palo Performance des OLAP-Servers Palo bei der Umsatzanalyse Performance des OLAP-Servers Palo bei der Umsatzanalyse mit 4 GPUs Performance des OLAP-Servers Palo im Planungsszenario (1. Aufruf) Performance des OLAP-Servers Palo im Planungsszenario ( Aufruf) Benötigte Zeit zum Laden der Daten in den OLAP-Server Infor Performance des OLAP-Servers Infor PM 10 im Analyseszenario Performance des OLAP-Servers Infor PM 10 im Planungsszenario Benötigte Zeit zum Laden der Daten in den OLAP-Server IBM Cognos TM Performance des OLAP-Servers IBM Cognos TM1 im Analyseszenario Performance des OLAP-Servers IBM Cognos TM1 im Planungsszenario Relativer Anteil der einzelnen Abfragen bei 64 Mio. Datensätzen Relativer Anteil der einzelnen Operationen bei 3,2 Mio. Datensätzen 90 11

12 Kapitel 1 Entwicklung und Bedeutung von Business-Intelligence-Systemen Der Begriff Business Intelligence entstand bereits im Jahre 1958 während der Forschungen zur selektiven Verbreitung von Informationen durch den IBM-Mitarbeiter Hans Peter Luhn und wurde ab 1989 von Howard Dresner, seinerzeit Analyst beim US-Marktforschungsunternehmen Gartner, aufgegriffen und geprägt. Ebenso unterschiedlich wie die Anbieter und deren Produkte sind aber bis heute auch die Interpretationen des Begriffs Business Intelligence. Auf den folgenden Seiten will ich deshalb zunächst versuchen, eine adäquate Definition des weit verbreiteten und dennoch so unterschiedlich interpretierten Begriffs zu finden. Dem historischen Abriss folgt die Betrachtung des Status quo und der aktuellen Herausforderungen sowie der Themen, die den BI-Markt in der nahen Zukunft beschäftigen werden. 1.1 Begrisdenition Auch wenn der Begriff Business Intelligence in der Wirtschaft schon fast allgegenwärtig und die Notwendigkeit sowie der Nutzen von BI-Systemen unumstritten ist, fehlt es bis heute an einer allgemeingültigen und durchgängig akzeptierten Definition. Wie die Abbildung 1.1 zeigt, gibt es drei unterschiedliche Sichtweisen vom engen über das analyseorientierte bis hin zum weiten BI-Verständnis. Diese konkurrierenden Definitionen haben zu einer Verwässerung des Begriffs geführt. 12

13 Kapitel 1 Entwicklung und Bedeutung von Business-Intelligence-Systemen 13 Abb. 1.1: Enges, analyseorientiertes oder weites BI-Verständnis? (In Anlehnung an [Zim08]) Hinsichtlich des Prozessschwerpunkts schwankt der Fokus zwischen der Verarbeitung der Rohdaten im Rahmen des ETL-Prozesses und der Anzeige der Ergebnisse. Die Aspekte sind dabei teilweise sehr technisch orientiert, teilweise aber auch ganz auf die Anwendung hin ausgerichtet. Bei einer solch großen Heterogenität wundert es kaum, dass Peter Mertens in [Mer02] sieben unterschiedliche Einsatzzwecke von BI-Anwendungen identifizieren konnte: BI als Fortsetzung der Daten- und Informationsverarbeitung BI als Filter der Informationsflut BI = MIS (Management Information System), aber besonders schnelle und flexible Auswertungen BI als Frühwarnsystem ( Alerting ) BI = Data Warehouse BI als Informations- und Wissensspeicher BI als Prozess: Symptomerhebung Diagnose Therapie Prognose Therapiekontrolle

14 Kapitel 1 Entwicklung und Bedeutung von Business-Intelligence-Systemen 14 Um im weiteren Verlauf die OLAP-Technologie und ihre Bedeutung innerhalb der Business Intelligence einordnen zu können, soll das weite BI-Verständnis vertreten werden. So versuchten auch Humm und Wietek in [HW05, Seite 4] die unterschiedlichen Anwendungen unter einer Definition zusammenzufassen: Business Intelligence umfasst ein breites Spektrum an Anwendungen und Technologien zur entscheidungsorientierten Sammlung, Aufbereitung und Darstellung geschäftsrelevanter Informationen. Ohne technische Details der Implementierung vorwegzunehmen, werden die drei Hauptaufgaben von BI-Systemen deutlich: Sammlung, Aufbereitung und Darstellung von Daten. Ganz im Sinne der Informationspyramide (siehe Abb. 1.2) ist das Primärziel eines BI-Systems, aus Daten Informationen und Wissen zu generieren und dieses zur richtigen Zeit dem richtigen Personenkreis zur Verfügung zu stellen. Nur mit dem anforderungsgerechten Wissen lassen sich richtige Entscheidungen treffen, wobei vom konkreten Einsatzzweck abhängt, welche Informationen relevant sind. Abb. 1.2: Informationspyramide [SM04, Seite 195]

15 Kapitel 1 Entwicklung und Bedeutung von Business-Intelligence-Systemen 15 Vor dem erfolgreichen BI-Einsatz steht deshalb zunächst konzeptionelle und inhaltliche Arbeit, im Zuge derer die konkreten Ziele definiert werden müssen. Da sich die Rahmenbedingungen immer wieder ändern, ist dies keine einmalige Aufgabe. Vielmehr bedarf es kontinuierlicher Kontrolle und Anpassungen. Es ist deshalb angebracht, Business Intelligence als einen hochdynamischen analytischen Prozess [zu betrachten], der Unternehmens- und Wettbewerbsdaten in handlungsgerichtetes Wissen [...] transformiert [HW05, Seite 4]. Aufgrund der Dynamik des Marktumfelds sollte dieser Prozess von stetiger Weiterentwicklung geprägt sein ( think big start small ). Die Zeit zwischen dem Kauf der Software und dem ersten Einsatz hängt auch eng mit der Anzahl der auftretenden Probleme zusammen (vgl. [FMB + 10, Seite 118]). Eine BI-Lösung ermöglicht demnach im Idealfall nicht nur die schnelle und flexible Reaktion auf Veränderungen, sondern verringert damit auch gleichzeitig Probleme. 1.2 Entwicklung von Business-Intelligence-Systemen Die Informationsverarbeitung ist so alt wie die Entwicklung von Computern selbst. Von Anfang an ging es darum, Daten zu verarbeiten und die dabei generierten Informationen zu nutzen. Nichts Anderes machen im Prinzip auch die heutigen BI- Anwendungen, obgleich die Aufgaben sehr viel komplexer und die Datenmengen sehr viel größer geworden sind. Mit der fortschreitenden Entwicklung und zunehmenden Verbreitung von Computern wuchs auch die Datenmenge stetig. Das Moorsche Gesetz lässt sich auch auf die Datenmengen anwenden, die Datenmenge verdoppelt sich [demnach] alle 12 bis 18 Monate [LPS10, Seite 351]. Insbesondere im Management wird es immer schwieriger, aus der Datenflut die gewünschten und benötigten Informationen zu filtern. Mit dem Ziel einer übersichtlichen und adäquaten Informationsversorgung von Managern und Entscheidern entwickelten sich in den 60er-Jahren mit den Management Information Systems (kurz: MIS) die Vorläufer heutiger BI- Systeme. Während die Basisdaten transparent im Hintergrund blieben, bekam der Anwender nur wenige wichtige und aussagekräftige Kennzahlen präsentiert. Mit

16 Kapitel 1 Entwicklung und Bedeutung von Business-Intelligence-Systemen 16 zunehmender Reife wurde dabei auch das Maß der Integration von Daten und das Niveau der Entscheidungsunterstützung permanent verbessert [HW05, Seite 3]. Die Abbildung 1.3 zeigt wie immer neue Funktionen integriert, das Unterstützungsniveau fortlaufend verbessert und auch die Bezeichnung immer wieder geändert wurde. So war in den 70er-Jahren von Decision Support Systems (DSS) die Rede, später von Executive Information Systems (EIS) bevor in den 90er-Jahren der Begriff des Data Warehousing (DWH) aufkam. Data Warehousing ist mittlerweile nicht mehr als eigenständig zu verstehen, sondern als eine Teiltechnologie wenn auch die vielleicht wichtigste innerhalb der Business-Intelligence-Umgebung. Abb. 1.3: Historie von entscheidungsunterstützenden Systemen [HW05, Seite 4] 1.3 Status quo Der weltweite Markt für Business Intelligence ist in den vergangenen Jahren stark gewachsen und auch die Wirtschaftskrise sorgte entgegen dem allgemeinen Trend nicht für Umsatzeinbrüche, sondern sogar für Wachstum (vgl. [imfpi09]). Laut dem US-Marktforschungsunternehmen Gartner Group lag der Umsatz 2009 weltweit bei 9,3 Mrd. US-Dollar nach 8,9 Mrd. im Jahr zuvor (vgl. [Püt10]). Der größte Teil davon entfällt auf die USA, während Deutschland mit einem Volumen von 800 Millionen Euro in 2008 nur einen sehr kleinen Anteil einnimmt (vgl. [Pel10]).

17 Kapitel 1 Entwicklung und Bedeutung von Business-Intelligence-Systemen 17 Mit SAP, Oracle, SAS Institute, IBM und Microsoft sind es nur fünf große Anbieter, die bereits 71 % des weltweiten BI-Marktes unter sich aufteilen (vgl. [Püt10]). Auch in Deutschland können die großen Fünf bereits 61 % des BI-Markts auf sich konzentrieren. Die restlichen Marktanteile gehen an kleinere Anbieter mit branchenspezifischen Lösungen oder speziellen Funktionen und Technologien. So konnte beispielsweise die Firma QlikTech, neben Applix einer der ersten Anbieter der In-Memory-Technologie (siehe Kapitel 2.3) in Deutschland, im Jahre 2008 ein Umsatzwachstum von über 47 % aufweisen (vgl. [Sar10]). Andere Firmen punkten mit der Planungs-Funktion, denn mehr denn je besteht die Notwendigkeit, analysieren und planen zu können, um ein Unternehmen zu steuern [Sar10]. Bei vielen Kunden war in der Vergangenheit sicherlich die Integration in die bestehenden Systemlandschaften ein wichtiges Entscheidungskriterium für große Investitionen in komplexe und umfangreiche BI-Lösungen. Allerdings hat auch hier ein Umdenken hin zu kleineren Projekten und Budgets stattgefunden. Dieser Schwenk in der Investitionspolitik der Unternehmen trifft die großen Anbieter härter, weil sich diese zu lange Zeit auf das Großgeschäft konzentriert [Sar10] haben. Ursprünglich waren Business-Intelligence-Anwendungen zumeist IT-getrieben und dem oberen Management und damit wenigen Anwendern vorbehalten. Zunehmend stehen die Anwendungen nun aber auch Benutzern des mittleren und unteren Managements zur Verfügung, was höhere Anforderungen an die Anwenderfreundlichkeit stellt. Auch hier sind kleinere Anbieter im Vorteil, da sich nur 13 % der Microsoft- und sogar nur 6 % der SAP-Kunden aus Gründen der Anwenderfreundlichkeit für die jeweilige Lösung entschieden haben (vgl. [Sar10]). Neben dem Usability-Trend sind es aber vor allem neue Entwicklungen und technologische Fortschritte, die in Zukunft wichtig sein werden. Die Interessantesten davon sollen im folgenden Abschnitt kurz vorgestellt werden.

18 Kapitel 1 Entwicklung und Bedeutung von Business-Intelligence-Systemen Ausblick Da sich die BI-Branche laufend den sich ändernden Rahmenbedingungen anpassen muss, ist eine Aussage über die Richtung der Entwicklung nur schwer zu treffen. Es gibt aber einige Themen, die von Kundenseite stark nachgefragt und deshalb auch die Anbieter beschäftigen werden. Entwicklungen und Innovationen im hochdynamischen BI-Umfeld lassen sich in drei Bereiche unterteilen: technische/technologische Innovationen fachliche/betriebswirtschaftliche Entwicklungen organisatorische Strukturen Technische Innovationen Um den explodierenden Datenmengen und immer weiter steigenden Performance- Anforderungen gerecht zu werden, bedarf es neuer technischer Entwicklungen. Zunächst einmal wird es eine Verschiebung nach oben in der Speicherhierarchie geben, wie auch Carsten Bange auf dem 10. Europäischen TDWI-Kongress im Juni 2010 zu verstehen gab: Disks are tomorrows tapes. SSD and RAM are tomorrows disks. Neben den schnelleren Zugriffszeiten auf Daten im Arbeitsspeicher sowie auf SSDs, lassen sich durch neue Kompressionsalgorithmen Speicherplatz sparen und damit auch Energiekosten einsparen. Eine weitere Herausforderung betrifft die Möglichkeiten des Zugriffs auf BI-Systeme. Mit der zunehmenden Verbreitung mobiler Endgeräte und der zunehmenden Selbstverständlichkeit des Überall-Internets wachsen auch die Anforderungen hinsichtlich des mobilen Zugriffs. Anwender wollen auch unterwegs auf Unternehmenskennzahlen und Analysen zugreifen. Aufgrund der Einschränkungen der mobilen Endgeräte, wie geringere Leistungsfähigkeit, kleinere Displays sowie die Bedienung ohne Maus, müssen optimierte Mobil-Versionen zur Verfügung gestellt werden. Im Vorteil sind Anbieter, die auch bisher schon den Zugriff über den Browser ermöglicht haben. Darüber hinaus muss vor allem auch die IT-Sicherheit beim Zugriff auf oft geschäftskritische Informationen gewährleistet werden.

19 Kapitel 1 Entwicklung und Bedeutung von Business-Intelligence-Systemen Fachliche und betriebswirtschaftliche Entwicklungen Aufgrund größerer Datenmengen und immer höheren Ansprüchen an die Datenaktualität sind auch die Performance-Anforderungen stark gestiegen. Während früher die nächtliche Befüllung normal und akzeptiert war, sind diese bis zu 24 Stunden alten Daten mittlerweile in vielen Fällen nicht mehr ausreichend. Während Business Intelligence ursprünglich vergangenheitsorientiert und damit reaktiv ausgerichtet ist, wird unter dem Schlagwort Operational BI die direkte und zeitnahe Verbindung der dispositiven und operativen Systemwelten [GKS09] immer wichtiger. Unter Operational BI versteht man die Verknüpfung der vorhandenen und etablierten Business-Intelligence-Technologien mit den Anforderungen des aktuellen Tagesgeschehens in den Unternehmen [GKS09]. Anstatt erst rückwirkend im Reporting Probleme zu erkennen, kann bereits im Verlauf eines Prozesses korrektiv eingegriffen werden. Dadurch besteht das Potential, Unternehmensprozesse massiv zu verbessern [Rog08]. Sowohl bei traditioneller als auch bei operativer Business Intelligence gilt aber gleichermaßen, dass jede Entscheidung nur so gut sein kann wie die zugrundeliegenden Daten. Eine ausreichende Menge an korrekten Daten ist aus diesem Grunde obligatorisch. Leider steht die Datenmenge oft im Widerspruch zur Datenqualität [Sch06, Seite 17], die sich primär auf die Korrektheit sowie die Vollständigkeit der Daten bezieht. Lückenhafte, inkorrekte oder widersprüchliche Daten führen zu falschen Ergebnissen und Erkenntnissen. Die Unternehmen haben das Problem erkannt und versuchen nun zunächst die Qualität ihrer Daten zu quantifizieren. Nur wenn die Qualität messbar ist, lässt sich auch der Erfolg von Qualitätssicherungsmaßnahmen kontrollieren und steuern. Als zweiten Aspekt muss beim Thema der Datenqualität auch die Aktualität der Daten betrachtet werden, schließlich können auch veraltete Daten Fehlentscheidungen zur Folge haben. Da hohe Anforderungen an die Datenaktualität auch höhere Ansprüche an die Performance stellen, stehen Datenqualität und Performance indirekt miteinander in Beziehung. Daten von hoher Qualität sind nicht nur innerhalb der Analyse wichtig, sondern insbesondere bei der Planung muss auf qualitätsgesicherte Informationen zurückgegriffen werden können. Nach der klassischen vergangenheitsorientierten Analy-

20 Kapitel 1 Entwicklung und Bedeutung von Business-Intelligence-Systemen 20 se und dem Einbeziehen aktueller Daten bei operativer Business Intelligence werden für die Unternehmenssteuerung auch Forecasts und die Planung immer wichtiger. Planung und Prognose wichtiger Kennzahlen werden dabei oft auch in Zusammenhang mit den Schlagworten Business Performance Management (BPM) oder Corporate Performance Management (CPM) erwähnt. Da die Planungs- Komponente in vielen BI-Lösungen aktuell noch nicht vorhanden ist, gibt es in diesem Bereich noch viel Potential und Nachholbedarf Organisatorische Strukturen Da Business Intelligence abteilungs- und kompetenzübergreifend ist, etablieren sich in den Unternehmen zunehmend Business Intelligence Competency Center (BICC) interdisziplinäre Teams zur Förderung des effektiven Einsatzes von BI (vgl. [GTS10, Seite 13]), die sich aus Mitarbeitern der verschiedenen involvierten Fachabteilungen sowie der IT zusammensetzen. Je nach Unternehmensgröße handelt es sich dabei um echte Organisationseinheiten oder um virtuelle Organisationen. Die wichtigsten Ziele eines Business Intelligence Competency Centers sind die Formulierung und Kontrolle der unternehmensweiten BI-Strategie. Das BICC zeichnet somit für die Einführung und Weiterentwicklung dieser Strategie verantwortlich. Oftmals gilt es dabei, historisch gewachsene und abteilungsfokussierte BI- Lösungen zu vereinheitlichen und zu konsolidieren, um damit für die aktive und zukunftsorientierte Gestaltung der BI-Systeme [GTS10, Seite 13] zu sorgen. In diese Arbeit finden zunehmend auch agile Methoden Einfluss, um einen schnellen und geregelten Arbeitsablauf zu gewährleisten, wenn es darum geht, auf geänderte Rahmenbedingungen zu reagieren. Agile Entwicklungsmethoden haben schon in der Software-Entwicklung zu erheblichen Verbesserungen hinsichtlich Projektmanagement, Change-Management und auch bezüglich der Produktqualität geführt.

21 Kapitel 2 OLAP und Einordnung in die BI-Referenzarchitektur Nachdem erläutert wurde was generell unter Business Intelligence zu verstehen ist, geht es nun um einen Begriff, der untrennbar mit Business Intelligence verbunden ist: OLAP. Zunächst soll die Abkürzung erläutert werden, bevor es um die Aufgaben und die Bedeutung von OLAP innerhalb von BI-Systemen geht. 2.1 Begrisdenition OLAP OLAP ist die Abkürzung für On-Line Analytical Processing und wurde 1993 vom Datenbanktheoretiker Edgar F. Codd (d 2003) geprägt. Da der Begriff alleine nichts darüber aussagt, warum man OLAP-Tools einsetzen sollte und was ein OLAP-Tool überhaupt leistet, definierte Codd zwölf (später folgte die Erweiterung auf 18) Regeln, denen ein Datenbanksystem entsprechen muss, um als OLAP-System zu gelten. Aufgrund ihrer Vielzahl erschienen die Coddschen Regeln schon bald als ungeeignet für die Definition von OLAP-Systemen und wurden von Nigel Pendse und Richard Creed im OLAP Report 1995 in der FASMI-Definition konsolidiert (vgl. [Pen08]). Die Übereinstimmung mit diesem Anforderungskatalog stellt sicher, dass Nutzern mit OLAP-Systemen ein schneller (Fast) analytischer (Analysis) Zugriff im Mehrbenutzerbetrieb (Shared) auf kontextrelevante multidimensionale betriebliche Informationen (Multidimensional Information) [Man08b] möglich ist. Fast Die Geschwindigkeit findet sich bereits in dieser Definition als eine der wichtigsten Anforderungen an ein OLAP-System wieder. Einfache Abfragen dürfen maximal fünf Sekunden dauern, komplexen Abfragen werden maximal 20 Sekunden zugestanden. 21

22 Kapitel 2 OLAP und Einordnung in die BI-Referenzarchitektur 22 Analysis Dem Anwender muss es auf einfache und intuitive Weise möglich sein, ohne Programmieraufwand komplexe Anfragen an das System zu stellen. Shared Das System erlaubt den parallelen Zugriff mehrerer Benutzer, ohne dass es zu Konflikten oder Seiteneffekten kommt. Multidimensional Die Daten werden multidimensional gespeichert, sodass sich jeder Wert genau einem Basiselement einer Dimension zuordnen lässt. Innerhalb der Dimensionen können die Basiselemente zu aggregierten Elementen zusammengefasst werden. Information OLAP-Datenbanken können unabhängig des Datenvolumens sowie der Dimensionalität aus Daten Informationen generieren. Die Datenherkunft bleibt für den Nutzer dabei transparent. OLAP ist damit ein Überbegriff für ein Konglomerat aus Software- und Hardware-Komponenten zur Durchführung komplexer Analysen. OLAP ist auch ein Synonym für die abfrageoptimierte Verarbeitung für multidimensionale Datenstrukturen [Sch06, Seite 23]. Um die Daten aus unterschiedlichen Perspektiven betrachten zu können, werden diese aus den Datenquellen in einem multidimensionalen Datenwürfel zusammengefasst und dann in Berichten mit Tabellen und Grafiken präsentiert [Man08a]. (a) 3 Dimensionen (b) n-dimensionaler Hyperwürfel Abb. 2.1: n-dimensionaler Hyperwürfel (Quelle: via [Man08c]) Jede Dimension des Würfels (engl. Cube) kann man sich dabei räumlich als eine Achse vorstellen, was aber die menschliche Vorstellungskraft ab der vierten Di-

23 Kapitel 2 OLAP und Einordnung in die BI-Referenzarchitektur 23 mension übersteigt. Damit sind Konstellationen bis hin zum n-dimensionalen Hyperwürfel (siehe Abbildung 2.1) möglich, wobei die Dimensionalität theoretisch unendlich groß sein kann Varianten von OLAP Da sich OLAP anhand der fünf Kriterien der FASMI-Definition definiert, gibt es technisch gesehen einen hohen Freiheitsgrad. Insbesondere die Art der Speicherung und des Zugriffs sind nicht festgelegt und unterscheiden sich zwischen den Systemen teilweise grundlegend. In der Praxis haben sich unterschiedliche Konzepte entwickelt, von denen die nachfolgenden heute von Bedeutung sind. ROLAP Für Relational OLAP werden relationale Datenbanken eingesetzt, die speziell für den Einsatz in Data-Warehouse-Umgebungen optimiert wurden. Aufgrund ihrer langen Existenz bieten relationale Datenbanken eine sehr hohe Stabilität und sind in hohem Maße skalierbar. Kennzahlen werden in ROLAP-System zur Laufzeit berechnet. Eine hohe Normalisierung der Daten wirkt sich allerdings nachteilig auf die Performance aus, da für bei Abfragen viele Verbundoperationen nötig sind. MOLAP Beim Multidimensional OLAP werden die Daten in multidimensionalen Datenstrukturen gespeichert. Aggregierte Kennzahlen können bereits bei der Erstellung des Datenwürfels berechnet und persistent gespeichert werden, um den späteren Zugriff zu beschleunigen. Dies würde aber auch den Speicherbedarf gegenüber relationalem OLAP erhöhen. Insbesondere bei Einsatz der In-Memory-Technologie verzichten die Anbieter aber oft darauf und berechnen alle Kennzahlen ausschließlich bei Bedarf. In jedem Fall aber handelt es sich um proprietäre Lösung von Spezial-Anbietern, die für den Einsatz von MOLAP nötig und deshalb in der Regel auch mit höheren Investitionen verbunden sind.

24 Kapitel 2 OLAP und Einordnung in die BI-Referenzarchitektur 24 HOLAP Hybrid OLAP stellt das Konglomerat aus ROLAP und MOLAP dar und versucht die Vorteile von ROLAP und MOLAP zu verbinden. Um allerdings die optimale und stabile Kombination beider Konzepte zu erreichen, benötigt es eine komplexe und damit auch fehleranfällige Architektur. Weitere Varianten mit geringer Bedeutung Darüber hinaus gibt es noch weitere Kategorisierungsmöglichkeiten für OLAP- Systeme. Diese dürfen nicht für sich alleine betrachtet werden, sondern treten oft in Kombination mit den bereits vorgestellten OLAP-Varianten auf oder stellen einen Spezialfall Letzterer dar. Desktop OLAP (DOLAP) DOLAP ist eine Abwandlung von MOLAP. Auch hier werden die Daten multidimensional abgelegt, allerdings nicht auf einem Server, sondern direkt auf dem Endgerät. DOLAP hat mit denselben Nachteilen wie MOLAP zu kämpfen, wobei sich der Performance-Flaschenhals aufgrund der im Normalfall schwächeren Hardware-Ausstattung des Endgeräts noch verschärfen kann. Allerdings lässt sich bei DOLAP auch dann noch arbeiten, wenn die Internetverbindung einmal nicht vorhanden sein sollte. Web-Based OLAP (WOLAP) Gemeint ist hierbei die Verlagerung der Analyse- Oberfläche ins Internet. Der Zugriff erfolgt ausschließlich per Webbrowser, was impliziert, dass auf dem Endgerät weder spezielle Software installiert sein muss noch Berechnungen durchgeführt werden. Real-Time OLAP (RTOLAP) RTOLAP beschreibt die Echtzeitanforderung an BI- Anwendungen. Die Informationen aus den Vorsystemen sollen nicht nur in verhältnismäßig langen Zyklen aktualisiert, sondern quasi sofort berücksichtigt werden. Damit ist Real-Time OLAP auch eng verbunden mit Operational BI. Die In-Memory-Technolgie, die im Fokus dieser Arbeit steht und in Kapitel 2.3 noch im Detail vorgestellt wird, kann hierfür einen wichtigen Beitrag leisten. Durch die Datenhaltung im Arbeitsspeicher und die daraus resultierenden schnellen Zugriffe sowie die Aggregationen in Echtzeit, lassen sich die hohen Performance-Anforderungen erfüllen.

25 Kapitel 2 OLAP und Einordnung in die BI-Referenzarchitektur Typische Operationen Die Datenwürfel lassen sich mit Hilfe spezieller Reporting-Programme auswerten und analysieren. Bei dieser Analyse egal ob Standard-Reports oder AdHoc- Reporting kommen einige OLAP-typische Operationen zum Einsatz. Dicing Beim Dicing bleibt die Dimensionalität des Datenwürfels erhalten, es wird aber innerhalb einzelner Dimensionen die Wertemenge eingeschränkt. Das Ergebnis ist ein Teilwürfel mit weniger Daten, auf dem aber weiterhin alle Abfragen möglich sind, die auf dem ursprünglichen Datenwürfel ausgeführt werden konnten. Slicing Das Slicing ist eine eigenständige OLAP-Operation, lässt sich aber auch als Spezialfall des Dicing betrachten. Beim Slicing wird eine Scheibe aus dem Datenwürfel ausgeschnitten, was sich auch als Dicing interpretieren lässt, bei dem in einer Dimension die Menge der Elemente auf genau ein Element beschränkt wird. Klassischer Anwendungsfall sind Produktmanager, die nur die Verkaufszahlen der Produkte sehen dürfen, für die sie zuständig sind. Ebenso dürfte ein Bezirks-Verkaufsleiter nur die Umsatzzahlen seines Bezirks analysieren. Abb. 2.2: Slicing und Dicing in einem multidimensionalen Datenwürfel (Quelle: Lehrstuhl für Wirtschaftsinformatik, Universität Bamberg via [Man08b] )

26 Kapitel 2 OLAP und Einordnung in die BI-Referenzarchitektur 26 Drill-Down und Roll-Up Wie bereits gesehen, geht es in Business-Intelligence-Systemen primär darum, anhand weniger Kennzahlen Entscheidungen zu treffen. Diese Kennzahlen auf oberster Ebene ergeben sich aus zahlreichen Kennzahlen niedrigerer Konsolidierungsstufen. Mit dem Drill-Down wird eine aggregierte Kennzahl in ihre Bestandteile zerlegt, womit man eine Konsolidierungsstufe tiefer steigt. Abb. 2.3: Drill-Down und Roll-Up - Aggregation und Aufschlüsselung der Daten (Quelle: Lehrstuhl für Wirtschaftsinformatik, Universität Bamberg via [Man08b] ) Die umgekehrte Richtung beschreibt Roll-Up. Hier geht es darum zu sehen, welchen Einfluss eine Kennzahl auf die nächsthöhere Kennzahl hat. Durch stetiges Roll-Up lässt sich damit der Einfluss vom untersten Beleg bis hin zu Kennzahlen auf oberster Stufe verfolgen. Pivotierung Unter Pivotierung versteht man das Rotieren eines Datenwürfels um die eigene Achse. Bei gleichen Daten erhält der Anwender damit eine neue Sicht auf die Daten. Bekannt ist dieses Verhalten auch von den sogenannten Pivot-Tabellen in Tabellenkalkulationen wie Microsoft Excel.

27 Kapitel 2 OLAP und Einordnung in die BI-Referenzarchitektur 27 Abb. 2.4: Neue Sicht auf die Daten durch Pivotierung (Quelle: Lehrstuhl für Wirtschaftsinformatik, Universität Bamberg via [Man08b] ) OLAP Join Der OLAP Join verbindet unterschiedliche Datenwürfel mit gleichen Dimensionen. Damit lassen sich aus den Kennzahlen der einzelnen Datenwürfel neue Kennzahlen berechnen, ohne dass sich die Struktur des Datenwürfels ändert. Abb. 2.5: Ein OLAP-Join verbindet Datenwürfel mit gleichen Dimensionen (Quelle: Lehrstuhl für Wirtschaftsinformatik, Universität Bamberg via [Man08b] ) Abgrenzung zu OLTP Klar abzugrenzen sind OLAP-Systeme von OLTP-Systemen (On-Line Transaction Processing), die im Bereich der relationalen Datenbanken zum Einsatz kommen. OLTP ist eine zu OLAP komplementäre Technologie, welche vor allem in den operativen Systemen zum Einsatz kommt und dort versucht eine möglichst exakte Repräsentation der betreffenden Miniwelt [Lau08] abzubilden. Typischerweise

28 Kapitel 2 OLAP und Einordnung in die BI-Referenzarchitektur 28 kommen dabei im Produktivbetrieb kurze und verhältnismäßig einfache Transaktionen zum Einsatz, die nur eine kleine Teilmenge der Daten betreffen. OLAP ist im Gegensatz dazu analysegetrieben, operiert auf multidimensionalen Datenwürfeln und benötigt aus diesem Grunde weitaus komplexere Operationen. Datenmanipulationen sind ursprünglich nicht vorgesehen, stattdessen werden die Daten historisiert und nicht-flüchtig gespeichert. Anfragen Fokus Transaktionsdauer und -typ OLTP (transaktional) Lesen, Schreiben, Modifizieren, Löschen kurze Lese-/ Schreibtransaktionen Anfragestruktur einfach strukturiert komplex Datenvolumen einer Abfrage Datenmodell wenige Datensätze anfrageflexibles Datenmodell OLAP (analytisch) Lesen, periodisches Hinzufügen lange Lesetransaktionen viele Datensätze analysebezogenes Datenmodell Daten Datenquellen meist eine mehrere Eigenschaften nicht abgeleitet, zeitaktuell, autonom, dynamisch abgeleitet, konsolidiert, historisiert, integriert, stabil Datenvolumen Megabyte - Gigabyte Gigabyte - Terabyte Zugriffe Einzeltupelzugriff Bereichsanfragen Anwender Anwendertyp Ein-/Ausgabe durch Sachbearbeiter Antwortzeit ms - s s - min Auswertungen durch Manager, Controller, Analysten Tabelle 2.1: Unterschiede zwischen OLTP und OLAP [BG09, Seite 10f]

29 Kapitel 2 OLAP und Einordnung in die BI-Referenzarchitektur Einordung von OLAP in die BI-Referenzarchitektur Wie soeben gezeigt wurde, kommt dem On-Line Analytical Processing in einem Business-Intelligence-System unabhängig von dessen expliziter Architektur eine ganz spezielle Aufgabe zu, es ist in gewisser Weise die BI-Rechenmaschine [Sch06, Seite 23] und obligatorischer Bestandteil eines jeden Systems. Da es bereits unterschiedliche Definitionen eines BI-Systems gibt (siehe Kapitel 1.1), ist ebenso umstritten, welche Architektur-Komponenten für dieses obligatorisch sind. In der Fachliteratur gibt es zahlreiche Versuche, die Architektur auf einen gemeinsamen Nenner zu bringen, wie beispielsweise jene nach Bauer und Günzel Die BI-Referenzarchitektur nach Bauer und Günzel Mit ihrem erstmalig im Jahre 2000 erschienenen Buch Data Warehouse Systeme Architektur, Entwicklung, Anwendung schufen Holger Günzel und Andreas Bauer ein Standardwerk, wenn es um die Architektur von BI- und Data-Warehouse- Systemen geht. Zu einer Zeit, in der sich die BI-Systeme, wie wir sie heute kennen, erst noch entwickelten, entwarfen sie eine Referenzarchitektur (vgl. [BG09, Seite 38]). Diese teilt das BI-System in einen Datenbeschaffungs- und einen Auswertebereich. Daneben existieren noch assistive Komponenten, die den Ablauf koordinieren. Das Referenzmodell ist eine idealtypische Darstellung, von der BI-Systeme in der Praxis mehr oder minder stark abweichen. Im Produktivsystem können deshalb einzelne Komponenten fehlen, ohne dass das System seinen Typus als Data- Warehouse-System verliert. Datenbeschaungsbereich Als Synonym für die Datenbeschaffung hat sich die Abkürzung ETL (Extract, Transform, Load) etabliert. Gemeint ist damit die Überführung von Daten aus heterogenen (und meistens externen) Datenquellen in das Data Warehouse. Im Zuge dessen werden die Daten bereinigt, vereinheitlicht, mit anderen Daten angereichert und teilweise auch schon aggregiert, bevor sie in einer Basis-Datenbank 1 oder direkt im 1 Alternativ wird auch der Begriff Staging-Datenbank verwendet.

30 Kapitel 2 OLAP und Einordnung in die BI-Referenzarchitektur 30 Abb. 2.6: Referenzmodell für die Architektur von Data-Warehouse-Systemen (Quelle: [BG09, Seite 38]) Data Warehouse abgelegt werden. Dieser zentrale Datenspeicher ist Single Point of Truth und Basis für alle Auswertungen. Es leuchtet deshalb ein, dass der Datenqualität (siehe auch Kapitel 1.4.2) eine besondere Bedeutung zukommt und diese spätestens im Rahmen des ETL-Prozesses sichergestellt werden muss. Auswertebreich Auf den zentral gespeicherten Daten können schließlich die OLAP-Analysen durchgeführt werden. Aus den Daten im Data Warehouse werden multidimensionale Datenwürfel generiert, auf denen letztendlich die Abfragen ausgeführt werden. Die Referenzarchitektur zeigt ebenso, dass auch der Paradigmenwechsel hin zur

31 Kapitel 2 OLAP und Einordnung in die BI-Referenzarchitektur 31 In-Memory-Technologie (dazu gleich mehr) das Modell nicht zum Kippen bringt, weil dieses logischer Natur ist. Die Abbildung 2.6 zeigt die Einordnung der Analyse innerhalb des BI-Systems unabhängig von der technischen Realisierung. Assistive Komponenten Zum Betrieb und zur Steuerung des Data-Warehouse-Systems werden noch weitere Komponenten benötigt. Als zentrale Komponente zeichnet der Data-Warehouse- Manager für die Initialisierung und Steuerung des Systems verantwortlich und überwacht die Prozesse von der Extraktion über die Transformation und das Laden bis hin zur Analyse. Die zur Durchführung dieser Aufgaben nötigen Informationen werden vom Metadaten-Manager bereitgestellt, ein Monitor ist für die Überwachung der Datenquellen verantwortlich. 2.3 In-Memory-Technologie Die letzte Revolution (vgl. [Com06]) bei OLAP-Systemen war die Ablösung von traditionellen Datenbanksystemen durch effiziente In-Memory-Technologien (vgl. [BHvdD09]). Ursprünglich wurden die Daten ausschließlich auf der Festplatte gespeichert und auch bei Abfragen von dort gelesen. Mit dem Einsatz der In- Memory-Technolgie werden die Datenwürfel nun entweder direkt im Arbeitsspeicher erstellt oder beim Programmstart aus einem zentralen Data Warehouse von der Festplatte komplett in den Hauptspeicher geladen. Durch die Datenhaltung im Arbeitsspeicher beschleunigen sich die Abfragen und typische OLAP-Operationen wie Slicing und Dicing erheblich. Der Zugriff auf Daten im Hauptspeicher ist gegenüber einer Festplatte durchschnittlich um den Faktor (vgl. [Wik10]) schneller. Dadurch, dass die (komplexen) Analysen näher an die Daten rücken, sinken auch die Anforderungen hinsichtlich der Serverund Netzwerk-Infrastruktur (vgl. [She10]). Die Datenanalyse im Arbeitsspeicher sorgt für eine deutliche Reduktion der Lesezugriffe auf den Festplatten. Komplexe Analysen sollen damit erschwinglicher, skalierbarer und schneller werden (vgl. [She10]). Da keine vorberechneten Kennzahlen existieren, ist auch der benötigte Speicherplatz geringer, die für das Netzwerk merklich geringere Belastung sorgt

32 Kapitel 2 OLAP und Einordnung in die BI-Referenzarchitektur 32 für geringere Anfangsinvestitionen in die Infrastruktur und die frühere Erreichung des Return on Investment (ROI) (vgl. [Fel09]). Nachdem die Technologie zunächst von kleinen Anbietern wie QlikTech 2 oder auch Jedox genutzt wurde, haben in der Zwischenzeit auch die großen Anbieter wie SAP oder Cognos erkannt, dass es keine andere Alternative gibt, um den heutigen und zukünftigen Herausforderungen, wie steigenden Datenmengen und immer höheren Performance-Anforderungen, zu genügen. Überhaupt ist die Performance eines der größten Hindernisse eines umfassenderen BI-Einsatzes (vgl. [Jai10]), dem mit In-Memory OLAP-Systemen begegnet werden kann. Die In-Memory-Technologie war auch schon vor ihrem Einsatz im BI-Umfeld bekannt. Allerdings gab es lange Zeit technische und finanzielle Hindernisse, die den Produktiveinsatz in größeren Umgebungen verhinderten. Erst der anhaltende Preisverfall für Speicherplatz und Arbeitsspeicher (vgl. [Blo10]) sowie die zunehmende Verfügbarkeit von 64-Bit-Systemen, die mehr Arbeitsspeicher adressierbar machen 3, haben dieser neuerlichen Nutzung geführt. Da die zu analysierenden Daten komplett im Hauptspeicher liegen, stellt dessen Größe hardwareseitig die Grenze der maximal möglichen Datenmenge dar. Diese Grenze lässt sich aber nicht genau quantifizieren, da der Arbeitsspeicher einerseits immer auch von anderen Prozessen mitbenutzt wird und andererseits jedes Betriebssystem nach eigenen Algorithmen irgendwann beginnt, Daten aus dem Arbeitsspeicher auf die Festplatte auszulagern. Um die Vorteile der In-Memory- Technolgie ohne Einschränkung nutzen zu können, ist ein ausreichend großer und auf die zu erwartende Datenmenge abgestimmter Arbeitsspeicher obligatorisch In 32-Bit-Systemen können maximal 4 GB Arbeitsspeicher adressiert werden. Bei 64-Bit liegt die theoretische Grenze der Adressierbarkeit bei 16 Exabyte (Exa = = Trillionen).

33 Kapitel 3 Vergleichbarkeit von OLAP-Systemen Die Performance ist ein oft erwähntes Problem beim Betrieb von OLAP-Systemen, wie auch Nigel Pendse in einem Interview im Januar 2010 auf die Frage nach den erfolgskritischen Faktoren in Business-Intelligence- und OLAP-Projekten feststellte (siehe [Rit10]). Allerdings ist es für Firmen im Vorfeld einer Investitionsentscheidung sehr schwer, die Performance unterschiedlicher Systeme zu bestimmen und die Alternativen dadurch miteinander vergleichbar zu machen. Um Systeme direkt miteinander vergleichen zu können, müssten Vergleichzahlen unter identischen Rahmenbedingungen zustande gekommen sein. Innerhalb eines Benchmarks 4 müssten alle Unterschiede bezüglich der Hardware sowie der Datenmenge eliminiert werden. Für den Empfänger der Ergebnisse müsste zudem nachvollziehbar sein, wie die Zeit gemessen wurde und wie sich der Benchmark zur Verifikation reproduzieren lässt. Ein derartiger Versuch für OLAP-Systeme wurde Ende der 90er Jahre mit dem Analytic Processing Benchmark (kurz: APB-1) unternommen. Allerdings war dieser schon bei seiner Veröffentlichung umstritten (vgl. [com96]) und ist heute quasi bedeutungslos, ohne dass es Alternativen gibt. Das letzte Release erfolgte im November 1998, weitere unter [Cou98a] angekündigte Benchmarks 5 wurden nie veröffentlicht. 4 Der Begriff Benchmark (engl. für Maßstab ) kommt aus der Vermessungstechnik und bezeichnet dort einen fixen Punkt, an dem sich andere Punkte orientieren. In der Informatik und der Betriebswirtschaftslehre hat sich der Begriff als Synonym für die Möglichkeit etabliert, Produkte und Dienstleistung oder auch Technologien und Prozesse miteinander zu vergleichen. 5 Die Zahl 1 in der Abkürzung APB-1 sollte ursprünglich dafür stehen, dass es sich um den ersten von mehreren Benchmarks handelt. 33

34 Kapitel 3 Vergleichbarkeit von OLAP-Systemen 34 Mit dem Transaction Processing Performance Council Benchmark (kurz: TPC) exitiert ein zweiter Benchmark, der ursprünglich für den Vergleich von OLTP-Systemen entwickelt wurde. Aufgrund der gravierenden Unterschiede zwischen OLAP und OLTP (siehe Kapitel 2.1.3) würde er sich bereits damit für die detaillierte Betrachtung disqualifizieren. Allerdings besteht der Benchmark aus mehreren Teilen, von denen sich der TCP-H speziell an Decision-Support-Systeme (DSS) richtet, also an die Vorgänger der heutigen Business-Intelligence-Systeme. Im Kern führten Decision-Support-Systeme bereits jene Auswertungen durch, für welche heute OLAP-Systemehauptsächlich eingesetzt werden und bei denen die Performance ein immer wichtigerer bis hin zum geschäftskritischen Faktor ist. Die Vorstellung des TCP-H erfolgt aus diesem Grunde im Kapitel Analytic Processing Benchmark Der letztmalig im November 1998 aktualisierte Analytic Processsing Benchmark wurde vom amerikanischen OLAP Council 6 gefördert und hatte das Ziel, die Gesamt-Performance eines OLAP-Systems zu bestimmen. Die Teilaufgaben werden dabei im Hinblick auf ihre Performance nicht separat bewertet, sondern zu einer Gesamtzeit aufsummiert (vgl. [Cou98b]). Um im Rahmen des Benchmarks eine allgemeine Aussage über die Performance eines OLAP-Systems treffen zu können, wurden im APB-1 die folgenden typischen Anwendungsfälle identifiziert: umfangreiche Daten aus externen und internen Datenquellen laden inkrementelles Laden von Daten aus operativen Systemen Aggregationen innerhalb einzelner Dimensionen Berechnung neuer Kennzahlen Zeitreihenanalysen AdHoc-Abfragen sowie Abfragen mit einem hohen Komplexitätsgrad Drill-Down innerhalb von Dimensionen 6 Das OLAP Council wurde 1995 gegründet und stand allen Unternehmen offen, die OLAP- Anwendungen entwickelten oder sich in anderer Weise damit auseinandersetzten. Voraussetzung für die Mitgliedschaft war die Zustimmung zu den Grundsätzen des OLAP Council, die OLAP als essentiell und geschäftskritisch für IT-Anwendungen ansahen und insbesondere die Performance sowie die Datenkonsistenz in den Fokus rückten. Zuletzt gehörten dem OLAP Council die Firmen Apllix/TM1, Business Objects, IBM, Hyperion, Management Science Associates, NCR, Oracle, Platinum Technology und Sun Microsystems an (vgl. [Cou97]).

35 Kapitel 3 Vergleichbarkeit von OLAP-Systemen Testumfang und -ablauf Der vollständige Prozess zur Bestimmung der Gesamtperformance des OLAP-Systems besteht aus sechs Teilen, die in folgender Reihenfolge durchlaufen werden: 1. Generierung der Daten für das initiale Befüllen 2. Initialisierung der OLAP-Datenbank, Laden der historischen Daten und optional Durchführung von Vorberechnungen (wenn von der OLAP-Datenbank unterstützt) 3. Generierung der Daten für das inkrementelle Update 4. Inkrementelles Update und optional Durchführung von Vorberechnungen 5. Generierung der Abfragen 6. Ausführung der Abfragen Datengenerierung Die Datengenerierung erfolgt mit einem frei zugänglichen Generator 7. Dadurch ist es nicht nötig, zur Reproduktion große Datenmengen zu übertragen. Die Bandbreite war insbesondere zu Zeiten der Veröffentlichung des Benchmarks noch eine sehr knappe Ressource und sollte auch heute nicht unnötig verschwendet werden. Der Datengenerator enthält ausschließlich Berechnungsvorschriften und generiert Daten, die immer statistisch gleichen Mustern entsprechen und damit auch jeweils zum gleichen Benchmark-Ergebnis führen. Die Daten liegen zunächst in Flat Files vor und müssen auf dem Zielsystem zunächst in die benötigte multidimensionale OLAP-Datenbank geladen werden. Der Generator arbeitet dreistufig. Zunächst werden die Daten für das initiale Befüllen des OLAP-Cubes generiert. Der zweite und dritte Aufruf liefert die Daten für das inkrementelle Update beziehungsweise die Abfragen. Das Programm steht nur als EXE-Datei für die Ausführung unter Windows zur Verfügung, eine Portierung auf andere Betriebssysteme gibt es nicht. 7 Download unter

36 Kapitel 3 Vergleichbarkeit von OLAP-Systemen 36 Abb. 3.1: Struktur und Zusammenhänge zwischen den vom APB-1 generierten Dateien Datenstruktur Die generierten Daten zeigen ein fiktives Szenario zur Analyse von Verkaufsdaten. Die logische Datenstruktur besteht aus sechs Dimensionen, in drei davon existieren Hierarchien: Customer (Aggregationen: Store Retailer Top) Product (Code Class Group Family Line Division Top) Channel (Base Top) Time Scenario Measures Die Dimension Measures enthält insgesamt zehn Kennzahlen. Neben den fünf absoluten Kennzahlen Units Sold (verkaufte Einheiten), Dollar Sales (Umsatz), Inventory (Bestand), Product Costs (Einzelkosten) und Shipping Cost (Vertriebskosten) werden fünf weitere Kennzahlen berechnet: Average Price (durchschnittl. Verkaufspreis) = Umsatz verkaufte Einheiten Costs (Kosten) = verkaufte Einheiten (Einzelkosten + Vertriebskosten)

37 Kapitel 3 Vergleichbarkeit von OLAP-Systemen 37 Margin (Gewinn) = Umsatz Kosten Margin Percent (Rendite) = Gewinn Umsatz Smoothes Sales (6-Monats-Durchschnitt der Einnahmen) Die Daten lassen sich nach dem Snowflake-Schema, wie in Abbildung 3.2 zu sehen, darstellen. Die Dimension Measures wird dabei zur Faktentabelle, mit der die anderen fünf Dimensionen verknüpft sind. Abb. 3.2: Das Datenmodell des APB-1 als Snowflake-Schema OLAP-Abfragen Der letzte und wichtigste Schritt des APB-1 ist die Ausführung der Abfragen. Es gibt insgesamt zehn verschiedene Abfragetypen, die mit unterschiedlicher Gewichtung in den APB-1 Benchmark eingehen: Channel Sales Analysis (Gewichtung: 10%) Customer Margin Analysis (10%) Product Inventory Analysis (15%) Time Series Analysis (3%)

38 Kapitel 3 Vergleichbarkeit von OLAP-Systemen 38 Customer Budget (5%) Product Budget (5%) Forecast Analysis (15%) Budget Performance (20%) Forecast Performance (15%) Ad Hoc (2%) Veröentlichung der Testergebnisse Aufgrund der vielen Variablen bei der Durchführung des APB-1-Benchmarks, fordert das OLAP-Council bei der Veröffentlichung von Ergebnissen die vollständige Offenlegung der folgenden Informationen: Audit-Report Datenbankschema benötigter Code zum Laden der Daten sowie für Vorberechnungen Anzahl der Nutzer Größe jedes einzelnen Benchmark-Datenfiles Datenbankgröße Datenbank-Serversoftware und -Tuning-Parameter Betriebssystem und Hardwareausstattung (CPU, Speicher) Das Ergebnis des APB-1 wird als Performance-Metrik AQM (Analytical Queries per Minute) angegeben, in die neben den Zeiten der einzelnen Teilaufgaben auch die Anzahl der verarbeiteten Abfragen einfließt. Das OLAP-System ist demnach umso besser, je größer das Ergebnis ist. Gesamtzeit für das inkrementelle Laden der Daten + Gesamtzeit für Vorberechnungen (wenn benötigt) + Gesamtzeit für die Ausführung aller Abfragen = Gesamtzeit für die AQM-Messung AQM = Anzahl ausgeführter Abfragen 60 Gesamtzeit für die AQM-Messung

39 Kapitel 3 Vergleichbarkeit von OLAP-Systemen Bewertung Obwohl es ursprünglich ein guter Ansatz war, ist der APB-1 heute praktisch bedeutungslos. Trotz seines Potentials zu einem Hersteller-übergreifenden Standard zu werden, ist der Benchmark an zahlreichen Problemen und nicht zuletzt an den Herstellern selber gescheitert. Bereits die Entwicklung zielte darauf ab, Produkte von allen Herstellern auszuschließen, die nicht Mitglied im OLAP Council waren (vgl. [FMB + 10, Seite 162]). Kritik gab es auch am Datenmodell, das nicht repräsentativ [war] und keine komplizierten Abfragen [FMB + 10, Seite 162]) enthielt. Da die Entstehung des Datenmodells undokumentiert ist, liegt die Vermutung nahe, dass es mehr oder minder frei erfunden ist und/oder dabei bereits Eigenheiten der Programme von Mitgliedern des OLAP-Councils berücksichtigt wurden. Die Performance-Kennzahl AQM ist nur bedingt sinnvoll, da lediglich einfache Abfragen für den Benchmark definiert wurden. In der Praxis kommen aber auch deutlich komplexere Abfragen vor, weshalb eine Aussage über die durchschnittliche Abfragezeit größere Aussagekraft besitzen würde. Die Anzahl Anfragen pro Minute ist lediglich in Mehrbenutzer-Systemen von Relevanz, da viele parallele Benutzer die Performance spürbar beeinträchtigen können. Darüber hinaus werden unterschiedliche Teildisziplinen zu letztlich einer einzigen Kennzahl zusammengefasst, wobei zwar die Zeiten für inkrementelle Ladevorgänge mit eingehen, die Zeit für das initiale Befüllen des OLAP-Cubes aber unberücksichtigt bleibt. Besser wäre es, die Teildisziplinen einzeln zu bewerten, um dem Anwender die Möglichkeit der Gewichtung nach seinen individuellen Ansprüchen zu ermöglichen. Schließlich ist die Performance des inkrementellen Ladens irrelevant, wenn das Data Warehouse immer komplett neu befüllt würde. Auch der Datengenerator für die einfache und komfortable Generierung der Daten war ein guter Gedanke, der aber letztlich unbefriedigend umgesetzt wurde. Da der Generator ausschließlich für Windows-Betriebssysteme nativ zur Verfügung steht, ist die plattformunabhängige Datengenerierung nicht möglich. Vielfach werden aber Linux-Derivate als Server-Betriebssystem eingesetzt, auf denen sich die Daten nicht direkt erzeugen lassen und von extern eingespielt werden müssen.

40 Kapitel 3 Vergleichbarkeit von OLAP-Systemen 40 Hinzu kommt die lange Liste an Informationen, die bei der Veröffentlichung eines Testergebnisses angegeben werden muss. Die hohe Anzahl der Variationsmöglichkeiten macht den direkten Vergleich zweier Systeme nahezu unmöglich. So waren bereits mehrere Durchläufe eines Anbieters nicht vergleichbar, da zwischen den Ausführungen zu viele Veränderungen vorgenommen wurden. Die einzige Veröffentlichung von Oracle hatte demnach reine Marketing-Gründe. Die genannten Kritikpunkte haben letztlich dazu geführt, dass der APB-1 nie an Bedeutung gewinnen konnte, dem Endbenutzer keinen Nutzen brachte und neben weiteren Veröffentlichungen auch die weiteren geplanten Benchmarks niemals erschienen sind. 3.2 Transaction Processing Performance Council Benchmark H Auch hinter diesem Benchmark steht mit dem Transaction Processing Performance Council 8 (kurz: TPC) eine Organisation, der sich einige namhafte Unternehmen der IT-Branche angeschlossen haben, darunter Branchengrößen wie Dell, IBM, Microsoft sowie die Prozessoren-Hersteller AMD und Intel. Das Konsortium wurde 1988 als Zusammenschluss von zunächst acht Firmen gegründet, die zwei Ziele hatten: 1. Veröffentlichung guter Benchmarks 2. Einführung eines guten Prozesses, um diese zu rekapitulieren und zu überwachen In der Folge wurden mehrere Benchmarks veröffentlicht, die leicht unterschiedliche Teilbereiche adressierten und die Probleme der Anwender verdeutlichten. Jeder Benchmark war auf diese Weise zugleich Indikator und Ansporn für die Weiterentwicklung durch die Anbieter. Von den im Laufe der Zeit entstandenen Benchmarks sind heute noch der TPC-C 9, der TPC-E 10 sowie der TPC-H relevant. 8 siehe 9 allgemeiner Leistungsvergleich von Datenbank-Servern unterschiedlicher Bauweisen 10 Simulation der Belastung eines OLTP-Systems am Beispiel eines Broker-Systems mit vielen simultanen Lese- und Schreib-Zugriffen

41 Kapitel 3 Vergleichbarkeit von OLAP-Systemen 41 Ziel des im Jahre 1999 veröffentlichten TPC-H-Benchmarks ist die Vergleichbarkeit entscheidungsunterstützender Systeme auf Basis von OLTP-Systemen. Trotz der grundsätzlichen Unterschiede zwischen OLAP und OLTP (siehe Kapitel 2.1.3) geht es bei diesem Benchmark um exakt jene Analysen, die heute mit Hilfe von Business-Intelligence-Systemen durchgeführt werden. Während die Daten heute in OLAP-Datenbanken multidimensional für die Analysen vorgehalten werden, waren sie damals noch in klassischen relationalen Datenbank-Management-Systemen (RDMS) gespeichert. Die im TCP-H dargestellten Anwendungsfälle Geschäftsprozesse und Datenmodelle eines Handelsunternehmens haben sich bis heute nicht grundlegend verändert, allerdings werden hierfür mittlerweile zumeist OLAP-Systeme eingesetzt. Anders als der Analytical Performance Benchmark werden für TPC-H auch heute noch regelmäßig neue Ergebnisse veröffentlicht 11. Hersteller der betroffenen Systeme wie IBM, HP, Sun oder Sybase nutzen die Ergebnisse vorrangig als Vertriebsargument gegenüber Wettbewerbern. Der TPC-H gruppiert die Ergebnisse dabei in Datenbankgrößen von 100 GB, 300 GB, GB, GB, GB sowie GB. Vergleiche sind nur innerhalb einer solchen Gruppe sinnvoll Testumfang und -ablauf Zur Abbildung des fiktiven Anwendungsfalls werden acht Tabellen benötigt, die, wie in Abbildung 3.3 zu sehen, miteinander in Verbindung stehen. Wie schon beim APB-1 gibt es auch für den TPC-H einen Datengenerator 12, der sowohl die Testdaten als auch die Abfragen für die Durchführung der Leistungstests generiert. Diese Daten müssen wiederum zunächst in die Datenbank geladen werden, bevor die Abfragen und Operationen durchgeführt werden können. Auch der TPC-H bezieht die Performance des Ladevorgangs nicht mit ein, sondern konzentriert sich ausschließlich auf die Abfragen und Datenmanipulationen. 11 Die aktuellen Benchmark-Ergebnisse finden sich unter last_ten_results.asp. 12 Download unter

42 Kapitel 3 Vergleichbarkeit von OLAP-Systemen 42 Abb. 3.3: Datenschema des Benchmarks TPC-H [Cou10, Seite 12] Der TPC-H umfasst 22 Ad-Hoc-Abfragen sowie zwei Operationen zur Datenmanipulation. Ad-Hoc bedeutet in diesem Fall, dass die Abfragen aus Sicht der Datenbank zufällig sind und keine speziell darauf optimierten Datenstrukturen oder vorberechnete Werte existieren. Die Abfragen sollen typische und praxisrelevante Anwendungsfälle simulieren Veröentlichung der Testergebnisse Zur Veröffentlichung des Testergebnisses müssen neben den Messergebnissen zahlreiche Informationen zum System und Messvorgang im sogenannten Full Disclosure Report (FDR) angegeben werden, um die Rahmenbedingungen zu dokumentieren. Dieses Dokument ermöglict später auch einem vom TPC zertifizierten Auditor, das Ergebnis zu validieren. Neben der Topologie und Ausstattung des Systems sind vor allem die Parameter der Software/Datenbank relevant, da Änderun-

43 Kapitel 3 Vergleichbarkeit von OLAP-Systemen 43 gen an den Standard-Einstellungen bereits erhebliche Performance-Unterschiede bewirken können. Veröffentlicht werden müssen unter anderem 13 : Executive Summary (Kurzzusammenfassung) Hardware-Ausstattung, Konfigurationen und Topologie Einstellungen und Parameter der Software/Datenbank Quelldateien und Skripte, die für die Reproduktion benötigt werden Angaben zu Preisen und Verfügbarkeit des Systems Wie schon der APB-1 definiert auch der TPC-H eigene Metriken, welche die Systeme miteinander vergleichbar machen sollen: Abfragen pro Stunde (query-per-hour) Die Kennzahl gibt an, wie viele Abfragen das System innerhalb einer Stunde verarbeiten konnte. Da sich die Teilergebnisse der einzelnen Abfragen teilweise erheblich unterscheiden, ist diese Kennzahl letztlich als Durchschnittswert zu verstehen. Preis-Leistung Aufbauend auf der ersten Kennzahl und den Kosten des Systems werden die tatsächlichen Durchschnittskosten berechnet, die pro Berechnung anfallen Bewertung Nachdem der TPC-H wie alle Benchmarks des Transaction Processing Council ursprünglich sehr Endbenutzer-orientiert war und die tatsächlichen Probleme und Herausforderungen deutlich herausstellte, hat zwischenzeitlich ein Wandel stattgefunden, im Zuge dessen die Leistungstests immer mehr von den großen Hardware- Anbietern beeinflusst wurden. Die Benchmarks werden mittlerweile auf Systemen durchgeführt, die mit ihren riesigen Mengen an Speicherplatz und Arbeitsspeicher sowie den daraus resultierenden Kosten so in der Praxis wahrscheinlich nie zum Einsatz kommen. Aus diesem Kräftemessen der Hardware-Anbieter untereinander hat sich mittlerweile auch Teradata als einer der größten Data-Warehouse-Anbieter zurückgezogen, was 13 Die vollständige Liste der Anforderungen findet sich unter [Cou10].

44 Kapitel 3 Vergleichbarkeit von OLAP-Systemen 44 ein deutliches Indiz dafür ist, dass das TPC seine Relevanz im Data-Warehouse- Sektor verloren hat [Sto09, Seite 15]. Zudem läge insbesondere dem TPC-H ein schlechtes Datenschema zugrunde, das auch immer nur in Ausschnitten und von keiner Abfrage komplett abgefragt würde. Zusammen mit der Ignoranz der Performance beim (initialen) Ladeprozess hat dies dafür gesorgt, dass der Benchmark hinsichtlich des Vergleichs unterschiedlicher Alternativen kaum noch relevant für irgendeine alltägliche Problemstellung ist [Sto09, Seite 15]. Die zunehmende Größe und Komplexität der Systeme, die in den TPC-H-Bestenlisten auftauchen, haben auch dazu geführt, dass die ebenfalls überladenen Full Disclosure Reports ein aktueller FDS von Hewlett Packard 14 vom November 2009 bringt es auf einen Umfang von 131 Seiten sowohl als Grundlage für Investitionsentscheidungen als auch für den Vergleich zweier Alternativen unbrauchbar geworden sind. Auf der Transaction Processing Performance Council Technology Conference, die in Lyon 2009 erstmal stattfand, fasste Michael Stonebraker vom Massachusetts Institute of Technolgy in Cambridge zusammen, dass das TPC seinen Weg verloren hat [Sto09, Seite 11] und immer langsamer und schwerfälliger geworden sei. Um nicht vollkommen in der Versenkung zu verschwinden, müsse sich das TPC jetzt neu definieren, sich an seine Wurzeln zurück erinnern und wieder die Alltagsprobleme und -anforderungen der Anwender adressieren, die da wären Performance, Skalierbarkeit und Einfachheit. Allerdings wird der TPC-H auf Herstellerseite immer noch herangezogen, um die Performance der eigenen Datenbanken zu überprüfen und die Abfragen zu identifizieren, die nicht besonders schnell bearbeitet werden können. Mit diesen Erkenntnissen lassen sich Optimierungen und die Weiterentwicklung gut steuern. 3.3 Rückschlüsse für die eigene Arbeit Nach Betrachtung der beiden Benchmarks lassen sich einige Rückschlüsse für den im weiteren Verlauf dieser Arbeit zu entwickelnden OLAP-Benchmark ziehen. Die 14 Download unter TPCH_FDR_v2.pdf

45 Kapitel 3 Vergleichbarkeit von OLAP-Systemen 45 dargelegten Kritik- und Schwachpunkte sollen nach Möglichkeit beseitigt und die guten Ansätze weiterentwickelt werden. Ladegeschwindigkeit berücksichtigen Der Hauptfokus beider Benchmarks lag auf der Performance bei Abfragen und inkrementellen Updates. Unberücksichtigt blieb aber in beiden Fällen der Ladeprozess, obwohl auch die Zeit zum Laden neuer Daten sowie für eventuell notwendige Neuberechnungen oder Reaggregationen der OLAP-Datenbanken eine nicht zu verachtende Performance-Metrik darstellt (vgl. [FMB + 10, Seite 160]). Da in der Praxis oft sehr große Datenmengen verarbeitet und teilweise auch OLAP- Cubes täglich innerhalb bestimmter zur Verfügung stehender Zeitfenster komplett neu befüllt werden müssen, ist die zu erwartende Dauer eine wichtige Information für Unternehmen. Eine schlechte Lade-Performance kann deshalb bereits ein Ausschlusskriterium sein. Repräsentatives Szenario Beide Benchmarks verwenden das Szenario eines fiktiven Handelsunternehmens. Auch wenn diese Art Szenario im BI-Umfeld oft verwendet wird, so findet sich leider keine Information über dessen Entstehung. Vielfach wird Software in der Praxis anders genutzt als vom Anbieter ursprünglich angedacht. Der Anwendungsfall sollte demnach möglichst repräsentativ sein und sich aus tatsächlichen Kundenanwendungen im Produktivbetrieb ergeben. Planungskomponente Eine zunehmend an Bedeutung gewinnende Aufgabe im BI-Umfeld ist die Planung. Während dieses Thema zu den Zeiten, in denen der APB-1 und der TPC-H entstanden sind, noch irrelevant war, so sind die Planung und Konsolidierung der Teilbereich innerhalb der Business Intelligence, der überdurchschnittlich wächst (vgl. [Bec09]). Nach der Performance beim Lade- und Analysevorgang muss deshalb auch berücksichtigt werden, inwieweit die OLAP-Systeme bereits die Planung und damit das Zurückschreiben der Daten unterstützen und wie ausgereift diese Funktion mittlerweile ist.

46 Kapitel 3 Vergleichbarkeit von OLAP-Systemen 46 Trennung der einzelnen Teilbereiche Der zu entwickelnde OLAP-Benchmark soll grundsätzlich die drei Teilbereiche Laden, Analyse und Planung unterscheiden und die einzelnen Performance-Kennzahlen nicht vermischen. Je nach Anwendungsfall ist es dem potentiellen Anwender damit möglich, die Schwerpunkte entsprechend seinen spezifischen Anforderungen zu setzen. Ein System, das in einem weniger wichtigen Teilbereich versagt aber dafür in der entscheidenden Disziplin überzeugen kann, ist schließlich immer noch besser als eines, das überall nur mittelmäßig abschneidet. Programm für Datengenerierung essentiell In beiden Benchmarks generiert ein kleines Programm die Testdaten, um die Übertragung großer Datenmengen zu vermeiden. Trotz des immer günstigeren Speicherplatzes bleibt die zur Verfügung stehende Bandbreite oftmals ein Flaschenhals. Der OLAP-Benchmark soll deshalb auch einen (Daten-)Generator enthalten. Bliebe noch die Frage nach dem passenden Datenformat. Der APB-1 benutzt ein File Positional 15, bei dem die Zuordnungsvorschrift zwingend bekannt sein muss. Darüber hinaus wären die Formate CSV (Comma Separated Values) und XML möglich. Beide Formate sind textbasiert und können bereits mit einem einfachen Texteditor bearbeitet werden. Für den OLAP-Benchmark sollen CSV-Dateien verwendet werden, da dabei der geringstmögliche Daten-Overhead anfällt. Vergleichbarkeit über unterschiedliche Hardware hinweg schwierig Es hat sich gezeigt, dass der Vergleich von Systemen auf unterschiedlicher Hardware schwierig ist. Neben der Tatsache, dass es nahezu unendlich viele Konfigurationsmöglichkeiten gibt, wirken sich auch Änderungen an der Hardware in vielfältiger Weise aus. 15 In einer solchen Textdatei steht jedem Wert eine fest definierte Anzahl Zeichen zur Verfügung. Wird diese Anzahl nicht benötigt, so müssen am Anfang oder am Ende Leerzeichen ergänzt werden damit der Folgewert wieder an seiner designierten Stelle beginnt. Zwischen zwei Werten steht anders als bei CSV-Dateien kein Trennzeichen mehr.

47 Kapitel 3 Vergleichbarkeit von OLAP-Systemen 47 Aus diesem Grunde soll der OLAP-Benchmark keine Bedingungen an die Hardware-Ausstattung stellen, sondern nur die Datengrundlage und den Ablauf definieren. Zum direkten Vergleich zweier Alternativen müssen diese auf identischer Hardware installiert und den Benchmark unter den identischen Voraussetzungen durchgeführt werden. Die Erkenntnisse sind dann eindeutig und bieten keinen Interpretationsspielraum. Wenn Firmen den Benchmarks im Rahmen eines Proof of Concept auf den späteren Zielsystemen durchführen, zeigen sich auch direkt Engpässe und mögliche Probleme. Und zuletzt werden dadurch auch unrealistische Hardware-Konfigurationen verhindert, was ein großes Problem des TPC-H hinsichtlich der Praxisrelevanz ist. Wenige klare Informationen Die soeben angesprochene Abstraktion von der Hardware bedeutet auch noch bei der Veröffentlichung der Ergebnisse eine signifikante Verbesserung. Bei einem Vergleich mehrerer Alternativen unter gleichen Hardware-Voraussetzungen muss die Konfiguration wenn überhaupt nur ein einziges Mal angegeben werden. Auch die Anzahl der Benchmark-Kennzahlen kann erheblich reduziert werden. Einfach gesagt sollten sich für jedes getestete System Antworten auf Fragestellungen gefunden werden, die da wären: Wie lange dauert das Laden oder die Analyse von 1, 2 oder 4 Millionen Datensätzen? Wie alle Reports und Analysen einer BI-Lösung muss auch der Benchmark die wesentlichen Ergebnisse mit wenigen Informationen deutlich machen. Die Ergebnisse müssen so aussagekräftig sein, dass keine Fragen offen bleiben. Zusammenfassung Die genannten Punkte lassen schon den groben Rahmen des In-Memory OLAP- Benchmarks erkennen. Bevor dieser in Kapitel 5 entwickelt wird, geht es im nächsten Kapitel zunächst um die Identifizierung eines repräsentativen Szenarios, das nicht aus den Köpfen der Entwickler, sondern aus der Praxis kommt. Hierzu werden Anwendungen von Kunden der Jedox AG analysiert, die im Produktivbetrieb eingesetzt werden.

48 Kapitel 4 Typische Szenarien im OLAP-Einsatz Bei den beiden bisher betrachteten Benchmarks war einer der Kritikpunkte, dass es keine Informationen über die Herkunft oder die Entstehung der verwendeten Szenarien und Datenmodelle gibt. Beides soll im Rahmen dieser Arbeit repräsentativ sein. Hierfür werden im ersten Schritt Anwendungen von Kunden der Jedox AG analysiert, um die häufigsten und typischen Anwendungsfälle herauszuarbeiten und auch zu sehen, wie komplex bezogen auf die Anzahl Dimensionen sowie die Anzahl Datensätze die Datenmodelle sind. Anhand dieser Informationen werden sich im Kapitel 4.2 die Szenarien für den späteren Benchmark ergeben. 4.1 Analyse von Kundenanwendungen aus der Praxis Bei der Analyse von Kunden-Anwendungen aus der Praxis soll der Funktionsumfang kurz umrissen werden. Die Details Anzahl und Größe der verwendeten Dimensionen sowie die Anzahl der Aggregationen finden sich im Anhang Kunde 1: Debitoren-Controlling und Umsatzanalyse Die Palo BI Suite wird in dieser Anwendung (detaillierte Statistik des Datenmodells im Anhang A.1) zur Analyse der Debitoren sowie der Umsatzdaten eingesetzt. Eine der zentralen Fragen bei der Debitoren-Analyse ist die nach dem jeweiligen Wertbeitrag. Anhand der Verkaufserlöse, Rabatte und Skonti, des Wareneinsatzes sowie des resultierenden Deckungsbeitrags kann zwischen guten (große Gewinnspanne) und schlechten (geringer Gewinn) Debitoren unterschieden werden. 48

49 Kapitel 4 Typische Szenarien im OLAP-Einsatz 49 Neben dem Wissen über die Deckungsbeiträge der Debitoren ist auch wichtig zu wissen, welche Artikel und Artikelgruppen sich wie erfolgreich verkaufen. Bei dieser Analyse wird derselbe Datenwürfel verwendet, die Daten werden nun aber aus einem anderen Blickwinkel betrachtet Kunde 2: Umsatzanalyse und -planung, Finanzcontrolling Auch bei diesem Kunden ist die Umsatzanalyse nach Regionen und Sparten Teil der BI-Anwendung, wobei das Datenmodell (siehe Anhang A.2) sehr einfach gehalten ist. In jeder Analyse findet sich der Vergleich der aktuellen Werte mit den Planzahlen sowie mit Vorjahreswerten, was auch die Betrachtung der historischen Entwicklung ermöglicht. Neben der Umsatzanalyse werden je Sparte und später auch für den Gesamtkonzern die Umsätze (brutto und netto) sowie die Deckungsbeiträge berechnet. Den aktuellen Zahlen und der Hochrechnung für das aktuelle Geschäftsjahr stehen auch hier die Planzahlen und Vorjahreswerte gegenüber. Der eigentliche Fokus liegt allerdings auf einem Kennzahlen-System für das Finanzcontrolling, in dem sich der Großteil der insgesamt 87 Kennzahlen (37 davon sind berechnete Werte) wiederfinden. Ausgehend vom Nettoumsatz werden Kennzahlen wie der EBITDA 16, das Betriebsergebnis oder auch das Wachstum sowie die Rendite berechnet. Weitere wichtige Kennzahlen sind die freien Cash-Flows, welche die Liquidität des Unternehmens repräsentieren Kunde 3: Kreditcontrolling Bei dieser Anwendung liegt der Fokus darauf, den Finanzstatus des international operierenden Unternehmens stets unter Kontrolle zu haben. Da sich das Geschäftsgebiet über Ländergrenzen hinweg erstreckt und auch die Kreditbeschaffung international erfolgt, sind die zu analysierenden Finanzdaten wie Kredite, Bankguthaben und Zinsen nach Ländern und Währungen untergliedert. Das vollständige Datenmodell findet sich im Anhang A Das EBITDA ist eine wichtige betriebswirtschaftliche Kennzahl zur Profitabilität eines Unternehmens. Es ist die Abkürzung für den englischsprachigen Ausdruck Earnings Before Interests, Depreciation and Amortization, also Gewinn vor Zinsen, Steuern, Abschreibungen auf Sachanlagen und Abschreibungen auf immaterielle Vermögensgegenstände.

50 Kapitel 4 Typische Szenarien im OLAP-Einsatz 50 Die Steuerung der Kredite und des Bankguthabens ist von elementarer Bedeutung, um das Unternehmen stets liquide zu halten. Allerdings soll dies mit dem geringstmöglichen Bankguthaben erreicht werden, um die Opportunitätskosten so niedrig wie möglich zu halten. Kredite werden deshalb bei Fälligkeit mit neuen Krediten refinanziert. Die Herausforderung besteht darin, zu jedem Zeitpunkt den Kredit mit den bestmöglichen Konditionen aufzunehmen. Es ist deshalb essentiell, immer den Überblick sowohl über die Konditionen von über 250 unterschiedlichen Finanzdienstleistern als auch das eigene Kreditportfolio mit verschiedenen Krediten mit unterschiedlichen Volumina, Konditionen und Laufzeiten zu behalten Kunde 4: Komplette Unternehmenssteuerung Bei dieser Filialkette deckt die BI-Anwendung nahezu alle Aufgabenbereiche der Unternehmenssteuerung ab. Die Analysen reichen von der Warenstatistik über die Tagesauswertungen (unternehmensweit und nach Filialen) bis hin zur Personalkostenabrechnung und Budgetplanung. Aufgrund der sehr unterschiedlichen Analysezwecke der einzelnen Datenwürfel gibt es drei voneinander unabhängige Kennzahlen-Dimensionen, wie auch im Anhang A.4 zu sehen ist. Die Personalkosten müssen insbesondere bei einem derart weit verzweigten Filialnetz mit Bezirksebenenen ständig kontrolliert werden. Insbesondere anhand der Hochrechnungen ist es möglich, ausufernde Personalausgaben frühzeitig zu erkennen. Da sich höhere Personalausgaben in einzelnen Filialen mit einem höheren Umsatz durchaus rechtfertigen lassen, ist auch dieser als Kennzahl vorhanden und kann in Relation zu den Durchschnittslöhnen sowie den Öffnungszeiten gesehen werden. Über die Jahre hinweg lässt sich die Kostenentwicklung überblicken und es lassen sich auch die Personalkosten für neue Geschäftsjahre planen. Den Personalkosten als eine der größten Ausgabe-Postionen steht der Warenverkauf gegenüber. Diese Statistik hilft dabei, den Überblick zu behalten und jene Produkte zu identifizieren, die sich besonders gut oder schlecht verkaufen. Damit lassen sich regionale Unterschiede erkennen, um die Produktpalette zu optimieren und auch durch rechtzeitiges Eingreifen Ausverkäufe zu vermeiden.

51 Kapitel 4 Typische Szenarien im OLAP-Einsatz 51 Eng verbunden mit der Warenstatistik sind auch die Tagesauswertungen, nur die Sichtweise ist in diesem Fall eine andere. Im Vordergrund stehen nun die Tagesumsätze der einzelnen Filialen und Bezirke. Diese erscheinen täglich kumuliert, sodass für jeden Monat direkt ersichtlich ist, welchen Umsatz die ersten sieben oder die ersten 14 Tage einbrachten Kunde 5: Debitoren-Controlling Die folgende Anwendung hat nur einen einzigen Einsatzzweck: das Debitoren- Controlling. Die Kunden verteilen sich weltweit, weshalb innerhalb der Kundendimension entsprechende Hierarchien existieren. Die heterogene Kundenstruktur impliziert auch, dass in unterschiedlichen Währungen gerechnet werden muss (siehe Anhang A.5). Aus den offenen Forderungen und dem Zahlungsverhalten der Kunden lassen sich Forecasts ableiten, um die zu erwartenden Zahlungseingänge in den nächsten Quartalen zu quantifizieren Kunde 6: Projektabrechnung Wie dieser Kunde zeigt, lässt sich die Palo-Software auch zur Projektabrechnung einsetzen. Die wichtigsten Fragen dabei betreffen die Art sowie den Umfang der Arbeit einzelner Mitarbeiter in bestimmten Projekten. Verschiedene Projekte bei unterschiedlichen Kunden haben zudem oft variierende Tagessätze, die verwaltet werden müssen. Neben diesen offensichtlichen Anforderungen an ein Projekt-Controlling ist auch die Zuordnung zwischen Kunden und Mitarbeitern mit Hilfe eines zweidimensionalen Datenwürfels abgebildet die 1 steht für seine Zuständigkeit, ansonsten steht die 0, gleiches gilt für den Kundenstatus aktiv oder nicht. Beides sind keine Anwendungsfälle für BI-Systeme, sondern eher ein Fall für relationale Datenbanken. Allerdings sind die Daten somit in einem einzigen System abgelegt, wodurch sich Änderungen unmittelbar auf alle aufbauenden Analysen auswirken. Um später Leistungen in Rechnung stellen zu können, sind alle Tätigkeiten der Mitarbeiter erfasst. Für jeden Zeitraum ist ersichtlich, welche Tätigkeiten für wel-

52 Kapitel 4 Typische Szenarien im OLAP-Einsatz 52 chen Kunden in welchem Projekt geleistet wurden. Neben Arbeitsbeginn und -ende sowie der daraus resultierenden Arbeitszeit können auch noch darüber hinaus entstandenen Kosten wie etwa Fahrtkosten erfasst werden. Auch gegebenenfalls abweichende tatsächlich zu verrechnende Arbeitszeiten lassen sich separat erfassen Kunde 7: Analyse von Umsatz, Projekten und Personal In dieser letzten Anwendung werden mit einer Erfolgsrechnung, einer Personalplanung, einer Projektabrechnung sowie einer Verkaufsanalyse vier unterschiedliche und größtenteils voneinander unabhängige Analysezwecke bedient, was auch ein entsprechend komplexes Datenmodell (vgl. Anhang A.7) zur Folge hat. Darin abgebildet ist zunächst ein einfaches Finanzcontrolling, innerhalb dessen sich die Daten nach Kunden und Geschäftseinheiten sowie zeitlich filtern lassen. Darüber hinaus ist die Gegenüberstellung von Plan- und Ist-Zahlen möglich. Ähnlich simpel fällt auch die Personalkostenanalyse aus, die sich Dimensionen mit dem Finanzcontrolling teilt und mit Personal-spezifischen Kennzahlen ergänzt. Innerhalb der Projektabrechnung sind die zeitlichen Filtermöglichkeiten sowie der Vergleich von Plan- und Ist-Zahlen zentraler Bestandteil. Darüber hinaus lassen sich die Daten nach Projektstatus filtern. Neben den tatsächlich entstandenen Kosten sind für jedes Projekt auch der Ertrag sowie betriebswirtschaftliche Kennzahlen rund um den Profit angegeben, womit der einfache und schnelle Überblick sowie das Monitoring der unterschiedlichen Projekte möglich ist. Zuletzt findet auch die schon fast obligatorische Umsatzanalyse Anwendung. Die zeitlichen Filtermöglichkeiten sind dabei noch erweitert, sodass die Unterscheidung nach Wochentagen, Samstagen und Sonntagen möglich ist. Die Produkt-Dimension enthält eine 3-stufige Hierarchie. Darüber hinaus lässt sich die Auswahl beispielsweise nach dem Geschäftsgebiet einschränken.

53 Kapitel 4 Typische Szenarien im OLAP-Einsatz Die typischen Szenarien Die vorherigen Seiten haben gezeigt, dass die Business-Intelligence-Lösungen auf Basis von Jedox Palo für sehr unterschiedliche Zwecke eingesetzt werden. Auch wenn die Auswahl von sieben Kunden aus einer Referenzliste von über 300 zahlenden Kunden-Firmen 17 nicht den Anspruch auf uneingeschränkte Repräsentativität erheben kann, so zeigen sich doch schon in dieser Stichprobe klare Tendenzen, die die Abbildung 4.1 sowie die Tabelle 4.1 zusammenfassen. Umsatzanalyse Finanzcontrolling Personalanalyse Projektabrechnung Umsatzplanung Personalplanung Projektplanung Kunde 1 Analyse Kunde 2 Kunde 3 Planung Kunde 4 Kunde 5 Kunde 6 Kunde 7 Zusammenfassung 4/7 6/7 3/7 2/7 2/7 1/7 2/7 Tabelle 4.1: Die Anwendungszwecke von BI-Lösungen bei Kunden der Jedox AG Die häufigsten Anwendungen im Analyse-Bereich betreffen das Finanzcontrolling sowie die klassische Umsatzanalyse. Darüber hinaus zeigt sich auch, dass sich problemlos die Personalausgaben und sogar Projekte verwalten lassen. Es ist anzunehmen, dass auch die Business-Intelligence-Lösungen anderer Anbieter in ähnlicher Weise eingesetzt werden. 17 Stand: Oktober 2010

54 Kapitel 4 Typische Szenarien im OLAP-Einsatz 54 Abb. 4.1: Die Anwendungszwecke der Jedox-Kunden Neben der Analyse als klassische Business-Intelligence-Anwendung bietet Palo zusätzlich noch die integrierte Möglichkeit der Planung, was von den Anwendern immer häufiger genutzt wird. Durch die technische Möglichkeit des Rückschreibens von Daten in den Datenwürfel finden die Daten nicht mehr ausschließlich über Datenintegrationsprozesse den Weg ins Data Warehouse, sondern können auch über das Frontend eingegeben und geändert werden. Einige Kunden machen von dieser Möglichkeit bereits Gebrauch und planen Projekte oder Personalausgaben. Insbesondere die Verfügbarkeit des Web-Frontends Palo Web macht diese Funktion zu einem mächtigen Feature, da neue Daten in Echtzeit und dezentral erfasst werden können, ohne dass s oder Dateien verschickt werden müssen. Die neuen Daten stehen unmittelbar danach für Auswertungen zur Verfügung. Wie in Kapitel 1.4 beschrieben handelt es sich bei der Planungsfunktion um einen der aufkommenden Trends im BI-Bereich, bei dem in den kommenden Jahren mit einem überdurchschnittlichen Wachstum gerechnet wird (vgl. [Zim09]). Im nächsten Kapitel werden die genauen Rahmenbedingungen für den OLAP- Benchmark festgelegt. Neben der technischen Basis müssen dafür zunächst die Datenmodelle definiert werden. Die vorherigen Seiten haben klare Tendenzen hin-

55 Kapitel 4 Typische Szenarien im OLAP-Einsatz 55 sichtlich der tatsächlichen Nutzung des Palo OLAP-Servers gezeigt, weshalb es für den Benchmark jeweils eine Analyse- und ein Planungsanwendung geben soll: Umsatzanalyse Die Umsatzanalyse ist die klassische BI-Anwendung und soll aus diesem Grunde als Szenario für den OLAP-Benchmark dienen. Im Gegensatz zum Finanzcontrolling weisen die Umsatzanalysen der besprochenen Kundenszenarien große Ähnlichkeiten auf. Beim Finanzcontrolling sind die Kennzahlen und Kennzahlensysteme dagegen historisch gewachsen und in ihrem Aufbau sowie Umfang und ihrer Komplexität sehr unterschiedlich. Auch weil die Datenmodelle einer Umsatzanalyse schnell sehr groß werden können, bietet sich dieses Szenario für den Benchmark an. Personalplanung Die Personalplanung ist ein ebenso allgemeingültiges Szenario, das in nahezu jeder Firma vorhanden ist und dabei auch immer sehr ähnliche Strukturen aufweist. Da die Personalkosten insbesondere in Hochlohnländern wie Deutschland einen sehr großen Kostenblock darstellen, ist ihnen eine hohe Aufmerksamkeit zu widmen. In Planungsszenarien werden oft unterschiedliche Modelle durchgerechnet, um die Auswirkungen von Änderungen zu simulieren. Solche Tests dürfen auch bei komplexen Datenstrukturen nicht zu lange dauern. Wie die Datenstrukturen der beiden Szenarien im Detail aussehen sollen, wird im folgenden Kapitel erarbeitet. Neben der Definition der Datenstrukturen geht es dort auch um die Beschreibung der (technischen) Rahmenbedingungen, der Datengenerierung sowie des Testablaufs.

56 Kapitel 5 Entwicklung des OLAP-Benchmarks Nach der Analyse einiger Kundenanwendungen geht es nun um die praktische Umsetzung des Benchmarks für In-Memory OLAP-Systeme sowie der dafür nötigen Vorarbeiten. Zunächst müssen die OLAP-Server ausgewählt werden, hardwareseitig gilt es die nötigen Rahmenbedingungen zu klären sowie die Datenmodelle und -strukturen für die beiden Testszenarien Umsatzanalyse und Personalplanung im Detail zu definieren. 5.1 Marktübersicht und Auswahl der Testkandidaten Wie bereits erwähnt, ist die In-Memory-Technologie eine der wichtigsten Entwicklungen im BI-Umfeld, die es erst ermöglicht, die steigenden Performance-Anforderungen zu erfüllen (vgl. Kapitel 2.3). Außerdem ist sie das primäre Kriterium bei der Auswahl der OLAP-Server für den Benchmark, wie bereits der Titel dieser Arbeit impliziert. Während sich der allgemeine BI-Markt aus vielen kleinen und großen Anbietern mit noch mehr unterschiedlichen Produkten zusammensetzt, gibt es bisher nur eine sehr überschaubare Menge an OLAP-Systemen, die die In-Memory-Technologie einsetzen: Palo Der OLAP-Server Palo der Jedox AG ist seit dem ersten Release im März 2006 das Kernstück des BI-Produktportfolios. Von Anfang an setzt Palo auf die multidimensionale Speicherung (MOLAP) sowie die In-Memory-Technologie und ist sowohl unter einer Open-Source-Lizenz als auch in einer funktionserweiterten Version unter kommerzieller Lizenz verfügbar. Seit dem Frühjahr 56

57 Kapitel 5 Entwicklung des OLAP-Benchmarks gibt es eine weitere Palo-Variante, die mit GPU-Unterstützung die Performance von OLAP-Analysen deutlich erhöhen soll. IBM Cognos TM1 Das vormals eigenständige Cognos wurde Anfang 2008 von IBM übernommen, nachdem sich Cognos kurz zuvor die Firma Applix mit ihrem OLAP-Server einverleibt hatte. Nicht erst seit der Übernahme durch den IBM-Konzern ist Cognos einer der großen Wettbewerber am BI-Markt und bietet ein weitreichendes Produktportfolio für Business Intelligence, Planung, Performance Management sowie Unternehmenskonsolidierung. Infor PM OLAP Server (ehemals MIS Alea) Der OLAP-Server ist die Kernkomponente der Performance-Management-Suite Infor PM 10 und damit die Basis für Analyse, Reporting und Planung. Der Infor PM OLAP Server speichert die Daten multidimensional und erlaubt auch das Zurückschreiben der Daten. Mondrian Auch der OLAP-Server Mondrian ist quelloffen und er ist in den BI- Suiten von Jaspersoft, Pentaho und SpagoBI enthalten, die allesamt auch in Open-Source-Versionen verfügbar sind. MIK-OLAP Die Daten lassen sich in MIK-OLAP relational oder multidimensional auf der Festplatte oder im Arbeitsspeicher halten. Mit den sogenannten Hybrid-Würfeln besteht zusätzlich die Möglichkeit, relationale und multidimensionale Speicherung sogar innerhalb eines Datenwürfels zu kombinieren. QlikTech Mit dem Produkt QlikView war die Firma QlikTech einer der Vorreiter auf dem Gebiet der In-Memory-Technologie und hat im Jahre 2008 den Sprung in die TOP 10 der BI-Anbieter in Deutschland geschafft (vgl. [BAR09]). QlikView abstrahiert dabei vom ETL-Prozess und ermöglicht die direkte Verknüpfung von Quellsystemen sowie den darauf aufbauenden Analysen, ohne dass zuvor Hierarchien und Dimensionen explizit definiert werden müssen. Von den sechs genannten OLAP-Servern werden lediglich die drei erstgenannten für den Benchmark herangezogen, wobei Palo sowohl in der Standard- als auch in der GPU-Version getestet wird. Mondrian schied aus dem Testfeld aus, da es die Planung nicht unterstützt, die beiden letzten Programme standen für den Benchmark nicht zur Verfügung.

58 Kapitel 5 Entwicklung des OLAP-Benchmarks 58 Jedes OLAP-System wird mit den Standard-Einstellungen getestet ohne Änderungen oder sonstige Optimierungen vorzunehmen. Es ist anzunehmen, dass mit bestimmten Einstellungen die Testergebnisse jeweils noch verbessert werden könnten, allerdings sind die Kenntnisse der einzelnen Produkte so unterschiedlich, dass eine Ungleichbehandlung nicht zu vermeiden gewesen wäre. Mit der Out-of-the- Box-Installation werden alle OLAP-Server gleichberechtigt und es wird auf diese Weise honoriert, wenn ein System bereits ohne manuelles Eingreifen gute Ergebnisse liefert. Für den Datenimport im Rahmen des ETL-Prozesses wird sofern vorhanden das Datenintegrations-Tool des jeweiligen Herstellers verwendet. 5.2 Die Hardware Wie bereits erwähnt ist ein vollständig von der Hardware abstrahierender Benchmark kaum realisierbar. Sowohl der APB-1- als auch der der TCP-H-Benchmark reduzierten ihre Benchmark-Ergebnisse zwar immer auf eine einzige Kennzahl, zur korrekten Interpretation musste aber immer auch die Hardware zur Durchführung des Leistungstest mit einbezogen werden. Dadurch sind die Benchmark-Ergebnisse schlecht bis gar nicht miteinander vergleichbar und vor allem Rückschlüsse auf die in der eigenen Systemlandschaft zu erwartende Performance nahezu unmöglich. Anspruch dieser Arbeit ist die direkte Vergleichbarkeit der OLAP-Server, die alle auf der identischen Hardware getestet werden. Beim Test-Server handelt es sich um einen Server mit den folgenden Ausstattungsmerkmalen: Mainboard Foxconn Destroyer mit OnBoard-Grafik Prozessor: AMD Phenom II X4 920 (4 x 2,80 GHz) 16 GB Arbeitsspeicher DDR GB Festplatte (SATA, rpm) von Western Digital, auf der das Betriebssystem sowie der OLAP-Server installiert werden 500 GB Festplatte von Samsung (SATA, rpm) für die Quelldaten 4 GPUs Nvidia Tesla C1060 mit jeweils 4 GB Grafik-RAM; jede GPU besitzt 240 (8 x 30) Grafikkerne

59 Kapitel 5 Entwicklung des OLAP-Benchmarks 59 Bei den vier Nvidia-GPUs von Typ Tesla handelt es sich um spezielle Grafikkarten, die eigens als alternative Recheneinheit entwickelt und optimiert wurden. Die Tesla-Grafikkarten werden nur von der GPU-Version des OLAP-Servers Palo verwendet. Für die Anzeige auf dem Monitor wird in allen Fällen die OnBoard-Grafik des Foxconn-Mainboards verwendet. 5.3 Testszenarien und Datenmodelle Im Kapitel 4.2 wurden mit der Umsatzanalyse und der Personalplanung die Szenarien bestimmt, in denen sich die In-Memory OLAP-Systeme beweisen müssen. Der Benchmark soll einerseits die Performance unterschiedlicher Systeme direkt miteinander vergleichbar machen und andererseits auch die Performance-Entwicklung der einzelnen OLAP-Server bei steigenden Datenmengen betrachten. An diesem Punkt wird es insbesondere dann interessant, wenn sich die Datenmenge zunehmend der Gesamtgröße des zur Verfügung stehenden Hauptspeichers annähert. Die nebenstehende Grafik zeigt vereinfacht dargestellt den Datenfluss von den Datenquellen über die Datenintegration und Informationsaufbereitung bis hin zur Analyse. Im Zentrum steht als Symbol für die OLAP-Datenbank das Datenmodell. Wichtig ist an dieser Stelle die Performance beim Laden der Daten in den OLAP-Server (Datenintegration) sowie die Performance bei der Informationsbereitstellung. Der Benchmark wird demnach messen, wie gut die Leistung an den Schnittstellen zur Daten-Sicht ist. Abb. 5.1: Datenfluss von der Datenintegration über die -aufbereitung bis hin zur -analyse (Quelle: [Rec10])

60 Kapitel 5 Entwicklung des OLAP-Benchmarks Datenmodell für die Umsatzanalyse In den Anhängen A.1 bis A.7 sind die Eigenschaften der Anwendungen zu finde. Vier Anwendungen davon umfassen eine Umsatzanalyse, deren relevante Datenwürfel in Tabelle 5.1 noch einmal kurz zusammengefasst werden. Das Datenmodell wird sich hinsichtlich der Komplexität an den Durchschnittswerten orientieren. Kunde Dimensionen Dimension und Aggregationsstufen Kunde Produkte in dreistufiger Hierarchie 38 Kennzahlen 8 Jahre Kunde Artikelgruppen in sechsstufiger Hierarchie 123 Länder in dreistufiger Hierarchie 87 Kennzahlen (der Großteil davon allerdings nur für das Finanzcontrolling relevant) 29 Jahre (10 Jahre davon enthalten Planzahlen) Kunde Produkte in dreistufiger Hierarchie 306 Filialen in vierstufiger Hierarchie 27 Kennzahlen 7 Jahre Kunde Produkte in zweistufiger Hierarchie Mittelwert 8, Geschäftseinheiten in vierstufiger Hierarchie 11 Kennzahlen 9 Jahre Tabelle 5.1: Zusammenfassung der Kundenanwendungen mit Umsatzanalyse Die Dimensionalität der betrachteten Umsatzanalysen liegt im Mittel bei 8,75. In Anlehnung daran wird das Datenmodell des Benchmarks aus acht Dimensionen bestehen, als Kennzahlen werden neben den Umsätzen die Gewinnspannen, die Anzahl der verkauften Artikel sowie die gewährten Rabatte erfasst. Damit ergeben sich die in Abbildung 5.2 zu sehenden Zusammenhänge, die einzelnen Dimensionen lassen sich wie folgt kurz beschreiben:

61 Kapitel 5 Entwicklung des OLAP-Benchmarks 61 Abb. 5.2: Datenmodell der Umsatzanalyse Jahr Um zwischen den einzelnen Jahren unterscheiden zu können, ist das Jahr in einer eigenen Dimension untergebracht. Monat Innerhalb eines Jahres erfolgt zunächst die Unterteilung in die einzelnen Monate sowie die Zusammenfassung von Monaten zu den Quartalen. Tag In einer dritten Zeit-Dimension sind die Tage untergebracht. Die Trennung von Tagen und Monaten in zwei Dimensionen ist nötig, da ansonsten Vergleiche der ersten 10 Tage zweier unterschiedlicher Monate nicht möglich wären. Filiale Jeder Umsatz fällt in einer bestimmten Filiale an, die sich wiederum in einem bestimmten Postleitzahlengebiet in einem bestimmten Land befindet. Bezirk Zudem lässt sich jeder Umsatz einem Bezirk zuschreiben. Während sich allerdings die Zuordnung einer Filiale zu einem Postleitzahlengebiet nicht ändert, können sich die Beschnitte von Bezirken und Regionen durchaus ändern. Dies führt zur beschriebenen Trennung in zwei separate Dimensionen. Artikel Innerhalb der Artikel-Dimension existiert eine dreistufige Hierarchie, die jeden Artikel einer Warengruppe sowie einer Untergruppe zuordnet.

62 Kapitel 5 Entwicklung des OLAP-Benchmarks 62 Marke Artikel werden unter mehreren Markennamen verkauft, teilweise als Nobelmarke, aber auch unter einem Label für Discounter. Ein und dasselbe Produkte kann somit unter verschiedenen Marken vertrieben werden, weshalb diese Unterscheidung nach Marken erforderlich wird. Kunde Bei jedem Verkauf wird der Kunde erfasst, der wiederum einer Kundengruppe zugeordnet ist. Darüber hinaus erfolgt in der nächsten Aggregationsstufe die Unterteilung der Kunden in Privat- und Geschäftskunden Datenmodell der Personalplanung Neben der klassischen Analyse ist mit einer Personalplanung auch eine Planungsanwendung Teil des OLAP-Benchmarks. Dies ist, wie in Kapitel 1.4 bereits erwähnt, eine der aufkommenden Anforderungen an BI-Systeme, wird aber noch nicht von allen OLAP-Servern unterstützt. Für den Benchmark wird eine Personalplanung entworfen, da diese zu den obligatorischen Aufgaben jeder Unternehmensführung gehört. Das Datenmodell einer Personalplanung präsentiert sich auch in unterschiedlichen Unternehmen häufig sehr ähnlich und ist zumeist einfach aufgebaut, wie die Tabelle 5.2 zeigt. Im Mittelpunkt steht der Mitarbeiter, der einen gewissen Monatslohn verdient und eventuell zusätzlich Urlaubs- und Weihnachtsgeld erhält. Diese Zahlen müssen ebenso messund planbar sein wie die Fehlzeiten eines jeden Mitarbeiters. Kunde Dimension und Aggregationssstufen Kunde Filialen in vierstufiger Hierarchie 46 Monate und mit diversen Kombinationen und Aggregationen in einer bis zu zwölfstufigen Hierarchie 12 unabhängige Kennzahlen für die Personalkosten (keine Aggregationen) 6 Jahre zzgl. Aufsummierung (7 Dimensionselemente) 4 Szenarien, u.a. Ist, Budget und Hochrechnung Tabelle 5.2: Personalplanung aus der analysierten Kundenanwendung

63 Kapitel 5 Entwicklung des OLAP-Benchmarks 63 In Anlehnung an die beschriebene Kundenanwendung entstand das in Abbildung 5.3 zu sehende Datenmodell. Die Dimensionen Filiale sowie Jahr und Monat sind dabei analog dem Datenmodell der Umsatzanalyse. Neu hinzu kommen die Dimensionen Mitarbeiter sowie der Datentyp, welcher zwischen Ist- und Planzahlen unterscheidet. Als Kennzahlen werden der Nettolohn, die Fehltage sowie das Urlaubs- und Weihnachtsgeld erfasst. Abb. 5.3: Datenmodell des Szenarios Personalplanung Die Dimensionen lassen sich wie folgt kurz charakterisieren: Filiale Die Filiale ist der Ort, an dem Personalkosten anfallen und ist auch im Planungsszenario in Postleitzahlengebiete und Länder gegliedert. Mitarbeiter Der Mitarbeiter ist das zentrale Element der Personalplanung. Eine feste Zuordnung zwischen einem Mitarbeiter und einer Filiale besteht nicht, da jeder Mitarbeiter Kosten in unterschiedlichen Filialen erzeugen kann. Mit dieser Trennung von Mitarbeitern und Filialen ist das Datenmodell auch sicher gegenüber Stellenwechseln. Datentyp Bei der Planung wird zwischen Ist- und Planzahlen unterschieden. Jahr Die obligatorische Jahres-Dimension ermöglicht die Trennung der Personalkostenplanung nach einzelnen Jahren. Monat Da die tagesweise Betrachtung wenig Sinn ergibt ist der Monat die kleinste Einheit. Die Monate werden zudem quartalsweise zusammengefasst.

Einführungsveranstaltung: Data Warehouse

Einführungsveranstaltung: Data Warehouse Einführungsveranstaltung: 1 Anwendungsbeispiele Berichtswesen Analyse Planung Forecasting/Prognose Darstellung/Analyse von Zeitreihen Performancevergleiche (z.b. zwischen Organisationseinheiten) Monitoring

Mehr

Marketing Intelligence Architektur und Konzepte. Josef Kolbitsch Manuela Reinisch

Marketing Intelligence Architektur und Konzepte. Josef Kolbitsch Manuela Reinisch Marketing Intelligence Architektur und Konzepte Josef Kolbitsch Manuela Reinisch Übersicht Mehrstufiges BI-System Architektur eines Data Warehouses Architektur eines Reporting-Systems Benutzerrollen in

Mehr

Einführung in OLAP und Business Analysis. Gunther Popp dc soft GmbH

Einführung in OLAP und Business Analysis. Gunther Popp dc soft GmbH Einführung in OLAP und Business Analysis Gunther Popp dc soft GmbH Überblick Wozu Business Analysis mit OLAP? OLAP Grundlagen Endlich... Technischer Background Microsoft SQL 7 & OLAP Services Folie 2 -

Mehr

Durchblick im Self-Service-Dschungel. Hannover, 16.03.2015 Patrick Keller, Senior Analyst

Durchblick im Self-Service-Dschungel. Hannover, 16.03.2015 Patrick Keller, Senior Analyst Durchblick im Self-Service-Dschungel Hannover, 16.03.2015 Patrick Keller, Senior Analyst Business Application Research Center (BARC) B Europas führendes IT-Analysten- und -Beratungshaus für Business Software

Mehr

1Ralph Schock RM NEO REPORTING

1Ralph Schock RM NEO REPORTING 1Ralph Schock RM NEO REPORTING Bereit für den Erfolg Business Intelligence Lösungen Bessere Entscheidungen Wir wollen alle Mitarbeiter in die Lage versetzen, bessere Entscheidungen schneller zu treffen

Mehr

OLAP und Data Warehouses

OLAP und Data Warehouses OLP und Data Warehouses Überblick Monitoring & dministration Externe Quellen Operative Datenbanken Extraktion Transformation Laden Metadaten- Repository Data Warehouse OLP-Server nalyse Query/Reporting

Mehr

Marketing Intelligence Übersicht über Business Intelligence. Josef Kolbitsch Manuela Reinisch

Marketing Intelligence Übersicht über Business Intelligence. Josef Kolbitsch Manuela Reinisch Marketing Intelligence Übersicht über Business Intelligence Josef Kolbitsch Manuela Reinisch Übersicht Beispiel: Pantara Holding Der Begriff Business Intelligence Übersicht über ein klassisches BI-System

Mehr

Logische Modellierung von Data Warehouses

Logische Modellierung von Data Warehouses Logische Modellierung von Data Warehouses Vertiefungsarbeit von Karin Schäuble Gliederung. Einführung. Abgrenzung und Grundlagen. Anforderungen. Logische Modellierung. Methoden.. Star Schema.. Galaxy-Schema..

Mehr

Datawarehouse Architekturen. Einheitliche Unternehmenssicht

Datawarehouse Architekturen. Einheitliche Unternehmenssicht Datawarehouse Architekturen Einheitliche Unternehmenssicht Was ist Datawarehousing? Welches sind die Key Words? Was bedeuten sie? DATA PROFILING STAGING AREA OWB ETL OMB*PLUS SAS DI DATA WAREHOUSE DATA

Mehr

Asklepius-DA Die intelligente Technologie für die umfassende Analyse medizinischer Daten Leistungsbeschreibung

Asklepius-DA Die intelligente Technologie für die umfassende Analyse medizinischer Daten Leistungsbeschreibung Asklepius-DA Die intelligente Technologie für die umfassende Analyse medizinischer Daten Leistungsbeschreibung Datei: Asklepius DA Flyer_Leistung_2 Seite: 1 von:5 1 Umfassende Datenanalyse Mit Asklepius-DA

Mehr

1 Einleitung. Betriebswirtschaftlich administrative Systeme

1 Einleitung. Betriebswirtschaftlich administrative Systeme 1 1 Einleitung Data Warehousing hat sich in den letzten Jahren zu einem der zentralen Themen der Informationstechnologie entwickelt. Es wird als strategisches Werkzeug zur Bereitstellung von Informationen

Mehr

Die Microsoft-Komplettlösung für Datawarehousing, Big Data und Business Intelligence im Überblick. Volker.Hinz@microsoft.com

Die Microsoft-Komplettlösung für Datawarehousing, Big Data und Business Intelligence im Überblick. Volker.Hinz@microsoft.com Die Microsoft-Komplettlösung für Datawarehousing, Big Data und Business Intelligence im Überblick Volker.Hinz@microsoft.com Was sagt der Markt? Fakten Meinung der Analysten zu Microsofts Angeboten Nutzen

Mehr

Data Warehouse Definition (1) http://de.wikipedia.org/wiki/data-warehouse

Data Warehouse Definition (1) http://de.wikipedia.org/wiki/data-warehouse Data Warehouse Definition (1) http://de.wikipedia.org/wiki/data-warehouse Ein Data-Warehouse bzw. Datenlager ist eine zentrale Datensammlung (meist eine Datenbank), deren Inhalt sich aus Daten unterschiedlicher

Mehr

Agenda. Hype oder Mehrwert. Herausforderungen. Methoden Werkzeuge. Kosten Nutzen. Definition Ziele

Agenda. Hype oder Mehrwert. Herausforderungen. Methoden Werkzeuge. Kosten Nutzen. Definition Ziele Agenda Definition Ziele Methoden Werkzeuge Herausforderungen Kosten Nutzen Hype oder Mehrwert Definition / Ziele Google Suche: define:business Intelligence Mit Business Intelligence können alle informationstechnischen

Mehr

In-Memory & Real-Time Hype vs. Realität: Maßgeschneiderte IBM Business Analytics Lösungen für SAP-Kunden

In-Memory & Real-Time Hype vs. Realität: Maßgeschneiderte IBM Business Analytics Lösungen für SAP-Kunden In-Memory & Real-Time Hype vs. Realität: Maßgeschneiderte IBM Business Analytics Lösungen für SAP-Kunden Jens Kaminski ERP Strategy Executive IBM Deutschland Ungebremstes Datenwachstum > 4,6 Millarden

Mehr

MIS by Franziska Täschler, Winformation GmbH ftaeschler@winformation-gmbh.ch Ausgabe 01/2001

MIS by Franziska Täschler, Winformation GmbH ftaeschler@winformation-gmbh.ch Ausgabe 01/2001 MIS Glossar by Franziska Täschler, Winformation GmbH ftaeschler@winformation-gmbh.ch Ausgabe 01/2001 Aggregat Data Cube Data Marts Data Mining Data Warehouse (DWH) Daten Decision Support Systeme (DSS)

Mehr

eevolution Business Intelligence Oliver Rzeniecki COMPRA GmbH Programmierer & Datenbankadministrator

eevolution Business Intelligence Oliver Rzeniecki COMPRA GmbH Programmierer & Datenbankadministrator eevolution Business Intelligence Oliver Rzeniecki COMPRA GmbH Programmierer & Datenbankadministrator Agenda Was ist Business Intelligence? Was ist OLAP? Unterschied zwischen OLAP und OLTP? Bestandteile

Mehr

Data Warehouse Technologien

Data Warehouse Technologien mitp Professional Data Warehouse Technologien von Veit Köppen, Gunter Saake, Kai-Uwe Sattler 2. Auflage 2014 Data Warehouse Technologien Köppen / Saake / Sattler schnell und portofrei erhältlich bei beck-shop.de

Mehr

Erfolgreiche Unternehmensführung durch den Einsatz von Corporate Performance Management

Erfolgreiche Unternehmensführung durch den Einsatz von Corporate Performance Management Andrei Buhrymenka Erfolgreiche Unternehmensführung durch den Einsatz von Corporate Performance Management Für Unternehmen mit Business Intelligence Diplomica Verlag Andrei Buhrymenka Erfolgreiche Unternehmensführung

Mehr

BARC-Studie Data Warehousing und Datenintegration

BARC-Studie Data Warehousing und Datenintegration Ergebnisse der BARC-Studie Data Warehouse Plattformen Dr. Carsten Bange BARC-Studie Data Warehousing und Datenintegration Data-Warehouse -Plattformen und Datenintegrationswerkzeuge im direkten Vergleich

Mehr

Michael Bauer Niederlassungsleiter Köln

Michael Bauer Niederlassungsleiter Köln Click to edit Master title style 1 Michael Bauer Niederlassungsleiter Köln Hamburg, 18. Juni 2009 2009 IBM Corporation Agenda Click to edit Master title style 2 zur Person Wo, Warum.., Was - CPM liefert

Mehr

Analytische Datenbanken und Appliances als Engine für erfolgreiche Business Intelligence

Analytische Datenbanken und Appliances als Engine für erfolgreiche Business Intelligence Analytische Datenbanken und Appliances als Engine für erfolgreiche Business Intelligence IBM Netezza Roadshow 30. November 2011 Carsten Bange Gründer & Geschäftsführer BARC Die Krise hat die Anforderungen

Mehr

Self Service BI. - Business Intelligence im Mittelstand - schnelle Ergebnisse, nachhaltige Erfolge

Self Service BI. - Business Intelligence im Mittelstand - schnelle Ergebnisse, nachhaltige Erfolge Self Service BI - Business Intelligence im Mittelstand - schnelle Ergebnisse, nachhaltige Erfolge 04. Juli 2013 Cubeware GmbH zu Gast im Hause der Raber+Märcker GmbH Referent: Uwe van Laak Presales Consultant

Mehr

Vorwort zur zweiten Auflage...V. Vorwort zur ersten Auflage... VIII

Vorwort zur zweiten Auflage...V. Vorwort zur ersten Auflage... VIII Vorwort zur zweiten Auflage...V Vorwort zur ersten Auflage... VIII 1 Management Support Systeme und Business Intelligence Anwendungssysteme zur Unterstützung von Managementaufgaben...1 1.1 Computergestützte

Mehr

Business Intelligence. Data Warehouse / Analyse Sven Elvers 2005-07-06

Business Intelligence. Data Warehouse / Analyse Sven Elvers 2005-07-06 Business Intelligence Data Warehouse / Analyse Sven Elvers 2005-07-06 Einleitung Dieses Dokument beschreibt einen für das Verständnis relevanten Teil der Präsentation. Business Intelligence Motivation

Mehr

Business Intelligence - Wie passt das zum Mainframe?

Business Intelligence - Wie passt das zum Mainframe? Business Intelligence - Wie passt das zum Mainframe? IBM IM Forum, 15.04.2013 Dr. Carsten Bange, Gründer und Geschäftsführer BARC Ressourcen bei BARC für Ihr Projekt Durchführung von internationalen Umfragen,

Mehr

Kapitel 2 Terminologie und Definition

Kapitel 2 Terminologie und Definition Kapitel 2 Terminologie und Definition In zahlreichen Publikationen und Fachzeitschriften tauchen die Begriffe Data Warehouse, Data Warehousing, Data-Warehouse-System, Metadaten, Dimension, multidimensionale

Mehr

Business Intelligence: Markt, Trends und Technologien. Dr. Carsten Bange Darmstadt, 22.1.2008

Business Intelligence: Markt, Trends und Technologien. Dr. Carsten Bange Darmstadt, 22.1.2008 Business Intelligence: Markt, Trends und Technologien Dr. Carsten Bange Darmstadt, 22.1.2008 Business Intelligence & Corporate Performance Management Entwicklung des BI-Softwaremarktes Seit Jahren robustes

Mehr

Master-Thesis (m/w) für unseren Standort Stuttgart

Master-Thesis (m/w) für unseren Standort Stuttgart Master-Thesis (m/w) für unseren Standort Abschlussarbeit im Bereich Business Process Management (BPM) Effizienzsteigerung von Enterprise Architecture Management durch Einsatz von Kennzahlen Braincourt

Mehr

DATA WAREHOUSE Optimiertes und flexibles Datenmanagement für das Investment Reporting

DATA WAREHOUSE Optimiertes und flexibles Datenmanagement für das Investment Reporting DATA WAREHOUSE Optimiertes und flexibles Datenmanagement für das Investment Reporting 1 Lange bewährt immer noch gelitten Das Data Warehouse ist vielen ein Dorn im Auge IT-Manager messen der zentralen

Mehr

Data Warehouse Grundlagen

Data Warehouse Grundlagen Seminarunterlage Version: 2.10 Version 2.10 vom 24. Juli 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen sind Warenzeichen

Mehr

Einführung in Hauptspeicherdatenbanken

Einführung in Hauptspeicherdatenbanken Einführung in Hauptspeicherdatenbanken Harald Zankl Probevorlesung 13. 01., 13:15 14:00, HS C Inhaltsverzeichnis Organisation Überblick Konklusion Harald Zankl (LFU) Hauptspeicherdatenbanken 2/16 Organisation

Mehr

REAL-TIME DATA WAREHOUSING

REAL-TIME DATA WAREHOUSING REAL-TIME DATA WAREHOUSING Lisa Wenige Seminarvortrag Data Warehousing und Analytische Datenbanken Friedrich-Schiller-Universität Jena - 19.01.12 Lisa Wenige 19.01.2012 2 Agenda 1. Motivation 2. Begriffsbestimmung

Mehr

Möglichkeiten für bestehende Systeme

Möglichkeiten für bestehende Systeme Möglichkeiten für bestehende Systeme Marko Filler Bitterfeld, 27.08.2015 2015 GISA GmbH Leipziger Chaussee 191 a 06112 Halle (Saale) www.gisa.de Agenda Gegenüberstellung Data Warehouse Big Data Einsatz-

Mehr

Data Warehousing. Kapitel 1: Data-Warehousing-Architektur. Folien teilweise übernommen von Matthias Gimbel

Data Warehousing. Kapitel 1: Data-Warehousing-Architektur. Folien teilweise übernommen von Matthias Gimbel Data Warehousing Kapitel 1: Data-Warehousing-Architektur Folien teilweise übernommen von Matthias Gimbel 2 Analyse von Geschäftsprozessen Mögliche Fragestellungen Wie entwickelt sich unser Umsatz im Vergleich

Mehr

Trends in Business Intelligence

Trends in Business Intelligence Trends in Business Intelligence Dr. Carsten Bange Business Intelligence (BI) beschreibt die Erfassung, Sammlung und Darstellung von Information zur Planung, Steuerung und Kontrolle der Unternehmensleistung.

Mehr

Business Intelligence im Krankenhaus

Business Intelligence im Krankenhaus Business Intelligence im Krankenhaus Dr. Thomas Lux Holger Raphael IT-Trends in der Medizin 03.September 2008 Essen Gliederung Herausforderungen für das Management im Krankenhaus Business Intelligence

Mehr

Multidimensionales Datenmodell, Cognos

Multidimensionales Datenmodell, Cognos Data Warehousing (II): Multidimensionales Datenmodell, Cognos Praktikum: Data Warehousing und Mining Praktikum Data Warehousing und Mining, Sommersemester 2010 Vereinfachte Sicht auf die Referenzarchitektur

Mehr

Business Intelligence für Controller

Business Intelligence für Controller Controllers Best Practice Fachbuch Business Intelligence für Controller Hermann Hebben und Dr. Markus Kottbauer Verlag für ControllingWissen ÄG, Freiburg und Wörthsee Ein Unternehmen der Haufe Mediengruppe

Mehr

Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht)

Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht) Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht) Christian Haag, DATA MART Consulting Consulting Manager Oracle DWH Team

Mehr

Die Bedeutung der Prozessmodellierung bei der Weiterentwicklung des DWHs der DAK Der Innovator als Missing Link

Die Bedeutung der Prozessmodellierung bei der Weiterentwicklung des DWHs der DAK Der Innovator als Missing Link Die Bedeutung der Prozessmodellierung bei der Weiterentwicklung des DWHs der DAK Der Innovator als Missing Link Konrad Linner, solvistas GmbH Nürnberg, 20.November 2012 Inhaltsverzeichnis Vorstellung solvistas

Mehr

INVEST projects. Besseres Investitionscontrolling mit INVESTprojects

INVEST projects. Besseres Investitionscontrolling mit INVESTprojects Besseres Investitionscontrolling mit Der Investitionsprozess Singuläres Projekt Idee, Planung Bewertung Genehmigung Realisierung Kontrolle 0 Zeit Monate, Jahre Perioden Der Investitionsprozess Singuläres

Mehr

Visual KPI: Echtzeitdaten & -information zu jeder Zeit, an jedem Ort! Dietmar Ort Sales MEGLA GmbH

Visual KPI: Echtzeitdaten & -information zu jeder Zeit, an jedem Ort! Dietmar Ort Sales MEGLA GmbH Visual KPI: Echtzeitdaten & -information zu jeder Zeit, an jedem Ort! Dietmar Ort Sales MEGLA GmbH Visual KPI Die individuelle KPI Software Einfach bereitzustellende Daten aus PI, AF, Microsoft SQL Server,

Mehr

DWH Szenarien. www.syntegris.de

DWH Szenarien. www.syntegris.de DWH Szenarien www.syntegris.de Übersicht Syntegris Unser Synhaus. Alles unter einem Dach! Übersicht Data-Warehouse und BI Projekte und Kompetenzen für skalierbare BI-Systeme. Vom Reporting auf operativen

Mehr

WAHLPFLICHTBEREICH WIRTSCHAFTSINFORMATIK 'DATA WAREHOUSE'

WAHLPFLICHTBEREICH WIRTSCHAFTSINFORMATIK 'DATA WAREHOUSE' Take control of your decision support WAHLPFLICHTBEREICH WIRTSCHAFTSINFORMATIK 'DATA WAREHOUSE' Sommersemester 2008 Gliederung Business Intelligence und Data Warehousing On-Line Analytical Processing Ziel

Mehr

The integration of business intelligence and knowledge management

The integration of business intelligence and knowledge management The integration of business intelligence and knowledge management Seminar: Business Intelligence Ketevan Karbelashvili Master IE, 3. Semester Universität Konstanz Inhalt Knowledge Management Business intelligence

Mehr

Das 1&1 Datawarehouse -Von Massendaten zu Prozesskennzahlen

Das 1&1 Datawarehouse -Von Massendaten zu Prozesskennzahlen Das 1&1 Datawarehouse -Von Massendaten zu Prozesskennzahlen Inhalt Das Unternehmen 1&1 Internet AG Ausgangssituation Projektziel Lösung Das 1&1 Datawarehouse 2 Zu meiner Person Volker Müller-Strunk Dipl.

Mehr

SAP BI Business Information

SAP BI Business Information Aus der Praxis für die Praxis. SAP BI Business Information Thomas Wieland Berlin, 24. November 2006 SAP BW Architektur Seite 2 Business Intelligence Aufgaben Bereitstellung harmonisierter Daten, Informationen

Mehr

Vergleich von Open-Source und kommerziellen Programmen zur Durchführung eines ETL-Prozesses

Vergleich von Open-Source und kommerziellen Programmen zur Durchführung eines ETL-Prozesses Vergleich von Open-Source und kommerziellen Programmen zur Durchführung eines ETL-Prozesses Exposé zur Diplomarbeit Humboldt-Universität zu Berlin Mathematisch-Naturwissenschaftliche Fakultät II Institut

Mehr

Trends in Business Intelligence

Trends in Business Intelligence Trends in Business Intelligence Patrick Keller Senior Analyst BARC Business Application Research Center BARC ist Marktanalyst und Berater spezialisiert auf Business Intelligence, Daten- und Dokumentenmanagement.

Mehr

Data Warehousing: Anwendungsbeispiel

Data Warehousing: Anwendungsbeispiel Frühjahrsemester 2012 cs242 Data Warehousing / cs243 Datenbanken Kapitel 1: Einführung H. Schuldt Data Warehousing: Anwendungsbeispiel Tresgros Tresgros Tresgros Filiale Muttenz Filiale Allschwil Filiale

Mehr

Wie integriert sich BI in den unternehmensweiten Softwareentwicklungsprozess? Nürnberg, 10.11.2009

Wie integriert sich BI in den unternehmensweiten Softwareentwicklungsprozess? Nürnberg, 10.11.2009 Wie integriert sich BI in den unternehmensweiten Softwareentwicklungsprozess? Nürnberg, 10.11.2009 I N H A L T 1. Warum Modelle für Business Intelligence (BI)? 2. Anforderungen von BI an Software- Entwicklungsprozesse

Mehr

Business Intelligence und Geovisualisierung in der Gesundheitswirtschaft

Business Intelligence und Geovisualisierung in der Gesundheitswirtschaft Business Intelligence und Geovisualisierung in der Gesundheitswirtschaft Prof. Dr. Anett Mehler-Bicher Fachhochschule Mainz, Fachbereich Wirtschaft Prof. Dr. Klaus Böhm health&media GmbH 2011 health&media

Mehr

OLAP mit dem SQL-Server

OLAP mit dem SQL-Server Hartmut Messerschmidt Kai Schweinsberg OLAP mit dem SQL-Server Eine Einführung in Theorie und Praxis IIIBibliothek V dpunkt.verlag Teil OLAP undder Microsoft SQL-Server 1 1 Theoretische Grundlagen 3 1.1

Mehr

Strategie und Self Service BI im Unternehmen. Gegensätze miteinander kombinieren

Strategie und Self Service BI im Unternehmen. Gegensätze miteinander kombinieren Strategie und Self Service BI im Unternehmen Gegensätze miteinander kombinieren Claas Planitzer Düsseldorf Juni 2015 Agenda 5. Herausforderungen 1. Idealbild 2. Realität 3. Self Service 4. BI. Was ist

Mehr

Business Intelligence

Business Intelligence Business Intelligence Anwendung 1 MInf1 HAW Hamburg Betreuender Professor: Prof. Dr. Zukunft by Jason Hung Vuong [12] Gliederung 1. Hamburg Energie Kooperation 2. Motivation 3. Business Intelligence 4.

Mehr

Oracle 10g revolutioniert Business Intelligence & Warehouse

Oracle 10g revolutioniert Business Intelligence & Warehouse 10g revolutioniert Business Intelligence & Warehouse Marcus Bender Strategisch Technische Unterstützung (STU) Hamburg 1-1 BI&W Market Trends DWH werden zu VLDW Weniger Systeme, mehr Daten DWH werden konsolidiert

Mehr

Data-Warehouse-Systeme

Data-Warehouse-Systeme Vorlesung im Wintersemester 2008/09 Data-Warehouse-Systeme Dr. Stefanie Rinderle-Ma Institut für Datenbanken und Informationssysteme Universität Ulm stefanie.rinderle@uni-ulm.de Übersicht 1) Einführung

Mehr

Zusammenspiel von Business Intelligence mit betrieblicher Anwendungssoftware Falk Neubert, Universität Osnabrück

Zusammenspiel von Business Intelligence mit betrieblicher Anwendungssoftware Falk Neubert, Universität Osnabrück Zusammenspiel von Business Intelligence mit betrieblicher Anwendungssoftware 14. März 2013, IHK Osnabrück-Emsland-Grafschaft Bentheim Geschichte Kassenbuch des Liederkranz, 1886 Hutmachergesangvereins

Mehr

Data Warehouse und Data Mining

Data Warehouse und Data Mining Data Warehouse und Data Mining Marktführende Produkte im Vergleich von Dr. Heiko Schinzer, Carsten Bange und Holger Mertens 2., völlig überarbeitete und erweiterte Auflage -. - Verlag Franz Vahlen München

Mehr

Von Big Data zu Executive Decision BI für den Fachanwender bis hin zu Advanced Analytics 10.45 11.15

Von Big Data zu Executive Decision BI für den Fachanwender bis hin zu Advanced Analytics 10.45 11.15 9.30 10.15 Kaffee & Registrierung 10.15 10.45 Begrüßung & aktuelle Entwicklungen bei QUNIS 10.45 11.15 11.15 11.45 Von Big Data zu Executive Decision BI für den Fachanwender bis hin zu Advanced Analytics

Mehr

Komponenten und Architekturen von Analytischen Informationssystemen (AIS)

Komponenten und Architekturen von Analytischen Informationssystemen (AIS) Komponenten und Architekturen von Analytischen Informationssystemen (AIS) Melanie Pfoh Konsultation 27. Juni 2013 Hinweis Diese Folien ersetzen keinesfalls den Übungsstoff des zugehörigen e-learning-kurses.

Mehr

Technologischen Rahmenbedingungen und Werkzeuge für eine wertschöpfende Controller-Rolle

Technologischen Rahmenbedingungen und Werkzeuge für eine wertschöpfende Controller-Rolle Technologischen Rahmenbedingungen und Werkzeuge für eine wertschöpfende Controller-Rolle 40. Congress der Controller, Themenzentrum C, München Steffen Vierkorn, Geschäftsführer Qunis GmbH, Neubeuern Die

Mehr

GESCHÄFTSZAHLEN SCHMACKHAFT ZUBEREITET Franke Kitchen Systems erhöht mit IBM Cognos die Flexibilität bei der Analyse von SAP-Daten

GESCHÄFTSZAHLEN SCHMACKHAFT ZUBEREITET Franke Kitchen Systems erhöht mit IBM Cognos die Flexibilität bei der Analyse von SAP-Daten GESCHÄFTSZAHLEN SCHMACKHAFT ZUBEREITET Franke Kitchen Systems erhöht mit IBM Cognos die Flexibilität bei der Analyse von SAP-Daten Thomas Ehret, Franke Kitchen Systems Group (Aarburg, Schweiz), email:

Mehr

Umsetzung der Anforderungen - analytisch

Umsetzung der Anforderungen - analytisch Umsetzung der Anforderungen - analytisch Titel des Lernmoduls: Umsetzung der Anforderungen - analytisch Themengebiet: New Economy Gliederungspunkt im Curriculum: 4.2.5.5 Zum Inhalt: In diesem Modul wird

Mehr

Inhalt. 1 Übersicht. 2 Anwendungsbeispiele. 3 Einsatzgebiete. 4 Systemanforderungen. 5 Lizenzierung. 6 Installation. 7 Key Features.

Inhalt. 1 Übersicht. 2 Anwendungsbeispiele. 3 Einsatzgebiete. 4 Systemanforderungen. 5 Lizenzierung. 6 Installation. 7 Key Features. Inhalt 1 Übersicht 2 Anwendungsbeispiele 3 Einsatzgebiete 4 Systemanforderungen 5 Lizenzierung 6 Installation 7 Key Features Seite 2 von 12 1. Übersicht MIK.arjuna ist eine 64-bit multidimensionale Datenbank,

Mehr

Einsatz von Anwendungssystemen

Einsatz von Anwendungssystemen Einsatz von Anwendungssystemen WS 2013/14 7 Führungssysteme 7.1 Data Warehouse 7.2 Planungssysteme 7.3 Balanced Scorecard (BSC) 7.4 Business Intelligence 7 Führungssysteme 7.1 Data Warehouse Ein Data Warehouse

Mehr

Zukunftsträchtige Potentiale: Predictive Analysis mit SAP HANA & SAP BO

Zukunftsträchtige Potentiale: Predictive Analysis mit SAP HANA & SAP BO innovation@work Zukunftsträchtige Potentiale: Predictive Analysis mit SAP HANA & SAP BO thinkbetter AG Florian Moosmann 8. Mai 2013 1 Agenda Prädiktive Analyse Begriffsdefinition Herausforderungen Schwerpunktbereiche

Mehr

David gegen Goliath Excel 2010 in Verbindung mit Datawarehouse und im Vergleich zu Business Objects

David gegen Goliath Excel 2010 in Verbindung mit Datawarehouse und im Vergleich zu Business Objects Thema: David gegen Goliath Excel 2010 in Verbindung mit Datawarehouse und im Vergleich zu Business Objects Autor: Dipl. Wirtsch.-Inf. Torsten Kühn PRAXIS-Consultant PRAXIS EDV- Betriebswirtschaft- und

Mehr

Data Warehouses und Moderne Betriebliche Anwendungen von Datenbanksystemen

Data Warehouses und Moderne Betriebliche Anwendungen von Datenbanksystemen Data Warehouses und Moderne Betriebliche Anwendungen von Datenbanksystemen (Folien von A. Kemper zum Buch 'Datenbanksysteme') Online Transaction Processing Betriebswirtschaftliche Standard- Software (SAP

Mehr

SAS Analytics bringt SAP HANA in den Fachbereich

SAS Analytics bringt SAP HANA in den Fachbereich Pressemitteilung Hamburg, 08. November 2013 SAS Analytics bringt SAP HANA in den Fachbereich Ergonomie kombiniert mit Leistungsfähigkeit: die BI-Experten der accantec group geben der neuen Partnerschaft

Mehr

Christian Kurze BI-Praktikum IBM WS 2008/09

Christian Kurze BI-Praktikum IBM WS 2008/09 Einführung in die multidimensionale Datenmodellierung e mit ADAPT BI-Praktikum IBM WS 2008/09 1 Gliederung Einführung multidimensionale Datenmodellierung 1. Multidimensionales Modell BI-Praktikum IBM WS

Mehr

good. better. outperform.

good. better. outperform. good. better. outperform. Analytic mit Oracle BI relational oder besser multidimensional? 8. Oracle BI & DWH Konferenz, 20.03.2013 Dirk Fleischmann Director Business Intelligence & DWH Business Intelligence

Mehr

Business Intelligenceein Überblick

Business Intelligenceein Überblick Exkurs Business Intelligenceein Überblick Folie 1 Januar 06 Literatur Kemper, Hans-Georg; Mehanna, Walid; Unger, Carsten (2004): Business Intelligence: Grundlagen und praktische Anwendungen Eine Einführung

Mehr

Business Performance Management Next Generation Business Intelligence?

Business Performance Management Next Generation Business Intelligence? Business Performance Management Next Generation Business Intelligence? München, 23. Juni 2004 Jörg Narr Business Application Research Center Untersuchung von Business-Intelligence-Software am Lehrstuhl

Mehr

Themenblock: Erstellung eines Cube

Themenblock: Erstellung eines Cube Themenblock: Erstellung eines Cube Praktikum: Data Warehousing und Data Mining Einführung relationale Datenbanken Problem Verwaltung großer Mengen von Daten Idee Speicherung der Daten in Form von Tabellen

Mehr

Bachelor/Master-Thesis (für den Standort Stuttgart) Treiberbasierte Planung

Bachelor/Master-Thesis (für den Standort Stuttgart) Treiberbasierte Planung Bachelor/Master-Thesis (für den Standort Stuttgart) Treiberbasierte Planung Hochschulstudium (Wirtschaftsinformatik oder ein vergleichbarer Studiengang) Fachliche und technische Kenntnisse im Bereich Business

Mehr

Mit Excel Know-how webbasierte BI- Applikationen erstellen #MobileBI Business Driven Intelligence

Mit Excel Know-how webbasierte BI- Applikationen erstellen #MobileBI Business Driven Intelligence Mit Excel Know-how webbasierte BI- Applikationen erstellen #MobileBI Jochen Heßler, 16.03.2015 2002 Gegründet in Freiburg, Deutschland 2002 Heute Büros in Freiburg, Frankfurt, Düsseldorf, Paris, Boston

Mehr

Strategisches Informationsmanagement auf Basis von Data Warehouse-Systemen

Strategisches Informationsmanagement auf Basis von Data Warehouse-Systemen Strategisches Informationsmanagement auf Basis von Data Warehouse-Systemen SAS PharmaHealth & Academia Gabriele Smith KIS-Tagung 2005 in Hamburg: 3. März 2005 Copyright 2003, SAS Institute Inc. All rights

Mehr

S A P B W O N H A N A P R O O F O F C O N C E P T B E I S. O L I V E R

S A P B W O N H A N A P R O O F O F C O N C E P T B E I S. O L I V E R S A P B W O N H A N A P R O O F O F C O N C E P T B E I S. O L I V E R S T E F A N M A R K 07.07.2015 F O L I E 1 V O N 2 7 F I R M E N P O R T R A I T S. O L I V E R GESCHICHTE F O L I E 2 V O N 2 7 F

Mehr

GESCHÄFTSSTELLENERÖFFNUNG HAMBURG, 25. APRIL 2013

GESCHÄFTSSTELLENERÖFFNUNG HAMBURG, 25. APRIL 2013 OSC Smart Integration GmbH SAP Business One GOLD-Partner in Norddeutschland GESCHÄFTSSTELLENERÖFFNUNG HAMBURG, 25. APRIL 2013 SAP Business One v.9.0 Heiko Szendeleit AGENDA OSC-SI 2013 / SAP Business One

Mehr

In-Memory Analytics. Marcel Poltermann. Fachhochschule Erfurt. Informationsmanagement

In-Memory Analytics. Marcel Poltermann. Fachhochschule Erfurt. Informationsmanagement Marcel Poltermann Fachhochschule Erfurt Informationsmanagement Inhaltsverzeichnis Glossar...III Abbildungsverzeichnis...III 1 Erläuterung:... 2 2 Technische Grundlagen... 2 2.1 Zugriff physische Datenträger:...

Mehr

Datenintegration mit Informatica PowerCenter

Datenintegration mit Informatica PowerCenter Datenintegration mit Informatica PowerCenter Mein Weg vom Studenten zum Consultant Christoph Arnold 03.07.2013 1 Agenda Von der THM zu Infomotion Datenschieberei oder doch mehr? Die weite Welt von Informatica

Mehr

Kapitel 4: Data Warehouse Architektur

Kapitel 4: Data Warehouse Architektur Data Warehousing, Motivation Zugriff auf und Kombination von Daten aus mehreren unterschiedlichen Quellen, Kapitel 4: Data Warehousing und Mining 1 komplexe Datenanalyse über mehrere Quellen, multidimensionale

Mehr

Was ist Analyse? Hannover, CeBIT 2014 Patrick Keller

Was ist Analyse? Hannover, CeBIT 2014 Patrick Keller Was ist? Hannover, CeBIT 2014 Patrick Keller Business Application Research Center Historie 1994: Beginn der Untersuchung von Business-Intelligence-Software am Lehrstuhl Wirtschaftsinformatik der Universität

Mehr

MHP BI Optimization Solution Ihre Lösung für einen maximalen Return on Investment Ihrer SAP BW Systemlandschaft!

MHP BI Optimization Solution Ihre Lösung für einen maximalen Return on Investment Ihrer SAP BW Systemlandschaft! MHP BI Optimization Solution Ihre Lösung für einen maximalen Return on Investment Ihrer SAP BW Systemlandschaft! Business Solutions 2015 Mieschke Hofmann und Partner Gesellschaft für Management- und IT-Beratung

Mehr

Non-Profit-Organisationen: Vom Controlling zum Strategischen Management

Non-Profit-Organisationen: Vom Controlling zum Strategischen Management Non-Profit-Organisationen: Vom Controlling zum Strategischen Management Einordnung der Begriffe Business Intelligence Strategic Association Management Controlling and Data Warehousing Data Mining, Knowledge

Mehr

Business Intelligence Aufgabenstellung

Business Intelligence Aufgabenstellung Hochschule Darmstadt Business Intelligence (BI) Fachbereich Informatik Praktikum 2 Prof. Dr. C. Wentzel Dipl. Inf. Dipl. Math. Y. Orkunoglu Sebastian Gobst Änderung: 15.06.2012 Datum: 30.05.2012 1. Einführung

Mehr

Eine Einführung in OLAP

Eine Einführung in OLAP Eine Einführung in OLAP Einleitung... 1 Wofür wird OLAP benötigt?... 1 Was ist OLAP?... 3 OLAP Charakteristika... 3 Dimensionen... 3 Hierarchien... 3 Flexible Präsentation... 4 OLAP und Data Warehousing...

Mehr

Möglichkeiten der E-Mail- Archivierung für Exchange Server 2010 im Vergleich

Möglichkeiten der E-Mail- Archivierung für Exchange Server 2010 im Vergleich Möglichkeiten der E-Mail- Archivierung für Exchange Server 2010 im Vergleich Seit Microsoft Exchange Server 2010 bieten sich für Unternehmen gleich zwei mögliche Szenarien an, um eine rechtskonforme Archivierung

Mehr

SAP Support On Demand - IBMs kombiniertes Service-Angebot für SAP Hosting und SAP Application Management Services (AMS)

SAP Support On Demand - IBMs kombiniertes Service-Angebot für SAP Hosting und SAP Application Management Services (AMS) (IGS) SAP Support On Demand - IBMs kombiniertes Service-Angebot für SAP Hosting und SAP Application Services (AMS) Martin Kadner, Product Manager SAP Hosting, GTS Klaus F. Kriesinger, Client Services Executive,

Mehr

Experten für CRM und BI seit über 10 Jahren. Analytische CRM Lösungen im Vergleich

Experten für CRM und BI seit über 10 Jahren. Analytische CRM Lösungen im Vergleich Experten für CRM und BI seit über 10 Jahren Analytische CRM Lösungen im Vergleich Kernaussagen Analytische CRM Lösungen Analyse- und Reportmöglichkeiten bestehender CRM- Systeme können den Managementanforderungen

Mehr

2. Microsoft Innovationstag Nord Integrierte Lösungen in der Öffentlichen Verwaltung

2. Microsoft Innovationstag Nord Integrierte Lösungen in der Öffentlichen Verwaltung 2. Microsoft Innovationstag Nord Integrierte Lösungen in der Öffentlichen Verwaltung Reporting, Analyse und Data Mining André Henkel, initions AG 22. und 23. Oktober 2013 in Hamburg

Mehr

Survival Guide für Ihr Business Intelligence-Projekt

Survival Guide für Ihr Business Intelligence-Projekt Survival Guide für Ihr Business Intelligence-Projekt Sven Bosinger Solution Architect BI Survival Guide für Ihr BI-Projekt 1 Agenda Was ist Business Intelligence? Leistungsumfang Prozesse Erfolgsfaktoren

Mehr

Social Media trifft Business

Social Media trifft Business Social Media trifft Business Intelligence Social Media Analysis als Teil der Unternehmenssteuerung Tiemo Winterkamp, VP Global Marketing Agenda Social Media trifft Business Intelligence Business Intelligence

Mehr

EXASOL AG Zahlen & Fakten

EXASOL AG Zahlen & Fakten Big Data Management mit In-Memory-Technologie EXASOL AG Zahlen & Fakten Name: EXASOL AG Gründung: 2000 Tochterges.: Management: Produkte: Firmensitz: Niederlassung: EXASOL Cloud Computing GmbH Steffen

Mehr

1 Einführung. Unbekannte Begriffe: Business Intelligence, Knowledge Management, Unternehmensportale, Information Warehouse.

1 Einführung. Unbekannte Begriffe: Business Intelligence, Knowledge Management, Unternehmensportale, Information Warehouse. 1 Einführung mysap Business Intelligence stellt mit Hilfe von Knowledge Management die Verbindung zwischen denen, die etwas wissen und denen, die etwas wissen müssen her. mysap Business Intelligence integriert

Mehr

DATA WAREHOUSE. Big Data Alfred Schlaucher, Oracle

DATA WAREHOUSE. Big Data Alfred Schlaucher, Oracle DATA WAREHOUSE Big Data Alfred Schlaucher, Oracle Scale up Unternehmensdaten zusammenfassen Noch mehr Informationen aus Unternehmens- Daten ziehen! Datenmengen, Performance und Kosten Daten als Geschäftsmodell

Mehr

SAP BW + Microsoft Excel Viel genutzt, oft unterschätzt

SAP BW + Microsoft Excel Viel genutzt, oft unterschätzt Corporate Performance Management SAP BW + Microsoft Excel Viel genutzt, oft unterschätzt Martin Krejci, Manager CPM Matthias Schmidt, BI Consultant Kristian Rümmelin, Senior BI Consultant Braincourt GmbH

Mehr

PRESSE-INFORMATION BUSINESS INTELLIGENCE PROFITIERT VON NEUEN TECHNOLOGIEN

PRESSE-INFORMATION BUSINESS INTELLIGENCE PROFITIERT VON NEUEN TECHNOLOGIEN PRESSE-INFORMATION BI-13-09-13 BUSINESS INTELLIGENCE PROFITIERT VON NEUEN TECHNOLOGIEN Business Analytics und Business Performance Management sind wesentliche Wachstumstreiber Mittelstand ist bedeutende

Mehr