Diplomarbeit Erstellung eines Konzepts zur Einführung eines

Fachhochschule Regensburg
Fachbereich Informatik und Mathematik
Studiengang Wirtschaftsinformatik
Diplomarbeit
(nach § 31 Rahmenprüfungsordnung und § 12 der
Allgemeinen Prüfungsordnung der Fachhochschule Regensburg)
Erstellung eines Konzepts
zur Einführung eines Business Intelligence Systems
Verfasser:
Florian Oppacher
Rauschbergstraße 15
83233 Bernau am Chiemsee
Matrikelnummer: 2266054
Aufgabensteller:
Prof. Dr. rer. nat., Dipl.-Math. Edwin Schicker
Zweitprüfer:
Prof. Dr. rer. nat., Dipl.-Math. Fritz Jobst
Firma:
Brückner Maschinenbau
Königsberger Straße 5-7
83309 Siegsdorf
Betreuer:
Josef Ramelsberger
Ausgabedatum:
28.03.2008
Abgabedatum:
28.12.2008
Business Intelligence
I
Inhalt
1 2 Motivation ............................................................................................................. 1 1.1 Umfeld der Diplomarbeit................................................................................. 1 1.2 Notwendigkeit der Diplomarbeit ..................................................................... 1 1.3 Herangehensweise und Aufbau der Arbeit ..................................................... 2 Theoretische Grundlagen ..................................................................................... 3 2.1 3 Grundbegriffe ................................................................................................. 3 2.1.1 Die Ressource Information ...................................................................... 3 2.1.2 Business Intelligence ............................................................................... 3 2.1.3 Data-Warehouse...................................................................................... 3 2.2 Qualität der Daten .......................................................................................... 6 2.3 Mehrdimensionale Sicht der Dinge................................................................. 8 2.3.1 Kennzahlen .............................................................................................. 9 2.3.2 Dimension ................................................................................................ 9 2.3.3 Hierarchisierung..................................................................................... 10 2.3.4 Würfel .................................................................................................... 10 2.4 Thema .......................................................................................................... 12 2.5 Operationen in multidimensionalen Cubes ................................................... 13 Informationsbedarfsanalyse ............................................................................... 17 3.1 Techniken ..................................................................................................... 17 3.1.1 Aufgabenanalyse ................................................................................... 17 3.1.2 Dokumentenanalyse .............................................................................. 17 3.1.3 Interviewtechniken ................................................................................. 18 3.1.4 Schriftliche Befragung ............................................................................ 18 3.1.5 Methodenkombinationen ....................................................................... 18 3.2 Fragebögen .................................................................................................. 19 3.2.1 Fragebogen für Berichte ........................................................................ 19 3.2.2 Fragebogen für Berichte ........................................................................ 22 4 Quelldatenanalyse ............................................................................................. 24 5 Modellierung eines Cubes .................................................................................. 26 5.1 Abbildung der Grundbestandteile einer Dimension ...................................... 26 5.2 Hierarchische Darstellung von Merkmalen ................................................... 26 5.3 Weitere Beschreibungen von Dimensionen ................................................. 27 Business Intelligence
6 7 5.4 Modellierung von Würfeln............................................................................. 28 5.5 Beispielmodellierung .................................................................................... 29 Implementierung ................................................................................................ 31 6.1 Cubeware Importer....................................................................................... 33 6.2 Operative Systeme ....................................................................................... 33 6.3 Extraktion ..................................................................................................... 33 6.4 Lademethoden ............................................................................................. 34 6.5 Aktualisierungszeitpunkte............................................................................. 35 6.6 Staging Area ................................................................................................ 35 6.7 Modellierung komplexer Sachverhalte ......................................................... 38 6.8 Views............................................................................................................ 39 6.9 Überführung in Würfel .................................................................................. 41 6.10 Datenbereitstellungsebene ....................................................................... 42 6.11 Metadaten ................................................................................................. 43 6.12 Präsentationsebene .................................................................................. 44 6.13 Ablage der verschiedenen Themen .......................................................... 45 Metadatenverwaltung ......................................................................................... 46 7.1.1 Generierung der Metadaten ................................................................... 47 7.1.2 Einlesen der Daten vom SQL Server in Access .................................... 49 7.1.3 Beschreibung der Metadaten für das Testsystem.................................. 53 7.1.4 Abgleich der Access Systeme untereinander ........................................ 53 7.2 8 9 II
Übersicht zur Metadatenverwaltung ............................................................. 53 Namenskonventionen ........................................................................................ 54 8.1 Bereichskürzel .............................................................................................. 54 8.2 Quellsysteme ............................................................................................... 54 8.3 Datenbanken ................................................................................................ 55 8.4 Tabellen aus den Quellsystemen ................................................................. 55 8.5 Views............................................................................................................ 56 8.6 Prozeduren auf dem SQL Server ................................................................. 57 8.7 Rollen für Berechtigungen im Active Directory ............................................. 58 8.8 Namen für Berichte in Cockpit ...................................................................... 58 Freigabekonzepte .............................................................................................. 59 9.1 Freigabeschritte bei Neuerstellung eines Würfels ........................................ 59 9.2 Freigabeschritte bei Aktualisierung eines Würfels ........................................ 61 9.3 Meldungssystem .......................................................................................... 63 Business Intelligence
10 III
Berechtigungskonzept ..................................................................................... 64 10.1 Elemente des Berechtigungssystems ....................................................... 64 10.2 Ausprägung der Rechte ............................................................................ 65 11 10.2.1 Active Directory .................................................................................. 66 10.2.2 Importbereich ..................................................................................... 66 10.2.3 Relationale Datenbank ....................................................................... 66 10.2.4 Multidimensionale Datenbank ............................................................ 66 10.2.5 Cubeware Teamserver ....................................................................... 67 Metadatenmanagement (MDM) ....................................................................... 68 11.1 11.1.1 Formular: Einlesen von SQL-Server ................................................... 69 11.1.2 Formular: Tabellen/ Views /Stored Procedures/ Rollen ...................... 69 11.1.3 Formular: Felder ................................................................................. 73 11.1.4 Formular: Meldungen ......................................................................... 77 11.2 12 Access Datenbank für das Entwicklungssystem (ADE) ............................ 68 Access Datenbank für das Produktivsystem (ADP) .................................. 79 11.2.1 Formular: Einlesen von SQL-Server ................................................... 80 11.2.2 Formular: Abgleich MDM .................................................................... 80 11.2.3 Formular: Tabellen/Views/SPs/Rollen ................................................ 84 11.2.4 Formular: Felder ................................................................................. 84 Konventionen für Cubeware Cockpit ............................................................... 86 12.1 Berichtskopf .............................................................................................. 86 12.2 Berichtskörper ........................................................................................... 86 13 Resümee ......................................................................................................... 88 14 Anhang ............................................................................................................ 89 14.1 Visio Modell: Berichtsdatum ...................................................................... 89 14.2 Visio Modell: Auftragseingang................................................................... 90 14.3 Literaturverzeichnis ................................................................................... 91 14.4 Abbildungsverzeichnis .............................................................................. 94 14.5 Abkürzungsverzeichnis ............................................................................. 96 Business Intelligence
1
1 Motivation
1.1
Umfeld der Diplomarbeit
Die Brückner-Gruppe mit ihren Hauptstandort in Siegsdorf ist ein Maschinen- und
Anlagenbauer mit ca. 1400 Beschäftigten. Die größte Tochterfirma ist die 1960
gegründete Brückner Maschinenbau GmbH & Co. KG. Mit einem Marktanteil von
über 50% ist sie Weltmarktführer bei Folienreckanlagen. „Gereckte Folien werden vor
allem
als
hochwertiges
Anwendungsbereichen
(z.B.
Verpackungsmaterial
Kondensator-
und
und
in
technischen
High-Tech-Bildschirmfolien)
eingesetzt“.1 Die Brückner Servtec GmbH erbringt weltweit Service-Leistungen (z.B.
Ersatzteile, Reparaturen, Software-Upgrades, Training) für Kunden.
Die 2007 erworbene Kiefel GmbH in Freilassing ist ein führender Hersteller für für
Serien- und Sondermaschinen zur Kunststoffverarbeitung in der Automobil-,
Medizintechnik- und Verpackungsindustrie. Die ebenfalls 2007 erworbene Kiefel
Extrusion GmbH in Worms ist spezialisiert auf Schlauchfolien-Extrusionsanlagen und
Folienwickelmaschinen.
Die IT-Abteilung (interne Bezeichnung: KEI) in Siegsdorf ist ein Dienstleister für alle
Firmen am Standort. Zu den Aufgabenfeldern zählen:
1.2
-
IT- Infrastruktur (Server, Netzwerk)
-
Kommunikation (Telefonie)
-
IT-Arbeitsplätze (Notebooks, PC, Drucker)
-
SAP Entwicklung und Betreuung
-
Business Intelligence
Notwendigkeit der Diplomarbeit
Ende des Jahres 2007 wurde von der Geschäftsleitung der Brückner Holding
beschlossen ein Business Intelligence (abgekürzt BI) System einzuführen.
Nach dem Beschluss fiel die Wahl nach einem detailierten Auswahlverfahren der
Abteilungen KEI und Controlling auf das Produkt der Firma Cubeware in Rosenheim.
Die Hauptgründe für die Entscheidung waren:
 Eine hervorragende Schnittstelle zu SAP
 Einfache Bedienbarkeit (im Vergleich zu den Konkurrenzprodukten)
 Nutzung des Micorsoft SQL-Servers für die Speicherung der Daten
1
Vgl. http://www.brueckner.com/German.74.0.html, 5.12.2008.
Business Intelligence
2
 Die räumliche Nähe der Firma zum Standort Siegsdorf
 Niedrige Investitionskosten
Eingeführt wurde das System zuerst für alle Firmen am Standort Siegsdorf. In naher
Zukunft sollen zudem alle anderen Tochterfirmen von der BI-Lösung profitieren.
Am Anfang begann man bei Brückner auf der sprichwörtlichen grünen Wiese.
Wissen und Erfahrung in diesem Bereich mussten erst langsam aufgebaut werden.
Schnell erkannte man die Notwendigkeit eines standardisierten Wegweisers zur
Planung und Durchführung von Business Intelligence Projekten (besonders für die
spätere Einführung bei den Tochterfirmen).
Daher wurde entschieden eine solche Anleitung in Form dieser Diplomarbeit
anfertigen zu lassen.
1.3
Herangehensweise und Aufbau der Arbeit
Zu Beginn dieser Arbeit werden theoretische Grundlagen erklärt um ein
Grundverständnis für die Thematik zu schaffen.
Der erste Schritt bei der praktischen Arbeit bestand darin, eine geeignete Methode
zu entwickeln, mit der der Informationsbedarf der Anwender im Unternehmen
ermittelt
wird.
Im
zweiten
Schritt
wurde
überprüft,
ob
der
gewünschte
Informationsbedarf mit den bestehen Quellsystemen abgedeckt werden kann. Um zu
visualisieren, wie die Daten in multidimensionaler Form gespeichert werden, wurden
Vorlagen geschaffen, die für eine Modellierung von Datenwürfeln verwendet werden.
Die Implementierung der BI-Software und die Schaffung einer Metadatenverwaltung
waren große Schwerpunktbereiche innerhalb der Diplomarbeit.
In
diesem
Zusammenhang
haben
sich
Problemstellungen
ergeben,
deren
Beantwortung für eine erfolgreiche Arbeit mit BI-Projekten notwendig war:
Um die Arbeit der Entwickler zu erleichtern und um eine einheitliche Nomenklatur zu
schaffen wurden Namenskonventionen festgelegt.
Die
im
Rahmen
der
Diplomarbeit
entwickelten
Freigabekonzepte
für
multidimensionale Würfel dienen als organisatorische Leitfäden.
Den Schutz der Daten im gesamten Business Intelligence System regelt das neu
entwickelte Berechtigungskonzept für alle Arten von Datenzugriffen.
Die am Ende der Diplomarbeit ausgearbeiteten Berichtskonventionen sorgen dafür,
dass alle BI-Berichte einem einheitlichen Standard entsprechen.
Business Intelligence
3
2 Theoretische Grundlagen
2.1
Grundbegriffe
Um ein besseres Verständnis für das Thema Business Intelligence zu gewährleisten
wird zuerst auf einige Begriffe eingegangen.
2.1.1 Die Ressource Information
Unternehmen sehen heute den Faktor Information als die entscheidende
Komponente um am Markt erfolgreich zu bestehen. In einer schnelllebigen Zeit ist es
enorm wichtig, unternehmensinterne und -externe Veränderungen frühzeitig zu
erkennen. Dafür müssen den Entscheidungsträgern Informationen in ausreichender
Qualität zum richtigen Zeitpunkt zur Verfügung stehen. Auf Grundlage dieser Daten
(und der Erfahrung der Entscheidungsträger) werden operative, taktische und
strategische
Entscheidungen
getroffen,
welche
für
die
Entwicklung
eines
Unternehmens zukunftsweisend sind.2
Nahezu alle Geschäftsprozesse sind IT-gestützt. Durch den gestiegenen Einsatz von
EDV-Systemen ist in den Unternehmen ein riesiger Pool an Daten vorhanden.
Dennoch
besteht
bei
den
Entscheidern
ein
Mangel
an
aussagekräftigen,
zuverlässigen Informationen. Dies liegt vor allem daran, dass die Daten nicht in der
entsprechenden Form und Struktur vorliegen.
2.1.2 Business Intelligence
Business Intelligence will den Mangel an verwendbaren Informationen beseitigen.
Allgemein bezeichnet der Begriff Business Intelligence den Einsatz von geeigneten
Applikationen
zur
Entscheidungsfindung
Unterstützung
im
der
Unternehmen.
operativen
Die
und
Datenbasis
strategischen
für
derartige
Analysesysteme liefern interne Leistungs- und Abrechnungsdaten sowie externe
Marktdaten.3
2.1.3 Data-Warehouse
Zur Versorgung der Business Intelligence Anwendungen mit verwendbaren
Informationen wird ein Data-Warehouse genutzt. Ein Data-Warehouse ist eine
zentrale
Datensammlung,
welche
2
Vgl. LEHMANN 2001, S.4.
3
Vgl. KEMPER, MEHANNA, UNGER 2006, S.4.
unter
Verwendung
von
geeigneten
Business Intelligence
4
Extraktionsmechanismen
aus
verteilten
und
unterschiedlich
strukturierten
Datenbeständen gespeist wird.
Die Daten müssen dabei so aufbereitet und aggregiert werden, dass sie hinsichtlich
der zu erwartenden Auswertungen in möglichst geeigneter Weise zusammengestellt
werden.4
Ein weiterer Nutzen eines Data-Warehouse ist, dass der geschaffene Datenpool für
andere Projekte im IT Umfeld verwendet werden kann. Wenn auf eine gemeinsame
Datenbasis zugegriffen wird, ist die Vergleichbarkeit der Daten erreicht. Konflikten im
Unternehmen wegen unterschiedlicher Aussagen aufgrund ungleicher Quelldaten ist
ein positiver Nebeneffekt, der nicht hoch genug eingeschätzt werden kann.
Definition: Inmon definiert ein Data-Warehouse als „subject-oriented, integrated,
nonvolatile
and
time-variant
management’s decisions”
collection
of
data
in
support
of
5
Demnach muss ein idealtypisches Data-Warehouse vier Funktionen erfüllen:
 Themenorientierung
Die Haltung der Daten richtet sich in operativen Systemen an die unmittelbare
Durchführung der Wertschöpfungsprozesse. Im Gegensatz dazu orientieren
sich die Daten an den Informationsbedürfnissen des Managements. Sie sollen
folgerichtig so gespeichert werden, dass sie sich an die relevanten Themen
eines Unternehmens richten.6
Typische Themenbereiche sind: Vertrieb, Materialwirtschaft, Produkte usw.
 Integration
Die Datenhaltung in den operativen Systemen ist meist auf unterschiedliche
Plattformen verteilt; eine „Managementsicht“ auf diese Daten ist nicht möglich.
Ein Data-Warehouse sorgt für die Integration der Daten in ein einheitliches
System. Die widerspruchsfreie Datenhaltung erweist sich in der Realität als
äußerst anspruchsvolle Aufgabe, „da die historisch gewachsenen operativen
Systeme mit den ihnen zugrunde liegenden Datenhaltungssystemen häufig
4
Vgl. RAUTENSTRAUCH 1997, S.104.
5
INMON 1996, S.33.
6
Vgl. KEMPER, MEHANNA, UNGER 2006, S.17.
Business Intelligence
Datenredundanzen,
5
Inkonsistenzen
und
semantische
Widersprüche
aufweisen“.7
 Beständigkeit
Die Daten in operativen Systemen sind oft kontinuierlichen Veränderungen
unterworfen und repräsentieren nur den jeweils aktuellen Zustand innerhalb
eines Geschäftsprozesses.8
Sind Daten einmal in ein Data-Warehouse geladen worden, so dürfen sie nicht
mehr gelöscht oder verändert werden. Damit ist sichergestellt, dass eine
einmal erstellte Auswertung jederzeit nachvollziehbar ist. Ausnahmen sind nur
gestattet, wenn es zu einer fehlerhaften Datenübernahme gekommen ist, oder
wenn Daten nicht mehr gebraucht werden.9
Damit das Datenwachstum nicht zu groß wird, sind auch für das DataWarehouse effektive Speichkonzepte zu implementieren. Haben Daten ein
bestimmtes Alter überschritten, so ist es beispielsweise sinnvoll sie in
komprimierter Form abzulegen oder anderweitig zu archivieren.10
 Zeitorientierung
