Anonymisierung von Kundendimensionen

Wie gelingt es, dass verschiedene Nutzer auf ein und denselben Cube zugreifen und in der Dimension „Kunde“ jeweils nur ihren eigenen Namen dargestellt bekommen, alle anderen Elemente aber als „anonym“ an-gezeigt werden? Was ein Anwender vielleicht ganz selbstverständlich hinnimmt, kann dem Implementierungsteam ordentlich Gehirnschmalz abverlangen. Schließlich sollen Datenvolumen und Abfragezeiten nicht unnötig aufgebläht werden. Die folgende technische Dokumentation erklärt step by step, wie diese nach-vollziehbare und zugleich knifflige Kundenanforderung von einem pmOne-Team elegant umgesetzt worden ist.

Wo stehe ich im Vergleich zu anderen? Insbesondere im beruflichen Umfeld ist die Frage, wie ich mich als Unternehmen im Vergleich zum Wettbewerb schlage, immer wieder spannend. Um ihren Kunden ein solches Benchmarking zu ermöglichen, ist es einigen Firmen ein Anliegen, die von ihnen gesammelten Daten bestimmten Zielgruppen zur Verfügung zu stellen – selbstverständlich in anonymisierter Form.

So auch im Falle eines pmOne-Projekts, wo ein Unternehmen sehr wohl die Daten, keinesfalls aber die dahinter stehenden Kundennamen preisgegeben wollte. An die pmOne-Berater wurde deshalb die Anforderung herangetragen, einen Datenwürfel mit Kundeninformationen so aufzubauen, dass die verschiedenen Nutzer in der Dimension „Kunde“ jeweils nur ihren eigenen Namen dargestellt bekommen, alle anderen Elemente aber als „anonym“ angezeigt werden.

So haben Anwender mit Zugriff auf den Cube die Möglichkeit, sich mit ihrer Peergroup zu vergleichen, ohne jedoch zu wissen, um wen es sich dabei handelt.

 

Das Beispiel zeigt, dass Kunde 0001 seine Daten unter seinem Namen sieht, alle anderen Daten werden hingegen anonymisiert dargestellt. Meldet sich Kunde 0002 am System an, kann er wiederum seine Daten sehen, die der Anderen sind anonymisiert.

 

1 UDM Modell

Um den beschriebenen Lösungsansatz umzusetzen, wurde ein einfaches Demo-Modell erstellt. In diesem vereinfachten Beispiel setzen sich die Bewegungsdaten aus zwei Kennzahlen und zwei Dimensionsausprägungen zusammen: Zeit und Kunde.

 

2 Allgemeiner Lösungsansatz

Der in dem Projekt gewählte Lösungsansatz sieht die Erstellung einer anonymisierten Kundendimension (1) vor. Darin sind alle Kunden sowohl ausgeschrieben als auch anonymisiert zu sehen. Diese Dimension ist indirekt mit den Bewegungsdaten verbunden, was über die nicht sichtbare Kundendimension (2) mit Hilfe einer sogenannten Many-to-Many Relation (3) gelingt. Die Kundendimension (2) enthält jeden Kunden nur einmal und dient als Verbindungsglied zur Kundendimension (1).

Über diese Art der Verknüpfung (3) wird jeder eindeutige Kunde in der Tabelle „DimKunde“ (2) mit seinen zwei entsprechenden Kundenelementen aus der „Dim_KundeAN“ (1) verknüpft. Dadurch sind die Werte aus den Bewegungsdaten sowohl auf dem Klartext-Kundenelement zu sehen als auch auf dem anonymisierten Kundenelement.

Nun muss noch sichergestellt werden, dass jeder Kunde jeweils nur sich in Klartext, alle anderen Kunden anonymisiert angezeigt bekommt. Das wird mit einer Dimensionsberechtigung gewährleistet, wodurch für jeden Kunden die entsprechenden Kundenelemente in der anonymisierten Kundendimension sichtbar bzw. nicht sichtbar gesetzt werden.

