こだわりのER図の書き方

# 導入

テーブル設計を行うときには、ER図がよく使われます。しかし全く同じ内容を表しているER図でも、書き方によっては意図が伝わりやすかったり、逆に伝わりにくかったりします。意図が伝わりやすいER図とは、どのようなものなのでしょうか？　この記事では提案の一つとして、筆者がER図を書くときに心がけていることについて紹介していきます。

# あまりよく考えられていないER図の例

ここでは、架空のECサイトでユーザーが商品を購入したときに使われるテーブルについて設計を行いました。**ユーザー**が**商品**をECサイトで**購入**します。ユーザーの**入金**を確認できたら、**在庫**から商品を**出庫**して、ユーザーに向けて**出荷**を行います。
去年はモデリングで上手く関連をつけられなかった新人くんも、先輩に教えてもらった"[トランザクションに着目した関連の付け方](https://qiita.com/nakaken0629/items/02633743068f217a0429)"に沿って、なかなか上手に関連がつけられたようです。設計が済んだテーブル情報を元にER図を作成してレビューしてもらうことにしました。さて、設計レビューは通るでしょうか？

![view-all.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/75307/21a245ec-400b-bb01-8ce1-e8d8c72de0ab.png)

# レビューにて

「ほう、なかなか立派なER図ができたようだね」
「はい、前に教えてもらったトランザクションに着目して関連をつけるようにしてみました」
「それじゃあ、しっかりレビューさせてもらうよ」
「はい（ドキドキ）」
...
「関連の付け方には、それほど気になる点はないんだけれど、なんとなく読み取りづらいER図なんだよねぇ」
「はぁ」
「トランザクションで見ると『購入』というモデルが最上位に来ているよね。これがトランザクションの基本となるモデルなのかな？」
「はい、ユーザーがサイト上で購入をするところから始まります」
「その下にある、『入金』『出荷』『出庫』、あと『購入明細』が、購入に関連づいたモデルだよね。購入明細だけ、他のモデルに比べて下の方にあるけど、これは何か意図があるのかな？」
「あ、特にないです。ツールが勝手にここに配置したんだと思います」
「この図を見ると、『購入』→『購入明細』→『商品』→『商品カテゴリ』という流れと、『購入』→『出荷』→『商品』→『商品カテゴリ』という二つの流れがあるように見えるけど、どうだろう？」
「そ、それもレイアウト的にそう見えるだけなのですが、むしろ商品に関しては『商品カテゴリ』→『商品』という親子関係があります」
「なるほど、レイアウトに関してはあまりこだわりなく書いているんだね。それが読み取りにくさにつながっているのかな...」
「...」
「このER図、一旦書き直させてもらってもいいかな？　自分が普段気をつけていることを使って、見やすくなるようにしてみるよ」
「お願いします」
「ところで、これは正確にはER図じゃなくてクラス図かな」
「はい、使ったツールがER図を扱えなかったので、クラス図で代替しました」
「まあ、"大体"わかるからいいか」
「親父ギャグは、滑ると辛いですよ」

# レイアウトにこだわったER図

![購入.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/75307/d655ddc9-59e2-7c57-c301-3fdf821043b6.png)
![マスタ.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/75307/11b5d6b0-b9d4-a830-8e35-54d96947edc7.png)

「はい、これが書き直したER図だよ」
「二枚になったんですね。確かに自分の作ったものに比べると、なんだか見やすい気がします」
「このER図には、いろいろこだわりが入っているんだけど、聞いてみる？」
「お願いします」

## A4横を意識してデザインする

二つのER図は、いずれもA4横に収まるようにレイアウトされています。モニターが横長ということ、人の視野は横方向が広いこと、などを考えると縦長よりは横長の方がぱっと見が良くなります。またドキュメントの大きさを揃えることで、統一感を持たせることができ、結果としてみやすさに繋がります。全ての図においてA4横に収めるのは結構厳しいのですが、逆に制約の中で見やすさにこだわることで、最終的に良いものができたりすることもあります。
なお、初期の設計の段階でスペースをギチギチに詰めてしまうと、メンテナンス時にたとえ項目一つの追加であっても他のモデルのレイアウトに影響が出てしまうことがあります。そのため、余裕を持ってデザインすることが大切です。

## 注目するモデルで分割する

A4横にこだわったレイアウトをする場合、どうしても一枚の設計書に収まりきらないことになります。そのためレイアウトを分割する必要が出てきます。その時は闇雲に分割するのではなく、それぞれ何に注目して分割するのかに注意します。
一つ目のER図は、トランザクションについてのものです。今回はトランザクションが少ないため一枚に収めることができましたが、これに店舗のバックエンドでの商品の発注に関するトランザクションがある場合には、それらを別のER図として分割すると良いでしょう。
二つ目のER図は、マスタとステートについてのものです。これもモデルが増えてきたら、マスタごと、ステートごとにさらにER図を分割すると良いでしょう。

## 親子関係のモデルは縦に並べる

親子の関係になるトランザクションは縦に並べるようにします。ここでは『購入』と『購入明細』、『出荷』と『出荷明細』がそれにあたります。親と子の属性の数が多い、あるいは親子から孫まであって縦幅が足りない時は、親は横から線を出して、子には上から線が入るようにレイアウトします。
またこれは、トランザクションだけではなくマスタ同士でも当てはまります。たとえば二つ目のレイアウトでは、商品カテゴリの中に商品が含まれる様を表しています。

