Erfolg in Data-Warehouse-Projekten: Eine praxisnahe Analyse von Erfolgsfaktoren und -kriterien

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einleitung

2 Theoretische Definitionen und grundlegende Konzepte
2.1 Definition von Data-Warehouse und Data-Warehousing
2.2 Operationelle Systeme vs. Data-Warehouse-Umgebung
2.3 Nutzen des Data-Warehouse
2.4 Data-Warehouse-Architektur

3 Grundlagen zum Konzept der kritischen Erfolgsfaktoren
3.1 Definition von kritischen Erfolgsfaktoren und -kriterien
3.2 Erfolgsmessung eines Informationssystems
3.3 Erfolg in Data-Warehouse-Projekten

4 Systematische Literaturanalyse
4.1 Vorgehensweise der Literaturrecherche
4.2 Übersicht über die in der Arbeit ausgewerteten Studien

5 Wissenschaftliche Ergebnisse zu Data-Warehouse-Erfolgskriterien und kritischen Erfolgsfaktoren in Data-Warehouse-Projekten
5.1 Data-Warehouse-Erfolgsdimensionen und -kriterien
5.2 Kritische Erfolgsfaktoren zur Entscheidungsfindung von Data-Warehouse- Implementierungen
5.3 Kritische Erfolgsfaktoren für Data-Warehouse-Projekte
5.3.1 Organisatorische Faktoren
5.3.2 Projektbezogene Faktoren
5.3.3 Technische Faktoren

6 Diskussion

7 Zusammenfassung und Ausblick

Literaturverzeichnis

Abbildungsverzeichnis

Abb. 2.1: Potenzielle betriebswirtschaftliche Nutzen von Data-Warehouse
Abb. 2.2: Umfassende Data-Warehouse-Architektur
Abb. 2.3: Data-Mart-Bus-Architektur
Abb. 2.4: Arten von Data-Warehouse-Architekturen

Abb. 3.1: Modell der Technologieakzeptanz
Abb. 3.2: IS-Erfolgsmodell von DeLone und McLean
Abb. 3.3: Modifiziertes IS-Erfolgsmodell von DeLone und McLean

Abb. 4.1: Forschungsmodell von Wixom, Watson (2001)
Abb. 4.2: Forschungsmodell von Hong et al. (2006)
Abb. 4.3: Forschungsmodell von Hwang, Xu (2008)
Abb. 4.4: Forschungsmodell von Kefi, Koppel (2011)

Abb. 5.1: Durchschnittliche Entwicklungszeit in Monaten bis zur Einführung des ersten Geschäftsprozesses oder Subjektbereichs
Abb. 5.2: Durchschnittliche Entwicklungskosten in Mio. Dollar bis zur Einführung des ersten Geschäftsprozesses oder Subjektbereichs
Abb. 5.3: Durchschnittliche Wartungskosten in Mio. Dollar pro Jahr

Tabellenverzeichnis

Tab. 2.1: Unterschiede zwischen operationellen Systemen und Data-Warehouse

Tab. 3.1: Häufige Vorteile und Probleme mit IT-Balanced Scorecard
Tab. 3.2: Häufige Vorteile und Probleme mit Benchmarking

Tab. 4.1: Empirische Studien zu Data-Warehouse-Erfolgskriterien und kritischen
Erfolgsfaktoren aus Business-Source-Premier
Tab. 4.2: Empirische Studien zu Data-Warehouse-Erfolgskriterien und kritischen Erfolgsfaktoren aus der ACM-Digital-Library
Tab. 4.3: MIS-Zeitschriftenranking
Tab. 4.4: Empirische Studien zu Data-Warehouse-Erfolgskriterien und kritischen Erfolgsfaktoren in Data-Warehouse-Projekten. Teil 1
Tab. 4.5: Empirische Studien zu Data-Warehouse-Erfolgskriterien und kritischen Erfolgsfaktoren in Data-Warehouse-Projekten. Teil 2

Tab. 5.1: Systemqualität. Signifikanz der Erfolgskriterien, die sich direkt auf die Nutzerzufriedenheit auswirken
Tab. 5.2: Informationsqualität. Signifikanz der Erfolgskriterien, die sich direkt auf die Nutzerzufriedenheit auswirken
Tab. 5.3: Servicequalität. Signifikanz der Erfolgskriterien, die sich direkt auf die Nutzerzufriedenheit auswirken
Tab. 5.4: Signifikanz der Erfolgskriterien, die sich auf die Systemnutzung direkt und indirekt auswirken
Tab. 5.5: Signifikanz der Erfolgsfaktoren, die für die Implementierung eines Data- Warehouse kritisch sind
Tab. 5.6: Signifikanz der organisatorischen Faktoren, die für Erfolge von Data- Warehouse-Projekte kritisch sind
Tab. 5.7: Signifikanz der projektbezogenen Faktoren, die für Erfolge von Data- Warehouse-Projekte kritisch sind
Tab. 5.8: Signifikanz der technischen Faktoren, die für Erfolge von Data-Warehouse- Projekte kritisch sind
Tab. 5.9: Erfolgsranking der fünf Data-Warehouse-Architekturen

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

Die Idee eines Data-Warehouse ist konzeptionell sehr einfach.¹ Ein Data-Warehouse ist grundsätzlich eine Datensammlung, die für die Unterstützung der Entscheidungsfindung geschaffen wird. Es löst ein langjähriges Problem der Entscheidungsunterstützung: der Bedarf an genauen, bereinigten, gut organisierten und zugänglichen Daten.² Das DataWarehouse-Konzept beruht auf zwei grundlegenden Bedürfnissen: die unternehmensübergreifende Sichtweise auf Information und die effektive Verwaltung von Unternehmensdaten.³ Daher wurden Data-Warehouse-Technologien immer wieder eingesetzt, um Infrastrukturen für Datenverwaltung aufzubauen.

Seit den 90er Jahren ist Data-Warehouse eines der bedeutendsten Entscheidungsunterstüt- zungswerkzeuge.⁴ Laut dem Bericht von HALL aus dem Jahr 2002 entwickelten nahezu 70 Prozent der großen Unternehmen auf der ganzen Welt ein Data-Warehouse oder ein ähnliches System für das Datenmanagement. Allerdings berichteten 41 Prozent der Befrag- ten, dass ihre Unternehmen mindestens einen Projektmisserfolg hatten, und nur 15 Prozent der Befragten gaben an, dass ihre Data-Warehouse-Implementierungen große Erfolge wa- ren.⁵

