2024.12.16

Accessのリレーショナルデータベースの基礎を学ぼう

Officeのお役立ち情報

【2025年版】Accessリレーショナルデータベースの真髄｜Excel地獄から脱出する究極の設計術

この記事の最終更新日：2025年7月9日

先輩、私、会社の、顧客と、その、注文履歴を、全部、一つの、巨大な、Excelシートで、管理しているんですけど、もう、限界なんです…！
同じ、お客様が、注文するたびに、毎回、同じ、住所や、電話番号を、入力しているので、入力ミスが、絶えなくて。それに、お客様の、住所が、変更になったら、過去の、全ての、注文履歴の、住所を、一つ一つ、手で、修正しないといけなくて、本当に、大変で…。
先日、Accessを使えば、こういう、悩みが、解決できるって、聞いたんです。テーブルを、分割して、「リレーションシップ」っていうので、繋ぐと、いいって。でも、その、テーブルを、どう、分割して、どう、繋げばいいのか、その「考え方」が、全く、わからなくて…。何か、設計図のような、基本となる、ルールって、ないんでしょうか？

その、悩み、そして、その、Excelシートは、まさに、我々が『Excel地獄』と、呼ぶ、典型的な、状態だね。そして、君は、そこから、脱出するための、正しい、扉の前に、立っている。素晴らしいよ。
君が、耳にした、「リレーションシップ」こそ、Accessという、リレーショナルデータベース管理システムの、心臓部であり、Excelを、単なる「表計算ソフト」から、本格的な「情報システム」へと、昇華させるための、最も、重要な、概念なんだ。
それは、闇雲に、テーブルを、分割する、ということじゃない。データの『重複』と『矛盾』を、徹底的に、排除し、データの、整合性を、守るための、科学的で、美しい、『正規化』という、設計手法に、基づいているんだ。
今日は、その、データベース設計の、黄金律である、正規化の、プロセスから、テーブル同士を、結びつける、キーと、リレーションシップの、全知識、そして、データの、一貫性を、守るための、絶対的な、ルールまで、君を、単なる、データ入力者から、情報システムを、設計する『アーキテクト』へと、変えるための、全ての、知識と、技術を、日本一、詳しく、伝授しよう。

【思想編】なぜ、あなたは「Excel地獄」に、堕ちたのか？ - データ重複という、原罪

あなたの、その、巨大な、Excelシートで、起きている、問題。

それは、決して、あなたの、注意力が、散漫だから、では、ありません。

それは、全ての、情報を、たった、一枚の、シート（テーブル）に、押し込めようとする、Excelの、使い方そのものに、内在する、構造的な、欠陥なのです。

データベースの世界では、この、構造的な、欠陥が、引き起こす、問題を、大きく分けて、3つの「異常（Anomaly）」として、定義しています。

1. 更新異常 (Update Anomaly):
まさに、君が、直面している、問題だ。ある、顧客の、住所が、変更になった場合、その顧客の、全ての、注文レコードの、住所を、一つずつ、修正しなければならず、もし、一つでも、修正を、忘れると、「同じ顧客なのに、複数の、住所が、存在する」という、データの『矛盾』が、発生します。
2. 挿入異常 (Insertion Anomaly):
まだ、一度も、注文をしたことがない、新規の、見込み顧客を、登録したい、と、考えたとします。しかし、注文情報と、顧客情報が、一体化した、テーブルでは、「注文がないと、顧客情報も、登録できない」という、奇妙な、状態に、陥ります。
3. 削除異常 (Deletion Anomaly):
ある顧客が、過去に行った、唯一の、注文レコードを、削除したとします。すると、その、注文情報と、共に、その顧客の、名前や、住所といった、顧客情報そのものまで、データベースから、完全に、消え去ってしまう、という、意図しない、情報の、損失が、発生します。

これらの、異常は、全て、一つの、テーブルに、異なる、主題の、情報（「顧客」に関する情報と、「注文」に関する情報）が、混在し、それによって「データの、重複」が、発生している、という、ただ、一点に、起因します。

そして、リレーショナルデータベースデータを、複数の、関連付けられた、表（テーブル）として、管理する、データベースモデル。データの、重複を、排除し、一貫性を、保つことに、優れています。Accessは、このモデルを、採用しています。の、設計思想、すなわち「正規化」とは、この、データの、重複という「原罪」を、徹底的に、排除し、これらの、異常が、決して、起こり得ない、クリーンで、美しい、データ構造を、作り上げていく、知的な、プロセスなのです。

