DB設計について考える（その１）
IDにすべきか複合主キーにすべきかという問題は、個人的には解決したので次に進む。
まず、DB設計とは何かと考えると業務の記録をする入れ物を作ることである。記録が必要なければ、そんなものはリアルタイムに生成して忘れてしまって一向に構わない。では、業務とは何かといえば会社というシステムの仕組みのことである。では、システムとは何かと言えば、入力・出力・処理・内部状態の四要素から構成される概念である。
すなわち、会社における入力・出力・処理・内部状態がすべて記録されたシステムは業務を完全に記録したシステムであると言うことができる。
まず、処理を考える。処理はプログラムなどで静的に構成され変化はしない。そのため処理はDB設計という観点から考えると無視することができる*1。
次に、内部状態は過去の入力・出力の結果であるから導出項目であり無視できると考える。そうすると、入力・出力・処理が記録されたシステムは業務が完全に記録されたシステムであることが導き出せる。ここで書かれているような「resource なんてない。ID以外の全ての属性は event に帰属するのだ！」という考え方はまさにそのような考え方から来ていると考えられる*2。
とはいえ、実務を考えれば業務を完全に記録する必要はない、あるいはテキストファイルにログが書き出されていればよいという場合は多い。その場合には入力・出力は一時的なものなので記録する必要などない。結果的にDB上には内部状態だけが残っていればよいということになる。これが「ビジネスアプリケーションはマスタメンテナンスシステム」と呼ばれる所以である。
ここでDB設計におけるひとつの設計指針が導き出される。入出力の履歴が必要であるならイベント・テーブルを用意すべきであるが、そうでないならばリソース・テーブルだけで構わない。ただし、情報量を考えるならば前者の方が多いので、要件が変化するような状況では前者を採用すべきである。これははぶ先生の主張とも整合的である。
ただし、ここではイベントとリソースの概念的な整理を行っただけであり、実際のDB設計ではリソースとイベントが混在することになる。次回（←っていつやねん）は、このことについて考えていきたい。