Ein Data-Warehouse-Projekt ist nicht nur eine hoch riskante Unternehmung, sondern auch eine teure Unternehmung. Die Kosten einer Data-Warehouse-Implementierung können bei einer bis mehreren Millionen Dollar liegen.⁶ Da ein Data-Warehouse keine spezifische Applikation sondern eine IT-Infrastruktur ist, die als Grundlage für die Entwicklung weite- rer Datenanalysewerkzeuge und -applikationen dient, erfordert es entsprechende Investiti- onen, dennoch realisiert es für Unternehmen dauerhafte Nutzen und generiert Mehrwerte.⁷ Aufgrund der hohen Investitionen und einer niedrigen Erfolgsquote sind die Verantwortli- chen gezwungen, eine sorgfältige Bewertung ihres Programms durchzuführen, und Fakto- ren, die für das Data-Warehouse-Projekt kritisch sein könnten, festzustellen und zu beach- ten.⁸

Das Ziel dieser Arbeit ist eine Ermittlung der Erfolgsfaktoren, die für Data-Warehouse- Implementierungen respektive Data-Warehouse-Projekte kritisch sind. Daher wird der wis- senschaftliche Stand der Forschung in Bezug auf kritische Erfolgsfaktoren untersucht und ausgewertet. Darüber hinaus wird eine Analyse von relevanten Data-Warehouse- Erfolgsmessgrößen durchgeführt, um die Auswirkungen bestimmter Erfolgsfaktoren auf Erfolge in Data-Warehouse-Projekten vergleichen zu können.

Die vorliegende Arbeit beginnt mit dieser Einleitung. In Teil 2 werden Grundlagen des Data-Warehouse-Konzepts behandelt. In Kapitel 2.1 wird zunächst Data-Warehouse definiert und seine Eigenschaften erläutert. Kapitel 2.2 zeigt auf, wie sich ein DataWarehouse-System von operationellen Systemen unterscheidet. Die Nutzen, die durch Data-Warehouse gewährleisten werden können, werden in Kapitel 2.3 näher behandelt. Teil 2 schließt in Kapitel 2.4 mit der Erläuterung der Data-Warehouse-Komponenten und Arten von Data-Warehouse-Architekturen.

Die Grundlagen zum Konzept der kritischen Erfolgsfaktoren werden in Teil 3 vorgestellt. Zuerst befasst sich Kapitel 3.1 mit Definitionen der kritischen Erfolgsfaktoren und -kriterien. In Kapitel 3.2 wird erklärt, weshalb die Feststellung von Erfolgskriterien für Informationssysteme wichtig ist und wie der Erfolg gemessen werden kann. Kapitel 3.3 endet schließlich mit der Fragestellung, weshalb die Feststellung von kritischen Erfolgs- faktoren in Data-Warehouse-Projekten entscheidend ist und in welcher Weise diese Fakto- ren klassifiziert werden können.

Teil 4 beschäftigt sich mit der systematischen Literaturanalyse, die dieser Arbeit zugrunde liegt. Während in Kapitel 4.1 die Vorgehensweise der Literaturrecherche beschrieben wird, gibt Kapitel 4.2 eine Übersicht über die in der Arbeit ausgewerteten Studien.

Teil 5 erläutert und vergleicht die wissenschaftlichen Ergebnisse zu den Data-Warehouse- Erfolgskriterien und den kritischen Erfolgsfaktoren in Data-Warehouse-Projekten. Zuerst stellt Kapitel 5.1 Ergebnisse zu Data-Warehouse-Erfolgsdimensionen und -kriterien vor. Danach zeigt Kapitel 5.2 die Erfolgsfaktoren auf, die für die Entscheidung ein Data- Warehouse zu implementieren kritisch sind. Schließlich erläutert Kapitel 5.3 die organisa- torischen, projektbezogenen und technischen kritischen Erfolgsfaktoren in Data- Warehouse-Projekten.

In Teil 6 werden die Ergebnisse der Untersuchungen diskutiert, und in Teil 7 schließt die Arbeit mit einer kurzen Zusammenfassung der zentralen Ergebnisse sowie einer Beleuchtung von Lücken, die in zukünftigen Forschungen berücksichtigt werden könnten.

2 Theoretische Definitionen und grundlegende Konzepte

2.1 Definition von Data-Warehouse und Data-Warehousing

Unter dem Begriff Data-Warehouse wird ein computergestütztes System verstanden, das wie ein speziell aufbereiteter Datenbehälter zur Unterstützung von Entscheidungsprozessen funktioniert.⁹ Die Daten werden aus Datenquellen extrahiert, bereinigt, transformiert und in Datenspeicher geladen. Die benötigten Daten werden von Anwendern und Applikationen aus dem Speicher, der die Dateninfrastruktur bereitstellt, aufgerufen.¹⁰

Während ein Data-Warehouse als ein Datenbehälter betrachtet wird, wird unter dem Begriff Data-Warehousing der ganze Prozess verstanden.¹¹ GARDNER definiert das DataWarehousing wie ein Prozess, kein Produkt, für die Ansammlung und Verwaltung von Daten aus verschiedenen Quellen zum Zwecke der Schaffung einer einheitlichen Detailansicht auf einzelne Geschäftsbereiche oder das ganze Geschäft.¹²

Ursprünglich haben DEVLIN UND MURPHY das Konzept der Data-Warehouse-Technologie eingeführt.¹³ Ein Nur-Lese-Datenbankaufbau wurde von ihnen vorgestellt, in dem historische Daten für Betrieb abgelegt werden und Anwender mit Integrationstools Abfragen und Recherchen für die Entscheidungsprozesse und Analysen durchführen können.

Von INMON wurden vier wichtigen Eigenschaften eines Data-Warehouse erläutert¹⁴:

Daten werden in einem Data-Warehouse themenorientiert organisiert, indem sie sich auf spezifische Datenobjekte beziehen. Zum Beispiel könnten die Datenobjekte für ein Einzelhandelsgeschäft „Produkt“, „Vertrieb“ und „Kunden“ heißen. Dies unterscheidet sich von Transaktionssystemen, in denen Daten nach Geschäftsprozessen wie Auf- tragserfassung, Bestandskontrolle oder Forderungen aus Lieferungen und Leistungen organisiert werden. Jedes Unternehmen hat die Möglichkeit eigene Themenbereiche festzulegen.

Die zweite wichtige Eigenschaft eines Data-Warehouse besteht darin, dass es integriert ist. Im Data-Warehouse werden Daten aus mehreren verschiedenen Quellen extrahiert und in einem konsistenten Format gespeichert, deshalb sollen sie bereinigt, konvertiert, in einheitliche Formate umgesetzt und korrekt aggregiert werden. Namenskonventio-

