Verwaltung von mehrdimensionalen Modellassemblys

Microsoft SQL Server Analysis Services stellt viele eingebaute Funktionen für die Verwendung mit den Sprachen MDX (Multidimensional Expressions) und Datenmining-Erweiterungen (DMX) bereit, mit denen alles von Standard-statistischen Berechnungen bis hin zum Durchlaufen von Mitgliedern in einer Hierarchie ausgeführt werden kann. Aber wie bei jedem anderen komplexen und robusten Produkt besteht immer die Notwendigkeit, die Funktionalität eines solchen Produkts weiter zu erweitern.

Aus diesem Grund können Sie mit Analysis Services einer Analysis Services-Instanz oder -Datenbank Assemblys hinzufügen. Mit Assemblys können Sie externe, benutzerdefinierte Funktionen mithilfe einer beliebigen ClR-Sprache (Common Language Runtime) erstellen, z. B. Microsoft Visual Basic .NET oder Microsoft Visual C#. Sie können auch Automatisierungssprachen wie Microsoft Visual Basic oder Microsoft Visual C++ verwenden.

Mit Assemblys können Sie die Geschäfts-Funktionalität von MDX und DMX erweitern. Sie erstellen die gewünschte Funktionalität in einer Bibliothek, z. B. eine DLL (Dynamic Link Library) und fügen die Bibliothek einer Instanz von Analysis Services oder einer Analysis Services-Datenbank als Assembly 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.

Eine Assembly mit neuen Prozeduren und Funktionen kann dem Server hinzugefügt werden. Sie können Assemblys verwenden, um benutzerdefinierte Funktionen zu verbessern oder hinzuzufügen, die nicht vom Server bereitgestellt werden. Mithilfe von Assemblies können Sie neue Funktionen zu mehrdimensionalen Ausdrücken (MDX), Data Mining Extensions (DMX) oder gespeicherten Prozeduren hinzufügen. Assemblys werden vom Speicherort geladen, an dem die benutzerdefinierte Anwendung ausgeführt wird, und eine Kopie der Assembly-Binärdatei wird zusammen mit den Datenbankdaten auf dem Server gespeichert. Wenn eine Assembly entfernt wird, wird die kopierte Assembly auch 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, verwaltetem C++ entwickelt wurden. COM-Assemblys sind COM-Bibliotheken, die auf dem Server registriert werden müssen

Assemblies können zu Server- oder Database-Objekten hinzugefügt werden. Serverassemblys können von jedem Benutzer aufgerufen werden, der mit dem Server oder einem objekt im Server verbunden ist. Datenbankassemblys können nur von Database Objekten oder Benutzern aufgerufen werden, die mit der Datenbank verbunden sind.

Ein einfaches Assembly Objekt besteht aus grundlegenden Informationen (Name und ID), Dateiauflistung und Sicherheitsspezifikationen.

Die Dateisammlung bezieht sich auf die geladenen Assemblydateien und die entsprechenden Debugdateien (PDB), wenn die Debugdateien mit den Assemblydateien geladen wurden. Assemblydateien werden vom Speicherort geladen, an dem die Anwendung die Dateien definiert hat, und eine Kopie wird zusammen mit den Daten auf dem Server gespeichert. Die Kopie der Assemblydatei wird verwendet, um die Assembly jedes Mal zu laden, wenn der Dienst gestartet wird.

Sicherheitsspezifikationen umfassen den Berechtigungssatz und die Impersonation, die zur Ausführung der Assembly verwendet wird.

Aufrufen von User-Defined-Funktionen

Das Aufrufen einer benutzerdefinierten Funktion in einer Assembly erfolgt genauso wie das Aufrufen einer systeminternen Funktion, mit der Ausnahme, dass Sie einen vollqualifizierten Namen verwenden müssen. Eine benutzerdefinierte Funktion, die einen von MDX erwarteten Typ zurückgibt, ist z. B. in einer MDX-Abfrage enthalten, wie im folgenden Beispiel gezeigt:

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

Benutzerdefinierte Funktionen können auch mithilfe des CALL-Schlüsselworts aufgerufen werden. Sie müssen das CALL-Schlüsselwort für benutzerdefinierte Funktionen verwenden, die Recordsets oder void-Werte zurückgeben, und Sie können das CALL-Schlüsselwort nicht verwenden, wenn die benutzerdefinierte Funktion von einem Objekt im Kontext der MDX- oder DMX-Anweisung oder des Skripts abhängt, wie z. B. vom aktuellen Würfel oder Data-Mining-Modell. Eine häufige Verwendung für eine Funktion, die außerhalb einer MDX- oder SHAPE-Abfrage aufgerufen wird, besteht darin, das AMO-Objektmodell zum Ausführen von Verwaltungsfunktionen zu verwenden. Wenn Sie beispielsweise die Funktion MyVoidProcedure(a, b, c) in einer MDX-Anweisung verwenden möchten, wird die folgende Syntax verwendet:

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

Assemblys vereinfachen die Datenbankentwicklung, indem gemeinsame Code einmal entwickelt und an einem einzigen Speicherort gespeichert werden kann. Clientsoftwareentwickler können Bibliotheken von Funktionen für Analysis Services erstellen und mit ihren Anwendungen verteilen.

Assemblys und benutzerdefinierte Funktionen können die Funktionsnamen der Analysis Services-Funktionsbibliothek oder anderer Assemblys duplizieren. Solange Sie die benutzerdefinierte Funktion mithilfe des vollqualifizierten Namens aufrufen, verwendet Analysis Services das richtige Verfahren. Aus Sicherheitsgründen und zur Vermeidung der Möglichkeit, einen doppelten Namen in einer anderen Klassenbibliothek aufzurufen, erfordert Analysis Services, dass Sie nur vollqualifizierte Namen für gespeicherte Prozeduren verwenden.