In operativen Systemen werden Daten zeitpunktbezogen gespeichert. Die
Daten
in
einem
Data-Warehouse
sind
im
Gegensatz
dazu
häufig
zeitraumbezogen abgelegt, z.B. ein Tag, eine Woche oder ein Monat. Die
zeitraumbezogene Speicherung ist notwendig, um Trends zu erkennen und zu
untersuchen.11 Die längerfristige Betrachtung der Daten ist auch der Grund,
warum die Daten über einen größeren Zeitraum vorgehalten werden.
Während in operativen Systemen die Daten zwischen 60 bis 90 Tagen
gespeichert werden, haben die Daten in einem Data-Warehouse eine
Verweildauer bis zu 10 Jahre.12
7
Vgl. KEMPER, MEHANNA, UNGER 2006, S.18.
8
Ebd, S. 19.
9
Vgl. MUCKSCH, BEHNE 1997, S. 40.
10
Vgl. KEMPER, MEHANNA, UNGER 2006, S.19.
11
Ebd., S.18.
12
Vgl. INMON 1996, S. 36.
Business Intelligence
2.2
6
Qualität der Daten
Daten eines Unternehmens fallen währende des operativen Tagesgeschäfts an. Die
hier entstandenen sogenannten Bewegungsdaten sind aber für Analysezwecke nicht
geeignet. Für die Entscheidungsunterstützung müssen sie zuerst aufbereitetet und
verdichtet werden. Grundsätzlich können zwei Arten von Daten unterschieden
werden:
a) Operative Daten
Operative Daten (Bewegungsdaten) werden auch als „Daten des täglichen
Gebrauchs“
bezeichnet.
Diese
für
Administrations-,
Dispositions-,
und
Abrechnungszwecke genutzten Informationen werden in sogenannten OnlineTransaction-Processing Systemen (OLTP-Systeme) verwaltet. Beispiele hierfür sind
Buchhaltung, Lagerhaltung, Materialwirtschaft. Operative Daten zeichnen sich
dadurch aus, dass mehrere Benutzer im Teilhaberbetrieb sich der gleichen Systeme
und Daten bedienen.13 Der Transaktionsbetrieb sorgt dafür, dass die anfordernden
Funktionsbereiche schnell und zuverlässig mit Steuerungsdaten versorgt werden.
Die Daten sind an betriebswirtschaftliche Abläufe und Funktionen orientiert.14 Sie
sind für eine entscheidungsunterstützende Sicht auf ein Unternehmen nicht geeignet,
da die Granularität der Daten zu stark ist.
b) Dispositive Daten
Einen Entscheider interessiert eher die Sicht aus der „Vogelperspektive“, d.h. er
benötigt die Daten in einer für ihn auswertbaren (aggregierten) Form. Erfüllen Daten
dieser Anforderung, werden diese als dispositive Daten bezeichnet.
Die Auswahl der Daten, welche gesammelt werden, richtet bei dispositiven Daten
nicht nach Funktionsbereichen oder Geschäftsprozessen.
Ein direkter Durchgriff auf operative Daten ist aus Managementsicht nicht
zielführend. Die dispositiven Daten unterscheiden sich noch in anderen Punkten, wie
in folgender Tabelle zu sehen ist.15
13
Vgl. KEMPER, MEHANNA, UNGER 2006, S.14.
14
Vgl. LEHMANN 2001, S.10.
15
Modifiziert nach CHRISTMANN 1996, S C822.07.
Business Intelligence
Ziel
7
Charakteristika operativer
Charakteristika dispositiver
Daten
Daten
Bearbeitung eines
Information für das Management;
Geschäftsprozesses durch
Entscheidungsunterstützung
verschiedene Benutzergruppen
Ausrichtung
Zeitbezug
Detailierte, granulare
Verdichtete, transformierte
Geschäftsvorfalldaten;
Daten; umfassendes
Hohe Anzahl an Transaktionen
Metadatenangebot;
mit Zugriff auf wenige
Zugriff auf hohe Anzahl von
Datensätze
Datensätzen
Aktuell;
Unterschiedliche,
zeitpunktbezogen;
aufgabenabhängige Aktualität;
auf die Transaktion ausgerichtet
stichtagbezogene
Historienbetrachtung;
jederzeit nachvollziehbar und
reproduzierbar
Modellierung Altbestände oft nicht modelliert
(funktionsorientiert)
Sachgebiets- o. themenbezogen;
standardisiert;
endbenutzertauglich
Zustand
Update
Häufig redundant;
Konsistent modelliert;
inkonsistent
kontrollierte Redundanz
Laufend und konkurrierend
Ergänzend;
Fortschreibung abgleitender,
aggregierter Daten
Tabelle 1: Gegenüberstellung operativer und dispositiver Daten
Business Intelligence
2.3
8
Mehrdimensionale Sicht der Dinge
Für Entscheidungsträger ist es grundsätzlich interessant verschiedene Sichten auf
ein Thema zu haben.
Diese Funktionalität müssen managementunterstützende Systeme bieten, und zwar
in der Art, dass es nicht in einer reinen Ansammlung von Listen endet. Für den
Bereich Auftragseingang sind beispielsweise folgende Sichten interessant:
Aufträge 2007 in Euro
Auftrag
Land
Quartal
Auftragswert
1
China
Q1- 2007
10
2
Deutschland
Q2- 2007
3
3
Japan
Q2- 2007
6
4
Frankreich
Q3- 2007
4
Abbildung 1: Auftragswerte mit Sicht auf Aufträge
Aufträge/ Quartal 2007 in Euro
Q1 -2007
Q2 -2007
Q3 -2007
Q4 -2007
China
10
5
8
7
Deutschland
5
3
6
2
Japan
2
6
5
1
Frankreich
1
-
4
3
Abbildung 2: Auftragswerte mit Sicht auf Länder
Die Abbildungen liefern einen Überblick über die vorhandenen Auftragswerte. In der
ersten Abbildung sind die Zahlen pro Auftrag angegeben, im zweiten Fall ist der
Ausgangspunkt der Auftragseingang für die jeweiligen Länder. Beiden Fällen ist
gemein, dass sie Auftragswerte abbilden. Nur der Blickwinkel auf die Zahlen ist
unterschiedlich.
Um
entsprechende
mehrdimensionale
Abfrageoperationen
(Kapitel
2.5)
durchzuführen werden die Daten in multidimensionalen Strukturen abgebildet.16
Diese Art der Analyse wird mit dem Begriff OLAP (Online Analytical Processing)
16
Vgl. BAUER, GÜNZEL 2004, S. 102.
Business Intelligence
9
beschrieben. Bevor jedoch auf die verschiedenen Datenanalysen eingegangen wird,
ist eine vorherige Begriffsabgrenzung sinnvoll.
2.3.1 Kennzahlen
Die Entwicklung und Auswertung aussagekräftiger Kennzahlen zur Bewertung von
Entwicklungen
im
Unternehmen
ist
seit
jeher
ein
wichtiger
Bereich
der
Betriebswirtschaftslehre.
Kennzahlen – auch Measures oder Fakten genannt - sind numerische Werte, die
eine „konzentrierte Aussagekraft zur Diagnose, Planung, Überwachung und
Steuerung eines Systems“17 besitzen müssen. Sie haben die Aufgabe, relevante
Zusammenhänge in verdichteter und quantitativ messbarer Form wiederzugeben.18
Kennzahlen sind meist monetäre Werte oder Mengen.
Beispiele: Umsatzerlöse, Auftragswerte, Materialbestand
2.3.2 Dimension
Der Wert einer Kennzahl besitzt ohne zugehörigen semantischen Bezug keine
Aussagekraft.
Erst
wenn
die
Kennzahl
in
Verbindung
mit
anderen
Informationsobjekten steht, ist sie verwendbar. Im Umfeld von Business Intelligence
spricht man bei diesen Objekten von Dimensionen.
Dimensionen sind demnach beschreibender Natur. Sie ermöglichen unterschiedliche
Sichten auf Kennzahlen. Mit ihnen können die Kennzahlen gruppiert und analysiert
werden.19
Allgemein wird „im OLAP-Themenbereich unter einer Dimension eines Raums eine
ausgewählte
Entität
Anwendungsbereichs
verstanden,
definiert
wird
mit
und
Strukturierung dient."20
Beispiele: Land, Auftrag, Berichtsjahr
17
HEINRICH 1996, S.386.
18
Vgl. HORVÁTH 2006, S543.
19
Vgl. KEMPER, MEHANNA, UNGER 2006, S.62.
20
Vgl. BAUER, GÜNZEL 2004, S. 102.
der
die
eine
der
Auswertungssicht
eindeutigen,
eines
orthogonalen
Business Intelligence
10
2.3.3 Hierarchisierung
Innerhalb einer Dimension kann es zu einem hierarchischen Aufbau kommen, was in
Form einer Dimensionsstruktur ausgedrückt wird. Dies tritt dann auf, wenn die
Kennzahlen in verschiedenen Verdichtungsstufen betrachtet werden sollen. Diese
Stufen werden auch als Merkmale bezeichnet.
Beispiel: Der Dimension Firma können die Merkmale Gesamtfirma, Verkaufsbüro und
Verkäufergruppe zugeordnet werden.
2.3.4 Würfel
Als Grundlage für multidimensionale Analysen dient der sogenannte Würfel (oder
auch Cube, Data Cube, InfoCube, HyperCube genannt). Die Kanten des Würfels
werden von den Dimensionen eingenommen. Die Kantenlänge wird durch die die
Anzahl der zugeordneten Merkmale bestimmt. In den einzelnen Würfelzellen werden
ein oder mehrere Kennzahlen abgelegt. So wird jede Kennzahl durch die jeweils
dazugehörenden Dimensionen charakterisiert.21
Kombiniert man zwei Dimensionen so erhält man ein Rechteck, welches als Tabelle
dargestellt werden kann. Kombiniert man drei Dimensionen entsteht ein Würfel (engl.
Cube)
Abbildung 3: schematische Darstellung deines multidimensionalen Würfels
21
Vgl. BAUER, GÜNZEL 2004, S.105.
Business Intelligence
11
Besteht ein Würfel aus mehr als drei Dimensionen, so lässt er sich graphisch nur
schwer darstellen. Die folgende Abbildung zeigt eine mögliche Darstellung am
Beispiel Auftragseingang. Sie hat allerdings nur informativen Charakter. Die
Modellierung eines Würfels ist in Kapitel 5 beschrieben.
Abbildung 4: Darstellung eines Würfels mit mehr als drei Dimensionen
Business Intelligence
2.4
Thema
Als
Thema
werden
12
bei
Brückner
alle
zusammengehörenden
Zuständigkeiten und Geschäftsprozesse bezeichnet, die
Aufgaben,
für Auswertungen eines
bestimmten Bereichs (z.B. Auftragseingang, Bestandscontrolling) notwendig sind.
Dies betrifft alle Vorgänge von der Informationsbedarfsanalyse (Kapitel 3) bis hin zur
Gestaltung von Berichten für die Anwender (Kapitel 12)
Das Team wählte bewusst ein Thema, das sich am Besten für einen ersten Prototyp
eignet. Es sollte überschaubar sein und einen „leichten“ Einstieg bieten. Weiter sollte
bereits eine qualitativ gute Datenbasis (SAP) vorhanden sein, die nicht erst
aufgebaut werden muss. Das Thema Auftragseingang im Bereich Vertrieb schien
hier am geeignetsten. Zudem steht hier ein großes fundiertes Wissen zur Verfügung,
da
die
interne
Cotrolling
Abteilung
bereits
entscheidungsunterstützende
Auswertungen auf in Access seit vielen Jahren nutzt. In dieser Diplomarbeit werden
aus diesem Grund alle Beispiele am Thema Auftragseingang erläutert.
Business Intelligence
2.5
13
Operationen in multidimensionalen Cubes
Multidimensionale
Datenwürfel
bestehen
wie
beschrieben
aus
Kennzahlen,
Dimensionen und Hierarchien. Die Anzahl der Dimensionen ist theoretisch
unbegrenzt. Gängige Kennzahlen beschränken sich aber auf eine einstellige Anzahl
an Dimensionen. Würde eine Cube aus einer größeren Zahl Dimensionen bestehen,
so wäre eine Analyse mangels Durchschaubarkeit schlicht unmöglich.22
Mit einem Cube können verschiedene Operationen durchgeführt werden. Die
Ausführungen zu diesem Thema lehnen sich in modifizierter Form an eine
Abhandlung von M. Böhnlein und A. Ulbrich vom Ende.23
Im Folgenden werden die geläufigsten Operationen aufgezeigt. Die Beispiele
beziehen sich auch hier auf das Thema Auftragseingang. Aus Gründen der
Übersichtlichkeit gibt es eine Beschränkung auf drei Dimensionen.
a, Drill Down
Die Operationen Drill Down und Roll Up ermöglichen das Durchlaufen der
Verdichtungsstufen entlang der auf einer Dimension zugeordneten Merkmale. Beim
Drill Down steigt man von einem aggregierten Merkmal auf ein Merkmal mit der
nächsttieferen detailierten Verdichtungsstufe ab.
Abbildung 5 zeigt anhand von fiktiven Zahlen an, wie sich der Gesamtwert aller
Aufträge für Asien am Standort Siegsdorf auf die einzelnen Firmen verteilt.
Abbildung 5: Drill Down
b, Roll Up
22
Vgl. KEMPER, MEHANNA, UNGER 2006, S.95.
23
nach BÖHNLEIN, ULBRICH VOM ENDE, Jahr unbekannt.
Business Intelligence
14
Der Roll Up ist die zum Drill Down komplementäre Operation. Sie wechselt in die
jeweils höhere Verdichtungsstufe der Hierarchie.
Abbildung 6: Roll Up
c, Slice
Die Operation Slice entspricht dem Herausschneiden einer Scheibe aus einem
dreidimensionalen Cube. Als Ergebnis erhält man eine zweidimensionale Tabelle.
Beschränkt man sich auf einzelne Dimensionselemente verschiedener Dimensionen,
so kann die Slice Operation auch auf beliebig dimensionierte Cubes angewendet
werden.
Abbildung 7 zeigt eine Filterung der Aufträge aus Asien auf das Jahr 2007
Abbildung 7: Slice
d, Dice
Die folgende Abbildung stellt die Wirkungsweise des Dice Operators dar. Dice
schneidet einen Teilwürfel aus dem gesamten Cube. Das Beispiel zeigt eine Auswahl
der Auftragswerte für Asien, wobei nur die Jahre 2006 und 2007 angezeigt werden.
Die Firma BBT wurde in der Selektion ebenfalls nicht berücksichtigt.
Business Intelligence
15
Abbildung 8: Dice
e, Rotate
Die Drehung eines Cubes um eine Achse wird als Rotate bezeichnet. Durch die
Drehung erhält man unterschiedliche Sichten auf den Datenwürfel. Im Beispiel wird
die Sicht des Benutzers von der Kombination Firma/Land auf die Kombination Firma/
Jahr geändert.
Abbildung 9: Rotate
f, OLAP-Join
Der OLAP- Join verbindet zwei Cubes miteinander. Voraussetzung dafür ist, ähnlich
wie bei Fremdschlüssel in der relationalen Welt, dass beide Würfel gemeinsame
Dimensionen aufweisen. Abbildung 10 zeigt die Verbindung der beiden Würfel
Anzahl Aufträge und Anzahl Anfragen. Als Ergebnis erhält man einen neuen Würfel
mit den prozentualen Anteil der realisierten Aufträge.
Business Intelligence
Abbildung 10: OLAP-Join
16
Business Intelligence
17
3 Informationsbedarfsanalyse
Am Anfang eines jeden Business Intelligence Projekts muss in Erfahrung gebracht
werden, welche Anforderungen der Benutzer an die gewünschten Berichte und
Auswertungen hat. Diese werden mit der Informationsbedarfsanalyse ermittelt.
Die hier gewonnen Informationen werden für die Quelldatenanalyse (Kapitel 4) und
die Würfelmodellierung (Kapitel 5) gebraucht und wirken sich somit direkt auf das zu
entwickelnde Data-Warehouse (Kapitel 6) aus.
Definition: Mit
der
Informationsbedarfsanalyse
Anforderungen
(Informationsbedarf)
werden
der
die
informationellen
Benutzer
an
ein
Informationssystem erhoben und beurteilt. 24
3.1
Techniken
Um den Informationsbedarf für ein Data-Warehouse zu ermitteln gibt es eine Reihe
von Techniken. Eine Auswahl dieser wird im Folgenden dargestellt.
3.1.1 Aufgabenanalyse
„Bei der Aufgabenanalyse wird aufgrund von Entscheidungen, die durch die
verantwortlichen Personen gefällt werden, auf die dazu benötigten Informationen
geschlossen. Dispositive Entscheidungen zeichnen sich jedoch dadurch aus, dass
sie häufig unstrukturiert und einmalig auftreten“.25 Außerdem besteht die Gefahr,
dass Funktionalitäten aus rein operativen Prozessen mit einfließen. Ob diese
Methode zielführend ist, kann daher bezweifelt werden. 26
3.1.2 Dokumentenanalyse
Mit der Dokumentenanalyse wird versucht den Informationsbedarf aus vorhandenen
Dokumenten abzuleiten. Subjektive Faktoren sollen dabei so weit wie möglich
ausgegrenzt
werden.
Der
Nachteil
dieser
Technik
ist,
dass
sie
stark
vergangenheitsorientiert ist27 und daher keine Verbesserung der Informationslage zu
erwarten ist. Für zukünftige Entscheidungen reichen die vorhandenen Daten oft nicht
aus.
24
STRAUCH 2002, S. 71.
25
STRUCKMEIER 1997, S. 34.
26
Vgl. STRUCKMEIER 1997, S. 34.
27
Vgl. STRAUCH 2002, S. 72.
Business Intelligence
18
3.1.3 Interviewtechniken
„Generell zielen alle Interviewtechniken darauf ab, anhand von Gesprächen
zwischen einem Interviewer und einem oder mehreren Interviewpartnern die Fakten
eines Aufgabengebietes darzustellen“.28
Eine Schwierigkeit, die auftreten kann, ist einen geeigneten Interviewer zu finden der
über ein fundiertes Fachwissen verfügt. Problematisch kann es werden, wenn der
Interviewer in der Firmenhierarchie über den Befragten steht. Der Zeitbedarf und die
damit verbundenen Kosten dürfen auch nicht unterschätzt werden.29
3.1.4 Schriftliche Befragung
Mit Hilfe von Fragebögen wird bei der schriftlichen Befragung der Informationsbedarf
ermittelt. Ein großer Vorteil dieser Methode ist, dass Anwender auf kostengünstige
und
standardisierte
Weise
befragt
werden
können.
Da
für
die
Benutzer
unterschiedliche Informationen von Bedeutung sind, ist die Gestaltung eines
allgemein gültigen Fragebogens jedoch recht schwierig.30 Das Ergebnis der
Erhebung ist stark davon abhängig, dass die richtigen Fragen gestellt werden. Falls
die Fragen missverstanden werden, leidet die Qualität der erhobenen Ergebnisse.31
3.1.5 Methodenkombinationen
Um die Nachteile der erläuterten Techniken auszugleichen, wird versucht, die
Methoden zu kombinieren.32
Im Zuge dieser Diplomarbeit hat sich nach Absprache mit mehren Beteiligten für
Brücker eine Kombination aus Interview und schriftlicher Befragung als ideal
herausgestellt:
Ein Interviewer spricht mit den Entscheidungsträgern und Anwendern einen
Fragebogen durch und füllt ihn mit den Befragten gemeinsam aus.
Der Fragebogen hilft dabei, dass die Struktur bzw. die Qualität des Interviews
sichergestellt und das Ergebnis in einheitlicher Form dokumentiert wird.
Falls noch Fragen auftauchen, welche der Fragebogen nicht abdeckt, so kann der
Interviewer diese mit den Befragten abklären, schriftlich festhalten und das Ergebnis
den Fragebögen beifügen.
28
KOREIMANN 2000, S. 64.
29
Vgl. STRAUCH 2002, S.73.
30
Vgl. STRUCKMEIER 1997, S. 85.
31
Vgl. STRAUCH 2002, S.73.
32
Vgl. STRAUCH 2002, S.73.
Business Intelligence
3.2
19
Fragebögen
Für die Befragung der Anwender wurden zwei Arten von Fragebögen entworfen.
3.2.1 Fragebogen für Berichte
Da Auswertungen den Entscheidern in Form von Berichten präsentiert werden sollen
(Kapitel 12), ist es naheliegend abzufragen, welche Berichte tatsächlich gebraucht
werden. Für diesen Zweck wird ein eigener, identisch aufgebauter Fragebogen
ausgefüllt. Dieser wird in Abbildung 11 gezeigt.
Beschreibung:
Im Berichtskopf
werden Nummer und Name des Berichts eingetragen.
1
Zusätzlich wird noch das Datum vermerkt.
In
2
ist eine detailierte Anforderungsbeschreibung zu erbringen.
Im nächsten Feld
3
wird
eingetragen,
welche
Kennzahlen
im
Bericht
ausgegeben werden sollen. Beispiele hierfür sind Auftragswert, Umsatz, Preis usw.
Die Frage, welche Größen mit den Kennzahlen in Bezug gesetzt werden sollen, kann
in
4
beantwortet werden. Die Antwort soll als Hilfestellung dazu dienen, bereits
erste in Frage kommende Dimensionen für den Würfel in Erfahrung zu bringen.
Firma, Verkaufsbüro, Jahre sind beispielsweise Dimensionen, die für den Würfel
Auftragseingang in Frage kommen.
Falls bereits Berichte jeglicher Form zu dem abgefragten Thema existieren, so kann
das in
In
6
5
angekreuzt werden.
wird abgefragt, ob evtl. vorhandene Berichte manuell oder automatisch
erstellt werden.
Nach
dem
Berichtseigentümer
wird
in
7
gefragt.
Liegt ein Bericht in elektronischer Form vor, so wird durch ankreuzen in
verwendete System mitgeteilt.
8
das
Business Intelligence
Fehlende oder überflüssige Informationen des vorhandenen Berichts sind in
20
9
zu beschreiben.
Welche Funktionsträger bzw. Abteilungen den Bericht erhalten sollen, muss in
10
dargestellt werden.
Enthält der gewünschte Bericht sensible Daten, die nicht jeder sehen soll, so ist dies
11
in zu erläutern.
Unter
12
kann veranlagt werden, in welchen Abständen (täglich, wöchentlich,
monatlich usw.) ein neuer Bericht generiert werden soll.
Business Intelligence
21
1
2
3
4
5
6
7
8
9
10
11
12
Abbildung 11: Formular zur Berichtsanforderung
Business Intelligence
22
3.2.2 Fragebogen für Berichte
Abbildung 12 zeigt einen zweiten Fragebogen für das Thema dargestellt. Dieser ist
als eine Art Inhaltsverzeichnis für die Berichtsfragebögen zu sehen.
Beschreibung:
Thema, Datum, Unternehmen, Organisationseinheit und der Projektname müssen im
Kopf
1
Um
ein
des Fragebogens eingetragen werden.
tieferes
Verständnis
über
den
Organisationseinheit zu bekommen, werden in
In der Liste
3
wird
jeder
gewünschte
2
Verantwortungsbereich
einer
drei Hauptleistungen erläutert.
Bericht
mit
der
entsprechenden
Berichtsnummer eingetragen.
Nicht jeder Wunsch nach einem Bericht ist relevant für BI-Auswertungen. Falls ein
Bericht für Auswertungen nicht in Frage kommt, so wird dies in dem Fragebogen
unter
4
kenntlich gemacht.
Der Frage, bis wann die Lösung erstellt sein soll, wird in
5
nachgegangen.
Falls es bereits Aktivitäten zu dem abgefragten Thema gibt, lassen sich mögliche
Synergien oder Konflikte in
6
anführen.
Business Intelligence
23
1
2
4
3
5
6
Abbildung 12: Formular zur Anforderung eines Themas
Business Intelligence
4
24
Quelldatenanalyse
Die Quelldatenanalyse überprüft auf Basis der Informationsbedarfsanalyse, ob die
Daten in geeigneter Form in den operativen Systemen zur Verfügung stehen. Dazu
muss erst untersucht werden, welche geeigneten Datenquellen im Unternehmen
vorhanden sind.
Als Datenquelle versteht man Systeme, welche als Informationslieferant für ein DataWarehouse
dienen.
Diese
sind
oft
sehr
heterogen
und
müssen
nicht
notwendigerweise Datenbanken sein. Auch Textdateien oder Tabellen können in
Frage kommen. Die Beschaffenheit der in den Quellen enthaltenen Daten wirkt sich
dabei direkt auf die Qualität der Analyseergebnisse aus.33
Die Eignung einer Datenquelle hängt entscheidend von der Qualität ihrer Daten ab.
Im Folgenden werden einige Beispiele für Qualitätsmängel von Quelldaten
aufgelistet:34
 Inkorrekte Daten, verursacht durch Eingabe-, Mess- oder Verarbeitungsfehler
 Logisch widersprüchliche Daten
 Unvollständige, ungenaue bzw. zu grobe Daten
 Duplikate im Datenbestand
 Uneinheitlich repräsentierte Daten
 Veraltete Daten
 Für den Verwendungszweck irrelevante Daten
 Unverständliche Daten
 Fehlende Daten durch mangelhafte Pflege
