JP2008511928A - メタデータの管理 - Google Patents

Abstract

【課題】 エンタープライズ・コンピュータ環境において、データ統合に関連して使用するためのより柔軟なメタデータ管理ツールを提供すること。
【解決手段】 エンタープライズ・コンピュータ環境において、データ統合に関連してメタデータを管理し、使用する方法及びシステムが、ここに提供される。メタデータ管理に対する統合されたプラットフォームに依存しない手法は、企業全体にわたるデータ統合サービス及び基礎データへのアクセスを可能にし、データ統合環境におけるツール及びジョブの再利用及び再設計を容易にすることができる。設計サイクル中に分岐し、併合することができ、企業にわたって動的に実装することができる、バージョン化されたメタデータ・モデルを保持することを含む、メタデータを管理するためのツールが提供される。プラットフォームに依存しない手法は、異種のハードウェア及びソフトウェア・コンピュータ環境における実装を含む様々な使用を容易にすることができる。
【選択図】 図１

Description

本発明は、情報技術の分野に関し、より特定的には、データ統合システムの分野に関する。

コンピュータ・アプリケーションの出現は、多くのビジネス・プロセスをより速く、より効率的なものにしてきたが、異なるデータ構造、通信プロトコル、言語及びプラットフォームを使用する異なるコンピュータ・アプリケーションの急増によって、一般的な企業の情報技術インフラストラクチャが極めて複雑になってきた。典型的な企業内における異なるビジネス・プロセスは、企業全体ではなく特定のビジネス・プロセスのために各々が開発され最適化される、全く異なるコンピュータ・アプリケーションを使用する場合がある。例えば、ビジネスが、支払勘定を追跡するための特定のコンピュータ・アプリケーションを有し、顧客との接触の経過を追跡するための全く異なるコンピュータ・アプリケーションとを有する場合がある。実際には、企業は集中顧客接触データベース(centralizedcustomer contact database)を保持するが、従業員は個人情報マネージャ(Personal information manager)などに彼ら自身の接触情報を保持するときなどに、同一のビジネス・プロセスでさえ、２つ以上のコンピュータ・アプリケーションを用いる場合がある。

専門のコンピュータ・アプリケーションは、顧客に合ったソリューションの利点をもたらすが、その急増は、同じデータを企業全体で何度も繰り返し入力して処理するといった非効率性や、企業が、１つのプロセスと関連するデータから利益を受ける別のプロセスを実行するときに、そのデータを利用できないことにつながる。例えば、支払勘定プロセスがサプライ・チェーン及び注文プロセスから分離される場合には、企業は、その信用履歴により該企業が注文を断わるであろう顧客からの注文を受け付け、応じる可能性がある。種々のコンピュータ・アプリケーション全体にわたるデータの全てに対して矛盾のないアクセスから企業が利益を得ることになる、他の多くの例を挙げることができる。

多くの会社が、企業における異なるアプリケーション間でデータを共有する必要性を認識し、これに取り組んできた。したがって、エンタープライズ・アプリケーションの統合(enterprise application integration)、すなわちＥＡＩが、異なるソースからのデータを処理するためのメッセージ・ベースの戦略として登場した。コンピュータ・アプリケーションの複雑さと数が増加するにつれて、ＥＡＩへの取り組みは、異なるプロトコルを処理する必要性、増え続けるデータ量及びトランザクション数を処理する必要性、並びに、データのより高速な統合に対する増え続ける要求にまで及ぶ、多くの課題に直面する。最小公分母アプローチ(least-common-denominatorapproach)、アトミック・アプローチ(atomic approach)及びブリッジ型アプローチ(bridge-type approach)を含む、ＥＡＩに対する様々なアプローチが行われた。しかしながら、ＥＡＩは、個々のアプリケーション間の通信に基づくものである。重大な欠点として、プラットフォーム及びアプリケーションの等差級数的な追加に応じて、ＥＡＩソリューションの複雑さは等比級数的に増大する。

データ統合システムは企業の必要性に対処するための有用なツールをもたらしたが、こうしたシステムは、典型的には、顧客ソリューションとして導入される。こうしたシステムは、長期にわたる開発サイクルを有し、ビジネス構造及び情報要件の変化に対応するために高度な技術的訓練を必要とすることがある。変化するビジネル環境において、機能の使用、再使用及び変更を可能にするデータ統合システム・ツールに対する必要性が残る。より特定的には、エンタープライズ・コンピュータ環境においてデータ統合と関連して使用するための、より柔軟なメタデータ管理ツールに対する必要性が残る。

エンタープライズ・コンピュータ環境において、データ統合に関連してメタデータを管理し、使用する方法及びシステムが、ここに提供される。メタデータ管理に対する統合されたプラットフォームに依存しない手法は、企業全体にわたるデータ統合サービス及び基礎データへのアクセスを可能にし、データ統合環境におけるツール及びジョブの再利用及び再設計を容易にすることができる。設計サイクル中に分岐し、併合することができ、企業にわたって動的に実装することができる、バージョン化されたメタデータ・モデルを保持することを含む、メタデータを管理するためのツールが提供される。プラットフォームに依存しない手法は、異種のハードウェア及びソフトウェア・コンピュータ環境における実装を含む様々な使用を容易にすることができる。

１つの態様において、ここで説明される方法は、クエリを第１のモデルに固有の用語で表現するステップと、第１のモデルと第２のモデルとの間の単数又は複数の関係を記述するマッピング情報を用いて、クエリを第２のモデルに固有の用語に変換するステップと、クエリを固有データ・ソース・フォーマットに変換するステップとを含む。別の態様において、システムは、クエリを第１のモデルに固有の用語で表現するための手段と、第１のモデルと第２のモデルとの間の単数又は複数の関係を記述するマッピング情報を用いて、クエリを第２のモデルに固有の用語に変換する手段と、クエリを固有のデータ・ソース・フォーマットに変換し、クエリがデータ・ソースに対して行われるようにするための手段を含む。

マッピング情報を照会することが可能である。マッピング情報は、変換ステップ中に利用可能である。第１のモデルは、ビューとすることができる。第２のモデルは、ハブとすることができる。データ・ソースは、データベースとすることができる。データベースは、単数又は複数のデータ・ソースについてのメタデータを格納することができる。データベースは、エンタープライズ・メタデータを表す持続モデルを格納することができる。データベースは、関係データベース及び／又はファイルとすることができる。本方法は、エンタープライズ・コンピュータ・システムにおいて実施することができ、又は、本システムがエンタープライズ・コンピュータ・システム内にあってもよい。本方法は、データ統合システムにおいて実施することができ、又は、本システムがデータ統合システム内にあってもよい。第１のモデルに固有の用語は、外部クライアントに固有の構文を含むことができる。第１のモデルは、ユーザ・インターフェースのためのビューとすることができる。本方法は、クエリ結果をユーザ・インターフェースに表示するステップをさらに含むことができ、又は本システムが、クエリ結果を表示するためのユーザ・インターフェースを含むこともできる。第１のモデルはサービスについてのビューとすることができる。サービスは、データ統合システム・サービスを含むことができる。サービスは、遠隔ツール及び／又はリアルタイム統合サービスを含むことができる。第１のモデル及び第２のモデルの少なくとも一方は、リポジトリ内に格納されたメタデータ・モデルとすることができる。本方法は、変換ツールを用いてクエリ結果を第１のモデルに変換するステップをさらに含むことができ、又は本システムが、対応する変換ツールを含むこともできる。変換ツールは、リポジトリ内に格納することができる。

別の態様においては、ここで説明される方法は、メタデータ・モデルをリポジトリに登録するステップと、第１のストレージ機構をメタデータ・モデルの単数又は複数の設計プロパティと関連付けるステップと、第２のストレージ機構をメタデータ・モデルの単数又は複数の運用プロパティと関連付けるステップとを含むことができ、第２のストレージ機構は、メタデータ・モデルの単数又は複数の運用プロパティの少なくとも１つのタイム・スタンプを格納する。

本方法においては、第１のストレージ機構は、メタデータ・モデルの単数又は複数の設計プロパティの少なくとも１つの単数又は複数のバージョンを格納する、バージョン化されたストレージ機構とすることができる。本方法は、メタデータ・モデルの単数又は複数の設計プロパティ及び単数又は複数の運用プロパティに注釈を付け、これらを第１のストレージ機構又は第２のストレージ機構のいずれかと関連付けるステップをさらに含むことができる。本方法は、メタデータ・モデルの単数又は複数の設計プロパティ及び単数又は複数の運用プロパティを第１のストレージ機構と第２のストレージ機構との間で割り当てるためのパッケージ構造を提供するステップをさらに含むことができる。本方法は、メタデータ・モデルの単数又は複数の設計プロパティ及び単数又は複数の運用プロパティを第１のストレージ機構と第２のストレージ機構との間で割り当てるための、メタデータ・モデルと関連付けられたマニフェストを提供するステップをさらに含むことができる。本方法は、運用プロパティを第１のモデルとして登録し、設計プロパティを第２のモデルとして登録するステップをさらに含むことができる。単数又は複数の運用プロパティ及び単数又は複数の設計プロパティにわたってメタデータ・モデルを照会することが可能である。本方法は、メタデータ・モデルとの単数又は複数のマッピングを登録するステップをさらに含むことができ、単数又は複数のマッピングは、メタデータ・モデルと単数又は複数の他のメタデータ・モデルとの関係を記述する。

別の態様において、システムは、登録されたメタデータ・モデルを含むリポジトリと、リポジトリ内にあり、メタデータ・モデルの単数又は複数の設計プロパティと関連付けられた第１のストレージ機構と、リポジトリ内にあり、メタデータ・モデルの単数又は複数の運用プロパティと関連付けられ、メタデータ・モデルの単数又は複数の運用プロパティの少なくとも１つのタイム・スタンプを格納するように適合された第２のストレージ機構とを含むことができる。

第１のストレージ機構は、メタデータ・モデルの単数又は複数の設計プロパティの少なくとも１つの単数又は複数のバージョンを格納する、バージョン化されたストレージ機構とすることができる。本システムは、メタデータ・モデルの単数又は複数の設計プロパティ及びメタデータ・モデルの単数又は複数の運用プロパティを、第１のストレージ機構又は第２のストレージ機構のいずれかと関連付けるための注釈を含むことができる。本システムは、第１のストレージ機構と第２のストレージ機構との間でメタデータ・モデルの単数又は複数の設計プロパティ及び単数又は複数の運用プロパティを割り当てるためのパッケージ構造を含むことができる。本システムは、メタデータ・モデルの単数又は複数の設計プロパティ及び単数又は複数の運用プロパティを第１のストレージ機構と第２のストレージ機構との間で割り当てるための、メタデータ・モデルと関連付けられたマニフェストを含むことができる。運用プロパティは、第１のモデルとして登録することができ、設計プロパティは、第２のモデルとして登録される。単数又は複数の運用プロパティ及び単数又は複数の設計プロパティにわたってメタデータ・モデルを照会することが可能である。本システムは、メタデータ・モデルとの登録された単数又は複数のマッピングをさらに含むことができ、単数又は複数のマッピングは、メタデータ・モデルと単数又は複数の他のメタデータ・モデルとの関係を記述する。

別の態様においては、モデルを持続させる方法は、第１のモデルを登録するステップと、第２のモデルと、第１のモデルの少なくとも１つのプロパティの第２のモデルへのマッピングとを識別するステップと、第１のモデルの少なくとも１つのプロパティの第２のモデルへのマッピングを持続させるステップとを含む。

本方法は、第２のモデルにマッピングされていない第１のモデルの少なくとも１つの他のプロパティを識別するステップと、第１のモデルの少なくとも１つの他のプロパティを持続させるステップとを含むことができる。第１のモデルは、複数のクラスを含むことができる。第２のモデルは、複数のクラスを含むことができる。本方法は、第１のモデルの少なくとも１つのプロパティの反射型ストレージ機構である第２のモデルへのマッピングを持続させるためのストレージ機構を提供するステップを含むことができる。本方法は、関係データベース内のメタデータ・モデルを表すためのスキーマを定めるステップと、このスキーマを用いて、第１のモデルの少なくとも１つのプロパティの第２のモデルへのマッピングを持続させるステップとをさらに含むことができる。本方法は、スキーマを変更することによって、関係データベース内の単数又は複数のプロパティを変更することによって、及び／又はマッピングを変更することによって、第１のモデルを改訂するステップをさらに含むことができる。第１のモデル及び第２のモデルは、メタデータ・モデルとすることができる。

別の態様においては、モデルを持続させるためのシステムは、第１のモデルの少なくとも１つのプロパティの第２のモデルへのマッピングと、第１のモデルを登録するためのリポジトリとを含むことができるので、リポジトリは、第１のモデルの少なくとも１つのプロパティの第２のモデルへのマッピングを持続させるように構成される。

第１のモデルの少なくとも１つの他のプロパティは、第２のモデルにマッピングすることができず、リポジトリは、第１のモデルの少なくとも１つの他のプロパティを持続させるように構成される。第１のモデル及び／又は第２のモデルの各々は、複数のクラスを含むことができる。本システムは、第１のモデルの少なくとも１つのプロパティの第２のモデルへのマッピングを持続させるためのストレージ機構をさらに含むことができ、このストレージ機構は、反射型ストレージ機構を含む。本システムは、関係データベース内のメタデータ・モデルを表すためのスキーマをさらに含むことができ、このスキーマは、第１のモデルの少なくとも１つのプロパティの第２のモデルへのマッピングを持続させる。スキーマを変更することによって、関係データベース内の単数又は複数のプロパティを変更することによって、及び／又はマッピングを変更することによって、第１のモデルが改訂される。第１のモデル及び第２のモデルは、メタデータ・モデルとすることができる。

別の態様においては、モデル駆動型メタデータ変換アーキテクチャが、単数又は複数のモデル間の変換のために単数又は複数のモデル対モデル・マッピングを用いる変換エンジンと、複数の変換エンジンの１つを動的に選択するための変換レジストリとを含むことができる。

変換エンジンは、コンパイルされた言語エンジン、解釈された言語エンジン、又は解釈されたマッピング・エンジンの単数又は複数を含むことができる。モデル対モデル・マッピングは、ハブ・スポーク・アーキテクチャにおけるハブと単数又は複数のビューとの間のものとすることができる。単数又は複数のモデル対モデル・マッピングは、ユーザ設定可能なものとすることができる。対応するモデルが導入された後、モデル対モデル・マッピングの１つを構成することができる。ハブと複数の同一ビューとの間の変換のための複数の変換エンジンにおいて、モデル対モデル・マッピングの１つを繰り返すことができる。ハブと複数の異なるビューとの間の変換のための複数の変換エンジンにおいて、異なるモデル対モデル・マッピングを実現することができる。

別の態様においては、メタデータをモデル間で変換する方法は、メタデータ変換要求を第１のモデルと第２のモデルとの間で受け取るステップと、第１のモデルと第２のモデルとの間の変換を特徴付けるモデル対モデル・マッピングを検索するステップと、モデル対モデル・マッピングを用いて、メタデータを第１のモデルから第２のモデルに変換するステップとを含む。

モデル対モデル・マッピングは、コンパイルされた言語、解釈された言語、又は変換エンジンによる変換のために適合されたマッピングを含むことができる。モデル対モデル・マッピングは、ハブ・スポーク・アーキテクチャにおけるハブとビューとの間のものにすることができる。本方法は、モデル対モデル・マッピングを構成するためのユーザ・インターフェースを提供するステップをさらに含むことができる。本方法は、モデル対モデル・マッピングを、動的アクセスのためのレジストリ内に格納するステップをさらに含むことができる。本方法は、第１のモデル及び第２のモデルのうち少なくとも１つが導入された後にモデル対モデル・マッピングを構成するステップをさらに含むことができる。ハブと複数の同一ビューとの間の変換のための複数の変換エンジンによって、モデル対モデル・マッピングを同時に用いることができる。本方法は、異なるモデル対モデル・マッピングが、ハブと複数の異なるビューとの間の変換のための複数の変換エンジンによって同時に用いられる、複数の異なるモデル対モデル・マッピングを登録するステップをさらに含むことができる。

１つの態様においては、ここで開示されるメタデータを管理する方法は、オブジェクト指向メタデータを運用プロパティを含む運用モデル及び設計プロパティを含む設計モデルに編成するステップと、運用モデルを動作リポジトリ内に格納するステップと、設計モデルを共有リポジトリ内に格納するステップとを含む。

