JP4741689B2 - データ処理方法、データ処理装置およびデータ処理プログラム - Google Patents

Description

本発明は、ＲＤＢＭＳ(Relational Data Base Management System)において、複数の組織で共有している情報（テーブルなど）に、特定の組織が参照および更新する固有項目を追加するための技術などに関する。

複数の組織で共有するデータを管理するシステムとして、ＲＤＢＭＳがある。例えば、ある企業の情報システムにおいて、顧客企業の企業情報をＲＤＢＭＳに格納し、その企業に所属する組織（部署など）の間で企業情報を共有することがある。企業情報は、複数の項目（列）を持ったテーブルとしてＲＤＢＭＳに格納され、そのテーブルへ業務ＡＰ（業務アプリケーション（プログラム））がアクセスし、企業情報を参照または更新する。項目の例としては、企業名や所在地などが考えられる。

このようなデータ処理システムにおいて、組織ごとに異なる項目を利用したい場合ある。図２は、そのような状況の例として、顧客企業情報管理システムでの例を示している。
顧客企業情報管理システム１００は、営業部門や調達部門などの社内組織の間で、顧客企業情報１３０を共有する。しかし、部門によって利用したい項目が異なり、営業部門の顧客管理アプリケーション（営業部門顧客管理ＡＰ１１０）は、情報１１１を参照し、企業の営業担当者やその連絡先（営業担当連絡先）を格納する項目を利用する。一方、調達部門の発注アプリケーション（調達部門発注ＡＰ１２０）は、情報１２１を参照し、企業が調達先として適当か判断するために、品質保証に関する国際標準であるＩＳＯ（International Organization for Standardization）９００１の認可状況や認定番号といった項目を利用する。

ここで、全ての組織の間で共有する項目を共通項目、特定の組織のみで利用する項目を固有項目と呼ぶことにする。図２の例では、企業名や所在地は共通項目である。営業担当者や営業担当連絡先は、営業部門のみが利用する固有項目である。

なお、業務ＡＰ（ここでは、営業部門顧客管理ＡＰ１１０、調達部門発注ＡＰ１２０）と組織の関係は、必ずしも１対１ではない。業務ＡＰを利用する組織がただ１つの場合もあれば、業務ＡＰを利用する組織が複数ある場合もある。前者の場合は、業務ＡＰは特定の組織の固有項目を利用する。後者の場合は、業務ＡＰの利用者が所属する組織の固有項目を利用することになり、１つの業務ＡＰでも、利用者によって異なる固有項目を使うことになる。

従来のＲＤＢＭＳにおいて、このような固有項目の管理を実現する方法として、次の３つの方法が知られている。
（方法１）組織毎に固有項目を格納する表を用意する方法（図２５で後述）
（方法２）組織毎に共通項目と固有項目の両方を格納する表を用意する方法（図２６で後述）
（方法３）共通項目と組織毎の固有項目を全て１つにまとめた表を用意する方法（図２７で後述）

この３つの方法は、非特許文献１の「Ｈｉｂｅｒｎａｔｅ（ハイバネート） イン アクション」の3.6節「クラス継承のマッピング」において、広く使われているオブジェクト／リレーショナルマッピングツールであるＨｉｂｅｒｎａｔｅで提供されている３つのマッピングパターンとして紹介されている。

非特許文献１における「3.6.3 サブクラスごとに１つのテーブル(Table per subclass)」が方法１に対応し、「3.6.1 具象クラスごとに１つのテーブル(Table per concrete class)」が方法２に対応し、「3.6.2 クラス階層ごとに１つのテーブル(Table per class hierarchy)」が方法３に対応する。

このとき、マッピングするオブジェクトのクラス構造（論理的なデータ構造）としては、共通項目を親クラスの属性として、組織毎の固有項目を組織毎のサブクラスの属性とするのが一般的である。図２に示す例でのクラス構造の例を図２４に示す。共通項目を属性に持つ親クラスが全社共通企業属性２４０１であり、固有項目を属性に持つサブクラスが営業部門固有企業属性２４０２と調達部門固有企業属性２４０３である。営業部門固有企業属性２４０２は営業部門が利用する固有項目を属性に持ち、調達部門固有企業属性２４０３は調達部門が利用する固有項目を属性に持つ。

これらを前提に、図２５〜２７について説明する。図２５では、共通項目が全社共通テーブル２５０１に格納され、営業部門が利用する固有項目が営業部門固有テーブル２５０２に格納され、調達部門が利用する固有項目が調達部門固有テーブル２５０３に格納されている。

図２６では、共通項目２６０２と営業部門が利用する固有項目が営業部門固有テーブル２６０１に格納され、共通項目２６１２と調達部門が利用する固有項目が調達部門固有テーブル２６１１に格納されている。
図２７では、共通項目２７１１と、営業部門固有項目２７１２と、調達部門固有項目２７１３とが、単一の全社共通テーブル２７０１に格納されている。

クリスチャン・バウワー、外１名 著、倉橋 央、外１名 監訳、「Ｈｉｂｅｒｎａｔｅ（ハイバネート） イン アクション」、ソフトバンク クリエイティブ、２００６年１月１５日，ｐ．１２１−１３１

前記した従来の方法（方法１〜３）では、ある組織の変更（例えば、新たな組織の追加など）が、他の組織の業務ＡＰやデータ処理システムの運用に影響するという問題がある。
例えば、方法１や方法２の場合、組織の追加に伴って固有項目を格納する表の追加が必要となり、データ処理システムの運用にも影響する。表が増えることにより、データをバックアップするためのバッチ処理や運用作業手順などを変更しなければならないためである。

また、方法１や方法２の別の課題として、固有項目を変更（追加、削除または内容変更）するとき、その組織の全ての業務ＡＰのトランザクションを中断しなければならないという課題もある。固有項目の追加などをするには、その組織の業務ＡＰが利用する固有項目を格納する表の構造を変更しなければならないためである。

方法３の場合、ある組織のための固有項目を変更するには、全ての組織の業務ＡＰのトランザクションを中断しなければならず、他の組織にも影響する。固有項目を変更するには、全ての組織の業務ＡＰが利用する単一の表の構造を変更しなければならないためである。
さらに、方法３の場合、表の列数が、共通項目と全ての組織の固有項目の合計となるため、列数が多くなりやすく、ＲＤＢＭＳで許容される列数の上限に達してしまうことがある。列数が当該上限に達すると、いずれの組織もそれ以上固有項目を追加することができなくなってしまう。

本発明は、これらの問題に鑑みてなされたものであり、データ処理システムにおいて、ある組織が利用する固有項目を変更したときに他の組織やデータ処理システムの運用に与える影響を小さくすることを課題とする。

