JP2009104276A - データ管理装置 - Google Patents

Abstract

【課題】簡易な構成で迅速にデータ検索できるデータ管理装置を得ること。
【解決手段】ＸＭＬ文書に含まれるデータを格納するデータ管理装置において、データの格納ルールに基づいて、ＸＭＬ文書内の各データを、予め設定されたデータ構造内に格納させる基本データまたは格納先のデータ構造が決められていない拡張データに設定し、基本データを基本データ格納ＤＢ２３に格納させるとともに、拡張データを拡張データ格納ＤＢ２４に格納させる格納実行部１８と、各基本データが格納される位置および各拡張データが格納される位置を格納先管理情報として記憶する格納先情報記憶部２０と、データの検索要求があった場合に、格納先管理情報に基づいて、基本データ格納ＤＢ２３および拡張データ格納ＤＢ２４から検索要求に対応する基本データおよび拡張データを検索する検索処理部１５と、を備える。
【選択図】 図１

Description

本発明は、管理対象となるデータ部分に応じてデータ部分を格納するデータベースを使い分けるデータ管理装置に関するものである。

近年、カーナビゲーション装置や携帯電話などの組込み機器の高機能化に伴って、組込み機器で用いる使い勝手の良いデータベースの開発が進められている。このようなデータベースにおいては、例えば種々のデータを効率良く格納できることや、データベース内から迅速に所望のデータを検索できることが望まれる。ところが、組込み機器に高速な検索処理を実現させるため、データ構造を特定したＲＤＢ（Relational Data Base）のテーブルのように予め格納するデータを決めてしまうと、後に拡張データを追加してデータを格納することができないといった問題があった。

特許文献１に記載のデータ変換システムは、スキーマ構造を含んだＸＭＬ（eXtensible Markup Language）データから、使用する部分のみをリレーショナル形式に変換してＲＤＢに格納している。

また、特許文献２に記載のデータベースモデルは、階層構造データフォーマットのＸＭＬ文書等に対し、記述子やその階層記述子などをリレーショナルデータベースマネジメントシステムにマッピングしている。

特開２００６−１１４０４５号公報 特開２００６−５０１５３９号公報

しかしながら、上記前者および後者の従来技術では、ＰＣ（Personal Computer）に比べてＣＰＵ（Central Processing Unit）能力が低くメモリ量が少ない組込み機器上でＸＭＬ文書をＲＤＢに格納させると、組込み機器はＲＤＢに格納したデータを高速に検索できないという問題があった。

また、上記後者の従来技術のように、ＲＤＢマッピングＸＭＬ−ＤＢを装置に搭載して拡張データを持たせやすいＸＭＬ文書をデータベースに格納させた場合、予め必要なデータだけを格納したＲＤＢに比べて、データベースに余分な情報が格納されるので、検索処理が遅くなるという問題があった。

本発明は、上記に鑑みてなされたものであって、簡易な構成で迅速に所望のデータを検索できるデータ管理装置を得ることを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、ＸＭＬ文書に含まれるデータを分割して、分割したデータをリレーショナルデータベースまたはＸＭＬデータベースに格納するデータ管理装置において、分割されるデータの格納先に関する格納ルールに基づいて、前記ＸＭＬ文書内の各データを、予め設定された所定のデータ構造内に格納させる基本データまたは格納先のデータ構造が決められていない拡張データに設定し、前記基本データを前記リレーショナルデータベースに格納させるとともに、前記拡張データを前記ＸＭＬデータベースに格納させる格納実行部と、前記各基本データが格納される前記リレーショナルデータベース内の位置および前記各拡張データが格納される前記ＸＭＬデータベース内の位置を、格納先管理情報として記憶する格納先記憶部と、前記データの検索要求があった場合に、前記格納先管理情報に基づいて、前記リレーショナルデータベースおよび前記ＸＭＬデータベースから前記検索要求に対応する基本データおよび拡張データを検索する検索処理部と、を備えることを特徴とする。

この発明によれば、各基本データが格納されるリレーショナルデータベース内の位置および各拡張データが格納されるＸＭＬデータベース内の位置を記憶しておくので、簡易な構成で迅速に所望のデータを検索できるという効果を奏する。

以下に、本発明に係るデータ管理装置の実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態によりこの発明が限定されるものではない。

実施の形態１．
図１は、本発明の実施の形態１に係るデータ管理装置の構成を示す図である。データ管理装置１は、例えばカーナビゲーション装置や携帯電話などの組込み機器に配設される装置（ハイブリッドデータベースシステム）である。

本実施の形態のデータ管理装置１は、ＸＭＬ文書を、予め決められた構造に格納できる基本データ部分（所定のデータ構造内に格納させるデータ）と、予め決められた構造に格納できない拡張データ部分（格納先のデータ構造が決められていないデータ）と、に自動分割し、それぞれＲＤＢ（基本データ格納ＤＢ２３）とＲＤＢマッピングＸＭＬ−ＤＢ（拡張データ格納ＤＢ２４）へ格納する。

本実施の形態では、例えば、データ管理装置１を搭載する機器で共通利用されるデータ（頻繁に検索されるデータ）を基本データに設定し、ＸＭＬ文書の用途の違いによって基本データの範疇に含まれないデータを拡張データに設定する。

データ管理装置１では、組込み機器向けに最適なスキーマを考案して、ＲＤＢやＲＤＢマッピングＸＭＬ−ＤＢを設計しておく。これにより、データ管理装置１は、ＲＤＢやＲＤＢマッピングＸＭＬ−ＤＢに格納しておいた基本データ部分や拡張データ部分を高速に検索する。

図１に示すように、データ管理装置１は、検索要求入力部１１、検索結果出力部１２、格納ルール入力部１３、データ入力部１４、検索処理部１５、格納ルール記憶部１６、格納ルール判定処理部１７、格納実行部１８、格納先管理部１９、格納先情報記憶部（格納先記憶部）２０、基本データ検索部２１、拡張データ検索部２２、基本データ格納ＤＢ２３、拡張データ格納ＤＢ２４を備えている。

検索要求入力部１１は、検索対象となるデータの検索条件を入力して検索処理部１５へ送る。検索結果出力部１２は、基本データ検索部２１や拡張データ検索部２２によって検索されたデータ（検索結果）を、検索処理部１５を介して受け取り、外部装置などに出力する。

格納ルール入力部１３は、データベーススキーマの生成指示に関する情報（後述の格納ルール条件情報１０１）を入力して格納ルール判定処理部１７へ送る。データ入力部１４は、データ管理装置１に格納する文書データ（後述の文書１０３）（ＸＭＬ文書）を入力して格納実行部１８に送る。

格納実行部１８は、データ入力部１４から送られてくる文書１０３を解析して各階層のデータを抽出し、格納ルール判定処理部１７に抽出したデータの格納先を問い合わせる。格納実行部１８は、問い合わせたデータの格納先が後述の格納先情報テーブル１０２内に有る場合に、格納先を問い合わせたデータが基本データであると判断する。

格納実行部１８は、データの格納先として格納先情報（基本データの格納先であるテーブルＩＤとカラムＩＤ）を格納ルール判定処理部１７から受け取ると、基本データ格納ＤＢ２３内からテーブルＩＤで指定された基本データ格納テーブルを探し出し、抽出した基本データ格納テーブル内から、カラムＩＤで指定されたカラムを探し出す。格納実行部１８は、探し出した基本データ格納テーブル内のカラムへ文書１０３の基本データを格納する。

格納実行部１８は、基本データ格納ＤＢ２３へ新たなデータを格納する際に、新たな基本データの行を格納する格納先（後述の基本データエントリＩＤ、テーブルＩＤ）を生成し、文書１０３のデータ格納が終わるまで記憶しておく。

