Data Warehouse - Modellierung

[OnkelPaddy]

Hallo zusammen,

ich habe die Aufgabe, ein Data Warehouse (DWH) aufzubauen.

Aktuell gibt es keins. Die Quelldaten liegen in verschiedenen Systemen

und sind teilweise inkonsistent.

Bislang habe ich nur kleinere Analysen mittels OLAP erstellt, aber noch nie

ein DWH modelliert. Ich habe damit begonnen, aus einem

Unternehmensbereich Daten per SSIS zu selektieren und in neue Entitäten

zu schreiben. Allerdings frage ich mich, ob es sinnvoll ist, die Daten normalisiert in der DB zu erstellen, oder ob es nicht geschickter ist, eine

denormalisierte Form zu wählen.

Ich bin auf das Problem gestossen, da ich bereits jetzt eine Vielzahl von

Tabellen habe. Diese müsste ich für OLAP Analysen stark verdichten. Das

würde aber riesige, unübersichtliche Queries verursachen.

Meine Frage ist: kennt sich jemand mit so etwas aus und kann mir die

Richtung zeigen, in die ich gehen soll (Link, Tutorial, Buchtipp, irgendwas)?

Laufen kann ich dann alleine.

1: Macht es sinn, normalisierte Daten zu speichern und diese anschließend zu

Dimensionstabellen und Faktentabellen zusammenzufassen?

2: Sollte ich evtl. gleich die Daten als Dimensions-, Faktentabellen in denormalisierter Form anlegen?

3: Muss ich die einzelnen Datenmodelle (Stern- vs. Schneeflockenschema)

bereits im DWH anlegen oder macht man das idR erst später im Datenmodell

des OLAP Cubes?

Hat irgendjemand einen Hinweis für mich?

Viele Grüße

[Schmarrer]

Hi,

also ich hab unser DataWareHouse (SQL Server 2005) mit aufgebaut und betreue dieses noch.

Wir verfahren so, dass wir die Daten aus den Quellsystemen ersteinmal (fast) 1:1 in eine Datenbank innerhalb des SQL Servers entladen. Hier werden vielleicht nur ein paar kleine Anpassungen von Datumswerten oder Null- bzw. leere Spalten vorgenommen. Hier werden alle benötigten Tabellen entladen, ohne etwas wegzulassen.

Von da aus gehts dann in weitere Bereiche (Datenbanken), wo das "relationale OLAP Modell" erstellt wird. Also sprich Faktentabellen und Dimensionstabellen. Schlüsselbeziehungen machen hier sicherlich auch Sinn (können aber auch weg gelassen werden), jedoch würde ich in der Faktentabelle auf "einfache" Primärschlüssel verzichten, da es in so einem OLAP Modell schnell mal zu einer Auffächerung von Datensätzen kommt.

Für jede Dimension gibt es also mindestens eine Tabelle oder View. Genau das selbe für die Measuregruppen/Faktentabellen.

Die logische Zuordnung, also Stern- oder Schneeflockenschema wird dann eigentlich im OLAP Modell getroffen. Ein richtiges Schneeflockenschema benutzen wir im SQL Server 2005 nicht mehr. Hier hast du nämlich über Hierarchien und deren Ebenen alle möglichen und du benötigst hierfür nur eine Tabelle.

Zum Thema verdichten der Daten: Ich habe die Erfahrung gemacht, dass es manchmal besser ist, den OLAP Prozessor die Aggregationen vornehmen zu lassen und auf relationaler Ebene daher nicht unbedingt ein "GROUP BY" anzuwenden. Geht ganz fix, da die OLAP Technologie ja extra dafür ausgelegt ist.

Als Buchtipp kann ich dir "Business Intelligence und Reporting mit SQL Server 2005" (Microsoft Press) empfehlen. Hier werden auch die Analysis Services, Reporting Services und Integration Services behandelt.

Ich weiß das ist jetzt alles vielleicht ein bisschen "durcheinander", aber das Thema ist so gewaltig groß, dass man manchmal gar nicht weiß wo man anfangen soll.

Aber bei Fragen helfe ich gern weiter...

Gruß

[dbwizard]

Hat irgendjemand einen Hinweis für mich?

Viele Grüße

Hallo,

Schau dir dies mal an. Vielleicht kann es etwas die Richtung aufzeigen, obwohle es natürlich stark "Komprimiert" dargestellt ist.

http://www.trivadis.com/uploads/tx_cabagdownloadarea/DWH_schnell_gemacht.pdf

(und nein, ich arbeite nicht dort :-)

Gruss

[OnkelPaddy]

Hallo ihr 2,

vielen Dank für die Infos. Das hat mir schon etwas geholfen. Das Buch habe

ich bereits hier liegen. Das OLAP und SSIS sind auch schön erklärt, aber

