Erweiterte Entwurfskonzepte im Data Warehousing

Größe: px
Ab Seite anzeigen:

Download "Erweiterte Entwurfskonzepte im Data Warehousing"

Transkript

1 Universität Karlsruhe (TH) Fakultät für Informatik Institut für Programmstrukturen und Datenorganisation (IPD) Hauptseminar Imperfektion und erweiterte Konzepte im Data Warehousing Erweiterte Entwurfskonzepte im Data Warehousing Seminararbeit von Yingzhe Liu Sommersemester 2005

2

3 Inhaltsverzeichnis Abbildungsverzeichnis iii 1 Erweiterte Entwurfskonzepte Einführung in DWS Denition DWS Anwendungsbereich Entwurfsgrundlagen für DWS Konzeptuelle Modellierung - ME/R-Modell Logische Modellierung Snowake-Schema Star-Schema Erweiterte Entwurfskonzepte konformierte Dimensionstabelle Erweiterte Dimensionstabelle Zusammenfassung Literaturverzeichnis 19 i

4

5 Abbildungsverzeichnis 1.1 Entwurfsprozess von Datenbanksystemen Grasche Notation der ME/R-Elemente Kaufhaus-Szenario in ME/R-Notation Snowake-Schema Snowake-Schema-Beispiel Star-Schema Star-Schema-Beispiel Speditionsszenario Speditionsszenario Speditionsszenario: konformierte Dimensionstabelle Many-to-many-Dimension Many-to-many-Dimension Many-to-many-Dimension Role-playing-Dimension Role-playing-Dimension Role-playing-Dimension iii

6

7 Yingzhe Liu 1 Erweiterte Entwurfskonzepte 1.1 Einführung in DWS Aufgrund der enormen operativen Datenmenge und dem Bedarf für Echtzeit- Reporting bzw. für die Auswertung durch OLAP (OnLine Analytical Processing) werden auf der Basis operativer Daten in betrieblichen Informationssystemen Data Warehouses immer mehr eingesetzt. Die Analyse bzw. Auswertung von umfangreichen Daten aus betrieblichen Informationssystemen stellt sich als Hauptzweck des Data Warehouse dar. In einem Data-Warehouse-System (DWS) sollen umfangreiche Datenbestände aus vielen verschiedenen Quellsystemen in passender Form zur Verfügung gestellt werden. Eine der zentralen Themen im Data Warehousing stellt die Modellierung der Datenstrukturen dar. In dieser Arbeit werden die Grundlagen auf Modellierungsebene im Data Warehousing, insbesondere die erweiterte konzeptuelle und logische Modellierung, erläutert. Vollständigkeitshalber wird zuerst die Begriichkeit im Bereich von Data- Warehouse-Systemen im Kapitel 1 vorgestellt. Kapitel 2 behandelt die grundlegenden Entwurfskonzepte für DWS. Anschlieÿend werden die erweiterten Entwurfskonzepte für DWS in Kapitel 3 vorgestellt. Zum Schluÿ werfen wir einen Blick auf verwandte Forschungen Denition DWS Data-Warehouse-Systeme repräsentieren ein analyseorientiertes Informationsystem einer Organisation. Eine ozielle Denition von Data Warehouse gibt es bis heute nicht. Die am häugsten zitierte Denition nach Bill Inmon [Imm96] lautet: 1

8 1 Erweiterte Entwurfskonzepte Denition (Data-Warehouse-System) A data warehouse is a subjectoriented, integrated, time-varying, non-volatile collection of data in support of the management s decision-making process. Ein Data Warehouse hat nach dieser Denition also vier Eigenschaften (siehe [BG01]), die alle der Entscheidungsunterstützung dienen: Fachorientierung Die Datenbasis dient also zur Modellierung eines spezischen Anwendungsziels. Integrierte Datenbasis Die Datenverarbeitung ndet auf integrierten Daten aus mehreren Datenbanken statt. Nicht üchtige Datenbasis Daten, die einmal in das Data Warehouse eingebracht wurden, werden kaum entfernt oder geändert. Historische Daten Die Daten werden über einen längeren Zeitraum gehalten. Der DW-Prozess, auch Data Warehousing genannt, beschreibt den dynamischen Vorgang: Datenbeschaungsprozess Datenspeichern Datenanalyse Ein Data-Warehouse-System enthält Systemkomponenten und einzelne, riesige Datenbanken. Ein Data Warehouse ist jedoch mehr als die Summe seiner Komponenten, d.h. erst mit dem Data-Warehouse-System kann es seine Aufgaben erfüllen Anwendungsbereich Der Hintergrund für DWS ist die Analysierbarkeit der Daten: eine homogene und integrierte Datenbasis, um eine eziente und zielorientierte Analyse durchzuführen. Im Folgenden werden drei häuge Anwendungsbereiche genannt. Betriebswirtschaftliche Anwendungsgebiete Die häugsten Einsatzbereiche benden 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: [BG01]). Mit den dargestellten Informationen können qualizierte Anwender Analysen durchführen und weitergehende Erkenntnisse gewinnen. 2

9 1.2 Entwurfsgrundlagen für DWS Wissenschaftliche Anwendungsgebiete Aus diesem Bereich stammen auch die technischen Wurzeln der DW-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 beispielhaftes Projekt lautet Earth Observing System [Mic91]. Technische Anwendungsgebiete Auch in technisch orientierten Anwendungsfeldern gibt es viele mögliche Verwendungszwecke. Wir erklären es durch ein paar Beispiele. Hier gelten die Mechanismen, die dem Data Warehousing zugrunde liegen, entsprechend. Eine Fabrik kann beispielsweise eine Sto- oder Materialdatenbank aufbauen, um die in Produkten verwendeten Materalien zu dokumentieren. So können die verantwortlichen Lieferanten bei Rückfrufaktionen oder Gewährleistungsfällen festgestellt werden. (siehe auch [BG01] in Kapitel 11.5). 1.2 Entwurfsgrundlagen für DWS Hier gehen wir zuerst auf den typischen Entwurfsprozess von Datenbanksystemen ein. Diesen zeigt Abbildung 1.1. Abbildung 1.1: Entwurfsprozess von Datenbanksystemen Im typischen Entwurfsprozess von Datenbanksystemen werden nach der Anforderungsanalyse die konzeptuelle und logische Datenbankmodellierung durchgeführt. Dabei werden die Anforderungen an das Datenbanksystem zuerst im konzeptuellen Schema und dann im logischen Schema abgebildet. Aus Sicht der Datenbanktheorie wird die konzeptuelle Modellierung eher auf einer von Zieldatenmodellen unabhängigen Ebene durchgeführt. Deshalb ist das konzeptuelle Schema unabhängig vom 3