格納実行部１８は、問い合わせたデータの格納先が格納先情報テーブル１０２内に無い場合に、格納先を問い合わせたデータが拡張データであると判断する。格納実行部１８は、格納先を問い合わせたデータが拡張データであると判断した場合、格納先を問い合わせた拡張データに、記憶しておいたテーブルＩＤと基本データエントリＩＤを対応付ける。格納実行部１８は、格納対象のデータが拡張データである場合に、拡張データを格納する情報テーブル（後述の拡張データ格納テーブル１０５）を拡張データ格納ＤＢ２４へ生成し、生成した拡張データ格納ＤＢ２４に拡張データを格納する。

格納ルール判定処理部１７は、格納ルール入力部１３から格納ルール条件情報１０１を受けると、格納ルール条件情報１０１に従ったデータベーススキーマの生成指示を格納先管理部１９に行なう。

また、格納ルール判定処理部１７は、格納実行部１８からデータ（文書１０３）の格納先の問い合わせがあると、格納先管理部１９にデータの格納先（格納先情報）を照会させる。格納ルール判定処理部１７は、格納先管理部１９から格納先情報（照会結果）として基本データの格納先であるテーブルＩＤとカラムＩＤを受けると、これらの格納先情報を格納実行部１８に渡す。

格納先管理部１９は、格納ルール判定処理部１７からデータベーススキーマの生成指示を受けると、格納ルール条件情報１０１に基づいて格納先情報テーブル１０２を生成し、格納先情報記憶部２０に記憶させる。また、格納先管理部１９は、格納先情報テーブル１０２に基づいて、基本データを格納する情報テーブル（後述の基本データ格納テーブル１０４）を基本データ格納ＤＢ２３に生成する。

格納先管理部１９は、格納ルール判定処理部１７からデータの格納先の照会があると、該当する格納先情報が格納先情報記憶部２０にあるか否かを判断する。格納先管理部１９は、問い合わせのあったデータの階層に一致する条件を格納先情報テーブル１０２から探す。問い合わせのあったデータに対応する格納先情報が格納先情報記憶部２０にあれば、格納先管理部１９は、問い合わせのあったデータは基本データであると判定し、格納ルール判定処理部１７に基本データの格納先である情報テーブルのテーブルＩＤとカラムＩＤを送る。

格納ルール記憶部１６は、格納ルール判定処理部１７が格納ルール入力部１３を介して受け取った格納ルール条件情報１０１を記憶するメモリなどの記憶手段である。格納先情報記憶部２０は、格納先管理部１９が生成した格納先情報テーブル１０２を記憶するメモリなどの記憶手段である。

検索処理部１５は、検索要求入力部１１から検索条件を受けると、検索要求入力部１１からの検索条件に対応するデータの階層を格納先管理部１９へ問い合わせるとともに、格納先管理部１９から送られてくる回答（データの格納先に関する格納先情報）に基づいて、基本データの検索を先に行なうか拡張データの検索を先に行なうか（基本データ検索であるか拡張データ検索であるか）を判断する。

検索処理部１５は、格納先管理部１９から検索条件に対応する格納先情報（後述の基本データ格納テーブル名とカラム名）を取得できた場合に、基本データの検索を先に行なうと判断し、基本データ検索部２１に、格納先情報と検索条件を渡して、基本データの検索を要求する。

検索処理部１５は、格納先管理部１９から検索条件に対応する基本データ格納テーブル名とカラム名を取得できなかった場合に、拡張データの検索を先に行なうと判断し、拡張データ検索部２２に拡張データの検索を要求する。検索処理部１５は、拡張データ検索部２２に拡張データの検索を要求した場合、拡張データ検索部２２が検索して得た格納先情報（後述の基本データ格納テーブル名、基本データエントリＩＤ）を基本データ検索部２１へ渡して、基本データ検索部２１に基本データの検索を要求する。検索処理部１５は、基本データ検索部２１や拡張データ検索部２２が検索したデータを検索結果出力部１２へ送る。

基本データ検索部２１は、検索処理部１５から送られてくる格納先情報と検索条件とに基づいて、基本データ格納ＤＢ２３から基本データを検索し、基本データエントリＩＤを含む、同一行の全てのカラムのデータを取得する。基本データ検索部２１は、取得したデータを検索処理部１５へ送る。

基本データ検索部２１は、検索処理部１５から送られてくる検索条件が、格納している基本データに対応していない条件であると判断した場合に、検索条件が拡張データの検索条件であると判断し、拡張データ検索部２２に検索を要求する。基本データ検索部２１は、データの格納先を示す階層条件が格納先情報テーブル１０２に無い場合に、検索条件は格納している基本データに対応していない条件であると判断する。

拡張データ検索部２２は、拡張データ格納ＤＢ２４から格納先情報に応じた拡張データを検索する。拡張データ検索部２２は、検索処理部１５から送られてくる格納先情報に基づいて、基本データエントリＩＤおよび基本データ格納テーブル名が一致するデータを拡張データ格納ＤＢ２４からから全て取得する。拡張データ検索部２２は、取得したデータ（拡張データ、基本データ格納テーブル名、基本データエントリＩＤ）を検索処理部１５へ送る。

基本データ格納ＤＢ２３は、格納先管理部１９が生成した基本データ格納テーブル１０４を格納するデータベースである。拡張データ格納ＤＢ２４は、格納実行部１８が生成した拡張データ格納テーブル１０５を格納するデータベースである。

つぎに、データ管理装置１の動作手順（データの格納処理とデータの検索処理）について説明する。図２は、データの格納処理手順を示すフローチャートである。データ管理装置１へは、予め格納ルール入力部１３から格納ルール条件情報１０１を入力しておく。格納ルール入力部１３は、格納ルール条件情報１０１を格納ルール記憶部１６に記憶（設定）させる（ステップＳ１１０）。

ここで、格納ルール条件情報１０１の構成について説明する。図３は、格納ルール条件情報の一例を示す図である。図３では、格納ルール条件情報（格納ルール条件式）１０１の実装仕様の一例を示している。格納ルール条件情報１０１は、ユーザによって設定される情報であり、組込み機器などで利用するＸＭＬ文書を、ＸＭＬ文書の全てで共通となる基本データ部分と、ＸＭＬ文書の用途によって異なる拡張データ部分とに、分割するための格納ルールに関する情報である。

例えば、同図の１行目の条件式では、「ｂｏｏｋ−ｌｉｓｔ」という名前のテーブルに「ｔｉｔｌｅ」という名前のカラムを設け、そのカラムに、入力文書の中で階層が「／ｂｏｏｋ／ｔｉｔｌｅ／」にあるノード値を格納することを示している。このＩＮＰＵＴ文において、ＴＯの次に記載されているのが格納先の基本データ格納テーブル名であり、ＡＳの次に記載されているのがそのテーブルにおける格納先カラム名である。なお、図３では条件式の記述順に沿って、同一テーブル内のカラムの順序が決まる仕様を示している。

つぎに、格納ルール判定処理部１７は、格納ルール条件情報１０１に従ったデータベーススキーマの生成指示を格納先管理部１９に行なう。格納先管理部１９は、格納ルール判定処理部１７からデータベーススキーマの生成指示を受けると、格納ルール条件情報１０１に基づいて格納先情報テーブル１０２を生成し、格納先情報記憶部２０に記憶させる（ステップＳ１２０）。

格納先情報テーブル１０２は、文書１０３から分割されたＸＭＬ文書の何れのデータ部分が基本データ格納ＤＢ２３の何れの位置に格納され、文書１０３から分割されたＸＭＬ文書の何れのデータ部分が拡張データ格納ＤＢ２４の何れの位置に格納されたかを示す情報である。

