Real-Time Data Warehousing

Größe: px
Ab Seite anzeigen:

Download "Real-Time Data Warehousing"

Transkript

1 Real-Time Data Warehousing Möglichkeiten und Grenzen echtzeitnaher Analysesysteme von Lisa Wenige Betreuerin: Dipl-Math. Katharina Büchse Seminar Data Warehousing und Analytische Datenbanken Friedrich-Schiller-Universität Jena

2 Inhaltsverzeichnis 1 Einführung Real-time Data Warehouses: eine Begriffsbestimmung Klassifikation der Latenzzeiten Organisatorische Latenz I Infrastrukturlatenz Organisatorische Latenz II Beschleunigungspotentiale: Möglichkeiten und Grenzen Beschleunigungspotentiale im ETL-Bereich Near-Realtime-Ansatz Direct-Data- oder Trickle-Feed-Ansatz Partitionsbasierter Ansatz Cachebasierter Ansatz Enterprise Application Integration Beschleunigungpotentiale im Analysebereich Materialisierte Sichten und Präaggregation Rechtebeschränkungen Priorisiertes Scheduling Just-in-Time-Integration Die Integration von OLTP und OLAP Fazit

3 1 Einführung Üblicherweise sind Transaktions- und Analysedatenbanken aufgrund ihrer unterschiedlichen Zielstellungen und Einsatzgebiete voneinander getrennt. In klassischen Systemen des Online Transactional Processing (OLTP) werden flüchtige, sich schnell verändernde Daten ständig neu eingepflegt, angepasst und gelöscht. Die anfallenden Geschäftsprozessinformationen sollen dabei immer schreibbar sein und den aktuellen Systemzustand widerspiegeln. Währenddessen arbeiten Datenbanken, die auf die Prinzipien des Online Analytical Processing (OLAP) ausgerichtet sind, mit historisierten Informationen. Bei ihnen geht es v. a. darum, die Transaktionsdaten so zu analysieren, dass adäquate Managemententscheidungen getroffen werden können. Klassische Data-Warehouse-Systeme weisen daher eine eher statische Struktur auf. Diese eignet sich zwar gut für lesende Zugriffe, sieht aber keine kontinuierliche Datenintegration vor. Aktualisierungen werden in diesem Zusammenhang nur periodisch vorgenommen [SaBe08, S. 49]. Allerdings ist mit der sich immer schneller vollziehenden Informationsvermehrung und den kürzeren Produktlebens- und Innovationszyklen der Wirtschaftswelt die Datenaktualität zu einem wettbewerbskritischen Faktor geworden. Unternehmen aus dem Bereich E-Commerce, der Luftfahrt- oder der Finanzindustrie müssen mit einer gestiegenen Umweltdynamik umgehen, schnell Trends erkennen und auf kurzfristige Ereignisse unmittelbar und adäquat reagieren [BaGü09, S. 101]. In diesem Zusammenhang können sich nur solche Firmen gegen die Konkurrenz behaupten, die ihre Entscheidungen mit Hilfe einer Datenbasis treffen, die sich auf dem neuesten Stand befindet. Dabei wird davon ausgegangen, dass Maßnahmen umso wirkungsvoller sind, je schneller sie ergriffen werden [Shel06, S. 426]. Aus diesem Grund entwickelt man seit einiger Zeit Strategien und Technologien, die die Zeitverzögerungen in den einzelnen Data-Warehousing-Phasen reduzieren sollen. Solche Lösungen werden im Umfeld der Analytischen Datenbanken auch als Real-time Data Warehouses bezeichnet. In der vorliegenden Arbeit soll es darum gehen, die Konzepte von Echtzeit- OLAP-Systemen vorzustellen und kritisch zu betrachten. Dafür wird in Abschnitt 2 zunächst eine genaue Begriffsbestimmung vorgenommen. Abschnitt 3 wird sich anschließend damit auseinandersetzen, welche Latenzzeiten und Beschleunigungspotentiale es bei der Aktualisierung von OLAP-Datenbanken gibt. Im Anschluss daran sollen mögliche Maßnahmen und Echtzeit-Architekturen genauer vorgestellt werden (Abschnitt 4). In Abschnitt 5 erfolgt dann die Vorstellung eines Ansatzes, bei dem OLTP- und OLAP-Datenbanken in einem integrierten System zusammengeführt werden. Die Arbeit endet mit einem Fazit, welches die in den einzelnen Abschnitten gewonnenen Erkenntnisse zusammenfasst und abschließend bewertet. 3

4 2 Real-time Data Warehouses: eine Begriffsbestimmung Um die Echtzeitdimension im Umfeld der Analytischen Datenbanken genauer zu charakterisieren, existieren zahlreiche Definitionen. So schreiben z. B. Lehner und Thiele: The real-time aspect in the context of data warehouses describes a new processing model where every change is automatically captured and pushed into the data warehouse. [LeTh09, S. 1] Diese Begriffsbestimmung verdeutlicht, dass das primäre Ziel eines Echtzeit- Data-Warehouses die Datenaktualität ist. Jede Änderung, die sich in den Transaktionssystemen vollzieht, soll ohne Verzögerung an die analytischen Komponenten weitergeleitet werden. Allerdings befindet sich in der obenstehenden Definition bereits ein Vorgriff auf die mögliche Implementierung eines solchen Echtzeit- Data-Warehouses. Wenn Lehner und Thiele schreiben, dass neue Transaktionsinformationen automatisch an die Zielsysteme im Push-Modus propagiert werden, dann wird der Bezugsrahmen der Definition bereits sehr eingeschränkt. Tatsächlich gibt es verschiedene Implementierungsmöglichkeiten und Architekturen, mit denen ein Echzeit-Data-Warehouse realisiert werden kann (s. Abschnitt 4). Aus diesen Gründen ist die folgende von Thiele gewählte Definition geeigneter: Der Begriff Echtzeit charakterisiert die Fähigkeit eines Data Warehouses [...] Änderungen in der Realwelt bzw. der Diskurswelt zeitnah im Data Warehouse abzubilden. [Thie10, S. 50] Diese Erklärung beschreibt ein Data Warehouse zum einen unabhängig von der jeweiligen Realisierung und relativiert zum anderen den Echtzeitbegriff. Tatsächlich wird es bei der Trennung von OLTP- und OLAP-Datenbanken kaum möglich sein, die analytischen Systeme mit den Transaktionsdaten ohne jegliche Zeitverzögerung zu versorgen. Die Bezeichnung zeitnah verdeutlicht dabei, dass Änderungen so schnell wie möglich propagiert werden sollten. Nicht ohne Grund gibt es daher im Englischen auch den Begriff des Near Real-time Data Warehouse [JöDe10]. Daneben existieren Bezeichnungen, wie Right-time oder On-time, die zeigen, dass die Forderung nach Datenaktualität nicht Selbstzweck sein sollte [ThPL08] [Baer04]. Vielmehr ist es wichtig, dass die Bereitstellung hochaktueller Daten bedarfsorientiert erfolgt. Es muss demnach eine auf die entsprechenden Anwenderbedürfnisse gerichtete Datenauswahl getroffen werden. Für diese Informationen erfolgt dann die Bereitstellung mit möglichst geringen Verzögerungsraten [BaGü09, S. 101] [ThPL08, S. 456]. Der Begriff der Datenaktualität wird in diesem Zusammenhang dabei häufig synonym mit dem englischen Ausdruck Data Freshness verwendet [LeTh09]. In Abgrenzung zu den bereits vorgestellten Konzepten gibt es außerdem das Konzept des Active Data Warehouse [MNSV09]. In einer solchen Datenbank werden auf Grundlage hochaktueller Daten automatisch Entscheidungen getroffen und im Falle der Über- oder Unterschreitung bestimmter Grenzwerte Maßnahmen ausgelöst. So ist es z. B. vorstellbar, dass in einem Multimedia-Online-Shop bei 4

5 Nichterreichen einer vorgegebenen Verkaufszahl in einem bestimmten Zeitintervall automatisiert eine Preisreduktion erfolgt. Eine aktuelle Datenbasis, die mit Real-time-Technologien geschaffen wurde, ist für dieses Vorgehen eine unmittelbare Voraussetzung. In dieser Arbeit soll es allerdings vorrangig um die Betrachtung von Methoden zur Realisierung eines Echtzeit-Data-Warehouses gehen. 3 Klassifikation der Latenzzeiten Im Zuge der Phasen des Data Warehousing-Prozesses können zahlreiche Verzögerungen auftreten. Im Folgenden werden unter Zuhilfenahme der von Shelp beschriebenen und in Abb. 1 dargestellten Einteilung die verschiedenen Latenzzeiten vorgestellt. Abbildung 1. Verzögerungspotentiale (in Anlehnung an [Shel06, S. 426]) 3.1 Organisatorische Latenz I Diese Art der Zeitverschiebung setzt sich aus der Wahrnehmungslatenz und der Verzögerung bei der Informationserfassung zusammen. Die Wahrnehmungslatenz beschreibt die Zeitdifferenz vom Auftreten eines Ereignisses in der Realwelt bis zu dem Zeitpunkt, an dem ein Verantwortlicher realisiert, dass eine Veränderung eingetreten ist. In einem Reisebüro, in dem der zuständige Mitarbeiter per eine Aufforderung zur Buchung einer Reise erhält, ist diese Verzögerung 5

