主キーと主要属性の定義.

Presentation on theme: "主キーと主要属性の定義."— Presentation transcript:

1 主キーと主要属性の定義

2 Quiz: ER図でのエンティティの位置 ER図の役割は，エンティティやその間の関連を正確に第三者に伝えることが第一であるから，ER図が詳細化されて図が分かりにくくなってくれば，エンティティの配置を変えて分かりやすいようにするべきである． ○か×か

3 エンティティの配置ルール いままでのER図では 最初に決めた配置ルールはできるかぎり，途中で変えない．
イベント系エンティティは発生順に左から右へ リソース系エンティティはその周りへ リレーションシップを表す線が交差しないように 最初に決めた配置ルールはできるかぎり，途中で変えない．

4 エンティティの配置ルールの例 ２つの方針 イベントに付帯するリソースを回りに配置
リソースを上に，イベントを下に イベントを発生順に並べる． イベントに付帯するリソースを回りに配置 リソースの中は，人，物，顧客，金銭などのタイプごとに分けて配置 数が多くなれば，サブジェクトごとに図を分ける

5 サブジェクト（図５－１）

6 配置ルールは指針 ルールがないと… ルールに厳格になりすぎると… どこまで拘るかはセンスの問題 ルールを指針として設け，守るように努める．
複数のモデラが分担してモデリングする場合，モデラにより異なる配置の図ができ，統合が困難． ルールに厳格になりすぎると… 線が交差し分かりにくい．それでは元も子もない． どこまで拘るかはセンスの問題 ルールを指針として設け，守るように努める． 異なる配置を取ると印象が変わる 混乱を避けるため，配置はできるだけ変えない

7 イメージが変わる例 （イベントとリソースは色分け）

8 イメージが変わる例

9 主要な属性の定義 切り出したエンティティを具体化しよう 主要な属性をエンティティに追加 ここで実施するのは，あくまでトップダウン
「この属性はあるはずだ」でよい すべての属性を見切るのが目的でない 属性名もDB構築時の正確性は必要ない． 正式な属性名はネーミング規則に則って付けるべき 仮の名前を付けておく

10 Quiz: 正確な名前を付けないのは？ トップダウン・モデリングで正確な名前をつけないのはなぜ？
詳細に拘らず，まずは全体を一望する図をつくることが肝心だから 正確な名前を付けるためのソフトウェアが開発されているから 後のモデリングにより，名前が修正される可能性があり，いま名前で悩むのは時間の無駄だから ○

11 前回の図４－１２を 書籍販売サイトの画面を見ながら エンティティの具体化をしてみる

12

13 エンティティの属性として思いつくのは 「思いつく」 でよい 「商品」エンティティでは 「顧客」エンティティでは
「思いつく」　　でよい 「商品」エンティティでは ISBN，作者，ページ数，価格，刊行日， などなど 「顧客」エンティティでは アドレス，電話番号，住所，顧客名 各エンティティの具体的イメージを　大まかにつかむ　ことが重要

14 主キー候補の選定 主キー Quiz: 「データベース」の教科書では主キー候補のことを エンティティ内のインスタンスを一意に識別する属性
候補キー キー候補 キー候補属性 正解は　　候補キー

15 主キー選定の手順 抽出した属性の中から主キー候補を選択 その中から選定基準に則って１つに絞る
最初に抽出した属性（の組合せ）だけではうまくいかないときは， 新たなキー属性をデータベース管理者がつくる 代理キー（Surrogate Key）: データベース管理者がつくるコードのこと

16 主キーの選定基準 値が変わらないもの できるだけ桁数の少ないもの 複合キーの場合，連結が多くないもの 必ず存在するもの せいぜい，５つまで
　NULL　を許さない

17 [補助] 値が変わると？NULLなら？ 値が変わると， NULLを許してしまうと
そのエンティティを参照している部分を全て書き換える必要がある． 実質的にデータベースの作り直りが必要 NULLを許してしまうと 主キーは，インスタンスを一意に識別するキー NULLだと，一意に識別できない

18 「顧客」エンティティの例 短いものとしてはemailアドレス emailアドレスは変わる可能性あり（ex. プロバイダ変更）

19 概念モデルでは具体的イメージ 必要そうな エンティティを切り出す エンティティ として存在するに違いない とおもう属性を切り出す
必要そうな　エンティティを切り出す エンティティ　として存在するに違いない　とおもう属性を切り出す エンティティも属性も 　具体的イメージをつかめるものにとどめる 　ことが大切

20 主キーとしてのコード どうしてもだめなら，コードの使用もやむなし 意味なしコードと意味ありコード

21 意味なしコードと意味ありコード コードにおまじないのような意味を持たせるのはモデルの美しさをなくすだけ
それでも意味ありコードのほうが用いられている． 現実解 意味ありコードを用いる 意味を示す属性は別に用意する

22 モデルの見直し： 概念モデルで，エンティティを抽出した段階では，間違いもある． 属性を追加し，主キーを決めると間違いが見えてくる

23 顧客とクレジット会社 顧客が複数のクレジット会社に加入していて，クレジット会社は一人の会員だけが加入していることになってしまっている．
本当は，顧客とクレジット会社は，多対多の関係 「会員」エンティティを追加

24 [補助] どうして，クレジット会社の会員は一人？
カージナリティを考えよう ●がついている方が多，ついていない方が１ 顧客 クレジット会社

25 本当は多対多であった 新しく会員を追加することによって ・顧客が複数のクレジット会社のカードを持っていること ・クレジット会社が複数の顧客をもっていること を示せる

26 顧客，ショッピングカート，商品 誰のショッピングカートで，何を買ったのかが不明 誰のショッピングカートかを示すため，
ショッピングカートから顧客への依存関係 何を買ったかをしめすため ショッピングカートから商品への非依存関係 ショッピングカート明細を追加

27 これだけでは， ・誰のショッピングカートか ・何を買おうとしているか が不明 こうすると， ・誰のショッピングカートに ・どの商品を何個 買おうとしているかが分かる

28 いままでの修正をまとめると 図５－９ PPTに入りきらないので，教科書を見てください．