ここで、格納先情報テーブル１０２の構成について説明する。図４は、格納先情報テーブルの一例を示す図である。格納先情報テーブル（格納先管理情報）１０２は、基本データ格納テーブル名、カラム名、階層パスをそれぞれ対応付けした、データの格納先に関する情報テーブルである。図４では、例えば、基本データ格納テーブル名の「ｂｏｏｋ−ｌｉｓｔ」、カラム名の「ｔｉｔｌｅ」、階層パスの「／ｂｏｏｋ／ｔｉｔｌｅ／」が対応付けられている。

つぎに、格納先管理部１９は、格納先情報テーブル１０２に基づいて、基本データ格納ＤＢ２３に基本データ格納テーブル１０４を生成する（ステップＳ１３０）。ここで、基本データ格納テーブル１０４の構成について説明する。図５は、基本データ格納テーブルの構成の一例を示す図である。基本データ格納テーブル１０４は、「基本データエントリＩＤ」、「ｔｉｔｌｅ」、「ｔｉｔｌｅ−ｋａｎａ」、「ａｕｔｈｏｒ」、「ａｕｔｈｏｒ−ｋａｎａ」を対応付けした、基本データに関する情報テーブルである。図５では、基本データ格納テーブル名が「ｂｏｏｋ−ｌｉｓｔ」である基本データ格納テーブル１０４の構成を示している。

「基本データエントリＩＤ」は、データのエントリを識別する情報である。また、「ｔｉｔｌｅ」、「ｔｉｔｌｅ−ｋａｎａ」、「ａｕｔｈｏｒ」、「ａｕｔｈｏｒ−ｋａｎａ」は、それぞれ、表題、表題のカナ読み、著者、著者のカナ読みを示すカラム名である。

図５では、「基本データエントリＩＤ」が「１」の基本データは、「ｔｉｔｌｅ」が「竜宮城ガイドブック」であり、「ｔｉｔｌｅ−ｋａｎａ」が「リュウグウジョウガイドブック」であり、「ａｕｔｈｏｒ」が「浦島太郎」であり、「ａｕｔｈｏｒ−ｋａｎａ」が「ウラシマタロウ」である場合を示している。

基本データ格納ＤＢ２３に基本データ格納テーブル１０４が生成された後、データ入力部１４に格納対象の文書１０３が入力されると、この文書１０３は格納実行部１８に送られる（ステップＳ１４０）。

ここで、格納対象となる文書１０３の構成について説明する。図６は、格納対象となる文書の構成の一例を示す図である。図６では、文書１０３の表題が「竜宮城ガイドブック」、表題のカナ読みが「リュウグウジョウガイドブック」、著者が「浦島太郎」、著者のカナ読みが「ウラシマタロウ」、出版社（ｐｕｂｌｉｓｈｅｒ）が「おとぎ出版」、国際標準図書番号（ｉｓｂｎ（International Standard Book Number））が「１２３−１２３４５６７８９０」である場合を示している。

格納実行部１８は、文書１０３を解析して各階層のデータを抽出し（ステップＳ１５０）、格納ルール判定処理部１７に抽出したデータの格納先を問い合わせる。格納ルール判定処理部１７は、格納実行部１８からデータの格納先の問い合わせがあると、格納先管理部１９にデータの格納先を照会させる。

格納先管理部１９は、格納ルール判定処理部１７からデータの格納先の照会指示があると、該当する格納先情報が格納先情報記憶部２０にあるか否かを判断する（ステップＳ１６０）。具体的には、格納先管理部１９は、格納先情報テーブル１０２から問い合わせのあったデータの階層に一致する条件を探す。

問い合わせのあったデータに対応する格納先情報が格納先情報記憶部２０にあれば（ステップＳ１６０、Ｙｅｓ）、格納先管理部１９は、問い合わせのあったデータは基本データであると判断する（ステップＳ１７０）。そして、格納先管理部１９は、問い合わせのあったデータ（階層パス）に対応するテーブルＩＤ（基本データ格納テーブルを識別するＩＤ）とカラムＩＤを格納先情報テーブル１０２から抽出する（ステップＳ１８０）。テーブルＩＤは、基本データ格納テーブル１０４などの基本データ格納テーブルを識別するＩＤである。また、カラムＩＤは、格納先情報テーブル１０２に示したカラム名を識別するＩＤである。

格納先管理部１９は、基本データの格納先であるテーブルＩＤとカラムＩＤを格納ルール判定処理部１７に送る。格納ルール判定処理部１７は、格納先管理部１９から基本データの格納先であるテーブルＩＤとカラムＩＤを受けると、受け取ったテーブルＩＤとカラムＩＤを格納実行部１８に送る。

格納実行部１８は、格納先管理部１９からテーブルＩＤとカラムＩＤを受けると、格納先を問い合わせたデータが基本データであると判断する。そして、格納実行部１８は、基本データ格納ＤＢ２３内の基本データ格納テーブル１０４に文書１０３の基本データを格納する。具体的には、格納実行部１８は、格納先管理部１９が抽出したテーブルＩＤで指定される基本データ格納テーブル内の、格納先管理部１９が抽出したカラムＩＤで指定されるカラムへ基本データを格納する（ステップＳ１９０）。このとき、基本データ格納ＤＢ２３では、格納の際に新たな基本データの行を生成し、生成したデータ行に基本データエントリＩＤを振っておく。

格納実行部１８は、新たな基本データの行に対応する基本データエントリＩＤと、新たな基本データを格納する基本データ格納テーブルのテーブルＩＤとを、文書１０３のデータ格納が終わるまで記憶しておく（ステップＳ２００）。

この後、格納実行部１８は、ステップＳ１５０の処理で抽出した全てのデータをデータ管理装置１内（基本データ格納ＤＢ２３または拡張データ格納ＤＢ２４）に格納したか否かを判断する（ステップＳ２１０）。

格納実行部１８が、ステップＳ１５０の処理で抽出した全てのデータをデータ管理装置１内に格納していないと判断すると（ステップＳ２１０、Ｎｏ）、格納先管理部１９は、次のデータに対応する格納先情報が格納先情報記憶部２０にあるか否かを判断する（ステップＳ１６０）。

問い合わせたデータに対応する格納先が格納先情報テーブル１０２内にないと格納先管理部１９が判断すると（ステップＳ１６０、Ｎｏ）、格納実行部１８は、格納先を問い合わせたデータが拡張データであると判断する。そして、格納実行部１８は、格納先を問い合わせたデータに、ステップＳ２００で記憶しておいた基本データエントリＩＤおよびテーブルＩＤを対応付けし、拡張データ格納ＤＢ２４へ格納する。格納実行部１８は、拡張データ格納ＤＢ２４内の拡張データ格納テーブル１０５に拡張データを格納する。

データ管理装置１は、ステップＳ１５０の処理で抽出した全てのデータをデータ管理装置１内（基本データ格納ＤＢ２３または拡張データ格納ＤＢ２４）へ格納するまで、ステップＳ１６０〜Ｓ２３０の処理を繰り返す。

図７は、拡張データ格納テーブルの構成を示す図である。拡張データ格納テーブル１０５は、ノードの階層構造が付加された、拡張データに関する情報テーブル（ノードテーブル）である。拡張データ格納テーブル１０５では、「ノードＩＤ」、「親ノードＩＤ」、「階層パス」、「ノード名」、「ノード値」、「基本データ格納テーブル名」、「基本データエントリＩＤ」が対応付けられている。

「ノードＩＤ」は、拡張データのノードを識別する情報であり、「親ノードＩＤ」は、拡張データが属する親ノードを識別する情報（「ノードＩＤ」）である。また、「階層パス」は、拡張データのノードが属する階層であり、「ノード名」は、拡張データのノード名である。また、「ノード値」は、拡張データのノード値であり、「基本データ格納テーブル名」は、基本データを格納するテーブルのテーブル名である。また、「基本データエントリＩＤ」は、基本データのエントリを識別する情報である。

