特表 2024-505522 自動モデル生成におけるモデルデプロイメントのモデル適合性および安定性の判定のためのシステムならびに方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-02-06

(54)【発明の名称】自動モデル生成におけるモデルデプロイメントのモデル適合性および安定性の判定のためのシステムならびに方法

(51)【国際特許分類】

   G06Q 40/06 20120101AFI20240130BHJP

【ＦＩ】

G06Q40/06

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023545824

(86)(22)【出願日】2022-01-28

(85)【翻訳文提出日】2023-09-27

(86)【国際出願番号】 US2022014418

(87)【国際公開番号】W WO2022165253

(87)【国際公開日】2022-08-04

(31)【優先権主張番号】63/142,826

(32)【優先日】2021-01-28

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】17/586,639

(32)【優先日】2022-01-27

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

(71)【出願人】

【識別番号】502303739

【氏名又は名称】オラクル・インターナショナル・コーポレイション

(74)【代理人】

【識別番号】110001195

【氏名又は名称】弁理士法人深見特許事務所

(72)【発明者】

【氏名】アグラワル，ビカス

(72)【発明者】

【氏名】ラーマナータン，クリシュナン

(72)【発明者】

【氏名】シシュトラ，プラニース

(72)【発明者】

【氏名】チャンド，ジャグディシュ

【テーマコード（参考）】

5L055

【Ｆターム（参考）】

5L055BB57

(57)【要約】

一実施形態によると、本明細書に記載するのは、モデルデプロイメントおよび自動モデル生成について、モデル適合性および安定性の判定を提供するための、コンピューティング環境と共に使用するシステムおよび方法である。モデル適合性・安定性コンポーネントは、特定のアプリケーションについてモデル適合性および安定性を判定するために、モデルの選択、モデルデプロイ可能性スコア・デプロイ可能性フラグの使用、およびモデルドリフトリスクの軽減をサポートする１つ以上の機能を提供することができる。たとえば、実施形態は、分析アプリケーション、データアナリティクス、または他のタイプのコンピューティング環境と共に使用されて、たとえば、金融アプリケーションまたは他のタイプのアプリケーションにおいて、直接実行可能なリスク予測を提供し得る。

【特許請求の範囲】

【請求項1】

自動モデル生成におけるモデルデプロイメントについて、モデル適合性および安定性を判定するシステムであって、
１つ以上のマイクロプロセッサを含むコンピュータ、および前記コンピュータ上で動作するデータアナリティクスクラウドまたは他のコンピューティング環境を備え、
前記１つ以上のマイクロプロセッサは、
前記データアナリティクスクラウドにおいて、複数のモデルを提供し、
前記データアナリティクスクラウドにおけるデータのセットに基づいて、前記複数のモデルのセットをスコアリングし、
前記スコアリングに基づいて、前記複数のモデルのセットのうちのモデルを選択し、
不安定性またはドリフトの兆候について、前記モデルを監視するように動作する、システム。

【請求項2】

前記複数のモデルのセットをスコアリングすることは、前記複数のモデルのセットの各々について、
前記モデルの予測を、確率ビンのセットのうちの確率ビンに自動的に割り当てることと、
逐次的確率ビンの間の正分類の逐次差分を決定することと、
逐次的確率ビンの間の正分類の逐次差分の各々に、重みを適用することとを含み、
正分類の逐次差分の各々に適用される前記重みは、前記重みが適用される前記確率ビンに従属する、請求項１に記載のシステム。

【請求項3】

前記重みは、より高確率のビンほど大きくなる、請求項２に記載のシステム。

【請求項4】

前記複数のモデルのセットをスコアリングすることはさらに、前記複数のモデルのセットの各々について、
確率ビンの各々の分類に失敗するごとに、ペナルティを適用することと、
失敗した分類ごとに、適用されたペナルティの各々に、ペナルティの重みを適用することとを含む、請求項３に記載のシステム。

【請求項5】

前記ペナルティの重みは、より高確率のビンほど大きくなる、請求項４に記載のシステム。

【請求項6】

前記複数のモデルのセットをスコアリングすることはさらに、前記複数のモデルのセットの各々について、
生成されたスコアを、分類されたサンプルの数で正規化することを含む、請求項５に記載のシステム。

【請求項7】

不安定性またはドリフトの兆候について、前記モデルを監視することは、
モデルの劣化の１つ以上のシグナルを検出することと、
同じ事前分類を有するインスタンスのクラスタまでの、前記モデルによって生成される各インスタンスの距離を決定することと、
前記モデルの新しいバージョンにおいて、最近傍の少なくとも１つ以上が反転分類を有していると判定することと、
前記モデルによって生成されたインスタンスの総数のうち、前記反転分類の割合を決定することと、
決定された前記割合が第１の閾値を超えると、前記モデルをわずかに不安定であるとタグ付けすることと、
決定された前記割合が第２の閾値を超えると、前記モデルを不安定であるとタグ付けすることとを含む、請求項１に記載のシステム。

【請求項8】

自動モデル生成におけるモデルデプロイメントについて、モデル適合性および安定性を判定する方法であって、
１つ以上のマイクロプロセッサを含むコンピュータ、および前記コンピュータ上で動作するデータアナリティクスクラウドまたは他のコンピューティング環境を提供することと、
前記データアナリティクスクラウドにおいて、複数のモデルを提供することと、
前記データアナリティクスクラウドにおけるデータのセットに基づいて、前記コンピュータが、前記複数のモデルのセットをスコアリングすることと、
前記コンピュータが、前記スコアリングに基づいて、前記複数のモデルのセットうちのモデルを選択することと、
前記コンピュータが、不安定性またはドリフトの兆候について、前記モデルを監視することとを含む、方法。

【請求項9】

前記複数のモデルのセットをスコアリングすることは、前記複数のモデルのセットの各々について、
前記モデルの予測を、確率ビンのセットのうちの確率ビンに自動的に割り当てることと、
逐次的確率ビンの間の正分類の逐次差分を決定することと、
逐次的確率ビンの間の正分類の逐次差分の各々に、重みを適用することとを含み、
正分類の逐次差分の各々に適用される前記重みは、前記重みが適用される前記確率ビンに従属する、請求項８に記載の方法。

【請求項10】

前記重みは、より高確率のビンほど大きくなる、請求項９に記載の方法。

【請求項11】

前記複数のモデルのセットをスコアリングすることはさらに、前記複数のモデルのセットの各々について、
確率ビンの各々の分類に失敗するごとに、ペナルティを適用することと、
失敗した分類ごとに、適用されたペナルティの各々に、ペナルティの重みを適用することとを含む、請求項１０に記載の方法。

【請求項12】

前記ペナルティの重みは、より高確率のビンほど大きくなる、請求項１１に記載の方法。

【請求項13】

前記複数のモデルのセットをスコアリングすることはさらに、前記複数のモデルのセットの各々について、
生成されたスコアを、分類されたサンプルの数で正規化することを含む、請求項１２に記載の方法。

【請求項14】

不安定性またはドリフトの兆候について、前記モデルを監視することは、
モデルの劣化の１つ以上のシグナルを検出することと、
同じ事前分類を有するインスタンスのクラスタまでの、前記モデルによって生成される各インスタンスの距離を決定することと、
前記モデルの新しいバージョンにおいて、最近傍の少なくとも１つ以上が反転分類を有していると判定することと、
前記モデルによって生成されたインスタンスの総数のうち、前記反転分類の割合を決定することと、
決定された前記割合が第１の閾値を超えると、前記モデルをわずかに不安定であるとタグ付けすることと、
決定された前記割合が第２の閾値を超えると、前記モデルを不安定であるとタグ付けすることとを含む、請求項８に記載の方法。

【請求項15】

１つ以上のコンピュータによって読み出され実行されると、前記１つ以上のコンピュータに方法を実行させる命令を格納した非一時的なコンピュータ読取可能記憶媒体であって、前記方法は、
１つ以上のマイクロプロセッサを含むコンピュータ、および前記コンピュータ上で動作するデータアナリティクスクラウドまたは他のコンピューティング環境を提供することと、
前記データアナリティクスクラウドにおいて、複数のモデルを提供することと、
前記データアナリティクスクラウドにおけるデータのセットに基づいて、前記複数のモデルのセットをスコアリングすることと、
前記スコアリングに基づいて、前記複数のモデルのセットうちのモデルを選択することと、
不安定性またはドリフトの兆候についてモデルを監視することとを含む、非一時的なコンピュータ読取可能記憶媒体。

【請求項16】

前記複数のモデルのセットをスコアリングすることは、前記複数のモデルのセットの各々について、
前記モデルの予測を、確率ビンのセットのうちの確率ビンに自動的に割り当てることと、
逐次的確率ビンの間の正分類の逐次差分を決定することと、
逐次的確率ビンの間の正分類の逐次差分の各々に、重みを適用することとを含み、
正分類の逐次差分の各々に適用される前記重みは、前記重みが適用される前記確率ビンに従属する、請求項１５に記載の非一時的なコンピュータ読取可能記憶媒体。

【請求項17】

前記重みは、より高確率のビンほど大きくなる、請求項１６に記載の非一時的なコンピュータ読取可能記憶媒体。

【請求項18】

前記複数のモデルのセットをスコアリングすることはさらに、前記複数のモデルのセットの各々について、
確率ビンの各々の分類に失敗するごとに、ペナルティを適用することと、
失敗した分類ごとに、適用されたペナルティの各々に、ペナルティの重みを適用することとを含み、
前記ペナルティの重みは、より高確率のビンほど大きくなる、請求項１７に記載の非一時的なコンピュータ読取可能記憶媒体。

