MeasureGroups in Analysis-Services-Datenmodellen sind grundsätzlich autarke Konstrukte, die nur über ihre gemeinsamen Dimensionen zueinander im Kontext stehen. Diese Verknüpfungen müssen dazu nicht einmal explizit definiert werden. Das ist aus Modellierungssicht sehr praktisch, denn existierende Systeme können so ohne negative Auswirkungen nahezu beliebig erweitert werden. Auch für den Anwender ist die Logik leicht zu handhaben: Eingestellte Filter, z.B. die Auswahl eines Monats oder eines Vertriebsgebiets, wirken global und damit auf alle betroffenen MeasureGroups.
Wenn jedoch einzelne MeasureGroups inhaltlich zusammenhängen, d.h. 1:n-Beziehungen zwischen Bewegungsdaten bzw. Faktentabellen existieren, ist dieser Ansatz nicht frei von Tücken. Hierfür gibt es viele Praxisbeispiele:
- Aufträge/Rechnungen und deren Positionen
- Supporttasks und -aktivitäten (Vorgänge mit unterschiedlichen Bearbeitern)
- Kunden und Verträge bei Energieversorgern (Gas, Wasser, Strom)
- Verkäufe und Kaufgründe (Microsofts Referenzbeispiel in der Adventure-Works-Demo)
- Umfragen mit Mehrfachnennungen bei Einzelfragen („Welche Hobbys haben Sie?“)
Derartige Szenarios sind für den versierten OLAP-Modellierer bzw. DeltaMaster-Modeler-Anwender prädestinierte Anwendungsfälle für Microsofts genialen Ansatz der m:n-Beziehungen zwischen MeasureGroups, um die Merkmale (Dimensionen) der detaillierteren (n-)MeasureGroup auch für die Measures der übergeordneten (1-)MeasureGroup auswerten zu können. Analysis Services verhindert dabei automatisch Doppelzählungen, indem eine Art Distinct-Count-Logik zur Anwendung kommt. Hierüber wurde bereits in einem früheren Beitrag geschrieben: „n-m Beziehung Dimensionsverknüpfung“ (25.09.2009).
Die Realität liefert jedoch auch kompliziertere Beispiele. Kürzlich waren wir bei der spanischen Tochter unseres Automobilkunden zu Gast, und im Bereich Aftersales sollten Werkstattdaten analysiert werden. Es lagen Daten zu Rechnungen, Arbeitspositionen und Teilepositionen vor:
Abbildung 1 Die drei Rohdatentabellen
Im OLAP-Modell entstehen daraus aufgrund der unterschiedlichen Dimensionalität drei separate MeasureGroups:
Abbildung 2 MeasureGroup 1 “Rechnungen” nach Zeit, Kunde und Fahrzeugmodell (Bestelltyp)
Abbildung 3 MeasureGroup 2 “Arbeitspositionen” zusätzlich nach Arbeitsleistung
Abbildung 4 MeasureGroup 3 “Teilepositionen” zusätzlich nach verwendetem Teil
Abbildung 5 Die drei MeasureGroups und deren Measures
Auf dieser Basis sollten beispielsweise folgende Fragestellungen beantwortet werden:
- Bei welchen Fahrzeugtypen/Baureihen fallen bestimmte Teile häufig aus?
- Welche Arbeitsleistungen „korrelieren“ mit welchen Austauschteilen?
Frage 1 bedeutet, eine Dimension (Baureihe/Modell/Typ) aus dem Rechnungskopf, d.h. der 1-MeasureGroup, zu filtern und dann eine Measure (Teileabsatz) nach einer Dimension der Teilepositionen, d.h. der n-MeasureGroup, z.B. per Ranking darzustellen – kein Problem für DeltaMaster-Anwender.
Frage 2 jedoch erfordert die Filterung eines Dimensionselements (Arbeitsleistung, z.B. „Ölservice“) der zweiten n-MeasureGroup und anschließende Durchführung des Rankings aus dem vorigen Fall. Doch halt, die beiden n-MeasureGroups stehen ja – abgesehen von ihren gemeinsamen, aus der 1-MeasureGroup abgeleiteten Dimensionen (Zeit, Händler, Kunde, Fahrzeugmodell) – zueinander in keiner Beziehung!
Abbildung 6 Dimensionsverwendung mit m:n-Beziehungen
Das bisherige Verständnis der m:n-Logik in Analysis Services war, dass mit ihrer Hilfe sowohl von den Arbeitspositionen als auch von den Teilepositionen kommend Measures aus dem Rechnungskopf betrachtet werden können. Dass dasselbe Konzept sogar „über Eck“ funktioniert, war uns nicht bewusst bzw. hielten wir es nicht für möglich. Auf dem Rückflug probierten wir es dennoch aus, indem die jeweiligen Zusatzdimensionen der n-MeasureGroups unter Verwendung der Rechnungsköpfe als Brücke (man spricht tatsächlich von „BridgeMeasureGroups“) sozusagen über Kreuz verknüpft wurden: In der MeasureGroup Arbeitspositionen wird so die Dimension Teil ergänzt, in der MeasureGroup Teilepositionen die Dimension Arbeit. Das verblüffende Ergebnis: Auf diese Weise sind tatsächlich alle Measures aller drei MeasureGroups über alle Dimensionen aller drei MeasureGroups auswertbar!
Abbildung 7 Ergebnisdaten in DeltaMaster
Wir hoffen, wir konnten mit diesem Blogbeitrag bei Ihnen genauso wie bei uns neue Horizonte eröffnen.
