長らくほったらかしにしてきたDB設計。
今回は、主キーはナチュラルキー・サロゲートキーどっちを使えばいいのか考える。
漢(オトコ)もDB設計は難しいって言ってる。
（正直この記事、何言ってるかわからなかったけど、それはDB設計が難しいのか漢(オトコ)が難しいのか・・・）
間違ってもいいから、作って壊して学んでいく。
1.主キーの役割
データベースの中から、ある一組のデータセット(レコード)を一意に識別するための情報。主キーに設定された項目は、複数のレコード間で重複することは許されず、主キーを持たないレコードが存在してもならない。主キーは必ずしも一つの項目とは限らず、複数の項目を組み合わせて主キーとして用いる場合もある。一般的には個々の要素に通し番号などを割り振ってこれを主キーに設定する場合が多い。
あるレコードを取ってくる場合に、目的のレコードと断定できるフィールドのことを主キーというのかな。
（レコードとは１行、フィールドとは個々の項目）
主キーに設定されたフィールドは、カラム（列）内で重複した値を持つことができない。
主キーを持たないレコードは存在してはいけない、という制約がある。
この主キーを、どんな項目に設定するかで色々派閥があるらしい・・・
2.ナチュラルキーとサロゲートキー
ナチュラルキーとは、入力データ自体を主キーとした場合。
だが、主キーの制約上、カラム内で重複する値を持てないため、以下のサロゲートキーが使われることがある。
サロゲートキーとは、通し番号などDB側で独自に割り当てたフィールドを主キーとした場合。
「業務上」意味を持たない連番IDってやつ。DBでは簡単に一意なフィールドが作れるけど！
サロゲートキーは本来なら存在しないはずのデータなので、これを許すかどうかで議論が起きるらしい。
本当のリレーショナルモデルでは存在しないから、DB界隈の人はつけないらしい・・・
3.複合主キー
サロゲートキーをつけない、かつナチュラルキーに重複がある場合はどうするのか。
その場合、複合主キーを使う。
テーブルの主キーを一つだけとすることを「単独主キー」、２つ以上のカラムを組み合わせた主キーを「複合主キー」と呼ぶらしい。
ナチュラルキーの組み合わせでレコードを特定するので、本来なら不要なサロゲートキーを新たに定義しなくて良いという利点がある。
ただ、この「複合主キー」にも問題が。
複雑、であるという問題が。
仕様変更時などに影響が及ぶ範囲が広くなり、既存の複合主キーでレコードが特定できなくなる問題などが起こりやすいらしい。
おそらくこの問題はDB設計を専門にしている方には、意味のない問題となるだろう。
しかし、自分の拙い設計では仕様変更が起こると考えると、サロゲートキーを使うのが無難だ。
参考
第3回 テーブル設計のグレーゾーン～毒と薬は紙一重 （4）サロゲートキーVSナチュラルキー：SQLアタマアカデミー｜gihyo.jp … 技術評論社
コメント