JP2005056085A - データ構造変換プログラム - Google Patents

Abstract

【課題】 構造化文書とＲＤＢ上のテーブルとの間で効率よくデータ構造を変換し、これらを柔軟に連携させる。
【解決手段】 構造化文書１ａ中の処理対象とするノードより下位のノードについて、操作対象とするＲＤＢ２内のテーブルとの対応付けを定義したデータ更新定義３ａを用いて、構造化文書１ａ中のルートノードを処理対象に設定し（ステップＳ２−１）、処理対象に設定されたノードを起点にして、データ更新定義３ａにより指示されるノードから繰り返し要素を抽出し（ステップＳ２−２）、繰り返し要素として抽出されたノードごとに、テーブルに対応付けられた要素内容または属性値を構造化文書１ａから抽出して、テーブルの更新を要求する処理を行い（ステップＳ２−３〜Ｓ２−６）、下位ノードからの繰り返し要素の抽出が指定されていた場合には、抽出されていたノードを新たに処理対象としてステップＳ２−２〜Ｓ２−６を実行する。
【選択図】 図１

Description

本発明は、構造化文書とリレーショナルデータベースとの間でデータ構造を変換する処理をコンピュータに実行させることにより、構造化文書により記述されたデータを用いてリレーショナルデータベースを更新する、あるいはリレーショナルデータベースを参照して構造化文書を復元することが可能なデータ構造プログラムに関する。

近年、インターネットのようなネットワーク環境を利用した企業間の電子商取引、いわゆるＢ２Ｂ（Business to Business）が盛んであるが、この電子商取引のようにネットワークを用いたシステムを運用する上で、使用される文書やデータに対する互換性に優れた構造化文書が要求されている。このような構造化文書の中でも特に、ＸＭＬ（eXtensible Markup Language）は、ＳＧＭＬ（Standard Generalized Markup Language）の文法定義を簡略化して処理パフォーマンスを向上し、ネットワーク適応性が向上したデータ記述言語として最も注目されている。

また、上記のようなシステムでは、構造化文書により記述されたデータをデータベースに格納する処理、およびデータベースに格納されたデータから構造化文書を復元する処理の効率化が求められている。特に、リレーショナルデータベース（以下、ＲＤＢと呼称する）に対してＸＭＬで記述されたデータの格納・復元を行う処理の効率化が求められている。

なお、このような技術に関連して、ＷｅｂサイトとＲＤＢとを効果的に連携させることが可能な従来の情報処理システムとして、入力される文字列に基づいてＷｅｂページの内容を表すＸＭＬ文書を生成するＸＭＬ生成部と、Ｗｅｂページの表示形式を表すスタイルシートの候補の中から、ＸＭＬ文書の対応するものを選択し、ＸＭＬ文書の関連付けるスタイル選択部と、生成されたＸＭＬ文書中の各要素をＲＤＢに登録するとともに、ＸＭＬ文書が編集されたときに、編集内容をＲＤＢに反映させるＲＤＢ連携部と、１または２以上のＸＭＬ文書を格納するＸＭＬデータベースのためのデータベースシステムとして機能するＸＭＬＤＢ制御部とがホスト上に設けられたものがあった（例えば、特許文献１参照）。
特開２００２−２２２１８１号公報（段落番号〔００９４〕〜〔０１１２〕，第１図）

上述したように、電子商取引のシステム等を実現する場合に、リレーショナルデータベース（以下、ＲＤＢと呼称する）に対するＸＭＬデータの格納・復元処理の効率化が求められている。しかし、ＲＤＢにおいて正規化により階層構造をなす複数のテーブルに、ＸＭＬデータを完全に対応付け、格納・復元の処理を行うプログラムの開発は、一般的に難易度が高い。例えば、やり取りされるＸＭＬ文書の階層構造と、ＲＤＢ上の階層構造とに応じて、その都度プログラムを作成する必要があり、しかも階層構造を解析するプログラムは複雑になることから、拡張性が低いことが問題であった。

本発明はこのような課題に鑑みてなされたものであり、構造化文書とＲＤＢ上のテーブルとの間で効率よくデータ構造を変換し、これらを柔軟に連携させることが可能なデータ処理プログラムを提供することを目的とする。

本発明では上記問題を解決するために、図１に示すような処理をコンピュータに実行させるデータ構造変換プログラムが提供される。このデータ構造変換プログラムは、構造化文書１ａとリレーショナルデータベース（ＲＤＢ）２との間でデータ構造を変換する処理を実行させるものであり、入力された構造化文書１ａ中の処理対象とするノードより下位のノードについて、操作対象とするリレーショナルデータベース２内のテーブルとの対応付けを定義したデータ更新定義３ａを取得する更新定義取得ステップＳ１と、入力された前記構造化文書１ａ中のルートノードを前記処理対象に設定する第１のステップ、前記処理対象に設定されたノードを起点にして、前記データ更新定義３ａにより指示されるノードから繰り返し要素を抽出する第２のステップ、前記繰り返し要素として抽出されたノードごとに、前記テーブルに対応付けられた要素内容または属性値を入力された前記構造化文書１ａから抽出して、前記テーブルの更新を要求する第３のステップからなる処理を実行し、前記第３のステップの実行中に前記データ更新定義３ａにより下位ノードからの繰り返し要素の抽出が指定されていた場合には、前記第３のステップにおいて抽出されていたノードを新たに前記処理対象として前記第２および第３のステップを実行するデータ更新ステップＳ２とを含む処理を前記コンピュータに実行させることを特徴とする。

このようなデータ構造変換プログラムでは、入力された構造化文書１ａ中の処理対象とするノードより下位のノードについて、操作対象とするリレーショナルデータベース２内のテーブルとの対応付けを定義したデータ更新定義３ａがあらかじめ定義され、このデータ更新定義３ａを取得して、データ更新ステップＳ２が実行されることにより、入力された構造化文書１ａにより記述されたデータを用いて、リレーショナルデータベース２が更新される。データ更新ステップＳ２では、入力された構造化文書１ａ中のルートノードを処理対象に設定する第１のステップと、処理対象に設定されたノードを起点にして、データ更新定義３ａにより指示されるノードから繰り返し要素を抽出する第２のステップと、繰り返し要素として抽出されたノードごとに、テーブルに対応付けられた要素内容または属性値を入力された構造化文書１ａから抽出して、テーブルの更新を要求する第３のステップとからなる処理が実行される。これにより、構造化文書１ａ中の処理対象ノードの下位ノードからデータが抽出され、その抽出データを用いてリレーショナルデータベース２内の対応するテーブルに対するデータ操作が行われる。

また、第３のステップの実行中にデータ更新定義３ａにより下位ノードからの繰り返し要素の抽出が指定されていた場合には、第３のステップにおいて抽出されていたノードを新たに処理対象として第２および第３のステップが実行される。このように、データ更新定義３ａを用いて第２および第３のステップが再帰的に実行されることにより、構造化文書１ａ中のより下位の階層からのデータが順次抽出されて、抽出したデータを用いたリレーショナルデータベース２へのデータ操作が行われる。

また、リレーショナルデータベース２の構造や、入力される構造化文書１ａが変更された場合には、対応するデータ更新定義３ａのみを変更すればよい。
また、本発明のデータ構造変換プログラムでは、図１に示すように、前記リレーショナルデータベース２に対する検索条件の入力を受ける条件入力ステップＳ３と、出力される構造化文書１ｂの全体あるいは一部の構造に対応するテンプレートと、前記テンプレートのインスタンス化の際の抽出対象とする前記リレーショナルデータベース２上のパラメータとを含む参照対象テーブル定義が１つ以上記述されたデータ参照定義３ｂを取得する参照定義取得ステップＳ４と、前記検索条件および前記参照対象テーブル定義に基づいて前記リレーショナルデータベース２に問い合わせを発行する第４のステップ、前記問い合わせの結果を用いて前記テンプレートをインスタンス化する第５のステップからなる処理を実行し、前記第５のステップの実行中に別の前記参照対象テーブル定義の呼び出しが指定されていた場合には、該当する前記参照対象テーブル定義を用いて前記第４および第５のステップを実行するテンプレート置換ステップＳ５とを含む処理をさらに前記コンピュータに実行させてもよい。

このような場合、出力される構造化文書１ｂの全体あるいは一部の構造に対応するテンプレートと、このテンプレートのインスタンス化の際の抽出対象とするリレーショナルデータベース２上のパラメータとを含む参照対象テーブル定義が１つ以上記述されたデータ参照定義３ｂがあらかじめ定義され、リレーショナルデータベース２に対する検索条件の入力を受けると、このデータ参照定義３ｂを取得してテンプレート置換ステップＳ５が実行される。ここで、テンプレート置換ステップＳ５では、入力された検索条件および参照対象テーブル定義に基づいてリレーショナルデータベース２に問い合わせを発行する第４のステップと、この問い合わせの結果を用いてテンプレートをインスタンス化する第５のステップとからなる処理が実行される。このような処理では、各参照対象テーブル定義を適用することにより、リレーショナルデータベース２上の１つのテーブルから抽出可能なデータを用いてテンプレートのインスタンス化が行われて、このテンプレートに記述された構造化文書１ｂの全体または一部の要素配列が復元される。

さらに、第５のステップの実行中に別の参照対象テーブル定義の呼び出しが指定されていた場合には、該当する参照対象テーブル定義を用いて第４および第５のステップが実行される。このように、参照対象テーブル定義を用いた処理が再帰的に実行されることにより、リレーショナルデータベース２上の指定されたテーブルから抽出したデータを用いて、各テンプレートが順次インスタンス化されて、構造化文書１ｂの要素配列が順次復元されていく。

また、リレーショナルデータベース２の構造や、復元する構造化文書１ｂの構造が変更された場合には、対応するデータ参照定義３ｂのみを変更すればよい。

本発明のデータ構造変換プログラムによれば、あらかじめ定義されたデータ更新定義を用いて、第２および第３のステップが再帰的に実行されることにより、入力された構造化文書の各階層からデータを抽出し、リレーショナルデータベースに対してデータ操作する処理を、効率的に行うことが可能となる。また、リレーショナルデータベースの構造や、入力される構造化文書の構造が変更された場合には、対応するデータ更新定義のみを変更して、データ更新ステップの処理手順を変更する必要がないため、入力される構造化文書とリレーショナルデータベースの各構造に対する拡張性を高め、これらを柔軟に連携させることが可能となる。

また、条件入力ステップ、参照定義取得ステップ、テンプレート置換ステップおよび文書出力ステップを含む処理をさらに実行させた場合には、参照対象テーブル定義を用いた処理が再帰的に実行されることにより、リレーショナルデータベース内の１つのテーブルから抽出したデータを用いて、構造化文書の全体または一部が順次復元されていくので、このような復元処理が効率化される。また、リレーショナルデータベースの構造や、復元する構造化文書が変更された場合には、対応するデータ参照定義のみを変更して、上記のテンプレート置換ステップおよび文書出力ステップの処理手順を変更する必要がないため、入力される構造化文書とリレーショナルデータベースの各構造に対する拡張性を高め、これらを柔軟に連携させることが可能となる。

以下、本発明の実施の形態を図面を参照して説明する。
図１は、本発明の原理を説明するための原理図である。この図１を用いて、本発明の概要を説明する。

本発明が適用されるデータ構造変換装置は、構造化文書１ａの入力を受けて、ＲＤＢ２に対するデータの格納、削除、修正の操作を行うものである。また、このＲＤＢ２からデータを抽出して、構造化文書１ｂとして復元して出力するものである。構造化文書１ａおよび１ｂは、例えばＸＭＬにより記述されたテキストデータであり、また、ＲＤＢ２としては、例えば正規化により階層構造をなしている複数のテーブルによって構成されたものを適用することができる。

本発明では、入出力される構造化文書１ａおよび１ｂと、ＲＤＢ２との間の構造の対応関係を記述したデータ対応定義３をあらかじめ作成しておき、このデータ対応定義３に従って上記の処理を実行する。データ対応定義３は、入力された構造化文書１ａに基づいてＲＤＢ２を更新する（すなわちデータの格納、削除、修正を行う）際に用いるデータ更新定義３ａと、ＲＤＢ２を参照して構造化文書１ｂを復元する際に用いるデータ参照定義３ｂの少なくとも一方を含んでいる。

データ更新定義３ａでは、入力された構造化文書１ａ中の処理対象とするノードより下位のノードについて、操作対象とするＲＤＢ２内のテーブルとの対応付けを定義している。例えば、データ更新定義３ａは、入力された構造化文書１ａ中の処理対象とするノードより下位のノードを相対的に指示するルート情報と、そのルート情報により指示されたノードごとに、操作対象とするＲＤＢ２内のテーブルに含まれるテーブル名、カラム名、カラムのデータ型等のメタデータを対応付けたテーブル対応付け情報とを含んでいる。このようなデータ更新定義３ａを用いることで、構造化文書１ａ中においてルート情報により指示された各ノードに対して、テーブル関連付け情報に基づいてテーブルの各メタデータとが関連付けられ、各ノードから抽出した要素内容や属性値のＲＤＢ２における格納対象を特定することが可能となる。

