関係モデルとテーブル設計
現代のシステムで主流の「関係データベース（RDB）」は、データをすべて2次元の「表（テーブル）」で整理します。しかし、データの並べ方を誤ると重複が発生し、不整合の原因になります。RDBの設計図となる主キー・外部キーの仕組みと、重複をなくして美しいテーブルを作る「正規化」を学びます。
1. テーブル（Table）の構成要素
RDBでは、データを縦と横の2次元の表として整理します。この表のことをテーブル（Table）と呼びます。
- 行（Row / レコード：Record）： 横の一行です。これで「顧客1人分」「注文1回分」などの「データ1件」を表現します。
- 列（Column / フィールド：Field）： 縦の一列です。「名前」「電話番号」「登録日」など、データの「属性（項目）」を表現します。
2. 主キー（Primary Key）と外部キー（Foreign Key）
複数のテーブルを結びつけて複雑な情報を表現するために、RDBでは2種類の「キー（Key：手がかり）」を利用します。
- 主キー（Primary Key：PK）：
そのテーブル内で、「レコードを絶対に1件に特定できる、重複のない代表の列」です。例えば、「顧客ID」や「社員番号」などです。主キーには、重複した値（同じIDが2つあるなど）や、空の値（NULL）を入れることはできません。 - 外部キー（Foreign Key：FK）：
別のテーブルの主キーを参照し、テーブル同士を関連付ける（リンクする）ための列です。
3. テーブルの重複をなくす「正規化（Normalization）」
データを設計するとき、1つの大きな表にすべての情報を詰め込んでしまうと問題が発生します。 例えば、以下のような「注文履歴」の表を考えます。
注文ID、注文日、顧客ID、顧客名、顧客の住所、商品名、金額
この表では、同じ顧客が何度も買い物をすると、そのたびに「顧客名」や「顧客の住所」という同じデータがデータベース内に何度も重複して保存されてしまいます。 もしその顧客が引っ越した場合、過去のすべての注文レコードを探し出して住所を書き換える必要があり、更新漏れによる「不整合」の原因になります。
この重複を排除し、テーブルを論理的に分割していく設計プロセスのことを正規化（Normalization）と呼びます。
正規化を行うと、注文テーブルからは顧客名や住所が排除され、代わりに顧客ID（外部キー）だけが書き込まれます。 顧客情報は「顧客テーブル」の中にただ1件だけ保存されます。
これで、顧客が引っ越しても「顧客テーブル」の住所を1箇所書き換えるだけで、すべての注文履歴から最新の住所が参照され、不整合を防止できます。
次のセクションでは、このように設計されたテーブル群に対して、プログラムから「データを取得せよ」「新しい注文を書き込め」と指示を送るための標準データベース言語「SQL」について学びます。
関係データベース設計における正規化の段階と、それぞれの要点を整理しておきましょう。
- 非正規形：ひとつのセルに複数のデータが含まれている（繰り返しがある）状態。
- 第1正規形：すべての列の値が、これ以上分割できない最小単位（原子値）のみで構成されている状態。
- 第2正規形：第1正規形を満たし、主キーの一部によって一意に決まる列（部分関数従属）を別テーブルに分割した状態。
- 第3正規形：第2正規形を満たし、主キー以外の列によって決まる列（推移的関数従属）を別テーブルに分割した状態。
正規化を行うことで、データの重複が排除され、データの挿入・更新・削除にともなう整合性の破綻（整合性異常）を防ぐことができます。