JP4665042B2 - データの動的アクセス - Google Patents

Description

本発明は、マスターデータの動的アクセスに関する。

混成の情報の技術環境においては、一つの構成内あるいは異なる構成に渡って、異なるコンピュータアプリケーションシステムが使用される。例えば、あるシステムは、ある会社のクライアントに関する情報を管理するのに使用することができ、他のシステムは製品に関する情報を管理するのに使用することができる。それぞれのシステムにはそれぞれのユーザーインターフェイスとデータ保存装置とデータを処理するための処理方法があるだろう。それぞれのシステムは、特定の仕事を扱うための性能を最適化するように設計されているだろう。２つのシステムが維持管理するデータの間には相互の関係があるだろう。例えば、幾つかの製品は、あるクライアントから要求があるかも知れず、ある特性に合致するように変更されなくてはならず、クライアントの特定の住所に届ける必要がある。

システムがデータを共有できるためには、一つのシステムが、クライアントのオブジェクトの形式で全てのクライアントデータを保存するマスターデータベースを維持管理するためのマスターデータサーバーとして導入されなくてはならず、他のシステムが、製品のオブジェクトの形式で全ての製品データを保存するマスターデータベースを維持管理するためのマスターデータサーバーとして導入されなくてはならない。それぞれのクライアントのオブジェクトは、クライアントの様々な態様を記述する属性を持っている。クライアントの属性の幾つかは、部分的なものであり、また幾つかは全体的なものである。部分的な属性は、それぞれのデータベースに保存されるだけだが、全体的な属性は、別のデータベースに非同期で定期的にもしくは或る要因によって複製が作られる。全体的な属性は複製が作られるので、システムは部分的なアプリケーションプログラミングインターフェイスを用いて各データベースにアクセスすることを必要とするクライアントデータと製品データとにアクセスすることができる。各システムは自身のデータベースを維持管理するので、それぞれのシステムは性能を向上させたり独自に維持管理することができる。

特開平７−６５０３２号公報

一態様において、本発明は広くデータに動的にアクセスする方法に使用される。本方法には、サーバーが維持管理するデータベース内に保存されたデータにアクセスするためにクライアントがサーバーに要求を送る段階と、データベースからデータの第１の組を読み出す段階と、クライアントが定義するマッピング規則の組に基づいて、データの第１の組をデータの第２の組にマッピングする段階と、データの第２の組をクライアントのところで受け取る段階とが含まれる。

本発明を実施することによって、以下の一つ或いは二つ以上の特徴が得られる。データベースに含まれるオブジェクトには、オブジェクトの属性値が含まれる。そのオブジェクトには製品が含まれる。そのオブジェクトにはビジネスの相手が含まれる。データの第１の組をデータの第２の組にマッピングすることには、クライアントに関連しないデータの第１の組の中の属性データを取り除くことが含まれる。マッピング規則の組は、時折、サーバーとは無関係なクライアントによって変更される。

他の態様において、本発明は広くデータを維持管理する方法に使用される。本方法には、識別子によって識別されるオブジェクトと関連する識別子とデータとをサーバーで受け取る段階と、各クライアントに対して、識別子とデータがクライアントが定義した一組の規則に適合するかを確認する段階と、識別子とデータとをデータベース内に入力する段階とを含み、前記サーバーは、クライアントにアクセスできるデータベースを維持管理するように構成されている。

本発明を実施することによって、以下の一つ或いは二つ以上の特徴が得られる。データベースには、オブジェクトに関連する属性値が含まれる。識別子とデータベースが一組の規則に適合することを確認する段階には、オブジェクトの属性に関連するクライアントが定義した規則の部分集合にデータが適合することを確認する段階が含まれる。規則の部分集合には、属性値の許容範囲にある形式を定義するための規則が含まれる。識別子とデータが一組の規則に適合していることを確認する段階には、該識別子が、オブジェクトの識別に関連するクライアントが定義した規則の部分集合に適合することを確認する段階が含まれる。その一組の規則には、識別子の許容範囲にある形式を定義する規則が含まれる。本方法には、さらに、識別子にデータをリンクする段階が含まれる。本方法には、さらに、識別子にリンクされるデータを要求する要求をクライアントからサーバーに送る段階と、識別子にリンクされたデータベース内のデータをクライアントの許容範囲の形式に変換する段階が含まれる。本方法には、さらに、サーバーから第２サーバーに要求を送る段階と、どのクライアントがデータベースにアクセスできるかを特定する段階と、第２サーバーから、データベースにアクセスすることができると特定されたクライアントにその要求を回す段階とが含まれ、該要求は、識別子とデータの特定を要求する。そのオブジェクトには、製品が含まれる。そのオブジェクトには、ビジネスの相手が含まれる。サーバーは、拡張可能なマークアップ言語で書かれたメッセージを用いてクライアントとやり取りする。本方法には、さらに、各クライアントに対して、識別子とデータベースがクライアントが定義した規則の組に適合するかどうかを確認する要求をクライアントに送る段階と、もしある特定のクライアントが応答しなければ、そのクライアントを免責摘要表（exception list）に載せて、その識別子とデータが特定のクライアントが定義する一組の規則に適合することが確認できなかったことを知らせる段階とを含む。識別子とデータとが特定のクライアントが定義する一組の規則に適合するかどうかを確認する他の試みは、ある所定の長さの時間の後か、特定のクライアントがデータベース内のデータにアクセスしようとした時に実施される。

他の態様では、本発明は広くデータを維持管理する方法に使用される。本方法には、あるオブジェクトに関連する一組のデータの変更の要求をクライアントからサーバーに送る段階と、サーバーがそのデータの組を固定化したのでクライアントだけがそのデータの組を変更できるというメッセージを受け取る段階と、変更したデータをデータベースに保存するために、変更した一組のデータをサーバーに送る段階と、変更したデータがデータベースに保存されたというメッセージを受け取る段階と、他のクライアントの各々に対して、変更したデータにアクセスできるのは他のどのクライアントかをサーバーで決定する段階と、変更したデータが、クライアントが定義した一組の規則に適合することを確認する段階とが含まれ、また、前記一組のデータはサーバーに維持管理されるデータベース内に保存される。

本発明を実施することによって、以下の一つ或いは二つ以上の特徴が得られる。データの組には、オブジェクトに関連する属性値が含まれる。クライアントが定義する規則の組には、属性値の許容範囲にある形式を定義するための規則が含まれる。サーバーは、属性を、クライアントが発行したチェックリストと比較することで、変更したデータにアクセスできるのは他のどのクライアントかを決定し、各チェックリストはクライアントにアクセス可能な属性を示している。オブジェクトには製品が含まれる。オブジェクトにはビジネスの相手が含まれる。サーバーは、拡張可能なマークアップ言語で書かれたコードを備えるメッセージを用いてクライアントとやり取りする。

他の態様では、本発明は広く、局在（local）データベースにデータを保存する第１モードと、サーバーコンピュータが維持管理する遠隔（remote）データベースにデータを保存する第２モードの間で切り換えをすることのできるモジュールを持ったクライアントコンピュータを提供する段階と、遠隔データベースに保存したデータを、クライアントコンピュータが定義した形式を持ったデータに動的にマッピングするためのインターフェイスを提供する段階とを含む方法に使用される。

