(57)【要約】【課題】  機能の使用、再使用および変更を変化するビジネス環境において可能にするデータ統合システム・ツールを提供すること。【解決手段】  追加のデータを必要とすることなく、他のアイテムとの関係に基づいてアイテムの識別を可能にする意味識別子と、データ、メタデータ、意味識別子その他のアイテムを、あるフォーマット、言語、および／またはデータ・モデルから他のものに変換することができる変換エンジンと、アイテムの多数のインスタンスまたは形式の区別を可能にする、ハブまたはデータベースの抽象化プロパティ・レベルとに関連する方法およびシステムが提供される。【選択図】      図１
2008511936.tif 000002
【特許請求の範囲】
【請求項１】
他のアイテムとの関係に基づいてアイテムを識別するための意味識別子を提供するステップと、
データ・モデル内のアイテムについての前記意味識別子の判定を可能にするために、データ・モデルのマッピングを獲得するステップと、
前記マッピングを、マッピングおよび前記意味識別子のうちの少なくとも１つに基づいて実行されるデータ統合機能と関連付けるステップと、
を含む、
データ統合のための方法。
【請求項２】
前記アイテムは、オブジェクト、データ・アイテム、データ、列、行、テーブル、データベース、インスタンス、属性、メタデータ、概念、トピック、主題、識別子、意味識別子、ＲＦＩＤタグ、ベンダー、供給業者、顧客、人、チーム、組織、ユーザ、ネットワーク、システム、装置、家族、店、製品、製造ライン、製品特性、製品仕様、製品属性、価格、コスト、材料仕様書、出荷データ、税金データ、コース、教育プログラム、位置、地図、部門、組織、有機的組織体、プロセス、規則、法、評価システム、商品、サービスおよびサービス提供のうちの１以上を含む、請求項１に記載の方法。
【請求項３】
前記関係は、関係階層におけるアイテムの位置を含む、請求項１に記載の方法。
【請求項４】
前記意味識別子は、アイテムについての固有の識別子である、請求項１に記載の方法。
【請求項５】
前記意味識別子は、前記アイテムの他のアイテムとのすべての関係より少ない数であって、当該識別子が固有であるために十分な数の関係に基づいている、請求項１に記載の方法。
【請求項６】
前記意味識別子は、当該識別子が固有であるために必要な最小数の関係に基づいている、請求項１に記載の方法。
【請求項７】
前記意味識別子は、アイテムについてのコンテキスト依存識別子である、請求項１に記載の方法。
【請求項８】
前記意味識別子は、アトミック・フォーマットで格納される、請求項１に記載の方法。
【請求項９】
前記意味識別子は、アトミック・フォーマットでデータ・リポジトリ内に格納される、請求項１に記載の方法。
【請求項１０】
前記意味識別子は動的なものである、請求項１に記載の方法。
【請求項１１】
前記意味識別子はコンテキストによって変化する、請求項１に記載の方法。
【請求項１２】
データ統合プロセスを実行する方法であって、
モデルをデータ・セットと関連付けるステップと、
前記データ・セットからアイテムを選択するための選択コマンドを、前記モデルから判定される前記アイテムについての区別特性に基づいて形成するステップと、
を含む、
方法。
【請求項１３】
前記選択コマンド／クエリの前記形成は、当該選択コマンド／クエリを使用されるプロセスの実行時に行われる、請求項１２に記載の方法。
【請求項１４】
前記選択コマンド／クエリの前記形成は、当該選択コマンド／クエリを使用されるプロセスの設計時に行われる、請求項１２に記載の方法。
【請求項１５】
データ統合プロセスを実行する方法であって、
モデルをデータ・セットと関連付けるステップと、
前記データ・セットを照会するためのクエリを、前記モデルから判定される前記アイテムについての区別特性に基づいて形成するステップと、
を含む、
方法。
【請求項１６】
前記選択コマンド／クエリの前記形成は、当該選択コマンド／クエリを使用されるプロセスの実行時に行われる、請求項１５に記載の方法。
【請求項１７】
前記選択コマンド／クエリの前記形成は、当該選択コマンド／クエリを使用されるプロセスの設計時に行われる、請求項１５に記載の方法。
【請求項１８】
データ統合のためのシステムであって、
他のアイテムとの関係に基づいてアイテムを識別するための意味識別子と、
データ・モデル内のアイテムについての前記意味識別子の判定を可能にするためのデータ・モデルのマッピングと、
前記マッピングを、マッピングおよび前記意味識別子のうちの少なくとも１つに基づいて実行されるデータ統合機能と関連付けるための機構と、
を備える
、システム。
【請求項１９】
前記関係は、関係階層におけるアイテムの位置を含む、請求項１８に記載のシステム。
【請求項２０】
前記意味識別子は、アイテムについての固有の識別子である、請求項１８に記載のシステム。
【請求項２１】
前記意味識別子は、前記アイテムの他のアイテムとのすべての関係より少ないが、当該識別子が固有のものであることを確実にするのに十分な数の関係に基づいている、請求項１８に記載のシステム。
【請求項２２】
前記意味識別子は、当該識別子が固有のものであることを確実にする最小数の関係に基づいている、請求項１８に記載のシステム。
【請求項２３】
前記意味識別子は、アイテムについてのコンテキスト依存識別子である、請求項１８に記載のシステム。
【請求項２４】
前記意味識別子は、アトミック・フォーマットで格納される、請求項１８に記載のシステム。
【請求項２５】
前記意味識別子は、アトミック・フォーマットでデータ・リポジトリ内に格納される、請求項１８に記載のシステム。
【請求項２６】
前記意味識別子は動的なものである、請求項１８に記載のシステム。
【請求項２７】
前記意味識別子はコンテキストによって変化する、請求項１８に記載のシステム。
【請求項２８】
前記意味識別子は、第２のアイテムに対して直接的な関係を有する第１のアイテムに対する直接的な関係を取得することによって、前記第２のアイテムに対する間接的な関係を再帰的に取得する、請求項１８に記載のシステム。
【請求項２９】
前記意味識別子は、文字列で取得され、前記文字列は、固有識別子のためにすべての要素が必要とされない場合に切り捨てられる、請求項１８に記載のシステム。
【請求項３０】
前記データ統合機能は変換操作である、請求項１８に記載のシステム。
【請求項３１】
前記変換操作は、意味識別子の前記フォーマット、意味識別子の前記言語、意味識別子の前記データ・モデルの１以上を修正する、請求項３０に記載のシステム。
【請求項３２】
前記変換操作の前記マッピングは、該操作の実行において、元の意味コンテキストと変換された意味コンテキストとの間で前後に変換されるデータをトレースすることができる、請求項３０に記載のシステム。
【請求項３３】
前記変換操作は、サービス指向アーキテクチャ内のサービスとして提供される、請求項１８に記載のシステム。
【請求項３４】
前記エンティティの区別特性に基づいて論理エンティティのインスタンスを選択的にフィルタリングするためのフィルタをさらに備える、請求項１８に記載のシステム。
【請求項３５】
前記区別特性は、前記マッピングおよび前記意味識別子の少なくとも１つから得られる、請求項３４に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報技術の分野に関し、より特定的には、データ統合システムの分野に関する。
【背景技術】
【０００２】
コンピュータ・アプリケーションの出現によって、多くのビジネス・プロセスがより速く、より効率的なものとなった。しかし、異なるデータ構造、通信プロトコル、言語およびプラットフォームを使用する異なるコンピュータ・アプリケーションが急増したことによって、一般的な企業のＩＴインフラストラクチャが極めて複雑になってきている。典型的な企業内における異なるビジネス・プロセスにおいて、企業全体ではなく特定のビジネス・プロセスのために各々が開発され最適化されたコンピュータ・アプリケーションが使用されている場合がある。例えば、ある企業が、支払勘定を追跡するための特定のコンピュータ・アプリケーションと、顧客とのコンタクトの履歴を追跡するためのコンピュータ・アプリケーションを有している場合がある。実際、集中顧客コンタクト・データベースを保持するが、従業員は個人情報マネージャなどに彼ら自身のコンタクト情報を保持する場合などでは、企業は同一のビジネス・プロセスであっても２つ以上のコンピュータ・アプリケーションを使用する場合がある。
【０００３】
特定用途のコンピュータ・アプリケーションによれば顧客に適合したソリューションを提供することができるという利点を得ることができるが、特定用途のコンピュータ・アプリケーションが多くなると、同じデータを企業全体で何度も繰り返し入力して処理する必要が生じたり、企業が１つのプロセスと関連するデータから利益を受ける他のプロセスを実行するときにそのデータを利用できないというような非効率につながってしまう場合がある。例えば、支払勘定プロセスがサプライ・チェーンおよび注文プロセスから分離された場合には、企業は、その企業が注文を拒絶するであろう信用履歴をもつ顧客からの注文を受け付け、応じてしまう可能性がある。他にも、様々なコンピュータ・アプリケーション全体にわたるデータのすべてに対して矛盾のないアクセスから企業が利益を得ることになる数多くの例がある。
【０００４】
多くの会社が、企業における異なるアプリケーション間でデータを共有する必要性を認識し、これに取り組んできた。このようにして、エンタープライズ・アプリケーション統合すなわちＥＡＩが、異なるソースからのデータを処理するためのメッセージ・ベースの戦略として登場した。コンピュータ・アプリケーションの複雑さと数が増加するにつれて、ＥＡＩへの取り組みは、異なるプロトコルを処理する必要性、増え続けるデータおよびトランザクションを処理する必要性、ならびに、増え続けるデータのより高速な統合に対する要求を含む多くの課題に直面する。最小公分母アプローチ、アトミック・アプローチおよびブリッジ型アプローチを含む、ＥＡＩに対する様々なアプローチが実施されている。しかし、ＥＡＩは、個々のアプリケーション間の通信に基づくものである。重大な課題は、プラットフォームおよびアプリケーションの直線的な追加に応じて、ＥＡＩソリューションの複雑さが幾何学的に増大することである。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
データ統合システムが企業の必要性に対処するための有用なツールをもたらす一方で、こうしたシステムが、典型的には、顧客ソリューションとして導入されている。このようなシステムは、長期にわたる開発サイクルを伴い、ビジネス構造および情報要求の変化に対応するために高度な技術的なトレーニングを必要とすることがある。変化するビジネス環境において、機能の使用、再使用および変更を可能にするデータ統合システム・ツールに対する必要性が残っている。こうしたツールの１つは、あるアイテムを、追加的なデータを必要とすることなく他のアイテムとの関係に基づいて一意的に識別することを可能にする意味識別子（ｓｅｍａｎｔｉｃ  ｉｄｅｎｔｉｆｉｅｒ）である。変換エンジンは、データ、メタデータ、意味識別子および他のアイテムを、あるフォーマット、言語、および／またはデータ・モデルから他のものに変換することができるツールである。最終的には、ハブまたはデータベースの抽象化プロパティ・レベルにより、アイテムの多数のインスタンスまたは形式の区別が可能になる。
【課題を解決するための手段】
【０００６】
アイテムについて意味識別子を存在させることができる。アイテムは、オブジェクト、データ・アイテム、データ、列、行、テーブル、データベース、インスタンス、属性、メタデータ、概念、トピック、主題、意味識別子、他の識別子、ＲＦＩＤタグ、ベンダー、供給業者、顧客、人、チーム、組織、ユーザ、ネットワーク、システム、装置、家族、店、製品、製造ライン、製品特性、製品仕様、製品属性、価格、コスト、材料仕様書、出荷データ、税金データ、コース、教育プログラム、位置、地図、部門、組織、有機的組織体、プロセス、規則、法、評価システム、商品、サービスおよびサービス提供、あるいは他のアイテムまたは概念とすることができる。アイテムは、データ統合ジョブおよび／またはデータ統合プラットフォームに関連付けることができる。意味識別子は、アイテムと１以上の他のアイテムとの関係に基づいて、アイテムを識別することができる。関係は、関係の不存在とすることもできる。関係は、意味に基づくものとすることができる。関係は、関係階層におけるアイテムの位置を含むことができる。
【０００７】
意味識別子は、アイテムについての固有の識別子とすることができる。アイテムについての固有の意味識別子が、アイテムと他のアイテムとのすべての関係より少ない数の関係を考えることが可能である。一意性を確実にするために、最小数の関係に基づいた意味識別子を作成することが有利である。アイテムについての固有の意味識別子を作成するのに必要とされる関係の数は、コンテキストによって異なり得る。意味識別子は、コンテキスト依存のものとすることができる。意味識別子は、動的なものとすることができる。
【０００８】
意味識別子は、文字列構造またはフォーマットで格納し、維持し、記録し、処理し、および／または解釈することができる構文の形で格納し、維持し、記録し、処理し、および／または解釈することができる。構文および／または文字列構造またはフォーマットは、構文解析可能である。構文および／または文字列構造またはフォーマットは、切り捨て、修正し、短縮し、構文解析し、または再配列することができる。構文および／または文字列を切り捨て、修正し、短縮し、または再配列し、依然として意味識別子を保持することが可能である。特定のコンテキストにおいて、より短い構文および／または文字列は有用であり、性能を増大させることができる。
【０００９】
意味識別子は、企業の方法におけるステップ、データベース内のデータ、行または列内のデータ、テーブル内の行または列、データベース内の行または列、テーブル内のデータ、データ内のテーブル、データベース内のメタデータ、ハブまたはリポジトリ内のアイテム、データベース内のアイテム、テーブル内のアイテム、列内のアイテム、行内のアイテム、組織内の人、通信の送信者または受信者、ネットワーク上のユーザ、ネットワーク上のシステム、ネットワーク上の装置、家族内の人、店の中の品目、メニュー上の料理、製造ライン内の製品、製品提供における製品、教育プログラムまたは訓練プログラムにおけるコースまたはステップ、地図上の位置、アイテムの位置、組織の部門、チームの人、規則システムにおける規則、サービス・スイートにおけるサービス、企業の組織階層内のエンティティ、供給チェーン内のエンティティ、マーケットにおける顧客、購買決定における購入者、商品またはサービスの価格、商品またはサービスのコスト、製造またはシステムの構成部品、方法のステップ、および／またはグループのメンバーのような意味コンテキストと関連付けることができる。
【００１０】
実施形態において、データベースは、列を持ったテーブルを有することができる。その列についての固有の意味識別子は、「データベース名のテーブル名の列名」とすることができる。この固有の意味識別子は、次の構文、すなわち「列名：：テーブル名：：データベース名」を用いて、格納され、維持され、記録され、処理され、および／または解釈される。構文および／または任意の関連した文字列を構文解析することができ、不必要な要素を除去することができる。例えば、１つのデータベースだけが存在する場合には、以下の構文は、列：：列名：：テーブル名についての固有の識別子を依然として生成することができる。固有の意味識別子を作成するのに、データベース関係は必要とされない。他の例において、データベースは、１つのテーブルしか有することができないので、以下の構文は、列：：列名：：データベース名についての固有の識別子とすることができる。固有の識別子を作成するのに、テーブル関係は必要とされない。より短い構文および／または文字列を使用することにより、処理の回数が減少し、効率が増大される。
【００１１】
変換エンジンは、１以上の意味識別子、データベース、意味識別子を含むデータベース、情報システム、意味識別子、または他のアイテムを含む情報システムに対して変換操作を行うことができる。変換操作は、意味識別子のフォーマット、言語、および／またはデータ・モデルを変換するか、または他の方法で修正することができる。変換操作は、１以上のデータ・ツール、言語、フォーマット、および／またはデータ・モデルとの間、少なくとも１つの他のデータ・ツール、言語、フォーマット、および／またはデータ・ツールとの間の変換またはマッピングを含むことができる。例えば、変換操作は、ＤａｔａＳｔａｇｅ７、ＱｕａｌｉｔｙＳｔａｇｅ、Ｂｕｓｉｎｅｓｓ  Ｏｂｊｅｃｔ、ＩＢＭ−ＤＢ２  Ｃｕｂｅ  Ｖｉｅｗｓ、ＵＭＬ１．１、ＵＭＬ１．３、ＥＲＳｔｕｄｉｏ、ＰｒｏｆｉｌｅＳｔａｇｅ、ＰｏｗｅｒＤｅｓｉｇｎｅｒ（ＰａｃｋａｇｅｓおよびＥｘｔｅｎｄｅｄ  Ａｔｔｒｉｂｕｔｅｓのためのサポートが付加された）、および／またはＭｉｃｒｏＳｔｒａｔｅｇｙとの間の変換、またはこれらへのマッピングを含むことができる。変換エンジンおよび／または変換操作は、随意的に、メタブローカにおいて実現することができる。変換エンジン、変換操作のマッピング、または変換操作は、操作の実行において、元の意味コンテキストと変換された意味コンテキストとの間で前後に変換されるデータをトレースすることができる。変換操作は、バッチで、リアルタイムに、または連続的に行い、実行し、および／または実施することができる。変換操作は、例えば、サービス指向アーキテクチャの一部としてなど、サービスとして提供すること、または利用可能にすることができる。
【００１２】
意味識別子、データベース、１以上の意味識別子を含むデータベース、情報システム、１以上の意味識別子を含む情報システム、または他のアイテムについての変換操作が存在すると、この変換操作を、いずれかの他の意味識別子、データベース、１以上の意味識別子を含むデータベース、情報システム、１以上の意味識別子、あるいは少なくとも１つの変換操作を共有する他のアイテムとの間で変換し、これにマッピングし、これに結合し、これとともに使用し、またはこれと関連付けることが可能になる。
【００１３】
アイテムは、物理モデリング活動および／または論理モデリング活動のような、多数の形式またはインスタンスで存在することができる。データベースおよび／またはハブにおいて、いずれかの関連したデータまたはメタデータを含むアイテムは、多数の形式またはインスタンスで存在することができる。アイテムの種々の形式またはインスタンスを区別するために、抽象化レベル、階層内の位置、他のアイテムとの関係、アイテムの１以上の区別属性、アイテムが見出されるコンテキスト、アイテムが見出される物理的位置等のような、いずれかの区別特性を使用されることができる。
【００１４】
１つの実施形態において、「従業員」と名づけられたテーブルのようなアイテムをハブに入れることができる。ハブ・コレクタは、ハブ内に２つの形式またはインスタンスの「従業員」、すなわち１つは物理データベース・インスタンスに対応し、他のものは論理モデリング活動に対応するものを有することができる。ハブ・データ収集の抽象化プロパティ・レベルは、物理モデルと論理モデル・インスタンスまたは形式との間の区別を可能にする。
【００１５】
クエリに応答するものとすることができる変換操作を実行するとき、変換エンジンは、ハブまたはデータベースからアイテムのすべてをグラブし、ロードし、または獲得することができる。変換エンジンは、抽象化レベル、階層内の位置、他のアイテムとの関係、アイテムの属性、物理的位置等のような区別特性に基づいて、アイテムをフィルタリングし、選択し、格納し、変換し、修正し、または他の方法で操作することができる。代替的には、クエリに応答するものとすることができる変換操作を実行するとき、変換エンジンは、ハブまたはデータベースにおいて、任意のデータおよび／またはメタデータを含むアイテムをフィルタリングし、選択し、格納し、変換し、修正し、または他の方法で操作することができ、関連した抽象化レベルのアイテムまたは関連した属性、位置、関係、位置等を有するアイテムだけをグラブし、または獲得することができる。フィルタリング、選択、格納、変換、修正、または他の操作は、実行時および設計時に行うことができ、バッチで、リアルタイムで、または連続的に行うことができる。実施形態において、フィルタリング、選択、格納、変換、修正、または他の操作は、データ・モデル、データ・モデルのマッピング、識別子の構文の区別特性等といった、開発時、設計時、または実行時に変換エンジンおよび／またはシステムによって得られる情報または入力に基づくものとすることができる。情報は、リアルタイムで動的に更新することができる。したがって、１つの好ましい実施形態において、システムは、論理アイテムを選択し、物理アイテムを省くため、または物理アイテムを選択し、論理アイテムを省くためなどに、データベースの周知のマッピングに基づいて、データベースからデータを選択するための選択コマンドを精緻化することができる。
【００１６】
場合によっては、プロセス全体において、フィルタリング、選択、または他の操作がハブまたはデータベースに近いほど、操作がより効率的かつ高速になる。変換エンジンは、クエリ自体に変換操作を行い、ハブまたはデータベースに直接送ることができる、改訂されたクエリまたは選択コマンドをもたらすことができる。改訂されたクエリまたは選択コマンドは、ハブまたはデータベースと直接互換性があるフォーマットにすることができる。
【００１７】
他の態様において、コンピュータ・プログラム製品は、コンピュータ・プログラム・コードを含むコンピュータ使用可能媒体を含むことができ、コンピュータ可読プログラム・コードは、１以上のコンピュータ上で実行されるとき、１以上のコンピュータに、上記の方法のいずれか１以上を実行させる。
【００１８】
本明細書において用いられる「Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｂｕｓｉｎｅｓｓ  Ｍａｃｈｉｎｅｓ」または「ＩＢＭ」は、ニューヨーク州アーモンク所在のインターナショナル・ビジネス・マシーンズ・コーポレーションを指している。
【００１９】
本明細書において用いられる「データ・ソース」または「データ・ターゲット」は、特定の意味が他に示されるかまたは語句の文脈を別に要求することがない限り、これらの用語と矛盾しない最も広範な意味を持つように意図されており、データベース、複数のデータベース、リポジトリ情報マネージャ、キュー、メッセージ・サービス、リポジトリ、データ機構、データ・ストレージ機構、データ・プロバイダ、ウェブサイト、サーバ、コンピュータ、コンピュータ・ストレージ機構、ＣＤ、ＤＶＤ、モバイル・ストレージ機構、中央ストレージ機構、ハードディスク、複数の調整データ・ストレージ機構、ＲＡＭ、ＲＯＭ、フラッシュメモリ、メモリカード、一時メモリ機構、永続メモリ機構、磁気テープ、ローカル接続コンピューティング機構、遠隔接続コンピューティング機構、無線機構、有線機構、モバイル機構、中央機構、ウェブ・ブラウザ、クライアント、ラップトップ、携帯情報端末（「ＰＤＡ」）、電話、携帯電話、移動電話、情報プラットフォーム、分析機構、処理機構、ビジネス・エンタープライズ・システムまたはデータを処理する他の機構もしくはデータまたは他の情報ならびに上記のシステムのいずれかに用いられる構造化データまたは非構造化データあるいはいずれかのストリーミング・データ、メッセージ化データ、イベント駆動データもしくはソース・データを保持するための何らかのファイルまたはファイル・タイプを格納するようになった他の機構、および、上記のいずれかの組み合わせを含むものとする。ストレージ機構とは、何らかの物理装置または論理装置、リソース、あるいは、データ・ソースもしくはデータ・ターゲットとして機能を果たすか、さもなければ検索可能な形式でデータを格納することができる機構である。
【００２０】
「Ｅｎｔｅｒｐｒｉｓｅ  Ｊａｖａ（登録商標）  Ｂｅａｎ（ＥＪＢ）」は、Ｊ２ＥＥプラットフォームのためのサーバ側のコンポーネント・アーキテクチャを含む。ＥＪＢは、分散Ｊａｖａ（登録商標）アプリケーション、トランザクションＪａｖａ（登録商標）アプリケーション、セキュアおよびポータブルＪａｖａ（登録商標）アプリケーションの迅速で簡単な開発をサポートする。ＥＪＢは、メッセージの並行処理を可能にするコンテナ・アーキテクチャをサポートし、分散トランザクションをサポートするため、Ｊ２ＥＥアーキテクチャを使用するデータベース更新、メッセージ処理およびエンタープライズ・システムへの接続が、同一のトランザクション・コンテキストに関与することが可能になる。
【００２１】
「ＪＭＳ」は、Ｊａｖａ（登録商標）ベースのＪ２ＥＥエンタープライズ・アーキテクチャのためのエンタープライズ・メッセージ・サービスであるＪａｖａ（登録商標）  Ｍｅｓｓａｇｅ  Ｓｅｒｖｉｃｅを意味する。「ＪＣＡ」は、以下により詳細に説明されるＪ２ＥＥプラットフォームのＪ２ＥＥ  Ｃｏｎｎｅｃｔｏｒ  Ａｒｃｈｉｔｅｃｔｕｒｅを意味する。ＥＪＢ、ＪＭＳおよびＪＣＡは、現代の分散トランザクション環境において一般的に用いられるソフトウェア・ツールであるが、同様の機能を提供するいずれかのプラットフォーム、システムまたはアーキテクチャを本明細書において説明されるデータ統合システムとともに利用できることに留意されたい。
【００２２】
本明細書において用いられる「リアルタイム」は、ビジネス・トランザクションまたはビジネスの継続時間に近い時間の間隔を含み、夜間に行われるバッチ処理操作のようなオフラインで行われるものとは対照的に、営業活動またはビジネス・プロセス中に行われるプロセスまたはサービスと含むものとする。ビジネス・プロセスの継続時間によって、リアルタイムは、秒、一瞬、分、時間、あるいはさらに日を含む場合がある。
【００２３】
本明細書において用いられる「ビジネス・プロセス」、「ビジネス・ロジック」および「ビジネス・トランザクション」は、販売、マーケティング、フルフィルメント、在庫管理、価格付け、製品設計、専門的サービス、金融サービス、管理、財務、引受業務、分析、契約、情報技術サービス、データ・ストレージ、データ・マイニング、情報配信、商品の経路指定、スケジューリング、通信、投資、トランザクション、提供、販売促進、広告、付け値、エンジニアリング、製造、サプライ・チェーン管理、人事管理、データ処理、データ統合、ワークフロー管理、ソフトウェア生成、ハードウェア生産、新製品の開発、研究、開発、戦略機能、品質管理および保証、パッケージ化、物流、顧客関係管理、リベートおよび返品処理、顧客サポート、製品保守、電話勧誘、企業広報、投資家向け広報活動を含むが、これらに限定されるものではなく、企業が行うことができるあらゆる方法、サービス、運用、プロセス、または取引を含むものとする。
【００２４】
本明細書において用いられる「サービス指向アーキテクチャ（ＳＯＡ）」は、企業のインフラストラクチャの一部を形成するサービスを含む。ＳＯＡにおいては、サービスは、迅速なアプリケーション開発を可能とし、冗長なコードを避ける、アプリケーションの開発および導入のための構成単位となることがある。各々のサービスは、サービスについてのデータ入力のソース、またはサービスのデータ出力のターゲットといった、周囲環境に結合できるビジネス・ロジックまたはビジネス規則の組を具体化することができる。ＳＯＡの種々の例が、以下の説明において提供される。
【００２５】
本明細書において用いられる「メタデータ」は、処理されるデータにコンテキストを導入するデータ、データに関するデータ、関連情報のコンテキストに関する情報、データの出所に関する情報、データの場所に関する情報、データの意味に関する情報、データの経過時間に関する情報、データの見出しに関する情報、データの単位に関する情報、データのフィールドに関する情報、および／または、データのコンテキストに関連する他のいずれかの情報に関する情報を含むものとする。
【００２６】
本明細書において用いられる「ＷＳＤＬ」すなわち「ウェブ・サービス記述言語」は、文書指向情報または手続き指向情報のいずれかを含むメッセージ上で動作するエンドポイントの組としてネットワーク・サービス（多くの場合、ウェブ・サービス）を記述するためのＸＭＬフォーマットを含む。動作およびメッセージは、抽象的に記述され、次いでエンドポイントを定めるために具体的なネットワーク・プロトコルおよびメッセージ・フォーマットに結合される。関連する具体的なエンドポイントは、抽象的なエンドポイント（サービス）に組み合わされる。ＷＳＤＬは、どのメッセージ・フォーマットまたはネットワーク・プロトコルが通信に用いられるかにかかわらず、エンドポイントおよびそれらのメッセージの記述を可能にするように拡張可能である。
【００２７】
本明細書において用いられる「メタブローカ」は、データまたはメタデータの変換操作その他の操作を行うための変換エンジンその他の手段を含むことができるシステムまたは方法を含むことができる。変換操作その他の操作は、１以上のフォーマット、言語、および／またはデータ・モデルから１以上のフォーマット、言語、および／またはデータ・モデルへのデータまたはメタデータの変換を含むことができる。
【発明を実施するための最良の形態】
【００２８】
以下の説明全体を通して、他に特に示されない限り、同様の要素に対する数字は同様の要素を指すことが意図されている。
【００２９】
本明細書に開示される本発明は、全体がハードウェアの実施形態、全体がソフトウェアの実施形態、または、ハードウェア要素とソフトウェア要素の両方を含む実施形態の形式を取ることができる。好ましい実施形態においては、本発明は、これらに限定されるものではないが、ファームウェア、常駐型のソフトウェア、マイクロコード等を含むソフトウェアにおいて実装される。
【００３０】
さらに、本発明は、コンピュータまたはいずれかの命令実行システムによって、またはこれらと接続して、使用されるためのプログラム・コードを提供するコンピュータ使用可能またはコンピュータ可読媒体からアクセス可能なコンピュータ・プログラム製品の形態を取ることができる。この説明のために、コンピュータ使用可能またはコンピュータ可読媒体は、命令実行システム、装置によって、またはこれらと接続して、使用されるためのプログラムを含み、格納し、通信し、伝搬し、または転送することが可能ないずれかの装置とすることができる。
【００３１】
媒体は、電子システム、磁気システム、光システム、電磁システム、赤外線システム、もしくは半導体システム（または機器もしくは装置）または伝搬媒体とすることができる。コンピュータ可読媒体の例は、半導体メモリまたはソリッドステート・メモリ、磁気テープ、取り外し可能コンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、磁気ハードディスクおよび光ディスクを含む。現時点における光ディスクの例は、ＣＤ−ＲＯＭ、ＣＤ−Ｒ／ＷおよびＤＶＤを含む。
【００３２】
プログラム・コードを格納および／または実行するのに適したデータ処理システムは、システム・バスを通してメモリ要素に直接的にまたは間接的に結合された少なくとも１つのプロセッサを含む。メモリ要素は、プログラム・コードの実際の実行時に使用されるローカル・メモリと、大容量記憶装置と、実行時に大容量記憶装置からコードを取得しなければならない回数を減少させるように少なくともいくつかのプログラム・コードの一時的な記憶場所を提供するキャッシュ・メモリとを含むことができる。
【００３３】
入力／出力装置すなわちＩ／Ｏ装置（キーボード、ディスプレイ、ポインティング装置等を含むが、これらに限定されるものではない）を、直接的に、または介在するＩ／Ｏコントローラを通して、システムに結合することができる。
【００３４】
プライベート・ネットワークまたは公衆ネットワークを通じて、データ処理システムを他のデータ処理システムまたは遠隔プリンタもしくは記憶装置に結合できるように、ネットワーク・アダプタをシステムに結合することもできる。モデム、ケーブル・モデムおよびイーサネット（登録商標）・カードは、現時点で利用可能なタイプのネットワーク・アダプタのうちの一部である。
【００３５】
図１は、企業の様々なデータの統合を容易にするためのプラットフォーム１００を表す。プラットフォームは、各々が複数の異なるコンピュータ・アプリケーションおよびデータ・ソースを含むことができる複数のビジネス・プロセスを含む。プラットフォームは、上述のようなデータ・ソースとすることができるいくつかのデータ・ソース１０２を含むことができる。これらのデータ・ソースは、様々な物理的場所からの様々なデータ・タイプを含むことができる。例えば、データ・ソースは、Ｓｙｂａｓｅ、Ｍｉｃｒｏｓｏｆｔ、Ｉｎｆｏｒｍｉｘ、Ｏｒａｃｌｅ、Ｉｎｌｏｍｏｖｅｒ、ＥＭＣ、Ｔｒｉｌｌｉｕｍ、Ｆｉｒｓｔ  Ｌｏｇｉｃ、Ｓｉｅｂｅｌ、ＰｅｏｐｌｅＳｏｆｔ、ＩＢＭ、Ａｐａｃｈｅ、またはＮｅｔｓｃａｐｅなどのプロバイダから提供されるシステムを含むことができる。データ・ソース１０２は、ＩＭＳ、ＤＢ２、ＡＤＡＢＡＳ、ＶＳＡＭ、ＭＤ  Ｓｅｒｉｅｓ、ＵＤＢ、ＸＭＬ、複合フラット・ファイル、またはＦＴＰファイルなどのデータベース製品または標準技術を使用するシステムを含むことができる。データ・ソース１０２は、Ｍｉｃｒｏｓｏｆｔ  Ｏｕｔｌｏｏｋ、Ｍｉｃｒｏｓｏｆｔ  Ｗｏｒｄ、Ｍｉｃｒｏｓｏｆｔ  Ｅｘｃｅｌ、Ｍｉｃｒｏｓｏｆｔ  Ａｃｃｅｓｓのようなアプリケーションによって作成または使用されるファイル、ならびに、ＡＳＣＩＩ、ＣＳＶ、ＧＩＦ、ＴＩＦ、ＰＮＧ等のような標準フォーマットのファイルを含むことができる。データ・ソース１０２は、様々な場所に配置することができ、または集中的に配置することもできる。データ・ソース１０２から供給されるデータは、様々な形式のものとすることができ、互換性があるか、または互換性のない異なるフォーマットを有することができる。
【００３６】
データ・ターゲットは、本明細書の後半で説明されるが、一般的に、これらのデータ・ターゲットは、上述のデータ・ソース１０２のいずれかとすることができる。このような用語の使用方法の違いは、一般的には、データ統合プロセスにおいてデータ・システムがデータを提供するのか、またはデータを受け取るのかに起因するものである。しかし、通常のデータ統合システムにおいては、データ・ソースはデータを受け取ることもできるし、データ・ターゲットはデータを提供することもできるため、特に他に記述がない限り、この区別はデータ・ソースとデータ・ターゲットとの間の能力に関する違いを与えることを意図するものではないことに留意されたい。
【００３７】
また、図１に示されたプラットフォームはデータ統合システム１０４も含む。データ統合システムは、例えば、データ統合システム１０４が受信するクエリまたは検索コマンドの結果としてのデータ・ソース１０２からのデータ収集を容易にすることができる。データ統合システム１０４は、データ・ソースがデータをデータ統合システム１０４に供給するように、１以上のデータ・ソース１０２に対してコマンドを送信することができる。受信されたデータは、様々なメタデータを含む多数のフォーマットのものであり得るため、データ統合システムは、統合処理のために後に結合することができるように、受信したデータを再構成することができる。データ統合システム１０４によって実現することができる機能は、以下により詳細に説明される。
【００３８】
また、プラットフォーム１００は、検索システム１０８を含む。検索システム１０８は、データ統合システム１０４から送信されるデータをさらに操作するのに用いられるデータベースまたは処理プラットフォームを含むことができる。例えば、データ統合システム１０４は、検索システム１０８が、処理されたデータを用いてビジネスに有用なレポート１１０を生成することができるように、データ・ソース１０２から受信するデータを整理し、結合し、変換し、または、他の方法で操作することができる。レポート１１０は、データの関連性を報告し、複雑なクエリに回答し、単純なクエリに回答し、または、ビジネスもしくはユーザに有用な他の報告を作成するために使用することができる。レポート１１０は、生データ、テーブル、チャート、グラフ、および検索システム１０８からのデータの他のいずれかの表現を含むことができる。
【００３９】
また、プラットフォーム１００は、データベースまたはデータベース管理システム１１２を含むこともできる。データベース１１２は、一時的または永続的もしくは長期的な記憶として、情報を格納するために使用することができる。例えば、データ統合システム１０４は、１以上のデータ・ソース１０２からデータを収集し、そのデータを、互いに互換性がある形式または互いに結合することができる形式に変換することができる。データが変換されると、データ統合システム１０４は、後で実施される検索のために、分解形式、結合形式その他の形式で、データをデータベース１１２に格納することができる。
【００４０】
図２は、企業の複数のエンティティおよびビジネス・プロセス間のデータ統合を示す概略図である。図示される実施形態においては、データ統合システム１０４は、ユーザ・インターフェース・システム２０２とデータ・ソース１０２との間の情報の流れを容易なものにする。データ統合システム１０４は、１以上のデータ・ソース１０２に存在するデータを抽出し、場合によっては変換するためのクエリを、インターフェース・システム２０２から受信することができる。インターフェース・システム２０２は、ラップトップ・コンピュータもしくはデスクトップ・コンピュータ、携帯電話、個人用情報端末（「ＰＤＡ」）、ネットワーク化プラットフォーム、およびこれらに取り付けられる装置上で作動するウェブ・ブラウザといった、データ統合システム１０４と通信するためのいずれかの装置およびプログラム、または、データ統合システム１０４とインターフェース接続される他のいずれかの装置またはシステムを含むことができる。
【００４１】
例えば、ユーザは、ＰＤＡを操作して、ＷｉＦｉまたはワイヤレス・アクセス・プロトコル／ワイヤレス・マークアップ言語（「ＷＡＰ／ＷＭＬ」）インターフェースを介してデータ統合システム１０４に情報を要求することができる。データ統合システム１０４は、その要求を受信して、ウェブサイトまたはＦＴＰファイル・サイト等の他のデータ・ソース１０２から情報にアクセスするために、必要ないずれかのクエリを生成することができる。データ・ソース１０２からのデータは、抽出され、要求するインターフェース・システム２０２（この例ではＰＤＡ）と互換性のあるフォーマットに変換され、次いで、ユーザが見て操作するためのインターフェース・システム２０２に送信することができる。他の実施形態においては、データは、データ・ソースから予め抽出され、データ統合システム１０４によって用いられるデータ・ウェアハウスその他のデータ機器であり得る別個のデータベース１１２に格納しておくことができる。データは、変換された状態で、またはその元の状態で、データベース１１２に格納することができる。例えば、データは、多くのデータ・ソース１０２からのデータを他の変換プロセスで結合することができるように、変換された状態で格納することができる。例えば、ＰＤＡからのクエリをデータ統合システム１０４に送信することができ、データ統合システム１０４は、データベース１１２から情報を抽出することができる。抽出後に、データ統合システム１０４は、そのデータをＰＤＡに返信する前にＰＤＡと互換性のある結合フォーマットに変換することができる。
【００４２】
図３は、企業の複数のデータ・ソース１０２についてのデータ統合を提供するためのアーキテクチャを示す概略図である。データ統合システム１０４の実施形態は、データ・ソースからのデータの抽出およびソース・データについての列の値およびテーブル構造の分析を（場合によっては他の処理の間に）実行するデータ発見段階３０２を含むことができる。また、データ発見段階３０２はデータ・ターゲットについてのテーブル構造、関係およびキーに関する推奨を生成することができる。より高度なプロファイリングおよび監査機能は、日付範囲の検証、計算の精度、if-then評価の精度等を含むことができる。データ発見段階３０２は、ソース・データの冗長な依存関係その他の変則的な部分を排除することなどによって、データを正規化することができる。データ発見段階３０２は、さらなる分析のためにデータ・ソース１０２内部の例外を掘り下げることまたはメインフレーム・データの直接プロファイリングを可能にするなどの付加的な機能を提供することができる。データ発見段階３０２の市販されている形態は、例えば、ＩＢＭのＷｅｂｓｐｈｅｒｅ  ＰｒｏｆｉｌｅＳｔａｇｅ製品があるがこれに限定されない。
【００４３】
データ統合システム１０４はまた、後に変換されることになる品質（クオリティ）データを生成するために、データを準備し、標準化し、照合し、または他の方法で操作する、データ準備段階３０４を含むこともできる。データ準備段階３０４は、データ内の不整合を調整すること、または（１対１の照合、１対多数の照合および重複排除を含む）正確な照合を行うことというような一般的なデータ品質機能を実行することができる。また、データ準備段階３０４は特定のデータ拡張機能を提供することもできる。例えば、データ準備段階３０４は、国際通信の改善のために、住所が多国間の郵便基準（ｍｕｌｔｉｎａｔｉｏｎａｌ  ｐｏｓｔａｌ  ｒｅｆｅｒｅｎｃｅ）に適合することを確実なものにすることができる。データ準備段階３０４は、空間情報の管理のために、位置データを多国間ジオコーディング標準（ｍｕｌｔｉｎａｔｉｏｎａｌ  ｇｅｏｃｏｄｉｎｇ  ｓｔａｎｄａｒｄ）に適合させることができる。データ準備段階３０４は、住所情報が、米国政府に認証された合衆国アドレス修正（ＵＳ  ａｄｄｒｅｓｓ  ｃｏｒｒｅｃｔｉｏｎ）によってアメリカ郵便公社の郵便料金の割引を受けることができることを保証するために、住所を変更または追加することができる。同様の分析およびデータ訂正を、適切に住所が記載された郵便について割引料金を提供する、カナダおよびオーストラリアの郵便システムに導入することができる。データ準備段階３０４の市販されている形態は、例えば、ＩＢＭのＷｅｂｓｐｈｅｒｅ  ＱｕａｌｉｔｙＳｔａｇｅ製品があるがこれに限定されない。
【００４４】
また、データ統合システムは、変換されたデータを変換し、質を高めて配信するデータ変換段階３０８を含むこともできる。データ変換段階３０８は、データの再構成および再フォーマットのような移行サービスを実行し、システム・ユーザのビジネス規則およびアルゴリズムに基づいて計算を実行することもできる。データ変換段階３０８はまた、特定の分析コンテキストにおけるデータのより高度な調整処理のために、ターゲット・データをデータマートまたはキューブとして知られるサブセットに編成することもできる。データ変換段階３０８は、データ統合システム１０４によって使用される様々なデータ・ソースおよびデータ・ターゲットの様々なソフトウェア・アーキテクチャおよびハードウェア・アーキテクチャの橋渡しをする、（以下に一般的に説明されるような）ブリッジ、トランスレータ、または他のインターフェースを使用することができる。データ変換段階３０８は、プラットフォーム１００全体にわたるデータ統合ジョブを設計するために、グラフィカル・ユーザ・インターフェース、コマンドライン・インターフェース、またはこれらの組み合わせを含むことができる。データ変換段階３０８の市販されている形態は、例えば、ＩＢＭのＷｅｂｓｐｈｅｒｅ  ＤａｔａＳｔａｇｅ製品があるがこれに限定されない。
【００４５】
データ統合システム１０４の段階３０２、３０４、３０８は、該システム１０４の性能を最適化するために、並列実行システム３１０を連続的にまたは組み合わせて用いて実行することができる。
【００４６】
データ統合システム１０４は、データ・ソース１０２と関連するメタデータを管理するためのメタデータ管理システム３１２を含むこともできる。一般に、メタデータ管理システム３１２は、データ統合環境におけるツールの全体にわたって、メタデータの交換、統合、管理および分析を提供することができる。例えば、メタデータ管理システム３１２は、ＩＢＭのＷｅｂｓｐｈｅｒｅ  ＯＤＢＣ  ＭｅｔａＢｒｏｋｅｒ、ＣＡ  ＥＲｗｉｎ、ＩＢＭ  Ｗｅｂｓｐｈｅｒｅ  ＰｒｏｆｉｌｅＳｔａｇｅ、ＩＢＭ  Ｗｅｂｓｐｈｅｒｅ  ＤａｔａＳｔａｇｅ、ＩＢＭ  Ｗｅｂｓｐｈｅｒｅ  ＱｕａｌｉｔｙＳｔａｇｅ、ＩＢＭ  ＤＢ２  Ｃｕｂｅ  ＶｉｅｗｓおよびＣｏｇｎｏｓ  Ｉｍｐｒｏｍｐｔｕのような、異なるソースにおけるデータの、広くアクセス可能な共通のビューを提供することができる。メタデータ管理システム３１２はまた、データ系統および影響分析のための分析ツールを提供することもできる。さらに、メタデータ管理システム３１２を用いて、データ統合システム１０４内のデータについてのデータ定義、アルゴリズムおよびビジネス・コンテキストのビジネス・データ用語集を作成することができ、この用語集は、企業全体で用いられるように公開することができる。メタデータ管理システム３１２の市販されている形態は、例えば、ＩＢＭのＷｅｂｓｐｈｅｒｅ  ＭｅｔａＳｔａｇｅ製品があるがこれに限定されない。
【００４７】
図４を参照すると、企業に関連するアイテムは、そのアイテムの意味コンテキストを取得するためといった、様々なコンテキストまたは階層の観点から記述することができる。このように、図４は、アイテムについての意味識別子を示す。アイテムは、オブジェクト、クラス、属性、データ・アイテム、データ・モデル、モデル、定義、識別、構造、言語、マッピング、関係、インスタンスその他の意味識別子を含む、他のアイテムまたは概念とすることができる。意味識別子は、アイテムの属性、アイテムの物理的位置、階層等におけるアイテムと１以上の他のアイテムとの関係等に基づいて、アイテムを識別することができる。場合によっては、何らかの特定の関係の不存在として関係を定義することができる。関係は、意味に基づくものとすることができる。関係は、関係階層におけるアイテムの位置を含むことができる。例えば、図４において、関連する他のアイテムとの関係に基づいて、アイテム１  ５２０２を識別することができる。アイテム１  ５２０２は、アイテム２  ５２０４、アイテム３  ５２０８およびアイテム４  ５２１０に直接関連するものとして、アイテム５  ５２１２に間接的に関連するものとして、およびアイテム５  ５２１２およびアイテム４  ５２１０を介してアイテム６  ５２１４に間接的に関連するものとして、識別することができる。アイテム１はまた、アイテム２  ５２０４、アイテム３  ５２０８およびアイテム４  ５２１０に直接関連するものとして識別することもできる。実施形態において、アイテム１  ５２０２とアイテム５  ５２１２およびアイテム６  ５２１４の間の間接的な関係は、アイテム１  ５２０２とアイテム４  ５２１０との関係において取得することができる。この連結タイプまたは再帰タイプの識別は、静的な識別子に加えて、動的な識別子の実現を可能にする。例えば、アイテム４  ５２１０とアイテム６  ５２１４との間の関係が変化する場合、アイテム２  ５２０４、アイテム３  ５２０８およびアイテム４  ５２１０を組み入れるアイテム１  ５２０８についての意味識別子は、アイテム４  ５２１０の組み入れを通してこの変更を組み入れ、アイテム６  ５２１４が意味識別子内に直接含まれていた場合のように、アイテム６  ５２１４の変更を説明するために更新を行う必要はない。
【００４８】
図５は、意味識別子のより具体的な例を示す。ジムは、米国某州、某町、某通り１１１に居住し、電話番号５５５−５５５−５５５５および社会保障番号０１２−３４−５６７８を有するジムとして識別することができる。代替的に、ジムは、他者との関係の観点から識別することができる。図５に示されるように、ジムは、ベティの息子、ラリーとジェフの兄弟、ジェシカの父親およびフランクの甥として識別することができる。
【００４９】
意味識別子は、１つのアイテムについての固有の識別子とすることができる。図５の例においては、ベティの息子、ラリーとジェフの兄弟、ジェシカの父親およびフランクの甥であるジムが世界に一人しかいない場合には、この意味識別子は、ジムについての固有識別子となる。アイテムに対する固有の意味識別子が、そのアイテムと他のアイテムとの関係のすべてより少ない数である場合を考えることも可能である。ベティの息子、ラリーの兄弟、ジェシカの父親であるジムが世界に一人しかいない場合には、固有の意味識別子を作成するのに、これらの関係の存在だけで十分である。ジムとジェフおよびフランクとの関係を考慮する必要はない。一意性を保証する最小数の関係に基づいた意味識別子を作成することが有利である。例えば、意味識別子がデータベース１１２内に格納されるか、またはデータ統合システム１０４によって処理される場合には、複雑でない意味識別子は、必要とする空間が少なく、より高速な処理が可能になる。
【００５０】
アイテムについての固有の意味識別子を作成するのに必要とされる関係の数は、コンテキストに基づいて異なり得る。図６は、２つの関心あるアイテム、すなわちアイテム１  ５４０２およびアイテム７  ５４０４を示す。コンテキストＡ  ５４０８において、アイテム１  ５４０２は、アイテム１  ５４０２とアイテム５  ５４１０およびアイテム６  ５４１２との関係によって、アイテム７  ５４０４と区別することができる。つまり、コンテキストＡにおいて、アイテム１  ５４０２についての固有の意味識別子は、アイテム２、３および４に直接関連し、アイテム４を通してアイテム５  ５４１０に間接的に関連し、アイテム５  ５４１０およびアイテム４を通してアイテム６  ５４１２に間接的に関連するものとすることができる。コンテキストＡにおいて、アイテム７  ５４０４についての固有の意味識別子は、アイテム２および３だけに直接関連するものとすることができる。図７は、異なるコンテキスト、すなわちコンテキストＢ  ５４１４内のアイテム１  ５４０２を示す。コンテキストＢ  ５４１４においてアイテム１  ５４０２を一意的に識別するために、アイテム１  ５４０２の、アイテム４との直接的な関係、アイテム６との直接的な関係の不存在、またはアイテム５との間接的な関係のいずれか１以上を考えることができる。コンテキストＢ  ５４１４において、アイテム１  ５４０２は、アイテム２および３に直接関連するが、アイテム６に直接関連していないものとして一意的にかつ意味的に識別することができる。したがって、アイテム１についての固有識別子は、コンテキストＡ  ５４０８とコンテキストＢ  ５４１４で異なる。このように、ここで説明されるデータ統合方法およびシステムの実施形態においては、データ統合ジョブまたはデータ統合プラットフォームに関連したアイテムのようなアイテムについての意味識別子に、そのアイテムについてのコンテキスト依存識別子を与えることができる。実施形態において、こうしたコンテキスト依存識別子は、データ・リポジトリ等の中に、アトミック・フォーマットの形で格納することができる。
【００５１】
他の実施形態において、コンテキストＡ  ５４０８およびコンテキストＢ  ５４１４は、２つの異なるインポート、マッピング、実行バージョン、モデル、メタブローカ・モデル、インスタンス、ツール、ビュー、オブジェクト、クラス、アイテム、関係、属性、または上記のいずれかの任意の組み合わせとすることができる。照合または比較機構は、異なるインポート、実行バージョン、モデル、メタブローカ・モデル、インスタンス、ツール、および／またはアイテムにおけるアイテムの識別の構文（シンタックス）を比較し、その比較に基づいてどの動作を取るべきかまたは動作を取るべきではないかについての判定を決定することができる。例えば、照合エンジンは、インポート・インスタンスＡによって用いられるモデルを、メタブローカＢによって用いられるモデルと比較することができる。この比較に基づいて、メタブローカＢは、変換または修正なしに、インポート・インスタンスＡのデータおよびメタデータにアクセスすることができ、比較機構が、メタブローカＢの続行を命令することができることが決定される。他の例においては、ツールＡ  ５４０８をツールＢ  ５４１４と比較することができ、各々のツールが他のツールのオブジェクトにアクセスし、使用することができる、ツール間のオブジェクト併合の実行が決定される。実施形態においては、比較機構が、変換機構をトリガし、それぞれのツールの各々における特定のアイテムの識別の処理のための異なる構文に基づいた変換、あるいは、比較によって決定されるツール間の他の差異に基づいた変換のような変換を必要とするいずれかのオブジェクトを変換するのを助けるといった、ブリッジ、メタブローカ、ハブ等の確立のようなツール間のオブジェクト併合を助けることができる。
【００５２】
実施形態において、意味識別子は、文字列構造またはフォーマットで格納し、維持し、記録し、処理し、および／または解釈することができる構文の形で格納し、維持し、記録し、処理し、および／または解釈することができる。図８は、構文およびその構文内に構成された対応する文字列の例を示す。構文  ５５０２は、列名：：テーブル名：：データベース名とすることができる。この構文は、例えば、データベース内のテーブルの列を識別する意味識別子に関連付けることができる。この構文  ５５０４内に構成された文字列は、年齢：：従業員：：従業員データベースとすることができる。この文字列は、例えば、特定の従業員データベース内の従業員の年齢を識別する意味識別子に関連付けることができる。図７の例において、コンテキストＢにおけるアイテム１  ５４０２についての意味識別子に対応する文字列は、アイテム２との直接的な関係：：アイテム３との直接的な関係：：アイテム４との直接的な関係とすることができる。意味識別子および対応する文字列はまた、アイテム１  ５４０２とアイテム６との間の直接的な関係の欠如を組み込むこともできる。
【００５３】
図９において、アイテム９  ５６０２についての、文字列フォーマットでの意味識別子は、アイテム２に直接関連している：：アイテム４に直接関連している：：アイテム５  ５６０４に間接的に関連しているものとすることができる。文字列を構文解析することができる。構文および／または文字列を切り捨て、修正することができ、および／または、構文および／または文字列の要素を再配列することができる。図１０において、文字列５７０２は、文字列５６０４を切り捨てたものであり、文字列５７０４は、文字列５６０４を切り捨て、修正し、および／または再配列したものであり、文字列５７０８は、文字列５６０６を修正し、および／または再配列したものである。変換エンジンによって、切り捨て、修正、および／または再配列を行うことができる。意味識別子の一意性のために、構文および／または文字列内に含まれるすべての関係を必要としないとき、構文および／または文字列を切り捨てることは有用である。文字列  ５６０４の所定のコンテキストにおいて、すべてのアイテムがアイテム３に直接関連している、すなわち、例えば、アイテム３が、すべてのアイテムを格納するデータベースであったと想定する。アイテム３を含む関係を省略する文字列を作成するといったように、文字列  ５６０４を切り捨て、依然として固有の意味識別子を残すことができる。構文および／または文字列の切り捨てにより、格納要件を減らし、処理の効率を増大させることができる。例えば、データ統合プロセスのための処理時間を減少させるために、構文および／または文字列における関係の順序を変えることも有用である。あまり共通性がない関係が先に処理された場合、システムは、アイテムを識別するために、アイテムとの関連付けられたより少ない関係にアクセスし、処理することが必要になる可能性が高い。例えば、アイテム３に関連するアイテムが殆どなく、アイテム４に関連するものはさらに少なく、多くのアイテムがアイテム２に関連する場合には、コンテキストによって、文字列５７０８が、文字列５６０４より短い時間でアイテム９を識別することが可能になる。コンテキストにおいてアイテム９を一意的に識別するために、文字列５７０８の最初の２要素だけを必要とし、文字列５６０４の最初の３要素を必要とするということもあり得る。
【００５４】
変換エンジンは、１以上の意味識別子、データベース１１２、意味識別子を含むデータベース１１２、情報システム、１以上の意味識別子を含む情報システム、または他のアイテムに対して変換操作を行うことができる。図１１は、文字列５８０４として具体化される意味識別子、および、データベース５８０８内に配置された文字列として具体化される意味識別子に作用する変換エンジン５８０２を示す。変換操作は、意味識別子のフォーマット、言語、および／またはデータ・モデルを変換するか、または他の方法で修正することができる。変換操作は、１以上のデータ・ツール、言語、フォーマット、および／またはデータ・モデルとの間の変換またはマッピング、少なくとも１つの他のデータ・ツール、言語、フォーマット、および／またはデータ・ツールとの間の変換またはマッピングを含むことができる。例えば、変換操作は、ＩＢＭからのＷｅｂＳｐｈｅｒｅ  ＤａｔａＳｔａｇｅ７、ＩＢＭからのＷｅｂＳｐｈｅｒｅ  ＱｕａｌｉｔｙＳｔａｇｅ、Ｂｕｓｉｎｅｓｓ  Ｏｂｊｅｃｔツール、ＩＢＭ−ＤＢ２  Ｃｕｂｅ  Ｖｉｅｗｓ、ＵＭＬ１．１、ＵＭＬ１．３、ＥＲＳｔｕｄｉｏ、ＩＢＭのＷｅｂＳｐｈｅｒｅ  ＰｒｏｆｉｌｅＳｔａｇｅ、ＰｏｗｅｒＤｅｓｉｇｎｅｒ（ＰａｃｋａｇｅｓおよびＥｘｔｅｎｄｅｄ  Ａｔｔｒｉｂｕｔｅｓのためのサポートが付加された）、および／またはＭｉｃｒｏＳｔｒａｔｅｇｙツールのような、周知のデータ統合ツールへの、これらからの、またはこれらの間の変換またはマッピングを含むことができる。変換エンジンおよび／または変換操作は、随意的に、メタブローカにおいて具体化することができる。変換操作は、バッチ、リアルタイムまたは連続的に行い、実行し、および／または実施することができる。変換操作は、例えば、サービス指向アーキテクチャの一部としてなど、サービスとして提供すること、または利用可能にすることができる。ＳＯＡは、ビジネス・エンタープライズのエンタープライズ・コンピュータ・システムのインフラストラクチャの一部とすることができる。ＳＯＡにおいて、サービスは、アプリケーション開発および導入のための基礎的要素になり、迅速なアプリケーション開発を可能とし、冗長なコードを避ける。各々のサービスは、サービスについてのデータ入力ソースまたはサービスについてのデータ出力ターゲットといった周囲環境に左右されない１組のビジネス・ロジックまたはビジネス規則を具体化する。その結果、適切な入力および出力がサービスとアプリケーションとの間に確立された場合、サービスを様々なアプリケーションとともに再使用することができる。サービス指向アーキテクチャは、環境の変化に対してサービスが保護されることを可能にするので、アーキテクチャは、周囲のコンピュータ環境が変わったとしても機能する。その結果、インフラストラクチャの変更の結果としてサービスを記録する必要はなくなり、そのことは、時間と労力の節約をもたらす。ＳＯＡは、ウェブ・サービスのためのものとすることができ、３つのエンティティ、すなわちサービス・プロバイダ、サービス・リクエスタおよびサービス・レジストリを含むことができる。レジストリは、公衆のものであっても、または私的なも���であってもよい。サービス・リクエスタは、適切なサービスを探してレジストリをサーチすることができる。適切なサービスが発見されると、サービス・リクエスタは、サービスを呼び出すのに必要な、ウェブ・サービス記述言語（Ｗｅｂ  Ｓｅｒｖｉｃｅｓ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ、「ＷＳＤＬ」）コードのようなコードを受け取ることができる。ＷＳＤＬは、ウェブ・サービスを記述するために従来より用いられているプログラミング言語である。次に、サービス・リクエスタは、サービスを呼び出すために、適切なフォーマット（ウェブ・サービス・メッセージのためのシンプル・オブジェクト・アクセス・プロトコル（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ、「ＳＯＡＰ」）フォーマットのような）のメッセージなどを通して、サービス・プロバイダと接続することができる。ＳＯＡＰプロトコルは、ウェブ・サービスにおいてデータを転送するための好ましいプロトコルである。ＳＯＡＰプロトコルは、ウェブ・サービス・クライアントとウェブ・サービス・サーバとの間のメッセージ交換フォーマットを定める。ＳＯＡＰプロトコルは、ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ（「ＸＭＬ」）スキーマを使用し、ＸＭＬは、データのタグ付けのためにウェブ・サービスにおいて通常用いられる一般的な言語仕様であるが、他のマークアップ言語を使用することもできる。
【００５５】
意味識別子、データベース１１２、１以上の意味識別子を含むデータベース１１２、情報システム、１以上の意味識別子を含む情報システム、または他のアイテムについての変換操作が存在すると、この変換操作を、いずれかの他の意味識別子、データベース１１２、１以上の意味識別子を含むデータベース１１２、情報システム、１以上の意味識別子を含む情報システム、あるいは少なくとも１つの変換操作を共有する他のアイテムとの間で変換し、これにマッピングし、これに結合し、これとともに使用し、またはこれと関連付けることが可能になる。変換操作のために、ハブのようなアトミック・データ・リポジトリを使用されるような実施形態においては、変換操作のマッピングは、とりわけ、操作の実行において、元の意味コンテキストと変換された意味コンテキストとの間で前後に変換されるデータをトレースすることができる。コンテキストによって、構文および／または文字列を変えるかまたは切り捨ててより効率的な格納またはより高速な処理を可能することによって、あるいは、意味コンテキストが変化する固有識別子を形成するのに用いられる関係を変えることなどによって、データ・アイテムの適切な識別子が変化することがある。したがって、動的な識別子は、再トレース可能な変換の利点を、データ・アイテムが用いられる種々のコンテキストにおける高速処理、効率的なデータ処理および効率的な操作の利点と結び付けることができる。
【００５６】
モデル内に識別を有するアイテムのような所定のアイテムは、物理インスタンスおよび論理モデリング・インスタンスのような多数の形式またはインスタンスで存在することができる。図１２は、アイテム、すなわち従業員情報５９０２のテーブルを示す。しかし、概念またはエンティティ「従業員」は、企業内で多数の異なる形式で存在する場合がある。例えば、従業員テーブル５９０２は、従業員に関連した値を物理データ・ストレージ機構に格納する物理テーブルとして存在することができる。他方、エンティティ従業員は、論理モデリング活動５９０８または種々の他の形式またはインスタンスにおける従業員を表すアイコンまたはテキストのような、論理エンティティとして表すこともできる。つまり、いずれかの関連したデータまたはメタデータを含む同じアイテムが、例えば、データベース、データ・リポジトリ、モデル、ハブ等におけるビュー、モデル、構造、またはデータ統合環境にわたる様々な形式またはインスタンスで存在することができる。図１３は、データベース６００２内の１つの形式または単一のインスタンス、および／または、データベース６００４またはハブ６００８内の２つ以上の形式またはインスタンスでの従業員テーブル５９０２を示す。
【００５７】
アイテムの種々の形式またはインスタンスを区別するために、抽象化レベル、アイテムの物理プロパティ、階層内のアイテムの位置、データベース内のアイテムの位置、アイテムが見出されるコンテキスト、アイテムの構文、アイテムと他のアイテムの関係、アイテムの属性、アイテムのクラス、または他の特性といった、何らかの区別特性を使用されることができる。例えば、再び図５を参照すると、年齢、性別、髪の色、ＩＱ、政治的所属、および／または過去３ヶ月に医者にかかった回数に基づいて、アイテムすなわちこの場合は個人を区別することができる。例えば、年齢が製品を区別化する要因として選択された場合には、ジェシカは唯一の１０歳以下の個人であり、ベティは５７歳から６７歳までの唯一の個人であり、ジムは３７歳である唯一の個人である。他の例において、アイテムの異なる形式またはインスタンスは、異なる抽象化レベルで、または異なるコンテキストで存在することができる。例えば、従業員テーブルは、従業員に関するデータに関連したデータベース内の値を格納するためなどに用いられる物理的な従業員テーブル５９０４、および従業員に関連するプロセスに鑑みて用いられるような論理的な従業員モデル５９０８といった、ハブ６１０２内の多数の形式またはインスタンスで存在することができる。
【００５８】
識別された特定のアイテムの異なるインスタンス間で区別化を行うことによって、様々な他の方法およびプロセスが可能になる。例えば、１つの実施形態において、「従業員」と名づけられたテーブルのようなアイテムをハブに入れることができる。ハブ・コレクタは、ハブ内に２つの形式またはインスタンス（１つは物理データベース・インスタンスに対応し、他のものは論理モデリング活動に対応する）の「従業員」を有することができる。ハブ内のアイテムに帰属するアイテムのプロパティのような区別特性により、物理インスタンスと論理モデル・インスタンスまたは形式との間の区別が可能になる。実施形態において、その区別特性は、抽象化の論理レベルと物理レベルを区別するためといった、いわゆる抽象化レベルとすることができる。他の場合においては、ハブは、他の特性を、異なる形式の識別子、関係、クラス、属性、物理的位置、論理的位置、モデル等のようなアイテムと関連付けることができる。
【００５９】
図１５に示されるように、データベース内にロードされるデータの選択、データの変換、クエリの生成等のような操作を実行するとき、変換エンジン６２０４のようなシステムは、ハブ６２０８またはデータベース６２１０から、すべてのアイテムをグラブし、ロードし、または獲得することができる。システムは、何らかの区別特性に基づいて、アイテムを選択またはフィルタリングすることができる。例えば、システムは、物理的抽象化レベルを有する、他のアイテムと特定の関係を有する、論理的抽象化レベルを有する、指定された日および時間の前に作成された、またはいずれかの他の区別特性を有するインスタンスまたは形式を選択またはフィルタリングすることができる。したがって、ここで説明される方法およびシステムは、いずれかの区別特性に基づいた同じアイテムまたはエンティティのインスタンスの選択的な処理を提供する。
【００６０】
図１６に示されるように、クエリ６２０２に応答するものとすることができる、変換操作のようなデータ統合操作を実行するとき、変換エンジン６２０４は、ハブ６２０８またはデータベース６２１０において、任意のデータおよび／またはメタデータを含むアイテムをフィルタリングまたは選択することができ、関連する抽象化レベルのそれらのアイテムだけをグラブし、ロードし、または獲得することができる。例えば、変換エンジンは、論理的抽象化レベルを有するインスタンスまたは形式をフィルタリングまたは選択し、物理的抽象化レベルを有するものだけを保持することができる。フィルタリングまたは選択は、実行時および設計時に行うことができ、バッチで、リアルタイムで、または連続的に行うことができる。実施形態において、フィルタリングおよび選択のこうした方法は、サービス指向アーキテクチャにおけるＲＴＩサービスとして提供することができる。
【００６１】
フィルタリングまたは選択は、開発時、設計時、または実行時に変換エンジンおよび／またはシステムによって獲得される、データ・モデルのマッピング、メタデータ・モデルのマッピング、区別特性、アイテムと他のアイテムの関係、アイテムの属性、または識別子の構文などの情報に基づくものとすることができる。実施形態において、情報は、リアルタイムで動的に更新することができる。
【００６２】
プロセス全体においてフィルタリングまたは選択がハブまたはデータベースにより近いほど、操作がより効率的かつ高速になる。図１７に示されるように、変換エンジン６２０４は、クエリ６２０２自体の変換操作を行い、ハブ６２０８またはデータベース６２１０に直接送るなど、さらなる処理のために送ることができる改善されたクエリ６４０２を実現することができる。例えば、改訂されたクエリ６４０２は、ハブ６２０８またはデータベース６２１０の固有フォーマットと直接互換性のあるフォーマットにすることができる。例えば、クエリをデータベース６２１０の固有フォーマットにすることによって、システムは、クエリに対する処理効率を高めることができる。同様に、クエリ６４０２をフィルタリングすることができ、または物理エンティティではなく論理モデリング・エンティティを保持するために、選択コマンドのようなコマンドを生成することができ、この場合、クエリ５４０２は、データベースに適したフォーマットではなく、論理モデリング活動（グラフィカル・ユーザ・インターフェースのような）に適したフォーマットにすることができる。勿論、クエリのみならず他のメッセージおよび操作を、抽象化レベルに従ってフィルタリングし、同じエンティティが、データ統合プラットフォームにわたってトレースされ、特定のデータ統合活動の適切な操作環境に従って処理できるようにすることが可能である。
【００６３】
ここで説明される方法およびシステムを用いて、意味コンテキストを捕捉し、オブジェクト、データ・アイテム、データ、列、行、テーブル、データベース、インスタンス、属性、メタデータ、概念、トピック、主題、意味識別子、他の識別子、ＲＦＩＤタグ、ベンダー、供給業者、顧客、人、チーム、組織、ユーザ、ネットワーク、システム、装置、家族、店、製品、製造ライン、製品特性、製品仕様、製品属性、価格、コスト、材料仕様書、出荷データ、税金データ、コース、教育プログラム、位置、地図、部門、組織、有機的組織体、プロセス、規則、法、評価システム、商品、サービス、および／またはサービス提供のような、企業に関連した広範囲のアイテムに対してデータ統合タスクを処理することができる。
【００６４】
ここで説明される方法およびシステムは、企業の方法におけるステップ、データベース内のデータ、行または列内のデータ、テーブル内の行または列、データベース内の行または列、テーブル内のデータ、データベース内のテーブル、データベース内のメタデータ、ハブまたはリポジトリ内のアイテム、データベース内のアイテム、テーブル内のアイテム、列内のアイテム、行内のアイテム、組織内の人、通信の送信者または受信者、ネットワーク上のユーザ、ネットワーク上のシステム、ネットワーク上の装置、家族内の人、店の中の品目、メニュー上の料理、製造ライン内の製品、製品提供における製品、教育プログラムまたは訓練プログラムにおけるコースまたはステップ、地図上の位置、アイテムの位置、組織の部門、チームの人、規則システムにおける規則、サービス・スイートにおけるサービス、企業の組織階層内のエンティティ、供給チェーン内のエンティティ、マーケットにおける顧客、購買決定における購入者、商品またはサービスの価格、商品またはサービスのコスト、製造またはシステムの構成部品、方法のステップ、グループのメンバー、または多くの他のものといった、様々な意味コンテキストにおいて使用されることができる。
【００６５】
本発明は、特定の好ましい実施形態に関連して説明されたが、他の実施形態が、当業者によって認識され、本発明の範囲内に含まれるように意図されていることに留意されたい。
【図面の簡単な説明】
【００６６】
【図１】各々が複数の異なるコンピュータ・アプリケーションおよびデータ・ソースを含むことができる複数のビジネス・プロセスを有するビジネス・エンタープライズの概略図である。
【図２】ビジネス・エンタープライズの複数のビジネス・プロセスにわたるデータ統合を示す概略図である。
【図３】ビジネス・エンタープライズに複数のデータ・ソースのデータ統合を提供するためのアーキテクチャを示す概略図である。
【図４】他のアイテムとの関連でアイテムを示す。
【図５】他のアイテムとの関連でアイテムを示す。
【図６】特定のコンテキストにおけるアイテムを示す。
【図７】特定のコンテキストにおけるアイテムを示す。
【図８】特定の文字列を示す。
【図９】アイテムおよび対応する文字列を示す。
【図１０】文字列および特定の変形を示す。
【図１１】特定の文字列に作用する変換エンジンを示す。
【図１２】多数の形式またはインスタンスで存在することができるアイテムを示す。
【図１３】ハブまたはデータベースにおいて多数の形式またはインスタンスで存在することができるアイテムを示す。
【図１４】ハブ内の種々の抽象化レベルのアイテムを示す。
【図１５】データベースまたはハブにおいてすべてのアイテムがグラブされる変換プロセスを示す。
【図１６】データベースまたはハブにおいてすべてのアイテムがフィルタリングされる変換プロセスを示す。
【図１７】クエリが変換される変換プロセスを示す。
【図１】
2008511936.tif 000003
【図２】
2008511936.tif 000004
【図３】
2008511936.tif 000005
【図４】
2008511936.tif 000006
【図５】
2008511936.tif 000007
【図６】
2008511936.tif 000008
【図７】
2008511936.tif 000009
【図８】
2008511936.tif 000010
【図９】
2008511936.tif 000011
【図１０】
2008511936.tif 000012
【図１１】
2008511936.tif 000013
【図１２】
2008511936.tif 000014
【図１３】
2008511936.tif 000015
【図１４】
2008511936.tif 000016
【図１５】
2008511936.tif 000017
【図１６】
2008511936.tif 000018
【図１７】
2008511936.tif 000019
【国際調査報告】
2008511936.tif 000020
2008511936.tif 000021