論理設計から動くシステムへ：ゼロからのデータモデリング入門（11）（3/3 ページ）

ホットスポット候補への対応

　論理I/O試算により、ホットスポット候補となる処理のI/O数を可視化でき、表示項目や結合条件、検索条件など、より詳細な情報を取得することができます。これを基にホットスポット候補への対応策として、「プロセスの見直し」、「RDBMS固有機能の検討」、「インデックス作成」、「データ構造の変更」の順に検討します。プロセスの見直しとしてSQL関数やストアドプロシージャによる処理効率の検討をし、RDBMS固有機能での対応としてテーブルへの物理アクセス回数を削減するデータクラスタリング機能、パーティショニング機能などの適用を検討します。

論理データモデルとの差異を知る

　物理データモデリングは、システムの視点で動く状態にすることを目的にしていますが、せっかくビジネスを反映した論理データモデル構造をなぜ変更するのか論証する必要があります。やみくもにプログラムの都合で変更するのではなく、プロセスとデータの視点からボトルネックを可視化し、施策の検討を行わなければなりません。

　自社で作成した論理データモデルを基に開発を外部委託した際、データ構造が大きく変更されていた場合には、明確に変更理由を求める必要があります。その際にどのようにホットスポットの選定をしたのか、選定したホットスポットに対する施策をどこまで検討してデータ構造の変更に至ったのかなどの説明を求めるべきです。CRUD図や論理I/O試算の考え方を理解しておくことにより、変更の根拠を確認することができるのです。

　いよいよ次回で本連載の最終回を迎えます。次回は、データモデルの総括として、これまでの話を振り返りながらデータモデリングへの取り組みと課題について解説します。