はじめに

前回の「データベース設計入門第3回：テーブル・カラム設計の基本」では、

テーブル
カラム
レコード
主キー
NULL
データ型
ID

など、テーブルを設計するうえでの基本について解説しました。

例えば、ECサイトであれば、

users
products
orders

のように、役割ごとにテーブルを分けてデータを管理します。

しかし、実際のシステムでは、それぞれのテーブルが完全に独立しているわけではありません。

例えば、

「この注文は、どのユーザーが行った注文なのか」

という情報が必要になります。

また、

「この注文には、どの商品が含まれているのか」

という情報も必要です。

つまり、テーブルを作ったあとは、

テーブル同士がどのような関係になっているのか

を考える必要があります。

このようなテーブル同士の関係を設計することを、一般にリレーション設計と呼びます。

今回は、テーブル同士の基本的な関係である、

1対1
1対多
多対多

について、ECサイトを例にしながら説明します。

また、テーブル同士を関連付けるために重要となる、

外部キー
親テーブルと子テーブル
中間テーブル

についても見ていきます。

この記事の対象者

この記事は、次のような人を対象にしています。

エンジニアとして開発をしているが、データベースについてあまり詳しくない人
SQLを書いた経験はあるものの、テーブル設計の経験が少ない人
テーブル同士をどのように関連付ければよいのか分からない人
「1対多」「多対多」といった言葉を聞いたことはあるが、意味をよく理解していない人
データベース設計を体系的に学び直したい人

SQLの基本的な知識があると理解しやすいですが、リレーション設計の経験がなくても問題ありません。

テーブル同士の「関係」とは

まずは、ユーザー情報を管理するusersテーブルと、注文情報を管理するordersテーブルを考えてみます。

users
-------------------
id
name
email
created_at

orders
-------------------
id
user_id
ordered_at
total_amount

例えば、次のようなユーザーがいるとします。

id	name	email
1	山田太郎	taro@example.com
2	佐藤花子	hanako@example.com

そして、注文データが次のようになっているとします。

id	user_id	ordered_at
101	1	2026-09-01
102	1	2026-09-05
103	2	2026-09-07

ここで、ordersテーブルの

user_id

に注目してください。

注文ID「101」のuser_idは「1」になっています。

これは、

users.id = 1

のユーザー、つまり山田太郎さんが行った注文であることを表しています。

図にすると、次のようなイメージです。

users
id = 1  山田太郎
   ↑
   │
   │ user_id = 1
   │
orders
id = 101

このように、あるテーブルのデータを別のテーブルから参照することで、テーブル同士の関係を表現できます。

外部キーとは

前回の記事では、レコードを一意に識別するための**主キー（PRIMARY KEY）**について説明しました。

例えばusersテーブルでは、

users.id

を主キーとして利用できます。

そして、先ほどのordersテーブルでは、

orders.user_id

から、

users.id

を参照していました。

users
-------------------
id        ← 主キー
name
email
     ↑
     │
     │ 参照
     │
orders
-------------------
id
user_id   ← users.id を参照
ordered_at

このように、別のテーブルのキーを参照するために設定する制約を、

外部キー（FOREIGN KEY）

と呼びます。

外部キーを設定することで、

存在しないユーザーに対する注文

のような不整合をデータベース側で防ぐことができます。

例えば、usersテーブルに、

id = 1
id = 2

のユーザーしか存在しないとします。

その状態で、

orders.user_id = 999

という注文が登録されてしまうと、

「user_id = 999とは誰なのか？」

という状態になります。

適切に外部キー制約が設定されていれば、このような存在しないデータへの参照を防ぐことができます。

なお、

user_id

というカラムそのものを「外部キー」と呼ぶこともありますが、厳密には、そのカラムに対して設定される参照のルールが外部キー制約です。

テーブル同士の関係は大きく3種類ある

テーブル同士の基本的な関係には、次の3種類があります。

1対1
1対多
多対多

英語では、それぞれ、

1対1   → One-to-One
1対多  → One-to-Many
多対多 → Many-to-Many

と呼ばれます。

順番に見ていきましょう。

1対1

1対1とは、

ある1件のデータに対して、別のテーブルのデータが最大1件対応する関係

です。

例えば、ユーザーの基本情報とプロフィール情報を別々のテーブルで管理するとします。

ユーザー
   │
   │ 1
   │
   │ 1
プロフィール

テーブルとしては、例えば次のようになります。

users
-------------------
id
name
email
created_at

user_profiles
-------------------
id
user_id
birthday
phone_number
address

1人のユーザーに対して、プロフィールを1件だけ持てる設計です。