Aufgrund der großen Anzahl an benötigten Berechtigungsrollen (jeder Kunde würde seine eigene Cube-Rolle benötigen) und der großen Anzahl der darin selektierten Kundenelemente ist es sinnvoll, ein sogenanntes Dynamic Security Model zu implementieren.

Dazu werden mit Hilfe der beiden Tabellen „Dim_User“ (4) und „V_BRIDGE_USER_SECURITY“ (5) die Kunden-Benutzer-Beziehungen zugeordnet, so dass bei Anmeldung die entsprechenden Kundenelemente in der anonymisierten Kundendimension automatisch ein- bzw. ausgeblendet werden.

3 Technische Umsetzung

Technisch besteht die Lösung aus einem relationalen Teil und einem multidimensionalen Teil.

3.1 Relational

Folgende Tabellen und Sichten wurden für die Lösung erstellt:

 

3.1.1 cdw.Dim_User

Diese Tabelle enthält alle Benutzer und deren Kunden-Zuordnung (z.B. User1 darf Kunde 1 sehen). Hier können nur Windows-Benutzer stehen, keine Windows-Gruppen.

 

Sobald ein neuer Benutzer angebunden werden soll, muss diese Tabelle manuell angepasst werden.

  • SID: Technischer Schlüssel des Benutzers
  • UserID: Windows User Kennung (DomäneWindows User Name)
  • Kunden: Kunden Zuordnung des Benutzers

3.1.2 cdw.DimKunde

Diese Tabelle enthält die Liste aller Kunden.

 

  • SID: Technischer Schlüssel des Kunden
  • Kunde: Kunden Beziehung
  • Company_Prefix: Bsp. Attribut Company Prefix
  • Company: Bsp. Attribut Company Bezeichnung

3.1.3 cdw.FactKennzahlen

Enthält die Bewegungsdaten zu diesem Beispiel.

3.1.4 cdw.Zeit

Beispiel Zeit Dimension

3.1.5 Dwh.Dim_KundeAN

Dieser View erzeugt die Dimensionen-Sicht für die anonymisierte Kundendimension.

 

Bsp. Inhalt:

 


3.1.6 DWH.V_BRIDGE_KD_KDAN

Dieser View erzeugt die Bridge-Tabelle für die Many-To-Many Beziehung der beiden

 

Kundendimensionen. Hierbei wird jeder Kunde mit jeweils zwei Zeilenzuordnungen erzeugt: Kunde – Kunde und Kunde – Kunde Anonym.

 

3.1.7 dwh. BRIDGE_Security_HLP

Dieser View erstellt eine Hilfstabelle für den View dwh. V_BRIDGE_USER_SECURITY. Dabei wird für jeden Kunden eine Kundenelementliste erzeugt, in der er selbst als Klartext-Kunde und alle anderen als anonymisierte Kunden enthalten sind.

 

3.1.8 dwh. V_BRIDGE_USER_SECURITY

Dieser View wird für die Dynamic Security-Zuordnung benötigt. Darin werden für jeden User die Kundenelemente erstellt, die für ihn sichtbar angezeigt werden sollen.

 

3.1.9 dwh.Zeit, dwh.User, dwh.FactKennzahlen

Diese Views stellen eine 1:1-Sicht auf die entsprechenden cdw-Tabellen dar und dienen als Grundlage für die Dimensionen Zeit und User sowie die Bewegungsdaten.

3.2 Multidimensional

3.2.1 Cube

Der Cube beinhaltet die Measure-Gruppen Kennzahlen, V BRIDGE KD KDAN und V BRIDGE USER SECURITY. Außerdem sind die Dimensionen Zeit, Kunde AN (Klartext und anonyme Kunden, von außen sichtbar), Kunde (Klartext Kundendimension, von außen nicht sichtbar) und die User-Dimension (von außen nicht sichtbar) enthalten.

3.2.2 Measure-Gruppen

