Verwaltung von mehrdimensionalen Modellassemblys

Gilt für: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

Microsoft SQL Server SQL Server Analysis Services bietet viele systeminterne Funktionen für die Verwendung mit den Sprachen MDX (Multidimensional Expressions) und Data Mining Extensions (DMX), die von statistischen Standardberechnungen bis hin zum Durchlaufen von Membern in einer Hierarchie alles erreichen. Wie bei jedem komplexen und robusten Produkt gibt es jedoch immer die Bestrebung, die Funktionalität des Produkts zu erweitern.

Daher können Sie mit SQL Server Analysis Services Assemblys zu einer SQL Server Analysis Services instance oder Datenbank hinzufügen. Mithilfe von Assemblys können Sie mit einer beliebigen CLR-Sprache (Common Language Runtime), z. B. Microsoft Visual Basic .NET oder Microsoft Visual C#, externe benutzerdefinierte Funktionen erstellen. Darüber hinaus können Sie COM-Automatisierungssprachen (Component Object Model) wie Microsoft Visual Basic oder Microsoft Visual C++ verwenden.

Wichtig

COM-Assemblys können ein Sicherheitsrisiko darstellen. Aufgrund dieses Risikos und anderer Überlegungen wurden COM-Assemblys in SQL Server Analysis Services (SSAS) 2008 veraltet. COM-Assemblys werden in zukünftigen Versionen möglicherweise nicht mehr unterstützt.

Mit Assemblys können Sie die Geschäftsfunktionalität von MDX und DMX erweitern. Sie erstellen die gewünschten Funktionen in eine Bibliothek, z. B. eine Dll (Dynamic Link Library), und fügen die Bibliothek als Assembly zu einer instance SQL Server Analysis Services oder einer SQL Server Analysis Services-Datenbank hinzu. Die öffentlichen Methoden in der Bibliothek werden dann als benutzerdefinierte Funktionen für MDX- und DMX-Ausdrücke, Prozeduren, Berechnungen, Aktionen und Clientanwendungen verfügbar gemacht.

Dem Server kann eine Assembly mit neuen Prozeduren und Funktionen hinzugefügt werden. Sie können Assemblys verwenden, um benutzerdefinierte Funktionen zu verbessern oder hinzuzufügen, die nicht vom Server bereitgestellt werden. Mithilfe von Assemblys können Sie mehrdimensionalen Ausdrücken (MDX), Data Mining-Erweiterungen oder gespeicherten Prozeduren neue Funktionen hinzufügen. Assemblys werden von der Position geladen, auf der die benutzerdefinierte Anwendung ausgeführt wird. Eine Kopie der Binärdateien der Assembly wird zusammen mit den Datenbankdaten auf dem Server gespeichert. Wenn eine Assembly entfernt wird, wird die kopierte Assembly ebenfalls vom Server entfernt.

Assemblys können von zwei verschiedenen Typen sein: COM und CLR. CLR-Assemblys sind Assemblys, die in .NET Framework-Programmiersprachen wie C#, Visual Basic .NET und Managed C++ entwickelt wurden. COM-Assemblys sind COM-Bibliotheken, die auf dem Server registriert werden müssen.

Assemblys können Server - oder Database -Objekten hinzugefügt werden. Serverassemblys können von allen mit dem Server verbundenen Benutzern und allen Objekten auf dem Server aufgerufen werden. Datenbankassemblys können nur von Database -Objekten aufgerufen werden oder von Benutzern, die mit der Datenbank verbunden sind.

Ein einfaches Assembly -Objekt besteht aus grundlegenden Informationen (Name und ID), der Dateisammlung und Sicherheitsinformationen.

Die Dateiauflistung verweist auf die geladenen Assemblydateien und ihre zugehörigen Debuggingdateien (.pdb), wenn die Debuggingdateien mit den Assemblydateien geladen wurden. Assemblydateien werden von der Position geladen, die von der Anwendung definiert wurde. Eine Kopie wird zusammen mit den Daten auf dem Server gespeichert. Die Kopie der Assemblydatei wird verwendet, um die Assembly bei jedem Start des Diensts zu laden.

Die Sicherheitsinformationen beinhalten den Berechtigungssatz und den für die Ausführung der Assembly verwendeten Identitätswechsel.

Aufrufen benutzerdefinierter Funktionen

Das Aufrufen einer benutzerdefinierten Funktion in einer Assembly erfolgt auf dieselbe Art wie das Aufrufen einer systeminternen Funktion, abgesehen davon, dass Sie einen vollqualifizierten Namen verwenden müssen. Beispielsweise ist eine benutzerdefinierte Funktion, die einen von MDX erwarteten Typ zurückgibt, in einer MDX-Abfrage enthalten, wie das folgende Beispiel zeigt:

Select MyAssembly.MyClass.MyStoredProcedure(a, b, c) on 0 from Sales  

