JP2004342091A

JP2004342091A - 階層データ形式のためのデータベースモデル

Info

Publication number: JP2004342091A
Application number: JP2004111979A
Authority: JP
Inventors: Marco Winter; ヴィンテルマルコ; Hartmut Peters; ハルトムート　ペーテルス; Meinolf Blawat; ブラヴァートマイノルフ; Ralf Ostermann; オステルマンラルフ; Dietmar Hepper; ヘッペルディトマール
Original assignee: Thomson Licensing SAS
Current assignee: Thomson Licensing SAS
Priority date: 2003-04-07
Filing date: 2004-04-06
Publication date: 2004-12-02
Anticipated expiration: 2024-04-06
Also published as: US7269582B2; CN1542657A; EP1467289A1; JP4561150B2; CN1542657B; KR101066628B1; TW200424884A; KR20040087903A; US20040199547A1; MY136874A; TWI334552B

Abstract

【課題】階層データ形式をリレーショナルデータベース管理システムにマッピングする際にデータの一貫性を保証する方法を提供する。
【解決手段】データ項目が、リンクする識別子及びロケータを有し、識別子及びロケータがデータ項目と共にデータベースに格納される方法において、識別子及びロケータの現在の組合せが格納済みであるか検査し（１１）、格納済みの場合、データ項目の格納済みの組合せを用い（１２）、格納済みでない場合、識別子又はロケータのどちらかがデータベースに格納済みであるか検査し（１３、１５）、格納済みの場合、識別子及びロケータの現在の組合せを一義的な組合せで置き換え（１４、１６）、一義的な組合せをデータ項目とともに格納し（１７）、格納されていない場合、識別子及びロケータの現在の組合せをデータ項目とともに格納する。
【選択図】図５

Description

本発明は、階層データ形式をリレーショナルデータベース管理システムにマッピングする際にデータの一貫性を保証する方法に関する。さらに、本発明は、このような方法を用いて記録媒体から読み出し及び／又は該媒体へ書き込む装置に関する。

デジタル記録の将来は、付加価値データサービスの前処理、提示及び達成によって特徴づけられるであろう。すなわち、例えばＤＶＲ（デジタルビデオレコーダ）のようなレコーダは、放送局や特殊サービスのようなコンテンツプロバイダによって配信され、又はユーザ自身によってさえも組み立てられる付加情報を格納し処理することになる。付加価値（メタデータ）は、ユーザにさらに情報を与えるために生成される。例えば、付加価値は、映画のあらすじを説明する要約、俳優の一覧などでよい。映画の中のナビゲーションを容易にする付加情報を提供することも、付加価値となる。例えば、映画は、セクション、サブセクションなどに構造化することができ、それぞれが個別のタイトルをもち、さらに有用な情報を含むこともできる。

構造的な情報を提供し、映像ストリームや音声ストリームのようなマルチメディアオブジェクト用の他のメタデータを移送するために、階層データ形式が一般に用いられる。公知であるとともに広く受け入れられている階層データ形式は、拡張マークアップ言語ＸＭＬである。ＸＭＬは、フォーマットされたデータの転送に使われる専用のマークアップ言語を定義するシステムである。従って、ＸＭＬは、他の専用言語の作成に使われる言語であるメタ言語とも呼ばれる。ＸＭＬデータは、複数の記述子の形で編成されるテキストから構成される。テキスト自体は、要素、属性及び内容、すなわち残りのテキストを含む。マルチメディアオブジェクト向けの用途以外にも、ＸＭＬ用の他の多くのアプリケーションが公知である。

近い将来、デジタルレコーダが非常に大量のデータを、ＸＭＬ又は別の階層データ形式でリレーショナルデータベースに格納することが予想される。というのは、こうしたデータベースは広く用いられており、非常に高機能だからである。格納のために、階層データ形式は、リレーショナルデータベース管理システム（ＲＤＢＭＳ）にマッピングされなければならない。従って、記述子を含む階層データ形式をリレーショナルデータベース管理システムにマッピングする方法が、係属中の欧州特許出願番号０２０１７０４５．２において提案されている。この方法によると、記述子は共通形式の部分に分けられ、こうした部分が関係づけられてリレーショナルデータベースに格納される。データベースモデルは、図４を参照して後で説明する。

