多次元モデルのアセンブリの管理
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 アセンブリは SQL Server 2008 Analysis Services (SSAS) で非推奨となりました。 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, ...)
Security
アセンブリのセキュリティは、コード アクセス セキュリティ モデルである、.NET Framework セキュリティ モデルに基づいています。 .NET Framework は、ランタイムが完全に信頼されるコードと部分的に信頼されるコードの両方をホストできると仮定する、コード アクセス セキュリティ メカニズムをサポートしています。 .NET Framework コード アクセス セキュリティによって保護されるリソースは、通常、リソースへのアクセスを許可する前に対応する権限を要求する、マネージド コードによってラップされます。 権限の要求は、(アセンブリ レベルで) 呼び出し履歴内のすべての呼び出し側が、対応するリソース権限を持つ場合にのみ満たされます。
アセンブリでは、実行権限は PermissionSet オブジェクトの Assembly プロパティを使用して渡されます。 マネージド コードが取得する権限は、有効なセキュリティ ポリシーによって決定されます。 Analysis Services 以外のホスト環境では、エンタープライズ、コンピューター、ユーザーの 3 つのレベルのポリシーが既に有効です。 コードが取得する権限の有効なリストは、これら 3 つのレベルによって取得される権限の共通部分によって決定されます。
Analysis Services は、ホスト中に CLR にホスト レベルのセキュリティ ポリシー レベルを提供します。このポリシーは、常に有効な 3 つのポリシー レベルより下の追加のポリシー レベルです。 このポリシーは、Analysis Services によって作成されるすべてのアプリケーション ドメインに対して設定されます。
Analysis Services ホスト レベル ポリシーは、システム アセンブリの Analysis Services 固定ポリシーとユーザー アセンブリのユーザー指定ポリシーの組み合わせです。 Analysis Services ホスト ポリシーのユーザー指定の部分は、各アセンブリに対して 3 つのアクセス許可バケットのいずれかを指定するアセンブリ所有者に基づいています。
| 設定する権限 | 説明 |
|---|---|
Safe |
内部的な計算権限を提供します。 この権限バケットでは、.NET Framework 内の保護されたリソースにアクセスする権限は許可されません。 これは、PermissionSet プロパティで何も指定されていない場合に、アセンブリに既定の権限バケットです。 |
ExternalAccess |
外部システム リソースにアクセスする追加機能と共に、Safe 設定と同じアクセスを提供します。 この権限バケットはセキュリティの保証を提供するものではありませんが、信頼性の保証は提供されます (このシナリオを保証するのは可能です)。 |
Unsafe |
制限はありません。 この権限セットで実行されるマネージド コードに対する、セキュリティあるいは信頼性の保証はありません。 管理者によって指定されたカスタム権限であっても、すべての権限が、この信頼性のレベルで実行されるコードに与えられます。 |
CLR が Analysis Services によってホストされている場合、スタック ウォーク ベースのアクセス許可チェックネイティブ Analysis Services コードとの境界で停止します。 Analysis Services アセンブリ内のマネージド コードは、常に前に示した 3 つのアクセス許可カテゴリのいずれかに分類されます。
COM (またはアンマネージ) アセンブリ ルーチンは、CLR セキュリティ モデルをサポートしません。
偽装
マネージド コードが Analysis Services 以外のリソースにアクセスするたびに、Analysis Services はアセンブリのプロパティ設定に ImpersonationMode 関連付けられている規則に従って、適切な Windows セキュリティ コンテキストでアクセスが行われるようにします。 アクセス許可設定を使用するSafeアセンブリは Analysis Services の外部のリソースにアクセスできないため、これらの規則は、 および Unsafe アクセス許可設定を使用するExternalAccessアセンブリにのみ適用されます。
現在の実行コンテキストが Windows 認証済みログインに対応し、元の呼び出し元のコンテキストと同じである場合 (つまり、中央に EXECUTE AS がない場合)、Analysis Services はリソースにアクセスする前に Windows 認証済みログインを偽装します。
元の呼び出し側のコンテキストを変更した中間の EXECUTE AS が存在する場合、外部リソースへのアクセスは失敗します。
ImpersonationMode プロパティは、ImpersonateCurrentUser または ImpersonateAnonymous に設定できます。 既定の設定、ImpersonateCurrentUser は、現在のユーザーのネットワーク ログイン アカウントでアセンブリを実行します。 設定が ImpersonateAnonymous 使用されている場合、実行コンテキストは、サーバー上の Windows ログイン ユーザー アカウントIUSER_servername に対応します。 これは、制限されたサーバー権限を持つ、インターネット ゲスト アカウントです。 このコンテキストで実行するアセンブリは、ローカル サーバーの制限されたリソースにのみアクセスできます。
アプリケーション ドメイン
Analysis Services は、アプリケーション ドメインを直接公開しません。 各アプリケーション ドメインは、同じアプリケーション ドメイン内で実行される一連のアセンブリにより、.NET Framework の System.Reflection 名前空間または他の方法を使用して実行時に互いを検出し、遅延バインドで互いの呼び出しを行うことができます。 このような呼び出しは、Analysis Services の承認ベースのセキュリティで使用されるアクセス許可チェックの対象になります。
アプリケーション ドメインの境界と各ドメインで実行されるアセンブリは実装ごとに定義されるため、同じアプリケーション ドメインからアセンブリを検出できるとは限らないことに注意してください。