多次元モデルのアセンブリの管理
適用対象:
SQL Server Analysis Services Azure Analysis Services Power BI Premium
Microsoft SQL Server Analysis Servicesには、標準の統計計算から階層内のメンバーの走査まで、すべてを実現するように設計された多次元式 (MDX) およびデータ マイニング拡張機能 (DMX) 言語で使用するための組み込み関数が多数提供されています。 ただし、他のすべての複雑で強力な製品がそうであるように、この製品も常に機能の拡張を求められています。
そのため、Analysis ServicesインスタンスまたはデータベースにアセンブリAnalysis Servicesを追加できます。 アセンブリを使用すると、Microsoft Visual Basic .NET や Microsoft Visual C# など、任意の共通言語ランタイム (CLR) 言語を使用する外部ユーザー定義関数を作成できます。 Microsoft Visual Basic や Microsoft Visual C++ など、コンポーネント オブジェクト モデル (COM) オートメーション言語を使用することもできます。
重要
COM アセンブリにより、セキュリティ上のリスクが生じる可能性があります。 このリスクや他の考慮事項により、COM アセンブリは 2008 年 1 月 2008 SQL Server (SSAS) Analysis Services非推奨とされました。 COM アセンブリは、今後のリリースではサポートされない可能性があります。
アセンブリにより、MDX と DMX のビジネス機能が拡張されます。 ダイナミック リンク ライブラリ (DLL) などのライブラリに必要な機能をビルドし、ライブラリをアセンブリとして Analysis Services のインスタンスまたは Analysis Services データベースに追加します。 ライブラリ内のパブリック メソッドは、ユーザー定義関数として、MDX および DMX 式、プロシージャ、計算、動作、およびクライアント アプリケーションに公開されます。
新しいプロシージャや関数を使用したアセンブリをサーバーに追加できます。 アセンブリを使用して、サーバーによって提供されていない独自の機能を拡張または追加できます。 アセンブリを使用することにより、多次元式 (MDX)、データ マイニング拡張機能 (DMX)、またはストアド プロシージャに新しい関数を追加できます。 カスタム アプリケーションの実行場所からアセンブリが読み込まれ、アセンブリ バイナリ ファイルのコピーは、データベースのデータと共にサーバーに保存されます。 アセンブリを削除すると、そのアセンブリのコピーもサーバーから削除されます。
アセンブリには、COM と CLR の 2 種類があります。 CLR アセンブリとは、C#、Visual Basic .NET、マネージド C++ など、.NET Framework プログラミング言語で開発されたアセンブリです。 COM アセンブリとは、サーバーに登録する必要がある COM ライブラリです。
アセンブリは、 Server オブジェクトまたは Database オブジェクトに追加できます。 サーバー アセンブリは、サーバーまたはサーバー内の任意のオブジェクトに接続している任意のユーザーが呼び出すことができます。 データベース アセンブリは、 Database オブジェクトまたはデータベースに接続しているユーザーのみが呼び出すことができます。
単純な Assembly オブジェクトは、基本情報 (名前と ID)、ファイル コレクション、およびセキュリティの仕様で構成されます。
デバッグ ファイルがアセンブリ ファイルと共に読み込まれた場合、ファイル コレクションは、読み込まれたアセンブリ ファイルとそれらに対応するデバッグ (.pdb) ファイルを参照します。 アセンブリ ファイルは、アプリケーションがファイルを定義した場所から読み込まれ、コピーは、データと共にサーバーに保存されます。 アセンブリ ファイルのコピーは、サービスが開始されるたびにアセンブリを読み込むために使用されます。
セキュリティの仕様には、アセンブリを実行するために使用される権限セットと権限の借用が含まれます。
ユーザー定義関数の呼び出し
アセンブリでのユーザー定義関数の呼び出しは、完全修飾名を使用する必要があるという点を除いて、固有の関数の呼び出しと同じように行われます。 たとえば、次の例に示すように、MDX によって予期される型を返すユーザー定義関数は MDX クエリに含まれます。
Select MyAssembly.MyClass.MyStoredProcedure(a, b, c) on 0 from Sales
ユーザー定義関数は、CALL キーワードを使用して呼び出すこともできます。 レコードセットまたは void 値を返すユーザー定義関数には CALL キーワードを使用する必要があります。また、ユーザー定義関数が、現在のキューブやデータ マイニング モデルなどの、MDX または DMX のステートメントやスクリプトのコンテキスト内のオブジェクトに依存する場合は、CALL キーワードは使用できません。 MDX または DMX クエリの外部で呼び出される関数の一般的な使用方法は、AMO オブジェクト モデルを使用して管理機能を実行することです。 たとえば、MDX ステートメントで MyVoidProcedure(a, b, c) 関数を使用する場合、次の構文を使用します。
Call MyAssembly.MyClass.MyVoidProcedure(a, b, c)
アセンブリは、一度共通のコードを開発して単一の場所に格納することで、データベースの開発を簡略化します。 クライアント ソフトウェア開発者は、アプリケーションに対して関数のライブラリを作成Analysis Servicesアプリケーションと一緒に配布できます。
アセンブリとユーザー定義関数は、関数ライブラリまたは他のアセンブリのAnalysis Servicesの関数名を複製できます。 完全修飾名を使用してユーザー定義関数を呼び出す限り、Analysis Servicesプロシージャが使用されます。 セキュリティ上、および別のクラス ライブラリで重複する名前を呼び出す可能性を排除するために、Analysis Services ではストアド プロシージャに完全修飾名のみを使用する必要があります。
特定の CLR アセンブリからユーザー定義関数を呼び出すには、次に示すように、ユーザー定義関数の前にアセンブリ名、完全なクラス名、プロシージャ名を付けます。
AssemblyName。FullClassName。ProcedureName(Argument1, Argument2, ...)
以前のバージョンの Analysis Servicesとの下位互換性のために、次の構文も使用できます。
AssemblyName!FullClassName!ProcedureName(Argument1, Argument2, ...)
COM ライブラリが複数のインターフェイスをサポートしている場合は、次に示すように、インターフェイス ID を使用してプロシージャ名を解決することもできます。
AssemblyName!InterfaceID!ProcedureName(Argument1, Argument2, ...)
セキュリティ
アセンブリのセキュリティは、コード アクセス セキュリティ モデルである、.NET Framework セキュリティ モデルに基づいています。 .NET Framework は、ランタイムが完全に信頼されるコードと部分的に信頼されるコードの両方をホストできると仮定する、コード アクセス セキュリティ メカニズムをサポートしています。 .NET Framework コード アクセス セキュリティによって保護されるリソースは、通常、リソースへのアクセスを許可する前に対応する権限を要求する、マネージド コードによってラップされます。 権限の要求は、(アセンブリ レベルで) 呼び出し履歴内のすべての呼び出し側が、対応するリソース権限を持つ場合にのみ満たされます。
アセンブリでは、実行権限は Assembly オブジェクトの PermissionSet プロパティを使用して渡されます。 マネージド コードが取得する権限は、有効なセキュリティ ポリシーによって決定されます。 非ホスト環境では、エンタープライズ、コンピューター、ユーザーの 3 つのAnalysis Services既に 3 つのレベルのポリシーが有効です。 コードが取得する権限の有効なリストは、これら 3 つのレベルによって取得される権限の共通部分によって決定されます。
Analysis Servicesホストしている間に、ホスト レベルのセキュリティ ポリシー レベルを CLR に提供します。このポリシーは、常に有効な 3 つのポリシー レベルを下回る追加のポリシー レベルです。 このポリシーは、アプリケーション ドメインによって作成されるアプリケーション ドメインごとにAnalysis Services。
ホストAnalysis Servicesポリシーは、システム Analysis Services固定ポリシーとユーザー アセンブリのユーザー指定ポリシーの組み合わせです。 ホスト ポリシーのユーザー指定の部分Analysis Services、アセンブリごとに次の 3 つのアクセス許可バケットのいずれかを指定するアセンブリ所有者に基づいて行います。
| 設定する権限 | 説明 |
|---|---|
| セーフ | 内部的な計算権限を提供します。 この権限バケットでは、.NET Framework 内の保護されたリソースにアクセスする権限は許可されません。 これは、 PermissionSet プロパティで何も指定されていない場合に、アセンブリに既定の権限バケットです。 |
| ExternalAccess | 外部システム リソースにアクセスする追加機能と共に、 Safe 設定と同じアクセスを提供します。 この権限バケットはセキュリティの保証を提供するものではありませんが、信頼性の保証は提供されます (このシナリオを保証するのは可能です)。 |
| Unsafe | 制限はありません。 この権限セットで実行されるマネージド コードに対する、セキュリティあるいは信頼性の保証はありません。 管理者によって指定されたカスタム権限であっても、すべての権限が、この信頼性のレベルで実行されるコードに与えられます。 |
CLR が Analysis Servicesホストされている場合、スタック ウォーク ベースのアクセス許可チェックは、ネイティブ のコードを使用して境界Analysis Servicesされます。 アセンブリ内のマネージド コードAnalysis Services、常に前に示した 3 つのアクセス許可カテゴリの 1 つになります。
COM (またはアンマネージ) アセンブリ ルーチンは、CLR セキュリティ モデルをサポートしません。
権限借用
マネージド コードが Analysis Services の外部にあるリソースにアクセスするたびに、Analysis Services はアセンブリの ImpersonationMode プロパティ設定に関連付けられている規則に従って、適切な Windows セキュリティ コンテキストでアクセスが行われるのを確認します。 セーフ アクセス許可設定を使用するアセンブリは Analysis Services の外部のリソースにアクセスできないので、これらの規則は ExternalAccess および Unsafe アクセス許可設定を使用するアセンブリにのみ適用されます。
現在の実行コンテキストが Windows Authenticated ログインに対応し、元の呼び出し元のコンテキスト (つまり、途中に EXECUTE AS がない) と同じ場合、Analysis Services はリソースにアクセスする前に Windows Authenticated ログインを偽装します。
元の呼び出し側のコンテキストを変更した中間の EXECUTE AS が存在する場合、外部リソースへのアクセスは失敗します。
ImpersonationMode プロパティは、 ImpersonateCurrentUser または ImpersonateAnonymousに設定できます。 既定の設定、 ImpersonateCurrentUserは、現在のユーザーのネットワーク ログイン アカウントでアセンブリを実行します。 ImpersonateAnonymous 設定を使用する場合、実行コンテキストは、サーバーの Windows ログイン ユーザー アカウント IUSER_servername に対応します。 これは、制限されたサーバー権限を持つ、インターネット ゲスト アカウントです。 このコンテキストで実行するアセンブリは、ローカル サーバーの制限されたリソースにのみアクセスできます。
アプリケーション ドメイン
Analysis Servicesアプリケーション ドメインを直接公開することはできません。 各アプリケーション ドメインは、同じアプリケーション ドメイン内で実行される一連のアセンブリにより、.NET Framework の System.Reflection 名前空間または他の方法を使用して実行時に互いを検出し、遅延バインドで互いの呼び出しを行うことができます。 このような呼び出しは、承認ベースのセキュリティによって使用されるAnalysis Servicesチェックの対象とされます。
アプリケーション ドメインの境界と各ドメインで実行されるアセンブリは実装ごとに定義されるため、同じアプリケーション ドメインからアセンブリを検出できるとは限らないことに注意してください。