JP6412924B2 - Ｅｔｌマップ設計のためのプロジェクタおよびセレクタコンポーネントタイプの使用 - Google Patents

Description

発明の背景
ペースが一層速くなっている今日のビジネス環境において、組織はより特殊化されたソフトウェアアプリケーションを使用する必要がある。さらに、組織は、異種混合のハードウェアプラットフォームおよびシステム上でこれらのアプリケーションの共存を保証する必要があるとともに、アプリケーションとシステムとの間でデータを共有する能力を保証する必要がある。

データ統合は、あるシステムから別のシステムへのデータ移行を行なうために具体的に構成する特別に設計されたソフトウェアを有するプロプライエタリサーバを必要とするリソース集中的なプロシージャである。これらのエリアにおいて、パフォーマンスが典型的に貧弱または非能率的となっている。

したがって、データ統合シナリオの開発に関係する問題を解決することが望まれており、そのいくつかが本願明細書において論じられ得る。さらに、データ統合シナリオの開発に関係する障害を低減することが望まれており、そのいくつかが本願明細書において論じられ得る。

発明の概要
この開示の以下の部分は、少なくとも主題の基本的な理解を提供する目的のために、この開示において発見される１つ以上のイノベーション、実施形態および／または例の簡素化された概要を提供する。この概要は、如何なる特定の実施形態または例の広範囲な概要も提供することを試みてはいない。さらに、この概要は、実施形態または例の主な／決定的な要素を識別するようには意図されておらず、または、この開示の主題の範囲を定めるようには意図されていない。したがって、この概要の１つの目的は、この開示において発見されるいくつかのイノベーション、実施形態および／または例を簡素化された形で、後述されるさらなる詳細な説明の前置きとして提供することであり得る。

さまざまな実施形態において、ユーザはデータ統合システムによって、プラットホームおよび技術に依存しない論理設計を作成し得る。ユーザは、ユーザがデータをソースとターゲットとの間でどのように流したいかをハイレベルで規定する論理設計を作成し得る。ユーザのインフラストラクチャを考慮して、ツールが論理設計を分析し、物理的設計を作成し得る。論理設計は、設計における各ソースおよびターゲットならびにジョインまたはフィルタのようなオペレーションおよびアクセスポイントに対応する複数のコンポーネントを含み得る。物理的設計に転送された際の各コンポーネントは、データに対してオペレーションを行なうようコードを生成する。存在する技術（たとえばＳＱＬサーバ、オラクル、Ｈａｄｏｏｐなど）およびに使用される言語（ＳＱＬ、ｐｉｇなど）に依存して、各コンポーネントによって生成されるコードは異なり得る。

１つの局面において、データ統合システムのユーザは、始めから終わりまで、論理設計における各コンポーネントにて、すべてのデータ属性を特定する必要はない。データ統合システムは、論理設計を通って流れる情報を完全に宣言する必要性を回避する、プロジェクタおよびセレクタタイプのような複数のコンポーネントタイプを提供する。データ統合システムは、所定のコンポーネントタイプによって表わされるオペレーションにて何の属性が必要とされるか決定し得る。これは、設計およびメンテナンスの両方を簡素化する。さまざまな局面において、既存のＲＤＢＭＳリソースと、パフォーマンスの向上を達成するために別個のプロプラエタリＥＴＬサーバの必要性を回避する性能とをレバレッジするデータ変換および移行が提供される。

一実施形態において、データマッピングの生成を促進するための方法は、論理設計の１つ以上のコンポーネントを特定する情報を受け取ることを含み、１つ以上のコンポーネントのうちの少なくとも１つは第１のタイプである。第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つの論理設計における下流のコンポーネントに可視であるデータ属性のセットが、論理設計における上流のコンポーネントに基づいて、判定される。次いで、第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つの論理設計における下流のコンポーネントに可視である属性のセットを示す情報が生成される。１つの局面において、第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つの論理設計における下流のコンポーネントに可視であるデータ属性のセットを判定することは、上流のコンポーネントから可視である１つ以上の属性を導き出すことと、下流のコンポーネントに１つ以上の属性をエクスポーズする（expose）こととを含み得る。別の局面において、論理設計の１つ以上のコンポーネントを特定する情報を受け取ることは、論理設計を通って流れる情報の形を変更するオペレーションを示す情報を受け取ることを含み得る。

いくつかの実施形態において、論理設計の１つ以上のコンポーネントを特定する情報を受け取ることは、論理設計を通って流れる情報のフローを制御するが論理設計を通って流れる情報の形を変更しないオペレーションを示す情報を受け取ることを含み得る。さらに別の実施形態において、論理設計の１つ以上のコンポーネントを特定する情報を受け取ることは、ソースデータストアに格納されるデータの１つ以上の属性を有するソースコンポーネントを示す情報を受け取ることを含み得る。論理設計の１つ以上のコンポーネントを特定する情報を受け取ることは、ターゲットデータストアに格納されるデータの１つ以上の属性を有するターゲットコンポーネントを示す情報を受け取ることを含み得る。

第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つの論理設計における下流のコンポーネントに可視である属性のセットを示す情報を生成することは、下流のコンポーネントに属性のリストをエクスポートすることを含み得る。一実施形態において、論理設計へのコンポーネントまたは属性の導入または除去による論理設計における変更が受け取られ得る。論理設計における変更が第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つに影響するかどうかの判定がなされる。論理設計における変更が、第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つに影響するという判定に基づいて、下流のコンポーネントに可視であるデータ属性の更新されたセットが判定され得る。

さらに別の実施形態において、論理設計へのコンポーネントまたは属性の導入による論理設計における変更が受け取られる。論理設計における変更が第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つに影響するかどうかを判定がなされ得る。論理設計における変更が、第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つに影響するという判定に基づいて、下流のコンポーネントに可視であるデータ属性のセットが保存され得る。別の局面において、論理設計における変更が、第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つに影響するという判定に基づいて、下流のコンポーネントに可視であるデータ属性のセットが自動的にリネームされ得る。

一実施形態において、一時的でないコンピュータ読取可能媒体は、データマッピングの生成を促進するためのコンピュータ実行可能コードを格納する。一時的でないコンピュータ読取可能媒体は、論理設計の１つ以上のコンポーネントを特定する情報を受け取るためのコードを含み、１つ以上のコンポーネントのうちの少なくとも１つは第１のタイプであり、一時的でないコンピュータ読取可能媒体はさらに、論理設計における上流のコンポーネントに基づいて、第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つの論理設計における下流のコンポーネントに可視であるデータ属性のセットを判定するためのコードと、第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つの論理設計における下流のコンポーネントに可視である属性のセットを示す情報を生成するためのコードとを含み得る。

別の実施形態において、データマッピングの生成を促進するためのシステムは、プロセッサと、プロセッサと通信するとともに命令のセットを格納するように構成されるメモリとを含み得、命令のセットは、プロセッサによって実行されると、論理設計の１つ以上のコンポーネントを特定する情報を受け取るようにプロセッサを構成し、１つ以上のコンポーネントのうちの少なくとも１つは第１のタイプであり、命令のセットはさらに、論理設計における上流のコンポーネントに基づいて、第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つの論理設計における下流のコンポーネントに可視であるデータ属性のセットを判定し、第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つの論理設計における下流のコンポーネントに可視である属性のセットを示す情報を生成するようにプロセッサを構成する。

一実施形態において、データマッピングの生成を促進するためのシステムは、論理設計の１つ以上のコンポーネントを特定する情報を受け取るように構成される受取部を含み、１つ以上のコンポーネントのうちの少なくとも１つは第１のタイプであり、システムは、論理設計における上流のコンポーネントに基づいて、第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つの論理設計における下流のコンポーネントに可視であるデータ属性のセットを判定するように構成される判定部と、第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つの論理設計における下流のコンポーネントに可視である属性のセットを示す情報を生成するように構成される生成部とを含む。第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つの論理設計における下流のコンポーネントに可視であるデータ属性のセットを判定することは、上流のコンポーネントから可視である１つ以上の属性を導き出すとともに、下流のコンポーネントに１つ以上の属性をエクスポーズすることを含み得る。

論理設計の１つ以上のコンポーネントを特定する情報は、論理設計を通って流れる情報の形を変更するオペレーションを示す情報を含み得る。論理設計の１つ以上のコンポーネントを特定する情報は、論理設計を通って流れる情報のフローを制御するが論理設計を通って流れる情報の形を変更しないオペレーションを示す情報を含み得る。論理設計の１つ以上のコンポーネントを特定する情報は、ソースデータストアに格納されるデータの１つ以上の属性を有するソースコンポーネントを示す情報を含み得る。論理設計の１つ以上のコンポーネントを特定する情報は、ターゲットデータストアに格納されるデータの１つ以上の属性を有するターゲットコンポーネントを示す情報を含み得る。第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つの論理設計における下流のコンポーネントに可視である属性のセットを示す情報を生成することは、下流のコンポーネントに属性のリストをエクスポートすることを含み得る。

一実施形態において、受取部はさらに、論理設計へのコンポーネントまたは属性の導入または除去による論理設計における変更を受け取るように構成されており、判定部はさらに、論理設計における変更が、第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つに影響するかどうかを判定するように構成されており、判定部はさらに、論理設計における変更が、第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つに影響するという判定に基づいて、下流のコンポーネントに可視であるデータ属性の更新されたセットを判定するように構成される。

１つの局面において、システムはさらに保存部を含み得、受取部はさらに、論理設計へのコンポーネントまたは属性の導入による論理設計における変更を受け取るように構成されており、判定部はさらに、論理設計における変更が、第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つに影響するかどうかを判定するように構成されており、保存部は、論理設計における変更が、第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つに影響するという判定に基づいて、下流のコンポーネントに可視であるデータ属性のセットを保存するように構成される。

別の局面において、システムはさらにリネーム部を含み得、受取部はさらに、コンポーネントまたは属性をリネームする論理設計における変更を受け取るように構成されており、判定部はさらに、論理設計における変更が、第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つに影響するかどうかを判定するように構成されており、リネーム部は、論理設計における変更が、第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つに影響するという判定に基づいて、下流のコンポーネントに可視であるデータ属性のセットをリネームするように構成される。

この開示の主題の性質および均等物（ならびに提供される如何なる固有または明白な利点および改良）のさらなる理解は、この開示の残りの部分、任意の添付の図面および請求の範囲への参照により、上記のセクションに加えて実現されるべきである。

この開示において発見されるイノベーション、実施形態および／または例を適切に記載および説明するために、１つ以上の添付の図面に対して参照がなされ得る。１つ以上の添付の図面を説明するよう用いられる付加的な詳細または例は、特許請求される発明のいずれか、ここで記載される実施形態および／または例のいずれか、またはこの開示において示されるいずれかのイノベーションの現在理解されている最良の形態の範囲への限定と見なされるべきではない。

本発明の実施形態を組み込み得るシステムの簡略図である。 本発明の実施形態に従ったデータ統合システムのブロック図である。 本発明の実施形態に従った、データ統合システムを実現するために使用され得るハードウェア／ソフトウェアスタックの簡略ブロック図である。 データ統合シナリオが本発明のさまざまな実施形態において作成され得るさまざまな異種混合のデータソースを有する環境のブロック図である。 データ統合システムによって実行され得る従来のデータ統合処理における簡略化されたデータフローを示す図である。 データ統合システムによって実行され得る従来のデータ統合処理における簡略化されたデータフローを示す図である。 本発明の実施形態に従った、データ統合システムによって実行され得る次世代データ統合処理における簡略化されたデータフローを示す図である。 本発明の実施形態に従った、データ統合システムによって実行され得る次世代データ統合処理における簡略化されたデータフローを示す図である。 本発明に従った一実施形態におけるＯＤＩスタジオとデータ統合システムのリポジトリとの間の相互作用の簡略ブロック図である。 本発明の実施形態に従った、データ統合シナリオを作成するための方法のフローチャートを示す図である。 本発明の実施形態に従った、データ統合シナリオを作成するためのユーザインターフェイスのスクリーンショットの図である。 本発明の実施形態に従った、マッピングを作成するための方法のフローチャートを示す図である。 本発明の実施形態に従った、データ統合シナリオにおいてマッピング情報を提供するためのユーザインターフェイスのスクリーンショットの図である。 本発明の実施形態に従った、データ統合シナリオにおいてフロー情報を提供するためのユーザインターフェイスのスクリーンショットの図である。 本発明の実施形態に従った、パッケージを作成するための方法のフローチャートを示す図である。 本発明の実施形態に従った、データ統合シナリオにおいてパッケージシーケンス情報を提供するためのユーザインターフェイスのスクリーンショットの図である。 本発明の実施形態に従った、データ統合シナリオを展開するための方法のフローチャートを示す図である。 本発明に従った一実施形態におけるマッピングの簡略ブロック図である。 本発明に従った一実施形態におけるマッピングの簡略ブロック図である。 本発明の実施形態に従った、コンポーネントタイプに基づいてコンポーネント属性を導き出すための方法のフローチャートを示す図である。 本発明に従った一実施形態においてフィルタコンポーネントを有する図１６Ａおよび図１６Ｂのマッピングの簡略ブロック図である。 本発明に従った一実施形態におけるマッピングの簡略ブロック図である。 本発明の実施形態に従った、コンポーネントを生成するための方法のフローチャートを示す図である。 本発明の実施形態を実施するために使用され得るコンピュータシステムの簡略ブロック図である。 実施形態に従ったデータマッピングの生成を促進するためのシステムの簡略ブロック図である。

発明の詳細な説明
イントロダクション
さまざまな実施形態において、ユーザはデータ統合システムによって、プラットホームおよび技術に依存しない論理設計を作成し得る。ユーザは、ユーザがデータをソースとターゲットとの間でどのように流したいかをハイレベルで規定する論理設計を作成し得る。ユーザのインフラストラクチャを考慮して、ツールが論理設計を分析し、物理的設計を作成し得る。論理設計は、設計における各ソースおよびターゲットならびにジョインまたはフィルタのようなオペレーションおよびアクセスポイントに対応する複数のコンポーネントを含み得る。物理的設計に転送された際の各コンポーネントは、データに対してオペレーションを行なうようコードを生成する。存在する技術（たとえばＳＱＬサーバ、オラクル、Ｈａｄｏｏｐなど）およびに使用される言語（ＳＱＬ、ｐｉｇなど）に依存して、各コンポーネントによって生成されるコードは異なり得る。