ＸＭＬでは、１つの文書が、複数のソフトウェアモジュール用に定義され且つ使用される要素及び属性を含むことができる。このような文書に対しては、認識及び起こり得る衝突が考慮されなければならない。ソフトウェアモジュールは、別のソフトウェアモジュール用に同じ要素タイプ又は属性名が異なるように定義されているときに衝突が起きたとしても、処理しなければならない要素及び属性を認識する必要がある。これにより、要素及び属性は、それを含む文書を超える範囲で汎用名をもつことが要求される。この目的のために、名前空間がＸＭＬにおいて使用される。ＸＭＬの名前空間とは、ロケータ、すなわち汎用資源識別子（ＵＲＩ）によって識別される名前の集合体である。曖昧性のない識別のために、文書中の要素及び属性には、接頭部が提供される。接頭部は、セパレータと呼ばれるものによって要素又は属性から分離され、例えば、ｍｗ：ａｕｔｈｏｒ（接頭部＝「ｍｗ」、セパレータ＝「：」、要素名=「ａｕｔｈｏｒ」）のようになる。このような接頭部を使うことができるようになる前は、ＸＭＬ文書において以下のように定義しなければならない。
<Section xmlns:mw="http://www.mw-homepage/mws-namespaces">
<mw:author>Winter et al.</mw:author>
</Section>

この例では、名前空間宣言はタグ「ｘｍｌｎｓ」で始まり、その後にセパレータ「：」及びＵＲＩ「http://www.mw-homepage/mws-namespaces」が続く。しかし、接頭部は、わずかな制約だけで誰でも自由に選択することができるので、以下のような矛盾する定義が起こる場合がある。
<Section xmlns:mw="http://www.mw-homepage/mws-namespaces">
<mw:title>Namespaces</mw:title>
</Section>

<Chapter xmlns:mw="http://www.another-mw-homepage/XML/ns">
<mw:section>Section 1</mw:section>
</Chapter>

上の例では、異なる２つのロケータが同じ接頭部とともに使われている。両方の定義が１つのデータベースに格納される場合、データベース中のデータは整合性がなくなる。
欧州特許出願番号０２０１７０４５．２

本発明の目的は、従来技術から公知であるリレーショナルデータベースに、階層データ形式でデータを格納する方法を改善することである。

本発明によると、データベースにデータ項目を格納する際のデータの一貫性を保証する方法であって、そのデータ項目は、当該データ項目を宛先にリンクする識別子及びロケータを有し、識別子とロケータとが、データ項目に加えてデータベースに格納される方法において、
識別子及びロケータの現在の組合せがデータベースに格納済みであるかを検査し、格納済みの場合、データ項目に対して、格納済みの組合せを用いるステップと、
識別子及びロケータの現在の組合せがデータベースに格納済みでない場合、識別子又はロケータのいずれかがデータベースに格納済みであるか検査し、格納済みの場合、識別子及びロケータの現在の組合せを一義的な組合せで置き換え、一義的な組合せをデータ項目とともに格納するステップと、
上記ステップにおいて、前記識別子も前記ロケータも前記データベースに格納済みでない場合、識別子及びロケータの現在の組合せをデータ項目とともに格納するステップとを含む。

