適用対象:
SQL Server 2019 以前の Analysis Services
Azure Analysis Services
Fabric/Power BI Premium
Important
データ マイニングは SQL Server 2017 Analysis Services で非推奨となり、現在は SQL Server 2022 Analysis Services で廃止されました。 非推奨および廃止された機能については、ドキュメントは更新されません。 詳細については、「 Analysis Services の下位互換性」を参照してください。
欠損値を正しく処理することは、効果的なモデリングに重要です。 このセクションでは、欠損値について説明し、データ マイニング構造とモデルを構築するときにSQL Server Analysis Services機能を使用してそれらを処理する方法について説明します。
データ マイニングでの欠損値の定義
欠損値は、さまざまなことを意味する可能性があります。 フィールドが適用されなかったか、イベントが発生しなかったか、データが使用できなかった可能性があります。 データを入力したユーザーが正しい値を知らなかったり、フィールドに入力されていない場合は気にしなかったりする可能性があります。
欠損値は、多くのデータ マイニング シナリオで重要な情報を提供します。 欠損値の意味は、コンテキストによって大きく異なります。 たとえば、請求書の一覧の日付の欠損値は、従業員の雇用日を示す列に日付がない場合とは大きく異なる意味を持ちます。 一般に、SQL Server Analysis Services は欠損値を情報として扱い、欠損値を計算に組み込むように確率を調整します。 そうすることで、モデルのバランスが取れ、既存のケースの重み付けをあまり大きくしないようにすることができます。
SQL Server Analysis Servicesには、欠損値を処理するための 2 つのメカニズムが用意されています。 最初のメソッドは、マイニング構造での null 処理を制御します。 各アルゴリズムは、NULL 値を許可するモデルで欠損値を処理およびカウントするために、2 番目のメソッドを異なる方法で実装します。
null の処理の指定
データ ソースは、欠損値を null、空のスプレッドシート セル、 N/A または別のコード、または 9999 のような人為的な値として表している可能性があります。 ただし、データ マイニングの目的上、null 値のみが欠損値と見なされます。 データに null ではなくプレースホルダー値が含まれている場合は、モデルの結果に影響を与える可能性があるため、NULL に置き換えるか、可能であれば正しい値を推論する必要があります。 SQL Server Integration Services の参照変換やデータ プロファイラー タスク、Excel のデータ マイニング Add-Ins で提供される Fill By Example ツールなど、適切な値を推測して入力するために使用できるさまざまなツールがあります。
モデリングするタスクで列の欠損値が許可されない場合は、マイニング構造を定義するときに NOT_NULL モデリング フラグを適用します。 このフラグは、ケースに適切な値がない場合に処理が失敗することを示します。 モデルの処理中にこのエラーが発生した場合は、エラーをログに記録し、モデルに提供されたデータを修正する手順を実行できます。
欠落状態の計算
データ マイニング アルゴリズムは、欠損値を情報として扱います。 テーブルの場合、 Missing は有効な状態です。 データ マイニング モデルでは、他の値を使用して値が欠落しているかどうかを予測できるため、欠損値はエラーになりません。
マイニング モデルを作成すると、すべての不連続列の 不足 状態がモデルに自動的に追加されます。 たとえば、入力列 [Gender] に男性と女性の値が含まれている場合、モデルは 3 番目の値 Missing を追加します。 列のヒストグラムには、 不足 状態のケースの数が含まれます。 Gender 列に値の欠損がない場合、ヒストグラムは欠損状態が 0 件であることを示しています。
既定で Missing 状態を含める理由は、データに使用可能なすべての値の例がない可能性があり、データに例がなかったからといってモデルから除外したくない場合に明確になります。 たとえば、ある店舗の売上データで、特定の製品を購入したすべての顧客が女性であることが示された場合、女性のみが製品を購入できると予測するモデルを作成することは望まれません。 代わりに、SQL Server Analysis Services は、可能な他の状態に対応する方法として、 Missing と呼ばれる余分な不明な値のプレースホルダーを追加します。
たとえば、次の表は、Bike Buyer チュートリアル用に作成されたデシジョン ツリー モデルの (All) ノードの値の分布を示しています。 この例のシナリオでは、[Bike Buyer] 列が予測可能な属性です。1 は "Yes" を示し、0 は "No" を示します。
| 価値 | サポート案件 |
|---|---|
| 0 | 9296 |
| 1 | 9098 |
| 行方 不明 | 0 |
このディストリビューションでは、顧客の約半分が自転車を購入していて、半分は購入していないことを示しています。 このデータセットのすべてのケースには [Bike Buyer] 列の値があるため、 欠損 値の数は 0 です。 ケースに [Bike Buyer] フィールドに null が含まれている場合、SQL Server Analysis Servicesはその行を Missing 値のケースとしてカウントします。
入力が連続列の場合、モデルは属性に対して可能な 2 つの状態 ( Existing と Missing) を表します。 つまり、列には数値データ型の値が含まれているか、何も値が含まれていないかのいずれかです。 値がある場合、モデルは平均値、標準偏差、およびその他の意味のある統計を計算します。 値がない場合、モデルは 不足している 値のカウントを提供し、それに応じて予測を調整します。 予測を調整する方法はアルゴリズムによって異なり、次のセクションで説明します。
注
入れ子になったテーブル内の属性の場合、欠損値は有益ではありません。 たとえば、顧客が製品を購入していない場合、入れ子になった Products テーブルにはその製品の行がなく、マイニング モデルではその製品の属性は作成されません。 特定の製品を購入していない顧客を識別するには、モデル フィルターで NOT EXISTS ステートメントを使用して、入れ子になったテーブルに存在しない製品をフィルター処理します。 詳細については、「 マイニング モデルにフィルターを適用する」を参照してください。
欠損状態の確率の調整
SQL Server Analysis Services では、値のカウントに加えて、データ セット全体の任意の値の確率が計算されます。 同じ計算が 不足 値に適用されます。 たとえば、次の表は、前の例のケースの確率を示しています。
| 価値 | サポート案件 | 確率 |
|---|---|---|
| 0 | 9296 | 50.55% |
| 1 | 9098 | 49.42% |
| 行方 不明 | 0 | 0.03% |
ケースの数が 0 の場合、 Missing 値の確率が 0.03%であるのは奇妙に思えるかもしれません。 この動作は仕様であり、モデルが不明な値を適切に処理できるようにする調整を表します。
一般に、確率は、すべての可能なケースで割った好ましいケースとして計算されます。 この例では、アルゴリズムは特定の条件 ([Bike Buyer] = 1、または [Bike Buyer] = 0) を満たすケースの合計を計算し、その数を行の合計数で除算します。 不足しているケースを考慮するために、アルゴリズムは考えられるすべてのケースの数に 1 を追加します。 その結果、不明なケースの確率は 0 ではなく、非常に小さい数値であり、状態が単なるあり得ない、不可能ではないことを示します。
小さい 欠損 値は予測を変更しませんが、履歴データに考えられるすべての結果が含まれていない場合のモデリングが向上します。
注
データ マイニング プロバイダーでは、欠損値の処理方法が異なります。 たとえば、一部のプロバイダーでは、入れ子になった列の欠落データはスパース表現として扱われ、非ネスト列の欠落データはランダムに欠落していると見なされます。
データがすべての結果を指定する場合は、マイニング構造列にNOT_NULLモデリング フラグを設定して、確率の調整を防ぎます。
注
サード パーティのプラグインからのカスタム アルゴリズムを含む各アルゴリズムは、欠損値を異なる方法で処理できます。
デシジョン ツリー モデルでの欠損値の特別な処理
Microsoftデシジョン ツリー アルゴリズムでは、欠損値の確率が他のアルゴリズムとは異なる方法で計算されます。 アルゴリズムでは、ケース数の合計に 1 つを追加する代わりに、別の数式を使用して Missing 状態を調整します。
デシジョン ツリー モデルでは、次の式を使用して 、Missing 状態の確率を計算します。
StateProbability = (ノード事前確率) * (状態サポート + 1) / (ノードサポート + 総状態数)
デシジョン ツリー アルゴリズムでは、モデル上のフィルターの存在をアルゴリズムが補正するのに役立つ追加の調整が提供されます。これにより、トレーニング中に多くの状態が除外される可能性があります。
SQL Server 2017 では、トレーニング中に状態が存在するが、特定のノードでサポートがゼロの場合、アルゴリズムによって標準調整が行われます。 ただし、トレーニング中に状態が検出されない場合、アルゴリズムは確率を正確に 0 に設定します。 この調整は 、不足 状態だけでなく、トレーニング データに存在するが、モデルのフィルター処理の結果としてサポートがゼロになっている他の状態にも適用されます。
この追加の調整の結果は、次の数式になります。
StateProbability = 0.0 (その状態でトレーニング セットでサポートが 0 の場合)
ELSE StateProbability = (NodePriorProbability)* (StateSupport + 1) / (NodeSupport + TotalStatesWithNonZeroSupport)
この調整の正味の効果は、ツリーの安定性を維持することです。
関連タスク
これらのリソースでは、欠損値を処理する方法について説明します。
| タスク | Links |
|---|---|
| 個々のモデル列にフラグを追加して、モデルが欠損値を処理する方法を制御する | モデリング フラグの表示または変更 (データ マイニング) |
| マイニング モデルのプロパティを設定して、モデルが欠損値を処理する方法を制御する | マイニング モデルのプロパティを変更する |
| DMX でモデリング フラグを指定する | モデリングフラグ (DMX) |
| マイニング構造で欠損値を処理する方法を変更する | マイニング構造のプロパティを変更する |
こちらもご覧ください
マイニング モデル コンテンツ (Analysis Services - データ マイニング)
モデリング フラグ (データ マイニング)