JP4165086B2

JP4165086B2 - Apparatus and method for storing XML data in RDB, apparatus and method for acquiring XML data from RDB, and program

Info

Publication number: JP4165086B2
Application number: JP2002047795A
Authority: JP
Inventors: 直太稲本
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2002-02-25
Filing date: 2002-02-25
Publication date: 2008-10-15
Anticipated expiration: 2022-02-25
Also published as: JP2003248615A

Description

【０００１】
【発明の属する技術分野】
本発明はXMLデータをRDBに格納する装置およびXMLデータをRDBから取得する装置に関する。
【０００２】
【従来の技術】
XML（eXtensible Markup Language）で記述されたデータをRDB（Relational Data Base）に格納する際、XMLデータをそのまま全部ストリーム（Stream）で格納するのではなく、検索などが有効に行えるように、RDBの各カラムとXMLの各タグの値とを対応付けて幾つかのテーブルに格納する。このため、従来のこの種の格納装置は、RDBに格納しやすい他の形式のXMLデータにXMLデータを一括して変換してバッファに蓄積してからRDBに格納している。また、こうして格納されたXMLデータをRDBから取得する際には、XMLデータを一括して取り出してバッファに蓄積し、格納しやすい形式から目的のXMLデータの形式に変換している。RDBに格納しやすい形式のXMLデータは、通常XMLデータのタグがRDBのカラム名、タグの値がRDBのカラムの内容となる以下のような形式のXMLデータである。
【０００３】