好ましくは、識別子及びロケータは、データ項目とは別々にデータベースに格納される。格納する前に、識別子及びロケータの組合せが使用済みであり格納済みであるか検査される。使用済みであり格納済みである場合、この組合せは、制約なく使うことができる。しかし、識別子又はロケータのどちらかが使用済みあり、異なる組合せでデータベースに格納済みである場合、現在の組合せを格納すると、一貫性のないデータがもたらされる。従って、この場合、現在の組合せは、一義的な識別子及びロケータの組合せに置き換えられ、これが次いで、データベースに格納される。識別子もロケータもデータベースに格納されていない場合、識別子及びロケータの現在の組合せがデータ項目に加えて格納される。本方法は、単一の識別子が複数のロケータとともにデータベースに格納されることを防止することによって、データの一貫性が保証されるという利点を有する。各識別子は、単一の、一義的なロケータに関連づけられる。

好ましくは、置き換えるステップは、
異なるロケータとの組合せで識別子が格納済みである場合、この識別子を、データベースに格納されていない一義的な識別子で置き換えるステップと、
異なる識別子との組合せでロケータが格納済みである場合、その識別子を、格納済みである識別子で置き換えるステップとを含む。異なるロケータとの組合せで識別子が格納済みである場合、この識別子を、データベースに格納されていない新しい識別子で置き換えるだけで十分である。しかし、このロケータが、異なる識別子との組合せで格納済みである場合、この識別子は有利には、格納済みである識別子で置き換えられる。後者は、データの一貫性を保証するために絶対に必要なわけではないが、データベース中での繰返しを防止し、従って、データベースに格納されなければならないデータの量を削減するのに役立つ。

好ましくは、データ項目は、階層データ形式のワードである。このようなワードの例は、要素及び属性である。階層データ形式は一般に、構造的な情報を提供するとともにマルチメディアオブジェクト用の他のメタデータを移送するために使われる。従って、本方法は、マルチメディアアプリケーションに広く適用可能となる。ただし、本方法は、階層データ形式に限定されず、他のデータ形式にも適用することができる。

好ましくは、階層データ形式は、拡張マークアップ言語ＸＭＬである。ＸＭＬは、公知であるとともに広く受け入れられている、記述子の形で編成されるテキストから構成される階層データ形式である。このようにして、本方法は、ＸＭＬ記述子の形のメタデータを含む、どのタイプのマルチメディアオブジェクトにも適用可能である。ＸＭＬは、ＳＧＭＬ、すなわち汎用マークアップ言語［ＩＳＯ８８７９］から派生した、十分に仕様が定められているマークアップ言語なので、ＸＭＬ記述子は予め定義された規則に従い、予期されないデータも条件も起こらない。

好ましくは、識別子及びロケータの組合せは名前空間宣言である。名前空間は、拡張マークアップ言語の重要な特徴である。名前空間により、同じ要素及び属性に対して異なる意味を定義し、又は追加の要素及び属性を定義することが可能になる。データベース中の異なる文書間での衝突を避けるために、ＸＭＬ記述子を格納することができるデータベースが、有利には名前空間を処理する方法を提供する。

好ましくは、ロケータは、統一資源識別子ＵＲＩである。統一資源識別子は、定義された宛先を指すための、公知であるとともに確立した概念である。当然ながら、統一資源ロケータ（ＵＲＬ）や統一資源名（ＵＲＮ）など他のタイプのロケータも使うことができる。

好ましくは、識別子は接頭部である。接頭部は、要素又は属性を、接頭部に関連づけられるとともにそれによって識別される規則によって定義されるものであると特徴づけるための、非常に容易であり使いやすい手段である。一般に、接頭部は、セパレータと呼ばれるもの、例えば「：」によって、要素又は属性から分離される。好ましくは、接頭部は、限られた数の制約だけで自由に選択することができる。可能な制約は例えば、標準定義、禁制文字、及び接頭部の長さに対する上限又は下限に関連する、特殊な予約接頭部である。

好ましくは、データ項目、識別子、及びロケータは、リレーショナルデータベースに格納される。こうしたデータベースは広く使用されており、非常に高性能である。こうしたデータベースにより、容易な操作及び高速なデータ探索が可能になる。当然ながら、本発明は、リレーショナルデータベースに限定されるわけではない。本発明は、他のタイプのデータベースにも適用することができる。

