« 勉強会:ユースケース実践ワークグループ | トップページ | 定例会から:ピザパーティ(初?) »

定例会から:サロゲートキーのススメ

データベースのテーブル設計を行う場合の「基本」にして、極めれば「奥義」とも成り得る(?!)基本テクニックの1つ、「サロゲートキー」についての話題がありました(IT-Tipsのコーナーで)。

自然キー(実在世界の要素そのままのキー。例:電話番号とか)は人間には優しい(分かり易い)が、仕様変更・拡張に弱いし、プログラム側での扱いが面倒な場合が多い。
つまりは、寿命の長い(と想定される)システムには、自然キーの採用は避けた方が良い。

この自然キーの弱点を回避する為に、システム内部で独自に割り付ける値(特別な理由が無ければシリアルな連続番号)を付けて間接的にマッピングする。
この場合の「システム内部で割り付ける」キーがサロゲート(代理)キーですね。

手法としての知識・実用経験が有っても、「サロゲート」という用語として知らなかったメンバーも何人かいました(私も知らんかった...)。

しかし、概念は知っていても、実務上のどのようなケースで、どう判断するか?
無闇にサロゲート化すれば、内部仕様的には分かり辛くなり、バグ発生率が高くなり、テストの効率も精度も低下します。
つまりはコストも上がるってことです。
当然ながらパフォーマンスも落ちますね。

また、最終的にドキュメント(ER図)をリバース作成しようとした場合にも、ツールによっては属性を正しく認識しなくなる場合も有るようです。

で、Tipsの発表をしてくれたメンバーからの出題、と言うか問い掛け。
「例えばメールアドレスのような、それ自体としてプライマリキーになりそうなフィールドで、関連付けを絶対に行わないと分かっている部分をサロゲート化するべきか?」

幾つか意見は出たんですが、「そのフィールドの内容が変化した(意味的な変化はしていない)としても、任意の1レコードを指し続けなければならない場合に対して、サロゲートキーを適用すべき」との指摘がありました。
なるほど、ごもっとも。

ご支援、宜しくお願いします!ブログランキング!

にほんブログ村 ベンチャーブログへこちらも宜しく!

|

« 勉強会:ユースケース実践ワークグループ | トップページ | 定例会から:ピザパーティ(初?) »

定例会、勉強会など」カテゴリの記事

コメント

はにさん、コメント有難う御座います!
仰るとおり、サロゲートキーを利用するデメリットも有りますね。

業務的な面から新規にDB設計を行うことが出来る(キーとなるコード体系などを含めて)場合で、望ましいコードルールの設計&運用が可能ならば、マスター系のDBでサロゲートキーを使うケースは少なかろうと思います。

逆に、例えば既存マスターDBが怪しいんだけどキー項目を入れ替えるわけにも行かないとか、或いはトランザクションDB(マスターに紐付くが3次的、4次的~で発生するようなレコード)の内部的な管理のアプローチの1つとして、「サロゲートキー」という選択肢が有るってことですよね(表現や理解が拙かったら申し訳ないです)。

投稿: | 2012年2月 6日 (月) 11時37分

サロゲートキーには、リレーション構成情報の欠落という問題があります。
これはサロゲートキーを構成する業務キー側に変更がある場合、
どの業務キーが変更されたか判断できないため、リレーションの再構築ができないという事象が発生します。

下記のようなテーブル構成にて
受注テーブル:受注ID、商品ID、納品日、数量
商品マスタ:商品ID、商品コード、適用開始日、適用終了日、単価

月中に都度受注が入力されて、請求時にさかのぼって単価が決まる
(マスタのレコードが追加され、元のレコードは短縮される)とすると、
受注テーブルの商品IDからだけではそれを判別できないため、
受注テーブルの商品IDの連動が別途必要になってしまいます。

仮に商品コードが変更されないことが保障できるならば、
ロジックの組みようもありますが、商品コードも変更される可能性があるなら
どちらが更新されたかはもはや構造上判別が不可能になってしまいます。

投稿: はに | 2012年2月 5日 (日) 23時09分

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 定例会から:サロゲートキーのススメ:

« 勉強会:ユースケース実践ワークグループ | トップページ | 定例会から:ピザパーティ(初?) »