10 1 Erweiterte Entwurfskonzepte konkret verwendeten Zieldatenmodell. Demgegenüber wird das logische Schema in einem konkreten Datenmodell dargestellt. Nach der Entscheidung für ein konkretes Datenbanksystem wird das interne Schema hergestellt (vgl. [Leh03]). Im klassischen relationalen Datenbankenentwurf ndet für die Erstellung des konzeptionellen Schemas meist eine Variante des Entity/Relationship-Modells (E/R- Modell) Anwendung. Das logische Datenschema wird dann formal im konkreten relationalen Datenmodell speziziert. Das relationale Datenmodell stellt dazu lediglich Relationen über Attribute als Ausdrucksmittel bereit. Die Schönheit eines logischen Schemas als Ergebnis des logischen Datenbankenentwurfs wird dabei formal quantizierbar durch den Grad der vorgenommenen Normalisierung bestimmt. Das interne Schema wird durch die Fähigkeiten des jeweiligen Datenbanksystems bestimmt (vgl. [BG01]). Der Entwurf von Data-Warehouse-Systemen wird in der Praxis analog wie der vorstehende Entwurfsprozess von klassischen Datenbanksystemen vorgehen. Die Frage hier ist aber, wie das Datenmodell in Data-Warehouse-Systemen aussehen soll und welche konzeptuelle und logische Modellierungsmethode in Data- Warehouse-Systemen eingesetzt werden sollen. In dieser Arbeit werden entsprechend folgende Fragen erklärt: Welche konzeptuellen Modellierungen von Data-Warehouse-Systemen existieren? Welche logischen Modellierungsschemata nden bei der Modellierung von Data-Warehouse-Systemen Anwendung? Was für erweiterte Konzepte sind in welchen Anwendungsfällen geeignet? Daraus ergibt sich als Zielsetzung dieses Kapitel, einen Überblick sowohl über die Grundlagen der konzeptuellen und logischen Modellierung von Data-Warehouse- Systemen als auch darüber hinausgehende erweiterte Konzepte zu geben Konzeptuelle Modellierung - ME/R-Modell Die ME/R-Notation (Multidimensional Entity/Relationship, [SBHD99]) wurde als spezielle Modellierungstechnik für multidimensionale Schemata entwickelt. Sie stellt eine Erweiterung des bekannten E/R-Ansatzes (Entity/Relationship, [Che76]) für relationale Schemata dar. Die Grundidee des ME/R-Ansatzes ist wie folgt: Um eine naturgemäÿe Darstellung der multidimensionalen Semantik zu erlauben, wird das E/R-Modell entsprechend spezialisiert und geringfügig erweitert. Zuerst sollen alle eingeführten Elemente der ME/R-Notation Spezialfälle der ursprünglichen E/R-Konstrukte sein, damit Leute, die mit dem E/R-Modell schon erfahren sind, auch das ME/R-Modell verstehen und benutzen können. Die Semantik muss die Unterscheidung zwischen Klassikationsschema, Würfelstruktur und die hierarchische Struktur der Klassikationen darstellen. Aus dieser Überlegung führt die ME/R-Notation folgende spezialisierte Konstrukte zusätzlich zur ursprünglichen E/R-Notation ein (siehe Abbildung 1.2): Eine spezielle Entitätenmenge Klassikationsstufe 4

11 1.2 Entwurfsgrundlagen für DWS Eine spezielle Entität Fakt Eine spezielle binäre Klassikationbeziehung zur Verbindung von Klassikationsstufen. Eine aus E/R übernommene Faktbeziehung, um Fakten und Dimensionen zu verbinden. Die Klassikationsbeziehung verbindet eine Dimensionsstufe A mit einer Dimensionsstufe B, welche eine höherwertige Abstraktionsebene darstellt. Beispielsweise werden Städte nach Ländern klassiziert. Aufgrund der speziellen Semantik der Klassikationsbeziehung dürfen keine Zyklen im so genannten Klassikationsgraphen existieren (vgl. [BG01]). Abbildung 1.2: Grasche Notation der ME/R-Elemente Die Faktbeziehung stammt aus einer allgemeinen n-ären Beziehung im E/R- Modell und wird hier spezialisiert. Durch sie werden n verschiedene Entitäten von Klassikationsstufen verbunden. Solche Beziehungen stellen ein Fakt der Dimensionalität n dar und bilden einen Würfel. Eine Beschreibung des Fakts verwenden wir als Name der Menge. Die unmittelbar verbundenen Klassikationsstufen nennen wir atomare Klassikationsstufen. Die Faktbeziehung modelliert die inhärente Trennung zwischen Dimension und Würfelzellen und somit die Struktur des Würfels. Die Attribute der Faktbeziehung modellieren die Kenngröÿen der Fakten, wogegen die Klassikationsstufen die qualizierenden Daten darstellen (vgl. [BG01]). Beispiel Wir betrachten eine Verkaufsanalyse. Kenngröÿen können z. B. Verkaufszahlen oder der Umsatz sein. Als Dimension dienen Produkt, Geographie und Zeit. Innerhalb einer Dimension sind auch Alternativpfade der Klassikationsbeziehungen möglich. Abbildung 1.3 zeigt solche Alternativpfade bei der Zeitdimension. Wochen sind somit nicht mehr eindeutig zu Quartalen oder Jahren zusammengefasst. 5

12 1 Erweiterte Entwurfskonzepte Abbildung 1.3: Kaufhaus-Szenario in ME/R-Notation Logische Modellierung Nach der konzeptuellen Modellierung ist eine formale Beschreibung des multidimensionalen Datenmodells für Data-Warehouse-Systeme dringend nötig. Zunächst müssen die verwendeten Basiskonstrukte und deren Beziehungen formal beschrieben werden. Das Pendant im relationalen Datenmodell ist die formale Denition einer Relation, eines Relationenschemas, einer Domäne etc. Im Falle des multidimensionalen Paradigmas sind die zu formalisierenden Entitäten Datenwürfel, Dimensionen etc. ([BG01]). In den folgenden zwei Kapiteln werden zwei verschiedene Verfahren, die das systemunabhängige konzeptuelle Modell in ein logisch eingesetztes Modell verwandeln, vorgestellt. Die Vorgehendsweise ist etwas anders als im relationalen Modell. Der Hauptunterschied zwischen dem multidimensionalen und relationalen Modell ist die zusätzliche Semantik, durch die die Beziehungen zwischen den Klassikationsstufen einer Dimension untereinander, zwischen den Würfeln und den Klassikationsstufen seiner Dimensionen sowie zwischen verschiedenen Würfeln zum Bestandteil des Modells gemacht werden Snowake-Schema Die Klassikationen im ME/R-Modell können direkt in einer relationalen Datenbank umgesetzt werden. Dies realisiert man durch die Zuordnung einer eigenen Tabelle für jede Klassikationsstufe. Diese Tabelle enthält neben der ID für die Klassikationsknoten dieser Klassikationsstufe auch die beschreibenden Attribute und Fremdschlüssel der direkt benachbarten höheren Klassikationsstufen. Abbildung 1.4 verdeutlicht das Snowake-Schema. Die Kenngröÿen eines Datenwürfels werden innerhalb einer Faktentabelle verwaltet. Diese wird nach obigem Schema konstruiert, d.h., neben einer Spalte für jede Kenngröÿe enthält sie Fremd- 6

