JP2009054023A - データ管理方法、データ管理装置、データ管理システム、プログラム及び記録媒体 - Google Patents

Abstract

【課題】複数のレコード対応表を利用するデータ表現方法を改良して、スキーマの拡張が可能なデータ管理方法を提供する。
【解決手段】物理スキーマ１０７と、これに対応する論理スキーマ１０２とを用いて、フィールドと値を持つデータの登録をするデータ管理方法であって、物理スキーマ１０７は、論理スキーマ１０２の１レコードに対して１ないし複数のレコードを割り当てられており、少なくとも、論理スキーマ１０２の主キーに対応するフィールドと、レコード番号のフィールドと、を備え、論理スキーマ１０２の拡張をする際に、物理スキーマ１０７の空きフィールドがない場合、新規レコードを作成し、論理スキーマ１０２の主キーに対応するフィールドの値を変更せずそのままセットし、レコード番号の値をインクリメントしその値をレコード番号のフィールドにセットし、残りのフィールドにデータをセットすることを特徴とする。
【選択図】図１

Description

本発明は、データ管理方法、データ管理装置、データ管理システム、プログラム及び記録媒体に関し、特に、属性と値を持つデータのスキーマの拡張に関する。

文書管理システムのようなデータ管理システムを、データベースを使って実現する場合、のちの拡張を考慮してデータベースは、余裕を持って設計されるのが通常である。しかしながら、システムの拡張要求が当初の予想を上回ってしまうことがあるのが実情であり、そのような場合の要求に応えるためのデータベース拡張の技術が要請される。本発明は、この要請に応えるべくなされた発明である。

本発明に関連する技術としては、特許文献１ないし３に記載の技術がある。特許文献１に記載の技術は、書式データ入力方式に関し、任意の長さになりうる入力データを複数のレコードに分割して格納し、位置を覚えておく方法である。しかしながら、特許文献１にいう位置情報は、検索のためではなく構文解析のためにあり、本発明とは類似しない。

また、特許文献２は、一つのレコードに収まりきらない長さのレコードを分割する方法における典型的な例を開示する。しかしながら、特許文献２に記載のレコード方式には、スキーマの拡張及び検索に対する仕組みが存在しない。また、特許文献３に記載の文書管理装置等の技術は、フラットテキストデータを複数レコードにシーケンシャルに格納する際、シーケンシャル番号を使用している点で本発明と共通するが、その他の点では特に共通しない。
特開平０３−２０４０４５号公報 特開平０３−０４８９２５号公報 特開２００２−０９１９８２号公報

文書管理システムのようなデータ管理システムを、データベースを使って実現する場合、あらかじめ全てのデータを格納できるようスキーマを決定し、その上でアプリケーションを構築していくことが一般的である。スキーマは変更すると影響が大きいため、慎重に決定する必要がある。普通は、システムに対する拡張要求があることを見越して、ある程度の余裕を見て設計する。ところが、システムの拡張要求が当初の予想を上回る場合がある。

そのような場合、スキーマを再度設計し直すことになり、システム全体に影響が及ぶとともに、それまで蓄積してきたデータのコンバートが必要になる。あるいは、論理的なスキーマとデータベース上のスキーマの対応関係を保持し、複数のレコードを使用して一つのデータを表現することでスキーマを仮想的に拡張する方法もある。ただし、この方法ではデータベース上のスキーマを修正する必要はないが、論理的なスキーマ設計と対応表の保持が必要となる。また、いずれの場合でも以下のような問題が存在する。

第１の問題は、各属性に対して割り当てられるフィールドのデータサイズは決まっており、動的に変えることができないという問題である。なお、可変長データ型にすればある程度の柔軟性があるが、上限があることには変わりはない。そして、第２の問題は、属性の総数はあらかじめ決まっており、動的に変えることができないという問題である。

上記二つの問題を解決するためには、無制限可変長データ型のフィールドに動的に可変するデータ類を全て格納する方法がある。しかしながら、この方法では検索の精度や検索速度に問題が出ることが多く、また、無制限可変長データ型のフィールドがデータベース上のスキーマに存在しなければ使用できない。

本発明は上記実情に鑑みて、複数のレコード対応表を利用するデータ表現方法を改良して、スキーマの拡張が可能なデータ管理方法を提供することを目的とする。