好ましくは、記録媒体から読み出し及び／又は該媒体へ書き込む装置は、データベースにデータ項目を格納する際のデータの一貫性を保証するために、本発明による方法を使用する。上述したように、将来のデジタルレコーダは、非常に大量のデータを階層データ形式でリレーショナルデータベースに格納することになるであろう。おそらく、階層データ形式は名前空間又は類似の概念を含むことになるので、こうしたデジタルレコーダは、好ましくは識別子及びロケータを処理することができる。

本発明のより良い理解のために、例示的な実施形態を、ＸＭＬを階層データ形式の例として用いて、以下の有利な実施形態の説明において図面を参照して詳細に述べる。本発明はこうした例示的な実施形態に限定されず、詳細に述べる特徴は、本発明の精神から逸脱することなく、便宜的に組み合せ及び／又は修正することもできることが理解されよう。

図１は、複数のメタデータ記述子２を含むメタデータストリーム１を示しており、それは図２を参照して後でより詳細に説明する。メタデータストリーム１は、メタデータ記述子２に加えて名前空間宣言３を含み、この宣言は、特定のメタデータストリーム１の中のすべてのメタデータ記述子２に対して有効である。

図２は、一般的なメタデータ記述子２を示す。メタデータ記述子の実際の内容は、コア７に含まれる。さらに、メタデータ記述子２は、名前空間宣言４と、一意の識別子５と、他のメタデータ記述子へのリンク６とを含む。一意の識別子５により、メタデータ記述子２の曖昧性のない識別が可能になる。この例では、名前空間宣言４は、対応する統一資源識別子（ＵＲＩ）「http://www.thomson.net/MetaDataStream/CoreMD」、すなわち、メタデータワードが定義される位置を指す識別子を有する接頭部「ｔｈ」を宣言する。名前空間宣言４は、特定のメタデータ記述子２に対してのみ有効である。名前空間宣言４は、ただ１つの宣言に限定されない。一意の接頭部を有する複数の宣言を定義することも可能である。異なる接頭部は通常、異なるＵＲＩ参照にリンクされるが、いくつかの接頭部を同じＵＲＩにリンクすることも可能である。ＵＲＩ参照は、一文字ずつ全て同じであるとき、一般に同一とみなされる。この意味において同一でない参照であっても、機能的に等価であることができる。コア７に含まれるすべてのメタデータワードは、接頭部の１つに印がつけられて、それぞれのＵＲＩにおいて定義されると理解すべきであることを示す。ワードに接頭部が提供されない場合、メタデータストリーム１の名前空間宣言４によって与えられる一般的な定義が適用される。

図３は、ａ）の部分では、ＸＭＬ記述子２のコア７の簡略化した例を示し、ｂ）の部分では、ＸＭＬツリーとしての対応する表現を示す。図を見るとわかるように、記述子２の例示的なコア７は、レベル０のｓｅｃｔｉｏｎＳｔａｒｔ、それぞれがタイトルを有するレベル１のセクション及びレベル２のセクションを含む。レベル２のセクションのタイトルは、値「ｄｏｗｎ」を有する属性「ａｒｒｏｗ」をもつ。記述子２のコア７は、合計１７ワードから構成され、各タイトルのテキストは、ワードの実際の数とは無関係にただ１つのワードとして数えられる。例えば、「５５５５Ｈｅｌｌｏ６６６６」は、３つの「実際の」ワードを含むが、１つの「論理」ワードである。図のａ）の部分において記述子２のコア７の各行に付与される番号は、コア７の中の各行の第１ワードの相対的なワード位置である。図のＢの部分における対応するツリー構造から、コア７は５つのレベル、すなわちレベル０〜レベル４をもつことがわかる。ツリー構造は、記述子２のコア７の異なるワードの間の階層関係を示す有益なツールである。