6 relativ groß. In einem Multimediahandel, in dem ein Kunde selbst die Bestellung tätigt, ist sie hingegen geringer. Auch bei der Erfassung der Veränderungen im jeweiligen Transaktionsverwaltungssystem können Latenzzeiten auftreten. So dauert es z. B. eine Weile, bis alle zu einer Reisebuchung gehörenden Informationen in das Datenbankmanagementsystem übertragen wurden. 3.2 Infrastrukturlatenz Die Infrastrukturlatenz setzt sich aus der Ladelatenz und der Analyselatenz zusammen. Sie charakterisiert die Zeitverschiebungen, die bei der Übertragung und Analyse der Daten im eigentlichen Data Warehouse auftreten. Diese Formen der Verzögerung müssen daher, im Gegensatz zur Organisatorischen Latenz I, v. a. auf der technischen Ebene gelöst werden. Im Fall der Ladelatenz geht es dabei darum, die Daten im Zuge des Extract, Transfer, Load -Prozesses (ETL) schneller bereitstellen zu können. Ein Multimediaversandhandel muss in dieser Phase z. B. die Informationen aus den Transaktionssystemen seiner verteilten Onlineshops und aus den Datenbankmanagementsystemen seiner Einzelhandelszweigstellen zusammenführen. Während der Datenbereinigung und -integration können in diesem Zusammenhang erhebliche Zeitverzögerungen auftreten, da die heterogenen Daten an ein einheitliches Schema angepasst und in die bestehenden Datenstrukturen eingefügt werden müssen. Im Gegensatz dazu, geht es bei der Analyselatenz um die Zeit, die ab der Bereitstellung im Data Warehouse verstreicht, bis ein Auswertungsergebnis verfügbar ist. Fragen der Datenhaltung und der Anfrageoptimierung spielen in diesem Bereich eine entscheidende Rolle. Mechanismen und Architekturlösungen zur Vemeidung von Infrastrukturlatenzen werden in Abschnitt 4 genauer behandelt. 3.3 Organisatorische Latenz II In diesem Komplex werden alle Latenzzeiten zusammengefasst, die von der Bereitstellung eines Analyseergebnisses vergehen, bis eine konkrete Maßnahme getroffen wird. Wenn sich z. B. in einem Data-Warehouse-Bericht abzeichnet, dass ein Produkt von einer bestimmten Kundengruppe verhältnismäßig wenig nachgefragt wird, müssten sich die Verantwortlichen für eine adäquate Reaktion entscheiden und diese manuell veranlassen. Die Verzögerungen, die in diesem Zusammenhang auftreten, können erheblich sein. Das bereits geschilderte Konzept des Active Data Warehouse verspricht für diese Art der Latenz zumindest partiell Abhilfe zu schaffen. 4 Beschleunigungspotentiale: Möglichkeiten und Grenzen Klassische Data-Warehouse-Systeme bringen ihre Daten oftmals nur täglich auf den neuesten Stand [BaGü09, S. 102]. Es finden sich sogar Analytische Datenbanken, die lediglich eine Aktualität auf Wochen- oder Monatsbasis besitzen 6

7 [Thie10]. Während eines Updatevorgangs werden in einem sog. batch oder bulk load alle seit dem letzten Ladeprozess getätigten Änderungen in das Data Warehouse übernommen [Shel06, S. 426]. Während des ETL-Prozesses können die Benutzer und Applikationen des OLAP-Systems in der Regel nicht auf die Analysedaten zugreifen [SaBe08, S. 49]. Nachfolgend werden Konzepte vorgestellt, die helfen sollen, Transaktionsdaten schneller im Data Warehouse bereitzustellen. 4.1 Beschleunigungspotentiale im ETL-Bereich Eine Beschleunigung der Datenintegration ist häufig durch die Optimierung der in diesem Zusammenhang stattfindenden Prozessoperationen möglich. Dabei muss allerdings berücksichtigt werden, dass eine höhere Aktualität in diesem Bereich zu Lasten der Datenstabilität geht. Da die Informationen teilweise kontinuierlich in das Data Warehouse eingespeist werden und keine festen Publikationszeitpunkte bestehen, kann es zu Inkonsistenzen und Schemaverletzungen kommen [Thie10, S. 57]. Zudem haben die gesteigerten Ladegfrequenzen eine Erhöhung der Analyselatenz zur Folge. Die ständigen Aktualisierungen führen dazu, dass entweder das OLAP-System vorübergehend nicht verfügbar ist oder sich die Antwortzeiten aufgrund des gestiegenen Workloads erhöhen [Thie10, S. 56] Near-Realtime-Ansatz Es wird Transaktionsdaten geben, die zwar aktuell sein müssen, deren Verfügbarkeit aber nicht unmittelbar erfolgskritisch ist. So können z. B. die Verkaufszahlen des Multimediahandels auf einem Stand gehalten werden, der mehrmals am Tag, ggf. auch stündlich, erneuert wird. Zu diesem Zweck müssen lediglich die Ladefrequenzen der Batchoperationen erhöht werden.[lang04] Um festzustellen, welche Daten sich seit dem letzten Update verändert haben, wird eine Monitoring-Komponente eingesetzt, die die Datenmanipulationen der OLTP-Systeme überwacht. Im Zuge des Monitoring werden in den Transaktionssystemen veränderte Datensätze entsprechend markiert. Für diese Vorgehensweise existieren verschiedene Verfahren. Im Near-Realtime-Warehousing sind dabei v. a. die Ansätze des timestampbasierten, des logbasierten und des snapshotbasierten Monitoring relevant [BaGü09, S. 50]. timestampbasiert: Jedem Datensatz werden in der Quelldatenbank Zeitstempel zugeordnet. Im Fall einer Änderung erhält ein Tupel eine neue Zeitmarke. Beim nächsten Batch-Load werden dann die Transaktionsdaten in das Data Warehouse integriert, deren Timestamps jünger sind als der Zeitpunkt des letzten Ladeprozesses. logbasiert: Im Zuge dieses Verfahrens arbeitet man mit den Logdateien der Transaktionsdatenbank, um die zu ladenden Tupel zu identifizieren. 7

8 snapshotbasiert: Beim Snapshot-Verfahren wird der aktuelle Zustand der Quelldaten in periodischen Abständen in eine Datei (Snapshot) geschrieben. Um schließlich die für das Batching relevanten Datensätze zu ermitteln, erfolgt eine Deltaberechnung der Nettoänderungen zwischen den einzelnen Snapshots Direct-Data- oder Trickle-Feed-Ansatz In diesem push-basierten Verfahren erfolgt eine synchrone Aktualisierung. Die Nettoänderungen werden, sobald sie in den Transaktionssystemen auftauchen, direkt in die OLAP-Datenbank übertragen [Lehn03, S. 181 f.]. Zu diesem Zweck muss das Datenbankmanagementsystem aktive Mechanismen wie Trigger unterstützen. Sobald eine Manipulation erfolgt, werden die entsprechenden Tupel in die Faktentabellen des Data Warehouses eingefügt [BaGü09]. Bei diesem Ansatz liegen die Daten minutenoder sogar sekundenaktuell vor, da sie kontinuierlich in die Analysedatenbank geschrieben werden. Zudem sind die in das OLAP-System zu übertragenden Datenvolumen nicht sehr umfangreich. Aus diesem Grund kann das Data Warehouse auch während der inkrementellen Aktualisierung genutzt werden.[fasa10] Allerdings skaliert das Verfahren nicht gut. Komplexe OLAP-Anfragen können schnell mit kontinuierlichen INSERT-Operationen in Konflikt geraten. Dies führt zu einer Verschlechterung der Anfrageperformanz [Lang04] Partitionsbasierter Ansatz Auch bei diesem Ansatz wird die Aktualisierung inkrementell vorgenommen. Sobald eine Änderung bei den Transaktionsdaten erfolgt ist, wird sie unmittelbar an das OLAP-System propagiert. Allerdings werden die Informationen in einer Übergangstabelle im Data Warehouse zwischengespeichert, bevor sie in die historisierten Faktentabellen geladen werden [Lang04]. Santos und Bernardino beschreiben eine Vorgehensweise, die diesen Ansatz weiter spezifiziert [SaBe08, S. 49ff.]. Sie schlagen vor, für jedes Tupel, für das in der Datenquelle ein COMMIT erfolgt ist, einen Trigger auszulösen, der eine Datentransformation initialisiert. Die auf diese Weise erzeugten Datensätze werden vorübergehend in die Real-time-Tabellen des Data Warehouses geschrieben. Eine solche Tabelle besitzt im Unterschied zu den eigentlichen Faktentabellen keine Indizes, Primärschlüssel oder sonstige Integritätsbedingungen. Auf diese Weise ist es möglich, eine bessere Schreib- und Leseperformance zu erzielen. Zusätzlich wird für jede Änderung, die bei ein und derselben Zelle in der temporären Tabelle erfolgt, ein Zähler inkrementiert. So müssen die Daten nicht erst überschrieben werden. Stattdessen wird lediglich derjenige Datensatz mit dem höchsten Zähler in das Data Warehouse übernommen. Für die Abfrage werden dann ggf. historisierte und temporäre Daten gejoint (s. Abschnitt 4.2.4). Vorteilhaft ist zudem, dass für einen Anfrage-Befehl, welcher nur aktuelle Daten benötigt, ausschließlich die Replikatabellen abgefragt werden müssen. Eine Übertragung der Daten aus der Partition in das eigentliche Data Warehouse sollte immer dann erfolgen, wenn ein erhöhtes Aufkommen an Echtzeitdaten zu einer verminderten Anfrageperformance führt. Dies geschieht, da der Auf- 8