本発明を実施することによって、以下の一つ或いは二つ以上の特徴が得られる。本方法は、さらに、局在データベースにデータを保存する第１モードと、サーバーコンピュータが維持管理する遠隔データベースにデータを保存する第２モードの間で切り換えをすることのできるモジュールも持った第２クライアントコンピュータを提供する段階を含んでおり、インターフェイスは、また、遠隔データベースに保存したデータを、第２クライアントコンピュータが定義した第２形式を持ったデータに動的にマッピングし、該第２形式は、第１クライアントに無関係に第２クライアントが変更する。

他の態様では、本発明は広く、識別子が特定するオブジェクトに関連したデータを保存するデータベースを維持管理するデータサーバーと、データベースの中に保存されたデータにアクセスするクライアントと、クライアントおよびデータサーバーとやり取りする統合サーバーとを含み、前記オブジェクトはオブジェクトの態様を説明する属性を持ち、前記データは属性に関連する属性値を含み、各クライアントは識別子と属性に対する一組の規則を定義し、前記統合サーバーは、データに対するクライアントからの要求に応えて、データサーバー中のデータを、クライアントが定義した規則に適合する形式を持ったデータにマッピングすることを特徴とするシステムに使用される。

本発明を実施することによって、以下の一つ或いは二つ以上の特徴が得られる。統合サーバーは、拡張可能なマークアップ言語で書かれたコードを含んだメッセージを用いてクライアントおよびデータサーバーとやり取りする。

他の態様では、本発明は広く、マスターデータの動的アクセスに対して、機械読み取り可能な媒体に明白に保存され、プログラム可能なプロセッサに対し、サーバーが維持管理するデータベースに保存されるデータにアクセスするというクライアントからの要求を受け取らせ、かつデータからの第１のデータの組を読み出させ、かつクライアントが定義した一組のマッピング規則に基づいて、第１のデータの組を第２のデータの組へマッピングさせ、かつ第２のデータの組をクライアントへ送らせるように動作可能な命令を含むコンピュータプログラム製品に使用される。

本発明を実施することによって、以下の一つ或いは二つ以上の特徴が得られる。データベースに保存されるデータには、オブジェクトの属性値が含まれる。オブジェクトには製品が含まれる。オブジェクトにはビジネスの相手が含まれる。命令は、プログラム可能なプロセッサに対し、クライアントに関連のない第１のデータの組内の属性データを取り除かせるように動作可能である。マッピング規則の組は、時折、サーバーに無関係にクライアントが変更する。

他の態様では、本発明は広く、クライアントにアクセス可能なデータベース内に保存されたマスターデータの動的アクセスに対して、機械読み取り可能な媒体に明白に保存され、プログラム可能なプロセッサに対し、識別子および識別子によって確認されるオブジェクトに関連するデータを受け取らせ、かつ各クライアントに対して、識別子とデータがクライアントが定義した一組の規則に適合するかを確認させ、かつ識別子とデータとをデータベース内に入れさせるように動作可能な命令を含むコンピュータプログラム製品に使用される。

本発明を実施することによって、以下の一つ或いは二つ以上の特徴が得られる。データには、オブジェクトに関連する属性値が含まれる。命令は、プログラム可能なプロセッサに、オブジェクトの属性に関連してクライアントが定義した規則の部分集合にデータが適合することを確認させるように動作可能である。規則の部分集合には、属性値の許容範囲にある形式を定義するための規則が含まれる。命令は、プログラム可能なプロセッサに、オブジェクトの識別に関連してクライアントが定義した規則の部分集合に前記識別子が適合することを確認させるように動作可能である。規則の組には、識別子の許容範囲にある形式を定義するための規則が含まれる。命令は、プログラム可能なプロセッサに対し、データを識別子にリンクさせるように動作可能である。命令は、プログラム可能なプロセッサに対し、識別子にリンクされるデータの要求をクライアントからサーバーへ送らせ、識別子とリンクするデータベース中のデータを、クライアントの許容範囲にある形式へ変換させるように動作可能である。オブジェクトには製品が含まれる。オブジェクトにはビジネスの相手が含まれる。サーバーは、拡張可能なマークアップ言語で書かれたメッセージを用いてクライアントとやり取りする。命令は、プログラム可能なプロセッサに、各クライアントに対して、識別子とデータがクライアントの定義した規則の組に適合するかどうかを確認する要求をクライアントへ送らせ、もし特定のクライアントが応答しなければ、そのクライアントを免責摘要表に載せて、その識別子とデータが特定のクライアントが定義する一組の規則に適合することが確認できなかったことを知らせるように動作することが可能である。命令は、プログラム可能なプロセッサに、識別子とデータが特定のクライアントの定義した規則の組に適合するかどうかを確認する他の試みを、所定の長さの時間の後、あるいは特定のクライアントがデータベース内のデータにアクセスしようとする時に始めさせるように動作することが可能である。

他の態様では、本発明は広く、マスターデータの動的アクセスに対して、機械読み取り可能な媒体に明白に保存されて、クライアントとサーバーを持ったコンピュータシステムに対し、オブジェクトに関連した一組のデータの変更に対して第１クライアントからサーバーへ要求を送らせ、サーバーがそのデータの組を固定化したのでクライアントだけがそのデータの組を変更できるというメッセージを受け取らせ、データをデータベースに保存するために、変更した一組のデータをサーバーに送らせ、変更したデータの組がデータベースに保存されたというメッセージを受け取らせるように動作可能な命令を含むコンピュータプログラム製品に使用され、前記サーバーは他のクライアントのそれぞれに対して、変更されたデータの組にアクセスできる他のクライアントはどれかを決定し、かつ変更されたデータの組が、クライアントが定義した規則の組に適合することを確認する。

本発明を実施することによって、以下の一つ或いは二つ以上の特徴が得られる。データの組には、オブジェクトに関連した属性値が含まれる。クライアントが定義した規則の組には、属性値の許容範囲にある形式を定義するための規則が含まれる。命令は、コンピュータシステムに、属性値をクライアントが発行したチェックリストと比較させるように動作可能であり、各チェックリストは、クライアントにアクセス可能な属性を示す。オブジェクトには製品が含まれる。オブジェクトにはビジネスの相手が含まれる。命令は、サーバーに、拡張可能なマークアップ言語で書かれたコードを備えるメッセージを用いてクライアントとやり取りさせるように動作可能である。

本発明の一つ或いは二つ以上の実施形態の詳細は、添付の図面と以下の記載とから説明される。本発明の他の特徴と目的と利点とは、明細書の記載と図面と特許請求の範囲とから明らかになるであろう。

混成のシステムの図である。 クライアントとサーバーの詳細図である。 マスターデータの整合性を確認するための処理を示す図である。 マスターデータの整合性を確認するための処理を示す図である。 マスターデータの整合性を確認するための処理を示す図である。 データのエントリを示す図である。 複合型ソフトウェアに対するアーキテクチャを示す図である。 複合型アーキテクチャを示す図である。 プロキシを用いてマスターデータにアクセスするアプリケーションを示す図である。 コンピュータシステムを示す図である。

図１を参照すると、混成システム１００は、マスターデータサーバー（ＭＤＳ）１１０と、統合サーバー１０９と、クライアントシステム１０２〜１０６とを含む。マスターデータサーバー１１０は、一つのマスターデータベース１１２を維持管理し、クライアントシステム１０２〜１０６は、統合サーバー１０９とマスターデータサーバー１１０を通して、同期して動的にマスターデータベース１１２にアクセスする。クライアントシステム１０２〜１０６は、データが最初にマスターデータ１１２に保存される時に、整合性検査処理によってデータベース１１２に保存されるデータに一致を取る。データがマスターデータサーバー１１０あるいはクライアントシステム１０２〜１０６によって更新されると、その変更は、クライアントシステム１０２〜１０６の全てが見ることのできるものである。一つのマスターデータベース１１２を用いる利点は、管理のオーバーヘッドが減ることであり、異なるデータベースの同期の問題は無くなる。

