Measures oder Measure Dimension
Beim letzten Projekt hat mich ein Kollege gefragt wie wir die Deckungsbeitragsrechnung darstellen. Es handelte sich dabei um eine operative Steuerung - eine Deckungsbeitragsrechnung mit mehreren Stufen suggeriert bei machen automatisch eine Account Dimension und nur eine Kennzahle - den Wert, wobei wir die Werte relational durchaus als Spalten der Faktentabelle berechnet haben. Generell taucht diese Fragestellung immer im Zusammenhang mit Finanzapplikationen auf.
Darauf habe ich mir kurz die Vorteile / Nachteile überlegt.
- Wenn man sich die Objektstruktur von Analysis Services Ansieht kann man darauf schließen, das Analysis Services intern ähnlich speichert wie er das ideale Starschema geleifert haben will. Dies spricht eindeutig für Kennzahlen.
- Mit einer Account Dimension kann man eine Struktur - einen logischen Navigationspfad - abbilden. Kennzahlen sind aus AS Sicht immer eine flache Liste.
- Unterschiedliche Kennzahlen können unterschiedliche Datentypen habe - eine Kennzahl kann nur einen Datentyp haben. Dadurch muss man automatisch den größten gemeinsamen Datentyp - in aller Regel Double oder Money - wählen.
- Wenn man logisch überlegt - eine weitere Dimension bedeutet auch eine weitere Referenz auf eine andere Dimension.
- Analysis Services ließt bei einer Abfrage immer alle Kennzahlen der Measuregroup für die gewählten Dimensionen. Dies kann ein Vorteil oder Nachteil sein. Ebenso wird eine tabellarische Struktur für den Cache verwendet.
Um dies zu verifizieren habe ich eine kleine Beispieldatenbank gemacht.
- Drei Dimensionen mit je 100 Elementen
- Eine Faktentabelle mit allen Kombinationen ==> 1.000.000 Zeilen
- mit 10 Kennzahlen unterschiedlicher Datentypen (int, bigint, money, float).
mit diesem Star Schema habe ich dann zwei Analysis Services Datenbanken erstellt die sich lediglich um eine Kennzahlendimension oder Kennzahlen unterscheiden.
- von den relational 10 Kennzahlen habe ich nur 8 verwendet und alle mit dem gleichen Datentyp Currency, damit ich keine Unterschiede im Speicherplatz durch die Datentypen habe.
- für die Measuredimension habe ich eine Named Query mit 1 bis 8 als Key erzeugt und M1 ... MX als Namen.
- für die Faktentabelle habe ich eine Named Query mit einem union all der 8 Kennzahlen und konstanten Eintragungen für die Measuredimension gemacht.
Das Ergebnis
| Measures | Measures als Dimension | |
|---|---|---|
| Datenbankgröße als Backup | 29.782.016 bytes | 48.291.840 bytes |
| Partitionsdatendatei Größe | 29.475.790 bytes | 47.597.646 bytes |
Auch unterschieden sich die Abfragen entsprechend
| Measures | Measures als Dimension | |
|---|---|---|
| Abfrage | select {[Measures].[M1],[Measures].[M4],[Measures].[M9]} on columns, {[Dim1].[Id].AllMembers} on rows from [Cube] | select {[Dim4].[Id].&[1],[Dim4].[Id].&[4],[Dim4].[Id].&[9]} on columns, {[Dim1].[Id].AllMembers} on rows from [Cube] |
| Laufzeit kalter Cache | 159ms | 201ms |
Alleine Aufgrund der Datenbankgrößenunterschiede muss eine Abfrage mit der Kennzahlendimension länger dauern als eine Abfrage mit den Kennzahlen, da erheblich mehr Daten von der Festplatte gelesen werden müssen.
Daher kann für mich nur folgende Schlussfolgerung gelten - falls nicht unbedingt erforderlich immer Measures zu verwenden.
Nochmal der Hinweise, dass dies kein repräsentativer Vergleich war. Jeder sollte das für seine Situation angepasst Testen.
Testumgebung war
- SQL Server 2008 Developer Edition RTM
- Dell Latitude E6400
Um diesen Vergleich selbstständig nachvollziehen zu können sind hier alle Daten zum herunterladen.