Seminar. Data Warehousing im Verkehrsbereich. Grundlagen und Architektur

Größe: px
Ab Seite anzeigen:

Download "Seminar. Data Warehousing im Verkehrsbereich. Grundlagen und Architektur"

Transkript

1 Stärkung der SelbstOrganisationsfähigkeit im Verkehr durch I+K-gestützte Dienste Seminar Data Warehousing im Verkehrsbereich Sommersemester 2003 Grundlagen und Architektur Bearbeiter: Ting Zheng Betreuer: Heiko Schepperle Datum: 20. Juli 2003

2

3 Inhaltsverzeichnis 1 Einleitung 1 2 Grundlage Definition von Data Warehouse Abgrenzungen Abgrenzung aus der Perspektive der Anwendung Abgrenzung aus der Perspektive der Datenhaltung Abgrenzung aus der Perspektive des Entwicklungsprozesses Anwendungsbereich Referenzarchitektur Aspekte einer Referenzarchitektur Beschriebung der Referezarchitektur Datenquellen Auffinden der Quelldaten Anforderung an die Qualität der Quelldaten Klassifikation der Quelldaten Datenbeschaffungsbereich Monitor Arbeitsbereich Extraktionskomponente Transformationskomponente Ladekomponente Basisdatenbank Data Warehouse & Data Mart Data Mart Data-Warehouse-Architektur Metadaten und Repositorium Zusammenfassung 16 5 Literaturverzeichnis 17 i

4

5 1 Einleitung Data-Warehouse-Systeme repräsentieren ein analyseorientiertes Informationsystem einer Organisation. Die Qualität, Integrität und Konsistenz des zu Grunde liegenden Datenmaterials, das aus einer Vielzahl heterogener Quellsysteme stammt, müssen zunächst garantiert werden. Eine einheitliche Sichtweise auf Daten eines Unternehmens wird dabei durch eine Vielzahl von Faktoren wie beispielsweise die voranschreitende Globalisierung und Deregulierung der Märkte, anspruchsvollere Kunden, verschärfter Konkurrenzkampf auf Seite der Lieferanten und eine im Allgemeinen deutliche Verkürzung der Produktlebenszyklen erzwungen. Zur systemübergreifenden Auswertung werden die Daten, die verteilt in entwickelten Anwendungen in einer heterogenen Systemlandschaft eines Unternehmens abgespeichert sind, gemäß der Idee eines Data Warehouse periodisch aus einer Vielzahl von Datenquellen extrahiert, bereinigt, integriert und in die konsolidierten Datenbasis eines Data-Warehouse-Systems überführt. Der Data Warehouse Gedanke entstand aus verschiedenen Sichtweisen. Folgende Perspektiven lassen sich unterscheiden: Betriebswirtschaftliche Sichtweise Data-Warehouse-Systeme werden in einem Unternehmen eingesetzt, um aus einem operativen System eine von Detaildaten abstrahierte und historisierte Sichtweise auf das jeweilige Unternehmen ableiten zu können. Das klassische Managment Information System kann dabei als Vorläufer einer Data-Warehouse-Anwendung gesehen werden. Statistische Sichtweise Die Verwaltung empirisch erfasster Kennzahlen weist eine lange Tradition in der elektronischen Datenverarbeitung auf und genießt immer noch einen hohen Stellenwert. Die Statistiken als Resultat komplexer Analysen und Auswertung statischer Modelle sind dabei sowohl im Bereich der öffentlichen Hand als auch im privatwirtschaftlichen Sektor von zentraler Bedeutung. Integrative Sichtweise Data-Warehouse-Systeme leisten durch ihre Integrationsarbeit einen großen Beitrag, die Vision eines unternehmensweiten Datenmodells und einer unternehmensweiten Datenversorgung voranzubringen. 1

6 2 Grundlage 2.1 Definition von Data Warehouse Eine Offizielle Definition von Data Warehouse gibt es bis heute nicht. Die am häufigsten zitierte Definition nach Bill Inmon([Inmo96]) lautet: Definition: Data-Warehouse-System A data warehouse is a subject-oriented, integrated, time-varying, non-volatile collection of data in support of the management s decision-making process. Ein Data Warehouse hat nach dieser Definition also vier Eigenschaften, die alle der Entscheidungsunterstützung dienen. Hier werden die Eigenschaften kurz skizziert: Fachorientierung Der Zweck der Datenbasis liegt nicht mehr auf der Erfüllung einer Aufgabe z.b. eine Personaldatenverwaltung, sondern auf der Modellierung eines spezifischen Anwendungsziels. Integrierte Datenbasis Die Datenverarbeitung findet auf integrierten Daten aus mehreren Datenbanken statt. Nicht flüchtige Datenbasis Die Datenbasis ist als stabil zu betrachten. Daten, die einmal in das Data Warehouse eingebracht wurden, werden kaum entfernt oder geändert. Historische Daten Die Verarbeitung der Daten ist so angelegt, dass vor allem Vergleiche über die Zeit stattfinden. Es ist dazu unumgänglich, Daten über einen längeren Zeitraum zu halten. Der Data-Warehouse-Prozess, auch Data Warehousing genannt, beschreibt den dynamischen Vorgang, angefangen beim Datenbeschaffungsprozess über das Speichern bis zur Analyse der Daten, d.h. den Fluss und die Verarbeitung der Daten aus den Datenquellen, bis zum Analyseergebnis beim Anwender. Ein Data-Warehouse-System wird als eine Sammlung von Systemkomponenten 1 und einzelnen riesigen Datenbanken verstanden. Ein Data Warehouse ist also mehr als die Summe seiner Komponenten, d.h. erst mit dem Data-Warehouse-System kann es seine Aufgaben erfüllen. 2.2 Abgrenzungen Um den Data-Warehouse-Systeme gut zu verstehen, muss man es von traditionellen Informationssystemen abgrenzen Abgrenzung aus der Perspektive der Anwendung Ein wesentlicher Unterschied zwischen einen Data-Warehouse-System und einem transaktionalen 2 Anwendungssystem zur Abwicklung des Alltagsgeschäfts in einem Unternehmen ist bereits in dem Anwendbarkreis der jeweiligen Systeme zu sehen. Aus einer technischen Sichtwei- 1 z.b. Quelldaten, Extraktionskomponenten, Transformationskomponenten usw. siehe Kapitel 3 2 Traditionelle Informationssystem ist überlich ein transaktionales System. 2

7 KAPITEL 2. GRUNDLAGE 2.2. ABGRENZUNGEN se lässt sich eine Abgrenzung klassischer datenbankbasierter Anwendungssysteme und Data- Warehouse-basierter Analysesysteme hinsichtlich der Interaktion zwischen Benutzer und System ausmachen. Während im transaktionalen Betrieb kurze Lese- und Schreibtransaktionen meist einzelne Datensätze lesen oder modifizieren, d.h. einfügen, löschen oder ändern, überwiegt im Analysebetrieb der Lesebetrieb mit Bezug auf eine Vielzahl einzelner Datensätze, die durch Anwendung statistischer Verfahren zu charakteristischen Aussagen verdichtet werden. Außerdem ist die Anzahl tatsächlicher und potenzieller Nutzer des jeweiligen Systems zu betrachten. Während transaktional arbeitende Systeme tatsächliche und potenzielle Nutzer im Tausender- Bereich zählen, sind klassische Data-Warehouse-Systeme bedingt durch die komplexen und aufwändig auszuwertenden Anfragen nur auf einen deutlich kleineren Nutzerkreis zugeschnitten, so dass auch die Gesamtzahl der Anwender pro Installation typischerweise deutlich geringer ausfällt als bei klassischen transaktionalen Systemen. Die Tabelle 2.1 führt die Unterschiede aus der Perspektive der Anwendung auf. Tabelle 2.1: Vergleich Aus Perspektive der Anwendung Transaktional ausgerichtete Analytisch orientierte Anwendungs- Data-Warehouse- systeme Systeme Anwendertyp Sacharbeiter Manager Controller Analysten Anwenderanzahl sehr viele wenig Interaktionstyp Lesen Einfügen Ändern Lesen Hinfügen Interaktionsdauer kurz periodisch Anfragestruktur einfach strukturiert komplex Anzahl gleichzeitiger sehr viele wenige Zugriffe Anwenderzahl sehr viele wenige Abgrenzung aus der Perspektive der Datenhaltung Ein transaktionales System und ein Data Warehouse sind bei einem Versuch der den Anwendungsszenarien hinsichtlich der Datenhaltung bzw. Datenverarbeitung aus der Perspektive des Datenbanksystems Unterschiede in einer Vielzahl von Eigenschaften erkennbar. Daten eines Data-Warehouse-Systems werden aus einer Vielzahl heterogener Datenquellen extrahiert, bereinigt und in einer konsolidierten Datenbasis integriert. Demgegenüber steht im Kontext transaktionale Informationssystem die Verwaltung einer logisch zentralisierten Datenbasis mit originären und zeitaktuellen Daten. Das Datenvolumen und die Antwortszeit eines Data-Warehouse- Systemssiehen im Vergleich mit einem transaktionalen System riesig aus. Der Vergleich wird in der Tabelle 2.2 zusammenfassend angezeigt Abgrenzung aus der Perspektive des Entwicklungsprozesses Obwohl auf den ersten Blick der Aufbau und Betrieb eines Data-Warehouse-Systems in einer Organisation wie ein normales IT-Projekt erscheint, sind - bedingt durch die besonderen Eigenschaften des Data-Warehouse-Ansatzes - weiterreichende Unterschiede im Entwicklungsprozess auszumachen. 3

