はじめに

リレーショナルデータベースの文脈において混同されがちな、代理キー(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}ということになります。
お察しの通り、この文脈で代理キーと代替キーとを混同した場合、相当ややこしいことになるでしょう。

まとめ

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