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,

Konzeptuelle und logische Modellierung eines Data-Warehouse-Systems

Konzeptuelle und logische Modellierung eines Data-Warehouse-Systems Seminar Data Warehousing im Verkehrsbereich Sommersemester 2003 Konzeptuelle und logische Modellierung eines Data-Warehouse-Systems Ling Kong 09.07.2003 Inhaltsverzeichnis 1. Einleitung... 1 2. Multidimensionales

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

Das Multidimensionale Datenmodell

Das Multidimensionale Datenmodell Das Multidimensionale Datenmodell Konzeptuelle Modellierung Umsetzung des Modells Beispiel ER-Modell 2 / 36 Probleme ER-Modellierung Keine Unterscheidung Klassifikation, Attribute, Kenngrößen Dimension

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

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

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

Einführung relationale Datenbanken. Themenblock: Erstellung eines Cube. Schlüssel. Relationenmodell Relationenname Attribut. Problem.

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

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

Vorwort zur 5. Auflage... 15 Über den Autor... 16

Vorwort zur 5. Auflage... 15 Über den Autor... 16 Vorwort zur 5. Auflage...................................... 15 Über den Autor............................................ 16 Teil I Grundlagen.............................................. 17 1 Einführung

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

2 Datenbanksysteme, Datenbankanwendungen und Middleware... 45

2 Datenbanksysteme, Datenbankanwendungen und Middleware... 45 Vorwort 15 Teil I Grundlagen 19 i Einführung In das Thema Datenbanken 21 I.I Warum ist Datenbankdesign wichtig? 26 i.2 Dateisystem und Datenbanken 28 1.2.1 Historische Wurzeln 29 1.2.2 Probleme bei der

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

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

Themenblock: Data Warehousing (I)

Themenblock: Data Warehousing (I) Themenblock: Data Warehousing (I) Praktikum: Data Warehousing und Data Mining Agenda Einführung Data Warehouses Online Transactional Processing (OLTP) Datenmanipulation mit SQL Anfragen mit SQL Online

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

Datenbankentwurf. 4.2 Logischer Entwurf. Kapitel 4. ER-Modell. Umsetzung. Entwurfsdokumentation. relationales Modell. Verbesserung

Datenbankentwurf. 4.2 Logischer Entwurf. Kapitel 4. ER-Modell. Umsetzung. Entwurfsdokumentation. relationales Modell. Verbesserung 4.2 Logischer Entwurf Datenbankentwurf 4.2 Logischer Entwurf 2002 Prof. Dr. Rainer Manthey Informationssysteme Logischer Entwurf: Einordnung Entwurfsdokumentation logische Strukturen "auf dem Papier" konzeptueller

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

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

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

Entwurf von Datenbanken

Entwurf von Datenbanken Bisher: was sind Datenbanken? Wie funktionieren sie? Im Folgenden: wie entwickle ich eine Datenbank? Was ist eine gute Datenbank? Der Datenbankentwurfsprozess Das Entity Relationship (ER) Modell Abbildung

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

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

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

Data-Warehouse-Technologien

Data-Warehouse-Technologien Data-Warehouse-Technologien Prof. Dr.-Ing. Kai-Uwe Sattler 1 Prof. Dr. Gunter Saake 2 1 TU Ilmenau FG Datenbanken & Informationssysteme 2 Universität Magdeburg Institut für Technische und Betriebliche

Mehr

Aufgabe 1: [Logische Modellierung]

Aufgabe 1: [Logische Modellierung] Aufgabe 1: [Logische Modellierung] a) Entwerfen Sie für das von Ihnen entworfene Modell aus Aufgabe 2 des 1. Übungsblattes ein Star-Schema. b) Entwerfen Sie für das vorangegangene Modell einen Teil eines

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

7. Übung - Datenbanken

7. Übung - Datenbanken 7. Übung - Datenbanken Informatik I für Verkehrsingenieure Aufgaben inkl. Beispiellösungen 1. Aufgabe: DBS a Was ist die Kernaufgabe von Datenbanksystemen? b Beschreiben Sie kurz die Abstraktionsebenen

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

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

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

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

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

4 Grundlagen der Datenbankentwicklung