１つの局面において、データ統合システムのユーザは、始めから終わりまで、論理設計における各コンポーネントにて、すべてのデータ属性を特定する必要はない。データ統合システムは、論理設計を通って流れる情報を完全に宣言する必要性を回避する、プロジェクタおよびセレクタタイプのような複数のコンポーネントタイプを提供する。データ統合システムは、所定のコンポーネントタイプによって表わされるオペレーションにて何の属性が必要とされるか決定し得る。これは、設計およびメンテナンスの両方を簡素化する。

図１は、この開示において発見されるイノベーション、実施形態および／または例のいずれかの実施形態を組み込み得るか、または、実施形態に組み込まれ得るシステム１００の簡略図である。図１は、本発明を組み込む実施形態を単に例示しており、請求の範囲において記載される本発明の範囲を限定しない。当業者は、他の変形例、修正例および代替例を認識するであろう。

一実施形態において、システム１００は１つ以上のユーザコンピュータ１１０（たとえばコンピュータ１１０Ａ、１１０Ｂおよび１１０Ｃ）を含む。ユーザコンピュータ１１０は、（任意の適切な種類のマイクロソフト社のＷｉｎｄｏｗｓ（登録商標）および／またはアップル社のＭａｃｉｎｔｏｓｈ（登録商標）オペレーティングシステムを実行するパーソナルコンピュータおよび／もしくはラップトップコンピュータを単に例示として含む）汎用のパーソナルコンピュータ、ならびに／または、さまざまな商業的に利用可能なＵＮＩＸ（登録商標）もしくはＵＮＩＸライクなオペレーティングシステムのいずれかを実行するワークステーションコンピュータであり得る。これらのユーザコンピュータ１１０はさらに、本発明の方法を行なうように構成される１つ以上のアプリケーションと、１つ以上のオフィスアプリケーション、データベースクライアントおよび／またはサーバアプリケーションならびにウェブブラウザアプリケーションとを含むさまざまなアプリケーションのうちのいずれかを有し得る。

代替的には、ユーザコンピュータ１１０は、ネットワーク（たとえば以下に記載される通信ネットワーク１２０）を介して通信することができ、ならびに／または、ウェブページもしくは他のタイプの電子文書を表示およびナビゲートすることができるシンクライアントコンピュータ、インターネットが有効化された携帯電話、および／または携帯情報端末といった任意の他の電子デバイスであり得る。例示的なシステム１００は３つのユーザコンピュータを有するよう示されているが、任意の数のユーザコンピュータまたはデバイスがサポートされ得る。

本発明のある実施形態は、通信ネットワーク１２０を含み得るネットワーク化された環境において動作する。通信ネットワーク１２０は、ＴＣＰ／ＩＰ、ＳＮＡ、ＩＰＸ、およびＡｐｐｌｅＴａｌｋなどを含むがこれらに限定されないさまざまな商業的に利用可能なネットワークプロトコルのいずれかを用いるデータ通信をサポートし得る、当業者が精通している任意のタイプのネットワークであり得る。単に例示として、通信ネットワーク１２０は、イーサネット（登録商標）ネットワークおよび／もしくはトークンリングネットワークなどを含むがこれらに限定されないローカルエリアネットワーク（「ＬＡＮ」）、ワイドエリアネットワーク、仮想プライベートネットワーク（ＶＰＮ：virtual private network）を含むがこれに限定されない仮想ネットワーク、インターネット、イントラネット、エクストラネット、公衆交換電話ネットワーク（「ＰＳＴＮ：public switched telephone network」）、赤外線ネットワーク、ＩＥＥＥ８０２．１１スイートのプロトコル、当該技術において公知であるＢｌｕｅｔｏｏｔｈ（登録商標）プロトコル、および／もしくは任意の他の無線プロトコルのいずれかの下で動作するネットワークを含むがこれに限定されないワイヤレスネットワーク、ならびに／または、これらおよび／もしくは他のネットワークの任意の組合せであり得る。

本発明の実施形態は、１つ以上のサーバコンピュータ１３０（たとえばコンピュータ１３０Ａおよび１３０Ｂ）を含み得る。サーバコンピュータ１３０の各々は、上で論じられたオペレーティングシステムのいずれかを含むがこれらに限定されないオペレーティングシステムと、任意の商業的に利用可能なサーバオペレーティングシステムとを有するよう構成され得る。サーバコンピュータ１３０の各々はさらに、１つ以上のクライアント（たとえばユーザコンピュータ１１０）および／または他のサーバ（たとえばサーバコンピュータ１３０）にサービスを提供するように構成され得る１つ以上のアプリケーションを実行し得る。

単に例示として、サーバコンピュータ１３０の１つは、単に例示としてウェブページまたは他の電子文書についてユーザコンピュータ１１０からの要求を処理するよう使用され得るウェブサーバであり得る。ウェブサーバはさらに、ＨＴＴＰサーバ、ＦＴＰサーバ、ＣＧＩサーバ、データベースサーバ、およびＪａｖａ（登録商標）サーバなどを含むさまざまなサーバアプリケーションを実行し得る。本発明のいくつかの実施形態において、ウェブサーバは、本発明の方法を実行するよう、ユーザコンピュータ１１０の１つ以上の上でウェブブラウザ内で動作され得るウェブページを取り扱うように構成され得る。

いくつかの実施形態において、サーバコンピュータ１３０は、ユーザコンピュータ１１０および／または他のサーバコンピュータ１３０の１つ以上の上で実行される、クライアントによってアクセス可能な１つ以上のアプリケーションを含み得る１つ以上のファイルおよび／またはアプリケーションサーバを含み得る。単に例示として、サーバコンピュータ１３０の１つ以上は、ユーザコンピュータ１１０および／または他のサーバコンピュータ１３０に応答して、（いくつかの場合において本発明の方法を行なうように構成され得る）ウェブアプリケーションを含むがこれらに限定されないプログラムまたはスクリプトを実行可能な１つ以上の汎用コンピュータであり得る。

単に例示として、ウェブアプリケーションは、Ｊａｖａ、ＣもしくはＣ＋＋のような任意のプログラミング言語、および／または、Ｐｅｒｌ、Ｐｙｔｈｏｎ、もしくはＴＣＬのような任意のスクリプト言語、および、任意のプログラミング／スクリプト言語の組合せで記述された１つ以上のスクリプトまたはプログラムとして実現され得る。アプリケーションサーバはさらに、オラクル、マイクロソフト、およびＩＢＭなどから商業的に利用可能なものを含むがこれらに限定されないデータベースサーバを含み得、当該データベースサーバは、ユーザコンピュータ１１０の１つおよび／またはサーバコンピュータ１３０の別の１つの上で実行されるデータベースクライアントからの要求を処理し得る。

いくつかの実施形態において、アプリケーションサーバは、本発明の実施形態に従って情報を表示するために動的にウェブページを作成し得る。アプリケーションサーバによって提供されるデータは、（たとえばＨＴＭＬ、ＸＭＬ、Ｊａｖａｓｃｒｉｐｔ、ＡＪＡＸなどを含む）ウェブページとしてフォーマットされ得るか、および／または、（たとえば上述したような）ウェブサーバを介してユーザコンピュータ１１０の１つへ転送され得る。同様に、ウェブサーバは、ユーザコンピュータ１１０の１つからウェブページ要求および／もしくは入力データを受け取り得、ならびに／または、アプリケーションサーバへウェブページ要求および／もしくは入力データを転送する。

さらに別の実施形態に従うと、サーバコンピュータ１３０の１つ以上は、ファイルサーバとして機能し得、ならびに／または、ユーザコンピュータ１１０の１つおよび／もしくはサーバコンピュータ１３０の別の１つ上で実行されるアプリケーションによって組み込まれる、本発明の方法を実現するのに必要なファイルの１つ以上を含み得る。代替的には、当業者が理解するように、ファイルサーバは、すべての必要なファイルを含み得、ユーザコンピュータ１１０および／またはサーバコンピュータ１３０の１つ以上によってそのようなアプリケーションが遠隔から呼び出されることを可能にする。なお、本願明細書におけるさまざまなサーバ（たとえばアプリケーションサーバ、データベースサーバ、ウェブサーバ、ファイルサーバなど）について記載される機能は、インプリメンテーションに特有のニーズおよびパラメータに依存して、単一のサーバおよび／または複数の特殊化されるサーバによって実行され得る。

ある実施形態において、システム１００は、１つ以上のデータベース１４０（たとえばデータベース１４０Ａおよび１４０Ｂ）を含み得る。データベース１４０の位置は任意である。すなわち、単に例示として、データベース１４０Ａは、サーバコンピュータ１３０Ａ（および／またはユーザコンピュータ１１０の１つ以上）に対してローカルな（および／または存在している）記憶媒体上に存在し得る。代替的には、データベース１４０Ｂは、（たとえば通信ネットワーク１２０を介して）ユーザコンピュータ１１０およびサーバコンピュータ１３０の１つ以上と通信し得る限り、ユーザコンピュータ１１０およびサーバコンピュータ１３０のいずれかまたはすべてからリモートであり得る。実施形態の特定の集合では、データベース１４０は、当業者が精通しているストレージエリアネットワーク（ＳＡＮ）に存在し得る。（同様に、ユーザコンピュータ１１０およびサーバコンピュータ１３０に起因する機能を実行するための任意の必要なファイルが適切なように、それぞれのコンピュータ上にローカルにおよび／またはリモートに格納され得る。）実施形態の１つの集合において、データベース１４０の１つ以上は、ＳＱＬフォーマットのコマンドに応答してデータを格納、更新および抽出するよう適合されるリレーショナルデータベースであり得る。たとえば、データベース１４０は、上述したように、データベースサーバによって制御および／または維持され得る。

データ統合の概略
図２は、本発明のある実施形態に従ったデータ統合システム２００の簡略ブロック図である。図２は、この開示において示される１つ以上の発明のさまざまな実施形態または実現例を組み込み得るデータ統合システム２００の簡略図である。図２は、本願明細書において開示される発明の実施形態または実現例を単に例示しているだけであり、請求の範囲に記載されるような任意の発明の範囲を限定するべきでない。当業者は、この開示および本願明細書において示される教示を通じて、図において示される実施形態または実現例に対する他の変形例、修正例および／または代替例を認識し得る。

この実施形態において、データ統合システム２００は、情報ソース２０２、情報統合部２０４、および情報宛先部２０６を含む。一般に、情報ソース２０２から情報統合部２０４に情報が流れ、これにより、情報は、情報宛先部２０６によって、消費され、利用可能になり、または別の態様で使用され得る。データフローは一方向または双方向であり得る。いくつかの実施形態において、１つ以上のデータフローがデータ統合システム２００に存在し得る。

情報ソース２０２は、データを提供するよう構成される１つ以上のハードウェアおよび／またはソフトウェア要素を示す。情報ソース２０２は、データへの直接または間接のアクセスを提供し得る。この実施形態において、情報ソース２０２は、１つ以上のアプリケーション２０８と１つ以上のリポジトリ２１０とを含む。

アプリケーション２０８は、デスクトップアプリケーション、ホストされたアプリケーション、ウェブベースアプリケーション、またはクラウドベースアプリケーションのような従来のアプリケーションを示す。アプリケーション２０８は、１つ以上の所定の目的のために、データを受け取り、処理し、かつ維持するように構成され得る。アプリケーション２０８のいくつかの例は、カスタマーリレーションシップマネジメント（ＣＲＭ：customer relationship management）アプリケーション、金融サービスアプリケーション、管理およびリスクコンプライアンスアプリケーション、人的資本マネージメント（ＨＣＭ：human capital management）調達アプリケーション、サプライチェーンマネジメントアプリケーション、または、プロジェクトもしくはポートフォリオマネージメントアプリケーションなどを含む。アプリケーション２０８は、当該技術において公知のようなさまざま人間が読むことが可能でありマシンが読み取り可能なフォーマットでアプリケーションデータを操作およびエクスポートするために構成される機能を含み得る。アプリケーション２０８はさらに、リポジトリ２１０におけるデータにアクセスするとともに、リポジトリ２１０にデータを格納し得る。

リポジトリ２１０は、データへのアクセスを提供するように構成されるハードウェアおよび／またはソフトウェア要素を示す。リポジトリ２１０は、データの論理的および／または物理的なパーティショニングを提供し得る。リポジトリ２１０は、リポーティングおよびデータ分析をさらに提供し得る。リポジトリ２１０のいくつかの例は、データベース、データウェアハウス、またはクラウドストレージなどを含む。リポジトリは、１つ以上のアプリケーション２０８からのデータを統合することにより作成される中央レポジトリを含み得る。リポジトリ２１０に格納されたデータは、オペレーショナルシステムからアップロードされ得る。データは、ソースにおいて利用可能になる前に付加的なオペレーションを介して渡され得る。

情報統合部２０４は、データ統合サービスを提供するように構成される１つ以上のハードウェアおよび／またはソフトウェア要素を示す。直接または間接のデータ統合サービスが情報統合部２０４において提供され得る。この実施形態において、情報統合部２０４は、データ移行部２１２、データウェアハウジング部２１４、マスターデータマネージメント部２１６、データ同期部２１８、連結部２２０、およびリアルタイムメッセージ部２２２を含む。情報統合部２０４は、データ統合機能を提供する１つ以上のモジュール、サービス、または、ここで示された要素以外の付加的な要素を含み得るということが理解されるであろう。