本方法は、運用モデルについてのメタデータの少なくとも１つの項目にタイム・スタンプを押すステップをさらに含むことができる。共有リポジトリは、設計モデルの１つより多いバージョンをサポートすることができる。本方法は、モデルとのユーザ対話のためのメタデータ環境を提供するステップをさらに含むことができる。ユーザ環境は、モデルを編集するための作業空間を含むことができる。作業空間は、ユーザ専用のものとしてもよく、及び／又は、共有することもできる。メタデータ環境は、チーム空間を含むことができる。チーム空間は、メタデータ・インスタンスのバージョン化をサポートすることができる。メタデータ環境は、ユーザ・コンピュータ上に局所的に、又はユーザ・コンピュータにアクセス可能な遠隔サーバ上に、常駐することができる。本方法は、共有リポジトリ内の設計モデルの単数又は複数のバージョンを動的に比較するステップを含むことができる。共有リポジトリは、設計モデルのバージョンの分岐をサポートすることができる。本方法は、設計モデルの複数のバージョンを調整し、及び／又は、設計モデルの複数のバージョンを動的に調整するステップを含むことができる。本方法は、メッセージ指向サービスを通してメタデータ・モデルを非同期的に呼び出すことによって、メタデータ・サービス内のメタデータ・モデルを用いるステップ、及び／又は、アプリケーション・プログラミング・インターフェースを通してメタデータ・モデルを同期的に呼び出すことによって、メタデータ・サービス内のメタデータ・モデルを用いるステップを含むことができる。本方法は、メタデータ・モデルを使用するサービスを同時に実行するステップ、及び／又は、モデルを使用するサービスを実行するための並列処理を使用するステップを含むことができる。

ここで説明されるようなメタデータを管理するためのシステムは、メタデータ・モデルの単数又は複数の運用プロパティを有する運用モデル及びメタデータ・モデルの単数又は複数の設計プロパティを有する設計モデルを含むオブジェクト指向メタデータ・モデルと、運用モデルを格納する運用リポジトリと、設計モデルを格納する共有リポジトリとを含むことができる。

運用モデルからのメタデータの少なくとも１つの項目にタイム・スタンプを押すことができる。共有リポジトリは、設計モデルの１つより多いバージョンをサポートすることができる。システムは、モデルとのユーザ対話のためのメタデータ環境を含むことができる。ユーザ環境は、モデルを編集するための作業空間を含むことができる。作業空間は、ユーザ専用のものとしてもよく、又は共有することもできる。メタデータ環境は、チーム空間を含むことができる。チーム空間は、メタデータ・インスタンスのバージョン化をサポートすることができる。メタデータ環境は、ユーザ・コンピュータ上に局所的に、又は遠隔サーバ上に、常駐することができる。共有リポジトリは、設計モデルの単数又は複数の異なるバージョンの動的比較をサポートすることができる。共有リポジトリは、設計モデルのバージョンの分岐をサポートすることができる。共有リポジトリは、設計モデルの複数のバージョンの調整をサポートすることができる。共有リポジトリは、設計モデルの複数のバージョンの動的調整をサポートすることができる。システムは、メッセージ指向メタデータ・サービスを通してメタデータ・モデルを非同期的に呼び出すことによってメタデータ・モデルを用いるメタデータ・サービス、及び／又は、アプリケーション・プログラミング・インターフェースを通してメタデータ・モデルを同期的に呼び出すことによってメタデータ・モデルを用いるメタデータ・サービスを含むことができる。同時処理又は並行処理の少なくとも一方を実行するサービスにおいて、メタデータ・モデルを用いることができる。

ここで開示されるようなメタデータの調整方法は、共通のセットの調整規則によって特徴付けられる調整区域を識別する調整区域プロパティをメタデータ・オブジェクトと関連付けるステップと、共通のセットの調整規則に従って複数のメタデータ・オブジェクト・インスタンスを調整し、調整区域内に調整されたメタデータ・オブジェクト・インスタンスを提供するステップとを含むことができる。

本方法は、単数又は複数の付加的なメタデータ・オブジェクト・インスタンスを用いて、調整されたメタデータ・オブジェクト・インスタンスを調整するための第２の調整区域を定めるステップを含むことができる。調整区域は、複数のメタデータ・オブジェクト・インスタンスを含むことができる。本方法は、メタデータ・オブジェクト・インスタンスの処理を定める一致タイプを調整区域プロパティと関連付けるステップをさらに含むことができる。本方法は、識別を、調整区域内のメタデータ・オブジェクト・インスタンスを一意的に識別するメタデータ・オブジェクト・インスタンスと関連付けるステップをさらに含むことができる。本方法は、メタデータ・オブジェクトについての調整系統を提供するステップをさらに含むことができる。調整系統は、単数又は複数の調整区域を通る経路を記述し、単数又は複数のデータ・ソースを識別し、単数又は複数の調整規則を識別し、及び／又はメタデータ・オブジェクト・インスタンスの履歴を含むことができる。

別の態様においては、ここで説明されるようなメタデータを調整するためのシステムは、共通のセットの調整規則によって特徴付けられる調整区域と、複数のメタデータ・オブジェクト・インスタンスの各々を調整区域と関連付ける調整区域プロパティを含む複数のメタデータ・オブジェクト・インスタンスと、複数のメタデータ・オブジェクト・インスタンスが関連付けられる調整区域に関する共通のセットの調整規則に従って複数のメタデータ・オブジェクト・インスタンスを調整することによって調整区域内に調整されたメタデータ・オブジェクト・インスタンスを生成する調整エンジンと、を含むことができる。

本システムは、単数又は複数の付加的なメタデータ・オブジェクト・インスタンスを用いて、調整されたメタデータ・オブジェクト・インスタンスを調整するための第２の調整区域を含むことができる。調整区域は、複数のメタデータ・オブジェクト・インスタンスを含むことができる。一致タイプは、調整区域内のメタデータ・オブジェクト・インスタンスの処理を定めることができる。メタデータ・オブジェクト・インスタンスの各々と関連付けられた識別は、調整区域内のそのメタデータ・オブジェクト・インスタンスを一意的に識別することができる。メタデータ・オブジェクトに対して、調整系統を提供することができる。調整系統は、単数又は複数の調整区域を通る経路を記述し、単数又は複数のデータ・ソースを識別し、単数又は複数の調整規則を識別し、及び／又はメタデータ・オブジェクト・インスタンスの履歴を含むことができる。

別の態様においては、データ統合システムのためにメタデータ・サービスの同時処理を提供する方法は、メタデータ・サービスをオブジェクト・ストリームに分けるステップと、オブジェクトに関するメタデータに基づいて、一次内的参照を有するオブジェクトのクラスタを識別するステップと、複数のプロセッサの単一のものにおいてオブジェクト・クラスタを実行するステップと、オブジェクト・クラスタの外にある少なくとも１つのオブジェクトを識別するステップと、複数のプロセッサの別のものにおいて少なくとも１つのオブジェクトを実行するステップと、を含むことができる。

オブジェクトは、少なくとも１つのメタデータ・モデルを含むことができる。プロセッサは、物理的に別個のハードウェア上にある。サービスは、メタデータの競合を解決する調整プロセスを含むことができる。オブジェクトは、メタデータ・インポートを含むことができる。一次内的参照は、データ依存関係のグラフを用いて識別することができる。サービスは、同時処理のためのパイプラインとして編成することができる。パイプラインは、少なくとも、オブジェクト識別フェーズ、候補者取り出しフェーズ、調整フェーズ、併合フェーズ及び格納フェーズを含むことができる。

他の態様において、コンピュータ・プログラム製品は、コンピュータ可読プログラム・コードを含むコンピュータ使用可能媒体を含むことができ、コンピュータ可読プログラム・コードは、単数又は複数のコンピュータ上で実行されたとき、単数又は複数のコンピュータに、上記の方法のいずれか単数又は複数を行わせる。

本明細書において用いられる「Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ」又は「ＩＢＭ」は、ニューヨーク州アーモンク所在のインターナショナル・ビジネス・マシーンズ・コーポレーション社を指す。

ここで用いられる「データ・ソース」又は「データ・ターゲット」は、特定の意味が他に示されるか又は語句の文脈を別に要求することがない限り、これらの用語と矛盾しない最も広範な意味を持つように意図されており、データベース、複数のデータベース、リポジトリ情報マネージャ、キュー、メッセージ・サービス、リポジトリ、データ機器、データ・ストレージ機器、データ・プロバイダ、ウェブサイト、サーバ、コンピュータ、コンピュータ・ストレージ機器、ＣＤ、ＤＶＤ、モバイル・ストレージ機器、中央ストレージ機器、ハードディスク、複数の調整データ・ストレージ機器、ＲＡＭ、ＲＯＭ、フラッシュメモリ、メモリカード、一時メモリ機器、永続メモリ機器、磁気テープ、ローカル接続コンピューティング機器、遠隔接続コンピューティング機器、無線機器、有線機器、モバイル機器、中央機器、ウェブ・ブラウザ、クライアント、ラップトップ、携帯情報端末（「ＰＤＡ」）、電話、携帯電話、移動電話、情報プラットフォーム、分析機器、処理機器、ビジネス・エンタープライズ・システム又はデータを処理する他の機器若しくはデータ又は他の情報並びに上記のシステムのいずれかに用いられる構造化されたデータ又は構造化されていないデータ或いはいずれかのストリーミング・データ、メッセージ化データ、イベント駆動データ若しくはソース・データを保持するための何らかのファイル又はファイル・タイプを格納するようになった他の機器、及び、上記のいずれかの組み合わせを含むものとする。ストレージ機構とは、何らかの物理装置又は論理装置、リソース、或いは、データ・ソース若しくはデータ・ターゲットとして機能を果たすか、さもなければ検索可能な形式でデータを格納することができる機器である。

「Ｅｎｔｅｒｐｒｉｓｅ Ｊａｖａ Ｂｅａｎ（ＥＪＢ）」は、Ｊ２ＥＥプラットフォームのためのサーバ側のコンポーネント・アーキテクチャを含むものである。ＥＪＢは、分散Ｊａｖａアプリケーション、トランザクションＪａｖａアプリケーション、セキュア及びポータブルＪａｖａアプリケーションの迅速で簡単な開発をサポートする。ＥＪＢは、メッセージの並行処理（ｃｏｎｃｕｒｒｅｎｔ ｃｏｎｓｕｍｐｔｉｏｎ）を可能にするコンテナ・アーキテクチャをサポートし、分散トランザクションをサポートするため、Ｊ２ＥＥアーキテクチャを用いるデータベース更新、メッセージ処理及びエンタープライズ・システムへの接続が、同一のトランザクション・コンテキストに関与することが可能になる。

「ＪＭＳ」は、ＪａｖａベースのＪ２ＥＥエンタープライズ・アーキテクチャのためのエンタープライズ・メッセージ・サービスであるＪａｖａ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅを意味する。「ＪＣＡ」は、以下により詳細に説明されるＪ２ＥＥプラットフォームのＪ２ＥＥ Ｃｏｎｎｅｃｔｏｒ Ａｒｃｈｉｔｅｃｔｕｒｅを意味する。ＥＪＢ、ＪＭＳ及びＪＣＡは、現代の分散トランザクション環境において一般的に用いられるソフトウェア・ツールであるが、同様の機能を提供するいずれかのプラットフォーム、システム又はアーキテクチャを本明細書において説明されるデータ統合システムと共に利用できることを理解すべきである。

本明細書において用いられる「リアルタイム」は、ビジネス・トランザクション又はビジネスの継続時間に近い時間の間隔を含み、夜間に行われるバッチ処理操作のようなオフラインで行われるものとは対照的に、営業活動又はビジネス・プロセス中に行われるプロセス又はサービスと含むものとする。ビジネル・プロセスの継続時間によって、リアルタイムは、秒、一瞬、分、時間、或いはさらに日を含む場合がある。

本明細書において用いられる「ビジネス・プロセス」、「ビジネス論理」及び「ビジネス・トランザクション」は、これらに限定されるものではないが、販売、マーケティング、フルフィルメント、在庫管理、価格付け、製品設計、専門的サービス、金融サービス、管理、財務、引受業務、分析、契約、情報技術サービス、データ・ストレージ、データ・マイニング、情報の配信、商品の経路指定、スケジューリング、通信、投資、トランザクション、提供、販売促進、広告、付け値、エンジニアリング、製造、サプライ・チェーン管理、人事管理、データ処理、データ統合、ワークフロー管理、ソフトウェア生成、ハードウェア生産、新製品の開発、研究、開発、戦略機能、品質管理及び保証、パッケージ化、物流、顧客関係管理、リベート及び返品処理、顧客サポート、製品保守、電話勧誘、企業広報、投資家向け広報活動、及び、他の多くのものを含む、企業が行うことができるあらゆる方法、サービス、運用、プロセス、又は取引を含むものとする。

本明細書において用いられる「サービス指向アーキテクチャ（ＳＯＡ）」は、企業のインフラストラクチャの一部を形成するサービスを含む。ＳＯＡにおいては、サービスは、迅速なアプリケーション開発を可能とし、冗長なコードを避ける、アプリケーションの開発及び導入のための構成単位となることがある。各々のサービスは、サービスについてのデータ入力のソース、又はサービスのデータ出力のターゲットといった、周囲環境に結合できるビジネス論理又はビジネス規則の組を具体化することができる。ＳＯＡの種々の例が、以下の説明において提供される。

本明細書において用いられる「メタデータ」は、処理されるデータにコンテキストを導入するデータ、データに関するデータ、関連情報のコンテキストに関する情報、データの出所に関する情報、データの場所に関する情報、データの意味に関する情報、データの経過時間に関する情報、データの見出しに関する情報、データの単位に関する情報、データのフィールドに関する情報、及び／又は、データのコンテキストに関連する他のいずれかの情報に関する情報を含むものとする。

本明細書において用いられる「ＷＳＤＬ」すなわち「ウェブ・サービス記述言語（Ｗｅｂ Ｓｅｒｖｉｃｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）」は、文書指向情報又は手続き指向情報のいずれかを含むメッセージ上で動作するエンドポイントの組としてネットワーク・サービス（多くの場合、ウェブ・サービス）を記述するためのＸＭＬフォーマットを含む。動作及びメッセージは、抽象的に記述され、次いでエンドポイントを定めるために具体的なネットワーク・プロトコル及びメッセージ・フォーマットに結合される。関連する具体的なエンドポイントは、抽象的なエンドポイント（サービス）に組み合わされる。ＷＳＤＬは、どのメッセージ・フォーマット又はネットワーク・プロトコルが通信に用いられるかにかかわらず、エンドポイント及びそれらのメッセージの記述を可能にするように拡張可能である。

以下の説明全体を通して、特に示されない限り、同様の要素の数字は、同じ要素を指すことが意図される。

本明細書に開示される本発明は、全体がハードウェアの実施形態、全体がソフトウェアの実施形態、又は、ハードウェア要素とソフトウェア要素の両方を含む実施形態の形式を取ることができる。好ましい実施形態においては、本発明は、これらに限定されるものではないが、ファームウェア、常駐ソフトウェア、マイクロコード等を含むソフトウェアにおいて実施される。

さらに、本発明は、コンピュータ又はいずれかの命令実行システムによって、又はこれらと接続して、用いるためのプログラム・コードを提供するコンピュータ使用可能又はコンピュータ可読媒体からアクセス可能なコンピュータ・プログラム製品の形態を取ることができる。この説明のために、コンピュータ使用可能又はコンピュータ可読媒体は、命令実行システム、装置によって、又はこれらと接続して、用いるためのプログラムを含み、格納し、通信し、伝搬し、又は転送することが可能ないずれかの装置とすることができる。

媒体は、電子システム、磁気システム、光システム、電磁システム、赤外線システム、若しくは半導体システム（又は装置）又は伝搬媒体とすることができる。コンピュータ可読媒体の例は、半導体メモリ又はソリッドステート・メモリ、磁気テープ、取り外し可能コンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、磁気ハードディスク及び光ディスクを含む。現時点における光ディスクの例は、コンパクト・ディスク−読み取り専用メモリ（ＣＤ−ＲＯＭ）、コンパクト・ディスク−読み取り／書き込みメモリ（ＣＤ−Ｒ／Ｗ）及びＤＶＤを含む。

プログラム・コードを格納及び／又は実行するのに適したデータ処理システムは、システム・バスを通してメモリ要素に直接的に又は間接的に結合された少なくとも１つのプロセッサを含む。メモリ要素は、プログラム・コードの実際の実行時に使用されるローカル・メモリと、大容量記憶装置と、実行時に大容量記憶装置からコードを取得しなければならない回数を減少させるように少なくとも幾つかのプログラム・コードの一時的な記憶場所を提供するキャッシュ・メモリとを含むことができる。

入力／出力装置すなわちＩ／Ｏ装置（これらに限定されるものではないが、キーボード、ディスプレイ、ポインティング・デバイス等を含む）は、直接的に、又は介在するＩ／Ｏコントローラを通して、システムに結合することができる。

介在するプライベート・ネットワーク又は公衆ネットワークを通して、データ処理システムを他のデータ処理システム又は遠隔プリンタ若しくはストレージ・デバイスに結合できるように、ネットワーク・アダプタをシステムに結合することもできる。モデム、ケーブル・モデム及びイーサネット・カードは、現時点で利用可能なタイプのネットワーク・アダプタのうちのほんの幾つかである。

