SQL Server Analysis Services では、ケース テーブルに含まれる一連のケースとしてデータ マイニング アルゴリズムにデータをフィードする必要があります。 ただし、すべてのケースを 1 行のデータで記述できるわけではありません。 たとえば、ケースは、顧客情報を含む 1 つのテーブルと、顧客購入を含む別のテーブルの 2 つのテーブルから派生する場合があります。 顧客情報テーブル内の 1 人の顧客が、顧客購入テーブルに複数の項目を含む可能性があるため、1 つの行を使用してデータを記述することが困難になります。 Analysis Services には、 入れ子になったテーブルを使用して、このようなケースを処理するための一意のメソッドが用意されています。 入れ子になったテーブルの概念を次の図に示します。
この図では、最初のテーブル (親テーブル) に顧客の情報が含まれており、各顧客に一意の識別子が関連付けられています。 2 番目のテーブル (子テーブル) には、各顧客の購入が含まれています。 子テーブルの購入は、CustomerKey列という一意の識別子によって親テーブルに関連付けられています。 図の 3 番目のテーブルは、2 つのテーブルを組み合わせたものです。
入れ子になったテーブルは、ケース テーブルで、TABLE のデータ型を持つ特殊な列として表されます。 特定のケース行の場合、この種類の列には、親テーブルに関連する子テーブルから選択された行が含まれます。
入れ子になったテーブル内のデータは、予測または入力、またはその両方に使用できます。 たとえば、モデル内に 2 つの入れ子になったテーブル列があるとします。1 つの入れ子になったテーブル列には、顧客が購入した製品の一覧が含まれる場合があります。もう 1 つの入れ子になったテーブル列には、顧客の趣味と関心に関する情報が含まれています。調査から取得した可能性があります。 このシナリオでは、購入行動を分析し、購入の可能性を予測するための入力として、顧客の趣味と関心を使用できます。
ケーステーブルとネストされたテーブルの結合
入れ子になったテーブルを作成するには、2 つのソース テーブルに定義済みのリレーションシップが含まれている必要があります。そのため、1 つのテーブル内の項目を他のテーブルに関連付けることができます。 SQL Server Data Tools (SSDT) では、データ ソース ビューでこのリレーションシップを定義できます。
注
CustomerKey フィールドは、ケース テーブルと入れ子になったテーブルをデータ ソース ビュー定義内でリンクし、マイニング構造内の列のリレーションシップを確立するために使用されるリレーショナル キーです。 ただし、通常は、その構造に基づいて構築されたマイニング モデルでは、このリレーショナル キーを使用しないでください。 通常、テーブルを結合するためだけに機能し、分析に役立つ情報が提供されない場合は、マイニング モデルからリレーショナル キー列を省略することをお勧めします。
入れ子になったテーブルは、データ マイニング拡張機能 (DMX) または分析管理オブジェクト (AMO) を使用してプログラムで作成することも、SQL Server Data Tools (SSDT) のデータ マイニング ウィザードとデータ マイニング デザイナーを使用して作成することもできます。
マイニング モデルでの入れ子になったテーブル列の使用
ケース テーブルでは、キーは多くの場合、顧客 ID、製品名、または系列内の日付です。テーブル内の行を一意に識別するデータです。 . ただし、入れ子になったテーブルでは、通常、キーはリレーショナル キー (または外部キー) ではなく、モデリングする属性を表す列です。
たとえば、ケース テーブルに注文が含まれ、入れ子になったテーブルに順序の項目が含まれている場合は、ケース テーブルに格納されている複数の注文にわたって、入れ子になったテーブルに格納されている項目間のリレーションシップをモデル化することに関心があります。 したがって、アイテムの入れ子になったテーブルはリレーショナル キー OrderID によって Orders ケース テーブルに結合されますが、入れ子になったテーブル キーとして OrderID を使用しないでください。 代わりに、入れ子になったテーブル キーとして Items 列を選択します。その列には、モデル化するデータが含まれているためです。 ケース テーブルと入れ子になったテーブルの間のリレーションシップはデータ ソース ビュー定義によって既に確立されているため、ほとんどの場合、マイニング モデルの OrderID は無視しても問題ありません。
入れ子になったテーブル キーとして使用する列を選択する場合は、その列の値がケースごとに一意であることを確認する必要があります。 たとえば、ケース テーブルが顧客を表し、入れ子になったテーブルが顧客が購入したアイテムを表している場合は、顧客ごとに複数回項目が一覧表示されないようにする必要があります。 顧客が同じアイテムを複数回購入した場合は、一意の各製品の購入数を集計する列を含む別のビューを作成できます。
入れ子になったテーブルの重複する値を処理する方法は、作成するマイニング モデルと、解決するビジネス上の問題によって異なります。 一部のシナリオでは、顧客が特定の製品を購入した回数は気にせず、少なくとも 1 つの購入の有無を確認したい場合があります。 その他のシナリオでは、購入の数量と順序が非常に重要な場合があります。
項目の順序が重要な場合は、シーケンスを示す追加の列が必要になる場合があります。 シーケンス クラスタリング アルゴリズムを使用してモデルを作成する場合は、項目の順序を表す追加の キー シーケンス 列を選択する必要があります。 キー シーケンス列は、シーケンス クラスタリング モデルでのみ使用される特殊な種類の入れ子になったキーであり、一意の数値データ型が必要です。 たとえば、整数と日付の両方をキー シーケンス列として使用できますが、すべてのシーケンス値は一意である必要があります。 キー シーケンス列に加えて、シーケンス クラスタリング モデルには、購入された製品など、モデル化されている属性を表す入れ子になったテーブル キーもあります。
入れ子テーブルから非キー入れ子列の使用
ケース テーブルと入れ子になったテーブルの間の結合を定義し、入れ子になったテーブル キーとして使用する興味深い属性と一意の属性を含む列を選択したら、入れ子になったテーブルの他の列をモデルへの入力として含めることができます。 入れ子になったテーブルのすべての列は、入力と予測に使用するか、予測のみに使用できます。
たとえば、入れ子になったテーブルに Product、 ProductQuantity、 ProductPrice の列が含まれている場合は、入れ子になったテーブル キーとして Product を選択し、入力として使用するマイニング構造に ProductQuantity を追加できます。
入れ子になったテーブル データのフィルター処理
SQL Server 2014 では、データ マイニング モデルのトレーニングまたはテストに使用されるデータに対してフィルターを作成できます。 ファイラーは、モデルの構成に影響を与えたり、ケースのサブセットでモデルをテストしたりするために使用できます。 フィルターは、入れ子になったテーブルにも適用できます。 ただし、入れ子になったテーブルで使用できる構文には制限があります。
入れ子になったテーブルにフィルターを適用する場合、多くの場合、属性の存在または非存在をテストしています。 たとえば、モデルで使用されるケースを、入れ子になったテーブルで指定された値を持つケースのみに制限するフィルターを適用できます。 または、モデルで使用されるケースを、特定のアイテムを購入していない顧客に制限することもできます。
入れ子になったテーブルにフィルターを作成する場合は、より大きいか小さいかなどの演算子を使用することもできます。 たとえば、モデルで使用されるケースを、ターゲット製品の n ユニット以上を購入した顧客に制限できます。 入れ子になったテーブル属性に対してフィルター処理を行う機能により、モデルをカスタマイズするための柔軟性が大幅に向上します。
モデル フィルターを作成して使用する方法の詳細については、「 マイニング モデルのフィルター (Analysis Services - データ マイニング)」を参照してください。
こちらもご覧ください
データ マイニング アルゴリズム (Analysis Services - データ マイニング)
マイニング構造 (Analysis Services - データ マイニング)