はじめに
このER図には、意図的に仕込んだ 9 つの違和感があります。全部指摘できますか？
- どの違和感も ER 図の基本を知っていれば言語化できるものです
- 「なんとなく変」を「これは◯◯が矛盾している」と言えるようになるのがゴール
- ER 図の書き方は教科書に載っていますが、「読む力」の訓練は意外と扱われないように思いこんなものを作りました
9 つの違和感 (目次)
図の左上から右下に向かって番号を振ってあります。
| # | どこがおかしい？ | ER 概念 |
|---|---|---|
| 1 | 「カテゴリ ⇔ サブカテゴリ」が循環参照 | 自己参照の設計不備 |
| 2 | 「顧客」の属性欄に JSON や配列が並ぶ | 1NF 違反 |
| 3 | 「顧客 ⇔ 注文」に「発注」「確定」2 本の線 | 関連の役割名重複 |
| 4 | 「発注」線の両端が「必ず 1」に固定 | カーディナリティ誤用 |
| 5 | 「顧客 ⟷ 商品」に中間実体なし | 多対多の分解漏れ |
| 6 | 「レビュー ⇔ 商品」の線だけ記法が違う | 記法混在 |
| 7 | 「配送先」が独立主キーで親を持たない | 弱エンティティ判定ミス |
| 8 | 「注文明細」の主キーが親を継承していない | 識別関係の PK 非継承 |
| 9 | 「明細」線の参加制約が両側で食い違い | 参加制約矛盾 |
解説
この記事では 3 つだけ抜粋して解説します。
#1 循環参照 (サブカテゴリ ⇔ カテゴリ)
このER図では「カテゴリ」と「サブカテゴリ」が 2 つの別エンティティになっていて、それぞれが互いのキーを FK として持ち、無限にたどれる状態になっています。
これは本来 自己参照 (再帰関連) で書くべきパターン。「カテゴリ」1 つのテーブルで「親カテゴリ ID」を FK として自身に向けて張ってあげれば、階層の深さがいくつでも表現できます。
サブカテゴリを別エンティティにしてしまうと、「サブサブカテゴリ」を追加したくなったときにまた新しいエンティティが必要になり、業務ルールが変わるたびにスキーマが増えます。
#4 カーディナリティ矛盾 (発注線)
「発注」線の両端に「必ず 1」の記号 (縦棒 1 本) が付いていて、これは「1 人の顧客は最大 1 注文しか持てない」「1 つの注文には最大 1 顧客しか紐付けられない」という意味になります。
EC サイトなら 1 顧客が複数回注文するのが普通で、この時点でこのモデルは業務として成立しません。カーディナリティは業務ルールを直接規定するので、最初にここで間違えるとその後のスキーマも実装も破綻します。
「EC サイト」と「顧客 - 注文 1:1」は、1 秒で違和感を持てるようになりたいペアです。
#5 多対多に中間実体なし (顧客 ⟷ 商品)
「顧客」と「商品」が直接 N:M で結ばれています。これでは「田中さんが 8/1 にこの商品を 2 個買った」という 購入履歴を格納する場所が存在しません。
多対多 (N:M) の関連は必ず 連関実体 (中間テーブル) に分解する必要があります。この図の場合、間に「注文明細」というエンティティがあるにもかかわらず経由していないのが違和感の正体です。
連関実体を挟むと、対応固有の属性 (購入日、数量、価格、支払い済みフラグ、など) を持たせる場所ができます。多対多を直接繋いだ瞬間、これらを持たせる場所がなくなります。
残り 6 つの答え合わせ + インタラクティブなクイズ
残りの違和感の解説はサイト側で公開しています。
各違和感を ER 図の基礎概念で言語化する構成で、7 サブページに分けて詳しく解説しています。各サブページには「このパターン、成立する？」の ◯× クイズも用意しました。
おわりに
ER 図はデータベース設計の言語ですが、教科書は「書き方」ばかり教えて「読み方」を扱いません。実務ではむしろレビューで渡された既存の ER 図を読み解く場面のほうが多いです。「変なER図」はその読解訓練の教材として作りました。
「なんとなく変」で止まっていた ER 図が、9 つの概念で言語化できるようになる感覚を、ぜひ試してみてください。
より深く学びたい方向けの書籍としては、楽々ERDレッスン (羽生章洋) と 達人に学ぶDB設計徹底指南書 第 2 版 (ミック) がおすすめです。