Home Data Warehousing Warum benötigt man ein Data Warehouse: Definition, Architektur und Vorteile

Warum benötigt man ein Data Warehouse: Definition, Architektur und Vorteile

Was ist ein Data Warehouse (Kapitel 1), wie ist es aufgebaut (Kapitel 2) und warum brauche ich als Organisation ein Data Warehouse (Kapitel 3)? Diese Fragen beantwortet der folgende Wissensartikel.

Inhaltsverzeichnis

1. Was ist ein Data Warehouse?

1.1. Definition Data Warehouse

„Ein Data Warehouse ist ein subjektorientierter integrierter, zeitraumbezogener und nicht-volatiler Datenbestand, um die Entscheidungs-, Planungs- und Controlling Prozesse des Managements zu unterstützen“ (Müller & Lenz, 2013, S. 14).

Data Warehousing kann als einer der wichtigsten Bestandteile des Business Intelligence gesehen werden. Man versteht darunter den gesamten Prozess, der in einem Data Warehouse durchlaufen wird. Die einzelnen Schritte dieses Prozesses werden folgend dargestellt:

  1. Der Prozess beginnt mit der Datenbeschaffung, welche auf externen sowohl als auch internen Quellen eines Unternehmens basiert.
  2. Darauf folgt Datenaufbereitung und die darauffolgende Datentransformation.
  3. Schlussendlich werden die aufbereiteten sowie transformierten Daten schliesslich im Data Warehouse gespeichert – Daten Speicherung. (Müller & Lenz, 2013, S. 11)
 

Diese Prozessschritte lassen darauf schliessen, dass dieser Prozess im Grunde genommen nur die Datenbankpflege gesammelter Daten beschreibt. Diese Annahme ist jedoch weit gefehlt: Die Realität zeigt, dass dieser weit gefasste Prozess aus vielen einzelnen Prozessen besteht, welche einen enormen Arbeitsaufwand besitzen. Ein Beispiel dafür ist der ETL Prozess (Extraktion, Transformation und Laden), welcher beschreibt, wie die den verschiedenen Abteilungen zugeordneten Daten in das Data Warehouse übertragen und miteinander verknüpft werden. (Müller & Lenz, 2013, S. 11-12)

1.2. Woher stammt die Idee des Data Warehouse?

Historisch betrachtet taucht der Begriff Data Warehouse erstmals im Jahr 1988 auf. Barry A. Delvin und Paul T. Murphy beschreiben hier erstmals den Einsatz einer zentralen Stelle zur Datensammlung. (Köppen, 2014)

Sie beschrieben in der Zeitschrift „Systems Journal“ von IBM, dass aufgrund des voranschreitenden Einsatzes von IT-Systemen in den Unternehmen das Bedürfnis entstand, auf die in den jeweiligen Systemen hinterlegten Unternehmensdaten zugreifen zu können. Anhand dieses Bedürfnisses war eindeutig erkennbar, dass eine Architektur beziehungsweise ein System notwendig ist, welches diese gesammelten Unternehmensdaten aus den verschiedenen IT-Anwendungen zusammenführt und einen einheitlichen Zugriff darauf ermöglicht. Delvin und Murphy (1988) stellten hier über knapp 20 Seiten hinweg das eigens aufgebaute EBIS vor. Das E steht für die Kürzel der Regionen Europa (E), Mittlerer Osten (ME) und Afrika (A) die Buchstaben BIS stehen für Business Information System.  Dieses von IBM intern entwickelte System sollte es ermöglichen, erstmals die IT-Daten aus den verschiedenen Regionen zusammenzuführen und gilt somit als erstes Beispiel für ein Data Warehouse System. (Devlin & Murphy, 1988, S. 60)

2. Wie ist ein Data Warehouse aufgebaut?

Für ein Data Warehouse gibt es verschiedene Anforderungen, die sich je nach Branche und Unternehmen stark verändern können. Daher existiert keine fest einzuhaltende Architektur für ein Data Warehouse. Im Laufe der Zeit haben sich die Aufbauten der Data Warehouses also immer wieder verändert und es entstanden verschiedene Modellierungsvarianten, die die Architektur eines Data Warehouses beschreiben. (Hahne, 2014)