【請求項19】

前記複数のモデルのセットをスコアリングすることはさらに、前記複数のモデルのセットの各々について、
生成されたスコアを、分類されたサンプルの数で正規化することを含む、請求項１８に記載の非一時的なコンピュータ読取可能記憶媒体。

【請求項20】

不安定性またはドリフトの兆候について、前記モデルを監視することは、
モデルの劣化の１つ以上のシグナルを検出することと、
同じ事前分類を有するインスタンスのクラスタまでの、前記モデルによって生成される各インスタンスの距離を決定することと、
前記モデルの新しいバージョンにおいて、最近傍の少なくとも１つ以上が反転分類を有していると判定することと、
前記モデルによって生成されたインスタンスの総数のうち、前記反転分類の割合を決定することと、
決定された前記割合が第１の閾値を超えると、前記モデルをわずかに不安定であるとタグ付けすることと、
決定された前記割合が第２の閾値を超えると、前記モデルを不安定であるとタグ付けすることとを含む、請求項１５に記載の非一時的なコンピュータ読取可能記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

優先権の主張
本願は、２０２１年１月２８日に出願された「ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＤＥＴＥＲＭＩＮＡＴＩＯＮ ＯＦ ＭＯＤＥＬ ＦＩＴＮＥＳＳ ＡＮＤ ＳＴＡＢＩＬＩＴＹ ＦＯＲ ＭＯＤＥＬ ＤＥＰＬＯＹＭＥＮＴ ＩＮ ＡＵＴＯＭＡＴＥＤ ＭＯＤＥＬ ＧＥＮＥＲＡＴＩＯＮ（自動モデル生成におけるモデルデプロイメントのモデル適合性および安定性の判定のためのシステムおよび方法）」と題する米国仮特許出願第６３／１４２，８２６号、および２０２２年１月２７日に出願された「ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＤＥＴＥＲＭＩＮＡＴＩＯＮ ＯＦ ＭＯＤＥＬ ＦＩＴＮＥＳＳ ＡＮＤ ＳＴＡＢＩＬＩＴＹ ＦＯＲ ＭＯＤＥＬ ＤＥＰＬＯＹＭＥＮＴ ＩＮ ＡＵＴＯＭＡＴＥＤ ＭＯＤＥＬ ＧＥＮＥＲＡＴＩＯＮ（自動モデル生成におけるモデルデプロイメントのモデル適合性および安定性の判定のためのシステムおよび方法）」と題する米国特許出願第１７／５８６，６３９号の優先権の利益を主張し、上記の出願の各々の内容は、引用により本明細書に援用する。

【0002】

技術分野
本明細書に記載する実施形態は、一般に、データモデル、データアナリティクス環境、ならびにモデルデプロイメントおよび自動モデル生成について、モデル適合性および安定性の判定を提供するためのシステムおよびに方法に関する。

【背景技術】

【0003】

背景
データアナリティクスをサポートするためのシステム、および特定の顧客の要件に対処するプロセス、たとえば顧客の金融アプリケーションにおいて売掛金を予測するプロセスに関して、異なる顧客は、その基礎となるデータ生成ビジネスプロセスの特性に近似する異なるモデルの生成を必要とする可能性があると推測される場合がある。

【0004】

このようなモデルは、顧客企業の異なる部門における同様のプロセスに対して異なる可能性がある。さらに、経時的に、データ生成ビジネスプロセスが変化し、それらのプロセスに対する入力の特徴的な分布も変化する可能性がある。

【発明の概要】

【課題を解決するための手段】

【0005】

要約
一実施形態によると、本明細書に記載するのは、モデルデプロイメントおよび自動モデル生成について、モデル適合性および安定性の判定を提供するための、コンピューティング環境と共に使用されるシステムおよび方法である。モデル適合性・安定性コンポーネントは、特定のアプリケーションのモデル適合性および安定性を判定するために、モデルの選択、モデルデプロイ可能性スコア・デプロイ可能性フラグの使用、ならびにモデルドリフトリスクの軽減をサポートする１つ以上の機能を提供し得る。たとえば、実施形態は、分析アプリケーション、データアナリティクス、または他のタイプのコンピューティング環境と共に使用されて、たとえば、金融アプリケーションまたは他のタイプのアプリケーションにおいて、直接実行可能なリスク予測を提供し得る。

【図面の簡単な説明】

【0006】

【図1】一実施形態に係る、例示的なデータアナリティクス環境を示す図である。

【図2】一実施形態に係る、例示的なデータアナリティクス環境をさらに示す図である。

【図3】一実施形態に係る、例示的なデータアナリティクス環境をさらに示すである。

【図4】一実施形態に係る、例示的なデータアナリティクス環境をさらに示す図である。

【図5】一実施形態に係る、例示的なデータアナリティクス環境をさらに示す図である。

【図6】一実施形態に係る、データアナリティクス環境に関連して使用される、モデル適合性および安定性の判定を示す図である。

【図7】一実施形態に係る、さまざまなモデルの確率スコアの比較例を示す図である。

【図8】一実施形態に係る、モデル適合性および安定性を判定するためのプロセスまたは方法を示す図である。

【図9】一実施形態に係る、モデル適合性および安定性を判定するためのプロセスまたは方法をさらに示す図である。

【図10】一実施形態に係る、インボイスのソートされたリストを説明する図である。

【図11】一実施形態に係る、データを分析するモデルの出力を説明する図である。

【図12】一実施形態に係る、自動モデル生成におけるモデルデプロイメントについて、モデル適合性および安定性を判定するための方法を示すフローチャートである。

【発明を実施するための形態】

【0007】

詳細な説明
上述したように、データアナリティクスをサポートするシステム、および特定の顧客の要件に対処する（たとえば、顧客の金融アプリケーションにおける売掛金を予測する）プロセスに関して、異なる顧客は、その基礎となるデータ生成ビジネスプロセスの特性に近似した異なるモデルの生成を必要とする可能性があると推測される場合がある。

【0008】

このようなモデルは、顧客企業の異なる部門における同様のプロセスに対して異なる可能性がある。さらに、経時的に、データ生成ビジネスプロセスが変化し、それらのプロセスへの入力の特性分布も変化する可能性がある。

【0009】

一実施形態によると、本明細書に記載するのは、モデルデプロイメントおよびモデル自動生成について、モデル適合性および安定性の判定を提供するための、コンピューティング環境と共に使用されるシステムおよび方法である。モデル適合性・安定性コンポーネントは、特定のアプリケーションのモデル適合性および安定性を判定するために、モデルの選択、モデルデプロイ可能性スコア・デプロイ可能性フラグの使用、およびモデルドリフトリスクの軽減をサポートする１つ以上の機能を提供することができる。

【0010】

さまざまな実施形態によると、記載するアプローチは、たとえば、以下のようなさまざまな考慮事項に対処するために使用することができる。

【0011】

手動方法は時間および金額において法外に高価であるため、モデル適合性は自動化によって恩恵を受ける。システムおよび方法がデータサンプルを使用して企業向けのモデルのクラスを作成する場合、何千もの顧客が存在し、各データセットの予測のつかない変化を手動で調べ、データに基づいてモデルを調整することは法外に高価であるため、システムは、事例ごとの顧客データを使用して、専門家のデータサイエンティストと手動でモデルを調整する機会を得られない。記載するアプローチは、特定のモデルクラスの広範なセットを使用する際に、顧客データセットから抽出可能な最大識別情報コンテンツを表すモデル適合性を、体系的に見つけることができる。

【0012】

さらに、スコアの使用は、経時的、部門横断的な変化を考慮した新しいモデルの自動生成を必要とし、人間の介入を必要とすることなく、適切なメトリクスを使用して何千もの潜在的なモデル候補を自動的にフィルタリングし、予測に基づいて最も重要な実用的洞察を見つける。記載するアプローチは、二値分類モデルの空間に関するこの特定の問題に対処し、マルチクラス分類に拡張することができる。

【0013】

モデルドリフトリスクは軽減されるべきである。モデル精度メトリクスは、訓練分布とテスト分布とのドリフトによって大きく変化する可能性があるが、システムおよび方法は、モデル選択の基準として、単にモデル精度メトリクスを使用することはできない。入力分布または特定の日もしくは週に採取された母集団のサンプルの分布が変化すると、昨日支払われた可能性が高いと分類されていたインボイスを、今日は支払われていない可能性が高いと分類するなど、複数のインスタンスで分類が逆転する程度にまで、新しいモデルでは決定境界に大きなドリフトが見られることが予想される。記載するアプローチは、スコアリング分布が訓練分布からどの程度シフトしているか、また訓練分布間のシフトが経時的にどの程度変化しているかを調べるために使用することができる。

【0014】

モデルは安定したものでなければならない。決定境界が毎日大幅にドリフトするほどモデルが不安定であることが検出された場合、これはモデルの適合に複数の問題があることを示している。このような場合、分類の判定は、個々のインスタンスのデータが変化しなくても、前日の予測を反転させるほど日々変化し続けることになる。記載するアプローチは、このような不安定性を検出するために使用することができる。

【0015】

データアナリティクス環境
一般に記載されるデータアナリティクスによって、データから結論またはその他の情報を導き出すために、大量のデータをコンピュータベースで調査または分析することが可能になる。一方、ビジネスインテリジェンスツール（ｂｕｓｉｎｅｓｓ ｉｎｔｅｌｌｉｇｅｎｃｅ：ＢＩ）は、組織のビジネスユーザに、ビジネスユーザが戦略的なビジネス上の意思決定を行えるような形式で、企業データを記述する情報を提供する。

