最終更新日：2003.05.27
webmaster@kototone.jp
こととねは、クリエイティブ・コモンズ・ライセンス（表示 - 継承 2.1 日本）の下でライセンスされています。
まことに今さらながら、ずっと思い違いをしていたことに気付いてしまった。これまでリレーショナルデータベースは書誌には向かないと言い張ってきたのであるが、そんなことはない、リレーショナルデータベースで理想的な書誌の構築は充分可能である。そのことにようやく気付くにいたったのである。
ではなぜRDBは書誌に向かないと言ったのだろう。以下にその根拠を述べよう。
書誌事項は非常に柔軟でありまた一貫性に欠ける部分が多くあるためである。例えば著者などは頻繁に複数出現する。出版者が複数記載されていることもある。非常にまれであるが、書名が複数存在することもある（もちろん副書名などということは言わない。合刻本というのがあるのだ）。
反面、それら複数出現する項目がまったく出ないこともありえる。本書名がないと言うことはさすがにないだろうが（あったら教えてください）、著者が明記されないものもある。
このように出現する項目がはかれないというのが書誌の特徴であり、そのいくつ出るか分からない、出ないかも知れない項目のためにフィールドを定義するのは効率が悪い。著者なら三人までと決めておくのか。いつ出るか分からない書名を複数持つ書籍のために書名フィールドを複数用意しておくのか、その場合はいくつまで用意するのか。
以上のような理由をもってRDBは書誌には向かないと断言し、文書型定義次第で同一要素の複数回出現を可能とし、必ず出現しなければならない、また出現してもしなくてもよいなどを自由に設計できるXMLこそが書誌に向いているのだと言っていた。
だがその考えは間違いだったと気付いたのである。
RDBというものは、複数のテーブルを関連づけて利用できるところにその意義がある。例えば書誌と所蔵という相反するデータ（書誌は複数の書籍に渡って使えるが、所蔵データは一冊ごとにユニークである）を別のテーブルに格納し、必要に応じてそれらを繋ぎあわせる。書誌を複数の所蔵データで共有するといえばいいだろうか。こうすれば、複数ある同一書籍のためにいくつも同じ書誌データを持たなくて済む。
だがここで止まっていたのだな。ここより先に進めば、RDBは書誌に向かないなどという早合点をすることはなかった。
書誌的事項を書誌テーブルに全て収めることはなかったのである。
ひとつのテーブルにではなく、書誌的事項ごとに複数テーブルを作ればよい。例えばひとつと決まっているもの（ってなにがあるのだろう？）を軸とし、それに各事項を関連づける。ひとつと決まっているものというのがなにかといえば実は思いつかない（複数出版者もあれば複数ISBNもある、それもざらに）ので、書誌IDでもふっておこう。
それらを表現してみると、以下のようになるだろうか。なお繁雑を避けるため、本タイトルと責任表示に留めておく。
主ID |
|---|
| 001 |
| 002 |
| 003 |
| 004 |
| 主ID | ID | 本タイトル |
|---|---|---|
| 001 | 1 | 父 パードレ・パドローネ |
| 002 | 1 | あゆみ |
| 003 | 1 | 化学物質過敏症 |
| 004 | 1 | フランス人が日本人によく聞く100の質問 |
| 主ID | ID | 責任表示 | 著作の種類 |
|---|---|---|---|
| 001 | 1 | ガヴィーノ・レッダ | 著 |
| 001 | 2 | 竹山博英 | 訳 |
| 002 | 1 | 須藤真澄 | 著 |
| 003 | 1 | 柳沢幸雄 | 著 |
| 003 | 2 | 石川哲 | 著 |
| 003 | 3 | 宮田幹夫 | 著 |
| 004 | 1 | 福井芳男 | 著 |
| 004 | 2 | 中井珠子 | 著 |
本タイトル及び責任表示テーブルは主IDとそれぞれに（同一の主IDを持つレコードの中で）与えられるIDを持って主キーとする。そして各テーブルが持つ主IDに基づきリレーションを作成する。
このようにしてやれば書誌に複数現れる項目を無駄なく格納することができ、必要に応じてデータを請求することも充分可能である。