例えば、「ノードＩＤ」が「１」の拡張データは、「親ノードＩＤ」が「０」であり、自ノードが親ノードであることを示している。また、「ノードＩＤ」が「１」の拡張データは、「階層パス」が「／ｂｏｏｋ／」である。また、「ノード名」は、「ｂｏｏｋ」であり、「ノード値」は、無しである。さらに、「基本データ格納テーブル名」は、「ｂｏｏｋ−ｌｉｓｔ」であり、「基本データエントリＩＤ」は「１」である。

本実施の形態では、拡張データ格納テーブル１０５にツリー構造で格納する拡張データのルートから子孫までの全ノードに、基本データ格納テーブル１０４に分割して格納される基本データと同じエントリＩＤ（基本データエントリＩＤ）を対応付けておく。例えば、ノードＩＤが「１」〜「３」のノードは、基本データ格納テーブル１０４に格納されている基本データに対応するノードであるので、この基本データと同じ基本データエントリＩＤの「１」を対応付けておく。

なお、本実施の形態では、拡張データを拡張データ格納ＤＢ２４へ格納させる際に、拡張データとステップＳ２００で記憶しておいた基本データエントリＩＤおよびテーブルＩＤを対応付けたが、基本データエントリＩＤおよびテーブルＩＤを抽出するまでは、拡張データの格納を保留し、他の基本データから格納処理を行なう。換言すると、最初の基本データを格納して基本データエントリＩＤおよびテーブルＩＤを取得するまでは、拡張データの拡張データ格納ＤＢ２４への格納処理を保留する。

つぎに、データ管理装置１に格納されたデータの検索処理について説明する。図８は、データの検索処理手順を示すフローチャートである。検索要求入力部１１に検索条件が入力されると、検索要求入力部１１は検索条件を検索処理部１５へ送る（ステップＳ３１０）。

検索処理部１５は、検索要求入力部１１からの検索条件を解析し、基本データの検索を先に行なうか拡張データの検索を先に行なうかを判断する。具体的には、検索処理部１５は、格納先管理部１９から基本データ格納テーブル名とカラム名を得ることができたか否かに基づいて、検索対象が基本データであるか拡張データであるかを判断する。検索処理部１５は、例えば、検索条件が、／ｂｏｏｋ／ｔｉｔｌｅ／＝“竜宮城ガイドブック”である場合、階層がｂｏｏｋの下のｔｉｔｌｅで、その値が“竜宮城ガイドブック”であるデータのセットを取得するために、／ｂｏｏｋ／ｔｉｔｌｅ／という階層を格納先管理部１９へ問い合わせる。

格納先管理部１９は、検索処理部１５から問い合わせのあった階層に一致する条件（基本データ格納テーブル名とカラム名）を格納先情報テーブル１０２から抽出する（ステップＳ３２０）。格納先管理部１９は、例えば、基本データ格納テーブル名が「ｂｏｏｋ−ｌｉｓｔ」、カラム名が「ｔｉｔｌｅ」を、／ｂｏｏｋ／ｔｉｔｌｅ／の階層に一致する条件として格納先情報テーブル１０２から抽出する。格納先管理部１９は、抽出したこれらの基本データ格納テーブル名やカラム名を検索処理部１５へ送る。

検索処理部１５は、検索条件（データの階層）に対応する基本データ格納テーブル名とカラム名を格納先管理部１９から取得することができた場合に（ステップＳ３３０、Ｙｅｓ）、検索処理は基本データが先であると判断する（ステップＳ３４０）。そして、検索処理部１５は、基本データ検索部２１に格納先情報テーブル１０２内の格納先に関する情報（基本データ格納テーブル名の「ｂｏｏｋ−ｌｉｓｔ」およびカラム名の「ｔｉｔｌｅ」）と検索条件（＝“竜宮城ガイドブック”）を送る。

基本データ検索部２１は、検索条件に対応する基本データを基本データ格納ＤＢ２３から検索して取得する。具体的には、基本データ検索部２１は、検索処理部１５から送られてくる格納先情報と検索条件とに基づいて、基本データ格納ＤＢ２３から基本データを検索し、基本データエントリＩＤを含む、同一行の全てのカラムのデータを取得する。これにより、基本データ検索部２１は、基本データ格納ＤＢ２３から基本データ格納テーブル名と基本データエントリＩＤに対応するデータ行を取得する（ステップＳ３５０）。基本データ検索部２１は、取得した基本データを検索処理部１５へ送る。

さらに、検索処理部２１は、基本データ格納テーブル１０４内の格納先情報（基本データエントリＩＤ＝「１」と、基本データ格納テーブル名の「ｂｏｏｋ−ｌｉｓｔ」）を拡張データ検索部２２へ送る。拡張データ検索部２２は、基本データ検索部２１が検索した基本データに対応する拡張データを拡張データ格納ＤＢ２４から検索して取得する。ここでの拡張データ検索部２２は、検索処理部２１からの格納先情報を用いて、基本データエントリＩＤおよび基本データ格納テーブル名が一致する拡張データを拡張データ格納ＤＢ２４から全て取得する。具体的には、拡張データ検索部２２は、検索処理部２１からの基本データ格納テーブル名に対応する基本データ格納テーブル名を有するとともに、検索処理部２１からの基本データエントリＩＤに対応する基本データエントリＩＤを有する拡張データを、拡張データ格納テーブル１０５から抽出する（ステップＳ３６０）。

拡張データ検索部２２は、取得したデータを検索処理部１５へ送る。検索処理部１５は、基本データ検索部２１および拡張データ検索部２２から得た検索結果を検索結果出力部１２へ送り、検索結果出力部１２から検出結果が出力される（ステップＳ３７０）。

検索処理部１５は、検索条件に対応する基本データ格納テーブル名とカラム名を格納先管理部１９から取得することができなかった場合に（ステップＳ３３０、Ｎｏ）、検索処理は拡張データが先であると判断する（ステップＳ３８０）。換言すると、検索要求入力部１１から入力された検索条件が、格納先情報テーブル１０２に格納されている基本データの条件（階層パス）に対応しない場合に、検索処理部１５は、拡張データを基本データよりも先に検索すると判断する。例えば、検索条件が、／ｂｏｏｋ／ｉｓｂｎ／＝“１２３−１２３４５６７８９０”であるデータ（セット）の検索を要求した場合（階層がｂｏｏｋの下のｉｓｂｎで、その値が“１２３−１２３４５６７８９０”のデータ検索を行なう場合）、／ｂｏｏｋ／ｉｓｂｎ／という階層条件が格納先情報テーブル１０２には無い。このため、検索処理部１５は検索条件が拡張データであると判断する。

そして、検索処理部１５は、拡張データ検索部２２に、／ｂｏｏｋ／ｉｓｂｎ／＝“１２３−１２３４５６７８９０”という条件の検索を要求する。拡張データ検索部２２はこの検索条件にしたがって拡張データ格納ＤＢ２４（拡張データ格納テーブル１０５）の中を検索する。この結果、拡張データ検索部２２は、拡張データ（ノードＩＤ）とともに、基本データ格納テーブル名「ｂｏｏｋ−ｌｉｓｔ」と基本データエントリＩＤ＝「１」という情報を得ることができる（ステップＳ３９０）。

拡張データ検索部２２は、検索して得た拡張データ、基本データ格納テーブル名、基本データエントリＩＤを検索処理部１５へ送る。そして、検索処理部１５は、基本データ格納テーブル名と基本データエントリＩＤを基本データ検索部２１へ送り、基本データ検索部２１に基本データの検索を要求する。基本データ検索部２１は、取得した拡張データに対応する基本データを基本データ格納ＤＢ２３から検索して取得する（ステップＳ４００）。具体的には、基本データ検索部２１は、基本データ格納ＤＢ２３から、基本データ格納テーブル名と基本データエントリＩＤの一致するデータ行を抽出し、抽出したこれらのデータ行を検索処理部１５へ送る。

