構造化文書データ変換装置及び方法
【課題】アプリケーションが個別にデータの読み替え処理をプログラミングしなくても、異なる構造化データを、共通化された構造を持つものとして参照可能とする。
【解決手段】変換エンジン２０は、ＤＢ１０に記憶された、見かけ上の構造は異なるが、共通の論理構造を持つと見なされる要素群の組毎に用意され変換規則定義情報であって、当該組内の物理形式が共通の要素群毎にそれぞれ対応した変換規則を含む変換規則定義情報の１つ、例えば変換規則定義情報１２０-1が、アプリケーションプログラム４０から指定された場合、当該情報１２０-1に従って、対応する要素群の組を対象に、ＤＢ１０に記憶された構造化データの物理形式を論理形式に変換する。ユーザインタフェース３０は、変換された論理形式を持った構造化データがＤＢ１０に存在するかの如く変換エンジン２０による変換結果をアプリケーションプログラム４０に返す。
【解決手段】変換エンジン２０は、ＤＢ１０に記憶された、見かけ上の構造は異なるが、共通の論理構造を持つと見なされる要素群の組毎に用意され変換規則定義情報であって、当該組内の物理形式が共通の要素群毎にそれぞれ対応した変換規則を含む変換規則定義情報の１つ、例えば変換規則定義情報１２０-1が、アプリケーションプログラム４０から指定された場合、当該情報１２０-1に従って、対応する要素群の組を対象に、ＤＢ１０に記憶された構造化データの物理形式を論理形式に変換する。ユーザインタフェース３０は、変換された論理形式を持った構造化データがＤＢ１０に存在するかの如く変換エンジン２０による変換結果をアプリケーションプログラム４０に返す。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、構造化データ（構造化文書）の形式を変換する構造化データ変換装置及び変換方法に係り、特に、構造化データ（構造化文書）の一種である半構造化データ（半構造化文書）として知られているＸＭＬデータ（ＸＭＬ文書）の表現形式を変換するのに好適な構造化データ変換装置及び方法に関する。
【背景技術】
【０００２】
データを記述する手段として、ＸＭＬ(Extensible Markup Language)が広く利用されている。このＸＭＬを用いて記述されたデータ（文書）はＸＭＬデータ（ＸＭＬ文書）と呼ばれる。
【０００３】
ＸＭＬデータは、論理的に、階層を持った木構造を表現し、構造化データ（構造化文書）の一種である半構造化データ（半構造化文書）として知られている。ＸＭＬは、タグ、属性名、及びそれらの階層構造による自己説明性を有している。このため、ＸＭＬは、データの利用時に構造を目的に合わせて整形したり、その中から必要な情報を抽出することが可能な特長を持つ。特に昨今、技術発展の顕著なＸＭＬデータベース（ＸＭＬＤＢ）では、データ構造を事前に規定することなく応用ソフトウェア（アプリケーション）がそれぞれの固有形式で情報登録しても、それらの情報に陰に含まれる共通構造に注目して一括処理や分析を行うアプリケーションを実現可能であるという大きな効用をもたらしている。
【０００４】
従来、データ登録アプリケーションに固有の形式でＸＭＬＤＢに格納されたデータを、利用時に目的の構造に読み替える（つまり変換する）には、大別して次の２つの方法（変換方法）がある。
【０００５】
１つは、アプリケーションが、ＤＢから読み取ったデータを目的の構造に変換するか、もしくは、その中の参照する情報項目を直接に取り出して変換する方法（方法１）である。もう１つは、ＤＢから対象データを形式毎にいったん取り出し、これを変換して形式を共通化する方法（方法２）である。この変換法の定義と変換の実行には、ＸＭＬの標準の１つであるＸＳＬＴ（XSL Transformations, XSL:Extensible Stylesheet Language)が用いられる（例えば、非特許文献１参照）。
【非特許文献１】XSL Transformations (XSLT) Version 1.0，[online]，平成１１年１１月１６日，World Wide Web Consortium (W3C)，[平成１６年６月２１日検索]，インターネット<URL: http://www.w3.org/TR/1999/REC-xslt-19991116>
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上記した従来技術、例えば方法１には、データ読み替えの多くの処理は類似しているにも拘わらず、アプリケーションがそれぞれの読み替え処理をプログラミングしなければならない問題がある。一方、方法２には、データを格納形式毎に一旦取り出して、ＸＳＬＴプロセッサを実行しなければならないため、実行効率が悪いという問題がある。ＸＳＬＴプロセッサは、ＸＳＬＴスタイルシート（変換法の定義）を利用して変換結果を出力するプログラムである。
【０００７】
また、方法１及び２のいずれも、元のデータの形式が複数存在する場合にアプリケーションはそのことを考慮しなければならないため、プログラミングが複雑になると共に、元のデータの形式が増大したときの拡張性に欠けるという問題もある。
【０００８】
本発明は上記事情を考慮してなされたものでその目的は、アプリケーションが個別にデータの読み替え処理をプログラミングしなくても、異なる構造化データを、共通化された構造を持つものとして参照できる構造化データ変換装置及び方法を提供することにある。
【課題を解決するための手段】
【０００９】
本発明の１つの観点によれば、データベースに記憶された構造化データの形式を変換する構造化データ変換装置が提供される。この構造化データ変換装置は、上記データベースに記憶された、見かけ上の構造は異なるが、共通の論理構造を持つと見なされる予め定められた要素群の組毎に用意される変換規則定義情報であって、当該組内の物理形式が共通の上記要素群毎にそれぞれ対応した変換規則を含む変換規則定義情報の１つが、上記構造化データを利用するアプリケーションプログラムから指定された場合、当該指定された変換規則定義情報に従って、上記データベースに記憶されたデータの形式である物理形式を、共通の論理構造を表す形式である論理形式に変換する変換手段と、この変換手段によって変換された論理形式を持ったデータが上記データベースに存在するかの如く、当該変換手段による変換結果を上記アプリケーションプログラムに返すインタフェース手段とを備える。
【００１０】
このような構成においては、アプリケーションプログラムによって任意の変換規則定義情報が指定されると、その変換規則定義情報に対応する要素群の組、即ち見かけ上の構造は異なるが、共通の論理構造を持つと見なされる要素群の組を対象に、当該指定された変換規則定義情報に従って、構造化データの物理形式が論理形式に変換される。そして、変換された論理形式を持った構造化データがデータベースに存在するかの如く、その変換結果がアプリケーションプログラムに返される。
【００１１】
このように、上記の構成によれば、アプリケーションプログラムは、構造化データ変換装置の変換手段に対して任意の変換規則定義情報を指定するだけで、当該アプリケーションプログラムが個別にデータの読み替え処理をプログラミングしなくても、当該アプリケーションプログラムからは、当該変換規則定義情報に対応した、見かけ上の構造が異なるデータベース内の構造化データを、共通化された構造を持つものとして参照できる。しかも、元のデータの形式が増大したときにも、それに合わせて変換規則定義情報を変更するだけで容易に対応できるため、拡張性に富む。更に、データベース内の元の構造化データが、見かけ上の構造が異なる幾つかのグループから構成されていても、アプリケーションプログラムに対し、共通化された構造のデータが連続して存在するように認識させることができる。
【００１２】
ここで、データベースに記憶された要素群の組毎に用意される変換規則定義情報に、それぞれ識別情報が付与される構成とするならば、上記変換手段に次のような機能、即ち、アプリケーションプログラムから任意の変換規則定義情報の識別情報が指定された場合に、データベースに記憶された変換規則定義情報のうちの、当該識別情報が付与されている変換規則定義情報が指定されたとして、当該指定された変換規則定義情報に従う変換を行う機能を持たせると良い。ここで、上記識別情報に名前を用いるならば、アプリケーションプログラムは名前を指定するだけで、データ変換に用いる変換規則定義情報と変換の対象となる要素群の組を指定できる。
【００１３】
また、上記変換規則定義情報に含まれている変換規則が、当該変換規則を適用する要素群中の各要素に共通のフィールド変換規則であって、当該各要素の下に位置する任意の要素であるフィールドのうち、共通の論理構造に対応した物理構造を持つフィールドの変換規則であるフィールド変換規則を含む構成とするならば、上記変換手段に次のようなフィールド変換手段、即ち、上記フィールド変換規則に従い、対応するフィールドの物理形式を論理形式に変換するフィールド変換手段を持たせると良い。この変換規則を適用する要素群中の各要素の下に位置する要素であるフィールドのうち、フィールド変換規則で定義されるフィールドについて、物理形式を論理形式に変換するフィールド変換を自動的に行うことができる。
【００１４】
特に、変換規則定義情報に含まれている変換規則が、当該変換規則を適用する要素群の格納箇所を示すパスの情報を含み、フィールド変換規則が、対応するフィールドの変換前の要素名を表す変換前タグと変換後の要素名を表す変換後タグとを含む構成とするならば、上記変換手段に次のような各手段、即ち、指定された変換規則定義情報を適用する要素群の組の中から、変換対象となる要素群を順次選択する第１の選択手段と、指定された変換規則定義情報の中から、この第１の選択手段によって選択された要素群の格納箇所を表すパスで特定される変換規則を選択する第２の選択手段と、上記第１の選択手段によって選択された要素群から、変換対象となる要素を順次選択する第３の選択手段とを持たせ、この第３の選択手段によって選択された要素中の各フィールドのうち、第２の選択手段によって選択された変換規則中のフィールド変換規則に含まれている変換前タグに一致するタグを含むフィールドの物理形式が、上記フィールド変換手段により当該フィールド変換規則に従って論理形式に変換される構成とすると良い。
【００１５】
また、フィールド変換規則にフィールド値の変換を定義したフィールド値変換規則が含まれる構成とするならば、上記変換手段に、次のような手段、即ちフィールド変換規則による変換の対象となるフィールドの値をフィールド値変換規則に従って変換するフィールド値変換手段を持たせると良い。このような構成においては、フィールドの物理形式を論理形式に変換することにより、フィールド値と変換後の形式との間に矛盾が生じる場合に、その矛盾を解消することができる。例えば、＜定価＞フィールド（定価要素）のフィールド値（要素内容）は千円単位で表され、＜価格＞フィールド（価格要素）のフィールド値（要素内容）は円単位で表される場合に、＜定価＞タグを共通化された＜価格＞タグに変換する場合、そのフィールド値（要素内容）を千円単位から円単位に変換することができる。
【００１６】
また、上記変換手段に、次のような手段、即ちアプリケーションプログラムから集約型の操作と、当該集約型の操作の対象となる集約対象フィールドの論理形式を表す論理名が指定された場合、上記フィールド変換規則に上記フィールド値変換規則が含まれているならば、上記指定された集約対象フィールドの値に対する変換後の値を、その時点までの集約結果に反映し、上記フィールド変換規則に上記フィールド値変換規則が含まれていないならば、上記指定された集約対象フィールドの値を、その時点までの集約結果に反映する集約手段を持たせると良い。このような構成においては、指定された集約対象フィールドの変換後の値を集約結果に反映することが可能となるため、フィールド値と変換後の形式との間の矛盾を解消しながら、集約対象フィールドの値を集約すること、例えば単位が統一された集約対象フィールドの値を加算することができる。
【発明の効果】
【００１７】
本発明によれば、アプリケーションプログラムから任意の変換規則定義情報を指定するだけで、その変換規則定義情報に対応する要素群の組である、見かけ上の構造は異なるが、共通の論理構造を持つと見なされる要素群の組を対象に、当該指定された変換規則定義情報に従って、構造化データの物理形式が論理形式に変換され、その変換された論理形式を持った構造化データがデータベースに存在するかの如く、その変換結果がアプリケーションプログラムに返される。このため、アプリケーションプログラムは、個別にデータの読み替え処理をプログラミングしなくても、当該変換規則定義情報に対応した、見かけ上の構造が異なるデータベース内の構造化データを、共通化された構造を持つものとして参照できる。
【発明を実施するための最良の形態】
【００１８】
以下、本発明を、構造化データ（半構造化データ）の代表であるＸＭＬデータの表現形式を変換するＸＭＬデータ変換装置に適用した一実施形態につき図面を参照して説明する。
図１は本発明の一実施形態に係るＸＭＬデータ変換装置の構成を示すブロック図である。ＸＭＬデータ変換装置は、ＸＭＬＤＢ（ＸＭＬデータベース）１０と、ＸＭＬデータ変換エンジン２０と、ユーザインタフェース３０とを備えている。ＸＭＬＤＢ１０はハードディスクドライブに代表される外部記憶装置（図示せず）に保存されているものとする。なお、ＸＭＬＤＢ１０をＸＭＬデータ変換装置から独立させて、例えばネットワークを介して当該ＸＭＬデータ変換装置内の変換エンジン２０からアクセス可能な構成とすることも可能である。この場合、ＸＭＬＤＢ１０を、複数のＸＭＬデータ変換装置で共有することも可能である。
【００１９】
ＸＭＬは均質な階層構造で表されるデータである。しかし、以下の説明においては便宜上、共通構造の認識に基づき処理される要素を「レコード」、レコードの下に位置する要素を「フィールド」、レコード群を子要素とする要素を「テーブル」と表現する。
【００２０】
ＸＭＬＤＢ１０には、ＸＭＬデータ変換エンジン２０による変換の対象となり得るＸＭＬデータである物理データ（元データ）１１が格納される。物理データ１１は、レコード群を子要素として有する幾つかのテーブル（物理テーブル、物理要素群）、例えば３つのテーブル１１０-1，１１０-2及び１１０-3を含む。テーブル１１０-iは、定められた特徴を備えたデータではなく、共通な構造を持った要素（レコード）群に対する外部からの意味づけ結果を示すデータである。
【００２１】
ＸＭＬＤＢ１０にはまた、ＸＭＬデータ変換エンジン２０によって適用されるＸＭＬデータ変換の規則（ＸＭＬデータ変換法）を定義した情報（変換規則定義情報）のファイル（以下、変換規則定義ファイルと称する）１２も格納される。ここでは、変換規則定義ファイル１２は、変換規則定義情報１２０-1及び１２０-2を含む変換規則定義情報の集合として定義されており、ファイル名によって管理される通常のデータファイルとは異なるものとする。変換規則定義情報１２０-j（ｊ＝１，２）は、ＸＭＬデータの表現形式を物理形式から論理形式に変換するための変換規則を定義した情報である。ここで、物理形式とは、変換対象となるＸＭＬデータの元の表現形式をいい、論理形式とは、元の表現形式と共通な論理構造の目的とする表現形式をいう。
【００２２】
ＸＭＬデータ変換エンジン２０は、変換規則定義ファイル１２内の変換規則定義情報１２０-jに基づきＸＭＬデータを物理形式から論理形式に変換する。ＸＭＬデータ変換エンジン２０は、形式形式変換部２１とフィールド値変換部２２とを備えている。
【００２３】
形式変換部２１はＸＭＬデータ変換の実行部であり、ＸＭＬデータ変換エンジン２０の中枢部をなす。形式変換部２１は、アプリケーション（アプリケーションプログラム）４０からユーザインタフェース３０を介して与えられるＸＭＬデータ変換要求に応じて、物理形式から論理形式へのＸＭＬデータ変換を実行する。形式変換部２１は、例えば２つの変換ユニット２１０-1及び２１０-2を含む。変換ユニット２１０-1及び２１０-2は、変換により得られる論理形式データの処理法に応じて選択して用いられる。変換ユニット２１０-1は、ＸＭＬデータ変換により構造を共通化された論理レコード群を、一括してアプリケーションプログラム４０に渡す処理（以下、処理１と称する）を適用する。一方、変換ユニット２１０-2は、上記論理レコード群に対して集約型の操作を行った結果をアプリケーションプログラム４０に渡す処理（以下、処理２と称する）を適用する。集約型の操作とは、論理レコード群を集約する操作を指し、例えば定価要素の要素内容と価格要素の要素内容を、いずれも価格要素の要素内容として、それらの総和を算出する操作が挙げられる。また、エラー要素の要素内容（エラーの有無）と誤り要素の要素内容（誤りの有無）を、いずれもエラー要素の要素内容として、１つでもエラー（誤り）があれば、不良とする操作も集約型の操作である。変換ユニット２１０-1及び２１０-2のいずれを用いるかは、ユーザの選択操作に応じてアプリケーションプログラム４０から指定される。
【００２４】
フィールド値変換部２２は、変換規則定義情報１２０-jによりフィールド値の変換が指定されたとき、形式変換部２１（内の変換ユニット２１０-1または２１０-2）から呼び出されて、その値の変換を実行する。フィールド値変換部２２は、例えば、値を四捨五入するための変換関数（四捨五入関数）２２１と、値の単位を変換するための変換関数（単位変換関数）２２２とを有する。
【００２５】
ユーザインタフェース３０は、ＸＭＬデータ変換エンジン２０とアプリケーションプログラム４０（のユーザ）とのインタフェースである。ユーザインタフェース３０は、ユーザの操作に応じてアプリケーションプログラム４０から送られるＸＭＬデータ変換（物理形式から論理形式への変換）の要求を、ＸＭＬデータ変換エンジン２０（内の形式変換部２１）に通知する。ユーザインタフェース３０はまた、ＸＭＬデータ変換エンジン２０（内の形式変換部２１）によるＸＭＬデータの変換結果（つまり、物理形式から論理形式への変換結果）をアプリケーションプログラム４０に通知する。アプリケーションプログラム４０は、通知された変換結果（ＸＭＬデータの変換結果）を利用する。
【００２６】
ＸＭＬデータ変換エンジン２０は、計算機にインストールされた特定のソフトウェアプログラムを当該計算機が読み取って実行することにより実現される。このプログラムは、コンピュータで読み取り可能な記憶媒体（フロッピー（登録商標）ディスクに代表される磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤに代表される光ディスク、フラッシュメモリに代表される半導体メモリ等）に予め格納して頒布可能である。また、このプログラムが、ネットワークを介してダウンロード（頒布）されても構わない。
【００２７】
図２は、変換規則定義ファイル１２の記述内容の一般形を示す。図２において、各タグで表わされた記述項目は次のように定義される。
<logical-table>要素１２１は、変換規則定義ファイル１２全体、つまり変換規則定義情報１２０-jの集合を表わす。
【００２８】
<map>要素１２２は、１つの変換規則定義情報１２０-jを表わす。この<map>要素２０２が１つの論理的なテーブルを与える。<map>要素２０２は、仮想的に共通構造を持つと見せるデータ群（論理テーブル）毎に用意される。
<name>要素１２３は、論理テーブル名を表す。変換規則定義情報１２０-jは、アプリケーションプログラム４０からこの論理テーブル名によって識別される。つまり変換規則定義情報１２０-jには、固有の論理テーブル名が付与されている。
<recordname>要素１２４は、変換後レコード（論理レコード）タグを表す。
【００２９】
<translate>要素１２５は、変換元のデータからなるテーブル（物理テーブル）毎に用意される、レコード変換の規則を定義した情報である。
<path>要素１２６は、物理テーブルのパスを表す。
<field>要素１２７は、物理テーブルから論理テーブルに変換するとき、変換対象となるフィールドの変換規則を定義した情報である。
【００３０】
<physical>要素１２８は、変換対象フィールドの変換前のタグを表す。
【００３１】
<logical>要素１２９は、変換対象フィールドの変換後のタグを表す。
【００３２】
<function>要素１２Ａは、フィールド値の変換を要するとき、その変換に用いられる変換関数を指定する。
【００３３】
<param>要素１２Ｂは、<function>要素１２Ａで指定される変換関数が引数を要するとき、その引数を指定する。
【００３４】
図３は、変換対象データの一例を示す。この図３には、ＸＭＬデータ変換前の、異なる物理形式のレコード３１及び３２が、２つのパス “/root/商品カタログ” と “/root/製品情報” にそれぞれ格納されている状況と、当該レコード３１及び３２の具体例が示されている。なお、パス “/root/商品カタログ” には、レコード３１と同一の物理形式の別のレコードも格納されているものとする。つまり、パス “/root/商品カタログ” には、レコード３１を含む同一の物理形式のレコード群を子要素とする（図１中のテーブル１１０-iに相当する）テーブル３３が格納されている。同様に、パス “/root/製品情報” には、レコード３２と同一の物理形式の別のレコードも格納されているものとする。つまり、パス “/root/製品情報” には、レコード３２を含む同一の物理形式のレコード群を子要素とする（図１中のテーブル１１０-iに相当する）テーブル３４が格納されている。
【００３５】
図４は、図３に示されている、物理形式の異なる２種類のレコード３１及び３２の間のフィールドの対応関係を表形式で示す。図４には、レコード（商品カタログレコード）３１中の商品、メーカ、機種、サイズ及び定価の各フィールドと、レコード（製品情報レコード）３２中の製品、製造元、名称、画面サイズ及び価格の各フィールドとが、それぞれ対応していることが示されている。そこで、図４に示す表形式の最右端のカラムに記されたタグを持つ論理テーブルに、上述の対応関係のあるフィールドを統合し、アプリケーションプログラム４０からは共通のレコード形式に見せる変換規則の定義を考える。つまり、図３に示されている物理形式の異なるレコード３１及び３２を、それぞれ図５に示すレコード３１０及び３２０としてアプリケーションプログラム４０に提供することを考える。
【００３６】
図６は、図３のレコード３１及び３２を、それぞれ図５のレコード３１０及び３２０に変換するための、例えば変換規則定義情報１２０-1の具体例を示す。図６において、<map>要素６２２は、図２中の<map>要素１２２に相当しており、図２中の<translate>要素１２５に相当する２つの<translate>要素６２５-1及び６２５-2を含む。<translate>要素６２５-1は、レコード３１を含むレコード群を子要素とするテーブル３３（図３参照）に対応して用意され、<translate>要素６２５-2は、レコード３２を含むレコード群を子要素とするテーブル３４（図３参照）に対応して用意されている。
【００３７】
<translate>要素６２５-1は、図２中の<field>要素１２７に相当する、<field>要素６２７-1を含む。<field>要素６２７-1は、図３中のテーブル３３の子要素群、つまりレコード３１を含むレコード群に共通の、定価タグ（定価フィールド）を価格タグ（価格フィールド）に変換するためのフィールドの変換規則を定義している。<field>要素６２７-1は、図２中の<function>要素１２Ａに相当する、<function>要素６２Ａを含む。<function>要素６２Ａは、価格の単位変換のために、図１中の単位変換関数２２２を指定する。
【００３８】
一方、<translate>要素６２５-2は、３つの<field>要素６２７-2a，６２７-2b及び６２７-2cを含む。<field>要素６２７-2a，６２７-2b及び６２７-2cは、図３中のテーブル３４の子要素群、つまりレコード３２を含むレコード群に共通に用意される。<field>要素６２７-2aは、製造元タグ（製造元フィールド）をメーカータグ（メーカーフィールド）に変換するための、フィールドの変換規則を定義している。同様に、<field>要素６２７-2bは、名称タグ（名称フィールド）を機種タグ（機種フィールド）に変換するための、フィールドの変換規則を定義している。同様に、<field>要素６２７-2cは、外形／画面サイズタグ（外形／画面サイズフィールド）をサイズタグ（サイズフィールド）に変換するための、フィールドの変換規則を定義している。このように、図６に示す変換規則定義情報１２０-1は、図３中の２つのテーブル（物理テーブル）３３及び３４に含まれる各レコードを共通の論理的レコード形式に変換するために、当該各レコード内の特定のフィールドをどのように変換するかを示す変換規則を与えている。
【００３９】
次に、本実施形態の動作について、ＸＭＬデータ変換エンジン２０内の変換ユニット２１０-1の動作を例に、図７のフローチャートを参照して説明する。
まず、ユーザの操作に応じて、アプリケーションプログラム４０から変換ユニット２１０-1に対して、図６中の変換規則定義情報１２０-1を特定する論理テーブル名が通知されたものとする。この場合、変換ユニット２１０-1は、アプリケーションプログラム４０から指定された論理テーブル名の空の変換結果テーブル（論理テーブル）を、図示せぬメモリ上に用意する（ステップＳ１）。
【００４０】
次に、変換ユニット２１０-1は第１の選択手段として機能して、ＸＭＬＤＢ１０に格納されている、アプリケーションプログラム４０から指定された論理テーブル名の論理テーブルに対応する変換対象ＸＭＬデータ（即ち物理テーブル群）から、最初の変換対象テーブル（物理テーブル）を選択する（ステップＳ２）。ここでは、図３に示すテーブル３３及び３４を含むＸＭＬデータからテーブル３３が選択されたものとする。
【００４１】
次に、変換ユニット２１０-1は第２の選択手段として機能して、ＸＭＬＤＢ１０に格納されている変換規則定義ファイル１２内の変換規則定義情報のうちの、アプリケーションプログラム４０から指定された論理テーブル名で特定される変換規則定義情報から、変換対象テーブル３３のパス、つまり “/root/商品カタログ” で特定される変換規則である<translate>要素を選択する（ステップＳ３）。ここでは、アプリケーションプログラム４０から指定された論理テーブル名によって、図６に示す変換規則定義情報１２０-1が特定されるものとすると、当該変換規則定義情報１２０-1内の<translate>要素６２５-1が選択される。
【００４２】
次に、変換ユニット２１０-1は第３の選択手段として機能して、テーブル３３から、最初の変換対象レコードを選択する（ステップＳ４）。ここでは、レコード３１が変換対象レコードとして選択されたものとする。変換ユニット２１０-1は、変換対象レコード３１から最初の変換対象フィールドを選択する（ステップＳ５）。ここでは、レコード３１からメーカー要素（図３参照）が変換対象フィールドとして選択されたものとする。
【００４３】
変換ユニット２１０-1は、変換対象フィールド（メーカー要素）のタグ（メーカー）が<translate>要素６２５-1中の変換規則に含まれているかを判定する（ステップＳ６）。<translate>要素６２５-1中の変換規則に含まれるタグは、図６に示されるように、定価タグのみである。この場合、変換ユニット２１０-1は、後述するステップＳ７及びＳ８をスキップしてステップＳ９に進む。このステップＳ９において、変換ユニット２１０-1は、、現在処理中のテーブル３３に未処理のフィールドが残っているかを判定する。この例のように、未処理のフィールドが残っている場合、変換ユニット２１０-1はテーブル３３から次の変換対象フィールドを選択する（ステップＳ１０）。ここでは、図３から明らかなように、メーカー要素の次の品名要素が変換対象フィールドとして選択される。
【００４４】
変換ユニット２１０-1は、次の変換対象フィールド（＝品名要素）を選択すると、ステップＳ６に戻る。このステップＳ６において、変換ユニット２１０-1は、変換対象フィールド（品名要素）のタグ（品名）が<translate>要素６２５-1中の変換規則に含まれているかを判定する。ここで、変換対象フィールドである品名要素のタグ（品名）は、<translate>要素６２５-1中の変換規則に含まれていない。この場合、テーブル３３中の残りのフィールドについて、同様の処理が繰り返される。
【００４５】
さて、テーブル３３中の残りのフィールド、つまり機種要素、サイズ要素、重量要素及び定価要素の各タグのうち、<translate>要素６２５-1中の変換規則に含まれているタグは、定価タグのみである。変換ユニット２１０-1は、次の変換対象フィールドとしてテーブル３３から定価要素を選択した場合（ステップＳ１０）、当該価格要素のタグが<translate>要素６２５-1中の変換規則に含まれていると判定する（ステップＳ６）。ここでは、価格要素のタグが<translate>要素６２５-1中の<field>要素６２７-1に含まれている。この場合、変換ユニット２１０-1は、<field>要素６２７-1に<function>要素が含まれているかを判定し、<function>要素が含まれているならば、フィールド値変換部２２を呼び出す。するとフィールド値変換部２２は、<field>要素６２７-1に含まれている<function>要素で指定される変換関数を用いて、変換対象フィールドの値を変換する（ステップＳ７）。本実施形態では、<field>要素６２７-1中の<function>要素で単位変換関数２２２が指定されると共に、引数として１０００が指定されている。これにより、ステップＳ７では、変換対象フィールドの値、つまり定価要素の要素内容である「２９８」（図３参照）が、「２９８０００」に変換される。このフィールド値変換部２２によるフィールド値変換結果は変換ユニット２１０-1に返される。また変換ユニット２１０-1は、<field>要素６２７-1の変換規則（図６参照）に従い、変換対象フィールドのパス、つまり定価要素のタグを＜定価＞から＜価格＞に変換する（ステップＳ８）。
【００４６】
変換ユニット２１０-1は、テーブル（物理テーブル）３３中のレコード（物理レコード）３１に含まれている全てのフィールド（要素）について処理し終えると（ステップＳ９）、当該レコード３１を対象としたフィールド毎のデータ変換の結果である変換結果レコード（論理レコード）を変換結果テーブル（論理テーブル）に追加する（ステップＳ１１）。次に変換ユニット２１０-1は、テーブル３３に未処理のレコードが残っているかを判定する（ステップＳ１２）。もし、未処理のレコードが残っているならば、変換ユニット２１０-1は第３の選択手段として機能して、テーブル３３から次の変換対象レコードを選択し（ステップＳ１３）、当該変換対象レコードについて上記ステップＳ５から始まる処理を実行する。これに対し、未処理のレコードが残っていないならば、変換ユニット２１０-1は、ＸＭＬＤＢ１０内の変換対象データに未処理のテーブルが残っているかを判定する（ステップＳ１４）。この例のように、未処理のテーブルが残っているならば、変換ユニット２１０-1は第１の選択手段として機能して、変換対象データから次の変換対象テーブルを選択する（ステップＳ１５）。ここでは、図３に示されているテーブル３４が選択される。
【００４７】
変換ユニット２１０-1は、テーブル３４を変換対象テーブルとして選択すると、当該テーブル３４について上記ステップＳ３から始まる処理を実行する。ここでは、テーブル３４のパス、つまり “/root/製品情報” で特定される変換規則である<translate>要素６２５-2（図６参照）が選択される（ステップＳ３）。また、テーブル３４中のレコード、例えばレコード３２について、当該レコード３２に含まれている製造元要素、名称要素、外形要素及び価格要素のうち、製造元要素、名称要素及び外形要素が変換対象フィールドとして、それぞれ、<translate>要素６２５-2に含まれている<field>要素６２７-2a，６２７-2b及び６２７-2cの変換規則（図６参照）に従うデータ変換が行われる。ここでは、<field>要素６２７-2a，６２７-2b及び６２７-2cには、いずれも<function>要素は含まれていない。この場合、製造元要素、名称要素及び外形要素のパス（タグ）である＜製造元＞、＜名称＞及び＜外形／画面サイズ＞が、それぞれ＜メーカー＞、＜機種＞及び＜サイズ＞に変換される（ステップＳ８）。これら、テーブル（物理テーブル）３３中のレコード（物理レコード）３２に含まれている製造元要素、名称要素及び外形要素を変換対象フィールドとした変換結果のレコード（論理レコード）は、変換結果テーブル（論理テーブル）に追加される（ステップＳ１１）。やがて、ＸＭＬＤＢ１０内の変換対象データに含まれている全てのテーブル（物理テーブル）についての処理が完了すると、その時点において変換結果テーブル（論理テーブル）に格納されている論理レコードの群（つまり変換ユニット２１０-1による変換結果）が、ユーザインタフェース３０によってアプリケーションプログラム４０に渡される。
【００４８】
次に、ＸＭＬデータ変換エンジン２０内の変換ユニット２１０-2の動作について、図８のフローチャートを参照して説明する。
まず、ユーザの操作に応じて、アプリケーションプログラム４０から変換ユニット２１０-2に対して、ある論理テーブル名が通知されたものとする。この場合、変換ユニット２１０-2は、メモリ上に集約結果値を保持する領域を確保し、その領域内の集約結果値を初期化する（ステップＳ２１）。次に変換ユニット２１０-2は、アプリケーションプログラム４０から集約対象フィールドの論理名を取得する（ステップＳ２２）。ここでは変換ユニット２１０-2は、定価タグ及び価格タグに共通の＜価格＞を論理名として取得したものとする。
【００４９】
次に、変換ユニット２１０-1は第１の選択手段として機能して、ＸＭＬＤＢ１０に格納されている、アプリケーションプログラム４０から指定された論理テーブル名の論理テーブルに対応する変換対象ＸＭＬデータ（即ち物理テーブル群）から、最初の変換対象テーブル（物理テーブル）を選択する（ステップＳ２３）。次に、変換ユニット２１０-2は第２の選択手段として機能して、ＸＭＬＤＢ１０に格納されている変換規則定義ファイル１２内の変換規則定義情報のうちの、アプリケーションプログラム４０から指定された論理テーブル名で特定される変換規則定義情報から、変換対象テーブルのパスで特定される変換規則（<translate>要素）を選択する（ステップＳ２４）。
【００５０】
次に、変換ユニット２１０-2は第３の選択手段として機能して、変換対象テーブルから、最初の変換対象レコードを選択する（ステップＳ２５）。次に変換ユニット２１０-2は、変換対象レコードから、ステップＳ２２で取得した論理名の最初の集約対象フィールドを選択する（ステップＳ２６）。そして変換ユニット２１０-2は、集約対象フィールドのタグがステップＳ２４で選択された変換規則に含まれているかを判定する（ステップＳ２７）。もし、集約対象フィールドのタグがステップＳ２４で選択された変換規則に含まれているならば、変換ユニット２１０-2は当該規則に<function>要素が含まれているかを判定し、<function>要素が含まれているならば、フィールド値変換部２２を呼び出す。するとフィールド値変換部２２は、この<function>要素で指定される変換関数を用いて、変換対象フィールドの値を変換する（ステップＳ２８）。ここでは、価格要素の要素内容である価格の値の単位が変換されたものとする。このフィールド値変換部２２によるフィールド値変換結果は変換ユニット２１０-2に返される。すると、変換ユニット２１０-2は集約手段として機能して、現在の集約結果値に、フィールド値変換部２２から返されたステップＳ２８での変換結果を反映する（ステップＳ２９）。ここでは、変換された価格の値が、現在の集約結果値に加算されたものとする。
【００５１】
また集約対象フィールドのタグがステップＳ２４で選択された変換規則に含まれていても（ステップＳ２７）、ステップＳ２４で選択された変換規則に<function>要素が含まれていないときは、変換ユニット２１０-2はステップＳ２８を行わずに集約手段として機能して、集約対象フィールドの値をそのまま現在の集約結果値に反映する。また、集約対象フィールドのタグがステップＳ２４で選択された変換規則に含まれていないときも（ステップＳ２７）、変換ユニット２１０-2は集約手段として機能して、当該集約対象フィールドの値を現在の集約結果値に反映する（ステップＳ２９ａ）。
【００５２】
変換ユニット２１０-2はステップＳ２９または２９ａを実行するとステップＳ３０に進む。このステップＳ３０において、変換ユニット２１０-2は、変換対象テーブルに未処理のレコードが残っているかを判定する。もし、未処理のレコードが残っているならば、変換ユニット２１０-2は第３の選択手段として機能して、変換対象テーブルから次の変換対象レコードを選択し（ステップＳ３１）、当該変換対象レコードについて上記ステップＳ２６から始まる処理を実行する。これに対し、未処理のレコードが残っていないならば、変換ユニット２１０-2は、ＸＭＬＤＢ１０内の変換対象ＸＭＬデータ（アプリケーションプログラム４０から指定された論理テーブル名の論理テーブルに対応する物理テーブル群）に未処理のテーブルが残っているかを判定する（ステップＳ３２）。
【００５３】
もし、未処理のテーブルが残っているならば、変換ユニット２１０-2は第１の選択手段として機能して、変換対象データ（物理テーブル群）から次の変換対象テーブルを選択する（ステップＳ３３）。そして変換ユニット２１０-2は、選択された変換対象テーブルについて上記ステップＳ２４から始まる処理を実行する。これに対し、未処理のテーブルが残っていないならば、その時点における集約結果値（つまり変換ユニット２１０-2による変換結果）が、ユーザインタフェース３０によってアプリケーションプログラム４０に渡される。
【００５４】
なお、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。
【図面の簡単な説明】
【００５５】
【図１】本発明の一実施形態に係るＸＭＬデータ変換装置の構成を示すブロック図。
【図２】図１に示されている変換規則定義ファイル１２の記述内容の一般形を示す図。
【図３】アプリケーションプログラム４０からの論理テーブル名で特定される、変換対象テーブル（物理テーブル）３３及び３４を含む変換対象データ（ＸＭＬデータ）と、当該変換対象テーブル３３及び３４中の変換対象レコード３１及び３２の一例とを示す図。
【図４】図３に示されている、物理形式の異なる２種類のレコード３１及び３２の間のフィールドの対応関係を表形式で示す図。
【図５】図３中のレコード３１及び３２を対象とするデータ変換後のレコード３１０及び３２０の一例を示す図。
【図６】図３のレコード３１を含むテーブル３３及びレコード３２を含むテーブル３４を、それぞれ図５のレコード３１０を含むテーブル及びレコード３２０を含むテーブルに変換するための、変換規則定義情報１２０-1の具体例を示す図。
【図７】ＸＭＬデータ変換エンジン２０内の変換ユニット２１０-1の処理手順を示すフローチャート。
【図８】ＸＭＬデータ変換エンジン２０内の変換ユニット２１０-2の処理手順を示すフローチャート。
【符号の説明】
【００５６】
１０…ＸＭＬＤＢ（ＸＭＬデータベース）、１１…物理データ、１２…変換規則定義ファイル、２０…ＸＭＬデータ変換エンジン（変換手段）、２１…形式変換部（フィールド変換手段）、２２…フィールド値変換部（フィールド値変換手段）、３０…ユーザインタフェース、３１，３２…レコード（物理レコード）、３３，３４…テーブル（物理テーブル）、４０…アプリケーションプログラム、１１０-1，１１０-2，１１０-3…テーブル（物理テーブル）、１２０-1，１２０-2…変換規則定義情報、２１０-1，２１０-2…変換ユニット、２２１…変換関数（四捨五入関数）、２２２…変換関数（単位変換関数），３１０，３２０…レコード（論理レコード）。
【技術分野】
【０００１】
本発明は、構造化データ（構造化文書）の形式を変換する構造化データ変換装置及び変換方法に係り、特に、構造化データ（構造化文書）の一種である半構造化データ（半構造化文書）として知られているＸＭＬデータ（ＸＭＬ文書）の表現形式を変換するのに好適な構造化データ変換装置及び方法に関する。
【背景技術】
【０００２】
データを記述する手段として、ＸＭＬ(Extensible Markup Language)が広く利用されている。このＸＭＬを用いて記述されたデータ（文書）はＸＭＬデータ（ＸＭＬ文書）と呼ばれる。
【０００３】
ＸＭＬデータは、論理的に、階層を持った木構造を表現し、構造化データ（構造化文書）の一種である半構造化データ（半構造化文書）として知られている。ＸＭＬは、タグ、属性名、及びそれらの階層構造による自己説明性を有している。このため、ＸＭＬは、データの利用時に構造を目的に合わせて整形したり、その中から必要な情報を抽出することが可能な特長を持つ。特に昨今、技術発展の顕著なＸＭＬデータベース（ＸＭＬＤＢ）では、データ構造を事前に規定することなく応用ソフトウェア（アプリケーション）がそれぞれの固有形式で情報登録しても、それらの情報に陰に含まれる共通構造に注目して一括処理や分析を行うアプリケーションを実現可能であるという大きな効用をもたらしている。
【０００４】
従来、データ登録アプリケーションに固有の形式でＸＭＬＤＢに格納されたデータを、利用時に目的の構造に読み替える（つまり変換する）には、大別して次の２つの方法（変換方法）がある。
【０００５】
１つは、アプリケーションが、ＤＢから読み取ったデータを目的の構造に変換するか、もしくは、その中の参照する情報項目を直接に取り出して変換する方法（方法１）である。もう１つは、ＤＢから対象データを形式毎にいったん取り出し、これを変換して形式を共通化する方法（方法２）である。この変換法の定義と変換の実行には、ＸＭＬの標準の１つであるＸＳＬＴ（XSL Transformations, XSL:Extensible Stylesheet Language)が用いられる（例えば、非特許文献１参照）。
【非特許文献１】XSL Transformations (XSLT) Version 1.0，[online]，平成１１年１１月１６日，World Wide Web Consortium (W3C)，[平成１６年６月２１日検索]，インターネット<URL: http://www.w3.org/TR/1999/REC-xslt-19991116>
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上記した従来技術、例えば方法１には、データ読み替えの多くの処理は類似しているにも拘わらず、アプリケーションがそれぞれの読み替え処理をプログラミングしなければならない問題がある。一方、方法２には、データを格納形式毎に一旦取り出して、ＸＳＬＴプロセッサを実行しなければならないため、実行効率が悪いという問題がある。ＸＳＬＴプロセッサは、ＸＳＬＴスタイルシート（変換法の定義）を利用して変換結果を出力するプログラムである。
【０００７】
また、方法１及び２のいずれも、元のデータの形式が複数存在する場合にアプリケーションはそのことを考慮しなければならないため、プログラミングが複雑になると共に、元のデータの形式が増大したときの拡張性に欠けるという問題もある。
【０００８】
本発明は上記事情を考慮してなされたものでその目的は、アプリケーションが個別にデータの読み替え処理をプログラミングしなくても、異なる構造化データを、共通化された構造を持つものとして参照できる構造化データ変換装置及び方法を提供することにある。
【課題を解決するための手段】
【０００９】
本発明の１つの観点によれば、データベースに記憶された構造化データの形式を変換する構造化データ変換装置が提供される。この構造化データ変換装置は、上記データベースに記憶された、見かけ上の構造は異なるが、共通の論理構造を持つと見なされる予め定められた要素群の組毎に用意される変換規則定義情報であって、当該組内の物理形式が共通の上記要素群毎にそれぞれ対応した変換規則を含む変換規則定義情報の１つが、上記構造化データを利用するアプリケーションプログラムから指定された場合、当該指定された変換規則定義情報に従って、上記データベースに記憶されたデータの形式である物理形式を、共通の論理構造を表す形式である論理形式に変換する変換手段と、この変換手段によって変換された論理形式を持ったデータが上記データベースに存在するかの如く、当該変換手段による変換結果を上記アプリケーションプログラムに返すインタフェース手段とを備える。
【００１０】
このような構成においては、アプリケーションプログラムによって任意の変換規則定義情報が指定されると、その変換規則定義情報に対応する要素群の組、即ち見かけ上の構造は異なるが、共通の論理構造を持つと見なされる要素群の組を対象に、当該指定された変換規則定義情報に従って、構造化データの物理形式が論理形式に変換される。そして、変換された論理形式を持った構造化データがデータベースに存在するかの如く、その変換結果がアプリケーションプログラムに返される。
【００１１】
このように、上記の構成によれば、アプリケーションプログラムは、構造化データ変換装置の変換手段に対して任意の変換規則定義情報を指定するだけで、当該アプリケーションプログラムが個別にデータの読み替え処理をプログラミングしなくても、当該アプリケーションプログラムからは、当該変換規則定義情報に対応した、見かけ上の構造が異なるデータベース内の構造化データを、共通化された構造を持つものとして参照できる。しかも、元のデータの形式が増大したときにも、それに合わせて変換規則定義情報を変更するだけで容易に対応できるため、拡張性に富む。更に、データベース内の元の構造化データが、見かけ上の構造が異なる幾つかのグループから構成されていても、アプリケーションプログラムに対し、共通化された構造のデータが連続して存在するように認識させることができる。
【００１２】
ここで、データベースに記憶された要素群の組毎に用意される変換規則定義情報に、それぞれ識別情報が付与される構成とするならば、上記変換手段に次のような機能、即ち、アプリケーションプログラムから任意の変換規則定義情報の識別情報が指定された場合に、データベースに記憶された変換規則定義情報のうちの、当該識別情報が付与されている変換規則定義情報が指定されたとして、当該指定された変換規則定義情報に従う変換を行う機能を持たせると良い。ここで、上記識別情報に名前を用いるならば、アプリケーションプログラムは名前を指定するだけで、データ変換に用いる変換規則定義情報と変換の対象となる要素群の組を指定できる。
【００１３】
また、上記変換規則定義情報に含まれている変換規則が、当該変換規則を適用する要素群中の各要素に共通のフィールド変換規則であって、当該各要素の下に位置する任意の要素であるフィールドのうち、共通の論理構造に対応した物理構造を持つフィールドの変換規則であるフィールド変換規則を含む構成とするならば、上記変換手段に次のようなフィールド変換手段、即ち、上記フィールド変換規則に従い、対応するフィールドの物理形式を論理形式に変換するフィールド変換手段を持たせると良い。この変換規則を適用する要素群中の各要素の下に位置する要素であるフィールドのうち、フィールド変換規則で定義されるフィールドについて、物理形式を論理形式に変換するフィールド変換を自動的に行うことができる。
【００１４】
特に、変換規則定義情報に含まれている変換規則が、当該変換規則を適用する要素群の格納箇所を示すパスの情報を含み、フィールド変換規則が、対応するフィールドの変換前の要素名を表す変換前タグと変換後の要素名を表す変換後タグとを含む構成とするならば、上記変換手段に次のような各手段、即ち、指定された変換規則定義情報を適用する要素群の組の中から、変換対象となる要素群を順次選択する第１の選択手段と、指定された変換規則定義情報の中から、この第１の選択手段によって選択された要素群の格納箇所を表すパスで特定される変換規則を選択する第２の選択手段と、上記第１の選択手段によって選択された要素群から、変換対象となる要素を順次選択する第３の選択手段とを持たせ、この第３の選択手段によって選択された要素中の各フィールドのうち、第２の選択手段によって選択された変換規則中のフィールド変換規則に含まれている変換前タグに一致するタグを含むフィールドの物理形式が、上記フィールド変換手段により当該フィールド変換規則に従って論理形式に変換される構成とすると良い。
【００１５】
また、フィールド変換規則にフィールド値の変換を定義したフィールド値変換規則が含まれる構成とするならば、上記変換手段に、次のような手段、即ちフィールド変換規則による変換の対象となるフィールドの値をフィールド値変換規則に従って変換するフィールド値変換手段を持たせると良い。このような構成においては、フィールドの物理形式を論理形式に変換することにより、フィールド値と変換後の形式との間に矛盾が生じる場合に、その矛盾を解消することができる。例えば、＜定価＞フィールド（定価要素）のフィールド値（要素内容）は千円単位で表され、＜価格＞フィールド（価格要素）のフィールド値（要素内容）は円単位で表される場合に、＜定価＞タグを共通化された＜価格＞タグに変換する場合、そのフィールド値（要素内容）を千円単位から円単位に変換することができる。
【００１６】
また、上記変換手段に、次のような手段、即ちアプリケーションプログラムから集約型の操作と、当該集約型の操作の対象となる集約対象フィールドの論理形式を表す論理名が指定された場合、上記フィールド変換規則に上記フィールド値変換規則が含まれているならば、上記指定された集約対象フィールドの値に対する変換後の値を、その時点までの集約結果に反映し、上記フィールド変換規則に上記フィールド値変換規則が含まれていないならば、上記指定された集約対象フィールドの値を、その時点までの集約結果に反映する集約手段を持たせると良い。このような構成においては、指定された集約対象フィールドの変換後の値を集約結果に反映することが可能となるため、フィールド値と変換後の形式との間の矛盾を解消しながら、集約対象フィールドの値を集約すること、例えば単位が統一された集約対象フィールドの値を加算することができる。
【発明の効果】
【００１７】
本発明によれば、アプリケーションプログラムから任意の変換規則定義情報を指定するだけで、その変換規則定義情報に対応する要素群の組である、見かけ上の構造は異なるが、共通の論理構造を持つと見なされる要素群の組を対象に、当該指定された変換規則定義情報に従って、構造化データの物理形式が論理形式に変換され、その変換された論理形式を持った構造化データがデータベースに存在するかの如く、その変換結果がアプリケーションプログラムに返される。このため、アプリケーションプログラムは、個別にデータの読み替え処理をプログラミングしなくても、当該変換規則定義情報に対応した、見かけ上の構造が異なるデータベース内の構造化データを、共通化された構造を持つものとして参照できる。
【発明を実施するための最良の形態】
【００１８】
以下、本発明を、構造化データ（半構造化データ）の代表であるＸＭＬデータの表現形式を変換するＸＭＬデータ変換装置に適用した一実施形態につき図面を参照して説明する。
図１は本発明の一実施形態に係るＸＭＬデータ変換装置の構成を示すブロック図である。ＸＭＬデータ変換装置は、ＸＭＬＤＢ（ＸＭＬデータベース）１０と、ＸＭＬデータ変換エンジン２０と、ユーザインタフェース３０とを備えている。ＸＭＬＤＢ１０はハードディスクドライブに代表される外部記憶装置（図示せず）に保存されているものとする。なお、ＸＭＬＤＢ１０をＸＭＬデータ変換装置から独立させて、例えばネットワークを介して当該ＸＭＬデータ変換装置内の変換エンジン２０からアクセス可能な構成とすることも可能である。この場合、ＸＭＬＤＢ１０を、複数のＸＭＬデータ変換装置で共有することも可能である。
【００１９】
ＸＭＬは均質な階層構造で表されるデータである。しかし、以下の説明においては便宜上、共通構造の認識に基づき処理される要素を「レコード」、レコードの下に位置する要素を「フィールド」、レコード群を子要素とする要素を「テーブル」と表現する。
【００２０】
ＸＭＬＤＢ１０には、ＸＭＬデータ変換エンジン２０による変換の対象となり得るＸＭＬデータである物理データ（元データ）１１が格納される。物理データ１１は、レコード群を子要素として有する幾つかのテーブル（物理テーブル、物理要素群）、例えば３つのテーブル１１０-1，１１０-2及び１１０-3を含む。テーブル１１０-iは、定められた特徴を備えたデータではなく、共通な構造を持った要素（レコード）群に対する外部からの意味づけ結果を示すデータである。
【００２１】
ＸＭＬＤＢ１０にはまた、ＸＭＬデータ変換エンジン２０によって適用されるＸＭＬデータ変換の規則（ＸＭＬデータ変換法）を定義した情報（変換規則定義情報）のファイル（以下、変換規則定義ファイルと称する）１２も格納される。ここでは、変換規則定義ファイル１２は、変換規則定義情報１２０-1及び１２０-2を含む変換規則定義情報の集合として定義されており、ファイル名によって管理される通常のデータファイルとは異なるものとする。変換規則定義情報１２０-j（ｊ＝１，２）は、ＸＭＬデータの表現形式を物理形式から論理形式に変換するための変換規則を定義した情報である。ここで、物理形式とは、変換対象となるＸＭＬデータの元の表現形式をいい、論理形式とは、元の表現形式と共通な論理構造の目的とする表現形式をいう。
【００２２】
ＸＭＬデータ変換エンジン２０は、変換規則定義ファイル１２内の変換規則定義情報１２０-jに基づきＸＭＬデータを物理形式から論理形式に変換する。ＸＭＬデータ変換エンジン２０は、形式形式変換部２１とフィールド値変換部２２とを備えている。
【００２３】
形式変換部２１はＸＭＬデータ変換の実行部であり、ＸＭＬデータ変換エンジン２０の中枢部をなす。形式変換部２１は、アプリケーション（アプリケーションプログラム）４０からユーザインタフェース３０を介して与えられるＸＭＬデータ変換要求に応じて、物理形式から論理形式へのＸＭＬデータ変換を実行する。形式変換部２１は、例えば２つの変換ユニット２１０-1及び２１０-2を含む。変換ユニット２１０-1及び２１０-2は、変換により得られる論理形式データの処理法に応じて選択して用いられる。変換ユニット２１０-1は、ＸＭＬデータ変換により構造を共通化された論理レコード群を、一括してアプリケーションプログラム４０に渡す処理（以下、処理１と称する）を適用する。一方、変換ユニット２１０-2は、上記論理レコード群に対して集約型の操作を行った結果をアプリケーションプログラム４０に渡す処理（以下、処理２と称する）を適用する。集約型の操作とは、論理レコード群を集約する操作を指し、例えば定価要素の要素内容と価格要素の要素内容を、いずれも価格要素の要素内容として、それらの総和を算出する操作が挙げられる。また、エラー要素の要素内容（エラーの有無）と誤り要素の要素内容（誤りの有無）を、いずれもエラー要素の要素内容として、１つでもエラー（誤り）があれば、不良とする操作も集約型の操作である。変換ユニット２１０-1及び２１０-2のいずれを用いるかは、ユーザの選択操作に応じてアプリケーションプログラム４０から指定される。
【００２４】
フィールド値変換部２２は、変換規則定義情報１２０-jによりフィールド値の変換が指定されたとき、形式変換部２１（内の変換ユニット２１０-1または２１０-2）から呼び出されて、その値の変換を実行する。フィールド値変換部２２は、例えば、値を四捨五入するための変換関数（四捨五入関数）２２１と、値の単位を変換するための変換関数（単位変換関数）２２２とを有する。
【００２５】
ユーザインタフェース３０は、ＸＭＬデータ変換エンジン２０とアプリケーションプログラム４０（のユーザ）とのインタフェースである。ユーザインタフェース３０は、ユーザの操作に応じてアプリケーションプログラム４０から送られるＸＭＬデータ変換（物理形式から論理形式への変換）の要求を、ＸＭＬデータ変換エンジン２０（内の形式変換部２１）に通知する。ユーザインタフェース３０はまた、ＸＭＬデータ変換エンジン２０（内の形式変換部２１）によるＸＭＬデータの変換結果（つまり、物理形式から論理形式への変換結果）をアプリケーションプログラム４０に通知する。アプリケーションプログラム４０は、通知された変換結果（ＸＭＬデータの変換結果）を利用する。
【００２６】
ＸＭＬデータ変換エンジン２０は、計算機にインストールされた特定のソフトウェアプログラムを当該計算機が読み取って実行することにより実現される。このプログラムは、コンピュータで読み取り可能な記憶媒体（フロッピー（登録商標）ディスクに代表される磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤに代表される光ディスク、フラッシュメモリに代表される半導体メモリ等）に予め格納して頒布可能である。また、このプログラムが、ネットワークを介してダウンロード（頒布）されても構わない。
【００２７】
図２は、変換規則定義ファイル１２の記述内容の一般形を示す。図２において、各タグで表わされた記述項目は次のように定義される。
<logical-table>要素１２１は、変換規則定義ファイル１２全体、つまり変換規則定義情報１２０-jの集合を表わす。
【００２８】
<map>要素１２２は、１つの変換規則定義情報１２０-jを表わす。この<map>要素２０２が１つの論理的なテーブルを与える。<map>要素２０２は、仮想的に共通構造を持つと見せるデータ群（論理テーブル）毎に用意される。
<name>要素１２３は、論理テーブル名を表す。変換規則定義情報１２０-jは、アプリケーションプログラム４０からこの論理テーブル名によって識別される。つまり変換規則定義情報１２０-jには、固有の論理テーブル名が付与されている。
<recordname>要素１２４は、変換後レコード（論理レコード）タグを表す。
【００２９】
<translate>要素１２５は、変換元のデータからなるテーブル（物理テーブル）毎に用意される、レコード変換の規則を定義した情報である。
<path>要素１２６は、物理テーブルのパスを表す。
<field>要素１２７は、物理テーブルから論理テーブルに変換するとき、変換対象となるフィールドの変換規則を定義した情報である。
【００３０】
<physical>要素１２８は、変換対象フィールドの変換前のタグを表す。
【００３１】
<logical>要素１２９は、変換対象フィールドの変換後のタグを表す。
【００３２】
<function>要素１２Ａは、フィールド値の変換を要するとき、その変換に用いられる変換関数を指定する。
【００３３】
<param>要素１２Ｂは、<function>要素１２Ａで指定される変換関数が引数を要するとき、その引数を指定する。
【００３４】
図３は、変換対象データの一例を示す。この図３には、ＸＭＬデータ変換前の、異なる物理形式のレコード３１及び３２が、２つのパス “/root/商品カタログ” と “/root/製品情報” にそれぞれ格納されている状況と、当該レコード３１及び３２の具体例が示されている。なお、パス “/root/商品カタログ” には、レコード３１と同一の物理形式の別のレコードも格納されているものとする。つまり、パス “/root/商品カタログ” には、レコード３１を含む同一の物理形式のレコード群を子要素とする（図１中のテーブル１１０-iに相当する）テーブル３３が格納されている。同様に、パス “/root/製品情報” には、レコード３２と同一の物理形式の別のレコードも格納されているものとする。つまり、パス “/root/製品情報” には、レコード３２を含む同一の物理形式のレコード群を子要素とする（図１中のテーブル１１０-iに相当する）テーブル３４が格納されている。
【００３５】
図４は、図３に示されている、物理形式の異なる２種類のレコード３１及び３２の間のフィールドの対応関係を表形式で示す。図４には、レコード（商品カタログレコード）３１中の商品、メーカ、機種、サイズ及び定価の各フィールドと、レコード（製品情報レコード）３２中の製品、製造元、名称、画面サイズ及び価格の各フィールドとが、それぞれ対応していることが示されている。そこで、図４に示す表形式の最右端のカラムに記されたタグを持つ論理テーブルに、上述の対応関係のあるフィールドを統合し、アプリケーションプログラム４０からは共通のレコード形式に見せる変換規則の定義を考える。つまり、図３に示されている物理形式の異なるレコード３１及び３２を、それぞれ図５に示すレコード３１０及び３２０としてアプリケーションプログラム４０に提供することを考える。
【００３６】
図６は、図３のレコード３１及び３２を、それぞれ図５のレコード３１０及び３２０に変換するための、例えば変換規則定義情報１２０-1の具体例を示す。図６において、<map>要素６２２は、図２中の<map>要素１２２に相当しており、図２中の<translate>要素１２５に相当する２つの<translate>要素６２５-1及び６２５-2を含む。<translate>要素６２５-1は、レコード３１を含むレコード群を子要素とするテーブル３３（図３参照）に対応して用意され、<translate>要素６２５-2は、レコード３２を含むレコード群を子要素とするテーブル３４（図３参照）に対応して用意されている。
【００３７】
<translate>要素６２５-1は、図２中の<field>要素１２７に相当する、<field>要素６２７-1を含む。<field>要素６２７-1は、図３中のテーブル３３の子要素群、つまりレコード３１を含むレコード群に共通の、定価タグ（定価フィールド）を価格タグ（価格フィールド）に変換するためのフィールドの変換規則を定義している。<field>要素６２７-1は、図２中の<function>要素１２Ａに相当する、<function>要素６２Ａを含む。<function>要素６２Ａは、価格の単位変換のために、図１中の単位変換関数２２２を指定する。
【００３８】
一方、<translate>要素６２５-2は、３つの<field>要素６２７-2a，６２７-2b及び６２７-2cを含む。<field>要素６２７-2a，６２７-2b及び６２７-2cは、図３中のテーブル３４の子要素群、つまりレコード３２を含むレコード群に共通に用意される。<field>要素６２７-2aは、製造元タグ（製造元フィールド）をメーカータグ（メーカーフィールド）に変換するための、フィールドの変換規則を定義している。同様に、<field>要素６２７-2bは、名称タグ（名称フィールド）を機種タグ（機種フィールド）に変換するための、フィールドの変換規則を定義している。同様に、<field>要素６２７-2cは、外形／画面サイズタグ（外形／画面サイズフィールド）をサイズタグ（サイズフィールド）に変換するための、フィールドの変換規則を定義している。このように、図６に示す変換規則定義情報１２０-1は、図３中の２つのテーブル（物理テーブル）３３及び３４に含まれる各レコードを共通の論理的レコード形式に変換するために、当該各レコード内の特定のフィールドをどのように変換するかを示す変換規則を与えている。
【００３９】
次に、本実施形態の動作について、ＸＭＬデータ変換エンジン２０内の変換ユニット２１０-1の動作を例に、図７のフローチャートを参照して説明する。
まず、ユーザの操作に応じて、アプリケーションプログラム４０から変換ユニット２１０-1に対して、図６中の変換規則定義情報１２０-1を特定する論理テーブル名が通知されたものとする。この場合、変換ユニット２１０-1は、アプリケーションプログラム４０から指定された論理テーブル名の空の変換結果テーブル（論理テーブル）を、図示せぬメモリ上に用意する（ステップＳ１）。
【００４０】
次に、変換ユニット２１０-1は第１の選択手段として機能して、ＸＭＬＤＢ１０に格納されている、アプリケーションプログラム４０から指定された論理テーブル名の論理テーブルに対応する変換対象ＸＭＬデータ（即ち物理テーブル群）から、最初の変換対象テーブル（物理テーブル）を選択する（ステップＳ２）。ここでは、図３に示すテーブル３３及び３４を含むＸＭＬデータからテーブル３３が選択されたものとする。
【００４１】
次に、変換ユニット２１０-1は第２の選択手段として機能して、ＸＭＬＤＢ１０に格納されている変換規則定義ファイル１２内の変換規則定義情報のうちの、アプリケーションプログラム４０から指定された論理テーブル名で特定される変換規則定義情報から、変換対象テーブル３３のパス、つまり “/root/商品カタログ” で特定される変換規則である<translate>要素を選択する（ステップＳ３）。ここでは、アプリケーションプログラム４０から指定された論理テーブル名によって、図６に示す変換規則定義情報１２０-1が特定されるものとすると、当該変換規則定義情報１２０-1内の<translate>要素６２５-1が選択される。
【００４２】
次に、変換ユニット２１０-1は第３の選択手段として機能して、テーブル３３から、最初の変換対象レコードを選択する（ステップＳ４）。ここでは、レコード３１が変換対象レコードとして選択されたものとする。変換ユニット２１０-1は、変換対象レコード３１から最初の変換対象フィールドを選択する（ステップＳ５）。ここでは、レコード３１からメーカー要素（図３参照）が変換対象フィールドとして選択されたものとする。
【００４３】
変換ユニット２１０-1は、変換対象フィールド（メーカー要素）のタグ（メーカー）が<translate>要素６２５-1中の変換規則に含まれているかを判定する（ステップＳ６）。<translate>要素６２５-1中の変換規則に含まれるタグは、図６に示されるように、定価タグのみである。この場合、変換ユニット２１０-1は、後述するステップＳ７及びＳ８をスキップしてステップＳ９に進む。このステップＳ９において、変換ユニット２１０-1は、、現在処理中のテーブル３３に未処理のフィールドが残っているかを判定する。この例のように、未処理のフィールドが残っている場合、変換ユニット２１０-1はテーブル３３から次の変換対象フィールドを選択する（ステップＳ１０）。ここでは、図３から明らかなように、メーカー要素の次の品名要素が変換対象フィールドとして選択される。
【００４４】
変換ユニット２１０-1は、次の変換対象フィールド（＝品名要素）を選択すると、ステップＳ６に戻る。このステップＳ６において、変換ユニット２１０-1は、変換対象フィールド（品名要素）のタグ（品名）が<translate>要素６２５-1中の変換規則に含まれているかを判定する。ここで、変換対象フィールドである品名要素のタグ（品名）は、<translate>要素６２５-1中の変換規則に含まれていない。この場合、テーブル３３中の残りのフィールドについて、同様の処理が繰り返される。
【００４５】
さて、テーブル３３中の残りのフィールド、つまり機種要素、サイズ要素、重量要素及び定価要素の各タグのうち、<translate>要素６２５-1中の変換規則に含まれているタグは、定価タグのみである。変換ユニット２１０-1は、次の変換対象フィールドとしてテーブル３３から定価要素を選択した場合（ステップＳ１０）、当該価格要素のタグが<translate>要素６２５-1中の変換規則に含まれていると判定する（ステップＳ６）。ここでは、価格要素のタグが<translate>要素６２５-1中の<field>要素６２７-1に含まれている。この場合、変換ユニット２１０-1は、<field>要素６２７-1に<function>要素が含まれているかを判定し、<function>要素が含まれているならば、フィールド値変換部２２を呼び出す。するとフィールド値変換部２２は、<field>要素６２７-1に含まれている<function>要素で指定される変換関数を用いて、変換対象フィールドの値を変換する（ステップＳ７）。本実施形態では、<field>要素６２７-1中の<function>要素で単位変換関数２２２が指定されると共に、引数として１０００が指定されている。これにより、ステップＳ７では、変換対象フィールドの値、つまり定価要素の要素内容である「２９８」（図３参照）が、「２９８０００」に変換される。このフィールド値変換部２２によるフィールド値変換結果は変換ユニット２１０-1に返される。また変換ユニット２１０-1は、<field>要素６２７-1の変換規則（図６参照）に従い、変換対象フィールドのパス、つまり定価要素のタグを＜定価＞から＜価格＞に変換する（ステップＳ８）。
【００４６】
変換ユニット２１０-1は、テーブル（物理テーブル）３３中のレコード（物理レコード）３１に含まれている全てのフィールド（要素）について処理し終えると（ステップＳ９）、当該レコード３１を対象としたフィールド毎のデータ変換の結果である変換結果レコード（論理レコード）を変換結果テーブル（論理テーブル）に追加する（ステップＳ１１）。次に変換ユニット２１０-1は、テーブル３３に未処理のレコードが残っているかを判定する（ステップＳ１２）。もし、未処理のレコードが残っているならば、変換ユニット２１０-1は第３の選択手段として機能して、テーブル３３から次の変換対象レコードを選択し（ステップＳ１３）、当該変換対象レコードについて上記ステップＳ５から始まる処理を実行する。これに対し、未処理のレコードが残っていないならば、変換ユニット２１０-1は、ＸＭＬＤＢ１０内の変換対象データに未処理のテーブルが残っているかを判定する（ステップＳ１４）。この例のように、未処理のテーブルが残っているならば、変換ユニット２１０-1は第１の選択手段として機能して、変換対象データから次の変換対象テーブルを選択する（ステップＳ１５）。ここでは、図３に示されているテーブル３４が選択される。
【００４７】
変換ユニット２１０-1は、テーブル３４を変換対象テーブルとして選択すると、当該テーブル３４について上記ステップＳ３から始まる処理を実行する。ここでは、テーブル３４のパス、つまり “/root/製品情報” で特定される変換規則である<translate>要素６２５-2（図６参照）が選択される（ステップＳ３）。また、テーブル３４中のレコード、例えばレコード３２について、当該レコード３２に含まれている製造元要素、名称要素、外形要素及び価格要素のうち、製造元要素、名称要素及び外形要素が変換対象フィールドとして、それぞれ、<translate>要素６２５-2に含まれている<field>要素６２７-2a，６２７-2b及び６２７-2cの変換規則（図６参照）に従うデータ変換が行われる。ここでは、<field>要素６２７-2a，６２７-2b及び６２７-2cには、いずれも<function>要素は含まれていない。この場合、製造元要素、名称要素及び外形要素のパス（タグ）である＜製造元＞、＜名称＞及び＜外形／画面サイズ＞が、それぞれ＜メーカー＞、＜機種＞及び＜サイズ＞に変換される（ステップＳ８）。これら、テーブル（物理テーブル）３３中のレコード（物理レコード）３２に含まれている製造元要素、名称要素及び外形要素を変換対象フィールドとした変換結果のレコード（論理レコード）は、変換結果テーブル（論理テーブル）に追加される（ステップＳ１１）。やがて、ＸＭＬＤＢ１０内の変換対象データに含まれている全てのテーブル（物理テーブル）についての処理が完了すると、その時点において変換結果テーブル（論理テーブル）に格納されている論理レコードの群（つまり変換ユニット２１０-1による変換結果）が、ユーザインタフェース３０によってアプリケーションプログラム４０に渡される。
【００４８】
次に、ＸＭＬデータ変換エンジン２０内の変換ユニット２１０-2の動作について、図８のフローチャートを参照して説明する。
まず、ユーザの操作に応じて、アプリケーションプログラム４０から変換ユニット２１０-2に対して、ある論理テーブル名が通知されたものとする。この場合、変換ユニット２１０-2は、メモリ上に集約結果値を保持する領域を確保し、その領域内の集約結果値を初期化する（ステップＳ２１）。次に変換ユニット２１０-2は、アプリケーションプログラム４０から集約対象フィールドの論理名を取得する（ステップＳ２２）。ここでは変換ユニット２１０-2は、定価タグ及び価格タグに共通の＜価格＞を論理名として取得したものとする。
【００４９】
次に、変換ユニット２１０-1は第１の選択手段として機能して、ＸＭＬＤＢ１０に格納されている、アプリケーションプログラム４０から指定された論理テーブル名の論理テーブルに対応する変換対象ＸＭＬデータ（即ち物理テーブル群）から、最初の変換対象テーブル（物理テーブル）を選択する（ステップＳ２３）。次に、変換ユニット２１０-2は第２の選択手段として機能して、ＸＭＬＤＢ１０に格納されている変換規則定義ファイル１２内の変換規則定義情報のうちの、アプリケーションプログラム４０から指定された論理テーブル名で特定される変換規則定義情報から、変換対象テーブルのパスで特定される変換規則（<translate>要素）を選択する（ステップＳ２４）。
【００５０】
次に、変換ユニット２１０-2は第３の選択手段として機能して、変換対象テーブルから、最初の変換対象レコードを選択する（ステップＳ２５）。次に変換ユニット２１０-2は、変換対象レコードから、ステップＳ２２で取得した論理名の最初の集約対象フィールドを選択する（ステップＳ２６）。そして変換ユニット２１０-2は、集約対象フィールドのタグがステップＳ２４で選択された変換規則に含まれているかを判定する（ステップＳ２７）。もし、集約対象フィールドのタグがステップＳ２４で選択された変換規則に含まれているならば、変換ユニット２１０-2は当該規則に<function>要素が含まれているかを判定し、<function>要素が含まれているならば、フィールド値変換部２２を呼び出す。するとフィールド値変換部２２は、この<function>要素で指定される変換関数を用いて、変換対象フィールドの値を変換する（ステップＳ２８）。ここでは、価格要素の要素内容である価格の値の単位が変換されたものとする。このフィールド値変換部２２によるフィールド値変換結果は変換ユニット２１０-2に返される。すると、変換ユニット２１０-2は集約手段として機能して、現在の集約結果値に、フィールド値変換部２２から返されたステップＳ２８での変換結果を反映する（ステップＳ２９）。ここでは、変換された価格の値が、現在の集約結果値に加算されたものとする。
【００５１】
また集約対象フィールドのタグがステップＳ２４で選択された変換規則に含まれていても（ステップＳ２７）、ステップＳ２４で選択された変換規則に<function>要素が含まれていないときは、変換ユニット２１０-2はステップＳ２８を行わずに集約手段として機能して、集約対象フィールドの値をそのまま現在の集約結果値に反映する。また、集約対象フィールドのタグがステップＳ２４で選択された変換規則に含まれていないときも（ステップＳ２７）、変換ユニット２１０-2は集約手段として機能して、当該集約対象フィールドの値を現在の集約結果値に反映する（ステップＳ２９ａ）。
【００５２】
変換ユニット２１０-2はステップＳ２９または２９ａを実行するとステップＳ３０に進む。このステップＳ３０において、変換ユニット２１０-2は、変換対象テーブルに未処理のレコードが残っているかを判定する。もし、未処理のレコードが残っているならば、変換ユニット２１０-2は第３の選択手段として機能して、変換対象テーブルから次の変換対象レコードを選択し（ステップＳ３１）、当該変換対象レコードについて上記ステップＳ２６から始まる処理を実行する。これに対し、未処理のレコードが残っていないならば、変換ユニット２１０-2は、ＸＭＬＤＢ１０内の変換対象ＸＭＬデータ（アプリケーションプログラム４０から指定された論理テーブル名の論理テーブルに対応する物理テーブル群）に未処理のテーブルが残っているかを判定する（ステップＳ３２）。
【００５３】
もし、未処理のテーブルが残っているならば、変換ユニット２１０-2は第１の選択手段として機能して、変換対象データ（物理テーブル群）から次の変換対象テーブルを選択する（ステップＳ３３）。そして変換ユニット２１０-2は、選択された変換対象テーブルについて上記ステップＳ２４から始まる処理を実行する。これに対し、未処理のテーブルが残っていないならば、その時点における集約結果値（つまり変換ユニット２１０-2による変換結果）が、ユーザインタフェース３０によってアプリケーションプログラム４０に渡される。
【００５４】
なお、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。
【図面の簡単な説明】
【００５５】
【図１】本発明の一実施形態に係るＸＭＬデータ変換装置の構成を示すブロック図。
【図２】図１に示されている変換規則定義ファイル１２の記述内容の一般形を示す図。
【図３】アプリケーションプログラム４０からの論理テーブル名で特定される、変換対象テーブル（物理テーブル）３３及び３４を含む変換対象データ（ＸＭＬデータ）と、当該変換対象テーブル３３及び３４中の変換対象レコード３１及び３２の一例とを示す図。
【図４】図３に示されている、物理形式の異なる２種類のレコード３１及び３２の間のフィールドの対応関係を表形式で示す図。
【図５】図３中のレコード３１及び３２を対象とするデータ変換後のレコード３１０及び３２０の一例を示す図。
【図６】図３のレコード３１を含むテーブル３３及びレコード３２を含むテーブル３４を、それぞれ図５のレコード３１０を含むテーブル及びレコード３２０を含むテーブルに変換するための、変換規則定義情報１２０-1の具体例を示す図。
【図７】ＸＭＬデータ変換エンジン２０内の変換ユニット２１０-1の処理手順を示すフローチャート。
【図８】ＸＭＬデータ変換エンジン２０内の変換ユニット２１０-2の処理手順を示すフローチャート。
【符号の説明】
【００５６】
１０…ＸＭＬＤＢ（ＸＭＬデータベース）、１１…物理データ、１２…変換規則定義ファイル、２０…ＸＭＬデータ変換エンジン（変換手段）、２１…形式変換部（フィールド変換手段）、２２…フィールド値変換部（フィールド値変換手段）、３０…ユーザインタフェース、３１，３２…レコード（物理レコード）、３３，３４…テーブル（物理テーブル）、４０…アプリケーションプログラム、１１０-1，１１０-2，１１０-3…テーブル（物理テーブル）、１２０-1，１２０-2…変換規則定義情報、２１０-1，２１０-2…変換ユニット、２２１…変換関数（四捨五入関数）、２２２…変換関数（単位変換関数），３１０，３２０…レコード（論理レコード）。
【特許請求の範囲】
【請求項１】
データベースに記憶された構造化データの形式を変換する構造化データ変換装置において、
前記データベースに記憶された、見かけ上の構造は異なるが、共通の論理構造を持つと見なされる予め定められた要素群の組毎に用意される変換規則定義情報であって、当該組内の物理形式が共通の前記要素群毎にそれぞれ対応した変換規則を含む変換規則定義情報の１つが、前記構造化データを利用するアプリケーションプログラムから指定された場合、当該指定された変換規則定義情報に従って、対応する要素群の組を対象に、前記データベースに記憶された構造化データの形式である物理形式を、共通の論理構造を表す形式である論理形式に変換する変換手段と、
前記変換手段によって変換された論理形式を持った構造化データが前記データベースに存在するかの如く、前記変換手段による変換結果を前記アプリケーションプログラムに返すインタフェース手段と
を具備することを特徴とする構造化データ変換装置。
【請求項２】
前記データベースに記憶された前記要素群の組毎に用意される前記変換規則定義情報にはそれぞれ識別情報が付与されており、
前記変換手段は、前記アプリケーションプログラムから任意の変換規則定義情報の識別情報が指定された場合に、前記データベースに記憶された前記変換規則定義情報のうちの、当該識別情報が付与されている変換規則定義情報が指定されたとして、当該指定された変換規則定義情報に従う変換を行う
ことを特徴とする請求項１記載の構造化データ変換装置。
【請求項３】
前記変換規則定義情報に含まれている前記変換規則は、当該変換規則が適用される要素群中の各要素に共通のフィールド変換規則であって、当該各要素の下に位置する任意の要素であるフィールドのうち、共通の論理構造に対応した物理構造を持つフィールドの変換規則であるフィールド変換規則を含み、
前記変換手段は、前記フィールド変換規則に従い、対応するフィールドの物理形式を論理形式に変換するフィールド変換手段を含む
ことを特徴とする請求項１記載の構造化データ変換装置。
【請求項４】
前記変換規則定義情報に含まれている前記変換規則は、当該変換規則が適用される前記要素群の格納箇所を示すパスの情報を含み、前記フィールド変換規則は、対応するフィールドの変換前の要素名を表す変換前タグと変換後の要素名を表す変換後タグとを含み、
前記変換手段は、前記指定された変換規則定義情報が適用される要素群の組の中から、変換対象となる要素群を順次選択する第１の選択手段と、前記指定された変換規則定義情報の中から、前記第１の選択手段によって選択された要素群の格納箇所を表すパスで特定される変換規則を選択する第２の選択手段と、前記第１の選択手段によって選択された要素群から、変換対象となる要素を順次選択する第３の選択手段とを含み、
前記フィールド変換手段は、前記第３の選択手段によって選択された要素中の各フィールドのうち、前記第２の選択手段によって選択された変換規則中の前記フィールド変換規則に含まれている変換前タグに一致するタグを含むフィールドの物理形式を、当該フィールド変換規則に従って論理形式に変換する
ことを特徴とする請求項３記載の構造化データ変換装置。
【請求項５】
前記変換手段は、前記フィールド変換規則にフィールド値の変換を定義したフィールド値変換規則が含まれている場合に、前記フィールド変換規則による変換の対象となるフィールドの値を前記フィールド値変換規則に従って変換するフィールド値変換手段を含むことを特徴とする請求項３記載の構造化データ変換装置。
【請求項６】
前記フィールド値変換手段は、前記フィールド値変換規則によって四捨五入が指定されている場合、対応するフィールドの値を四捨五入する四捨五入手段を含むことを特徴とする請求項５記載の構造化データ変換装置。
【請求項７】
前記フィールド値変換手段は、前記フィールド値変換規則によって単位変換が指定されている場合、対応するフィールドの値の単位を変換する単位変換手段を含むことを特徴とする請求項５記載の構造化データ変換装置。
【請求項８】
前記変換手段は、前記アプリケーションプログラムから集約型の操作と、当該集約型の操作の対象となる集約対象フィールドの論理形式を表す論理名が指定された場合、前記フィールド変換規則に前記フィールド値変換規則が含まれているならば、前記指定された集約対象フィールドの値に対する変換後の値を、その時点までの集約結果に反映し、前記フィールド変換規則に前記フィールド値変換規則が含まれていないならば、前記指定された集約対象フィールドの値を、その時点までの集約結果に反映する集約手段を含むことを特徴とする請求項５記載の構造化データ変換装置。
【請求項９】
前記データベースを更に具備することを特徴とする請求項１記載の構造化データ変換装置。
【請求項１０】
データベースに記憶された構造化データの形式を変換する構造化データ変換方法において、
前記データベースに記憶された、見かけ上の構造は異なるが、共通の論理構造を持つと見なされる予め定められた要素群の組毎に用意される変換規則定義情報であって、当該組内の物理形式が共通の前記要素群毎にそれぞれ対応した変換規則を含む変換規則定義情報の１つが、前記構造化データを利用するアプリケーションプログラムから指定された場合、当該指定された変換規則定義情報に従って、対応する要素群の組を対象に、前記データベースに記憶された構造化データの形式である物理形式を、共通の論理構造を表す形式である論理形式に変換するステップと、
変換された論理形式を持った構造化データが前記データベースに存在するかの如く、前記変換するステップによる変換結果を前記アプリケーションプログラムに返すステップと
を具備することを特徴とする構造化データ変換方法。
【請求項１】
データベースに記憶された構造化データの形式を変換する構造化データ変換装置において、
前記データベースに記憶された、見かけ上の構造は異なるが、共通の論理構造を持つと見なされる予め定められた要素群の組毎に用意される変換規則定義情報であって、当該組内の物理形式が共通の前記要素群毎にそれぞれ対応した変換規則を含む変換規則定義情報の１つが、前記構造化データを利用するアプリケーションプログラムから指定された場合、当該指定された変換規則定義情報に従って、対応する要素群の組を対象に、前記データベースに記憶された構造化データの形式である物理形式を、共通の論理構造を表す形式である論理形式に変換する変換手段と、
前記変換手段によって変換された論理形式を持った構造化データが前記データベースに存在するかの如く、前記変換手段による変換結果を前記アプリケーションプログラムに返すインタフェース手段と
を具備することを特徴とする構造化データ変換装置。
【請求項２】
前記データベースに記憶された前記要素群の組毎に用意される前記変換規則定義情報にはそれぞれ識別情報が付与されており、
前記変換手段は、前記アプリケーションプログラムから任意の変換規則定義情報の識別情報が指定された場合に、前記データベースに記憶された前記変換規則定義情報のうちの、当該識別情報が付与されている変換規則定義情報が指定されたとして、当該指定された変換規則定義情報に従う変換を行う
ことを特徴とする請求項１記載の構造化データ変換装置。
【請求項３】
前記変換規則定義情報に含まれている前記変換規則は、当該変換規則が適用される要素群中の各要素に共通のフィールド変換規則であって、当該各要素の下に位置する任意の要素であるフィールドのうち、共通の論理構造に対応した物理構造を持つフィールドの変換規則であるフィールド変換規則を含み、
前記変換手段は、前記フィールド変換規則に従い、対応するフィールドの物理形式を論理形式に変換するフィールド変換手段を含む
ことを特徴とする請求項１記載の構造化データ変換装置。
【請求項４】
前記変換規則定義情報に含まれている前記変換規則は、当該変換規則が適用される前記要素群の格納箇所を示すパスの情報を含み、前記フィールド変換規則は、対応するフィールドの変換前の要素名を表す変換前タグと変換後の要素名を表す変換後タグとを含み、
前記変換手段は、前記指定された変換規則定義情報が適用される要素群の組の中から、変換対象となる要素群を順次選択する第１の選択手段と、前記指定された変換規則定義情報の中から、前記第１の選択手段によって選択された要素群の格納箇所を表すパスで特定される変換規則を選択する第２の選択手段と、前記第１の選択手段によって選択された要素群から、変換対象となる要素を順次選択する第３の選択手段とを含み、
前記フィールド変換手段は、前記第３の選択手段によって選択された要素中の各フィールドのうち、前記第２の選択手段によって選択された変換規則中の前記フィールド変換規則に含まれている変換前タグに一致するタグを含むフィールドの物理形式を、当該フィールド変換規則に従って論理形式に変換する
ことを特徴とする請求項３記載の構造化データ変換装置。
【請求項５】
前記変換手段は、前記フィールド変換規則にフィールド値の変換を定義したフィールド値変換規則が含まれている場合に、前記フィールド変換規則による変換の対象となるフィールドの値を前記フィールド値変換規則に従って変換するフィールド値変換手段を含むことを特徴とする請求項３記載の構造化データ変換装置。
【請求項６】
前記フィールド値変換手段は、前記フィールド値変換規則によって四捨五入が指定されている場合、対応するフィールドの値を四捨五入する四捨五入手段を含むことを特徴とする請求項５記載の構造化データ変換装置。
【請求項７】
前記フィールド値変換手段は、前記フィールド値変換規則によって単位変換が指定されている場合、対応するフィールドの値の単位を変換する単位変換手段を含むことを特徴とする請求項５記載の構造化データ変換装置。
【請求項８】
前記変換手段は、前記アプリケーションプログラムから集約型の操作と、当該集約型の操作の対象となる集約対象フィールドの論理形式を表す論理名が指定された場合、前記フィールド変換規則に前記フィールド値変換規則が含まれているならば、前記指定された集約対象フィールドの値に対する変換後の値を、その時点までの集約結果に反映し、前記フィールド変換規則に前記フィールド値変換規則が含まれていないならば、前記指定された集約対象フィールドの値を、その時点までの集約結果に反映する集約手段を含むことを特徴とする請求項５記載の構造化データ変換装置。
【請求項９】
前記データベースを更に具備することを特徴とする請求項１記載の構造化データ変換装置。
【請求項１０】
データベースに記憶された構造化データの形式を変換する構造化データ変換方法において、
前記データベースに記憶された、見かけ上の構造は異なるが、共通の論理構造を持つと見なされる予め定められた要素群の組毎に用意される変換規則定義情報であって、当該組内の物理形式が共通の前記要素群毎にそれぞれ対応した変換規則を含む変換規則定義情報の１つが、前記構造化データを利用するアプリケーションプログラムから指定された場合、当該指定された変換規則定義情報に従って、対応する要素群の組を対象に、前記データベースに記憶された構造化データの形式である物理形式を、共通の論理構造を表す形式である論理形式に変換するステップと、
変換された論理形式を持った構造化データが前記データベースに存在するかの如く、前記変換するステップによる変換結果を前記アプリケーションプログラムに返すステップと
を具備することを特徴とする構造化データ変換方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２００６−７９２７７（Ｐ２００６−７９２７７Ａ）
【公開日】平成１８年３月２３日（２００６．３．２３）
【国際特許分類】
【出願番号】特願２００４−２６１２６３（Ｐ２００４−２６１２６３）
【出願日】平成１６年９月８日（２００４．９．８）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【出願人】（３０１０６３４９６）東芝ソリューション株式会社 (1,478)
【Ｆターム（参考）】
【公開日】平成１８年３月２３日（２００６．３．２３）
【国際特許分類】
【出願日】平成１６年９月８日（２００４．９．８）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【出願人】（３０１０６３４９６）東芝ソリューション株式会社 (1,478)
【Ｆターム（参考）】
[ Back to top ]