JP2004126804A - 文書管理方法および装置 - Google Patents

Abstract

【課題】大量のＸＭＬ文書を効率良く取り扱うことが可能なデータベースを提供する。
【解決手段】ＸＭＬ−ＲＤＢゲートウェイ１００は、登録ユニット１１０によりＸＭＬ文書をリレーショナルデータベースに登録し、問い合わせユニット１２０により登録したＸＭＬデータへの問い合わせを受け付けて必要な処理を実行する。データベース登録部１１６は、ＸＭＬ文書入力部１１２に入力されたＸＭＬ文書を、マッピング定義保持部１１４に保持された規則にしたがってマッピングし、データベースに登録する。この規則は、ある要素に含まれる要素値および属性値のうち、出現数の上限が定まっているものについては、その要素に対応する階層のテーブルに前記上限の数のフィールドを設けてそれらの値を格納するように定められる。
【選択図】　　　　図２

Description

【０００１】
【発明の属する技術分野】
この発明は、文書管理技術に関する。この発明は特に、ＸＭＬなどの構造化言語により記述された文書をデータベースに格納して取り扱う技術に関する。
【０００２】
【従来の技術】
インターネットなどのネットワークを介したデータ交換に適した記述言語に、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）がある。ＸＭＬは、今や、ウェブによる各種サービス、電子商取引など、ＩＴにおいて注目を集める分野のコア技術として採用されている。ＸＭＬは、テキスト形式で記述されるため、マルチプラットフォーム環境でのデータ交換に適している上、文書構造を構成する個々の要素をタグにより記述することで、データの意味やデータ構造を保持したままデータ交換が可能である。また、タグの名前やタグの階層構造などをユーザが定義できるので、データの種類などに応じて柔軟に文書構造を規定することができる。このような多くの利点により、様々な分野においてデータがＸＭＬにより電子化され、利用されるようになっている。
【０００３】
大量のＸＭＬデータを効率良く扱うためには、ＸＭＬ文書をデータベースに格納して取り扱う必要がある。ＸＭＬデータを扱うデータベースとして、階層型データベース、リレーショナルデータベース、オブジェクト指向データベースなどが提案されている。（たとえば、非特許文献１参照）。
【０００４】
【非特許文献１】
大野　邦夫、「ＸＭＬデータベース再考」、ＸＭＬマガジン０４、ｐ．６０−ｐ．７４
【０００５】
【発明が解決しようとする課題】
しかしながら、従来のＸＭＬデータベースは、階層構造や要素の出現順序の適切な管理、データ操作の高速性、記憶領域の使用効率、インターフェイスの容易さ、などの観点から見て、いずれも一長一短と言わざるを得ない。大量のＸＭＬデータがやり取りされるようになった現在、ＸＭＬの利点を最大限に生かしつつ、大量のデータの取り扱いに適したデータベースを利用するための新たな技術が求められている。
【０００６】
本発明はこうした状況に鑑みてなされたものであり、その目的は、大量のＸＭＬ文書を効率良く取り扱うことが可能なデータベースを提供することにある。本発明の別の目的は、ＸＭＬ文書の利点を最大限に生かしたデータベースの利用技術を提供することにある。
【０００７】
【課題を解決するための手段】
本発明のある態様は、文書管理装置に関する。この文書管理装置は、構造化言語により記述された文書の入力を受け付ける入力部と、前記文書に含まれる要素値または属性値を、前記文書が有する階層構造を反映して設けられたテーブルにマッピングするための規則を保持する保持部と、前記規則を前記保持部から読み出して、その規則に基づいて前記要素値または属性値をテーブルにマッピングし、データベースに登録する登録部と、を備え、前記規則は、ある要素に含まれる要素値および属性値のうち、出現数の上限が定まっているものについては、その要素に対応する階層のテーブルに前記上限の数のフィールドを設けてそれらの値を格納するように定められる。
【０００８】
上位の階層の要素から順にテーブルにマッピングするとき、ある要素が１以上の同種のデータを含んでいる場合、そのデータの出現数が定まっている場合はそのテーブルにフィールドを設けて格納し、出現数が不定の場合は新たにテーブルを設けて格納する。新たに設けたテーブルは、下位階層の要素に対応したテーブルであり、上位のテーブルとの間でリレーションを張ることにより、文書の階層構造を反映した階層的なテーブル設計が実現される。ここで、文書に含まれる要素の階層構造に忠実にテーブルを設けると、記録領域の使用効率や検索効率が低下する場合があるが、出現数が定まったデータについては新たにテーブルを設けずに上位のテーブルに格納することで、記録領域の使用効率および検索効率を向上させることができる。
【０００９】
前記規則は、前記文書に含まれる要素値および属性値のうち、検索キーとして利用するものを抽出してテーブルにマッピングするように定められてもよい。これにより、さらに記録領域の使用効率や検索効率を向上させることができる。
【００１０】
前記テーブルは、前記要素値または属性値の前記文書中における出現順序を示す情報を格納するフィールドを含み、前記規則は、前記要素値または属性値と前記出現順序とを対応付けてテーブルに格納するように定められてもよい。文書を構成する要素の出現順序も重要な意味を持つので、出現順序を適切に保存しつつデータを管理することが重要である。
【００１１】
前記登録部は、前記要素値または属性値に対して所定の演算を施した結果をテーブルに格納してもよい。たとえば、テキストデータを連結したり、数字データに算術演算を施したりした結果を格納してもよい。
【００１２】
下位の階層の要素に対応するテーブルに、その要素を含む上位の階層の要素の識別情報を格納するフィールドを設け、前記規則は、前記下位の階層の要素の要素値または属性値と、前記上位の階層の要素の識別情報とを対応付けて格納してもよい。これにより、下位の階層のテーブルに格納されたデータであっても、上位の階層のテーブルを参照することなく、データを一意に識別することができる。
【００１３】
前記文書に対する問い合わせを行うための第１の問い合わせ言語により記述された第１の問い合わせ文を受け付ける問い合わせ受付部と、前記第１の問い合わせ文に記述された問い合わせを実行するために必要な処理を、前記データベースを管理する管理部に要求すべく、前記データベースに対する問い合わせを行うための第２の問い合わせ言語により記述された第２の問い合わせ文を生成する生成部と、前記第２の問い合わせ文を前記管理部に送る送信部と、前記管理部から前記第２の問い合わせ文に対する結果を受信する受信部と、前記結果に基づいて、前記第１の問い合わせ文に対する応答を生成する応答生成部と、前記応答を問い合わせ先に送信する応答送信部と、をさらに備えてもよい。第１の問い合わせ言語は、たとえば、ＸＱｕｅｒｙ、ＸＱＬ、ＸＰａｔｈなどであり、第２の問い合わせ言語は、たとえば、リレーショナルデータベース用の問い合わせ言語であるＳＱＬなどである。内部的には大量のデータの取り扱いに適したリレーショナルデータベースを使用しつつ、ユーザ側のインターフェイスにはＸＭＬ用の問い合わせ言語を利用することができる。
【００１４】
本発明の別の態様は、文書管理方法に関する。この方法は、構造化言語により記述された文書を受け付ける工程と、前記文書に含まれる要素値または属性値を、前記文書が有する階層構造を反映して設けられたテーブルにマッピングするための規則を予め取得して保持する工程と、前記規則に基づいて、前記要素値または属性値をテーブルにマッピングしてデータベースに登録する工程と、を含み、前記規則は、ある要素に含まれる要素値および属性値のうち、出現数が不定のものについては、その要素値または属性値を格納するための下位階層のテーブルを新たに設けて値を格納するように定められる。
【００１５】
なお、以上の構成要素の任意の組合せや、本発明の構成要素や表現を方法、装置、システム、コンピュータプログラム、コンピュータプログラムを格納した記録媒体などの間で相互に置換したものもまた、本発明の態様として有効である。
【００１６】
【発明の実施の形態】
【００１７】
図１は、実施の形態に係るデータベース管理システム１０の全体構成を示す。このデータベース管理システム１０は、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）、ＳＧＭＬ（Ｓｔａｎｄａｒｄ　Ｇｅｎｅｒａｌｉｚｅｄ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）などの構造化言語により記述された文書を、リレーショナルデータベース（Ｒｅｌａｔｉｏｎａｌ　ＤａｔａＢａｓｅ：以下、「ＲＤＢ」とも表記する）に格納して取り扱うことにより、大量の文書を効率良く扱うことを可能とする。本実施の形態では、ＸＭＬにより記述された文書をＲＤＢに格納する場合について説明する。
【００１８】
データベース管理システム１０は、クライアント２０ａおよび２０ｂ、ＷｅｂＤＡＶサーバ３０、ＸＭＬ−ＲＤＢゲートウェイ１００、ＲＤＢ管理ユニット４０、およびデータストレージ５０を含む。各装置は、有線または無線のネットワークにより接続され、ネットワークを介して互いに通信を行う。ＸＭＬ−ＲＤＢゲートウェイ１００は、クライアントから、ＸＭＬ文書に対する問い合わせに適したＸＱｕｅｒｙなどの問い合わせ言語による問い合わせを受け付け、それをＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ　Ｑｕｅｒｙ　Ｌａｎｇｕａｇｅ）などのＲＤＢ用の問い合わせ言語に変換してＲＤＢ管理ユニット４０へ送る。すなわち、ＸＭＬ−ＲＤＢゲートウェイ１００は、クライアントとＲＤＢ管理システムとを仲介するゲートウェイの機能を有する。ＸＭＬの問い合わせ言語には、ＸＰａｔｈ（ＸＭＬ　Ｐａｔｈ　Ｌａｎｇｕａｇｅ）、ＸＱＬ（ＸＭＬ　Ｑｕｅｒｙ　Ｌａｎｇｕａｇｅ）、ＸＱｕｅｒｙなどがあるが、本実施の形態では、ＸＱｕｅｒｙを例にとって説明する。
【００１９】
クライアント２０ａおよび２０ｂは、データベース管理システム１０を利用するユーザの装置である。ユーザは、クライアントアプリケーション２２ａまたは２２ｂを用いてデータベースを利用する。クライアントアプリケーション２２ａは、ＸＭＬ−ＲＤＢゲートウェイ１００に直接問い合わせを行うためのモジュールであるクライアントインターフェースライブラリ２４を備えており、ＸＭＬ−ＲＤＢゲートウェイ１００がサポートする問い合わせ言語、ここではＸＱｕｅｒｙにより問い合わせを行う。ＷｅｂＤＡＶサーバ３０は、ＷｅｂＤＡＶ（Ｗｅｂ−ｂａｓｅｄ　Ｄｉｓｔｒｉｂｕｔｅｄ　Ａｕｔｈｏｒｉｎｇ　ａｎｄ　Ｖｅｒｓｉｏｎｉｎｇ）プロトコルをサポートするサーバであり、クライアントアプリケーション２２ａおよび２２ｂからＨＴＴＰ（Ｈｙｐｅｒ−Ｔｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）による問い合わせを受け付け、ＸＭＬ−ＲＤＢゲートウェイモジュール３２によりＸＱｕｅｒｙに変換して問い合わせを行う。これにより、クライアントインターフェースライブラリ２４を備えていないクライアントアプリケーション２２ｂであっても本データベース管理システム１０を利用することができる。
【００２０】
ＸＭＬ−ＲＤＢゲートウェイ１００は、クライアントアプリケーション２２ａから直接、またはＷｅｂＤＡＶサーバ３０を介して、ユーザからの問い合わせを受け付け、それをＲＤＢ管理ユニット４０がサポートする問い合わせ言語、ここではＳＱＬに変換して問い合わせを行う。ＲＤＢ管理ユニット４０は、既知のＲＤＢＭＳ（Ｒｅｌａｔｉｏｎａｌ　ＤａｔａＢａｓｅ　Ｍａｎａｇｅｍｅｎｔ　Ｓｙｓｔｅｍ）であってよく、ＳＱＬによる問い合わせを受け付けて、データストレージ５０に格納されたＲＤＢに対して、ＡＰＰＥＮＤ（格納）、ＵＰＤＡＴＥ（更新）、ＤＥＬＥＴＥ（削除）、ＳＥＬＥＣＴ（取得）などの処理を行う。
【００２１】
ＸＭＬ−ＲＤＢゲートウェイ１００は、データベースに登録すべきＸＭＬ文書を外部から取得し、それを所定のマッピング定義に基づいてＲＤＢのテーブルへマッピングする機能も有する。このような構成により、ＲＤＢをＸＭＬデータベースとして利用することが可能となる。図１に示した各構成は、それぞれ別の装置により実現されてもよいし、いくつかの構成が一つの装置により実現されてもよい。データベース管理システム１０は、クライアント−サーバシステムとして実現されてもよいし、スタンドアロンシステムとして一つの装置内に実現されてもよい。このように、本実施の形態のデータベース管理システム１０を実現する装置の構成に自由度が高いことは当業者に理解されるところである。
【００２２】
図２は、ＸＭＬ−ＲＤＢゲートウェイ１００の内部構成を示す。ＸＭＬ−ＲＤＢゲートウェイ１００は、主に、ＸＭＬ文書をＲＤＢに登録する登録ユニット１１０、およびＲＤＢに対する問い合わせを行う問い合わせユニット１２０を備える。ＸＭＬ−ＲＤＢゲートウェイ１００は、ハードウエア的にはコンピュータのＣＰＵやメモリなどの構成で実現でき、ソフトウエア的にはゲートウェイ機能のあるプログラムなどによって実現できるが、本図ではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウエアの組合せによっていろいろなかたちで実現できる。
【００２３】
登録ユニット１１０は、ＲＤＢに登録するＸＭＬ文書を外部から取得するＸＭＬ文書入力部１１２と、ＸＭＬ文書をテーブルにマッピングするときの規則を記述したマッピング定義を保持するマッピング定義保持部１１４と、ＸＭＬ文書をマッピング定義にしたがってテーブルにマッピングし、ＲＤＢに登録するデータベース登録部１１６とを備える。ＸＭＬ文書をテーブルにマッピングする方法の詳細については、例を参照しつつ後述する。
【００２４】
問い合わせユニット１２０は、クライアント２０からＸＱｕｅｒｙによる問い合わせを受け付ける問い合わせ受付部１２２と、受け付けた問い合わせ文を解析し、ＳＱＬ文に変換する解析部１２４と、ＳＱＬによる問い合わせ文をＲＤＢ管理ユニット４０に送信する問い合わせ送信部１２６と、ＲＤＢ管理ユニット４０から問い合わせの結果を取得する問い合わせ結果取得部１３２と、問い合わせ結果取得部１３２が取得した結果を、もとのＸＱｕｅｒｙによる問い合わせ文に基づいてＸＭＬ文書に整形する文書整形部１３４と、整形されたＸＭＬ文書を問い合わせの結果としてクライアント２０に送信する文書送信部１３６とを備える。問い合わせの方法の詳細については、例を参照しつつ後述する。
【００２５】
まず、文書型定義（Ｄｏｃｕｍｅｎｔ　Ｔｙｐｅ　Ｄｅｆｉｎｉｔｉｏｎ：以下、「ＤＴＤ」ともいう）に則って記述された、正当な（ｖａｌｉｄ）ＸＭＬ文書をテーブルにマッピングしてＲＤＢに登録する方法を説明する。正当なＸＭＬ文書は、含まれる要素や構造が決まっているから、一度マッピング定義を定めると、そのマッピング定義にしたがって大量の文書を効率よくＲＤＢに格納することができる。文書型定義として、ＸＭＬ−ＳｃｈｅｍａやＲｅｌａｘなどを利用してもよい。
【００２６】
図３は、データベースに格納すべきＸＭＬ文書のサンプルデータのＤＴＤを示す。このＸＭＬ文書は、会合に参加したグループの構成メンバーを記述するものである。ＤＴＤから分かるとおり、ルート要素　”ｌｉｓｔ”　は、子要素として、必ず１回出現する要素　”ｍｏｎｔｈ”　と、０回以上出現する要素　”ｇｒｏｕｐ”　とを、この順序で含み、さらに属性値として文字データ　”ｙｅａｒ”　を含む。属性値　”ｙｅａｒ”　は、ここでは、会合が開催された年を格納する。要素　”ｍｏｎｔｈ”　は文字データを含み、ここでは、会合が開催された月を格納する。要素　”ｇｒｏｕｐ”　は、必ず１回出現する要素　”ｎａｍｅ”　と、１回以上出現する要素　”ｍｅｍｂｅｒ”　とを、この順序で含む。要素　”ｎａｍｅ”　は文字データを含み、ここでは、会合に参加したグループ名を格納する。要素　”ｍｅｍｂｅｒ”　は文字データを含み、ここでは、会合に参加したグループの構成メンバー名を格納する。
【００２７】
図４は、データベースに格納すべきＸＭＬ文書のサンプルデータを示す。このＸＭＬ文書には、２００２年８月に開催された会合に参加したグループの構成メンバーが格納されており、グループ名「Ｔｅａｍ　Ａ」のグループの構成メンバーは、「Ａ１」、「Ａ２」、「Ａ３」の３名であり、グループ名「Ｔｅａｍ　Ｂ」のグループの構成メンバーは、「Ｂ１」、「Ｂ２」、「Ｂ３」、「Ｂ４」の４名であり、グループ名「Ｔｅａｍ
Ｃ」のグループの構成メンバーは、「Ｃ１」、「Ｃ２」の２名である。
【００２８】
図５は、図４に示したＸＭＬ文書をテーブルにマッピングした例を示す。図５の例では、ＸＭＬ文書の階層構造を反映した３つのテーブルにデータが格納されている。まず、第１のテーブル　”ｔａｂｌｅ１”　には、トップノードである　”ｌｉｓｔ”　ノードに対応する「ｌｉｓｔ＿」欄を設け、”ｌｉｓｔ”　ノードにＩＤ番号を割り当てて格納する。このＩＤ番号は、ＸＭＬファイルのＩＤ番号としての意味も有する。さらに、この　”ｌｉｓｔ”　ノードに含まれる出現数の上限が定まった要素値および属性値の欄を設ける。この例では、”ｌｉｓｔ”　ノードの属性値　”ｙｅａｒ”　と、”ｍｏｎｔｈ”　ノードの要素値は、それぞれ　”ｌｉｓｔ”　ノードに１回ずつ含まれるので、「ｌｉｓｔ＿＿ｙｅａｒ」欄と、「ｌｉｓｔ＿ｍｏｎｔｈ」欄を１つずつ設け、それぞれの値を格納する。
【００２９】
”ｌｉｓｔ”　ノードに含まれる要素のうち、”ｇｒｏｕｐ”　ノードは出現数の上限値が定まっていないため、第１のテーブル　”ｔａｂｌｅ１”　に適当な数の欄を設けて格納しようとすると、それよりも多くの　”ｇｒｏｕｐ”　ノードが出現した場合に、そのＸＭＬ文書を格納することができない。また、そのような事態を見越して必要以上の欄を設けておいた場合には、記憶領域の使用効率が低下してしまう。そのため、本実施の形態では、出現数が不定な要素については、新たにテーブルを設けて格納する。
【００３０】
第２のテーブル　”ｔａｂｌｅ２”　には、”ｇｒｏｕｐ”　ノードの出現順序を格納する「ｌｉｓｔ＿ｇｒｏｕｐ＿」欄を設け、”ｇｒｏｕｐ”　ノードに対して、ＸＭＬ文書における出現順にＩＤ番号を割り当てて格納する。すなわち、このＩＤ番号は、単にレコードを一意に識別するだけでなく、ＸＭＬ文書におけるノードの出現順序をも示している。このように、出現順序を格納しておくことで、後述するように、ＸＭＬなどの構造化言語により記述されたデータに適した検索処理および検索結果の出力処理を行うことができる。第２のテーブル　”ｔａｂｌｅ２”　には、さらに、”ｇｒｏｕｐ”　ノードに必ず１回含まれるノード　”ｎａｍｅ”　の要素値を格納するための「ｌｉｓｔ＿ｇｒｏｕｐ＿ｎａｍｅ」欄が設けられる。また、新たに設けた第２のテーブル　”ｔａｂｌｅ２”　にも、「ｌｉｓｔ＿」欄を設けておき、第１のテーブル　”ｔａｂｌｅ１”　の「ｌｉｓｔ＿」欄に　ｆｏｒｅｉｇｎ　ｋｅｙ　指定をして、リレーションを張るとともに、データ削除処理のために、ＯＮ　ＵＰＤＡＴＥ　ＣＡＳＣＡＤＥ　指定をしておく。このように、下位の階層の要素を格納したテーブルにも上位の要素のＩＤ番号を格納しておくことで、上位のテーブルを参照することなく、各データをテーブル内で一意に識別することができるため、ＳＱＬによる問い合わせにおいて１回の指定でデータにアクセスすることが可能となる。この点についても、例を参照しつつ後述する。”ｇｒｏｕｐ”　ノードに含まれる要素のうち、”ｍｅｍｂｅｒ”　ノードは出現数が不定であるため、第２のテーブル　”ｔａｂｌｅ２”　には格納せず、新たに第３のテーブルを設けて格納する。
【００３１】
第３のテーブル　”ｔａｂｌｅ３”　には、”ｍｅｍｂｅｒ”　ノードの出現順序を格納する「ｌｉｓｔ＿ｇｒｏｕｐ＿ｍｅｍｂｅｒ＿」欄を設け、”ｍｅｍｂｅｒ”　ノードに対して、ＸＭＬ文書における出現順にＩＤ番号を割り当てて格納する。第３のテーブル　”ｔａｂｌｅ３”　には、さらに、”ｍｅｍｂｅｒ”　ノードの要素値を格納するための「ｌｉｓｔ＿ｇｒｏｕｐ＿ｍｅｍｂｅｒ」欄が設けられる。また、新たに設けた第３のテーブル　”ｔａｂｌｅ３”　に、「ｌｉｓｔ＿」欄および「ｌｉｓｔ＿ｇｒｏｕｐ＿」欄を設けておき、それぞれ、第１のテーブル　”ｔａｂｌｅ１”　の「ｌｉｓｔ＿」欄、第２のテーブル　”ｔａｂｌｅ２”　の「ｌｉｓｔ＿ｇｒｏｕｐ＿」欄にリレーションを張り、ＯＮ　ＵＰＤＡＴＥ　ＣＡＳＣＡＤＥ　指定をしておく。
【００３２】
図４に示したＸＭＬ文書は、上述したような規則に則って図５に示したテーブルにマッピングされる。本実施の形態では、このようなマッピング定義をＸＭＬ文書で記述し、マッピング定義保持部１１４に保持する。データベース登録部１１６は、このマッピング定義ファイルを参照して、入力されたＸＭＬ文書をテーブルに展開する。
【００３３】
図６は、マッピング定義を記述するＸＭＬ文書のＤＴＤを示す。マッピング定義は、ルート要素　”ｍａｐ”　を有する。要素　”ｍａｐ”　は、その下位に、１回以上出現する要素　”ｔａｂｌｅ”　を有する。要素　”ｔａｂｌｅ”　は、テーブルごとに設けられ、属性値として、テーブルの名称を格納する　”ｎａｍｅ”　を必ず含み、さらに、その下位に、１回以上出現する要素　”ｃｏｌｕｍｎ”　を有する。要素　”ｃｏｌｕｍｎ”　は、欄ごとに設けられ、省略不可能な属性値として、欄の名称を格納する　”ｎａｍｅ”　を含み、省略可能な属性値として、オプション設定を格納する　”ｏｐｔｉｏｎ”、他のテーブルの欄とのリレーションを格納する　”ｒｅｌａｔｉｏｎ”　、ＲＤＢにおけるテーブル定義に使用するデータ型を格納する　”ｔｙｐｅ”、欄に該当する要素または属性を指す　ｘｐａｔｈ　を格納する　”ｘｐａｔｈ”　を含む。
【００３４】
図７は、図４に示したＸＭＬ文書をテーブルに展開するためのマッピング定義を示す。テーブルの型は、「ＣＡＳＣＡＤＥ」であり、３つのテーブルが設けられる。第１のテーブルは、名称が「ｔａｂｌｅ１」であり、３つの欄を有する。第１の欄「ｌｉｓｔ＿」は、ＩＤを格納した整数型で、ｘｐａｔｈ　は「／ｌｉｓｔ」である。第２の欄「ｌｉｓｔ＿＿ｙｅａｒ」は、整数型で、ｘｐａｔｈ　は「／ｌｉｓｔ／＠ｙｅａｒ」である。第３の欄「ｌｉｓｔ＿ｍｏｎｔｈ」は、３２バイトの文字列型で、ｘｐａｔｈ　は「／ｌｉｓｔ／ｍｏｎｔｈ」である。第２のテーブルは、名称が「ｔａｂｌｅ２」であり、３つの欄を有する。第１の欄「ｌｉｓｔ＿」には、第１のテーブルの「ｌｉｓｔ＿」へのリレーションが張られている。第２の欄「ｌｉｓｔ＿ｇｒｏｕｐ＿」はＩＤを格納した整数型で、ｘｐａｔｈ　は「／ｌｉｓｔ／ｇｒｏｕｐ」である。第３の欄「ｌｉｓｔ＿ｇｒｏｕｐ＿ｎａｍｅ」は、６４バイトの文字列型で、ｘｐａｔｈ　は「／ｌｉｓｔ／ｇｒｏｕｐ［ｌｉｓｔ＿ｇｒｏｕｐ＿］」である。第３のテーブルは、名称が「ｔａｂｌｅ３」であり、４つの欄を有する。第１の欄「ｌｉｓｔ＿」は、第１のテーブルの「ｌｉｓｔ＿」へのリレーションが張られている。第２の欄「ｌｉｓｔ＿ｇｒｏｕｐ＿」には、第２のテーブルの「ｌｉｓｔ＿ｇｒｏｕｐ＿」へのリレーションが張られている。第３の欄「ｌｉｓｔ＿ｇｒｏｕｐ＿ｍｅｍｂｅｒ＿」はＩＤを格納した整数型で、ｘｐａｔｈ　は「／ｌｉｓｔ／ｇｒｏｕｐ［ｌｉｓｔ＿ｇｒｏｕｐ＿］／ｍｅｍｂｅｒ／」である。第４の欄「ｌｉｓｔ＿ｇｒｏｕｐ＿ｍｅｍｂｅｒ」は、６４バイトの文字列型で、ｘｐａｔｈ　は「／ｌｉｓｔ／ｇｒｏｕｐ［ｌｉｓｔ＿ｇｒｏｕｐ＿］／ｍｅｍｂｅｒ［ｌｉｓｔ＿ｇｒｏｕｐ＿ｍｅｍｂｅｒ＿］」である。
【００３５】
上記の例では、ＸＭＬ文書に含まれる全てのノードをテーブルにマッピングしたが、検索対象としないノードはテーブルにマッピングせず、検索キーとなるノードのみをテーブルにマッピングしてもよい。これにより、記憶領域の使用効率および検索効率を向上させることができる。この場合、マッピングしなかったノードのデータも必要であるから、ＸＭＬ文書全体をＢＬＯＢ（ｂｉｎａｒｙ　ｌａｒｇｅ　ｏｂｊｅｃｔ）型などの形式で格納しておいてもよい。テーブルにマッピングしていないノードに対する取得、更新などの問い合わせがあった場合は、ＢＬＯＢ型で格納されたデータに対して処理を行う。これにより、マッピングすることが不可能なデータを含むＸＭＬ文書であっても、本実施の形態のデータベース管理システムにより取り扱うことが可能となる。また、ノードの前後関係を修復したり、ノードツリー単位で更新したりすることが可能となる。全てのデータをテーブルにマッピングした場合であっても、ＸＭＬ文書全体をＢＬＯＢ型で格納しておいてもよい。
【００３６】
上述のマッピング定義ファイルは、データベース設計時にユーザまたはデータベース管理者が、ＸＭＬ文書の構造および内容を考慮し、検索キーとなるノードを抽出して作成してもよいし、図示しないマッピング定義生成部がＤＴＤまたはスキーマを参照して自動的に生成してもよい。後者の場合、マッピング定義生成部は、ＤＴＤ、ＸＭＬ−Ｓｃｈｅｍａ、またはＲｅｌａｘなどの文書型定義を参照して文書の階層構造を取得した後、文書に含まれる要素のうちテーブルにマッピングすべき要素をユーザに指定させるべく、要素の一覧を階層的に示したＧＵＩなどをユーザに提供し、ユーザの指示を受けつつ半自動的にマッピング定義を生成してもよい。ＸＭＬ−ＳｃｈｅｍａやＲｅｌａｘでは、データ型を指定することができるので、それを参照して、マッピングするテーブルのカラムの型を適切に指定することができる。
【００３７】
データベース登録部１１６は、ＸＭＬファイルをデータベースに登録する際に、要素値および属性値をそのまま格納するだけでなく、それらに何らかの演算を施したものを格納してもよい。演算の例として、複数のノードの文字列を連結して格納する場合について説明する。
【００３８】
図８は、サンプルデータのＸＭＬ文書のＤＴＤを示す。このＸＭＬ文書は、電子メールの内容を格納するものである。ルート要素　”ｍａｉｌ”　は、子要素として、必ず１回ずつ出現する要素　”Ｆｒｏｍ”　および　”ｂｏｄｙ”　をこの順序で含む。要素　”Ｆｒｏｍ”　は、必ず１回ずる出現する要素　”ｎａｍｅ”　および　”ａｄｄｒｅｓｓ”　をこの順序で含む。要素　”ｎａｍｅ”　は文字データを含み、ここでは電子メールの送信者の名前を格納する。要素　”ａｄｄｒｅｓｓ”　は文字データを含み、ここでは電子メールの送信者の電子メールアドレスを格納する。要素　”ｂｏｄｙ”　は、任意の順序で０回以上出現する、文字データ、要素　”ｂｒ”、および要素　”ｋｅｙｗｏｒｄ”　を含み、ここでは電子メールの本文を格納する。要素　”ｂｒ”　は文字データを０回または１回含み、ここでは改行を意味する。要素　”ｋｅｙｗｏｒｄ”　は文字データを含み、ここではキーワードとなる語を格納する。
【００３９】
図９は、サンプルデータのＸＭＬ文書を示す。このＸＭＬ文書には、名前が「Ｙ．　Ａ．」、電子メールアドレスが「Ｙ．Ａ．＠ｘｘｘ．ｘｘ．ｘｘ」である送信者が送信した電子メールの本文「Ａです。・・・」が格納されている。
【００４０】
図１０は、図９に示したＸＭＬ文書のマッピング定義を示す。図８に示したＤＴＤから分かるとおり、ルート要素　”ｍａｉｌ”　に含まれる要素値および属性値のうち、要素　”ｎａｍｅ”　および要素　”ａｄｄｒｅｓｓ”　の要素値は、それぞれ出現回数が１回と定まっているため、最上位のテーブルに欄を設けて格納することが可能である。要素　”Ｆｒｏｍ”　は属性値および要素値を持たないので、テーブルにマッピングしない。本実施の形態では、要素　”ｂｏｄｙ”　に含まれる文書整形用のタグ　”ｂｒ”　および　”ｋｅｙｗｏｒｄ”　を取り除き、電子メール本文に含まれるテキストデータを連結して格納することにする。そのため、要素　”ｂｏｄｙ”　の出現回数も１回と定まっているため、最上位のテーブルに格納可能である。したがって、テーブルは１つのみでよく、電子メールに割り当てられたＩＤ番号を格納する欄　”ｍａｉｌ＿”　と、送信者の名前を格納する欄　”ｍａｉｌ＿Ｆｒｏｍ＿ｎａｍｅ”　と、送信者の電子メールアドレスを格納する欄　”ｍａｉｌ＿Ｆｒｏｍ＿ａｄｄｒｅｓｓ”　と、電子メール本文を格納する欄　”ｍａｉｌ＿ｂｏｄｙ”　の４つの欄が設けられる。”ｍａｉｌ＿ｂｏｄｙ”　欄を定義する要素　”ｃｏｌｕｍｎ”　の属性値　”ｏｐｔｉｏｎ”　には、文字列を連結した値を格納することを示す　”ＴＥＸＴ”　が指定されている。
【００４１】
図１１は、図９に示したＸＭＬ文書を、図１０に示したマッピング定義に基づいてテーブルにマッピングした例を示す。”ｍａｉｌ＿ｂｏｄｙ”　欄には、”ｂｒ”　タグと　”ｋｅｙｗｏｒｄ”　タグが取り除かれて連結された文字列が格納されている。このように、本実施の形態のデータベース管理システムによれば、データに演算を施して加工してから格納することができるので、ＸＭＬ文書の構造や内容、問い合わせの内容、ＲＤＢの特性などに応じて、データベースのテーブル設計を最適化することができる。
【００４２】
以上説明したように、本実施の形態のデータベース管理システム１０では、ＸＭＬ文書の階層構造を反映した形でリレーションの張られた複数のテーブルにデータをマッピングする。このとき、出現数の上限値が定まっている要素値、属性値については、新たにテーブルを設けることなく、その要素値または属性値を含む上位の要素に対応するテーブルに欄を設けて格納するので、テーブルのネストを最小限に抑え、記憶領域の使用効率および検索効率を向上させることができる。また、下位の要素を格納するテーブルにも、その要素を含む上位の要素のＩＤ番号を対応づけて格納するので、問い合わせの際に、上位のテーブルを参照しなくとも下位の要素のデータにアクセスすることができる。
【００４３】
つづいて、上記のような方法でマッピングされたデータに対して問い合わせを行う方法について説明する。本実施の形態では、クライアントから受け付ける問い合わせ文はＸＱｕｅｒｙ、ＲＤＢに対する問い合わせ文はＳＱＬにより記述される。
【００４４】
図１２は、サンプルデータのＸＭＬ文書のＤＴＤを示す。このＸＭＬ文書は、書籍の管理情報を格納するものである。ルート要素　”ｂｉｂ”　は、子要素として、０回以上出現する要素　”ｂｏｏｋ”を含む。要素　”ｂｏｏｋ”　は、必ず１回ずつ出現する要素　”ｔｉｔｌｅ”、任意の順序で１回以上出現する要素”ａｕｔｈｏｒ”　および　”ｅｄｉｔｏｒ”、必ず１回出現する要素　”ｐｕｂｌｉｓｈｅｒ”　および　”ｐｒｉｃｅ”　を含む。要素　”ａｕｔｈｏｒ”　は、必ず１回ずつ出現する要素　”ｌａｓｔ”　および　”ｆｉｒｓｔ”　をこの順序で含む。要素　”ｅｄｉｔｏｒ”　は、必ず１回ずつ出現する要素　”ｌａｓｔ”、”ｆｉｒｓｔ”　および　”ａｆｆｉｌｉａｔｉｏｎ”　をこの順序で含む。要素　”ｔｉｔｌｅ”　は文字データを含み、書籍のタイトルを格納する。要素　”ｌａｓｔ”　は文字データを含み、著者または編者の姓を格納する。要素　”ｆｉｒｓｔ”　は文字データを含み、著者または編者の名を格納する。要素　”ａｆｆｉｌｉａｔｉｏｎ”　は文字データを含み、編者の所属を格納する。要素　”ｐｕｂｌｉｓｈｅｒ”　は文字データを含み、書籍の出版社を格納する。要素　”ｐｒｉｃｅ”　は文字データを含み、書籍の価格を格納する。ここで、個々のＸＭＬファイルは　”ｂｏｏｋ”　をルート要素としており、”ｂｉｂ”　は複数のＸＭＬファイルをまとめて取り扱うために設けられている。
【００４５】
図１３は、サンプルデータのＸＭＬ文書を示す。実際には、＜ｂｏｏｋ＞〜＜／ｂｏｏｋ＞が一つのＸＭＬファイルに相当するため、４つのＸＭＬ文書が存在していることになる。それぞれのＸＭＬ文書には、書籍のタイトル、著者または編者の姓名、編者がいた場合はその所属、出版社、および価格が記述されている。
【００４６】
図１４は、図１３に示したＸＭＬ文書をテーブルにマッピングした例を示す。第１のテーブル　”ｔａｂｌｅ１”　には、ＸＭＬ文書のトップノード　”ｂｏｏｋ”　に割り当てられたＩＤ番号を格納する　”ｂｉｂ＿ｂｏｏｋ＿”　欄が設けられており、さらに、要素　”ｂｏｏｋ”　に対してそれぞれ１回ずつ出現する、属性値　”ｙｅａｒ”　と、要素　”ｔｉｔｌｅ”、”ｐｕｂｌｉｓｈｅｒ”、および　”ｐｒｉｃｅ”　の要素値を格納する欄が設けられている。第２のテーブル　”ｔａｂｌｅ２”　には、要素　”ｂｏｏｋ”　に対する出現回数が不定の要素　”ａｕｔｈｏｒ”　のＩＤ番号を格納する　”ｂｉｂ＿ｂｏｏｋ＿ａｕｔｈｏｒ＿”　欄が設けられ、さらに、要素　”ａｕｔｈｏｒ”　に対してそれぞれ１回ずつ出現する、要素　”ｌａｓｔ”　および　”ｆｉｒｓｔ”　の要素値を格納する欄が設けられている。第３のテーブル　”ｔａｂｌｅ３”　には、要素　”ｂｏｏｋ”　に対する出現回数が不定の要素　”ｅｄｉｔｏｒ”　のＩＤ番号を格納する　”ｂｉｂ＿ｂｏｏｋ＿ｅｄｉｔｏｒ＿”　欄が設けられ、さらに、要素　”ｅｄｉｔｏｒ”　に対してそれぞれ１回ずつ出現する要素　”ｌａｓｔ”、”ｆｉｒｓｔ”　および　”ａｆｆｉｌｉａｔｉｏｎ”　の要素値を格納する欄が設けられている。
【００４７】
図１５は、クライアントからＸＭＬ−ＲＤＢゲートウェイに送られる問い合わせ文の例を示す。この問い合わせ文は、ＸＱｕｅｒｙにより記述されており、出版社が「Ａ」である本のタイトルと出版社を取得することを目的とする。この問い合わせ文を受けた場合、通常は次のような処理が行われる。まず、ＦＯＲ句では、変数＄ｂに、ＸＭＬ文書中の要素　”ｂｏｏｋ”　がバインドされ、この例では４つのタプルが生成される。次に、ＷＨＥＲＥ句では、要素　”ｂｏｏｋ”　の直下の階層にある要素　”ｐｕｂｌｉｓｈｅｒ”　の要素値が「Ａ」であるタプルを抽出する。この例ではＩＤ番号が「１」および「２」の書籍が抽出される。最後に、ＲＥＴＵＲＮ句では、抽出されたタプルのうち、要素　”ｔｉｔｌｅ”　および　”ｐｕｂｌｉｓｈｅｒ”　の要素値を用いて、ＲＥＴＵＲＮ句に記述された構造のＸＭＬ文書を生成して問い合わせ結果とする。しかしながら、本実施の形態のデータベース管理システム１０では、ＸＭＬ文書をＲＤＢに格納して取り扱うので、ＸＭＬ−ＲＤＢゲートウェイ１００の解析部１２４は、このＸＱｕｅｒｙによる問い合わせ文を解析してＳＱＬ文に変換し、問い合わせ送信部１２６を介してＲＤＢ管理ユニット４０に送る。
【００４８】
図１６は、図１５に示した問い合わせ文をＳＱＬ文に変換した例を示す。解析部１２４は、まずＦＯＲ句およびＷＨＥＲＥ句で絞り込む部分をビューに当てはめ、そのビューを利用してＸＱｕｅｒｙ文のＲＥＴＵＲＮ句で必要となる内容を取得するという方針に沿ってＳＱＬ文を生成する。図１６に示した問い合わせ文を受けたＲＤＢ管理ユニット４０は、まず、”ｔａｂｌｅ１”　のテーブルから、”ｂｉｂ＿ｂｏｏｋ＿ｐｕｂｌｉｓｈｅｒ”　欄の値が「Ａ」に等しいレコードの　”ｂｉｂ＿ｂｏｏｋ＿”　欄の値を抽出してビュー　”ｂｏｏｋｌｉｓｔ”　を生成する。すなわち、条件を満たす書籍のＩＤ番号を絞り込む。つづいて、テーブル　”ｔａｂｌｅ１”　とビュー　”ｂｏｏｋｌｉｓｔ”　から、”ｂｉｂ＿ｂｏｏｋ＿”　欄の値が互いに等しいレコードの、”ｂｉｂ＿ｂｏｏｋ＿ｔｉｔｌｅ”　欄と　”ｂｉｂ＿ｂｏｏｋ＿ｐｕｂｌｉｓｈｅｒ”　欄の値を取得する。すなわち、絞り込んだレコードから目的のデータを取得する。ＲＤＢ管理ユニット４０は、この結果をＸＭＬ−ＲＤＢゲートウェイ１００に送信する。
【００４９】
図１７は、図１５に示した問い合わせ文に対する結果を記述したＸＭＬ文書の例を示す。問い合わせ結果取得部１３２によって取得された結果を用いて、文書整形部１３４は、ＲＥＴＵＲＮ句に記述された構造のＸＭＬ文書を整形する。この例では、要素　”ｂｏｏｋ”　の子要素として、条件に適合する書籍のタイトルを格納した要素　”ｔｉｔｌｅ”　と、出版社を格納した要素　”ｐｕｂｌｉｓｈｅｒ”　とが記述される。
【００５０】
以上のように、本実施の形態のデータベース管理システムによれば、大量のデータを扱うのに適したＲＤＢを利用しつつ、ユーザ側はＸＭＬ文書の問い合わせに適したＸＱｕｅｒｙにより問い合わせを発行することができる。これにより、ユーザはＲＤＢのテーブル構造などを知らなくても、ＸＭＬ文書の構造のみを知っていれば問い合わせを行うことが可能となる。また、ＸＭＬ文書が持つ階層構造などの特徴を最大限に生かしたデータの取り扱いが可能な環境が提供される。
【００５１】
本実施の形態では、前述したように、ＸＭＬデータをテーブルにマッピングする際に、要素の出現順序を示すＩＤ番号を格納する欄を設けている。出現順序を格納しておく意味を、たとえば、ＨＴＭＬ文書において、長い文章が複数のタグで分割されている場合を例にとって説明する。このデータをＲＤＢに格納するとき、通常、ＲＤＢでは、レコードを一意に識別するためのＩＤ番号は割り当てられているが、そもそもファイル中における出現順序を記録しておくという概念がない。しかしながら、複数の要素　”Ｐ”　に格納された文章の各段落の順序が保存されなければ、文章全体として意味をなさない。したがって、既存のＲＤＢは、データの順序が重要な意味を持つＸＭＬ文書を取り扱うのに適していないと言える。このような問題を考慮して、本実施の形態では、データを格納する際に、文書中における出現順序を明示的に記録する。これにより、文書の構造を適切に保存しつつ、文書に含まれるデータをＲＤＢで取り扱うことが可能となる。以下、文書内のデータの位置を含んだ問い合わせの例を示す。問い合わせの対象となるＸＭＬデータとして、図１２から図１４に示したサンプルデータを用いる。
【００５２】
図１８は、クライアントからＸＭＬ−ＲＤＢゲートウェイ１００に送られる問い合わせ文の例を示す。この問い合わせ文は、著者が２名以上いる本のタイトルと２番目の著者を取得することを目的とする。まず、ＦＯＲ句では、変数＄ｂに、ＸＭＬ文書中の要素　”ｂｏｏｋ”　がバインドされ、この例では４つのタプルが生成される。次に、ＬＥＴ句では、変数＄ａに、要素　”ｂｏｏｋ”　の直下の階層にある要素　”ａｕｔｈｏｒ”　のうち２番目の要素値がバインドされる。次に、ＷＨＥＲＥ句では、要素　”ａｕｔｈｏｒ”　の数が２以上存在するタプルを抽出する。この例ではＩＤ番号が「３」の書籍が抽出される。最後に、ＲＥＴＵＲＮ句では、抽出されたタプルのうち、要素　”ｔｉｔｌｅ”　および２番目に位置する要素　”ａｕｔｈｏｒ”　の要素値を用いて、ＲＥＴＵＲＮ句に記述された構造のＸＭＬ文書を生成して問い合わせ結果とする。
【００５３】
図１９は、図１８に示した問い合わせ文をＳＱＬ文に変換した例を示す。図１９に示した問い合わせ文を受けたＲＤＢ管理ユニット４０は、まず、”ｔａｂｌｅ１”　および　”ｔａｂｌｅ２”　のテーブルを用いて、１つの　”ｂｉｂ＿ｂｏｏｋ＿”　欄の値に２つ以上の　”ｂｉｂ＿ｂｏｏｋ＿ａｕｔｈｏｒ＿”　欄の値が対応している　”ｂｉｂ＿ｂｏｏｋ＿”　欄の値を抽出してビュー　”ｂｏｏｋｌｉｓｔ”　を生成する。つづいて、テーブル　”ｔａｂｌｅ１”、”ｔａｂｌｅ２”　とビュー　”ｂｏｏｋｌｉｓｔ”　から、”ｂｉｂ＿ｂｏｏｋ＿ａｕｔｈｏｒ＿”　欄の値が２に等しい、すなわち２番目の著者に対応する、”ｂｉｂ＿ｂｏｏｋ＿ｔｉｔｌｅ”　欄、　”ｂｉｂ＿ｂｏｏｋ＿ａｕｔｈｏｒ＿ｌａｓｔ”　欄、および”ｂｉｂ＿ｂｏｏｋ＿ａｕｔｈｏｒ＿ｆｉｒｓｔ”　の値を取得する。ＲＤＢ管理ユニット４０は、この結果をＸＭＬ−ＲＤＢゲートウェイ１００に送信する。
【００５４】
図２０は、図１８に示した問い合わせ文に対する結果を記述したＸＭＬ文書の例を示す。問い合わせ結果取得部１３２によって取得された結果を用いて、文書整形部１３４は、ＲＥＴＵＲＮ句に記述された構造のＸＭＬ文書を整形する。この例では、要素　”ｂｏｏｋ”　の子要素として、条件に適合する書籍のタイトルを格納した要素　”ｔｉｔｌｅ”　と、２番目の著者の姓名を格納した要素　”ａｕｔｈｏｒ”　とが記述される。
【００５５】
以上のように、本実施の形態のデータベース管理システムによれば、文書に含まれるデータの文書内における出現位置を適切に記録し、検索や検索結果の出力に利用することができる。上記の例では、出現位置を含んだ問い合わせの例を示したが、その他、検索結果を出現順序に基づいて並び替えたり、データの位置を入れ替えたりするなどの処理を行うことが可能である。
【００５６】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、各構成要素や各処理プロセスの組合せにいろいろな変形が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。以下、変形例を挙げる。
【００５７】
ＸＭＬ−ＲＤＢゲートウェイ１００を複数のサーバ装置の組合せで構成することによって処理負担を分散してもよい。たとえば、登録ユニットの機能と、問い合わせユニットの機能を、それぞれ異なるサーバ装置に担当させてもよい。
【００５８】
データベース登録部１１６は、ＸＭＬファイルのデータベースへの登録に先立って、そのＸＭＬファイルの正当性のチェックを行ってもよい。また、要素値または属性値の型チェックを行ってもよい。チェックの結果、不正なデータが発見された場合は、その旨を出力して登録をキャンセルしてもよい。
【００５９】
【発明の効果】
本発明によれば、大量のＸＭＬ文書を効率良く取り扱うことが可能なデータベースを提供することができる。また、ＸＭＬ文書の利点を最大限に生かしたデータベースの利用技術を提供することができる。
【図面の簡単な説明】
【図１】実施の形態に係るデータベース管理システムの全体構成を示す図である。
【図２】実施の形態に係るＸＭＬ−ＲＤＢゲートウェイの内部構成を示す図である。
【図３】データベースに格納すべきＸＭＬ文書のサンプルデータのＤＴＤを示す図である。
【図４】データベースに格納すべきＸＭＬ文書のサンプルデータを示す図である。
【図５】図４に示したＸＭＬ文書をマッピングしたテーブルの例を示す図である。
【図６】マッピング定義を記述するＸＭＬ文書のＤＴＤを示す図である。
【図７】図４に示したＸＭＬ文書をテーブルに展開するためのマッピング定義を示す図である。
【図８】サンプルデータのＸＭＬ文書のＤＴＤを示す図である。
【図９】サンプルデータのＸＭＬ文書を示す図である。
【図１０】図９に示したＸＭＬ文書のマッピング定義を示す図である。
【図１１】図９に示したＸＭＬ文書を、図１０に示したマッピング定義に基づいてテーブルにマッピングした例を示す図である。
【図１２】サンプルデータのＸＭＬ文書のＤＴＤを示す図である。
【図１３】サンプルデータのＸＭＬ文書を示す図である。
【図１４】図１３に示したＸＭＬ文書をテーブルにマッピングした例を示す図である。
【図１５】クライアントからＸＭＬ−ＲＤＢゲートウェイに送られる問い合わせ文の例を示す図である。
【図１６】図１５に示した問い合わせ文をＳＱＬ文に変換した例を示す図である。
【図１７】図１５に示した問い合わせ文に対する結果を記述したＸＭＬ文書の例を示す図である。
【図１８】クライアントからＸＭＬ−ＲＤＢゲートウェイに送られる問い合わせ文の例を示す図である。
【図１９】図１８に示した問い合わせ文をＳＱＬ文に変換した例を示す図である。
【図２０】図１８に示した問い合わせ文に対する結果を記述したＸＭＬ文書の例を示す図である。
【符号の説明】
１０　データベース管理システム、　２０　クライアント、　３０　ＷｅｂＤＡＶサーバ、　４０　ＲＤＢ管理ユニット、　５０　データストレージ、　１００　ＸＭＬ−ＲＤＢゲートウェイ、　１１０　登録ユニット、　１１２　ＸＭＬ文書入力部、　１１４　マッピング定義保持部、　１１６　データベース登録部、　１２０　問い合わせユニット、　１２２　問い合わせ受付部、　１２４　解析部、　１２６　問い合わせ送信部、　１３２　問い合わせ結果取得部、　１３４　文書整形部、　１３６　文書送信部。

