Die Konzeption und der Aufbau einer guten OLAP-Datenbank ist eine Kunst für sich. Aber wenn diese Schritte abgeschlossen sind, ist die Arbeit noch lange nicht zu Ende – jetzt müssen die Zugriffsrechte der Anwender so zugeschnitten werden, dass jeder nur die Daten sehen kann, die er sehen darf.

Im heutigen ersten Teil dieses Blogbeitrags zeigen wir die Vorgehensweise, wie in den SQL Server Analysis Services (SSAS) die Zugriffsrechte über so genannte Rollen (engl. Roles) verwaltet werden können. Der zweite Teil wird das Thema Rechteverwaltung mit OLAP-Unterstützung beleuchten. Dort werden wir einen Ansatz zeigen, wie mit Hilfe von zusätzlichen Measuregroups der administrative Aufwand für die Rechteverwaltung minimiert und vereinfacht werden kann.

Vorbereitung/Szenario

Die folgenden Beispiele beziehen sich auf die SSAS-Version unserer Chair-Demodatenbank. In diesem Datenmodell werden die Zugriffsrechte für Produktmanager, Produktgruppenmanager und Vertriebsmitarbeiter angelegt.

Zum Testen der Zugriffsrechte brauchen wir natürlich auch ein paar Testuser, die wir den SSAS-Rollen zuordnen können. Hierfür reicht es, auf dem lokalen System in der Benutzerverwaltung einige Benutzer anzulegen.

Abb. 1: Anlegen der Testuser in der lokalen Benutzerverwaltung

Anlegen und Pflegen von Rollen

Die Administration von Rollen kann sowohl über das SQL Server Management Studio als auch über das SQL Server Business Intelligence Development Studio (BI-Studio) vorgenommen werden. Während man in der Phase der Projektumsetzung eher den Weg über das BI-Studio nehmen wird, weil man ja sowieso ständig damit arbeitet, empfiehlt sich im späteren produktiven Einsatz eher der Weg über das Management-Studio.

Egal welchen Weg man wählt – in beiden Fällen gibt es unterhalb der OLAP-Datenbank einen Ordner „Rollen“. Hier können bestehende Rollen administriert und neue Rollen über das Kontextmenü des Ordners angelegt werden.

Abb. 2: Aufruf des Rollendialogs im Management Studio

Abb. 3: Aufruf des Rollendialogs im BI-Studio

Die Dialoge für das Anlegen bzw. Ändern einer Rolle haben zwar ein unterschiedliches Erscheinungsbild – je nachdem ob sie über das Management Studio oder über das BI-Studio geöffnet wurden, bieten aber inhaltlich einen identischen Aufbau. Einzige Ausnahme ist der Abschnitt „Zellendaten“ des BI-Studios Dialogs, bei dem man zusätzlich das Datenmodell mit den Einstellungen der aktuellen Rolle im Browser-Modus testen kann. Aus diesem Grund werden wir die Parameter zum Einstellen einer Rolle am Beispiel des BI-Studio Dialogs erläutern.

SSAS-Rollen für Produktmanager

Im Chair-Datenmodell gibt es insgesamt 22 Produkte, für die es dem entsprechend also auch bis zu 22 Produktmanager geben kann. Je nach dem, wie die Produkte einem Produktmanager zugeordnet werden können, müssen also bis zu 22 SSAS-Rollen alleine für die Zuordnung der Produktmanager angelegt werden. Natürlich wird es vorkommen, dass ein Produktmanager nicht nur ein Produkt betreut – somit könnte man in einer SSAS-Rolle den Zugriff auf mehrere Produkte festlegen. Damit jedoch sichergestellt werden kann, dass spätere Umbau-Aktionen möglichst selten vorgenommen werden müssen, muss immer zuerst die Frage beantwortet werden, ob diese Produkte auf immer und ewig von einem Produktmanager betreut werden oder ob es nicht auch Änderungen in den Zuständigkeiten geben kann. Ein Produktmanager bekommt ein neues Produkt hinzu und gibt dafür ein anderes Produkt an einen anderen Produktmanager ab…

Auf jeden Fall müssen Rollen im SSAS angelegt werden. Und so wird es gemacht:

• Anlegen einer neuen SSAS-Rolle über das Kontextmenü des Ordners „Rollen“ im BI-Studio oder im Management Studio (s.o.)
• Einen sprechenden Namen vergeben z.B. „Produkt_Arcade_AE_44“. Entweder direkt im Eingabefeld „Rollenname“ (Management Studio) oder durch Umbenennen der .role-Datei (BI-Studio). Im BI-Studio darf die Endung .role nicht weggelassen werden!
• Im Abschnitt „Allgemein“ sind folgende Einstellungen möglich:
  • Rollenbeschreibung: Hier ist Platz für eine kurze Beschreibung der Rolle
  • Datenbankberechtigung „Vollzugriff“: Ist diese Berechtigung ausgewählt, haben die Mitglieder dieser Rolle volle Administrationsrechte auf dieser SSAS-Datenbank
  • Datenbankberechtigung „Datenbank verarbeiten“: Legt für die Mitglieder der Rolle fest, dass diese eine Verarbeitung der Datenbank anstoßen dürfen
  • Datenbankberechtigung „Definition lesen“: Erlaubt den Mitgliedern dieser Rolle die Metadaten der OLAP-Datenbank auszulesen
    