【０００４】
【発明が解決しようとする課題】
このような構成を有する従来の装置では、通常XSLT（eXtensible Style Language Transformation）プロセッサやパーズツリーであるDOM（Document Object Model）オブジェクトを使用するが、一般的にXSLTプロセッサまたはDOMオブジェクトがバッファとして使用するメモリ容量は、扱うXMLデータが大きくなればそれにつれて大きくなり、装置全体が使用するメモリ量をXMLデータのサイズによらずXMLの構造を表すデータ（DTD(Document Type Definition)またはXMLShema)の大きさと同じオーダーの一定値に保つことができない。
【０００５】
その理由は、XMLデータを他形式のXMLデータに一括して変換してバッファに蓄積した後にDBに格納するため、繰り返し項目が多数あるサイズの大きいXMLデータについてこれを行う場合、使用メモリ量がXMLデータのサイズにほとんどの場合比例するからである。
【０００６】
【発明の目的】
本発明の目的は、繰り返し項目が多いXMLデータをRDBに格納する場合に、XMLデータに繰り返し項目が多数あっても使用メモリ量をXMLデータのサイズによらず、XMLの構造を表すデータDTD等の大きさと同じオーダーの一定値に保つことができるようにすることにある。
【０００７】
本発明の別の目的は、繰り返し項目が多いXMLデータをRDBから取得する場合に、XMLデータに繰り返し項目が多数あっても使用メモリ量をXMLデータのサイズによらず、XMLの構造を表すデータDTD等の大きさと同じオーダーの一定値に保つことができるようにすることにある。
【０００８】
【課題を解決するための手段】
本発明のXMLデータのRDBへの格納装置は、格納対象となるXMLデータの構造を表すデータで定義された、値が入りうる XML のタグ毎に、該タグの XPath と、該タグと対応付けられている RDB のテーブル名及びカラム名と、値を保持するバッファとの組み合わせを有し、１回以上の繰り返し指定のあるタグについてはその実際の繰り返し数に関わらず一組分だけの前記組み合わせを有する内部データを記憶するメモリと、格納対象となる前記 XML データからタグの値を読み込んで該タグの XPath を含む前記組み合わせ中の前記バッファに記憶し、該バッファに記憶したタグの値を、該タグの XPath を含む前記組み合わせ中の前記 RDB のテーブル名及びカラム名で特定される前記 RDB のテーブルのカラムに対して書き込むことにより、前記XMLデータを前記RDBへ格納する格納手段とを備え、前記格納手段は、前記XMLデータの繰り返し部分については、１つの繰り返し部分毎に、タグの値をバッファに蓄積した時点で前記RDBの当該繰り返し部分のタグの値を格納するテーブルに対して、レコード中の値が未だ定まっていないカラムにはダミーの値を使用したINSERT文を発行してレコードを挿入する手段と、前記ダミーの値を書き出したカラムの値に対応するタグの値を前記XMLデータから読み出したときにUPDATE文を発行して前記レコードを更新する手段とを含んでいる。
【０００９】
また本発明のRDBからのXMLデータの取得装置は、取得対象となるXMLデータの構造を表すデータで定義された、値が入りうる XML のタグ毎に、該タグの XPath と、該タグと対応付けられている RDB のテーブル名及びカラム名と、値を保持するバッファとの組み合わせを有し、１回以上の繰り返し指定のあるタグについてはその実際の繰り返し数に関わらず一組分だけの前記組み合わせを有する内部データを記憶するメモリと、前記 RDB のテーブルのカラムの値を読み出して該テーブル名及びカラム名を含む前記組み合わせ中の前記バッファに記憶し、該バッファに記憶したカラムの値を、該テーブル名及びカラム名を含む前記組み合わせ中の前記 XPath で特定される前記タグの値として前記 XML データに書き出すことにより、前記RDBから前記XMLデータを取得する取得手段とを備え、前記取得手段は、前記XMLデータの繰り返し部分については、当該繰り返し部分のタグの値を格納するテーブルに対してSELECT文を発行し、１レコード毎に、当該レコード中のカラムの値を該当するバッファに蓄積した後、当該繰り返し部分のタグに対応する値を前記バッファから読み出して前記XMLデータのストリームに書き出す処理を繰り返す手段を含んでいる。
【００１０】
【作用】
本発明のXMLデータのRDBからの取得装置にあっては、XMLデータの繰り返し部分については、１つの繰り返し部分毎に、タグの値をバッファに蓄積した時点でRDBの当該繰り返し部分のタグの値を格納するテーブルに対して、レコード中の値が未だ定まっていないカラムにはダミーの値を使用したINSERT文を発行してレコードを挿入する。そして、ダミーの値を書き出したカラムの値に対応するタグの値をXMLデータから読み出したときにUPDATE文を発行して更新する。これにより、XMLデータの繰り返し部分のタグの値を格納するRDBのテーブルが、その繰り返し部分に含まれない外のタグの値をも格納する場合、当該テーブルに対するデータの書き出しがINSERT文、UPDATE文による複数回に別れるものの、XMLデータの繰り返し部分の数に関わらず一組分だけのバッファだけで足り、XMLデータのサイズがいくら大きくなっても内部データのサイズはDTDの大きさを超えることがない。
【００１１】
また本発明のRDBからのXMLデータの取得装置にあっては、XMLデータの繰り返し部分については、当該繰り返し部分のタグの値を格納するテーブルに対してSELECT文を発行し、１レコード毎に、当該レコード中のカラムの値を該当するバッファに蓄積した後、当該繰り返し部分のタグに対応する値を前記バッファから読み出して前記XMLデータのストリームに書き出す処理を繰り返すため、XMLデータの繰り返し部分の数に関わらず一組分だけのバッファだけで足り、XMLデータのサイズがいくら大きくなっても内部データのサイズはDTDの大きさを超えることがない。
【００１２】
【発明の実施の形態】
次に、本発明の実施の形態について図面を参照して詳細に説明する。
【００１３】
図１を参照すると、本発明の実施の形態におけるXMLデータのRDBへの格納装置１００は、XMLデータのRDBへの格納手段１０１と、内部データDA１０１を記憶するメモリ１０２とを備え、格納対象となるXMLデータ１０３を記憶する入力装置１０４とXMLデータを格納するRDB１０５とに接続されている。入力装置１０４は例えば磁気ディスク、通信バッファ等である。なお、１１０は磁気ディスク、半導体メモリ等のコンピュータ可読記録媒体であり、格納用プログラムが記録されている。ここに記録された格納用プログラムは、格納装置１００を構成するコンピュータに読み取られ、そのコンピュータの動作を制御することにより、そのコンピュータ上にモジュールとしての格納手段１０１を実現する。
【００１４】
内部データDA１０１は、入力対象となるXMLデータ１０３毎に事前に用意されており、XMLデータ１０３の構造を表し、RDB１０５との対応関係を持ち、XMLデータ１０３の中の繰り返しの数に関わらず一組分だけのバッファを持っている。より具体的には、内部データDA１０１は、XMLデータ１０３の構造を表すデータ（DTDまたはXMLShema）について、XMLデータ１０３の繰り返し部分を子セグメントにした木構造の構造になっており、値が入りうるXMLのタグについて、そのXPathと、それと対応付けられているRDB１０５のテーブル名及びカラム名と、値を保持するバッファとを持っている。親セグメントと子セグメントとはポインタで連結される。
【００１５】
格納手段１０１は、内部データDA１０１を順番にたどると同時に入力のXMLデータ１０３を読みながらRDB１０５に対してデータ追加操作を行うSQL文を発行するように動作する。このときにXMLデータ１０３のサイズがいくら大きくなっても内部データDA１０１のサイズは、DTDの大きさを超えることがない。
【００１６】
また、本発明の実施の形態におけるRDBからのXMLデータの取得装置２００は、RDBからのXMLデータの取得手段２０１と、内部データDA２０１を記憶するメモリ２０２とを備え、XMLデータを格納するRDB２０５と取得したXMLデータ２０３を記憶する出力装置２０４とに接続されている。出力装置２０４は例えば磁気ディスク、通信バッファ等である。なお、２１０は磁気ディスク、半導体メモリ等のコンピュータ可読記録媒体であり、取得用プログラムが記録されている。ここに記録された取得用プログラムは、取得装置２００を構成するコンピュータに読み取られ、そのコンピュータの動作を制御することにより、そのコンピュータ上にモジュールとしての取得手段２０１を実現する。
【００１７】
内部データDA２０１は、取得対象となるXMLデータ２０３毎に事前に用意されており、XMLデータ２０３の構造を表し、RDB２０５との対応関係を持ち、XMLデータ２０３の中の繰り返しの数に関わらず一組分だけのバッファを持っている。より具体的には、内部データDA２０１は、XMLデータ２０３の構造を表すデータ（DTDまたはXMLShema）について、XMLデータ２０３の繰り返し部分を子セグメントにした木構造の構造になっており、値が入りうるXMLのタグについて、そのXPathと、それと対応付けられているRDB２０５のテーブル名及びカラム名と、値を保持するバッファとを持っている。親セグメントと子セグメントとはポインタで連結される。
【００１８】
取得手段２０１は、内部データDA２０１を順番にたどると同時にXMLデータ２０３を書き出しながらRDB２０５に対してデータ取得操作を行うSQL文を発行するよう動作する。このときにXMLデータ２０３のサイズがいくら大きくなっても内部データDA２０１のサイズは、DTDの大きさを超えることがない。
【００１９】
次に、図２のフローチャートを参照して本実施の形態の格納装置１００の全体の動作について詳細に説明する。
【００２０】
まず、内部データDA１０１の着目する場所を先頭にする（図２のステップS１０１）。内部データDA１０１はセグメントの木構造になっているため、最初はルートのセグメントの先頭を着目する場所に定める。次に、XMLデータ１０３を内部データDA１０１の着目中のXPathに合致するところまで読む（ステップS１０２）。ここでXPathに合致するところがXMLデータ１０３になかったら（ステップS１１１でＮＯ）、エラーにする。さらに、そのXPathに対応するタグが繰り返しの始まりかチェックし（ステップS１１２）、繰り返しの始まりの場合はステップS１０３に進み、繰り返しの始まりでない場合はステップS１０５に進む。繰り返しの始まりの箇所には子セグメントへのポインタが入っているので、ポインタの有無により繰り返しの始まりか否かが判明する。
【００２１】
ステップS１０３では、親セグメントについてバッファに入っている値を元に、RDB１０５の該当するテーブルに対してINSERT文またはUPDATE文を発行する。INSERT文は当該親セグメントにおける初めての子セグメントの開始時（繰り返しの始まり）に使用され、UPDATE文は当該親セグメントにおける２番目以降の子セグメントの開始時（繰り返しの始まり）に使用される。INSERT文では、テーブルに１行が挿入されるが、その行の全てのカラムの値がバッファに入っていなければ、値が入っていないところはNULLなどのダミーのデータを入れる。次に、内部データDA１０１のそれに対応する子セグメントについて、「子セグメントについて開始」から始まる部分を再帰的に実行する（ステップS１０４）。そして、ステップS１１３に進む。
【００２２】
他方、ステップS１０５では、XMLデータ１０３からXPathに対応する値を読んで内部データDA１０１のバッファに格納し、XMLデータ１０３のXPathに対応するXMLの終了タグを読み飛ばし、内部データDA１０１の着目する場所を次に進める。次に、もしも着目していたXPathが、RDB１０５のテーブルのカラムが子孫のセグメントからINSERT文を発行したDBレコードに対応付けられていた場合は、それらのDBレコードに対してUPDATE文を発行する（ステップS１０６）。そして、ステップS１１３に進む。
【００２３】
ステップS１１３では、内部データの着目場所が着目中のセグメントの終わりかどうかチェックし、終わりでない場合はステップS１０２からの処理を繰り返し実行する。終わりの場合には、当該セグメントのバッファに追加された値がある場合は、バッファに入っている値を元にRDB１０５に対して、初めての書き出しの際にはINSERT文を発行し、２度目以降の同じレコードに対する書き出しの際にはUPDATE文を発行する（ステップS１０７）。そして、XMLデータ１０３の次の部分がそのセグメントを繰り返すタグになっているかチェックし、繰り返しになっている場合は、そのセグメントのバッファを再利用するためにステップS１０９でコピーしたバッファ以外のバッファを空にし（ステップS１０８）、ステップS１０２からの処理を繰り返し実行する。繰り返しでない場合はリターンする。なお、ステップS１０８でそのセグメントのバッファを全て空にするようにしても良いが、その場合にはステップS１０９からの処理を繰り返す。
【００２４】
このように本実施の形態の格納装置１００では、XMLデータ１０３をRDB１０５に格納する場合に、中間的にメモリ１０２上に持つ値はXMLデータ１０３の構造（DTD）の大きさとなるように構成されているため、たとえ繰り返し項目が多数あってXMLデータ１０３のサイズがいくら大きくなっても、中間的にメモリ１０２上に持つデータのサイズを入力XMLデータ１０３のサイズによらずDTDの大きさと同じオーダーの一定値にできる。
【００２５】
次に、図３のフローチャートを参照して本実施の形態の取得装置２００の全体の動作について詳細に説明する。
【００２６】
まず、内部データDA２０１の着目する場所を先頭にする（図３のステップS２０１）。内部データDA２０１はセグメントの木構造になっているため、最初はルートのセグメントの先頭を着目する場所に定める。次に、そのセグメントの着目中のXPathに対応付けられているRDB２０５のテーブルに対しSELECT文を発行する（ステップS２０２）。次に、ステップS２０２で発行したSQL文の実行結果の次のレコードがあるかチェックする（ステップS２０３）。次のレコードがない場合（ステップS２１１でＮＯ）、リターンする。次のレコードがある場合は、ステップS２０２で発行したSQL文の実行結果の次のレコードをフェッチし、得られた値を内部データDA２０１のそのセグメントのバッファに入れる（ステップS２０４）。
【００２７】
次に、内部データDA２０１の着目場所のXPathがXMLデータ２０３の繰り返しに対応するタグかどうかチェックし（ステップS２１２）、繰り返しの始まりの場合はステップS２０５へ進み、繰り返しの始まりでない場合はステップS２０６に進む。繰り返しの始まりの箇所には子セグメントへのポインタが入っているので、ポインタの有無により繰り返しの始まりか否かが判明する。
【００２８】
ステップS２０５では、そのXPathに対応する内部データDA２０１の子セグメントについて、「子セグメントについて開始」からの処理を再帰的に実行する。そして、ステップS２１３に進む。
【００２９】
ステップS２０６では、内部データDA２０１の着目中のXPathに対応するバッファの値が空の場合にはRDB２０５に対してSELECT文を発行してバッファの値を埋める。そして、XPathに対応するタグとバッファの値をXMLデータ２０３に書き出し、内部データDA２０１の着目中の場所を次へ進める（ステップS２０７）。そして、ステップS２１３に進む。
【００３０】
ステップS２１３では、内部データDA２０１の着目中の場所がそのセグメントの終わりかどうかチェックする。セグメントの終わりでない場合はステップS２１２からの処理を繰り返し実行する。セグメントの終わりの場合は、ステップS２０３からの処理を繰り返し実行する。
【００３１】
本実施の形態の取得装置２００では、XMLデータ２０３をRDB２０５から取得する場合、XMLデータ２０３はストリームとして書き出してしまい、中間的にメモリ２０２上に持つ値はXMLデータ２０３の構造（DTD）の大きさとなるように構成されているため、たとえ繰り返し項目が多数あってXMLデータ２０３のサイズがいくら大きくなっても、中間的にメモリ２０２上に持つデータのサイズをXMLデータ２０３のサイズによらずDTDの大きさと同じオーダーの一定値にできる。
【００３２】
次に、具体的な実施例を用いて本実施の形態の動作を説明する。
【００３３】
図４はXMLデータのDTDと、RDBのDBスキーマの具体例を示す。DTDでは要素型宣言部分のみを示してあり、要素Itemが繰り返される構造となっている。また、RDBは、PORequestテーブルとPOItemテーブルとの２つのテーブルを持つ。
【００３４】
図５はXML中のタグとDBテーブルのカラムとの対応関係の具体例を示す。この例では、値が入りうるXMLのタグのうち、Xpathが“/POReq/PONumber”，“/POReq/PODate”, “/POReq/fromRole/BusinessId”, “/POReq/toRole/BusinessId”であるタグの値が、PORequestテーブルのカラムPOId,Date,From,Toの値に対応する。また、XMLの繰り返し部分のタグItemに含まれる、Xpathが、“/POReq/Item/POItemNumber”,“/POReq/Item/ProductId”,“/POReq/Item/Request/Amount”,“/POReq/Item/Request/Price”であるタグの値と、当該繰り返し部分の外にある、Xpathが“/POReq/Location”であるタグの値とが、POItemテーブルのカラムPOId,ItemNumber,PId,Quantity,RequestPrice,Locationの値に対応する。なお、PORequestテーブルのカラムPOIdとPOItemテーブルのカラムPOIdとは、プライマリキーとフォーリンキーの関係にある。
【００３５】
図６は格納対象となるXMLデータの具体例を示す。この例では繰り返し項目１〜３の部分が繰り返し構造となっている。
【００３６】
図７は内部データの具体例を示す。この例の内部データは、図６のXMLデータの構造を表す図４のDTDについて、XMLデータの繰り返し部分を子セグメント（セグメント２）、それ以外を親セグメント（セグメント１）とした木構造を有し、各セグメント１、２において、図５の対応関係に従って、値が入りうるXMLのタグについて、そのXPathと、それと対応付けられているRDBのテーブル名及びカラム名と、値を保持するバッファとを設定してある。このような内部データは例えば以下のように作成される。
【００３７】
先ず、親セグメント１を生成する。次に、図５を参照すると、XMLの値が入りうる最初のXpathは“/POReq/PONumber”で、PORequestテーブルのカラムPOIdに対応するので、エントリE1を親セグメント１に生成する。同様にして、エントリE2〜E4を生成する。XMLの次のタグは繰り返しのタグItemなので、子セグメント２を生成し、親セグメント１にはタグItemのXpathと子セグメント２へのポインタを設定したエントリE5を生成する。次に、子セグメント２のエントリの生成に移るが、図５を参照すると、PORequestテーブルのカラムPOIdとPOItemテーブルのカラムPOIdとがプライマリキーとフォーリンキーの関係にあるため、プライマリキーに対応するXpathと、フォーリンキーを格納するテーブル及びカラムと、バッファとを持つエントリE50を生成した後、XMLの値が入りうる各Xpath用のエントリE51〜E54を生成する。次に、親セグメント１のエントリの生成に戻り、XMLの値が入りうる最後のXpath用のエントリE6を生成する。ここで、初期状態においては各エントリのバッファは空である。
【００３８】
以下、図４のDTDとDBスキーマで、これらの間に図５に示す対応関係があり、入力するXMLデータが図６に示すもので、図７のような内部データが用意されている場合を例にして、格納装置１００の具体的な動作を説明する。
【００３９】
XMLデータを読み始める前の内部データDA１０１の初期状態は図７に示すものとなっており、この中のセグメント１の先頭のエントリE1が着目する場所としてセットされる（ステップS１０１）。次に、この場所に対応するXPath “/POReq/PONumber” に対応するところをXMLデータから読み出す（ステップS１０２）。先頭が対応するタグとなっているのでエラーにはならず、またこのXPathはXMLデータ中の繰り返しに対応するXPathではないのでステップS１０５に進む。
【００４０】
ステップS１０５では、XMLデータの対応するタグの値 “order1” を内部データの対応するエントリE1のバッファに格納し、内部データの着目する場所を次に進める。着目中だったXPathが対応付けられているDBカラムは、子孫のセグメントでINSERT文を発行したレコードのものではないので、これに対するUPDATE文は発行されない（ステップS１０６）。次に、セグメントの終わりではないので、ステップS１０２からの処理を繰り返し実行する。XPath “/POReq/PODate”, “/POReq/fromRole/BusinessId”, “/POReq/toRole/BusinessId” について同様のこと（ステップS１０２、ステップS１０５）を繰り返した結果、内部データは図８に示すものとなる。
【００４１】
次のXPath “/POReq/Item” については、このXPathがXMLデータ中の繰り返しに対応するので、子セグメント２に基づく処理（繰り返し部分の処理）に入る前の親セグメントに対する処理として、ステップS１０３の処理を実行する。具体的には、現在の内部データのセグメント１のバッファに入っている値を元にDBのPORequestテーブルに対しINSERT文を発行する（ステップS１０３）。ここで、操作対象となるテーブルはセグメント１のバッファが空でないものに対応するテーブルだけである。このため、PORequestテーブルだけが対象となり、エントリE6のバッファが空であるPOItemテーブルに対する操作は行われない。
【００４２】
次に、このXPath “/POReq/Item”に対応する子セグメント２についてステップS１０２からの処理が再帰的に実行される（ステップS１０４）。
【００４３】
先ず、子セグメント２の最初の XPath ”/POReq/PONumber”は、”/POReq/Item”以下のパスではなく先祖セグメントのXPathに対応したものであり、DBテーブルではプライマリキーとフォーリンキーの関係にあるものとなっており（これは、子セグメント中のXpathと同じXpathが親セグメントにあるかどうかで判明する）、この場合は、バッファに親のセグメントのバッファに入っている値 “order1”をコピーし（ステップS１０９）、次のXPath “POItemNumber”に進む。すなわち、親セグメントのバッファの値が、DBテーブルの親テーブルと子テーブルを関係つけるためのプライマリキーであれば、子セグメントに子テーブルの対応するフォーリンキーの項目があるため、ここに値をコピーするわけである。
【００４４】
次に、子セグメント２におけるXPath “POItemNumber”, “ProductId”, “Request/Amout”, “Request/Price” についてステップS１０２、ステップS１０５が繰り返し実行された結果、内部データは図９に示すものとなる。
【００４５】
これでセグメント２の終わりなので、セグメントの終了時の処理を行う（ステップS１０７）。今の場合、セグメント２のバッファに入っている値を元にDBのPOItemテーブルに対してINSERT文が発行される。このとき、テーブルPOItemテーブルのカラムLocationに対応する値は、エントリE6のバッファに未だ入っていないので、このカラムについてはNULLなどのダミーのデータが使用される。
【００４６】
図６に示すXMLデータは、繰り返しのXPathの “/POReq/Item” が３つ含まれているので、同様のこと（ステップS１０２、ステップS１０５、ステップS１０７）をあと２回繰り返して、POItemテーブルに対してあと２回INSERT文が発行され、子セグメント２についての処理からセグメント１への処理へリターンする。
【００４７】
セグメント１の次のXPathは “/POReq/Location”で、これに関しステップS１０２とステップS１０５を実行した結果、内部データは図１０に示すものとなる。そして、”/POReq/Location”は、セグメント２に対応するDBのレコードのカラムに対応付けられているので、既にINSERT文が発行済みのPOItemテーブルのレコードに対して、このバッファに入っている値を元に、DBのPOItemテーブルに対してUPDATE文が発行される（ステップS１０６）。次にステップS１０７の実行に入るが、ステップS１０７は「そのセグメントのバッファで追加されたものがある場合」だけ処理を行うものであり、今の場合はバッファに新たに追加されたものがないため、何もしない。これでセグメント１の終わりで、XMLデータのRDBへの格納処理を終了する。このときにRDBに格納されているデータは図１１に示すものとなる。
【００４８】
以上の具体例では、ステップS１０３においてNULLなどのダミーのデータを入れる場面、同ステップS１０３においてUPDATE文を使用する場面、ステップS１０７においてUPDATE文を使用する場面は現れない。これらの場面は、例えば次のような具体例で現れる。
【００４９】
例えば図７のエントリE2がエントリE5とE6の間にあるような場合を考える。このような場合、親セグメント１のエントリE4までの処理を終えて、繰り返し部分の処理に入る前の親セグメント１に対するステップS１０３において、エントリE2のバッファが未だ空なので、PORequestテーブルのカラムDateにはNULLなどのダミーのデータが入れられる。また、子セグメント１の処理を終えて、エントリE2の処理に移ると、ステップS１０５でエントリE2のバッファに値が入るため、親セグメント１の処理を終える際のステップS１０７において、エントリE2のバッファに入っている値がUPDATE文を使用して、PORequestテーブルのカラムDateに書き込まれる。
【００５０】
また、ステップS１０３でUPDATE文が使用されるのは、親セグメント１に複数の繰り返し部分がある場合である。すなわち、１個目の子セグメントの処理に入る際の親セグメントに対するステップS１０３ではINSERT文が使用されるが、２個目以降の子セグメントの処理に入る際の親セグメントに対するステップS１０３の処理ではUPDATE文が使用される。
【００５１】
次に、図４のDTDとDBスキーマで、これらの間に図５に示す対応関係があり、RDBに格納されているデータが図１１に示すもので、図７のような内部データが用意されている場合を例にして、取得装置２００の具体的な動作を説明する。
【００５２】
XMLデータの書き出しを始める前の内部データDA２０１の初期状態は図７に示すものとなっており、この中のセグメント１の先頭のエントリE1が着目する場所としてセットされる（ステップS２０１）。次に、このセグメント１で対応付けられているDBカラムの値を取得するSELECT文が図１１で示される内容のDBのPORequestテーブルに対し実行される（ステップS２０２）。レコードが存在するので、ステップS２０４に進む（ステップS２０３）。SELECT文の実行結果をフェッチすることにより、セグメント１のエントリE1〜E4のバッファの値が埋まる（ステップS２０４）。この時点で内部データDA２０１は図１２に示すものとなる。
【００５３】
最初のXPath “POReq/PONumber”は繰り返しの項目ではないのでステップS２０６に進む。対応するエントリE1のバッファは空でないのでSELECT文は発行されない（ステップS２０６）。内部データDA２０１のXPath “POReq/PONumber”に対応するタグとその値がXMLデータに書き出され、次のXPathに進む（ステップS２０７）。ここで、XMLデータに書き出すときのXMLの終了タグについては、そのタグに囲まれたところが閉じられるまで書き出しが遅延される。
【００５４】
次に、XPath “/POReq/POData”, “/POReq/fromRole/BusinessId”, “/POReq/toRole/BusinessId” について同様のこと（ステップS２０７）を繰り返した結果、XMLデータの繰り返しに対応するXPath “/POReq/Item” の前までのXMLデータが書き出される。
【００５５】
次のXPath “/POReq/Item”はXMLデータ中の繰り返しに対応するので、XPath “/POReq/Item”に対応する子セグメント２について「子セグメントについて開始」からの処理が再帰的に実行される（ステップS２０５）。子セグメント２の XPath”/POReq/PONumber”は、”/POReq/Item”以下のパスではなく先祖セグメントのXPathに対応したものであり、DBテーブルではプライマリキーとフォーリンキーの関係にあるものとなっており、この場合は、エントリE50のバッファに親セグメントのエントリE1のバッファに入っている値 “order1”がコピーされ、XPath “POItemNumber”に進む（ステップS２０８）。次に、このセグメント２で対応付けられているDBカラムの値を取得するSELECT文が図１１で示される内容のDBのPOItemテーブルに対し実行される（ステップS２０２）。レコードが存在するので、ステップS２０４に進む（ステップS２０３）。SELECT文の実行結果をフェッチすることにより、セグメント２のエントリE51〜E54のバッファの値が埋まる（ステップS２０４）。
【００５６】
次に、XPath “POItemNumber”, “ProductId”, “Request/Amout”, “Request/Price” についてステップS２０７が繰り返し実行された結果、XPath “POReq/Item”に対応する繰り返し項目の１つ目がXMLデータに書き出される。これでセグメント２の終わりなのでステップS２０３からの処理を繰り返す。図１１に示すDBのPOItemテーブルは３つのレコードを含んでいるので、同様のこと（ステップS２０３、ステップS２０４、ステップS２０７）をあと２回繰り返して、残りの２つの繰り返し項目に対応する内容をXMLデータに書き出し、子セグメント２についての処理からセグメント１への処理へリターンする。
【００５７】
セグメント１の次のXPathは “/POReq/Location”で、これに対応するエントリE6のバッファが空なので、DBのPOItemテーブルにSELECT文を発行しフェッチしてバッファを埋め（ステップS２０６）、ステップS２０７を実行し対応する内容がXMLデータに書き出される。これで、XMLデータのRDBからの取得処理を終了する。この時点で内部データDA２０１は図１３に示すものとなり、書き出されたXMLデータは図６に示すものと同じものになる。
【００５８】
以上本発明の実施の形態について説明したが、本発明は以上の例に限定されずその他各種の付加変更が可能である。例えば、図１では、格納装置１０１と取得装置２０１とのそれぞれに内部データDA１０１、内部データDA２０１を設けたが、同じ構造のXMLデータについては格納装置１０１と取得装置２０１とで内部データは同じになるので、格納と取得とを同時に行わない場合には、１つの内部データを格納装置１０１と取得装置２０１とで共通に設けるようにしても良い。この場合、格納装置１０１と取得装置２０１とをあわせて、格納・取得装置として１つの装置として実現するようにしても良い。
【００５９】
【発明の効果】
以上説明したように本発明によれば、XMLデータをRDBに格納し、またRDBからXMLデータを取得する場合に、たとえXMLデータのサイズがいくら大きくなっても、使用メモリ量がDTDのサイズに比例した大きさに抑えられ、XMLデータのサイズによらずDTDの大きさと同じオーダーの一定値に抑えられる効果がある。その理由は、既存のXML処理系ではXMLデータのサイズに比例したメモリ容量を必要とするのに対し、本発明ではDTDの大きさに比例した内部データしかメモリ上に持たず、他のデータはDBへの格納ならDBに書き出してしまうし、DBからの取り出し時はXMLデータを作成するストリームに書き出してしまうためである。
【図面の簡単な説明】
【図１】本発明の実施の形態の構成を示すブロック図である。
【図２】本発明の実施の形態のXMLデータのRDBへの格納手段の動作を示す流れ図である。
【図３】本発明の実施の形態のRDBからのXMLデータの取得手段の動作を示す流れ図である。
【図４】 DTDとDBスキーマ情報の具体例を示す図である。
【図５】 XML中のタグとDBテーブルのカラムとの対応関係の具体例を示す図である。
【図６】 XMLデータの具体例を示す図である。
【図７】初期状態の内部データの具体例を示す図である。
【図８】 RDBにXMLデータを格納している最中の内部データの状態を示す図である。
【図９】 RDBにXMLデータを格納している最中の内部データの状態を示す図である。
【図１０】 RDBにXMLデータを格納している最中の内部データの状態を示す図である。
【図１１】 XMLデータを格納後のRDBの内容を示す図である。
【図１２】 XMLデータをRDBから取り出している最中の内部データの状態を示す図である。
【図１３】 XMLデータをRDBから取り出している最中の内部データの状態を示す図である。
【符号の説明】
１００ XMLデータのDBへの格納装置
１０１ XMLデータのDBへの格納手段
１０２内部データ
１０３入力のXMLデータ
１０４入力装置
１０６ RDB
１１０記録媒体
２００ DBからのXMLデータ取得装置
２０１ DBからのXMLデータ取得手段
２０２内部データ
２０３取得したXMLデータ
２０４出力装置
２０５ RDB
２１０記録媒体[0001]
BACKGROUND OF THE INVENTION
The present invention relates to an apparatus for storing XML data in an RDB and an apparatus for acquiring XML data from the RDB.
[0002]
[Prior art]
When storing data described in XML (eXtensible Markup Language) in RDB (Relational Data Base), RDB's RDB (Relational Data Base) does not store all XML data as a stream (Stream), Each column is associated with each tag value in XML and stored in several tables. For this reason, this type of conventional storage device converts the XML data into other types of XML data that are easy to store in the RDB, accumulates them in a buffer, and then stores them in the RDB. In addition, when acquiring the XML data stored in this way from the RDB, the XML data is collectively extracted and stored in a buffer, and converted from a format that is easy to store into a format of the target XML data. XML data in a format that can be easily stored in the RDB is XML data in the following format, in which the XML data tag is usually the RDB column name and the tag value is the contents of the RDB column.
[0003]