検索処理部１５は、基本データ検索部２１および拡張データ検索部２２から得た検索結果を検索結果出力部１２へ送り、検索結果出力部１２から検出結果が出力される（ステップＳ３７０）。

なお、本実施の形態では、基本データエントリＩＤとテーブルＩＤを別々のＩＤとしたが、基本データエントリＩＤにテーブルＩＤを含めておいてもよい。換言すると、基本データエントリＩＤによって、テーブル名と基本データを識別してもよい。特許請求の範囲に記載の基本データ識別情報が、基本データエントリＩＤおよびテーブルＩＤに対応している。

このように実施の形態１によれば、ユーザによって設定される格納先情報テーブル１０２にしたがって、文書（ＸＭＬ文書）１０３を基本データ格納ＤＢ（ＲＤＢ）２３と、拡張データ格納ＤＢ（ＲＤＢマッピングＸＭＬ−ＤＢ）２４に分割格納するとともに、格納したデータの格納先を管理しているので、簡易な構成で迅速に所望のデータを検索できる。

また、よく利用する基本データを基本データ格納ＤＢ２３に格納しているので、利用頻度の低い拡張データを拡張データ格納ＤＢ２４から検索する場合よりも、利用頻度の高い基本データを基本データ格納ＤＢ２３から高速に検索できる。

また、拡張データ格納テーブル１０５の拡張データに基本データ格納テーブル１０４の基本データと同じ基本データエントリＩＤを対応付けているので、基本データ格納ＤＢ２３から基本データを検索する際には、この基本データに対応する拡張データを拡張データ格納ＤＢ２４から一括して容易に検索できる。また、拡張データ格納ＤＢ２４から拡張データを検索する際には、この拡張データに対応する基本データを基本データ格納ＤＢ２３から容易に検索できる。したがって、データ管理装置１は、ＸＭＬ文書として元々同じツリー構造にあった全データを、基本データ格納ＤＢ２３や拡張データ格納ＤＢ２４から容易に取得することが可能となる。

また、ＸＭＬ文書を所定の階層をトップとしたデータ群に分け、各データ群ごとに基本データと拡張データとに分割するよう、ユーザが格納ルール条件情報１０１によって指定できるので、ユーザが所望する基本データと拡張データとの分割を容易に行なうことが可能となる。これにより、ＸＭＬ文書をユーザが決めた格納ルールに従って、基本データ格納ＤＢ２３と拡張データ格納ＤＢ２４に格納することが可能となる。

実施の形態２．
つぎに、図９〜図１３を用いてこの発明の実施の形態２について説明する。実施の形態２では、基本データ格納ＤＢ２３に新たな基本データ格納テーブルを追加する。なお、本実施の形態では、図１に示した実施の形態１と同様のデータ管理装置１を用いる。

基本データ格納ＤＢ２３は、ＲＤＢであるのでデータベースの運用開始後は、既存の情報テーブル（基本データ格納テーブル１０４）を変更することはできない。一方、既存のテーブルとは異なる別の情報テーブルを基本データ格納ＤＢ２３内に新たに追加することは可能である。

本実施の形態では、基本データ格納ＤＢ２３への新たな情報テーブルの追加処理の一例として、実施の形態１で用いた文書１０３（ｂｏｏｋ）とは異なる文書（後述の文書１０８（ｍｕｓｉｃ））を基本データ格納ＤＢ２３へ格納する場合について説明する。

実施の形態２に係るデータ管理装置１の動作手順として、まず新たな文書の追加格納処理について説明する。なお、データ管理装置１による新たな文書の追加格納処理のうち、図２に示した実施の形態１のデータ格納処理と同様の処理手順によって行う処理の説明は省略する。

既存の文書１０３とは異なる文書（後述の新たな文書１０８）を基本データ格納ＤＢ２３へ格納する際には、基本データ格納ＤＢ２３に新たな情報テーブルを追加する必要がある。基本データ格納ＤＢ２３に新たな情報テーブルを追加する場合、データ管理装置１へは、予め格納ルール入力部１３から新たな格納ルール条件情報（後述の格納ルール条件情報１０６）を入力しておく。格納ルール入力部１３は、この新たな格納ルール条件情報１０６を格納ルール記憶部１６に記憶させる。

ここで新たな情報テーブルを追加する際にデータ管理装置１に設定される新たな格納ルール条件情報１０６について説明する。図９は、新たな情報テーブルを追加する際に設定される新たな格納ルール条件情報の一例を示す図である。図９に示す格納ルール条件情報１０６は、図３に示した格納ルール条件情報１０１と同様の構成を有している。

例えば、図９に示す格納ルール条件情報１０６の１行目の条件式では、「ｍｕｓｉｃ−ｌｉｓｔ」という名前のテーブルに「ｔｉｔｌｅ」という名前のカラムを設け、そのカラムに、入力文書の中で階層が「／ｍｕｓｉｃ／ｔｉｔｌｅ／」にあるノード値を格納することを示している。

つぎに、格納ルール判定処理部１７は、格納ルール条件情報１０６に従ったデータベーススキーマの生成指示を格納先管理部１９に行なう。格納先管理部１９は、格納ルール条件情報１０６に基づいて、図１０に示す新たな格納先情報テーブル１０７を生成し、格納先情報記憶部２０に記憶させる。

格納先情報テーブル１０７の構成について説明する。図１０に示す格納先情報テーブル１０７は、図４に示した格納先情報テーブル１０２と同様の構成を有している。本実施の形態では、既存の格納先情報テーブル１０２に、新たに格納する文書の格納先に関する情報を追加して格納先情報テーブル１０７を作成している。格納先情報テーブル１０７では、例えば、基本データ格納テーブル名の「ｍｕｓｉｃ−ｌｉｓｔ」、カラム名の「ｍｕｓｉｃ」、階層パスの「／ｍｕｓｉｃ／ｔｉｔｌｅ／」が対応付けられている。

つぎに、格納先管理部１９は、基本データ格納ＤＢ２３内に、図１１に示す新たに追加する基本データ格納テーブル１０９を生成する。なお、ここでの格納先管理部１９が特許請求の範囲に記載の基本データ格納テーブル作成部に対応している。

図１１では、基本データ格納テーブル名が「ｍｕｓｉｃ−ｌｉｓｔ」である基本データ格納テーブル１０９の構成を示している。基本データ格納テーブル１０９は、図５に示した基本データ格納テーブル１０４と同様の構成を有している。

図１１では、「基本データエントリＩＤ」が「１」、「ｔｉｔｌｅ」が「運命」、「ｔｉｔｌｅ−ｋａｎａ」が「ウンメイ」、「ａｒｔｉｓｔ」が「ベートーヴェン」、「ａｒｔｉｓｔ−ｋａｎａ」が「ベートーヴェン」である場合を示している。

基本データ格納ＤＢ２３に新たな基本データ格納テーブル１０９が生成された後、データ入力部１４に格納対象の新たな文書１０８が入力されると、この文書１０８は格納実行部１８に送られる。

ここで、新たに格納対象となる文書１０８の構成について説明する。図１２は、新たに格納対象となる文書の構成の一例を示す図である。文書１０８は、ｍｕｓｉｃに関する文書データであり、図６に示した文書１０３と同様の構成を有している。図１２では、文書１０３の表題が「運命」、表題のカナ読みが「ウンメイ」、著者が「ベートーヴェン」、著者のカナ読みが「ベートーヴェン」、ジャンル（ｇｅｎｒｅ）が「クラシック」、ランキング（ｒａｎｋｉｎｇ）が「４つ星」である場合を示している。