【第一章：設計編】データベース正規化という、美しき、科学

正規化とは、データを、矛盾なく、そして、効率的に、管理するために、テーブルを、ルールに従って、分割していく、データベース設計における、最も、重要な、プロセスです。

ここでは、最も、基本的で、重要な、第三正規形までの、プロセスを、あなたの、Excelシートを、例に、見ていきましょう。

第一正規形 (1NF) - 繰り返し項目の、排除

第一正規形の、ルールは、シンプルです。「一つのセルには、一つの値しか、含めてはならない」。

例えば、あなたの、Excelシートで、一つの、注文レコードに、複数の、注文商品（商品A, 商品B, 商品C）を、カンマ区切りなどで、入力していたとします。

これは、第一正規形の、ルールに、違反しています。

これを、解決するには、まず、「注文」という、テーブルと、「注文明細」という、テーブルに、分割します。

これにより、一つの注文が、複数の、商品行を持つ、という、構造を、実現できます。

第二正規形 (2NF) - 部分関数従属の、排除

第二正規形は、テーブルの「主キー」の一部だけで、一意に、決まる、項目を、別のテーブルに、分離する、という、プロセスです。（主キーが、複数の、フィールドで、構成される、複合キーの場合に、問題となります）

例えば、「注文明細」テーブルに、「注文ID」と「商品ID」という、複合主キーがあったとします。

このとき、「商品名」や「単価」といった、情報は、「商品ID」だけで、決まります。

これらの、項目が、「注文明細」テーブルに、含まれていると、同じ商品が、注文されるたびに、同じ、商品名や、単価が、重複して、記録されることになります。

これを、防ぐために、「商品」テーブルを、新たに作成し、「商品ID」「商品名」「単価」といった、商品に関する、情報だけを、そちらに、移動させます。

第三正規形 (3NF) - 推移的関数従属の、排除

第三正規形は、主キー以外の、フィールドによって、一意に、決まる、項目を、分離する、という、プロセスです。

例えば、「注文」テーブルに、「顧客ID」と共に、「顧客の、所属部署名」や、「部署の、電話番号」といった、フィールドが、あったとします。

「部署名」や「部署の電話番号」は、主キーである「注文ID」ではなく、キーではない、「顧客ID」に、従属しています。（顧客が決まれば、その所属部署も決まる）

この状態は、部署の、電話番号が、変更になった際に、その部署に、所属する、全ての、顧客の、レコードを、修正しなければならない、という「更新異常」を、引き起こします。

これを、解決するために、「顧客」テーブルと、「部署」テーブルを、さらに、分離し、各テーブルが、単一の、主題に関する、情報のみを、持つように、設計します。

この、第三正規形まで、正規化を行うことで、あなたの、データ構造は、重複と、矛盾から、解放され、非常に、クリーンで、メンテナンス性の高い、状態になるのです。

結果として、元の、一つの、巨大な、Excelシートは、「顧客テーブル」「注文テーブル」「商品テーブル」「注文明細テーブル」「部署テーブル」といった、複数の、小さな、しかし、論理的に、関連付けられた、テーブル群へと、再構築されます。

【第二章：結合編】テーブル同士を、結びつける、キーと、リレーションシップ

正規化によって、分割された、テーブル群は、それだけでは、ただの、データの、断片です。

これらの、テーブルを、互いに、結びつけ、意味のある、情報として、再統合するための、接着剤の、役割を、果たすのが、「キー」と、「リレーションシップ」です。

主キーと、外部キー - 関係性の、架け橋

主キー (Primary Key):
テーブル内の、各レコード（行）を、一意に、識別するための、フィールド（列）です。例えば、「顧客テーブル」における「顧客ID」や、「商品テーブル」における「商品ID」が、これに、あたります。主キーの値は、テーブル内で、決して、重複してはならず、また、Null（空）であってはなりません。Accessでは、オートナンバー型を、主キーとして、設定することが、一般的です。
外部キー (Foreign Key):
ある、テーブルの、主キーを、参照するために、別の、テーブルに、設けられた、フィールドです。例えば、「注文テーブル」に、設けられた、「顧客ID」フィールドが、これに、あたります。この、外部キーが、「顧客テーブル」の、主キーと、結びつくことで、「どの、注文が、どの、顧客によって、行われたか」という、関係性が、定義されるのです。

