基本設計段階でVIEWを活用すると思いのほか便利であることに気づいた。
VIEWによって、設計書とデータベースモデルの間に1つのレイヤーを作れることになるのだ。
データベースの「VIEW」は、地味ながら効果的な疎結合の仕組みなのだといえる。
例えば、以下のような部分をVIEWとして作成しておくと良い。
- 複雑なクエリとなる部分
- 構造が安定していない（ERモデル上の変更が見込まれている）部分
- 汎用的に結合を用いるべき部分
- サブシステムをまたがって参照する部分
これによりデータモデルに影響する仕様変更をVIEWで、ある程度は吸収することができる。
この辺は教科書どおりだが、基本設計段階でビューを多用することに意義がある。
データモデルを変更した時に、設計書のいたるところに影響が出ることを避けられるのだ。
また設計書にJOINを書く手間を減らし、パフォーマンスチューニングによる非正規化なども意識しなくてすむため設計書がシンプルになる。
さらに、次のようなことも考えられる。
設計においては実装者のスキルレベルが不明であるため、
あまり複雑なSQLを作らなくて済むようにと設計者は頭を捻ることが多いが、これが意外と設計上の制約になる。
こういった問題もVIEWレイアーが吸収してくれる。
またサブシステムをまたがって参照されるような部分でも
VIEWを他サブシステムに公開しておくことで、
対象のデータ構造は、主管となるサブシステムの設計チームが
ある程度自由に構造変更できる。
当然、VIEWの詳細設計は設計者が行う必要があるが、基本設計フェイズではメモ書き程度に設計しておき、詳細設計で詰めれば良い。
そのためVIEWを基本設計で活用するというプラクティスは業務設計チームからも好評だ。
データアクセス層やビジネスロジック層といったレイヤーの考え方はアプリケーションのアーキテクチャには必須だが、
n階層モデルといった考え方も詳細設計以降の段階で出てくるものであり、
基本設計段階では設計チームの記述ルールなどで工夫をする必要があった。
ビューを使えば設計レベルでも、ある程度のレイヤーが設けられる。
大規模なシステムになると有効だ。