13 1.2 Entwurfsgrundlagen für DWS schlüsselbeziehungen zu den jeweils niedrigsten Klassikationsstufen der verschiedenen Dimensionen, gemäÿ der Granularität des Datenwürfels. Die Fremdschlüssel entsprechen den Zellkoordinaten in der multidimensionalen Datensicht. Sie bilden daher den zusammengesetzten Primärschlüssel für die Faktentabelle (siehe [Lin03]). Abbildung 1.4: Snowake-Schema Die hierarchischen Klassikationsstufen lassen sich am besten mit einem Beispiel verdeutlichen. Abbildung 1.5 zeigt eine Umsetzung in einem Speditionsunternehmen nach diesem Muster. Die Namensgeber vergleichen diese Variante mit dem Kristall einer Schneeocke. Damit werden n:m-beziehungen zwischen Hierarchieobjekten besser unterstürtzt, Aggregate optimal benutzt. Redundanz verschwindet auch. Auf der Schattenseite entsteht hier ein komplexeres Modell, welches für den Benutzer das Verständnis erschwert und bei der Anfrage kompliziert erscheint. Wie in Abbildung 1.4 gezeigt, sind bei Snowake-Schema alle Tabellen in Normalform. Bei einer Anfrage werden viele Join-Operationen ausgeführt, um viele Tabellen miteinander zu verbinden. Weil solche Verbindungen besonders zeitaufwändig sind, wird stattdessen in Data- Warehouse-Systemen häug das Star-Schema benutzt Star-Schema Im Star-Schema werden alle Dimensionsstufen, die zu einer Dimension gehören zu einer Dimensionstabelle zusammengefügt. Dies führt zur Denormalisierung der Dimensionstabelle, um eine schnellere Anfragebearbeitung zu erreichen. Eine Fak- 7

14 1 Erweiterte Entwurfskonzepte Abbildung 1.5: Snowake-Schema-Beispiel tentabelle wird mit N Dimensionen assoziiert. Im Modell ergibt sich dann ein Stern: die Faktentabelle steht im Mittelpunkt des Sternes, die dazugehörigen Dimensionen bilden die Strahlen des Sternes, daher kommt der Name Star-Schema. Innerhalb eines Star-Schemas gibt es für jede Dimension genau eine Dimensionstabelle. Abbildung 1.6 zeigt den prinzipiellen Aufbau eines Star-Schemas und Abbildung 1.7 repräsentiert das bereits ernannte Beispiel Spedition im Star-Schema. In Abbildung 1.7 sind die Klassikationsschemata der Zeit-, Produkt- und Geographiedimension dargestellt. Fahrzeug, Spedition, Landkreis, Regierungsbezirk, Bundesland und Staat werden im Star-Schema zu einer einzigen Dimensionstabelle Fahrzeug zusammengefsst. Die Fremdschlüssel der Faktentabelle sind mit der niedrigsten Granularität bezeichnet (z. B. FahrzeugID). In einem Star-Schema ist die Faktentabelle wie im Snowake-Schema normalisiert, demgegenüber sind die Dimensionstabellen nicht normalisiert. Demzufolge gibt es viele Redundanzen innerhalb der Dimensionstabellen. Die funktionalen Abhängigkeiten zwischen den Klassikationsstufen werden bei dieser Abbildung nicht sichtbar. Die Argumentation, wann und warum ein Star-Schema trotzdem dem Snowake- Schema vorzuziehen ist, stützt sich auf folgende Heuristiken über die Charakteristika von Data-Warehouse-Systemen (siehe [Lin03]): Schnellere Anfragebeantwortung. Anfragen werden auf höherer Granularitätsstufe (zum Beispiel Produktkategorie) eingeschränkt. Die aufwändigen Verbindungsopreationen zwischen verschiedenen Tabellen einer Dimension beim Snowake-Schema werden durch die Denormalisierung gespart. Erträglicher Speicheraufwand für Dimensionstabellen. 8

15 1.2 Entwurfsgrundlagen für DWS Abbildung 1.6: Star-Schema Abbildung 1.7: Star-Schema-Beispiel 9

16 1 Erweiterte Entwurfskonzepte Das Datenvolumen der Dimensionstabellen mit den Klassikationshierarchien ist relativ gering im Vergleich zum gesamten Volumen der Zellinhalte (Gröÿe der Faktentabelle). Das Datenvolumen wird somit durch die Denormalisierung insgesamt nicht dramastisch erhöht. Wenige Änderungen im Dimensionstabellen. Die Dimensionenstabellen werden seltener verändert als das Hinzufügen von neuen Faktendaten. Zusammenfassend besitzt das Star-Schema also folgende Eigenschaften, die es für Anwendungen geeignet erscheinen lassen: Einfache Struktur: Anfragen werden dadurch einfacher und lassen sich leichter formulieren. Einfache und exible Darstellung von Klassikationshierarchien: Klassikationshierarchien werden einfach innerhalb von Dimensionstabellen als Spalten angegeben. Eziente Anfrageverarbeitung innerhalb der Dimensionen: Die Selektionsprädikate, die höhere Dimensionsstufen zur Einschränkung verwenden, benötigen keine Verbindungsoperationen, um die Menge von Tupeln zu bestimmen, die mit der Faktentabellen verbunden werden müssen. Ob die Vorteile des Snowake-Schemas wie z. B. geringerer Speicherplatzbedarf und bessere Änderungsfreundlichkeit überwiegend oder das Star-Schema besser geeignet ist, hängt stark von den konkreten Daten- und Anfragecharakteristiken. 1.3 Erweiterte Entwurfskonzepte Wir werden hier die für das Data Warehousing bedeutendsten erweiterten Entwurfskonzepte: konformierte Dimensionstabelle und erweiterte Dimensionstabelle verdeutlichen konformierte Dimensionstabelle Der Leser wird sich hier vielleicht die Frage stellen: Was ist denn eine konformierte Dimensionstabelle? Dies stammt aus einem englischen Begri (vgl. Denition 1.3.1). Denition A conformed dimension is a dimension that means the same thing with every possible fact table to which it can be joined.[krrt98] Das heiÿt im Allgemeinen, dass eine konformierte Dimension mit allen benötigten Faktentabellen identisch verwendet werden kann. Das erklären wir in einem einfachen Beispiel. 10

