DB設計を行う際にサロゲートキーとナチュラルキーはどちらが良いのか？
ナチュラルキーはPKだとJOINが面倒なので主キーにしたくない。
サロゲートキーは可読性がよくない。
といった感じで、DBのキーに関してはよく論争することがあります。
私もとある現場でナチュラルキーでDB設計を行ったところ、「古いね～」って言われました。
そんな経緯もあって、サロゲートキーとナチュラルキーについて、調べてどちらがいいのか考えてみました。
ナチュラルキー(自然キー)
業務的にそのテーブルをユニークにしキーそのものに意味が含まれているものをナチュラルキーと言います。
簡単に言いますと入力データ自体をPKとした場合、PKはナチュラルキーとなります。
以下の表から社員マスタテーブルの社員コード(PK)のように、業務的に意味のあるキーがPKとなっている場合、ナチュラルキーと言います。
（※キーになる項目に対して意味のあるルール決めを行わないといけない。）
社員マスタ
| 社員コード(PK) | 社員名 |
|---|---|
| syain01 | 〇〇 太郎 |
| syain11 | 〇〇 次郎 |
| syain12 | 〇〇 三郎 |
| syain20 | 〇〇 カツオ |
| syain37 | 〇〇 花子 |
サロゲートキー(代理キー)
システム的にユニークな値になるようにDB設定等にてオートインクリメントで連番を設定している、テーブルのPKのことをサロゲートキー（代理キー）と呼びます。
このPKに関してですが、あくまでユニークになる連番なので、業務的は意味を持つ値ではありません。
以下の表から、システム上ユニークになるように連番を設定したID（PK）をPKとしている場合、サロゲートキーと言います。
社員マスタ
| ID (PK) | 社員コード | 社員名 |
|---|---|---|
| 1 | syain01 | 〇〇 太郎 |
| 2 | syain11 | 〇〇 次郎 |
| 3 | syain12 | 〇〇 三郎 |
| 4 | syain20 | 〇〇 カツオ |
| 5 | syain37 | 〇〇 花子 |
ナチュラルキーとサロゲートキーどちらを使う？
ここが問題になってくると思います。
ナチュラルキーとサロゲートキーはどちらが優れているというものでは無いです。
サロゲートキーは、システム開発においての一つの思考であり業務的には必ずしも必要ではないです。
しかしながらナチュラルキーだけではシステム開発をする上で、どうしても難しく解決が困難な事が多々あると思います。
それぞれのメリット・デメリットを理解し適切なDB設計をすることが大事です。
サロゲートキーの特徴
-
テーブル間の依存関係が希薄
サロゲートキーの場合、業務の変更により主キーの体系が変化した場合などの影響が少ないです。
ナチュラルキーの場合、参照する様々なエンティティに影響が生じるため影響が大きいです。 -
画面間引き継ぎの情報や実装などを統一できる
全てのテーブルでサロゲートキーとしてIDを持った場合、削除や更新など全ての処理でその行に対する処理をIDで行うことが可能です。
ナチュラルキーの場合、特定のキーが必要となりますが、異なるテーブルでは一意と特定する為に必要なキーが異なります。
全てのテーブルでサロゲートキーとしてIDを持つなどすると、必要なキーは統一され、画面間で引き継ぐ情報や実装を統一することが可能ですが、それが一概に良いとは言えません。
コードを自動生成するツールを作る場合など、実装を容易にするという面では良いかもしれません。 -
複合主キーのテーブルに比べSQLの条件が簡潔に実装できる
ナチュラルキーを複合主キーとして使った場合、主キーに対するあらゆる操作が複雑になります。
サロゲートキーの場合、1項目でレコードを一意に特定することが出来るという点でSQLを簡潔に記載することが出来ます。 -
業務上は意味のないキーなので、容量を余分に使ったりする
サロゲートキーは業務上必要なものではないので、DBの容量などを考えると余分な容量を使うことになります。
DBの容量によるコストやパフォーマンスなどを考慮するとデメリットとなります。
結果として
サロゲートキーの特徴が主となってしまいましたが、必ずしもサロゲートキーが良いというわけではないと思います。
ナチュラルキーは業務上必要な項目なので必ずテーブルに持つことになり、データの解析性などを勘案するとメリットも高いのもありますし、サロゲートキーのように業務上必要ではない項目とはいえシステム設計を行う上で考慮することも出てくると思います。
一つのことに固執することなく、柔軟に使い分けてより良いDB設計を行なえればと思います。