[0004]
[Problems to be solved by the invention]
In the conventional apparatus having such a configuration, an XSLT (eXtensible Style Language Transformation) processor or a DOM (Document Object Model) object that is a parse tree is generally used, but the XSLT processor or DOM object is generally used as a buffer. The memory capacity increases as the XML data handled increases, and the amount of memory used by the entire device depends on the size of the data (DTD (Document Type Definition) or XML Shema) that represents the structure of the XML regardless of the size of the XML data. Cannot keep a constant value in the same order.
[0005]
The reason is that XML data is converted into XML data of other formats at once, stored in the buffer, and then stored in the DB, so if you do this for large XML data with many repeated items, the amount of memory used will be This is because it is almost proportional to the size of XML data.
[0006]
OBJECT OF THE INVENTION
The object of the present invention is to store XML data with many repeated items in the RDB. Even if there are many repeated items in the XML data, the amount of memory used does not depend on the size of the XML data, the data DTD representing the structure of the XML, etc. It is to be able to keep a constant value of the same order as the size of.
[0007]
Another object of the present invention is to obtain data representing the structure of XML regardless of the size of the XML data, even if there are many repeated items in the XML data, when acquiring XML data with many repeated items from the RDB. The purpose is to be able to maintain a constant value in the same order as the size of the DTD or the like.
[0008]
[Means for Solving the Problems]
  The device for storing XML data in the RDB of the present invention displays the structure of XML data to be stored.Can be a value defined in the data XML For each tag, XPath And associated with the tag RDB The tag with the table name and column name and the buffer for holding the value are included, and the tag having one or more repetition designations has only one combination regardless of the actual number of repetitions.A memory for storing internal data;The storage target XML Read the tag value from the data and XPath And storing the tag value stored in the buffer in the buffer in the combination. XPath In the combination comprising RDB Specified by the table name and column name RDB By writing to the table column,Storage means for storing the XML data in the RDB,The storage means records, with respect to a repeated portion of the XML data, a record for a table that stores the tag value of the repeated portion of the RDB at the time when the tag value is accumulated in the buffer for each repeated portion. A means for inserting a record by issuing an INSERT statement using a dummy value for a column whose value is not yet determined, and a tag value corresponding to the column value in which the dummy value is written out And a means for issuing an UPDATE statement when updating the record to update the record.
