Am 14. September 2017 haben wir eine überarbeitete Fassung unserer Datenschutzrichtlinie veröffentlicht. Wenn Sie video2brain.com weiterhin nutzen, erklären Sie sich mit diesem überarbeiteten Dokument einverstanden. Bitte lesen Sie es deshalb sorgfältig durch.

SQL Server Analysis Services im mehrdimensionalen Modus Grundkurs

Theoretische Konzepte, die Appetit machen

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Bei vielen Ideen von Ralph Kimball merkt man sofort, dass sie unmittelbar aus der praktischen Anwendung in BI-Projekten entstanden sind. Die Kurzvorstellung einiger Konzepte soll dazu anregen, Kimballs Design-Prinzipien praktisch einzuführen.
04:51

Transkript

In diesem einführenden Video möchte ich von den vier einfachen Schritten berichten, die nach dem sehr erfolgreichen Data Warehouse Theoretiker Ralph Kimball am Anfang jedes Data Warehouse Projeks stehen, und die vielleicht klar machen, wie einfach man nach seinen Methoden vorgehen kann. Der erste Schritt ist das Wählen des Prozesses, des Themas. Worum geht's eigentlich in dem Data Mart? Bei unserem simplen Verkaufsbeispiel geht's natürlich insbesondere um Verkaufszahlen und alles, was einen Einfluss darauf hat. Der nächste Schritt wäre der, die Granularität zu ermitteln, sich also zu überlegen, welche Details man eigentlich ins Data Warehouse, oder Data Mart, wie Kimball oft sagt, mit rüber nimmt. Ein etwas veralteter Ratschlag. Heute denkt man da nicht mehr so lange drüber nach, denn die heutigen Datenbanksysteme sind so schnell geworden, dass man eigentlich sagt, nimm alles mit, was du nur irgendwie kriegen kannst, am besten bis auf die Einzelbuchung. Früher hingegen, hat man öfter mal sowas wie Tagessummen gebildet, oder gar Monatsnamen, Jahressummen und diese abgelegt, weil die Performance nicht gereicht hat. Das ist aber heute vorbei. Heute gilt wirklich, alles mitnehmen an Detail-Info, was man kriegen kann bis hin zu den Einzelbuchungen. Der ditte Schritt ist wieder typisch Kimball, nämlich er gesagt, denke darüber nach, welche gemeinsamen Dimensionen du mit mehr als einer Faktentabelle, mehr als einmal in deinem Data Warehouse verwenden kannst. Bestes Beispiel dafür ist die Zeitdimension und die Tabelle hinter der Zeitdimension. Die kann ich wirklich überall verwenden, wo es um Datumswerte geht. Aber wenn ich eben Mitarbeiter zum Beispiel öfter habe als Einkäufer oder als Verkäufer, dann kann ich auch dort eine gemeinsame Dimension bauen und sie immer wieder und wieder verwenden. Und der vierte und letzte Schritt wäre dann der, Fakten und Kennzahlen auszuwählen, die in der Granularität des Data Mart vorhanden sind, und sie sollten additiv sein, müssen sie aber nicht. Bei unserem Verkaufsbeispiel zum Beispiel haben wir Umsätze, die sind additiv, da haben wir Kosten, die sind additiv, zum Beispiel Stückzahlen, die additiv sind. Wenn wir aber zum Beispiel auch Preisdaten haben, dann sind die nicht unbedingt additiv. Allein die Tatsache, dass ich da Preise habe, wenn ich die dann aufsummiere, kommt ziemlicher Unsinn bei raus. Ich muss sie erst mit der Stückzahl malnehmen. Aber auch ist denkbar. Das zeigt einfach nur mal, wie simpel und einfach Kimball vorgeht in seine ersten leichten Schritten. Habe ich erstmal so eine Data Mart definiert, ich sage mal mit einer Faktentabelle und entsprechenden Deminsionen drum herum, dann hat Kimball auch eine schöne Lösung dafür, wie ich dann mit mehreren verschiedenen Faktentabellen umgehe. Das ist dann die sogenannte Data Warehouse Bus Matrix, die er sich hat einfallen lassen. Unsere bisherigen Beispiele haben sich alle auf Verkaufszahlen, Store Sales, bezogen. Store Sales, das wäre die Faktentabelle dazu, symbolisiert... kann ich mit allerlei Dingen verbinden. Zum Beispiel mit dem Datum, wann wurde verkauft? Mit dem Produkt, was wurde da gekauft? Dem Laden, der Werbeaktion. Das ist alles relativ easy und simpel. Was ist aber, wenn ich zum Beispiel auch Lagerbestände auswerten will? Store Inventory. Das wären erstmal Zahlen, die nicht additiv sind, aber das Problem lösen wir später. Wonach kann ich die auswerten? Natürlich auch nach Datum, ist ja klar, natürlich auch nach Produkt und nach Store eben, wie viel liegt in diesem Laden herum? Aber die anderen Dinge, eben z.B. die Werbeaktion, die kann ich zu dem Zeitpunkt mit dem Store Inventory, mit dem Inventar nicht in Verbindung bringen. Das heißt, hier gibt es einfach keine Verbindung. Es wird also zwischen der Faktentabelle, Store Inventory, und der Dimensionstabelle, Werbeaktion/Promotion, später keine Verbindung geben. Um das noch mal deutlicher zu machen, sehen wir uns mal das dritte Beispiel an. Das ist der Einkauf logischerweise. Wenn ich also diese Sachen irgendwann mal eingekauft habe, dann kann ich diesen Einkauf auch nach Datum auswerten, ist ja klar. Auch nach Produkt, denn das habe ich gerade gekauft. Auch nach Ladengeschäft? Nein, natürlich nicht. Zum Zeitpunkt des Einkaufs ist ja noch gar nicht klar, in welchem Laden später mal der Artikel verkauft werden wird. Und nach Promotion? Nein, auch das nicht. Die Werbeaktion entscheidet man weitaus später. Aber was ich natürlich tun kann, ich kann auswerten nach Lagerhaus, wo das Ganze abgelegt wird, ich kann zum Beispiel nach Vendor, wo habe ich es eingekauft, bei welchem Großhändler, unterscheiden und ich kann nach Logistiker unterscheiden, der mir das Ganze geliefert hat. Und aus dieser Bus Matrix ergibt sich langsam die Verbindung zwischen den gemeinsamen Dimensionstabellen und den Faktentabellen und das alles ist für unser Projekt hochgradig relevant, denn ich kann ganz klar sagen, dass die Entwickler bei Microsoft, die die Analysis Services entworfen haben, alles Kimballisten sind, die also Ralph Kimball's Werke sehr gut kennen, geradezu eingeatmet haben, direkt bei sich auf dem Schreibtisch stehen haben und solche Prinzipien, wie Kimball sie sich ausgedacht hat, sehr, sehr gut in den Analysis Services später realisiert haben. Macht vielleicht doch noch mal Lust, in einem von Ralph Kimball's Werken nachzulesen.

SQL Server Analysis Services im mehrdimensionalen Modus Grundkurs

Lernen Sie eigene OLAP-Cubes und -Lösungen mit dem multidimensionalem Modus der SQL Server Analysis Services zu erstellen.

3 Std. 57 min (54 Videos)
Derzeit sind keine Feedbacks vorhanden...
 
Hersteller:
Software:
Exklusiv für Abo-Kunden
Erscheinungsdatum:25.04.2017

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!