上記目的を達成する請求項１記載の発明は、固定スキーマと、該固定スキーマに対応する論理スキーマとを用いて、フィールドと値を持つデータの登録をするデータ管理方法であって、前記固定スキーマは、前記論理スキーマの１レコードに対して１ないし複数のレコードを割り当てられており、少なくとも、前記論理スキーマの主キーに対応するフィールドと、レコード番号のフィールドと、を備え、前記論理スキーマの拡張をする際に、前記固定スキーマの空きフィールドがない場合、新規レコードを作成し、前記論理スキーマの主キーに対応するフィールドの値を変更せずそのままセットし、レコード番号の値をインクリメントし該値を前記レコード番号のフィールドにセットし、残りのフィールドにデータをセットすることを特徴とするデータ管理方法である。

請求項２記載の発明は、請求項１記載のデータ管理方法において、残りのフィールドデータをセットした後、前記固定スキーマと前記論理スキーマの対応関係を対応表に格納することを特徴とする。

請求項３記載の発明は、請求項１又は２記載のデータ管理方法において、前記固定スキーマにおける各フィールドに、対応する前記論理スキーマにおけるフィールド名が付加された値をセットすることを特徴とする。

請求項４記載の発明は、固定スキーマを備えるデータベース部と、前記固定スキーマに対応する論理スキーマを備えるアプリケーション部と、前記固定スキーマ及び前記論理スキーマを用いてフィールドと値を持つデータの登録をする登録部と、を有し、前記固定スキーマは、前記論理スキーマの１レコードに対して１ないし複数のレコードを割り当てられており、少なくとも、前記論理スキーマの主キーに対応するフィールドと、レコード番号のフィールドと、を備え、前記登録部は、前記論理スキーマの拡張をする際に、前記固定スキーマの空きフィールドがない場合、新規レコードを作成し、前記論理スキーマの主キーに対応するフィールドの値を変更せずそのままセットし、レコード番号の値をインクリメントし該値を前記レコード番号のフィールドにセットし、残りのフィールドにデータをセットすることを特徴とするデータ管理装置である。

請求項５記載の発明は、固定スキーマを備えるデータベースサーバと、前記固定スキーマに対応する論理スキーマを備えるアプリケーションサーバと、を有し、前記データベースサーバは、前記固定スキーマ及び前記論理スキーマを用いてフィールドと値を持つデータの登録をする登録部、を備え、前記固定スキーマは、前記論理スキーマの１レコードに対して１ないし複数のレコードを割り当てられており、少なくとも、前記論理スキーマの主キーに対応するフィールドと、レコード番号のフィールドと、を備え、前記登録部は、前記論理スキーマの拡張をする際に、前記固定スキーマの空きフィールドがない場合、新規レコードを作成し、前記論理スキーマの主キーに対応するフィールドの値を変更せずそのままセットし、レコード番号の値をインクリメントし該値を前記レコード番号のフィールドにセットし、残りのフィールドにデータをセットすることを特徴とするデータ管理システムである。

請求項６記載の発明は、コンピュータに、請求項１記載のデータ管理方法を実行させることを特徴とするプログラムである。

請求項７記載の発明は、請求項６記載のプログラムをコンピュータ読取可能に記録したことを特徴とする記録媒体である。

本発明によれば、スキーマの拡張が可能なデータ管理方法を提供することが可能となる。

以下、本発明の好適な実施の形態について図面を参照して説明する。
図１は、本実施形態に係るデータ管理装置の構成例を示すブロック図である。本実施形態に係るデータ管理装置は、データの検索と登録をする機能を持つ。なお、図１中で、実線は処理要求を、破線はデータの流れを表す。以下、図１に示す各ブロックについて説明する。

アプリケーション部１０１は、実際のサービスをシステムの利用者に提供する機能を果たす。アプリケーション部１０１は、実際のデータベース上のスキーマ構造（物理スキーマ１０７）とは無関係に（ここでいう無関係とは直接に関係するのではないという意味であり、後述する対応表１０４により対応関係がある）論理的なスキーマ構造（論理スキーマ１０２）を持ち、論理スキーマ１０２に対し種々の処理を行う。

