JP5506548B2 - Xmlデータベース管理システム及び方法及びプログラム - Google Patents

Xmlデータベース管理システム及び方法及びプログラム Download PDF

Info

Publication number
JP5506548B2
JP5506548B2 JP2010126318A JP2010126318A JP5506548B2 JP 5506548 B2 JP5506548 B2 JP 5506548B2 JP 2010126318 A JP2010126318 A JP 2010126318A JP 2010126318 A JP2010126318 A JP 2010126318A JP 5506548 B2 JP5506548 B2 JP 5506548B2
Authority
JP
Japan
Prior art keywords
xml
xml document
document set
primary key
database management
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2010126318A
Other languages
English (en)
Other versions
JP2011253323A (ja
Inventor
展郎 谷口
俊文 榎本
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2010126318A priority Critical patent/JP5506548B2/ja
Publication of JP2011253323A publication Critical patent/JP2011253323A/ja
Application granted granted Critical
Publication of JP5506548B2 publication Critical patent/JP5506548B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Document Processing Apparatus (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Machine Translation (AREA)

Description

本発明は、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(例えば、非特許文献1参照)などのスキーマ定義言語が存在する。
XML Schema: http://www.w3.org/XML/Schema/ 3.11節
しかしながら、これらのスキーマ定義言語は、単独のXML文書のスキーマの定義を目的としたものであり、XML文書集合のスキーマの定義には不都合な点が存在する。その一つが、XML文書集合における、各XML文書の主キーの指定である。
通常、リレーショナルDBMS(RDBMS)では、テーブル毎に、一つのカラムあるいは複数のカラムの組を主キーとして指定し、レコードの集合であるテーブル内に、同一の主キーを持つレコードが1つしか存在しないよう保証する仕組みを持っている。しかし、従来のXMLDBMSでは、文書の主キーを指定し、XML集合内に、同一の主キーを持つXML文書が1つしか存在しないことを保証する仕組みはなかった。
XML Schemaでは、keyエレメントあるいはkeyrefエレメントを用いて、文書内のあるエレメントXに対し、下位のアトリビュートやエレメントを主キーとして指定して、主キーとして指定されたアトリビュートやエレメントが同じ値を持つエレメントXが、あるエレメント配下に1つしか存在しないような制約を記述することができる。
しかし、これはあくまで文書内のみでの整合性を考慮したものであり、複数の文書間での整合性を扱うことはできなかった。
また、主キーとして指定できるのは下位のアトリビュートやエレメントのみであり、上位のアトリビュートやエレメントを用いることはできなかった。
本発明は、上記の点に鑑みなされたもので、XMLDBMSで一意性のサポートを実現することが可能なXMLデータベース管理システム及び方法及びプログラムを提供することを目的とする。
上記の課題を解決するため、本発明(請求項1)は、一つあるいは複数のコンピュータ上で動作する一つのXMLデータベース管理システムであって、
XML文書集合を格納するXML文書集合記憶手段と、
一つのXML文書集合のスキーマを定義するスキーマ定義において、任意の階層の複数のエレメントのスキーマに、各エレメントに対して、主キーとして上位または下位の階層のエレメントあるいはアトリビュートを一つ以上指定するデータ構造が設定できる前提において、該XML文書集合に対する操作を要求された場合は、該操作前に、該主キーとして指定されたエレメントあるいはアトリビュートの値の組が、前記XML文書集合記憶手段の該XML文書集合中に一つしかないかどうかを上位のエレメントから順に判定し、2つ以上あれば、例外信号を出力する一意性管理手段と、を有する。
また、本発明(請求項2)は、前記各エレメントに対する主キーの設定では、
少なくとも1つのエレメントに対しては、複数の主キーが設定される。
また、本発明(請求項)は、一意性管理手段から例外信号が出力された場合に、前記主キーとして指定されたエレメントあるいはアトリビュートの値の組が、前記XML文書集合記憶手段の該XML文書集合中に2つ以上あると判定されたエレメントの内容を、該2つ以上あると判定されたエレメントのうち前記操作要求に含まれるエレメントの内容と置き換える操作を行う追加/置換操作手段を、更に有する。
また、本発明(請求項)は、一意性管理手段が例外信号を出力した場合に、前記XML文書集合記憶手段の該XML文書集合中に2つ以上あると判定されたエレメントのうち、前記操作要求に含まれるエレメントの内容を、その時点で該XML文書集合内に存在するエレメント内容に、スキーマ定義の整合性を保って追記する操作を行う追加/追記操作手段を、更に有する。
また、本発明(請求項)は、一つあるいは複数のコンピュータ上で動作する一つのXMLデータベース管理システムを管理するXMLデータベース管理方法であって、
XML文書集合を格納するXML文書集合記憶手段と、一意性管理手段を有する装置において、
前記一意性管理手段が、一つのXML文書集合のスキーマを定義するスキーマ定義において、任意の階層の複数のエレメントのスキーマに、各エレメントに対して、主キーとして上位または下位の階層のエレメントあるいはアトリビュートを一つ以上指定するデータ構造が設定できる前提において、該XML文書集合に対する操作を要求された場合は、該操作前に、該主キーとして指定されたエレメントあるいはアトリビュートの値の組が、前記XML文書集合記憶手段の該XML文書集合中に一つしかないかどうかを上位のエレメントから順に判定し、2つ以上あれば、例外信号を出力する。
また、本発明(請求項6)は、前記各エレメントに対する主キーの設定では、
少なくとも1つのエレメントに対しては、複数の主キーが設定される。
また、本発明(請求項)は、一意性管理手段が前記例外信号を出力した場合に、前記主キーとして指定されたエレメントあるいはアトリビュートの値の組が、前記XML文書集合記憶手段の該XML文書集合中に2つ以上あると判定されたエレメントの内容を、該2つ以上あると判定されたエレメントのうち前記操作要求に含まれるエレメントの内容と置き換える操作を行う。
また、本発明(請求項)は、一意性管理手段が前記例外信号を出力した場合に、前記XML文書集合記憶手段の該XML文書集合中に2つ以上あると判定されたエレメントのうち、前記操作要求に含まれるエレメントの内容を、その時点で該XML文書集合内に存在するエレメント内容に、スキーマ定義の整合性を保って追記する操作を行う。
また、本発明(請求項)は、請求項1乃至のいずれか1項に記載のXMLデータベース管理システムを構成する各手段としてコンピュータを機能させるためのプログラムである。

上記のように、本発明によれば、XML文書に文書の一意性を示すエレメントとエレメントの一意性を示すエレメントを設けて、文書やエレメントの一意性を保障することにより、XMLDBMSでもRDBMSと同等以上の一意性がサポートされるようになり、データを破壊されにくく、正確さを保ちやすくなる。また、それら一意性を、少ない手間で扱えるようになる。
本発明の第1の実施の形態におけるシステム構成図である。 本発明の第1の実施の形態における一意性管理機能部の処理のフローチャートである。 本発明の第2の実施の形態におけるシステム構成図である。 本発明の第3の実施の形態におけるシステム構成図である。 本発明の第3の実施の形態における追加/追記操作機能部の処理のフローチャートである。 本発明の第1の実施例のデータ構造の例である。 本発明の第1の実施例で用いる注文書を表すXML文書のデータ構造を模式化した図である。 本発明の第1の実施例におけるデータ構造をスキーマ定義として記述した例である。 本発明の第1の実施例における格納対象のXML文書の例である。 本発明の第1の実施例における新たなXML文書の例である。 本発明の第1の実施例における格納対象のXML文書の例である。 本発明の第2の実施例における格納対象のXML文書の例である。 本発明の第3の実施例の追記対象のXML文書の例である。 本発明の第3の実施例の処理終了後のXML文書集合記憶部のXML文書の例である。
以下に図面と共に、本発明の実施の形態を説明する。
本発明は、一意性のサポートをXMLDBMSで実現するために、文書間でも有効な主キー指定記述をスキーマに追加可能にするものである。また、主キー指定記述において、上位のアトリビュートやエレメントを指定可能にし、木構造において特徴的な上位階層からのスコープの絞込みにも対応できるようにする。
そして、XMLDBMSにおいて、上記の主キー指定記述を解釈し、同一の主キーを持つXMLの部分木(XML文書内の特定のノード以下のデータ)が、XML文書集合内で1つしか存在しないことを保証する仕組みを実現する。
[第1の実施の形態]
図1は、本発明の第1の実施の形態におけるシステム構成を示す。
同図に示すシステムは、ユーザとインタフェースを介してデータの送受信を行うXMLDBMS100、オペレーティングシステム(OS)200、コンピュータ(仮想コンピュータ)300から構成される。
XMLDBMS100は、XML文書集合記憶部120、スキーマ定義情報記憶部130を保持し、スキーマ定義に従って、XMLの部分木の一意性を保証する一意性管理機能部110を有する。
図2は、本発明の第1の実施の形態における一意性管理機能部の処理のフローチャートであり、一意性管理機能部110の一般的な処理を示している。
ステップ101) 一意性管理機能部110は、スキーマ定義情報記憶部130のスキーマ定義情報を解釈し、主キー指定が定義されているエレメントとキーの箇所をメモリ(図示せず)に記憶する。
ステップ102) 入力された新しいXML文書から、主キー指定されているエレメントとそのキー値を全て取り出す。
ステップ103) 既にXML文書集合記憶部120に格納されているXML文書群から、主キー指定されているエレメントとそのキー値を全て取り出す。
ステップ104) 最も上位のエレメントから順次キー値の比較を行う。
ステップ105) 同一のキー値がある場合はステップ108に移行し、ない場合はステップ106に移行する。
ステップ106) 全てのエレメントを比較した場合はステップ107に移行し、残りのエレメントがある場合はステップ104の処理に戻る。
ステップ107) ステップ105において同一の値がない場合は新しいXML文書をXML文書集合記憶部120に格納する。
ステップ108) ステップ105において、同一の値がある場合は例外信号を出力して終了する。なお、本発明における「例外信号」とは同一の値が既に存在していることを意味する。
上記のように、一意性管理機能部110は、木構造データを対象としているため、より上位のエレメントから、一意性をチェックしていく(スコープを絞り込んでいく)ことがポイントである。また、主キー指定が定義されているエレメントの解釈や記憶や、XML文書集合からキー値の走査の方法については、予めインデックスを作成しておくことで高速に行うことも考えられる。
[第2の実施の形態]
図3は、本発明の第2の実施の形態におけるシステム構成を示す。
同図において、図1と同一構成部分には同一符号を付し、その説明を省略する。
図3に示すシステムは、図1のXMLDBMS100に追加/置換操作機能部140を付加した構成である。
追加/置換操作機能部140は、データの追加要求時に既に同一の主キーを持つ部分木がXML文書集合記憶部120に存在していた場合、該当する部分木を追加要求された新しい部分木に入れ替える。
具体的には、図2に示した一意性管理機能部110の処理のステップ108において、例外信号が出力された場合に、追加/置換操作機能部140は、既にXML文書集合記憶部120に格納されているXML文書の当該エレメントを、新しいXML文書の当該エレメントに置換する。
[第3の実施の形態]
図4は、本発明の第3の実施の形態におけるシステム構成を示す。
同図において、図1と同一構成部分には同一符号を付し、その説明を省略する。
図4に示すシステムは、図1のXMLDBMS100に追加/追記操作機能部150を付加した構成である。
追加/追記操作機能部150は、データの追加要求時に既にXML文書集合記憶部120に同一の主キーを持つ部分木が存在していた場合、該当する部分木に対し、追加要求された新しい部分木を、整合性を保って追記する。
図5は、本発明の第3の実施の形態における追加/追記操作機能部の処理のフローチャートである。
ステップ301) 新しいXML文書の当該エレメントの下位で、最上位にあるキー指定されているエレメントとそのキー値群を取り出す。
ステップ302) エレメントとキー値のペアを1つ取り出す。
ステップ303) XML文書記憶部120に格納されているXML文書の当該エレメントの下位に同一のキー値を持つエレメントが存在するかを判定し、存在する場合はステップ304に移行し、存在しない場合はステップ305に移行する。
ステップ304) 当該エレメントの組に対して「追記操作」を行い、ステップ306に移行する。
ステップ305) エレメントを、XML文書記憶部120に格納されているXML文書の当該エレメントの下位の適切な位置に追加する。
ステップ306) 全てのエレメントについて比較した場合は当該処理を終了し、残りのエレメントがある場合はステップ302に戻る。
以下に第1の実施例として、前述の第1の実施の形態について具体的に説明する。
図6は、本発明の第1の実施例のデータ構造の例である。
同図に示すデータ構造は、XML Schema内に埋め込む形で実現したものである。これはあくまでも一つの例であり、スキーマファイルとは別にこれを記述する方法もある。
図7は、本発明の第1の実施例で用いる注文書を表すXML文書のデータ構造を模式化したものである。これはあくまでも一つの例であり、本発明は文書一般に適用可能である。
図8は、本発明の第1の実施例におけるデータ構造をスキーマ定義として記述した例であり、図7のデータ構造をXML Schemaと図6の記法を用いてスキーマ定義として記述したものである。
図8の例において、5〜20行目の「order」エレメントの定義の中で、7〜10行目に、このエレメントの主キーが直下の「date」エレメントと「orderNumber」エレメントであると定義している。また、28〜36行目の「itemOrder」エレメントの定義の中で、30〜34行目に、このエレメントの文書集合ないの主キーが、2階層上のエレメント、すなわち、「order」エレメントの直下の「date,orderNumber」エレメントならびにこのエレメント直下の「item」エレメント直下の「itemId」エレメントであると定義している。
ユーザが文書集合を作る際、このスキーマ定義を該文書集合に紐付けると、図1の一意性管理機能部110は、これら2つの主キー定義を読み取り、この文書集合に関連付けてスキーマ定義情報記憶部130に記憶しておく。
次に、ユーザがこの文書集合に、図9のXML文書を格納したとする。この文書は図8のスキーマ定義に従っており、これ以前に、「/order/date]エレメントが"20100323"であり、かつ、「/order/orderNumber」エレメントが"19"であるような文書はなく、また、order内に同じitemIdも存在しなかったので、問題なく格納される。
さらに、ユーザがこの文書集合に図10に示すXML文書を新たに格納しようとしたとする。この文書はXML Schemaの定義は充足しているので、従来のXMLDBMSであれば、問題なく格納できる。しかし、図1の一意性管理機能部110を持つXMLDBMSでは、このとき一意性管理機能部110が一意性のチェックを行い、例外信号を出力する。
具体的には、一意性管理機能部110は、図2のフローに従い、対象となる文書集合に関連付けられた主キー定義を全て取り出す。
次に、これらの主キー定義をそれぞれチェックする。このチェックの順序については、本発明の範囲内では特に定義せず、並列に行ってもよいし、順番に行ってもよく、また、順番に行う場合、どちらを先に行ってもよい。ここでは、「order」エレメントの主キー定義チェック例を取り上げる。
まず、主キー定義より「order」の主キーは「order」直下の「date, orderNumber」エレメントの組なので、これらの値を図10のXML文書から取り出すと、
(date, orderNumber) = (20100323, 19)
であることがわかる。
次に、対象文書集合内の「order」エレメントについて、直下の「date, orderNumber」エレメントの値がそれぞれ"20100323, 19"であるものが存在するかどうか検索する。本発明では、この検索の実行方法の詳細は特に定義せず、総当りで行ってもよいし、主キーに予めインデックスを張っておき、それを用いてもよい。すると、以前にXML文書集合記憶部120に格納された図9の文書に、該当する「order」エレメントが発見されるので、一意性管理機能部110は、例外信号を出力する。どれか一つの主キー定義チェックでも例外信号を出力した場合、一意性管理機能部110は全ての主キー定義チェックを終了する。
さらに、別の操作の例として、同じ文書集合に、今度は図11の文書を新たに格納しようとする。この場合も、図10の文書の場合と同様に、まず、一意性管理機能部110は、対象となる文書集合に関連付けられた主キー定義を全て取り出し、これらの主キー定義をそれぞれチェックする。ここでは、「itemOrder」エレメントの主キー定義チェックの例を取り上げる。まず、主キー定義より、「itemOrdere」の主キーは、
../..date, ../../orderNumber, item/itemId
なので、これらの値を図11のXML文書から取り出すと、
(../../date, ../orderNumber, item/itemId) = (20100323, 21, ZEAS06)
となる組が、10〜17行目の「itemOrder」と、26〜33行目の「itemOrder」の2つあることがわかる。これは主キー定義で指定された一意性制約に反するので、一意性管理機能部110は、例外信号を出力する。どれか一つの主キー定義チェックでも例外信号を出力した場合、一意性管理機能部110は全ての主キー定義チェックを終了する。
一意性管理機能部110が例外信号を出力した後のXMLDBMSの振る舞いについては、本実施例の記述対象としない。
[第2の実施例]
以下に、第2の実施例として、前述の第2の実施の形態の具体例を示す。
本実施例でも、第1の実施例と同様、図6の記法、図7のXML文書構造、図8のスキーマ定義を利用して説明する。
さらに、スキーマ定義がある文書集合に設定されていて、既に図9のXML文書がこのXML文書集合記憶部120に格納されている状態を前提とする。
今、ユーザがこのXML文書集合記憶部120に図10のXML文書を新たに格納しようとしたとする。第1の実施例で示したように、この文書はXML Schemaの定義は充足しているので、従来のXMLDBMSであれば問題なく格納できるが、図1の一意性管理機能部110を持つXMLDBMSでは、このとき一意性管理機能部110が一意性のチェックを行い、例外信号が出力される。
この信号を第2の実施の形態で示した追加/置換操作機能部140が受け取ると、追加/置換操作機能部140は、この文書集合内に存在する図9のXML文書の「order」エレメントの内容を、図10のXML文書のエレメントの内容と置き換える操作を行う。
すなわち、操作が全て終了した後、このXML文書集合には、図9のXML文書は存在せず、図10のXML文書が格納されている状態になる。また、第1の実施例までのXMLDBMSであれば、このXML文書集合記憶部120には、図9のXML文書が格納されていて、図10のXML文書は存在しない状態となる。
また、もしこの操作が図12のXML文書を格納する操作であれば、図12のXML文書の「order」エレメントの主キー値は、
(date, orderNumber)= (20100323,20)
であり、図9のXML文書の「order」エレメントの主キー値である
(date, orderNumber) = (20100323,19)
とは衝突しないので、格納操作が通常通り行われる。この場合操作が全て終了した後、このXML文書集合記憶部120には、図9と図12のXML文書が格納されている状態になる。
ここまで述べてきたように、追加/置換操作機能部140は、主キーが同じものがなければ追加を行い、主キーが同じものがあれば置換を行う機能である。
[第3の実施例]
本実施例でも、第1、第2の実施例と同様に、図6の記法、図7のXML文書構造、図8のスキーマ定義を利用する。さらに、このスキーマ定義がある文書集合に設定されていて、既に、図9のXML文書がこの文書集合記憶部120に格納されている状態を前提とする。
今、ユーザがこの文書集合記憶部120に図10のXML文書を新たに格納しようとしたとする。第1の実施例で示したように、この文書は、XML Schemaの定義は充足しているので、従来のXMLDBMSであれば問題なく格納できるが、図1の一意性管理機能部110を持つXMLDBMSでは、このとき一意性管理機能部110が一意性のチェックを行い、例外信号が出力される。
この信号を第3の実施の形態で示した追加/追記操作機能部150が受け取ると、追加/追記操作機能部150は、この文書集合記憶部120内に存在する図9のXML文書の「order」エレメントの内容に、図13の追記対象のXML文書の「order」エレメントの内容を、スキーマ定義との整合性を保って追記する操作を行う。
具体的な処理は、基本的には図9のXML文書集合記憶部120内のXML文書の「order」エレメントの内容と、図13の追記対象のXML文書の「order」エレメントの内容を比較し、図13の「order」エレメントの内容のうち図9の「order」エレメントの内容には存在しなかった部分を、図9の「order」エレメントの対応する部分に追加する。この例での処理は以下のようになる。
まず、図9、図13の「order」エレメントにおいて、直下の「date」エレメントと「orderNumber」エレメントは一致していることがわかっているので、この部分について、追加/追記操作機能部150は何もしない。
また、両XML文書の「order」エレメントのアトリビュートを比べると、それぞれ「xmlns」アトリビュートを一つだけもち、その値も一致しているので、この部分については何もしない。同様に、両XML文書の「order」エレメント直下の「customer」エレメントも一致しているので、この部分についても追加/追記操作機能部150は何もしない。
さらに、「itemOrders」エレメントの内容を見ると、図13の「itemOrder」エレメント内には、図9の「itemOrders」エレメントには含まれていない「itemOrder」エレメントが、図13の10〜33行目まで3つある。従って、追加/追記操作機能部150は、文書集合記憶部120内にある図9のXML文書の「itemOrders」エレメント内に、図13の10〜33行目間での3つの「itemOrder」エレメントを追記して、処理を終了する。
したがって、このXML文書集合記憶部120内の元の図9のXML文書は、一連の処理が終わった後は、図14のようになっている。
ここまで述べてきたように、追加/置換機能操作部150は、主キーが同じものがなければ追加を行い、主キーが同じものがあれば、スキーマ定義の整合性を保って、適切な位置に差分を追記する操作を行う機能である。
なお、この例では、アトリビュートや「customer」エレメントが一致していたが、このような、主体キー以外でかつスキーマ定義において同一文書に1回(あるいは何らかの定数回:(アトリビュートの場合は常に1回、エレメントの場合はmaxOccursで定められた回数で、この例ではデフォルト値である1かい)しか出現していけないと定義されているアトリビュートあるいはエレメントが一致していなかった場合の振る舞いについて、本発明で規定するのは、スキーマ定義との整合性を保つということのみである。すなわち、この例では、2個目のアトリビュートや「custmer」エレメントを追記することはないということである。それ以上の振る舞いについては、例えば、異常発生として例外を出力して処理をロールバックする、図9のものをそのまま残して処理を続ける、あるいは、新しいもので置き換えて処理を続けるなどが考えられるが、本発明ではその部分には限定しない。
同様に、もし、図8のスキーマ定義で「itemOrder」エレメントのmaxOccursがunboundedではなく、例えば、"3"であった場合、図13の10〜33行目間での3つの「itemOrder」エレメントを全て追記することは、スキーマ定義に反するのでできない。その場合、どの様な処理を行うかについては、前段同様に、様々な処理が考えられるが、本発明では特に限定しない。
なお、上記の実施の形態及び実施例で示したXMLDBMS100の構成要素(一意性管理機能部、追加/置換操作機能部、追加/追記操作機能部)の動作をプログラムとして構築し、XMLDBMSとして利用されるコンピュータにインストールする、または、ネットワークを介して流通させることが可能である。
また、構築されたプログラムをハードディスクや、フレキシブルディスク、CD-ROM等の可搬記憶媒体に格納し、コンピュータにインストールする、または、配布することが可能である。
なお、本発明は、上記の実施の形態及び実施例に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。
100 XMLデータベース管理システム(XMLDBMS)
110 一意性管理機能部
120 XML文書集合記憶部
130 スキーマ定義情報記憶部
140 追加/置換操作機能部
150 追加/追記操作機能部
200 オペレーティングシステム(OS)
300 コンピュータ/仮想コンピュータ

Claims (9)

  1. 一つあるいは複数のコンピュータ上で動作する一つのXMLデータベース管理システムであって、
    XML文書集合を格納するXML文書集合記憶手段と、
    一つのXML文書集合のスキーマを定義するスキーマ定義において、任意の階層の複数のエレメントのスキーマに、各エレメントに対して、主キーとして上位または下位の階層のエレメントあるいはアトリビュートを一つ以上指定するデータ構造が設定できる前提において、該XML文書集合に対する操作を要求された場合は、該操作前に、該主キーとして指定されたエレメントあるいはアトリビュートの値の組が、前記XML文書集合記憶手段の該XML文書集合中に一つしかないかどうかを上位のエレメントから順に判定し、2つ以上あれば、例外信号を出力する一意性管理手段と、
    を有することを特徴とするXMLデータベース管理システム。
  2. 前記各エレメントに対する主キーの設定では、
    少なくとも1つのエレメントに対しては、複数の主キーが設定される、
    ことを特徴とする請求項1記載のXMLデータベース管理システム。
  3. 前記一意性管理手段が前記例外信号を出力した場合に、前記主キーとして指定されたエレメントあるいはアトリビュートの値の組が、前記XML文書集合記憶手段の該XML文書集合中に2つ以上あると判定されたエレメントの内容を、該2つ以上あると判定されたエレメントのうち前記操作要求に含まれるエレメントの内容と置き換える操作を行う追加/置換操作手段を、更に有する
    請求項1または2記載のXMLデータベース管理システム。
  4. 前記一意性管理手段が前記例外信号を出力した場合に、前記XML文書集合記憶手段の該XML文書集合中に2つ以上あると判定されたエレメントのうち、前記操作要求に含まれるエレメントの内容を、その時点で該XML文書集合内に存在するエレメント内容に、スキーマ定義の整合性を保って追記する操作を行う追加/追記操作手段を、更に有する
    請求項1または2記載のXMLデータベース管理システム。
  5. 一つあるいは複数のコンピュータ上で動作する一つのXMLデータベース管理システムを管理するXMLデータベース管理方法であって、
    XML文書集合を格納するXML文書集合記憶手段と、一意性管理手段を有する装置において、
    前記一意性管理手段が、一つのXML文書集合のスキーマを定義するスキーマ定義において、任意の階層の複数のエレメントのスキーマに、各エレメントに対して、主キーとして上位または下位の階層のエレメントあるいはアトリビュートを一つ以上指定するデータ構造が設定できる前提において、該XML文書集合に対する操作を要求された場合は、該操作前に、該主キーとして指定されたエレメントあるいはアトリビュートの値の組が、前記XML文書集合記憶手段の該XML文書集合中に一つしかないかどうかを上位のエレメントから順に判定し、2つ以上あれば、例外信号を出力する
    ことを特徴とするXMLデータベース管理方法。
  6. 前記各エレメントに対する主キーの設定では、
    少なくとも1つのエレメントに対しては、複数の主キーが設定される、
    ことを特徴とする請求項5記載のXMLデータベース管理方法。
  7. 前記一意性管理手段が出力した前記例外信号を受け取った場合に、前記主キーとして指定されたエレメントあるいはアトリビュートの値の組が、前記XML文書集合記憶手段の該XML文書集合中に2つ以上あると判定されたエレメントの内容を、該2つ以上あると判定されたエレメントのうち前記操作要求に含まれるエレメントの内容と置き換える操作を行う
    請求項5または6記載のXMLデータベース管理方法。
  8. 前記一意性管理手段が出力した前記例外信号を受け取った場合に、前記XML文書集合記憶手段の該XML文書集合中に2つ以上あると判定されたエレメントのうち、前記操作要求に含まれるエレメントの内容を、その時点で該XML文書集合内に存在するエレメント内容に、スキーマ定義の整合性を保って追記する操作を行う
    請求項5または6記載のXMLデータベース管理方法。
  9. 請求項1乃至のいずれか1項に記載のXMLデータベース管理システムを構成する各手段としてコンピュータを機能させるためのプログラム。
JP2010126318A 2010-06-01 2010-06-01 Xmlデータベース管理システム及び方法及びプログラム Active JP5506548B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2010126318A JP5506548B2 (ja) 2010-06-01 2010-06-01 Xmlデータベース管理システム及び方法及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2010126318A JP5506548B2 (ja) 2010-06-01 2010-06-01 Xmlデータベース管理システム及び方法及びプログラム

Publications (2)

Publication Number Publication Date
JP2011253323A JP2011253323A (ja) 2011-12-15
JP5506548B2 true JP5506548B2 (ja) 2014-05-28

Family

ID=45417222

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010126318A Active JP5506548B2 (ja) 2010-06-01 2010-06-01 Xmlデータベース管理システム及び方法及びプログラム

Country Status (1)

Country Link
JP (1) JP5506548B2 (ja)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4289022B2 (ja) * 2003-05-22 2009-07-01 日本電信電話株式会社 構造化文書処理方法及び装置及び構造化文書処理プログラム及び構造化文書処理プログラムを格納した記憶媒体
JP2005284575A (ja) * 2004-03-29 2005-10-13 Fujitsu Ltd タグ付き構造化文書格納システム、そのプログラム、及びその方法。

Also Published As

Publication number Publication date
JP2011253323A (ja) 2011-12-15

Similar Documents

Publication Publication Date Title
US20210334250A1 (en) Construction of database schema models for database systems and rest api's
EP2909748B1 (en) Data lineage system
US9477786B2 (en) System for metadata management
US7865873B1 (en) Browser-based system and method for defining and manipulating expressions
CN102521416B (zh) 数据关联查询方法和数据关联查询装置
RU2378690C2 (ru) Способ и система для преобразования иерархической структуры данных на основе схемы в плоскую структуру данных
EP2260413B1 (en) Web content management
US8886617B2 (en) Query-based searching using a virtual table
US11288290B2 (en) Building reports
US7720885B2 (en) Generating a word-processing document from database content
JP6078437B2 (ja) パーソナル情報匿名化システム
JP2006114045A (ja) スキーマデータ(schemadata)からデータ構造へのマッピング
US6915303B2 (en) Code generator system for digital libraries
JP2008052662A (ja) 構造化文書管理システム及びプログラム
US20160092554A1 (en) Method and system for visualizing relational data as rdf graphs with interactive response time
KR20060067812A (ko) 복합 데이터 액세스
US9613067B2 (en) Defining and transforming entity relationship-XML hybrid data models
US20210089619A1 (en) Methods to create and use responsive forms with externalized configurations and artifacts
US20080027899A1 (en) Systems and Methods for Integrating from Data Sources to Data Target Locations
WO2007081017A1 (ja) 文書処理装置
US7873902B2 (en) Transformation of versions of reports
JP5506548B2 (ja) Xmlデータベース管理システム及び方法及びプログラム
US11636421B1 (en) Model driven reporting
JP2008234429A (ja) 部分ライブラリ構築装置、プログラムおよび部分ライブラリ構築方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20121025

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20130828

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130903

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20131004

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20131028

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20140311

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140318

R150 Certificate of patent or registration of utility model

Ref document number: 5506548

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150