また、上記のルート情報とテーブル対応付け情報とからなる定義を更新対象要素定義とすると、データ更新定義３ａには、複数の更新対象要素定義を記述することができ、かつ各更新対象要素定義には、すべての更新対象要素定義を再帰的に呼び出すための再帰呼び出し情報を記述することが可能となっている。更新対象要素定義を再帰的に呼び出して処理することにより、構造化文書１ａの深い階層に記述された要素からデータを抽出し、ＲＤＢ２内のテーブルに対してデータ操作を行う処理を効率的に行うことが可能となる。

一方、データ参照定義３ａには、出力される構造化文書１ｂの全体あるいは一部の構造に対応するテンプレートと、このテンプレートのインスタンス化の際に抽出対象とするＲＤＢ２上のパラメータとを含む参照対象テーブル定義が、１つ以上記述される。各テンプレートには、復元される構造化文書１ｂの構造が直接記述され、例えば、ＲＤＢ２から得られるレコードのうちの抽出対象とするカラムの値と、構造化文書１ｂ中の置換すべき要素内容または属性値とが対応付けられている。また、各テンプレートをインスタンス化する際のＲＤＢ２上の抽出対象についての情報が、パラメータにより記述される。

さらに、各参照対象テーブル定義には、他の参照対象テーブル定義の呼び出しを指定することも可能となっている。このような参照テーブル定義に従って処理を実行すると、指定された他の参照対象テーブル定義を呼び出して再帰的に処理することができ、ＲＤＢ２内の指定されたテーブルから抽出したデータを用いて、出力する構造化文書１ｂを復元する処理を効率的に行うことが可能となる。

次に、上記のデータ構造変換装置における基本的な処理について説明する。
〔データ更新処理〕
まず、ＲＤＢ２に対してデータを格納する処理について、図中のステップ番号に従って説明する。

構造化文書１ａが入力されると、まず、これに対応するデータ更新定義３ａを取得する更新定義取得ステップＳ１を実行する。そして、取得したデータ更新定義３ａに従って、データ更新ステップＳ２を実行する。

データ更新ステップＳ２では、ステップＳ２−１において、入力された構造化文書１ａ中のルートノードを処理対象に設定する。そして、ステップＳ２−２において、ステップＳ２−１で処理対象に設定されたノードを起点にして、取得したデータ更新定義３ａによって指示されるノードから繰り返し要素を抽出する。ここでは、構造化文書１ａのルートノードより１つ下位のノードから、データ更新定義３ａの各更新対象要素定義のルート情報にマッチする繰り返し要素がすべて抽出される。そして、ステップＳ２−３〜Ｓ２−６のループ処理が実行される。

ステップＳ２−３では、ステップＳ２−２で繰り返し要素として抽出されたノードごとに、ＲＤＢ２上のテーブルに対応付けられた要素内容または属性値を、入力された構造化文書１ａから抽出する。そして、抽出された要素内容または属性値が、テーブル対応付け情報により対応付けられたテーブルに格納されるように、ＲＤＢ２に対する操作要求を発行する。これにより、構造化文書１ａの該当するノードから抽出された数値や文字列が、ＲＤＢ２上の対応するテーブルに格納される。

ここで、ステップＳ２−４において、ステップＳ２−３で処理中に下位ノードからの繰り返し要素の抽出が指定されているか否かを判断する。この判断は、ステップＳ２−２および２−３で用いられていた更新対象要素定義において再帰呼び出し情報が記述されているか否かによって行われ、再帰呼び出し情報が指定されていた場合のみ、ステップＳ２−５に進む。ステップＳ２−５では、ステップＳ２−３で抽出されていたノードを新たに処理対象として設定し、データ更新定義３ａを再び適用してステップＳ２−２〜Ｓ２−６の処理を実行する。これにより、構造化文書１ａのより下位のノードから、各更新対象要素定義のルート情報にマッチする繰り返し要素がすべて抽出され、その要素内容や属性値がテーブル対応付け情報に基づくテーブルに格納される。構造化文書１ａの階層が深い場合は、このような再帰的な処理が繰り返されることで、各階層から要素内容や属性値が順次抽出され、対応するテーブルのカラムに格納される。

また、ステップＳ２−３〜Ｓ２−６までのループ処理は、ステップＳ２−２において抽出された繰り返し要素のすべてに対する処理が終了するまで続けられる。これにより、構造化文書１ａに含まれるすべてのデータが抽出されて、ＲＤＢ２に格納される。

なお、構造化文書１ａの入力を受けて、ＲＤＢ２内のデータを削除する場合には、ステップＳ２−２の処理の後に、まず繰り返し要素抽出の指定に対する判断（ステップＳ２−４に該当）を行って、より下位の階層に対する処理を実行した後に、上位のデータ抽出およびテーブル更新（ここでは削除）要求を行う処理（ステップＳ２−３に該当）を実行する。これにより、テーブルの下位レコードから順にデータの削除が行われる。データ削除処理では、構造化文書１ａからの抽出値により、プライマリキーとされたカラムの値を指定して、対応するレコードを削除する。

また、ＲＤＢ２内のデータを更新する場合には、まず該当するレコードの削除を行った後に、あらためてデータの格納処理を行えばよい。
〔データ参照処理〕
次に、ＲＤＢ２のデータを参照して構造化文書１ｂを復元する処理について説明する。

まず、検索条件入力ステップＳ３を実行し、ユーザから検索条件が入力される。検索条件としては、データ参照定義３ｂ中の参照対象テーブル定義において記述されたパラメータを指定する情報とその値、および、最初に適用する参照対象テーブル定義を指定する情報が入力される。

次に、参照定義取得ステップＳ４により、データ参照定義３ｂを取得し、テンプレート置換ステップＳ５を実行する。テンプレート置換ステップＳ５では、ステップＳ５−１〜Ｓ５−５のループ処理が実行される。

ステップＳ５−１において、入力された検索条件と、取得したデータ参照定義３ｂ中の参照対象テーブル定義とに基づいて、ＲＤＢ２に対して問い合わせを発行する。ここではまず、検索条件により指定された参照対象テーブル定義を適用して、これに記述されたパラメータと入力された検索条件とから、抽出対象とするＲＤＢ２上のテーブルとパラメータを指定し、問い合わせを発行する。

この問い合わせに対する結果がＲＤＢ２から出力されると、ステップＳ５−２において、問い合わせの結果を用いて参照対象テーブル定義中のテンプレートをインスタンス化する。テンプレートでは、ＲＤＢ２から得られるレコードのうち抽出対象とするテーブルのカラムと、復元する構造化文書１ｂ中の要素内容や属性値とが対応付けられているので、得られたレコードによりテンプレートの対応する要素内容や属性値が置換され、構造化文書１ｂが順次復元される。

ここで、ステップＳ５−３において、ステップＳ５−２で用いられた参照対象テーブル定義中に、他の参照対象テーブル定義の呼び出しが指定されているか否かを判断し、指定されていた場合のみステップＳ５−４に進む。ステップＳ５−４では、呼び出された参照対象テーブル定義に従って、ステップＳ５−１〜Ｓ５−５の処理を実行する。これにより、ＲＤＢ２から抽出したデータを用いて各テンプレートで指定された要素内容や属性が順次インスタンス化される。テンプレートには、出力する構造化文書１ｂの全体または一部がそのまま記述されるので、このような処理により構造化文書１ｂの要素配列を効率的に復元していくことができる。

以上の処理により、入力された構造化文書１ａの各階層からデータを抽出し、ＲＤＢ２内のテーブルに対してデータ操作する処理、および、これらのテーブルからレコードを抽出し、テンプレートをインスタンス化して構造化文書１ｂを復元する処理を効率化することができる。データ参照定義３ａおよびデータ更新定義３ｂにおいて、指定したテーブルおよびそのカラムと入出力対象の構造化文書１ａおよび１ｂの属性および要素とが対応付けられるので、例えば、ＲＤＢ２が正規化により階層構造をなすテーブルから構成されている場合等、ＲＤＢ２のテーブル構造が複雑な場合や、入出力対象の構造化文書１ａおよび１ｂの階層構造が深い場合にも、テーブルと構造化文書との間でデータを容易にマッピングすることができる。

また、上記のデータ構造変換装置では、データ対応定義３を用いてＲＤＢ２の更新処理、およびＲＤＢ２の参照処理が行われるが、これらの処理を行う処理エンジン（例えば、コンピュータ上で実行される処理プログラム）は、データ対応定義３を参照して、これに従って処理を実行するものである。従って、ＲＤＢ２のテーブル構造や、入力される構造化文書１ａ、復元する構造化文書１ｂの各構造が変更された場合は、この変更に応じて使用するデータ対応定義３を変更すればよく、処理エンジン自体を変更する必要はない。また、異なる構造を有する構造化文書１ａが入力される、あるいは異なる構造の構造化文書１ｂを復元する場合には、それらに応じたデータ対応定義３をそれぞれ作成して、共通の処理エンジンに対して適用すればよい。従って、ＲＤＢ２の構造変更や、入出力対象の構造化文書１ａおよび１ｂのバリエーションに応じて、各構造の対応関係と処理手順とを個別のプログラムとして作成していた従来の手法と比較して、仕様変更に対する対応が容易になり、低コストで拡張性の高いＲＤＢシステムを構築することが可能となる。

なお、データ構造変換装置は、ＲＤＢ２に対するデータの更新機能と、ＲＤＢ２を参照して構造化文書１ｂを復元する機能のうち、いずれか一方を備えるようにしてもよい。ＲＤＢ２の更新機能のみ備える場合には、入力される構造化文書１ａとＲＤＢ２の各構造に応じた１種類以上のデータ更新定義３ａを用意しておく必要がある。また、同様に、ＲＤＢ２の参照機能のみ備える場合には、ＲＤＢ２と復元する構造化文書１ｂの各構造に応じた１種類以上のデータ参照定義３ｂを用意しておく必要がある。

次に、本発明の具体的な実施の形態例について説明する。
図２は、本発明を適用可能なデータベースサービスシステムのシステム構成を示す図である。

図２に示すデータベースサービスシステムは、データベースサーバ１００と、複数のクライアント２０１〜２０３とが、ネットワーク３００を通じて接続された構成を有している。データベースサーバ１００は、正規化により階層構造をなす複数のテーブルを具備するＲＤＢを備えており、各クライアント２０１〜２０３は、ネットワーク３００を通じて、ＲＤＢに対するデータの格納、削除、修正を行う機能と、ＲＤＢのデータを参照する機能の一方または双方を有している。また、データベースサーバ１００と、各クライアント２０１〜２０３との間では、ＸＭＬ文書によりネットワーク３００を通じたデータのやり取りが行われるものとする。

例えば、ネットワーク３００を通じて電子文書を用いた電子商取引が行われる場合を想定すると、商品の注文を受ける側の企業サーバの一部として設けられたデータベースサーバ１００に対して、クライアント２０１〜２０３からＸＭＬ文書により商品の注文が行われ、データベースサーバ１００には、商品や注文、発送等についての情報が格納される。この場合、データベースサーバ１００側では、受信したＸＭＬ文書の構造を解析してデータを抽出し、対応するテーブルに対する操作ができるようなデータ構造に変換する処理が行われる。また、各クライアント２０１〜２０３は、注文対象となる商品やすでに注文した商品等についての情報をデータベースサーバ１００から抽出して、ＸＭＬ文書として受け取ることができる。この場合、データベースサーバ１００側では、ＲＤＢから抽出したデータを出力するＸＭＬ文書に格納できるようなデータ構造に変換する処理が行われる。

ここで、各クライアント２０１〜２０３とデータベースサーバ１００との間で送受信されるＸＭＬ文書の構造が統一されていない場合が考えられる。例えば、各クライアント２０１〜２０３の側において、注文した商品や過去の取引等のデータを格納した独自のデータベースが使用されている場合に、構造の異なるこれらのデータベースの形式に合致した階層構造を有するＸＭＬ文書がそれぞれ使用されることが考えられる。また、各クライアント２０１〜２０３の側で、データベースサーバ１００内の同一ＲＤＢに対して操作や参照の必要なテーブルやカラムが異なる場合には、入出力されるＸＭＬ文書の構造もそれぞれ異なることになる。さらに、これらのＸＭＬ文書の構造や、データベースサーバ１００のテーブル構造が変更される場合も考えられる。このような場合に対して、本発明を適用することにより、データベースサーバ１００側における上記のようなデータ構造変換機能を柔軟に対応させ、その拡張性を高めることができる。