[0009]
  The XML data acquisition device from the RDB of the present invention displays the structure of the XML data to be acquired.Can be a value defined in the data XML For each tag, XPath And associated with the tag RDB The tag with the table name and column name and the buffer for holding the value are included, and the tag having one or more repetition designations has only one combination regardless of the actual number of repetitions.A memory for storing internal data;Above RDB The column value of the table is read and stored in the buffer in the combination including the table name and the column name, and the column value stored in the buffer is stored in the buffer in the combination including the table name and the column name. XPath As the value of the tag specified by XML By exporting to data,Obtaining means for obtaining the XML data from the RDB;,For the repetitive part of the XML data, the acquisition unit issues a SELECT statement to the table storing the tag value of the repetitive part, and for each record, the value of the column in the record corresponds to the corresponding buffer. And storing the value corresponding to the tag of the repetitive portion from the buffer and writing it to the XML data stream.
[0010]
[Action]
  In the apparatus for acquiring XML data from the RDB according to the present invention, for the repeated portion of the XML data, the tag value of the repeated portion of the RDB at the time when the tag value is accumulated in the buffer for each repeated portion. For a table that stores a value, insert a record by issuing an INSERT statement using a dummy value for a column for which the value in the record is not yet determined. Then, when the tag value corresponding to the column value in which the dummy value is written is read from the XML data, an UPDATE statement is issued and updated. As a result, if the RDB table that stores the tag value of the repeated part of the XML data also stores the value of the other tag that is not included in the repeated part, the data write to the table is an INSERT or UPDATE statement. The number of repeated parts of XML dataRegardlessOnly one set of buffers is sufficient, and no matter how large the XML data size, the internal data size will not exceed the size of the DTD.