図１は、企業の様々なデータの統合を容易にするためのプラットフォーム１００を表す。プラットフォームは、各々が複数の異なるコンピュータ・アプリケーション及びデータ・ソースを含むことができる複数のビジネス・プロセスを含む。プラットフォームは、上述のようなデータ・ソースとすることができる幾つかのデータ・ソース１０２を含むことができる。これらのデータ・ソースは、様々な物理的場所からの様々なデータ・タイプを含むことができる。例えば、データ・ソースは、Ｓｙｂａｓｅ、Ｍｉｃｒｏｓｏｆｔ、Ｉｎｆｏｒｍｉｘ、Ｏｒａｃｌｅ、Ｉｎｌｏｍｏｖｅｒ、ＥＭＣ、Ｔｒｉｌｌｉｕｍ、Ｆｉｒｓｔ Ｌｏｇｉｃ、Ｓｉｅｂｅｌ、ＰｅｏｐｌｅＳｏｆｔ、ＩＢＭ、Ａｐａｃｈｅ、又はＮｅｔｓｃａｐｅなどのプロバイダからのシステムを含むことができる。データ・ソース１０２は、ＩＭＳ、ＤＢ２、ＡＤＡＢＡＳ、ＶＳＡＭ、ＭＤ Ｓｅｒｉｅｓ、ＵＤＢ、ＸＭＬ、複合フラット・ファイル、又はＦＴＰファイルなどのデータベース製品又は標準を用いるシステムを含むことができる。データ・ソース１０２は、Ｍｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋ、Ｍｉｃｒｏｓｏｆｔ Ｗｏｒｄ、Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｅｌ、Ｍｉｃｒｏｓｏｆｔ Ａｃｃｅｓｓのようなアプリケーションによって作成又は使用されるファイル、並びに、ＡＳＣＩＩ、ＣＳＶ、ＧＩＦ、ＴＩＦ、ＰＮＧ等のような標準フォーマットのファイルを含むことができる。データ・ソース１０２は、様々な場所からのものとするか、又は集中的に配置することもできる。データ・ソース１０２から供給されるデータは、様々な形式のものとすることができ、互いに互換性があるもの又は互換性のないものとすることができる異なるフォーマットを有することができる。

データ・ターゲットは、本明細書の後半で説明される。一般に、これらのデータ・ターゲットは、上述のデータ・ソース１０２のいずれかとすることができる。こうした用語の使い方の違いは、一般的には、データ統合プロセスにおいてデータ・システムがデータを提供するのか、又はデータを受け取るのかを示すものである。しかしながら、従来のデータ統合システムにおいては、データ・ソースがデータを受け取り、データ・ターゲットがデータを提供することができるため、この区別は、（特に他に記述がない限り）データ・ソースとデータ・ターゲットとの間の能力に関して違いを与えることを意図するものではないことを理解すべきである。

図１に示されたプラットフォームはまた、データ統合システム１０４も含む。データ統合システムは、例えば、データ統合システム１０４が受信するクエリ又は検索コマンドの結果として、データ・ソース１０２からのデータの収集を容易なものとすることができる。データ統合システム１０４は、データ・ソースがデータをデータ統合システム１０４に与えるように、データ・ソース１０２の単数又は複数に対してコマンドを送信することができる。受信されたデータは、様々なメタデータを含む多数のフォーマットのものとすることができるため、データ統合システムは、統合処理のために後に結合することができるように、受信したデータを再構成することができる。データ統合システム１０４によって行うことができる機能は、以下により詳細に説明される。

プラットフォーム１００はまた、幾つかの検索システム１０８も含む。検索システム１０８は、データ統合システム１０４から送信されるデータをさらに操作するのに用いられるデータベース又は処理プラットフォームを含むことができる。例えば、データ統合システム１０４は、検索システム１０８が、処理されたデータを用いてビジネスに有用なレポート１１０を生成することができるように、データ・ソース１０２から受信するデータを浄化し、結合し、変換し、又は、他の方法で操作することができる。レポート１１０を用いて、データの関連性を報告し、複雑なクエリに回答し、単純なクエリに回答し、又は、ビジネス若しくはユーザに有用な他の報告を作成することができ、生データ、テーブル、チャート、グラフ、及び検索システム１０８からのデータの他のいずれかの表現を含むことができる。

プラットフォーム１００はまた、データベース又はデータベース管理システム１１２を含むこともできる。データベース１１２を用いて、時間的に、一時的に、又は永続的若しくは長期的な記憶として、情報を格納することができる。例えば、データ統合システム１０４は、単数又は複数のデータ・ソース１０２からデータを収集し、そのデータを、互いに互換性がある形式又は互いに結合することができる形式に変換することができる。データが変換されると、データ統合システム１０４は、後の検索のために、分解形式、結合形式、又は他の形式で、データをデータベース１１２に格納することができる。

図２は、企業の複数のエンティティ及びビジネス・プロセス間のデータ統合を示す概略図である。示される実施形態においては、データ統合システム１０４は、情報がユーザ・インターフェース・システム２０２とデータ・ソース１０２との間を流れるのを容易にする。データ統合システム１０４は、データ・ソース１０２の単数又は複数に存在するデータの抽出と、場合によっては変換とを必要とするクエリを、インターフェース・システム２０２から受信することができる。インターフェース・システム２０２は、ラップトップ・コンピュータ若しくはデスクトップ・コンピュータ、携帯電話、個人用情報端末（「ＰＤＡ」）、ネットワーク化プラットフォーム、及びこれらに取り付けられる装置上で作動するウェブ・ブラウザといった、データ統合システム１０４と通信するためのいずれかの装置及びプログラム、又は、データ統合システム１０４とインターフェース接続される他のいずれかの装置又はシステムを含むことができる。

例えば、ユーザは、ＰＤＡを操作して、ＷｉＦｉ又はワイヤレス・アクセス・プロトコル／ワイヤレス・マークアップ言語（「ＷＡＰ／ＷＭＬ」）インターフェースを介してデータ統合システム１０４に情報を要求することができる。データ統合システム１０４は、その要求を受信して、ウェブサイト又はＦＴＰファイル・サイト等の他のデータ・ソース１０２から情報にアクセスするために、必要ないずれかのクエリを生成することができる。データ・ソース１０２からのデータは、抽出され、要求するインターフェース・システム２０２（この例ではＰＤＡ）と互換性のあるフォーマットに変換され、次いで、ユーザが見て操作するためのインターフェース・システム２０２に送信することができる。別の実施形態においては、データは、データ・ソースから予め抽出され、データ統合システム１０４によって用いられるデータ・ウェアハウス又は他のデータ機器とすることができる別個のデータベース１１２に格納しておくことができる。データは、変換された状態で、又はその元の状態で、データベース１１２に格納することができる。例えば、データは、多くのデータ・ソース１０２からのデータを別の変換プロセスで結合することができるように、変換された状態で格納することができる。例えば、ＰＤＡからのクエリをデータ統合システム１０４に送信することができ、データ統合システム１０４は、データベース１１２から情報を抽出することができる。抽出後に、データ統合システム１０４は、そのデータをＰＤＡに返信する前にＰＤＡと互換性のある結合フォーマットに変換することができる。

図３は、企業の複数のデータ・ソース１０２についてのデータ統合を提供するためのアーキテクチャを示す概略図である。データ統合システム１０４の実施形態は、場合によっては他の処理の間で、データ・ソースからのデータの抽出と、ソース・データについての列の値及びテーブル構造の分析とを実行するデータ発見段階３０２を含むことができる。データ発見段階３０２はまた、データ・ターゲットについてのテーブル構造、関係及びキーに関する推奨を生成することができる。より高度なプロファイリング及び監査機能は、日付範囲の検証、計算の精度、イフゼン(if-then)評価の精度等を含むことができる。データ発見段階３０２は、ソース・データの冗長依存性(redundantdependency)及び他の異常を排除することなどによって、データを正規化することができる。データ発見段階３０２は、さらなる分析のためにデータ・ソース１０２内部の例外を掘り下げること又はメインフレーム・データの直接プロファイリングを可能にすることなどの、付加的な機能を提供することができる。データ発見段階３０２の市販形態の限定されない例は、ＩＢＭ社のＷｅｂｓｐｈｅｒｅ ＰｒｏｆｉｌｅＳｔａｇｅ製品に見出すことができる。

データ統合システム１０４はまた、後に変換されることになる品質データ（ｑｕａｌｉｔｙ ｄａｔａ）を生成するために、データを準備し、標準化し、照合し、又は他の方法で操作する、データ準備段階３０４を含むこともできる。データ準備段階３０４は、データ内の不整合を調整すること、又は（１対１の照合、１対多数の照合及び重複排除（ｄｕｄｕｐｌｉｃａｔｉｏｎ）を含む）正確な照合を行うことといった、一般的なデータ品質機能を実行することができる。データ準備段階３０４はまた、特定のデータ拡張機能を提供することもできる。例えば、データ準備段階３０４は、国際通信の改善のために、住所が多国間の郵便基準（ｍｕｌｔｉｎａｔｉｏｎａｌ ｐｏｓｔａｌ ｒｅｆｅｒｅｎｃｅ）に適合することを確実なものにすることができる。データ準備段階３０４は、空間情報の管理のために、位置データを多国間ジオコーディング標準（ｍｕｌｔｉｎａｔｉｏｎａｌ ｇｅｏｃｏｄｉｎｇ ｓｔａｎｄａｒｄ）に適合させることができる。データ準備段階３０４は、住所情報が、Ｇｏｖｅｒｎｍｅｎｔ Ｃｅｒｔｉｆｉｅｄ Ｕ．Ｓ．Ａｄｄｒｅｓｓ Ｃｏｒｒｅｃｔｉｏｎの下でＵ．Ｓ．Ｐｏｓｔａｌ Ｓｅｒｖｉｃｅの郵便料金割引を受ける資格があるものであることを保証するために、住所を変更又は追加することができる。同様の分析及びデータ改訂を、適切に住所が記載された郵便について割引料金を提供する、カナダ及びオーストラリアの郵便システムに導入することができる。データ準備段階３０４の市販形態の限定されない例は、ＩＢＭ社のＷｅｂｓｐｈｅｒｅ ＱｕａｌｉｔｙＳｔａｇｅ製品に見出すことができる。

データ統合システムはまた、変換されたデータを変換し、質を高めて配信するデータ変換段階３０８を含むこともできる。データ変換段階３０８は、データの再構成及び再フォーマットのような移行サービスを実行し、システム・ユーザのビジネス規則及びアルゴリズムに基づいて計算を実行することもできる。データ変換段階３０８はまた、特定の分析コンテキストにおけるデータのより高度な調整処理のために、ターゲット・データをデータマート又はキューブとして知られるサブセットに編成することもできる。データ変換段階３０８は、データ統合システム１０４によって使用される様々なデータ・ソース及びデータ・ターゲットの様々なソフトウェア・アーキテクチャ及びハードウェア・アーキテクチャの橋渡しをする、（以下に一般的に説明されるような）ブリッジ、トランスレータ、又は他のインターフェースを用いることができる。データ変換段階３０８は、プラットフォーム１００全体にわたるデータ統合ジョブを設計するために、グラフィカル・ユーザ・インターフェース、コマンドライン・インターフェース、又はこれらの何らかの組み合わせを含むことができる。データ変換段階３０８の市販形態の限定されない例は、ＩＢＭ社のＷｅｂｓｐｈｅｒｅ ＤａｔａＳｔａｇｅ製品に見出すことができる。

データ統合システム１０４の段階３０２、３０４、３０８は、該システム１０４の性能を最適化するために、並列実行システム３１０を連続的に又は組み合わせて用いて実行することができる。

データ統合システム１０４はまた、データ・ソース１０２と関連するメタデータを管理するためのメタデータ管理システム３１２を含むこともできる。一般に、メタデータ管理システム３１２は、データ統合環境におけるツールの全てにわたって、メタデータの交換、統合、管理及び分析を提供することができる。例えば、メタデータ管理システム３１２は、ＩＢＭのＷｅｂｓｐｈｅｒｅ ＯＤＢＣ ＭｅｔａＢｒｏｋｅｒ、ＣＡ ＥＲｗｉｎ、ＩＢＭ Ｗｅｂｓｐｈｅｒｅ ＰｒｏｆｉｌｅＳｔａｇｅ、ＩＢＭ Ｗｅｂｓｐｈｅｒｅ ＤａｔａＳｔａｇｅ、ＩＢＭ Ｗｅｂｓｐｈｅｒｅ ＱｕａｌｉｔｙＳｔａｇｅ、ＩＢＭ ＤＢ２ Ｃｕｂｅ Ｖｉｅｗｓ及びＣｏｇｎｏｓ Ｉｍｐｒｏｍｐｔｕのような、異なるソースにおけるデータの、広くアクセス可能な共通のビューを提供することができる。メタデータ管理システム３１２はまた、データ系統及び影響分析のための分析ツールを提供することもできる。さらに、メタデータ管理システム３１２を用いて、データ統合システム１０４内のデータについてのデータ定義、アルゴリズム及びビジネル・コンテキストのビジネス・データ用語集を作成することができ、この用語集は、企業全体で用いられるように公開することができる。メタデータ管理システム３１２の市販形態の限定されない例は、ＩＢＭのＷｅｂｓｐｈｅｒｅ ＭｅｔａＳｔａｇｅ製品に見出すことができる。

特に示されるか又は文脈によって必要とされない限り、「マッピング」という用語は、ビュー、モデル、又はモデル・インスタンスの間の関連するメタデータ及びメタ・メタデータの設計時の活動を指し、「変換」は、対応するリアルタイムの活動を指す。以下の説明は、実際には、アトミック・データ項目をモデル化するデータ・ソースについてのメタデータである、メタデータ管理システムに関するものであることにも留意すべきである。同様に、メタデータ管理システム内のメタデータは、実際には、メタ・メタデータとしても知られる、このメタデータを記述するメタデータである。メタ・メタデータをさらに抽象化し、メタ・メタ・メタデータにすることも可能であり、妥当である。混乱を避けるために、下記の名称は、一般的に、データ、メタデータ、メタ・メタデータの階層に従っており、ここでデータは、単数又は複数のデータ・ソース／ターゲットについての基礎データを表す。しかしながら、場合によっては、メタデータを単にデータ（メタデータ管理システムによって管理されるデータである）と呼ぶこともでき、メタ・メタデータは、これに対応して単にメタデータ、すなわちメタデータ管理システム内のモデルの立場からのメタデータと呼ぶこともできることを理解すべきである。より一般的には、使用法は、コンテキストから明らかになるはずである。しかしながら、使用法が不明瞭な場合には、可能な限り幅広い意味で解釈すべきである。

図４は、例えば、上述のメタデータ管理システム又はメタデータ機器３１２のいずれかとすることができる、メタデータ管理システム５２０２のためのアーキテクチャを示す。メタデータ管理システム５２０２は、複数のビュー５２０８を通してハブ５２０６と通信する、ツール又はクライアントのような複数の外部ユーザ５２０４と、モデル５２１２の運用メタデータに関連する少なくとも１つの運用クラス５２１４及び／又はモデル５２１２の設計メタデータに関連する少なくとも１つの設計クラス５２１６を有する、少なくとも１つのモデル５２１２を含むリポジトリ５２１０とを含むことができる。リポジトリ５２１０内のモデル５２１２と対話するために、メタデータ・サービス５２１８を提供することができる。

ユーザ５２０４は、上述のインターフェース・システム２０２のいずれか、又は他の何らかのクライアント装置、ツール、或いはソフトウェア・インターフェースの他のプログラムとすることができ、これらを通じて、ユーザがクエリを実行するか又は他の方法でデータベース内のデータを調査することができる。ユーザ５２０４は、ユーザ５２０４が用いるデータ・モデルとハブ５２０６が用いるデータ・モデルとの間で通信するように適合されたビュー５２０８を用いて、クエリを実行することができる。ビュー５２０８は、例えば、フィールド、データ・タイプ、データ階層、データ関係、時間情報、ソース情報、或いは、データがユーザ５２０２によって表示又は使用される方法、及び、外部ユーザ５２０４に提供されるビュー５２０８内のデータ・モデルとハブ５２０６によって内部で用いられるデータ・モデルとの間の何らかの適切なマッピングに関連する何らかの他の情報を含むことができる。図４においては、２つのビュー５２０８だけが示されるが、任意の数のビュー５２０８を用いることができること、かつ、ビュー５２０８は、同じタイプの外部ユーザ５２０４が１つより多く存在する場合には同じビュー５２０８とすることができ、異なる外部ユーザ５２０４が存在する場合には異なるビュー５２０８とすることができ、或いはメタデータ管理システムの処理能力と矛盾がないこれらのビューの任意の数及び組み合わせとすることができることが理解されるであろう。

外部ユーザ５２０４は、ユーザ５２０４に特有のものであり、ハブ５２０６内に対応する要素を持たないデータ又はメタデータを使用できることも理解すべきである。例えば、Ｅｒｗｉｎ設計ツールは、Ｅｒｗｉｎに特有のオブジェクト「座標」を使用し、図形「キャンバス」においてオブジェクトが現れる場所を記述する。ハブ５２０６は、ユーザ５２０４にトランスペアレントな方法でハブ・モデルへの拡張をサポートすることによって、特例を処理するように設計することができる。随意的には、ビュー５２０８はまた、或いは代わりに、ハブ５２０６への接続に加えて、適切な外部データへの直接的マッピングを提供することもできる。

