【初心者向け】DBリレーションとは？種類と具体例をER図で解説

こんにちは！バックエンドエンジニアの日下部です。

この記事ではアプリ開発の最も重要な要素の1つ、データベースのテーブル同士の関係性を定義するDBリレーションについて基本から丁寧に解説します。初心者でも理解しやすいように、ER図を使って視覚的に説明していきます。ER図（Entity Relationship Diagram）とは、「ユーザー」や「投稿」などそのアプリおけるそれぞれの主体（エンティティ）が、どういう関係性を持っているかを図解したものです。文字通りですね。コワクナイヨ。ちなみにこの記事ではMermaidというツールを使ってER図を出力しています。

これからバックエンド開発を学びたいと思っている方は、ぜひ最後まで読んでみてください！

DBリレーションとは？

DBリレーションとはRDB（リレーショナルデータベース：MySQLやPostgreSQLなど）において、データ主体同士の「関係性」を定義するものです。

まずRDBの前提となるデータ主体の語彙をおさらいしておきます。

• テーブル：エクセルでいうシート。アプリに登場する1つの主体としても扱われる。
• レコード：テーブルにおいて横1行で表示される1件のデータ。
• カラム：レコードが持つべきそれぞれの要素。テーブルにおける縦1列のこと。

では記事投稿機能を例に考えてみましょう。

まず登場する主体はユーザーと記事ですね。実際にはそれらを管理する users テーブルと posts テーブルです。

次にこれら主体の関係性を考えて定義する必要があります。この例だと 「1人のユーザーは複数の投稿を持つことができる 」のようなものですね。その場合一般的に「一対多（one-to-many）」リレーションと呼ばれる種類に当てはまります。

このようにアプリに登場する主体の関係性を定義する重要工程が今回のテーマ、DBリレーションなのです😎

DBリレーションの基本種類

DBリレーションにはいくつか種類がありますが、まずは次の3つを押さえておけば実務で困ることはありません。

• 一対一 (one-to-one)
• 一対多 (one-to-many)
• 多対多 (many-to-many)

それぞれ詳しく見ていきましょう。

一対一 (one-to-one)リレーション

一対一リレーションとは、あるレコードが別のレコード1つとだけ対応する関係を指します。

具体例として、users テーブルを中心に user_profiles（プロフィール情報）や user_settings（ユーザー設定）を管理する場合を考えてみましょう。

実際には要件を理解してこれらの主体に分割できること、「1人のユーザーにはそれぞれ1つのプロファイルと設定が存在するべきだな」とイメージすることから始めましょう！

ではどうやってリレーションを実現するのでしょうか？以下のPK, FKという2つの要素を使います。

• Primary Key（PK） とは各テーブルに必ず存在する id のような固有識別子のこと
• 一方で Foreign Key（外部キー / FK） とは「別テーブルにある参照したいカラム」のこと。大抵はそのテーブルのPK。

この例ではuser_profilesテーブルのuser_id と user_settingsテーブルのuser_id のそれぞれのFKカラムは、どちらも usersテーブルのid を参照したいのでそれと全く同じ値を持ちます。これによって「このテーブルはあのテーブルに紐づく」という関係性が実現するので、コードでデータを引っ張って来れるわけです。

なぜ一つのテーブルにまとめないのか？

「一対一なら、まとめて1つのテーブルにしてもいいのでは？」と思うかもしれません。しかし、実務では責務の分離のために分けることが推奨されます。主な理由は以下の通りです。

• 利用頻度の違い
  ユーザー基本情報（id, emailなど）は頻繁に取得されますが、ユーザー設定（通知ON/OFFなど）は設定画面を開くとき以外はほとんど使いません。別テーブルに分けることで、毎回不要なデータを取得せずに済みます。
• カラム数の増加を防ぐ
  users テーブルに全てをまとめると、id, name, email といったよく使う情報に加えて不要なカラムまで取得することになり、処理効率が落ちます。