• Im Abschnitt „Mitgliedschaft“ können Benutzer bzw. Benutzergruppen zur Rolle hinzugefügt werden
  
• Im Abschnitt „Datenquellen“ kann festgelegt werden, ob die Benutzer
  • lesenden „Zugriff“ auf die Datenquelle bekommen. Diese Einstellung wird benötigt, wenn per DMX-Abfrage (Data Mining Extensions) auf die Quelldaten zugegriffen werden soll. In Verbindung mit DeltaMaster ist diese Einstellung jedoch ohne Bedeutung da DeltaMaster keine DMX-Abfragen verwendet.
  • die Definition der Datenquelle auslesen dürfen. Diese Einstellung ist wichtig, wenn ein Benutzer in DeltaMaster ein neues Analysemodell anlegt und bei der Anbindung des relationalen Modells auswählt, dass die relationalen Strukturen direkt vom Analysis Server ausgelesen werden sollen. Das ist nur möglich, wenn diese Einstellung ausgewählt wurde.
    
• Im Abschnitt „Cubes“ wird der Zugriff auf die Cubes festgelegt. Damit die Mitglieder der Rolle Daten aus dem Cube sehen können muss unter „Zugriff“ mindestens „Lesen“ ausgewählt sein. Über die Einstellungen für „Lokaler Cube/Drillthrough“ kann festgelegt werden, ob die Mitglieder der Rolle berechtigt sind, einen Drillthrough auf die Basistabellen auszuführen und/oder einen lokalen Cube zu erzeugen. Über die Auswahl von „Verarbeiten“ wird festgelegt, dass die Rollenmitglieder eine Verarbeitung des Cubes anstoßen dürfen.
  
• Nun kommen wir zu dem Abschnitt, in dem sich ein kleiner aber feiner Unterschied zum Rollen-Dialog des Mangement-Studios bietet: „Zellendaten“. Hier können die Zugriffsrechte auf die Zellendaten eines Cubes per MDX dynamisch festgelegt werden. Die in den einzelnen Abschnitten verwendeten MDX-Statements müssen lediglich den Wert TRUE (1) oder FALSE (0) zurück geben. Im zweiten Teil dieses Beitrags wird näher auf diese Einstellungsmerkmale eingegangen. Hinweisen möchten wir jedoch auf den unscheinbaren Link im oberen rechten Bereich des Dialogs. Hierüber kann man Testweise den Datenbrowser des BI-Studios aufrufen und den Datenzugriff mit den Zugriffsrechten der aktuellen Rolle testen. Der Datenbrowser ist zwar nicht besonders komfortabel in der Bedienung, aber es ist eine gute Möglichkeit, wenn vor der Bereitstellung auf der OLAP-Datenbank schon einmal testweise überprüft werden kann, ob alle Einschränkungen korrekt umgesetzt wurden.
  
• Im Abschnitt „Dimensionen“ kann festgelegt werden, ob die Rollenmitglieder den Inhalt einer Dimension bearbeiten dürfen. Da diese Funktionalität jedoch von DeltaMaster nicht unterstützt wird, bleiben hier alle Einstellungen unberührt. Lediglich die Einstellung „Verarbeiten“ könnte von Interesse sein, wenn es sich bei der Rolle um eine Administratoren-Rolle handelt – allerdings wird diese Option automatisch gesetzt, wenn im Abschnitt „Allgemein“ die Einstellung „Vollzugriff (Administration)“ gewählt wird.
  
• Jetzt kommen wir zu dem Abschnitt „Dimensionsdaten“, in dem wir den Zugriff auf die einzelnen Dimensionselemente festlegen können.
  
