2つの設計アプローチ
業務システムの設計アプローチとして、POA (Process Oriented Approach)とDOA (Data Oriented Approach)という考え方がある。POAでは業務プロセスつまり仕事の手順から手をつけていく。DOAではデータつまり帳簿から手をつけていく。自分には、DOAの方が理に適っていると思える。一般的な傾向として、業務プロセスよりデータの方が安定しているし、変更の影響が大きいからだ。だからデータベースに早めに安定した設計を与えたい。そうしないと、プログラミングできない。
データ構造がダメな状態で、プログラミングによって挽回することはできません。『データベース・リファクタリング』にもどうようの主張があった。
――『達人に学ぶDB設計』
機能が先かデータが先か
ところが、先日『はじめよう！要件定義』を読んでいたら、UI・機能・データを、- 何はともあれUI
- 操作に対して機能が動作すること
- 機能に必要なデータ揃っていること
何かを設計するときには、常にもうひとまわり大きなコンテキストの中で考えること。椅子ならば部屋の中にあることを考える。部屋なら家の中、家なら環境の中、環境なら都市計画の中。
――エリエル・サーリネン
並走すればいい
データモデリングの視点で見ると、これはトップダウンアプローチだ。普通は、これだけでは足りない。既存データがあるからだ。そこには、UIには表れない、他のシステムから連携されるデータが格納されているかもしれない。過去の業務プロセスに由来する、今は使わないデータが格納されているかもしれない。ここで、ボトムアップアプローチつまり既存データの分析も必要になる。ボトムアップアプローチでデータが変わるとどうなるか。既存データは変えられないから機能やUIにフィードバックがかかることになる。絵にするとこのようなイメージ。これならしっくり来る。
データベース恐怖症？
ここからは設計を離れて人の話。UIや機能の分析と、既存データの分析を一人で両方やる必要はないにしろ、最終的には統合して一貫した設計に仕上げないと動かない。だから、分担して情報交換することになる。そのときのことを考えると、もう少しデータベース設計の知識が広まるといいな、と思う。データベース設計をできてプログラミングできない人は見たことがないけれど、逆はよく見かける。漢(オトコ)のコンピュータ道: データベースについてのそもそも論や『SQLアンチパターン』を見ると、隔たりは大きそうだけれど。
