目次

データモデリング

  • データモデリングの間は性能を考えない。特に論理モデルの作成時はそうである。
    • データモデルはプログラムから独立した方がよいからである。
  • データモデリング担当者がきちんと正規化し適切なモデリングを行い、プログラマーは処理方法を意識せずに欲しいデータを取得するようなSQLを書く。このような状況のまま放置して、性能テストを迎えると、1回のSQLの実行に何秒もかかってしまい要件を満たしていないことが発覚する。特に、OLTPのように処理するデータが膨大なときがそうである。
    • インデックスを作成したり、DBの非正規化・集計表作りを行うことでこの問題は回避できる。
    • DBMSの処理済のデータを実表として持つ機能を用いる。この機能を用いると、SQLが来てから大量に処理するのではなく、事前にわかっている大量処理(結合など)を先行して処理しておき、中間データとして別途DB内が管理する(なんでもかんでもリアルタイム処理すればよいというわけではないことの一例)。ただし、処理済みのデータを保持するため、DBの容量が増えるという問題はある。
      • Oracleではスナップショット機能という。

分析作業から設計作業への移行方法

作りこみ型アプローチ

  • 分析での作業成果物であるER図やクラス図などのモデルを設計作業のための入力とし、詳細な情報を付加した上で最適化を施し設計も出るとするアプローチのこと。
  • 分析モデルから設計モデルまでがシームレスにつながっており、モデルなどの作業成果物は作業が進むにつれて、分析モデルをベースとして詳しい情報が追加され、さらには実行環境のために最適化されて成長していく。
  • 分析作業から設計作業に移行するときに、分析作業の成果物のモデル(ER図、アーキテクチャ図など)をそのまま利用できるメリットがある。
    • ただし、分析作業と設計作業で作成するモデルがガラリと変わる場合は作りこみ型アプローチは向いていない。例えば、初期のデータ中心開発や初期のオブジェクト指向開発、機能に基づく構造化手法開発などである。

変換型アプローチ

  • 分析作業の成果物と設計の成果物を明確に分離して作業を進める。
  • 変換型アプローチを採用している開発手法や方法論は少ない。
    • 変換型の方法論としてはシュレイアー&メラー法などがある。

参考文献

  • 『44のアンチパターンに学ぶDBシステム』
  • 『モデルとプロセスをめぐる冒険』