(57)【特許請求の範囲】
【請求項１】
一つあるいは複数のコンピュータ上で動作する一つのXMLデータベース管理システムであって、
XML文書集合を格納するXML文書集合記憶手段と、
一つのXML文書集合のスキーマを定義するスキーマ定義において、任意の階層の複数のエレメントのスキーマに、各エレメントに対して、主キーとして上位または下位の階層のエレメントあるいはアトリビュートを一つ以上指定するデータ構造が設定できる前提において、該XML文書集合に対する操作を要求された場合は、該操作前に、該主キーとして指定されたエレメントあるいはアトリビュートの値の組が、前記XML文書集合記憶手段の該XML文書集合中に一つしかないかどうかを上位のエレメントから順に判定し、２つ以上あれば、例外信号を出力する一意性管理手段と、
を有することを特徴とするXMLデータベース管理システム。
【請求項２】
前記各エレメントに対する主キーの設定では、
少なくとも１つのエレメントに対しては、複数の主キーが設定される、
ことを特徴とする請求項１記載のXMLデータベース管理システム。
【請求項３】
前記一意性管理手段が前記例外信号を出力した場合に、前記主キーとして指定されたエレメントあるいはアトリビュートの値の組が、前記XML文書集合記憶手段の該XML文書集合中に２つ以上あると判定されたエレメントの内容を、該２つ以上あると判定されたエレメントのうち前記操作要求に含まれるエレメントの内容と置き換える操作を行う追加/置換操作手段を、更に有する
請求項１または２記載のXMLデータベース管理システム。
【請求項４】
前記一意性管理手段が前記例外信号を出力した場合に、前記XML文書集合記憶手段の該XML文書集合中に２つ以上あると判定されたエレメントのうち、前記操作要求に含まれるエレメントの内容を、その時点で該XML文書集合内に存在するエレメント内容に、スキーマ定義の整合性を保って追記する操作を行う追加/追記操作手段を、更に有する
請求項１または２記載のXMLデータベース管理システム。
【請求項５】
一つあるいは複数のコンピュータ上で動作する一つのXMLデータベース管理システムを管理するXMLデータベース管理方法であって、
XML文書集合を格納するXML文書集合記憶手段と、一意性管理手段を有する装置において、
前記一意性管理手段が、一つのXML文書集合のスキーマを定義するスキーマ定義において、任意の階層の複数のエレメントのスキーマに、各エレメントに対して、主キーとして上位または下位の階層のエレメントあるいはアトリビュートを一つ以上指定するデータ構造が設定できる前提において、該XML文書集合に対する操作を要求された場合は、該操作前に、該主キーとして指定されたエレメントあるいはアトリビュートの値の組が、前記XML文書集合記憶手段の該XML文書集合中に一つしかないかどうかを上位のエレメントから順に判定し、２つ以上あれば、例外信号を出力する
ことを特徴とするXMLデータベース管理方法。
【請求項６】
前記各エレメントに対する主キーの設定では、
少なくとも１つのエレメントに対しては、複数の主キーが設定される、
ことを特徴とする請求項５記載のXMLデータベース管理方法。
【請求項７】
前記一意性管理手段が出力した前記例外信号を受け取った場合に、前記主キーとして指定されたエレメントあるいはアトリビュートの値の組が、前記XML文書集合記憶手段の該XML文書集合中に２つ以上あると判定されたエレメントの内容を、該２つ以上あると判定されたエレメントのうち前記操作要求に含まれるエレメントの内容と置き換える操作を行う
請求項５または６記載のXMLデータベース管理方法。
【請求項８】
前記一意性管理手段が出力した前記例外信号を受け取った場合に、前記XML文書集合記憶手段の該XML文書集合中に２つ以上あると判定されたエレメントのうち、前記操作要求に含まれるエレメントの内容を、その時点で該XML文書集合内に存在するエレメント内容に、スキーマ定義の整合性を保って追記する操作を行う
請求項５または６記載のXMLデータベース管理方法。
【請求項９】
請求項１乃至４のいずれか１項に記載のXMLデータベース管理システムを構成する各手段としてコンピュータを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、XML(eXtensible Markup Language)データベース管理システム及び方法及びプログラムに係り、特に、XML文書を管理するXML(eXtensible Markup Language)データベース管理システム及び方法及びプログラムに関する。
【背景技術】
【０００２】
XMLは、ディジタル・データのフォーマットとして広く普及している。このXMLで記述された大量のデータ（XMLデータベース）を管理するシステムとして、XMLデータベース管理システム（XMLDBMS）が存在している。
【０００３】
XML標準の定義では、最低限「整形式（well-formed）である」という条件を満たしていれば、XML文書として認められる。これにより、様々なデータ構造を柔軟に扱えるという利点がある。一方、あるXMLデータが、特定のデータ構造（スキーマ）に従っていることを求めたい場合もある。このデータ構造を定義する言語がスキーマ定義言語であり、XMLの場合、DTD(Document Type Definition)、XML Schema（例えば、非特許文献１参照）などのスキーマ定義言語が存在する。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】XML Schema: http://www.w3.org/XML/Schema/  3.11節
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、これらのスキーマ定義言語は、単独のXML文書のスキーマの定義を目的としたものであり、XML文書集合のスキーマの定義には不都合な点が存在する。その一つが、XML文書集合における、各XML文書の主キーの指定である。
【０００６】
通常、リレーショナルDBMS(RDBMS)では、テーブル毎に、一つのカラムあるいは複数のカラムの組を主キーとして指定し、レコードの集合であるテーブル内に、同一の主キーを持つレコードが１つしか存在しないよう保証する仕組みを持っている。しかし、従来のXMLDBMSでは、文書の主キーを指定し、XML集合内に、同一の主キーを持つXML文書が１つしか存在しないことを保証する仕組みはなかった。
【０００７】
XML  Schemaでは、keyエレメントあるいはkeyrefエレメントを用いて、文書内のあるエレメントXに対し、下位のアトリビュートやエレメントを主キーとして指定して、主キーとして指定されたアトリビュートやエレメントが同じ値を持つエレメントXが、あるエレメント配下に１つしか存在しないような制約を記述することができる。
【０００８】
しかし、これはあくまで文書内のみでの整合性を考慮したものであり、複数の文書間での整合性を扱うことはできなかった。
【０００９】
また、主キーとして指定できるのは下位のアトリビュートやエレメントのみであり、上位のアトリビュートやエレメントを用いることはできなかった。
【００１０】
本発明は、上記の点に鑑みなされたもので、XMLDBMSで一意性のサポートを実現することが可能なXMLデータベース管理システム及び方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記の課題を解決するため、本発明（請求項１）は、一つあるいは複数のコンピュータ上で動作する一つのXMLデータベース管理システムであって、
XML文書集合を格納するXML文書集合記憶手段と、
一つのXML文書集合のスキーマを定義するスキーマ定義において、任意の階層の複数のエレメントのスキーマに、各エレメントに対して、主キーとして上位または下位の階層のエレメントあるいはアトリビュートを一つ以上指定するデータ構造が設定できる前提において、該XML文書集合に対する操作を要求された場合は、該操作前に、該主キーとして指定されたエレメントあるいはアトリビュートの値の組が、前記XML文書集合記憶手段の該XML文書集合中に一つしかないかどうかを上位のエレメントから順に判定し、２つ以上あれば、例外信号を出力する一意性管理手段と、を有する。
また、本発明（請求項２）は、前記各エレメントに対する主キーの設定では、
少なくとも１つのエレメントに対しては、複数の主キーが設定される。
【００１２】
また、本発明（請求項３）は、一意性管理手段から例外信号が出力された場合に、前記主キーとして指定されたエレメントあるいはアトリビュートの値の組が、前記XML文書集合記憶手段の該XML文書集合中に２つ以上あると判定されたエレメントの内容を、該２つ以上あると判定されたエレメントのうち前記操作要求に含まれるエレメントの内容と置き換える操作を行う追加/置換操作手段を、更に有する。
【００１３】
また、本発明（請求項４）は、一意性管理手段が例外信号を出力した場合に、前記XML文書集合記憶手段の該XML文書集合中に２つ以上あると判定されたエレメントのうち、前記操作要求に含まれるエレメントの内容を、その時点で該XML文書集合内に存在するエレメント内容に、スキーマ定義の整合性を保って追記する操作を行う追加/追記操作手段を、更に有する。
【００１４】
また、本発明（請求項５）は、一つあるいは複数のコンピュータ上で動作する一つのXMLデータベース管理システムを管理するXMLデータベース管理方法であって、
XML文書集合を格納するXML文書集合記憶手段と、一意性管理手段を有する装置において、
前記一意性管理手段が、一つのXML文書集合のスキーマを定義するスキーマ定義において、任意の階層の複数のエレメントのスキーマに、各エレメントに対して、主キーとして上位または下位の階層のエレメントあるいはアトリビュートを一つ以上指定するデータ構造が設定できる前提において、該XML文書集合に対する操作を要求された場合は、該操作前に、該主キーとして指定されたエレメントあるいはアトリビュートの値の組が、前記XML文書集合記憶手段の該XML文書集合中に一つしかないかどうかを上位のエレメントから順に判定し、２つ以上あれば、例外信号を出力する。
また、本発明（請求項６）は、前記各エレメントに対する主キーの設定では、
少なくとも１つのエレメントに対しては、複数の主キーが設定される。
【００１５】
また、本発明（請求項７）は、一意性管理手段が前記例外信号を出力した場合に、前記主キーとして指定されたエレメントあるいはアトリビュートの値の組が、前記XML文書集合記憶手段の該XML文書集合中に２つ以上あると判定されたエレメントの内容を、該２つ以上あると判定されたエレメントのうち前記操作要求に含まれるエレメントの内容と置き換える操作を行う。
【００１６】
また、本発明（請求項８）は、一意性管理手段が前記例外信号を出力した場合に、前記XML文書集合記憶手段の該XML文書集合中に２つ以上あると判定されたエレメントのうち、前記操作要求に含まれるエレメントの内容を、その時点で該XML文書集合内に存在するエレメント内容に、スキーマ定義の整合性を保って追記する操作を行う。
【００１７】
また、本発明（請求項９）は、請求項１乃至４のいずれか１項に記載のXMLデータベース管理システムを構成する各手段としてコンピュータを機能させるためのプログラムである。
【発明の効果】
【００１８】
上記のように、本発明によれば、XML文書に文書の一意性を示すエレメントとエレメントの一意性を示すエレメントを設けて、文書やエレメントの一意性を保障することにより、XMLDBMSでもRDBMSと同等以上の一意性がサポートされるようになり、データを破壊されにくく、正確さを保ちやすくなる。また、それら一意性を、少ない手間で扱えるようになる。
【図面の簡単な説明】
【００１９】
【図１】本発明の第１の実施の形態におけるシステム構成図である。
【図２】本発明の第１の実施の形態における一意性管理機能部の処理のフローチャートである。
【図３】本発明の第２の実施の形態におけるシステム構成図である。
【図４】本発明の第３の実施の形態におけるシステム構成図である。
【図５】本発明の第３の実施の形態における追加/追記操作機能部の処理のフローチャートである。
【図６】本発明の第１の実施例のデータ構造の例である。
【図７】本発明の第１の実施例で用いる注文書を表すXML文書のデータ構造を模式化した図である。
【図８】本発明の第１の実施例におけるデータ構造をスキーマ定義として記述した例である。
【図９】本発明の第１の実施例における格納対象のXML文書の例である。
【図１０】本発明の第１の実施例における新たなXML文書の例である。
【図１１】本発明の第１の実施例における格納対象のXML文書の例である。
【図１２】本発明の第２の実施例における格納対象のXML文書の例である。
【図１３】本発明の第３の実施例の追記対象のXML文書の例である。
【図１４】本発明の第３の実施例の処理終了後のXML文書集合記憶部のXML文書の例である。
【発明を実施するための形態】
【００２０】
以下に図面と共に、本発明の実施の形態を説明する。
【００２１】
本発明は、一意性のサポートをXMLDBMSで実現するために、文書間でも有効な主キー指定記述をスキーマに追加可能にするものである。また、主キー指定記述において、上位のアトリビュートやエレメントを指定可能にし、木構造において特徴的な上位階層からのスコープの絞込みにも対応できるようにする。
【００２２】
そして、XMLDBMSにおいて、上記の主キー指定記述を解釈し、同一の主キーを持つXMLの部分木（XML文書内の特定のノード以下のデータ）が、XML文書集合内で１つしか存在しないことを保証する仕組みを実現する。
【００２３】
［第１の実施の形態］
図１は、本発明の第１の実施の形態におけるシステム構成を示す。
【００２４】
同図に示すシステムは、ユーザとインタフェースを介してデータの送受信を行うXMLDBMS１００、オペレーティングシステム（OS）２００、コンピュータ（仮想コンピュータ）３００から構成される。
【００２５】
XMLDBMS１００は、XML文書集合記憶部１２０、スキーマ定義情報記憶部１３０を保持し、スキーマ定義に従って、XMLの部分木の一意性を保証する一意性管理機能部１１０を有する。
【００２６】
図２は、本発明の第１の実施の形態における一意性管理機能部の処理のフローチャートであり、一意性管理機能部１１０の一般的な処理を示している。
【００２７】
ステップ１０１）  一意性管理機能部１１０は、スキーマ定義情報記憶部１３０のスキーマ定義情報を解釈し、主キー指定が定義されているエレメントとキーの箇所をメモリ（図示せず）に記憶する。
【００２８】
ステップ１０２）  入力された新しいXML文書から、主キー指定されているエレメントとそのキー値を全て取り出す。
【００２９】
ステップ１０３）  既にXML文書集合記憶部１２０に格納されているXML文書群から、主キー指定されているエレメントとそのキー値を全て取り出す。
【００３０】
ステップ１０４）  最も上位のエレメントから順次キー値の比較を行う。
【００３１】
ステップ１０５）  同一のキー値がある場合はステップ１０８に移行し、ない場合はステップ１０６に移行する。
【００３２】
ステップ１０６）  全てのエレメントを比較した場合はステップ１０７に移行し、残りのエレメントがある場合はステップ１０４の処理に戻る。
【００３３】
ステップ１０７）  ステップ１０５において同一の値がない場合は新しいXML文書をXML文書集合記憶部１２０に格納する。
【００３４】
ステップ１０８）  ステップ１０５において、同一の値がある場合は例外信号を出力して終了する。なお、本発明における「例外信号」とは同一の値が既に存在していることを意味する。
【００３５】
上記のように、一意性管理機能部１１０は、木構造データを対象としているため、より上位のエレメントから、一意性をチェックしていく（スコープを絞り込んでいく）ことがポイントである。また、主キー指定が定義されているエレメントの解釈や記憶や、XML文書集合からキー値の走査の方法については、予めインデックスを作成しておくことで高速に行うことも考えられる。
【００３６】
[第２の実施の形態]
図３は、本発明の第２の実施の形態におけるシステム構成を示す。
【００３７】
同図において、図１と同一構成部分には同一符号を付し、その説明を省略する。
【００３８】
図３に示すシステムは、図１のXMLDBMS１００に追加/置換操作機能部１４０を付加した構成である。
【００３９】
追加/置換操作機能部１４０は、データの追加要求時に既に同一の主キーを持つ部分木がXML文書集合記憶部１２０に存在していた場合、該当する部分木を追加要求された新しい部分木に入れ替える。
【００４０】
具体的には、図２に示した一意性管理機能部１１０の処理のステップ１０８において、例外信号が出力された場合に、追加/置換操作機能部１４０は、既にXML文書集合記憶部１２０に格納されているXML文書の当該エレメントを、新しいXML文書の当該エレメントに置換する。
【００４１】
［第３の実施の形態］
図４は、本発明の第３の実施の形態におけるシステム構成を示す。
【００４２】
同図において、図１と同一構成部分には同一符号を付し、その説明を省略する。
【００４３】
図４に示すシステムは、図１のXMLDBMS１００に追加/追記操作機能部１５０を付加した構成である。
【００４４】
追加/追記操作機能部１５０は、データの追加要求時に既にXML文書集合記憶部１２０に同一の主キーを持つ部分木が存在していた場合、該当する部分木に対し、追加要求された新しい部分木を、整合性を保って追記する。
【００４５】
図５は、本発明の第３の実施の形態における追加/追記操作機能部の処理のフローチャートである。
【００４６】
ステップ３０１）  新しいXML文書の当該エレメントの下位で、最上位にあるキー指定されているエレメントとそのキー値群を取り出す。
【００４７】
ステップ３０２）  エレメントとキー値のペアを１つ取り出す。
【００４８】
ステップ３０３）  XML文書記憶部１２０に格納されているXML文書の当該エレメントの下位に同一のキー値を持つエレメントが存在するかを判定し、存在する場合はステップ３０４に移行し、存在しない場合はステップ３０５に移行する。
【００４９】
ステップ３０４）  当該エレメントの組に対して「追記操作」を行い、ステップ３０６に移行する。
【００５０】
ステップ３０５）  エレメントを、XML文書記憶部１２０に格納されているXML文書の当該エレメントの下位の適切な位置に追加する。
【００５１】
ステップ３０６）  全てのエレメントについて比較した場合は当該処理を終了し、残りのエレメントがある場合はステップ３０２に戻る。
【実施例１】
【００５２】
以下に第１の実施例として、前述の第１の実施の形態について具体的に説明する。
【００５３】
図６は、本発明の第１の実施例のデータ構造の例である。
【００５４】
同図に示すデータ構造は、XML Schema内に埋め込む形で実現したものである。これはあくまでも一つの例であり、スキーマファイルとは別にこれを記述する方法もある。
【００５５】
図７は、本発明の第１の実施例で用いる注文書を表すXML文書のデータ構造を模式化したものである。これはあくまでも一つの例であり、本発明は文書一般に適用可能である。
【００５６】
図８は、本発明の第１の実施例におけるデータ構造をスキーマ定義として記述した例であり、図７のデータ構造をXML Schemaと図６の記法を用いてスキーマ定義として記述したものである。
【００５７】
図８の例において、５〜２０行目の「order」エレメントの定義の中で、７〜１０行目に、このエレメントの主キーが直下の「date」エレメントと「orderNumber」エレメントであると定義している。また、２８〜３６行目の「itemOrder」エレメントの定義の中で、３０〜３４行目に、このエレメントの文書集合ないの主キーが、２階層上のエレメント、すなわち、「order」エレメントの直下の「date,orderNumber」エレメントならびにこのエレメント直下の「item」エレメント直下の「itemId」エレメントであると定義している。
【００５８】
ユーザが文書集合を作る際、このスキーマ定義を該文書集合に紐付けると、図１の一意性管理機能部１１０は、これら２つの主キー定義を読み取り、この文書集合に関連付けてスキーマ定義情報記憶部１３０に記憶しておく。
【００５９】
次に、ユーザがこの文書集合に、図９のXML文書を格納したとする。この文書は図８のスキーマ定義に従っており、これ以前に、「/order/date］エレメントが"20100323"であり、かつ、「/order/orderNumber」エレメントが"19"であるような文書はなく、また、order内に同じitemIdも存在しなかったので、問題なく格納される。
【００６０】
さらに、ユーザがこの文書集合に図１０に示すXML文書を新たに格納しようとしたとする。この文書はXML Schemaの定義は充足しているので、従来のXMLDBMSであれば、問題なく格納できる。しかし、図１の一意性管理機能部１１０を持つXMLDBMSでは、このとき一意性管理機能部１１０が一意性のチェックを行い、例外信号を出力する。
【００６１】
具体的には、一意性管理機能部１１０は、図２のフローに従い、対象となる文書集合に関連付けられた主キー定義を全て取り出す。
【００６２】
次に、これらの主キー定義をそれぞれチェックする。このチェックの順序については、本発明の範囲内では特に定義せず、並列に行ってもよいし、順番に行ってもよく、また、順番に行う場合、どちらを先に行ってもよい。ここでは、「order」エレメントの主キー定義チェック例を取り上げる。
【００６３】
まず、主キー定義より「order」の主キーは「order」直下の「date, orderNumber」エレメントの組なので、これらの値を図１０のXML文書から取り出すと、
（date, orderNumber） = (20100323, 19)
であることがわかる。
【００６４】
次に、対象文書集合内の「order」エレメントについて、直下の「date， orderNumber」エレメントの値がそれぞれ"20100323, 19"であるものが存在するかどうか検索する。本発明では、この検索の実行方法の詳細は特に定義せず、総当りで行ってもよいし、主キーに予めインデックスを張っておき、それを用いてもよい。すると、以前にXML文書集合記憶部１２０に格納された図９の文書に、該当する「order」エレメントが発見されるので、一意性管理機能部１１０は、例外信号を出力する。どれか一つの主キー定義チェックでも例外信号を出力した場合、一意性管理機能部１１０は全ての主キー定義チェックを終了する。
【００６５】
さらに、別の操作の例として、同じ文書集合に、今度は図１１の文書を新たに格納しようとする。この場合も、図１０の文書の場合と同様に、まず、一意性管理機能部１１０は、対象となる文書集合に関連付けられた主キー定義を全て取り出し、これらの主キー定義をそれぞれチェックする。ここでは、「itemOrder」エレメントの主キー定義チェックの例を取り上げる。まず、主キー定義より、「itemOrdere」の主キーは、
../..date, ../../orderNumber, item/itemId
なので、これらの値を図１１のXML文書から取り出すと、
（../../date, ../orderNumber, item/itemId) = (20100323, 21, ZEAS06)
となる組が、１０〜１７行目の「itemOrder」と、２６〜３３行目の「itemOrder」の２つあることがわかる。これは主キー定義で指定された一意性制約に反するので、一意性管理機能部１１０は、例外信号を出力する。どれか一つの主キー定義チェックでも例外信号を出力した場合、一意性管理機能部１１０は全ての主キー定義チェックを終了する。
【００６６】
一意性管理機能部１１０が例外信号を出力した後のXMLDBMSの振る舞いについては、本実施例の記述対象としない。
【００６７】
［第２の実施例］
以下に、第２の実施例として、前述の第２の実施の形態の具体例を示す。
【００６８】
本実施例でも、第１の実施例と同様、図６の記法、図７のXML文書構造、図８のスキーマ定義を利用して説明する。
【００６９】
さらに、スキーマ定義がある文書集合に設定されていて、既に図９のXML文書がこのXML文書集合記憶部１２０に格納されている状態を前提とする。
【００７０】
今、ユーザがこのXML文書集合記憶部１２０に図１０のXML文書を新たに格納しようとしたとする。第１の実施例で示したように、この文書はXML Schemaの定義は充足しているので、従来のXMLDBMSであれば問題なく格納できるが、図１の一意性管理機能部１１０を持つXMLDBMSでは、このとき一意性管理機能部１１０が一意性のチェックを行い、例外信号が出力される。
【００７１】
この信号を第２の実施の形態で示した追加/置換操作機能部１４０が受け取ると、追加/置換操作機能部１４０は、この文書集合内に存在する図９のXML文書の「order」エレメントの内容を、図１０のXML文書のエレメントの内容と置き換える操作を行う。
【００７２】
すなわち、操作が全て終了した後、このXML文書集合には、図９のXML文書は存在せず、図１０のXML文書が格納されている状態になる。また、第１の実施例までのXMLDBMSであれば、このXML文書集合記憶部１２０には、図９のXML文書が格納されていて、図１０のXML文書は存在しない状態となる。
【００７３】
また、もしこの操作が図１２のXML文書を格納する操作であれば、図１２のXML文書の「order」エレメントの主キー値は、
（date, orderNumber）=  (20100323,20)
であり、図９のXML文書の「order」エレメントの主キー値である
（date, orderNumber） =  (20100323,19)
とは衝突しないので、格納操作が通常通り行われる。この場合操作が全て終了した後、このXML文書集合記憶部１２０には、図９と図１２のXML文書が格納されている状態になる。
【００７４】
ここまで述べてきたように、追加/置換操作機能部１４０は、主キーが同じものがなければ追加を行い、主キーが同じものがあれば置換を行う機能である。
【００７５】
[第３の実施例]
本実施例でも、第１、第２の実施例と同様に、図６の記法、図７のXML文書構造、図８のスキーマ定義を利用する。さらに、このスキーマ定義がある文書集合に設定されていて、既に、図９のXML文書がこの文書集合記憶部１２０に格納されている状態を前提とする。
【００７６】
今、ユーザがこの文書集合記憶部１２０に図１０のXML文書を新たに格納しようとしたとする。第１の実施例で示したように、この文書は、XML Schemaの定義は充足しているので、従来のXMLDBMSであれば問題なく格納できるが、図１の一意性管理機能部１１０を持つXMLDBMSでは、このとき一意性管理機能部１１０が一意性のチェックを行い、例外信号が出力される。
【００７７】
この信号を第３の実施の形態で示した追加/追記操作機能部１５０が受け取ると、追加/追記操作機能部１５０は、この文書集合記憶部１２０内に存在する図９のXML文書の「order」エレメントの内容に、図１３の追記対象のXML文書の「order」エレメントの内容を、スキーマ定義との整合性を保って追記する操作を行う。
【００７８】
具体的な処理は、基本的には図９のXML文書集合記憶部１２０内のXML文書の「order」エレメントの内容と、図１３の追記対象のXML文書の「order」エレメントの内容を比較し、図１３の「order」エレメントの内容のうち図９の「order」エレメントの内容には存在しなかった部分を、図９の「order」エレメントの対応する部分に追加する。この例での処理は以下のようになる。
【００７９】
まず、図９、図１３の「order」エレメントにおいて、直下の「date」エレメントと「orderNumber」エレメントは一致していることがわかっているので、この部分について、追加/追記操作機能部１５０は何もしない。
【００８０】
また、両XML文書の「order」エレメントのアトリビュートを比べると、それぞれ「xmlns」アトリビュートを一つだけもち、その値も一致しているので、この部分については何もしない。同様に、両XML文書の「order」エレメント直下の「customer」エレメントも一致しているので、この部分についても追加/追記操作機能部１５０は何もしない。
【００８１】
さらに、「itemOrders」エレメントの内容を見ると、図１３の「itemOrder」エレメント内には、図９の「itemOrders」エレメントには含まれていない「itemOrder」エレメントが、図１３の１０〜３３行目まで３つある。従って、追加/追記操作機能部１５０は、文書集合記憶部１２０内にある図９のXML文書の「itemOrders」エレメント内に、図１３の１０〜３３行目間での３つの「itemOrder」エレメントを追記して、処理を終了する。
【００８２】
したがって、このXML文書集合記憶部１２０内の元の図９のXML文書は、一連の処理が終わった後は、図１４のようになっている。
【００８３】
ここまで述べてきたように、追加/置換機能操作部１５０は、主キーが同じものがなければ追加を行い、主キーが同じものがあれば、スキーマ定義の整合性を保って、適切な位置に差分を追記する操作を行う機能である。
【００８４】
なお、この例では、アトリビュートや「customer」エレメントが一致していたが、このような、主体キー以外でかつスキーマ定義において同一文書に１回（あるいは何らかの定数回:（アトリビュートの場合は常に１回、エレメントの場合はmaxOccursで定められた回数で、この例ではデフォルト値である１かい）しか出現していけないと定義されているアトリビュートあるいはエレメントが一致していなかった場合の振る舞いについて、本発明で規定するのは、スキーマ定義との整合性を保つということのみである。すなわち、この例では、２個目のアトリビュートや「custmer」エレメントを追記することはないということである。それ以上の振る舞いについては、例えば、異常発生として例外を出力して処理をロールバックする、図９のものをそのまま残して処理を続ける、あるいは、新しいもので置き換えて処理を続けるなどが考えられるが、本発明ではその部分には限定しない。
【００８５】
同様に、もし、図８のスキーマ定義で「itemOrder」エレメントのmaxOccursがunboundedではなく、例えば、"３"であった場合、図１３の１０〜３３行目間での３つの「itemOrder」エレメントを全て追記することは、スキーマ定義に反するのでできない。その場合、どの様な処理を行うかについては、前段同様に、様々な処理が考えられるが、本発明では特に限定しない。
【００８６】
なお、上記の実施の形態及び実施例で示したXMLDBMS１００の構成要素（一意性管理機能部、追加/置換操作機能部、追加/追記操作機能部）の動作をプログラムとして構築し、XMLDBMSとして利用されるコンピュータにインストールする、または、ネットワークを介して流通させることが可能である。
【００８７】
また、構築されたプログラムをハードディスクや、フレキシブルディスク、CD-ROM等の可搬記憶媒体に格納し、コンピュータにインストールする、または、配布することが可能である。
【００８８】
なお、本発明は、上記の実施の形態及び実施例に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。
【符号の説明】
【００８９】
１００  XMLデータベース管理システム（XMLDBMS）
１１０  一意性管理機能部
１２０  XML文書集合記憶部
１３０  スキーマ定義情報記憶部
１４０  追加/置換操作機能部
１５０  追加/追記操作機能部
２００  オペレーティングシステム（OS）
３００  コンピュータ/仮想コンピュータ
【図１】
0005506548.tif 000002
【図２】
0005506548.tif 000003
【図３】
0005506548.tif 000004
【図４】
0005506548.tif 000005
【図５】
0005506548.tif 000006
【図６】
0005506548.tif 000007
【図７】
0005506548.tif 000008
【図８】
0005506548.tif 000009
【図９】
0005506548.tif 000010
【図１０】
0005506548.tif 000011
【図１１】
0005506548.tif 000012
【図１２】
0005506548.tif 000013
【図１３】
0005506548.tif 000014
【図１４】
0005506548.tif 000015