図３は、本発明の実施の形態に係るデータベースサーバ１のハードウェア構成例を示す図である。
図３に示すように、データベースサーバ１００は、ＣＰＵ（Central Processing Unit）１０１、ＲＡＭ（Random Access Memory）１０２、ＨＤＤ（Hard Disk Drive）１０３、グラフィック処理部１０４、入力Ｉ／Ｆ（インタフェース）１０５および通信Ｉ／Ｆ１０６によって構成され、これらはバス１０７を介して相互に接続されている。

ＣＰＵ１０１は、データベースサーバ１００全体に対する制御をつかさどる。ＲＡＭ１０２は、ＣＰＵ１０１に実行させるプログラムの少なくとも一部や、このプログラムによる処理に必要な各種データを一時的に記憶する。ＨＤＤ１０３には、ＯＳ（Operating System）やアプリケーションプログラム、各種データが格納される。

グラフィック処理部１０４には、モニタ１０４ａが接続されている。このグラフィック処理部１０４は、ＣＰＵ１０１からの命令に従って、モニタ１０４ａの画面上に画像を表示させる。入力Ｉ／Ｆ１０５には、キーボード１０５ａやマウス１０５ｂが接続されている。この入力Ｉ／Ｆ１０５は、キーボード１０５ａやマウス１０５ｂからの信号を、バス１０７を介してＣＰＵ１０１に送信する。通信Ｉ／Ｆ１０６は、ネットワーク３００に接続され、このネットワーク３００を介して、クライアント２０１〜２０３等の他のコンピュータとの間でデータの送受信を行う。

以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。
次に、上記のデータベースサーバ１００の処理機能について説明する。

図４は、本発明の実施の形態に係るデータベースサーバ１００の機能を示すブロック図である。
図４に示すように、データベースサーバ１００は、データ構造変換部１１０と、データベース部１２０とから構成されている。データ構造変換部１１０は、ＲＤＢ更新処理部１１１、ＸＭＬ復元処理部１１２、および対応定義記憶部１１３によって構成されている。また、データベース部１２０は、ＲＤＢＭＳ（ＲＤＢ Management System）１２１、およびＲＤＢ１２２によって構成されている。

ＲＤＢ更新処理部１１１は、対応定義記憶部１１３に記憶されたＸＭＬ−ＲＤＢ対応定義１３０を参照して、ネットワーク３００を通じて入力されたＸＭＬ文書１４１からデータを抽出し、データベース部１２０にテーブルの内容を更新させるためのＳＱＬ（Structured Query Language）文を発行する。ＸＭＬ復元処理部１１２は、ネットワーク３００を通じてユーザからの要求を受けると、対応定義記憶部１１３に記憶されたＸＭＬ−ＲＤＢ対応定義１３０を参照して、データベース部１２０に問い合わせを行い、その結果を用いてＸＭＬ文書１４２を復元し、ユーザに対して出力する。対応定義記憶部１１３は、入出力対象のＸＭＬ文書１４１および１４２の構造と、データベース部１２０内のＲＤＢ１２２上の対応するテーブルとの対応関係が記述されたＸＭＬ−ＲＤＢ対応定義１３０を１つ以上記憶している。

ＲＤＢＭＳ１２１は、ＲＤＢ１２２を管理する機能を有し、データ構造変換部１１０からのＳＱＬ文を解析して、ＲＤＢ１２２のテーブルを操作する処理や、ＲＤＢ１２２からデータを抽出してデータ構造変換部１１０に出力する処理を行う。

なお、データ構造変換部１１０とデータベース部１２０とを、別のコンピュータ装置に設け、これらの間で通信ケーブルを通じて情報の送受信が行われるようにしてもよい。
ここで、ＸＭＬ−ＲＤＢ対応定義１３０は、入出力対象のＸＭＬ文書１４１および１４２とＲＤＢ１２２の各構造の対応関係が定義されたものであり、実際の処理手順が記述されるものではない。また、ＲＤＢ更新処理部１１１およびＸＭＬ復元処理部１１２は、ＸＭＬ−ＲＤＢ対応定義１３０の記述を解釈し、この記述に応じた処理を行う処理エンジンとして機能する。ＲＤＢ更新処理部１１１およびＸＭＬ復元処理部１１２の処理機能は、実際には、このような処理手順を記述した処理プログラムが、ＣＰＵ１０１によって実行されることにより実現される。

また、例えば、異なる文書構造のＸＭＬ文書１４１および１４２が入出力対象とされた場合には、それらに応じた数だけのＸＭＬ−ＲＤＢ対応定義１３０が対応定義記憶部１１３に用意される。また、ＲＤＢ１２２内のテーブル構造が変更された場合には、すべてのＸＭＬ−ＲＤＢ対応定義１３０が変更される。そして、ＲＤＢ更新処理部１１１では、入力されたＸＭＬ文書１４１に対応するＸＭＬ−ＲＤＢ対応定義１３０を用いて処理が行われ、同様に、ＸＭＬ復元処理部１１２でも、出力されるＸＭＬ文書１４２に対応するＸＭＬ―ＲＤＢ対応定義１３０を用いて処理が行われる。

以下、ＸＭＬ−ＲＤＢ対応定義１３０を、ＸＭＬを用いたテキストデータとして記述した場合を例に挙げて説明する。
図５は、ＸＭＬ−ＲＤＢ対応定義のデータ構造を概略的に示す図である。なお、図５に示すＸＭＬ−ＲＤＢ対応定義では、入出力対象のＸＭＬ文書１４１および１４２と区別するために、すべてのタグが“ｘｒｍ”にバインドされた名称の空間に属するようにしている。

図５に示す１つのＸＭＬ−ＲＤＢ対応定義「ｘｒｍ：ｄｅｆｉｎｉｔｉｏｎｓ」は、ＸＭＬ文書１４１を用いてＲＤＢ１２２を更新する際に使用するデータ更新定義「ｘｒｍ：ｕｐｄａｔｅ−ｄｅｆ」と、ＲＤＢ１２２を参照してＸＭＬ文書１４２を復元する際に使用するデータ参照定義「ｘｒｍ：ｑｕｅｒｙ−ｄｅｆ」のうち、少なくとも一方を具備している。更新時に入力されるＸＭＬ文書１４１と、復元されるＸＭＬ文書１４２の構造が同じ場合には、基本的にデータ更新定義「ｘｒｍ：ｕｐｄａｔｅ−ｄｅｆ」とデータ参照定義「ｘｒｍ：ｑｕｅｒｙ−ｄｅｆ」が１組ずつ記述される。

データ更新定義「ｘｒｍ：ｕｐｄａｔｅ−ｄｅｆ」には、１つ以上の更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」が記述される。更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」では、入力されるＸＭＬ文書１４１とＲＤＢ１２２上のテーブルとの対応が定義されており、その属性として、入力されたＸＭＬ文書１４１中の処理対象としているノード（カレントノードと呼称する）を起点として、その下位ノードから更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」の適用対象とする繰り返しノードを抽出するためのルート情報が、ＸＰａｔｈ式を用いたパス情報として記述される。

更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」には、１つ以上の更新対象テーブル定義「ｘｒｍ：ｔａｂｌｅ」が記述される。また、更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」の要素として、更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」を再帰的に呼び出すための更新対象要素呼び出し「ｘｒｍ：ｃａｌｌ−ｕｐｄａｔｅ」を記述することができる。

更新対象テーブル定義「ｘｒｍ：ｔａｂｌｅ」では、更新対象とするＲＤＢ１２２上のテーブルの情報とそのテーブルが持つカラムの情報が定義されており、その属性としてテーブル名が記述される。更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」内に複数の更新対象テーブル定義「ｘｒｍ：ｔａｂｌｅ」が記述されることにより、パス情報に適合したＸＭＬ文書１４１中のノードに対して、ＲＤＢ１２２上の複数のテーブルを対応付けることが可能となる。

また、更新対象テーブル定義「ｘｒｍ：ｔａｂｌｅ」には、１つ以上の更新対象カラム定義「ｘｒｍ：ｃｏｌｕｍｎ」が記述される。更新対象カラム定義「ｘｒｍ：ｃｏｌｕｍｎ」では、更新対象とするカラムのメタデータ（カラム名、データ型、プライマリキーであるか否かを示す情報）と、カラムへ設定する値の取得元を指定するパス情報が定義される。カラムのメタデータは属性として記述され、パス情報はＸＰａｔｈ式により記述される。また、カラムに設定可能なデータ型としては、単一の数値や文字列の他、ＬＯＢ（Large Object）を適用することも可能となっている。

一方、データ参照定義「ｘｍｌ：ｑｕｅｒｙ−ｄｅｆ」には、１つ以上の参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ」が記述される。参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ」では、参照処理時に発行するＳＱＬ文を構成するために必要な情報として、参照するＲＤＢ１２２上のテーブルの情報や、キーとするパラメータ、復元するＸＭＬ文書１４２のテンプレートが定義される。この参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ」は、属性として、その名前と、発行するＳＱＬ文のＷＨＥＲＥ句を指定するためのパラメータの値（パラメータ付きクエリと呼称する）が１つ以上記述され、その要素には、パラメータリスト「ｘｒｍ：ｐａｒａｍｓ−ｉｎ−ｗｈｅｒｅ」とテンプレート定義「ｘｒｍ：ｔｅｍｐｌａｔｅ」とが１つずつ記述される。

パラメータリスト「ｘｒｍ：ｐａｒａｍｓ−ｉｎ−ｗｈｅｒｅ」では、参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ」において指定されたＷＨＥＲＥ句の各パラメータに値を設定する方法が定義されており、パラメータの数だけパラメータ定義「ｘｒｍ：ｐａｒａｍ」が記述される。パラメータ定義「ｘｒｍ：ｐａｒａｍ」では、ＳＱＬ文を発行する際に指定するパラメータの名前、インデックス、データ型が、それぞれ属性として定義される。

また、テンプレート定義「ｘｒｍ：ｔｅｍｐｌａｔｅ」では、ＲＤＢ１２２に対する問い合わせに応じて得られたレコードごとに、置換すべきＸＭＬ文書１４２中の要素や属性を記述したテンプレートが定義される。従って、テンプレート定義「ｘｒｍ：ｔｅｍｐｌａｔｅ」の内容がインスタンス化されることで、出力するＸＭＬ文書１４２が復元される。テンプレート定義「ｘｒｍ：ｔｅｍｐｌａｔｅ」では、その要素として、テンプレート内の要素に付与する属性や、置換する値の取得元のカラムあるいはパラメータを指定する情報（カラム名、パラメータ名、データ型）を記述することができる。このデータ型としては、単一の数値や文字列の他、ＬＯＢを指定することも可能となっている。

また、テンプレート定義「ｘｒｍ：ｔｅｍｐｌａｔｅ」では、他の参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ」を再帰的に呼び出すための参照対象テーブル呼び出し「ｘｒｍ：ｃａｌｌ−ｑｕｅｒｙ」を１つだけ記述することもできる。参照対象テーブル呼び出し「ｘｒｍ：ｃａｌｌ−ｑｕｅｒｙ」では、呼び出す参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ」の名前が、属性として指定される。

なお、以下の説明では、ＸＭＬ−ＲＤＢ対応定義「ｘｒｍ：ｄｅｆｉｎｉｔｉｏｎｓ」中に、更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」、更新対象テーブル定義「ｘｒｍ：ｔａｂｌｅ」、更新対象カラム定義「ｘｒｍ：ｃｏｌｕｍｎ」、参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ」、パラメータ定義「ｘｒｍ：ｐａｒａｍ」が記述される個数を、それぞれＵＥ、ＵＴ、ＵＣ、ＱＴ、ＱＰと表すことにする。

次に、ＲＤＢ更新処理部１１１におけるＸＭＬ−ＲＤＢ対応定義を用いたＲＤＢ１２２に対するデータ更新処理の流れについて説明する。はじめに、ＲＤＢ１２２に対するデータの格納および削除の処理について、フローチャートを用いて説明する。

図６は、ＲＤＢ１２２に対するデータの格納および削除を行う際の更新定義適用処理の全体の流れを示すフローチャートである。
図６の処理は、ネットワーク３００を通じて、ＲＤＢ更新処理部１１１に対してＸＭＬ文書１４１が入力されると、開始される。このとき、入力されたＸＭＬ文書１４１に応じたＸＭＬ−ＲＤＢ対応定義が指定されて、これを随時参照しながら処理が実行される。また、ＸＭＬ文書１４１とともに、引数として格納処理または削除処理を指定するフラグが入力される。

ステップＳ６０１〜Ｓ６０５のメインループでは、データ更新定義「ｘｒｍ：ｕｐｄａｔｅ−ｄｅｆ」に記述された更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」の数（ＵＥ）だけ繰り返し実行される。すなわち、記述された更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」をそれぞれ順次適用して、ステップＳ６０１〜Ｓ６０５の処理を繰り返し実行する。