In vielen Unternehmen sind Data Warehouse Konzepte historisch gesehen nicht basierend auf einem proaktiven Plan hin zur Durchführung von Business Intelligence entstanden. Stattdessen entstanden sie im Zuge der fortlaufenden Weiterentwicklung von IT-Systemlandschaften in den jeweiligen Unternehmen. Beim Aufbau eines Data Warhouses gibt es verschiedene sowohl technische als auch betriebswirtschaftliche Aspekte, die zu beachten sind. Daher ist es von Vorteil, wenn die Architektur eines Data Warehouses von Grund auf geplant und durchdacht wurde. Dieses strukturierte Vorgehen liefert im weiteren Verlauf Vorteile, sowohl bei der Nutzung als auch bei der Weiterentwicklung des Data Warehouses. (Gluchowski, 2021)

Aufgrund der Vorteile, die eine strukturierte Architektur für ein Data Warehouse mit sich bringt, wird folgend zuerst eine Grundlegende Struktur eines Data Warehouses dargestellt. Daraufhin werden einige Beispiele verschiedener Architekturvarianten vorgestellt.

Abbildung 1:Architektur eines Data Warehouses (Müller & Lenz, 2013, S. 19)
Abbildung 1: Architektur eines Data Warehouses (Müller & Lenz, 2013, S. 19)

Abbildung 1 stellt den grundlegenden Aufbau, sowie notwendige Komponenten eines Data Warehouses dar. Zu einem Data Warehouse werden sowohl die Daten aus den verschiedenen Quellen (Abbildung 1 Bereich 1), als auch die ETL Prozesse, welche die verschiedenen Daten in den 3. Bereich und das hier zentral abgebildete Data Warehouse (Core Data Warehouse) laden, zu der Gesamtkonzeption eines Data Warehouses hinzugezählt. Ebenso wird bei der Grundkonzeption eines Data Warehouses die Bereitstellung der Daten aus dem Core Data Warehouse zur Erstellung von Datenanalysen und Reports miteinbezogen. (Müller & Lenz, 2013)

Im folgenden werden die folgenden fünf bekanntesten Modellierungsvarianten näher beschrieben:

  • Unabhängige Data Marts – Stove Pipe

  • Data Marts mit gemeinsamen Dimensionen

  • Abhängige Data Marts – Hub and Spoke

  • Föderierte Architekturen

  • Data-Warehouse-Schichtenarchitektur

2.1. Unabhängige Data Marts – Stove Pipe

Bei der ersten Modellierungsvariante der Architektur eines Data Warehouses spricht man von unabhägnigen Data Marts. Dies beschreibt den Fall, wenn in Unternehmen einzelne Abteilungen damit beginnen, selbst Business Intelligence Lösungen aufzubauen. Solch ein Vorgehen hat zur Folge, dass jede Abteilung ein eigenen Data Mart aufbaut. Somit besteht das Core Data Warehouse aus der Unternehmenssicht betrachtet aus mehreren abteilungsbezogenen Data Marts die unabhängig voneinander sind. Diese Modellierungsvariante ist als negativ-Beispiel zu sehen, da in diesem Fall im Unternehmen kein „Single point of truth“ vorhanden ist, der die gemeinsame Datenwahrheit darstellt. Das liegt daran, dass die Daten in den jeweiligen Data Marts in unterschiedlichen Dimensionen eingeteilt und zudem auch unterschiedlich gekennzeichnet sind. Daraus resultiert, dass die Daten aus den jeweiligen Abteilungen nicht miteinander vergleichbar sind und zudem für jede Abteilung bzw. Data Mart ein eigener ETL Prozess angelegt werden muss. (Müller & Lenz, 2013, S. 21)

2.2. Data Marts mit gemeinsamen Dimensionen

