要塞としてのデータベース

データベースには、社員が入力したデー夕、顧客から集めたデー夕、その他ありとあらゆるデータが集められています。ユーザーインターフェイス、ビジネスロジックやアプリケーションロジックには変化があり、社員にも出入りはありますが、データは永遠に残ります。ですから、初日からしっかりとしたデータモデルを構築しておくことの重要性は、いくら強調しでも足りないほどです。

アジャイルテクニックが蔓延するようになって、アプリケーションは開発しながら設計していけばよい、いやその方がよいのだという考え方が広く浸透しています。複雑で包括的な技術設計をあらかじめ書くという時代は終わったというのです。新しい考え方の人々は言います。「早い段階から頻繁にデプロイせよ。稼働する1行のコードは、頭の中の10行に勝る」これらの御説を聞くと、すばらしすぎて夢のようだという気がしてきます。そして、データに関しては、まさにそうなのです。

ビジネスルールやユーザーインターフェイスは非常に速いペースで発展しますが、あなたが集めるデータの構造やリレーションにはそんなことは普通ありません。ですから、データモデルは、構造的にも分析的にも最初の段階できちっと決めておくことが大切です。異なるスキーマにデータをそのまま移すのは、かなり難しく、時間がかかり、エラーを起こしやすい仕事です。アプリケーションレイヤーのバグは、ときどき大きな問題になる程度ですが、データベースのバグは致命的な意味を持っています。データレイヤーの設計ミスは、見つけて修正できたととしても、壊れてしまったデータは元に戻りません。

今日のデータの安全を保障し、明日のデータの拡張性を約束してくれるのは、しっかりとしたデータモデルです。データの安全保障とは、アプリケーションレイヤーのバグの影響を受けないということです。アプリケーションレイヤーは頻繁に変わるため、いかに努力しでもバグが忍び込むことはなかなか避けられませんが、それでもデータレイヤーには影響を及ぼさないということです。そのためには、参照整合性を適用し、ドメインの制約を組み込み、そして、そのために役立つキーを選択することです。一方、明日のデータの拡張性とは、データを適切に正規化し、後でデータモデルの上にアーキテクチャー上のレイヤーを簡単に追加できるようにすることです。近道はありません。

データベースは、あなたの貴重なデータを守る最後の門番です。性質上、短命なアプリケーションレイヤーは、自ら番人の役割を担うことはできません。データベースが番人の役割を全うするには、無関係なデータをはねつけ、無意味なリレーンョンを結ばないようにデータモデルを設計しなければなりません。キー、外部キーリレーション、ドメイン制約などは、スキーマで記述されていれば簡潔で、理解したり確かめたりしやすく、自己記述的になります。データモデルで、変換されたドメインルールは、物理的で永続的でもあります。アプリケーションロジックに変更を加えても、これらが消えることはありません。

リレーショナルデータベースから最大限の力を引き出す(アプリケーションデータの単純な貯蔵庫ではなく、アプリケーションの不可欠な構成要素とする)には、最初の段階から、自分が構築しているものが何なのか、しっかりとした理解が必要です。プロダクトが発展すれば、データレイヤーも発展していきますが、発展のどの段階をとっても、データベースは要塞としての役割を果たしていなければいけません。アプリケーションの他のレイヤーが抱えているバグをトラップするという重い責務をデータベースに与え、データベースを信頼すれば、がっかりさせられることはないはずです。