データモデリング正規化 Quiz 正規化の本質とは • ① • ② • ③ • ④ 主キーをできるだけ減らす 1つの事実は1箇所で管理主キーと外部キーの一貫性を崩さないエンティティをできるだけ減らすその心は？ • 1箇所で管理しないと修正時にあっちこっちを修正する必要があるので、データ不整合を起こしやすい [補助] 1箇所で管理しないと… • 「会員住所」を「会員都道府県」、「会員市町村」、「会員地区番地名」にわけるとする会員住所会員住所会員住所分散した箇所すべてで修正会員住所会員住所 1箇所の修正でOK 正規化 Quiz: 正規化を意味づける関係データベースでの重要な概念とは • 直列化可能性 • 関数従属性 • データ独立性正規化 • 関数従属性に着目して正規化 • Quiz ：関係Rのスキーマ内の属性の集合Xと Yについて、YがXに関数従属するとは？ ①– Y から X に依存関係があること ②– X の値により Y の値が一意に決まること ③– Yの値を決定する関数がXの値を決定する関数より導出できること一意に決まるなら，一元管理ができるはず正規化の第１ステップ繰り返し項目を取り除け「注文内容」エンティティにおいて – 商品購入数量、注文商品名、書籍種別、商品購入単価は複数存在する可能性 • これらを「注文明細」エンティティにまとめる – 「注文明細」から「注文内容」へ依存関係 – 「注文内容」内の商品コードごとに一意に決まる • 注文番号と商品コードが主キーとなる初期モデルをみてみますと •1回の注文で、複数の書籍を購入する場合、これらは複数存在する。 •注文明細として分離させる •注文明細の主キー •１つの注文は注文番号で •各種類の商品は商品コードで正規化の第１ステップ（続き） • 「商品」エンティティにおいて、著者は複数存在する可能性 – 「書籍著者」エンティティを作る – 著者の識別のため、「著者連番」属性を含める • 「書籍書評」も複数存在する可能性 – 「書籍書評」エンティティを作る • エンティティ「商品」の特化として「書籍」 – 将来の発展系のため正規化の第１ステップ（また続き） • 「商品」エンティティ内の属性「商品在庫量」 – 在庫量は倉庫（配送センタ）単位でもつ – エンティティ「配送センタ」と「商品在庫」を作る – 「商品在庫」は「商品」と「配送センタ」に依存 • エンティティ「ショッピングカート」内の属性 – 「カート合計金額」以外は商品単位で複数存在する – 「ショッピングカート明細」エンティティを作る Quiz:エンティティ「ショッピングカート」と「注文内容」は同じ属性に見える． • エンティティ「ショッピングカート」と「注文内容」は「商品名」、「数量」、「購入単価」という同じ属性を持っているように見える．なぜ，これらを分けるのか？ ① 本当は違う属性だから ② ユーザから見やすさを追求するため ③ 性能が良くなるから – 実際には、購入候補と、購入すると決めたものの違い – よって、同一にはできない。未確定分類以上をまとめると図７－５正規化の第２ステップ複合キーの一部に関数従属する属性は別のエンティティとせよ • 「注文明細」エンティティにおいて – 属性「注文商品名」、「書籍種別」は、複合キーの一部の「商品コード」（つまり、書籍）から一意に決まる属性 – エンティティ「書籍」をつくり「注文明細」が依存すればよい – 今回の場合、エンティティ「書籍」はすでにある。 • 複合キーの一部に従属する属性があるということは – 複合キーの一部を主キーとし、これら従属する属性からなるエンティティが本来なら存在するということ – このエンティティを別に作って、１箇所で管理する。本来は、書籍を見ればわかる情報「ショッピングカート明細」の中の属性「カート書籍名」についても同様正規化の第３ステップ主キー以外の項目に依存する属性は別のエンティティとせよ • 「注文内容」エンティティにおいて – 属性「商品注文者」、「顧客番号」は、自らの主キー「注文番号」でなく、注文した顧客から決まる属性 – エンティティ「顧客」に「注文内容」が依存すればよい • エンティティにとって、主キー以外の項目に依存する項目があるということは、これら項目は別エンティティで既に定義されているということ主キー以外の項目に依存する項目は別エンティティで既に定義されているはず。そのエンティティがなければ作るべき関数従属以外の観点からの正規化 • これまでの正規化は、同じ主キーのみに依存するデータ項目を１つのエンティティにまとめる作業 • 関数従属と別に、意味を考えた正規化も必要 – 導出項目 – データ発生や更新のタイミング（次章） – 登録方法の違い導出項目 • その値が、別項目の値から計算される項目 • 正規化の観点からは削除すべきであるが、計算が自動化できるなら残すべき • 特に別エンティティ内の項目値を使う場合は残したほうがDBの管理が容易 [例] 「注文内容」について • 「商品請求金額」は削除 – 同一エンティティ内の「商品購入合計」＋「購入消費税」 • この計算に使った「商品購入合計」は残す – 「注文明細」エンティティの複数の「商品購入金額」の合計 [補助] 金額の計算 • 「商品請求金額」は削除 – 同一エンティティ内の「商品購入合計」＋「購入消費税」 • この計算に使った「商品購入合計」は残す – 「注文明細」エンティティの複数ある「商品購入金額」の合計データの発生や更新のタイミング • 「注文内容」エンティティの「商品配送先」 – 「顧客」エンティティの住所がデフォルト値 – しかし、購入時に別のものに変更可能 • 別のエンティティ「商品配送先」を作る登録方法の違い • 書籍表紙写真は、画像データでRDBに直接載せるには得策でない。 • 別エンティティ「書籍画像」を作成し、画像ファイル名をRDBに登録以上をまとめた図７－１０