“同期する”及び“動的”の言葉は、クライアントシステムで実行される処理が情報を必要とする時には、クライアント側で局所的にデータを保存せずにいつでもマスターデータベース１１２からその情報にアクセスできることを意味している。その処理は、バックグランドで実行されるバッチ処理で良いし、ユーザーがマスターデータにアクセスし閲覧し維持管理できるように適応された処理で良い。別の処理は別のデータ形式を必要とし、クライアントシステムとマスターデータサーバーの間で転送されたデータは、一つの形式から他の形式に、システムの構成によって、動的にマッピングされる。各クライアントシステムは、他のシステムとは無関係に構成することができ、各システムは、マスターデータベース１１２中のデータを別々に閲覧し処理することができる。統合サーバー１０９は、各クライアントシステムとマスターデータサーバーが定義したデータ形式に適合するように、データを動的にマッピングする。

図２を参照すると、クライアント１１４は、クライアントシステム１０２〜１０６のいずれかを表すのに使用されている。例えば、販売アプリケーション１１６や、製品に関係するデータにアクセスする製品アプリケーション１１８などの異なるアプリケーションプログラムが、クライアント１１４上で実行される。アプリケーションプログラム１１６と１１８は、製品サービス層１２４から提供される機能にアクセスする。製品ユーザーインターフェイス１２０は、製品サービス層１２４と相互作用して、ユーザーのデータを画像表記したものを提供する。製品サービス層１２４はクライアント１１４に固有のものであり、クライアント１１４に関連する製品モデルに従った製品データを処理する機能を提供する。例えば、クライアント１１４は、クライアント関係を管理するのに使用されるアプリケーションを持っていよう。これらのアプリケーションは、クライアントとの間で転送される製品に関係したデータを必要とする。クライアント１１４上で実行されるアプリケーションが使用する製品データには、販売データが含まれるが、財務データは含まれない。クライアント１１４は、製品に関連するいかなるデータも保存しない。その代わりに、そのようなデータにアクセスしようという全ての要求は、統合サーバー１０９内の交換インターフェイス１２６を通してマスターデータサーバー１１０に回される。

マスターデータサーバー１１０の主な機能は、マスターデータベース１１２に保存されるマスターデータを維持管理することである。マスターデータにアクセスするアプリケーション１２８や１３０のような異なるアプリケーションプログラムは、マスターデータサーバー１１０上で実行することができる。アプリケーション１２８と１３０は、製品サービス層１３４が提供する機能にアクセスする。製品ユーザーインターフェイス１３２は製品サーバー層１３４と相互作用して、ユーザーのデータを画像表記したものを提供する。製品サービス層１３４はマスターデータサーバー１１０に固有のものであり、マスターデータサーバー１１０に関連する製品モデルに従った製品データを処理する機能を提供する。製品サービス層１３４はマスターデータベース１１２にアクセスする。クライアント１１４上で実行されるアプリケーションが、マスターデータベース１１２内に保存されるマスターデータにアクセスする必要がある時は、要求が交換インターフェイス１２６を通して製品サービス層１３４へ回される。交換インターフェイス１２６は、ピアトゥピア接続を用いて製品サービス層１２４と１３４へ接続することができる。

クライアント１１４に関連した製品モデルは、マスターデータサーバー１１０と関連した製品モデルとは異なるだろう。従って、製品サービス層１２４が製品サービス１３４を通してマスターデータベース１１２にアクセスする時は、意味論（semantic）マッピングが必要である。

製品サービス層１２４は、クライアント１１４のアプリケーションが使用することのできる、整合性の或るアプリケーションプログラミングインターフェイスを提供する。これによって、販売アプリケーション１１６と製品アプリケーション１１８を維持管理し更新することがより容易になる。製品サービス層はクライアントに固有のものであるため、異なるクライアントは異なる製品サービス層をもつことになる。クライアントシステムの各製品サービス層とそれの関連したアプリケーションは、他のクライアントシステムの製品サービス層とは無関係に変更したり更新したりすることができる。

[マスターデータの維持管理]
マスターデータが作られたり変更された時、そのデータは、クライアント上で実行されているビジネス処理と整合性があるべきである。正しく動作するよう処理するために、その処理は、それが使用するデータの整合性に依存する必要が出てくる。マスターデータが作られたり更新される時、どのクライアントがデータを使用するかは知られている。従って、データに関係する全てのクライアントは、そのデータを使用する前にデータの整合性を調べる。

ユーザーがマスターデータを維持管理する（例えば、加えたり、変更したり、削除したり）ので、ユーザーは、変更がクライアント上で実行される処理と整合性があることを確かめることを望む。ユーザーは、整合性があることを知らせ、データが整合性を持つのに役立つような迅速な応答を必要とする。

クライアントによる整合性の規則は、互いに相反する。もし矛盾が生じたら、全てのクライアントを満足させるようなデータの選択は存在しないので、マスターデータオブジェクトを維持管理することはできない。それゆえクライアントは、マスターデータオブジェクトが作られるかも知れないその前に、ユーザーがデータを維持管理することによって調和が取れていなくてはならない。

整合性は、データを書くときか読むときのいずれかの時に調べることができる。データを読むときに整合性を調べることの利点は、各クライアントが、その処理で使用するデータの整合性を、データを読むときに確認するということである。欠点は、読む動作は書く動作よりも頻繁に行われるので、データを読む時のに整合性を調べることは、データを書くときよりも効率的で無いことである。他の欠点は、読む動作の間に不整合が発見されたときに、不整合を解決することができないことである。不整合なデータにアクセスした処理を停止し、誰がそのデータに侵入したのかを見つけて、修正が可能か又どれが正しいデータかを決定する必要がある。比較すると、データを書くときに整合性を調べることの利点は、実際にデータが保存されマスターデータベースに書き込まれる前に、ユーザーにデータベースを修正させることが可能なことである。

図３を参照すると、新しいデータがマスターデータベース１１２に入ると、ユーザーがマスターデータサーバー１１０を通してデータ入力処理１４２を実行する。この例では、マスターデータの維持管理は、マスターデータサーバー１１０が実行する。クライアントＡ１１４とＢ１１４は、統合サーバー１０９に接続される。ユーザーは、ユーザーインターフェイス（例えば、画面）を選択して、新しい製品のために新しい入力を作り固定する＜１４６＞。一例として、ユーザーは番号“４７１１”を選択して新しい製品を特定する。新しい入力がマスターデータベース１１２に保存される前に、他のユーザーが他の製品を特定するのに使用することができないように、識別子“４７１１”が“固定”される。固定化の手続きによって、唯一人の人以外は識別子“４７１１”に関連するマスターデータを作ることができなくなる。

識別子によってマスターデータベース１１２に入力されたデータに、全てのアプリケーションが確実にアクセスできるために、識別子（すなわち、番号“４７１１“）は、識別子の許容範囲にある形式を定義する体系に対して照合する＜１４８＞。マスターデータサーバー１１０とクライアントＡ１１４とクライアントＢ１１４の各々は、他の体系とは異なる自身の体系を持つことができる。例えば、マスターデータサーバー１１０は、１０桁未満の識別子を必要とする体系を使用することができる。識別子がマスターデータサーバー１１０が必要とする体系に適合することを確認されて、要求がマスターデータサーバー１１０から統合サーバー１０９へ送られて、その識別子を様々なクライアントが生成した体系に対して調べる。

