Aufbau eines Data Warehouse für Analysedaten zu Kfz-Bauteilen

Transkript

1 Universität Stuttgart Fakultät Informatik, Elektrotechnik und Informationstechnik Institut für Verteilte und Parallele Systeme, Abteilung Anwendersoftware Universitätsstraße 38, D Stuttgart Robert Bosch GmbH Abteilung GS-AM/ENG3 Kruppstraße 1, D Stuttgart Diplomarbeit Nr Aufbau eines Data Warehouse für Analysedaten zu Kfz-Bauteilen Ralf Dieterle Studiengang: Informatik Prüfer: Prof. Dr.-Ing. habil. Bernhard Mitschang Betreuer: Dr. rer. nat. Holger Schwarz (Universität Stuttgart) Dipl. Ing. Jost Gerd Schneider (Robert Bosch GmbH) begonnen am: 17. Mai 2005 beendet am: 16. November 2005 CR-Klassifikation: H.2.4., H.2.7, H.4.2., J.1

2

3 Danksagungen An dieser Stelle möchte ich mich meinen Betreuern, Herrn Jost Gerd Schneider (Robert Bosch GmbH) und Herrn Holger Schwarz (Universität Stuttgart), die mich während dieser Arbeit fortwährend unterstützt haben, meinen Dank aussprechen. Ein besonderer Dank geht auch an die gesamte Abteilung GS-AM/ENG3 der Firma Robert Bosch GmbH, die mich wäh rend der sechs Monate, an deren ich bei ihnen tätig war, herzlich aufgenommen haben und mir bei Bedarf hilfreich zur Seite standen.

4

5 Inhaltsverzeichnis 1 Einleitung Zielsetzung Aufbau der Arbeit Grundlagen Data Warehouse Begriffsbestimmung Historie Architektur Data-Warehouse-Manager Datenquelle(n) und Datenqualität Monitor Arbeitsbereich (staging area) Extraktionskomponente Transformationskomponente Ladekomponente Basisdatenbank Data Warehouse Analyse Data Marts Repository Metadatenmanager Data Warehousing Dokumentenmanagement Aufgabe DMS-Architektur Entwurf eines Data Warehouse Vorgehensweise beim Entwurf Der konzeptuelle Entwurf Das starer-modell v

6 vi Inhaltsverzeichnis Das ME/R-Modell Multidimensional UML (muml) Application Design for Analytical Processing (APAPT) Dimensional Fact Model (DFM) Vergleich von konzeptuellen Modellen Relationale Speicherung Logischer Entwurf Relationale Umsetzung (ROLAP) Snowflake-Schema...29 Star-Schema Mischformen Galaxie: mehrere Würfel Multidimensional OLAP (MOLAP) Hybrid OLAP (HOLAP) Historisierung Physischer Entwurf Entwurfsstrategien Systemarchitekturen Projekt Aufgabe Saugmodule, Saugrohre und mehr Anforderungen Daten Funktionale Anforderungen Sonstige Anforderungen Erster Architekturentwurf des DW Analyse Daten und Datenquellen Funktionale und sonstige Anforderungen Zusätzliche Anforderungen Randbedingungen Standard-Software bei Robert Bosch SAP BW Oracle Weitere alternative Datenbank-Lösung...58

7 Inhaltsverzeichnis vii SAP BEx WebFOCUS Dokumentum Anforderungserfüllung Entscheidung für Oracle HTML DB Architekturbild nach Softwareauswahl Entwurf des Data Warehouse Konzeptueller Entwurf Logischer Entwurf Physischer Entwurf Implementierung Software/Framework Änderungen und Erweiterungen Besonderheiten Datenstruktur Beispiel Umsetzung Evaluation 91 7 Ausblick 93 8 Glossar 95 Anhang A Dokumentenmanagement 97 Anhang B Datenbankstruktur 113 Anhang C Prozeduren 121 Literaturverzeichnis 127 Abbildungsverzeichnis 131 Tabellenverzeichnis 133

8

9 1 Einleitung In vielen Bereichen der Wirtschaft werden Daten gesammelt. Diese Daten liegen allerdings meist in unterschiedlichen Formaten vor, sind an unterschiedlichen Stellen gespeichert und sind von unterschiedlichem Informationsgehalt bzw. von unterschiedlicher Qualität. Eine In tegration dieser Datenbestände mit einheitlichen Zugriffsmöglichkeiten scheint daher geboten, insbesondere dann, wenn aufgrund dieser Daten Entscheidungen getroffen werden sollen. Da tensammlungen z.b. über die Stärken und Schwächen der eigenen Produkte und Vergleiche mit Produkten der Mitbewerber (Benchmarking) können in diesem Bereich als ein wichtiges Mittel gesehen werden, um strategische Entscheidungen zu treffen oder diese zu untermauern. Ein Data Warehouse kann zur Dokumentation und als Arbeitsmedium dienen, indem Basisund Analysedaten strukturiert und an einer Stelle in einem einheitlichen Format abgelegt werden. Verknüpfungen zwischen diesen Daten, Dokumenten und Bildern bzw. Grafiken können hergestellt und daraus Berichte generiert werden. Die Anforderungen an die Berichte und Auswertungen können zusätzliche Funktionalitäten, wie sie z.b. von so genannten Reporting-Tools bereitgestellt werden, erforderlich machen. Der Umfang einer Dokumentensammlung und die Anforderungen an die Funktionalität, die für die Verwaltung dieser erforderlich erscheint, kann den Einsatz und die Anbindung eines eigenständigen Dokumentenmanagement-System sinnvoll erscheinen lassen. Viele Begriffe in diesem Umfeld sind Anglizismen und sollen auch als solche erhalten bleiben, da eine Übersetzung oftmals unangebracht ist und nicht zum besseren Verständnis beiträgt. So erscheint zum Beispiel eine Übersetzung des Begriffs Data Warehouse un sinnig. Wichtige Begriffe und Abkürzungen sind zusätzlich im Glossar näher erläutert, so dass hier eventuelle Verständnisprobleme beseitigt werden können. In dieser Diplomarbeit wird darauf verzichtet explizit geschlechtsneutrale oder gleichermaßen beide Formen (männliche und weibliche) von Bezeichnungen zu verwenden. Dies soll keine Diskriminierung darstellen, sondern der Einfachheit und Verständlichkeit des Textes dienen. 1.1 Zielsetzung Ziel dieser Arbeit ist es, Basis- und Analysedaten von Saugmodulen (und Saugrohren) in einem Data Warehouse bereitzustellen, daraus Vergleichsmöglichkeiten herzuleiten und die Ergebnisse durch Berichte bereitzustellen. 1

10 2 1.1 Zielsetzung Dazu müssen zunächst diese Datenbestände analysiert werden, um geeignete Datenstrukturen entwickeln zu können. Da die Basis- und Analysedaten auch Bilder, Grafiken und ganze Do kumente enthalten können, ist zu prüfen, wie diese genau aussehen, und ob eventuell dafür zu sätzliche Funktionalitäten erforderlich sind, wie sie nur Dokumentenmanagement-Systeme be reitstellen können. Des weiteren ist zu prüfen, in wie weit der Einsatz von Reporting-Tools oder zusätzlicher OLAP-Werkzeuge sinnvoll und notwendig ist, um die gewünschten Berichtsfunktionalitäten zu ermöglichen. Diese Funktionalitäten sollen schließlich in geeigneter Weise umgesetzt und bereitgestellt werden. Dabei sind die Anforderungen der Mitarbeiter und damit der Benutzer des Systems und die Rahmenbedingungen der Firma Robert Bosch GmbH, z.b. bezüglich Auswahl der Software, zu berücksichtigen. 1.2 Aufbau der Arbeit In Kapitel 2 wird eine Übersicht des Bereichs Data Warehouse dargelegt. Dabei wird neben der Erläuterung der gebräuchlichen Begriffe, die in diesem Zusammenhang verwendet werden, auch die prinzipiellen Aufgaben des Data Warehousing und eine typische Architektur eines solchen Systems vorgestellt. Zusätzlich wird ein kurzer Überblick eines typischen Doku mentenmanagement-systems gegeben, da eventuell eine Verwendung in Verbindung mit dem Data Warehouse in Betracht kommen könnte. Im dritten Kapitel werden die Aspekte beim Entwurf eines typischen Data Warehouse genauer betrachtet. Die einzelnen Phasen des Entwurfs werden ebenso vorgestellt, wie mögliche Entwurfsstrategien. In Kapitel 4 wird die Zielsetzung dieser Diplomarbeit zunächst näher beschrieben. Die An forderungen und die Analyse der Daten münden schließlich in einen ersten konzeptuellen Entwurf eines Data Warehouse. Die folgenden Schritte des logischen und physischen Entwurfs sind das Ergebnis der Randbedingungen, die zuvor betrachtet werden. Dabei wird auch die Auswahl der Software getroffen und begründet. Die Implementierung wird in Kapitel 5 dargelegt. Dabei wird die verwendete Software näher vorgestellt. Anhand von Beispielen der Implementierung wird gezeigt, wie das darunter liegende Framework eingesetzt und verwendet wird. Trotz der gewissenhaften Analyse (Kapi tel 3), ergaben sich durch den Einsatz der Software und neuen Erkenntnissen kleine Änderungen der Datenstruktur, die erläutert werden. Die Stärken und Schwächen des verwendeten Frameworks bezüglich der Aufgabenstellung werden bewertet und dargelegt. In Kapitel 6 wird eine detaillierte Bewertung vorgenommen, indem die Implementierung be züglich der Aufgabenstellung analysiert und bewertet wird. Das Kapitel 7 enthält einen Ausblick auf weitere Verbesserungen und Erweiterung, die vorge nommen werden können.

11 2 Grundlagen 2.1 Data Warehouse Begriffsbestimmung Eine einheitliche Definition des Begriffs Data Warehouse gibt es nicht. In der Literatur findet man mehrere, die im Folgenden betrachtet werden sollen: A Data Warehouse is a subject orientated, integrated, nonvolatile, (and) time variant collec tion of data in support of management's decisions. ([Inm93], Page 29) A data warehouse is a copy of transaction data specifically structured for querying and reporting. (Ralph Kimball in [KR+98]) Data-Warehouse-System: Informationssystem, bestehend aus allen für den Data-Warehouse-Prozess notwendigen Komponenten. Dies sind die Komponenten des Datenbeschaffungsbereichs und der Analyse, der Metadatenmanager, der Data-Warehouse-Manager und die Datenbanken Basisdaten bank, Data Warehouse und Repositorium. ([BG01] Seite 516) Während die Definitionen von [Inm93] und [KR+98] mehr in den Bereich der Unternehmens führung gehen bzw. Aussagen über einen möglichen Zweck eines Data Warehouse gemacht werden, beschreibt die Definition in [BG01] nur die verwendeten bzw. notwendigen Komponenten. Diese Komponenten werden später näher beschrieben und in einer Architektur dargestellt. In [Zeh03] wird die Definition von [Inm93] als zu begrenzt kritisiert und statt dessen die folgende Definition vorgeschlagen und begründet: Ein Data Warehouse ist ein physischer Datenbestand, der eine integrierte Sicht auf die zu grunde liegenden Datenquellen ermöglicht. [Zeh03] In der Arbeit tauchen weitere wichtige Begriffe aus dem Bereich Data Warehousing auf, die im Folgenden kurz erklärt werden sollen. 3

12 4 2.1 Data Warehouse Die Dimension bezeichnet eine mögliche Sicht auf assoziierte Kennzahlen, wobei eine end liche Menge (n 2) von Dimensionselementen (Hierarchieobjekten) eine semantische Be ziehung aufweisen. Sie beschreiben die orthogonale Struktur des Datenraums (z.b. Pro dukt, Gebiet, Zeit,...). Die Dimensionselemente sind die Knoten der Klassifikationshierarchie, d.h. die Klassifika tionsstufe beschreibt den Verdichtungsgrad. Die Klassifikationsschemata stellen eine einzelne Dimensionen dar, die u.a. eine Klassifi kationshierarchie beschreiben. Die Hierarchien als einfache Hierarchien, indem die höhere Hierarchieebene die aggregierten Werte genau einer niedrigeren Hierarchieebene enthält, d.h. der oberste Knoten (Top) enthält einen einzelnen Wert als Verdichtung der Dimension. Beispiel: Top Produktkategorie Produktfamilie Produktgruppe Artikel parallele Hierarchien, indem die Hierarchieebenen keine hierarchischen Beziehungen in den parallelen Zweigen besitzen. Die Parallelhierarchie ist dabei ein Pfad im Klassifika tionsschema (Konsolidierungspfad). Beispiel: Top Jahr Quartal Monat Tag und parallel dazu Top Jahr -Woche- Tag Ein Datenwürfel stellt die Grundlage der multidimensionalen Analyse dar. Dabei entspre chen die Kanten der Dimension und die Zellen entsprechen einer oder mehreren Kennzah len (Funktion der Dimension). Die Anzahl der Dimensionen bestimmt dabei die Dimensio nalität. Eine Darstellung bei zwei Dimensionen erfolgt als Tabelle, bei drei Dimensionen: als Würfel und bei mehr als drei Dimensionen als multidimensionale Domänenstruktur Historie Anfang der 60er Jahre wurden ähnliche Systeme meist als Executive Information Systemes (EIS) oder auch Executive Support Systems (ESS) bezeichnet. Sie dienten der qualitativen In formationsversorgung von Entscheidern, indem sie kleine, verdichtete Auszüge aus operativen Datenbeständen in statistische Berichte aufbereiteten. Die Architektur bestand aus MainframeSystemen. In den 80er Jahren kam der Begriff der Management Informationssystemen (MIS) auf, die mittels statischen Berichtsgeneratoren und der Einführung von Hierarchieebenen für die Aus wertung von Kennzahlen (Roll-Up, Drill-Down) auf Client-/Server-Systemen und graphischen Benutzungsoberflächen (GUIs) arbeiteten. Weitere Begriffe bzw. Systeme aus diesen Zeiten sind Management Decision Systems oder Decision Support Systems (DSS) bzw. Strategic Planing Systems. All diese Ansätze bzw. Systeme waren nicht immer sonderlich erfolgreich, da einige der Rahmenbedingungen, auch bedingt durch den Stand der Hardware-Entwicklung, einer effek tiven und kostengünstigen Realisierung entgegenstanden. So fehlte es meist an ausreichend schnellen Netzwerken, billigen, schnellen und groß dimensionierten Speichern und ausrei chend schnellen CPUs. Daneben war die Flexibilität, die Produktivität und die Vertrauens würdigkeit der existierenden Lösungen und deren Daten stark eingeschränkt.

13 2 Grundlagen 5 Seit dem Jahr 1992 wurde das Konzept eines Data-Warehouse eingeführt. Die redundante Haltung von Daten, unabhängig von Quellsystemen und operativen Daten, mit dem Ziel und der Beschränkung auf deren Analyse. Aufbauend auf dieses Konzept entwickelten sich OLAP (vgl. [CCS93]), indem interaktiv bzw. explorativ Datenanalysen auf Basis eines konzeptuellen Datenmodells ermöglicht wurden. OLTP OLAP Transaktionsvolumen hoch niedriger Antwortzeit gering (ms s) verfahrensabhängig (gering bis nicht relevant) (s min) Aktualisierungen oft selten (periodisch) Zeitraum aktuelle Periode Vergangenheit und aktuelle Daten Kontext Einzelapplikationen applikationsübergreifend Abfragen kurze Lese-/Schreibtransaktionen; lange ad-hoc bzw. vordefinierte vorhersehbar Lesetransaktionen Eigenschaften nicht abgeleitet, zeitaktuell, autonom, dynamisch abgeleitet, konsolidiert, integriert, stabil Verarbeitungseinheiten Tupel/Tupelmengen mehrdimensionale Datenstrukturen (Würfel) Datenvolumen wenige Datensätze (MB GB) viele Datensätze (GB TB) Anfragestruktur einfach, Einzeltupelzugriff komplex, Bereichsanfragen Fokus Lesen, Schreiben, Modifizieren, Löschen Lesen, periodisches Hinzufügen Datenquellen meist eine mehrere Anwendertyp Sachbearbeiter Manager, Controller, Analysten Tabelle 2.1 Vergleich von OLTP und OLAP Die Handhabung großer und komplexer Datensammlungen wurde durch die Konzepte des Knowledge Discovery in Databases (KDD) und Data Mining erweitert, indem versucht wird, verborgenes Wissen und Zusammenhänge aus den Datenbeständen herauszulösen. Dabei hat

14 6 2.1 Data Warehouse sich der Begriff der Business Intelligence (BI) herausgebildet, der heutzutage oftmals Verwendung findet. In der Tabelle 2.1 ist ein Vergleich (vgl. [BG01]) des im Data Warehousing verwendeten On Line Analytical Procesing (OLAP) gegenüber dem im operativen Bereich verwendeten Online Transaction Processing (OLTP) dargestellt Architektur Nach der Definition in [BG01], mit den dort erwähnten Komponenten, soll hier eine Refe renzarchitektur (siehe Abbildung 2.1) eines Data Warehouse (DWH) dargestellt werden. Sie besteht dabei aus denen, im Folgenden beschriebenen Komponenten, die teilweise auch optio nal sind. d.h. nicht unbedingt Teile eines Data-Warehouse-Systems (DWS) sein müssen Data-Warehouse-Manager Der Data-Warehouse-Manager ist die zentrale Komponente eines Data-Warehouse-Systems (DWS). Er initiiert, steuert und überwacht die einzelnen Prozesse. Die Initiierung des Daten beschaffungsprozesses kann dabei in regelmäßigen Zeitabständen (z.b. jede Nacht oder am Wochenende), bei wichtigen Änderungen von Quelldaten, die von den Monitoren gemeldet werden oder auf explizites Verlangen eines Nutzers, z.b. des Data-Warehouse-Administra tors, ausgelöst werden. Die weiteren Schritte des Ladeprozesses müssen, bezüglich der Daten bereinigung und Integration, überwacht und koordiniert werden. Treten dabei Fehler auf, so müssen diese dokumentiert und dem Data-Warehouse-Administrator gemeldet werden. An schließend muss ein Wiederanlaufmechanismus initiiert werden. Im zentralen Repository wird über den Metadatenmanager auf die Metadaten zugegriffen, die zur Steuerung der Abläufe und Parametrisierung der beteiligten Komponenten dienen Datenquelle(n) und Datenqualität Die Datenquellen sind der Lieferant für die eigentlichen Daten und Metadaten. Sie selbst sind dabei aber nicht Teil des DWH. Sie können intern, d.h. innerhalb des eigenen Unternehmens oder extern, z.b. Internet und heterogen bzgl. der Struktur, den Inhalten und den Schnitt stellen, z.b. Datenbanken und Dateien, sein. Die Auswahl der Datenquellen und deren Quali tät ist von entscheidender Bedeutung. Diese Auswahl ist bestimmt durch den Zweck des DWS, der rechtlichen, organisatorischen, technischen und zeitlichen Verfügbarkeit und even tuell den Preis für deren Erwerb, sofern es sich um externe Daten handelt. Die Datenquellen lassen sich z.b. nach der Herkunft (intern, extern), der Zeit (aktuell, histo risch), der Nutzungsebene (Primärdaten, Metadaten), dem Inhalt (Zahlen, Zeichenketten, Gra fiken, Dokumente), der Darstellung (numerisch, alphanumerisch, Datum, BLOB,...), der Ko dierung (Sprache, Zeichensatz) und nach dem Grad des Vertrauens bzw. der Glaubwürdigkeit klassifizieren: Entscheidend für die Qualität der Datenquellen sind die Konsistenz bzw. die Widerspruchs freiheit, die Korrektheit, d.h. die Übereinstimmung mit der Realität und die Vollständigkeit, d.h. keine fehlenden Werte oder Attribute. Da die zeitliche Dimension in einem Data Ware house eine entscheidende Rolle spielt, ist die richtigen Granularität von großer Bedeutung. Die Glaubwürdigkeit und Zuverlässigkeit der Datenquellen, sind bedingt durch die Nachvoll ziehbarkeit der Datenentstehnung und die Vertrauenswürdigkeit der Datenlieferanten. Für die

15 2 Grundlagen 7 Zielgruppe ist die Verständlichkeit und die Relevanz der Daten, sowie die Präsentation in einem geeigneten Format von entscheidender Bedeutung Monitor Die Monitore dienen der Entdeckung von Veränderungen in einer Datenquelle. Dabei existiert für gewöhnlich je Datenquelle ein eigener Monitor. Die Monitore werden dabei auf verschie dene Weise (trigger-basiert, zeit- bzw. zeitstempelbasiert) aktiv Arbeitsbereich (staging area) Der Arbeitsbereich dient der zentralen Datenbeschaffung (data staging area) und Daten haltung und als temporärer Zwischenspeicher zur Datentransformation. Im Arbeitsbereich wird die Transformation (zur Bereinigung und Integration der Daten) durchgeführt. Das Laden der transformierten Daten in das DWH bzw. die Basisdatenbank erfolgt erst, wenn diese Prozesse erfolgreich abgeschlossen wurden. Dies hat den Vorteil, dass weder die Quellen noch das DWH beeinflusst wird, d.h. es werden keine von vorne herein fehlerbehafte ten Daten in das DWH übernommen. Ist dieser Schritt erfolgreich, so werden sie aus dem Arbeitsbereich entfernt. Im Folgenden werden die einzelnen Arbeitsschritte und damit auch die beteiligten Komponenten, also die Extraktions-, Transformations- und Lade-Komponente, die zu sammenfassend auch als ETL-Komponenten bezeichnet werden, beschrieben Extraktionskomponente Als Extraktion wird die Übertragung der gewünschten Quelldaten in den Arbeitsbereich verstanden. Diese Übertragung kann sofort, periodisch, ereignisgesteuert oder auf Anfrage eines Nutzers, z.b. des Data-Warehouse-Administrators, geschehen (vgl. Monitoring-Strategi en). Diese Extraktion wird meist über Standardschnittstellen zu den operativen Systemen realisiert (ODBC, JDBC,...) und besitzt Strategien zur Fehlerbehandlung und Fortsetzung in Ausnahmefällen, d.h. ein Wiederaufsetzen bei Hardware- oder Softwarefehlern Transformationskomponente Unter der Transformation versteht man die Vorbereitung und Anpassung der Daten für das Laden in die Basisdatenbank bzw. das DWH. Dabei werden die Daten inhaltlich (Daten-/In stanzintegration und Bereinigung bezüglich der Qualitätsanforderungen) und strukturell (Schemaintegration bezüglich der Schemaanforderungen) bearbeitet. Das Ziel dabei ist die Überführung aller Daten in ein einheitliches Format (Datenmigration), d.h. die Anpassung der Datentypen, der Datumformate, der Maßeinheiten, der Kodierungen, der Kombination bzw. der Separierung von Attributwerten etc. Daneben werden durch Data Clearing bzw Data Cleansing Verunreinigungen der Daten beseitigt, indem fehlerhafte oder fehlende Werte, Red undanzen und veraltete Werte korrigiert bzw. beseitigt werden. Diese Tätigkeit wird auch als Data-Scrubbing & Data Auditing bezeichnet Ladekomponente Das Laden dient der Übertragung der transformierten Daten in die Basisdatenbank bzw. das DWH. Hierfür existieren spezielle Ladewerkzeuge, die große Datenmengen verarbeiten können (Bulk Loader). Dabei ist zu beachten, dass bereits existierende Daten im DWH nicht

16 8 2.1 Data Warehouse Data-Warehouse-System Analyse Data Warehouse Data WarehouseManager Laden Metadatenmanager Repository Basisdatenbank Laden Transformation Arbeitsbereich Extraktion Monitor Datenbeschaffungsbereich Datenfluss Datenquelle(n) Kontrollfluss Abbildung 2.1 Referenzarchitektur von Data Warehouse-Systemen überschrieben werden, sondern zusätzlich abgespeichert werden (Historisierung). Zeitlich be trachtet kann das Laden entweder online erfolgen, d.h. während die Basisdatenbank bzw. das DWH weiterhin zur Verfügung steht oder offline, wenn das DWH nicht für Anfragen bereit ist. Soll eine Beeinträchtigung der Benutzung minimiert werden, so können diese Ladevor gänge z.b. nachts oder am Wochenende geschehen.