Benutzerdefinierte Funktionen können außerdem mithilfe des CALL-Schlüsselworts aufgerufen werden. Sie müssen das CALL-Schlüsselwort für benutzerdefinierte Funktionen verwenden, die Recordsets oder 'void' zurückgeben. Dagegen können Sie das CALL-Schlüsselwort nicht verwenden, wenn die benutzerdefinierte Funktion von einem Objekt im Kontext der MDX- oder DMX-Anweisung bzw. des -Skripts, z. B. dem aktuellen Cube oder dem Data Mining-Modell, abhängt. Eine außerhalb einer MDX- oder DMX-Abfrage aufgerufene Funktion wird häufig verwendet, um das AMO-Objektmodell für die Ausführung administrativer Funktionen einzusetzen. Beispielsweise wird die MyVoidProcedure(a, b, c) -Funktion in einer MDX-Anweisung mit der folgenden Syntax verwendet:

Call MyAssembly.MyClass.MyVoidProcedure(a, b, c)  

Assemblys vereinfachen die Datenbankentwicklung, da gemeinsamer Code nur einmal entwickelt zu werden braucht und an einem einzigen Ort gespeichert werden kann. Clientsoftwareentwickler können Bibliotheken mit Funktionen für SQL Server Analysis Services erstellen und mit ihren Anwendungen verteilen.

Assemblys und benutzerdefinierte Funktionen können die Funktionsnamen der SQL Server Analysis Services Funktionsbibliothek oder anderer Assemblys duplizieren. Solange Sie die benutzerdefinierte Funktion mit ihrem vollqualifizierten Namen aufrufen, wird SQL Server Analysis Services die richtige Prozedur verwenden. Aus Sicherheitsgründen und um die Möglichkeit zu vermeiden, einen doppelten Namen in einer anderen Klassenbibliothek aufzurufen, erfordert SQL Server Analysis Services, dass Sie nur vollqualifizierte Namen für gespeicherte Prozeduren verwenden.

Um eine benutzerdefinierte Funktion von einer bestimmten CLR-Assembly aus aufzurufen, wird der benutzerdefinierten Funktion der Assemblyname, der vollständige Klassenname und der Prozedurname vorangestellt, wie im Folgenden dargestellt:

AssemblyName. FullClassName. ProcedureName(Argument1, Argument2, ...)

Aus Gründen der Abwärtskompatibilität mit früheren Versionen von SQL Server Analysis Services ist auch die folgende Syntax akzeptabel:

Assemblyname!VollständigerKlassenname!Prozedurname(Argument1, Argument2, ...)

Unterstützt eine COM-Bibliothek mehrere Schnittstellen, kann der Prozedurname auch mithilfe der Schnittstellen-ID aufgelöst werden, wie im Folgenden dargestellt:

Assemblyname!Schnittstellen-ID!Prozedurname(Argument1, Argument2, ...)

Sicherheit

Die Sicherheit für Assemblys basiert auf dem .NET Framework-Sicherheitsmodell, bei dem es sich um ein Codezugriffs-Sicherheitsmodell handelt. .NET Framework unterstützt einen Codezugriffs-Sicherheitsmechanismus, der annimmt, dass die Laufzeit sowohl vollständig vertrauenswürdigen als auch teilweise vertrauenswürdigen Code hosten kann. Die durch die .NET Framework-Codezugriffssicherheit geschützten Ressourcen sind üblicherweise von verwaltetem Code umgeben, der die entsprechenden Berechtigungen anfordert, bevor er den Zugriff auf die Ressource ermöglicht. Die Anforderung der Berechtigung ist nur dann erfüllt, wenn alle aufrufenden Prozesse (auf Assemblyebene) in der Aufrufliste über die entsprechende Ressourcenberechtigung verfügen.

Für Assemblys wird die Ausführungsberechtigung mit der PermissionSet -Eigenschaft des Assembly -Objekts erteilt. Die Berechtigungen, die der verwaltete Code erhält, hängen von der gültigen Sicherheitsrichtlinie ab. In einer nicht SQL Server Analysis Services gehosteten Umgebung gelten bereits drei Richtlinienebenen: Unternehmen, Computer und Benutzer. Die gültige Berechtigungsliste, die der Code erhält, hängt von der Schnittmenge der Berechtigungen auf diesen drei Ebenen ab.

SQL Server Analysis Services stellt eine Sicherheitsrichtlinienebene auf Hostebene für die CLR bereit, während sie gehostet wird. Diese Richtlinie ist eine zusätzliche Richtlinienebene unterhalb der drei Richtlinienebenen, die immer in Kraft sind. Diese Richtlinie wird für jede Anwendungsdomäne festgelegt, die von SQL Server Analysis Services erstellt wird.

Die SQL Server Analysis Services Richtlinie auf Hostebene ist eine Kombination aus SQL Server Analysis Services festen Richtlinie für Systemassemblys und einer vom Benutzer angegebenen Richtlinie für Benutzerassemblys. Der vom Benutzer angegebene Teil der SQL Server Analysis Services Hostrichtlinie basiert darauf, dass der Assemblybesitzer einen von drei Berechtigungsbuckets für jede Assembly angibt:

