Tweet

なぜ彼はLAMPを捨てXML DBに走ったのか

最新のXMLデータベース実装となるViper 2（DB2 9.5）のリリースを機に、全4回の連載記事であらためてXMLデータベースの利点を考えてみる。そこで見えてきたものとは？（編集部）

■いかにしてKさんは設計変更のワナにはまったか

　これはインターネット上でサービスを提供しているある企業で働くKさんのお話です。この会社では、CGM（ユーザー生成メディア）サイトを立ち上げることになり、Kさんが全体のアーキテクチャ設計からデータベース、プログラミングまですべてを担当することになりました。しかもベータ・サービスの開始が1カ月後と迫っています。

　Kさんは早速、アーキテクチャの選定に入りました。この部分は迷うことなくLAMPを選択しました（注1）。これまでの経験上慣れているのと、オープンソースであるためコストもかからないのでほかに選択の余地はないように思いました。

　次に、サイトの企画者と要件の打ち合わせを持ち、データベースの設計に取り掛かりました。しかし要件が柔らかく、はっきりしない部分が多くあり、データベースの設計にすぐには取り掛かれませんでした。2日後ようやく要件が固まったということで、企画者からの要件に基づきデータベースの設計に入ることができました（注2）。

　例えば、ユーザー管理のテーブルは図1のようなテーブル・スキーマになっています。

図1　ユーザー管理テーブルのスキーマ定義 （画像をクリックすると拡大します）

　このユーザー管理テーブルも含めて、20個のテーブル設計が完了したので、ようやくプログラミングに取り掛かりました。プログラミングを始めて3日目のことです。突然企画者から呼ばれて「ユーザーの属性を増やしたいので、ユーザー管理テーブルの項目を変更したい」との依頼を受けました。実は今日の企画会議で、登録ユーザーの興味のある分野をユーザー登録時に入力してもらおうと決まり、早速変更の依頼が来たのでした。しかしKさんは困りました。興味のある分野を複数登録したいということなのですが、いくつまで必要なのか、いまは決められないというのです。

　数が決まっていれば図2のように、正規形を崩して持つことが可能です。

図2　ユーザー管理テーブルの変更 新たな列「興味1」 「興味2」「興味3」を追加した。 （画像をクリックすると拡大します）

　しかしこの設計方法には落とし穴が潜んでいます。興味1〜3までと数を決めてしまったので、仮に4つまで増やしたいということになると、テーブルの設計を変更し、SQLの修正（興味1、興味2、興味3という名前をSQLに埋め込んでいるため）、プログラムの修正と非常に面倒な作業が発生してしまいます。Kさんは1時間くらい悩みましたが、スケジュールを優先させてこのままの設計で進めることにしました。

　ここで、このケースをリレーショナル・データベースの正規化に基づいて正規化すると、どうなるかを考えておきましょう。

• 関連情報：データベースエンジニアへの道（3）
  「素早く正規形を見抜く実践テクニック」

　この場合は第2正規形を適用し、テーブルを2つに分割することになり、図3のようなサイド・テーブルができます。

図3　ユーザー管理テーブルから分割されたサイド・テーブル （画像をクリックすると拡大します）

　このように“ユーザID”をキーにしてテーブルのJOINを行って利用する形になります。実はこの正規形を利用すると、プログラムの実装時に数々の面倒なことが起こります。

1.　データの検索・表示の際のSQL

　テーブルが2つあるのでJOINが必要なのはもちろんですが、結果セットを使いやすい形で取得するためにはSQLに工夫が必要になります（ここでは詳しく触れませんので、皆さんも考えてみてください。本稿の最後にDB2を使ったときの解答があります）。普通にSQLを書くと（リスト1）、図4のように“ユーザID”と“ユーザ名”が重複して結果セットに含まれてしまい、プログラムからデータを取り出すときに少々厄介です。

図4　“ユーザID”と“ユーザ名”が重複して結果セットに含まれる （画像をクリックすると拡大します）

2.　データ挿入時の課題

　次に、ユーザー登録の場面を考えてみましょう。まずは、ユーザー情報の入力画面で興味の欄をいくつ表示するかという問題に直面します。ただし、今回のケースではKさんが3つと決めてしまったので、この部分については悩む必要はありません。しかし、テーブルが2つあるので、INSERT文を2回発行しなければなりませんので、プログラムの実装がその分多くなってしまいます。

3.　パフォーマンスの問題

　テーブルをJOINするということは実はパフォーマンスにも影響が出ますし、テーブルが増えるということはデータベースの運用でもそれだけ仕事が増えてしまいます。

　以上のように、きちんと正規化のルールを守っても、SQLやプログラム、パフォーマンスにしわ寄せがきてしまい、全体としてはどうも良い解決策とはいえないようです。

　さてさて、Kさんの奮闘はまだまだ続きそうです。データベースの設計部分のユーザー管理テーブルだけを取り上げてもさまざまな問題が起こります。このケースは決して特殊ではなく、昨今のシステム構築のプロジェクトでは少なからずここでご紹介したいくつかの問題に悩んでいるのではないでしょうか。

1/2

Index
連載：Viper 2で学ぶXMLデータベース最新事情（1） 　なぜ彼はLAMPを捨てXML DBに走ったのか
	Page 1 ・いかにしてKさんは設計変更のワナにはまったか
	Page 2 ・XMLデータベースという選択肢 ・XMLデータベース（Viper 2）による実装

Viper 2で学ぶXMLデータベース最新事情

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

RSSフィード