統合サーバー１０９は、クライアントが新しいデータへアクセスできるところの情報を持っている。例えば、クライアントＡ１１４とクライアントＢ１１４は共に“製品”に関連するデータにアクセスする。統合サーバー１０９は、体系に対して識別子を調べる要求を、関係するクライアントである、この場合、クライアントＡ１１４とクライアントＢ１１４に回す＜１５０＞。クライアントＡ１１４が識別子を確認するという要求を受け取ると、クライアントＡ１１４は、自身の体系に対して識別子を調べる＜１５２＞。もし識別子が体系に合致しなければ、誤りメッセージがマスターデータサーバー１１０に送られて、ユーザーが他の識別子を選ばなくてはならないことを示す。同様に、クライアントＢ１１４は、自身の体系に対して識別子を調べ＜１５４＞、もし識別子が体系に合致しなければ、誤りメッセージをマスターデータサーバー１１０に送る。１４８，１５２，１５４で調べることによって、マスターデータサーバー１１０とクライアントＡ１１４とクライアントＢ１１３のすべてが、サーバー１１０とクライアントＡ１１４とクライアントＢ１１４の各々に対して、正しい識別子を用いて新しいデータにアクセスすることができることが確実となる。

もし、識別子の形式が確認されると、ユーザーは、製品４７１１に関する一般的な属性の維持管理を継続する。例えば、ある属性は、製品の短い説明か、或いは測定の基本単位か、或いは測定の販売単位か、或いは製品の価格か、或いは製品の数量か、あるいは製品に関するプランニングパラメータか、或いは製品の販売者であって良い。一般的な属性は、二つ以上のクライアントに関連する属性である。

ユーザーは、各属性毎に属性値を入力し、属性値がそれら属性に対する整合性の記録の集まりを満足しているかどうかを調べる＜１５８＞。例えば、整合性の規則では、もし測定の新しい単位が加えられると、それは測定の既存の単位に対して変換因子を必要とすることを要求する。他の例として、整合性の規則は、もし或る数が製品の価格を表すのに使用されると、貨幣も同様に明記されなくてはならない。

マスターデータサーバー１１０は、統合サーバー１０９に要求を送って、属性値の確認を要求する。統合サーバー１０９は、その要求を関連するクライアントに回す＜１６０＞。その要求を受け取ると、クライアントＡ１１４は、その属性値をクライアントＡ１１４が定義する整合性の記録に対して検査し＜１６２＞、もし規則違反が起こるとメッセージをマスターデータサーバー１１０に送る。例えば、クライアントＡ１１４が、測定の販売単位を伴う測定の基本単位を必要とする整合性の規則を定義することができる（例えば、もし販売員が製品を箱単位で売ると、販売員はこの測定の単位である箱と、一箱の中にいくつ製品が入っているかに関する追加情報とを必要とする）。他の整合性規則は、価格をユーロで明記することを要求するかも知れない。

属性の確認に関する要求を受け取ると、クライアントＢ１４４は、クライアント１４４が定義した規則に対して属性値を調べる＜１６４＞。例えば、整合性の規則は、未決の計画実行が無ければ製造時間のみが変更可能であることを要求する（その理由は、例えば、計画実行は一定の製造時間によって決まるからである）。

クライアントＡ１１４とクライアントＢ１１４が、属性がこれらクライアントが定義した規則に適合することを確認した後、ユーザーは、インターフェイス（例えば、画面）を選択して、例えば販売に関連するデータを維持管理する＜１６６＞。販売に関連する属性は、クライアントＡ１１４にのみ関係し、クライアントＢ１１４には関係しない。統合サーバー１０９は、どの種類の属性がどのクライアントに関係するかを追跡し続ける。ユーザーが販売に関連するデータを追加あるいは変更した後に、マスターデータサーバー１１０は、要求を統合サーバー１０９に送り、そのデータがクライアントの整合性規則に適合することを確認する。統合サーバー１０９は、その要求を、本例ではクライアントＡ１１４である関連するクライアントに回す＜１６８＞。その要求を受け取ると、クライアントＡ１１４は、販売に関連するデータを、クライアントＡ１１４が定義した販売データに関連する整合性規則と照合する。もしそのデータが整合性規則と整合していれば、マスターデータサーバー１１０は、新しいデータをマスターデータベース１１２へ保存する＜１７２＞。

マスターデータも、維持管理ダイアログを実行するインターフェイスを用いるクライアントのユーザーが維持管理することができる。インターフェイスは、クライアントに関連するデータのみが表示され維持管理されるように設計することができる。

図４を参照すると、データ維持管理処理１７４は、クライアントがマスターデータベース１１２内のデータを更新した時に実行される。この例では、クライアントＡ１１４は、製品４７１１に関するデータを更新することを希望している。クライアントＡ１１４は製品４７１１を“開く”＜１７６＞が、これは、ユーザーが識別子“製品４７１１”を入力してどのデータを更新する必要があるのかを特定することのできる、グラフィカルユーザーインターフェイスを示すことを意味していよう。

クライアントＡ１１４は、要求を統合サーバー１０９に送り、これがマスターデータサーバー１１０からのデータを要求する＜１７８＞。要求を受け取ると、マスターデータサーバー１１０は製品４７１１に関連するデータを読んで固定する＜１８０＞。固定化は、どのクライアントがデータベースを変更したかに係わらず、マスターデータサーバー１１０が行う。マスターデータサーバー１１０は、この情報が、データへのアクセスをしようとしている他のクライアントと交信することができるように、どのクライアントがデータベースを固定化したかを知る必要がある。このデータは統合サーバー１０９に送られ、データはクライアントＡ１１４の形式を持ったデータにマッピングされる。一例として、クライアントＡ１１４は、販売に関連するデータを維持管理する。クライアント１１４は、販売に関連するデータのみを示す画面を表示するのにグラフィカルユーザーインターフェイスを使う。クライアントＡ１１４にいるユーザーは、販売に関連するデータの維持管理（例えば、訂正したり削除したり）を進める＜１８２＞。更新されたデータは、他のクライアントとマスターデータサーバー１１０が定義した規則に対する整合性を調べられる。

クライアントＡ１１４は、要求をサーバー１０９に送って、確認処理を始める。統合サーバー１０９は、この要求を関連するクライアントへ回す。この例では、販売データクライアントＢ１４４に関連していないので、統合サーバー１０９はその要求をクライアントＢ１４４には送らない。統合サーバー１０９は、要求をマスターデータサーバー１１０へ送るが、このサーバーは要求に応答してマスターデータサーバー１１０が整合性のために定義した整合性規則に対して、属性を照合する＜１８８＞。マスターデータサーバー１１０と他のクライアントは、更新済みデータが整合性規則に整合していることを示すメッセージを送り、また、マスターデータサーバーが更新済みデータをマスターデータベース１１２へ保存することを要求するメッセージをマスターデータサーバー１１０へ送る。

マスターデータサーバー１１０は、多くのアプリケーションあるいは異なるクライアント上で実行される処理に必要なデータを維持管理する。オブジェクトに関連したデータを維持管理するクライアント（あるいは、クライアントを使用するユーザー）は、全てのデータを変更する資格を与えられたり承認されたりはせず、自身の処理（例えば、販売）に関するデータのみを維持管理することができる。統合サーバー１０９は、ユーザーが自身の処理に関連するデータを持つ画面のみにアクセスすることができ、従ってこの画面に対して整合性の要求を扱うことができるだけであるように構成される。維持管理されてきたデータ（及びデータに関連するオブジェクト）は、この画面に対して使用することができる（例えば、この画面に関連する処理に対して使用することができる）。そのデータは、まだ作られていない画面（例えば、未来の計画）においては使用することができない。