nen, Schlüsselaufbau, Maßeinheiten sowie physischen Eigenschaften von Daten sollen den gleichen Konsistenzregeln folgen.

Ein Data-Warehouse ist nicht-flüchtig - Anwender können die Daten nicht ändern oder aktualisieren. Wenn neue Daten in das Data-Warehouse geladen werden, werden sie im allgemeinen Sinne nicht aktualisiert, sondern als Snapshot-Daten im statischen Format geladen. Zudem werden Aggregationen durchgeführt, um die Daten zusammenzufassen. Die Nicht-Flüchtigkeit sorgt dafür, dass alle Anwender unternehmensweit auf derselben Datenbasis arbeiten können.

Die vierte wichtige Eigenschaft eines Data-Warehouse liegt daran, dass es zeitvariant ist. Ein Data-Warehouse hält historisierte Daten vor, d. h. sie sind dermaßen organisiert, dass ein Zeitraumbezug immer ein Bestandteil der Schlüssel ist. Das DataWarehouse beinhaltet typischerweise die Daten mit einem Horizont von fünf bis zehn Jahren. Die historischen Daten werden für die Feststellung von Abweichungen, Trends sowie langfristigen Beziehungen benutzt.

Die Besonderheit eines Data-Warehouse besteht darin, dass es in die Kategorie von IT¹⁵ - Infrastrukturtechnologien, insbesondere in Bezug auf Datenarchitektur, fällt.¹⁶ Als IT- Infrastruktur wird ein Data-Warehouse wie ein Set von gemeinsam nutzbaren, materiellen IT-Ressourcen definiert, das wie eine Basis für die Ermöglichung von vorhandenen und zukünftigen Applikationen dient.¹⁷ Die Leistungsfähigkeit solcher Infrastrukturen sollte auf den geschäftlichen Nutzen einwirken, indem die wichtigen Geschäftsprozesse unterstützt werden.¹⁸ Ein Data-Warehouse unterstützt die Integration eines Sets von internen und ex- ternen Datenquellen, ermöglicht einen unternehmensweiten sowie interorganisationalen Datenzugriff, setzt Datenqualitätsstandards durch, gibt Antworten auf betriebswirtschaftli- che Fragestellungen und fördert ein strategisches Denken durch Customer Relation Ma- nagement, Data-Mining¹⁹ sowie andere Frontend-Anwendungen.²⁰

In der vorliegenden Arbeit wird der Oberbegriff Informationssystem (IS) verwendet. Unter IS wird ein „System zur Speicherung, Wiedergewinnung […], Verknüpfung und Auswer- tung von Informationen [verstanden]. Ein Informationssystem besteht aus einem Daten- banksystem, Datenmodellen, Klassifizierungen der Daten und den Auswertungsprogram- men […]. Einen Spezialfall bilden Managementinformationssysteme (MIS), in denen alle Größen und Kenndaten gespeichert sind, die zur optimalen Führung eines Unternehmens notwendig und sinnvoll sind.“²¹

2.2 Operationelle Systeme vs. Data-Warehouse-Umgebung

Den im vorherigen Kapitel behandelten Definition und Eigenschaften eines DataWarehouse liegen zwei implizite Annahmen zugrunde²²:

- Ein Data-Warehouse ist von operationellen Systemen physisch separat.

- Ein Data-Warehouse beinhaltet sowohl die aggregierten Daten (Informationsdaten), als auch die Transaktionsdaten (operative bzw. Betriebsdaten).

Als eins der ersten Hindernisse in Data-Warehouse-Projekten behandelt GARDNER die Problematik des Verständnisses, welche Unterschiede zwischen den operativen Daten und Informationsdaten bestehen.²³ Operative Daten sind rund um die funktionellen Organisati- onsstrukturen innerhalb eines Unternehmens organisiert. Die funktionell orientierten Daten erfüllen die sofortige funktionelle Verarbeitung von Anwenderanforderungen. Die funktio- nelle Orientierung ist für operative Daten, d. h. für bestimmte Unternehmensbereiche rele- vante Daten, ideal.

Die Analytiker eines Entscheidungsunterstützungssystems benötigen Informationen aus mehreren Funktionsbereichen oder Geschäftseinheiten, d. h. Daten, die themenorientiert sind und einen Gesamtüberblick verschaffen. Die themenorientierten, detaillierten Trans- aktionsdaten erlauben den Anwendern im Unternehmen den Detaillierungsgrad bis hin zu den einzelnen Geschäftsvorfällen zu erhöhen und nicht nur die Antworten auf spezifische Fragestellungen zu bekommen, sondern auch die Sicht darauf, wie die Ergebnisse zu Stan- de gekommen sind. Die funktionell orientierten „Ofenrohr“-Systeme können eine derartige Analysemethode nicht leisten.

In Tab. 2.1 werden auch die weiteren Unterschieden der beiden Systemarten vorgestellt.²⁴

Abbildung in dieser Leseprobe nicht enthalten²⁵

Quelle: Vgl. Teo, Ang (2000), S. 39.

Tab. 2.1: Unterschiede zwischen operationellen Systemen und Data-Warehouse

Da die Effizienz und Produktivitätsverbesserungen in einem operationellen System leichter greifbar sind, ist die Analyse bezüglich der Kostenvorteile dieser Systeme einfacher durch- zuführen als für ein Data-Warehouse. Hingegen ist eine Messung von Informationswerten für die Entscheidungsträger oft kompliziert, da die beiden Systeme verschiedene Ziele ver- folgen. Der offensichtlichste Nutzen besteht in der Zeitersparnis, weil die Daten nicht aus verschiedenen operationellen Systemen, sondern aus einem Data-Warehouse ausgelesen werden können.

Ein Data-Warehouse beinhaltet denormalisierte (d. h. die Redundanz in einem Databank- aufbau ist erlaubt) und integrierte, historische Werte, die im Zeitbezug nützlich und einfach zugänglich sind. Operationelle Systeme beinhalten vollständig normalisierte Daten, damit die Datenintegrität aufrechterhalten wird. Datenwerte sind in diesen Systemen üblicher- weise aktuell und ändern sich täglich. Operative Daten werden in der Regel nur 60 bis 90 Tage (oder sogar weniger) vorgehalten.²⁶ Daher sind die operationellen Systeme für hohe Datenabfragevolumen zwecks Analyse und Entscheidungsunterstützung nicht geeignet.