8 2.3. ANWENDUNGSBEREICH KAPITEL 2. GRUNDLAGE Transaktional ausgerichtete Analytisch orientierte Anwendungs- Data-Warehouse- systeme Systeme Datenquellen zentraler Datenbestand mehrere unabhängige Datenquellen Schemaentwurf anfrageneutrale Datenmodellierunmodellierung analysebezogene Daten- Eigenschaften originär abegleitet/konsolidiert des Datenbestands zeitaktuell historisiert autonom dynamisch integriert stabil teilweise aggregiert Datenvolumn Megabyte - Gigabyte Gigabyte - Terabyte Typische Antwortzeit ms - s s - min Tabelle 2.2: Vergleich aus Perspektive der Datenhaltung Mitwirkung der Fachabteilung Der Erfolg eines Data-Warehouse-Systems hängt von der aktiven Mitarbeit der einzelnen Organisationseinheiten ab. Diese Abhängigkeit betrifft sowohl die Dateneingangsseite als auch die Nutzung der integrierten und konsolidierten Datenbestände auf der Datenausgangseite. Durchsetzen eines Qualitätsanspruchs Wegen der Heterogenität der Quelldaten muss bereits beim Entwurfsprozess ein Konsens über akzeptable Datenqualität mit den Datenlieferanten herbeigeführt werden. Gemeinsames Sprachverständnis Bevor überhaupt systemtechnische Angelegenheiten diskutiert werden, muss entweder Einigung auf eine gemeinsame Terminologie oder Klarheit über die jeweils unterschiedlichen Interpretationen von Fachbegriffen hergestellt sein. Nachvollziehbarkeit Die Nachvollziehbarkeit durch Dokumentation und Metadatenverwaltung im Kontext des Data Warehousing ist wichtiger als sie in klassischen und fachabteilungsbezogenen IT- Projekten. Für jedes Datum einer Data-Warehouse-Datenbasis muss der Anspruch erfüllt werden, den Weg vom Quellsystem über Extraktion, Transformation, Hochrechnung bis ins Data Warehouse detailliert verfolgen zu können. Vom Produkt- zum Prozess-Gedanken Der Aufbau und Betrieb eines Data-Warehouse-Systems ist als andauernder und iterativer Prozess zu verstehen, indem Lösungen neue Anforderungen wecken und diese wiederum realisiert werden. Es gibt keinen endgültigen Fertigstellungszeitpunkt und es kann keinesfalls als Installation (mit geringer Anpassung) eines Produkts verstanden werden. 2.3 Anwendungsbereich Der Triebfeder hinter dem Data Warehouse Gedanken ist die Analysierbarkeit der Daten: eine homogene und itegrierte Datenbasis, geeignet aufbereitet, um eine effiziente und zielorientierte Analyse durchzuführen. Im Folgenden werden drei häufige Anwendungsbereiche aufgezählt. 4

9 KAPITEL 2. GRUNDLAGE 2.3. ANWENDUNGSBEREICH Betreibswirtschaftliche Anwendungsgebiete Die häufigsten Einsatzfelder finden sich zurzeit hier. Es gibt eigentlich keinen Bereich eines Unternehmens, in welchem auf Daten und Informationen für eine erfolgreiche Abwicklung der Geschäftsprozesse verzichtet werden kann. In diesem Bereich gibt es die vier Untergebiete: Informationsbereitstellung, Analyse, Planung und Kampagnenmanagement (siehe: [BaGü00]). Mit den dargestellten Informationen können qualifizierte Anwender Analysen durchführen und weitergehende Erkenntnisse gewinnen. Wissenschaftliche Anwendungsgebiete Aus diesem Bereich stammen auch die technischen Wurzeln der Data-Warehouse-Technologie, vor allem im Hinblick auf die datenbanktechnische Speicherung und Verarbeitung. Bei wissenschaftlichen, empirischen Untersuchungen fallen oft große Mengen an Daten, beispielsweise Messwerte, an. Ein beispielhafte Projekt lautet Earth Observing System[Mich91]. Technische Anwendungsgebiete Auch in technisch orientierten Anwendungsfeldern gibt es viele mögliche Verwendungszwecke. Es seien hier einige wenige angedeutet. Die dem Data Warehousing zugrunde liegenden Mechanismen und Prinzipien gelten hier entsprechend. Ein Unternehmen des produzierenden Gewerbes kann beispielsweise eine Stoff- oder Materialdatenbank aufbauen, um die in Produkten befindlichen Inhaltsstoffe oder verwendeten Materalien zu dokumentieren. Damit ist es möglich, bei Rückfrufaktionen oder Gewährleistungsfällen die betroffenen Chargen zu ermitteln oder eventuell verantwortliche Lieferanten ausfindig zu machen sowie Mängelquoten oder Ausfallwahrscheinlichkeiten zu analysieren (siehe auch [BaGü00] in Kapitel 11.5). 5

10 3 Referenzarchitektur 3.1 Aspekte einer Referenzarchitektur Im Folgenden wird ein Referenzmodell für die Architektur von Data-Warehouse-Systemen, kurz Referenzarchitektur (siehe [BaGü00])genannt, beschrieben.eine Referenzarchitektur besteht aus zwei Teilen: dem Referenzmodell und einem Sachverhalten, auf den es angewandet wird. Der Sachverhalt, auf den dieses Referenzmodell hier angewendet wird, ist die Architektur von Data- Warehouse-Systemen. Die Architektur von Data-Warehouse-Systemen versteht sich als zusammenen Aufbau mehrerer Schichten. 3.2 Beschriebung der Referezarchitektur Abbildung 3.1: von Data-Warehouse-Systemen Die Abbildung 3.1 spiegelt die Existenz und den Zusammenhang der verschiedenen Operanden und Operationen mit ihren Aufbereitungs- und Analysefunktionen sowie den notwendigen Daten- und Kontrollfluss zwischen diesen Komponenten wider. Unter Datenfluss ist sowohl der 6

11 KAPITEL 3. REFERENZARCHITEKTUR 3.3. DATENQUELLEN Datenfluss von der Datenquelle zum Data Warehouse zu verstehen als auch der Metadatenfluss zwischen den Repositorium (siehe 3.7) und dem Metadatenmanager. In einer Top-Down - und auswertungsorientierten Betrachtung wird eine Datenbank als Data Warehouse bezeichnet, wenn eine einzelne - von anderen unabhängige - Anwendersicht wiedergegeben wird. Dies bedeutet, dass die Anwendungsanforderungen bei der Modellierung (z.b. mittels einer multidimensionalen Modellierung) mit verankert werden und dadurch eine anwenderspezifische Analyse unterstützt wird. Diese Datenbank berücksichtigt aber noch nicht alle Anforderungen, z.b. die Flexibilität, da verschiedene multidimensionale Modelle häufig nicht mehr vereinbar sind. Deshalb ist es notwendig, zusätzlich eine flexible und nicht auswertungsorientierte Datenbank bereitzustellen. In einer Bottom-up - Betrachtung wird die Integration, Konsistenzsicherung und Auswertungsflexibilität präferiert und die Datenbank, die eine eher auswertungsneutrale und erweiterbare Sicht bietet, als Data Warehouse bezeichnet. Das Data Warehouse ähnelt dem Ansatz einer replizierten, föderierten Datenbank ohne einen modifizierenden Zugriff. Die vom Data Warehouse abhängigen/unabhängig, multidimensional modellierten und auswertungsorientierten verteilten Datenbanken werden Data Mart genannt. In den folgenden Abschnitten werden die wichtigsten Komponenten eines Data-Warehouse- Systems vorgestellt. 3.3 Datenquellen Die Datenquelle ist die Komponente, von der die datenflussorientierte Betrachtung ausgeht. Sie steht als Stellvertreter für mehrere zu integrierende, meist heterogene, reale Datenquellen. Obwohl die Datenquellen nicht zum Data-Warehouse-System gehören, bauen sie die Grundlage für das Data-Warehouse-System auf Auffinden der Quelldaten Die in den Datenquellen enthaltenden Daten sowie deren Beschreibung werden zusammenfassend Quelldaten genannt. Die für das Data Warehouse geeigneten Quelldaten müssen in entsprechender Weise ausfindig gemacht werden. Wenn es mehrere Datenquellen für Data-Warehouserelevante Sachverhalte aus bestimmten Entitätstypen oder einzelnen Attributen gibt, ist die jeweils geeignete Quelle auszuwählen; Die Auswahl soll die folgenden Faktoren in Betracht ziehen: Der Zweck des Data Warehouse Datenquellen sollen gemäß des Zwecks des Data Warehouse ausgewählt werden. Die Qualität der Quelldaten An die Beschaffenheit der Quelldaten werden vor allem bestimmte Forderungen gestellt. Dieses Thema wird im Abschnitt weiter behandelt. Die Verfügbarkeit (rechtlich, sozial, organisatorisch, technisch) Verfügbarkeit der Datenquellen ist nicht automatisch gegeben. Der Preis für den Erwerb der Quelldaten Insbesondere kosten die externen Daten Geld. Man muss sich daran überlegen, ob es sich lohnt, solche Daten zu erwerben Anforderung an die Qualität der Quelldaten In Data-Warehouse-Systemen kommt die Subjektivität der Datenqualität besonders zum Tragen, da dort die Daten für verschiedene Zwecke verwendet werden können. In diesem Zusammenhang wird noch auf die besondere Rolle der Anwender eingegangen. Datenqualität ist abhängig 7