前記課題を解決するために、本発明は、複数の組織が共有する情報を格納するＲＤＢＭＳを有するデータ処理装置と、組織のいずれかがデータ処理装置のＲＤＢＭＳに格納された情報を使用する際に用いられデータ処理装置と通信可能に接続される業務アプリケーション実行装置と、を備えるデータ処理システムにおけるデータ処理装置である。
情報は、ＩＤによって識別され、複数のデータ項目から構成されている。
データ処理装置は、ＩＤと、複数の組織に共通のデータ項目である共通項目の値である共通項目値と、を格納する共通項目情報、および、ＩＤと、組織の名前である組織名と、組織名に対応する組織が参照・更新するデータ項目である固有項目の名前である固有項目名と、固有項目の値である固有項目値と、を格納する固有項目情報、をＲＤＢＭＳに記憶しており、業務アプリケーション実行装置から入力された、共通項目と固有項目とが区別なく混在して指定された出力項目名と、共通項目と固有項目とが区別なく混在した検索条件式と、組織名と、に基づいて、共通項目と固有項目とが混在したレコードを業務アプリケーション実行装置に出力するテーブル仮想化部を備えている。
テーブル仮想化部は、入力された出力項目名および検索条件式に含まれるデータ項目が共通項目であるか固有項目であるかの項目種別を、共通項目情報を参照して判定する項目種別判定処理部と、項目種別判定処理部で固有項目と判定されたデータ項目について、固有項目情報における組織名と固有項目名が、入力された組織名および固有項目と判定されたデータ項目の固有項目名と一致する部分を検索する固有項目検索条件式を作成する固有項目参照変換処理部と、入力された検索条件式から、項目種別判定処理部で共通項目と判定されたデータ項目を残した共通項目検索条件式を作成する共通項目参照変換処理部と、共通項目検索条件式を用いて共通項目情報から取り出したレコードと、当該レコードと同一ＩＤを持ち、かつ固有項目検索条件式を用いて固有項目情報から取り出した固有項目値とを、出力項目名に基づいて連結して、共通項目と固有項目とが混在したレコードとして出力するレコード出力処理部と、を備える。

本発明によれば、データ処理システムにおいて、ある組織が利用する固有項目を変更したときに他の組織やデータ処理システムの運用に与える影響を小さくすることができる。

第１の実施形態のデータ処理システムの構成図である。 顧客企業情報管理システムを含む説明図である。 データ処理システムのハードウェアを含む構成を示す図である。 共通項目表および固有項目表管理表の一例を示す図である。 固有項目表の例を示す図である。 参照処理部の処理で使われる項目一覧表と仮想行の例を示す図である。 参照処理部の参照処理の流れを示すフローチャートである。 項目種別の判定処理の流れを示すフローチャートである。 固有項目の参照の変換処理の流れを示すフローチャートである。 共通項目の参照の変換処理の流れを示すフローチャートである。 項目一覧表が図６に示す内容の場合に、検索条件式を共通項目の参照の変換処理で実行したときの例を示す図である。 レコード出力処理の流れを示すフローチャートである。 追加処理の流れを示すフローチャートである。 共通項目表が図４に示す内容の場合に、追加処理でレコードを入力したときの処理の例を示す図である。 更新処理の流れを示すフローチャートである。 共通項目レコード更新処理の流れを示すフローチャートである。 固有項目レコード更新処理の流れを示すフローチャートである。 第２の実施形態のデータ処理システムの構成図である。 固有項目管理表の一例を示す図である。 固有項目定義部で固有項目定義を追加するときの処理の流れを示すフローチャートである。 ビュー表定義生成部のビュー表定義生成処理の流れを示すフローチャートである。 ビュー表定義生成処理で出力されるＳＱＬ文およびその構造の例を示す図である。 ビュー表定義生成処理で出力されるＳＱＬ文およびその構造の例を示す図である。 クラス構造の例を示す図である。 サブクラスごとに１つのテーブルを割り当てたときのテーブル構成の例を示す図である。 具象クラスごとに１つのテーブルを割り当てたときのテーブル構成の例を示す図である。 クラス階層ごとに１つのテーブルを割り当てたときのテーブル構成の例を示す図である。 テーブル仮想化部の構成を示す図である。

以下、本発明を実施するための形態（以下、実施形態という。）について、図面を参照（言及図以外も適宜参照）しながら説明する。

（第１の実施形態）
図１に示すように、第１の実施形態のデータ処理システム１００００は、データ処理装置２００、業務アプリケーション実行装置２５０，２６０および２７０を備えて構成され、それらはネットワーク２４０を介して相互に接続される。
業務アプリケーション実行装置２５０，２６０および２７０は、データ処理装置２００上のデータを参照または更新するためのアプリケーションプログラムである業務アプリケーション２５１，２６１および２７１をそれぞれ備えている。

データ処理装置２００は、業務アプリケーション２５１，２６１および２７１から参照または更新されるデータを管理するＲＤＢＭＳ２３０と、組織ごとに異なる固有項目を持った仮想テーブルのデータを参照または更新する手段を業務アプリケーション２５１，２６１および２７１に提供するテーブル仮想化部２０１と、を備えている。

ＲＤＢＭＳ２３０は、ＳＱＬ（Structured Query Language）インターフェイス部２３１と記憶装置２１０（記憶部）とを含む。ＳＱＬインターフェイス部２３１は、業務アプリケーション２５１，２６１および２７１にデータを参照または更新するためのインターフェイスとして、ＳＱＬを提供する。ＳＱＬインターフェイス部２３１に接続する手段として、ＯＤＢＣ（Open Database Connectivity）やＪＤＢＣ（Java（登録商標）プログラムからデータベースにアクセスするためのインターフェイス）などが広く使われている。なお、テーブル仮想化部２０１が、この記憶装置２１０上の表にアクセスするためにＳＱＬインターフェイス部２３１を使ってもよい。

記憶装置２１０は、複数の組織で共有する共通項目の値を格納する共通項目表２１１（共通項目情報）、組織固有の固有項目の値を格納し、固有項目の値の型ごとに異なる表を含む固有項目表２２０（固有項目情報）、固有項目表２２０と型の関係を格納する固有項目表管理表２１２（固有項目情報管理情報）を含む。

ＶＡＲＣＨＡＲ型固有項目表２２１は、ＶＡＲＣＨＡＲ型（可変長文字列型）の固有項目の値を格納する。同様に、ＩＮＴ型固有項目表２２２およびＤＡＴＥ型固有項目表２２３は、それぞれＩＮＴ型（数値型）およびＤＡＴＥ型（日付型）の固有項目の値を格納する。なお、これらの型以外の固有項目表を含んでもよい。

次に、データ処理システム１００００のハードウェア構成などについて説明する。図３（業務アプリケーション実行装置２５０，２６０および２７０のハードウェア構成は同様なので、代表して業務アプリケーション実行装置２５０について図示）に示すように、データ処理装置２００は、ＣＰＵ（Central Processing Unit）３１１、主記憶装置３００、二次記憶装置３１０、及び通信インターフェイス３１２を備え、それらはバス３１３によって相互に接続される。

主記憶装置３００は、ＣＰＵ３１１によって実行されるテーブル仮想化プログラム３０１およびＲＤＢＭＳプログラム３０２を含む。テーブル仮想化プログラム３０１は、テーブル仮想化部２０１を含む。ＲＤＢＭＳプログラム３０２は、ＲＤＢＭＳ２３０を含み、さらに、ＲＤＢＭＳ２３０はＳＱＬインターフェイス部２３１を含む。