Beispiele:
‐
Die hierarchische Zuordnung Verkäufergruppe auf Verkaufsbüro wurde nicht
erstellt.
‐
Der Importprozess verlangt einen Datentyp „String“ – die ankommenden
Daten sind aber vom Datentyp „Integer“
‐
Ein Feld in der Quelltabelle wurde durch führende Nullen aufgefüllt. Bei der
Zieltabelle sind die Nullen aber nicht vorgesehen.
33
Vgl. BAUER 2004, S.39.
34
Nach BAUER 2004, S. 40.
Business Intelligence
25
Falls eine oder mehrere dieser Mängel auftreten, ist es am sinnvollsten, diese direkt
im Quellsystem zu beheben. Wenn dies nicht möglich ist, können diese Mängel noch
bei der Extraktion der Daten ins Data-Warehouse beseitigt werden.
Wurden die geeigneten Quelldaten ermittelt, dann ist zu prüfen, ob der direkte Zugriff
auf die Daten möglich ist. Auf die vielen (oft proprietären) Formate der Quellsysteme
ist ein direkter Durchgriff auf die Daten eventuell nicht möglich.
Die Stärke der Software der Firma Cubeware liegt insbesondere in den sehr guten
Schnittstellen auf eine große Anzahl verschiedener Quellsysteme, so dass hier keine
Probleme zu erwarten sind. Auch ist nach bisherigen Erfahrungen eine sehr schnelle
Verarbeitung gewährleistet.
Es kann sein, dass rechtliche Barrieren überwunden werden müssen. So ist es
beispielsweise bei einem Zugriff auf personenbezogene Daten möglich, dass eine
Abstimmung mit dem Betriebsrat notwendig ist.
Business Intelligence
26
5 Modellierung eines Cubes
Wie im Kapitel 2.3 beschrieben, besteht ein Cube aus Dimensionen und Kennzahlen.
Je nach Bedarf können unterschiedliche Sichten auf die Daten erstellt werden. Um
die Komplexität eines Cubes im Griff zu behalten, wird vor Beginn der Realisierung
das entsprechende Datenmodell aufgebaut. Eine „Bauskizze“ soll die Anforderung
und die daraus resultierende Datenstruktur visualisieren.
Da bei Brückner das Programm Microsoft Visio eingesetzt wird, wurde beschlossen,
dieses Werkzeug für die Modellierung von Cubes zu verwenden.
Geeignete Vorlagen (sog. Shapes) für die Modellierung sind in der verfügbaren Visio
Version aber leider nicht enthalten. Deshalb wurden für diesen Zweck eigene
Vorlagen im Zuge dieser Diplomarbeit entwickelt. Diese lehnen sich teilweise an die
an die Arbeit von Michael Hahne an.35
5.1
Abbildung der Grundbestandteile einer Dimension
Für die Darstellung einer Dimension steht das Objekt Dimension zur Verfügung.
Innerhalb
dieses
Objekts
findet
sich
der
Dimensionsname.
Das Objekt Merkmal ist über eine gerichtete Kante mit dem Objekt Dimension
verbunden. Auch das Objekt Merkmal wird mit einen Namen dargestellt. Abbildung
13 zeigt das Grundkonstrukt zur Modellierung von Dimensionen
Abbildung 13: Aufbau Dimension mit Merkmal
Unter
Merkmal
versteht
man
ein
Objekt,
das
zur
Abbildung
von
Aggregationshierarchien verwendet wird.
5.2
Hierarchische Darstellung von Merkmalen
Die Reihenfolge wird grafisch durch die Rangordnung der Objekte von oben nach
unten ausgedrückt.
35
Nach HAHNE 2004, ab S.8.
Business Intelligence
27
Auf der obersten Hierarchiestufe wird ein Merkmalswert oft nicht aus einer
vorhandenen Datenbasis gespeist, sondern als Aggregation der darunterliegenden
Merkmalswerte berechnet. Mit dem Objekt Aggregation lässt sich dieser Fall
modellieren.
Abbildung 14: Hierarchie innerhalb einer Dimension
5.3
Weitere Beschreibungen von Dimensionen
Dimensionen lassen sich zusätzlich mit Hilfe von Attributen beschreiben. Attribute
haben einen ergänzenden Charakter. Sie sollen die Möglichkeit bieten, neben den
Merkmalen noch zusätzliche Elemente anzuzeigen. Für die Modellierung wird das
Objekt Attribut eingesetzt.
Attribute werden auf jeder Merkmalsstufe als zusätzliches Element angezeigt. Daher
werden die Attributobjekte nicht mit jedem einzelnen Merkmal verknüpft, sondern
direkt mit der Dimension verbunden. Jedes Attribut-Objekt besitzt einen Namen. Als
Verbinder dient ebenfalls eine gerichtete Kante.
Abbildung 15: Beschreibendes Attribut
Business Intelligence
28
Gibt es für ein Merkmal (wenige) Ausprägungen, die schon vorher bekannt sind, so
ist es oft interessant diese ebenfalls in die Modellierung mit einzubringen. Für solche
Fälle ist das Objekt Element vorgesehen. Dieses Objekt besitzt wie die anderen
Objekte einen Namen. Mit dem Merkmal sind die Ausprägungen über eine gerichtete
Kante verbunden.
Abbildung 16: Ausprägungen eines Merkmals
5.4
Modellierung von Würfeln
Das wichtigste Würfel-Objekt ist der Basis-Cube (Abbildung 17). Die einzelnen
Dimensionen werden um den Cube herum angeordnet. Im Objekt erfolgt die
Benennung des Themas und eine Auflistung der verwendeten Kennzahlen.
Die Dimensionen können detailliert modelliert werden. Ist die gesamte Darstellung
aber zu unübersichtlich, dann wird die Dimensionsmodellierung separat erstellt.
Abbildung 17: Darstellung eines Basiscube
Neben dem Basis-Cube gibt es noch den Multi-Cube. Diese Darstellung wird
verwendet, wenn ein Würfel auf mehrere andere Würfel aufbaut. Wie beim Basis-
Business Intelligence
29
Cube enthält das Objekt Multi-Cube einen Namen und eine Auflistung der
Kennzahlen.
M
Thema
Kennzahlen
B
Thema
Kennzahlen
B
Thema
Kennzahlen
Abbildung 18: Multi-Cube mit Basis-Cubes
Da auch Multi-Cubes eine eigene Dimensionierung haben, ist diese Darstellung nicht
vollständig. Es muss daher eine eigene Modellierung analog zu den Basis-Cubes
vorgenommen werden.
5.5
Beispielmodellierung
Im Folgenden wird eine mögliche Modellierung zum Thema Auftragseingang
aufgezeigt. Es handelt sich hier aber nur um einen Auszug mit zwei Dimensionen.
Das vollständige Modell kann in Kapitel 14.2 wieder gefunden werden.
Als einzige Kennzahl im Basis-Cube Auftragseingang wird der Auftragswert
ausgewertet. Um den Würfel herum werden die Dimensionen Firma und Belegart
angeordnet. Diese sind über gerichtete Kanten mit dem Basis-Cube verbunden.
Innerhalb der Dimension Firma sind die Aggregation Gesamt Firma und die
Merkmale Firma, Verkaufsbüro und Verkäufergruppe in hierarchischer Anordnung
aufgereiht. Weiter wird die Dimension über die Attribute Anzahl Positionen, Land,
Ort, Verkaufsorganisation, Vertriebsweg und Bezeichnung beschrieben.
Auf die Dimension Belegart ist nur ein Merkmal zugeordnet. Da es aber nur drei
Ausprägungen für die Belegart gibt, wurden diese über die Element-Objekte Ist, Plan
und Forecast beschrieben.
Business Intelligence
30
Abbildung 19: Ausschnitt einer Modellierung zum Auftragseingang
Business Intelligence
31
6 Implementierung
Zur Darstellung der verschiedenen Sichten auf die Kennzahlen soll ein wie in Kapitel
2.3.4 beschriebener multidimensionaler Würfel erstellt werden. Um die Informationen
in gewünschter Form zu erhalten, müssen die Daten aber erst aus den
Quellsystemen in ein Data-Warehouse extrahiert werden. In diesem Kapitel wird das
in der Brückner Holding eingesetztes Business-Intelligence-System beschrieben.
Abbildung 20 zeigt den Weg der Daten, bis sie in der Form vorliegen, damit
Entscheider im Unternehmen die notwendigen Analysen durchführen können.
Die gezeigte Darstellung zeigt das Business Intelligence System bei Brückner. Bei
anderen Firmen, welche ebenfalls die Software einsetzen kann die Implementierung
(insbesondere die Metadaten Verwaltung) abweichen.
Um die Qualität der Entwicklungsarbeit sicherzustellen und bei Erweiterungen und
Änderungen produktive Anwendungen nicht zu gefährden, wird bei Brückner die
Entwicklung vollständig auf einem separaten System (Testsystem) durchgeführt. Erst
bei der Freigabe wird das Thema auf das Produktivsystem übernommen.
Somit sind alle Komponenten, die unter die relationale und die multidimensionale
Ebene fallen, doppelt vorhanden. Beide Systeme werden unter den Begriff DataWarehouse (Kapitel 2.1.3) geführt.
Business Intelligence
Abbildung 20: Komponenten der Business Intelligence Lösung von Brückner
32
Business Intelligence
6.1
33
Cubeware Importer
Angefangen von der Extraktion der Daten aus den Quellsystemen bis zum Aufbau
der Würfel unterstützt die Software Cubware Importer die gesamte Steuerung und
Verwaltung.
Der Importer verfügt über eine sehr einfach zu bedienende und performante SAP
Schnittstelle. Die Software kann direkt auf Tabellen und BAPIs (standardisierte
Schnittstellen) zugreifen. Sie ist in der Lage aus anderen Quellsystemen wie Oracle,
SQL-Server, Access, Excel, Textdateien usw. Daten zu importieren. Der Zugriff auf
bereits erstellte Würfel ist selbstverständlich ebenso möglich.
6.2
Operative Systeme
Aus den operativen Systemen kommen die Rohdaten für das Data-Warehouse.
Bei Brückner wird hauptsächlich SAP eingesetzt. Tochterfirmen in der Brückner
Holding verwenden neben SAP auch andere Systeme, wie „AS400“-Anwendungen
oder einfache Access und Excel Dateien.
Für das Thema Auftragseingang existieren die Daten überwiegend in SAP. Diese
werden mit Daten aus einer Access Anwendung des internen Controllings
angereichert.
6.3
Extraktion
Unter Extraktion versteht man die Überführung der Daten aus den Quellsystemen in
die sogenannte "Staging Area". Die Staging Area besteht aus einer relationalen
Datenbank. Bei Brückner wird der SQL-Server von Microsoft eingesetzt. Für die
Übernahme der Daten gibt es zwei Möglichkeiten. Entweder werden die Daten direkt
ohne Veränderungen übernommen, oder sie werden vor der Speicherung in der
Datenbank einer Bereinigung unterzogen. Dies hat folgenden Hintergrund:
In der Konstruktionsphase wird ein einheitliches Datenschema für das DataWarehouse festgelegt. Da die Daten mit unterschiedlichen Datenstrukturen aus den
operativen Quellsystemen kommen, müssen diese an das jeweilige Datenschema im
Data Warehouse angepasst werden. Aber auch eventuell auftretende Anomalien und
Inkonsistenzen werden an dieser Stelle beseitigt. Folgende Probleme können
beispielsweise auftreten:36
36
Vgl. WIKIPEDIA1, 15.9.2008.
Business Intelligence

