ER図をDDLに落とす
変換は機械的に決まる
ここまでで、ER図の部品はひととおり出揃いました。実は、ER図から DDL への変換には判断の余地がほとんどありません。次の表のとおりに機械的に置き換えるだけです。
| ER図の要素 | DDL |
|---|---|
| エンティティ | CREATE TABLE |
| 属性 | 列 |
| 主キー | PRIMARY KEY |
| 1対多の線 | 多の側に FOREIGN KEY |
| 1対1の線 | どちらかに FOREIGN KEY + UNIQUE |
| 多対多の線 | 中間テーブル + FOREIGN KEY 2本 |
| 0を許さない | NOT NULL |
| 0を許す | NOT NULL を付けない |
判断が要るのは図を描くところまでで、そこから先は作業です。だから図をきちんと描くことに時間を使う価値があります。
記号と DDL の対応を読む
配送を追加します。図はこうです。
erDiagram
orders ||--o| shipments : shipped_by||--o| を両方向から読みます。左から右は「1件の注文に、配送は0または1件」。右から左は「1件の配送は、ちょうど1件の注文に属する」。
これを表に当てはめると、次の3つが出てきます。
- 1対1なので、外部キーは
shipments.order_idに置き、UNIQUEを付ける - 配送は必ず注文に属するので
NOT NULL - 注文側は0を許すので、
ordersには何も足さない
「0または1」の側に列を作らない、というのがここでの読み取りです。もし orders に shipment_id を作ってしまうと、配送前の注文はすべて NULL になります。
図に書けないことは DDL にも書けない
逆に言えば、DDL に書きたいことは全部図に書いてあるはずです。もし DDL を書いていて「ここは NULL を許すんだっけ」と迷ったら、それは図が足りていないサインです。
コードを書きながら設計を決め始めると、また第1章の状態に戻ります。手が止まったら図に戻る。この往復を習慣にします。
手を動かす
図を DDL に変換して、変換が正しくできたかを列の定義で確かめます。
テーブル構造
CREATE TABLE stores (
id integer PRIMARY KEY,
name text NOT NULL
);
CREATE TABLE customers (
id integer PRIMARY KEY,
name text NOT NULL
);
CREATE TABLE orders (
id integer PRIMARY KEY,
store_id integer NOT NULL REFERENCES stores (id),
customer_id integer NOT NULL REFERENCES customers (id)
);
INSERT INTO stores VALUES (1, '渋谷店');
INSERT INTO customers VALUES (1, '田中あかり');
INSERT INTO orders VALUES (1, 1, 1), (2, 1, 1);
期待される出力
| column_name | data_type | is_nullable |
|---|---|---|
| id | integer | NO |
| order_id | integer | NO |
| carrier | text | NO |
| shipped_on | date | YES |