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

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

どうも、あかさたです。今回は前回に引き続き、「これまでの分析設計を確実に Rails での開発につなぐこと」をテーマに、ER 図について紹介します。前回は、「なぜ ER 図を使うのか」「ER 図とは何か」を紹介しました。今回は、実際に Rails を意識した ER 図の書き方を本記事の事例に沿って紹介します。

Rails を意識した ER 図の記述

Rails には、テーブル名はモデル名の複数形（Article であれば、Articles）、外部キーになるカラムには、結合先のエンティティ名 + “_id”（User である場合、user_id）にするといった命名規約があります。
これは、Rails には Convention over Configuration（設定より規約）という考え方があるためです。規約に沿った開発をすることで本来必要なはずのさまざまな設定を省略することができます。このため、ER 図にとっては、やや不適切な命名となってしまう場合があります。二つの考え方を紹介します。

• ER 図上では Rails の命名規則に従わない（DDL を記述する際に、命名規則に従って命名しなおす）
• ER 図上でも Rails の命名規則に従う

SQL の自動生成を行わない場合や ER 図を日本語で書く場合は、前者を選択することも考えられます。SQL を自動生成する場合は後者の方が分かりやすいでしょう。分析と ER 図の見通しのよさを取るか、ER 図と DB スキーマの見通しのよさを取るかという話にもなります。ER 図でテーブルやカラムをどこまで網羅するかにも影響されます。

どちらがより優れた判断かはなかなか一言では言えないのですが、Rails では、DDL を必ずしも直接記述するわけではないので、状況に応じた判断をすればいいでしょう。本記事では、前者を採用します。

要求から ER 図を作成する

ER 図を作成するには、「Entity」「Attribute」「Relationship」を要求分析時に作成したドキュメントから見つけ出さなくてはなりません。実際に事例をもとに ER 図を作成しながら、やり方の一例を紹介します。

Entity と Attribute の発見

Entity と Attribute は要求ドキュメント（「ユースケース図とユースケース記述」「フィーチャモデル」「画面設計」）から見つけることができます。

本連載では、フィーチャモデルを作成した際に、実現方法の検討を行っているため、そこから「ブログ記事」「認証ユーザー」という Entity を発見することができます。（「認証ユーザー」は、具体的には記事を書く「ライター」と記事を公開する「ブログ管理担当者」がいますが、テーブルとしては、「認証ユーザー」一つで十分でしょう。）

Attribute の抜き出しは本記事では省略しますが、多くの場合、画面設計から抜き出すことができます。ためしに、この記事そのものを画面設計とみなして、Attribute を抜き出してみると、「タイトル」「ID（URL 参照）」「記事内容」「投稿日」「ライター名」などが抜き出せます。ライター名は、Relationship で解決するかどうか判断する必要があります。

画面設計から見つけにくい Attribute も存在します。たとえば、画面上では「記事を公開するボタンを押すと記事は公開状態になる」というような場合、具体的に入力フィールドや表示項目として「公開されているかどうか」が出てこない場合もあります。（普通表示しますが。）そのような場合には、ユースケース記述を参照します。場合によっては、「ブログ記事」のようなオブジェクトの状態遷移を検討しても良いです。

Relationship の発見

Entity は、ユースケース名やイベントフローの主語もしくは目的語として登場します。例として、「認証ユーザー」と「ブログ記事」の間の Relationship について分析してみます。分析は、「両者の間に Relationship は存在するかどうか」「存在するとすれば多重度はどのようになっているか」という観点から行います。

まず、「両者の間に Relationship は存在するかどうか」についてです。「認証ユーザー」と「ブログ記事」が登場するユースケース記述や画面設計を閲覧します。たとえば、「ライターごとのブログ記事を表示するページ」の画面設計や、「ライターは自分の記事しか編集できない」などのルール記述は見つかれば、ライターから記事を見つける必要（もしくは記事からライターを見つける必要）があるので、Relationship が存在することがわかります。

同じ Entity の間でも、異なる Relationship が発見される場合があります。あるブログ記事に対して、「ライター」である「認証ユーザー」と公開する「認証ユーザー（ブログ記事管理者）」というような場合です。そのような場合は、Relationship は別々に作成します。この記事では、前者の Relationship のみを使用します。後者は「必要ない」ためです。取捨選択を行うわけです。

次に、「存在するとすれば多重度はどのようになっているか」を検討します。一人のライターが複数の記事を書くことはあります。一つの記事を複数のライターが書くかどうかです。本記事の要求では明らかになっていませんが、一般的にはライターは一人なので、ここでも一人にしましょう。「認証ユーザー」と「ブログ記事」の多重度は「1:多」であることがわかります。

Relationship を発見する際に、新しく Entity を発見する場合があります。たとえば、「ブログ記事を公開する」ときに、「いつ誰が公開・非公開を設定したのか履歴を残したい」という要求があれば、「公開履歴」というような Entity を抜き出す場合があります。記事では、流れ作業のような書き方をしていますが、実際にはそれぞれ行ったり来たりしながら作業を進めていく必要があることに注意してください。

作成した ER 図

「認証ユーザー」については検討していませんが、上記を踏まえると以下のような ER 図を作成することができます。

まとめ

前回と今回で「これまでの分析設計を確実に Rails での開発につなぐこと」をテーマに、ER 図の作成方法を Rails の実態に合わせて紹介してきました。

一番難しいことは、「どこまで完璧な ER 図を作成するか」判断することです。

Rails では、マイグレーションによって、DB スキーマも試行錯誤しながら開発をすることができます。動作を確認しにくい ER 図上で完璧なものを作るよりは、レールの上で試行錯誤する方が効率が良いと考えられます。

一つアイディアを提示しておくと、試行錯誤のベースに乗せるために、「Entity（テーブル）」の洗い出しは完全な状態にしておき、「Relationship」と「Attribute」はある程度の状態で完了させて、レールの上で試行錯誤しながら完全なものにしていくというものです。

ただし、システムの重要度や新規開発か保守開発かでもこの辺の考え方は変わっていく可能性があるため、個別でいいと思った方法を選択してください。大切なことは、完全なモデルを作成することは、必ずしもいい結果を生むわけではないということです。効率よく要求された品質のシステムを開発できる方法を選択してください。

次回は、モデルを実装に落とし込む手順について紹介します。それでは！