mb_language("uni"); mb_internal_encoding("utf-8"); mb_http_input("auto"); mb_http_output("utf-8"); ?>
前回はリレーショナルデータベース(RDB)とXMLデータベース(XML DB)の設計の違いについて説明し、XML DBはRDBの苦手な部分に柔軟に対応できるということをお伝えしました。今回はRDBとXML DBの階層構造の違いについて説明します。
RDBとXML DBの階層構造を比較する前に、RDBでも階層構造を表現できることを説明します。RDBで階層を表現方法する方法の1つとして、エンティティとその間の親子関係で表現する方法があります。
▲図1:階層構造の設計
RDBで階層構造を表現する場合、図1のように「第1階層テーブル→第2階層テーブル→第3階層テーブル」と作っていけば、個々の階層のテーブルができます。これを組織の階層としてあらわすと、「最上位の組織のテーブル→中間の組織のテーブル→最下位の組織のテーブル」となります。そして、個々のテーブルの中に自分のキーと親のキーを持たせて、主従(親子)を定義します。
階層構造をRDBで作るのに対して、XML DBで作る場合は、組織の階層を素直に組み立てていくことで表現できます。
▲図2:組織の階層の組み立て
ここでRDBで行う組織の階層を組み立てる方法とXML DBで扱う方法を比較すると、表1のことがいえます。
▼表1:RDBで行う組織の階層を組み立てる方法とXML DBで扱う方法との比較
同一階層での処理 |
---|
データ構造がテーブル1つに固まっていれば、RDBの方がXML DBよりも効率よい処理が可能です。 |
階層の深さ |
RDB・XML DBともに素直な階層表現の方が階層の深さに制限がありません。 |
階層のバラつき |
バラつきに法則があり、不変か・変化するかということがデータベースを構築する上でのポイントになります。RDBで扱う場合、バラつきが法則化されていて不変ならテーブルを作ることは有益です。しかし、法則がなければテーブルの数はどんどん増えてきますので、XML DBでデータベース構築をした方がよいでしょう。 |
また常に変更が加わる場合、どうしてもテーブルの設計変更はつきまといますので、運用の困難性が増します(変更の法則がない場合は、XMLで対応でもスキーマ定義を頻繁に変更しなくてはなりません)。
表1の方法で階層構造を組み立てる時には、拡張性・柔軟性の点でXML DBの方がRDBに比べて有利です。ですが、階層構造が固定で構造の種類が少なく、横通しの処理が多ければ、データベースの運用も含めてRDBの利点がいきます。
図2の例は階層を構成しているデータで階層構造を組み立てています。その結果、組織変更などで階層構造を変更する時にはデータも移動する必要があります。RDBでもXML DBであっても、どちらを選んでも同じ問題がでてきます。
▲図2:組織の階層の組み立て(再掲)
また、組織構造の種類は1つで済むとは限りませんので、データ(値)が複数の階層にも対応できる構造を作る場合があります。その1つの案として、階層とデータの分離を行うことがあげられます。
RDBでも部品管理や組織管理を行うとき、図3の構造で設計する場合があります。それはRDBのテーブル1つを使い再帰的に階層を表現する方法ですが、そのような構造はモデルとしてはわかりにくいものです。
▲図3:階層の柔軟性を持たせる設計
XMLを使った場合、階層構造とデータを分離し、その間はリンク情報として扱うことができます。
RDBでも柔軟な階層構造を扱えますが、パフォーマンスやモデルのわかりやすさなどから、XML DBの方が柔軟な階層構造を扱うことに向いています。データ部分の扱いはフラットな構造なので、同一種類データベースで扱っても、他の種類のデータベースで扱っても問題はありません。
また、階層部分をRDBで扱うと大変わかりにくい構造となってしまい、パフォーマンス的にも、ダイナミックに階層を抽出しますので不利です。一方、XMLではその階層部分を素直にあらわせばよいのです。
ドキュメントは階層構造、構造は通常内容に依存します。また、1つの文書の階層を均一にすることが望ましいですが、常に例外が起こります。階層を均一できれば、RDB・XML DBどちらでシステムを構築しても問題は少ないでしょう。
しかし、内容により階層構造の違いがでてくる時、RDBを利用してのデータベースシステムの構築は厄介です。一般的な文書構造を実現する場合は、XML DBが向いています。
また、コンテンツの再利用は階層構造と文章(内容)の分離を行い、コンテンツ部をフラットに管理します。
商品や組織の情報はそれ自身が構造体を持ちます。その構造全体を商品や組織などの定義をXML DBは容易に行えます。しかし、RDBでは商品や組織などの定義を行うことは困難です。
例えば、図4の企業と組織の例ではRDBは企業エンティティと組織エンティティを関連で表現します。
▲図4:エンティティ
図4のモデルで表現しているのはエンティティとしての企業と組織だけです。しかし、企業と組織のモデルでは、企業と組織を考えた広義の企業という概念があるはずです。それを踏まえて、XML DBで表現すると図5のようにできます。
▲図5:XMLでのエンティティ表現
図5は狭義の企業を企業基本とし、組織を含めた広義の企業を企業としています。
RDBはテーブルと関連して表現することができますが、それらを束ねた定義ができません。その表現はセマンティック(注1)なもので、XML DBはセマンティック表現に向いているといえるでしょう。
※注1:セマンティック:意味を解釈すること
ここまでの内容を踏まえ、いよいよ統合システムへのXML DBの適用に話を進めます。システムアーキテクチャを決めるとき、XML DBの適用に明確なコンセプトを有することが重要です。
本来ならば様々なケースを示しながらXML DBの適用についての長所・短所を解説するところですが、まずは筆者の様々な経験からたどり着いた(1つの)答えを図6として示します。
▲図6:XML DBの適用についての明確なコンセプト
皆さんに筆者がこの方式をなぜここで紹介しているかを、RDBとXML(データベース)の特徴を今まで解説してきた内容から推測していただきたい。さらに、読者がこの方式をベースにさらによい方式を生み出すために本解説がいきることを切に願っています。
▲このページのTOPへ