| |
第1回 結果発表
多数のご応募、ありがとうございました！当選者の発表は賞品の発送に代えさせていただきます。 |
| |
|
| |
問題- 代理キーを使ったデータモデリング |
| |
↑クリックすると拡大
|
目的：
代理キー（Surrogate Key）の設定方法をマスターしましょう。
問題：
下図は代理キーを使用してないモデルです。
・正規化を行っていくと、キーが複合キー（複数）になってきます。
・ビジネス・ルールを読んでいくためには代理キーを使用しないでナチュラル・キーで表現した方が業務の理解が進みます。しかしながら、実装を考えると、主キーが複合キーの場合、キーの項目数が多くなると、処理上問題が出てきます。
・また、帳票などからデータモデルを作成する場合、代理キーの意識があまり出てきません。
・これを解決するために、代理キーを設定します。
代理キーを使用していない左記のモデルを代理キーを使用して記述してください
※この問題の.erwinファイルをダウンロードする場合はこちらをクリック！ (erwin_challenge1.zip 5KB) |
| |
|
| |
ベスト回答（ご応募者名：ペンタゴン様） |
| |
|
| |
ペンタゴン様からのコメント：
注文と注文明細エンティティが主キーが多かったため、代理キーを設定しました。
迷ったのが代理キーの名前です。
私たちの会社では、一目でわかるように通常代理キーの名前に接頭語をつけるのですが、みなさんどうされているものなのでしょうか。 |
| |
|
| |
株式会社メタジトリー 松本様による監修：
モデルはOKです。
少し、代理キーに関して考えてみました。
ボトムアップでデータモデルを作ってきた人たちには、この代理キーという概念がほとんどありません。ところが、トップダウンでデータモデルを作ると、この代理キーの概念が非常に重要になってきます。
2006年のDAMA（Data ManagementのConference）で、僕の友人のKaren Lopezさんが、提示したデータモデリングの議論の中でも取り上げられました。
代理キーかナチュラルキーかの課題です。
代理キーは、ある意味不自然（ビジネスルール上から見て）ですし、本来意味を持ちません。一方、ナチュラルキーは自然ではありますが、多くなると混乱を招きます。物理モデルから代理キーを使うと言う人もいます。レスポンスの問題からです。これらの問題は単純には解決しません。その際も大きな議論が起こりました。どこから、代理キーを使うか明確な指針はないでしょう。
代理キーの名称ですが、今回は「id」としましたが、代理キーであることを明確にするために「key」と言う名前を付けたりする人もいます。これもひとつの方法だと思います。
|
| |
|
| |
用語解説 |
| |
ナチュラルキー：
ビジネス上、実際に使用されるキー。
複合キー：
複数属性により構成される主キー。
代理キー：
複合主キーによる弊害を防ぐために、代理の主キーとして設定する単一のシリアル番号属性のこと。Surrogate Keyともいう。
正規化：
データの冗長性を排除し、依存関係を整理する作業のこと。結果的に「1 fact in 1 place」（一つの事実は一箇所のみに存在する）の状態となることを目的とする。 |
| |
|
| |
|