12 3.3. DATENQUELLEN KAPITEL 3. REFERENZARCHITEKTUR davon, wie die Anwender die Daten interpretieren. Obwohl die Datenqualität durch subjektive Kriterien bestimmt ist, sind die Ursachen für Datenqualitätsprobleme überlicherweise objektiv und messbar. Die folgende Liste führt die exemplarischen Qualitätseinzelforderung auf: 1. Konsistenz Die primären Daten 1 sollen widerspruchsfrei sein. Die Metadaten sollen mit den primären Daten zusammenpassen. Die Metadaten sollen auch widerspruchsfrei sein. 2. Korrektheit Die Korrektheitsanforderung wird angewandt auf die primären Daten und deren inhaltliche Beschreibung, somit auf die Abbildung von Sachverhalten in der Realität. 3. Vollständigkeit Vollständigkeit bezieht sich auf die Existenz eines Datenmodells, das hinreichend viele Attribute für die Gleichheit von Realobjekten und Datenobjekt zur Verfügung stellt. 4. Genauigkeit und Granularität Ein Attribut soll genug Detaillierungsgrad haben, um die Gleichheit bzw. Verschiedenheit zu beschreiben. 5. Zuverlässigkeit und Glaubwürdigkeit Die Beschreibung der Beschaffung und Erfassung von Quelldaten muss standardisiert werden. Die Regel, wann, wo und wie die Quelldaten erfasst werden, muss festgelegt werden. 6. Verständlichkeit Die primären Daten sollen inhaltlich und technisch verständlich beschrieben werden. 7. Verwendbarkeit und Relevanz Die erfassten Quelldaten sollen weiterverarbeitbar sein und dem vorgesehenen Zweck dienen Klassifikation der Quelldaten Eine Klassifikation der Quelldaten dient vor allem als Mittel zur Beschreibung. Hierdurch werden die Daten strukturiert, die Übersicht verbessert und das Spektrum der Daten demonstriert. Die Quelldaten lassen sich anhand folgender Kriterien klassifizieren: 1. Herkunft: Interne Daten oder Externe Daten. 2. Zeit: historische Daten oder aktuell verfügbare Daten. 3. Nutzungsebene: Ebene der primären Daten oder Ebene der beschreibenden Daten/Metadaten. 4. Inhalt/Datentyp nach semantischen Aspekten: Zahl, Maßeinheit, Zeichenkette, Code, Audiosequenz Videosequenz usw. 5. Darstellung/Datentyp nach technischen Aspekten: numerisch, alphanumerisch, date/time, boolean/logical, binary usw. 6. Sprache und Zeichensatz: Deutsch, Englisch, Chinesisch usw. 1 die in Quelldaten enthaltenden Daten. 8

13 KAPITEL 3. REFERENZARCHITEKTUR 3.4. DATENBESCHAFFUNGSBEREICH 7. Technischer Zeichensatz: One-Byte-Code, Double-Byte-Code usw. 8. Schreiborientierung: von links nach rechts, bidirektional, vertikal usw. 9. Schutzwürdigkeit je nach Vertraulichkeitsgrad: Schutz erforderlich oder nicht erforderlich 3.4 Datenbeschaffungsbereich Datenbeschaffungsbereich besteht aus den fogenden Komponenten: Monitor, Arbeitsbereich, Extraktionskomponente, Transformationskomponente und Ladekomponente. In ihm erfolgt die Integration der Quelldaten. Der Data-Warehouse-Manager spielt hier eine wichtige Rolle. Alle Datenbeschaffungsprozesse stehen unter seiner Kontrolle. Die wichtigsten Aufgaben des Data- Warehouse-Managers in diesem Zusammenhang ist die Initiierung des Datenbeschaffungsprozesses. Der Beginn des Datenbeschaffungsprozesses kann in verschiedener Art und Weise vom Data-Warehouse-Manager ausgelöst werden, z.b: In regelmäßigen Zeitintervallen, beispielsweise jede Woche oder am Ende eines Monats. Zu diesem Zeitpunkt wird die Extraktion von Daten aus den verschiedenen Quellen und das anschließende Schreiben in den Arbeitsbereich durch den Data-Warehouse-Manager ausgelöst. Explizites Verlangen des Data-Warehouse-Administrators. (Fast)Echtzeit-Aktualisierung: alle Änderungen in den Quellsystemen werden möglichst zeitnah in die Basisdatenbank zu propagieren. Aktualisierung in Abhängigkeit einer Änderungsqualität: Bei Erreichen einer definierten Anzahl von Änderungen werden diese in die Basisdatenbank übertragen. Nachdem der Data-Warehouse-Manager den Beginn des Ladeprozesses ausgelöst hat, sorgt er dafür, dass die einzelnen Aufgaben und Schritte des Datenbeschaffungsprozesses wie Transformation, Integration, Bereinigung usw. korrekt und in der richtigen Reihenfolge ausgeführt werden Monitor Ein Monitor ist für das Entdecken von Datenmanipulationen in einer Datenquelle zuständig. Die konkrete Funktionsweise eines Monitors hängt unmittelbar von den Charakteristika der angeschlossenen Datenquelle sowie von den Anforderungen der Analysekomponenten ab. Deshalb existiert im Allgemeinen ein Monitor pro Datenquelle. Es können folgende Monitoring-Strategien unterschieden werden: Trigger-basiert: Handelt es sich bei der Datenquelle um ein Datenbanksystem, welches aktive Mechanismen in Form von Triggern unterstützt, kann das Monitoring wie folgt vorgenommen werden: Jede Datenmanipulation löst einen Trigger aus, der das geänderte Tupel in eine Datei oder eine andere Datenstruktur schreibt. Replikationsbasiert: Moderne Datenbankmanagementsysteme bieten Replikationsdienste an. Diese Dienste können so spezifiziert werden, dass sie geänderte Tupel in spezielle Tabellen schreiben. 9