[0011]
  Further, in the XML data acquisition apparatus from the RDB of the present invention, for the repeated portion of the XML data, a SELECT statement is issued to the table storing the tag value of the repeated portion, and for each record, After accumulating the column values in the record in the corresponding buffer, the process of reading the value corresponding to the tag of the repetition part from the buffer and writing it to the XML data stream is repeated. InRegardlessOnly one set of buffers is sufficient, and no matter how large the XML data size, the internal data size will not exceed the size of the DTD.
[0012]
DETAILED DESCRIPTION OF THE INVENTION
Next, embodiments of the present invention will be described in detail with reference to the drawings.
[0013]
Referring to FIG. 1, an XML data RDB storage device 100 according to an embodiment of the present invention includes an XML data RDB storage means 101 and a memory 102 for storing internal data DA101. Are connected to an input device 104 that stores XML data 103 and an RDB 105 that stores XML data. The input device 104 is, for example, a magnetic disk or a communication buffer. Reference numeral 110 denotes a computer-readable recording medium such as a magnetic disk or a semiconductor memory, in which a storage program is recorded. The storage program recorded here is read by a computer constituting the storage device 100, and the operation of the computer is controlled to realize the storage means 101 as a module on the computer.
[0014]
  The internal data DA101 is prepared in advance for each XML data 103 to be input, represents the structure of the XML data 103, has a correspondence with the RDB 105, and is repeated in the XML data 103.Regardless of the number ofHas only one set of buffers. More specifically, the internal data DA101 has a tree-structured structure in which the repeated portion of the XML data 103 is a child segment of the data (DTD or XMLShema) representing the structure of the XML data 103, and a value can be entered. The XML tag has its XPath, the table name and column name of the RDB 105 associated therewith, and a buffer for holding the value. The parent segment and the child segment are connected by a pointer.
[0015]
The storage unit 101 operates to issue an SQL statement for performing data addition operation to the RDB 105 while reading the input XML data 103 at the same time as tracing the internal data DA101. At this time, no matter how large the size of the XML data 103 is, the size of the internal data DA101 does not exceed the size of the DTD.
[0016]
The apparatus 200 for acquiring XML data from the RDB according to the embodiment of the present invention includes an XML data acquiring unit 201 from the RDB and a memory 202 that stores internal data DA201, and an RDB 205 that stores XML data. It is connected to an output device 204 that stores the acquired XML data 203. The output device 204 is, for example, a magnetic disk or a communication buffer. Reference numeral 210 denotes a computer-readable recording medium such as a magnetic disk or a semiconductor memory, on which an acquisition program is recorded. The acquisition program recorded here is read by a computer constituting the acquisition apparatus 200, and the operation of the computer is controlled to realize the acquisition means 201 as a module on the computer.
[0017]
  The internal data DA201 is prepared in advance for each XML data 203 to be acquired, represents the structure of the XML data 203, has a correspondence with the RDB 205, and is repeated in the XML data 203.Regardless of the number ofHas only one set of buffers. More specifically, the internal data DA201 has a tree-structured structure in which the repeated portion of the XML data 203 is a child segment of the data (DTD or XMLShema) representing the structure of the XML data 203, and can contain a value. The XML tag has its XPath, the table name and column name of the RDB 205 associated therewith, and a buffer for holding the value. The parent segment and the child segment are connected by a pointer.