Während es bei den funktionellen Prozessen für operationelle Systeme um die Logik von Datenerfassung, -validierung und -berechnung geht, umfassen die funktionellen Prozesse für ein Data-Warehouse die Logik von Transformation und Integration der aus operationellen Systemen extragierten Daten. Die Datendefinitionen dieser extragierten Daten, ihre Integrität und Verlässlichkeit sollen die Konsistenz sicherstellen.

Normalerweise gehören die Systeme und die Daten für operationelle Systeme den Fachabteilungen. Im Falle eines Data-Warehouse wird das Eigentumsrecht in zwei Teile geteilt, indem eine Informationsservice-Abteilung (ISD²⁷ ) die Data-Warehouse-Architektur besitzt und die Fachabteilungen die Daten im Data-Warehouse besitzen. Dies ermöglicht den Fachabteilungen eine Kontrolle der Datenqualität. Zudem wird das ISD durch diese Fachabteilungen im Data-Warehouse-Projekt unterstützt.

Ein implementiertes Data-Warehouse hat sowohl auf die Endbenutzter als auch auf die operationellen Systeme eine positive Auswirkung.²⁸ Die Anwender können davon profitie- ren, dass die Unstimmigkeit unter den operativen Daten bewältigt wird. Mit Hilfe von nut- zerfreundlichen Tools können sie die Daten eigenständig und in einer kürzeren Zeit ausle- sen sowie detaillierte Analysen verschiedener Art durchführen. Mit einem Data-Warehouse ist die Belastung der operationellen Systeme planbarer sowie eine Reduzierung von Be- triebsstörungen möglich. Das nächste Kapitel beschäftigt sich mit weiteren Vorteilen von Data-Warehouse.

2.3 Nutzen des Data-Warehouse

Ein Data-Warehouse an sich schafft keinen Mehrwert; die Wertschöpfung wird durch den Nutzen von Daten im Data-Warehouse generiert.²⁹ Von den Erkenntnissen, die aus dem Data-Warehouse gewonnen werden, profitieren viele Unternehmen³⁰, indem sich ihre Um- sätze wesentlich erhöhen und ihre Kosten sinken, sowie neue, bessere Produkte und Leis- tungen angeboten werden können.³¹ Ein Data-Warehouse spielt auch eine entscheidende Rolle in aktuellen strategischen Unternehmensinitiativen wie Customer Relationship Ma- nagement (CRM), Business Performance Management sowie Supply Chain Management.³²

Der Mehrwert infolge eines gut geführten Data-Warehouse kann enorm sein. HWANG und XU erwähnen das Ergebnis einer Untersuchung von IDC, einem führenden Forschungsunternehmen, welches darauf hinweist, dass die durchschnittlichen Renditen der Investitionen in Data-Warehouse-Projekte bei 400 Prozent liegen.³³

In einem Fallbeispiel berichten WATSON UND HALEY über einen Qualitätsingenieur eines großen Herstellungsunternehmens.³⁴ Er sollte mehr als 20.000 Service-Call-Tickets pro Monat durchlesen sowie die Probleme lösen. Mit der Implementierung eines DataWarehouse und den vorhandenen Service-Call-Daten in diesem Data-Warehouse kann der Ingenieur nun das 30- bis 40-fache an Service-Call-Tickets bearbeiten. Wenn ein Problem eine niedrigere Störfallrate als 0,1 % hat, spart das Unternehmen mehr als $35.000 an Service-Call-Kosten bezüglich dieses Problems pro Monat.

Im Jahr 1997 führten WATSON UND HALEY eine Untersuchung durch, indem sie die 121 Teilnehmer einer Data-Warehousing-Konferenz befragten.³⁵ Die Konferenz wurde vom Data-Warehousing-Institut, der führenden professionellen Organisation für Data- Warehouse-Manager und Fachleute, gefördert. Es handelte sich um die Motivation der Unternehmen, zu denen die Konferenzteilnehmer gehörten, ein Data-Warehouse eingesetzt zu haben. 38 Prozent der Befragten wiesen auf einen besseren Informationszugang hin, 21 Prozent der Befragten profitierten von besseren sowie genaueren Informationen, und 20 Prozent der Befragten nannten die einzige integrierte Datenquelle als Vorteil.

Beachtenswert sind die gewonnenen Vorteile infolge eines Data-Warehouse-Projekts in Anthem-Blue-Cross-And-Blue-Shield, einem der größten Gesundheitsmanagementunter- nehmen in den USA.³⁶ Ein besserer Informationszugriff ermöglicht Anthem die Pflegequa- litätsverbesserung und Pflegekostensenkung für ihre Versicherungsnehmer durch Rück- gang der Betrugsfälle, Verhandlung mit Lieferanten um niedrigere Raten, besseres Risi- komanagement sowie Rettung von Leben, indem die Kenntnisse über die Vertragsärzte aus dem Netzwerk erweitert wurden. Das integrierte Data-Warehouse ermöglicht dem Unter- nehmen die Kundenpflegequalität zu erhöhen und einen effizienten Kundenservice zu ge- währleisten, während die Kosten für Gesundheitsversorgung sich verringern.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Vgl. Watson, Goodhue, Wixom (2002), S. 493; Watson, Haley (1998), S. 36. Abb. 2.1: Potenzielle betriebswirtschaftliche Nutzen von Data-Warehouse

Abb. 2.1 stellt die Systematik von potenziellen betriebswirtschaftlichen Nutzen eines DataWarehouse dar³⁷ und illustriert, dass bestimmte Vorteile im Vergleich zu anderen leichter abschätzbar sind.³⁸ Außerdem reichen die Vorteile von denjenigen, die innerhalb eines Unternehmens eine lokale Wirkung haben, bis zu den Vorteilen, die das Unternehmen im globalen Umfang beeinflussen.

Die Zeitersparnis sowie vielfältigere und bessere Informationen sind die spürbarsten Vor- teile. Anwender führen mit einem Data-Warehouse ihre Aufgaben schneller aus.³⁹ Sie kön- nen auch die Qualitätsverbesserung von Informationen erkennen, obwohl die einzelnen beeinflussten Entscheidungen nicht identifiziert können oder der Nutzen nicht berechnet werden kann. Mit der dritten Kategorie können die einzelnen Entscheidungen oder Entscheidungsgruppen erkannt werden, die deutlich besser als in der Vergangenheit getroffen worden sind. Dies wird vom Data-Warehouse beeinflusst, indem die Manager Probleme und Chancen früher erkennen können. Die größten Vorteile der Data-Warehouse- Applikationen bestehen darin, dass sie der Neugestaltung von Geschäftsprozessen dienen und die strategischen Unternehmensentscheidungen unterstützen, die dann zu wesentlichen Änderungen in der Funktionsweise der Organisation führen.

