適用対象:
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 の下位互換性」を参照してください。
このセクションでは、モデル フィルターの構文とサンプル式について詳しく説明します。
入れ子になったテーブル属性と EXISTS に対するフィルター
フィルター構文
通常、フィルター式は WHERE 句の内容と同じです。 論理演算子 AND、OR、NOT を使用して複数の条件を接続できます。
入れ子になったテーブルでは、 EXISTS 演算子と NOT EXISTS 演算子を使用することもできます。 サブクエリが少なくとも 1 つの行を返す場合、 EXISTS 条件は true に 評価されます。 これは、入れ子になったテーブル内の特定の値を含むケース (少なくとも 1 回はアイテムを購入した顧客など) にモデルを制限する場合に便利です。
サブクエリで指定された条件が存在しない場合、 NOT EXISTS 条件は true に評価されます。 たとえば、特定のアイテムを購入したことがない顧客にモデルを制限する場合があります。
一般的な構文は次のとおりです。
<filter>::=<predicate list> | ( <predicate list> )
<predicate list>::= <predicate> | [<logical_operator> <predicate list>]
<logical_operator::= AND| OR
<predicate>::= NOT <predicate>|( <predicate> ) <avPredicate> | <nestedTablePredicate> | ( <predicate> )
<avPredicate>::= <columnName> <operator> <scalar> | <columnName> IS [NOT] NULL
<operator>::= = | != | <> | > | >= | < | <=
<nestedTablePredicate>::= EXISTS (<subquery>)
<subquery>::=SELECT * FROM <columnName>[ WHERE <predicate list> ]
フィルター
論理演算子によって接続された 1 つ以上の述語が含まれています。
述語リスト
論理演算子で区切られた 1 つ以上の有効なフィルター式。
Columnname
マイニング構造列の名前。
論理演算子
AND、 OR、 NOT
avPredicate
スカラー マイニング構造列にのみ適用できるフィルター式。
avPredicate 式は、モデル フィルターまたは入れ子になったテーブル フィルターの両方で使用できます。
次のいずれかの演算子を使用する式は、連続列にのみ適用できます。 :
< (より小さい)
> (より大きい)
>= (以上)
<= (以下)
注
データ型に関係なく、 不連続型、 分離型、または キー型を持つ列にこれらの演算子を適用することはできません。
次のいずれかの演算子を使用する式は、連続、不連続、分離、またはキー列に適用できます。
= (等しい)
!= (等しくない)
IS NULL
引数 avPredicate が分離された列に適用される場合、フィルターで使用される値は、特定のバケット内の任意の値にすることができます。
つまり、条件を AgeDisc = '25-35'として定義するのではなく、その間隔の値を計算して使用します。
例: AgeDisc = 27 は、27 と同じ間隔の任意の値 (この場合は 25 から 35) を意味します。
nestedTablePredicate
入れ子になったテーブルに適用されるフィルター式。 モデル フィルターでのみ使用できます。
引数 nestedTablePredicate のサブクエリ引数は、テーブル マイニング構造列にのみ適用できます
サブクエリ
SELECT ステートメントの後に有効な述語または述語の一覧が続きます。
すべての述語は 、avPredicates で説明されている型である必要があります。 さらに、述語は、現在の入れ子になったテーブルに含まれている列のみを参照できます。これは、引数 columnName によって識別されます。
フィルター構文に関する制限事項
フィルターには次の制限が適用されます。
フィルターには単純な述語のみを含めることができます。 これには、算術演算子、スカラー、列名が含まれます。
ユーザー定義関数は、フィルター構文ではサポートされていません。
プラス記号やマイナス記号などの非ブール演算子は、フィルター構文ではサポートされていません。
フィルターの例
次の例は、マイニング モデルに適用されるフィルターの使用を示しています。 SQL Server データ ツールを使用してフィルター式を作成すると、フィルター ダイアログ ボックスの [プロパティ ] ウィンドウと [式 ] ウィンドウに、WITH FILTER キーワードの後に表示される文字列のみが表示されます。 ここでは、列の種類と使用法を理解しやすくするために、マイニング構造の定義が含まれています。
例 1: 一般的な Case-Level フィルター処理
この例では、モデルで使用されるケースを、職業がアーキテクトであり、年齢が 30 歳を超える顧客に制限する単純なフィルターを示しています。
ALTER MINING STRUCTURE MyStructure ADD MINING MODEL MyModel_1
(
CustomerId,
Age,
Occupation,
MaritalStatus PREDICT
)
WITH FILTER (Age > 30 AND Occupation='Architect')
例 2: 入れ子テーブル属性を使用したケースレベルフィルタリング
マイニング構造に入れ子になったテーブルが含まれている場合は、入れ子になったテーブル内の値の存在をフィルター処理するか、特定の値を含む入れ子になったテーブル行をフィルター処理できます。 この例では、牛乳を含む購入を少なくとも 1 回行った 30 歳以上のお客様に、モデルに使用されるケースを制限します。
この例に示すように、モデルに含まれる列のみをフィルターで使用する必要はありません。 入れ子になったテーブル Products はマイニング構造の一部ですが、マイニング モデルには含まれません。 ただし、入れ子になったテーブルの値と属性をフィルター処理することはできます。 これらのケースの詳細を表示するには、ドリルスルーを有効にする必要があります。
ALTER MINING STRUCTURE MyStructure ADD MINING MODEL MyModel_2
(
CustomerId,
Age,
Occupation,
MaritalStatus PREDICT
)
WITH DRILLTHROUGH,
FILTER (Age > 30 AND EXISTS (SELECT * FROM Products WHERE ProductName='Milk')
)
例 3: 複数の入れ子になったテーブル属性のケースレベルでのフィルタリング
この例では、ケース テーブルに条件が適用され、入れ子になったテーブル内の属性に別の条件が適用され、入れ子になったテーブル列の特定の値に対して別の条件が適用されます。
フィルターの最初の条件 ( Age > 30) は、ケース テーブルの列に適用されます。 残りの条件は、入れ子になったテーブルに適用されます。
2 番目の条件 EXISTS (SELECT * FROM Products WHERE ProductName='Milk' は、入れ子になったテーブル内でミルクを含む少なくとも 1 つの購入が存在することを確認します。 3 番目の条件 Quantity>=2は、顧客が 1 回のトランザクションで少なくとも 2 ユニットの牛乳を購入している必要があることを意味します。
ALTER MINING STRUCTURE MyStructure ADD MINING MODEL MyModel_3
(
CustomerId,
Age,
Occupation,
MaritalStatus PREDICT,
Products PREDICT
(
ProductName KEY,
Quantity
)
)
FILTER (Age > 30 AND EXISTS (SELECT * FROM Products WHERE ProductName='Milk' AND Quantity >= 2)
)
例 4: 入れ子になったテーブル属性がない場合のケースレベルのフィルター処理
この例では、入れ子になったテーブルに属性がないかどうかをフィルター処理して、特定のアイテムを購入しなかった顧客にケースを制限する方法を示します。 この例では、牛乳を購入したことがない 30 歳以上の顧客を使用してモデルをトレーニングします。
ALTER MINING STRUCTURE MyStructure ADD MINING MODEL MyModel_4
(
CustomerId,
Age,
Occupation,
MaritalStatus PREDICT,
Products PREDICT
(
ProductName
)
)
FILTER (Age > 30 AND NOT EXISTS (SELECT * FROM Products WHERE ProductName='Milk') )
例 5: 複数の入れ子になったテーブル値に対するフィルター処理
この例の目的は、入れ子になったテーブルのフィルター処理を示しています。 入れ子になったテーブル フィルターはケース フィルターの後に適用され、入れ子になったテーブル行のみが制限されます。
EXISTS が指定されていないため、このモデルには、入れ子になったテーブルが空の複数のケースが含まれる可能性があります。
ALTER MINING STRUCTURE MyStructure ADD MINING MODEL MyModel_5
(
CustomerId,
Age,
Occupation,
MaritalStatus PREDICT,
Products PREDICT
(
ProductName KEY,
Quantity
) WITH FILTER(ProductName='Milk' OR ProductName='bottled water')
)
WITH DRILLTHROUGH
例 6: 入れ子になったテーブル属性と EXISTS に対するフィルター処理
この例では、入れ子になったテーブルのフィルターによって、行が牛乳またはボトル入り飲料水を含むものに制限されます。 その後、モデル内のケースは EXISTS ステートメントを使用して制限されます。 これにより、入れ子になったテーブルが空でないことを確認できます。
ALTER MINING STRUCTURE MyStructure ADD MINING MODEL MyModel_6
(
CustomerId,
Age,
Occupation,
MaritalStatus PREDICT,
Products PREDICT
(
ProductName KEY,
Quantity
) WITH FILTER(ProductName='Milk' OR ProductName='bottled water')
)
FILTER (EXISTS (Products))
例 7: 複雑なフィルターの組み合わせ
このモデルのシナリオは例 4 と似ていますが、はるかに複雑です。 入れ子になったテーブル ProductsOnSale には、フィルター条件(OnSale)、ProductName に記載されている製品に対して OnSale の値が true である必要があることを意味します。 ここでは、 OnSale は構造体列です。
ProductsNotOnSale のフィルターの 2 番目の部分では、この構文が繰り返されますが、OnSale の値が true ではない製品にフィルター処理します(!OnSale)。
最後に、条件が組み合わされ、ケース テーブルに 1 つの追加の制限が追加されます。 その結果、25 歳以上のすべての顧客について、 ProductsOnSale リストに含まれるケースに基づいて ProductsNotOnSale リスト内の製品の購入を予測します。
ALTER MINING STRUCTURE MyStructure ADD MINING MODEL MyModel_7
(
CustomerId,
Age,
Occupation,
MaritalStatus,
ProductsOnSale
(
ProductName KEY
) WITH FILTER(OnSale),
ProductsNotOnSale PREDICT ONLY
(
ProductName KEY
) WITH FILTER(!OnSale)
)
WITH DRILLTHROUGH,
FILTER (EXISTS (ProductsOnSale) AND EXISTS(ProductsNotOnSale) AND Age > 25)
例 8: 日付のフィルター処理
他のデータと同様に、日付に基づいて入力列をフィルター処理できます。 日付/時刻型の列に含まれる日付は連続値です。したがって、より大きい (>) や小さい (<) などの演算子を使用して日付範囲を指定できます。 データ ソースが連続データ型ではなく、不連続値またはテキスト値として日付を表す場合は、日付範囲でフィルター処理することはできませんが、個別の個別の値を指定する必要があります。
ただし、フィルターに使用される日付列がモデルのキー列でもある場合、時系列モデルの日付列にフィルターを作成することはできません。 これは、時系列モデルとシーケンス クラスタリング モデルでは、日付列が KeyTime 型または KeySequence 型として処理される可能性があるためです。
時系列モデルで連続する日付をフィルター処理する必要がある場合は、マイニング構造に列のコピーを作成し、新しい列でモデルをフィルター処理できます。
たとえば、次の式は、予測モデルに追加された Continuous 型の日付列のフィルターを表します。
=[DateCopy] > '12:31:2003:00:00:00'
注
モデルに追加する追加の列が結果に影響を与える可能性があることに注意してください。 したがって、系列の計算で列を使用しない場合は、モデルではなくマイニング構造にのみ列を追加する必要があります。 列のモデル フラグを PredictOnly または Ignore に設定することもできます。 詳細については、「 モデリング フラグ (データ マイニング)」を参照してください。
他のモデルの種類の場合は、他の列と同様に、入力条件またはフィルター条件として日付を使用できます。 ただし、 Continuous データ型でサポートされていない特定のレベルの細分性を使用する必要がある場合は、式を使用してフィルター処理と分析に使用する単位を抽出することで、データ ソースに派生値を作成できます。
Warnung
フィルター条件として日付を指定する場合は、現在の OS の日付形式に関係なく、次の形式を使用する必要があります: mm/dd/yyyy。 その他の形式の場合、エラーになります。
たとえば、コール センターの結果をフィルター処理して週末のみを表示する場合は、データ ソース ビューで各日付の曜日名を抽出する式を作成し、その曜日名の値を入力に使用するか、フィルター処理で個別の値として使用できます。 繰り返し値がモデルに影響を与える可能性があるので、日付列と派生値ではなく、列の 1 つだけを使用する必要があります。
こちらもご覧ください
マイニング モデルのフィルター (Analysis Services - データ マイニング)
テストと検証 (データ マイニング)