ER図を使ってAccessデータベースの設計を行う

今回は、データベース設計でよく使われる「ER図」と、Accessのテーブル設計・リレーションシップとの関係について解説します。

ER図について調べると、専門用語が多くて分かりづらいと感じる方も多いのではないでしょうか。
特にAccessでデータベースを作る場合、「ER図の意味は何となく分かるけれど、実際にどう作ればよいのか」「Accessのリレーションシップと何が違うのか」といった点で迷いやすいです。

この記事では、ER図を単体の知識として説明するだけでなく、Accessで使うためのER図の作り方を中心に整理します。
「顧客」「注文」「商品」「注文明細」という身近な例を使いながら、テーブル・フィールド・主キー・外部キー・1対多・多対多といった考え方を、順番に見ていきます。

対象は、社内SEや業務担当者として小規模なAccessデータベースを作る方です。
専門的なER図の記法を完璧に覚えることよりも、Accessでテーブル設計に迷わないための考え方を身につけることを目的にします。

まずは、ER図がどのようなものか、Accessのテーブル設計とどう関係するのかを確認しましょう。

ER図とはAccessのテーブル設計を整理する図

ER図（Entity Relationship Diagram）は、データベースに必要なテーブルの種類と、テーブル同士のつながりを図にしたものです。
一言で言うと、Accessでデータベースを作る前に書く「設計図」です。

「E」はEntity（エンティティ）の略で、「管理したい情報のまとまり」を意味します。
注文管理であれば、「顧客」「注文」「商品」がそれぞれ1つのまとまりです。
Accessではこのまとまりが、そのままテーブルになります。

「R」はRelationship（リレーションシップ）の略で、「まとまり同士のつながり」を意味します。
例えば「1人の顧客が複数の注文をする」「1つの注文に複数の商品が含まれる」といった関係です。
Accessではこのつながりが、リレーションシップの設定に対応します。

イメージとしては、家を建てる前に設計図を書くのと同じです。
設計図なしに工事を始めると、後から「この部屋はどこにつながるの？」と困るように、Accessもテーブル設計を考えずに作り始めると、後から「この情報はどのテーブルに入れるべきだったか」と迷いやすくなります。

実際、Accessはテーブルを作ってすぐにフォームやレポートを動かせるため、設計を後回しにしがちです。
しかし設計なしに進めると、「顧客名を注文テーブルにも入れてしまった」「同じ商品情報があちこちに重複している」といった問題が起きやすくなります。

ER図は、こうした問題を防ぐために作る前に全体像を整理するためのものです。
専用ツールがなくても、紙やホワイトボードに書くだけで十分に使えます。

Accessで使うER図の作り方を5ステップで確認する

Accessで使うER図は、きれいな図を作ることよりも、テーブル設計に必要な情報を整理することが目的です。
難しく考えず、「どのテーブルに、何を、どうつなぐか」を順番に決めていくだけで十分です。

作り方は、次の5つの手順で考えると進めやすくなります。

手順	やること	確認ポイント	Accessで考えること
1	業務で扱うデータのまとまりを洗い出す	顧客、注文、商品などに分けられるか	テーブル候補を出す
2	テーブルごとの項目を整理する	その項目は誰の情報か	フィールドを決める
3	主キーを決める	1件を一意に識別できるか	ID項目を主キーにする
4	外部キーを決める	どのテーブルを参照するか	参照先IDを持たせる
5	線でつないで関係を確認する	1対多か、多対多か	リレーションシップの元を作る

この流れで整理すると、ER図の作り方とAccessのテーブル設計がつながって見えやすくなります。
それぞれの手順を順番に確認していきましょう。

1. 業務で扱うデータのまとまりを洗い出す

最初に、「業務で何の情報を管理したいか」を大きく分けます。
注文管理であれば、「顧客」「注文」「商品」「注文明細」が候補になります。
この段階では、細かい項目まで決める必要はありません。まず「何についての情報か」だけを整理するのがポイントです。

洗い出したまとまりが、そのままAccessのテーブル候補になります。
「顧客のことを管理したい → 顧客テーブルを作る」というように、1つのまとまりに1つのテーブルを対応させるイメージです。

2. テーブルごとの項目を整理する

次に、それぞれのテーブルにどの項目を持たせるかを考えます。
顧客テーブルなら顧客ID・顧客名・住所・電話番号、商品テーブルなら商品ID・商品名・単価、注文テーブルなら注文ID・注文日・顧客IDといったイメージです。

このとき重要なのが、「その項目は誰の情報なのか」を意識することです。
顧客名や住所は顧客の情報 → 顧客テーブルへ。
商品名や単価は商品の情報 → 商品テーブルへ。
注文日は注文そのものの情報 → 注文テーブルへ。
このように、情報の持ち主ごとにテーブルを分けるのが基本です。