文書１０８が格納実行部１８に送られた後、データ管理装置１では、実施の形態１と同様の処理手順によって、文書１０８を基本データ格納ＤＢ２３と拡張データ格納ＤＢ２４に格納する。すなわち、格納実行部１８は、文書１０８を解析して各階層のデータを抽出し、格納ルール判定処理部１７に抽出したデータの格納先を問い合わせる。格納ルール判定処理部１７は、格納実行部１８からデータの格納先の問い合わせがあると、格納先管理部１９にデータの格納先を照会させる。

格納先管理部１９は、該当する格納先情報が格納先情報記憶部２０にあるか否かを判断する。問い合わせのあったデータに対応する格納先情報が格納先情報記憶部２０にあれば、格納先管理部１９は、問い合わせのあったデータは基本データであると判断する。そして、格納先管理部１９は、問い合わせのあったデータに対応するテーブルＩＤとカラムＩＤを格納先情報テーブル１０７から抽出する。格納先管理部１９は、基本データの格納先であるテーブルＩＤとカラムＩＤを格納ルール判定処理部１７を介して格納実行部１８に送る。

格納実行部１８は、格納先管理部１９からテーブルＩＤとカラムＩＤを受けると、格納先を問い合わせたデータが基本データであると判断する。そして、格納実行部１８は、基本データ格納ＤＢ２３内の基本データ格納テーブル１０９に文書１０８の基本データを格納する。このとき、基本データ格納ＤＢ２３では、格納の際に新たな基本データの行を生成し、生成したデータ行に基本データエントリＩＤを振っておく。

格納実行部１８は、新たな基本データの行に対応する基本データエントリＩＤと、新たな基本データを格納する基本データ格納テーブルのテーブルＩＤとを、文書１０８のデータ格納が終わるまで記憶しておく。

この後、格納実行部１８は、文書１０８から抽出した全てのデータをデータ管理装置１内に格納したか否かを判断する。格納実行部１８が、文書１０８から抽出した全てのデータをデータ管理装置１内に格納していなければ、格納先管理部１９は、次のデータに対応する格納先情報が格納先情報記憶部２０にあるか否かを判断する。

問い合わせたデータに対応する格納先が格納先情報テーブル１０７内にないと格納先管理部１９が判断すると、格納実行部１８は、格納先を問い合わせたデータが拡張データであると判断する。そして、格納実行部１８は、格納先を問い合わせたデータに、記憶しておいた基本データエントリＩＤおよびテーブルＩＤを対応付けし、拡張データ格納ＤＢ２４内（後述の拡張データ格納テーブル１１０）へ格納する。

データ管理装置１は、文書１０８から抽出した全てのデータをデータ管理装置１内へ格納するまで、基本データ格納ＤＢ２３への基本データの格納処理と拡張データ格納ＤＢ２４への拡張データの格納処理を行なう。

図１３は、新たに作成される拡張データ格納テーブルの構成を示す図である。新たに作成される拡張データ格納テーブル１１０は、図７に示した拡張データ格納テーブル１０５と同様の構成を有している。本実施の形態では、既存の拡張データ格納テーブル１０５に、新たに格納する拡張データを追加して、拡張データ格納テーブル１１０を作成している。

例えば、「ノードＩＤ」が「４」の拡張データは、「親ノードＩＤ」が「０」であり、「階層パス」が「／ｍｕｓｉｃ／」である。また、「ノード名」は、「ｍｕｓｉｃ」であり、「ノード値」は、無しである。さらに、「基本データ格納テーブル名」は、「ｍｕｓｉｃ−ｌｉｓｔ」であり、「基本データエントリＩＤ」は「１」である。なお、本実施の形態に係るデータ管理装置１のデータ検索処理は、実施の形態１のデータ管理装置１と同様の手順によって行うので、その説明は省略する。

このように実施の形態２によれば、ユーザによって設定される格納先情報テーブル１０２に基づいて、新たな基本データ格納テーブル１０９と新たな拡張データ格納テーブル１１０を生成するので、容易に新たな情報テーブルを追加することが可能となる。

実施の形態３．
つぎに、図１４〜図２０を用いてこの発明の実施の形態３について説明する。実施の形態３では、所定ノードの一部（曲名の１文字目など）を抽出し、抽出した情報を付加情報として拡張データに対応付けておく。

図１４は、実施の形態３に係るデータ管理装置の構成を示す図である。図１４の各構成要素のうち図１に示す実施の形態１のデータ管理装置１と同一機能を達成する構成要素については同一番号を付しており、重複する説明は省略する。

本実施の形態のデータ管理装置１は、検索要求入力部１１、検索結果出力部１２、格納ルール入力部１３、データ入力部１４、検索処理部１５、格納ルール記憶部１６、格納ルール判定処理部１７、格納実行部１８、格納先管理部１９、格納先情報記憶部２０、基本データ検索部２１、拡張データ検索部２２、基本データ格納ＤＢ２３、拡張データ格納ＤＢ２４に加えて、拡張データ付加情報記憶部３１を備えている。

拡張データ付加情報記憶部３１は、格納先管理部１９に接続しており、後述の付加情報（拡張データ付加情報）を記憶する。本実施の形態の格納先管理部１９は、格納ルール判定処理部１７によって生成される後述の付加定義情報テーブル１１２を、拡張データ付加情報記憶部３１に格納させる。

実施の形態３に係るデータ管理装置１の動作手順として、まず文書の格納処理について説明する。なお、データ管理装置１による文書の格納処理のうち、図２に示した実施の形態１のデータ格納処理と同様の処理手順によって行う処理の説明は省略する。

データ管理装置１へは、実施の形態１と同様に予め格納ルール入力部１３から後述の格納ルール条件情報１１１を入力しておく。ここで、格納ルール条件情報１１１の構成について説明する。図１５は、実施の形態３に係る格納ルール条件情報の一例を示す図である。図１５に示す格納ルール条件情報１１１は、図３に示した格納ルール条件情報１０１と同様の構成を有している。格納ルール条件情報１１１は、格納ルール条件情報１０１に付加定義情報（拡張データへ付加する情報を定義した情報）が加えられた情報である。

図１５の５行目の条件式（ＡＤＤＸの行）が付加定義情報（コマンド文）の一例であり、本実施の形態ではこの付加定義情報をデータを格納する際の格納ルールに追加する。付加定義情報は、例えば、拡張データ格納ＤＢ２４へ拡張データを格納する際に、特定のノードに対してのみ所定のバイト長の情報を付加するコマンドである。所定のバイト長の情報は、例えば特定のノードとは異なる他のノードの一部（所定のバイト長からなるノード値）である。

図１５では、「／ｍｕｓｉｃ／ｇｅｎｒｅ／」のノードに対して、「／ｍｕｓｉｃ／ｔｉｔｌｅ／ｋａｎａ／」のノード値の最初の２バイト分を付加情報として拡張データ格納ＤＢ２４へ格納させる場合の付加定義情報を示している。

付加定義情報を有した格納ルール条件情報１１１は、格納ルール判定処理部１７によって解析され、格納ルール記憶部１６に記憶させておく。格納ルール判定処理部１７は、格納ルール条件情報１１１に基づいて、付加定義情報を格納する付加定義情報テーブルを生成する。

ここで付加定義情報テーブルの構成について説明する。図１６は、付加定義情報テーブルの構成の一例を示す図である。付加定義情報テーブル１１２は、「付加情報ノード」、「バイト長」、「付加情報追加先ノード」を対応付けた付加定義情報に関する情報テーブルである。

「付加情報ノード」は、付加情報を作成する際に用いられるノードを示し、「付加情報追加先ノード」は、付加情報の作成対象となるノードの階層パスを示している。また、「バイト長」は、付加情報として拡張データ格納テーブル（後述の拡張データ格納テーブル１１３）に付加される情報のサイズ（バイト長）を示している。