Bei einer Weiteren Modellierungsvariante sind die Data Marts über gemeinsame Dimensionen miteinander verbunden. Dies sorgt dafür, dass die einzelnen Data Marts nicht mehr unabhängig voneinander sind. Das ermöglicht ein hin- und her wechseln zwischen Data Marts die über eine bestimmte Dimension miteinander verbunden sind. Als Beispiel führen Müller und Lenz hier die Verknüpfung des Absatz Data Marts mit dem Personaleinsatz Data Marts auf. Diese beiden Würfel sind beispielweise durch die für beide Fälle identische Filialstruktur und somit die Ortsdimension miteinander verbunden. (Müller & Lenz, 2013, S. 21)

2.3. Abhängige Data Marts – Hub and Spoke

Die Modellierungsvariante mit abhängigen Data Marts wird häufig als Hub and Spoke Architektur bezeichnet und stellt neben der Architektur mit Data Marts mit gemeinsamen Dimensionen die am häufigsten genutzte Architektur in der Praxis dar. In diesem Fall werden die Data Marts nach einem vorgegebenen Schema, welches für das gesamte Unternehmen gilt, von dem ODS mit Daten versorgt. Dieser Ansatz entspricht dem Gegensatz zu den unabhängigen Data Marts und verfolgt das sogenannte Top Down Prinzip. (Müller & Lenz, 2013, S. 22)

2.4. Föderierte Architekturen

Die förderierte Architektur eines Data Warehouses kommt zum Einsatz, wenn auf die Daten in den Quellsystemen direkt zugegriffen und diese nicht durch einen ETL Prozess extrahiert werden sollen. Dabei wird bei Abfragen virtuell auf die Daten zugegriffen, um sie mit in die Analysen einfliessen zu lassen. Diese Vorgehensweise wird genutzt, wenn Daten schnelllebig sind oder von Dritten verwaltet werden. Die Hauptkomponenten sind bei der föderierten Architektur der Wrapper und der Mediator. Der Wrapper stellt den Zugriff auf die Daten in den Quellsystemen bereit und gleicht die Daten aneinander an. Wobei der Mediator die Abfragen koordiniert und die Ergebnisse miteinander verbindet.

2.5. Data-Warehouse-Schichtenarchitektur

Neben den klassischen Strukturen eines Data Warehouses hat sich mittlerweile eine weitere Grundlgegende Architektur für ein Data warehouse etabliert. Hierbei handelt es sich um die Schichtenarchitektur, worin die einzelnen Komponenten und Prozesse des Data Warehoueses in verschiedene Schichten eingeteilt werden. (Gluchowski, 2021)

Gluchowski verweist ausserdem darauf, dass es in der Praxis keine einheitliche Vorgabe gibt, wie die Schichten aufgebaut und bezeichnet werden. Folgend wird daher das Beispiel einer idealtypischen Schichtenarchitektur von Gluchowski dargestellt.

Abbildung 2: Schichtenarchitektur Data Warehouse (Gluchowski, 2021)

Wie Abbildung 2 verdeutlicht, entspricht der Start- und Endpunkt der Schichtenarchitektur den Start- und Endpunkten der in Abbildung 1 dargestellten grundlegenden Architektur eines Data Warehouses. In beiden Architekturen sind die externen Quellen der Ursprung und die Analysen sowie Reportings das Ziel des Data Warehousing Prozesses.

3. Warum benötigt man ein Data Warehouse?

Data Warehousing ist ein essenzieller Bestandteil von Business Intelligence. Häufig wird der Begriff Data Warehousing auch zur Bezeichnung des Prozesses, der sich hinter Business Intelligence verbirgt, verwendet. Die Literatur zeigt, dass die Grenzen zwischen den Prozessen hinter den beiden Begriffen nicht klar definiert sind und ineinander übergehen.

Den Begriff Data Warehousing definieren Müller und Lenz (2013) wie folgt:

„Unter Data Warehousing versteht man den Geschäftsprozess, der die Datenbeschaffung aus internen und extern zugänglichen Quellen, die Datentransformation und -aufbereitung gemäss der Quell- und Zieldatenbankschemata, die Datenqualitätssicherung und die Speicherung im (zentralen) Data Warehouse bzw. in (dezentralen) Data Marts (Benutzersichten) und die auf OLAP basierende Datenanalyse umfasst.“ (Müller & Lenz, 2013, S. 11)