9 wand der Zusammenführung von Datenmengen aus den dauerhaften und den temporären Tabellen mit der Zunahme der Informationen ansteigt. In diesem Zusammenhang ließe sich für die Antwortzeiten z. B. ein Schwellwert festlegen, den es nicht zu unterschreiten gilt. Es ist auch möglich, im Zuge des Data- Warehouse-Designs andere Ladebedingungen zu spezifizieren. So wäre es z. B. denkbar, die Temporärdaten immer dann in die Faktentabellen zu übertragen, wenn eine bestimmte Tupel-Anzahl erreicht oder eine gewisse Zeitspanne überschritten ist. Die Einfügeoperationen gehen einher mit dem Wiederaufbau aller Indizes und der Aktualisierung von Aggregationen und materialisierten Sichten Cachebasierter Ansatz Eine weitere Möglichkeit ist es, die neu hinzukommenden Transaktionsdaten vorübergehend in einem Real-time Data Cache (RTDC) außerhalb des eigentlichen Data Warehouses zu speichern. Dieser Cache ist ein eigener Datenbankserver, in dem die Relationen den Faktentabellen des historisierten OLAP-Systems gleichen. Allerdings werden nur solche Tabellen vorgehalten, die für die Real-time-Daten benötigt werden [SSPK09]. Diese Architektur eignet sich für alle Arten von Applikationen, die entweder mit einem großen Aufkommen von Echtzeitdaten umgehen müssen oder eine gesteigerte Anfrageperformanz benötigen. Sollten Analyseprozesse sowohl auf historische als auch auf aktuelle Daten angewiesen sein, können die Daten mit Hilfe einer Just-In-Time-Integration (s. Abschnitt 4.2.4) zusammengeführt werden. Wie im Fall des partitionsbasierten Ansatzes müssen die Echtzeitdaten periodisch in das eigentliche Data Warehouse übertragen werden. Bei beiden Verfahren ist im Zuge des Ladeprozesses mit erhöhtem Workload und einer Beeinträchtigung der Antwortzeiten zu rechnen. Während bei der partitionsbasierten Herangehensweise, aufgrund der fehlenden Restriktionen in den Temporärtabellen, zusätzliche Transformationen nötig sind, treten beim Laden der RTDC-Daten v. a. Verzögerungen auf, weil die Tupel aus einem separaten System übertragen werden [Lang04] Enterprise Application Integration Die Ladeprozesse des Data Warehouses können auch mit Hilfe bereits integrierter Transaktionsdaten beschleunigt werden. Das kann über die Umsetzung einer Enterprise-Application- Integration-Architektur (EAI) erfolgen. Diese Form der Prozessintegration verknüpft die operativen Prozesse der Transaktionssysteme redundanzfrei miteinander. Im Beispiel des Multimediahandels würden Bestell-, Liefer- und Rechnungsinformationen nicht in separaten Softwaresystemen und Datenbanken gehalten, sondern ganzheitlich in einem gemeinsamen System erfasst und bearbeitet werden. Die integrierten Daten ließen sich dann von der EAI-Schicht in das Data Warehouse übertragen. In diesem Stadium wäre bereits ein Großteil der Bereinigungsoperationen, wie z. B. Formatänderungen, schon getätigt [Shel06, S. 432]. 9

10 4.2 Beschleunigungpotentiale im Analysebereich Klassische OLAP-Systene arbeiten üblicherweise auf statischen, nicht veränderlichen Daten. In einem Echtzeit-Data-Warehouse besteht das Problem, dass gleichzeitig lesende und schreibende Zugriffe verarbeitet werden müssen. Dies führt dazu, dass die Daten Inkonsistenzen aufweisen und damit instabil sein können. Darüber hinaus ist es möglich, dass die kontinuierlichen Ladeprozesse Anfragen blockieren oder Antwortzeiten verlängern. Auf diese Weise führt die gesteigerte Data Freshness im ETL-Bereich des Data Warehouse zu einer Belastung der Anfrage-Performance. Gleichzeitig greifen Mechanismen, die der Anfrageoptimierung dienen, auf historisierte Daten zurück. So könnten z. B. aggregrierte Daten nicht mit den bereits geladenen Echtzeitinformationen übereinstimmen. [Lang04]. Die richtige Strategie im Spannungsverhältnis zwischen Datenaktualität und verringerter Anfragelatenz muss von Fall zu Fall abgewogen werden. In diesem Zusammenhang sollten Systembenutzer in den Designprozess einbezogen werden, um Anforderungen an die Data Freshness und gewünschte durchschnittliche Antwortzeiten zu spezifizieren [Thie10, S. 56]. Im Folgenden werden daher sowohl Ansätze vorgestellt, die die Anfragelatenzen verringern, als auch solche, die darauf ausgerichtet sind, aktuelle Daten adäquat abzufragen Materialisierte Sichten und Präaggregation Anfragen in OLAP- Systemen sind weitaus komplexer, als in OLTP-Datenbanken. Wenn die Daten eines Data Warehouses in relationen Strukturen abgelegt sind (Relational OLAP - ROLAP), dann müssen sie anhand mehrerer Dimensionen zusammengefügt und über viele Hierarchieebenen hinweg aggregiert werden [PaKYJ02, S. 379]. Dies wird auch als Snowflake-Schema bezeichnet. Antwortzeiten von Abfragen können dabei im Minutenbereich liegen und daher nicht den Echtzeitzustand der Daten widerspiegeln [Lang04]. Eine verbreitete Strategie, um diesem Problem zu begegnen, ist die Speicherung häufig abegfragter Ergebnisse in bereits gejointen Relationen. Diese Tabellen werden auch materialisierte Sichten (materialized views) genannt und dienen der Zugriffsbeschleunigung. Abb. 2 zeigt das Star-Schema eines potentiellen Data Warehouses. Dieses Schema könnte die Datengrundlage im OLAP-System des bereits erwähnten Multimediahandels sein. Geht man z. B. davon aus, dass die Vertriebsmanager Angaben bzgl. der täglichen Umsatzzahlen aller Einzelhandelszweigstellen in verschiedenen Städten seit Beginn des Jahres benötigen, dann könnte eine materialisierte Sicht folgendermaßen aussehen (das Beispiel ist angelehnt an [PaKYJ02, S. 381]). 10

11 Abbildung 2. Star-Schema eines potentiellen Data Warehouse [PaKYJ02, S. 380] CREATE VIEW Daily_Sales_2012 AS SELECT Store.city, Time.day, sum(sales.sales_dollar) FROM Store, Time, Sales WHERE Sales.store_id=Store.store_id AND Sales.time_id=Time.time_id AND Time.year >= 2012 GROUP BY Store.city, Time.day Auf diese Weise sind die aggegregierten Ergebnisse der zusammengefügten Tabellen bei zukünftig anfallenden Anfragen schon gespeichert und können schnell abgerufen werden. Allerdings steht dieser Ansatz der Anfragebeschleunigung in Konflikt mit der kontinuierlichen Aktualisierung. Es müsste sichergestellt werden, dass eine Erneuerung der materialisierten Sichten immer dann erfolgt, sobald zusätzliche Echtzeitdaten in das Data Warehouse eingefügt werden. Ein solches Vorgehen ist sehr aufwändig und kann dazu führen, dass die Beschleunigung der Antwortperformance durch die häufigen Neuberechnungen der Sichten wieder verloren geht. Die provisorische Speicherung aller denkbaren Kombinationen von Aggregationen (Multidimensional OLAP - MOLAP) nimmt darüber hinaus viel Speicherplatz in Anspruch. Aus diesem Grund wird häufig von dem Konzept der anwenderorientierten Voraggregation Gebrauch gemacht, bei dem nur die wichtigsten Berechnungen im Vorfeld stattfinden. Diese gemischte Vorgehensweise wird auch als Hybrides OLAP (HOLAP) bezeichnet [PeJe01, S. 43 f.] Allerdings ist darauf hinzuweisen, dass in den nächsten Jahren durch die zusätzlichen Möglichkeiten der Hardwarebeschleunigung mit einer Verschiebung zugunsten des ROLAP zu 11

12 rechen ist, da sich Aggregrationen zunehmend schneller im Hauptspeicher berechnen lassen (s. Abschnitt 5) Rechtebeschränkungen Eine weitere Möglichkeit, um die Anfragegeschwindigkeiten des OLAP-Systems zu verbessern, ist eine Rechteverwaltung, die es einigen Nutzern verbietet, Anfragen auf bestimmten Daten durchzuführen oder komplexe Analysen zu starten. So müsste z. B. das obere Management des Multimediahandels nicht unbedingt Zugriff auf hochaktuelle Daten haben. Denn die langfristige, strategische Planung lässt sich ggf. ohne die Absatzzahlen der letzten Tage oder Stunden durchführen. Für die Marketingabteilung, die auch auf kurzfristige Trends reagieren muss, ist der Zugriff auf die Echtzeitdaten hingegen relevant. Rollenbasierte Zugriffsbeschränkungen ermöglichen demnach die Verringerung des Workloads und die Verbesserung der Antwortzeiten [Lang04] Priorisiertes Scheduling Das prioritätsgesteuerte Laden bietet eine Möglichkeit, um den Workload im Data Warehouse auf einem niedrigen Level zu halten und trotz allem die Abfrage hochaktueller Daten zu gewährleisten. Lehner und Thiele stellen ein Verfahren vor, bei dem nur Echtzeitaktualisierungen vorgenommen werden, die Relevanz für die aktuellen OLAP-Anfragen besitzen [LeTh09]. Dazu wird angenommen, dass die kontinuierlich anfallenden Echzeitdaten vorübergehend in einer Update-Queue und die an das System gestellten Anfragen in einer Query-Queue zwischengespeichert werden. Unter Berücksichtigung der von den Systemnutzern vorgegebenen Spezifikationen wird jeder Anfrage der Query-Queue eine Priorität zugewiesen. Für die Abfrage mit der höchsten Priorität wird ermittelt, welche der sich in der Update-Queue befindenden Transaktionsdaten zunächst in das Data Warehouse geladen werden müssen. Auf diese Weise können dann die hochaktuellen Daten aus dem OLTP-System right on time bereitgestellt werden. Allerdings ist an dieser Stelle darauf hinzuweisen, dass das geschilderte Vorgehen bei Anfragen, die viele Aktualisierungen benötigen, zu erheblichen Verzögerungen führt. Daher lässt sich das Konzept nur bei einem geringen Aufkommen an Echtzeitdaten sinnvoll einsetzen Just-in-Time-Integration Im Gegensatz zu den in den vorherigen Abschnitten vorgestellten Konzepten behandelt der kommende Abschnitt kein Verfahren, das direkt darauf abzielt, die Antwortzeiten des OLAP-Systems zu verbessern oder den Workload zu senken. Im Folgenden wird vielmehr die Frage zu beantworten sein, inwieweit die Real-Time-Daten durch entsprechende Anfrage-Tools zeitnah genutzt werden können. Ein Ansatz, um dies zu erreichen, ist die Just-in-Time-Integration. Bei diesem Verfahren werden die Daten erst zum Zeitpunkt der Anfrage zusammengeführt. Im Unterschied zum Ladeprozess beim priorisierten Scheduling werden die während der Anfrage in das Data Warehouse überführten Daten allerdings nicht persistent gespeichert. 12