34
Anpassung von Datenwerten
z.B. unterschiedliche Bezeichnungen für das Geschlecht: m, f wird zu
männlich, weiblich

Anpassung von Maßeinheiten
z.B. Umrechnungen zwischen unterschiedlichen Währungen: Dollar in Euro

Eliminierung von Duplikaten

Fehlende Werte

Anpassungen der Datentypen
z.B.: Umwandlung Datentyp Integer (Zahl) in varChar (Text)
Der Importer ermöglicht es Extraktionen über eine graphische Oberfläche anhand
von Mappings auf einfache Weise durchzuführen.
Das Füllen der Staging Area ist aber auch über klassisches SQL möglich. Die SQL
Abfragen werden dann in Form von Prozeduren abgelegt. Die Prozeduren sind auf
dem SQL-Server in der Staging Area gespeichert und lassen sich sowohl manuell als
auch zeitgesteuert ausführen.
Abbildung 21: Mapping für eine Extraktion
6.4
Lademethoden
Beim Laden der Daten werden zwei unterschiedliche Methoden unterschieden:
Business Intelligence
35
a, Vollständiges Laden
Der komplette Datenbestand aus den operativen Systemen wird beim vollständigen
Laden neu extrahiert. Die alten Daten in der Staging Area werden dabei
überschrieben.
b, Inkrementelle Laden
Beim inkrementellen Laden werden nur die Daten aus den operativen Systemen
geladen, welche Änderungen erfahren haben. Dadurch werden Ressourcen und
Laufzeit eingespart. 37
Da das BI-System von Brückner sich noch in der Einführungsphase befindet und die
genutzte Datenmenge sich noch in Grenzen hält, werden die Daten vollständig
geladen.
Erhöht
sich
das
Datenvolumen
im
Laufe
der
Zeit,
muss
aus
Laufzeitgründen sicherlich auch auf das inkrementelle Laden zurückgegriffen
werden.
6.5
Aktualisierungszeitpunkte
Die Aktualisierung des Datenbestandes erfolgt in vorher festgelegten Zeitabständen.
Sie
kann
stündlich,
täglich,
wöchentlich
oder
monatlich
je
nach
Aktualitätsanforderungen erfolgen.
Die zeitliche Steuerung der Aktualisierungen übernehmen im Importer sogenannte
Jobs. Ein Job kann die bereits erwähnten Mappings und Prozeduren zu einem vorher
terminierten Zeitpunkt anstoßen.
6.6
Staging Area
Bevor mit dem Laden der Daten in die Staging Area begonnen werden kann, müssen
die jeweiligen Tabellen in einer Datenbank des SQL-Servers erzeugt werden.
Das Erzeugen der Tabellen ist über den Importer möglich. In der Praxis hat sich
allerdings herausgestellt, dass das direkte Anlegen der Tabellen in der Datenbank
praktikabler ist.
Nach dem Laden der Daten stehen diese zur weiteren Verarbeitung zur Verfügung.
In dem so entstandenen "Datenpool" stehen aber nicht nur Daten zu einem
bestimmten Thema (z.B. Auftragseingang) zur Verfügung. Es soll vielmehr eine
37
EGGER 2004, S.139.
Business Intelligence
36
Datenbasis geschaffen werden, auf die alle bestehenden und zukünftigen Cubes
Zugriff haben. Auf diese Weise wird verhindert, dass Daten redundant gespeichert
werden. Auch wird die Zeit, welche für den Import verbraucht wird, wesentlich
verringert, da weniger Datensätze eingelesen werden müssen.
Um die Übersichtlichkeit zu wahren, wird für jedes Thema eine eigene Datenbank
angelegt. Interne Tests zeigten, dass beim Zugriff auf Informationen über verteilte
Datenbanken kein signifikanter Zeitverlust messbar ist.
Bevor die Daten genutzt werden können, müssen in einem weiteren Schritt die
Tabellen aufbereitet werden, denn nicht alle gewünschten Daten sind in den
operativen Quellsystemen enthalten. Manche Informationen müssen erst neu
berechnet oder aus vorhandenen Datensätzen abgeleitet werden.
Für derartige Aktualisierungen, muss es eine Möglichkeit geben, logische
Zusammenhänge und mathematische Berechnungen durchzuführen. Der Importer
bietet für diesen Zweck an, eigene Skripte mit der Skriptsprache TCL zu verfassen.
Die so verfassten Skripte werden wiederum über im Importer hinterlegte Jobs
angestoßen. Wie bei der Extraktion werden die Jobs zeitgesteuert aufgerufen.
Eine Kombination von Scripten im Importer und Prozeduren auf dem SQL-Server ist
ebenfalls möglich. Umfangreiche Scripts werden bei Brückner grundsätzlich im SQL,
anstatt des proprietäre TCL, entwickelt.
Abbildung 22 zeigt ein Beispiel für die Scriptsprache TCL. Es werden Datensätze auf
Vorhandensein überprüft.
# Behandlung von neuen Sätzen auf Kopfebene
# Verarbeitung aller Kopf-Sätze, die nicht im alten Datenbestand vorkommen
#
set sqlKopfImp "SELECT VBAK_VBELN FROM V_ERP.TMP_AUFKOPF WHERE
VBAK_VBELN NOT IN (SELECT VBAK_VBELN FROM V_ERP.AUFKOPF)"
SQL_DB BeginTrans
SQL_DB NewResultSet AuftragskopfImport
AuftragskopfImport Open $sqlKopfImp
AuftragskopfImport BindCol {VBAK_VBELN} BelNrK
Business Intelligence
37
SQL_DB2 Connect
while {[AuftragskopfImport MoveNext] == 1} {
set ex "EXEC V_ERP.AUFHEAD_NEW '$BelNrK'"
if {[SQL_DB2 ExecSQL $ex] ==1} {
SQL_DB2 Commit
} else {
SQL_DB2 Rollback
}
}
#SQL_DB2 Commit
DeleteResultSet AuftragskopfImport
SQL_DB2 Disconnect
SQL_DB Disconnect
Abbildung 22: TCL Script
Für eine vereinfachte Umsetzung der Aktualisierungsaufgaben ist es oft sinnvoll,
temporäre Tabellen zu verwenden. Abbildung 23 zeigt den Ablauf zur Verarbeitung
einer Aktualisierungslogik mit Hilfe von Aktualisierungstabellen. Ist die Abarbeitung
abgeschlossen, werden die temporären Hilfstabellen wieder geleert. Die Struktur der
Tabellen an sich bleibt aber erhalten.
Abbildung 23: Extraktion mit Hilfe einer Aktualisierungstabelle
Business Intelligence
6.7
38
Modellierung komplexer Sachverhalte
Wie beschrieben können nicht alle Felder in der Staging Area aus operativen
Quellsystemen gefüllt werden. Manche notwendigen Daten sind noch nicht
vorhanden und müssen daher erst erstellt werden.
Der logische Komplexitätsgrad, der bei der Generierung dieser Daten zugrunde liegt,
ist oft sehr hoch. Für ein besseres Verständnis ist es sinnvoll und nicht selten auch
unverzichtbar, dass die logischen Zusammenhänge und benötigten Regeln vorher
grafisch modelliert werden.
Wie bei der Modellierung eines Würfels hat sich auch hier Microsoft Visio als ideales
Werkzeug herausgestellt.
Die Abbildung in Kapitel 14.1 zeigt ein Modell für das Setzen eines Berichtsdatums.
Kurzbeschreibung:
Wenn von einem Kunden ein Auftrag eingeht, dann wird er bei Brückner nicht
automatisch als Auftragseingang geführt, da es vorkommen kann, dass er es sich
nach kurzer Zeit „dann doch anders überlegt“. Erst wenn die erste Anzahlung
eingegangen ist, wird der Auftrag durch Eintragen eines Effektivdatums in das SAPSystem als „echter“ Auftragseingang angesehen und beim Laden in das DataWarehouse berücksichtigt.
Das Effektivdatum kann aber nicht immer als Berichtsdatum für den Auftragseingang
in den BI-Berichten verwendet werden. Es ist möglich, dass ein Vertriebsmitarbeiter
im September das Effektivdatum für einen Auftrag auf einen Tag im August setzt. So
würden bereits abgeschlossene Monatsstatistiken verändert werden. Auftragswerte
für vergangene Monate dürfen sich aber nicht ändern. Daher wurde folgendes
festgelegt: Wenn eine Auftrag neu in das Data-Warehouse geladen wird und dieser
ein Effektivdatum eines vergangenen Monats besitzt, so wird er mit dem
Berichtsdatum gleich dem ersten des aktuellen Monats geführt.
Business Intelligence
6.8
39
Views
Views sind virtuelle Tabellen. „Sie existieren nicht real, erscheinen dem Benutzer
aber wie „normale“ Tabellen.“38 Sie sind in Wirklichkeit aber nur Verknüpfungen auf
„echte“ Tabellen. Mittels SQL-Abfrage können sie wie jede andere physikalische
Tabelle angesprochen werden.
Da ein Thema letztendlich als Cube abgebildet werden soll, ist es am einfachsten
Views zu erstellen. Die Views werden dabei so zusammengestellt, dass die Daten
möglichst direkt in die multidimensionale Datenbank überführt werden können.
Da ein Würfel immer aus den Komponenten Dimension und Fakten besteht, werden
zwei Arten von Views unterschieden. Am häufigsten werden Views als Datenbasis
zum anschließenden Aufbau einer Dimension verwendet. Diese sog. DIM-Views
(siehe Kapitel 8: Namenskonventionen) beinhalten alle Information, wie sie aus der
Modellierungsphase bekannt sind:
-
Merkmale
-
Ausprägungen von Merkmalen
-
angezeigte Attribute
Abbildung 24 zeigt auszugsweise einen View, dessen Inhalt die Grundlage für den
Aufbau der Dimension Geschäftsbereiche bildet.
Geschäfts-
Geschäfts-
Geschäfts-
bereich
bereichstgrp
bereichsgrp_BEZ
BIO
BIO_OTH
Biogas Others
LV
2400
BIO
BIO_OTH
Biogas Others
Prov
2400
BIO
BIO_OTH
Biogas Others
Sonstiges
2400
BIO
BIO_PLA
Biogas Plants
BIO_ETH
2400
BIO
BIO_PLA
Biogas Plants
BIO_GAS
2400
BIO
BIO_PLA
Biogas Plants
BIO_MAS
2400
BIO
BIO_SER
Biogas Service
ET_Pers
2400
Produktgruppe Buchungskeis
Abbildung 24: View zum Aufbau der Dimension Geschäftsbereiche
38
SCHICKER 2000, S.71.
Business Intelligence
40
Um einen Würfel zu vervollständigen, bedarf es noch der Kennzahlen. Diese sind in
sog. CUB-Views abgebildet. Cub-Views stellen folgende Informationen zur
Verfügung:
-
Kennzahlen
-
Merkmalsdaten aller Dimensionen auf der untersten Hierarchiestufe
-
Ausprägung der Merkmale
Der View für den Cube Auftragseingang enthält beispielsweise folgende Spalten:
Währung,
Hauswährung,
Firma,
Mengeneinheit,
Auftrag,
Effektivdatum, Berichtsdatum, Auftragswert (Ursprungswährung),
Produktgruppe,
Auftragswert
(umgerechnet), usw.
Die Views werden im Importer graphisch dargestellt. Die Erstellung dieser ist dort
allerdings nicht möglich. Für die Definition der Views werden gespeicherte
Prozeduren auf dem SQL-Server genutzt. Als Scriptsprache für die Prozeduren dient
T-SQL. Das Starten der Prozeduren übernimmt der Importer mittels vordefinierter
Jobs.
USE [BBI_V_Auftragseingang]
GO
/****** Objekt:
View [V_ERP].[vw_Dim_Geschaeftsbereiche]
Skriptdatum:
06/18/2008 12:50:35 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER VIEW [V_ERP].[vw_Dim_Geschaeftsbereiche]
AS
SELECT
GESCHAEFTSBEREICH
AS
Grp01Geschaeftsbereich,
GESCHBEREICHSGRP AS Grp02GeschBerGrp,
GESCHBEREICHSGRP_BEZ
AS
ATTGeschBerGrpBez,
PRODUKTGRUPPE AS ATTProduktgruppe, BUCHUNGSKREIS
FROM
ERP.GESCHAEFTSBEREICHE
Business Intelligence
GROUP
BY
41
GESCHAEFTSBEREICH,
GESCHBEREICHSGRP,
GESCHBEREICHSGRP_BEZ, PRODUKTGRUPPE, BUCHUNGSKREIS
Abbildung 25: Prozedur zur Generierung eins Views in der Scriptsprache T-SQL
6.9
Überführung in Würfel
Die Überführung der Daten aus der relationalen Ebene der Views in die
multidimensionale Ebene der Würfel gestaltet sich mit dem Importer ähnlich einfach
wie bei der Datenextraktion. Über eine graphische Oberfläche lassen sich
Verbindungen zwischen den Feldern der DIM-Views und den Merkmalen der
Dimensionen ziehen. Die so definierten Jobs werden vom Importer gestartet und
ermöglichen einen Aufbau der Dimensionen. Wie alle Jobs lassen auch diese eine
zeitgesteuerte Nutzung zu.
Analog wird bei den Verbindungen zwischen den Cub-View und den Kennzahlen
vorgegangen. Kleinere Transformationen wie das Formatieren von Feldern können
an dieser Stelle vorgenommen werden. Prinzipiell können die Felder hier auch
stärkeren Transformationen unterzogen werden. Grundsätzlich sollte aber darauf
geachtet werden, dass die Daten in den Views bereits der Form entsprechen, wie sie
in den Dimensionen gebraucht werden.
Abbildung 26: Überführung des View Geschäftsbereiche in die entsprechende Dimension
Business Intelligence
42
6.10 Datenbereitstellungsebene
Nach der Datenübernahme müssen die Informationen in multidimensionaler Form
zur
Verfügung
stehen.
Einige
Anbieter
von
BI-Lösungen
bieten
"echte"
multidimensionale Datenbanken als proprietäre (herstellerspezifische) Lösungen an.
Weitestgehend haben sich am Markt aber Systeme durchgesetzt, bei denen
multidimensionale Würfel auf zweidimensionale, relationale Datenbanken abgebildet
werden. Die Speicherung der Daten erfolgt dann meist nach dem sogenannten Starbzw. Galaxy-Schema (als Erweiterung des Star-Schemas). Die Software der Firma
Cubeware verfolgt ebenfalls diesen Weg.
a, Star-Schema
Das
Star-Schema
setzt
sich
aus
einer
Kennzahlentabelle
und
mehreren
Dimensionstabellen zusammen.39
Der Name Star beruht auf die sternförmige Anordnung der Dimensionstabellen und
der Kennzahlentabelle.
Abbildung
27
zeigt
ein
(nicht
vollständiges)
Auftragseingang anhand eines ERM-Diagramms.
Abbildung 27: Star Schema am Beispiel Auftragseingang
39
KURZ 1999, S.166.
Star-Schema
zum
Thema
Business Intelligence
43
Auf eine Normalisierung in der 3. Normalform wird verzichtet. Um der 3. Normalform
zu genügen, müsste jedes Merkmal in der Dimensionstabelle in einer eigenen
Tabelle abgelegt werden. Dies hätte aber zur Folge, dass für eine Abfrage viel mehr
Tabellenverknüpfungen (sog. "joins") generiert werden müssten, was wiederum die
Abfragen stark verlangsamen würde. Durch den bewussten Verzicht auf die 3.
Normalform wird daher ein immenser Geschwindigkeitsvorteil geschaffen.40 Erkauft
wird
diese
Performancesteigerung
allerdings
mit
einem
größeren
Speicherplatzbedarf durch die redundante Datenhaltung. Neben dem PerformanceVorteil bietet das Star-Schema auch noch eine einfache und schnelle Wartung der
entstandenen Tabellen.
b, Galaxy Schema
Besteht ein BI System aus mehreren Würfeln so ist es sehr wahrscheinlich, dass
verschiedene
Kennzahlentabellen
mit
strukturidentischen
Dimensionstabellen
verbunden sind. Aus Konsistenzgründen ist eine mehrfache Verwendung von
Dimensionstabellen empfehlenswert.41 Verbindet man die einzelnen Sterne (Würfel)
über die gemeinsamen Dimensionen, so entsteht eine Anhäufung von Sternen.
Daher der Name Galaxy.
6.11 Metadaten
Im Bereich Data Warehouse versteht man unter dem Begriff Metadaten „gemeinhin
jede Art von Informationen, die für den Entwurf, die Konstruktion und die Benutzung
eines Informationssystems benötigt werden.“42
Umgangssprachlich kann man Metadaten auch als „Daten über Daten“ bezeichnen.
Für die Dokumentation des Themas sind diese Daten wichtiger Bestandteil: Welche
Daten fallen an und vor allem welche Art von Information geben sie wieder. Will
beispielsweise ein Anwender wissen, welche Bedeutung der Eintrag im Feld X in der
Tabelle Y hat, muss es eine Möglichkeit geben, sich zu informieren. Es ist aber nicht
nur interessant zu wissen, welche Daten es gibt, sondern auch wie sie entstehen.
Die Quell-Daten sind im Cube über mehrere Stufen verdichtet und evtl. interpretiert.
Für
eine
Beschreibung
Verarbeitungslogiken
und
aller
um
durchgeführten
Ergebnisse
40
Vgl. KEMPER, MEHANNA, UNGER 2006, S.63.
41
Ebd, S.64.
42
Vgl. BAUER, GÜNZEL 2004, S. 328.
Transformationen
nachvollziehen
zu
können
und
bzw.
Business Intelligence
Abweichungen
zu
44
analysieren,
ist
die
Dokumentation
wichtig.
In
der
Metadatenverwaltung (Kapitel 7) können alle die Beschreibungen hinterlegt werden,
die der Anwender bzw. Entwickler für dokumentationswürdig befindet.
Metadaten könne dabei auf drei Arten genutzt werden:43
 Passiv als konsistente Dokumentation der verschiedenen Aspekte eines DataWarehouse-Systems.
 Aktiv indem semantische Aspekte wie beispielsweise Transformationsregeln
als Metadaten gespeichert werden, die dann von der entsprechenden
Komponente in Data-Warehouse interpretiert und ausgeführt werden. Dieser
Fall wird als metagetriebener Prozess bezeichnet
 Semiaktiv,
indem
beispielsweise
Tabellendefinitionen
in
der
Metadatenverwaltung gespeichert werden. Die Metadaten werden dann von
einem entsprechenden Werkzeug ausgewertet und für Überprüfungszwecke
eingesetzt. Ein Anfrage-Parser überprüft beispielsweise die Existenz eines
Datenbankattributs anhand dieser Metadaten. Zur Ausführung eines direkten
Prozesses werden die Metadaten allerdings nicht verwendet.
Die Verwaltung der Metadaten wird genauer in den Kapiteln 7 und 11 behandelt.
6.12 Präsentationsebene
Cubware Cockpit bietet eine einfache, intuitive Benutzeroberfläche mit vielfältigen
Darstellungs- und Analysemöglichkeiten. Neben dem Zugriff auf mehrdimensionale
Würfel können auch relationale Datenquellen eingebunden werden.
„Das flexible Berichtslayouting unterstützt die Gestaltung von ansprechenden und
übersichtlichen Darstellungen der Unternehmensdaten. Neben den Analysetechniken
Slice&Dice und DrillDown&RollUP der mehrdimensionalen Daten in Tabelle und
Grafik kann mit Hilfe von Filtern und Aktionen die Datenauswahl individuell gesteuert
und parametrisiert werden.“44
Wie Cockpit Berichte aussehen und welche Anforderungen sie erfüllen müssen kann
in Kapitel 12 nachgelesen werden.
Je nach Zielgruppe der Berichte dürfen diese mehr oder weniger angepasst werden.
So sind für die Geschäftsleitung relativ starre Berichte vorgesehen, wohingegen
Anwender, die im operativen Geschäft eingebunden sind, mehr Gestaltungsfreiheit
haben.
43
Ebd.
44
CUBEWARE 2008, S. 15.
Business Intelligence
45
Die Benutzer sind aber nicht nur an Cockpit gebunden. Auch andere FrontendSoftware wie Excel kann auf die Daten im Data-Warehouse zugreifen und diese
entsprechend darstellen. Da die Cockpit Lizenzen im Vergleich zu Excel erheblich
mehr kosten, wird Excel bei machen Themen zum Einsatz kommen.
6.13 Ablage der verschiedenen Themen
Bei Brückner wird für jedes Thema (wie z. B. der Auftragseingang) sowohl relational,
als auch mehrdimensional, eine eigene Datenbank angelegt. Das heißt, dass jeder
Würfel in einer eigenen Datenbank gespeichert wird. Zudem werden alle
Stammdaten in einer eigenen Datenbank erfasst.
Bei Stammdaten handelt es sich um Grund- oder Referenzdaten welche selten eine
Änderung erfahren. Typische Stammdaten sind beispielsweise Kreditoren, Debitoren
und der Materialstamm.
Der Name der jeweiligen Datenbank richtet sich nach dem jeweiligen Thema.
Näheres dazu in Kapitel 8 (Namenskonvention).
Business Intelligence
46
7 Metadatenverwaltung
Wie beschrieben sind Daten im Data-Warehouse in zweidimensionaler (Tabellen,
Views) oder mehrdimensionaler Form gespeichert. Für einen Entwickler ist es sehr
hilfreich, wenn ihm beispielsweise eine Beschreibung der oftmals kryptischen
Feldnamen zur Verfügung steht. Auch reicht die Dokumentation im Quellcode von
Prozeduren oft nicht aus um nach einigen Monaten noch nachvollziehen zu können,
welche Transformationen, Filter oder Prozesse damit abgebildet werden sollen. Eine
ausführliche Dokumentation mit der Möglichkeit Bilddokumente anzufügen, ist an
dieser Stelle sehr wünschenswert.
Das System von Cubeware bietet leider keine Komponente zur Generierung oder
Verwaltung von Metadaten.
Daher wurde im Rahmen dieser Diplomarbeit ein eigenes Tool dafür programmiert,
welches firmenintern unter den Namen MDM (Metadaten Management) geführt wird.
Aufgrund der weiten Verbreitung in der Firma wurde MDM überwiegend im Microsoft
Access implementiert.
Die Metadaten werden bei Brückner nur für Dokumentationszwecke genutzt. Für eine
aktive oder semiaktive Nutzung (Kapitel 6.11) wird MDM nicht verwendet.
Bei Brückner existiert sowohl für den Produktiveinsatz, als auch für die Entwicklung,
ein eigenes Data-Warehouse. Beiden Systemen steht ein eigener (virtueller) Server
zur Verfügung.
Business Intelligence
7.1
47
Zeitlicher Ablauf der Metadatenverwaltung
Abbildung 28 zeigt den zeitlichen Ablauf der Metadatenverwaltung.
Abbildung 28: zeitlicher Ablauf der Metadatenverwaltung
7.1.1 Generierung der Metadaten
Um den Inhalt eines Data-Warehouse dokumentieren zu können, müssen zuerst die
existierenden Daten abgefragt werden.
Zu diesem Zweck wurden Prozeduren programmiert, welche die Struktur der
einzelnen Datenbanken (jeder Würfel hat ja eine eigene) abfragt und in einer eigenen
Datenbank abspeichert. Diese Prozeduren können in zeitlich festgelegten Intervallen
vom Importer angestoßen werden. Eine ausreichende Aktualität (täglich) ist daher
gegeben. Die Prozeduren laufen sowohl auf dem Entwicklungs- als auch auf dem
Produktivsystem ab, so dass für beide Systeme die Metadaten gespeichert werden.
Innerhalb der Prozeduren werden SQL Befehle verwendet, die auf das sogenannte
Information Schema der jeweiligen Datenbank zugreifen. Das Information Schema
besteht aus Systemtabellen, in denen alle relevanten Informationen einer Datenbank
abgelegt sind. Es können Daten wie Tabellenname, Feldname, Primärschlüssel,
Prozedurname usw. abgerufen werden.
Business Intelligence
48
Abbildung 29 zeigt in einem ERM Modell, welche Daten abgefragt und auf dem SQL
Server gespeichert werden
Abbildung 29: ERM-Modell: Metadaten auf SQL-Server
Die auf diese Weise erfassten Daten betreffen die relationalen Ebene des DataWarehouse. Da die Views die Basis für einen Würfel bilden (Kapitel 6.8), ist über
diese auch eine Beschreibung des multidimensionale Teils des Data-Warehouse
möglich.
Business Intelligence
49
7.1.2 Einlesen der Daten vom SQL Server in Access
Nachdem die Struktur im Data-Warehouse auf dem Entwicklungssystem, als auch
auf dem Produktivsystem, gespeichert worden ist, werden diese Informationen in
zwei Access Datenbanken45 überführt.
Beide Access Systeme befinden sich in einem zentralen Verzeichnis auf einem
Firmenserver. Der Zugriff auf dieses Verzeichnis wurde auf Personen beschränkt, die
in das Projekt involviert sind.
Das Einlesen der Daten in Access aus der Metadaten-Datenbank auf dem SQLServer übernimmt ein in VBA programmiertes Script, das manuell angestoßen wird.
Dabei werden nur die Daten aktualisiert, die im Access noch nicht vorhanden sind.
Falls Teile der Struktur auf dem SQL-Server (z.B. ein Feld in einer Tabelle) gelöscht
werden, so wird im Access automatisch die Gültigkeit (Gültigkeitsdatum) auf den Tag
des Einlesens gesetzt.
45
Für jedes System eine eigene
Business Intelligence
Abbildung
30
zeigt
50
in
einem
ERM
Modell
Metadatenverwaltung in Access enthält.
Abbildung 30: ERM-Modell: Metadatenverwaltung in Access
alle
Informationen,
die
die
Business Intelligence
51
Beschreibung:
Thema
ID_DB
DB_Name
Primärschlüssel der Tabelle „Thema“
Der
Name
der
Datenbank.
Laut
Namenskonvention entspricht dies auch dem
Themennamen des Projekts.
View
ID_View
View_Name
ID_DB
Beschreibung *
Primärschlüssel der Tabelle „View“
Der Name des Views
Fremdschlüssel auf Tabelle „Thema“
Die Beschreibung des Views
Prozedur
ID_Prozedur
Pro_Name
ID_DB
Beschreibung *
date_gültig
Primärschlüssel der Tabelle „Prozedur“
Der Name der Prozedur
Fremdschlüssel auf Tabelle „Thema“
Die Beschreibung der Prozedur
Gültigkeitsdatum
einer
Prozedur.
Standardmäßig auf 31.12.9999 gesetzt. Wird
eine Prozedur vom SQL Server gelöscht,
dann wird beim Abgleich hier das Datum des
aktuellen Tages gesetzt.
Gibt an wann die Prozedur das letzte Mal
geändert wurde.
Date_geändert
Meldung
MeldungsNr*
ID_DB
Name*
Status*
Entwickler*
Eindeutige Meldungsnummer. Wird beim
Erstellen einer Meldung von SAP vergeben
Fremdschlüssel auf Tabelle „Thema“
Der Name der Meldung
Der aktuelle Status der Meldung
Der in der Meldung betroffene Entwickler
Rolle
ID_Rolle
Rolle
Primärschlüssel der Tabelle „Rolle“
Name der Rolle.
Jeder Datenbank sind bestimmte Rollen mit
entsprechenden Rechten zugeordnet
Tabelle
ID_Tabelle
Tabelle_Name
ID_DB
Beschreibung *
Primärschlüssel der Tabelle „Tabelle“
Der Name der Tabelle „Tabelle“
Fremdschlüssel auf Tabelle „Thema“
Die Beschreibung der Tabelle
Feld
ID_Feld
Primärschlüssel der Tabelle „Feld“
Business Intelligence
52
Feld_Name
ID_Tabelle
Datentyp
Datentyp_Länge
Primärschlüsselfeld
Der Name des Feldes
Fremdschlüssel auf die Tabelle „Tabelle“
Datentyp des Feldes z.B.: NVARCHAR
Länge des Datentyps
Gibt an ob es sich bei dem Feld um ein
Primärschlüsselfeld handelt (Boolean)
Beschreibung *
Die Beschreibung des Feldes
Kurzbeschreibung * Kurzbeschreibung
des
Feldes.
Laut
Namenskonvention wird im Feldnamen der
Name der Ursprungstabelle mitgeführt. Da
diese Namen oft etwas kryptisch sind, wurde
eine Kurzbezeichnung eingeführt.
date_gültig
Gültigkeitsdatum eins Feldes. Standardmäßig
auf 31.12.9999 gesetzt. Wird ein Feld vom
SQL Server gelöscht, dann wird beim Abgleich
hier das Datum des aktuellen Tages gesetzt.
Direktzuordnung
Gibt an ob der Feldinhalt direkt aus dem
Quellsystemübernommen
wurde.
Standardmäßig wird beim Abgleich dieses
Feld auf „JA“ gesetzt
BI-Feld *
Gibt an, ob der Feldinhalt durch eine
Transformation entstanden ist
Filter
ID_Filter
ID_Feld
Beschreibung *
Primärschlüssel der Tabelle „Filter“
Fremdschlüssel auf Tabelle „Feld“
Beschreibung des Filters.
Transformation ID_Transformation
ID_Feld
Beschreibung *
Grafik *
Primärschlüssel der Tabelle „Transformation“
Fremdschlüssel auf Tabelle „Feld“
Beschreibung des der Transformation
Wurde zum besseren Verständnis der Logik
einer Transformation ein Visio File oder
Ähnliches erstellt, so kann es an dieser Stelle
verlinkt werden.
* = Diese Felder werden manuell vom Entwickler gefüllt.
Tabelle 2: Beschreibung des ERM-Modells für die Metadatenverwaltung
Business Intelligence
53
7.1.3 Beschreibung der Metadaten für das Testsystem
In der Access Datenbank mit den Metadaten für das Entwicklungssystem erfolgt die
manuelle Beschreibung der Metadaten über Eingabeformulare. Die Ausgabe der
gesamten Dokumentation ist über Formulare und Berichte möglich.
Eine genaue Beschreibung der Access Oberfläche mit allen Möglichkeiten der
Datenein- und ausgabe kann in Kapitel 11 nachgelesen werden.
7.1.4 Abgleich der Access Systeme untereinander
Nachdem ein Entwickler seine Arbeiten am Entwicklungssystem abgeschlossen hat,
portiert er seine Ergebnisse auf das Produktivsystem. Da die Datenstruktur von
Entwicklungs- und Produktivsystem dann (weitestgehend) gleich sind und die
Metadaten bereits für das Testsystem dokumentiert worden sind, sollen die
Beschreibungen der Metadaten für das Produktivsystem nicht mehr erneut manuell
eigegeben werden müssen. Dazu wurde ein VBA-Script programmiert, das die
Beschreibungen der beiden Access Systeme miteinander synchronisiert.
7.2
Übersicht zur Metadatenverwaltung
Für ein besseres Verständnis wird an dieser Stelle nochmal dargestellt, wie die
einzelnen Komponenten der Metadatenverwaltung zusammenhängen.
Abbildung 31: Übersicht zur Metadatenverwaltung
Business Intelligence
54
8 Namenskonventionen
Wie in Kapitel 6 dargestellt besteht ein Data Warehouse System aus einer Vielzahl
von Objekten. Datenbanken, Tabellen, Felder, Views usw. müssen festgelegt und in
der Metadatenverwaltung gepflegt werden. Um bereits bei der Namensgebung eine
Unterscheidung der verschiedenen Objekte zu erreichen, müssen die Namen einer
bestimmten Konvention folgen. Auch muss bei machen Objekten wie dem
Datenbanknamen oder dem Tabellennamen sofort erkennbar sein, welchem Thema
(Cube) sie zugeordnet sind. Daher wurden im Zuge der Diplomarbeit folgende
Konventionen festgelegt.
8.1
Bereichskürzel
Für die verschiedenen Bereiche im BI-System wurden folgende Bereichskürzel
festgelegt:
V=Vertrieb
L=Logistik
C= Controlling
F= Finance
P=Projekt/ Produktdaten
8.2
Quellsysteme
Für die folgenden Quellsysteme wurden bereits Kürzel festgelegt. Es wurde dabei
auf die in den jeweiligen Firmen gebräuchliche Namensgebung zurück gegriffen.
ERP= SAP System der Brückner Group
P013= SAP System Kiefel Freilassing
Dienen Text-, Excel-, Access-Files oder ähnliche Dokumente als Quellsystem, wird
als Präfix die jeweilige Abteilungsbezeichnung verwendet.
Schema:
"Abteilungsbezeichnung" + "." + "Dokumentname"
Bsp.:
KCC.GeschBereiche.txt
Business Intelligence
8.3
55
Datenbanken
Allgemein:
Der Datenbankname lautet gleich dem aus der Konzeption (Viso) bekannten
Themennamen.
Das Schema stellt eine Abkürzung für den Firmennamen dar.
Folgende Firmen- Schemen wurden bereits festgelegt:
-
BBI= Brückner Siegsdorf
-
KF= Kiefel Freilassing
Schema:
"Firmen-Präfix"
+
"_"
+
"Bereichskürzel"
+
"Themenname"
Bsp.: BBI_V_Auftragseingang
8.4
Tabellen aus den Quellsystemen
Tabellennamen
Allgemein:
Werden Tabellen 1:1 aus dem Quellsystem übernommen, so wird der jeweilige
Tabellenname (+ vorangestelltes Schema) wieder verwendet.
Bei Namen neuer Tabellen (z.B. durch die Zusammenführung von mehreren
Tabellen des Quellsystems) soll ein Richtwert von sechs Zeichen eingehalten
werden.
Schema:
‐
Tabellenname Bewegungsdaten
"Bereichskürzel" + "_" + "Quellsystem" + "." + "Tabellenname"
Bsp.: V_ERP.Aufpos (neu benannte Tabelle)
V_ERP.VBPA
‐
(aus dem Quellsystem 1:1 übernommene Tabelle)
Tabellenname Stammdaten
"Quellsystem" + "." + "Tabellenname"
Bsp.: ERP.Projekt (neu benannte Tabelle)
ERP.TVGRT (aus dem Quellsystem 1:1 übernommene Tabelle)
Business Intelligence
‐
56
Tabellenname für temporäre Tabellen
"TMP" + "." + "Tabellenname"
Bsp.:
TMP.Aufpos
Feldnamen
Allgemein:
Werden Felder 1:1 aus dem Quellsystem übernommen, so wird der jeweilige
Feldname (+ vorangestelltes Schema) wieder verwendet.
Bei neu erstellten Feldern soll darauf geachtet werden, dass für den Feldnamen ein
Richtwert von sechs Zeichen eingehalten wird.
Schema:
‐
Feldname bei direkter Übernahme aus Quellsystem
"Tabellenname des Quellsystems" & "_" & "Feldname im Quellsystem"
Bsp.: VBAP_VBELN
‐
Feldname bei neu erstellten Feldern
"BI" & "_" & "Feldname"
Bsp.: BI_Quelle
8.5
Views
View-Name
Allgemein:
Für den View-Namen wird der aus der Konzeption (Visio) bekannte Dimensionsname
verwendet. Eine Ausnahme dazu bilden Views, welche zur Ausführung einer
(Transformations-) Logik verwendet werden.
Schema:
‐
View-Name für Dimensionen
"Bereichskürzel" & "_" & "Quellsystemkürzel" & "." & "vw" & "_" & "DIM"
& "_" & "Konzeptname"
Bsp.: V_ERP.vw.Dim_Firma
Business Intelligence
‐
57
View-Name für Cubes
"Bereichskürzel" & "_" & "Quellsystemkürzel" "." & "vw" & "_" & "CUB"
&
"_" & "Konzeptname"
Bsp.: V_ERP.vw.Cub_Auftrag
‐
View-Name für Views zur Unterstützung einer (Transformations-) Logik
"Bereichskürzel" & "_" & "Quellsystemkürzel" "." & "vw" & "_" & "Logik
Kürzel" & "_" & "Logik-Name"
Bsp.: V_ERP.vw_Diff_Kundenauftragspos_old_new
View-Feldname
Allgemein:
Werden Felder 1:1 aus Tabellen der Staging Area übernommen,
so wird der
jeweilige Feldname wiederverwendet. Bei Feldnamen für Views vom Typ "Cub" soll
ein prägnanter, sprechender Name verwendet werden
Schema:
‐
View-Feldname Merkmale
"View-Feldname"
Bsp.: VBAK_VKBUK
‐
View-Feldname für Attribute
"ATT" & "_" & "View-Feldname"
Bsp.: ATT_VBAK_VKORG
‐
View-Feldname bei Views vom Typ "Cub"
"View-Feldname"
Bsp.: Produktgruppe
8.6
Prozeduren auf dem SQL Server
Allgemein:
Für Prozeduren sollen aussagekräftige, sprechende Namen verwendet werden.
Business Intelligence
58
Schema:
"Bereichskürzel" & "_" & "Quellsystem" & ".“ + "Prozedurname"
Bsp.: V_ERP.Berichtssatz_aktualisieren
8.7
Rollen für Berechtigungen im Active Directory
Allgemein:
Im Active Directory werden lokale und globale Gruppen erstellt. Für den Zugriff auf
alle Tochterfirmen muss als Firma das Kürzel BTH verwendet werden.
Als Recht kommen folgende Abkürzungen in Frage:
R = Read
M = Modify
W = Write
Schema:
‐
Rollenname für globale Gruppe
"G“ & "_" & "BBI“ & "_“ & "Name des Cubes“ & "_" & "Firma" & "_" &
"Recht"
Bsp.: G_BBI_Auftragseingang_BMS_R
‐
Rollenname für lokale Gruppe
"L" & "_“ & "S“ & "_“ & "BBI & "_“ & & "DB“ & "Name der Datenbank“
& "Recht“
8.8
Namen für Berichte in Cockpit
Allgemein:
Im Namen vorangestellt ist das Thema, welches im Bericht behandelt wird. Sind
mehrere Themen betroffen, so werden alle Themen benannt. Bei Bedarf können
Themen auch abgekürzt werden.
Schema:
"Thema“ & "_" & "Sicht auf Thema"
Bsp.: Auftragseingang_Auftragseingang nach Kunden
EinkaufsCo_BestandCo_Lagerbestände nach Marktsegmente
Business Intelligence
59
9 Freigabekonzepte
Alle Zahlen die in Form von BI- Berichten zur Verfügung gestellt werden sollen,
müssen vorher von verschiedenen Instanzen freigegeben werden, bevor sich für
Analysezwecke genutzt werden können.
Sowohl für die erstmalige Freigabe eines Themas, als auch für die laufende
Aktualisierung
eines
Würfels
wurden
im
Rahmen
dieser
Diplomarbeit
Freigabeprozesse entwickelt.
9.1
Freigabeschritte bei Neuerstellung eines Würfels
Um die Qualität der Datenbasis sicherzustellen, muss ein Würfel erst freigegeben
werden, bevor er für Analysen bereitgestellt wird.
Nach der erstmaligen Erstellung eines Würfels muss die Fachabteilung diesen auf
Inhalt und Form überprüfen. Zugleich muss die Controlling Abteilung neben dem
Würfel auch die darauf basierende Datenbasis in der Staging Area (Kapitel 6.6) auf
Inhalt und Form kontrollieren.
Geprüft wird auf Erfüllung die ursprünglich gestellten Anforderungen (z.B.
Vollständigkeit, Konsistenz, Aktualität).
Hat eine der beiden Abteilungen Mängel zu melden, so muss die IT-Abteilung die
gewünschten Änderungen vornehmen. Danach erfolgt eine erneute Überprüfung.
Wenn der Würfel und die Datenbasis alle Prüfungen bestehen, dann gilt das Thema
als freigegeben.
Business Intelligence
60
Würfel
entwickelt
XOR
V
Fachabteilung
Freigabe
erteilt
Prüfung
multidimensionale
Daten(Inhalt+Form)
Prüfung
multidimensionale
und relationale
Daten(Inhalt+Form)
XOR
XOR
Freigabe nicht
erteilt
Freigabe nicht
erteilt
Freigabe
erteilt
V
Änderung auf
mulitdimensionaler
und/oder
relationaler Ebene
Controlling
IT-Abteilung
V
Thema ist
freigegeben
Abbildung 32: Freigabeprozess bei Neuerstellung eines Würfels
Business Intelligence
9.2
61
Freigabeschritte bei Aktualisierung eines Würfels
Für das Management der Brückner Holding ist es notwendig, Einblick auf
Kennzahlen in allen Unternehmen des Konzerns zu haben. Die Daten der
Tochterunternehmen entstehen in vollständig seperaten Systemen. Sie werden in
Eigenverantwortung der Organisationseinheiten ermittelt und bereitgestellt.
Dabei haben die Fachabteilungen (insbesondere von Tochterfirmen mit Standort
nicht in Siegsdorf) ein Interesse daran, dass Daten nicht ohne Prüfung und Freigabe
an hierarchisch höhere Instanzen weitergeleitet werden. Um diesen Wunsch zu
entsprechen, wurde der entsprechende Freigabeprozess entwickelt.
Die Fachabteilung erstellt für die Weitergabe der Daten spezielle Import-Tabellen.
Deren Struktur und Inhalt wurde zuvor definiert, um eine reibungslose Übernahme in
das Data-Warhouse zu gewährleisten. Grundsätzlich wird hier das CSV-Format
eingesetzt.
Nach der Erstellung wird die Tabelle von der Fachabteilung nach Form und Inhalt
geprüft. Falls Mängel gefunden werden, so werden diese beseitigt. Anschließend
erfolgt eine erneute Überprüfung.
Sind alle Vorgaben erfüllt, dann wird die Tabelle auf einem zentralen Server der
Brückner Holding abgelegt.
Vor der Übernahme in das BI-System überprüft die Controlling Abteilung die
abgelegten Tabellen auf die richtige Form (korrekte Aufbau, Daten in den richtigen
Spalten, Namenskonventionen etc.).
Daraufhin legt das Controlling die Tabelle in einem eigens dafür vorgesehen
Importbereich ab. Dieser Importbereich kann sowohl eine Datenbank, als auch ein
Verzeichnis sein.
Wurde die Tabelle im Importbereiche abgelegt, so ist dies für die IT-Abteilung das
Signal, dass die Tabelle freigegeben wurde und bereit für das Einlesen in das DataWarehouse ist.
Dabei kann es trotz mehrmaliger vorheriger Überprüfungen vorkommen, dass Fehler
auftauchen, die erst an dieser Stelle auffallen. Geschieht dies, beispielsweise durch
Inkonsistenzen, so muss das Controlling diese beheben, bevor ein neuer
Importversuch unternommen wird.
Business Intelligence
62
Import-Tabelle
erstellt
XOR
Prüfung
Tabelle
(Form+Inhalt)
Fachabteilung
Nacharbeit
Tabelle
Fachabteilung
XOR
Ablage auf
Server
Prüfung
Tabelle (Form)
Controlling
XOR
Ablage
Tabelle in
Importbereich
Einlesen der
Daten in das
DataWarehouse
IT-Abteilung
Nacharbeit
Tabelle aus
Importbereich
XOR
DataWarehouse ist
aktualisiert
Einlesen nicht
erfolgreich
Abbildung 33: Freigabeprozess bei Aktualisierung eines Würfels
Controlling
Business Intelligence
9.3
63
Meldungssystem
Ebenso wie das gesamte Projekt wird auch der Freigabeprozess bei der
Neuerstellung und bei Änderungen eines Würfels durch ein in SAP verfügbares
Meldungssystem unterstützt. Das System besteht aus zwei Teilen.
Am Anfang eines jeden Projekts (entspricht im BI-Umfeld einem Thema, für das
Analysen ermöglicht werden sollen) wird eine Meldung aufgesetzt. Diese verfügt
über eine automatisch vergebene Nummer und einen manuell eingetragenen Titel.
Ein Title könnte etwa lauten „BBI_Auftragseingang_Siegsdorf“
Weiter werden noch wichtige Informationen angegeben wie:
‐
Was soll mit dem Projekt erreicht werden
‐
Um welche Art des Projekts handelt es sich z.B. BBI (Brückner Business
Intelligence), SAP, ELO, usw.
‐
Welche Kosten werden kalkuliert
‐
Welcher Bereich im Unternehmen ist betroffen
‐
Welche Zuständigkeit ist gegeben (Projektleitung)
Während des Projekts können für die Zuteilung und Erledigung von Aufgaben
beliebig viele Maßnahmen einer Meldung zugewiesen werden. Somit ist eine
durchgehende Dokumentation des gesamten Projektverlaufs gewährleistet.
Für den Freigabeprozess bei der Erstellung eines Würfels ist beispielsweise
folgender Maßnahmenkatalog vorstellbar:
‐
Maßnahme: Test durch Key User
→ Prüfung der multidimensionalen Daten auf Inhalt und Form durch die
Fachabteilung.
‐
Ändern Maßnahme: Setzen des Status der Maßnahme auf „abgeschlossen“
→ entspricht der Freigabe des Würfels durch die Fachabteilung
‐
Maßnahme: Produktivsetzung durch die IT-Abteilung
→ die Daten werden für die Anwender freigegeben.
Optional können jederzeit Zwischen- und Infobescheide an Beteiligte verschickt
werden.
Business Intelligence
64
10 Berechtigungskonzept
Besonders in Hinblick auf die Vertraulichkeit sensibler Daten ist ein strukturiertes
Berechtigungskonzept unabdingbar. Die Geschäftsleitung der Brückner Holding darf
beispielsweise den Auftragseingang über alle Firmen hinweg einsehen, während für
die Geschäftsführung einer Tochterfirma nur die Werte für deren Bereich abrufbar
sein sollen. Auch rechtlich können sich Zwänge für Zugriffsbeschränkungen ergeben.
Zum Beispiel müssen nach Datenschutzbestimmungen personenbezogene Daten
aus dem Personalmanagement geschützt werden.
Um den Schutzbedürfnissen innerhalb der Firma und auch des Gesetzgebers
gerecht zu werden, wurde im Zuge der Diplomarbeit ein Berechtigungskonzept
entworfen.
10.1 Elemente des Berechtigungssystems
Das Berechtigungssystem für das BI-System bei Brückner ist vier-stufig aufgebaut.
Abbildung 34: Berechtigungssystem
„Active Directory ermöglicht es, ein Netzwerk entsprechend der realen Struktur des
Unternehmens oder seiner räumlichen Verteilung zu gliedern“. 46
46
Vgl. WIKIPEDIA2, 20.9.2008
Business Intelligence
65
Mit Hilfe dieses Dienstes ist es möglich jeden Anwender in eine oder mehrere
sogenannten globalen Gruppen einzuordnen. Den globalen Gruppen sind wiederum
lokale Gruppen zugeordnet.
Jeder dieser lokalen Gruppen werden bestimmte Rechte (z.B. Lese-/ oder
Schreibrechte auf ein Verzeichnis) eingeräumt. Die Authentifizierung eines
Anwenders erfolgt über eine Passwortabfrage nach dem Einschalten des
Arbeitsrechners.
Als Importbereich wird das geschützte „Zwischenlager“ für Quelldaten der
Tochterfirmen bezeichnet. An dieser Stelle werden Daten abgelegt, die für die
Weiterverarbeitung in einen multidimensionalen Würfel vom Controlling freigegeben
worden sind. Der Importbereich kann sowohl ein Verzeichnis als auch eine
Datenbank sein. Je nach dem werden die entsprechenden Rollen und Rechte
vergeben.
Die im Active Directory hinterlegten lokalen Gruppen werden im relationalen Teil des
Data-Warehouse bestimmte Rollen zugeordnet.
Den Rollen der multidimensionalen Datenbanken werden die globalen Gruppen des
Active Directory zugewiesen
Sowohl auf relationaler, als auch auf multidimensionaler Ebene ist jede Rolle mit den
ihr zugedachten Rechten ausgestattet.
Im Sprachgebrauch von Microsoft wird die relationale Datenbank auch als
„Datenbankmodul“ und die multidimensionale Datenbank als „Analysis Service“
bezeichnet.
Die Software „Cubeware Teamserver“ regelt die Rechteverwaltung für die Frontend
Software „Cockpit“. Cockpit (siehe Kapitel 6.12) ist eine grafische Oberfläche, welche
es
anhand
von
definierten
Berichten
ermöglicht
Kennzahlen
anschaulich
darzustellen.
Wie beim SQL-Server benutzt die Verwaltung des Teamservers die im
„Active Directory“ angelegten lokalen Gruppen um diesen geeignete Rollen
zuzuweisen. Jede dieser Rollen ist auch hier mit bestimmten Rechten verbunden.
10.2 Ausprägung der Rechte
Auf jeder Stufe des Berechtigungssystems gibt es eine unterschiedliche Handhabung
der Benutzerrechte. Im Folgenden wird diese erläutert.
Business Intelligence
66
10.2.1 Active Directory
Das Active Directory ist für die Administration der Rechte von Netzwerkkomponenten
wie Verzeichnisfreigaben oder Drucker zuständig.
Innerhalb des BI-Systems wird es für die Verwaltung der Nutzer und Gruppen
gebraucht, damit eine Zuordnung der
Anwender auf die Rollen in den
nachgelagerten Komponenten des Berechtigungssystems möglich ist.
10.2.2 Importbereich
Für diesen Bereich werden die Rechte für die Rollen so gestaltet, dass nur das
Controlling und die IT-Abteilung Zugriff darauf haben
10.2.3 Relationale Datenbank
Dieser Teil des Data-Warehouse ist sehr stark eingeschränkt. Aufgrund des kleinen
Personenkreises finden die Beschränkungen nur auf Datenbankebene statt. Eine
Rechtevergabe auf einzelne Tabellen ist prinzipiell möglich, aber nicht vorgesehen.
Der SQL-Server bietet verschiedenste Möglichkeiten der Rechtevergabe. Bei
Brückner sind für eine angelegte Rolle allerdings nur Leserechte oder Lese- und
Schreibrechte vorgesehen.
10.2.4 Multidimensionale Datenbank
Die einfachste Zugriffseinschränkung ist das Ausblenden eines ganzen Würfels.
Damit hat ein Anwender keinerlei Zugriff auf die Daten.
Eine weitere Möglichkeit ist, dass bestimmte Dimensionen nicht angezeigt werden
können. Dies ist im Data-Warehouse von Brückner möglich, für die nahe Zukunft
aber nicht angedacht.
Am häufigsten wird die Einschränkung auf bestimmte Dimensionen des Würfels
verwendet. Beispielsweise soll ein Verkaufsleiter nur die Kennzahlen für seine Firma
auswerten können. Die Zahlen über Verkäufe anderer Tochterfirmen sollen für ihn
nicht einsehbar sein.
Auch Vertraulichkeit der Daten auf den verschiedenen Aggregationsstufen kann
unterschiedlich sein.
So ist es möglich, den Zugriff auf Daten unterhalb einer bestimmten Hierarchiestufe
zu verhindern. Man kann sich z.B. vorstellen, dass jemand nur auf Monats- nicht
aber auf Wochen und Tagesdaten Zugriff erhalten soll.
Business Intelligence
67
Der umgekehrte Weg, dass höher aggregierte Daten sensibler sind, als weniger
aggregierte Daten, ist ebenfalls vorstellbar. Auch diese Anforderung kann über die
Rechtevergabe abgedeckt werden.
10.2.5 Cubeware Teamserver
Der
Cubeware
Teamserver
bietet
eine
große
Auswahl
von
Rollen
mit
entsprechenden eingeschränkten Rechten.
Bei Brückner werden bisher aber nur vier verschiedene Rollentypen mit folgenden
Rechten verwendet:
Rollentyp
Rechte
Berichtsleser
Darf veröffentlichte Berichte lesen
Berichtskonsument
Wie Berichtsleser + Anpassung der Berichte nach
seinen Bedürfnissen möglich; lokale Speicherung des
angepassten Berichts erlaubt.
Berichtseigentümer
Wie Berichtskonsument + Möglichkeit eigene Berichte zu
erstellen und ändern
Administrator
Wie Berichtseigentümer + Veröffentlichung privater
Berichte
Tabelle 3: Rollentypen für den Cubeware Teamserver
Business Intelligence
68
11 Metadatenmanagement (MDM)
In diesem Kapitel wird beschrieben wie die im Zuge der Diplomarbeit entwickelte
Metadatenverwaltung zu bedienen ist.
In Kapitel 7 wurde aufgezeigt, dass es für die Verwaltung der Metadaten zwei Access
Datenbanken gibt. Zum Einen die Access Datenbank für das Testsystem und die
Access Datenbank für das Produktivsystem. Im Folgenden werden beide mit ADE
und ADP abgekürzt.
11.1 Access Datenbank für das Entwicklungssystem (ADE)
Nach dem Aufruf wird automatisch ein Startbildschirm geöffnet. Auf diesem sind vier
Buttons zu erkennen, welche Formulare für folgende Funktionen aufrufen.
1
: Einlesen der Daten von dem SQL-Servers in ADE
2
: Ein- und Ausgabe von Beschreibungen für Tabellen, Views, Stored Procedures
und Rollen
3
: Ein- und Ausgabe von Beschreibungen für Felder
4
: Ein- und Ausgabe von Beschreibungen für Meldungen
1
3
4
2
Abbildung 35: Startbildschirm der ADE
Business Intelligence
69
11.1.1 Formular: Einlesen von SQL-Server
Für die Synchronisation der Daten des SQL-Servers mit der ADE muss der Button
1
gedrückt werden.
Dies löst im Hintergrund eine VBA Prozedur aus, welche für einen inkrementellen
Abgleich der Daten sorgt. Inkrementell bedeutet, es werden nur solche Daten
eingelesen, welche im ADE noch nicht vorhanden sind.
Am Ende informiert die Meldung
über eine erfolgreiche Ausführung. Außerdem
2
bekommt der Anwender in einer Liste
3
angezeigt, welche Elemente der ADE
neu hinzugefügt wurden.
1
2
Abbildung 36: Daten von SQL-Server einlesen
11.1.2 Formular: Tabellen/ Views /Stored Procedures/ Rollen
Dieses Formular ist in Registerform aufgebaut. Für jeden Bereich ist ein Register für
die Eingabe (E) und die Ausgabe (A) der Beschreibungen vorgesehen. Eine
Ausnahme bildet das Register „Rolle“, da alle Angaben automatisch generiert
werden.
11.1.2.1
Reiter Tabelle–Eingabe
Für die Beschreibung einer Tabelle müssen zuerst ein Thema
1
und
eine
dazu passende Tabelle
2
ausgewählt werden. Daraufhin wird die Textbox
„Tabelle
3
freigegeben. Eine passende Beschreibung kann jetzt
Beschreibung“
eingegeben werden. Wurde für diese bereits eine Beschreibung hinterlegt, so wird
diese automatisch zur weiteren Bearbeitung in die Textbox geladen.
Business Intelligence
70
Mit einem Click auf dem Button
Meldung
5
4
werden die Eingaben gespeichert. Eine
informiert den Anwender abschließend über eine erfolgreiche
Ausführung.
1
2
3
4
5
Abbildung 37: Eingabe einer Beschreibung für eine Tabelle
11.1.2.2
Reiter Tabelle-Ausgabe
Das Register für die Ausgabe ist ähnlich dem der Eingabe. Nach Auswahl des
Themas und der Tabelle wird die Beschreibung in der Textbox
Das Feld
2
1
angezeigt.
zeigt an, ob die Tabelle noch Gültigkeit besitzt. Standardmäßig wird
dieses Feld beim Abgleich mit dem 31.12.9999 belegt. Wurde eine Tabelle aus dem
Data-Warehouse gelöscht, so wird beim Abgleich dieses Feld auf das gerade
aktuelle Datum gesetzt.
Dieses
Vorgehen
wurde
bewusst
gewählt,
damit
eine
durchgehende
Nachverfolgbarkeit der Änderungen im Data-Warehouse gewährleistet ist.
Business Intelligence
71
2
1
Abbildung 38: Ausgabe der Metadaten für eine Tabelle
11.1.2.3
Reiter View-Eingabe und View-Ausgabe
Hier kann dokumentiert werden welche Aufgaben die Views innerhalb des DataWarehouse erfüllen.
Der Aufbau der Register ist analog dem der Tabellen.
11.1.2.4
Reiter SP-Eingabe
Wie in Kapitel 6.3 beschrieben sind Stored Procedures auf dem SQL-Server
hinterlegte
Programme,
welche
zur
Durchführung
vielfältiger
(beispielsweise die Ausführung einer Transformation) gebraucht werden.
Die Eingabemaske sieht ähnlich aus wie die der Tabellen.
Aufgaben
Business Intelligence
72
Abbildung 39: Eingabe einer Beschreibung für eine Stored Procedure
11.1.2.5
Reiter SP-Ausgabe
Die Ausgabemaske für die Stored Procedures wurde im Vergleich zu den bisher
dargestellten Masken um ein Feld erweitert.
In
1
kann der Zeitpunkt abgelesen werden, wann eine Prozedur das letzte Mal
bearbeitet wurde.
Wie bei den Tabellen wird bei einem Datum, welches in der Vergangenheit liegt,
angezeigt wann eine Prozedur aus dem Datawarehouse gelöscht wurde.
2
Abbildung 40: Ausgabe der Metadaten für eine Stored Procedure
1
2
Business Intelligence
11.1.2.6
73
Reiter Rollen-Ausgabe
Um den Zugriff auf die Datenbasis im DHW einzuschränken, wurden im Zuge des
Berechtigungskonzepts (Kapitel 10) für jede Datenbank eigenen Rollen definiert. Der
Name der jeweiligen Rolle kann in an dieser Stelle nachgelesen werden.
Nach Auswahl eines Themas werden in einem Listenfeld die passenden Rollen
1
angezeigt.
1
Abbildung 41: Ausgabe von Rollen
11.1.3 Formular: Felder
Da für die Beschreibung von Feldern mehrere Attribute berücksichtigt werden
müssen, wurde aus Gründern der Übersichtlichkeit ein eigenes Formular entworfen.
11.1.3.1
Reiter: Eingabe
Nach Auswahl des Themas
beschreibende
Feld
3
1
und
der
Tabelle
2
muss
das
zu
selektiert werden.
Falls ein Feld bereits dokumentiert wurde, so werden alle hinterlegten Werte in den
entsprechenden Formularfeldern zur weiteren Verarbeitung vorbelegt.
Da die Feldbezeichnung laut Namenskonvention oft recht kryptisch anmutet, kann
über das Feld „Kurzbezeichnung“ ein aussagekräftiger Name vergeben werden.
Im Feld „Feldbeschreibung“ kann dokumentiert werden, welche Inhalte in diesem
Feld im Data Warehouse abgespeichert werden.
Business Intelligence
74
Direkt zugeordnetes Feld
Grundsätzlich wird bei der Datenübernahme davon ausgegangen, dass es sich um
ein direkt zugeordnetes Feld handelt. Ein Feld wird als direkt zugeordnet bezeichnet,
wenn die Daten eins zu eins aus dem Quellsystem übernommen worden sind. Die
einzige zugelassene Einschränkung ist das Setzen eines Filters. Wurde ein Filter
verwendet, so kann dieser nach einem Click auf die Checkbox „Filter“
einem darauf erscheinenden Textfeld
4
in
beschrieben werden.
5
1
2
3
4
5
Abbildung 42: Eingabe von Beschreibungen für ein direkt zugeordnetes Feld
BI-Feld
Ein BI-Feld ist ein Feld, das durch eine Transformation (meist aus mehreren Feldern
des Quellsystems) entstanden ist.
Business Intelligence
75
Handelt es sich bei dem zu beschreibenden Feld um ein BI-Feld, so muss die
Checkbox „BI-Feld“ angeclickt werden. Daraufhin verschwindet die Checkbox „Filter“
und die Textboxen „Beschreibung Transformation“
7
6
und „Link zu Grafik“
erscheinen.
Unter „Beschreibung Transformation“ ist, wie der Name schon aussagt, die für das
Feld zu Grunde liegende Transformation darzustellen. Es handelt sich dabei um ein
„Muss-Feld“, d.h. ein Ausfüllen dieses Feldes ist zwingend erforderlich.
Transformationen unterliegen oft eine sehr komplexen Zusammenhängen, die über
eine reine Textbeschreibung schwer verständlich gemacht werden kann. In vielen
Fällen wird daher der Sachverhalt grafisch in Visio modelliert. Sind solche Modelle
vorhanden, so kann über „Link zu Grafik“ auf diese Dokumente verwiesen werden.
Mit Click auf den Button
8
werden die eingegeben Daten in der Datenbank
abgelegt. Der Anwender wird abschließend über die erfolgreiche Transaktion
informiert.
6
7
Abbildung 43: Eingabe von Beschreibungen für ein BI-Feld
8
Business Intelligence
11.1.3.2
76
Reiter: Ausgabe
Nach Auswahl von Thema, Tabelle und Feld werden neben den manuell
eingegebenen Daten noch zusätzliche Felder angezeigt.
1
informiert darüber, ob das ausgewählte Feld innerhalb seiner Tabelle ein
Primärschlüsselfeld ist. Der Datentyp des Feldes kann in
2
eingesehen werden.
Die Informationen über Primärschlüsselfeld und Datentyp werden automatisch beim
Abgleich in die Access Datenbank übernommen.
3
gibt
Aufschluss
darüber,
ob
das
Feld
noch
eine
Gültigkeit
besitzt.
Standardmäßig wird hier beim Abgleich der Access Datenbank mit dem SQL-Server
das Datum auf den 31.12.9999 gesetzt. Ein Löschen des Zielfeldes im Data
Warehouse hat zur Folge, dass das Datum 31.12.9999 mit dem aktuellen Datum am
Tag des Abgleichs ersetzt wird.
1
2
Abbildung 44: Ausgabe der Metadaten für ein Feld
3
Business Intelligence
77
11.1.4 Formular: Meldungen
Bei Brückner wird für jedes neue Projekt eine sogenannte Meldung im SAP System
angelegt. An eine Meldung können beliebig viele sogenannte Maßnahmen
angehängt werden. In den Maßnahmen wird beschrieben, welche Aufgaben, wann,
von wenn und bis wann erledigt wurden. Eine durchgehende Dokumentation des
gesamten Projektverlaufs ist dadurch gegeben.
Um schnell zu wissen, welche Meldungen BI-Projekte betreffen, wurden die
Meldungen ebenfalls Bestandteil im Metadaten Management.
Inhalte von Meldungen und Maßnahmen sind nicht erfasst. Diese können aber recht
einfach über die angezeigte Meldungsnummer im SAP System abgefragt werden.
11.1.4.1
Reiter Meldung anlegen
Im Feld Meldungsnummer
1
muss die eindeutige Meldungsnummer, welche
vom SAP System vergeben wird, eingetragen werden.
Unter
2
soll der Name des Entwicklers eingetragen werden, welcher die Meldung
initialisiert hat.
Die Bezeichnung der Meldung wird in
In der Combobox
geführt.
3
muss der Status („offen“, „in Arbeit“ oder „geschlossen“)
4
ausgewählt werden.
1
2
3
4
Abbildung 45: Eingabe der Meldungsinformationen
Business Intelligence
11.1.4.2
78
Register Meldung ändern
Hier kann nur der Status der Meldung geändert werden.
11.1.4.3
Register Meldung anzeigen
Nach Auswahl des Themas können hier die zugehörigen Meldungen angezeigt
werden.
Abbildung 46: Meldungen anzeigen
Business Intelligence
79
11.2 Access Datenbank für das Produktivsystem (ADP)
Nach dem Aufruf wird automatisch ein Startbildschirm geöffnet. Auf diesem sind vier
Buttons zu erkennen, welche Formulare für folgende Funktionen aufrufen.
Buttons zu erkennen, welche Formulare für folgende Funktionen aufrufen.
1
: Einlesen der Daten von dem SQL-Servers in ADP
2
: Abgleich ADP mit ADE
3
: Ausgabe von Beschreibungen für Tabellen, Views, Stored Procedures und
Rollen
4
: Ausgabe von Beschreibungen für Felder
1
3
4
Abbildung 47: Startbildschirm für die ADP
2
Business Intelligence
80
11.2.1 Formular: Einlesen von SQL-Server
Das Einlesen der Daten in ADP funktioniert analog zum Testsystem. Der Anwender
muss den Prozess einfach nur über einen Button anstoßen. Abschließend wird er
darüber informiert, welche Objekte neu in die Access Datenbank transferiert wurden.
Abbildung 48: Einlesen der Daten von SQL-Server
11.2.2 Formular: Abgleich MDM
Der Entwickler muss die Beschreibung der Metadaten nur einmal für das Testsystem
vornehmen. Alle Beschreibungen, die er erstellt hat, kann er per Mausclick in die
Access Datenbank für das Produktivsystem übernehmen.
11.2.2.1
Reiter: Nicht vorhanden
Die Übernahme funktioniert natürlich nur für Objekte (Tabellen, Felder…), die sowohl
im Testsystem, als auch im Produktivsystem, vorhanden sind. Objekte, die es nur im
Testsystem gibt, kann man sich durch Click auf den entsprechenden Button
1
im Register anzeigen lassen.
Durch Click auf eine der betreffenden Schaltflächen
2
öffnet sich eine Abfrage.
Hier sieht der Entwickler auf einen Blick, welche Objekte noch nicht auf dem
Produktivsystem vorhanden sind. Abfrage zeigt im Beispiel Tabellen, die noch nicht
auf dem Produktivsystem zu finden sind.
Business Intelligence
81
1
2
Abbildung 49: Formular zur Ausgabe von Objekten die in ADP nicht vorhanden sind
11.2.2.2
Reiter Abgleich MDM
Der Abgleich aller Beschreibungen für Objekte, die bereits auf beiden Systemen zu
finden sind, erfolgt im Reiter „Abgleich MDM“ durch Click auf den Button
1
.
In diesem Schritt werden alle manuell erstellten Beschreibungen aus der ADE in die
Datenbank für das Produktivsystem (ADP) kopiert. Dies trifft aber nur zu, wenn keine
Konflikte aufgetreten sind.
Beispiele für Konflikte:
‐
Es ist bereits eine Metadatenbeschreibung für das Produktivsystem hinterlegt.
‐
Der Datentyp ist unterschiedlich.
‐
Die Länge des Datentyps ist unterschiedlich.
‐
Unterschiedliche Primärschlüssel sind gesetzt.
Business Intelligence
82
1
2
Abbildung 50: Abgleich der Access Datenbanken untereinander
Sind Konflikte aufgetreten, erscheint ein Hinweis auf aufgetretene Probleme. Diese
könne mit einem Click auf den Button
11.2.2.3
2
angezeigt werden.
Reiter: Konflikte beim Abgleich
Nachdem auf „Konflikte anzeigen“ geclickt wurde, werden weitere Reiter
1
im
Formular sichtbar. Je nachdem wo die Konflikte auftraten, stehen Reiter für Tabellen,
Felder, usw. zur Verfügung.
Business Intelligence
83
1
2
Abbildung 51: Konflikte beim Abgleich
Die Abbildung zeigt ein Beispiel für ein Feld, dessen Beschreibung einer
Transformation in den beiden Systemen unterschiedlich ist. Zur besseren Darstellung
wird der Konflikt in roter Farbe gezeigt. Falls noch weitere Konflikte auftreten würden,
würden diese ebenfalls in roter Farbe hervorgehoben.
Rechts daneben ist eine Checkbox eingeblendet. Diese dient als Kennzeichen für die
Übernahme. Falls dort Anwender dort einen Haken setzt, wird die alte Beschreibung
durch die neuen Beschreibung ersetzt. Ein Click auf den Button
2
wertet die
Checkboxen aus und aktualisiert dementsprechend die Beschreibungen in der ADP.
Anschließend wird das nächste Feld mit einem Konflikt angezeigt.
Business Intelligence
84
Konflikte können auf diese Weise aber nur gelöst werden, wenn sie bei Attributen
auftreten, die manuell eingegeben wurden. Datentyp oder Primärschlüssel sind
beispielsweise Informationen, welche automatisch aus dem Data Warehouse
importiert wurden. Eine Checkbox für die Übernahme gibt es dann natürlich nicht.
Falls sich hier Unterschiede zwischen Test- und Produktivsystem ergeben, dann
muss diese der Entwickler im Data Warehouse beseitigen. In solchen Fällen gibt die
Metadatenverwaltung aber zumindest eine wertvolle Hilfestellung für den Entwickler,
indem sie aufzeigt, wo noch Handlungsbedarf ist.
Wenn alle Datensätze in einem Reiter besichtigt wurden, wird der entsprechende
Reiter im Formular wieder ausgeblendet und auf den nächsten gesprungen.
11.2.3 Formular: Tabellen/Views/SPs/Rollen
Da wie erläutert Beschreibungen in die ADP nur über eine Synchronisation mit der
ADS gelangen, wird auf Eingabemasken verzichtet. Angaben zu Tabellen, Views,
Stored Procedures und Rollen können nur eingesehen, aber nicht verändert werden.
Wie bei der ADS wurde für eine übersichtliche Darstellung ein Formular mit
1
Reitern für alle Objekte im Data-Warehouse erstellt.
1
Abbildung 52: Ausgabe der Metadaten für Tabellen, Views, Stored Procedures und Rollen
11.2.4 Formular: Felder
Die Beschreibungen für Felder lassen sich auch hier nur ausgeben. Eine Änderung
ist nicht möglich.
Business Intelligence
Abbildung 53: Ausgabe der Metadaten für ein Feld
85
Business Intelligence
86
12 Konventionen für Cubeware Cockpit
Um eine einheitliche Form und Gestaltung der Cockpit Berichte zu gewährleisten
wurden im Rahmen der Diplomarbeit einige Konventionen aufgestellt.
12.1 Berichtskopf
Schriftart:
Arial
Schriftgröße:
14pt
Schriftformatierung:
fett
Elemente links oben:
Element rechts oben:
 Firma
 Standort
 Titel
 Stand
Logo der Brückner Group
Hintergrund:
Farbverlauf Lavendel
12.2 Berichtskörper
Hintergrundfarbe für ganzen Berichtskörper: weiß
Erstes Objekt (optional)
Filter- oder Auswahlleiste
Zweites Objekt
Tabelle
Schriftart:
Arial
Schriftgröße:
10pt
Schriftformatierung Vorspalte und Kopfzeile:
Normal
Schriftformatierung Tabellenfelder:
Normal
Schriftformatierung Summen:
Fett
Hintergrundfarbe Vorspalte und Kopfzeile:
lichtgrau (Standard)
Hintergrundfarbe Tabellenfelder:
weiß
Business Intelligence
87
Drittes Objekt
Grafik
Schriftart:
Arial
Schriftgröße:
10pt
Farben:
Standard-Farbpalette
Abbildung 54: Layout eines Berichts in Cockpit
Business Intelligence
88
13 Resümee
Rückblickend auf die Erstellung der Diplomarbeit kann ich sagen, dass es sich bei
Business Intelligence um ein sehr umfangreiches Thema handelt. Es brauchte sehr
zeitintensive Nachforschungen in der Literatur, um sich einen grundlegenden
Überblick über das Thema zu verschaffen. Das Einlesen in die Literatur ist zwingend
notwendig, bereitet aber nicht auf alle Schwierigkeiten vor, welche die Einführung
eines Business Intelligence Systems mit sich bringt. Auf viele Herausforderungen
stößt man erst während der täglichen Arbeit mit dem System. Ein Konzept, wie man
den Informationsbedarf der Entscheider am Besten ermittelt und dokumentiert, findet
man beispielsweise so gut wir gar nicht in der einschlägigen Literatur. Auch bei
Fragestellungen wie dem gesicherten und autorisierten Zugriff auf Daten oder dem
Prozess bei der Freigabe von multidimensionalen Würfeln ist es sehr schwierig,
Antworten in der Literatur oder von Fachberatern zu erhalten. Dies sind aber nur
Beispiele für die Herausforderungen, auf die man fast tagtäglich bei der Arbeit mit
einem Business Intelligence System trifft. Gerade aber das oftmalige „Betreten von
Neuland“ macht den großen Reiz dieses Themas aus.
Besonders viel Spaß gemacht hat mir die Entwicklung der Metadatenverwaltung.
Ursprünglich war nicht geplant, dass ich diese programmiere, da zu Beginn der
Diplomarbeit gar nicht bekannt war, dass diese im System von Cubeware fehlt. Auch
fehlte
am
Anfang
das
Bewusstsein
in
der
Firma,
wie
wichtig
eine
Metadatenverwaltung für die tägliche Arbeit der Entwickler ist.
Durch die Einarbeitung in das Thema, aber vor allem durch die hilfsbereite und
tatkräftige Unterstützung durch die Kollegen bei Brückner konnte ich mir ein großes
Wissen im Bereich Business Intelligence aneignen, was mich sicherlich auch in
beruflicher Hinsicht weiterbringen wird. Aber auch der Firma Brückner steht durch
diese Diplomarbeit ein Nachschlagwerk zur Verfügung, das sich bei der Einführung
des BI-Systems in weiteren Tochterfirmen als sehr hilfreich erweisen wird.
Business Intelligence
14 Anhang
14.1 Visio Modell: Berichtsdatum
89
Business Intelligence
14.2 Visio Modell: Auftragseingang
90
Business Intelligence
14.3 Literaturverzeichnis
BAUER, GÜNZEL 2004
Bauer, A., Günzel H. (Hrsg.): Data Warehouse Systeme;
Heidelberg: dpunkt.verlag
BÖHLEIN, ULBRICH VOM ENDE (Jahr unbekannt)
M. Böhnlein, A. Ulbrich-vom Ende: Grundlagen des Data WarehousingModellierung und Architektur (Whitepaper)
Bamberg: Universität Bamberg- Lehrstuhl für Wirtschaftsinformatik
CHRISTMANN 1996
Christmann, A: Data-Warehouse-Lösung der Stadt Köln in: KEMPER,
MEHANNA, UNGER 2006: Business Intelligence- Grundlagen und
praktische Anwendungen
Wiesbaden: Friedr. Vieweg & Sohn Verlag
CUBEWARE 2008
Cubeware GmbH: Schulungsunterlagen Cockpit V6pro
Rosenheim: Cubeware GmbH
EGGER 2004
Egger, N: Praxishandbuch SAP BW 3.1
Bonn: Galileo Press
HAHNE 2004
Hahne; M: Grafische Repräsentation mehrdimensionaler
Datenmodelle des SAP Business Information Warehouse (Whitepaper)
Bretzenheim: cundus AG
HEINRICH 1996
Heinrich, L.J.: Informationsmanagement
München, Wien: Oldenburg Verlag
91
Business Intelligence
92
Horváth 2006
Horváth, P: Controlling
München: Vahlen Verlag
INMON 1996
Inmon, W.H.: Building the Data Warehouse
New York: John Wily & Sons
KEMPER, MEHANNA, UNGER 2006
Kemper, H-G, Mehanna, W, Unger, C.: Business Intelligence- Grundlagen und
praktische Anwendungen
Wiesbaden: Friedr. Vieweg & Sohn Verlag
KOREIMANN 2000
Koreimann, D.S.: Grundlagen der Software-Entwicklung
München, Wien: Oldenburg Verlag
KURZ 1999
Kurz, A: Data Warehousing- Enabling Technology
Bonn: MITP-Verlag
LEHMANN 2001
Lehmann, P: Meta-Datenmanagement in Data-Warehouse-Systemen
(Dissertation)
Magdeburg: Otto-von-Guericke-Universität Magedburg
MUCKSCH, BEHNE 1997
Mucksch, H, Behne, W: Das Data Warehouse-Konzept als Basis einer
unternehmensweiten Informationslogistik
Wiesbaden: Gabler Verlag in: Strauch, B: Entwicklung einer Methode für die
Informationsbedarfsanalyse im Data Warehousing
RAUTENSTRAUCH 1997
Rautenstrauch, C: Effiziente Gestaltung von Arbeitsplatzsystemen; Bonn In:
Strauch,
Business Intelligence
93
B: Entwicklung einer Methode für die Informationsbedarfsanalyse im
Data Warehousing (Dissertation)
SCHICKER 2000
Schicker, E: Datenbanken und SQL
Stuttgart / Leipzip / Wiesbaden: B. G. Teubner GmbH
STRAUCH 2002
Strauch, B: Entwicklung einer Methode für die Informationsbedarfsanalyse im
Data Warehousing (Dissertation)
Bamberg: Difo-Druck GmbH
STRUCKMEIER 1997
Struckmeier, H: Gestaltung von Führungsinformationssystemen
Wiesbaden: Deutscher Universitätsverlag
WIKIPEDIA1
Wikipedia- die freie Enzyklopädie: ETL-Prozess;
http://de.wikipedia.org/wiki/ETL-Prozess am 15.9.2008
WIKIPEDIA2
Wikipedia- die freie Enzyklopädie: Active Directory
http://de.wikipedia.org/wiki/Active_Directory am 15.9.2008
Business Intelligence
94
14.4 Abbildungsverzeichnis
Abbildung 1: Auftragswerte mit Sicht auf Aufträge ...................................................... 8 Abbildung 2: Auftragswerte mit Sicht auf Länder......................................................... 8 Abbildung 3: schematische Darstellung deines multidimensionalen Würfels ............ 10 Abbildung 4: Darstellung eines Würfels mit mehr als drei Dimensionen ................... 11 Abbildung 5: Drill Down ............................................................................................. 13 Abbildung 6: Roll Up .................................................................................................. 14 Abbildung 7: Slice...................................................................................................... 14 Abbildung 8: Dice ...................................................................................................... 15 Abbildung 9: Rotate ................................................................................................... 15 Abbildung 10: OLAP-Join .......................................................................................... 16 Abbildung 11: Formular zur Berichtsanforderung ...................................................... 21 Abbildung 12: Formular zur Anforderung eines Themas ........................................... 23 Abbildung 13: Aufbau Dimension mit Merkmal .......................................................... 26 Abbildung 14: Hierarchie innerhalb einer Dimension................................................. 27 Abbildung 15: Beschreibendes Attribut ..................................................................... 27 Abbildung 16: Ausprägungen eines Merkmals .......................................................... 28 Abbildung 17: Darstellung eines Basiscube .............................................................. 28 Abbildung 18: Multi-Cube mit Basis-Cubes ............................................................... 29 Abbildung 19: Ausschnitt einer Modellierung zum Auftragseingang .......................... 30 Abbildung 20: Komponenten der Business Intelligence Lösung von Brückner .......... 32 Abbildung 21: Mapping für eine Extraktion ................................................................ 34 Abbildung 22: TCL Script .......................................................................................... 37 Abbildung 23: Extraktion mit Hilfe einer Aktualisierungstabelle ................................. 37 Abbildung 24: View zum Aufbau der Dimension Geschäftsbereiche ......................... 39 Abbildung 25: Prozedur zur Generierung eins Views in der Scriptsprache T-SQL .... 41 Abbildung 26: Überführung des View Geschäftsbereiche in die entsprechende
Dimension ................................................................................................................. 41 Abbildung 27: Star Schema am Beispiel Auftragseingang ........................................ 42 Abbildung 28: zeitlicher Ablauf der Metadatenverwaltung ......................................... 47 Abbildung 29: ERM-Modell: Metadaten auf SQL-Server ........................................... 48 Abbildung 30: ERM-Modell: Metadatenverwaltung in Access ................................... 50 Abbildung 31: Übersicht zur Metadatenverwaltung ................................................... 53 Abbildung 32: Freigabeprozess bei Neuerstellung eines Würfels ............................. 60 Business Intelligence
95
Abbildung 33: Freigabeprozess bei Aktualisierung eines Würfels ............................. 62 Abbildung 34: Berechtigungssystem ......................................................................... 64 Abbildung 35: Startbildschirm der ADE ..................................................................... 68 Abbildung 36: Daten von SQL-Server einlesen ......................................................... 69 Abbildung 37: Eingabe einer Beschreibung für eine Tabelle ..................................... 70 Abbildung 38: Ausgabe der Metadaten für eine Tabelle ............................................ 71 Abbildung 39: Eingabe einer Beschreibung für eine Stored Procedure..................... 72 Abbildung 40: Ausgabe der Metadaten für eine Stored Procedure ........................... 72 Abbildung 41: Ausgabe von Rollen ........................................................................... 73 Abbildung 42: Eingabe von Beschreibungen für ein direkt zugeordnetes Feld ......... 74 Abbildung 43: Eingabe von Beschreibungen für ein BI-Feld ..................................... 75 Abbildung 44: Ausgabe der Metadaten für ein Feld .................................................. 76 Abbildung 45: Eingabe der Meldungsinformationen .................................................. 77 Abbildung 46: Meldungen anzeigen .......................................................................... 78 Abbildung 47: Startbildschirm für die ADP ................................................................ 79 Abbildung 48: Einlesen der Daten von SQL-Server .................................................. 80 Abbildung 49: Formular zur Ausgabe von Objekten die in ADP nicht vorhanden sind
.................................................................................................................................. 81 Abbildung 50: Abgleich der Access Datenbanken untereinander .............................. 82 Abbildung 51: Konflikte beim Abgleich ...................................................................... 83 Abbildung 52: Ausgabe der Metadaten für Tabellen, Views, Stored Procedures und
Rollen ........................................................................................................................ 84 Abbildung 53: Ausgabe der Metadaten für ein Feld .................................................. 85 Abbildung 54: Layout eines Berichts in Cockpit......................................................... 87 Business Intelligence
14.5 Abkürzungsverzeichnis
ADE
Access Datenbank für das Entwicklungssystem
ADP
Access Datenbank für das Produktivsystem
BI
Business Intelligence
BBI
Brückner Business Intelligence
CSV
Character Separated Values oder Comma Separated Values
ERM
Entity-Relationship-Modell
ERP
Enterprise Resource Planning
MDM
Metadaten Management
OLAP Online Analytical Processing
OLTP Online Transaction Processing
PDF
Portable Document Format
SQL
Structured Query Language
T-SQL Transact-SQL
TCL
Tool Command Language
96
Business Intelligence
97
ERKLÄRUNG
1. Mir ist bekannt, dass dieses Exemplar der Diplomarbeit als Prüfungsleistung in
das Eigentum des Freistaates Bayern übergeht.
2. Ich erkläre hiermit, dass ich diese Diplomarbeit selbständig verfasst, noch nicht
anderweitig für andere Prüfungszwecke vorgelegt, keine anderen als die
ange-gebenen Quellen und Hilfsmittel benutzt sowie wörtlich und sinngemäße
Zitate als solche gekennzeichnet habe.
Bernau am Chiemsee, den 20. Dezember 2008
……………………………………………………………..
Unterschrift