[0018]
The acquisition unit 201 operates to issue an SQL statement for performing a data acquisition operation to the RDB 205 while writing the XML data 203 while simultaneously tracing the internal data DA201. At this time, no matter how large the size of the XML data 203, the size of the internal data DA201 does not exceed the size of the DTD.
[0019]
Next, the overall operation of the storage device 100 of this embodiment will be described in detail with reference to the flowchart of FIG.
[0020]
First, the focused location of the internal data DA101 is set at the top (step S101 in FIG. 2). Since the internal data DA101 has a tree structure of segments, first, the head of the root segment is determined as the place of interest. Next, the XML data 103 is read up to a point that matches the XPath under consideration of the internal data DA101 (step S102). If there is no place in the XML data 103 that matches the XPath (NO in step S111), an error is generated. Further, it is checked whether or not the tag corresponding to the XPath is the start of repetition (step S112). If it is the start of repetition, the process proceeds to step S103, and if not, the process proceeds to step S105. Since the pointer to the child segment is entered at the beginning of the repetition, it is determined whether or not the repetition starts depending on the presence or absence of the pointer.
[0021]
In step S103, an INSERT statement or an UPDATE statement is issued to the corresponding table in the RDB 105 based on the value stored in the buffer for the parent segment. The INSERT statement is used at the start of the first child segment in the parent segment (start of repetition), and the UPDATE statement is used at the start of the second and subsequent child segments in the parent segment (start of repetition). In the INSERT statement, one row is inserted into the table. If the values of all the columns in the row are not in the buffer, dummy data such as NULL is inserted where there is no value. Next, with respect to the child segment corresponding to that of the internal data DA101, the part starting from “start for child segment” is recursively executed (step S104). Then, the process proceeds to step S113.
[0022]
On the other hand, in step S105, the value corresponding to the XPath is read from the XML data 103 and stored in the buffer of the internal data DA101, the end tag of the XML corresponding to the XPath of the XML data 103 is skipped, and the place of interest in the internal data DA101 Next. Next, if the focused XPath is associated with DB records that have issued INSERT statements from descendent segments, the RDB 105 table columns issue UPDATE statements for those DB records ( Step S106). Then, the process proceeds to step S113.
[0023]
In step S113, it is checked whether or not the focused location of the internal data is the end of the segment being focused. If not, the processing from step S102 is repeatedly executed. In the case of the end, if there is a value added to the buffer of the segment, issue an INSERT statement to the RDB 105 based on the value in the buffer when writing for the first time. When the same record is written, an UPDATE statement is issued (step S107). Then, it is checked whether the next part of the XML data 103 is a tag for repeating the segment. If the tag is repeated, a buffer other than the buffer copied in step S109 is used to reuse the segment buffer. It is emptied (step S108), and the processing from step S102 is repeatedly executed. Return if not repeated. In step S108, all the buffers of the segment may be emptied. In this case, the processing from step S109 is repeated.
[0024]
As described above, in the storage device 100 according to the present embodiment, when the XML data 103 is stored in the RDB 105, an intermediate value on the memory 102 is configured to have the size of the structure (DTD) of the XML data 103. Therefore, even if there are many repeated items and the size of the XML data 103 is increased, the size of the data on the memory 102 in the middle is the same order as the size of the DTD regardless of the size of the input XML data 103. Can be a constant value.
[0025]
Next, the overall operation of the acquisition apparatus 200 of this embodiment will be described in detail with reference to the flowchart of FIG.
[0026]
First, the focused location of the internal data DA201 is set at the top (step S201 in FIG. 3). Since the internal data DA201 has a tree structure of segments, first, the head of the root segment is determined as the place of interest. Next, a SELECT statement is issued to the table in the RDB 205 associated with the XPath being focused on for the segment (step S202). Next, it is checked whether there is a next record of the execution result of the SQL statement issued in step S202 (step S203). If there is no next record (NO in step S211), the process returns. If there is a next record, the next record of the execution result of the SQL statement issued in step S202 is fetched, and the obtained value is put in the buffer of that segment of the internal data DA201 (step S204).
[0027]
Next, it is checked whether or not the XPath at the target location of the internal data DA201 is a tag corresponding to the repetition of the XML data 203 (step S212). If the repetition starts, the process proceeds to step S205. If the repetition does not start, the process proceeds to step S206. move on. Since the pointer to the child segment is entered at the beginning of the repetition, it is determined whether or not the repetition starts depending on the presence or absence of the pointer.
[0028]
In step S205, for the child segment of the internal data DA201 corresponding to the XPath, the processing from “start for child segment” is recursively executed. Then, the process proceeds to step S213.
[0029]
In step S206, if the value of the buffer corresponding to the focused XPath in the internal data DA201 is empty, a SELECT statement is issued to the RDB 205 to fill the buffer value. Then, the tag corresponding to the XPath and the buffer value are written in the XML data 203, and the location of interest in the internal data DA201 is advanced to the next (step S207). Then, the process proceeds to step S213.
[0030]
In step S213, it is checked whether the location of interest in the internal data DA201 is the end of the segment. If it is not the end of the segment, the processing from step S212 is repeated. In the case of the end of the segment, the processing from step S203 is repeatedly executed.
[0031]
In the acquisition apparatus 200 according to the present embodiment, when the XML data 203 is acquired from the RDB 205, the XML data 203 is written out as a stream, and the value held in the memory 202 is the size of the structure (DTD) of the XML data 203. Therefore, even if there are a large number of repeated items and the size of the XML data 203 increases, the size of the data stored in the memory 202 is intermediately set to the DTD regardless of the size of the XML data 203. Can be a constant value in the same order as the size of.
[0032]
Next, the operation of this embodiment will be described using specific examples.
[0033]
FIG. 4 shows a specific example of the DTD of XML data and the DB schema of RDB. In the DTD, only the element type declaration part is shown, and the element Item is repeated. The RDB has two tables, a PORequest table and a POItem table.
[0034]
FIG. 5 shows a specific example of the correspondence relationship between tags in XML and DB table columns. In this example, among the XML tags that can contain values, the tags whose Xpath is “/ POReq / PONumber”, “/ POReq / PODate”, “/ POReq / fromRole / BusinessId”, “/ POReq / toRole / BusinessId” Corresponds to the values of the columns POId, Date, From, and To of the PORequest table. In addition, the Xpath included in the tag Item of the XML repeat part is “/ POReq / Item / POItemNumber”, “/ POReq / Item / ProductId”, “/ POReq / Item / Request / Amount”, “/ POReq / Item The value of the tag “/ Request / Price” and the value of the tag whose Xpath is “/ POReq / Location” outside the repeated part are the POItem table columns POId, ItemNumber, PId, Quantity, RequestPrice, Corresponds to the value of Location. Note that the column POId of the PORequest table and the column POId of the POItem table have a primary key and foreign key relationship.
[0035]
FIG. 6 shows a specific example of XML data to be stored. In this example, the repeated items 1 to 3 have a repeated structure.
[0036]
FIG. 7 shows a specific example of internal data. The internal data in this example has a tree structure for the DTD of FIG. 4 representing the structure of the XML data of FIG. In each of the segments 1 and 2, according to the correspondence relationship of FIG. 5, for the XML tag that can contain a value, the XPath, the RDB table name and column name associated therewith, and a buffer for holding the value Is set. Such internal data is created as follows, for example.
[0037]
First, the parent segment 1 is generated. Next, referring to FIG. 5, the first Xpath that can contain the XML value is “/ POReq / PONumber”, which corresponds to the column POId of the PORequest table, so the entry E1 is generated in the parent segment 1. Similarly, entries E2 to E4 are generated. Since the next tag of XML is a repetitive tag Item, a child segment 2 is generated, and an entry E5 in which an Xpath of the tag Item and a pointer to the child segment 2 are set in the parent segment 1 is generated. Next, the process proceeds to the generation of an entry for the child segment 2. Referring to FIG. 5, the column POId of the PORequest table and the column POId of the POItem table have a primary key and foreign key relationship, and therefore the Xpath corresponding to the primary key. Then, an entry E50 having a table and column for storing a foreign key, and a buffer is generated, and then entries E51 to E54 for each Xpath that can contain XML values are generated. Next, returning to the generation of the entry of the parent segment 1, the last Epath entry E6 that can contain the XML value is generated. Here, in the initial state, the buffer of each entry is empty.
[0038]
In the following, the DTD and DB schema in FIG. 4 have the correspondence shown in FIG. 5, the input XML data is shown in FIG. 6, and the internal data as shown in FIG. 7 is prepared. A specific operation of the storage device 100 will be described as an example.
[0039]
The initial state of the internal data DA101 before starting to read the XML data is as shown in FIG. 7, and the top entry E1 of the segment 1 is set as a place of interest (step S101). Next, the location corresponding to XPath “/ POReq / PONumber” corresponding to this location is read from the XML data (step S102). Since the head is a corresponding tag, no error occurs, and since this XPath is not an XPath corresponding to repetition in XML data, the process proceeds to step S105.
[0040]
In step S105, the value “order1” of the corresponding tag of the XML data is stored in the buffer of the corresponding entry E1 of the internal data, and the location where the internal data is focused is advanced. Since the DB column associated with the XPath that has been focused on is not the record of the INSERT statement issued by the descendant segment, the UPDATE statement for this is not issued (step S106). Next, since it is not the end of the segment, the processing from step S102 is repeatedly executed. XPath “/ POReq / PODate”, “/ POReq / fromRole / BusinessId”, “/ POReq / toRole / BusinessId” is similar (step S102, step S105), and the internal data is as shown in FIG. Become.
[0041]
As for the next XPath “/ POReq / Item”, since this XPath corresponds to the repetition in the XML data, the processing of the parent segment before entering the processing based on the child segment 2 (processing of the repeated portion) is performed in step S103. Execute the process. Specifically, an INSERT statement is issued to the PORequest table of the DB based on the value stored in the current internal data segment 1 buffer (step S103). Here, the table to be operated is only the table corresponding to the segment 1 buffer that is not empty. For this reason, only the PORequest table is targeted, and no operation is performed on the POItem table in which the buffer of the entry E6 is empty.
[0042]
Next, the processing from step S102 is recursively executed for the child segment 2 corresponding to this XPath “/ POReq / Item” (step S104).
[0043]
First, the first XPath “/ POReq / PONumber” of child segment 2 corresponds to the XPath of the ancestor segment, not the path below “/ POReq / Item”. In the DB table, the relationship between the primary key and foreign key (This is determined by whether the parent segment has the same Xpath as the Xpath in the child segment.) In this case, the value “order1” stored in the parent segment's buffer is stored in the buffer. Copy (step S109) and proceed to the next XPath “POItemNumber”. That is, if the value of the parent segment buffer is the primary key for associating the parent table and child table of the DB table, the child segment has a corresponding foreign key item in the child table, so copy the value here That is why.
[0044]
Next, as a result of repeatedly executing Step S102 and Step S105 for XPath “POItemNumber”, “ProductId”, “Request / Amout”, “Request / Price” in child segment 2, the internal data is as shown in FIG. .
[0045]
Since this is the end of segment 2, processing at the end of the segment is performed (step S107). In this case, an INSERT statement is issued for the POItem table in the DB based on the value stored in the segment 2 buffer. At this time, since the value corresponding to the column Location of the table POItem table is not yet entered in the buffer of the entry E6, dummy data such as NULL is used for this column.
[0046]
Since the XML data shown in FIG. 6 includes three repeated XPath “/ POReq / Item”, the same thing (step S102, step S105, step S107) is repeated twice more in the POItem table. On the other hand, the INSERT statement is issued two more times, and the process returns from the process for child segment 2 to the process for segment 1.
[0047]
The next XPath of the segment 1 is “/ POReq / Location”. As a result of executing Step S102 and Step S105 with respect to this, the internal data is as shown in FIG. Since “/ POReq / Location” is associated with the DB record column corresponding to segment 2, the value stored in this buffer for the POItem table record for which an INSERT statement has already been issued. Based on the above, an UPDATE statement is issued to the DB POItem table (step S106). Next, execution of step S107 is performed, but step S107 performs processing only when “there is an additional buffer in the segment”, and in this case there is no new addition in the buffer. ,do nothing. This completes the process of storing XML data in the RDB at the end of segment 1. At this time, the data stored in the RDB is as shown in FIG.
[0048]
In the above specific example, the scene where dummy data such as NULL is inserted in step S103, the scene where the UPDATE statement is used in step S103, and the scene where the UPDATE sentence is used in step S107 do not appear. These scenes appear in the following specific examples, for example.
[0049]
For example, consider a case where entry E2 in FIG. 7 is between entries E5 and E6. In such a case, the processing up to the entry E4 of the parent segment 1 is finished, and the buffer of the entry E2 is still empty in step S103 for the parent segment 1 before entering the processing of the repeated portion. Dummy data such as NULL is entered. Further, when the processing of the child segment 1 is finished and the processing of the entry E2 is started, the value is entered in the buffer of the entry E2 in step S105. Therefore, in the step S107 when the processing of the parent segment 1 is finished, The entered value is written to column Date of PORequest table using UPDATE statement.
[0050]
In addition, the UPDATE statement is used in step S103 when the parent segment 1 has a plurality of repeated portions. That is, in step S103 for the parent segment when entering the process of the first child segment, the INSERT statement is used in the process of step S103 for the parent segment when entering the process of the second and subsequent child segments. used.
[0051]
Next, the DTD and DB schema in FIG. 4 have the correspondence shown in FIG. 5, and the data stored in the RDB is shown in FIG. 11, and internal data as shown in FIG. 7 is prepared. The specific operation of the acquisition apparatus 200 will be described by taking the case of the case as an example.
[0052]
The initial state of the internal data DA201 before starting to write the XML data is as shown in FIG. 7, and the first entry E1 of the segment 1 in this is set as a place of interest (step S201). Next, a SELECT statement for obtaining the value of the DB column associated with this segment 1 is executed for the PORequest table of the DB having the contents shown in FIG. 11 (step S202). Since a record exists, the process proceeds to step S204 (step S203). By fetching the execution result of the SELECT statement, the buffer values of the entries E1 to E4 of the segment 1 are filled (step S204). At this time, the internal data DA201 is as shown in FIG.
[0053]
Since the first XPath “POReq / PONumber” is not a repeated item, the process proceeds to step S206. Since the buffer of the corresponding entry E1 is not empty, the SELECT statement is not issued (step S206). The tag corresponding to the XPath “POReq / PONumber” of the internal data DA201 and its value are written in the XML data, and the process proceeds to the next XPath (step S207). Here, with respect to the end tag of XML when writing to XML data, the writing is delayed until the portion surrounded by the tag is closed.
[0054]
Next, as a result of repeating the same for XPath “/ POReq / POData”, “/ POReq / fromRole / BusinessId”, “/ POReq / toRole / BusinessId” (Step S207), XPath “ The XML data up to “/ POReq / Item” is exported.
[0055]
Since the next XPath “/ POReq / Item” corresponds to the repetition in the XML data, the process from “start with child segment” is recursively executed for child segment 2 corresponding to XPath “/ POReq / Item”. (Step S205). XPath ”/ POReq / PONumber” of child segment 2 corresponds to the XPath of the ancestor segment, not the path below “/ POReq / Item”, and has a primary key and foreign key relationship in the DB table. In this case, the value “order1” stored in the buffer of entry E1 of the parent segment is copied to the buffer of entry E50, and the process proceeds to XPath “POItemNumber” (step S208). Next, a SELECT statement for acquiring the value of the DB column associated with this segment 2 is executed on the POItem table of the DB having the contents shown in FIG. 11 (step S202). Since a record exists, the process proceeds to step S204 (step S203). By fetching the execution result of the SELECT statement, the buffer values of the entries E51 to E54 of the segment 2 are filled (step S204).
[0056]
Next, step S207 is repeatedly executed for XPath “POItemNumber”, “ProductId”, “Request / Amout”, “Request / Price”. As a result, the first of the repeated items corresponding to XPath “POReq / Item” is XML. Written to the data. Since this is the end of segment 2, the processing from step S203 is repeated. Since the POItem table of the DB shown in FIG. 11 includes three records, the same thing (step S203, step S204, step S207) is repeated two more times, and the contents corresponding to the remaining two repetition items are expressed as XML. The data is written, and the process returns to the segment 1 process from the child segment 2 process.
[0057]
The next XPath of segment 1 is “/ POReq / Location”, and the buffer of the entry E6 corresponding to this is empty, so a SELECT statement is issued and fetched into the POItem table of the DB to fill the buffer (step S206), step S207 Is executed and the corresponding contents are written to the XML data. This completes the process of acquiring XML data from the RDB. At this point, the internal data DA201 is as shown in FIG. 13, and the written XML data is the same as that shown in FIG.
[0058]
Although the embodiments of the present invention have been described above, the present invention is not limited to the above examples, and various other additions and modifications can be made. For example, in FIG. 1, the internal data DA101 and the internal data DA201 are provided in the storage device 101 and the acquisition device 201, respectively. However, the XML data having the same structure is the same in the storage device 101 and the acquisition device 201. Therefore, if storage and acquisition are not performed at the same time, one internal data may be provided in common between the storage device 101 and the acquisition device 201. In this case, the storage device 101 and the acquisition device 201 may be combined and realized as one device as the storage / acquisition device.
[0059]
【The invention's effect】
As described above, according to the present invention, when the XML data is stored in the RDB and the XML data is acquired from the RDB, the amount of used memory becomes the size of the DTD no matter how large the size of the XML data is. There is an effect that it is suppressed to a proportional size and can be suppressed to a constant value in the same order as the size of the DTD regardless of the size of the XML data. The reason is that while the existing XML processing system requires a memory capacity proportional to the size of the XML data, the present invention has only internal data in proportion to the size of the DTD in the memory, and other data is This is because if it is stored in the DB, it will be written to the DB, and when it is extracted from the DB, it will be written to the stream that creates the XML data.
[Brief description of the drawings]
FIG. 1 is a block diagram showing a configuration of an embodiment of the present invention.
FIG. 2 is a flowchart showing an operation of a storage unit for storing XML data in an RDB according to the embodiment of this invention.
FIG. 3 is a flowchart showing an operation of a means for acquiring XML data from an RDB according to the embodiment of this invention.
FIG. 4 is a diagram illustrating a specific example of DTD and DB schema information.
FIG. 5 is a diagram illustrating a specific example of a correspondence relationship between a tag in XML and a column of a DB table.
FIG. 6 is a diagram illustrating a specific example of XML data.
FIG. 7 is a diagram illustrating a specific example of internal data in an initial state.
FIG. 8 is a diagram showing a state of internal data while XML data is stored in the RDB.
FIG. 9 is a diagram illustrating a state of internal data while XML data is stored in the RDB.
FIG. 10 is a diagram showing a state of internal data while XML data is stored in an RDB.
FIG. 11 is a diagram showing the contents of an RDB after storing XML data.
FIG. 12 is a diagram showing a state of internal data while XML data is being extracted from the RDB.
FIG. 13 is a diagram showing a state of internal data while XML data is being extracted from the RDB.
[Explanation of symbols]
100 XML data storage device in DB
101 Means for storing XML data in DB
102 Internal data
103 Input XML data
104 Input device
106 RDB
110 Recording medium
200 XML data acquisition device from DB
201 XML data acquisition means from DB
202 Internal data
203 Acquired XML data
204 Output device
205 RDB
210 Recording medium