4 Grundlagen der Datenbankentwicklung 4 Grundlagen der Datenbankentwicklung In diesem Kapitel werden wir die Grundlagen der Konzeption von relationalen Datenbanken beschreiben. Dazu werden Sie die einzelnen Entwicklungsschritte von der Problemanalyse

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

3. Das Relationale Datenmodell

3. Das Relationale Datenmodell 3. Das Relationale Datenmodell Das Relationale Datenmodell geht zurück auf Codd (1970): E. F. Codd: A Relational Model of Data for Large Shared Data Banks. Comm. of the ACM 13(6): 377-387(1970) DBMS wie

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

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

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

Multidimensionale Datenbanksysteme

Multidimensionale Datenbanksysteme Multidimensionale Datenbanksysteme Modellierung und Verarbeitung Von Dr.-Ing. Wolfgang Lehner IBM Almaden Research Center, San Jose, USA Technische Universität Darrr:ctadi FACHBEREICH INFORMATIK BIBLIOTHEK

Mehr

WS 2002/03. Prof. Dr. Rainer Manthey. Institut für Informatik III Universität Bonn. Informationssysteme. Kapitel 1. Informationssysteme

WS 2002/03. Prof. Dr. Rainer Manthey. Institut für Informatik III Universität Bonn. Informationssysteme. Kapitel 1. Informationssysteme Informationssysteme Informationssysteme WS 2002/03 Prof. Dr. Rainer Manthey Institut für Informatik III Universität Bonn 2002 Prof. Dr. Rainer Manthey Informationssysteme 1 DB und/oder IS: terminologischer

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

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

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

Datenbanken I - Einführung

Datenbanken I - Einführung - Einführung April, 2011 1 von 30 Outline 1 Organisatorisches 2 Vorlesungsinhalt 3 Begrisklärung 4 Motivation 5 Abstraktion 6 Datenmodelle 7 Literaturangabe 2 von 30 Scheinkriterien Belegübung Regelmäÿige

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

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

9. Einführung in Datenbanken

9. Einführung in Datenbanken 9. Einführung in Datenbanken 9.1 Motivation und einführendes Beispiel 9.2 Modellierungskonzepte der realen Welt 9.3 Anfragesprachen (Query Languages) 9.1 Motivation und einführendes Beispiel Datenbanken

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

IT-Kompaktkurs. Datenbanken Skript zur Folge 5. Prof. Dr. Georg Herde Fachhochschule Deggendorf

IT-Kompaktkurs. Datenbanken Skript zur Folge 5. Prof. Dr. Georg Herde Fachhochschule Deggendorf IT-Kompaktkurs Skript zur Folge 5 Prof. Dr. Georg Herde Fachhochschule Deggendorf Semantisches Datenmodell, Entity-Relationship, Normalformen Bei der Entwicklung einer Datenbank wird das Ziel angestrebt,

Mehr

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Alfons Kemper, Ph.D.

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Alfons Kemper, Ph.D. TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Alfons Kemper, Ph.D. Blatt r. 2 Hausaufgabe Übung zur Vorlesung Grundlagen: Datenbanken im WS3/4 Henrik Mühe (muehe@in.tum.de)

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

Wirtschaftsinformatik 2. Tutorium im WS 11/12

Wirtschaftsinformatik 2. Tutorium im WS 11/12 Wirtschaftsinformatik 2. Tutorium im WS 11/12 Entity/Relationship-Modell SQL Statements Tutorium Wirtschaftsinformatik WS 11/12 2.1 Datenmodellierung mit ERM (1) Datenmodellierung zur Erarbeitung des konzeptionellen

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

Views in SQL. 2 Anlegen und Verwenden von Views 2

Views in SQL. 2 Anlegen und Verwenden von Views 2 Views in SQL Holger Jakobs bibjah@bg.bib.de, holger@jakobs.com 2010-07-15 Inhaltsverzeichnis 1 Wozu dienen Views? 1 2 Anlegen und Verwenden von Views 2 3 Schreibfähigkeit von Views 3 3.1 Views schreibfähig

Mehr

Vorlesung Datenbankmanagementsysteme