整合性を照合する必要のあるクライアントは、統合サーバー１０９によって決定される。統合サーバー１０９は、照合の要求を、実行時にクライアントへ回し、“了解メッセージ”あるいは整合性の誤りを記載したメッセージの集積のいずれかの、各クライアントの結果を戻す。誤りは、ユーザーがデータを変更して整合性を保証できるように表示される。

整合性の照合処理の間、もしクライアントが応答しないと、クライアントは、免責摘要表に載せられ、照合処理は、残りのクライアントに対して処理を続ける。これによって、マスターデータの維持管理は、クライアントのいくつかの間違いのせいで妨害されることは絶対に無い。

図５を参照すると、データ維持管理処理１９４は、クライアントが応答しない時に発生する。マスターデータサーバー１１０は、製品４７１１に関連するデータを維持管理し＜１９６＞、整合性を確かめる要求を統合サーバー１０９へ送る。統合サーバー１０９は、その要求を関連するクライアントに回す＜１９８＞。この要求を受け取ると、クライアントＡ１１４は属性を調べる＜２００＞。クライアントＢ１４４は、この要求を受け取ると、同様に属性を調べると考えられる＜２０２＞。しかし、幾つかの理由から（例えば、シャットダウン）、クライアントＢ１４４は応答しないこともある＜２０４＞。統合サーバー１０９は、クライアントからの全ての応答を集めて＜２０６＞、クライアントＢ１４４から応答を受け取っていないことを発見する。統合サーバー１０９は、クライアントから集めた応答をマスターデータサーバー１１０へ送る。

マスターデータサーバー１１０は、クライアントＢ１４４を免責摘要表に加えて＜２０８＞、クライアントＢ１４４が、更新済みデータがクライアントＢ１４４が要求した整合性規則と整合性があるかどうかを確かめられていないことを示す。マスターデータサーバー１１０は、更新済みデータをマスターデータベース１１２へ保存して＜２０８＞、クライアントＢ１４４を調べる仕事の流れを始める＜２１２＞。この仕事の流れは、ある時間が過ぎた後に、手動もしくは自動でクライアントＢ１４４を調べることができる、あるいはクライアントＢ１４４が読み出し要求を送った時などの、クライアントとの通信が可能であると知らせるきっかけの出来事があると、クライアントＢ１４４を調べる。もし統合サーバー１０９が首尾良くクライアントＢ１４４と通信することができると、クライアントＢ１４４は、整合性を確認する属性を調べる＜２１４＞。不一致は無いというクライアントＢ１４４からの確認を受け取ると、マスターデータサーバー１１０はクライアントＢ１４４を免責摘要表から外す。

上記の方法を用いて、マスターデータの維持管理処理は、クライアントがネットワーク内で利用可能で無い時にはインストールされない。不整合のデータは、クライアントに渡らない。免責摘要表は、どのクライアントを、整合性の照合が完全に終わるまで、一時的にオブジェクトへのアクセスを禁止すべきかを決定するのに使用する。

［整合性と組織的単位］
データオブジェクトの属性は“組織単位”であろう。組織単位のために作られたデータは、あるクライアントにのみ関連するだろう。例えば、最初の製造工場に対する計画データが作られた時に、そのデータは、最初の製造工場に対して計画を実施するアプリケーション（例えば、上級プランナーとオプティマイザーのアプリケーション）によってのみ必要とされ、第２の製造工場に対して計画を実施する計画アプリケーションとは無関係であろう。

統合サーバー１０９は、データが関係のあるクライアントにのみデータを回す。整合性の照合は、それらのクライアントによって実行される。もし統合サーバー１０９が処理するメッセージには、２つの組織への参照が含まれるならば、メッセージは２つの小メッセージに分割することができ、各小メッセージは整合性の照合を実施するのに使用されるだろう。この方法は、組織単位以外の属性によって異なるクライアントへデータを回すのに使用することもできる。

時に、データは正確に回されない。それ故、クライアントは、クライアントの通常動作を乱さないやり方で無関係のデータに反応するように設計される。例えば、もし第２製造工場に対する計画アプリケーションが第１製造工場に対するデータを受け取ると、計画アプリケーションは、誤りを整合性照合処理に返す前に、このデータを無視する必要がある。

［クライアントを加える］
新しい整合性の要求を備えた新しいクライアントが混成システム１００に加えられると、クライアントの整合性の照合が、新しいクライアントがデータにアクセスできる前に、全てのマスターデータに対して実行される。

新しいクライアントは、統合サーバー１０９で登録され、どの属性を照合したら良いかを示す照合インターフェイスを発行する。新しいクライアントは、新しいクライアントが整合性の照合が完了するまでアクセスされないように、全てのデータに対して免責摘要表に置かれる。仕事の流れ２１２（図６）に似た仕事の流れが、新しいクライアントに対する整合性の照合を実行するために始められる。

［探索］
クライアントがマスターデータを探索する時、要求がマスターデータサーバー１１０に回送される。最初に、マスターデータサーバー１１０は、重要なフィールド（例えば、短い記述）を少々持った探索結果の表をクライアントに戻す。もし、クライアントが探索結果の全てあるいはいくつかの上にさらなる情報を必要とするならば、クライアントは、それ以上の情報にアクセスするのに読み出し処理（下述）を使用する。探索に使用されるマスターデータサーバー１１０のアプリケーションプログラミングインターフェイス（ＡＰＩ）は、クライアントが必要とする探索の選択事項を網羅する多数の可能性を提示するように設計される。

クライアントがマスターデータベース１１２内のデータを読む要求をすると、その要求は、マスターデータサーバー１１０へ回される。例えば、読み出し処理には２つの種類がある。読み出し処理の一つの種類は“識別結果を得る”と呼ばれる、オブジェクトの識別情報に対する要求であり、これは、オブジェクトの識別子とある記述パラメータ（例えば、製品に対する短い文章や、ビジネスの相手に対する名前）を返す。他の種類の読み出し処理は“詳細を得る”と呼ばれる、オブジェクトの詳細情報に対する要求であり、これは、オブジェクトに関連する情報全てを返す。

各クライアントは、オブジェクトの属性の定義を各自持つであろうし、クライアントはそのオブジェクトの一部を“詳細を得る”読み出し処理の中で考察する。それらの属性は、マスターデータサーバー１１０の中で知られた全ての属性の部分集合であろう。マスターデータサーバー１１０が別の、より一般的なデータモデルを持っていることはあり得ることであり、それ故、クライアントＡＰＩはマスターデータサーバーＡＰＩにマッピングされる必要がある。このマッピングは、アプリケーション統合層の中で実行される。

［削除］
マスターデータベース１１２内でのデータの削除は、２段階で実行することができる。最初に、各クライアントは、オブジェクトへの参照が存在するかどうかを尋ねられる。もし参照が存在しなければ、クライアントからオブジェクトに関連したデータを読もうとする読み出し処理は、それ以降受け付けられず、オブジェクトはどの探索結果においても返されない。２番目に、オブジェクトはマスターデータベース１１２に保管され、またそこから削除される。２番目の段階は、全てのクライアントが、オブジェクトに対する参照は無いことを述べた時に実行される。他のクライアントが未だオブジェクトにアクセスし使用することができるのに対し、あるクライアントに関してオブジェクトを“削除”することが可能である（第２段階は飛ばした）。