Claims

The structure of the XML data to be stored target defined in the table to the data, for each XML tag value can enter, and XPath of the tag, and table names and column names of the RDB that is associated with the tag, A memory for storing internal data having a combination with a buffer for holding a value and having only one set of the combination regardless of the actual number of repetitions for a tag with one or more repetition designations, and a storage target read the tag value from the XML data to be stored in said buffer in said combination comprising XPath of the tag, the tag value stored in the buffer, the RDB in the combination comprising XPath of the tag by writing to the column of the table of the RDB specified by the table names and column names, and a storage means for storing the XML data into the RDB,
The storage means records, with respect to a repeated portion of the XML data, a record for a table that stores the tag value of the repeated portion of the RDB at the time when the tag value is accumulated in the buffer for each repeated portion. A means for inserting a record by issuing an INSERT statement using a dummy value for a column whose value is not yet determined, and a tag value corresponding to the column value in which the dummy value is written out And a means for updating the record by issuing an UPDATE statement when read from the XML data storage device in the RDB.

The structure of the XML data to be acquired object defined in the table to the data, for each XML tag value can enter, and XPath of the tag, and table names and column names of the RDB that is associated with the tag, It has a combination of a buffer to hold the values for the tags that 1 or more times specified a memory for storing the internal data having the combination of only one set amount regardless of its actual number of iterations, the RDB The column value of the table is read and stored in the buffer in the combination including the table name and the column name, and the column value stored in the buffer is stored in the buffer in the combination including the table name and the column name. An acquisition means for acquiring the XML data from the RDB by writing to the XML data as the value of the tag specified by XPath ;
For the repetitive part of the XML data, the acquisition unit issues a SELECT statement to the table storing the tag value of the repetitive part, and for each record, the value of the column in the record corresponds to the corresponding buffer. An apparatus for acquiring XML data from an RDB, comprising: means for repeating a process of reading a value corresponding to the tag of the repetitive portion from the buffer and writing the value to the XML data stream after being stored in the RDB.