13 Das Verfahren der Just-in-Time-Integration bietet den Vorteil, dass Realtime- Informationen in jeder Phase des ETL-Prozesses (und somit auch noch nicht integrierte Daten) abgerufen werden können. Abb. 3 zeigt das Schema einer solchen idealtypischen Architektur. Abbildung 3. Referenzarchitektur eines Echtzeit-Data-Warehouses[Thie10, S. 52] Nach dieser Vorstellung werden die Anfragen aus dem OLAP-System über die Vermittlungsschicht auf die einzelnen Prozessstufen umgeleitet. So ist es möglich, die schon extrahierten aber noch unbereinigten Daten aus dem Arbeitsbereich abzufragen. In weiter fortgeschrittenen Phasen des Extraxt-Transfer- Load-Prozesses, in denen z. B. bereits Formatanpassungen und Duplettenentfernungen erfolgt sind, kann ein Abruf aus der konsolidierten Basisdatenbank stattfinden. Zudem steuert die Vermittlungsschicht die Ausgabe von Daten aus dem Data Warehouse, den Data Marts und dem Reporting-Layer. Die vorgestellte Architektur stellt besonders hohe Anforderungen an den Query-Manager. Er hat zum einen die Aufgabe, festzustellen, welche Real-Time-Komponenten die Anfrage enthält. Zum anderen muss er den Anfragebefehl so modifizieren, dass die Echtzeitdaten auch tatsächlich ermittelt werden können. Dafür ist es erforderlich, dass der Query-Manager die Schemata der Real-Time-Informationen an den verschiedenen Stationen des ETL-Prozesses kennt [Lang04]. Werden z. B. Daten abgefragt, die sich noch im Transformationsprozess befinden, müssten die Anfragen, entsprechend den Schemaanforderungen der einzelnen Prozessstufen, umgeschrieben werden (engl. query-rewrite) [Thie10, S. 52]. Auf diese Weise könnten OLAP-Anfragen, die beispielsweise in Form einer Multidimensional Expression (MDX)[Nola99] gestellt sind, in SQL-konforme Teilanfragen zerlegt und zu den Schichten geschickt werden, die in einer eindimensionalen relationalen Struktur vorliegen. 13

14 5 Die Integration von OLTP und OLAP Klassischerweise sind OLAP und OLTP in zwei getrennten Systemen organisiert. Die bisher geschilderten Ansätze haben Wege aufgezeigt, um die Prozesse im Rahmen dieser Architektur zu beschleunigen. Im Folgenden wird hingegen ein Verfahren vorgestellt, das das Ziel verfolgt, transaktions- und analyseorientierte Operationen in einem System zu integrieren. Hierzu stellt Plattner ein Datenbankmanagementsystem vor, welches im Wesentlichen auf einer spaltenorientierten In-Memory-Datenhaltung basiert [Plat09]. Traditionellerweise werden die Informationen einer transaktionsverwaltenden Datenbank tupelweise (d. h. in Form der einzelnen Tabellenzeilen) gespeichert. So können Datensätze effizienter aktualisiert und eingefügt werden. Demgegenüber erfolgt die Speicherung der OLAP-Daten weitestgehend spaltenorientiert. Auf diese Weise lassen sich reine Lesezugriffe und Aggregationen schneller durchführen [Thie10]. Plattner geht nun davon aus, dass die spaltenorientierte Speicherstrategie ebenso für ein integriertes System anwendbar sein könnte. Seine Argumentation ist, dass sich die höheren Prozessorgeschwindigkeiten moderner Rechner und die Möglichkeit einer In-Memory-Datenhaltung ausnutzen lassen, um sowohl Lesezugriffe als auch update-intensive Prozesse in einem gemeinsamen Datenbankmanagementsystem zu organisieren. Zudem ermöglicht die Vorhaltung der Tabellen im Hauptspeicher eine schnellere Verarbeitung von Join-Operationen und Aggregationen. Dabei werden die Berechnungen nicht mehr im Voraus getätigt, sondern zur Laufzeit generiert. Zudem stellt Plattner für seinen Systementwurf einen insert-only-ansatz vor. Bei dieser Vorgehensweise finden keine Löschoperationen statt. Stattdessen erhalten neue Zellenwerte einen aktuellen Zeitstempel. So können Einfüge- und Veränderungsoperationen schneller getätigt werden. Für die Abfrage und Analyse der Daten werden dann nur solche Werte berücksichtigt, deren Zeitstempel zum Beginn der Anfrage kleiner, als der aktuelle Timestamp sind. Außerdem können mit einem solchen Vorgehen aufwändige Sperrverfahren vermieden werden. Stattdessen bestimmen Zeitstempel über die Abarbeitungsreihenfolge nebenläufiger Operationen. Dieses Verfahren wird auch als pessimistisches Sperren bezeichnet. Für den Fall, dass auf einem Tupel Datenmanipulationen ausgeführt werden, wird der Zeitstempel einer neuen Anfrage automatisch dekrementiert. Auf diese Weise wird der gerade bearbeitete Datensatz aus der Analyse ausgeschlossen. Um die Datenvolumen im Hauptspeicher auf einem möglichst niedrigen Niveau zu halten, erfolgt die Sicherung historischer Daten auf einem separaten persistenten Speichermedium. In dem von Plattner vorgestellten System entfällt die ETL-Schicht einer klassischen Data-Warehouse-Architektur. Veränderungen werden in der gemeinsamen Datenbank gespeichert und können unmittelbar in analytische Berechnungen einbezogen werden. Auf diese Weise ist die Verringerung von Latenzzeiten im Lade- und Analysebereich möglich. Zudem wird durch die Zusammenführung des OLTP- und des OLAP-Systems die Redundanz der Datenhaltung beseitigt. Aufwendungen, die zuvor zweimal für die Speicherung und Verarbeitung der 14

15 Informationen getätigt wurden, müssen nun nur noch einmal vorgenommen werden. Das von Plattner beschriebene integrierte System ist bislang allerdings nur für eine Datenbank mit ca. 35 Millionen Tupeln getestet worden. Es bleibt abzuwarten, wie gut diese Lösung für Tabellengrößen mit über 100 Millionen Tupeln skaliert. Außerdem ist nach wie vor ungeklärt, inwieweit ein adäquates Sperrund Workloadmanagement bewerkstelligt werden kann. Da in Plattners Systementwurf Abfrageoperationen mit Einfügeprozessen in Konflikt stehen können, ist das Finden effizienter Lösungen in diesen Bereichen besonders erfolgskritisch. Gleichwohl ist die Frage zu beantworten, ob die Zusammenführung von OLTPund OLAP-Systemen tatsächlich zielführend ist. So geht z. B. Conn darauf ein, dass die Transaktiondatenbanken und das Data Warehouse unterschiedlichen Zwecken dienen und daher getrennt sein sollten. Auf diese Weise könnten Datenschemata und Speicherstrukturen am besten auf die jeweiligen Systemanforderungen ausgerichtet werden. Zudem werden nicht alle Transaktionsinformationen für die Erstellung von Analyseberichten benötigt [Conn05, S. 516]. Zusätzlich vernachlässigt der Ansatz von Plattner, dass in einem OLAP-System nicht nur Daten aus relationalen Systemen vorzufinden sind, denen ein einheitliches Schema zugrunde liegt. Vielmehr können die integrierten Informationen sehr heterogenen, mitunter sogar semistrukturierten Quellen (z. B. XML-Daten) entspringen. Auch Inmon sieht den Verzicht auf die Transformations- und Integrationsprozesse kritisch: There is no point in bringing data [...] into the data warehouse environment without integrating it. If the data arrives at the data warehouse in an unintegrated state, it cannot be used to support a corporate view of data. [Inmo06] Aus diesem Grund wird ein ganzheitliches Transaktions- und Analysesystem nur für bestimmte Anwendungsfälle praktikabel sein. 6 Fazit In der vorliegenden Arbeit wurde darauf eingegangen, dass die Daten klassischer Data Warehouses mehreren Zeitverzögerungen unterliegen. Die Ausführungen haben gezeigt, dass bereits zahlreiche Möglichkeiten bestehen, Transaktionsdaten in einem Data Warehouse zeitnah zur Verfügung zu stellen. So gibt es sowohl in den einzelnen Phasen des ETL-Prozesses als auch bei der Erstellung von Berichten und Analysen Beschleunigungspotentiale. In diesem Zusammenhang sollte nicht vergessen werden, dass Zeiteinsparungen in einem Bereich zu Verzögerungen in dem jeweils anderen Bereich führen können. Die Entscheidung zwischen einer höheren Datenaktualität und verringerten Anfragelatenzen muss dabei für jeden Fall neu getroffen werden. Überdies ist zu berücksichtigen, dass eventuelle Zeiteinsparungen auch immer vor dem Hintergrund der jeweiligen Anwenderbedürfnisse gesehen werden sollten. So müssten z. B. im Fall des Multimediaversandhandels nicht unbedingt die Daten der Personalverwaltung 15

16 unmittelbar für die Analyse bereitstehen. Vielmehr ist es wichtig, dass die richtigen Informationen, wie beispielsweise die neuesten Verkaufszahlen, zur richtigen Zeit verfügbar sind. Darüber hinaus können mithilfe der Integration von OLTP- und OLAP-Systemen zusätzliche Zeiteinsparungen erzielt werden. Aber auch hier ist, aufgrund der vereinfachten Systemarchitektur und eines gemeinsamen Schemas für alle Daten, mit Einbußen bei der Funktionalität zu rechnen. Die höhere Datenaktualität geht in diesem Fall zu Lasten einer integrierten Sicht auf heterogene Datenbestände. Zudem sind effiziente Sperrmechanismen nötig, um den gleichzeitigen und konsistenten Zugriff von Schreib- und Leseoperationen zu ermöglichen. Zusammenfassend kann festgehalten werden, dass die Anforderung der Datenaktualität in einem Data Warehouse vor dem Hintergrund dynamischer Umweltverhältnisse ein wichtiges und wünschenswertes Ziel ist. Gleichwohl sollte bedacht werden, zu welchem Preis potentielle Zeiteinsparungen erreicht werden können. Eine Reduktion der Latenzzeit wird mit diesem Wissen nur dann vorgenommen, wenn sie für den gegebenen Zweck auch tatsächlich sinnvoll erscheint. Literatur Baer04. Hermann Baer. On-Time Data Warehousing with Oracle Database10g - Information at the Speed of your Business, March BaGü09. Andreas Bauer und Holger Günzel (Hrsg.). Data-Warehouse-Systeme: Architektur, Entwicklung, Anwendung, Band 3. Aufl. dpunkt-verl., Heidelberg Conn05. Samuel Conn. OLTP and OLAP data integration : a review of feasible implementation methods and architectures for real time data analysis. SoutheastCon, Proceedings. IEEE, 2005, S FaSa10. Farrah Farooq und Syed Mansoor Sarwar. Real-time data warehousing for business intelligence. Proceedings of the 8th International Conference on Frontiers of Information Technology, Inmo06. W. H. Inmon. Building the data warehouse, Band 4. eds. John Wiley Sons, New York JöDe10. Thomas Jörg und Stefan Dessloch. Near Real-Time Data Warehousing Using State-of-the-Art ETL Tools. Work, Band 41, 2010, S Lang04. Justin Langseth. Real-time Data Warehousing: Challenges and Solutions, August Lehn03. Wolfgang Lehner. Datenbanktechnologie für Data-Warehouse-Systeme: Konzepte und Methoden. dpunkt-verl., Heidelberg LeTh09. Wolfgang Lehner und Maik Thiele. Evaluation of Load Scheduling Strategies for Real-Time Data Warehouse Environments. Proceedings of the 3rd International Workshop on Business Intelligence for the Real-Time Enterprise, 2009, S MNSV09. Mukesh K. Mohania, Ullas Nambiar, Michael Schrefl und Millist W. Vincent. Active and Real-Time Data Warehousing. In Encyclopedia of Database Systems, S Nola99. Carl Nolan. Manipulate and Query OLAP Data Using ADOMD and Multidimensional Expressions, August