Vorlesung Datenbankmanagementsysteme Vorlesung Datenbankmanagementsysteme SQL zur Datenanalyse & Einführung Online Analytical Processing (OLAP) (auf Basis von Oracle) Vorlesung Datenbankmanagementsysteme SQL zur Datenanalyse M. Lange, S.

Mehr

Vorlesung 30.03.2009 1) Einführung

Vorlesung 30.03.2009 1) Einführung Vorlesung 30.03.2009 1) Einführung Was versteht man unter dem Begriff Datenbank? - Eine Datenbank ist eine Struktur zur Speicherung von Daten mit lesendem und schreibendem Zugriff - Allgemein meint man

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

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 27. Juni 2013 Hinweis Diese Folien ersetzen keinesfalls den Übungsstoff des zugehörigen e-learning-kurses.

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

Einteilung von Datenbanken

Einteilung von Datenbanken Datenbanksysteme (c) A.Kaiser; WU-Wien 1 Einteilung von Datenbanken 1. formatierte Datenbanken 2. unformatierte Datenbanken Information Retrieval Systeme 2 Wozu Datenbanken? Speicherung und Verwaltung

Mehr

ABTEILUNGS- ABTEILUNGS- LEITER NAME

ABTEILUNGS- ABTEILUNGS- LEITER NAME Übungsaufgaben Übungsaufgabe 1 - Normalisierung - Gegeben ist folgende unnormalisierte Relation, die Daten über Mitarbeiter und deren Abteilungszughörigkeit enthält. Weiterhin sind die Beteiligung(en)

Mehr

Datenbanken (WS 2015/2016)

Datenbanken (WS 2015/2016) Datenbanken (WS 2015/2016) Klaus Berberich (klaus.berberich@htwsaar.de) Wolfgang Braun (wolfgang.braun@htwsaar.de) 0. Organisatorisches Dozenten Klaus Berberich (klaus.berberich@htwsaar.de) Sprechstunde

Mehr

Datenbanksysteme 2 Frühjahr-/Sommersemester 2014 28. Mai 2014

Datenbanksysteme 2 Frühjahr-/Sommersemester 2014 28. Mai 2014 Lehrstuhl für Praktische Informatik III Prof. Dr. Guido Moerkotte Email: moer@db.informatik.uni-mannheim.de Marius Eich Email: marius.eich@uni-mannheim.de Datenbanksysteme 2 8. Übungsblatt Frühjahr-/Sommersemester

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

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

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

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

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

Star - Schema. AnPr. Name Klasse Datum. ANPR_StarSchema_v03.docx Seite 1

Star - Schema. AnPr. Name Klasse Datum. ANPR_StarSchema_v03.docx Seite 1 Name Klasse Datum 1 OLAP vs. OLTP In den RDBMS Konfigurationen unterscheidet man zwei verschiedene Grundtypen: OLTP: OnLine Transactional Processing ist für die Transaktionsprozesse und somit zur funktionalen

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

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

Kampagnenmanagement mit Siebel Marketing/Oracle BI ein Praxisbericht

Kampagnenmanagement mit Siebel Marketing/Oracle BI ein Praxisbericht Kampagnenmanagement mit Siebel Marketing/Oracle BI ein Praxisbericht Thomas Kreuzer ec4u expert consulting ag Karlsruhe Schlüsselworte: Kampagnenmanagement Praxisbericht Siebel Marketing Oracle BI - ec4u

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

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

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

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

Mehr

Data-Warehouse-Systeme

Data-Warehouse-Systeme 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

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

1. Übungsblatt. Besprechung: 27.10 (Gruppe A), 3.11 (Gruppe B)

