不足値 (Analysis Services - データ マイニング)
不足値は、データ内でさまざまな意味を持ちます。たとえば、フィールドが該当しなかった、イベントが発生しなかった、データを使用できなかった、データを入力した人に適切な値がわからなかった、フィールドが入力されていなくても気にしなかった、などが考えられます。このため、Analysis Services には、こうした不足値 (NULL 値とも呼ばれます) の管理および計算のために 2 つの明確に異なるメカニズムが用意されています。
列に不足値があってはいけないタスクをモデル化している場合は、マイニング構造を定義するときに NOT_NULL モデリング フラグを使用します。これにより、ケースに適切な値がない場合には処理が失敗するようになります。モデルの処理中にエラーが発生した場合は、そのエラーをログに記録して、モデルに入力されたデータを修正することができます。適切な値を推定して入力するためには、SQL Server Integration Services の参照変換または Data Profiler タスクや、Excel 用データ マイニング アドインの Fill By Example ツールなど、さまざまなツールを使用できます。
一方、不足値が重要な情報を提供するデータ マイニング シナリオも数多くあります。通常、Analysis Services では不足値が有益なデータとして扱われ、不足値を計算に含めるために確率が調整されます。これにより、既存のケースに偏ったモデルにならないようにすることができます。ここでは、NULL 値を許可するモデルで値が Missing として定義およびカウントされるしくみと、それらの Missing 値がモデルの作成時にデータ マイニング アルゴリズムによって処理および使用される方法について説明します。
.gif "注意") 注 |
|---|
Missing 値の処理方法は、アルゴリズム (サード パーティ プラグインから入手したカスタム アルゴリズムを含む) ごとに異なる可能性があります。 |
モデルでの不足値の使用
データ マイニング アルゴリズムにとって不足値は有益なデータであり、ケース テーブルにおいて Missing は他の状態と同様の有効な状態です。さらに、データ マイニング モデルでは他の値を使用して値が不足するかどうかを予測できます。要するに、値が不足していてもエラーとして扱われることはありません。
データ マイニング モデルを作成すると、すべての不連続列についてモデルに Missing 状態が自動的に追加されます。たとえば、Gender の入力列に Male と Female の 2 つの可能な値が含まれている場合、Missing 値を表すために 3 つ目の値が自動的に追加されます。また、その列のすべての値の分布を示すヒストグラムには、Missing 値を持つケースの数が常に含まれます。Gender 列に値の不足がない場合は、Missing 状態が見つかったケースの数が 0 としてヒストグラムに示されます。
既定で Missing 状態が含まれると、データに可能な値の例がすべては含まれていないと考えられる場合に、データに例が含まれていないというだけの理由でその可能性がモデルで排除されないようにすることができます。たとえば、店舗の売上データで、特定の製品を購入した顧客がたまたますべて女性だったからと言って、その製品は女性しか購入しないと予測するモデルが作成されるようでは問題があります。これに対して Analysis Services では、可能なその他の状態を考慮に入れるための手段として、Missing という追加の不明な値のためのプレースホルダが追加されます。
たとえば次の表は、Bike Buyer チュートリアルのために作成されたデシジョン ツリー モデルの (すべて) ノードの値の分布を示しています。この例のシナリオでは、[Bike Buyer] 列は予測可能な属性です。1 は "Yes" を表し、0 は "No" を表します。
値 |
ケース |
|---|---|
0 |
9296 |
1 |
9098 |
Missing |
0 |
この分布からは、自転車を購入した顧客と購入しなかった顧客の数がほぼ半々であることがわかります。このデータセットは完璧であるため、すべてのケースが [Bike Buyer] 列の値を持ち、Missing 値の数は 0 になっています。しかし、[Bike Buyer] フィールドに NULL のケースがあった場合には、その行が Missing 値を持つケースとしてカウントされます。
入力が連続列の場合には、この属性に対して Existing と Missing の 2 つの可能な状態が適用されます。つまり、その列に何らかの数値データ型の値が含まれているか、値が何も含まれていないかのいずれかになります。値があるケースの場合は、平均、標準偏差、およびその他の意味のある統計がモデルで計算されます。値がないケースの場合は、Missing 値の数がカウントされ、それに基づいて予測が調整されます。予測を調整する方法はアルゴリズムによって異なります。詳細については次のセクションを参照してください。
| 注 |
|---|
入れ子になったテーブルの属性では、不足値は有益なデータにはなりません。たとえば、顧客が製品を購入していない場合は、入れ子になった Products テーブルにその製品に対応する行は含まれず、マイニング モデルでその不足している製品の属性は作成されません。ただし、特定の製品を購入していない顧客に関心がある場合は、モデル フィルタで NOT EXISTS ステートメントを使用することにより、入れ子になったテーブルにその製品が存在しないという属性に基づいてフィルタ処理されるモデルを作成できます。詳細については、「マイニング モデルにフィルターを適用する方法」を参照してください。 |
不足値のための確率の調整
Analysis Services では、値がカウントされるだけでなく、データセット全体での値の確率も計算されます。これは、Missing 値にも当てはまります。たとえば次の表は、前の例のケースの確率を示しています。
値 |
ケース |
確率 |
|---|---|---|
0 |
9296 |
50.55% |
1 |
9098 |
49.42% |
Missing |
0 |
0.03% |
Missing 値の確率が、ケースの数が 0 なのに 0.03% として計算されているのは奇妙に見えるかもしれません。実のところ、この動作は意図的なものであり、モデルで不明な値を適切に処理できるようにするための調整を表しています。
一般に確率は、好ましいケースをすべての可能なケースで割ることによって計算されます。この例の場合は、特定の条件 ([Bike Buyer] = 1 または [Bike Buyer] = 0) を満たすケースの合計を計算し、その数を行の合計数で割ります。ただしここでは、Missing のケースを計算に入れるために、すべての可能なケースの数に 1 が追加されます。その結果、不明なケースの確率は、0 ではなくごく小さな値になります。これにより、その状態がありそうにないだけで、あり得なくはないことが示されます。
小さな Missing 値が追加されても予測子の結果は変わりませんが、過去のデータにすべての考えられる結果が含まれてはいないシナリオで、モデリングを改善することが可能になります。
| 注 |
|---|
不足値を処理する方法はデータ マイニング プロバイダによって異なります。たとえば、入れ子になった列の不足しているデータはスパース表現だが、入れ子になっていない列ではそのデータが不規則に不足していると想定するプロバイダもあります。 |
データですべての結果が指定されていることがわかっている場合に、確率が調整されないようにするには、マイニング構造の列で NOT_NULL モデリング フラグを設定します。
デシジョン ツリー モデルにおける不足値の特別な処理
Microsoft デシジョン ツリー アルゴリズムによる不足値の確率の計算方法は、他のアルゴリズムと異なります。デシジョン ツリー アルゴリズムでは、ケースの合計数に単純に 1 を追加する代わりに、若干異なる式を使用して Missing 状態のための調整を行います。
Missing 状態の確率は、デシジョン ツリー モデルでは次のように計算されます。
StateProbability = (NodePriorProbability)* (StateSupport + 1) / (NodeSupport + TotalStates)
さらに、SQL Server 2008 Analysis Services のデシジョン ツリー アルゴリズムでは、モデルのフィルタの存在を補正するための追加の調整が行われます (フィルタが存在すると、トレーニングの間に多くの状態が除外される可能性があります)。
SQL Server 2008 では、状態がトレーニング中に存在したが、たまたま特定のノードのサポートが 0 だったという場合には、標準の調整が行われます。一方、トレーニング中に状態が一度も検出されなかった場合には、その確率が厳密に 0 に設定されます。この調整は、Missing 状態だけでなく、トレーニング データに存在するがモデル フィルタの結果としてサポートが 0 になる状態にも適用されます。
この追加の調整の結果となる式を次に示します。
StateProbability = 0.0 トレーニング セットでその状態のサポートが 0 の場合
ELSE StateProbability = (NodePriorProbability)* (StateSupport + 1) / (NodeSupport + TotalStatesWithNonZeroSupport)
この調整の最終的な効果として、ツリーの安定性が維持されます。