17 2 Grundlagen Basisdatenbank Die Basisdatenbank ist die integrierte und physische Datenbasis für verschiedene Analysen. Dabei ist sie allgemeiner als das DWH, d.h. sie ist unabhängig von konkreten Analysen bzw. es existiert noch keine analysespezifische Datenaufbereitung. Ein oder auch mehrere DWH werden aus ihr mit qualitätsgesicherten Daten versorgt. Sie hat somit eine zentrale Sammel-, Integrations- und Distributionsfunktion von relevanten Daten. In der Praxis wird sie allerdings häufig, aus Aufwands- und Kostengründen, weggelassen Data Warehouse Das Data Warehouse ist eine Datenbank für Analysezwecke und orientiert sich bezüglich Struktur und Inhalt an diesen Bedürfnissen. Zusammen mit der Basisdatenbank, sofern vor handen und dem Repository, beinhaltet sie alle notwendigen Daten für die Analysen des Anwenders. Ihre Grundlage sind die klassischen Datenbanken mit all ihren Vorteilen, wie Recovery, Mehrbenutzerbetrieb, Datenneutralität und -unabhängigkeit. Unterstützt werden auch hier Massenlader (bulk loader) und die effiziente Anfrageverarbeitung durch spezielle Indexstrukturen (z.b. Bitmap-Index [CI98]) und Caching-Mechanismen Analyse Die Aufgabe der Analyse liegt in der Nutzung der gesammelten Daten durch bereitgestellte Analysewerkzeuge. Diese Werkzeuge unterstützen, neben der Analyse, auch die Navigation über die Daten und deren Sichtung. Die Analyse kann dabei die Bereiche der einfachen und erweiterten Aggregation, der Visualisierung, des Online Analytical Processing (OLAP), kom plexe statistischen Untersuchungen und das Data Mining bzw. Knowledge Discovery in Da tabases umfassen. Die Ergebnisse dieser Prozesse werden für die Weiterverarbeitung bzw. Weitergabe aufberei tet und können als Grundlage für Entscheidungen herangezogen werden. Eine Zurückspei cherung der Analysedaten, z.b. Plandaten, in die Basisdatenbank dient u.a. der Sicherung der Ergebnisse und kann gleichzeitig der Verbesserung der Qualität der Datenbasis dienen. Damit lassen sich auch die Ergebnisse zukünftiger Analysen verbessern. Dabei soll die Richtigkeit der Daten und damit deren Qualität, die Geschwindigkeit der Informationsbereitstellung, die Funktionalität und Benutzungsfreundlichkeit der Oberfläche (Usability) im Vordergrund stehen. Die Akzeptanz bei den Benutzern wird durch die Einhaltung diese Maßnahmen erhöht. Die Analysewerkzeuge (Business Intelligence Tools, BIT) sind die Schnittstelle zwi schen der Data-Warehouse-Anwendung und dem Endanwender. Als Darstellungsformen kommen dabei sowohl einfache Tabellen, als auch Pivot-Tabellen bzw. Kreuztabellen in Frage. Die Analysen können z.b. durch das Vertauschen von Zeilen und Spalten, durch die Veränderungen der Tabellendimensionen oder durch die Schachtelung dieser durchgeführt werden, wobei auch eine Hinzunahme von weiteren Dimensionen möglich ist. Eine Präsentation durch Grafiken, insbesondere bei großen Datenmengen hat sich als sinnvoll herausgestellt. Dabei können neben Text- auch Multimedia-Elemente einfließen. Bei umfangreichen Beständen an Dokumenten kann der Einbezug eines Dokumentenmanage ment-systems hilfreich sein. Die Funktionalität reicht vom einfachen Zugriff auf die Daten (data access), über einfache Be richtswerkzeuge (reporting tools), die z.b. durch sog. Ampelfunktionen (traffic lighting) verfügen, bis zur regelgebundenen Formatierung von Bereichen in Tabellen, Grafiken und

18 Data Warehouse Landkarten. Die Ampelfunktion hat ihren Namen wegen der häufig verwendeten Aufteilung der Grenzwerte in drei Klassen oder Kategorien mit der entsprechenden Farbgebung (grün, gelb, rot). Eine solche Beschränkung auf drei Farben bzw. Klassen ist jedoch nicht zwingend. Online Analytical Processing (OLAP) Ist die oben beschriebene Funktionalität nicht ausreichend, so kommen Tools aus dem Bereich des Online Analytical Processing (OLAP) zum Einsatz. Hierbei ist eine interaktive Daten analyse durch eine Klassifikationsnavigation möglich. Es lassen sich Berichte mit verdichte ten, quantitativen Werten und Kennzahlen (multidimensionale Sichtweise) erzeugen, die durch intuitive Navigationsoperationen des Analysewerkzeugs (Drill-Down, Roll-Up, DrillAcross,...) generiert werden. Durch Gruppierungs- und Berechnungsfunktionen, die z.b. statis tisch oder betriebswirtschaftlicher Natur sind, können erweiterte Erkenntnisse gewonnen werden, die zur Entwicklung und Validierung von Hypothesen dienen. Eine eventuell auch automatisierte Plausibilitätsprüfung ist ebenfalls möglich. Die typischen OLAP-Operationen, die durchgeführt werden können sind: Die Pivotierung, d.h. das Rotation bzw. Drehen des Würfels, entspricht der Vertauschung der Dimensionen. Die Analyse der Daten kann aus verschiedenen Perspektiven erfolgen. Roll-Up: Erzeugen von neuen Informationen durch Datenaggregation entlang des Konsol idierungspfades, d.h. die Dimensionalität bleibt erhalten (z.b. Jahr Quartal Monat Tag). Drill-Down: Navigation von aggregierten Daten zu detaillierteren Daten. Die Navigation erfolgt dabei entlang der Konsolidierungspfade (Komplementärfunktion zu Roll-Up). Drill-Accross: Ein Wechsel von einem Datenwürfel zu einem anderen Datenwürfel. Außerdem lassen sich individuelle Sichten durch die folgenden Operationen erzeugen: Slice: Ausscheiden von Scheiben (Slice) aus einem Datenwürfel, d.h. eine Verringerung der Dimensionalität. Dice: Ausschneiden eines kleineren Teilwürfels, d.h. die Dimensionalität bleibt erhalten und die Hierarchieobjekte werden verändert bzw. verkleinert (z.b. Fokus auf bestimmte Produkte, Regionen oder Zeiträume). Drill-Through: Wechsel von einer feinen OLAP-Perspektive auf Quellenansicht. Abgeleitet aus den zwölf Codd'schen Regeln [CCS93], die um weitere sechs erweitert wurden, fand eine 1995 von Nigel Pendse und Richard Creeth entwickelte Definition als FAS MI (Fast Analysis of Shared Multidimensional Information) Test [PC95] eine weitere Ver breitung, dessen Ausprägungen in Tabelle 2.2 zu sehen sind. Diese Regeln sind seither nicht verändert worden und vereinfachen, nicht zuletzt durch die leichte Merkbarkeit des Akro nyms, etwa vergleichbar mit den ACID-Eigenschaften von Transaktionssystemen, die Zu sammenfassung einer Definition von OLAP.

19 2 Grundlagen 11 FAST - Bereitstellung der Antworten innerhalb von fünf Sekunden - einfachen Analysen brauchen weniger als eine Sekunde - nur wenige Analysen brauchen länger als 20 Sekunden ANALYSIS - Bewältigung von jeglicher Geschäftslogik und statistischen Analysen, die für die Anwendungen und Anwender relevant sind - Anwender müssen in die Lage versetzt werden, neue ad-hocanalysen ohne Programmierkenntnisse formulieren zu können SHARED - sicherer Mehrbenutzerbetrieb durch Zugriffsrechte (bis auf Zellebene) - Sperrverfahren sowie stabile Sicherungs- und Wiederherstellungsverfahren MULTIDIMENSIONAL - multidimensionale konzeptuelle Sicht auf die Daten - Unterstützung von einfachen und mehrfachen Hierarchien, unabhängig von der darunter liegenden Datenbank INFORMATION - Fähigkeit zur Handhabung von großen Datenmengen (Skalierbarkeit) Tabelle 2.2 FASMI-Test Data Mining Das Data Mining ist eine Erweiterung der Analysefunktionen durch maschinelles Lernen und Techniken aus der Statistik. Dabei geht es um die Gewinnung von neuen Erkenntnissen und das Erkennen von neuen Zusammenhängen, ohne vor formulierte exakte Fragestellungen. So soll z.b. eine Vorhersage von Werten möglich sein. Assoziationsregeln und Segmente in nerhalb der Daten sollen erkannt und eine automatische Klassifikation der Elemente ermöglicht werden. Realisiert werden diese Darstellungsformen und Funktionalitäten durch einfaches Standard Reporting:, also Reportingwerkzeuge zur klassischen Berichtserstellung. Daneben existieren auch so genannte Berichtshefte, die eine grafische Entwicklungsumgebung zur Erstellung von Präsentationen, bestehend aus Tabellen und Grafiken etc., bereitstellen. Bei dynamischen Be richtsheften besteht die Möglichkeit der Navigation innerhalb der Tabellen. Sollen Aus wertungen interaktiv erstellt werden, so bedient man sich des Ad-hoc Query & Reporting, in dem einfache grafische Werkzeuge zur schnellen Erstellung und Präsentation von Berichten, mit der Kapselung der Datenbankanbindung und Anfragesprachen, bereitgestellt werden. Es stehen für diese Aufgaben spezielle Analyse-Clients zur Navigation, Manipulation bzw. Berechnung zur Verfügung. Weiterhin sind diese Clients geeignet für die umfangreiche Präsentation mit Werkzeugen zur interaktiven mehrdimensionalen Analyse. Verbreitet sind auch Speadsheet Add-Ins, die Tabellenkalkulationen durch Funktionalitäten der Datenan bindung und Navigation erweitern. Daneben existieren ausgewachsene Entwicklungsumge bungen, die Entwickler bei der Erstellung eigener Analyseanwendungen unterstützen.

20 Data Warehouse Als lassen sich zwei grundsätzliche Plattformen zur Präsentation, Analyse und Weiterver arbeitung von Daten aus Data Warehouses unterscheiden: Fat Clients: Systeme, die über eigene Speicher- und Verarbeitungskapazitäten verfügen (z.b. PCs). Die proprietären Anwendungsprogramme übernehmen dabei größtenteils oder auch vollständig die Anfrage, Kalkulation und Darstellung der Daten. Thin Clients: Systeme, bei denen die Funktionalität auf die Darstellung von Daten beschränkt ist, die auf einem Serversystem erzeugt wurden. Häufig kommen dabei Techniken aus dem WWW zum Einsatz, indem diese Daten in einem Browser dargestellt werden. Als Clients können z.b. auch Netzwerkcomputer (NC) oder PDAs eingesetzt werden. Neben der Darstellung in den oben genannten Systemen, können wichtige Daten und Nach richten zusätzlich z.b. per SMS, Fax, Pager oder durch automatische Sprachausgabe, z.b. per Telefon, übertragen werden. Bei dieser Art der Datenübermittlung spricht man von einer ak tiven Verteilung Data Marts Ist eine beschränkte Sicht, z.b. abteilungspezifisch, auf das DWH ausreichend, so können hierfür Data Marts eingesetzt werden. Die Vorteile liegen in der Eigenständigkeit, dem Da tenschutz, indem nur ein Teil der Daten sichtbar sind, der Lastverteilung und ihrem begrenz ten Datenvolumen. Sie können durch eine Verteilung von (Teil-)Replikaten des DWH umge setzt werden. Die Abgrenzung zwischen Data Warehouse und Data Mart ist fließend. So gibt es einerseits wohl kein Data Warehouse, das alle unternehmensweiten relevanten Daten in tegriert hat und andererseits können auch abteilungsweite Systeme so komplex sein, dass man eigentlich nicht mehr von einem Data Markt sprechen kann. Hat man ein Data Mart vor sich, so unterscheidet man zwischen abhängigen und unabhän gigen Data Marts. Durch die Verwendung einer Basisdatenbank wird die Problematik der un abhängigen Data Marts verschwinden. Wegen der teilweise nicht immer verwendeten Basis datenbank und den in der Literatur existierenden Begriff, seien sie anschließend dennoch er klärt und voreinander abgegrenzt. Abhängige Data Marts Die Verteilung des Datenbestandes erfolgt nach der Integration und Bereinigung (Basisdaten bank), sowie der Organisation entsprechend den Analysebedürfnissen innerhalb einer Abtei lung oder eines Teils eines Unternehmens. Dabei wird nach der Nabe und Speiche -Archi tektur (hub and spoke) vorgegangen, d.h. die abhängigen Data Marts sind in diesem Fall nur ein Extrakt inkl. der Aggregation des DWH. Zudem findet keine weitere oder spezielle Be reinigung der Daten statt, was zur Folge hat, dass die Analyse auf Data Marts konsistent zu den Analysen auf dem entsprechenden DWH ist. Eine einfache Realisierung ist durch die Nutzung von Replikations- oder Sichtmechanismen (Views) der zugrunde liegenden Daten banken des DWH möglich. Eine typische Architektur ist in Abbildung 2.2 zu sehen (vgl [BG01]). Bei der Aufteilung der Data Marts lassen sich strukturelle Extrakte, d.h. eine Beschränkung auf Teile des Schemas, z.b. bestimmte Kennzahlen oder Dimensionen, inhalt liche Extrakte, d.h. eine Beschränkung auf den Inhalt, z.b. Filialen oder aggregierte Extrakte, d.h. eine Verringerung der Granularität, z.b. Monatsergebnisse, unterscheiden.

21 2 Grundlagen 13 Analyse Analyse Data Mart 1 Data Mart 2 Analyse Analyse Data Mart 3 Data Warehouse Laden Abbildung 2.2 Architektur bei Verwendung von abhängigen Data Marts Analyse Analyse Analyse Analyse Data Warehouse Transformation Data Mart 1 Data Mart 2 Data Mart 3 Laden Laden Laden Data Mart 4 Laden Abbildung 2.3 Architektur bei Verwendung von unabhängigen Data Marts Unabhängige Data Marts Die unabhängigen Data Marts (vgl Abbildung 2.3) sind unabhängig voneinander entstandene kleine Data Warehouses bzw. Data-Warehouse-Systeme. Dies kann z.b. ein DWH einer einzelnen Organisationseinheit eines Unternehmens sein. Der verlockende Vorteil liegt in der geringeren Komplexität beim Entwurf und der Realisierung, sowie dem geringeren zeitlichen und finanziellen Aufwand, der beim Aufbau eines Systems zu investieren ist. Zumeist wird dabei auf die Basisdatenbank verzichtet und das Data Mart so ausgelegt, dass nur die abtei lungsspezifischen Bedürfnisse erfüllt werden. Eine Eignung für weiterreichendere Aus

22 Data Warehouse wertungen über das Data Mart hinaus ist damit allerdings nicht gegeben, d.h. die Flexibilität der Nutzung ist eingeschränkt. Es besteht die Möglichkeit zur Transformation und Integration in einen übergeordneten Analysekontext, wie dies in Abbildung 2.3 angedeutet ist. Hier sind jedoch die unterschiedlichen Analysesichten und die Konsistenz der Analysen aufgrund einer zusätzlich notwendigen Transformation problematisch. Dies erschwert möglicherweise eine Zusammenführung in ein einheitliches Data Warehouse Repository Im Repository werden die Metadaten des DWS gespeichert. Die Metadaten enthalten dabei alle Informationen über den Aufbau, die Wartung und die Administration des DWS, sowie die Befähigung des DWS zur Informationsgewinnung. Enthalten sind z.b. logische und konzeptu elle Datenbankschemata aus den Datenquellen, der Basisdatenbank und dem Data Warehouse, die Zugriffsrechte und die Prozessinformationen inklusive deren Verarbeitungsschritte und Parameter. Es sind also sowohl beschreibende Informationen, wie Inhalt, Struktur, Kontext und Bedeutung als auch prozessbezogene Informationen, die die Verarbeitung betreffen, gespeichert. Damit wird die Sicht der Metadaten bei traditionellen Datenbanken stark erwei tert, da dort hauptsächlich nur Schemainformationen und Zugriffsrechte verwaltet werden Metadatenmanager Im Metadatenmanager, der selbst eine Datenbankanwendung ist, wird die Metadatenver waltung gesteuert, inklusive der Integrations-, Zugriffs-, Abfrage- und Navigationsmöglich keiten, sowie das Versions- und Konfigurationsmanagement. Da viele Komponenten über den Metadatenmanager auf das Repository zugreifen, besitzt dieser eine definierte Schnittstelle (API) für Zugriffs- und Änderungsoperationen auf den Metadaten Data Warehousing Der Data-Warehouse-Prozess, der auch als Data Warehousing bezeichnet wird, lässt sich in die folgenden Phasen gliedern: 1. Die Überwachung der Quellen auf Änderungen durch Monitore. 2. Das Kopieren der relevanten Daten mittels Extraktion in einen temporären Arbeitsbereich. 3. Die Transformation der Daten im Arbeitsbereich, die Datenbereinigung (data cleansing) und/oder die Datenintegration. 4. Das Kopieren der Daten in die integrierte Basisdatenbank als Grundlage für verschiedene Analysen. Diese Phase ist optional, je nachdem, ob eine Basisdatenbank vorhanden ist. 5. Das Laden der Daten in das Data Warehouse. 6. Die Analyse, d.h. die Operationen auf den Daten des Data Warehouse. Zur Steuerung dieser Prozesse ist der Data-Warehouse-Manager zuständig. Die Phasen 2-5 werden im auch zusammenfassend als ETL bezeichnet [BG01].

23 2 Grundlagen Dokumentenmanagement Die Zielsetzung der Arbeit (vgl. Kapitel 1.1) ermöglicht grundsätzlich auch den zusätzlichen Einsatz eines Dokumentenmanagement-Systems. Um eine Entscheidung über die Anbindung und den Einsatz eines solchen Systems treffen zu können, soll hier zunächst ein kurzer Über blick über diese Thematik gegeben werden Aufgabe Die Aufgabe eines Dokumentenmanagement-Systemen (DMS) (vgl. [GSS99] und Abbildung 2.4) umfasst die Erfassung von extern und intern vorliegenden Dokumenten und Informa tionen, sowie deren Aufbereitung in eine geeignete elektronische Form. Diese Dateien müssen in geeigneten Formaten abgelegt und abgespeichert werden. Die Suche bzw. Recherche nach Dokumenten im Bestand und der Zugriff auf diese muss einfach möglich sein. Eine Darstel lung auf einem Bildschirm, der Ausdruck und die Weiterleitung von ausgewählten Doku menten. z.b. über oder Fax, soll ebenfalls ermöglicht werden. Zusätzlich soll eine Wei terverteilung von Dokumenten, sofern dies erforderlich ist, ermöglicht werden. Die Organisation des Daten- und Verarbeitungsflusses der Dokumente in einer Organisation und in den dabei einzuhaltenden Arbeitsablauf, soll definiert werden können. Eine Festlegung der Administration von Dokumenten und deren Ablagestrukturen, inklusive der Verwaltung der Zugriffsrechte von Benutzern oder Benutzergruppen, soll getroffen werden können. Dabei soll jedes Dokument nur an einer Stelle physikalisch gespeichert werden, außer im Fall von Replikation, dort existiert aber stets eine Master-Kopie. Dennoch ist sicherzustellen, dass für jeden Berechtigten alle Dokumente jederzeit, vollständig, aktuell und verknüpft mit den zuge hörigen im Kontext stehenden Dokumenten, zur Verfügung stehen (vgl. [GS+04]). Die Art und Häufigkeit des Zugriffs und die Lebensdauer, der zu erfassenden Dokumente, be stimmt dabei die notwendige Art der Speicherung. So können kurzlebige und normalerweise auch Daten mit mittlerer Lebensdauer durchaus auf Magnetplatten abgelegt werden. Dies kann sogar notwendig sein, wenn häufig darauf zugegriffen wird oder eine schnelle Verfüg barkeit erwünscht wird. In einem solchen Sonderfall werden auch langlebige Daten auf Magnetplatten oder auf optischen Archiven gespeichert. Ansonsten ist eine Speicherung auf Band unumgänglich, insbesondere dann, wenn die Datenbestände sehr umfangreich sein soll ten. Die Notwendigkeit auch langlebige Daten effizient und schnell verfügbar zu machen, soll durch den Ansatz der Dokumentenmanagement-Software zufriedenstellend gelöst werden. Neben der reiner Erfassung von Dokumenten in Papierform, z.b. durch Scannen, sollen auch bereits in digitaler Form vorliegende Dokumente, wie z.b. Audio- und Video-Clips und Bilder, integriert werden. Durch die Verknüpfung der Dokumente mit weiteren Daten in einer Datenbank können Zusammenhänge erfasst und auffindbar gemacht werden. In diesem Fall spricht man auch von einer Wissensbasis (Knowledgeware) DMS-Architektur Definiert man den Begriff Dokumentenmanagement-System (DMS) übergreifend, so deckt es die wesentlichen Aspekte eines Dokuments ab: Dies reicht von der Entstehung oder der Erfassung, über die Verteilung und die Recherche, bis hin zur Speicherung und Integration in

24 Dokumentenmanagement unterschiedliche Anwendungen und endet schließlich in der Ausgabe und den Versand (vgl. Abbildung 2.4 aus [GSS99]). Dokumentenverteilung Dokumentenerstellung und -bearbeitung Recherche, , Fax, Intranet, Workflow, Groupware Host-Anwendungen PC-Anwendungen, Scannen, Vorgangssteuerung Informationsintegration Korrespondenz, Fax, , ausgehende Post, Drucklisten, Wissensbasis, Business Rules Dokumentenspeicherung Kurzeit, Langzeit Caching, Sicherungen Abbildung 2.4 Aufgaben des Dokumentenmanagements Systematisiert man die Abläufe im Dokumentenmanagement und betrachtet das System unter dem Aspekt der IT-orientierten Anforderungen, so fallen typischerweise folgende unterschied liche Aufgaben an: 1. Erfassen der zu archivierenden Daten bzw. Dokumente, z.b. durch scannen und nachbe arbeiten. 2. Indizieren aller Dokumente, die zu archivieren sind. 3. Speichern, Sichern und Verwalten der Dokumente. 4. Suche und Abruf der Daten aus dem Archivbestand. 5. Darstellung der Daten auf dem Bildschirm und Weiterverarbeitung. 6. Ausgabe auf Papier oder andere Datenträger, Weiterleitung oder Weiterverteilung. 7. Kontrolle des Dokumentenflusses und teilweise automatische Initiierung von Be arbeitungsschritten. 8. Integration in die konventionelle IT bzw. Anbindung an andere Anwendungen.

25 2 Grundlagen 17 Dieser kurze Überblick über die Aufgabe und Architektur eines DokumentenmanagementSystems soll an dieser Stelle zunächst ausreichen. Eine ausführlichere Betrachtung, mit einer Abgrenzung zu einem Content-Management-System, ist im Anhang A zu finden.

26

27 3 Entwurf eines Data Warehouse 3.1 Vorgehensweise beim Entwurf Der typische Ablauf beim Entwurf und der Realisierung eines Data Warehouse ist in Abbil dung 3.1 beschrieben (vgl. [EN94]). Dabei werden nach der Analyse beim Datenbankentwurf drei Ebenen unterschieden. Reale Welt / Miniwelt Anforderungsanalyse Anforderungen Datenbank Funktionale Anforderungen Konzeptueller Entwurf Funktionale Analyse Konzeptuelles Schema ZugriffsSpezifikationen DBMS unabhängig Logischer Entwurf DBMS abhängig Logisches Schema Anwendungsprogramm Entwurf Physischer Entwurf Physisches Schema Abbildung 3.1 Entwurfsphasen eines Informationssystems 19

28 Vorgehensweise beim Entwurf Anforderungsanlyse Mit der Analyse wird versucht, die Anforderungen zu beschreiben, die an das System gestellt werden. Eine Beschreibung der operativen Daten zählt ebenso dazu, wie die Behandlung von NULL-Werten, die Datenqualität und die Stabilität des verwendeten Schemas. Ein Ver ständnis der Semantik der Daten, also was bestimmte Daten ausdrücken, ist ebenso wichtig, wie eine verständliche informelle Beschreibung der Zusammenhänge. Hilfreich ist auch die Verwendung von E/R-Modellen. Dieses E/R-Modell [Che76] der operativen Daten dient nun in der anschießenden Phase dazu, die relevanten Daten für das Data Warehouse zu identifizieren. Dabei findet eine Auswahl statt, welche Daten als Fakten und welche als Attribute verwendet werden sollen. In [GRM98a] und [GRM98b] ist eine Technik (Dimensional Fact Modell, DFM) beschrieben, wie aus einem solchen E/R-Modell ein konzeptuelles Schema erstellt werden kann (vgl. Kapi tel 3.2.5). Neben diesem Aufbau eines grafisch orientierten Attributbaums, kann es hilfreich sein, wenn eine Tabelle mit den Attributen, deren Beschreibung und einer Zuordnung als Fakt (F), Dimension (D) oder optionales Element (O) erstellt wird, wie dies in [HLV00] vorgeschlagen wird. Konzeptueller Entwurf Der konzeptuelle Entwurf beschreibt die Datenbankstruktur, die Semantik, die Beziehungen und die Integritätsbedingungen (Contraints). Dieser Entwurf stellt eine stabile Beschreibung des Datenbankinhalts dar und ist ein mächtiges und deklaratives Datenmodell. Als Eingabe dienen die Ergebnisse der Anforderungsanalyse, die in der vorhergehenden Phase erarbeitet wurden.. Die Ausgabe ist eine von einem DBMS unabhängige high-level Repräsentation der Anforderungen, die auch als konzeptuelles Schema bezeichnet wird. Wichtiges Ziel ist die Richtigkeit und die Lesbarkeit. Logischer Entwurf Der logische Entwurf ist die Abbildung des konzeptuellen Schemas auf ein Modell eines DBMS. Die Abbildung ist systemunabhängig, wenn mit festen Abbildungsregeln gearbeitet wird, die nur abhängig vom verwendeten Modell sind. Das Ergebnis ist aber trotzdem nur übertragbar auf ein anderes DBMS mit dem selben Modell. Die Abbildung ist systemabhän gig, wenn die spezifischen Funktionalitäten eines DBMS benutzt werden. Das Ergebnis ist eine Menge von DDL-Befehlen in der Sprache des gewählten DBMS. Als Eingabe dient das konzeptuelle Schema aus der vorhergehenden Entwurfsphase. Die Ausgabe ist ein logisches Schema, das dem Datenmodell des gewählten DBMS entspricht. Wichtig dabei ist die Richtigkeit der Übersetzung und die Effizienz des Schemas. Eine automatische Übersetzung ist möglich, wenn die entsprechenden Werkzeuge verwendet werden. Physischer Entwurf Der physische Entwurf bildet das logische Schema auf Speicher-Strukturen und Zugriffspfade des jeweiligen DBMS ab. Dabei spielen die Performance-Anforderungen, d.h. die Ant wortzeit, die Speichernutzung und der Durchsatz eine entscheidende Rolle. Durch