データ移行部２１２は、データ移行を提供するように構成される１つ以上のハードウェアおよび／またはソフトウェア要素を示す。一般に、データ移行部２１２は、ストレージタイプ、フォーマット、またはシステム同士の間でデータを転送するための１つ以上のプロセスを提供する。データ移行部２１２は通常、移行を達成するようマニュアルまたはプログラムオプションを提供する。データ移行プロシージャにおいて、１つのシステム上のデータまたは１つのシステムによって提供されるデータは、データ抽出およびデータロードのための設計を提供する別のシステムにマッピングされる。データ移行は、１つ以上のフェーズを含み得、当該１つ以上のフェーズとしてはたとえば、第１のシステムのデータ形式を第２のシステムのフォーマットおよび要件に関連させる１つ以上の設計が作成される設計フェーズと、データが第１のシステムから読み出されるデータ抽出フェーズと、データクリーニングフェーズと、データが第２のシステムに書き込まれるデータローディングフェーズとがある。いくつかの実施形態において、データ移行は、データが上記のフェーズのうちのいずれかにおいて正確に処理されるかどうか判定するよう、データ検証フェーズを含み得る。

データウェアハウジング部２１４は、リポーティングおよびデータ分析のために使用されるデータベースを提供するように構成される１つ以上のハードウェアおよび／またはソフトウェア要素を示す。データウェアハウスは典型的に、１つ以上の異種のソースからのデータを統合することにより作成されるデータの中央レポジトリとして閲覧される。データウェアハウジング部２１４は、現在のデータの格納と履歴データの格納とを含み得る。データウェアハウジング部２１４は、典型的な抽出、変換、ロード（ＥＴＬ：extract, transform, load）ベースのデータウェアハウスを含み得、これにより、ステージング層、データ統合層およびアクセス層が主な機能を収容する。一例において、ステージング層またはステージングデータベースは、１つ以上の異なるソースデータシステムの各々から抽出される生データを格納する。統合層は、ステージング層からのデータを変換し、オペレーショナルデータストア（ＯＤＳ：operational data store）データベースにこの変換されたデータをしばしば格納することによって、異なるデータセットを統合する。その後、統合データは、しばしばデータウェアハウスデータベースと称されるさらに別のデータベースに移される。当該データは、（しばしば次元と称される）階層グループと、ファクト（fact）およびアグリゲートファクト（aggregate fact）とへ配され得る。アクセス層は、ユーザまたは他のシステムがデータを抽出するのを補助するために提供され得る。データウェアハウスはデータマートへ細分され得、これにより、各データマートはウェアハウスからのデータのサブセットを格納する。いくつかの実施形態において、データウェアハウジング部２１４は、ビジネスインテリジェンスツールと、データを抽出、変換およびリポジトリへロードするツールと、メタデータを管理および抽出するツールとを含み得る。

マスターデータマネージメント部２１６は、データのマスターコピーを管理するように構成される１つ以上のハードウェアおよび／またはソフトウェア要素を示す。マスターデータマネージメント部２１６は、一貫してマスターデータを規定および管理するプロセス、ガバナンス、ポリシー、スタンダードおよびツールのセットを含み得る。マスターデータマネージメント部２１６は、マスターデータの信頼すべきソースを作成するために、重複を除去し、データを標準化し、ルールを組み込んでシステムに誤ったデータが入ることを除去するための機能を含み得る。マスターデータマネージメント部２１６は、データを収集、集合、マッチング、統合、品質保証、持続、組織の全体にわたって配分するためのプロセスを提供し得、これにより、情報の進行中のメンテナンスおよびアプリケーション使用において一貫性および制御を保証する。

データ同期部２１８は、データを同期させるように構成される１つ以上のハードウェアおよび／またはソフトウェア要素を示す。データ同期部２１８は、ソースからターゲットおよびその逆のデータの間の一貫性を確立することを提供し得る。データ同期部２１８はさらに、時間にわたるデータの連続的なハーモナイゼーションを提供し得る。

連結部２２０は、構成要素ソースからのデータの閲覧を統合するように構成される１つ以上のハードウェアおよび／またはソフトウェア要素を示す。連結部２２０は、複数の自律データベースシステムを単一の連結データベースへとトランスピアレントにマッピングし得る。構成要素データベースは、コンピュータネットワークを介して相互に接続されてもよく、地理的に分散されてもよい。連結部２２０は、いくつかの異なるデータベースをマージすることに対する代替案を提供する。連結データベースまたは仮想データベースはたとえば、すべての構成要素データベースの合成を提供し得る。連結部２２０は、異なる構成要素データベースにおいて実際のデータ統合を提供しなくてもよく、閲覧においてのみ提供してもよい。

連結部２２０は、構成要素データベースが異種混合であっても、単一のクエリーによって、ユーザおよびクライアントが複数の非連続のデータベースにおいてデータを格納および抽出することを可能にする均一なユーザインターフェイスを提供する機能を含み得る。連結部２２０は、関連する構成要素データソースへの提出のためのサブクエリーにクエリーを分解するとともにサブクエリーの結果セットを合成する機能を含み得る。連結部２２０は、サブクエリーへの１つ以上のラッパー（wrapper）を、それらを適切なクエリー言語に変換するよう含み得る。いくつかの実施形態において、連結部２２０は、エクスポートスキーマおよびアクセスオペレーションの発行を通じてデータを連結部の他のメンバーに利用可能にする自律コンポーネントの集合である。

リアルタイムメッセージ部２２２は、リアルタイム制約（たとえばイベントからシステム応答までのオペレーショナルデッドライン）に従ってメッセージサービスを提供するように構成される１つ以上のハードウェアおよび／またはソフトウェア要素を示す。リアルタイムメッセージ部２２２は、厳密な時間制約内における動作または応答を保証する機能を含み得る。一例において、リアルタイムメッセージ部２２２には、１つのデータベースからいくつかのオーダおよび消費者データを取得し、ファイル中に保持されるいくつかの従業員データとそれを組合せ、その後、当該統合データをマイクロソフトＳＱＬサーバ２０００データベースにロードするタスクが課され得る。オーダは、到達する際に分析される必要があるので、リアルタイムメッセージ部２２２は、可能な限りリアルタイムに近い状態でターゲットデータベースにオーダを渡し、可能な限りワークロードを小さく維持するよう新しくかつ変更されたデータのみを抽出し得る。

情報宛先部２０６は、データを格納または消費するように構成される１つ以上のハードウェアおよび／またはソフトウェア要素を示す。この実施形態において、情報宛先部２０６は、データへの直接または間接のアクセスを提供し得る。この実施形態において、情報宛先部２０６は、１つ以上のアプリケーション２２４と１つ以上のリポジトリ２２６とを含む。

アプリケーション２２４は、デスクトップアプリケーション、ホストされたアプリケーション、ウェブベースアプリケーション、またはクラウドベースアプリケーションのような従来のアプリケーションを示す。アプリケーション２２４は、１つ以上の所定の目的のために、データを受け取り、処理し、かつ維持するように構成され得る。アプリケーション２２４のいくつかの例は、カスタマーリレーションシップマネジメント（ＣＲＭ：customer relationship management）アプリケーション、金融サービスアプリケーション、管理およびリスクコンプライアンスアプリケーション、人的資本マネージメント（ＨＣＭ：human capital management）調達アプリケーション、サプライチェーンマネジメントアプリケーション、または、プロジェクトもしくはポートフォリオマネージメントアプリケーションなどを含む。アプリケーション２２４は、当該技術において公知のようなさまざま人間が読むことが可能でありマシンが読み取り可能なフォーマットでアプリケーションデータを操作およびインポートするために構成される機能を含み得る。アプリケーション２２４はさらに、リポジトリ２２６おけるデータにアクセスするとともに、リポジトリ２２６にデータを格納し得る。

リポジトリ２２６は、データへのアクセスを提供するように構成されるハードウェアおよび／またはソフトウェア要素を示す。リポジトリ２２６は、データの論理的および／または物理的なパーティショニングを提供し得る。リポジトリ２２６は、リポーティングおよびデータ分析をさらに提供し得る。リポジトリ２２６のいくつかの例は、データベース、データウェアハウス、またはクラウドストレージなどを含む。リポジトリは、１つ以上のアプリケーション２２６からのデータを統合することにより作成される中央レポジトリを含み得る。リポジトリ２２６に格納されたデータは、情報統合部２０４を通じてアップロードまたはインポートされ得る。データは、宛先にて利用可能になる前に付加的なオペレーションを介して渡され得る。

データ統合システム
図３は、本発明の実施形態に従ったデータ統合システム２００を実現するために使用され得るハードウェア／ソフトウェアスタックの簡略ブロック図である。図３は、本願明細書において開示される発明の実施形態または実現例を単に例示しているだけであり、請求の範囲に記載されるような任意の発明の範囲を限定するべきでない。当業者は、この開示および本願明細書において示される教示を通じて、図において示される実施形態または実現例に対する他の変形例、修正例および／または代替例を認識し得る。この実施形態に従ったデータ統合システム２００において発見されるコンポーネントの一例は、カリフォルニア州レッドウッドショアズのオラクル社によって提供される製品のオラクルフュージョンミドルウェア（ORACLE FUSION Middleware）ファミリーのメンバーであるオラクルデータインテグレータ（ORACLE DATA INTEGRATOR）を含んでもよい。オラクルデータインテグレータは、セットベースのデータ統合タスクを実行するために１つ以上のデータベースを使用するＪａｖａベースのアプリケーションである。さらにオラクルデータインテグレータは、データを抽出し、変換されたデータをウェブサービスおよびメッセージを通じて提供し、サービス指向のアーキテクチャにおいてイベントに応答および作成する統合プロセスを作成し得る。オラクルデータインテグレータは、従来のＥＴＬ［抽出−変換−ロード（extract-transform-load）］アーキテクチャではなく、ＥＬＴ［抽出−ロードおよび変換（extract-Load and Transform）］アーキテクチャに基づく。オラクルデータインテグレータのためのユーザマニュアルのコピーが、この開示に添付されており、本願明細書においてすべての目的のために参照により援用される。

さまざまな実施形態において、データ統合システム２００は、データ変換および統合プロセスの規定への新しい宣言型設計アプローチ（declarative design approach）を提供し、より速くより簡易な開発およびメンテナンスが得られる。したがって、データ統合システム２００は、インプリメンテーションの詳細から宣言型ルールを分離する。データ統合システム２００はさらに、データ変換および検証プロセスの実行のためのユニークなＥ−ＬＴアーキテクチャ（抽出−ロード変換（Extract-Load Transform））を提供する。実施形態におけるこのアーキテクチャは、スタンドアロンのＥＴＬサーバおよびプロプラエタリエンジンの必要性を除去する。その代りに、いくつかの実施形態において、データ統合システム２００は、ＲＤＢＭＳエンジンの固有のパワーをレバレッジする。

いくつかの実施形態において、データ統合システム２００は、オラクルフュージョンミドルウェアプラットフォームのような１つ以上のミドルウェアソフトウェアパッケージに統合し、ミドルウェアスタックのコンポーネントになる。図３に示されるように、データ統合システム２００は、ＪａｖａＥＥアプリケーションとしてランタイムコンポーネントを提供し得る。

この例において、データ統合システム２００の１つのコンポーネントはリポジトリ３０２である。リポジトリ３０２は、ＩＴインフラストラクチャに関する構成情報、すべてのアプリケーションのメタデータ、プロジェクト、シナリオおよび実行ログを格納するように構成されるハードウェアおよび／またはソフトウェア要素を示す。いくつかの局面において、たとえばデベロップメント、ＱＡ、ユーザ、アクセプタンスおよびプロダクションといった、リポジトリ３０２の複数のインスタンスは、ＩＴインフラストラクチャにおいて共存し得る。リポジトリ３０２は、メタデータおよびシナリオを交換するいくつかの分離された環境を可能にするように構成される（たとえば、デベロップメント環境、テスト環境、メンテナンス環境、およびプロダクション環境）。リポジトリ３０２はさらに、オブジェクトがアーカイブされバージョン番号を割り当てられるバージョン制御システムとして動作するように構成される。

この例において、リポジトリ３０２は、少なくとも１つのマスターリポジトリ３０４および１つ以上のワークリポジトリ３０６から形成される。データ統合システム２００内での使用のために開発または構成されるオブジェクトは、これらのリポジトリタイプの１つに格納され得る。一般に、マスターリポジトリ３０４は、ユーザ、プロファイルおよび権限を含むセキュリティ情報と、技術、サーバ定義、スキーマ、コンテキスト、および言語などを含むトポロジー情報と、またバージョン付けおよびアーカイブされたオブジェクトといった情報を格納する。１つ以上のワークリポジトリ３０６は、実際の開発されたオブジェクトを含み得る。

いくつかのワークリポジトリは、（たとえば別個の環境を有するか、または、特定のバージョニングライフサイクルにマッチするよう）データ統合システム２００において共存し得る。１つ以上のワークリポジトリ３０６は、スキーマ定義、データストア構造およびメタデータ、フィールドおよびカラム定義、データ品質制約、相互参照、ならびにデータリネージなどを含む、モデルについての情報を格納する。１つ以上のワークリポジトリ３０６はさらに、ビジネスルール、パッケージ、プロシージャ、フォルダ、ナレッジモジュール、および変数などを含むプロジェクトと、シナリオ、スケジューリング情報およびログを含むシナリオ実行とを格納し得る。いくつかの局面において、１つ以上のワークリポジトリ３０６は、（典型的にプロダクション目的のために）実行情報のみを含み得、実行リポジトリとして指定され得る。

さまざまな実施形態において、リポジトリ３０２は、１つ以上のＥＴＬプロジェクトを格納する。ＥＴＬプロジェクトは、ソースまたはターゲットにおけるデータのデータ属性をモデリングする１つ以上のデータモデルを規定またはそうでなければ特定する。ＥＴＬプロジェクトはさらに、データを移動および変換するために、データ品質制御と、マッピングを規定することとを提供する。データの完全性制御はデータの全体的な一貫性を保証する。アプリケーションデータは、特定のソースまたはターゲットによって課された制約および宣言型ルールに必ずしも有効ではない。たとえば、オーダが顧客を伴わないことが分かった、または、オーダラインが製品を伴わないことが分かったなどである。データ統合システム２００は、これらの制約違反を検出し、再利用または報告目的のためにそれらを格納するよう作業環境を提供する。

