ディメンションの概要 (Analysis Services - 多次元データ)
すべての Microsoft SQL Server Analysis Services ディメンションは、データ ソース ビューのテーブルの列またはビューに基づく属性のグループです。 ディメンションには、キューブとは無関係に存在するもの、複数のキューブ内で使用できるもの、および 1 つのキューブ内で複数回使用できるものがあり、Analysis Services インスタンス間でリンクできます。 キューブとは無関係に存在するディメンションをデータベース ディメンションといい、キューブ内のデータベース ディメンションとデータベース ディメンションのインスタンスをキューブ ディメンションといいます。
スター スキーマ デザインに基づくディメンション
ディメンションの構造は、主に、基になるディメンション テーブルの構造によって決まります。 最も単純な構造をスター スキーマといいます。このスキーマでは、各ディメンションが、主キーと外部キーのリレーションシップによってファクト テーブルに直接リンクされている 1 つのディメンション テーブルに基づいています。
次の図は、 AdventureWorksDW2012 サンプル データベースのサブセクションを示しています。この中で、FactResellerSales ファクト テーブルは、2 つのディメンション テーブル DimReseller と DimPromotion に関連付けられています。 FactResellerSales ファクト テーブルの ResellerKey 列は、DimReseller ディメンション テーブルの ResellerKey 主キー列に対する外部キー リレーションシップを定義します。 同様に、FactResellerSales ファクト テーブルの PromotionKey 列は、DimPromotion ディメンション テーブルの PromotionKey 主キー列に対する外部キー リレーションシップを定義します。
.gif "ファクト ディメンションのリレーションシップの論理スキーマ")
スノーフレーク スキーマ デザインに基づくディメンション
ディメンションを定義するには複数のテーブルからの情報を必要とするため、より複雑な構造が必要になることがよくあります。 この構造は、スノーフレーク スキーマといいます。このスキーマでは、各ディメンションが、最終的には主キーと外部キーのリレーションシップによってファクト テーブルにリンクされる、相互にリンクされた複数のテーブルの列の属性に基づいています。 たとえば、次の図は、サンプル プロジェクト AdventureWorksDW の Product ディメンションを完全に記述するために必要なテーブルを示しています。
.gif "AdventureWorksAS の Product ディメンション用のテーブル")
製品を完全に記述するには、製品のカテゴリとサブカテゴリを Product ディメンションに含める必要があります。 ただし、これらの情報は、DimProduct ディメンションのメイン テーブルに直接含まれているわけではありません。 DimProduct から DimProductSubcategory への外部キー リレーションシップを使用すると、DimProductSubcategory には、DimProductCategory テーブルへの外部キー リレーションシップがあるので、製品のカテゴリおよびサブカテゴリに関する情報を Product ディメンションに含めることができるようになります。
スノーフレーク スキーマと参照リレーションシップの対比
状況によっては、スノーフレーク スキーマを使用して 1 つのディメンション内の属性を複数のテーブルから定義するか、2 つの異なるディメンションを定義して、そのディメンション間の参照ディメンション リレーションシップを定義するか、選択が必要になる場合があります。 次の図は、このようなシナリオを示しています。
.gif "サンプルの参照されるディメンションの論理スキーマ")
上の図では、FactResellerSales ファクト テーブルに、DimGeography ディメンション テーブルとの外部キー リレーションシップがありません。 ただし、FactResellerSales ファクト テーブルには DimReseller ディメンション テーブルとの外部キー リレーションシップがあり、DimReseller ディメンション テーブルには DimGeography ディメンション テーブルとの外部キー リレーションシップがあります。 各販売店に関する地理情報を含む Reseller ディメンションを定義するには、DimGeography ディメンション テーブルと DimReseller ディメンション テーブルからこれらの属性を取得する必要があります。 ただし Analysis Services で、2 つの異なるディメンションを作成し、その 2 つのディメンション間で参照ディメンション リレーションシップを定義することによりメジャー グループ内でこれらのディメンションをリンクしても、同じ結果を得られます。 参照ディメンション リレーションシップの詳細については、「ディメンション リレーションシップ」を参照してください。
このシナリオで参照ディメンション リレーションシップを使用することの利点の 1 つとして、1 つの地理ディメンションを作成した後、追加のストレージ領域を必要とすることなく、この地理ディメンションに基づいて、複数のキューブ ディメンションを作成できることが挙げられます。 たとえば、地理キューブ ディメンションの 1 つを販売店ディメンションにリンクし、別の地理キューブ ディメンションを顧客ディメンションにリンクすることができます。 関連項目 : ディメンション リレーションシップ、参照リレーションシップと参照リレーションシップのプロパティの定義
ディメンションの処理
ディメンションを作成した後、ディメンション内の属性および階層のメンバーを表示するには、あらかじめこのディメンションを処理しておく必要があります。 ディメンションの構造が変更されたり、その基になるテーブルの情報が更新された場合、ディメンションをもう一度処理しないと、変更内容を表示できません。 構造の変更後にディメンションを処理する際は、そのディメンションが含まれたキューブも処理する必要があります。これを行わないと、キューブを表示できません。
セキュリティ
ディメンションの従属オブジェクトは、階層、レベル、メンバーを含め、Analysis Services のロールを使用してすべてセキュリティで保護されています。 ディメンションのセキュリティは、そのディメンションを使用するデータベース内のすべてのキューブ、または特定のキューブにのみ適用できます。 ディメンションのセキュリティの詳細については、「ディメンション アクセスの許可」を参照してください。