29 3 Entwurf eines Data Warehouse 21 Optimierungstechniken, wie die Denormalisierung, die Replikation oder durch das Einfügen von Indexen, insbesondere Bitmap-Indexen [CI98], wird versucht, den Anforderungen gerecht zu werden. Als Eingabe dient das logisches Schema aus der vorhergehenden Entwurfsphase. Die Ausgabe ist ein physisches Schema, das für ein spezielles DBMS zugeschnitten ist. Hauptaugenmerk liegt auf der Optimierung der Performance. Dabei gibt es durchaus Unterschiede zwischen den Entwurfsphasen beim klassischen relatio nalen und multidimensionalen Datenbankentwurf. Diese Unterschiede sind in Tabelle 3.1 (vgl. [Leh03]) zusammengefasst. Klassisch relationaler Daten bankentwurf Konzeptuelles Schema (semi-formal) Multidimensionaler Datenbankentwurf Varianten der Entity- diverse Ansätze für Entwurfsnotationen, z.b. Relationship-Metho ME/R, muml, ADAPT,... de Logisches Sche Relationen mit At ma (formal) tributen Datenwürfel mit Summenattributen: Fakten und Kennzahlen Dimensionshierarchien mit Kategorienattributen: klassifikatorische und beschreibende Attribute Physisches Schema Speicherorganisation (Primär- und Sekun därindexe, Parti tionierung,...) Relationale Speicher organisation (ROLAP): Schemamuster nach Star/Snowflake Multidimensionale Spei cherorganisation (MO LAP): Native Imple mentierung Tabelle 3.1 Vergleich von relationalem und multidimensionalem Datenbankentwurf 3.2 Der konzeptuelle Entwurf Es hat sich als sinnvoll herausgestellt, dass vor dem logischen Schemaentwurf des Data Ware house zunächst ein konzeptuelles Datenmodell entworfen werden sollte. Mit Hilfe dieses Modells wird versucht, die interessanten Zusammenhänge der Anwendungsdomäne zu modellieren. Dabei wird auf Beschränkungen der Machbarkeit zunächst keine Rücksicht ge nommen, sondern es wird versucht eine möglichst natürliche Sicht auf die Welt zu formu lieren. Erreicht werden soll dies durch den Einsatz von grafisch orientierten Techniken wie E/R-Diagramme oder UML (Unified Modeling Lanuage). Diese Modelle können als Grund lage für die weiteren Phasen des Entwurfprozesses dienen, indem daraus die notwendigen Designentscheidungen, wie z.b. die Auswahl eines Datenbankproduktes oder der Architektur variante, sowie Entscheidungen über Optimierungsstrategien, abgeleitet werden können. Es lassen sich die folgenden Basisanforderungen an den konzeptuellen Entwurf formulieren (vgl. [PP01])

30 Der konzeptuelle Entwurf Ausdrucksmächtigkeit (expressivness): Das Datenmodell muss mächtig genug sein, um die Unterschiede zwischen Daten- und Abhängigkeitstypen aufzuzeigen. Eine Beschreibung von Anwendungssemantiken und -contraints sollte möglich sein. Die Ausdrucksmächtigkeit steigt mir der Zahl der unterstützten Modellierungstrukturen. Einfachheit (simplicity): Sie steht im Widerspruch zur Ausdrucksmächtigkeit. Dabei sollte das Modell einfach genug sein, um von einem typischen Benutzer verwendet und verstanden zu werden. Dabei ist eine grafische Notation wünschenswert. Minimalität (minimality): Die Minimalität ist gegeben, wenn kein Konzept durch die Komposition anderer Konzepte dargestellt werden kann. Dabei sollte es keine Überschneidungen geben. Konstrukte wie z.b. explizite Dimensionen und Hierarchien werden nicht der konzeptuellen Ebene zuge ordnet, da sie keine Realweltobjekte, sondern nur vorgedachte Navigationspfade darstellen [PP01]. Formale Grundlage (formality): Alle Konzepte eines Modells haben eine einheitliche, präzise und wohldefinierte Interpre tation. Formale Konzepte können mathematisch manipuliert werden. Intuitive grafische Darstellung (vgl. Einfachheit) Bei der konzeptuellen Modellierungsphase eines Data Warehouse müssen die Fakten und ihre Eigenschaften dargestellt werden. Die zeitlichen Dimensionen müssen mit den Fakten ver bunden und Objekte repräsentiert, sowie ihre Eigenschaften und Verbindungen untereinander beachtet werden. Die Verbindungen zwischen den Objekten und Fakten müssen aufgezeichnet und die Dimensionen differenziert und in Hierarchien kategorisiert werden. Bei der Modellierung von hierarchischen Beziehungen besteht die Möglichkeit, dass zwischen strikten und nicht-strikten bzw. vollständigen und unvollständigen Beziehungen unterschieden wird [TBC99]. Eine strikte Beziehung bzw. Mitgliedschaft bedeutet, dass alle Mitglieder nur zu einer höhe ren Objektklasse gehören. Eine vollständige Mitgliedschaft bedeutet, dass alle Mitglieder zu einer höheren Objektklasse gehören und diese nur aus diesen Mitgliedern besteht. So ist z.b. die Beziehung Filiale Firma strikt und vollständig, da die Filialen zu genau einer Firma ge hören und die Firma genau aus diesen Filialen besteht. Die anfangs erwähnten Techniken der klassischen Modellierung sind allerdings nicht ganz ausreichend, da es ihnen an der für DWS, z.b. bezüglich des multidimensionalen Daten modells, notwendigen Semantik fehlt. Deshalb wurde das E/R-Model [Che76] und die UML um die Semantik zur multidimensiona len Datenmodellierung erweitert. Es handelt sich hierbei um das multidimensionale Entity/Re lationship-modell (ME/R-Modell) und die multidimensionale Unified Modeling Language (muml). Zudem existieren zahlreiche weitere Ansätze, wie z.b. ADAPT und starer. Diese Ansätze, sollen nun näher betrachtet werden.

31 3 Entwurf eines Data Warehouse Das starer-modell Das starer-modell, das in [TBC99] beschrieben ist, soll das bekannte Entity-RelationshipModell mit dem, am häufigsten im Bereich eines DWS verwendeten Star-Schema ver knüpften. Dazu werden einige neue Typen von Relationen hinzugefügt, um auch Hierarchien unterstützen und darstellen zu können. Die Erweiterungen gegenüber dem klassischen E/R-Modell sind wie folgt definiert: Die Fakten repräsentieren Fakten aus der realen Welt und werden durch eine Kreis dargestellt. Dabei sind sie immer mit einer zeitlichen Dimension verbunden, wie z.b. eine Rückzahlung. Die Entitäten repräsentieren die Objekte/Entitäten aus der realen Welt mit den entsprechenden Eigenschaften und werden durch ein Rechteck dargestellt, wie z.b. ein Kunde oder ein Kredit. Die Beziehungen (Relationship) sind die Verbindungen zwischen Entitäten oder zwischen Entitäten und Fakten und werden als Raute dargestellt. Dabei werden die Kardinalitäten mit 1:N, N:1 und N:M bezeichnet. Eine Beziehung z.b. zwischen Kunde und Adresse wird über hat oder eine Beziehung zwischen Kunde und Rückzahlung wird über bezahlt verbunden. Beziehungen zwischen Entitäten können die Ausprägungen Spezialisierung bzw. Gene ralisierung, Aggregation und Mitgliedschaft haben. Die Attribute sind statische Eigenschaften von Entitäten, Beziehungen und/oder Fakten und werden werden durch Ellipsen dargestellt, so z.b. Name von Entität Kunde. Fakten haben dabei die zusätzlichen Eigenschaften: stock (S), d.h. sie sind beliebig aggregierbar. Beispiel: Verkaufsmenge eines Artikel pro Tag. flow (F), d.h. sie beliebig aggregierbar mit der Ausnahme der temporalen Dimension, z.b. der Lagerbestand. value-per-unit (V), d.h. aktuelle Zustände sind nicht summierbar; nur MIN(), MAX(), AVERAGE() sind zulässig, z.b. Steuersatz. Dabei werden sie durch die zusätzlichen Buchstaben (S,F und V) innerhalb der Ellipse links abgetrennt dargestellt Das ME/R-Modell Diese Erweiterung von [SB+98] stellt eine Spezialisierung des E/R-Modells dar. Alle neu ein geführten Elemente des ME/R-Modells sollten nur Spezialfälle der ursprünglichen E/R-Kon strukte sein. Sie reduzieren damit weder die Ausdrucksmächtigkeit noch die Flexibilität des E/R-Modells. Die Anzahl der Erweiterungen des E/R-Modells sollen gering sein, so dass es für erfahrene E/R-Modellierer leicht erlernbar ist. Außerdem ermöglicht ein minimaler Satz von Erweiterungen die einfache Übertragbarkeit von wissenschaftlichen Ergebnissen, z.b. durch eine formale Fundierung, vom E/R-Modell auf das ME/R-Modell, indem nur die spezi fischen Erweiterungen zu betrachten und anzupassen sind.

32 Der konzeptuelle Entwurf Obwohl auf Minimalität ausgerichtet, sollte die Spezialisierung mächtig genug sein, um die grundlegende multidimensionale Semantik auszudrücken, d.h. die Möglichkeit der Unter scheidung von qualifizierenden (Klassifikationsschema) und quantifizierenden (Würfelstruk tur) Daten und der hierarchischen Struktur der Klassifikation. Gemäß diesen Überlegungen werden die folgenden spezialisierten Konstrukte eingeführt: Entitätenmenge Dimension Level (Klassifikationsstufe): keine explizite Modellierung von Dimensionsstufen n-äre Beziehungsmenge Fact : Kennzahlen als Attribute der Beziehungen binäre Beziehungsmenge Classification bzw. Roll-Up zur Verbindung von Klassifi kationsstufen: definiert gerichteten, zyklenfreien Graphen (directed acyclic graph, DAG). fact name a fact relationship set level name a dimension level set a rolls-up relationship set Abbildung 3.2 Die grafische Notation der ME/R-Elemente Multidimensional UML (muml) Die Multidimensional UML (muml) ist eine multidimensionale Erweiterung der Unified Modeling Language (UML). Damit ist die Erstellung von konzeptuellen und multidimensiona len Schemata mittels UML-Notation möglich. Als Lieferant der multidimensionalen Sprach konstrukte und Semantik diente die Multidimensional Modeling Language (MML), die durch die drei Mechanismen Contraints, Eigenschaftswerte (tagged value) und Stereotypen in die UML integriert werden können, ohne dessen Metamodell verändern bzw. erweitern zu müssen. Die weite Verbreitung, die Möglichkeit der sprachinhärtenten Erweiterung und die Unterstützung durch bestehende CASE-Tools, z.b. IBMs Rational-Software Familie, trug zur Verbreitung dieser objektorientierten Notation bei. Ausgewählte Modellierungskontrukte der muml (vgl. [BG01])sind in Abbildung 3.3 zu se hen.

33 3 Entwurf eines Data Warehouse <<Fact-Class>> Bezeichnung 25 Attr1: Attributtyp1 Attr2: Attributtyp2 /Attr3: Attributtyp3 {formula, parameter} Fakt-Klasse mit abgeleiteter Kenngröße <<Dimension>> Bezeichnung <<Dimensional-Class>> Bezeichnung 1..* Dimensionsklasse 1 Dimensionsbeziehung <<Roll-Up>> Produktgruppe Roll-Up-Beziehung Abbildung 3.3 Ausgewählte muml-modellierungskonstrukte Application Design for Analytical Processing (APAPT) Die Besonderheit des von [Bul96] entwickelten ADAPT, ist der revolutionäre Ansatz, d.h. dieses Modell basiert nicht auf bereits existierende Modelle. Diese grafische Modellierungs notation hat keine formale Grundlage. Sie besitzt eine Beschreibung für sämtliche MetadatenObjekte und eine Unterstützung von Berechnungsvorschriften. Die wichtigsten Elementegruppen sind dabei die Kernelemente, d.h. Darstellungen für Hypercube, Dimensionen, Berechnungsformeln, Hierarchie und Datenquellen, die Dimensionstypen für aggregierte, sequentielle und partitionierte Dimensionen, Eigen schafts-, Kennzahl- und Tupeldimensionen, die Dimensionselemente der Hierarchiestufe, Dimensionsausschnitte, Dimensionsattribute und Ausschnitte) Es existiert also eine sehr umfangreiche Notation mit zahlreichen Symbolen. Der Vorteil dabei ist, dass damit auch komplexe Sachverhalte in einer geeigneten Weise dargestellt werden können. Dies ist aber auch gleichzeitig der größte Nachteil, denn die Notationsvielfalt muss erst erlernt und korrekt angewendet werden Dimensional Fact Model (DFM) Das von [GRM98b] entwickelte Dimensional Fact Model (DFM) besitzt neben einer veränderten Notation auch eine methodische Vorgehensweise [GRM98a] zur Transformation von einem in dritter Normalform befindlichen Entity-Relationship-Modell in multidimensio nale Strukturen, also das DFM.

34 Der konzeptuelle Entwurf Dabei wird folgendermaßen vorgegangen: 1. Fakten definieren 2. Für jeden Fakt 1. Baue den Attributbaum (attribute tree) 2. Korrigiere den Attributbaum (sofern notwendig), indem Teile abgeschnitten (pruning) oder herausgeschnitten/transplantiert (grafting) werden 3. Definiere die Dimensionen 4. Definiere die Kennzahlen 5. Definiere die Hierarchien manager manager hierarchy weight dimension attribute season department marketing group category city type brand product diet day of week fact holiday sale district SALE year sales manager quarter month date store qty sold revenue no. of customers city address measure / fact attribute aggregation dimension country state phone promotion begin date non dimensional attribute price reduction end date ad type cost Abbildung 3.4 Beispiel eines Dimensional Fact Model (DFM) Das Ziel liegt dabei insbesondere in der Modellierung von typischen Strukturen von Data Warehouse- und OLAP-Anwendungen. Das konzeptuelle Modell besteht aus einer Menge von

35 3 Entwurf eines Data Warehouse 27 Faktentabellen, die sich weiter in Fakten, Dimensionen und Hierarchien aufschlüsseln lassen. Die Fakten beinhalten die Faktenattribute oder auch Maße (measures) genannt. Jeder Knoten, der direkt mit der Faktentabelle in Beziehung steht, stellt eine Dimension dar. Diese Knoten bestehen aus den Basiselementen mit der geringsten Granularität. Die stufenweise, parallele oder mehrfache Verdichtung dieser Objekte stellt dann eine Hierarchie dar (vgl Abbildung 3.4). Die Hierarchie hat ihre Wurzel bei der Dimension mit den Daten feinster Granularität und entwickelt sich über ihre Aggregationsebenen. In den Dimension sind neben den Objekten der Aggregationsebene auch so genannte nicht-dimensionale Attribute (non-dimensional attribu tes), die weitergehende Informationen der jeweiligen Aggregationsebene enthalten und selbst nicht aggregiert werden können Vergleich von konzeptuellen Modellen Ein in [TP+01] gemachter Vergleich der konzeptuellen multidimensionalen Modellierungsan sätze ist in Tabelle 3.2 zu sehen. Diese Übersicht bietet einen schnellen Überblick über die Funktionalität und Mächtigkeit der einzelnen Modelle. Sie kann somit als Anhaltspunkt dienen, wenn die Auswahl eines Modells aufgrund einer bestimmten Funktionalität erfolgen muss. Multidimensionale Modellierungseigenschaften Modell DFM M/ER StarER Strukturelle Ebene Fakten: - viele-zu-viele-beziehungen mit bestimmten Dimensionen - Atomare Maße - Abgeleitete Maße - Additivität Nein Ja Nein Ja Nein Ja Nein Nein Ja Ja Nein Ja Dimensionen: - Mehrfache und alternative Pfadklassifikationshierarchien - Nicht-strikte Klassifikationshierarchien - Vollständige Klassifikationshierarchien - Kategorisierung von Dimensionen Ja Nein Nein Nein Ja Nein Nein Ja Ja Ja Ja Ja Dynamische Ebene Spezifikation von Anfangserfordernissen der Benutzer OLAP-Operatoren Modellierung des Systemverhaltens Ja Nein Nein Ja Ja Ja Nein Nein Nein Ja Ja Ja Nein Ja Nein Grafische Notation Automatische Generierung in Verbindung mit kommerziellen OLAP-Anwendungen Tabelle 3.2 Vergleich von multidimensionalen konzeptuellen Modellen

36 Der konzeptuelle Entwurf Relationale Speicherung Bei einer relationalen Speicherung der Daten, also der Abbildung der multidimensionalen Konstrukte (Würfel, Dimensionen und Klassifikationshierarchien) auf ein relationales Daten bankmodell gilt es einiges zu beachten. Das Ziel dieser Abbildung muss sein, den Verlust von anwendungsbezogener Semantik des multidimensionalen Modells zu vermeiden. Dabei ist eine effiziente Übersetzung der multi dimensionalen Anfragen zu gewährleisten und eine effiziente Verarbeitung der übersetzten Anfragen sicherzustellen. Zusätzlich muss die Wartung, d.h. z.b. das Laden neuer Daten einfach und schnell zu erledigen sein. Neben diesen Anforderungen ist zu beachten, dass wegen der Anfragecharakteristik von Analyseanwendungen und den dabei auftretenden Datenvolumen spezielle Randbedingungen erfüllt sein müssen, z.b. bezüglich der Antwortzeit, die durch eine vollständige Nor malisierung im Allgemeinen nicht erreicht werden können. Produkt Duett Lavamat S Zeit München, Isartor Nürnberg, Breite Gasse Region Artikel Filiale Tag Duett Nürnberg, Breite Gasse Duett München, Isartor Lavamat S München, Isartor Abbildung 3.5 Dualismus von Würfel und Tabelle Verkäufe

37 3 Entwurf eines Data Warehouse 29 Wird bei der Abbildung eines Datenwürfels auf die Klassifikationshierarchie verzichtet, so kann bereits jede einzelnen Relation selbst als multidimensionaler Würfel betrachtet werden. Die einzelnen Spalten der Relation werden dabei als Dimension aufgefasst. Ein Tupel ent spricht dabei genau einer Zelle des multidimensionalen Würfels. Die Abbildung erfolgt also folgendermaßen (vgl. Abbildung 3.5): Dimension und Kennzahlen Spalten der Relation Zelle Tupel 3.3 Logischer Entwurf War der konzeptuelle Entwurf noch unabhängig von der Realisierung, so hängen die zwei folgenden Entwurfsphasen von der verwendeten Datenbanktechnologie ab. Daher soll hier zu nächst ein kurzer Überblick über die möglichen Ausprägungen des OLAP gegeben werden Relationale Umsetzung (ROLAP) Werden die multidimensional strukturierten Daten in einem relationalen Datenbanksystem abgelegt so spricht man von relationalem OLAP (ROLAP). Die Problematik hierbei ist, dass bei dieser Art der Speicherung Semantik verloren geht oder nur noch implizit im Schema vor handen ist. Deutlich wird dies in der Unterscheidung zwischen Dimension und Kenngrößen. Die Faktentabellen mit ihrer Tabellendefinition lassen dabei nicht mehr erkennen, ob ein At tribut eine Kenngröße oder eine Dimension ist, so z.b. Verkäufe oder Produkt_ID. Auch eine Unterscheidung zwischen einem Attribut, das zum Aufbau einer Klassifikationshierarchie dient oder nur beschreibenden Charakter hat, ist nicht möglich. Zusätzlich gehen Informa tionen über den Aufbau der Dimension, also die sog. Dill-Pfade, verloren. So bildet z.b. die Region eine Klassifikation von Städten. Zur Minderung oder Vermeidung dieses Verlustes der Semantik werden in den Systemkata logen der Datenbanksysteme zusätzliche Metadaten gehalten, die allerdings proprietär und nicht standardisiert sind, also vom verwendeten Datenbanksystem abhängen. In DBMS von Oracle z.b. kann dies durch die CREATE DIMENSION- bzw. CREATE HIERARCHYBefehle beim Erstellen der Strukturen erreicht werden. Die Transformation multidimensionaler Anfragen in eine relationale Repräsentation führt außerdem zu sehr komplexen Anfragen. Diese Anfragen lassen sich nur schwer ohne die Un terstützung von Werkzeugen erstellen. Daher kommen spezielle Anfragewerkzeuge, die sog. OLAP-Clients, zum Einsatz. Werden die Klassifikationshierarchien nicht beachtet, so müssen diese durch erweiterte Techniken abgebildet werden, welche anschließend betrachtet werden sollen Snowflake-Schema Für jede Klassifikationsstufe wird eine eigene Tabelle angelegt. In dieser Tabelle sind neben der ID, die die Klassifikationsknoten dieser Klassifikationsstufe enthalten, auch die beschreibenden Attribute, wie z.b. Marke, Hersteller oder Bezeichnung, verzeichnet. Wegen

38 Logischer Entwurf der 1:n-Beziehungen zwischen direkt benachbarten höheren Klassifikationsstufen müssen in den Tabellen zusätzlich deren Schlüssel als Fremdschlüssel aufgenommen werden (vgl. Abbildung 3.6). Eine zusätzliche Faktentabelle enthält die Kenngrößen (measures, variables oder facts) eines Datenwürfels. Über die Fremdschlüssel sind die jeweils niedrigsten Klassifikationsstufen einer Dimension verknüpft. Diese Fremdschlüssel entsprechen den Zellkoordinaten in der multidimensionalen Datenansicht und bilden damit den zusammengesetzten Primärschlüssel für die Faktentabelle. Abbildung 3.6 Beispiel eines Snowflake-Schemas Bezüglich der Klassifikationsbeziehungen, z.b. Produktgruppe Produktfamilie, ist das Snowflake-Schema normalisiert. Daher können keine Änderungsanomalien auftreten. Allerdings sind Join-Operationen über mehrere Tabelle notwendig. Im Beispiel oben sind dies elf Tabellen. Um diese Nachteile etwas zu entschärfen, empfiehlt es sich in den Schlüssel feldern numerische Werte zu verwenden, die automatisch generiert werden können und somit künstliche Schlüssel (surrogate keys) darstellen. Zudem sollte auf textuelle Beschreibungen an dieser Stelle verzichtet werden Star-Schema Das Star-Schema kann über eine Denormalisierung, der zu einer Dimension gehörenden Tabellen, aus dem Snowflake-Schema abgeleitet werden. Somit ergibt sich für jede Dimensi on genau eine Tabelle. Es entfallen damit viele der teuren Verbundoperationen. In Abbildung 3.7 ist das obige Beispiel als Star-Schema ausgeführt. Im Vergleich zum Snowflake-Schema, in dem jede Tabelle jeweils den Namen der Klassifi kationsstufe trägt, sollte im Star-Schema der Oberbegriff für die jeweilige Dimension als

39 3 Entwurf eines Data Warehouse 31 Tabellenname genommen werden. Die Faktentabelle ist, bei beiden Schemata in gleicher Weise, normalisiert. Durch die Denormalisierung der Dimensionstabellen werden Red undanzen bewusst in Kauf genommen. In der Praxis hat sich das Star-Schema als vorteilhaft erwiesen, da die Anfragen häufig auf einer höheren Granularitätsstufe, z.b. Produktkategorie, erfolgen. Bei Anfragen diesen Typs werden viele Join-Operationen, gegenüber dem Snowflake-Schema, eingespart und die Ant Abbildung 3.7 Beispiel eines Star-Schemas wortzeiten verkürzt. Außerdem ist das Datenvolumen in den Dimensionstabellen meist gering, besonders im Vergleich zur Größe der Faktentabelle. Trotz der redundanten Speicherung von Inhalten durch die Denormalisierung, werden sie nicht dramatisch vergrößert. Daneben werden selten Änderungen an den Klassifikationen vorgenommen. Damit hält sich die Gefahr von Änderungsanomalien in Grenzen, da die Ladeoperationen in einem kontrollierten Prozess erfolgen. Neue Faktendaten können hingegen leicht hinzugefügt werden. Die Vorteile des Star-Schemas lassen sich damit wie folgt zusammenfassen: Einfache Struktur: Die Verständlichkeit wird durch die relativ einfache Struktur begünstigt und erleichtert da mit eine Umsetzung innerhalb einer multidimensionalen Verarbeitungseinheit. Dies gilt auch für manuell erstellte Anfragen. Einfache und flexible Darstellung von Klassifikationshierarchien: Eine einfache und flexible Darstellung von Klassifikationshierarchien wird durch Spalten in Dimensionstabellen möglich. Die dabei auftretenden Redundanzen sind im Vergleich zur gesamten Datenbank meist gering. Im Star-Schema ist eine Darstellung der Bezie hungen zwischen den Klassifikationsstufen nicht mehr möglich. Effiziente Anfrageverarbeitung innerhalb der Dimensionen: Die in denormalisierter Form vorliegenden Dimensionstabellen erlauben eine schnelle Er mittlung der Anzahl, der mit der Faktentabelle zu verknüpfenden Tupel, wenn Selektions prädikate höherer Dimensionsstufen zur Einschränkung verwenden werden. Dies ist auch ohne teure Verbundoperationen möglich.

40 Logischer Entwurf Der konkrete Anwendungsfall entscheidet letztendlich darüber, welches Schema das beste, d.h. am geeignetsten ist. Je nachdem, ob ein schneller Datenzugriff (Star-Schema) oder ein geringerer Speicherplatzbedarf und eine leichtere Änderungsmöglichkeit (Snowflake-Schema) im Vordergrund stehen, entscheiden über das ideale Schema. In der Praxis haben sich daher auch Mischformen entwickelt Mischformen Bei den Mischformen werden die einzelnen Dimensionen, je nach Anforderung, entweder im Star-Schema (denormalisiert) oder in Snowflake-Schema (normalisiert) dargestellt. Die Gründe sind im Prinzip die selben, wie schon oben genannt, nur jetzt bezogen auf jeweils eine Dimension. Im Einzelnen sind dies: Frequenz der Änderung: Werden bei einer Dimension häufig Änderungen vorgenommen, so ist es günstiger diese zu Normalisieren, um den Pflegeaufwand zu verringern ( Snowflake-Schema). Anzahl der Dimensionselemente: Hat eine Dimension sehr viele Elemente in der niedrigst en Klassifikationsstufe, so treten im denomalisierten StarSchema sehr viele Redundanzen auf. Anzahl der Klassifikationsstufen innerhalb einer Dimension: Auch die Anzahl der Klassifi kationsstufen erhöht im Star-Schema die Anzahl der Redundanzen. Materialisierung von Aggregaten für Dimensionsstufen: Eine Antwortzeitverbesserung ist durch die Normalisierung der materialisierten Aggregate einer Dimension in einer Klassifi kationsstufe möglich Galaxie: mehrere Würfel Ist eine Faktentabelle, wie z.b. im Star-Schema in Abbildung 3.6, nicht ausreichend, weil mehrere Kennzahlen mit jeweils unterschiedlichen Dimensionen benötigt werden, müssen mehrere Faktentabellen und damit mehrere, auch teilweise mit dem gleichen Dimensions tabellen verknüpfte, Schemata angelegt werden. Sie werden dann als Multi-FaktentabellenSchemata oder Galaxie bezeichnet. Andere Bezeichnungen sind auch Multi-Cubes oder Hy per-cubes Multidimensional OLAP (MOLAP) Wird das multidimensionale Datenmodell in einer multidimensionalen Speicherstruktur verwirklicht, so spricht man von Mulidimensional OLAP oder kurz MOLAP. Die Unter stützung der Speicherstruktur ist allerdings nicht auf den OLAP-Bereich begrenzt, sondern wird auch von ganz unterschiedlichen Werkzeugen genutzt, wie z.b. von Data Mining und Reporting-Tools. Bei einer Speicherung von größeren Datenbeständen (> 100 GB) hat sich die multidimensionale Speicherung allerdings als nicht vorteilhaft herausgestellt [BG01] Hybrid OLAP (HOLAP) Bei einer Kombination der beiden obigen Ansätze spricht man von Hybrid OLAP (HOLAP). Hier liegen die Daten zwar relational vor, einige Teile davon werden allerdings zusätzlich in

