key, keyref, unique: その1

2002年12月15日(日)更新


■IDによる管理の欠点

たけち: 前回はID型、そしてIDREF型とIDREFS型について学んだけれど、これらを使ったIDの管理には、気軽に簡単に使えるという利点があった反面、いろいろな欠点があったよね。どんな欠点があったか覚えているかい?

さらら: え、えっと(^^;

たけち: 復習として次に載せておこうね。それから、欠点を解消しようと思ったら、どんなことができないといけないかも載せておこうね。

さらら: えぇ。 (^ ^*

表35-1 IDによる管理の欠点と解消
No. IDによる管理の欠点 欠点を解消する

1

IDとなるもの、そしてIDを参照するものは属性でなければならない。要素の内容をIDにしたり、要素の内容でIDを参照するような場合の検証は不可能である。

IDとなるもの、そしてIDを参照するものは要素でも属性でもかまわない。

2

複数の要素型の中の属性をIDとして設定した場合、それぞれを別々に独立した一意性を持った対象としての検証は不可能であり、XMLデータ全体が一意性の検証対象となる。

複数の要素や属性を、 別々に独立した一意性を持った対象としてIDを設定することができる。

3

一つの要素型においては、IDとして取り扱うことができるのは一つの属性のみである。一つの要素型の中で、複数の属性をIDとして取り扱うことはできない。複数の要素や属性の値の組み合わせを、IDとして取り扱うように検証することは不可能である。

複数の要素や属性の値の組み合わせをIDとして取り扱うことができる。

4

IDの有効範囲はそのXMLデータ全体であると最初から決められている。そのため、一部の特定の範囲をIDの有効範囲として指定することは不可能である。

IDの有効範囲を任意に指定することができる。

5

ID型は、データ型の形式としてはNCName型となっている。そのためNCName型以外の値をIDとして使うことはできない。例えばNCName型は最初の一文字に数字が使えないため、「123456」といった数字だけのIDは使えない。(「A123456」といった値なら大丈夫)

データ型の種類に関係なく、IDとして使うことができる。


■複数の要素や属性の値の組み合わせをIDとして取り扱う

さらら: そうね。こういうことができないと困る場合って、やっぱりありそうね。

たけち: というわけで、ID型、そしてIDREF型とIDREFS型に代わる、IDを管理する本格的な仕組みが必要とされたわけだね。まず、No.3についてみてみようね。

3.複数の要素や属性の値の組み合わせをIDとして取り扱うことができる。

たけち: ということは、「複数の要素や属性の値の組み合わせをIDとして取り扱う」データのまとまり、というものがあるということだよね。

さらら: そうね。

たけち: 前回、次のような例を見たね。

たけち

※ID型、IDREF型、IDREFS型によるIDの管理方法の欠点-(3)

3-1.一つの要素型においては、IDとして取り扱うことができるのは一つの属性のみである。一つの要素型の中で、複数の属性をIDとして取り扱うことはできない。
3-2.複数の要素や属性の値の組み合わせを、IDとして取り扱うように検証することは不可能である。
↓歌集(anthology)と歌番号(pno)との組み合わせでIDにはできない

<?xml version="1.0" encoding="Shift_JIS" ?>
<poems>
<poem pno="0028" anthology="万葉集">春過ぎて夏来たるらし白妙の衣干したり天の香具山</poem>
<poem pno="0146" anthology="万葉集">後見むと君が結べる磐代の小松がうれをまたも見むかも</poem>
<poem pno="0408" anthology="万葉集">なでしこがその花にもが朝な朝な手に取り持ちて恋ひぬ日なけむ</poem>
<poem pno="0028" anthology="古今和歌集">ももちどりさへづる春は物ごとにあらたまれども我ぞふり行く</poem>
<poem pno="0146" anthology="古今和歌集">郭公なくこゑきけばわかれにしふるさとさへぞこひしかりける</poem>
<poem pno="0408" anthology="古今和歌集">都いでて今日みかの原いづみ河かは風さむし衣かせ山</poem>
</poems>

たけち: この場合、pno属性とanthology属性が実際にIDとなる部分だよね。だけど「複数の要素や属性の値の組み合わせをIDとして取り扱う」データのまとまり、というのはこの場合 、poem要素になるんだね。

さらら: ふ〜ん。

たけち: つまり、ここで大事なのは、

    ※実際にIDとなる部分(要素または属性)

 と

    ※そのIDを含んで独立しているデータのまとまり(要素)

 というのは別物である場合があるということなんだ。そう考えないと辻褄が合わなくなってくるよね。

さらら: そうねぇ〜。

たけち


■フィールドとセレクタ

たけち: この「実際にIDとなる部分」と「そのIDを含んで独立しているデータのまとまり」の組み合わせで、一意性が保たれるようにならないといけないわけだね。
この「実際にIDとなる部分」を"フィールド(field)"と呼び、「そのIDを含んで独立しているデータのまとまり」を"セレクタ(selector)"と呼ぶんだよ。

さらら: う〜ん、何か言われてもぴんと来ないけれど…(^ ^;)

たけち: そうだね。例えばさっきの例だと、pnoとanthologyがフィールド(field)になって、そしてそれぞれの各行、つまりpoem要素がセレクタ(selector)になるなんだね。図にしておくね。

さらら

フィールドとセレクタ(1) poemデータの例

さらら: はぁ........

たけち: う〜ん。じゃあ、もう一つ今までの例を見てみようか。

※XMLデータ例: 歌人(person)

<person id="p01">
<name>持統天皇</name>
<sex>female</sex>
<birth>0645</birth>
<death>0702</death>
</person>

<person id="p02">
<name>高市皇子</name>
<sex>male</sex>
<birth>0654</birth>
<death>0696</death>
</person>

<person id="p03">
<name>大伴家持</name>
<sex>male</sex>
<birth>0718</birth>
<death>0785</death>
</person>

<person id="p04">
<name>坂上郎女</name>
<sex>female</sex>
<birth>0700</birth>
<death>0750</death>
</person>

<person id="p05">
<name>柿本人麻呂</name>
<sex>male</sex>
<birth>0645</birth>
<death>0701</death>
</person>

たけち:  この場合は、次の図のようにidがフィールド(field)になって、そしてそれぞれの各行、つまりperson要素がセレクタ(selector)になるんだね。

フィールドとセレクタ(2) personデータの例

さらら: そんなものなのね。

たけち: この考え方は大事だからよく覚えてね(^^;)


■その他の改善要望

たけち: さて、その次に、、No.1とNo.5についてみてみようね。

1.IDとなるもの、そしてIDを参照するものは要素でも属性でもかまわない。

5.データ型の種類に関係なく、IDとして使うことができる。

たけち: の2つの要望からIDとしたい要素または属性(field)は、データ型に関係なく、IDになるように指定できないといけないということが言えるよね。

さらら: そうね。

たけち

たけち: そして、No.2だけど、

2.複数の要素や属性をIDに設定することができる。

たけち: ということは、最初の『実際にIDとなる部分そのIDを含んで独立しているデータのまとまりの組み合わせ』が複数ある場合があるということなんだよ。で、複数あるということは、それぞれに名前をつけないと、参照したい場合にわけがわからなくなるよね。

さらら: そうなのね。(何かよくわからないけど...(^ ^;) )

たけち: そして、No.4だけど、

4.IDの有効範囲を任意に指定することができる。

たけち: ということは、「どの要素の中が有効範囲なのかが決められなければいけない」ということなんだ。

さらら: 。。。。。。(有効範囲? (._.?) )(

たけち: というわけで、今まで言ったことをまとめてみるね。

1.「実際にIDとなる部分 ="フィールド"」と「そのIDを含んで独立しているデータのまとまり ="セレクタ"」の組み合わせで、一意性が保たれるようにならないといけない。

2. IDとしたい要素または属性は、データ型に関係なく、IDになるように指定できないといけない。

3. 1の組み合わせを複数作ることができて、それぞれに名前をつけられなければならない。

4. どの要素の中が有効範囲なのかが決められなければいけない。


■keyとkeyref

さらら: ふ〜ん。これだけのことができなくちゃいけないのね。で、XML Schemaではどんな風になるの?

たけち: そうだね。そこでこの条件を満たすべく作られたのが、keyとkeyrefという仕組みなんだよ。keyやkeyrefは、次のような特徴があるんだ。

さらら

表35-2 keyとkeyref
No. keyやkeyrefの特徴

1

「実際にIDとなる部分(要素または属性) ="フィールド"」と、「そのIDを含んで独立しているデータのまとまり(要素) ="セレクタ"」の組み合わせからできている。

2

「実際にIDとなる部分(要素または属性) ="フィールド"」と、「そのIDを含んで独立しているデータのまとまり(要素) ="セレクタ"」は、データ型とは無関係に、XPathを使って指定する。

3

1の組み合わせを複数作ることができて、それぞれに名前をつける。

4

上記の定義を、要素宣言の中で行う。この要素がkeyやkeyrefの有効範囲となる。

さらら: う〜ん。これだけ見てもよくわかない。(^ ^;)

たけち: そうだね。じゃ、今回はここまでにして、次回はそれぞれについて具体的にみていこうね。

さらら: は〜い。

次回は、key, keyref, unique: その2です...... (^ ^)v


XMLスキーマのコーナーは、TAKABEさま(XSLTの遊び部屋)の全面的なご協力をいただいて作成しています。