17 PaKYJ02. Chang-Sup Park, Myoung Ho Kim und Lee Yoon-Joon. Finding an efficient rewriting of OLAP queries using materialized views in data warehouses. Decision Support Systems, 32(4), 2002, S PeJe01. Torben Pedersen und Christian Jensen. Multidimensional database technology. Computer, 34(12), dec 2001, S Plat09. Hasso Plattner. A common database approach for OLTP and OLAP using an in-memory column database. In Proceedings of the 35th SIGMOD international conference on Management of data, 2009, S SaBe08. Ricardo Santos und Jorge Bernardino. Real-time data warehouse loading methodology. Proceedings of the 2008 international symposium on Database engineering applications, 2008, S Shel06. Joachim Shelp. Real-Time Warehousing und EAI. In Analytische Informationssysteme: Business Intelligence-Technologien und Anwendungen. Springer, SSPK09. Michael Soffner, Norbert Siegmund, Mario Pukall und Veit Köppen. Towards Real-Time Data Integration and Analysis for Embedded Devices. In Grundlagen von Datenbanken, S Universität Rostock, Thie10. Maik Thiele. Qualitätsgetriebene Datenproduktionssteuerung in Echtzeit- Data-Warehouse-Systemen. Dissertation, Technische Universität Dresden, ThPL08. Christian Thomsen, Torben Bach Pedersen und Wolfgang Lehner. RiTE: Providing On-Demand Data for Right-Time Data Warehousing. In Proceedings of the 2008 IEEE 24th International Conference on Data Engineering. IEEE Computer Society, 2008, S

REAL-TIME DATA WAREHOUSING

REAL-TIME DATA WAREHOUSING REAL-TIME DATA WAREHOUSING Lisa Wenige Seminarvortrag Data Warehousing und Analytische Datenbanken Friedrich-Schiller-Universität Jena - 19.01.12 Lisa Wenige 19.01.2012 2 Agenda 1. Motivation 2. Begriffsbestimmung

Mehr

Kapitel 2 Terminologie und Definition

Kapitel 2 Terminologie und Definition Kapitel 2 Terminologie und Definition In zahlreichen Publikationen und Fachzeitschriften tauchen die Begriffe Data Warehouse, Data Warehousing, Data-Warehouse-System, Metadaten, Dimension, multidimensionale

Mehr

Themenblock: Erstellung eines Cube

Themenblock: Erstellung eines Cube Themenblock: Erstellung eines Cube Praktikum: Data Warehousing und Data Mining Einführung relationale Datenbanken Problem Verwaltung großer Mengen von Daten Idee Speicherung der Daten in Form von Tabellen

Mehr

Vergleich von Open-Source und kommerziellen Programmen zur Durchführung eines ETL-Prozesses

Vergleich von Open-Source und kommerziellen Programmen zur Durchführung eines ETL-Prozesses Vergleich von Open-Source und kommerziellen Programmen zur Durchführung eines ETL-Prozesses Exposé zur Diplomarbeit Humboldt-Universität zu Berlin Mathematisch-Naturwissenschaftliche Fakultät II Institut

Mehr

Einführungsveranstaltung: Data Warehouse

Einführungsveranstaltung: Data Warehouse Einführungsveranstaltung: 1 Anwendungsbeispiele Berichtswesen Analyse Planung Forecasting/Prognose Darstellung/Analyse von Zeitreihen Performancevergleiche (z.b. zwischen Organisationseinheiten) Monitoring

Mehr

Data Warehouse Grundlagen

Data Warehouse Grundlagen Seminarunterlage Version: 2.10 Version 2.10 vom 24. Juli 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen sind Warenzeichen

Mehr

1 Einleitung. Betriebswirtschaftlich administrative Systeme

1 Einleitung. Betriebswirtschaftlich administrative Systeme 1 1 Einleitung Data Warehousing hat sich in den letzten Jahren zu einem der zentralen Themen der Informationstechnologie entwickelt. Es wird als strategisches Werkzeug zur Bereitstellung von Informationen

Mehr

Data Warehouse Definition (1) http://de.wikipedia.org/wiki/data-warehouse

Data Warehouse Definition (1) http://de.wikipedia.org/wiki/data-warehouse Data Warehouse Definition (1) http://de.wikipedia.org/wiki/data-warehouse Ein Data-Warehouse bzw. Datenlager ist eine zentrale Datensammlung (meist eine Datenbank), deren Inhalt sich aus Daten unterschiedlicher

Mehr

Data Warehouse Technologien

Data Warehouse Technologien mitp Professional Data Warehouse Technologien von Veit Köppen, Gunter Saake, Kai-Uwe Sattler 2. Auflage 2014 Data Warehouse Technologien Köppen / Saake / Sattler schnell und portofrei erhältlich bei beck-shop.de

Mehr

Einführung in OLAP und Business Analysis. Gunther Popp dc soft GmbH

Einführung in OLAP und Business Analysis. Gunther Popp dc soft GmbH Einführung in OLAP und Business Analysis Gunther Popp dc soft GmbH Überblick Wozu Business Analysis mit OLAP? OLAP Grundlagen Endlich... Technischer Background Microsoft SQL 7 & OLAP Services Folie 2 -

Mehr

Einführung in Hauptspeicherdatenbanken

Einführung in Hauptspeicherdatenbanken Einführung in Hauptspeicherdatenbanken Harald Zankl Probevorlesung 13. 01., 13:15 14:00, HS C Inhaltsverzeichnis Organisation Überblick Konklusion Harald Zankl (LFU) Hauptspeicherdatenbanken 2/16 Organisation

Mehr

Business Intelligence. Data Warehouse / Analyse Sven Elvers 2005-07-06

Business Intelligence. Data Warehouse / Analyse Sven Elvers 2005-07-06 Business Intelligence Data Warehouse / Analyse Sven Elvers 2005-07-06 Einleitung Dieses Dokument beschreibt einen für das Verständnis relevanten Teil der Präsentation. Business Intelligence Motivation

Mehr

Kapitel II. Datenbereitstellung 2004 AIFB / FZI 1. Vorlesung Knowledge Discovery

Kapitel II. Datenbereitstellung 2004 AIFB / FZI 1. Vorlesung Knowledge Discovery Kapitel II Datenbereitstellung 2004 AIFB / FZI 1 II. Datenbereitstellung 2004 AIFB / FZI 2 II. Datenbereitstellung Collect Initial Data identify relevant attributes identify inconsistencies between sources

Mehr

OLAP und Data Warehouses

OLAP und Data Warehouses OLP und Data Warehouses Überblick Monitoring & dministration Externe Quellen Operative Datenbanken Extraktion Transformation Laden Metadaten- Repository Data Warehouse OLP-Server nalyse Query/Reporting

Mehr

MIS by Franziska Täschler, Winformation GmbH ftaeschler@winformation-gmbh.ch Ausgabe 01/2001

MIS by Franziska Täschler, Winformation GmbH ftaeschler@winformation-gmbh.ch Ausgabe 01/2001 MIS Glossar by Franziska Täschler, Winformation GmbH ftaeschler@winformation-gmbh.ch Ausgabe 01/2001 Aggregat Data Cube Data Marts Data Mining Data Warehouse (DWH) Daten Decision Support Systeme (DSS)

Mehr

Data Warehousing Grundbegriffe und Problemstellung

Data Warehousing Grundbegriffe und Problemstellung Data Warehousing Grundbegriffe und Problemstellung Dr. Andrea Kennel, Trivadis AG, Glattbrugg, Schweiz Andrea.Kennel@trivadis.com Schlüsselworte Data Warehouse, Cube, Data Mart, Bitmap Index, Star Queries,

Mehr

Logische Modellierung von Data Warehouses

Logische Modellierung von Data Warehouses Logische Modellierung von Data Warehouses Vertiefungsarbeit von Karin Schäuble Gliederung. Einführung. Abgrenzung und Grundlagen. Anforderungen. Logische Modellierung. Methoden.. Star Schema.. Galaxy-Schema..

Mehr

Data Warehousing. Sommersemester 2005. Ulf Leser Wissensmanagement in der Bioinformatik

Data Warehousing. Sommersemester 2005. Ulf Leser Wissensmanagement in der Bioinformatik Data Warehousing Sommersemester 2005 Ulf Leser Wissensmanagement in der Bioinformatik ... Der typische Walmart Kaufagent verwendet täglich mächtige Data Mining Werkzeuge, um die Daten der 300 Terabyte

Mehr

Eignung unterschiedlicher Faktenmodellierungen in Data Warehouse-Systemen

Eignung unterschiedlicher Faktenmodellierungen in Data Warehouse-Systemen Christoph Arnold (B. Sc.) Prof. Dr. Harald Ritz Eignung unterschiedlicher Faktenmodellierungen in Data Warehouse-Systemen AKWI-Tagung, 17.09.2012, Hochschule Pforzheim Christoph Arnold, Prof. Dr. Harald

Mehr

Index- und Zugriffsstrukturen für. Holger Brämer, 05IND-P