検索部１０３は、アプリケーション部１０１からの検索要求が送付されると、データベース部１０６よりデータを取得する。検索部１０３は、内部に、論理スキーマ１０２と物理スキーマ１０７の対応をテーブル化した、対応表１０４を持つ。検索部１０３は、検索の際にこの対応表１０４からデータを得て、データベース部１０６に実際に投げるクエリを作成する。

登録部１０５は、アプリケーション部１０１からのデータ登録要求が送付されると、データベース部１０６にデータを登録する。論理スキーマ１０２と物理スキーマ１０７の相違を機械的に吸収し、マッピングを実施する。ただし、マッピングの実施の際は、対応表１０４は使用しない。

データベース部１０６は、固定したスキーマであり、実際のデータベース上のスキーマ構造である、物理スキーマ１０７を持つ。また、データは、このデータベース部１０６に格納される。

図１に示した本実施形態は、文書の登録・検索を行うデータ管理システムとして適用されうる。そこで、本実施形態を文書の登録・検索を行うデータ管理システムとして実施した具体例を２例挙げて、本実施形態のさらに詳細な構成・作用を説明する。

第１のデータ管理システム例において、利用者は、図２のような入力フォームを使って文書情報をシステムに登録し、検索時には図３のようなフォームに条件を入力して検索する。また、本例では、はじめに、各部は、図４のような構造とデータを持っている。

図４に示すフィールドは説明の単純化のために全て文字列型とする。図４中で「文書ＩＤ」は、論理スキーマ１０２における主キーとなる。図４に示すとおり、「文書ＩＤ」に対応するフィールドを物理スキーマもまた、有している。また、図４中で、データベース上のスキーマの「フィールド０」は、一つの文書に対して複数のレコードを使用することを前提とし、レコードの順序を格納するために内部的に使用する。なお、「フィールド０」の値は、「レコード番号」と呼ぶ。つまり、論理スキーマ１０２の１レコードに対して、物理スキーマ１０７は、１ないし複数のレコードを割り当てられており、レコード番号で識別して一意性を保つのである。

次に、新たなシステム要求で、例えば、「備考」フィールドを論理スキーマ１０２に追加しなくてはならない場合を考える。フィールド追加を実施した後、各部は、図５のようなデータを持つようになる。データベース上のスキーマである物理スキーマ１０７には既に空きがないため、１つのレコード上に全てのフィールドのデータを格納することができない。このため、２つ目のレコードを使用して「備考」フィールドを実現する。このとき、「フィールド０」と、「フィールド１」は、レコードの一意性を保つために必要になるため、「フィールド２」が「備考」を格納するために使用される。

次に第２のデータ管理システム例について説明する。第２のデータ管理システム例は、第１の例と同様に、文書の登録・検索を行うデータ管理システムである。第１の例と同様に、本例は、図２のような入力フォームを使って文書情報をシステムに登録し、検索時には図３のようなフォームに条件を入植して検索する。また、始めに、各部は、図４のような構造とデータを持っている。

本例において、ここで注目すべきなのは、アプリケーション部１０１の論理スキーマ１０２において、各フィールドの長さが無制限になっていることである。今、「タイトル」フィールドの値の長さが２５６バイトであるようなデータを挿入したとする。挿入後、各部は、図６のようなデータを持つようになる。

挿入されたデータは、「タイトル」の長さが１フィールドでは足りないため、２つのフィールドを消費する。このため、以降の格納位置が１つずつ後ろにずれ、最終的には２つのレコードにまたがる。すなわち、論理スキーマ１０２における「キーワード」フィールドが、物理スキーマ１０７における「フィールド５」と次レコードの「フィールド２」を使用することになる。なお、本例において、物理スキーマ１０７における「フィールド０」と「フィールド１」を使わないのは、第１の例と同様に、それらがレコードの一意性を保つために必要になるためである。

上述の２つの具体例では、どちらの例でも物理スキーマ１０７の一つのフィールドが複数の意味を持つ可能性がある。これは検索の場合に問題となるが、データの先頭に論理フィールド名を埋め込むことで、この問題を回避することができる。例えば、上記第１の例に合わせて例を示すと、「フィールド２」は、「タイトル」と「備考」の二つの意味を持つが、データを入れる場合に、次のようにすることで区別することができる。
＜タイトル＞：［実際のデータ］
＜備考＞：［実際のデータ］