【0016】

データアナリティクス環境およびビジネスインテリジェンスツール/サーバの例としては、Ｏｒａｃｌｅ Ｂｕｓｉｎｅｓｓ Ｉｎｔｅｌｌｉｇｅｎｃｅ Ｓｅｒｖｅｒ（ＯＢＩＳ），Ｏｒａｃｌｅ Ａｎａｌｙｔｉｃｓ Ｃｌｏｕｄ（ＯＡＣ），Ｏｒａｃｌｅ Ｆｕｓｉｏｎ Ａｎａｌｙｔｉｃｓ Ｗａｒｅｈｏｕｓｅ（ＦＡＷ）が挙げられ、これらは、データマイニングまたはアナリティクス、分析アプリケーションなどの機能をサポートする。

【0017】

図１は、一実施形態に係る例示的なデータアナリティクス環境を示す。
図１に示す例示的な実施形態は、本明細書に記載のさまざまな実施形態を使用可能なデータアナリティクス環境の例を示す目的で提供される。他の実施形態および例によると、本明細書に記載のアプローチは、他のタイプのデータアナリティクス、データベース、またはデータウェアハウス環境と共に使用することができる。図１に示し、他のさまざまな実施形態に関して本明細書にさらに記載するコンポーネントおよびプロセスは、たとえば、クラウドコンピューティングシステム、または他の適切にプログラムされたコンピュータシステムによって実行可能なソフトウェアもしくはプログラムコードとして提供され得る。

【0018】

図１に示すように、一実施形態によると、データアナリティクス環境１００は、コンピュータハードウェア（たとえば、プロセッサ、メモリ）１０１を有し、制御プレーン１０２、およびデータプレーン１０４として動作し、データウェアハウス、データウェアハウスインスタンス１６０（データベース１６１、または他のタイプのデータソース）へのアクセスを提供する１つ以上のソフトウェアコンポーネントを含むコンピュータシステムによって提供され得るか、または他の態様ではそのようなコンピュータシステムにおいて動作し得る。

【0019】

一実施形態によると、制御プレーンは、たとえば、Ｏｒａｃｌｅ（登録商標） Ａｎａｌｙｔｉｃｓ Ｃｌｏｕｄ環境、または他のタイプのクラウド環境などのＳａａＳもしくはクラウド環境のコンテキスト内で提供される、クラウドまたは他のソフトウェア製品の制御を提供するように動作する。たとえば、一実施形態によると、制御プレーンは、顧客（テナント）および／またはプロビジョニングコンポーネント１１１を有するクラウド環境によるアクセスを可能にするコンソールインターフェイス１１０を含み得る。

【0020】

一実施形態によると、コンソールインターフェイスは、グラフィカルユーザインターフェイス（ｇｒａｐｈｉｃａｌ ｕｓｅｒ ｉｎｔｅｒｆａｃｅ：ＧＵＩ）および／またはコマンドラインインターフェイス（ｃｏｍｍａｎｄ－ｌｉｎｅ ｉｎｔｅｒｆａｃｅ：ＣＬＩ）または他のインターフェイスを操作する顧客（テナント）によるアクセスを可能にすることができ、かつ／または、ＳａａＳもしくはクラウド環境のプロバイダおよびその顧客（テナント）によって使用されるインターフェイスを含み得る。たとえば、一実施形態によると、コンソールインターフェイスは、顧客がＳａａＳ環境内で使用するサービスをプロビジョニングし、プロビジョニングされたそれらのサービスを設定することを可能にするインターフェイスを提供することができる。

【0021】

一実施形態によると、顧客（テナント）は、データウェアハウス内の顧客スキーマのプロビジョニングを要求することができる。顧客はまた、コンソールインターフェイスを介して、必須属性（たとえば、ログイン認証情報）およびオプションの属性（たとえば、サイズまたは速度）を含む、データウェアハウスインスタンスに関連する多数の属性を提供することができる。次に、プロビジョニングコンポーネントは、データウェアハウスの顧客スキーマを含む要求されたデータウェアハウスインスタンスをプロビジョニングし、顧客によって供給された適切な情報を、データウェアハウスインスタンスにポピュレートすることができる。

【0022】

一実施形態によると、プロビジョニングコンポーネントは、たとえば、特定の顧客（テナント）について、要求されたＥＴＬプロセスの実行頻度を変更または更新することによって、データウェアハウスインスタンス、および／またはデータプレーンで動作するＥＴＬプロセスを、更新または編集するためにも使用できる。

【0023】

一実施形態によると、データプレーンは、データパイプラインまたはプロセス層１２０およびデータ変換層１３４を含むことができ、これらは一緒に、たとえば、顧客（テナント）のＳａａＳ環境でプロビジョニングされるビジネス生産性ソフトウェアアプリケーションなど、組織の企業ソフトウェアアプリケーションもしくはデータ環境からの運用データまたはトランザクションデータを処理する。データパイプラインまたはプロセスは、ＳａａＳ環境でプロビジョニングされるビジネスアプリケーションおよびデータベースからトランザクションデータを抽出し、変換されたデータをデータウェアハウスにロードするさまざまな機能を含み得る。

【0024】

一実施形態によると、データ変換層は、システムがＳａａＳ環境でプロビジョニングされるビジネスアプリケーションおよび対応するトランザクションデータベースから受信したトランザクションデータを、データアナリティクス環境によって理解されるモデル形式に変換するために使用する、たとえば知識モデル（ｋｎｏｗｌｅｄｇｅ ｍｏｄｅｌ：ＫＭ）などのデータモデル、または他のタイプのデータモデルを含み得る。モデル形式は、データウェアハウスへの格納に適した任意のデータ形式で提供することができる。一実施形態によると、データプレーンは、データ設定ユーザインターフェイス、ならびにマッピング設定データベースも含み得る。

【0025】

一実施形態によると、データプレーンは、たとえば、ＳａａＳ環境で提供されるビジネス生産性ソフトウェアアプリケーションおよび対応するトランザクションデータベースなどの組織の企業ソフトウェアアプリケーションまたはデータ環境からトランザクションデータを抽出し、抽出されたデータをモデル形式に変換し、変換されたデータをデータウェアハウスの顧客スキーマにロードすることを含む、抽出、変換、およびロード（ｅｘｔｒａｃｔ，ｔｒａｎｓｆｏｒｍ，ｌｏａｄ：ＥＴＬ）動作を実行する役割を担う。

【0026】

たとえば、一実施形態によると、環境の各顧客（テナント）は、データウェアハウス（自身の顧客スキーマと関連付けられている）内の自身の顧客テナンシと関連付けることができ、さらに、データアナリティクススキーマへの読取り専用アクセスを提供することができ、それは、データパイプラインまたはプロセス、たとえば、ＥＴＬプロセスによって、定期的またはその他のベースで更新することができる。

【0027】

一実施形態によると、データパイプラインまたはプロセスは、たとえば、ＳａａＳ環境においてプロビジョニングされるビジネス生産性ソフトウェアアプリケーションおよび対応するトランザクションデータベース１０６などの企業ソフトウェアアプリケーションまたはデータ環境から、トランザクションデータを抽出するために、間隔をおいて（たとえば、毎時／毎日／毎週）実行するようにスケジュールすることができる。

【0028】

一実施形態によると、抽出プロセス１０８は、トランザクションデータを抽出することができ、抽出時に、データパイプラインまたはプロセスは、抽出されたデータをデータステージング領域に挿入することができ、このデータステージング領域は、抽出されたデータの一時的なステージング領域として機能することができる。データ品質コンポーネントおよびデータ保護コンポーネントは、抽出されたデータの完全性を保証するために使用することができる。たとえば、一実施形態によると、データ品質コンポーネントは、データがデータステージング領域に一時的に保持されている間、抽出されたデータに対して検証を実行することができる。

【0029】

一実施形態によると、抽出プロセスが抽出を完了すると、データ変換層は、抽出されたデータをデータウェアハウスの顧客スキーマにロードされるモデル形式に変換する変換プロセスを開始するために、使用することができる。

【0030】

一実施形態によると、データパイプラインまたはプロセスは、データ変換層と一緒に動作して、データをモデル形式に変換することができる。マッピング設定データベースは、データ変換によって使用されるデータモデルを定義するメタデータおよびデータマッピングを格納することができる。データ設定ユーザインターフェイス（ｕｓｅｒ ｉｎｔｅｒｆａｃｅ：ＵＩ）は、マッピング設定データベースへのアクセスおよび変更を容易にすることができる。

【0031】

一実施形態によると、データ変換層は、抽出されたデータを、たとえばデータモデルに従って、データウェアハウスの顧客スキーマにロードするのに適した形式に変換することができる。変換中、データ変換は、ディメンション生成、ファクト生成、およびアグリゲーション生成を、適宜実行することができる。ディメンション生成は、データウェアハウスインスタンスにロードするためのディメンションまたはフィールドを生成することを含み得る。

【0032】

一実施形態によると、抽出されたデータの変換後、データパイプラインまたはプロセスは、変換されたデータをデータウェアハウスインスタンスの顧客スキーマにロードするために、ウェアハウスロード手順１５０を実行することができる。変換されたデータを顧客スキーマにロードした後、変換されたデータを分析し、さまざまな追加のビジネスインテリジェンスプロセスで使用することができる。

【0033】

