統合ディメンション モデル

  • [アーティクル]

ERP (Enterprise Resource Planning) データベースなどのデータ ソースから情報を直接取得する必要があるユーザーは、いくつかの難題に直面しています。

  • このようなデータ ソースの内容は、ユーザーではなくシステムや開発者を念頭に置いて設計されているので、非常に理解しにくい場合も少なくありません。
  • ユーザーにとって関心のある情報は、通常、複数の異種データ ソースに分散されています。リレーショナル データベースだけが異なる場合でも、ユーザーは使用する SQL の言語仕様など、各データベースの詳細を理解する必要があります。また、これらのデータ ソースは、リレーショナル データベースだけでなく、ファイルや Web サービスなど、種類が大きく異なる場合があります。
  • 多くのデータ ソースは、トランザクション レベルの詳細を大量に保持できるようになっていますが、ビジネス上の意志決定をサポートするクエリでは、集計された概要情報が必要になることも少なくありません。データ量が増加すると、このような集約値を取得するために必要な時間が極端に長くなり、対話形式のエンド ユーザー分析を行うには無理が生じる場合があります。
  • 通常、ビジネス ルールはデータ ソースにカプセル化されていません。ユーザーは、自分でデータを解釈する必要があります。

統合ディメンション モデル (UDM) の役割は、ユーザーとデータ ソース間の橋渡しをすることです。UDM は、1 つまたは複数の物理的なデータ ソース上に構築されます。ユーザーは Microsoft Excel などのさまざまなクライアント ツールを使用して、UDM に対するクエリを発行します。

単一の UDM を介した、クライアントによるすべてのデータ ソースへのアクセス

データ ソースを覆う薄い層として UDM を構築しただけでも、エンド ユーザーにとっては、より理解しやすいデータ モデル、異種のバックエンド データ ソースからの分離、集約型クエリのパフォーマンスの向上という利点があります。しかもシナリオによっては、単純な UDM は自動的に構築できる場合もあります。UDM の構築にさらに投資を行った場合は、そのモデルから提供されるメタデータの豊富さによって、さらに多くの利点がもたらされます。

UDM には次の利点があります。

  • ユーザー モデルを大幅に強化する。
  • データ量が非常に多い場合でも、対話形式での分析をサポートする高パフォーマンスのクエリが実現される。
  • ビジネス ルールをモデルに取り込んで、豊富な分析機能をサポートする。
  • "環を閉じる (Closing the Loop)" : 表示されたデータに対してユーザーがアクションを実行できる。

基本的なエンド ユーザー モデル

ユーザーが複数の異なる期間の売上とノルマを比較する必要がある場合の例を考えます。

売上データは、他の多くのテーブルと共に、メインの Sales and Inventory データベースに格納されています。使用するテーブルを特定した後でも、Product などの 1 つのエンティティのデータが数多くのテーブルに分散していることに気付く場合があります。参照整合性がアプリケーション ロジックによって適用されているので、これらのテーブル間にはリレーションシップが定義されていません。Sales Quotas は別のアプリケーションのデータベースに格納されています。どのデータベースにも、ノルマと実際の売上を比較する場合に、注文に関する他の日付 (注文日、期限日、予定日など) ではなく注文の出荷日を使用する必要があるなどのビジネス ルールは取り込まれていません。

データ ソースへの直接アクセス

まず、エンド ユーザーがデータ ソースに直接アクセスする場合を検討します。次の図は、サンプル ツールを使用して作成するクエリの例を示しています。

異種データ ソース間の結合が可能な DSV

この時点までに、ユーザーの作業はかなり進行しています。進捗状況は以下のとおりです。

  • 対象となるテーブルを見つけるために、多数のわかりにくい名前のテーブルを入念に調べました。
  • テーブルとの結合に使用する列を特定しました。
  • 含まれている詳細のシステム指向色が強い多数のテーブルから、関心のある詳細を含む列を選択しました。たとえば、製品カテゴリの詳細情報を含んでいるテーブルの 11 個の列の中で、ユーザーに実際に関係があるのは 2 つの名前列だけです。

