分析モデリングした際に、
たとえばあるユースケース
「顧客を(一意な顧客番号で)検索する」みたいなユースケースがあったとき、
【顧客】てエンティティには【顧客番号】という属性が必要です。
※この顧客番号ってのは DBを意識した主キーなるものではないことに注意してください。
これわたしも最初モデリングに慣れてない頃は、分析段階でDBを意識してしまってたんですが、
本来の分析モデリングでは以下の詳細は考えません。
・言語はなににするのか
・DBはどれ使うか などなど
あくまでも分析段階では、ユースケース(つまり機能要求)を満たすために
何が 必要なのか？を明らかにするだけです。
なので上記の顧客番号は、「顧客を(一意な顧客番号で)検索する」という、
ユースケースシナリオを実現するために必要な属性というだけです。
そして分析モデリングがある程度まとまったら、次に設計にいきます。
この時RDBを使うということになったとしましょう。
その際にこの顧客番号は、一意なために顧客テーブルの候補キーといえますね。
①そこでこれをそのまま顧客テーブルの主キーとして使うのか → ナチュラルキー手法
②それとも別に新たに主キーを定義してあげて、顧客番号にユニーク制約つけるのか → サロゲートキー手法
この２通りの手法があります。
一見、①の方が素直に見えます、、、よね？
しかもドメインモデルとテーブルの見た目が乖離しないからシンプルって利点があります。
逆に②はドメインモデルとテーブルの見た目が乖離して見えてしまうて欠点があります。
ただサロゲートキーにも利点はありますし、それは同時にナチュラルキーの欠点でもあることです。
結論から言うと
変化に強いのがサロゲートの利点、 変化に弱いのがナチュラルキーの欠点です。
ナチュラルキーはその特性上UIに近い存在だからか、
結構UI側に振り回されて変更が入りやすいって特性があります。
しかしながら主キーはその特性上、更新してはいけないという制約があります。
なので結果的に仕様変更に弱いし、複雑になってしまう恐れがあります。
対して、サロゲートキーは内部で自動的に一意な値を振る特性があるので
特にUIとかの都合に振り回されず、結果的に仕様変更などの変化に対して強く、
シンプルなテーブル設計の維持がしやすくなります。
さらに１つ追加すると、
ドメインモデルとテーブルのミスマッチの解消にはサロゲートキーが好ましいといわれています。
理由は、サロゲートキー自体はシンプルなものなので、
DAOパターンや RailsなどのActiveRecordを使うことで、
ドメインモデルとテーブルのミスマッチを容易に解消できます。
以上のことから、顧客番号なるものが変更される可能性がほぼないならナチュラルキー、
そうでないなら最初からサロゲートキーを用いることが後々の変化にも対応できることがうかがえます。