1. Übungsblatt. Besprechung: 27.10 (Gruppe A), 3.11 (Gruppe B) DATENBANKEN IN DER PRAXIS: DATA WAREHOUSING Wintersemester 2015/2016 Prof. Dr. Jens Teubner DBIS Group Übung: Dr. Cornelia Tadros ISSI Group Allgemeine Hinweise 1. Übungsblatt Besprechung: 27.10 (Gruppe

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

Frühjahrsemester 2011. Data Warehousing Kapitel 5: Data Warehousing. H. Schuldt. 5.1 Einführung. Filiale Allschwil

Frühjahrsemester 2011. Data Warehousing Kapitel 5: Data Warehousing. H. Schuldt. 5.1 Einführung. Filiale Allschwil Frühjahrsemester Data Warehousing Kapitel 5: Data Warehousing H. Schuldt Wiederholung aus Kapitel 5. Einführung Tresgros Tresgros Tresgros Filiale Muttenz Filiale Allschwil Filiale Liestal Anfragen: Welches

Mehr

Inhalt der Vorlesung. 1 Datenmodellierung (Entity-Relationship Modell) 2 Das relationale Modell. 3 Relationenalgebra. 4 Datenbanksprache (SQL)

Inhalt der Vorlesung. 1 Datenmodellierung (Entity-Relationship Modell) 2 Das relationale Modell. 3 Relationenalgebra. 4 Datenbanksprache (SQL) Inhalt der Vorlesung 1 Datenmodellierung (Entity-Relationship Modell) 2 Das relationale Modell 3 Relationenalgebra 4 Datenbanksprache (SQL) 5 Normalisierung 6 Vom ERM zum Datenbankschema 7 Routinen und

Mehr

6 HANA-optimierte InfoCubes

6 HANA-optimierte InfoCubes 117 HANA-optimierte InfoCubes bilden im»sap BW powered by SAP HANA«das Pendant zu relationalen InfoCubes in BW-Systemen mit relationalen Datenbanksystemen. Obwohl ihr Modell wesentlich auf die spaltenorientierte

Mehr

Das SQL-Schlüsselwort ALL entspricht dem Allquantor der Prädikatenlogik

Das SQL-Schlüsselwort ALL entspricht dem Allquantor der Prädikatenlogik Beispielaufgaben Informationssysteme erstellt von Fabian Rump zur IS Vorlesung 2009/10 1 Multiple Choice Aussage richtig falsch Eine SQL-Abfrage beginnt immer mit dem Schlüsselwort SELECT Eine Datenbank

Mehr

Seminar Data Warehousing. Seminar. Data Warehousing. Thema: Speichermodelle für Data-Warehouse-Strukturen

Seminar Data Warehousing. Seminar. Data Warehousing. Thema: Speichermodelle für Data-Warehouse-Strukturen Seminar Data Warehousing Thema: Speichermodelle für Data-Warehouse-Strukturen Friedrich-Schiller-Universität Jena Fakultät für Mathematik und Informatik Institut für Informatik Lehrstuhl für Datenbanken

Mehr

Frühjahrsemester 2010. Data Warehousing Kapitel 5: Data Warehousing. H. Schuldt. 5.1 Einführung. Filiale Allschwil

Frühjahrsemester 2010. Data Warehousing Kapitel 5: Data Warehousing. H. Schuldt. 5.1 Einführung. Filiale Allschwil Frühjahrsemester Data Warehousing Kapitel 5: Data Warehousing H. Schuldt Wiederholung aus Kapitel 5. Einführung Tresgros Tresgros Tresgros Filiale Muttenz Filiale Allschwil Filiale Liestal Anfragen: Welches

Mehr

Teil 7: Einführung in den logischen Entwurf

Teil 7: Einführung in den logischen Entwurf 7. Einführung in den logischen Entwurf 7-1 Teil 7: Einführung in den logischen Entwurf Literatur: Elmasri/Navathe:Fundamentals of Database Systems, 3. Auflage, 1999. Chapter 3, Data Modeling Using the

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

Null-Werte in Relationalen Datenbanken

Null-Werte in Relationalen Datenbanken Seminar: Imperfektion in Datenbanken WS03/04 Null-Werte in Relationalen Datenbanken Thomas Bierhance Einführung Null-Werte in DBen sind notwendiges Übel, da... (1) das Wissen über die tatsächliche Welt

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

Redundanz: Dieselben Informationen werden doppelt gespeichert.

Redundanz: Dieselben Informationen werden doppelt gespeichert. Kapitel 1 Einführung 1.1 Definition Ein Datenbanksystem (auch Datenbankverwaltungssystem, abgekürzt DBMS = data base management system) ist ein computergestütztes System, bestehend aus einer Datenbasis

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

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

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