データ統合システム２００のいくつかの実施形態において、スタティック制御およびフロー制御という２つの異なるタイプの制御が存在する。スタティック制御は、アプリケーションデータの完全性を検証するために使用されるルールの存在を示す。これらのルール（制約と称される）のうちのいくつかは、（一次キー、基準制約などを使用して）データサーバにおいて既に実現されている場合がある。データ統合システム２００は、付加的な制約の定義およびチェックを、ソースにおいてそれらを直接的に宣言することなく可能にする。フロー制御は、自身の宣言型ルールを実現する変換および統合プロセスのターゲットに関する。フロー制御は、ターゲットにデータをロードする前に、これらの制約に従ってアプリケーションの入力データを検証する。フロー制御プロシージャは一般にマッピングと称される。

ＥＴＬプロジェクトは、ランタイム環境における実行のために展開され得るパッケージへと自動化され得る。したがって、パッケージにおける異なるステップ（マッピングおよびプロシージャなど）の実行をシーケンス処理するとともに、これらのステップの各々について既存のコードを含んでいるプロダクションシナリオを作り出すことによって、データ統合フローの自動化が達成される。パッケージは典型的に、実行ダイヤグラムへ組織されるステップのシーケンスから構成される。パッケージは、プロダクションのためのシナリオを生成するよう使用されるメインオブジェクトである。それらは、データ統合ワークフローを表わしており、たとえば、データストアまたはモデルに対するリバースエンジニアリングプロセスを開始し、アドミニストレータに電子メールを送信し、ファイルをダウンロードし、それを解凍し、マッピングが実行されなければならない順序を規定し、変化するパラメータで実行コマンドに対して繰り返すループを規定するジョブを実行し得る。

シナリオは、プロダクションにソースコンポーネント（マッピング、パッケージ、プロシージャ、変数）を配置するよう設計される。シナリオは、このコンポーネントについてコード（ＳＱＬおよびシェルなど）の生成により得られる。生成されると、ソースコンポーネントのコードが凍結され、シナリオがワークリポジトリ３０６の１つ以上のようなリポジトリ３０２の内部に格納される。シナリオは、エクスポートされ、次に、異なるプロダクション環境にインポートすることができる。

さまざまな実施形態において、データ統合システム２００は、Ｊａｖａグラフィカルモジュールおよびスケジューリングエージェントによってアクセスされるモジュールの態様でリポジトリ３０２のまわりに組織される。グラフィカルモジュールは、リポジトリ３０２に格納される１つ以上の統合プロセスを設計および構築するよう使用され得る。アドミニストレータ、デベロッパおよびオペレータは、リポジトリ３０２にアクセスするためにデベロップメントスタジオを使用し得る。エージェントは、リポジトリ３０２に格納される統合プロセスに関連付けられる統合タスクのセットをスケジューリングおよび調整するために使用され得る。たとえばランタイムにおいて、デスクトップ、ウェブサービス上に展開されるか、または、ソースと通信するエージェントは、１つ以上の統合プロセスの実行を調整する。エージェントは、マスターリポジトリ３０４に格納されるコードを抽出し、さまざまなソースおよびターゲットシステムに接続し、全体的なデータ統合プロセスまたはシナリオを取りまとめ得る。

この実施形態において、データ統合システム２００は、上で論じたグラフィカルモジュールおよび／またはエージェントの１つ以上を含み得るデスクトップ３０８を含む。デスクトップ３０８は、パーソナルコンピュータ、ラップトップ、ネットブック、およびタブレットなどのような１つ以上のデスクトップまたはワークステーションコンピューティングデバイスを示す。デスクトップ３０８はＪａｖａ仮想マシン（ＪＶＭ）３１０およびオラクルデータインテグレータ（ＯＤＩ：Oracle Data Integrator）スタジオ３１２を含む。Ｊａｖａ仮想マシン（ＪＶＭ）３１０は、Ｊａｖａバイトコードを実行し得る仮想マシンである。ＪＶＭ３１０はほとんどの場合、既存のオペレーティングシステム上で実行するよう実現されるが、ハードウェア上で直接的に実行するよう実現され得る。ＪＶＭ３１０は、Ｊａｖａバイトコードが実行され得るランタイム環境を提供し、ランタイムウェブサービス（ＷＳ）３１４およびエージェント３１６のような機能を可能にする。ＪＶＭ３１０は、Ｊａｖａクラスライブラリと、Ｊａｖａアプリケーションプログラミングインターフェイス（ＡＰＩ：application programming interface）を実現する（Ｊａｖａバイトコードでの）スタンダードクラスライブラリのセットと、Ｊａｖａランタイム環境（ＪＲＥ：Java Runtime Environment）を形成する他の要素とを含み得る。

エージェント３１６は、リポジトリ３０２に格納された１つ以上の統合プロセスに関連付けられる統合タスクのセットをスケジューリングおよび調整するように構成される。たとえば、ランタイムにおいて、エージェントは、統合プロセスの実行を調整する。エージェントは、マスターリポジトリ３０４に格納されるコードを抽出し、さまざまなソースおよびターゲットシステムに接続し、全体的なデータ統合プロセスまたはシナリオを取りまとめ得る。

図３を再び参照して、ＯＤＩスタジオ３１２はデータ統合プロジェクトを設計するよう構成されるハードウェアおよび／またはソフトウェア要素を含む。この例において、ＯＤＩスタジオ３１２は、データ統合プロジェクトを作成および管理するために使用される４つのグラフィカルモジュールまたはナビゲータ、すなわち、デザイナーモジュール３１８、オペレータモジュール３２０、トポロジーモジュール３２２およびセキュリティモジュール３２４を含む。デザイナーモジュール３１８は、データストア（テーブル、ファイルおよびウェブサービスなど）、データマッピング、およびパッケージ（マッピングを含む統合ステップのセット）を規定するように構成されるモジュールである。さまざまな実施形態において、デザイナーモジュール３１８は、データ変換およびデータ完全性について宣言型ルールを規定する。したがって、プロジェクトデベロップメントがデザイナーモジュール３１８において発生する。さらに、デザイナーモジュール３１８において、データベースおよびアプリケーションメタデータがインポートおよび規定される。デザイナーモジュール３１８は、一実施形態において、メタデータおよびルールを使用して、プロダクションについてデータ統合シナリオまたはロードプランを生成する。一般に、デザイナーモジュール３１８は、データ完全性チェックを設計するように使用されるとともに、たとえば既存のアプリケーションまたはデータベースの自動リバースエンジニアリング、変換および統合マッピングのグラフィカルデベロップメントおよびメンテナンス、マッピングにおけるデータフローの可視化、自動ドキュメンテーション生成、および生成されたコードのカスタマイゼーションのような変換を構築するように使用される。

オペレータモジュール３２０は、プロダクション統合ジョブを閲覧および管理するように構成されるモジュールである。したがって、オペレータモジュール３２０は、プロダクションにおけるデータ統合プロセスを管理および監視し、エラーカウントを有する実行ログ、処理されたロウの数、実行統計、および実行される実際のコードなどを示し得る。設計時において、デベロッパはさらに、デザイナーモジュール３１８に関連して、デバッグ目的のためにオペレータモジュール３２０を使用し得る。

トポロジーモジュール３２２は、データソースおよびエージェントへの接続を作成および管理するように構成されるモジュールである。トポロジーモジュール３２２は、インフラストラクチャの物理的および論理的アーキテクチャを規定する。インフラストラクチャまたはプロジェクトアドミニストレータは、トポロジーモジュール３２２を通じて、サーバと、データベーススキーマおよびカタログと、エージェントとをマスターリポジトリに登録し得る。セキュリティモジュール３２４は、ユーザおよびそれらのリポジトリ権限を管理するように構成されるモジュールである。

一般に、ユーザまたはプロセスは、ソースおよびターゲット３２６について１つ以上のデータ統合プロセスを有するデータ統合プロジェクトを作成するよう、デザイナーモジュール３１８と相互作用する。各データ統合プロセスは、少なくとも１つのデータ統合タスクを含む。いくつかの実施形態において、データ統合タスクは、データのどのビットが変換され他のビットと組み合わされるかと、当該データが実際にどのように抽出およびロードされるかの技術的な詳細とを示すビジネスルールのセットによって規定される。好ましい実施形態において、データ統合タスクは、データマッピングを構築するために宣言型のアプローチを使用して特定される。マッピングは、ターゲットと称される、１つのデータストアにポピュレートするオブジェクトであり、１つ以上の他のデータストアからのデータはソースとして既知である。一般に、ソースデータストアにおけるカラムは、マッピングを通じてターゲットデータストアにおけるカラムにリンクされる。マッピングは、パッケージステップとしてパッケージに加えられ得る。上で論じたように、パッケージはデータ統合ジョブを規定する。パッケージは、プロジェクトの下に作成され、各々がマッピングまたはプロシージャであり得るステップの組織されたシーケンスから構成される。パッケージは、１つの入口点および複数の出口点を有し得る。

いくつかの実施形態において、新しいマッピングを作成する場合、デベロッパまたは技術的なビジネスユーザは、どのデータが統合されるかと、どのビジネスルールを使用するべきかとをまず規定するよう、デザイナー３１８と相互作用する。たとえば、デベロッパは、どのテーブルが連結されるべきか、どのフィルタが適用されるべきか、データを変換するためにどのＳＱＬエクスプレッションが使用されるべきかを特定し得る。使用されるＳＱＬの特定の言語は、コードが実行されるべきデータベースプラットホームによって決定される。その後、別個のステップにおいて、技術スタッフは、デザイナー３１８と相互に作用して、このデータを抽出、組合せ、次いで統合するのに最も効率的な方法を選ぶ。たとえば、技術スタッフは、インクリメンタルロード（incremental load）、バルクローティングユーティリティ（bulk-loading utility）、スローリー・チェンジング・ディメンション（slowly changing dimension）、および変更データキャプチャ（changed-data capture）といった、データベースに特有のツールおよび設計技術を使用し得る。

この実施形態において、マッピングはソースおよびターゲット３２６について作成され得る。ソースおよびターゲット３２６は、１つ以上のレガシーアプリケーション３２８と、１つ以上のファイル／ＸＭＬ文書３３０と、１つ以上のアプリケーション３３２と、１つ以上のデータウェアハウス（ＤＷ）と、ビジネスインテリジェンス（ＢＩ）ツールおよびアプリケーションと、エンタープライズプロセスマネージメント（ＥＰＭ：enterprise process management）ツールおよびアプリケーション３３４と、（ランタイムウェブサービス３４０およびエージェント３４２を含む）１つ以上のＪＶＭ３３６とを含み得る。

図４は、本発明のさまざまな実施形態においてデータ統合シナリオが作成され得るさまざまな異種混合のデータソースを有する環境４００のブロック図である。この例において、環境４００はＯＤＩスタジオ３１２およびリポジトリ３０２を含む。リポジトリ３０２は、統合シナリオ４００を生成するのに必要とされるメタデータのすべてを含む。ユーザまたはプロセスは、データ完全性制御４０２および宣言型ルール４０４を使用して統合シナリオ４００を作成するようＯＤＩスタジオ３１２と相互作用する。

オーダアプリケーション４０６は、顧客のオーダをトラッキングするためのアプリケーションを示す。「オーダアプリケーション」データモデルは、オーダアプリケーション４０６に格納されたデータと、任意のデータ完全性制御または条件とを表わすよう作成される。たとえば、「オーダアプリケーション」データモデルは、ハイパーストラクチャードクエリラングエッジデータベース（ＨＳＱＬＤＢ：Hyper Structured Query Language Database）に基づき得、ＳＲＣ＿ＣＩＴＹ、ＳＲＣ＿ＣＵＳＴＯＭＥＲ、ＳＲＣ＿ＯＲＤＥＲＳ、ＳＲＣ＿ＯＲＤＥＲ＿ＬＩＮＥＳ、ＳＲＣ＿ＰＲＯＤＵＣＴおよびＳＲＣ＿ＲＥＧＩＯＮという５つのデータストアを含む。

パラメータファイル４０８は、販売員のリストおよび年齢のセグメンテーションから年齢の範囲を含むプロダクションシステムから発行されるフラットファイル（たとえばＡＳＣＩＩ）を示す。この例において、「パラメータ」データモデルが、フラットファイルにおけるデータを表わすために作成される。たとえば、「パラメータ」データモデルは、ファイルインターフェイスに基づき得、ＳＲＣ＿ＳＡＬＥＳ＿ＰＥＲＳＯＮおよびＳＲＣ＿ＡＧＥ＿ＧＲＯＵＰという２つのデータストアを含み得る。

セールスアドミニストレーションアプリケーション４１０はセールスをトラッキングするためのアプリケーションを示す。セールスアドミニストレーションアプリケーション４１０は、オーダアプリケーション４０６およびパラメータファイル４０８からのデータの変換でポピュレートされたデータウェアハウスであり得る。「セールスアドミニストレーション」データモデルは、セールスアドミニストレーションアプリケーション４１０に格納されるデータと、任意のデータ完全性制御または条件または変換とを表わすよう作成される。たとえば、「セールスアドミニストレーション」データモデルはハイパーストラクチャードクエリラングエッジデータベース（ＨＳＱＬＤＢ）マッピングに基づき得、ＴＲＧ＿ＣＩＴＹ、ＴＲＧ＿ＣＯＵＮＴＲＹ、ＴＲＧ＿ＣＵＳＴＯＭＥＲ、ＴＲＧ＿ＰＲＯＤＵＣＴ、ＴＲＧ＿ＰＲＯＤ＿ＦＡＭＩＬＹ、ＴＲＧ＿ＲＥＧＩＯＮ、およびＴＲＧ＿ＳＡＬＥという６つのデータストアを含み得る。