ハブ５２０６は、一般に、データの主題又はそのビジネス・コンテキストによって定められるデータ・モデル５２１２を用いることができる。したがって、一般に、データについてのハブ・モデルは、単一のアプリケーション内で頻繁に変更されないと予想される。ハブ・モデルに変更がなされる場合には、単数又は複数のビュー５２０８に対して、対応する更新を必要とすることがある。ハブ５２０６は、リポジトリ５２１０内に格納された単数又は複数のモデル５２１２を用いて、基礎データ（例えば、エンタープライズ・データについてのメタデータ）と対話することができる。リポジトリ５２１０の設計クラス５２１６に対してハブを使用することは、広範な適用可能性を有する１つの有用なアーキテクチャであるが、運用クラス５２１４は、一般に、こうしたハブ５２０６を必要としないことを理解すべきである。より一般的には、ここに説明されるメタデータ管理システム５２０２は、如何なるハブ５２０６も有さずに設計することができる。このアーキテクチャは、例えば、種々のビューの設計モデルの間に共通性が殆どないか又は全くない場合に有用である。そのような場合、メタデータ管理システム５２０２における種々のビュー間の通信のために、中央コネクタのような非持続性の論理ハブを動的に生成するといった、他の技術を用いることができる。メタデータ管理システム５２０２において中央ハブ５２０６が用いられるかどうかにかかわらず、ここで説明されるシステムの他の原理を適用することができる。

モデル５２１２は、オブジェクト指向技術を用いて、Ｅｃｌｉｐｓｅ及びＥｃｌｉｐｓｅ Ｍｏｄｅｌｉｎｇ Ｆｒａｍｅｗｏｒｋ（「ＥＭＦ」）のようなプラットフォーム内に格納し、操作することができる。モデル５２１２は、メタデータ、及びデータ・ソース及／又はターゲット内の関連構造へのマッピング、並びにいずれかの他の有用でより抽象的なメタデータのモデリングを含むことができる。モデルのこれらの側面は、リポジトリ５２１０内に永続的に格納されるリポジトリ・オブジェクト内に含ませることができる。

リポジトリ５２１０は、運用クラス５２１４及び設計クラス５２１６を含む単数又は複数のモデル５２１２を格納することができる。モデルは、メタデータ、メタ・メタデータ、或いは何らかの他の有用なデータの記述的又は機能的特徴を含むことができる。一例として、モデル５２１２は、オンスのような重量の単位の値を含むことができる。システム・ユーザが、新しいデータ・ソースを実装することを望むか、又は重量をポンドで指定する既存のデータ・ソースを統合することを望む場合には、データに異なる観点（又は同じ観点）を提供できる単数又は複数のビュー５２０８を通して、これらの異なるソースに対応するメタデータをハブ５２０６内で一貫して処理し、外部ユーザ５２０４に提示できるように、この情報をモデル５２１２内に含ませることができる。より一般的には、モデル５２１２は、メタデータ管理システムによって考えられる統合及びいずれかの他の使用に有用な基礎データ及びメタデータに関する何らかの情報を含むことができる。モデル５２１０は、データに関する情報、並びに、企業にわたって又は企業間で、データ使用の一貫した処理及び拡張可能性を可能にするためのデータ変更方法に関する情報を有効に捕捉することができる。

モデル５２１２がリポジトリ５２１０内に作成されるとき、まとめて及び／又は均一に照会される間、モデル５２１２を、独立して管理することができる設計コンポーネント及び運用コンポーネントに自動的に区分化することができる。オブジェクト指向技術を用いて、モデル５２１２についての運用クラス５２１４を格納することができ、任意の適切なプロパティ、方法等をクラス間で継承することができる。運用クラス５２１４は、特に、外部プロセスのモデル運用側面を含むか、又はリアルタイム結果の持続的ストレージを提供することができる。運用クラス５２１４にタイム・スタンプを押すことができ、又は他の方法で固有の参照のためにラベル付けすることができる。Ｅｃｌｉｐｓｅプラットフォームは、ここで説明されるモデルを構築し、保持するための１つの有用なツールであるが、任意のオブジェクト指向ツール又は技術を同様に用い得ることも理解されるであろう。以下の説明において、「プロパティ」という用語は、一般に、オブジェクト指向記述、或いは、クラス、サブ・クラス、パッケージ、パッケージ構造、プロパティ、属性、方法、関係、継承等を含む、Ｕｎｉｖｅｒｓａｌ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（「ＵＭＬ」）クラス・モデルの要素のような他の類似した記述の種々の特徴を指すように用いられる。したがって、この用語がここで用いられるとき、運用クラス、パッケージ構造等は、運用プロパティとすることができる。

モデル５２１２から設計クラス５２１６をインスタンス化し、あらゆるプロパティ、方法等を継承することもできる。これらの設計クラス５２１６内の情報は、バージョン化情報を含むこともできるので、多数のオブジェクト・インスタンスを、連続的に又は分岐して、或いはそれらの組み合わせの形で保持することができる。エンタープライズ・コンピュータ・システムの要求及び設計目的に従って、バージョン化されたメタデータ・オブジェクトは、ユーザによって操作し、編集し、更新し、或いは他の方法で制御し、管理することができる。バージョン制御又は同様の技術を用いて、設計クラス５２１６のメタデータ・オブジェクトを共有するか、又は個々のユーザ又はチームにチェックアウトすることができる。一般に、異なる設計が試みられるとき又は基礎データの変更があるとき、異なるバージョンを用いることができる。リアルタイムの実行可能ファイルを作成する前に、種々の設計を調整し、分岐を併合させ得ることが理解されるであろう。ＥＭＦは、上述のようなリポジトリ５２１０内のクラスをモデル化するための有用なプラットフォームとすることができるが、Ｏｂｊｅｃｔ Ｍａｎａｇｅｍｅｎｔ Ｇｒｏｕｐ，Ｉｎｃ．社のＭｅｔａ−Ｏｂｊｅｃｔ Ｆａｃｉｌｉｔｙのような、何らかの類似したモデル化フレームワークを用い得ることも理解されるであろう。

エンタープライズ・コンピュータ・システムは、データ統合システム１０４を含むことができる。エンタープライズ・コンピュータ・システムは、単数又は複数のローカル・エリア・ネットワークを通して局所的に接続された、及び／又は、例えば、インターネット上の仮想プライベート・ネットワークを用いる単数又は複数の広域ネットワーク又は公衆ネットワークを通して遠隔接続された、コンピュータ、メインフレーム、携帯機器、データ・ソース及び他の装置の任意の組み合わせを含むことができる。エンタープライズ・コンピュータ・システム内の装置を相互接続して単一の企業とし、データ、リソース、通信及び情報技術管理を共有することができる。一般的に、エンタープライズ・コンピュータ・システム内のリソースは、会社、協会、又は行政体、或いは大学のような共通エンティティによって使用される。しかしながら、特定のビジネス・モデルにおいて、アプリケーション・サービス・プロバイダが遠隔の実行アプリケーションへのオンデマンド式アクセスを提供する場合など、多数の異なるエンティティによって、エンタープライズ・コンピュータ・システムのリソースを所有（又はリース）し、使用することができる。エンタープライズ・コンピュータ・システムはまた、それぞれの変換エンジン（ブリッジ・ベースのシステムにおいては、ブリッジとすることができる）を通して、ここではリポジトリ情報マネージャ（「ｒｅｐｏｓｉｔｏｒｙ ｉｎｆｏｒｍａｔｉｏｎ ｍａｎａｇｅｒ、ＲＩＭ」）と呼ばれる（下記では「ハブ」とも呼ばれる）共通のデータ構造にアクセスする複数のツールを含むこともできる。ＲＩＭは、上述されたデータ・ソース１０２のいずれかを含むことができる。一般に、ツールは、例えば、様々なタイプのデータベース管理システム及びＲＩＭ内に格納される共有データにアクセスできる他のアプリケーション・プログラムを含む。ツール、ＲＩＭ、及び変換エンジンは、単一のコンピュータ・システム上で処理し、保持することができ、或いは、それらは、例えば、データ・アクセス要求、変換されたデータ・アクセス要求及び異なるコンポーネント間の応答を転送するネットワークによって相互接続することができる多数のコンピュータ・システム上で処理し、保持することができる。

実行中、ツールは、データ・アクセス動作、すなわちＲＩＭからのデータの検索又はＲＩＭへのデータの格納を開始するデータ・アクセス要求を生成することができる。データは、下記に説明されるアトミック・データ・モデル及びフォーマットの形でＲＩＭに格納することができる。一般に、下記に説明されるように、ツールは、様々な特徴的データ・モデル及びフォーマットの形でＲＩＭに格納されたデータを閲覧し、各々の変換エンジンは、データ・アクセス要求の受信時に、必要に応じて、それぞれのツールの特徴的モデル、フォーマット、ＲＩＭのアトミック・モデル・フォーマットの間でデータを変換する。例えば、データ項目がＲＩＭから検索される検索タイプのアクセス操作の際に、変換エンジンは、アクセス要求に応答して検索されるデータ項目を協働して含むＲＩＭ内の単数又は複数のアトミック・データ項目を識別し、ＲＩＭが、アトミック・データ項目を変換エンジンの１つに提供することを可能にする。次に、変換エンジンは、ＲＩＭから受け取るアトミック・データ項目を集約して、ツールの特徴的モデル及びフォーマットによって要求されるような単数又は複数のデータ項目すなわちデータの「ビュー」にし、集約されたデータ項目を、アクセス要求を発行したツールに提供する。ＲＩＭ内のデータが更新されるデータ格納の際、変換エンジンは、ツールの１つについての、特徴的モデル及びフォーマットの形で格納されたデータを受け取ることができる。変換エンジンは、データを、ＲＩＭのためのアトミック・モデル及びフォーマットに変換し、変換されたデータをＲＩＭに提供し、格納することができる。データ格納アクセス要求がデータの更新を可能にする場合には、ＲＩＭは、変換エンジンから新しく与えられたデータを現在のデータと置き換えることができる。他方、データ格納アクセス要求が新しいデータを表す場合には、ＲＩＭは、そのデータを、変換エンジンによって提供されるようなアトミック・フォーマットの形で、ＲＩＭ内の現在のデータに付加することができる。

メタデータ・サービス５２１８を用いて、リポジトリ５２１０内のオブジェクト、クラス５２１４、５２１６及びモデル５２１２を作成し、編集し、削除し、又は他の方法で操作し、或いはモデル５２１２及び内部に含まれる任意の他のデータを照会し、これを調査することができる。ユーザ・インターフェース、コマンドライン・インターフェース、プログラミング・インターフェース、又は他のインターフェースを通して、サービス５２１８をユーザに提示することができる。サービス５２１８は、バージョン化、分岐、併合及びリポジトリ５２１０内でサポートされるいずれかの他の操作のような機能を提供することができる。これらの操作の一部が、下記により詳細に説明される。メタデータ・サービス５２１８はまた、例えば、インパクト分析（或るモデル・タイプのインスタンスの変更が、そのモデルにおける他のタイプのインスタンスにどのような影響を与えるか）、操作上の分析（イベント・メタデータによる実行可能なオブジェクトの履歴）、データ・系統（ウェアハウス内の又はエンタープライズ・コンピュータ・システムにわたるデータ移動の履歴）、バージョン・ドリルダウン（メタデータ・オブジェクトについてのバージョン履歴の調査）、オブジェクト区別付け（メタデータ・オブジェクト間の差異の調査）及びオブジェクト併合（指定された規則に従って同じクラスの２つのオブジェクトを組み合わせる）といったデータ分析サービスを含むこともできる。メタデータ・サービス５２１８はまた、例えば、リポジトリ５２１０内に及び／又はリポジトリ５２１０から移動されるとき、メタデータを変換するためのインポート及びエクスポート・サービスを含むこともできる。メタデータ・サービス５２１８は、例えば、Ｊ２ＥＥプラットフォームを用いて実現することができ、ＳＯＡのようなサービス指向アーキテクチャを通してユーザに提供することができる。同様に、リポジトリ５２１０内のトランザクションは、例えば、Ｊ２ＥＥアプリケーション・サーバ内のビーン・コンテナを用いて管理することができる。サービス５２１８はまた、ユーザ・インターフェース内の単数又は複数のツールとしてエンドユーザに提供できることも理解されるであろう。

上述した機能（例えば、バージョン化、分岐、ドリルダウン等）は、主として、メタデータ・オブジェクト内の詳細及びそれらの間の詳細、又は別個のメタデータ・インスタンスに向けられるが、メタモデル管理、すなわちメタ・メタデータ管理、又はメタデータ・モデルのモデルの管理に対処するために、メタデータ管理に対するこの一般的な手法を容易に抽象化できることに留意すべきである。

したがって、ここでは、メタモデル間のマッピングの定義を提供し、メタモデルのためのインターフェースを生成し、メタデータ・モデルの実装及び変換を容易にするメタモデリング・ツールが説明される。メタモデリング・ツールは、多数の関連機能へのアクセスを提供するグラフィカル・ユーザ・インターフェースを通して提供することができる。例えば、インターフェースは、メタモデル及びマッピング、並びにメタデータ・モデルの出力を定義し、検証し、試験し、分析するためのツールを提供することができる。インターフェースはまた、メタモデルの文書化、メタモデル・マッピング及びメタモデリング・ツールによって生成されたメタデータ・モデルの任意のインスタンスのためのツールを提供することができる。メタモデリング・ツールは、例えば、新しいバージョンのエンタープライズ・モデルを導入するために有効に用いることができる。ダイアグラミング、モデリング及びマッピングは、例えば、ＩＢＭ Ｒａｔｉｏｎａｌ ＸＤＥのようなサービスによってサポートすることができる。

メタモデリング・ツールは、例えば、サービス指向のサービスとして導入することができる。メタモデリング・ツールは、同期化、バージョン化、履歴の追跡及び上述のメタデータ・ツールと矛盾のない他の適切な能力を用いて、メタデータ・モデルのための中央管理マッピング仕様を提供することができる。したがって、マッピング・モデルは、ハブとビュー（又は他のモデル）との間のオブジェクト変換を表すことができるが、このメタモデリングの観点からのマッピング・モデルはさらに、又は代わりに、異なるメタデータ・モデル間のマッピングを表すことができ、このマッピング・モデルは、より新しいバージョンのメタデータ・モデルに更新するときのように、最終的にモデル自体の間の変換に用いることができる。メタモデリング・ツールは、例えば、モデル定義とは別個の又はこれに緩やかに結合された独立した仕様言語を提供することができ、開発の制御及び実装の柔軟性を可能にする。メタモデリング・ツールは、有利に、開発環境内にマッピング仕様の動的走査検索を提供することができ、様々な詳細のレベルで文書を自動生成するためのツールを提供することができる。統合スイートのメタモデリング・ツールを用いる場合には、試験メタデータを生成し、マッピングを動的に実行するように、開発を行うことができるので、直ちに効果を獲得し、これを進行中の開発に組み込むことができる。

モデルの運用属性と設計属性との間の概念的区別を保持するために、設計クラス５２１６及びプロパティの持続的格納のための共有リポジトリ（図示せず）、並びに、運用クラス５２１４及びプロパティの持続的格納のための運用リポジトリ（図示せず）といった２つ又はそれ以上のリポジトリに、リポジトリ５２１０を論理的及び／又は物理的に分離させることができる。したがって、モデル５２１２がリポジトリ５２１０に登録されるとき、運用クラス５２１４は運用リポジトリ内で持続され、設計クラス５２１６は共有リポジトリ内で持続されることが可能である。それらの関連を定めるために、クラス内の注釈を用いて、ある物理的又は論理的リポジトリ内で運用クラス及び設計クラスを区別することができる。他の技術が周知であり、他の技術を用いてモデルのクラスを運用側面と設計側面に分離させるか、或いは、別個の運用リポジトリ及び設計リポジトリを物理的又は論理的に提供できることが理解されるであろう。例えば、共通／運用の分離は、モデルのクラス構造内に暗黙的に設計してもよく、或いは、マニフェスト又は他のリスト若しくはプログラミング装置が、モデルを伴い、各々のクラス又はプロパティとその適切なリポジトリとの関連を列挙してもよい。どのように実装されようと、有利なことに、この構成により、モデル５２１２の設計及び運用要素のための異なる持続性の処理が可能になる。例えば、設計クラス５２１６は、プログラマのチームによって開発し、改訂することができ、よって、堅固なバージョン化能力及び調整が必要とされる。対照的に、運用クラス５２１４は、タイム・スタンプ又は他の固有識別子を用いるなど、異なるジョブについて固有の識別を必要とすることがある。したがって、ユーザによって照会し、変換し、又は他の方法で操作することができる単一のモデルを保持しながら、クラスのグループの各々についての適切なサービスを定めることができる。

図５は、単数又は複数のビュー又はモデルを介する（メタデータの）データベースとの通信を示す。サービス５３０２、ユーザ・インターフェース５３０３、又は任意の他のインターフェースは、データベース５３１２にクエリを実行依頼するためなどといった、上述のデータ・ソース１０２のいずれかとすることができるデータベース５３１２と通信することができる。上述のリポジトリ５２１０のようなリポジトリ５３０４によって提供される、ビュー５３０８及びハブ５３１０のようなメタデータ・モデルを通して、通信を行うことができる。これらのメタデータ・モデルは、フィールド、フィールド名、フィールド属性、データ・タイプ、データ階層、データ関係、時間情報、ソース情報のようなデータに関する情報、或いはデータの構造、位置、又は使用に関連する任意の他の情報、或いはこうしたデータに関するメタデータ（すなわち、メタ・メタデータ）を含むことができる。