Index- und Zugriffsstrukturen für. Holger Brämer, 05IND-P Index- und Zugriffsstrukturen für Data Warehousing Holger Brämer, 05IND-P Index- und Zugriffstrukturen für Data Warehousing Materialisierte Sichten Bitmap-Indexe Verbundindexe Materialisierte Sichten gehören

Mehr

Kapitel II. Datenbereitstellung. II. Datenbereitstellung. II.1 Grundlagen. II. Datenbereitstellung. Collect Initial Data. II.

Kapitel II. Datenbereitstellung. II. Datenbereitstellung. II.1 Grundlagen. II. Datenbereitstellung. Collect Initial Data. II. II. bereitstellung Kapitel II bereitstellung 1 2 II. bereitstellung II.1 Grundlagen Collect Initial Data identify relevant attributes identify inconsistencies between sources Describe Data characterize

Mehr

Änderungen erkennen Schneller handeln Stefan Panek. Senior Consultant Christoph Jansen. Consultant 23.10.2008

Änderungen erkennen Schneller handeln Stefan Panek. Senior Consultant Christoph Jansen. Consultant 23.10.2008 Änderungen erkennen Schneller handeln Stefan Panek. Senior Consultant Christoph Jansen. Consultant 23.10.2008 Seit der Datenbankversion 9i bietet Oracle das Feature Change Data Capture an. Aber was genau

Mehr

Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht)

Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht) Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht) Christian Haag, DATA MART Consulting Consulting Manager Oracle DWH Team

Mehr

Welche Daten gehören ins Data Warehouse?

Welche Daten gehören ins Data Warehouse? Welche Daten gehören ins Warehouse? Dani Schnider Principal Consultant 9. Januar 2012 In vielen DWH-Projekten stellt sich die Frage, welche Daten im Warehouse gespeichert werden sollen und wie dieser Datenumfang

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

Data Warehousing. Kapitel 1: Data-Warehousing-Architektur. Folien teilweise übernommen von Matthias Gimbel

Data Warehousing. Kapitel 1: Data-Warehousing-Architektur. Folien teilweise übernommen von Matthias Gimbel Data Warehousing Kapitel 1: Data-Warehousing-Architektur Folien teilweise übernommen von Matthias Gimbel 2 Analyse von Geschäftsprozessen Mögliche Fragestellungen Wie entwickelt sich unser Umsatz im Vergleich

Mehr

Mit Transbase Hypercube Data Warehouse Anwendungen effizient betreiben. Die Hypercube-Technologie

Mit Transbase Hypercube Data Warehouse Anwendungen effizient betreiben. Die Hypercube-Technologie Mit Transbase Hypercube Data Warehouse Anwendungen effizient betreiben Transbase Hypercube ist eine Transbase -Option, die die innovative Hypercube-Technologie für komplexe analytische Anwendungen (OLAP)

Mehr

Marketing Intelligence Architektur und Konzepte. Josef Kolbitsch Manuela Reinisch

Marketing Intelligence Architektur und Konzepte. Josef Kolbitsch Manuela Reinisch Marketing Intelligence Architektur und Konzepte Josef Kolbitsch Manuela Reinisch Übersicht Mehrstufiges BI-System Architektur eines Data Warehouses Architektur eines Reporting-Systems Benutzerrollen in

Mehr

In die Zeilen würden die Daten einer Adresse geschrieben werden. Das Ganze könnte in etwa folgendermaßen aussehen:

In die Zeilen würden die Daten einer Adresse geschrieben werden. Das Ganze könnte in etwa folgendermaßen aussehen: 1 Einführung in Datenbanksysteme Fast jeder kennt Excel und hat damit in seinem Leben schon einmal gearbeitet. In Excel gibt es Arbeitsblätter, die aus vielen Zellen bestehen, in die man verschiedene Werte

Mehr

Data-Warehouse-Systeme

Data-Warehouse-Systeme Data-Warehouse-Systeme Architektur, Entwicklung, Anwendung von Andreas Bauer, Holger Günzel 3., überarb. u. aktualis. Aufl. Data-Warehouse-Systeme Bauer / Günzel schnell und portofrei erhältlich bei beck-shop.de

Mehr

Marketing Intelligence Übersicht über Business Intelligence. Josef Kolbitsch Manuela Reinisch

Marketing Intelligence Übersicht über Business Intelligence. Josef Kolbitsch Manuela Reinisch Marketing Intelligence Übersicht über Business Intelligence Josef Kolbitsch Manuela Reinisch Übersicht Beispiel: Pantara Holding Der Begriff Business Intelligence Übersicht über ein klassisches BI-System

Mehr

Datawarehouse Architekturen. Einheitliche Unternehmenssicht

Datawarehouse Architekturen. Einheitliche Unternehmenssicht Datawarehouse Architekturen Einheitliche Unternehmenssicht Was ist Datawarehousing? Welches sind die Key Words? Was bedeuten sie? DATA PROFILING STAGING AREA OWB ETL OMB*PLUS SAS DI DATA WAREHOUSE DATA

Mehr

eevolution Business Intelligence Oliver Rzeniecki COMPRA GmbH Programmierer & Datenbankadministrator

eevolution Business Intelligence Oliver Rzeniecki COMPRA GmbH Programmierer & Datenbankadministrator eevolution Business Intelligence Oliver Rzeniecki COMPRA GmbH Programmierer & Datenbankadministrator Agenda Was ist Business Intelligence? Was ist OLAP? Unterschied zwischen OLAP und OLTP? Bestandteile

Mehr

Data Warehousing: Anwendungsbeispiel

Data Warehousing: Anwendungsbeispiel Frühjahrsemester 2012 cs242 Data Warehousing / cs243 Datenbanken Kapitel 1: Einführung H. Schuldt Data Warehousing: Anwendungsbeispiel Tresgros Tresgros Tresgros Filiale Muttenz Filiale Allschwil Filiale

Mehr

Business Intelligence

Business Intelligence Business Intelligence Anwendungssysteme (BIAS) Lösung Aufgabe 1 Übung WS 2012/13 Business Intelligence Erläutern Sie den Begriff Business Intelligence. Gehen Sie bei der Definition von Business Intelligence

Mehr

In-Memory Datenbanken im Kontext komplexer Analytics Pojekte am Beispiel der Otto Group BI

In-Memory Datenbanken im Kontext komplexer Analytics Pojekte am Beispiel der Otto Group BI In-Memory Datenbanken im Kontext komplexer Analytics Pojekte am Beispiel der Otto Group BI Hanau, 25.02.2015 1 Titel der Präsentation, Name, Abteilung, Ort, xx. Monat 2014 Der Aufbau der Group BI Plattform

Mehr

SQL PASS Treffen RG KA. Überblick Microsoft Power BI Tools. Stefan Kirner Karlsruhe, 27.05.2014

SQL PASS Treffen RG KA. Überblick Microsoft Power BI Tools. Stefan Kirner Karlsruhe, 27.05.2014 SQL PASS Treffen RG KA Überblick Microsoft Power BI Tools Stefan Kirner Karlsruhe, 27.05.2014 Agenda Die wichtigsten Neuerungen in SQL 2012 und Power BI http://office.microsoft.com/en-us/office365-sharepoint-online-enterprise-help/power-bi-for-office-365-overview-andlearning-ha104103581.aspx

Mehr

Datenbanktechnologie für Data-Warehouse-Systeme

Datenbanktechnologie für Data-Warehouse-Systeme Wolfgang Lehner Datenbanktechnologie für Data-Warehouse-Systeme Konzepte und Methoden dpunkt.verlag 1 1.1 1.2 1.3 1.4 1. 5 2 2.1 2.2 2.3 Einleitung 1 Betriebswirtschaftlicher Ursprung des Data Warehousing...

Mehr

Integration Services Übersicht

Integration Services Übersicht Integration Services Übersicht Integration Services Übersicht Integration Services stellt umfangreiche integrierte Tasks, Container, Transformationen und Datenadapter für die En t- wicklung von Geschäftsanwendungen

Mehr

Teil XI Spalten-orientierte DBMSs

Teil XI Spalten-orientierte DBMSs Teil XI Spalten-orientierte DBMSs Spalten-orientierte Datenbankmanagementsysteme 1 Motivation 2 Funktionsweise 3 Erweiterungen 4 Literatur c Sattler / Saake / Köppen Data-Warehouse-Technologien Letzte

Mehr

25.06.2014 TDWI Konferenz DWH Architektur Agilität durch Data Vault Modeling. Twitter: #TDWI #DataVault @DV_Modeling @BLUEFORTE @TDWI_EU

25.06.2014 TDWI Konferenz DWH Architektur Agilität durch Data Vault Modeling. Twitter: #TDWI #DataVault @DV_Modeling @BLUEFORTE @TDWI_EU BLUEFORTE GmbH Dirk Lerner 25.06.2014 TDWI Konferenz DWH Architektur Agilität durch Data Vault Modeling Twitter: #TDWI #DataVault @DV_Modeling @BLUEFORTE @TDWI_EU 1 Elemente des Data Vault (Basic) HUB

Mehr

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann Blatt Nr. 11 Übung zur Vorlesung Einsatz und Realisierung von Datenbanksystemen im SoSe15 Moritz Kaufmann (moritz.kaufmann@tum.de)

Mehr

Data Warehouses und Moderne Betriebliche Anwendungen von Datenbanksystemen

