| Oracle Data Miningアプリケーション開発者ガイド 11g リリース2(11.2) E57719-01 |
|
 前 |
 次 |
この章では、Oracle Data Miningでデータがどのように解釈されるかについて説明します。ここでは、データ・マイニングのケース表の要件、およびデータ属性とモデル属性の概念について取り上げます。データ変換については、『Oracle Data Mining概要』を参照してください。
この章には、次の項が含まれます。
マイニング対象のデータは、1つの表またはビュー内で定義する必要があります。各レコードの情報は別個の行に格納する必要があります。このデータ・レコードは一般的にケースと呼ばれます。各ケースは、一意のケースIDで識別されます。表またはビュー自体は、ケース表と呼ばれます。
マイニングに使用できる表の例として、SHスキーマのCUSTOMERS表があります。各顧客のすべての情報は、1つの行に格納されています。CUST_ID列にケースIDが格納されます。例3-1に示されている行は、SH.CUSTOMERSから選択されています。
例3-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
|
注意: Oracle Data Miningでは、ネイティブ・トランザクショナル・データで構築できる相関モデルを除き、すべての種類のモデルに単一レコード・ケースのデータが必要です。「マーケット・バスケット・データ」を参照してください。 |
ケース表の列には、各ケースを説明する属性が含まれます。例3-1で、属性はCUST_GENDER、CUST_YEAR_OF_BIRTHおよびCUST_MAIN_PHONE_NUMBERです。属性は、監視ありモデルの予測子および監視なしモデルの記述子です。ケースIDのCUST_IDは、特別な属性として表示できます(これは予測子または記述子ではありません)。
Oracle Data Miningでは、次の列のデータ型を指定できます。
VARCHAR2、CHARNUMBER、FLOATDM_NESTED_CATEGORICALSDM_NESTED_NUMERICALSデータ型の変換については、『Oracle Data Mining概要』を参照してください。
ネストした型については、「ネストしたデータ」で説明します。ケースID列はネストした型を格納できません。
分類モデルまたは回帰モデルを作成するには、ケース表が2つ必要です。1つはモデルの作成(トレーニング)用、もう1つはモデルのテスト用に使用されます。作成データおよびテスト・データは多くの場合、同じデータセットから導出すると便利です。たとえば、モデルの作成用に行の60%を選択し、モデルのテスト用に残りの40%を選択するといったことが考えられます。
その他のマイニング機能を実装するモデル(属性評価、クラスタリング、相関または特徴抽出)では、別個のテスト・データは使用しません。
データ・マイニング・モデルの多くは別個のデータに適用できます。モデルの適用対象となるデータは、適用データまたはスコアリング・データと呼ばれます。Oracle Data Miningでは、分類、回帰、異常検出、クラスタリングおよび特徴抽出のスコアリング操作をサポートします。
スコアリング・プロセスでは、スコアリング・データ内の列名と、モデルの作成に使用された列の名前とがマッチングされます。スコアリング・プロセスでは、スコアリング・データ内にすべての列が存在している必要はありません。データ型が一致しない場合、Oracle Data Miningでは型の強制が試行されます。たとえば、PRODUCT_RATINGという列が作成データ内ではVARCHAR2型であるのに対し、スコアリング・データ内ではNUMBER型である場合、Oracle Data MiningではTO_CHAR()関数が効果的に適用され、スコアリング・データ内の列の型が変換されます。
テスト・データまたはスコアリング・データ内の列には、作成データ内の対応する列と同じ変換を行う必要があります。たとえば、作成データ内のAGE列が数値から値CHILD、ADULTおよびSENIORに変換された場合、スコアリング・データ内のAGE列にも同じ変換を実行して、モデルが適切に評価できるようにする必要があります。
属性は、データ・マイニングで使用されるデータの項目です。予測モデルでは、属性は、特定の結果に影響を及ぼす予測子です。記述モデルでは、自然なグループまたは相関を見つけるために分析される情報項目です。たとえば、従業員データの表は、肩書き、雇用日、給与、年齢、性別などの属性を持ちます。
データ属性とは、モデルの作成、テストまたはスコアリングに使用されるデータセットの列のことです。モデル属性とは、モデルによって内部的に使用されるデータ表現のことです。
データ属性とモデル属性が同一である場合もあります。たとえば、値S、M、Lが格納されているSIZEという列が、モデル作成用としてアルゴリズムによって使用される属性であるとします。モデル属性SIZEは、内部的にはその導出元であるデータ属性と同じである可能性が高いと考えられます。
一方、ある製品グループの売上高が格納されているネストした列SALES_PRODは、モデル属性とは一致しません。データ属性はSALES_PRODですが、モデル属性は、対応する売上高と関連付けられた各製品(ネストした列の各行)となります。
変換によっても、データ属性とモデル属性の不一致が起こります。たとえば、変換によって2つのデータ属性に計算が適用され、その結果が新しい属性に格納されたとします。この新しい属性は、対応するデータ属性を持たないモデル属性になります。ビニング、正規化および外れ値の処理などの変換では、ケース表のデータ属性とモデルの属性表現の不一致が起こります。
監視ありモデルのターゲットは特別な属性です。作成データのターゲット列には、モデルの作成(トレーニング)に使用される履歴データが格納されます。テスト・データのターゲット列には、予測の比較対象になる履歴データが格納されます。スコアリング・データのターゲット列には、モデルを適用したときの結果が格納されます。
ターゲットは、クラスタリング・モデル、特徴抽出モデル、相関モデルおよび異常検出モデルでは使用されません。
*_MINING_MODEL_ATTRIBUTESビューを問い合せると、特定のモデルのターゲットを見つけることができます(例3-2を参照)。
モデル属性は、量的または質的のいずれかです。データ属性(ケース表の列)は、Oracleデータ型を持ちます。
Oracle Data Miningでは、NUMBER、FLOATおよびDM_NESTED_NUMERICALSを量的として解釈し、CHAR、VARCHAR2およびDM_NESTED_CATEGORICALSを質的として解釈します。ただし例外として、分類モデルのターゲットがNUMBERまたはFLOATの場合は質的として解釈されます。
量的属性は、論理上は無限の数の値を持つことができます。これらの値には暗黙的な順序があり、値間の差も順序付けられます。
質的属性は、有限数の離散的カテゴリまたはクラスに属する値を持ちます。値には、暗黙的な順序は関連付けられていません。一部のカテゴリは2値(yesまたはno、maleまたはfemaleなど)であり、取り得る値が2つのみです。質的ターゲットが3つ以上の値を持つモデルを表すときは、多クラスという表現を使用します。たとえば、ターゲットが洋服のサイズで、その値がsmall、mediumまたはlargeである場合などです。
分類モデルのターゲットは質的です。一方、回帰モデルのターゲットは量的です。属性評価モデルのターゲットは、質的または量的のいずれかです。
モデルのシグネチャは、モデルの作成に使用されたデータ属性のセットです。シグネチャの属性の一部またはすべては、スコアリング用に存在している必要があります。一部の列が存在していない場合、それらは無視されます。名前は同じだがデータ型が異なる列が存在している場合、モデルではそのデータ型の変換が試行されます。
必ずしも作成データのすべての列がモデルのシグネチャに含まれるとは限りません。アルゴリズム固有の基準により、モデルが特定の列を無視することがあります。また、変換によって一部の列が除外される場合もあります。モデルの作成で実際に使用されたデータ属性のみがシグネチャに含まれます。
モデルのシグネチャの列、およびターゲット(監視ありモデルの場合)は、データ・ディクショナリ・ビューALL/USER/DBA_MINING_MODEL_ATTRIBUTESにリストされます。ALL接頭辞を使用した場合、このビューは、現在のユーザーがアクセスできるすべてのマイニング・モデルのシグネチャとターゲットを戻します。USER接頭辞を使用した場合は、ユーザー・スキーマ内のマイニング・モデルのシグネチャとターゲットを戻します。DBA接頭辞を使用できるのはDBAのみです。
ALL_MINING_MODEL_ATTRIBUTESビューの列を次に示します。表3-1はその詳細です。
SQL> describe all_mining_model_attributes Name Null? Type ---------------------------------------------------------- OWNER NOT NULL VARCHAR2(30) MODEL_NAME NOT NULL VARCHAR2(30) ATTRIBUTE_NAME NOT NULL VARCHAR2(30) ATTRIBUTE_TYPE VARCHAR2(11) DATA_TYPE VARCHAR2(12) DATA_LENGTH NUMBER DATA_PRECISION NUMBER DATA_SCALE NUMBER USAGE_TYPE VARCHAR2(8) TARGET VARCHAR2(3)
表3-1 ALL_MINING_MODEL_ATTRIBUTES
| 列 | 説明 |
|---|---|
|
|
マイニング・モデルの所有者。 |
|
|
マイニング・モデルの名前。 |
|
|
データ属性(列)の名前。 |
|
|
モデルによってデータ属性から導出されたモデル属性のタイプ。属性のタイプは、量的または質的のいずれかとなる。 この情報は、データ属性とモデル属性との間に1対1のマッピング関係がある場合にかぎり有意。モデルによる使用方法を変更する変換がデータ属性に対して実行されていた場合は、 |
|
|
データ属性(列)のOracleデータ型。次のいずれかとなる。 NUMBERFLOATCHARVARCHAR2NESTED TABLE値が DM_NESTED_NUMERICALSまたは DM_NESTED_CATEGORICALSデータ型が 詳細は、「ネストしたデータ」を参照。 |
|
|
データ型の長さ。 |
|
|
固定小数点数の精度(10進有効桁数)。データ型 |
|
|
固定小数点数のスケール。スケール(小数点から最下位桁までの桁数)は、データ型 |
|
|
属性がモデルの作成に使用されたかどうかを表す。一部の属性は、変換またはアルゴリズムの処理によって除外される場合がある。* |
|
|
属性がターゲットかどうか。値は、 属性がターゲットであり、かつアルゴリズムにより処理用に変換されている場合、 |
例3-2の問合せでは、データ・マイニングのサンプル・プログラムの1つから生成されたSVMモデルT_SVM_CLAS_SAMPLEのデータ属性に関する情報が戻されます。この問合せでは、モデルのシグネチャ内の各データ属性の名前とデータ型、属性が使用されたタイプ(量的または質的)、および属性がターゲットかどうかが戻されます。
例3-2 ALL_MINING_MODEL_ATTRIBUTES
SQL> select model_name, attribute_name, attribute_type, data_type, target
from user_mining_model_attributes
where model_name = 'T_SVM_CLAS_SAMPLE';
MODEL_NAME ATTRIBUTE_NAME ATTRIBUTE_TYPE DATA_TYPE TARGET
------------------- --------------------- --------------- ----------- ------
T_SVM_CLAS_SAMPLE COMMENTS NUMERICAL NESTED TABLE NO
T_SVM_CLAS_SAMPLE AGE NUMERICAL NUMBER NO
T_SVM_CLAS_SAMPLE CUST_MARITAL_STATUS CATEGORICAL VARCHAR2 NO
T_SVM_CLAS_SAMPLE COUNTRY_NAME CATEGORICAL VARCHAR2 NO
T_SVM_CLAS_SAMPLE CUST_INCOME_LEVEL CATEGORICAL VARCHAR2 NO
T_SVM_CLAS_SAMPLE EDUCATION CATEGORICAL VARCHAR2 NO
T_SVM_CLAS_SAMPLE OCCUPATION CATEGORICAL VARCHAR2 NO
T_SVM_CLAS_SAMPLE HOUSEHOLD_SIZE CATEGORICAL VARCHAR2 NO
T_SVM_CLAS_SAMPLE YRS_RESIDENCE NUMERICAL NUMBER NO
T_SVM_CLAS_SAMPLE BULK_PACK_DISKETTES NUMERICAL NUMBER NO
T_SVM_CLAS_SAMPLE FLAT_PANEL_MONITOR NUMERICAL NUMBER NO
T_SVM_CLAS_SAMPLE HOME_THEATER_PACKAGE NUMERICAL NUMBER NO
T_SVM_CLAS_SAMPLE BOOKKEEPING_APPLICATION NUMERICAL NUMBER NO
T_SVM_CLAS_SAMPLE PRINTER_SUPPLIES NUMERICAL NUMBER NO
T_SVM_CLAS_SAMPLE Y_BOX_GAMES NUMERICAL NUMBER NO
T_SVM_CLAS_SAMPLE OS_DOC_SET_KANJI NUMERICAL NUMBER NO
T_SVM_CLAS_SAMPLE CUST_GENDER CATEGORICAL CHAR NO
T_SVM_CLAS_SAMPLE AFFINITY_CARD NUMERICAL NUMBER YES
モデル属性の名前は、1つの列名と1つのサブ列名から構成されます。
column_name[.subcolumn_name]
column_name構成要素は、データ属性の名前です。モデル属性の名前には必ず含まれます。ネストした属性の場合は、例3-3に示すようにsubcolumn_nameも含まれます。
モデルの詳細によって、モデル属性、およびアルゴリズムによるモデル属性の処理に関する情報がわかります。アルゴリズムにはそれぞれ別個のGET_MODEL_DETAILSルーチンが存在します。
モデル属性には変換式や逆変換式が関連付けられます。変換は、アルゴリズムによる処理用としてモデルに適用されます。逆変換は、モデルの詳細用に適用されます。GET_MODEL_DETAILSによってユーザーに戻される情報は、元のデータ属性の形式または可能なかぎりそれに近い形式で表されます。
逆変換は、監視ありモデルをスコアリングするときにターゲットに対しても適用されます。逆変換では、モデルの透明性がサポートされます。透明性については、『Oracle Data Mining概要』を参照してください。
例3-4に、属性評価モデルに対するGET_MODEL_DETAILSファンクションの定義を示します。PIPELINEDキーワードは、すべての行を1つの単一値として戻すのではなく、複数の単一値として戻すようにOracle Databaseに指示します。
例3-4 属性評価モデルのモデルの詳細
属性評価モデルに対する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))
Oracle Data Miningでは、各レコードが個別の行に含まれた、単一レコード・ケース形式のケース表が必要です。データの一部または全部が複数レコード・ケース形式で、各レコードが複数の行に含まれている場合はどうなるでしょうか。1つの属性で一連の値または値の集合(学生のテスト・スコアや顧客に購入された製品)を表す場合はどうなるでしょうか。
このような1対多の関係は通常、表間の結合として実装します。たとえば、顧客表を売上表と結合し、購入された製品のリストを各顧客に関連付ける場合があります。
Oracle Data Miningでは、ネストした列を通じてディメンション化されたデータをサポートしています。ケース表にディメンション化されたデータを含めるには、ビューを作成し、データ・マイニングのネストした表タイプの1つに結合データをキャストします。ネストした列の各行は、属性の名前と値のペアから構成されます。ネストした各行は、別個の属性として内部的に処理されます。
ネストしたデータをサポートするアルゴリズムは、表3-2にリストされています。
表3-2 ネストしたデータをサポートするOracle Data Miningアルゴリズム
| アルゴリズム | マイニング機能 |
|---|---|
|
Apriori |
相関ルール |
|
GLM |
分類、回帰 |
|
k-Means |
クラスタリング |
|
MDL |
属性評価 |
|
Naive Bayes |
分類 |
|
NMF |
特徴抽出 |
|
SVM |
分類、回帰、異常検出 |
Oracle Databaseでは、実在するエンティティをデータベース内のオブジェクトとしてモデル化できる、ユーザー定義のデータ型がサポートされています。コレクション型は、複数値属性をモデル化するためのオブジェクト・データ型です。ネストした表はコレクション型です。ネストした表は、他のデータ型が使用できる場所であればどこでも使用できます。コレクション型の詳細は、『Oracle Databaseオブジェクト・リレーショナル開発者ガイド』を参照してください。
Oracle Data Miningでは、量的属性用と質的属性用の2つのネストしたオブジェクト型がサポートされています。
DM_NESTED_NUMERICALSオブジェクト型は、量的属性のネストした表です。各行は、単一のDM_NESTED_NUMERICALです。
ネストした量的属性(行)は、次のように示されます。
SQL> describe dm_nested_numerical
Name Null? Type
----------------------------------------- -------- ----------------------------
ATTRIBUTE_NAME VARCHAR2(4000)
VALUE NUMBER
量的属性のコレクション(表)は、次のように示されます。
SQL> describe dm_nested_numericals
DM_NESTED_NUMERICALS TABLE OF SYS.DM_NESTED_NUMERICAL
Name Null? Type
----------------------------------------- -------- ----------------------------
ATTRIBUTE_NAME VARCHAR2(4000)
VALUE NUMBER
DM_NESTED_CATEGORICALSオブジェクト型は、質的属性のネストした表です。各行は、単一のDM_NESTED_CATEGORICALです。
ネストした質的属性(行)は、次のように示されます。
SQL> describe dm_nested_categorical
Name Null? Type
----------------------------------------- -------- ----------------------------
ATTRIBUTE_NAME VARCHAR2(4000)
VALUE VARCHAR2(4000)
質的属性のコレクション(表)は、次のように示されます。
SQL> describe dm_nested_categoricals
DM_NESTED_CATEGORICALS TABLE OF SYS.DM_NESTED_CATEGORICAL
Name Null? Type
----------------------------------------- -------- ----------------------------
ATTRIBUTE_NAME VARCHAR2(4000)
VALUE VARCHAR2(4000)
例3-5は、ある売上表のビューのデータです。4つの地域で販売された製品のうちの3種類の売上が表示されています。このデータは、各ケース(製品)の売上が複数の行に格納されているため、製品レベルでのマイニングには適していません。
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 . .
例3-6は、このデータがマイニング用にどのように変換されるかを示しています。ケースID列はPRODUCTになります。SALES_PER_REGION(DM_NESTED_NUMERICALS型のネストした列)がデータ属性になります。この表は、各ケースの情報が単一行に格納されているため、マイニングに適しています。
例3-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)
.
.
Oracle Data Miningでは、ネストした各行は例3-7のように別々のモデル属性として扱われます。(この例は、単に概念を表したものです。実際には、処理前にデータがピボットされることはありません。)
例3-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 . .
例3-8に、データ・マイニング用のネストした列を定義する方法を示します。この例では、トランザクショナルなマーケット・バスケット・データを使用します。
例3-8 ネストした列への変換
ビューSALES_TRANS_CUSTは、各マーケット・バスケットを識別するトランザクションIDと、各バスケット内の製品のリストを表示します。
SQL> describe sales_trans_cust Name Null? Type ----------------------------------------------------- -------- ---------------- TRANS_ID NOT NULL NUMBER PROD_NAME NOT NULL VARCHAR2(50) QUANTITY NUMBER
次のSQL文は、SALES_TRANS_CUST_NESTEDというビューで、このデータをDM_NESTED_NUMERICALS型の列に変換します。このビューは、マイニング用のケース表として使用できます。
SQL> CREATE VIEW sales_trans_cust_nested AS
SELECT trans_id,
CAST(COLLECT(DM_NESTED_NUMERICAL(
prod_name, quantity))
AS DM_NESTED_NUMERICALS) custprods
FROM sales_trans_cust
GROUP BY trans_id;
この問合せは、変換されたデータから2つの行を戻します。
SQL> 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', 2),
DM_NESTED_NUMERICAL('External 8X CD-ROM', 1),
DM_NESTED_NUMERICAL('SIMM- 16MB PCMCIAII card', 1))
マーケット・バスケット・データは、一連のバスケットまたはトランザクションで販売された商品群を表します。Oracle Data Miningでは、マーケット・バスケット分析に相関マイニング機能が提供されます。
相関モデルで使用されるAprioriアルゴリズムでは、ある商品が別の商品と同時に購入される傾向を記述する相関ルールが生成されます。たとえば、相関ルールで、ピーナッツ・バターを購入する顧客の80%がジャムも購入する信頼度が65%だと示される場合があります。
マーケット・バスケット・データは通常、トランザクショナルです。トランザクショナルなデータでは、1つのケースが1回の取引(トランザクション)を表し、トランザクションのデータは複数の行に格納されます。Oracle Data Miningの相関モデルはトランザクショナル・データまたは単一レコード・ケースのデータで構築できます。ODMS_ITEM_ID_COLUMN_NAMEおよびODMS_ITEM_VALUE_COLUMN_NAMEの設定では、相関ルールのデータがトランザクショナル形式かどうかを指定できます。
|
注意: 相関モデルは、ネイティブ・トランザクショナル・データで構築できる唯一のモデルです。その他すべての種類のモデルについて、Oracle Data Miningでは、単一レコード・ケース形式で存在するデータが必要です。 |
Aprioriアルゴリズムでは、データがトランザクショナルで、データに多数の欠損値が含まれていることが想定されます。Aprioriは、すべての欠損値をスパース・データとして解釈し、スパース・データを処理するための独自のネイティブ・メカニズムを持っています。
Oracle Data Miningでは、スパース・データと、ランダムな欠損値の含まれるデータとが区別されます。後者は、一部の属性値が不明であることを意味します。一方、スパース・データには、データ内には表されていないが既知であるとみなされる値が含まれます。
スパース・データの典型例はマーケット・バスケット・データです。何百または何千個もある取扱い商品の中で、個々のケース(バスケットまたはトランザクション)に含まれる商品はわずかです。商品の値はすべて既知ですが、すべての商品がバスケットの中に存在するわけではありません。存在する商品に対しては特定の数量がありますが、存在していない商品についてはスパース(既知の数量は0(ゼロ))となります。
Oracle Data Miningでは、欠損データは次のように解釈されます。
欠損 - 単純な(ネストしていない)データ型の列内の欠損値は、ランダムに欠損しているとみなされます。
スパース - ネストした列内の欠損値は、スパース性を示します。
この項の例では、データがスパースであるのかランダムに欠損しているのかをOracle Data Miningがどのように識別するかについて説明します。
ある売上表には、一定期間内に複数の店舗で顧客に販売された製品グループのPOSデータが格納されます。それぞれの顧客は、一部の製品しか購入しません。顧客が購入しなかった製品は、売上表の行として表示されません。
1人の顧客が各製品に支払った金額を求める場合、購入されなかった製品の金額は0(ゼロ)と推定されます。表に行が表示されなくても、この値はランダムな欠損でも未知でもなくゼロになります。
売上データは(製品、店舗、顧客、時間で)ディメンション化され、マイニング用のネストしたデータとして表されます。
ネストした列の欠損値は常にスパース性を示すため、マイニング対象のデータに関してこの解釈が適切であることを確認する必要があります。たとえば、大規模な映画データベースのユーザーの映画評価が格納されている複数レコード・ケースのデータセットをマイニングしようとする場合、欠損している評価は未知の(ランダムに欠損している)値ですが、Oracle Data Miningではこのデータをスパースとして扱い、欠損値については評価を0(ゼロ)と推定します。
欠損値の処理方法は、アルゴリズムおよびデータの性質(質的または量的、スパースまたはランダムな欠損)によって異なります。表3-3に、欠損値の処理方法の概要を示します。
|
注意: Oracle Data Miningでは、自動データ準備が使用されているかどうかにかかわらず、同じ欠損値処理が実行されます。 |
表3-3 アルゴリズムによる欠損値処理
| 欠損データ | SVM、NMF、k-Means、GLM | NB、MDL、DT、OC | Apriori |
|---|---|---|---|
|
ランダムな欠損値(量的) |
欠損している量的な値は平均値に置換される。 |
すべての欠損データがスパースとして解釈される。 |
|
|
ランダムな欠損値(質的) |
欠損している質的な値は最頻値に置換される。 |
欠損値はそのままランダムな欠損として処理される。 |
すべての欠損データがスパースとして解釈される。 |
|
スパース・データ(量的) |
スパースな量的データは0(ゼロ)に置換される。 |
DTとO-Clusterはネストしたデータをサポートしないため、スパース・データもサポートされない。NBおよびMDLでは、スパースな量的データは0(ゼロ)に置換される。 |
スパース・データは処理される。 |
|
スパース・データ(質的) |
スパースな質的データは0(ゼロ)ベクトルに置換される。 |
DTとO-Clusterはネストしたデータをサポートしないため、スパース・データもサポートされない。NBおよびMDLでは、スパースな質的データは |
スパース・データは処理される。 |
Oacle Data Miningで、欠損データを、ランダムな欠損としてではなくスパースとして、またはスパースとしてではなくランダムな欠損として処理する必要がある場合、モデルを作成する前に変換を行う必要があります
欠損値をスパースとして処理する必要があるが、Oracle Data Miningではその欠損値がランダムな欠損値として解釈される場合、NVLなどのSQL関数を使用すると、NULLを「NA」などの値に置換できます。Oracle Data Miningでは、特定の値が存在する場合、欠損値処理は行われません。『Oracle Database SQL言語リファレンス』を参照してください。
欠損しているネストした属性をランダムな欠損として処理する場合は、ネストした行を、別々の列に格納された物理的な属性に変換できます(ただし、ケース表の列数がデータベースによる制限(1000列以内)を超えない場合に限ります)。存在しうる属性の名前をすべて入力し、それらをNULLとして指定してください。