多くの処理によって、処理トランザクションから、そのトランザクションに関連したマスターデータへの航行（navigation）が可能となる。例えば、ある製品に対する販売注文が生まれると、ユーザーは、製品の識別子と製品の記述とを見る。もしユーザーがより詳細を知りたい場合は、他の属性を見るためにその製品に関するマスターデータを示すインターフェイスへ航行することができる。

図２に示される例のように、クライアントの結びつきが緩い時は、２つの場合がある。もしクライアントが自身のマスターデータユーザーインターフェイスを持っているなら、そのマスターデータユーザーインターフェイスは、製品のマスターデータを表示するのに使用されるはずである。もしクライアントが自身のユーザーインターフェイスを持っていないなら、マスターデータサーバー１１０のユーザーインターフェイスが使用される。

［アプリケーション間の通信］
図６は、アプリケーションと、例えば製品マスターデータのようなマスターデータとの間の相互関係を示している。ユーザーは、ユーザーインターフェイス２１８を用いて製品に関する注文２２０を作る。ユーザーは、探索アプリケーションを用いて、様々な属性（例えば、永久鍵、記述、製品の種類）によって或る製品を探し出す。ユーザーがデータを入力画面へ入力した後、探索アプリケーションは製品が存在するかどうかを調べる。探索アプリケーションは、製品マスターデータベース１１２にアクセスする製品ＡＰＩ２２２を呼び出す。もし探索アプリケーションが製品を見つけると、その製品の短い記述文章がユーザーインターフェイス上に現れる。ユーザーが注文のデータを入力し終えた後、ユーザーはデータを保存する。注文のデータが保存されると、その製品のマスターデータへのリンク（あるいは参照）が作られる。いくつかの場合には、製品の属性が必要に応じて更新される。

［ソフトウェアの層の間の通信］
図７は、クライアントシステム２２４とマスターデータサーバー１１０のソフトウェアの層の間の通信を示している。クライアントシステム２２４には、ユーザーインターフェイス２２６とビジネスサーバー層２２８と継続サービス（persistency service）層２３０とマスターデータベース２３２とが含まれる。同様に、マスターデータサーバー１１０には、ユーザーインターフェイス２３４とビジネスサービス層２３６と継続サービス層２３８とデータベース２４０とが含まれる。クライアントシステム２２４とマスターデータサーバー１１０は、階層構造のソフトウェアアーキテクチャである。各層は、各システム内部のすぐ下の層の関数にアクセスする。クライアントシステム２２４がマスターデータサーバー１１０のデータベース２４０内のデータにアクセスする必要がある時、クライアント２２４のビジネスサービス層２２８は、マスターデータにアクセスするために、マスターデータサーバー１１０のビジネスサービス層２３８と通信する。

マスターデータサーバー１１０のみがマスターデータベース２４０内のマスターデータにアクセスする。動作の一つのモードでは、クライアントシステム２２４はマスターデータを保持せず、クライアントに特化した処理データのみに対して自身の継続サービス２３０を使用する。例えば、ポータルを使用することによって、ユーザーインターフェイス２２６と２３４は、統合することができ、ユーザーはユーザーインターフェイス２２６からユーザーインターフェイス２３４へリンク或いは航行することができる。

クライアントシステム２２４のユーザーインターフェイス２２６とビジネスサービス層２２８は、例えば交換インターフェイス或いはウェブサービスを通して直接にマスターデータサーバー１１０のビジネスサービス層２３６にアクセスできる。

クライアントシステム２２４の継続サービス層２３０は、マスターデータサーバー１１０のビジネスサービス層２３６を使用して、マスターデータの継続を委譲することができる。

クライアントシステム２２４のユーザーは、アーキテクチャの要求によって、ビジネスサービス層２２８（リンク２４２を通して）、或いは継続サービス層２３０（リンク２４４を通して）からマスターデータベース２４０にアクセスすることを決定できる。継続サービス層２３０から接続することの利点は、継続サービス層２３０内のサービスの数は、通常、ビジネスサービス層２２８内のサービスの数よりも少ないことである。この結果、マスターデータベース２４０にアクセスできるように、少々の努力でクライアントシステム２２４を適応させることになる。継続サービス層２３０から接続することの他の利点は、継続サービス層２３０からマスターデータサーバー１１０にアクセスすることによって、どこにデータが保存されるかに係わらず、ビジネスサービス層２２８は独立して構成することができる点である。これによって、図８に示されるハイブリッドアーキテクチャを実施することが、より容易になる。

［クライアント側でのハイブリッドデータ保存］
混成情報技術システムの一実施例において、どのようにクライアントがマスターデータにアクセスするかは、どのようにクライアントが構成されるかによって決まる。もしクライアントが単独のシステムであれば、マスターデータはクライアントのデータベース内に直接に保存される。もしクライアントがマスターデータサーバーを持った分散型の環境で実行されるなら、マスターデータサーバーのマスターデータの継続性が使用される。

開発しているソフトウェアの見地からすると、マスターデータの一つのソフトウェア“インスタンス”のみを実施するのが有利であり、これは異なるシステム−つまり統合済み導入シナリオ内と同様に分散型環境−において使用することができる。これによって、開発費用と維持管理費用が削減され、顧客に単一のソフトウェアを提供することができる。

マスターデータにアクセスするための“ハイブリッドソフトウェア”は、図８に示したアーキテクチャを用いて開発することができる。継続サーバー層２３０は、局在データベース２３２か遠隔マスターデータベース２４０のいずれかに、マスターデータサーバー１１０のビジネスサービス層２３６を通してアクセスすることができるように設計される。このことによって、クライアント側におけるソフトウェアをカスタマイズする点において、データが維持管理されるのが局所的にか或いは遠隔からかを決定することが可能になる。

［マスターデータのマッピング］
マスターデータは、クライアントシステムとマスターデータサーバーとの間でメッセージを用いて交換される。統合サーバーは、メッセージの経路決定とマッピングに対して責任がある。統合サーバーは、クライアントに関する情報を持っており、メッセージのマッピングとデータの種類とインターフェイスに適切なものを選択することができる。

統合サーバーを用いることの利点は、クライアントシステムあるいはマスターデータサーバー上にコードを加える必要が無いことである。マッピング規則は、統合サーバーの上で維持管理され保存される。一例では、マッピング規則は、クライアントのアプリケーションを開発する人が開発する。

［クライアントからマスターデータにアクセスする］
図９を参照すると、マスターデータサーバー１１４には、製品データを管理する製品データモジュール２８８が含まれる。製品データモジュール２８８には、ユーザーインターフェイス部品２８２とアプリケーションプログラミングインターフェイス部品２８４とマスターデータベース２８６とが含まれる。クライアントアプリケーション２５０は、マスターデータブローカー（broker）２８４を呼ぶことによって製品データモジュール２８８にアクセスするが、これによって、キャッシュの機能と、権限の確認とを実行して、局在して保存されるデータにアクセスするか（クライアントが単独システムとして構成される場合）、遠隔に保存されるデータにアクセスするか（クライアントがマスターデータサーバーと相互作用するように構成される場合）を決定する。クライアント１１０がマスターデータサーバーと相互作用するとき、いくつかのデータは、局所的に（例えば、クライアント１１０のメモリ内で）キャッシュに格納することもできる。

