Data Warehouse – Wikipedia
![](https://upload.wikimedia.org/wikipedia/commons/thumb/d/d8/Data_Warehouse_Feeding_Data_Mart.jpg/220px-Data_Warehouse_Feeding_Data_Mart.jpg)
![](https://upload.wikimedia.org/wikipedia/commons/thumb/8/8d/Data_warehouse_architecture.jpg/330px-Data_warehouse_architecture.jpg)
Beim Rechnen a Data Warehouse ((DW oder DWH), auch bekannt als Enterprise Data Warehouse ((EDW) ist ein System zur Berichterstellung und Datenanalyse und wird als Kernkomponente von Business Intelligence angesehen.[1] DWs sind zentrale Repositorys für integrierte Daten aus einer oder mehreren unterschiedlichen Quellen. Sie speichern aktuelle und historische Daten an einem einzigen Ort[2] Diese werden zum Erstellen von Analyseberichten für Mitarbeiter im gesamten Unternehmen verwendet.[3]
Die im Lager gespeicherten Daten werden aus den Betriebssystemen (z. B. Marketing oder Vertrieb) hochgeladen. Die Daten können einen Betriebsdatenspeicher durchlaufen und eine Datenbereinigung erfordern[2] für zusätzliche Vorgänge, um die Datenqualität sicherzustellen, bevor sie in der DW für die Berichterstellung verwendet wird.
Extrahieren, Transformieren, Laden (ETL) und Extrahieren, Laden, Transformieren (ELT) sind die beiden Hauptansätze zum Aufbau eines Data Warehouse-Systems.
ETL-basiertes Data Warehousing[edit]
Das typische ETL-basierte Data Warehouse (Extract, Transform, Load)[4] Verwendet Staging-, Datenintegrations- und Zugriffsebenen, um die Schlüsselfunktionen unterzubringen. Die Staging-Schicht oder Staging-Datenbank speichert Rohdaten, die aus jedem der unterschiedlichen Quelldatensysteme extrahiert wurden. Die Integrationsschicht integriert die unterschiedlichen Datensätze, indem sie die Daten aus der Staging-Schicht transformiert, wobei diese transformierten Daten häufig in einer ODS-Datenbank (Operational Data Store) gespeichert werden. Die integrierten Daten werden dann in eine weitere Datenbank verschoben, die häufig als Data Warehouse-Datenbank bezeichnet wird. Dort werden die Daten in hierarchischen Gruppen, häufig als Dimensionen bezeichnet, sowie in Fakten und aggregierten Fakten angeordnet. Die Kombination von Fakten und Dimensionen wird manchmal als Sternschema bezeichnet. Die Zugriffsebene hilft Benutzern beim Abrufen von Daten.[5]
Die Hauptquelle der Daten wird bereinigt, transformiert, katalogisiert und für Manager und andere Geschäftsfachleute für Data Mining, Online-Analyseverarbeitung, Marktforschung und Entscheidungsunterstützung zur Verfügung gestellt.[6] Die Mittel zum Abrufen und Analysieren von Daten, zum Extrahieren, Transformieren und Laden von Daten sowie zum Verwalten des Datenwörterbuchs werden jedoch auch als wesentliche Komponenten eines Data Warehousing-Systems angesehen. Viele Verweise auf Data Warehousing verwenden diesen breiteren Kontext. Eine erweiterte Definition für Data Warehousing umfasst daher Business Intelligence-Tools, Tools zum Extrahieren, Transformieren und Laden von Daten in das Repository sowie Tools zum Verwalten und Abrufen von Metadaten.
IBM InfoSphere DataStage, Ab Initio Software, Informatica – PowerCenter sind einige der Tools, die häufig zur Implementierung von ETL-basiertem Data Warehouse verwendet werden.
ELT-basiertes Data Warehousing[edit]
![](https://upload.wikimedia.org/wikipedia/commons/thumb/2/2a/ELT_Diagram.png/244px-ELT_Diagram.png)
ELT-basiertes Data Warehousing beseitigt ein separates ETL-Tool für die Datentransformation. Stattdessen wird ein Staging-Bereich im Data Warehouse selbst verwaltet. Bei diesem Ansatz werden Daten aus heterogenen Quellsystemen extrahiert und dann direkt in das Data Warehouse geladen, bevor eine Transformation stattfindet. Alle erforderlichen Transformationen werden dann im Data Warehouse selbst abgewickelt. Schließlich werden die manipulierten Daten in Zieltabellen im selben Data Warehouse geladen.
Leistungen[edit]
Ein Data Warehouse verwaltet eine Kopie der Informationen aus den Quelltransaktionssystemen. Diese architektonische Komplexität bietet die Möglichkeit:
- Integrieren Sie Daten aus mehreren Quellen in eine einzige Datenbank und ein einziges Datenmodell. Mehr Zusammenstellung von Daten in einer einzelnen Datenbank, sodass eine einzelne Abfrage-Engine verwendet werden kann, um Daten in einem ODS darzustellen.
- Reduzieren Sie das Problem von Sperrenkonflikten auf Datenbankisolationsstufe in Transaktionsverarbeitungssystemen, die durch Versuche verursacht werden, große, lang laufende Analyseabfragen in Transaktionsverarbeitungsdatenbanken auszuführen.
- Pflegen Sie den Datenverlauf, auch wenn dies bei den Quelltransaktionssystemen nicht der Fall ist.
- Integrieren Sie Daten aus mehreren Quellsystemen und ermöglichen Sie so eine zentrale Ansicht im gesamten Unternehmen. Dieser Vorteil ist immer wertvoll, insbesondere dann, wenn die Organisation durch Fusion gewachsen ist.
- Verbessern Sie die Datenqualität, indem Sie konsistente Codes und Beschreibungen bereitstellen, fehlerhafte Daten kennzeichnen oder sogar beheben.
- Präsentieren Sie die Informationen der Organisation konsistent.
- Stellen Sie ein einziges gemeinsames Datenmodell für alle interessierenden Daten bereit, unabhängig von der Datenquelle.
- Restrukturieren Sie die Daten so, dass sie für die Geschäftsbenutzer sinnvoll sind.
- Restrukturieren Sie die Daten so, dass sie auch bei komplexen analytischen Abfragen eine hervorragende Abfrageleistung bieten, ohne die Betriebssysteme zu beeinträchtigen.
- Mehrwert für betriebliche Geschäftsanwendungen, insbesondere CRM-Systeme (Customer Relationship Management).
- Erleichtern Sie das Schreiben von Abfragen zur Entscheidungsunterstützung.
- Wiederholte Daten organisieren und eindeutig definieren
Generisch[edit]
Die Umgebung für Data Warehouses und Marts umfasst Folgendes:
- Quellsysteme, die Daten für das Lager oder den Markt bereitstellen;
- Datenintegrationstechnologie und -prozesse, die zur Vorbereitung der Daten für die Verwendung erforderlich sind;
- Verschiedene Architekturen zum Speichern von Daten im Data Warehouse oder in Data Marts eines Unternehmens;
- Verschiedene Tools und Anwendungen für die verschiedenen Benutzer;
- Metadaten, Datenqualität und Governance-Prozesse müssen vorhanden sein, um sicherzustellen, dass das Lager oder der Markt seine Zwecke erfüllt.
In Bezug auf die oben aufgeführten Quellsysteme erklärt R. Kelly Rainer: “Eine häufige Quelle für Daten in Data Warehouses sind die Betriebsdatenbanken des Unternehmens, bei denen es sich um relationale Datenbanken handeln kann.”[7]
In Bezug auf die Datenintegration erklärt Rainer: “Es ist notwendig, Daten aus Quellsystemen zu extrahieren, zu transformieren und in einen Data Mart oder ein Warehouse zu laden.”[7]
Rainer erläutert das Speichern von Daten im Data Warehouse oder in Data Marts eines Unternehmens.[7]
Metadaten sind Daten über Daten. “IT-Mitarbeiter benötigen Informationen zu Datenquellen, Datenbank-, Tabellen- und Spaltennamen, Aktualisierungsplänen und Maßnahmen zur Datennutzung.”[7]
Die erfolgreichsten Unternehmen sind heute diejenigen, die schnell und flexibel auf Marktveränderungen und -chancen reagieren können. Ein Schlüssel zu dieser Reaktion ist die effektive und effiziente Nutzung von Daten und Informationen durch Analysten und Manager.[7] Ein “Data Warehouse” ist ein Repository mit historischen Daten, das nach Unterstützung der Entscheidungsträger in der Organisation organisiert ist.[7] Sobald Daten in einem Data Mart oder Warehouse gespeichert sind, kann auf sie zugegriffen werden.
Verwandte Systeme (Data Mart, OLAPS, OLTP, Predictive Analytics)[edit]
Ein Data Mart ist eine einfache Form eines Data Warehouse, das sich auf ein einzelnes Thema (oder einen Funktionsbereich) konzentriert. Daher beziehen sie Daten aus einer begrenzten Anzahl von Quellen wie Vertrieb, Finanzen oder Marketing. Data Marts werden häufig von einer einzelnen Abteilung innerhalb einer Organisation erstellt und gesteuert. Die Quellen können interne Betriebssysteme, ein zentrales Data Warehouse oder externe Daten sein.[8] Denormalisierung ist die Norm für Datenmodellierungstechniken in diesem System. Da Data Marts im Allgemeinen nur einen Teil der in einem Data Warehouse enthaltenen Daten abdecken, sind sie häufig einfacher und schneller zu implementieren.
Attribut | Data Warehouse | Datenmarkt |
---|---|---|
Umfang der Daten | unternehmensweit | abteilungsweit |
Anzahl der Themenbereiche | mehrere | Single |
Wie schwer zu bauen | schwierig | einfach |
Wie viel Zeit braucht man, um zu bauen | Mehr | weniger |
Speichermenge | größer | begrenzt |
Zu den Arten von Data Marts gehören abhängige, unabhängige und hybride Data Marts.[clarification needed]
Die Online-Analyseverarbeitung (OLAP) zeichnet sich durch ein relativ geringes Transaktionsvolumen aus. Abfragen sind oft sehr komplex und beinhalten Aggregationen. Für OLAP-Systeme ist die Reaktionszeit ein Effektivitätsmaß. OLAP-Anwendungen werden häufig von Data Mining-Techniken verwendet. OLAP-Datenbanken speichern aggregierte historische Daten in mehrdimensionalen Schemata (normalerweise Sternschemata). OLAP-Systeme haben normalerweise eine Datenlatenz von einigen Stunden, im Gegensatz zu Data Marts, bei denen die Latenz voraussichtlich näher an einem Tag liegt. Der OLAP-Ansatz wird verwendet, um mehrdimensionale Daten aus mehreren Quellen und Perspektiven zu analysieren. Die drei grundlegenden Vorgänge in OLAP sind: Roll-up (Konsolidierung), Drilldown und Slicing & Dicing.
Die Online-Transaktionsverarbeitung (OLTP) ist durch eine große Anzahl kurzer Online-Transaktionen (INSERT, UPDATE, DELETE) gekennzeichnet. OLTP-Systeme legen Wert auf eine sehr schnelle Abfrageverarbeitung und die Aufrechterhaltung der Datenintegrität in Umgebungen mit mehreren Zugriffen. Bei OLTP-Systemen wird die Effektivität anhand der Anzahl der Transaktionen pro Sekunde gemessen. OLTP-Datenbanken enthalten detaillierte und aktuelle Daten. Das zum Speichern von Transaktionsdatenbanken verwendete Schema ist das Entitätsmodell (normalerweise 3NF).[9] Normalisierung ist die Norm für Datenmodellierungstechniken in diesem System.
Bei der prädiktiven Analyse geht es darum, verborgene Muster in den Daten mithilfe komplexer mathematischer Modelle zu finden und zu quantifizieren, mit denen zukünftige Ergebnisse vorhergesagt werden können. Die prädiktive Analyse unterscheidet sich von OLAP darin, dass sich OLAP auf die Analyse historischer Daten konzentriert und reaktiver Natur ist, während sich die prädiktive Analyse auf die Zukunft konzentriert. Diese Systeme werden auch für das Customer Relationship Management (CRM) verwendet.
Geschichte[edit]
Das Konzept des Data Warehousing reicht bis in die späten 1980er Jahre zurück[10] als die IBM-Forscher Barry Devlin und Paul Murphy das “Business Data Warehouse” entwickelten. Im Wesentlichen sollte das Data Warehousing-Konzept ein Architekturmodell für den Datenfluss von Betriebssystemen zu Entscheidungsunterstützungsumgebungen bereitstellen. Das Konzept versuchte, die verschiedenen mit diesem Fluss verbundenen Probleme anzugehen, hauptsächlich die damit verbundenen hohen Kosten. In Ermangelung einer Data Warehousing-Architektur war eine enorme Redundanz erforderlich, um Umgebungen mit mehreren Entscheidungsunterstützungen zu unterstützen. In größeren Unternehmen war es typisch, dass Umgebungen mit mehreren Entscheidungshilfen unabhängig voneinander betrieben wurden. Obwohl jede Umgebung unterschiedliche Benutzer bediente, benötigten sie häufig einen Großteil der gleichen gespeicherten Daten. Der Prozess des Sammelns, Bereinigens und Integrierens von Daten aus verschiedenen Quellen, normalerweise aus langfristig vorhandenen Betriebssystemen (normalerweise als Legacy-Systeme bezeichnet), wurde in der Regel teilweise für jede Umgebung repliziert. Darüber hinaus wurden die Betriebssysteme häufig überprüft, als neue Anforderungen an die Entscheidungsunterstützung auftauchten. Oft erforderten neue Anforderungen das Sammeln, Bereinigen und Integrieren neuer Daten von “Data Marts”, die auf den sofortigen Zugriff durch Benutzer zugeschnitten waren.
Wichtige Entwicklungen in den ersten Jahren des Data Warehousing:
- 1960er Jahre – General Mills und das Dartmouth College entwickeln in einem gemeinsamen Forschungsprojekt die Begriffe Maße und Fakten.[11]
- 1970er Jahre – ACNielsen und IRI bieten dimensionale Datenmärkte für den Einzelhandelsverkauf an.[11]
- 1970er Jahre – Bill Inmon beginnt, den Begriff Data Warehouse zu definieren und zu diskutieren.[citation needed]
- 1975 – Sperry Univac führt MAPPER (MAintain, Prepare and Produce Executive Reports) ein, ein Datenbankverwaltungs- und Berichtssystem, das das weltweit erste 4GL enthält. Es ist die erste Plattform für den Bau von Informationszentren (ein Vorläufer der modernen Data Warehouse-Technologie).
- 1983 – Teradata stellt den DBC / 1012-Datenbankcomputer vor, der speziell für die Entscheidungsunterstützung entwickelt wurde.[12]
- 1984 – Metaphor Computer Systems, gegründet von David Liddle und Don Massaro, veröffentlicht ein Hardware- / Softwarepaket und eine grafische Benutzeroberfläche für Geschäftsanwender, um ein Datenbankverwaltungs- und Analysesystem zu erstellen.
- 1985 – Die Sperry Corporation veröffentlicht einen Artikel (Martyn Jones und Philip Newman) über Informationszentren, in dem sie den Begriff MAPPER Data Warehouse im Kontext von Informationszentren einführen.
- 1988 – Barry Devlin und Paul Murphy veröffentlichen den Artikel “Eine Architektur für ein Geschäfts- und Informationssystem”, in dem sie den Begriff “Business Data Warehouse” einführen.[13]
- 1990 – Red Brick Systems, gegründet von Ralph Kimball, führt Red Brick Warehouse ein, ein Datenbankverwaltungssystem speziell für Data Warehousing.
- 1991 – Prism Solutions, gegründet von Bill Inmon, führt Prism Warehouse Manager ein, eine Software zur Entwicklung eines Data Warehouse.
- 1992 – Bill Inmon veröffentlicht das Buch Erstellen des Data Warehouse.[14]
- 1995 – Das Data Warehousing Institute, eine gemeinnützige Organisation, die Data Warehousing fördert, wird gegründet.
- 1996 – Ralph Kimball veröffentlicht das Buch Das Data Warehouse Toolkit.[15]
- 2000 – Dan Linstedt veröffentlicht öffentlich die Data Vault-Modellierung, die 1990 als Alternative zu Inmon und Kimball konzipiert wurde, um eine langfristige historische Speicherung von Daten aus mehreren Betriebssystemen zu ermöglichen, wobei der Schwerpunkt auf Rückverfolgung, Prüfung und Widerstandsfähigkeit gegenüber Änderungen liegt des Quelldatenmodells.
- 2008 – Bill Inmon veröffentlicht zusammen mit Derek Strauss und Genia Neushloss “DW 2.0: Die Architektur für die nächste Generation von Data Warehousing”, in dem er seinen Top-Down-Ansatz für Data Warehousing erläutert und den Begriff Data Warehousing 2.0 prägt.
- 2012 – Bill Inmon entwickelt und macht öffentliche Technologie als “Textdisambiguierung” bekannt. Die Textdisambiguierung wendet den Kontext auf den Rohtext an und formatiert den Rohtext und den Kontext in ein Standarddatenbankformat um. Sobald der Rohtext einer Textdisambiguierung unterzogen wurde, kann er mit der Standard-Business-Intelligence-Technologie einfach und effizient abgerufen und analysiert werden. Die Textdisambiguierung wird durch die Ausführung der Text-ETL erreicht. Die Disambiguierung von Texten ist überall dort nützlich, wo Rohtext gefunden wird, z. B. in Dokumenten, Hadoop, E-Mail usw.
Informationsspeicherung[edit]
Fakten[edit]
Eine Tatsache ist ein Wert oder eine Messung, die eine Tatsache über die verwaltete Entität oder das verwaltete System darstellt.
Die vom berichtenden Unternehmen gemeldeten Tatsachen gelten als Rohdaten. Wenn beispielsweise in einem Mobiltelefonsystem eine BTS (Basis-Transceiver-Station) 1.000 Anforderungen für die Zuweisung von Verkehrskanälen empfängt, 820 zuweist und die verbleibenden ablehnt, werden drei gemeldet Fakten oder Messungen an ein Managementsystem:
tch_req_total = 1000
tch_req_success = 820
tch_req_fail = 180
Fakten auf Rohebene werden in verschiedenen Dimensionen auf höheren Ebenen zusammengefasst, um mehr Service- oder geschäftsrelevante Informationen daraus zu extrahieren. Diese werden als Aggregate oder Zusammenfassungen oder aggregierte Fakten bezeichnet.
Wenn beispielsweise drei BTS in einer Stadt vorhanden sind, können die oben genannten Fakten in der Netzwerkdimension von der BTS auf die Stadtebene aggregiert werden. Zum Beispiel:
tch_req_success_city = tch_req_success_bts1 + tch_req_success_bts2 + tch_req_success_bts3
avg_tch_req_success_city = (tch_req_success_bts1 + tch_req_success_bts2 + tch_req_success_bts3) / 3
Dimensional versus normalisierter Ansatz zur Speicherung von Daten[edit]
Es gibt drei oder mehr führende Ansätze zum Speichern von Daten in einem Data Warehouse – die wichtigsten Ansätze sind der dimensionale Ansatz und der normalisierte Ansatz.
Der dimensionale Ansatz bezieht sich auf den Ansatz von Ralph Kimball, bei dem angegeben wird, dass das Data Warehouse unter Verwendung eines Dimensionsmodells / Sternschemas modelliert werden sollte. Der normalisierte Ansatz, auch 3NF-Modell (Third Normal Form) genannt, bezieht sich auf den Ansatz von Bill Inmon, bei dem angegeben wird, dass das Data Warehouse unter Verwendung eines ER-Modells / normalisierten Modells modelliert werden sollte.[16]
Dimensionaler Ansatz[edit]
Bei einem dimensionalen Ansatz werden Transaktionsdaten in “Fakten” unterteilt, bei denen es sich im Allgemeinen um numerische Transaktionsdaten handelt, und in “Dimensionen”, bei denen es sich um Referenzinformationen handelt, die den Fakten einen Kontext geben. Beispielsweise kann eine Verkaufstransaktion in Fakten wie die Anzahl der bestellten Produkte und den für die Produkte gezahlten Gesamtpreis sowie in Dimensionen wie Bestelldatum, Kundenname, Produktnummer, Bestellversand und Rechnungsempfänger unterteilt werden Standorte und Verkäufer, die für den Eingang der Bestellung verantwortlich sind.
Ein wesentlicher Vorteil eines dimensionalen Ansatzes besteht darin, dass das Data Warehouse für den Benutzer leichter zu verstehen und zu verwenden ist. Auch das Abrufen von Daten aus dem Data Warehouse erfolgt in der Regel sehr schnell.[15] Dimensionsstrukturen sind für Geschäftsanwender leicht zu verstehen, da die Struktur in Messungen / Fakten und Kontext / Dimensionen unterteilt ist. Fakten beziehen sich auf die Geschäftsprozesse und das Betriebssystem des Unternehmens, während die sie umgebenden Dimensionen einen Kontext über die Messung enthalten (Kimball, Ralph 2008). Ein weiterer Vorteil des dimensionalen Modells besteht darin, dass nicht jedes Mal eine relationale Datenbank erforderlich ist. Daher ist diese Art der Modellierungstechnik für Endbenutzerabfragen im Data Warehouse sehr nützlich.
Das Modell von Fakten und Dimensionen kann auch als Datenwürfel verstanden werden.[17] Wenn die Dimensionen die kategorialen Koordinaten in einem mehrdimensionalen Würfel sind, ist die Tatsache ein Wert, der den Koordinaten entspricht.
Die Hauptnachteile des dimensionalen Ansatzes sind die folgenden:
- Um die Integrität von Fakten und Dimensionen zu gewährleisten, ist das Laden des Data Warehouse mit Daten aus verschiedenen Betriebssystemen kompliziert.
- Es ist schwierig, die Data-Warehouse-Struktur zu ändern, wenn die Organisation, die den dimensionalen Ansatz anwendet, die Art und Weise ändert, in der sie Geschäfte tätigt.
Normalisierter Ansatz[edit]
Bei dem normalisierten Ansatz werden die Daten im Data Warehouse nach bis zu einem gewissen Grad nach Regeln zur Datenbanknormalisierung gespeichert. Tabellen sind nach gruppiert Themenbereiche die allgemeine Datenkategorien widerspiegeln (z. B. Daten zu Kunden, Produkten, Finanzen usw.). Die normalisierte Struktur unterteilt Daten in Entitäten, wodurch mehrere Tabellen in einer relationalen Datenbank erstellt werden. Bei der Anwendung in großen Unternehmen entstehen Dutzende von Tabellen, die durch ein Netz von Verknüpfungen miteinander verbunden sind. Darüber hinaus wird jede der erstellten Entitäten bei der Implementierung der Datenbank in separate physische Tabellen konvertiert (Kimball, Ralph 2008). Der Hauptvorteil dieses Ansatzes besteht darin, dass das Hinzufügen von Informationen zur Datenbank einfach ist. Einige Nachteile dieses Ansatzes bestehen darin, dass es für Benutzer aufgrund der Anzahl der beteiligten Tabellen schwierig sein kann, Daten aus verschiedenen Quellen zu aussagekräftigen Informationen zusammenzufügen und auf die Informationen zuzugreifen, ohne die Datenquellen und die Datenstruktur genau zu verstehen des Data Warehouse.
Sowohl normalisierte als auch dimensionale Modelle können in Entity-Relationship-Diagrammen dargestellt werden, da beide verknüpfte relationale Tabellen enthalten. Der Unterschied zwischen den beiden Modellen ist der Normalisierungsgrad (auch als Normalformen bezeichnet). Diese Ansätze schließen sich nicht gegenseitig aus, und es gibt andere Ansätze. Bei dimensionalen Ansätzen können Daten bis zu einem gewissen Grad normalisiert werden (Kimball, Ralph 2008).
Im Informationsgetriebenes Geschäft,[18] Robert Hillard schlägt einen Ansatz zum Vergleich der beiden Ansätze vor, der auf dem Informationsbedarf des Geschäftsproblems basiert. Die Technik zeigt, dass normalisierte Modelle weitaus mehr Informationen enthalten als ihre Dimensionsäquivalente (selbst wenn in beiden Modellen dieselben Felder verwendet werden), diese zusätzlichen Informationen gehen jedoch zu Lasten der Benutzerfreundlichkeit. Die Technik misst die Informationsmenge in Bezug auf die Informationsentropie und die Verwendbarkeit in Bezug auf das Datentransformationsmaß für kleine Welten.[19]
Entwurfsmethoden[edit]
Bottom-up-Design[edit]
In dem Prost Ansatz werden zunächst Data Marts erstellt, um Berichts- und Analysefunktionen für bestimmte Geschäftsprozesse bereitzustellen. Diese Data Marts können dann integriert werden, um ein umfassendes Data Warehouse zu erstellen. Die Data Warehouse-Busarchitektur ist in erster Linie eine Implementierung von “the bus”, einer Sammlung von konformen Dimensionen und konformen Fakten, die Dimensionen sind, die (auf eine bestimmte Weise) zwischen Fakten in zwei oder mehr Data Marts geteilt werden.[20]
Top-Down-Design[edit]
Das von oben nach unten Der Ansatz basiert auf einem normalisierten Unternehmensdatenmodell. “Atomic” -Daten, dh Daten mit größter Detailgenauigkeit, werden im Data Warehouse gespeichert. Aus dem Data Warehouse werden dimensionale Data Marts erstellt, die Daten enthalten, die für bestimmte Geschäftsprozesse oder bestimmte Abteilungen benötigt werden.[21]
Hybrid-Design[edit]
Data Warehouses (DW) ähneln häufig der Hub- und Speichenarchitektur. Legacy-Systeme, die das Lager versorgen, umfassen häufig das Kundenbeziehungsmanagement und die Planung von Unternehmensressourcen, wodurch große Datenmengen generiert werden. Um diese verschiedenen Datenmodelle zu konsolidieren und den Ladevorgang für die Extrakttransformation zu vereinfachen, verwenden Data Warehouses häufig einen Betriebsdatenspeicher, dessen Informationen in die tatsächliche DW analysiert werden. Um die Datenredundanz zu verringern, speichern größere Systeme die Daten häufig normalisiert. Data Marts für bestimmte Berichte können dann über dem Data Warehouse erstellt werden.
Eine hybride DW-Datenbank wird in der dritten Normalform gehalten, um Datenredundanz zu beseitigen. Eine normale relationale Datenbank ist jedoch für Business Intelligence-Berichte, bei denen die dimensionale Modellierung vorherrscht, nicht effizient. Kleine Data Marts können Daten aus dem konsolidierten Lager einkaufen und die gefilterten, spezifischen Daten für die erforderlichen Faktentabellen und Abmessungen verwenden. Der DW bietet eine einzige Informationsquelle, aus der die Data Marts lesen können, und bietet eine breite Palette von Geschäftsinformationen. Durch die Hybridarchitektur kann ein DW durch ein Stammdatenverwaltungs-Repository ersetzt werden, in dem sich betriebliche (nicht statische) Informationen befinden können.
Die Modellierungskomponenten für Datentresore folgen der Hub- und Speichenarchitektur. Dieser Modellierungsstil ist ein hybrides Design, das aus den Best Practices sowohl der dritten Normalform als auch des Sternschemas besteht. Das Datentresormodell ist keine echte dritte Normalform und verstößt gegen einige seiner Regeln. Es handelt sich jedoch um eine Top-Down-Architektur mit einem Bottom-Up-Design. Das Datentresormodell ist ausschließlich auf ein Data Warehouse ausgerichtet. Es ist nicht darauf ausgerichtet, für Endbenutzer zugänglich zu sein, was beim Erstellen weiterhin die Verwendung eines Data Mart- oder Star-Schema-basierten Release-Bereichs für geschäftliche Zwecke erfordert.
Data Warehouse-Merkmale[edit]
Es gibt grundlegende Funktionen, die die Daten im Data Warehouse definieren, darunter Themenorientierung, Datenintegration, Zeitvariante, nichtflüchtige Daten und Datengranularität.
Fachorientiert[edit]
Im Gegensatz zu den Betriebssystemen drehen sich die Daten im Data Warehouse um Themen des Unternehmens. Die Themenorientierung ist nicht (Datenbanknormalisierung). Die Themenorientierung kann für die Entscheidungsfindung sehr nützlich sein. Das Sammeln der erforderlichen Objekte wird als themenorientiert bezeichnet.
Integriert[edit]
Die im Data Warehouse gefundenen Daten werden integriert. Da es von mehreren Betriebssystemen stammt, müssen alle Inkonsistenzen beseitigt werden. Zu den Konsistenzen gehören Namenskonventionen, Messung von Variablen, Codierungsstrukturen, physikalische Attribute von Daten usw.
Zeitunterschied[edit]
Während Betriebssysteme aktuelle Werte widerspiegeln, da sie den täglichen Betrieb unterstützen, stellen Data Warehouse-Daten Daten über einen langen Zeithorizont (bis zu 10 Jahre) dar, dh, sie speichern historische Daten. Es ist hauptsächlich für Data Mining und Prognosen gedacht. Wenn ein Benutzer nach einem Kaufmuster eines bestimmten Kunden sucht, muss er Daten zu aktuellen und vergangenen Einkäufen anzeigen.[22]
Nicht flüchtig[edit]
Die Daten im Data Warehouse sind schreibgeschützt. Dies bedeutet, dass sie nicht aktualisiert, erstellt oder gelöscht werden können (es sei denn, es besteht eine gesetzliche oder gesetzliche Verpflichtung dazu).[23]
Data Warehouse-Optionen[edit]
Anhäufung[edit]
Im Data Warehouse-Prozess können Daten in Data Marts auf verschiedenen Abstraktionsebenen aggregiert werden. Der Benutzer kann beginnen, die gesamten Verkaufseinheiten eines Produkts in einer gesamten Region zu betrachten. Dann betrachtet der Benutzer die Zustände in dieser Region. Schließlich können sie die einzelnen Geschäfte in einem bestimmten Zustand untersuchen. Daher beginnt die Analyse normalerweise auf einer höheren Ebene und führt zu niedrigeren Detailebenen.[22]
Data Warehouse-Architektur[edit]
Die verschiedenen Methoden zum Erstellen / Organisieren eines von einer Organisation angegebenen Data Warehouse sind zahlreich. Die verwendete Hardware, die erstellte Software und die Datenressourcen, die speziell für die korrekte Funktionalität eines Data Warehouse erforderlich sind, sind die Hauptkomponenten der Data Warehouse-Architektur. Alle Data Warehouses haben mehrere Phasen, in denen die Anforderungen der Organisation geändert und verfeinert werden.[24]
Versus Betriebssystem[edit]
Betriebssysteme sind für die Wahrung der Datenintegrität und die Geschwindigkeit der Aufzeichnung von Geschäftstransaktionen mithilfe der Datenbanknormalisierung und eines Entity-Relationship-Modells optimiert. Betriebssystementwickler befolgen im Allgemeinen die 12 Regeln von Codd zur Datenbanknormalisierung, um die Datenintegrität sicherzustellen. Vollständig normalisierte Datenbankdesigns (dh solche, die alle Codd-Regeln erfüllen) führen häufig dazu, dass Informationen aus einem Geschäftsvorgang in Dutzenden bis Hunderten von Tabellen gespeichert werden. Relationale Datenbanken verwalten die Beziehungen zwischen diesen Tabellen effizient. Die Datenbanken weisen eine sehr schnelle Einfüge- / Aktualisierungsleistung auf, da bei jeder Verarbeitung einer Transaktion nur eine geringe Datenmenge in diesen Tabellen betroffen ist. Um die Leistung zu verbessern, werden ältere Daten normalerweise regelmäßig aus den Betriebssystemen gelöscht.
Data Warehouses sind für analytische Zugriffsmuster optimiert. Analytische Zugriffsmuster umfassen im Allgemeinen die Auswahl bestimmter Felder und selten oder nie select *
Hiermit werden alle Felder / Spalten ausgewählt, wie dies in Betriebsdatenbanken üblich ist. Aufgrund dieser Unterschiede in den Zugriffsmustern profitieren Betriebsdatenbanken (lose OLTP) von der Verwendung eines zeilenorientierten DBMS, während Analysedatenbanken (lose OLAP) von der Verwendung eines spaltenorientierten DBMS profitieren. Im Gegensatz zu Betriebssystemen, die eine Momentaufnahme des Geschäfts verwalten, führen Data Warehouses im Allgemeinen eine unendliche Historie, die durch ETL-Prozesse implementiert wird, die regelmäßig Daten von den Betriebssystemen in das Data Warehouse migrieren.
Entwicklung der Organisationsnutzung[edit]
Diese Begriffe beziehen sich auf den Grad der Komplexität eines Data Warehouse:
- Offline-Data-Warehouse
- Data Warehouses in dieser Entwicklungsphase werden in regelmäßigen Abständen (normalerweise täglich, wöchentlich oder monatlich) von den Betriebssystemen aus aktualisiert und die Daten in einer integrierten berichtsorientierten Datenbank gespeichert.
- Offline-Data-Warehouse
- In dieser Phase werden Data Warehouses regelmäßig anhand der Daten in den Betriebssystemen aktualisiert, und die Data Warehouse-Daten werden in einer Datenstruktur gespeichert, die die Berichterstellung erleichtert.
- Pünktliches Data Warehouse
- Online Integrated Data Warehousing stellt die Echtzeitdaten der Data Warehouses-Phase im Warehouse dar, die für jede an den Quelldaten durchgeführte Transaktion aktualisiert werden
- Integriertes Data Warehouse
- Diese Data Warehouses stellen Daten aus verschiedenen Geschäftsbereichen zusammen, sodass Benutzer die benötigten Informationen systemübergreifend nachschlagen können.[25]
Verweise[edit]
- ^ Dedić, Nedim; Stanier, Clare (2016). Hammoudi, Slimane; Maciaszek, Leszek; Missikoff, Michele M. Missikoff; Lager, Olivier; Cordeiro, José (Hrsg.). Eine Bewertung der Herausforderungen der Mehrsprachigkeit in der Data Warehouse-Entwicklung. Internationale Konferenz über Unternehmensinformationssysteme, 25. bis 28. April 2016, Rom, Italien (PDF). Vorträge der 18. Internationalen Konferenz über Unternehmensinformationssysteme (ICEIS 2016). 1. SciTePress. S. 196–206. doi:10.5220 / 0005858401960206. ISBN 978-989-758-187-8.
- ^ ein b “9 Gründe, warum Data Warehouse-Projekte fehlschlagen”. blog.rjmetrics.com. Abgerufen 2017-04-30.
- ^ “Erkundung von Data Warehouses und Datenqualität”. spotlessdata.com. Archiviert von das Original am 26.07.2018. Abgerufen 2017-04-30.
- ^ “Was ist Big Data?”. spotlessdata.com. Archiviert von das Original am 2017-02-17. Abgerufen 2017-04-30.
- ^ Patil, Preeti S.; Srikantha Rao; Suryakant B. Patil (2011). “Optimierung des Data Warehousing-Systems: Vereinfachung der Berichterstellung und Analyse”. IJCA Proceedings on International Conference und Workshop zu neuen Trends in der Technologie (ICWET). Gründung der Informatik. 9 (6): 33–37.
- ^ Marakas & O’Brien 2009
- ^ ein b c d e f Rainer, R. Kelly; Cegielski, Casey G. (2012-05-01). Einführung in Informationssysteme: Aktivieren und Transformieren von Unternehmen, 4. Ausgabe (Kindle ed.). Wiley. pp. 127128, 130, 131, 133. ISBN 978-1118129401.
- ^ “Data Mart-Konzepte”. Orakel. 2007.
- ^ “OLTP vs. OLAP”. Datawarehouse4u.Info. 2009.
Wir können IT-Systeme in transaktionale (OLTP) und analytische (OLAP) unterteilen. Im Allgemeinen können wir davon ausgehen, dass OLTP-Systeme Data Warehouses mit Quelldaten versorgen, während OLAP-Systeme bei deren Analyse helfen.
- ^ “Die Geschichte bisher”. 15.04.2002. Archiviert von das Original am 08.07.2008. Abgerufen 2008-09-21.
- ^ ein b Kimball 2013, pg. 15
- ^ Paul Gillin (20. Februar 1984). “Wird Teradata einen Markt wiederbeleben?”. Computerwelt. S. 43, 48. Abgerufen 2017-03-13.
- ^ Devlin, BA; Murphy, PT (1988). “Eine Architektur für ein Geschäfts- und Informationssystem”. IBM Systems Journal. 27: 60–80. doi:10.1147 / sj.271.0060.
- ^ Inmon, Bill (1992). Erstellen des Data Warehouse. Wiley. ISBN 0-471-56960-7.
- ^ ein b Kimball, Ralph (2011). Das Data Warehouse Toolkit. Wiley. p. 237. ISBN 978-0-470-14977-5.
- ^ Golfarelli, Matteo; Maio, Dario; Rizzi, Stefano (01.06.1998). “Das dimensionale Faktenmodell: ein konzeptionelles Modell für Data Warehouses”. Internationale Zeitschrift für kooperative Informationssysteme. 07 (02n03): 215–247. doi:10.1142 / S0218843098000118. ISSN 0218-8430.
- ^ http://www2.cs.uregina.ca/~dbd/cs831/notes/dcubes/dcubes.html
- ^ Hillard, Robert (2010). Informationsgetriebenes Geschäft. Wiley. ISBN 978-0-470-62577-4.
- ^ “Informationstheorie & Business Intelligence-Strategie – Datenumwandlungsmaßnahme für kleine Welten – MIKE2.0, die Open-Source-Methode für die Informationsentwicklung”. Mike2.openmethodology.org. Abgerufen 2013-06-14.
- ^ “Die Bottom-Up-Fehlbezeichnung – DecisionWorks Consulting”. DecisionWorks Consulting. Abgerufen 2016-03-06.
- ^ Gartner, Of Data Warehouses, Betriebsdatenspeicher, Data Marts und Data Outhouses, Dezember 2005
- ^ ein b Paulraj., Ponniah (2010). Data Warehousing-Grundlagen für IT-Experten. Ponniah, Paulraj. (2. Aufl.). Hoboken, NJ: John Wiley & Sons. ISBN 9780470462072. OCLC 662453070.
- ^ H., Inmon, William (2005). Aufbau des Data Warehouse (4. Aufl.). Indianapolis, IN: Wiley Pub. ISBN 9780764599446. OCLC 61762085.
- ^ Gupta, Satinder Bal; Mittal, Aditya (2009). Einführung in das Datenbankverwaltungssystem. Laxmi-Veröffentlichungen. ISBN 9788131807248.
- ^ “Data Warehouse”.
Weiterführende Literatur[edit]
- Davenport, Thomas H. und Harris, Jeanne G. Wettbewerb um Analytik: Die neue Wissenschaft des Gewinnens (2007) Harvard Business School Press. ISBN 978-1-4221-0332-6
- Ganczarski, Joe. Data Warehouse-Implementierungen: Studie zu kritischen Implementierungsfaktoren (2009) VDM Verlag ISBN 3-639-18589-7 ISBN 978-3-639-18589-8
- Kimball, Ralph und Ross, Margy. Das Data Warehouse Toolkit Dritte Ausgabe (2013) Wiley, ISBN 978-1-118-53080-1
- Linstedt, Graziano, Hultgren. Das Geschäft mit der Modellierung von Datentresoren Zweite Ausgabe (2010) Dan linstedt, ISBN 978-1-4357-1914-9
- William Inmon. Erstellen des Data Warehouse (2005) John Wiley and Sons, ISBN 978-81-265-0645-3
Recent Comments