Nicht-eindeutige Hierarchien sind der Albtraum eines jeden BI-Entwicklers. Liegt diese Anforderung aber auf dem Tisch, gilt es, kreativ zu sein. Dieser Blogbeitrag zeigt, wie mit Hilfe von Many-to-Many-Bridges mehrdeutige Hierarchien unter Zuhilfenahme einer weiteren Dimension abgebildet werden können und zeigt auf, welche Punkte es dabei zu beachten gibt. Die Beziehungen können anschließend in DeltaMaster ausgewertet werden.

Überblick

Die Eindeutigkeit von Elementen innerhalb einer Hierarchie ist ein striktes Dogma und eine Notwendigkeit der multidimensionalen Datenmodellierung. Nur wenn Elemente eindeutig einem Pfad in einer Hierarchie zugeordnet werden können, ist eine Aggregation von Kennzahlen sinnvoll und möglich. Die Praxis macht dem BI-Entwickler bei diesem Thema jedoch häufig einen Strich durch die Rechnung. Kunden, die mehreren Postleitzahlgebieten zugeordnet sind oder Produkte, die in zwei Produktgruppen auftauchen, sind die täglichen Herausforderungen bei der multidimensionalen Modellierung.

Häufig wird dem Problem mit der Erstellung eines zusätzlichen, künstlichen Primärschlüssels begegnet. Dies hat jedoch den entscheidenden Nachteil, dass Elemente durch diese Modellierung doppelt in der Hierarchie vorkommen und die Ermittlung eines Gesamtwertes für dieses Element nicht ohne Weiteres möglich ist. Dieser Blogbeitrag gibt einen Überblick über einen alternativen Lösungsansatz.

Die Ausgangslage

Entstanden ist die hier beschriebene Lösung durch die folgende Fragestellung: Wie können für einzelne Anwenderkreise Produkte in bestimmten Gruppen zusammengefasst werden, wenn jedes Produkt theoretisch in mehr als einer Gruppe vorkommen kann?

Wäre der letzte Halbsatz nicht, wäre die Antwort ganz klar: In einer parallelen Hierarchie der Produktdimension. Doch auch diese hat sich an die allgemeinen Regeln zu halten: Jedes Element muss in der Hierarchie eindeutig sein.

Also wieder zurück zur Anforderung: In DeltaMaster sollen durch diese Gruppierung die folgenden Funktionen möglich sein:

• Filterung der Produkte nach entsprechender Gruppierung
• Gruppierte Anzeige der Produkte

Die Lösung

Zugegebenermaßen, es hat kurze Zeit gedauert. Aber die Lösung für diese mehrdeutige Zuordnung liegt eigentlich schon unverschämt offensichtlich auf der Hand und wurde bereits 2014 in dem Blogbeitrag eines geschätzten Kollegen beschrieben: Many-to-Many (m:n)-Bridges.

Datenmodell

Schon seit SQL Server 2005 bietet Microsoft SQL Server Analysis Services mit dieser Modellierungsfunktion die Möglichkeit, Mehrdeutigkeiten zwischen Dimensionen mit Hilfe einer Measuregroup abzubilden. Die theoretischen Grundlagen werden in diesem Blogbeitrag nicht weiter erläutert, da es bereits wunderbare Artikel von Kollegen dazu gibt.

Die Idee: Die mehrdeutige Zuordnung wird nicht innerhalb einer einzigen Dimension abgebildet, sondern unter Zuhilfenahme einer zweiten Dimension, der Produktgruppe. Verbunden werden diese beiden Dimensionen dann mit Hilfe einer so genannten Bridge-Measuregroup, sodass nur die eigentliche Produktdimension mit den bestehenden Bewegungsdaten verbunden bleibt. Der Ausschnitt des Datenmodells sieht dann wie folgt aus:

Benötigt werden in der relationalen Datenbank demnach die folgenden Objekte:

• Eine View für die Produktdimension (In der Regel bereits vorhanden)
• Eine View für die Produkthauptgruppendimension
• Eine View für die Many-to-Many-Bridge

Der Aufbau der Views richtet sich nach dem jeweiligen Datenmodell. Zu beachten ist lediglich, dass die View für die Many-to-Many-Bridge so aufgebaut ist, dass pro Zeile ein Schlüssel der Produktdimension mit einem Schlüssel der Gruppierungsdimension kombiniert wird. Die Kombination darf mehrdeutig sein.

Einrichtung in DeltaMaster ETL

Die Einrichtung der Many-to-Many-Beziehung erfolgt in DeltaMaster ETL in zwei Schritten.

Zuerst muss auf Basis der in Kapitel 3.1 erstellten View eine neue Measuregroup angelegt und an die entsprechenden Dimensionen angebunden werden. Für weitere Funktionalitäten wird keine Kennzahl benötigt, deshalb wird nur eine Zählerkennzahl angelegt:

Abbildung 1: Zuordnung der Measuregroup