マスターデータブローカー２５２には、製品サーバー部品２９０と交換インターフェイスプロキシ２９２と局在マスターデータベース２９６とが含まれる。製品サーバー部品２９０は、アプリケーション２５０が呼ぶことのできるアプリケーションプログラミングインターフェイスを提供する。もしクライアント１１０が単独のシステムならば、製品サーバー部品２９０は、パス２９８を通して局在マスターデータベース２９６内に保存されるデータにアクセスできる。もしクライアント１１０がマスターデータサーバー１１４と相互作用するように構成されていると、製品サービス部品２９０は、パス３００を通して交換インターフェイスプロキシ２９２と通信することができる。交換インターフェイスプロキシ２９２は、統合サーバー１０９の交換インターフェイス１２６を通して、マスターデータサーバー１１４のアプリケーションプログラミングインターフェイス２８４と通信する。アプリケーションプログラミングインターフェイス２８４は、マスターデータベース２８６内に保存されるマスターデータにアクセスするのに使用される。クライアント１１０が単独のシステムとして構成されるにしても、マスターデータサーバー１１４と相互作用するネットワークシステムの一部として構成されるにしても、マスターデータは、局在マスターデータベース２９０あるいはマスターデータベース２８６のいずれか一つのデータベース内で維持管理される。

［データオブジェクト間のリンク］
マスターデータオブジェクトと処理オブジェクトは、ある意味論と結びつけることができる。その実行は、例えば一般的な顧客関係管理相関（customer relationship management interlinkage）の、時間依存の属性ｎ：ｍの関連性のようなパターンによって行われる。

マスターデータは、マスターデータサーバー１１０上に保存される。マスターデータオブジェクト間のリンクがマスターデータサーバー１１０上に保存されるべきかどうかの決定は、接続されたクライアント内のリンクの使用法による。もしリンクの意味論が多くのシステムに必要ならば、そのリンクは、マスターデータサーバー１１０上に保存されなくてはならない。

一般的に、マスターデータサーバー１１０は、処理データを知らない（或いは保存しない）。従って、クライアント１１４は、処理データから参照したマスターデータへのリンクを維持管理する責任がある。

時に、マスターデータサーバー１１０上の処理データへのリンクを保持する必要があるだろう。そのようなリンクをマスターデータサーバー１００上で実施することは、一般的である。

［データのキャッシング］
マスターデータの読み出しアクセスは、マスターデータの他の処理よりも頻繁に起こり、屡々、速度が重視されるアプリケーションの一部である。クライアント側にあるデータをキャッシングすることにより、読み出しアクセス動作は、より高速に実行できる。

クライアント上でキャッシングを実行するために、異なる方法を使用することができる。どちらの方法が良いかは、マスターデータのアーキテクチャによる。一つの方法は、統合サーバー内のデータをキャッシングすることである。一つの方法では、統合サーバーは、メッセージ読み出し動作に対する応答をキャッシングすることができる。もし同じメッセージが再び送られると、応答は、キャッシュから送ることができる。もう一つの方法では、キャッシングはメッセージレベルで実行することができる。メッセージは、マスターデータアプリケーションによってキャッシングされる。さらに別の方法では、オブジェクトモデルがキャッシングされる。屡々、クライアントマスターデータトランザクションは、キャッシュ機構を持っている。このキャッシュは、マスターデータサーバーと通信する時にも使用することができる。

適切なキャッシングの結果を得るために、キャッシュされた内容は、クライアントのセッションの間で分ける必要がある。典型的には、これは、キャッシュをデータベース上で継続させることによって達成される。分けたオブジェクトの新しい基準の技術を用いて、メモリ内のキャッシュは性能を向上させるために分けることもできる。

継続的なキャッシュが用いられると、クライアントは、古い入力がキャッシュから削除されるように、最後のアクセス時間を記録することになる。

キャッシュされたデータは、データが最早役に立たなくなったときに無効にする必要がある。マスターデータはめったに変更されないので、より良い方法は、定期的に無効にするよりも明示的に無効にする方法を使用することである。マスターデータが変更されると、この情報は、全てのクライアントに知らされるので、皆、自分のキャッシュを無効にすることができる。クライアントは、無効にした全てのデータを、例えば夜間などの都合の良い時に再読み出しすることもできる。キャッシングの作用は、サーバー側で申し出ることができる。セッション間で分けられたキャッシュの結果、性能は向上するだろう。

［権限の確認］
ユーザーは権限の確認に重要な役を果たす。ユーザーは、あるオブジェクト或いはオブジェクトの種類を要求する資格を与えられる。一つの方法は、全てのユーザーを全てのクライアントからマスターデータサーバー上に存在させることである。ユーザーの権限は、通常通りにマスターデータサーバー上で与えることができる。この方法は、システム管理を増大させる傾向がある。他の方法は、全ての権限の確認をクライアント上でさせ、マスターデータサーバーに要求された全てのデータを戻させることである。この方法は、ユーザー管理の観点からはより簡単であるが、整合性のある権限の概念を実施することがより難しくなる。

マスターデータサーバーは、２段階の権限アーキテクチャを使用する。第１段階では、マスターデータサーバーは、クライアントシステムに権限を割り当てる。第２段階では、クライアントシステムは、さらに、クライアントのユーザー或いはクライアント上で実行されている処理に権限のレベルを割り当てる。例えば、販売クライアントシステムは、販売データを変更する権限と同様に、一般的なデータと販売データを読む権限を持つことができる。他のクライアントシステムは、販売データを変更する権限を持たずに、一般的なデータと販売データを読むための権限を持つことができる。販売クライアントシステムの特定のユーザーは、一般的なデータと特定の製品に関する販売データを読む権限を与えられ得る。あるクライアント上のユーザーは、クライアントがマスターデータをアクセスする際に持っているより高位の権限レベルを持つことはできない。

上述した方法は、データがクライアントを通してアクセスされる際に使用されるものである。ユーザーがマスターデータサーバーに直接に航行するときは、マスターデータサーバー上でユーザーとしてログオンする必要がある。そのユーザーには、ユーザーの現状に基づいて、あるレベルの権限が認められる。

［マスターデータ管理の結果］
以下で、データを保存するためにマスターデータサーバーを用いたいくつかの結果を説明する。

マスターデータサーバーは多くのクライアントの要求に合致するように設計される。マスターデータソフトウェアは、クライアントサイトにおいて設定の前に知られていない属性の保存ができるように柔軟に設計される。ＳＡＰが提供するEasy Extension Workbenchを用いて、全てのマスターデータで同様の方法を用いることができる。

整合性を調べる枠組みは、クライアントがデータの整合性を調べることができるように提供される。

ソフトウェアは、マスターデータの保存が、システムの接続に応じて、局所であるいは遠隔で実行することができるように、混在したやり方で書かれる。

［原則］
表１は、中央マスターデータサーバーへの動的アクセスを支援するための原則の例を示している。

マスターデータサーバーが維持管理するマスターデータベース内の中央にマスターデータが保存されるシステムを実現することには、いくつかの危険がある。統合サーバーとマスターデータサーバーは、高い有用性（絶対安全性）を持つことが必要である。もしマスターデータサーバーが利用可能でなければ、マスターデータに基づく処理はもはや実行することができない。マスターデータサーバーの故障によって起こる損害を軽減するために、局在キャッシング機構がクライアント上に入れられる。マスターデータの誤りによって処理は停止する。従って、マスターデータのマッピングは、絶対に誤りがあってはならない。全てのオブジェクトは、正確にマッピングをし、全ての必要な属性は正確にマッピングをしなくてはならない。システム間のトランザクションの整合性は、達成するのが難しい。データは、２つの相の委任を必要としないようにモデル化されるべきである。クライアントにおけるアプリケーションのカスタム化は、調和されなくてはならない。マスターデータのモデルと実現は、全てのクライアントに特別な属性を与えることができるような方法でマスターデータを拡張する柔軟性を提供する必要がある。