Der Erfolg und Nutzen eines Data-Warehouse hängt wesentlich von der definierten Architektur innerhalb der Organisation ab.⁴⁰ Eine mangelhafte Entscheidung in der DataWarehouse-Architekturauswahl kann Probleme wie Mangel an Skalierbarkeit oder Einheitlichkeit sowie Erschwernisse in der Leistungsausführung hervorrufen.

Im nächsten Kapitel werden die Komponenten und Architekturarten von Data-Warehouse erläutert.

2.4 Data-Warehouse-Architektur

Eine Architektur von Data-Warehouse enthält die Komponententeile sowie die Verknüpfungen zwischen den Teilen.⁴¹ In Abb. 2.2 wird eine umfassende Data-Warehouse- Architektur dargestellt.⁴²

Im unteren Teil der Abb. 2.2 befinden sich verschiede Datenquellen. Die meisten Daten kommen aus den operationellen Systemen, z. B. aus Betrieb, Marketing oder Buchhaltung. Außerdem können auch externe Daten eingefügt werden. Diese Datenquellen verwenden oft für die Datenlagerung verschiedene Hardware und Software sowie die Mischung aus hierarchischen, relationalen und Netzwerkdatenmodellen. Die Größe der Datenbanken kann von einigen Megabytes bis Gigabytes reichen, was an sich viel, aber im Vergleich zum entsprechenden Data-Warehouse wenig ist. Es ist nicht unüblich, dass ein DataWarehouse auf über 100 Quellsysteme zurückgreift.

Durch Verwendung einer maßgeschneiderten Software oder kommerziellen Extrahieren- Transformieren-Laden -Software (ETL-Software) werden Daten aus diesen Datenquellen extrahiert. Die Daten werden dann dem Transaktionsverarbeitungsbereich für die Trans- formation zugeführt. Spezielle Software kann extra für die Erleichterung von Datenbereinigungsprozessen verwendet werden. Die aufbereiteten Daten können zur Unterstützung des Datenspeichers von operationellen Systemen dienen. Diese Daten werden für das Laden ins Data-Warehouse aufbereitet.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Vgl. Watson (2001), S. 4; Srivastava, Chen (1999), S. 120.

Abb. 2.2: Umfassende Data-Warehouse-Architektur

Das Data-Warehouse ist der Hauptdatenbehälter von historischen Informationen für die Unterstützung von Entscheidungsprozessen. Da die Data-Warehouse-Daten im Unternehmen in der Regel die endgültigen Daten sind, wird dieser Datenbehälter in vielen Fällen „Basisdaten“ genannt. Die Daten werden normallerweise im Batch-Modus eingespielt oder extrahiert, deshalb sind interaktive Abfragen kein wesentliches Thema. Die Daten können direkt aus dem Data-Warehouse für Analysen benutzt werden; in den meisten Fällen werden sie dennoch in den Data-Marts analysiert.

Ein Data-Mart ist ein kleines Data-Warehouse, das entweder auf eine begrenzte Zahl von Themenbereichen des Unternehmens wie „Marketing“ oder „Sales“⁴³ oder auf Unterstüt- zung bestimmter Anwendergruppen wie Finanzanalysten oder Qualitätssicherungsspezia- listen⁴⁴ fokussiert ist.⁴⁵ Daten werden periodisch aus dem Data-Warehouse in die Data- Marts extrahiert. Interaktive Abfragen sind ein wichtiges Thema in Data-Marts, weil die Tools für interaktive Analysen unmittelbar die Daten abrufen. Üblicherweise stellen Data- Marts eine multidimensionalen Sicht von Daten, z. B. Dimensionen „Kunde“, „Produkt“, „Region“ und „Zeit“ bereit.

Im Vergleich zu den abh ä ngigen Data-Marts, die auf die Daten aus dem Data-Warehouse zurückgreifen und Kopien von den aus dem Data-Warehouse extrahierten Daten beschaffen, können andere Data-Warehouse-Architekturen die unabh ä ngigen Data-Marts enthalten, die direkt auf den Quellsystemen aufgebaut werden und in denen wie bei einem DataWarehouse die Daten extrahiert, transformiert und geladen werden.⁴⁶

Die Datenstruktur eines Data-Warehouse wird ausführlich von GRAY und WATSON erläu- tert.⁴⁷ Das Data-Warehouse beinhaltet fünf Datengruppen: aktuelle detaillierte Daten, ältere detaillierte Daten, leicht aggregierte Daten, hoch aggregierte Daten, sowie Metadaten. Alle Datengruppen werden nicht unbedingt auf demselben Datenträger gespeichert, obwohl es eine Software für jede Datengruppe gibt. Eines der zentralen Themen bei dem Data- Warehouse-Design liegt bei der Granularit ä t von Daten, die sich auf die Menge von De- tails oder die Verdichtung von Dateneinheiten bezieht. D. h. je mehr Details es gibt, desto niedriger ist der Granularitätsgrad⁴⁸:

Aktuelle detaillierte Daten. Sie spiegeln die neusten Ereignisse wider. Diese Daten können sehr voluminös werden, wenn sie im niedrigsten Granularitätsgrad abge- speichert werden. Da der niedrigste Grad der Granularität „atomisch“ heißt, d. h. er kann nicht weiter untergegliedert werden⁴⁹, werden diese Daten oft atomische Daten genannt. Oft ist es lediglich eine Replikation von aktuellen Transaktionsdaten, die bereinigt und dann geladen werden. Dennoch müssen nicht alle Felder aus operationellen Systemen übertragen werden. Es ist zu beachten: obwohl die Daten als „aktuelle“ detaillierte Daten bezeichnet werden, sind sie nur zu dem Zeitpunkt aktuell, wenn sie aus dem Transaktionssystem extrahiert werden.

Ältere detaillierte Daten. Die meisten Data-Warehouse folgen der Regel: wenn die detaillierten Daten ein bestimmtes Alter erreichen, werden sie zu dem Massenspeicher verschoben. Obwohl der Zugangsprozess länger dauert, da das Medium langsamer ist, können diese Daten trotzdem abgefragt werden.