例えば、

id	name
1	山田太郎
2	佐藤花子

というユーザーがいるとします。

プロフィールは、

id	user_id	birthday
1	1	1990-01-01
2	2	1995-05-10

となります。

users.id = 1

に対応するプロフィールは、

user_profiles.user_id = 1

の1件です。

「1件だけ」を保証する必要がある

ここで注意したいのが、

user_profiles.user_id

を作っただけでは、必ずしも1対1になるわけではないということです。

例えば、

user_id = 1
user_id = 1
user_id = 1

という3件のプロフィールを登録できてしまえば、1対多になってしまいます。

1ユーザーにつきプロフィールを1件だけにしたいのであれば、

user_profiles.user_id

に重複を許さない制約を設定するなどして、

同じユーザーに対するプロフィールは1件だけ

というルールをデータベース側でも保証する必要があります。

1対1なら必ずテーブルを分けるのか

ここで、

「1対1なら、最初から全部usersテーブルに入れてもよいのでは？」

と思うかもしれません。

その考え方も間違いではありません。

例えば、

users
-------------------
id
name
email
birthday
phone_number
address

としても設計できます。

そのため、

1対1の関係があるから必ずテーブルを分割する

というわけではありません。

例えば、

普段は利用しない情報を分離したい
特定機能でだけ使用する情報を分けたい
セキュリティや権限の都合で分離したい
テーブルごとの役割を明確にしたい

といった理由がある場合に、別テーブルにすることがあります。

重要なのは、

なぜテーブルを分けるのか

を説明できることです。

1対多

実際のデータベース設計で非常によく登場するのが、1対多です。

1対多とは、

ある1件のデータに対して、別のテーブルのデータが複数件対応する関係

です。

ECサイトで考えてみましょう。

1人のユーザーは、1回だけではなく何度も注文できます。

そのため、

ユーザー
   │
   │ 1
   │
   │ N
 注文

という関係になります。

ここで、

は1件、

は複数件を表しています。

つまり、

1人のユーザー
      │
      ├─ 注文1
      ├─ 注文2
      └─ 注文3

という関係です。

テーブルでは、

users
-------------------
id
name
email
created_at

orders
-------------------
id
user_id
ordered_at
total_amount

と表現できます。

例えば、山田太郎さんのIDが「1」で、

id	name
1	山田太郎

だったとします。

山田さんが3回注文すれば、

id	user_id	ordered_at
101	1	2026-09-01
102	1	2026-09-05
103	1	2026-09-10

のようになります。

すべての注文が、

user_id = 1

によって山田さんを参照しています。

これが1対多の基本的な形です。

親テーブルと子テーブル

このような関係を説明するとき、

親テーブル
子テーブル

という言葉が使われることがあります。

先ほどの例では、

users
   │
   │ 1
   │
   │ N
orders

となっています。

orders.user_idからusers.idを参照しているため、この関係について考えると、

users  → 親テーブル
orders → 子テーブル

と呼ぶことができます。

イメージとしては、

親：users

ユーザー1
   │
   ├─ 注文101
   ├─ 注文102
   └─ 注文103

子：orders

という形です。

親・子はテーブルに固定された役割ではない

ただし、

usersは常に親テーブル
ordersは常に子テーブル

というわけではありません。

例えば、

users
   │
orders
   │
order_items

という関係があった場合、

ordersはusersとの関係では子ですが、

order_itemsとの関係では親になります。

つまり、

親テーブル・子テーブルという呼び方は、どの参照関係について話しているかによって変わる

ということです。

外部キーは基本的に「多」の側に置く

1対多の関係を設計するとき、

「どちらのテーブルに相手のIDを持たせればよいのか？」

と迷うことがあります。

基本的には、

「多」の側から「1」の側を参照する

と考えると分かりやすいです。

例えば、

ユーザー 1
     │
     │
     N
   注文

であれば、「多」の側であるordersに、

user_id

を持たせます。

users
-------------------
id

orders
-------------------
id
user_id  ← users.idを参照

注文側から、

「この注文は、どのユーザーのものなのか」

を表しているわけです。

多対多

次に、多対多です。

多対多とは、

一方の複数のデータと、もう一方の複数のデータが互いに関連する関係

です。

ECサイトの、

注文
商品

を考えてみましょう。

1つの注文には、複数の商品を含めることができます。

例えば、

注文101
   ├─ パソコン
   ├─ マウス
   └─ キーボード

という注文ができます。

一方、同じ商品が別々の注文に含まれることもあります。

マウス
   ├─ 注文101
   ├─ 注文105
   └─ 注文110