データアナリティクス環境の異なる顧客は、データアナリティクスもしくはビジネスインテリジェンスデータを提供する目的で、またはソフトウェア分析アプリケーションを開発する目的で、データがどのように分類され、集約され、または変換されるかに関して、異なる要件を有する可能性がある。一実施形態によると、このような異なる要件をサポートするために、セマンティック層１８０は、顧客のデータのセマンティックモデルを定義するデータを含むことができ（これは、一般的に理解されているビジネス用語を使用して当該データを理解しアクセスする際に、ユーザをサポートするのに有用である）、プレゼンテーション層１９０にカスタムコンテンツを提供することができる。

【0034】

一実施形態によると、セマンティックモデルは、たとえばＯｒａｃｌｅ環境において、ＢＩリポジトリ（ＲＰＤ）ファイルとして定義することができ、論理スキーマ、物理スキーマ、物理から論理へのマッピング、アグリゲーションテーブルナビゲーション、および／またはセマンティックモデルのさまざまな物理層、ビジネスモデルおよびマッピング層、およびプレゼンテーション層の側面を実現する他の構成体を定義するメタデータを有する。

【0035】

一実施形態によると、顧客は、たとえばデータウェアハウスインスタンスに格納されたデータに関連するカスタムファクトまたはディメンションを追加することによって、特定の要件をサポートするためにデータソースモデルに修正を実行することができ、システムは、それに応じてセマンティックモデルを拡張することができる。

【0036】

一実施形態によると、プレゼンテーション層は、たとえば、ソフトウェア分析アプリケーション、ユーザインターフェイス、ダッシュボード、主要業績評価指標（ｋｅｙ ｐｅｒｆｏｒｍａｎｃｅ ｉｎｄｉｃａｔｏｒ：ＫＰＩ）、または、Ｏｒａｃｌｅ Ａｎａｌｙｔｉｃｓ Ｃｌｏｕｄ、もしくはＯｒａｃｌｅ Ａｎａｌｙｔｉｃｓ ｆｏｒ Ａｐｐｌｉｃａｔｉｏｎｓなどの製品によって提供され得るような、他のタイプのレポートまたはインターフェイスを使用して、データコンテンツへのアクセスを可能にすることができる。

【0037】

一実施形態によると、クエリエンジン１８（たとえば、ＯＢＩＳ）は、連携クエリエンジンのように動作して、ＳＱＬを介して、たとえば、Ｏｒａｃｌｅ Ａｎａｌｙｔｉｃｓ Ｃｌｏｕｄ環境内で分析クエリを提供し、サポートされるデータベースに動作をプッシュダウンし、ビジネスユーザクエリを適切なデータベース固有のクエリ言語（たとえば、Ｏｒａｃｌｅ ＳＱＬ，ＳＱＬ Ｓｅｒｖｅｒ ＳＱＬ，ＤＢ２ ＳＱＬまたはＥｓｓｂａｓｅ ＭＤＸ）に変換する。クエリエンジン（ＯＢＩＳなど）は、データベースにプッシュダウンできないＳＱＬオペレータの内部実行もサポートする。

【0038】

一実施形態によると、ユーザ／開発者は、コンピュータハードウェア１１（たとえば、プロセッサ、ストレージ、メモリ）、ユーザインターフェイス１２、およびアプリケーション１４を含むクライアントコンピュータデバイス１０と対話することができる。ＯＢＩＳなどのクエリエンジンまたはビジネスインテリジェンスサーバは、一般に、データベースモデルに対するインバウンドの、たとえばＳＱＬのリクエストを処理し、１つ以上の物理データベースクエリを構築および実行し、データを適切に処理し、リクエストに応答してデータを返すように動作する。

【0039】

これを達成するために、一実施形態によると、クエリエンジンまたはビジネスインテリジェンスサーバは、クエリの対象領域として利用可能なデータを記述する論理モデルまたはビジネスモデルまたはメタデータ、受信クエリを受け取り、接続されたデータソースで使用される物理クエリに変換するリクエストジェネレータ、および受信クエリを受け取り、論理モデルをナビゲートし、特定のクエリに必要なデータを最も好適に返す物理クエリを生成するナビゲータといった、さまざまなコンポーネントまたは機能を含み得る。

【0040】

たとえば、一実施形態によると、クエリエンジンまたはビジネスインテリジェンスサーバは、さまざまなデータソース上で簡略化されたスタースキーマ・ビジネスモデルを作成することにより、ユーザがあたかも単一のソースから発生したものであるかのようにデータを照会できるような、データウェアハウス内のデータにマッピングされた論理モデルを採用することができる。次に、情報を、ビジネスモデル層マッピングルールに従って、主題領域としてプレゼンテーション層に返すことができる。

【0041】

一実施形態によると、クエリエンジン（たとえば、ＯＢＩＳ）は、さまざまな実施形態において一般にＲｑＬｉｓｔｓと呼ばれるさまざまな子（リーフ）ノードを含み得るクエリ実行計画５６に従って、データベースに対するクエリを処理することができ、１つ以上の診断ログエントリを生成する。クエリ実行計画内で、各実行計画コンポーネント（ＲｑＬｉｓｔ）は、クエリ実行計画内のクエリのブロックを表し、一般にＳＥＬＥＣＴ文に変換される。ＲｑＬｉｓｔは、ＳＥＬＥＣＴ文を入れ子になったＳＥＬＥＣＴ文から選択できるのと同様に、入れ子になった子ＲｑＬｉｓｔを有し得る。

【0042】

一実施形態によると、動作中にクエリエンジンまたはビジネスインテリジェンスサーバは、クエリ実行計画を作成することができ、その後、たとえば、リクエストに応答するのに必要なデータのアグリゲーションを実行するために、さらに最適化することができる。たとえば、ＯＤＢＣインターフェイスを介して結果が呼び出し元のアプリケーションに返される前に、データを結合し、さらに計算を適用することができる。

【0043】

一実施形態によると、複数のデータソースを必要とする複雑なマルチパスリクエストは、クエリエンジンまたはビジネスインテリジェンスサーバが、クエリを分解し、どのソース、マルチパス計算、およびアグリゲーションを使用できるかを判定し、複数のデータベースおよび物理ＳＱＬ文にまたがる論理クエリ実行計画を生成することを必要とする場合があり、結果はその後、クエリエンジンまたはビジネスインテリジェンスサーバによって返され、さらに結合または集約される。

【0044】

図２はさらに、一実施形態に係る例示的なデータアナリティクス環境を示す。
図２に示すように、一実施形態によると、プロビジョニングコンポーネントはまた、以下にさらに記載するような、プロビジョニング・アプリケーション・プログラミング・インターフェイス（provisioning application programming interface：ＡＰＩ）１１２、複数のワーカー１１５、メータリングマネージャ１１６、およびデータプレーンＡＰＩ１１８を含み得る。コンソールインターフェイスは、たとえば、ＳａａＳ環境内でサービスをプロビジョニングするために、またはプロビジョニングされたサービスに対して設定変更を行うために、コマンド、命令、または他の入力がコンソールインターフェイスにおいて受信されるとＡＰＩコールを行うことによって、プロビジョニングＡＰＩと通信することができる。

【0045】

一実施形態によると、データプレーンＡＰＩは、データプレーンと通信することができる。たとえば、一実施形態によると、データプレーンが提供するサービスに向けられるプロビジョニングおよび設定変更は、データプレーンＡＰＩを介してデータプレーンに伝達され得る。

【0046】

一実施形態によると、メータリングマネージャは、制御プレーンを介してプロビジョニングされたサービスのサービスおよび使用量を計測するさまざまな機能を含み得る。たとえば、一実施形態によると、メータリングマネージャは、課金目的で、特定の顧客（テナント）について、制御プレーンを介してプロビジョニングされたプロセッサの経時的な使用量を記録することができる。同様に、メータリングマネージャは、課金目的で、ＳａａＳ環境の顧客による使用のために区分されたデータウェアハウスの格納スペースの量を記録することができる。

【0047】

一実施形態によると、データプレーンによって提供されるデータパイプラインまたはプロセスは、以下にさらに説明するような、監視コンポーネント１２２、データステージングコンポーネント１２４、データ品質コンポーネント１２６、およびデータ投影コンポーネント１２８を含み得る。

【0048】

一実施形態によると、データ変換層は、以下でさらに説明するような、ディメンション生成コンポーネント１３６、ファクト生成コンポーネント１３８、およびアグリゲーション生成コンポーネント１４０を含み得る。データプレーンはまた、データ設定（コンフィグレーション）ユーザインターフェイス１３０と、マッピング設定（コンフィグレーション）データベース１３２とを含み得る。

【0049】

一実施形態によると、データウェアハウスは、デフォルトのデータアナリティクススキーマ（いくつかの実施形態によると、本明細書では分析ウェアハウススキーマと呼ぶ）１６２と、システムの顧客（テナント）ごとに、顧客スキーマ１６４とを含み得る。

【0050】

一実施形態によると、複数のテナントをサポートするために、システムは、複数のデータウェアハウスまたはデータウェアハウスインスタンスの使用を可能にすることができる。たとえば、一実施形態によると、第１のテナントのための第１のウェアハウス顧客テナンシは、第１のデータベースインスタンス、第１のステージング領域、および複数のデータウェアハウスまたはデータウェアハウスインスタンスの第１のデータウェアハウスインスタンスを含むことができ、第２のテナントのための第２の顧客テナントは、第２のデータベースインスタンス、第２のステージング領域、および複数のデータウェアハウスまたはデータウェアハウスインスタンスの第２のデータウェアハウスインスタンスを含み得る。

【0051】