二次記憶装置３１０は、図１の記憶装置２１０に相当する。
通信インターフェイス３１２は、ネットワーク２４０に接続する手段である。
業務アプリケーション実行装置２５０は、ＣＰＵ３２１、主記憶装置３２２、二次記憶装置３２３、および通信インターフェイス３２５を備え、それらはバス３２４によって相互に接続される。
主記憶装置３００は、ＣＰＵ３２１によって実行される業務アプリケーション２５１を記憶する。通信インターフェイス３２５は、ネットワーク２４０に接続する手段である。

ここで、図２８を参照して、テーブル仮想化部２０１について説明する。図２８に示すように、テーブル仮想化部２０１は、参照処理部６２１、追加処理部６２２、更新処理部６２３を含む。
参照処理部６２１は、項目種別の判定処理部２８０１（項目種別判定処理部）、固有項目の参照の変換処理部２８０２（固有項目参照変換処理部）、共通項目の参照の変換処理部２８０３（共通項目参照変換処理部）およびレコード出力処理部２８０４を含む（詳細は後述）。

追加処理部６２２は、レコード分割処理部２８１１、共通項目レコード追加処理部２８１２および固有項目レコード追加処理部２８１３を含む（詳細は後述）。
更新処理部６２３は、レコード分割処理部２８２１、共通項目レコード更新処理部２８２２および固有項目レコード更新処理部２８２３を含む（詳細は後述）。

次に、図４を参照して、共通項目表２１１および固有項目表管理表２１２について説明する。図４に示すように、共通項目表２１１は、レコードを識別するためのＩＤ（IDentification）４０１および複数の組織で共有する共通項目を含む。図４の例では、共通項目として、企業名４０２、所在地４０３および代表者４０４を示している。
固有項目表管理表２１２は、固有項目表２２０に格納する固有項目値の型を表す型４１１、および、固有項目表の名前を表す固有項目表名４１２（固有項目情報の名前）を含む。

図５を参照して、固有項目表２２０について説明する。図５に示すように、ＶＡＲＣＨＡＲ型固有項目表２２１は、ＩＤ５０１、利用組織５０２（組織名）、項目名５０３（固有項目名）、項目値５０４（固有項目値）を含む。ＩＤ５０１は、レコードを識別するための識別子であり、共通項目表２１１のＩＤ４０１（図４参照）と同じ識別子を格納する。利用組織５０２は、固有項目を利用する組織を表す組織名を格納する。項目名５０３は、固有項目の名前を格納する。項目値５０４は、固有項目の値を格納する。
ＩＮＴ型固有項目表２２２およびＤＡＴＥ型固有項目表２２３は、ＶＡＲＣＨＡＲ型固有項目表２２１の場合と比べて、項目値５０４の型が異なる他は同様なので、説明を省略する。

図６を参照して、参照処理部６２１の処理で使われる項目一覧表６００と仮想行６１０について説明する。項目一覧表６００は、参照処理部６２１の処理において、入力された項目に関する情報を記憶するのに使われる。
図６に示すように、項目一覧表６００は、項目名６０１、項目種別６０２、固有項目の検索条件式６０３を含む。項目名６０１は、項目の名前を表す。項目種別６０２は、項目が共通項目か固有項目のどちらであるかを表す。固有項目の検索条件式６０３は、項目が固有項目の場合に、固有項目の値を固有項目表２２０から検索するのに用いる条件式を表す。

仮想行６１０は、参照処理部６２１の処理において、出力するレコードを作成するのに使われる。仮想行６１０は、業務アプリケーション２５１から入力された出力項目名の一覧の内容に対応して列が変わる。図６の仮想行６１０は、その一例を示している。入力ＩＤ６１１は必ず存在するが、企業名６１２、所在地６１３、営業担当者６１４、営業担当連絡先６１５は一例であり、出力項目名の一覧に対応する項目が指定されたときに存在する。

項目一覧表６００と仮想行６１０は、参照処理部６２１の処理を実行するときに、一時的に主記憶装置３００（図３参照）に格納される。参照処理部６２１の処理が終わったときには、項目一覧表６００と仮想行６１０は主記憶装置３００の上から削除される。

次に、図７〜１７を用いて、テーブル仮想化部２０１の処理の流れについて説明する。
テーブル仮想化部２０１を構成する参照処理部６２１、追加処理部６２２、更新処理部６２３は、業務アプリケーション２５１，２６１および２７１からの要求に応じて実行される。共通項目や固有項目を含むデータを、参照するときには参照処理部６２１が、追加するときには追加処理部６２２が、更新するときには更新処理部６２３が、それぞれ実行される。

図７を参照して、参照処理部６２１の参照処理の流れについて説明する。参照処理は、組織名、出力項目名の一覧、検索条件式を入力とする。なお、組織名は、データを利用する組織の名前を表す。出力項目名の一覧は、参照する項目名の一覧を表す。検索条件式は、参照するレコードを特定するための条件を表す。これらの用語の意味は、以下、他図においても同様である。

図７に示すように、まず、参照処理では、主記憶装置３００（図３参照）に項目一覧表６００を作成する（ステップ７０１）。
続いて、項目種別の判定処理を実行する（ステップ７０２）。このとき、引数として組織名、出力項目名の一覧、検索条件式を指定する。このステップ７０２（項目種別の判定処理）の詳細については、後述する。

次に、固有項目の参照の変換処理を、組織名を引数として実行する（ステップ７０３）。このステップ７０３（固有項目の参照の変換処理）の詳細については、後述する。
そして、共通項目の参照の変換処理を実行し、その戻り値を共通項目のみの検索条件式とする（ステップ７０４）。このとき引数として、組織名、検索条件式を指定する。このステップ７０４（共通項目の参照の変換処理）の詳細については、後述する。
最後に、レコード出力処理を実行する（ステップ７０５）。このとき引数として、組織名、出力項目名の一覧、検索条件式、共通項目のみの検索条件式を指定する。このステップ７０５（レコード出力処理）の詳細については、後述する。

図８を参照して、項目種別の判定処理の流れについて説明する。項目種別の判定処理は、項目種別の判定処理部２８０１（図２８参照）で実行される処理であり、組織名、出力項目名の一覧、検索条件式を入力とする。

図８に示すように、まず、項目種別の判定処理では、出力項目名の一覧に含まれる全ての項目について、その名前を項目名６０１（図６参照）に設定した行を、項目一覧表６００に追加する（ステップ８０１）。このとき、当該行の項目種別６０２と固有項目の検索条件式６０３は空欄である。
次に、検索条件式に含まれる全ての項目について、その名前を項目名６０１に持つ行がまだ項目一覧表６００にない場合、その名前を項目名６０１に設定した行を、項目一覧表６００に追加する（ステップ８０２）。

ここで、項目一覧表６００の全ての行Ｌについて、ステップ８０４〜８０６の手順を繰り返す（ステップ８０３〜８０７）。
Ｌの項目名６０１について、共通項目表２１１（図４参照）に同じ名前の項目（同じ項目名）があるかどうか判定する（ステップ８０４）。同じ名前の項目があればステップ８０５を、なければステップ８０６を実行する。
ステップ８０５では、項目一覧表６００の項目種別６０２に「共有項目」を入れる。ステップ８０６では、項目一覧表６００の項目種別６０２に「固有項目」を入れる。