17 1.3 Erweiterte Entwurfskonzepte Wir nehmen wieder das obige Szenario aus Abschnitt in einem Speditionsunternehmen. In der Faktentabelle in Abbildung 1.8 sind die Daten enthalten, welches Fahrzeug an welchem Tag welche Produkte transportiert hat. Abbildung 1.8: Speditionsszenario 1 Für die Abteilung, die die Aufträge an die Mitarbeiter verteilt, fügen wir zusätzlich eine Faktentabelle hinzu (siehe Abbildung 1.9). Darin werden die Daten gespeichert, wer welchen Auftrag mit welchem Fahrzeug ausführt. Abbildung 1.9: Speditionsszenario 2 Dieselbe Dimension Fahrzeug hat in beiden Fällen unterschiedliche Einträge, was aufgrund verschiedener Einsatzmöglichkeiten in verschiedenen Abteilungen gerecht ist. Soll es dann zwei Dimensionen Fahrzeug in demselben Unternehmen geben? 11

18 1 Erweiterte Entwurfskonzepte Wir wissen doch, dass die beiden Dimensionen im Unternehmen eigentlich dasselbe meinen. Somit passen wir die Dimension Fahrzeug so an, dass sie in beiden Fällen eingesetzt werden kann. Abbildung 1.10 stellt die angepasste Dimension Fahrzeug dar. Alle Attribute werden in einer konformierten Dimension gespeichert. Abbildung 1.10: Speditionsszenario: konformierte Dimensionstabelle Diese Vorgehensweise bietet reichlich Vorteile: Es ist nur eine einzige Dimension zu pegen und sie ist mit jeder Faktentabelle (bei gleicher Granularität) verwendbar Erweiterte Dimensionstabelle In diesem Kapitel beschreiben wir zwei normale Modellierungssituationen, wo eine spezische Dimensionsstruktur sehr ezient ist. Many-to-many-Dimension In vielen klassischen Modellierungssituationen sind die Existenz und die Granularität einer Faktentabelle verständlich und fundamental. Die Zuordnung der Dimensionstabellen zu Faktentabellen sind auch trivial. Aber eine Dimension kann auch mehrere Werte haben und die Anzahl der möglichen Werte für diese Dimension ist eventuell unbekannt, wenn die Faktentabelle erstellt wird. Solch eine Dimension nennen wir Many-to-many-Dimension. Patientendaten in einer Praxis liefern ein gutes Beispiel (siehe Abbildung 1.11). Alle Patientendaten inkl. die zugehörigen Personaldaten, Diagnosen und Zeitangaben werden in einer Patient-Faktentabelle abgespeichert. Das Problem ist, was mit der Diagnosentabelle passiert. Oft hat ein Patient mehrere Diagnosen. Eine mögliche Lösung zeigt uns die Abbildung 1.12: für jede Diagnose eine eigene Dimension. Diese Lösung ist nicht realistisch. Der Grund ist: 12

19 1.3 Erweiterte Entwurfskonzepte Abbildung 1.11: Many-to-many-Dimension 1 Abbildung 1.12: Many-to-many-Dimension 2 13

20 1 Erweiterte Entwurfskonzepte 1. Wir kennen die obere Schranke der Diagnosenanzahl nicht. 2. So ein Schema würde beim Abfragen (zum Beispiel: join) sehr langsam sein. Eine bessere Lösung ist, zwischen der Faktentabelle und der Diagnose-Dimension eine Brückentabelle hinzufügen (siehe Abbildung 1.13). In der Brückentabelle generieren wir die originale DiagnoseID in der Faktentabelle zu einer spezialen Diagnose- GruppeID. Die Diagnosengruppe-Tabelle, also unsere Brückentabelle, enthält eine spezische Menge von Einträgen für jeden Patienten. Jeder Eintrag enthält wieder die DiagnoseGruppeID, eine individuelle DiagnoseID und einen Gewichtungsfaktor. In einer gegebenen Diagnosengruppe muss die Summe aller Gewichtungsfaktoren 1,00 sein. Abbildung 1.13: Many-to-many-Dimension 3 Die Lösung mit einer zusätzlichen Brücktabelle ist nicht perfekt. Mit einem Beispiel verdeutlichen wir die Schwierigkeiten bei Brückentabellen. Beispiel Annahme: eine Diagnosentabelle hat 1k Einträge und jeder Eintrag hat 10kByte. Speicheraufwand: 10MB eine Faktentabelle hat 100k Einträge und jeder Eintrag hat 1kByte. Speicheraufwand: 100MB in einer Brückentabelle hat jeder Eintrag 50Byte. Dann muss man bei einer zusätzlichen Brückentabelle mit folgendem zusätzlichen Speicheraufwand (siehe Tabelle 1.1) rechnen: Speicheraufwand = alle Fakten Diag/Pat. Gröÿe eines Eintrags 14

21 Speicheraufwand Diag./Pat. 50MB MB MB 100 Tabelle 1.1: Speicheraufwand der Brückentabelle 1.3 Erweiterte Entwurfskonzepte Wie gezeigt verursacht die Erhöhung der Diagnosenanzahl einen entsprechend höheren Speicheraufwand. Deshalb ist die Lösung mit einer Brückentabelle bei extrem gestiegener Diagnosenanzahl (was zwar selten auftritt, aber nicht ausgeschlossen werden kann) auch nicht mehr akzeptabel. Role-Playing-Dimension Eine role in einem Data Warehouse ist eine Situation, wo eine einzelne Dimension mehrmals in derselben Faktentabelle auftritt. Abbildung 1.14 liefert wieder ein Beispiel aus einer Klinik. Abbildung 1.14: Role-playing-Dimension 1 In der Faktentabelle kann das Datum mehrfach auftauchen. Zum Beispiel hat ein Patient ein Operationsdatum und ein Rechnungsdatum. Anfrage: select * from Patient where OpZeitID= and RechZeitID= Da wir nur eine Zeitdimension haben, versucht SQL in so einem Join alle Daten gleichzustellen. Das ist aber nicht gewünscht. Eine mögliche Lösung (siehe Abbildung 1.15) wäre, verschiedene Dimensionen zu verwenden, da sie ja auch verschiedene Rollen spielen. Diese intuitive Lösung hat folgende Nachteile: 15

22 1 Erweiterte Entwurfskonzepte Alle Zeitdimensionen werden zwar unterschiedlich benannt. Sie müssen aber konsistent gehalten werden, weil sie immerhin die gleiche Domäne haben müssen. In einer komplizierten Umgebung (zum Beispiel Telekommunikationsindustrie) müssen mehrere verschiedene partiell überlappende Tabellen gehalten werden. Hier verursacht obige Lösung extrem hohen Wartungsaufwand. Abbildung 1.15: Role-playing-Dimension 2 Durch Einsatz von Sichten auf dieselbe Dimension kann eine bessere Lösung geliefert werden. Es ist zu beachten, dass jede Sicht auf eine Dimension eindeutige Spaltennamen benötigt. Abbildung 1.16 verdeutlicht die Vorgehensweise. Abbildung 1.16: Role-playing-Dimension Zusammenfassung In dieser Arbeit haben wir gemeinsam die benötigten Grundlagen beim Data- Warehouse-Entwurf und anschlieÿend die passenden Techniken in vielen allgemeingültigen Fällen kennengelernt. Hier muss man betonen, dass das Star-Schema aufgrund seiner schnellen Anfragebeantwortung und einfachen Struktur zwar überwiegend verwendet wird, um eine relativ optimale Struktur zu bekommen, aber 16