一実施形態によると、マッピング設定データベースにおいて定義されたデータモデルに基づいて、監視コンポーネントは、変換される複数の異なるデータセットの従属関係を決定することができる。決定された従属関係に基づいて、監視コンポーネントは、複数の異なるデータセットのうちのどれを最初にモデル形式に変換すべきかを判定することができる。

【0052】

たとえば、一実施形態によると、第１のモデルデータセットが他のモデルデータセットへの従属関係を含まず、第２のモデルデータセットが第１のモデルデータセットへの従属関係を含む場合、監視コンポーネントは、第１のデータセットへの第２のデータセットの従属関係に対応するために、第２のデータセットよりも前に第１のデータセットを変換すると決定することができる。

【0053】

たとえば、一実施形態によると、ディメンションは、たとえば、「名前」、「住所」、または「年齢」などのデータのカテゴリを含み得る。ファクト生成には、データが取り得る値の生成、すなわち「尺度」の生成が含まれる。ファクトは、データウェアハウスインスタンス内の適切なディメンションに関連付けることができる。アグリゲーション生成は、データウェアハウスインスタンスの顧客スキーマ内の既存のデータに対する、変換されたデータのアグリゲーションを計算するデータマッピングの作成を含む。

【0054】

一実施形態によると、（データモデルによって定義されるように）任意の変換が実施されると、データパイプラインまたはプロセスは、ソースデータを読取り、変換を適用し、データをデータウェアハウスインスタンスにプッシュすることができる。

【0055】

一実施形態によると、データ変換はルールで表現することができ、変換が行われると、値をステージング領域で中間的に保持することができ、データ品質コンポーネントおよびデータ投影コンポーネントは、データがデータウェアハウスインスタンスにおいて顧客スキーマにアップロードされる前に、変換されたデータの完全性を検証およびチェックすることができる。抽出、変換、ロードプロセスが、たとえば、多数の計算インスタンスまたは仮想マシンで実行されると、監視を提供することができる。従属関係もまた、抽出、変換、ロードプロセス中に維持することができ、データパイプラインまたはプロセスは、そのような順序決定を処理することができる。

【0056】

一実施形態によると、抽出されたデータの変換後、データパイプラインまたはプロセスは、変換されたデータをデータウェアハウスインスタンスの顧客スキーマにロードするために、ウェアハウスロード手順を実行することができる。変換されたデータを顧客スキーマにロードした後、変換されたデータを分析し、さまざまな追加のビジネスインテリジェンスプロセスで使用することができる。

【0057】

図３はさらに、一実施形態に係る例示的なデータアナリティクス環境を示す。
図３に示すように、一実施形態によると、データを、たとえば、データパイプラインプロセスを使用して、顧客（テナント）の企業ソフトウェアアプリケーションもしくはデータ環境（１０６）から、または１つ以上の顧客固有のアプリケーション１０７から供給されたカスタムデータ１０９として供給することができ、いくつかの例ではデータの格納のためのオブジェクトストレージ１０５の使用を含むデータウェアハウスインスタンスにロードすることができる。

【0058】

たとえば、Ｏｒａｃｌｅ Ａｎａｌｙｔｉｃｓ Ｃｌｏｕｄ（ＯＡＣ）などのアナリティクス環境の実施形態によると、ユーザは、異なる接続およびスキーマからのテーブルを使用するデータセットを作成することができる。システムは、これらのテーブル間で定義された関係を使用して、データセット内の関係または結合を作成する。

【0059】

一実施形態によると、顧客（テナント）ごとに、システムは、システム／クラウドテナンシ１１４内で、システムによって維持および更新されるデータアナリティクススキーマを使用して、当該顧客の企業アプリケーション環境内および顧客テナンシ１１７内のデータの分析に基づいて、当該顧客のデータウェアハウスインスタンスを事前にポピュレートする。このように、システムによって維持されるデータアナリティクススキーマは、データパイプラインまたはプロセスによって、顧客の環境からデータを取得し、顧客のデータウェアハウスインスタンスにロードすることを可能にする。

【0060】

一実施形態によると、システムはまた、環境の顧客ごとに、顧客によって容易に変更可能であり、かつ顧客が自身のデータウェアハウスインスタンス内でデータを補足して利用することを可能にする顧客スキーマを提供する。顧客ごとに、結果として生じるデータウェアハウスインスタンスは、内容が顧客によって部分的に制御され、環境（システム）によって部分的に制御されるデータベースとして動作する。

【0061】

たとえば、一実施形態によると、データウェアハウス（たとえば、Ｏｒａｃｌｅ Ａｕｔｏｎｏｍｏｕｓ Ｄａｔａ Ｗａｒｅｈｏｕｓｅ：ＡＤＷ）は、データアナリティクススキーマと、顧客／テナントごとに、その企業ソフトウェアアプリケーションまたはデータ環境から供給された顧客スキーマとを含み得る。データウェアハウステナンシ（たとえば、ＡＤＷクラウドテナンシ）においてプロビジョニングされたデータは、そのテナントのみがアクセス可能であり、同時に、共有環境のさまざまな、たとえば、ＥＴＬ関連または他の機能へのアクセスを可能にする。

【0062】

一実施形態によると、複数の顧客／テナントをサポートするために、システムは複数のデータウェアハウスインスタンスの使用を可能にし、たとえば、第１の顧客テナンシは、第１のデータベースインスタンス、第１のステージング領域、および第１のデータウェアハウスインスタンスを含んでもよく、第２の顧客テナンシは、第２のデータベースインスタンス、第２のステージング領域、および第２のデータウェアハウスインスタンスを含み得る。

【0063】

一実施形態によると、特定の顧客／テナントについて、そのデータの抽出時に、データパイプラインまたはプロセスは、抽出されたデータをテナントのデータステージング領域に挿入することができ、このデータステージング領域は、抽出されたデータの一時的なステージング領域として機能し得る。データ品質コンポーネントとデータ保護コンポーネントとを使用して、たとえば、データがデータステージング領域に一時的に保持されている間に、抽出されたデータの検証を実行することによって、抽出されたデータの完全性を保証することができる。抽出プロセスが抽出を完了すると、データ変換層を使用して変換プロセスを開始して、抽出されたデータをデータウェアハウスの顧客スキーマにロードされるモデル形式に変換することができる。

【0064】

図４はさらに、一実施形態に係る例示的なデータアナリティクス環境を示す。
図４に示すように、一実施形態によると、たとえば、上述のデータパイプラインプロセスを使用して、顧客（テナント）企業ソフトウェアアプリケーションもしくはデータ環境から、または１つ以上の顧客固有のアプリケーションから供給される顧客データとしてデータを抽出し、データウェアハウスインスタンスへデータをロードする、またはデータウェアハウス内のデータをリフレッシュするプロセスは、一般に３つの大まかな段階を含み、これらの段階は、１つ以上の抽出サービス１６３、変換サービス１６５、およびロード／パブリッシュサービス１６７を含むＥＴＰサービス１６０またはプロセスによって実行され、かつ、１つ以上の計算インスタンス１７０によって実行される。

【0065】

たとえば、一実施形態によると、抽出のためのビューオブジェクトのリストは、たとえば、ＲＥＳＴコールを介してＯｒａｃｌｅ ＢＩ Ｃｌｏｕｄ Ｃｏｎｎｅｃｔｏｒ（ＢＩＣＣ）コンポーネントに提出することができる。抽出されたファイルは、データを格納するために、たとえばＯｒａｃｌｅ Ｓｔｏｒａｇｅ Ｓｅｒｖｉｃｅ（ＯＳＳ）コンポーネントなどのオブジェクト格納コンポーネントにアップロードすることができる。変換プロセスは、オブジェクトストレージコンポーネント（ＯＳＳなど）からデータファイルを取り込み、ビジネスロジックを適用しながら、データパイプラインまたはプロセスの内部であり、かつ顧客（テナント）には公開されないターゲットデータウェアハウス（ＡＤＷデータベースなど）にロードする。ロード／パブリッシュサービスまたはプロセスは、たとえばＡＤＷデータベースまたはウェアハウスからデータを取り込み、顧客（テナント）がアクセス可能なデータウェアハウスインスタンスに公開する。

【0066】

図５はさらに、一実施形態に係る例示的なデータアナリティクス環境を示す。
一実施形態に係る複数のテナント（顧客）を有するシステムの動作を示す図５に示すように、データは、たとえば、上述のデータパイプラインプロセスを使用して、複数の顧客（テナント）の企業ソフトウェアアプリケーションまたはデータ環境の各々から供給され、データウェアハウスインスタンスにロードされ得る。

【0067】

一実施形態によると、データパイプラインまたはプロセスは、複数の顧客（テナント）の各々、たとえば顧客Ａ１８０、顧客Ｂ１８２について、特定のアナリティクス使用事例のベストプラクティスに従ってシステムによって定期的に更新されるデータアナリティクススキーマを維持する。

【0068】

一実施形態によると、複数の顧客（たとえば、顧客Ａ、顧客Ｂ）の各々について、システムは、システムによって維持され更新されるデータアナリティクススキーマ１６２Ａ，１６２Ｂを使用して、その顧客の企業アプリケーション環境１０６Ａ，１０６Ｂ内、および各顧客のテナンシ（たとえば、顧客Ａテナンシ１８１、顧客Ｂテナンシ１８３）内のデータの分析に基づいて、顧客のデータウェアハウスインスタンスを事前にポピュレートし、それによって、データは、データパイプラインまたはプロセスによって、顧客の環境から取得され、顧客のデータウェアハウスインスタンス１６０Ａ，１６０Ｂにロードされる。

