DB設計の主キー・ナチュラルキー・サロゲートキー・複合主キー

長らくほったらかしにしてきたDB設計
今回は、主キーはナチュラルキー・サロゲートキーどっちを使えばいいのか考える。

漢(オトコ)もDB設計は難しいって言ってる
(正直この記事、何言ってるかわからなかったけど、それはDB設計が難しいのか漢(オトコ)が難しいのか・・・)

間違ってもいいから、作って壊して学んでいく。

1.主キーの役割

IT用語辞典より引用

データベースの中から、ある一組のデータセット(レコード)を一意に識別するための情報。主キーに設定された項目は、複数のレコード間で重複することは許されず、主キーを持たないレコードが存在してもならない。主キーは必ずしも一つの項目とは限らず、複数の項目を組み合わせて主キーとして用いる場合もある。一般的には個々の要素に通し番号などを割り振ってこれを主キーに設定する場合が多い。

あるレコードを取ってくる場合に、目的のレコードと断定できるフィールドのことを主キーというのかな。
(レコードとは1行、フィールドとは個々の項目)

主キーに設定されたフィールドは、カラム(列)内で重複した値を持つことができない。
主キーを持たないレコードは存在してはいけない、という制約がある。

この主キーを、どんな項目に設定するかで色々派閥があるらしい・・・

2.ナチュラルキーとサロゲートキー

ナチュラルキーとは、入力データ自体を主キーとした場合。
だが、主キーの制約上、カラム内で重複する値を持てないため、以下のサロゲートキーが使われることがある。

サロゲートキーとは、通し番号などDB側で独自に割り当てたフィールドを主キーとした場合。
「業務上」意味を持たない連番IDってやつ。DBでは簡単に一意なフィールドが作れるけど!

サロゲートキーは本来なら存在しないはずのデータなので、これを許すかどうかで議論が起きるらしい。
本当のリレーショナルモデルでは存在しないから、DB界隈の人はつけないらしい・・・

3.複合主キー

サロゲートキーをつけない、かつナチュラルキーに重複がある場合はどうするのか。
その場合、複合主キーを使う。

テーブルの主キーを一つだけとすることを「単独主キー」、2つ以上のカラムを組み合わせた主キーを「複合主キー」と呼ぶらしい。

ナチュラルキーの組み合わせでレコードを特定するので、本来なら不要なサロゲートキーを新たに定義しなくて良いという利点がある。

ただ、この「複合主キー」にも問題が。
複雑、であるという問題が。

仕様変更時などに影響が及ぶ範囲が広くなり、既存の複合主キーでレコードが特定できなくなる問題などが起こりやすいらしい。
おそらくこの問題はDB設計を専門にしている方には、意味のない問題となるだろう。

しかし、自分の拙い設計では仕様変更が起こると考えると、サロゲートキーを使うのが無難だ。

参考

第3回 テーブル設計のグレーゾーン~毒と薬は紙一重 (4)サロゲートキーVSナチュラルキー:SQLアタマアカデミー|gihyo.jp … 技術評論社

漢(オトコ)のコンピュータ道: ナチュラルキーとサロゲートキーについての議論

複合主キー「否定派」と「許容派」の論争: 設計者の発言

複合主キーを避けるべき理由 – 虎塚

スポンサーリンク
ad
ad

シェアする

  • このエントリーをはてなブックマークに追加

フォローする

スポンサーリンク
ad