Um eine benutzerdefinierte Funktion aus einer bestimmten CLR-Assembly aufzurufen, wird die benutzerdefinierte Funktion dem Assemblynamen, dem vollständigen Klassennamen und dem Prozedurnamen vorangestellt, wie hier gezeigt:

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

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

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

Wenn eine COM-Bibliothek mehrere Schnittstellen unterstützt, kann die Schnittstellen-ID auch zum Auflösen des Prozedurnamens verwendet werden, wie hier gezeigt:

AssemblyName! InterfaceID! ProcedureName(Argument1, Argument2, ...)

Sicherheit

Die Sicherheit für Assemblys basiert auf dem .NET Framework-Sicherheitsmodell, bei dem es sich um ein Codezugriffssicherheitsmodell handelt. .NET Framework unterstützt einen Codezugriffssicherheitsmechanismus, der davon ausgeht, dass die Laufzeit sowohl voll vertrauenswürdigen als auch teilweise vertrauenswürdigen Code hosten kann. Die Ressourcen, die durch .NET Framework-Codezugriffssicherheit geschützt sind, werden in der Regel von verwaltetem Code umschlossen, der die entsprechende Berechtigung erfordert, bevor der Zugriff auf die Ressource ermöglicht wird. 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 Assemblierungen wird die Berechtigung zur Ausführung über die PermissionSet Eigenschaft des Assembly Objekts übergeben. Die Berechtigungen, die verwalteter Code empfängt, werden von der tatsächlichen Sicherheitsrichtlinie bestimmt. Es gibt bereits drei Richtlinienebenen, die in einer nicht von Analysis Services gehosteten Umgebung wirksam sind: Unternehmen, Computer und Benutzer. Die effektive Liste der Berechtigungen, die Der Code empfängt, wird durch die Schnittmenge der berechtigungen bestimmt, die von diesen drei Ebenen abgerufen wurden.

Analysis Services stellt eine Sicherheitsrichtlinienstufe auf Hostebene für die CLR bereit, während sie gehostet wird; Diese Richtlinie ist eine zusätzliche Richtlinienebene unter den drei Richtlinienebenen, die immer wirksam sind. Diese Richtlinie wird für jede Anwendungsdomäne festgelegt, die von Analysis Services erstellt wird.

Die Analysis Services-Richtlinie auf Hostebene ist eine Kombination aus einer festen Analysis Services-Richtlinie für Systemassemblys und eine vom Benutzer angegebene Richtlinie für Benutzerassemblys. Der vom Benutzer angegebene Teil der Analysis Services-Hostrichtlinie basiert auf dem Assemblybesitzer, der einen von drei Berechtigungs-Buckets für jede Assembly angibt:

Wenn CLR von Analysis Services gehostet wird, stoppt die stapelbasierte Berechtigungsprüfung an der Grenze zum nativen Analysis Services-Code. Jeder verwaltete Code in Analysis Services-Assemblys fällt immer in eine der drei zuvor aufgeführten Berechtigungskategorien.

Nicht verwaltete COM-Assembly-Routinen unterstützen das Sicherheitsmodell der Common Language Runtime (CLR) nicht.

Nachahmung

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

• Wenn der aktuelle Ausführungskontext der Windows-Authentifizierung entspricht und mit dem Kontext des ursprünglichen Aufrufers übereinstimmt (d. h., es gibt kein EXECUTE AS dazwischen), übernimmt Analysis Services die Identität der authentifizierten Windows-Anmeldung, bevor auf die Ressource zugegriffen wird.

• Wenn ein zwischengeschalteter EXECUTE AS vorhanden ist, der den Kontext vom ursprünglichen Aufrufer geändert hat, schlägt der Versuch, auf externe Ressource zuzugreifen, fehl.

Die ImpersonationMode Eigenschaft kann auf ImpersonateCurrentUser oder ImpersonateAnonymous. Die Standardeinstellung ImpersonateCurrentUser führt eine Assembly unter dem Netzwerk-Anmeldekonto des aktuellen Benutzers aus. Wenn die ImpersonateAnonymous Einstellung verwendet wird, entspricht der Ausführungskontext dem Windows-Anmeldebenutzerkonto IUSER_Servername auf dem Server. Dies ist das Internet-Gastkonto, das eingeschränkte Berechtigungen auf dem Server hat. Eine Assembly, die in diesem Kontext ausgeführt wird, kann nur auf begrenzte Ressourcen auf dem lokalen Server zugreifen.

Anwendungsdomänen

Analysis Services macht Anwendungsdomänen nicht direkt verfügbar. Aufgrund einer Gruppe von Assemblys, die in derselben Anwendungsdomäne ausgeführt werden, können Anwendungsdomänen während der Ausführung mithilfe des System.Reflection Namespaces im .NET Framework oder auf andere Weise einander ermitteln und spät gebunden aufrufen. Solche Aufrufe unterliegen den Berechtigungsprüfungen, die von der autorisierungsbasierten Sicherheit von Analysis Services verwendet werden.

Sie sollten sich nicht darauf verlassen, Assemblys in derselben Anwendungsdomäne zu finden, da die Anwendungsdomänengrenze und die Assemblys, die in jede Domäne eingehen, durch die Implementierung definiert werden.

Siehe auch

Festlegen der Sicherheit für gespeicherte Prozeduren
Definieren gespeicherter Prozeduren