Data Warehouses und Moderne Betriebliche Anwendungen von Datenbanksystemen Data Warehouses und Moderne Betriebliche Anwendungen von Datenbanksystemen (Folien von A. Kemper zum Buch 'Datenbanksysteme') Online Transaction Processing Betriebswirtschaftliche Standard- Software (SAP

Mehr

Zeiterfassung in der Praxis: Von der Eingabe über HTML DB bis zur Auswertung des Cubes

Zeiterfassung in der Praxis: Von der Eingabe über HTML DB bis zur Auswertung des Cubes Zeiterfassung in der Praxis: Von der Eingabe über HTML DB bis zur Auswertung des Cubes Niels de Bruijn MT AG, Ratingen Schlüsselworte HTML DB, OLAP, AWM, Starschema, ETL-Prozess, Datawarehousing, Business

Mehr

Data Warehousing. Fragen des Marketingleiters. Beispiel: : Amazon. Technisch... Amazon weltweit... Datenbank. Aufbau eines DWH OLAP <-> OLTP Datacube

Data Warehousing. Fragen des Marketingleiters. Beispiel: : Amazon. Technisch... Amazon weltweit... Datenbank. Aufbau eines DWH OLAP <-> OLTP Datacube Fragen des Marketingleiters Data Warehousing Wie viele Bestellungen haben wir jeweils im Monat vor Weihnachten, aufgeschlüsselt nach? Aufbau eines DWH OLAP OLTP Datacube Beispiel: : Amazon Technisch

Mehr

Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte Einleitung

Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte Einleitung Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte DWH Projekt, Methodik, Stärken und Schwächen, Übersicht, Weg der Daten,

Mehr

Friedrich-Schiller-Universität Jena

Friedrich-Schiller-Universität Jena Friedrich-Schiller-Universität Jena Seminararbeit zum Thema Data Warehousing Abgrenzung, Einordnung und Anwendungen von Sebastian Hentschel Matrikelnummer 55281 Seminar Data Warehousing Sommersemester

Mehr

Oracle-Statistiken im Data Warehouse effizient nutzen

Oracle-Statistiken im Data Warehouse effizient nutzen Zur performanten Ausführung von Berichten und Ad-hoc-Abfragen eines BI-Systems sind beim Oracle Optimizer aussagekräftige und aktuelle Statistiken für die Tabellen und Indizes von essenzieller Bedeutung.

Mehr

Konzeption eines Master-Data-Management-Systems. Sven Schilling

Konzeption eines Master-Data-Management-Systems. Sven Schilling Konzeption eines Master-Data-Management-Systems Sven Schilling Gliederung Teil I Vorstellung des Unternehmens Thema der Diplomarbeit Teil II Master Data Management Seite 2 Teil I Das Unternehmen Vorstellung

Mehr

Analyse von unstrukturierten Daten. Peter Jeitschko, Nikolaus Schemel Oracle Austria

Analyse von unstrukturierten Daten. Peter Jeitschko, Nikolaus Schemel Oracle Austria Analyse von unstrukturierten Daten Peter Jeitschko, Nikolaus Schemel Oracle Austria Evolution von Business Intelligence Manuelle Analyse Berichte Datenbanken (strukturiert) Manuelle Analyse Dashboards

Mehr

Business Intelligence Data Warehouse. Jan Weinschenker

Business Intelligence Data Warehouse. Jan Weinschenker Business Intelligence Data Warehouse Jan Weinschenker 28.06.2005 Inhaltsverzeichnis Einleitung eines Data Warehouse Data Warehouse im Zusammenfassung Fragen 3 Einleitung Definition: Data Warehouse A data

Mehr

Nach Data Warehousing kommt Business Intelligence

Nach Data Warehousing kommt Business Intelligence Nach Data Warehousing kommt Business Intelligence Andrea Kennel Trivadis AG Glattbrugg, Schweiz Schlüsselworte: Business Intelligence, Data Warehouse Zusammenfassung Data Warehouse bedeutet, dass operative

Mehr

Business Intelligence Praktikum 1

Business Intelligence Praktikum 1 Hochschule Darmstadt Business Intelligence SS 2014 Fachbereich Informatik Praktikumsversuch 1 Prof. Dr. C. Wentzel Dipl. Inf. Dipl. Math. Y. Orkunoglu Datum: 07.05.2014 Business Intelligence Praktikum

Mehr

Fördercontrolling im öffentlichen Bereich Aspekte beim Aufbau eines DWH. Software mit Format.

Fördercontrolling im öffentlichen Bereich Aspekte beim Aufbau eines DWH. Software mit Format. Fördercontrolling im öffentlichen Bereich Aspekte beim Aufbau eines DWH Gerd Schandert, Neuss den 18.03.2014 Agenda 1. Vorstellung Auftraggeber 2. Förderung allgemein 3. Schichten im Data Warehouse 4.

Mehr

Kapitel 4: Data Warehouse Architektur

Kapitel 4: Data Warehouse Architektur Data Warehousing, Motivation Zugriff auf und Kombination von Daten aus mehreren unterschiedlichen Quellen, Kapitel 4: Data Warehousing und Mining 1 komplexe Datenanalyse über mehrere Quellen, multidimensionale

Mehr

Hochschule für Technik, Wirtschaft und Kultur Leipzig. Fakultät Informatik, Mathematik und Naturwissenschaften. Abstract

Hochschule für Technik, Wirtschaft und Kultur Leipzig. Fakultät Informatik, Mathematik und Naturwissenschaften. Abstract Hochschule für Technik, Wirtschaft und Kultur Leipzig Fakultät Informatik, Mathematik und Naturwissenschaften Abstract Oberseminar "Datenbanksysteme - Aktuelle Trends" Hauptspeicherdatenbanken Eingereicht

Mehr

Konzepte zur Datenhaltung für Webseiten in einem Web-Content- Management-System

Konzepte zur Datenhaltung für Webseiten in einem Web-Content- Management-System Konzepte zur Datenhaltung für Webseiten in einem Web-Content- Management-System Web-Content-Management-Systeme () dienen dazu, komplexe Websites zu verwalten und den Autoren einzelner Webseiten möglichst

Mehr

Dokumentation QuickHMI-Schnittstelle. Datenbanken

Dokumentation QuickHMI-Schnittstelle. Datenbanken Dokumentation QuickHMI-Schnittstelle für SQLServer Datenbanken Version 1.0 D-28359 Bremen info@indi-systems.de Tel + 49 421-989703-30 Fax + 49 421-989703-39 Inhaltsverzeichnis Was ist die QuickHMI-Schnittstelle

Mehr

OLAP und Aggregierung

OLAP und Aggregierung Stärkung der SelbstOrganisationsfähigkeit im Verkehr durch I+K-gestützte Dienste Seminar Data Warehousing im Verkehrsbereich Sommersemester 2003 OLAP und Aggregierung von Jan Sandberger Betreuer: Heiko

Mehr

Data Warehouses. Alexander Fehr. 23. Dezember 2002

Data Warehouses. Alexander Fehr. 23. Dezember 2002 Data Warehouses Alexander Fehr 23. Dezember 2002 Inhaltsverzeichnis 1 Einführung 1 1.1 Motivation.............................. 1 1.2 Definitionen.............................. 1 1.3 Abgrenzung von operativen

Mehr

Integration Services - Dienstarchitektur

Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Dieser Artikel solle dabei unterstützen, Integration Services in Microsoft SQL Server be sser zu verstehen und damit die

Mehr

Business Intelligence - Wie passt das zum Mainframe?

Business Intelligence - Wie passt das zum Mainframe? Business Intelligence - Wie passt das zum Mainframe? IBM IM Forum, 15.04.2013 Dr. Carsten Bange, Gründer und Geschäftsführer BARC Ressourcen bei BARC für Ihr Projekt Durchführung von internationalen Umfragen,

Mehr

Oracle 10g revolutioniert Business Intelligence & Warehouse

Oracle 10g revolutioniert Business Intelligence & Warehouse 10g revolutioniert Business Intelligence & Warehouse Marcus Bender Strategisch Technische Unterstützung (STU) Hamburg 1-1 BI&W Market Trends DWH werden zu VLDW Weniger Systeme, mehr Daten DWH werden konsolidiert

Mehr

Technische Seminarreihe Empowering Business Intelligence

Technische Seminarreihe Empowering Business Intelligence PRESSEMITTEILUNG / Veranstaltungshinweis Technische Seminarreihe Empowering Business Intelligence Trivadis bietet für Entwickler, Projektleiter, Datenbank-Administratoren sowie DWHund BI-Interessierte

Mehr

BARC-Studie Data Warehousing und Datenintegration

BARC-Studie Data Warehousing und Datenintegration Ergebnisse der BARC-Studie Data Warehouse Plattformen Dr. Carsten Bange BARC-Studie Data Warehousing und Datenintegration Data-Warehouse -Plattformen und Datenintegrationswerkzeuge im direkten Vergleich

Mehr

DB2 SQL, der Systemkatalog & Aktive Datenbanken

DB2 SQL, der Systemkatalog & Aktive Datenbanken DB2 SQL, der Systemkatalog & Aktive Datenbanken Lehr- und Forschungseinheit Datenbanken und Informationssysteme 1 Ziele Auf DB2 Datenbanken zugreifen DB2 Datenbanken benutzen Abfragen ausführen Den Systemkatalog

Mehr

BI Konsolidierung: Anspruch & Wirklichkeit. Jacqueline Bloemen. in Kooperation mit

BI Konsolidierung: Anspruch & Wirklichkeit. Jacqueline Bloemen. in Kooperation mit BI Konsolidierung: Anspruch & Wirklichkeit Jacqueline Bloemen in Kooperation mit Agenda: Anspruch BI Konsolidierung Treiber Was sind die aktuellen Treiber für ein Konsolidierungsvorhaben? Kimball vs. Inmon

Mehr

Vorwort zur zweiten Auflage...V. Vorwort zur ersten Auflage... VIII

Vorwort zur zweiten Auflage...V. Vorwort zur ersten Auflage... VIII Vorwort zur zweiten Auflage...V Vorwort zur ersten Auflage... VIII 1 Management Support Systeme und Business Intelligence Anwendungssysteme zur Unterstützung von Managementaufgaben...1 1.1 Computergestützte

Mehr

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Andreas Ditze MID GmbH Kressengartenstraße 10 90402 Nürnberg a.ditze@mid.de Abstract: Data Lineage

Mehr

Lehrgebiet Informationssysteme

Lehrgebiet Informationssysteme Lehrgebiet AG Datenbanken und (Prof. Michel, Prof. Härder) AG Heterogene (Prof. Deßloch) http://wwwlgis.informatik.uni-kl.de/ Was sind? Computergestützte Programmsysteme, die Informationen erfassen, dauerhaft

Mehr

Data-Warehouse-Systeme

Data-Warehouse-Systeme Vorlesung im Wintersemester 2008/09 Data-Warehouse-Systeme Dr. Stefanie Rinderle-Ma Institut für Datenbanken und Informationssysteme Universität Ulm stefanie.rinderle@uni-ulm.de Übersicht 1) Einführung

Mehr

INVEST projects. Besseres Investitionscontrolling mit INVESTprojects

