WIRTSCHAFTSUNIVERSITÄT WIEN BAKKALAUREATSARBEIT

Transkript

1 WIRTSCHAFTSUNIVERSITÄT WIEN BAKKALAUREATSARBEIT Titel der Bakkalaureatsarbeit: Einsatz von Data Warehousing und OLAP im Bereich der Konjunkturstatistik im produzierenden Bereich Englischer Titel der Bakkalaureatsarbeit: Deployment of Data Warehouse and OLAP in the range of short-term statistics in manufacturing Verfasserin/Verfasser: Christoph Koller Matrikel-Nr.: Studienrichtung: Kurs: Textsprache: Betreuerin/Betreuer: Unternehmen/Betreuer: J Bakkalaureat Wirtschaftsinformatik 0924 IT-Praktikum mit Bachelorarbeit Deutsch Dr. David Meyer WKÖ Stabsabteilung Statistik / MMag. Roland Vögel Ich versichere: dass ich die Bakkalaureatsarbeit selbstständig verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt und mich auch sonst keiner unerlaubten Hilfe bedient habe. dass ich die Ausarbeitung zu dem obigen Thema bisher weder im In- noch im Ausland (einer Beurteilerin/ einem Beurteiler zur Begutachtung) in irgendeiner Form als Prüfungsarbeit vorgelegt habe. dass diese Arbeit mit der vom Betreuer beurteilten Arbeit übereinstimmt. Datum Unterschrift 1

2 Einsatz von Data Warehousing und OLAP im Bereich der Konjunkturstatistik im produzierenden Bereich Deployment of Data Warehouse and OLAP in the range of shortterm statistics in manufacturing Stichworte: Data Warehouse, OLAP, Datenmodell, Business Intelligence (BI) Keywords: Data Warehouse, OLAP, Data Model, Business Intelligence (BI) Zusammenfassung Die vorliegende Arbeit befasst sich mit dem Einsatz von Data Warehousing und OLAP (Online Analytical Processing). Im ersten Schritt werden drei BI-Lösungen vorgestellt und es wird untersucht, welches Produkt sich für die praktische Umsetzung am besten eignet. Das erarbeitete Datenmodell wird in das Data Warehouse übergeführt und mittels OLAP-Engine werden vordefinierte Abfragen erstellt. Abstract The document deals with the deployment of Data Warehouse and OLAP. In the first chapter three BI-solutions will be introduced and tested, to find the product which is the best for implementation. The finished data model will be transferred to the Data Warehouse and predefined queries will be generated per OLAP-Engine. 2

3 Inhaltsverzeichnis Inhaltsverzeichnis... 3 Abbildungsverzeichnis... 5 Tabellenverzeichnis Einleitung Motivation Zusammenfassung der Daten des Projekts Data Warehouse und Online Analytical Processing (OLAP) Entwurfsphasen eines Data Warehouse Komponenten eines Data Warehouse Multidimensionales Konzept Online Analytical Processing (OLAP) Vergleich einzelner Softwareprodukte (BI-Lösungen) Microsoft SQL Server 2005 Enterprise Edition Datenbankmodul Integration Services Analysis Services Reporting Services Pentaho BI Suite Data Integration Kettle Analysis Mondrian Data Mining Weka Reporting JFreeReport Oracle Business Intelligence Enterprise Edition (OBIEE) Oracle BI Server Oracle BI Presentation Service Oracle BI Publisher Vergleich der Business Intelligence Lösungen Praktische Umsetzung mittels Microsoft SQL Server Anforderungsanalyse und Entwürfe Physisches Datenmodell Erstellen des Data Warehouse OLAP-Cube Erstellen eines Analysis Services-Projekt Bericht Erstellen eines Reporting Services-Projekt Fazit und Ausblick Quellenverzeichnis

4 Anhang Quellcode