Leicht aggregierte Daten. Das Datenaggregieren in Bezug auf die Erwartung von Abfragen für Standardgrößen verbessert in der Praxis die Anwendung und Reaktionszeiten von Data-Warehouse. Data-Warehouse-Entwickler stehen üblicherweise vor zwei Entscheidungen: nach welchen Attributen zu aggregieren und welche Zeiteinheit für die Aggregation auszuwählen ist. Der Kompromiss liegt darin, dass entweder dieselben Abfragen wieder und wieder berechnet werden sollen oder ein größerer Speicherplatz benötigt wird.

Hoch aggregierte Daten. Die höheren Führungskräfte benötigen Informationen, die in einer kompakten und leicht zugänglichen Form vorhanden sind. Diese Informa- tionen werden gewöhnlich immer wieder herangezogen. Die Daten werden über ei- nen langen Zeitraum aufgehoben, damit Trends festgestellt werden können. Bei der Lagerung von hoch aggregierten Daten werden Reaktionszeiten des Data- Warehouse zudem verbessert.

Es ist wichtig, Daten über die Daten in einem Data-Warehouse zu pflegen.⁵⁰ Diese werden als Metadaten definiert und sind eher die Informationen über das Data-Warehouse als die Informationen, die durch das Data-Warehouse bereitgestellt werden. Sowohl die IT- Mitarbeiter, die das Data-Warehouse bedienen und managen, als auch die Anwender, die auf das Data-Warehouse zugreifen, benötigen die Metadaten. Die IT-Mitarbeiter brauchen solche Informationen wie Datenquellen und -ziele; Namen von Datenbanken, Tabellen und Spalten; Aktualisierungszeitplane sowie Anwendungsmesszahlen von Daten. Die Anwen- der benötigen Definitionen von Objekten und Attributen; Informationen über die vorhan- denen Reporting- und Abfragen-Tools; Verteilerinformationen für Berichte sowie die In- formationen zum Helpdesk.

Die Metadaten sind entscheidend für ein Data-Warehouse und beinhalten Folgendes⁵¹:

- Das Inhaltsverzeichnis des Data-Warehouse gibt Aufschluss darüber, wo die Daten abgespeichert werden.
- Der Leitfaden zum Datenmapping vom operativen Format zum Data-Warehouse- Format
- Die Regeln für das Datenaggregieren

Allerdings werden die Metadaten in der Praxis nicht in dem hohen Maße berücksichtigt, wie es sein sollte.⁵² Dies ist mit der mangelhaften Beachtung durch Systementwickler sowie Mangel an Methoden der gemeinsamen Metadatennutzung unter verschiedenen Anbieterprodukten zu begründen.

Viele Anwender greifen auf das Data-Warehouse zu, indem sie Datenanalysewerkzeuge und -applikationen verwenden, die für sie angemessen sind.⁵³ Mehrere verschiedene Applikationen können auf ein Data-Warehouse aufgebaut werden, um strategische Analysen mit Data-Warehouse-Daten durchzuführen.⁵⁴ Im oberen Teil der Abb. 2.2 werden die folgenden Tools dargestellt⁵⁵:

SQL-Queries. Die Anwender, die das grundlegende Data-Warehouse-Datenmodell verstehen und wissen, wie Abfragen in SQL geschrieben werden, können ihre eigenen SQL-Queries schreiben.⁵⁶ Allerdings kann diese Erwartung eher unter ITMitarbeitern (z. B. den Applikationsprogrammierern, die SQL in eine Applikation einbauen) und fortgeschrittenen Nutzern vorausgesetzt werden.

Decision-Support-Systems/Executive-Information-Systems (DSS/EIS). Diese beiden Gruppen von Managementinformationssystemen sind seit Jahren wichtige Ent- scheidungsunterstützungsapplikationen. DSS stellt die Informationen bereit, um die spezifischen Entscheidungsfindungsaufgaben zu unterstützen. EIS stellt die Infor- mationen bereit, die auf breite Informationsbedürfnisse von Führungskräften und anderen Unternehmensmitarbeitern zugeschnitten sind.⁵⁷ Viele EIS verwenden für die Datenansicht das „Slice-and-Dice“-Verfahren und haben DSS-Applikationen eingebaut. Abhängig von der Applikation können DSS/EIS sowohl wenigen als auch einer Vielzahl von Anwendern im Unternehmen dienen.

Online-Analytic-Processing (OLAP). OLAP kann effizient die mehrdimensionalen Sichten von Data-Warehouse darlegen und seine aggregierten Daten in verschiede- nen Kategorien verarbeiten. Diese Applikation ermöglicht Funktionen wie Filte- rung, Aggregation, „Roll-Up“, „Drill-Down“, “Pivoting” etc. Die OLAP-„Würfel“ werden öfter aus dem Data-Warehouse extrahiert und den Entscheidungsträgern zur Verfügung gestellt. Die Anwender können sich mit dieser Applikation einen ver- gleichenden anwenderdefinierten Überblick verschaffen sowie die historischen und geplanten Daten auswerten, daher ist OLAP eine wichtige Methode in Data- Warehouse-Architekturen.

Reporting. Der Reporting-Server ermöglicht das Definieren, die effiziente Ausfüh- rung und Darstellung von Reporten, z. B. der Report „Gesamtumsatz nach Region in diesem Jahr im Vergleich zum Umsatz im vergangenen Jahr“. Das Data- Warehouse leistet den Management-Reporting-Systemen einen guten Beistand, in- dem es eine einheitliche, konsistente und integrierte Datenbank bereitstellt.

Enterprise-Search. Eine unternehmensinterne Suchmaschine unterstützt das Stich- wort-Suchparadigma über den Text und die strukturierten Daten im Data- Warehouse. Beispielsweise kann eine Suche nach E-Mail-Nachrichten, Dokumen- ten, Bestellentwicklung und Support-Calls in Bezug auf einen Kunden durchgeführt werden, damit ein Händler sich vor einem Meeting mit diesem Kunden vorbereiten kann. Dazu ermöglicht die Applikation während der Suche Filterung und Sortie- rung über strukturierte Dokumentenattribute wie Autoren, letztes Änderungsdatum, Dokumentenart und Unternehmen, oder auch andere Datenobjekte, die für die Auswertung von Interesse sein könnten.

Data-Mining. Ein Data-Mining-System ermöglicht eine automatische Suche nach verdeckten Beziehungen in Daten.⁵⁸ Mit Hilfe dieser Applikation können Endnutzer die vorhandenen Beziehungen zwischen den verschiedenen Daten erkennen. Bei- spielsweise dient Data-Mining dazu, neue Marktsegmente zu entdecken, sowie Charakteristiken von Verbrauchern zu erkennen, die ein bestimmtes Marktsegment verlassen haben. Im Vergleich zu OLAP kann das vom Data-Mining gebotene Set von Algorithmen eine bessere Leistung erbringen, indem solche Datenauswertun- gen wie Entscheidungsbaum- und Warenkorbanalysen, lineare und logistische Re- gression, neuronale Netze etc. durchgeführt werden können. Diese speziellen Algo- rithmen sind durch wissenschaftliche Forschung vor mehreren Jahren geschaffen worden, jedoch können diese Forschungsergebnisse erst seit einigen Jahren in Software-Produkte umgesetzt werden.