【0069】

一実施形態によると、データアナリティクス環境はまた、環境の複数の顧客の各々について、顧客によって容易に変更可能であり、かつ顧客が自身のデータウェアハウスインスタンス内でデータを補足し利用することを可能にする顧客スキーマ（たとえば、顧客Ａスキーマ１６４Ａ、顧客Ｂスキーマ１６４Ｂ）を提供する。

【0070】

上述したように、一実施形態によると、データアナリティクス環境の複数の顧客の各々について、結果として生じるデータウェアハウスインスタンスは、その内容が顧客によって部分的に制御され、データアナリティクス環境（システム）によって部分的に制御されるデータベースとして動作し、データベースは、さまざまアナリティクス使用事例に対応するために、企業アプリケーション環境から取得した適切なデータがあらかじめポピュレートされているであろうことを含む。特定の顧客についての抽出プロセス１０８Ａ，１０８Ｂが抽出を完了すると、データ変換層を使用して変換プロセスを開始して、抽出されたデータを、データウェアハウスの顧客スキーマにロードされるモデル形式に変換することができる。

【0071】

一実施形態によると、起動プラン１８６は、顧客（テナント）の特定のニーズに対応するために、特定の機能領域について、顧客についてのデータパイプラインまたはプロセスサービスの動作を制御するために使用することができる。

【0072】

たとえば、一実施形態によると、起動計画は、特定の順序で、特定の時間帯に、特定の時間窓内で実行される、多数の抽出、変換、およびロード（パブリッシュ）サービスまたはステップを定義することができる。

【0073】

一実施形態によると、各顧客を、独自の起動計画（複数可）に関連付けることができる。たとえば、第一の顧客Ａの起動プランは、その顧客の企業ソフトウェアアプリケーション環境（たとえば、Ｏｒａｃｌｅ Ｆｕｓｉｏｎ Ａｐｐｌｉｃａｔｉｏｎｓ環境）から取得されるテーブルを決定する、またはサービスおよびそのプロセスがどのように順番に実行されるかを決定することができる。一方、第２の顧客Ｂの起動プランも同様に、その顧客の企業ソフトウェアアプリケーション環境から取得されるテーブルを決定する、またはサービスおよびそのプロセスがどのように順番に実行されるかを決定することができる。

【0074】

モデル適合性および安定性の判定
一実施形態によると、システムは、モデルデプロイメントおよび自動モデル生成のために、モデル適合性および安定性を判定する手段を含み得る。

【0075】

図６は、一実施形態に係る、データアナリティクス環境に関連して使用される、モデル適合性および安定性の判定を示す。

【0076】

たとえば、図６に示すように、一実施形態によると、システムは１つ以上のデータモデル２３０を含み得る。パッケージ化された（追加設定なし、初期）モデル２３２は、上述のようなＥＴＬもしくは他のデータパイプラインまたはプロセスの使用に基づいて、パッケージ化されたコンテンツ２３４を提供して顧客の企業ソフトウェアアプリケーションまたはデータ環境からデータウェアハウスインスタンスにデータをロードするために使用することができ、パッケージ化されたモデルは、その後、プレゼンテーション層２４０にパッケージ化されたコンテンツを提供するために使用することができる。カスタムモデル２３６は、パッケージ化されたモデルを拡張するため、またはカスタムコンテンツ２３８をプレゼンテーション層に提供するために使用することができる。

【0077】

一実施形態によると、プレゼンテーション層は、たとえば、Ｏｒａｃｌｅ Ａｎａｌｙｔｉｃｓ ＣｌｏｕｄまたはＯｒａｃｌｅ Ａｎａｌｙｔｉｃｓ ｆｏｒ Ａｐｐｌｉｃａｔｉｏｎｓなどの製品によって提供され得るような、ソフトウェア分析アプリケーション、ユーザインターフェイス、ダッシュボード、主要業績評価指標（ＫＰＩ）２４２、または他のタイプのレポートもしくはインターフェイスを使用して、データコンテンツへのアクセスを可能にすることができる。

【0078】

図６にさらに示すように、一実施形態によると、システムは、モデル適合性・安定性コンポーネント２５０を含み、以下に記載するように、特定のアプリケーションについてモデル適合性および安定性を判定するために、モデル選択２５２、モデルデプロイ可能性スコア・デプロイ可能性フラグ２５４の使用、およびモデルドリフトリスク２５６の軽減をサポートする１つ以上の機能を提供することができる。

【0079】

一実施形態によると、部門をまたがる経時的な変化を考慮した新しいモデルの自動生成を必要とする顧客のビジネスニーズに対して、システムは、人間の介入を必要とすることなく、適切なメトリクスを使用して、何千もの潜在的なモデル候補の中から自動的にフィルタリングを行い、予測に基づいて最も重要な実行可能な洞察を見出すことを可能にする。

【0080】

モデルスコアリングおよび選択
上述したように、一実施形態によると、システムは、特定のアプリケーションについてモデル適合性および安定性を判定するために、モデル選択をサポートする１つ以上の特徴を提供することができるモデル適合性・安定性コンポーネントを含む。

【0081】

たとえば、顧客が売掛金を期限内に支払うか否かのような二値分類の問題では、モデル選択の判定が重要である。このような環境では、モデルの適合性を判定するためにさまざまなクラスのメトリクスを使用することができる。

【0082】

一実施形態によると、メトリクスの第一のクラスは、キャリブレーションなしで異なるアルゴリズムによって生成される、分布の上部（たとえば、ｐ＝［０．８，０．９］）および下部（たとえば、ｐ＝［０．１，０．２］）に重みを置く傾向があるか、または、最も高確率のビン（たとえば、ｐ＝［０．９，１］）がより高い割合の事例を有する逐次的に低い確率のビンよりも低い割合の場合を有するように不均等に分布しているか、または、不均等の鋸歯状のパターンの可能性があるという、歪んだ確率ビンの問題に対処する。

【0083】

モデルの成功基準
十分にキャリブレーションされたモデルがデプロイされた場合、期待されるのは、確率ビンのインスタンス・メンバーシップが、上位のビンから下位のビンに向かって、着実かつ急激に（たとえば、指数関数的に）低下することである。これは、モデルがほとんどの事例を高信頼度で分類し、少数の事例のみを低信頼度で分類していることを示す。

【0084】

一実施形態によると、このようなモデルのみを除去してデプロイするために、システムは、上記の基準を満たすモデルを見つけるための、かつ確率ビン内のインスタンスの鋸歯状頻度の特徴を示すモデルを除去するためのメトリックを採用する。

【0085】

確率ビンに基づくスコア
図７は、一実施形態に係る、さまざまなモデルの確率スコアの比較例を示す図である。

【0086】

図７に示すように、一実施形態によると、スコアの点数は、確率ビンに基づくことができ、上位の確率ビンから下位のビンに向かって正分類が急激に減少する。

【0087】

一実施形態によると、図７に示すように、スコアが、２つの異なるモデル、すなわちモデル７１０および７２０について生成される。モデル７１０および７２０の各々は、インボイスが支払われるか否かを判定するために使用できるモデルの例である。図示するように、モデルは１０の確率ビンに分割される。スコアリングモデルには、複数の正分類の数だけでなく複数の誤分類も示されており、関連する各スコアリングメカニズムの重みも提供されている。図示するように、モデル７１０は各確率ビン間でほぼ直線的な減少を有するが、モデル７２０は高確率（０．９－１）から低確率まで指数関数的な減少を有する。

【0088】

一実施形態によると、各モデルの結果スコア７１１および７２１を決定することができ、これは、高確率で正しい結果を予測する良好なモデルを示すように、確率の指数関数的な低下を有するモデルがより高くスコア付けされることを示す。

【0089】

一実施形態によると、以下に示す例示的なスコアリング関数は、修正された階段状の形状を有する関数のクラスを表し、高確率ビンから低確率ビンへの正しく分類された事例の数の非減少についての降順ペナルティと、分類されるインスタンスの総数で正規化された、誤分類に対するすべてのビンについてのペナルティとを有する：

【0090】

【数1】

【0091】

一実施形態によると、上記（式１）に従ってプログラムされたシステムは、以下を考慮する：

【0092】

【数2】

【0093】

【数3】

【0094】

一実施形態によると、スコアリング関数の別の例は、以下のように示すことができる：

【0095】

【数4】

【0096】

図８は、一実施形態に係る、モデル適合性および安定性を判定するためのプロセスまたは方法を示す。

【0097】

図８に示すように、一実施形態によると、データセットの所与のモデルについてスコアを決定することができる。モデルが確率（たとえば、インボイスが支払われるか否かの確率）を生成すると、モデルの出力は、確率「ビン」に集めることができる、すなわち、確率の範囲のグループ分けである。たとえば、モデルの出力が１０の確率ビンにグループ化されている場合、ビンの範囲は、０－０．１，０．１－０．２，０．２－０．３，０．３－０．４，０．４－０．５，０．５－０．６，０．６－０．７，０．７－０．８，０．８－０．９および０．９－１．０となる。モデルの出力を実際の結果（たとえば、インボイスが実際に支払われたか否か）と比較することにより、確率ビンごとに正分類および誤分類の数を求めることによって、モデルを調べることができる。

【0098】

なお、一実施形態によると、本願で議論および図示された例は、本明細書に記載のスコアリングプロセスを実証するために１０の確率ビンを利用するが、より多いまたはより少ない確率ビンを利用することができる（たとえば、各確率ビンが０．０１の確率範囲をカバーする１００の確率ビン）。

