JP2009146084A - テーブル管理装置 - Google Patents
テーブル管理装置 Download PDFInfo
- Publication number
- JP2009146084A JP2009146084A JP2007321563A JP2007321563A JP2009146084A JP 2009146084 A JP2009146084 A JP 2009146084A JP 2007321563 A JP2007321563 A JP 2007321563A JP 2007321563 A JP2007321563 A JP 2007321563A JP 2009146084 A JP2009146084 A JP 2009146084A
- Authority
- JP
- Japan
- Prior art keywords
- field
- record
- additional
- data
- unit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
【課題】データベース構成を変更せずフィールドの追加や削除が可能であり、ＲＤＢＭＳに用意される全てのデータ型についてデータレコードの格納／検索の可能なシステムを提供する。
【解決手段】入力手段５１０は、フィールドを追加する業務テーブルのテーブル識別ＩＤと、追加対象フィールドのフィールドＩＤ、フィールド名称、フィールドのデータ型とを含むフィールド追加要求を受け付ける。フィールド追加部１１０は、フィールド追加要求のこれらのデータを１レコードとして追加フィールド管理テーブル４１０に登録すると共に、登録の際、前記データ型のフィールド値を格納する追加フィールドデータテーブル４４０が作成済みかを判定し、作成されていない場合、インデックス、テーブルＩＤ、フィールドＩＤ、フィールド値の項目からなり、フィールド値としてフィールド追加要求に含まれるデータ型を格納する追加フィールドデータテーブル４４０を作成する。
【選択図】図３
【解決手段】入力手段５１０は、フィールドを追加する業務テーブルのテーブル識別ＩＤと、追加対象フィールドのフィールドＩＤ、フィールド名称、フィールドのデータ型とを含むフィールド追加要求を受け付ける。フィールド追加部１１０は、フィールド追加要求のこれらのデータを１レコードとして追加フィールド管理テーブル４１０に登録すると共に、登録の際、前記データ型のフィールド値を格納する追加フィールドデータテーブル４４０が作成済みかを判定し、作成されていない場合、インデックス、テーブルＩＤ、フィールドＩＤ、フィールド値の項目からなり、フィールド値としてフィールド追加要求に含まれるデータ型を格納する追加フィールドデータテーブル４４０を作成する。
【選択図】図３
Description
この発明は、データベースの構成を変更することなしに、フィールドの追加や削除を行うことができるテーブル管理装置に関する。
特開２０００−１２３０３８号公報（特許文献１）では、データベースの構成を変更することなしに、フィールドの追加や削除を行うことができるデータベース装置の技術として、ＲＤＢ（Ｒｅｌａｔｉｏｎａｌ ＤａｔａＢａｓｅ）の対応関係テーブルに列番号、データのフィールド名、型、サイズを記憶し、データベース上に行番号、列番号、データのフィールドで構成するデータを格納し、行番号および列番号をキーにして一つのレコードで追加定義されたフィールドのデータを登録、検索できるシステムが開示されている。
特開２０００−１２３０３８号公報
背景技術に示した特許文献１においては以下の課題がある。
（１）特許文献１ではデータ格納フィールドに可変長文字列型を使っているため、文字列以外の値を格納／抽出／検索する場合、エンコード／デコードが発生し、特に数値型のデータでは効率が悪くなり、エンコード／デコードすることによって本来の値が失われることがある。
（２）数値型をエンコードしたフィールドデータに対して、多くの場合ＳＱＬの検索条件式が使えない。例えば、「“２”と“１０”」の文字列比較を実施すると「“２”＞“１０”」と誤った結果となるし、浮動小数点型では小数点の位置が個々の値によって異なるため文字列同士を比較しても意味がない。
（１）特許文献１ではデータ格納フィールドに可変長文字列型を使っているため、文字列以外の値を格納／抽出／検索する場合、エンコード／デコードが発生し、特に数値型のデータでは効率が悪くなり、エンコード／デコードすることによって本来の値が失われることがある。
（２）数値型をエンコードしたフィールドデータに対して、多くの場合ＳＱＬの検索条件式が使えない。例えば、「“２”と“１０”」の文字列比較を実施すると「“２”＞“１０”」と誤った結果となるし、浮動小数点型では小数点の位置が個々の値によって異なるため文字列同士を比較しても意味がない。
これらの課題を解決するために、（１）及び（２）に対しては、追加フィールドの値を格納するために別テーブルをデータ型別に用意することで、ＲＤＢＭＳ（Ｒｅｌａｔｉｏｎａｌ Ｄａｔａｂａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）で用意されている全てのデータ型について関数などの機能を利用して格納／検索の可能なシステムを提供する。
この発明のテーブル管理装置は、
テーブルを管理するテーブル管理装置において、
インデックスのフィールドと名称が付与された１以上のフィールドとのそれぞれのフィールド値からなるレコードを１レコードとして登録する複数の登録テーブルを格納するテーブル格納部と、
前記複数の登録テーブルのうちのいずれかを一意に示すテーブルＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）と、テーブルＩＤの示す登録テーブルのフィールド名称に対応するフィールド値とを含む登録用情報の入力を受け付ける入力受付部と、
前記入力受付部により受け付けられた登録用情報にこの登録用情報を特定するインデックスを付与し、インデックスの付与された登録用情報のうちテーブルＩＤを除くインデックスとフィールド値とを１レコードとして、この登録用情報に含まれるテーブルＩＤの示す登録テーブルに登録する登録部と
を備え、
前記入力受付部は、
フィールドの追加を要求する情報であって、テーブルＩＤと、このテーブルＩＤの示す登録テーブルとの関係において追加が要求されるフィールドに一意に付与されたフィールドＩＤと、追加が要求されるフィールドのフィールド名称と、追加が要求されるフィールドに格納されるフィールド値のデータ型とを含むとともに、テーブルＩＤの示す登録テーブルに対してフィールド名称の示すフィールドの追加を要求するフィールド追加要求情報を受け付け、
前記テーブル管理装置は、さらに、
追加フィールド管理テーブルを格納する追加フィールド管理テーブル格納部と、
前記入力受付部がフィールド追加要求情報を受け付けると、
フィールド追加要求情報に含まれるテーブルＩＤと、フィールドＩＤと、フィールド名称と、データ型とを１レコードとして前記追加フィールド管理テーブルに登録するとともに、フィールド追加要求情報に含まれるデータ型のフィールド値を格納する追加フィールドデータテーブルが既に作成されているかどうかを判定し、作成されていないと判定すると、インデックスと、テーブルＩＤと、フィールドＩＤと、フィールド値との項目からなるテーブルであって、フィールド値としてフィールド追加要求情報に含まれるデータ型を格納する追加フィールドデータテーブルを作成するフィールド追加部と
備え、
前記入力受付部は、
インデックスと、テーブルＩＤと、フィールド名称と、このフィールド名称に対応する値とを含む情報であって前記テーブルＩＤの示す登録用テーブルにおける前記インデックスの示すレコードの更新を要求する更新要求情報の入力を受け付け、
前記テーブル管理装置は、さらに、
前記入力受付部が更新要求情報を受け付けると、この更新要求情報に含まれるテーブルＩＤとフィールド名称とに基づいて、前記追加フィールド管理テーブルに登録されたレコードのうち更新要求情報に含まれるテーブルＩＤとフィールド名称とをもつレコードを特定し、特定された特定レコードに含まれるデータ型からこのデータ型の追加フィールドデータテーブルを特定し、特定された追加フィールドデータテーブルの中に更新要求情報に含まれるインデックスを有するレコードが存在するかどうかを判定し、判定の結果、存在しないと判定すると、更新要求情報に含まれるインデックス、テーブルＩＤ、フィールド名称に対応する値、及び前記追加フィールド管理テーブルにおいて特定された特定レコードに含まれるフィールドＩＤとを１レコードとして前記追加フィールドデータテーブルに登録する更新部を備えたことを特徴とする。
テーブルを管理するテーブル管理装置において、
インデックスのフィールドと名称が付与された１以上のフィールドとのそれぞれのフィールド値からなるレコードを１レコードとして登録する複数の登録テーブルを格納するテーブル格納部と、
前記複数の登録テーブルのうちのいずれかを一意に示すテーブルＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）と、テーブルＩＤの示す登録テーブルのフィールド名称に対応するフィールド値とを含む登録用情報の入力を受け付ける入力受付部と、
前記入力受付部により受け付けられた登録用情報にこの登録用情報を特定するインデックスを付与し、インデックスの付与された登録用情報のうちテーブルＩＤを除くインデックスとフィールド値とを１レコードとして、この登録用情報に含まれるテーブルＩＤの示す登録テーブルに登録する登録部と
を備え、
前記入力受付部は、
フィールドの追加を要求する情報であって、テーブルＩＤと、このテーブルＩＤの示す登録テーブルとの関係において追加が要求されるフィールドに一意に付与されたフィールドＩＤと、追加が要求されるフィールドのフィールド名称と、追加が要求されるフィールドに格納されるフィールド値のデータ型とを含むとともに、テーブルＩＤの示す登録テーブルに対してフィールド名称の示すフィールドの追加を要求するフィールド追加要求情報を受け付け、
前記テーブル管理装置は、さらに、
追加フィールド管理テーブルを格納する追加フィールド管理テーブル格納部と、
前記入力受付部がフィールド追加要求情報を受け付けると、
フィールド追加要求情報に含まれるテーブルＩＤと、フィールドＩＤと、フィールド名称と、データ型とを１レコードとして前記追加フィールド管理テーブルに登録するとともに、フィールド追加要求情報に含まれるデータ型のフィールド値を格納する追加フィールドデータテーブルが既に作成されているかどうかを判定し、作成されていないと判定すると、インデックスと、テーブルＩＤと、フィールドＩＤと、フィールド値との項目からなるテーブルであって、フィールド値としてフィールド追加要求情報に含まれるデータ型を格納する追加フィールドデータテーブルを作成するフィールド追加部と
備え、
前記入力受付部は、
インデックスと、テーブルＩＤと、フィールド名称と、このフィールド名称に対応する値とを含む情報であって前記テーブルＩＤの示す登録用テーブルにおける前記インデックスの示すレコードの更新を要求する更新要求情報の入力を受け付け、
前記テーブル管理装置は、さらに、
前記入力受付部が更新要求情報を受け付けると、この更新要求情報に含まれるテーブルＩＤとフィールド名称とに基づいて、前記追加フィールド管理テーブルに登録されたレコードのうち更新要求情報に含まれるテーブルＩＤとフィールド名称とをもつレコードを特定し、特定された特定レコードに含まれるデータ型からこのデータ型の追加フィールドデータテーブルを特定し、特定された追加フィールドデータテーブルの中に更新要求情報に含まれるインデックスを有するレコードが存在するかどうかを判定し、判定の結果、存在しないと判定すると、更新要求情報に含まれるインデックス、テーブルＩＤ、フィールド名称に対応する値、及び前記追加フィールド管理テーブルにおいて特定された特定レコードに含まれるフィールドＩＤとを１レコードとして前記追加フィールドデータテーブルに登録する更新部を備えたことを特徴とする。
この発明により、ＲＤＢＭＳで用意されている全てのデータ型について、関数などの機能を利用して格納／検索の可能なシステムを提供することができる。
実施の形態１．
図１は、コンピュータである動的テーブル管理システム１００００（テーブル管理装置）の外観の一例を示す図である。図１において、動的テーブル管理システム１００００は、システムユニット８３０、ＣＲＴ（Ｃａｔｈｏｄｅ・Ｒａｙ・Ｔｕｂｅ）やＬＣＤ（液晶）の表示画面を有する表示装置８１３、キーボード８１４（Ｋｅｙ・Ｂｏａｒｄ：Ｋ／Ｂ）、マウス８１５、ＦＤＤ８１７（Ｆｌｅｘｉｂｌｅ・Ｄｉｓｋ・ Ｄｒｉｖｅ）、コンパクトディスク装置８１８（ＣＤＤ：Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｄｒｉｖｅ）、プリンタ装置８１９などのハードウェア資源を備え、これらはケーブルや信号線で接続されている。システムユニット８３０は、コンピュータであり、また、ネットワークに接続されている。
図１は、コンピュータである動的テーブル管理システム１００００（テーブル管理装置）の外観の一例を示す図である。図１において、動的テーブル管理システム１００００は、システムユニット８３０、ＣＲＴ（Ｃａｔｈｏｄｅ・Ｒａｙ・Ｔｕｂｅ）やＬＣＤ（液晶）の表示画面を有する表示装置８１３、キーボード８１４（Ｋｅｙ・Ｂｏａｒｄ：Ｋ／Ｂ）、マウス８１５、ＦＤＤ８１７（Ｆｌｅｘｉｂｌｅ・Ｄｉｓｋ・ Ｄｒｉｖｅ）、コンパクトディスク装置８１８（ＣＤＤ：Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｄｒｉｖｅ）、プリンタ装置８１９などのハードウェア資源を備え、これらはケーブルや信号線で接続されている。システムユニット８３０は、コンピュータであり、また、ネットワークに接続されている。
図２は、コンピュータである動的テーブル管理システム１００００のハードウェア資源の一例を示す図である。図２において、動的テーブル管理システム１００００は、プログラムを実行するＣＰＵ８１０（中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。ＣＰＵ８１０は、バス８２５を介してＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）８１１、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）８１２、表示装置８１３、キーボード８１４、マウス８１５、通信ボード８１６、ＦＤＤ８１７、ＣＤＤ８１８、プリンタ装置８１９、磁気ディスク装置８２０と接続され、これらのハードウェアデバイスを制御する。磁気ディスク装置８２０の代わりに、光ディスク装置、フラッシュメモリなどの記憶装置でもよい。
ＲＡＭ８１２は、揮発性メモリの一例である。ＲＯＭ８１１、ＦＤＤ８１７、ＣＤＤ８１８、磁気ディスク装置８２０等の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置あるいは記憶部、格納部の一例である。通信ボード８１６、キーボード８１４、ＦＤＤ８１７などは、入力部、入力装置の一例である。また、通信ボード８１６、表示装置８１３、プリンタ装置８１９などは、出力部、出力装置の一例である。
通信ボード８１６は、ネットワーク（ＬＡＮ等）に接続されている。通信ボード８１６は、ＬＡＮに限らず、インターネット、ＩＳＤＮ等のＷＡＮ（ワイドエリアネットワーク）などに接続されていても構わない。
磁気ディスク装置８２０には、オペレーティングシステム８２１（ＯＳ）、ウィンドウシステム８２２、プログラム群８２３、ファイル群８２４が記憶されている。プログラム群８２３のプログラムは、ＣＰＵ８１０、オペレーティングシステム８２１、ウィンドウシステム８２２により実行される。
上記プログラム群８２３には、以下に述べる実施の形態の説明において「〜部」として説明する機能を実行するプログラムが記憶されている。プログラムは、ＣＰＵ８１０により読み出され実行される。
ファイル群８２４には、以下に述べる実施の形態の説明において、「〜テーブル」として説明する各種のテーブルや、「〜の判定結果」、「〜の算出結果」、「〜の抽出結果」、「〜の生成結果」、「〜の処理結果」として説明する情報や、データや信号値や変数値やパラメータなどが、「〜ファイル」や「〜データベース」の各項目として記憶されている。「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ８１０によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・出力・印刷・表示などのＣＰＵの動作に用いられる。抽出・検索・参照・比較・演算・計算・処理・出力・印刷・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリやキャッシュメモリやバッファメモリに一時的に記憶される。
また、以下に述べる実施の形態の説明においては、データや信号値は、ＲＡＭ８１２のメモリ、ＦＤＤ８１７のフレキシブルディスク、ＣＤＤ８１８のコンパクトディスク、磁気ディスク装置８２０の磁気ディスク、その他光ディスク、ミニディスク、ＤＶＤ（Ｄｉｇｉｔａｌ・Ｖｅｒｓａｔｉｌｅ・Ｄｉｓｋ）等の記録媒体に記録される。また、データや信号は、バス８２５や信号線やケーブルその他の伝送媒体によりオンライン伝送される。
また、以下に述べる実施の形態の説明において「〜部」として説明するものは、「〜回路」、「〜装置」、「〜機器」、「手段」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。すなわち、「〜部」として説明するものは、ＲＯＭ８１１に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、ＤＶＤ等の記録媒体に記憶される。プログラムはＣＰＵ８１０により読み出され、ＣＰＵ８１０により実行される。すなわち、プログラムは、以下に述べる「〜部」としてコンピュータを機能させるものである。あるいは、以下に述べる「〜部」の手順や方法をコンピュータに実行させるものである。
図３は、実施の形態１における動的テーブル管理システム１００００のシステム構成を示す。動的テーブル管理システム１００００は、ＲＤＢＭＳ４００（テーブル格納部、追加フィールド管理テーブル格納部）、入力手段５１０（入力受付部）、表示手段５２０、業務サーバ１０００を備えている。
業務サーバ１０００は、ＤＢ定義部１００と、所定の業務アプリケーションを実行する業務アプリケーション実行部２００と、ＤＢ処理部３００とを備えている。ＤＢ定義部１００は、フィールド追加部１１０、追加フィールド取得部１２０、追加フィールド削除部１３０、を備えている。ＤＢ処理部３００は、追加フィールドレコード追加部３１０（登録部）と、追加フィールドレコード検索部３２０（ビュー作成部）と、追加フィールドレコード削除部３３０（ビュー作成部）と、追加フィールドレコード更新部３４０（更新部）とを備える。ＲＤＢＭＳ４００は、追加フィールド管理テーブル４１０と、レコード関連付けインデックス管理テーブル４２０と、複数の業務テーブル４３０と、複数の追加フィールドデータテーブル４４０とを備えている。
（入力手段５１０、表示手段５２０）
入力手段５１０、表示手段５２０は、業務サーバ１０００に対する入力及び出力機能を提供する。
入力手段５１０、表示手段５２０は、業務サーバ１０００に対する入力及び出力機能を提供する。
（ＤＢ定義部１００）
ＤＢ定義部１００は、ＲＤＢＭＳ４００で管理している業務テーブル４３０に対して、データベースの構成を変更することなしに、フィールドの追加や削除を行う機能を提供し、フィールドの追加や削除の情報を追加フィールド管理テーブル４１０に格納する。
ＤＢ定義部１００は、ＲＤＢＭＳ４００で管理している業務テーブル４３０に対して、データベースの構成を変更することなしに、フィールドの追加や削除を行う機能を提供し、フィールドの追加や削除の情報を追加フィールド管理テーブル４１０に格納する。
（業務アプリケーション実行部２００）
業務アプリケーション実行部２００により実行される業務アプリケーションは、業務を実行する機能を提供し、入力手段５１０からの入力された情報に基づいて、業務に必要な情報をＤＢ処理部３００に送受信し、処理した結果を表示手段５２０に出力する。
業務アプリケーション実行部２００により実行される業務アプリケーションは、業務を実行する機能を提供し、入力手段５１０からの入力された情報に基づいて、業務に必要な情報をＤＢ処理部３００に送受信し、処理した結果を表示手段５２０に出力する。
（ＤＢ処理部３００）
ＤＢ処理部３００は、ＲＤＢＭＳ４００で管理されている業務データに対する入出力機能を提供し、業務アプリケーション実行部２００により実行される業務アプリケーションから、追加フィールドを含んだ業務テーブルへのデータ要求に対して、ユーザに追加フィールドを意識させずに、業務テーブルと追加フィールドとから抽出したデータを結合し、まとまったデータとして出力する。
ＤＢ処理部３００は、ＲＤＢＭＳ４００で管理されている業務データに対する入出力機能を提供し、業務アプリケーション実行部２００により実行される業務アプリケーションから、追加フィールドを含んだ業務テーブルへのデータ要求に対して、ユーザに追加フィールドを意識させずに、業務テーブルと追加フィールドとから抽出したデータを結合し、まとまったデータとして出力する。
（ＲＤＢＭＳ４００）
ＲＤＢＭＳ４００は、業務テーブル４３０と、後からフィールドの追加や削除が可能なようにフィールドを管理するための追加フィールド管理テーブル４１０，レコード関連付けインデックス管理テーブル４２０と、追加フィールドのフィールド値を格納する追加フィールドデータテーブル４４０を持つ。
ＲＤＢＭＳ４００は、業務テーブル４３０と、後からフィールドの追加や削除が可能なようにフィールドを管理するための追加フィールド管理テーブル４１０，レコード関連付けインデックス管理テーブル４２０と、追加フィールドのフィールド値を格納する追加フィールドデータテーブル４４０を持つ。
以下に業務サーバ１０００の備えるＤＢ定義部１００、ＤＢ処理部３００、及びＲＤＢＭＳ４００について詳しく説明をする。
（ＲＤＢＭＳ４００）
ＲＤＢＭＳ４００は、追加フィールド管理テーブル４１０と、レコード関連付けインデックス管理テーブル４２０と、業務テーブル４３０と、追加フィールドデータテーブル４４０の４種類のテーブルを管理する。
ＲＤＢＭＳ４００は、追加フィールド管理テーブル４１０と、レコード関連付けインデックス管理テーブル４２０と、業務テーブル４３０と、追加フィールドデータテーブル４４０の４種類のテーブルを管理する。
（追加フィールド管理テーブル４１０）
図４は、追加フィールド管理テーブル４１０を示す図である。追加フィールド管理テーブル４１０は、どの業務テーブル４３０にどのようなフィールドが追加されているかという情報を管理するテーブルである。追加フィールド管理テーブル４１０は、少なくとも追加対象のテーブルを一意に決定するテーブル識別ＩＤ４１１と、追加対象のテーブルにおいてフィールドを一意に決定するフィールドＩＤ４１２と、フィールドの格納値のデータ型を定義するデータ型４１３と、フィールドの名称を定義する項目名４１４とのフィールドから成る。
図４は、追加フィールド管理テーブル４１０を示す図である。追加フィールド管理テーブル４１０は、どの業務テーブル４３０にどのようなフィールドが追加されているかという情報を管理するテーブルである。追加フィールド管理テーブル４１０は、少なくとも追加対象のテーブルを一意に決定するテーブル識別ＩＤ４１１と、追加対象のテーブルにおいてフィールドを一意に決定するフィールドＩＤ４１２と、フィールドの格納値のデータ型を定義するデータ型４１３と、フィールドの名称を定義する項目名４１４とのフィールドから成る。
（インデックス管理テーブル４２０）
図５は、レコード関連付けインデックス管理テーブル４２０を示す図である。レコード関連付けインデックス管理テーブル４２０は、業務テーブル４３０と追加フィールドデータテーブル４４０のそれぞれに格納されたレコードを関連付けるインデックス番号に重複が発生しないように管理するテーブルである。レコード関連付けインデックス管理テーブル４２０は、少なくとも発行済みインデックス４２１のフィールドから成る。
図５は、レコード関連付けインデックス管理テーブル４２０を示す図である。レコード関連付けインデックス管理テーブル４２０は、業務テーブル４３０と追加フィールドデータテーブル４４０のそれぞれに格納されたレコードを関連付けるインデックス番号に重複が発生しないように管理するテーブルである。レコード関連付けインデックス管理テーブル４２０は、少なくとも発行済みインデックス４２１のフィールドから成る。
（業務テーブル４３０）
図６は、ある業務テーブルを示す図である。業務テーブルは、いずれも同じ構成である。業務テーブル４３０は、業務データを格納し運用中にフィールドの追加が可能なテーブルである。業務テーブル４３０は、少なくとも追加フィールドデータとの関連を格納するインデックス４３１と、業務情報を格納する業務情報４３２・・・のフィールドから成る。
図６は、ある業務テーブルを示す図である。業務テーブルは、いずれも同じ構成である。業務テーブル４３０は、業務データを格納し運用中にフィールドの追加が可能なテーブルである。業務テーブル４３０は、少なくとも追加フィールドデータとの関連を格納するインデックス４３１と、業務情報を格納する業務情報４３２・・・のフィールドから成る。
（追加フィールドデータテーブル４４０）
図７は、追加フィールドデータテーブル４４０を示す図である。追加フィールドデータテーブル４４０は、業務テーブル４３０に対して追加したフィールドの実データが格納されるテーブルである。追加フィールドデータテーブル４４０は、追加フィールド管理テーブル４１０に対して、追加したレコードのデータ型４１３が追加フィールド管理テーブル４１０の中でいちばん最初だった場合に、動的に作成されるテーブルである。少なくとも業務テーブル４３０と追加フィールドデータテーブル４４０のレコードを関連付けるインデックス４４１と、追加対象の業務テーブルを一意に識別可能なテーブル識別ＩＤ４４２と、追加したフィールドを識別するフィールドＩＤ４４３と、データ型４１３で定義された型を格納可能な値４４４のフィールドから成る。
図７は、追加フィールドデータテーブル４４０を示す図である。追加フィールドデータテーブル４４０は、業務テーブル４３０に対して追加したフィールドの実データが格納されるテーブルである。追加フィールドデータテーブル４４０は、追加フィールド管理テーブル４１０に対して、追加したレコードのデータ型４１３が追加フィールド管理テーブル４１０の中でいちばん最初だった場合に、動的に作成されるテーブルである。少なくとも業務テーブル４３０と追加フィールドデータテーブル４４０のレコードを関連付けるインデックス４４１と、追加対象の業務テーブルを一意に識別可能なテーブル識別ＩＤ４４２と、追加したフィールドを識別するフィールドＩＤ４４３と、データ型４１３で定義された型を格納可能な値４４４のフィールドから成る。
（ＤＢ定義部１００）
図３を参照して、ＤＢ定義部１００を説明する。ＤＢ定義部１００は、フィールド追加部１１０と、追加フィールド取得部１２０と、追加フィールド削除部１３０とを備えている。
図３を参照して、ＤＢ定義部１００を説明する。ＤＢ定義部１００は、フィールド追加部１１０と、追加フィールド取得部１２０と、追加フィールド削除部１３０とを備えている。
（フィールド追加部１１０）
フィールド追加部１１０は、ＲＤＢＭＳ４００によって管理されている既存の業務テーブル４３０において不足しているフィールドを仮想的に追加する機能を有する。詳細は、動作の説明で後述するが、フィールド追加部１１０は、図４の追加フィールド管理テーブル４１０に対して、追加対象の業務テーブルを一意に識別可能なテーブル識別ＩＤ４１１と、追加したフィールドを一意に識別するフィールドＩＤ４１２と、追加したフィールドのデータ型を示すデータ型４１３と、追加したフィールドの名称を示す項目名４１４とからなる情報をレコードとしてインサートする（後述のＳ１０２）。この時、フィールド追加部１１０は、図４の追加フィールド管理テーブル４１０にレコードをインサートする際に、インサートするレコードのデータ型４１３（追加フィールドデータテーブル４４０は、データ型ごとに存在する）が、追加フィールド管理テーブル４１０の中で最初だった場合、すなわち、追加フィールド管理テーブル４１０には、インサートされたレコードの有するデータ型のレコードがいまだに登録されていない場合には、図７に示した追加フィールドデータテーブル４４０を動的に作成する。すなわち、追加フィールドデータテーブル４４０は、フィールド追加部１１０によって、データ型ごとに作成される。図３に示す複数の追加フィールドデータテーブル４４０は、フィールド追加部１１０によって作成された場合を示している。追加フィールドデータテーブル４４０は、業務テーブル４３０のレコードと、追加フィールドデータテーブル４４０のレコードとを関連付けるインデックス４４１（後述）と、フィールドの追加対象となる業務テーブルを一意に識別可能なテーブル識別ＩＤ４４２と、追加したフィールドを識別するフィールドＩＤ４４３と、データ型４１３で定義された型のデータ（フィールド値）を格納する「値４４４」とのフィールドを持つ。
フィールド追加部１１０は、ＲＤＢＭＳ４００によって管理されている既存の業務テーブル４３０において不足しているフィールドを仮想的に追加する機能を有する。詳細は、動作の説明で後述するが、フィールド追加部１１０は、図４の追加フィールド管理テーブル４１０に対して、追加対象の業務テーブルを一意に識別可能なテーブル識別ＩＤ４１１と、追加したフィールドを一意に識別するフィールドＩＤ４１２と、追加したフィールドのデータ型を示すデータ型４１３と、追加したフィールドの名称を示す項目名４１４とからなる情報をレコードとしてインサートする（後述のＳ１０２）。この時、フィールド追加部１１０は、図４の追加フィールド管理テーブル４１０にレコードをインサートする際に、インサートするレコードのデータ型４１３（追加フィールドデータテーブル４４０は、データ型ごとに存在する）が、追加フィールド管理テーブル４１０の中で最初だった場合、すなわち、追加フィールド管理テーブル４１０には、インサートされたレコードの有するデータ型のレコードがいまだに登録されていない場合には、図７に示した追加フィールドデータテーブル４４０を動的に作成する。すなわち、追加フィールドデータテーブル４４０は、フィールド追加部１１０によって、データ型ごとに作成される。図３に示す複数の追加フィールドデータテーブル４４０は、フィールド追加部１１０によって作成された場合を示している。追加フィールドデータテーブル４４０は、業務テーブル４３０のレコードと、追加フィールドデータテーブル４４０のレコードとを関連付けるインデックス４４１（後述）と、フィールドの追加対象となる業務テーブルを一意に識別可能なテーブル識別ＩＤ４４２と、追加したフィールドを識別するフィールドＩＤ４４３と、データ型４１３で定義された型のデータ（フィールド値）を格納する「値４４４」とのフィールドを持つ。
（追加フィールド取得部１２０）
追加フィールド取得部１２０は、任意の「業務テーブル４３０」に対して後から追加された追加フィールドの情報を取得する機能を持つ。追加フィールド取得部１２０は、図４に示した追加フィールド管理テーブル４１０から、追加対象の業務テーブルを一意に識別可能なテーブル識別ＩＤ４１１と、追加したフィールドを一意に識別するためのフィールドＩＤ４１２と、追加したフィールドのデータ型を示すデータ型４１３と、追加したフィールドの名称を示す項目名４１４との情報を取得する。
追加フィールド取得部１２０は、任意の「業務テーブル４３０」に対して後から追加された追加フィールドの情報を取得する機能を持つ。追加フィールド取得部１２０は、図４に示した追加フィールド管理テーブル４１０から、追加対象の業務テーブルを一意に識別可能なテーブル識別ＩＤ４１１と、追加したフィールドを一意に識別するためのフィールドＩＤ４１２と、追加したフィールドのデータ型を示すデータ型４１３と、追加したフィールドの名称を示す項目名４１４との情報を取得する。
（追加フィールド削除部１３０）
追加フィールド削除部１３０は、任意の業務テーブル４３０に対して後から追加されたフィールド情報を削除する機能を持つ。追加フィールド削除部１３０は、図４の追加フィールド管理テーブル４１０から、追加したフィールド情報を削除する。
追加フィールド削除部１３０は、任意の業務テーブル４３０に対して後から追加されたフィールド情報を削除する機能を持つ。追加フィールド削除部１３０は、図４の追加フィールド管理テーブル４１０から、追加したフィールド情報を削除する。
（追加フィールドデータテーブル４４０の動的削除）
この時、追加フィールド削除部１３０は、追加フィールド管理テーブル４１０に対して、削除したレコードのデータ型４１３が追加フィールド管理テーブル４１０にもはや存在しなくなった場合、追加フィールドデータテーブル４４０を動的に削除する。一方、削除されたレコードのデータ型４１３と同じデータ型をもつレコードが追加フィールド管理テーブル４１０に登録されている場合は、追加フィールドデータテーブル４４０を削除せずに、該当フィールドのレコードを追加フィールドデータテーブル４４０から全て削除する（その型のレコードがあれば残す）。
この時、追加フィールド削除部１３０は、追加フィールド管理テーブル４１０に対して、削除したレコードのデータ型４１３が追加フィールド管理テーブル４１０にもはや存在しなくなった場合、追加フィールドデータテーブル４４０を動的に削除する。一方、削除されたレコードのデータ型４１３と同じデータ型をもつレコードが追加フィールド管理テーブル４１０に登録されている場合は、追加フィールドデータテーブル４４０を削除せずに、該当フィールドのレコードを追加フィールドデータテーブル４４０から全て削除する（その型のレコードがあれば残す）。
（ＤＢ処理部３００）
ＤＢ処理部３００は、追加フィールドレコード追加部３１０（以下、レコード追加部３１０という）と、追加フィールドレコード検索部３２０（以下、レコード検索部３２０という）と、追加フィールドレコード削除部３３０（以下、レコード削除部３３０という）とから構成される。
ＤＢ処理部３００は、追加フィールドレコード追加部３１０（以下、レコード追加部３１０という）と、追加フィールドレコード検索部３２０（以下、レコード検索部３２０という）と、追加フィールドレコード削除部３３０（以下、レコード削除部３３０という）とから構成される。
（レコード追加部３１０）
レコード追加部３１０は、業務アプリケーション２１０からのレコード追加要求（レコードの新規登録）に対して、業務テーブル４３０と追加フィールドデータテーブル４４０とにレコード情報を格納する（後述のＳ３０１〜）。レコード追加部３１０は、業務テーブル４３０と、この業務テーブル４３０に追加された追加フィールドの情報とをテーブル識別ＩＤ４１１をキーとして追加フィールド管理テーブル４１０から抽出し、レコード関連付けインデックス管理テーブル４２０から一意のインデックス値を算出する。レコード追加要求の追加フィールドに対応するデータは、追加フィールドデータテーブル４４０にインデックス４４１と、テーブル識別ＩＤ４４２と、フィールドＩＤ４４３と、値４４４とを追加フィールドの数だけインサートする。また、レコード追加要求の追加フィールド以外の業務情報４３２，４３３，・・・は、先ほどレコード関連付けインデックス管理テーブル４２０の情報から算出したインデックス４３１を付加して業務テーブル４３０にインサートする。（後述のＳ３０１〜で詳述する）。
レコード追加部３１０は、業務アプリケーション２１０からのレコード追加要求（レコードの新規登録）に対して、業務テーブル４３０と追加フィールドデータテーブル４４０とにレコード情報を格納する（後述のＳ３０１〜）。レコード追加部３１０は、業務テーブル４３０と、この業務テーブル４３０に追加された追加フィールドの情報とをテーブル識別ＩＤ４１１をキーとして追加フィールド管理テーブル４１０から抽出し、レコード関連付けインデックス管理テーブル４２０から一意のインデックス値を算出する。レコード追加要求の追加フィールドに対応するデータは、追加フィールドデータテーブル４４０にインデックス４４１と、テーブル識別ＩＤ４４２と、フィールドＩＤ４４３と、値４４４とを追加フィールドの数だけインサートする。また、レコード追加要求の追加フィールド以外の業務情報４３２，４３３，・・・は、先ほどレコード関連付けインデックス管理テーブル４２０の情報から算出したインデックス４３１を付加して業務テーブル４３０にインサートする。（後述のＳ３０１〜で詳述する）。
（レコード検索部３２０）
レコード検索部３２０は、業務アプリケーション２１０からのレコード検索要求に対して、業務テーブル４３０と追加フィールドデータテーブル４４０とから適切にレコード情報を抽出する機能を提供する（後述のＳ４０１〜で詳述する）。レコード検索部３２０は、ある業務テーブルと、この業務テーブルに追加された追加フィールドの情報とをテーブル識別ＩＤ４１１をキーに追加フィールド管理テーブル４１０から抽出し、該当する業務テーブルと追加フィールドデータテーブル４４０から追加フィールドを付加した仮想的な業務テーブルのビューを作成し、このビューに対して検索を実施する。
レコード検索部３２０は、業務アプリケーション２１０からのレコード検索要求に対して、業務テーブル４３０と追加フィールドデータテーブル４４０とから適切にレコード情報を抽出する機能を提供する（後述のＳ４０１〜で詳述する）。レコード検索部３２０は、ある業務テーブルと、この業務テーブルに追加された追加フィールドの情報とをテーブル識別ＩＤ４１１をキーに追加フィールド管理テーブル４１０から抽出し、該当する業務テーブルと追加フィールドデータテーブル４４０から追加フィールドを付加した仮想的な業務テーブルのビューを作成し、このビューに対して検索を実施する。
（レコード削除部３３０）
レコード削除部３３０は、業務アプリケーション２１０からのレコード削除要求に対して、レコード削除要求に係る業務テーブルと追加フィールドデータテーブル４４０とに対してレコード情報を削除する機能を提供する。レコード削除部３３０は、ある業務テーブルとこの業務テーブルに追加されたフィールド情報とをテーブル識別ＩＤ４１１をキーに追加フィールド管理テーブル４１０から抽出し、該当する業務テーブルと追加フィールドデータテーブル４４０から追加フィールドを付加した仮想的な業務テーブルのビューを作成し、このビューに対して削除対象のレコードを特定し、全てのレコードのインデックス４３１（図６）、インデックス４４１（図７）によって、その業務テーブルと追加フィールドデータテーブル４４０の該当レコードを削除する。レコード削除は、後述のＳ５０１〜で詳述する。
レコード削除部３３０は、業務アプリケーション２１０からのレコード削除要求に対して、レコード削除要求に係る業務テーブルと追加フィールドデータテーブル４４０とに対してレコード情報を削除する機能を提供する。レコード削除部３３０は、ある業務テーブルとこの業務テーブルに追加されたフィールド情報とをテーブル識別ＩＤ４１１をキーに追加フィールド管理テーブル４１０から抽出し、該当する業務テーブルと追加フィールドデータテーブル４４０から追加フィールドを付加した仮想的な業務テーブルのビューを作成し、このビューに対して削除対象のレコードを特定し、全てのレコードのインデックス４３１（図６）、インデックス４４１（図７）によって、その業務テーブルと追加フィールドデータテーブル４４０の該当レコードを削除する。レコード削除は、後述のＳ５０１〜で詳述する。
（動的テーブル管理システム１００００の動作）
次に、システムの動作を以下に記述する。
次に、システムの動作を以下に記述する。
＜Ａ．業務テーブルへのフィールドの追加＞
業務テーブルに対して足りないフィールドを追加する場合を説明する。以下の説明Ａ〜Ｅでは、対象とする業務テーブルは、業務テーブルＡを想定する。図８は、フィールドを追加する動作を示すフローチャートである。
業務テーブルに対して足りないフィールドを追加する場合を説明する。以下の説明Ａ〜Ｅでは、対象とする業務テーブルは、業務テーブルＡを想定する。図８は、フィールドを追加する動作を示すフローチャートである。
Ｓ１０１において、入力手段５１０からＤＢ定義部１００（フィールド追加部１１０）に対して、「フィールドの追加」を要求するフィールド追加要求情報を入力する。すなわち、ユーザが入力手段５１０を用いて、ある業務テーブルに対するフィールド追加要求を入力すると、フィールド追加部１１０が、このフィールド追加要求を受け付ける。フィールド追加要求情報は、
（１）追加が要求されるフィードをする業務テーブのテーブル識別ＩＤ、
（２）追加が要求されるフィールドをその業務テーブルにおいて一意に識別するフィールドＩＤ、
（３）追加が要求されるフィールドの項目名（フィールド名称）、
（４）追加が要求されるフィールドに格納されるデータのデータ型
を含む。
（１）追加が要求されるフィードをする業務テーブのテーブル識別ＩＤ、
（２）追加が要求されるフィールドをその業務テーブルにおいて一意に識別するフィールドＩＤ、
（３）追加が要求されるフィールドの項目名（フィールド名称）、
（４）追加が要求されるフィールドに格納されるデータのデータ型
を含む。
Ｓ１０２において、
入力手段５１０から入力されたフィールド追加要求情報に従って、図４に示すように、
フィールド追加部１１０は、追加フィールド管理テーブル４１０に、
追加対象の業務テーブルを一意に識別可能なテーブル識別ＩＤ４１１と、
追加するフィールドを一意に識別するフィールドＩＤ４１２と、
追加するフィールドのデータ型を示すデータ型４１３と、
追加するフィールドの名称を示す項目名４１４との
情報をレコードとしてインサートする。
図９は、フィールド追加部１１０によるＳ１０２の処理内容をＳＱＬ文として示した。また、図１０は、このＳＱＬ文に対するフィールド追加部１１０によるＳ１０２の処理結果を示したものである。
入力手段５１０から入力されたフィールド追加要求情報に従って、図４に示すように、
フィールド追加部１１０は、追加フィールド管理テーブル４１０に、
追加対象の業務テーブルを一意に識別可能なテーブル識別ＩＤ４１１と、
追加するフィールドを一意に識別するフィールドＩＤ４１２と、
追加するフィールドのデータ型を示すデータ型４１３と、
追加するフィールドの名称を示す項目名４１４との
情報をレコードとしてインサートする。
図９は、フィールド追加部１１０によるＳ１０２の処理内容をＳＱＬ文として示した。また、図１０は、このＳＱＬ文に対するフィールド追加部１１０によるＳ１０２の処理結果を示したものである。
Ｓ１０３において、フィールド追加部１１０は、追加フィールド管理テーブル４１０を参照することにより、追加フィールド管理テーブル４１０に追加（インサート）したレコードのデータ型４１３と同じデータ型のレコードが既に登録されているかどうかを検索する。フィールド追加部１１０は、いまだに登録されていない場合にはＳ１０４の処理を実行し、既に追加されている場合は終了する。
（追加フィールドデータテーブル４４０の動的作成）
Ｓ１０４において、フィールド追加部１１０は、業務テーブル４３０と追加フィールドデータテーブル４４０の互いのレコードを関連付けるインデックス４４１と、フィールドの追加対象となる業務テーブルを一意に識別可能なテーブル識別ＩＤ４４２と、追加したフィールドをこのフィールドか追加される業務テーブルとの関係において識別するフィールドＩＤ４４３と、データ型４１３で定義された型を格納可能な「値４４４」とのフィールドを持つ追加フィールドデータテーブル４４０を動的に作成する。
Ｓ１０４において、フィールド追加部１１０は、業務テーブル４３０と追加フィールドデータテーブル４４０の互いのレコードを関連付けるインデックス４４１と、フィールドの追加対象となる業務テーブルを一意に識別可能なテーブル識別ＩＤ４４２と、追加したフィールドをこのフィールドか追加される業務テーブルとの関係において識別するフィールドＩＤ４４３と、データ型４１３で定義された型を格納可能な「値４４４」とのフィールドを持つ追加フィールドデータテーブル４４０を動的に作成する。
以上により、フィールドか追加される業務テーブルに対して、仮想的にフィールドが追加される。この仮想的に追加されたフィールド（実際には業務テーブルに存在しないフィールド）を追加フィールドと呼ぶ。
＜Ｂ．追加フィールドを削除する処理＞
次に、図１１を参照して、追加フィールドを削除する処理を説明する。図１１は、ある業務テーブルに対して追加された追加フィールドを検索し、ヒットした追加フィールドを削除する処理を示すフローチャートである。
次に、図１１を参照して、追加フィールドを削除する処理を説明する。図１１は、ある業務テーブルに対して追加された追加フィールドを検索し、ヒットした追加フィールドを削除する処理を示すフローチャートである。
Ｓ２０１において、ユーザは、まず、入力手段５１０からＤＢ定義部１００に対して、「ある業務テーブルの追加フィールドの検索要求」を入力する。追加フィールド取得部１２０は、この「検索要求」に応答して、テーブル識別ＩＤを検索キーにして、追加フィールド管理テーブル４１０から、
追加対象の業務テーブルを一意に識別可能なテーブル識別ＩＤ４１１と、
追加したフィールドを一意に識別するためのフィールドＩＤ４１２と、
追加したフィールドのデータ型を示すデータ型４１３と、
追加したフィールドの名称を示す項目名４１４との
情報を取得する。
図１２は、追加フィールド取得部１２０によるＳ２０１の処理内容をＳＱＬ文として示したものである。また、図１３及び図１４は、このＳＱＬ文に対する追加フィールド取得部１２０によるＳ２０１の処理結果を示したものである。図１３は、図１２の上段のｓｅｌｅｃｔ文に対応し、図１４は、図１２の下段のｓｅｌｅｃｔ文に対応する。
追加対象の業務テーブルを一意に識別可能なテーブル識別ＩＤ４１１と、
追加したフィールドを一意に識別するためのフィールドＩＤ４１２と、
追加したフィールドのデータ型を示すデータ型４１３と、
追加したフィールドの名称を示す項目名４１４との
情報を取得する。
図１２は、追加フィールド取得部１２０によるＳ２０１の処理内容をＳＱＬ文として示したものである。また、図１３及び図１４は、このＳＱＬ文に対する追加フィールド取得部１２０によるＳ２０１の処理結果を示したものである。図１３は、図１２の上段のｓｅｌｅｃｔ文に対応し、図１４は、図１２の下段のｓｅｌｅｃｔ文に対応する。
Ｓ２０１の結果、例えば、図１３の結果が表示手段５２０に表示される。そして、Ｓ２０２において、ユーザは、入力手段５１０を用いて、表示手段５２０に表示された結果から削除する項目名（レコード）を指定する。追加フィールド削除部１３０は、この指定に応答し、テーブル識別ＩＤ４１１及びフィールドＩＤ４１２を削除キーにして、追加フィールド管理テーブル４１０に登録されているレコードのうち該当するレコードを削除する。図１５は、追加フィールド削除部１３０が追加フィールド管理テーブル４１０からレコードを削除する処理をＳＱＬ文として示したものである。また、追加フィールド削除部１３０は、テーブル識別ＩＤ４１１及びフィールドＩＤ４１２を削除キーとして、追加フィールドデータテーブル４４０にある実際のデータも削除する。図１６は、追加フィールド削除部１３０が追加フィールドデータテーブル４４０のレコードを削除する処理をＳＱＬ文として示したものである。
Ｓ２０３において、追加フィールド削除部１３０は、追加フィールド管理テーブル４１０を参照して、削除したレコードのデータ型４１３と同じデータ型を有するレコードが追加フィールド管理テーブル４１０に存在するか検索する。図１７は、追加フィールド削除部１３０が、追加フィールド管理テーブル４１０を対象として、削除したレコードと同じデータ型のレコードを検索する処理をＳＱＬ文として示したものである。同じデータ型を有するレコードが追加フィールド管理テーブル４１０に存在しない場合、処理はＳ２０４に進む。存在する場合、処理は終了する。
（追加フィールドデータテーブル４４０の動的削除）
Ｓ２０４において、追加フィールド削除部１３０は、該当する型の追加フィールドデータテーブル４４０を削除する。図１８は、追加フィールド削除部１３０が、該当する追加フィールドデータテーブル４４０を削除する処理をＳＱＬ文として示したものである。
Ｓ２０４において、追加フィールド削除部１３０は、該当する型の追加フィールドデータテーブル４４０を削除する。図１８は、追加フィールド削除部１３０が、該当する追加フィールドデータテーブル４４０を削除する処理をＳＱＬ文として示したものである。
＜Ｃ．業務テーブルへのデータレコードの新規登録処理＞
図１９は、ある業務テーブルに対してデータレコードを追加する場合のフローチャートである。
図１９は、ある業務テーブルに対してデータレコードを追加する場合のフローチャートである。
Ｓ３０１において、ＤＢ処理部３００に対して、ユーザは、入力手段５１０から希望する業務テーブルに対するデータレコードの追加要求（登録情報）を入力する。追加要求（登録情報）は、
「データレコードの新規登録を希望するテーブルＩＤ」と
「テーブルＩＤの示す業務テーブルのフィールドのフィールド名に対応する１以上のフィールド値」と
を含む。
また、「テーブルＩＤの示す業務テーブルの追加フィールドのフィールド名（項目名）に対応する１以上のフィールド値」を含んでよいことは当然である。ユーザは、データレコードのフィールド値が、追加フィールドに対するものかどうかを意識することは不要である。
「データレコードの新規登録を希望するテーブルＩＤ」と
「テーブルＩＤの示す業務テーブルのフィールドのフィールド名に対応する１以上のフィールド値」と
を含む。
また、「テーブルＩＤの示す業務テーブルの追加フィールドのフィールド名（項目名）に対応する１以上のフィールド値」を含んでよいことは当然である。ユーザは、データレコードのフィールド値が、追加フィールドに対するものかどうかを意識することは不要である。
Ｓ３０２において、レコード追加部３１０は、対象となる業務テーブルのレコードと、追加フィールドデータテーブルのレコードとを関連付けるインデックス４４１を生成するために、レコード関連付けインデックス管理テーブル４２０に格納されている発行済みインデックス４２１の最大値を取得し、１を足す。図２０は、インデックスを生成する処理の内容をＳＱＬ文として示したものである。
Ｓ３０３において、ＤＢ処理部３００のレコード追加部３１０は、テーブル識別ＩＤ４１１を検索キーにして、追加フィールド管理テーブル４１０から追加フィールドのデータ型４１３および項目名４１４の情報を取得する（更新要求ごとに、初回１回のみ実施する）。レコード追加部３１０は、追加フィールドがある場合は１件ごとにＳ３０４を実施し、
追加フィールドがない場合あるいは全追加フィールドに対してＳ３０４を実施済みの場合はＳ３０６を実施する。図２１は、該当する業務テーブル４３０として業務テーブルＡを対象として、追加フィールドデータテーブル４４０から業務テーブルＡのレコードを抽出する処理内容をＳＱＬ文として示したものである。図２２は、図２１のｓｅｌｅｃｔ文の実行結果（クエリ発行結果）を示している。
追加フィールドがない場合あるいは全追加フィールドに対してＳ３０４を実施済みの場合はＳ３０６を実施する。図２１は、該当する業務テーブル４３０として業務テーブルＡを対象として、追加フィールドデータテーブル４４０から業務テーブルＡのレコードを抽出する処理内容をＳＱＬ文として示したものである。図２２は、図２１のｓｅｌｅｃｔ文の実行結果（クエリ発行結果）を示している。
Ｓ３０４において、レコード追加部３１０は、Ｓ３０１の追加要求（登録情報）に、追加フィールドの項目名に対応するフィールド値（項目値）が含まれているか判定し、含まれていればＳ３０５を実施し、含まれていない場合はＳ３０３を実施する。
Ｓ３０５において、レコード追加部３１０は、追加フィールドのデータを追加フィールドデータテーブル４４０に格納する。図２３は、レコード追加部３１０によるＳ３０５の処理内容をＳＱＬ文として示したものである。図２４は、図２３のＳＱＬ文の実行の結果、データ型が「ＤＡＴＡ型」である追加フィールドデータテーブル４４０に「値」（追加要求に含まれていたフィールド値）が登録された状態を示している。図２５は、図２３のＳＱＬ文の実行の結果、データ型が「ＩＮＴ型」である追加フィールドデータテーブル４４０に「値」（追加要求に含まれていたフィールド値）が登録された状態を示している。
Ｓ３０６において、レコード追加部３１０は、該当する業務テーブルにデータを格納する。図２６は、レコード追加部３１０によるＳ３０６の処理内容をＳＱＬ文として示したものである。図２７は、図２６のＳＱＬ文の実行の結果、該当する業務テーブルに業務項目１、業務項目２等に、この業務テーブルに登録されるべきデータ（業務項目１、業務項目２等のフィールド値）が登録された状態を示す図である。
＜Ｄ．業務テーブルに対するデータレコードの検索処理＞
次に図２８を参照して、業務テーブルに対するデータ検索の処理を説明する。図２８は、業務テーブルに対してデータレコードを検索する処理を示すフローチャートである。
次に図２８を参照して、業務テーブルに対するデータ検索の処理を説明する。図２８は、業務テーブルに対してデータレコードを検索する処理を示すフローチャートである。
Ｓ４０１において、ユーザは、入力手段５１０を用いて、業務アプリケーション２１０を介することにより、ＤＢ処理部３００に対し、希望する業務テーブルに対するデータレコードの検索要求を送る。ＤＢ処理部３００では、レコード検索部３２０が、データレコードの検索要求を受け付ける。検索要求は、例えば、「業務テーブルＡ」のビューを生成することができるように、少なくとも業務テーブルＡの
「テーブル識別ＩＤ＝Ａ」
を含む。
「テーブル識別ＩＤ＝Ａ」
を含む。
Ｓ４０２において、レコード検索部３２０は、検索要求情報に含まれるテーブル識別ＩＤを検索キーにして、追加フィールド管理テーブル４１０から、
追加対象の業務テーブルを一意に識別可能なテーブル識別ＩＤ４１１と、
追加したフィールドを一意に識別するためのフィールドＩＤ４１２と、
追加したフィールドのデータ型４１３と、
項目名４１４と
を取得する。図２９は、レコード検索部３２０が追加フィールド管理テーブル４１０から業務テーブルＡのレコードを抽出する処理内容をＳＱＬ文として示したものである。図３０は、図２９のＳＱＬ文の実行の結果、該当するレコードが抽出された状態を示す図である。
追加対象の業務テーブルを一意に識別可能なテーブル識別ＩＤ４１１と、
追加したフィールドを一意に識別するためのフィールドＩＤ４１２と、
追加したフィールドのデータ型４１３と、
項目名４１４と
を取得する。図２９は、レコード検索部３２０が追加フィールド管理テーブル４１０から業務テーブルＡのレコードを抽出する処理内容をＳＱＬ文として示したものである。図３０は、図２９のＳＱＬ文の実行の結果、該当するレコードが抽出された状態を示す図である。
Ｓ４０３において、レコード検索部３２０は、Ｓ４０２の結果、追加フィールドがあれば（追加フィールド管理テーブル４１０からテーブル識別ＩＤのレコードが抽出された場合には）Ｓ４０４を実施し、なければＳ４０５から処理を実施する。
Ｓ４０４において、レコード検索部３２０は、Ｓ４０２の結果から、業務テーブルＡに対して業務テーブルＡの追加フィールドを加えたテーブルのビューを作成する。具体的には、レコード検索部３２０は、業務テーブルＡのレコードと、追加フィールドデータテーブル４４０のレコードとは、業務テーブルＡにおけるインデックス４３１と，追加フィールドデータテーブル４４０におけるインデックス４４１とから関連付けることができる。この場合、追加フィールドデータテーブル４４０は複数存在し得る。図３１は、レコード検索部３２０が、ビューを作成する処理をＳＱＬ文として示したものである。図３２は、図３１のＳＱＬ文の実行の結果、作成された業務テーブルのビューを示す図である。図３２に示すように、業務テーブルＡのフィールドである「業務項目１」、「業務項目１」等と業務テーブルＡの追加フィールドである追加項目１（ＤＡＴＡ型）、追加項目２（ＩＮＴ型）が追加されたビューが生成されている。そして、「業務項目１」、「業務項目１」のレコードと、追加項目１（ＤＡＴＡ型）、追加項目２（ＩＮＴ型）のデータ（フィールド値）とは、インデックスを介して結合される。図３２では、それぞれのインデックス９、１０等のレコードが一つの意味あるレコードとなっている。
Ｓ４０５において、レコード検索部３２０は、業務テーブルＡに対し検索を実行する。追加フィールドがある場合は、Ｓ４０４の結果によるビューに対して、検索条件をＷｈｅｒｅ句に追加して記述する。図３３は、レコード検索部３２０が、業務テーブルＡを対象として図３３に示す検索条件でデータレコードを検索する処理をＳＱＬ文として示したものである。図３４は、図３３のＳＱＬ文の実行の結果、業務テーブルのビューにおいてインデックス９のレコードがヒットした状態を示している。
＜Ｅ．業務テーブルへのデータレコードの削除処理＞
次に、図３５を参照して、業務テーブルに対するデータレコードの削除処理を説明する。図３５は、業務テーブルＡからデータレコードを削除する場合のフローチャートを示す。Ｓ５０１〜Ｓ５０５は図２８のＳ４０１〜Ｓ４０５の検索処理と同じである。最後のＳ５０６が、図２８では検索実行であったのに対し、Ｓ５０６では、該当するデータレコードの削除処理となる点のみが異なる。
次に、図３５を参照して、業務テーブルに対するデータレコードの削除処理を説明する。図３５は、業務テーブルＡからデータレコードを削除する場合のフローチャートを示す。Ｓ５０１〜Ｓ５０５は図２８のＳ４０１〜Ｓ４０５の検索処理と同じである。最後のＳ５０６が、図２８では検索実行であったのに対し、Ｓ５０６では、該当するデータレコードの削除処理となる点のみが異なる。
Ｓ５０１において、ユーザは、入力手段５１０を用いて業務アプリケーション２１０を介することにより、ＤＢ処理部３００に対し、業務テーブルＡからのデータレコードの削除を求める削除要求を送る。ＤＢ処理部３００のレコード削除部３３０は、データレコードの検索要求を受け付ける。
Ｓ５０２において、レコード削除部３３０は、テーブル識別ＩＤを検索キーにして追加フィールド管理テーブル４１０から、
少なくとも追加対象の業務テーブルを一意に識別可能なテーブル識別ＩＤ４１１と、
追加したフィールドを一意に識別するためのフィールドＩＤ４１２と、
追加したフィールドのデータ型４１３
および
項目名４１４の
情報を取得する。
図３６、図３７は、Ｓ４０２の図２９、図３０と同じである。
少なくとも追加対象の業務テーブルを一意に識別可能なテーブル識別ＩＤ４１１と、
追加したフィールドを一意に識別するためのフィールドＩＤ４１２と、
追加したフィールドのデータ型４１３
および
項目名４１４の
情報を取得する。
図３６、図３７は、Ｓ４０２の図２９、図３０と同じである。
Ｓ５０３において、Ｓ５０２の結果、追加フィールドがあればＳ５０４を実施し、なければＳ５０５から処理を実施する。
Ｓ５０４において、Ｓ５０２の結果から、業務テーブル４３０に対して追加フィールドを加えたテーブルを作成する。業務テーブル４３０と追加フィールドデータテーブル４４０はインデックス４３１，４４１に関連付けることができ、例えば、以下に示すようなＳＱＬ文によって、簡単にビューを作成することが可能である。図３８、図３９は、Ｓ４０４の図３１、図３２と同じである。
Ｓ５０５において、業務テーブルに対し検索を実行する。追加フィールドがある場合はＳ５０４の結果に対して、検索条件をＷｈｅｒｅ句に追加して記述する。図４０、図４１は、Ｓ４０４の図３３、図３４と同じである。
Ｓ５０６において、レコード削除部３３０は、Ｓ５０５の結果から、該当レコードのインデックス４３１，インデックス４４１をキーに、業務テーブル４３０と追加フィールドデータテーブル４４０に対してレコードを削除する。図４２は、レコード削除部３３０が、業務テーブルＡ、及び追加フィールド管理テーブル４１０からインデックスが９であるレコードを削除する処理をＳＱＬ文として示したものである。
各テーブルのフィールドと値が、どのような関連を持つのかを図４３に示す。
図４５を参照して、ビューの作成動作を説明する。各テーブルは、図４５に示すＲＤＢＭＳ４００の状態とする。この状態でレコード検索部３２０（あるいはレコード削除部３３０部）がビュー作成する場合を説明する。ビューの作成対象は業務テーブルＡとする。
（１）まず、入力手段５１０が、検索要求を受け付ける。検索要求には、業務テーブルＡのテーブルＩＤを含む。
（２）レコード検索部３２０は、入力手段５１０から業務アプリケーション２１０を介して検索要求情報（ビュー作成要求情報の一例）を受け付けると、検索要求情報に含まれたテーブルＩＤ「Ａ」をキーとしてこのテーブルＩＤ「Ａ」を持つレコードを追加フィールド管理テーブル４１０のなかから第１レコードとして特定する。図４５の場合、「Ａ，００１，ＤＡＴＡ，生年月日」と「Ａ，００２，ＩＮＴ，年齢」とのレコード（第１レコード）が特定される。
（３）レコード検索部３２０は、「Ａ，００１，ＤＡＴＡ，生年月日」及び「Ａ，００２，ＩＮＴ年齢」の示すデータ型の追加フィールドデータテーブルに対して、すなわち、追加フィールドデータテーブル４４０−１、追加フィールドデータテーブル４４００−２とに対して、これらのレコードの示すフィールドＩＤ「００１」、「００２」をキーとしてこのフィールドＩＤをもつレコードを追加フィールドデータテーブル４４０−１、４４０−２から特定する。図４５の場合は、それぞれ「９，Ａ，００１，生年月日」と「９，Ａ，００２，年齢」とのレコード（第２レコード）が特定される。
（４）レコード検索部３２０は、フィールドＩＤを同じくする第１レコードと第２レコードとの間で第２レコードの示すフィールド値と第１レコードの示すフィールド名称とを対応付ける。この例では、「生年月日」（フィールド名称）と「１９８０／１／１」（フィールド値）とが対応付けられ、「年齢」（フィールド名称）と「２７」（フィールド値）とが対応付けられる。
（５）レコード検索部３２０は、フィールド名称が対応付けられたフィールド値をこのフィールド値の元となる第２レコードの示すインデックスと同一のインデックスを持つレコードであって登録テーブルに登録されているレコードに結合する。すなわちレコード検索部３２０は、「生年月日：１９８０／１／１」及び「年齢：２７」を業務テーブルＡにおけるインデックス「９」のレコード「ニッポン，タロウ」に結合する。よってレコード「苗字，名前，生年月日，年齢」の項目からなるレコードとして「ニッポン，タロウ，１９８０／１／１，２７」が作成される。業務テーブルＡの複数のレコードに対して同じ処理が実行されることで、業務テーブルＡのビューが生成される。
図４５を参照して、ビューの作成動作を説明する。各テーブルは、図４５に示すＲＤＢＭＳ４００の状態とする。この状態でレコード検索部３２０（あるいはレコード削除部３３０部）がビュー作成する場合を説明する。ビューの作成対象は業務テーブルＡとする。
（１）まず、入力手段５１０が、検索要求を受け付ける。検索要求には、業務テーブルＡのテーブルＩＤを含む。
（２）レコード検索部３２０は、入力手段５１０から業務アプリケーション２１０を介して検索要求情報（ビュー作成要求情報の一例）を受け付けると、検索要求情報に含まれたテーブルＩＤ「Ａ」をキーとしてこのテーブルＩＤ「Ａ」を持つレコードを追加フィールド管理テーブル４１０のなかから第１レコードとして特定する。図４５の場合、「Ａ，００１，ＤＡＴＡ，生年月日」と「Ａ，００２，ＩＮＴ，年齢」とのレコード（第１レコード）が特定される。
（３）レコード検索部３２０は、「Ａ，００１，ＤＡＴＡ，生年月日」及び「Ａ，００２，ＩＮＴ年齢」の示すデータ型の追加フィールドデータテーブルに対して、すなわち、追加フィールドデータテーブル４４０−１、追加フィールドデータテーブル４４００−２とに対して、これらのレコードの示すフィールドＩＤ「００１」、「００２」をキーとしてこのフィールドＩＤをもつレコードを追加フィールドデータテーブル４４０−１、４４０−２から特定する。図４５の場合は、それぞれ「９，Ａ，００１，生年月日」と「９，Ａ，００２，年齢」とのレコード（第２レコード）が特定される。
（４）レコード検索部３２０は、フィールドＩＤを同じくする第１レコードと第２レコードとの間で第２レコードの示すフィールド値と第１レコードの示すフィールド名称とを対応付ける。この例では、「生年月日」（フィールド名称）と「１９８０／１／１」（フィールド値）とが対応付けられ、「年齢」（フィールド名称）と「２７」（フィールド値）とが対応付けられる。
（５）レコード検索部３２０は、フィールド名称が対応付けられたフィールド値をこのフィールド値の元となる第２レコードの示すインデックスと同一のインデックスを持つレコードであって登録テーブルに登録されているレコードに結合する。すなわちレコード検索部３２０は、「生年月日：１９８０／１／１」及び「年齢：２７」を業務テーブルＡにおけるインデックス「９」のレコード「ニッポン，タロウ」に結合する。よってレコード「苗字，名前，生年月日，年齢」の項目からなるレコードとして「ニッポン，タロウ，１９８０／１／１，２７」が作成される。業務テーブルＡの複数のレコードに対して同じ処理が実行されることで、業務テーブルＡのビューが生成される。
＜Ｆ．業務テーブルのデータレコードへの更新処理＞
次に、図４４を参照して、業務テーブルに対するデータレコードの更新処理を説明する。図４４は、業務テーブルＡに対して、追加済み（登録済み）のデータレコードを更新する処理のフローチャートを示す。具体的な例を用いて説明する。
次に、図４４を参照して、業務テーブルに対するデータレコードの更新処理を説明する。図４４は、業務テーブルＡに対して、追加済み（登録済み）のデータレコードを更新する処理のフローチャートを示す。具体的な例を用いて説明する。
（データ更新：Ｓ６０１）
業務テーブルＡに対して、新たに２つ目の追加フィールドとして「年齢」を追加したとする。（追加フィールド管理テーブル４１０におけるレコードは、『業務テーブルＡ（テーブル識別ＩＤ）、００２（フィールドＩＤ）、ＩＮＴ（データ型）、年齢（項目名）』とする。）すなわち、図８のフローチャートにしたがって、フィールド追加部１１０が、追加フィールドとして、「年齢」を追加しているとする。図４５は、その状態を示している。図４５において、追加フィールド管理テーブル４１０には、「テーブル識別ＩＤ、フィールド識別ＩＤ、データ型、項目名」として、レコード「Ａ，００１、ＤＡＴＡ、生年月日」に対して、さらに、レコード「Ａ，００２、ＩＮＴ、年齢」が追加されている状態である。そして、フィールド追加部１１０は、レコード「Ａ，００２、ＩＮＴ、年齢」の登録に関連して、追加フィールドデータテーブル４４０−１に加えて、追加フィールドデータテーブル４４０−２を作成した状態である。ここで、ユーザは、業務テーブルＡについて、既に登録して済みである『ニッポン（苗字）、タロウ（名前）』のレコードを検索し、インデックスが”９”であることを確認する。そして、ユーザは、業務テーブルＡに対し、インデックスが”９”のレコードについて、“年齢”フィールドを”２７”才に更新要求する。ユーザは、予め、図４５に示した検索処理などの機能によって、更新対象の「テーブル識別ＩＤ」と「インデックス」を特定しておく。そして、ユーザは入力手段５１０から更新要求情報を入力する。ここで、更新要求情報は、インデックス、テーブルＩＤ、項目名、フィールド値を含む。図４５には、更新要求情報の例として、「インデックス、テーブルＩＤ、項目名、フィールド値」＝「９，Ａ，年齢，２７」を示している。ユーザは、入力手段５１０から「９，Ａ，年齢，２７」を入力する。
業務テーブルＡに対して、新たに２つ目の追加フィールドとして「年齢」を追加したとする。（追加フィールド管理テーブル４１０におけるレコードは、『業務テーブルＡ（テーブル識別ＩＤ）、００２（フィールドＩＤ）、ＩＮＴ（データ型）、年齢（項目名）』とする。）すなわち、図８のフローチャートにしたがって、フィールド追加部１１０が、追加フィールドとして、「年齢」を追加しているとする。図４５は、その状態を示している。図４５において、追加フィールド管理テーブル４１０には、「テーブル識別ＩＤ、フィールド識別ＩＤ、データ型、項目名」として、レコード「Ａ，００１、ＤＡＴＡ、生年月日」に対して、さらに、レコード「Ａ，００２、ＩＮＴ、年齢」が追加されている状態である。そして、フィールド追加部１１０は、レコード「Ａ，００２、ＩＮＴ、年齢」の登録に関連して、追加フィールドデータテーブル４４０−１に加えて、追加フィールドデータテーブル４４０−２を作成した状態である。ここで、ユーザは、業務テーブルＡについて、既に登録して済みである『ニッポン（苗字）、タロウ（名前）』のレコードを検索し、インデックスが”９”であることを確認する。そして、ユーザは、業務テーブルＡに対し、インデックスが”９”のレコードについて、“年齢”フィールドを”２７”才に更新要求する。ユーザは、予め、図４５に示した検索処理などの機能によって、更新対象の「テーブル識別ＩＤ」と「インデックス」を特定しておく。そして、ユーザは入力手段５１０から更新要求情報を入力する。ここで、更新要求情報は、インデックス、テーブルＩＤ、項目名、フィールド値を含む。図４５には、更新要求情報の例として、「インデックス、テーブルＩＤ、項目名、フィールド値」＝「９，Ａ，年齢，２７」を示している。ユーザは、入力手段５１０から「９，Ａ，年齢，２７」を入力する。
Ｓ６０２おいて、レコード更新部３４０は、更新要求情報に含まれるテーブル識別ＩＤである”業務テーブルＡ”を検索キーとして、追加フィールド管理テーブル４１０からデータ型および項目名を取得する（更新要求ごとに、初回１回のみ実施する）。図４６は、レコード更新部３４０が、追加フィールド管理テーブル４１０を対象として業務テーブルＡの行うレコードの取得処理をＳＱＬ文として示したものである。図４７は、図４６のＳＱＬ文の実行の結果、図４５の追加フィールド管理テーブル４１０から、フィールドＩＤが「００１」と「００２」との２つのレコードを取得したことを示している。
まずは、レコード更新部３４０は、１つ目の追加フィールド”生年月日”について、Ｓ６０３を実施する。すなわち、Ｓ６０３おいて、レコード更新部３４０は、更新要求情報の項目名として、”生年月日”が存在するかを確認する。この例では存在しないので、処理はＳ６０２に戻る。
Ｓ６０２おいて、２つ目の追加フィールド”年齢”について、Ｓ６０３を実施する。Ｓ６０３おいて、レコード更新部３４０は、更新要求の項目名に”年齢”が存在するかを確認する。この例では存在するため、レコード更新部３４０はＳ６１３を実施する。
Ｓ６１３おいて、年齢はＩＮＴ型であるので、レコード更新部３４０は、追加フィールドデータテーブル４４０−２［ＩＮＴ型］に対して、更新要求情報である「９，Ａ，年齢，２７」に対応するレコードが存在するかをインデックスをキーに判定する。すなわちレコード更新部３４０は、追加フィールドデータテーブル４４０−２に「インデックス＝９」のレコードが存在するかどうかを判定する。レコード更新部３４０が、「インデックス＝９」のレコードの存在を判定する処理をＳＱＬ文として示したものである。図４５に示すように、追加フィールドデータテーブル４４０−２は作成されてはいるが、レコードは登録されていない状態とする。このため、『９（インデックス）、業務テーブルＡ（テーブル識別ＩＤ）、００２（フィールドＩＤ）、２７（年齢）』のレコードは、まだ追加フィールドデータテーブル４４０−２には登録されておらず、結果として、レコードが検索されない。図４９は、図４８のＳＱＬ文の実行の結果、レコードが検索されない状態を示している。
レコードは存在しないため、レコード更新部３４０は、Ｓ６１４を実施する。すなわち、レコード更新部３４０は、Ｓ６１４において、追加フィールドデータテーブル４４０−２［ＩＮＴ型］に対して、「９，Ａ，年齢，２７」に対応するレコードである『９（インデックス）、業務テーブルＡ（テーブル識別ＩＤ）、００２（フィールドＩＤ）、２７（値）』を追加する。図５０は、レコード更新部３４０による追加フィールドデータテーブル４４０−２［ＩＮＴ型］へのレコードの登録処理を示したものである。「００２（フィールドＩＤ）」は、更新要求情報「９，Ａ，年齢，２７」に含まれるテーブル識別ＩＤ及び項目名から追加フィールド管理テーブル４１０のレコードが決定するので、決定されたレコードから「００２（フィールドＩＤ）」が決まる。
Ｓ６１４からＳ６０２へ戻るが、Ｓ６０２では未処理の追加フィールドは存在しないので、処理はＳ６１５に進む。
Ｓ６１５おいて、レコード更新部３４０は、Ｓ６０１で入力した更新要求情報に、追加フィールド以外の、つまり業務テーブルＡへの更新要求（この例では、苗字あるいは名前）があるか判定する。この例では存在しないので処理は終了する。
以上の処理の結果、図４５に示すように、更新用要求情報「９，Ａ，年齢，２７」の入力に対して、追加フィールドデータテーブル４４０−２にレコード「９，Ａ，００２，２７」が追加（登録）される。
図４４の更新処理のフローチャートについての一般的処理を簡単に説明する。
Ｓ６０１において、ユーザは、ＤＢ処理部３００に対して業務テーブルに対するデータレコードの更新要求（テーブル識別ＩＤ、インデックス、項目名と値）を要求する。
Ｓ６０２において、ＤＢ処理部３００のレコード更新部３４０は、テーブル識別ＩＤを検索キーにして、追加フィールド管理テーブル４１０から、追加フィールドのデータ型４１３および項目名４１４の情報を取得する（更新要求ごとに、初回１回のみ実施する）。追加フィールドがある場合は１件ごとにＳ６０３を実施し、追加フィールドがない場合、あるいは全追加フィールドに対してＳ６０３を実施済みの場合はＳ６０５を実施する。図５１は、レコード更新部３４０が、追加フィールド管理テーブル４１０から業務テーブルＡのレコードを取得するしょりをＳＱＬ文として示したものである。図５２は、図５１のＳＱＬ文の実行の結果、業務テーブルＡのレコードが取得された状態を示している。
Ｓ６０３において、レコード更新部３４０は、Ｓ６０１の更新要求情報に処理対象となる追加フィールドが含まれているか判定し、含まれていればＳ６１３を実施し、含まれていない場合はＳ６０２を実施する。
Ｓ６１３において、レコード更新部３４０は、処理対象の追加フィールドに対する追加フィールドデータテーブル４４０に、更新要求情報に対応するデータレコードが存在するか判定し、存在すればＳ６０４を実施し、存在しなければＳ６１４を実施する。図５３は、レコード更新部３４０が、追加フィールドデータテーブル４４０から該当するレコードを取得する処理をＳＱＬ文として示したものである。図５４は、図５３のＳＱＬ文の実行の結果、業務テーブルＡのレコードが取得された状態を示している。
Ｓ６０４において、レコード更新部３４０は、Ｓ６１３の結果から、対象となる追加フィールドデータテーブル４４０に対して、更新要求情報のデータ内容に更新する。図５５は、レコード更新部３４０が、追加フィールドデータテーブル４４０の該当するレコードを更新する処理をＳＱＬ文として示したものである。図５６は、図５５のＳＱＬ文の実行の結果、追加フィールドデータテーブル４４０のレコードが更新された状態を示している。
Ｓ６１４の場合は、すなわち、該当するデータ型の追加フィールドデータテーブル４４０に更新要求情報のインデックスをもつ存在しない場合は、レコード更新部３４０は、追加フィールドデータテーブル４４０に対して、要求要求情報に対応するレコードを追加する。図５７は、レコード更新部３４０が、追加フィールドデータテーブル４４０にレコードを追加する処理をＳＱＬ文として示したものである。図５８は、図５７のＳＱＬ文の実行の結果、追加フィールドデータテーブル４４０に更新要求情報に対応するレコードが追加された状態を示している。
Ｓ６１５において、レコード更新部３４０は、業務テーブルに対する更新項目があればＳ６０５を実施し、なければ終了する。
Ｓ６０５において、レコード更新部３４０は、更新要求情報のテーブル識別ＩＤの示す業務テーブルに対して、更新要求情報のデータを格納することによりデータ更新する。図５９は、レコード更新部３４０が、業務テーブルの該当するデータを更新する処理をＳＱＬ文として示したものである。図６０は、図５９のＳＱＬ文の実行の結果、業務テーブルの該当するデータが更新された状態を示している。
以上のように、実施の形態１による動的テーブル管理システム１００００によれば、追加フィールドの値を格納するために別テーブルをデータ型別に用意することで、ＲＤＢＭＳで用意されている全てのデータ型について関数などの機能を利用して格納／検索の可能なシステムを提供することができる。
１００ ＤＢ定義部、１１０ フィールド追加部、１２０ 追加フィールド取得部、１３０ 追加フィールド削除部、２００ 業務アプリケーション実行部、２１０ 業務アプリケーション、３００ ＤＢ処理部、３１０ レコード追加部、３２０ レコード検索部、３３０ レコード削除部、３４０ レコード更新部、４００ ＲＤＢＭＳ、４１０ 追加フィールド管理テーブル、４１１ テーブル識別ＩＤ、４１２ フィールドＩＤ、４１３ データ型、４１４ 項目名、４２０ レコード関連付けインデックス管理テーブル、４２１ 発行済みインデックス、４３０ 業務テーブル、４３１ インデックス、４３２ 業務情報、４３３ 業務情報、４４０ 追加フィールドデータテーブル、４４１ インデックス、４４２ テーブル識別ＩＤ、４４３ フィールドＩＤ、４４４ 値、５１０ 入力手段、５２０ 表示手段、１０００ 業務サーバ、１００００ 動的テーブル管理システム。
Claims (4)
- テーブルを管理するテーブル管理装置において、
インデックスのフィールドと名称が付与された１以上のフィールドとのそれぞれのフィールド値からなるレコードを１レコードとして登録する複数の登録テーブルを格納するテーブル格納部と、
前記複数の登録テーブルのうちのいずれかを一意に示すテーブルＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）と、テーブルＩＤの示す登録テーブルのフィールド名称に対応するフィールド値とを含む登録用情報の入力を受け付ける入力受付部と、
前記入力受付部により受け付けられた登録用情報にこの登録用情報を特定するインデックスを付与し、インデックスの付与された登録用情報のうちテーブルＩＤを除くインデックスとフィールド値とを１レコードとして、この登録用情報に含まれるテーブルＩＤの示す登録テーブルに登録する登録部と
を備え、
前記入力受付部は、
フィールドの追加を要求する情報であって、テーブルＩＤと、このテーブルＩＤの示す登録テーブルとの関係において追加が要求されるフィールドに一意に付与されたフィールドＩＤと、追加が要求されるフィールドのフィールド名称と、追加が要求されるフィールドに格納されるフィールド値のデータ型とを含むとともに、テーブルＩＤの示す登録テーブルに対してフィールド名称の示すフィールドの追加を要求するフィールド追加要求情報を受け付け、
前記テーブル管理装置は、さらに、
追加フィールド管理テーブルを格納する追加フィールド管理テーブル格納部と、
前記入力受付部がフィールド追加要求情報を受け付けると、
フィールド追加要求情報に含まれるテーブルＩＤと、フィールドＩＤと、フィールド名称と、データ型とを１レコードとして前記追加フィールド管理テーブルに登録するとともに、フィールド追加要求情報に含まれるデータ型のフィールド値を格納する追加フィールドデータテーブルが既に作成されているかどうかを判定し、作成されていないと判定すると、インデックスと、テーブルＩＤと、フィールドＩＤと、フィールド値との項目からなるテーブルであって、フィールド値としてフィールド追加要求情報に含まれるデータ型を格納する追加フィールドデータテーブルを作成するフィールド追加部と
備え、
前記入力受付部は、
インデックスと、テーブルＩＤと、フィールド名称と、このフィールド名称に対応する値とを含む情報であって前記テーブルＩＤの示す登録用テーブルにおける前記インデックスの示すレコードの更新を要求する更新要求情報の入力を受け付け、
前記テーブル管理装置は、さらに、
前記入力受付部が更新要求情報を受け付けると、この更新要求情報に含まれるテーブルＩＤとフィールド名称とに基づいて、前記追加フィールド管理テーブルに登録されたレコードのうち更新要求情報に含まれるテーブルＩＤとフィールド名称とをもつレコードを特定し、特定された特定レコードに含まれるデータ型からこのデータ型の追加フィールドデータテーブルを特定し、特定された追加フィールドデータテーブルの中に更新要求情報に含まれるインデックスを有するレコードが存在するかどうかを判定し、判定の結果、存在しないと判定すると、更新要求情報に含まれるインデックス、テーブルＩＤ、フィールド名称に対応する値、及び前記追加フィールド管理テーブルにおいて特定された特定レコードに含まれるフィールドＩＤとを１レコードとして前記追加フィールドデータテーブルに登録する更新部を備えたことを特徴とするテーブル管理装置。 - 前記入力受付部が受け付ける登録情報は、
テーブルＩＤ、フィールド値に加え、さらに、前記追加フィールド管理テーブルに登録された少なくともいずれかのレコードの有するフィールド名称に対応するフィールド値である管理フィールド値を含み、
前記登録部は、
前記入力受付部により受け付けられた登録情報に、この登録情報を特定するインデックスを付与し、インデックスの付与された登録情報に含まれるテーブルＩＤと管理フィールド値とに基づいて前記追加フィールド管理テーブルに登録されたレコードのうち登録情報に含まれるテーブルＩＤと、管理フィールド値に対応するフィールド名称とをもつレコードを特定し、特定された特定レコードに含まれるデータ型の追加フィールドデータテーブルに、付与されたインデックスと、登録情報にふくまれるテーブルＩＤと、前記追加フィールド管理テーブルにおいて特定された特定レコードに含まれる追加フィールドＩＤと、登録情報に含まれる管理フィールド値とを１レコードとして登録するとともに、登録情報に含まれるフィールド値に生成されたインデックスを付与し、インデックスの付与されたフィールド値を１レコードとして、登録情報に含まれるテーブルＩＤの示す登録テーブルに登録することを特徴とする請求項１記載のテーブル管理装置。 - 前記入力受付部は、
ビューの作成対象となる登録テーブルのテーブルＩＤを含むとともに、テーブルＩＤの示す登録テーブルに対するビューの作成を要求するビュー作成要求情報を受け付け、
前記テーブル管理装置は、さらに、
前記入力受付部がビュー作成要求情報を受け付けると、ビュー作成要求情報に含まれたテーブルＩＤをキーとしてこのテーブルＩＤを持つレコードを追加フィールド管理テーブルのなかから第１レコードとして特定し、第１コードの示すデータ型の前記追加フィールドデータテーブルに対して、第１レコードの示すフィールドＩＤをキーとしてこのフィールドＩＤをもつレコードを追加フィールドデータテーブルから第２レコードとして特定し、フィールドＩＤを同じくする第１レコードと第２レコードとの間で第２レコードの示すフィールド値と第１レコードの示すフィールド名称とを対応付け、フィールド名称が対応付けられたフィールド値をこのフィールド値の元となる第２レコードの示すインデックスと同一のインデックスを持つレコードであって登録テーブルに登録されているレコードに結合することにより、ビュー作成要求情報に含まれたテーブルＩＤの示す登録テーブルのビューを作成するビュー作成部を備えたことを特徴とする請求項１または２のいずれかに記載のテーブル管理装置。 - 前記入力受付部は、
前記追加フィールド管理デーブルに登録されている特定のレコードを指定するとともに指定されたレコードの削除を要求する削除指示情報を受け付け、
前記テーブル管理装置は、さらに、
前記入力受付部が削除指示情報を受け付けると、削除指示情報により指示されたレコードを追加フィールド管理テーブルから削除するとともに、削除後に、削除されたレコードの有するデータ型と同じデータ型を有するレコードが残っているかを判定し、残っていないと判定すると、削除されたレコードの有するデータ型の追加フィールドデータテーブルを削除する追加フィールド削除部を備えたことを特徴とする請求項１〜３のいずれかに記載のテーブル管理装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2007321563A JP2009146084A (ja) | 2007-12-13 | 2007-12-13 | テーブル管理装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2007321563A JP2009146084A (ja) | 2007-12-13 | 2007-12-13 | テーブル管理装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2009146084A true JP2009146084A (ja) | 2009-07-02 |
Family
ID=40916636
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007321563A Pending JP2009146084A (ja) | 2007-12-13 | 2007-12-13 | テーブル管理装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2009146084A (ja) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2015022575A (ja) * | 2013-07-19 | 2015-02-02 | 富士通株式会社 | データ管理プログラム、データ管理装置およびデータ管理方法 |
| CN110019242A (zh) * | 2017-12-29 | 2019-07-16 | 北京京东尚科信息技术有限公司 | 用于数据表的处理方法、装置和系统 |
| CN110196877A (zh) * | 2018-08-17 | 2019-09-03 | 平安科技（深圳）有限公司 | 数据展示方法、装置、计算机设备及存储介质 |
| US20200042510A1 (en) * | 2015-12-19 | 2020-02-06 | The Von Drakk Corporation | Method and device for correlating multiple tables in a database environment |
| US10922299B2 (en) | 2018-04-24 | 2021-02-16 | The Von Drakk Corporation | Correlating multiple tables in a non-relational database environment |
| KR20210097984A (ko) * | 2020-01-31 | 2021-08-10 | 이화여자대학교 산학협력단 | 교육 관광 데이터베이스 구축장치, 방법 및 교육 관광 검색서버 |
-
2007
- 2007-12-13 JP JP2007321563A patent/JP2009146084A/ja active Pending
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2015022575A (ja) * | 2013-07-19 | 2015-02-02 | 富士通株式会社 | データ管理プログラム、データ管理装置およびデータ管理方法 |
| US20200042510A1 (en) * | 2015-12-19 | 2020-02-06 | The Von Drakk Corporation | Method and device for correlating multiple tables in a database environment |
| CN110019242A (zh) * | 2017-12-29 | 2019-07-16 | 北京京东尚科信息技术有限公司 | 用于数据表的处理方法、装置和系统 |
| US10922299B2 (en) | 2018-04-24 | 2021-02-16 | The Von Drakk Corporation | Correlating multiple tables in a non-relational database environment |
| US11151112B2 (en) | 2018-04-24 | 2021-10-19 | The Von Drakk Corporation | Correlating multiple tables in a non-relational database environment |
| CN110196877A (zh) * | 2018-08-17 | 2019-09-03 | 平安科技（深圳）有限公司 | 数据展示方法、装置、计算机设备及存储介质 |
| CN110196877B (zh) * | 2018-08-17 | 2024-05-07 | 平安科技（深圳）有限公司 | 数据展示方法、装置、计算机设备及存储介质 |
| KR20210097984A (ko) * | 2020-01-31 | 2021-08-10 | 이화여자대학교 산학협력단 | 교육 관광 데이터베이스 구축장치, 방법 및 교육 관광 검색서버 |
| KR102357200B1 (ko) | 2020-01-31 | 2022-01-28 | 이화여자대학교 산학협력단 | 교육 관광 데이터베이스 구축장치, 방법 및 교육 관광 검색서버 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9600507B2 (en) | Index structure for a relational database table | |
| US7386568B2 (en) | Techniques for partial rewrite of XPath queries in a relational database | |
| US8301610B2 (en) | Optimizing search for insert-only databases and write-once data storage | |
| US20150234870A1 (en) | Dynamic mapping of extensible datasets to relational database schemas | |
| US7526469B2 (en) | Method and system of database management with shared area | |
| WO2018097846A1 (en) | Edge store designs for graph databases | |
| JP2009146084A (ja) | テーブル管理装置 | |
| JP2016126788A (ja) | 関係型データベース表の列横断的検索 | |
| JP2008009861A (ja) | システム構成管理方式 | |
| US20090193420A1 (en) | Method and system for batch processing form data | |
| US9430554B2 (en) | Object-relational mapping based on virtual columns | |
| JP5186270B2 (ja) | データベースのキャッシュシステム | |
| US9576008B2 (en) | System and method for search indexing | |
| CA3089289C (en) | System and methods for loading objects from hash chains | |
| US20180144060A1 (en) | Processing deleted edges in graph databases | |
| KR20150123603A (ko) | 데이터베이스 관리 방법 및 데이터베이스 관리 시스템 | |
| JP2007334412A (ja) | 検索プログラムおよび検索装置 | |
| CN114116907A (zh) | 一种数据库的同步方法、装置、电子设备和存储介质 | |
| US11256679B2 (en) | Systems and methods for storing object state on hash chains | |
| JP7274293B2 (ja) | 情報処理装置、情報処理方法及びプログラム | |
| US20100205197A1 (en) | Two-valued logic database management system with support for missing information | |
| US20160042022A1 (en) | Data coordination support apparatus and data coordination support method | |
| JP4825504B2 (ja) | データ登録・検索システムおよびデータ登録・検索方法 | |
| JP5606303B2 (ja) | 情報処理装置及び情報処理方法及びプログラム | |
| EP4009175A1 (en) | Simulation service providing a generic api endpoint |