図５Ａおよび図５Ｂは、データ統合システム２００によって実行され得る従来のデータ統合処理における簡素化されたデータフローを示す。この例において、オーダアプリケーション４０６、パラメータファイル４０８、１つ以上の他の随意または付加的なソースからのデータは、セールスアドミニストレーションアプリケーション４１０にターゲットとされる従来のＥＴＬプロセスを通じて流れる。データ変換は別個のＥＴＬサーバ５００において発生する。シナリオは専用のリソースまたはプロプラエタリリソースを必要とし、パフォーマンスがより貧弱になり、高コストを引き起こす。

図６Ａおよび図６Ｂは、本発明の実施形態に従った、データ統合システム２００によって実行され得る次世代データ統合処理における簡素化されたデータフローを示す。この例において、オーダアプリケーション４０６、パラメータファイル４０８、１つ以上の他の随意または付加的なソースからのデータは、セールスアドミニストレーションアプリケーション４１０にターゲットとされるＥ−ＬＴプロセスを通じて流れる。データ変換は既存のリソースをレバレッジし、パフォーマンスおよび効率がより高くなる。上述したように、先のＥＴＬシステムは、データ変換を実行するために専用および／またはプロプラエタリインフラストラクチャを必要とした。これは、部分には、未知のユーザインフラストラクチャに対応するためになされた。たとえば、どのタイプのデータベースが使用されているか知ることがなければ、先行のＥＴＬシステムは、どの変換オペレーションが所与のシステムにおいて利用可能であるか予想することができなかった。しかしながらこれは、如何なる専用および／またはプロプラエタリインフラストラクチャなしで適切なデータ変換を実行することができるユーザの既存データベースおよびサーバのようなリソースが十分に利用されないことになる。

実施形態に従うと、本発明は、ユーザの特定のニーズに従ってユーザがデータ統合プロセスをカスタマイズすることを可能にすることによってユーザの既存のインフラストラクチャをレバレッジする。たとえば、データ統合プランが設計されると、データ統合プランは、実行単位と称される、単一のシステムによって実行可能である個別の部分に分割され得る。ひとたびデータ統合プランが複数の実行単位に分割されると、ユーザのインフラストラクチャおよびシステムリソースに基づいて、ユーザには物理的なプランが提示され得る。このプランはさらにユーザによって、どのユーザシステムがどの実行単位を実行するかを変更するようカスタマイズされ得る。たとえば、ジョインオペレーションが第１のデータベース上で実行されるプランがユーザには提示され得、ユーザは、第２のデータベースにジョインオペレーションを移動させることによって当該プランをカスタマイズし得る。

図６Ｂに示されるように、これにより、先行のＥＴＬシステムを特徴付けたスタンドアロン変換サーバに依存しない抽出−ロード−変換（Ｅ−ＬＴ：extract-load-transform）アーキテクチャが得られる。代わりに、上述したように、データ変換はユーザの既存のインフラストラクチャ上で実行され得る。Ｅ−ＬＴアーキテクチャは、プロプラエタリ変換サーバを取得および維持することに関連付けられるコストを低減しつつユーザにさらに大きなフレキシビリティを提供する。

図３を再び参照すると、エージェントは統合プロセスに関連付けられる統合タスクのセットをスケジューリングおよび調整するために使用され得る。たとえば、ランタイムにおいて、エージェントは、統合プロセスの実行を調整する。エージェントは、マスターリポジトリ３０４に格納されるコードを抽出し得、さまざまなソースおよびターゲットシステムに接続し得、全体的なデータ統合プロセスまたはシナリオを取りまとめる。さまざまな実施形態において、２つのタイプのエージェントが存在する。一例において、スタンドアロンのエージェントがエージェント３１６のようなデスクトップ３０８上にインストールされる。別の例において、アプリケーションサーバエージェントは（オラクルＷｅｂＬｏｇｉｃサーバの上で展開されるＪａｖａＥＥエージェントのように）アプリケーションサーバ３２６上で展開され得、高いアベイラビリテイ要件についてのクラスタリングのようなアプリケーションサーバレイヤーフィーチャから利益を得ることができる。さらに別の例において、エージェントは、エージェント３４２のように、ソースおよびターゲット３２６上で展開され得る。

この実施形態において、データ統合システム２００は、上で論じられるエージェントの１つ以上を含み得るアプリケーションサーバ３４４を含む。アプリケーションサーバ３４４は、１つ以上のアプリケーションサーバ、ウェブサーバ、またはホストされたアプリケーションを示す。この例において、アプリケーションサーバ３４４は、ＦＭＷコンソール３４６、サーブレットコンテナ３４８、ウェブサービスコンテナ３５０、およびデータソース接続プール３５２を含む。

ＦＭＷコンソール３４６は、サーブレットコンテナ３４８、ウェブサービスコンテナ３５０およびデータソース接続プール３３４に関係する情報のような、アプリケーションサーバ３４４の局面を管理するように構成される１つ以上のハードウェアおよび／またはソフトウェア要素を示す。たとえば、ＦＭＷコンソール３４６は、オラクルＷｅｂＬｏｇｉｃサーバドメインを管理するために使用されるブラウザベースのグラフィカルユーザインターフェイスであり得る。ＦＭＷコンソール３４６は、ＷｅｂＬｏｇｉｃサーバインスタンスを構成、開始、停止し、ＷｅｂＬｏｇｉｃサーバクラスタを構成し、データベース接続性（ＪＤＢＣ）およびメッセージング（ＪＭＳ）のようなＷｅｂＬｏｇｉｃサーバサービスを構成し、ユーザ、グループおよび役割を作成および管理することを含むセキュリティパラメータを構成し、ＪａｖａＥＥアプリケーションを構成および展開し、サーバおよびアプリケーションのパフォーマンスを監視し、サーバおよびドメインのログファイルを閲覧し、アプリケーション展開記述子を閲覧し、選択されたランタイムアプリケーション展開記述子要素を編集する機能を含み得る。いくつかの実施形態において、ＦＭＷコンソール３４６は、プロダクションにおけるデータ統合プロセスへのアクセスをＦＭＷコンソール３４６に提供するＯＤＩプラグイン３５４を含み、エラーカウントを有する実行ログ、処理されたロウの数、実行統計、および実行される実際のコードなどを示し得る。

サーブレットコンテナ３４８は、アプリケーションサーバ３４４の性能を拡張するように構成される１つ以上のハードウェアおよび／またはソフトウェア要素を示す。サーブレットは、ＨＴＭＬフォームから提出されたデータを処理するまたは格納するためにほとんどの場合に使用され、データベースクエリの結果のような動的なコンテンツを提供し、適切な顧客のショッピングカートへ品物を充填するといった、ステートレスＨＴＴＰプロトコルに存在しない状態情報を管理する。サーブレットは典型的に、Ｊａｖａクラスが要求に応答し得るプロトコルである、ＪａｖａサーブレットＡＰＩに準拠するＪａｖａＥＥにおけるＪａｖａクラスである。サーブレットを展開および実行するために、サーブレットコンテナ３４８は、サーブレットと相互作用するウェブサーバのコンポーネントとして使用される。したがって、サーブレットコンテナ３４８は、ウェブサービスコンテナ３５０のパブリックウェブサービス３５６およびデータサービス３５８によって提供される機能と、データソース接続プール３５２によって提供されるデータプールへのアクセスとを拡張し得る。サーブレットコンテナ３４８はさらに、サーブレットのライフサイクルを管理し、特定のサーブレットにＵＲＬをマッピングし、ＵＲＬリクエスタが正しいアクセス権を有することを保証することを担う。

この例において、サーブレットコンテナ３４８は、ＯＤＩ ＳＤＫ３６２に関連付けられるＪａｖａＥＥアプリケーション３６０と、ＯＤＩコンソール３６４と、ＪａｖａＥＥエージェント３６８に関連付けられるランタイムウェブサービス３６６とを含む。ＯＤＩ ＳＤＫ３６２は、データ統合およびＥＴＬ設計のためのソフトウェア開発キット（ＳＤＫ）を提供する。ＯＤＩ ＳＤＫ３６２は、一般的でありかつ非常に反復的である作業の自動化を可能にし、ユーザが反復のタスクをスクリプトにすることを可能にする。

ＯＤＩコンソール３６４は、リポジトリ３０２へのウェブアクセスを提供するＪａｖａエンタープライズエディション（ＪａｖａＥＥ：Java Enterprise Edition）アプリケーションである。ＯＤＩコンソール３６４は、プロジェクト、モデルおよび実行ログを含むDesign-Timeオブジェクトをユーザがブラウズすることを可能にするように構成される。ＯＤＩコンソール３６４は、ユーザがフローマップを閲覧し、すべてのデータのソースを追跡し、データを構築するのに使用される変換を理解するためにフィールドレベルにさらにドリルダウンすることを可能にし得る。さらに、エンドユーザは、ＯＤＩコンソール３６４を通じてシナリオ実行を開始および監視し得る。１つの局面において、ＯＤＩコンソール３６４は、データサーバ、物理および論理スキーマのようなトポロジーオブジェクトを閲覧および編集し、かつ、リポジトリ３０２を管理する能力をアドミニストレータに提供する。

データシナリオ設計および開発
上で論じたように、シナリオは、ソースコンポーネント（マッピング、パッケージ、プロシージャ、変数）をプロダクションに配置するよう設計される。このコンポーネントについて、シナリオがコード（ＳＱＬ、シェルなど）の発生から得られる。シナリオは、エクスポートされ、その後、異なるプロダクション環境へインポートされ得る。

図７は、本発明に従った一実施形態におけるＯＤＩスタジオとデータ統合システムのリポジトリとの間の相互作用の簡略ブロック図である。図７に示される実施形態において、図３のＯＤＩスタジオ３１２は、プロダクションについてデータ統合シナリオ７００を生成するようメタデータおよびルールを使用する。一般に、デザイナーモジュール３１８は、データ完全性チェックを設計するように使用されるとともに、たとえば既存のアプリケーションまたはデータベースの自動リバースエンジニアリング、変換および統合マッピングのグラフィカルデベロップメントおよびメンテナンス、マッピングにおけるデータフローの可視化、自動ドキュメンテーション生成、および生成されたコードのカスタマイゼーションのような変換を構築するように使用される。

図８は、本発明の実施形態に従った、データ統合シナリオを作成するための方法８００のフローチャートを示す。図８に示された方法８００の実現または処理は、コンピュータシステムまたは情報処理デバイスのようなロジックマシンの中央処理装置（ＣＰＵまたはプロセッサ）によって実行される際にソフトウェア（たとえば命令またはコードモジュール）によって実行され得るか、電子デバイスまたは特定用途向け集積回路のハードウェアコンポーネントによって実行され得るか、または、ソフトウェアおよびハードウェア要素の組合せによって実行され得る。図８に示される方法８００は、ステップ８１０において開始する。

さまざまな実施形態において、ユーザはＯＤＩスタジオ３１２のデザイナーモジュール３１８とのセッションを開始し、リポジトリ３０２へ接続し得る。ユーザは１つ以上のユーザインターフェイスフィーチャと相互作用して、新しいデータ統合プロジェクトを作成するか、または、たとえばマスターリポジトリ３０４に格納される既存のデータ統合プロジェクトから選択し得る。一般に、デザイナーモジュール３１８は、メタデータを管理し、データ完全性チェックを設計し、変換を構築するよう使用される。さまざまな実施形態において、デザイナーモジュール３１８を通じて取り扱われる主なオブジェクトはモデルおよびプロジェクトである。データモデルは、データソースまたはターゲットにおけるメタデータのすべてを含む（たとえばテーブル、カラム、制約、記述、相互参照など）。プロジェクトは、ソースまたはターゲット（たとえばマッピング、プロシージャ、変数など）についてロードおよび変換ルールのすべてを含む。

ステップ８２０において、１つ以上のデータモデルが作成される。ステップ８３０において、１つ以上のプロジェクトが作成される。図９は、本発明の実施形態に従った、データ統合シナリオを作成するためのユーザインターフェイス９００のスクリーンショットである。この例において、ナビゲーションパネル９１０は、情報を表示し、プロジェクトとの相互作用のための機能を含む。ナビゲーションパネル９２０は情報を表示し、データモデルとの相互作用のための機能を含む。上で論じたように、ユーザはデータモデルを作成するだけでなく、データモデルにおけるデータについて任意のデータ完全性チェックを開発し得る。さらに、ユーザは、ソースからのデータをターゲットにロードするフローにおいてデータについてのデータ完全性および変換を提供する、プロジェクトについてのマッピングおよびプロシージャ、変数を特定し得る。ステップ８４０では、１つ以上のデータ統合シナリオが生成される。図８はステップ８５０で終了する。

図１０は、本発明の実施形態に従った、マッピングを作成するための方法１０００のフローチャートを示す。図１０に示された方法１０００の実現または処理は、コンピュータシステムまたは情報処理デバイスのようなロジックマシンの中央処理装置（ＣＰＵまたはプロセッサ）によって実行される際にソフトウェア（たとえば命令またはコードモジュール）によって実行され得るか、電子デバイスまたは特定用途向け集積回路のハードウェアコンポーネントによって実行され得るか、または、ソフトウェアおよびハードウェア要素の組合せによって実行され得る。図１０に示される方法１０００は、ステップ１０１０において開始する。

ステップ１０２０において、ターゲットデータストア情報が受け取られる。たとえば、ユーザは、ターゲットデータストア情報を提供するよう、デザイナーモジュール３１８の１つ以上のユーザインターフェイスフィーチャと相互作用し得る。一実施形態において、ユーザは、選択されたデータモデルおよび任意の関連付けられる変換またはデータ完全性チェックの局面を視覚的に表わすマッピングまたはフローパネル上にナビゲーションパネル９１０から、１つ以上のデータモデルを含むターゲットデータストア情報をドラッグアンドドロップし得る。

