エンジニアの視点から活用するXMLデータベース 「第2回：リレーショナルデータベースとXMLデータベースの設計の違い」

XMLデータベースに着目

筆者がXMLデータベースをはじめて使ったのは2000年頃です。その頃のXMLデータベースの用途は電子カタログでしたが、当時はリレーショナルデータベース（以下、RDB）に格納する方がメジャーでした。

著者がXMLに着目したのは、データベース構造に自由度を採用しているからでした。様々なものを電子カタログ化すると、属性が品物によりバラバラになり、このような状態でRDBを使うと表1のどちらかになります。

▲表1:電子カタログにRDBを用いる際の問題点

表1の結果として表2の問題が起こり、最適解が見つからずに何を選択しても問題が残る結果となりました。

▲表2:電子カタログにRDBを用いたことにより起こった問題点

これらの問題を一気に解決するために登場したのがXMLデータベースです。XMLデータベースを選択する理由として、様々な品物の個々に必要な属性をタグ付きで持たせればよいことがあげられます。

検索には、必要な属性をタグで定義すれば検索対象として宣言したことになり、検索精度が高められました。また、属性を抽出するロジックもXMLの構造との連携で複雑にならないということも決定の理由でした。

RDBの特性：正規化

DBMSの主流であるRDBは表の集合で構成され、「アプリケーションとデータの分離の原則」で設計しますが、アプリケーションの独立性を持たせるために「データの正規化」技術を使います。

▲図1：正規化

以降では正規化について順に解説します。

第1正規化

表の中での繰り返している項目を独立した他の表とし、表内の属性の繰り返し数の可変要素を排除します。そして独立させた繰り返しの表と元の表に関連を張ります。これが第1正規化です。例えば売上明細一覧表の中に、商品コードと商品名の繰り返しが1行の中にあれば、売上商品として切り出します。

第2正規化

その次に、表の中の属性で従属関係のものを独立した表にし、同じ属性値を排除して関連を張ります。これにより値の冗長性を排除できます。例えば、売上明細一覧表の中に取扱担当者コードと氏名があったら、取り扱者として切り出すことがあげられます。

第3正規化

さらに、キー属性と属性の間で従属関係のあるものを独立した表にし、関連をつけて表の中の従属関係を表同士の従属関係にし、値の冗長性を排除します。これを第3正規化といいます。

例えば、第1正規化の例で切り出された売上商品表があるとすると、その中の商品は売上単位（売上番号）にくくられています（商品コードで区別するかたまり）。商品の商品名は商品コードに従属していますので、商品として独立させます。さらに第4、5正規化...と正規化は続きますが、通常は第3正規化まで行います。

RDBで第3正規化までを行う理由は定義と値の冗長性の排除です。その結果、様々な業務処理で表を操作することより、業務が必要とするデータが1箇所から効率よく取得でき、また効率よく更新できます。

XMLデータベースと正規化

XMLデータベースはRDBのような構造を作るべきでしょうか。筆者の考えは「NO」です。この方式はRDBの機能をXMLで実現しただけであり、XMLデータベースの特徴をいかしていません。

データベースの構造を設計していくと、RDBの特性である一覧表で扱うと都合がよいものもあれば、都合が悪いものもあります。

XMLデータベースを使えばどちらでも対応ができますが、後者への対応でXMLデータベースの特性をいかせば、今までにないデータベースアーキテクチャとなります。数年前に参加した米国のカンファレンスでER図とXMLの対比をテーマに研究発表していました。

メタ（定義）データをXMLで記述することが当然の流れになることに関しては同意しますが、業務で扱うデータベース構造をすべて、リレーショナル型にすることはありません。そのようにするとXMLデータベース適用のメリットは少ないでしょう。

つまり、XMLデータベースはRDBにない能力を発揮します。その能力が必要とする領域での適用を原則とすべきでしょう。

XMLデータベースの適用領域

XMLデータベースを使う技術的理由には階層構造の表現があります。階層構造への対応はRDBの苦手な領域です。

RDBは全体最適の構造にするために、前述した正規化という共通の方法をもとに、共通の法則を抽出しモデル化します。共通な繰返しの法則、共通な従属関係の法則、共通な項目...、などと共通な法則が集約できればできるほど、RDBはその効果を発揮します。構造上からも、作成するテーブル数が少なくなります。逆に、共通性が少なく、法則の種類が増えればテーブル数は増えてきます。

