Recommended
More Related Content
What's hot
What's hot (20)
Similar to 2019 若手技術者向け講座 DB設計
More from keki3
More from keki3 (20)
2019 若手技術者向け講座 DB設計
- 3. 目次 目次 • DB設計とは • 正規化 • 用語の整理 • 第一正規化 • 第二正規化 • 第三正規化 • 正規化の補足 • 実業務における正規化 • 主キーの決め方 • コードとIDの違い • IDの導入 • ビューの活用 • テーブル設計の手順 3
- 4. DB設計 4
- 5. DB設計 • DB設計とは • システムに合わせて最適なデータの管理が行えるようにテーブルやイ ンデックスを設計していく作業のことです。 • DB設計が上手にできていない場合 • パフォーマンスが低下する • データ間での整合性が取れなくなる • サーバーの容量が足りなくなる といったことが起こる可能性があります。 • DB設計は主に論理設計と物理設計に分かれます。 • 今回は論理設計の中のテーブル設計について学習します。 5
- 8. 正規化 • 正規化とは • 論理的に矛盾が生じないようにデータの関係性を整理していくこと。 • 第一正規化、第二正規化、第三正規化、ボイスコッド正規化、第四正 規化、第五正規化までの手順がある。 • しかし、第三正規化まで実施すれば、結果的に第五正規形までなされ ていることがほとんどなので、通常は第三正規化までしか紹介されて いません。 8
- 9. 正規化 • 正規化の目的 • 「One Fact In One Place」 • 「1つの事実は1つの場所へ」という意味。正規化の本質を表している 言葉。 • 正規化の目的は、データの重複を無くして、最小限のデータで必要な アウトプットが構成できるようになること。 9
- 10. 正規化 • 用語の整理（キー） • 候補キー • 1行を特定するための列（カラム）の組み合わせのこと。 • 主キー（プライマリーキー） • 候補キーから一つ選んだもの。 • 一つのリレーションにつき1つ存在する。 • 一般的にはIDが主キーとなる場合が多い。 • 非キー • 候補キーでも主キーでもない列のこと。 10
- 11. 正規化 • 用語の整理（関数従属） • 関数従属 • ある値がから別の値が特定できる状態のことです。 • 例えば、商品コードが決まれば商品名称が決まる場合、「商品名称は商品コード に関数従属している」と言います。 • 部分関数従属 • 候補キーの一部に関数従属している状態 • 完全関数従属 • 候補キーの全て列に関数従属している状態 • 推移関数従属 • 推移的に候補キーに従属している状態 11 詳しくは DB設計_補足資料.xlsx の「関数従属」シート を参照
- 12. 正規化 • 第一正規化 • 繰り返しを排除すること。 • 第一正規化されたリレーションを第一正規形呼ぶ。 • 第一正規化されていない状態を、非正規形と呼ぶ。 12
- 13. 正規化 • 非正規形 • 以下のテーブルは、非正規形になっています。 • 繰り返しになっている項目はどれか。 • このテーブル構造の問題点は何か。 13 非正規形 講座番号 講座名 生徒指名 所属企業名 101 Java講座 山田太郎、鈴木次郎 株式会社A、株式会社B 102 PHP講座 坂田三郎 株式会社C 103 インフラ講座 山田太郎、坂田三郎、井上四郎 株式会社A、株式会社B、株式会社C
- 14. 正規化 • 第一正規化（例） 14 講座 第一正規形① 講座番号 講座名 出席番号1 生徒指名1 所属企業ID1 所属企業名1 出席番号2 生徒指名2 所属企業ID2 所属企業名2 出席番号3 生徒指名3 所属企業ID3 所属企業名3 101 Java講座 1 山田太郎 201 株式会社A 2 鈴木次郎 202 株式会社B 102 PHP講座 3 坂田三郎 203 株式会社C 103 インフラ講座 1 山田太郎 201 株式会社A 3 坂田三郎 203 株式会社C 4 井上四郎 201 株式会社A 講座 第一正規形② 講座番号 講座名 出席番号 生徒指名 所属企業ID 所属企業名 101 Java講座 1 山田太郎 201 株式会社A 101 Java講座 2 鈴木次郎 202 株式会社B 102 PHP講座 3 坂田三郎 203 株式会社C 103 インフラ講座 4 井上四郎 201 株式会社A 103 インフラ講座 3 坂口三郎 203 株式会社C 103 インフラ講座 1 山田太郎 201 株式会社A
- 15. 正規化 • 第二正規化 • 部分関数従属を無くすこと。 • 第二正規化された状態を、第二正規形と呼ぶ。 • 全ての非キー属性が候補キーに完全関数従属している状態。 • 簡単に言うと、主キーの一部のカラムによって決まるカラムがある場 合は、第二正規形になっていないと言える。 15
- 16. 正規化 • 第二正規化 • 部分関数従属している項目はどれか • このテーブル構造（第一正規形）における問題点は何か 16 講座 第一正規形 講座番号 講座名 出席番号 生徒指名 所属企業ID 所属企業名 101 Java講座 1 山田太郎 201 株式会社A 101 Java講座 2 鈴木次郎 202 株式会社B 102 PHP講座 3 坂田三郎 203 株式会社C 103 インフラ講座 4 井上四郎 201 株式会社A 103 インフラ講座 3 坂口三郎 203 株式会社C 103 インフラ講座 1 山田太郎 201 株式会社A
- 17. 正規化 • 第二正規化（例） • 第二正規形 17 受講講座 講座番号 出席番号 101 1 101 2 102 1 103 1 103 4 103 5 講座 講座番号 講座名 101 Java講座 102 PHP講座 103 インフラ講座 生徒 出席番号 名前 所属企業ID 所属企業名 1 山田太郎 201 株式会社A 2 鈴木次郎 202 株式会社B 3 坂田三郎 203 株式会社C 4 井上四郎 201 株式会社A
- 18. 正規化 • 第三正規化 • 推移関数従属をなくすこと。 • 第三正規化された状態を、第三正規形と呼ぶ。 18
- 19. 正規化 • 第三正規化 • 推移関数従属している項目はどれか • このテーブル構造（第二正規形）における問題点は何か 19 生徒 出席番号 名前 所属企業ID 所属企業名 1 山田太郎 201 株式会社A 2 鈴木次郎 202 株式会社B 3 坂田三郎 203 株式会社C 4 井上四郎 201 株式会社A
- 20. 正規化 • 第三正規化（例） • 第三正規形 20 生徒 出席番号 名前 所属企業ID 1 山田太郎 201 2 鈴木次郎 202 3 坂田三郎 203 4 井上四郎 201 企業 所属企業ID 所属企業名 201 株式会社A 202 株式会社B 203 株式会社C
- 21. 正規化 • 第三正規形（全体） 21 生徒 出席番号 名前 所属企業ID 1 山田太郎 201 2 鈴木次郎 202 3 坂田三郎 203 4 井上四郎 201 企業 所属企業ID 所属企業名 201 株式会社A 202 株式会社B 203 株式会社C 受講講座 講座番号 出席番号 101 1 101 2 102 1 103 1 103 4 103 5 講座 講座番号 講座名 101 Java講座 102 PHP講座 103 インフラ講座
- 24. 正規化 • 第三正規化以降の正規化 • 正規化は、理論的には第三正規化以降もあります。 • ボイス・コッド正規化 • 第四正規化 • 第五正規化 • の3つがあります。 • ただし、実業務においては、第三正規化まで行えば第五正規形の条件 も満たしていることがほとんどのため、一般にはほとんど行われませ ん。 24
- 25. 実業務における正規化 26
- 26. 正規化 • 実業務における正規化 • 以下のようなテーブル構造とデータがあったとします。 • これはテーブルは正規化されているでしょうか？ 27 商品マスタ 商品コード 商品名 単価 01001 商品A 100 01002 商品B 150 01003 商品C 200 売上 伝票番号 日付 顧客番号 商品コード 単価 数量 金額 00001 2018/9/1 00100 01001 100 15 1500 00002 2018/9/2 00200 01001 90 30 2700 00003 2018/9/2 00100 01002 150 20 3000 00004 2018/9/3 00200 01003 200 30 5000 次ページを見る前に 考えてみてください。
- 27. 正規化 • 実業務における正規化 • 単価の項目は商品マスタが持っているため、一見すると正規化されて いないように見える。 • しかし、よく見ると商品マスタの単価と異なる単価になっている伝票 が存在している。 • 事実としてそのようなことが起きるのであれば、それはデータとして 保持しておく必要がある。業務上必要になる項目なので、正規化され ていないわけではない。 28 商品マスタ 売上 商品コード 商品名 単価 伝票番号 日付 顧客番号 商品コード 単価 数量 金額 01001 商品A 100 00001 2018/9/1 00100 01001 100 15 1500 01002 商品B 150 00002 2018/9/2 00200 01001 90 30 2700 01003 商品C 200 00003 2018/9/2 00100 01002 150 20 3000 00004 2018/9/3 00200 01003 200 30 5000
- 28. 正規化 • 実業務における正規化 • 金額はどうでしょうか。通常、「金額 = 単価 × 数量」となるので、導 出項目ならば正規化の時点で省かれる。 • しかし、よく見ると「単価 × 数量 = 金額」となってないレコードが存 在している。 • 値引きなど、事実としてそうなる取引があった場合にはそれを記録し ておく必要がある。 • これも正規化されていないように見えて実は必要な項目なのです。 29 商品マスタ 売上 商品コード 商品名 単価 伝票番号 日付 顧客番号 商品コード 単価 数量 金額 01001 商品A 100 00001 2018/9/1 00100 01001 100 15 1500 01002 商品B 150 00002 2018/9/2 00200 01001 90 30 2700 01003 商品C 200 00003 2018/9/2 00100 01002 150 20 3000 00004 2018/9/3 00200 01003 200 30 5000
- 29. 正規化 • 実業務における正規化 • テーブル構造だけを見ると一見正規化されていないように見える項目 でも、じつはきちんと正規化されており、業務の都合で必要な項目で ある場合もあります。 • テーブル設計では正規化の理論だけにとらわれず、業務において必要 なデータかどうかをしっかりと見極めることが大切です。 30
- 30. ER図 31
- 31. ER図 • ER図 • テーブル同士の関連性を表す図としてER図があります。 • ERはEntity-Relationshipの略です。 • ER図にはいくつかの表記方法があります。有名なものは以下の2つ。 • IE記法 • IDEF1X記法 32
- 32. ER図 • IE（Information Engineering）記法 • James Martinという人が提唱したデータベースの設計に特化したER図 表記法です • リレーションシップが鳥の足のような形をしていることから、別名 「鳥の足記法」とも呼ばれています • IDEF1X記法に比べて、リレーションシップが直感的に理解しやすいと いう特徴を持っています • 多重度は下記のように表現します 33
- 33. ER図 • IE記法の記述例 34 エンティティ 部署、社員という実体があり、 部署と社員は「1 対 多」の関係性があるので、 1つの部署には、複数の社員が所属していて、 社員は、1つの部署に所属していることを表しています リレーションシップ FKとは、Foreign Keyの略で あり、外部キーのこと エンティティを線で上下に分け、 上には主キー、下には主キーで はないものを記述します を使うことにより、 多の関係性を表しています
- 34. ER図 • IDEF1X（Integration Definition）記法 • 米国標準技術研究所（NIST）が規格化した、データベースの設計に特 化した表記方法です • リレーションシップを「●」などで表現することが特徴です • IE記法より細かい表現ができますが、その分IE記法に比べて直感的な分 かりやすさは低くなります • 多重度は下記のように表現します 35
- 35. ER図 • IDEF1X記法の記述例 36 エンティティ 部署、社員という実体があり、 部署と社員は「1 対 多」の関係性があるので、 1つの部署には、複数の社員が所属していて、 社員は、1つの部署に所属していることを表しています リレーションシップ FKとは、Foreign Keyの略で あり、外部キーのこと エンティティを線で上下に分け、 上には主キー、下には主キーで はないものを記述します ●を使うことにより、 多の関係性を表しています
- 36. 演習問題（正規化） 37
- 37. 正規化 • 配布資料「DB設計_演習.xlsx」の中の演習１を実施してくださ い。 • 非正規形のテーブルを第三正規形にする演習です。 • 正規化する過程で主キーも適切に設定してください。 • また、正規化が完了したらER図を作成してください。 38
- 38. 主キーの決め方 39
- 40. 主キーの決め方 • コードとIDの違い • コードは「あだ名」。コードそのものに何かしらの意味がある。 • 企業によってコード体系が決まる。 • 変更される可能性がある。 • 企業の統合や組織改革などで、コード体系が変わる可能性は高い。 • IDは意味のない記号（通常は連番が多い） • 変更する必然性はない。 主キーを決める際には、未来永劫変わる可能性がないかどうか が大事。 つまり、主キーは、コードではなくIDを使用しましょう。 41
- 41. 主キーの決め方 • コードを主キーにすることの弊害 • 以下のようなコード体系で商品コードが決まっていたとします。 • この場合の問題点はなんでしょう。 42 商品コードのコード体系 頭2桁 商品の分類コード 後ろ3桁 分類毎の連番 商品マスタ 売上 商品コード 商品名 単価 伝票番号 日付 商品コード 数量 01001 商品A 100 00001 9月1日 01001 2 01002 商品B 150 00002 9月2日 01002 3 01003 商品C 200 00003 9月3日 01003 4 仕入 伝票番号 日付 商品コード 数量 00001 8月20日 01001 10 00002 8月20日 01002 10 00003 8月20日 01003 10
- 42. 主キーの決め方 • コードを主キーにすることの弊害 • 例えば、商品のアイテム数が増え、連番を4桁に変更する必要が出た とします。その場合、コード体系の変更に伴って関連するすべての テーブルで更新作業が必要になります。 43 商品コードのコード体系 頭2桁 商品の分類コード 後ろ4桁 分類毎の連番 商品マスタ 売上 商品コード 商品名 単価 伝票番号 日付 商品コード 数量 010001 商品A 100 00001 9月1日 010001 2 010002 商品B 150 00002 9月2日 010002 3 010003 商品C 200 00003 9月3日 010003 4 仕入 伝票番号 日付 商品コード 数量 00001 8月20日 010001 10 00002 8月20日 010002 10 00003 8月20日 010003 10
- 43. 主キーの決め方 • IDを導入する • 主キーにIDを導入した場合 44 商品マスタ 売上 商品ID 商品コード 商品名 単価 伝票番号 日付 商品ID 数量 1 01001 商品A 100 00001 9月1日 1 2 2 01002 商品B 150 00002 9月2日 2 3 3 01003 商品C 200 00003 9月3日 3 4 仕入 伝票番号 日付 商品ID 数量 00001 8月20日 1 10 00002 8月20日 2 10 00003 8月20日 3 10
- 44. 主キーの決め方 • IDを導入する • 主キーにIDを導入した場合 • 商品マスタ以外は商品コードを保持しない 45 商品マスタ 売上 商品ID 商品コード 商品名 単価 伝票番号 日付 商品ID 数量 1 01001 商品A 100 00001 9月1日 1 2 2 01002 商品B 150 00002 9月2日 2 3 3 01003 商品C 200 00003 9月3日 3 4 仕入 伝票番号 日付 商品ID 数量 00001 8月20日 1 10 00002 8月20日 2 10 00003 8月20日 3 10
- 45. 主キーの決め方 • IDを導入する • コード体系が変わっても変更対象は商品マスタのみなので、影響範囲 は少ない。 46 商品マスタ 売上 商品ID 商品コード 商品名 単価 伝票番号 日付 商品ID 数量 1 010001 商品A 100 00001 9月1日 1 2 2 010002 商品B 150 00002 9月2日 2 3 3 010003 商品C 200 00003 9月3日 3 4 仕入 伝票番号 日付 商品ID 数量 00001 8月20日 1 10 00002 8月20日 2 10 00003 8月20日 3 10
- 46. 主キーの決め方 • まとめ • 主キーには変更される可能性がないものを設定する。 • コードはあだ名。変更の可能性があるので主キーにはしない。 • 実際の運用ではすべてのテーブルにIDを設定して、それを主キーとす る。 • コードにはユニーク制約を付与して、アクセスパスとして利用する。 47
- 47. ビューの活用 • ビューの活用 • 正規化を実施すると、テーブルの数が増えます。 • データの整合性は保たれますが、アウトプットの際には結合が多く発 生します。 • 毎回結合のSQLを書くのが面倒な場合は、ビューを定義しておくと テーブルアクセスの記述が楽になりますので、有効に活用してくださ い。 48 -- ビューの定義 CREATE VIEW ビュー名 AS SELECT文
- 48. テーブル設計の手順 • テーブル設計の手順 1. 必要なデータの洗い出し 2. 正規化 • テーブルの洗い出し • 主キーの設定 • カラムの設定 49
- 49. 演習問題（実践編） 50
- 51. 解説 • 部門 • 名前のフリガナ • 複数の役職を持つ人、複数の部署に所属する人 • 部署変更の対応 • 住所の持ち方 • 備考の活用 52
- 52. 解説 • 部門 • 部門は通常階層構造を持ちます。（事業部、部、課など。） • そのような場合、上位部門IDを持つことで階層構造を定義できます。 53 部門 部門ID 部門名 上位部門ID
- 53. 解説 • 名前のフリガナ • 名刺は、人によっては名前にフリガナが降られていることもあるので、 フリガナのデータも保持しておくと便利。 • 半角カナか全角カナのどちらで保持するかは設計者の好み。 54
- 54. 解説 • 複数の役職を持つ人、複数の部署に所属する人 • 企業によって、または人によっては複数の役職を持つ人、または複数 の部署に所属する人がいるかもしれません。 • その場合は所属情報を別のテーブルで保持しておく必要があります。 55 部門 部門ID 部門名 上位部門ID 社員 社員ID 社員名 所属部門 所属部門ID 社員ID (FK) 部門ID (FK)
- 55. 解説 • 部署変更の対応 • 会社の中で部署が変更されてしまう場合もあります。 • 変更の履歴も管理したい場合はどうすればよいでしょうか。 56
- 56. 解説 • 部署変更の対応 • 履歴まで管理したい場合は、開始所属日と終了所属日、という日付を 持たせておくことで、過去の履歴まで管理できるようになります。 57 部門 部門ID 部門名 上位部門ID 社員 社員ID 社員名 所属部門 所属部門ID 社員ID (FK) 部門ID (FK) 開始所属日 終了所属日
- 57. 解説 • 住所の持ち方 • 名刺に記載された住所は一般に以下のような形になっている場合が多 いかと思います。 • この場合、テーブルで住所の情報を1つのカラムで持っていた場合、 アウトプットする際にプログラム側で文字をうまく切り取って改行す るなどの加工が必要になるため、面倒です。 • 住所１、住所２のように、複数のカラムに分けて持つことで、アウト プットする際に柔軟に対応できるようになります。 58 〒900-0000 沖縄県那覇市XXX 1-1-1 XXXXビル 5F
- 58. 解説 • 備考の活用 • 名刺は、人や企業によって記載する情報が異なるため、全部の情報を 事前に網羅しておくのは難しいです。 • そのような場合、「備考」のような何にでも使える汎用的なカラムを 用意しておくと便利です。 59
- 59. まとめ • まとめ • テーブル設計には絶対の正解はありません。 • データに矛盾が生じない、かつプログラムで扱いやすい（アウトプッ トしやすい）かを考慮した設計をしましょう。 • 正規化はあくまで矛盾のないテーブル設計するための手段です。業務 やプログラムのことも考慮した柔軟な設計を心掛けましょう。 • 最終的にアウトプットしやすいかどうかを考慮することが、良いテー ブル設計をするためのコツです。 60
- 60. テーブル設計の学習方法 • 最後に • テーブル設計はプログラミングに比べて経験を積む機会が少ないです。 • テーブル設計のコツを掴むには、名刺やレシートなど、普段の生活で 目にするシステムからアウトプットされたものかたテーブル定義を考 えることで慣れてきます。 • 正規化は情報処理試験のテキストでの勉強も有効です。 61
- 61. 参考図書 • 楽々ERDレッスン • 達人に学ぶDB設計 徹底指南書 62