The structure of the XML data to be stored target defined in the table to the data, for each XML tag value can enter, and XPath of the tag, and table names and column names of the RDB that is associated with the tag, A memory for storing internal data having a combination with a buffer for holding a value and having only one set of the combination regardless of the actual number of repetitions of a tag having one or more repetition designations; A method for storing XML data in an RDB on a computer equipped with
The storage means reads a tag value from the XML data to be stored, stores the tag value in the buffer in the combination including the tag XPath , and stores the tag value stored in the buffer as the tag XPath . A storage step of storing the XML data in the RDB by writing to the column of the RDB table specified by the table name and column name of the RDB in the combination including , and
In the storage step, for each repetition part of the XML data, a record is stored in the table that stores the tag value of the repetition part of the RDB when the tag value is accumulated in the buffer for each repetition part. Issue a INSERT statement using a dummy value to insert a record for a column whose value is not yet determined, and insert the record corresponding to the column value in which the dummy value was written out into the XML data A method of storing XML data in an RDB, comprising: issuing an UPDATE statement when reading from the database and updating the record.

The structure of the XML data to be acquired object defined in the table to the data, for each XML tag value can enter, and XPath of the tag, and table names and column names of the RDB that is associated with the tag, A memory for storing internal data having a combination with a buffer for holding a value and storing only one set of the combination for a tag with one or more repetition designations regardless of the actual number of repetitions; A method for acquiring XML data from an RDB on a computer equipped with
The acquisition unit reads the column value of the RDB table, stores the value in the buffer including the table name and the column name, and stores the column value stored in the buffer with the table name and the column name. An acquisition step of acquiring the XML data from the RDB by writing to the XML data as the value of the tag specified by the XPath in the combination including , and
For the repetitive part of the XML data, the acquisition step issues a SELECT statement to the table storing the tag value of the repetitive part, and for each record, the buffer value corresponding to the column value in the record is issued. A method for acquiring XML data from an RDB, comprising: a step of repeatedly storing a value corresponding to a tag of the repetitive portion from the buffer and writing the value to the XML data stream after being stored in the RDB.

The structure of the XML data to be stored target defined in the table to the data, for each XML tag value can enter, and XPath of the tag, and table names and column names of the RDB that is associated with the tag, A computer having a combination with a buffer for holding a value, and a memory for storing internal data having a combination of only one set for a tag with one or more repetition designations regardless of the actual number of repetitions The
Read the tag value from the XML data to be stored target stored in said buffer in said combination comprising XPath of the tag, the tag value stored in the buffer, in said combination comprising XPath of the tag by writing to the column of the table of the RDB specified by the table name and column names of the RDB, a storage means for storing the XML data into the RDB, the repeating portion of the XML data, 1 For each repeating part, when a tag value is accumulated in the buffer, a dummy value is assigned to a column in which the value in the record is not yet determined for the table storing the tag value of the repeating part of the RDB. Issuing the used INSERT statement to insert a record, and when reading the value of the tag corresponding to the column value in which the dummy value was written out from the XML data A program that functions as a storage means including a means for issuing an UPDATE statement to update the record.

The structure of the XML data to be acquired object defined in the table to the data, for each XML tag value can enter, and XPath of the tag, and table names and column names of the RDB that is associated with the tag, A computer having a combination with a buffer for holding a value, and a memory for storing internal data having a combination of only one set for a tag with one or more repetition designations regardless of the actual number of repetitions The
Stored in said buffer in said combination comprising said table name and column names read the value in the column of the table of the RDB, the value of the column stored in the buffer, in the combination comprising the table name and column names The acquisition means for acquiring the XML data from the RDB by writing to the XML data as the value of the tag specified by the XPath of the XML data, and for the repeated portion of the XML data, Issue a SELECT statement to the table that stores the values, accumulate the column values in the record for each record in the corresponding buffer, and then read the value corresponding to the tag of the repeated part from the buffer. A program that functions as an acquisition unit including a unit that repeats a process of writing to the XML data stream.