図９を参照して、固有項目の参照の変換処理の流れについて説明する。固有項目の参照の変換処理は、固有項目の参照の変換処理部２８０２（図２８参照）で実行される処理である。
図９に示すように、固有項目の参照の変換処理では、項目一覧表６００の行のうち、項目種別６０２が「固有項目」の全ての行Ｌについて、ステップ９０２，９０３の処理を繰り返す（ステップ９０１〜９０４）。

ここで、行Ｌの項目名６０１を＜項目名＞、組織名を＜組織名＞とする（ステップ９０２）。
そして、行Ｌの固有項目の検索条件式６０３に、「利用組織＝’＜組織名＞’ ＡＮＤ 項目名＝’＜項目名＞’」を入れる（ステップ９０３）。

図１０、および、図６の各情報の例を前提とする図１１を参照して、共通項目の参照の変換処理について説明する。共通項目の参照の変換処理は、共通項目の参照の変換処理部２８０３（図２８参照）で実行される処理であり、組織名、検索条件式を入力とする。

図１０に示すように、まず、共通項目の参照の変換処理では、検索条件式を部分式に分解する（ステップ１００１）。ここで、部分式とは、検索条件式を構成する式で、その式を評価すると真偽値を取る式のことである。典型的には、部分式は項目や定数を使った等式（例：営業担当者＝’山田一郎’）や述語（例：所在地 ＬＩＫＥ ‘東京％’）であり、それらが論理演算子ＡＮＤやＯＲで連結されて検索条件式を構成する。例えば、図１１の式１１０２と式１１０４は、検索条件式１１０１を分解して得られた部分式である。

そして、ステップ１００１で得られた全ての部分式について、ステップ１００３，１００４の処理を繰り返す（ステップ１００２〜１００５）。
ステップ１００３では、部分式に含まれる項目について、項目一覧表６００の項目種別６０２を参照する。もし、項目種別６０２が「固有項目」である項目が１つ以上あれば、「固有項目」の項目に関してステップ１００４を実行する。そうでなければ（例えば、全ての項目の項目種別６０２が「共通項目」であれば）、ステップ１００５へ進み、ステップ１００２から始まる繰り返しを続行する。
ステップ１００４では、部分式を‘ＴＲＵＥ’に変換する。

図１１の部分式１１０２には、項目として「所在地」が使われているが、項目一覧表６００でその項目に対応する項目種別６０２は「共通項目」のため、部分式１１０２を‘ＴＲＵＥ’に変換しない（部分式１１０３）。図１１の部分式１１０４には、項目として「営業担当者」が使われており、項目一覧表６００でその項目に対応する項目種別６０２は「固有項目」のため、部分式１１０４を‘ＴＲＵＥ’に変換する（部分式１１０５）。

ステップ１００６では、分解した部分式を１つの検索条件式にまとめ、戻り値として返す。１つの検索条件式にまとめるときは、ステップ１００１で部分式に分解したときの論理演算子を使う。例えば、図１１では、部分式１１０３と部分式１１０５を１つの検索条件式１１０６にまとめた例を示している。部分式１１０３と部分式１１０５は、ＡＮＤで連結されていた検索条件式１１０１をステップ１００１で分解したものであるため、検索条件式１１０６もＡＮＤで連結している。

図１２を参照して、レコード出力処理の流れについて説明する。レコード出力処理は、レコード出力処理部２８０４（図２８参照）で実行される処理であり、組織名、出力項目名の一覧、検索条件式、固有項目のみの検索条件式を入力とする。

図１２に示すように、まず、レコード出力処理では、項目一覧表６００の全ての項目名６０１を列に持つ仮想行６１０（図６参照）を作る（ステップ１２０１）。
続いて、共通項目表２１１（図４参照）の行Ｌのうち、固有項目のみの検索条件式が成立する行Ｌについて、ステップ１２０３〜１２０９の処理を繰り返す（ステップ１２０２〜１２１０）。
項目一覧表６００で項目種別６０２が「共通項目」である全ての項目名６０１に対応する列（カラム）の値とＩＤを行Ｌから取得し、仮想行６１０の対応する列に格納する（ステップ１２０３）。

そして、項目一覧表６００で項目種別６０２が「固有項目」の行Ｍについて、ステップ１２０５からステップ１２０７の処理を繰り返す（ステップ１２０４）。
仮想行６１０のＩＤ６１１と同じＩＤを持ち、行Ｍの固有項目の検索条件式６０３が成立する行Ｎを検索する（ステップ１２０５）。
次に、行Ｍの項目名６０１と同じ名前を持つ仮想行６１０の列に、行Ｎの項目値５０４（図５参照）の値を格納する（ステップ１２０６）。ここで、もしステップ１２０５で行Ｎが存在しなかった場合、仮想行６１０の当該列には‘ＮＵＬＬ’を格納する。

続いて、仮想行６１０は検索条件式が成立するかどうか判定し（ステップ１２０８）、成立する場合（Ｙｅｓ）はステップ１２０９を実行し、成立しない場合（Ｎｏ）はステップ１２０９をスキップする。
ステップ１２０９では、入力された検索条件式が成立するレコードとして、仮想行６１０を業務ＡＰ（業務アプリケーション実行装置２５０の業務アプリケーション２５１など）に出力する。

図１３、および、図４の各情報の例を前提とする図１４を参照して、追加処理の流れについて説明する。追加処理は追加処理部６２２（図１参照）で実行される処理である。
図１３に示す処理のうち、ステップ１３０１，１３０２の処理１３２１は、レコード分割処理部２８１１（図２８参照）で実行されるレコード分割処理である。また、ステップ１３０３の処理１３２２は、共通項目レコード追加処理部２８１２（図２８参照）で実行される共通項目レコード追加処理である。さらに、ステップ１３０４〜１３０８の処理１３２３は、固有項目レコード追加処理部２８１３（図２８参照）で実行される固有項目レコード追加処理である。
なお、追加処理は、組織名およびレコードを入力とする。レコードは、追加するレコードを表す。

まず、追加処理では、レコードから、共通項目表２１１（図４参照）の項目と同じ項目を持つ列のみ残した共通項目レコードを作成する（ステップ１３０１）。図１４の例では、レコード１４５０から、共通項目であるＩＤ、企業名、所在地（共通項目１４５１）のみ残した共通項目レコード１４５２を作成している。

さらに、レコードから、共通項目表２１１の項目と同じ項目を持つ列を取り除いた（ただし、ＩＤは残す）固有項目レコードを作成する（ステップ１３０２）。図１４の例では、共通項目である企業名、所在地（共通項目１４５１）を取り除き、ＩＤ、営業担当者、営業担当連絡先を列として持つ固有項目レコード１４５４を作成している。
そして、共通項目レコードを共通項目表２１１（図４参照）に追加する（ステップ１３０３）。

続いて、固有項目レコードのＩＤを除く全ての列Ｃについて、ステップ１３０５〜１３０７の処理を繰り返す（ステップ１３０４〜１３０８）。
まず、列Ｃの値の型を判定し、その型をＴＹＰＥとする（ステップ１３０５）。続いて、固有項目表管理表２１２（図４参照）から、型ＴＹＰＥと同じ型４１１を持つ行を検索し、その固有項目表名４１２をＴＡＢＬＥとする（ステップ１３０６）。