すなわち、上述の２例においては、論理スキーマ１０２の拡張が必要になった際に、既に物理スキーマ１０７の空きフィールドがない場合、物理スキーマ１０７側に新規レコードを作成し、当該新規レコードの「フィールド０」には前のレコードから１つインクリメントされた値を、「フィールド１」には前のレコードと同一の文書ＩＤを示す値をセットする。その上で、新規レコードの残りのフィールドに、はみ出したデータをセットする。したがって、複数のレコード対応表（本実施形態における各スキーマ）を利用するデータ表現方法を改良したことになるので、スキーマの拡張が可能になる。

また、複数の意味を持つことになるフィールドの値については、対応する論理スキーマ１０２におけるフィールド名等を付加した値をセットする構成であるので、検索の際に起きる問題も回避することができる。

次に、本実施形態における、登録部１０５の動作についてフローチャートを参照してさらに詳細に説明する。図７に、登録部１０５のフローを示す。
登録部１０５では、アプリケーション部１０１から論理スキーマ１０２上のフィールド名とその値のペアの形でデータを受け取る（ステップＳ７０１）。レコード番号は登録部１０５が内部的に使用する番号で、始めは、例えば、１に設定される（ステップＳ７０２）。文書ＩＤとレコード番号は、常に「フィールド０」と「フィールド１」にセットする（ステップＳ７０３）。

続いて、データが存在する限り、残りのフィールドに順番にセットしていく（ステップＳ７０４ないしステップＳ７１１）。データベース上のフィールドが登録途中で尽きた場合（ステップＳ７０５、Ｎｏ）、新規レコードを使用する（ステップＳ７０７）。新規レコードにも文書ＩＤとレコード番号はセットされるが、このときレコード番号は１づつインクリメントされる（ステップＳ７０６、ステップＳ７０８）。

データベース上のフィールドの長さが一つのフィールドの実データ長より短い場合（ステップＳ７１０、Ｎｏ）、次の空きフィールドが使用される（ステップＳ７０５、Ｙｅｓ）。空きフィールドがない場合には（ステップＳ７０５、Ｎｏ）、新しいレコードを使用する（ステップＳ７０６ないしステップＳ７０８）。データが正しく格納されたら、登録部１０５は、論理スキーマ１０２上のフィールド名と物理スキーマ１０７のフィールド名（群）を検索部１０３に送付する（ステップＳ７１１）。

次に、本実施形態における、検索部１０３の動作についてフローチャートを参照してさらに詳細に説明する。図８に検索部１０３のフローを示す。
検索部１０３では、アプリケーション部１０１から論理スキーマ１０２上のフィールド名とその条件値のペアの形でデータを受け取る（ステップＳ８０１）。検索部１０３は内部に保持するマップである対応表１０４を使って、論理スキーマ１０２上のフィールド名をデータベース部１０６上の物理スキーマ１０７におけるフィールド名に変換し（ステップＳ８０２）、クエリを作成する（ステップＳ８０３）。

検索部１０３は、作成された検索クエリを、データベース部１０６に送付する（ステップＳ８０４）。検索結果データを受け取ると（ステップＳ８０５）、フィールド名変換等を行った上で、検索結果をアプリケーション部１０１に送付する（ステップＳ８０６）。

図７、図８を参照して説明した上記フローによると、本実施形態は、アプリケーション部１０１の動きを止めないで論理スキーマ１０２の拡張を可能にしている。したがって、本実施形態のデータ管理システムにおいては、論理的なスキーマとデータベース上のスキーマの対応を動的に管理できるため、スキーマの拡張を容易に行うことができる。

なお、記憶装置、演算装置、入出力装置を備えた一般的なコンピュータに、上記本実施形態の各部の機能を実現させるプログラムもまた、本発明の一実施形態である。本発明をプログラムとして構成することで、本発明を種々の環境上で実現することができる。また、そのプログラムをコンピュータ読取可能な記録媒体に記録したものもまた、本発明の一実施形態であり、その場合、プログラムを複数の手段で保持し、種々の環境上にインストールすることが可能となる。

なお、上記実施形態は、金物としてのコンピュータは１台であるデータ管理装置として構成したが、本発明はこれに限定されることなく実施可能である。本発明は、図１で示した、アプリケーション部１０１の機能を実現するアプリケーションサーバと、データベース部１０６の機能を実現するデータベースサーバと、を少なくとも有するデータ管理システムとしても実施することができる。この場合、検索部１０３や登録部１０５の機能は、データベースサーバが担う。

