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

Datenbankstrukturen für Analysis Services

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Wie sollte eigentlich die SQL-Datenbank aussehen, auf der Analysis-Services-Cubes gebaut werden, und was wird Analysis Services daraus machen? Ein ganz kurzer Exkurs in relationalem Data-Warehouse-Design.
05:31

Transkript

Dieses Video beschäftigt sich mit der Struktur der Datenbanken, auf denen unsere Analysis Services zum Einsatz kommen, und mit dem was die Analysis Services aus dieser Datenbankstruktur dann machen. Zunächst einmal sehen wir hier eine ganz typische relationale Datenbank, so wie sie eigentlich unter fast allen unseren ERP-Systemen und sonstigen Systemen liegen. Die sieht so aus, dass sie eben aus vielen, vielen Tabellen besteht, in dem Beispiel hier sind es 12, das ist natürlich ein Witz, meistens sind es viele Dutzende, oder wie bei SAP sogar zehntausende. Die sind deshalb entstanden, weil man dadurch Redundanz, also Doppelspeicherung, eliminiert hat. Dadurch wird alles in eigene Tabellen ausgelagert, aber die Abfragen werden natürlich viel, viel komplexer. Das Ganze führt aber dazu, dass geringer Speicherplatz gebraucht wird, und die Detail-Operationen, also die Inserts, die Updates, die Leads, diese Operationen, die durch viele gleichzeitige Nutzer gemacht werden, sehr viel schneller werden. Das ist also ein ganz tolles Datenbankmodell, aber für die Auswertung durch Analysis Services sehr, sehr schlecht geeignet. Was sich bei Analysis Services viel, viel besser anbietet, ist ein OLAP-Datenbankmodell, ein sogenanntes Stern-Schema, wie man es hier rechts sieht, benannt nach seiner sternförmigen Anordnung. Und so ein Schema, das ist lustigerweise hier das Schema was genau dieselben Daten enthält wie bei dem Schema davor, davor waren es 12 Tabellen, hier sind es jetzt nur noch 6 übriggeblieben, also es sind weniger Tabellen, bei den gleichen Informationen, die Abfragen werden wesentlich einfacher und damit eben auch schneller. Speicherplatz ist uns dabei egal, wir speichern eben sehr viele Dinge auch mal redundant und doppelt ab, zugunsten einer schnellen Abfrage-Performance. Updates passieren ja in so einem OLAP-Datenbankmodell nicht mehr, hier wird nur noch gelesen, und damit ist das Ganze auch möglich zu optimieren nur auf schnelle Suche, das heißt, man kann ganz viele Indizes einbauen, Suchindizes, dann ist das auch relational schon schnell. Diese Indizes kann man sich übrigens sparen, wenn man es in einen Analysis Services Cube lädt, denn der kann das mit den schnellen Abfragen noch viel besser, als die Datenbank darunter. Ja apropos, wenn man es in einen Cube lädt, dann sieht man, dass bestimmte Datenstrukturen, gerade von Analysis Services Multidimensional, sehr, sehr gut unterstützt werden. Und das ist hier sogar mal etwas, was den Stern ein wenig komplizierter macht, nämlich nicht nur eine Faktentabelle, wie im Beispiel gerade eben, sondern mehrere davon. Das klassische Problem da ist, wenn man zum Beispiel etwas verkauft und man hat Einzelpositionen, Ordered Details, da sind dann zum Beispiel die Mengen drin und die Preise drin und so weiter, und dann habe ich aber im Rechnungskopf zum Beispiel noch Positionen wie Frachtkosten oder so, die eben für die gesamte Rechnung gelten. Und wie kann ich das dann gemeinsam auswerten? Andere OLAP-Server haben da eben größere Schwierigkeiten mit so was. Analysis Services Multidimensional ist da sehr, sehr robust. es macht einfach das, was man relational auch machen würde, nämlich einen Join zwischen den Orders und Order Details Tabellen. Und es macht diesen Join grafisch in der sogenannten Datenquellensicht oder englisch Data Source View. Es ist eine grafische Oberfläche mit der man einfach den Analysis Services sagen kann, wenn Du Informationen aus diesen beiden Tabellen brauchst, dann kommst Du auf diese oder jene Weise an sie heran, Du musst Dir dann einfach einen Join bauen wenn Du die Daten ausliest, dann kannst Du es genauso gut verwenden, als wenn die in einer Tabelle wären. Und das Einzige was von diesen zwei unterschiedlichen Tabellen in unserem Beispiel hier, Ordered Details und Orders, dann übrig bleibt später, was der Anwender immer noch sieht, wenn er auf einem solchen Cube herumbrowst, ist, dass eben die Zahlen aus Ordered Details, aus einer Measure group kommen und die Zahlen aus Orders aus einer anderen Measure group. Das wird nach wie vor sichtbar bleiben, auch bis letztendlich zum Endanwender, dass da mal ursprünglich zwei verschiedene Tabellen die Grundlage gewesen sind. Und noch etwas ist hundertprozent typisch, wenn man bei Analysis Services einen OLAP Cube mit den darunterliegenden Datenbanktabellen verbindet, nämlich das Konzept der Attribute. Die Attribute kommen typischerweise aus den Dimensionstabellen, und man kann sie im Prinzip aus jeder Spalte einer Dimensionstabelle mit einem einzigen Mausklick machen. Beispiel hier, das Geschlecht, ich habe irgendwo eine Kundentabelle in der ist eine Spalte drin, da steht männlich oder weiblich drin, und wenn ich das mit einem einzigen Klick mache, beim Entwerfen, dann ist das eben sofort ein Attribut und das kann ich verwenden in meinen Analysen, und zwar, ohne noch viel mehr zu machen, einfach wie eine Dimension, ohne weitere Ebenen. Das Beispiel sei hier im Bild gezeigt, also die Hierarchie Gender ist gar nicht wirklich eine Hierarchie, da geht es um das Geschlecht und die besteht eigentlich immer nur aus männlich, weiblich und dem automatischen Knoten darüber, Alle Kunden, zum Beispiel. Und diese Attribute mache ich mir natürlich nicht nur eins, zwei, drei, sondern möglichst viele, so viele Spalten wie ich habe in der Dimensionstabelle, und wenn ich dann eine richtige Hierarchie haben will, zum Beispiel für einen Drill-Down, dann baue ich mir diese Hierarchie aus den vorhandenen Attributen ganz einfach dynamisch zusammen, zum Beispiel fange ich an bei allen Kunden aus einem Land, dann die Kunden aus einer bestimmten Region und dann die Kunden einer Stadt. Also, Attribute sind ein ganz wichtiges konstituierendes Element von multidimensionalen Analysis Services Cubes. Das war ein kleiner Einblick in das Grundverhältnis zwischen den Datenstrukturen, der Quelldatenbank und den Objekten in Analysis Services Multidimensional.

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!