ステップ１０３０では、ソースデータストア情報が受け取られる。たとえば、ユーザは、ソースデータストア情報を提供するよう、デザイナーモジュール３１８の１つ以上のユーザインターフェイスフィーチャと相互作用し得る。一実施形態において、ユーザは、選択されたデータモデルおよび任意の関連付けられる変換またはデータ完全性チェックの局面を視覚的に表わすターゲットデータストア情報の同じマッピングまたはフローパネル上にナビゲーションパネル９１０から、１つ以上のデータモデルを含むソースデータストア情報をドラッグアンドドロップし得る。

さまざまな実施形態において、ソースデータストア情報およびターゲットデータストア情報は、１つ以上のデータモデルおよび随意にオペレーションから形成され得る。オペレーションのいくつかの例は１つ以上のデータセットオペレーション（たとえばユニオン、ジョイン、インターセクションなど）、データ変換、データフィルタオペレーション、制約、記述、相互参照、または完全性チェックなどを含み得る。さらに別の実施形態において、これらのオペレーションのうちのいくつかは、あらかじめ構成されるとともに、デザイナーモジュール３１８において視覚的に表わされ得る。他の実施形態において、カスタムオペレーションが提供され得、オペレーションを実現するロジックおよびマッピングなどをユーザが特定することを可能にする。

ステップ１０４０において、マッピング情報が受け取られる。たとえば、ユーザは、ターゲットデータストア情報にソースデータストア情報をマッピングするよう、デザイナーモジュール３１８の１つ以上のユーザインターフェイスフィーチャと相互作用し得る。一実施形態において、ユーザは、ソースデータストア情報におけるデータ要素の属性をターゲットデータストア情報におけるデータ要素の属性に視覚的に接続し得る。これは、ソースデータストア情報およびターゲットデータストア情報におけるテーブルのカラム名をマッチングすることにより行われ得る。さらに別の実施形態において、１つ以上の自動マッピング技術がマッピング情報を提供するために使用され得る。

図１１は、本発明の実施形態に従った、データ統合シナリオにおけるマッピング情報を提供するためのユーザインターフェイス１１００のスクリーンショットである。この例において、ソースコンポーネントの属性はターゲットコンポーネントの属性にマッピングされる。

図１０を再び参照して、ステップ１０５０において、データロードストラテジーが受け取られる。データロードストラテジーは、ソースデータストア情報からの実際のデータが抽出フェーズの間にどのようにロードされるべきであるかについての情報を含む。データロードストラテジーは、デザイナー３１８のフロータブにおいて規定され得る。いくつかの実施形態において、データロードストラテジーは、マッピングの構成に依存してフローについて自動的に計算され得る。

たとえば、１つ以上のナレッジモジュールが当該フローのために提案され得る。ナレッジモジュール（ＫＭ）は、異なる技術にわたって再使用可能な変換およびＥＬＴ（抽出、ロード、および変換）ストラテジーを実現するコンポーネントである。１つの局面において、ナレッジモジュール（ＫＭ）はコードテンプレートである。各ＫＭは、全体のデータ統合プロセスにおいて個々のタスクに専用であり得る。ＫＭにおけるコードは、ほとんど置換法で実行されるであろう形で現われ、多くの異なる統合ジョブによって一般的に使用されることを可能にする。生成および実行されるコードは、デザイナーモジュール３１８において規定される宣言型ルールおよびメタデータに由来する。この一例は、オラクルデータベース１０ｇから変更データキャプチャを通じてデータを抽出し、オラクルデータベース１１ｇにおけるパーティショニングされたファクトテーブルに変換データをロードするか、または、マイクロソフトＳＱＬサーバデータベースからのタイムスタンプベースの抽出を作成し、このデータをテラデータエンタープライズデータウェアハウス（Teradata enterprise data warehouse）にロードすることである。

ＫＭの能力はそれらの再使用可能性とフレキシビリティにあり、たとえば、あるロードストラテジーが１つのファクトテーブルのために開発され得、その後、当該ロードストラテジーが他のすべてのファクトテーブルに適用され得る。１つの局面において、所与のＫＭを使用するすべてのマッピングは、ＫＭに対してなされる任意の変化を引き継ぐ。いくつかの実施形態において、統合ナレッジモジュール（ＩＫＭ：integration knowledge module）、ロードナレッジモジュール（ＬＫＭ：loading knowledge module）、およびチェックナレッジモジュールＣＫＭ（check knowledge module）といったように、５つの異なるタイプのＫＭが提供され、それらの各々はソースからターゲットまで変換処理における１つのフェーズをカバーする。

図４を参照して、ユーザは、環境４００においてＳＲＣ＿ＡＧＥ＿ＧＲＯＵＰ、ＳＲＣ＿ＳＡＬＥＳ＿ＰＥＲＳＯＮファイルおよびＳＲＣ＿ＣＵＳＴＯＭＥＲテーブルからデータを抽出する方法を規定し得る。ロードストラテジーを規定するために、ユーザは、ＳＲＣ＿ＡＧＥ＿ＧＲＯＵＰファイルのロードに対応するソースセットを選択し、ＳＱＬへのＬＫＭファイルを選択し得、ファイルからＳＱＬまでのフローを実現する。１つの局面において、ＬＫＭはリモートサーバからステージングエリアにソースデータロードすることを担う。

ステップ１０６０では、データ統合ストラテジーが受け取られる。ローディングフェーズを規定した後、ユーザは、ロードされたデータのターゲットへの統合に適合するべきストラテジーを規定する。統合ストラテジーを規定するために、ユーザは、ターゲットオブジェクトを選択し、ＩＫＭ ＳＱＬインクリメンタルアップデート（IKM SQL Incremental Update）を選択し得る。ＩＫＭは、最終の変換されたデータをターゲットに書き込むことを担う。ＩＫＭは、開始されると、リモートサーバのためのすべてのローディングフェーズは、たとえばすべてのリモートソースデータセットがＬＫＭによってステージングエリアにロードされたといったように、既にそれらのタスクを行なったか、または、ソースデータストアがステージングエリアと同じデータサーバ上に存在するとみなす。

ステップ１０７０では、データ制御ストラテジーが受け取られる。一般に、ＣＫＭは、データセットのレコードが規定された制約と一貫していることをチェックすることを担う。ＣＫＭは、データ完全性を維持するために使用され得、全体的なデータ品質イニシアチブに参加する。ＣＫＭは２つの態様で使用され得る。第１に、既存データの一貫性をチェックするために使用され得る。これは任意のデータストア上またはマッピング内で行われ得る。この場合、チェックされたデータは、現在データストアに存在するデータである。第２の場合において、ターゲットデータストアにおけるデータが、ロードされた後でチェックされる。この場合、ＣＫＭは、ターゲットへの書き込みの前に、結果得られたフロー上のターゲットデータストアの制約をシミュレートする。

図１２は、本発明の実施形態に従った、データ統合シナリオにおいてフロー情報を提供するためのユーザインターフェイス１２００のスクリーンショットである。

ステップ１０８０において、マッピングが生成される。図１０はステップ１０９０において終了する。

データ統合シナリオパッケージおよび展開
上で論じたように、パッケージにおいて異なるステップ（マッピングおよびプロシージャなど）の実行をシーケンス処理するとともに、これらのステップの各々について既存のコードを含んでいるプロダクションシナリオを作り出すことによって、データ統合システム２００においてデータ統合フローの自動化が達成され得る。パッケージは、実行ダイヤグラムへ組織されるステップのシーケンスから構成される。パッケージは、プロダクションのためのシナリオを生成するよう使用されるメインオブジェクトである。シナリオは、ソースコンポーネント（マッピング、パッケージ、プロシージャ、変数）をプロダクションに配置するよう設計される。このコンポーネントについて、シナリオがコード（ＳＱＬ、シェルなど）の発生から得られる。シナリオは、エクスポートされ、その後、異なるプロダクション環境へインポートされ得る。

図１３は、本発明の実施形態に従った、パッケージを作成するための方法のフローチャートを示す。図１３に示された方法１３００の実現または処理は、コンピュータシステムまたは情報処理デバイスのようなロジックマシンの中央処理装置（ＣＰＵまたはプロセッサ）によって実行される際にソフトウェア（たとえば命令またはコードモジュール）によって実行され得るか、電子デバイスまたは特定用途向け集積回路のハードウェアコンポーネントによって実行され得るか、または、ソフトウェアおよびハードウェア要素の組合せによって実行され得る。図１３に示される方法１３００はステップ１３１０において開始する。

ステップ１３２０において、パッケージステップ情報が受け取られる。パッケージステップ情報は、ステップ、要素、プロパティ、およびコンポーネントなどを識別する情報を含む。一例において、ユーザは、パッケージについて１つ以上のステップを作成、識別、またはそうでなければ特定するよう、デザイナーモジュール３１８の１つ以上のユーザインターフェイスフィーチャと相互作用し得る。一実施形態において、１つ以上のコンポーネントが選択され、図に配置される。これらのコンポーネントはパッケージにおけるステップとして現われる。

ステップ１３３０において、パッケージステップシーケンス情報が受け取られる。パッケージステップシーケンス情報は、ステップについてのオーダリング、および従属性などを識別する情報を含む。ひとたびステップが作成されると、ステップがデータ処理チェーンへと順に並べられるかまたは並べ替えられる。一例において、ユーザは、パッケージの１つ以上のステップについてシーケンシングまたはオーダリングを提供するよう、デザイナーモジュール３１８の１つ以上のユーザインターフェイスフィーチャと相互作用し得る。データ処理チェーンは、第１のステップとして規定されたユニークステップを含み得る。一般に、各ステップは、成功または失敗のような１つ以上の終結状態を有する。失敗または成功のようないくつかの状態におけるステップの後には別のステップまたはパッケージの終了が続き得る。１つの局面において、失敗のようないくつかの状態の場合、シーケンス情報は多くの再試行を規定し得る。別の局面において、パッケージはいくつかの可能な終結ステップのみを有し得る。

図１４は、本発明の実施形態に従った、データ統合シナリオにおいてパッケージステップシーケンス情報を提供するためのユーザインターフェイスのスクリーンショットである。

ステップ１３４０において、パッケージが生成される。図１３はステップ１３５０において終了する。

上で論じたように、データ統合フローの自動化は、パッケージにおける異なるステップ（マッピングおよびプロシージャなど）の実行をシーケンス処理することにより達成され得る。次いで、パッケージのステップの各々について既存のコードを含むプロダクションシナリオのために、パッケージが作り出され得る。さまざまな実施形態において、パッケージはプロダクション環境において自動的に実行されるよう展開される。

図１５は、本発明の実施形態に従ったデータ統合シナリオを展開するための方法１５００のフローチャートを示す。図１５に示された方法１５００の実現または処理は、コンピュータシステムまたは情報処理デバイスのようなロジックマシンの中央処理装置（ＣＰＵまたはプロセッサ）によって実行される際にソフトウェア（たとえば命令またはコードモジュール）によって実行され得るか、電子デバイスまたは特定用途向け集積回路のハードウェアコンポーネントによって実行され得るか、または、ソフトウェアおよびハードウェア要素の組合せによって実行され得る。図１５に示される方法１５００はステップ１５１０において開始する。

ステップ１５２０において、統合シナリオが抽出される。一実施形態において、パッケージがリポジトリ３０２から抽出される。ステップ１５３０において、統合シナリオは１つ以上のエージェントに展開される。ステップ１５４０において、統合シナリオは１つ以上のエージェントによって実行される。１つの局面において、統合シナリオは、たとえばＯＤＩスタジオ３１２から、コマンドラインから、またはウェブサービスからといったようにいくつかの態様で実行され得る。たとえば、シナリオ実行は、上に論じられるようにオペレータモジュール３２０などを介して閲覧および監視され得る。図１５はステップ１５５０において終了する。

プロジェクタおよびセレクタタイプの使用
ほとんどのデータ統合システムにおいて、マッピングは、マップの部分を形成するすべての入力および出力属性の明示的な定義を必要とする。典型的なフローベースのＥＴＬツールにおいて、コネクタが属性レベルに形成される。これにより、非常に簡潔なマッピングモデルが得られる。しかしながら、これによりさらに、巨大な数のオブジェクトが生成されるとともに、属性レベルコネクタの数によりマップを構築および維持することが煩雑になる。

さまざまな実施形態において、データ統合システム２００は、マッピングの設計およびメンテナンスを容易にするための１つ以上の技術を組み込む。コンポーネントは、すべての入力および出力属性を特定する必要なく、かつ、コンポーネントレベルコネクタがリルートされることなく、単純に既存の設計に加えられ得る。１つの局面において、アサインメントエクスプレッション（assignment expression）が上流のコンポーネントのすべてまたは部分を参照することを可能にするコンポーネントが実現される。したがって、あるタイプのコンポーネントの属性は、下流のコンポーネントに伝播され得るか、または、そうでなければ、マッピングデザイナー側に対して最小の労力で上流のコンポーネントから引き継がれる。

１つの局面において、データ統合システム２００は、属性レベル接続性を管理する必要性を最小化する。たとえば、データ統合システム２００は、マッピングのコンポーネントを分類し得る（ジョイナー、セット、テーブル、フィルタなど）。カテゴリーのいくつかの例はプロジェクタおよびセレクタである。一般に、プロジェクタは、マップを通って流れるデータの形に影響するコンポーネントである。セレクタはデータのフローを制御するコンポーネントであるが、フローの形を根本的に変更しない。さまざまな実施形態では、上流のコンポーネントの属性が可視であるという点において、セレクタタイプコンポーネントはトランスピアレントに構成される。プロジェクタタイプコンポーネントは、上流のコンポーネントの属性が可視ではなく、データフローの形で利用可能になったもののみ可視であるという点で、透過ではない（opaque）であるように構成される。

したがって、上流からのデータを閲覧することを可能にするためには、下流のコンポーネントの属性に各属性が接続されることが必要されており、さまざまな実施形態において、データ統合システム２００は、ユーザが最も近いプロジェクタの属性までおよび当該属性を含む任意の上流の属性を直接的に参照することを可能にする。したがって、データ統合システム２００は、マッピングの設計およびメンテナンスを非常に容易にする。データ統合システム２００はさらに、既存の設計へのコンポーネントの追加、典型的には単に必要なレベルコネクタをリルートすることを簡易にする。