41 3 Entwurf eines Data Warehouse 33 mehrdimensionalen Strukturen abgelegt. Dies kann die Effizienz bestimmter Analysen erhö hen. Der MOLAP- und HOLAP-Ansatz soll in dieser Arbeit nicht weiter verfolgt werden, da den meisten Data-Warehouse-Systemen relationalen Datenbanken zugrunde liegen und dies auch für diese Arbeit am praktikabelsten erscheint Historisierung Ein wichtiger Aspekt eines Data Warehouses ist die Historisierung, also der Erhalt von zeitli chen Veränderungen der Daten. So soll es möglich sein, auch im Nachhinein zu sehen, welche Zusammenhänge zu einem bestimmten Zeitpunkt bzw. Zeitraum bestanden. Zur Lösung dieser Problematik wurden bereits in [Kim96], dort als slowly changing dimensions be zeichnet, einige Vorschläge bzw. Lösungsstrategien entworfen und vorgestellt. Es handelt sich dabei um drei Methoden, die als Typ 1, Typ 2 bzw. Typ 3 bezeichnet werden und zur Lösung der Problematik angeboten werden. Typ 1: Überschreiben Das sich ändernde Attribut wird einfach mit dem aktuellen Wert überschrieben. Der alte Wert geht verloren und damit auch die historische Information. Typ 2: Erzeugung eines neuen dimensionalen Eintrags In der Dimensionstabelle wird ein neuer Eintrag mit einem neu erzeugten Primärschlüssel eingefügt. Damit ergibt sich ein neuer künstlicher Schlüssel. Alternativ kann zusätzlich eine zusätzliche Spalten für die Gültigkeit (als Datum), die aktuellen und vorherigen Werte und eines Verfalldatums eingefügt werden. Eine solche Aufnahme von Zeitinformationen in die Dimensionstabelle wird in [Kim96] allerdings als unnötig bezeichnet, da sich diese Änderungen über die Faktentabelle zeitlich einordnen lassen. Typ 3: Erzeugung eines zusätzlichen Feldes das den aktuellen Wert enthält Neben dem Hinzufügen des Attributs für den aktuellen Wert, kann auch eine Um benennung des alten Attributs, z.b. mit einem Zusatz, von Vorteil sein. Beispiele Die Leistung eines bestimmten Pkw, z.b. Mercedes-Benz SL 350, ändert sich, obwohl die Be zeichnung des Typs (SL 350) gleich bleibt. Dies könnte z.b. dann eintreten, wenn der heute im SLK 350 verbaute Motor, der dort eine Leistung von 200 kw hat, inmitten des Modelljahrs 2005 auch im SL 350, der bisher 180 kw hat, eingebaut wird. Die drei Methoden sollen nun an diesem Beispiel aus Tabelle 3.3 durchgespielt werden. Fahrzeug_ID (PK) Modelljahr Pkw_Typbez Leistung_KW Mercedes SL Tabelle 3.3 Bisheriges Aussehen der Dimension

42 Logischer Entwurf Typ 1: Überschreiben Fahrzeug_ID (PK) Modellahr Pkw_Typbez Leistung_KW SL Tabelle 3.4 Änderung nach Typ 1 Die alten Werte werden mit neuen Daten überschrieben. Dies hat zur Folge, dass es keine Möglichkeit mehr gibt festzustellen, wie hoch die Leistung zu Beginn des Jahres 2005 war, da nur noch der aktuelle Wert in der Tabelle vorhanden ist. Diese Methode ist also nur sinnvoll, wenn der Verlust des alten Wertes nicht relevant ist oder wenn es sich um eine Korrektur handelt. Typ 2: Erzeugung eines zusätzlichen Tupels Fahrzeug_ID (PK) Modelljahr Pkw_Typbez Leistung_KW SL SL Tabelle 3.5 Änderung nach Typ 2 Eine Änderung, wie sie in Tabelle 3.5 gemacht wurde, erzeugt einen neuen Eintrag, dessen zeitliche Einordnung nur mit Hilfe der Faktentabelle erfolgen kann. Ist es jedoch notwendig, dass eine solche zeitliche Aufschlüsselung bereits in der Dimensions tabelle erfolgen soll, so muss dort der Primärschlüssel angepasst werden, indem er z.b. als Konkatenation aus altem Primärschlüssel mit einem zeitlichem Schlüssel neu zusammenge setzt wird, ohne dabei einen neuen künstlichen Schlüssel zu erzeugen. Diese Art der Erweite rung des Primärschlüssels in einer Dimension wird in [BS+98] auch als temporales StarSchema bezeichnet. Diese Änderungen müssen sich nun auch in der damit verknüpften Fak tentabelle widerspiegeln, welche dort eine einmalige Anpassung notwendig macht. Mit dieser Methode lassen sich die kompletten historischen Daten innerhalb der Dimension rekonstru ieren. Dies wird allerdings mit einer etwas vergrößerten Tabelle und gegebenenfalls etwas schlechterer Performance bei den Join-Operationen, wegen des vergrößerten Primärschlüssel, erkauft. In [BS+98] wird allerdings dargelegt, dass die Nachteile, bei einer Verwendung des temporalen Star-Schemas, kleiner ausfallen, als eventuell vermutet würde. Ist eine so exakte Verfolgung der Veränderungen innerhalb einer Dimension, seien diese nun zeitlich genau nachvollziehbar oder nur durch einen neuen Primärschlüssel erkennbar, nicht notwendig, so kann der Typ 3 herangezogen werden.

43 3 Entwurf eines Data Warehouse 35 Typ 3: Zusätzliches Attribut für neuen Wert Fahrzeug_ID (PK) Modelljahr Pkw_ Typbez Leistung_ KW_alt Leistung_ KW_neu SL Tabelle 3.6 Änderung nach Typ 3 (neues Attribut) Problematisch bei dieser Methode ist, dass bei wiederholten Änderungen der vorherige bzw. alte Wert überschreiben wird. Daneben müssen diese neue Attribute für alle Spalten eingefügt werden, die sich ändern bzw. deren Änderungen nachvollziehbar sein sollen. Typ 3 ist also nur sinnvoll, wenn sich nur bestimmte und wenige Änderungen ergeben, diese sehr selten sind oder weiter zurückliegende Änderungen nicht mehr interessant sind. Bei alternativen Imple mentierungen (z.b. ERwin, vgl. [Hah00]) werden der ursprüngliche und der aktuelle Wert gespeichert. Eventuell gespeicherte Zwischenwerte gehen hierbei verloren. 3.4 Physischer Entwurf Die im logischen Entwurf festgelegten Tabellen, für den Fall der relationalen Speicherung, müssen nun in geeignete Speicherungsstrukturen abgebildet werden. Ist vorher bekannt, wel che Art von Zugriffen erfolgen soll, so können die entsprechenden Zugriffsmechanismen und Indexstrukturen, wie z.b. der Bitmap-Index [CI98], festgelegt werden. Eine Verbesserung der Verarbeitungsgeschwindigkeit wird auch durch so genannte materialisierte Sichten erreicht, indem Teilergebnisse vorab berechnet und in der Datenbank abgespeichert werden. Eine Parti tionierung der Tabellen kann auch diesem Ziel dienen. Welche Maßnahmen in einem bestimmten Fall zu einem optimalen Ergebnis führen hängt so wohl von der Daten selbst, als auch von der Zugriffscharakteristik ab. Daneben spielt auch die Leistungsfähigkeit der verwendeten Datenbanksoftware ein Rolle, die die gewünschten Struk turen unterstützen muss. Die Optimierung, insbesondere in Bereich Datenbanken, ist ein wei tes Feld, da sie sowohl von der Software als auch von der verwendeten Hardware abhängig ist, so dass hier nicht weiter darauf eingegangen werden soll. 3.5 Entwurfsstrategien Es können zwei verschiedene Strategien zum Entwurf unterschieden werden. Als Erstes die Top-Down-Strategie, die mit einer hohen Abstraktionsebene beginnt und sukzessiv verfeinert. Die Zweite Strategie geht genau den umgekehrten Weg, d.h. man beginnt mit konkreten An forderungen (Sichten) und vereinigt diese zu einem integrierten, redundanzfreien konzeptu ellen Schema (Bottom-Up-Strategie). Bei dieser Strategie kann auch inkrementell vorge gangen werden, indem von der groben Abstraktionsebene ausgegangen wird und nur die Teil systeme verfeinert werden, die im Moment realisiert werden sollen. Dieser Entwurf kann nun

44 Entwurfsstrategien bei der Hinzunahme von weiteren Teilsystemen erweitert werden. Gegebenenfalls sind An passungen und Erweiterungen am bisherigen konzeptuellen Schema erforderlich. Wurden am Ende alle Teilsysteme realisiert so, hat man damit auch das gesamte konzeptuelle Schema ite rativ entwickelt. Diese Vorgehensweise entspricht dem Grundsatz: Think big Start small und wird von vielen Seiten empfohlen [Sun98]. So kann durch diese Art des Vorgehens auch die Entwicklungszeit bis zur ersten Anwendung verkürzt werden. Erkauft wird dieser Vorteil durch den höheren Änderungsaufwand bei der Erweiterung. Stellt sich allerdings schon bei der ersten Realisierung heraus, dass Anpassungen am globalen Schema erforderlich sind, so ist der gesamte Anpassungsaufwand geringer als z.b. bei der Top-Down-Strategie. 3.6 Systemarchitekturen Die Verteilung der einzelnen Einheiten, also der Datenbeschaffungsbereich (ETL), die Basis datenbank und die Data-Warehouse-Datenbank, aus der in Abbildung 2.1 dargestellten Archi tektur eines Data-Warehouse-Systems und die Wahl der Entwurfsstrategie bestimmen schließ lich auch den Aufbau der Systemarchitektur. Dabei wird unterschieden, wie viele logische Schichten die Architektur aufweist, ob abhän gige oder unabhängige Data Marts oder nur ein integriertes Data Warehouse zum Einsatz kommt. Diese logische Schichten lassen sich auch physikalisch trennen, wenn dies z.b. aus Kapazität- oder Performance-Gründen erforderlich wird. Daher werden in [Sun98] die folgenden Architekturen vorgeschlagen und bewertet. Hierbei findet die optionale Basisda tenbank (vgl. [BG01] und Abbildung 2.1) keine Berücksichtigung. Two-Tier-Data-Warehouse-Architektur: Die Daten des Datenbeschaffungsbereichs mit den unterschiedlichen ETLKomponenten, die aus unterschiedlichen Quellen gespeist werden können, fließen in ein zentrales Data Warehouse (enterprise data warehouse). Vorteil: Keine Redundanzen, da eine zentrale Speicherung der Daten und Me tadaten erfolgt. Die Analyse von gebietsübergreifenden Daten ist möglich. Nachteil: Eine sehr komplexe Struktur und damit hohe Anforderungen bei der Realisierung, was sehr lange Anlaufzeiten bis zur ersten Realisation zur Folge haben kann. Da alle Bereiche des Unternehmens Aus wertungen erstellen, sind die Datenmengen sehr groß. Two-Tier-Data-Mart-Architektur: Die Daten des Datenbeschaffungsbereichs mit den unterschiedlichen ETLKomponenten fließen in die einzelnen unabhängigen Data-Marts. Im schlechtesten Fall muss jeder ETL-Prozess jedes Data Mart bedienen. Dadurch entstehen gege benenfalls Redundanzen. Der Umfang der Daten in den einzelnen Data Marts ist geringer und nur für den jeweiligen Einsatzzweck bestimmt. Vorteile: Ein geringerer Anlaufaufwand und damit niedrigere Anfangskosten sind die gewünschten Ziele, die erreicht werden können. Die Zeit bis

45 3 Entwurf eines Data Warehouse 37 zu einer ersten Realisierung ist damit wesentlich verkürzt. Dies senkt die Kosten. Nachteile: Die Folgekosten jedoch, die durch einen erhöhten Wartungs- und Wei terentwicklungsaufwand entstehen, sind nicht unerheblich. Zudem sind keine Auswertungen möglich, die über die Grenzen der einzelnen Bereiche hinausgehen. Alternativ könnten die Data-Marts wieder in einem einzigen DataWarehouse vereinigt werden, wie dies in Abbildung 2.3 gezeigt wird. Dies entspricht dann allerdings einer Three-Tier-Architektur und erzeugt erneuten Aufwand und erhöhte Kosten. Three-Tier-Data-Warehouse-Architektur: Nach dem Datenbeschaffungsbereich (ETL) folgt ein zentrales Data Warehouse. Aus diesem heraus werden die einzelnen abhängigen Data-Marts (vgl. Abbildung 2.2), mit denen für ihren Aufgabenbereich relevanten Daten geladen. Vorteile: Dies ist die effektivste Methode der Unterstützung von Data Marts. Die Redundanzen bei der Datenbeschaffung fallen weg, da die Quell daten jeweils nur einmal gelesen und nur an einer Stelle bearbeitet und gespeichert werden. Dies hat eine Verbesserung der Datenqualität zur Folge und bietet die zusätzliche Möglichkeit einer bereichsüber greifenden Datenauswertung. Nachteile: Im Prinzip sind die Anforderungen genauso hoch, wie bei der Realisierung mit der Two-Tier-Data-Warehouse-Architektur. Bei Änderungen am Data-Warehouse müssen diese zudem zeitgleich an den betroffenen Data Marts nachgebildet werden. Damit ist die Three-Tier-Data-Warehouse-Architektur ähnlich schwierig und aufwendig zu realisieren, wie die Two-Tier-Data-Warehouse-Architektur. Allerdings sind die Vorteile zu gewichtig, um davon Abstand zu nehmen. Als Ausweg aus diesen Dilemma bietet sich die in krementelle Realisierung an, wie sie u.a. in [Sun98] vorgeschlagen und bereits im vorherigen Abschnitt erläutert wurde. Eine Bewertung der Vorgehensmodelle erfolgt dabei durch die folgenden Fragestellungen, die bereits angedeutet wurden. Wie hoch ist der Entwicklungsaufwand bis ein erstes System zur Verfügung steht? Wie hoch ist der Aufwand bei der Wartung und dem Betrieb des Systems, d.h. wie sind die Abhängigkeiten zwischen den Data Marts und den Quellen bzw. dem Data Warehouse? Wie hoch ist der Aufwand bei Änderungen und Anpassungen? Wie sieht es mit der Skalierbarkeit, z.b. bezüglich des Datenvolumens, aus? Bei der Beantwortung dieser Fragen spielen auch die jeweiligen Randbedingungen eine ent scheidende Rollen. So ist die Größe der Unternehmung, die Anzahl der Beschäftigten, die Erfahrung mit der Realisierung solcher Projekte und nicht zuletzt das Budget möglicherweise

46 Systemarchitekturen ein Grund, sich für die eine oder andere Architektur zu entscheiden. Jedoch sollte zur Vermei dung von Inkonsistenzen und Redundanzen, sowohl bei den Daten, als auch bei den Data Marts, als erstes ein globales konzeptuelles Schema entwickelt werden [Sun98].

47 4 Projekt 4.1 Aufgabe Die Abteilung GS-AM/ENG3 der Firma Robert Bosch GmbH in Stuttgart befasst sich mit der Entwicklung, der Berechnung und der Konstruktion neuer Saugmodule, inklusive deren Funktionen und Produktionsprozesse. Dabei werden auch Fremderzeugnisse analysiert, d.h. einem Benchmarking unterzogen. Das Ziel dieser Arbeit ist es nun, die Basis- und Analyseda ten von Saugmodulen und Saugrohren in einen Data Warehouse bereitzustellen, daraus Ver gleichsmöglichkeiten herzuleiten und diese durch geeignete Berichte bereitzustellen. Dabei sollen externe Dokumente und Berichte ebenso integriert werden, wie Bilder, Grafiken und Messergebnisse. Dazu müssen zunächst die existierenden und gewünschten Datenbestände analysiert werden, um daraus geeignete Datenstrukturen entwickeln zu können. Da die Basis- und Analysedaten auch Bilder, Grafiken und ganze Dokumente enthalten können, ist zu prüfen, wie diese genau aussehen, und ob eventuell dafür zusätzliche Funktionalitäten erforderlich sind, wie sie nur Dokumentenmanagement-Systeme (vgl Kapitel 2.2 und Anhang A) bereitstellen können. Des weiteren ist zu prüfen, inwieweit der Einsatz von Reporting-Tools oder OLAP-Werk zeugen sinnvoll und notwendig ist, um die gewünschten Berichtsfunktionalitäten zu gewähr leisten. Diese Funktionalitäten sollen schließlich in geeigneter Weise umgesetzt und bereitge stellt werden. Dabei sind die Anforderungen der Mitarbeiter und damit der Benutzer des Sys tems und die Rahmenbedingungen der Firma Robert Bosch GmbH, z.b. bezüglich der Aus wahl der Software, zu berücksichtigen. Bevor die Anforderungen genauer betrachtet werden, soll im nächsten Abschnitt zunächst der abteilungs- und fachspezifische Hintergrund etwas genauer betrachtet werden. Dies trägt zum besseren Gesamtverständnis bei und veranschaulicht viele der, in diesem Bereich, verwende ten Begriffe und Abkürzungen. 4.2 Saugmodule, Saugrohre und mehr Wie bereits oben erwähnt, beschäftigt sich die Abteilung GS-AM/ENG3 mit den Saugmodu len bzw. Saugrohren. Sie ist eine Unterabteilung des Geschäftsbereichs GasolineSystemsAirManagement (GS-AM), welcher sich mit allen Komponenten beschäftigt, die im Zu sammenhang mit Benzinmotoren und dem Management der Luft stehen [RB04a]. Das reicht von den Saugmodulen bzw. Saugrohren, den Drosselvorrichtungen (DV-E), den Fahrpedalmodulen, den Sekundärluftpumpen über die Tankentlüftungsventile (TEV) bis zu den Abgas 39

48 Saugmodule, Saugrohre und mehr rückführsteller (AGR) und deren Regelklappen [RB04b]. In Abbildung 4.1 sind einige dieser Elemente, die innerhalb eines Pkw verbaut werden, mit ihrer dortigen Einbaulage dargestellt. Die Steuerung der Luft ist entscheidend für die Leistungsfähigkeit eines Motors, d.h. die Luft zufuhr muss exakt auf die Kraftstoffzufuhr abgestimmt sein, damit die Verbrennung, wie ge wünscht, erfolgen kann. Die Kraftstoffverbrennung hängt dabei von der angesaugten Luftmasse, der Bewegung und der Zusammensetzung der Luft, d.h. dem Anteil von Abgas oder Kraftstoffdämpfen und der Vermischung von Luft und Kraftstoff im Saugrohr ab. Ein optimal abgestimmtes System kann dabei den Verbrauch und die Emissionen senken und die Dynamik des Motors deutlich ver bessern. Abbildung 4.1 Produktbereich GS-AM bei Robert Bosch GmbH Das Saugmodul beeinflusst die Luft-Ladungswechselvorgänge, die dem Motor die entspre chende Leistungscharakteristik geben, wobei diese z.b. durch den Einsatz von Swirl-Klappen optimiert werden. Es umfasst das Saugrohr und weitere Komponenten des Motormanage ments, wie z.b. die Zündspule, den Luftfilter, die Zylinderkopfhaube, den Kaftstoffzuteiler (KSZ), das Motorsteuergerät, den Kabelbaum und das Abgasrückführungsrohr (AGR). Die Abbildung 4.2 und 4.3 zeigen die meisten der Komponenten eines Saugrohrs. Die wichtigsten dieser Komponenten, wie die Drosselvorrichtung (DV-E), das Tankentlüftungs ventil (TEV), die Regelklappe und die Sekundärluftpumpe, sind außerdem in Abbildung 4.4 detaillierter, mit deren Teilkomponenten, zu sehen.

49 4 Projekt 41 Schutzkappe Schraube selbstschneidend Schrauben metrisch TEV2.5 DV-E5 Verschlussstopfen Schraube selbstschneidend Schrauben metrisch Reedsensor Schutzkappe Dämmplatte AGR-Rohr KSZ-S Rückschlagventil SG ME7.6.1 Saugrohr Kabelbaum PDA-Klappen Abbildung 4.2 Saugmodul mit Anbauteilen Das Saugrohr ist dabei das zentrale Bauteil, mit dem die meisten der anderen Komponenten verbunden sind. In Abbildung 4.3 ist ein solches Saugrohr deutlicher zu erkennen. Die Beson derheit der Saugrohre bei Bosch ist, dass diese aus Kunststoff gefertigt sind. Optional lassen sich die Saugmodule unter einer Designhaube verstecken, wie dies in Abbildung 4.3 oben links zu sehen ist. Abbildung 4.3 Saugmodul und Saugrohr

50 Saugmodule, Saugrohre und mehr Abbildung 4.4 DV-E, TEV, Regelklappe und Sekundärluftpumpe 4.3 Anforderungen In den folgenden Abschnitten sind die Anforderungen, die vor allem von Seiten der Mitarbei ter an das System gestellt wurden, dargelegt. Diese wurden in einem Brainstorming erarbei tet und dienen als Grundlage für die Analyse, den Entwurf und die Implementierung. Einige dieser Anforderungen haben dabei den Charakter einer Wunschliste, d.h. eine Realisierung wäre zu aufwendig und würde den Rahmen dieser Arbeit sprengen. Dies trifft insbesondere auf einige der funktionalen Anforderungen zu Daten Die Anforderungen an die Daten, d.h. die Frage welche Daten aufgenommen werden sollen, sind im Folgenden dargestellt. Dabei handelt es sich vielfach um fachspezifische Abkürzungen, die bereits im vorherigen Abschnitt erläutert wurden. D.1 Datenbasis bzw. -quelle für Hersteller und technische Daten von Fahrzeugen und Motoren: Auto Katalog [AMS03] [AMS04] [AMS05]. Diese Daten sollen durch das Scannen der Datenblätter/Fahrzeugdaten und an

51 4 Projekt 43 schließender Umwandlung mittels OCR in eine MS-Excel-Tabelle überführt werden. Die Bilder der Fahrzeuge sollen auch eingescannt werden (vgl. D.3). D.2 Stücklisten (über SAP Verknüpfung über Link ausreichend) Stücklisten der Saugmodule bzw. Saugrohre, die durch ein SAP-System verwaltet werden. Dabei erscheint es ausreichend, wenn nur ein Link (z.b. über die SAPNummer) gespeichert wird. Eine Übernahme der kompletten Listen ist nicht nötig. D.3 Bilder der Fahrzeuge und Motoren Aufnahmen der Fahrzeuge und Motoren aus Zeitschriften oder selbst fotografiert. D.4 Logos der Fahrzeug-Hersteller (OEM) und der Teilehersteller Zur leichteren Identifikation der Hersteller und Teilehersteller sollen deren Logos aufgenommen und dargestellt werden. D.5 Übersicht der Fahrzeugdaten inkl. SOP; Daten von Klassikern auch nach EOP in Datenbestand halten Die Daten des Starts der Produktion (SOP) und dem Ende der Produktion (EOP) sollen aufgenommen werden. Dabei sollen die Daten auch nach EOP im Bestand verbleiben. D.6 Hyperlink zu Herstellern / Link zu AP-Datenbank (USA) Die Hersteller sollen durch einen einfachen Link auswählbar sein. Die bereits in den USA aufgebaute AP-Datenbank soll entsprechend verlinkt werden, wenn dort zu einem bestimmten SR/SM Detailinformationen vorhanden sind. D.7 Info über Teilehersteller, allgemeine Info zum Teilehersteller (Motorenwerk, Fahrzeugwerk) Entsprechend den Angaben über die Hersteller, so soll auch für Teilehersteller ein Link verfügbar gemacht werden. Zusätzlich sind weitere Informationen abzuspei chern, wie z.b. Ansprechpartner, Standort, etc. D.8 Hinweise auf Testberichte, Veröffentlichungen, Presse Sofern vorhanden, sollen Hinweise auf Testberichte, z.b. in [AMS05b] und Ver öffentlichen in Fachzeitschriften und generell in der Presse verzeichnet werden. D.9 Zerlegungsberichte (inkl. Bilder) (vgl. F.10 und F.11) Die Zerlegungsberichte als ganzes, elektronische Dokumente, wie z.b. s und zusätzliche Bilder sollen aufgenommen werden. Wichtige Kennzahlen sollen se parat aufgenommen werden. D.10 Analyseberichte Die Analyseberichte als ganzes und zusätzliche Bilder sollen aufgenommen werden. D.11 Benchmarkberichte Die Benchmarkberichte als ganzes, elektronische Dokumente, wie z.b. s und zusätzliche Bilder sollen aufgenommen werden. Wichtige Kennzahlen sollen separat aufgenommen werden.