ステップＳ６０２において、データの格納処理と削除処理のどちらが指定されているか判定する。格納処理が指定されている場合は、ステップＳ６０３に進み、データを格納するための更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」の適用処理（図７に記述）を実行する。また、削除処理が指定されている場合は、ステップＳ６０４に進み、データを削除するための更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」の適用処理（図９に記述）を実行する。

図７は、データを格納するための更新対象要素定義適用処理（図６のステップＳ６０３に対応）の流れを示すフローチャートである。
ステップＳ７０１では、カレントノードを起点として、その子要素の中から、更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」の属性（後述する「ｆｏｒ−ｅａｃｈ」）に記述されたパス情報に適合する要素の配列を抽出する。初期状態では、カレントノードは、入力されたＸＭＬ文書１４１のルートノードに設定される。また、抽出された要素数をＮに設定する。

ステップＳ７０２〜Ｓ７０８のループは、パス情報に適合した要素配列のそれぞれに対して順次実行される。さらに、ステップＳ７０３〜Ｓ７０５のループでは、適合した要素配列に対して、適用中の更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」に記述された更新対象テーブル定義「ｘｒｍ：ｔａｂｌｅ」を順次適用して、ステップＳ７０４のデータ格納のための更新対象テーブル定義適用処理を繰り返し実行する。すなわち、ステップＳ７０４の処理は、適用中の更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」に記述された更新対象テーブル定義「ｘｒｍ：ｔａｂｌｅ」の数（ＵＴ）だけ繰り返し実行される。

次に、ステップＳ７０６では、適用中の更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」の中に、更新対象要素呼び出し「ｘｒｍ：ｃａｌｌ−ｕｐｄａｔｅ」があるか否かを判断し、ある場合はステップＳ７０７に進み、ない場合はステップＳ７０８のループ終端に進む。

ステップＳ７０７では、更新対象要素呼び出し「ｘｒｍ：ｃａｌｌ−ｕｐｄａｔｅ」に基づいて、図６に示した更新定義適用（格納）処理（ステップＳ６０１〜Ｓ６０３，Ｓ６０５）を再帰的に実行する。この処理では、Ｓ７０２〜Ｓ７０８のループでパス情報に適合するとして抽出されている要素をカレントノードに設定（ステップＳ７０１に対応）して、これらにすべての更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」を順次適用する。これにより、入力されたＸＭＬ文書１４１中のさらなる下位ノードから、更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」のパス情報に適合する要素が抽出されて、処理が実行される。処理の終了後、ステップＳ７０８のループ終端に進む。

次に、図８は、データを格納する際の更新対象テーブル定義適用処理（図７のステップＳ７０４に対応）の流れを示すフローチャートである。
図８に示す更新対象テーブル定義適用処理では、更新対象テーブル定義「ｘｒｍ：ｔａｂｌｅ」のそれぞれを適用して、ＸＭＬ文書１４１中の要素または属性の値を、対応するＲＤＢ１２２上のテーブルに格納するためのＳＱＬ文を、データベース部１２０に対して発行する。

ステップＳ８０１では、まず、発行するＳＱＬ文として、命令“ＩＮＳＥＲＴ ＩＮＴＯ”と、その対象として、更新対象テーブル定義「ｘｒｍ：ｔａｂｌｅ」の属性に記述されたテーブル名とを記述する。

ステップＳ８０２〜Ｓ８０４のループでは、更新対象テーブル定義「ｘｒｍ：ｔａｂｌｅ」の要素に記述された更新対象カラム定義「ｘｒｍ：ｃｏｌｕｍｎ」のそれぞれの属性からカラム名を順次抽出して、ステップＳ８０１で記述したＳＱＬ文に順次追加する。なお、ステップＳ８０３では、更新対象カラム定義「ｘｒｍ：ｃｏｌｕｍｎ」が複数記述されていた場合には、元のＳＱＬ文に“，”を追加後、カラム名を追加する。

そして、ステップＳ８０５では、生成されたＳＱＬ文に、カラムに格納すべきデータを指定するための予約語を記述する。具体的には、“）ＶＡＬＵＥＳ（”と追加する。
ステップＳ８０６〜Ｓ８１２のループは、更新対象テーブル定義「ｘｒｍ：ｔａｂｌｅ」の要素に記述された更新対象カラム定義「ｘｒｍ：ｃｏｌｕｍｎ」の数（ＵＣ）だけ実行される。

ステップＳ８０７では、処理中の更新対象カラム定義「ｘｒｍ：ｃｏｌｕｍｎ」の要素内容（「ｘｒｍ：ｆｒｏｍ−ｘｐａｔｈ」とする）に記述された値取得元のパス情報（後述する属性「ｘｐａｔｈ」）に基づいて、その要素を起点に値取得元をＸＭＬ文書１４１から特定し、テーブルに設定する設定値とする。

ステップＳ８０８では、処理中の更新対象カラム定義「ｘｒｍ：ｃｏｌｕｍｎ」の属性から、カラムに格納するデータ型を判断し、ＬＯＢが指定されていた場合にはステップＳ８０９に進み、それ以外が指定されていた場合にはステップＳ８１０に進む。

ステップＳ８０９では、ステップＳ８０７で設定した設定値をその要素配下のサブツリーとし、設定値が例えばプログラムや画像・音声データ等の場合はバイナリデータ（ＢＬＯＢの場合、ＢＬＯＢ：Binary ＬＯＢ）に、例えばＸＭＬ文書の要素配列等の場合は文字列（ＣＬＯＢの場合、ＣＬＯＢ：Character ＬＯＢ）にシリアライズする。また、ステップＳ８１０では、ステップＳ８０７で設定した設定値を文字列として評価し、データ型に応じた編集を行う。そして、ステップＳ８１１において、設定値をＳＱＬ文に追加し、１つの更新対象カラム定義「ｘｒｍ：ｃｏｌｕｍｎ」を適用した処理が終了する。

ステップＳ８１３において、予約語“ＶＡＬＵＥＳ”の句を終端させてＳＱＬ文を完成させ、ステップＳ８１４において、このＳＱＬ文をデータベース部１２０に発行する。これにより、１つのノードに対して１つの更新対象テーブル定義「ｘｒｍ：ｔａｂｌｅ」を適用したテーブルへのデータ格納が行われる。

そして、以上の処理が、記述された更新対象テーブル定義「ｘｒｍ：ｔａｂｌｅ」の数（ＵＴ）だけ実行され（ステップＳ７０３〜Ｓ７０５）、さらにこれらの処理が、カレントノード配下の適合ノードに対してそれぞれ実行され（ステップＳ７０２〜Ｓ７０８）、さらにこれらの処理が、すべての更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」を順次適用して実行される（ステップＳ６０１〜Ｓ６０３，Ｓ６０５）。これにより、ＸＭＬ文書１４１のすべてのノードに対して更新対象要素定義「ｘｍｌ：ｕｐｄａｔｅ」が適用されて、すべてのデータが抽出され、ＲＤＢ１２２内に格納される。

例えば、ＸＭＬ文書の階層構造が深い場合には、更新対象要素呼び出し「ｘｒｍ：ｃａｌｌ−ｕｐｄａｔｅ」を用いた再帰処理の回数が増加していくことになり、ＲＤＢ１２２側のテーブルの階層が深い等、テーブル構造が複雑な場合には、各更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」に記述される更新対象テーブル定義「ｘｒｍ：ｔａｂｌｅ」の数が増加することになる。

次に、ＲＤＢ１２２内のデータを削除する場合の処理について説明する。図９は、データを削除するための更新対象要素定義適用処理（図６のステップＳ６０４に対応）の流れを示すフローチャートである。

上述したデータを格納する処理では、更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」の適用時に、まず上位のノードに対して更新対象テーブル定義「ｘｒｍ：ｔａｂｌｅ」を順次適用し、その後に更新対象要素呼び出し「ｘｒｍ：ｃａｌｌ−ｕｐｄａｔｅ」に基づいて再帰的な処理を行うことで、ＲＤＢ１２２上では親側のレコードからデータが格納されていた。これに対し、データを削除する場合には、更新対象要素呼び出し「ｘｒｍ：ｃａｌｌ−ｕｐｄａｔｅ」を先に適用することにより、子側のレコードからデータの削除を行っていく。

ステップＳ９０１では、カレントノードを起点として、その子要素の中から、更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」の属性（後述する「ｆｏｒ−ｅａｃｈ」）に記述されたパス情報に適合する要素の配列を抽出する。初期状態では、カレントノードは、入力されたＸＭＬ文書１４１のルートノードに設定される。また、抽出された要素数をＮに設定する。

ステップＳ９０２〜Ｓ９０８のループは、パス情報に適合した要素配列のそれぞれに対して順次実行される。ここで、更新対象テーブル定義「ｘｒｍ：ｔａｂｌｅ」の適用の前に、ステップＳ９０３において、更新対象要素呼び出し「ｘｒｍ：ｃａｌｌ−ｕｐｄａｔｅ」が記述されているか否かを判断する。記述されている場合はステップＳ９０４に進み、記述されていない場合はステップＳ９０５に進む。

ステップＳ９０４では、図６に示した更新定義適用（削除）処理（ステップＳ６０１〜Ｓ６０２、Ｓ６０４〜Ｓ６０５）を再帰的に実行する。この処理では、Ｓ９０２〜Ｓ９０８のループで抽出されている要素をカレントノードに設定（ステップＳ９０１に対応）して、これらにすべての更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」を順次適用する。これにより、入力されたＸＭＬ文書１４１中のさらなる下位ノードから、更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」のパス情報に適合する要素が抽出されて、処理が実行される。処理の終了後、ステップＳ９０５に進む。

ステップＳ９０５〜Ｓ９０７のループでは、ステップＳ９０１でパス情報に適合した要素配列に対して、更新対象テーブル定義「ｘｒｍ：ｔａｂｌｅ」を順次適用して、ステップＳ９０６のデータ削除のための更新対象テーブル定義適用処理を繰り返し実行する。すなわち、ステップＳ９０６の処理は、適用中の更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」に記述された更新対象テーブル定義「ｘｒｍ：ｔａｂｌｅ」の数（ＵＴ）だけ繰り返し実行され、処理終了後に、ステップＳ９０８のループ終端に進む。

次に、図１０は、データを削除する際の更新対象テーブル定義適用処理（ステップＳ９０６に対応）の流れを示すフローチャートである。
図１０示す更新対象テーブル定義適用処理では、更新対象テーブル定義「ｘｒｍ：ｔａｂｌｅ」のそれぞれを適用して、ＸＭＬ文書１４１中の要素または属性に対応するＲＤＢ１２２上のレコードを削除するためのＳＱＬ文を、データベース部１２０に対して発行する。

ステップＳ１００１では、発行するＳＱＬ文として、命令“ＤＥＲＥＴＥ ＦＲＯＭ”を記述し、その対象として、更新対象テーブル定義「ｘｒｍ：ｔａｂｌｅ」の属性に記述されたテーブル名を追加し、さらに削除対象のレコードを指定するための“ＷＨＥＲＥ”を追加する。

ステップＳ１００２〜Ｓ１００６のループは、更新対象テーブル定義「ｘｒｍ：ｔａｂｌｅ」の要素に記述された更新対象カラム定義「ｘｒｍ：ｃｏｌｕｍｎ」の数（ＵＣ）だけ実行される。

ステップＳ１００３では、更新対象とするカラムの名前を更新対象カラム定義「ｘｒｍ：ｃｏｌｕｍｎ」から取得し、その属性からこのカラム名がプライマリキーであるか否かを判断する。プライマリキーである場合はステップＳ１００４に進み、そうでない場合はステップＳ１００６のループ終端に進む。データを削除する場合は、テーブルのメタデータのうちプライマリキーとその値を利用することにより、削除するレコードの条件を指定する。

ステップＳ１００４では、処理中の更新対象カラム定義「ｘｒｍ：ｃｏｌｕｍｎ」の要素内容（「ｘｒｍ：ｆｒｏｍ−ｘｐａｔｈ」）に記述された値取得元のパス情報（後述する属性「ｘｐａｔｈ」）に基づいて、その要素を起点に値取得元をＸＭＬ文書１４１から特定し、テーブルに設定する設定値とする。そして、その設定値を文字列として評価し、指定されたデータ型に応じた編集を行う。

ステップＳ１００５では、ＳＱＬ文に、更新対象カラム定義「ｘｒｍ：ｃｏｌｕｍｎ」の属性で指定されたカラム名を追加し、さらにステップＳ１００４で編集された設定値を追加する。これにより、プライマリキーで指定されたカラムに関係するレコードをすべて削除するＳＱＬ文が生成される。なお、ステップＳ１００５では、更新対象カラム定義「ｘｒｍ：ｃｏｌｕｍｎ」が複数記述されていた場合には、元のＳＱＬ文に“ＡＮＤ”を追加後、設定値を追加する。