格納先管理部１９は、格納ルール判定処理部１７によって生成された付加定義情報テーブル１１２を、拡張データ付加情報記憶部３１に格納させる。２バイト分の付加情報は、実施の形態１で説明した拡張データ格納テーブル１０５の拡張データとともに、拡張データ格納テーブル１１３に格納される。

つぎに、格納ルール判定処理部１７は、格納ルール条件情報１１１に従ったデータベーススキーマの生成指示を格納先管理部１９に行なう。格納先管理部１９は、格納ルール判定処理部１７からデータベーススキーマの生成指示を受けると、格納ルール条件情報１１１に基づいて格納先情報テーブル１０２を生成し、格納先情報記憶部２０に記憶させる。さらに、格納先管理部１９は、基本データ格納ＤＢ２３に基本データ格納テーブル１０４を生成する。

基本データ格納ＤＢ２３に基本データ格納テーブル１０４が生成された後、データ入力部１４に格納対象の文書１０３が入力されると、この文書１０３は格納実行部１８に送られる。格納実行部１８は、実施の形態１，２と同様の処理によって、基本データ格納ＤＢ２３内の基本データ格納テーブル１０４に文書１０３の基本データを格納する。

また、格納実行部１８は、実施の形態１，２と同様の処理によって、拡張データ格納ＤＢ２４内に拡張データを格納する。このとき、本実施の形態では、格納実行部１８が拡張データ付加情報記憶部３１に格納されている付加定義情報テーブル１１２を用いて、拡張データ格納ＤＢ２４内に拡張データ格納テーブル１１３を格納する。拡張データ格納テーブル１１３は、付加情報および拡張データを格納する情報テーブル（付加情報付きのノードテーブル）である。

図１７は、付加情報を有した拡張データ格納テーブルの構成を示す図である。拡張データ格納テーブル１１３は、「ノードＩＤ」、「親ノードＩＤ」、「階層パス」、「ノード名」、「ノード値」、「基本データ格納テーブル名」、「基本データエントリＩＤ」、「付加情報」が対応付けられている。換言すると、拡張データ格納テーブル１１３は、実施の形態１で説明した拡張データ格納テーブル１０５に、付加情報を対応付けた情報テーブルである。

図１７に示した拡張データ格納テーブル１１３では、「ノードＩＤ」が「５」の行の、ノード名が「ｇｅｎｒｅ」のノードに、付加情報として「／ｍｕｓｉｃ／ｔｉｔｌｅ／ｋａｎａ／」のノード値（曲名フリガナ）の２バイト分、”ウ”が追加された場合を示している。

ここで、データ入力部１４から複数の文書が入力された場合の、基本データ格納テーブルと、拡張データ格納テーブルの構成例（生成結果例）について説明する。図１８は、基本データ格納テーブル名が「ｍｕｓｉｃ−ｌｉｓｔ」である基本データ格納テーブル１１４の構成を示している。

例えば、「基本データエントリＩＤ」が「２」の基本データは、「ｔｉｔｌｅ」が「ドナウ河のさざ波」であり、「ｔｉｔｌｅ−ｋａｎａ」が「ドナウガワノサザナミ」であり、「ａｒｔｉｓｔ」が「イヴァノヴィッチ」であり、「ａｒｔｉｓｔ−ｋａｎａ」が「イヴァノヴィッチ」である。

図１９は、図１８に示した基本データ格納テーブルに対応する拡張データ格納テーブルである。図１９では、図１６に示した付加定義情報に基づいて、図１８に示した基本データ格納テーブルに付加情報を付加した場合を示している。図１９に示すように、基本データ格納テーブル１１４に対応する拡張データ格納テーブル１１５は、「ノードＩＤ」、「親ノードＩＤ」、「階層パス」、「ノード名」、「ノード値」、「基本データ格納テーブル名」、「基本データエントリＩＤ」、「付加情報」が対応付けられている。

例えば、「ノードＩＤ」が「８」の拡張データは、「親ノードＩＤ」が「７」であり、「階層パス」が「／ｍｕｓｉｃ／ｇｅｎｒｅ／」である。また、「ノード名」は、「ｇｅｎｒｅ」であり、「ノード値」は、「クラシック」である。さらに、「基本データ格納テーブル名」は、「ｍｕｓｉｃ−ｌｉｓｔ」であり、「基本データエントリＩＤ」は「２」である。

図１９に示した拡張データ格納テーブル１１５では、階層パスが「／ｍｕｓｉｃ／ｇｅｎｒｅ／」のノードは、例えば「ノードＩＤ」が「８」の行のノードである。そして、このノードの基本データエントリＩＤは、「２」である。基本データエントリＩＤが「２」の基本データに含まれるノード値のうち、「／ｍｕｓｉｃ／ｔｉｔｌｅ／ｋａｎａ／」のノード値は、図１８の基本データ格納テーブル１１４より、「ドナウガワノサザナミ」である。

したがって、格納実行部１８は、付加情報を作成する際に用いるノードのノード値として、「ドナウガワノサザナミ」を抽出する。そして、「ドナウガワノサザナミ」から２バイト分の情報として「ド」を抽出し、抽出した「ド」を付加情報とする。格納実行部１８は、この「ド」を「ノードＩＤ」が「８」の行のノードに対応付けて、拡張データ格納テーブル１１５に格納する。

このように、本実施の形態では、所定階層のノードに対して別階層のノード（付加情報）を組み合わせて同一レコードに格納させるようユーザから付加定義情報によって指示されることによって、データ管理装置１は、所定のノードが格納されるレコードに、このノードとは異なる同一レコード内の他のノードの値の一部または全部を対応付けて格納する。これにより、組み合わせられた階層のノードに、当該階層のノードを格納するレコードのインデックスとしての役割を持たせることが可能となる。

つぎに、データ管理装置１に格納されたデータの検索処理について説明する。なお、図８に示した実施の形態１のデータ検索処理と同様の処理についてはその説明を省略する。拡張データ格納ＤＢ２４（付加情報が付加された拡張データ格納テーブル１１５）や基本データ格納ＤＢ２３に対して、例えば、／ｍｕｓｉｃ／ｇｅｎｒｅ／＝”クラシック”の検索条件で検索要求がなされると、この検索要求は検索要求入力部１１から検索処理部１５へ送られる。

検索処理部１５は、階層がｍｕｓｉｃの下のｇｅｎｒｅで、その値が“クラシック”であるデータのセットを取得するために、／ｍｕｓｉｃ／ｇｅｎｒｅ／の階層を格納先管理部１９へ問い合わせる。

格納先管理部１９は、検索処理部１５から問い合わせのあった階層に一致する条件を格納先情報テーブル１０２から抽出し、抽出した基本データ格納テーブル名やカラム名を検索処理部１５へ送る。この後、検索処理部１５は、基本データ検索部２１と拡張データ検索部２２に、基本データの検索と拡張データの検索を行なわせる。

拡張データ格納ＤＢ２４では、／ｍｕｓｉｃ／ｇｅｎｒｅ／の階層が拡張データ格納ＤＢ２４に格納されているので、拡張データ格納テーブル１１５から拡張データの検索が行われる。

拡張データ検索部２２は、検索結果として複数の／ｍｕｓｉｃ／ｇｅｎｒｅ／のノードを示すレコードを得ることができる。このとき、検索結果として得ることができるレコードの件数が多いと、この拡張データに対応する全ての基本データを基本データ格納テーブル１１４から取得する際に長時間を要する。また、得られた拡張データや基本データを例えば５０音順にソートして、ユーザに提供するまでには長時間を要する。

そこで、本実施の形態では、所定の検索条件を追加することによって、データの検索処理を行なう。例えば、ア行で始まる曲名が必要な場合、以下に示す検索条件によってデータ検索を行なう。すなわち、拡張データ検索部２２は、「／ｍｕｓｉｃ／ｇｅｎｒｅ／＝”クラシック”」かつ「／ｍｕｓｉｃ／ｔｉｔｌｅ／の先頭２バイト＜”ア”」の検索条件によってデータ検索を行なう。