![親子関係.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/75307/954afbb0-14a4-a8ad-3ed0-fbbfd261da6d.png)

## トランザクションは発生順に横に並べる

『購入』『入金』『出庫』『出荷』のトランザクションは、この順序で生成されます。このように順に生成される一連のモデルは横に並ぶようにレイアウトします。今回の『入金』『出庫』のように依存関係を持たず独立して作成されるようなものは、縦に並べることもあります。

## トランザクションに関連づくマスタやステートは右側に配置する

『購入』に対する『ユーザー』や『購入明細』に対する『商品』のように、トランザクションに関連づくマスタやステートは、マスタの横に配置します。このようなマスタやステートは関連があること自体が重要な情報なので、マスタやステートだけで独立したER図を用意した場合、属性を省略するとわかりやすくなることもあります。

## トランザクションに関連づくマスタやステートは、トランザクションを中心とするER図の中では複数配置しても良い

一枚目のER図をよく見ると、『商品マスタ』が複数箇所に存在しています。仮に一つにまとめた場合、上のルールを守るのが難しくなります。そのため、複数配置でルールを守りやすくします。この場合は属性を省略すべきです。

## 多重度をきちんとつける

モデル館には1:1関係、1:n関係、n:n関係があります。それらはもれなく書く必要があります。ここまでのルールを守ると、必ず左上にあるモデルが1で、右下にあるモデルがnになります。これで多重度が不自然なところがわかりやすくなります。
また、最小値が"0"なのか"1"なのかは、意外と重要です。これにより親子関係が親だけ先にできるものなのか、あるいは親子は同時にできなければならないのか、といった制約が明確になります。

## 線が交わらないようにする

関連の線は極力交わらないようにします。交わりが増えると非常に見づらい図となります。ただし必須ではなく、交わってでも短い経路で直接結んだほうがわかりやすい場合には、交わっても良いです。半円の記号を使って飛び越える見た目があるツールであればそれを使っても良いでしょう。今回では、『購入』と『出荷』を結ぶ関連と『在庫』と『出庫』を結ぶ関連が交わっています。『購入』と『出荷』を結ぶ線を、『在庫』の上を通るように遠回りさせることもできますが、今回は直接結びました。

# 作り直したER図を囲んで

「作り直したER図を見て、どう思った？」
「確かに自分が作ったER図よりは見やすいなと思いました」
「そういってもらえると、頑張って書き直した甲斐があるよ」
「関連だけでなくて、いろいろ考えながらレイアウトしているんだなというのがわかったのが、今回はよかったです。
「念のため補足しておくと、先に挙げたルールは僕が個人的に決めているルールであって、一般的にはそんなルールは知らないという人が多いということは覚えておいてほしい」
「はい」
「大切なのは、読みやすくするための工夫をするということ。そのためには『その図で何を伝えたいのか』ということを考えてER図を書くということ。これはER図だけではなく、全ての設計書、ひいては全ての文書について当てはまるので、覚えていくといいと思うよ」
「ありがとうございます」

次は、見やすいER図が書けるようになっているでしょうか。

# まとめ

1. たとえ適切な関連が結ばれていても、レイアウト次第では見にくいER図になってしまう
2. 見やすいER図を作るには、あらかじめ決めたルールを厳格に守ることが大切

# 補足：ER図を書くツールについて

ER図を書くツールについては、これといった決定打がないのが現状です。
最初のあまりよく考えられていないER図は、PlantUMLを使って書いています。名前の通りUML主体なのでER図は未対応なのと、レイアウトは基本的に自動で行われてしまうので、レイアウトをコントロールするのは非常に難しいところがあります。
作り直したER図は、実はPowerPointで作成しています。メンテナンス性は極端に悪いので通常の業務でPowerPointを選択することは皆無でしょう。ただし、有料とはいえ会社のパソコンにはインストール済みのことも多く、清書ツールと割り切れば必ずしもなしと言いきれないところはあります。
有料アプリのおすすめはastah*があります。これは自由にレイアウトが組めて、ER図もかけて、属性の編集などもしやすく、細かなところまで考慮された非常によいツールです。ただし値段もかなり高いため、個人で使うならばともかく、チームあるいは会社全体で採用するという時には費用対効果を検討して、お金を出してもらう人を説得する必要があります。
無料アプリでおすすめは、Oracle Data Modelerがあります。このアプリケーションは、Oracleとは関係なく独立してER図を書くことができます。世の中のその他のER図エディターと比較すると、共通のモデルを元に複数のER図を書くことができる数少ないエディターです。非常に良いツールで、しかもデータはテキストファイルで保存されるのでGit管理もできそうなのですが、実際のところはモデルの位置をほんの少し動かしただけで広い範囲で差分が出てしまうので、実質的には差分管理ができないというのが玉に瑕です。

PlantUML: https://plantuml.com/ja/
PowerPoint: https://www.microsoft.com/ja-jp/microsoft-365/p/powerpoint/cfq7ttc0pbmc
astah*: https://astah.change-vision.com/ja/
Oracle Data Modeler: https://www.oracle.com/jp/database/sqldeveloper/technologies/sql-data-modeler/

（このブログはちゅらいとを使って校正しています）