M:N-Beziehnungen können auch mit Verknüpfungen oberhalb der Blattebene (höhere Granularität) gebildet werden. Dadurch entstehen im Detail unterschiedliche Ergebnisse. Abhängig von der Zielsetzung kann entsprechend agiert werden. Dieser Blogbeitrag liefert drei unterschiedliche Beispiele zur Einschätzung des jeweiligen Verhaltens.
In zwei vergangenen Blogbeiträgen wurde bereits untersucht, wie m:n-Beziehungen zwischen Dimensionen in SQL Data Tools modelliert werden können. Um eine Verbindung zwischen den Dimensionen herzustellen, wird eine sogenannte Hilfs-Measuregruppe oder Bridge-Tabelle verwendet.
Normalerweise werden die Dimensionstabellen auf der detailliertesten Ebene einer Hierarchie mit der Bridge-Tabelle verbunden. In einem Kundenprojekt ist (durch Zufall?) ein Fall aufgetreten, bei dem nicht die unterste Ebene, sondern eine übergeordnete Ebene für die Verbindung zur Bridge Tabelle verwendet wurde. Dies war für uns Anlass genug, einen solchen Fall näher zu untersuchen. Dazu haben wir uns drei Beispiele überlegt, anhand derer wir die Ergebnisse anschaulich darstellen wollen.
Kunden-/Organisationsstrukturdimension
In diesem Beispiel werden Kunden betrachtet, die in Verkaufsorganisationen aufgeteilt sind. Jeder Verkaufsorganisation kann eine oder mehrere Branchen zugeordnet werden. Die verkauften Produkte einer Verkaufsorganisation generieren einen Umsatz.
Zwischen den Dimensionen Kunde und Branche besteht eine m:n-Beziehung. Man erkennt zum Beispiel, dass die Verkaufsorganisation BMW_Auto in die beiden Branchen KFZ und Fahrzeug eingeordnet wurde. Der aggregierte Umsatz über ‚Alle Branchen‘ liegt für diese Verkaufsorganisation trotzdem bei 1000.
Die zugrundeliegende Dimensionsverwendung des Cubes sieht wie folgt aus:
Es wurde eine sogenannte Hilfs-Measuregruppe oder Bridge verwendet, um die beiden Dimensionen Kunde und Branche miteinander zu verknüpfen. Das Granularitätsattribut ist hierbei die Verkaufsorganisation, also die unterste Ebene der Kunden-Hierarchie.
Bis zu diesem Punkt entspricht die Vorgehensweise einfach dem Aufbau einer m:n-Logik in Analysis Services. Aber was passiert, wenn die Kundendimension nicht über die Verkaufsorganisation, sondern über die Kundenebene angebunden wird?
Analysis Services lässt die Auswahl der Kundenebene zu (sofern diese Spalte in der Bridge Tabelle vorhanden ist), gibt aber eine Warnung aus, dass möglicherweise nicht richtig aggregiert werden kann.
Verwendet man diese neuen Einstellungen für die Modellierung in DeltaMaster, kann folgender Bericht erstellt werden:
Durch diese Anbindung der Kundendimension, hat sich die Zuordnung der Verkaufsorganisationen zu den Branchen verändert.
Es wird erkannt, ob sich ein Kunde in einer bestimmten Branche befindet oder nicht. Zum Beispiel ist klar, dass keine Verkaufsorganisation des Kunden Fiat in die Branche Motorrad eingeordnet wurde. Allerdings kann nicht mehr zugeordnet werden, welche Verkaufsorganisation innerhalb eines Kunden welcher Branche zugeordnet war. Man betrachte beispielsweise die Branche Motorrad: Im ersten Fall war klar, dass nur BMW_Motorrad in dieser Branche lag. Mit der neuen Zuordnung wird nur erkannt, dass der Kunde BMW der Branche Motorrad zugeordnet ist, aber ob dies für alle Verkaufsorganisationen gilt, ist nicht mehr nachvollziehbar. Daher wird allen Verkaufsorganisationen der entsprechende Wert zugeordnet. Die Änderungen wirken sich also auch auf die Aggregation der Werte auf Kundenebene aus.
Produktdimension
Dieses Beispiel ist an die Chair AG Datenbank angelehnt. Es gibt verschiedene Produkte, die in Produktgruppen eingeteilt sind. Für jedes Produkt gibt es eine oder mehrere Rabattaktionen und umgekehrt kann auch eine Rabattaktion für verschiedene Produkte gelten. Die m:n-Beziehung besteht also zwischen der Produkt- und der Aktionsdimension.
Wieder gibt es zwei Möglichkeiten diese m:n-Beziehung anzubinden: auf Produktebene oder auf Produktgruppenebene.
Analog zum Kundenbeispiel ergeben sich in DeltaMaster zwei verschiedene Berichte.
Betrachtet man beispielsweise die Produktgruppe Precisio erkennt man, dass im zweiten Fall – also bei Verwendung der Produktgruppe als Granularitätsattribut – nicht zugeordnet werden kann, welches Produkt der Produktgruppe mit welcher Aktion angeboten wird. Man sieht auch, dass die neue Aggregation für die nächste Hierarchieebene übernommen und damit weitergerechnet wird.
Zeitdimension
Das gleiche Vorgehen kann auch angewendet werden, wenn eine m:n-Beziehung zur Zeitdimension vorliegt. Hier wird das Beispiel von Mode-Kollektionen genutzt. Eine Kollektion wird mehrere Monate im Jahr verkauft. Kollektionen können sich auch überlappen, das heißt in einem Monat können mehrere Kollektionen angeboten werden.
Zunächst werden die Kollektionen auf Monatsebene angebunden.
Man sieht zum Beispiel, dass im Monat September 2016 insgesamt ein Umsatz von 1000 generiert wurde, wobei in diesem Monat sowohl die Frühling/Sommer- als auch die Herbst/Winter-Kollektion, nicht aber die Xmas-Kollektion angeboten wird.
Die Kollektionen auf Quartalsebene anzubinden, macht zwar logisch wenig Sinn, allerdings werde ich diesen Fall trotzdem darstellen, um die oben gezeigten Ergebnisse nochmal mit einer anderen Dimension zu verdeutlichen.
Wie erwartet, kann auch hier nicht mehr zugeordnet werden, in welchen Monaten genau eine Kollektion angeboten wird, sobald sie in mindestens einem Monat eines bestimmten Quartals zur Verfügung steht. Obwohl die Frühling/Sommer-Kollektion im vierten Quartal nur im Oktober verfügbar ist, kann dies durch die Anbindung auf Quartalsebene nicht mehr nachvollzogen werden.
Fazit
Durch Zufall sind wir darauf gestoßen, dass es überhaupt möglich ist m:n-Beziehungen nicht auf der untersten Ebene aufzubauen. In welchen Fällen dies sinnvoll ist, ist eine andere Frage. Es sollte zumindest klar geworden sein, dass das Granularitätsattribut für die Anbindung einer Bridge Tabelle bei m:n-Beziehungen entscheidend ist, je nachdem welche Ergebnisse man sehen möchte.