以上、本発明の好適な実施の形態について説明したが、本発明はこれに限定されるものではなく、要旨を逸脱しない範囲内で種々の変形実施が可能である。本実施形態で説明した各種構成要素は、適宜組み合わせることができる。

本発明の実施形態に係るデータ管理装置の構成例を示すブロック図である。 本実施形態における操作画面の表示例を示す図である。 本実施形態における操作画面の表示例を示す図である。 本実施形態における変更前の各スキーマを説明するための図である。 本実施形態における変更後の各スキーマを説明するための図である。 本実施形態における変更後の各スキーマを説明するための図である。 本実施形態の登録部の動作を示すフローチャートである。 本実施形態の検索部の動作を示すフローチャートである。

符号の説明

１０１ アプリケーション部
１０２ 論理スキーマ（アプリケーション部の論理的なスキーマ）
１０３ 検索部
１０４ 対応表
１０５ 登録部
１０６ データベース部
１０７ 物理スキーマ（データベース上の実際のスキーマ）

Claims (7)

1. 固定スキーマと、該固定スキーマに対応する論理スキーマとを用いて、フィールドと値を持つデータの登録をするデータ管理方法であって、
   前記固定スキーマは、前記論理スキーマの１レコードに対して１ないし複数のレコードを割り当てられており、少なくとも、前記論理スキーマの主キーに対応するフィールドと、レコード番号のフィールドと、を備え、
   前記論理スキーマの拡張をする際に、前記固定スキーマの空きフィールドがない場合、
   新規レコードを作成し、
   前記論理スキーマの主キーに対応するフィールドの値を変更せずそのままセットし、
   レコード番号の値をインクリメントし該値を前記レコード番号のフィールドにセットし、
   残りのフィールドにデータをセットすることを特徴とするデータ管理方法。
2. 残りのフィールドデータをセットした後、前記固定スキーマと前記論理スキーマの対応関係を対応表に格納することを特徴とする請求項１記載のデータ管理方法。
3. 前記固定スキーマにおける各フィールドに、対応する前記論理スキーマにおけるフィールド名が付加された値をセットすることを特徴とする請求項１又は２記載のデータ管理方法。
4. 固定スキーマを備えるデータベース部と、
   前記固定スキーマに対応する論理スキーマを備えるアプリケーション部と、
   前記固定スキーマ及び前記論理スキーマを用いてフィールドと値を持つデータの登録をする登録部と、を有し、
   前記固定スキーマは、前記論理スキーマの１レコードに対して１ないし複数のレコードを割り当てられており、少なくとも、前記論理スキーマの主キーに対応するフィールドと、レコード番号のフィールドと、を備え、
   前記登録部は、
   前記論理スキーマの拡張をする際に、前記固定スキーマの空きフィールドがない場合、
   新規レコードを作成し、
   前記論理スキーマの主キーに対応するフィールドの値を変更せずそのままセットし、
   レコード番号の値をインクリメントし該値を前記レコード番号のフィールドにセットし、
   残りのフィールドにデータをセットすることを特徴とするデータ管理装置。
5. 固定スキーマを備えるデータベースサーバと、
   前記固定スキーマに対応する論理スキーマを備えるアプリケーションサーバと、を有し、
   前記データベースサーバは、
   前記固定スキーマ及び前記論理スキーマを用いてフィールドと値を持つデータの登録をする登録部、を備え、
   前記固定スキーマは、前記論理スキーマの１レコードに対して１ないし複数のレコードを割り当てられており、少なくとも、前記論理スキーマの主キーに対応するフィールドと、レコード番号のフィールドと、を備え、
   前記登録部は、
   前記論理スキーマの拡張をする際に、前記固定スキーマの空きフィールドがない場合、
   新規レコードを作成し、
   前記論理スキーマの主キーに対応するフィールドの値を変更せずそのままセットし、
   レコード番号の値をインクリメントし該値を前記レコード番号のフィールドにセットし、
   残りのフィールドにデータをセットすることを特徴とするデータ管理システム。
6. コンピュータに、請求項１記載のデータ管理方法を実行させることを特徴とするプログラム。
7. 請求項６記載のプログラムをコンピュータ読取可能に記録したことを特徴とする記録媒体。

Images