Der Demo-Cube enthält folgende Dimensionszuordnungen:

 

3.2.3 Zuordnung für die anonyme Kundendimension

Die Measure-Gruppe Kennzahlen ist direkt mit den Dimensionen Zeit und Kunde verbunden. Die Dimension Kunde AN (anonym) ist indirekt über die Bridge Measure-Gruppe V BRIDGE KD KDAN mit der Measure-Gruppe Kennzahlen verbunden.

3.2.4 Zuordnung für die Dynamic Security

Die Measure-Gruppe V BRIDGE USER SECURITY ist direkt mit den Dimensionen Kunde AN und User verbunden.

3.2.5 Kennzahlen

Die Measure-Gruppe Kennzahlen enthält die sichtbaren Kennzahlen Kennzahl1 und Kennzahl2. Sie bilden die Wert-Informationen der Bewegungsdaten (z.B. Umsatz, Menge, etc.).

 

Die Measure-Gruppe V BRIDGE KD KDAN enthält die nicht sichtbare Kennzahl V BRIDGE KD KDAN Count und hat keine weitere Bedeutung, wird aber benötigt, damit die Many-To-Many Relation hergestellt werden kann.

Die Measure-Gruppe V BRIDGE USER SECURITY enthält ebenfalls eine nicht sichtbare Count Kennzahl: User-Cuunt. Diese wird für die Ermittlung der Dynamic Security-Zuordnung verwendet.

3.2.6 Cube Rolle (Dynamic Security)

 

Das Konzept der Dynamic Security wird mit Hilfe der in den Cube integrierten Measure-Gruppe V BRIDGE KD KDAN und der Dimension User umgesetzt. Dabei wird eine einzige Rolle im Cube angelegt und wie folgt parametrisiert:

GENERAL

Hier werden alle Zugriffsberechtigungen auf die Datenbank deaktiviert.

 

 

MEMBERSHIP

Alle Benutzer, die Zugriff auf den Cube haben sollen, werden hier eingetragen. Zu empfehlen wäre eine Windows AD Rolle, die alle User enthält.

 

 

CUBE

Hier muss der Cube auf Read-Berechtigung gesetzt sein.

 

 

DIMENSION DATA

Das ist der Bereich, der für die Dynamic Security zuständig ist. Im Demo-Cube wird auf der Dimension Kunden AN das Attribut Kunden AN in der Registerkarte Advanced wie folgt gesetzt:

 

In dem Textfeld Allowed Member Set wird das MDX Statement hinterlegt.

NONEMPTY(
          [Kunde AN].[Kunde_AN].Members,
          (StrToMember("[User].[User_ID].[" + UserName () + "]"),
           [Measures].[UserCount])
         )


Diese MDX-Anfrage wird jedes Mal ausgeführt, wenn sich ein User anmeldet. Dabei wird eine Liste von Kundenelementen zurückgegeben, die dann auf sichtbar gesetzt wird. Welche Kundenelemente in der Liste enthalten sind, wird über die Kennzahl UserCount der Kennzahlen-Gruppe V BRIDGE KD KDAN ermittelt, indem der jeweilige User (UserName()) als Dimensionsfilter auf diese Measure-Gruppe gesetzt wird. Über das NONEMPTY werden dann nur diejenigen Kundenelemente zurückgeliefert, bei denen der Wert „1“ steht.

Christian Fürstenberg

VP - BI & Analytics Platform

pmOne AG

Christian Fürstenberg ist spezialisiert auf Data Warehouse-Lösungen, die auf Microsoft-Plattformen und -Technologien basieren. Als Head of Market Unit North steuert er die vertrieblichen Aktivitäten im nördlichen Geschäftsgebiet der pmOne AG und arbeitet an optimalen BI-Strategien und -Architekturen für Mittelständler und Konzerne. Sein Fachwissen gründet auf mehr als 15 Jahren Erfahrung im Consulting.

https://www.pmone.com •  Blog-Beiträge von diesem Autor