INVEST projects. Besseres Investitionscontrolling mit INVESTprojects Besseres Investitionscontrolling mit Der Investitionsprozess Singuläres Projekt Idee, Planung Bewertung Genehmigung Realisierung Kontrolle 0 Zeit Monate, Jahre Perioden Der Investitionsprozess Singuläres

Mehr

Relationale Datenbanken Datenbankgrundlagen

Relationale Datenbanken Datenbankgrundlagen Datenbanksystem Ein Datenbanksystem (DBS) 1 ist ein System zur elektronischen Datenverwaltung. Die wesentliche Aufgabe eines DBS ist es, große Datenmengen effizient, widerspruchsfrei und dauerhaft zu speichern

Mehr

SQL structured query language

SQL structured query language Umfangreiche Datenmengen werden üblicherweise in relationalen Datenbank-Systemen (RDBMS) gespeichert Logische Struktur der Datenbank wird mittels Entity/Realtionship-Diagrammen dargestellt structured query

Mehr

Business Intelligence und Geovisualisierung in der Gesundheitswirtschaft

Business Intelligence und Geovisualisierung in der Gesundheitswirtschaft Business Intelligence und Geovisualisierung in der Gesundheitswirtschaft Prof. Dr. Anett Mehler-Bicher Fachhochschule Mainz, Fachbereich Wirtschaft Prof. Dr. Klaus Böhm health&media GmbH 2011 health&media

Mehr

In.Memory im SQL Server 2014 im Vergleich mit SAP Hana im Praxistest

In.Memory im SQL Server 2014 im Vergleich mit SAP Hana im Praxistest In.Memory im SQL Server 2014 im Vergleich mit SAP Hana im Praxistest Synopsis Darmstadt 13.-14.05.2014 Guido Jacobs, Microsoft Tobias Maier & Dr. Benjamin Kettner, ixto GmbH Microsoft SQL Server 2014 //

Mehr

Big Data in Marketing und IT

Big Data in Marketing und IT Big Data in Marketing und IT Chancen erkennen, Strategien entwickeln und Projekte erfolgreich umsetzen T-Systems Hacker Day 30. September 2015 Prof. Dr. Alexander Rossmann Reutlingen University Big Data

Mehr

Anwendertage WDV2012

Anwendertage WDV2012 Anwendertage WDV2012 28.02.-01.03.2013 in Pferdingsleben Thema: Business Intelligence mit Excel 2010 Referent: Dipl. Wirtsch.-Inf. Torsten Kühn PRAXIS-Consultant Alles ist möglich! 1 Torsten Kühn Dipl.

Mehr

vfabric-daten Big Data Schnell und flexibel

vfabric-daten Big Data Schnell und flexibel vfabric-daten Big Data Schnell und flexibel September 2012 2012 VMware Inc. All rights reserved Im Mittelpunkt: Daten Jeden Morgen wache ich auf und frage mich: Wie kann ich den Datenfluss optimieren,

Mehr

Event Stream Processing & Complex Event Processing. Dirk Bade

Event Stream Processing & Complex Event Processing. Dirk Bade Event Stream Processing & Complex Event Processing Dirk Bade Die Folien sind angelehnt an eine Präsentation der Orientation in Objects GmbH, 2009 Motivation Business Activity Monitoring Sammlung, Analyse

Mehr

Data Warehousing mit Oracle

Data Warehousing mit Oracle Data Warehousing mit Oracle Business Intelligence in der Praxis von Claus Jordan, Dani Schnider, Joachim Wehner, Peter Welker 1. Auflage Hanser München 2011 Verlag C.H. Beck im Internet: www.beck.de ISBN

Mehr

DATA WAREHOUSE. Big Data Alfred Schlaucher, Oracle

DATA WAREHOUSE. Big Data Alfred Schlaucher, Oracle DATA WAREHOUSE Big Data Alfred Schlaucher, Oracle Scale up Unternehmensdaten zusammenfassen Noch mehr Informationen aus Unternehmens- Daten ziehen! Datenmengen, Performance und Kosten Daten als Geschäftsmodell

Mehr

Einleitung. Literatur. Pierre Fierz. Architektur von Datenbanksystemen. Physische Datenunabhängigkeit. Der Datenbank Administrator (DBA) 1.

Einleitung. Literatur. Pierre Fierz. Architektur von Datenbanksystemen. Physische Datenunabhängigkeit. Der Datenbank Administrator (DBA) 1. Inhalt der Vorlesung Literatur 1 Datenmodellierung (Entity-Relationship Modell) 2 Das relationale Modell 3 Relationenalgebra 4 Datenbanksprache (SQL) 5 Normalisierung 6 Vom ERM zum Datenbankschema 7 Routinen

Mehr

DWH Szenarien. www.syntegris.de

DWH Szenarien. www.syntegris.de DWH Szenarien www.syntegris.de Übersicht Syntegris Unser Synhaus. Alles unter einem Dach! Übersicht Data-Warehouse und BI Projekte und Kompetenzen für skalierbare BI-Systeme. Vom Reporting auf operativen

Mehr

Microsoft Dynamics NAV Technische Details

Microsoft Dynamics NAV Technische Details Microsoft Dynamics NAV Technische Details INHALT Microsoft Dynamics NAV Technische Details........................................ [3] Infrastruktur.............................................. [3] Systemanforderungen.....................................

Mehr

Data Warehouse. für den Microsoft SQL SERVER 2000/2005

Data Warehouse. für den Microsoft SQL SERVER 2000/2005 Warehouse für den Microsoft SQL SERVER 2000/2005 Begriffe 1 DWH ( Warehouse) ist eine fachübergreifende Zusammenfassung von Datentabellen. Mart ist die Gesamtheit aller Datentabellen für einen fachlich

Mehr

Möglichkeiten für bestehende Systeme

Möglichkeiten für bestehende Systeme Möglichkeiten für bestehende Systeme Marko Filler Bitterfeld, 27.08.2015 2015 GISA GmbH Leipziger Chaussee 191 a 06112 Halle (Saale) www.gisa.de Agenda Gegenüberstellung Data Warehouse Big Data Einsatz-

Mehr

Asklepius-DA Die intelligente Technologie für die umfassende Analyse medizinischer Daten Leistungsbeschreibung

Asklepius-DA Die intelligente Technologie für die umfassende Analyse medizinischer Daten Leistungsbeschreibung Asklepius-DA Die intelligente Technologie für die umfassende Analyse medizinischer Daten Leistungsbeschreibung Datei: Asklepius DA Flyer_Leistung_2 Seite: 1 von:5 1 Umfassende Datenanalyse Mit Asklepius-DA

Mehr

A Platform for Complex Event Processing

A Platform for Complex Event Processing A Platform for Complex Event Processing Einführung Business Process Technology Prof. Dr. Mathias Weske Matthias Kunze Nico Herzberg Business Process Technology Seit 2001 Untersuchung realer Probleme des

Mehr

The integration of business intelligence and knowledge management

The integration of business intelligence and knowledge management The integration of business intelligence and knowledge management Seminar: Business Intelligence Ketevan Karbelashvili Master IE, 3. Semester Universität Konstanz Inhalt Knowledge Management Business intelligence

Mehr

Institut für Wirtschaftswissenschaftliche Forschung und Weiterbildung GmbH Institut an der FernUniversität in Hagen MUSTERLÖSUNG

Institut für Wirtschaftswissenschaftliche Forschung und Weiterbildung GmbH Institut an der FernUniversität in Hagen MUSTERLÖSUNG Institut für Wirtschaftswissenschaftliche Forschung und Weiterbildung GmbH Institut an der FernUniversität in Hagen Name Straße PLZ, Ort IWW Studienprogramm Aufbaustudium 1. Musterklausur IT-gestützte

Mehr

Agenda. Themenblock: Data Warehousing (I) Referenzarchitektur. Eigenschaften eines Data Warehouse. Einführung Data Warehouse Data Access mit SQL

Agenda. Themenblock: Data Warehousing (I) Referenzarchitektur. Eigenschaften eines Data Warehouse. Einführung Data Warehouse Data Access mit SQL Themenblock: Data Warehousing (I) Praktikum: Data Warehousing und Data Mining 2 Eigenschaften eines Data Warehouse Referenzarchitektur Integrierte Sicht auf beliebige Daten aus verschieden Datenbanken

Mehr

Corporate Performance Management als Weiterentwicklung von Business Intelligence

Corporate Performance Management als Weiterentwicklung von Business Intelligence Martin Kobrin Corporate Performance Management als Weiterentwicklung von Business Intelligence Grundlagen, Implementierungskonzept und Einsatzbeispiele Diplomica Verlag Martin Kobrin Corporate Performance

Mehr

Data Warehousing und Data Mining

Data Warehousing und Data Mining Data Warehousing und Data Mining Architektur und Komponenten von Data Warehouses Ulf Leser Wissensmanagement in der Bioinformatik Inhalt dieser Vorlesung Architektur Komponenten ETL Ulf Leser: Data Warehousing

Mehr

Umsetzung der Anforderungen - analytisch

Umsetzung der Anforderungen - analytisch Umsetzung der Anforderungen - analytisch Titel des Lernmoduls: Umsetzung der Anforderungen - analytisch Themengebiet: New Economy Gliederungspunkt im Curriculum: 4.2.5.5 Zum Inhalt: In diesem Modul wird

Mehr

1 Einführung. Unbekannte Begriffe: Business Intelligence, Knowledge Management, Unternehmensportale, Information Warehouse.

1 Einführung. Unbekannte Begriffe: Business Intelligence, Knowledge Management, Unternehmensportale, Information Warehouse. 1 Einführung mysap Business Intelligence stellt mit Hilfe von Knowledge Management die Verbindung zwischen denen, die etwas wissen und denen, die etwas wissen müssen her. mysap Business Intelligence integriert

Mehr

Geschäftsprozessmodellierung und implementierung am Beispiel SAP ERP

Geschäftsprozessmodellierung und implementierung am Beispiel SAP ERP Geschäftsprozessmodellierung und implementierung am Beispiel SAP ERP V04 02. Mai 2011, 16.15-17.45 Uhr, ITS-Pool nur zugelassene Teilnehmer Niedersächsisches Hochschulkompetenzzentrum für SAP (CCC) Aktuelles

Mehr