そして、ステップＳ１００２〜Ｓ１００６の処理がすべての更新対象カラム定義「ｘｒｍ：ｃｏｌｕｍｎ」について実行された後、ステップＳ１００７において、生成されたＳＱＬ文をデータベース部１２０に対して発行する。以上の処理により、“ＷＨＥＲＥ”句で指定されたレコードが削除される。

なお、データの削除を行う場合には、削除したいＸＭＬ文書の識別等を含む条件を指定することも可能である。この場合は、後述するデータ参照処理により、該当するＸＭＬ文書を一旦抽出し、そのＸＭＬ文書を上記のデータ削除処理に用いて処理することで、実現される。

また、ＲＤＢ１２２上のデータの修正を行う場合には、該当するＸＭＬ文書を用いて上記のデータ削除処理を行い、テーブル上のレコードを一旦削除した後、新規のデータを記述したＸＭＬ文書を用いてデータ格納処理を行うことで、テーブル上のデータの入れ替えを行うことが可能となる。

次に、ＲＤＢ１２２上のデータを参照してＸＭＬ文書１４２を復元する処理について説明する。図１１は、データ参照処理全体の流れを示すフローチャートである。
ステップＳ１１０１では、最初に適用させる参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ」の名前を識別する情報と、参照対象を指定するためのパラメータの名前およびその値とを受信する。これらの情報は、クライアント２０１〜２０３のいずれかにおいてユーザによって入力され、ネットワーク３００を通じて送信される。

ここで、受信したパラメータ名とその値のペアの集合を、パラメータマップとして保持する。また、最初に適用させる参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ」では、参照対象を指定するパラメータとしてプライマリキーが指定されている必要がある。

ステップＳ１１０２では、ユーザに返却するドキュメント（ＸＭＬ文書１４２）として、空のドキュメントを設定する。
ステップＳ１１０３では、ステップＳ１１０１で指定された参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ」を適用する処理を実行する。

ステップＳ１１０４では、ステップＳ１１０３の処理結果を用いて、返却用ドキュメントを返す。すなわち、復元されたＸＭＬ文書１４２を、ネットワークを通じて送信する。
図１２は、参照対象テーブル適用処理（ステップＳ１１０３に対応）の流れを示すフローチャートである。

ステップＳ１２０１〜Ｓ１２０３のループは、適用する参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ」中のパラメータリスト「ｘｒｍ：ｐａｒａｍｓ−ｉｎ−ｗｈｅｒｅ」に記述されたパラメータ定義「ｘｒｍ：ｐａｒａｍ」の数、すなわち指定されるパラメータ名の数だけ実行される。

ステップＳ１２０２では、各パラメータ定義「ｗｒｍ：ｐａｒａｍ」の属性に記述されたパラメータ名に対応する値をパラメータマップから順次取得し、属性に記述されたデータ型に応じた編集を行う。そして、その結果を、適用中の参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ」の属性に記述されたパラメータ付きクエリに、パラメータ定義「ｗｒｍ：ｐａｒａｍ」中のインデックスを指定して設定する。これにより、ＳＱＬ文の“ＷＨＥＲＥ”句にセットする値が確定する。

そして、ステップＳ１２０４において、適用する参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ」の属性に記述されたテーブル名を参照対象のテーブルとして指定し、さらに、テンプレート定義「ｘｒｍ：ｔｅｍｐｌａｔｅ」で指定されたカラム名を用いて問い合わせのＳＱＬ文を生成し、データベース部１２０に発行する。

この問い合わせの結果、抽出されたレコードを受信すると、ステップＳ１２０５〜Ｓ１２０７のループはそのレコード（結果セット）の数だけ実行される。ステップＳ１２０６では、テンプレート定義「ｘｒｍ：ｔｅｍｐｌａｔｅ」をインスタンス化してＸＭＬ文書１４２を復元するテンプレート復元処理が実行される。従って、このステップＳ１２０６の処理は、テンプレート内の要素内容や属性がすべての結果セットにより置換されるまで繰り返し実行されることになる。

図１３は、テンプレート復元処理（ステップＳ１２０６に対応）の流れを示すフローチャートである。
図１３の処理は、テンプレート定義「ｘｒｍ：ｔｅｍｐｌａｔｅ」中のノードを順に辿って、そのノードの記述に対応する処理を実行していくことにより行われる。従って、ステップＳ１３０１では、適用対象のノードの記述を参照する。そして、そのノードが抽出対象のカラムを指定する要素内容（「ｘｒｍ：ｆｒｏｍ−ｃｏｌｕｍｎ」とする）である場合はステップＳ１３１０に進み、抽出対象のパラメータを指定する要素内容（「ｘｒｍ：ｆｒｏｍ−ｐａｒａｍ」とする）である場合はステップＳ１３１３に進み、参照対象テーブル呼び出し「ｘｒｍ：ｃａｌｌ−ｑｕｅｒｙ」である場合はステップＳ１３１４に進み、それ以外である場合はステップＳ１３０２に進む。

ステップＳ１３０２では、適用対象となっているノードを複写して、結果格納用ノードに追加する。ここで、結果格納用ノードは、復元されるＸＭＬ文書１４２中の１つのノードを構成する。

ステップＳ１３０３では、適用対象のノードの種類を判定し、要素が記述されていた場合はステップＳ１３０４に進む。また、テキストノードであれば、このテキストデータがＸＭＬ文書１４２にそのまま記述されるため、処理を終了する。

ステップＳ１３０４では、適用対象ノードの子ノードを参照し、ステップＳ１３０４〜Ｓ１３０９のループをその子ノードの数だけ実行する。初期状態では、抽出したうちの最初の子ノードを適用対象とする。

ステップＳ１３０５では、適用対象とした子ノードが、復元するＸＭＬ文書１４２の対象要素の属性を指定するための属性指定の要素（後述する「ｘｒｍ：ａｔｔｒｉｂｕｔｅ」）であるか否かを判断し、属性指定である場合はステップＳ１３０６に進み、そうでない場合はステップＳ１３０８に進む。

ステップＳ１３０６では、ステップＳ１３０２で追加された結果格納用ノードの対象要素に、データを格納すべき属性を追加する。そして、ステップＳ１３０７では、そのノードの要素内容に従って、図１３に示すテンプレート復元処理を再帰的に実行する。実行後にステップＳ１３０９のループ終端に進む。

一方、適用対象のノードが属性指定でない場合は、ステップＳ１３０８において、そのノードの要素内容に従って、図１３に示すテンプレート復元処理を再帰的に実行し、実行後にステップＳ１３０９のループ終端に進む。

また、ステップＳ１３１０では、抽出対象のカラムを指定する要素内容（「ｘｒｍ：ｆｒｏｍ−ｃｏｌｕｍｎ」）に基づき、指定されたカラムからの抽出値で置換される要素内容または属性のデータ型を判断する。データ型としてＬＯＢが指定されていた場合にはステップＳ１３１１に進み、それ以外（例えば単一の数値や文字列）が指定されていた場合はステップＳ１３１２に進む。

ステップＳ１３１１では、抽出対象のカラムを指定する要素内容「ｘｒｍ：ｆｒｏｍ−ｃｏｌｕｍｎ」に基づき、指定されたカラム名に対応するデータを結果セットから１つ取得して、テンプレートに基づくＸＭＬ文書の要素としてパースし、結果格納用ノードに追加する。ここで、取得されるデータは、例えば、ＸＭＬ文書の要素配列等を示すテキストデータ（ＣＬＯＢの場合）や、プログラムや画像・音声データ等のバイナリデータ（ＢＬＯＢの場合）等が適用される。

一方、ステップＳ１３１２では、抽出対象のカラムを指定する要素内容「ｘｒｍ：ｆｒｏｍ−ｃｏｌｕｍｎ」に基づき、指定されたカラム名に対応するデータを結果セットから取得して、テキストノードに変換し、結果格納用ノードに追加する。

また、ステップＳ１３１３では、抽出対象のパラメータを指定する要素内容（「ｘｒｍ：ｆｒｏｍ−ｐａｒａｍ」）に基づき、指定されたパラメータ名に対応するデータを結果セットから１つ取得して、結果格納用ノードに追加する。

また、ステップＳ１３１４では、そのノードに記述された参照対象テーブル呼び出し「ｘｒｍ：ｃａｌｌ−ｑｕｅｒｙ」に基づき、指定された参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ」を適用して、図１２に示した処理を再帰的に実行する。これにより、指定された参照テーブル定義「ｘｒｍ：ｑｕｅｒｙ」に記述されたテンプレートがインスタンス化され、ＸＭＬ文書１４２の一部が復元される。

ここで、ステップＳ１３０７およびＳ１３０８の再帰処理について補足説明する。これらのステップでは、抽出対象とするテーブル上のカラムまたはパラメータを指定する要素内容（「ｘｒｍ：ｆｒｏｍ−ｃｏｌｕｍｎ」または「ｘｒｍ：ｆｒｏｍ−ｐａｒａｍ」）に基づいて、テンプレート中の適用対象ノードの属性または要素内容に対して、インスタンス化する処理が実行される。このため、この処理では、実際には、ステップＳ１３０１の判断で、ステップＳ１３１０またはＳ１３１３に続く処理が実行されることになる。

従って、図１３の処理の繰り返しにより、ＲＤＢ１２２から受信した結果セットを用いて、参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ」に記述されたテンプレートがインスタンス化され、参照対象テーブル呼び出し「ｘｒｍ：ｃａｌｌ−ｑｕｅｒｙ」が記述されていた場合には、これにより指定された別の参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ」を適用する処理が実行されていくことで、すべてのテンプレートがインスタンス化されて、ＸＭＬ文書１４２が復元されることになる。

例えば、テンプレートに記述されたＸＭＬ文書の階層構造が深い場合には、ステップＳ１３０８を経て、再びステップＳ１３０４〜Ｓ１３０９のループに至る処理が複数回繰り返されることになり、ＲＤＢ１２２のテーブル階層が深い等、テーブル構造が複雑な場合には、例えばステップＳ１３１４によって参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ」の再帰処理回数が増加することになる。

次に、入出力対象のＸＭＬ文書とＲＤＢ１２２のテーブル構造、およびこれに適用されるＸＭＬ−ＲＤＢ対応定義の例を具体的に挙げて、データベースサーバ１００の具体的な動作例について説明する。なお、以下の例では、入力されるＸＭＬ文書１４１と、出力されるＸＭＬ文書１４２の各構造が同一である場合を想定する。

図１４は、実施例１に係るＸＭＬ文書とＲＤＢ１２２の構造を示す図である。
図１４（Ａ）に示すＸＭＬ文書は、“会社”要素の下位ノードに、“名称”“部署”の各要素が記述され、さらに“部署”要素の下位ノードに“名称”要素が記述された階層構造を有している。また、図１４（Ｂ）に示すＲＤＢ１２２は、“会社コード”“会社名”の２つのカラムを持つ会社テーブルと、“会社コード”“部署コード”“部署名”の３つのカラムを持つ部署テーブルとからなり、会社テーブル：部署テーブルが１：ｎの階層構造を有している。なお、“会社コード”“部署コード”のそれぞれがプライマリキー（ＰＫ）に指定されている。

図１５は、図１４のＸＭＬ文書およびＲＤＢ１２２に対して適用されるＸＭＬ−ＲＤＢ対応定義「ｘｒｍ：ｄｅｆｉｎｉｔｉｏｎｓ」のコード例を示す図である。
図１５に示すＸＭＬ−ＲＤＢ対応定義「ｘｒｍ：ｄｅｆｉｎｉｔｉｏｎｓ」では、第２行〜第２２行にデータ更新定義「ｘｒｍ：ｕｐｄａｔｅ−ｄｅｆ」、第２３行〜第４９行にデータ参照定義「ｘｒｍ：ｑｕｅｒｙ−ｄｅｆ」がそれぞれ記述されている。また、データ更新定義「ｘｒｍ：ｕｐｄａｔｅ−ｄｅｆ」には、第３行〜第１１行、および第１２行〜第２１行の２つの更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」が記述されている。また、“ｆｏｒ−ｅａｃｈ”属性として“会社”が記述された１つ目の更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」の要素として、更新対象要素呼び出し「ｘｒｍ：ｃａｌｌ−ｕｐｄａｔｅ」が記述されている。

一方、データ参照定義「ｘｒｍ：ｑｕｅｒｙ−ｄｅｆ」では、第２４行〜第３６行、および第３７行〜第４９行の２つの参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ」が記述されている。また、１つ目の参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ」内に定義されたテンプレート定義「ｘｒｍ：ｔｅｍｐｌａｔｅ」の“会社”要素として、参照対象テーブル呼び出し「ｘｒｍ：ｃａｌｌ−ｑｕｅｒｙ」が記述されている。

