Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DB Design Study for Beginners

DMTC
August 27, 2014

DB Design Study for Beginners

DB設計入門で使った勉強会のスライド

DMTC

August 27, 2014
Tweet

More Decks by DMTC

Other Decks in Programming

Transcript

  1. ⾃自⼰己紹介 p ⼩小⽥田  崇之  (おだ  たかゆき)   p givery  Inc.  内定者  

    p 実は⼤大学4年年だったりします   p 実は24歳だったりします   p 実は午年年です 2014/08/27
  2. 今⽇日の内容:  Database  ⼊入⾨門 p ⾃自⼰己紹介   p なぜ  Database  は必要なのか?    

    p 正規化  :  Database設計の基礎知識識   p 良良い  Database  設計とは?   2014/08/27
  3. 今⽇日の内容:  Database  ⼊入⾨門 p ⾃自⼰己紹介   p なぜ  Database  は必要なのか?    

    p 正規化  :  Database設計の基礎知識識   p 良良い  Database  設計とは?   2014/08/27
  4. Simple  Twitterを作ろう  by  CSV p 保存する情報   n ユーザー情報  →  Users.csv  

    n ツイート情報  →  Tweets.csv   n フォロー情報  →  Followers.csv   n お気に⼊入り情報  →  Favorites.csv   p とりあえずこんな感じかな?   p 次のスライドで   それぞれの項⽬目をリストアップしてみます   2014/08/27
  5. Users.csv  /  Tweets.csv p ユーザー情報   n username   n mail   n password

      n register_date   p ツイート情報   n username   n tweet   n tweet_datetime   2014/08/27
  6. Followers.csv  /  Favorites.csv p お気に⼊入り情報   n favorite_tweet   n tweeted_username   n favorited_username

      n favorated_datetime   p フォロー情報   n followee_username   n follower_username   n followed_datetime 2014/08/27
  7. Simple  Twitter  を作ろう  by  CSV p まずはユーザー登録から   p ユーザー登録はこんな感じかな?   n Users.csv

     を読み込む n 新規のユーザー情報を末尾に追加   n 終了了   p なんだ結構簡単じゃん   2014/08/27
  8. Simple  Twitter  を作ろう  by  CSV p あ,でも重複登録されると困るな   n Users.csv  を読み込む n 同じ名前が無いかをチェック

      •  同じ名前が無ければ末尾に追加   •  同じ名前があればエラーを返す   n 終了了   p まぁまぁいけるねぇ 2014/08/27
  9. Simple  Twitter  を作ろう  by  CSV p 次はユーザー情報の更更新だ!   p 更更新の⼿手順はこんな感じかな?   n Users.csv

     を読み込む n 今ログインしてるユーザーの⾏行行を探す   n その⾏行行の情報を⼀一部更更新して末尾に追加   n 元にあった⾏行行は削除する   n 終了了   2014/08/27
  10. 今⽇日の内容:  Database  ⼊入⾨門 p ⾃自⼰己紹介   p なぜ  Database  は必要なのか?    

    p 正規化  :  Database設計の基礎知識識   p 良良い  Database  設計とは?   2014/08/27
  11. もう少し細かく説明すると 正規化とは、データを⼀一元管理理するための理理論論です。   1データ1箇所の原則を実現するために、1970年年に E.F.Codd⽒氏がリレーショナルモデルの理理論論として提 案しました。   正規化の理理論論は、データの冗⻑⾧長性を排除し、更更新時 の整合性を維持しやすくすることを⽬目指しています。  

      具体的には、属性間の関連性を分析し、属性の最適 なグループ化を図ることを⽬目的としています。  ⼀一般 には第3正規化まで⾏行行えば⼗十分といわれていますが、 本来は、あてはまる場合にはきちんと第5正規化ま で⾏行行う必要があります。 2014/08/27
  12. 正規化に関わる⽤用語説明 p 関数従属性   n ある属性Aの値が決まると他の属性Bの値が⼀一意に決まる とき、「属性Bは  、属性Aに関数従属である」(A→B)   p 完全従属   n 2の属性A、Bの間でA→Bが成⽴立立し、Aが複数の属性の集合

    で成り⽴立立っている場合、Aのいかなる部分集合も関数従属 が成⽴立立しない状態を表します。   p 部分従属   n 関数従属が成⽴立立しているが、完全従属ではない状態を表し ます。   p 推移従属   n エンティティの3つの属性A、B、Cにおいて、「A→Bかつ B≠>AそしてB→Cである」とき「A→C」が得られ、既存の 関数従属から新たな関数従属が得られる状態を表します。 2014/08/27
  13. 正規化の⼿手順 p  ⾮非正規形のデータから   n  繰り返しの排除   p  第1正規化  

    n  完全関数従属   p  第2正規化   n  推移従属の排除   p  第3正規化   n  ⾮非キー属性による関数従属の排除   p  ボイスコッド正規化   n  多値従属性の分解   p  第4正規化   n  情報無損失分解   p  第5正規化   2014/08/27
  14. ⾮非正規形 ユーザー メール 購⼊入商品 購⼊入⽇日 商品価格 Dさん [email protected] AAA 2014/4/1

    700 BBB 2014/6/3 230 DDD 2014/8/27 1200 Gさん [email protected] CCC 2014/4/28 380 BBB 2014/8/27 230 Tさん [email protected] DDD 2014/3/21 1200 2014/08/27
  15. 第1正規化 ユーザー メール 購⼊入商品 購⼊入⽇日 商品価格 Dさん [email protected] AAA 2014/4/1

    700 Dさん [email protected] BBB 2014/6/3 230 Dさん [email protected] DDD 2014/8/27 1200 Gさん [email protected] CCC 2014/4/28 380 Gさん [email protected] BBB 2014/8/27 230 Tさん [email protected] DDD 2014/3/21 1200 2014/08/27
  16. 第3正規化 ユーザー メール Dさん [email protected] Gさん [email protected] Tさん [email protected] 2014/08/27

    購⼊入商品 商品価格 AAA 700 BBB 230 DDD 1200 CCC 380 ユーザー 購⼊入商品 購⼊入⽇日 Dさん AAA 2014/4/1 Dさん BBB 2014/6/3 Dさん DDD 2014/8/27 Gさん CCC 2014/4/28 Gさん BBB 2014/8/27 Tさん DDD 2014/3/21 ユーザーテーブル 購⼊入テーブル 商品テーブル
  17. 今⽇日の内容:  Database  ⼊入⾨門 p ⾃自⼰己紹介   p なぜ  Database  は必要なのか?    

    p 正規化  :  Database設計の基礎知識識   p 良良い  Database  設計とは?   2014/08/27
  18. さっきのデータ構造 p ユーザー情報   n username   n mail   n password   n register_date

      p ツイート情報   n username   n tweet   n tweet_datetime   p お気に⼊入り情報   n favorite_tweet   n tweeted_username   n favorited_username   n favorated_datetime p フォロー情報   n followee_username   n follower_username   n followed_datetime 2014/08/27
  19. 問題点 p username  使い回しすぎ   n 同じデータが何回も出てくる   n この設計では,usernameは実質変更更不不可能   p favorite  のデータが無駄に⼤大きい

      n 元のツイートを削除した時の扱いが⼤大変   n ツイートをファボした⼈人を検索索すると⼤大変   2014/08/27
  20. ちなみに俺の改善案 p Users   n id   n username   n mail   n password

      n created_at   p Tweets   n id   n user_id   n tweet   n tweeted_at   2014/08/27