ワード「ｓｅｃｔｉｏｎＳｔａｒｔ」は、さらなる名前空間宣言を含み、この宣言は、対応するＵＲＩ「http://mw-homepage/mw-namespaces」を有する接頭部「ｍｗ」を宣言する。接頭部「ｔｈ」とともに、接頭部「ｍｗ」は、異なるワード（ｓｅｃｔｉｏｎ、ｔｉｔｌｅ、ａｒｒｏｗ、．．．）を、その定義の発生元に従って区別するために使われる。言い換えると、接頭部「ｔｈ」は、後続のワードが「http://www.thomson.net/MetaDataStream/CoreMD」で定義されると理解すべきであることを示し、接頭部「ｍｗ」は、後続のワードが「http://mw-homepage/mw-namespaces」で定義されると理解すべきであることを示す。

図４に、係属中の欧州特許出願番号０２０１７０４５．２で開示された、リレーショナルデータベースに階層データ形式をマッピングするデータベースモデルを示す。このデータベースモデルは、対応するテーブルによって表される、１つの主関係８及び５つの副関係９を使用する。主関係８は、メタデータ記述子２に関する構造的情報を含み、副関係９には、異なるタイプのメタデータワードの値が格納される。こうすることにより、関係８及び９の中での繰返しを避けることができる。この例では、ＸＭＬワードは、タイプ「Ｅｌｅｍｅｎｔ」、「Ｓｔｒｉｎｇ」、「Ａｔｔｒｉｂｕｔｅ」、「Ｐｒｅｆｉｘ」、及び「Ｎａｍｅｓｐａｃｅ」に分けられる。当然ながら、他のタイプ、例えば「Ｉｎｔｅｇｅｒ」なども使うことができる。

主関係８の第１列「Ｄｅｓｃｒ＃」は、データベース管理システムの中での一義的な記述子番号を示す。第２列「ＷｏｒｄＰｏｓ．」は、特定の記述子２に格納されているワードの相対的な位置を含む。「Ｄｅｓｃｒ＃」及び「ＷｏｒｄＰｏｓ．」はまとめて関係８の主キーとされ、記述子２の完全な回復を可能にする。ＸＭＬワードのタイプは、関係８において列「Ｔｙｐｅ」に包含的に格納される。各ＸＭＬワードごとに、値「Ｔｙｐｅ」の他にも対応する記述子キー「Ｄｅｓｃｒ．Ｋｅｙ」が主関係８に含められる。記述子キーは、特定のタイプのＸＭＬワードに対する、副関係９における関連するエントリを示す。列「Ｔｙｐｅ」及び「Ｄｅｓｃｒ．Ｋｅｙ」は、主キーによって指定された各ＸＭＬワードを特定の値とリンクするので、まとめて副キーとされる。

主関係８の列「Ｌｅｖｅｌ」は、図３Ｂに示した、各ＸＭＬワードの階層レベルを含む。見るとわかるように、記述子２のすべてのワードが主関係に格納されるわけではない。「</title>」及び「</section>」のような「終了」ワードは、付加情報を含まず、記述子２の回復には必ずしも必要ない。従って、こうしたワードは、データベースに格納されない。当然ながら、必要であればこうしたワードを格納することも可能である。さらなる列「ＮｅｘｔＵｐｐｅｒＷｏｒｄＰｏｓ．」が主関係８に含められ、特定の記述子２の中のＸＭＬワードの１つ上の階層のワードに対する指示子を含む。これは、共通形式の一部分のワード位置だけが、例えば照会の結果としてわかっているとき、記述子部分を回復するのに有用な情報である。記述子部分の高速な復元が、この付加情報を提供することによって容易になる。記述子２のすべてのワードに対して、関連づけられる名前空間が追加の列「Ｎａｍｅｓｐａｃｅ」に含められる。これは、メタデータワードの正しい定義を保証するのに必要である。当然ながら、名前空間宣言自体に対しては、関連する名前空間は主関係８に含められない。名前空間は、主関係８の末尾（ワード位置１４及び１５）に格納される。この例におけるデータベースは、ＸＭＬ文書がデータベースに入れられるとき、すべての名前空間が最初に別々に集められるように実現される。文書全体が名前空間なしで入れられた場合、文書用に実際に使われる名前空間のみが、関係８の末尾に格納される。文書の復元に際しては、この方法が逆になる。最初に、名前空間が読み出され、その後でのみ、ＸＭＬ文書が復元される。復元されたＸＭＬ文書は、最初のＸＭＬ文書と全く同一でなくてよいが、ＸＭＬ文書の先頭に列挙される、実際に使われる名前空間のみを含む。こうすることにより、明瞭性が増し、一貫性が向上する。