サービス５３０２は、そのサービス５３０２に固有の、すなわちサービス５３０２によって定められる構造及びフォーマットを有するデータ・ビューを用いて、クエリを生成することができる。このクエリは、データベース５３１２内のデータ構造に関する如何なる情報も用いずに、サービス５３０２によって構成することができる。クエリを受信するビュー５３０８を含む複数の異なるビューに矛盾のないメタデータ表現のためのモデルを提供するハブ５３１０に、リポジトリ５３０４が要求中のサービス５３０２に提供するビュー５３０８をマッピングすることができる。次いで、ハブ５３１０を、データベース５３１２によって内部で用いられる構造にマッピングすることができる。ビュー５３０８、ハブ５３１０及びデータベース５３１２の間のマッピング情報を利用することによって、このクエリは、有利に、データベース５３１２に固有のデータ・モデル又は構文を用いるクエリに変換することができる。クエリはデータベース５３１２のいずれかの最適化又は調整から利益を得ることができるので、このことは著しい性能上の利点をもたらし得る。さらなる利点として、特定のクエリ５３０２についての可能な最適化を探索するために、独立してマッピング情報を照会することができる。

対照的に、実行ファイルを作成するとき、他の既存の技術はメタデータ・モデルを「平坦化する」ので、クエリは、データベース全体に対して実行する必要があり、結果は、サービス５３０２に提示されたビュー５３０８を用いて構文解析される。実際上、データベース５３１２からの関連する可能性が高いオブジェクトの全てをハブ５３１０においてインスタンス化し、クエリの実行のためにメモリ内で操作することができるビュー５３０８に変換しなければならない。このことは、メモリに著しい負荷を与え、データベース５３１２内に設計される何らかの性能上の利点を喪失させることになる。介在するモデルについてのマッピング情報を用いてクエリ自体をデータベース５３１２の固有の構文に変換することによって、クエリ結果だけをインスタンス化し、外部のサービス５３０２への提示のために変換することが必要になる。

同様に、ユーザ・インターフェース５３０３は、リポジトリ５３０４が提供する多数のモデルを通して、データベース５３１２と通信することができる。ユーザは、ユーザ・インターフェース５３０３におけるデータの提示に対応する構造及びフォーマットを有するフィールドを用いて、クエリをユーザ・インターフェース５３０３内に作成することができる。クエリは、ビュー５３０８によって受信され、いずれかの利用可能なマッピング情報を用いてハブ５３１０に関するクエリに変換され、次いで、いずれかの利用可能なマッピング情報を用いてデータベース５３１２に関するクエリに変換され、クエリ全体をデータベース５３１２に固有の構文で提示することが可能になる。

ユーザ・インターフェース５３０３及びサービス５３０２の両方について、単一のビュー５３０８が示されるが、各々が、データを閲覧するそれぞれの外部モデルを有することができ、リポジトリ５３０４によって、これらのモデルを保持し、提供できることが理解されるであろう。クエリは、データベース５３１２に対して実行され、ユーザ・インターフェース５３０３によって容易に使用可能な形式で、ハブ５３１０及びビュー５３０８を通して戻すことができる結果を生成することができる。より一般的には、データ統合システムのハブ・アンド・スポーク型アーキテクチャと整合性がある二層構造が図５に示されるが、種々のモデル内のメタデータ間の関係に関するマッピング情報が利用可能である場合には、互いに対して何らかの相対的な関係にある如何なる数のメタデータ・モデルも、データベースにアクセスするためのここで記載された技術から利益を得ることができる。

図６は、ビュー５３０８とハブ５３１０との間でメタデータ変換サービスを提供する変換エンジンを含むリポジトリ・サービス５３０４を示す。変換エンジンは、異なるモデルによって用いられる様々な固有のメタデータ構造とデータベース５３１２との間で、上述のようなクエリの変換と、モデル間のオブジェクト変換とを提供することができる。図６に全体的に示されるように、変換エンジン又は複数の変換エンジンをリポジトリ５３０４内のサービスとして提供し、そこで変換エンジンを登録し、及び／又は格納することができる。リポジトリ・サービス５３０４は、変換エンジンにアクセスし、クエリをハブ５３１０のためのフォーマットに変換することができる。図示されていないが、ハブ５３１０とデータベース５３１２との間で類似した変換を提供することができる。より一般的には、変換エンジンは、クエリを、外部モデルから多数のクエリ言語又はプログラミング言語の形で受信し、それぞれのモデル及びデータベース５３１２に利用可能なマッピング情報を使用し、該クエリをデータベース５３１２のために最適化された構造のクエリに変換することができる。したがって、クエリは、一般に、ビュー５３０８（又は他のモデル）に固有の用語で表現することができ、データベース５３１２に固有の用語でデータベース５３１２に提示することができる。

変換エンジンは、上述のようにクエリを変換する１つの概念的手法であるが、他の手法を考え、ここで説明されるシステムと共に有効に用い得ることが理解されるであろう。一般に、これらの手法は、システムによって用いられるメタデータ・モデル間のマッピング情報と、データベース５３１２への任意のマッピングとを別個に格納することから利益を得る。実行時にマッピング情報を変換エンジン又はいずれかの他のツール若しくはサービスにアクセス可能な形で保持することによって、メタデータ管理システムは、著しい性能を達成することができる。

図７は、複数の外部サービス５３０２のために変換エンジンを提供するリポジトリ・サービスを示す。サービス５３０２は、例えば、データ変換段階３０８、データ準備段階３０４、ＲＴＩサービス２７０４、ユーザ・インターフェース、或いはデータベース５３１２内のメタデータにおいてクエリを実行できるいずれかの他のサービス又は外部クライアントとすることができる。サービス５３０２は、クエリを、ビュー５３０８に固有の構文の形でビュー５３０８に与えることができる。変換エンジンは、クエリをハブ５３１０に固有の構文に変換することができ、次いで、これをデータベース５３１２に固有の構文を用いるクエリに変換することができる。変換エンジンにアクセスし、クエリ結果を再びサービス５３０２に固有の構文に変換することによって、クエリ結果をサービス５３０２に戻すことができる。このように、サービス５３０２は、それぞれの固有の構文を用いて、データベース５３１２と効率的に通信することができる。クエリを説明するためにここで用いられる「構文」という用語は、任意の構文、構造、フォーマット、プログラミング言語、及び／又は、サービス又はデータベースなどの外部から、又はメタデータ・モデル間のような内部で、クエリを表すために用いることができるインターフェースを指すことを理解すべきである。

図８−図１０は、持続的ストレージのために、メタデータ・モデルを関係データベース内のスキーマにどのようにマッピングできるかを示す。一般に、メタデータ・モデルは、オブジェクト指向関係管理ツールを用いて記述することができる。こうしたメタデータ・モデルが、共有リポジトリ及び運用リポジトリのようなリポジトリに登録されたとき、下記に説明される種々の技術を用いて、イン・メモリ・モデルを関係データベース内のスキーマにマッピングすることができる。この戦略は、Ａｐａｃｈｅ Ｏｂｊｅｃｔ／Ｒｅｌａｔｉｏｎａｌ Ｂｒｉｄｇｅ（「ＯＪＢ」）のようなツールを用いてＪａｖａツールを関係データベースに対して持続させる管理に特に適している。重要な利点として、この手法は、市販の関係データベースの高い性能を利用しながら、実質的な設計の柔軟性を可能にする。メタデータ・モデルを格納するのに有効に用いることができる多数の特定のマッピングが、以下の図８−図１０を参照して説明される。

図８は、メタデータ・モデルと関係データベースとの間の対応関係を示す。メタデータ・モデル５６０２は、フィールド、フィールド名、フィールド属性、データ・タイプ、データ階層、データ関係、時間情報、ソース情報を含むメタデータに関する情報、或いはデータの構造、位置、又は使用に関連する任意の他の情報といった、モデル５６０２の種々のプロパティを定める複数のオブジェクト指向クラス５６０４を含むことができる。データベース５６０８は、モデル５６０２を物理的に格納するのに用いられる関係スキーマを表す複数のテーブル５６１０を含むことができる。図の垂直方向の矢印によって全体的に示されるように、モデル５６０２とデータベース５６０８との間のマッピングは、モデル５６０２内のクラス５６０４の、データベース５６０８内のテーブル５６１０に対する１対１のマッピングとすることができる。このように、クラス５６０２のあらゆる側面が、テーブル５６０８の１つの中に対応する側面を有するので、モデル５６０２の構造が、文字通りデータベース５６０８内に再生される。このように、モデル５６０２とデータベース５６０８との間の概念的な線形変換を保持することができる。このような表現は、一般に、より高い性能をもたらすことができ、リアルタイムに直接コンパイルすることができ、又は容易にプリコンパイルすることができるが、モデル５６０２の変更には、データベース５６０８の全体の再構成及び対応するコンパイルされたバージョンへの変更が必要となることがある。

図９は、関係データベースへのメタデータ・モデルの代替的なマッピングを示す。メタデータ・モデル５７０２は、例えば、上述のメタデータ・モデル５６０２とすることができる。図の垂直方向の矢印によって全体的に示されるように、モデル５７０２とデータベース５７０４との間のマッピングは、モデル５７０２内のクラスのプロパティから、データベース５７０４内のテーブル５７０６のエントリへのものとすることができる。モデル５７０２によって用いられるオブジェクト指向構造に関係なく、別個の物理的テーブル内のバージョン・データ又はリアルタイムアーチファクトを構成すること等によって特定の使用を最適化するように、テーブル５７０６を構成することができる。この手法は、任意のモデルを有利に一般的なテーブル構造内で完全に特徴付けることを可能にする。モデル５７０２に対する如何なる変更も、１行又は２行の更新といった、データベース５７０４内の影響を受けた任意のエントリに対する更新を必要とするだけなので、この手法は、テーブル５７０６内に格納された記述に他の方法で影響を及ぼすことなく、拡張性を強化することができる。一般に、このことは、持続性のために用いられるデータベース５７０４の相対的に高い性能と、モデル５７０２と持続的な形態との間のマッピングの相対的な拡張性との間の設計トレードオフを表している。

図１０は、上記の図８及び図９に説明されたモデル・マッピングの組み合わせを示す。メタデータ・モデル５８０２は、例えば、上述のメタデータ・モデル５６０２とすることができる。図の垂直方向の矢印によって全体的に示されるように、モデル５８０２とデータベース５８０８との間のマッピングは、部分的にモデル５８０２内のクラス５８０４から、直接、図８を参照して上述されたような対応する構造を有するデータベース５８０８内のテーブル５８１０へのものとすることができる。モデル５８０２は、プロパティ５８０６をクラス５８０４に付加すること等によって、ユーザによって修正することができる。図９を参照して上述されたような一般的テーブル５８１４内に記述的エントリ５８１２を記録すること等によって、対応する変更をデータベース５８０８内に格納されたモデルに行うことができる。したがって、モデルの静的部分を、より実行可能な固定されたスキーマにマッピングすることができ、モデルの非静的部分すなわちユーザ構成可能部分を、拡張可能な記述的スキーマにマッピングすることができる。このように、モデル５８０２を格納するための関係スキーマは、モデルの相対的固定部分の性能をモデルのユーザ構成可能部分の拡張性と有利に組み合わせるハイブリッドとすることができる。

登録されたモデルの各々は、持続性のものにすることができる。ビューのような第１のモデルを登録するとき、ハブのような第２のモデル及び第１のモデルの第２のモデルへのマッピングと共に、モデルを登録プロセスに送ることができる。第１のモデルのプロパティを第２のモデルにマッピングできる場合には、マッピング自体を超えた付加的な持続機構は必要とされない。しかしながら、第１のモデルのプロパティを第２のモデルにマッピングできない場合には、マッピングされないプロパティを持続させるための機構を提供することができる。如何なる特定のモデルも、別のモデルへのマッピング、部分的なマッピング、又は完全なマッピングを有することができないことが理解されるであろう。プロパティが持続性を必要とする例、すなわちプロパティが既存のモデルにマッピングされない例においては、図８−図１０を参照して上述された拡張可能なモデルのための技術のいずれかを用いて、モデルの持続性のためのストレージ機構を提供することができる。特定的には、最も一般的なテーブル形態は、多数の設計サイクルを通して望ましい持続機構を提供できるが、モデルのマッピングされない部分のクラス構造を複製することによって、ランタイム・モデルを有利に導入することができる。

上述の一般的な構造は、拡張可能なモデルのための反射型ストレージ機構を提供できることがさらに理解されるであろう。このストレージ機構はその環境を「理解する」ことができ、モデル記述を見て、任意のオブジェクトの関連するクラス、属性、マッピング等を決定することができる。こうした反射型能力を用いて、上述の一般的なテーブル・フォーマットのようなスキーマは、拡張を適合させる方法でモデルのプロパティを持続させることができる高レベルの設計環境を提供することができる。

図１１は、複数の内部サービスを外部のメタデータに露出するアーキテクチャを示す。場合によっては、データが別個の企業又はエンタープライズ・アプリケーション間で共有される場合など、メタデータが、ここで説明されるメタデータ管理システムによって管理されるメタデータ・モデルの外部に常駐することがある。こうした外部のメタデータにアクセスするためのアーキテクチャは、第１のビュー５９０４を有する外部メタデータ５９０２、ハブ５９０６、及び複数の内部サービス５９１０への第２のビュー５９０８を含むことができる。

メタデータ管理システムは、外部メタデータ５９０２の第１のビュー５９０４を提供することができ、次いで、これをハブ５９０６に接続して、外部メタデータ５９０２についての共通の内部モデルを提供することができる。メタデータのそれぞれのビュー、第２のビュー５９０８を通して、内部サービス５９１０をハブ５９０６に同様にマッピングすることができる。これらの相互接続されたモデル５９０４、５９０６、５９０８を通して、内部サービス５９１０は、内部サービス５９１０に固有の形態で、外部メタデータ５９０２にアクセスすることができる。次に、内部サービス５９１０をサービス指向アーキテクチャ内に導入して、メタデータ管理システム内のサービスとして、又はより一般的には企業全体にわたるサービスとして、外部メタデータ５９０２へのアクセスを提供することができる。

図１２は、ビュー及びハブといったメタデータ・モデル間の変換のために解釈されたマッピングを用いる、メタデータのマッピング・モデル駆動型変換を示す。メタデータ管理システム６０００は、ハブ６００２、単数又は複数の変換エンジン６００４及び単数又は複数のビュー６００６、６００８を含むことができる。変換エンジン６００４は、ハブ６００２とビュー６００６、６００８の間の単数又は複数のマッピングを特徴付けるマッピング・モデル６０１０を含むことができる。要求を受信したとき、こうしたモデルを解釈し、マッピング・モデル６０１０を用いて、オブジェクトのインスタンスを要求者にどのように表現すべきかを決定することができる。マッピング・モデル６０１０は、より大きな設計の柔軟性をもたらすことができるモデル（例えば、Ｊａｖａクラス又はＥＭＦオブジェクト又はインスタンスのようなデータ構造）として、又は変換エンジン６００４により大きい実行効率を提供できるコンパイルされたコードとして、或いは解釈されたコードとしてなど、多数の形態で表現することができる。より一般的には、任意の数の異なる変換エンジン６００４において、単一のモデル対モデル・マッピング又はマッピング・モデル６０１０をインスタンス化することができる。同時に、抽象的なモデルからコンパイルされたコードまでの範囲に及ぶ任意の数の形態で、異なる変換エンジン６００４をインスタンス化することができる。マッピング・モデル６０１０は、共通のアクセス及び整合性を提供するように、変換エンジン６００４のための変換レジストリ（図示せず）内に登録することができる。

既存のシステムにおいて、ビュー対ハブのマッピングは、一般に、導入されると変わらない静的マッピングとして生成される。ビュー６００６、６００８及びビューからハブへのマッピング６０１０をモデルとして処理することによって、メタデータのインスタンスがビューからハブに移動されたとき、又はハブからビューに移動されたとき、マッピングを直接解釈することができる。ビューは、例えば、Ｊａｖａクラス、Ｊａｖａコード、又は基礎モデルの何らかの解釈として内部で表すことができる。同様に、Ｊａｖａコード、Ｊｙｔｈｏｎ（Ｊａｖａベースのスクリプティング）等のような種々の形態でマッピングを解釈することができる。要求が受信されると、ビュー・モデル、マッピング・モデル及びハブ・モデルによって、要求をパラメータ化することができる。モデル駆動型変換エンジンは、モデルの１つにおいて表現されたオブジェクトを受け取り、別のモデルの１つにおいて表現されたオブジェクトを戻すことができる。

例えば、ハブは、解釈されたＪａｖａコードを用いてアクセスされるオブジェクト指向構成とすることができる。同様に、Ｊａｖａ又は何らかの他のプログラミング言語を用いて、ビュー６００６、６００８を解釈することができる。変換エンジン６００４は、ハブ６００２とビュー６００６、６００８との間のメタデータ・モデル・マッピングを用いて、要求及びオブジェクト・インスタンスを、ハブとビュー６００６、６００８との間で移動させることができる。変換エンジン６００４は、メタデータ・モデル又はオブジェクトの単数又は複数の変更に応答して、手動操作で又は自動的に（又は手動で）ユーザによって動的に修正することができる。