23 1.4 Zusammenfassung in der Praxis fast immer zusätzliche Techniken, sogenannte erweiterte Konzepte, notwendig sind. Konformierte Dimensionen sind eine der grundlegenden Techniken. In manchen Fällen kann man auch analog konformierte Fakten verwenden. Bei Many-to-many- Dimension oder Role-playing-Dimension benutzen wir erweiterte Dimensionstabellen. In anderen Fällen zum Beispiel Time-of-Day und Value-Band-Reporting ist der Einsatz der sogenannten erweiterten Faktentabelle von Vorteil (siehe [KRRT98]). 17

24

25 Literaturverzeichnis [BG01] [Che76] [Imm96] Andreas Bauer and Holger Günzel. Data-Warehouse-Systeme. dpunkt, Heidelberg, Peter Pin-Shan Chen. The Entity-Relationship ModelToward a Uni- ed View of Data. ACM Trans. Database Syst., 1(1):936, W. H. Immon. Building the Data Warehouse. Second Edition. John Wiley & Sons, New York, [KRRT98] R. Kimball, L. Reeves, M. Ross, and W. Thornthwaite. Warehause Lifecycle Toolkit. John Wiley & Sons, [Leh03] The Data Wolfgang Lehner. Datenbanktechnologie für Data-Warehouse-Systeme, Konzepte und Methoden. dpunkt, [Lin03] Kong Ling. Konzeptuelle und logische Modellierung eines Data- Warehouse-Systems. Seminararbeit, Seminar: Data Warehousing im Verkehrsbereich, IPD, Fakultät für Informatik, Universität Karlsruhe (TH), [Mic91] Z. Michalewicz. Statistical and scientic databases. In Series in Computers and Their Applications. Ellis Horwood, [SBHD99] C. Sapia, M. Blaschka, G. Höing, and B. Dinter. Extending the e/r model for the multidimensional paradigm. In Kambayashi Y. et. Al., editor, Advances in Database Technologies, volume LNCS Springer,

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

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

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

Kapitel 6 Einführung in Data Warehouses

Kapitel 6 Einführung in Data Warehouses Kapitel 6 Einführung in Data Warehouses Skript zur Vorlesung: Datenbanksysteme II Sommersemester 2008, LMU München 2008 Dr. Peer Kröger Dieses Skript basiert zu einem Teil auf dem Skript zur Vorlesung

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

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

Multidimensionales Datenmodell

Multidimensionales Datenmodell Multidimensionales Datenmodell Grundbegriffe fi Fakten, Dimensionen, Würfel Analyseoperationen fi Drill-Down, Roll-Up, Slice und Dice Notationen zur konzeptuellen Modellierung fi ME/R, ADAPT Relationale

Mehr

Hetero-Homogene Data Warehouses

Hetero-Homogene Data Warehouses Hetero-Homogene Data Warehouses TDWI München 2011 Christoph Schütz http://hh-dw.dke.uni-linz.ac.at/ Institut für Wirtschaftsinformatik Data & Knowledge Engineering Juni 2011 1 Data-Warehouse-Modellierung

Mehr

Multidimensionales Datenmodell, Cognos

Multidimensionales Datenmodell, Cognos Data Warehousing (II): Multidimensionales Datenmodell, Cognos Praktikum: Data Warehousing und Mining Praktikum Data Warehousing und Mining, Sommersemester 2010 Vereinfachte Sicht auf die Referenzarchitektur

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

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

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

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

Data Warehouses. Data Warehouse Architektur ... Sommersemester 2011. Melanie Herschel melanie.herschel@uni-tuebingen.de

Data Warehouses. Data Warehouse Architektur ... Sommersemester 2011. Melanie Herschel melanie.herschel@uni-tuebingen.de Data Warehouses Sommersemester 2011 Melanie Herschel melanie.herschel@uni-tuebingen.de Lehrstuhl für Datenbanksysteme, Universität Tübingen Data Warehouse Architektur Data-Warehouse-System Teilsichten

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

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

Friedrich-Schiller-Universität Jena Fakultät für Mathematik Informatik Lehrstuhl für Datenbanken und Informationssysteme Betreut von: David Wiese

Friedrich-Schiller-Universität Jena Fakultät für Mathematik Informatik Lehrstuhl für Datenbanken und Informationssysteme Betreut von: David Wiese Friedrich-Schiller-Universität Jena Fakultät für Mathematik Informatik Lehrstuhl für Datenbanken und Informationssysteme Betreut von: David Wiese Seminar Data Warehousing Sommersemester 2005 vorgelegt

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

Fundamentals of Software Engineering 1

Fundamentals of Software Engineering 1 Folie a: Name Fundamentals of Software Engineering 1 Grundlagen der Programmentwurfstechnik 1 Sommersemester 2012 Dr.-Ing. Stefan Werner Fakultät für Ingenieurwissenschaften Folie 1 Inhaltsverzeichnis

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

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

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

Komponenten und Architekturen von Analytischen Informationssystemen (AIS)

Komponenten und Architekturen von Analytischen Informationssystemen (AIS) Komponenten und Architekturen von Analytischen Informationssystemen (AIS) Melanie Pfoh Konsultation 27. Juni 2013 Hinweis Diese Folien ersetzen keinesfalls den Übungsstoff des zugehörigen e-learning-kurses.

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

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

Fachbereich Informatik Praktikum 1

Fachbereich Informatik Praktikum 1 Hochschule Darmstadt DATA WAREHOUSE SS2015 Fachbereich Informatik Praktikum 1 Prof. Dr. S. Karczewski Dipl. Inf. Dipl. Math. Y. Orkunoglu Datum: 14.April.2015 1. Kurzbeschreibung In diesem Praktikum geht

Mehr

Anfrageoptimierung in Data Warehouses durch Verwendung voraggregierter Views

Anfrageoptimierung in Data Warehouses durch Verwendung voraggregierter Views Anfrageoptimierung in Data Warehouses durch Verwendung voraggregierter Views Diplomarbeit Fakultät für Informatik und Elektrotechnik Lehrstuhl Datenbanken und Informationssysteme Universität Rostock Vorgelegt

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

Aufbau eines Data Warehouse für den Lebensmitteleinzelhandel