5 Abbildungsverzeichnis Abbildung 1 Entwurfsphasen eines DW nach Kimball Abbildung 2 Komponenten eines Data Warehouse [KiRo02] Abbildung 3 Architekturmodell eines DW Abbildung 4 Multidimensionales Datenmodell - OLAP-Cube Abbildung 5 Beziehungen zwischen SQL Server 2005-Komponenten [Micr05] Abbildung 6 Integration Services und ihre Schlüsselkomponenten [Micr05] Abbildung 7 Kommunikation auf mittlerer Ebene [Micr05] Abbildung 8 Pentaho Open BI-Suite [vgl Abbildung 9 Pentaho Server Architektur [vgl. Pent06] Abbildung 10 Grafische ETL-Oberfläche [Pent08b] Abbildung 11 Mondrian als OLAP-Engine [vgl. HeKl07] Abbildung 12 Analysis View in der Pentaho User Console [Pent08c] Abbildung 13 Logisches Datenmodell Starschema Abbildung 14 Datenbanksicht Abbildung 15 Logisches Datenmodell Abbildung 16 ETL-Control Flow Abbildung 17 Data-Flow eines der ETL-Pakete Abbildung 18 Sicht auf die Faktentabelle mit Daten Abbildung 19 Data Source View innerhalb der Analysis Services Abbildung 20 Neue Kennzahlen werden berechnet Abbildung 21 Auswertung im Stile einer Pivot-Tabelle Abbildung 22 Generierter Bericht in den Reporting Services Abbildung 23 Darstellung im Browser

6 Tabellenverzeichnis Tabelle 1 Zusammenfassung der Projektdaten... 8 Tabelle 2 12 Regeln nach Codd Tabelle 3 BI-Komponenten und deren OS-Projekte Tabelle 4 Übersicht der Softwarelösungen - Meine Einschätzung Tabelle 5 Auflistung der Entitäten Tabelle 6 Dimensionstabelle dim_bundesland

7 1 Einleitung 1.1 Motivation Die Stabsabteilung Statistik der Wirtschaftskammer Österreich stellt der Wirtschaftskammerorganisation eine Vielzahl von Daten zur Verfügung. Als Mitarbeiter dieser Abteilung werde ich deshalb tagein tagaus mit statistischen Daten konfrontiert. Der Aufgabenschwerpunkt meiner Tätigkeit liegt in der Verarbeitung und Bereitstellung von Daten im Bereich der Konjunkturstatistik im produzierenden Bereich (KJSTiPB). Die Daten werden monatlich von Statistik Austria übermittelt. Über werden uns diese Daten im CSV-Format zur Verfügung gestellt. Dabei handelt es sich um fünf verschiedene Dateien. Diese gliedern sich wie folgt: Daten nur für Österreich nach Kammersystematik (Industrie und Gewerbe) Daten für Österreich und die Bundesländer nach Kammersystematik (nur Industrie) Daten für Österreich und die Bundesländer nach ÖNACE 2003 (auf 2-Steller Ebene) Daten nur für Österreich nach ÖNACE 2003 (auf 4-Steller Ebene) Daten nur für Österreich nach Kammersystematik (Fachverband Druck) Zur Verarbeitung der CSV-Dateien werden diese zuerst in EXCEL bereinigt (Leerzeichen werden eliminiert). Die weitere Bearbeitung erfolgt über eine ACCESS- Datenbank, die von seitens der Stabsabteilung Statistik aufgebaut wurde. Danach werden die bereinigten Zahlen mittels Copy+Paste in die dazugehörige Ablagetabelle nach ACCESS (4 an der Zahl) gespeichert. Für die weitere Verarbeitung wurden zwei Module geschrieben (Visual Basic Applikation), die über die Schaltflächen Daten einlesen und Daten aktualisieren ausgeführt werden. Nach diesem Prozedere erhalten wir neue Tabellen in ACCESS, die nun nach EXCEL exportiert werden. Die EXCEL-Dateien werden in einen Upload-Bereich geladen. Die dazugehörigen Download-Links werden per Mail an die Adressaten der KJSTiPB verschickt. 7

8 Um einerseits jedem Benutzer die gleiche Grundlage zu bieten und andererseits mit dem Zeitalter der Online-Dienste zu gehen, wird der Einsatz von Data Warehouse und OLAP im Bereich der Konjunkturstatistik im Produzierenden Bereich angedacht. Das nachfolgende Kapitel 2 beschäftigt sich mit der Theorie zu Data Warehouse und OLAP. Im Kapitel 3 werden einzelne Softwarelösungen vorgestellt, die für den Einsatz im Bereich Data Warehouse und OLAP bestimmt sind. Dabei werden die Vorgehensweisen erklärt und zum Schluss wird eine Bewertung durchgeführt. Die praktische Umsetzung mittels ausgewählter Software wird in Kapitel 4 erläutert und Kapitel 5 gewährt einen kleinen Ausblick auf weitere Vorhaben und bietet noch Platz für ein abschließendes Fazit. 1.2 Zusammenfassung der Daten des Projekts Projektname Autor Semester Universitärer Betreuer Betreuendes Unternehmen Ansprechpartner Unternehmen Einsatz von Data Warehouse und OLAP im Bereich der Konjunkturstatistik im Produzierenden Bereich Christoph Koller (h ) christoph.koller@wko.at WS2008/2009 Dr. David Meyer Wirtschaftskammer Österreich Stabsabteilung Statistik Wiedner Hauptstraße 76/5. Stock 1045 Wien MMag. Roland Vögel Projektstart Oktober 2008 Projektende Jänner 2009 Projektinhalt (Zusammenfassung) Business-Intelligence-Lösungen auswählen und testen, Datenmodell erstellen und ins Data Warehouse überführen, Daten mittels vordefinierter Abfragen bereitstellen (OLAP- Engine) Tabelle 1 Zusammenfassung der Projektdaten 8

9 2 Data Warehouse und Online Analytical Processing (OLAP) Im nachfolgenden Kapitel werden die Entwurfsphasen eines Data Warehouse vorgestellt, die bei der Systementwicklung durchlaufen werden. Die Komponenten eines Data Warehouse werden erklärt, um diese effizient einsetzen zu können und am Ende des Kapitels folgt ein theoretischer Teil zum multidimensionalen Konzept (OLAP). 2.1 Entwurfsphasen eines Data Warehouse In der Literatur der Informatik bilden die nachfolgenden fünf Phasen die Basis sämtlicher Vorgehensmodelle der Systementwicklung, speziell der Softwareentwicklung [vgl. BeSt04]: Analyse und Definition, Entwurf bzw. Design, Implementation und Integration, Test und Abnahme Wartung und Anpassung Dies entspricht auch der Vorgehensweise, wie sie bei der Entwicklung von Data- Warehouse-Systemen verwendet wird. Dabei unterscheiden sich jedoch die verwendeten Techniken in den unterschiedlichen Phasen zum Teil grundlegend im Vergleich zu denen, die in der traditionellen Entwicklung von Softwaresystemen eingesetzt werden. 9

10 Abbildung 1 Entwurfsphasen eines DW nach Kimball Abbildung 1 beschreibt die einzelnen Phasen der Data-Warehouse-Realisierung, wie sie von Kimball in [vgl. KiRo96] beschrieben wurde. Ausgehend von den Datenbankschemata der operativen Daten, wird zunächst eine Anforderungsanalyse und spezifikation des Data Warehouse erstellt. Hiervon abgeleitet wird ein logisches Schema, zum Beispiel ein Star-Schema, erstellt und anschließend der physische Entwurf durchgeführt. Abschließend wird der physische Entwurf implementiert. 2.2 Komponenten eines Data Warehouse Wie in Abbildung 2 ersichtlich, gibt es vier Komponenten wie in [KiRo02] beschrieben, aus denen ein Data Warehouse aufgebaut ist, den Operational Source Systems, der Data Staging Area, der Data Presentation Area und den Data Access Tools. 10

11 Abbildung 2 Komponenten eines Data Warehouse [KiRo02] Die Daten aus den Quellsystemen durchlaufen mehrere Stufen bevor sie schließlich für die Berichtsabfrage zur Verfügung stehen. Operational Source Systems Die Quellsysteme können sowohl operative Systeme, andere externe Quellen als auch weitere Data Warehouse-Systeme sein. In unserem Fall sind das die Access- Datenbank und die monatlichen zugesandten CSV-Files. Die Daten aus der Access- Datenbank werden zur Gänze übernommen, dh das auf der Data Staging Area nur ein ETL-Paket (extract-transformation-load) erstellt werden muss, da der Aufbau der CSV-Files und der Tabellen aus der Access-Datenbank identisch ist. Data Staging Area Die Data Staging Area ist einerseits ein Speicherbereich und andererseits wird auf der Data Staging Area eine Menge an Prozessen durchgeführt (ETL-Prozess). Der Extraktor (extract) ist die Schnittstelle zwischen den operativen Systemen, sowie anderen externen Quellen, und dem Data Warehouse. Die Aufgabe des Extraktors ist die Auswahl und Beschaffung der Daten aus den Quellsystemen. Dieser stellt die Daten der Transformationsschicht zur weiteren Bearbeitung zur Verfügung. Die Transformationsschicht (innerhalb der Data Staging Area) ist für die Integrität der Daten verantwortlich. Hier werden die enthaltenen Daten geprüft, vereinheitlicht, umgewandelt und verdichtet. Der Bereich Laden (load) ist schließlich für die Weitergabe an die entsprechenden Datenziele und für die Überwachung der Ladeprozesse zuständig. 11

12 Data Presentation Area Die Data Presentation Area ist für die Speicherung der globalen Informationen verantwortlich. Hier werden die integrierten Daten der verschiedenen Ladeprozesse aus den unterschiedlichsten Quellen vereint und unveränderlich abgespeichert. Im Laufe der Zeit sammelt sich so ein umfangreicher historischer Datenbestand an. Dieser wiederum dient als zentrale Datenbasis für alle übergeordneten Reportinganwendungen (Data Access Tools), in der schon Vorberechnungen und Aggregationen stattgefunden haben können. Data Access Tools Die Data Access Tools sind die letzte Kernkomponente in der Data Warehouse Umgebung. Diese ermöglichen erst den Zugang zu den Daten auf der Presentation Area, wo die Daten in einem multidimensionalen Datenmodell abgelegt sind und welches für Analysetätigkeiten optimiert wurde. In Abbildung 3 ersichtlich gibt es zusätzliche Bereiche, die für einen Aufbau eines Data Warehouse wichtig sind, wie z.b. das Metadaten-Repository. Das Metadaten- Repository enthält alle Informationen zu den im Data Warehouse enthaltenen Informationen. Es beschreibt die einzelnen Felder des Extraktor ebenso wie den Aufbau des Reporting-Cubes (z.b. Aufbau einer Struktur, Feldlänge und typ). Abbildung 3 Architekturmodell eines DW 12

13 Bei der Entwicklung eines Data Warehouse können mehrere Ansätze verfolgt werden, jedoch bedient man sich idealerweise folgender: Top down Es wird vom Allgemeinen das Spezielle entwickelt. Bottom up Es wird vom Speziellen das Allgemeine abgeleitet. In unserem Fall handelt es sich daher um eine Top down Entwicklung, dh basierend auf einem zentralen Data Warehouse werden die Data Marts 1 erstellt. 2.3 Multidimensionales Konzept Online Analytical Processing (OLAP) Der Begriff wurde erstmalig im September 1993 in einem White Paper von E.F. Codd, S.B. Codd und C.T. Sally geprägt. Die Autoren prüfen in diesem Paper die Frage, inwieweit herkömmliche relationale Datenbanken und die damit verbundene Abfragesprache SQL geeignet sind, eine multidimensionale Datenanalyse zu leisten. Unter einer multidimensionalen Analyse verstehen sie vor allem, Daten zu konsolidieren, in unterschiedlicher Weise darzustellen und so zu analysieren, dass dies für verschiedene Personen im Unternehmen einen Sinn ergibt. Anstelle des Begriffs multidimensionaler Datenanalyse schlagen sie den Begriff OLAP vor, der nach ihrer Meinung die multidimensionale Datenanalyse als ein Feature neben anderen enthält. Schaut man in die Veröffentlichungen der letzten Jahre, so werden die beiden Begriffe multidimensional bzw. OLAP weitgehend synonym verwendet [vgl. ABDe06]. Weiters wurde der Begriff OLAP in diesem White Paper durch 12 Regeln präzisiert (siehe Tabelle 2): Grundlegende Anforderungen Multidimensionalität Intuitive Datenanalyse Zugriffsmöglichkeit Transparenz Dimensionsverwaltung Einheitliche Struktur und Funktionalität der Datendimensionen Unbeschränkte Durchführung dimensions- 1 spezialisierte analytische Datenbank für bestimmte Fachbereiche 13

14 Berichtsgenerierung Physikalische Aspekte übergreifender Operationen Unbegrenzte Anzahl von Verdichtungsebenen und Dimensionen Konsistentes Antwortzeitverhalten Flexible Berichtsgenerierung Client-Server-Architektur Mehrbenutzerunterstützung Dynamische Handhabung dünn besiedelter Matrizen Tabelle 2 12 Regeln nach Codd Online Analytical Processing zählt zu den Methoden der analytischen Informationssysteme. OLAP-Systeme beziehen ihre Daten entweder aus den operationalen Datenbeständen eines Unternehmens oder aus einem Data Warehouse (Datenlager). Im Gegensatz zum Online-Transaction-Processing (OLTP) steht hier die Durchführung komplexer Analysevorhaben im Vordergrund, welche ein sehr hohes Datenaufkommen verursachen. Das Ziel ist, durch multidimensionale Betrachtung dieser Daten ein entscheidungsunterstützendes Analyseergebnis zu gewinnen. OLAP ermöglicht auch ungeübten Benutzern, d.h. ohne besondere Abfrage- oder Berichtssprachekenntnis (z.b. SQL), flexible und mehrdimensionale Ad-hoc-Abfragen. Grundlegende Merkmale des multidimensionalen Konzepts sind daher Dimensionen, Fakten (Measures), Hierarchie und Cube. Legen wir nun dieses Konzept auf die Abbildung 4 um, so haben wir drei Dimensionen (Produkt, Zeitraum, Region), eine Faktentabelle (Kennzahlen, enthält Umsatz, Beschäftigte z.b.) und innerhalb der Dimensionen eventuell Hierarchien (Zeitraum aufgegliedert in Jahr Quartal Monat Woche Tag oder die Region in Welt Kontinente Land Bundesland Bezirk Gemeinde Ort als Bespiel). Aus Dimensionen und Fakten lässt sich die OLAP zugrunde liegende Struktur bilden, welches ein multidimensionaler OLAP-Cube ist, der aus dem Data Warehouse erstellt wurde. 14

15 Abbildung 4 Multidimensionales Datenmodell - OLAP-Cube Wenn für jede Dimension nur eine Tabelle vorgesehen ist, die jeweils alle Hierarchieebenen berücksichtigt, und jede Dimensionstabelle direkt mit der Faktentabelle verbunden ist wie dies für Abbildung 10 auf Seite 31 zutrifft -, wird dies als Star-Schema bezeichnet. In diesem Fall liegen die Werte in den Dimensionstabellen in denormalisierter 2 Form vor. Es sind aber auch andere Schemata möglich und praktikabel, beispielsweise das Snowflake-Schema oder das Galaxy-Schema. OLAP Tools zeichnen sich durch ihre Browsing-Fähigkeit aus. Unter Browsing lassen sich folgende Aktivitäten zusammenfassen: Filtern Drill Down und Roll Up Detaillierung bzw. Zusammenfassung entlang einer Dimension Slicing and Dicing weitere Dimensionen auswählen bzw. abwählen Drilling Across Zugriff auf mehrere Data Marts Drilling Through Detailzugriff auf operative Datenbanken Pivoting Austauschen von Zeilen und Spalten 2 bewusste Rücknahme einer Normalisierung zum Zweck der Verbesserung des Laufzeitverhaltens einer Datenbankanwendung 15

16 Im Aufbau der Datenbereithaltung werden zwei Klassen von OLAP Software unterschieden. ROLAP (Relationales OLAP) ROLAP zeigt eine Teilmenge der Objektdaten eines relationalen Datenbanksystems. Ihre Mehrdimensionalität wird über die Metadaten abgebildet. ROLAP-Tools profitieren von der Kompatibilität und Flexibilität relationaler Datenbanksysteme. ROLAP greifen direkt auf die Data-Mart- bzw. Data Warehousedaten zu, die am Server liegen. Dadurch entstehen keine zusätzlichen Ladetätigkeiten. Nachteil liegt in der schlechten Abfrageeffizienz (Problem: Joins über mehrere Tabellen notwendig). Daher empfiehlt sich ROLAP für Fälle, in denen es um sehr große Datenmengen geht, auf die nicht sehr häufig mit Abfragen zugegriffen wird. MOLAP (Multidimensionales OLAP) Bei MOLAP sind die Objektdaten mehrdimensional und werden von einem mehrdimensionalen Datenbanksystem verwaltet, das die meisten Abfragen vorberechnet, jedoch können MOLAP-Cubes sehr groß werden. MOLAP sind folglich abfrageeffizienter, jedoch bedarf dies langer Ladezeiten (thin client 3 ). Daher ist MOLAP im Allgemeinen am besten für kleine Cubes geeignet, auf die häufig zugegriffen wird und die eine kurze Antwortzeit brauchen. Jedes dieser beiden Konzepte hat, wie gezeigt, Vor- und Nachteile. Daher wird von verschiedenen Anbietern neuerdings ein Speicherkonzept angeboten, das eine Mischung von MOLAP und ROLAP darstellt. Da dieses Konzept keine reine Form ist, wird es als hybrides OLAP bezeichnet, Kurzform HOLAP. HOLAP (Hybrides OLAP) Die HOLAP-Methode verbindet Merkmale der beiden Methoden MOLAP und ROLAP, um den besten Kompromiss aus diesen beiden Verfahren zu finden: Die aggregierten Daten werden vorberechnet und im multidimensionalen Cube gespeichert, während die Detaildaten im relationalen Data Warehouse verbleiben. Wenn daher Abfragen gestartet werden, die auf aggregierte Daten zugreifen, entspricht HOLAP der MOLAP-Methode, bei Zugriffen auf Detaildaten dagegen der ROLAP-Methode. HOLAP-Cubes sind stets kleiner als MOLAP-Cubes, aber größer 3 die Daten werden am Server gespeichert Gegenteil fat client, wo die Daten am Client gespeichert sind 16

17 als ROLAP-Cubes. Die HOLAP-Methode empfiehlt sich für Situationen, die kurze Antwortzeiten für den Zugriff auf aggregierte Daten, die auf einer großen Menge von Detaildaten basieren, verlangen [vgl. ABDe06]. Die praktische Umsetzung der Theorie zu Data Warehousing und OLAP wird in Kapitel 4 durchgeführt. Das nachfolgende Kapitel 3 befasst sich mit dem Vergleich von Softwarelösungen im Bereich Business Intelligence. 17

18 3 Vergleich einzelner Softwareprodukte (BI-Lösungen) Am Business-Intelligence-Markt gibt es eine Vielzahl an Softwarelösungen, die für meine Bachelorarbeit interessant wären. Um den Umfang dieser Arbeit jedoch nicht zu sprengen, wurden folgenden BI-Lösungen ausgewählt: Microsoft SQL Server 2005 Enterprise Edition Oracle Business Intelligence Enterprise Edition Pentaho BI Suite Diese werden in weiterer Folge beschrieben und zu guter Letzt wird entschieden, welches Produkt für die praktische Umsetzung genommen wird. 3.1 Microsoft SQL Server 2005 Enterprise Edition Die Datenbankplattform Microsoft SQL Server 2005 wird für den umfangreichen Einsatz von Data Warehousing- und E-Commerce Anwendungen eingesetzt. Microsoft SQL Server 2005 ist außerdem eine Business Intelligence-Plattform für Datenintegrations-, Analyse- und Berichtslösungen und setzt sich aus folgenden Komponenten zusammen, die sich auch einzeln einsetzen lassen: Datenbankmodul Integration Services Analysis Services Reporting Services Notification Services Replikation Service Broker Volltextsuche 18

19 Abbildung 5 Beziehungen zwischen SQL Server 2005-Komponenten [Micr05] Die Kernkomponenten (siehe Abbildung 5) sind das Datenbankmodul, Integration Services, Analysis Services und Reporting Services, die auf den folgenden Seiten näher erläutert werden. Microsoft stellt beim SQL Server 2005 neue Entwicklungsumgebungen zur Verfügung, die bei Entwicklungs- und Verwaltungsaufgaben helfen: SQL Server Management Studio und Business Intelligence Development Studio. Im Management Studio werden SQL Server-Datenbankmodul- und Benachrichtigungslösungen entwickelt und verwaltet. Des Weiteren werden bereitgestellte Analysis Services- Lösungen und Integration Services-Pakete verwaltet und ausgeführt. Auch Reporting Services-Berichte und Berichtsmodelle werden im Management Studio betreut. In BI Development Studio werden Business Intelligence-Lösungen mithilfe von Analysis Services-Projekten entwickelt, um Cubes, Dimensionen und Miningstrukturen zu entwickeln, mithilfe von Reporting Services-Projekten, um Berichte zu erstellen, mithilfe des Berichtsmodellprojekts, um Modelle für Berichte zu definieren, und mithilfe von Integration Services-Projekten, um Pakete zu erstellen. In den Studio-Umgebungen bietet SQL Server 2005 die notwendigen grafischen Tools zum Entwerfen, Entwickeln, Bereitstellen und Verwalten von relationalen Datenbanken, analytischen Objekten, Datentransformationspaketen, Replikationstopologien, Berichtsservern und Berichten sowie Benachrichtigungsservern. 19

20 Die einzelnen Komponenten können als selbständige Einheiten, als integrierte SQL- Server-Komponenten oder als integrierte Komponenten in externen Anwendungen betrieben werden [vgl. Micr05] Datenbankmodul Das Datenbankmodul ist der Kerndienst zum Speichern, Verarbeiten und Sichern von Daten. Es ermöglicht einen gesteuerten Zugriff und eine schnelle Transaktionsverarbeitung, um auch den Anforderungen der anspruchsvollsten Datenverarbeitungsanwendungen im Unternehmen gerecht zu werden. Das Datenbankmodul wird verwendet, um relationale Datenbanken für OLTP- (Online Transactional Processing, Onlinetransaktionsverarbeitung) oder OLAP-Daten (Online Analytical Processing, Analytische Onlineverarbeitung) zu erstellen. Dazu gehört das Erstellen von Tabellen zur Datenspeicherung und von Datenbankobjekten, wie z. B. Indizes, Sichten und gespeicherte Prozeduren, zum Anzeigen, Verwalten und Sichern von Daten [vgl. Micr05] Integration Services SQL Server 2005 Integration Services (SSIS) ist die ETL-Komponente (Extract, Transform and Load - Extrahieren, Transformieren und Laden) von SQL Server Damit wurde die frühere ETL-Komponente von SQL Server, Data Transformation Services (DTS), ersetzt. Integration Services besteht aus vier Schlüsselkomponenten: dem Integration Services-Dienst, dem Integration Services-Objektmodell, dem Integration Services- Runtime Engine und den ausführbaren Dateien zur Laufzeit sowie dem Datenflusstask, der das Datenflussmodul und die Datenflusskomponenten kapselt (siehe Abbildung 6). 20

21 Abbildung 6 Integration Services und ihre Schlüsselkomponenten [Micr05] Integration Services ist eine Plattform zum Erstellen von Datenintegrations- und Datentransformationslösungen. Die Integration Services werden verwendet, um komplexe Unternehmensprobleme durch Kopieren oder Downloaden von Dateien, Senden von -Nachrichten als Antwort auf Ereignisse, Aktualisieren von Data Warehouses, Bereinigen von Daten und Data Mining sowie Verwalten von SQL Server-Objekten und -Daten zu lösen. Die Pakete können allein oder gemeinsam mit anderen Paketen für komplexe Unternehmensanforderungen verwendet werden. Integration Services kann Daten aus einer Vielzahl von Quellen, wie z. B. XML- Datendateien, Flatfiles und relationalen Datenquellen, extrahieren und transformieren und die Daten dann in ein oder mehrere Ziele laden. Integration Services enthält eine Vielzahl integrierter Tasks und Transformationen, Tools zum Erstellen von Paketen und den Integration Services-Dienst zum Ausführen 21

22 und Verwalten von Paketen. Die grafischen Integration Services-Tools können verwenden werden, um Lösungen zu erstellen, ohne eine einzige Codezeile schreiben zu müssen. Weiters kann das umfangreiche Integration Services- Objektmodell programmiert werden, um Pakete programmgesteuert zu erstellen und benutzerdefinierte Tasks sowie andere Paketobjekte zu codieren [vgl. Micr05] Analysis Services Analysis Services ist der zentrale Dienst zum Unterstützen der schnellen Analyse von Geschäftsdaten, der OLAP- (Online Analytical Processing) und Data Mining- Funktionalität für Business Intelligence-Anwendungen liefert. OLAP Analysis Services ermöglicht es multidimensionale Strukturen zu entwerfen, zu erstellen und zu verwalten, die Detaildaten und aggregierte Daten aus mehreren Datenquellen, wie z. B. relationalen Datenbanken, in einem einzigen einheitlichen, logischen Modell enthalten, das durch mögliche integrierte Berechnungen unterstützt wird. Basierend auf diesem einheitlichen Datenmodell bietet Analysis Services schnelle, intuitive, Top-Down-Analyse großer Mengen von Daten, das Benutzern in mehreren Sprachen und Währungen geliefert werden kann. Analysis Services kann mit Data Warehouses, Data Marts, Produktionsdatenbanken und Speichern operativer Daten verwendet werden, wobei die Analyse von Verlaufs- und Echtzeitdaten unterstützt wird. Data Mining Analysis Services enthält die Features und Tools, die zum Erstellen komplexer Data Mining-Lösungen benötigt werden. Eine Kombination dieser Features und Tools kann verwenden werden, um Trends und Muster in den Daten zu ermitteln und um intelligente Entscheidungen zu schwierigen Unternehmensproblemen zu treffen. Microsoft SQL Server 2005 Analysis Services (SSAS) unterstützt eine Thin Client- Architektur. Das Analysis Services-Berechnungsmodul ist vollständig serverbasiert, sodass alle Abfragen auf dem Server aufgelöst werden. Daher ist für jede Abfrage nur ein Roundtrip zwischen dem Client und dem Server erforderlich, was zu skalierbarer Leistung führt, wenn die Komplexität der Abfragen zunimmt. SSAS 22

23 unterstützt den führenden OLAP-Standard: die Multidimensional Expression (MDX) Language. Das native Protokoll für Analysis Services ist XMLA (XML for Analysis). Analysis Services stellt mehrere Datenzugriffsschnittstellen für Clientanwendungen zur Verfügung. Diese Komponenten verwenden jedoch alle XMLA für die Kommunikation mit einer Instanz von Analysis Services. Zusammen mit Analysis Services werden mehrere unterschiedliche Anbieter zur Verfügung gestellt, um unterschiedliche Programmiersprachen zu unterstützen. Ein Anbieter kommuniziert mit einem Server mit Analysis Services, indem XMLA in SOAP-Paketen über TCP/IP oder durch Internetinformationsdienste (Internet Information Services, IIS) über HTTP gesendet und empfangen wird. Eine HTTP- Verbindung verwendet ein von IIS instanziiertes COM-Objekt, das als Datapump 4 bezeichnet wird und als Datenleitung für Analysis Services-Daten fungiert. Analysis Services verfügt über eine Webarchitektur mit einer vollständig skalierbaren mittleren Ebene, die sowohl in kleineren als auch in großen Organisationen bereitgestellt werden kann. Analysis Services stellt umfassende Unterstützung auf mittlerer Ebene für Webdienste zur Verfügung. ASP-Anwendungen werden von OLE DB für OLAP und ADO MD unterstützt, ASP.NET-Anwendungen werden von ADOMD.NET unterstützt. Die mittlere Ebene, in Abbildung 7 dargestellt, ist für viele gleichzeitige Benutzer skalierbar [vgl. Micr05]. 4 ein Datapump dient zum Importieren und Exportieren 23

24 Abbildung 7 Kommunikation auf mittlerer Ebene [Micr05] Reporting Services SQL Server 2005 Reporting Services (SSRS) ist eine serverbasierte Berichterstellungsplattform, die umfassende Datenberichtserstellung von relationalen und multidimensionalen Datenquellen bietet. Reporting Services enthält Verarbeitungskomponenten, eine vollständige Reihe von Tools, die zum Erstellen und Verwalten von Berichten verwendet werden können, und eine Anwendungsprogrammierschnittstelle (API, Application Programming Interface), mit der Entwickler Daten- und Berichtsverarbeitung in benutzerdefinierten Anwendungen integrieren und erweitern können. Die Berichte können aus relationalen oder 24

25 multidimensionalen Daten von SQL Server, Analysis Services, Oracle oder jedem beliebigen Microsoft.NET Framework-Datenprovider, wie z. B. ODBC oder OLE DB erstellt werden. Mit Reporting Services ist es möglich, interaktive, tabellarische oder Freiformberichte zu erstellen, die Daten in geplanten Intervallen oder bei Bedarf abzurufen, sobald der Benutzer einen Bericht öffnet. Reporting Services ermöglichen außerdem das Erstellen von Ad-hoc-Berichten basierend auf vordefinierten Modellen und das interaktive Durchsuchen von Daten in dem Modell. Alle Berichte können in Desktopformaten und weborientierten Formaten wie HTML, PDF, CSV und XLS ausgegeben werden. Benutzer können aus einer Vielzahl von Anzeigeformaten auswählen, um Berichte bei Bedarf in geeigneten Formaten zur Datenbearbeitung oder zum Drucken zu rendern. Reporting Services ist eine serverbasierte Lösung und bietet daher die Möglichkeit, die Berichtsspeicherung und -verwaltung zu zentralisieren, den Zugriff auf Berichte, Modelle und Ordner zu sichern, die Verarbeitung und Verteilung von Berichten zu steuern sowie die Verwendung von Berichten im Unternehmen zu standardisieren [vgl. Micr05]. 3.2 Pentaho BI Suite Pentaho wurde von ehemaligen Mitarbeitern der BI-Marktführer Hyperion Solutions, Cognos und SAS Institute im Jahr 2002 in Florida gegründet. Die Pentaho BI Suite ist eine modulare Open Source Lösung, die auf Basis der Programmiersprache Java entwickelt wurde. Die BI Suite integriert die Komponenten für Reporting, Data Mining, OLAP und ETL, welche sich auch einzeln einsetzen lassen. Bestandteile der BI Suite sind die Pentaho BI-Plattform (Pentaho Server, Pentaho Design Studio) und die Pentaho BI-Komponenten (siehe Tabelle 3). Komponente ETL (Data Integration) OLAP (Analysis Service) Data Mining Reporting Open-Source-Projekte Kettle Mondrian Weka JFreeReport Tabelle 3 BI-Komponenten und deren OS-Projekte 25

26 In der Pentaho BI Suite werden alle BI-Komponenten durch Verknüpfung Ihrer Serverkomponenten mit dem Pentaho BI-Server zu einem Gesamtpaket vereint. Somit können die einzelnen Komponenten als selbständige Einheiten, als integrierte Pentaho-Komponenten oder als integrierte Komponenten in externen Anwendungen betrieben werden. Abbildung 8 Pentaho Open BI-Suite [vgl. Wie in Abbildung 8 ersichtlich, ist in der Anwendungsschicht mit der Solution Engine und den modular einsetzbaren BI-Komponenten die gesamte Anwendungslogik angesiedelt und dient der anwendungsspezifischen Aufbereitung, Nutzung und Verteilung der Daten. 26

27 Abbildung 9 Pentaho Server Architektur [vgl. Pent06] Zur Darstellung der Funktionalitäten und Inhalten aus der Anwendungsschicht, dient das Pentaho Portal auf der Präsentationsschicht, wo die Daten in integrierter und personalisierter Form zur Verfügung stehen. Die Daten stehen somit über einen Web Browser (HTTP) zur Verfügung (siehe Abbildung 9). 27

28 3.2.1 Data Integration Kettle Die ETL-Komponente für die Open Source BI-Lösung Pentaho liefert das OS-Projekt Kettle. Seit 2006 ist Kettle unter dem Namen Pentaho Data Integration Teil der Pentaho BI-Suite. Pentaho Data Integration verwendet einen innovativen, metadaten-getrieben Ansatz, d.h. es wird spezifiziert was gemacht werden soll, und nicht wie man es machen will. Aufgrund der grafischen Aufbereitung (GUI Graphic User Interface) der ETL-Komponente ist es jedem möglich komplexe Transformationen zu erstellen ohne eine einzige Zeile Programmcode zu schreiben (siehe Abbildung 10). Abbildung 10 Grafische ETL-Oberfläche [Pent08b] Pentaho Data Integrations Architektur wurde in Java geschrieben. Es herrscht eine strikte Trennung von User Interface, Daten und Metadaten. Weiters werden eine Vielzahl von Datenformate für den ETL-Prozess unterstützt wie Flat Files (txt, csv), Excel-Dateien und mehr als 30 offene und proprietäre Datenbankformate. Data Integration enthält eine Vielzahl von Tools zum Erstellen von Jobs. Ein Repository steht zur Verfügung, welches für die Speicherung von Transformationen bereitgestellt wird und zur Verwaltung verwendet werden kann [vgl. Pent08b]. 28

29 3.2.2 Analysis Mondrian Das Modul Pentaho Analysis besteht aus dem OLAP-Server Mondrian, GUI- Anwendungen zur Konfiguration der OLAP-Würfel und dem OLAP-Webfrontend JPivot. Pentaho Analysis bietet interaktive Datennavigation mit sondierbaren Tabellen und Grafiken bzw. Kreuztabellen-Berichte. Mondrian ist eine Java-basierte Server-Engine für relationales OLAP, die integriertes, mehrstufiges Caching ermöglicht. Optimierte Antwortzeiten stellen einen schnellen Zugriff auf die Unternehmensdaten im Data Warehouse zur Verfügung. Es ist möglich, eine Vielzahl von Dimensionen in den Cube aufzunehmen, um Analysen größeren Umfangs vorzunehmen. Vordefinierte Berechnungen oder Berechnungen zur Laufzeit bietet Pentaho Analysis. Der Zugriff auf Mondrian kann durch Multi Dimensional Expressions (MDX) erfolgen. Aufgabe für den OLAP-Engine hierbei ist es, die MDX-Anforderungen in SQL-Queries (SQL- Abfragen) umzuwandeln, um auf die Daten im Data Warehouse zugreifen zu können. Zusätzlich unterstützt Mondrian den Datenzugriff via XMLA oder OLAP4J (siehe Abbildung 11). Abbildung 11 Mondrian als OLAP-Engine [vgl. HeKl07] Die Pentaho User Console ist ein GUI, welches webbasierte Analyse ermöglicht. Das Interface bietet zentralen Zugang zu den BI Komponenten Reporting, Analysis und 29

30 Dashboards, um neue Berichte, Analysen etc. benutzerfreundlicher durchführen zu können. Die Navigation innerhalb der Konsole ist explorerbasiert aufgebaut. Durch JDBC wird die Verbindung zu proprietären Datenbanken wie Oracle, Microsoft SQL Server und andere unterstützt. Auf der quelloffenen Seite stehen MySQL, PostgresSQL und andere zur Verfügung. Als OLAP-Frontend dient JPivot. JPivot beinhaltet einen OLAP-Navigator, um in den Dimensionen eines Würfels zu navigieren und die anzuzeigenden Dimensionselemente und Fakten auszuwählen. In dem Navigator wird auch die Positionierung der ausgewählten Objekte auf der Kreuztabelle vorgenommen. Die Ergebnisse der Abfragen werden von JPivot in einer interaktiven Kreuztabelle oder wahlweise in einem Graphen dargestellt. In der Kreuztabelle kann der Anwender tiefer in die Detaildaten navigieren und somit die Analyse direkt auf den Ergebnissen der ursprünglichen Abfrage weiter detaillieren. Eine erstellte Analyse-Sicht lässt sich auf dem BI-Server speichern und zu einem späteren Zeitpunkt wieder aufrufen. Die Daten werden dann aktualisiert dargestellt (siehe Abbildung 12). Abbildung 12 Analysis View in der Pentaho User Console [Pent08c] 30

31 3.2.3 Data Mining Weka Pentaho hat mit dem Data-Mining-Projekt Weka die Palette der BI-Komponenten innerhalb der BI Suite erweitert Reporting JFreeReport Durch die modulare Architektur der Pentaho OS BI-Suite sind unterschiedliche Reporting Engines integrierbar. Die Pentaho BI-Komponente Reporting enthält das OS-Reporting-Projekt JFreeReport. Pentaho Reporting ermöglicht einen leichten Zugang zu Daten für die Mitarbeiter, Kunden bzw. Partner des Unternehmens. Die BI-Komponente stellt die Daten in relationalen, OLAP oder XML-basierten Datenquellen bereit und liefert Output in den verschiedensten Dateiformaten wie HTML, PDF, CSV, RTF und XLS. Pentaho Reporting kann als alleiniges Desktop-Reporting-Tool, als webbasiertes Ad-hoc- Reporting-Tool oder innerhalb einer BI-Anwendung eingesetzt werden [vgl. Pent08d]. Die XML-basierten Berichtsdefinitionen von Pentaho Report enthalten die logische Beschreibung der Inputdaten sowie eine Definition des Berichtsaufbaus. Die Reporting Engine generiert zur Ausführungszeit aus den vorhandenen Daten und den Berichtsdefinitionen die eigentlichen Berichte. Sie ist Teil des Pentaho BI- Servers und kann auch in externe Applikationen eingebettet werden. In den Action Sequences wird definiert, aus welcher Quelle die Daten kommen und mit welcher Berichtsdefinition sie verschmolzen werden sollen. Mit der Reporting Engine werden die Berichte berechnet und in den jeweiligen Formaten ausgegeben. Zur Darstellung der Daten verwendet die Reporting Engine Bereiche, Bänder und Felder, die die einzelnen Spalten aus den Eingabedaten widerspiegeln. Die Felder besitzen zusätzlich die Eigenschaft, mit externen Inhalten mittels Parameter oder zur Laufzeit mit Funktionen gefüllt und berechnet werden zu können. Felder werden Bändern zugeordnet, um sie in dem Bericht anzuzeigen. Felder, die mit den Datenspalten verknüpft sind, werden im Detailband oder den Gruppenbändern platziert, um flache oder strukturierte Listen anzuzeigen. Felder mit statischen Inhalten, z.b. Berichtstitel oder Logos, werden in den anderen Bändern platziert. 31

32 Um spezielle Funktionen, wie Seitenanzahl eines Berichts, abzubilden kann man auf die von Pentaho angebotenen Funktionen zurückgreifen. Die Berichte können mittels Sub-Berichten erweitert werden. Berichte können z.b Tabellen und Grafiken enthalten [vgl. Jáno08]. Zur Erstellung von Berichtsdefinitionen stellt Pentaho den Entwicklern zwei Programme zur Verfügung, nämlich den Report Designer und den Report Design Wizard. Der Report Design Wizard dient zur schnellen und einfachen Berichtsgenerierung, der auch für ungeübte Benutzer leicht zu bedienen ist. Der Report Designer bietet einem freie Hand bei der Gestaltung eines Berichtes und dieser kann jederzeit in der Vorschau angezeigt werden. 3.3 Oracle Business Intelligence Enterprise Edition (OBIEE) Die Oracle Business Intelligence Suite Enterprise Edition stellt eine Vielzahl an BI- Produkten zur Verfügung und bietet eine große Anzahl an BI-Möglichkeiten wie interaktive Dashboards ( Armaturenbretter ), Ad-hoc-Reporting, proaktives Alarmieren, Echtzeit-Performance und Offline-Analysen. Eine moderne webserviceorientierte Architektur bietet die Grundlage der Oracle BI-Suite. Oracle Business Intelligence Suite Enterprise Edition beinhaltet folgende Komponenten: Oracle BI Server Oracle BI Answers Oracle BI Interactive Dashboards Oracle BI Delivers Oracle BI Disconnected Analytics Oracle BI Publisher Oracle BI Briefing Books Der Oracle BI Server ist ein skalierbarer, effizienter Abfrage- und Analyseserver, der die Daten aus relationalem, unstrukturiertem OLAP oder anderen Quellen, sei es Oracle oder auch nicht, integriert. 32

33 Oracle BI Answers stellt das Analyse- bzw. Abfragetool der OBIEE dar. Das Ad-hoc- Abfrage- und Analysetool wirkt der logischen Sicht auf die Informationen aus multiplen Datenquellen entgegen (Vereinfachung der Sicht auf die Daten). Die Oracle BI Interactive Dashboards bilden personalisierte Informationen ab, die die Benutzer bei der Entscheidungsfindung unterstützen sollen. Oracle BI Delivers stellt die Alarmierungsengine der BI-Suite dar. Über eine Vielzahl von Kanälen werden die Mitteilungen verteilt, damit auf gewisse, neue Geschäftssituationen früh genug reagiert werden kann. Wie der Name schon vermuten lässt, handelt es sich bei Oracle BI Disconnected Analytics um eine Offline-Version, die dem Benutzer das Arbeiten für unterwegs ermöglichen soll. Der Reportingengine der OBIEE ist die Komponente Oracle BI Publisher, mit derer Berichte in unterschiedlichen Formaten generiert und an verschiedene Benutzergruppen verteilt werden können. Oracle BI Briefing Books beinhalten Auszüge aus den Dashboards oder anderen Berichten, die für Offline-Präsentationen verwendet werden können Oracle BI Server Der Oracle BI Server übernimmt zwei zentrale Funktionen erstens muss er die eingehenden Abfrageaufrufe in ausführbaren Code compilieren und zweitens muss er diesen neu erzeugten Code ausführen. Klienten des Oracle BI Servers sehen eine logisches Schema unabhängig vom physischen Quelldatenbankschema. Der Client übermittelt simples, logisches SQL welches vom Server in physisches SQL übersetzt und an die Back-End-Datenbanken gesendet wird, wo mithilfe des Oracle BI Server Execution Engine der Code ausgeführt wird [vgl. Orac07] Oracle BI Presentation Service Der Oracle BI Presentation Service Server stellt das User-Interface für Oracle Answers und Interactive Dashboards zur Verfügung, welche für die Visualisierung der Daten des Oracle BI Servers verantwortlich sind. Die Interaktion mit dem Oracle 33

34 BI Server erfolgt als ODBC 5 Client und der Presentation Service Server stellt eine Vielzahl an wichtigen Services zur Verfügung: Es erstellt ein User-Interface für Oracle Answers und Interactive Dashboards. Es antwortet auf die Auswahl des Benutzers, generiert logisches SQL für den Oracle BI Server und speichert logische SQL-Statements und deren Ergebnisse im Cache zwischen. Die Spezifikationen, die der Benutzer für die Präsentation der Daten macht, werden aufgezeichnet und über den Charting Engine wird kommuniziert, der für die Erstellung von Grafiken verantwortlich ist. Nachdem der Oracle BI Server das Ergebnis generiert hat, kann mithilfe des Presentation Service Server die Datendarstellung gedreht oder die Daten summieren werden. Benutzer- und Gruppensicherheit wird für personalisierte Abfragen und Dashboards gewährt. Bereits beim Einloggen wird dem Presentation Service Server vom Oracle BI Server mitgeteilt, welche Datenbanken, Tabellen, etc. der Benutzer einsehen darf [vgl. Orac07]. Oracle BI Answers und Interactive Dashboards Oracle BI Answers bietet Benutzern Ad-hoc-Abfrage- und Analysemöglichkeiten. Als reine Webapplikation aufgebaut, hat der Benutzer die Möglichkeiten neue Abfragen zu erstellen oder bereits bestehende zu modifizieren. Aufgrund der Tatsache, dass der Benutzer eine logische Sicht auf die Daten hat, gelingt es ihm leichter Grafiken, Berichte, Pivottabellen, etc. zu erstellen. Die Komplexität der Datenstruktur bleibt ihm verborgen. Interactive Dashboards macht Daten für Business-Users leichter zugänglich. Oracle BI Interactive Dashboard läuft innerhalb einer Webarchitektur und verschafft Benutzern Informationen, die gefiltert und personalisiert bereitgestellt werden. Dadurch ist es leichter, die Daten zu verstehen und diese helfen beim Entscheidungsfindungsprozess. Die Kombination aus Oracle BI Answers und 5 Open Database Connectivity ( Offene Datenbank-Verbindungsfähigkeit ) ist eine standardisierte Datenbankschnittstelle, die SQL als Datenbanksprache verwendet. 34

35 Interactive Dashboards unterstützt den Entscheidungsfindungsprozess zusätzlich [vgl. Orac07] Oracle BI Publisher Der Oracle BI Publisher stellt eine höchst effiziente, skalierbare Reporting-Lösung dar. Der Kern des Publishers liegt in der Generierung von Reports aus unterschiedlichen Datenquellen in unterschiedlichen Dokumentformaten und in der Verteilung der Informationen auf unterschiedlichen Kanälen. Am Beginn eines Berichtserstellungsprozess stehen beim Oracle BI Publisher die Daten. Diese entstammen dem Oracle BI Server oder einer anderen Datenquelle. Über eine Webanwendungsumgebung wird eine Reportdefinition erstellt. Nachdem die Daten ausgewählt wurden, wird ein Report-Layout, ein Report Delivery Format und die Kanäle gewählt. Es ist auch möglich, dem Publisher mitzuteilen, wann er den Report erstellen und dann versenden soll. Der Oracle BI Publisher unterstützt die Dateiformate Microsoft Word, Excel, RTF, PDF, XML, EDI und andere [vgl. Orac07]. 35

36 3.4 Vergleich der Business Intelligence Lösungen Abschließend möchte ich die einzelnen Softwarelösungen in Tabelle 4 nochmals darstellen und aus meiner Sicht bewerten. Die Skala der Bewertung reicht von sehr gut bis hin zu nicht zufriedenstellend (5-stufige Bewertungsskala). Microsoft Server 2005 SQL Pentaho BI Suite Oracle Business Intelligence Enterprise Edition Installation leicht zu installieren; Installations- und Setupassistent sehr hilfreich; in einem einzigen Installationsvorgang wird alles (einzelne Module) installiert; wenige Anpassungen sind vorzunehmen (++) Installation umfangreicher (getrennte Installation der Module); die einzelnen Module müssen erst lauffähig gemacht werden; ohne den Installationsguide aus [jáno08] ein wenig hilflos (o) auch die Oracle BIEE lässt sich leicht installieren (+) Interoperabilität Module sind unabhängig; können auch einzeln verwendet werden; sehr gutes Zusammenspiel der einzelnen Module als ganzes SQL Server-Paket; Verwaltung und Programmierung geschieht in zwei eigenen Studios (++) jedes Modul stellt ein eigenes Programm dar, die in der BI Suite zusammenarbeiten; ein wenig unübersichtlich im Gegensatz zum SQL Server (+) die Module der Oracle BIEE können getrennt von einander verwendet werden; die BI Edition beinhaltet jedoch kein Datenbankmodul, deshalb müsste eine Oracle Database zusätzlich heruntergeladen werden (o) Skalierbarkeit laut den White Papers der einzelnen Softwarelösungen besitzen diese gute Skalierbarkeit; Performance leidet unter den Datenmenge nicht (+) Benutzerfreundlich sehr benutzerfreundlich; ähnelt anderen Microsoft- Produkten, deshalb 36 wie in einigen Texten zu lesen ist, leidet die Benutzerfreudlichkeit ein wenig; kann mich etwas ungewohnt für mich mit Oracle zu arbeiten; hat sich im Laufe des

37 Umgang für mich relativ leicht; Verwaltung im Management Studio, Programmierung im BI Development Studio (++) nur anschließen, ohne Pentaho-WIKI ein wenig ratlos; sollte sich mit der Version Pentaho BI Suite 2 verbessern (o) Testens gebessert (o) Kosten kommerzielles Produkt; in meiner Firma wird damit jedoch gearbeitet, dadurch entstehen für mich keine Kosten; ansonsten teuer (o) Open-Source- Produkt; frei zugänglich; wird immer wieder weiterentwickelt und verbessert; jeder kann dazu beitragen (++) kommerzielles Produkt; nur Testversion downloadbar; teuere Software (-) 5-stufige Bewertungsskala: sehr gut (++), gut (+), durchschnittlich (o), wenig zufriedenstellend (-), nicht zufriedenstellend (--) Tabelle 4 Übersicht der Softwarelösungen - Meine Einschätzung Wie der Tabelle 4 zu entnehmen ist, schneidet der Microsoft SQL Server 2005 am besten ab gefolgt von der Pentaho BI Suite und der Oracle Business Intelligence Enterprise Edition. Deshalb habe ich mich für den Aufbau des Data Warehouse mit Microsoft SQL Server 2005 entschieden. Des Weiteren steht mir der SQL Server unentgeltlich zur Verfügung. Der Aufbau des SQL Servers ist anderen Microsoft-Produkten sehr ähnlich und auch die Online-Dokumentation ist sehr hilfreich. Das nachfolgende Kapitel 4 beinhaltet den die praktische Umsetzung mittels Microsoft SQL Server

38 4 Praktische Umsetzung mittels Microsoft SQL Server 2005 Bei der praktischen Umsetzung ist uns die Verwaltungsumgebung des Microsoft SQL Server 2005 behilflich, das SQL Server Management Studio. Das Data Warehouse wird im Bereich des Analysestools des Microsoft SQL Server 2005 Analysis Services eingesetzt. Bei den Analysis Services erstellen wir den OLAP-Cube, der die Dimensionen und Fakten beinhalten, damit wir die Datenauswertungen durchführen können. Dabei setzten wir die Entwicklungsumgebung des Programms ein, das Business Intelligence Development Studio. In weiterer Folge generieren wir Berichte zur besseren Darstellung der Daten. Eine Testumgebung wurde ebenfalls eingerichtet, die zur Darstellung der Daten im Web dient. Diese stellt jedoch eine stark vereinfachte Umgebung dar und soll lediglich zur besseren Veranschaulichung meiner getätigten Arbeit dienen, wie in Kapitel 5 Fazit und Ausblick zu lesen ist. 4.1 Anforderungsanalyse und Entwürfe Anforderungsanalyse und konzeptueller Entwurf Ausgehend vom vorhandenen Datenbankschema (Access-Datenbank) gilt es eine Anforderungsanalyse zu machen. Die Daten der Konjunkturstatistik im Produzierenden Bereich werden in vier unterschiedlichen Tabellen gehalten: Daten in der Kammersystematik nach Bundesländern Daten in der Kammersystematik nur für Österreich 6 Daten in der ÖNACE-2-Steller 7 nach Bundesländern und für Österreich Daten in der ÖNACE-4-Steller nur für Österreich Alle Tabellen enthalten die Felder Aufarbeitung, Monat, Jahr, Systematik-Code, Bundesland und die einzelnen Merkmale wie Betriebe, Arbeiter, Angestellte, Beschäftigte, etc. Für das Data Warehouse gilt es, die Felder Aufarbeitung bis hin 6 Summe der Bundesländer ist nicht gleich der Österreich-Wert aufgrund der Statistischen Geheimhaltung (ab 3 Betriebe Wert ausweisbar) 7 ÖNACE: Europäische Systematik der Wirtschaftstätigkeiten; ÖNACE-2-Steller: 2-stelliger Code (z.b. 29 steht für Maschinenbau); ÖNACE-4-Steller: 4-stelliger Code (z.b steht für Herstellung von handgeführten Werkzeugen mit Motorantrieb) 38

39 zum Bundesland in eigene Dimensionstabellen abzulegen und nur die Primärschlüssel als Fremdschlüssel in die Faktentabelle mit den einzelnen Merkmalen zu übernehmen. Zu berücksichtigen ist auch, dass es ab 2008 eine neue Version der ÖNACE (vormals ÖNACE 2003) gibt. Einen Ansatz zur graphischen Repräsentation eines konzeptuellen Datenbankmodells stellt das Entity-Relationship- Modell dar: Entitäten Aufarbeitung Monat Quartal Jahr Systematik Bundesland Merkmale (Betriebe, Beschäftigte, etc.) Tabelle 5 Auflistung der Entitäten Logischer Entwurf Nachdem das konzeptuelle Schema erstellt worden ist, gilt es nun das logische Schema zu entwerfen. Wie aus Tabelle 5 ersichtlich ist, ist es möglich die Tabellen Monat, Quartal und Jahr in eine Tabelle dim_time zusammenzufassen. Weiters ist zu berücksichtigen, dass es ab 2008 einen neuen ÖNACE-Code gibt. Die Felder sys_version, sys_gueltig_von, sys_gueltig_bis werden zusätzliche zum Feld sys_code bzw. sys_text in die Dimensionstabelle dim_sys aufgenommen. Die Abbildung 10 zeigt das entstandene logische Datenmodell - Starschema. 39

40 Abbildung 13 Logisches Datenmodell Starschema Die nachfolgenden Schritte beinhalten die Umsetzung unseres logischen Datenmodells (siehe Abbildung 13) am SQL Server, d.h. wir erstellen ein Data Warehouse. 4.2 Physisches Datenmodell Erstellen des Data Warehouse Als erstes erstellen wir eine neue Datenbank, über die Schaltfläche New Database und benennen diese Konjunkturstatistik (siehe Abbildung 14). Abbildung 14 Datenbanksicht 40

41 Nachdem wir die Datenbank am Server erstellt haben, müssen wir diese mit Daten befüllen. Dazu brauchen wir jedoch Tabellen, wo wir die Daten ablegen können. Unsere Datenbank besteht aus vier Dimensionstabellen und einer Faktentabelle. Damit die Dimensionstabellen und Faktentabellen miteinander verknüpft werden können, legen wir in den Dimensionstabellen Primärschlüssel an. Diese dienen zur Identifikation und stellen eine eindeutige Wertekombination dar. Z.B. besteht der Primärschlüssel der Dimensionstabelle dim_sys aus einer Kombination von zwei Spalten. Dies ist deshalb der Fall, da es in den unterschiedlichen Systematiken (Kammersystematik 2005, ÖNACE 2003 und ÖNACE 2008) gleiche Codierung gibt und nur der Systematik-Code kein eindeutiger Schlüssel wäre. Mit der Spalte sys_version wird dem Code noch die Version angehängt und schon haben wir einen eindeutigen Identifikator aus der Kombination von dim_primary_sys und sys_version gebildet. Verknüpft sind die einzelnen Tabellen über den Primärschlüssel aus der Dimensionstabelle mit dem Fremdschlüssel aus der Faktentabelle (siehe Abbildung 15). Abbildung 15 Logisches Datenmodell Die Dimensionstabellen werden manuell befüllt, da diese nicht so umfangreich sind. Tabelle 6 zeigt die Dimensionstabelle dim_bundesland. Diese beinhaltet den Primärschlüssel dim_primary_bundesland und das Feld bundesland sowie deren Einträge. 41

42 dim_primary_bundesland bundesland 1 Burgenland 2 Kärnten 3 Niederösterreich 4 Oberösterreich 5 Salzburg 6 Steiermark 7 Tirol 8 Vorarlberg 9 Wien 10 Österreich Tabelle 6 Dimensionstabelle dim_bundesland Nachdem die Struktur des Data Warehouse nun steht, befüllen wir die Faktentabelle mit den Daten aus der Access-Datenbank. Hierfür müssen wir die vier Tabellen aus der Access-Datenbank in das Data Warehouse laden. Als erstes werden diese Tabellen als CSV-Files abgespeichert und mittels des danach erstellten ETL- Packages in das Data Warehouse geladen. Diese Pakete werden nur einmal geladen und danach inaktiv gesetzt, damit keine doppelten Einträge (Redundanz) entstehen. Die Connection-Manager der einzelnen CSV-Files werden so angepasst, dass die monatlichen CSV-Files (Flat File) Bestandteil des ETL-Packages sind. Dazu erstellen wir ein Integration Service Projekt, in welchem wir fünf Data Flows für den Import aus den CSV-Files skizzieren. Die Integration Services des SQL Servers stellen die ETL- Schicht dar (Extraction-Transformation-Load). Wir extrahieren die Daten aus den Flat-Files (CSV-Files) und transformieren diese. D.h. Zusätzliche Informationen werden innerhalb des ETL-Prozesses aus den Dimensionstabellen geladen wie zum Beispiel aus der Dimensionstabelle dim_sys wird das Feld sys_version benötigt, da diese Information in den Flat-Files nicht vorhanden ist. Nachdem die einzelnen Schritte (Extrahieren Transformieren) innerhalb des ETL- Package ausgeführt wurden, werden die Daten aus den Flat-Files bzw. die 42

43 zusätzlichen Informationen aus den Dimensionstabellen in die Faktentabelle geladen. Nach einem erfolgreichen ETL-Prozess werden die jeweiligen Pakete in Grün angezeigt. (Abbildung 16). Abbildung 16 ETL-Control Flow Sollte sich jedoch ein Fehler einschleichen, so wird im Control Flow das Paket in Rot angezeigt. In der Data Flow Ansicht werden genau diese Stellen mit Rot angezeigt, in der der Fehler enthalten ist. Es kann also vorkommen, dass bereits beim Extrahieren der CSV-Datei ein Fehler entstanden ist, dies ist dann der Fall, wenn z.b. das Format der CSV-Datei nicht mit dem Format für die Transformation übereinstimmt. Im Registerblatt Progress/Execution Results werden die einzelnen Schritte des ETL- Vorgangs dokumentiert, die vom System ausgeführt werden und es wird angezeigt, welcher Fehler wo entstanden ist. Eines dieser ETL-Pakete werden wir nun näher beleuchten als erstes muss eine Verbindung mit der jeweiligen Quelle hergestellt werden. Dazu bedienen wir uns des Connection Manager, wo wir eine neue Quelle hinzufügen. Für den Import müssen wir den einzelnen Spalten einen Datentyp zuordnen. Die Fremdschlüssel bekommen den Datentyp des Primärschlüssels der Dimensionstabelle und die Merkmale der Faktentabelle entweder Integer oder Float, da es sich hierbei um Kennzahlen handelt mit denen gerechnet wird. Die Datei wird extrahiert und muss nur mehr in das gewünschte Ausgangsformat überführt werden. Als erstes wird die 43

44 Dimensionstabelle Bundesland hinzugeladen. Es wird ein Abgleich zwischen extrahierter CSV-File und Dimensionstabelle Bundesland gemacht. Bei erfolgreichem Match wird die Datei weitergeschickt und mit der Time-Dimensionstabelle gematcht. Fehlende Felder können aufgrund des Matches zwischen den Tabellen neu generiert und in die Faktentabelle aufgenommen werden, jedoch muss dieses Feld in dieser bereits bestehen, da ansonsten der Import nicht funktioniert. Auch die Systematik- Tabelle und zum Schluss noch die Dimensionstabelle Version sind Bestandteil des Data Flows. Die Datei steht nun im Ausgabeformat zur Verfügung und wird am Ende des ETL- Pfades in die Faktentabelle geladen. Ob der Vorgang auch erfolgreich war, sehen wir an den grünhinterlegten Kästchen in der Data Flow Ansicht oder an der Anzahl der bearbeiteten/hinzugefügten Zeilen (jeweils 61 Rows/Zeilen in Abbildung 17), die innerhalb des Prozess übergeben werden. Das Registerblatt Progress/Execution Results beinhaltet die einzelnen Schritte, die vom System durchgeführt wurden. Dabei wird angezeigt wie viele Zeilen aus der Dimensionstabelle Bundesland z.b. geladen wurden bzw. auch wie viele Zeilen in die Faktentabelle importiert wurden. Abbildung 17 Data-Flow eines der ETL-Pakete Über das Microsoft SQL Server Management Studio können wir die einzelnen Tabellen des Data Warehouses einsehen und in Abbildung 18 wird die Faktentabelle mit den angefügten Daten angezeigt. 44

45 Abbildung 18 Sicht auf die Faktentabelle mit Daten Zugriffsberechtigungen bzw. Rollen können wir auch über das Management Studio festlegen. Auch Stored Procedures werden hier abgelegt, jedoch werde ich hier nicht näher darauf eingehen. 4.3 OLAP-Cube Erstellen eines Analysis Services-Projekt Um einen OLAP-Cube in Microsoft SQL Server 2005 erstellen zu können, müssen wir zu den Analysis Services wechseln. Dort erstellen wir ein Analysis Services- Projekt. Zuerst müssen wir eine neue Datenquelle erstellen. Die neue Datenquelle ist das Konjunkturstatistik Data Warehouse, welches wir davor erstellt und befüllt haben. Um eine Sicht (grafische Darstellung) auf die neue Datenquelle zu bekommen, erzeugen wir einen View auf das Konjunkturstatistik Data Warehouse (siehe Abbildung 19). 45

46 Abbildung 19 Data Source View innerhalb der Analysis Services Damit wir die Daten auswerten können, erstellen wir einen neuen OLAP-Cube, den wir Konjunkturstatistik nennen. Der Cube wird mittels eines Wizards (Assistenten) erzeugt. Dabei wird der Dimensionstabelle dim_time die Zeitdimension zugeordnet, wo dem Feld dim_primary_jahr Year, dim_primary_quartal Quarter und dim_primary_monat Month zugewiesen wird. Die anderen Dimensionen des Cubes sind die Tabellen Bundesland, Aufarbeitung und Systematik. Zentral für einen OLAP-Cube jedoch ist die Faktentabelle, denn ohne diese wären keine Auswertungen möglich. Da oft die unterschiedlichsten Kennzahlen benötigt werden, so ist es möglich, neue Merkmale zu berechnen oder neue Auswertungsdimensionen zu erstellen, die eine andere Sicht auf die Daten darstellen. In unserem Data Warehouse sind z.b. Angestellte nach männlich und weiblich untergegliedert, jedoch fehlt eine Gesamtzahl. Diese erzeugen wir innerhalb des Registerblatts Calculations, wo wir ein Calculated Member namens Angestellte erzeugen, die die Summe aus männlichen und weiblichen Angestellten ergibt (Abbildung 20). 46

47 Abbildung 20 Neue Kennzahlen werden berechnet Nachdem wir einige Kennzahlen berechnet haben, gehen wir in das Registerblatt Browser, wo wir uns eine Auswertung zusammenstellen. Die neuen Kennzahlen, die Merkmale der Faktentabelle und die vier Dimensionstabellen stehen zur Auswahl. Sollte dies nicht der Fall sein, so ist es notwendig den Button Process zu drücken, damit wird der Cube neu berechnet. Die Ansicht innerhalb des Registerblatts Browser ist vergleichbar mit einer Pivottabelle. Wir können einzelne Felder der Dimensionstabellen in die Column Area, Row Area oder Filter Area schieben. Die Merkmale der Faktentabelle bzw. die neuen Kennzahlen können nur in die Data Area verschoben werden, da Auswertungen mit Zahlen erstellen werden sollen. Wie in Abbildung 21 ersichtlich haben wir die Felder sys_version und systematik in die Row Area verschoben. Die Column Area beinhaltet die Zeitangabe Jahr. In der Filter Area steht das Feld Bundesland, welches auf Gesamtösterreich eingeschränkt ist. Unsere Data Area beinhaltet das Feld Beschäftigte. Weitere Einschränkungen wurden in der Subcube Area vorgenommen. Innerhalb dieser Area können die unterschiedlichsten Filtervorgänge durchgeführt werden. In unserem Beispiel haben wir die sys_version auf die KS 2005 eingegrenzt. Weiters wurde festgelegt, dass nur jene Systematik-Codes in die Auswertung übernommen werden, die mit der Zahl 2 beginnen und für die Zeitangabe Jahr wurde ein Bereich ab 2005 bis 2007 gesetzt. Zu beachten ist, dass einzelne Merkmale als Durchschnitt ausgewiesen werden 47

48 sollen und andere als Summe. Die Anzahl der Betriebe (Arbeiter, Angestellte, Lehrlinge, etc.) sollte jedenfalls als Durchschnitt der Monate ausgewiesen werden, da ansonsten in der Jahresabbildung stark überhöhte Werte herauskommen. Die Ausweisung als Summe hat bei Arbeitsstunden, Verdiensten oder Produktionswerten einen Sinn. Diese Kriterien (Durchschnitt und Summe) werden innerhalb der Properties (Eigenschaftsfenster) des jeweiligen Merkmals festgelegt. Abbildung 21 Auswertung im Stile einer Pivot-Tabelle 4.4 Bericht Erstellen eines Reporting Services-Projekt Mit Hilfe des Konjunkturstatistik-Cubes erstellen wir mehrere Berichte. Dazu müssen wir einen neuen Report erzeugen und zu den Reporting Services wechseln. Als Quelle nehmen wir den Konjunkturstatistik-Cube. Die für uns relevanten Felder beziehen wir bei der Berichtserstellung mit ein. Den Inhalt des Berichts erstellen wir mittels Query Builder, der ähnlich einer Abfrage in Access aufgebaut ist. Wer jedoch lieber SQL-Queries generieren will, kann dies auch innerhalb des Query Builder tun. Über das Registerblatt Preview können wir uns den neuen Bericht anschauen, als auch in die unterschiedlichsten Formate exportieren, um damit weiterarbeiten zu können. Wir erstellen einen Bericht für die Anzahl der Betriebe, für Arbeiter, Angestellte, Lehrlinge, Beschäftigte, Auftragseingänge, Auftragsbestände und für die Abgesetzte Produktion. Diese Berichte können am Report-Server bereitgestellt 48

49 werden, der im Firmen-Netzwerk erst konfiguriert werden muss. Die Abbildung 22 zeigt einen Auszug aus den Reporting Services (Beschäftigte in der Kammersystematik) sowie die Exportmöglichkeiten. Abbildung 22 Generierter Bericht in den Reporting Services 49

50 5 Fazit und Ausblick Nachdem es in der Wirtschaftskammer Österreich im Dezember 2008 zu einer umfangreichen Betriebssystem-Umstellung gekommen ist, so wurden die ganzen Arbeiten für das IT-Praktikum auf meinem privaten Laptop durchgeführt. Auch die IT- Abteilung war in dieser Zeit nur sehr schwer zu erreichen, jedoch habe ich mich mit Ihnen darauf geeinigt, dass ich mich nach Fertigstellung meiner Bachelorarbeit mit Ihnen zusammensetze und Ihnen mein Data Warehouse für die Konjunkturstatistik im Produzierenden Bereich vorstelle. Weiters wird angedacht, eine Homepage für die Abfrage von Daten einzurichten. Damit wird jedem Benutzer die gleiche Ausgangslage geboten und der Zugang zu den Daten soll dadurch vereinfacht werden. Das Herunterladen des gesamten Datenbestandes entfällt und so kann jeder Benutzer die Daten abrufen, die er zur weiteren Bearbeitung benötigt. Von Seiten der Stabsabteilung Statistik gab es positives Feedback als erstes wurde die Eigeninitiative gelobt und zweitens bietet das neue Tool eine weitere Erleichterung/Bereicherung für unsere tägliche Arbeit. Eine kleine Testumgebung wurde bereits am privaten Laptop erstellt. Die Abbildung 23 zeigt die Webanwendung mit der Default-Seite, über die per Auswahl der Kriterien die gewünschten Auswertungen durchgeführt werden. Die Daten werden innerhalb der Default-Seite angezeigt. Es besteht die Möglichkeit, die einzelnen Spalten zu sortieren und innerhalb der Seite zu blättern. Abbildung 23 Darstellung im Browser 50

51 Die Website wurde mit dem Visual Web Developer, der einen kleinen Webserver ASP Development Server für das Anzeigen der Seiten im Browser zur Verfügung stellt, erstellt und wird in näherer Zukunft weiterentwickelt, damit sie dem Corporate Identity der Wirtschaftskammer Österreich entspricht. Der Quellcode ist im Anhang verfügbar. 51

52 Quellenverzeichnis [ABDe06]: [BeSt04]: [HeKl07] [KiRo96]: [KiRo02]: [JaMi06]: Azevedo, Pedro; Brosius, Gerhard; Dehnert, Stefan. Business Intelligence und Reporting mit Microsoft SQL Server Microsoft Press Deutschland. Bernroider, Edward; Stix, Volker. Grundzüge der Modellierung. Wien 2004 Facultas. Held, Marcus; Klose, Ingo: Business Intelligence mit Pentaho , abgefragt am 16. September Kimball, Ralph; Ross, Margy. The Data Warehouse Toolkit The Complete Guide to Dimensional Modeling. 1nd edition Wiley & Sons. Kimball, Ralph; Ross, Margy. The Data Warehouse Toolkit The Complete Guide to Dimensional Modeling. 2nd edition Wiley & Sons. Jacobson, Reed; Misner, Stacia; Hitachi Consulting. Microsoft SQL Server 2005 Analysis Services Microsoft Press Deutschland. [Jáno08]: János, Attila. Pentaho Open Source BI. Wien, April [Micr05]: SQL Server Microsoft Developer Network. abgefragt am 15. Juli [Pent06]: [Orac07]: Oracle Business Intelligence Suite Enterprise Edition Plus Technical Overview. Oracle. erstellt November 2007, abgefragt am 16. September Pentaho Open Source Business Intelligence Plattform Technical White Paper. Pentaho Open Source Business Intelligence. erstellt 2006, abgefragt am 16. September

53 [Pent08a]: [Pent08b]: [Pent08c]: [Pent08d]: Pentaho BI Suite Enterprise Edition. Pentaho Open Source Business Intelligence. abgefragt am 16. September Pentaho Data Integration. Pentaho Open Source Business Intelligence. abgefragt am 16. September Pentaho Analysis. Pentaho Open Source Business Intelligence. abgefragt am 16. September Pentaho Reporting. Pentaho Open Source Business Intelligence. abgefragt am 16. September [Watt06]: Watt, Andrew. Microsoft SQL Server 2005 für Dummies. 2. aktualisierte Auflage Wiley-VCH-Verlag 53

54 Anhang Quellcode Default.aspx Page Language="VB" AutoEventWireup="false" CodeFile="Default.aspx.vb" Inherits="_Default" %> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " <html xmlns=" > <head runat="server"> <title>konjunkturstatistik im Produzierenden Bereich</title> </head> <body> <h2>konjunkturstatistik im Produzierenden Bereich</h2> <h3>auswahl der Auswertungskriterien</h3> <form id="form1" runat="server"> <table><tr><td><b>aufarbeitung:</b></td> <td><asp:dropdownlist ID="DropDownList0" DataSourceID="SqlDataSource0" AutoPostBack="true" DataTextField="version" Runat="server" /> <asp:sqldatasource ID="SqlDataSource0" Runat="server" SelectCommand="SELECT DISTINCT [dim_primary_version] as version FROM [dim_version]" ConnectionString="<%$ ConnectionStrings:Konjunkturstatistik %>" /></td></tr> <tr><td><b>systematik-version:</b></td> <td><asp:dropdownlist ID="DropDownList1a" DataSourceID="SqlDataSource1a" AutoPostBack="true" DataTextField="sys_version" Runat="server" /> <asp:sqldatasource ID="SqlDataSource1a" Runat="server" SelectCommand="SELECT DISTINCT [sys_version] FROM [dim_sys]" ConnectionString="<%$ ConnectionStrings:Konjunkturstatistik %>" /></td></tr> <tr><td><b>systematik-code beginnt mit:</b></td> <td><asp:dropdownlist ID="DropDownList1b" DataSourceID="SqlDataSource1b" AutoPostBack="true" DataTextField="code" Runat="server" /> <asp:sqldatasource ID="SqlDataSource1b" Runat="server" SelectCommand="SELECT DISTINCT left([dim_primary_sys],1) as code FROM [dim_sys] order by [code]" ConnectionString="<%$ ConnectionStrings:Konjunkturstatistik %>" /></td></tr> <tr><td><b>bundesland:</b></td> <td><asp:dropdownlist ID="DropDownList2" DataSourceID="SqlDataSource2" AutoPostBack="true" 54

55 DataTextField="bundesland" Runat="server" /> <asp:sqldatasource ID="SqlDataSource2" Runat="server" SelectCommand="SELECT DISTINCT [bundesland] FROM [dim_bundesland]" ConnectionString="<%$ ConnectionStrings:Konjunkturstatistik %>" /></td></tr> <tr><td><b>monat von:</b></td> <td><asp:dropdownlist ID="DropDownList3a" DataSourceID="SqlDataSource3a" AutoPostBack="true" DataTextField="dim_primary_monat1" Runat="server" /> <asp:sqldatasource ID="SqlDataSource3a" Runat="server" SelectCommand="SELECT DISTINCT [dim_primary_monat] as dim_primary_monat1 FROM [dim_time]" ConnectionString="<%$ ConnectionStrings:Konjunkturstatistik %>" /></td> <td><b>bis:</b></td> <td><asp:dropdownlist ID="DropDownList3b" DataSourceID="SqlDataSource3b" AutoPostBack="true" DataTextField="dim_primary_monat2" Runat="server" /> <asp:sqldatasource ID="SqlDataSource3b" Runat="server" SelectCommand="SELECT DISTINCT [dim_primary_monat] as dim_primary_monat2 FROM [dim_time]" ConnectionString="<%$ ConnectionStrings:Konjunkturstatistik %>" /></td></tr> <tr><td><b>jahr von:</b></td> <td><asp:dropdownlist ID="DropDownList3c" DataSourceID="SqlDataSource3c" AutoPostBack="true" DataTextField="dim_primary_jahr1" Runat="server" /> <asp:sqldatasource ID="SqlDataSource3c" Runat="server" SelectCommand="SELECT DISTINCT [dim_primary_jahr] as dim_primary_jahr1 FROM [dim_time]" ConnectionString="<%$ ConnectionStrings:Konjunkturstatistik %>" /></td> <td><b>bis:</b></td> <td><asp:dropdownlist ID="DropDownList3d" DataSourceID="SqlDataSource3d" AutoPostBack="true" DataTextField="dim_primary_jahr2" Runat="server" /> <asp:sqldatasource ID="SqlDataSource3d" Runat="server" SelectCommand="SELECT DISTINCT [dim_primary_jahr] as dim_primary_jahr2 FROM [dim_time]" ConnectionString="<%$ ConnectionStrings:Konjunkturstatistik %>" /></td></tr></table> <asp:gridview ID="GridView1" runat="server" AllowPaging="True" AllowSorting="True" AutoGenerateColumns="False" DataKeyNames="Jahr,Aufarbeitung,Code,Sys_Version" DataSourceID="SqlDataSource10" BackColor="LightGoldenrodYellow" BorderColor="Tan" BorderWidth="1px" CellPadding="2" ForeColor="Black" GridLines="None" Height="200px" PageSize="20" ShowFooter="True"> <PagerSettings Mode="NumericFirstLast" PageButtonCount="20" /> <Columns> <asp:boundfield DataField="Bundesland" HeaderText="Bundesland" SortExpression="Bundesland" /> 55

56 <asp:boundfield DataField="Jahr" HeaderText="Jahr" ReadOnly="True" SortExpression="Jahr" /> <asp:boundfield DataField="Aufarbeitung" HeaderText="Aufarbeitung" ReadOnly="True" SortExpression="Aufarbeitung" /> <asp:boundfield DataField="Code" HeaderText="Code" ReadOnly="True" SortExpression="Code" /> <asp:boundfield DataField="Sys_Version" HeaderText="Sys_Version" ReadOnly="True" SortExpression="Sys_Version" /> <asp:boundfield DataField="Bezeichnung" HeaderText="Bezeichnung" SortExpression="Bezeichnung" /> <asp:boundfield DataField="Betriebe" HeaderText="Betriebe" ReadOnly="True" SortExpression="Betriebe" /> <asp:boundfield DataField="Arbeiter" HeaderText="Arbeiter" ReadOnly="True" SortExpression="Arbeiter" /> <asp:boundfield DataField="Angestellte" HeaderText="Angestellte" ReadOnly="True" SortExpression="Angestellte" /> <asp:boundfield DataField="Lehrlinge" HeaderText="Lehrlinge" ReadOnly="True" SortExpression="Lehrlinge" /> <asp:boundfield DataField="Beschaeftigte" HeaderText="Beschäftigte" ReadOnly="True" SortExpression="Beschaeftigte" /> <asp:boundfield DataField="AbgesetzteProduktion" HeaderText="Abgesetzte Produktion in Mio. Euro" ReadOnly="True" SortExpression="AbgesetzteProduktion" /> </Columns> <FooterStyle BackColor="Tan" /> <PagerStyle BackColor="PaleGoldenrod" ForeColor="DarkSlateBlue" HorizontalAlign="Center" /> <SelectedRowStyle BackColor="DarkSlateBlue" ForeColor="GhostWhite" /> <HeaderStyle BackColor="Tan" Font-Bold="True" /> <AlternatingRowStyle BackColor="PaleGoldenrod" /> </asp:gridview> <asp:sqldatasource ID="SqlDataSource10" runat="server" ConnectionString="<%$ ConnectionStrings:Konjunkturstatistik %>" SelectCommand="SELECT dim_bundesland.bundesland AS Bundesland, dim_time.dim_primary_jahr AS Jahr, dim_version.dim_primary_version AS Aufarbeitung, dim_sys.dim_primary_sys AS Code, dim_sys.sys_version AS Sys_Version, dim_sys.sys_text AS Bezeichnung, AVG(fact_kje.ep_arb_m + fact_kje.ep_arb_w) AS Arbeiter, AVG(fact_kje.ep_ang_m + fact_kje.ep_ang_w) AS Angestellte, AVG(fact_kje.ep_gl_m + fact_kje.ep_gl_w + fact_kje.ep_kl_m + fact_kje.ep_kl_w) AS Lehrlinge, 56

57 AVG(fact_kje.ep_ins_m + fact_kje.ep_ins_w) AS Beschaeftigte, SUM((fact_kje.prod_ap_l1 + fact_kje.prod_ap_l2)/1000) AS AbgesetzteProduktion, AVG(fact_kje.betriebe) AS Betriebe FROM dim_bundesland INNER JOIN fact_kje ON dim_bundesland.dim_primary_bundesland = fact_kje.dim_primary_bundesland INNER JOIN dim_sys ON fact_kje.dim_pirmary_sys = dim_sys.dim_primary_sys AND fact_kje.sys_version = dim_sys.sys_version INNER JOIN dim_time ON fact_kje.dim_primary_monat = dim_time.dim_primary_monat AND fact_kje.dim_primary_quartal = dim_time.dim_primary_quartal AND fact_kje.dim_primary_jahr = dim_time.dim_primary_jahr INNER JOIN dim_version ON fact_kje.dim_primary_version = dim_version.dim_primary_version WHERE (dim_time.dim_primary_monat GROUP BY dim_bundesland.bundesland, dim_time.dim_primary_jahr, dim_version.dim_primary_version, </body> </html> dim_sys.dim_primary_sys, dim_sys.sys_version, dim_sys.sys_text HAVING (dim_sys.sys_version and left(dim_sys.dim_primary_sys,1) and dim_bundesland.bundesland and dim_time.dim_primary_jahr and dim_version.dim_primary_version <SelectParameters> <asp:controlparameter Name="version" ControlID="DropDownList0" /> <asp:controlparameter Name="sys_version" ControlID="DropDownList1a" /> <asp:controlparameter Name="code" ControlID="DropDownList1b" /> <asp:controlparameter Name="bundesland" ControlID="DropDownList2" /> <asp:controlparameter Name="dim_primary_monat1" ControlID="DropDownList3a" /> <asp:controlparameter Name="dim_primary_monat2" ControlID="DropDownList3b" /> <asp:controlparameter Name="dim_primary_jahr1" ControlID="DropDownList3c" /> <asp:controlparameter Name="dim_primary_jahr2" ControlID="DropDownList3d" /> </SelectParameters> </asp:sqldatasource> </form> Default.aspx.vb Partial Public Class _Default Inherits System.Web.UI.Page End Class 57

58 Web.config <?xml version="1.0"?> <configuration> <configsections> <sectiongroup name="system.web.extensions" type="system.web.configuration.systemwebextensionssectiongroup, System.Web.Extensions, Version= , Culture=neutral, PublicKeyToken=31BF3856AD364E35"> <sectiongroup name="scripting" type="system.web.configuration.scriptingsectiongroup, System.Web.Extensions, Version= , Culture=neutral, PublicKeyToken=31BF3856AD364E35"> <section name="scriptresourcehandler" type="system.web.configuration.scriptingscriptresourcehandlersection, System.Web.Extensions, Version= , Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirepermission="false" allowdefinition="machinetoapplication"/> <sectiongroup name="webservices" type="system.web.configuration.scriptingwebservicessectiongroup, System.Web.Extensions, Version= , Culture=neutral, PublicKeyToken=31BF3856AD364E35"> <section name="jsonserialization" type="system.web.configuration.scriptingjsonserializationsection, System.Web.Extensions, Version= , Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirepermission="false" allowdefinition="everywhere" /> <section name="profileservice" type="system.web.configuration.scriptingprofileservicesection, System.Web.Extensions, Version= , Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirepermission="false" allowdefinition="machinetoapplication" /> <section name="authenticationservice" type="system.web.configuration.scriptingauthenticationservicesection, System.Web.Extensions, Version= , Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirepermission="false" allowdefinition="machinetoapplication" /> <section name="roleservice" type="system.web.configuration.scriptingroleservicesection, System.Web.Extensions, Version= , Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirepermission="false" allowdefinition="machinetoapplication" /> </sectiongroup> </sectiongroup> </sectiongroup> </configsections> <appsettings/> 58

59 <connectionstrings> <add name="konjunkturstatistik" connectionstring="data Source=KULA13;Initial Catalog=Konjunkturstatistik;Integrated Security=True" providername="system.data.sqlclient" /> </connectionstrings> <system.web> <!-- Set compilation debug="true" to insert debugging symbols into the compiled page. Because this affects performance, set this value to true only during development. Visual Basic options: Set strict="true" to disallow all data type conversions where data loss can occur. Set explicit="true" to force declaration of all variables. --> <compilation debug="false" strict="false" explicit="true"> <assemblies> <add assembly="system.core, Version= , Culture=neutral, PublicKeyToken=B77A5C561934E089"/> <add assembly="system.data.datasetextensions, Version= , Culture=neutral, PublicKeyToken=B77A5C561934E089"/> <add assembly="system.web.extensions, Version= , Culture=neutral, PublicKeyToken=31BF3856AD364E35"/> <add assembly="system.xml.linq, Version= , Culture=neutral, PublicKeyToken=B77A5C561934E089"/> </assemblies> </compilation> <pages> <namespaces> <clear /> <add namespace="system" /> <add namespace="system.collections" /> 59

60 <add namespace="system.collections.generic" /> <add namespace="system.collections.specialized" /> <add namespace="system.configuration" /> <add namespace="system.text" /> <add namespace="system.text.regularexpressions" /> <add namespace="system.linq" /> <add namespace="system.xml.linq" /> <add namespace="system.web" /> <add namespace="system.web.caching" /> <add namespace="system.web.sessionstate" /> <add namespace="system.web.security" /> <add namespace="system.web.profile" /> <add namespace="system.web.ui" /> <add namespace="system.web.ui.webcontrols" /> <add namespace="system.web.ui.webcontrols.webparts" /> <add namespace="system.web.ui.htmlcontrols" /> </namespaces> <controls> <add tagprefix="asp" namespace="system.web.ui" assembly="system.web.extensions, Version= , Culture=neutral, PublicKeyToken=31BF3856AD364E35"/> <add tagprefix="asp" namespace="system.web.ui.webcontrols" assembly="system.web.extensions, Version= , Culture=neutral, PublicKeyToken=31BF3856AD364E35"/> </controls> </pages> <!-- The <authentication> section enables configuration of the security authentication mode used by ASP.NET to identify an incoming user. --> <authentication mode="windows" /> <!-- The <customerrors> section enables configuration of what to do if/when an unhandled error occurs 60

61 during the execution of a request. Specifically, it enables developers to configure html error pages to be displayed in place of a error stack trace. <customerrors mode="remoteonly" defaultredirect="genericerrorpage.htm"> <error statuscode="403" redirect="noaccess.htm" /> <error statuscode="404" redirect="filenotfound.htm" /> </customerrors> --> <httphandlers> <remove verb="*" path="*.asmx"/> <add verb="*" path="*.asmx" validate="false" type="system.web.script.services.scripthandlerfactory, System.Web.Extensions, Version= , Culture=neutral, PublicKeyToken=31BF3856AD364E35"/> <add verb="*" path="*_appservice.axd" validate="false" type="system.web.script.services.scripthandlerfactory, System.Web.Extensions, Version= , Culture=neutral, PublicKeyToken=31BF3856AD364E35"/> <add verb="get,head" path="scriptresource.axd" type="system.web.handlers.scriptresourcehandler, System.Web.Extensions, Version= , Culture=neutral, PublicKeyToken=31BF3856AD364E35" validate="false"/> </httphandlers> <httpmodules> <add name="scriptmodule" type="system.web.handlers.scriptmodule, System.Web.Extensions, Version= , Culture=neutral, PublicKeyToken=31BF3856AD364E35"/> </httpmodules> </system.web> <system.codedom> <compilers> <compiler language="vb;vbs;visualbasic;vbscript" extension=".vb" warninglevel="4" type="microsoft.visualbasic.vbcodeprovider, System, Version= , Culture=neutral, PublicKeyToken=b77a5c561934e089"> <provideroption name="compilerversion" value="v3.5"/> <provideroption name="optioninfer" value="true"/> <provideroption name="warnaserror" value="false"/> 61

62 </compiler> </compilers> </system.codedom> <!-- --> The system.webserver section is required for running ASP.NET AJAX under Internet Information Services 7.0. It is not necessary for previous version of IIS. <system.webserver> <validation validateintegratedmodeconfiguration="false"/> <modules> <remove name="scriptmodule" /> <add name="scriptmodule" precondition="managedhandler" type="system.web.handlers.scriptmodule, System.Web.Extensions, Version= , Culture=neutral, PublicKeyToken=31BF3856AD364E35"/> </modules> <handlers> <remove name="webservicehandlerfactory-integrated"/> <remove name="scripthandlerfactory" /> <remove name="scripthandlerfactoryappservices" /> <remove name="scriptresource" /> <add name="scripthandlerfactory" verb="*" path="*.asmx" precondition="integratedmode" type="system.web.script.services.scripthandlerfactory, System.Web.Extensions, Version= , Culture=neutral, PublicKeyToken=31BF3856AD364E35"/> <add name="scripthandlerfactoryappservices" verb="*" path="*_appservice.axd" precondition="integratedmode" type="system.web.script.services.scripthandlerfactory, System.Web.Extensions, Version= , Culture=neutral, PublicKeyToken=31BF3856AD364E35"/> <add name="scriptresource" precondition="integratedmode" verb="get,head" path="scriptresource.axd" type="system.web.handlers.scriptresourcehandler, System.Web.Extensions, Version= , Culture=neutral, PublicKeyToken=31BF3856AD364E35" /> </handlers> </system.webserver> <runtime> <assemblybinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentassembly> <assemblyidentity name="system.web.extensions" publickeytoken="31bf3856ad364e35"/> 62

63 <bindingredirect oldversion=" " newversion=" "/> </dependentassembly> <dependentassembly> <assemblyidentity name="system.web.extensions.design" publickeytoken="31bf3856ad364e35"/> <bindingredirect oldversion=" " newversion=" "/> </dependentassembly> </assemblybinding> </runtime> </configuration> DataSet1.xsd 63