14 3.4. DATENBESCHAFFUNGSBEREICH KAPITEL 3. REFERENZARCHITEKTUR Zeitstempel-basiert: Jedem Datensatz ist ein Zeitstempel zugeordnet, der im Fall einer Änderung des Datensatzes auf den Zeitpunkt der Änderung gesetzt wird. Anhand der Zeitstempel kann später entschieden werden, welche Datensätze sich nach dem Zeitpunkt der letzten Extraktion geändert haben. Temporale Datenbankmanagementsysteme bieten eine explizite Unterstützung der Zeitdimension an, sind aber bisher nicht über den Forschungsstatus hinausgekommen. Log-basiert: In diesem Fall wird die Fähigkeit von Datenbankmanagementssystemen ausgenutzt, vorgenommene Transaktionen in einer Log-Datei zu protokollieren. Durch Analyse einer solchen Log-Datei kann ermittel werden, welche Daten sich geändert haben. Snapshot-basiert: Bei dieser Variante wird der Datenbestand einer Quelle in periodischen Zeitabständen in eine Datei, den sog. Snapshot, geschrieben. Durch einen Vergleich von Snapshots können Änderungen identifiziert werden Arbeitsbereich Den Arbeitsbereich kann man als einen Zwischenspeicher betrachten, wo die Datenbeschaffungsprozessen durchgeführt werden. Als Datenbeschaffungsbereich werden zusammenfassend diejenigen Komponenten eines Data-Warehouse-Systems bezeichnet, die funktional zwischen den Datenquellen und der Basisdatenbank angesiedelt sind. Der Datenbeschaffungsbereich dient also vornehmlich der Integration von Daten aus heterogenen Quellen und wird typischerweise vom Administrator des Daten-Warehouse-Systems verwaltet. Im Arbeitsbereich des Datenbeschaffungsbereichs werden Daten auf ihrem Weg von den Datenquellen in die Basisdatenbank temporär zwischengespeichert. Notwendige Datentransformationen können dann direkt auf diesem Zwischenspeicher ausgeführt werden, ohne dass die Datenquellen oder die Basisdatenbank beeinflusst werden. Die drei Komponenten: Extraktionskomponente, Transformationskomponente und Ladekomponente, die auch häufig als ETL-Komponenten zusammengefasst, haben eine direkte Verbindung zum Arbeitsbereich. Im Folgenden werden sie kurz vorgestellt Extraktionskomponente Die Extraktionskomponente ist für die Übertragung von Daten aus einer Datenquelle in den Arbeitsbereich verantwortlich. Je nach verwendeter Monitoring-Strategie gestaltet sich die Extraktion unterschiedlich: Bei der Trigger-basierten Variante sind die geänderten Datensätze aus den entsprechenden Dateien auszulesen, bei Verwendung der Replikationsdienste können sie per SQL-Anfrage aus den Replikationstabellen selektiert werden. Die Zeitstempel-basierte Variante erfordert lediglich die Selektion von Datensätzen anhand ihres Zeitstempels. Die Log- bzw. Snapshotbasierte Strategien führen den Vergleich von Logdateien bzw. Snapshot durch. Werden die als geändert identifizierten Tupel beispielsweise in eine Datei eingetragen, so ist diese Datei zu importieren. Eine Extraktionskomponente hat außerdem die Aufgabe, die Auswahl von Quellen bzw. von Ausschnitten aus Quellen, die in das Data-Warehouse-System importiert werden sollen, zu steuern. Dazu ist Wissen über die später auf den Daten durchzuführenden Auswertungen erforderlich, da diese unter Umständen spezielle Anforderungen an die Referenz und Beschaffenheit von Daten stellen. Die Festlegung von Zeitpunkten, an denen Extraktionen durchgeführt werden sollen, hängt entschiedend von der Semantik der Date bzw. von den auf diesen Daten durchzuführenden Auswertungen ab. Es gibt vier möglichen Strategien: Periodische Extraktionen, Extraktionen auf Anfrage, Ereignisgesteuerte Extraktion, Sofortige Extraktionen bei Änderung (vergleiche mit auf der Seite 9). 10

15 KAPITEL 3. REFERENZARCHITEKTUR 3.4. DATENBESCHAFFUNGSBEREICH Transformationskomponente Bevor die extrahierten Daten in die Basisdatenbank geladen werden können, müssen sie in einen geeigneten Zustand eingebracht werden. Dies betrifft sowohl strukturelle Aspekte wie Schemaintegration als auch inhaltliche Aspekte wie Datenintegration und Datenbereinigung. Daten, die aus heterogenen Quellen stammen, müssen zunächst in ein einheitliches internes Format überführt werden, um miteinander vergleichbar zu sein. Dazu sind häufig folgende Transformationen erforderlich. Anpassung von Datentypen Konvertierung von Kodierungen Vereinheitlichung von Zeichenketten Vereinheitlichung von Datumsangaben Umrechnung von Maßeinheiten Kombination bzw. Separierung von Attributwerten Solche Transformationen, die dem Zweck der Standardisierung dienen, werden unter den Begriff Datenmigration zusammengefasst. Sie leisten einen entscheidenden Beitrag zur Integration von Daten aus heterogenen Quellen Ladekomponente Nach Abschluss der Datentransformation befinden sich im Arbeitsbereich bereinigte und angemessen aufbereitete Daten, die für die Speicherung und spätere Auswertungen geeignet sind. Für die Weiterleitung dieser Daten sind zwei Ladekomponenten zuständig: eine Komponente zur Übertragung von analyseunabhängigen Detaildaten aus dem Arbeitsbereich in die Basisdatenbank. eine Komponente zur Übertragung von analysespezifischen Daten (z.b. Aggregate) aus der Basisdatenbank in das Data Warehouse. 2 Eine wichtige Eigenschaft von Data-Warehouse-Systemen ist die Historisierung von Daten, d.h., es werden nicht nur aktuelle Daten verwaltet, sondern zusätzlich auch Daten aus früheren Zeitperioden. Beim inkrementellen Laden von Daten muss diese Eigenschaft berücksichtigt werden. Ein im Data Warehouse gespeicherter Datensatz, zu dem es eine Änderung in einer Datenquelle gegeben hat, darf nicht einfach mit dem geänderten Datensatz überschrieben werden. Stattdessen ist der geänderte Datensatz zusätzlich abzulegen. Es gibt grundsätzlich zwei Ladevorgängen: Online-Ladevorgang Man kann den Ladevorgang durchführen, obwohl auf der Basisdatenbank bzw. Data Warehouse Anfragen gestartet werden können. Offline-Ladevorgang Anfragen an Basisdatenbank bzw. Data Warehouse und Ladevorgang können nicht parallel durchgeführt werden. In der Praxis muss Ladeprozess online durchgeführt werden, ohne den laufenden Betrieb des Data-Warehouse-Systems zu unterbrechen. Allerdings soll das Zeitfenster am Wochenende oder an einem Feiertag gewählt werden. 2 Falls keine Basisdatenbank vorhanden ist, existiert nur eine Ladaekomponente. 11

16 3.5. BASISDATENBANK KAPITEL 3. REFERENZARCHITEKTUR 3.5 Basisdatenbank Als Stufe zwischen dem Arbeitsbereich und dem Data Warehouse ist in der Referenzarchitektur die Komponente der Basisdatenbank angesiedelt. Sie ist die integrierte Datenbasis für verschiedene Analysen und hat somit zentrale Verteilungsfunktion, wodurch Mehrfachverwendung und Flexibilität in der Verwendung der Daten möglich wird. Trotz dieser zentralen Bedeutung für die gesamte Data-Warehouse-Architektur wird in der Praxis oft auf die Basisdatenbank verzichtet, weil Aufbau und Pflege aufwendig und teuer werden können. Die Basisdatenbank liefert eine integrierte Sicht: Die Schemata der unterschiedlichen Datenquellen und die Daten selbst sind bereinigt und integriert. Sie ist weder von der Modellierung noch von der Optimierung auf eine spezifische Analyse fokussiert, sondern vielmehr von einer Anwendungsneutralität geprägt, d.h. insbesondere sind keine Aggregate mit Blick auf typische OLAP-Anfragen anzutreffen. Die Aktualisierung der Basisdatenbank kann zu beliebigen Zeitpunkten erfolgen und hängt vom Aktualisierungsbedarf ab. Konsistenzproblematiken können durch häufigere Aktualisierung vermieden werden. Die Basisdatenbank stellt die folgenden Funktionen zur Verfügung: Sie nimmt alle für die Analyse notwendigen Daten auf und stellt das zentrale Datenlager dar. Sie hat somit Sammel- und Integrationsfunktion. Sie hat alle Data Warehouses mit Daten zu versorgen; somit hat sie Distributionsfunktion. Sie kann direkt - also unter Umgebung eines Data Warehouse - als Datenbasis für die Analyse verwendet werden. In diesem Fall hat sie dann auch eine Auswertungsfunktion. Es gibt auch vier Akualisierungsstrategien von Basisdatenbank (siehe auf der Seite 9). Zusätzlich zu den Qualitätsanforderungen an die Quelldaten (siehe 3.3.2) kommen für die Basisdatenbank die folgenden zwei Qualitätsanforderung hinzu: Nachvollziehbarkeit Die Beschreibung der automatischen Transformationen und die Erklärung der manuellen Eingriffsmöglichkeiten in diese Transformation was für Entwickler bzw. Anwender verständlich und zugänglich sein. Eine Arbeits- oder Verfahrensanweisung, in der die Prozesse im Datenbeschaffungsbereich und der Transport der Daten von hier in die Basisdatenbank und Data Warehouses festgelegt sind, muss vorhanden sein. Der Datenfluss von den Quellsystemen bis hin zur Basisdatenbank bzw. Data Warehouse muss beschrieben sein. Verfügbarkeit Die für die geplanten Verwendungszwecke notwendigen Daten müssen in der Basisdatenbank bzw. im Data Warehouse zusammen mit den zugehörigen Metadaten im Repositorium zur Verfügung stehen. Die technische Möglichkeit des Zugriffs auf die Basisdatenbank und das Data Warehouse muss sichergestellt werden. Die Daten müssen schnell genug zur Verfügung gestellt werden können. Obwohl ihr Aufbau und ihre Pflege aufwändig sind, kann die Basisdatenbank die Komplexität der Schnittstellen zwischen Datenquellen und Data Warehouse ziemlich reduzieren. 3.6 Data Warehouse & Data Mart Das Data Warehouse ist die zugrunde liegende Datenbank, die für Analysezwecke aufgebaut wird. Die Aufgabe des Data Warehouse ist es, die für die Analysen des Anwenders notwendigen Daten dauerhauft zu verwalten und den Analyseprozessen in geeigneter Form zur Verfügung zu stellen. Zur Realisierung des Data Warehouse werden üblicherweise ein oder mehrere Datenbankmanagementsysteme eingesetzt. Die Hauptproblematik des Data Warehouse liegt im 12

