Aufbau eines Data Warehouse - Arbeitsschritte

Question

Hallo liebes Forum,

ich bin gerade dabei ein Data Warehouse aufzubauen und möchte gerne meine Arbeitsschritte mit Euch besprechen.

Ausgangsbasis ist die Beispieldatenbank der Kronus AG von MS Dynamics Nav. Das DW soll mit dem SQL Server 2012 aufgebaut werden und anschließend mit einem OLAP Cube ausgewertet werden.
Da es sich um mein erstes Data Warehouse handelt und ich keine genaue Anleitung zur techn. Umsetzung gefunden habe, hoffe ich auf Eure Mithilfe.

Die Daten der Kronus AG sind in einer Datenbank abgespeichert, die direkt in SSMS geladen werden kann.

Mein geplantes Vorgehen:

Zuerst möchte ich die Datenbankstruktur des DW erstellen. Hier plane ich einen leeren Cube in SSAS zu erstellen, dessen Tabellen im Anschluss mit den jeweiligen Daten aus der operativen Datenbank gefüllt werden soll. Den ETL-Prozess möchte ich mit T-Sql Anweisungen abbilden. An dieser Stelle habe ich noch etwas Lesebedarf... Ich habe mir "stored procedures" und "trigger" angesehen und bin für mich zur Erkenntnis gekommen, dass stored procedures eine vorprogrammierte Anweisung darstellen, die erst durch manuellen Anstoß der stored procedure durchgeführt wird. Unter trigger verstehe ich eine vorprogrammierte, serverseitige Anweisung, die automatisch angestoßen wird, wenn ein bestimmtes Ereignis (Eintrag/Änderung eines neuen Datensatzes in die betroffene Tabelle) eintritt.
Die operative Datenbank ist in meinem Fall nur 200 MB groß und muss einmal pro Monat um die neuen Datensätze upgedated werden. Insofern denke ich es könnten beide Methoden verwendet werden. Spricht man bei der Verwendung von Triggern von einem Real-Time-Data Warehouse? und wirken sich trigger negativ auf die performance großer Datenbanken aus? Sind Trigger in meinem Fall die elegantere Alternative?
Was haltet Ihr von meinem geplanten Vorgehen?

Das Data Warehouse soll dazu genutzt werden, die vergangenen Sales und Produktionsdaten mit einem OLAP-Cube auszuwerten und dem Management zur zukünftigen Planung dienen. Daher suche ich zudem eine geeignete Methode die Planwerte in die Datenbank zu speichern. Die Analyse der realisierten Ist-Werte aus der Vergangenheit findet über PowerPivot in Excel statt. Bietet der SQL-Server eine elegante Lösung für den Datenimport der Planwerte? (Bei der Open Source Software "Palo" hat das Management die Möglichkeit Measures direkt in den Cube einzugeben. Bei Eingabe auf einer Parent-Ebene wird der Wert automatisch auf die Kindelemente heruntergebrochen.)

Eine weitere Frage, die mich beschäftigt: Wenn ich die zukünftigen Planwerte direkt in Plan-GuV und Plan-Bilanz integrieren möchte, müssen dann die Werte für Guv und Bilanz auch über eine Datenbank/Cube abgebildet/errechent werden? oder sollten diese Werte besser in Excel geplant und verrechnet werden?

Ich hoffe das waren jetzt nicht zu viele Fragen auf einmal und Ihr könnt mir gute Anregungen zu meinem Vorhaben geben.
Vielen Dank bereits für Eure Antworten!
VG Sebastian 

Answer 1

Hallo Sebastian,

eine genaue technische Anleitung für den Aufbau eines Dataware Houses gibt es aus dem einfachen Grunde nicht, weil es immer Anforderungsgetrieben ist und jede Anforderung ist nun mal anders. Es gibt aber Konzepte zu dem Thema, das bekannteste ist die von Ralph Kimball, sein Buch ist sozusagen das Standardwerk zum Thema.

Deine bisherigen Überlegungen "ignoriere ich unfreundlicher weise" mal, den die gehen eher in die nicht richtige Richtung.

Ausgangsbasis ist ein (oder mehrere) OLTP System(e), in der die Daten möglichst normalisiert gespeichert werden; das erlaubt hohe Schreibgeschwindigkeit, ist aber für umfangreiche Auswertungen suboptimal; dafür verwendet man eben das DWH.

In einem DWH liegen die Daten in geringer normalisierten bzw. komplett denormalisierter Form vor, um Abfragen mit wenig JOINs zu ermöglichen und so performate Auswertungen zu erhalten. Um die Daten OLTP => DWH zu überführen, nutzt man separate ETL Prozesse; auf keinen Fall so was direkt gekoppeltes wie Trigger oder Stored Procedure. Das würde auf die Performanz gehen und das DWH müsste immer unverändert verfügbar sein; ein No-Go.
Statt dessen verwendet man ETL Tool wie SSIS = SQL Server Integration Services, um die Daten modelliert zu übertragen.

Aus dem DWH kann man dann einen SSAS Cube modellieren, nicht umgekehrt.

Was die Planwerte betrifft, die gleiche Funktion wie in Palo gibt es im SSAS auch, nennt sich WriteBack Funktion, dabei werden dann die umgerechneten, erfassten Planwert in die relationale Datenquelle (dem DWH) wieder zurück geschrieben.

---

Olaf Helper
Blog Xing

Answer 2

Hallo TimeSeries,

Ich gehe davon aus, dass die Antwort Dir weitergeholfen hat.
Solltest Du noch "Rückfragen" dazu haben, so gib uns bitte Bescheid.

Grüße,
Robert

---

Robert Breitenhofer, MICROSOFT   Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „Entwickler helfen Entwickler“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

Answer 3

Vielen Dank, das war eine sehr gute Erklärung.