52 Anforderungen D.12 Hinweise auf Probleme (Rückrufaktionen,...) Sind Probleme und Rückrufaktionen aufgetreten, so sollen diese zeitlich katego risiert aufgenommen werden. D.13 Kosten für gekauftes Ersatzteil Die Beschaffungskosten für ein Ersatzteil sollen aufgenommen werden. Dies ist z.b. der Preis, der für ein gekauftes Saugrohr bezahlt werden muss. D.14 War RB am RFQ beteiligt? 1. RB Angebot 2. SOD (Start of Design) 3. RB-TP War die Abteilung (GS-AM/ENG3) an der Ausschreibung und Entwicklung des Produkts (SR/SM) beteiligt? Wie hoch war das Angebot von RB? Wenn ja, wann war SOD? D.15 Marktanteilermittlung durch Verkaufszahlen und Zulassungszahlen Die Zulassungsstatistiken des Kraftfahrtbundesamts sind über das Internet abrufbar (vormonatlich und vom Vorjahr). Durch den Vergleich mit den Verkaufszahlen (PTS-Statistik) lassen sie die Marktanteile ermitteln bzw. ab schätzen. D.16 Technische Daten der Saugmodule (SM) und Saugrohre (SR): Saugmodul DVE (Drosselvorrichtung), KSZ (Kraftstoffzuteiler), TEV (Tankentlüf tungsventil), Aktuator (1. GPA; 2.TPSE), Sensor, Anschlüsse (BKV,..), SG, KB, BBV (Blow-By-Ventil), Schläuche, Clipse, Abmaße (L/B/H) des SM Saugrohr: Anschraubkonzept, Verbindungskonzepte, Kunststoff (Materialart,..), Ge wicht, Runnerlänge und -querschnitte, Plenumvolumen, Füllungs optimierung, Stücklisten, Auffälligkeiten (besser/schlechter als RBCB, Pro zessabnormitäten), Dichtungskonzepte, Schalenaufbau, Prozesstechnik, Abmaße der Komponenten (Buchsen, Schrauben,...) Dies sind vor allem die technische Daten der Saugrohre bzw. Saugmodule, bei den eine Erklärung jedes einzelnen Teils bzw. deren Abkürzung an dieser Stelle keinen Sinn macht. Die wichtigsten Teile wurden in Kapitel 4.2 näher beschrieben Funktionale Anforderungen Die funktionalen Anforderungen bestimmen im wesentlichen die Programmierung des Anwendungsprogramms.

53 4 Projekt 45 F.1 Suchfunktionen (für Modelle, Saugmodule, Saugrohre,...) Eine Suchfunktion, d.h. die Möglichkeit nach bestimmten Modellen, Saugmodu len, Saugrohren, etc. im Datenbestand suchen zu können, ist besonders wichtig. F.2 Von Intra- bzw. Internet aus zugreifbar (vgl. Anforderung S.5) Diese Funktionalität hängt direkt von der verwendeten Architektur ab. Die ge bräuchliche Client-Server-Architektur bietet i.a. diese Möglichkeit. F.3 Offline-Version gewünscht, eigenständiges Programm (CD, Synchronisation und Auslagerung von (Teil)Datenbeständen auf Laptop) Teile oder auch der gesamte Datenbestand soll in einer Offline-Version oder als CD verfügbar sein. Damit können diese Daten mitgenommen werden und beim Kunden vor Ort abgefragt werden. F.4 Newsletter (automatische Benachrichtigung, Gewichtung der Wichtigkeit der Änderungen) Werden von einem Mitarbeiter Eintragungen in der Datenbank vorgenommen, so sollen interessierte Personen eine Benachrichtigung erhalten. Die Bewertung über die Wichtigkeit der Änderungen soll dabei möglich sein. F.5 Abfragen nach Datum / letzter Änderungen Es soll die Möglichkeit bestehen, nach den letzten Änderungen zu suchen, bzw. nach Änderungen zu einem bestimmten Zeitpunkt. F.6 Eingabe / Änderungsmöglichkeiten von Daten, Bildern und Dokumenten Es sollen Neueingaben möglich und die existierenden Daten sollen veränderbar sein. Zusätzlichen sollen Dokumente und Bilder aufgenommen werden können. F.7 Vergleichsmöglichkeiten der technischen Daten, Stücklisten und SM bzw. SR Es soll die Möglichkeit bestehen, die technischen Daten von SR/SM und Modellen zu vergleichen. Die zugehörigen Stücklisten sollen darstellbar sein. F.8 Ausdruck von Berichten, Vergleichen, Analysen und Stücklisten Die Berichte, Vergleiche und Analysen sollen ausdruckbar bzw. abzuspeichern sein. F.9 Anzeige/Einbinden von Grafiken und Dokumenten (Vorschau, Detailansicht) Bei der Detailansicht von Daten sollen die Dokumente und Bilder auswählbar sein. Bei Bildern soll ein Vorschaubild angezeigt werden, das bei Bedarf in voller Größe angezeigt werden kann. F.10 Analyse und Ermittlung von Marktanteilen (RB, Mitbewerber) auf Basis von Zu lassungszahlen Eine Ermittlung der Marktanteile soll durch die eingegebenen Daten der Zu lassungszahlen und der Verkaufszahlen ermöglicht werden. Damit lassen sich die Marktanteile ermitteln und z.b. grafisch darstellen. F.11 Kennzahlen aus Berichten (automatisch) extrahieren Aus den verschiedenen Berichten (Analyse., Benchmark- und Zerlegungsberichte) sollen möglichst automatisch Kennzahlen extrahiert werden.

54 Anforderungen Sonstige Anforderungen Dies sind die Anforderungen, die einen generellen Charakter haben, d.h. es geht weder um die Daten, noch um die spezielle Funktionalität des Anwendungsprogramms, sondern mehr um die Funktionalität eines Frameworks. Die Grenzen hierbei sind jedoch fließend. S.1 Zugriffs- und Sicherheitskonzepte (Lese-, Änderungs- und Adminrechte) Die Anwendung soll so gestaltet sein, dass sich verschiedene Rollen definieren lassen. Es soll Gruppen/Benutzer geben, die Daten nur lesen dürfen, anderen soll erlaubt werden Daten und ändern und neue Einträge vorzunehmen und eine dritte Gruppe soll die Verwaltung der Anwendung und die Vergabe von Rechten vor nehmen (Authentifizierung und Autorisierung). S.2 Erweiterbarkeit (z.b. durch weitere Komponenten und zusätzliche Datenbestände bzw. Daten aus anderen Abteilungen) Die Anwendung soll z.b, durch weitere Teilkomponenten erweiterbar sein. Der Aufwand bei Änderungen den den Datenbeständen und auch deren Struktur soll vertretbar sein. Eine Integration von Datenbeständen aus anderen Abteilungen soll möglich sein. S.3 Corporate Identity (der Robert Bosch GmbH) Das Aussehen der Anwendung soll an die allgemeine Richtlinien der Firma Robert Bosch GmbH anpassbar bzw. als eine Anwendung dieses Unternehmens erkennbar sein. S.4 Usability (einfache Bedienung) Die Anwendung soll so gestaltet sein, dass sie einfach und möglichst intuitiv zu bedienen ist. Der Lern- und Umstellungsaufwand sollte dabei so gering wie möglich sein. S.5 Webinterface keine zusätzliche Software-Installation auf Seiten der Benutzer Die Anwendung sollte sich innerhalb des Web-Browsers bedienen lassen, so dass keine Installation einer separaten Client-Anwendung notwendig ist. S.6 Einsatz von Standardsoftware der Firma Robert Bosch GmbH Die eingesetzte Software für die Realisierung der Aufgabe soll aus dem Repertoire der Standard-Software stammen, die innerhalb der Robert Bosch GmbH zum Ein satz kommt. 4.4 Erster Architekturentwurf des DW Bei der Beachtung der funktionalen und sonstigen Anforderungen, lässt sich ein erster Archi tekturentwurf erstellen, der in Abbildung 4.5 zu sehen ist. Die Forderung nach einem Web-In terface (S.5 und F.2) macht den Einsatz eines Applikations-Servers zwingend erforderlich. Es ergibt sich damit eine logische Drei-Schichten-Architektur (3-tier), die, wie in der Abbildung ausgeführt, in einer physischen Zwei-Schichten-Architektur (2-tier) ausgeführt sein kann, d.h. der Applikations-Server und die Backend-Datenbank laufen auf einem Rechner. Die Daten quellen sind ebenfalls angedeutet.

55 4 Projekt 47 Ein-/Ausgabe von Daten Applikations-Server Clients DBMS / Data Warehouse Data Warehouse HTTPServer Drucker OCRProzess Scanner SAP Analyse-, Benchmark- und Zerlegungsberichte manuelle Eingabe von Daten Auto Katalog Datenquellen Abbildung 4.5 Erster Architekturentwurf Wie die Daten der Datenquellen in das Data Warehouse gelangen, ist hier noch nicht ausge führt, da diese Prozesse von der eingesetzten Software und deren Funktionalität abhängen. Eine genaue Analyse der Daten bzw. Datenquellen, der funktionalen und sonstigen An forderungen erfolgt im anschließenden Kapitel. 4.5 Analyse Die jetzt folgende Analyse der Daten bzw. Datenquellen soll etwas mehr Klarheit über die Herkunft, die nötigen Schritte und den Aufwand zur Beschaffung dieser Daten schaffen. Eine solche Analyse soll auch für die funktionalen und sonstigen Anforderungen erfolgen. Dabei sollen jene Anforderungen besonders betrachtet werden, die im Rahmen dieser Arbeit nicht berücksichtigt und implementiert werden können Daten und Datenquellen Nachdem in den Anforderungen bestimmt wurde, welche Daten gewünscht werden, bzw. wie diese zu Verarbeiten und Aufzubereiten sind, so stellen sich nun die folgenden Fragen: Woher kommen Daten, d.h. wo liegen die Datenquellen?

56 Analyse Welches Format haben sie? Wie hoch ist der Aufwand diese zu beschaffen? Fahrzeugdaten Als eine der wichtigen Datenquellen sind die Daten der Fahrzeuge, die hier auch als Modell bezeichnet werden, anzusehen. Diese Daten stammen aus der Zeitschrift Auto Katalog [AMS03] [AMS04] [AMS05]. Sie erscheint einmal im Jahr und listet alle weltweit verfügba ren Fahrzeugmodelle der unterschiedlichen Hersteller auf. Zu jedem Modell sind zahlreiche technischen Daten verzeichnet (vgl.abbildung 4.6), inklusive Bilder und Bezugsadressen. Daneben sind auch Modelle verzeichnet, die dort als Exoten bezeichnet werden, also Son dermodelle und Kleinserien von meist weniger bekannten Herstellern. Abbildung 4.6 Beispielseite aus Auto Katalog - Modelljahr 2005 Die Problematik bei diesen Daten, die bereits im vorherigen Abschnitt angesprochen wurde, ist, dass diese zunächst nur in gedruckter Form vorliegen. Ein Datensatz ist zwar käuflich zu erwerben, diese Option wurde aber aus Kostengründen von der Abteilung GS-AM/ENG3 abgelehnt. Es muss also ein Prozess gefunden und definiert werden, wie diese Daten extrahiert und in das Data Warehouse geladen werden können. Dabei sollte der Aufwand und damit die Kosten, so gering wie möglich sein. In der Vergangenheit wurde einmal von einem Prak tikanten der gesamte Datenbestand aus [AMS03] von Hand in eine MS-Access-Datenbank eingegeben. Dies ist zwar grundsätzlich möglich, stellt aber keinen praktikablen Ansatz für die Zukunft dar. Stattdessen wird eine Lösung mittels einer OCR-Software (Optical Charak ter Recognition, OCR) ins Auge gefasst, d.h. die Tabellen bzw. Listen aus der Zeitschrift sollen eingescannt und durch die Software z.b. in Excel-Tabellen umgewandelt werden. Diese Tabellen müssen anschließend noch etwas nachbearbeitet werden und können dann in das Data Warehouse (Data Staging Area) geladen werden. Wie diese Arbeitsschritte aussehen könnten ist in Abbildung 4.7 dargestellt. Trotz der Erleichterung durch die Texterkennungs

57 4 Projekt 49 software, ist der manuelle Aufwand immer noch sehr hoch und sollte nicht unterschätzt werden. OCR-Prozess DWS Scanner Auto Katalog Nachbearbeitung Abbildung 4.7 Arbeitsschritte zur Datenbeschaffung aus Auto Katalog Operationale Daten Die operationalen Daten, die in einem typischen Data Warehouse normalerweise die wichtigs te und oft auch einzigste Datenquelle darstellen, sind hier nur sehr spärlich vertreten. Als ein Vertreter dieser Daten kommen nur die Daten aus dem Verkauf der Saugmodule bzw. Saug rohre in Frage, die bei der Rober Bosch GmbH durch ein SAP-System verwaltet werden. Eine automatische Übernahme von Daten, wie z.b. die Summe der monatlichen Verkäufe von Saugrohren, ist damit grundsätzlich möglich. Sollte sich eine solche Anbindung nicht realisieren lassen, so ist auch eine manuelle Eingabe denkbar, da es sich nur um sehr wenige Daten handelt. Es betrifft weniger als 15 Saugmodule bzw. Saugrohre und die Daten müssten nur einmal pro Monat eingegeben werden. Zur Ermittlung des Marktanteil werden noch die Verkaufszahlen der entsprechenden PkwModelle benötigt. Da diese Zahlen nicht von den Hersteller zu bekommen sind, wird der Um weg über die Zulassungszahlen gegangen, die ungefähr den produzierten Fahrzeugen entspre chen sollten. Die Quelle dieser Zulassungszahlen ist die Internetseite des Kraftfahrt-Bundes amts [KBA05]. Dort werden die Pkw-Neuzulassungen für Deutschland nach Segmenten und Modellreihen des jeweiligen Vormonats als Dokument kostenlos veröffentlicht (vgl Abbil dung 4.8).

58 Analyse Abbildung 4.8 Monatliche Zulassungszahlen des KBA (05/2005) Außerdem ist eine detailliertere Aufstellung, bis hinunter zu den einzelnen Modellen und de ren Hubraum bzw. Leistung, als Jahresübersicht des Vorjahres, ebenfalls kostenlos, erhältlich (vgl. Abbildung 4.9). Abbildung 4.9 Jährliche Zulassungszahlen des KBA (2004) Eine Analyse der Dokumente ergab dabei die folgende Problematik: Das monatlich er scheinende Dokument enthält die Daten nicht detailliert genug und das jährlich erscheinende Dokument, enthält zwar die benötigten Daten, diese sind aber nicht zeitnah genug. Außerdem

59 4 Projekt 51 müssen die Daten aus den Dokumenten mühsam herausgesucht werden, was wegen der teil weise komplizierten Bezeichnung der Modelle zusätzlich erschwert wird. Die monatlichen Zulassungszahlen sind auch in der jeweils aktuellen Ausgabe der Zeitschrift Auto Motor und Sport [AMS05b] abgedruckt, allerdings auch nur in der geringeren Detaillierung (TOP 50 Liste, Zulassungen nach Hersteller/Marke). Diese Daten stammen aus den Beständen des Kraftfahrt-Bundesamts [KBA05]. Eine Version, die den eigentlichen Anforderungen genügen könnte, d.h. einer zeitnahen und detaillierten Aufschlüsselung der zugelassenen Fahrzeuge, ist also nicht kostenlos erhältlich. Das Kraftfahrt-Bundesamt bietet jedoch die Erstellung von maßgeschneiderten Statistiken, gegen Kostenerstattung, an. Wie hoch diese Kostenerstattung ist, wurde im Rahmen dieser Arbeit nicht ermittelt. Es besteht jedoch auf der Seite von GS-AM/ENG3 der Wunsch, für diese Daten keine extra Kosten zu produzieren, wie dies auch bereits bei die Fahrzeugdaten der Fall ist. Die generelle Problematik bei den Fahrzeug-, Verkaufs- und Zulassungszahlen sind gleich mehrfacher Natur. Da ist zunächst die Verfügbarkeit. Dies trifft vor allem auf die Zulassungs zahlen zu, die nicht kostenlos in der gewünschten Form und Granularität erhältlich sind. Als weiterer Punkt ist die Bedeutung der Datenqualität nicht zu unterschätzen, insbesondere dann, wenn viele manuelle Schritte bei deren Ermittlung und Übertragung zu durchlaufen sind. Die automatische Texterkennung durch eine OCR-Software z.b. ist auch nicht fehlerfrei, so dass es nicht auszuschließen ist, dass fehlerbehaftete oder unvollständige Daten in das Data Ware house gelangen. Die manuelle Übertragung von Daten birgt auch Fehlerquellen, die aber wegen der geringeren Datenmengen in diesem Fall wohl beherrschbar sein sollte. Die Daten für die Saugmodule, Saugrohre, Analyse-, Benchmark- und Zerlegungsberichte sind teilweise auch manuell einzugeben. Diese Problematik wird etwas entschärft, da die Ein gaben nur von Personen vorgenommen werden, die sich mit der Materie auskennen. In diesem Fall werden etwaige fehlerhafte Eingaben, durch das Wissen über die Zusammenhänge, einfa cher erkannt und können sofort korrigiert werden. In Tabelle 4.1 ist eine Zusammenstellung der Anforderungen an die Daten, ihre Quelle(n), die Änderungshäufigkeit und das Format gemacht worden. Aussagen über das genaue Aussehen der Daten, d.h. die Länge der Einträge, um daraus die maximale Feldgröße bestimmen zu können, werden an dieser Stellte nicht gemacht. Eine Änderungshäufigkeit selten bedeutet dabei, dass die Daten selten geändert werden müssen. Dies ist wichtig, um den Aufwand abzuschätzen, insbesondere dann, wenn diese Änderungen manuell geschehen müssen. Unter dem Format wird die Art der Darstellung der Daten in den Quellsystemen verstanden.

60 Analyse Daten D.1/D.3/D.4 Quelle Änderungshäufigkeit Auto Katalog nie/selten extern D5 Datenformat Beschaffung/ Eingabe Excel-Tabelle über OCR erzeugt Bilder aus Zeitung oder extern Logos der Hersteller manuell/ automatisch intern selten Text/Datum je für SM/SR auch Pkw-Modell manuell D.9/D.10/D.11 intern selten Text Grafiken Bilder manuell aus pdf-dokument D.15 extern selten Text/Integer manuell (PTS-Statistik, Internet) D.7 intern/ extern selten Text Hyperlink manuell D.8/D.12 intern/ extern selten Text manuell D.13 intern selten Text/Integer manuell intern selten Text manuell intern selten/mittel Text/Integer Stücklisten Bilder D.14 D.17 manuell Tabelle 4.1 Analyse der Datenanforderungen Die Analyse-, Benchmark- und Zerlegungsberichte bestehen meist nur aus einer losen Samm lung von Bildern und Dokumenten, die selbst wieder Bilder und Texte enthalten. Abgelegt sind sie bisher in einer Dateistruktur auf einem Netzwerklaufwerk im LAN. So wäre es in diesem Fall grundsätzlich wünschenswert, diese Dokumente strukturiert abzulegen. Bisher ist ein Wiederfinden von Inhalten nur dann möglich, wenn der Mitarbeiter genau weiß, wo ein bestimmtes Dokument abgelegt wurde. Eine Ablage ist dabei nur nach einem Kriterium möglich, so z.b. nach Fahrzeugmodell. Darüber hinausgehende Verknüpfungen, z.b. zwi schen einem Bericht und einem Modell sind ebenfalls nicht möglich. Eine Suche nach Inhal ten stellt sich dabei ebenso als schwierig bzw. unmöglich heraus. Eine Abhilfe könnte hier, wie bereits erwähnt, der Einsatz eines Dokumentenmanagement-Systems schaffen, das in Ka pitel kurz vorgestellt wird. Insbesondere dann, wenn ältere Berichte, die nicht auch in elektronischer Form vorliegen, aufgenommen werden sollen, da diese erst in eine geeignete

61 4 Projekt 53 elektronische Form gebracht werden müssen. Die technischen Daten der Saugmodule bzw. Saugrohre sind aus diesen Berichten manuell zu extrahieren. Datenumfang und -wachstum Die in den Zeitschriften Auto Katalog [AMS03][AMS04][AMS05] verzeichneten Modelle haben jeweils einen Umfang von ca unterschiedlichen Einträgen. Dabei ist es keines falls so, dass jedes Jahr ca neue Modelle erscheinen, sondern die Daten beziehen sich auf die Fahrzeuge, die aktuell am Markt erhältlich sind. Die Veränderung des Datenbestandes im DWH wird nur durch wirkliche Neuerscheinungen und durch die Modellpflege von bereits vorgestellten Modellen bedingt. So kann z.b. ein Modell im Folgejahr mit neuen Motoren oder mehreren Motorvarianten angeboten werden. Quantitativ sind dies allerdings im Ver gleich zum gesamten Bestand nur wenige Änderungen, die allerdings erkannt und berück sichtigt werden müssen. Die Problematik der Erkennung von doppelten und gleichen Einträ gen beim Laden in die Datenbank soll im nächsten Kapitel näher betrachtet werden. Der Da tenumfang der Modelle wächst also jährlich nur um wenige Prozent und sollte damit sehr einfach datenbanktechnisch zu beherrschen sein. In der Abteilung GS-AM/ENG3 wurden bisher ca. 15 Saugmodule bzw. Saugrohre betreut. Dies bedeutet, dass der Datenumfang durchaus über eine manuelle Eingabe zu bewerkstel ligen ist. Die Analyse-, Benchmark- und Zerlegungsberichte haben bisher auch erst ein geringeres Ausmaß erreicht, das sich ebenfalls in dieser Weise bewältigen lässt. Das Wachs tum, d.h. die Anzahl der neu hinzukommenden Saugmodule und Saugrohre ist ebenfalls sehr gering. Die Anzahl der untersuchten Saugmodule von Fremdherstellern bewegt sich ebenfalls im einstelligen Bereich. Damit gelten die oben gemachten Aussagen auch hier. Ein etwas höheren Aufwand bedeutet die Aufnahme der Bilder und Grafiken in die Daten bank, da sie eventuell erst in eine geeignete Form gebracht werden müssen. Wegen der gegen über Dokumenten und einfachen Daten erheblich höheren Dateigröße wird dies auch in Zu kunft der Posten mit dem größten Wachstum und Verbrauch an Speicherplatz sein. Größtes Wachstum deshalb, weil die Anzahl der Bilder, die beim Benchmarking gemacht werden, steigt, und weil die höheren Auflösungen von modernen digitalen Kameras auch größere Da teien bedeuten Funktionale und sonstige Anforderungen Die exakte Analyse der funktionalen und sonstigen Anforderungen und deren Imple mentierung lassen sich am besten in einer direkten Gegenüberstellung der möglichen Lö sungsalternativen machen (vgl. Kapitel 4.7). Die oben kurz angesprochenen Punkte der funktionalen Anforderungen (F.1 F.11) und der sonstigen Anforderungen (S.1 S.6) sollen ausreichen, um eine erste Bewertung der Software abgeben zu können Zusätzliche Anforderungen Einige dieser zusätzlichen Anforderungen, die während dieser Arbeit identifiziert und teil weise bereits angesprochen wurden, sollen nun zusammengefasst werden. Diese Auswahl kann als zusätzliche Bewertungsgrundlage für eine Entscheidung über den Einsatz einer be stimmten Softwarelösung dienen. Z.1 Machbarkeit: Die eingesetzte Software muss geeignet sein, um die Anforderungen, jedenfalls zum

62 Analyse größten Teil, zu erfüllen. Dabei darf sie nicht zu komplex sein, um die Einarbeitungszeit im Rahmen zu halten. Auch der Aufwand bei der Erstellung der Lösung sollte innerhalb des Zeitrahmens der Diplomarbeit möglich sein. Z.2 Zeitliche Verfügbarkeit: Die ausgewählte Software muss im Unternehmen verfügbar sein und im begrenzten zeitlichen Rahmen bereitgestellt werden können. Dabei sind die unternehmensinternen Antrags-, Genehmigungs- und Bereitstellungsprozesse zu beachten. Z.3 Zugriffsbeschränkung: Die Anbindung von SAP ist grundsätzlich möglich (z.b. über Database-Link in Oracle), aber eventuell sprechen Datensicherheitsrichtlinien gegen eine direkte und automa tisierte Anbindung. Hierfür müssen entsprechende Zugänge freigeschaltet werden. Alternativ lassen sich diese wenigen Zahlen auch mit vertretbarem Aufwand manuell übertragen. Z.4 Budget: Die ausgewählte Software muss innerhalb des finanziellen Rahmens der Abteilung liegen. Dies trifft auch für die Beschaffung der Daten aus externen Datenquellen zu. Z.5 Aufwand: Bei der Beschaffung der Daten ist der manuelle Aufwand zu beachten, insbesondere wenn es sich um Eingaben handelt, die komplizierte und zeitaufwendige Prozesse da hinterstehen. Der angedachte ETL-Prozess der Beschaffung der Fahrzeug-Daten ist in vielen Bereichen nur manuell durchzuführen. Die Daten der Zulassungsstatistik sind komplett manuell zu bestimmen und zu über tragen. Diese manuellen Vorgänge müssen von einem Mitarbeiter gemacht werden. Es gibt kein Automatismus, der das erledigt, d.h. es muss abteilungsseitig ein Prozess im plementiert werden, der sicherstellt, dass neue Daten auch zuverlässig aufgenommen werden können. Die Brauchbarkeit des Data Warehouse hängt davon ab. 4.6 Randbedingungen Die Randbedingungen dürfen auf keinen Fall vernachlässigt werden. Eine dieser Bedingungen besagt, dass nur Standard-Software, die bei der Robert Bosch GmbH bereits im Einsatz ist, Verwendung finden kann (vgl. Anforderung S.6). Eine andere Software ist kaum einzusetzen, da die dafür notwendigen Prozesse, sowohl den zeitlichen Rahmen, als auch die Wichtigkeit dieser Diplomarbeit übersteigen würden. Dabei sollen auch die oben angesprochenen weiteren Anforderungen ihre Beachtung finden Standard-Software bei Robert Bosch Die Standard-Software, die im Bereich Data Warehouse/Business Intelligence bei der Robert Bosch GmbH eingesetzt wird, soll anschließend kurz vorgestellt werden. Diese Kurzvorstel lung soll keinesfalls alle Leistungsmerkmale der vorgestellten Software darlegen, sondern le diglich als Anhaltspunkt für die Entscheidung über die Eignung zur Lösung der gestellten Aufgabe dienen. Zunächst soll die Standardsoftware im Bereich Datenbanken/Data Ware house vorgestellt werden. In diesem Bereich ist das Business Warehouse von SAP (SAP BW)

