Ruby on Rails によるシステム開発をモデリングで効率的に行う

• 概要編
• 分析・設計編（ユースケース図とユースケース記述）
• 分析・設計編（フィーチャモデリング）
• 分析・設計編（フィーチャと解決領域のマッチング）
• 分析・設計編（ER 図）
• 分析・設計編（ER 図の実践）
• 実装編（モデルを実装に落とし込む）
• まとめ

どうも、あかさたです。前回は「意識的に効率的な開発を行うこと」ことについて説明しました。今回と次回は、「これまでの分析設計を確実に Rails での開発につなぐこと」をテーマに、ER 図を紹介します。今回は、ER 図を、「なぜ ER 図を使うのか」「ER 図とは何か」という観点から説明します。

なぜ ER 図？

暗い路地裏で誰かがあなたの前に出てきて、「おい、UMLダイアグラムを見たいか？」と言ったら、そのダイアグラムはおそらくクラス図のことでしょう。（「UMLモデリングのエッセンス第３版」より）

Rails はドメインモデルを永続化するための DB スキーマさえあれば、開発を開始することができます。永続化するモデルを記述するモデリング技法としては、UML のクラス図があり、モデリングといえば一番最初に思い浮かべる手法です。ActiveRecord との相性もよさそうです。しかし、私は ER 図をお勧めします。

ここで、ER 図をお勧めするのは、私が ER 図の方が好きだから以下のような理由があります。

• ER 図の方が単純な図である
• ER 図を見るときはデータ構造に集中することができる
• ER 図は DB との相性がいい

ER 図は単純です。図を構成する要素は Entity、Attribute、Relationship しか存在しません。クラス図には様々な要素が含まれており、そのすべてを説明するには大変な労力を要しますし、関連端や多重度を誤記／誤読する人も多いのです。クラス図を正確に理解・記述できるスキルを持った人はあまり多くないでしょう。

私も 5% くらい執筆にかかわったその場でつかえるしっかり学べるUML2.0では、クラス図の解説に 50 ページ程度を割いています。それでも、クラス図の仕様を大体網羅しているかなという感じで、それを読んだだけでは正確に操ることはおろか、正確に読み下すことも難しいでしょう。

また、クラス図には、操作を明記することでふるまいを想起させる情報を追加することができます。その方が図の理解を促進する場合もありますが、データ構造を理解する上では妨げになる情報でもあります。豪華絢爛に属性と操作を追加してしまい、読むのに非常に骨の折れる（≒ソースコードを読むのと変わらない）図を何度も見たことがあります。

ER 図はデータモデルを表現するための図です。DB との相性がよく、「DB スキーマさえあれば・・・」という Rails の開発においては非常に役立つものです。とはいえ、クラス図を使うことに反対するわけではありません。UML に精通したメンバーで構成されているチームなら、それもありでしょう。いずれにせよ、ここでは ER 図を使用するものとします。

では、ER 図とはどのようなものか説明します。

ER 図とは？

ER 図（Entity-Relationship Diagram）とは、具体的なシステムのデータモデルを図として表現する図解表記法の一種です。ER 図は Entity（エンティティ、実体）、Relationship（関係、関連）、Attribute（属性）から構成されています。Entity は関係データベースでいえば、テーブルに相当します。Relationship は、Entity 間の関係を表現します。Attribute は、テーブルのカラムになります。

「ライターはブログ記事を書く」というケースを考えてみましょう。「ライター」と「ブログ記事」は Entity、「書く」は Relationship、ライターの「名前」などは Attribute になります。以下にかなり大雑把ですが、サンプルを載せます。

「ブログ記事」「ライター」は Entity です。Entity は内部が二つに分かれた矩形で表現し、矩形の上に名前を表記します。「ID」は Attribute ですが、矩形の上側の領域に記述されています。これは、主キーであることを表現しています。「ライターID」「タイトル」「内容」「名前」も Attribute ですが、主キーではありません。外部キーとなるもの（「ライターID」）には、「（FK）」が付加されます。

Relationship は、Entity 間の関係線として表現されます。線の端が「縦線」になっているものは、多重度（cardinality）が 1、「丸と広がっていく三本線（鳥足）」は多です。「ライター 1 に対して記事多」というように読みます。

ER 図の良いところは、書かれた図を割とそのまま DB スキーマとして使用することができることです。

まとめ

今回は、「なぜ ER 図を使うのか」「ER 図とは何か」という点を紹介しました。本記事では、ER 図の書き方を詳しく紹介できなかったので、詳細を知りたい方は、こちらの記事（@IT）がお勧めです。また、ER 図のテストについて知りたい方は、こちらの記事（オブジェクトの広場）の特別講演「現場を助けるモデリング」の発表資料を参照してください。

次回は、実際に Rails を意識した ER 図の書き方を本記事の事例に沿って紹介します。それでは！