Bereits im ersten Blogbeitrag zur Rechteverwaltung in SSAS haben wir darauf verwiesen, dass es eine alternative Möglichkeit gibt, um Benutzerrechte einfach und übersichtlich zu pflegen. Diesen Modellierungsansatz möchten wir heute mit Hilfe einer zusätzlichen “Rechte”-Measuregroup zeigen. Natürlich ist dazu einiges in SSAS einzustellen bzw. über den DeltaMaster Modeler zu pflegen; aber am Ende wird eine einfache Eingabeanwendung in DeltaMaster genügen, um die Zugriffsrechte aller Anwender zu pflegen.
Hier eine kleine Checkliste, was zu tun ist:
- Anlegen einer neuen Dimension mit Benutzer-Logins
- Anlegen einer neuen Measuregroup “Security”
- Aufbau eines Erfassungsberichts für die Pflege der Zugriffsrechte
- Einrichten einer Rolle in der die Einstellungen aus der Measuregroup “Security” abgefragt werden
Klingt einfach – ist auch einfach.
Zuerst müssen die Benutzernamen aller Anwender in eine Dimension gepackt werden. Dazu brauchen wir zuerst eine einspaltige Tabelle in der die Namen in der Form <DOMÄNE> \<BENUTZERNAME> eingetragen werden.
| CREATE TABLE [dbo].[T_S_User]( | ||
| [Username] [varchar](50) NOT NULL | ||
| ) | ||
Im SSAS bauen wir mit den Informationen aus dieser Tabelle eine neue Dimension auf die wir USER nennen.
Jetzt gilt es die Dimensionen zu identifizieren, die für die Berechtigung der einzelnen Anwender relevant sind. Nehmen wir zum Beispiel aus dem Demomodell des ersten Teils die Dimensionen PRODUKTE und KUNDEN. Mit diesen Dimensionen und der neuen Dimension USER erzeugen wir eine neue Measuregroup SECURITY. Dieser Measuregroup fügen wir nur ein Measure vom Typ Integer hinzu, das wir AccessRight nennen. Darüber wird später gesteuert, ob ein Anwender Daten sehen bzw. erfassen darf oder nicht. Für diese Measuregroup muss außerdem eine Writeback-Partition angelegt werden, damit später die Pflege direkt im SSAS-Modell erfolgen kann. Alternativ würde auch eine relationale Tabelle ausreichen, in der die IDs der Dimensionselemente und der Wert für das Measure AccessRight angegeben werden. Aber eine relationale Tabelle hat den Nachteil, dass nach einer Anpassung der Zugriffsrechte das SSAS-Modell neu verarbeitet werden muss, bevor diese Anpassung greift.
Am besten ist es, wenn man den DeltaMaster Modeler ab Version 2.0.9 einsetzt; denn hier kann man ohne viel Arbeit direkt das Rückschreiben aktivieren. Einfach beim Anlegen der MeasureGroup in der Spalte Act. Writeback das Flag auf 1 (Auswahl Yes) setzen. Den Rest erledigt dann DeltaMaster Modeler.
Abb. 1 Aktivierung des Writeback über DeltaMaster Modeler
Sollte Ihr Datenmodell nicht mit DeltaMaster Modeler aufgebaut sein, können Sie natürlich im BI-Studio für den Cube die neue Measuregroup Security anlegen und dann im Bereich Partitionen eine Rückschreibe-Partition für die Measuregroup anlegen (Rechtsklick auf die Partition und “Rückschreibeeinstellungen…” anklicken).
Abb. 2 Anlegen der Writeback-Partition im BI-Studio
Egal, wie man die Security-Partition samt Rückschreibepartition angelegt hat – jetzt ist es möglich in DeltaMaster einen Pivot-Bericht zu bauen, mit dem die Zugriffsrechte administriert werden können. Das tolle ist, dass auf übersichtliche Weise die Benutzerrechte bis auf Zellen-Ebene festgelegt werden können.
Damit die Pflege nicht auf unterster Produkt- und Kundenebene abgehandelt werden muss (dann wäre es ja nicht mehr wirklich komfortabel), gibt es einen Trick: Geben Sie auf einem Knoten den Wert “1!” ein, wird jede Basiszelle unterhalb des Knotens mit dem Wert “1” beschrieben.
Abb. 3 Verteilung des Eingabewertes auf alle Kind-Elemente
Nun ist es an der Zeit, die Berechtigungen im Würfel zu setzen. Hierfür benötigen wir eine Rolle im SSAS-Modell, der alle Anwender (außer den Administratoren) zugeordnet werden müssen. Die Rolleneinstellungen für Mitgliedschaft, Datenquellen und Cubes sind so vorzunehmen wie bereits im ersten Teil des Blogbeitrags beschrieben. Die Einstellung der Zellberechtigungen erfolgt in der Karteikarte Zellendaten und muss inhaltlich dem folgenden Screenshot entsprechen:
Abb. 4 Einstellung der Zellberechtigungen
Dreh und Angelpunkt ist hier die SSAS-Funktion Username(), die zur Erzeugung des Dimensions-Elements für die User-Dimension genutzt wird. Nur so können die Userspezifischen Rechte aus der Measuregroup Security ermittelt werden.
Vom SSAS wird für Bereiche ohne Berechtigung der Zellwert mit “SEC” überschrieben, so dass die Anwender auch sehen, dass die Daten aufgrund von Berechtigungseinschränkungen nicht angezeigt werden.
Fazit:
Die hier beschriebene Alternative zur Rechtevergabe über Rollen hat zwar einen gewissen Charme, stößt aber auch sehr schnell an die Grenzen der Benutzerakzeptanz. Vor allem bei der Anzeige der Dimensionsauswahl werden alle Dimensionselemente angezeigt. Im schlimmsten Fall müssen sich die Anwender im wahrsten Sinne des Wortes auf die Suche nach ihren Daten machen, denn ob sie Daten sehen können, zeigt sich erst, wenn der Bericht aufgrund der neuen Auswahl aktualisiert wird. Über eine dimensionsbasierte Einschränkung bekommen die Anwender nur die Elemente in der Dimensionsauswahl zu sehen, für die ihnen auch Zugriffsrechte eingeräumt wurden. Das ist natürlich ein wichtiger Aspekt im Bezug auf die Benutzerfreundlichkeit des Systems.
Auch die Wertaggregation ist nicht unbedingt so, wie sie sein soll. Während man bei der Lösung des ersten Beitrags festlegen konnte, ob die Summen nur auf der Basis der Sichtbaren Elemente vorgenommen werden sollen (—> Enable Visual Totals) oder ob die Summe den “echten” Wert auf dieser Zelle anzeigen soll, so ist bei der hier beschriebenen Lösung immer die Gesamtsumme zu sehen. Eine Einstellung à la Enable Visual Totals gibt es nicht.