マスターデータへの動的アクセスに対する処理は、ディジタル電子回路、あるいはコンピュータハードウェア、あるいはファームウェア、あるいはソフトウェア、あるいはそれらの組み合わせによって実現することができる。マスターデータへの動的アクセスのための装置は、情報手段内、例えば機械読み取り可能な保存装置、あるいはプログラム可能なプロセッサで実行する伝搬信号内で、はっきりと具現化されるコンピュータプログラム製品内で実現することができる。マスターデータへの動的アクセスのための方法の段階は、入力データ上で動作し出力を生成することによって、本発明の機能を実行する命令のプログラムを実行するプログラム可能なプロセッサによって実行することができる。マスターデータへの動的アクセスの処理は、有利なことに、データと命令をそこから受け取り、データと命令をそこへ送るように結合される少なくとも一つのプログラム可能なプロセッサと、データ保存システムと、少なくとも一つの入力装置と、少なくとも一つの出力装置とを含んだプログラム可能なシステム上で実行可能な一つあるいは二つ以上のコンピュータプログラム内で実行することができる。コンピュータプログラムは、ある動作を実行するか、ある結果を引き出すために、コンピュータ内で直接或いは間接に使用できる一組の命令である。コンピュータプログラムは、いかなる形態のプログラミング言語で書くことができ、その中には、コンパイルされたりインタープリットされた言語が含まれ、またコンピュータプログラムは、いかなる形態でも配置することができ、その中には、独立型のプログラムとして、またはモジュールや部品やサブルーチンとして、またはコンピュータ環境内で使用するのに適した他のユニットが含まれる。

命令のプログラムの実行のために適したプロセッサには、例として、汎用あるいは専用のマイクロプロセッサや、単独のプロセッサあるいは何らかの種類のコンピュータの多数のプロセッサの内の一つが含まれる。一般的に、一つのプロセッサは、読み出し専用のメモリあるいはランダムアクセスメモリあるいはその両方から、命令とデータを受け取る。コンピュータの必須要素は、命令を実行するためのプロセッサと、命令とデータを格納するための一つあるいは二つ以上のメモリとである。一般的に、コンピュータは、またデータファイルを保存するための一つあるいは二つ以上の大容量保存装置を含んでいるか、それと通信するために動作可能に結合され、該装置には、内部ハードディスクや移動可能なディスクなどの磁気ディスクと、光磁気ディスクと、光ディスクが含まれる。明白にコンピュータプログラム命令とデータを具現化するのに適した保存装置には、あらゆる形態の不揮発性メモリが含まれるが、その中には一例として、ＥＰＲＯＭやＥＥＰＲＯＭやフラッシュメモリ素子などの半導体メモリ素子や、内部ハードディスクと移動可能なディスクなどの磁気ディスクや、光磁気ディスクや、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭディスクが含まれる。プロセッサとメモリは、ＡＳＩＣ（特定用途向け集積回路）が補完したり、その中に組み込まれたりすることができる。

その種のコンピュータの一例が図１０に示され、そこでマスターデータの動的アクセスのための処理を実現するのに適した処理システム２５６のブロックが示される。システム２５６には、プロセッサ２５８と、ランダムアクセスメモリ（ＲＡＭ）２６０と、プログラムメモリ２６２（例えば、フラッシュＲＯＭのような、書き込み可能な読み出し専用メモリ（ＲＯＭ））と、ハードドライブ制御器２６４と、ビデオ制御器２６６と、プロセッサ（ＣＰＵ）バス２７０に結合された入力／出力（Ｉ／Ｏ）制御器２６８が含まれる。システム２５６は、例えばＲＯＭに予めプログラムしておくことができるし、また他のデータ源から（例えば、フロッピディスク（商標登録）やＣＤ−ＲＯＭや他のコンピュータから）プログラムをロードすることでプログラムする（また、予めプログラムする）こともできる。

ハードドライブ制御器２６４は、マスターデータソフトウェアを実行するためのプログラムを含んだ、実行可能なコンピュータプログラムを保存するのに適したハードディスク２７２へ結合される。ビデオ制御器２６６は、グラフィカルユーザーインターフェイスを表示するための表示装置２７４に結合される。Ｉ／Ｏ制御器２６８は、Ｉ／Ｏバス２７６を用いてＩ／Ｏインターフェイス２７８へ結合される。Ｉ／Ｏインターフェイス２７８は、シリアルリンクやローカルエリアネットワークや無線リンクや並列リンクなどの通信リンクを通して、データをアナログあるいはディジタルの形式で受け取りまた送る。

さらにＩ／Ｏバス２７６に結合されるのは、キーボード２８０である。代わりに、別々の接続（別々のバス）をＩ／Ｏインターフェイス２７８とキーボード２８０に対して使用することができる。マスターデータの動的アクセスの処理は、データサーバーのようなバックエンド部品を含むか、あるいはアプリケーションサーバーまたはインターフェイスサーバーのようなミドルウェア部品を含むか、あるいはグラフィカルユーザーインターフェイスやインターネットブラウザやそれらの組み合わせを持つクライアントコンピュータのようなフロントエンド部品を含むコンピュータシステム内で実現することができる。システムの部品は、いかなる形態でも、あるいは通信ネットワークのようなディジタルデータ通信の媒体によって接続することができる。通信ネットワークの例には、例えば、ローカルエリアネットワーク（“ＬＡＮ”）やワイドエリアネットワーク（“ＷＡＮ”）やインターネットが含まれる。

コンピュータシステムには、クライアントとサーバーが含まれる。クライアントとサーバーは、一般的に互いに離れており、典型的には、既述したようなネットワークを通して相互作用をする。クライアントとサーバーの関係は、それぞれのコンピュータ上で実行され、互いにクライアント−サーバー関係を持つコンピュータプログラムに基づいて発生する。

本発明は、特定の実施形態について説明してきた。他の実施形態は、添付の特許請求の範囲の範囲内にある。例えば、本発明の段階は、別の順序で実行することができ、それでも望む結果を得ることができる。

本発明の多くの実施形態を説明してきた。それでもなお、様々な変更が本発明の趣旨と範囲とから離れずに可能であることは理解されよう。例えば、統合サーバー１０９とマスターデータサーバー１１０は、物理的に同じコンピュータの中にあって良い。本発明は、二つのコンピュータ間で共有されるあらゆる種類のデータに適用でき、“マスターデータ”に限定するものではない。データは、一般的なデータあるいはアプリケーションデータで良い。従って、他の実施形態は、添付の特許請求の範囲の範囲内にある。

１００…混成システム
１０２〜１０６…クライアントシステム
１０９…統合サーバー
１１０…マスターデータサーバー
１１２…マスターデータベース
１１４…クライアント
１１６…販売アプリケーション
１１８…製造アプリケーション
１２０…製品ユーザーインターフェイス
１２４…製品サービス層
１２６…交換インターフェイス
１２８…アプリケーションＡ
１３０…アプリケーションＢ
１３２…製品ユーザーインターフェイス
１３４…製品サービス層

Claims (41)

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. 前記命令は、サーバーに、拡張可能なマークアップ言語で書かれたコードを備えるメッセージを用いてクライアントとやり取りさせるように動作可能であることを特徴とする請求項３５記載のコンピュータプログラムを保存した機械読み取り可能な媒体。

Images