• Hier ist wie folgt vorzugehen:
  • Auswahl der Dimension. Um den Zugriff für die Produktmanager auf die einzelnen Produkte festzulegen, wählen wir also die Dimension „Produkte“. Die Auswahl der Dimension kann hier sowohl auf Datenbankebene als auch auf Cube-Ebene vorgenommen werden. Das wird interessant, sobald man mehrere Cubes innerhalb einer Datenbank verwendet – wenn es, wie in unserem Fall, nur einen Cube gibt, erscheint diese Auswahlmöglichkeit redundant. Wir pflegen unsere Zugriffseinschränkungen auf Datenbankebene:
    
  • Auswahl der Attributhierarchie und der Dimensionselemente. Hierfür gibt es zwei Möglichkeiten – entweder eine listenbasierte Auswahl auf dem Unterabschnitt „Standard“ oder eine MDX-Basierte, frei definierbare Auswahl auf dem Unterabschnitt „Erweitert“. Für unsere Anforderungen genügt die listenbasierte Auswahl im Unterabschnitt „Standard“. Für die Auswahl der Attributhierarchie und der Dimensionselement werden nur die Bezeichnungen und Schlüssel aus den Basistabellen der Dimension angezeigt. Die Einzelprodukte, für die wir jetzt eine Einschränkung vornehmen wollen, stehen auf der Attributhierarchie „ProduktID“. Der Schlüssel für das Element „Arcade AE 44“ ist „P1“. Die Auswahl sieht damit so aus:
    

Tipp:

Um den Schlüssel eines Elements zu ermitteln kann man im Dimensionsbrowser von DeltaMaster bei gedrückter ALT-Taste mit der Maus auf das entsprechende Element zeigen. In einem Tooltip wird dann der Uniquename des Elements angezeigt. Der Schlüsselwert steht am Ende des Strings nach dem „&“-Zeichen.

• • Eine Einstellung die niemals vergessen werden sollte, ist die Auswahl „Sichtbarer Gesamtwert aktivieren“ im Unterabschnitt „Erweitert“. Hierüber wird festgelegt, ob auf übergeordneten Ebenen nur die Summen der Elemente angezeigt wird, die der Anwender sehen darf, oder ob die Gesamtsumme über alle darunterliegenden Elemente angezeigt wird, obwohl der Anwender nur einen Teil davon sehen darf. In unserem konkreten Fall würde das zum Beispiel so aussehen: Der Anwender RoleTest_PM würde ohne die Einstellung „Sichtbare Gesamtwerte aktivieren“ auf der Ebene der Produktgruppen auf den übergeordneten Ebenen die Summen über alle Produkte angezeigt bekommen und nicht nur die Summen über die Produkte, die er sehen darf. Das ist ziemlich verwirrend – finden Sie nicht? Was würden Sie aus einer solchen Tabelle für Rückschlüsse ziehen:
    
    Mit der aktivierten Einstellung „Sichtbarer Gesamtwert aktualisieren“ sieht das Ergebnis dann so aus:
    Die richtige Einstellung im Unterabschnitt „Erweitert“ sieht dann so aus:
  • Den Abschnitt „Miningstrukturen“ werden wir hier nicht verwenden. Wer mehr darüber erfahren möchte findet unter anderem auf den TechNet-Seiten von Microsoft weierführende Informationen.

Hinweise zum Testen der Zugriffsrechte

Um die Rolleneinstellungen, die wir gerade vorgenommen haben, zu testen, ist es natürlich erst einmal wichtig, dass die vorgenommenen Einstellungen auch auf dem Server angekommen sind. Bei der Rollenpflege über das Management Studio wirkt sich eine Änderung direkt auf die Datenbank aus – es gibt also kein Netz und keinen doppelten Boden. Im BI-Studio kommt es darauf an, ob Sie sich direkt mit der OLAP-Datenbank verbunden haben (über Datei – Öffnen – Analysis Services Datenbank…) oder ob Sie ein Projekt für die Datenbank angelegt haben. Im Fall, dass Sie sich direkt verbunden haben, stehen die vorgenommenen Änderungen auch sofort in der Datenbank. Wenn Sie jedoch ein Projekt angelegt haben, müssen Sie dieses erst bereitstellen, bevor die Änderungen an der Rollendefinition auf der Datenbank verfügbar sind. Eine vollständige Verarbeitung ist jedoch nicht nötig, wenn nur Änderungen an den Rollen vorgenommen wurden.

Um die Zugriffsrechte testen zu können, ist es notwendig, dass sich der DeltaMaster, die OLAP-Datenbank und die lokal angelegten Testuser auf dem gleichen Rechner befinden. Um sich mit einem lokal angelegten Testuser an der Datenbank anzumelden, muss nach dem Öffnen der DeltaMaster-Analysesitzung der Anmeldedialog wie folgt ausgefüllt werden.

Übung: Anlegen einer Rolle für Produktgruppe „Precisio“

Legen Sie nun selbst eine Rolle für den Zugriff auf die Produktgruppe „Precisio“ (Dimension: Produkte; Attributhierarchie: ProduktgruppeID; Schlüssel: 6) an. Einziges Mitglied dieser Rolle soll der Testuser „RoleTest_PG“ sein.

Das Ergebnis in DeltaMaster müsste dann so aussehen:

Vorschau

Im nächsten Blogbeitrag zum Thema Rechteverwaltung in SSAS werden wir zeigen, welche alternativen Möglichkeiten es gibt, um die Zugriffsrechte für Benutzer mit einem geringeren administrativen Aufwand festzulegen.