テーブル名がＴＡＢＬＥと同じ固有項目表（図５のＶＡＲＣＨＡＲ型固有項目表２２１、ＩＮＴ型固有項目表２２２、ＤＡＴＥ型固有項目表２２３のいずれか）に、ＩＤ５０１が固有項目レコードのＩＤの値、利用組織５０２が組織名、項目名５０３が列Ｃの項目名、項目値５０４が列Ｃの値である行を追加する（ステップ１３０７）。図１４では、列Ｃが営業担当者の場合に追加する行の例としてレコード１４５５、列Ｃが営業担当連絡先の場合に追加する行の列としてレコード１４５６を示している。

図１５を参照して、更新処理の流れについて説明する。更新処理は、更新処理部６２３（図１参照）で実行される。図１５に示す処理のうち、ステップ１５０１，１５０２の処理１５２１は、レコード分割処理部２８２１（図２８参照）で実行される処理である。更新処理は、組織名およびレコードを入力とする。レコードは、更新するレコードを表す。

図１５に示すように、まず、更新処理では、レコードから、共通項目表２１１（図４参照）の項目と同じ項目名を持つ列のみ残した共通項目レコードを作成する（ステップ１５０１）（図１３のステップ１３０１と同様）。
続いて、レコードから、共通項目表２１１の項目と同じ項目を持つ列を取り除いた（ただし、ＩＤは残す）固有項目レコードを作成する（ステップ１５０２）（図１３のステップ１３０２と同様）。

そして、共通項目レコード更新処理を実行する（ステップ１５０３：詳細は図１６で後述）。
最後に、固有項目レコード更新処理を実行する（ステップ１５０４：詳細は図１７で後述）。

図１６を参照して、共通項目レコード更新処理について説明する。共通項目レコード更新処理は、共通項目レコード更新処理部２８２２（図２８参照）で実行され、組織名および共通項目レコードを入力とする。なお、共通項目レコードに含まれる項目は、共通項目のみでなければならない。

図１６に示すように、まず、共通項目レコード更新処理では、レコードにおけるＩＤと同じＩＤを持つ行を共通項目表２１１（図４参照）から検索し、その行を行Ｌとする（ステップ１６０１）。
続いて、レコードの全ての列Ｃについて、ステップ１６０３の処理を繰り返す（ステップ１６０２〜１６０４）。
ステップ１６０３では、列Ｃの項目と同じ項目名の行Ｌの列を、列Ｃの値で更新する。

図１７を参照して、固有項目レコード更新処理について説明する。固有項目レコード更新処理は、固有項目レコード更新処理部２８２３（図２８参照）で実行され、組織名および固有項目レコードを入力とする。なお、固有項目レコードに含まれる項目は、ＩＤと固有項目のみでなければならない。

図１７に示すように、まず、固有項目レコード更新処理では、レコードにおけるＩＤの値を、ｉｄとする（ステップ１７０１）。
次に、レコードの全ての列Ｃについて、ステップ１７０３からステップ１７１４までの処理を繰り返す（ステップ１７０２〜１７１５）。

列Ｃの値の型を判定し、その型をＴＹＰＥとする（ステップ１７０３）。そして、固有項目表管理表２１２（図４参照）から、型ＴＹＰＥと同じ型を持つ行を検索し、その固有項目表名４１２と同じ名前を持つ固有項目表をＴとする（ステップ１７０４）。
そして、固有項目表Ｔ（図５参照）から、利用組織５０２が組織名と等しく、項目名５０３が列Ｃの項目名と等しく、ＩＤがｉｄと等しい行Ｌを検索する（ステップ１７０５）。ここで、行Ｌが存在した場合（ステップ１７０６でＹｅｓ）はステップ１７０７を実行し、存在しない場合（ステップ１７０６でＮｏ）はステップ１７０８を実行する。

ステップ１７０７では、行Ｌの項目値５０４を、列Ｃの値で更新する。ステップ１７０８では、ＩＤ５０１がｉｄ、利用組織５０２が組織名、項目名５０３が列Ｃの項目名、項目値５０４が列Ｃの値である行を、固有項目表Ｔに追加する。

次に、固有項目表管理表２１２の、型４１１がＴＹＰＥでない全ての行の固有項目表名４１２について、その名前を持つ固有項目表Ｔに対して、ステップ１７１１〜１７１３の処理を繰り返す（ステップ１７１０〜１７１４）。
まず、固有項目表Ｔから、利用組織５０２が組織名と等しく、項目名５０３が列Ｃの項目名と等しく、ＩＤ５０１がｉｄと等しい行Ｌを検索する（ステップ１７１１）。
ここで、行Ｌが存在した場合（ステップ１７１２でＹｅｓ）はステップ１７１３を実行し、存在しない場合（ステップ１７０６でＮｏ）はステップ１７１４へ進む。ステップ１７１３では、行Ｌを固有項目表Ｔから削除する。

このように、本発明の第１の実施形態によれば、業務アプリケーション２５１，２６１および２７１は、テーブル仮想化部２０１に含まれる参照処理部６２１、追加処理部６２２および更新処理部６２３を利用し、その出力を得ることで、共通項目と固有項目を含むデータを参照または更新することができる。このとき、共通項目表２１１や固有項目表２２０の構造を意識する必要がない。さらに、共通項目と固有項目を区別する必要がないため、共通項目と固有項目が混在した組織専用の表に対して、レコードを参照または更新しているかのように、データを参照または更新することができる。

また、固有項目の追加は、新しい固有項目を列として持つレコードを追加する（追加処理を実行する）ことにより実現できる。このとき、記憶装置２１０に格納しているいずれの表の構造も変更する必要がないため、固有項目を追加しても、他の組織やデータ処理システム１００００の運用に影響をほとんど与えずに済む。

（第２の実施形態）
本発明の第１の実施形態では、テーブル仮想化部２０１に含まれる参照処理部６２１、追加処理部６２２、更新処理部６２３がデータを参照または更新する手順を実行していた。それに対して第２の実施形態では、ＲＤＢＭＳのビュー表がデータを参照または更新する手順を実行する。

図１８を参照して、本発明の第２の実施形態のデータ処理システム１００００ａ（１００００）の構成について説明する。なお、第１の実施形態のデータ処理システム１００００と同様の構成には同様の符号を付し、説明を適宜省略する。

データ処理装置２００ａ（２００）は、第１の実施形態のデータ処理装置２００と比べ、テーブル仮想化部２０１が削除され、テーブルビュー仮想化部１８００と固有項目管理表１８１０とが追加された点で異なっている。

テーブルビュー仮想化部１８００は、固有項目を定義する手段を提供する固有項目定義部１８０１と、データを参照または更新するためのビュー表定義を生成するビュー表定義生成部１８０２とを含む。
固有項目管理表１８１０は、固有項目の定義に関する情報を含み、固有項目定義部１８０１によって更新され、ビュー表定義生成部１８０２から参照される。