Müller und Lenz (2013) stellen in Ihrem Buch zu Business Intelligence dar, dass der Anteil des Data Warehousings 25% an dem gesamten Konzept, das durch das Wort Business Intelligence beschrieben wird, ausmacht. Ergänzt wird dieser Beitrag zu 25% von Data Mining und Statistik sowie zu 50% von Betriebswirtschaft und Operations-Research. (Müller & Lenz, 2013, S. 15)

Daher kann die Frage „Warum wird ein Data Warehouse benötigt?“ damit beantwortet werden, dass ein Data Warehouse und der Prozess des Data Warehousings notwendig ist, um Business Intelligence in einem Unternehmen auszuführen. Um die Frage nach dem „Warum“ im Sinne eines Data Warehouses eindeutig zu beantworten, muss folglich zuerst die Frage nach der Motivation für Business Intelligence in einem Unternehmen beantwortet werden.

Exkurs: Business Intelligence

Schon seit über 60 Jahren wird in Unternehmen IT-basierte Managementunterstützung stetig vorangetrieben. Im Vordergrund stand hierbei meist, Führungskräfte durch die Nutzung von gesammeltem Wissen bzw. Erfahrungen in Form von IT-basierten Zahlen, Daten und Fakten für zukünftige Management Entscheidungen oder auch zur Festlegung für strategisches Vorgehen zu unterstützen. Es dauerte jedoch einige Jahre, bis die ersten funktionsfähigen sowie erfolgreich eingesetzten Systeme entwickelt wurden. Diese waren zu Beginn noch aufgabenorientiert. (Kemper, Baars, & Mehanna, 2010, S. 1)

Der Begriff „Management Support Systems“ hat sich in den 80er Jahren durchgesetzt, um die Vielfallt an bestehenden Informations- und Kommunikationssystemen zusammenzufassen. Er findet auch heute noch seine Verwendung in der Wissenschaft. Dies liegt daran, dass damit beschrieben wird, wie IT-basierte Managementunterstützung sich nicht nur auf die Nutzung von Computern bezieht, sondern ebenso auf die Unterstützung des Managements mit Hilfe von Informations- und Kommunikationstechnologien abzielt. (Kemper, Baars, & Mehanna, 2010, S. 1)

Der Begriff Business Intelligence beschreibt im Grunde die IT-basierte Managementunterstützung und wird seit den 90er Jahren konstant dazu genutzt, Prozesse und Anwendungen zu beschreiben, die mit der IT im Zusammenhang stehen. Zurückzuführen ist dieser Begriff hauptsächlich auf Überlegungen der Gardner Group, welche sich mit Marktforschungen sowie der Analyse von Entwicklungen in der IT beschäftigt. Festzuhalten ist zudem, dass der Begriff Business Intelligence nicht eindeutig zu definieren oder zu beschreiben ist.  Die Definitionsvielfalt für diesen Sammelbegriff ist gross und führt unter anderem dazu, dass dieser Begriff fortlaufend dafür gesorgt hat, das Prinzip der IT-basierten Managementunterstützung zu diskutieren und ständig neu zu überdenken. (Kemper, Baars, & Mehanna, 2010, S. 2)

Mit den Erkenntnissen, wie ein Data Warehouse funktioniert und warum Unternehmen sich dazu entscheiden, Business Intelligence umzusetzen, lässt sich die Frage, warum ein Data Warehouse benötigt wird, wie folgt beantworten:

Hier ist zum einen die grundlegende Motivation zu nennen, welche sich hinter dem Wort Business Intelligence verbirgt. Diese beinhaltet das Ziel, die IT basierte, strategische Managementunterstützung zu ermöglichen. Dabei geht es darum, dem Management mithilfe der Verknüpfung und Analyse von unternehmensweiten Datenbeständen eine fundierte Grundlage zu bieten, um darauf basierend strategische Entscheidungen treffen zu können.

An diesem Punkt kommt das Data Warehouse zum Einsatz, denn die Funktionalitäten eines Data Warehouses ermöglichen es Unternehmen, alle Daten zu vereinen und diese so zu modellieren, dass komplexe Abfragen sowie Analysen anhand der Datenbestände möglich sind.  

Literaturverzeichnis