Obwohl Data-Warehouse-Systeme weitverbreitet sind, gibt es keine allgemeine Meinung, welche Data-Warehouse-Architektur die Beste ist.⁵⁹ Die Herangehensweise der oben vor- gestellten Data-Warehouse-Architektur wird mit Bill Inmon⁶⁰, dem Vater von Data- Warehousing, verbunden.⁶¹ INMON rät den Unternehmen, die top-down Enterprise-Data- Warehouse-Strategie zu verwenden, indem die traditionellen relationalen Datenbank-Tools (ER-Modellierung⁶² ) auf die Entwicklung eines unternehmensweiten Data-Warehouse an- gepasst werden. Auf Basis dieses unternehmensweiten Datenbehälters werden weitere Fachbereichsdatenbanken, d. h. die abhängigen Data-Marts entwickelt. Besonderes Au- genmerk wird darauf gelegt, eine skalierbare und pflegbare Infrastruktur aufzubauen.⁶³ Unter Berücksichtigung der unternehmensbezogenen Sicht auf die Daten, wird die Archi- tektur iterativ bzw. Themenbereich nach Themenbereich entwickelt.

Die Enterprise-Data-Warehouse-Architektur konkurriert seit mehreren Jahren mit der so genannten Data-Mart-Bus-Architektur, die von Ralph Kimball⁶⁴, einem anderen hochange- sehenen Berater im Data-Warehousing, entwickelt wurde.⁶⁵ Abb. 2.3 stellt das Schema einer Data-Mart-Bus-Architektur dar. KIMBALL rät den Unternehmen, eine bottom-up Da- ta-Mart-Strategie mit der dimensionalen Modellierung zu verwenden. Anstatt eine einzige unternehmensweite Datenbank zu erstellen, schlägt der Berater vor, einzelne Datenbanken, d. h. unabhängige Data-Marts, pro Hauptgeschäftsprozess aufzubauen. Die dimensional modellierten Data-Marts werden miteinander verknüpft und wirken durch den Data-Bus- Standard zusammen wie ein unternehmensweites Data-Warehouse.

Die Hauptanforderung dieses Data-Bus-Standards besteht darin, dass alle Data-Marts die standardisierten, konformen Dimensionen verwenden sollen.⁶⁶ Unter den konformen Di- mensionen werden die Dimensionen mit konsistenten Schlüsseln, Kolumnennamen, Attri- butdefinitionen und Attributwerten über die Geschäftsprozesse verstanden, d. h. zwei kon- forme Dimensionen sind gleich, oder eine ist der perfekte Teilsatz von der anderen. Unter Verwendung von konformen Dimensionen werden zusätzliche Data-Marts nachgebaut und logisch integriert, indem eine Unternehmenssicht von Daten geschaffen werden kann. Dabei beinhaltet diese Architektur keine normalisierten, relationalen Daten.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Vgl. Jukic (2006), S. 86.

Abb. 2.3: Data-Mart-Bus-Architektur

Die Enterprise-Data-Warehouse- und Data-Mart-Bus-Architekturen sind grundlegend unterschiedliche Herangehensweisen, und jede hat ihre starken Befürworter. ARIYACHANDRA UND WATSON erläutern auch zwei weitere Data-Warehouse-Architekturalternativen: die unabhängigen Data-Marts sowie die föderierte Architektur.⁶⁷ Zum Vergleich werden die vier Data-Warehouse-Architekturen in Abb. 2.4 dargestellt.

Für einige Unternehmen sind die unabh ä ngigen Data-Marts erste Versuche, einen Datenbehälter für die Entscheidungsunterstützungsinformationen aufzubauen. Diese Data-Marts sind üblicherweise von anderen Datenbanken unabhängig und dienen spezifischen lokalen Anforderungen einer bestimmten Applikation oder Geschäftseinheit. Sie beinhalten inkonsistente Datendefinitionen und verwenden verschiedene Dimensionen und Werte, daher ist die Durchführung einer übergreifenden Datenanalyse kompliziert.

Eine föderierte Architektur ist zu empfehlen, wenn eine fragmentierte Entscheidungsunterstützungsdatenumgebung besteht und es möglich ist, zumindest einen Teil dieser Daten zu integrieren. Nach Fusionen, Übernahmen sowie Unternehmensreorganisationen kann es zu einer derartigen Situation kommen. Wegen politischer Gegebenheiten innerhalb des Unternehmens und Implementationsherausforderungen werden keine Anstrengungen unternommen, eine einheitliche, integrierte Lösung zu entwickeln.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Vgl. Ariyachandra, Watson (2006), S. 5.

Abb. 2.4: Arten von Data-Warehouse-Architekturen

Die föderierte Architektur lässt existierende Entscheidungsunterstützungsstrukturen (z. B. operationelle Systeme, Data-Marts) unverändert. Unter Verwendung von gemeinsam benutzten Schlüsseln, unternehmensweiten Metadaten, verteilten Suchanfragen etc. werden die Daten entweder logisch oder physisch integriert.

Am Anfang eines Data-Warehouse-Projektes steht jedes Unternehmen vor den Überlegungen, welche reellen Unterschiede und Zielkonflikte in Bezug auf die zur Auswahl stehenden Data-Warehouse-Architekturen bestehen, und muss entscheiden, welche Herangehensweise für individuelle Unternehmensumgebung am besten geeignet ist.⁶⁸

[...]

---

¹ Vgl. March, Hevner (2007), S. 1031; Watson (2001), S. 2.

² Vgl. Watson, Fuller, Ariyachandra (2004), S. 435.

³ Vgl. Mukherjee, D’Souza (2003), S. 82; Ma, Chou, Yen (2000), S. 125.

⁴ Vgl. Ramamurthy, Sen, Sinha (2008), S. 817; March, Hevner (2007), S. 1031; Quaddus, Intrapairot (2001), S. 223; Teo, Ang (2000), S. 35.

⁵ Vgl. Ramamurthy, Sen, Sinha (2008), S. 817 f.; Hall (2002).

⁶ Vgl. Mukherjee, D’Souza (2003), S. 82.