解釈されようと、コンパイルされようと、又は他の方法で実行されようと、モデルを解釈／実行するソフトウェア又はソフトウェア・エンジンは、同期式であっても、又は非同期式であってもよいことを理解すべきである。非同期式環境においては、モデルへのアクセスは、メッセージング・サービス又は他の非同期式技術によるものである。同期式環境においては、アプリケーション・プログラミング・インターフェース又はエンジンへの他の同期式インターフェースを通して、エンジンへの呼び出しを直接行うことができる。

図１３は、メタデータ環境との対話を示す。モデル６１０２は、バージョン化されていないクラス６１０４（運用リポジトリ内に格納される）及びバージョン化されたクラス６１０６（共有リポジトリ内に格納される）として表すことができる。ユーザ６１１０がモデルと対話するために、ユーザ・メタデータ環境６１０８を提供することができる。以下の説明に用いられる「環境」は、基礎モデル・データと、１又は複数のユーザ６１１０が、揮発性メモリ又は不揮発性メモリ、或いはその両方であっても、モデル及びメタデータの格納されたインスタンスを含み、上記のいずれかの任意のバージョンと共に運用プロパティ及び設計プロパティを含む、モデル及びモデル・データを閲覧し、照会し、操作するために、いずれかの適切なグラフィカル・ユーザ・インターフェース、コマンドライン・インターフェース、或いは他のプログラマチック・インターフェースを通して、閲覧し、操作することができる、モデル又はメタデータについての他のコンテキスト情報とを指すように意図されている。一般的な「環境」（又は「ユーザ環境」）という用語は、総称的に、１又は複数のユーザがメタデータと対話することができる任意のモデル・コンテキストを指すように意図されるが、幾つかの環境が、以下に説明されるように具体的に考えられる。以下の例は、ここで説明されるシステムと共に有効に用いることができるユーザ環境の数及び種類に限定されるものでない。

モデル６１０２は、例えば、上述のビュー及びハブのいずれか、或いはいずれかの他のメタデータ・モデルとすることができる。モデルは、運用クラス及び属性、並びに設計クラス及び属性を含むことができる。上記のように、モデル６１０２は、種々のモデル・クラスの目的に従って、２つの異なるリポジトリ内に格納することができる。したがって、運用リポジトリは、モデルを用いて実行されるジョブについてのメタデータ結果を格納するように構成することができ、共有リポジトリは、コラボレーション及び反復的設計プロセスをサポートするように構成することができる。運用リポジトリ及び共有リポジトリは、物理的及び／又は論理的に分離させることができること、及び、各々の一部は内部に格納されるモデル・クラスのサブセットによって定められ、一部は各々にアクセスするために用いられるサービス又は方法によって定められることを理解すべきである。

作業空間又はチーム空間といった多数の異なるモードにおいて、ユーザ６１１０は、メタデータ環境６１０８と対話することができる。サンドボックスとも呼ばれる作業空間は、例えば、メタデータの設計プロパティの変更が、新しいモデルとして保存されるか又は既存のモデルに上書きされるかのいずれかである、バージョン化されていない環境において、ライブ編集をモデルに提供することができる。作業空間は、ユーザのコンピュータ上に局所的に、又はユーザがメタデータと対話できるサーバ上に遠隔的に存在することができる。一般に、モデルを作業空間内に置くことにより、他の潜在的なユーザのためのモデルがロックされることになる。しかしながら、作業空間は、共有使用をもたらすことができるので、１より多いユーザが変更を編集し、作業空間に保存できるようになる。チーム空間は、バージョン化を提供することができるので、多数のバージョンのチェックアウト、チェックイン、分岐等が可能になる。

より一般的には、チーム空間は、上述の全てのメタデータ・バージョン化能力についてのメタデータ環境を提供することができる。例えば、バージョン化されたメタデータ環境は、個々のユーザによって作成又は編集されたメタデータのバージョン化をサポートすることができる。したがって、バージョン化されたメタデータ環境のユーザは、モデルをチェックアウトし、そのモデルを新しいバージョンとして再びチェックインすることができる。このように、作業空間は、協働的な編集を可能にするが、チーム空間は、バージョン制御を有するメタデータの協働的な編集及び／又は連続的な編集を可能にすることができる。

ユーザ・インターフェースはまた、上述の運用プロパティ及び／又は運用リポジトリと関連付けられたメタデータ環境６１０８であるイベント空間へのアクセスを提供することもできる。

ユーザ環境６１０８はまた、企業全体にわたって多数のリポジトリのための集中型グローバル環境を提供する連合ユーザ環境とすることもでき、又はこれを含むことができる。連合ユーザ環境は、異なるリポジトリの共通のビューを提供することができ、又は各々のリポジトリを別個に表すこともできる。

ユーザ６１１０は、例えば、グラフィカル・インターフェース又はコマンドライン・インターフェース、或いは上述のデータ発見段階３０２、データ準備段階３０４、又はデータ変換段階３０８のようなリポジトリ内のメタデータ・モデルにアクセスするプログラム又はサービスを通してメタデータ環境６１０８と対話する人間のユーザとすることができる。

図１４は、複数のバージョンのメタデータ６２０４を格納する共有リポジトリ６２０２を示す。メタデータ６２０４は、例えば、上述のビュー及びハブについてのメタデータとすることができる。メタデータ・データベース６２０６は、上述のデータ・ソース１０２のいずれかにすることができる。メタデータ６２０４の各バージョンは、メタデータ・データベース６２０６内に格納された、異なるものではあるが関連したメタデータのバージョンを提供することができる。メタデータ６２０４のバージョンは、例えば、データ統合プロジェクトに従事している開発者チームによって作成し、特にデータベース６２０６内に格納されたインスタンスを用いて比較することができる。

図１５は、全てが一般的に上述されたような、メタデータ・データベース６３０６内に格納されたメタデータを特徴付ける複数のオブジェクト・バージョン６３０４を含む共有リポジトリ６３０２を示す。クライアント６３０８は、直接、又は上述のユーザ環境の１つにおいて、オブジェクト・バージョン６３０４と対話することができ、一般的に上述された設計操作のいずれかを実行することができる。これは、例えば、メタデータ・モデルの動的比較、ドリルダウン、編集、試験、又は他のいずれかの適切な機能を含むことができる。クライアントはまた、共有リポジトリ６３０２及びオブジェクト・バージョン６３０４を用いて、メタデータ・データベース６３０６内の基礎メタデータを調査することもできる。

図１６は、バージョン化されたメタデータ・オブジェクトの調整を示す。共有リポジトリ６４０２及びバージョン化されたオブジェクト６４０４は、上述の共有リポジトリ６３０２及びバージョン化されたオブジェクト６３０４とすることができる。バージョンの調整は、設計サイクルの様々な時点で所望することができ、一般に、実行可能モデルのリリースのために必要とされる。単一のインスタンス６４０８に対するバージョン化されたオブジェクト６４０４の調整は、調整プロセス６４０６を通して制御することができる。多数の技術が周知であり、それらを自動調整、半自動調整及び手動調整のために用いることもできる。一般に、ここで説明されるシステムと共に何らかのこうした技術を用いることができる。調整プロセス６４０６は、有利に、完全なバージョン履歴と、調整された単一のインスタンス６４０８についての調整系統とを保持し、調整プロセス６４０４への修正を可能にし、いずれかの以前の調整されていない状態に戻し、又はソース・メタデータ及び調整系統を調査することができる。併合などにおける調整の際にメタデータ内の直接競合が解決される場合には、以前の属性値を呼び戻し、分岐及び様々なバージョンの代替的な調整と共に用いることができる。

図１７は、調整区域にわたる段階的調整を示す。複雑な調整プロセスを管理し、メタデータ・インスタンスのための正確な調整系統を維持するために、調整区域を設けることができる。図１７の調整区域を説明する前に、メタデータ・インスタンスの幾つかの有用なプロパティに言及する。

エンタープライズ内の各メタデータ・インスタンスは、インスタンスと調整区域との関連を定義する関連付けられた調整区域プロパティを有することができる。調整区域は、例えば、人的資源、経理、財務、在庫、製造、給与、エンジニアリング等のようなデータの制度上の分離を反映するように、調整プロセスの設計者によって選択することができる。調整区域は、国、地方、州、町、建物、設備等のような、データ及び企業に適した任意の粒度の地理的なものとすることができる。調整区域は、例えば、新しいシステムからレガシー・システムを分離する、メインフレームから従業員のデスクトップを分離する、従業員から顧問を分離するといったように、履歴上又は構造上のものにすることができる。調整区域は、消費者製品、相手先商標製品製造、製品、店舗業務、電子商取引業務等、又はより一般的には製造及び小売のような部門又は他のサブグループへのビジネスの組織を反映させることができる。同様に、調整区域は、会社が獲得した又は会社から分離独立した新しいビジネス単位に対して、調整区域を設けることができる。

各々の調整区域について、優先順位、例外、組み合わせ等に関する任意の数の調整規則を定めることができる。調整のための技術は公知であり、調整規則に従って、調整区域内のメタデータ・インスタンスを調整するために、こうした技術の全てを有効に用いることができる。調整区域は、一致なし（複製が削除される）、ビューが一致する（バージョンは、ビュー・レベルに保持される）、及び／又はビュー以外の一致がある（バージョンは、ハブ・レベルに保持される）のように、インスタンスを参照するモデルにおいて、調整結果がどのように伝搬されるかを定める一致タイプをさらに定めることができる。

オブジェクトの各インスタンスはまた、調整区域内のオブジェクトを一意的に識別する識別子を有することもできる。項目の意味文脈を捕捉するためなどに、様々な文脈又は階層に関して各項目を記述することができる。項目は、オブジェクト、クラス、属性、データ項目、データ・モデル、メタデータ・モデル、モデル、定義、識別、構造、言語、マッピング、関係、インスタンス、又は別の意味識別子を含む他の項目又は概念とすることができる。意味識別子は、項目の属性、項目の物理的位置、階層等における項目と単数又は複数の他の項目との関係等に基づいて、項目を識別することができる。場合によっては、関係は、何らかの特定関係の不存在として定義することができる。関係は、意味に基づくことができる。関係は、関係階層における項目の位置と関係させることができる。例えば、項目は、該項目が関係する他の項目との関係に基づいて識別することができ、別の項目に直接関係していても、別の項目に間接的に関係していても、及び／又は単数又は複数の他の項目を通して別の項目に間接的に関係していてもよい。静的識別子に加えて動的識別子を可能にするために、関係を連結させるか又は再帰的に定義することができる。例えば、２つの項目間の関係が変更する場合には、２つの項目の一方を組み込む別の項目についての意味識別子も、２つの項目間の変更された関係を組み込む。

より具体的な例として、項目Ｊｉｍは、米国某州、某町、某通り１１１に居住し、電話番号５５５−５５５−５５５５及び社会保障番号０１２−３４−５６７８を有するＪｉｍとして特定することかできる。代替的に、Ｊｉｍは、他者との関係の観点から特定することができる。Ｊｉｍは、Ｂｅｔｔｙの息子、ＬａｒｒｙとＪｅｆｆの兄弟、Ｊｅｓｓｉｃａの父親及びＦｒａｎｋの甥として特定することができる。

意味識別子は、１つの項目についての固有識別子とすることができる。上記の例においては、Ｂｅｔｔｙの息子、ＬａｒｒｙとＪｅｆｆの兄弟、Ｊｅｓｓｉｃａの父親及びＦｒａｎｋの甥であるＪｉｍが世界に一人しかいない場合には、この意味識別子は、Ｊｉｍについての固有識別子となる。項目への固有の意味識別子が、その項目と他の項目との関係の全ての関係より少ない数である場合を考えることも可能である。Ｂｅｔｔｙの息子、Ｌａｒｒｙの兄弟、Ｊｅｓｓｉｃａの父親であるＪｉｍが世界に一人しかいない場合には、固有の意味識別子を作成するのに、これらの関係の存在だけで十分である。ＪｉｍとＪｅｆｆ及びＦｒａｎｋとの関係を考慮する必要はない。一意性を保証する最小の数の関係に基づいた意味識別子を作成することが有利である。例えば、意味識別子がデータベース１１２内に格納されるか、又はデータ統合システム１０４によって処理される場合、より複雑でない意味識別子は、必要とする空間が少なく、より高速な処理が可能になる。

項目についての固有の意味識別子を作成するのに必要とされる関係の数は、コンテキストに基づいて異なり得る。例えば、第１の項目すなわち項目１は、該項目１と２つの付加的な項目すなわち項目３及び項目４との関係によって、コンテキストすなわちコンテキストＡ内の第２の項目すなわち項目２と区別することができる。すなわち、コンテキストＡにおいては、項目１について固有の意味識別子は、項目３及び４に直接関連し、項目３及び４を通して任意の数の他の項目と間接的に関連するもとすることができる。異なるコンテキストすなわちコンテキストＢにおいては、項目１は、該項目１と項目３（恐らく、項目４ではないが）との関係によって、並びに、該項目１と別の項目すなわち項目５との関係及び項目６との関係の不存在によって、一意的に特定することができる。したがって、ここで説明されるデータ統合方法及びシステムの実施形態においては、データ統合ジョブ又はデータ統合プラッフォームに関連した項目のような項目についての意味識別子に、その項目についてのコンテキスト依存識別子を与えることができる。実施形態において、こうしたコンテキスト依存識別子は、データ・リポジトリ等の中に、アトミック・フォーマットの形で格納することができる。

コンテキストＡ及びコンテキストＢは、２つの異なるインポート、マッピング、実行バージョン、モデル、メタブローカ・モデル、インスタンス、ツール、ビュー、オブジェクト、クラス、項目、関係、属性、又は上記のいずれかの任意の組み合わせとすることができる。調整又は比較機器は、異なるインポート、実行バージョン、モデル、メタブローカ・モデル、インスタンス、ツール、及び／又は項目における項目の識別の値及び／又は構文を比較し、その比較に基づいてどの動作を取るべきか又は動作を取るのを控えるべきかについての判断を決定する又は助けることができる。例えば、調整エンジンは、インポート・インスタンスＡによって用いられるモデルを、メタブローカＢによって用いられるモデルと比較することができる。この比較に基づいて、メタブローカＢは、変換又は修正なしで、インポート・インスタンスＡのデータ及びメタデータにアクセスでき、比較機器が、メタブローカＢの続行を命令できることを決定することができる。別の例においては、ツールＡをツールＢと比較することができ、各々のツールが他のツールのオブジェクトにアクセスすることができる、ツール間のオブジェクト併合の実行を決定することができる。実施形態においては、調整機器は、変換機器をトリガし、それぞれのツールの各々における特定の項目の識別の処理についての異なる構文に基づいた変換、又は比較によって判断されるようなツール間の他の差異に基づいた変換などの変換を必要とする任意のオブジェクトを変換するために、ブリッジ、メタブローカ、ハブ等の確立といった、ツール間のオブジェクト併合を助けることができる。

実施形態においては、文字列構造又はフォーマットで格納し、維持し、記録し、処理し、及び／又は解釈することができる構文の形で、意味識別子を格納し、維持し、記録し、処理し、及び／又は解釈することができる。例えば、構文は、列名：：テーブル名：：データベース名とすることができる。この構文は、例えば、データベース内のテーブルの列を特定する意味識別子と関連付けることができる。この構文内に構成された文字列は、年齢：：従業員：：従業員データベースとすることができる。この文字列は、例えば、特定の従業員データベース内の従業員の年齢を特定する意味識別子と関連付けることができる。コンテキストＡ内の項目１（上記の例）についての意味識別子に対応する文字列は、項目３との直接的な関係：：項目４との直接的な関係とすることができる。意味識別子及び対応する文字列はまた、上記のコンテキストＢにおいて行われるように、項目１と項目５との間の直接的な関係の欠如を組み込むこともできる。

構文文字列を構文解析することができる。構文及び／又は文字列を切り捨て、修正することができ、及び／又は、構文及び／又は文字列の要素を再配列することができる。変換エンジンは、切り捨て、修正、及び／又は再配列を行うことができる。意味識別子の一意性のために、構文及び／又は文字列内に含まれる関係の全てを必要としないとき、構文及び／又は文字列を切り捨てることは有用である。構文文字列の所定のコンテキストにおいて、全ての項目が項目３に直接関連していた、すなわち、例えば、項目３が全ての項目を格納するデータベースであったと想定する。項目３を含む関係を省略する文字列を作成するといったように、構文文字列を切り捨て、依然として固有の意味識別子を残すことができる。構文及び／又は文字列を切り捨てることにより、ストレージ要件を減らし、処理の効率を増大させることができる。例えば、データ統合プロセスのための処理時間を減少させるために、構文及び／又は文字列における関係の順序を変えることも有用である。あまり共通性がない関係が先に処理された場合、システムは、項目を特定するために、項目との関連がより少ない関係にアクセスし、処理することが必要になる可能性が高い。例えば、項目３に関連する項目が殆どなく、項目４に関連するものはさらに少なく、多くの項目が項目２に関連する場合には、コンテキストによって、１つの構文文字列は、別の構文文字列より短い時間で項目９を特定することができる。あるコンテキストにおいて１つの項目を一意的に特定するために、構文文字列の特定の要素だけを必要とするが、別の文脈においては、構文文字列の全ての要素を必要とするということもある。