図１９を参照して、固有項目管理表１８１０について説明する。固有項目管理表１８１０は、組織名１９０１と、固有項目名１９０２と、型１９０３と、固有項目表名１９０４とを含む。組織名１９０１は、固有項目を利用する組織の組織名を表す。固有項目名１９０２は、固有項目の名前を表す。型１９０３は、固有項目の型を表す。固有項目表名１９０４は、固有項目表の名前を表す。

図２０を参照して、固有項目定義部１８０１で固有項目定義を追加するときの処理の流れについて説明する。
図２０に示すように、固有項目定義部１８０１は、システム利用者から、組織名、固有項目名および型の入力を受け付ける（ステップ２００１）。

そして、固有項目管理表１８１０に、ステップ２００１で受け付けた入力に対応する行を追加する（ステップ２００２）。具体的には、固有項目管理表１８１０の新たな行の組織名１９０１、固有項目名１９０２および型１９０３に、入力のあった組織名、固有項目名および型を格納する。また、固有項目表管理表２１２（図４参照）から型１９０３と型４１１が同じ行を検索し、その固有項目表名４１２の値を固有項目表名１９０４に格納する。

次に、ビュー表定義生成部１８０２のビュー表定義生成処理を実行する（ステップ２００３）。ビュー表定義生成処理の入力として、組織名には、ステップ２００１の入力で受け付けた組織名を設定する。ビュー表定義生成処理の詳細は、図２１で後述する。
最後に、ビュー表定義生成処理（ステップ２００３）で出力されたビュー表を、入力された組織名に対応する組織がデータを参照または更新するためのビュー表として出力する（ステップ２００４）。

図２１、および、ＳＱＬ文などの例を示す図２２、図２３を適宜参照して、ビュー表定義生成部１８０２のビュー表定義生成処理について説明する。前記したように、ビュー表定義生成処理は、組織名を入力とする。組織名は、ビュー表を利用する組織の組織名を表す。

図２１に示すように、まず、ビュー表定義生成処理では、固有項目管理表１８１０から、組織名１９０１の値が入力した組織名と等しい行ＬＳを検索する（ステップ２１０１）。ここで、行ＬＳは複数行になることがある。
次に、行ＬＳの全ての行Ｌについて、ステップ２１０３〜２１０５の処理を繰り返す（ステップ２１０２〜２１０６）。

まず、ＳＱＬのＳＥＬＥＣＴ文を生成する（ステップ２１０３）。このＳＥＬＥＣＴ文は、行Ｌの固有項目表名１９０４と同じ名前を持つ固有項目表（固有項目表２２０における３つの固有項目表のいずれか）から、利用組織５０２が入力の組織名と等しく、かつ行Ｌの固有項目名１９０２が項目名５０３の値と等しい行の、ＩＤ５０１と項目値５０４を取得する処理を記述するものである。ただし、項目値５０４の列名は、固有項目名１９０２の値とする。

例えば、行Ｌが図１９の固有項目管理表１８１０の行１９１１の場合、組織名１９０１が「営業」、固有項目表名１９０４が「ＶＡＲＣＨＡＲ型固有項目表」、固有項目名１９０２が「営業担当者」である。このときステップ２１０３によって、ＶＡＲＣＨＡＲ型固有項目表２２１（図５参照）から、利用組織５０２が「営業」と等しく、かつ項目名５０３が「営業担当者」と等しい行の、ＩＤ５０１と項目値５０４を取得するＳＥＬＥＣＴ文が生成される。ここで、そのＳＥＬＥＣＴ文で取得した項目値５０４の列名は、「営業担当者」となる。図２２のＳＱＬ文の例２２０１の２行目〜４行目は、そのＳＥＬＥＣＴ文の例を示している。
また、同様に行Ｌが図１９の固有項目管理表１８１０の行１９１２の場合、図２２のＳＱＬ文の例２２０２の２行目〜４行目に相当するＳＥＬＥＣＴ文が、ステップ２１０３で生成される。

図２１に戻って説明を続けると、次に、ステップ２１０３で生成したＳＥＬＥＣＴ文を実行するビュー表定義を、ビュー表名を「{組織名}_{固有項目名}」として生成する（ステップ２１０４）。ここで、「｛組織名｝」には入力の組織名、「｛固有項目名｝」には行Ｌの固有項目名１９０２が入る。

例えば、入力の組織名が「営業」で、行Ｌが図１９の固有項目管理表１８１０の行１９１１で、固有項目名１９０２が「営業担当者」の場合、ステップ２１０４はビュー表名「営業＿営業担当者」として、図２２のＳＱＬ文の例２２０１に示すビュー表定義を出力する。この場合のビュー表の構造は、図２２のビュー表「営業_営業担当者」の例２２１０のようになる。同様に、行Ｌが図１９の固有項目管理表１８１０の行１９１２の場合に出力するビュー表「営業_営業担当連絡先」の定義は、図２２のＳＱＬ文の例２２０２となり、ビュー表の構造は図２２のビュー表「営業_営業担当連絡先」の例２２２０のようになる。

そして、ステップ２１０４で生成したビュー表定義を、ＳＱＬインターフェイス部２３１を通じてＲＤＢＭＳ２３０に入力し、ビュー表を作成する（ステップ２１０５）。
続いて、ステップ２１０７では、ＳＱＬのＳＥＬＥＣＴ文を生成する。このＳＥＬＥＣＴ文は、共通項目表２１１（図４参照）と、ステップ２１０４で生成した全てのビュー表定義に対応するビュー表「｛組織名｝_｛固有項目名｝」を、共通項目表２１１のＩＤ４０１と等しいＩＤ２２１１を持つ行で連結し、共通項目表２１１の全ての項目（列）と、全てのビュー表「｛組織名｝_｛固有項目名｝」の固有項目を表す列を取得する。

例えば、固有項目管理表１８１０が図１９に示す内容で、入力の組織名が「営業」の場合、共通項目表２１１（図４参照）と、ビュー表「営業_営業担当者」２２１０およびビュー表「営業_営業担当連絡先」２２２０を、共通項目表２１１のＩＤ４０１と等しいＩＤ２２１１を持つ行で連結し、共通項目表２１１と、営業担当者２２１２および営業担当連絡先２２１３を取得するＳＥＬＥＣＴ文を生成する。図２３のＳＱＬ文の例２２０３の２行目〜４行目は、このＳＥＬＥＣＴ文に相当する。

次に、ステップ２１０７で生成したＳＥＬＥＣＴ文を実行するビュー表定義を、ビュー表名を「｛組織名｝」として生成する（ステップ２１０８）。例えば、入力の組織名が「営業」の場合、ビュー表名を「営業」として生成する。このときに生成するビュー表定義のＳＱＬ文の例を、図２３のＳＱＬ文の例２２０３に示し、このビュー表の構造を図２３のビュー表「営業」２２３０に示す。

続いて、ステップ２１０８で生成したビュー表定義を、ＳＱＬインターフェイス部２３１を通じてＲＤＢＭＳ２３０ａ（２３０）に入力し、ビュー表を作成する（ステップ２１０９）。
最後に、ビュー表名「｛組織名｝」をビュー表定義生成処理の結果として出力する（ステップ２１１０）。