つまり、

1つの注文 → 複数の商品

1つの商品 → 複数の注文

という関係です。

概念的には、

注文 N
   │
   │
   │
   │ N
 商品

となり、これが多対多です。

多対多では中間テーブルを使う

多対多の関係をリレーショナルデータベースで表現するときは、

中間テーブル

を使うのが一般的です。

今回の例では、

order_items

という「注文商品」を管理するテーブルを間に作ります。

 注文
   │
   │ 1
   │
   │ N
注文商品
   │
   │ N
   │
   │ 1
 商品

英語のテーブル名で表すと、

orders
   │
   │ 1
   │
   │ N
order_items
   │
   │ N
   │
   │ 1
products

となります。

例えば、

orders
-------------------
id
user_id
ordered_at

order_items
-------------------
id
order_id
product_id
quantity

products
-------------------
id
name
price

というテーブルを作ります。

ここでorder_itemsには、

order_id
product_id

という2つの参照を持たせています。

中間テーブルのデータを見てみる

例えば、商品が次のように登録されているとします。

id	name
201	パソコン
202	マウス
203	キーボード

そして、注文ID「101」で、

パソコンを1個
マウスを2個

購入したとします。

order_itemsは、例えば次のようになります。

id	order_id	product_id	quantity
1	101	201	1
2	101	202	2

1行目は、

order_id   = 101
product_id = 201

なので、

注文101に商品201（パソコン）が含まれている

ことを表します。

2行目は、

order_id   = 101
product_id = 202

なので、

注文101に商品202（マウス）が含まれている

ことを表しています。

つまり、中間テーブルは、

「どのデータと、どのデータが関連しているのか」

を管理する役割を持っています。

多対多は「2つの1対多」と考える

多対多は、最初は少し理解しにくいかもしれません。

その場合は、

2つの1対多に分解する

と考えると分かりやすくなります。

まず、

注文
   │ 1
   │
   │ N
注文商品

です。

1つの注文には、複数の注文商品が存在します。

次に、

商品
   │ 1
   │
   │ N
注文商品

です。

1つの商品は、複数の注文商品から参照されます。

つまり、

注文 N ─ N 商品

という多対多の関係を、

注文 1 ─ N 注文商品
商品 1 ─ N 注文商品

という2つの1対多に分解しているわけです。

多対多の設計で迷ったときは、

間に中間テーブルを置き、2つの1対多として考える

と理解すると分かりやすいでしょう。

中間テーブルには「関係に関する情報」も持たせられる

中間テーブルには、2つのIDだけではなく、

その関係そのものについての情報

を持たせることもできます。

例えば、

order_items
-------------------
id
order_id
product_id
quantity
unit_price

とします。

quantityは、

「この注文では、この商品を何個購入したのか」

という情報です。

例えば、

注文101 × マウス → 2個
注文102 × マウス → 1個

のように、同じ商品でも注文によって数量が変わります。

この数量は、

orders

だけの情報でも、

products

だけの情報でもありません。

「注文と商品の組み合わせ」

に対する情報です。

そのため、中間テーブルであるorder_itemsに持たせるのが自然です。

unit_priceについても、例えば購入時点の商品単価を保存するのであれば、

「その注文で、その商品をいくらで購入したのか」

という注文商品に関する情報として持たせることができます。

この、

その情報は、何についての情報なのか

という考え方は、テーブル設計では非常に重要です。

1対1・1対多・多対多を整理する

ここまでの内容を一度整理してみましょう。

1対1

ユーザー
   │
   │ 1
   │
   │ 1
プロフィール

1人のユーザーに対して、プロフィールが最大1件対応する関係です。

1対多

ユーザー
   │
   │ 1
   │
   │ N
 注文

1人のユーザーに対して、複数の注文が存在する関係です。

実際のデータベース設計では、非常によく登場します。

多対多

概念的には、

注文 N ─ N 商品

です。

実際には中間テーブルを使い、

 注文
   │ 1
   │
   │ N
注文商品
   │ N
   │
   │ 1
 商品

のように表現します。

「0件でもよいのか」も考える

ここまで、

1対1
1対多
多対多

という分類について説明しました。

しかし、実際の設計ではもう1つ考えておきたいことがあります。

それが、

0件でもよいのか

という点です。

例えば、新しく会員登録したユーザーは、まだ注文をしたことがないかもしれません。

そのため、ユーザーと注文の関係は、より正確には、

1人のユーザーには0件以上の注文が存在する

と考えることができます。

ユーザー
   │
   │
   └─ 注文 0件以上

プロフィールについても、