リレーションシップの、3つの、種類

Accessの、「データベースツール」タブにある、「リレーションシップ」ウィンドウでは、これらの、キーを、使って、テーブル間の、関係を、視覚的に、定義します。

リレーションシップには、大きく分けて、3つの、種類があります。

1. 一対多 (One-to-Many):
最も、一般的な、関係です。「一」の、顧客が、「多」の、注文を、行う、という関係が、これに、あたります。「顧客テーブル」の、主キー（顧客ID）と、「注文テーブル」の、外部キー（顧客ID）を、線で、結ぶことで、定義します。
2. 多対多 (Many-to-Many):
「多」の、注文が、「多」の、商品を、含む、という、関係です。この、多対多の、関係を、直接、表現することはできないため、「ジャンクションテーブル（中間テーブル）」を、使います。先の、例では、「注文明細テーブル」が、これに、あたります。この、テーブルは、「注文ID」と「商品ID」という、二つの、外部キーを持ち、これによって、「注文」テーブルと、「商品」テーブルを、間接的に、結びつけます。
3. 一対一 (One-to-One):
比較的、稀な、関係です。例えば、セキュリティ上の、理由から、基本の「社員テーブル」とは、別に、給与や、人事考課といった、機密情報だけを、格納する「社員詳細テーブル」を、作成し、両者を「社員ID」で、結びつける、といった、ケースで、使われます。

データの、整合性を、守る「参照整合性」

リレーションシップを、定義する際に、最も、重要な、オプションが、「参照整合性の、強制」です。

これに、チェックを入れると、Accessは、以下の、二つの、ルールを、厳格に、適用し、データベースの、矛盾を、防ぎます。

ルール1：
親テーブル（例：「顧客テーブル」）に、存在しない、キーの値（例：存在しない「顧客ID」）を、子テーブル（例：「注文テーブル」）の、外部キーに、入力できなくなります。
ルール2：
子テーブルに、関連する、レコードが、存在する、親テーブルの、レコード（例：注文履歴が、ある、顧客）を、誤って、削除できなくなります。

さらに、「フィールドの、連鎖更新」や「レコードの、連鎖削除」といった、オプションを、有効にすれば、親テーブルの、主キーが、変更された際に、子テーブルの、外部キーも、自動で、更新されたり、親レコードを、削除した際に、関連する、子レコードも、自動で、削除されたりします。これらは、非常に、強力な機能ですが、意図しない、大量削除の、リスクも、あるため、その、意味を、完全に、理解した上で、慎重に、利用する必要があります。

まとめ - リレーショナルデータベースは、世界の「関係性」を、モデル化する、知的な、芸術である

Accessの、リレーショナルデータベース設計は、単なる、技術的な、作業では、ありません。

それは、現実世界の、複雑な、事象と、その、関係性を、観察し、分析し、そして、テーブルと、リレーションシップという、論理的な、モデルへと、落とし込んでいく、知的で、創造的な、芸術活動なのです。

1. まず「Excel地獄」の、苦しみから、学ぶこと:
データの、重複が、引き起こす、更新、挿入、削除の、三つの「異常」。この、痛みを、理解することこそが、リレーショナルデータベースの、必要性を、心から、受け入れるための、第一歩です。
2. 「正規化」という、羅針盤に従い、データを、分解せよ:
一つの、テーブルには、一つの、主題だけ。この、大原則のもと、第三正規形を、目指して、テーブルを、美しく、そして、論理的に、分割していく。この、プロセスが、あなたの、データベースの、品質を、決定づけます。
3. 「キー」と「リレーションシップ」で、世界を、再結合せよ:
分割された、テーブルを、主キーと、外部キーという、金の、糸で、再び、結びつけること。そして、「参照整合性」という、鉄の、掟で、その、関係性の、秩序を、守ること。これにより、あなたの、データベースは、単なる、データの、集合体から、矛盾のない、一貫した「情報システム」へと、昇華します。

正しく、設計された、リレーショナルデータベースは、あなたが、これから、作成する、全ての、フォームや、クエリ、レポートの、強固な、土台となります。

それは、あなたの、ビジネスを、支え、成長させ、そして、日々の、面倒な、データ管理の、悩みから、あなたを、永遠に、解放してくれる、最も、価値のある、知的資産となるでしょう。

ぜひ、あなたも、この、奥深く、そして、美しい、データベース設計の、世界に、足を踏み入れてみてください。