一般的に、データベース設計において重複項目をなくすこととテーブル数を少なくすることは相反します。

RDBは両者が相反しない領域（基幹業務のような標準化の徹底が行える領域）に対して最も威力を発揮します。DBMSの適合性は設計技術にあう対象領域かです。それを服に例えれば、オーダーメードとセミオーダーメードとレディメードの違いのようなものです。

RDBはレディメードです。「サイズ」「色」「形」「飾り」などが決められて、その種類と組み合わせのパターンがあれば、その組み合わせを選択すればよいのです。

しかし、オーダーメードでしたらどうでしょう。袖の色をそれぞれ変えてくれとか、カバンとセットのトータルなデザインにしてくれとか...。決められない要求を受け入れられるとしたら、あらかじめ確定できません。

大昔、電話の色は黒であり、PCの色も固定されていました。その時はわざわざ色を使うという属性を作りません。しかし突然、カラーを扱うことになったとたんに色指定の対象を全商品とする構造にするか、特定商品に限ったものにするかを決める必要があります。こういった選択は悩ましいものです。

▲図2：色指定の対象の範囲

RDBの苦手な部分に柔軟に対応できるXMLデータベース

様々な場面で変化の多い現在において、全体の法則をあらかじめ決めるのは困難です。つまりRDBの特性からすると、苦手なものが沢山あるのです。

その苦手なものに対して、RDBで扱う場合は「その他属性」を設けて、「電話の色、パソコンの色」などと押し込む方法で対処します。しかしこのようにすると、利用する時に問題がでてきます。

もし色で検索したり、色を格納したりする時に例外項目の処理は様々なものが混在して入るものですから、扱いにくいものとなります。扱いやすくするためには、アプリケーションのロジックで対応しなければなりませんので、複雑になっていまします。しかし、それに対してXMLの場合はタグを追加すればよいのです。

今まで色を扱わない構造の中に色というものがでてきた時、色を扱うものがでてきたのなら、全体構造の変更するのではなく、その部分はタグを追加すればよういというものです。

この気楽さがXMLにはあります。

繰り返しますが、単一商品の電子カタログをRDBで扱う時に問題は少ないですが、様々な商品を扱い、その内容が予定外に変わるものはRDBに向きません。

XMLデータベースに着目すべき理由がここにあります。

これから、XMLデータベースの構築技術を詳細から全体へ、属性の定義から構造の設計へ、そしてシステム全体の話へとボトムアップ的に解説をしていきます（特にXMLデータベースが得意なものを中心に選んでいます）。

要素および属性の決める

まずはデータ項目からはじめます。ある商品の商品IDがa100で金額が1000円とします。筆者がこれをXMLで記述すると次のようになります。

<商品 商品ID="a100">
	<商品名 言語="日本語">○○○○○</商品名>
	<値段 単位="円">1000< /値段>
	...
</商品>

また、以下の表現でも可能です。

<商品>
	<商品ID>a100" </商品ID>
	<言語>日本語</言語>
	<商品名>○○○○○</商品名>
	<値段>1000</値段>
	<単位>円<値段>
	...
</商品>

どちらの記述が好ましいかといいますと、前者ではないでしょうか。それは、「金額と単位」「名称と言語」は対で扱うものであるからです。XMLでは、これをアトリビュート表現と（タグの中で書く形式）とエレメント表現（タグの間に書く形式）の組み合わせで素直に表現できます。

それに対してRDBの表形式ではどうでしょうか。RDBは2次元の表現ですので、表1のようになります（金額と単位、言語と商品名を吐き出すことも考えられますが、そこまで徹底した正規化はテーブル数が膨大になり、また操作が面倒になるので、普通は行いません）。

▼表1：RDBでの表形式

基本形のRDBはテーブル配下のフィールド（カラム）に階層構造を持ち込みません。従って、「商品名と言語」「値段とその単位」の関係は作れないので、その関係はアプリケーション側で意識しなければなりません。

まとめ

XMLのほうがRDBより属性の定義をより細やかに行えます。多国籍言語の扱いやそれにともなう通貨の扱いなどの処理はXMLが得意とする領域です。少なくとも、アプリケーションとのインターフェースにそのデータをデータベースの構造として扱えますので、XMLデータベース設計を行う場合はその特長をいかす設計を薦めます。

RDBを使っている場合でも、そのインターフェースをXML対応で行うことで対応が可能ですが、そのための新たな定義は必要です。

• 1
• 2
• 3
• 4