以下、図１５のＸＭＬ−ＲＤＢ更新定義「ｘｒｍ：ｄｅｆｉｎｉｔｉｏｎｓ」を適用したデータ更新および参照処理について説明する。
図１６、図１７および図１８は、それぞれ、実施例１におけるデータ更新処理を説明するための第１、第２および第３の図である。ここで、図１６〜図１８において、図１４（Ａ）に示したＸＭＬ文書の文書構造を模式的に表し、実施例１におけるデータ更新処理のうち、代表としてデータ格納処理について説明する。なお、これらの説明では、上記の図６〜図８のフローチャートの各ステップに随時対応付けながら説明することにする。

図１４（Ａ）に示したＸＭＬ文書の文書構造は、図１６（Ａ）のように模式的に表すことができる。この図では、ルートノードの下位ノードに「会社」要素が配置され、「会社」要素の属性に「コード」、その下位ノードに「名称」要素と２つの「部署」要素が配置され、さらに「部署」要素の各属性に「コード」、その下位ノードに「名称」要素が配置されていることを示している。

まず、図１６（Ｂ）に示すように、カレントノードをルートノードに設定し、データ更新定義「ｘｒｍ：ｕｐｄａｔｅ−ｄｅｆ」中のうちの１つ目の更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」を適用する（ステップＳ６０１〜Ｓ６０３、Ｓ６０５に対応）。１つ目の更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」の「ｆｏｒ−ｅａｃｈ」属性に記述されたパス情報（ＸＰａｔｈ式「会社」）に適合する要素を、ルートノードの下位ノードから抽出する（ステップＳ７０１に対応）。これにより、更新対象テーブル定義「ｘｒｍ：ｔａｂｌｅ」の適用対象として、「会社」要素が抽出される。

次に、抽出された「会社」要素を起点として、１つ目の更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」の配下にある更新対象テーブル定義「ｘｒｍ：ｔａｂｌｅ」をそれぞれ適用する（ステップＳ７０３〜Ｓ７０５に対応）。記述された２つの更新対象テーブル定義「ｘｒｍ：ｔａｂｌｅ」では、「会社テーブル」内のカラム名「会社コード」「会社名」に対してそれぞれデータを格納するように指示され（ステップＳ８０２〜Ｓ８０４に対応）、これらへの値の取得元として、図１６（Ｃ）に示すように、「会社」要素を起点としたパス情報（ＸＰａｔｈ式「＠コード」「名称」）により「会社」要素の「コード」属性（＠コードと表記）および「名称」要素の要素内容がそれぞれ指定されている。

従って、これらの値取得元から「０１」「会社Ａ」が取得されて、ＳＱＬ文が生成され（ステップＳ８０７〜Ｓ８０８，Ｓ８１０〜Ｓ８１２のループに対応）、データベース部１２０に対して発行される（ステップＳ８１４に対応）。これにより、ＲＤＢ１２２上の会社テーブルに対してデータが格納される。

ここで、更新対象テーブル定義「ｘｒｍ：ｔａｂｌｅ」では、２つの更新対象カラム定義「ｘｒｍ：ｃｏｌｕｍｎ」の後に更新対象要素呼び出し「ｘｒｍ：ｃａｌｌ−ｕｐｄａｔｅ」が記述されていることから、図１７（Ａ）に示すように、カレントノードとなっていたルートノードを例えば一旦スタックに退避し、カレントノードを「会社」要素に設定して、すべての更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」を再び適用する（ステップＳ７０７に対応）。

まず、図１７（Ａ）のように、１つ目の更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」の「ｆｏｒ−ｅａｃｈ」属性に記述されたパス情報（ＸＰａｔｈ式「会社」）に適合する要素を、「会社」の下位ノードから抽出する。ここでは、適合する要素がないことから、次に、図１７（Ｂ）のように、２つ目の更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」が適用され（ステップＳ６０１〜Ｓ６０３，Ｓ６０５の処理を再び実行）、その「ｆｏｒ−ｅａｃｈ」属性に記述されたパス情報（ＸＰａｔｈ式「部署」）に適合する要素を「会社」の下位ノードから抽出する。これにより、２つの「部署」要素が抽出される。

次に、抽出された各要素に対して、同様に、２つ目の更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」に記述された更新対象テーブル定義「ｘｒｍ：ｔａｂｌｅ」をそれぞれ適用する（ステップＳ７０３〜Ｓ７０５のループを２回実行）。まず、１つ目の「部署」要素については、図１８（Ａ）に示すように、「部署テーブル」内のカラム名「会社コード」「部署コード」「部署名」に対してそれぞれデータを格納するように指示し、これらへの値の取得元を、「部署」要素を起点としたパス情報（ＸＰａｔｈ式「．．／＠コード」「＠コード」「名称」）に基づいてそれぞれ「会社」要素の「コード」属性、「部署」要素の「コード」属性、「名称」要素の要素内容として、ＳＱＬ文を発行する。同様に、２つ目の「部署」要素についても、図１８（Ｂ）に示すように、格納先のカラム名と、これらへの値の取得元とが指示され、ＳＱＬ文が発行される。これにより、「部署テーブル」内の２つのレコードに対してデータが格納される。

以上で「会社」要素をカレントノードとした処理が終了し、ルートノードをスタックからＰＯＰして再びカレントノードに設定する。ルートノードをカレントノードとした処理では、図１６（Ｂ）および（Ｃ）に示したように、１つ目の更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」の適用が終了しているため、次に２つ目の更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」が適用される（ルートノードをカレントノードとした場合について、ステップＳ６０１〜Ｓ６０３，Ｓ６０５のループの２回目の実行）。しかし、指定されたパス情報（ＸＰａｔｈ式「部署」）に適合する要素はルートノードの下位ノードには存在しないため、これで入力されたＸＭＬ文書内のすべてのノードからデータが抽出され、ＲＤＢ１２２に格納されたことになる。

次に、図１９および図２０は、それぞれ、実施例１におけるデータ参照処理を説明するための第１および第２の図である。ここで、図１９および図２０において、発行されるＳＱＬ文とその結果セット、テンプレート、復元されるＸＭＬ文書のイメージを対応付けて表し、実施例２におけるデータ参照処理について説明する。なお、これらの説明では、上記の図１１〜図１３のフローチャートの各ステップに随時対応付けながら説明することにする。

まず、ＸＭＬ文書を復元するために、ユーザより、最初の適用する参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ」として定義名“ｑ１”、参照対象とするパラメータとして「会社コード＝０１」が指定されているものとする。ここで、返却用ドキュメントの結果ツリーとして、ルートノードを作成する。そして、ユーザからの入力に基づいて、１つ目の参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ（ｎａｍｅ＝“ｑ１”）」を適用する（ステップＳ１１０３に対応）。

この参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ（ｎａｍｅ＝“ｑ１”）」により、パラメータリスト「ｘｒｍ：ｐａｒａｍｓ−ｉｎ−ｗｈｅｒｅ」で指定された「会社コード」のパラメータに対して、ユーザからの入力値「０１」が設定されて、図１９（Ａ）に示すような問い合わせのＳＱＬ文が発行される（ステップＳ１２０１〜Ｓ１２０４に対応）。このＳＱＬ文への応答として、データベース部１２０の「会社テーブル」からは、図１９（Ｂ）のような１組の結果セットが得られる。

そして、この結果セットを用いて、テンプレート定義「ｘｒｍ：ｔｅｍｐｌａｔｅ」で定義されている図１９（Ｃ）のようなテンプレートが復元される（ステップＳ１２０５〜Ｓ１２０７に対応）。このテンプレートでは、まず属性指定の要素「ｘｒｍ：ａｔｔｒｉｂｕｔｅ」により、「会社」要素の属性を追加して、この属性の値を、「ｘｒｍ：ｆｒｏｍ−ｃｏｌｕｍｎ」で指定されるカラム（会社コード）からの抽出データで置換するように定義されている（ステップＳ１３０２〜Ｓ１３０７に対応。ステップＳ１３０７のサブルーチンではさらにステップＳ１３１０，Ｓ１３１２を実行）。また、「名称」要素の要素内容を、「ｘｒｍ：ｆｒｏｍ−ｃｏｌｕｍｎ」で指定されるカラム（会社名）からの抽出データで置換するように定義されている（ステップＳ１３０２〜Ｓ１３０５，Ｓ１３０８に対応。ステップＳ１３０８のサブルーチンではさらにステップＳ１３１０，Ｓ１３１２を実行）。

これにより、「会社コード＝０１」「会社名＝会社Ａ」の値によりテンプレートがインスタンス化され、図１９（Ｄ）に示すような１つの「会社」要素からなるＸＭＬ文書が復元される。また、このテンプレート内では、「会社」要素の下位ノードに参照対象テーブル呼び出し「ｘｒｍ：ｃａｌｌ−ｑｕｅｒｙ」が記述されているため、その要素を置換するために、指定された参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ（ｎａｍｅ＝“ｑ２”）」が適用される（ステップＳ１３１４に対応）。

参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ（ｎａｍｅ＝“ｑ２”）」に基づき、またパラメータとしては当初設定された「会社コード＝０１」がそのまま使用されて、図２０（Ａ）に示すような問い合わせのＳＱＬ文が発行され、その応答として、データベース部１２０の「部署テーブル」からは、図２０（Ｂ）のような２組の結果セットが得られる。

そして、これらの結果セットを用いて、テンプレート定義「ｘｒｍ：ｔｅｍｐｌａｔｅ」で定義されている図２０（Ｃ）のようなテンプレートが復元される。結果セットが２つ得られているので、各結果セットを用いてテンプレートのインスタンス化がそれぞれ実行され（ステップＳ１２０５〜Ｓ１２０７のループを２度実行）、図２０（Ｄ）に示すような２つの「部署」要素からなるＸＭＬ文書が復元される。

従って、参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ（ｎａｍｅ＝“ｑ１”）」内の参照対象テーブル呼び出し「ｘｒｍ：ｃａｌｌ−ｑｕｅｒｙ」の要素が置換されたことになり、図２０（Ｅ）に示すように、「会社」要素の下位ノードに「名称」要素とともに２つの「部署」要素が記述されたＸＭＬ文書が最終的に復元される。

次に、ＸＭＬ文書とＲＤＢ１２２のそれぞれが他の構造を持つ場合について、実施例２〜４として例示し、それぞれの場合のデータ更新および参照処理について簡単に説明する。

図２１は、実施例２に係るＸＭＬ文書とＲＤＢ１２２の構造を示す図である。
図２１（Ａ）に示すＸＭＬ文書は、“会社”要素の下位ノードに、１つの“名称”要素と２つの“部署”要素が記述され、さらに各“部署”要素の下位ノードに“名称”要素と“社員”要素が記述され、さらに“社員”要素の下位ノードに“指名”要素が記述された階層構造を有している。

また、図２１（Ｂ）に示すＲＤＢ１２２は、“会社コード”“会社名”の２つのカラムを持つ会社テーブルと、“会社コード”“部署コード”“部署名”の３つのカラムを持つ部署テーブルと、“会社コード”“部署コード”“社員番号”“氏名”の４つのカラムを持つ社員テーブルとからなり、会社テーブル：部署テーブルが１：ｎ、部署テーブル：社員テーブルが１：ｎとされた３階層のテーブル構造を有している。なお、“会社コード”“部署コード”“社員番号”のそれぞれがプライマリキー（ＰＫ）に指定されている。

このようなＸＭＬ文書のデータを用いてＲＤＢ１２２を更新する場合には、データ更新定義「ｘｒｍ：ｕｐｄａｔｅ−ｄｅｆ」において、ＸＭＬ文書中の「会社」要素を抽出して会社テーブルに対応付けたもの、「部署」要素を抽出して部署テーブルに対応付けたもの、「社員」要素を抽出して社員テーブルに対応づけたものの３つの更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」を用意する。そして、会社テーブルへのデータ操作後に更新対象要素呼び出し「ｘｒｍ：ｃａｌｌ−ｕｐｄａｔｅ」を指定して、再帰処理により部署テーブルへの対応付けに基づくデータ操作を行い、さらに再帰処理により社員テーブルへの対応付けに基づくデータ操作を行うことで実現される。

一方、データ参照処理を行う場合は、抽出対象として会社テーブル、部署テーブル、社員テーブルをそれぞれ指定してテンプレートを復元する参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ」を用意する。そして、会社テーブルからの抽出データによるインスタンス化処理後に、参照対象テーブル呼び出し「ｘｒｍ：ｃａｌｌ−ｑｕｅｒｙ」を指定して、再帰処理により部署テーブルからの抽出データによるインスタンス化を行い、さらに再帰処理により社員テーブルからの抽出データによるインスタンス化を行うことで、ＸＭＬ文書が復元される。

図２２は、実施例３に係るＸＭＬ文書とＲＤＢ１２２の構造を示す図である。
図２２（Ａ）に示すＸＭＬ文書は、“会社”要素の下位ノードに、１つの“名称”要素と２つの“部署”要素、２つの“売上”要素が記述され、さらに各“部署”要素の下位ノードに“名称”要素が記述された階層構造を有している。