Claims (8)

1. 構造化言語により記述された文書の入力を受け付ける入力部と、
   前記文書に含まれる要素値または属性値を、前記文書が有する階層構造を反映して設けられたテーブルにマッピングするための規則を保持する保持部と、
   前記規則を前記保持部から読み出して、その規則に基づいて前記要素値または属性値をテーブルにマッピングし、データベースに登録する登録部と、を備え、前記規則は、ある要素に含まれる要素値および属性値のうち、出現数の上限が定まっているものについては、その要素に対応する階層のテーブルに前記上限の数のフィールドを設けてそれらの値を格納するように定められたことを特徴とする文書管理装置。
2. 前記規則は、前記文書に含まれる要素値および属性値のうち、検索キーとして利用するものを抽出してテーブルにマッピングするように定められたことを特徴とする請求項１に記載の文書管理装置。
3. 前記テーブルは、前記要素値または属性値の前記文書中における出現順序を示す情報を格納するフィールドを含み、
   前記規則は、前記要素値または属性値と前記出現順序とを対応付けてテーブルに格納するように定められたことを特徴とする請求項１または２に記載の文書管理装置。
4. 前記登録部は、前記要素値または属性値に対して所定の演算を施した結果をテーブルに格納することを特徴とする請求項１から３のいずれかに記載の文書管理装置。
5. 下位の階層の要素に対応するテーブルに、その要素を含む上位の階層の要素の識別情報を格納するフィールドを設け、
   前記規則は、前記下位の階層の要素の要素値または属性値と、前記上位の階層の要素の識別情報とを対応付けて格納するように定められたことを特徴とする請求項１から４のいずれかに記載の文書管理装置。