調整エンジンは、メタデータ・インスタンスの特定、並びに、調整のための規則を定める調整区域及び任意の一致タイプの仕様を用いて、メタデータのインスタンスにおける調整を実行することができる。調整操作は、調整区域内のインスタンスを一意的に特定するための意味識別子を用いることができ、或いは別の調整区域内の調整されたインスタンスの意味識別子のフォーマット、言語、及び／又はデータ・モデルを変換するか、又は他の方法で修正することができる。調整操作は、単数又は複数のデータ・ツール、言語、フォーマット及び／又はデータ・モデルとの間の調整又はマッピング、少なくとも１つの他のデータ・ツール、言語、フォーマット、及び／又はデータ・モデルとの間の調整又はマッピングを含むことができる。例えば、調整操作は、ＩＢＭからのＷｅｂＳｐｈｅｒｅ ＤａｔａＳｔａｇｅ７、ＩＢＭからのＷｅｂＳｐｈｅｒｅ ＱｕａｌｉｔｙＳｔａｇｅ、Ｂｕｓｉｎｅｓｓ Ｏｂｊｅｃｔツール、ＩＢＭ−ＤＢ２ Ｃｕｂｅ Ｖｉｅｗｓ、ＵＭＬ１．１、ＵＭＬ１．３、ＥＲＳｔｕｄｉｏ、ＩＢＭのＷｅｂＳｐｈｅｒｅ ＰｒｏｆｉｌｅＳｔａｇｅ、ＰｏｗｅｒＤｅｓｉｇｎｅｒ（Ｐａｃｋａｇｅｓ及びＥｘｔｅｎｄｅｄ Ａｔｔｒｉｂｕｔｅｓのためのサポートが付加された）、及び／又はＭｉｃｒｏＳｔｒａｔｅｇｙツールのような、周知のデータ統合ツールへの、周知のデータ統合ツールからの、又はそれらの間のマッピングを含むことができる。調整エンジン及び／又は調整操作は、随意的に、メタブローカにおいて実現することができる。調整操作は、バッチで、リアルタイムに、又は連続的ベースで行い、実行し、及び／又は実施することができる。調整操作は、例えば、サービス指向アーキテクチャの一部としてといったサービスとして提供すること、又は利用可能にすることができる。

意味識別子、データベース１１２、単数又は複数の意味識別子を含むデータベース１１２、情報システム、単数又は複数の意味識別子若しくは他の項目を含む情報システムについての調整操作が行われると、この調整操作を、いずれかの他の意味識別子、データベース１１２、単数又は複数の意味識別子を含むデータベース１１２、情報システム、単数又は複数の意味識別子を含む情報システム、或いは少なくとも１つの調整操作を共有する他の項目との間で調整し、これにマッピングし、これに結合し、これと共に使用し、又はこれと関連付けることが可能になる。変換操作のために、ハブのようなアトミック・データ・リポジトリを用いるような実施形態においては、調整操作のマッピングは、とりわけ、元の意味コンテキストと変換された意味コンテキストとの間で、前後方向の操作の実行による調整を追跡することができる。コンテキストによって、構文及び／又は文字列を変えるか又は切り捨て、より効率的な格納又はより高速な処理を可能することによって、或いは、意味コンテキストが異なる固有識別子を形成するのに用いられる関係を変えることなどによって、データ項目の適切な識別子は異なり得る。したがって、動的な識別子は、再トレース可能な調整の利点を、データ項目が用いられる種々のコンテキストにおける高速処理、効率的なデータ処理及び効率的な操作の利点と結び付けることができる。

図１７は、調整区域を示す。一般に、メタデータ・オブジェクト又は項目は、それぞれのデータ・コンステレーション内で一意的に識別されるが、調整プロセスはまた、異なるソースからのオブジェクトの異なるインスタンスを組み合わせることができる調整プロセスを通して識別を管理しなければならない。多数のソースからのメタデータについて、多数の調整区域６４５０−６４５８を定めることができる。例えば、図１７の左側にある調整区域６４５０−６４５４は、会社内の部門又は別個のデータベースのような、企業の様々な要素からのソース・データとすることができる。上述の技術を用いて、これらのソース調整区域６４５０−６４５４内の各々における各メタデータ・インスタンスについて、調整区域、規則、一致タイプ及び識別子を定めることができる。調整規則に従って、調整エンジンは、２つの調整区域（例えば、区域６４５０及び区域６４５２）からのデータを調整して、各項目が一意的に識別される新しい調整区域６４５６にし、ソース調整区域からのメタデータ・インスタンスの調整されたバージョンを表すことができる。この新しい調整区域６４５６は、次に、単数又は複数の他の調整区域（例えば、区域６４５４）と調整され、エンタープライズ内のメタデータ・インスタンスの完全な調整を表す別の調整区域６４５８を提供することができる。同時に、いずれの調整区域も、これを特定の調整区域に導入する前に単数又は複数のソースからのメタデータをより細かく調整するために、それ自体とデータ・ソースとの間に単数又は複数の調整区域を有することができる。したがって、図１７のパターンは、メタデータ・インスタンスの調整のための何らかの恣意的なパターン又はフローを達成するための何らかの方法で、繰り返し、変更し、及び／又は拡張することができる。

具体例として、第１の調整区域６４５０は、全ての新しい雇用に対する初任給を含むことができる、人的資源に関するメタデータを表すことができる。第２の調整区域６４５２は、全ての従業員に対する週給の情報を含む給与データを表すことができる。会社の経理部にいる人物のようなユーザによって、これらの調整区域を調整して、新しい調整区域６４５６とし、給与情報を追跡することができる。正確を期し、整合性を保つために、この調整区域６４５６内のメタデータを分析することができ、満足な調整が得られるまでこれを修正することができる。別の調整区域６４５４は、企業の財務データベースについてのメタデータを表すことができる。財務データベースは、企業の給与コストについてのメタデータを含む、企業に関する完全な財務データを含むことができる。このデータは、高品質を有するものと特徴付けすることができ、これを監査し、企業の他の領域において他の方法で用いることもできる。１つのデータ・ソースは、品質保証基準が低いことが知られている外部の請負業者によって準備されたコンパイルを表し、別のデータ・ソースは、社内の良く訓練され、監督された従業員からのデータ入力を表す場合などの、データ品質についてのあらゆる情報を考慮して調整規則を設計することができる。企業内の従業員給与の完全に統合されたビューを表すメタデータを含む別の調整区域６４５８において、この調整区域６４５４からのメタデータを別の調整区域６４５４からの給与メタデータと調整することができる。この例をさらに拡張するために、図１７の調整区域６４５０−６４５８の全てを、会社分割に特有のものとすることができ、これらを、他の企業分割又は企業買収からの統合された調整区域とさらに統合すこともできる。同様に、上述の段階的調整を用いて、異なる企業の部門、地理上の位置、子会社、機能上のビジネス単位等からのデータを漸進的に統合させることができる。

上述の段階的調整プロセスから多くの重要な利点がもたらされることが理解されるであろう。１つの利点は、調整系統の保持である。複雑なデータ統合環境においては、階層ファイル、フラット・ファイル、連合データ・ソース等を含む多数のメタデータ・ソースが存在する可能性が高い。このような環境においては、統合及び調整のプロセスを追跡すること、及び、途中で調整ステップを逆にする能力を維持することの両方が重要である。上述の技術によって提供される調整系統は、調整系統の完全な監査、検査及び修正を可能にし、完全に調整されたモデル内の各メタデータ・インスタンスについて、元のデータ・ソースへの明確な経路を提供する。

別の利点として、段階的調整は、統合されたモデル内のデータ・ソースへの可視性をもたらす。例えば、図１７の完全に統合された調整区域６４５８は、ビジネス分析ツールのためのメタデータ・モデルとして、分析者又は管理者が用いることができる。分析ツールに基づいたビジネス決定を行う前に、データ・ソース及び品質を調査することは有用であり、又はより不可欠である。別の例として、ビジネス決定に、データの特定のビューを必要とすることがある。住所の通り名は、対面式マーケティング・キャンペーンにとって重要であり、郵便番号は、メーリング・キャンペーンにとって重要である。異なるデータ・ソースは、異なる詳細のレベル及び異なる正確さのレベルで、関連情報を伝えることができる。マーケティング・キャンペーンを設計するための分析ツールで所望のメタデータの最良のビューを表現するように、調整プロセスを検査し、必要に応じて修正することができる。この例を続けると、あるデータ・ソースは、非常に詳細かつ正確に住所を定めることができるが、例えば、年に二度、又は情報の受信時に断続的にといったように、まれにしか更新されないことがある。別のデータ・ソースは、所在地住所含むが郵便番号は含まない極めて最新の情報（例えば、電話リストのような）を含むことができる。統合されたエンタープライズ・データ・モデルについての調整系統を調査することによって、管理者は、郵便番号のインスタンスのデータだけがない可能性があることを認識し、所在地住所から最新の郵便番号を合成するように調整プロセス（又は随意的に、統合されたメタデータ・モデル自体）を再設計することができる。

更に別の利点として、段階的調整は、統合されたビューからデータ・ソースに向けて調整及び修正を上流に伝搬する能力をもたらす。このことは、最終的に、エンタープライズ内の元のデータ・ソースからのメタデータ及びデータのデータ構造と品質を改善する。

上記の一般的な手法は、極めて異種のデータ環境において特定のユーティリティを有することができる。例えば、複雑な会社環境において、製造、経理、人的資源及びエンジニアリングのような多数の個々のグループは、各々そのグループに特有の多岐にわたるデータベースを用いて、別個のデータ・サイロを維持することができる。この環境においては、データ統合を有効に用いて、改善されたビジネス・インテリジェンスを可能にする方法で別個のデータベースを統合することができる。データベースを統合してグループについての包括的なメタデータ・モデルを形成すること等によって、統合をグループ内での垂直方向のものにしてもよく、或いは、各々のグループからの給与を統合して包括的な給与メタデータ・モデルを形成すること等によって、統合をグループにまたがる水平方向のものにしてもよい。会社全体にわたる完全なデータ統合は、グループ内での統合ステップとグループにまたがる統合ステップを交互に行うことを含むことができる。

図１８は、バージョン化されたメタデータ・オブジェクトの調整を示す。共有リポジトリ６５０２、バージョン化されたオブジェクト６５０４、調整プロセス６５０６及び調整された単一のオブジェクト・インスタンス６５０８の全ては、図面に関連して上述されたものとすることができる。さらに、各オブジェクト・バージョン６５０４及び単一のオブジェクト・インスタンス６５０８は、メタデータ・データベース６５１０内に格納されたメタデータを指す。モデルに無関係な変更（例えば、会社が新しい付加的な特徴の在庫を追跡したいと望む場合、又は何らかのデータ統合ジョブの影響下の）、或いはメタデータの変更（例えば、ビジネス分析のために、いずれかの数の５日移動平均がモデルに付加される）のために、メタデータ・データベース６５１０内のメタデータが変わることがあることが理解されるであろう。したがって、メタデータ・オブジェクトのバージョンと共にメタデータ・データベース６５１０を区分化するか、又は他の方法でメタデータの変更履歴を保持することが望ましい。この付加的な情報を用いる場合、ユーザは、メタデータの改定を通して前後に移動する際に完全な柔軟性を有する。

図１９は、メタデータ・プロセスにおける同時処理の使用の一例を示す。この例では、調整プロセス６６０４において、複数のメタデータ・インスタンス６６０２が調整される。調整の際、調整されたバージョンのメタデータ・モデルを作成するために、相当量のメタデータを併合するか又は上書きする必要がある。独立した実行又はパイプライン化された実行のために個々のプロセッサ６６０６にストリームすることができる独立したプロセス・オブジェクトとして、調整プロセス６６０４を構成することによって、プロセスを改善することができる。独立したプロセス・オブジェクトは、複数のプロセッサ６６０６を含む単一のハードウェア装置６６０８にストリームすることができ、又は異なるハードウェア装置６６１０、６６０８にストリームすることができ、或いはネットワークを通じて利用可能ないずれかの他のプロセッサ又はプロセッサのグループにストリームすることができる。

同時処理及び関連した並列処理の概念は、当該分野において公知のものであり、ここで詳細に説明する必要はない。一般に、同時処理及び並列処理は、独立して又はパイプライン内で処理することができるサブ・グラフ（オブジェクトについての依存関係の有向グラフを指す）としても知られる、主としてオブジェクトの自己参照クラスタの「塊」にプロセスを分割できる場合に適している。調整プロセスは、同時実行のためのパイプラインとして容易にモデル化することができる。例えば、プロセスは、識別を新しいメタデータ・ソースからのオブジェクト・ストリームに割り当てるためのタスク、前のメタデータ・ソースから可能な競合候補を取り出すためのタスク、調整のためのタスク、調整結果をメタデータ・オブジェクトの出力のセットに併合するためのタスク及び併合されたメタデータ・オブジェクトを格納するためのタスクを含むことができる。メタデータ・インポートのような他のメタデータ・プロセスも、同時処理に適している。

以下の図面は、メタデータ管理に関連した幾つかの方法を説明する。これらのプロセスは、ハードウェア、ソフトウェア、又はこれらの何らかの組み合わせにおいて実現できることが理解されるであろう。プロセスは、プログラム命令、プログラム・データ及びプログラム出力、或いは他の中間又は最終結果を格納するための内部及び／又は外部メモリと共に、単数又は複数のマイクロプロセッサ、マイクロコントローラ、内蔵マイクロコントローラ、プログラム可能デジタル信号プロセッサ、或いは他のプログラム可能な装置において実現することができる。これらのプロセスは、Ｃのような構造化されたプログラミング言語、Ｃ＋＋又はＪａｖａのようなオブジェクト指向プログラミング言語、或いは、コンピュータ、コンピュータのネットワーク及びそれらの組み合わせを含む、いずれかの均一のグループ又は異種のグループのハードウェア・プラットフォーム及びソフトウェア・プラットフォーム上で実行するようにコンパイル又は解釈することが可能ないずれかの他の高レベル又は低レベルのプログラミング言語を用いて作成される、コンピュータ実行可能コードとして実現できることがさらに理解されるであろう。プロセスはまた、各種のツール、プラットフォーム及びアーキテクチャを用いて、拡張可能なエンタープライズ・メタデータ管理システムを達成することもできる。ソフトウェア・プラットフォームの特定の例が上記に与えられるが、他のプラットフォーム及び技術も存在しており、ここで説明されるシステムと共にそれらを有効に用いることができる。

図２０は、ユーザ・インターフェース６７０２からメタデータ・データベース６７１２への照会プロセスに関与するエンティティの図である。クエリは、ユーザがユーザ・インターフェースの固有構文の形でクエリを準備する、ユーザ・インターフェース６７０２で開始することができる。クエリは、ビューのようなメタデータ・モデル６７０４に送ることができる。次に、変換エンジン６７０８によって、又はビューのような第１のメタデータ・モデル６７０４とハブのような第２のメタデータ・モデル６７１０との間のマッピングを記述するマッピング情報を適用することによって、クエリを変換することができる。ハブ６７１０は、付加的な変換又はマッピング・ステップを用いて、変換されたクエリをデータベース６７１２に送り、ハブ・ベースのクエリをデータベース６７１２の固有の構文のクエリに変換することができる。結果は、様々なエンティティ及び任意の適切な変換を通して、最初にそのクエリを発行したユーザ・インターフェース６７０２に送ることができる。

図２１は、メタデータ・モデルからメタデータ・データベースを拡張するプロセスに関与するエンティティを示す。ユーザは、適切な編集インターフェースを用いて、属性等をビュー６８０２に付加することができる。ビュー・モデル６８０２とハブ６８０４との間でメタデータを変換するように、変換エンジンを更新することができる。ハブ・アンド・スポーク・モデルのハブ６８０４は、通常、整合性がある形で維持されるが、ビュー６８０２の変更の性質及びその理由によって、ハブ６８０４を更新することもできる。付加的に、ハブとデータベース６８０８との間で変換するように、変換エンジンを更新することもできる。データ・モデル６８０４及び／又は変換エンジンはまた、データベース６８０８内の新しいビュー６８０２を反映させるのに適するように、適切なデータベース特有コマンドを用いて、適切な行、列、又はテーブルをデータベース６８０８に付加することもできる。データベース６８０８に変更がなされた場合、これらの変更は、モデル・チェーンを通してビュー６８０２まで押し戻すことができる。