【0099】

一実施形態によると、ステップ８１０において、スコアリングプロセスは、正分類の逐次差分を決定し、低確率ビンについて、逐次的に低い各確率ビンに重みを適用することができる。確率ビンごとに適用される重みは、自動的に生成することができ、たとえば、モデルが高確率で結果を予測する場合、モデルが正しいことに高い重要性が置かれるように、高確率のビンをより重くすることができる。

【0100】

一実施形態によると、次に、ステップ８２０において、スコアリングプロセスは、分類が失敗するごとにペナルティを適用することができる。

【0101】

一実施形態によると、ステップ８３０において、スコアリングプロセスは、確率ビンごとにステップ８２０で評価されたペナルティに重みを適用することができる。重みは、ステップ８１０におけるように、高確率のビンについてより高く、さらに指数関数的に高くすることができる。このようなペナルティ重みは、同様に自動的に生成することができる。高確率のビンの誤分類は、同様に、低確率のビンにおける失敗した分類と比較してスコアを減少させなければならないため、高いペナルティが、高確率のビンの失敗した分類に適用される。

【0102】

一実施形態によると、ステップ８４０において、スコアリングプロセスは、生成されたスコアを、分類されたサンプルの数で正規化することができる。すなわち、たとえば、正規化は、生成されたスコアをサンプルの数で除算することであってもよい。

【0103】

一実施形態によると、ステップ８５０において、スコアリングプロセスは、選択的に、たとえば、モンテカルロシミュレーションによって他の可能性を考慮し、低品質のスコアリング技術を取り除くことであってもよい。

【0104】

デプロイ可能性スコア・デプロイ可能性フラグ
本明細書で説明するように、一実施形態によると、システムは、特定のアプリケーションについてモデル適合性および安定性を判定するために、モデルのデプロイ可能性スコア・デプロイ可能性フラグの使用をサポートする１つ以上の機能を提供することが可能なモデル適合性・安定性コンポーネントを含む。

【0105】

一実施形態によると、デプロイ可能性スコア・デプロイ可能性フラグを決定するために、以下のアプローチを使用することができる：

【0106】

【数5】

【0107】

ここで、上記（式２）に従ってプログラムされたシステムは、以下を考慮する：

【0108】

【数6】

【0109】

一実施形態によると、デプロイ可能性スコア（ψ）は、－１０～＋１０のスケールである：完全な分類の場合、ψは10を上回り、完全な誤分類の場合、ψは－１０を下回る。

【0110】

一実施形態によると、モデルデプロイ可能性フラグは、ヘヴィサイドの階段関数に基づいて、以下のように定義することができる：

【0111】

【数7】

【0112】

ここで、上記（式３）に従ってプログラムされたシステムは、以下を考慮する：

【0113】

【数8】

【0114】

一実施形態によると、デプロイ可能性スコアは以下のように実現することができる。
システムは、適合率、再現率、正解率、Ｆ１スコアがすべてＭＣＣによって説明されるように、正分類の他のすべての尺度の代わりとして、下記の（式５）によって示されるようなマシューズ相関係数（ＭＣＣ）を使用することができる。

【0115】

確率ビンスコアは、モデルハイジーンの前提条件であり、基本閾値を超えると、全体的なデプロイ可能性に追加される。

【0116】

基本的なハイジーン係数を超えた後、デプロイ可能性スコアはＭＣＣと高い相関があり、確率ビンスコアと共に向上する。

【0117】

デプロイ可能性スコアが上記（式３）の閾値を超えると、システムはそのモデルをデプロイ可能とみなすことができる。

【0118】

初期モデルのデプロイメントについては、システムは、デプロイ可能性スコア＞上記のＴであると判断することができる。

【0119】

【数9】

【0120】

一実施形態によると、元のモデルから続く新規モデルのデプロイ可能性をチェックするために、新規モデルがデプロイ可能性スコア＞Ｔを有し続け、かつ人間による判定が行われたときの元のデプロイ可能性スコアである１倍以内より悪くない限り、システムはデプロイ可能である。これは、ＭＣＣ、Ｆ１スコア、および受信者操作特性曲線下面積（Ａｒｅａ Ｕｎｄｅｒ ｔｈｅ Ｃｕｒｖｅ ｏｆ ｔｈｅ Ｒｅｃｅｉｖｅｒ Ｏｐｅｒａｔｏｒ Ｃｈａｒａｃｔｅｒｉｓｔｉｃ：ＡＵＣ ｏｆ ＲＯＣ）における０．１以下のシフトにほぼ対応する。

【0121】

一実施形態によると、公知のメトリクスの第２のクラスは、タイプＩエラーおよびタイプＩＩエラーが等しく重み付けされるＦ１スコアなど、真陽性（ＴＰ）、偽陽性（ＦＰ）、真陰性（ＴＮ）、および偽陰性（ＦＮ）の相対的なカウントによって判定されるように、クラスがどの程度良好に区別されたかを判定するために使用することができる。

【0122】

一実施形態によると、記載されるアプローチは、顧客が適合率に対して再現率を重み付けするように選択することを可能にし、顧客が適合率よりも再現率を高くしたい場合、βを１より大きく設定することができ、顧客が再現率よりも適合率を高くしたい場合、βを１より小さく設定することができる：

【0123】

【数10】

【0124】

しかしながら、これらのＦ尺度および関連する尺度は、クラスの不均衡に起因して歪んでおり、特に、不払いの事例のような関心のある実際のクラスが、支払いが完了した事例に対して稀である場合がある。このクラスの不均衡の問題を解決するために、システムは、マシューズ相関係数（ＭＣＣ）によってモデルをフィルタリングすることができる。

【0125】

【数11】

【0126】

上記の判定は、完全な正分類では１に近く、誤分類では－１に近く、ランダムな分類では０に近い。一実施形態によると、上記のスコアを満たす場合、０．５のＭＣＣを超えるモデルを受け入れることができる。マシューズ相関係数は、マルチクラス分類の事例にも十分に適用される。

【0127】

モデルドリフトリスクの軽減
上述したように、一実施形態によると、システムは、特定のアプリケーションについてモデル適合性および安定性を判定するために、モデルドリフトリスクの軽減をサポートする１つ以上の機能を提供することができるモデル適合性・安定性コンポーネントを備える。

【0128】

一実施形態によると、モデルドリフトリスクは、モデル安定性検出を用いて軽減することができる。モデル精度メトリクスは、訓練およびテスト分布のドリフトによって大きく変化し得るが、システムおよび方法は、モデル選択の基準として単にモデル精度メトリクスを使用するものではない。入力分布、または特定の日もしくは週に採取された母集団のサンプルの分布が変化すると、昨日支払われた可能性が高いと分類されたインボイスを、今日は支払われない可能性が高いと分類するなど、複数のインスタンスで分類を逆転させる程度にまで、新しいモデルにおける決定境界の有意なドリフトが見られることが予想される。

【0129】

一実施形態によると、システムおよび方法は、同じインボイスに関する新しいデータが入ってくると予測に変化が生じると予想すべきであるが、独立変数が以前の期間と比較して実質的に同じままであれば、同じインボイスに関する予測に大きな変化が生じると予想すべきでない。

【0130】

しかしながら、一実施形態によれば、訓練分布に経時的に有意なシフトがある場合、決定境界のシフトが発生する可能性がある。これらのシフトを明示的に検出し、エンドユーザに呼びかけることができる。たとえば、２つの分布が、それらの中心傾向および分散の尺度が統計的に有意に異なるほど、互いに実質的に乖離している場合である。

【0131】

一実施形態によると、決定境界が大きく（たとえば、毎日）ドリフトするほどモデルが不安定であるとシステムが検出する場合、これは、モデル適合における複数の問題を示している。そのような場合、分類の決定は、個々のインスタンスのデータに変化がなくても、前日の予測を反転させるほど、日々変化し続けることになる。

【0132】

一実施形態によると、本明細書に記載のアプローチは、関心のあるクラスインスタンスの一部においてランダムな小さな摂動（独立変数の標準偏差の５％未満）がなされ、分類において有意なシフトが検出された場合、モデル不安定性シナリオに達したと結論付けることができるような感度メトリックを使用して、モデルの安定性を評価するために使用することができ、またはシステムおよび方法は、決定境界に近いインスタンスを扱っている可能性がある。システムは、正規化距離尺度を使用して、所与の分類において、決定境界に近いインスタンスとインスタンスのクラスタ内部の事例とを区別することができる。

【0133】

一実施形態によると、分類確率の変化が大きくジャンプするので、クラス・クラスタの中心に近いインスタンスであっても、不安定性が見られると予想される。

【0134】

一実施形態によると、システムおよび方法は、スコアリング分布が訓練分布からどの程度シフトしているか、および訓練分布間のシフトが経時的にどの程度であるかを決定し、調べることができる。この目的で、記載されるアプローチは、以下の２つのスコアの組み合わせを使用することができる。

【0135】

モデルおよび分布のドリフト：一実施形態によると、Ｆ１スコア（正解率の尺度）およびマシューズ相関係数（ＭＣＣ）の減少は、ドリフトの直接的な指標であり、Ｆ１スコアが閾値（たとえば、０．６）を下回る、またはＭＣＣが境界（たとえば、０．３５）を下回るときはいつでも、システムは、モデルの再訓練を要求するために自動的にアラームフラグを立てることができる。Ｋｕｌｌｂａｃｋ－Ｌｅｉｂｌｅｒ Ｄｉｖｅｒｇｅｎｃｅまたは Ｂｈａｔｔａｃｈａｒｙａ ｄｉｓｔａｎｃｅタイプの尺度を評価して、訓練データセットからスコアリングデータセットへの入力独立変数の分布のシフトを判定することで、入力分布が過去の訓練データからどの程度ずれているかを判定することができる。

