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)
アセンブリは、共通コードを 1 回開発し、1 つの場所に格納できるようにすることで、データベース開発を簡略化します。 クライアント ソフトウェア開発者は、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 プロパティと共に渡されます。 マネージド コードが受け取るアクセス許可は、有効なセキュリティ ポリシーによって決まります。 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 の外部のリソースにアクセスできないため、これらの規則は、ExternalAccessおよびUnsafeアクセス許可設定を使用するアセンブリにのみ適用されます。
現在の実行コンテキストが Windows 認証ログインに対応し、元の呼び出し元のコンテキストと同じ場合 (つまり、中央に EXECUTE AS がない場合)、Analysis Services はリソースにアクセスする前に Windows 認証済みログインを偽装します。
元の呼び出し元からコンテキストを変更した中間 EXECUTE AS がある場合、外部リソースへのアクセスは失敗します。
ImpersonationMode プロパティは、ImpersonateCurrentUserまたはImpersonateAnonymousに設定できます。 既定の設定 ImpersonateCurrentUserは、現在のユーザーのネットワーク ログイン アカウントでアセンブリを実行します。
ImpersonateAnonymous設定を使用する場合、実行コンテキストは、サーバー上の Windows ログイン ユーザー アカウントIUSER_servername に対応します。 これは、サーバーに対する特権が制限されているインターネット ゲスト アカウントです。 このコンテキストで実行されているアセンブリは、ローカル サーバー上の制限付きリソースにのみアクセスできます。
アプリケーション ドメイン
Analysis Services は、アプリケーション ドメインを直接公開しません。 同じアプリケーション ドメインで実行されているアセンブリのセットのため、アプリケーション ドメインは、.NET Framework の System.Reflection 名前空間を使用して実行時に互いを検出し、遅延バインディング方式で呼び出すことができます。 このような呼び出しは、Analysis Services の承認ベースのセキュリティで使用されるアクセス許可チェックの対象となります。
アプリケーション ドメインの境界と各ドメインに入るアセンブリは実装によって定義されるため、同じアプリケーション ドメイン内のアセンブリを検索する必要はありません。