Dieser Beitrag zeigt, wie in BI-Anwendungen Berechtigungen für Anwender in unterschiedlicher Tiefe einfach abgebildet werden können, z. B. innerhalb von Vertriebsstrukturen. So kann etwa der eigene Verantwortungsbereich im Detail, andere Organisationseinheiten jedoch nur aggregiert angezeigt werden. Damit wird ein internes Benchmarking möglich, ohne Datenschutzanforderungen zu verletzen.
„Wie können Sie sicherstellen, dass unsere Mitarbeiter im Vertrieb nur die Daten ihrer eigenen Region im Detail sehen und die der anderen nur in Summe?“, so lautete jüngst die Fragestellung eines unserer Kunden. Ein Schulungsteilnehmer im Bissantz Campus formulierte es so: „Die sollen ruhig ein bisschen schwitzen, wenn sie die Zahlen ihrer Kollegen sehen!“
Aus Datenschutzgründen darf das natürlich nur aggregierte Werte betreffen und keine Details. Mit anderen Worten: Etwas internes Benchmarking ist durchaus erwünscht, doch selbstverständlich nicht mehr als erlaubt.
Widerspruch durch die Datenspeicherung
Diese Forderung steht für Data Engineers zunächst vermeintlich im Widerspruch zur bewährten Praxis der Datenspeicherung und Aggregation in dimensionalen Datenmodellen (OLAP): In der Datenbank werden die Daten stets auf der Detailebene gespeichert (z. B. beim Kunden). Die (Zwischen-)Summen auf Vertriebsgebieten und Regionen werden entlang der Dimensionshierarchien automatisch berechnet.
Beim internen Benchmarking sollen nun Anwender einzelne Zweige in der Vertriebshierarchie nicht komplett sehen dürfen, die Aggregationen hingegen schon. Den Lösungsweg dazu skizzieren wir im Folgenden am Beispiel unserer Demo-Anwendung der Chair AG.
Lösung zur Sichtbarkeit aggregierter Werte im internen Benchmarking
In unserer Beispielanwendung existieren in der Dimension Kunde die vier deutschlandweiten Vertriebsregionen Süd, Nord, Ost und West mit jeweils untergeordneten Gebieten und Postleitbereichen bis hin zu den einzelnen Kunden.
Zu Prüfzwecken berechtigen wir einen Test-User auf eine Region (Süd=1). Dies bedeutet minimalen Pflegeaufwand für den Kunden in der Praxis.
Abbildung 1: Berechtigung für Test-User
Die tatsächlichen Berechtigungen werden jedoch auf der nächsthöheren Detailebene definiert (in unserer Chair-Demo: Gebiet). Die zugehörige SQL-View für die Rechte-MeasureGroup lässt sich Abbildung 2 entnehmen.
Abbildung 2: SQL-View für die Rechte-MeasureGroup
Diese Measure wird dann in einer dynamischen Rolle in Analysis Services genutzt, wobei unter „Dimensionsdaten“ für das detaillierte Attribut (Gebiet) alle Elemente verweigert werden, für die der aktuelle Anwender nicht explizit berechtigt ist. Zudem darf die Option „Sichtbare Gesamtwerte“ NICHT aktiviert sein, damit für die höheren Ebenen (Region und Gesamt) dennoch Werte angezeigt werden (vgl. Abbildung 3).
Abbildung 3: MSAS-Rolle
Das MDX-Statement für die „Verweigerte Elementgruppe“ in lautet wie folgt:
EXCEPT( [Kunde].[GebietID].[GebietID],
NonEmpty(
[Kunde].[GebietID].[GebietID],
(StrToMember("[User].[UserID].&[" + UserName() + "]"),
[Measures].[Berechtigt]
)
)
)So sieht das Ergebnis in DeltaMaster aus:
Abbildung 4: Ergebnis in DeltaMaster
In der Filterleiste werden nur für die Region Süd die Pfeilsymbole rechts von der Elementbezeichnung angezeigt, nicht jedoch für die drei anderen Regionen weiter unten.
In Grafischen Tabellen ist die Anzeige der Plus-Symbole neben den betroffenen Regionen ohne Details weder im Editier- noch im Präsentationsmodus zu verhindern, ein Klick darauf bleibt jedoch ohne Wirkung, sodass die geforderte Sicherheit stets gewährleistet bleibt.
Abbildung 5: Ergebnis in DeltaMaster