【0136】

モデルの安定性：一実施形態によると、記載するアプローチは、入力独立変数の無視できるほどの変化にもかかわらず、分類の変化についてスコアリングメカニズムを提供するために使用することができる。

【0137】

図９はさらに、一実施形態に係る、モデル適合性および安定性を判定するためのプロセスまたは方法を示す。

【0138】

図９に示すように、一実施形態によると、プロセスは、モデルがドリフトしており、緩和が必要であるかどうかを判定するために利用することができる。このプロセスは、モデルの安定性に対するリスクを判定するためにも使用できる。

【0139】

たとえば、図９のプロセスは、モデルが予測をシフト／反転させている場合（たとえば、ある日から次の日にかけて「支払い済み」から「未払い」に予測の数を反転させている場合－これは、モデルの不安定性または劣化の兆候である可能性がある）を判定するために使用することができる。

【0140】

一実施形態によると、ステップ９１０において、プロセスは、分布ドリフト下でのモデル劣化の１つ以上のシグナルを検出することができる。たとえば、プロセスは、ＭＣＣおよびＡＵＣスコアを追跡して、スコアが低下しているかどうかを決定することができる。閾値を超える損失は、モデルがドリフトしている、または大きくドリフトしている（たとえば、０．１以上の損失の閾値）とみなすことができる。さらに、このプロセスでは、Ｋｕｌｌｂａｃｋ－Ｌｅｉｂｌｅｒ Ｄｉｖｅｒｇｅｎｃｅ（相対エントロピーとしても知られる）またはＢｈａｔｔａｃｈａｒｙａ Ｄｉｓｔａｎｃｅタイプの尺度を評価して、訓練データセットからスコアリングデータセットへの入力独立変数の分布のシフトを判定することができる。

【0141】

一実施形態によると、ステップ９２０において、プロセスは、モデルの安定性・検出・スコアリングプロセスを開始することができる。

【0142】

一実施形態によると、ステップ９３０において、プロセスは、同じ事前分類を有する最近傍（たとえば、３０個の近傍）のクラスタからの各インスタンス（たとえば、インボイス）の距離を決定することができる。距離は、たとえば、同じ事前分類を有するその最も近い３０個の近傍のクラスタからの各インボイスまたはインスタンスのマハラノビス距離を求めることによって、計算することができる。

【0143】

一実施形態によると、ステップ９４０において、プロセスは、これらの最近傍のうちの少なくとも１つ以上がモデルの新しいバージョンにおいて分類を反転させると判定する場合、これを反転分類のカウントに追加することができる。

【0144】

一実施形態によると、ステップ９５０において、プロセスは、分類されるインスタンスの総数のうち、そのような反転分類の割合または比率を決定することができる。

【0145】

一実施形態によると、ステップ９６０において、そのような反転分類が閾値（たとえば、ＭＣＣの対応する増加がないインスタンスの総数の２パーセント）を超える場合、プロセスは、モデルがわずかに不安定であるとしてフラグを立てることができる。

【0146】

一実施形態によると、ステップ９７０において、そのような反転分類が第２の閾値（たとえば、ＭＣＣの対応する増加がないインスタンスの総数の１０％）を超える場合、プロセスは、モデルが不安定であるとしてフラグを立てる。

【0147】

一実施形態によると、上述した閾値は、たとえばユーザまたは管理者によってシステムで受信された入力に基づいて、設定、修正、および／または変更することができる。

【0148】

一実施形態によると、記載されるアプローチは、すべての数値独立変数（たとえば、金額、延滞日数、フォローアップの回数）をｚスコアに変換し、すべてのカテゴリ独立変数（たとえば、顧客の業種、場所、インボイスのタイプ、インボイス項目のタイプ）をエントロピー符号化再正規化ｚスコアに変換し、現在のインボイスと異なるインボイスタイプまたは顧客タイプのクラスタとの間のユークリッド距離（共分散行列が同一行列である場合）を見つけることによって、インボイスまたはインスタンス間の標準偏差正規化距離のマハラノビス距離に基づく尺度を使用する。

【0149】

たとえば、一実施形態によると、支払済みインボイスからのインボイス距離が未払いインボイスからのものと比較して大きい場合、プロセスは、それを高リスクカテゴリーに割り当てることができる。図１０に示すように、システムは、ソートされたインボイスのリストを、リスク別にユーザに提示することができる。

【0150】

図１０は、一実施形態に係る、インボイスのソートされたリストを説明する図である。
図１０に示すように、例示的なスクリーンショット１０００が、たとえば、システムのユーザインターフェイスを介して提供され得る。上述したスコアリングシステムに起因して選択されたモデルに基づいて、さまざまなメトリクスを、ユーザインターフェイスを介して提供することができる。これには、リスク上位１０件のインボイスとそれらの金額、支払済み上位１０件のインボイスとそれらの金額、上位２０％のインボイスとリスク総量、上位２０％のインボイスと支払済み総額などが含まれるが、これらに限定されない。

【0151】

図１１は、一実施形態に係る、データを分析するモデルの出力を説明する図である。
図１１に示すように、例示的なスクリーンショット１１００が、たとえば、システムのユーザインターフェイスを介して提供され得る。上述したスコアリングシステムに起因して選択されたモデルに基づいて、確率ビンに関連するさまざまなメトリクスを、ユーザインターフェイスを介して提供することができる。システムは、確率間隔の等しいビンを作成し、すべての数値変数のビンの列との相関（たとえば、ピアソンの相関）を作成することによって、そのようなチャートを生成することができる。その後、相互に関連する変数のトップ数（たとえば、５）を決定することができる。

【0152】

そのような決定の後、一実施形態によると、システムは、これらの変数のビン平均が、全母集団の平均と少なくともある割合（たとえば、５０％）異なるかどうかを判定することができる。ビン平均が母集団の平均と少なくとも、たとえば５０％異なる場合、この変数を説明のリストと共に表示することができる。

【0153】

図１２は、一実施形態に係る、自動モデル生成におけるモデルデプロイメントのモデル適合性および安定性を判定する方法のフローチャートである。

【0154】

一実施形態によると、ステップ１２１０において、方法は、１つ以上のマイクロプロセッサを含むコンピュータ、およびコンピュータ上で動作するデータアナリティクスクラウドまたは他のコンピューティング環境を提供することができる。

【0155】

一実施形態によると、ステップ１２２０において、方法は、データアナリティクスクラウドにおいて、複数のモデルを提供することができる。

【0156】

一実施形態によると、ステップ１２３０において、方法は、データアナリティクスクラウドにおけるデータのセットに基づいて、複数のモデルのセットをスコアリングで点数化することができる。

【0157】

一実施形態によると、ステップ１２４０において、方法は、スコアリングに基づいて、複数のモデルのセットのうちのモデルを選択することができる。

【0158】

一実施形態によると、ステップ１２２０において、方法は、不安定性またはドリフトの兆候について、モデルを監視することができる。

【0159】

さまざまな実施形態によると、本明細書の教示は、本開示の教示に従ってプログラムされた１つ以上のプロセッサ、メモリおよび／またはコンピュータ読取可能記憶媒体を含む、１つ以上の従来の汎用または特殊なコンピュータ、コンピューティングデバイス、機械、またはマイクロプロセッサを使用して、好都合に実現され得る。適切なソフトウェアコーディングは、ソフトウェア技術の当業者には明らかなように、本開示の教示に基づいて熟練プログラマによって容易に作成され得る。

【0160】

いくつかの実施形態において、本明細書の教示は、本教示のプロセスのいずれかを実行するようにコンピュータをプログラムするために使用され得る、命令を格納した非一時的な１つまたは複数のコンピュータ読取可能記憶媒体であるコンピュータプログラム製品を含み得る。このような記憶媒体の例としては、ハードディスクドライブ、ハードディスク、ハードドライブ、固定ディスク、または他の電気機械的データ記憶デバイス、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ－ＲＯＭ、マイクロドライブ、および光磁気ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気カードもしくは光カード、ナノシステム、または命令および／またはデータの非一時的な格納に適した他のタイプの記憶媒体もしくはデバイスを挙げることができるが、これらに限定されない。

【0161】

前述の記載は、例示および説明の目的で提供されたものであり、網羅的であること、または保護範囲を開示された正確な形態に限定することは意図されていない。多くの修正および変形が当業者には明らかであろう。たとえば、本明細書で提供される例のいくつかは、Ｏｒａｃｌｅ Ａｎａｌｙｔｉｃｓ Ｃｌｏｕｄなどのクラウド環境での使用を例示しているが、さまざまな実施形態によると、本明細書に記載のシステムおよび方法は、他のタイプの企業ソフトウェアアプリケーション、クラウド環境、クラウドサービス、クラウドコンピューティング、または他のコンピューティング環境で使用することができる。

【0162】

実施形態は、本教示の原理およびその実際的な適用を最もよく説明するために選択され、説明された。これにより、当業者が、さまざまな実施形態、および考えられる特定の使用に適したさまざまな変更を伴う実施形態を理解することができる。添付の特許請求の範囲およびその均等物によって範囲が定義されることが意図される。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7-1】

【図7-2】

【図8】

【図9】

【図10】

【図11-1】

【図11-2】

【図12】

【国際調査報告】