17 KAPITEL 3. REFERENZARCHITEKTUR 3.6. DATA WAREHOUSE & DATA MART Design des geeigneten logischen Schemas. Dieses Schema orientiert sich ausschließlich an den Analysebedürfnissen der Anwender, die vorher in Form eines konzeptuellen Schemas spezifiert wurden Data Mart Man kann ein Data Mart als ein kleines abteilungsweites Data Warehouse betrachten. Die Grundidee des Konzeptes besteht darin, einen weiteren inhaltlich beschränkten Fokus des Unternehmens oder einer Abteilung als Teilsicht eines Data Warehouse abzubilden. Hierfür kann es folgende Gründe geben: Eigenständigkeit Datenschutzaspekte durch Teilsicht auf die Daten Organistorische Apspekte Verringerung des Datenvolumens Performanzgewinn durch Aggregationen Verteilung der Last Unabhängigkeit von den Akualisierungszyklen des Data Warehouse Data-Warehouse-Architektur Es gibt drei möglichen Architekturen von Data Warehouse. 1. Zentralisierte Architektur eines Data Warehouse (Abbildung 3.2) Diese zentralierte Architektur vereinigt alle analytischen Daten auf einer einzigen Platt- Abbildung 3.2: Zentralisierte Architektur form. Vorteile sind die geringe Redundanz und die Hardwareersparnis. Wegen der mangelnden Modularisierungsmöglichkeiten eignet sich die zentrale Architektur aber nur für kleine Unternehmen. Für einen größeren und heterogenen Benutzerkreis ist sie benutzerunfreundlich und abfrageineffizient. 13

18 3.6. DATA WAREHOUSE & DATA MART KAPITEL 3. REFERENZARCHITEKTUR Abbildung 3.3: Hierachische Architektur 2. Hierachische Architektur eines Data Warehouse(Abbildung3.3) Diese Architektur ist verbreiteter. Sie koordiniert lokale Data Marts durch ein Data Warehouse. Ziel des Data Warehouse ist die Extraktion, Integration und Verteilung der Daten. Ein Data Mart ist von Data Warehouse abhängig und orientiert sich auf die Analyseaufgabe einer Abteilung. Data Marts verteilen die Last des Data Warehouse. Dadurch wird Effizienz gewonnen. 3. Data-Mart-Architektur (Abbildung 3.4) In dieser Architektur ist das Data Warehouse nichts anderes als die Vereinigung aller Abbildung 3.4: Data Mart-Architektur Data Marts. Die Einrichtung und Verwaltung lokaler Data Marts ist einfacher als bei den anderen Architekturen. Durch die Verteilung kann man Skalierbarkeit sicherstellen. Schwierig ist die effiziente Kontrolle redundanter und inkonsistenter Daten über viele Data Marts hinweg. Aus diesem Grund ist diese Architektur im Allgemein nicht zu empfehlen. 14

19 KAPITEL 3. REFERENZARCHITEKTUR 3.7. METADATEN UND REPOSITORIUM 3.7 Metadaten und Repositorium Generell versteht man unter Metadaten alle Informationen, die den Aufbau, die Wartung und die Administration des Data-Warehouse-Systems vereinfachen und darüber hinaus die Informationsgewinnung aus dem Data Warehouse ermöglichen. Dabei handelt es sich um Informationen über die Daten aus den Datenquellen, der Basisdatenbank und dem Data Warehouse wie z.b. konzeptuelle und logische Datenbankschemata und ihre Dokumentation, physische Speicherinformationen, Zugriffsrechte und Qualitätssicherung sowie Informationen über die verschiedenen Data-Warehouse-Prozesse, welche die Daten extrahieren, bereinigen, transformieren und analysieren. Metadaten umfassen also beschreibende Informationen über Inhalt, Struktur, Kontext und Bedeutung von Daten, aber auch prozessbezogene Informationen über die Verarbeitung dieser Daten. Metadaten lassen sich üblicherweise in fachliche und technische Metadaten einteilen. Die fachlichen Metadaten dienen in erster Linie dem Endanwender. In dieser Kategorie fallen anwendungsspezifische Dokumentationen über vordefinierte Anfragen und Berichte sowie Fachbegriffe und Terminologien, Thesauri und domänenspezifisches Wissen. Demgegenüber sind die technischen Metadaten von Administratoren, Anwendungsentwicklern und Softwarewerkzeugen erstellt worden bzw. für sie bestimmt. Hierzu gehören die Beschreibungen der logischen und physischen Datenschemata, Integritätsbedingungen sowie Implementierungsinformationen der verschiedenen Skripte für Extraktion, Transformation und Analyse der Daten wie beispielweise Dateiname, Erstellungsdatum, Autor und Beschreibung der Transformationen. Alle Metadaten werden im Repositorium abgelegt und verwaltet. Metadaten sind für die ständige Wartung und Benutzung eines Data-Warehouse-Systems unerlässlich. 15

20 4 Zusammenfassung Data-Warehouse-Systeme bilden eine Infrastruktur zum Aufbau einer konsistenten Datenbasis, aus der spezifische und analyseorientierte Datenbanken abgeleitet werden können, die dann Gegenstand statistischer Auswertungen sind. Der erste Schritt zur Realisierung einer integrierten und konsistenten Sichtweise über eine Vielzahl von Datenquellen erfolgt dadurch, dass in einem Extraktionsvorgang relevante Daten aus den betroffenen Quellsystemen extrahiert, gemäß vorgegebener Regeln auf Schema- und Datenebene transformiert und schließlich in die konsolidierte Datenbasis eines Data-Warehouse- Systems geladen werden. Der zweite Schritt besteht darin, dass für bestimmte Anwendungen spezifisch Datenbasen definiert werden, die sowohl inhaltlich als auch vom physischen Datenbankentwurf her auf die jeweiligen Analysen zugeschnitten sind. Wichtig ist dabei, dass sowohl alle definierten Strukturen als auch alle Abläufe in einem Metadaten-Repositorium dokumentiert werden. Zusammenfassend stellt ein DWS integrierte und dokumentierte Daten zur Analyse bereit. 16

Architektur eines Data Warehouse Systems. Mario Jandeck

Architektur eines Data Warehouse Systems. Mario Jandeck Architektur eines Data Warehouse Systems Mario Jandeck Agenda Folie 2 von 24 1. Die Referenzarchitektur 2. Komponenten des Data Warehouse Systems 3. Datenbeschaffung und Qualität 4. Analyse im Data Warehouse

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

Data Warehousing und Data Mining

Data Warehousing und Data Mining 2 Data Warehousing und Data Mining Kapitel 1: Data-Warehousing-Architektur von Geschäftsprozessen Mögliche Fragestellungen Wie entwickelt sich unser Umsatz im Vergleich zum letzten Jahr? In welchen Regionen

Mehr

Informationssysteme: Neuere Konzepte Teil II

Informationssysteme: Neuere Konzepte Teil II Informationssysteme: Neuere Konzepte Kapitel 1: Data-Warehousing-Architektur Folien teilweise übernommen von Matthias Gimbel 2 von Geschäftsprozessen Mögliche Fragestellungen Wie entwickelt sich unser

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

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

Data-Warehouse-Architektur

Data-Warehouse-Architektur Data-Warehouse-Architektur Anforderungen Referenzarchitektur Phasen des Data Warehousing Komponenten VL Data Warehouses, WS 2000/2001 2-1 Anforderungen des Data Warehousing Unabhängigkeit zwischen Datenquellen

Mehr

Seminar im Sommersemester 2004 an der Universität Karlsruhe (TH)