6. 前記文書に対する問い合わせを行うための第１の問い合わせ言語により記述された第１の問い合わせ文を受け付ける問い合わせ受付部と、
   前記第１の問い合わせ文に記述された問い合わせを実行するために必要な処理を、前記データベースを管理する管理部に要求すべく、前記データベースに対する問い合わせを行うための第２の問い合わせ言語により記述された第２の問い合わせ文を生成する生成部と、
   前記第２の問い合わせ文を前記管理部に送る送信部と、
   前記管理部から前記第２の問い合わせ文に対する結果を受信する受信部と、
   前記結果に基づいて、前記第１の問い合わせ文に対する応答を生成する応答生成部と、
   前記応答を問い合わせ先に送信する応答送信部と、
   をさらに備えることを特徴とする請求項１から５のいずれかに記載の文書管理装置。
7. 構造化言語により記述された文書を受け付ける工程と、
   前記文書に含まれる要素値または属性値を、前記文書が有する階層構造を反映して設けられたテーブルにマッピングするための規則を予め取得して保持する工程と、
   前記規則に基づいて、前記要素値または属性値をテーブルにマッピングしてデータベースに登録する工程と、を含み、
   前記規則は、ある要素に含まれる要素値および属性値のうち、出現数が不定のものについては、その要素値または属性値を格納するための下位階層のテーブルを新たに設けて値を格納するように定められたことを特徴とする文書管理方法。
8. 構造化言語により記述された文書を受け付ける機能と、
   前記文書に含まれる要素値または属性値を、前記文書が有する階層構造を反映して設けられたテーブルにマッピングするとき、ある要素に含まれる要素値および属性値のうち、出現数の上限が定まっているものについては、その要素に対応する階層のテーブルに前記上限の数のフィールドを設けてそれらの値を格納する一方、出現数が不定のものについては、下位階層のテーブルにそれらの値を格納する機能と、
   をコンピュータに実現させることを特徴とするコンピュータプログラム。

Images