極北データモデリングスマートフォン用の表示で見る極北データモデリングこの広告は、90日以上更新していないブログに表示しています。2014-08-27主キーが「圧倒的多数の関数従属性が成立しないことを保証する」ものならば、受注ヘッダに顧客名を置いてはならないのだろうかモデリング渡辺先生がミステリアスな記事をupしている。http://watanabek.cocolog-nifty.com/blog/2014/08/post-b7d8.htmlつまり主キー設計というものは、「いくつかの関数従属性が成立することを分析する仕事」というよりは、むしろ「圧倒的多数の関数従属性が成立しないことを保証する仕事」である。その責任の重大さがおわかりだろうか。情報処理試験なんかに出てくる主キー設計手順では、テーブル上の複数の候補キーから主キーを選択するのではなかったか。その他の属性」という関数従属性がテーブル内にあるのは普通のことではないのか。元記事のセミナーの例に倣って、こんな受注ヘッダを想定する。顧客番号)→顧客名が成り立つだろう。顧客番号)→顧客名も成り立ってしまう(元記事における"{a,d}→c"のケース)。この関数従属性が「禁じられている」と考えるなら、何らかの手当(顧客名か受注日時を外出しにするとか?)をしなくてはならないが、向こうの流派ではいったいどうするのだろうか。いう関数従属性は成り立っていないと考えている。顧客名を受注ヘッダ上に置いており、「必要なら顧客マスタから拾ってくればよいデータ」ではないと考えている。成り立つと思っている。これは我々の業界でいうマスタ/トランザクションの違いであり、オントロジーでいうendurant/perdurantの違いだ。イベント)は特定の時刻に固定されており、その属性は時刻を指定しなくては値を特定できない。して渡辺先生もこんなことわかってて書いていて、元記事の「主キー」を「候補キー」と読み替えればいいだけの話なのだろうか。内的・外的という考え方がある。ファットモデルになるのか生きているうちに自然キーvsサロゲートキー問題に決着を付けたい(1)事実と真実はどう違うか。裁判官のキャリブレーションについて月別アーカイブはてなブログをはじめよう!tgkさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。