Seminar im Sommersemester 2004 an der Universität Karlsruhe (TH) Seminar im Sommersemester 2004 an der Universität Karlsruhe (TH) Verteilung und Integration von Informationen im Verkehrsbereich Thema: OLAP in verteilten Data-Warehouse- Umgebungen Vortrag: Christian

Mehr

Anforderungen des Data Warehousing. 2. Data-Warehouse-Architektur. Anforderungen des Data Warehousing. Referenzarchitektur. Data-Warehouse-Manager

Anforderungen des Data Warehousing. 2. Data-Warehouse-Architektur. Anforderungen des Data Warehousing. Referenzarchitektur. Data-Warehouse-Manager 2. Data-Warehouse-Architektur Anforderungen Referenzarchitektur Phasen des Data Warehousing Komponenten Anforderungen des Data Warehousing Unabhängigkeit zwischen Datenquellen und Analysesystemen (bzgl.

Mehr

Data-Warehouse-Architektur

Data-Warehouse-Architektur Data-Warehouse-Architektur ƒ Anforderungen ƒ Referenzarchitektur ƒ Phasen des Data Warehousing ƒ Komponenten Vorlesung Data-Warehouse-Technologien 2-1 Anforderungen des Data Warehousing ƒ Unabhängigkeit

Mehr

Seminararbeit zum Thema. Referenzarchitektur von. Data-Warehouse-Systemen

Seminararbeit zum Thema. Referenzarchitektur von. Data-Warehouse-Systemen Friedrich-Schiller-Universität Jena Fakultät für Mathematik und Informatik Institut für Informatik Prof. Dr. Klaus Küspert, Dipl.-Math. Katharina Büchse Seminararbeit zum Thema Referenzarchitektur von

Mehr

Teil II Data-Warehouse-Architektur

Teil II Data-Warehouse-Architektur Teil II Data-Warehouse-Architektur Data-Warehouse-Architektur 1 Anforderungen 2 Referenzarchitektur 3 Phasen des Data Warehousing 4 c Sattler / Saake / Köppen Data-Warehouse-Technologien Letzte Änderung:

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

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

10. Vorlesung: Datenorganisation SS 2007

10. Vorlesung: Datenorganisation SS 2007 10. Vorlesung: Datenorganisation SS 2007 8 Parallele Transaktionen 9 9.1 Drei-Ebenen Ebenen-Architektur 9.2 Verteilte Datenbanken 9.3 Client-Server Server-Datenbanken 9.4 Föderierte Datenbanken 9.5 Das

Mehr

Online Analytical Processing

Online Analytical Processing Online Analytical Processing Online Analytical Processing Online Analytical Processing (OLAP) ermöglicht die multidimensionale Betrachtung von Daten zwecks E rmittlung eines entscheidungsunterstützenden

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

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

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 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

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

Contents. Ebenen. Data Warehouse - ETL Prozess Version: July 10, 2007. 1 Ebenen. Andreas Geyer-Schulz und Anke Thede. 2 Problemquelle Quellsysteme 4

Contents. Ebenen. Data Warehouse - ETL Prozess Version: July 10, 2007. 1 Ebenen. Andreas Geyer-Schulz und Anke Thede. 2 Problemquelle Quellsysteme 4 Contents Data Warehouse - ETL Prozess Version: July 10, 2007 Andreas Geyer-Schulz und Anke Thede Schroff-Stiftungslehrstuhl Informationsdienste und Elektronische Märkte Fakultät für Wirtschaftswissenschaften

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

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

Data Warehouse Technologien

Data Warehouse Technologien Veit Köppen Gunter Saake Kai-Uwe Sattler Data Warehouse Technologien Inhaltsverzeichnis Inhaltsverzeichnis vii 1 Einführung in Data-Warehouse-Systeme 1 1.1 Anwendungsszenario Getränkemarkt...............

Mehr

Data Preprocessing 1. Thema: Bussiness Intelligence Teil 1: OLAP & Data Warehousing. von Christian Merker

Data Preprocessing 1. Thema: Bussiness Intelligence Teil 1: OLAP & Data Warehousing. von Christian Merker 1 Data Preprocessing 1 Thema: Bussiness Intelligence Teil 1: OLAP & Data Warehousing von Christian Merker 2 Gliederung Motivation Monitore Datenextraktion Schema- und Datenintegration Datenbereinigung

Mehr

Data-Wa re house-systeme

Data-Wa re house-systeme P Andreas Bauer + Holger Günzel (Hrsg.) Data-Wa re house-systeme Architektur Entwicklung Anwendung 2., überarbeitete und aktualisierte Auflage dpun kt.verlag I n ha I t sve rzeic h n is Teil I 1 1.1 1.2

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

Veit Köppen Gunter Saake Kai-Uwe Sattler. 2. Auflage. Data Warehouse Technologien

Veit Köppen Gunter Saake Kai-Uwe Sattler. 2. Auflage. Data Warehouse Technologien Veit Köppen Gunter Saake Kai-Uwe Sattler 2. Auflage Data Warehouse Technologien Inhaltsverzeichnis Inhaltsverzeichnis ix 1 Einführung in Data-Warehouse-Systeme 1 1.1 Anwendungsszenario Getränkemarkt...

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

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

Informationsintegration und Webportale

Informationsintegration und Webportale Informationsintegration und Webportale 02.12.2013 : Data-Warehouse-Systeme, Markus Ewald (FZI) INSTITUTS-, FAKULTÄTS-, ABTEILUNGSNAME (in der Masteransicht ändern) KIT Universität des Landes Baden-Württemberg

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

1 Die Active Directory

1 Die Active Directory 1 Die Active Directory Infrastruktur Prüfungsanforderungen von Microsoft: Configuring the Active Directory Infrastructure o Configure a forest or a domain o Configure trusts o Configure sites o Configure

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-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

fi Data Warehouse: Sammlung von Technologien zur Unterstützung von Entscheidungsprozessen fi Herausforderung an Datenbanktechnologien

fi Data Warehouse: Sammlung von Technologien zur Unterstützung von Entscheidungsprozessen fi Herausforderung an Datenbanktechnologien Einführung Gegenstand der Vorlesung fi Data Warehouse: Sammlung von Technologien zur Unterstützung von Entscheidungsprozessen fi Herausforderung an Datenbanktechnologien Datenvolumen (effiziente Speicherung

Mehr

Informationssysteme. Prof. Dr. Hans Czap. Lehrstuhl für Wirtschaftsinformatik I. Lehrstuhl für Wirtschaftsinformatik I - II - 1 -

Informationssysteme. Prof. Dr. Hans Czap. Lehrstuhl für Wirtschaftsinformatik I. Lehrstuhl für Wirtschaftsinformatik I - II - 1 - Vorlesung Grundlagen betrieblicher Informationssysteme Prof. Dr. Hans Czap Email: Hans.Czap@uni-trier.de - II - 1 - Inhalt Kap. 1 Ziele der Datenbanktheorie Kap. 2 Datenmodellierung und Datenbankentwurf

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

Definition Informationssystem

Definition Informationssystem Definition Informationssystem Informationssysteme (IS) sind soziotechnische Systeme, die menschliche und maschinelle Komponenten umfassen. Sie unterstützen die Sammlung, Verarbeitung, Bereitstellung, Kommunikation

Mehr

Einführung. Informationssystem als Abbild der realen Welt

Einführung. Informationssystem als Abbild der realen Welt Was ist ein Datenbanksystem? Anwendungsgrundsätze Betrieb von Datenbanksystemen Entwicklung von Datenbanksystemen Seite 1 Informationssystem als Abbild der realen Welt Modellierung (Abstraktion) Sachverhalte

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

Datenbanken 16.1.2008. Die Entwicklung der Datenbanksysteme ist eng an die der Hardware gekoppelt und wird wie jene in Generationen eingeteilt:

Datenbanken 16.1.2008. Die Entwicklung der Datenbanksysteme ist eng an die der Hardware gekoppelt und wird wie jene in Generationen eingeteilt: Datenbanksysteme Entwicklung der Datenbanksysteme Die Entwicklung der Datenbanksysteme ist eng an die der Hardware gekoppelt und wird wie jene in Generationen eingeteilt: 1. Generation: In den fünfziger

Mehr

Data Warehouse Version: June 26, 2007. Andreas Geyer-Schulz und Anke Thede

Data Warehouse Version: June 26, 2007. Andreas Geyer-Schulz und Anke Thede Data Warehouse Version: June 26, 2007 Andreas Geyer-Schulz und Anke Thede Schroff-Stiftungslehrstuhl Informationsdienste und Elektronische Märkte Fakultät für Wirtschaftswissenschaften Gebäude 20.20 Rechenzentrum,

Mehr

Software-Engineering und Datenbanken

Software-Engineering und Datenbanken Software-Engineering und Datenbanken Prof. Dr. Bernhard Schiefer bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer Prof. Dr. Bernhard Schiefer 1-1 Wesentliche Inhalte Begriff DBS Datenbankmodelle

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

Profilbezogene informatische Bildung in den Klassenstufen 9 und 10. Schwerpunktthema Daten und Datenbanken

Profilbezogene informatische Bildung in den Klassenstufen 9 und 10. Schwerpunktthema Daten und Datenbanken Profilbezogene informatische Bildung in den Klassenstufen 9 und 10 Schwerpunktthema Robby Buttke Fachberater für Informatik RSA Chemnitz Fachliche Einordnung Phasen relationaler Modellierung Fachlichkeit

Mehr

Datenbanken. Prof. Dr. Bernhard Schiefer. bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer

Datenbanken. Prof. Dr. Bernhard Schiefer. bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer Datenbanken Prof. Dr. Bernhard Schiefer bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer Wesentliche Inhalte Begriff DBS Datenbankmodelle Datenbankentwurf konzeptionell, logisch und relational

Mehr

Grundlagen von Datenbanken

Grundlagen von Datenbanken Grundlagen von Datenbanken Aufgabenzettel 1 Grundlagen Datenbanken: Kurzer historischer Überblick (1) Anwendung 1 Anwendung 2 Datei 1 Datei 2 Datei 3 Zugriff auf Dateien ohne spezielle Verwaltung 2 Exkurs:

Mehr

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Dateiname: ecdl5_01_00_documentation_standard.doc Speicherdatum: 14.02.2005 ECDL 2003 Basic Modul 5 Datenbank - Grundlagen

Mehr

Kapitel 10 Aktive DBMS

Kapitel 10 Aktive DBMS Kapitel 10 Aktive DBMS 10 Aktive DBMS 10 Aktive DBMS...1 10.1 Einführung und Definition...2 10.2 Funktionsprinzip: ADBMS und ECA-Modell...4 10.3 Potentiale und Vorteile ADBMS...5 10.4 Aktive Elemente einer

Mehr

Teil VI. Datenbanken

Teil VI. Datenbanken Teil VI Datenbanken Überblick 1 Grundlegende Begriffe Motivation 2 Relationale Datenbanksysteme Das Relationale Datenmodell SQL 3 Entwurf von Datenbanken Das Enity Relationship (ER) Modell Abbildung von

Mehr

Data Warehousing in der Lehre

Data Warehousing in der Lehre Data Warehousing in der Lehre Prof. Dr.-Ing. Tomas Benz Dipl.-Inform. Med. Alexander Roth Agenda Vorstellung Fachhochschule Heilbronn Vorstellung i3g Vorlesungen im DWH-Bereich Seminare Projekte Studien-

Mehr

30. Juni 2006 - Technische Universität Kaiserslautern. Paul R. Schilling

30. Juni 2006 - Technische Universität Kaiserslautern. Paul R. Schilling 30. Juni 2006 - Technische Universität Kaiserslautern Paul R. Schilling ! " #$% & '( ( ) *+, - '. / 0 1 2("$ DATEN SIND ALLGEGENWÄRTIG Bill Inmon, father of data warehousing Unternehmen In einer vollkommenen

Mehr

erfolgreich steuern Datenqualität rä dpunkt.verlag Ldwi Praxislösungen für Business-Intelligence-Projekte Rüdiger Eberlein Edition TDWI

erfolgreich steuern Datenqualität rä dpunkt.verlag Ldwi Praxislösungen für Business-Intelligence-Projekte Rüdiger Eberlein Edition TDWI Detlef Apel Wolfgang Behme Rüdiger Eberlein Christian Merighi Datenqualität erfolgreich steuern Praxislösungen für Business-Intelligence-Projekte 3., überarbeitete und erweiterte Auflage Edition TDWI rä

Mehr

Einführung. Kapitel 1 2 / 508

Einführung. Kapitel 1 2 / 508 Kapitel 1 Einführung 2 / 508 Einführung Was ist ein Datenbanksystem (DBS)? Ein System zum Speichern und Verwalten von Daten. Warum kein herkömmliches Dateisystem verwenden? Ausfallsicherheit und Skalierbarkeit

Mehr

Survival Guide für Ihr Business Intelligence-Projekt

Survival Guide für Ihr Business Intelligence-Projekt Survival Guide für Ihr Business Intelligence-Projekt Sven Bosinger Solution Architect BI Survival Guide für Ihr BI-Projekt 1 Agenda Was ist Business Intelligence? Leistungsumfang Prozesse Erfolgsfaktoren

Mehr

Modellbasierte Business Intelligence in der Praxis. Nürnberg, 10.11.2009

Modellbasierte Business Intelligence in der Praxis. Nürnberg, 10.11.2009 Modellbasierte Business Intelligence in der Praxis Nürnberg, 10.11.2009 I N H A L T 1. Warum Modelle für Business Intelligence (BI)? 2. Inhalte von Datenmodellen für BI 3. Inhalte von Prozessmodellen 4.

Mehr

Intelligence (BI): Von der. Nürnberg, 29. November 2011

Intelligence (BI): Von der. Nürnberg, 29. November 2011 Modelle für Business Intelligence (BI): Von der Anforderung zum Würfel Nürnberg, 29. November 2011 Warum Modelle für Business Intelligence (BI)? Warum Modelle für Business Intelligence (BI)? Bis zur Auswertung

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

Carl-Christian Kanne. Einführung in Datenbanken p.1/513

Carl-Christian Kanne. Einführung in Datenbanken p.1/513 Einführung in Datenbanken Carl-Christian Kanne Einführung in Datenbanken p.1/513 Kapitel 1 Einführung Einführung in Datenbanken p.2/513 Einführung Was ist ein Datenbanksystem (DBS)? Ein System zum Speichern

Mehr

Datenqualität erfolgreich steuern

Datenqualität erfolgreich steuern Edition TDWI Datenqualität erfolgreich steuern Praxislösungen für Business-Intelligence-Projekte von Detlef Apel, Wolfgang Behme, Rüdiger Eberlein, Christian Merighi 3., überarbeitete und erweiterte Auflage

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

Sven Bosinger solution architect BI. Data Warehouse Architekturen Der Schlüssel zum Erfolg! DOAG 16.11.2007 1

Sven Bosinger solution architect BI. Data Warehouse Architekturen Der Schlüssel zum Erfolg! DOAG 16.11.2007 1 Sven Bosinger solution architect BI Data Warehouse Architekturen Der Schlüssel zum Erfolg! DOAG 16.11.2007 1 Agenda Kurze Vorstellung its-people Architektur als Erfolgsfaktor Verschiedene Architekturansätze

Mehr

Datenbanksysteme SS 2007

Datenbanksysteme SS 2007 Datenbanksysteme SS 2007 Frank Köster (Oliver Vornberger) Institut für Informatik Universität Osnabrück 1 Kapitel 16: Data Warehousing und Knowledge Discovery in Databases DEFINITIONEN & BEGRIFFE Klassische

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

Data Mining Standards am Beispiel von PMML. Data Mining Standards am Beispiel von PMML

Data Mining Standards am Beispiel von PMML. Data Mining Standards am Beispiel von PMML Data Mining Standards am Beispiel von PMML Allgemeine Definitionen im Data Mining Data Mining (DM) Ein Prozess, um interessante neue Muster, Korrelationen und Trends in großen Datenbeständen zu entdecken,

Mehr

Klassifikation von Integrationskonflikten

Klassifikation von Integrationskonflikten Klassifikation von Integrationskonflikten Christiane Telöken 1 Inhaltsverzeichnis 1. Was bedeutet Integration? 2. Strukturelle Heterogenitätskonflikte 2.1 Konflikte bei bilateralen Korrespondenzen 2.2

Mehr

Softwaretool Data Delivery Designer

Softwaretool Data Delivery Designer Softwaretool Data Delivery Designer 1. Einführung 1.1 Ausgangslage In Unternehmen existieren verschiedene und häufig sehr heterogene Informationssysteme die durch unterschiedliche Softwarelösungen verwaltet

Mehr

Ein Schlüssel ist eine Menge von Attributen (also eines oder mehrere), die eine Datenzeile (Tupel) einer Tabelle eindeutig identifiziert

Ein Schlüssel ist eine Menge von Attributen (also eines oder mehrere), die eine Datenzeile (Tupel) einer Tabelle eindeutig identifiziert Maika Büschenfeldt Datenbanken: Skript 1 1. Was ist eine relationale Datenbank? In Datenbanken können umfangreiche Datenbestände strukturiert abgelegt werden. Das Konzept relationaler Datenbanken soll

Mehr

Modellierung von OLAP- und Data- Warehouse-Systemen

Modellierung von OLAP- und Data- Warehouse-Systemen Andreas Totok Modellierung von OLAP- und Data- Warehouse-Systemen Mit einem Geleitwort von Prof. Dr. Burkhard Huch Deutscher Universitäts-Verlag Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis

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

FHTW Berlin Einführungsskript SAP BPS Gruppe 3. Einführungsskript. Stefan Henneicke Uwe Jänsch Andy Renner Daniel Fraede

FHTW Berlin Einführungsskript SAP BPS Gruppe 3. Einführungsskript. Stefan Henneicke Uwe Jänsch Andy Renner Daniel Fraede Einführungsskript Projekt: elearning SAP BPS Auftraggeber: Prof. Dr. Jörg Courant Gruppe 3: Bearbeiter: Diana Krebs Stefan Henneicke Uwe Jänsch Andy Renner Daniel Fraede Daniel Fraede 1 Inhaltsverzeichnis

Mehr

Enterprise Applikation Integration und Service-orientierte Architekturen. 01 Einführung

Enterprise Applikation Integration und Service-orientierte Architekturen. 01 Einführung Enterprise Applikation Integration und Service-orientierte Architekturen 01 Einführung Agenda Warum EAI Klassifikation von EAI-Ansätzen Ebenen der Integration Architekturen zur Datenintegration Prof. Dr.

Mehr

Data Warehouse ??? Ein Data Warehouse ist keine von der Stange zu kaufende Standardsoftware, sondern immer eine unternehmensindividuelle

Data Warehouse ??? Ein Data Warehouse ist keine von der Stange zu kaufende Standardsoftware, sondern immer eine unternehmensindividuelle ??? Zusammenfassung, Ergänzung, Querverbindungen, Beispiele A.Kaiser; WU-Wien MIS 188 Data Warehouse Ein Data Warehouse ist keine von der Stange zu kaufende Standardsoftware, sondern immer eine unternehmensindividuelle

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

Analysen sind nur so gut wie die Datenbasis

Analysen sind nur so gut wie die Datenbasis Analysen sind nur so gut wie die Datenbasis Datenaufbereitung und Sicherung der Datenqualität durch den kontextbasierten MIOsoft Ansatz. Daten gelten längst als wichtiger Produktionsfaktor in allen Industriebereichen.

Mehr

Modellbasierte Business Intelligence- Praxiserfahrungen in einem komplexen Data Warehouse Umfeld. München, 26. Januar 2010

Modellbasierte Business Intelligence- Praxiserfahrungen in einem komplexen Data Warehouse Umfeld. München, 26. Januar 2010 Modellbasierte Business Intelligence- Praxiserfahrungen in einem komplexen Data Warehouse Umfeld München, 26. Januar 2010 I N H A L T 1. Warum Modelle für Business Intelligence (BI)? 2. Inhalte von Datenmodellen

Mehr

Ein Beispiel. Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse?

Ein Beispiel. Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse? Ein Beispiel Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse? Dipl.-Kfm. Claus Häberle WS 2015 /16 # 42 XML (vereinfacht) visa

Mehr

Carl-Engler-Schule Karlsruhe Datenbank 1 (5)

Carl-Engler-Schule Karlsruhe Datenbank 1 (5) Carl-Engler-Schule Karlsruhe Datenbank 1 (5) Informationen zur Datenbank 1. Definition 1.1 Datenbank-Basis Eine Datenbank-Basis ist eine Sammlung von Informationen über Objekte (z.b Musikstücke, Einwohner,

Mehr

Oracle BI EE mit großen Datenmengen

Oracle BI EE mit großen Datenmengen Oracle BI EE mit großen Datenmengen Christian Casek Riverland Solutions GmbH München Schlüsselworte: Oracle BI EE, Oracle BI Applications, Informatica, RPD, große Datenmengen, Performance, Performanceoptimierung,

Mehr

Data Mining-Projekte

Data Mining-Projekte Data Mining-Projekte Data Mining-Projekte Data Mining stellt normalerweise kein ei nmaliges Projekt dar, welches Erkenntnisse liefert, die dann nur einmal verwendet werden, sondern es soll gewöhnlich ein

Mehr

Die folgenden Features gelten für alle isquare Spider Versionen:

Die folgenden Features gelten für alle isquare Spider Versionen: isquare Spider Die folgenden s gelten für alle isquare Spider Versionen: webbasiertes Management (Administratoren) Monitoring Sichten aller gefundenen Beiträge eines Forums Statusüberprüfung Informationen

Mehr

Datenbanken: Architektur & Komponenten 3-Ebenen-Architektur

Datenbanken: Architektur & Komponenten 3-Ebenen-Architektur Datenbanken: Architektur & Komponenten 3-Ebenen-Architektur Moderne Datenbanksysteme sind nach der 3-Ebenen-Architektur gebaut: Anwendung 1 Web-Anwendung Anwendung 2 Java-Programm... Anwendung n Applikation

Mehr

JOB MANAGEMENT MIT DEM SAP SOLUTION MANAGER. Whitepaper

JOB MANAGEMENT MIT DEM SAP SOLUTION MANAGER. Whitepaper JOB MANAGEMENT MIT DEM SAP SOLUTION MANAGER. Whitepaper Wussten Sie, dass lediglich der kleinere Teil der Datenverarbeitung in Ihrem System von End-Anwendern generiert wird? Der größere Teil der Informationen

Mehr

CAS genesisworld.exchange connect Abgleich von Adressen und Terminen

CAS genesisworld.exchange connect Abgleich von Adressen und Terminen Abgleich von Adressen und Terminen Stand Juni 2004 Was ist CAS genesisworld.exchange connect? Inhalt 1 Was ist CAS genesisworld.exchange connect?... 3 2 Systemvoraussetzungen... 5 2.1 Software...5 2.2

Mehr

Business Intelligence Data Warehouse für den Ferienclub

Business Intelligence Data Warehouse für den Ferienclub Business Intelligence Data Warehouse für den Ferienclub Jan Weinschenker 8. Juli 2005 Im Rahmen der Vortragsreihe im Fach Anwendungen I beschäftigt sich diese Ausarbeitung mit dem Thema Data Warehousing.

Mehr

GDP4U. Intelligente Ideen für Finanzinstitute

GDP4U. Intelligente Ideen für Finanzinstitute GDP4U Intelligente Ideen für Finanzinstitute --> GDP4U Die Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen (GDPdU 147 Abs. 6 AO) verpflichten Finanzinstitute, den Finanzbehörden den

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

Gliederung Datenbanksysteme

Gliederung Datenbanksysteme Gliederung Datenbanksysteme 5. Datenbanksprachen 1. Datendefinitionsbefehle 2. Datenmanipulationsbefehle 3. Grundlagen zu SQL 6. Metadatenverwaltung 7. DB-Architekturen 1. 3-Schema-Modell 2. Verteilte

Mehr

Objektorientierte Datenbanken

Objektorientierte Datenbanken OODB 11 Slide 1 Objektorientierte Datenbanken Vorlesung 11 vom 01.07.2004 Dr. Sebastian Iwanowski FH Wedel OODB 11 Slide 2 Inhalt heute: Datenbanken in betriebswirtschaftlichen Anwendungen OTLP (SAP) Data

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

Geschäftsprozessmanagement

Geschäftsprozessmanagement Geschäftsprozessmanagement Der INTARGIA-Ansatz Whitepaper Dr. Thomas Jurisch, Steffen Weber INTARGIA Managementberatung GmbH Max-Planck-Straße 20 63303 Dreieich Telefon: +49 (0)6103 / 5086-0 Telefax: +49

Mehr

Oracle Automatic Storage Management (ASM) Best Practices

Oracle Automatic Storage Management (ASM) Best Practices Oracle Automatic Storage Management (ASM) Best Practices Markus Michalewicz BU Database Technologies ORACLE Deutschland GmbH 2 Page 1 www.decus.de 1 Agenda ASM Funktionalität und Architektur Storage Management

Mehr

Informationsintegration

Informationsintegration Informationsintegration Grundlegende Architekturen Ulf Leser Inhalt diese Vorlesung Klassifikation verteilter, autonomer, heterogener Systeme Weitere Klassifikationskriterien Schichtenaufbau integrierter

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

Wo sind meine Anforderungen?

Wo sind meine Anforderungen? Whitepaper Telekommunikation Wo sind meine Anforderungen? Eine effektive Lösung auf Basis von Confluence und JIRA 2011 SYRACOM AG 1 Einleitung Erfahrene Projektmitarbeiter sehen sich oftmals im Projektalltag

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