図２２は、ツール６９０２からリポジトリ６９１０にアクセスするためのプロセスに関与するエンティティを示す。ツール６９０２は、ビュー６９０４に関して通信するサードパーティのツールとすることができる。ツール６９０２は、ビュー６９０４を通してマッピングされたメタデータを要求することができ、このマッピングされたメタデータを、変換エンジンによってハブ６９０８のための形態に変換することができる。リポジトリ６９１０内のマッピングされたメタデータに物理的にアクセスするために、ハブは、別の変換エンジンを通して、要求をさらに変換することができる。このように、要求は、一連のクエリ変換を通してリポジトリに到達することができる。次に、結果すなわち単数又は複数のメタデータ・オブジェクトは、リポジトリ６９１０からハブ６９０８、ビュー６９０４及び最終的に要求側のツール６９０２に移動する際に、多数の変換又は変換エンジンを通過することができる。したがって、１つの態様においては、単数又は複数のモデルを介してリポジトリに対するクエリを変換し、単数又は複数のオブジェクト変換を介してマッピングされたメタデータのような単数又は複数のオブジェクトをリポジトリ６９１０からツール６９０２に提供するステップを含むことができる、外部ツールからリポジトリにアクセスする方法が存在する。有利なことに、本方法は、リポジトリのための固有の構文の形でクエリをリポジトリ６９１０に提示し、ツール６９０２のための固有の構文の形で結果を外部ツール６９０２に提示する。

図２３は、ツールが、バージョン化されたメタデータ・モデル及びバージョン化されていないメタデータ・モデルにアクセスするプロセスに関与するエンティティを示す。ツール７００２は、例えば、上述のようなイベント・ユーザ環境、チーム・ユーザ環境、又は作業ユーザ環境とすることができるユーザ環境７００４と通信することができる。ユーザ環境７００４は、Ｊａｖａ空間、或いはメタデータ・ツールと共に用いるのに適したいずれかの他のフレームワーク又はプラットフォームとして実装することができる。ユーザ環境７００４のタイプ及びツール７００２の性質並びにユーザ環境７００４において実行される操作によって、ユーザ環境は、バージョン化されていないモデル７００８すなわち運用リポジトリ内の運用クラス及び属性、或いはバージョン化されたモデル７０１０すなわち共有リポジトリ内の設計クラス及び属性のいずれかと通信することができる。ユーザ環境において見ることができるメタデータ・モデルを編集し、メタデータ・モデルの既存のバージョンに置き換わるものとして又は新しいバージョンとして、バージョン化されたモデル７０１０に再び書き込むことができる。メタデータ７０１０が既に別のツール又はユーザにチェックアウトされている場合、ツール７００２が、共有リポジトリ内のバージョン化されたメタデータ７０１０をチェックアウトするのを防止できることが理解されるであろう。

図２４は、ユーザ・インターフェースが共有リポジトリ内のメタデータの多数バージョンにアクセスするプロセスに関与するエンティティを示す。ユーザ・インターフェース７１０２は、メタデータの単数又は複数のバージョン７１０８にアクセスする要求を共有リポジトリ７１０４に発行することができ、メタデータの他のバージョン及び性質並びに種々のバージョン間の変更の性質及び時間順序について、共有リポジトリ７１０４にさらに照会することができる。

図２５は、メタデータのバージョンのための調整プロセスに関与するエンティティを示す。バージョン７２０２は、調整プロセス７２１２を通して別のバージョン７２０４と調整することができる。付加的な調整プロセス７２１４、７２１８を用いて、２つ又はそれ以上の付加的なバージョン７２０８、７２１０について類似した調整を行うことができる。各々の調整後又は全ての調整後、調整されたバージョンを、前のバージョンからの変更を反映する、メタデータの新しいバージョンに併合することができる。この調整は、段階的に又は一度に全てを実行することができ、競合の調整、調整の順序等にわたって、ユーザ制御を随意的に実行することができる。

図２６は、同時処理を用いる調整プロセスに関与するエンティティを示す。この調整プロセスは、別個の調整の各々を、クラスタ７３０２内にあるものにも又は物理的に互いに離れたものにもすることができる、複数のプロセッサ７３０４に別個に渡すことが可能であり、かつ、各調整フェーズ間の依存関係の性質によって、パイプライン式又は並列式に実行できる点を除いて、上述されたような調整プロセスとすることができる。

本発明は、特定の好ましい実施形態に関連して説明されたが、他の実施形態が、当業者によって認識され、本開示の範囲内に含まれるように意図されることを理解すべきである。

各々が複数の異なるコンピュータ・アプリケーション及びデータ・ソースを含むことができる複数のビジネス・プロセスを有するビジネス・エンタープライズの概略図である。 ビジネス・エンタープライズの複数のビジネス・プロセスにわたるデータ統合を示す概略図である。 ビジネス・エンタープライズに複数のデータ・ソースのデータ統合を提供するためのアーキテクチャを示す概略図である。 メタデータ管理システムのためのアーキテクチャを示す。 データベースに照会するための、ビュー・モデル及びデータ・モデルを介する通信を示す。 ビュー・モデルについてのクエリ結果を変換するためにアクセスされる変換エンジンを示す。 外部サービスについてのクエリ結果を変換するためにアクセスされる変換エンジンを示す。 静的モデル・マッピングを示す。 拡張可能なモデル・マッピングを示す。 モデル・マッピングの組み合わせを示す。 複数の内部サービスを外部メタデータに露出させるアーキテクチャを示す。 メタデータのマッピングされたモデル駆動型変換を示す。 メタデータ環境との対話を示す。 メタデータの複数のバージョンを格納する共有リポジトリを示す。 バージョン化されたリポジトリ内のメタデータのバージョンを動的に比較するクライアントを示す。 メタデータ調整プロセスを示す。 調整区域にわたる段階的調整を示す。 バージョン化されたメタデータ・オブジェクトの調整を示す。 メタデータ・プロセスにおける同時処理の使用例を示す。 ユーザ・インターフェース６７０２からメタデータ・データベース６７１２に対する照会プロセスに関与するエンティティの図である。 メタデータ・モデルからメタデータ・データベースを拡張するプロセスに関与するエンティティを示す。 ツールからリポジトリにアクセスするためのプロセスに関与するエンティティを示す。 ツールがバージョン化されたメタデータ・モデル及びバージョン化されていないメタデータ・モデルにアクセスするプロセスに関与するエンティティを示す。 ユーザ・インターフェースが共有リポジトリ内のメタデータの多数のバージョンにアクセスするプロセスに関与するエンティティを示す。 メタデータのバージョンに係る調整プロセスに関与するエンティティを示す。 同時処理を用いる調整プロセスに関与するエンティティを示す。

Claims (45)

1. メタデータ・モデルをリポジトリに登録するステップと、
   第１のストレージ機構を前記メタデータ・モデルの単数又は複数の設計プロパティと関連付けるステップと、
   第２のストレージ機構を前記メタデータ・モデルの単数又は複数の運用プロパティと関連付けるステップと
   を含み、
   前記第２のストレージ機構は、前記メタデータ・モデルの前記単数又は複数の運用プロパティの少なくとも１つについてのタイム・スタンプを格納する、方法。
2. 前記第１のストレージ機構は、前記メタデータ・モデルの前記単数又は複数の設計プロパティの少なくとも１つの単数又は複数のバージョンを格納する、バージョン化されたストレージ機構である、請求項１に記載の方法。
3. 前記メタデータ・モデルの前記単数又は複数の設計プロパティ及び前記単数又は複数の運用プロパティに注釈を付け、これらを前記第１のストレージ機構又は第２のストレージ機構のいずれかと関連付けるステップをさらに含む、請求項１に記載の方法。
4. 前記メタデータ・モデルの前記単数又は複数の設計プロパティ及び前記単数又は複数の運用プロパティを前記第１のストレージ機構と前記第２のストレージ機構との間で割り当てるためのパッケージ構造を提供するステップをさらに含む、請求項１に記載の方法。
5. 前記メタデータ・モデルの前記単数又は複数の設計プロパティ及び前記単数又は複数の運用プロパティを前記第１のストレージ機構と前記第２のストレージ機構との間で割り当てるために、該メタデータ・モデルと関連付けられたマニフェストを提供するステップをさらに含む、請求項１に記載の方法。
6. 前記運用プロパティを第１のモデルとして登録し、前記設計プロパティを第２のモデルとして登録するステップをさらに含む、請求項１に記載の方法。
7. 前記単数又は複数の設計プロパティ及び前記単数又は複数の運用プロパティにわたって前記メタデータ・モデルを照会することが可能である、請求項１に記載の方法。
8. 前記メタデータ・モデルとの単数又は複数のマッピングを登録するステップをさらに含み、前記単数又は複数のマッピングは、該メタデータ・モデルと単数又は複数の他のメタデータ・モデルとの関係を記述する、請求項１に記載の方法。
9. 登録されたメタデータ・モデルを含むリポジトリと、
   前記リポジトリ内の第１のストレージ機構であって、前記メタデータ・モデルの単数又は複数の設計プロパティと関連付けられた第１のストレージ機構と、
   前記リポジトリ内の第２のストレージ機構であって、前記メタデータ・モデルの単数又は複数の運用プロパティと関連付けられ、かつ、該メタデータ・モデルの前記単数又は複数の運用プロパティの少なくとも１つのタイム・スタンプを格納するようになっている第２のストレージ機構と
   を備えるシステム。
10. 前記第１のストレージ機構は、前記メタデータ・モデルの前記単数又は複数の設計プロパティの少なくとも１つの単数又は複数のバージョンを格納する、バージョン化されたストレージ機構である、請求項９に記載のシステム。
11. 前記メタデータ・モデルの前記単数又は複数の設計プロパティ及び該メタデータ・モデルの前記単数又は複数の運用プロパティを、前記第１のストレージ機構又は第２のストレージ機構のいずれかと関連付けるための注釈をさらに備える、請求項９に記載のシステム。
12. 前記メタデータ・モデルの前記単数又は複数の設計プロパティ及び前記単数又は複数の運用プロパティを前記第１のストレージ機構と前記第２のストレージ機構との間で割り当てるためのパッケージ構造をさらに備える、請求項９に記載のシステム。
13. 前記メタデータ・モデルの前記単数又は複数の設計プロパティ及び前記単数又は複数の運用プロパティを前記第１のストレージ機構と前記第２のストレージ機構との間で割り当てるための、該メタデータ・モデルと関連付けられたマニフェストをさらに備える、請求項９に記載のシステム。
14. 前記運用プロパティは第１のモデルとして登録され、前記設計プロパティは第２のモデルとして登録される、請求項９に記載のシステム。
15. 前記単数又は複数の設計プロパティ及び前記単数又は複数の運用プロパティにわたって前記メタデータ・モデルを照会することが可能である、請求項９に記載のシステム。
16. 前記メタデータ・モデルとの登録された単数又は複数のマッピングをさらに備え、前記単数又は複数のマッピングは、該メタデータ・モデルと単数又は複数の他のメタデータ・モデルとの関係を記述する、請求項９に記載のシステム。
17. コンピュータ可読プログラム・コードを含むコンピュータ使用可能媒体を備えるコンピュータ・プログラム製品であって、前記コンピュータ可読プログラム・コードは、単数又は複数のコンピュータ上で実行されるとき、前記単数又は複数のコンピュータに、
    メタデータ・モデルをリポジトリに登録させ、
    第１のストレージ機構を前記メタデータ・モデルの単数又は複数の設計プロパティと関連付けさせ、
    第２のストレージ機構を前記メタデータ・モデルの単数又は複数の運用プロパティと関連付けさせ、
    前記第２のストレージ機構は、前記メタデータ・モデルの前記単数又は複数の運用プロパティのタイム・スタンプを格納する、コンピュータ・プログラム製品。
18. メタデータを管理する方法であって、
    オブジェクト指向メタデータを、運用プロパティを含む運用モデル及び設計プロパティを含む設計モデルに編成するステップと、
    前記運用モデルを運用リポジトリ内に格納するステップと、
    前記設計モデルを共有リポジトリ内に格納するステップと
    を含む、方法。
19. 前記運用モデルのメタデータの少なくとも１つの項目にタイム・スタンプを押すステップをさらに含む、請求項１８に記載の方法。
20. 前記共有リポジトリは、前記設計モデルの２つ以上のバージョンをサポートする、請求項１８に記載の方法。
21. 前記メタデータ・モデルとのユーザ対話のためのユーザ環境を与えるステップをさらに含む、請求項１８に記載の方法。
22. 前記ユーザ環境は前記モデルを編集するための作業空間を含む、請求項２１に記載の方法。
23. 前記作業空間はユーザ専用である、請求項２２に記載の方法。
24. 前記作業空間はメタデータ・インスタンスのバージョン化をサポートする、請求項２１に記載の方法。
25. 前記共有リポジトリ内の前記設計モデルの単数又は複数の異なるバージョンを動的に比較するステップをさらに含む、請求項１８に記載の方法。
26. 前記共有リポジトリは、前記設計モデルのバージョンの分岐をサポートする、請求項１８に記載の方法。
27. 前記設計モデルの複数のバージョンを調整するステップをさらに含む、請求項１８に記載の方法。
28. メッセージ指向サービスを通して前記メタデータ・モデルを非同期的に呼び出すことによって、メタデータ・サービス内の該メタデータ・モデルを用いるステップをさらに含む、請求項１８に記載の方法。
29. 前記メタデータ・モデルを用いるサービスを同時に実行するステップをさらに含む、請求項１８に記載の方法。
30. メタデータを管理するためのシステムであって、
    前記メタデータ・モデルの単数又は複数の運用プロパティを有する運用モデル及び該メタデータ・モデルの単数又は複数の設計プロパティを有する設計モデルを含むオブジェクト指向メタデータ・モデルと、
    前記運用モデルを格納する運用リポジトリと、
    前記設計モデルを格納する共有リポジトリと
    を備えるシステム。
31. クエリを第１のモデルに固有の用語で表現するステップと、
    前記第１のモデルと第２のモデルとの間の単数又は複数の関係を記述するマッピング情報を用いて、前記クエリを前記第２のモデルに固有の用語に変換するステップと、
    前記クエリを固有のデータ・ソース・フォーマットに変換するステップと
    を含む方法。
32. 前記マッピング情報を照会することが可能である、請求項３１に記載の方法。
33. 前記第１のモデルはビューであり、前記第２のモデルはハブである、請求項３１に記載の方法。
34. 前記方法は、エンタープライズ・コンピュータ・システムにおいて実行される、請求項３１に記載の方法。
35. 前記方法は、データ統合システムにおいて実行される、請求項３１に記載の方法。
36. コンピュータ可読プログラム・コードを含むコンピュータ使用可能媒体を備えるコンピュータ・プログラム製品であって、前記コンピュータ可読プログラム・コードは、単数又は複数のコンピュータ上で実行されるとき、前記単数又は複数のコンピュータに、
    第１のモデルを登録させ、
    第２のモデルと、前記第１のモデルの少なくとも１つのプロパティの前記第２のモデルへのマッピングとを特定させ、
    前記第１のモデルの少なくとも１つのプロパティの前記第２のモデルへの前記マッピングを持続させる、コンピュータ・プログラム製品。
37. 前記第２のモデルにマッピングされていない前記第１のモデルの少なくとも１つの他のプロパティを特定するステップと、
    前記第１のモデルの前記少なくとも１つの他のプロパティを持続させるステップと
    をさらに含む、請求項３６に記載のコンピュータ・プログラム製品。
38. 前記第１のモデルは複数のクラスを含む、請求項３６に記載のコンピュータ・プログラム製品。
39. 前記第２のモデルは複数のクラスを含む、請求項３６に記載のコンピュータ・プログラム製品。
40. 前記コンピュータ可読プログラム・コードは、単数又は複数のコンピュータ上で実行されるとき、前記単数又は複数のコンピュータに、前記第１のモデルの前記少なくとも１つのプロパティの前記第２のモデルへの前記マッピングを持続させるための、反射型ストレージ機構であるストレージ機構を提供させる、請求項３６に記載のコンピュータ・プログラム製品。
41. 前記コンピュータ可読プログラム・コードは、単数又は複数のコンピュータ上で実行されるとき、前記単数又は複数のコンピュータに、関係データベース内のメタデータ・モデルを表すためのスキーマを定めさせ、前記スキーマを用いて、前記第１のモデルの前記少なくとも１つのプロパティの前記第２のモデルへの前記マッピングを持続させる、請求項３６に記載のコンピュータ・プログラム製品。
42. 前記コンピュータ可読プログラム・コードは、単数又は複数のコンピュータ上で実行されるとき、前記単数又は複数のコンピュータに、前記スキーマを変更することによって前記第１のモデルを改訂させる、請求項４１に記載のコンピュータ・プログラム製品。
43. 前記コンピュータ可読プログラム・コードは、単数又は複数のコンピュータ上で実行されるとき、前記単数又は複数のコンピュータに、前記関係データベース内の単数又は複数のプロパティを変更することによって前記第１のモデルを改訂させる、請求項４１に記載のコンピュータ・プログラム製品。
44. 前記コンピュータ可読プログラム・コードは、単数又は複数のコンピュータ上で実行されるとき、前記単数又は複数のコンピュータに、前記マッピングを変更することによって前記第１のモデルを改訂させる請求項３６に記載のコンピュータ・プログラム製品。
45. 前記第１のモデル及び前記第２のモデルがメタデータ・モデルである、請求項３６に記載のコンピュータ・プログラム製品。

Images