Devlin, B. A. & Murphy, P. T. (1988). An architecture for a business and information system. IBM Systems Journal, 60–80. https://www.semanticscholar.org/paper/An-Architecture-for-a-Business-and-Information-Devlin-Murphy/c22ce1eeafb01f0682e194a2a22349aa141b78f6

Gluchowski, P. (2021, 26. Februar). Data Warehouse. Enzyklopaedie der Wirtschaftsinformatik. https://enzyklopaedie-der-wirtschaftsinformatik.de/wi-enzyklopaedie/lexikon/daten-wissen/Business-Intelligence/Data-Warehouse

Hahne, M. (2014). Modellierung von Business-Intelligence-Systemen: Leitfaden für erfolgreiche Projekte auf Basis flexibler Data-Warehouse-Architekturen. Edition TDWI. TDWI Europe. http://site.ebrary.com/lib/alltitles/Doc?id=10904187

Kemper, H.‑G., Baars, H., & Mehanna, W. (2010). Business Intelligence – Grundlagen und praktische Anwendungen: Eine Einführung in die IT-basierte Managementunterstützung  (3., überarbeitete und erweiterte Auflage). Studium Wirtschaftsinformatik. Vieweg + Teubner.

Köppen, V. (2014). Data Warehouse Technologien (2. Aufl.). mitp Professional. mitp. https://ebookcentral.proquest.com/lib/kxp/detail.action?docID=6166362

Müller, R. M. & Lenz, H.‑J. (2013). Business Intelligence. Springer Berlin Heidelberg. https://doi.org/10.1007/978-3-642-35560-8

Published by:

Marco Ferrari

Masterand
autor:IN

Wie hat Ihnen der Artikel gefallen?

Wie hilfreich war dieser Beitrag?

Klicken Sie auf einen Stern, um zu bewerten!

Durchschnittliche Bewertung 5 / 5.
Anzahl Bewertungen: 3

Bislang keine Stimmen! Seien Sie die erste Person, die diesen Beitrag bewertet!

Share on twitter
Share on facebook
Share on xing
Share on linkedin
Share on email

ANALYTICS LÖSUNGEN

Erfahren Sie mehr über unsere Analytics Lösungen

INFORMATIONEN

Weitere Informationen

Wiki - The Big 5 - Sustainability Reporting

Die „Big Five“ des Sustainability Reportings

Wer gibt Standards im Bereich der Nachhaltigkeitsberichterstattung vor? Der folgende Wissensartikel befasst sich mit dieser Frage. Es werden fünf verschiedene…

Titelbild On-Premise vs. Off-Premise Software Was ist der Unterschied

On-Premise vs. Off-Premise Software: Was ist der Unterschied?

Was ist On- und was ist Off-Premise Software und was ist der Unterschied? Diese Thematik behandelt der folgende Wissensartikel. Zudem…

Wiki 5 Sustainability KPIs

Die 5 wichtigsten Sustainability KPIs

Was sind die 5 wichtigsten Sustainability KPIs? Und warum sind Sustainabilty KPIs wichtig für Ihr Unternehmen? Inhaltsverzeichnis 1. Wozu werden…

Wiki Wie berechne ich den Carbon Footprint

Überblick Carbon Footprint Software

Vorabinformation: Diesem Artikel gehen zwei Wikis voraus: (1) „Corporate und Product Carbon Footprint“ und (2) „Wie berechne ich einen Carbon…

Wiki Wie berechne ich den Carbon Footprint

Wie berechne ich den Carbon Footprint?

Dieser Artikel beantwortet die Frage, wie man einen Carbon Footprint – also einen ökologischen Fussabdruck – berechnet. Dabei werden wichtige…

Wiki Analysis for Office

Optimierte Effizienz für End-User: SAP Analysis for Office (AfO)

Dieser Artikel gibt eine Überblick über SAP Analysis for Office (AfO). Zudem werden folgende Fragen beantwortet: Was ist eine SAP…

Wiki Corporate Carbon Footprint

Corporate Carbon Footprint & Product Carbon Footprint

Was ist der Corporate Carbon Footprint und was ist der Product Carbon Footprint? Welche Rolle spielen dabei das Drei-Säulen-Modell, Scope…