例えば、注文テーブルに顧客名や住所まで毎回入れてしまうと、同じ顧客が10回注文するたびに同じ情報が10件登録されます。
後から住所が変わった場合、10件すべてを修正しなければならず、修正漏れが起きやすくなります。
テーブルを分けておくことで、こうした手間とミスを防げます。

3. 主キーを決める

テーブルと項目が整理できたら、主キーを決めます。
主キーとは、「そのテーブルの中で、1件のデータを特定するための番号や記号」です。
顧客テーブルなら顧客ID、注文テーブルなら注文ID、商品テーブルなら商品IDがこれにあたります。
同じ値が重複しないことが条件で、1つのテーブルに1つだけ設定します。

Accessでは、主キーの項目にオートナンバー型を使うと、レコードを追加するたびにAccessが自動で連番（1、2、3…）を割り当ててくれます。
手動でIDを管理する必要がないため、初めてデータベースを作る方にも扱いやすいです。

4. 外部キーを決める

外部キーとは、別のテーブルとつなぐために持たせるID項目のことです。
例えば、注文テーブルに顧客IDを持たせると、「この注文は顧客テーブルのどの顧客のものか」を表せます。

ここで少し分かりにくいのが、「同じ顧客IDでも役割が変わる」という点です。
顧客テーブルの顧客IDは、そのテーブルの1件を特定するための主キーです。
一方、注文テーブルに入っている顧客IDは、顧客テーブルを参照するための外部キーです。
項目の名前が同じでも、どのテーブルに置かれているかで役割が変わります。

比較項目	主キー	外部キー
役割	テーブル内の1件を一意に識別する	別テーブルのデータを参照する
重複	基本的に重複しない	同じ値が複数行に入ることがある
例	顧客テーブルの顧客ID	注文テーブルの顧客ID
Accessでの使い方	主キーとして設定する	リレーションシップで主キー側につなぐ

Accessのリレーションシップ設定では、この主キーと外部キーを線でつなぎます。
ER図を作る段階で「どのIDを使ってつなぐか」を決めておくと、後のAccess作業がスムーズになります。

5. 線でつないで関係を確認する

最後に、テーブル同士を線でつなぎ、関係を確認します。
このとき意識するのが「1対多」と「多対多」の2種類の関係です。

顧客と注文の場合、1人の顧客が複数の注文をします。
でも、1つの注文が複数の顧客のものになることはありません。
このように「1つ対複数」の関係を1対多と呼びます。
顧客テーブルの顧客IDと、注文テーブルの顧客IDを線でつなぐイメージです。

一方、注文と商品の関係は少し複雑です。
1つの注文に複数の商品が含まれます。
そして同じ商品が、別の注文にも何度も登場します。
つまり「注文側も複数、商品側も複数」という関係になります。
これを多対多と呼びます。

Accessでは多対多をそのまま直接つなぐことができません。
そのため、間に「注文明細テーブル」を用意し、注文と商品をそれぞれ1対多でつなぐ形に整理します。
この考え方は次のセクションで詳しく説明します。

顧客・注文・商品でAccessのER図を考える

ここからは、顧客、注文、商品を例にして、Accessで使うER図を具体的に考えてみます。

注文管理では、すべての情報を1つのテーブルにまとめると一見シンプルに見えます。
しかし実務では、顧客情報・注文情報・商品情報・注文明細をテーブルに分けて管理した方が、修正や集計がしやすくなります。

まずは、情報の種類ごとにテーブルを分けます。

テーブル名	主なフィールド例	役割
顧客テーブル	顧客ID、顧客名、住所、電話番号	顧客の基本情報を管理する
注文テーブル	注文ID、注文日、顧客ID	注文そのものの情報を管理する
商品テーブル	商品ID、商品名、単価	商品の基本情報を管理する

注文テーブルに顧客名や住所を直接入れてしまうと、同じ顧客が注文するたびに同じ情報が何度も登録されます。
例えば、顧客Aが10回注文すれば、顧客Aの名前や住所が10行分入ることになります。
この状態で顧客Aの住所が変わった場合、10行すべてを修正しなければならず、修正漏れが起きやすくなります。

そこで、注文テーブルには顧客名や住所ではなく、顧客IDだけを持たせます。
顧客名や住所は顧客テーブル側で管理するため、住所が変わっても顧客テーブルを1か所修正するだけで済みます。
「顧客の情報は顧客テーブルで管理し、注文テーブルはIDでつなぐだけ」と覚えておくと分かりやすいです。

注文と商品は注文明細でつなぐ

注文と商品の関係を整理するときは、注文明細テーブルが必要になります。

例えば、注文ID「1001」に商品Aと商品Bが含まれているとします。
さらに商品Aは、別の注文ID「1002」にも登場します。
このように、1つの注文に複数の商品が含まれ、かつ1つの商品が複数の注文に登場する関係を「多対多」と呼びます。

