ディメンションの使用法は、キューブ ディメンションとキューブ内のメジャー グループの間のリレーションシップを定義します。 キューブ ディメンションは、特定のキューブで使用されるデータベース ディメンションのインスタンスです。 キューブには、メジャー グループに直接関連付けられているのではなく、別のディメンションまたはメジャー グループを介してメジャー グループに間接的に関連している可能性があるキューブ ディメンションを含めることができます。また、多くの場合、キューブディメンションを持つことができます。 データベース ディメンションまたはメジャー グループをキューブに追加すると、Microsoft SQL Server Analysis Services は、キューブのデータ ソース ビュー内のディメンション テーブルとファクト テーブル間のリレーションシップを調べ、ディメンション内の属性間のリレーションシップを調べることによって、ディメンションの使用状況を判断しようとします。 Analysis Services は、検出可能なリレーションシップのディメンション使用法の設定を自動的に設定します。
ディメンションとメジャー グループの間のリレーションシップは、リレーションシップに参加しているディメンション テーブルとファクト テーブルと、特定のメジャー グループ内のディメンションの粒度を指定する粒度属性で構成されます。
標準ディメンション リレーションシップ
キューブ ディメンションとメジャー グループの間の標準ディメンション リレーションシップは、ディメンションのキー列がファクト テーブルに直接結合されるときに存在します。 この直接リレーションシップは、基になるリレーショナル データベースの主キーと外部キーのリレーションシップに基づいていますが、データ ソース ビューで定義されている論理リレーションシップに基づいている場合もあります。 標準ディメンション リレーションシップは、従来のスター スキーマ設計におけるディメンション テーブルとファクト テーブルの間のリレーションシップを表します。 通常のリレーションシップの詳細については、「 通常のリレーションシップと通常のリレーションシップのプロパティを定義する」を参照してください。
参照ディメンションのリレーションシップ
キューブ ディメンションとメジャー グループの間の参照ディメンション リレーションシップは、次の図に示すように、ディメンションのキー列が別のディメンション テーブルのキーを介してファクト テーブルに間接的に結合されるときに存在します。
参照ディメンション リレーションシップは、スノーフレーク スキーマ デザインのディメンション テーブルとファクト テーブルの間のリレーションシップを表します。 スノーフレーク スキーマでディメンション テーブルが接続されている場合は、複数のテーブルの列を使用して 1 つのディメンションを定義することも、個別のディメンション テーブルに基づいて個別のディメンションを定義し、参照ディメンション リレーションシップ設定を使用してそれらの間のリンクを定義することもできます。 次の図は、 InternetSales という名前の 1 つのファクト テーブルと、 Customer と Geography という名前の 2 つのディメンション テーブルをスノーフレーク スキーマで示しています。
Customer テーブルをディメンション メイン テーブルとして、Geography テーブルを関連テーブルとして含むディメンションを作成できます。 その後、ディメンションと InternetSales メジャー グループの間に通常のリレーションシップが定義されます。
または、InternetSales メジャー グループに関連する 2 つのディメンション ( Customer テーブルに基づくディメンションと Geography テーブルに基づくディメンション) を作成することもできます。 その後、Customer ディメンションを使用して、参照ディメンションリレーションシップを使用して、Geography ディメンションを InternetSales メジャー グループに関連付けることができます。 この場合、InternetSales メジャー グループのファクトが Geography ディメンションによってディメンション化される場合、ファクトは顧客と地理によってディメンション化されます。 キューブに Reseller Sales という名前の 2 つ目のメジャー グループが含まれている場合、Reseller Sales と Geography の間にリレーションシップが存在しないため、Geography 別の Reseller Sales メジャー グループのファクトをディメンション化することはできません。
次の図に示すように、連結できる参照ディメンションの数に制限はありません。
参照されるリレーションシップの詳細については、「 参照されるリレーションシップの定義」および「参照されるリレーションシップのプロパティ」を参照してください。
ファクト ディメンションのリレーションシップ
ファクト ディメンションは、多くの場合、縮退ディメンションと呼ばれ、ディメンション テーブルの属性列ではなく、ファクト テーブルの属性列から構築される標準ディメンションです。 便利なディメンション データは、重複を減らすためにファクト テーブルに格納される場合があります。 たとえば、次の図は、Adventure Works DW 多次元 2012 サンプル データベースの FactResellerSales ファクト テーブルを示しています。
テーブルには、リセラーによって発行された注文の各行に関する属性情報だけでなく、注文自体に関する属性情報も含まれています。 前の図で囲まれている属性は、ディメンションの属性として使用できる FactResellerSales テーブル内の情報を識別します。 この場合、運送業者追跡番号とリセラーによって発行された発注書番号という 2 つの追加情報が、CarrierTrackingNumber 属性列と CustomerPONumber 属性列によって表されます。 たとえば、この情報は興味深い情報です。たとえば、ユーザーは、1 つの追跡番号で出荷されるすべての注文の集計情報 (製品の合計コストなど) を表示することに関心があります。 ただし、これら 2 つの属性のディメンション データがないと、整理または集計できません。
理論上、FactResellerSales テーブルと同じキー情報を使用するディメンション テーブルを作成し、他の 2 つの属性列 CarrierTrackingNumber と CustomerPONumber をそのディメンション テーブルに移動できます。 ただし、データのかなりの部分を複製し、データ ウェアハウスに不要な複雑さを追加して、2 つの属性のみを個別のディメンションとして表します。
注
ファクト ディメンションは、ドリルスルー アクションをサポートするために頻繁に使用されます。 アクションの詳細については、「 アクション (Analysis Services - 多次元データ)」を参照してください。
注
ファクト ディメンションは、ファクト リレーションシップによって参照されるメジャー グループに対する更新のたびに増分更新する必要があります。 ファクト ディメンションが ROLAP ディメンションの場合、Analysis Services 処理エンジンはキャッシュを削除し、メジャー グループを増分処理します。
ファクトリレーションシップの詳細については、「 ファクトリレーションシップとファクトリレーションシッププロパティの定義」を参照してください。
多対多ディメンションのリレーションシップ
ほとんどのディメンションでは、各ファクトが 1 つのディメンション メンバーにのみ結合され、1 つのディメンション メンバーを複数のファクトに関連付けることができます。 リレーショナル データベースの用語では、これは一対多リレーションシップと呼ばれます。 ただし、多くの場合、1 つのファクトを複数のディメンション メンバーに結合すると便利です。 たとえば、銀行のお客様が複数のアカウント (確認、保存、クレジット カード、投資口座) を持ち、1 つのアカウントに共同所有者または複数の所有者を持つことができます。 このようなリレーションシップから構築された Customer ディメンションには、1 つのアカウント トランザクションに関連する複数のメンバーが含まれます。
SQL Server Analysis Services を使用すると、ディメンションとファクト テーブルの間に多対多リレーションシップを定義できます。
注
多対多ディメンション リレーションシップをサポートするには、データ ソース ビューで、前の図に示すように、関連するすべてのテーブル間に外部キー リレーションシップが確立されている必要があります。 そうしないと、ディメンション デザイナーの [ ディメンション使用法 ] タブでリレーションシップを確立するときに、適切な中間メジャー グループを選択できなくなります。
多対多リレーションシップの詳細については、「 多対多リレーションシップの定義」および「多対多リレーションシップのプロパティ」を参照してください。