leider wenige Handlungshilfen beim Planen eines kompletten DWH.

...aber das Thema ist so gewaltig groß, dass man manchmal gar nicht weiß wo man anfangen soll.

Genau das ist mein Problem. Aber nach deiner Ausführung und dem Link von

dbwizard habe ich jetzt eine grobe Richtung. Das PDF ist zwar sehr kurz, aber

es ist recht anschaulich der gesamte Prozess dargestellt. Das hat mir schon

geholfen.

Vielen Dank

PS: weitere Tipps werden gerne entgegen genommen.

[OnkelPaddy]

Hi,

mir drängt sich gerade noch eine Frage auf:

Wenn ihr die Daten erstmals aus den unterschiedlichsten Datenbeständen

ladet (in Staging Area), macht ihr dann auch schon erste Selektionen

auf bestimmte Spalten oder gar Zeilen?

Ich habe es hier zum Teil mit sehr breiten Spalten zu tun, von denen mich

aber nur wenige wirklich interessieren.

Wenn ich das DWH streng getrennt in mehreren Schritten (jede Vorstufe als

eigene DB) fülle, erhalte ich doch eine unglaubliche Fülle an redundanten Daten.

Entsteht da nicht ein Berg an Datenmüll?

[Schmarrer]

Hi,

also gewissene Vorselektionen kannst du sicherlich machen, aber dies tun wir eigentlich nicht. Grund: Der Einfallsreichtum der späteren Berichtsredakteure!!!

Nimmst du nur die Spalten (oder z.b. nur das Jahr) die du vermeindlich brauchst, klappt das zwar wunderbar am Anfang, aber wenn du dann eine Erweiterung hast (glaube mir, die wird sicherlich kommen), dann hast du mehr Aufwand als dir vielleicht lieb ist.

Unsere breiteste Tabelle in der Datastagingarea (dsa)hat ca. 250 Spalten

Redundanzen hast du dadurch sicherlich (dsa und die jeweilige DB´s für das relationale Modell), aber denke auch an die Formatierung und Anpassung der Datensätze in den weiteren DB´s im Gegensatz zu der Datastagingarea. Aber ich geb dir recht, redundanzen entstehen. Aber mit den heutigen Speicherkapazitäten dürften das doch nicht das Problem dabei sein!?

Gruß

[OnkelPaddy]

Hallo zusammen,

ich habe, wie in dem PDF vorgeschlagen, drei Datenbanken angelegt.

In der ersten, der Loading Area habe ich die Daten so wie sie sind aus den

Fremdsystemen übernommen. In der Clearing Area habe ich dann nur noch die Spalten drin, die mich interessieren. Ich habe hier Typkonvertierungen gemacht und neue/zusätzliche Hierarchien etc. angelegt.

Nun sollte es von hier aus in die Core Area gehen. Meine Daten liegen nun angepasst in den Tabellen des Clearing Bereiches.

Meine Frage: Wird bei der Übertragung von hier zum Core noch irgendwas mit

den Daten gemacht? Werden die Daten im Core denormalisiert oder bereits im Clearing Bereich? Leider gibt das Dokument das nicht her.

Oder findet die Denormalisierung erst in den DataMarts statt?

[Schmarrer]

Hi,

also ich finde drei Datenbanken für einen Cube schlicht weg zu viel!

Man muss aber sicherlich auch dazu sagen, dass der ganze BI Bereich so unterschiedlich ist, dass jeder einen andere Ansatz wählt.

Bei drei Datenbanken hast du die von dir angesprochenen Redundanzen natürlich in Perfektion.

Was hälst du von der Vorgehensweise:

Alle Daten liegen in der DSA unangepasst vor. Dann verwendest du in einer anderen Datenbank einen View zur Datenselektion. Vorteil: Die Daten liegen logisch noch in der DSA und bis hier hin hast du noch keine Redundanzen und du kannst sehr schön durch die verschiedenen Funktionen bereits sehr viele Anpassungen vornehmen. Nachteil: Die Select - Statements können durchaus ziemlich groß und komplex sein.

Hast du dir dann per View deine "passende" Tabelle zurecht gemacht, überführst du die Daten per StoredProcedure (insert into.... from VIEW....) in die Dimensions/Faktentabelle.... Danach kannst du in der SP noch updates auf die Tabelle durchführen...

Sprich: Du hast für jede Dimensionstabelle eine Tabelle, einen View und eine StoredProcedure... Werden einige sicherlich vielleicht als kompliziert ansehen, aber wie gesagt, jeder hat seine eigenen Wege!

Man muss natürlich auch bedenken, dass jede zusätzliche Datenbank Speicher alloziiert... Aber das nur so nebenbei...

Gruß

Bearbeitet 16. Juli 2009 von Schmarrer