Abbildung 2: Notwendige Measures

Anschließend kann diese dann unter „Advanced Modeling“ im Bericht „Many-to-Many Bridges“ verwendet werden, um die bestehenden Measuregroups mit der neuen Gruppierungsdimension zu verbinden:

Abbildung 3: Bericht für Many-to-Many-Bridges in DeltaMaster ETL

Abbildung 4: Einrichten der Bridge

Die Datenquelle

Im zugrunde liegenden Fall war die abzubildende Gruppierung nicht als Datenquelle verfügbar und musste zunächst angelegt werden. Als unkompliziert einzurichtende Variante bietet sich hier die tabellarische Pflege per eingabefähigem DeltaMaster SQL-Durchgriff an. Eine Anleitung zur Einrichtung findet sich in einem weiteren Blogartikel.

Ergebnisse in DeltaMaster

Eines vorweg: Eine echte Hierarchie haben wir hier natürlich nicht abgebildet, es handelt sich nach wie vor um zwei eigenständige Dimensionen. Mit DeltaMaster können wir jedoch nun zwei wesentliche Abfragen ausführen, aus denen heraus diese Modellierung entstanden ist.

Filtern nach Gruppierung

Möchte man nun in DeltaMaster nur die Produkte sehen, die in einer entsprechenden Gruppierung zusammengefasst wurden, geht dies einfach über den entsprechenden Filter:

Abbildung 5: Filterung nach Gruppierung

Das Charmante: Die Produkte behalten ihre ursprüngliche Hierarchie und können weiterhin über diese ausgewertet werden:

Abbildung 6: Filterung innerhalb von Hierarchien

Gliederung nach Gruppierung

Alternativ kann die neue Dimension mit der bestehenden verschachtelt werden, um eine Gruppierung sichtbar zu machen:

Abbildung 7: Anzeige von Gruppierungen

Auch hier besteht die Möglichkeit, die Produkte weiterhin über ihre ursprüngliche Hierarchie auszuwerten. Das Praktische: Umsätze von Produkten, die in mehreren Gruppen vorkommen, werden zwar auf die Summe der jeweiligen Gruppen aggregiert. Betrachtet man aber die Summe aller Gruppierungen, zum Beispiel wenn der Filter nicht aktiv ist, wird der Umsatz jedes Produktes (korrekterweise) nur jeweils einmal in die Gesamtsumme mit einbezogen:

Abbildung 8: Anzeige von Zwischensummen

Doch Moment: Wer genau nachrechnet wird feststellen, dass auch nach Elimination der doppelten Produkte die Gesamtsumme in den gezeigten Bildern dennoch nicht korrekt ist. Das liegt daran, dass es Produkte gibt, die keiner Gruppierung zugeordnet sind. Da über die Many-to-Many-Bridge aber nur explizite Zuordnungen angegeben werden, werden nicht zugeordnete Produkte nicht, wie aus Dimensionen-Measuregroup-Zuordnungen üblich, automatisch auf einem Default-Member angezeigt. Dies wäre eigentlich nicht weiter schlimm. Doch da der Knoten “Alle Produkte” diese nicht zugeordneten Produkte dennoch aggregiert, entsteht ein Problem. Möchte man dieses Verhalten umgehen, so muss man die Zuordnungsview noch mit ein wenig Logik versehen, anstatt nur die Zuordnungstabelle durchzureichen:

 

ALTER VIEW  
V_Import_Fact_Bridge_Produkt_Produktgruppierung AS 

SELECT 
p.ProduktID 
,pg.ProduktGruppierungID 

--Mapping für alle Produkte ermitteln 
FROM 
dbo.V_Import_Dim_Produkt p 
--Wenn vorhanden Gruppierung finden, ansonsten NULL 
LEFT JOIN 
dbo.T_S_Map_Produkt_Produktgruppierung pg 
ON p.ProduktID = pg.ProduktID 

Somit werden für alle Produkte Zuordnungen erstellt und das Ergebnis sieht in DeltaMaster wie folgt aus:

Abbildung 9: Anzeige mit Default Member

Zusammenfassung

Wie der Name schon sagt, eignen sich Many-to-Many-Bridges hervorragend für die Abbildung von Mehrdeutigkeiten innerhalb, von und zwischen Dimensionen. Das hier gezeigte Beispiel ermöglicht es, Produkte für unterschiedliche Anwendungsbereiche zu gruppieren, ohne auf die Eindeutigkeit der Zuordnung achten zu müssen oder die ursprüngliche Hierarchie zu verlieren. Die Einrichtung ist dank DeltaMaster ETL kinderleicht und erfordert nur wenige Anpassungen am Datenmodell.

Vorsicht ist lediglich bei der Aggregation geboten. Werden in einem Bericht mehrere Gruppierungen auf einmal in Verbindung mit einer Gesamtsumme angezeigt, so schadet eine kurze Erläuterung per Berichtskommentar in der Regel nicht.