主キーと主要属性の定義 Quiz: ER図でのエンティティの位置 • ER図の役割は，エンティティやその間の関連を正確に第三者に伝えることが第一であるから，ER図が詳細化されて図が分かりにくくなってくれば，エンティティの配置を変えて分かりやすいようにするべきである． ○か×かエンティティの配置ルール • いままでのER図では – イベント系エンティティは発生順に左から右へ – リソース系エンティティはその周りへ – リレーションシップを表す線が交差しないように • 最初に決めた配置ルールはできるかぎり，途中で変えない．エンティティの配置ルールの例 • ２つの方針 – リソースを上に，イベントを下に – イベントを発生順に並べる． • イベントに付帯するリソースを回りに配置 • リソースの中は，人，物，顧客，金銭などのタイプごとに分けて配置 • 数が多くなれば，サブジェクトごとに図を分けるサブジェクト（図５－１）配置ルールは指針 • ルールがないと… – 複数のモデラが分担してモデリングする場合，モデラにより異なる配置の図ができ，統合が困難． • ルールに厳格になりすぎると… – 線が交差し分かりにくい．それでは元も子もない． • どこまで拘るかはセンスの問題 • ルールを指針として設け，守るように努める． – 異なる配置を取ると印象が変わる – 混乱を避けるため，配置はできるだけ変えないイメージが変わる例（イベントとリソースは色分け）イメージが変わる例主要な属性の定義切り出したエンティティを具体化しよう • 主要な属性をエンティティに追加 • ここで実施するのは，あくまでトップダウン – 「この属性はあるはずだ」でよい – すべての属性を見切るのが目的でない – 属性名もDB構築時の正確性は必要ない． • 正式な属性名はネーミング規則に則って付けるべき • 仮の名前を付けておく Quiz: 正確な名前を付けないのは？ • トップダウン・モデリングで正確な名前をつけないのはなぜ？ ○ ① 詳細に拘らず，まずは全体を一望する図をつくることが肝心だから ② 正確な名前を付けるためのソフトウェアが開発されているから ③ 後のモデリングにより，名前が修正される可能性があり，いま名前で悩むのは時間の無駄だから前回の図４－１２を書籍販売サイトの画面を見ながらエンティティの具体化をしてみるエンティティの属性として思いつくのは「思いつく」でよい • 「商品」エンティティでは ISBN，作者，ページ数，価格，刊行日，などなど • 「顧客」エンティティでは Emailアドレス，電話番号，住所，顧客名などなど各エンティティの具体的イメージを大まかにつかむことが重要主キー候補の選定 • 主キー – エンティティ内のインスタンスを一意に識別する属性 • Quiz: 「データベース」の教科書では主キー候補のことを – 候補キー – キー候補 – キー候補属性正解は候補キー主キー選定の手順 • 抽出した属性の中から主キー候補を選択 • その中から選定基準に則って１つに絞る • 最初に抽出した属性（の組合せ）だけではうまくいかないときは， – 新たなキー属性をデータベース管理者がつくる代理キー（Surrogate Key）: データベース管理者がつくるコードのこと主キーの選定基準 • 値が変わらないもの • できるだけ桁数の少ないもの • 複合キーの場合，連結が多くないもの – せいぜい，５つまで • 必ず存在するもの – NULL を許さない [補助] 値が変わると？NULLなら？ • 値が変わると， – そのエンティティを参照している部分を全て書き換える必要がある． – 実質的にデータベースの作り直りが必要 • NULLを許してしまうと – 主キーは，インスタンスを一意に識別するキー – NULLだと，一意に識別できない「顧客」エンティティの例 • 短いものとしてはemailアドレス • emailアドレスは変わる可能性あり（ex. プロバイダ変更） • 将来的には，顧客コードを作成．現時点ではemailアドレスのまま概念モデルでは具体的イメージ • 必要そうなエンティティを切り出す • エンティティとして存在するに違いないとおもう属性を切り出す • エンティティも属性も具体的イメージをつかめるものにとどめることが大切主キーとしてのコード • どうしてもだめなら，コードの使用もやむなし • 意味なしコードと意味ありコード意味なしコードと意味ありコード • コードにおまじないのような意味を持たせるのはモデルの美しさをなくすだけ • それでも意味ありコードのほうが用いられている． • 現実解 – 意味ありコードを用いる – 意味を示す属性は別に用意するモデルの見直し： • 概念モデルで，エンティティを抽出した段階では，間違いもある． • 属性を追加し，主キーを決めると間違いが見えてくる顧客とクレジット会社 • 顧客が複数のクレジット会社に加入していて，クレジット会社は一人の会員だけが加入していることになってしまっている． • 本当は，顧客とクレジット会社は，多対多の関係 • 「会員」エンティティを追加 [補助] どうして，クレジット会社の会員は一人？ • カージナリティを考えよう • ●がついている方が多，ついていない方が１顧客クレジット会社本当は多対多であった新しく会員を追加することによって・顧客が複数のクレジット会社のカードを持っていること・クレジット会社が複数の顧客をもっていることを示せる顧客，ショッピングカート，商品 • 誰のショッピングカートで，何を買ったのかが不明 • 誰のショッピングカートかを示すため， – ショッピングカートから顧客への依存関係 • 何を買ったかをしめすため – ショッピングカートから商品への非依存関係 • ショッピングカート明細を追加これだけでは，・誰のショッピングカートか・何を買おうとしているかが不明こうすると，・誰のショッピングカートに・どの商品を何個買おうとしているかが分かるいままでの修正をまとめると • 図５－９ • PPTに入りきらないので，教科書を見てください．