(57)【特許請求の範囲】
【請求項１】
業務処理システムとデータ管理システムを備えたAPサーバと、複数のテーブルを備えたDBサーバとからなるデータ処理システムであって、
上記データ管理システムは、複数の第１のオブジェクトと、複数の第２のオブジェクトとの組合せよりなる階層状のデータ構造を備え、
上記第１のオブジェクトは、上記階層状のデータ構造の最下層よりも上層に配置されており、
これら第１のオブジェクトは、直接管理すべきものとして定義された下位のオブジェクトを保持する機能、
下位のオブジェクトに対して、当該オブジェクトが直接または間接に管理しているオブジェクト及びデータ項目を問合わせる機能、
下位のオブジェクトから返信されたオブジェクト及びデータ項目の一覧を保持する機能、
直近上位のオブジェクトから、直接または間接に管理しているオブジェクト及びデータ項目に関する問合わせがあった場合に、上記一覧に保持されたオブジェクト及びデータ項目を返信する機能、
上記業務処理システムから、型を指定したオブジェクトの取得要求が入力された場合に、上記一覧に保持されたオブジェクトの型と一致するか否かを判定する機能、
一致する場合には当該オブジェクトのアドレスを業務処理システムに出力する機能、
一致しない場合には不正な処理であることを示すメッセージを業務処理システムに出力する機能、
上記業務処理システムから、データ項目の名前を指定したデータの取得要求が入力された場合に、上記一覧に保持されたデータ項目の名前と一致するか否かを判定する機能、
一致する場合には当該データを直接管理するオブジェクトを介してデータを取得し、業務処理システムに出力する機能、
一致しない場合には不正な処理であることを示すメッセージを業務処理システムに出力する機能、
上記業務処理システムから、データ項目の名前を指定したデータの書込要求が入力された場合に、上記一覧に保持されたデータ項目の名前と一致するか否かを判定する機能、
一致する場合には当該データを直接管理するオブジェクトに対してデータの書込を指令する機能、
一致しない場合には不正な処理であることを示すメッセージを業務処理システムに出力する機能を備え、
上記第２のオブジェクトは、上記階層状のデータ構造の最下層に配置されると共に、上記DBサーバの各テーブルに一対一で対応しており、
これら第２のオブジェクトは、
(1)自己が直接管理するデータ項目の一覧を保持する機能、
(2)直近上位の第１のオブジェクトから、直接または間接に管理しているオブジェクト及びデータ項目に関する問合わせがあった場合に、上記一覧に保持されたデータ項目を返信する機能、
(3)直近上位の第１のオブジェクトから、データ項目を指定したデータの取得要求が入力された場合に、SQL文をDBサーバに発行して該当データを対応テーブルの該当項目から取得し、上記第１のオブジェクトに出力する機能、
(4)直近上位の第１のオブジェクトから、データ項目を指定したデータの書込要求が入力された場合に、SQL文をDBサーバに発行して対応テーブルの該当項目に対するデータの書込を実行する機能、
(5)上記業務処理システムから、データ項目の名前を指定したデータの取得要求が入力された場合に、上記一覧に保持されたデータ項目の名前と一致するか否かを判定する機能、
(6)一致する場合にはSQL文をDBサーバに発行し、該当データを対応テーブルの該当項目から取得し、業務処理システムに出力する機能、
(7)一致しない場合には不正な処理であることを示すメッセージを業務処理システムに出力する機能、
(8)上記業務処理システムから、データ項目の名前を指定したデータの書込要求が入力された場合に、上記一覧に保持されたデータ項目の名前と一致するか否かを判定する機能、
(9)一致する場合にはSQL文をDBサーバに発行し、対応テーブルの該当項目に対するデータの書込を実行する機能、
(10)一致しない場合には不正な処理であることを示すメッセージを業務処理システムに出力する機能、
を備えたことを特徴とするデータ処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、コンピュータのメモリ上に階層状のデータ管理構造を生成する技術に関する。
【背景技術】
【０００２】
コンピュータのメモリ上でデータを汎用的に管理する方法の一つとして、非特許文献１に示すように、ハッシュマップを利用する方法が知られている。
このハッシュマップは、Java（登録商標）言語のHashMapクラスによって提供されるものであるため、プログラマは特別なコードを書くことなく利用できる点で便利である。
【非特許文献１】HashMap (Java 2 プラットフォーム SE v1.4.0)インターネットURL:http://sdc.sun.co.jp/java/docs/j2se/1.4/ja/docs/ja/api/java/util/HashMap.html検索日：平成１９年１２月１１日
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、ハッシュマップは汎用性を備えているが故に、そこに格納されたデータを操作するに際しては固有の型を指定することができず、プログラム実行時に型チェックが効かないという問題がある。
具体的には、ハッシュマップを利用するアプリケーションプログラム側から型を特定した形で処理のリクエストが発行された場合に、本来であれば当該型が存在するか否かがデータ管理システム側でチェックされ、存在しない場合には「例外」のメッセージを返して処理を中断させるべきである。ところが、ハッシュマップでデータが管理されている場合には固有の型に基づいたチェックが機能しないため、そのまま不正な値を保持してしまう危険性があった。
【０００４】
また、アプリケーションプログラムがデータを扱う場合には、個々のデータ項目単位で処理対象を認識するよりも、一定の粒度で階層状に集約させた方が便利な場合がある。例えば、DBサーバ内においてＡテーブル、Ｂテーブル、Ｃテーブル…のようにテーブルが細分化されていたとしても、一定の業務処理を行う場合には必ずＡテーブル〜Ｃテーブルのデータが必要とされるのであれば、Ａテーブル〜Ｃテーブルに対してまとめて処理ができるようにすることが効率的である。ところが、ハッシュマップ内においては各データ項目がフラットな状態で格納されており、相互間に階層構造や入れ子構造を定義できないという問題があった。
【０００５】
上記の問題は、汎用的なハッシュマップの利用を諦め、プログラマ自身が独自の構造を備えたデータ格納領域をメモリ上に形成するようなコードを書けば解決することができる。
しかしながら、この場合には必然的にプログラマの負担が増大するデメリットが生じる。特に、データ間に階層状の集約構造を形成するためには、各データ間の上下関係を逐一辿り、データの取得や書込を実現するためにアクセッサー（ゲッター及びセッター）と称する機能を実現するためのコーディングが必要となり、階層構造の複雑化に伴い膨大な行数のコードを記述する必要が生じる。
【０００６】
この発明は、従来のデータ管理システムが抱えていた上記の問題を解決するために案出されたものであり、プログラマに過大な負担を与えることなく、データを任意の粒度で階層状に集約可能であり、プログラム実行時における型チェックも有効に機能するデータ管理技術を提供することを目的としている。
【課題を解決するための手段】
【０００７】
上記の目的を達成するため、請求項１に記載したデータ処理システムは、業務処理システムとデータ管理システムを備えたAPサーバと、複数のテーブルを備えたDBサーバとからなるシステムであって、上記データ管理システムは、複数の第１のオブジェクトと、複数の第２のオブジェクトとの組合せよりなる階層状のデータ構造を備え、上記第１のオブジェクトは、上記階層状のデータ構造の最下層よりも上層に配置されており、これら第１のオブジェクトは、直接管理すべきものとして定義された下位のオブジェクトを保持する機能、下位のオブジェクトに対して、当該オブジェクトが直接または間接に管理しているオブジェクト及びデータ項目を問合わせる機能、下位のオブジェクトから返信されたオブジェクト及びデータ項目の一覧を保持する機能、直近上位のオブジェクトから、直接または間接に管理しているオブジェクト及びデータ項目に関する問合わせがあった場合に、上記一覧に保持されたオブジェクト及びデータ項目を返信する機能、上記業務処理システムから、型を指定したオブジェクトの取得要求が入力された場合に、上記一覧に保持されたオブジェクトの型と一致するか否かを判定する機能、一致する場合には当該オブジェクトのアドレスを業務処理システムに出力する機能、一致しない場合には不正な処理であることを示すメッセージを業務処理システムに出力する機能、上記業務処理システムから、データ項目の名前を指定したデータの取得要求が入力された場合に、上記一覧に保持されたデータ項目の名前と一致するか否かを判定する機能、一致する場合には当該データを直接管理するオブジェクトを介してデータを取得し、業務処理システムに出力する機能、一致しない場合には不正な処理であることを示すメッセージを業務処理システムに出力する機能、上記業務処理システムから、データ項目の名前を指定したデータの書込要求が入力された場合に、上記一覧に保持されたデータ項目の名前と一致するか否かを判定する機能、一致する場合には当該データを直接管理するオブジェクトに対してデータの書込を指令する機能、一致しない場合には不正な処理であることを示すメッセージを業務処理システムに出力する機能を備え、上記第２のオブジェクトは、上記階層状のデータ構造の最下層に配置されると共に、上記DBサーバの各テーブルに一対一で対応しており、これら第２のオブジェクトは、(1)自己が直接管理するデータ項目の一覧を保持する機能、(2)直近上位の第１のオブジェクトから、直接または間接に管理しているオブジェクト及びデータ項目に関する問合わせがあった場合に、上記一覧に保持されたデータ項目を返信する機能、(3)直近上位の第１のオブジェクトから、データ項目を指定したデータの取得要求が入力された場合に、SQL文をDBサーバに発行して該当データを対応テーブルの該当項目から取得し、上記第１のオブジェクトに出力する機能、(4)直近上位の第１のオブジェクトから、データ項目を指定したデータの書込要求が入力された場合に、SQL文をDBサーバに発行して対応テーブルの該当項目に対するデータの書込を実行する機能、(5)上記業務処理システムから、データ項目の名前を指定したデータの取得要求が入力された場合に、上記一覧に保持されたデータ項目の名前と��致するか否かを判定する機能、(6)一致する場合にはSQL文をDBサーバに発行し、該当データを対応テーブルの該当項目から取得し、業務処理システムに出力する機能、(7)一致しない場合には不正な処理であることを示すメッセージを業務処理システムに出力する機能、(8)上記業務処理システムから、データ項目の名前を指定したデータの書込要求が入力された場合に、上記一覧に保持されたデータ項目の名前と一致するか否かを判定する機能、(9)一致する場合にはSQL文をDBサーバに発行し、対応テーブルの該当項目に対するデータの書込を実行する機能、(10)一致しない場合には不正な処理であることを示すメッセージを業務処理システムに出力する機能を備えたことを特徴としている。
【発明の効果】
【００１１】
この発明に係るデータ処理システムの場合、APサーバのデータ管理システムが、複数の第１のオブジェクトと複数の第２のオブジェクトとの組合せよりなる階層状のデータ構造を備えており、最下層よりも上層に配置される第１のオブジェクトが、それぞれ下位のオブジェクトを辿って自己の配下に存在するオブジェクトの構成を把握すると共に、その情報を上位のオブジェクトに伝達する機能を備えており、また、最下層に配置され、DBサーバの各テーブルに一対一で対応した複数の第２のオブジェクトが、それぞれ自己が直接管理するデータ項目の一覧を直近上位の第１のオブジェクトに伝達する機能を備えているため、起動と同時に自動的に階層状のデータ管理構造が実現されることとなる。このためプログラマは、各第１のオブジェクトのコーディングに際し、それぞれが直接管理すべき下位のオブジェクトを定義するだけで済み、一々アクセッサーをコーディングする手間から解放される。
【００１２】
しかも、各第１のオブジェクトは業務処理システムから型指定されたオブジェクトや名前指定された項目が存在するか否かを判定する機能を備えており、各第２のオブジェクトは業務処理システムから名前指定された項目が存在するか否かを判定する機能を備えているため、プログラム実行時における型チェック及び名前チェックが有効に機能することとなる。
【００１３】
また、業務処理システムが任意の階層の第１のオブジェクトに対してデータの処理を依頼した場合、当該第１のオブジェクトが自己の配下に存在するオブジェクトを通じて処理を実行する仕組みを備えているため、業務処理システムはデータの細かい構造を認識することなく、一定の粒度で包括的な処理を指示することが可能となる。
この結果、データの構成に変更が生じた場合であっても、業務処理システム用のプログラムについて修正を行う必要がなく、保守性の向上に資する。
【発明を実施するための最良の形態】
【００１４】
図１は、この発明に係るデータ管理システムを含んだデータ処理システム10の全体構成図であり、このデータ処理システム10は、複数のAPサーバ12と、DBサーバ14と、ロードバランサ（負荷分散装置）16とを備えている。
ロードバランサ16と各APサーバ12間、及び各APサーバ12とDBサーバ14間はネットワークによって接続されている。
また、各APサーバ12に対しては、イントラネットやインターネット等のネットワーク及びロードバランサ16を介して多数のクライアント端末20が接続されている。
【００１５】
DBサーバ14は、DB管理システム（DBMS）22と、業務処理用の各種テーブル24を備えている。
DB管理システム22は、各テーブル24に格納されたデータの入出力、更新、および所定の演算などを行う。
【００１６】
各APサーバ12は、業務処理システム26と、データ管理システム28とを備えている。
上記の業務処理システム26及びデータ管理システム28は、APサーバ12のCPUが対応のアプリケーションプログラムに従って必要な処理を実行することによって実現される。
【００１７】
ロードバランサ16は、クライアント端末20から送信されたリクエストを、各APサーバ12にかかっている負荷に応じて分散する役割を果たす。
【００１８】
クライアント端末20は、ＰＣ等のコンピュータよりなり、OSの他に、Webブラウザプログラムや専用のアプリケーションプログラムがセットアップされている。
【００１９】
業務処理システム26は、各クライアント端末20から送信された業務データの処理要求を受け付け、データ管理システム28を介してDBサーバ14から必要なデータを取得してクライアント端末20に送信したり、データに必要な加工を施してDBサーバ14に登録する機能を果たす。
【００２０】
データ管理システム28は、Java（登録商標）等のオブジェクト指向言語によってコーディングされたプログラム部品（クラス）をインスタンス化させた複数のオブジェクトによって形成されている。
図２は、このデータ管理システム28の構造を示す概念図であり、APサーバ12のメモリ上にデータの階層構造が形成されている様子を模式的に示している。
【００２１】
このデータ構造は、M_ABCD、M_AB、M_CD、M_DEからなる第１のオブジェクトと、R_A、R_B、R_C、R_D、R_Eからなる第２のオブジェクトを備えている。
【００２２】
まず、最下層（第１層）に位置するR_A、R_B、R_C、R_D、R_Eの第２のオブジェクトは、DBサーバのテーブルA〜Eに１：１で対応しており、各テーブルのデータ項目を保持している。
すなわち、R_Aは「a1, a2, a3」のデータ項目を、R_Bは「b1, b2」のデータ項目を、R_Cは「c1, c2, c3」のデータ項目を、R_Dは「d1, d2, d3, d4」のデータ項目を、R_Eは「e1, e2, e3」のデータ項目をそれぞれ内部で直接管理している。
【００２３】
これに対し、第２層に位置するM_AB、M_CD、M_DEの第１のオブジェクトは、直接的にはテーブル構造を認識してはおらず、自己が管理すべき第１層のオブジェクトのみを直接的に管理している。
すなわち、M_ABはR_A及びR_Bを、M_CDはR_C及びR_Dを、M_DEはR_D及びR_Eをそれぞれ管理すべきオブジェクトとして保持している。
【００２４】
第３層に位置するM_ABCDの第１のオブジェクトも、直接的にはテーブル構造を認識してはおらず、自己が管理すべき第２層のオブジェクトのみを直接的に認識している。
すなわち、M_ABCDは、M_AB及びM_CDを直接管理すべきオブジェクトとして保持している。
【００２５】
上記のオブジェクトの中、M_AB、M_CD、M_DE、M_ABCDの第１のオブジェクトは、それぞれBase Object Model Rigidという共通のスーパークラスを継承している。
このBase Object Model Rigidクラスには、以下の機能がコーディングされている。
(1)自己が直接管理すべきものとして定義された下位のオブジェクトを保持する機能。
(2)自己が直接管理すべき下位のオブジェクトに対して、当該オブジェクトが直接または間接に管理しているオブジェクト及びデータ項目を問い合わせる機能。
(3)自己が直接管理すべき下位のオブジェクトから返信されたオブジェクト及びデータ項目を一覧として保持する機能。
(4)上位のオブジェクトから自己が直接または間接に管理しているオブジェクト及びデータ項目の問合わせがあった場合に、自己が保持しているオブジェクト及びデータ項目のアドレスを回答する機能。
(5)外部プログラムから、型を指定したオブジェクトの取得要求が入力された場合に、上記一覧に保持されたオブジェクトの型と一致するか否かを判定する機能。
(6)一致する場合には当該オブジェクトのアドレスを外部プログラムに出力する機能。
(7)一致しない場合には「例外」メッセージを返して処理を中断させる機能。
(8)外部プログラムから、データ項目の名前を指定したデータの取得要求が入力された場合に、上記一覧に保持されたデータ項目の名前と一致するか否かを判定する機能。
(9)一致する場合には当該データを直接管理するオブジェクトを介してデータを取得し、外部プログラムに出力する機能。
(10)一致しない場合には「例外」メッセージを返して処理を中断させる機能。
(11)外部プログラムから、データ項目の名前を指定したデータの書込要求が入力された場合に、上記一覧に保持されたデータ項目の名前と一致するか否かを判定する機能。
(12)一致する場合には当該データを直接管理するオブジェクトに対してデータの書込を指令する機能。
(13)一致しない場合には「例外」メッセージを返して、処理を中断させる機能。
上記のように、M_AB、M_CD、M_DE、M_ABCDの各オブジェクトはBase Object Model Rigidを継承しているため、これら(1)〜(13)の機能を共通に具備している。
【００２６】
これに対して、第１層を構成するR_A、R_B、R_C、R_D、R_Eの第２のオブジェクトはBase Object Model Rigidを継承することなく、以下の機能を備えるようにコーディングされている。
(1)自己が直接管理するデータ項目の一覧を保持する機能。
(2)直近上位の第１のオブジェクトから、直接または間接に管理しているオブジェクト及びデータ項目に関する問合わせがあった場合に、上記一覧に保持されたデータ項目を返信する機能。
(3)直近上位の第１のオブジェクトから、データ項目を指定したデータの取得要求が入力された場合に、SQL文をDBサーバ14に発行し、該当データを対応テーブルの該当項目から取得し、上記第１のオブジェクトに出力する機能。
(4)直近上位の第１のオブジェクトから、データ項目を指定したデータの書込要求が入力された場合に、SQL文をDBサーバ14に発行して対応テーブルの該当項目に対するデータの書込を実行する機能。
(5)外部プログラムから、データ項目の名前を指定したデータの取得要求が入力された場合に、上記一覧に保持されたデータ項目の名前と一致するか否かを判定する機能。
(6)一致する場合にはSQL文をDBサーバ14に発行し、該当データを対応テーブルから取得して外部プログラムに出力する機能。
(7)一致しない場合には、「例外」メッセージを返して、処理を中断させる機能。
(8)外部プログラムから、データ項目の名前を指定したデータの書込要求が入力された場合に、上記一覧に保持されたデータ項目の名前と一致するか否かを判定する機能。
(9)一致する場合にはSQL文をDBサーバ14に発行し、対応テーブルの該当項目に対するデータの書込を実行する機能。
(10)一致しない場合には、「例外」メッセージを返して、処理を中断させる機能。
ただし、(3)、(4)、(6)及び(9)におけるSQL文の発行に係る機能については、他のプログラムモジュールに委譲することもできる。
【００２７】
上記の各オブジェクトの中、上位のオブジェクトとの接続関係を備えたオブジェクトは、それぞれ共通のインターフェイスとしてIobject Model Rigidを実装している。
【００２８】
つぎに、図３及び図４のフローチャートに従い、データ管理システム28による処理手順について説明する。
まず、データ管理システム28の起動と同時に、M_AB、M_CD、M_DE、M_ABCDの第１のオブジェクトは、それぞれ自己が直接管理している下位のオブジェクトに対し、それらが直接または間接に管理しているオブジェクト及びデータ項目を問い合わせる（Ｓ10）。
【００２９】
例えば、第３層目に位置するM_ABCDが直接管理しているオブジェクトはM_ABとM_CDであるため、M_ABCDはM_AB及びM_CDに対して上記の問合わせを行う。
同時に、第２層目に位置するM_ABが直接管理しているオブジェクトはR_AとR_Bであるため、M_ABはR_A及びR_Bに対して上記の問合わせを行う。
【００３０】
末端のR_Aは管理しているオブジェクトはなく、データ項目のみを管理しているため、M_ABに対してデータ項目である「a1, a2, a3」のみを返す。
また、末端のR_Bも管理しているオブジェクトはなく、データ項目のみを管理しているため、M_ABに対してデータ項目である「b1, b2」のみを返す。
【００３１】
これに対しM_ABは、「a1, a2, a3」及び「b1, b2」を自己が間接的に管理するデータ項目として内部に保持する（Ｓ12）。
同時にM_ABは、上位のオブジェクトであるM_ABCDに対し、自己が直接管理しているオブジェクトがR_A及びR_Bであること、またR_Aがデータ項目「a1, a2, a3」を、R_Bがデータ項目「b1, b2」を直接管理していることを伝達する（Ｓ14）。
【００３２】
同様に、M_CDも「c1, c2, c3」及び「d1, d2, d3, d4」を自己が間接的に管理するデータ項目として内部に保持する（Ｓ12）と共に、M_ABCDに対し自己が直接管理しているオブジェクトがR_C及びR_Dであること、またR_Cがデータ項目「c1, c2, c3」を、R_Dがデータ項目「d1, d2, d3, d4」を直接管理していることが伝達される（Ｓ14）。
【００３３】
M_ABCDは、M_AB及びM_CDから返信された回答データを内部に保持する（Ｓ12）。
【００３４】
一方、M_DEは第２階層目に位置するオブジェクトではあるが、自己の上位に他のオブジェクトが存在しない最上位のオブジェクトであるため、自己が直接管理しているR_D及びR_Eに対して上記の問合わせを行い、その回答である「d1, d2, d3, d4」及び「e1, e2, e3」を内部に保持する。
【００３５】
以上のように、各オブジェクトは、自己が直接管理している下位のオブジェクトに対して、当該オブジェクトが直接または間接に管理しているオブジェクト及びデータ項目を問い合わせ、その回答データを自己が間接的に管理するオブジェクト及びデータ項目として内部に保持すると同時に、自己の上位に位置する他のオブジェクトからの同様の問合わせに対して、自己が直接または間接に管理しているオブジェクト及び／またはデータ項目を回答する機能を備えている。
【００３６】
ここで、外部プログラムに基づく業務処理システム26から、型を指定したオブジェクトの取得命令をデータ管理システム28が受信すると（Ｓ16）、型の一致／不一致が対応のオブジェクトにおいて判定される（Ｓ18）。
【００３７】
例えば、業務処理システム26から「M_ABCD.getOM(M_AB.class)」という命令がデータ処理システム28に対して出力された場合、M_ABCDに対して「M_AB型のオブジェクトを取得せよ」という意味内容を表している。
この場合、M_ABというオブジェクトは存在しており、対応する型は確かに存在するため、M_ABCDはYESの判定を下す（Ｓ18）。
つぎに、M_ABCDはM_ABのアドレス（参照）を業務処理システム26に送信する（Ｓ22）。
【００３８】
なお、仮に業務処理システム26からM_ABCDに対してM_DEの取得命令が出力された場合、M_ABCDはM_DEを直接にも間接にも管理していないため、型の不一致と判定し（Ｓ18／No）、「例外」のメッセージを業務処理システム26に返し（Ｓ20）、以後の処理を拒絶する。
【００３９】
M_ABCDからM_ABのアドレスを取得し、a1項目を直接管理している第２のオブジェクトがR_Aであり、その直近上位の第１のオブジェクトがM_ABであることを認識した業務処理システム26から、「M_AB.getByName("a1");」の命令（a1という項目の名前を指定したデータの取得命令）が送信されると、これを受けたM_ABは（Ｓ24）、項目の名前が一致することを確認した後（Ｓ26／Y）、配下のR_Aを介してa1項目のデータを取得し、業務処理システム26に送信する（Ｓ30）。
これに対し、該当の項目が存在しない場合（Ｓ26／N）、M_ABは「例外」のメッセージを業務処理システム26に返し（Ｓ28）、以後の処理を拒絶する。
【００４０】
つぎに、業務処理システム26からa1項目に係るデータの書込を命じる「M_AB.setByName ("a1");」の命令が送信されると、これを受けたM_ABは（Ｓ32）、項目の名前が一致することを確認した後（Ｓ34／Y）、配下のR_Aに対してデータの書込を依頼する（Ｓ38）。
該当の項目が存在しない場合（Ｓ34／N）、M_ABは「例外」のメッセージを業務処理システム26に返し（Ｓ36）、以後の処理を拒絶する。
【００４１】
業務処理システム26は、データ管理システム28を構成する任意のオブジェクトに対して、型を指定したオブジェクトの取得命令を発することができる。
例えば、業務処理システム26から「M_DE.getOM(R_D.class);」という命令がデータ処理システム28に対して出力された場合、M_DEに対して「R_D型のオブジェクトを取得せよ」という意味内容を表している。
この場合も、R_Dというオブジェクトは存在しており、対応する型は確かに存在するため、M_DEはYESの判定を下す（Ｓ18）。
つぎに、M_DEはR_Dのアドレスを業務処理システム26に送信する（Ｓ22）。
【００４２】
あるいは、業務処理システム26から「M_CD.setByName ("c1");」という項目の名前を指定した書込命令が出力された場合、これを受けたM_CDは（Ｓ32）、項目の名前が一致することを確認した後（Ｓ34／Y）、配下のR_Cに対してデータの書込を依頼する（Ｓ38）。
【００４３】
第２のオブジェクトであるR_A、R_B、R_C、R_D、R_Eは、上層に位置する第１のオブジェクトからデータ項目を指定したデータの取得命令が出力されると、必要なSQL文をDBサーバ14に発行してデータを取得した後、依頼元の第１のオブジェクトに返す。
また、第１のオブジェクトから項目とデータを指定した書込命令が出力されると、第２のオブジェクトは必要なSQL文をDBサーバ14に発行してデータの書込を行う。
【００４４】
業務処理システム26は、第２のオブジェクトであるR_A、R_B、R_C、R_D、R_Eに対して、項目の名前を指定したデータの取得命令を出力することもできる。
この場合、第２のオブジェクトは項目の名前が一致することを確認した上で、必要なデータをDBサーバ14の該当テーブルから取得して、業務処理システム26に送信する。
また、業務処理システム26はR_A、R_B、R_C、R_D、R_Eに対して、項目の名前及びデータを指定した書込命令を出力することもできる。
この場合も、第２のオブジェクトは項目の名前が一致することを確認した上で、DBサーバ14に対しデータの書込を依頼する。
【００４５】
上記のデータ管理システム28は、データの階層構造を担うM_ABCD、M_AB、M_CD、M_DEの各オブジェクトが、共通のスーパークラスであるBase Object Model Rigidを継承することによって実現される仕組みであるため、プログラマはデータの階層構造を形成するためのコーディングや、各階層を辿ってデータを取り出したり書き込むためのコーディングから解放される。
すなわち、プログラマがBase Object Model Rigidを継承して各ノードの子クラスを作成するに際し、当該第１のオブジェクトが直接管理すべき下位のオブジェクトを定義だけしておけば、あとは各オブジェクトが上下のオブジェクトとメッセージを交換し合い、自動的に階層構造が形成されることとなる。
【００４６】
しかも、第１のオブジェクトは業務処理システム26から型指定されたオブジェクトが存在するか否かを判定する型チェック機能、及び名前指定された項目が存在するか否かを判定する名前チェック機能を備えているため、プログラム実行時における型チェックや名前チェックが有効に機能することとなる。
また、業務処理システム26が任意の階層のオブジェクトに対してデータの処理を依頼した場合、当該オブジェクトが自己の配下に存在するオブジェクトを通じて処理を実行する仕組みを備えているため、業務処理システム26側はデータを格納するテーブル側の細かい仕様や構造を認識することなく、一定の粒度で包括的な処理を行うことが可能となる。この結果、テーブル構成に変更が生じた場合であっても、業務処理システム26のプログラムについて修正を行う必要がない。
【００４７】
これに対し、第１層を構成するR_A、R_B、R_C、R_D、R_Eの第２のオブジェクトは、自己よりも下層のオブジェクトが存在せず、「自己が直接管理すべき下位のオブジェクトに対して、当該オブジェクトが直接または間接に管理しているオブジェクト及びデータ項目を問い合わせる機能」及び「自己が直接管理すべき下位のオブジェクトから返信されたオブジェクト及びデータ項目を保持する機能」が不要であるため、M_ABCD、M_AB、M_CD、M_DEの各オブジェクトのようにBase Object Model Rigidを継承してはいない。
【００４８】
また、R_A、R_B、R_C、R_D、R_Eの第２のオブジェクトは、具体的なテーブル構成と対応している必要があるため、プログラマはテーブルとの対応関係を個別に定義する必要がある。
ただし、上記のようにR_A、R_B、R_C、R_D、R_Eの各オブジェクトが、テーブルA〜Eに一対一で対応している場合には、公知のテーブル定義自動生成ツールを用いることにより、その部分のコーディングを自動化することが可能となる。
【００４９】
また、上記の通りDBサーバ14に対してSQL文を発行する機能を別のプログラムモジュールに委譲することもできる。
【図面の簡単な説明】
【００５０】
【図１】この発明に係るデータ管理システムを含むデータ処理システムの全体構成を示す図である。
【図２】データ管理システムの構造を示す概念図である。
【図３】データ管理システムによる処理手順を示すフローチャートである。
【図４】データ管理システムによる処理手順を示すフローチャートである。
【符号の説明】
【００５１】
10  データ処理システム
12  APサーバ
14  DBサーバ
16  ロードバランサ
20  クライアント端末
22  DB管理システム
24  テーブル
26  業務処理システム
28  データ管理システム
【図１】
0005044389.tif 000002
【図２】
0005044389.tif 000003
【図３】
0005044389.tif 000004
【図４】
0005044389.tif 000005