図１６Ａおよび図１６Ｂは、本発明に従った一実施形態におけるマッピングの簡略ブロック図である。この例において、図１６Ａのマッピング１６００は、データソースＳＲＣ＿ＥＭＰを表わすコンポーネント１６１０と、データソースＳＲＣ＿ＤＥＰＴを表わすコンポーネント１６２０と、データターゲットＴＧＴ＿ＥＭＰＤＥＰＴを表わすコンポーネント１６３０とを含む。データターゲットＴＧＴ＿ＥＭＰＤＥＰＴを更新するために、データソースＳＲＣ＿ＥＭＰおよびＳＲＣ＿ＤＥＰＴについてジョインが必要とされる。ＪＯＩＮを表わすコンポーネント１６４０は、入力としてコンポーネント１６１０および１６２０に接続するとともに出力としてコンポーネント１６３０に接続するマッピング１６００に加えられる。コンポーネント１６４０は（ＳＲＣ＿ＥＭＰ．ＤＥＰＴＮＯ＝ＳＲＣ＿ＤＥＰＴ．ＤＥＰＴＮＯ）といったジョインエクスプレッションを提供するように構成される。

従来のデータ統合システムにおいて、マッピング１６００は、ＪＯＩＮを表わすコンポーネント１６４０の部分を形成するすべての入力および出力属性の明示的な定義を必要とする。対照的に、さまざまな実施形態において、マッピングデベロッパは、コンポーネント１６４０を通って流れているためコンポーネント１６３０に可視である、コンポーネント１６１０によって表わされるデータソースＳＲＣ＿ＥＭＰの属性およびコンポーネント１６２０によって表わされるデータソースＳＲＣ＿ＤＥＰＴの属性からデータターゲットＴＧＴ＿ＥＭＰＤＥＰＴのカラムがどのように直接的にポピュレートされるかを定義し得る。たとえば、ターゲットカラムＴＧＴ＿ＥＭＰＤＥＰＴ．ＮＡＭＥのアサインメントは、コンポーネント１６４０の属性への参照の必要なく、ＳＲＣ＿ＥＭＰ．ＥＮＡＭＥを参照し得る。

図１７は、本発明の実施形態に従った、コンポーネントタイプに基づいてコンポーネント属性を導き出すための方法１７００のフローチャートを示す。図１７に示される方法１７００の実現または処理は、コンピュータシステムまたは情報処理デバイスのようなロジックマシンの中央処理装置（ＣＰＵまたはプロセッサ）によって実行される際にソフトウェア（たとえば命令またはコードモジュール）によって実行され得るか、電子デバイスまたは特定用途向け集積回路のハードウェアコンポーネントによって実行され得るか、または、ソフトウェアおよびハードウェア要素の組合せによって実行され得る。図１７に示される方法１７００はステップ１７１０において開始する。

ステップ１７２０において、コンポーネントについてのコンポーネントタイプが決定される。上で論じたように、いくつかのタイプのコンポーネントは、マッピングを通って流れるデータの形に影響する一方、他のタイプのコンポーネントは、データのフローを制御するがフローの形を根本的に変更しない。ステップ１７３０において、下流のコンポーネントについての属性はコンポーネントタイプに基づいて決定される。たとえば、コンポーネントがデータのフローを制御するがフローの形を根本的に変更しない場合、データ統合システム２００は上流のコンポーネントの属性に基づいて属性のセットを導き出し得る。ステップ１７４０では、導き出されたコンポーネントは、下流のコンポーネントに晒される。図１７はステップ１７５０において終了する。したがって、ターゲットカラムＴＧＴ＿ＥＭＰＤＥＰＴ．ＮＡＭＥのアサインメントは、コンポーネント１６４０の属性への参照の必要なく、ＳＲＣ＿ＥＭＰ．ＥＮＡＭＥをトランスピアレントに参照し得る。

データ統合システム２００はさらに、既存の設計へのコンポーネントの追加、典型的には単に必要なレベルコネクタをリルートすること、を簡易にする。たとえば、フィルタコンポーネントが設計に加えられると、コンポーネントレベルコネクタの変更は、ある下流のコンポーネントの属性のアサインメントに対する変更を必要としない。

図１８は、本発明に従った一実施形態における、フィルタコンポーネント１８００を有するマッピング１６００の簡略ブロック図である。この例において、マッピング１６００は、コンポーネント１６１０とコンポーネント１６４０との間に配置されるフィルタコンポーネント１８００を含む。（たとえばフィルタＳＲＧ＿ＥＭＰ．ＳＡＬ＞３０００を使用して）マッピング１６００へフィルタコンポーネント１８００を加えるために、ユーザは、コンポーネント１６１０とコンポーネント１６４０との間のグラフへフィルタコンポーネント１８００を加える必要があるだけである。コンポーネントレベルコネクタは、フィルタコンポーネント１８００が入力としてコンポーネント１６１０に接続するとともに出力としてのコンポーネント１６４０に接続するように再リンクされる必要がある。そのような変更は、マッピング１６００において、如何なる下流のアサインメントへの変更も必要としない。従来のフローツールでは、カラムレベルのすべては、新しいコンポーネントの導入によって再リンクされる必要がある。

図１９は、本発明に従った一実施形態におけるマッピング１９００の簡略ブロック図である。この例において、マッピング１９００は、データソースを表わすコンポーネントＳ１と、データソースを表わすコンポーネントＳ２と、データターゲットを表わすコンポーネントＴとを含む。コンポーネントＣ１、Ｃ２およびＣ３は、マッピングを通って流れるデータの形に影響するように構成されるか、または、データのフローを制御するがフローの形を根本的に変更しないように構成される。この例において、コンポーネントＣ１はプロジェクタタイプである。したがって、コンポーネントＣ１は、下流のコンポーネント（たとえばコンポーネントＣ３以下）から閲覧されると、（いくつかがコンポーネントＳ１の１つ以上の属性から宣言される）属性の宣言されたセットを有しており、コンポーネントＣ３はセレクタタイプである。したがって、コンポーネントＣ３は（いくつかは、下流のコンポーネント（たとえばコンポーネントＴ）から閲覧されると、コンポーネントＣ１およびＣ２の１つ以上の属性から導出される）属性の導出されたセットを有する。

図２０は、本発明の実施形態に従った、コンポーネントを生成するための方法２０００のフローチャートを示す。図２０に示された方法２０００の実現または処理は、コンピュータシステムまたは情報処理デバイスのようなロジックマシンの中央処理装置（ＣＰＵまたはプロセッサ）によって実行される際にソフトウェア（たとえば命令またはコードモジュール）によって実行され得るか、電子デバイスまたは特定用途向け集積回路のハードウェアコンポーネントによって実行され得るか、または、ソフトウェアおよびハードウェア要素の組合せによって実行され得る。図２０に示される方法２０００はステップ２０１０において開始する。

ステップ２０２０において、コンポーネント定義が受け取られる。たとえば、コンポーネント定義はルール、オペレーション、プロシージャ、変数、およびシーケンスなどを含み得る。ステップ２０３０において、コンポーネントタイプが受け取られる。たとえば、コンポーネントがフローにおけるデータの形を変更する場合、コンポーネントは１つの態様で分類され得る。コンポーネントがデータのフローを制御するがフローの形を根本的に変更しない場合、コンポーネントは別の態様で分類され得る。ステップ２０４０では、コンポーネントが生成され、データ統合システム２００によって使用され得る。図２０はステップ２０５０において終了する。

したがって、データ統合システム２００はユーザがプラットホームおよび技術に依存しない論理設計を作成することを可能にする。ユーザは、どのようにデータがソースとターゲットとの間に流れることをユーザが望むかをハイレベルで規定する論理設計を作成し得る。ユーザのインフラストラクチャを考慮して、ツールは、論理設計を分析し得、物理的設計を作成する。論理設計は、設計における各ソースおよびターゲットに対応する複数のコンポーネントと、ジョインまたはフィルタのようなオペレーションと、アクセスポイントとを含み得る。物理的設計に転送された際の各コンポーネントは、データに対してオペレーションを実行するようコードを生成する。存在する技術（たとえばＳＱＬサーバ、オラクル、Ｈａｄｏｏｐなど）と使用される言語（ＳＱＬ、ｐｉｇなど）とに依存して、各コンポーネントによって生成されるコードは異なり得る。

したがって、データ統合システムのユーザは、論理設計における各コンポーネントにて、始めから終わりまですべてのデータ属性を特定することは必要とされない。データ統合システム２００は、論理設計を通って流れる情報を完全に宣言する必要性を回避する、プロジェクタおよびセレクタタイプのような複数のコンポーネントタイプを提供する。データ統合システム２００は、所定のコンポーネントタイプによって表わされるオペレーションにてどの属性が必要かを決定することができる。これは設計およびメンテナンスの両方を簡素化する。

結論
図２１は、本発明の実施形態を実施するために使用され得るコンピュータシステム２１００の簡略ブロック図である。図２１に示されるように、コンピュータシステム２１００は、バスサブシステム２１２０を介して多くの周辺機器と通信するプロセッサ２１１０を含む。これらの周辺機器は、メモリサブシステム２１４０およびファイルストレージサブシステム２１５０を含むストレージサブシステム２１３０と、入力デバイス２１６０と、出力デバイス２１７０と、ネットワークインターフェイスサブシステム２１８０とを含み得る。

バスサブシステム２１２０は、コンピュータシステム２１００のさまざまなコンポーネントおよびサブシステムを意図されるように互いと通信させるためのメカニズムを提供する。バスサブシステム２１２０は単一のバスとして概略的に示されるが、バスサブシステムの代替的な実施形態は複数のバスを利用してもよい。

ストレージサブシステム２１３０は、本発明の機能を提供する基本的なプログラミングおよびデータ構造を格納するように構成され得る。本発明の機能を提供するソフトウェア（コードモジュールまたは命令）は、ストレージサブシステム２１３０に格納され得る。これらのソフトウェアモジュールまたは命令は、プロセッサ２１１０によって実行され得る。ストレージサブシステム２１３０は、さらに本発明に従って使用されるデータを格納するためのリポジトリを提供し得る。ストレージサブシステム２１３０は、メモリサブシステム２１４０とファイル／ディスクストレージサブシステム２１５０とを含み得る。

メモリサブシステム２１４０は、プログラム実行の間に命令およびデータの格納のためのメインランダムアクセスメモリ（ＲＡＭ）２１４２と、固定された命令が格納されるリードオンリメモリ（ＲＯＭ）２１４４とを含む多くのメモリを含み得る。ファイルストレージサブシステム２１５０は、プログラムおよびデータファイルのための持続性（不揮発性）ストレージを提供しており、ハードディスクドライブ、関連するリムーバブル媒体を有するフロッピー（登録商標）ディスクドライブ、コンパクトディスクリードオンリメモリ（ＣＤ−ＲＯＭ）ドライブ、ＤＶＤ、オプティカルドライブ、リムーバブル媒体カートリッジ、および他の同様のストレージ媒体を含み得る。

入力デバイス２１６０は、キーボードと、マウス、トラックボール、タッチパッドまたはグラフィックスタブレットのようなポインティングデバイスと、スキャナと、バーコードスキャナと、ディスプレイに組み込まれるタッチスクリーンと、音声認識システム、マイクロホンのような音声入力デバイスと、他のタイプの入力デバイスとを含み得る。一般に、「入力デバイス」という用語の使用は、コンピュータシステム２１００に情報を入力するためのすべての可能なタイプのデバイスおよびメカニズムを含むように意図される。

出力デバイス２１７０は、ディスプレイサブシステム、プリンタ、ファックスマシン、または音声出力デバイスなどのノンビジュアルディスプレイを含み得る。ディスプレイサブシステムは、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）のようなフラットパネルデバイス、または投射デバイスであり得る。一般に、「出力デバイス」という用語の使用は、コンピュータシステム２１００から情報を出力するためのすべての可能なタイプのデバイスおよびメカニズムを含むように意図される。

ネットワークインターフェイスサブシステム２１８０は、他のコンピュータシステム、デバイス、および通信ネットワーク２１９０のようなネットワークにインターフェイスを提供する。ネットワークインターフェイスサブシステム２１８０は、コンピュータシステム２１００からデータを受け取るとともに他のシステムにデータを送信するためのインターフェイスとして機能する。通信ネットワーク２１９０のいくつかの例は、プライベートネットワーク、パブリックネットワーク、専用回線、インターネット、イーサネットネットワーク、トークンリングネットワーク、および光ファイバーネットワークなどである。

コンピュータシステム２１００は、パーソナルコンピュータ、ポータブルコンピュータ、ワークステーション、ネットワークコンピュータ、メインフレーム、キオスクまたは任意の他のデータ処理システムを含むさまざまなタイプのものであり得る。コンピュータおよびネットワークの絶えず変化する性質により、コンピュータシステムの好ましい実施形態を説明する目的のために、図２１に示されるコンピュータシステム２１００の説明は特定の例としてのみ意図される。図２１に示されたシステムよりも多くまたはより少ないコンポーネントを有する多くの構成が可能である。

図２２は、実施形態に従ったデータマッピングの生成を促進するためのシステム２２００の簡略ブロック図である。図２２においてシステム２２００に含まれるユニットは、コンピュータシステムまたは情報処理デバイスのようなロジックマシンの中央処理装置（ＣＰＵまたはプロセッサ）によって実行される際にソフトウェア（たとえば命令またはコードモジュール）において実行され得るか、電子デバイスまたは特定用途向け集積回路のハードウェアコンポーネントにおいて実行され得るか、または、ソフトウェアおよびハードウェア要素の組合せにおいて実現され得る。