これにより、拡張データ検索部２２は、拡張データ格納ＤＢ２４内の拡張データ格納テーブル１１５から検索した、／ｍｕｓｉｃ／ｇｅｎｒｅ／のノードを示すレコードの中から、ア行で始まる曲だけを取り出すことができる。

拡張データ検索部２２は、拡張データの検索結果を５０音順にソートするとともに、ソートした検索結果を検索処理部１５に送る。図２０は、ソート後の検索結果の一例を示す図である。同図に示すように検索結果テーブル１１６は、「ノードＩＤ」、「親ノードＩＤ」、「階層パス」、「ノード名」、「ノード値」、「基本データ格納テーブル名」、「基本データエントリＩＤ」、「付加情報」が対応付けられている。

例えば、「ノードＩＤ」が１１のレコードとして、「親ノードＩＤ」＝１０、「階層パス」＝／ｍｕｓｉｃ／ｇｅｎｒｅ／、「ノード名」＝ｇｅｎｒｅ、「ノード値＝クラシック、「基本データ格納テーブル名」＝ｍｕｓｉｃ−ｌｉｓｔ、「基本データエントリＩＤ」＝７、「付加情報」＝アが得られる。

拡張データ検索部２２は、取得した検索結果を検索処理部１５へ送り、検索処理部１５が検索結果を検索結果出力部１２へ送る。そして、検索結果出力部１２から検出結果が出力される。ユーザは、その後、この検索結果に基づいて、基本データ格納ＤＢ２３内の基本データ格納テーブル１１４から、拡張データに対応する基本データを取得すればよい。

なお、本実施の形態では、付加情報が１つの場合について説明したが、付加情報は１つに限らず複数であってもよい。また、付加情報は２バイトに限らず何れのサイズであってもよい。

このように実施の形態３によれば、拡張データ格納テーブルに付加情報を付加しているので、データの検索結果を迅速にソートすることが可能となり、データの条件検索を迅速に行なうことが可能になる。また、所定の条件検索が必要なノードに対してのみ付加情報を与えるので、拡張データ格納ＤＢ２４のメモリサイズが冗長に大きくならずに済む。

以上のように、本発明に係るデータ管理装置は、ＸＭＬ文書の格納とデータ検索に適している。

本発明の実施の形態１に係るデータ管理装置の構成を示す図である。 データの格納処理手順を示すフローチャートである。 格納ルール条件情報の一例を示す図である。 格納先情報テーブルの一例を示す図である。 基本データ格納テーブルの構成の一例を示す図である。 格納対象となる文書の構成の一例を示す図である。 拡張データ格納テーブルの構成を示す図である。 データの検索処理手順を示すフローチャートである。 新たな情報テーブルを追加する際に設定される新たな格納ルール条件情報の一例を示す図である。 新たに生成する格納先情報テーブルの一例を示す図である。 新たに追加する基本データ格納テーブルの一例を示す図である。 新たに格納対象となる文書の構成の一例を示す図である。 新たに作成される拡張データ格納テーブルの構成を示す図である。 実施の形態３に係るデータ管理装置の構成を示す図である。 実施の形態３に係る格納ルール条件情報の一例を示す図である。 付加定義情報テーブルの構成の一例を示す図である。 付加情報を有した拡張データ格納テーブルの構成を示す図である。 基本データ格納テーブル名が「ｍｕｓｉｃ−ｌｉｓｔ」である基本データ格納テーブルの構成を示す図である。 図１８に示した基本データ格納テーブルに対応する拡張データ格納テーブルの構成を示す図である。 ソート後の検索結果の一例を示す図である。

符号の説明

１ データ管理装置
１１ 検索要求入力部
１２ 検索結果出力部
１３ 格納ルール入力部
１４ データ入力部
１５ 検索処理部
１６ 格納ルール記憶部
１７ 格納ルール判定処理部
１８ 格納実行部
１９ 格納先管理部
２０ 格納先情報記憶部
２１ 基本データ検索部
２１ 検索処理部
２２ 拡張データ検索部
２３ 基本データ格納ＤＢ
２４ 拡張データ格納ＤＢ
３１ 拡張データ付加情報記憶部
１０１，１０６，１１１ 格納ルール条件情報
１０２，１０７ 格納先情報テーブル
１０３，１０８ 文書
１０４，１０９，１１４ 基本データ格納テーブル
１０５，１１０，１１３，１１５ 拡張データ格納テーブル
１１２ 付加定義情報テーブル
１１６ 検索結果テーブル

Claims (6)

1. ＸＭＬ文書に含まれるデータを分割して、分割したデータをリレーショナルデータベースまたはＸＭＬデータベースに格納するデータ管理装置において、
   分割されるデータの格納先に関する格納ルールに基づいて、前記ＸＭＬ文書内の各データを、予め設定された所定のデータ構造内に格納させる基本データまたは格納先のデータ構造が決められていない拡張データに設定し、前記基本データを前記リレーショナルデータベースに格納させるとともに、前記拡張データを前記ＸＭＬデータベースに格納させる格納実行部と、
   前記各基本データが格納される前記リレーショナルデータベース内の位置および前記各拡張データが格納される前記ＸＭＬデータベース内の位置を、格納先管理情報として記憶する格納先記憶部と、
   前記データの検索要求があった場合に、前記格納先管理情報に基づいて、前記リレーショナルデータベースおよび前記ＸＭＬデータベースから前記検索要求に対応する基本データおよび拡張データを検索する検索処理部と、
   を備えることを特徴とするデータ管理装置。
2. 前記リレーショナルデータベースは、前記基本データを識別する基本データ識別情報を前記基本データに対応付けて格納するとともに、前記ＸＭＬデータベースは、前記拡張データに対応する基本データの前記基本データ識別情報を前記拡張データに対応付けて格納し、
   前記検索部は、前記基本データ識別情報を用いて、前記基本データおよび前記拡張データを検索することを特徴とする請求項１に記載のデータ管理装置。
3. 前記検索部は、前記検索要求に対応する基本データの格納先が前記格納先管理情報に設定されている場合に、前記格納先管理情報に基づいて前記リレーショナルデータベースから前記検索要求に対応する基本データを検索し、その後、検索した基本データに対応付けられている基本データ識別情報に基づいて前記ＸＭＬデータベースから前記検索要求に対応する拡張データを検索することを特徴とする請求項２に記載のデータ管理装置。
4. 前記検索部は、前記検索要求に対応する基本データの格納先が前記格納先管理情報に設定されていない場合に、前記検索要求に対応する基本データの格納先に基づいて前記ＸＭＬデータベースから前記検索要求に対応する拡張データを検索し、その後、検索した拡張データに対応付けられている基本データ識別情報に基づいて前記リレーショナルデータベースから前記検索要求に対応する基本データを検索することを特徴とする請求項２または３に記載のデータ管理装置。
5. 前記格納ルールに基づいて、前記基本データを格納するデータテーブルを前記リレーショナルデータベース内に作成する基本データ格納テーブル作成部をさらに備え、
   前記格納実行部は、前記格納ルールおよび前記拡張データに基づいて、前記拡張データを格納するデータテーブルを前記ＸＭＬデータベース内に作成することを特徴とする請求項１〜４のいずれか１つに記載のデータ管理装置。
6. 前記格納実行部は、前記拡張データに付加する情報を定義した付加定義情報に基づいて、前記拡張データのうちの一部のデータを抽出するとともに抽出した一部のデータを前記拡張データに付加して前記ＸＭＬデータベース内に格納させることを特徴とする請求項１〜５のいずれか１つに記載のデータ管理装置。

Images