ディメンション リレーションシップ

適用対象: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

ディメンションを使用する場合は、キューブ内にある、キューブ ディメンションとメジャー グループ間のリレーションシップが定義されます。 キューブ ディメンションとは、特定のキューブで使用されるデータベース ディメンションのインスタンスです。 キューブにはキューブ ディメンションを含めることができ、実際、多くの場合は含んでいます。キューブ ディメンションはメジャー グループと直接には関連付けられていませんが、別のディメンションまたは別のメジャー グループを介して間接的にメジャー グループと関連付けられることがあります。 データベース ディメンションまたはメジャー グループをキューブに追加すると、Microsoft SQL Server SQL Server Analysis Servicesは、キューブのデータ ソース ビュー内のディメンション テーブルとファクト テーブル間のリレーションシップを調べ、ディメンション内の属性間のリレーションシップを調べることによって、ディメンションの使用状況を判断しようとします。 SQL Server 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 テーブルと同じキー情報を使用するディメンション テーブルを 1 つ作成し、残りの 2 つの属性列である CarrierTrackingNumber と CustomerPONumber をそのディメンション テーブルに移動できます。 ただし、わずか 2 つの属性を別のディメンションとして表すために、非常に多くの重複データを設定し、データ ウェアハウスを不必要に複雑にすることになります。

ファクト リレーションシップの詳細については、「 ファクト リレーションシップの定義」および「ファクト リレーションシップのプロパティ」を参照してください。

多対多ディメンションのリレーションシップ

ほとんどのディメンションでは、各ファクトは一意のディメンション メンバーと結合していますが、1 つのディメンション メンバーは複数のファクトと関連付けることができます。 リレーショナル データベース用語では、これを一対多のリレーションシップと呼びます。 ただし、多くの場合、1 つのファクトを複数のディメンション メンバーと結合すると便利です。 たとえば、銀行の顧客は複数の口座 (当座預金口座、普通預金口座、クレジット カードの口座、および投資口座) を持つ場合がありますが、1 つの口座に対し、共同所有者がいたり、複数の所有者がいたりするケースもあります。 このようなリレーションシップから作成された顧客ディメンションには、1 回の口座取引に関連付けられるメンバーが複数存在します。

SQL Server SQL Server Analysis Servicesでは、ディメンションとファクト テーブルの間に多対多リレーションシップを定義できます。

多対多リレーションシップの詳細については、「 多対多リレーションシップの定義」および「多対多リレーションシップのプロパティ」を参照してください。

参照

ディメンション (Analysis Services - 多次元データ)