DB設計の難しさ

今日は徒然なるままにDB設計について思っていることを並べてみようと思う。

ようやくWEB+DB Pressの次号の原稿を書き終えた。2年間の連載であるが、来年はプライベートが忙しくなる予定なので、連載はこれにて終了とさせてもらうつもりである。

「なぜ人はリレーショナルデータベースを使いこなせないのか」

このところ執筆や講演を通じてリレーショナルモデルについて説明する機会を色々頂いているが、それらの活動の根源となっているのが、この素朴な疑問である。その疑問をパワーにしてこれまで活動を行なってきた。

現時点での自分の回答は「データベース設計が難しいから」である。もちろんリレーショナルモデルそのものの難しさというのもあるが、それよりは「適切な使い分けができていない」ということが大きいように思う。言葉を変えると、リレーショナルモデルを適用すべきデータとそうでないデータの判断ができていないからDB設計がおかしなことになるのだと。

最近、Haskell ポインタープログラミングというエントリを読んだ。このエントリでも記されているように、関数型言語を使って副作用のない純粋なコードだけで完結させることはできない。HaskellにIOが必要なのと同じで、リレーショナルデータベースでも純粋なリレーショナルモデルだけですべてを完結させることはできない。山本氏の表現を借りると、象牙の塔だけでは世界は完結しないのである。

どんなモデルでも世界を完全にそれだけで表現することはできないので、モデルから漏れた部分をどうモデルと整合性を持たせつつうまく扱うかが問題となる。HaskellのIOというモデルは世界の境界を表す方法として、とてもエレガントのように思う。だが、リレーショナルデータベースでそのような境界をしっかりと意識するべきだとか、境界の中と外で異なったアプローチでDB設計やロジックを実践するべきだという話は聞いたことがない。

それどころか、なぜかRDBでは、「リレーショナルモデルなんて意味ないっしょ」とか「正規化のやり過ぎは現実的じゃないぜヒャッハー」とか「ナチュラルキーは消毒だー！！」みたいな意見しか聞こえてこない。確かにリレーショナルモデルは難しい。たぶんみんなが思ってるより難しい。比較的手軽に使い始められる割にはとても難しい。だけど、難しいからといってそれを実践しないのは違う。境界を見極める以前にデータモデルそのものを実践することが極めて重要であることは言うまでもない。

リレーショナルモデルの難しさは、データをモデリングする難しさそのものだから、リレーショナルモデルから逃れたところでそれは変わらない。スキーマレスな設計であっても、データをどう表現するべきかという問題はついて回る。抽象的な概念をデータとして表現するという点は、どのようなデータベースであっても変わらない。リレーショナルデータベースだけが難しいわけではない。リレーショナルモデルから逃れようとするよりも、むしろ「データとは何か、そのデータは何を意味するのか、なぜそれが必要なのか」という本質に近づくことが正解じゃないかと思う。

純粋なリレーショナルモデルが適用できる範囲はたぶん多くの人が思ってるより狭い。リレーショナルモデルには、厳密に言えば「集合」として表現できるデータしか適用できない。そうでないデータを格納し、クエリを書くことができるようになっているのは、単にSQLがそれ以外のデータでも対応できてしまうからに過ぎない。SQLがリレーショナルモデルの垣根を超えられるおかげで応用範囲は広がったが、そのせいで本当に多くの人がリレーショナルモデルの本質を見失っているように思う。

ただし、集合として表現できる（あるいは表現すべき）範疇のデータならリレーショナルモデルは鉄壁だ。しっかりとリレーショナルモデルに則ってモデリングすることでリレーショナルデータベースはその真価を発揮する。データの整合性を保つことも容易だし、クエリだってとてもシンプルに書ける。しかし残念ながら、世の中の多くの人は「SQLでできることは何か」という思考に陥ってしまっているため、「リレーショナルモデルを実践するためにSQLをどう使うか」という発想に欠けているように思う。その結果、リレーショナルモデルの境界線が曖昧になり、データベース設計が破綻する。

かと言って、リレーショナルモデルでできることだけしか考えないのは現実的ではない。リレーショナルモデルの適用範囲は狭いので、それ以外のデータ構造についてどう扱うかというのが、実は一番難しい課題だったりする。なんせリレーショナルモデルではないのだから、リレーショナルデータベースでそれらを扱うのは次善の策に過ぎず、どうモデリングすべきかということについて正解がない。それだけでなく、リレーショナルモデルとはまったく違ったセオリーが必要になる。設計の可能性は無限大である。

リレーショナルモデルの境界がわからないと、本来リレーショナルモデルで表現すべきデータまでもが無限大の可能性の中に埋もれてしまうことになり、DB設計はカオスなものになってしまうだろう。せっかく鉄板のDB設計理論があるにも関わらず、それらを活用することができないのは勿体無い。DB設計理論とは、言うまでもなく正規化と直交性である。見方を変えると、よく「正規化が上手く行かない」と言われるのは、リレーショナルモデルの境界を区別できていないからである。当然ながら、リレーショナルモデルで表現すべきでないデータをテーブルで表現しても、正規化はできないからだ。

そんなわけで、本当はリレーショナルデータベース上でのデータのモデリングはとてもとても難しいのである。

ちなみに、個人的にはリレーショナルデータベースに固執することは全くないと思っている。仕事柄MySQLが普及することは応援したいのだが、リレーショナルモデルに適合しないデータであれば、別にリレーショナルモデルに拘る必要は全くない。むしろ他にデータモデルにピッタリなデータベースがあればそちらを進んで使うべきだろう。境界線がはっきりしていて、リレーショナルとそれ以外のデータモデルの双方が必要なら、リレーショナルデータベースと他のデータベースを連携すれば良いと思う。DB設計がぐじゃぐじゃになって、リレーショナルデータベースの使い方が破綻するよりは、他の種類のデータベースと連携したほうが双方幸せになれるのではなかろうか。ただ、リレーショナルデータベースと連携するならトランザクションは欲しいところである。

ひとつだけ注意して欲しいのは、リレーショナルモデルに限界があるのと同じで、他のデータモデルでリレーショナルモデルを置き換えることはできないということだ。未だに「スキーマレスなDB設計ならリレーショナルモデルより楽になる」というような意見を見かけるのだが、それは根本的に間違っている。リレーショナルモデルが得意とする領域は、他のデータモデルにとっては境界の外側なのだから。

データベースの使い分けというのがより一般的になったとき、果たしてSQLはまだ残っているだろうかということをよく考える。もしかすると、SQLよりももっと純粋にリレーショナルモデルを実践できる言語（Tutorial Dのような）が台頭しているかも知れない。とはいえ、リレーショナルデータベースに必要なのはリレーショナルモデルだけでないというのが実はなかなか厄介な課題だと思う。特にトランザクションもなくてはならない機能だ。SQLは上手く折り合いをつけてその双方を扱える言語であり、やはりまだまだ寿命が続くかも知れない。

オチはないが今日のところは以上である。本エントリは今年最後のエントリである。最後にひとこと読者の皆さんにはお礼を申し上げたい。

今年は本ブログをご愛顧いただきありがとうございました。来年もよろしくお願いいたします。