この多対多の関係を注文テーブルと商品テーブルだけで表そうとすると、「1つの注文に複数の商品をどう入れるか」で設計が崩れやすくなります。
そこで、2つのテーブルの間に注文明細テーブルを置いて整理します。

テーブル名	主なフィールド例	役割
注文明細テーブル	注文明細ID、注文ID、商品ID、数量、販売単価	どの注文に、どの商品が、いくつ含まれるかを管理する

販売単価は、注文時点の価格を記録するための項目です。
例えば商品の値上げが発生しても、注文明細テーブルに当時の価格を持たせておくことで、過去の注文金額を正しく残せます。
商品テーブルの単価とは別に管理するのはこのためです。

注文明細テーブルを使うと、注文と商品の多対多の関係を「2つの1対多」に分けて整理できます。

• 1つの注文に、複数の注文明細がある（注文 → 注文明細：1対多）
• 1つの商品が、複数の注文明細に登場する（商品 → 注文明細：1対多）

この形にすることで、注文ごとの商品・数量・金額を明細として正しく管理できます。
Accessで注文管理を作る場合、この注文明細テーブルの考え方を押さえておくだけで、テーブル設計で迷いにくくなります。

顧客・注文・商品・注文明細の4つをER図にまとめると、テーブル同士の関係は次のようになります。

関係	つなぐキー	関係の種類
顧客テーブル → 注文テーブル	顧客ID	1対多
注文テーブル → 注文明細テーブル	注文ID	1対多
商品テーブル → 注文明細テーブル	商品ID	1対多

注文テーブルと商品テーブルを直接つながないことがポイントです。
多対多の関係は、間に注文明細テーブルを置くことで、Accessでも扱いやすい1対多の形に整理できます。

ER図を書くときは、まずテーブル名を書き、次に主キーと外部キーを入れ、最後に関係の線を引く順番で進めると整理しやすいです。
きれいな図を目指すよりも、「どのIDでつながっているか」が自分や関係者に伝わることを優先しましょう。

ER図をAccessのリレーションシップに落とし込む

ER図でテーブル・フィールド・主キー・外部キー・関係を整理したら、次はAccessで実際に形にしていきます。
具体的には、Accessでテーブルを作成し、リレーションシップを設定する作業です。

注意点として、ER図を書いてもAccessには自動で反映されません。
ER図はあくまで「設計の整理」であり、Accessへの反映は手作業で行います。
ER図で考えた内容をもとに、Accessで「テーブルを作る→主キーを設定する→外部キーの項目を用意する→リレーションシップ画面でつなぐ」という順番で進めます。

Accessで設定するリレーションシップ

ER図で使う用語は難しく見えますが、Accessの用語と1対1で対応しています。
次の表を参考に読み替えると、ER図とAccessの関係が整理しやすくなります。

ER図の用語	Accessでの考え方	例
エンティティ	テーブル	顧客テーブル、注文テーブル
属性	フィールド	顧客名、注文日、商品名
主キー	レコードを一意に識別する項目	顧客ID、注文ID
外部キー	別テーブルとつなぐための項目	注文テーブルの顧客ID
リレーション	リレーションシップ	顧客テーブルと注文テーブルの関連

例えば「顧客」というエンティティはAccessの顧客テーブルに、「顧客名」「住所」「電話番号」という属性はフィールドにそれぞれ対応します。
顧客テーブルの「顧客ID」は主キーとして設定します。
注文テーブルにも「顧客ID」を持たせることで、「この注文はどの顧客のものか」を参照できるようになります。この注文テーブル側の顧客IDが外部キーです。

Accessのリレーションシップ画面では、この主キーと外部キーを線でつなぎます。
顧客・注文・商品・注文明細の例では、次の3つの関係を設定します。

• 顧客テーブルの顧客ID → 注文テーブルの顧客ID
• 注文テーブルの注文ID → 注文明細テーブルの注文ID
• 商品テーブルの商品ID → 注文明細テーブルの商品ID

ER図で引いた線が、そのままAccessのリレーションシップ設定に対応するイメージです。
ER図で全体の構造を考え、Accessのリレーションシップ画面で実際の設定に落とし込む、という流れになります。

リレーションシップを設定するときに、あわせて検討したいのが参照整合性の設定です。
参照整合性とは、テーブル間で矛盾したデータが登録されないようにするための仕組みです。
例えば「顧客テーブルに存在しない顧客IDを、注文テーブルに登録できないようにする」といったルールを設定できます。
存在しない顧客IDが注文テーブルに入ると、「誰の注文か分からないデータ」ができてしまいます。参照整合性はこうした問題を防ぐための設定です。

※参照整合性は便利な反面、削除・更新の扱いを誤ると予期せぬ動作につながることがあります。業務でどのようにデータを残すかを確認してから設定するのが無難です。

