タグ

ブックマーク / watanabek.cocolog-nifty.com (6)

  • 概念モデルと論理モデルの違い(前編) - 設計者の発言

    管理会計システムの開発ツール「FusionPlace」の開発者であり会計士でもある杉さんが、9月の「第19回関西IT勉強宴会」でたいへん興味深い発表をされた。それを聞いて、私の中で曖昧だった「概念データモデル」の位置づけがはっきりして、「論理データモデル」との違いが浮き彫りになった。この快適なスッキリ感をおすそわけしたい。 ■従来の「概念データモデル」の危うさ これまで「概念データモデル」という用語は「対象領域における重要なテーブルのみを示したデータモデル」くらいの意味で使われていた。1ページか2ページに収まるように重要なテーブルのみを置き、しばしばキーが省略された形で示される。一部を示すとたとえばこんな調子だ。 以前に書いた記事「危ういデータモデルを見破るコツ」で、概念データモデルと呼ばれる図面の上に「多対多」のテーブル関連が現れることを批判した。一部のテーブルを省略すれば必然的に「多

    概念モデルと論理モデルの違い(前編) - 設計者の発言
  • 危ういデータモデルを見破るコツ - 設計者の発言

    ひところよりもデータモデル(ER図)を作成することの重要性が理解されるようになったが、それでも形だけ整えられて納品されてしまうことがある。「納品しろと言われたからしかたなく作った」ようなモデルはヤバい。素人のイラストにもとづいて高層ビルを建てるような無茶を避けるために、危ういモデルを事前に見破るコツを知っておこう。 ただし、データモデルの「意味的な正しさ」は個別の問題なので立ち入らない。ここではその「見かけ」から危ういモデルを見破るための3つのポイントを紹介しよう。「キー設計が甘い」、「多対多を含んでいる」、「他の設計要素を支えない」といった兆候があれば注意したほうがいい。それぞれを説明しよう。 1.キー設計が甘い データモデルはデータ項目間の「関数従属性」と「ドメイン制約」を示すための図面である。それゆえに、キー属性がいい加減に設計されたモデルは役にたたない。キーはテーブルの存在証明のよ

    危ういデータモデルを見破るコツ - 設計者の発言
  • サロゲートキーは強制されるべきものではない - 設計者の発言

    複合主キーに代えてサロゲートキー(単独主キーの代替キー)を導入すべきかどうか。それはDB設計上の重要な判断事項である。なにしろレコードのアイデンティティである主キーの設定にかかわる問題だ。さまざまなメリットやデメリットを考慮してそれは判断される。その結果、サロゲートキーを導入することもあるし、しないこともある。 ところが、サロゲートキーを強制する(あるいはサロゲートキーを導入しないと開発しにくい)開発基盤がいくつか存在する。具体的には、全テーブルの識別子が"ID"等のフィールド名を持つ単独主キーであることが求められたりする。私に言わせれば、そういう開発基盤は「大盛を強制する牛丼屋」である。メニューにあるはずの「並」を頼むと、あれこれイヤガラセをされる牛丼屋。 この問題に関連して、「サロゲートキーを使わなかったから、ひどい目にあった」という開発者の声を聞いたことがあるかもしれない。心配はいら

    サロゲートキーは強制されるべきものではない - 設計者の発言
  • 設計者の発言−渡辺幸三ブログ

    2021年4月から、2020年以降の記事を含めて「はてなブログ」に引っ越しました。今後もよろしくお願いします。 設計者の発言(はてな版)

    設計者の発言−渡辺幸三ブログ
  • ナチュラルキーを主キーにしてはいけない - 設計者の発言

    定期的に複合主キーの話題が盛り上がるのは楽しい。好きな話題なので便乗しよう。 「複合主キーを許すべきかどうか」の議論に関して私が理解できないのが、なぜか「ナチュラルキーを主キー(一次識別子)に含めてはいけない」という話とセットで語られがちな点だ。もちろん、ナチュラルキーを主キーに含めてはいけない。だめ、ゼッタイ。しかしこれは複合主キーの必要性とは無関係な議論であって、複合主キーを回避すべき理由にはならない。 ■ナチュラルキーと人工キー ナチュラルキーについて、公開中の販売管理システムのモデルで説明しよう。まず、商品マスタの主キーは「内部商品№」である。これは、追加されるたびに自動的に発番されてセットされる項目で、ユーザの目には触れない「人工キー」だ。「Row ID」と思ってもらえばいい。 [商品] 内部商品№、品名、{品番}、... いっぽうユーザの目に触れる項目は、「二次識別子」とされて

    ナチュラルキーを主キーにしてはいけない - 設計者の発言
  • 「複合キー」と実装用フレームワーク - 設計者の発言

    テーブルの主キーの設定に関して「複合キーと代理キーのどちらが適切か」という議論がある。私の立場は明確で、 分析段階では必要に応じて複合キーを用いながらモデリングし、実装段階で環境の事情に応じて代理キーを導入すればよい。もちろん、モデルのとおりに実装することが許されるならば、それがいちばんよい。 というものだ。根拠を説明しよう。 以下のようなデータ要件があるとする。記号ではイメージしにくいという読者には、テーブルAが「社員」で、Cが「趣味」で、ACが「社員の趣味」と想像してもらえばよい。その場合の属性eは、各社員の各趣味に対する「好みの度合い(-2は大嫌い、2は大好き、とか)」くらいと考えてもらえばよい。要は a,b,c,d,e の5つの管理項目が見出され、項目間に b=F(a)、d=F(c)、e=F(a,c) の関数従属性が認められたという例だ。 [A] {a},  b + 100 aaa

    「複合キー」と実装用フレームワーク - 設計者の発言
  • 1