また、図２２（Ｂ）に示すＲＤＢ１２２は、“会社コード”“会社名”の２つのカラムを持つ会社テーブルと、“会社コード”“年度”“売上”の３つのカラムを持つ売上テーブルと、“会社コード”“部署コード”“部署名”の３つのカラムを持つ部署テーブルとからなり、会社テーブル：売上テーブル、および、会社テーブル：部署テーブルがそれぞれ１：ｎとされた２階層のテーブル構造を有している。なお、“会社コード”“年度”“部署コード”のそれぞれがプライマリキー（ＰＫ）に指定されている。

このようなＸＭＬ文書のデータでＲＤＢ１２２を更新する場合には、データ更新定義「ｘｒｍ：ｕｐｄａｔｅ−ｄｅｆ」において、ＸＭＬ文書中の「会社」要素を抽出して会社テーブルに対応付けたもの、「部署」要素を抽出して部署テーブルに対応付けたもの、「売上」要素を抽出して売上テーブルに対応づけたものの３つの更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」を用意する。そして、会社テーブルへのデータ操作後に更新対象要素呼び出し「ｘｒｍ：ｃａｌｌ−ｕｐｄａｔｅ」を指定して、再帰処理により例えば部署テーブルへの対応付けに基づくデータ操作を行い、さらに同じノードについて売上テーブルへの対応付けに基づくデータ操作を行うことで実現される。

一方、データ参照処理を行う場合は、抽出対象として会社テーブル、部署テーブル、売上テーブルをそれぞれ指定してテンプレートを復元する参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ」を用意する。そして、会社テーブルからの抽出データによるインスタンス化処理後に、参照対象テーブル呼び出し「ｘｒｍ：ｃａｌｌ−ｑｕｅｒｙ」を指定して、再帰処理により部署テーブルからの抽出データによるインスタンス化を行う。さらに、テンプレート上の「部署」要素と同じノードに参照対象テーブル呼び出し「ｘｒｍ：ｃａｌｌ−ｑｕｅｒｙ」を指定して、再帰処理により売上テーブルからの抽出データによるインスタンス化を行うことで、「部署」要素と「売上」要素とが同じノードに記述されるＸＭＬ文書が復元される。

図２３は、実施例４に係るＸＭＬ文書とＲＤＢ１２２の構造を示す図である。
図２３（Ａ）に示すＸＭＬ文書は、“会社”要素の下位ノードに、“名称”要素と“会社”要素が記述され、さらに“会社”要素の下位ノードに“名称”要素と２つの“会社”要素が記述され、さらにこれらの各“会社”要素の下位ノードに“名称”要素が記述された入れ子状態の深い階層構造を有している。

また、図２３（Ｂ）に示すＲＤＢ１２２は、“会社コード”“会社名”“親会社コード”の３つのカラムを持つ会社テーブルを有しており、“親会社コード”に対して“会社コード”が指定される構造となっている。なお、“会社コード”がプライマリキー（ＰＫ）に指定されている。

このようなＸＭＬ文書のデータでＲＤＢ１２２を更新する場合には、データ更新定義「ｘｒｍ：ｕｐｄａｔｅ−ｄｅｆ」において、ＸＭＬ文書中の「会社」要素を抽出して会社テーブルに対応付け更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」を１つだけ用意すればよい。この更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」では、ＸＭＬ文書中の「会社」要素にマッチするノードに対して、ＲＤＢ１２２内の「会社コード」のカラムに対して親ノードの属性を対応付け、「会社名」のカラムに対して「名称」要素の内容を対応付ける更新対象テーブル定義「ｘｒｍ：ｔａｂｌｅ」を記述するとともに、更新対象要素呼び出し「ｘｒｍ：ｃａｌｌ−ｕｐｄａｔｅ」を記述しておく。これにより、ＸＭＬ文書中のあるノードを起点に「会社」要素にマッチするノードを抽出してデータ操作を行った後に、再帰処理によりその下位ノードから「会社」要素にマッチするノードを抽出してデータ操作を行う。このような処理の繰り返しにより、ＸＭＬ文書中の各ノードのデータが、会社テーブルの「会社コード」「会社名」の各カラムに対して順次格納されていく。

一方、データ参照処理を行う場合は、抽出対象として会社テーブルを指定してテンプレートを復元する参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ」を用意する。そして、このテンプレート定義「ｘｒｍ：ｔｅｍｐｌａｔｅ」において、「会社」要素の属性や「名称」要素を会社テーブルからのレコードにより置換するように指定した後、「会社」要素の下位ノードに参照対象テーブル呼び出し「ｘｒｍ：ｃａｌｌ−ｑｕｅｒｙ」により同じ参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ」を指定しておく。これにより、再帰処理によりさらに下位ノードの要素に対するインスタンス化が順次行われ、入れ子構造のＸＭＬ文書が復元される。

ところで、上記の各実施例では、ＲＤＢ１２２上のテーブルに対して格納可能なデータ型、あるいはテーブルから抽出してテンプレートを置換することが可能なデータ型として、単一の文字列（“ｖａｒｃｈａｒ”に対応）が指定されていたが、これ以外に、単一の数値（例えば整数値の場合“ｉｎｔｅｇｅｒ”等）を指定することが可能である。さらに、このデータ型としてＬＯＢ（ＢＬＯＢ、ＣＬＯＢ）を指定することも可能である。以下、実施例５として、このようにデータ型としてＬＯＢが指定された場合の例を挙げる。

図２４は、実施例５に係るＸＭＬ文書とＲＤＢ１２２の構造を示す図である。
図２４（Ａ）に示すＸＭＬ文書は、“会社”要素の下位ノードに、“名称”要素と“部署”要素が記述され、さらに“部署”要素の下位ノードに“名称”要素と“社員”要素が記述され、さらに“社員”要素の下位ノードに“氏名”要素が記述された階層構造を有している。

また、図２４（Ｂ）に示すＲＤＢ１２２は、上述した実施例１の場合と基本的に同じであり、“会社コード”“会社名”の２つのカラムを持つ会社テーブルと、“会社コード”“部署コード”“部署情報”の３つのカラムを持つ部署テーブルとを有しており、“会社コード”“部署コード”がプライマリキー（ＰＫ）に指定されている。また、“部署情報”カラムのデータ型としてＬＯＢが指定されている。ここで、ＸＭＬ文書中の“部署”要素に記述された要素配列を、“部署情報”カラムに格納し、また逆に、これらの要素配列によりＸＭＬ文書を復元する場合の処理を想定する。

図２５は、実施例５において適用されるＸＭＬ−ＲＤＢ対応定義のコード例を示す図である。
図２５に示すＸＭＬ−ＲＤＢ対応定義「ｘｒｍ：ｄｅｆｉｎｉｔｉｏｎｓ」の基本的な構成は、部署テーブル内の「部署名」カラムを「部署情報」カラムに変更すれば、図１５に示したものと基本的に同じ構造となっている。ただし、図１５の場合と異なる点は、「ｆｏｒ−ｅａｃｈ」属性に「部署」が設定された更新対象要素定義「ｘｒｍ：ｕｐｄａｔｅ」において、「部署情報」カラムに適用するデータのデータ型として「ｂｌｏｂ」が指定されている点（第１１８行）、および、「ｎａｍｅ＝“ｑ２”」で表される参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ」内のテンプレート定義「ｘｒｍ：ｔｅｍｐｌａｔｅ」において、「部署情報」カラムから抽出するデータのデータ型として「ｂｌｏｂ」が指定されている点（第１４３行）である。

この例ではデータ型として「ｂｌｏｂ」が指定されているため、ＸＭＬ文書からＲＤＢ１２２にデータを格納する場合には、パス情報で指示される抽出元の要素内容（ここでは「部署」要素全体の要素配列）がバイナリデータとしてシリアライズされて（図８のステップＳ８０９に対応）、「部署情報」カラムに格納される。また、ＲＤＢ１２２からデータを抽出してＸＭＬ文書を復元する場合には、“部署情報”カラムからこれらの要素配列をバイナリデータとして抽出し、ＸＭＬ文書として変換した後、テンプレートの値を置換する。

このように、テーブルに格納、またはテーブルから抽出するデータのデータ型としてＬＯＢを設定可能とすることにより、取り扱うことが可能なデータの範囲が広がり、汎用性が高まる。例えば、ＸＭＬ文書により書くことが不可能なプログラムや画像・音声等のファイルを取り扱いの対象とすることが可能となる。

以上の実施例１〜３および５のように、ＲＤＢ１２２が正規化により階層構造をなす複数のテーブルを具備している場合や、ＸＭＬ文書の要素が入れ子構造であるような特殊な階層構造である場合でも、これらに対応したＸＭＬ−ＲＤＢ対象定義を用意しておくだけで、基本的な処理手順を変えることなく、ＸＭＬ文書からの抽出データの格納や、ＸＭＬ文書の復元を実行することが可能となる。また、入出力対象のＸＭＬ文書１４１および１４２の構造や、ＲＤＢ１２２のテーブル構造が変更された場合にも、これらの各構造に対応するＸＭＬ−ＲＤＢ対応定義１３０の記述を変更して、ＲＤＢ更新処理部１１１およびＸＭＬ復元処理部１１２に適用することにより対応することができる。ＸＭＬ−ＲＤＢ対応定義１３０では、ＸＭＬ文書１４１および１４２とＲＤＢ１２２の各構造との間の対応関係のみが定義されており、これを利用するＲＤＢ更新処理部１１１やＸＭＬ復元処理部１１２は常に同一のものが使用される。従って、両者の構造の対応関係と処理手順の双方が記述されたプログラムを、各構造の違いに応じて個別に作成する必要があった従来の手法と比較して、作業の負担を大幅に低減することが可能となり、汎用性が高められる。

また、データ更新処理では、基本的に、ＸＭＬ文書のノードごとにデータを抽出して、ＲＤＢ１２２内の対応付けられたテーブルに対するデータ操作が行われる。そして、同様な処理を再帰的に行うことで、ＸＭＬ文書の全ノードからのデータ抽出を行い、ＲＤＢ１２２に格納していく。従って、操作対象のテーブルやカラムは、データ更新定義「ｘｒｍ：ｕｐｄａｔｅ−ｄｅｆ」での定義に従って順次指定されていくだけなので、テーブル構造に関係なく、常に同じ処理手順をＸＭＬ文書の階層ごとに繰り返していくことでＲＤＢ１２２へのデータ操作が順次行われていくので、効率的なデータ更新処理が実現される。

また、データ参照処理では、１つのデータ参照対象テーブル定義「ｘｒｍ：ｑｕｅｒｙ」によりＲＤＢ１２２上の１つのテーブルから抽出されるデータと、このデータでインスタンス化され得るＸＭＬ文書の全体または一部の要素配列とが対応付けられている。従って、このようなデータ参照テーブル定義「ｘｒｍ：ｑｕｅｒｙ」を更新対象テーブル呼び出し「ｘｒｍ：ｃａｌｌ−ｑｕｅｒｙ」に基づいて順次呼び出し、同様の処理手順を再帰的に実行することにより、ＸＭＬ文書の要素配列が順次復元されていくので、効率的なデータ参照処理が実現される。

（付記１） 構造化文書とリレーショナルデータベースとの間でデータ構造を変換する処理をコンピュータに実行させるデータ構造変換プログラムにおいて、
入力された構造化文書中の処理対象とするノードより下位のノードについて、操作対象とするリレーショナルデータベース内のテーブルとの対応付けを定義したデータ更新定義を取得する更新定義取得ステップと、
入力された前記構造化文書中のルートノードを前記処理対象に設定する第１のステップ、
前記処理対象に設定されたノードを起点にして、前記データ更新定義により指示されるノードから繰り返し要素を抽出する第２のステップ、
前記繰り返し要素として抽出されたノードごとに、前記テーブルに対応付けられた要素内容または属性値を入力された前記構造化文書から抽出して、前記テーブルの更新を要求する第３のステップ、
からなる処理を実行し、前記第３のステップの実行中に前記データ更新定義により下位ノードからの繰り返し要素の抽出が指定されていた場合には、前記第３のステップにおいて抽出されていたノードを新たに前記処理対象として前記第２および第３のステップを実行するデータ更新ステップと、
を含む処理を前記コンピュータに実行させることを特徴とするデータ構造変換プログラム。

（付記２） 前記データ更新定義は、入力された前記構造化文書中の前記処理対象とするノードより下位のノードを相対的に指示するルート情報と、前記ルート情報により指示されたノードごとに、操作対象とする前記リレーショナルデータベース内のテーブルのメタデータを対応付けたテーブル対応付け情報とを含む更新対象要素定義を少なくとも１つ含み、
前記データ更新ステップでは、前記データ更新定義に含まれる前記更新対象要素定義を前記ルートノードから順次適用することを特徴とする付記１記載のデータ構造変換プログラム。

