JP4289022B2 - 構造化文書処理方法及び装置及び構造化文書処理プログラム及び構造化文書処理プログラムを格納した記憶媒体 - Google Patents
構造化文書処理方法及び装置及び構造化文書処理プログラム及び構造化文書処理プログラムを格納した記憶媒体 Download PDFInfo
- Publication number
- JP4289022B2 JP4289022B2 JP2003145414A JP2003145414A JP4289022B2 JP 4289022 B2 JP4289022 B2 JP 4289022B2 JP 2003145414 A JP2003145414 A JP 2003145414A JP 2003145414 A JP2003145414 A JP 2003145414A JP 4289022 B2 JP4289022 B2 JP 4289022B2
- Authority
- JP
- Japan
- Prior art keywords
- structured document
- database
- statement
- stored
- xml
- 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.)
- Expired - Lifetime
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、構造化文書処理方法及び装置及び構造化文書処理プログラム及び構造化文書処理プログラムを格納した記憶媒体に係り、特に、データーベースを利用した構造化文書処理方法及び装置及び構造化文書処理プログラム及び構造化文書処理プログラムを格納した記憶媒体に関する。
【０００２】
【従来の技術】
ＸＭＬ（eXtensible Markup Language）は、ネットワーク上で交換される文書やデータの記述形式を規定するために、Ｗ３Ｃ(World Wide Web Consortium)が制定した規準規格である。ＸＭＬは、構造化文書の国際標準であるＳＧＭＬ(Standard Generalized Markup Language)の拡張可能性とＨＴＭＬ(HyperText Language)のインターネット利用性を併せ持った形式として期待されている。例えば、ＥＣ(Electronic Commerce)やＫＭ(Knowledge Management)で交換されるデータの記述や電子図書館の蔵書カタログの記述にもＸＭＬは利用できる。そして、このような利用例では、ＸＭＬの交換性という要件を超えて、大量のＸＭＬ文書を格納し、検索、更新できるという要件が重要になってくる。この要件を満たすためには、データーベース技術の適用・開発が必要となる。これには、大きく２つの方式がある。
【０００３】
（１）まず、１つの方式として、ネイティブＸＭＬデーターベースの開発がある。当該方式は、ＸＭＬ文書をそのまま格納し、検索、更新も可能なデーターベースを新たに開発する。Tamino（ソフトウェアＡＧ），eXcelon（エクセロン）、Yggdrasill（メディアフュージョン）などが挙げられる。
【０００４】
（２）２つ目の方式として、既存データーベースの機能拡張がある。既存のＲＤＢ（リレーショナルデーターベース）等に対し、ＸＭＬ文書を格納したり、取得したデータをＸＭＬ化する機能を拡張する。Oracle9i（オラクル）、ＳＱＬ Server2000（マイクロソフト）、ＤＢ２（ＩＢＭ）など主要なデーターベースはＸＭＬ対応となっている。
【０００５】
上記の（１）は、ＸＭＬ文書をそのまま扱えるのが大きな利点である。しかし、現在、ほとんどのデータがＲＤＢに格納されており、これら既存データとの連携、活用には（２）が適している。（２）でＸＭＬ文書の格納、検索、更新を行う場合、ＸＭＬ文書とＲＤＢとのマッピング方法が重要となる。ＸＭＬをＲＤＢにマッピングし、格納するには、大きく２つの方法がある。
【０００６】
ａ）ＸＭＬ文書全体を１カラムに格納する方法：
ＲＤＢのＣＬＯＢ（Character Large Object）やVarchar等のデータ型を利用することで、ＸＭＬ文書全体をそのまま１カラムに格納する。ＸＭＬ文書内のデータだけでなく、ＸＭＬ文書自体の文書構造を保持する場合に有効な方法である。例えば、新聞や雑誌の記事をアーカイブとして残す場合が当てはまる。この場合、指定された要素（日時や記者名等）のみ別カラムとし、インデックスを作成することで検索可能となる。
【０００７】
ｂ）ＸＭＬ文書をデータ項目に分解して複数カラムに格納する方法：
元となるＸＭＬ文書の要素や属性をデータ項目として分解し、ＲＤＢの複数のカラムに格納する。元のＸＭＬ文書自体は保存されないため、ＲＤＢ上に文書構造は保持されない。しかし、ＲＤＢ上のデータとして扱うため、当該データを複数のアプリケーションで共用する場合に有効な格納方法である。また、ＲＤＢからＸＭＬへのマッピング方法を決めておくことで、既存のＲＤＢに蓄積したデータをＸＭＬ文書として取得（出版）する（このような技術をＸＭＬ Publishingと呼ぶ）こともできる。
【０００８】
これらの格納方法をＸＭＬ−ＲＤＢ間のマッピング定義情報により実現する技術も開発されている（例えば、非特許文献１参照）。
【０００９】
【非特許文献１】
IBM,DB2XMLExtender:http://www-6.ibm.com/jp/sofuware/data/developer/colum/kantanextend/05xmlextender/01/html
【００１０】
【発明が解決しようとする課題】
しかし、格納方法をＸＭＬ−ＲＤＢ間のマッピング定義情報により実現する技術では、不十分な点も多い。
【００１１】
（１） ＸＭＬに対する標準的な問い合わせで検索，追加、更新することが困難であるという問題（機能的要件）： Ｗ３Ｃによって開発が進められている標準的な検索言語XQuery(http:///www.w3.org/TR/xquery/)では、検索結果ＸＭＬの構造を再構成、変換するといった柔軟な記述が可能となっている。また、追加、更新に関してもXupdate(http://www.xmldb.org/xupdate/)というＸＭＬに対応した言語が提案されている。しかし、従来の方法では、格納されたデータは、ＲＤＢ上のデータとして扱われる。そして、検索、追加、更新に用いられるクエリは、一般的にＸＭＬ拡張したＳＱＬが用いられる。また、ＸＭＬPublishingにおける、ＲＤＢからＸＭＬへのマッピングも固定的である。つまり、従来の方法では、格納されたデータをＲＤＢ上のデータとして扱うため、ＸＭＬに対する標準的なクエリで検索、追加、更新することが困難である。
【００１２】
（２） 検索の高速性と追加、更新の高速性を両立することが困難（性能的要件）： 一般的に、ＸＭＬ文書全体を検索、取得するだけなら、上記従来のａ）がｂ）に比べて高速である。一方、ＸＭＬ文書中の要素の追加、更新頻度が高い場合、ｂ）がａ）に比べて高速である。そして、ＸＭＬ文書の利用形態によっては、検索の高速性と追加、更新の高速性の両方が求められる場合がある。つまり、応用によってはこれらの格納方法を組み合わせることが必要となる。しかし、従来のＸＭＬ−ＲＤＢ間のマッピング定義情報では、ａ）とｂ）の２つの格納方法を柔軟に組み合わせて、検索の高速性と追加、更新の高速性を両立させることが困難である。
【００１３】
本発明は、上記の点に鑑みなされたもので、ＸＭＬ文書を、当該ＸＭＬ文書の階層構造に基づき、重複を許した部分ＸＭＬ文書に分割してＲＤＢと対応付けるマッピング定義情報及び当該定義に則って、入力されたＸＭＬに対する標準的な問い合わせをＳＱＬへ変換することにより、検索の高速性と追加、更新の高速性の両立を実現するデーターベースを利用した構造化文書処理方法及び装置及び構造化文書処理プログラム及び構造化文書処理プログラムを格納した記憶媒体を提供することを目的とする。
【００１４】
【課題を解決するための手段】
図１は、本発明の原理を説明するための図である。
【００１５】
本発明は、データベースを利用して構造化文書の格納、検索、更新及び削除の操作を行う構造化文書処理方法において、
入力された構造化文書に対する問い合わせを解析し、該問い合わせの要求している操作が挿入か、更新か、削除か、検索かを判定する操作判定ステップ（ステップ１）と、
記憶手段に格納されている、構造化文書の階層構造に基づいて、分割した部分文書同士の重複を許して、構造化文書を部分文書に分割してデータベースと対応付けるマッピング定義情報を参照して、操作判定ステップの判定に基づいて、入力された問い合わせを、該データベースに対し、挿入／更新／削除／検索のいずれかの操作を行う命令文に変換する命令文生成ステップ（ステップ２）と、
変換された命令文をデータベースに送信し、操作を実行させる操作指示ステップ（ステップ３）と、
命令文が挿入／更新／削除操作のいずれかであれば、該命令文を実行した文書件数を取得する文書件数取得ステップ（ステップ４）と、
命令文が検索操作であれば、マッピング定義情報を参照して、データベースの検索結果を構造化文書として出力する構造化文書出力ステップ（ステップ５）と、を行う。
【００２３】
図２は、本発明の原理構成図である。
【００２４】
本発明（請求項１）は、データベースを利用して構造化文書の格納、検索、更新及び削除の操作を行う構造化文書処理装置であって、
入力された構造化文書に対する問い合わせを解析し、該問い合わせの要求している操作が挿入か、更新か、削除か、検索かを判定する操作判定手段１２０と、
記憶手段に格納されている前記構造化文書全体、及び、該構造化文書の階層構造に基づいて分割される当該構造化文書の一部をデータベース３００と対応付けるマッピング定義情報１７０と、
マッピング定義情報１７０を参照して、操作判定手段の判定に基づいて、入力された問い合わせを、データベース３００に対し、挿入／更新／削除／検索のいずれかの操作を行う命令文に変換する命令文生成手段１３０と、
変換された命令文をデータベース３００に送信し、操作を実行させる操作指示手段１４０と、
命令文が挿入／更新／削除操作のいずれかであれば、該命令文を実行した文書件数を取得する文書件数取得手段１５０と、
命令文が検索操作であれば、マッピング定義情報１７０を参照して、データベース３００の検索結果を構造化文書として出力する構造化文書出力手段１６０と、を備え、
命令文生成手段１３０は、
挿入／更新操作用の構造化文書の構造が正当かを判定する手段と、
構造化文書全体を挿入する問い合わせか、あるいは、既に格納されている構造化文書に対し、構造化文書の一部を挿入または構造化文書の全体を更新または構造化文書の一部を更新する問い合わせかを判定する手段と、
構造化文書の一部を挿入または構造化文書の全体を更新または構造化文書の一部を更新する問い合わせであれば、マッピング定義情報を参照して、該構造化文書の一部に対応する要素の先祖要素がデータベース３００に格納されているかを判定する手段と、
先祖要素が、データベース３００に格納されていれば、該先祖要素の更新を行うための命令文を生成する更新命令生成手段と、
マッピング定義情報１７０を参照して、構造化文書の一部に対応する要素の子孫要素がデータベース３００に格納されているかを判定する手段と、
子孫要素がデータベース３００に格納されていれば、該子孫要素の更新を行うための命令文を生成する子孫要素更新命令生成手段と、を含む。
【００２５】
本発明（請求項２）は、データベースを利用して構造化文書の格納、検索、更新及び削除の操作を行う構造化文書処理装置であって、
入力された構造化文書に対する問い合わせを解析し、該問い合わせの要求している操作が挿入か、更新か、削除か、検索かを判定する操作判定手段１２０と、
記憶手段に格納されている構造化文書全体、及び、該構造化文書の階層構造に基づいて分割される当該構造化文書の一部をデータベース３００と対応付けるマッピング定義情報１７０と、
マッピング定義情報１７０を参照して、操作判定手段の判定に基づいて、入力された問い合わせを、該データベース３００に対し、挿入／更新／削除／検索のいずれかの操作を行う命令文に変換する命令文生成手段１３０と、
変換された命令文をデータベース３００に送信し、操作を実行させる操作指示手段１４０と、
命令文が挿入／更新／削除操作のいずれかであれば、該命令文を実行した文書件数を取得する文書件数取得手段１５０と、
命令文が検索操作であれば、マッピング提示情報１７０を参照して、データベース３００の検索結果を構造化文書として出力する構造化文書出力手段１６０と、を備え、
命令文生成手段１３０は、
マッピング定義情報１７０を参照して、構造化文書の一部に対応する要素の先祖要素がデータベースに格納されているかを判定する手段と、
先祖要素がデータベース３００に格納されていれば、該先祖要素から対応要素までの更新を行うための命令文を生成する更新命令生成手段と、
マッピング定義情報１７０を参照して、構造化文書の一部に対応する要素の子孫要素がデータベースに格納されているかを判定する手段と、
子孫要素がデータベース３００に格納されていれば、該子孫要素の更新を行うための命令文を生成する子孫要素更新命令生成手段と、を含む。
【００２６】
また、本発明（請求項３）は、上記の命令文生成手段１３０において、
挿入／更新操作用の構造化文書の構造が正当かを判定する手段と、
構造化文書全体を挿入する問い合わせか否かを判定する手段と、
構造化文書全体を挿入する問い合わせであれば、同一の構造を持った複数の構造化文書を識別するための識別子を払い出し、マッピング定義情報１７０を参照して、データベースに対し挿入を行う命令文へと変換する手段を含む。
【００２９】
また、本発明（請求項４）は、上記の更新命令生成手段において、
更新対象のデータを取得するための命令文を生成、実行する手段と、
取得した更新対象のデータを更新する手段と、
更新したデータを再度、挿入するための命令文を生成する手段と、
データベースに格納されている先祖要素について問い合わせで指定した要素まで、上記の各手段を制御して各手段による処理を繰り返させる制御手段と、を含む。
【００３０】
また、本発明（請求項５）は、上記の子孫要素更新命令生成手段において、
マッピング定義情報１７０を参照して、更新対象の同一要素のデータがデータベース３００上で複数行に別々に格納されているのか、一行にまとめて格納されているのかを判定する手段と、
複数行に別々に格納されている場合、データを一旦削除する命令文を生成、実行し、既に更新済みの先祖要素を格納しているデータを元に、該データを再度挿入するための命令文を該データを格納している全子孫要素について生成する手段と、
一行にまとめて格納されている場合に、更新対象のデータを取得するための命令文を生成、実行する手段と、
取得した更新対象のデータを更新する手段と、
更新したデータを再度、挿入するための命令文を生成する手段と、
データベースに格納されている子孫要素について問い合わせで指定した要素まで、上記の各手段を制御して各手段による処理を繰り返させる制御手段と、を含む。
【００３１】
また、本発明（請求項６）は、上記の命令文生成手段１３０において、
マッピング定義情報１７０を参照して、問い合わせに含まれる問い合わせ結果指定部分に対応する要素がそのまま前記データベースに格納されているか否かを判定する手段と、
そのままデータベースに格納されていれば、その所在を取得する手段と、
そのままデータベースに格納されていなければ、検索結果が出現するまで、問い合わせに含まれる問い合わせ結果指定部分に対応する要素の子孫要素を辿りその所在を取得する手段と、
取得した所在と、入力された問い合わせから検索のための命令文を生成する手段と、を含む。
【００３２】
本発明（請求項７）は、請求項１乃至２のいずれか１項に記載の構造化文書処理装置を構成する各手段としてコンピュータを機能させるための構造化文書処理プログラムである。
【００３３】
本発明（請求項８）は、請求項７に記載のプログラムを格納した記憶媒体である。
【００３４】
上記のように、本発明は、入力されたＸＭＬに対する標準的な問い合わせを解析し、当該問い合わせの要求している操作が挿入か、更新か、削除か、検索かを判定し、ＸＭＬ−ＲＤＢ間のマッピング定義情報（ＸＭＬ文書の階層構造に基づき、重複を許したＸＭＬ文書に分割して、ＲＤＢと対応付けるマッピング定義情報）に則って、入力された問い合わせをＳＱＬをＲＤＢ上で実行し、挿入／更新／削除であれば、当該操作を実行した文書件数を取得し、検索であれば、ＸＭＬ−ＲＤＢ間のマッピング定義情報を参照し、ＲＤＢの検索結果をＸＭＬ文書として出力するものである。ＸＭＬに対する標準的な問い合わせを解析し、ＸＭＬ−ＲＤＢ間のマッピング定義情報を参照することで、当該問い合わせを用いたＲＤＢへのＸＭＬ文書の挿入、更新、削除、検索が可能となる。また、当該マッピング定義情報は、ＸＭＬ文書の階層構造に基づき、重複を許して部分ＸＭＬ文書に分割して、ＲＤＢと対応付けることで、検索の高速性と追加、更新の高速性を両立することができる。
【００３５】
【発明の実施の形態】
以下、図面と共に本発明の実施の形態を説明する。
【００３６】
図３は、本発明の一実施の形態における構造化文書処理装置の構成を示す。
【００３７】
構造化文書処理装置１００は、アプリケーションプログラムインタフェース部１１０と、ＸＭＬ問い合わせ文解析部１２０、ＲＤＢ−ＸＭＬマッピング定義情報１７０、ＳＱＬ文生成部１３０、ＲＤＢ管理システムインタフェース部１４０、ＤＯＭ操作部１５０、問い合わせ結果生成部１６０から構成される。
【００３８】
アプリケーションプログラムインタフェース部１１０は、アプリケーションプログラムと通信網４００とを介してユーザから入力されたＸＭＬ問い合わせ文を受け付ける。ＸＭＬ問い合わせ文は、変数バインド部分、問い合わせ条件指定部分、問い合わせ結果指定部分から構成される。
【００３９】
ＸＭＬ問い合わせ解析部１２０は、アプリケーションプログラムインタフェース部１１０が受け付けたＸＭＬ問い合わせ文の構文を解析し、ＸＭＬ問い合わせ文解析情報を出力する。
【００４０】
図４は、本発明の一実施の形態におけるＲＤＢ−ＸＭＬマッピング定義情報に含まれる情報の概要を示す。ＲＤＢ−ＸＭＬマッピング定義情報１７０には、ＲＤＢにアクセスするための情報１７１と、ＳＱＬ−ＤＤＬを生成するために必要なテーブル生成情報１７２と、ＸＭＬ文書の情報とＲＤＢに格納された情報との対応関係をマッピングするためのルート情報１７３が含まれる。なお、当該ＲＤＢ−ＸＭＬマッピング定義情報１７０は、ハードディスク装置等の記憶媒体に格納される。
【００４１】
ＳＱＬ文生成部１３０では、ＸＭＬ問い合わせ文解析情報とＲＤＢ−ＸＭＬマッピング定義情報からＳＱＬ文を生成し、ＲＤＢ管理システムインタフェース部１４０と通信網４００を介してＲＤＢ管理システム３００に送信する。そして、ＳＱＬ結果をＲＤＢ管理システム３００から取得する。ＲＤＢ管理システムインタフェース部１４０は、生成したＳＱＬ文の受け付け、ＲＤＢ管理システム３００への接続、ＳＱＬ結果の取得を行う。
【００４２】
ＤＯＭ操作部１５０は、問い合わせ結果指定部分の先祖／子孫要素がＲＤＢに格納されている際、当該要素を取得し、ＤＯＭ（Document Object Model:XML操作のための標準ＡＰＩの１つ）に展開した後、ＤＯＭ操作により、問い合わせ結果指定部分に対し更新を行う。
【００４３】
問い合わせ結果生成部１６０では、取得したＳＱＬ結果と読み出したＲＤＢ−ＸＭＬマッピング定義情報から問い合わせ結果を生成する。問い合わせ結果とは、挿入・更新・削除の場合は操作を実行したＸＭＬ文書件数であり、検索の場合は、返却されるＸＭＬ文書を指す。
【００４４】
次に、本発明の構造化文書処理装置１００の処理手順の概要について説明する。
【００４５】
図５は、本発明の一実施の形態における構造化文書処理装置の全体の概要動作のフローチャートである。
【００４６】
構造化文書処理装置１００は、準備フェーズ（ステップ１０００）と操作フェーズ（ステップ２０００）の順で処理が行われる。準備フェーズ（ステップ１０００）では、ＲＤＢ−ＸＭＬマッピング定義情報１７０中のテーブル生成情報を元にＳＱＬ−ＤＤＬを出力し、ＲＤＢ上にテーブルを生成する。操作フェーズ（ステップ２０００）では、生成されたテーブルに対し、ＸＭＬ文書の挿入・更新・削除・検索を行う。
【００４７】
図６は、本発明の一実施の形態における準備フェーズのフローチャートである。
【００４８】
準備フェーズでは、まず、ＲＤＢ−ＸＭＬマッピング定義情報を作成し、記憶手段に格納する（ステップ１０１０）。ＳＱＬ文生成部１３０では、当該ＲＤＢ−ＸＭＬマッピング定義情報１７０中のテーブル生成情報を元に、ＳＱＬ−ＤＤＬを出力する（ステップ１０２０）。ＲＤＢ管理システムインタフェース部１４０では、当該ＲＤＢ−ＸＭＬマッピング定義情報１７０中のＲＤＢアクセス情報を元に、ＲＤＢ管理システム３００へ接続し、ＳＱＬ−ＤＤＬをＲＤＢ管理システム３００へ送信する（ステップ１０３０）。ＲＤＢ管理システム３００では、送信されたＳＱＬ−ＤＤＬに基づいてテーブルを生成する（ステップ１０４０）。
【００４９】
図７〜図９は、本発明の一実施の形態における操作フェーズのフローチャートである。
【００５０】
操作フェーズでは、まず、アプリケーションプログラムインタフェース部１１０が、アプリケーションプログラム２００を介して入力されたＸＭＬ問い合わせ文を受理する（ステップ２０１０）。問い合わせは、図３に示すように、変数バインド部分、問い合わせ条件指定部分、問い合わせ結果指定部分から構成される。
【００５１】
ＸＭＬ問い合わせ文解析部１２０は、ＸＭＬ問い合わせ文を解析し、ＸＭＬ問い合わせ文解析情報を出力する（ステップ２０２０）。このＸＭＬ問い合わせ文解析情報から、受理したＸＭＬ問い合わせ文が検索操作を行うため構文か否かを判定する（ステップ２０３０）。同様に、挿入／更新操作を行うための構文か削除操作を行う構文かを判定する（ステップ２０３１）。
【００５２】
挿入／更新操作を行うための構文であれば、挿入／更新用ＸＭＬ文書の構造が正当かを判定する（ステップ２０４０）。正当でなければエラーを出力して操作フェーズを終了する。正当であれば、全ＸＭＬ文書の挿入を行うための構文かを判定する（ステップ２０４１）。全ＸＭＬ文書の挿入を行うための構文であれば、１つ１つのＸＭＬ文書を識別するための文書キーを払い出し（ステップ２０４２）、ＳＱＬ文生成部１３０は、ＲＤＢ−ＸＭＬマッピング定義情報１７０とＸＭＬ問い合わせ文解析情報を参照し、全ＸＭＬ文書挿入用ＳＱＬを生成する（ステップ２０４３）。生成したＳＱＬ文をＲＤＢ管理システム３００で実行し（ステップ２０４４）、挿入を実行した文書件数を取得し（ステップ２０７０）、これを問い合わせ結果として出力する（ステップ２０８７）。
【００５３】
全ＸＭＬ文書の挿入を行うための構文でなければ（ステップ２０４１）、部分ＸＭＬ文書の挿入あるいは、全／部分ＸＭＬ文書の更新を行う構文である。以降の処理は、部分ＸＭＬ文書挿入／更新／削除で同一となる。まず、問い合わせ結果指定部分に対応する要素の先祖要素がＲＤＢに格納されているかを判定する（ステップ２０５０）。格納されていれば、ＳＱＬ文生成部１３０は、ＲＤＢ−ＸＭＬマッピング定義情報１７０とＸＭＬ問い合わせ文解析情報を参照し、テーブル名とカラム名を取得し、更新対象データ取得用ＳＱＬを生成する（ステップ２０５１）。生成したＳＱＬを実行し、更新対象データを取得する（ステップ２０５２）。
【００５４】
ＤＯＭ操作部１５０は、取得したデータをＤＯＭ(Document Object Model:XML操作のための標準ＡＰＩの一つ)に展開した後、ＤＯＭ操作により、問い合わせ結果指定部分に対し更新を行い、再び、ＸＭＬ化する（ステップ２０５３）。ＳＱＬ文生成部１３０は、挿入用ＳＱＬを生成し、更新を行ったＸＭＬをデーターベースに再挿入する（ステップ２０５４）。ステップ２０５１からステップ２０５４までを問い合わせ結果指定部分で指定された要素まで繰り返す。
【００５５】
次に、問い合わせ結果指定部分に対応する要素の子孫要素がＲＤＢに格納されているかを判定する（ステップ２０６０）。格納されていれば、同一パスのＮ個の要素がＮ行に別々に格納されているのか、１行にまとめて格納されているのかを判定する（ステップ２０６１）。１行にまとめて格納されている場合、先程のステップ２０５１からステップ２０５４と同様に、更新対象データを取得し、ＤＯＭ展開し、更新を行い、ＸＭＬ化してデーターベースに再挿入する（ステップ２０６４からステップ２０６７）。Ｎ行に別々に格納されている場合、先祖要素の更新時に取得した文書キーでデータ削除用ＳＱＬを生成し、実行（ステップ２０６２）した後、既に更新済みの先祖要素を格納している列のデータを元にデータ挿入用ＳＱＬを生成し、実行する（ステップ２０６３）。
【００５６】
ステップ２０６０からステップ２０６６までをＲＤＢに格納されているすべての子孫要素に対して行う。部分ＸＭＬ文書挿入／更新／削除を実行した文書件数を取得し（ステップ２０７０）、これを問い合わせ結果として出力する（ステップ２０８７）。
【００５７】
検索操作を行うための構文であれば（ステップ２０３０）、ＲＤＢ−ＸＭＬマッピング定義情報１７０を参照して、問い合わせ結果指定部分に対応する要素がＲＤＢに格納されているかを判定する（ステップ２０８０）。格納されていれば、当該要素が格納されているＲＤＢのテーブル名、カラム名を取得する（ステップ２０８３）。格納されていない場合、格納されている要素が出現するまで、当該要素の子孫要素を辿り、格納されているＲＤＢのテーブル名、カラム名を取得する（ステップ２０８２）。これを全ての子孫要素に対して繰り返し、全てのテーブル名、カラム名を取得する（ステップ２０８１）。
【００５８】
取得したテーブル名、カラム名と問い合わせ条件指定部分から得られた解析情報を元にＳＱＬを生成／実行する（ステップ２０８４）。ＲＤＢ−ＸＭＬマッピング定義情報１７０を参照して、問い合わせ結果指定部分に対応する要素がＲＤＢに格納されているかを判定することで、ＸＭＬ再構築が必要かを判定する（ステップ２０８５）。必要であればＲＤＢ−ＸＭＬマッピング定義情報１７０を参照して、ＳＱＬの検索結果からＸＭＬ文書を問い合わせ結果として生成し（ステップ２０８６）、出力する（ステップ２０８７）。再構築が必要でない場合は、該当する要素がＲＤＢに格納されているので、それを問い合わせ結果として出力する（ステップ２０８７）。
【００５９】
【実施例】
以下、図面と共に本発明の実施例を説明する。
【００６０】
最初に、準備フェーズについて説明する。
【００６１】
（１）テーブル生成（準備フェーズ）：
図１０は、本発明の一実施例のＲＤＢ−ＸＭＬマッピング定義情報の詳細を示す図である。図１１は、本発明の一実施例のＲＤＢアクセス情報と記述例を示す。図１２は、本発明の一実施例のテーブル生成情報と記述例を示す。図１３〜図１５は、本発明の一実施例のルート情報と記述例を示す。
ＲＤＢ−ＸＭＬマッピング定義情報１７０は、ＸＭＬ形式で規定された定義であり、図４に示したように、ＲＤＢアクセス情報１７１（図１１）、テーブル生成情報１７２（図１２），ルート情報１７３（図１３〜図１５）が含まれる。
【００６２】
（２）ＲＤＢ−ＸＭＬマッピング定義情報（図１０）：
ＲＤＢ−ＸＭＬマッピング定義情報１７０のルート要素である。Target属性により対象のＲＤＢ管理システム種別を定義する。version属性の値により、ＲＤＢ−ＸＭＬマッピング定義情報１７０の識別を行う。
【００６３】
（３）ＲＤＢアクセス情報（図１１）：
ＲＤＢの接続先毎の情報を定義する要素である。
【００６４】
・access要素
ＲＤＢ管理システムインタフェース部１４０を経由してＲＤＢに接続するための情報を定義する要素である。接続時に必要な接続先urlをｕｒｌ要素へ、接続時に必要なユーザ名やパスワードをproperty要素に定義する。
【００６５】
（ａ）url要素
ＲＤＢ管理システムインタフェース部１４０を経由してＲＤＢに接続する際に指定するＵＲＬを定義する要素である。
【００６６】
（ｂ）property要素
ＲＤＢ管理システムインタフェース部１４０を経由してＲＤＢに接続する際に指定するプロパティ情報（ユーザ名、パスワード等）を指定する要素である。name属性によりプロパティ名を定義する。
【００６７】
（２）テーブル生成情報（図１１）
ＳＱＬ文生成部１３０にて、ＲＤＢのテーブル生成用ＳＱＬ−ＤＤＬを生成するために必要な情報を定義する。
【００６８】
（ａ）table要素
個々のテーブルに対する情報を定義する。name属性に対し、テーブル名を記述する。
【００６９】
（ｂ）column要素
親要素のtable要素のname属性に指定したテーブルに持たせるカラムの情報を定義する。name属性に対し、カラム名を記述し、type属性に対し、ＲＤＢで定義されるデータ型を記述する。
【００７０】
（ｃ）constraint要素
親要素がtable要素の場合、表定義としての制約をＳＱＬと同じ形式で記述する。また、親要素がcolumn要素の場合は行定義としての制約をＳＱＬと同じ形式で記述する。
【００７１】
（ｄ） charactoristics要素
親要素のtable要素で指定されるテーブルに対しての物理特性やテーブル特性を定義する。ＳＱＬのCREATE文におけるphisical_propertis及びtable_propertiesに相当する部分をＳＱＬと同じ形式で記述する。
【００７２】
図１２にテーブル生成の記述例を示す。
【００７３】
（３）ルート情報（図１３）
入出力されるＸＭＬ文書とＲＤＢ内に格納されているデータとの関連をマッピングするための情報を定義する。element情報、attribute要素、text要素は、それぞれ元ＸＭＬ文書の要素，属性，テキストに相当し、元ＸＭＬと同じ階層構造について記述する。
【００７４】
ルート情報に定義する項目を図１５に示す。
【００７５】
（ａ）element要素
ＸＭＬ文書の要素に対応する要素である。各種属性にてＲＤＢとのマッチング情報を定義する。各属性の内容を以下に示す。
【００７６】
・name属性
ＸＭＬ文書の要素名を定義する。
【００７７】
・table属性
格納先のテーブル名を定義する。なお、すべての要素に定義されるわけではなく、定義は子孫の要素に次のtable属性が定義されるまでを有効範囲とする。
【００７８】
・column属性
格納先のカラム名を定義する。対象のテーブルは、上記のテーブル属性で定義された対象の(ansector-or-selfの内で直近のtable属性に定義された)テーブルとなり、対応するＸＭＬのデータの格納先が特定される。
【００７９】
・ratio属性
本属性は、table属性に付随して定義され、ｎ個の要素が存在する場合に、複数の格納先テーブル間の関係を定義する。
【００８０】
“１：１”の場合、本属性を持つ１もしくはｎ個の要素を１タプルに格納する。
【００８１】
“１：ｎ”もしくは“１：Ｎ”の場合、本属性を持つ１つもしくは、Ｎ個の要素をＮタプルに格納する。
【００８２】
なお、本属性が省略された場合“１：１”として扱う。
【００８３】
・minOccurs属性
本属性の定義された要素が持つことのできる要素の最小数を“０”か“１”で定義する。
【００８４】
・maxOccurs属性
本属性の定義された要素が持つことのできる要素の最大数を“１”か“unbounded”(制限なし)で定義する。
【００８５】
・docID属性
ＸＭＬ文書を識別するための文書IDに該当する要素に対し、本属性に“yes”を定義する。
【００８６】
・type属性
本属性は、column属性に付随して定義され、格納先のカラムのデータ型を定義する。ＸＭＬデータ格納の際に参照され、入力のデータとデータがたの整合性を判断する。
【００８７】
・size属性
本属性は、column属性に付随して定義され、格納先のカラムのサイズを定義する。ＸＭＬデータ格納の際に参照され、入力のデータのサイズが格納可能かを判断する。
【００８８】
・pkey属性
本属性は、table属性に付随して定義され、table属性に定義されたテーブルの主キーとなるカラム名を定義する。省略された場合は、DocKey（文書キー）を主キーと見做す。
【００８９】
・parent-fkey属性
本属性は、table属性に付随して定義され、該当のテーブルの主キーに対しての外部キーとなるカラム名を定義する。本属性で指定した列は、直近の先祖要素に定義されているテーブルの列として定義されるものとする。
【００９０】
・exts属性
拡張機能であるユーザ定義関数名を記述する。本属性を定義することによりユーザ定義関数と本属性が定義されたパスとの関連付けを定義する。
【００９１】
（ｂ）attribute要素
ＸＭＬ文書の属性に対応する要素である。各種属性にてデーターベースとのマッピング情報を定義する。属性は、element要素と同じ属性をもつが、その他にattribute要素固有の属性としてmeta属性を持つ。
【００９２】
・meta属性
追加属性を識別するための属性である。本属性に“yes”が指定された要素を追加属性と見做す。ＸＭＬ問い合わせ文で操作する場合は、直接本属性が定義された要素を問い合わせ結果指定部分(do節/return節)に指定しない限り、操作を行えないものとする。直接指定せずに操作を行おうとした場合、更新時には例外、検索時には、検索対象外とする。
【００９３】
（ｃ）text属性
ＸＭＬ文書の属性に対応する要素である。各種属性にてＲＤＢとのマッピング情報を定義する。属性は、element要素と同じ属性を持つ。
【００９４】
上記の項目を用いたＸＭＬ文書例、ルート情報の記述例を図１５に示す。本発明のＸＭＬ−ＲＤＢ間のマッピング定義情報１７０（ルート情報）は、ＸＭＬ文書を部分ＸＭＬ文書に分割してＲＤＢへ格納する。分割は、階層的に行い、重複も許している。図１６には、この格納の重複関係を階層構造（格納構造木）で示している。
【００９５】
準備フェーズでは、まず、ＲＤＢアクセス情報１７１（図１１）、テーブル生成情報１７２（図１２）、ルート情報１７３（図１３〜図１５）を含むＲＤＢ−ＸＭＬマッピング定義情報１７０（図１０）を作成する（ステップ１０１０）。ＳＱＬ文生成部１３０では、当該ＲＤＢ−ＸＭＬマッピング定義情報１７０中のテーブル生成情報（図１２）を元に、ＳＱＬ−ＤＤＬを出力する（ステップ１０２０）。ＲＤＢ管理システムインタフェース部１４０では、当該ＲＤＢ−ＸＭＬマッピング定義情報１７０中のＲＤＢアクセス情報（図１１）を元に、ＲＤＢ管理システム３００へ接続し、ＳＱＬ−ＤＤＬをＲＤＢ管理システム３００へ送信する（ステップ１０３０）。
【００９６】
ＲＤＢ管理システム３００では、送信されたＳＱＬ−ＤＤＬに基づいてテーブルを生成する（ステップ１０４０）。ＳＱＬ−ＤＤＬの出力例及びテーブルの生成例を図１６に示す。
【００９７】
次に、操作フェーズについて説明する。
【００９８】
（１） ＸＭＬ文書挿入（操作フェーズ）
入力されたＸＭＬ問い合わせ文を元にＲＤＢ−ＸＭＬマッピング定義情報１７０を参照して、ＲＤＢに対して全ＸＭＬ文書または、部分ＸＭＬ文書の挿入を行う。図１７（ａ），（ｂ）に示す問い合わせがアプリケーションプログラム２００から発行された場合を例に具体的に説明する。
【００９９】
まず、問い合わせを受理し（図７、ステップ２０１０）、ＸＭＬ問い合わせ文解析部１２０は、ＸＭＬ問い合わせ文を解析し、ＸＭＬ問い合わせ文解析情報を出力する（図７、ステップ２０２０）。挿入／更新／削除のＸＭＬ問い合わせ文は、ＸＭＬUpdate、検索のＸＭＬ問い合わせ文は、ＸQueryの構文に基づいている。
【０１００】
ＸＭＬ問い合わせ解析情報から問い合わせ結果指定部分がｄｏ節なので検索操作を行う構文ではなく（図７、ステップ２０３０）、また、append関数が指定されているので挿入操作を行う構文と判定される（図７、ステップ２０３１）。ＸＭＬ−ＲＤＢマッピング定義情報１７０のルート情報を元に挿入用ＸＭＬ文書構造のチェックを行う（図８、ステップ２０４０）。変数バインド部分のfor節からroot関数の引数であるroot名を取得し、ＸＭＬ−ＲＤＢマッピング定義情報１７０の該当するroot名を持つroot要素を特定する。また、for節に指定するバインド位置で、全ＸＭＬ文書挿入であるか部分ＸＭＬ文書挿入であるかを判定する。バインド指定でパスが指定されていない場合は、全ＸＭＬ文書挿入とみなし、ルート要素が指定されていた場合、部分ＸＭＬ文挿入とみなす（図８、ステップ２０４１）。これは、本実施例でぇあ、図１７（ｃ）に示す格納モデルを想定しているためである。
【０１０１】
全ＸＭＬ文書挿入であれば（図１７（ｂ））、文書キーを払い出し（図８、ステプ２０４２）、ＳＱＬ文生成部１３０は、ＲＤＢ−ＸＭＬマッピング定義情報１７０とＸＭＬ問い合わせ文解析情報を参照し、全ＸＭＬ文書挿入用ＳＱＬを生成する（図８、ステップ２０４３）。
【０１０２】
具体的には、ＲＤＢ−ＸＭＬマッピング定義情報１７０のルート情報１７３を参照し、最上位階層の要素から順次階層を辿り、table属性が存在した場合、定義されたテーブル名と、その有効範囲に存在するすべてのcolumn属性に定義された列名を取得し、ＳＱＬ文を生成する。なお、table属性に付随してratio属性が定義されていた場合、以下のルールに従いＳＱＬ文を生成する。
【０１０３】
・“１：１”の場合：
本属性を持つテーブルに格納する１もしくはＮ個の要素を１行に格納する。
【０１０４】
・“１：Ｎ”の場合：
本属性を持つテーブルに格納する１もしくはＮ個の要素をＮ行に格納する。
【０１０５】
ＳＱＬ生成イメージを図１８に示す。生成したＳＱＬ文をＲＤＢ管理システム３００で実行し（図８、ステップ２０４４）、挿入を実行した文書件数を取得し（図８、ステップ２０７０）、これを問い合わせ結果として出力する（図９、ステップ２０８７）。
【０１０６】
部分ＸＭＬ文書挿入であれば（図１７（ａ））、do節に指定されたパスに対応する要素の先祖要素にcolumn属性を持っている要素が存在する場合は、更新対象とみなす（図８、ステップ２０５０）。ＲＤＢ−ＸＭＬマッピング定義情報１７０を参照し、テーブル名とカラム名を取得し、問い合わせ条件指定部分（where節）の解析で取得したデータと合わせてＳＱＬを生成する（図８、ステップ２０５１）。ＳＱＬ生成イメージを図１９に示す。生成したＳＱＬを実行し、更新対象のデータを取得する（図８、ステップ２０５２）。取得したデータは、ＤＯＭ木に展開した後、ＤＯＭ操作によりdo節で指定されたパスに対し挿入を行い、再度ＸＭＬ化する（図８、ステップ２０５３）。
【０１０７】
ＳＱＬ文生成部１３０は、挿入用ＳＱＬを生成し、更新を行ったＸＭＬをデーターベースに再格納する（OracleJBDCドライバの更新可能ResultSet使用）。上記操作をdo節で指定されたパスの要素まで繰り返す（図８、ステップ２０５０〜ステップ２０５４）。
【０１０８】
次に、do節に指定されたパスに対応する要素が子孫要素を持っており、その子孫要素にcolumn属性が定義されていた場合、ＲＤＢに格納されていると判断する（図８、ステップ２０６０）。更新対象のtable属性に対し、ratio属性が“１：１”で定義してある場合（図８、ステップ２０６１の判定）は、先祖要素と同じ方法で更新を行う（図８、ステップ２０６４〜ステップ２０６７）。また、ratio属性が“１：ｎ”もしくは、“１：Ｎ”である場合（図８、ステップ２０６１の判定）は該当するカラムに対して対象のデータを一旦削除した後に挿入を行う。先祖要素の更新時の取得した文書キーでＤＥＬＥＴＥ文を生成し、実行した（図８、ステップ２０６２）後、既に更新済みの先祖要素を格納しているカラムのデータを元にＩＮＳＥＲＴ文を生成し、実行する（図８、ステップ２０６３）。ＳＱＬの生成イメージを図２０に示す。ステップ２０６０からステップ２０６６までをＲＤＢに格納されている全ての子孫要素に対して行う。部分ＸＭＬ文書挿入／更新／削除を実行した文書件数を取得し（図８、ステップ２０７０）、これを問い合わせ結果として出力する（図９、ステップ２０８７）。
【０１０９】
（２） ＸＭＬ文書更新（操作フェーズ）
入力されたＸＭＬ問い合わせ文を元にＲＤＢ−ＸＭＬマッピング定義情報１７０を参照してＲＤＢに対してＸＭＬ文書の更新を行う。図２１（ａ）に示す問い合わせがアプリケーションプログラム２００から発行された場合を考える。
【０１１０】
問い合わせの受理（図７、ステップ２０１０）、ＸＭＬ問い合わせ文解析（図７、ステップ２０２０）は、前述の（１）ＸＭＬ文書挿入と同様である。問い合わせ結果指定部分がdo節なので検索操作を行う構文ではなく（図７、ステップ２０３０）、update関数が指定されているので更新操作を行う構文と判断される（図７、ステップ２０３１）。ＸＭＬ−ＲＤＢマッピング定義情報１７０のルート情報１７３を元に挿入用ＸＭＬ文書構造のチェックを行う（図７、ステップ２０４０）。全ＸＭＬ文書挿入でなく、更新なので（図８、ステップ２０４１）、以降の処理は、前述の（１）文書挿入で説明したステップ２０５０からステップ２０８７と同様であるため、その説明は省略する。
【０１１１】
（３） ＸＭＬ文書削除（操作フェーズ）
入力されたＸＭＬ問い合わせ文を元にＲＤＢ−ＸＭＬマッピング定義情報１７０を参照して、ＲＤＢに対してＸＭＬ文書の更新を行う。図２２（ａ）（ｂ）に示す問い合わせがアプリケーションプログラム２００から発行された場合を考える。
【０１１２】
問い合わせの受理（図７、ステップ２０１０）、ＸＭＬ問い合わせ文の解析（図７、ステップ２０２０）は、前述の（１）ＸＭＬ文書挿入、（２）ＸＭＬ文書更新と同様である。問い合わせ結果指定部分がdo節なので検索操作を行う構文ではなく（図７、ステップ２０３０）、remove関数が指定されているので削除操作を行う構文と判断される（図７、ステップ２０３１）。以降の処理は（１）ＸＭＬ文書挿入、（２）ＸＭＬ文書更新したステップ２０５０からステップ２０８７と同様であるため、説明を省略する。
【０１１３】
なお、更新済みの先祖要素を格納しているカラムのデータ内にＭＤのルート情報で更新対象と見做す要素が存在しなかった場合は、ＩＮＳＥＲＴ文生成時に値を指定しない（ＮＵＬＬを挿入する）。本実施例では、図２２（ａ）に示すＸＭＬ問い合わせ文による削除処理（図２３（ａ））が対応する。また、更新対象の要素がタグのみでテキストノードが存在しなかった場合は、空値（“”）を指定してＩＮＳＥＲＴ文を生成する。本実施例では、図２２（ｂ）に示すＸＭＬ問い合わせ文による削除処理（図２３（ｂ））が対応する。
【０１１４】
（４） ＸＭＬ文書検索（操作フェーズ）
入力されたＸＭＬ問い合わせ文を元にＲＤＢ−ＸＭＬマッピング定義情報１７０を参照してＲＤＢに対してＸＭＬ文書の検索を行う。図２４（ａ）に示す問い合わせがアプリケーションプログラム２００から発行された場合を考える。
【０１１５】
問い合わせの受理（図７、ステップ２０１０）、ＸＭＬ問い合わせ文の解析（図７、ステップ２０２０）は、前述の（１）ＸＭＬ文書挿入、（２）ＸＭＬ文書更新、（３）ＸＭＬ文書削除と同様であるので、その説明を省略する。
【０１１６】
問い合わせ結果指定部分が、return節なので、検索操作を行う構文と判断される（図７、ステップ２０３０）。ＲＤＢ−ＸＭＬマッピング定義情報１７０を参照して、問い合わせ結果指定部分のパスに対応する要素にcolumn属性が存在するので、当該要素はＲＤＢに格納されていると判断される（図９、ステップ２０８０）。当該要素が格納されているＲＤＢのテーブル名と、カラム名を取得する（図９、ステップ２０８３）。取得したテーブル名、カラム名と問い合わせ条件指定部分から得られた解析情報を元にＳＱＬを生成／実行する（図９、ステップ２０８４）。問い合わせ結果指定部分に対応する要素がＲＤＢに格納されているため、ＸＭＬ再構築は不要と判断される（図９、ステップ２０８５）。該当する要素がＲＤＢに格納されているので、それを問い合わせ結果として出力する（図９、ステップ２０８７）。
【０１１７】
図２５（ａ）に示す問い合わせがアプリケーションプログラム２００から発行された場合を考える。
【０１１８】
問い合わせの受理（図７、ステップ２０１０）から検索操作を行う構文との判定（図７、ステップ２０３０）までは先程の例と同様である。ＲＤＢ−ＸＭＬマッピング定義情報１７０を参照して、問い合わせ結果指定部分のパスに対応する要素にcolumn属性が存在しないので、当該要素は、ＲＤＢに格納されていないと判断される（図９、ステップ２０８０）。当該要素の子孫要素を辿り、column属性が存在する要素が出現するまで、子孫要素を辿ってテーブル名、カラム名を取得する（図９、ステップ２０８２）。これを全ての子孫要素に対して繰り返し、全てのテーブル名、カラム名を取得する（図９、ステップ２０８１）。取得したテーブル名、カラム名と問い合わせ条件指定部分から得られた解析情報を元に、ＳＱＬを生成／実行する（ステップ２０８４）。問い合わせ結果指定部分に対応する要素がＲＤＢに格納されていないため、ＸＭＬ再構築は必要と判定される（ステップ２０８５）。図２６に示すように、ＲＤＢ−ＸＭＬマッピング定義情報１７０を参照して、ＳＱＬの検索結果からＸＭＬ文書を問い合わせ結果として生成し（図９、ステップ２０８６）、出力する（ステップ２０８７）。
【０１１９】
なお、上記の準備フェーズ及び操作フェーズをプログラムとして構築し、構造化文書処理装置として利用されるコンピュータにインストールしておき、ＣＰＵ等の制御手段により実行する、または、ネットワークを介して流通させることも可能である。
【０１２０】
また、構築されたプログラムを、構造化文書処理装置として利用されるコンピュータに接続される、ハードディスク装置や、フレキシブルディスク、ＣＤ−ＲＯＭ等の可搬記憶媒体に格納しておき、実行時に、コンピュータにインストールして実行させることも可能である。
【０１２１】
なお、本発明は、上記の実施の形態及び実施例に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。
【０１２２】
【発明の効果】
上述のように、本発明によれば、ＸＭＬ文書の階層構造に基づいて、重複を許した部分ＸＭＬ文書に分割してＲＤＢと対応付けるマッピング定義情報及び当該定義に則って、入力されたＸＭＬに対する標準的な問い合わせをＳＱＬへ変換することにより、検索の頻度が高いのか、挿入／更新の頻度が高いのかという個々のＸＭＬ文書の利用形態に応じて、
（１）ＸＭＬ文書全体／部分をＲＤＢの１カラムに格納する。
（２）データ項目毎に分解して複数カラムに格納する。
という２つの格納方法を組み合わせることが可能となる。
【０１２３】
即ち、ＲＤＢを利用してＸＭＬ文書を扱う際に、検索の高速性と、追加、更新の高速性を両立することが可能となる。
【図面の簡単な説明】
【図１】本発明の原理を説明するための図である。
【図２】本発明の原理構成図である。
【図３】本発明の一実施の形態における構造化文書処理装置の構成図である。
【図４】本発明の一実施の形態におけるＲＤＢ−ＸＭＬマッピング定義情報に含まれる情報の概要を示す図である。
【図５】本発明の一実施の形態における構造化文書処理装置の全体の概要動作フローチャートである。
【図６】本発明の一実施の形態における準備フェーズのフローチャートである。
【図７】本発明の一実施の形態における操作フェーズのフローチャート（その１）である。
【図８】本発明の一実施の形態における操作フェーズのフローチャート（その２）である。
【図９】本発明の一実施の形態における操作フェーズのフローチャート（その３）である。
【図１０】本発明の一実施例のＲＤＢ−ＸＭＬマッピング定義情報の詳細を示す図である。
【図１１】本発明の一実施例のＲＤＢアクセス情報と記述例を示す図である。
【図１２】本発明の一実施例のテーブル生成情報と記述例である。
【図１３】本発明の一実施例のルート情報と記述例（その１）である。
【図１４】本発明の一実施例のルート情報と記述例（その２）である。
【図１５】本発明の一実施例のルート情報と記述例（その３）である。
【図１６】本発明の一実施例のＳＱＬ−ＤＤＬの出力例及びテーブルの生成例である。
【図１７】本発明の一実施例の操作フェーズにおいて使用する問い合わせと格納モデルである。
【図１８】本発明の一実施例の操作フェーズにおけるＳＱＬ生成イメージ（その１）である。
【図１９】本発明の一実施例の操作フェーズにおけるＳＱＬ生成イメージ（その２）である。
【図２０】本発明の一実施例の操作フェーズにおけるＳＱＬ生成イメージ（その３）である。
【図２１】本発明の一実施例の操作フェーズにおいて使用する問い合わせとＲＤＢ−ＸＭＬマッピング定義情報を示す図（その１）である。
【図２２】本発明の一実施例の操作フェーズにおいて使用する問い合わせとＲＤＢ−ＸＭＬマッピング定義情報を示す図（その２）である。
【図２３】本発明の一実施例の操作フェーズのＸＭＬ文書削除処理において生成するＳＱＬを示す図である。
【図２４】本発明の一実施例の操作フェーズにおけるＸＭＬ文書検索において使用する問い合わせとＲＤＢ−ＸＭＬマッピング定義情報と生成するＳＱＬを示す図である。
【図２５】本発明の一実施例の操作フェーズにおけるＸＭＬ文書検索において使用する問い合わせとＲＤＢ−ＸＭＬマッピング定義を生成するＳＱＬを示す図である。
【図２６】本発明の一実施例の操作フェーズのＸＭＬ文書検索において使用する問い合わせとＲＤＢ−ＸＭＬマッピング定義情報とＳＱＬ結果と問い合わせ結果を示す図である。
【符号の説明】
１００ 構造化文書処理装置
１１０ アプリケーションプログラムインタフェース部
１２０ 操作判定手段、ＸＭＬ問い合わせ文解析部
１３０ 命令文生成手段、ＳＱＬ文生成部
１４０ 操作指示手段、ＲＤＢ管理システムインタフェース部
１５０ 文書件数取得手段、ＤＯＭ操作部
１６０ 構造化文書出力手段、問い合わせ結果生成部
１７０ マッピング定義情報、ＲＤＢ−ＸＭＬマッピング定義情報
１７１ ＲＤＢアクセス情報
１７２ テーブル生成情報
１７３ ルート情報
２００ アプリケーションプログラム
３００ データーベース、ＲＤＢ管理システム
【発明の属する技術分野】
本発明は、構造化文書処理方法及び装置及び構造化文書処理プログラム及び構造化文書処理プログラムを格納した記憶媒体に係り、特に、データーベースを利用した構造化文書処理方法及び装置及び構造化文書処理プログラム及び構造化文書処理プログラムを格納した記憶媒体に関する。
【０００２】
【従来の技術】
ＸＭＬ（eXtensible Markup Language）は、ネットワーク上で交換される文書やデータの記述形式を規定するために、Ｗ３Ｃ(World Wide Web Consortium)が制定した規準規格である。ＸＭＬは、構造化文書の国際標準であるＳＧＭＬ(Standard Generalized Markup Language)の拡張可能性とＨＴＭＬ(HyperText Language)のインターネット利用性を併せ持った形式として期待されている。例えば、ＥＣ(Electronic Commerce)やＫＭ(Knowledge Management)で交換されるデータの記述や電子図書館の蔵書カタログの記述にもＸＭＬは利用できる。そして、このような利用例では、ＸＭＬの交換性という要件を超えて、大量のＸＭＬ文書を格納し、検索、更新できるという要件が重要になってくる。この要件を満たすためには、データーベース技術の適用・開発が必要となる。これには、大きく２つの方式がある。
【０００３】
（１）まず、１つの方式として、ネイティブＸＭＬデーターベースの開発がある。当該方式は、ＸＭＬ文書をそのまま格納し、検索、更新も可能なデーターベースを新たに開発する。Tamino（ソフトウェアＡＧ），eXcelon（エクセロン）、Yggdrasill（メディアフュージョン）などが挙げられる。
【０００４】
（２）２つ目の方式として、既存データーベースの機能拡張がある。既存のＲＤＢ（リレーショナルデーターベース）等に対し、ＸＭＬ文書を格納したり、取得したデータをＸＭＬ化する機能を拡張する。Oracle9i（オラクル）、ＳＱＬ Server2000（マイクロソフト）、ＤＢ２（ＩＢＭ）など主要なデーターベースはＸＭＬ対応となっている。
【０００５】
上記の（１）は、ＸＭＬ文書をそのまま扱えるのが大きな利点である。しかし、現在、ほとんどのデータがＲＤＢに格納されており、これら既存データとの連携、活用には（２）が適している。（２）でＸＭＬ文書の格納、検索、更新を行う場合、ＸＭＬ文書とＲＤＢとのマッピング方法が重要となる。ＸＭＬをＲＤＢにマッピングし、格納するには、大きく２つの方法がある。
【０００６】
ａ）ＸＭＬ文書全体を１カラムに格納する方法：
ＲＤＢのＣＬＯＢ（Character Large Object）やVarchar等のデータ型を利用することで、ＸＭＬ文書全体をそのまま１カラムに格納する。ＸＭＬ文書内のデータだけでなく、ＸＭＬ文書自体の文書構造を保持する場合に有効な方法である。例えば、新聞や雑誌の記事をアーカイブとして残す場合が当てはまる。この場合、指定された要素（日時や記者名等）のみ別カラムとし、インデックスを作成することで検索可能となる。
【０００７】
ｂ）ＸＭＬ文書をデータ項目に分解して複数カラムに格納する方法：
元となるＸＭＬ文書の要素や属性をデータ項目として分解し、ＲＤＢの複数のカラムに格納する。元のＸＭＬ文書自体は保存されないため、ＲＤＢ上に文書構造は保持されない。しかし、ＲＤＢ上のデータとして扱うため、当該データを複数のアプリケーションで共用する場合に有効な格納方法である。また、ＲＤＢからＸＭＬへのマッピング方法を決めておくことで、既存のＲＤＢに蓄積したデータをＸＭＬ文書として取得（出版）する（このような技術をＸＭＬ Publishingと呼ぶ）こともできる。
【０００８】
これらの格納方法をＸＭＬ−ＲＤＢ間のマッピング定義情報により実現する技術も開発されている（例えば、非特許文献１参照）。
【０００９】
【非特許文献１】
IBM,DB2XMLExtender:http://www-6.ibm.com/jp/sofuware/data/developer/colum/kantanextend/05xmlextender/01/html
【００１０】
【発明が解決しようとする課題】
しかし、格納方法をＸＭＬ−ＲＤＢ間のマッピング定義情報により実現する技術では、不十分な点も多い。
【００１１】
（１） ＸＭＬに対する標準的な問い合わせで検索，追加、更新することが困難であるという問題（機能的要件）： Ｗ３Ｃによって開発が進められている標準的な検索言語XQuery(http:///www.w3.org/TR/xquery/)では、検索結果ＸＭＬの構造を再構成、変換するといった柔軟な記述が可能となっている。また、追加、更新に関してもXupdate(http://www.xmldb.org/xupdate/)というＸＭＬに対応した言語が提案されている。しかし、従来の方法では、格納されたデータは、ＲＤＢ上のデータとして扱われる。そして、検索、追加、更新に用いられるクエリは、一般的にＸＭＬ拡張したＳＱＬが用いられる。また、ＸＭＬPublishingにおける、ＲＤＢからＸＭＬへのマッピングも固定的である。つまり、従来の方法では、格納されたデータをＲＤＢ上のデータとして扱うため、ＸＭＬに対する標準的なクエリで検索、追加、更新することが困難である。
【００１２】
（２） 検索の高速性と追加、更新の高速性を両立することが困難（性能的要件）： 一般的に、ＸＭＬ文書全体を検索、取得するだけなら、上記従来のａ）がｂ）に比べて高速である。一方、ＸＭＬ文書中の要素の追加、更新頻度が高い場合、ｂ）がａ）に比べて高速である。そして、ＸＭＬ文書の利用形態によっては、検索の高速性と追加、更新の高速性の両方が求められる場合がある。つまり、応用によってはこれらの格納方法を組み合わせることが必要となる。しかし、従来のＸＭＬ−ＲＤＢ間のマッピング定義情報では、ａ）とｂ）の２つの格納方法を柔軟に組み合わせて、検索の高速性と追加、更新の高速性を両立させることが困難である。
【００１３】
本発明は、上記の点に鑑みなされたもので、ＸＭＬ文書を、当該ＸＭＬ文書の階層構造に基づき、重複を許した部分ＸＭＬ文書に分割してＲＤＢと対応付けるマッピング定義情報及び当該定義に則って、入力されたＸＭＬに対する標準的な問い合わせをＳＱＬへ変換することにより、検索の高速性と追加、更新の高速性の両立を実現するデーターベースを利用した構造化文書処理方法及び装置及び構造化文書処理プログラム及び構造化文書処理プログラムを格納した記憶媒体を提供することを目的とする。
【００１４】
【課題を解決するための手段】
図１は、本発明の原理を説明するための図である。
【００１５】
本発明は、データベースを利用して構造化文書の格納、検索、更新及び削除の操作を行う構造化文書処理方法において、
入力された構造化文書に対する問い合わせを解析し、該問い合わせの要求している操作が挿入か、更新か、削除か、検索かを判定する操作判定ステップ（ステップ１）と、
記憶手段に格納されている、構造化文書の階層構造に基づいて、分割した部分文書同士の重複を許して、構造化文書を部分文書に分割してデータベースと対応付けるマッピング定義情報を参照して、操作判定ステップの判定に基づいて、入力された問い合わせを、該データベースに対し、挿入／更新／削除／検索のいずれかの操作を行う命令文に変換する命令文生成ステップ（ステップ２）と、
変換された命令文をデータベースに送信し、操作を実行させる操作指示ステップ（ステップ３）と、
命令文が挿入／更新／削除操作のいずれかであれば、該命令文を実行した文書件数を取得する文書件数取得ステップ（ステップ４）と、
命令文が検索操作であれば、マッピング定義情報を参照して、データベースの検索結果を構造化文書として出力する構造化文書出力ステップ（ステップ５）と、を行う。
【００２３】
図２は、本発明の原理構成図である。
【００２４】
本発明（請求項１）は、データベースを利用して構造化文書の格納、検索、更新及び削除の操作を行う構造化文書処理装置であって、
入力された構造化文書に対する問い合わせを解析し、該問い合わせの要求している操作が挿入か、更新か、削除か、検索かを判定する操作判定手段１２０と、
記憶手段に格納されている前記構造化文書全体、及び、該構造化文書の階層構造に基づいて分割される当該構造化文書の一部をデータベース３００と対応付けるマッピング定義情報１７０と、
マッピング定義情報１７０を参照して、操作判定手段の判定に基づいて、入力された問い合わせを、データベース３００に対し、挿入／更新／削除／検索のいずれかの操作を行う命令文に変換する命令文生成手段１３０と、
変換された命令文をデータベース３００に送信し、操作を実行させる操作指示手段１４０と、
命令文が挿入／更新／削除操作のいずれかであれば、該命令文を実行した文書件数を取得する文書件数取得手段１５０と、
命令文が検索操作であれば、マッピング定義情報１７０を参照して、データベース３００の検索結果を構造化文書として出力する構造化文書出力手段１６０と、を備え、
命令文生成手段１３０は、
挿入／更新操作用の構造化文書の構造が正当かを判定する手段と、
構造化文書全体を挿入する問い合わせか、あるいは、既に格納されている構造化文書に対し、構造化文書の一部を挿入または構造化文書の全体を更新または構造化文書の一部を更新する問い合わせかを判定する手段と、
構造化文書の一部を挿入または構造化文書の全体を更新または構造化文書の一部を更新する問い合わせであれば、マッピング定義情報を参照して、該構造化文書の一部に対応する要素の先祖要素がデータベース３００に格納されているかを判定する手段と、
先祖要素が、データベース３００に格納されていれば、該先祖要素の更新を行うための命令文を生成する更新命令生成手段と、
マッピング定義情報１７０を参照して、構造化文書の一部に対応する要素の子孫要素がデータベース３００に格納されているかを判定する手段と、
子孫要素がデータベース３００に格納されていれば、該子孫要素の更新を行うための命令文を生成する子孫要素更新命令生成手段と、を含む。
【００２５】
本発明（請求項２）は、データベースを利用して構造化文書の格納、検索、更新及び削除の操作を行う構造化文書処理装置であって、
入力された構造化文書に対する問い合わせを解析し、該問い合わせの要求している操作が挿入か、更新か、削除か、検索かを判定する操作判定手段１２０と、
記憶手段に格納されている構造化文書全体、及び、該構造化文書の階層構造に基づいて分割される当該構造化文書の一部をデータベース３００と対応付けるマッピング定義情報１７０と、
マッピング定義情報１７０を参照して、操作判定手段の判定に基づいて、入力された問い合わせを、該データベース３００に対し、挿入／更新／削除／検索のいずれかの操作を行う命令文に変換する命令文生成手段１３０と、
変換された命令文をデータベース３００に送信し、操作を実行させる操作指示手段１４０と、
命令文が挿入／更新／削除操作のいずれかであれば、該命令文を実行した文書件数を取得する文書件数取得手段１５０と、
命令文が検索操作であれば、マッピング提示情報１７０を参照して、データベース３００の検索結果を構造化文書として出力する構造化文書出力手段１６０と、を備え、
命令文生成手段１３０は、
マッピング定義情報１７０を参照して、構造化文書の一部に対応する要素の先祖要素がデータベースに格納されているかを判定する手段と、
先祖要素がデータベース３００に格納されていれば、該先祖要素から対応要素までの更新を行うための命令文を生成する更新命令生成手段と、
マッピング定義情報１７０を参照して、構造化文書の一部に対応する要素の子孫要素がデータベースに格納されているかを判定する手段と、
子孫要素がデータベース３００に格納されていれば、該子孫要素の更新を行うための命令文を生成する子孫要素更新命令生成手段と、を含む。
【００２６】
また、本発明（請求項３）は、上記の命令文生成手段１３０において、
挿入／更新操作用の構造化文書の構造が正当かを判定する手段と、
構造化文書全体を挿入する問い合わせか否かを判定する手段と、
構造化文書全体を挿入する問い合わせであれば、同一の構造を持った複数の構造化文書を識別するための識別子を払い出し、マッピング定義情報１７０を参照して、データベースに対し挿入を行う命令文へと変換する手段を含む。
【００２９】
また、本発明（請求項４）は、上記の更新命令生成手段において、
更新対象のデータを取得するための命令文を生成、実行する手段と、
取得した更新対象のデータを更新する手段と、
更新したデータを再度、挿入するための命令文を生成する手段と、
データベースに格納されている先祖要素について問い合わせで指定した要素まで、上記の各手段を制御して各手段による処理を繰り返させる制御手段と、を含む。
【００３０】
また、本発明（請求項５）は、上記の子孫要素更新命令生成手段において、
マッピング定義情報１７０を参照して、更新対象の同一要素のデータがデータベース３００上で複数行に別々に格納されているのか、一行にまとめて格納されているのかを判定する手段と、
複数行に別々に格納されている場合、データを一旦削除する命令文を生成、実行し、既に更新済みの先祖要素を格納しているデータを元に、該データを再度挿入するための命令文を該データを格納している全子孫要素について生成する手段と、
一行にまとめて格納されている場合に、更新対象のデータを取得するための命令文を生成、実行する手段と、
取得した更新対象のデータを更新する手段と、
更新したデータを再度、挿入するための命令文を生成する手段と、
データベースに格納されている子孫要素について問い合わせで指定した要素まで、上記の各手段を制御して各手段による処理を繰り返させる制御手段と、を含む。
【００３１】
また、本発明（請求項６）は、上記の命令文生成手段１３０において、
マッピング定義情報１７０を参照して、問い合わせに含まれる問い合わせ結果指定部分に対応する要素がそのまま前記データベースに格納されているか否かを判定する手段と、
そのままデータベースに格納されていれば、その所在を取得する手段と、
そのままデータベースに格納されていなければ、検索結果が出現するまで、問い合わせに含まれる問い合わせ結果指定部分に対応する要素の子孫要素を辿りその所在を取得する手段と、
取得した所在と、入力された問い合わせから検索のための命令文を生成する手段と、を含む。
【００３２】
本発明（請求項７）は、請求項１乃至２のいずれか１項に記載の構造化文書処理装置を構成する各手段としてコンピュータを機能させるための構造化文書処理プログラムである。
【００３３】
本発明（請求項８）は、請求項７に記載のプログラムを格納した記憶媒体である。
【００３４】
上記のように、本発明は、入力されたＸＭＬに対する標準的な問い合わせを解析し、当該問い合わせの要求している操作が挿入か、更新か、削除か、検索かを判定し、ＸＭＬ−ＲＤＢ間のマッピング定義情報（ＸＭＬ文書の階層構造に基づき、重複を許したＸＭＬ文書に分割して、ＲＤＢと対応付けるマッピング定義情報）に則って、入力された問い合わせをＳＱＬをＲＤＢ上で実行し、挿入／更新／削除であれば、当該操作を実行した文書件数を取得し、検索であれば、ＸＭＬ−ＲＤＢ間のマッピング定義情報を参照し、ＲＤＢの検索結果をＸＭＬ文書として出力するものである。ＸＭＬに対する標準的な問い合わせを解析し、ＸＭＬ−ＲＤＢ間のマッピング定義情報を参照することで、当該問い合わせを用いたＲＤＢへのＸＭＬ文書の挿入、更新、削除、検索が可能となる。また、当該マッピング定義情報は、ＸＭＬ文書の階層構造に基づき、重複を許して部分ＸＭＬ文書に分割して、ＲＤＢと対応付けることで、検索の高速性と追加、更新の高速性を両立することができる。
【００３５】
【発明の実施の形態】
以下、図面と共に本発明の実施の形態を説明する。
【００３６】
図３は、本発明の一実施の形態における構造化文書処理装置の構成を示す。
【００３７】
構造化文書処理装置１００は、アプリケーションプログラムインタフェース部１１０と、ＸＭＬ問い合わせ文解析部１２０、ＲＤＢ−ＸＭＬマッピング定義情報１７０、ＳＱＬ文生成部１３０、ＲＤＢ管理システムインタフェース部１４０、ＤＯＭ操作部１５０、問い合わせ結果生成部１６０から構成される。
【００３８】
アプリケーションプログラムインタフェース部１１０は、アプリケーションプログラムと通信網４００とを介してユーザから入力されたＸＭＬ問い合わせ文を受け付ける。ＸＭＬ問い合わせ文は、変数バインド部分、問い合わせ条件指定部分、問い合わせ結果指定部分から構成される。
【００３９】
ＸＭＬ問い合わせ解析部１２０は、アプリケーションプログラムインタフェース部１１０が受け付けたＸＭＬ問い合わせ文の構文を解析し、ＸＭＬ問い合わせ文解析情報を出力する。
【００４０】
図４は、本発明の一実施の形態におけるＲＤＢ−ＸＭＬマッピング定義情報に含まれる情報の概要を示す。ＲＤＢ−ＸＭＬマッピング定義情報１７０には、ＲＤＢにアクセスするための情報１７１と、ＳＱＬ−ＤＤＬを生成するために必要なテーブル生成情報１７２と、ＸＭＬ文書の情報とＲＤＢに格納された情報との対応関係をマッピングするためのルート情報１７３が含まれる。なお、当該ＲＤＢ−ＸＭＬマッピング定義情報１７０は、ハードディスク装置等の記憶媒体に格納される。
【００４１】
ＳＱＬ文生成部１３０では、ＸＭＬ問い合わせ文解析情報とＲＤＢ−ＸＭＬマッピング定義情報からＳＱＬ文を生成し、ＲＤＢ管理システムインタフェース部１４０と通信網４００を介してＲＤＢ管理システム３００に送信する。そして、ＳＱＬ結果をＲＤＢ管理システム３００から取得する。ＲＤＢ管理システムインタフェース部１４０は、生成したＳＱＬ文の受け付け、ＲＤＢ管理システム３００への接続、ＳＱＬ結果の取得を行う。
【００４２】
ＤＯＭ操作部１５０は、問い合わせ結果指定部分の先祖／子孫要素がＲＤＢに格納されている際、当該要素を取得し、ＤＯＭ（Document Object Model:XML操作のための標準ＡＰＩの１つ）に展開した後、ＤＯＭ操作により、問い合わせ結果指定部分に対し更新を行う。
【００４３】
問い合わせ結果生成部１６０では、取得したＳＱＬ結果と読み出したＲＤＢ−ＸＭＬマッピング定義情報から問い合わせ結果を生成する。問い合わせ結果とは、挿入・更新・削除の場合は操作を実行したＸＭＬ文書件数であり、検索の場合は、返却されるＸＭＬ文書を指す。
【００４４】
次に、本発明の構造化文書処理装置１００の処理手順の概要について説明する。
【００４５】
図５は、本発明の一実施の形態における構造化文書処理装置の全体の概要動作のフローチャートである。
【００４６】
構造化文書処理装置１００は、準備フェーズ（ステップ１０００）と操作フェーズ（ステップ２０００）の順で処理が行われる。準備フェーズ（ステップ１０００）では、ＲＤＢ−ＸＭＬマッピング定義情報１７０中のテーブル生成情報を元にＳＱＬ−ＤＤＬを出力し、ＲＤＢ上にテーブルを生成する。操作フェーズ（ステップ２０００）では、生成されたテーブルに対し、ＸＭＬ文書の挿入・更新・削除・検索を行う。
【００４７】
図６は、本発明の一実施の形態における準備フェーズのフローチャートである。
【００４８】
準備フェーズでは、まず、ＲＤＢ−ＸＭＬマッピング定義情報を作成し、記憶手段に格納する（ステップ１０１０）。ＳＱＬ文生成部１３０では、当該ＲＤＢ−ＸＭＬマッピング定義情報１７０中のテーブル生成情報を元に、ＳＱＬ−ＤＤＬを出力する（ステップ１０２０）。ＲＤＢ管理システムインタフェース部１４０では、当該ＲＤＢ−ＸＭＬマッピング定義情報１７０中のＲＤＢアクセス情報を元に、ＲＤＢ管理システム３００へ接続し、ＳＱＬ−ＤＤＬをＲＤＢ管理システム３００へ送信する（ステップ１０３０）。ＲＤＢ管理システム３００では、送信されたＳＱＬ−ＤＤＬに基づいてテーブルを生成する（ステップ１０４０）。
【００４９】
図７〜図９は、本発明の一実施の形態における操作フェーズのフローチャートである。
【００５０】
操作フェーズでは、まず、アプリケーションプログラムインタフェース部１１０が、アプリケーションプログラム２００を介して入力されたＸＭＬ問い合わせ文を受理する（ステップ２０１０）。問い合わせは、図３に示すように、変数バインド部分、問い合わせ条件指定部分、問い合わせ結果指定部分から構成される。
【００５１】
ＸＭＬ問い合わせ文解析部１２０は、ＸＭＬ問い合わせ文を解析し、ＸＭＬ問い合わせ文解析情報を出力する（ステップ２０２０）。このＸＭＬ問い合わせ文解析情報から、受理したＸＭＬ問い合わせ文が検索操作を行うため構文か否かを判定する（ステップ２０３０）。同様に、挿入／更新操作を行うための構文か削除操作を行う構文かを判定する（ステップ２０３１）。
【００５２】
挿入／更新操作を行うための構文であれば、挿入／更新用ＸＭＬ文書の構造が正当かを判定する（ステップ２０４０）。正当でなければエラーを出力して操作フェーズを終了する。正当であれば、全ＸＭＬ文書の挿入を行うための構文かを判定する（ステップ２０４１）。全ＸＭＬ文書の挿入を行うための構文であれば、１つ１つのＸＭＬ文書を識別するための文書キーを払い出し（ステップ２０４２）、ＳＱＬ文生成部１３０は、ＲＤＢ−ＸＭＬマッピング定義情報１７０とＸＭＬ問い合わせ文解析情報を参照し、全ＸＭＬ文書挿入用ＳＱＬを生成する（ステップ２０４３）。生成したＳＱＬ文をＲＤＢ管理システム３００で実行し（ステップ２０４４）、挿入を実行した文書件数を取得し（ステップ２０７０）、これを問い合わせ結果として出力する（ステップ２０８７）。
【００５３】
全ＸＭＬ文書の挿入を行うための構文でなければ（ステップ２０４１）、部分ＸＭＬ文書の挿入あるいは、全／部分ＸＭＬ文書の更新を行う構文である。以降の処理は、部分ＸＭＬ文書挿入／更新／削除で同一となる。まず、問い合わせ結果指定部分に対応する要素の先祖要素がＲＤＢに格納されているかを判定する（ステップ２０５０）。格納されていれば、ＳＱＬ文生成部１３０は、ＲＤＢ−ＸＭＬマッピング定義情報１７０とＸＭＬ問い合わせ文解析情報を参照し、テーブル名とカラム名を取得し、更新対象データ取得用ＳＱＬを生成する（ステップ２０５１）。生成したＳＱＬを実行し、更新対象データを取得する（ステップ２０５２）。
【００５４】
ＤＯＭ操作部１５０は、取得したデータをＤＯＭ(Document Object Model:XML操作のための標準ＡＰＩの一つ)に展開した後、ＤＯＭ操作により、問い合わせ結果指定部分に対し更新を行い、再び、ＸＭＬ化する（ステップ２０５３）。ＳＱＬ文生成部１３０は、挿入用ＳＱＬを生成し、更新を行ったＸＭＬをデーターベースに再挿入する（ステップ２０５４）。ステップ２０５１からステップ２０５４までを問い合わせ結果指定部分で指定された要素まで繰り返す。
【００５５】
次に、問い合わせ結果指定部分に対応する要素の子孫要素がＲＤＢに格納されているかを判定する（ステップ２０６０）。格納されていれば、同一パスのＮ個の要素がＮ行に別々に格納されているのか、１行にまとめて格納されているのかを判定する（ステップ２０６１）。１行にまとめて格納されている場合、先程のステップ２０５１からステップ２０５４と同様に、更新対象データを取得し、ＤＯＭ展開し、更新を行い、ＸＭＬ化してデーターベースに再挿入する（ステップ２０６４からステップ２０６７）。Ｎ行に別々に格納されている場合、先祖要素の更新時に取得した文書キーでデータ削除用ＳＱＬを生成し、実行（ステップ２０６２）した後、既に更新済みの先祖要素を格納している列のデータを元にデータ挿入用ＳＱＬを生成し、実行する（ステップ２０６３）。
【００５６】
ステップ２０６０からステップ２０６６までをＲＤＢに格納されているすべての子孫要素に対して行う。部分ＸＭＬ文書挿入／更新／削除を実行した文書件数を取得し（ステップ２０７０）、これを問い合わせ結果として出力する（ステップ２０８７）。
【００５７】
検索操作を行うための構文であれば（ステップ２０３０）、ＲＤＢ−ＸＭＬマッピング定義情報１７０を参照して、問い合わせ結果指定部分に対応する要素がＲＤＢに格納されているかを判定する（ステップ２０８０）。格納されていれば、当該要素が格納されているＲＤＢのテーブル名、カラム名を取得する（ステップ２０８３）。格納されていない場合、格納されている要素が出現するまで、当該要素の子孫要素を辿り、格納されているＲＤＢのテーブル名、カラム名を取得する（ステップ２０８２）。これを全ての子孫要素に対して繰り返し、全てのテーブル名、カラム名を取得する（ステップ２０８１）。
【００５８】
取得したテーブル名、カラム名と問い合わせ条件指定部分から得られた解析情報を元にＳＱＬを生成／実行する（ステップ２０８４）。ＲＤＢ−ＸＭＬマッピング定義情報１７０を参照して、問い合わせ結果指定部分に対応する要素がＲＤＢに格納されているかを判定することで、ＸＭＬ再構築が必要かを判定する（ステップ２０８５）。必要であればＲＤＢ−ＸＭＬマッピング定義情報１７０を参照して、ＳＱＬの検索結果からＸＭＬ文書を問い合わせ結果として生成し（ステップ２０８６）、出力する（ステップ２０８７）。再構築が必要でない場合は、該当する要素がＲＤＢに格納されているので、それを問い合わせ結果として出力する（ステップ２０８７）。
【００５９】
【実施例】
以下、図面と共に本発明の実施例を説明する。
【００６０】
最初に、準備フェーズについて説明する。
【００６１】
（１）テーブル生成（準備フェーズ）：
図１０は、本発明の一実施例のＲＤＢ−ＸＭＬマッピング定義情報の詳細を示す図である。図１１は、本発明の一実施例のＲＤＢアクセス情報と記述例を示す。図１２は、本発明の一実施例のテーブル生成情報と記述例を示す。図１３〜図１５は、本発明の一実施例のルート情報と記述例を示す。
ＲＤＢ−ＸＭＬマッピング定義情報１７０は、ＸＭＬ形式で規定された定義であり、図４に示したように、ＲＤＢアクセス情報１７１（図１１）、テーブル生成情報１７２（図１２），ルート情報１７３（図１３〜図１５）が含まれる。
【００６２】
（２）ＲＤＢ−ＸＭＬマッピング定義情報（図１０）：
ＲＤＢ−ＸＭＬマッピング定義情報１７０のルート要素である。Target属性により対象のＲＤＢ管理システム種別を定義する。version属性の値により、ＲＤＢ−ＸＭＬマッピング定義情報１７０の識別を行う。
【００６３】
（３）ＲＤＢアクセス情報（図１１）：
ＲＤＢの接続先毎の情報を定義する要素である。
【００６４】
・access要素
ＲＤＢ管理システムインタフェース部１４０を経由してＲＤＢに接続するための情報を定義する要素である。接続時に必要な接続先urlをｕｒｌ要素へ、接続時に必要なユーザ名やパスワードをproperty要素に定義する。
【００６５】
（ａ）url要素
ＲＤＢ管理システムインタフェース部１４０を経由してＲＤＢに接続する際に指定するＵＲＬを定義する要素である。
【００６６】
（ｂ）property要素
ＲＤＢ管理システムインタフェース部１４０を経由してＲＤＢに接続する際に指定するプロパティ情報（ユーザ名、パスワード等）を指定する要素である。name属性によりプロパティ名を定義する。
【００６７】
（２）テーブル生成情報（図１１）
ＳＱＬ文生成部１３０にて、ＲＤＢのテーブル生成用ＳＱＬ−ＤＤＬを生成するために必要な情報を定義する。
【００６８】
（ａ）table要素
個々のテーブルに対する情報を定義する。name属性に対し、テーブル名を記述する。
【００６９】
（ｂ）column要素
親要素のtable要素のname属性に指定したテーブルに持たせるカラムの情報を定義する。name属性に対し、カラム名を記述し、type属性に対し、ＲＤＢで定義されるデータ型を記述する。
【００７０】
（ｃ）constraint要素
親要素がtable要素の場合、表定義としての制約をＳＱＬと同じ形式で記述する。また、親要素がcolumn要素の場合は行定義としての制約をＳＱＬと同じ形式で記述する。
【００７１】
（ｄ） charactoristics要素
親要素のtable要素で指定されるテーブルに対しての物理特性やテーブル特性を定義する。ＳＱＬのCREATE文におけるphisical_propertis及びtable_propertiesに相当する部分をＳＱＬと同じ形式で記述する。
【００７２】
図１２にテーブル生成の記述例を示す。
【００７３】
（３）ルート情報（図１３）
入出力されるＸＭＬ文書とＲＤＢ内に格納されているデータとの関連をマッピングするための情報を定義する。element情報、attribute要素、text要素は、それぞれ元ＸＭＬ文書の要素，属性，テキストに相当し、元ＸＭＬと同じ階層構造について記述する。
【００７４】
ルート情報に定義する項目を図１５に示す。
【００７５】
（ａ）element要素
ＸＭＬ文書の要素に対応する要素である。各種属性にてＲＤＢとのマッチング情報を定義する。各属性の内容を以下に示す。
【００７６】
・name属性
ＸＭＬ文書の要素名を定義する。
【００７７】
・table属性
格納先のテーブル名を定義する。なお、すべての要素に定義されるわけではなく、定義は子孫の要素に次のtable属性が定義されるまでを有効範囲とする。
【００７８】
・column属性
格納先のカラム名を定義する。対象のテーブルは、上記のテーブル属性で定義された対象の(ansector-or-selfの内で直近のtable属性に定義された)テーブルとなり、対応するＸＭＬのデータの格納先が特定される。
【００７９】
・ratio属性
本属性は、table属性に付随して定義され、ｎ個の要素が存在する場合に、複数の格納先テーブル間の関係を定義する。
【００８０】
“１：１”の場合、本属性を持つ１もしくはｎ個の要素を１タプルに格納する。
【００８１】
“１：ｎ”もしくは“１：Ｎ”の場合、本属性を持つ１つもしくは、Ｎ個の要素をＮタプルに格納する。
【００８２】
なお、本属性が省略された場合“１：１”として扱う。
【００８３】
・minOccurs属性
本属性の定義された要素が持つことのできる要素の最小数を“０”か“１”で定義する。
【００８４】
・maxOccurs属性
本属性の定義された要素が持つことのできる要素の最大数を“１”か“unbounded”(制限なし)で定義する。
【００８５】
・docID属性
ＸＭＬ文書を識別するための文書IDに該当する要素に対し、本属性に“yes”を定義する。
【００８６】
・type属性
本属性は、column属性に付随して定義され、格納先のカラムのデータ型を定義する。ＸＭＬデータ格納の際に参照され、入力のデータとデータがたの整合性を判断する。
【００８７】
・size属性
本属性は、column属性に付随して定義され、格納先のカラムのサイズを定義する。ＸＭＬデータ格納の際に参照され、入力のデータのサイズが格納可能かを判断する。
【００８８】
・pkey属性
本属性は、table属性に付随して定義され、table属性に定義されたテーブルの主キーとなるカラム名を定義する。省略された場合は、DocKey（文書キー）を主キーと見做す。
【００８９】
・parent-fkey属性
本属性は、table属性に付随して定義され、該当のテーブルの主キーに対しての外部キーとなるカラム名を定義する。本属性で指定した列は、直近の先祖要素に定義されているテーブルの列として定義されるものとする。
【００９０】
・exts属性
拡張機能であるユーザ定義関数名を記述する。本属性を定義することによりユーザ定義関数と本属性が定義されたパスとの関連付けを定義する。
【００９１】
（ｂ）attribute要素
ＸＭＬ文書の属性に対応する要素である。各種属性にてデーターベースとのマッピング情報を定義する。属性は、element要素と同じ属性をもつが、その他にattribute要素固有の属性としてmeta属性を持つ。
【００９２】
・meta属性
追加属性を識別するための属性である。本属性に“yes”が指定された要素を追加属性と見做す。ＸＭＬ問い合わせ文で操作する場合は、直接本属性が定義された要素を問い合わせ結果指定部分(do節/return節)に指定しない限り、操作を行えないものとする。直接指定せずに操作を行おうとした場合、更新時には例外、検索時には、検索対象外とする。
【００９３】
（ｃ）text属性
ＸＭＬ文書の属性に対応する要素である。各種属性にてＲＤＢとのマッピング情報を定義する。属性は、element要素と同じ属性を持つ。
【００９４】
上記の項目を用いたＸＭＬ文書例、ルート情報の記述例を図１５に示す。本発明のＸＭＬ−ＲＤＢ間のマッピング定義情報１７０（ルート情報）は、ＸＭＬ文書を部分ＸＭＬ文書に分割してＲＤＢへ格納する。分割は、階層的に行い、重複も許している。図１６には、この格納の重複関係を階層構造（格納構造木）で示している。
【００９５】
準備フェーズでは、まず、ＲＤＢアクセス情報１７１（図１１）、テーブル生成情報１７２（図１２）、ルート情報１７３（図１３〜図１５）を含むＲＤＢ−ＸＭＬマッピング定義情報１７０（図１０）を作成する（ステップ１０１０）。ＳＱＬ文生成部１３０では、当該ＲＤＢ−ＸＭＬマッピング定義情報１７０中のテーブル生成情報（図１２）を元に、ＳＱＬ−ＤＤＬを出力する（ステップ１０２０）。ＲＤＢ管理システムインタフェース部１４０では、当該ＲＤＢ−ＸＭＬマッピング定義情報１７０中のＲＤＢアクセス情報（図１１）を元に、ＲＤＢ管理システム３００へ接続し、ＳＱＬ−ＤＤＬをＲＤＢ管理システム３００へ送信する（ステップ１０３０）。
【００９６】
ＲＤＢ管理システム３００では、送信されたＳＱＬ−ＤＤＬに基づいてテーブルを生成する（ステップ１０４０）。ＳＱＬ−ＤＤＬの出力例及びテーブルの生成例を図１６に示す。
【００９７】
次に、操作フェーズについて説明する。
【００９８】
（１） ＸＭＬ文書挿入（操作フェーズ）
入力されたＸＭＬ問い合わせ文を元にＲＤＢ−ＸＭＬマッピング定義情報１７０を参照して、ＲＤＢに対して全ＸＭＬ文書または、部分ＸＭＬ文書の挿入を行う。図１７（ａ），（ｂ）に示す問い合わせがアプリケーションプログラム２００から発行された場合を例に具体的に説明する。
【００９９】
まず、問い合わせを受理し（図７、ステップ２０１０）、ＸＭＬ問い合わせ文解析部１２０は、ＸＭＬ問い合わせ文を解析し、ＸＭＬ問い合わせ文解析情報を出力する（図７、ステップ２０２０）。挿入／更新／削除のＸＭＬ問い合わせ文は、ＸＭＬUpdate、検索のＸＭＬ問い合わせ文は、ＸQueryの構文に基づいている。
【０１００】
ＸＭＬ問い合わせ解析情報から問い合わせ結果指定部分がｄｏ節なので検索操作を行う構文ではなく（図７、ステップ２０３０）、また、append関数が指定されているので挿入操作を行う構文と判定される（図７、ステップ２０３１）。ＸＭＬ−ＲＤＢマッピング定義情報１７０のルート情報を元に挿入用ＸＭＬ文書構造のチェックを行う（図８、ステップ２０４０）。変数バインド部分のfor節からroot関数の引数であるroot名を取得し、ＸＭＬ−ＲＤＢマッピング定義情報１７０の該当するroot名を持つroot要素を特定する。また、for節に指定するバインド位置で、全ＸＭＬ文書挿入であるか部分ＸＭＬ文書挿入であるかを判定する。バインド指定でパスが指定されていない場合は、全ＸＭＬ文書挿入とみなし、ルート要素が指定されていた場合、部分ＸＭＬ文挿入とみなす（図８、ステップ２０４１）。これは、本実施例でぇあ、図１７（ｃ）に示す格納モデルを想定しているためである。
【０１０１】
全ＸＭＬ文書挿入であれば（図１７（ｂ））、文書キーを払い出し（図８、ステプ２０４２）、ＳＱＬ文生成部１３０は、ＲＤＢ−ＸＭＬマッピング定義情報１７０とＸＭＬ問い合わせ文解析情報を参照し、全ＸＭＬ文書挿入用ＳＱＬを生成する（図８、ステップ２０４３）。
【０１０２】
具体的には、ＲＤＢ−ＸＭＬマッピング定義情報１７０のルート情報１７３を参照し、最上位階層の要素から順次階層を辿り、table属性が存在した場合、定義されたテーブル名と、その有効範囲に存在するすべてのcolumn属性に定義された列名を取得し、ＳＱＬ文を生成する。なお、table属性に付随してratio属性が定義されていた場合、以下のルールに従いＳＱＬ文を生成する。
【０１０３】
・“１：１”の場合：
本属性を持つテーブルに格納する１もしくはＮ個の要素を１行に格納する。
【０１０４】
・“１：Ｎ”の場合：
本属性を持つテーブルに格納する１もしくはＮ個の要素をＮ行に格納する。
【０１０５】
ＳＱＬ生成イメージを図１８に示す。生成したＳＱＬ文をＲＤＢ管理システム３００で実行し（図８、ステップ２０４４）、挿入を実行した文書件数を取得し（図８、ステップ２０７０）、これを問い合わせ結果として出力する（図９、ステップ２０８７）。
【０１０６】
部分ＸＭＬ文書挿入であれば（図１７（ａ））、do節に指定されたパスに対応する要素の先祖要素にcolumn属性を持っている要素が存在する場合は、更新対象とみなす（図８、ステップ２０５０）。ＲＤＢ−ＸＭＬマッピング定義情報１７０を参照し、テーブル名とカラム名を取得し、問い合わせ条件指定部分（where節）の解析で取得したデータと合わせてＳＱＬを生成する（図８、ステップ２０５１）。ＳＱＬ生成イメージを図１９に示す。生成したＳＱＬを実行し、更新対象のデータを取得する（図８、ステップ２０５２）。取得したデータは、ＤＯＭ木に展開した後、ＤＯＭ操作によりdo節で指定されたパスに対し挿入を行い、再度ＸＭＬ化する（図８、ステップ２０５３）。
【０１０７】
ＳＱＬ文生成部１３０は、挿入用ＳＱＬを生成し、更新を行ったＸＭＬをデーターベースに再格納する（OracleJBDCドライバの更新可能ResultSet使用）。上記操作をdo節で指定されたパスの要素まで繰り返す（図８、ステップ２０５０〜ステップ２０５４）。
【０１０８】
次に、do節に指定されたパスに対応する要素が子孫要素を持っており、その子孫要素にcolumn属性が定義されていた場合、ＲＤＢに格納されていると判断する（図８、ステップ２０６０）。更新対象のtable属性に対し、ratio属性が“１：１”で定義してある場合（図８、ステップ２０６１の判定）は、先祖要素と同じ方法で更新を行う（図８、ステップ２０６４〜ステップ２０６７）。また、ratio属性が“１：ｎ”もしくは、“１：Ｎ”である場合（図８、ステップ２０６１の判定）は該当するカラムに対して対象のデータを一旦削除した後に挿入を行う。先祖要素の更新時の取得した文書キーでＤＥＬＥＴＥ文を生成し、実行した（図８、ステップ２０６２）後、既に更新済みの先祖要素を格納しているカラムのデータを元にＩＮＳＥＲＴ文を生成し、実行する（図８、ステップ２０６３）。ＳＱＬの生成イメージを図２０に示す。ステップ２０６０からステップ２０６６までをＲＤＢに格納されている全ての子孫要素に対して行う。部分ＸＭＬ文書挿入／更新／削除を実行した文書件数を取得し（図８、ステップ２０７０）、これを問い合わせ結果として出力する（図９、ステップ２０８７）。
【０１０９】
（２） ＸＭＬ文書更新（操作フェーズ）
入力されたＸＭＬ問い合わせ文を元にＲＤＢ−ＸＭＬマッピング定義情報１７０を参照してＲＤＢに対してＸＭＬ文書の更新を行う。図２１（ａ）に示す問い合わせがアプリケーションプログラム２００から発行された場合を考える。
【０１１０】
問い合わせの受理（図７、ステップ２０１０）、ＸＭＬ問い合わせ文解析（図７、ステップ２０２０）は、前述の（１）ＸＭＬ文書挿入と同様である。問い合わせ結果指定部分がdo節なので検索操作を行う構文ではなく（図７、ステップ２０３０）、update関数が指定されているので更新操作を行う構文と判断される（図７、ステップ２０３１）。ＸＭＬ−ＲＤＢマッピング定義情報１７０のルート情報１７３を元に挿入用ＸＭＬ文書構造のチェックを行う（図７、ステップ２０４０）。全ＸＭＬ文書挿入でなく、更新なので（図８、ステップ２０４１）、以降の処理は、前述の（１）文書挿入で説明したステップ２０５０からステップ２０８７と同様であるため、その説明は省略する。
【０１１１】
（３） ＸＭＬ文書削除（操作フェーズ）
入力されたＸＭＬ問い合わせ文を元にＲＤＢ−ＸＭＬマッピング定義情報１７０を参照して、ＲＤＢに対してＸＭＬ文書の更新を行う。図２２（ａ）（ｂ）に示す問い合わせがアプリケーションプログラム２００から発行された場合を考える。
【０１１２】
問い合わせの受理（図７、ステップ２０１０）、ＸＭＬ問い合わせ文の解析（図７、ステップ２０２０）は、前述の（１）ＸＭＬ文書挿入、（２）ＸＭＬ文書更新と同様である。問い合わせ結果指定部分がdo節なので検索操作を行う構文ではなく（図７、ステップ２０３０）、remove関数が指定されているので削除操作を行う構文と判断される（図７、ステップ２０３１）。以降の処理は（１）ＸＭＬ文書挿入、（２）ＸＭＬ文書更新したステップ２０５０からステップ２０８７と同様であるため、説明を省略する。
【０１１３】
なお、更新済みの先祖要素を格納しているカラムのデータ内にＭＤのルート情報で更新対象と見做す要素が存在しなかった場合は、ＩＮＳＥＲＴ文生成時に値を指定しない（ＮＵＬＬを挿入する）。本実施例では、図２２（ａ）に示すＸＭＬ問い合わせ文による削除処理（図２３（ａ））が対応する。また、更新対象の要素がタグのみでテキストノードが存在しなかった場合は、空値（“”）を指定してＩＮＳＥＲＴ文を生成する。本実施例では、図２２（ｂ）に示すＸＭＬ問い合わせ文による削除処理（図２３（ｂ））が対応する。
【０１１４】
（４） ＸＭＬ文書検索（操作フェーズ）
入力されたＸＭＬ問い合わせ文を元にＲＤＢ−ＸＭＬマッピング定義情報１７０を参照してＲＤＢに対してＸＭＬ文書の検索を行う。図２４（ａ）に示す問い合わせがアプリケーションプログラム２００から発行された場合を考える。
【０１１５】
問い合わせの受理（図７、ステップ２０１０）、ＸＭＬ問い合わせ文の解析（図７、ステップ２０２０）は、前述の（１）ＸＭＬ文書挿入、（２）ＸＭＬ文書更新、（３）ＸＭＬ文書削除と同様であるので、その説明を省略する。
【０１１６】
問い合わせ結果指定部分が、return節なので、検索操作を行う構文と判断される（図７、ステップ２０３０）。ＲＤＢ−ＸＭＬマッピング定義情報１７０を参照して、問い合わせ結果指定部分のパスに対応する要素にcolumn属性が存在するので、当該要素はＲＤＢに格納されていると判断される（図９、ステップ２０８０）。当該要素が格納されているＲＤＢのテーブル名と、カラム名を取得する（図９、ステップ２０８３）。取得したテーブル名、カラム名と問い合わせ条件指定部分から得られた解析情報を元にＳＱＬを生成／実行する（図９、ステップ２０８４）。問い合わせ結果指定部分に対応する要素がＲＤＢに格納されているため、ＸＭＬ再構築は不要と判断される（図９、ステップ２０８５）。該当する要素がＲＤＢに格納されているので、それを問い合わせ結果として出力する（図９、ステップ２０８７）。
【０１１７】
図２５（ａ）に示す問い合わせがアプリケーションプログラム２００から発行された場合を考える。
【０１１８】
問い合わせの受理（図７、ステップ２０１０）から検索操作を行う構文との判定（図７、ステップ２０３０）までは先程の例と同様である。ＲＤＢ−ＸＭＬマッピング定義情報１７０を参照して、問い合わせ結果指定部分のパスに対応する要素にcolumn属性が存在しないので、当該要素は、ＲＤＢに格納されていないと判断される（図９、ステップ２０８０）。当該要素の子孫要素を辿り、column属性が存在する要素が出現するまで、子孫要素を辿ってテーブル名、カラム名を取得する（図９、ステップ２０８２）。これを全ての子孫要素に対して繰り返し、全てのテーブル名、カラム名を取得する（図９、ステップ２０８１）。取得したテーブル名、カラム名と問い合わせ条件指定部分から得られた解析情報を元に、ＳＱＬを生成／実行する（ステップ２０８４）。問い合わせ結果指定部分に対応する要素がＲＤＢに格納されていないため、ＸＭＬ再構築は必要と判定される（ステップ２０８５）。図２６に示すように、ＲＤＢ−ＸＭＬマッピング定義情報１７０を参照して、ＳＱＬの検索結果からＸＭＬ文書を問い合わせ結果として生成し（図９、ステップ２０８６）、出力する（ステップ２０８７）。
【０１１９】
なお、上記の準備フェーズ及び操作フェーズをプログラムとして構築し、構造化文書処理装置として利用されるコンピュータにインストールしておき、ＣＰＵ等の制御手段により実行する、または、ネットワークを介して流通させることも可能である。
【０１２０】
また、構築されたプログラムを、構造化文書処理装置として利用されるコンピュータに接続される、ハードディスク装置や、フレキシブルディスク、ＣＤ−ＲＯＭ等の可搬記憶媒体に格納しておき、実行時に、コンピュータにインストールして実行させることも可能である。
【０１２１】
なお、本発明は、上記の実施の形態及び実施例に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。
【０１２２】
【発明の効果】
上述のように、本発明によれば、ＸＭＬ文書の階層構造に基づいて、重複を許した部分ＸＭＬ文書に分割してＲＤＢと対応付けるマッピング定義情報及び当該定義に則って、入力されたＸＭＬに対する標準的な問い合わせをＳＱＬへ変換することにより、検索の頻度が高いのか、挿入／更新の頻度が高いのかという個々のＸＭＬ文書の利用形態に応じて、
（１）ＸＭＬ文書全体／部分をＲＤＢの１カラムに格納する。
（２）データ項目毎に分解して複数カラムに格納する。
という２つの格納方法を組み合わせることが可能となる。
【０１２３】
即ち、ＲＤＢを利用してＸＭＬ文書を扱う際に、検索の高速性と、追加、更新の高速性を両立することが可能となる。
【図面の簡単な説明】
【図１】本発明の原理を説明するための図である。
【図２】本発明の原理構成図である。
【図３】本発明の一実施の形態における構造化文書処理装置の構成図である。
【図４】本発明の一実施の形態におけるＲＤＢ−ＸＭＬマッピング定義情報に含まれる情報の概要を示す図である。
【図５】本発明の一実施の形態における構造化文書処理装置の全体の概要動作フローチャートである。
【図６】本発明の一実施の形態における準備フェーズのフローチャートである。
【図７】本発明の一実施の形態における操作フェーズのフローチャート（その１）である。
【図８】本発明の一実施の形態における操作フェーズのフローチャート（その２）である。
【図９】本発明の一実施の形態における操作フェーズのフローチャート（その３）である。
【図１０】本発明の一実施例のＲＤＢ−ＸＭＬマッピング定義情報の詳細を示す図である。
【図１１】本発明の一実施例のＲＤＢアクセス情報と記述例を示す図である。
【図１２】本発明の一実施例のテーブル生成情報と記述例である。
【図１３】本発明の一実施例のルート情報と記述例（その１）である。
【図１４】本発明の一実施例のルート情報と記述例（その２）である。
【図１５】本発明の一実施例のルート情報と記述例（その３）である。
【図１６】本発明の一実施例のＳＱＬ−ＤＤＬの出力例及びテーブルの生成例である。
【図１７】本発明の一実施例の操作フェーズにおいて使用する問い合わせと格納モデルである。
【図１８】本発明の一実施例の操作フェーズにおけるＳＱＬ生成イメージ（その１）である。
【図１９】本発明の一実施例の操作フェーズにおけるＳＱＬ生成イメージ（その２）である。
【図２０】本発明の一実施例の操作フェーズにおけるＳＱＬ生成イメージ（その３）である。
【図２１】本発明の一実施例の操作フェーズにおいて使用する問い合わせとＲＤＢ−ＸＭＬマッピング定義情報を示す図（その１）である。
【図２２】本発明の一実施例の操作フェーズにおいて使用する問い合わせとＲＤＢ−ＸＭＬマッピング定義情報を示す図（その２）である。
【図２３】本発明の一実施例の操作フェーズのＸＭＬ文書削除処理において生成するＳＱＬを示す図である。
【図２４】本発明の一実施例の操作フェーズにおけるＸＭＬ文書検索において使用する問い合わせとＲＤＢ−ＸＭＬマッピング定義情報と生成するＳＱＬを示す図である。
【図２５】本発明の一実施例の操作フェーズにおけるＸＭＬ文書検索において使用する問い合わせとＲＤＢ−ＸＭＬマッピング定義を生成するＳＱＬを示す図である。
【図２６】本発明の一実施例の操作フェーズのＸＭＬ文書検索において使用する問い合わせとＲＤＢ−ＸＭＬマッピング定義情報とＳＱＬ結果と問い合わせ結果を示す図である。
【符号の説明】
１００ 構造化文書処理装置
１１０ アプリケーションプログラムインタフェース部
１２０ 操作判定手段、ＸＭＬ問い合わせ文解析部
１３０ 命令文生成手段、ＳＱＬ文生成部
１４０ 操作指示手段、ＲＤＢ管理システムインタフェース部
１５０ 文書件数取得手段、ＤＯＭ操作部
１６０ 構造化文書出力手段、問い合わせ結果生成部
１７０ マッピング定義情報、ＲＤＢ−ＸＭＬマッピング定義情報
１７１ ＲＤＢアクセス情報
１７２ テーブル生成情報
１７３ ルート情報
２００ アプリケーションプログラム
３００ データーベース、ＲＤＢ管理システム
Claims (8)
- データベースを利用して構造化文書の格納、検索、更新及び削除の操作を行う構造化文書処理装置であって、
入力された構造化文書に対する問い合わせを解析し、該問い合わせの要求している操作が挿入か、更新か、削除か、検索かを判定する操作判定手段と、
記憶手段に格納されている前記構造化文書全体、及び、該構造化文書の階層構造に基づいて分割される当該構造化文書の一部をデータベースと対応付けるマッピング定義情報と、
前記マッピング定義情報を参照して、前記操作判定手段の判定に基づいて、入力された前記問い合わせを、前記データベースに対し、挿入／更新／削除／検索のいずれかの操作を行う命令文に変換する命令文生成手段と、
変換された命令文を前記データベースに送信し、操作を実行させる操作指示手段と、
前記命令文が挿入／更新／削除操作のいずれかであれば、該命令文を実行した文書件数を取得する文書件数取得手段と、
前記命令文が検索操作であれば、前記マッピング定義情報を参照して、前記データベースの検索結果を構造化文書として出力する構造化文書出力手段と、を備え、
前記命令文生成手段は、
挿入／更新操作用の構造化文書の構造が正当かを判定する手段と、
前記構造化文書全体を挿入する問い合わせか、あるいは、既に格納されている構造化文書に対し、構造化文書の一部を挿入または構造化文書の全体を更新または構造化文書の一部を更新する問い合わせかを判定する手段と、
前記構造化文書の一部を挿入または構造化文書の全体を更新または構造化文書の一部を更新する問い合わせであれば、前記マッピング定義情報を参照して、該構造化文書の一部に対応する要素の先祖要素が前記データベースに格納されているかを判定する手段と、
前記先祖要素が、前記データベースに格納されていれば、該先祖要素の更新を行うための命令文を生成する更新命令生成手段と、
前記マッピング定義情報を参照して、前記構造化文書の一部に対応する要素の子孫要素が前記データベースに格納されているかを判定する手段と、
前記子孫要素が前記データベースに格納されていれば、該子孫要素の更新を行うための命令文を生成する子孫要素更新命令生成手段と、を含む
ことを特徴とする構造化文書処理装置。 - データベースを利用して構造化文書の格納、検索、更新及び削除の操作を行う構造化文書処理装置であって、
入力された構造化文書に対する問い合わせを解析し、該問い合わせの要求している操作が挿入か、更新か、削除か、検索かを判定する操作判定手段と、
記憶手段に格納されている前記構造化文書全体、及び、該構造化文書の階層構造に基づいて分割される当該構造化文書の一部をデータベースと対応付けるマッピング定義情報と、
前記マッピング定義情報を参照して、前記操作判定手段の判定に基づいて、入力された前記問い合わせを、前記データベースに対し、挿入／更新／削除／検索のいずれかの操作を行う命令文に変換する命令文生成手段と、
変換された命令文を前記データベースに送信し、操作を実行させる操作指示手段と、
前記命令文が挿入／更新／削除操作のいずれかであれば、該命令文を実行した文書件数を取得する文書件数取得手段と、
前記命令文が検索操作であれば、前記マッピング提示情報を参照して、前記データベースの検索結果を構造化文書として出力する構造化文書出力手段と、を備え、
前記命令文生成手段は、
前記マッピング定義情報を参照して、前記構造化文書の一部に対応する要素の先祖要素が前記データベースに格納されているかを判定する手段と、
前記先祖要素が前記データベースに格納されていれば、該先祖要素から対応要素までの更新を行うための命令文を生成する更新命令生成手段と、
前記マッピング定義情報を参照して、前記構造化文書の一部に対応する要素の子孫要素が前記データベースに格納されているかを判定する手段と、
前記子孫要素が前記データベースに格納されていれば、該子孫要素の更新を行うための命令文を生成する子孫要素更新命令生成手段と、
を含むことを特徴とする構造化文書処理装置。 - 前記命令文生成手段は、
挿入／更新操作用の構造化文書の構造が正当かを判定する手段と、
前記構造化文書全体を挿入する問い合わせか否かを判定する手段と、
前記構造化文書全体を挿入する問い合わせであれば、同一の構造を持った複数の構造化文書を識別するための識別子を払い出し、前記マッピング定義情報を参照して、前記データベースに対し挿入を行う命令文へと変換する手段を含む
請求項１または２記載の構造化文書処理装置。 - 前記更新命令生成手段は、
更新対象のデータを取得するための命令文を生成、実行する手段と、
取得した更新対象のデータを更新する手段と、
更新したデータを再度、挿入するための命令文を生成する手段と、
前記データベースに格納されている先祖要素について問い合わせで指定した要素まで、上記の各手段を制御して各手段による処理を繰り返させる制御手段と、
を含む請求項１または２記載の構造化文書処理装置。 - 前記子孫要素更新命令生成手段は、
前記マッピング定義情報を参照して、更新対象の同一要素のデータが前記データベース上で複数行に別々に格納されているのか、一行にまとめて格納されているのかを判定する手段と、
複数行に別々に格納されている場合、データを一旦削除する命令文を生成、実行し、既に更新済みの先祖要素を格納しているデータを元に、該データを再度挿入するための命令文を該データを格納している全子孫要素について生成する手段と、
一行にまとめて格納されている場合に、更新対象のデータを取得するための命令文を生成、実行する手段と、
取得した更新対象のデータを更新する手段と、
更新したデータを再度、挿入するための命令文を生成する手段と、
前記データベースに格納されている子孫要素について問い合わせで指定した要素まで、上記各手段を制御して各手段による処理を繰り返させる制御手段と、
を含む請求項１または２記載の構造化文書処理装置。 - 前記命令文生成手段は、
前記マッピング定義情報を参照して、前記問い合わせに含まれる問い合わせ結果指定部分に対応する要素がそのまま前記データベースに格納されているか否かを判定する手段と、
そのまま前記データベースに格納されていれば、その所在を取得する手段と、
そのまま前記データベースに格納されていなければ、検索結果が出現するまで、前記問い合わせに含まれる問い合わせ結果指定部分に対応する要素の子孫要素を辿りその所在を取得する手段と、
前記取得した所在と、入力された問い合わせから検索のための命令文を生成する手段と、
を含む請求項１また２記載の構造化文書処理装置。 - 請求項１乃至６のいずれか１項に記載の構造化文書処理装置を構成する各手段としてコンピュータを機能させるための構造化文書処理プログラム。
- 請求項７に記載のプログラムを格納したことを特徴とする記憶媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003145414A JP4289022B2 (ja) | 2003-05-22 | 2003-05-22 | 構造化文書処理方法及び装置及び構造化文書処理プログラム及び構造化文書処理プログラムを格納した記憶媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003145414A JP4289022B2 (ja) | 2003-05-22 | 2003-05-22 | 構造化文書処理方法及び装置及び構造化文書処理プログラム及び構造化文書処理プログラムを格納した記憶媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004348485A JP2004348485A (ja) | 2004-12-09 |
| JP4289022B2 true JP4289022B2 (ja) | 2009-07-01 |
Family
ID=33532595
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003145414A Expired - Lifetime JP4289022B2 (ja) | 2003-05-22 | 2003-05-22 | 構造化文書処理方法及び装置及び構造化文書処理プログラム及び構造化文書処理プログラムを格納した記憶媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4289022B2 (ja) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100714693B1 (ko) | 2005-06-07 | 2007-05-04 | 삼성전자주식회사 | 소프트웨어 모듈의 독립성을 보장하는 데이터베이스어플리케이션을 구현하는 시스템 및 방법 |
| JP5506548B2 (ja) * | 2010-06-01 | 2014-05-28 | 日本電信電話株式会社 | Ｘｍｌデータベース管理システム及び方法及びプログラム |
| WO2012011915A1 (en) * | 2010-07-22 | 2012-01-26 | Hewlett-Packard Development Company, L.P. | Sql enumerator |
| JP6339932B2 (ja) * | 2014-12-26 | 2018-06-06 | エヌ・ティ・ティ・コムウェア株式会社 | データ管理装置、データ管理方法及びデータ管理プログラム |
| CN114357051B (zh) * | 2022-01-11 | 2024-08-20 | 天津大学 | 基于原生JSON的SQL与NoSQL数据转换方法 |
-
2003
- 2003-05-22 JP JP2003145414A patent/JP4289022B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004348485A (ja) | 2004-12-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7318063B2 (en) | Managing XML documents containing hierarchical database information | |
| US7386567B2 (en) | Techniques for changing XML content in a relational database | |
| US7634498B2 (en) | Indexing XML datatype content system and method | |
| US6959416B2 (en) | Method, system, program, and data structures for managing structured documents in a database | |
| US8001151B2 (en) | Querying markup language data sources using a relational query processor | |
| US7353222B2 (en) | System and method for the storage, indexing and retrieval of XML documents using relational databases | |
| JP4352079B2 (ja) | 分散データベースから情報を検索するシステム、装置、および方法 | |
| JP5320438B2 (ja) | Ｘｍｌデータ記憶、クエリー再書込、ビジュアライゼーション、マッピング、および参照のための方法および装置 | |
| US7844633B2 (en) | System and method for storage, management and automatic indexing of structured documents | |
| US20020143742A1 (en) | Apparatus, method, and program for retrieving structured documents | |
| KR20090028758A (ko) | 정보 재사용 방법, 정보 제공 방법, 편집 가능한 문서, 및 문서 편집 시스템 | |
| JP2005190163A (ja) | 構造化データ検索方法、構造化データ検索装置およびプログラム | |
| EP1192561A1 (en) | Database management system with capability of fine-grained indexing and querying | |
| JP4289022B2 (ja) | 構造化文書処理方法及び装置及び構造化文書処理プログラム及び構造化文書処理プログラムを格納した記憶媒体 | |
| US20050060307A1 (en) | System, method, and service for datatype caching, resolving, and escalating an SQL template with references | |
| JP3671765B2 (ja) | 異種情報源問い合わせ変換方法及び装置及び異種情報源問い合わせ変換プログラムを格納した記憶媒体 | |
| JP2006031377A (ja) | 構造化文書管理装置、検索装置、記憶方法、検索方法及びプログラム | |
| Yu et al. | Metadata management system: design and implementation | |
| JP2005056085A (ja) | データ構造変換プログラム | |
| JP4724177B2 (ja) | Ｘｍｌデータにアクセスするためのインデックス | |
| Al-Wasil et al. | Establishing an XML metadata klnowledge base to assist integration of structured and semi-structured databases | |
| JP3842574B2 (ja) | 情報抽出方法および構造化文書管理装置およびプログラム | |
| JP2004348593A (ja) | 格納検索装置、格納検索方法、格納検索プログラム、および格納検索プログラム記録媒体 | |
| Garcia | Business information integration from XML and relational databases sources | |
| Chen et al. | Efficient processing of XPath queries using indexes |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050720 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080722 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080910 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081216 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090213 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090310 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090323 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4289022 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120410 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130410 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140410 Year of fee payment: 5 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| EXPY | Cancellation because of completion of term |