Aufbau eines Data Warehouse für den Lebensmitteleinzelhandel Die Fallstudie aus der Wirtschaftsinformatik: Aufbau eines Data Warehouse für den Lebensmitteleinzelhandel Dipl.-Kfm. Carsten Bange, Dr. Heiko Schinzer, Würzburg 1. Ausgangssituation Der hohe Wettbewerbsdruck

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

Business Intelligence im Krankenhaus

Business Intelligence im Krankenhaus Business Intelligence im Krankenhaus Dr. Thomas Lux Holger Raphael IT-Trends in der Medizin 03.September 2008 Essen Gliederung Herausforderungen für das Management im Krankenhaus Business Intelligence

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

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

Data Warehouse. Kapitel 17. Abbildung 17.1: Zusammenspiel zwischen OLTP und OLAP. Man unterscheidet zwei Arten von Datenbankanwendungen:

Data Warehouse. Kapitel 17. Abbildung 17.1: Zusammenspiel zwischen OLTP und OLAP. Man unterscheidet zwei Arten von Datenbankanwendungen: Kapitel 17 Data Warehouse OLTP Online Transaction Processing OLAP Online Analytical Processing Decision Support-Anfragen Data Mining opera- tionale DB opera- tionale DB opera- tionale DB Data Warehouse

Mehr

DW Data Warehousing Funktionsweise, Einsatz- und Problemfelder

DW Data Warehousing Funktionsweise, Einsatz- und Problemfelder DW Data Warehousing Funktionsweise, Einsatz- und Problemfelder Andreas Meier, Universität Fribourg Folie 1 DW Cartoon Quelle: Knoll M., Meier A. (Hrsg): Web & Data Mining. Praxis der Wirtschaftsinformatik,

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

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

Modellierungsaspekte eines Data Warehouse Wolfgang Gerken Fachhochschule Hamburg

Modellierungsaspekte eines Data Warehouse Wolfgang Gerken Fachhochschule Hamburg Modellierungsaspekte eines Data Warehouse Wolfgang Gerken Fachhochschule Hamburg Zusammenfassung Die Extraktion von verwertbarem Wissen aus Daten wird immer wichtiger. Dabei hilft ein Data Warehouse. Es

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

Software-Engineering Einführung

Software-Engineering Einführung Software-Engineering Einführung 7. Übung (04.12.2014) Dr. Gergely Varró, gergely.varro@es.tu-darmstadt.de Erhan Leblebici, erhan.leblebici@es.tu-darmstadt.de Tel.+49 6151 16 4388 ES Real-Time Systems Lab

Mehr

Komponenten und Architekturen von Analytischen Informationssystemen (AIS)

Komponenten und Architekturen von Analytischen Informationssystemen (AIS) Komponenten und Architekturen von Analytischen Informationssystemen (AIS) Melanie Pfoh Konsultation Zusammenfassung OPAL 6. Übung Juni 2015 Agenda Hinweise zur Klausur Zusammenfassung OPAL Übungen / Kontrollfragen

Mehr

Strategien zur Erweiterung eines Data Warehouse

Strategien zur Erweiterung eines Data Warehouse Studiengang: Informatik Prüfer: Betreuer: Prof. Dr.-Ing. habil. Bernhard Mitschang Thomas Sauter (DaimlerChrysler AG) Holger Schwarz (Universität Stuttgart) begonnen am: 01. September 2001 beendet am:

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

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

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

Einführung in Data Warehouses

Einführung in Data Warehouses Kapitel l6 Einführung in Data Warehouses Vorlesung: Dr. Matthias Schubert Skript 2009 Matthias Schubert Dieses Skript basiert auf dem Skript zur Vorlesung Datenbanksysteme II von Prof. Dr. Christian Böhm

Mehr

6 InfoCubes erstellen und konfigurieren

6 InfoCubes erstellen und konfigurieren InfoCubes bilden die Reportingschicht in der LSA; sie sind für die Performance des Reportings entscheidend. In diesem Kapitel stellen wir Ihnen vor, welche InfoCubes es gibt und wie Sie damit arbeiten.

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

Relationale Datenbanken Kursziele

Relationale Datenbanken Kursziele Relationale Datenbanken Kursziele DB Grundlagen Daten-Modellierung Relationales Modell und DB => Praxis: Mit SQL als Anfragesprache Mit MySQL als DB RDB 1-1 Kursinhalt (Tage) 1. DB Einleitung / Entity-Relationship

Mehr

SQL- & NoSQL-Datenbanken - Speichern und Analysen von großen Datenmengen

SQL- & NoSQL-Datenbanken - Speichern und Analysen von großen Datenmengen SQL- & NoSQL-Datenbanken - Speichern und Analysen von großen Datenmengen Lennart Leist Inhaltsverzeichnis 1 Einführung 2 1.1 Aufgaben einer Datenbank...................... 2 1.2 Geschichtliche Entwicklung

Mehr

DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER

DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER INHALTSVERZEICHNIS 1. Datenbanken 2. SQL 1.1 Sinn und Zweck 1.2 Definition 1.3 Modelle 1.4 Relationales Datenbankmodell 2.1 Definition 2.2 Befehle 3.

Mehr

ENTERBRAIN Reporting & Business Intelligence

ENTERBRAIN Reporting & Business Intelligence Überblick Vorhandene Listen/Analysen in ENTERBRAIN Die Daten in ENTERBRAIN Das Fundament des BI - Hauses Details zur ENTERBRAIN Staging Area Reports und Cubes auf Basis der Staging Area Data Mining mit

Mehr

WAHLPFLICHTBEREICH WIRTSCHAFTSINFORMATIK 'DATA WAREHOUSE'

WAHLPFLICHTBEREICH WIRTSCHAFTSINFORMATIK 'DATA WAREHOUSE' Take control of your decision support WAHLPFLICHTBEREICH WIRTSCHAFTSINFORMATIK 'DATA WAREHOUSE' Sommersemester 2008 Gliederung Business Intelligence und Data Warehousing On-Line Analytical Processing Ziel

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

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

ER-Modellierung am Beispiel der Universitätsdatenbank aus der DBIS-Vorlesung

ER-Modellierung am Beispiel der Universitätsdatenbank aus der DBIS-Vorlesung ER-Modellierung am Beispiel der Universitätsdatenbank aus der DBIS-Vorlesung Datenbank-Praktikum SS 2010 Prof. Dr. Georg Lausen Florian Schmedding ER-Modell: Wiederholung Entitäten E Beziehungen B Attribute

Mehr

Integritätsbedingungen / Normalformen- Beispiel: Kontoführung

Integritätsbedingungen / Normalformen- Beispiel: Kontoführung Technische Universität München WS 2003/04, Fakultät für Informatik Datenbanksysteme I Prof. R. Bayer, Ph.D. Lösungsblatt 8 Dipl.-Inform. Michael Bauer Dr. Gabi Höfling 12.01. 2004 Integritätsbedingungen

Mehr

Uni Duisburg-Essen Fachgebiet Informationssysteme Prof. Dr. N. Fuhr