63 4 Projekt 55 und Oracle als Standard-Software im Einsatz. Als Spezial-Software im Bereich Reporting kommen WebFocus und SAP BEx zum Einsatz. Als Software zum Dokumentenmanagement wird Dokumentum eingesetzt. Alle betrachteten Systeme sind geeignet, um die Architektur, wie sie in Kapitel 4.4 dargestellt wurde zu realisieren SAP BW Das SAP BW ist bei Robert Bosch in einem umfassenden Gesamtprozess eingebettet. Dies ist in Abbildung 4.10 dargestellt [Mae05]. Dabei ist die Entwicklung und Umsetzung bei RB noch nicht abgeschlossen, d.h. einige Teile sind bereits umgesetzt, andere Teile müssen noch umgesetzt werden. Abbildung 4.10 Business Intelligence bei RB mit SAP BW Die gesamte SAP BW-Architektur (vgl. Abbildung 4.11) ist eine integrierte Umgebung für eine unternehmsweite BI-Strategie, die dabei die folgenden Komponenten umfasst: Anbindungsmöglichkeit für SAP- und Fremdanwendungen Standardisierte Geschäfts- und Datenmodelle ETL-Funktionalität Administrationsoberfläche mit Planungs- und Überwachungsfunktionalität MetadatenRepository Reporting-Frontend (Web-basiert und als Plugin für MS-Excel)

64 Randbedingungen Abbildung 4.11 SAP BW Architektur Das SAP BW wird bei RB zum operationellen Reporting verwendet, z.b.. zum Management des Data Warehouse, für Verkaufsreports und für die Produktionslogistik. Dabei wird das Ge samtsystem in drei Regionen (Amerika, Europa, Asien/Pazifik) unterteilt. Wichtig dabei ist, dass die einzelnen Bereiche so modularisiert sind, dass bei den Anwendungen eine lokale Un abhängigkeit erreicht werden kann. Zur Harmonisierung ist es unbedingt notwendig, dass ein einheitliches globales Datenmodell existiert. SAP BW ist dabei die unternehmensweite Stan dard-software im Bereich Data Warehouse. Bewertung Diese Lösung ist als Gesamtkonzept grundsätzlich sehr gut geeignet um die Aufgabe zu lösen. Insbesondere wegen der bereits im System vorhandenen operativen Daten würde eine automa tische Übernahme erleichtert. Die Möglichkeit mittels dieser Lösung Reports erstellen zu können sind nicht ausreichend, so dass ein entsprechendes Werkzeug zusätzlich bereitgestellt werden muss. Diese Reporting-Tools werden weiter unten vorgestellt. Eine Bewertung der Erfüllung der einzelnen funktionalen und sonstigen Anforderungen werden in Kapitel 4.7 vorgenommen, so dass hier nicht weiter darauf eingegangen werden soll. Hinsichtlich der zu sätzlichen Anforderungen (vgl. Kapitel 4.5.3) und hierbei besonders gegenüber den An forderungen Z.1 (Machbarkeit), Z2 (zeitliche Verfügbarkeit) und Z.4 (Budget) schneidet dieser Ansatz schlecht ab, sofern die entsprechenden Prozesse richtig eingeschätzt wurden. Vorteile bestehen aber hinsichtlich der Zugriffsbeschänkung (Z.3), da ein direkter Zugang in nerhalb des SAP-Systems bereits besteht und nur noch die entsprechenden Rechte gesetzt werden müssten.

65 4 Projekt Oracle Die Datenbank-Software von Oracle ist bekannt für ihre Leistungsfähigkeit. Die hier zur Nutzung bereitgestellte Version 9.2 ist leistungsfähig genug, um den Aufbau eines Data Ware house zur bewerkstelligen [Sha03]. Zur weiteren Unterstützung bei der Entwicklung eines Data Warehouse und von Anwendungsprogrammen stehen zahlreiche zusätzliche alternative Entwicklungspfade zur Verfügung. So seien hier einige davon nur kurz genannt: Oracle Business Intelligence, Oracle Application Server, Oracle Analytic Workspace Manager, Oracle Enterprise Manager, Oracle Warehouse Builder, Oracle Designer und Oracle JDevel oper als Entwicklungsumgebung Java-basierter Anwendungen. Die Anforderungen (vgl Kapitel 4.3) und die Analyse der Daten (vgl. Kapitel 4.5) haben ge zeigt, dass ein Bedarf an einer speziellen Software zur Modellierung eines Data Warehouse nicht gegeben ist. Die Sachverhalte sind nicht so kompliziert, dass diese nicht auch ohne den Einsatz einer speziellen Software beherrschbar wären. Damit erscheint der Einsatz der meis ten Software-Pakete, die oben genannt wurden, als unnötig. Selbstverständlich würde der Ein satz einer weiteren Software auch mit Kosten verbunden sein und eine gewisse Zeit beanspru chen, bis diese zur Verfügung steht. Trotzdem wäre der Einsatz des Oracle Application Server in Verbindung mit dem Oracle JDeveloper denkbar. Hiermit ließe sich der in Kapitel 4.4 ge machte Architekturentwurf realisieren. Als Entwicklungsumgebung stellt der JDeveloper ein mächtiges Werkzeug dar, mit dem sich prinzipiell jede Art von Anwendungen realisieren lassen. Die Funktionalität der Software geht dabei aber weit über die Anforderungen hinaus. Entsprechend dieser Funktionalität ist der Aufwand bei der Entwicklung z.b. gegenüber der HTML DB-Lösung ungleich höher die anschließend betrachtet werden soll. Die Oracle HTML DB-Lösung fällt etwas aus dem Rahmen und stellt einen besonderen Zugang zur Datenbank- und Anwendungsentwicklung dar. Dieser pragmatische Ansatz soll dabei kein Ersatz für den Oracle Application Server in Verbindung mit dem JDeveloper sein. Die Zielrichtung geht mehr dahin, dass die Vorteile einer Einzelplatzdatenbank (einfache Be dienung, schnelle Ergebnisse und Flexibilität) mit den Vorteilen einer zentralen Datenbank (Sicherheitskonzepte, Datenintegrität, Skalierbarkeit und Verfügbarkeit) kombiniert werden [Beh04]. Die komplette Entwicklung und auch der Zugang zu den Anwendungen erfolgt dabei über etablierte Web-Technologie. Die Daten können über HTML DB in die Datenbank ge laden werden und von Spreadsheets (z.b. MS-Excel-Tabellen), Desktop-Datenbanken (z.b. MS-Access) und Datei-Servern stammen. Der Zugriff erfolgt über jeden Java-Script-fähigen Browser. Die typische System-Architektur kann in zwei (2-tier) oder drei Schichten (3-tier) ausgeführt sein, je nach den Anforderungen an die Anwendungen und die Datenbank. Der HTTP-Server (Apache mit mod_plsql) und die HTML DB-Engine fungieren dabei als Ap plikations-server. Als Backend-Datenbank kann jede Oracle-Datenbank mit einer Version hö her als verwendet werden. Ende Oktober 2005 wurde von Oracle eine etwas abgespeckte Version ihrer Datenbank-Soft ware, die als Oracle Database 10g Express Edition (Oracle Database XE) bezeichnet wird, als Beta-Version vorgestellt. Die endgültige Version soll zum Ende des Jahres 2005 fertig gestellt sein. Die Besonderheit der Software liegt darin, dass diese Version gleich inklusive des HTML DB-Frameworks installiert wird und außerdem lizenzkostenfrei abgegeben wird. Die Datenbank-Software ist begrenzt auf eine maximale Datenbankgröße von 4 GB und nur einer aktiven laufenden Instanz auf einem Server. Zusätzlich wird nur ein Prozessor (auch auf Mehrprozessor-Rechnern) und maximal 1 GB Hauptspeicher unterstützt.

66 Randbedingungen Diese Grenzen sind für die hier anfallenden Datenmengen (vgl Kapitel 4.5.1) akzeptabel, und würden einem Einsatz grundsätzlich nicht entgegenstehen. Inwiefern ein Einsatz dieser lizenz kostenfreien Software die Kosten für die Dienstleistung senken würde, ist während dieser Arbeit nicht evaluiert worden, da sie nicht z.z. noch nicht eingesetzt wird. Bewertung Diese Lösung scheint sehr gut dazu geeignet zu sein, um viele der Anforderungen (vgl. Kapi tel 4.3) und insbesondere viele der zusätzlichen Anforderungen (vgl. Kapitel 4.5.3) zu erfül len. Eine Bewertung der Erfüllung der einzelnen funktionalen und sonstigen Anforderungen werden in Kapitel 4.7 vorgenommen, so dass hier nicht weiter darauf eingegangen werden soll. Die zusätzlichen Anforderungen Z.1, Z.2 und Z.4 lassen sich, aller Voraussicht nach, gut bis sehr gut durch diese Lösung erfüllen. Ein Problem der Zugriffsbeschränkung auf das SAPSystem (Z.3) ist jedoch gegeben. Der dort beschriebene Ausweg, nämlich der manuellen Übernahme der Daten, ist jedoch vertretbar und sollte kein Kriterium sein, um von diesem Ansatz Abstand zu nehmen Weitere alternative Datenbank-Lösung Als Alternative zur Datenbank-Software von Oracle steht noch die Software von Microsoft zur Verfügung. Der MS-SQL-Server ist ähnlich leistungsfähig, jedoch existiert (bisher) kein zu der HTML DB-Option vergleichbares Framework. Das.NET-Framework von Microsoft beinhaltet zwar auch (Teil-)Lösungen für einzelne Probleme und erleichtert in diesen Berei chen auch deren Entwicklung, jedoch existiert keine einheitliche Gesamtlösung, die mit Oracles HTML DB vergleichbar wäre. Damit erfordert die Entwicklung von Web-basierten Anwendungen einen höheren Aufwand, so dass dieses System hier nicht weiter untersucht werden soll SAP BEx Die SAP BEx Reporting-Tools [RB05b][RB05d] können entweder mit einer eigenen SAP-Cli ent-software (SAP-GUI) oder über jeden Java-Script-fähigen Browser bedient werden. Der SAP-Client ist in Aussehen und Funktionsweise einem Web-Browser vergleichbar. Die Reporting-Tools bestehen dabei aus einem Query Designer und einem Web Application Desi gner, mit deren Hilfe sich die Web-Reports entwickeln lassen. Daneben existiert ein Add-in für MS-Excel, das auch die direkte Datenübernahme und Auswertungen innerhalb der Anwendung erlaubt (vgl Abbildung 4.12). Über Web Items, das sind spezielle Webreporting-Objekte, die über einen Data Provider mit dem SAP BW verbunden sind, können Daten aus dem SAP BW angezeigt werden. Sie lassen sich in vier Gruppen unterteilen: 1) Display, enthält Tabellen, Charts, Karten, Ticker, Text elemente und einfache Filter, 2) Filtering, enthält Dropdown-Listen, Radio Buttons, Check Boxen, hierarchische Kontextmenüs und Bedingungen, 3) Navigation enthält generische Navi gationsstrukturen und Menüs und 4) Integration enthält einzelne Dokumente, Dokumentenlis ten sowie ein Überwachungsmonitor.

67 4 Projekt 59 Abbildung 4.12 Aufbau und Zusammenspiel der SAP BEx-Reporting-Tools Zur Unterstützung der Endanwender existiert ein Ad-hoc Query Designer, mit dessen Hilfe sich Berichte nach Bedarf direkt aus einer Web-Anwendung heraus erstellen und verändern lassen. Eine als Information Broadcasting benannte Funktionalität ermöglicht es, dass eine er eignis- oder zeitgesteuerte Berichtsverteilung ermöglicht wird (vgl. Abbildung 4.13). Dabei lassen sich diese Berichte als HTML- und/oder MS-Excel-Datei und als HTML-Link (per ) verschicken oder in das Portal integrieren. Abbildung 4.13 Information Broadcasting in SAP BEx

68 Randbedingungen Ein Vergleich zwischen den Web-Reports, also der Darstellung innerhalb eines Web-Brow sers, gegenüber den Plugins in MS-Excel zeigt [RB05e], dass die Darstellung von UnicodeZeichen, die Performance, die Bedienbarkeit, die Einfachheit bei der Verwendung, die fle xiblen Möglichkeiten der Publikation und die einfacheren Layoutanpassungen diese klar gegenüber der Plugin-Lösung im Vorteil sieht. Lediglich bezüglich des geringeren Aufwands bei der Ersterstellung eines Layouts (Templates), der direkten Weiterverarbeitung innerhalb von MS-Excel und den besseren Möglichkeiten beim Ausdruck, ist die zweite Lösung im Vorteil. Bewertung: Da diese Reporting-Tools nur in Verbindung mit dem SAP BW zum Einsatz kommen können, gelten auch hier die in diesem Bereich gemachten Aussagen. Grundsätzlich ist eine solche Funktionalität jedoch zu gebrauchen, wenn die entsprechenden Daten zuverlässig und zeitnah zur Verfügung stehen WebFOCUS Die Anwendung WebFOCUS der Firma Information Builders bildet alle Bereiche der Daten auswertung ab [KKS04]. Dabei können diese Daten in relationalen Datenbanken vorliegen, in proprietären Formaten in alten Datenbeständen (Legacy Systems) vorliegen, in Datenwürfeln (Cubes) oder in einem Data Warehouse gespeichert sein. Eine integrierte ETL-Komponente gehört ebenso zum Leistungsspektrum, wie der Zugang zu einem Data Warehouse mit DrillThrough oder der direkte Zugriff auf unterschiedliche operative Datenbestände. Die Funktionalität (vgl. Abbildung 4.14) ist dabei mit der von SAP BEx vergleichbar und geht sogar darüber hinaus, d.h. es gibt ebenso die Möglichkeit der automatischen zeit- oder ereig nisgesteuerten Berichterstellung, Monitore zur Überwachung von Schwellenwerten, dyna mische und statische Reports mit Grafiken und Charts, Drilldowns, Möglichkeiten der Ad-hoc Erstellung und Änderung von Berichten (Web-basiert), Ausgaben per , als MS-ExcelDatei, als pdf-datei und als HTML-Dokument und eine Portal-Integration mit personalisierter Darstellung. Daneben sind die Möglichkeiten der Visualisierung und Druckaufbereitung gegenüber SAP BEx stark erweitert. Die zusätzliche ETL-Funktionalität ermöglicht zudem die Anbindung mehrerer unterschiedlicher Datenquellen und den direkten Zugriff auf opera tive Datenbestände unterschiedlichen Typs. In der Abbildung 4.10 ist zu sehen, wo WebFocus bei RB zum Einsatz kommt. Die Ziele [RB05c] hierbei sind, aus der Sicht der Anwender, dass ein ganzheitliches Berichtswesen in einer Umgebung bereitgestellt wird, dieses durch einen einfachen und web-basierten Zugriff erreichbar ist, eine Anpassung an die unterschiedlichen Benutzertypen möglich ist und die Fachabteilung in der Berichtserstellung eingebunden werden. Aus Sicht der Technologie und Architektur ist ein flexibler Zugriff auf die Daten aus unterschiedlichen Quellsystemen, eine Reduzierung von redundanter Datenhaltung für Reports und die Vermeidung der Notwendig keit von proprietärer Client-Software (fat clients) als Ziel zu definieren.

69 4 Projekt 61 Abbildung 4.14 Funktionalität von WebFOCUS Diese Anforderungen können durch WebFocus erfüllt werden, wie bereits oben dargelegt. Als Besonderheit ist der direkte Zugriff auf die zugrunde liegenden Daten in Echtzeit möglich (vgl. Abbildung 4.15). Abbildung 4.15 Systemarchitektur WebFOCUS

70 Randbedingungen Bewertung Für WebFOCUS hat gegenüber SAP-BEx den Vorteil, dass es mit unterschiedlichen DBMS zusammenarbeiten kann. Somit ist auch gut geeignet, um z.b. mit der Oracle-Lösung einge setzt zu werden. Der Leistungsumfang erscheint dabei noch weit über den von SAP-BEx hin auszugehen. Ein Vergleich von SAP BEx und WebFocus, der in [RB05a] gemacht wurde, stellt fest, dass SAP BEx für Standardreports zum Einsatz kommen sollte, die über das Web oder in Excel gemacht werden. Dabei ist eine schnelle Entwicklung der Reports möglich, die aus einem SAP BW gespeist werden. Sollen hingegen mehrere, auch unterschiedliche, Quell systeme (z.b. SAP BW, Oracle) mit komplexen Druck- und Visualisierungsmöglichkeiten notwendig sein, so ist nur WebFocus dafür geeignet. Betrachtet man die wenigen Daten die zur Zeit ausgewertet werden könnten, z.b. Marktanteil, so erscheint ein Einsatz nicht zweckmäßig Dokumentum Die Funktionsweise (vgl Abbildung 4.16) eines typischen Dokumentenmanagement-Systems (DMS) wurde bereits in Kapitel 2.2 kurz vorgestellt. Zusätzlich ist im Anhang A eine ausführ lichere Betrachtung dieses Thematik zu finden. Daher sollen hier nur die wesentlichen Merk male dieser speziellen Dokumentenmanagement-Software betrachtet werden [RB02]. Abbildung 4.16 Typische Arbeitsabläufe eines DMS Die Dokumente bestehen aus der Sicht eines Dokumentenmanagement-Systems aus Meta informationen und Dateien bzw. Content. Documentum speichert diese Metainformationen in einem relationalen Datenbankmanagementsystem (RDBMS) und die Dateien bzw. den Con tent in einem Dateisystem (Filesystem). Der Verbund aus der Datenbank und dem Dateisys tem wird als Docbase bezeichnet. Die Docbases werden dabei in sog. Cabinets untergliedert, welche in etwa einem Netzlaufwerk auf einem Datei-Server entspricht. Die Cabinets enthalten Folder. Diese Folder enthalten wiederum Folder und/oder Dokumente.

71 4 Projekt 63 Rollen in Documentum Die Anwender können entsprechend ihrer jeweiligen Berechtigungen in Documentum ver schiedene Funktionen wahrnehmen. Der System-Administrator und Superuser übernimmt dabei administrative Funktionen in Documentum. Der Coordinator ist für die gesamte redak tionelle Informationsorganisation zuständig, d.h. er ist z.b. für die Definition von Workflows verantwortlich. Der Contributer koordiniert als Endnutzer der Anwendungssoftware, die In halte der Dokumente und deren Bearbeitung. Der Consumer ist der Endnutzer von Informa tionen, d.h. er sucht nach Inhalten und lässt sie sich je nach Bedarf anzeigen. Rechteverwaltung Die Basisrechte, die auch als Objektrechte bezeichnet werden, legen fest, wer was mit einem Dokument tun kann. Sie können für jedes Dokument in der DocBase individuell vergeben werden. Sie werden durch den Anwender, der ein Dokument erstellt hat bzw. im Besitz des Dokuments ist, vergeben oder standardmäßig durch den econtent Server. Zusätzlich zu den Basisrechten können erweiterte Rechte vergeben werden, die dem Anwender erlauben weitere Handlungen an einem Dokument vorzunehmen. Die Acces Control Lists (ACLs) sind bereits vordefinierte Rechte-Sets. In ihnen werden für bestimmte Anwender bzw. Anwendergruppen Rechte festgelegt. Die ACLs werden dann ent sprechenden Documentum-Objekten (Dokumente, Ordner, Kabinetts) zugeteilt. Ordner Alle Dokumente werden in Documentum in Ordnern zusammengefasst. Den Ordnern werden ACLs zugeteilt. Sie bestimmen u.a., ob ein Ordner im Documentum-Desktop bzw. IntranetClient angezeigt wird. Wird ein Dokument innerhalb eines Ordners neu angelegt, so erbt es die übergeordneten Rechte dieses Ordners. Anwender und Gruppen Ein Anwender ist, wer Zutritt zu einer Docbase hat und einen NT-User Account besitzt. Die Anwender sind Personen aber auch virtuelle Accounts. Eine Gruppe ermöglicht einer Teil menge von Anwendern den Zugang zu bestimmten Ordnern bzw. Dokumenten. Sie kann ein zelne Personen oder auch weitere Gruppen enthalten. Die Anwender bzw. Gruppen sind in sog. Anwender-Objekten (dm_user object) bzw. Gruppenobjekten (dm_group object) festge halten. Sie können von einem Sysadmin-Anwender im Documtentum-Administrator angelegt bzw. modifiziert werden. Dort werden auch die Anwender-Privilegien vergeben (z.b. Create Group). Um die abgelegten Dokumente Zugänglich zu machen, kennt Documentum die Mechanismen Replikation, d.h. die Verteilung von Metainformationen und Content, verteilter Content, d.h. die Verteilung von Content und die zentrale Haltung der Metadaten (wird bei RB nicht umge setzt) und lokale Docbases. Diese Mechanismen können auch in einer Mischform eingesetzt und auf Docbase-, Cabinet- oder Folder-Ebene angewendet werden. Auch lokale Docbases können übergreifend als Informationspool angeboten werden, der Zugriff wird dann über sog. Docbroker geregelt.

72 Randbedingungen Bewertung Die Forderung nach dem Einsatz eines Dokumentenmanagement-System taucht im An forderungskatalolog (vgl. Kapitel 4.3) nicht auf. Somit findet später auch keine Bewertung statt, so dass dies bereits an dieser Stelle geschehen soll. Die Funktionalität von Documentum ist grundsätzlich sehr gut geeignet, um eingesetzt zu werden. Durch diesen Einsatz würde die Problematik der Ablage und vor allem das Wieder finden von Dokumenten und Inhalten entschärft. Das integrierte Rechtesystem stellt sicher, dass Dokumente nur von dafür autorisierten Personen oder Gruppen geöffnet werden können. Der Leistungsumfang geht dabei aber weit über das hinaus, was zur Zeit benötigt wird. Teile der benötigten Funktionalität lassen sich innerhalb des Anwendungsprogramms realisieren. Der erhöhte Aufwand für die Anbindung und die Kosten für die Bereitstellung würden den praktischen Nutzen bei weitem übersteigen. Es erscheint daher nicht sinnvoll, dass dieses Sys tem in der aktuellen Situation eingesetzt wird. Sollte sich die Anzahl der Dokumente in der Zukunft jedoch start erhöhen, so sollte dieser Ansatz weiter verfolgt werden. 4.7 Anforderungserfüllung Die Auswahl der geeigneten Software soll durch einen Vergleich der möglichen Lösungs alternativen (vgl. Anforderung S.6) und den Anforderungen, die bereits in Kapitel 4.3 aufge schlüsselt wurden, erfolgen (vgl Tabelle 4.2 und 4.3). Die Anforderungen an die Daten (vgl. Kapitel 4.3.1) sind von allen System erfüllbar und sollen daher hier nicht detaillierter betrach tet werden. Interessanter sind die funktionalen (vgl. Kapitel 4.3.2) und sonstigen An forderungen (vgl. Kapitel 4.3.3), da sich hier die größten Unterschiede der verschiedenen Lö sungsalternativen zeigen. Diese funktionalen und sonstigen Anforderungen sollen nun etwas detaillierter betrachtet werden und bezüglich der potentiellen Software bewertet werden, d.h. es soll die Frage ge stellt werden, ob und wie eine bestimmte Anforderung durch die Software erfüllt werden kann. Viele dieser Bewertungen sind subjektiv und erheben keinen Anspruch auf Vollständig keit. Die Grundlage dieser Bewertungen sind die Dokumentationen und Leistungs beschreibungen der jeweiligen Softwarepakete [SAP05][Mic05][Beh04][Ora05a]. Eine rein objektive Bewertung wäre erst möglich, wenn versucht würde, mit allen Software-Optionen das Projekt zu realisieren und abschließend zu bewerten. Diese Vorgehensweise würde jedoch den Rahmen der Arbeit bei weitem sprengen. Funktionale Anforderungen: F.1 Eine Implementierung von Suchfunktionen ist mit einfachen Mitteln in allen betrachte ten System möglich. Such- bzw. Auswahlfunktionen sind ein Grundbestandteil eines je den Datenbanksystems. Eine Unterstützung bei der Implementierung dieser Funktionali tät über eine Benutzungsschnittstelle (GUI) durch das Framework ist dabei hilfreich, wie dies z.b. bei der Oracle-Lösung der Fall ist. F.2 Der Zugriff auf die Anwendung vom Intra- bzw. Internet erfordert eine Client-ServerArchitektur. Im Datenbank- bzw. Data Warehouse-Bereich kommt hierbei häufig eine

