Zentralisierte und modulare Business Intelligence Plattform und
Werbung
Zentralisierte und modulare Business Intelligence Plattform und Infrastruktur Master Thesis MT-11.01.01 Experte Betreuer: Autoren: Dr. A. Schmidhauser M. Schwab D. Massimi P. Brändle _____________________________________________________________________________ A. Vorwort Die vorliegende Master Thesis entstand als gemeinsames Werk durch Daniele Massimi und Pascal Brändle im Zeitraum vom 25. April bis 22. September 2011. Das Thema der Arbeit ergab sich aus einer immer wiederkehrenden Problematik bei der Schweizerischen Post und befasste sich mit der Entlastung der operativen Datenbanksysteme durch die Realisation eines unternehmensweiten Operational Data Store. Das Projekt wurde nach der Hermes Methode durchgeführt. Bei dieser Methode wird für jede einzelne Projektphase mindestens ein Dokument vorausgesetzt. Um die Anzahl der Dokumente auf eines zu reduzieren, wurden diese in einem zusammengefasst. Dadurch ergaben sich gewisse Redundanzen, die wir jedoch aus Gründen der Vollständigkeit im Dokument belassen haben. Wir danken Herrn Martin Schwab als Chefarchitekt Entwicklung bei IT Post und Herrn Dr. Arno Schmidhauser von der Berner Fachhochschule für die kompetente Betreuung und die Unterstützung während der Master Thesis. Zu guter Letzt bedanken wir uns bei unseren Familien und Freunden, die uns während dieser Zeit stets mit viel Geduld begleitet und motiviert haben. _____________________________________________________________________________ 2 _____________________________________________________________________________ B. Inhaltsverzeichnis 1 2 Dokumentaufbau........................................................................................................................6 Management Summary .............................................................................................................7 2.1 Ausgangslage .....................................................................................................................7 2.2 Lösungsansätze und Ergebnis ...........................................................................................7 2.3 Beurteilung und Ausblick ....................................................................................................8 3 Einleitung .................................................................................................................................10 4 Problemstellung .......................................................................................................................11 5 Voranalyse ...............................................................................................................................12 5.1 Interviews ..........................................................................................................................12 5.2 Anforderungen ..................................................................................................................12 5.3 Überprüfung BI Positionierung Post .................................................................................13 5.4 Definition Use Cases Business ........................................................................................17 5.5 Pflichtenheft ......................................................................................................................24 5.6 Ausgangslage ...................................................................................................................24 5.7 Ist-Zustand ........................................................................................................................24 5.8 Ziel ....................................................................................................................................25 5.9 Anforderungen ..................................................................................................................26 5.10 Kriterienkatalog .................................................................................................................28 5.11 Voranalysebericht .............................................................................................................31 6 Konzept ....................................................................................................................................35 6.1 Einleitung ..........................................................................................................................35 6.2 Problematik bei der Schweizerischen Post ......................................................................35 6.3 Daten.................................................................................................................................36 6.4 Begriffsdefinitionen und Technologien .............................................................................38 6.5 Zentralisierung vs. Dezentralisierung ...............................................................................50 6.6 Definition Module „Zentralisierte und modulare BI Plattform und Infrastruktur“ ...............52 6.7 Referenzarchitektur...........................................................................................................55 6.8 Lösungsvarianten / mögliche Architekturen ....................................................................56 6.9 Gegenüberstellung der Lösungsvarianten zu den Muss und Kann Kriterien...................62 6.10 Definition Ziel Architektur „Zentralisierte und modulare ...................................................65 Business Intelligence Infrastruktur und Plattform“ .......................................................................65 6.11 Verfügbarkeit der BI Plattform ..........................................................................................85 6.12 Wiederverwendbarkeit der Daten .....................................................................................85 6.13 Cleanup Daten ..................................................................................................................87 6.14 Sicherheit ..........................................................................................................................87 6.15 Prozesse ...........................................................................................................................96 6.16 Umgang mit Berechtigungen ..........................................................................................101 6.17 Richtlinien und Konvention für ODS Datenbankobjekte.................................................102 6.18 Allgemein gültige Namenskonventionen ........................................................................102 6.19 Konzeptbericht ................................................................................................................108 7 Realisierung ...........................................................................................................................110 7.1 Einleitung PoC ................................................................................................................110 7.2 Aufbau PoC Plattform .....................................................................................................110 7.3 Durchführung PoC ..........................................................................................................114 7.4 Betriebskonzept ..............................................................................................................120 8 Einführung ..............................................................................................................................127 8.1 Supportprozesse .............................................................................................................127 8.2 Weiteres Vorgehen bei operativer Umsetzung...............................................................128 8.3 Interview zur Lösung .......................................................................................................129 9 Projektabschlussbericht .........................................................................................................131 9.1 Allgemeines ....................................................................................................................131 10 Anhang ...................................................................................................................................134 _____________________________________________________________________________ 3 _____________________________________________________________________________ C. Akronyme ABS ASM BI BO CAS CDC CRM DCL DDL DML DWH ELT ERD ES ESB ETL Fat Client Grid Control GUI HERMES HPOVO I/O IBS IDS IPS IT JDBC LOB LUN MOLAP MS SQL Server MySQL NIC ODBC ODS OLAP OLTP Oracle OS P-MAN PostgreSQL RDBMS Repository ROLAP ROI RPO RTO Ausserbetriebsetzung Automatic Storage Management (Oracle Disk Volume Manager) Business Intelligence Business Objects (SAP Tool) Certificate of Advanced Studies Change Data Capture Customer Relationship Management Data Care Luzern AG (Tochtergesellschaft der Post) Data Definition Language (Strukturverändernde Befehle in der Datenbank) Data Manipulation Language (Insert, Update und Delete in der Datenbank) Data Warehouse Extract Load Transformation (Data Integration Technik) Entity Relationship Diagramm Enterprise Service Enterprise Service Bus Extract Transformation Load (Data Integration Technik) Client Software mit integrierten logischen Funktionen Zentralisierte Datenbanküberwachung und Administration Graphical User Interface Projektführungsmethode Hewlett Packard Openview Operations Center Input / Output Inbetriebsetzung Intrusion Detection System Intrusion Prevention System Informationstechnologie Java Database Connectivity Large Object (Objekte in der Datenbank, z.B.: BLOB Binary Large Object) Logical Unit Number Multidimensional Online Analytical Processing RDBMS Softwarelieferant RDBMS Softwarelieferant Network Interface Card Open Database Connectivity Operational Data Store Online Analytical Processing Online Transactional Processing RDBMS Software, Application Server und Applikationslieferant Operating System Post Metropolitan Area Network RDBMS Softwarelieferant Relational Database Management System Speicherort für Metadaten Relational Online Analytical Processing Return of Investment Recovery Point Objective Recovery Time Objective _____________________________________________________________________________ 4 _____________________________________________________________________________ SAN SAP SAP BW SLA SLES SOA SOAP SQL SQL*Net SuSE UC UHD Use Case VLDB ZDH ZDS Storage Area Network Softwarelieferant SAP Business Warehouse Service Level Agreement SuSE Linux Enterprise (Enterprise Distribution von SuSE) Service Oriented Architecture Simple Object Access Protocol Structured Query Language Oracle Network Adapter Vertreiber von Linux Distribution Use Case User Help Desk Anwendungsfall Very Large Database Zentrale Datenhaltung (SAN Storage der IT Post) Zentrale Datensicherung (Backup Infrastruktur der IT Post) D. Quellen Gartner Inc.: Verschiedene publizierte Artikel Forrester Research Inc.: Verschiedene publizierte Artikel A. Bauer / H. Günzel: [2009] Data Warehouse System R. Kimball / M. Ross: [2008] The Data Warehouse Lifecycle Toolkit W. Inmon: [2005] Building the Data Warehouse W. Inmon: [2007] DW 2.0 W. Inmon: [1995] Building the Operational Data Store _____________________________________________________________________________ 5 _____________________________________________________________________________ 1 Dokumentaufbau Dieses Kapitel soll helfen einen groben Überblick, über die Themen in den verschiedenen Projektphasen zu erhalten. Allgemein Management Summary Einleitung Problemstellung Voranalyse Erhebung der Anforderungen (Interviews, Dokumentenstudium) Überprüfung BI Positionierung bei IT Post Definition Use Cases aus Business Sicht Erstellung Pflichtenheft Erstellung Kriterienkatalog Konzept Erläutern der Problematik Moduldefinitionen Begriffsdefinitionen und Technologien Erarbeitete Lösungsvarianten Wahl der Lösungsvariante Definition der BI Plattform und Infrastruktur Berechtigungskonzept Prozesse Namenskonventionen Realisierung Vorgehen beim PoC Aufbau der PoC Umgebung Betriebskonzept Einführung Supportprozesse Weiteres Vorgehen _____________________________________________________________________________ 6 _____________________________________________________________________________ 2 Management Summary Die wesentlichen Aussagen über die Master Thesis „Zentralisierte und modulare Business Intelligence Infrastruktur und Plattform“ werden im Folgenden kurz zusammengefasst. 2.1 Ausgangslage Oft sind die operativen Datenbanken überlastet. Betroffene Benutzer beklagen sich über lange Bearbeitungs- und schlechte Antwortzeiten. Verarbeitungen können nicht immer fristgerecht fertig gestellt werden, was zu Problemen bei nachgelagerten Systemen führt. Resultate von Analysen können variieren, weil durch mehrfache Replikationen von einem System auf das andere der „Single Point of Truth“ nicht mehr feststellbar ist. Zusätzlich wächst auch das Bedürfnis nach sogenannt zeitnahen bzw. „real time“ Daten für Business Analysen immer mehr. Dies sind nur einige der Probleme, mit denen die Bereiche zu kämpfen haben. In einer ersten Analyse konnten folgende Ursachen identifiziert werden: Die Auswertungen oder Analysen der Daten werden direkt auf den operativen Datenbanken ausgeführt. Das Replizieren der Daten auf Umsysteme verursacht unnötige Redundanzen und Last. Zeitliche Abhängigkeiten in Verarbeitungsprozessen können nicht mehr garantiert werden. Reports, Aggregationen und Datenkonsolidierungen auf den operativen Systemen beeinflussen die Performance negativ. Es gibt kein allgemeines Konzept für die Datenintegration. Es fehlt eine einheitliche Infrastruktur, welche die Bereichsdaten zentral zur Verfügung stellt. Nicht abgestimmte Datenstrukturen führen oft zu hohen Laufzeiten (normalisiert vs. denormalisiert). Bislang wurde versucht, solche Probleme durch den Einsatz von dedizierten Auswertungssystemen zu entschärfen, welche mit Replikaten versehen wurden. Dies führte jeweils zu Mehrkosten und zu sogenannten Insellösungen. Um diese Probleme nachhaltig zu beheben, soll eine neue zentrale und modulare Plattform aufgebaut werden. 2.2 Lösungsansätze und Ergebnis Das Ziel ist daher eine Plattform, welche die operativen Systeme entlastet, indem die Daten den Consumer-Systemen zur Verfügung gestellt werden. Je nach Bedarf können die Daten in aufbereiteter Form zur Verfügung gestellt werden um Reports und Verarbeitungen performanter durchzuführen. Ein Anbinden an bestehende DWHs sollte ebenfalls möglich sein. Um den Bedürfnisträgern gerecht zu werden, wurden die Bedürfnisse mittels Interviews erhoben. Danach wurden aus diesen Erkenntnissen die entsprechenden Anforderungen abgeleitet, welche ein IT System zu erfüllen hat. Es wurde diesbezüglich ein Kriterienkatalog mit erhöhter Granularität erstellt, welcher zur besseren Beurteilung in Gruppen aufgeteilt wurde. _____________________________________________________________________________ 7 _____________________________________________________________________________ In einem nächsten Schritt wurden verschiedene Lösungsvarianten unter Berücksichtigung der Einhaltung der Anforderungen erarbeitet. Die endgültige Lösung entstand aufgrund von technischen und strategischen Gegebenheiten. Zum einen wurde die Architektur auf die technische Machbarkeit geprüft und zum anderen wurde bei der Produktwahl auf die strategische Produktpalette bei der Schweizerischen Post geachtet. Die Lösung wurde ausserdem so konzipiert, dass diese skalierbar ist. Dadurch ist es möglich mit einer kleiner angelegten Infrastruktur zu beginnen und diese dann mittels Cluster Technologie zu erweitern. Dank dieser Architektur sind Anfangs keine hohen Investitionen nötig. Dies führt dazu, dass die Kosten für die Kunden tief gehalten werden können, was in der heutigen Zeit ein wichtiger Entscheidungsfaktor ist. In diesem Projekt wurden lediglich die Lizenzkosten und allfällige Investitionen berücksichtigt. Für die operative Wirtschaftlichkeit muss noch eine detaillierte Berechnung gemacht werden. Diese muss aufzeigen, welche Kosten anfallen dürfen, um die operativen Systeme zu entlasten. Für diese Entlastung werden heute zusätzlich dedizierte Systeme aufgebaut. Mit der neuen Lösung könnte eine kostengünstigere gemeinsame Plattform zur Verfügung gestellt werden, weshalb diese Kosten kein Hindernis darstellen sollten. 2.3 Beurteilung und Ausblick Mit dieser Arbeit soll aufgezeigt werden, wie die bereits beschriebenen Probleme durch eine zentrale und modulare Plattform entschärft werden können. Dabei wurde der Fokus stets auf folgende Punkte gerichtet: Entlastung der Operativen Systemen Vereinheitlichung von Datenintegration Aufbau einer zentralen Plattform als Basis für ein unternehmensweites Data Warehouse Mit der „Zentralen und modularen BI Plattform und Infrastruktur“ können die aktuellen Probleme behoben werden. Als Konsequenz müssen keine zusätzlichen Auswertungssysteme mehr beschafft und betrieben werden. Dies führt zu Kostensenkungen bei einer gleichzeitigen Erhöhung der Effizienz der Systeme. Ein weiterer Vorteil besteht in der Eliminierung von redundanten Daten. Dies spart Speicherplatz und reduziert die Kosten für die Nutzung der teuren Speichersysteme und deren speziellen Netzwerktechnologien (SAN). Durch diese Massnahme können die Daten anderen Bereichen zentral zur Verfügung gestellt, womit man auch wieder einen Single Point of Truth hat. Zudem kann durch die Entlastung der operativen Systeme, die auf Online Transaktionen ausgerichtet sind, mit einer gesteigerten Performance gerechnet werden, was sich auch in kürzeren Antwortzeiten bemerkbar machen würde. Ein weiterer Aspekt ist, dass durch den Einsatz eines Operational Data Store, die Vorstufe eines Data Warehouse entsteht. Eine Wiederverwendbarkeit der Daten wäre somit unternehmensweit gewährleistet. Dadurch wird der Aufwand für das Sammeln der Daten auf verschiedenen Systemen stark reduziert. _____________________________________________________________________________ 8 _____________________________________________________________________________ Wie bereits erwähnt entstand die Lösung aufgrund der Anforderungen, die bei den Kunden erhoben wurden. Mittels einem Proof of Concept, welches aus einem Kundenprojekt abgeleitet wurde, konnte die Lösung zudem validiert und verifiziert werden. Damit diese Arbeit über den Status eines Proof of Concept hinweg kommt, müssen verschiedene Punkte angegangen werden. Als erstes muss eine Wirtschaftlichkeitsrechnung erstellt werden, um die nötigen Investitionen auszulösen. Anschliessend müssten noch folgenden Schritte eingeleitet werden: Vernehmlassung des Konzeptes durch das Management Schulung der betroffenen Mitarbeiter Eingliedern der Plattform in der Organisation Betreiben von Marketing Aufbau des IT Services „Zentralisierte und modulare Business Intelligence Infrastruktur und Plattform“ Bestimmen eines Serviceverantwortlichen _____________________________________________________________________________ 9 _____________________________________________________________________________ 3 Einleitung Die Schweizerische Post befördert jährlich ca. 121 Millionen Menschen mit dem Postauto. Täglich stellt sie rund 15 Millionen Briefsendungen und 100 Millionen Pakete pro Jahr zu. Zudem wickelt die Postfinance 894 Millionen Zahlungsverkehrstransaktionen pro Jahr ab. Diese und andere Leistungen werden durch eine umfassende IT Infrastruktur unterstützt und ermöglicht. Der Servicebereich IT Services der Schweizerischen Post betreibt hierzu fast 2000 Datenbanken von verschiedenen Datenbankanbietern (z.B. Oracle Datenbankmanagement System der Firma Oracle, MS SQL Server der Firma Microsoft, die Open Source Systeme MySql und PostgreSQL) mit unterschiedlichen Datenbanktechnologien. Neben der operativen Nutzung werden diese Datenbanken auch für Analysen und Auswertungen sowie zur Bereitstellung von Services im Sinne einer Service orientierten Anwendungsinfrastruktur (SOA) verwendet. Die Replikation der Daten erfolgt mittels verschiedener Technologien wie z.B. Snapshots, Replikation, Export / Import, Flatfiles, u.v.a. In der Regel werden die Analysen direkt auf den operativen Systemen ausgeführt. Dadurch kann es zu Störungen in den operativen Systemen kommen, so dass gelegentlich nicht alle „online“ Anfragen bewältigt werden können. In der Analyse dieser Daten erkennt man ein Business Intelligence Muster. Gestützt darauf möchten wir mit diesem Unterfangen eine zentralisierte und modulare BI Plattform realisieren, die auch als Datenquelle für „read only ES“ dienen kann. Im CAS BI01 haben wir uns bereits im Rahmen einer Semesterarbeit mit der Thematik Replikation und Real Time Replikation auseinander gesetzt und so das notwendige Know-How erarbeitet. In dieser Abhandlung werden die Replikationsmechanismen deshalb nicht mehr im Detail erörtert und behandelt. _____________________________________________________________________________ 10 _____________________________________________________________________________ 4 Problemstellung Wie bereits erwähnt, greifen die einzelnen Bereiche der Schweizerischen Post bei einem Analysebedarf mehrheitlich auf die operativen Datenbanken zu, um Auswertungen oder Aggregate zu erstellen. Dabei werden folgende Probleme ersichtlich: Die Daten werden vermehrt von den operativen Datenbanken abgeholt, was zu Betriebsstörungen führen kann. Diese Situation hat sich mit SOA akzentuiert. Die Daten werden vermehrt auf andere Umsysteme repliziert, auf welchen danach die Analysen der Daten durchgeführt werden. Die Resultate der Analysen können je nach Umsystem variieren (kein Single Point of Truth). Die Daten müssen bis zu einem bestimmten Zeitpunkt (z.B. 06:00 Uhr) garantiert auf einem Umsystem verfügbar sein, damit das Umsystem korrekt funktionieren kann. Die Daten werden erst zur Laufzeit auf dem operativen System konsolidiert und aggregiert, was die Performance der operativen Systeme negativ beeinflusst. Die Reports werden direkt auf operativen Systemen ausgeführt, was sich ebenfalls negativ auf die Performance auswirkt. Die Bereiche benötigen immer häufiger zeitnahe Daten (real time) für Auswertungen. Dies führt vermehrt dazu, dass Reports direkt auf operativen Systemen ausgeführt werden. Es gibt kein allgemein gültiges Konzept für die Integration der Daten. Es gibt keine Infrastruktur, die Bereichsdaten zentral zur Verfügung stellt. Nicht abgestimmte Datenstrukturen führen zu hohen Laufzeiten (normalisiert vs. denormalisiert). _____________________________________________________________________________ 11 _____________________________________________________________________________ 5 Voranalyse Im folgendem Kapitel werden sämtliche Schritte dokumentiert, die bei einer Voranalyse nach der HERMES Methode notwendig sind. Im Vordergrund steht das Analysieren und Erheben von Business- sowie System Requirements. Dabei werden bestehende Probleme, Prozesse und eingesetzte Tools genauer betrachtet. Hauptaugenmerk bei der Lösungssuche liegt auf folgenden Punkten: 5.1 Entlastung der operativen Systeme Erweiterung durch Anpassungen am Datenmodell Kosten Skalierbarkeit Benutzbarkeit Wartbarkeit Interviews Um den Anforderungen der Kunden gerecht zu werden, benötigen wir ein genaues Bild ihrer Problematiken im Bereich Business Intelligence. Durch die Führung von Interviews haben wir uns einen Überblick über die aktuelle Situation der Kundenseite verschafft. Dabei galt es nicht nur das Vorhandene zu überprüfen, sondern auch einen Einblick in die offenen Kundenbedürfnisse zu bekommen. Aus prozesstechnischen Gründen war es nicht möglich den direkten Kundenkontakt zu suchen, weshalb wir die Interviews mit Personen durchgeführt haben, die durch ihre Funktion bei der Schweizerischen Post enge Beziehungen zu den Kunden pflegen. Die von uns gewählten Interviewpartner haben sowohl die Kundensicht, als auch ihre Sicht als Verantwortliche in ihrem Bereich vertreten. Die Interviews wurden so gestaltet, dass Fragen zu Business- sowie System Requirements abgedeckt waren. Aus diesen Erkenntnissen haben wir die Anforderungen abgeleitet und ins Pflichtenheft übertragen. [siehe Kapitel 5.5 und Anhang der einzelnen Interviews] 5.2 Anforderungen Im folgenden Kapitel werden die Anforderungen beschrieben. Hierbei unterteilen wir diese in Business- und in Systemanforderungen. Diese Unterteilung dient der besseren Nachvollziehbarkeit in den späteren Projektphasen. Der Schwerpunkt liegt auf der Problemlösung im Bereich Business Intelligence sowie Data Integration. _____________________________________________________________________________ 12 _____________________________________________________________________________ 5.2.1 Business Anforderungen Um für die Bereiche und deren Fachgebiete eine zugeschnittene Lösung zu erarbeiten, die einen signifikanten Mehrwert bringt, ist es wichtig die Tätigkeiten und die Schwerpunkte der Fachgebiete zu kennen. Die wichtigsten Faktoren in Bezug auf die benötigten Informationen sind: 5.2.2 Aktualität der Daten Quellsysteme und Zielsysteme kennen Art der Reports Anzahl der Reports Kadenz und Zeitkritikalität eines Datentransfers Prozesse Datenvolumen Zielpublikum Anzahl User Technische Anforderungen Bei den technischen Anforderungen werden die relevanten Aspekte eines Systems definiert, die zur Abdeckung der Business Anforderungen notwendig sind. Dies umfasst folgende Hauptpunkte: 5.3 Berücksichtigen der aktuellen und zukünftigen Systemlandschaft und der Umsysteme Einsatz der bestehenden Tools Einsatz der bestehenden Technologien Einsatz der bestehenden Datenbank Technologien Anzahl Benutzer (concurrent) Skalierbarkeit des heutigen sowie zukünftigen Systems Recovery Time Objective (RTO) Recovery Point Objective (RPO) Lastspitzen und Lastverteilung Richtlinien und Standardisierung Überprüfung BI Positionierung Post Bei der Schweizerischen Post ist die IT Infrastruktur grundsätzlich zentral organisiert. Diese lässt sich in zwei Hauptbereiche unterteilen, namentlich Postfinance und IT Post. Der Hauptunterschied zwischen den Bereichen liegt darin, dass die Postfinance sich um ihre eigenen Systeme kümmert, die IT Post hingegen für die Basisinfrastruktur und die Systeme der anderen Postbereiche verantwortlich ist. Die obengenannte Gegebenheit ist von enormer Wichtigkeit, um die Heterogenität der Geschäftsfelder zu verstehen. Diese Problematik spiegelt sich in allen IT Projekten - so auch im Bereich Business Intelligence - wider. _____________________________________________________________________________ 13 _____________________________________________________________________________ Im Folgenden soll die Business Intelligence Situation im Bereich IT Post und ihrer Kunden näher erläutert werden. Vor einigen Jahren wurden bei der IT Post verschiedene Konzepte und Arbeitspapiere erstellt, welche die Thematik Business Intelligence beschreiben. Folgendes Arbeitspapier ist derzeit gültig: Titel BI Positionierung IT Dokument BK_BI_Positionierung_IT_V0102.pdf Author Andreas Mannhart Im Dokument BI Positionierung IT werden folgende Themen behandelt: Architektur BI Technologie Produktportfolio Organisation und Aufgaben Der Zweck des Dokumentes ist die verbindliche Vorgabe für die Realisierung neuer BI Projekte sowie der Förderung des technischen Verständnisses von Mitarbeitern, die Kundenofferten erstellen. Es beinhaltet eine grobe Referenzarchitektur, die sich stark an den Vorschlag von A. Bauer / H. Günzel anlehnt und als exemplarisches Beispiel dient. Die Einsatzmöglichkeit der Referenzarchitektur ist jedoch von Fall zu Fall zu verifizieren. Danach wird eine Vielzahl von Business Intelligence Komponenten und derer Einsatzgebiete beschrieben. Bei einigen wird auch eine Empfehlung zu ihrer Verwendung abgegeben. Ein weiteres Kapitel behandelt die Organisation sowie Aufgaben, Kompetenzen und Verantwortlichkeiten der Rolle Facharchitekt Business Intelligence. Zudem weist das Dokument ein Produktportfolio mit den strategischen Produkten der Schweizerischen Post auf. Zum heutigen Zeitpunkt erscheint eine Überprüfung der strategischen Produkte sinnvoll, da aufgrund veränderter Gegebenheiten die Auswahl neu zu definieren ist. Nachfolgende Liste ist folgendermassen zu interpretieren: Das Dokument entstand im Jahre 2009. Seinerzeit wurden seitens IT Post die Softwareprodukte der Firmen Microsoft und SAP als Ökosystem definiert. Die zweite Spalte bildet somit den Zustand aus dem Jahre 2009 und die dritte Spalte die Zukunft. Seit einigen Monaten wird diese Strategie nicht mehr absolut verfolgt. Stellen sich andere Produkte als geeigneter heraus, werden diese obwohl sie nicht in der Produktliste geführt werden, trotzdem eingesetzt. _____________________________________________________________________________ 14 _____________________________________________________________________________ Produktliste aus dem Dokument BI Positionierung IT: BI-Bereich aktuelle Situation heute bei IT eingesetzt Reporting und Analyse OLAP Analysen Statistik, Prognose und Data Mining MS SQL Server Reporting Services MS SQL Server Analysis Services Business Objects ZEWAS (Jasper Reports) SAP BW BEx Oracle Reports Sollsituation gemäss Kontinuitätsplanung ( bis 3 Jahre) MS SQL Server Reporting Services MS SQL Server Analysis Services SAP Business Objects (WebIntelligence, Crystal Reports, Voyager Pioneer) ZEWAS (Jasper Reports) * SAP Business Explorer (BEx) Web und Excel Analyzer Pioneer SAP Business Objects Explorer MS SQL Server Analysis Services SAP BW IBM SPSS / Clementine Planung und Budgetierung SAP SEM / BPS SAP BI / IP MIS/Dashboard und Scorecard Microsoft Office Dashboard BusinessObjects Xcelsius Arcplan Enterprise SAP SEM SAP Visual Composer BusinessObjects Extraktion, Transformation und Laden PL/SQL MS SQL Server Integration Services BusinessObjects DataIntegrator SAP Extraktor Plug-in Informatica PowerCenter MS SQL Server Analysis Services SAP Business Objects (Voyager Pioneer) SAP Business Explorer Web und Excel Analyzer Pioneer IBM SPSS / Clementine SAP Business Objects Predictive Analytics MS SQL Server Data Mining SAP Netweaver Business Warehouse / Integrated Planning SAP BO Business Planning and Consolidation SAP Business Objects (Crystal Xcelsius, Dashboard Builder, BI Widgets) SAP Strategic Enterprise Management SAP BO Strategy Management SAP Netweaver Visual Composer (VC) (bei Composite Applications) MS SharePoint Server Informatica PowerCenter (*) SAP Business Objects Data Services SAP Business Warehouse Extraktor Plug-in MS SQL Server Integration Services _____________________________________________________________________________ 15 _____________________________________________________________________________ Datenqualitätsmanagement Fuzzy (Adressen DCL) Metadatenmanagem ent SAP BO Meta Data Manager SAP BW SAP Business Objects Data Quality Premium SAP Netweaver Masterdatamanagement (MDM) Stammdatendrehscheibe SAP Business Objects Meta Data Manager (BOMM) SAP Business Warehouse (BW) Legende: * nicht strategisch, keine neuen Lösungen (*) wenn Ökosystem nicht geeignet (Eignung wird im Einzelfall geprüft) 5.3.1 Fazit Zusammenfassend ist das Dokument „BI Positionierung IT“ eher als ein Leitfaden über Business Intelligence Komponenten anzusehen. Zudem beinhaltet es ein Architekturbeispiel, wie ein DWH aussehen könnte. Im Dokument, wird zu wenig konkret auf die Umsetzung von BI resp. DWH Einsatzbereiche eingegangen. Auf der Intranetseite des BI Teams (das sich hauptsächlich mit BO befasst) wird jedoch Unterstützung und Beratung bei DWH Projekten angeboten. Zum heutigen Zeitpunkt sind keine Prozesse im Business Intelligence Bereich bekannt. Es gibt auch keine nennenswerten „Best Practices“, bereichsübergreifende Namenskonventionen oder Datenintegrations- oder Transformationsrichtlinien. Der Schwerpunkt des Dokumentes liegt auf einer detaillierten Produktpalette mit der heutigen sowie zukünftigen strategischen Ausrichtung. Eine Beschreibung der Produkte, sowie deren Einsatzbereichen und Integration fehlt gänzlich. Bei IT Projekten kann dies aber zu Mini-Evaluationen und zu „Insel-Lösungen“ führen. Vermehrte Einzellfall-Lösungen erschweren schlussendlich den Betrieb, da die Vielzahl der Produkte ein erhöhtes Know-How erfordert. 5.3.2 Empfehlung Ein solches Dokument sollte weniger eine Auflistung von verschiedenen Produkten enthalten, sondern vielmehr den „Weg zum Ziel“ beschreiben. Aus unserer Sicht sollten folgende Thematiken eingehender behandelt werden: Standardisierte Prozesse und derer Aktivitäten die zu einem DWH führen Standardisierte Plattformen Tools Definitionen: wann ist welches Tool einzusetzen Mit diesen grundlegenden Informationen könnten BI Projekte dynamischer und effizienter durchgeführt werden. Insbesondere müsste das Know-How über die verschiedenen Produkte nicht immer wieder zusätzlich aufgebaut werden. _____________________________________________________________________________ 16 _____________________________________________________________________________ 5.4 Definition Use Cases Business Im Folgenden wird ein Use Case Modell vorgestellt und Typologien von Use Cases behandelt. Aus den Interviews wurden verschiedene Anforderungen erhoben und festgestellt, dass verschiedene Kunden ähnliche Anforderungen an die Systeme stellen. Abbildung 5.1: Use Case Modell Business _____________________________________________________________________________ 17 _____________________________________________________________________________ 5.4.1 Use Case Beschreibung In diesem Kapitel werden die Use Cases des Use Case Modells beschrieben. 5.4.1.1 Use Case 1 „Standardauswertung ausführen“ Name des Use Case Standardauswertung ausführen Kurzbeschreibung Starten von vordefinierten Auswertungen Auslöser / Motivation Der Benutzer möchte eine Standardauswertung ausführen, die eigens für seine Bedürfnisse entwickelt worden ist. Ergebnis Die Standard Auswertung wird ausgeführt. Akteure BI End User Eingehende Information Vordefinierte Parameter Vorbedingungen Verbindung mit Auswertungstool erstellt Nachbedingungen - Essenzielle Schritte - 5.4.1.2 Use Case 2 „OLAP Auswertung ausführen“ Name des Use Case OLAP Auswertung ausführen Kurzbeschreibung Starten von OLAP Auswertung mit OLAP Tool. OLAP Tool erlaubt mittels ROLAP oder MOLAP Abfragen für Analyse Zwecken. Auslöser / Motivation Der Benutzer möchte eine OLAP Auswertung ausführen. Ergebnis Die OLAP Auswertung wird ausgeführt. Akteure BI End User Eingehende Information Benutzerspezifische Parameter Vorbedingungen Verbindung mit OLAP Tool erstellt Nachbedingungen - Essenzielle Schritte - _____________________________________________________________________________ 18 _____________________________________________________________________________ 5.4.1.3 Use Case 3 „Ad Hoc Auswertung ausführen“ Name des Use Case Ad Hoc Auswertung ausführen Kurzbeschreibung Starten von Ad Hoc Auswertung mit Auswertungstool Auslöser / Motivation Der Benutzer möchte eine Ad Hoc Auswertung mittels einem frei wählbaren Reportingtool ausführen. Ergebnis Die Ad Hoc Auswertung wird ausgeführt. Akteure BI End User Eingehende Information Benutzerspezifische Parameter Vorbedingungen Verbindung mit Auswertungstool ist erstellt Nachbedingungen - Essenzielle Schritte - 5.4.1.4 Use Case 4 „Data Mart Auswertung ausführen“ Name des Use Case Data Mart Auswertung ausführen Kurzbeschreibung Starten von Data Mart Auswertung mit Auswertungstool Auslöser / Motivation Der Benutzer möchte eine Data Mart Auswertung, die speziell für seine Bedürfnisse entwickelt worden ist. Ergebnis Die Data Mart Auswertung wird ausgeführt. Akteure BI End User Eingehende Information Vordefinierte Parameter Vorbedingungen Verbindung mit Auswertungstool ist erstellt Nachbedingungen - Essenzielle Schritte - _____________________________________________________________________________ 19 _____________________________________________________________________________ 5.4.1.5 Use Case 5 „Daten einfügen“ Name des Use Case Daten einfügen Kurzbeschreibung Der Benutzer möchte mit einem definierten Tool Daten einfügen. Auslöser / Motivation Der Benutzer möchten aus Business Gründen Daten einfügen. Dies um die Daten zu aktualisieren oder weil die geforderte Datenqualität nicht erfüllt wird. Ergebnis Daten werden eingefügt Akteure BI End User und BI Plattform Administrator Eingehende Information Vordefinierte Parameter Vorbedingungen Verbindung mit ETL Tool oder anderem Tool erstellt Nachbedingungen ETL Ladeprozesse wurde initiiert Essenzielle Schritte - 5.4.1.6 Use Case 6 „Daten mutieren (Update)“ Name des Use Case Daten mutieren (Update) Kurzbeschreibung Der Benutzer möchte mit einem definierten Tool Daten mutieren. Auslöser / Motivation Der Benutzer möchten Daten mutieren (updaten). Ergebnis Daten wurden mutiert Akteure BI Plattform Administrator und Developer Eingehende Information Vordefinierte Parameter Vorbedingungen Verbindung mit ETL Tool oder anderem Tool erstellt Nachbedingungen ETL Mutationsprozesse wurden initiiert Essenzielle Schritte - _____________________________________________________________________________ 20 _____________________________________________________________________________ 5.4.1.7 Use Case 7 „Daten löschen“ Name des Use Case Daten löschen Kurzbeschreibung Der Benutzer möchte mit einem definierten Tool Daten löschen. Auslöser / Motivation Der Benutzer möchte Daten löschen. Da es aus Business Gründen keinen Sinn mehr ergibt die Daten länger als nötig auf zu bewahren, werden alte Daten gelöscht. Ergebnis Daten wurden gelöscht Akteure BI Plattform Administrator und Developer Eingehende Information Vordefinierte Parameter Vorbedingungen Verbindung mit ETL Tool oder anderem Tool erstellt Nachbedingungen ETL Löschprozesse wurden initiiert Essenzielle Schritte - 5.4.1.8 Use Case 8 „Ladeprozeduren anstossen“ Name des Use Case Lade Prozeduren anstossen Kurzbeschreibung Der Benutzer möchte eine spezifische Ladeprozedur anstossen. Auslöser / Motivation Der Benutzer benötigt neue Daten. Daher soll er diese Schnittstelle selber bedienen können. Ergebnis Ladeprozeduren konnten gestartet werden Akteure BI End User, BI Plattform Administrator und Developer Eingehende Information Vordefinierte Parameter Vorbedingungen Verbindung mit ETL Tool oder anderem Tool erstellt Nachbedingungen ETL Ladeprozesse wurde initiiert Essenzielle Schritte - _____________________________________________________________________________ 21 _____________________________________________________________________________ 5.4.1.9 Use Case 9 „Daten Provider anbinden“ Name des Use Case Daten Provider (Datenquellen) anbinden Kurzbeschreibung Anbinden eines neuen Daten Providers Auslöser / Motivation Neue Daten Provider sollen angebunden werden Ergebnis Neue Daten Provider sind angebunden Akteure BI Plattform Administrator und Developer Eingehende Information Vordefinierte Parameter Vorbedingungen Verbindung mit ETL Tool oder anderem Tool erstellt Nachbedingungen Daten werden aus dem Quellsystem extrahiert Essenzielle Schritte Datenbank Zugriffe müssen geregelt sein (User- / Rollenkonzept) 5.4.1.10 Use Case 10 „Daten Consumer anbinden“ Name des Use Case Daten Consumer anbinden Kurzbeschreibung Anbinden eines neuen Daten Consumers Auslöser / Motivation Neue Daten Consumer sollen angebunden werden Ergebnis Neue Daten Consumer sind angebunden Akteure BI Plattform Administrator Eingehende Information Vordefinierte Parameter Vorbedingungen Verbindung mit ETL Tool oder anderem Tool erstellt Nachbedingungen Daten werden vom Sourcesystem geladen Essenzielle Schritte Datenbank Zugriffe müssen geregelt sein (User- / Rollenkonzept) _____________________________________________________________________________ 22 _____________________________________________________________________________ 5.4.1.11 Use Case 11 „Daten transformieren“ Name des Use Case Daten transformieren Kurzbeschreibung Daten sollten nach definierten Anforderungen transformiert werden Auslöser / Motivation Der Fachbereich benötigt transformierte Daten. Ergebnis Daten sind den Anforderungen entsprechend transformiert Akteure BI Plattform Administrator und Developer Eingehende Information Vordefinierte Parameter Vorbedingungen ETL Transformationsprozesse sind definiert Nachbedingungen - Essenzielle Schritte - _____________________________________________________________________________ 23 _____________________________________________________________________________ 5.5 Pflichtenheft Das Pflichtenheft beschreibt Ziele, welche mit der angestrebten Lösung zu erreichen sind sowie die Anforderungen und Wünsche an das zukünftige System. 5.6 Ausgangslage Wie in Kapitel 3 bereits erwähnt, sind die operativen Systeme durch analytische Auswertungen und unkontrollierte Datenreplikationen von Fremdsystemen stark beeinträchtigt. Dies wiederum führt zu Störungen im täglichen Betrieb. 5.7 Ist-Zustand Viele Bereiche der Schweizerischen Post benötigen Daten aus diversen Datenbanksystemen für Analysen und Auswertungen oder um die Daten im Sinne einer SOA als Service (nachfolgend Enterprise Service ES) zur Verfügung zu stellen. Die Replikation der Daten erfolgt mittels verschiedenster Technologien wie z.B. Snapshots, Replikation, Export / Import, Flatfiles, u.v.a. Umsysteme allgemeine operative Systeme überlastetes operatives System User Application Server Dedizierte operative Systeme XML Gateway Enterprise Service Bus Abildung 5.2: Ist-Zustand _____________________________________________________________________________ 24 _____________________________________________________________________________ In der Regel werden diese Analysen direkt auf den operativen Systemen ausgeführt. Diese Analysen beeinträchtigen die operativen Systeme dermassen, dass dies gelegentlich zu Störungen führt und nicht alle „online“ Anfragen bewältigt werden können. 1. Die Daten werden vermehrt von den operativen Datenbanken abgeholt, was zu Betriebsstörungen führen kann. Diese Situation hat sich mit SOA akzentuiert. 2. Die Daten werden vermehrt auf andere Umsysteme repliziert, auf welchen danach die Analysen der Daten durchgeführt werden. 3. Die Resultate der Analysen können je nach Umsystem variieren (kein Single Point of Truth). 4. Die Daten müssen bis zu einem bestimmten Zeitpunkt (z.B. 06:00 Uhr) garantiert auf einem Umsystem verfügbar sein, damit das Umsystem korrekt funktionieren kann. 5. Die Daten werden erst zur Laufzeit auf dem operativen System konsolidiert und aggregiert, was die Performance der operativen Systeme negativ beeinflusst. 6. Die Reports werden direkt auf operativen Systemen ausgeführt, was sich ebenfalls negativ auf die Performance auswirkt. 7. Die Bereiche benötigen immer häufiger zeitnahe Daten (real time) für Auswertungen. Dies führt vermehrt dazu, dass Reports direkt auf operativen Systemen ausgeführt werden. 8. Es gibt kein allgemein gültiges Konzept für die Integration der Daten. 9. Es gibt keine Infrastruktur, die Bereichsdaten zentral zur Verfügung stellt. 10. Nicht abgestimmte Datenstrukturen führen zu hohen Laufzeiten (normalisiert vs. denormalisiert). 5.8 Ziel Das Ziel ist es eine Plattform zu bauen, die die operativen Systeme entlastet, indem die Daten den Consumer-Systemen zentral zur Verfügung gestellt werden. Bei Bedarf können die Daten in aufbereiteter Form zur Verfügung gestellt werden, um allfällige Reports und Verarbeitungen performant durchzuführen. Das Anbinden an bestehende DWHs sollte dabei ebenfalls möglich sein. _____________________________________________________________________________ 25 _____________________________________________________________________________ 5.9 Anforderungen Aus den Interviews sowie aus unter Kapitel 5.7 erwähnten Betriebsproblemen, können folgende Anforderungen abgeleitet werden: 5.9.1 PA1 PA2 PA3 PA4 PA5 PA6 PA7 PA8 Anforderungen aus dem Projektauftrag (PA) Daten müssen auf einer separaten Plattform zur Verfügung gestellt werden, um die operativen Systeme nicht mehr länger zu beeinträchtigen. Bilden eines Single Point of Truth Daten müssen auf einer separaten Plattform aggregiert werden. Die Reports dürfen nicht mehr auf dem operativen System durchgeführt werden. Die eingesetzten Replikationsmechanismen müssen Real Time bzw. Near Real Time Funktionalitäten unterstützen. Aufbau eines allgemein gültigen Konzepts für die Datenintegration. Aufbau einer zentralen Infrastruktur für die Bereitstellung von Bereichsdaten für andere Systeme Verbesserung der Performance bei langlaufenden Reports durch Anpassen der Datenstruktur (denormalisieren) 5.9.2 Zusätzliche Anforderung aus den Interviews Ergänzend zu den Anforderungen aus dem Projektantrag wurden aus den Interviews zusätzliche abgeleitet. 5.9.2.1 IB1 IB2 IB3 IB4 IB5 IB6 IB7 IB8 IB9 IB10 IB11 Businessanforderungen aus Interview (IB) Die Auswertungen von Fremdsystemen dürfen nicht auf dem Quellsystem ausgeführt werden. Die Daten müssen von mehreren Monaten bis zu mehreren Jahren verfügbar sein. Die Möglichkeit von Real Time, Near Real Time ist gewünscht. Der Einsatz der bestehenden Tools sollte weiterhin möglich sein. Das zukünftige System soll mind. die SLA Anforderungen (RTO, RPO, Supportzeiten,usw.) der Quellsysteme erfüllen. Die Prozesse für die Anbindung müssen klar definiert sein. Beim Datentransfer soll auf die Kadenz und die Zeitkritikalität geachtet werden. Die Aktualität der Daten muss sichergestellt sein. Die neue Lösung soll günstiger sein. Auswertungen mit Scheduler und Mailversand sollen weiterhin möglich sein. Der Zeitpunkt der Datenintegration soll frei wählbar sein. _____________________________________________________________________________ 26 _____________________________________________________________________________ 5.9.2.2 IS1 IS2 IS3 IS4 IS5 IS6 IS7 IS8 IS9 IS10 IS11 IS12 IS13 IS14 Systemanforderungen aus Interviews (IS) Es müssen verschiedenste Datenquellen angebunden werden können (analog heutiger Situation) Verschiedenste Protokolle werden unterstützt (JDBC, SQL*Net, SOAP, ODBC,...) Es sollen multidimensionale Auswertungen möglich sein. Das neue System soll stabil / robust sein. Die Anbindung soll schnell und unkompliziert sein. Das System muss bidirektional wirken können. (Input aus Sourcen, Delivering von Targets) Die von den operativen Systemen replizierten Daten müssen wiederverwendbar sein. Es müssen verschiedenste Workloads durchgeführt werden können (komplexe Reports, Data Mining, OLAP, etc.). Das zukünftige System muss skalierbar sein (vertikal / horizontal). Das System kann mit einer hohen Anzahl Concurrent-User umgehen. Die auftretenden Lastspitzen (z.B. an Monatsenden) müssen bewältigt werden können. Das System muss einem hohem Transaktionsvolumen gewachsen sein. Das Datenvolumen soll keine Herausforderung darstellen (min. 3 Mt, max. 10Jahre). Das System soll bei Bedarf (z.B. an Monatsenden) skalierbar sein. _____________________________________________________________________________ 27 _____________________________________________________________________________ 5.10 Kriterienkatalog Um den Kriterienkatalog erstellen zu können, muss die Granularität der Anforderungen erhöht werden. Nur dann können diese Kriterien entsprechend ihrem Erfüllungsgrad hin gemessen werden. Dabei werden Muss- und Kann-Ziele definiert. Hierbei ist es sinnvoll, Gruppierungen nach den zu beurteilenden Kriterien zu erstellen und die erhobenen Anforderungen direkt im Kriterienkatalog zu referenzieren (z.B. PA1). Die Anforderungen werden nach funktionalen und nicht-funktionalen Anforderungsgruppen aufgeteilt. Funktionale Anforderungen Data Integration Plattform Performance Skalierbarkeit Flexibilität / Vielseitigkeit Nicht Funktionale Anforderungen Prozesse Kosten 5.10.1 Funktionale Anforderungen Data Integration (DI) Nr. Kriterium DI1 Real Time resp. Near Real Time Datenreplikation möglich DI2 DI4 Verschiedenste Datenquellen müssen angebunden werden können (analog heutiger Situation) Daten werden bei Integration in eine gemeinsame einheitliche Datenstruktur überführt Unregelmässige Ad Hoc Datenintegration möglich DI5 Denormalisieren der Daten bei Anbindung DI3 Referenz PA5, IB3, IB8 IS1 Muss X Kann X IS7 X IB7, IB8, IB11 PA8, IS3, IS8, IS11 X X _____________________________________________________________________________ 28 _____________________________________________________________________________ Plattform (PL) Nr. Kriterium PL1 Aufbau einer separaten zentralen Plattform für Bereitstellung und Aggregation der Daten PL2 PL3 PL4 PL5 PL6 PL7 PL8 PL9 PL10 PL11 PL12 PL13 PL14 PL15 PL16 PL17 PL18 PL19 PL20 Der Zugriff auf die Daten ist nicht an ein Protokoll gebunden Daten sind während 3 Monaten verfügbar Daten sind während 12 Monaten verfügbar Daten sind während >12 Monaten verfügbar Schnelle, einfach Anbindung Anbinden von Oracle RDBMS Anbinden von MySQL Anbinden von MSSQL Anbinden von Flatfiles, XML Der Zugriff mit bestehenden Tools ist weiterhin möglich Es werden multidimensionale Auswertungen unterstützt. Die Auswertungen können mittels Scheduler sowie anschliessendem Mailversand erstellt werden. Durch den Einsatz bewährter Technologien wird eine hohe Stabilität und Robustheit des Systems gewährleistet Die Plattform ist so dimensioniert, dass Lastspitzen keine Probleme darstellen. Die neue Plattform erfüllt mindestens die SLA Anforderungen der Quellsysteme Das System kann sowohl als Target, wie auch als Source verwendet werden. Die Plattform kann mindestens 20 Concurrent-User bewältigen, welche Standardreports ausführen. Die Plattform kann mindestens 50 Concurrent-User bewältigen, welche Standardreports ausführen. Die Plattform kann mindestens 100 Concurrent-User bewältigen, welche Standardreports ausführen. Performance (PE) Nr. Kriterium PE1 Zu verarbeitendes Transaktionsvolumen: hohes Transaktionsvolumen (5-6 Millionen Transaktionen pro Tag à 1KB) PE2 Zu verarbeitendes Transaktionsvolumen: mittleres Transaktionsvolumen (2-5 Millionen Transaktionen pro Tag à 1KB) PE3 Zu verarbeitendes Transaktionsvolumen: tiefes Transaktionsvolumen (1-2 Millionen Transaktionen pro Tag à 1KB) PE4 Die Datenmodellierung ist auf Performance ausgerichtet Referenz PA1, PA2, PA3, PA4, PA7, IB1 IS2 IB2 IB2 IB2 IB9, IS5 IS1 IS1 IS1 IS1 IB4, IS8 IS3, IS8 IB10 Muss X X X X IS4 X X X X X X X X X X IS11 X IB5 X IS6 IS10 Kann X X IS10 X IS10 X Referenz IS12 Muss IS12 X IS12 X PA8, IS8 X Kann X _____________________________________________________________________________ 29 _____________________________________________________________________________ Skalierbarkeit (SK) Nr. Kriterium SK1 System muss bei Bedarf skalierbar sein (on demand) SK2 Das System ist horizontal wie auch vertikal skalierbar Flexibilität (FL) Nr. Kriterium FL1 Die Wiederverwendbarkeit der Daten ist gewährleistet. FL2 Die Daten sind veränderbar 5.10.2 Referenz IS14 IS9, IS10, IS11, IS12, IS13 Muss Kann X X Referenz IS7 IS7 Muss Kann X X Referenz IB6 PA6, PA8, IB6, IS5 Muss X X Kann Referenz IB9 Muss Kann X Nicht Funktionale Anforderungen Prozesse (PZ) Nr. Kriterium PZ1 Es sind definierte Integrationsprozesse vorhanden. PZ2 Erstellen von allgemein gültigen Richtlinien und Standards für die Datenintegration Kosten (KS) Nr. Kriterium KS1 Die neue Lösung ist günstiger als eine Einzellösung _____________________________________________________________________________ 30 _____________________________________________________________________________ 5.11 Voranalysebericht In dieser Phase des Projektes wurden folgende Aktivitäten durchgeführt: 5.11.1 Erhebung des Ist-Zustandes Erhebung der Anforderungen Definition von Use Cases Erstellung des Kriterienkataloges (Pflichtenheft) Erhebung des Ist-Zustandes Bei der IST-Zustand Analyse soll aufgezeigt werden welche Prozesse, Techniken und Technologien eingesetzt werden. Hierbei wurden sämtliche existierende Dokumentationen und Prozessdefinitionen sowie die eingesetzten Technologien und Produkte analysiert. 5.11.1.1 Dokumentation Die bestehende Dokumentation verweist hierbei lediglich auf die Fachliteratur. Es sind keine konkreten Architekturen bekannt, vielmehr werden für die jeweiligen Projekte situativ zugeschnittene Architekturen definiert. Als Leitfaden dient das interne Dokument „BI Positionierung IT“. Dieses Dokument beschreibt eine Referenzarchitektur, die sich stark an die A. Bauer / H. Günzel Architektur anlehnt. Jedoch wird darauf hingewiesen, dass die beschriebene Referenzarchitektur je nach Gegebenheiten und Anforderungen zu überprüfen ist. 5.11.1.2 Prozesse Es wird auf Prozesse von bekannten BI Autoren (R. Kimball, A. Bauer / H. Günzel, W. Inmon, etc.) hingewiesen, allerdings fehlen konzeptionell ausgearbeitete Prozesse. Das führt dazu, dass bei jedem Projekt wieder von vorne begonnen werden muss und viele Grundsatzentscheidungen und Prozesse ständig neu definiert werden müssen. Dadurch kommt es sowohl zu einem organisatorischen, als auch technischen Mehraufwand. Mittels standardisierter Prozesse wäre eine grössere Effizienz zu erreichen und die Durchlaufzeit eines Projektes wären um einiges kürzer. Zudem wären die Zuständigkeiten und Aufgaben der beteiligten Personen klar geregelt. 5.11.1.3 Technologien Bei der Überprüfung der Ist-Situation wurde festgestellt, dass bei BI Projekten jeweils verschiedenste Technologien zum Einsatz kommen. Dies ist jedoch völlig normal, da unterschiedliche Business Anforderungen bestehen, welche nicht mit einheitlichen Technologien gelöst werden können. _____________________________________________________________________________ 31 _____________________________________________________________________________ 5.11.1.4 Produkte Die grösste Herausforderung stellen die Produkte selbst dar, da hier ein sehr breites Produktportfolio besteht. Diese Gegebenheit ist sehr verlockend, da sich dadurch eine Vielzahl von Lösungen anbietet. Andererseits ist genau dieser Umstand, der Grund für die bestehenden Insellösungen. Dadurch benötigt ein Unternehmen entsprechend gut ausgebildete Mitarbeiter, die über ein enormes Fachwissen der breiten Produktpalette verfügen. Das Betreiben einer solchen Lösung, wird schnell zu einer Herausforderung, da mit höchster Wahrscheinlichkeit das Knowhow nur bei einzelnen Mitarbeitern vorhanden sein wird. Ausserdem besteht die Gefahr, dass durch diese Vielzahl an Produkten keine konkreten Richtlinien eingehalten werden können. Dies führt zu vielen Einzellösungen und zu Problemen im Betrieb, wenn die Dokumentationen zu wenig ausführlich sind, sofern sie überhaupt vorhanden sind. In diesem Bereich ist eher eine Harmonisierung des Produktportfolios anzustreben. So könnte das Know-how viel effizienter aufgebaut werden. Richtlinien und Standards wären viel einfacher zu implementieren und zu überprüfen. In dem Produktportfolio werden die Einsatzgebiete grob beschrieben, jedoch fehlt die Information wann und wie welches Produkt eingesetzt wird. 5.11.2 Erhebung der Anforderungen Damit der Soll-Zustand realisiert werden kann, müssen die Anforderungen bekannt sein. Diese wurden, wie bereits erwähnt, mittels Interviews erhoben. Da uns der direkte Kundenkontakt nicht gestattet ist, wurden die Interviews mit Schlüsselpersonen im Bereich BI, DWH und Architektur geführt. Diese Personen haben nebst ihrem Fachbereich zusätzlich die Kundensicht vertreten. Es wurden Fragen im Bereich Business sowie System gestellt, damit später in den genannten Bereichen die entsprechenden Anforderungen abgeleitet werden konnten. Die Schwerpunkte der Interviews bestanden im Erheben der Business Anforderungen Aktualität der Daten Quellsysteme und Zielsysteme Art von Reports Anzahl Reports Kadenz und Zeitkritikalität der Datentransfers Prozesse Datenvolumen Zielpublikum Anzahl User sowie der Technischen Anforderungen Berücksichtigen der aktuellen und zukünftigen Systemlandschaft und Umsysteme Einsatz der bestehenden Tools Einsatz der bestehenden Technologien _____________________________________________________________________________ 32 _____________________________________________________________________________ Einsatz der bestehenden Datenbanktechnologien Anzahl Benutzer (concurrent) Skalierbarkeit des zukünftigen Systems Recovery Time Objective (RTO) Recovery Point Objective (RPO) Lastspitzen und Lastverteilung Richtlinien und Standardisierung Die erhobenen Anforderungen wurden einerseits in funktionale und nicht funktionale Anforderungen aufgeteilt und andererseits in einem Kriterienkatalog festgehalten. Damit kann erreicht werden, dass die Anforderungen messbar sind und die Umsetzung der Anforderungskriterien gleichzeitig überprüft werden kann. Die Anforderungskategorien sehen wie folgt aus: Funktionale Anforderungen Data Integration Plattform Performance Skalierbarkeit Flexibilität / Vielseitigkeit Nicht Funktionale Anforderungen 5.11.3 Prozesse Kosten Erstellung des Kriterienkatalog (Pflichtenheft) Mit der Erstellung des Katalogs wurden die nötigen Kriterien definiert, welche aus den funktionalen und nicht funktionalen Anforderungen abgeleitet wurden. Gleichzeitig ist damit der Erreichungsgrad der Umsetzung messbar. Die Kriterien weisen ein hohe Granularität in Bezug auf die Anforderungen auf und werden als Muss oder Kann Kriterien klassifiziert. Die Muss Kriterien müssen für den Soll-Zustand zwingend umgesetzt werden. Das Nicht-Erfüllen eines Kann Kriteriums hingegen wirkt sich jedoch nicht auf die Grundfunktionalitäten der Plattform aus. 5.11.4 Definition von Use Cases Damit die Ziele aus Sicht Fachbereich sichtbar gemacht werden konnten, wurden Use Case Diagramme erstellt. Diese beschreiben welcher Inhalt nötig ist, um die Ziele zu erreichen. In der Phase der Voranalyse, beschränken sich die Use Cases lediglich auf die Business Cases. Dem zu Folge werden die Funktionen auch nur aus Sicht Business modelliert. Die Use Cases richten sich nach den Business Requirements. _____________________________________________________________________________ 33 _____________________________________________________________________________ Im Bereich Business Intelligence sind die Use Cases limitiert, da die Haupttätigkeiten aus der Sicht des End Users im Bereich der Auswertung der Daten liegen. Das System als Ganzes besteht aber dennoch aus weiteren Merkmalen wie Extrahieren, Laden und Transformieren. Die Modellierung der Systemkomponenten wird in der Phase Konzept eingehender behandelt. _____________________________________________________________________________ 34 _____________________________________________________________________________ 6 Konzept In diesem Kapitel wird das Konzept für die Entstehung der „Zentralisierte und modulare Business Intelligence Infrastruktur und Plattform“ erstellt. Dabei werden die Aspekte zur Realisierung sowie der Einführung erarbeitet und definiert. 6.1 Einleitung Für die Realisierung des Konzepts sollen zunächst mögliche Lösungen erarbeitet, analysiert und bewertet werden. Nach der Bewertung der erarbeiteten Lösungsmöglichkeiten wird sich eine Lösung herauskristallisieren und diese wird als zukünftige Plattform definiert. In einem weiteren Schritt sind die Details des Konzepts zu erarbeiten und die Zielarchitektur, die notwendigen Prozesse und Richtlinien zu definieren. 6.2 Problematik bei der Schweizerischen Post In der IT Infrastruktur der Schweizerischen Post greifen einzelne Systeme oft auf andere Systeme zu, um Auswertungen und Analysen durchzuführen. Häufig ziehen die Systeme die benötigte Daten ab und persistieren diese auf anderen Systemen. Hierbei werden diese Daten erneut von weiteren Systemen in Anspruch genommen. Daraus ergibt sich, dass Daten redundant gehalten werden und man keinen „Single Point of Truth“ mehr hat. Diese Situation wurde in der Problemstellung [Kapitel 4] bereits angesprochen. Aus oben genannter Situation ergibt sich ein sogenanntes Spinnennetz (Spiderweb), welches bekanntermassen langfristig zu Problemen führt, da sämtliche Systeme von ihren Quellen abhängig sind. Zudem werden die Daten immer wieder nach Anforderungen des Business so manipuliert wie es gerade sinnvoll ist, was jedoch die Wiederverwendbarkeit der Daten erheblich einschränkt. Abbildung 6.1: Spinnennetz (Spiderweb) _____________________________________________________________________________ 35 _____________________________________________________________________________ 6.3 Daten Im nächsten Kapitel wird das Thema Daten näher erläutert. 6.3.1 Definition Daten Daten sind eine Sammlung von einzelnen Zeichen, die in Kombination einen Sinn und Nutzen ergeben. Daten alleine ergeben allerdings noch keinen Mehrwert. Erst wenn diese zu Informationen weiter verarbeitet werden, können Daten für ein Unternehmen sinnvoll eingesetzt werden. Dabei gilt es, die Daten in einer sinnvollen Struktur zu speichern und gegebenenfalls in Relation zu anderen Daten zu bringen. W. Inmon unterteilt in seinem Buch „Building the Data Warehouse“ die Daten in zwei Kategorien: Primitive Data / Operational Data Derived Data / DSS Data Abbildung 6.2: Quelle - W.Inmon „Building the Data Warehouse“ Während die „Primitive Data / Operational Data“ eher den Daten in einem ODS gleichen, so sind die „Derived Data / DSS Data“ in einem DWH anzutreffen. Für unsere Thesis bedeutet dies, dass wir die Daten, nachdem diese aus den operativen Datenbanken extrahiert wurden, später in ein DWH überführen müssen. 6.3.2 Von Daten zu Informationen Eine Schwierigkeit besteht darin, von Daten zu Informationen zu gelangen. Was auf den ersten Blick für sich alleine uninteressant erscheint, gewinnt in Kombination mit anderen Daten schnell an Bedeutung. Deshalb ist es sehr wichtig, Art und Weise und den Ort der Datenspeicherung frühzeitig zu bestimmen. Datenstrukturen und Relationen werden in einem Datenmodell zusammengefasst, welche mittels Entity Relationship Diagramm verwaltet werden. _____________________________________________________________________________ 36 _____________________________________________________________________________ Daten sind das wichtigste Gut eines Unternehmens, aber erst wenn sie auch zu Informationen veredelt werden. Mit Informationen können Unternehmen kritische Entscheidungen auf der Basis von objektiven Werten treffen und das Business somit zum Optimum führen und in der Regel kommerzielle Vorteile erlangen. Ohne die richtigen Informationen würde ein Unternehmen Entscheidungen im Blindflug treffen und damit allenfalls einen kommerziellen Schaden herbeiführen. 6.3.3 Informationspyramide Den Detailierungsgrad und die Wichtigkeit der Informationen kann man am besten mittels einer Informationspyramide darstellen. Dabei werden die Informationen immer mehr abstrahiert und aggregiert, bis diese letztendlich für jeden Bedürfnisträger in der gewünschten Form vorliegen. Strategische Ebene: Geringe Anzahl an User Wochentliche/Monatliche Aktualisierung Grafischorientierte Tools CEO/CFO/CIO Leiter Leiter Finanzen Leiter Briefzentrum Paketzentrum Fachdienste Poststellen Integrations Poststellen Leiter Systeme Buchhalter Mitarbeiter Taktische Ebene: Grosse Anzahl an Usern Tägliche/Wochentliche Aktualisierung Flexible Analyse- und Reporting-Tools Operative Ebene: Grosse Anzahl an Usern Zeitnahe Aktualisierung der Daten Zugriff auf detaillierte Daten Reporting Abbildung 6.3: Informationspyramide _____________________________________________________________________________ 37 _____________________________________________________________________________ 6.4 Begriffsdefinitionen und Technologien Um ein gemeinsames Verständnis des Konzeptes zu schaffen, werden nachfolgend einzelne wichtige Begriffe erläutert. 6.4.1 Dataware House (DWH) Ein Dataware House ist eine Datenbank die meist riesige Datenmengen beinhaltet und die für Datenanalysen ausgelegt ist. Es kann historische Daten abbilden und dient als Quelle für BIApplikationen. Als Datenquellen dienen dabei meist operative Datenbanken aber auch andere Dataware Houses. Allerdings gibt es in der Fachliteratur keine klare einheitliche Definition zum DWH. Folgende drei Autoren sind besonders hervorzuheben, die eine weit verbreitete Definition erstellt haben. W. Inmon: „A data warehouse is a subject-oriented, integrated, time-variant, nonvolatile collection of data in support of management´s decision-making process.“ A. Bauer / H. Günzel: „Ein Data-Warehouse ist eine physische Datenbank, die eine integrierte Sicht auf (beliebige) Daten darstellt, um Analysen zu ermöglichen.“ R. Kimball: „A data warehouse is a copy of transaction data specifically structured for querying and reporting.“ 6.4.2 Data Mart Bei einem Data Mart werden, aus applikatorischen oder organisatorischen Gründen, Teile eines DWHs in eine separate Datenbank extrahiert. Dabei kann zwischen abhängigen und unabhängigen Data Marts unterschieden werden. Die Daten weisen jeweils eine hohe Denormalisierung und Aggregation auf und betreffen meist einen separaten Fachbereich. Data Marts sind die multidimensionale Sicht eines Fachbereiches. Durch die Verlagerung auf eine andere Maschine, kann zusätzlich die Performance verbessert werden. _____________________________________________________________________________ 38 _____________________________________________________________________________ 6.4.3 Operational Data Store (ODS) In dem folgenden Kapitel wird der ODS näher beschrieben. Dabei wird auch auf die verschiedenen ODS Klassen nach Definition von W. Inmon eingegangen. 6.4.3.1 Was ist ein ODS? Bei dieser Frage scheiden sich die Geister. Im BI Umfeld sind verschieden Spezialisten tätig, die Definitionen und Referenzarchitekturen realisiert haben und nach denen sich die meisten BI Architekten richten. Die bekanntesten Spezialisten sind R. Kimball, W. Inmon und A. Bauer / H. Günzel. Alle obengenannten „Referenzen“, haben ihre Definition bezüglich ODS erläutert. Unsere Definition basiert auf allen drei, da eine Kombination dieser aus unserer Sicht am meisten Sinn macht. Der ODS ist eine zentralisierte und integrierte Datensammlung, bei der die operativen Quellsysteme als Zulieferer dienen. Das ODS beinhaltet die gleiche Granularität der Daten wie die operativen Datenbanken und weist eine Begrenzung bezüglich historischen Daten aus. Dies bedeutet, dass die Daten nur für eine gewisse Zeit vorhanden sind. Anschliessend werden diese entweder gelöscht oder in ein DWH überführt. Der ODS ist Applikationsneutral. Das Datenmodell ist nicht auf eine spezifische Applikation zugeschnitten, sondern auf Wiederverwendbarkeit ausgerichtet. Die Daten in einem ODS sind aktualisierbar. Es ist allerdings empfehlenswert, die Mutationen direkt auf den operativen Datenbanken durchzuführen und die Daten anschliessend erneut in den ODS zu laden. Sinnvollerweise ist ein ODS in verschiedene Kategorien unterteilt (Subject Oriented). Dabei werden in grossen Unternehmen die Daten in verschiedene Kategorien unterteilt, so dass die verschiedenen Business Anforderungen abgedeckt werden können. Dies erleichtert das Management der Informationen, zudem können die Daten besser integriert werden. Die Daten eines ODS werden für operative Zwecke verwendet. Daher ist es sinnvoll diese so aktuell wie möglich zu halten. Zusätzlich unterliegen die Daten aus den operativen Systemen einer hohen Volatilität. Das heisst, die Daten sind ständigen Veränderungen ausgesetzt. Dies ist einer der Hauptunterschiede zum DWH. _____________________________________________________________________________ 39 _____________________________________________________________________________ 6.4.3.2 Klassenbeschreibung W. Inmon unterteilt das ODS in verschiede Klassen. Die Klassen unterscheiden sich untereinander aufgrund des zeitlichen Aspektes bei der Aktualisierung im ODS. Klasse I: Das Zeitintervall bis die Daten im ODS vorhanden sind, dauert nur wenige Millisekunden. Diese Art von Aktualisierung ist für den End User transparent. Das System steuert die Übermittlung, respektive die Replikation zum ODS. Bei diese Art von Replikation kann von Real Time gesprochen werden. Für den End User ist es nicht feststellbar, ob sich der Datenbestand im ODS vom operativen System unterscheidet. Klasse II: Bei dieser Klasse vergehen Stunden bis die Daten ins ODS überführt werden. Der End User kann den Unterschied zwischen operativen System und ODS feststellen. Klasse III: In der Klasse III, werden die Daten einmal pro Tag ins ODS repliziert. In der Regel geschieht dies über Nacht mittels klassischer Ladeprozedur. Klasse IV: Die Klasse IV hat den grössten zeitlichen Intervall bezüglich Datenüberführung. dies kann von mehreren Wochen bis zu mehreren Jahren dauern. Diese Klasse regelt die Datenüberführung vom ODS ins DWH. Klasse I (Millisekunden) Klasse II (Stunden) ODS Klasse IV (Monaten – Jahren) DWH Klasse III (Tage) Abbildung 6.4: ODS Klassen _____________________________________________________________________________ 40 _____________________________________________________________________________ 6.4.4 Unterschied zwischen ODS und DWH Auf den ersten Blick scheinen ODS und DWH sehr ähnlich. Geht es jedoch um Volatilität, Aktualität und Detailierungsgrad der Informationen, werden erhebliche Unterschiede sichtbar. Während beim ODS die Daten in kurzen Intervallen laufend aktualisiert werden, werden im DWH die Änderungen mittels einem erstellten Snapshot in längeren Intervallen übertragen und historisiert. Kurz gesagt, enthält der ODS aktuelle / frische Daten, während das DWH historische Daten beinhaltet. Ein weiterer Unterschied ist die Granularität der Daten. Im ODS sind die Daten sehr detailliert vorhanden, wohingegen im DWH die Daten bereits aufbereitet und aggregiert vorliegen. Aus Sicht des DWH ist der ODS nur eine weitere Datenquelle. 6.4.5 Basisdatenbank Die Basisdatenbank wird gemäss A. Bauer / H. Günzel als Zwischenstufe zwischen operativen Datenbanken und dem DWH bezeichnet. Sie dient als Integration der Daten für verschiedene Analysen und agiert als Verteiler. Es wird Wert drauf gelegt, dass die Wiederverwendbarkeit für andere Zielsysteme gegeben ist. 6.4.6 Unterschied zwischen Basisdatenbank und ODS Der Unterschied zwischen einer Basisdatenbank und dem ODS besteht darin, dass die Daten immer in die Basisdatenbank integriert und mehrheitlich auch transformiert werden. Die Basisdatenbank wird nicht eingesetzt, um etwaige Aggregationen vorzunehmen. Diese Aktionen werden im DWH durchgeführt, nachdem die Daten weitergereicht wurden. Grundsätzlich stellt die Basisdatenbank im Gegensatz zum ODS nur eine „Datendrehscheibe“ für das DWH dar. Mit der Basisdatenbank werden auch Qualitätssicherungsfunktionen wahrgenommen. 6.4.7 Daten Replikation Daten Replikationsmechanismen werden eingesetzt, um Daten von einem System zum anderen zu replizieren. Diese Aktion wird nötig, wenn operative Systeme entlastet werden sollen oder Daten zur Weiterverarbeitung an ein anderes System übermittelt werden. Vielfach werden Daten ausgelagert, um anschliessend darauf Reports zu erstellen oder Analysen durchzuführen. Es gibt diverse Replikationsmechanismen. Hier die Bekanntesten: Materialized Views triggerbasierte Replikation transaktionsbasierte Replikation High Water Mark Replikation logbasierte Replikation _____________________________________________________________________________ 41 _____________________________________________________________________________ In unserer Semesterarbeit (CAS BI01) haben wir uns bereits ausführlich mit diversen Replikationsmechanismen auseinander gesetzt, weshalb hier nicht mehr detailliert darauf eingegangen wird. 6.4.8 Online Transactional Processing (OLTP) Bei einem OLTP System werden Transaktionen verarbeitet. Dabei werden Daten gelesen, geändert, gelöscht oder geschrieben. Ziel eines OLTP Systems ist es möglichst viele Transaktionen in möglichst kurzer Zeit zur verarbeiten. Die Transaktionen sind meist von einfacher Struktur und liefern tendenziell wenige Datensätze zurück. 6.4.9 Online Analytical Processing (OLAP) Bei OLAP steht die Durchführung von komplexen Analysen in Vordergrund. Die dabei verarbeitende Datenmenge ist sehr hoch und führt zu Antwortzeiten zwischen Sekunden und Minuten. Als Resultat werden jeweils sehr viele Datensätze zurückgeliefert. Die Daten liegen für die Abfragen meist in einem speziellen dimensionalen Modell vor. Häufig trifft man OLAP in DWHs an. 6.4.10 Extract Transformation Load (ETL) ETL ist ein Prozess, der in die drei Teilschritte Extract, Transformation und Load unterteilt wird. Die Daten werden dabei aus einem Quellsystem extrahiert, in die gewünschte Form umgewandelt und danach in das Zielsystem geladen. Für den ETL Prozess werden häufig spezielle Tools verwendet. Extraktionskomponente: Die Extraktionskomponente ist für die Übertragung der Daten aus einer angebundenen Datenquelle zur Transaktionskomponente verantwortlich. Als Datenquellen können nebst anderen Datenbanken auch Flatfiles dienen. Transformationskomponente: Die Transformationskomponente hat zum Ziel die Daten, welche meist aus verschiedensten Quellen kommen in eine allgemeingültige Struktur zu bringen. Mögliche Transformationsschritte sind: Behandlung von Null-Werten Erstellen von zusätzlichen Schlüsseln Aggregation der Daten Standardisierung von Elementen Bereinigungen De- / Normalisierung u.v.a. _____________________________________________________________________________ 42 _____________________________________________________________________________ Ladekomponente: Die Ladekomponente lädt die transformierten Daten in das Zielsystem. Dabei wir häufig auf proprietäre Tools des Ziel RDBMS zurückgegriffen. Der Ladevorgang findet meist online statt, so dass weiterhin auf die Daten des Zielsystems zugegriffen werden kann. Ausnahme bildet der Initalload, der in der Regel offline durchgeführt wird. 6.4.11 Extract Load Transformation (ELT) Beim ELT Prozess werden dieselben Komponenten wie beim ETL Prozess verwendet. Der Unterschied liegt einzig und alleine in der Abfolge der Komponenten. 6.4.12 Structed Query Language (SQL) SQL ist eine standardisierte Datenbanksprache für Abfragen und Manipulationen von Daten in einer relationalen Datenbank. Dabei spielt es keine Rolle, ob man sich auf einer Oracle, einer MSSQL oder einer Datenbank eines anderen Herstellers befindet. Viele Hersteller haben diesen Standard mit eigenen Funktionalitäten erweitert, was sich durch eine leicht veränderte Syntax bemerkbar macht. SQL gilt seit 1992 als standardisierte Sprache (SQL ANSI 92). 6.4.13 Relational Database Management System (RDBMS) Ein RDBMS ist ein Datenbank System, welches hauptsächlich auf die Relationen der Objekte (i.d.R. Tabellen) zu einander ausgelegt ist. In einer Datenbank besteht die Gefahr Daten redundant zu halten. Daher werden in der Software Design Phase die Funktionen so definiert, dass solche Redundanzen möglichst vermieden werden. Dies gelingt, indem man sich an die Normalisierungsregeln der 3. Normalform hält. Damit werden die Entitäten so ausgelegt, dass diese in sich selbst eine sinnvolle Gruppierung ohne Redundanzen bilden. Anschliessend werden diese Entitäten mit Primary Key ausgestattet und eine implizite „uniqueness“ gebildet. Diese Entitäten machen aber erst in Relation mit anderen Entitäten Sinn, da damit sinnvolle Informationen gebildet werden können. Die Relationen unter den Entitäten werden mittels Foreign Key bewerkstelligt. Dabei wird das Primary Key Attribut der einen Entität als Foreign Key der anderen Entität benutzt. Somit stehen ab diesem Zeitpunkt beide Entitäten in Relation zu einander. Ein solches relationales Gebilde kann eine unübersichtliche Grössenordnung erreichen. Hierbei können sogenannte Entity Relationship Diagramm (ERD) Tools Abhilfe schaffen. Mit RDBMS Datenbanken müssen nicht zwingend die beschriebenen Relationen abgebildet werden. Sie besagen nur, dass sie im Stande wären, solche Relationen herzustellen. Die grössten und bekanntesten RDBMS-Anbieter sind: Microsoft Oracle IBM MySQL PostgreSQL (Open Source) _____________________________________________________________________________ 43 _____________________________________________________________________________ 6.4.14 Change Data Capture (CDC) Change Data Capture (CDC) ist eine Datenbank Technologie, die eingesetzt wird um Datenveränderungen (Inserts, Updates, Deletes) aufzuzeichnen. Diese Technologie wird häufig für Data Integration eingesetzt. In gewissen DWH Projekten, bei denes es wichtig ist Datenveränderungen so schnell als möglich einfliessen zu lassen, ist diese Technologie äusserst hilfreich. Die Architektur besteht aus einer Source und einer oder mehreren Staging Areas. Die Staging Area ist nicht mit dem DWH Staging Area zu verwechseln, da lediglich das Ziel System gemeint ist. Source Bereich Staging Bereich Change_Table Subscriber_Table Subscriber Abbildung 6.5: CDC Architektur CDC besteht aus folgenden Komponenten: Capturing Publishing Subscriber Der Capturing Mode befasst sich mit dem Erfassen der Datenveränderungen. Der Publisihing Mode hingegen behandelt, wie die Datenveränderungen zum Zielsystem kommen. Die Subscriber sind die eigentlichen Benutzter. In der Regel sind dies Applikationen. Diverse RDBMS Anbieter, bieten für ihren Datenbanken die CDC Technologie an. Alles in allem agieren diese nach ähnlichem Muster. _____________________________________________________________________________ 44 _____________________________________________________________________________ 6.4.15 Real Time Real Time beschreibt jenen Zustand, der die Dauer eines Vorganges klar definiert. Das heisst, die Zeitdauer darf die kritische Marke des Systems nicht überschreiten, die ansonsten zu schwerwiegenden Fehlern im System führt. In der Regel spricht man von „verzögerungsarm“. Da diese Metrik relativ ist, muss diese von Fall zu Fall definiert werden. Dabei kann man von Millisekunden bis mehreren Sekunden ausgehen. Real Time wird vielfach mit „im selben Augenblick“ verwechselt. Dieser Zustand sagt noch nichts über die Übertragungs- oder Verarbeitungsgeschwindigkeit aus. 6.4.16 Near Real Time Near Real Time ist vom Grundsatz her ähnlich wie Real Time. Der Hauptunterschied ist, dass die kritische Marke wesentlich höher angesetzt ist. Diese Systeme vertragen somit eine höhere Latenz, bis es zu applikatorischen Problemen kommt. 6.4.17 Snapshots / Materialized Views Snapshots oder Materialized Views ist eine Technik, die eingesetzt wird, um Views zu materialisieren. Damit wird die logische Struktur einer View, die aus mehreren Tabellen bestehen kann, in einer persistenten Form abgespeichert. In der Regel basiert eine Materialized View aus einer Tabelle, die nach vordefinierten Zeitintervallen (Refreshs) aktualisiert wird. Bei den Refreshs bestehen verschiedene Varianten. Es können full, inkrementelle oder transaktionsbasierte Refreshs stattfinden. Full und inkrementelle Refreshs werden durch einen Job Scheduler gesteuert. Die Materialized Views werden dort eingesetzt, wo der Zugriff auf die normale View zu lange dauert, weil diese aus vielen Joins über verschiedenste Tabellen besteht. Müssen solche Joins in einer View aufgelöst werden, können enorme Probleme entstehen. Materialized View werden häufig auch als Replikationsverfahren eingesetzt, da die Möglichkeit besteht, diese in verteilten Datenbanken einzusetzen. 6.4.18 Normalisierung Normalisierung ist meist bei relationalen Datenbanken anzutreffen. Dabei wird eine möglichst hohe Redundanzfreiheit der Daten angestrebt. Dies geschieht, indem Teile der Daten zerlegt und in eine andere Tabelle ausgelagert werden. Zusätzlich werden die Daten mit Primary und Foreign Keys in Beziehung zueinander gesetzt. Meist wird nur bis zur 3. Normalform zerlegt, man spricht dann häufig von 3NF. 6.4.19 Denormalisierung Bei der Denormalisierung werden die Daten, die in normalisierter Form vorliegen, in wenige grosse und flache Tabellen zurück umgewandelt. Dabei entstehen Redundanzen, die man jedoch wegen der geringeren Komplexität und dem Performancegewinn gerne in Kauf nimmt. _____________________________________________________________________________ 45 _____________________________________________________________________________ 6.4.20 Multidimensional Von Multidimensional ist die Rede, wenn Daten so organisiert werden, dass Analysen über die verschiedenen Dimensionen durchgeführt werden können. In der Regel spricht man von Dimensionen und Fakten. Dimensionen sind qualifizierende Daten, was bedeutet, dass sie von beschreibender Natur sind. Fakten hingegen sind quantifizierende Daten, womit die Daten als Aggregate zur Verfügung stehen. Multidimensionale Konstrukte sind auch als Würfel (Cubes) bekannt. Cubes ermöglichen beliebig viele Analysen über unterschiedliche Dimensionen. 6.4.21 Star Schema Beim Denormalisieren werden die Daten häufig in ein sogenanntes Star Schema überführt. Dabei wird eine Faktentabellen und Dimensionstabellen erstellt. Die Faktentabelle bildet mit Hilfe der Foreign Keys aus den Dimensionen den Primary Key. Durch dieses Konstrukt erreicht man eine hohe Abfragegeschwindigkeit, da weniger Joins nötig sind. Zusätzlich fördert es durch die Einfachheit, die Verständlichkeit und Nachvollziehbarkeit. 6.4.22 Snow Flake Modell Das Snow Flake Modell besteht aus einer Vielzahl von Star Schemas. Wie im Star Schema beschrieben, steht die Faktentabelle mit den darunterliegenden Dimensionen im Vordergrund. Das Snow Flake Modell verbindet verschiedene Faktentabellen und deren Dimensionen. Durch das Verbinden können die Dimensionen weiter verwendet werden, womit diese zu „Comformed Dimension“ werden. 6.4.23 Operative Datenbanken Von operativen Datenbanken ist die Rede, wenn diese mittels Applikation für das operative Kerngeschäft eines Unternehmen von enormer Wichtigkeit sind. In der Regel sind dies sogenannte Online Transactional Processing (OLTP) Systeme. Eine typische OLTP Applikation ist ein Customer Relationship Management System (CRM) eines Call Centers. Dort werden Daten des Kunden online abgefragt und sogleich eingegeben. So ein operatives System respektive Datenbank, ist auf kurze schnelle Transaktionen ausgelegt und bewältigt die Anfragen innerhalb von Millisekunden. Aufgrund der Art der Daten sind diese Systeme für Analysen begehrt, was jedoch zu Performanceeinbussen im OLTP Bereich führen kann. 6.4.24 Schnittstellen Schnittstellen ermöglichen in unserem Fall die Verbindung zu einer oder mehreren Datenquellen. Sie bildet die Basis für den Datenaustausch zwischen den Systemen. Je nach Datenbankhersteller werden unterschiedliche Datenbankschnittstellen angeboten. _____________________________________________________________________________ 46 _____________________________________________________________________________ 6.4.25 Skalierbarkeit (horizontal / vertikal) Skalierbarkeit ist ein weiter Begriff und bedingt daher einer näheren Interpretation. In einer IT Systemlandschaft sind verschiedene Komponenten im Einsatz. Jede davon erfüllt eine spezielle Funktion. Anhand eines Beispiels soll dies näher erläutert werden: zwei Systeme sind netzwerkmässig miteinander verbunden und tauschen grosse Datenmengen untereinander aus. Das eine System hat ein 1 Gbit/s Interface hat und das andere ein 100 Mbit/s Interface. In diesem Fall wird das zweite System unweigerlich ans Limit seiner Bandbreite kommen. Als Konsequenz daraus, wird man skalieren müssen, was hier einem Erhöhen der Bandbreite entspricht. Skalierungsprobleme sind in folgenden Hauptkomponenten anzutreffen: Hardware Storage Operating System Datenbank Applikation Bevor die Clustering resp. Grid Technologie sich durchgesetzt hat, wurde die Skalierung mittels Beschaffung von grossen Infrastrukturen und dem stetigen Ausbau der Systeme realisiert, bis dies nicht mehr möglich war. Diese Art von Skalierung ist auch bekannt als vertikale Skalierung oder Scale Up. Server Memory Einbau von zusätzlicher Memory Vertikale Skalierung CPU Einbau von zusätzlicher CPUs Abbildung 6.6: Vertikale Skalierung _____________________________________________________________________________ 47 _____________________________________________________________________________ Was ist Clustering resp. Grid Technologie? Clustering Technologie wird hauptsächlich eingesetzt, um Systeme redundant zu gestalten. Dabei ist nebst dem aktiven System immer auch ein passives System im Einsatz, das bei einem allfälligen Ausfall des primären Systems, dessen Funktion übernehmen kann. Mit der Grid Technologie hat man die Effizienz von Aktiv / Passiv System steigern wollen, so dass Aktiv / Aktiv Systeme daraus resultierten. Dabei ist in der Regel eine proprietäre Software im Einsatz, die das Locking Problem über die verteilte Infrastruktur wahrnimmt. Failover Cluster passiv aktiv Abbildung 6.7: Failover Cluster Mittels Grid Technologie wurden neue Lösungen für die Skalierungsproblematik möglich. Durch diese Technologie muss nicht mehr auf eine grosse und teure Infrastruktur gesetzt werden, sondern es genügt die Beschaffung einer kleineren und kostengünstigeren Infrastruktur, die bei Bedarf skalieren kann. Diese Art von Skalierung nennt man horizontale Skalierung oder Scale Out. Horizontale Skalierung aktiv aktiv aktiv aktiv Datenbank Abbildung 6.8: Horizontale Saklierung 6.4.26 Recovery Time Objective (RTO) Recovery Time Objective definiert die Zeit, die bei einem Systemausfall längstens verstreichen darf, bis das System wieder hergestellt und den Usern zur Verfügung steht. Diese Kennzahl ist bei Business kritischen Applikationen von enormer Wichtigkeit, um bei einem Systemausfall einen kommerziellen Schaden zu verhindern. Diese Kennzahlen werden in der Regel in den Service Level Agreements (SLA) festgelegt. Daraus resultiert eine architektonische Lösung die dem SLA standhält. _____________________________________________________________________________ 48 _____________________________________________________________________________ 6.4.27 Recovery Point Objective (RPO) Recovery Point Objective definiert das Datenvolumen, das bei einem allfälligen Systemausfall entbehrt werden kann, ohne dass daraus ein kommerzieller Schaden seitens Business resultiert. Das heisst, die verlorenen Daten können nicht restored werden und müssen neu erfasst resp. rekonstruiert werden. Zusammengefasst bedeutet dies, dass definiert wird, wieviel Datenverlust tragbar ist. Diese Kennzahl wird analog dem RTO in einem Service Level Agreement (SLA) festgelegt. Mittels dieser Kennzahl werden entsprechende architektonische Lösungen realisiert, die dem SLA entsprechen. 6.4.28 Reporting Mittels Reporting können Reports (Berichte) aus den Daten in der Datenbank erstellt werden. Dabei kann zwischen Standardreports und Ad Hoc Reports unterschieden werden. Bei den Standartreports handelt es sich in der Regel um vordefinierte Abfragen, die vom Benutzer nicht oder nur minimal angepasst werden können. Diese zeichnen sich in der Regel, dank einer gut strukturierten Abfrage, durch eine gute Performance aus. Ad Hoc Reports hingegen können durch den Benutzer zusammengestellt werden. Häufig wird dafür ein spezielles Tool verwendet, in welchem, der Benutzer die entsprechenden Attribute zusammenfügen kann. Das Tool generiert danach im Hintergrund ein entsprechendes SQL Statement. Selbstverständlich können Ad Hoc Reports auch durch selbstgeschriebene SQL Statements erstellt werden. Solche Ad Hoc Reports können aber zu Problemen führen, wenn durch suboptimale oder nicht vorhandene Indexes zusätzlich grosse Datenmengen gelesen werden müssen. _____________________________________________________________________________ 49 _____________________________________________________________________________ 6.4.29 View Layer Der Einsatz von Views ist bei Datenbank Technologien ein bewährtes Hilfsmittel. Mittels Views können logische Sichten über mehren Datenbankobjekte (i.d.R. Tabellen, Views, Materialisierte Tabellen) erstellt werden. Wie erwähnt sind dies logische Konstrukte ohne jegliche Persistenz. Views dienen in der Regel nur als Abfrage Instrumente. Ein Vorteil von Views ist, dass die Objekte neu benannt werden können. Dies ist vor allem bei weniger aussagekräftigen Attributen nützlich. In grossen Unternehmen besteht das Bedürfnis Daten aus verschiedenen Abteilungen bzw. Bereichen verschiedenen Stakeholdern zur Verfügung zu stellen. Damit eine Vielzahl an Redundanzen vermieden werden kann, werden die Daten zentral zur Verfügung gestellt. Da oftmals nicht alle Datenstrukturen die Anforderungen aller Stakeholder, erfüllen, kann mit entsprechenden auf die Stakeholder angepassten Views dieses Problem behoben werden. Die Regelung der Zugriffe und Berechtigungen werden zentral verwaltet. Das Deployment kann ebenfalls von zentraler Stelle gesteuert werden. End User Applikations Server Umsystem View Layer View View View View View View View View View Abbildung 6.9: View Layer 6.5 Zentralisierung vs. Dezentralisierung Beim Aufbau einer Plattform stellt sich die Frage, ob diese zentral oder verteilt gegliedert sein soll. Je nach Applikation und deren Einsatzzweck macht eine zentralisierte oder verteilte Plattform mehr oder weniger Sinn. Bei einem ODS macht eine zentralisierte Plattform mehr Sinn, da die bereitgestellten operativen Daten eine grössere Erreichbarkeit der verschiedenen Bedürfnisträger ermöglicht. Die Anforderung der Wiederverwendbarkeit der Daten wird mittels zentralisierter Plattform vollumfänglich erfüllt. Wäre ein ODS verteilt, ergäben sich verschiedene Domains auf welchen sich die End User zuerst die nötigen Zugriffe und Berechtigungen beschaffen müssten. Zudem müssten die Daten unter _____________________________________________________________________________ 50 _____________________________________________________________________________ Umständen über verteilte Datenbanken in Relation (gejoint) gebracht werden, was eventuell gar nicht möglich wäre, da die Datenstruktur dies gar nicht zulassen würde. Ein verteilter ODS kann allerdings Sinn machen, wenn die einzelnen ODS's als eigene Kategorie (Subject Oriented) bereitgestellt werden. _____________________________________________________________________________ 51 _____________________________________________________________________________ 6.6 Definition Module „Zentralisierte und modulare BI Plattform und Infrastruktur“ Damit die Bedürfnisse und Anforderungen der Kunden in einer standardisierten Form erfüllt werden können, werden Module gebildet. Damit besteht die Möglichkeit, dem Kunden eine optimale und schnelle Lösung zu bieten. Die Module lassen sich wie in einem Baukastensystem untereinander kombinieren und die Projektanforderungen können optimal erfüllt werden. Die einzelnen Module werden aus einer Kombination von technischen und kundenspezifischen Anforderungen abgeleitet. Diese werden wie folgt gebildet: Extraktion (Replikation) Datenhaltung (Aufbewahrung der Daten) Aktualisierung (Jobsteuerung) Transformation Reporting DWH Überführung Abbildung 6.10: Module zu „Zentralisierte und modulare Business Intelligence Plattform und Infrastruktur“ 6.6.1 Extraktion In diesem Modul wird die Extraktion spezifiziert. Der Kunde kann nach seinen Anforderungen aus folgenden Extraktionseigenschaften, die in zwei Kategorien unterteilt sind, auswählen: Datenaspekt: Extraktion 1:1 tailorierte Extraktion Zeitaspekt: Extraktion Real Time Extraktion Near Real Time Extraktion mit definierten Intervall 6.6.1.1 Extraktion 1:1 Mit dieser Option bestimmt der Kunde, dass seine Daten ohne jegliche Strukturänderung und Transformation ins ODS übernommen werden. Dabei kann auch bestimmt werden, ob sämtliche Tabellen einer Datenbank oder nur bestimmte übernommen werden sollen. Mit dieser Option wird nichts bezüglich der Aktualität der Datenübernahme definiert. _____________________________________________________________________________ 52 _____________________________________________________________________________ 6.6.1.2 Extraktion Real Time Bei der Wahl dieser Option bestehen applikatorische Abhängigkeiten betreffend der Aktualität der Daten. Dies bedeutet, dass beim Überschreiten der kritischen zeitlichen Marke, die Applikation schwerwiegende Probleme bekommt. Bei dieser Option werden die Daten schnellst möglich extrahiert. 6.6.1.3 Extraktion Near Real Time Mit dieser Eigenschaft wird spezifiziert in welchem Intervall die Daten übernommen werden sollen. Near Real Time hat im Vergleich zu Real Time ein grösseres Intervall. Dies Variante eignet sich für Applikationen, die in Bezug auf die Aktualität der Daten weniger problemanfällig sind. 6.6.1.4 Extraktion mit definierten Intervall Hier kann der Kunde das gewünschte Intervall definieren. Dabei wird die Jobsteuerung so eingestellt, dass diese den Bedürfnissen des Kunden gemäss den Projektspezifikationen entspricht. 6.6.2 Aktualisierung (Jobsteuerung) Bei der Aktualisierung handelt es sich in erster Linie um die Jobsteuerung. Grundsätzlich kommen dabei zwei unterschiedliche Technologien zum Einsatz. Einerseits mittels Scheduler, der für das Starten der Jobs zum definierten Zeitpunkt verantwortlich ist, andererseits mittels einem Agenten, der dafür sorgt, dass die Daten repliziert werden, sobald diese generiert wurden. 6.6.3 Datenhaltung In diesem Modul werden unterschiedliche Datenaufbewahrungszeiten definiert. Dabei wird zwischen zwei Datentypen unterschieden. temporale Daten Stammdaten datumsbezogene Stammdaten Eine maximale Datenaufbewahrungszeit gilt nur für temporale Daten. Auf die Definition wird später noch genauer eingegangen. Für Stammdaten und datumsbezogene Stammdaten hingegen wird keine maximale Aufbewahrungszeit definiert, da diese in der Regel eher statisch sind und das Datenwachstum begrenzt ist. _____________________________________________________________________________ 53 _____________________________________________________________________________ 6.6.4 Transformation Mit diesem Modul können Transformationen definiert werden. Dies kann von Strukturänderungen bis hin zu Änderungen der Daten alles beinhalten. Zudem ist dieses Modul auch zuständig für eine etwaige Überführung der Daten in ein DWH. 6.6.5 Reporting Zu einer BI Plattform gehört unweigerlich auch mindestens ein Reportingtool. Für die Reports werden nur die Schnittstellen zu den Daten zur Verfügung gestellt. Die nötigen Zugriffe und Berechtigungen müssen aber zwingend geregelt und definiert werden. Darauf wird in einem späteren Kapitel noch näher eingegangen. 6.6.5.1 Abgrenzung zu Reporting Dieses Modul wird hier nicht detailliert behandelt, da der Kunde freie Wahl in Bezug des Reportingtools hat. Durch die enorme Auswahl an Reportingtools, macht eine Eingrenzung der Möglichkeiten keinen Sinn. Schlussendlich ist für die Plattform das entsprechende Statement relevant und nicht durch welches Tool es ausgeführt wird. 6.6.6 DWH Überführung In dieser Arbeit wird nicht genauer auf dieses Modul eingegangen, da der Hauptfokus dieser Arbeit auf der Entlastung der operativen Systeme liegt und da dies von Fall zu Fall genauer angeschaut werden muss. Hier müsste definiert werden, wie und in welcher Form die Daten in das DWH überführt werden sollen. _____________________________________________________________________________ 54 _____________________________________________________________________________ 6.7 Referenzarchitektur Eine Referenzarchitektur soll helfen die Komplexität, durch Zerlegung in einzelne Module, zu verringern. Sie trägt zu einem einheitlichen Verständnis der beteiligten Parteien bei und dient als Basis für das Data Warehousing. Für unsere Arbeit haben wir uns für die Referenzarchitektur von A. Bauer / H. Günzel entschieden. Datenbeschaffungsbereich Auswertebereich Extraktion Datenquelle Laden Arbeitsbereich Laden Basisdatenbank Analyse Data Warehouse Transformation Data Warehouse Manager Metadatenmanager Monitor Repository Datenfluss Kontrollfluss Abbildung 6.11: Referenzarchitektur A. Bauer / H. Günzel: Data Warehouse System _____________________________________________________________________________ 55 _____________________________________________________________________________ 6.8 Lösungsvarianten / mögliche Architekturen Nachfolgend wird gestützt auf verschiedenen Lösungsvarianten, welche auf den Anforderungen basieren, die geeignetste Architektur erarbeitet. 6.8.1 Lösungsvariante 1 BI / ETL Admin 1:1 (CDC) Operatives System ETL DWH ODS po Re ts rts or Rep BI User Abbildung 6.12: Lösungsvariante 1 Motivation: Bei dieser Variante steht der „Keep it simple“ Gedanke im Vordergrund. Es wird bewusst auf eine geringe Komplexität geachtet. Beschreibung: Die Daten werden vom operativen System mittels CDC Technologie extrahiert und unverändert in den ODS überführt. Dies führt zu einem Abbild des operativen Systems. Danach können die Daten aus dem ODS extrahiert, transformiert und in ein DWH geladen werden. Der BI User kann nun für Reports, die einen aktuellen Datenbestand verlangen, auf den ODS oder für Abfragen, die historische Daten benötigen, auf das DWH zugreifen. Der BI / ETL Admin hat die Möglichkeit die CDC und ETL Prozesse anzustossen und gegebenenfalls anzupassen. Vorteile geringe Komplexität hohe Standardisierung schnelle Anbindung der operativen Systeme Applikation muss für bestehende Abfragen nur den Connectstring anpassen Real Time möglich Nachteile geringe Flexibilität Daten liegen im ODS noch nicht in optimaler Datenstruktur vor Anbindung von Systemen, die kein CDC beherrschen wird nicht abgedeckt _____________________________________________________________________________ 56 _____________________________________________________________________________ 6.8.2 Lösungsvariante 2 BI / ETL Admin 1:1 * Operatives System ETL DWH ODS po Re rts s ort Rep * klassische Replikationsmechanismen wie Materialized Views, SQL, ... BI User Abbildung 6.13: Lösungsvariante 2 Motivation: Erweiterung der Variante 1 zur Behebung derer Nachteile. Beschreibung: Diese Variante unterscheidet sich nur geringfügig von der Variante 1. Der Unterschied besteht im Zulassen von klassischen Replikationsmechanismen für die Übermittlung der Daten in den ODS. Bei den „klassischen“ Replikationsmechanismen kommen Technologien wie Materialized Views, SQL Queries, Triggers, uvm. zum Einsatz. [siehe Anhang Semesterarbeit CAS BI 01] Der Aufgabenbereich und die Funktion des BI User und des BI / ETL Admin bleiben unverändert im Vergleich zu Variante 1. Vorteile geringe Komplexität hohe Standardisierung schnelle Anbindung Applikation muss für bestehende Abfragen nur den Connectstring anpassen Real Time möglich Anbindung von Systemen, die kein CDC beherrschen, ist abgedeckt Nachteile Daten liegen im ODS noch nicht in optimaler Datenstruktur vor _____________________________________________________________________________ 57 _____________________________________________________________________________ 6.8.3 Lösungsvariante 3 BI / ETL Admin EL ETL Staging DWH ODS 1-n Rep orts Operatives System T Rep s ort BI User <T=mit oder ohne Transformation> Abbildung 6.14: Lösungsvariante 3 Motivation: Bei dieser Variante kann anders als bei Variante 1 und 2 bereits, beim Laden in den ODS bereits transformiert werden. Dabei kommt eine Staging Area zum Einsatz. Bei dieser Technologie wird keine Middleware verwendet; alles läuft auf dem Zielsystem. Beschreibung: Wie bereits erwähnt werden dabei die Daten vom Quellsystem extrahiert. Bei der Replikation kann die Datenstruktur erhalten bleiben (1:1 Replikation) oder eine tailorierte Replikation (Teilreplikation) durchgeführt werden. Als Replikationsmechanismus kommen sämtliche Technologien in Frage. Dies wird durch die Business Anforderungen entsprechend gesteuert. Die Idee ist ein standardisiertes Verfahren zu implementieren, welches sämtliche Anforderungen (Real Time bis asynchrone Replikation) abdecken kann. Das standardisierte Verfahren hat den Vorteil, dass die Anbindung schnell und einheitlich durchgeführt werden kann. Dabei kann immer nach dem gleichen Muster vorgegangen werden. Auf dem Zielsystem, in diesem Fall dem ODS, wird ein ELT Tool installiert, welches für das Laden und die Transformierung zuständig ist. Die extrahierten Daten werden in eine Staging Area überführt. Diese kann logisch oder physisch sein, abhängig vom eingesetzten ELT Tool und der definierten Transformation. Die Daten können so modelliert werden, wie diese schlussendlich für das Business sinnvollerweise vorliegen sollen. Falls die Daten bereits in der gewünschten Form vorliegen, muss der beschriebene Prozess nicht durchlaufen werden. _____________________________________________________________________________ 58 _____________________________________________________________________________ Die Überführung vom ODS in ein allfälliges DWH wird via ein ELT oder ein allfälliges ETL durchgeführt. Die Zugriffe sind derart geregelt, dass der BI Admin zusammen mit dem BI Entwickler für das Deployen der Transformationen zuständig ist. Zudem ist der BI Admin für das Monitoren der ELund der Transformationsprozesse zuständig. Dem BI End User wird der Zugriff auf die bereitgestellten Daten gewährt. Dies kann auf dem ODS oder einem allfälligen DWH sein. Der Einsatz dieser Technologie hat natürlich Vor- und Nachteile. Diese sind untenstehender Liste zu entnehmen: Vorteile Keine Middleware Einheitliche und schnelle Anbindung Niedrige Kosten: Hardware für Middleware sind nicht notwendig Teure Lizenzen sind begrenzt Teure Connectoren für ETL sind nicht notwendig Daten können im ODS in „abfrageoptimierter“ Form abgelegt werden Real Time möglich Anbindung von Systemen, die kein CDC beherrschen, ist abgedeckt Nachteile Ressourcenverbrauch auf Zielsystem Keine „saubere“ Trennung zwischen Datenbanksystem und ELT Tool Staging Area mit Persistenz notwendig _____________________________________________________________________________ 59 _____________________________________________________________________________ 6.8.4 Lösungsvariante 4 BI / ETL Admin MIDDLEWARE ETL Operatives System ETL DWH ODS 1-n po Re ts rts or Rep BI User Abbildung 6.15: Lösungsvariante 4 Motivation: Diese Variante soll die Anforderungen mittels einer Middleware (ETL) abdecken. Dabei soll mit einem einzigen Tool extrahiert, geladen und transformiert werden. Beschreibung: Mit dieser Variante wird auf das „klassische“ ETL referenziert. Mittels ETL Software werden die ETL Prozesse grösstenteils „deklarativ“ programmiert. Die Middleware ist zuständig für die Anbindung ans Quell- und Zielsystem. Zudem werden dabei je nach Business Anforderungen die Prozesse so modelliert, dass neben der Extraktion und dem Ladeprozess gleichzeitig transformiert werden kann. Dabei kommen die bekannten ETL Funktionen zum Zuge wie Extrahieren, Transformieren und Laden. Die Staging Area wird implizit durch die Middleware in Form eines Memorybereiches des ETL Tool bereitgestellt. Die Middleware wird in der Regel auf ein separates System installiert, auf welchem auch die Metadaten der ETL Prozesse generiert werden. Die Metadaten werden normalerweise in einer Datenbank abgespeichert. Diese kann sowohl auf dem gleichen System wie das ETL Tool, als auch auf einem anderen System liegen. Das Weiterreichen der Daten an weitere Systeme wie ein DWH wird ebenfalls mittels Middleware realisiert. Dabei können die Daten weiter verarbeitet werden. Zum Beispiel durch Aggregation oder andere ETL Funktionen. Der BI Admin agiert direkt auf der Middleware. Dies kann mittels Web-GUI oder Fat Client geschehen. Dabei wird für die jeweiligen Projekte ein Repository angelegt, auf welchem die Metadaten der ETL Prozesse logisch abgebildet werden. _____________________________________________________________________________ 60 _____________________________________________________________________________ Der BI End User greift mittels Reporting Tool direkt auf den ODS zu. Die Zugriffe werden in der Regel entweder mittels Reporting Tool oder direkt auf der Datenbank geregelt. Auch diese Variante weist Vor- und Nachteile auf: Vorteile Sigle Point of Action einzelnes und einheitliches Tool Je nach Produkt kann die Middleware um weitere Optionen erweitert werden (z.B. Data Quality, u.v.a) Metadaten Management geregelt zentrale Überwachung Nachteile Konnektoren für jeweilige Quell- und Zielsystem notwendig zusätzliches System notwendig teure Third Party SW Lizenzen Lock In zu SW Lieferant ETL Prozesse nicht portierbar auf Konkurrenzprodukte Höhere Belastung des operativen Systems als bei Variante 3 _____________________________________________________________________________ 61 _____________________________________________________________________________ 6.9 Gegenüberstellung der Lösungsvarianten zu den Muss und Kann Kriterien In diesem Kapitel soll aufgezeigt werden, welche Lösungsvariante die meisten Muss und Kann Kriterien abdeckt und sich daher am besten eignet. Dabei werden die Kriterien mittels einem Punktesystem gewichtet. Je nach Erfüllungsgrad wird höher oder tiefer bewertet. Die Skala der Punktevergabe sieht wie folgt aus: Erfüllt: Teilweise erfüllt: Nicht erfüllt: 2 Punkte 1 Punkte (z.B.: durch Einsatz von kostenpflichtigen Optionen) 0 Punkte Nr. Kriterien DI1 Real Time resp. Near Real Time Datenreplikation möglich Verschiedenste Datenquellen müssen angebunden werden können (analog heutiger Situation) Aufbau einer separaten zentralen Plattform für Aggregation und Bereitstellung der Daten L1 L2 L3 L4 X 2 2 2 1 X 2 2 2 2 X 2 2 2 2 X 2 2 2 2 PL3 Der Zugriff auf die Daten ist nicht Protokoll gebunden Daten sind während 3 Monaten verfügbar X 2 2 2 2 PL7 Anbinden von Oracle RDBMS X 2 2 2 2 PL15 Die Plattform ist so dimensioniert, dass Lastspitzen keine Probleme darstellen. X 2 2 2 2 PL16 Die neue Plattform erfüllt mindestens die SLA Anforderungen der Quellsysteme. X 2 2 2 2 PL18 Die Plattform kann mindestens 20 ConcurrentUser bewältigen, welche Standardreports ausführen. PE3 Zu verarbeitendes Transaktionsvolumen: tiefes Transaktionsvolumen (1-2 Millionen Transaktionen pro Tag à 1KB) X 2 2 2 2 X 2 2 2 2 PE2 Zu verarbeitendes Transaktionsvolumen: mittleres Transaktionsvolumen (2-5 Millionen Transaktionen pro Tag à 1KB) X 2 2 2 2 PE4 Die Datenmodellierung ist auf Performance ausgerichtet Es sind definierte Integrations-Prozesse vorhanden. Erstellen von allgemein gültigen Richtlinien und Standards zu Datenintegrationen X 0 1 2 2 X 2 2 2 2 X 2 2 2 2 0 1 2 2 DI2 PL1 PL2 PZ1 PZ2 DI3 Daten werden bei Integration in eine gemeinsame einheitliche Datenstruktur überführt Muss Kann X _____________________________________________________________________________ 62 _____________________________________________________________________________ Nr. Kriterien Muss Kann L1 L2 L3 L4 DI4 Unregelmässige Ad Hoc Datenintegration möglich X 0 1 2 2 DI5 Denormalisieren der Daten bei Anbindung X 0 1 2 2 PL4 Daten sind während 12 Monaten verfügbar X 2 2 2 2 PL5 Daten sind während >12 Monaten verfügbar X 2 2 2 2 PL6 Schnelle, einfach Anbindung X 1 1 1 1 PL8 Anbinden von MySQL X 2 2 2 2 PL9 Anbinden von MSSQL X 2 2 2 2 PL10 Anbinden von Flatfiles, XML X 2 2 2 2 PL11 Der Zugriff mit bestehenden Tools ist weiterhin möglich PL12 Es werden multidimensionale Auswertungen unterstützt. PL13 Die Auswertungen können mittels Scheduler sowie anschliessendem Mailversand erstellt werden. PL14 Durch den Einsatz bewährter Technologien, wird eine hohe Stabilität und Robustheit des Systems gewährleistet. PL17 Das System kann sowohl als Target wie auch als Source verwendet werden. X 2 2 2 2 X 2 2 2 2 X 2 2 2 2 X 2 1 2 2 X 2 2 2 2 PL19 Die Plattform kann mindestens 50 ConcurrentUser bewältigen, welche Standardreports ausführen. PL20 Die Plattform kann mindestens 100 ConcurrentUser bewältigen, welche Standardreports ausführen. PE1 Zu verarbeitendes Transaktionsvolumen: hohes Transaktionsvolumen (5-6 Millionen Transaktionen pro Tag à 1KB) X 2 2 2 2 X 2 2 2 2 X 2 2 2 2 SK1 System muss bei Bedarf skalierbar sein (on demand) Das System ist horizontal wie auch vertikal skalierbar Die Wiederverwendbarkeit der Daten ist gewährleistet. Die Daten sind veränderbar. X 2 2 2 2 X 2 2 2 2 X 2 2 2 2 X 2 2 2 2 Die neue Lösung ist günstiger als eine Einzellösung. X 2 2 2 1 63 66 71 69 SK2 FL1 FL2 KS1 Total: Nach Auswertung der Punktevergabe hat sich ergeben, dass die Lösungsvariante 3 sich am besten eignet. Bei dieser Entscheidung wurden die Kosten nicht abschliessend berücksichtigt. Hauptaugenmerk wurde auf die Funktionalitäten gelegt. Alle Lösungsvarianten verursachen Mehrkosten, hier gilt es mittels Wirtschaftlichkeitsrechnung heraus zu finden, wie hoch diese sein werden und welchen _____________________________________________________________________________ 63 _____________________________________________________________________________ quantifizierbaren Mehrwert daraus geschlagen werden kann. In der dargestellten Bewertung werden lediglich die Lizenz- und Wartungskosten berücksichtigt. Durch allfällige Veränderungen der strategischen Ausrichtung bei IT Post und neuen Lizenzvereinbarungen kann oben formulierter Entscheid beeinflusst werden. _____________________________________________________________________________ 64 _____________________________________________________________________________ 6.10 Definition Ziel Architektur „Zentralisierte und modulare Business Intelligence Infrastruktur und Plattform“ Nachfolgend wird die Lösungsvariante 3, die sich als beste Lösung heraus gestellt hat, in ihre Einzelteile zerlegt. Somit können die verschiedenen Komponenten eruiert und allfällige Probleme früh erkannt und angegangen werden. Zusätzlich wird auch die dafür notwendige Hardware definiert. 6.10.1 Use Case Modell Systemarchitektur In diesem Kapitel wird mittels UML auf die Systemarchitektur eingegangen. Dabei werden die unterschiedlichen Komponenten näher betrachtet. 6.10.1.1 Zentrale Komponenten Die zentralen Komponenten zeigen gleichzeitig auch die Grobarchitektur der Lösungsvariante 3. Folgende 3 Hauptkomponenten sind ersichtlich: die zu entlastenden operativen Datenbanken das ETL / ELT Environment, das für die Datenreplikation sowie die Transformation zuständig ist das ODS, in das schlussendlich die Daten ausgelagert werden Abbildung 6.16: Komponente Zentrale Komponenten _____________________________________________________________________________ 65 _____________________________________________________________________________ 6.10.1.2 Operative Datenbanken Hier werden die Standardkomponenten bei den operativen Datenbanken aufgezeigt. Dies spiegelt die bestehende Situation wider. In der Regel wird ein Server benötigt, um die Datenbank als Software Komponenten zu verwalten. Die Datenbank ist vom Server als Hardwarekomponente abhängig. Die Hardwarekomponente ist so auszulegen, dass diese den Business Anforderungen und den daraus resultierenden SLAs standhält. Abbildung 6.17: Komponente Operative Datenbanken 6.10.1.3 ETL / ELT Environment Dieser Teil ist das Herzstück der gesamten Plattform. Im Vordergrund steht die Komponente „ETL / ELT Environment“. Abgebildet wird diese zwar als Einheit, in Wirklichkeit besteht sie aber aus mehreren Teilkomponenten, namentlich einer Extraktions-, einer Transformations- und einer Ladekomponente. Der Einfachheit halber werden diese ETL / ELT Komponenten als Ganzes betrachtet. Die ETL / ELT Komponente wird dabei als Software klassifiziert und ist von der Softwarekomponente Datenbank und von der Hardwarekomponente Server abhängig. Abbildung 6.18: Komponente ETL / ELT Environment _____________________________________________________________________________ 66 _____________________________________________________________________________ 6.10.1.4 Operational Data Store (ODS) Beim Operational Data Store handelt es sich um diejenige Komponente, welche die extrahierten Daten persistiert. Hierbei sehen die Komponenten analog der operativen Datenbanken aus. Sie besteht aus einer Softwarekomponente für die Datenbank und eine Hardwarekomponente für den Server. Abbildung 6.19: Komponente ODS _____________________________________________________________________________ 67 _____________________________________________________________________________ 6.10.1.5 Use Case „Zentralisierte und modulare Business Intelligence Infrastruktur und Plattform“ In diesem Model werden die Use Cases, welche für die ETL / ELT Aktivitäten zuständig sind in die Hauptkomponente „Zentralisierte und modulare Business Intelligence Infrastruktur und Plattform“ eingebettet. Die Use Cases aus Sicht des BI End User werden nicht abgebildet, da diese Use Cases mittels Reportingkomponente realisiert werden. Diese ist jedoch nicht Bestandteil der zu realisierenden Plattform. Abbildung 6.20: Use Case „Zentralisierte und modulare Business Intelligence Plattform und Infrastruktur“ 6.10.1.6 Sequenzdiagramm der Komponenten Mit dem Sequenzdiagramm wird aufgezeigt, wie die beschriebenen Komponenten miteinander interagieren. Dieses Diagramm zeigt die Interaktion auf der obersten Ebene. Der Ausgangspunkt ist die ETL / ELT Komponente, welche sich benötigte Daten von den operativen Datenbanken holt und diese weiter verarbeitet. Die verarbeiteten Daten werden anschliessend im Operational Data Store abgespeichert und zur Verfügung gestellt. Abbildung 6.21: Sequenzdiagramm der Komponenten _____________________________________________________________________________ 68 _____________________________________________________________________________ 6.10.1.7 Sequenzdiagramm Use Case 5 Der Use Case 5 wird speziell behandelt, da mit der Aktion des Use Case 5, Daten eingefügt werden. Dabei soll das Einfügen ohne ETL / ELT möglich sein, soll heissen mittels einer Third Party Applikation oder via „inserts“ direkt in der Datenbank. Daher ist im Sequenzdiagramm nur die Interaktion zwischen BI Admin / Entwickler und dem ODS, ohne den Einsatz von Komponenten der Zentralisierten und modularen BI Plattform und Infrastruktur, abgebildet. Abbildung 6.22: Sequenzdiagramm Use Case 5 _____________________________________________________________________________ 69 _____________________________________________________________________________ 6.10.1.8 Sequenzdiagramm Use Case 6,7,8,9,10 und 11 In diesem Sequenzdiagramm werden die Aktionen der Use Cases 6,7,8,9,10 und 11 abgebildet. Hier eine nochmalige Auflistung der entsprechenden Use Cases: UC 6: Daten mutieren (Aktionen via ETL / ELT Environment) UC 7: Daten löschen (Aktionen via ETL / ELT Environment ) UC 8: Lade Prozeduren anstossen (Aktionen via ETL / ELT Environment ) UC 9: Daten Consumer anbinden UC 10: Daten Provider anbinden UC 11: Daten Transformieren Die Interaktion wird vom BI Plattform Admin oder Entwickler angestossen. Dabei werden sequentiell ein oder mehrere der obengenannten Use Cases angestossen. Abbildung 6.23: Sequenzdiagramm Use Case 6,7,8,9,10 und 11 6.10.1.9 Sequenzdiagramm Use Case 1,2,3 und 4 Für die Use Cases 1 bis 4 wurden keine Sequenzdiagramme erstellt, da diese Use Cases die fachliche Seite im Sinne von Erstellung von Reports beschreiben. Diese Arbeit befasst sich hauptsächlich mit der Überführung der Daten von den operativen Datenbanken zu derer Entlastung und daher werden die Use Cases 1 bis 4 in diesem Sinne nicht weiter behandelt. _____________________________________________________________________________ 70 _____________________________________________________________________________ 6.10.2 Infrastrukturkomponenten Im Folgendem wird die Infrastruktur der Lösungsvariante 3 konkretisiert. Dabei sollen die Hardware- und Basissoftwarekomponenten erläutert und definiert. 6.10.2.1 Architektur der Infrastrukturkomponenten Ein Ziel der Plattform ist es bei Bedarf zu skalieren. Damit ist es möglich auf eine einfache Art und Weise Ressourcen zu erweitern. Die Thematik Skalierbarkeit wurde bereits im Kapitel 6.4.25 erläutert. Ein weiterer Aspekt der Skalierung ist, dass keine exorbitanten Kosten verursacht werden. Die Plattform muss so kostengünstig wie möglich aufgebaut werden. Nur damit ist eine solche Plattform zu rechtifertigen. Um die Kosten niedrig zu halten, wird diese Plattform mit Standardservern, die bei der Schweizerischen Post eingesetzt werden, aufgebaut. Die zentrale Datenbank, der Operational Data Store (ODS), wird auf Basis einer Oracle Datenbank aufgebaut. Dies aus folgenden Gründen: Sehr gute Handhabung von grossen Datenbanken (Partitioning, Storage Management, uvm.) Sehr gutes Know-how bei IT Post Sehr gute Hochverfügbarkeitstechnologien Sehr gute Skalierungstechnologien Sehr gute Recoverytechnologien Sehr gute Lizenzierungsmodalitäten bei der Schweizerischen Post Der Disk Storage wird aus der Zentralen Datenhaltung (ZDH) bezogen, die aus mehreren zentralen SAN Storage Systemen besteht. Die Netzwerkinfrastruktur, welche die verteilte Datenbankarchitektur miteinander verbindet, wird aus der zentralen Netzwerk Infrastruktur P-MAN (Post Metropolitan Area Network) bezogen. Die BI Plattform wird auf derselben Hardware wie der ODS betrieben. Somit entfällt eine teure Middleware Plattform. Die detaillierte Beschreibung dazu folgt in den nachfolgenden Kapiteln. Die SLAs, welche in Zusammenarbeit mit den Kunden definiert wurden, müssen eingehalten werden. Da mit diesem Konzept eine zentrale Plattform aufgebaut wird, gilt es die höchste SLA Definition abzudecken. Sämtliche Hardwarekomponenten müssen auf diese SLAs abgestimmt werden, damit bei einem allfälligen Systemausfalls, die definierten Ausfallzeiten eingehalten werden können. Die Plattform ist nach dem oben Gesagten redundant aufzubauen. Dies betrifft sämtliche Komponenten der Plattform. Aus Kostengründen wird in einer ersten Phase auf die vertikale Skalierung gesetzt, die in späteren Phasen in eine horizontale Skalierung überführt werden kann. Dies bedeutet, dass zunächst eine kleine kostengünstige Plattform aufgebaut wird, die in Zukunft entsprechend den erhobenen Anforderungen ausgebaut werden kann. Dies ermöglicht uns gleich von Beginn an dem Kunden eine attraktive, kostengünstige und zentrale Lösung zur Verfügung zu stellen. _____________________________________________________________________________ 71 _____________________________________________________________________________ Die „anfängliche“ Hardware Architektur sieht wie folgt aus: Umsysteme BI End User XML Gateway Application Server aktiv ETL Environment passiv Log Shipping ODS ODS Hot Standby Abbildung 6.24: „anfängliches“ System Wenn die „anfängliche“ vertikale Skalierung ausgeschöpft ist, wird mittels Clustering horizontal weiter skaliert. Dabei muss das „zukünftige“ System mittels Cluster Software um weitere Knoten (Server) erweitert werden. In dieser Phase wird nicht die „Aktiv / Aktiv“ Variante mittels Grid Computing angestrebt, sondern der Fokus wird lediglich auf die Hardwareerweiterung gelegt. Hierfür können die Server gruppiert werden, so dass diese nur für spezifischen Applikationen zur Verfügung stehen. Wie bereits erwähnt, besteht bei der Konfiguration dieser Architektur keine Möglichkeit die Server im „Aktiv / Aktiv“ Modus zu betreiben. Somit ist ein Workload Balancing für die Applikationen nicht möglich. Jedoch kann diese Architektur ohne grössere Probleme soweit ausgebaut werden, dass diese im „Aktiv / Aktiv“ Modus arbeiten könnte. Diese Ausbauphase wäre die dritte Ausbaumöglichkeit womit man schlussendlich beim Grid Computing angelangt wäre. Beim Grid Computing und dem entsprechenden „Aktiv / Aktiv“ Modus wird via dem Cluster Interconnect das Memory geshared. Nur so ist es möglich gleichzeitig obengenannten Modus zu betreiben. Hierbei werden die Datenblöcke aus dem jeweiligen Memory Bereich eines Servers auf den anderen übertragen. Dieser Mechanismus kann allerdings auch zu Problemen führen, wenn Datenblöcke zu häufig gebraucht werden. Dies führt zu Performanceproblemen, weil die benötigten Blöcke immer wieder hin und her geschoben werden müssen. Um dieses Phänomen zu unterbinden sind applikatorische sowie datenbanktechnische Adaptierungen notwendig. _____________________________________________________________________________ 72 _____________________________________________________________________________ Umsysteme BI End User Application Server XML Gateway ETL Environment ODS Cluster 1 ODS Cluster 2 ODS Hot Standby Gruppe 3 ODS Gruppe 2 Gruppe 3 Log Shipping Log Shipping Gruppe 2 ODS ODS Hot Standby ODS ODS Hot Standby Gruppe 1 Gruppe 1 Log Shipping Abbildung 6.25: „zukünftiges“ System 6.10.2.2 Server In diesem Kapitel soll die zugrunde liegende Hardware näher beleuchtet werden. In unserem Fall handelt es sich um Low End Server der Firma Hewlett Packard (HP). Diese bilden die Basis für den Aufbau der Plattform. Die angedachten Server gehören zur Blade Architektur. Blade Server werden in Blade Racks als Server Batterien verbaut. Dies bewirkt eine kompakte Verbauung und demzufolge eine Konsolidierung von Server Räumen. Zudem ermöglicht das Erstellen von Server Profilen eine einfachere Handhabung des Hardware Lifecycle. Wie bereits beschrieben wird nicht gleich von Anfang an die definitive Plattform aufgebaut, um insbesondere eine „Kostenexplosion“ zu vermeiden. Die Plattform soll den Bedürfnissen entsprechend wachsen können. Angaben zum Server: Typ HP Blade DL465 CPU AMD mit 2 CPU und 12 Core, 2,56 Ghz Memory Bis 256 Gb NIC 4 Ports mit bis zu 10 Gbit/s geshared – FCoE für SAN Storage Anbindung OS SuSE SLES 11 SP1 _____________________________________________________________________________ 73 _____________________________________________________________________________ 6.10.2.3 Datenbank Als Standard Datenbank wird die RDBMS von Oracle eingesetzt. Oracle als einer der führenden RDBMS Lieferanten, deckt sämtliche Anforderungen an ein RDBMS bei der Schweizerischen Post ab. Wie bereits beschrieben wird das Oracle RDBMS aus folgenden Gründen eingesetzt: Sehr gute Handhabung von grossen Datenbanken (Partitioning, Storage Management, uvm.) Sehr gutes Know-how bei IT Post Sehr gute Hochverfügbarkeitstechnologien Sehr gute Skalierungstechnologien Sehr gute Recoverytechnologien Sehr gute Lizenzierungsmodalitäten bei der Schweizerischen Post Aus technischer Sicht sticht das Argument „Very Large Database“ (VLDB) hervor, wenn man davon ausgeht, dass man sich bei diesem Unterfangen, mit sehr grossen Datenmengen auseinander zu setzen hat. Oracle bietet diesbezüglich sehr gute Funktionen. Hier ein kleiner Auszug von nutzvollen Oracle RDBMS Features im DWH Bereich: Partitioning (add, split, drop, exchange) Ermöglicht grosse Datenbank Objekte (32 TB mit 8k und 64 TB mit 16k Blocksize) Gute Lade und Entlade Funktionen (Export / Import, Data Pump, SQL*Loader, uvm.) Materialized View Tabellen Kompression (ermöglich das Einsparen von Disk Space) Pivot und Unpivot Operatoren LOB (Large Object) Management Einige Eckdaten des eingesetzten RDBMS: RDBMS Oracle Enterprise Edition (EE) 11.2.0.x Optionen: Partitioning Advanced Compression Oracle Text Java Option XML DB Funktion Partitionieren von Tabellen und Indexes Komprimieren von Tabellen, ermöglicht Disk Space Einsparung und Performancegewinn Erlaubt mittels Indexierung des Dateninhaltes eine Volltext Suche Erlaubt das Einbinden von Java Programmen in die Datenbank Erlaubt das Einbinden von XML Strukturen Bei der Schweizerischen Post werden weitere RDBMS betrieben, wie zum Beispiel MS SQL Server, MySQL oder PostgreSQL. MS SQL Server Datenbanken werden immer häufiger eingesetzt und gewinnen an Bedeutung, mit diesen Datenbanken werden aber eher kleine Applikationen betrieben. Bei der Schweizerischen Post wurden bis heute keine DWHs mit MS SQL Server realisiert. Die RDBMS MySQL und PostgreSQL werden momentan noch in reduzierter Form betrieben. _____________________________________________________________________________ 74 _____________________________________________________________________________ 6.10.2.4 Storage Eine grosse Datenbank benötigt auch einen grossen Disk Space. Dieser Aspekt muss vor dem Aufbau einer solchen Plattform berücksichtigt werden, um eine optimale Flexibilität beim Ausbau der Plattform zu gewährleisten oder etwaige Performanceprobleme im Zusammenhang mit Disk I/O zu vermeiden. Unweigerlich stellt sich die Frage, auf welchem Filesystem die Datenbankdateien abgelegt werden sollen. Hierfür besteht eine Vielzahl an Filesystemen, die für Datenbankdateien mehr oder weniger geeignet sind. Für unsere Plattform wird ein Disk Volume Manager eingesetzt. Die Aufgabe eines Disk Volume Managers ist das Verwalten der „rohen“ Disks oder der Logical Unit Number (LUN). Mittels Disk Volume Manager werden die „rohen“ Disks in logische Einheiten aufgeteilt und mit einem Stripe Size versehen. Die Stripe Size ist diejenige Grösseneinheit, welche auf jeder Disk oder LUN sequentiell geschrieben wird. Dieses Verteilen schliesst sogenannte Hot Disks aus, das heisst die Disks, resp. LUNs werden alle im gleichem Masse belastet. Zusätzlich wird durch das Verteilen eine höhere I/O Bandbreite erreicht, was zu einer Performancesteigerung im I/O Bereich führt. Abbildung 6.26: Disk Striping Der Disk Volume Manager hat zudem den Vorteil, dass Operationen im Bereich Storage Management „online“ durchgeführt werden können. Dies ist von enormer Wichtigkeit, wenn Systeme im 7x 24 Modus betrieben werden müssen. Disk Volume Manager haben weitere Vorteile: Online Ein- und Ausbinden von LUNs Automatisches Rebalancing der Diskgruppen beim Hinzufügen oder Löschen von LUNs Einsatz von Ausfall Gruppen (Host based Mirror) Einfache Migration von Diskgruppen auf neue Server Backup und Restore der Disk Volume Managers Metadaten Eckdaten des Disk Volume Manager: Produkt Oracle Automatic Storage Management (ASM) 11.2.0.x Diskgruppen Bis zu 64 Verwaltbare Grösse Bis zu 140 Petabyte per File _____________________________________________________________________________ 75 _____________________________________________________________________________ 6.10.2.5 Netzwerk Das Netzwerk ist bei verteilten Datenbanken eine der wichtigsten Komponenten. Diese ermöglicht den Datenaustausch der Datenbanken untereinander. Es ist speziell darauf zu achten, dass die Bandbreite des Netzwerkes gross genug dimensioniert ist, damit sehr umfangreiche Datenmengen bewältigt werden können. Eine hohe Bandbreite ist dann sichergestellt, wenn sämtliche Komponenten in einem Netzwerkverbund (Netzwerkadapter, Switch, Router) die erforderlichen Durchsätze garantieren. Heutzutage sind Komponenten, die eine Bandbreite von 1 Gbit/s oder höher erlauben, standardmässig in den meisten Servern oder Netzwerkkomponenten verbaut. Eckdaten der geforderten Netzwerkbandbreite: NIC >= 1Gbit/s (i.d.R. 1 Gbit/s) Switches >= 1Gbit/s (i.d.R. 10 Gbit/s) Router >= 1Gbit/s (i.d.R. 10 Gbit/s) _____________________________________________________________________________ 76 _____________________________________________________________________________ 6.10.3 Definition BI Plattform Im Weiteren wird auf die Definition der BI Plattform detailliert eingegangen. Dabei werden die relevanten BI Komponenten erläutert und definiert. 6.10.3.1 Tag 1 zu Tag n Phänomen Beim Aufbau einer BI Plattform ist es nicht möglich alles auf einmal aufzubauen, da die Kosten und der Ressourcenbedarf zu hoch wären. Daher werden zunächst nur die notwendigen Komponenten realisiert und in späteren Schritten weiter ausgebaut. Das „Tag 1 zu Tag n Phänomen“ dient hierbei natürlich nur als Veranschaulichung. In der Realität verläuft diese Phase über eine längere Zeitperiode. Die nachfolgende Grafik zeigt auf, wie sich dieses Phänomen verhält: Tag 1: Es existieren nur operative Systeme. Sämtliche analytische Operationen und Reporting werden direkt auf diesen Systemen realisiert. Existierende Systeme Tag 2: Es wird das erste DWH realisiert. Die ersten End User greifen zu und führen analytische Operationen und Reporting durch. DWH End User Existierende Systeme Tag 3: Es entstehen weitere „subject oriented“ DWHs. Die Anzahl an End User steigt. Analytische Operation und Reporting werden auf diesen ausgeführt. DWH Existierende Systeme DWH DWH Tag 4: Durch die steigende Datenmenge und Anzahl User werden Bereichsdaten in Data Marts abgebildet oder sie werden mittels OLAP Tools analysiert. Existierende Systeme End User End User End User DWH End User DWH End User DWH End User _____________________________________________________________________________ 77 _____________________________________________________________________________ Tag n: Am Tag n müssen multidimensionale Datenmodelle Abhilfe schaffen. Das System wird schnell und kostengünstig. Die BI Plattform ist zu Ende ausgebaut. End User End User DWH End User End User DWH Existierende Systeme End User DWH End User End User 6.10.4 BI Plattform Architektur Wie anhand des „Tag 1 zu Tag n Phänomen“ dargestellt, wird in diesem Unterfangen nicht eine „voll“ ausgebaute BI Plattform realisiert. Es wird lediglich die erste Stufe bis zum ODS realisiert. Dieser Umstand hindert jedoch nicht künftige Ausbauten bis hin zu einem etwaigen DWH zu erstellen. Unsere BI Plattform Architektur wurde bereits im Kapitel „Lösungsvariante / Mögliche Architekturen„ definiert, beschrieben und bewertet. Die Lösungsvariante 3 erfüllt die Bedürfnisse der Stakeholder am besten. Die Spezifikationen der Lösung wird in diesem Kapitel detailliert beschrieben. Wie bereits in der Problemstellung beschrieben, verfolgen wir das primäre Ziel der Entlastung der operativen Datenbanken. Dies heisst, dass wir uns in dieser Phase, lediglich auf die Datenbewegungen und Transformationen bis ins ODS fokussieren (roter Kreis in Abb. 6.27). Diese Lösung gilt als EL-T Lösung. Transformiert wird erst nachdem die Daten geladen wurden. BI / ETL Admin EL ETL Staging DWH ODS 1-n Rep orts Operatives System T Rep s ort BI User Abbildung 6.27: Architektur Lösungsvariante 3 _____________________________________________________________________________ 78 _____________________________________________________________________________ 6.10.4.1 Softwarekomponenten Die BI Plattform umfasst diverse Softwarekomponenten. So gibt es nebst der Datenbank als Hauptkomponente noch die Extraktions-, Lade- und Transformationskomponente. Zusätzlich kommen noch Aspekte der Verfügbarkeit, Sicherheit und Skalierbarkeit hinzu. 6.10.4.1.1 Datenbankkomponenten Die Datenbankkomponente in der BI Plattform wird hauptsächlich für das Metadaten Management des ELT Tool und derer Transformationsprozesse eingesetzt. Auf die Staging Area und den ODS wird in diesem Kapitel nicht weiter eingegangen. Dies wurde im Kapitel Infrastrukturkomponenten bereits erläutert. Hier die Eckdaten der Datenbankkomponente: RDBMS Oracle Enterprise Edition (EE) 11.2.0.x OS SuSE SLES 11 SP1 6.10.4.1.2 Extraktionskomponente Als primäre Extraktionskomponente wird das Oracle Produkt Goldengate eingesetzt. Dies ist ein sehr schlankes und effizientes Tool, das die CDC Technologie nutzt, um Daten von A nach B zu transferieren. Durch die aktuellen Vertragsbedingungen der Post mit Oracle, sind für dieses Tool keine weiteren Lizenzkosten zu erwarten. Durch die Wahl der Extraktionskomponente Oracle Goldengate können sämtliche geforderten Datenbanksysteme mittels einem Tool angebunden werden. Dieser Umstand führt nebst den bereits erläuterten technologischen und kommerziellen Gründen dazu, dass eine starke Standardisierung bei der Extraktion der Daten vorgenommen werden kann. Im Rahmen unserer Semesterarbeit haben wir uns schon ausführlich mit diesem Tool auseinander gesetzt. Dabei konnten wir bereits erste Erfahrungen mit der Real Time Funktionalität von Goldengate sammeln. Folgende Hauptkomponenten von Oracle Goldengate, sind als Hintergrundprozesse vorhanden: Extract Data Pump Replicat Trail oder Extract Files Manager Collector _____________________________________________________________________________ 79 _____________________________________________________________________________ Folgende Quellen können mittels Oracle Goldengate angebunden werden: Oracle RDMBS MS SQL Server DB2 MySQL Sybase Teradata Flat Files Die Architektur von Oracle Goldengate sieht wie folgt aus: Abbildung 6.28: Oracle Goldengate Architektur Eckdaten der Extraktionskomponente: Software Oracle Goldengate 11.1.1.x 6.10.4.1.3 Ladekomponente Als Ladekomponente wird dasselbe Tool wie bei der Extraktionskomponente eingesetzt. Hierbei ist zu beachten, dass bei einer 1:1 Übernahme der Daten die Staging Area übersprungen werden kann. Die Architektur ist analog der Extraktionskomponente aufgebaut. Eckdaten der Ladekomponente: Software Oracle Goldengate 11.1.1.1.x _____________________________________________________________________________ 80 _____________________________________________________________________________ 6.10.4.1.4 Transformationskomponente Mit der Transformationskomponente bringt der BI Admin die Daten in die gewünschte Form nach der Spezifikation des Entwicklers oder des Fachdienstes. Wie in der Lösungsvariante 3 ersichtlich ist, liegt die Transformationskomponente nicht als Middleware vor. Die Transformationskomponente wird direkt auf dem Server installiert, auf welchem sich auch der ODS befindet. Wie bereits erwähnt, handelt es sich um eine ELT Lösung, und gibt uns die Flexibilität neben der 1:1 Datenübernahme, die keine Transformation benötigt, zusätzlich noch zu transformieren. Die Transformation wird mittels Oracle Data Integrator und Oracle Goldengate realisiert. Letzteres wird für kleine, nicht komplexe Transformationen eingesetzt. Oracle Data Integrator wird für alle weiteren Transformationsschritte eingesetzt. Der Entscheid ODI einzusetzen basiert auf folgenden Überlegungen und ist nur für diese Arbeit gültig. Gründe dafür sind: Aktuelle Lizenzvereinbarungen Evaluieren eines ELT Tools Möglicher Nachfolger für heute eingesetzte ELT Tools wie z.B. Oracle Warehouse Builder „horizonterweiterung“ Prinzipiell können auch andere bereits eingesetzte Tools verwendet werden. Die grobe Architektur von Oracle Data Integrator besteht aus folgenden Komponenten: Repositories User Interface (GUI) Desing-time Projects Runtime Agents Übersicht über die Oracle Data Integrator Architektur: Entwicklung User Interface Topology / Security Administrators Design-time Repository Metadata / Rules Entwickler User Interface Legacy Code Execution Log Agent Data Flow Conductor Execution Return Code DWH Flat/XML ESB Produktion Topology / Security Administrators Operator Entwicklung CRM Runtime Repository Execution Log Produktion CRM Code Execution Log Agent Data Flow Conductor Execution DWH Legacy Return Code Thin Client Business Users Metadata Lineage Metadata Navigator ESB Flat/XML Abbildung 6.29: ODI Architektur _____________________________________________________________________________ 81 _____________________________________________________________________________ Eckdaten der Transformationskomponente: Software Oracle Data Integrator 11.1.1.5.0 Oracle Goldengate 11.1.1.1.0 6.10.4.1.5 Reportingkomponente Bei der Wahl der Reportingkomponente lassen wir dem BI User sämtliche Freiheiten. Hierbei können sämtliche Tools, die sich gegen eine Oracle Datenbank verbinden können, eingesetzt werden. Bei der Schweizerischen Post werden in der Regel folgende Tools verwendet: Quest Toad Quest Toad for Data Analyst Microsoft Excel SAP Business Objects (Reporting und OLAP) Jasper Report Die Liste der Produkte ist nicht abschliessend, wie bereits erwähnt werden hier keine Einschränkungen definiert. _____________________________________________________________________________ 82 _____________________________________________________________________________ 6.10.5 ODS-Organisation Eine besondere Schwierigkeit stellt die Gruppierung der Daten dar. Dabei stellen sich folgende Fragen: Soll für die Daten im ODS pro Quellsystem ein eigenes Schema erstellt werden oder alles in einem einzigen Schema abgelegt werden? Welche Daten machen zusammen Sinn, bzw. sind zusammen zu fassen? Hier wird erläutert, wie im ODS mit den Daten aus den operativen Systemen umgegangen werden soll. 6.10.5.1 Subject oriented Damit man nicht eine wahllose Sammlung an Daten hat, empfiehlt es sich den ODS zu organisieren. Der von uns verwendetet Ansatz ist „Subject oriented“. Zunächst sind die Daten den entsprechenden Konzernbereichen zuzuordnen. In unserem Fall bilden wir dafür Datenbank Schema für die jeweiligen Postbereiche. Das Modell sieht wie folgt aus: DB3 DB4 DB2 Roles Reporting Tool BI_APPL_1 Reporting Tool Roles DB3 DB4 DB5 BI_APPL_2 Subject Oriented Gruppe 3 DB2 DB1 Subject Oriented Gruppe 2 DB1 Subject Oriented Gruppe 1 ODS Roles Reporting Tool BI_APPL_3 DB5 Abbildung 6.30: Subject oriented Konzept Mit diesem Ansatz bewahren wir uns eine gewisse Flexibilität im Falle einer Datenmigration. _____________________________________________________________________________ 83 _____________________________________________________________________________ 6.10.5.2 Zugriffsrichtlinie Bei den in den ODS geladenen Daten gibt es für jedes Quellsystem ein eigenes Datenbank Schema. Um den „Subject Oriented“ Gedanken trotzdem aufrecht zu erhalten, werden diverse übergeordnete Schemas für den Zugriff erstellt. Daten Fachbereich PM Daten Fachbereich PL Daten Fachbereich XY DBA Schnittstellen User BI User BI / ETL Admin C, R, U, D Appl Owner PM C, R, U, D Appl Owner PL R(*) Appl Owner XY R(*) C, R, U, D R R C, R, U, D R R C, R, U, D R(*) C, R, U, D R(*) C, R, U, D R R C, R, U, D R(*) R(*) C, R, U, D Legende: C=Create, R=Read, U=Update, D=Delete (*) mit Bewilligung des Datenherrs Zugriffe auf die Daten erfolgen in der Regel jeweils nur lesend. Ausnahmen bilden dabei der DBA, der BI / ETL Admin und das Appl Owner Schema. Applikationen greifen über einen Schnittstellenuser auf die Daten. Dieser besitzt nur einen lesenden Zugriff. Dabei wird für jede zugreifende Applikation ein eigener Schnittstellenuser erstellt. Die BI User können mittels persönlichen oder vordefinierten Datenbankaccounts auf die Daten zugreifen; dies wiederum nur lesend. Um die Zugriffe zu regeln, werden entsprechende Datenbank Rollen erstellt [siehe Kapitel 6.14.1 Richtlinien zum User- und Rollenkonzept], mit denen die entsprechenden Berechtigungen auf die Daten spezifisch vergeben werden können. Die Datenhoheit obliegt dem zuständigen Fachdienst. Er ist der sogenannte Datenherr. Benötigt eine Applikation oder eine Person aus einem anderen Fachbereich Zugriff auf die Daten, so sind diese beim entsprechenden Datenherr einzuholen. Der Datenbankbetrieb wird dann einen Datenbankaccount erstellen und ihm die entsprechenden Berechtigungen mittels Rollen zuteilen. 6.10.5.3 ODS Datenaustausch Das Konzept sieht vor, dass der ODS die Daten nur über den defnierten ELT Prozess erhält. Es dürfen keine Daten über andere Ladertechnolgien (Datenbank Links, SQL*Loader, etc.) geladen werden. Es ist jedoch erlaubt andere Datenbanken mittels Datenbank Links mit Daten aus dem ODS zu beliefern. _____________________________________________________________________________ 84 _____________________________________________________________________________ 6.11 Verfügbarkeit der BI Plattform Die Verfügbarkeit der Plattform wurde bereits in der Architektur der Plattform berücksichtigt und entsprechend gestaltet. Die Verfügbarkeit richtet sich an den RTO und RPO, welche in den SLAs definiert wurden. Da eine zentrale Plattform realisiert wird, muss sich die Verfügbarkeit an jenen Service anlehnen, welcher die strengsten SLA Definitionen hat. 6.11.1 Definition der Plattformverfügbarkeit Das SLA ist ein Vertragsdokument zwischen dem Auftraggeber und dem Service Provider, welches die zu erbringende Leistung und Qualität (Güte) eines IT Services regelt. Jeder Service hat sein eigenes SLA, zugeschnitten auf dessen Bedürfnisse. Für unsere Plattform relevant sind die unten definierten Ausfall- und Wiederherstellungszeiten (RTO) und die maximalen Datenverlustzeit (RPO): Klasse Zeitkritikalität Maximale Wiederherstellungszeit IT Service Maximale Datenverlustzeit Höchste Zeitkritikalität bis 4 Stunden A Kein Datenverlust toleriert Erhöhte Zeitkritikalität bis 12 Stunden bis 4 Stunden B Zeitkritisch bis 3 Tage bis 8 Stunden Standard > 3 Tage (best Effort) > 8 Stunden (best Effort Bemerkungen C D Standardanforderungen des IT-Grundschutzes Abbildung 6.31: SLA IT Post Da wir als Minimalkriterium das SLA des kritischsten Service abzudecken haben, muss die Plattform auf die Klasse A ausgelegt werden. Einige Kunden haben für ihre business kritischen Applikationen in den SLA‟s Konventionalstrafen vereinbart, falls die SLA‟s nicht eingehalten werden. 6.12 Wiederverwendbarkeit der Daten Es werden zwei Typen unterschieden: Daten die im ODS als Replikat für andere operative Systeme zur Verfügung gestellt werden Daten die im DWH historisiert werden _____________________________________________________________________________ 85 _____________________________________________________________________________ 6.12.1 Replikate Werden die Daten nur als Replikat für die eigene oder andere Applikationen verwendet, so kann auf eine Anpassung der Struktur verzichtet werden. Es ist jedoch empfehlenswert, die Daten bereits bei einem Releasewechsel in eine künftig wiederverwendbare Form zu bringen. 6.12.2 Ausprägungen der Daten im ODS Die Daten im ODS sind operativer Natur, was sich auch in der Datenaktualität bemerkbar macht. Es werden folgende Datenkategorien unterschieden: temporale Daten Stammdaten Datumsbezogene Stammdaten 6.12.2.1 Temporale Daten Temporale Daten sind Daten, die mit einem Zeitstempel versehen sind. Bei solchen Daten sind Zeitinformationen vorhanden, wie zum Beispiel, wann ein Ereignis stattgefunden oder geendet hat. Temporale Daten können aufgrund ihrer Eigenschaft einfach bewirtschaftet werden. So können diese partitioniert oder aufgrund ihres Zeitstempel verändert oder gelöscht werden. 6.12.2.2 Stammdaten Stammdaten sind statische Daten. Diese werden in der Regel einmal erfasst und - wenn überhaupt - nur in grossen Abständen verändert. Stammdaten werden zur Identifikation, Klassifizierung und Charakterisierung von Bewegungsdaten benötigt. Diese stehen in einem grossen Unternehmen meistens mehreren Applikationen zur Verfügung und sind daher auf die Wiederverwendbarkeit ausgelegt. 6.12.2.3 Datumsbezogene Stammdaten Datumsbezogenen Stammdaten sind eine Art Mischform zwischen Stamm- und temporalen Daten. Sie erlangen resp. verlieren ihre Gültigkeit mittel einem IBS-Flag (Inbetriebsetzungsdatum) und einem ABS-Flag (Ausserbetriebsetzungsdatum) . Dies trifft häufig zu, wenn die Historisierung bereits auf dem Quellsystem gemacht wird (z.B. Daten über Wohnadressen von Kunden). Diese Daten werden inkl. der bereits „abgelaufenen“ Einträge übernommen. 6.12.3 Historisierte Daten Bei der Überführung der Daten aus dem ODS ins DWH sind diese, wenn möglich in ein allgemein gültiges Format zu transformieren. Dies muss jedoch immer von Fall zu Fall entschieden werden. Die Richtlinien betreffend Datenmodellierung im DWH sind nicht Bestandteil dieser Arbeit, sie müssen situativ oder projektspezifisch behandelt werden. _____________________________________________________________________________ 86 _____________________________________________________________________________ Falls Daten aus dem ODS aus Compliance Gründen zu archivieren sind, müssen die Compliance Richtlinien der entsprechenden Institution befolgt werden. Auf die Archivierungsaspekte gehen wir im Rahmen dieser Arbeit nicht weiter ein. 6.12.4 Handhabung der Daten im ODS Der ODS ist nicht als Archiv vorgesehen. Daher werden folgende Richtlinien definiert: Nr. HIS-1 HIS-2 HIS-3 HIS-4 Richtlinie Stammdaten und datumsbezogene Stammdaten können beliebig lange im ODS gehalten werden Temporalen Daten wird eine maximale Aufbewahrungsfrist von 90 Tagen gewährt Temporale Daten werden als partitionierte Tabellen gespeichert Nach Ablauf der 90 Tagen werden die Daten entweder gelöscht oder in ein DWH bzw. in ein Archiv überführt 6.13 Cleanup Daten Beim Cleanup der Daten im ODS wird zwischen zwei Fällen unterschieden: - Cleanup durch Quellsystem ausgelöst - Cleanup durch den ODS ausgelöst Generell gilt, wenn nichts Weiteres definiert ist, werden die Daten nach der im Antragsformular definierten Zeit wieder gelöscht. 6.13.1 Cleanup durch Quellsystem ausgelöst Falls das Quellsystem bereits über ein eigenes Cleanup verfügt, muss auf dem ODS kein separates Cleanup eingerichtet werden. Werden auf dem Quellsystem Daten gelöscht, wird dies von Goldengate registriert und die Informationen der zu löschenden Daten an den ODS übermittelt. Danach werden die entsprechenden Records automatisch gelöscht. 6.13.2 Cleanup durch ODS ausgelöst Daten die nach der Extraktion und dem Laden in den ODS noch transformiert werden, erhalten zusätzlich einen Surrogate Key mit einem Timestamp. Mittels diesem Timestamp können später die Daten, die älter als die definierte Aufbewahrungsfrist sind, gelöscht werden. 6.14 Sicherheit Die Vorgaben des Grundschutzhandbuches betreffend Datenintegrität, Verfügbarkeit und Vertraulichkeit sind zwingend einzuhalten. Das Rollen- und Userkonzept, welches im folgendem Kapitel behandelt wird, behandelt einen Teil des Datenschutzes und muss entsprechender beachtet werden. Dies hat schlussendlich Einfluss auf die Verfügbarkeit, Vertraulichkeit und Integrität der Daten. _____________________________________________________________________________ 87 _____________________________________________________________________________ Datenschutz im technischen Bereich bedeutet: Schutz der gespeicherten Daten gegen Zugriff durch Dritte gilt sowohl für die Datenbank als Ganzes als auch für spezielle Datenbereiche unterscheidet den Zugriff zu eigenen Objekten bzw. zu fremden Objekten Oracle hat ein umfangreiches und ausgefeiltes Datenschutzkonzept, welches durch das Zusammenspiel verschiedener Mechanismen realisiert wird: Zugriff auf Datenbank Zugriff auf eigene und fremde Objekte Durchführung von Operationen Um diese Mechanismen abzudecken, werden User, Rollen, Profiles und Packages eingesetzt. 6.14.1 Richtlinien zum User- und Rollenkonzept Folgende Richtlinien für User und Rollen dienen der Sicherheit und sind zwingend einzuhalten. 6.14.1.1 Usertypen Nr. SEC-01 Richtlinie Oracle User XY Zweck User XY ist der Applikationsuser. Er ist der einzige User, der Objekte erstellen darf. Dem Applikationsuser XY gehören n Objekte der Applikation XY. Rollen und Grants Er besitzt die Rollen DBA_MAKE_SESSION und DBA_APPL_OWNER. Sind Berechtigungen auf andere Applikationen notwendig, müssen diese via Rollen erteilt werden. Ausnahmen bilden Packages, welche einem anderen Owner gehören. In diesem Fall muss das EXECUTE Recht direkt vergeben werden. Alle Grants, welche der Applikationsuser braucht, dürfen nur unter der Berücksichtigung des Securityaspektes vergeben werden. Das heisst, Systemprivilegien wie ANY ..., BECOME USER und GRANT ANY ... sind nicht erlaubt. Passwort Management Das Passwort darf vom Datenbankbetrieb jederzeit auf den Produktions- und Integrationsdatenbanken geändert werden und ist dem Applikationsverantwortlichen und Entwickler nicht bekannt. Auf den anderen Datenbanktypen (Development, Test und Schulung) darf dies erst nach Absprache mit dem Applikationsverantwortlichen und Entwickler durchgeführt werden. Dies ist notwendig, da sie für Weiterentwicklung und Debugging Zugriff auf die Datenbank benötigen. Profile Profile Default _____________________________________________________________________________ 88 _____________________________________________________________________________ Nr. Richtlinie SEC-02 Oracle User XY_SS Zweck Er ist ein Schnittstellenuser. Dieser User wird für den Datenaustausch zwischen zwei Datenbanken benötigt, falls der Quelluser und der Zieluser nicht identisch sind. Rollen und Grants Er besitzt die Rolle DBA_MAKE_SESSION und eine Schnittstellenrolle mit den Berechtigungen auf die Objekte des Zielusers. Die Rolle wird nach dem Schnittstellenuser XY_SS_ROL benannt. Passwort Management Der Datenbankbetrieb darf das Passwort, nach Absprache mit dem Applikationsverantwortlichen, auf allen Datenbanktypen (Development, Test, Schulung, Integration und Produktion) ändern. Bei einer Passwortänderung sind die bestehenden Datenbanklinks mit dem neuen Passwort anzupassen. Dies gilt auch für allfällige Scripts und Konfigurationsfiles. Profile Profile Default SEC-03 Oracle User XY_APPL Zweck Es handelt sich um einen Schnittstellenuser zum Applikationsserver. Dieser User wird für N-Tier Applikationen gebraucht und ist auch, entsprechend geschützt, in Konfigurationsfiles auf dem Applikationsserver vorhanden. Er dient als Verbindung zwischen dem Applikationsserver und der Datenbank. Rollen und Grants Der User besitzt die Rolle DBA_MAKE_SESSION und die entsprechenden Applikationsrollen. Passwort Management Der Datenbankbetrieb darf das Passwort, nach Absprache mit dem Applikations- und Systemverantwortlichen, auf allen Datenbanktypen (Development, Test, Schulung, Integration und Produktion) ändern. Das Passwort der Produktions- und Integrationsdatenbanken ist nur dem Datenbankbetrieb sowie dem Systemverantwortlichen, welcher die Konfigurationsfiles verwaltet, bekannt. Profile Profile Default SEC-04 Oracle User XY_SU Zweck Je nach Applikation sind 1-n Administrationsuser erlaubt, die Monatsverarbeitungen _____________________________________________________________________________ 89 _____________________________________________________________________________ Nr. Richtlinie der Applikation sowie Abfragen auf dem Catalog durchführen dürfen. Rollen und Grants Er besitzt die Rollen DBA_MAKE_SESSION, SELECT_CATALOG_ROLE (eventuell auch eine eigene Rolle auf ALL_ Views) und die entsprechenden Applikationsrollen, welche auch das Ausführen von DML Befehlen erlauben. Passwort Management Der Datenbankbetrieb darf das Passwort nach Absprache mit dem Applikationsverantwortlichen auf allen Datenbanktypen (Development, Test, Schulung, Integration und Produktion) ändern. Profile Profile Default SEC-05 Oracle User XYZ Zweck Ist ein Enduser, welcher je nach Applikationsberechtigungen Abfragen auf den Applikationsobjekten ausführen darf. Rollen und Grants Er besitzt die Rolle DBA_MAKE_SESSION, SELECT_CATALOG_ROLE (nur Applikationsverantwortlicher), die entsprechenden Applikationsrollen und auch eigene Rollen auf ALL_ Views. Passwort Management Das Passwort darf nur auf Anweisung der Benutzers geändert werden. Profile Profile End_User _____________________________________________________________________________ 90 _____________________________________________________________________________ 6.14.1.2 Rollen der verschiedenen Usertypen Nr. SEC-06 Richtlinie Durch den Datenbankbetrieb werden per Default 2 Rollen auf der Datenbank erstellt. Dies sind die Rollen DBA_MAKE_SESSION und DBA_APPL_OWNER. Sie beinhalten folgende Privilegien: DBA_MAKE_SESSION (für Applikations-, Schnittstellen- und Enduser) - create session alter session DBA_APPL_OWNER (für Applikationsuser) - alter session create any synonym create cluster create database link create procedure create public synonym drop public synonym create sequence create snapshot create synonym create table create trigger create type create view grant query rewrite Sämtliche von der Applikation erstellte Rollen werden durch den DBA geprüft. Dabei wird kontrolliert, ob sie dem Standard entsprechen und keine Berechtigungen enthalten, welchen dem Security- und Integritätsaspekt widersprechen. In keiner Applikationsrolle dürfen Berechtigungen enthalten sein, welche Änderungen an der Konfiguration oder Struktur der Datenbank zulassen. Werden dennoch zusätzliche Berechtigungen benötigt, müssen diese mit dem DBA abgesprochen werden und mittels einer separaten Rolle vergeben werden. SEC-07 System-Privilegien Es ist untersagt Oracle Systemprivilegien an End User zu vergeben. Einzige Ausnahme ist der Applikationsuser. Falls die Applikation zwingend irgendwelche Systemprivilegien benötigt, muss dies vorgängig mit dem DBA abgesprochen werden. _____________________________________________________________________________ 91 _____________________________________________________________________________ 6.14.1.3 Rollenkonzept für Applikation, System - und Objektprivilegien Nr. SEC-08 Richtlinie Das Rollenkonzept ist nach dem „Subject oriented“ Ansatz auszurichten. [Kapitel „Subject oriented“] Alle Zugriffsprivilegien auf Datenbankobjekte werden ausschliesslich an Rollen vergeben. Diese Rollen werden restriktiv an den entsprechenden Usertyp vergeben. Das direkte Erteilen von Zugriffsberechtigungen an die Usertypen ist nicht gestattet. Ausnahme sind Packages, Prozeduren mit Objekten die einem anderen User gehören. Das Erteilen von Zugriffsberechtigungen an PUBLIC ist in der Regel nicht gestattet. Das Erteilen der Systemrollen CONNECT, RESOURCE oder DBA an die Usertypen ist nicht gestattet. Bei einem Rollenkonzept ist darauf zu achten, dass dieses nicht mehr als drei Levels enthält. Der Grund liegt darin, dass es ansonsten unübersichtlich und damit schlecht wartbar wird. Dadurch allfällige entstandene Redundanzen werden in Kauf genommen. 6.14.1.4 Profile Nr. SEC-09 Richtlinie Es werden die Profiles DEFAULT und END_USER eingesetzt. Das Profile END_USER unterscheidet sich nur in der Anzahl Sessions per User und ist für alle Benutzer der Applikation verbindlich. CREATE PROFILE END_USER LIMIT SESSIONS_PER_USER 8; 6.14.1.5 Tablespaces Nr. SEC-10 Richtlinie Dem Appl Owner sind als Default Tablespace Appikationstablespaces zugeteilt, welche auf „Quota Unlimited Tablespace“ gesetzt sind. Als Default Tablespaces wird, falls es nicht anderes gewünscht ist <APPLICATIONSNAME_S> verwendet. Allen anderen Usern wird als Default Tablespace USERS zugewiesen, auf welchem sie keine Quota besitzen. Allen Usern wird der Temporary Tablespace TEMP zugewiesen. _____________________________________________________________________________ 92 _____________________________________________________________________________ 6.14.1.6 Datenbanklinks Nr. SEC-11 Richtlinie Es gibt keine direkten Datenbanklinks auf fremde Objekte. Alle Zugriffe werden über Schnittstellenuser geregelt. Datenmanipulationen müssen mittels Packages durchgeführt werden. Somit ist garantiert, dass von keinem anderen User aus, auf einer externen Datenbank, Daten ohne Wissen manipuliert werden können. Create DB-Link und ansprechen von Objekten über DB-Link Im ODS dürfen DB-Links nicht direkt angesprochen werden. Das Ansprechen der DBLinks muss in Synonyme implementiert werden. Bei allfälligen Änderungen muss somit nur das Synonym angepasst werden. z.B.: CREATE SYNONYM TAP_GAT_MASTER FOR [email protected]; Zwei Varianten von Privat Datenbanklinks sind zulässig. Variante1: Quell- und Zielapplikationsuser sind identisch. z.B: CREATE DATABASE LINK P10PA4.WORLD USING 'P10PA4.WORLD'; Variante2: Quell- und Zielapplikationsuser sind nicht identisch und werden über einen Schnittstellenuser verbunden. z.B: CREATE DATABASE LINK P10PA4.WORLD@ABC_XYZ_SS CONNECT TO ABC_XYZ_SS IDENTIFIED BY XXXXX USING 'P10PA4.WORLD'; Public Datenbanklinks sind nicht gestattet. Ebenso das Anlegen von DB-Links auf andere User ausser dem Applikationsuser. _____________________________________________________________________________ 93 _____________________________________________________________________________ 6.14.1.7 Ergänzungen und Erklärungen Im Weiteren sollen einzelne Teile des User- und Rollenkonzeptes näher erläutert werden. 6.14.1.8 Schnittstellenuser erstellen Damit verteilte Datenbanken, ihre Daten austauschen können, benötigt man in der Regel einen User und die entsprechenden Zugriffsberechtigungen. Sind mehrere Schnittstellen vorhanden, verliert man unter Umständen den Überblick von welchen Schnittstellen aus zugegriffen wird. Um dies zu vermeiden definiert man auf der Quelle einen Schnittstellenuser und vergibt diesem die notwendigen Berechtigungen. Durch die Namenvergabe wird damit ersichtlich, welche Schnittstelle diese Daten benötigt. Damit ist auch eine einfachere Bewirtschaftung möglich. Operative DB Schnittstellen User auf Operative DB ODSDB_OPDB_SS User OPDB ODS User ODSDB Rolle auf Ziel DB ODSDB_OPDB_SS_ROL Abbildung 6.31: Schnittstellenuser Sinnvollerweise ist ein entsprechendes Rollenkonzept zu entwickeln und dem Benutzer sind die entsprechenden Rollen zuzuweisen. 6.14.1.9 Berechtigungen ohne Rollenkonzept Bei steigender Anzahl User und Datenbankobjekten wird das Verwalten von Zugriffsberechtigungen unübersichtlich und enorm schwierig. User Tabellen Abbildung 6.32: Berechtigungen ohne Rollenkonzept Die Konklusion daraus sind etliche tausende von Grants zu einzelnen Usern. Daraus ist ersichtlich, weshalb ein User- Rollenkonzept sinnvoll ist. _____________________________________________________________________________ 94 _____________________________________________________________________________ 6.14.1.10 Beispiel mit Rollenkonzept Ein Rollenkonzept ist Initial aufwendig, auf längere Sicht lohnt es sich mehrfach. Im Projektablauf ist mit dem Rollenkonzept daher hinreichend früh zu beginnen. User ZUBO Role PM Role Rollen ASDP Role Adresschecker Role Tabellen Abbildung 6.33: Berechtigungen mit Rollenkonzept _____________________________________________________________________________ 95 _____________________________________________________________________________ 6.15 Prozesse In diesem Kapitel werden die Prozesse definiert. Diese werden gebraucht, damit die erforderlichen Schritte bekannt sind, um eine Überführung in den ODS zu bewerkstelligen. Die einzelnen Schritte werden definiert, sobald der Kunde bei IT Post die Anfrage startet. Dabei unterscheiden wir folgende Prozesse: Prozess „Antrag Kunde“ Prozess „technische Implementation“ Prozess „Zugriffsberechtigung auf Fremddaten bestellen“ Prozess „Zugriffsberechtigung auf Fremddaten erstellen“ _____________________________________________________________________________ 96 _____________________________________________________________________________ 6.15.1 Prozess „Antrag Kunde“ Es werden lediglich die wichtigsten Schritte aus Kundensicht definiert. Wie bereits erwähnt, beginnt die Prozessdefinition mit der Kundenanfrage betreffend der Überführung in einem ODS bei IT Post. Prozess „Antrag Kunde“ Der Kunde definiert von welcher Datenbank die Daten extrahiert werden sollen. Quelldatenbank definieren Datenart definieren Definieren, ob es sich bei den Daten um temporale Daten oder Stammdaten handelt. Definieren welche Daten1:1 und welche tailoriert übernommen werden sollen. Übernahmeart definieren definieren des Intervalls für die Datenübernahme Intervall für die Datenübernahme der entsprechenden Tabellen definieren. Zugriffe definieren Welche User sollen wie auf welche Daten zugreifen. temoporale Daten und Stammdaten definieren Überführung ins DWH nein Wie soll mit den temporalen Daten nach Ablauf der maximalen Aufbewahrungsfrist fortgefahren werden? Falls keine Überführung in DWH gewünscht ist werden diese gelöscht. ja Übernahmeart definieren In welcher Form sollen die Daten ins DWH überführt werden? (z.B. 1:1, Aggregiert, Denormalisiert) _____________________________________________________________________________ 97 _____________________________________________________________________________ 6.15.2 Prozess „technische Implementation“ Der Prozess „technische Implementation“ behandelt die technischen Tätigkeiten, die nötig sind um die Daten in den ODS zu überführen. Prozess „technische Implementation“ Goldengate auf Quelldatenbank installieren User auf ODS erstellen tailoriert Tabellenstrukturen auf ODS vorbereiten Wie sollen die Daten ins ODS überführt werden? (Tailoriert / 1:1) 1:1 Erstellen der Tabellenstrukturen im ODS. Rollen definieren Cleanup einrichten nein Überführung ins DWH Datenart Stammdaten ja Transformation/ Aagreagation Die vom Auftraggeber definierten User werden auf dem ODS erstellt. Datenübernahme Jobs mit entsprechenden Intervall definieren temporal Der DBA installiert und konfiguriert Goldengate auf der Quelldatenbank. Jobs mit entsprechenden Intervall definieren Jobs für die Datenübernahme erstellen. Rolle für die User erstellen und entsprechende Berechtigungen erteilen. Handelt es sich um temporale Daten, die nicht ins DWH überführt werden, wird ein Cleanup eingerichtet. Die Daten werden nach max. 90 Tagen gelöscht. Werden die Daten in ein DWH überführt, müssen diese in die gewünschte Form überführt werden. Job und Transformation / Aggregation vorbereiten für die Überführung ins DWH. Transformation/ Aggregation vorbereiten _____________________________________________________________________________ 98 _____________________________________________________________________________ 6.15.3 Prozess „Zugriffsberechtigungen auf Fremddaten bestellen“ Dieser Prozess dient der Bestellung von Zugriffsberechtigungen auf Daten, die im ODS abgelegt sind. Möchten Benutzer auf fachdienstübergreifende Daten zugreifen, muss eine Genehmigung beim Datenherr eingeholt werden. Dies weil der Datenherr bestimmt, wer auf seine Daten Zugriff erhält. Prozess „Zugriffsberechtigungen auf Fremddaten bestellen“ Daten definieren nein Genehmigung einholen Genehmigung Datenherr vorhanden Definieren der Daten im ODS für welche der Zugriff gewünscht wird. Zugriff auf die Daten darf nur mit Genehmigung des Datenherr erfolgen. ja Fehlt die Genehmigung des Datenherrn, so ist sie vorgängig einzuholen. User auf ODS definieren Definieren mit welchem User auf die gewünschten Daten zugegriffen werden soll. Antrag an BI Admin weiterleiten Genehmigung des Datenherrn und Antrag für den Datenzugriff an BI Admin zur Umsetzung weiterleiten. _____________________________________________________________________________ 99 _____________________________________________________________________________ 6.15.4 Prozess „Zugriffsberechtigungen auf Fremddaten erstellen“ Dieser Prozess dient der Zugriffsberechtigungserteilung auf bereichsübergreifende Daten im ODS. Er beinhaltet die Schritte des BI Admin bei der Umsetzung. Prozess „Zugriffsberechtigungen auf Fremddaten erstellen“ nein Auftrag zurück an Auftraggeber Antrag auf Vollständigkeit prüfen Der BI Admin prüft den Auftrag auf Vollständigkeit. Bei allfälligen Unklarheiten wird beim Auftraggeber nachgefragt. Genehmigung Datenherr vorhanden Die Berechtigungen dürfen nur mit der Genehmigung des Datenherrn vergeben werden. Fehlt diese, muss der Auftrag an den Auftraggeber zurückgewiesen werden. ja Erstellen des gewünschten Users auf dem ODS. User auf ODS erstellen Rollen definieren und User zuweisen Auftraggeber informieren Berechtigungen für den Zugriff auf die gewünschten Tabellen in einer Rolle definieren und dem User zuweisen. Auftraggeber über die Umsetzung informieren. _____________________________________________________________________________ 100 _____________________________________________________________________________ 6.16 Umgang mit Berechtigungen Für Datenzugriffe ist die Bewilligung des Datenherrn Voraussetzung. Meistens ist jedoch nicht das Erteilen der Berechtigungen das Problem, sondern deren Entfernung, weil ein z.B. berechtigter Mitarbeiter kündigt oder die Abteilung wechselt. Für diesen Fall, wird dem Datenherrn quartalsweise ein Auszug mit den Personen gesendet, welche auf seine Daten Zugriff haben. Personen, die keinen Zugriff mehr auf seine Daten haben dürfen, muss er an das Datenbankbetriebsteam melden, damit diese die Zugriffe entfernen. Bei IT Post gibt es aktuell noch kein Identitymanagement System, über welches die Zugriffe bei einem Wechsel oder Kündigung eines Mitarbeiters automatisch entfernt werden. _____________________________________________________________________________ 101 _____________________________________________________________________________ 6.17 Richtlinien und Konvention für ODS Datenbankobjekte Hierbei geht es um die Namenskonventionen der Datenbankobjekte. Der Fokus wird auf Oracle Datenbanken gelegt, da der ODS auf diesem RDBMS beruht. Um eine Datenbank effizient zu unterhalten oder bei allfälligen Problemen rasch Hilfe zu leisten, ist es notwendig, dass die Datenbankobjekte die Namenskonventionen einhalten. 6.18 Allgemein gültige Namenskonventionen Bei der Namensgebung ist generell darauf zu achten, dass keine Umlaute, Blanks oder Sonderzeichen wie z.B.:;,?,@, usw. verwendet werden. In diesem Dokument wird oft der Ausdruck <Owner> gebraucht. Dieses Kürzel ist mit Bedacht zu wählen, da es die Basis für viele Namen bildet und es nachträglich (ohne grossen Aufwand) kaum geändert werden kann. Es sollte mindestens 3 bis maximal 10 Zeichen lang sein. 6.18.1 Database Link Der Database Link Name wird von Oracle vorgeschrieben (global naming) und besteht aus dem Ziel-Datenbanknamen und dem Domainnamen (Default=WORLD), welche durch einen Punkt getrennt werden und fakultativ dem Connection Qualifier, welcher durch ein @ getrennt wird. z.B.: P10PA10.WORLD Ein Database Link darf nur über ein Synonym angesprochen werden (z.B.: in Packages, Views oder Snapshots). 6.18.2 Connection Qualifier Private Link Es sind nur Privat Links zulässig. Damit können die Security Richtlinien und Gewaltentrennungen in der Datenbank sichergestellt werden. Definition: <SID>.WORLD@<Schnittstellen_User> Ein fakultatives Verbindungskennzeichen kann am Ende des Database Link Namen, getrennt mit einem „@‟ Zeichen angehängt werden. z.B.: P10PA10.WORLD@OPD_SS Public Links dürfen prinzipiell nicht verwendet werden. Ausnahmen müssen mit dem Datenbank Engineering abgesprochen werden. _____________________________________________________________________________ 102 _____________________________________________________________________________ 6.18.3 User Applikation Owner Der Username des Applikation Owners besteht aus dem Applikationskürzel und hat mindestens 3 bis maximal 10 Zeichen lang zu sein. Definition: z.B.: < Applikationskürzel > IFS CUROK 6.18.4 Tabellen Der Tabellenname (ohne Owner) besteht aus maximal 15 Zeichen und ist frei wählbar. Definition: z.B.: <Owner>_<Name> CURO_XML_LOG_POS_VAR DEZA_CONFIG Description: Jede Tabelle muss mittels Table Comment beschrieben werden. 6.18.5 Columns Beim Neuerstellen einer Tabelle ist folgende Column-Reihenfolge einzuhalten: 1. 2. 3. 4. 5. 6. 7. Primary Key Unique Keys Foreign Keys Non-unique Keys Not Null Felder Null-Felder VARCHAR2(2000) Die Reihenfolgen muss nur beim Erstmaligen erstellen der Tabelle eingehalten werden. Bei Erweiterungen ist dies nicht mehr möglich. Name: Besteht aus dem Tabellenname (ohne Owner) und dem Feld, welches durch das „_”Zeichen getrennt wird. Definition: z.B.: <Tabellenname_ohne_Owner>_<Feld> VALRE_SUBSYS LOG_JOB_ID (aus Tabelle CURO_VALRE) (aus Tabelle DEZA_LOG) Description: Jedes Column muss mittels Comment beschrieben werden. _____________________________________________________________________________ 103 _____________________________________________________________________________ 6.18.6 Primary Key Der Feldname für den Primary Key ist immer „ID” Definition: z.B: <Column>_ID VALRE_ID 6.18.7 Foreign-Key Column Feldnamen von Foreign-Key Feldern bestehen aus dem Column Prefix, dem Namen der referenzierten Tabelle (ohne Owner) und dem Namen des referenzierten Feldes, welche durch das „_”-Zeichen getrennt werden. Wenn es mehrere Foreign-Keys gibt, dann muss ein Name (z. B. der Name der Relation) als Suffix angegeben werden. Definition: <Column Prefix>_<ForeignTabName>_<ForeignColumnName>[_<Name>] Definition: z.B: DETAIL_SSVR_ID DLS_ZW_SYS_NR 6.18.8 Constraints Der Constraintname besteht aus dem Tabellennamen, den Column Namen (optional, nur obligatorisch wenn der Constraint auf bestimmte Felder zeigt, mit Ausnahme von „ID” Feldern für Primary Keys) und dem Kürzel zur Bezeichnung der Constraintart, welche durch das „_“ -Zeichen getrennt werden. Wo der Constraintname zu lang wird, kann anstelle der Column Namen ein anderer aussagekräftigerer Name verwendet werden. Definition: <Tabellename>[_< Kolonnennamen>]_<Constraintart> Die Constraintart ist wie folgt definiert : z.B.: PK CK FK UK NN (Primary-Key-Constraint) (Check-Constraint) (Foreign-Key-Constraint) (Unique-Key-Constraint) (Not-Null-Constraint) RWP_DLS_MUSER_NN CURO_PROZU_UK RWP_BEI_FAKM_FK _____________________________________________________________________________ 104 _____________________________________________________________________________ 6.18.9 Views Viewnamen werden wie folgt aufgebaut: Definition: z.B.: <Viewname>_<künstlicher Name>_V RWP_ABF_BS_EMS_V CURO_KUN_ALLE_V DEZA_REF_CODES_V 6.18.10 Trigger Namen Der Triggername besteht aus dem Owner, dem Tabellennamen, dem Zeitpunkt (A=After, B=Before) mit dem Triggertyp (R=Row, S=Statement), dem Auslöseereignis (D=Delete, I=Insert, U=Update - sortiert) und dem Suffix „TG‟, welche durch das „_“ -Zeichen getrennt werden. Definition: z.B.: <Owner>_<Tabellenname>_<Zeitpunkt><Typ>_<Ereignis>_TG DEZA_VERSION_BR_UI_TG CURO_VALRE_BR_UID_TG IFS_EG_STATUS_IU_TG 6.18.11 Index Der Indexname besteht aus dem Tabellennamen, den indizierten Feldnamen (ohne Tabellenkürzel) und der Indexart, welche durch das „_”-Zeichen getrennt werden. Wo der Indexname zu lang wird, kann anstelle des Feldnamen ein anderer aussagekräftigerer Name verwendet werden. Definition: <Tabellenname>_<Feldnamen>_<Indexart> Die Indexart ist wie folgt definiert : z.B.: I UI BI PK Index FK Bitmap index Primary key index AUSB_BELEGNR_I BER_DEBI_ID_I BEDE_UK BEDE_PK UK und PK Indexes werden automatisch von den Constraints erstellt. _____________________________________________________________________________ 105 _____________________________________________________________________________ 6.18.12 Package Package Body: Der Packagename besteht aus dem Owner, einem selbstsprechenden Namen und wenn möglich dem Suffix „Pack“ und wird durch das „_“-Zeichen getrennt werden. Definition: z.B.: <Owner>_<Name>_PACK CURO_PUT_VAL_PACK IFS_FRL_ZSP_PACK DEZA_RDLF_PACK Package Body und Specification haben den gleichen Namen. 6.18.13 Procedure (Standalone) Procedure: Der Prozedurnamen besteht aus dem Owner, einem selbstsprechenden Namen und wenn möglich dem Suffix „Proc“, welche durch durch das „_“-Zeichen getrennt werden. Definition: z.B.: <Owner>_<Name>_PROC CURO_INS_PROC IFS_UPD_PROC DEZA_CONS_PROC 6.18.14 Function (Standalone) Function: Der Funktionsname besteht aus dem Owner, einem selbstsprechenden Namen und wenn möglich dem Suffix „Func“, welche durch das „_“-Zeichen getrennt werden. Definition: z.B.: <Owner>_<Name>_FUNC CURO_NAME_FUNC ASDP_PLZ_FUNC 6.18.15 Rolen Namen Der Rollenname besteht aus dem Owner und einem Namen, welche durch das „_“ -Zeichen getrennt werden. Der Suffix „ROL“ ist fakultativ. Definition: z.B.: <Owner>_<Name>[_ROL] RWP_10 CUR_50 DBA_DEVELOPPER WWW_RWP_MUT_ALL _____________________________________________________________________________ 106 _____________________________________________________________________________ 6.18.16 Sequenz Name Der Sequenzname besteht aus dem Owner, dem betreffenden Feldnamen (inkl. dem TabellenPrefix) und dem Suffix „SEQ”, welche durch das „_“ -Zeichen getrennt werden. Definition: z.B.: <Owner>_<Feldname>_SEQ WWW_RWP_VK_ID_SEQ IFS_AUFG_ID_SEQ CURO_VALRE_ID_SEQ 6.18.17 Materialized Views Eine Materialized View besteht aus dem Owner, einem Namen (für einfache Materialized Views, der Tabellenname) und dem Suffix „MV” (alt SNAP für Snapshot), welche durch das „_“ -Zeichen getrennt werden. Definition: z.B.: <Owner>_<Name>_MV IFS_FRP_ALL_KUN_MV CURO_ISO_CODE_MV Die Referenz auf die Master-Tabelle muss immer über ein Synonym erfolgen. [siehe Kapitel 6.19.19]. 6.18.18 Materialized View - Synonym Der Synonymname der Master-Tabelle und der dazugehörige Materlialized View muss gleich lauten, damit die Location Transparency gewährleistet ist. Das Synonym soll immer auf die physische MV$-Tabelle, die beim Create Materlialized View generiert wird, angelegt werden und nicht auf die View. 6.18.19 Synonym Alle Packages, Sequences, Snapshots, Tables und Views müssen durch ein PRIVATE SYNONYM angesprochen werden. Wo es applikatorisch bedingt notwendig ist (z.B.: bei Business Objects), können auch PUBLIC SYNONYMS verwendet werden. _____________________________________________________________________________ 107 _____________________________________________________________________________ 6.19 Konzeptbericht In dieser Phase des Projektes wurden folgende Aktivitäten durchgeführt: 6.19.1 Definition von Begriffen und Technologien Definition der Module Varianten erarbeitet, gewichtet und ausgewählt Definition Zielarchitektur Definition BI Plattform ODS-Organisation Prozesse für den Betrieb der Plattform erstellt Definition von Begriffen und Technologien Als erstes wurden Begriffe und Technologien, die später im Konzept erwähnt werden, genauer beschrieben. Dies ist wichtig, um Missverständnissen vorzubeugen oder die einzelnen Schritte besser nachvollziehen zu können. Dabei wurde auf einzelne Begriffe und Technologien bewusst detaillierter eingegangen als auf andere. 6.19.2 Definition der Module Mit der Definition von Modulen wird versucht, eine Standardisierung bei der Datenüberführung in den ODS zu erreichen. Die Module sollen dem Kunden, helfen seine Daten in den ODS zu überführen. Auf der technischen Seite helfen die Standardisierungen bei einer schnellen und unkomplizierten Umsetzung. 6.19.3 Varianten Es wurden 4 Varianten erarbeitet, die als mögliche Zielarchitektur in Fragen kamen. Dabei wurde jeweils versucht, die Schwachstellen der vorangegangenen Variante durch Anpassungen oder Erweiterungen in der nächsten Variante zu beheben. Anschliessend wurden die Varianten mit den definierten Anforderungen abgeglichen und gewichtet. Dies war notwendig, um eine objektive Auswahl treffen zu können. Hier ist zu erwähnen, dass wir vollständigkeitshalber und zum Zwecke der Nachvollziehbarkeit sämtliche Kriterien mit einbezogen haben, was dazu führt, dass gewisse plattformabhängige Kriterien bei allen Varianten die selbe Bewertung erhielten. 6.19.4 Zielarchitektur Nachdem sich die Variante 3 als beste Lösung heraus kristallisiert hatte, musste die Zielarchitektur definiert werden. Diese wurde mit einem Use Case Modell abgebildet. In einem weiteren Schritt wurde die Hardwarearchitektur definiert. Dabei wurden auch mögliche Skalierungsvarianten berücksichtigt. _____________________________________________________________________________ 108 _____________________________________________________________________________ 6.19.5 BI Plattform Unter dem Kapitel der BI Plattform Architektur wurde auf die Softwarekomponenten der künftigen Plattform eingegangen. Es wurde klar definiert, welche Software zum Einsatz kommt. 6.19.6 ODS-Organisation Bei der ODS-Organisation wurde genauer auf den ODS eingegangen. Es wurde der Umgang mit den Daten behandelt. Dabei ging es darum, wie die Daten im ODS organisiert werden, wer welche Zugriffe darauf erhält und wie die Daten zu historisieren sind. Es wurde ebenfalls auf die Verfügbarkeit des ODS eingegangen. Zusätzlich wurde ein Userkonzept für die Benutzer im ODS erstellt. Dieses regelt die Organisation der User und deren Berechtigungen im ODS aus technischer Sicht. Zu guter Letzt wurden Prozesse für die Datenübernahme und Bestellung von Zugriffsberechtigungen erstellt. Hierfür wurde zwischen der fachlichen und der technischen Sicht unterschieden. _____________________________________________________________________________ 109 _____________________________________________________________________________ 7 Realisierung In diesem Kapitel werden die definierten Konzepte, die in den vorherigen Kapiteln behandelt wurden, mittels Proof of Concept geprüft. Zudem wird das nötige Betriebskonzept erstellt. 7.1 Einleitung PoC Als Proof of Concept wurde das Projekt Adresschecker gewählt. Das Projekt entstand, weil diverse Bedürfnisträger eine Adressprüfung mittels eines Webservices durchführen wollten. Bei der Überprüfung einer Adresse werden je nach Art der Überprüfung Anfragen über mehrere Datenbanken durchgeführt. Im PoC werden diese Quellen an den ODS angebunden und die nötigen Daten repliziert, so dass die operativen Systeme nicht mehr zusätzlich belastet werden und die Daten zentralisiert zur Verfügung gestellt werden können. 7.2 Aufbau PoC Plattform Für die PoC Umgebung wurden folgende Systeme aufgebaut: ODS Datenbank Datenbanken für Adresschecker o ASDP o ZUBO o KDP o WAS o ZDL Zusätzlicher Service auf XML Gateway, für Test externer Aufrufe Zusätzliche Webservices (intern / extern) mit ODS als Backend ODI Umgebung 7.2.1 ODI Auf einem Server wurde ODI installiert und konfiguriert. ODI wird für die ETL Funktionalität verwendet. Im PoC wird er für die Anpassung der Datenstruktur und das Denormalisieren verwendet. In einem nächsten Schritt wird mit ihm die Überführung der Daten ins DWH durchgeführt. _____________________________________________________________________________ 110 _____________________________________________________________________________ 7.2.2 Adresschecker Architektur Client Internet Zone SOAP request/response IX Zone XML Gateway Postnetz SOAP request/response ASDP PL/SQL call PL/SQL call ZUBO JDBC call ESB Web Services extern DB Service PL/SQL call JDBC call ESB Web Services intern PL/SQL call PL/SQL call ZDL KDP SOAP request/response Postnetz Software WAS Abbildung 7.1: Adresschecker Architektur Dies ist die Architektur des Services, der für das PoC gewählt wurde. Darauf sieht man, wie bei internen oder externen Aufrufen die Webservices die Daten von verschiedenen operativen Datenbanken abrufen. 7.2.3 Quellen Als Quellen dienen die Datenbanken ASDP, ZUBO, KDP, WAS und ZDL. Jede dieser Datenbanken enthält Adressdaten verschiedenster Art. ASDP (Allgemeine Stammdaten Post) In der Anwendung ASDP werden Stammdaten für die ganze Post verwaltet. Darin sind die Postleitzahlen sowie PLZ-Informationen, Gemeindedaten und Feiertagsdaten enthalten. ZUBO (Zustelldaten Botenbezirk Sortierfile) Diese Anwendung verwaltet alle „postalisch bedienten Adressen“ der Schweiz und des Fürstentums Liechtenstein. Jede Adresse enthält den Schlüssel zum System Geo-Post (Geografische Koordinaten einer Adresse). ZUBO liefert für jede postalisch bediente Adresse die Anzahl Haushaltungen (zugestellt, Stopp, Fächer, Total) sowie die Zustellogistik (Zustellstelle, Bezirk für Brief und Paketzustellung, gültig von- bis, Zustellmittel, Abholstelle). WAS (Webservice Adressuche) WAS besteht aus einem ZUBO Teilreplikat. Die Daten in dieser Datenbank liegen zum Teil bereits denormalisiert vor. _____________________________________________________________________________ 111 _____________________________________________________________________________ KDP (Kundendaten Post) Mit der KDP Datenbank wird die Zuordnung eines postweiten Schlüssels in den einzelnen Kundendatenbanken sichergestellt. Dies bildet die Voraussetzung für ein umfassendes Kundenbild, insbesondere für Gross- und Grösstkunden. Mit KDP werden alle Firmenund Privatadressen zur postweiten Nutzung zur Verfügung gestellt. ZDL (Zustell Dienstleistungen) ZDL umfasst die Bewirtschaftung der postalischen Dienstleistungen zur Unterstützung der Zustellung, insbesondere die Nachsendeaufträge, Zustellung ins Postfach, DomizilUnteradressen, Vollmachten, Zeitungen ohne Adresse usw. 7.2.4 Technische Funktionen aus der Spezifikation Der Service soll sowohl für interne als auch externe Kunden für Adressvalidierungen zur Verfügung stehen. In einer ersten Phase sollen mit diesem Service Adressen aus der Schweiz und dem Fürstentum Lichtenstein validiert werden können. Erst in einer späteren Phase soll der Service um weitere Länder erweitert werden. 7.2.4.1 Zugriff auf die Daten Damit die internen Datenzugriffe von den externen getrennt werden können, wird der Zugriff durch ein User- und Rollenkonzept geregelt. So kann intern auf sämtliche Daten zugegriffen werden, wohingegen externe Kunden nur einen eingeschränkten Zugriff auf die Daten erhalten. 7.2.4.2 Fuzzy Search Logic Die Funktion „Unscharfe Suche: fehlerhaft geschriebene Strassennamen berücksichtigen“ wird mittels Oracle Text realisiert. Mit dieser Option kann mittels einer Indexierung von Datenfeldern eine Volltextsuche realisiert werden. Diese Funktion ist jedoch erst in einem späteren Release vorgesehen. Die Validierung der Adressen wird in drei Etappen realisiert: 1. Verifizierung des Ortes 2. Verifizierung der Adresse 3. Verifizierung der Personennamen (natürliche und juristische) Der Service ermöglicht eine Informationssuche und Validierung der Daten. Standardmässig wird der Service als Suchsystem eingesetzt. Falls eine Validierung der Daten durchgeführt wird, müssen sämtliche Input Parameter beim Aufruf des Services mitgegeben werden. _____________________________________________________________________________ 112 _____________________________________________________________________________ Suchservice Der Suchservice gibt die Informationen zurück, die den Suchkriterien entsprechen. zum Beispiel: wenn als Input Parameter die Postleitzahl 2400 eingegeben wird, liefert der Service folgende Daten zurück. 1. 2400 Le Locle 2. 2400 Le Prévoux 3. + alle historischen Daten zur Postleitzahl 2400 Validierungsservice Der Validierungsservice prüft die Daten auf ihre Richtigkeit. Für die Validierung müssen mindestens zwei Inputparameter mitgegeben werden. Zum Beispiel: 2400 Le Prévoux resp. Postleitzahl und Ort 7.2.4.3 Verifizierung des Ortes (Etappe 1) Die Verifizierung des Ortes ermöglicht die gleichzeitige Validierung der Postleitzahl und des Ortes. Für diese Etappe werden die Daten aus ASDP benötigt. Dabei werden auch historische Daten berücksichtigt. 7.2.4.4 Verifizierungsprozess Die Postleitzahlen und Orte werden als Input Parameter mitgegeben. Als Resultat erhält der Kunde einen oder mehrere Einträge zurück. Wenn die Postleitzahl nicht mit dem Ort übereinstimmt, wird die Postleitzahl als prioritärer Suchinput verwendet. Als Ausgabe wird für jeden gefunden Eintrag folgendes zurückgeben: 1. ID der Postleitzahl (ONRP) 2. die Postleitzahl als 4-stellige Ziffer (substr(PLZ_PLZ,1, 4)) 3. den Ort mit 18 Zeichen (PLZB_ORT_18), 27 Zeichen (PLZB_ORT_27) und 39 Zeichen (PLZB_ORT_39) Die Ausgabe des Ortes mit 39 Zeichen wird externen Kunden nicht angeboten 4. ein Indikator, der angibt, ob die Postleitzahl gültig ist 5. ein Indikator, der angibt, ob der Ort gültig ist 6. ein Indikator, der angibt, ob die Postleitzahl und der Ort gültig sind 7. ein Indikator, ob der angibt, ob die Postleitzahl und der Ort offiziell sind 8. Sind die Daten nicht offiziell, wird der Vermerk „Adresszusatz“ zurückgegeben 9. ein Indikator, falls der Ort „ alternativ“ ist 10. der Sprachcode für den Ort „alternativ“ 11. der Sprachcode für die Postleitzahl 12. der Typ der Postleitzahl _____________________________________________________________________________ 113 _____________________________________________________________________________ 7.2.4.5 Suchprozess Wird die Postleitzahl und der Ort eingeben, so wird die Suche nach folgenden Kriterien durchgeführt: 1. Postleitzahl (4-stellig) und Ort 2. Postleitzahl (4-stellig) 3. Ort Beispiel: 2400 Le Locle Resultat = 2400 Le Locle als ersten Eintrag. 2400 La Chaux-de-Fonds Resultat = 2400 Le Locle + 2400 Le Prévoux als zweiten Eintrag. 2402 Le Locle Resultat = 2400 Le Locle als dritten Eintrag. 7.3 Durchführung PoC Die Durchführung des PoC geschieht in zwei Phasen. Phase1: In der ersten Phase wird einfach mal die Grundfunktionalität zur Verfügung gestellt und geprüft. 1. Aufbau einer eignen Umgebung für den PoC (Datenbanken, XMLGateway, ESB Webservices, ODI, ODS) 2. Datenübernahme aus den Quellsystemen. Dabei werden die Daten mittels Oracle Goldengate 1:1 in den ODS überführt. 3. Anpassen der Scripts / Packages und des Webservices auf die PoC Umgebung 4. Testen des Adresscheckers Phase2: In der zweiten Phase werden die Resultate des Adresscheckers aus technischer Sicht geprüft. Es wird geprüft, welche Abfragen optimiert werden müssen. Dabei wird entweder das Statement oder die Datenstruktur angepasst. 1. 2. 3. 4. Identifizieren der „langsamen“ Funktionen / Statements Statement anpassen, Daten denormalisieren oder aggregieren Allfälliges Anpassen der Scripts, PL/SQL Packages und des Webservices Testen des Adresscheckers _____________________________________________________________________________ 114 _____________________________________________________________________________ 7.3.1 Lösung Mit diesem Modell soll aufgezeigt werden, wie die heutige Situation durch die Verifizierung mittels Proof of Concept vereinfacht werden kann. Ausganglage Poc Lösung KDP ODS Webserver Client Abbildung 7.2: PoC Lösung WAS Webserver ZDL Client ZUBO ASDP Abbildung 7.3: PoC Ausgangslage 7.3.2 Resultate Phase 1 In dem nächsten Kapitel werden folgende Arbeiten erläutert: Data Integration mit Oracle Goldengate Data Integration mit Oracle Data Integrator (ODI) Test Webservice 7.3.2.1 Data Integration mit Oracle Goldengate Wie bereits mehrfach beschrieben, werden die Daten mittels Oracle Goldengate vom Quellsystem in den ODS überführt. Die unterschiedlichen Quellsysteme wurden bereits an anderer Stelle erwähnt. Hier werden lediglich, die Konfigurationsfiles für die Extraktions- und den Ladeprozess dargestellt. Beispiel anhand der Quelle ASDP: Konfiguration auf Quellsystem EXTRACT e_asdp USERID asdp, PASSWORD <pwd> RMTHOST v056z3, MGRPORT 7809 RMTTASK replicat, GROUP l_asdp _____________________________________________________________________________ 115 _____________________________________________________________________________ TABLE TABLE TABLE TABLE TABLE TABLE TABLE TABLE TABLE ASDP.ASDP_DOM; ASDP.ASDP_LOGM; ASDP.ASDP_LOGL; ASDP.ASDP_LOGP; ASDP.ASDP_WSUSER; ASDP.ASDP_SUCH; ASDP.ASDP_ADRCHK; ASDP.ASDP_PLZB; ASDP.ASDP_PLZ; Konfiguration auf Zielsystem REPLICAT l_asdp USERID ods1, PASSWORD <pwd> ASSUMETARGETDEFS MAP ASDP.ASDP_DOM, TARGET ASDP.ASDP_DOM, KEYCOLS (DOM_NOM,DOM_CODE); MAP ASDP.ASDP_LOGM, TARGET ASDP.ASDP_LOGM, KEYCOLS (LOGM_ID); MAP ASDP.ASDP_LOGL, TARGET ASDP.ASDP_LOGL, KEYCOLS (LOGL_ID); MAP ASDP.ASDP_LOGP, TARGET ASDP.ASDP_LOGP, KEYCOLS (LOGP_NOM); MAP ASDP.ASDP_WSUSER, TARGET ASDP.ASDP_WSUSER, KEYCOLS (WSUSER_WEBSERVICE,WSUSER_PARAMETRE,WSUSER_DATE); MAP ASDP.ASDP_SUCH, TARGET ASDP.ASDP_SUCH, KEYCOLS (SUCH_ABS,SUCH_BEZ,SUCH_FLD,SUCH_ID); MAP ASDP.ASDP_ADRCHK, TARGET ASDP.ASDP_ADRCHK, KEYCOLS (ADRCHK_PARAM,ADRCHK_VAL1_V); MAP ASDP.ASDP_PLZB, TARGET ASDP.ASDP_PLZB, KEYCOLS (PLZB_ID); MAP ASDP.ASDP_PLZ, TARGET ASDP.ASDP_PLZ, KEYCOLS (PLZ_ID); Als Resultat wurden die Daten der ASDP Tabellen auf das Zielsystem repliziert. 7.3.2.2 Data Integration mit Oracle Data Integrator (ODI) Mit dem ELT Tool ODI haben wir aufgezeigt wie Transformationen oder Ladeprozesse in etwaige DWHs oder im ODS stattfinden. Zunächst wurden die Data Stores definiert. Dabei wird in Physical und Logical Architecture unterschieden. Der Unterschied liegt darin, dass einerseits die physische Infrastruktur und andererseits der logische Aufbau in der Datenbank beschrieben werden. Abbildung 7.4: ODI Physical Architecture Abbildung 7.5: ODI Logical Architecture _____________________________________________________________________________ 116 _____________________________________________________________________________ Anschliessend wurde die Struktur der entsprechenden Quell- und Zielsystemen vorbereitet. Hierbei werden sogenannte Models gebildet, wo mittels Reverse Engineering die Struktur der Quell- und Zielsysteme ersichtlich wird: Abbildung 7.6: ODI Model Damit gelangt man zum anschliessenden Ladeprozess: Abbildung 7.7: ODI Mapping _____________________________________________________________________________ 117 _____________________________________________________________________________ 7.3.2.3 Test Webservice Stellvertretend für verschiedene Tests folgen zwei Aufrufe des Webservices, die mittels soapUI auf der neuen Umgebung durchgeführt wurden. Abbildung 7.8: SOAP Aufruf 1 Abbildung 7.9: SOAP Aufruf 2 _____________________________________________________________________________ 118 _____________________________________________________________________________ 7.3.3 Resultate der Phase 2 In dieser Phase wurden die Sessions des Webservices auf dem ODS überwacht, um sogenannte Langläufer (Statements, die überdurchschnittliche Ausführungszeiten haben) ausfindig zu machen. Bei der Analyse der Statement respektive der Execution Plans konnten jedoch keine „schlimmen“ Statements ausfindig gemacht werden. Der Grund dafür ist, dass es sich beim Webservice um eine klassische OLTP Applikation handelt, die über Indexzugriffe nur wenige Resultate zurück liefert. In der Folge konnten/mussten auch keine Statements angepasst werden. _____________________________________________________________________________ 119 _____________________________________________________________________________ 7.4 Betriebskonzept Das Betriebskonzept bildet die Grundlage für einen reibungslosen und sicheren Einsatz. Es werden alle im Zusammenhang mit dem Betrieb auftauchenden Fragen beantwortet. 7.4.1.1 Zweck Das Betriebskonzept beschreibt die Aktivitäten und die Organisation zum Betrieb der zentralisierten und modularen BI Plattform und Infrastruktur. 7.4.2 Architektur Die Plattform ist folgendermassen aufgebaut. DWH SLES 11 x64 ODI SLES 11 x64 ODS ODI SLES 11 x64 Staging SLES 11 x64 Goldengate operative Datenbank SLES 11 x64 Abbildung 7.10: Architekturübersicht _____________________________________________________________________________ 120 _____________________________________________________________________________ Beim DWH, ODI und dem ODS handelt es sich um zentrale Komponenten, die nebst Redundanzen betreffend Ausfallsicherheit, nur einmal vorhanden sind. Die operative Datenbank existiert mehrmals und kann ein Oracle, MSQL, MySQL oder ein anderes RDBMS sein. Oracle Goldengate bildet die Schnittstelle zwischen dem ODS und der operativen Datenbank. Es ist jeweils auf einer Quell- und Zieldatenbank installiert. Das ODI ist für die Transformierung der Daten im ODS oder für die Überführung der Daten vom ODS ins DWH verantwortlich. 7.4.3 Komponenten Folgende Komponenten sind für einen reibungslosen Betrieb verantwortlich. Dementsprechend muss die Organisation so strukturiert sein, dass Spezialisten für die jeweilige Komponente, den nötigen Support sicherstellen können. 7.4.3.1 Operatives System Das operative System liefert die Daten für den ODS. Dadurch wird das operative System langfristig entlastet und die Daten können so auf dem ODS anderen Nutzern zur Verfügung gestellt werden. 7.4.3.2 Staging Der Stagingbereich ist nicht zwingend. Er wird benötigt, falls die Daten nicht 1:1 aus dem Quellsystem übernommen werden und dient als Zwischenspeicher für nachfolgende Transformationen. 7.4.3.3 ODS Im ODS werden Stammdaten, datumbezogene Stammdaten und temporale Daten gehalten. Diese Daten können in aufbereiteter Form für Reports und Analysen zur Verfügung gestellt werden. Die Daten werden Subject Oriented abgelegt. 7.4.3.4 ODI Mit dem ODI werden die Daten transformiert und/oder ins DWH überführt. 7.4.3.5 DWH Auf Wunsch des Datenherrn, können temporale Daten nach Ablauf der maximalen Aufbewahrungsdauer, vom ODS ins DWH überführt werden. Die historisierten Daten können ebenfalls in aufbereiteter Form für Reports und Analysen zur Verfügung gestellt werden. _____________________________________________________________________________ 121 _____________________________________________________________________________ 7.4.4 Installationsverantwortung Hierbei soll beschrieben werden, welche Organisationseinheit für die Installationen der jeweiligen Komponenten verantwortlich ist. 7.4.4.1 Installation Betriebssystem Das Betriebssystem wird durch das OS Team IT245 standardmässig und automatisiert aufgesetzt. 7.4.4.2 Installation Datenbank Die Installation des Datenbankservers läuft nicht automatisiert, sondern wird manuell von der IT234 nach Anleitung des Datenbankengineering (IT226) durchgeführt. Die Best Practices der jeweiligen RDBMS sind dabei stets einzuhalten. 7.4.4.3 Installation Goldengate Auf der Quelldatenbank und auf dem ODS muss Goldengate nach Anleitung des Datenbankengineering (IT226) installiert und konfiguriert werden. 7.4.4.4 ODI Der ODI ist ebenfalls nach Anleitung des Datenbankengineering (IT226) zu installieren und konfigurieren. 7.4.5 Betriebssicherheit Im Weiteren werden folgende Punkte beschrieben: Grundsicherheit Benutzersicherheit Überwachung / Protokollierung 7.4.5.1 Grundsicherheit Die Server werden gemäss dem IT Grundschutz der schweizerischen Post abgesichert. 7.4.5.2 Benutzersicherheit Die Benutzersicherheit wird mit dem User- und Rollenkonzept gewährleistet. _____________________________________________________________________________ 122 _____________________________________________________________________________ 7.4.5.3 Überwachung / Protokollierung Die Hauptüberwachung der Systeme wird mittels IDS / IPS durch die IT Netzsecurity gewährleistet. Für die Datenbanken gibt es keine generischen Vorgaben. Je nach Kunden- oder Complianceanforderungen werden die entsprechenden Sicherheitsfeatures situativ installiert oder aktiviert. _____________________________________________________________________________ 123 _____________________________________________________________________________ 7.4.6 Normalbetrieb Die Organisationeinheiten für den Betrieb nehmen folgende Verantwortungen wahr: Monitoring der Basisinfrastruktur o Server o Netzwerk und deren Komponenten o Storage Systeme Monitoring der Applikatorischen Dienste o Datenbanken o Applikationserver Monitoring von Applikationen Datensicherungen Patching von Systemen Upgrades und Migrationen 7.4.6.1 Datensicherung Die Datensicherung der Systeme wird nach den Best Practices der Engineering Teams der jeweiligen Technologie eingerichtet und sichergestellt. Das Engineering gibt die Sicherungsstrategien vor und ist für die Erstellung und Umsetzung von Business Continuity Konzepten verantwortlich. Systeme und Datenbanken werden nach folgender Sicherungsstrategie gesichert: Wöchentliche Vollsicherung (Level 0) Tägliche inkrementelle kumulative Sicherung (Level 1) Mehrmalige tägliche Archivelog Sicherungen (Oracle Datenbanken) So Inc0 Mo Di Mi Do Fr Sa Inc1 Inc1 Inc1 Inc1 Inc1 Inc1 Incremental 0 (Fullbackup) Incremental 1 Archivelog Backup Abbildung 7.11: Backup Strategie _____________________________________________________________________________ 124 _____________________________________________________________________________ 7.4.6.2 Überwachung Folgende OEs sind für die aufgeführten Technologien verantwortlich: IT245 Server und Betriebssysteme IT234 Datenbanken IT26[1-5] Applikationsserver und Applikationen Als Hauptüberwachungstool wird HP Openview eingesetzt. Für Systeme / Komponenten, die damit nicht abgedeckt werden können, werden zusätzliche Tools eingesetzt: Hardware: HP Health Datenbanken: Oracle Enterprise Manager (Grid Control) Applikationsserver: Springsource Hyperiq, HP Business Avalaibility Control (BAC) 7.4.6.3 Performanceüberwachung Für die Performanceüberwachung werden verschiedene Tools eingesetzt. Einerseits werden gewisse Schwellwerte mit entsprechender Alarmierung bei Überschreitung definiert, andererseits können einfach zusätzliche Informationen gesammelt werden, die zur Analyse der Performanceprobleme nützlich sind. Folgende Tools werden dabei eingesetzt: HP Openview Oracle Enterprise Manager Grid Control Springsource Hyperiq 7.4.7 Lifecycle der Software Die Informatik ist einem stetigen Wandel ausgesetzt. Täglich kommen neue Technologien oder neue Software Release hinzu. Zudem wird die Software ständig optimiert und Fehler korrigiert. Das Einspielen von Patches wird dadurch unabdingbar. 7.4.7.1 Release Wechsel Neue Releases, auch Major Releases genannt, werden durch das Engineering überprüft und zur Einführung vorbereitet. Neue Releases werden gemäss dem Lifecycle der entsprechenden Software geplant und eingeführt. 7.4.7.2 Patches Die Patches werden durch das Engineering getestet und zur Verteilung vorbereitet. Security Patches werden vierteljährlich installiert. One Off Patches werden nur für dringende Korrekturen installiert. Sicherheitspatches werden gemäss den Empfehlungen von Operational Security (OPS) verteilt. _____________________________________________________________________________ 125 _____________________________________________________________________________ 7.4.8 Abgrenzung und Schnittstellen Nachfolgend sollen organisatorische Abgrenzungen und Schnittstellen behandelt werden. 7.4.8.1 Organisation 7.4.8.2 Zusammenarbeit von Betrieb und Engineering Betrieb der Betriebssysteme IT245 Betrieb des ODS, ODI und DWH IT234 Engineering des ODS, ODI und DWH IT226 Betrieb: Implementiert und betreibt Systeme nach den Vorgaben 7x24 Änderungen an den Konzepten werden durch das Engineering geprüft und freigegeben Patchlevel auf Produktion und Integration ist in der Verantwortung des Betriebs, jedoch erst nach vorgängiger Freigabe durch das Engineering Userverwaltung auf Produktion und Integration ist in der Verantwortung des Betriebs Engineering: Änderungen auf Produktionssystemen werden generell nur durch den Betrieb gemacht. Das Engineering macht Änderungen nur nach vorgängiger Absprache mit dem Betrieb. Änderungen auf Integrationssystemen werden generell nur durch den Betrieb gemacht. Das Engineering macht Änderungen nur nach vorgängiger Absprache mit dem Betrieb. Bei neuangebundenen Datenbanken muss eine Betriebsübergabe stattfinden. Diese werden im Bullnix Web (IT internes Wiki) dokumentiert. Test- und Entwicklungsumgebungen sind in Verantwortung des Engineering, unter Mitwirkung des Betriebs. _____________________________________________________________________________ 126 _____________________________________________________________________________ 8 Einführung In diesem Kapitel werden lediglich die Supportprozesse erläutert. Es wird beschrieben, wie innerhalb der IT Post mit Problemen im Zusammenhang mit der BI Plattform vorzugehen ist. Das technische Konzept wurde in einem früheren Kapitel [Kapitel 6 Konzept] bereits behandelt. 8.1 Supportprozesse Nach der Einführung eines neuen Informatiksystems müssen auftretende Probleme so schnell wie möglich gelöst werden. Nur durch eine strukturierte Organisation und durch strikte Trennung von Aufgaben, Kompetenzen und Verantwortungen, ist eine schnelle und effiziente Problembehebung möglich. Dabei werden folgende Supportlevel unterschieden: First Level Support Second Level Support Third Level Support Die Organisation bei IT Post ist nach obengenannter Auflistung gegliedert. Der Support wird durch die Unit „IT2 Betrieb“ wahrgenommen. Innerhalb IT2 befinden sich folgende Sub-Units: IT22 Engineering IT23 Basis Betrieb IT26 Applikationsbetrieb Die genannten Sub-Units sind für den First und Second Level Support zuständig. Der Third Level Support wird in der Regel vom Hardware- oder Softwarelieferanten sichergestellt. Durch hochspezialisierte Mitarbeiter ist es möglich, ca. 95% der Probleme im IT Bereich zu lösen. In den nachfolgenden Kapiteln werden die Problemfälle im Bereich „Zentralisierte und modulare Business Intelligence Infrastruktur und Plattform“ definiert. Als Big Picture gilt folgender Prozess: Kunde UHD First Level Support Betrieb Second Level Support Entwickler/ Hersteller Thirdlevel Support Abbildung 8.1: Support Prozess _____________________________________________________________________________ 127 _____________________________________________________________________________ 8.1.1 First Level Support Das User Help Desk (UHD) bildet den Single Point of Contact. Das heisst, dass für jegliche Art von Problemen der Erstkontakt über den First Level Support geht. Hauptaufgabe ist das Erfassen und Lösen von Userproblemen. Dabei werden einfache und wiederkehrende Probleme selbstständig gelöst. Komplexere Probleme werden an den Second Level delegiert. 8.1.2 Second Level Support Der Second Level Support besteht aus separaten Teams. Es gibt Teams für das Betriebssystem, die Datenbank und die Applikation. Der Second Level Support bearbeitet diejenigen Tickets, welche vom UHD nicht selbständig gelöst werden konnten. 8.1.3 Third Level Support Der Third Level Support bildet die letzte Eskalationsstufe bei einem Problem. Er wird durch die Entwickler, Engineerings Teams oder den Hersteller wahrgenommen. 8.2 Weiteres Vorgehen bei operativer Umsetzung Für die operative Umsetzung der „Zentralisierte und modulare Business Intelligence Infrastruktur und Plattform“, sind ausserdem noch folgende in dieser Arbeit nicht behandelte Punkte durchzuführen. 8.2.1 Schulung Bei einer Umsetzung dieses Konzeptes, müssen die Mitarbeiter der genannten Organisationen vorgängig geschult werden. Sie werden dafür in 3 Kategorien eingeteilt, namentlich: Serviceverantwortliche Betrieb Entwickler 8.2.1.1 Serviceverantwortliche Bei IT Post sind die Serviceverantwortlichen direkte Ansprechpartner der Kunden. Sie betreuen und beraten den Kunden in IT Fragen So versteht sich, dass die Serviceverantwortlichen zwingend für die neue Plattform zu schulen sind. In erster Linie soll das Verständnis der Architektur und der technischen Möglichkeiten geschult werden, nicht jedoch die technischen Details. _____________________________________________________________________________ 128 _____________________________________________________________________________ 8.2.1.2 Betrieb 8.2.1.3 Entwickler und BI Admin 8.2.2 Service Die Schulung der Betriebsorganisationen der IT Post umfasst in erster Linie die Fragestellungen der Fehlerbehebung respektive das Wissen zu erlangen für die Wiederaufnahme des Services. Dafür muss auf die Architektur und im speziellen auf die neu eingeführten Technologien eingegangen werden. Bei den Entwicklern und dem BI Admin liegt der Schwerpunkt der Schulung auf dem Umgang mit Oracle Data Integrator. Da Oracle Data Integrator umfangreiche Funktionalitäten bietet, empfiehlt sich eine externe Schulung der einzelnen Mitarbeiter. In Zusammenarbeit mit der Abteilung IT Services (IT4) muss ein Service erstellt werden. Desweiteren muss die Abteilung IT4 die Preisgestaltung des Services vornehmen. 8.2.3 Marketing Der Service respektive die neue Plattform muss schlussendlich auch publik gemacht werden. Der neue Service muss an den Leitungsmeetings und den Kundenbetreuer vorgestellt werden. Zusätzlich ist es Sinnvoll ein Factsheet zu erstellen, welches dem Kunden bei der Beratung abgegeben werden kann. 8.2.4 Wirtschaftlichkeit Für die Wirtschaftlichkeit wurden lediglich die Lizenz- und Wartungskosten berücksichtigt. Eine Vollkostenrechnung, respektive Wirtschaftlichkeitsrechnung ist noch ausstehend und müsste noch erstellt werden. In dieser werden Einheitspreise für die Weiterverrechnung kalkuliert sowie der Return of Investment (ROI) berechnet. Anschliessend müsste diese der Abteilung Finanzen zur Prüfung vorgelegt werden. 8.3 Interview zur Lösung Zu Beginn dieser Arbeit wurden Interviews mit verschiedenen Schlüsselpersonen durchgeführt. Um sicher zu stellen, dass die konzipierte Lösung auch den Anforderungen entspricht, wurde ihnen das Konzept zur Begutachtung vorab zur Verfügung gestellt. Allfällige Wünsche und Anregungen können im Falle einer produktiven Umsetzung des Projektes in einen späteren Release sogleich mit einfliessen. _____________________________________________________________________________ 129 _____________________________________________________________________________ 8.3.1 Feedback der Interviewpartner Hier folgt eine Zusammenfassung mit dem Feedback der Interviewpartner. Feedback Martin Schwab – Chefarchitekt Entwicklung IT Post: „IT Post hat mit der „Zentralisierten und modularen BI Plattform und Infrastruktur“ eine Lösung zur Hand, um aktuelle und absehbare Problematiken im Zusammenhang mit ReportingAnforderungen auf OLTP-Systeme rasch und professionell zu lösen.“ Feedback Reto Pestoni – Architekt Integration und SOA IT Post: „Durch das Einführen der vorgeschlagenen Architektur könnte in Zukunft die Umsetzungszeit von Datenintegrationen wesentlich reduziert und gleichzeitig die Servicequalität erhöht werden. Im SOA Umfeld (Webservice Datenquellen) werden vermehrt Real Time Informationen benötigt, was uns mit diesem Konzept zur Verfügung stehen würde.“ Feedback Dr. phil. Andreas Mannhart – Facharchitekt Business Intelligence IT Post: „Als Facharchitekt BI unterstütze ich die Initiative der Datenbankspezialisten D.Massimi und P.Brändle, die im Rahmen einer Masterarbeit an der Berner Fachhochschule ein bereichs- oder gar postweites ODS-System aufbauen möchten, sehr. Ein solches System könnte den Aufbau verschiedenster Data Warehouses stark beschleunigen und damit sowohl wertvolle Informationen für die Bereiche der Schweizerischen Post als auch anspruchsvolle Projekte für IT generieren. Für eine bereichs- oder postweite Verbreitung erachte ich es jedoch als unabdingbar, in der Konzernleitung oder im Top-Management eines Bereichs nach einem „Götti“ zu suchen. Andernfalls könnte es leicht sein, dass das Projekt nicht die gebührende Beachtung findet. Ich wünsche den beiden Studierenden einen guten Abschluss ihrer Arbeit und werde mir das Zielsystem sobald als möglich vorführen lassen.“ _____________________________________________________________________________ 130 _____________________________________________________________________________ 9 Projektabschlussbericht Zu guter Letzt soll an dieser Stelle der Master Thesis gemäss der Hermes Phase ein Projektabschlussbericht verfasst werden. 9.1 Allgemeines Die Projektabschlussbeurteilung bietet Platz für die Erwähnung ergänzender Massnahmen und die Auswertung der Erfahrungen. Es ist ein Soll / Ist-Vergleich der sachlichen, terminlichen und finanziellen Projekt- und Vorgehensziele. Die Lehren und Erfahrungen aus dem Projekt werden dokumentiert und können auf diese Weise für zukünftige Projekte genutzt werden. 9.1.1 Projektverlauf Das Projekt wurde mit dem Projektantrag gestartet. Danach folgten die Phasen: Voranalyse Konzept Realisierung Einführung Abschluss In diesen Phasen wurden folgende Arbeiten durchgeführt. Phase Voranalyse Konzept Realisierung Einführung Abschluss Ergebnisse Pflichtenheft Erhebung IST-Zustandes Anforderungskatalog Business und Technologie Überprüfung der heutigen BI Positionierung und Evaluierung neuer Tools Interviews Definieren von Use Cases Voranalysebericht Lösungsvarianten mit Empfehlung Definition Ziel-Architektur Definition BI Plattform (Modul, Standards) Konzeptbericht Aufbau BI Plattform Durchführung PoC Betriebskonzept Supportprozesse Schulung Projektabschlussbericht Jede dieser Phasen wurde durch einen Abschlussbericht abgeschlossen. Während der ganzen Projektzeit trafen wir regelmässig unseren Projektbetreuer, um den aktuellen Stand der Arbeiten sowie die weiteren Vorgehensweisen zu besprechen. Während den Phasen Voranalyse, Konzept und Realisierung gab es jeweils ein Treffen mit dem Experten. _____________________________________________________________________________ 131 _____________________________________________________________________________ 9.1.2 Ziel 9.1.3 Analyse und Beurteilung der Ziele und Lösungen Das Ziel der Projektarbeit war der Aufbau einer zentralen Plattform zur Entlastung der operativen Systeme sowie der Bildung einer Basis für ein bereichsübergreifendes DWH. Diese Plattform soll modular und zukunftsorientiert sein. Zusätzlich wurden auch Definitionen und Vorgehensweisen zur Anbindung zukünftiger Quellsysteme erarbeitet. Die definierten Ziele konnten erreicht werden. Es wurde eine Plattform gebaut, welche die von den Interviewpartnern geforderten Ansprüche erfüllt. Zusätzlich deckt die Plattform auch die Anforderungen im Bereich Hochverfügbarkeit und Skalierbarkeit ab. Sicherheits- und Datenschutzanforderungen konnten durch Prozesse, User- und Rollenkonzepte ebenfalls abgedeckt werden. Durch das Proof of Concept konnte die Plattform auf ihr Tauglichkeit geprüft und es konnten bereits erste Erfahrungen gesammelt werden. Da die Wahl des ETL / ELT Tools gewissen firmeninternen Kriterien unterliegt, wie zum Beispiel aktuelle Unternehmenslizenzen, BI Strategie, u.v.a. kann es bei einem produktiven Einsatz der Lösung zu Abweichungen im Bereich der eingesetzten ETL / ELT Software für die Überführung ins DWH kommen. Allerdings stellt dies für die Plattform – dank dem modularen Aufbau - kein Problem dar. 9.1.4 Mittelbedarf 9.1.5 Termineinhaltung 9.1.6 Wirtschaftlichkeit Für die Projektarbeit wurde kein Budget gesprochen, weil das Projekt Teil einer Master Thesis ist und die Mitarbeiter für die erbrachten Leistungen nicht honoriert wurden. Somit entfällt eine Beurteilung der Kosteneinhaltung. Für den Aufbau des Proof of Concept konnte auf virtuelle Maschinen zurückgegriffen werden, die uns für eine kurze Zeit zur Verfügung gestellt wurden. weshalb es diesbezüglich auch zu keiner Kostenverrechnung kam. Die im Projektplan vorgesehenen Endtermine der Projektphasen konnten eingehalten werden. Ausnahme bildete das Proof of Concept, das entgegen den Erwartungen mehr Zeit in Anspruch nahm. Mit einem erhöhten Effort konnte dies jedoch wieder kompensiert werden. Es wurde keine Wirtschaftlichkeitsrechnung erstellt. Der Fokus lag hauptsächlich auf der Funktionalität und Machbarkeit des Projekts. Als einzige kommerzielle Aspekte sind die Lizenzund Wartungskosten eingeflossen. Vor einer allfälligen Einführung ist zwingend eine Wirtschaftlichkeitsrechnung seitens des Managements vorzunehmen. Dabei wird ersichtlich wie lange der ROI dauert. Zudem können erst mit der Wirtschaftlichkeitsrechnung konkrete Aussagen über die Kosten des Services gemacht werden. _____________________________________________________________________________ 132 _____________________________________________________________________________ 9.1.7 Konsequenzen Bei einer produktiven Einführung wären die Entwickler mehr einzubeziehen, als dies in dieser Master Thesis möglich war. Bei der Zusammenführung der Datenquellen in den ODS können die benötigten Tabellen relativ einfach identifiziert und überführt werden. Bei der Überführung der benötigten PL/SQL Packages werden jedoch viele nicht benötigte Funktionen und Prozeduren mit übernommen. Dies verschärft sich, indem in PL/SQL Packages wiederum Bestandteile anderer teilweise Schema übergreifenden PL/SQL Packages aufgerufen werden. Für einen produktiven Einsatz wären diese erheblich zu entflechten. Für die Überführung der Daten ins DWH muss ein ETL Tool definiert werden. Dies ist abhängig von den Entwicklungen bei der Schweizerischen Post. Die Wahl im PoC den ODI zu verwenden basierte darauf, erste Erfahrungen mit einem potenziellen Nachfolgeprodukt für den bereits eingesetzten Oracle Warehouse Builder sammeln zu können. Hinzu kommt, dass mit der kürzlich abgeschlossenen Unternehmenslizenz der ODI bereits enthalten ist. Zusätzlich bedarf es einer Schulung der betroffenen Abteilungen und ihrer verantwortlichen Personen. [siehe Kapitel 8.2.1 Schulung] Bevor man eine solche Plattform aufbaut, ist eine ausführliche Liste mit den zu übernehmenden Daten resp. Services zu erstellen. Damit kann die Plattform von Anfang an angemessen dimensioniert werden und muss nicht laufend skaliert werden. 9.1.8 Antrag Als nächstes wird diese Arbeit als Vorschlag für den Aufbau einer solchen Plattform in das Unternehmen einfliessen. Dort muss dann das weitere Vorgehen definiert und entsprechendes Budget gesprochen werden. _____________________________________________________________________________ 133 _____________________________________________________________________________ 10 Anhang Titel Themeneingabe Dokument Themeneingabe Master Thesis.PDF Interview Martin Schwab Interview_Martin_Sc hwab.pdf Interview Reto Pestoni Interview_Reto_Pest oni.pdf Interview Andreas Mannhart Interview_Andreas_ Mannhart.pdf Interview Aldo Derungs Interview_Aldo_Deru ngs.pdf Interview Roger Schindler Interview_Roger_Sc hindler.pdf Semesterarbeit CAS BI 01 Real Time und Near Real Time Data Integration von D.Massimi und P.Brändle Semesterarbeit CAS BI01.pdf _____________________________________________________________________________ 134