図２２に示されるように、特に、データ統合システム２２００は、受取部２２１０、判定部２２２０および生成部２２３０を含み得る。受取部２２１０は、論理設計の１つ以上のコンポーネントを特定する情報を受け取るように構成され得、１つ以上のコンポーネントのうちの少なくとも１つは第１のタイプである。判定部２２２０は、論理設計における上流のコンポーネントに基づいて、第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つの論理設計における下流のコンポーネントに可視であるデータ属性のセットを判定するように構成され得る。生成部２２３０は、第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つの論理設計における下流のコンポーネントに可視である属性のセットを示す情報を生成するように構成され得る。

実施形態に従うと、第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つの論理設計における下流のコンポーネントに可視であるデータ属性のセットを判定することは、上流のコンポーネントから可視である１つ以上の属性を導き出すことと、下流のコンポーネントに１つ以上の属性をエクスポーズすることとを含み得る。

実施形態に従うと、論理設計の１つ以上のコンポーネントを特定する情報は、論理設計を通って流れる情報の形を変更するオペレーションを示す情報を含み得る。

実施形態に従うと、論理設計の１つ以上のコンポーネントを特定する情報は、論理設計を通って流れる情報のフローを制御するが論理設計を通って流れる情報の形を変更しないオペレーションを示す情報を含み得る。

実施形態に従うと、論理設計の１つ以上のコンポーネントを特定する情報は、ソースデータストアに格納されるデータの１つ以上の属性を有するソースコンポーネントを示す情報を含み得る。

実施形態に従うと、論理設計の１つ以上のコンポーネントを特定する情報は、ターゲットデータストアに格納されるデータの１つ以上の属性を有するターゲットコンポーネントを示す情報を含み得る。

実施形態に従うと、第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つの論理設計における下流のコンポーネントに可視である属性のセットを示す情報を生成することは、下流のコンポーネントに属性のリストをエクスポートすることを含み得る。

実施形態に従うと、受取部２２１０はさらに、論理設計へのコンポーネントまたは属性の導入または除去による論理設計における変更を受け取るように構成され得る。判定部２２２０はさらに、論理設計における変更が、第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つに影響するかどうかを判定するように構成され得る。論理設計における変更が、第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つに影響するという判定に基づいて、判定部２２２０はさらに、下流のコンポーネントに可視であるデータ属性の更新されたセットを決定するように構成され得る。

実施形態に従うと、データ統合システム２２００は保存部２２４０をさらに含み得る。受取部２２１０はさらに、論理設計へのコンポーネントまたは属性の導入による論理設計における変更を受け取るように構成され得る。判定部２２２０はさらに、論理設計における変更が、第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つに影響するかどうか判定するように構成され得る。論理設計における変更が第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つに影響するという判定に基づいて、保存部２２４０は下流のコンポーネントに可視であるデータ属性のセットを保存するように構成され得る。

実施形態に従うと、データ統合システム２２００はリネーム部２２５０をさらに含み得る。受取部２２１０はさらに、コンポーネントまたは属性をリネームする、論理設計における変更を受け取るように構成され得る。判定部２２２０はさらに、論理設計における変更が、第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つに影響するかどうかを判定するように構成され得る。論理設計における変更が第１のタイプである１つ以上のコンポーネントのうちの少なくとも１つに影響するという判定に基づいて、リネーム部２２５０は下流のコンポーネントに可視であるデータ属性のセットをリネームするように構成され得る。

本発明の具体的な実施形態を記載してきたが、さまざまな修正例、変更例、代替的な構成、および均等例も本発明の範囲内に含まれる。記載された発明は、ある特定のデータ処理環境内のオペレーションに制限されず、複数のデータ処理環境において自由に作用する。さらに、特定の一連のトランザクションおよびステップを使用して本発明が記載されたが、本発明の範囲は記載された一連のトランザクションおよびステップに限定されるわけではないということは当業者に明らかであるはずである。

さらに、本発明をハードウェアおよびソフトウェアの特定の組合せを用いて説明したが、ハードウェアおよびソフトウェアの他の組合せも本発明の範囲内であると認識されるべきである。本発明は、ハードウェアのみで、またはソフトウェアのみで、またはその組合せを使用して実現され得る。

したがって、明細書および図面は、限定的な態様ではなく例示的な態様であるとみなされるべきである。しかしながら、添付の特許請求の範囲に記載されるより広い本発明の精神および範囲から逸脱することがなければ、追加、削減、削除、ならびに、他の修正および変更もなされてもよいということが明らかであろう。

その教示がこの開示内に示され得る１つ以上の発明のいずれかのさまざまな実施形態がソフトウェア、ファームウェア、ハードウェアまたはその組合せにおけるロジックの形で実現され得る。ロジックは、この開示において示された発明のさまざまな実施形態において開示され得るステップのセットを実行するために、ロジックマシンの中央処理装置（ＣＰＵまたはプロセッサ）を指示するように適合される命令のセットとして、マシンアクセス可能なメモリ、マシン読み取り可能な物品、有形的なコンピュータ読取可能媒体、コンピュータ読取可能記憶媒体、または他のコンピュータ／マシン読取可能媒体に格納され得る。ロジックは、この開示に示される発明のさまざまな実施形態における方法またはプロセスを行うよう実行される際に、コードモジュールがコンピュータシステムまたは情報処理デバイスのプロセッサにより作動状態になると、ソフトウェアプログラムまたはコンピュータプログラムプロダクトの一部を形成し得る。本願明細書において提供されるこの開示および教示に基づいて、示された発明の１つ以上のさまざまな実施形態の開示されたオペレーションまたは機能のいずれかをソフトウェア、ファームウェア、ハードウェアまたはその組合せで実現するための他の態様、変形例、修正例、代替例および／または方法を当業者は理解するであろう。

その教示がこの開示に示され得るそれらの発明のいずれか１つの開示された例、実現例およびさまざまな実施形態は、当業者にこの開示の教示を妥当な明瞭さで伝えるために単に例示的である。これらの実現例および実施形態は例示的な図または特定の図を参照して記載され得る際に、記載される方法および／または特定の構造のさまざまな修正例または適合例は当業者に明らかになり得る。本願明細書において発見されるこの開示およびこれらの教示に依存し、かつ、当該教示によって技術を進歩させたすべてのそのような修正例、適合例または変形例は、その教示がこの開示内に示され得る１つ以上の発明の範囲内に存在すると考えられるべきである。したがって、開示内に示された発明が具体的に示される実施形態にまったく限定されないということが理解されるので、この記載および図は限定的な意味で考えられるべきでない。

したがって、上記の記載および如何なる添付の図面、説明および図は、例示的であるが限定的ではないように意図される。したがって、この開示に示される如何なる発明の範囲も、上記の記載および図に示されるそれらの実施形態を単純に参照してではなく、それらの完全な範囲または均等物とともに係属中の請求項を参照して決定されるべきである。

Claims (13)

1. データマッピングの生成を促進するための方法であって、
   論理設計の１つ以上のコンポーネントを特定する情報を１つ以上のコンピュータシステムにて受け取ることを含み、前記１つ以上のコンポーネントのうちの少なくとも１つは第１のタイプであり、前記方法はさらに、
   前記１つ以上のコンピュータシステムに関連付けられる１つ以上のプロセッサにより、前記論理設計における上流のコンポーネントに基づいて、前記第１のタイプである前記１つ以上のコンポーネントのうちの少なくとも１つの前記論理設計における下流のコンポーネントに可視であるオブジェクトのデータ属性のセットを判定することと、
   前記第１のタイプである前記オブジェクトのデータ属性のセットを集合させることと、
   前記１つ以上のコンピュータシステムに関連付けられる前記１つ以上のプロセッサにより、前記第１のタイプである前記１つ以上のコンポーネントのうちの少なくとも１つの前記論理設計における前記下流のコンポーネントに可視であるオブジェクトのデータ属性のセットを含む集合を示す情報を生成することとを含む、方法。
2. 前記１つ以上のコンピュータシステムに関連付けられる前記１つ以上のプロセッサにより、前記第１のタイプである前記１つ以上のコンポーネントのうちの少なくとも１つの前記論理設計における前記下流のコンポーネントに可視であるオブジェクトのデータ属性の前記セットを判定することは、前記上流のコンポーネントから可視であるオブジェクトの１つ以上の属性を導き出すことと、前記下流のコンポーネントに前記１つ以上の属性をエクスポーズすることとを含む、請求項１に記載の方法。
3. 前記論理設計の前記１つ以上のコンポーネントを特定する前記情報を受け取ることは、前記論理設計を通って流れる情報の形を変更するオペレーションを示す情報を受け取ることを含む、請求項１または２に記載の方法。
4. 前記論理設計の前記１つ以上のコンポーネントを特定する前記情報を受け取ることは、前記論理設計を通って流れる情報のフローを制御するが前記論理設計を通って流れる前記情報の形を変更しないオペレーションを示す情報を受け取ることを含む、請求項１〜３のいずれか１項に記載の方法。
5. 前記論理設計の前記１つ以上のコンポーネントを特定する前記情報を受け取ることは、ソースデータストアに格納されるデータの１つ以上の属性を有するソースコンポーネントを示す情報を受け取ることを含む、請求項１〜４のいずれか１項に記載の方法。
6. 前記論理設計の前記１つ以上のコンポーネントを特定する前記情報を受け取ることは、ターゲットデータストアに格納されるデータの１つ以上の属性を有するターゲットコンポーネントを示す情報を受け取ることを含む、請求項１〜５のいずれか１項に記載の方法。
7. 前記第１のタイプである前記１つ以上のコンポーネントのうちの少なくとも１つの前記論理設計における前記下流のコンポーネントに可視であるオブジェクトのデータ属性のセットを含む集合を示す前記情報を生成することは、前記下流のコンポーネントに属性のリストをエクスポートすることを含む、請求項１〜６のいずれか１項に記載の方法。
8. 前記論理設計へのコンポーネントまたは属性の導入または除去による前記論理設計における変更を前記１つ以上のコンピュータシステムにて受け取ることと、
   前記１つ以上のコンピュータシステムに関連付けられる前記１つ以上のプロセッサにより、前記論理設計における前記変更が前記第１のタイプである前記１つ以上のコンポーネントのうちの少なくとも１つに影響するかどうかを判定することと、
   前記論理設計における前記変更が前記第１のタイプである前記１つ以上のコンポーネントの少なくとも１つに影響するという判定に基づいて、前記１つ以上のコンピュータシステムに関連付けられる前記１つ以上のプロセッサにより、前記下流のコンポーネントに可視であるオブジェクトのデータ属性の更新されたセットを判定することとをさらに含む、請求項１〜７のいずれか１項に記載の方法。
9. 前記論理設計へのコンポーネントまたは属性の導入による前記論理設計における変更を前記１つ以上のコンピュータシステムにて受け取ることと、
   前記１つ以上のコンピュータシステムに関連付けられる前記１つ以上のプロセッサにより、前記論理設計における前記変更が前記第１のタイプである前記１つ以上のコンポーネントのうちの少なくとも１つに影響するかどうかを判定することと、
   前記論理設計における前記変更が前記第１のタイプである前記１つ以上のコンポーネントのうちの少なくとも１つに影響するという判定に基づいて、前記下流のコンポーネントに可視であるオブジェクトのデータ属性の前記セットを保存することとをさらに含む、請求項１〜８のいずれか１項に記載の方法。
10. コンポーネントまたは属性をリネームする前記論理設計における変更を、前記１つ以上のコンピュータシステムにて受け取ることと、
    前記１つ以上のコンピュータシステムに関連付けられる前記１つ以上のプロセッサにより、前記論理設計における前記変更が前記第１のタイプである前記１つ以上のコンポーネントのうちの少なくとも１つに影響するかどうかを判定することと、
    前記論理設計における前記変更が前記第１のタイプである前記１つ以上のコンポーネントのうちの少なくとも１つに影響するという判定に基づいて、前記下流のコンポーネントに可視であるオブジェクトのデータ属性の前記セットをリネームすることとをさらに含む、請求項１〜９のいずれか１項に記載の方法。
11. データマッピングの生成を促進するためのコンピュータ実行可能コードを含むコンピュータ読取可能プログラムであって、
    論理設計の１つ以上のコンポーネントを特定する情報を受け取るためのコードを含み、前記１つ以上のコンポーネントのうちの少なくとも１つは第１のタイプであり、
    前記論理設計における上流のコンポーネントに基づいて、前記第１のタイプである前記１つ以上のコンポーネントのうちの少なくとも１つの前記論理設計における下流のコンポーネントに可視であるオブジェクトのデータ属性のセットを判定するためのコードと、
    前記第１のタイプである前記オブジェクトのデータ属性のセットを集合させるためのコードと、
    前記第１のタイプである前記１つ以上のコンポーネントのうちの少なくとも１つの前記論理設計における前記下流のコンポーネントに可視であるオブジェクトのデータ属性のセットを含む集合を示す情報を生成するためのコードとを含む、コンピュータ読取可能プログラム。
12. コンピュータによって実行されると、請求項１〜１０のいずれか１項に記載の方法を当該コンピュータに実施させるコンピュータ読取可能プログラム。
13. データマッピングの生成を促進するためのシステムであって、
    プロセッサと、
    前記プロセッサと通信し、かつ、命令のセットを格納するように構成されるメモリとを含み、前記命令のセットは、前記プロセッサによって実行されると、
    論理設計の１つ以上のコンポーネントを特定する情報を受け取るように前記プロセッサを構成し、前記１つ以上のコンポーネントのうちの少なくとも１つは第１のタイプであり、前記命令のセットはさらに、
    前記論理設計における上流のコンポーネントに基づいて、前記第１のタイプである前記１つ以上のコンポーネントのうちの少なくとも１つの前記論理設計における下流のコンポーネントに可視であるオブジェクトのデータ属性のセットを判定し、
    前記第１のタイプである前記オブジェクトのデータ属性のセットを集合させ、
    前記第１のタイプである前記１つ以上のコンポーネントのうちの少なくとも１つの前記論理設計における前記下流のコンポーネントに可視であるオブジェクトのデータ属性のセットを含む集合を示す情報を生成するように前記プロセッサを構成する、システム。