このように、DBリレーションを適切に設計することで、データベースのパフォーマンスや可読性を高めることができるのです。

一対多 (one-to-many)リレーション

一対多リレーションとは、1つのレコードが複数のレコードと紐づく関係を指します。

典型的な例は、冒頭紹介したユーザーとブログ記事の関係です。

• 1人のユーザー（users テーブル）は、複数の投稿（posts テーブル）を持つことができる
• さらに、1つの投稿には複数のコメント（comments テーブル）がつくことがある

このとき、posts.user_id は users.id を参照し、comments.post_id は posts.id を参照することでテーブル同士が結びつきます。

一対一との違い

一対一リレーションでは1対1の対応でしたが、一対多では「親テーブル1レコードに対して子テーブルが複数紐づく」点が大きな違いです。
例えば id=1 のユーザーに対して、user_id=1 を持つ投稿が複数存在するイメージです。

以下に例をあげます。

テーブル: users

テーブル: posts

テーブル: comments

実装で注意すべきこと

初心者がやりがちなNG例として、users テーブルに post_ids というカラムを追加し、配列のように投稿IDをまとめて格納する方法があります。

これは以下の理由で推奨されません。

• DBが理解できない関係性
  配列から「このユーザーは3つの投稿を持つ」と解釈できず、アプリ側で余計な実装が必要になる。
• 検索効率が悪い
  アプリコード上で実際にSQLを用いてデータを呼び出す際、WHERE 句で検索するには配列を扱うのは難しく、インデックスも効かないためパフォーマンスが落ちる。
• カスケード削除が効かない
  外部キー制約がないため、任意のユーザー削除時にそのユーザーの投稿やコメントなどのデータも自動で削除する「cascade on delete」が機能しない。

RDBでは、1つのセル（データ1件の中のとある要素）に配列など複数の値を格納することは推奨されません。
一対多リレーションでは、外部キーを使って正しく主体を分割して紐づけることで、検索や削除処理も効率的に行えるようになります。

多対多 (many-to-many)リレーション

多対多リレーションとは、1つのレコードが複数のレコードに紐づき、かつ相手側のレコードも同様に複数のレコードに紐づく関係を指します。

例として、ブログ記事（posts テーブル）とタグ（tags テーブル）の関係を見てみましょう。

• 1つのブログ投稿は、複数のタグを持つことができる
• 1つのタグは、複数のブログ投稿に紐づくことができる

このような関係を正しく表現するためには中間テーブル（リレーションテーブル）を挟むのが基本であり、これまでのリレーションと異なる点です。

中間テーブルの役割

2つの主体間の関係性をシンプルに管理でき、検索効率も保てます。

もし中間テーブルを作らずに直接紐づけようとすると、片方のテーブルに重複データを持たせることになり、データの整合性や拡張性に問題が発生します。

正しい実装例

テーブル: posts　投稿データを管理（id, title, content など）

テーブル: tags　タグ名を管理（id, name など）

テーブル: post_tags (中間テーブル)　post_id と tag_id を持ち、両テーブルを結びつける

多対多リレーションは、現場で頻繁に登場する重要な概念です。
投稿とタグ以外にも、ユーザーとグループ、商品とカテゴリなど、さまざまなケースで活用されます。

中間テーブルを活用したDBリレーション設計を身につけることで、無駄のない効率的なデータベース構造を作れるようになります。

まとめ：DBリレーションを理解すれば設計力が上がる

今回紹介した 一対一 / 一対多 / 多対多 の3つのDBリレーションを理解すれば、ほとんどのデータベース設計に対応できます。

実際の現場では自己参照リレーションやポリモーフィックリレーションといった特殊ケースも登場しますが、基本のリレーションを押さえておけば応用が効きます。

DBリレーションを正しく理解し、ER図で可視化できるようになると、バックエンド開発の基礎力がぐっと高まります。ぜひ実際にテーブル設計を試しながら学んでみてください。

弊社の制作実績はこちら