23 データの準備
モデルの作成に使用できる表またはビューを作成する方法について説明します。
23.1 データ要件
データ・マイニングのためにデータがどのように格納され表示されるかについて理解します。
データ・マイニング操作では、1つの表またはビュー内で定義されたデータが必要です。各レコードの情報は別個の行に格納する必要があります。このデータ・レコードは一般的にケースと呼ばれます。各ケースは、必要に応じて一意のケースIDで識別されます。表またはビュー自体は、ケース表と呼ばれます。
マイニングに使用できる表の例として、SHスキーマのCUSTOMERS表があります。各顧客のすべての情報は、1つの行に格納されています。CUST_ID列にケースIDが格納されます。次の例に示されている行は、SH.CUSTOMERSから選択されています。
例23-1 ケース表の例
SQL> select cust_id, cust_gender, cust_year_of_birth,
cust_main_phone_number from sh.customers where cust_id < 11;
CUST_ID CUST_GENDER CUST_YEAR_OF_BIRTH CUST_MAIN_PHONE_NUMBER
------- ----------- ---- ------------- -------------------------
1 M 1946 127-379-8954
2 F 1957 680-327-1419
3 M 1939 115-509-3391
4 M 1934 577-104-2792
5 M 1969 563-667-7731
6 F 1925 682-732-7260
7 F 1986 648-272-6181
8 F 1964 234-693-8728
9 F 1936 697-702-2618
10 F 1947 601-207-4099関連項目
23.1.1 列のデータ型
ケース表の列データの様々なタイプについて理解します。
ケース表の列には、各ケースを説明する属性が含まれます。例23-1で、属性はCUST_GENDER、CUST_YEAR_OF_BIRTHおよびCUST_MAIN_PHONE_NUMBERです。属性は、監視ありモデルの予測子または監視なしモデルの記述子です。ケースIDのCUST_IDは、特別な属性として表示できます(これは予測子または記述子ではありません)。
Oracle Data Miningでは、標準のOracleデータ型と次のコレクション型をサポートしています。
DM_NESTED_CATEGORICALSDM_NESTED_NUMERICALSDM_NESTED_BINARY_DOUBLESDM_NESTED_BINARY_FLOATS
23.1.3 スコアリング要件
データ・マイニング・モデルの多くは、スコアリングと呼ばれるプロセスで別個のデータに適用できます。Oracle Data Miningでは、分類、回帰、異常検出、クラスタリングおよび特徴抽出のスコアリング操作をサポートします。
スコアリング・プロセスでは、スコアリング・データ内の列名と、モデルの作成に使用された列の名前とがマッチングされます。スコアリング・プロセスでは、スコアリング・データ内にすべての列が存在している必要はありません。データ型が一致しない場合、Oracle Data Miningでは型の強制が試行されます。たとえば、PRODUCT_RATINGという列がトレーニング・データ内ではVARCHAR2型であるのに対し、スコアリング・データ内ではNUMBER型である場合、Oracle Data MiningではTO_CHAR()関数が効果的に適用され、スコアリング・データ内の列の型が変換されます。
テスト・データまたはスコアリング・データ内の列には、作成データ内の対応する列と同じ変換を行う必要があります。たとえば、作成データ内のAGE列が数値から値CHILD、ADULTおよびSENIORに変換された場合、スコアリング・データ内のAGE列にも同じ変換を実行して、モデルが適切に評価できるようにする必要があります。
注意:
Oracle Data Miningでは、ユーザーが指定した変換指示をモデルに組み込んで、モデルの適用時は常にその変換指示が再適用されるようにすることが可能です。変換指示がモデルに組み込まれているときは、テスト・データセットまたはスコアリング・データセットに対してその変換指示を指定する必要はありません。
Oracle Data Miningは、自動データ準備(ADP)もサポートしています。ADPを有効にすると、アルゴリズムで必要とされる変換が自動的に実行され、ユーザーが指定した変換とともにモデル内に組み込まれます。
関連項目:
自動および埋込みデータ変換の詳細は、「データの変換」を参照してください
23.2 属性について
属性は、データ・マイニングで使用されるデータの項目です。予測モデルでは、属性は、特定の結果に影響を及ぼす予測子です。記述モデルでは、自然なグループまたは相関を見つけるために分析される情報項目です。たとえば、肩書き、雇用日、給与、年齢、性別などの属性を持つ従業員データの表です。
23.2.1 データ属性とモデル属性
データ属性とは、モデルの作成、テストまたはスコアリングに使用されるデータセットの列のことです。モデル属性とは、モデルによって内部的に使用されるデータ表現のことです。
データ属性とモデル属性が同一である場合もあります。たとえば、値S、M、Lが格納されているSIZEという列が、モデル作成用としてアルゴリズムによって使用される属性です。モデル属性SIZEは、内部的にはその導出元であるデータ属性と同じである可能性が高いと考えられます。
一方、ある製品グループの売上高が格納されているネストした列SALES_PRODは、モデル属性とは一致しません。データ属性はSALES_PRODとなりますが、モデル属性は、対応する売上高と関連付けられた各製品(ネストした列の各行)です。
変換によっても、データ属性とモデル属性の不一致が起こります。たとえば、変換によって2つのデータ属性に計算が適用され、その結果が新しい属性に格納されたとします。この新しい属性は、対応するデータ属性を持たないモデル属性になります。ビニング、正規化および外れ値の処理などの変換では、ケース表のデータ属性とモデルの属性表現の不一致が起こります。
関連項目
関連項目:
23.2.2 ターゲット属性
データ・マイニングにおけるターゲットの意味、および様々なターゲットのデータ型について理解します。
監視ありモデルのターゲットは特別な属性です。トレーニング・データのターゲット列には、モデルのトレーニングに使用される履歴値が格納されます。テスト・データのターゲット列には、予測の比較対象になる履歴データが格納されます。スコアリングでは、ターゲットの予測が生成されます。
ターゲットは、クラスタリング・モデル、特徴抽出モデル、相関モデルおよび異常検出モデルでは使用されません。
ネストした列および非構造化データ(BFILE、CLOB、BLOBなど)の列は、ターゲットとして使用できません。ターゲット属性には単純なデータ型を使用する必要があります。
表23-1 ターゲットのデータ型
| マイニング機能 | ターゲットのデータ型 |
|---|---|
|
|
|
|
|
*_MINING_MODEL_ATTRIBUTESビューを問い合せると、特定のモデルのターゲットを見つけることができます。
23.2.3 量的、質的および非構造化テキスト
量的、質的および非構造化テキスト属性について説明します。
モデル属性は、量的、質的または非構造化(テキスト)です。データ属性(ケース表の列)は、Oracleデータ型を持ちます(「列のデータ型」を参照)。
量的属性は、論理上は無限の数の値を持つことができます。これらの値には暗黙的な順序があり、値間の差も順序付けられます。Oracle Data Miningでは、NUMBER、FLOAT、BINARY_DOUBLE、BINARY_FLOAT、DM_NESTED_NUMERICALS、DM_NESTED_BINARY_DOUBLESおよびDM_NESTED_BINARY_FLOATSを量的として解釈します。
質的属性は、有限数の離散的カテゴリまたはクラスを特定する値を持ちます。値には、暗黙的な順序は関連付けられていません。一部のカテゴリは2値(yesまたはno、maleまたはfemaleなど)であり、取り得る値が2つのみです。その他のカテゴリは多クラスであり、3つ以上の値(small、mediumおよびlargeなど)を持ちます。
Oracle Data Miningでは、デフォルトでCHARおよびVARCHAR2を質的として解釈しますが、これらの列は非構造化データ(テキスト)の列として識別される場合もあります。Oracle Data Miningでは、DM_NESTED_CATEGORICALSの列を質的として解釈します。CLOB、BLOBおよびBFILEの列には、常に非構造化データが含まれます。
分類モデルのターゲットは質的です。(分類モデルのターゲットが量的である場合、このターゲットは質的として解釈されます。)一方、回帰モデルのターゲットは量的です。属性評価モデルのターゲットは、質的または量的のいずれかです。
関連項目
23.2.4 モデル・シグネチャ
モデルのシグネチャは、モデルの作成に使用されたデータ属性のセットです。シグネチャの属性の一部またはすべては、スコアリング用に存在している必要があります。モデルは、可能なかぎり欠損している列も埋めようとします。名前は同じだがデータ型が異なる列が存在している場合、モデルではそのデータ型の変換が試行されます。余分な未使用の列が存在している場合、それらは無視されます。
必ずしも作成データのすべての列がモデルのシグネチャに含まれるとはかぎりません。アルゴリズム固有の基準により、モデルが特定の列を無視することがあります。また、変換によって一部の列が除外される場合もあります。モデルの作成で実際に使用されたデータ属性のみがシグネチャに含まれます。
23.2.5 モデル属性の名前の詳細
23.2.6 モデル詳細
モデルの詳細によって、モデル属性、およびアルゴリズムによるモデル属性の処理に関する情報がわかります。アルゴリズムにはそれぞれ別個のGET_MODEL_DETAILSルーチンが存在します。かわりにモデルの詳細ビューを利用することをお薦めします。
モデル属性には変換式や逆変換式が関連付けられます。変換はモデルを作成するアルゴリズムの処理の前にデータ属性に適用されます。逆変換はモデルの作成後にモデル属性に適用されますので、モデルの詳細は元のデータ属性の形式または可能なかぎりそれに近い形式で表されます。
逆変換では、モデルの透明性がサポートされます。逆変換は、アルゴリズムによって内部的に処理されるデータを、ユーザーが解釈可能な形式で表示します。
例23-3に、属性評価モデルに対するGET_MODEL_DETAILSファンクションの定義を示します。
例23-3 属性評価モデルのモデルの詳細
属性評価モデルに対するGET_MODEL_DETAILSファンクションの構文は次のとおりです。
DBMS_DATA_MINING.GET_MODEL_DETAILS_AI (
model_name VARCHAR2)
RETURN DM_RANKED_ATTRIBUTES PIPELINED;
このファンクションは、仮想表DM_RANKED_ATTRIBUTESを戻します。これらの列がモデルの詳細です。指定したモデルの各モデル属性に対応する個別の行が存在します。これらの列は、次のように示されます。
attribute_name VARCHAR2(4000) attribute_subname VARCHAR2(4000) importance_value NUMBER rank NUMBER(38)
23.3 ネストしたデータの使用
1対多の関係の表間の結合は、ネストされた列によって表されます。
Oracle Data Miningでは、各レコードが個別の行に含まれた、単一レコード・ケース形式のケース表が必要です。データの一部または全部が複数レコード・ケース形式で、各レコードが複数の行に含まれている場合はどうなるでしょうか。1つの属性で一連の値または値の集合(学生のテスト・スコアや顧客に購入された製品)を表す場合はどうなるでしょうか。
このような1対多の関係は通常、表間の結合として実装します。たとえば、顧客表を売上表と結合し、購入された製品のリストを各顧客に関連付けることができます。
Oracle Data Miningでは、ネストした列を通じてディメンション化されたデータをサポートしています。ケース表にディメンション化されたデータを含めるには、ビューを作成し、データ・マイニングのネストした表タイプの1つに結合データをキャストします。ネストした列の各行は、属性の名前と値のペアから構成されます。ネストした各行は、別個の属性として内部的に処理されます。
23.3.1 ネストしたオブジェクト型
ネストした表は、他のデータ型のかわりに使用できるオブジェクト・データ型です。
Oracle Databaseでは、実在するエンティティをデータベース内のオブジェクトとしてモデル化できる、ユーザー定義のデータ型がサポートされています。コレクション型は、複数値属性をモデル化するためのオブジェクト・データ型です。ネストした表はコレクション型です。ネストした表は、他のデータ型が使用できる場所であればどこでも使用できます。
Oracle Data Miningでは、次のネストしたオブジェクト型をサポートしています。
DM_NESTED_BINARY_DOUBLESDM_NESTED_BINARY_FLOATSDM_NESTED_NUMERICALSDM_NESTED_CATEGORICALS
ネストした型の説明は、この例を参照してください。
例23-4 Oracle Data Miningのネストしたデータ型
describe dm_nested_binary_double Name Null? Type ----------------------------------------- -------- ---------------------------- ATTRIBUTE_NAME VARCHAR2(4000) VALUE BINARY_DOUBLE describe dm_nested_binary_doubles DM_NESTED_BINARY_DOUBLES TABLE OF SYS.DM_NESTED_BINARY_DOUBLE Name Null? Type ------------------------------------------ -------- --------------------------- ATTRIBUTE_NAME VARCHAR2(4000) VALUE BINARY_DOUBLE describedm_nested_binary_floatName Null? Type ----------------------------------------- -------- --------------------------- ATTRIBUTE_NAME VARCHAR2(4000) VALUE BINARY_FLOAT describedm_nested_binary_floatsDM_NESTED_BINARY_FLOATS TABLE OF SYS.DM_NESTED_BINARY_FLOAT Name Null? Type ----------------------------------------- -------- ---------------------------- ATTRIBUTE_NAME VARCHAR2(4000) VALUE BINARY_FLOAT describedm_nested_numericalName Null? Type ----------------------------------------- -------- ---------------------------- ATTRIBUTE_NAME VARCHAR2(4000) VALUE NUMBER describedm_nested_numericalsDM_NESTED_NUMERICALS TABLE OF SYS.DM_NESTED_NUMERICAL Name Null? Type ----------------------------------------- -------- ---------------------------- ATTRIBUTE_NAME VARCHAR2(4000) VALUE NUMBER describedm_nested_categoricalName Null? Type ----------------------------------------- -------- ---------------------------- ATTRIBUTE_NAME VARCHAR2(4000) VALUE VARCHAR2(4000) describedm_nested_categoricalsDM_NESTED_CATEGORICALS TABLE OF SYS.DM_NESTED_CATEGORICAL Name Null? Type ----------------------------------------- -------- ---------------------------- ATTRIBUTE_NAME VARCHAR2(4000) VALUE VARCHAR2(4000)
23.3.2 例: マイニング用のトランザクショナル・データの変換
例23-5は、ある売上表のビューのデータです。4つの地域で販売された製品のうちの3種類の売上が表示されています。このデータは、各ケース(製品)の売上が複数の行に格納されているため、製品レベルでのマイニングには適していません。
例23-6は、このデータがマイニング用にどのように変換されるかを示しています。ケースID列はPRODUCTです。SALES_PER_REGION(DM_NESTED_NUMERICALS型のネストした列)がデータ属性です。この表は、各ケースの情報が単一行に格納されているため、製品ケース・レベルでのマイニングに適しています。
注意:
この例は、単に概念を表したものです。実際には、処理前にデータがピボットされることはありません。
例23-5複数レコード・ケース形式の地域ごとの製品売上
PRODUCT REGION SALES ------- -------- ---------- Prod1 NE 556432 Prod2 NE 670155 Prod3 NE 3111 . . Prod1 NW 90887 Prod2 NW 100999 Prod3 NW 750437 . . Prod1 SE 82153 Prod2 SE 57322 Prod3 SE 28938 . . Prod1 SW 3297551 Prod2 SW 4972019 Prod3 SW 884923 . .
例23-6 単一レコード・ケース形式の地域ごとの製品売上
PRODUCT SALES_PER_REGION
(ATTRIBUTE_NAME, VALUE)
------ --------------------------
Prod1 ('NE' , 556432)
('NW' , 90887)
('SE' , 82153)
('SW' , 3297551)
Prod2 ('NE' , 670155)
('NW' , 100999)
('SE' , 57322)
('SW' , 4972019)
Prod3 ('NE' , 3111)
('NW' , 750437)
('SE' , 28938)
('SW' , 884923)
.
.
例23-7 SALES_PER_REGIONから導出されたモデル属性
PRODUCT SALES_PER_REGION.NE SALES_PER_REGION.NW SALES_PER_REGION.SE SALES_PER_REGION.SW ------- ------------------ ------------------- ------------------ ------------------- Prod1 556432 90887 82153 3297551 Prod2 670155 100999 57322 4972019 Prod3 3111 750437 28938 884923 . .
23.4 マーケット・バスケット・データの使用
マーケット・バスケット・データは、一連のバスケットまたはトランザクションで販売された商品群を表します。Oracle Data Miningでは、マーケット・バスケット分析に相関マイニング機能が提供されます。
相関モデルで使用されるAprioriアルゴリズムでは、ある商品が別の商品と同時に購入される傾向を記述する相関ルールが生成されます。たとえば、相関ルールで、ピーナッツ・バターを購入する顧客は80%の確率でジャムも購入すると示される場合があります。
マーケット・バスケット・データは通常、トランザクショナルです。トランザクショナルなデータでは、1つのケースが1回の取引(トランザクション)を表し、トランザクションのデータは複数の行に格納されます。Oracle Data Miningの相関モデルはトランザクショナル・データまたは単一レコード・ケースのデータで構築できます。ODMS_ITEM_ID_COLUMN_NAMEおよびODMS_ITEM_VALUE_COLUMN_NAMEの設定では、相関ルールのデータがトランザクショナル形式かどうかを指定できます。
注意:
相関モデルは、ネイティブ・トランザクショナル・データで構築できる唯一のモデルです。その他すべての種類のモデルについて、Oracle Data Miningでは、単一レコード・ケース形式で存在するデータが必要です。
Aprioriアルゴリズムでは、データがトランザクショナルで、データに多数の欠損値が含まれていることが想定されます。Aprioriは、すべての欠損値をスパース・データとして解釈し、スパース・データを処理するための独自のネイティブ・メカニズムを持っています。
関連項目:
ODMS_ITEM_ID_COLUMN_NAME設定およびODMS_ITEM_VALUE_COLUMN_NAME設定の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
23.4.1 例: マーケット・バスケット分析用のネストした列の作成
例に、マーケット・バスケット分析用のネストした列を定義する方法を示します。
相関モデルは、ネイティブ・トランザクショナル・データまたはネストしたデータで構築できます。次の例に、マーケット・バスケット分析用のネストした列を定義する方法を示します。
次のSQL文は、SALES_TRANS_CUST_NESTEDというビューで、このデータをDM_NESTED_NUMERICALS型の列に変換します。このビューは、マイニング用のケース表として使用できます。
CREATE VIEW sales_trans_cust_nested AS
SELECT trans_id,
CAST(COLLECT(DM_NESTED_NUMERICAL(
prod_name, 1))
AS DM_NESTED_NUMERICALS) custprods
FROM sales_trans_cust
GROUP BY trans_id;
この問合せは、変換されたデータから2つの行を戻します。
SELECT * FROM sales_trans_cust_nested
WHERE trans_id < 101000
AND trans_id > 100997;
TRANS_ID CUSTPRODS(ATTRIBUTE_NAME, VALUE)
------- ------------------------------------------------
100998 DM_NESTED_NUMERICALS
(DM_NESTED_NUMERICAL('O/S Documentation Set - English', 1)
100999 DM_NESTED_NUMERICALS
(DM_NESTED_NUMERICAL('CD-RW, High Speed Pack of 5', 1),
DM_NESTED_NUMERICAL('External 8X CD-ROM', 1),
DM_NESTED_NUMERICAL('SIMM- 16MB PCMCIAII card', 1))例23-8 ネストした列への変換
ビューSALES_TRANS_CUSTは、各マーケット・バスケットを識別するトランザクションIDと、各バスケット内の製品のリストを表示します。
describe sales_trans_cust Name Null? Type ----------------------------------------------------- -------- ---------------- TRANS_ID NOT NULL NUMBER PROD_NAME NOT NULL VARCHAR2(50) QUANTITY NUMBER
関連項目
23.6 欠損値の処理
Oracle Data Miningでは、スパース・データと、ランダムな欠損値の含まれるデータとが区別されます。後者は、一部の属性値が不明であることを意味します。一方、スパース・データには、データ内には表されていないが既知であるとみなされる値が含まれます。
スパース・データの典型例はマーケット・バスケット・データです。何百または何千個もある取扱い商品の中で、個々のケース(バスケットまたはトランザクション)に含まれる商品はわずかです。商品の値はすべて既知ですが、すべての商品がバスケットの中に存在するわけではありません。存在する商品に対しては特定の数量がありますが、存在していない商品についてはスパース(既知の数量は0(ゼロ))となります。
Oracle Data Miningでは、欠損データは次のように解釈されます。
-
ランダムな欠損: 単純な(ネストしていない)データ型の列内の欠損値は、ランダムに欠損しているとみなされます。
-
スパース: ネストした列内の欠損値は、スパース性を示します。
23.6.1 例: 欠損値とスパース・データの識別基準
この項の例では、データがスパースであるのかランダムに欠損しているのかをOracle Data Miningがどのように識別するかについて説明します。
23.6.1.1 売上表のスパース性
ある売上表には、一定期間内に複数の店舗で顧客に販売された製品グループのPOSデータが格納されます。それぞれの顧客は、少数の製品しか購入しません。顧客が購入しなかった製品は、売上表の行として表示されません。
1人の顧客が各製品に支払った金額を求める場合、購入されなかった製品の金額は0(ゼロ)と推定されます。表に行が表示されなくても、この値はランダムな欠損でも未知でもなくゼロになります。
売上データは(製品、店舗、顧客、時間で)ディメンション化され、多くの場合、マイニング用のネストしたデータとして表されます。
ネストした列の欠損値は常にスパース性を示すため、マイニング対象のデータに関してこの解釈が適切であることを確認する必要があります。たとえば、大規模な映画データベースのユーザーの映画評価が格納されている複数レコード・ケースのデータセットをマイニングしようとする場合、欠損している評価は未知の(ランダムに欠損している)値ですが、Oracle Data Miningではこのデータをスパースとして扱い、欠損値については評価を0(ゼロ)と推定します。
23.6.2 Oracle Data Miningにおける欠損値の扱い
欠損値の処理方法は、アルゴリズムおよびデータの性質(質的または量的、スパースまたはランダムな欠損)によって異なります。次の表に、欠損値の処理方法の概要を示します。
注意:
Oracle Data Miningでは、自動データ準備が使用されているかどうかにかかわらず、同じ欠損値処理が実行されます。
表23-2 アルゴリズムによる欠損値処理
| 欠損データ | EM、GLM、NMF、k-Means、SVD、SVM | DT、MDL、NB、OC | Apriori |
|---|---|---|---|
|
ランダムな欠損値(量的) |
欠損している量的な値はアルゴリズムにより平均値に置換される。 期待値最大化(EM)では、ガウス分布でモデル化された列のみ置換される。 |
すべての欠損データがスパースとして解釈される。 |
|
|
ランダムな欠損値(質的) |
一般化線形モデル(GLM)、Non-Negative Matrix Factorization (NMF)、k-Meansおよびサポート・ベクター・マシン(SVM)により、欠損質的値がモードで置換されます。 特異値分解(SVD)は、質的データをサポートしていません。 EMは欠損している質的な値を置換しない。EMはNULLを、独自の頻度カウントとともに、個別値として扱う。 |
欠損値はそのままランダムな欠損として処理される。 |
すべての欠損データがスパースとして解釈される。 |
|
スパース・データ(量的) |
スパースな量的データはアルゴリズムにより0(ゼロ)に置換される。 |
O-Clusterはネストしたデータをサポートしないため、スパース・データもサポートされない。ディシジョン・ツリー(DT)、最小記述長(MDL)およびNaive Bayes (NB)では、スパースな量的データはゼロに置換される。 |
スパース・データは処理される。 |
|
スパース・データ(質的) |
SVD以外のすべてのアルゴリズムは、スパースな質的データをゼロ・ベクターで置換する。SVDは質的データをサポートしない。 |
O-Clusterはネストしたデータをサポートしないため、スパース・データもサポートされない。DT、MDLおよびNBでは、スパースな質的データは |
スパース・データは処理される。 |
23.6.3 欠損値処理の変更
欠損データをスパースまたはランダムな欠損として置換します。
Oracle Data Miningで、欠損データを、ランダムな欠損としてではなくスパースとして、またはスパースとしてではなくランダムな欠損として処理する必要がある場合、モデルを作成する前に変換を行う必要があります
欠損値をスパースとして処理する必要があるが、Oracle Data Miningではその欠損値がランダムな欠損値として解釈される場合、NVLなどのSQL関数を使用すると、NULLを「NA」などの値に置換できます。Oracle Data Miningでは、特定の値が存在する場合、欠損値処理は行われません。
欠損しているネストした属性をランダムな欠損として処理する場合は、ネストした行を、別々の列に格納された物理的な属性に変換できます(ただし、ケース表の列数がデータベースによる制限(1000列以内)を超えない場合に限ります)。存在しうる属性の名前をすべて入力し、それらをNULLとして指定してください。かわりに、存在していないすべての商品について、ネストした列に行を挿入し、各行に平均値やモードなどの値を割り当てます。