73 4 Projekt 65 logische Drei-Schichten-Architektur zum Einsatz, also eine Trennung von Client, Ap plikations-server und Datenbank. Die Architektur wird von allen untersuchten Syste men angeboten. Die Systeme auf Basis von SAP haben den Vorteil, dass der dort verfügbare Browser von den meisten Mitarbeitern sowieso benutzt wird und damit be reits geöffnet ist. Damit sind die Benutzer auch bereits angemeldet und haben sich gegenüber dem System bereits authentifiziert, was hiermit auch für die zu imple mentierende Anwendung der Fall wäre (Single Sign-on). Auf Seiten von Oracle und dem MS-SQL-Server besteht die Möglichkeit der Authentifizierung über LDAP bzw. NTLM, also die automatische Verwendung der Login-Daten des Intranets. F.3 Die funktionale Anforderung F.3 (Offline-/CD-Version) stellt einen besonderen Punkt dar. Wegen der Client-Server-Architektur aller zur Auswahl stehenden Software-Lö sungen, erscheint eine Realisierung zunächst nicht möglich. Daher wurde diese An forderung als optional gekennzeichnet. Verschiedene Möglichkeiten zur Lösung dieser Anforderung werden in Kapitel 7 (Ausblick) diskutiert. F.4 Eine Benachrichtigung der Benutzer über Änderungen am Datenbestand erfordert, dass die Datenbank bzw. der Applikations-Server in der Lage ist s zu versenden. Eine Sammlung von s und die Bewertung der Wichtigkeit kann durch das Anwendungsprogramm erfolgen. Die SAP-Lösung in Verbindung mit SAP BEx bietet z.b. die Möglichkeit zum automatischen Versandt von s, ebenso wie Oracle HTML DB. F.5 Neben der automatischen Benachrichtigungen soll die Möglichkeit bestehen, dass die letzten Änderungen anzeigt und ausgewählt werden können. Die Funktionalität lässt sich gemäß den Anforderung F.1 bei allen Systemen erfüllen, indem die Suche nach einem bestimmten Zeitpunkt bzw. Zeitraum eingegrenzt wird. Hierfür ist es notwendig den Änderungszeitpunkt abzuspeichern. F.6 Die Neueingabe und Änderung von Daten, Bildern und Dokumenten ist mit allen be trachteten Systemen gleichermaßen möglich. Das Abspeichern von binären Daten (z.b. Bilder, Grafiken, Dokumente im PDF-Format) wird von allen Datenbanken unterstützt. Denkbar ist auch die Speicherung von Verweisen in der Datenbank und die Ablage der Dateien auf einem Dateisystem, wie die in Dokumentenmanagement-Systemen gemacht wird. F.7 Die Möglichkeit eines Vergleichs von Daten, in unserm Bereich die technischen Daten der Saugmodule bzw. Saugrohre und Pkw-Modelle, fällt in den Bereich der Grund funktionalität eines jeden Datenbanksystems. Dies leisten alle der Systeme in gleicher Weise. F.8 Die Ergebnisse der Vergleiche, die abgelegten Analyseberichte und die erzeugten Be richte sollen abzuspeichern sein und auch ausgedruckt werden können. Die Speicherung von Daten in verschiedenen Formaten wird von den verwendeten Clients (Browser) un terstützt. Auch kann von dort der Ausdruck initiiert werden. Eine Unterstützung von weiterer Funktionalität durch die Anwendung ist zusätzlich möglich (z.b. SAP BEx und HTML DB). F.9 Die Anzeige von Bildern und Dokumenten wird durch den Browser bzw. der auf den Rechnern der Anwender installierten Software unterstützt. Die automatische Erzeugung von Vorschaubildern der hochgeladenen Bilder wird z.b. von Oracle HTML DB (in

74 Anforderungserfüllung termedia) unterstützt. Ähnliche Funktionalitäten lassen sich auch bei den anderen Syste men implementieren. Die Anzeige von Bildern in Berichten und die Vollbildanzeige dieser bei Bedarf stellt keine der alternativen Lösungen vor allzu große Probleme. F.10 Die Ermittlung von Marktanteilen von Saugrohren bzw. Saugmodulen benötigt die Da ten des Verkaufs von Bosch und die Verkaufs- bzw. Produktionszahlen der Fahrzeug produzenten. Die letzteren Daten sind allerdings nicht zu bekommen, so dass über die entsprechenden Zulassungszahlen versucht wird an diese Daten heranzukommen. Sind diese Werte zu bekommen, so lassen sich damit die entsprechenden Marktanteile annä herungsweise bestimmen. Eine grafische Darstellung dieser Ergebnisse ist wünschens wert. Da die Verkaufszahlen direkt im SAP-System vorhanden sind, ist eine automa tische Übernahme dieser Werte, gegenüber den anderen Systemen, einfacher zu bewerk stelligen. Die grafische Darstellung lässt sich über die Reporting-Tools, über die in tegrierte Funktionalität in Oracle HTML DB, sowie über entsprechende Bibliotheken des.net-frameworks (MS-SQL-Server) bewerkstelligen. F.11 Das automatische Extrahieren von Kennzahlen aus Berichten stellt auch einen Punkt dar, der in dieser Arbeit nicht gelöst werden kann. Zum Einen sind die Anforderungen an eine solche Funktionalität sehr hoch, zum Anderen liegen die Berichte in einer so un terschiedlichen und teilweise unstrukturierten Form vor, dass eine Lösung zunächst nicht praktikabel erscheint. Implementiert werden könnte eventuell eine Suchfunktion innerhalb eines Berichts. Dies leistet aber meist bereits jede Software, die ein solches Dokument anzeigen kann und macht deshalb wenig Sinn. Die automatische Extraktion von Wissen aus Dokumenten, das sog. Text-Mining, ist eine spezielle Funktionalität von Dokumentenmanagement-Systemen. und ist ansatzweise im Anhang A beschrieben. Sonstige Anforderungen S.1 Authentifikations- - und Authorisationsmechanismen werden von allen betrachteten Systemen angeboten. Dabei kann die Authentifikation sowohl gegenüber dem eingesetz ten DBMS geschehen, als auch auf der Ebene des Anwendungsprogramms erfolgen. S.2 Obwohl selbstverständlich alle Systeme erweiterbar sind, so gibt es doch Unterschiede beim Aufwand zur Erfüllung dieser Anforderung. Bei der Hinzunahme von neuen Da tenbeständen sind die Unterschiede zwischen den verglichenen Systemen eher gering. Größere Unterschiede ergeben sich bei der dabei notwendigen Anpassung der Anwendungsprogramme. Hierbei ist der Ansatz, der in Oracle HTML DB verfolgt wird, gegenüber den anderen Lösung klar die bessere Wahl. S.3 Ähnlich der Anforderung S.2, so bietet bei der einfachen und schnellen Anpassung des Aussehens des Anwendungsprogramms auch hier die Oracle-Lösung die besseren Lö sungsmodelle an, indem dort das Aussehen einer kompletten Anwendung durch die Verwendung von Templates verändert werden kann, ohne diese selbst zu verändern. S.4 Die Usability, also die einfache und intuitive Bedienbarkeit der Anwendung hängt mehr von der erstellten Anwendung als von den dafür verwendeten Software ab. Diese Arbeit kann jedoch von einem entsprechenden Framework unterstützt werden und erleichtert so die Erstellung einer konsistenten und leicht zu bedienenden Oberfläche. Vergleichbare Frameworks existieren für alle Systeme.

75 4 Projekt S.5 67 Die Anforderung, dass die Bedienung über ein Web-Interface möglich sein soll, ver schiebt die Anforderung S.1 und S.4 in das Fenster eines Web-Browsers. Es soll si chergestellt sein, dass die komplette Bedienung und Interaktion zwischen Benutzer und Anwendung durch einem Web-Browser möglich ist. Diese Anforderung hat einen ent scheidenden Einfluss auf die Architektur, die bereits in Abbildung 4.5 dargelegt wurde. Eine solche Architektur lässt grundsätzlich sich mit allen betrachteten Lösung realisieren, jedoch unterscheidet sich der dafür nötige Aufwand teilweise erheblich. Die einfachste und am schnellsten realisierbare Lösung ist auch hier durch das OracleFramework möglich. Die Ergebnisse dieser Analyse sind in der Tabelle 4.2 übersichtlich zusammengefasst. Viele dieser Bewertungen sind rein subjektiver Natur und wurden aufgrund der oben diskutierten Aussagen gemacht. Es kann sicherlich auch darüber gestritten werden, ob an der einen oder anderen Stellte eine bestimmte Bewertung nun gerechtfertigt ist oder nicht. Möglicherweise bietet auch eine neuere Software-Version eine bestimmte Funktionalität, die eventuell nicht beachtet wurde. Dies verändert aber vermutlich nichts wesentliches am Gesamtergebnis SAP BW mit SAP BEx SAP BW mit WebFOCUS Oracle 9i/10g mit HTML DB Alternative Datenbank (z.b. MS-SQL-Server) Funktionale Anforderungen: F.1 (Suchfunktion) F.2 (Intra-/Internetzugriff) F.3 (Offline/CD-Version) F.4 ( -Fkt) F.5 (letzte Änderung) F.6 (Editierbarkeit) F.7 (Vergleichsmögl.) F.8 (Ausdruck) F.9 (Grafiken verwalten) F.10 (Marktanteile) F.11 (Extraktion) o o -- Sonstige Anforderungen: S.1 (Sicherheit) S.2 (Erweiterbarkeit) S.3 (Corporate Identity) S.4 (Usability) S.5 (Webinterface) o Daten-Anforderungen entsprechend D.1 D.16 Erfüllung der Anforderung: ++ sehr gut + gut o durchschnittlich - schlecht - - sehr schlecht Tabelle 4.2 Kriterienkatalog zur Software-Auswahl (1)

76 Anforderungserfüllung Der Vergleich zeigt, dass bezüglich der Anforderungen, seien diese nun durch die Daten, durch die gewünschte Funktionalität oder sonstiger Natur bedingt, mit allen Alternativen zu meist gut bis sehr gut zu erfüllen sind. Bei den sonstigen Anforderungen kommen die Vorteile der Oracle-Lösung voll zum Tragen. Da ist zum Einen die einfache Erweiterbarkeit der Anwendung und zum Zweiten die schnelle und einfache Präsentation dieser Ergebnisse über das Web-Interface. Nebenbedingungen bzw. zusätzliche Anforderungen Nicht weniger wichtig sind die Neben- bzw. Randbedingungen, die einzuhalten sind. Eine erste Randbedingung, die in der Sammlung als S.6 dargelegt wurde (vgl ), ist, dass nur Standard-Software eingesetzt werden kann, die bei RB bereits eingesetzt wird. Diese Be dingung begründet die Auswahl der Kandidaten für diesen Vergleich. Ein Charakter dieser Arbeit, nämlich die strenge zeitliche Begrenzung, stellt eine weitere wichtige Nebenbedingung für die Auswahl der Software dar (vgl. Z.1, Kapitel 4.5.3). Diese zeitliche Begrenzung betrifft u.a. den Aufwand für die Einarbeitung, d.h. es muss innerhalb des engen zeitlichen Rahmens dieser Arbeit möglich sein, die Softwarelösung ausreichend verstehen und beherrschen zu können, um damit die angestrebten Ziele erreichen zu können. Da erst zur Halbzeit dieser Arbeit entschieden werden konnte, welche Software zum Einsatz kommt, ist die verbleibenden Zeit einfach zu kurz, um eine Lösung mittels der SAP-Software zu erreichen (vgl. Z.2). Weiterhin dagegen spricht die Tatsache, dass SAP-Lösungen für Pro jekte dieser Art einfach zu umfangreich sind und einen zu langen Vorlauf erfordern. Daneben unterliegen alle Projekte im SAP-Bereich (bei der Firma Robert Bosch GmbH) einem Relea se-zyklus, d.h. eine Entwicklung ist nur langfristig möglich. Dagegen erscheint Oracle HTML DB besser geeignet, um die Ziele im zeitlichen Rahmen erreichen zu können. Die Dauer für die Bereitstellung durch die firmeninterne IT-Abteilung ist auch zu beachten und sollte nicht unterschätzt werden. Je einfacher die Lösung, desto schneller sollte diese Dienstleistung bereitgestellt werden können. Diese Vermutung hat sich allerdings als falsch herausgestellt, wie sich im Verlauf der Arbeit gezeigt hat. Mehr dazu in Kapitel 6. Der zeitliche Aufwand, der für die Implementierung der Datenbank und des Anwendungspro gramms notwendig ist, korreliert direkt mit der Einfachheit der Benutzung des Framework der verwendeten Software. Hierbei scheint die Software von Oracle einen guten Kompromiss zwischen der Leistungsfähigkeit und der Einfachheit der Verwendung gefunden zu haben. Der Aufwand für die Änderungen und die Erweiterungen der implementierten Lösung liegt zwar nicht innerhalb dieses engen zeitlichen Rahmens. Bei der Bewertung spielt dies aber in Bezug auf die Wartbarkeit und die Anpassungsfreundlichkeit eine bedeutende Rolle. Auch hier stellt die Lösung mit Oracle und dem HTML-DB-Framework klar seine Vorteile heraus. Betrachtet man nun die Kosten, die mit der Bereitstellung der Dienstleistung für die jeweilige Fachabteilung verbunden ist (vgl. Z.4), so ist anzunehmen, dass auch hier eine etwas einfache re Lösung kostengünstiger angeboten wird. Wie schon bei der Datenbeschaffung, so sollte die finanzielle Belastung der Kostenstelle der Abteilung GS-AM/ENG3 so gering wie möglich ausfallen. Eine Übersicht über die teilweise subjektiv bewerteten Kriterien ist in Tabelle 4.3 zu finden. Auch für diese Tabelle gelten die Aussagen die bereits bezüglich Tabelle 4.2 gemacht wurden.

77 4 Projekt 69 SAP BW mit SAP BEx Zeitliche Aufwandsabschätzung: Z.1: Einarbeitung Z.2: - Bereitstellung - Implementierung - Änderungen - Erweiterungen Z.4: Kosten für Realisierung bzw. Bereitstellung SAP BW mit Oracle 9i/10g Alternative WebFOCUS mit HTML DB Datenbank (MSSQL-Server) o o o o o o Aufwand/Kosten : ++ sehr gering + gering o durchschnittlich - hoch - - sehr hoch Tabelle 4.3 Kriterienkatalog zur Software-Auswahl (2) Eine weitere Alternative, die nicht in die Tabelle aufgenommen wurde, wäre die Nutzung von Oracle HTML DB in Verbindung mit WebFOCUS als Reporting-Tool. Dieser Ansatz ist grundsätzlich auch möglich, jedoch sind die Anforderung an die Analyse bzw. Auswertung der Zahlen so gering, dass der Einsatz einer so komplexen und umfangreichen Software, wie WebFOCUS, in dieser Ausbaustufe der Arbeit als unnötig angesehen werden kann. Nebenbei bemerkt würde dieser Einsatz selbstverständlich wieder mit Kosten, z.b. für die Bereitstellung der Software und der Dienstleistung, verbunden sein, die in keinem Verhältnis zum wirkli chen Nutzen stehen. Ähnliches gilt für den Einsatz eines Dokumentenmanagement-Systems (Dokumentum). Die Anzahl der Dokumente (vgl Kapitel 4.5.1) ist einfach zu gering, um diesen Einsatz, den Aufwand zur Anbindung und die zusätzlichen Kosten der Software zu rechtfertigen. 4.8 Entscheidung für Oracle HTML DB Betrachtet man nun die im vorherigen Kapitel untersuchten Anforderungen und die Nebenbe dingungen, so lässt sie damit ein klarer Favorit ermitteln. Die Entscheidung für Oracle HTML DB ist vor allem auf Grund der Nebenbedingungen klar gefallen. Hier ist Oracle in Ver bindung mit dem HTML DB-Framework eindeutig die beste Wahl. Die einfache Unter stützung bei einer schnellen Entwicklung von leicht bedienbaren datenbankgestützten Anwendungen, inklusive eines ausgewachsenen Rechte- und Zugriffsmanagements für Benutzer und Entwickler spielen dabei ebenso eine Rolle, wie die einfache Erweiterbarkeit und Wartbarkeit bei Änderungen. Wegen der eher geringen Anforderungen an die Auswertung der Daten wird auf den zusätzli chen Einsatz eines Reporting-Tools verzichtet. Das in Frage kommende WebFOCUS wäre in

78 Entscheidung für Oracle HTML DB diesem Fall erheblich überdimensioniert und erfordert zudem einen zusätzlichen Lernaufwand bei der Bedienung. Das selbe gilt auch für ein Dokumentenmanagement-System. Die Anzahl der Dokumente, die zur Zeit verwaltet werden könnten, würde einen solchen Einsatz nicht rechtfertigen. Sollten sich die Anforderungen z.b. bezüglich der Auswertungen erhöhen, so könnte ein Einsatz und eine Anbindung eines Reporting-Tools durchaus in Erwägung gezogen werden. Ebenso verhält es sich mit dem Einsatz eines Dokumentenmanagement-Systems. Sollte sich die Anzahl der Dokumente, die strukturiert abgelegt werden sollen, stark erhöhen, so wäre eine Verwendung und Anbindung zu vertreten. 4.9 Architekturbild nach Softwareauswahl Darstellung der Oracle HTML DB-Architektur in Verbindung mit dem DW und den Daten quellen. Entsprechend dem ersten Architekturentwurf nur verfeinert und spezialisiert. Applikations-Server Clients DBMS / Data Warehouse Data Warehouse HTTPServer HTML DBEngine Oracle 9i/10g Drucker OCRProzess Scanner Analyse-, Benchmark- und Zerlegungsberichte Auto Katalog Datenquellen Abbildung 4.17 Architektur mit Oracle HTML DB SAP

79 4 Projekt 71 Wie in der Abbildung 4.17 zu sehen ist, entspricht die Architektur, die mit der Oracle HTML DB-Lösung verwirklicht werden kann, der, die bereits als Prototyp im Kapitel 4.4 angegeben wurde. Somit bestätigt sich die Erfüllbarkeit vieler Anforderungen durch diese Lösung Entwurf des Data Warehouse Nachdem nun die Anforderungen bestimmt sind, die Analyse der Daten und die Auswahl der Software erfolgt ist, kann ein erster Entwurf des Schemas der Daten erfolgen. Eine vorherige Bestimmung der Software ist für den konzeptuellen Entwurf nicht notwendig, da dieser ja un abhängig davon erfolgen kann. Die ausgewählte bzw. eingesetzte Datenbank-Software spielt jedoch in den darauf folgenden Entwurfsphasen eine Rolle. Die Daten eines Pkw-Modells und deren Beziehungen zu Hersteller, Motor, Saugmodul und Saugrohr sind in Abbildung 4.18 als E/R-Diagramm dargestellt. DICHTUNGSKONZEPTE... BEZEICHNUNG 1 1..n SAUGMODUL hat ANSCHLUSSKONZEPT SAUGROHR 1..n... BEZEICHNUNG hat HUBRAUM 1..n LEISTUNG MOTOR 1..n... NAME... hat 1..n 1..n MODELL BEZEICHNUNG 1 baut HERSTELLER... Abbildung 4.18 E/R-Diagramm Es dient dabei als Vorlage zum besseren Verständnis und zur Erkennung von Zusammen hängen. Die Attribute sind, aus Gründen der Übersichtlichkeit, nur angedeutet.

80 Entwurf des Data Warehouse Da es sich hier um ein Data Warehouse handelt, werden in die Kapitel 3 beschriebenen Richt linien beim Entwurf umgesetzt Konzeptueller Entwurf Zur Identifikation von Fakten und Dimensionen existiert keine Regel. Es ist ein kreativer Akt, der Erfahrung und ein Verständnis der Zusammenhänge verlangt. Fakten lassen sich am einfachsten dadurch identifizieren, indem dort die Daten gesammelt werden, die ausgewertet werden sollen. Diese Daten stehen zudem in einem zeitlichen Zusammenhang und sollten Werte enthalten, die einen additiven Charakter haben. Die Granularität der Daten in den Fak tentabellen muss mit denen damit verbundenen Dimensionen korrespondieren [Kim97] [Kim03a] [Kim03b]. In unserem Fall interessieren auf diesem Gebiet die Marktanteile der Saugmodule bzw. Saug rohre. Diese lassen sich durch die Verkaufszahlen und entsprechenden Zulassungszahlen der betreffenden Modelle errechnen bzw. abschätzen. Eine ME/R-Modellierung der Marktanteile für das Saugmoduls ist in Abbildung 4.19 zu sehen. Die Modellierung für die Marktanteile des Saugrohrs unterscheidet sich nur in der Bezeichnung des Fakt. JAHR HERSTELLER SAUGMODUL QUARTAL MODELL Marktanteil_ SM MONAT ZULASSUNGSZAHLEN_D SM_VERKAEUFE BEMERKUNG Abbildung 4.19 ME/R-Modellierung Marktanteil_SM Weiter von Interesse sind Rückrufaktionen von Saugmodulen bzw. Saugrohren mit den ent sprechenden Pkw-Modellen. Eine weitere Auswertung lässt sich über die RFQ-Beteiligung, also einer Beteiligung der Abteilung (GS-AM/ENG3) am gesamten Entwicklungsprozess des Saugmoduls bzw. Saugrohrs, inklusive der Ausschreibung, erstellen. Zur Sammlung von Pro blemen, die mit den Saugmodulen bzw. Saugrohren erkannt wurden, dient eine weitere Fak tentabelle. Beispielhaft ist die ME/R-Modellierung für die Modellierung des PROBLEM-Fak

81 4 Projekt 73 ts in Abbildung 4.20 dargestellt. Die ME/R-Modelle für die Fakten RUECKRUFAKTION und RFQ_BETEILIGUNG sind entsprechend, mit etwas veränderten Attributen. Die Daten der Zulassungszahlen sind höchstens einmal pro Monat zu erhalten. Damit stellt dies die kleinste zeitliche Granularität für die Faktentabelle MARKTANTEIL_SM bzw. MARKTANTEIL_SR dar. Diese zeitliche Auflösung ist auch für die anderen Faktentabellen (RUECKRUFAKTION, RFQ_BETEILIGUNG und PROBLEM) ausreichend. Nebenbei be merkt, beinhalten die zuletzt genannten Faktentabellen keine Daten, die sich aggregieren lassen. Sie stellen damit nicht das Ideal einer Faktentabelle dar (vgl. [Kim03a]), denn Aus wertungen lassen sich hiermit lediglich z.b. hinsichtlich der Anzahl der Ereignisse innerhalb eines Zeitrahmens machen. JAHR HERSTELLER MODELL SAUGMODUL QUARTAL PROBLEM MONAT SAUGROHR BESCHREIBUNG Abbildung 4.20 ME/R-Modellierung Problem Eine wichtige Dimension stellt die Zeit dar. Sie ist die Grundlage für die Auswertungen, die durch das Data Warehouse ermöglicht werden sollen. Alle anderen Daten wandern in die je weiligen Dimensionen. Das sind u.a. alle technischen Daten von den Saugmodulen bzw. Saugrohren und den Modellen. Damit ergeben sich die folgenden Dimensionen: ZEIT, MODELL, SAUGMODUL und SAUGROHR. Die Analyse-, Benchmark- und Zerlegungsberichte, die sich jeweils auf ein Saugmodul bzw. Saugrohr beziehen, stellen eine Besonderheit dar. In ihnen sind weiterführende Detailinforma tionen zu bestimmten Sachverhalten dargestellt, die zwar mit der entsprechenden Dimension verknüpft sind, selbst aber keine Fakten und keine Dimensionen darstellen. Eine Speicherung dieser Daten innerhalb einer Dimension (z.b. Saugmodul bzw. Saugrohr) ist grundsätzlich auch möglich. Dies wurde aber aus Gründen der Übersichtlichkeit und der besseren Trennung der Sachverhalte nicht gemacht.

82 Entwurf des Data Warehouse Logischer Entwurf Das Ziel des logischen Entwurfs ist eine Abbildung des Dimensionschematas aus dem kon zeptuellen Entwurf in ein Schema, das die Eigenschaften der ausgewählten Zieldatenbank be rücksichtigt. In unserem Fall erfolgt die Abbildung auf eine relationale Datenbank und damit auf Tabellen. Als logisches Schema wurde das Snowflake-Schema verwendet. Aus Gründen der Übersichtlichkeit wurden in der Abbildung 4.21 die teilweise normalisierten Tabellen nur bezüglich der niedrigsten Ebene angezeigt. MODELL MODELL_ID (PK) HERSTELLER_ID MODELLJAHR SOP EOP TEILEHERSTELLER BEZEICHNUNG AUFBAU TUEREN SITZPLAETZE BAUART_ZYLINDERANZAHL EINBAULAGE HUBRAUM BOHRUNG_HUB VERDICHTUNG VENTILE_ZYLINDER LAGE_NOCKENWELLE_VENTILE GEMISCHAUFBEREITUNG AUFLADUNG LEISTUNG_BEI_UMDR MAX_DREHMOMENT_BEI_UMDR ANTRIEBSART SCHALTGETRIEBE_GAENGE AUTOMATIKGETRIEBE_GAENGE VORDERACHSE HINTERACHSE SERVOLENKUNG BREMSEN_VO_HI ANTIBLOCKIERSYSTEM ANTRIEBSSCHLUPFREGELUNG SERIEN_BEREIFUNG RADSTAND SPUR_VO_HI AUSSENMASSE_L_B_H LEERGEWICHT ZUL_GESAMTGEWICHT KOFFERRAUMVOLUMEN_MIN_MAX ANHAENGERLAST_GEBREMST TANKINHALT BESCHLEUNIGUNG HOECHSTGESCHWINDIGKEIT VERBRAUCH KRAFTSTOFFART ZEIT ZEIT_ID (PK) MONAT MONAT_BEZEICH QUARTAL JAHR MARKTANTEIL_SR MODELL_ID SAUGROHR_ID ZEIT_ID SR_VERKAEUFE ZULASSUNGSZAHLEN_D BEMERKUNG RFQ_BETEILIGUNG MODELL_ID ZEIT_ID SAUGROHR_ID SAUGMODUL_ID RB_ANGEBOT SOD RB_TP PROBLEM MODELL_ID ZEIT_ID SAUGROHR_ID SAUGMODUL_ID BESCHREIBUNG MARKTANTEIL_SM MODELL_ID ZEIT_ID SAUGMODUL_ID SM_VERKAEUFE ZULASSUNGSZAHLEN_D BEMERKUNG RUECKRUFAKTION MODELL_ID ZEIT_ID SAUGROHR_ID SAUGMODUL_ID BESCHREIBUNG SAUGROHR SAUGROHR_ID (PK) BEZEICHNUNG TEILEHERSTELLER_ID BENCHMARKBERICHT_ID ANALYSEBERICHT_ID ZERLEGUNGSBERICHT_ID SAP_STUELI_LINK ANSCHRAUBKONZEPTE MATERIALART GEWICHT RUNNERLAENGE RUNNERQUERSCHNITTE PELUMVOLUMEN FUELLUNGSOPTI AUFFAELLIGKEITEN BESSER_ALS_RB PROZESSABNORMITAETEN DICHTUNGSKONZEPTE SCHALENAUFBAU PROZESSTECHNIK ABMASSE_KOMPONENTEN SAUGMODUL SAUGMODUL_ID (PK) SAUGROHR_ID BEZEICHNUNG ANALYSEBERICHT_ID BENCHMARKBERICHT_ID ZERLEGUNGSBERICHT_ID ABMASSE_L_B_H DVE KSZ TEV AKTUATOR_GPA AKTUATOR_TPSE SENSOR ANSCHL_BKV ANSCHL_LENKHILFEPUMPE SG KB BBV SCHLAEUCHE CLIPSE Abbildung 4.21 Galaxie Da alle Faktentabellen über gemeinsame Dimensionstabellen zusammenhängen spricht man hier von einer Galaxie bzw. Constellation (vgl. Kapitel ). Die Aufteilung der Faktentabellen RUECKRUFAKTION, RFQ_BETEILIGUNG und PRO BLEM ist nicht zwingend notwendig, da sie mit den selben Dimensionen verbunden sind und auch die selbe Granularität bezüglich dieser Dimensionen haben. Die Gründe hierfür wurden oben bereits dargelegt. Denkbar wäre auch eine gemeinsame Faktentabelle mit unterschiedli chen Ansichten (Views) für die jeweiligen Zwecke. Dagegen spricht allerdings die zusätzli chen Join-Operation zur Auflösung der Ansicht bei Anfragen. Eine Lösung wäre hierfür die Verwendung von materialisierten Ansichten (Materialized Views).