⁷ Vgl. Ramamurthy, Sen, Sinha (2008), S. 818; Wixom, Watson (2001), S. 18.

⁸ Vgl. Mukherjee, D’Souza (2003), S. 82.

⁹ Vgl. Hartono, Santhanam, Holsapple (2007), S. 257; Gray, Watson (1998a), S. 8 ff.

¹⁰ Vgl. Watson (2001), S. 2.

¹¹ Vgl. Klesse, Winter (2007), S. 2; Watson (2001), S. 2.

¹² Vgl. Gardner (1998), S. 54.

¹³ Vgl. Hwang et al. (2004), S. 2; Devlin, Murphy (1988), S. 62 f.

¹⁴ Vgl. Inmon (2005), S. 29 ff.; Watson (2001), S. 2; Ang, Teo (2000), S. 15; Gray, Watson (1998b), S. 84 f.

¹⁵ Abkürzung für Informationstechnologie. Heutzutage wird der Begriff „elektronische Datenverarbeitung (EDV)“ durch den Begriff „IT“ meist ersetzt. Diese sind Oberbegriffe für die Methoden und Geräte, mit denen Daten auf elektronischem Weg verarbeitet werden können. O. V. (2004), S. 103; O. V. (2003), S. 296.

¹⁶ Vgl. Ramamurthy, Sen, Sinha (2008), S. 819.

¹⁷ Vgl. Wixom, Watson (2001), S. 18; Duncan (1995), S. 39 f.

¹⁸ Vgl. Wixom, Watson (2001), S. 18; Ross, Beath, Goodhue (1996), S. 31 f.

¹⁹ Im Kapitel 2.4 werden derartige Applikationen ausführlich behandelt.

²⁰ Vgl. Ramamurthy, Sen, Sinha (2008), S. 819; Wixom, Watson (2001), S. 18.

²¹ O. V. (2001), S. 304.

²² Vgl. Gray, Watson (1998b), S. 84; Gardner (1998), S. 54.

²³ Vgl. Gardner (1998), S. 54 f.

²⁴ Vgl. Teo, Ang (2000), S. 38 ff.

²⁵ Im Englischen „Information Services Department“.

²⁶ Vgl. Gray, Watson (1998b), S. 85.

²⁷ Aus dem Englischen „Information Services Department“.

²⁸ Vgl. Watson et al. (2001b), S. 7 f.; Teo, Ang (2000), S. 42 f.

²⁹ Vgl. Watson, Haley (1998), S. 36.

³⁰ Vgl. Hwang, Xu (2008), S. 48; Hwang, Xu (2005), S. 7.

³¹ Vgl. Cooper et al. (2000), S. 560; Watson, Haley (1998), S. 36.

³² Vgl. Ariyachandra, Watson (2010), S. 200; Watson, Fuller, Ariyachandra (2004), S. 435; Watson et al. (2001a), S. 19 ff.; Cooper et al. (2000), S. 557 ff.

³³ Vgl. Hwang, Xu (2008), S. 48.

³⁴ Vgl. Watson, Haley (1998), S. 36.

³⁵ Vgl. Watson, Haley (1998), S. 34.

³⁶ Vgl. Claudio (1998), S. 58.

³⁷ Vgl. Watson, Goodhue, Wixom (2002), S. 492 f; Watson, Haley (1998), S. 36 f.

³⁸ Vgl. Watson et al. (2001b), S. 53.

³⁹ Vgl. Park (2006), S. 57.

⁴⁰ Vgl. Ariyachandra, Watson (2010), S. 200.

⁴¹ Vgl. Watson (2001), S. 4.

⁴² Vgl. Chaudhuri, Dayal, Narasayya (2011), S. 90 f.; Watson (2001), S. 4 f.; Srivastava, Chen (1999), S. 119 f.

⁴³ Vgl. Watson (2001), S. 3.

⁴⁴ Vgl. Watson (2001), S. 4.

⁴⁵ Vgl. Srivastava, Chen (2001), S. 119; Gray, Watson (1998b), S. 88.

⁴⁶ Vgl. Watson (2001), S. 3.

⁴⁷ Vgl. Watson, Gray (1998b), S. 85 f.

⁴⁸ Vgl. Inmon (2005), S. 41.

⁴⁹ Vgl. Kimball et al. (2008), S. 134; Breslin (2004), S. 13.

⁵⁰ Vgl. Watson (2001), S. 10; Gray, Watson (1998b), S. 86.

⁵¹ Vgl. Gray, Watson (1998b), S. 86; Gardner (1998), S. 59 f.

⁵² Vgl. Watson (2001), S. 10.

⁵³ Vgl. Watson (2001), S. 5.

⁵⁴ Vgl. Srivastava, Chen (1998), S. 119.

⁵⁵ Vgl. Chaudhuri, Dayal, Narasayya (2011), S. 90-98; March, Hevner (2007), S. 1036 f.; Watson (2001), S. 14 f.; Ma, Chou, Yen (2000), S. 127 ff.

⁵⁶ Vgl. Watson (2001), S. 14; Joshi, Curtis (1999), S. 33 f.

⁵⁷ Vgl. Watson, Houdeshel, Rainer (1997), S. 3.

⁵⁸ Vgl. Ma, Chou, Yen (2000), S. 127.

⁵⁹ Vgl. Ariyachandra, Watson (2010), S. 200; Watson et al. (2001a), S. 3.

⁶⁰ Vgl. Inmon, W. H.: Building the Data Warehouse. 4. Aufl., Indianapolis 2005.

⁶¹ Vgl. Ariyachandra, Watson (2006), S. 4; Breslin (2004), S. 6; Hwang, Cappel (2002), S. 3; Watson (2001), S. 5; Watson et al. (2001a), S. 3 ff.

⁶² Aus dem Englischen „Entity-Relationship-Modeling“.

⁶³ Ariyachandra, Watson (2008), S. 146.

⁶⁴ Vgl. Kimball, R. et al.: The Data Warehouse Lifecycle Toolkit. 2. Aufl., Indianapolis 2008.

⁶⁵ Vgl. Ariyachandra, Watson (2006), S. 4; Breslin (2004), S. 6; Hwang, Cappel (2002), S. 3; Watson (2001), S. 5; Watson et al. (2001a), S. 4 f.

⁶⁶ Vgl. Breslin (2004), S. 13; Kimball et al. (2008), S. 244.

⁶⁷ Vgl. Ariyachandra, Watson (2008), S. 146 f.

⁶⁸ Vgl. Jukic (2006), S. 83.