ディメンション リレーションシップ
ディメンションを使用する場合は、キューブ内にある、キューブ ディメンションとメジャー グループ間のリレーションシップが定義されます。キューブ ディメンションとは、特定のキューブで使用されるデータベース ディメンションのインスタンスです。キューブにはキューブ ディメンションを含めることができ、実際、多くの場合は含んでいます。キューブ ディメンションはメジャー グループと直接には関連付けられていませんが、別のディメンションまたは別のメジャー グループを介して間接的にメジャー グループと関連付けられることがあります。データベース ディメンションまたはメジャー グループをキューブに追加すると、MicrosoftSQL ServerAnalysis Services では、キューブのデータ ソース ビューのディメンション テーブルとファクト テーブル間のリレーションシップを調べ、ディメンションの属性間のリレーションシップを調べて、ディメンションの使用法を判別しようとします。Analysis Services は、検出できるリレーションシップのディメンションの使用法を自動設定します。
ディメンションとメジャー グループ間のリレーション シップは、そのリレーション シップに参加しているディメンション テーブルとファクト テーブル、および特定のメジャー グループに含まれているディメンションの粒度を指定する粒度属性で構成されます。
標準ディメンションのリレーションシップ
ディメンションのキー列が直接ファクト テーブルと結合されている場合、キューブ ディメンションとメジャー グループ間には標準ディメンションのリレーションシップが存在します。この直接的なリレーションシップは、基になるリレーショナル データベースの主キー/外部キー リレーションシップに基づきますが、データ ソース ビューで定義されている論理リレーションシップに基づくこともあります。標準ディメンションのリレーションシップは、従来のスター スキーマ デザインにおけるディメンション テーブルとファクト テーブル間のリレーションシップを表します。標準リレーションシップの詳細については、「標準リレーションシップおよび標準リレーションシップ プロパティの定義」を参照してください。
参照ディメンションのリレーションシップ
次の図に示すように、キューブ ディメンションのキー列が別のディメンション テーブルのキーを使用して間接的にファクト テーブルに結合される場合は、このキューブ ディメンションとメジャー グループ間には参照ディメンションのリレーションシップが存在します。
参照ディメンションのリレーションシップは、ディメンション テーブルとファクト テーブル間のリレーションシップをスノーフレーク スキーマ デザインで表します。ディメンション テーブルがスノーフレーク スキーマ形式で関連付けられている場合、複数のテーブルの列を使用して 1 つのディメンションを定義することや、個別のテーブルに基づいて個別のディメンションを定義し、次に、参照ディメンションのリレーションシップの設定を使用してそれらの間にリンクを定義することができます。次の図は、スノーフレーク スキーマの、ファクト テーブル InternetSales およびディメンション テーブル Customer および Geography を示しています。
ディメンション メイン テーブルの Customer テーブルと関連テーブルとして含められた Geography テーブルを使用して 1 つのディメンションを作成できます。作成すると、標準のリレーションシップがディメンションと InternetSales メジャー グループ間に定義されます。
また、InternetSales メジャー グループに関連付けられたディメンションを 2 つ作成することもできます。この場合、1 つは Customer テーブルに基づくディメンションであり、もう 1 つは Geography テーブルに基づくディメンションです。次に、Customer ディメンションを使用する参照ディメンションのリレーションシップを使用して Geography ディメンションを InternetSales メジャー グループに関連付けることができます。この場合、InternetSales メジャー グループ内のファクトを Geography ディメンションを使用して多次元化すると、それらのファクトは顧客別および地域別に多次元化されます。キューブに Reseller Sales という 2 つ目のメジャー グループが含まれる場合は、Reseller Sales と Geography の間にリレーションシップが存在しないので、Geography を使用して Reseller Sales メジャー グループ内のファクトを多次元化することはできません。
次の図に示すように、連結できる参照ディメンションの数に上限はありません。
参照リレーションシップの詳細については、「参照リレーションシップと参照リレーションシップのプロパティの定義」を参照してください。
ファクト ディメンションのリレーションシップ
ファクト ディメンションは逆ディメンションとも呼ばれますが、ディメンション テーブルの属性列ではなくファクト テーブルの属性列で構築される標準ディメンションです。重複部分を減らすために、有用な多次元データがファクト テーブルに格納されることがあります。たとえば、次の図に Adventure Works DW サンプル データベースの FactResellerSales ファクト テーブルを示します。
このテーブルには、販売店からの注文を格納する各行の属性情報だけではなく、注文自体についても属性情報が格納されています。上記の図の丸で囲まれた属性から、ディメンション内の属性として使用できる FactResellerSales テーブル内の情報を特定できます。この場合、運送業者の問い合わせ番号および販売店からの受注番号という 2 つの付加情報が CarrierTrackingNumber 属性列と CustomerPONumber 属性列によって表されます。これは関心を引く情報です。たとえば、1 つの追跡番号で発送されたすべての注文品について、ユーザーは商品の合計金額などの集計情報を確認したいと考えるでしょう。ただし、この 2 つの属性の編成および集計には、ディメンション データが必要です。
理論上は、FactResellerSales テーブルと同じキー情報を使用するディメンション テーブルを 1 つ作成し、残りの 2 つの属性列である CarrierTrackingNumber と CustomerPONumber をそのディメンション テーブルに移動できます。ただし、わずか 2 つの属性を別のディメンションとして表すために、非常に多くの重複データを設定し、データ ウェアハウスを不必要に複雑にすることになります。
注意 |
---|
多くの場合、ファクト ディメンションはドリルスルー アクションをサポートするために使用されます。アクションの詳細については、「アクション (Analysis Services - 多次元データ)」を参照してください。 |
注意 |
---|
ファクト ディメンションは、ファクト リレーションシップが参照するメジャー グループが更新されるたびに増分更新する必要があります。ファクト ディメンションが ROLAP ディメンションの場合、Analysis Services 処理エンジンがすべてのキャッシュを削除し、メジャー グループの増分処理を行います。 |
ファクト リレーションシップの詳細については、「ファクト リレーションシップとファクト リレーションシップ プロパティの定義」を参照してください。
多対多ディメンションのリレーションシップ
ほとんどのディメンションでは、各ファクトは一意のディメンション メンバと結合していますが、1 つのディメンション メンバは複数のファクトと関連付けることができます。リレーショナル データベース用語では、これを一対多のリレーションシップと呼びます。ただし、多くの場合、1 つのファクトを複数のディメンション メンバと結合すると便利です。たとえば、銀行の顧客は複数の口座 (当座預金口座、普通預金口座、クレジット カードの口座、および投資口座) を持つ場合がありますが、1 つの口座に対し、共同所有者がいたり、複数の所有者がいたりするケースもあります。このようなリレーションシップから作成された顧客ディメンションには、1 回の口座取引に関連付けられるメンバが複数存在します。
SQL ServerAnalysis Services では、ディメンションとファクト テーブル間に多対多リレーションシップを定義できます。
注意 |
---|
上の図に示したように、多対多ディメンションのリレーションシップをサポートするには、データ ソース ビューで、関係するすべてのテーブル間に外部キー リレーションシップを確立する必要があります。このようにしないと、ディメンション デザイナの [ディメンションの使用法] タブでリレーションシップを確立するときに正しい中間メジャー グループを選択できません。 |
多対多リレーションシップの詳細については、「多対多リレーションシップと多対多リレーションシップのプロパティの定義」を参照してください。