図５に、リレーショナルデータベースに階層データ形式をマッピングする際にデータの一貫性を保証する、本発明による方法を示す。ステップ１０で、接頭部及び統一資源識別子からなる名前空間が、データベースに伝送される。接頭部及びＵＲＩを格納する前に、ステップ１１で、接頭部及びＵＲＩの現在の組合せがデータベースに格納済みであるか検査する。格納済みである場合、ステップ１２で、格納済みの名前空間、すなわち接頭部及びＵＲＩが、データ項目用に使われる。ただし、ステップ１１で、現在の組合せがデータベースに格納済みでないことがわかった場合、ステップ１３で、ＵＲＩが、異なる接頭部とともにデータベースに格納済みであるか検査する。格納済みである場合、ステップ１４で、現在の接頭部は、格納済みの接頭部に変更される。その後、ステップ１７で、データ項目と名前空間、すなわち接頭部及びＵＲＩが、データベースに格納される。ステップ１３で、ＵＲＩが、異なる接頭部とともにデータベースに格納されていないことがわかった場合、ステップ１５で、接頭部が、異なるＵＲＩとともにデータベースに格納されているか検査する。格納されていない場合、ステップ１７で、接頭部及びＵＲＩの現在の組合せは、データ項目に加えてデータベースに格納される。ただし、ステップ１５で、現在の接頭部が、異なるＵＲＩとの組合せでデータベースに格納されていることがわかった場合、ステップ１６で、現在の接頭部は、一義的な接頭部に変更される。この場合も、ステップ１７で、データ項目と接頭部及びＵＲＩの組合せが、データベースに格納される。

以下の３つの例は、本発明による方法をさらに説明する。
１．）第１のＸＭＬ文書がデータベースに送り込まれると仮定する。
<Section xmlns:mw-"http://www.mw-homepage/mws-namespaces">
<mw:author>Winter et al.</mw:author>
</Section>
その後で、さらにＸＭＬ文書がデータベースに送り込まれる。
<Chapter xmlns:mw="http://www.mw-homepage/mws-namespaces">
<mw:title>Namespaces</mw:title>
</Chapter>
この名前空間はデータベースに格納済みなので、新しい名前空間はデータベースに送り込まれない。そうではなく、格納済みの名前空間が再度使われる。

２．）再度、第１のＸＭＬ文書がデータベースに送り込まれる。
<Section xmlns:mw="http://www.mw-homepage/mws-namespaces">
<mw:author>Winter et al.</mw:author>
</Section>
その後、以下のＸＭＬ文書がデータベースに送り込まれる。
<Chapter xmlns:mmww="http://www.mw-homepage/mws-namespaces">
<mmww:title>Namespaces</mmww:title>
</Chapter>
この場合、同じＵＲＩが異なる接頭部と組み合わせられる。データベースの中でのデータの一貫性を保証するため、すなわち各ＵＲＩを単一の接頭部と組み合わせるために、データ項目がデータベースに格納される前に、現在の接頭部は、格納済みの接頭部に変更される。
<Chapter xmlns:mw="http://www.mw-homepage/mws-namespaces">
<mw:title>namespaces</mw:title>
</Chapter>

