ソフトウェア産業に産業革命を起こすデータモデリング

ツールを使った表裏一体モデリング

   データモデラーの方々は3種類のモデルについてのアプローチをよく解説しますし、筆者もExcelやVisioなどを使ってよくER図を作りました。しかしその経験上、上記のアプローチは労力に見合うほどの効率が得られないと考えています。

   この方式の最大の欠点は、モデル間の可逆性（リバース）がないことです。確かに、最初にもやもやとした事象を整理して「概念モデル → 論理モデル → 物理モデル」とブレークダウンするには役立つでしょう。

   しかし、データベースの設計においては設計途中で頻繁に変更が入りますし、運用・保守で変わることもあります。そのため、データモデリング作業は順方向（トップダウンアプローチ）と逆方向（ボトムアップアプローチ）を繰り返しながら進むとされています。

   変更の度に「概念モデル ← 論理モデル ← 物理モデル」と逆方向に手動修正するというのは、口でいうほどたやすいことではありません。修正ミスや漏れがでてくる可能性があります。その結果、「ER図は残っているけれど、実際のテーブルと一致するかどうかは定かでない」という事態を招いてしまうのです。

   そういった問題を解決するために登場したのがデータモデリングツールです。「ERwin」や「ER/Studio」などの海外製品や「Object Browser ER」など国産製品が相次いでリリースされ、その可逆性を解決しました。

   これらのツールを使えば、「論理モデル ← 物理モデル ← RDBMS」というリバース連携が実現できます。また、それと同時に「論理モデル → 物理モデル → RDBMS」というフォワード連携も可能なので、フォワードとリバースを組み合わせたスパイラルなデータモデリングが可能になるのです。


   図3はこのようなツールを使った表裏一体型のデータモデリングです。ツールを使うことにより、いつでも実際のRDBMSの定義をER図にリバース生成できます。また、リバース生成したものを修正してRDBMSにフォワード反映できますので、RDBMSとER図の情報がいつでも完全一致することになります。

ツールの論理モデルとモデリング理論の論理モデルの違い

   「物理 → 論理」の可逆性を確保する場合、ツール上の論理モデルはモデリング理論における論理モデルとは少し異なります。ツールでは物理モデルからの可逆性を確保するために、より物理モデルに近いモデル構造になっています。

   例えば、論理モデルでは図4のようにn対nのエンティティ関係を直接記述します（線の端の太丸がnをあらわす）。


   しかし、このままではRDBMSへ実装できないので、図5のように中間に結合用テーブルを用意して2つの1対nから構成されることになります。


   ツール上の論理モデルは、表2のようにエンティティ名やアトリビュート名、リレーションなどの論理情報を物理情報とは別に持てるのですが、このような構造情報に関しては可逆性確保のため物理モデルと同じになるのです。

RDBMS	物理モデル	論理モデル
テーブル名	テーブル名	エンティティ名
参照整合性制約	参照整合性制約	リレーション
列名	列名	アトリビュート

   みなさんのまわりで、ER図で概念モデルを作成している人はいますか。設計手法は人それぞれの得意があるので否定はしませんが、筆者は概要設計段階の作業はUMLや業務フロー図など、ER図ではない表記法を採用しています。