プロフィール登録は任意

というシステムなら、

1人のユーザーに対してプロフィールは0件または1件

となります。

ER図などでは、

0..1
0..N
1..N

のような表記で最小件数と最大件数を表すことがあります。

最初のうちは、

1対1
1対多
多対多

という基本を理解したうえで、

「0件という状態は許可されるのか？」

もあわせて確認するとよいでしょう。

関係を判断するときは日本語で考える

1対1・1対多・多対多を判断するとき、いきなりテーブル構造を考えると分かりにくい場合があります。

そのようなときは、まず、

業務上の関係を日本語の文章にする

と考えやすくなります。

例えば、ユーザーと注文なら、

1人のユーザーは、複数の注文を行うことができる。

1つの注文は、1人のユーザーに属する。

となります。

つまり、

ユーザー 1 ─ N 注文

です。

注文と商品なら、

1つの注文には、複数の商品を含めることができる。

1つの商品は、複数の注文に含まれることができる。

となります。

両方とも「複数」なので、

注文 N ─ N 商品

となり、多対多であることが分かります。

そこで中間テーブルを作り、

注文
 │
注文商品
 │
商品

という形にします。

迷ったときは、

「AはBをいくつ持てるのか？」

「BはAをいくつ持てるのか？」

という2方向から確認すると、関係を整理しやすくなります。

関係はシステムの要件によって変わる

テーブル同士の関係には、

「このテーブル同士なら必ずこの関係になる」

という決まりがあるわけではありません。

例えば、

ユーザー
住所

について考えてみます。

1ユーザーにつき住所を1件しか登録できないシステムなら、

ユーザー 1 ─ 1 住所

になるかもしれません。

一方、

自宅
勤務先
実家
その他の配送先

など、複数の住所を登録できるシステムなら、

ユーザー 1 ─ N 住所

になります。

つまり、同じ「ユーザー」と「住所」であっても、システムの要件によって関係は変わります。

そのためリレーション設計でも、第2回で行った要件整理が重要になります。

実際のシステムでは、データ同士がどのような関係になっているのか

を確認して設計しましょう。

ECサイト全体の関係を見てみる

最後に、今回使用したECサイトのテーブルをまとめてみます。

ユーザー
   │
   │ 1
   │
   │ N
 注文
   │
   │ 1
   │
   │ N
注文商品
   │
   │ N
   │
   │ 1
 商品

テーブル名にすると、

users
   │
   │ 1
   │
   │ N
orders
   │
   │ 1
   │
   │ N
order_items
   │
   │ N
   │
   │ 1
products

そして、主な参照関係は、

users.id
   ↑
   │
orders.user_id

orders.id
   ↑
   │
order_items.order_id

products.id
   ↑
   │
order_items.product_id

となります。

複数のテーブルをこのように関連付けることで、

あるユーザーが行った注文
ある注文に含まれている商品
ある商品が含まれている注文
あるユーザーが過去に購入した商品

などをたどれるようになります。

テーブルを1つずつ独立して考えるだけでなく、

システム全体でテーブルがどのようにつながっているのか

を見ることが、リレーション設計では重要です。

まとめ

今回は、テーブル同士の関係を設計する方法について解説しました。

テーブル同士の基本的な関係には、

1対1
1対多
多対多

があります。

1対1は、

ユーザー 1 ─ 1 プロフィール

のように、1件に対して最大1件が対応する関係です。

1対多は、

ユーザー 1 ─ N 注文

のように、1件に対して複数件が対応する関係です。

1対多では基本的に、「多」の側から「1」の側を外部キーで参照します。

多対多は、

注文 N ─ N 商品

のように、双方が複数のデータと関連する関係です。

多対多の関係は、通常は中間テーブルを使って、

注文 1 ─ N 注文商品
商品 1 ─ N 注文商品

という2つの1対多として表現します。

また、テーブル同士を関連付けるときには外部キーを設定することで、

存在しないユーザーを参照する注文

のような不整合を防ぐことができます。

リレーションを考えるときは、

AはBをいくつ持てるのか？

BはAをいくつ持てるのか？

という2方向から考えてみると、関係を整理しやすくなります。

そして何より重要なのは、

実際のシステムや業務では、データ同士がどのような関係になっているのか

を確認することです。

第3回では1つ1つのテーブルやカラムを設計しました。

今回の第4回では、それらのテーブルをつなぎ、システム全体としてどのようなデータ構造にするのかを考えました。

テーブルを設計したあとは、それぞれを独立したものとして見るのではなく、テーブル同士のつながりもあわせて整理していきましょう。

関連記事