Uni Duisburg-Essen Fachgebiet Informationssysteme Prof. Dr. N. Fuhr Raum: LF 230 Bearbeitung: 9.-11. Mai 2005 Datum Gruppe Vorbereitung Präsenz Aktuelle Informationen unter: http://www.is.informatik.uni-duisburg.de/courses/dbp_ss03/ Tabellen in IBM DB2 Tabellen Eine relationale

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

Cassandra Query Language (CQL)

Cassandra Query Language (CQL) Cassandra Query Language (CQL) Seminar: NoSQL Wintersemester 2013/2014 Cassandra Zwischenpräsentation 1 Gliederung Basic facts Datentypen DDL/DML ähnlich zu SQL Besonderheiten Basic facts CQL kurz für

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

IM FOKUS: DESIGN & MANAGEMENT VON DATA WAREHOUSES

IM FOKUS: DESIGN & MANAGEMENT VON DATA WAREHOUSES 10 IM FOKUS: DESIGN & MANAGEMENT VON DATA WAREHOUSES Step by Step Zehn Schritte für ein erfolgreiches Data Warehouse Design IM FOKUS: DESIGN & MANAGEMENT VON DATA WAREHOUSES Data Warehouse Technologie

Mehr

Business Intelligence

Business Intelligence Business Intelligence Anwendung 1 MInf1 HAW Hamburg Betreuender Professor: Prof. Dr. Zukunft by Jason Hung Vuong [12] Gliederung 1. Hamburg Energie Kooperation 2. Motivation 3. Business Intelligence 4.

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

Data Warehouse. Kapitel 16. Abbildung 16.1: Zusammenspiel zwischen OLTP und OLAP. Man unterscheidet zwei Arten von Datenbankanwendungen:

Data Warehouse. Kapitel 16. Abbildung 16.1: Zusammenspiel zwischen OLTP und OLAP. Man unterscheidet zwei Arten von Datenbankanwendungen: Kapitel 16 Data Warehouse OLTP Online Transaction Processing OLAP Online Analytical Processing Decision Support-Anfragen Data Mining operationale DB operationale DB operationale DB Data Warehouse operationale

Mehr

Business Intelligence Praktikum 1

Business Intelligence Praktikum 1 Hochschule Darmstadt Business Intelligence WS 2013-14 Fachbereich Informatik Praktikumsversuch 1 Prof. Dr. C. Wentzel Dipl. Inf. Dipl. Math. Y. Orkunoglu Datum: 14.10.2013 Business Intelligence Praktikum

Mehr

Relationale Datenbanken Kursziele

Relationale Datenbanken Kursziele Relationale Datenbanken Kursziele DB Grundlagen Daten-Modellierung Relationales Modell und DB => Praxis: Mit SQL als Anfragesprache Mit MySQL als DB RDB 1-1 Kursinhalt (Tage) 1. Einleitung / Entity-Relationship

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

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

Hinweise zur Klausur Zusammenfassung OPAL-Übungen / Kontrollfragen Fragen Vertiefung Modellierung

Hinweise zur Klausur Zusammenfassung OPAL-Übungen / Kontrollfragen Fragen Vertiefung Modellierung Komponenten und Architekturen von Analytischen Informationssystemen (AIS) Melanie Pfoh Konsultation Zusammenfassung OPAL 24. Juni 2014 Agenda Hinweise zur Klausur Zusammenfassung OPAL-Übungen / Kontrollfragen

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

Intelligente Kanzlei

Intelligente Kanzlei Seite 1 von 5 Intelligente Kanzlei Datawarehouse und OLAP in der Steuerkanzlei Notwendigkeit eines Kanzleiinformationssystems Seit einigen Jahren sind enorme Veränderungen am Beratungsmarkt durch einen

Mehr

Realisierung von OLAP Operatoren in einem visuellen Analysetool. Vortrag von Alexander Spachmann und Thomas Lindemeier

Realisierung von OLAP Operatoren in einem visuellen Analysetool. Vortrag von Alexander Spachmann und Thomas Lindemeier Realisierung von OLAP Operatoren in einem visuellen Analysetool Vortrag von Alexander Spachmann und Thomas Lindemeier Gliederung Ausgangssituation/Motivation Was ist OLAP? Anwendungen Was sind Operatoren?

Mehr

Hochschule Darmstadt Business Intelligence WS 2013-14 Fachbereich Informatik Praktikumsversuch 3. Aufgabenstellung

Hochschule Darmstadt Business Intelligence WS 2013-14 Fachbereich Informatik Praktikumsversuch 3. Aufgabenstellung Hochschule Darmstadt Business Intelligence WS 2013-14 Fachbereich Informatik Praktikumsversuch 3 Prof. Dr. C. Wentzel Dipl. Inf. Dipl. Math. Y. Orkunoglu Datum: 18.12.2013 1. Kurzbeschreibung Dieses Praktikum

Mehr

Christian Kurze BI-Praktikum IBM WS 2008/09

Christian Kurze BI-Praktikum IBM WS 2008/09 Einführung in die multidimensionale Datenmodellierung e mit ADAPT BI-Praktikum IBM WS 2008/09 1 Gliederung Einführung multidimensionale Datenmodellierung 1. Multidimensionales Modell BI-Praktikum IBM WS

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

Einsatz des Enterprise Guide in der Lehre - Data Warehousing zum Anfassen und Explorieren -

Einsatz des Enterprise Guide in der Lehre - Data Warehousing zum Anfassen und Explorieren - Lehre Einsatz des Enterprise Guide in der Lehre - Data Warehousing zum Anfassen und Explorieren - Hans-Günter Lindner FH Frankfurt am Main Nibelungenplatz 1 60318 Frankfurt am Main lindner@fb2.fh-frankfurt.de

Mehr

Star-Schema-Modellierung mit ERwin - eine kritische Reflexion der Leistungspotentiale und Anwendungsmöglichkeiten

Star-Schema-Modellierung mit ERwin - eine kritische Reflexion der Leistungspotentiale und Anwendungsmöglichkeiten Star-Schema-Modellierung mit ERwin - eine kritische Reflexion der Leistungspotentiale und Anwendungsmöglichkeiten Michael Hahne T&I GmbH Workshop MSS-2000 Bochum, 24. März 2000 Folie 1 Worum es geht...

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

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector 7.4 Analyse anhand der SQL-Trace 337 7.3.5 Vorabanalyse mit dem Code Inspector Der Code Inspector (SCI) wurde in den vorangegangenen Kapiteln immer wieder erwähnt. Er stellt ein paar nützliche Prüfungen

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

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015 Abstrakt zum Vortrag im Oberseminar Graphdatenbanken Gero Kraus HTWK Leipzig 14. Juli 2015 1 Motivation Zur Darstellung komplexer Beziehungen bzw. Graphen sind sowohl relationale als auch NoSQL-Datenbanken

