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