Berechtigungseinstellung	Beschreibung
Safe	Stellt eine interne Berechnungsberechtigung bereit. Dieser Berechtigungsbucket weist keine Berechtigungen für den Zugriff auf die geschützten Ressourcen in .NET Framework zu. Es handelt es hierbei um den Standard-Berechtigungsbucket für eine Assembly, sofern nicht mithilfe der PermissionSet -Eigenschaft ein anderer Bucket angegeben wurde.
ExternalAccess	Bietet den gleichen Zugriff wie die Safe -Einstellung, zusätzlich jedoch die Möglichkeit, auf externe Systemressourcen zuzugreifen. Dieser Berechtigungsbucket leistet keine Gewähr für Sicherheit (obwohl dieses Szenario gesichert werden kann), wohl aber für Zuverlässigkeit.
Unsichere	Es gelten keine Einschränkungen. Für verwalteten Code, der unter diesem Berechtigungssatz ausgeführt wird, kann keine Gewähr für Sicherheit oder Zuverlässigkeit geleistet werden. Für Code, der auf dieser Vertrauensebene ausgeführt wird, wird jede Berechtigung gewährt, selbst eine vom Administrator hinzugefügte benutzerdefinierte Berechtigung.

Wenn CLR von SQL Server Analysis Services gehostet wird, endet die stapellaufbasierte Berechtigungsprüfung an der Grenze mit nativem SQL Server Analysis Services Code. Jeder verwaltete Code in SQL Server Analysis Services Assemblys fällt immer in eine der drei zuvor aufgeführten Berechtigungskategorien.

COM- (oder nicht verwaltete) Assemblyroutinen unterstützen das CLR-Sicherheitsmodell nicht.

Identitätswechsel

Wenn verwalteter Code auf Ressourcen außerhalb SQL Server Analysis Services zugreift, befolgt SQL Server Analysis Services die Regeln, die der Einstellung der ImpersonationMode-Eigenschaft der Assembly zugeordnet sind, um sicherzustellen, dass der Zugriff in einem geeigneten Windows-Sicherheitskontext erfolgt. Da Assemblys, die die Berechtigungseinstellung Safe verwenden, nicht auf Ressourcen außerhalb SQL Server Analysis Services zugreifen können, gelten diese Regeln nur für Assemblys, die die Berechtigungseinstellungen ExternalAccess und Unsafe verwenden.

• Wenn der aktuelle Ausführungskontext der Windows-Authentifizierungsanmeldung entspricht und dem Kontext des ursprünglichen Aufrufers entspricht (d. h., es gibt keine EXECUTE AS in der Mitte), wird SQL Server Analysis Services die Identität der Windows-authentifizierten Anmeldung annehmen, bevor auf die Ressource zugegriffen wird.

• Wird der Kontext des ursprünglichen aufrufenden Prozesses durch EXECUTE AS geändert, erzeugt der Zugriff auf die externe Ressource einen Fehler.

Für die ImpersonationMode -Eigenschaft kann ImpersonateCurrentUser oder ImpersonateAnonymousfestgelegt werden. Mit der Standardeinstellung, ImpersonateCurrentUser, wird eine Assembly unter dem Netzwerk-Anmeldekonto des aktuellen Benutzers ausgeführt. Wird die ImpersonateAnonymous -Einstellung verwendet, entspricht der Ausführungskontext dem Benutzerkonto IUSER_Servername für die Windows-Anmeldung auf dem Server. Hierbei handelt es sich um ein Internet-Gastkonto, das nur über eingeschränkte Rechte auf dem Server verfügt. Eine Assembly, die in diesem Kontext ausgeführt wird, kann nur beschränkt auf Ressourcen auf dem lokalen Server zugreifen.

Anwendungsdomänen

SQL Server Analysis Services macht Anwendungsdomänen nicht direkt verfügbar. Aufgrund eines Assemblysatzes, der in der gleichen Anwendungsdomäne ausgeführt wird, können Anwendungsdomänen während der Ausführung einander erkennen, indem sie den System.Reflection -Namespace in .NET Framework oder ein anderes Verfahren anwenden, und sie können einander auf spät gebundene Weise aufrufen. Solche Aufrufe unterliegen den Berechtigungsprüfungen, die von SQL Server Analysis Services autorisierungsbasierten Sicherheit verwendet werden.

Sie sollten sich nicht darauf verlassen, Assemblys in der gleichen Anwendungsdomäne zu finden, da die Grenze der Anwendungsdomäne und die Assemblys, die sich in jeder Domäne befinden, durch die Implementierung definiert werden.

Weitere Informationen

Festlegen der Sicherheit für gespeicherte Prozeduren
Definieren gespeicherter Prozeduren