なお、ER図は専用ツールがなくても作れます。
小規模なAccessデータベースであれば、紙・ホワイトボード・Excelで十分です。
Excelの場合は、図形でテーブルを並べる方法でも、「テーブル名・フィールド名・主キー・外部キー・関係先」を表でまとめる方法でも構いません。

ただし、ExcelでER図を書いてもAccessの動作は変わりません。
Accessでテーブル同士の関係を機能させるには、実際にテーブルを作り、主キーと外部キーを用意した上で、リレーションシップを設定する必要があります。

ER図とAccessのリレーションの違い

ER図とAccessのリレーションシップは、どちらもテーブルの関係を扱うものですが、役割はまったく異なります。

一言で言うと、ER図は「作る前に考える設計図」で、Accessのリレーションシップは「考えた内容をAccessに設定する作業」です。
家づくりでたとえるなら、ER図が設計図、Accessのリレーションシップが実際の工事にあたります。

比較項目	ER図	Accessのリレーションシップ
位置づけ	データベースを考えるための設計図	Access上で関係を設定する機能
主な目的	テーブル、フィールド、キー、関係を整理する	主キーと外部キーを実際につなぐ
作る場所	紙、ホワイトボード、Excel、専用ツールなど	Accessのリレーションシップ画面
Accessの動作への影響	描くだけでは動作に影響しない	設定内容がデータ入力や整合性に影響する
注意点	関係者が理解できる形で残す	参照整合性や削除時の動きも確認する

表にある通り、ER図を書いただけではAccessの動作は何も変わりません。
ER図はあくまで「どんなテーブルを作り、どうつなぐか」を整理するためのものです。
実際にAccessが関係を認識するのは、リレーションシップ画面で主キーと外部キーをつないで初めてです。

つまり、ER図とAccessのリレーションシップはセットで考えるものです。
ER図で全体の構造を整理してから、Accessのリレーションシップ画面で設定する、という順番で進めると、作業の意味が分かりやすくなります。

ER図は専用ツールがなくても作れます。紙・ホワイトボード・Excelで十分です。
大切なのはツールの種類ではなく、「どのテーブルを、何でつなぐか」を自分や関係者が理解できる形で残すことです。

まとめ

今回は、Accessで使うER図の作り方と、Accessのリレーションシップに落とし込む考え方を解説しました。

ER図は、Accessのテーブル設計を整理するための図です。
専門的な記法を完璧に覚えることよりも、どのテーブルにどの項目を置き、どのキーでつなぐのかを考えることが大切です。

Accessで使うER図の作り方は、業務で扱うデータのまとまりを洗い出し、テーブルごとの項目を整理し、主キーを決め、外部キーを決め、線でつないで関係を確認する流れで考えると分かりやすくなります。

顧客、注文、商品、注文明細の例では、テーブルを分けることで1対多や多対多の関係を整理できることを確認しました。

ER図は設計、Accessのリレーションシップは実装です。
ER図で考えた主キーと外部キーの関係を、Accessのリレーションシップ画面で形にしていきます。

実務では、必ずきれいなER図を作らなければいけないわけではありません。
紙、ホワイトボード、Excel、Accessのリレーションシップ画面など、状況に応じて使いやすい方法で整理できます。

大事なのは、テーブルを作る前に「何をどこで管理し、何でつなぐのか」を考えることです。
そこを整理しておくことで、あとから修正しやすいAccessデータベースを作りやすくなります。

FAQ

AccessだけでER図は作れますか？

Accessのリレーションシップ画面を使うと、作成済みテーブル同士の関係を図のように確認できます。ただし、設計初期に全体像を整理したり、他の人と共有したりする用途では、紙、ホワイトボード、Excel、専用のER図ツールなどで先に整理してからAccessに反映する方法も使いやすいです。

ER図とAccessのリレーションシップは同じものですか？

同じではありません。ER図はテーブル構成や関係を考えるための設計図で、Accessのリレーションシップはその関係をAccess上で設定する機能です。

AccessでER図を作るとき、主キーと外部キーはなぜ必要ですか？

主キーはテーブル内の1件を識別するために使い、外部キーは別のテーブルとつなぐために使います。Accessのリレーションシップでは、この主キーと外部キーの関係を設定します。

注文テーブルと商品テーブルを直接つないではいけませんか？

注文と商品は多対多になりやすいため、直接つなぐと設計が複雑になりやすいです。Accessでは注文明細テーブルを間に置き、注文と注文明細、商品と注文明細の2つの1対多に分けると整理しやすくなります。

ER図はExcelで作っても問題ありませんか？

小規模なAccessデータベースであれば、Excelでテーブル名、フィールド、主キー、外部キー、関係先を整理する方法でも十分です。ただし、Excelで図を書くだけではAccessのリレーションシップ設定には反映されません。