| Oracle Real-Time Decisions新機能ガイド リリース2.2.1 E06108-01 |
|
 戻る |
この章では、Oracle Real-Time Decisions（Oracle RTD）リリース2.2.1で実装されたモデルのスナップショットについて説明します。この章の項目は次のとおりです。
Oracle RTDリリース2.2.1では、Oracle RTDの学習プロセスの結果をデータベース・テーブルにコピーできます。この結果には、イベント件数、予測値、相関関係などが含まれます。簡単なSQLコマンドを使用すると、このデータベース・テーブルからレポートを生成できます。この機能は、モデルのスナップショットと呼ばれています。
各インライン・サービスは1つのスタディ名に関連付けられます。また、各インライン・サービスには、1つ以上のモデルを持つことができます。学習プロセスのデータは、スタディ内の各モデルに適用されます。モデルのスナップショット機能を使用すると、スタディに対するすべてのモデル結果をデータベースにダンプできます。
|
注意: 厳密に言うと、保存されるデータに該当する正確な用語は、モデルのスナップショットではなく、スタディのスナップショットです。この項では、便宜上の理由により、これらの2つの用語を同義語として使用します。 |
モデルのスナップショットの設定および使用の概要
モデルのスナップショットの設定および使用プロセスには、次の4つの主要な段階があります。
モデルのスナップショット・テーブルの構成。
Oracle RTDの学習データを関連付けられたモデルに追加するための、1つ以上のアプリケーションの実行。
この段階では、モデルのスナップショット・テーブルは明示的に使用されず、次の段階で使用するデータが用意されます。
学習データからのモデルのスナップショット・テーブルの移入と、必要に応じたテーブルの消去。
モデルのスナップショット・テーブルからのレポートの作成。
Oracle RTDリリース2.2.1では、モデルのスナップショットに関連する2つの新しいシステム・パラメータが追加されています。詳細は、第3.8項「モデルのスナップショット・プロセスのチューニング」を参照してください。
図3-1に、モデルのスナップショット・テーブルとその列、およびテーブル間の関係を表すコネクタ線を示します。
各コネクタは、上部のテーブルから下位のテーブルへの関係が、1対多関係であることを示しています。逆に、下部のテーブルから上部のテーブルへの関係は1対1になります。
たとえば、RTDStudyからRTDAppへの関係は1対多です。一方、RTDAppからRTDStudyへの関係は1対1です。これは、各スタディは1つ以上のアプリケーションを持てるが、各アプリケーションは1つのスタディしか持てないという実世界の条件に対応しています。本番環境では、1つのスタディに対して1つのアプリケーションのみを使用してください。
|
注意: この項では、アプリケーションという用語がインライン・サービスと同義で使用されています。たとえば、RTDAppテーブルには、Oracle RTDアプリケーション、つまりOracle RTDのインライン・サービスに関する情報が格納されます。 |
各テーブルの要素間には、次の1対多関係があります（1対多の関係は、逆方向では1対1の関係になります）。
各スタディは、1つ以上のアプリケーションと1つ以上のモデルを持てます。
各アプリケーションは、1つ以上の選択肢グループと1つ以上の選択肢を持てます。
各選択肢グループは、1つ以上の選択肢を持てます。
各選択肢、イベントおよびモデルは、1つ以上のモデル・インスタンスを持てます。
モデル・インスタンスと3つの属性（パーティション、予測および相関関係）の間には、多対多関係があります。
各テーブルの列名とその説明は次のとおりです。
RTDApp
| 列 | 説明 |
|---|---|
| id | 主キー。 |
| study_id | RTDStudyへの外部キー。 |
| name | アプリケーション名。 |
RTDAttribute
| 列 | 説明 |
|---|---|
| id | 主キー。 |
| name | 属性名。 |
| path | セッションのルートからこの属性へのアクセス方法を示す区切り記号付きの属性名。 |
RTDChoice
| 列 | 説明 |
|---|---|
| id | 主キー。 |
| app_id | RTDAppへの外部キー。 |
| internal_name | 選択肢の内部名。 |
| display_name | 選択肢の表示名。 |
| choicegroup_id | RTDChoiceGroupへの外部キー。 |
RTDChoiceGroup
| 列 | 説明 |
|---|---|
| id | 主キー。 |
| app_id | RTDAppへの外部キー。 |
| internal_name | 選択肢グループの内部名。 |
| display_name | 選択肢グループの表示名。 |
RTDCorrelation
| 列 | 説明 |
|---|---|
| model_instance_id | RTDModelInstanceへの外部キー。 |
| attribute_id | RTDAttributeへの外部キー。 |
| count_output_input | 移入する入力データで、この出力属性値が検出された件数。 |
| correlation | -1〜1の値。正の相関関係は、入力属性値の出力値への関係の度合いを表し、負の相関関係は、関係がないことを示します。 |
| count_input | 移入において、この入力属性値が検出された件数。 |
| value | 入力属性の値。 |
RTDEvent
| 列 | 説明 |
|---|---|
| id | 主キー。 |
| name | イベント名。 |
RTDModel
| 列 | 説明 |
|---|---|
| id | 主キー。 |
| name | モデル名。 |
| study_id | RTDStudyへの外部キー。 |
RTDModelInstance
| 列 | 説明 |
|---|---|
| id | 主キー。 |
| state | モデルの状態。
指定可能な値は次のとおりです。 c: 完了。モデルは完了しているため変更できません（以前の時間枠などで指定する）。完全ダンプを実行するか、ダンプを削除して増分ダンプを実行するまで、再書込み不能です。 d: 複合。モデルは、現行と以前の時間枠を対象としています。 s: 分割。モデルは、現行時間枠を対象としています。 w: 書込み中。モデルは現在書き込み中です。結果に一貫性がない場合があります。 |
| model_id | RTDModelへの外部キー。 |
| choice_id | RTDChoiceへの外部キー。 |
| event_id | RTDEventへの外部キー。 |
| count_total | ベース・イベントの合計件数。 |
| count_positive | この非ベース・イベントが記録された移入のサブセットのサイズ。 |
| time_window_start | 時間枠の開始。 |
| time_window_end | 時間枠の終了。 |
| quality | モデルの品質。0〜1の値で、1に近いほど質が高く、0は未学習を表します。 |
RTDPartition
| 列 | 説明 |
|---|---|
| model_instance_id | RTDModelInstanceへの外部キー。 |
| attribute_id | RTDAttributeへの外部キー。 |
| value | パーティションを表す属性値。 |
RTDPredictiveness
| 列 | 説明 |
|---|---|
| model_instance_id | RTDModelInstanceへの外部キー。 |
| attribute_id | RTDAttributeへの外部キー。 |
| predictiveness | 特定のモデル・インスタンスに対する入力属性を評価するスコア。0〜1の値で、1に近いほど有効であることを表します。 |
RTDStudy
| 列 | 説明 |
|---|---|
| id | 主キー。 |
| name | スタディ名。 |
この段階の主要な目的は、モデルのスナップショット・テーブルを作成し、それをアプリケーション・サーバーおよびJMX MBeansに登録することです。
モデルのスナップショット・テーブルを構成する手順は次のとおりです。
モデルのスナップショット・テーブルを格納するデータベースを選択します。
|
注意: スナップショット・テーブルはSDDBデータベースに格納することもできますが、本番システムでは格納しないでください。 |
RTD_HOME\scriptsディレクトリから、次のコマンドを実行してモデルのスナップショット・テーブルを作成します。
sdexec com.sigmadynamics.tools.SDDBTool.SDDBTool -f -i -I InitSnapshotDb.ctl db_type db_host db_port db_name db_runtime_user db_admin_user db_admin_password
sdexecスクリプトのパラメータについて、次の表で説明します。
| パラメータ | 説明 |
|---|---|
db_type |
データベースの種類。
oracle、sqlserverまたはdb2のいずれかを選択します。 |
db_host |
データベース・サーバーをホスティングするコンピュータの名前。 |
db_port |
データベースのポート番号。 |
db_name |
データベースの名前（Oracleデータベースの場合はSID）。 |
db_runtime_user脚注1 |
システムのランタイム・ユーザーのユーザー名。 |
db_admin_user |
データベースでテーブルおよびストアド・プロシージャを作成する権限を持つユーザーの名前。 |
db_admin_password |
管理者ユーザーのパスワード。 |
脚注1 Oracleデータベースの場合は、db_runtime_userとdb_admin_userは同じユーザーになります。
アプリケーション・サーバーに、モデルのスナップショット・テーブルの格納先であるデータベースを参照する新しいデータソースを作成します。
アプリケーション・サーバーにおけるデータソースの作成方法の詳細は、『Oracle Real-Time Decisionsインストレーションおよび管理ガイド』の「Oracle Real-Time Decisionsのデータ・アクセスの構成」を参照してください。
新しいデータソースを作成する際には、この後の手順で使用する新しいJNDI名を指定する必要があります。
新しいデータソースをOracle RTDに追加します。
新しいデータソースをOracle RTDに追加する手順は、アプリケーション・サーバーの種類によって異なります。
ご使用のアプリケーション・サーバーの手順を、次の中から選択します。
アプリケーション・サーバーがOC4Jの場合は、手順5に進みます。
アプリケーション・サーバーがWebSphereの場合は、手順11に進みます。
アプリケーション・サーバーがWebLogicの場合は、手順14に進みます。
Oracle RTDへのデータソースの追加手順: OC4Jの場合
Oracle RTDがスタンドアロンのOC4J上で実行されている場合は、ディレクトリOC4J_HOME/j2ee/home/applications/OracleRTDに移動します。Oracle RTDがOracle Application Serverで実行されている場合は、ORACLE_AS_HOME/j2ee/oc4j_instance/applications/OracleRTDに移動します。
このディレクトリは、Oracle RTDをアプリケーションとしてデプロイしたときのRTD.earファイルの展開先です。
ファイル./ls/WEB-INF/web.xmlを探し、web.xmlを開いて編集します。ファイルの下部にスクロールします。SDDSのリソース参照を定義しているコード・セクションをコピーして、既存のセクションの後ろに貼り付けます。コピーしたセクションで、文字列SDDSを、手順3で入力したJNDI名（jndi_name）に置き換えます。
次に例を示します。
<resource-ref id="jndi_name_LS"> <res-ref-name>jndi_name</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> <res-sharing-scope>Unshareable</res-sharing-scope> </resource-ref>
変更を保存して、ファイルを閉じます。
ディレクトリOC4J_HOME/j2ee/home/application-deployments/OracleRTDに移動します。この場合、applicationsディレクトリではなく、application-deploymentsディレクトリに移動することに注意してください。
ファイル./ls/WEB-INF/orion-web.xmlを探し、web.xmlを開いて編集します。ファイルの下部にスクロールします。SDDSのリソース参照マッピングを定義している行をコピーして、既存の行の後ろに貼り付けます。コピーした行で、文字列SDDSを、手順3で入力したJNDI名（jndi_name）に置き換えます。次に例を示します。
<resource-ref-mapping name="jndi_name" location="jndi_name"/>
変更を保存して、ファイルを閉じます。
OC4Jを起動します。
手順16に進みます。
Oracle RTDへのデータソースの追加手順: WebSphereの場合
次のファイルを開いて編集します。
WEBSPHERE_HOME/AppServer/profiles/profile_name/config/cells/server_name/ applications/OracleRTD.ear/deployments/OracleRTD/ls.war/WEB-INF/web.xml
次の手順に従って、新しい<resource-ref>エントリを作成します。
Oracle RTD Database（SDDS）の既存の<resource-ref>エントリをコピーして、その直下に貼り付けます。
SDDSエントリと同様に、識別可能な値（末尾に_LSを付加）を入力してid属性を変更します。idの値はファイル内で一意である必要があります。
手順3で指定したJNDI名（jndi_name）を入力して、<res-ref-name>タグを変更します。
次に例を示します。
<resource-ref id="jndi_name_LS"> <res-ref-name>jndi_name</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> <res-sharing-scope>Unshareable</res-sharing-scope> </resource-ref>
変更を保存して、ファイルを閉じます。
手順16に進みます。
Oracle RTDへのデータソースの追加手順: WebLogicの場合
インストール時にRTD.earファイルを展開したディレクトリ（RTD_HOME/package/expanded）に移動します。
ls.warアーカイブを開いてweb.xmlを抽出し、web.xmlを開いて編集します。ファイルの下部にスクロールします。SDDS_LSのリソース参照を定義しているコード・セクションをコピーして、既存のセクションの後ろに貼り付けます。コピーしたセクションで、文字列SDDSを、手順3で入力したJNDI名（jndi_name）に置き換えます。
次に例を示します。
<resource-ref id="jndi_name_LS"> <res-ref-name>jndi_name</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> <res-sharing-scope>Unshareable</res-sharing-scope> </resource-ref>
変更内容を保存してファイルを閉じ、ファイルを元のls.war.に再びアーカイブします。
手順16に進みます。
J2SEコンソールで、新しいデータソースの名前をOracleRTD MBeansに登録します。
「MBeans」→「OracleRTD」→「SDClusterPropertyManager」→「Misc」にナビゲートします。
ModelSnapshotDSName属性で、モデルのスナップショット用に作成したデータソースの名前を指定します。
図3-2に、J2SEコンソールのModelSnapshotDSName属性で指定されている、モデルのスナップショットのデータソース名SDDMを示します。
Oracle RTDを使用するアプリケーションでは通常、日常的な操作手順の一環としてモデル学習のアクティブ化が構成されています。
Oracle RTDのモデル学習をアクティブ化する場合、コール元アプリケーションを実行するだけで済みます。アプリケーションで適切な操作が実行され、Oracle RTDのモデル学習プロセスにデータを送信するプロシージャがトリガーされます。デフォルトでは、セッションの終了時に、すべてのモデルで学習が行われます。
モデルの学習データのスナップショットは、予測に必要なデータが十分に蓄積されていない場合も含めて、いつでも取得できます。
各モデルには、週、月、四半期などの時間枠が定義されています。時間枠は、学習プロセスにおいて収集されるデータ量を決定し、モデルのスナップショット・テーブルに書き込まれるデータ量に影響を与えます。
スナップショット・テーブルに書き込まれるデータの量は、次のオプションから選択できます。
スタディに対する、モデルの全学習データ
現行の時間枠のスタディに対する、モデルの全学習データ
また、モデルのスナップショット・テーブルから、スタディに対するモデルの全学習データを削除することもできます。
モデルのスナップショット・テーブルを移入または消去する手順は次のとおりです。
J2SEコンソールで、「MBeans」→「OracleRTD」→「Learning Server」→「スタディ名」にナビゲートします。
「Operations」タブをクリックします。
図3-3に、J2SEコンソールのCrossSellスタディに対して指定されているモデルのスナップショット操作を示します。
必要なスナップショット・オプションをクリックします。
CompleteSnapshot
スタディのこれまでに取得された全データを削除し、現時点までのすべてのスタディ・データを再書き込みします。
IncrementalSnapshot
未完了の時間枠のスタディ・データを削除し、現時点までの現行時間枠のデータを再書き込みします。
DeleteSnapshot
スタディに対して取得された全データを削除します。
モデルのスナップショット・テーブルからのレポート作成では通常、標準のSQL Selectコマンドを使用します。
この項では、モデルの複数のスナップショット・テーブルから情報を抽出するスクリプトの例を示します。各スクリプト例の後には、サンプル出力が続きます。また、一部の例には、実行結果の解釈に役立つ注釈があります。
これらの例で使用されるインライン・サービスは、CrossSellアプリケーションです。また、データは、400,000ユーザー・セッションをシミュレートしたOracle RTD Load Generatorスクリプトを実行して生成されています。
次のクエリーは、選択肢別のカウントをすべての時間枠で取得します。
select g.display_name as 'Choice Group',
c.display_name as 'Choice',
e.name as 'Event',
mi.timewindow_start as 'Start',
mi.timewindow_end as 'End',
mi.state as 'Model Status',
m.name as 'Model Name',
mi.count_total,
mi.count_positive,
mi.quality
from RTDApp a
inner join RTDStudy s on s.id=a.study_id
inner join RTDModel m on m.study_id=s.id
inner join RTDModelInstance mi on mi.model_id=m.id
inner join RTDEvent e on mi.event_id=e.id
inner join RTDChoice c on c.id=mi.choice_id
inner join RTDChoiceGroup g on c.choicegroup_id=g.id
where a.name='CrossSell'
order by m.name,
g.display_name,
c.display_name,
mi.timewindow_start
図3-4に、選択肢別のカウントのクエリー結果を示します。
選択肢別のカウントのクエリー結果についての注釈
行13では、ChoiceがGold Card、EventがInterested、count_totalが477、count_positiveが19、qualityが0.0になっています。これは、Gold Cardオファーが提示された477ユーザーのうち、19人が興味を示したことを意味します。このカウントは少ないため、Gold Card選択肢とInterestedイベントに関するモデル品質は0になります。
行14では、ChoiceがGold Card、EventがPurchased、count_totalが477、count_positiveが1、qualityが0.0になっています。これは、1人のユーザーがこのオファーを購入したことを意味します。Gold Card選択肢とPurchasedイベントに関するモデル品質は0になります。
行13および行14の有効期間は、両方とも2003年4月1日〜2003年7月1日です。
Choice Group列とChoice列の値BASE EVENTは、全般的または全体的なオファーを意味します。
たとえば、行1では、ChoiceがBASE EVENT、EventがInterested、count_totalが24917、count_positiveが1663、qualityがおよそ0.6882になっています。これは、開始日から終了日までの期間に、合計24917ユーザーがオファーを提示され、その中の1663人が興味を示したことを意味します。この期間のモデル全体の品質はおよそ0.69になります。
行2では、ChoiceがBASE EVENT、EventがPurchased、count_totalが24917、count_positiveが220、qualityがおよそ0.5666になっています。これは、行1と同じ期間において、すべての選択肢に対して合計220の購入イベントがあり、モデル品質がおよそ0.57であることを意味します。
次のクエリーは、Credit Protection選択肢のPurchasedイベントに対する上位6位の予測属性を時間枠ごとに選択します。
select a.name 'Attribute Name',
p.predictiveness 'Predictiveness',
c.display_name 'Choice Name',
mi.timewindow_start as 'Start',
mi.timewindow_end as 'End',
mi.state as 'Model Status'
from RTDApp app
inner join RTDChoice c on c.app_id=app.id
inner join RTDStudy s on s.id=app.study_id
inner join RTDModel m on m.study_id=s.id
inner join RTDModelInstance mi on mi.model_id=m.id and mi.choice_id=c.id
inner join RTDEvent e on mi.event_id=e.id
inner join RTDPredictiveness p on p.model_instance_id=mi.id
inner join RTDAttribute a on a.id=p.attribute_id
where app.name = 'CrossSell'
and c.display_name = 'Credit Protection'
and e.name = 'Purchased'
and m.name = 'OfferAcceptance'
and 7 > (select count(*)
from RTDPredictiveness p2
where p2.model_instance_id = p.model_instance_id
and p2.predictiveness > p.predictiveness)
order by mi.timewindow_end desc,
p.predictiveness desc
図3-5に、上位6位の予測属性のクエリー結果を示します。
次のクエリーは、クレジット保護の購入が期待される顧客数と実際に購入した顧客数を、婚姻ステータス別に示します。また、これら2つの値の間の差異と、オファーの受入れにおける相関関係の重要度も示します。
select cor.value 'customer MaritalStatus',
cor.count_output_input 'Actual Count',
mi.count_positive*cor.count_input/mi.count_total 'Expected Count',
(100*(mi.count_positive*cor.count_input/mi.count_total
- cor.count_output_input))/cor.count_output_input 'Percent Difference',
cor.correlation 'Importance',
c.display_name 'Choice Name',
mi.timewindow_start as 'Start',
mi.timewindow_end as 'End',
mi.state as 'Model Status'
from RTDApp app
inner join RTDChoice c on c.app_id=app.id
inner join RTDStudy s on s.id=app.study_id
inner join RTDModel m on m.study_id=s.id
inner join RTDModelInstance mi on mi.model_id=m.id and mi.choice_id=c.id
inner join RTDEvent e on mi.event_id=e.id
inner join RTDCorrelation cor on cor.model_instance_id=mi.id
inner join RTDAttribute a on a.id = cor.attribute_id
where app.name = 'CrossSell'
and c.display_name = 'Credit Protection'
and e.name = 'Purchased'
and m.name = 'OfferAcceptance'
and a.name = 'customer MaritalStatus'
order by mi.timewindow_end desc,
cor.correlation desc
期待カウントと実カウントの差異のクエリーについての注釈
Actual Count（cor.count_output_input）は、クレジット保護を実際に購入した顧客の婚姻ステータス別の人数です。
Expected Count（cor.count_input）は、mi.count_positive/mi.count_totalの計算式で算出される、婚姻ステータス別の合計カウントに関する単純な線形予測です。
Percent Differenceは、「100×（期待カウント−実カウント）/実カウント」の計算式で算出されます。
図3-6に、期待カウントと実カウントの差異のクエリー結果を示します。
期待カウントと実カウントの差異のクエリー結果についての注釈
婚姻ステータスごとに2つの行があり、それぞれが2003年4月1日〜2003年7月1日と2003年7月1日〜2003年10月1日のいずれかの時間枠に対応しています。
RTDPartitionテーブルには、パーティション化属性が保持されます。モデルがパーティション化されていない場合、モデルは時間枠ごとに1つのモデル・インスタンスを持ち、RTDPartitionテーブルには関連する行がありません。
1つ以上のディメンションに沿って分割したモデルは、パーティション化されたモデルと呼ばれます。
たとえば、モデルMを、婚姻ステータスと好きな飲み物という2つの属性によってパーティション化するとします。婚姻ステータスに3つの値（既婚、未婚、離婚）、好きな飲み物に2つの値（コーヒー、ティー）がある場合、このモデルには6つのモデル・インスタンスがあります。
この場合、各モデル・インスタンスはRTDPartitionテーブルに、関連する2つの行を持ちます。たとえば、婚姻ステータスが既婚で、好きな飲み物がコーヒーという組合せに対応するモデル・インスタンスは、次の情報を保持するRTDPartitionの2つの行に関連付けられます。
RTDPartitionの行1: 属性=婚姻ステータス、値=既婚
RTDPartitionの行2: 属性=好きな飲み物、値=コーヒー
モデルのパーティション化の有無は、モデルのスナップショット・テーブルのクエリー結果に影響を与える場合があります。結果から繰返しを排除するには、クエリー内でRTDPartitionとRTDAttributeの結合条件を指定してください。
次の例は、期待カウントと実カウントの差異のクエリーを変更および拡張したもので、モデルがDiabetic（yesまたはno値を持つ）とMarital Statusという2つの属性でパーティション化されています。
select a.name,
p.value,
subquery.*
from (select cor.value 'Favorite Sports',
cor.count_output_input 'Actual Count',
mi.count_positive*cor.count_input/mi.count_total 'Expected Count',
(100*(mi.count_positive*cor.count_input/mi.count_total
- cor.count_output_input))/cor.count_output_input 'Percent Difference',
cor.correlation 'Importance',
c.display_name 'Choice Name',
mi.timewindow_start as 'Start',
mi.timewindow_end as 'End',
mi.state as 'Model Status'
mi.id model_instance_id
from RTDApp app
inner join RTDChoice c on c.app_id=app.id
inner join RTDStudy s on s.id=app.study_id
inner join RTDModel m on m.study_id=s.id
inner join RTDModelInstance mi on mi.model_id=m.id and mi.choice_id=c.id
inner join RTDEvent e on mi.event_id=e.id
inner join RTDCorrelation cor on cor.model_instance_id=mi.id
inner join RTDAttribute a on a.id = cor.attribute_id
where app.name = 'HighlyPartitionedDataset'
and c.display_name = 'Fanta'
and e.name = 'loved'
and m.name = 'SatisfactionModel'
and a.name = 'Favorite Sports') as subquery
inner join RTDPartition p on subquery.model_instance_id = p.model_instance_id
inner join RTDAttribute a on p.attribute_id = a.id
order by subquery.[End] desc,
subquery.model_instance_id,
a.name,
p.value
subquery.[Importance] desc
図3-7に、パーティション化された期待カウントと実カウントのクエリー結果を示します。
Oracle RTDリリース2.2.1では、モデルのスナップショット・プロセスをチューニングする2つの新しいシステム・プロパティが提供されています。
ModelSnapshotMinAbsCorrelationは、すべての相関行をダンプするか、相関関係の最小値を設定してダンプを制御するかどうかを指定します。デフォルト値の0.000001では、相関関係が非常に低い行のダンプが回避されます。すべての相関行をダンプするには、この値を0に設定します。
ModelSnapshotNumberOfBinsは、モデルのスナップショットのビン数を制御します。数値型の属性値は自動的にビニングされます（つまり、数値範囲に割り当てられます）。デフォルトのビン数は5つです。数値データの精度を上げるには、ビン数を増やします。
|
注意: 別の時間枠では、同じ数値属性に対して別のビンが作成されます。そのため、数値型の属性値は、複数の時間枠にまたがって結合できない可能性があります。 |
システム・プロパティの値を変更する場合は、アプリケーション・サーバーのサーバー・プロパティとして設定します。アプリケーション・サーバーにおけるサーバー・プロパティの構成方法の詳細は、『Oracle Real-Time Decisionsインストレーションおよび管理ガイド』を参照してください。
WebSphereとOC4Jの場合、JVM引数を編集します。WebLogicの場合は、Javaオプションを編集します。たとえば、パラメータ-DModelSnapshotNumberOfBins=10をWebSphereとOC4JのJVM引数に、またはWebLogicのJavaオプションに追加します。