３．）この例でも、第１のＸＭＬ文書がデータベースに送り込まれる。
<Section xmlns:mw="http://www.mw-homepage/mws-namespaces">
<mw:author>Winter et al.</mw:author>
</Section>
その後、以下のＸＭＬ文書がデータベースに送り込まれる。
<Chapter xmlns:mw="http://www.another-mw-homepage/XML/ns">
<mw:title>Namespaces</mw:title>
</Chapter>
この場合、同じ接頭部が、異なる２つのＵＲＩ参照と組み合わされて使われる。データベースの中でのデータの一貫性を保証するために、データ項目がデータベースに格納される前に、現在の接頭部は、新しい一義的な接頭部に変更される。
<Chapter xmlns:mw2="http://www.another-mw-homepage/XML/ns">
<mw2:title>Namespaces</mw2:title>
</Chapter>

複数のメタデータ記述子を含むメタデータストリームを示す図である。名前空間情報、一意の識別子及び他のメタデータ記述子へのリンクを含む一般的なメタデータ記述子を示す図である。名前空間情報の表現を含む簡略化したＸＭＬ記述子を示す図である。ＸＭＬツリーの表現を含む簡略化したＸＭＬ記述子を示す図である。要素、属性、整数値、文字列の値、接頭部、及び名前空間が異なる関係に分離されるリレーショナルデータベースに階層データ形式をマッピングするデータベースモデルを示す図である。リレーショナルデータベースに階層データ形式をマッピングする際にデータの一貫性を保証する、本発明による方法を示す図である。

符号の説明

１メタデータストリーム
２メタデータ記述子、ＸＭＬ記述子
４名前空間宣言
５識別子
６リンク
７コア
８主関係
９副関係

Claims

データベースにデータ項目を格納する際のデータの一貫性を保証する方法であって、該データ項目は、当該データ項目を宛先にリンクする識別子を有し、前記識別子と前記宛先を指すロケータとが、前記データ項目と共に前記データベースに格納される方法において、
識別子及びロケータの現在の組合せが前記データベースに格納済みであるかを検査し（１１）、格納済みの場合、前記データ項目に対して、格納済みの組合せを用いる（１２）ステップと、
識別子及びロケータの現在の組合せが前記データベースに格納済みでない場合、前記識別子又は前記ロケータのどちらかが前記データベースに格納済みであるか検査し（１３、１５）、格納済みの場合、前記識別子及びロケータの現在の組合せを一義的な組合せで置き換え（１４、１６）、前記一義的な組合せを前記データ項目とともに格納する（１７）ステップと、
上記ステップにおいて、前記識別子も前記ロケータも前記データベースに格納済みでない場合、識別子及びロケータの現在の組合せをデータ項目とともに格納する（１７）ステップとを含むことを特徴とする方法。
前記置き換えるステップ（１４、１６）が、
異なるロケータとの組合せで前記識別子が格納されている場合、前記識別子を、前記データベースに格納されていない一義的な識別子で置き換える（１６）ステップと、
異なる識別子との組合せで前記ロケータが格納されている場合、前記識別子を、格納されている識別子で置き換える（１４）ステップと
を含むことを特徴とする請求項１に記載の方法。
前記データ項目が階層データ形式のワードであることを特徴とする請求項１又は２に記載の方法。
前記階層データ形式が拡張マークアップ言語であることを特徴とする請求項３に記載の方法。
識別子及びロケータの組合せが名前空間宣言であることを特徴とする請求項１から４のいずれか一項に記載の方法。
前記ロケータが統一資源識別子であることを特徴とする請求項１から５のいずれか１項に記載の方法。
前記識別子が接頭部であることを特徴とする請求項１から６のいずれか１項に記載の方法。
前記データベースがリレーショナルデータベースであることを特徴とする請求項１から７のいずれか１項に記載の方法。
データ項目をデータベースに格納する際にデータの一貫性を保証するために、請求項１から８のいずれか１項に記載の方法を用いることを特徴とする記録媒体から読み出し及び／又は該媒体へ書き込む装置。