このように、本発明の第２の実施形態によれば、固有項目定義部１８０１を利用して固有項目の定義を追加すると、ビュー表定義生成部１８０２が、共通項目と固有項目を含むビュー表を出力する。業務アプリケーション２５１，２６１および２７１は、このビュー表を介して、共通項目と固有項目を含むデータを参照または更新することができる。
このとき、第１の実施形態と同様、業務アプリケーション２５１，２６１および２７１は、共通項目表２１１や固有項目表２２０の構造を意識したり、共通項目と固有項目を区別したりする必要はない。

本発明の第１の実施形態および第２の実施形態における特徴の１つは、固有項目表２２０（図５参照）の構造が、組織追加などの場合でも変わらない点である。これにより、ある組織のみが利用する固有項目を変更（追加、削除または内容変更）しても、他の組織やデータ処理システムの運用に影響がほとんど発生しない。

また、他の特徴は、テーブル仮想化部２０１やテーブルビュー仮想化部１８００によって、業務ＡＰ（営業部門顧客管理ＡＰ１１０、調達部門発注ＡＰ１２０）が共通項目表２１１や固有項目表２２０の構造を意識することなく従来通りにデータを参照および更新できる点である。これにより、業務ＡＰを新たに開発する必要がない、業務ＡＰの運用を変更する必要がないなどの効果を奏する。

具体的には、例えば、テーブル仮想化部２０１は、そのようなインターフェイスとしての役割を果たすために、データを参照するためのオペレーションとして、共通項目と固有項目を区別なく混在して指定された出力項目名と、共通項目と固有項目が区別なく混在した検索条件式と、組織名とを入力として、検索条件式が成立するレコードを検索し、指定された出力項目名に基づいて、共通項目の項目カラムと固有項目のカラムが混在したレコードを出力するオペレーションを提供する。

このオペレーションを提供するために、テーブル仮想化部２０１には、以下の４つの処理が含まれる。
（１）項目種別の判定処理（図８参照）
（２）固有項目の参照の変換処理（図９参照）
（３）共通項目の参照の変換処理（図１０参照）
（４）レコード出力処理（図１２参照）

（１）の項目種別の判定処理では、入力された出力項目名や検索条件式に含まれる項目名が共通項目であるか固有項目であるかの項目種別を、共通項目表のスキーマ情報に基づいてする。
（２）の固有項目の参照の変換処理では、固有項目と判断された項目について、固有項目表の組織名と項目名が、入力された組織名と固有項目と判断された項目の名前と一致する行を検索する固有項目検索条件式を作成する。

（３）の共通項目の参照の変換処理では、入力された検索条件式から、共通項目と判断された項目のみ残した共通項目検索条件式を作成する。
（４）のレコード出力処理では、共通項目検索条件式を使って共通項目表から取り出したレコードと、そのレコードと同一ＩＤを持ち、かつ固有項目検索条件式が成立する固有項目表のレコードから取り出した固有項目の値とを、入力された出力項目名に基づいて連結して、共通項目と固有項目とが混在したレコードとして出力する。

さらに、テーブル仮想化部２０１が提供するインターフェイスは、データを更新するために、共通項目と固有項目が区別なく混在して指定された項目の値とＩＤとを持つレコードを入力として、共通項目表と固有項目表を更新するオペレーションも提供する。

このオペレーションを提供するために、テーブル仮想化部２０１には、以下の３つの処理が含まれる。
（１１）レコード分割処理（図１３の処理１３２１参照）
（１２）共通項目レコード更新処理（図１６参照）
（１３）固有項目レコード更新処理（図１７参照）

（１１）のレコード分割処理では、入力されたレコードの項目が共通項目であるか固有項目であるかを共通項目表のスキーマ情報に基づいて判断し、共有項目のみ集めた共通項目レコードと、固有項目のみ集めた固有項目レコードを作成する。
（１２）の共通項目レコード更新処理では、共通項目レコードで共通項目表を更新する。
（１３）の固有項目レコード更新処理では、固有項目レコードの各列から、ＩＤ、組織名、項目名、項目値から構成されるレコードを作成し、固有項目表を更新する。

以上で本実施形態の説明を終えるが、本発明の態様はこれらに限定されるものではない。例えば、ハードウェアの構成やフローチャートの内容について、本発明の主旨を逸脱しない範囲で適宜変更が可能である。

２００ データ処理装置
２０１ テーブル仮想化部
２１０ 記憶装置
２１１ 共通項目表
２１２ 固有項目表管理表
２２０ 固有項目表
２３０ ＲＤＢＭＳ
２３１ ＳＱＬインターフェイス部
２４０ ネットワーク
２５０，２６０，２７０ 業務アプリケーション実行装置
２５１，２６１，２７１ 業務アプリケーション
３００，３２２ 主記憶装置
３０１ テーブル仮想化プログラム
３０２ ＲＤＢＭＳプログラム
３１０，３２３ 二次記憶装置
３１１，３２１ ＣＰＵ
３１２，３２５ 通信インターフェイス
３１３，３２４ バス
６２１ 参照処理部
６２２ 追加処理部
６２３ 更新処理部
１８００ テーブルビュー仮想化部
１８０１ 固有項目定義部
１８０２ ビュー表定義生成部
１８１０ 固有項目管理表

Claims (9)

1. 複数の組織が共有する情報を格納するＲＤＢＭＳ(Relational Data Base Management System)を有するデータ処理装置と、前記組織のいずれかが前記データ処理装置のＲＤＢＭＳに格納された前記情報を使用する際に用いられ前記データ処理装置と通信可能に接続される業務アプリケーション実行装置と、を備えるデータ処理システムにおける前記データ処理装置によるデータ処理方法であって、
   前記情報は、ＩＤ（IDentification）によって識別され、複数のデータ項目から構成されており、
   前記データ処理装置は、
   前記ＩＤと、前記複数の組織に共通のデータ項目である共通項目の値である共通項目値と、を格納する共通項目情報、および
   前記ＩＤと、前記組織の名前である組織名と、前記組織名に対応する組織が参照・更新するデータ項目である固有項目の名前である固有項目名と、前記固有項目の値である固有項目値と、を格納する固有項目情報、を前記ＲＤＢＭＳに記憶しており、
   前記業務アプリケーション実行装置から入力された、前記共通項目と前記固有項目とが区別なく混在して指定された出力項目名と、前記共通項目と前記固有項目とが区別なく混在した検索条件式と、前記組織名と、に基づいて、前記共通項目と前記固有項目とが混在したレコードを前記業務アプリケーション実行装置に出力するテーブル仮想化部を備えており、
   前記テーブル仮想化部において、
   項目種別判定処理部が、入力された前記出力項目名および前記検索条件式に含まれるデータ項目が共通項目であるか固有項目であるかの項目種別を、前記共通項目情報を参照して判定し、
   固有項目参照変換処理部が、前記項目種別判定処理部で固有項目と判定されたデータ項目について、前記固有項目情報における組織名と固有項目名が、入力された前記組織名および前記固有項目と判定されたデータ項目の固有項目名と一致する部分を検索する固有項目検索条件式を作成し、
   共通項目参照変換処理部が、入力された前記検索条件式から、前記項目種別判定処理部で共通項目と判定されたデータ項目を残した共通項目検索条件式を作成し、
   レコード出力処理部が、前記共通項目検索条件式を用いて前記共通項目情報から取り出したレコードと、当該レコードと同一ＩＤを持ち、かつ前記固有項目検索条件式を用いて前記固有項目情報から取り出した固有項目値とを、前記出力項目名に基づいて連結して、前記共通項目と前記固有項目とが混在したレコードとして出力する
   ことを特徴とするデータ処理方法。
