初心者でもわかるようにDBのkey(キー)制約をまとめてみた[PK(主キー)/UK(ユニークキー)/FK(外部キー)]
はじめに
業務でデータベース(DB)を扱う機会が増えると聞き、少し不安を感じています。
データベースを「いじる」と聞くと難しそうで怖い印象がありますが、
この記事を通じてDBの基本的な知識、特にKey制約について整理し、理解を深めたいと思います。
今回は、普段なんとなく知っているけれど、うまく説明できない「Key制約」に焦点を当てます。
key制約とは
リレーショナルデータベース(RDB)では、データを効率的に扱い、レコードを特定するために「Key」と呼ばれる仕組みが利用されます。
Key制約とはこの「Key」に一定の条件を課すことで、データの一意性や整合性を保つためのルールです。
PK(PRIMARY KEY/主キー)制約
PRIMARY KEY(プライマリキー、主キー)は、テーブルの各行(レコード)を一意に識別するための列(または複数列)に付ける制約です。
例えば、usersテーブルの主キーにuser_id列を設定すると、このuser_id列の値がそのテーブル内の各レコードを一意に識別します。
UK(UNIQUE KEY/ユニークキー)制約
UNIQUE KEY(ユニークキー)はPRIMARY KEYと同様に列の値が重複しないように制限するための制約です。
「主キー以外の列も一意性を持たせたい」ときに使う制約です
自分用メモ
UKって例えばuserテーブル内でもうuser_idにPK使っちゃってるけど、電話番号とかメールアドレスって一意じゃないとダメじゃん、けどPKってテーブルに1個だけじゃん!てときにUK使おう!ってかんじ
もう少しきれいに書くとUKを使うときは、、、
-
主キーが既に存在する場合
例えば、user_idがusersテーブルの主キー(PK)に設定されている場合、他の列(例えば、電話番号やメールアドレス)にも一意性を持たせたいときにUKを使います。 -
理由
電話番号やメールアドレスは通常、重複が許されません。
同じメールアドレスや電話番号を持つ複数のユーザーが登録されてしまうと、システムの整合性が崩れます。
FK(FOREGN KYE/外部キー)制約
FOREIGN KEY(外部キー)は、2つのテーブルのデータ間にリンクを設定し、参照整合性を確保するための制約です。
[参考記事]
[メモ]
見えるくんにおいて外部キーは開いてるページのPKがどこのテーブルの外部キーとして使われてるか
被参照外部キーは何て名前のFKを使ってどのテーブルを見ているか
わいた疑問と解決策
[疑問]
- 会員テーブル(members): user_id が主キー
- ゴールド会員テーブル(gold_members): こちらも user_id を持つ
- 注文テーブル(orders): user_id を参照する場合、どちらのテーブルの user_id か分からなくなる可能性がある
[解決策]
-
外部キー名をそもそもわかるように変えておく
ordersテーブルの外部キー名を、どのテーブルを参照しているのか明確にするよう命名します。
例えば、、、
・member_user_id: membersテーブルのuser_idを参照
・gold_member_user_id: gold_membersテーブルのuser_idを参照 -
リレーションを正確に設計
DBの外部キー制約を使いそれぞれの外部キーがどのテーブルを参照しているか明示的に指定する。
FOREIGN KEY (member_user_id) REFERENCES members(user_id),
FOREIGN KEY (gold_member_user_id) REFERENCES gold_members(user_id)
- テーブル構造の見直し(オプション)
統一テーブル設計: membersとgold_membersを1つのテーブルにまとめ、会員種別を表す列(例: member_type)を追加。
member_type ENUM('regular', 'gold') -- 通常会員かゴールド会員かを区別
[結論]
- 外部キー名を適切に変更することで、どのテーブルを参照しているかを明確化する。
- 外部キー制約を正確に設定し、データベースレベルで整合性を保つ。
- 必要に応じて、会員テーブルの構造を統一してシンプルに設計することで運用効率を上げる。
Discussion