代理キーと代替キーの違いについて

はじめに

リレーショナルデータベースの文脈において混同されがちな、代理キー(alternate key)と代替キー(surrogate key)についてまとめました。

代理キーとは

代理キーは主キーに選ばれなかった候補キーのことを指します。オルターネイトキーとも呼ばれます。混乱を避けるため、オルターネイトキーと呼ぶことをおすすめします。

例を示します。

Personnel(company_id, emp_id, name, mail_address)

関係変数Personnelには(company_id, emp_id, name, mail_address)属性が含まれます。全ての社員は一意なcompany_idとemp_idの組を持ち、またすべての社員は一意なmail_addressを持つという要件があるとします。
このとき、関数従属性は以下の通りです。

{company_id, emp_id} -> {name, mail_address}
{mail_address} -> {company_id, emp_id, name}

よって、候補キーは{company_id, emp_id}または{mail_address}です。¹
ここで、{company_id, emp_id}を主キーに設定したとします。すると、候補キー{mail_address}が余ります。この主キーに選ばれなかった候補キーこそが、オルターネイトキーです。

代替キーとは

代替キーは人工的に付与されたキー属性の事を指します。対義語は自然キー（ナチュラルキー）です。サロゲートキーとも呼ばれますが、たいていの場合は代理キーと混同されて呼ばれています。混乱を避けるため、サロゲートキーと呼ぶことをおすすめします。
Ruby on RailsなどのORMフレームワークによってテーブルを作成すると、自動的に連番のidが付与されることがあります。このidがサロゲートキーです。サロゲートキーは開発環境と本番環境とでidがずれるなどの厄介な問題を引き起こすことがあるため、開発にRailsを利用しているなどのやむを得ない事情がなければ、自然キーを主キーに設定することをおすすめします。

例を示します。
先ほどの関係変数PersonnelをRailsのマイグレーションで実装したとします。Railsは自動的に連番のidを付与する仕様になっているため、出来上がったPersonnelテーブルの構造は次の通りになりました。

Personnel(personnel_id, company_id, emp_id, name, mail_address)

主キーはサロゲートキーである{personnel_id}、オルターネイトキーは{company_id, emp_id}および{mail_address}ということになります。
お察しの通り、この文脈で代理キーと代替キーとを混同した場合、相当ややこしいことになるでしょう。

まとめ

代替キーと代理キーとの混同は、サイゼリアでアボガド料理を食べながらファイヤーエンブレムを遊ぶようなものなのでやめましょう。

1. キー属性からキー属性への関数従属性があるため、この関係変数は第三正規形であってボイスコッド正規形ではありません。 ↩