データベースのキーについて
関係データベースには、様々な種類の「キー」があります。
主なキーについて以下の表に示します。
主キー(Primary Key)：
一つのテーブルには一つの主キーがあり、そのキーによってテーブル内の各行（レコード）が一意に識別されます。
主キーはNULL値を持つことができず、必ず一意でなければなりません。
候補キー（Candidate Key）：
主キーと同じく、テーブル内の各行を一意に識別できる属性（または属性のセット）です。
ただし、一つのテーブルには複数の候補キーが存在する可能性があります。主キーは候補キーの中から一つ選ばれます。
非キー（Non-Key）：
候補キーでも主キーでもない属性を指します。
非キーはテーブル内のレコードを一意に識別する能力がありません。
外部キー（foreign key）：
複数のテーブルの関係を結び付けるためのキーのことです。
完全関数従属、部分関数従属、推関数従属について
データベースの設計において、完全関数従属、部分関数従属、推関数従属は正規化の過程で重要な概念です。
完全関数従属
属性 ( A ) が属性セット ( B ) に完全関数従属する場合、( B ) の任意の部分集合に ( A ) が関数従属しないという条件が必要です。
例：
学生ID, コースID → 成績
学生ID, コースID→成績 では、成績は学生ID, コースIDに完全関数従属しています。
部分関数従属
属性 ( A ) が属性セット ( B ) に部分関数従属する場合、( B ) のいくつかの部分集合に ( A ) が関数従属するという条件があります。
例：
学生ID, コースID → 学生名
学生ID, コースID→学生名 では、学生名は学生ID, コースIDに部分関数従属しています。これは、学生名が学生IDだけにも関数従属しているからです。
推関数従属
属性 ( A ) が属性 ( B ) に関数従属し、属性 ( B ) が属性 ( C ) に関数従属するが、( A ) が ( C ) に直接関数従属していない場合、( A ) と ( C ) の間に推関数従属が存在します。
例：
部署ID → マネージャID
部署ID→マネージャID とマネージャID → マネージャ名
マネージャID→マネージャ名 の場合、部署IDとマネージャ名の間には推関数従属が存在します。
正規化とは
データの重複をなくし整合的にデータを取り扱えるようにデータベースを設計することを、データベースの正規化と呼びます。正規化を行っておくと、データの追加・更新・削除などに伴うデータの不整合が起きるのを防ぎ、メンテナンスの効率を高めることができます。
ここでは、データベースを設計する際に一般的に用いられる第1～第3正規形までを説明していきます。
非正規形
非正規形では、データが重複していたり、複数の値が1つのセルに格納されていたりします。
| 顧客ID | 名前 | 住所 | 電話番号 |
|---|---|---|---|
| 1 | UT 太郎 | 東京都港区 | 090-○○○○-○○○○, 080-××××-×××× |
| 2 | アンカバ 花子 | 大阪府大阪市北区 | 070-△△△△-△△△△ |
| 3 | UT 太郎 | 東京都港区 | 090-○○○○-○○○○ |
非正規形のデータでは以下のような問題点が考えられます。
- 1つのセルに複数の値が格納されている
- データの重複が存在する
- 更新や削除時に不整合が生じる可能性が高い
第1正規形
第1正規形では、すべての属性が「単一の値」を持つようにします。つまり、セル内に複数の値を持たない形です。
また、第1正規形とした時点で、主キーを定義します。この手順では顧客IDと電話番号からなる、複合主キーとする場合で説明を進めます。
| 顧客ID | 名前 | 住所 | 電話番号 |
|---|---|---|---|
| 1 | UT 太郎 | 東京都港区 | 090-○○○○-○○○○ |
| 1 | UT 太郎 | 東京都港区 | 080-××××-×××× |
| 2 | アンカバ 花子 | 大阪府大阪市北区 | 070-△△△△-△△△△ |
| 3 | UT 太郎 | 東京都港区 | 090-○○○○-○○○○ |
単一の値を持つ形とした第1正規形ですが、まだ以下の問題点が残っています。
- 顧客ID「1」と「3」のデータが重複している
- 顧客の情報が更新されるたびに、複数行を修正する必要がある
第2正規形
第2正規形では、部分関数従属性を排除します。先ほど確認したとおり、名前と住所は顧客IDのみで一意に決まるため、電話番号の分割を行います。
顧客テーブル（顧客IDを主キーとする）
| 顧客ID | 名前 | 住所 |
|---|---|---|
| 1 | UT 太郎 | 東京都港区 |
| 2 | アンカバ 花子 | 大阪府大阪市北区 |
| 3 | UT 太郎 | 東京都港区 |
電話番号テーブル（顧客IDと電話番号を主キーとする）
| 顧客ID | 電話番号 |
|---|---|
| 1 | 090-○○○○-○○○○ |
| 1 | 080-××××-×××× |
| 2 | 070-△△△△-△△△△ |
| 3 | 090-○○○○-○○○○ |
分割を行うことで、顧客テーブルでは「顧客ID→名前、住所」の関係のみが残り、部分関数従属性が無くなりました。
第3正規形
第3正規形では、推移関数従属性を排除します。
第2正規形の顧客テーブルでは、顧客IDで住所が一意に決定し、それに伴って都道府県や市区町村が一意に決まります。このような推移関数従属性を排除するため、住所の分割を行いましょう。
顧客テーブル
| 顧客ID | 名前 | 住所ID |
|---|---|---|
| 1 | UT 太郎 | 1 |
| 2 | アンカバ 花子 | 2 |
| 3 | UT 太郎 | 1 |
住所テーブル
| 住所ID | 住所 |
|---|---|
| 1 | 東京都港区 |
| 2 | 大阪府大阪市北区 |
電話番号テーブル
| 顧客ID | 電話番号 |
|---|---|
| 1 | 090-○○○○-○○○○ |
| 1 | 080-××××-×××× |
| 2 | 070-△△△△-△△△△ |
| 3 | 090-○○○○-○○○○ |
分割後は、顧客テーブル・住所テーブルともに、直接的な従属性のみであるため、第3正規形の条件を満たす形になりました。なお、住所が都道府県や市区町村に依存している場合は、住所をさらに分割します。
まとめ
正規化の作業を通じて、データの冗長性が軽減され、整合的に管理できるようになっていく過程がつかめたでしょうか。次回は実際にSQLを用いてデータの挿入・更新・削除といったことを行いますので、正規化のメリットをより強く実感できるものと思います。
それぞれの正規形の条件をあらためて以下にまとめます。
第1正規形
・繰り返し項目を持たない
・導出項目を持たない
第2正規形
・第1正規形を満たしている
・主キーに対してすべての非キー属性が完全関数従属
第3正規形
・第2正規形を満たしている
・すべての非キー属性がどの候補キーに対しても推移的に関数従属していない
コメント