ユーザーは現在、"外部" 結合と "内部" 結合の使い分けと、必要な集計を提供するための詳細情報のグループ化方法を定義する作業に取り組んでいます。

しかし、ユーザーはさらに困難な作業に直面します。たとえば、どのようにしてデータを他のデータ ソースと結合するのでしょうか。いずれかのデータベースで分散クエリがサポートされていたとしても、大部分のユーザーは分散クエリを作成できません。また、その作業をユーザーが行う際にツールから提供されるサポートが不十分な場合もあります。次のサンプル コードは、外部データを照会する 1 つの方法を示しています。

SELECT Quotas.QuotaAmount, Quotas.EmployeeId, …
FROM OPENROWSET('SQLOLEDB','seattle1';
'Sales';'MyPass',
   'SELECT * FROM Forecasts.dbo.SalesQuota’ ) As Quotas

Web サービスなどの他のデータ ソースを使用する場合、ユーザーは、どのようにして適切なリモート呼び出しを行うのか、またその後で、返された XML を他のデータと結合するにはどのような処理を行えばよいのかを決定する際に、別の大きな障害に直面します。

さらに、この作業を 1 つのクエリに対して行っても、その多くは、次のクエリ、さらにその後のクエリに対しても個別に行う必要があります。

UDM を使用したデータ ソースへのアクセス

これに対して、次の図は、データ ソース上に構築された単純な UDM にアクセスしているユーザーにクエリの作成がどのような形で表示されるのかを示しています。

複数のデータ ソースでのクライアントの UDM へのアクセス

この例で示されているデザイン インターフェイスは、Microsoft SQL Server 2005 に付属の開発ツールで使用できます。ただし、UDM をサポートしている任意のインターフェイスを使用することもできます。たとえば、Office Excel や Office Web コンポーネント (OWC) などのクライアント ツールを使用することも、よくあるレポート作成/分析ツールを使用することもできます。

左側のツリー ビューは、UDM のコンテンツを示します。この例では、次の点に注意してください。

  • ユーザー指向の関連アイテムのみがユーザーに表示されます。行の GUID などのシステム列、または最終更新日時は表示されません。
  • 名前は、基になるデータベースで採用されている開発者指向の命名規則に従った名前ではなく、表示名が使用されます。

また、UDM では、Product や Employee などの各ビジネス エンティティのすべての属性が個別の "ディメンション" にグループ化されます。このため、クライアントは、関連する多数のテーブル間で明示的に結合を行わなくても、この例の Product Color、Subcategory、および Category を参照できます。

トランザクション値、つまり測定値を表す列は、"メジャー" として表示されます。たとえば、ユーザーは通常、売上金額や販売ノルマなどの集計列を必要とします。"メジャー" および "ディメンション" としてデータを表示するこの方法は、ディメンション モデリングと呼ばれます。

図の右側には、現在のクエリに含まれている要素が示されています。この場合、"製品カテゴリ別の売上金額およびノルマ" を要求するために、ユーザーは 3 つの関連アイテムをツリー ビューからデザイン インターフェイスの右側にドラッグするだけでクエリを定義しました。2 つの異なるデータ ソースに実際にアクセスするために必要な詳細情報を指定する必要も、関連する多数のテーブル間で正しい結合を行う必要もありませんでした。

このモデルでは、通貨記号の使用など、既定で使用する基本的な書式が定義されています。特定のしきい値より低い場合に値を赤字で表示するなどの条件付き書式を含む、さらに高度な書式を定義することもできます。

このモデルではさまざまなクエリがサポートされています。たとえば、Employee ディメンションから属性をドラッグするだけで、図を従業員別にさらに分割できます。

基本モデルの拡張

前の例では、単純な UDM でも基本的なデータ探索作業を大幅に簡略化できる方法を示しました。ただし、ユーザーにデータのアクセス権を許可する場合には、さらに別の問題を検討する必要があります。次に例を示します。

  • 異なるユーザーからのさまざまな種類のクエリをサポートする UDM は、サイズが非常に大きくなることがあります。特定の作業に取り組んでいるユーザーが無関係の情報で妨害されないようにするには、どのようにしたらよいでしょうか。
  • 母国語でのレポートの表示を希望するグローバル ユーザーは、どのようにサポートしたらよいでしょうか。
  • 時間に関する一般的な質問を簡単に処理するにはどうしたらよいでしょうか。たとえば、売上を前年の同時期と比較して表示したい場合などがあります。

ここでは、これらの疑問のいくつかについて検討し、UDM がどのように基本モデルを拡張して高度なデータ探索を可能にしているかを示します。

階層

エンティティの属性をすべてディメンションに統合すると、ユーザーにとってはモデルが大幅に簡略化されることになりますが、属性間には、単純な一覧では表現できないリレーションシップが他にも存在しています。前の例では、Category、SubCategory、および SKU が、製品を体系化する階層の 1 つを定義しています。分析はこれらの階層に基づいて行うことが多いので、UDM ではこのような階層を定義できます。たとえば Category 別の合計をまず表示し、次に SubCategory にドリル ダウンし、続いて最下位の SKU レベルにドリル ダウンする場合があります。各階層は属性の連続であり、これらをクエリで使用することで、ドリル ダウンやドリル アップのシナリオを簡単にすることができます。

次の図は、エンド ユーザーに表示されるインターフェイス内で階層がどのように表示されるかを示しています。モデルには複数の異なる階層が含まれており、製品はこれらの階層に従って編成されます。ここで示されているクエリは、"製品カテゴリ別の売上およびノルマを表示し、次にサブカテゴリに分類する" という問いに答えます。このクエリは、"Products By Category" 階層をグリッドにドラッグして定義しました。詳細なデータを表示するには、"Bike" カテゴリをダブルクリックしてサブカテゴリを展開します。

UDM での階層の移動

階層のレベル間で移動する場合の細部は、UDM によって処理されます。また、UDM では、Quotas は SubCategory レベルにはなく、Category レベルでのみ使用できるといった細かい仕様にも対応できます。

特殊な種類の階層として、親子階層があります。これは、互いに複雑なリレーションシップを持つエンティティに対応しています。次の図の Employee ディメンションには "Employees By Organization Structure" という階層があります。この階層を使用すると、組織の各レベルで親子リレーションシップ間の移動やロールアップ値の分析が簡単にできます。たとえば、VP of Sales (営業部長) である Charles Marshall のノルマには、彼のスタッフ全員のノルマの合計に加えて、彼に直接関連付けられているノルマが含まれています。

UDM での親子階層の移動

カテゴリ化

ユーザーは通常、データにカテゴリ化を適用します。たとえば、"これらの属性はすべて従業員の個人的な詳細情報に関するものである" や、"その属性は電子メール アドレスである" のようにカテゴリ化します。UDM は、特にこのようなカテゴリ化に基づいて価値を付加できるように、2 つのメカニズムを備えています。

  • ディメンション、属性、その他のオブジェクトは、意味のあるカテゴリに配置することによって、クライアント ツール内でさらに有効に利用することができます。たとえば、ある属性を URL として設定することができます。その場合、この属性が含まれたレポートでは、その URL の値に基づいた移動が可能になります。別の属性を電子メール アドレスとして設定することもできます。この場合、レポート作成用のクライアントでは、何らかのユーザー操作が行われたときに新しい電子メールを自動的に開くといった処理ができます。
  • メジャー、階層、その他のオブジェクトは、ユーザーにとって意味のあるフォルダにグループ化できます。これにより、レポート作成ツールで数多くの属性を表示する際に、扱いやすい表示が可能になります。たとえば、"Customer Demographics" という属性のグループを作成できます。

時間

通常、時間情報は DataTime または Date データ型のいずれかを使用して、基になるデータ ソースに記録されています。SQL または XPath に精通しているユーザーであれば、年別にデータを合計するのに必要な日付情報を抽出できますが、そのようなユーザーにとっても、"曜日別売上の表示" や "7 月 1 日から始まる会計年度別の分類" など、時間のそれ以外の側面に基づいたクエリを作成することは、困難な場合があります。

ところが UDM には、次のようなカレンダーを含めた時間認識が組み込まれています。

  • 標準
  • 会計
  • レポート ("445" など)
  • 製造 (13 期間)
  • ISO8601

したがって、モデルには、日ごとの詳細を定義するための属性のセットを豊富に備えた時間ディメンションを含めることができます。次の図は、ユーザーが会計年度 2001 年の売上金額とノルマの表示を選択した結果を示しています。この操作を行うには、関連アイテムをツリーからフィルタ領域にドラッグするだけで済みました。UDM では、このユーザー操作を日付の範囲に変換する方法と、クエリに含める必要があるのが期限日や注文日ではなく、注文の出荷日であることを示すビジネス ルールの両方を理解しています。UDM によって正しい結合が暗黙のうちに行われます。

時間によるメジャーのディメンション指定

さらに UDM には、"今月を前年の同月と比較する" といった期間対期間の比較を含む、時間に関する一般的な質問を処理するためのサポートが特別に用意されています。

翻訳

前の例では、モデルの内容とデータの両方が 1 つの言語で表示されています。ただし、国際的なユーザーの場合は、自分のローカル言語でメタデータを表示する必要が生じます。

これに対処するために、UDM ではメタデータの翻訳を任意の言語で提供できるようにしています。特定のロケールを使用して接続しているクライアント アプリケーションは、すべてのメタデータを適切な言語で受け取ることができます。

また、データの翻訳をモデルで提供することもできます。1 つの属性をデータ ソース内の異なる複数の要素にマップして、それらの要素に対して異なる言語で翻訳を提供することができます。たとえばユーザーが、前の例で使用したツールと同じツールを使用してフランス語ロケールのクライアント コンピュータから接続すると、次の図に示すように、UDM とクエリの結果はフランス語で表示されます。

UDM でのメタデータの翻訳の表示

分析観点

ここで使用しているモデル例のサイズはあまり大きくありません。現実のモデルはこれよりはるかに広い範囲で定義され、数十ものメジャーやディメンションを含み、各ディメンションには数十または数百の属性が含まれている場合があります。特定の作業に従事するユーザーは、通常、このようなモデル全体を表示する必要はありません。モデル全体のサイズの大きさでユーザーが困らないようにするには、モデルのサブセットを表示するためのビューを定義する必要性が生じます。

UDM にはこのようなビューが用意されており、それらは分析観点と呼ばれます。UDM には多数の分析観点が用意されており、各分析観点では、特定のグループのユーザーに関係のある、モデルの特定のサブセットのみ (メジャー、ディメンション、属性など) が表示されます。各分析観点は、その分析観点の表示を許可されているユーザーを定義するユーザー セキュリティ ロールに関連付けることができます。

たとえば、"Seattle Inventory" という分析観点は、Inventory メジャー グループからのメジャーのみを含み、"Warehouse By Location" 階層を非表示にし、既定の City を "Seattle" にするように定義できます。

属性のセマンティックス

UDM には、属性のセマンティックスが他にも用意されています。これらのセマンティックスは、情報の使用を容易にするためのものです。属性に適用できるいくつかのセマンティックスの例を次に示します。

  • 名前対キー : リレーショナル データベースを見ても、EmployeeID が、システムによって生成された、意味のない一意のキーであることが明白でない場合があります。UDM では Employee 属性にキー (一意の EmployeeID) と名前 (たとえば FirstName と LastName を連結したもの) の両方を持たせることで、この問題を解決しています。"従業員を表示する" といったクエリでは、同じ名前を持つ従業員は一意の ID から正しく区別され、ユーザーに対しては意味のある名前が表示されるようになります。
  • 順序 : 多くの場合、属性の値は、単純なアルファベット順や数値順ではなく、一定の順序で表示する必要があります。UDM では、この要件を満たす既定の順序を定義できます。次に例を示します。
    • 曜日は "日曜日"、"月曜日"、"火曜日" などと表示されます。
    • 優先順位は "高"、"中"、"低" の順序で表示されます。
  • 分離 : 数値属性では、属性のそれぞれの値を表示しても意味がない場合があります。たとえば、製品の個々の価格 ($9.97、$10.05、$10.10、…) について売上を表示するよりも、価格範囲 (<$10、$10 ～ $15、…) 別売上を表示した方がはるかに役立ちます。UDM を使用すると、さまざまな基準を使用して属性をこのような範囲に分けることができます。

主要業績評価指標 (KPI)

企業ではしばしば、主要業績評価指標 (KPI) が定義されます。これは、企業の健全性の測定に使用される重要な基準です。UDM ではこのような KPI を作成できるので、企業は理解しやすい形式でデータをグループ化したり表示することができます。また、KPI では、良好、平均、不良などを示す信号機マークなど、状態と傾向を表したグラフィックを使用できます。

UDM における各 KPI では、各パフォーマンス基準に対して次の最高 4 つの表現が定義されます。

  • 実績値
  • 目標値
  • 状態 : -1 ～ 1 の範囲の正規化された値で、実績対目標の比率 (-1 は "非常に悪い"、1 は "非常に良い") を示します。
  • 傾向 : -1 ～ 1 の範囲の正規化された値で、一定期間の傾向 (-1 は "大幅に悪化している"、1 は "大幅に改善されている") を示します。

KPI を使用することにより、ユーザーがすぐに理解できる形式で、関連するメジャーをクライアント ツールで示すことができます。次の図は、表示フォルダに編成されている 3 つの KPI がクライアント ツールでどのように表示されるのかを示しています。

UDM での KPI の表示

パフォーマンス

ユーザーによる対話形式での問い合わせには、高速な応答時間が求められます。非常に大きなデータセットを対象にしてこのような問い合わせが頻繁に行われる場合、この要件への対応が課題になります。

UDM ではパフォーマンスを改善するためにキャッシュ サービスが用意されています。キャッシュには、基になるデータ ソースから読み取られた詳細データと、そのデータに基づいて事前に計算された集計値の両方を格納できます。ただし、そのようなキャッシュ値を使用すると、データがある程度古くなります。どの程度新しい情報が必要であるかは、ビジネス要件によって異なります。最新のデータを表示することが重要な場合もあれば、2 時間前または 2 日前のデータを表示してもまったく差し支えない場合もあります。

データの即時性を決定するためのポリシーを反映させるために、UDM ではキャッシュを明示的に管理する (たとえばキャッシュを毎日午前 2 時に更新するようにスケジュールを定義する) ことも、プロアクティブ キャッシュを使用して透過的に管理することもできます。ユーザーはデータの新しさの度合いを指定でき、UDM ではできるだけ高速にクエリに応答するために、キャッシュの自動作成および管理機能を提供しています。

分析

前のセクションでは、UDM が対話形式でのデータの探索をどのようにサポートするかについて説明しました。ただし、基になるデータ ソースから単に情報を取得するだけでは、それが非常にわかりやすく使いいやすい形式であったとしても、複雑なビジネス ロジックをユーザー モデルに組み込む目標を達成しているとは言えません。このため UDM は、データに対して単純な計算も複雑な計算も定義できる機能を備えています。

基本的な分析

クエリは通常、集計データを返します。たとえば典型的なクエリでは、販売注文を個別にすべて表示するのではなく、カテゴリ別に売上を表示します。ただし、基になるリレーショナル データには特定のメジャーの集計方法を定義するようなルールはありません。たとえば、売上金額を適切に合計し、単価を平均するなどの処理が考えられます。UDM ではこのような機能を追加します。

集計方法は、次のようなさまざまな方法で定義できます。

  • Sum、Count、Distinct Count、Max、Mix などの単純な集計関数が使用可能です。
  • 集計は準加法として定義できます。これは、"Last Period" が使用される時間ディメンション以外のすべてのディメンションで、Sum などの単純な関数が使用されることを意味します。たとえば、Inventory Level は Product から Product Category までを合計できますが、月の在庫レベルは各日の在庫レベルの合計ではなく、月の最後の日の在庫レベルになります。
  • 集計は、Income 対 Expense などの勘定科目の種類に基づくことができます。
  • 集計は、特別な要件を満たすためにカスタマイズできます。

UDM には、計算されるメンバを含めることもできます。これらのメンバは、ソース データに直接関連付けられているのではなく、そのデータから派生します。たとえば、計算されるメンバの Variance は、Sales と Quota の差を計算するために定義できます。

同様に、UDM ではユーザーにとって関心のあるエンティティのセットを定義できます。たとえば、売上高別のトップ 10 の顧客や、最も重要な製品などを定義できます。これらのセットは、その後クエリの範囲を特定のエンティティのセットに制限するために簡単に使用できます。

高度な分析

ユーザーが要求する計算は、先ほど示した "Variance" の例よりもはるかに複雑な場合があります。次に、いくつかの複雑な計算の例を示します。

  • 各期間について 3 か月の移動平均を示す。
  • 前年の同期間と成長率を比較する。
  • 売上が基本通貨で表示されている場合は、その売上を売上時の日次平均為替レートを使用して元の通貨に変換する。
  • 来年のカテゴリ別予算売上を今年の 10% 増として計算し、過去 3 年間の相対平均売上に基づいて各製品に予算を割り当てる。

UDM にはこのような計算を定義するための豊富なモデルが用意されており、UDM は、セルの値を他のセルの値に基づいて計算できる、多次元スプレッドシートのようなものと考えることができます。しかし、これだけでは、UDM の強力な計算機能を十分に説明できたとは言えません。セルの値は、他のセルの現在の値だけではなく過去の値にも基づいて計算される場合があります。このため、連立方程式がサポートされています。たとえば、利益は売上から費用を差し引くことで求められますが、費用に含まれるボーナスは、利益から求められます。

このような計算式を作成するために設計された強力な言語 MDX (多次元式) に加えて、UDM では Microsoft .NET との統合も実現しています。これにより、ストアド プロシージャや関数を C#.NET や Visual Basic.NET などの任意の検証可能な .NET 言語で作成できます。作成したストアド プロシージャや関数は、計算に使用する目的で MDX から呼び出せます。

このような計算の細部はクライアントから独立して行われます。クライアント アプリケーションからは、さらに多くの便利なメジャーがモデルに追加されているように見えるだけです。たとえば次の例では、ユーザーは米国で販売された最も利益の高い製品を把握するために、Sales に基づいて計算されたさまざまなメジャーを表示しています。

UDM での計算されるメジャーの表示

データ マイニングとの統合

簡単に理解できる詳細な形式でデータを表示する機能は有益ですが、そのデータから新しい情報を推測する機能も必要です。

UDM はデータ マイニング テクノロジと密接に統合されており、データをマイニングし、その後で発見したパターンから予測を行うことができるようにしています。

データに基づいたアクション

多くの場合、ユーザーがデータを表示すると、そこから直ちに新しい疑問が生じたり、さらに別のアクションが必要になります。次に例を示します。

  • "その数字をもたらした売上の内訳はどのような内容か。"
  • "ノルマが低すぎるので高める必要がある。"
  • "それはおかしい。その数字にコメントを付ける必要がある。"
  • "そのプロモーションに関して Web サイトにはどのような詳細が記述されているか。"

一方的にユーザーにわかりやすくデータを表示するだけでは十分ではありません。また、ユーザーが表示されたデータに基づいて簡単にアクションを実行できるようにする必要もあります。

UDM ではこれを次の 2 種類の方法でサポートしています。

  • 変更をデータに書き戻せます。
  • データにアクションを関連付けられるようにしています。

書き戻し

UDM は読み取り専用ではありません。データは UDM を通じて更新することも可能です。メジャーの場合、更新は元の値の差分として、元の値とは別に保持できます。

さらに、サマリ値の更新もできます。たとえば、予算作成シナリオを検討します。予算額は最終的には詳細レベル (チームおよび勘定科目別) まで特定できても、最初は集約されたレベル (部門と勘定科目の種類別) でしかわからない場合があります。

アクション

UDM ではデータとデータに基づいたアクション間のリンクとしてアクションをサポートしています。主なアクションの種類は次のとおりです。

  • URL : 指定された URL に移動する。このアクションでは、さらに情報を取得できるようにユーザーを特定の URL に誘導することと、別の作業を実行するための Web ベースのアプリケーションにユーザーを誘導することが可能です。次に例を示します。
    • ある製品に関して、その製品について説明している企業 Web サイトに移動する。
    • 製品と倉庫の組み合わせに関して、Web ベースの在庫管理アプリケーションに移動し、製品と倉庫をパラメータとして渡し、安全在庫レベルを増加できるようにする。
  • レポート作成 : 指定されたレポートを実行する。たとえば、任意の製品に対し、製品の説明と現在の注文状況を記述した、パラメータ化された製品レポートをアクションによって作成できます。
  • ドリルスルー : 最低の詳細レベルまでドリルスルーする。たとえば、製品および顧客別の合計売上を確認しているユーザーは、ドリルスルーによって、その合計に関連している販売トランザクションすべてを表示できます。

アクションは、データの特定の領域に関連付けることができます。たとえば、Web ページに移動するアクションを各製品に適用し、詳細な在庫移動トランザクションを表示するアクションは製品および倉庫別の Quantity の各値に適用できます。

アクションは UDM の一部として定義されますが、適用されるアクションの詳細を取得し、それをユーザーに提供し、必要に応じてそのアクションを開始するのはクライアント アプリケーションの役割です。

セキュリティ

UDM へのアクセスは制御が可能です。主なセキュリティ機能は次のとおりです。

  • UDM はロールベースのセキュリティを提供します。ロールを定義し、そのロールに権限を与え、各ロールのメンバとしてユーザーを追加することができます。ユーザーの実際の権限は、ユーザーが属している各ロールに与えられている権限を結合したものになります。ロールの権限に "強力な拒否" を含めることにより、ユーザーが属している他のロールとは無関係にユーザーの権限を除去することもできます。
  • 管理権限 (UDM を変更する権限など) は、データ アクセス権とは別に許可できます。また、オブジェクトのメタデータを読み取る権限、およびデータの読み取りと書き込みのアクセス用の権限を個別に定義できます。
  • データに対するセキュリティ保護は、個々のセルに至るまでの粒度で指定できます。たとえば、ユーザーが、顧客 "ACME" への製品 "Widget" の売上を表示できないように制限できます。セキュリティには条件を付けることもできます。たとえば、あるロールでは、部門に 5 名を超える従業員が存在する場合にのみ、部門の合計給与を表示できるなどの条件です。
  • 権限では、表示合計を使用するかどうかを定義できます。使用する場合、合計はユーザーに権限がある下位レベルのメンバのみを反映するようになります。セルのアクセスを条件付きにすることもできます。これは、他のセルから派生したセルは、派生元のすべてのセルが表示可能である場合にのみ表示できることを意味します。たとえば、利益が収益とコストから派生している場合、ユーザーは収益とコストの両方を表示する権限を持っている製品についてのみ、利益を表示できることになります。

参照

その他の技術情報

Analysis Services の概念

ヘルプおよび情報

SQL Server 2005 の参考資料の入手