Mehr

Business Intelligence Aufgabenstellung

Business Intelligence Aufgabenstellung Hochschule Darmstadt Business Intelligence (BI) Fachbereich Informatik Praktikum 2 Prof. Dr. C. Wentzel Dipl. Inf. Dipl. Math. Y. Orkunoglu Sebastian Gobst Änderung: 15.06.2012 Datum: 30.05.2012 1. Einführung

Mehr

Data Cube. Aggregation in SQL. Beispiel: Autoverkäufe. On-line Analytical Processing (OLAP) 1. Einführung. 2. Aggregation in SQL, GROUP BY

Data Cube. Aggregation in SQL. Beispiel: Autoverkäufe. On-line Analytical Processing (OLAP) 1. Einführung. 2. Aggregation in SQL, GROUP BY Data Cube On-line Analytical Processing (OLAP). Einführung Ziel: Auffinden interessanter Muster in großen Datenmengen 2. Aggregation in SQL, GROUP BY 3. Probleme mit GROUP BY 4. Der Cube-Operator! Formulierung

Mehr

Kapitel DB:III. III. Konzeptueller Datenbankentwurf

Kapitel DB:III. III. Konzeptueller Datenbankentwurf Kapitel DB:III III. Konzeptueller Datenbankentwurf Einführung in das Entity-Relationship-Modell ER-Konzepte und ihre Semantik Charakterisierung von Beziehungstypen Existenzabhängige Entity-Typen Abstraktionskonzepte

Mehr

Logische Modellierung von Data Warehouses

Logische Modellierung von Data Warehouses Logische Modellierung von Data Warehouses Vertiefungsarbeit von Karin Schäuble aus Lörrach BERUFSAKADEMIE LÖRRACH STAATLICHE STUDIENAKADEMIE UNIVERSITY OF COOPERATIVE EDUCATION Ausbildungsbereich Wirtschaft

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

Einführung in SQL. Sprachumfang: Indizes. Datensätzen. Zugriffsrechten

Einführung in SQL. Sprachumfang: Indizes. Datensätzen. Zugriffsrechten Einführung in SQL Die Sprache SQL (Structured Query Language) ist eine Programmiersprache für relationale Datenbanksysteme, die auf dem ANSI-SQL-Standard beruht. SQL wird heute von fast jedem Datenbanksystem

Mehr

Datenbanktechnologie mit praktischen Übungen in MySQL und PHP

Datenbanktechnologie mit praktischen Übungen in MySQL und PHP Datenbanktechnologie mit praktischen Übungen in MySQL und PHP Übung, Sommersemester 2013 29. April 2013 - MySQL 2 Sebastian Cuy sebastian.cuy@uni-koeln.de Aufgaben Anmerkungen Best practice: SQL Befehle

Mehr

Einstieg in relationale Datenbanken mit MySQL. Dr. Kerstin Puschke September 2009

Einstieg in relationale Datenbanken mit MySQL. Dr. Kerstin Puschke September 2009 Einstieg in relationale Datenbanken mit MySQL Dr. Kerstin Puschke September 2009 1 Lizenz Lizenz Dieser Text steht unter einer Creative Commons Attribution-Share Alike 3.0 Germany Lizenz, siehe http://creativecommons.org/licenses/by-sa/3.0/de/

Mehr

Data Warehousing und BI

Data Warehousing und BI Data Warehousing und BI IT-Spezialisierung Informationswirtschaft Vertiefungskurs VI Seminararbeit Betreuer: Priv. Doz. Dr. Michael Hahsler Christian Deutsch 03.07. 2007 Abstract Die vorliegende Arbeit

Mehr

Vertrautmachen mit Daten

Vertrautmachen mit Daten Kapitel III Vertrautmachen mit Daten 2004 AIFB / FZI 1 III Vertrautmachen mit Daten (see also Data Preparation ) 2004 AIFB / FZI 2 III Vertrautmachen mit Daten III.1 OLAP III.1.1 Einführung in OLAP Wie

Mehr

Multidimensionales Datenmodell. Motivation. Motivation /2. Grundbegriffe. Analyseoperationen. Notationen zur konzeptuellen Modellierung

Multidimensionales Datenmodell. Motivation. Motivation /2. Grundbegriffe. Analyseoperationen. Notationen zur konzeptuellen Modellierung Multidimensionales Datenmodell Grundbegriffe Dimensionen, Fakten/Kennzahlen, Würfel Analyseoperationen Drill-Down, Roll-Up, Slice und Dice Notationen zur konzeptuellen Modellierung ME/R,ADAPT,graphbasierteAnsätze

Mehr

EDV-GESTÜTZTES ENTWERFEN, BERECHNEN UND KONSTRUIEREN IM BAUINGENIEURWESEN Prof. Dr.-Ing. Klaus Wassermann MODULPRÜFUNG

EDV-GESTÜTZTES ENTWERFEN, BERECHNEN UND KONSTRUIEREN IM BAUINGENIEURWESEN Prof. Dr.-Ing. Klaus Wassermann MODULPRÜFUNG EDV-GESTÜTZTES ENTWERFEN, BERECHNEN UND KONSTRUIEREN IM BAUINGENIEURWESEN Prof. Dr.-Ing. Klaus Wassermann MODULPRÜFUNG Bachelorstudiengang Facility Management Informatik am 26. September 2007 Name, Vorname

Mehr

Einführung in SQL Datenbanken bearbeiten

Einführung in SQL Datenbanken bearbeiten Einführung in SQL Datenbanken bearbeiten Jürgen Thomas Entstanden als Wiki-Buch Bibliografische Information Diese Publikation ist bei der Deutschen Nationalbibliothek registriert. Detaillierte Angaben

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

Implementierung eines Data Marts. Gunther Popp dc soft GmbH

Implementierung eines Data Marts. Gunther Popp dc soft GmbH Implementierung eines Data Marts Gunther Popp dc soft GmbH Überblick Vorstellung der Beispielanwendung Prozeß zur Erstellung eines Data Marts - Design - Datenermittlung - Implementierung Erläutert am Beispiel-Mart

Mehr

Erste Schritte, um selber ConfigMgr Reports zu erstellen

Erste Schritte, um selber ConfigMgr Reports zu erstellen Thomas Kurth CONSULTANT/ MCSE Netree AG thomas.kurth@netree.ch netecm.ch/blog @ ThomasKurth_CH Erste Schritte, um selber ConfigMgr Reports zu erstellen Configuration Manager Ziel Jeder soll nach dieser

Mehr

Übung Datenbanksysteme

Übung Datenbanksysteme Übung Datenbanksysteme Martin Reifberger Übungsaufgabe 1 Sachverhalt: Ein mittelständiges Industrieunternehmen möchte sein Auftragswesen datenbankbasiert organisieren, da die tägliche Flut auflaufender

Mehr