Durch: Arshad Ali | Aktualisiert: 2013-06-24 | Bemerkungen (9) | Verwandt: > Analysis Services-Entwicklung
Problem
In meinen letzten Tipps habe ich über die Bedeutung einer Business Intelligence-Lösung gesprochen, warum es für Führungskräfte Priorität hat, was für ein typische Business Intelligence Systemarchitektur sieht aus wie, etc. In diesem Tipp werde ich ausführlich darüber sprechen, wie sich ein Data Warehouse vom operativen Datenspeicher unterscheidet und welche unterschiedlichen Entwurfsmethoden für ein Data Warehouse verwendet werden.
Lösung
Dieser Tipp behandelt Data Warehouses (DW, manchmal auch Enterprise Data Warehouse oder EDW genannt), wie sie sich von Operational Data Store (ODS) und verschiedenen Data Warehouse-Entwurfsmethoden unterscheiden.
Enterprise Data Warehouse (EDW oder DW) Gegen. Operational Data Store (ODS)
Der Zweck des Data Warehouses in der gesamten Business Intelligence-Architektur besteht darin, Unternehmensdaten aus verschiedenen heterogenen Datenquellen zu integrieren, um das Reporting von Historien- und Trendanalysen zu erleichtern. Es fungiert als zentrales Repository und enthält die „Single Version of Truth“ für die Organisation, die sorgfältig aus Daten erstellt wurde, die in unterschiedlichen internen und externen Betriebsdatenbanken \ Systemen gespeichert sind. Für eine bessere Leistung liegen die meisten Daten im Data Warehouse in der normalisierten Form vor, die entweder in Stern- oder Schneeflockenschemata kategorisiert werden kann (mehr dazu im nächsten Tipp).
Der Zweck des Operation Data Store (ODS) besteht darin, Unternehmensdaten aus verschiedenen heterogenen Datenquellen zu integrieren, um das operative Reporting in Echtzeit oder nahezu in Echtzeit zu ermöglichen. Oft sind die Daten im ODS ähnlich strukturiert wie die Quellsysteme, obwohl sie während der Integration Datenbereinigung, Deduplizierung und Anwendung von Geschäftsregeln zur Gewährleistung der Datenintegrität erfordern können. Ein ODS ist hauptsächlich dazu gedacht, Daten recht häufig auf der niedrigsten granularen Ebene für die operative Berichterstattung in einem nahezu Echtzeit-Datenintegrationsszenario zu integrieren. Normalerweise wird ein ODS nicht für historische und Trendanalysen großer Datenmengen optimiert.
Fassen wir die Unterschiede zwischen einem ODS und DW zusammen:
- Ein ODS ist für die operative Berichterstattung gedacht und unterstützt aktuelle oder nahezu Echtzeitberichterstattungsanforderungen, wobei ein DW für die historische und Trendanalyseberichterstattung über ein großes Datenvolumen gedacht ist
- Ein ODS ist für niedriggranulare Abfragen gedacht, während ein DW für komplexe Abfragen auf Zusammenfassungsebene oder für aggregierte Daten verwendet wird
- Ein ODS liefert Informationen für operative, taktische Entscheidungen über die aktuelle oder nahezu Echtzeitdatenerfassung, bei der DW liefert Feedback für strategische Entscheidungen, die zu Gesamtsystemverbesserungen führen
- In einem ODS die Häufigkeit der Datenlast kann stündlich oder täglich sein, während in einem DWdie Häufigkeit der Datenlasten täglich, wöchentlich, monatlich oder vierteljährlich sein kann
Data Warehouse-Entwurfsmethoden
Beim Entwerfen einer Data Warehouse-Lösung werden normalerweise zwei verschiedene Methoden angewendet. Diese Methoden sind das Ergebnis von Forschungen von BillInmon und Ralph Kimball.
Bill Inmon – Top-Down-Data-Warehouse-Designansatz
Bill Inmon wird manchmal auch als „Vater des Data Warehousing“ bezeichnet; seine Entwurfsmethodik basiert auf einem Top-Down-Ansatz und definiert Data Warehouse in diesen Begriffen
- Subjektorientiert – Die Daten in einem Data Warehouse werden auf der Grundlage des Themenbereichs kategorisiert und sind daher „subjektorientiert“.
- Integriert – Daten werden aus verschiedenen unterschiedlichen Datenquellen integriert und daher universelle Namenskonventionen, Messungen, Klassifikationen usw., die im Data Warehouse verwendet werden. Das Data Warehouse bietet eine konsolidierte Unternehmensansicht der Daten und wird daher als integrierte Lösung bezeichnet.
- nichtflüchtig – Sobald die Daten in das Data Warehouse integriert \ geladen sind, können sie nur noch gelesen werden. Benutzer können keine Änderungen an den Daten vornehmen, und dies macht die Daten nicht flüchtig.
- Zeitvariante – Schließlich werden Daten für lange Zeiträume in Jahren quantifiziert gespeichert und haben ein Datum und einen Zeitstempel und werden daher als „Zeitvariante“ beschrieben.
Bill Inmon sah die Notwendigkeit, Daten aus verschiedenen OLTP-Systemen in ein zentrales Repository (Data Warehouse genannt) mit einem sogenannten Top-Down-Ansatz zu integrieren. Bill Inmon sieht ein Data Warehouse im Zentrum der „Corporate Information Factory“ (CIF) vor, das einen logischen Rahmen für die Bereitstellung von Business Intelligence (BI), Business Analytics und Business Management-Funktionen bietet.
Dieses Top-Down-Design bietet eine sehr konsistente dimensionale Ansicht der Daten über Data Marts hinweg, da alle Data Marts aus dem zentralen Repository (Data Warehouse) geladen werden.Das Top-Down-Design hat sich auch als flexibel erwiesen, um Geschäftsänderungen zu unterstützen, da es die Organisation als Ganzes betrachtet, nicht jede Funktion oder jeden Geschäftsprozess der Organisation. Das Generieren eines neuen dimensionalen Data Marts anhand der im Data Warehouse gespeicherten Daten ist eine relativ einfache Aufgabe. Obwohl es einige Herausforderungen für den Top-Down-Ansatz gibt, stellt er beispielsweise ein sehr großes Projekt mit einem sehr breiten Anwendungsbereich dar, und daher sind die Vorlaufkosten für die Implementierung eines Data Warehouses unter Verwendung der Top-Down-Methodik erheblich.Darüber hinaus kann die Zeitdauer vom Projektstart bis zu dem Punkt, an dem Endbenutzer die ersten Vorteile der Lösung erleben, erheblich sein. Darüber hinaus kann die Top-Down-Methodik während der Implementierungsphase unflexibel sein und nicht auf sich ändernde Abteilungs- oder Geschäftsprozessanforderungen reagieren (ein Problem für das sich dynamisch ändernde Umfeld von heute).
Ralph Kimball – Bottom-up Data Warehouse Design Ansatz
Ralph Kimball ist ein renommierter Autor zum Thema Data Warehousing. Seine Entwurfsmethodik heißt dimensionale Modellierung oderdie Kimball-Methodik. Diese Methodik konzentriert sich auf einen Bottom-up-Ansatz, der den Wert des Data Warehouse für die Benutzer so schnell wie möglich hervorhebt. In seiner Vision ist ein Data Warehouse die Kopie der Transaktionsdaten, die speziell für analytische Abfragen und Berichte strukturiert sind, um das Entscheidungsunterstützungssystem zu unterstützen. Gemäß seiner Methodik werden Data Marts zuerst erstellt, um Berichts- und Analysefunktionen für spezifische Geschäfts- und Funktionsprozesse bereitzustellen, und später können diese Data Marts schließlich zu einem umfassenden Enterprise Data Warehouse zusammengefasst werden. Der Bottom-up-Ansatz konzentriert sich auf jeden Geschäftsprozess zu einem bestimmten Zeitpunkt, sodass der Return on Investment so schnell sein kann, wie First Data Mart erstellt wird. Wenn Sie jedoch nicht sorgfältig geplant sind, fehlt Ihnen möglicherweise das Gesamtbild des Enterprise Data Warehouse, indem einige Dimensionen fehlen oder redundante Dimensionen usw. erstellt werden. wenn Sie sich zu sehr auf einen einzelnen Geschäftsprozess konzentrieren.
Ralph Kimballs Bottom-up-Ansatz schlägt vor, eine Geschäftsmatrix zu erstellen, die alle gemeinsamen Elemente enthalten sollte (die von Data Marts verwendet werden, z. B. konforme \ gemeinsame Dimensionen, Kennzahlen usw.) für das Unternehmen als Ganzes definiert. Damit kann der Benutzer Lösungen entwerfen und entwickeln, die die Analyse über die Geschäftsprozesse hinweg für Cross Selling unterstützen. Hier können Sie mehr über die Matrix erfahren.
Für eine Person, die eine Karriere im Bereich Data Warehouse und Business Intelligence machen möchte, würde ich empfehlen, Bill Inmons Bücher zu studieren (Aufbau des Data Warehouse und DW 2.0: Die Architektur für die nächste Generation von Data Warehousing) und Ralph Kimballs Buch (Das Microsoft Data Warehouse Toolkit).
Nächste Schritte
- Überprüfenmicrosoft SQL Server Business Intelligence – Was, Warum und wie – Teil 1.
- Überprüfenmicrosoft SQL Server Business Intelligence Systemarchitektur – Teil 2.
- Schauen Sie sich alle theSQL Server Business Intelligence Tipps auf MSSQLTips.com.
Zuletzt aktualisiert: 2013-06-24
Über den Autor
Arshad Ali ist ein SQL- und BI-Entwickler, der sich auf Data Warehousing-Projekte für Microsoft konzentriert.Alle meine Tipps anzeigen
- Weitere Business Intelligence-Tipps…