83 4 Projekt 75 Die Faktentabellen MARKTANTEIL_SR bzw MARKTANTEIL_SM wurden unterteilt und sind jeweils nur noch mit der entsprechenden Dimension (SAUGROHR bzw. SAUGMO DUL) verbunden. MODELL_SM MODELL_ID SAUGMODUL_ID MODELL_SR MODELL_ID SAUGROHR_ID MODELL MODELL_ID (PK) HERSTELLER_ID MODELLJAHR SOP EOP TEILEHERSTELLER BEZEICHNUNG AUFBAU TUEREN SITZPLAETZE BAUART_ZYLINDERAN EINBAULAGE HUBRAUM BOHRUNG_HUB VERDICHTUN... HERSTELLER HERSTELLER_ID (PK) HERSTELLERNAME HERSTELLERADRESSE WWW_HERSTELLER IMPORTEUR WWW_IMPORTEUR TEILEHERSTELLER_SM MARKTANTEIL_SR MODELL_ID SAUGROHR_ID ZEIT_ID SR_VERKAEUFE ZULASSUNGSZAHLEN_D BEMERKUNG SAUGMODUL_ID TEILEHERSTELLER_ID BEMERKUNG SAUGMODUL SAUGMODUL_ID SAUGROHR_ID BEZEICHNUNG ANALYSEBERICHT_ID BENCHMARKBERICHT_ID ZERLEGUNGSBERICHT_ID ABMASSE_L_B_H DVE KSZ TEV... (PK) TEILEHERSTELLER TEILEHERSTELLER_ID NAME ADRESSE WWW_ADRESSE ANSPRECHPARTNER BEMERKUNGEN (PK) ANALYSEBERICHT RFQ_BETEILIGUNG MODELL_ID ZEIT_ID SAUGROHR_ID SAUGMODUL_ID RB_ANGEBOT SOD RB_TP PROBLEM MODELL_ID ZEIT_ID SAUGROHR_ID SAUGMODUL_ID BESCHREIBUNG SAUGROHR SAUGROHR_ID BEZEICHNUNG TEILEHERSTELLER_ID BENCHMARKBERICHT_ID ANALYSEBERICHT_ID ZERLEGUNGSBERICHT_ID SAP_STUELI_LINK ANSCHRAUBKONZEPTE MATERIALART GEWICHT... ANALYSEBERICHT_ID BEZEICHNUNG TEXT (PK) (PK) BENCHMARKBERICHT BENCHMARKBERICHT_ID (PK) BEZEICHNUNG TEXT ZERLEGUNGSBERICHT ZERLEGUNGSBERICHT_ID BEZEICHNUNG TEXT (PK) MARKTANTEIL_SM ZEIT ZEIT_ID (PK) MONAT MONAT_BEZEICH QUARTAL JAHR MODELL_ID ZEIT_ID SAUGMODUL_ID SM_VERKAEUFE ZULASSUNGSZAHLEN_D BEMERKUNG RUECKRUFAKTION MODELL_ID ZEIT_ID SAUGROHR_ID SAUGMODUL_ID BESCHREIBUNG BILDER DOKUMENTE DOKUMENT_ID (PK) DOKUMENT_NAME FILENAME TITLE MIME_TYPE DOC_SIZE CREATED_ON DOKUMENT DESCRIPTION MODELL_ID SAUGMODUL_ID SAUGROHR_ID ANALYSEBERICHT_ID BENCHMARKBERICHT_ID ZERLEGUNGSBERICHT_ID IMAGE_ID (PK) IMAGE_NAME FILENAME TITLE MIME_TYPE DOC_SIZE CREATED_ON DATE IMAGE DESCRIPTION MODELL_ID SAUGMODUL_ID SAUGROHR_ID ANALYSEBERICHT_ID BENCHMARKBERICHT_ID ZERLEGUNGSBERICHT_ID THUMBNAIL Abbildung 4.22 Gesamtübersicht aller Zusammenhänge Bei alle Dimensionen wird als Primärschlüssel (PK) ein künstlich erzeugter Schlüssel, der auch als surrogate key bezeichnet wird, verwendet. Die Faktentabellen erhalten als Primär schlüssel die Fremdschlüssel der Dimensionen, die mit ihnen verbundenen sind. In un serem Fall wird der Primärschlüssel der Faktentabelle MARKTANTEIL_SM also aus den künstlich erzeugten Fremdschlüsseln der Dimensionen MODELL, SAUGMODUL und ZEIT gebildet. Bei der anderen Faktentabelle (MARTKANTEIL_SR) ist dies analog. Der zu sammengesetzte Primärschlüssel bei den Fakten PROBLEM, RUECKRUFAKTION und RFQ_BETEILIGUNG besteht aus vier Fremdschlüsseln, nämlich MODELL, SAUGROHR,

84 Entwurf des Data Warehouse SAUGMODUL und ZEIT. Die Zusammenhänge aller Tabellen sind in Abbildung 4.22 zu se hen Physischer Entwurf Aus dem logischen Schema (vgl. Abbildung 4.22) wird der physische Entwurf für das relatio nale DBMS abgeleitet. Ein weiteres Ziel des physischen Entwurfs ist die Optimierung des Antwortzeitverhaltens. Dies wird z.b. durch das Hinzufügen von Indexen für Fremdschlüssel erreicht. Auch spezielle Indexstrukturen wie Bitmap-Index [CI98] tragen dazu bei, indem dort Ergebnisse von Joins zwischen Fakten- und Dimensionstabellen abgelegt werden. Die Partitionierung bzw. Replika tion des Datenbestandes auf physikalisch unabhängigen und eigenständigen Partitionen dienen auch diesem Zweck. Mehr zu diesem Thema ist in [KR+98] nachzulesen. Das Zielsystem ist ein DBMS von Oracle. Auf dem Entwicklungssystem läuft die Version 10g, auf dem Produktivsystem, das die Anwendung und die Datenbank später aufnehmen soll ist die Version 9i installiert. Da keine speziellen Funktionalitäten verwendet wurden, die nur auf der einen oder anderen Version verfügbar sind, spielen diese Unterschiede keine Rolle. Alle Fremdschlüsselbeziehungen wurden mit einem Index versehen, wie dies beispielhaft in Abbildung X zu sehen ist. Wegen der, für ein Data Warehouse, geringen Datenumfangs, er scheint das Anlegen eines Bitmap-Index nicht notwendig. Das gleiche gilt für eine Parti tionierung oder gar Replikation des Datenbestandes. Als Beispiel für den MARKTANTEIL_SM seien hier die entsprechenden DDL-Anweisungen für die Oracle-Datenbank dargestellt. Eine Auflistung sämtlicher DDL-Anweisungen zur Er stellung des gesamten DHW ist im Anhang B zu finden. CREATE TABLE MARKTANTEIL_SM ( MODELL_ID NUMBER, ZEIT_ID NUMBER, SAUGMODUL_ID NUMBER, SM_VERKAEUFE NUMBER, ZULASSUNGSZAHLEN_D NUMBER, BEMERKUNG VARCHAR2(4000), ZEITSTEMPEL TIMESTAMP (6), CONSTRAINT MARKTANTEIL_SM_PK PRIMARY KEY (MODELL_ID, ZEIT_ID, SAUGMODUL_ID) ENABLE, CONSTRAINT MARKTANTEIL_SM_MO_FK FOREIGN KEY (MODELL_ID) REFERENCES MODELL (MODELL_ID) ENABLE, CONSTRAINT MARKTANTEIL_SM_ZT_FK FOREIGN KEY (ZEIT_ID) REFERENCES ZEIT (ZEIT_ID) ENABLE, CONSTRAINT MARKTANTEIL_SM_SM_FK FOREIGN KEY (SAUGMODUL_ID) REFERENCES SAUGMODUL (SAUGMODUL_ID) ENABLE ) / CREATE INDEX MARKTANTEIL_SM_IDX1 ON MARKTANTEIL_SM (MODELL_ID) / CREATE INDEX MARKTANTEIL_SM_IDX2 ON MARKTANTEIL_SM (ZEIT_ID) /

85 4 Projekt 77 CREATE INDEX MARKTANTEIL_SM_IDX3 ON MARKTANTEIL_SM (SAUGMODUL_ID) / CREATE UNIQUE INDEX MARKTANTEIL_SM_PK ON MARKTANTEIL_SM (MODELL_ID, ZEIT_ID, SAUGMODUL_ID) /

86

87 5 Implementierung 5.1 Software/Framework Die Auswahl der Software in Kapitel 4.8 fiel auf die Datenbank-Software von Oracle in Ver bindung mit der HTML DB-Option. Dieses Framework soll nun kurz vorgestellt werden. In der Vergangenheit gab es bisher zwei grundlegend verschiedene Herangehensweise bei der Entwicklung von Datenbanken und deren Anwendungen auf der Abteilungsebene einer Unter nehmung. Die Entwicklung von Einzelplatzdatenbanken, mit den Vorteilen einer schnellen und einfachen Entwicklung. Dies ist verbunden mit einer hohen Flexibilität und ermöglicht eine schnelle Erreichung von (akzeptablen) Ergebnissen. Daneben existieren zentrale Daten banken, deren Vorteile vor allem in der Integration von Sicherheitskonzepten, der Wahrung der Datenintegrität und den erweiterten Möglichkeiten der Skalierung und Verfügbarkeit liegen. Es musste also immer abgewogen werden, ob man eine schnelle und einfache Entwicklung haben wollte oder mehr Aufwand und damit auch mehr Zeit bzw. Geld in eine zentrale Lösung investierte. Der pragmatische Ansatz von Oracle HTML DB geht dahin, dass die Vorteile einer Einzel platzdatenbank mit denen einer zentralen Datenbank kombiniert werden [Beh04]. Die komplette Entwicklung und Verwaltung, sowie der Zugang zu den Anwendungen wird über einen Web-Browser ermöglicht. Selbst die Daten können über die HTML DB-Oberfläche innerhalb des Browsers in die Datenbank geladen werden und von Tabellenkakulationen (z.b. MS-Excel-Tabellen), von Desktop-Datenbanken (z.b. MS-Access) oder von Datei-Servern stammen. Die typische System-Architektur kann in zwei (2-tier) oder drei Schichten (3-tier) ausgeführt sein, je nach den Anforderungen an die Anwendungen und die Datenbank. Der HTTP-Server (Apache mit mod_plsql) und die HTML DB-Engine fungieren dabei als Ap plikations-server. Als Backend-Datenbank kann jede Oracle-Datenbank mit einer Version hö her als verwendet werden. Damit sind alle Vorteile einer solchen Datenbank, die be reits oben angesprochen wurden, auch für das HTML DB-Framework und deren Anwendungen verfügbar. Eine Unterstützung von mehreren Sprachen, sowohl bei der Entwicklung der Anwendungen, als auch bei dem Anwendungen selbst, ist möglich. Das HTML DB-Framework ist in drei Komponenten aufgeteilt: Der Application Builder (vgl. Abbildung 5.1) dient der Entwicklung und Verwaltung von erstellten Anwendungen. 79

88 Software/Framework Abbildung 5.1. HTML DB Application Builder Der SQL Workshop (vgl Abbildung 5.2) dient der Erzeugung und Verwaltung von Da tenbank-objekten. Hier werden z.b. die Tabellen, Sichten, Prozeduren, etc. erzeugt und verwaltet. Tools ermöglichen zudem die Erstellung von SQL-Abfragen ohne eine Kennt nis der SQL-Syntax. Abbildung 5.2. HTML DB SQL-Workshop

89 5 Implementierung 81 Die Administration (vgl Abbildung 5.3) dient der Verwaltung des Workspaces, der Benutzer und Entwickler und der Verwaltung des HTML DB-Dienstes. Abbildung 5.3. HTML DB Administration Die Abbildung 5.4 zeigt eine komplette Seitendefinition. Die Seiten bestehen dabei aus Re gionen mit ihren entsprechenden Elementen und Schaltfläche (Links), Berechnungen, Pro zessen und Verzweigungen (Mitte) und den Navigationselementen und Templates (Rechts). Abbildung 5.4. HTML DB - Seitendefinition

90 Software/Framework Zur Bearbeitung einer Region in einer Seite, die z.b. aus einer SQL-Abfrage bestehen kann, steht ein Eingabehilfe zur Verfügung, die in Abbildung 5.5 zu sehen ist. Abbildung 5.5. SQL-Eingabe für Region Mittels dieser Elemente lassen sie komplexe Anwendungen entwickeln. Zusätzlich wird eine multilinguale Entwicklung unterstützt. Zur Berichtserstellung stehen unterschiedliche Arten von Charts und Balkendiagrammen zur Verfügung. Eine Integration von bestehenden WebServices ist auch möglich. 5.2 Änderungen und Erweiterungen Alle Tabellen, deren Veränderungen zeitlich nachvollziehbar überwacht werden sollen, erhal ten einen Zeitstempel (Timestamp). Dies ist notwendig, da sonst eine Benachrichtigung der Benutzer über eine Veränderung schwierig wäre. Alternativ wäre eine Lösung mittels Trigger denkbar, indem bei jeder Änderung z.b. in einem Eingabeformular, automatisch eine Benach richtigung verschickt wird. Eine Funktionalität zur Sammlung solcher Benachrichtigungen ist sinnvoll, um die Anzahl der verschickten s so gering wie möglich zu halten. Aus praktischen Gründen wurden die Herstellerdaten aus der Tabelle MODELL herausge nommen und in eine eigenständige Tabelle (HERSTELLER) aufgenommen (vgl. Abbildung 5.6). Diese teilweise Normalisierung widerspricht zwar der Vorgehensweise beim Data Ware house-entwurf, stellt jedoch bezüglich der Auswertung keine wesentlichen Nachteile dar.

91 5 Implementierung 83 Im Laufe der Arbeit hat sich gezeigt, dass die Kardinalitäten einiger Beziehungen zu Beginn falsch eingeschätzt wurden. So kann z.b. ein Saugmodul mehrere Teilehersteller haben, wenn die unterschiedlichen Anbauteile (vgl. Kapitel 4.2) betrachtet werden. Zudem kann ein Fahr zeugmodell auch unterschiedliche Saugmodule bzw. Saugrohre haben, wenn z.b. ein PkwProduzent den Zulieferer wechselt. Diese n:m-beziehungen wurden durch die Hinzunahme von Bridge-Tables aufgelöst (TEILEHERSTELLER_SM, MODELL_SM und MODELL_SR), wie dies in Abbildung 5.6 zu sehen ist. MODELL MODELL_ID (PK) HERSTELLER_ID MODELLJAHR SOP EOP TEILEHERSTELLER BEZEICHNUNG AUFBAU TUEREN SITZPLAETZE BAUART_ZYLINDERAN EINBAULAGE HUBRAUM BOHRUNG_HUB VERDICHTUN... SAUGMODUL MODELL_SM MODELL_ID SAUGMODUL_ID SAUGROHR MODELL_SR HERSTELLER SAUGMODUL_ID SAUGROHR_ID BEZEICHNUNG ANALYSEBERICHT_ID BENCHMARKBERICHT_ID ZERLEGUNGSBERICHT_ID ABMASSE_L_B_H DVE KSZ TEV... MODELL_ID SAUGROHR_ID HERSTELLER_ID (PK) HERSTELLERNAME HERSTELLERADRESSE WWW_HERSTELLER IMPORTEUR WWW_IMPORTEUR SAUGROHR_ID BEZEICHNUNG TEILEHERSTELLER_ID BENCHMARKBERICHT_ID ANALYSEBERICHT_ID ZERLEGUNGSBERICHT_ID SAP_STUELI_LINK ANSCHRAUBKONZEPTE MATERIALART GEWICHT... (PK) TEILEHERSTELLER_SM SAUGMODUL_ID TEILEHERSTELLER_ID BEMERKUNG (PK) TEILEHERSTELLER TEILEHERSTELLER_ID NAME ADRESSE WWW_ADRESSE ANSPRECHPARTNER BEMERKUNGEN (PK) Abbildung 5.6 Teilweise Normalisierung von MODELL und Bridge-Tables 5.3 Besonderheiten Die Behandlung von zeitlichen Veränderungen in den Dimensionen, die auch als slowly changing dimensions bezeichnet werden, sind vor allem für die Tabelle bzw. Dimension MODELL interessant. Dort werden regelmäßig neue Modelle hinzugefügt, die sich teilweise von den alten Modellen unterscheiden. Wie eine Lösung aussehen könnte, wurde bereits in Kapitel anhand eines Beispiels dargelegt.

92 Besonderheiten Grundsätzlich soll hier der Typ 2 verwendet werden, d.h. eine Veränderung wird durch die Hinzunahme eines neues Tupels mit einem neuen künstlichen Schlüssel abgebildet. Zur Ver folgung der zeitlichen Veränderung innerhalb der Dimension, also die Möglichkeit zur Be stimmung für welches Modelljahr diese Veränderung stattgefunden hat, wird das Modelljahr um ein Jahr erhöht. Die oben dargestellte Vorgehensweise ist insbesondere auch in dem Fall zu durchlaufen, wenn die Veränderungen zwischen den Erscheinungsterminen des Auto Kata logs berücksichtigt werden sollen. Dies stellt einen praktikablen Ansatz dar, denn diese Ver änderungen würden spätestens im darauf folgenden Auto Katalog und damit auch mit dem folgenden Modelljahr erscheinen. Der Eintrag wird also in diesem Fall nur vorweggenommen. Die Abbildung 5.7 zeigt den gesamten ETL-Prozess, der zu durchlaufen ist. Dabei sind, wie bereits mehrfach erwähnt, viele Arbeitsschritte manuell zu erledigen. Eine externe Beschaf fung der Fahrzeugdaten würde diesen Prozess erheblich erleichtern und beschleunigen und zu dem die Qualität der Daten erhöhen. OCR-Prozess Nachbearbeitung Scanner Auto Katalog Kontrolle und Laden jedes einzelnen Datensatzes Zuordnung von Verknüpfungen Applikations-Server HTTPServer HTML DBEngine Extraktion (bulk load) Applikations-Server Data Warehouse HTTPServer HTML DBEngine Data Staging Area Oracle 9i/10g und HTML DB Abbildung 5.7 Arbeitsschritte und Datenfluss beim ETL-Prozess Eine weitere Problematik lässt sich bei der Erkennung von gleichen Modellen feststellen. So ist es selbst für die erfahrenen Mitarbeiter schwierig oder gar unmöglich, an Hand der Typbe zeichnung zu erkennen, welcher Motor verbaut wurde. Zudem hat sich gezeigt, dass selbst, bei sonst identischen technischen Daten, es vorkommen kann, dass der Motor eine andere Leistung hat. Es ist daher anzunehmen, dass in diesen Motoren unterschiedliche Komponenten verbaut sind, die sich nicht anhand der sonst üblichen Daten herauslesen lassen. Die Bestimmung von gleichen Motoren ist aber wichtig, um hierfür eine Zuordnung zu den entsprechenden Saugmodulen bzw. Saugrohren machen zu können.

93 5 Implementierung Datenstruktur Beispiel Die realisierte Datenstruktur (vgl. Abbildung 5.8) entspricht weitgehend der in Abbildung 4.22 gezeigten Darstellung. Hinzugekommen ist eine zusätzliche Tabelle MODELL_UPLOAD, die dem Arbeitsbereich (Data Staging Area) entspricht. Dort werden die neuen Daten der Modelle extrahiert und überprüft, um anschließend in das Data Ware house geladen zu werden. MODELL_SM MODELL_ID SAUGMODUL_ID MODELL_SR MODELL MODELL_ID (PK) HERSTELLER_ID MODELLJAHR SOP EOP TEILEHERSTELLER BEZEICHNUNG AUFBAU TUEREN SITZPLAETZE BAUART_ZYLINDERAN EINBAULAGE HUBRAUM BOHRUNG_HUB VERDICHTUN... HERSTELLER HERSTELLER_ID (PK) HERSTELLERNAME HERSTELLERADRESSE WWW_HERSTELLER IMPORTEUR WWW_IMPORTEUR ZEIT ZEIT_ID (PK) MONAT MONAT_BEZEICH QUARTAL JAHR MODELL_UPDLOAD MODELL_ID (PK) HERSTELLER_ID MODELLJAHR BEZEICHNUNG AUFBAU TUEREN SITZPLAETZE BAUART_ZYLINDERAN EINBAULAGE HUBRAUM BOHRUNG_HUB VERDICHTUN... TEILEHERSTELLER_SM MODELL_ID SAUGROHR_ID MARKTANTEIL_SR MODELL_ID SAUGROHR_ID ZEIT_ID SR_VERKAEUFE ZULASSUNGSZAHLEN_D BEMERKUNG SAUGMODUL_ID TEILEHERSTELLER_ID BEMERKUNG SAUGMODUL SAUGMODUL_ID SAUGROHR_ID BEZEICHNUNG ANALYSEBERICHT_ID BENCHMARKBERICHT_ID ZERLEGUNGSBERICHT_ID ABMASSE_L_B_H DVE KSZ TEV... (PK) TEILEHERSTELLER TEILEHERSTELLER_ID NAME ADRESSE WWW_ADRESSE ANSPRECHPARTNER BEMERKUNGEN (PK) ANALYSEBERICHT RFQ_BETEILIGUNG MODELL_ID ZEIT_ID SAUGROHR_ID SAUGMODUL_ID RB_ANGEBOT SOD RB_TP PROBLEM MODELL_ID ZEIT_ID SAUGROHR_ID SAUGMODUL_ID BESCHREIBUNG SAUGROHR SAUGROHR_ID BEZEICHNUNG TEILEHERSTELLER_ID BENCHMARKBERICHT_ID ANALYSEBERICHT_ID ZERLEGUNGSBERICHT_ID SAP_STUELI_LINK ANSCHRAUBKONZEPTE MATERIALART GEWICHT... ANALYSEBERICHT_ID BEZEICHNUNG TEXT (PK) (PK) BENCHMARKBERICHT BENCHMARKBERICHT_ID (PK) BEZEICHNUNG TEXT ZERLEGUNGSBERICHT ZERLEGUNGSBERICHT_ID BEZEICHNUNG TEXT (PK) MARKTANTEIL_SM MODELL_ID ZEIT_ID SAUGMODUL_ID SM_VERKAEUFE ZULASSUNGSZAHLEN_D BEMERKUNG RUECKRUFAKTION MODELL_ID ZEIT_ID SAUGROHR_ID SAUGMODUL_ID BESCHREIBUNG BILDER DOKUMENTE DOKUMENT_ID (PK) DOKUMENT_NAME FILENAME TITLE MIME_TYPE DOC_SIZE CREATED_ON DOKUMENT DESCRIPTION MODELL_ID SAUGMODUL_ID SAUGROHR_ID ANALYSEBERICHT_ID BENCHMARKBERICHT_ID ZERLEGUNGSBERICHT_ID IMAGE_ID (PK) IMAGE_NAME FILENAME TITLE MIME_TYPE DOC_SIZE CREATED_ON DATE IMAGE DESCRIPTION MODELL_ID SAUGMODUL_ID SAUGROHR_ID ANALYSEBERICHT_ID BENCHMARKBERICHT_ID ZERLEGUNGSBERICHT_ID THUMBNAIL Abbildung 5.8 Gesamtübersicht Data Warehouse

94 Umsetzung 5.5 Umsetzung Hier sollen einzelne beispielhafte Seiten der Anwendung als Screenshots zeigen, wie die Um setzung erfolgt ist. So zeigt z.b. die Abbildung 5.9 die Startseite der Anwendung, wie sie in einem Browser-Fenster dargestellt wird. Abbildung 5.9 Startseite der Anwendung Das Aussehen der Anwendung lässt sich durch die Auswahl eines anderen Templates teil weise vorkommen verändern. Wie so etwas aussehen kann zeigt die Abbildung 5.10.

95 5 Implementierung 87 Abbildung Gleiche Anwendung mit unterschiedlichen Templates Die Abbildung Abbildung 5.11 zeigt die Bearbeitung der Daten eines Bildes. Diese Daten können jederzeit verändert und das Bild kann sogar gelöscht werden, sofern die entspre chenden Rechte vorhanden sind.

96 Umsetzung Abbildung 5.11 Dateneingabe zu einem Bild Die Abbildung 5.12 zeigt den Vergleich von zwei Modellen die frei ausgewählt werden können. Die Anzahl der Vergleichskandidaten ist frei wählbar. So können diese jederzeit zur Liste hinzugefügt oder aus ihr entfernt werden. Abbildung 5.12 Vergleich zweier Modelle

97 5 Implementierung 89 Das Eingabe- bzw. Änderungsformular für ein Saugmodul ist in Abbildung 5.13 dargestellt. Neben der Eingabe der Daten werden hier auch eventuell vorhandene Verknüpfungen mit Modell und Teileherstellern angezeigt, die ebenfalls bearbeitet werden können. Abbildung 5.13 Eingabeformular für Saugmodule