（付記３） 前記更新対象要素定義には、すべての前記更新対象要素定義を再帰的に呼び出すための再帰呼び出し情報を記述することが可能であり、
前記データ更新ステップでは、前記第３のステップの実行中に前記再帰読み出し情報を検出した場合に、前記第３のステップにおいて抽出されていたノードを新たに前記処理対象として前記第２および第３のステップを実行することを特徴とする付記２記載のデータ構造変換プログラム。

（付記４） 前記テーブル対応付け情報は、操作対象とする前記テーブルを識別するメタデータと、識別される前記テーブル内のカラムを定義するメタデータ、および前記カラムに格納する前記構造化文書中の要素内容または属性値を指示するパス情報を含む１つ以上のカラム定義情報とを含むことを特徴とする付記２記載のデータ構造変換プログラム。

（付記５） 前記テーブル対応付け情報により前記テーブル内に格納可能なデータとして、単一の数値または文字列、入力された前記構造化文書中の要素配列の一部からなる文字列、バイナリデータのいずれかを適用することが可能であることを特徴とする付記２記載のデータ構造変換プログラム。

（付記６） 前記リレーショナルデータベースに対する検索条件の入力を受ける条件入力ステップと、
出力される構造化文書の全体あるいは一部の構造に対応するテンプレートと、前記テンプレートのインスタンス化の際に抽出対象とする前記リレーショナルデータベース上のパラメータとを含む参照対象テーブル定義が１つ以上記述されたデータ参照定義を取得する参照定義取得ステップと、
前記検索条件および前記参照対象テーブル定義に基づいて前記リレーショナルデータベースに問い合わせを発行する第４のステップ、
前記問い合わせの結果を用いて前記テンプレートをインスタンス化する第５のステップ、
からなる処理を実行し、前記第５のステップの実行中に別の前記参照対象テーブル定義の呼び出しが指定されていた場合には、該当する前記参照対象テーブル定義を用いて前記第４および第５のステップを実行するテンプレート置換ステップと、
を含む処理をさらに前記コンピュータに実行させることを特徴とする付記１記載のデータ構造変換プログラム。

（付記７） 前記検索条件には、前記参照対象テーブル定義で定義された前記パラメータを指定する情報とその値、および前記第４のステップにおいて最初に適用する前記参照対象テーブル定義を指定する情報が含まれることを特徴とする付記６記載のデータ構造変換プログラム。

（付記８） 前記テンプレートでは、前記第４のステップで発行される前記問い合わせにより得られるレコードのうちの抽出対象とするカラムの値と、出力する前記構造化文書中の置換すべき要素内容または属性値とが対応付けられていることを特徴とする付記６記載のデータ構造変換プログラム。

（付記９） 前記テンプレートにおいてインスタンス化される対象として、単一の数値または文字列、出力される前記構造化文書中の要素配列の一部をなす文字列、バイナリデータのいずれかを適用することが可能であることを特徴とする付記６記載のデータ構造変換プログラム。

（付記１０） 構造化文書とリレーショナルデータベースとの間でデータ構造を変換するためのデータ構造変換方法において、
入力された構造化文書中の処理対象とするノードより下位のノードについて、操作対象とするリレーショナルデータベース内のテーブルとの対応付けを定義したデータ更新定義を取得する更新定義取得ステップと、
入力された前記構造化文書中のルートノードを前記処理対象に設定する第１のステップ、
前記処理対象に設定されたノードを起点にして、前記データ更新定義により指示されるノードから繰り返し要素を抽出する第２のステップ、
前記繰り返し要素として抽出されたノードごとに、前記テーブルに対応付けられた要素内容または属性値を入力された前記構造化文書から抽出して、前記テーブルの更新を要求する第３のステップ、
からなる処理を実行し、前記第３のステップの実行中に前記データ更新定義により下位ノードからの繰り返し要素の抽出が指定されていた場合には、前記第３のステップにおいて抽出されていたノードを新たに前記処理対象として前記第２および第３のステップを実行するデータ更新ステップと、
を含むことを特徴とするデータ構造変換方法。

（付記１１） 前記リレーショナルデータベースに対する検索条件の入力を受ける条件入力ステップと、
出力される構造化文書の全体あるいは一部の構造に対応するテンプレートと、前記テンプレートのインスタンス化の際に抽出対象とする前記リレーショナルデータベース上のパラメータとを含む参照対象テーブル定義が１つ以上記述されたデータ参照定義を取得する参照定義取得ステップと、
前記検索条件および前記参照対象テーブル定義に基づいて前記リレーショナルデータベースに問い合わせを発行する第４のステップ、
前記問い合わせの結果を用いて前記テンプレートをインスタンス化する第５のステップ、
からなる処理を実行し、前記第５のステップの実行中に別の前記参照対象テーブル定義の呼び出しが指定されていた場合には、該当する前記参照対象テーブル定義を用いて前記第４および第５のステップを実行するテンプレート置換ステップと、
をさらに含むことを特徴とする付記１０記載のデータ構造変換方法。

（付記１２） 構造化文書とリレーショナルデータベースとの間でデータ構造を変換するデータ構造変換装置において、
入力された構造化文書中の処理対象とするノードより下位のノードについて、操作対象とするリレーショナルデータベース内のテーブルとの対応付けを定義したデータ更新定義、および、出力される構造化文書の全体あるいは一部の構造に対応するテンプレートと、前記テンプレートのインスタンス化の際に抽出対象とする前記リレーショナルデータベース上のパラメータとを含む参照対象テーブル定義が１つ以上記述されたデータ参照定義からなるデータ対応定義を記憶する対応定義記憶部と、
入力された前記構造化文書中のルートノードを前記処理対象に設定し、前記処理対象に設定されたノードを起点にして、前記データ更新定義により指示されるノードから繰り返し要素を抽出し、前記繰り返し要素として抽出されたノードごとに、前記テーブルに対応付けられた要素内容または属性値を入力された前記構造化文書から抽出して、前記テーブルの更新を要求する処理を実行し、さらに、前記要素内容の抽出処理の実行中に前記データ更新定義により下位ノードからの繰り返し要素の抽出が指定されていた場合には、前記要素内容の抽出処理において前記繰り返し要素として抽出されていたノードを新たに前記処理対象として、前記繰り返し要素の抽出、前記要素内容の抽出および前記テーブルの更新要求の処理を再帰的に実行するデータ更新処理部と、
前記リレーショナルデータベースに対する検索条件の入力を受ける検索条件入力部と、
前記検索条件および前記データ参照定義中の前記参照対象テーブル定義に基づいて前記リレーショナルデータベースに問い合わせを発行し、前記問い合わせの結果を用いて前記テンプレートをインスタンス化する処理を実行し、前記インスタンス化の処理の実行中に別の前記参照対象テーブル定義の呼び出しが指定されていた場合には、該当する前記参照対象テーブル定義を用いてリレーショナルデータベースへの前記問い合わせの発行、および前記インスタンス化の処理を再帰的に実行するデータ参照処理部と、
を有することを特徴とするデータ構造変換装置。

本発明の原理を説明するための原理図である。 本発明を適用可能なデータベースサービスシステムのシステム構成を示す図である。 本発明の実施の形態に係るデータベースサーバのハードウェア構成例を示す図である。 本発明の実施の形態に係るデータベースサーバの機能を示すブロック図である。 ＸＭＬ−ＲＤＢ対応定義のデータ構造を概略的に示す図である。 ＲＤＢに対するデータの格納および削除を行う際の更新定義適用処理の全体の流れを示すフローチャートである。 データを格納するための更新対象要素定義適用処理の流れを示すフローチャートである。 データを格納する際の更新対象テーブル定義適用処理の流れを示すフローチャートである。 データを削除するための更新対象要素定義適用処理の流れを示すフローチャートである。 データを削除する際の更新対象テーブル定義適用処理の流れを示すフローチャートである。 データ参照処理全体の流れを示すフローチャートである。 参照対象テーブル適用処理の流れを示すフローチャートである。 テンプレート復元処理の流れを示すフローチャートである。 実施例１に係るＸＭＬ文書とＲＤＢの構造を示す図である。 実施例１において適用されるＸＭＬ−ＲＤＢ対応定義のコード例を示す図である。 実施例１におけるデータ更新処理を説明するための第１の図である。 実施例１におけるデータ更新処理を説明するための第２の図である。 実施例１におけるデータ更新処理を説明するための第３の図である。 実施例１におけるデータ参照処理を説明するための第１の図である。 実施例１におけるデータ参照処理を説明するための第２の図である。 実施例２に係るＸＭＬ文書とＲＤＢの構造を示す図である。 実施例３に係るＸＭＬ文書とＲＤＢの構造を示す図である。 実施例４に係るＸＭＬ文書とＲＤＢの構造を示す図である。 実施例５に係るＸＭＬ文書とＲＤＢの構造を示す図である。 実施例５において適用されるＸＭＬ−ＲＤＢ対応定義のコード例を示す図である。

符号の説明

１ａ，１ｂ 構造化文書
２ ＲＤＢ
３ データ対応定義
３ａ データ更新定義
３ｂ データ参照定義
１００ データベースサーバ
１１０ データ構造変換部
１１１ ＲＤＢ更新処理部
１１２ ＸＭＬ復元処理部
１１３ 対応定義記憶部
１２０ データベース部
１２１ ＲＤＢＭＳ
１２２ ＲＤＢ
１３０ ＸＭＬ−ＲＤＢ対応定義
１４１，１４２ ＸＭＬ文書
２０１〜２０３ クライアント
３００ ネットワーク

Claims (5)

1. 構造化文書とリレーショナルデータベースとの間でデータ構造を変換する処理をコンピュータに実行させるデータ構造変換プログラムにおいて、
   入力された構造化文書中の処理対象とするノードより下位のノードについて、操作対象とするリレーショナルデータベース内のテーブルとの対応付けを定義したデータ更新定義を取得する更新定義取得ステップと、
   入力された前記構造化文書中のルートノードを前記処理対象に設定する第１のステップ、
   前記処理対象に設定されたノードを起点にして、前記データ更新定義により指示されるノードから繰り返し要素を抽出する第２のステップ、
   前記繰り返し要素として抽出されたノードごとに、前記テーブルに対応付けられた要素内容または属性値を入力された前記構造化文書から抽出して、前記テーブルの更新を要求する第３のステップ、
   からなる処理を実行し、前記第３のステップの実行中に前記データ更新定義により下位ノードからの繰り返し要素の抽出が指定されていた場合には、前記第３のステップにおいて抽出されていたノードを新たに前記処理対象として前記第２および第３のステップを実行するデータ更新ステップと、
   を含む処理を前記コンピュータに実行させることを特徴とするデータ構造変換プログラム。
2. 前記データ更新定義は、入力された前記構造化文書中の前記処理対象とするノードより下位のノードを相対的に指示するルート情報と、前記ルート情報により指示されたノードごとに、操作対象とする前記リレーショナルデータベース内のテーブルのメタデータを対応付けたテーブル対応付け情報とを含む更新対象要素定義を少なくとも１つ含み、
   前記データ更新ステップでは、前記データ更新定義に含まれる前記更新対象要素定義を前記ルートノードから順次適用することを特徴とする請求項１記載のデータ構造変換プログラム。
3. 前記テーブル関連付け情報により前記テーブル内に格納可能なデータとして、単一の数値または文字列、入力された前記構造化文書中の要素配列の一部からなる文字列、バイナリデータのいずれかを適用することが可能であることを特徴とする請求項２記載のデータ構造変換プログラム。
4. 前記リレーショナルデータベースに対する検索条件の入力を受ける条件入力ステップと、
   出力される構造化文書の全体あるいは一部の構造に対応するテンプレートと、前記テンプレートのインスタンス化の際に抽出対象とする前記リレーショナルデータベース上のパラメータとを含む参照対象テーブル定義が１つ以上記述されたデータ参照定義を取得する参照定義取得ステップと、
   前記検索条件および前記参照対象テーブル定義に基づいて前記リレーショナルデータベースに問い合わせを発行する第４のステップ、
   前記問い合わせの結果を用いて前記テンプレートをインスタンス化する第５のステップ、
   からなる処理を実行し、前記第５のステップの実行中に別の前記参照対象テーブル定義の呼び出しが指定されていた場合には、該当する前記参照対象テーブル定義を用いて前記第４および第５のステップを実行するテンプレート置換ステップと、
   を含む処理をさらに前記コンピュータに実行させることを特徴とする請求項１記載のデータ構造変換プログラム。
5. 前記テンプレートにおいてインスタンス化される対象として、単一の数値または文字列、出力される前記構造化文書中の要素配列の一部をなす文字列、バイナリデータのいずれかを適用することが可能であることを特徴とする請求項４記載のデータ構造変換プログラム。

Images