2. 前記テーブル仮想化部は、
   前記業務アプリケーション実行装置から入力された、前記組織名と、前記共通項目と前記固有項目が区別なく混在して指定されたデータ項目と、当該データ項目の値と、前記ＩＤと、を持つレコードに基づいて、前記ＲＤＢＭＳに格納された当該ＩＤと同一ＩＤを持つ情報の前記共通項目値と前記固有項目値とを更新する機能を有しており、
   前記テーブル仮想化部において、
   レコード分割処理部が、入力された前記レコードのデータ項目の項目種別を、前記共通項目情報を参照して判定し、前記レコードを、前記共通項目のデータ項目を集めた共通項目レコードと、前記固有項目のデータ項目を集めた固有項目レコードとに分割し、
   共通項目レコード更新処理部が、前記共通項目レコードに基づいて前記共通項目情報を更新し、
   固有項目レコード更新処理部が、前記固有項目レコードを、前記ＩＤ、前記組織名、前記固有項目名、前記固有項目値を使ったレコードに展開し、展開した当該レコードで前記固有項目情報を更新する
   ことを特徴とする請求項１の記載のデータ処理方法。
3. 前記固有項目情報は、固有項目の型ごとに複数設定され、それぞれに名前が付与されており、
   前記データ処理装置は、
   前記固有項目の型と、前記固有項目情報の名前と、を関係付けて格納する固有項目情報管理情報を、さらに備えており、
   前記テーブル仮想化部は、
   前記固有項目情報を用いるとき、前記固有項目の値の型に応じて、前記固有項目情報管理情報から前記固有項目情報の名前を取得して、当該名前に対応する前記固有項目情報を選択して用いる
   ことを特徴とする請求項１または請求項２に記載のデータ処理方法。
4. 前記テーブル仮想化部の処理手順が前記ＲＤＢＭＳのビュー情報定義として前記データ処理装置に備えられた記憶装置に記憶されており、前記ビュー情報定義に基づいて、前記ＲＤＢＭＳが前記テーブル仮想化部の処理手順を実行する
   ことを特徴とする請求項１または請求項２に記載のデータ処理方法。
5. 複数の組織が共有する情報を格納するＲＤＢＭＳ(Relational Data Base Management System)を有するデータ処理装置と、前記組織のいずれかが前記データ処理装置のＲＤＢＭＳに格納された前記情報を使用する際に用いられ前記データ処理装置と通信可能に接続される業務アプリケーション実行装置と、を備えるデータ処理システムにおける前記データ処理装置であって、
   前記情報は、ＩＤ（IDentification）によって識別され、複数のデータ項目から構成されており、
   前記データ処理装置は、
   前記ＩＤと、前記複数の組織に共通のデータ項目である共通項目の値である共通項目値と、を格納する共通項目情報、および
   前記ＩＤと、前記組織の名前である組織名と、前記組織名に対応する組織が参照・更新するデータ項目である固有項目の名前である固有項目名と、前記固有項目の値である固有項目値と、を格納する固有項目情報、を前記ＲＤＢＭＳに記憶しており、
   前記業務アプリケーション実行装置から入力された、前記共通項目と前記固有項目とが区別なく混在して指定された出力項目名と、前記共通項目と前記固有項目とが区別なく混在した検索条件式と、前記組織名と、に基づいて、前記共通項目と前記固有項目とが混在したレコードを前記業務アプリケーション実行装置に出力するテーブル仮想化部を備えており、
   前記テーブル仮想化部は、
   入力された前記出力項目名および前記検索条件式に含まれるデータ項目が共通項目であるか固有項目であるかの項目種別を、前記共通項目情報を参照して判定する項目種別判定処理部と、
   前記項目種別判定処理部で固有項目と判定されたデータ項目について、前記固有項目情報における組織名と固有項目名が、入力された前記組織名および前記固有項目と判定されたデータ項目の固有項目名と一致する部分を検索する固有項目検索条件式を作成する固有項目参照変換処理部と、
   入力された前記検索条件式から、前記項目種別判定処理部で共通項目と判定されたデータ項目を残した共通項目検索条件式を作成する共通項目参照変換処理部と、
   前記共通項目検索条件式を用いて前記共通項目情報から取り出したレコードと、当該レコードと同一ＩＤを持ち、かつ前記固有項目検索条件式を用いて前記固有項目情報から取り出した固有項目値とを、前記出力項目名に基づいて連結して、前記共通項目と前記固有項目とが混在したレコードとして出力するレコード出力処理部と、
   を備えることを特徴とするデータ処理装置。
6. 前記テーブル仮想化部は、
   前記業務アプリケーション実行装置から入力された、前記組織名と、前記共通項目と前記固有項目が区別なく混在して指定されたデータ項目と、当該データ項目の値と、前記ＩＤと、を持つレコードに基づいて、前記ＲＤＢＭＳに格納された当該ＩＤと同一ＩＤを持つ情報の前記共通項目値と前記固有項目値とを更新する機能を有し、
   入力された前記レコードのデータ項目の項目種別を、前記共通項目情報を参照して判定し、前記レコードを、前記共通項目のデータ項目を集めた共通項目レコードと、前記固有項目のデータ項目を集めた固有項目レコードとに分割するレコード分割処理部と、
   前記共通項目レコードに基づいて前記共通項目情報を更新する共通項目レコード更新処理部と、
   前記固有項目レコードを、前記ＩＤ、前記組織名、前記固有項目名、前記固有項目値を使ったレコードに展開し、展開した当該レコードで前記固有項目情報を更新する固有項目レコード更新処理部と、
   を備えることを特徴とする請求項５の記載のデータ処理装置。
7. 前記固有項目情報は、固有項目の型ごとに複数設定され、それぞれに名前が付与されており、
   前記データ処理装置は、
   前記固有項目の型と、前記固有項目情報の名前と、を関係付けて格納する固有項目情報管理情報を、さらに備え、
   前記テーブル仮想化部は、
   前記固有項目情報を用いるとき、前記固有項目の値の型に応じて、前記固有項目情報管理情報から前記固有項目情報の名前を取得して、当該名前に対応する前記固有項目情報を選択して用いる
   ことを特徴とする請求項５または請求項６に記載のデータ処理装置。
8. 前記テーブル仮想化部の処理手順が前記ＲＤＢＭＳのビュー情報定義として前記データ処理装置に備えられた記憶装置に記憶され、前記ビュー情報定義に基づいて、前記ＲＤＢＭＳが前記テーブル仮想化部の処理手順を実行する
   ことを特徴とする請求項５または請求項６に記載のデータ処理装置。
9. 請求項１から請求項４のいずれか一項に記載のデータ処理方法をコンピュータに実行させるためのデータ処理プログラム。
   

Images