DB Design Study for Beginners

Slide 1

Slide 1 text

%#ઃܭೖ໳ givery Inc. ⼩小⽥田崇之 2014/08/27

Slide 2

Slide 2 text

⾃自⼰己紹介 p ⼩小⽥田崇之 (おだたかゆき) p givery Inc. 内定者 p 実は⼤大学4年年だったりします p 実は24歳だったりします p 実は午年年です 2014/08/27

Slide 3

Slide 3 text

今回話す事 p データベースの必要性 p 正規化 p データベース設計の時に気をつける事とか 2014/08/27

Slide 4

Slide 4 text

今⽇日話さない事 p インデックスについて p トランザクションについて p ⼤大規模開発の時のDBサーバー構築 2014/08/27

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

Slide 7

Slide 7 text

なんでなん？ 2014/08/27

Slide 8

Slide 8 text

じゃぁCSVでの管理理を考えよう 2014/08/27

Slide 9

Slide 9 text

お題: 簡易易ツイッター「SIMPLE TWITTER」を作ろう 2014/08/27

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

でもその前に 2014/08/27

Slide 12

Slide 12 text

p 今から⾒見見せる項⽬目はサービスのデータベースの設計としては酷いです p 理理由はあとで解説します p どこが酷いのか考えてみてね 2014/08/27

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

ちなみに p 今⾒見見せたデータの構造は酷いです． (⼤大事なことなので) p 何が酷いかは後でまた⾒見見てみましょう 2014/08/27

Slide 16

Slide 16 text

Simple Twitter を作ろう by CSV p まずはユーザー登録から p ユーザー登録はこんな感じかな？ n Users.csv を読み込む n 新規のユーザー情報を末尾に追加 n 終了了 p なんだ結構簡単じゃん 2014/08/27

Slide 17

Slide 17 text

Simple Twitter を作ろう by CSV p あ，でも重複登録されると困るな n Users.csv を読み込む n 同じ名前が無いかをチェック •  同じ名前が無ければ末尾に追加 •  同じ名前があればエラーを返す n 終了了 p まぁまぁいけるねぇ 2014/08/27

Slide 18

Slide 18 text

Simple Twitter を作ろう by CSV p 次はユーザー情報の更更新だ！ p 更更新の⼿手順はこんな感じかな？ n Users.csv を読み込む n 今ログインしてるユーザーの⾏行行を探す n その⾏行行の情報を⼀一部更更新して末尾に追加 n 元にあった⾏行行は削除する n 終了了 2014/08/27

Slide 19

Slide 19 text

あれ？データベース，いらないですやん． 2014/08/27

Slide 20

Slide 20 text

Simple Twitter を作ろう by CSV p じゃぁ次はツイートかな？ p 重複気にしなくて良良いから楽ちん♪ n Tweets.csvを読み込む n 末尾に新規のツイート追加 n 終了了 p おっしゃ次々〜～♪ 2014/08/27

Slide 21

Slide 21 text

ちょっと待って 2014/08/27

Slide 22

Slide 22 text

考えてますか？ 2014/08/27

Slide 23

Slide 23 text

あんなことや 2014/08/27

Slide 24

Slide 24 text

こんなことあったでしょう？ 2014/08/27

Slide 25

Slide 25 text

そう，こんなこと． 2014/08/27

Slide 26

Slide 26 text

同時アクセス・同時書き込み 2014/08/27

Slide 27

Slide 27 text

何が起きる？ p 同時書き込みされると？ n ⽚片⽅方が上書きされて，⽚片⽅方が無かった事に n 「あれ？ツイートしたのに・・・？」 p 対策は？ n 気にしない n ロック機能を実装する •  誰かが触ってる間は他の⼈人はアクセス禁⽌止！ 2014/08/27

Slide 28

Slide 28 text

同時書き込みイメージ p Tweets.csv読み込み p Tweets.csvへ書き込み p Tweets.csv保存完了了データが消える p Tweets.csv読み込み p Tweets.csvへ書き込み p Tweets.csv保存完了了データが残る⽅方 2014/08/27

Slide 29

Slide 29 text

ロック機能を使うと p メリット n 同時アクセスによる上書きの⼼心配は消える n 同時アクセスによる重複の⼼心配も消える p デメリット n 読み込みしたいだけの⼈人もアクセス禁⽌止に •  「あれ？タイムライン真っ⽩白？」 •  「やけにロード⻑⾧長くない？」 2014/08/27

Slide 30

Slide 30 text

Simple Twitterを作ろう by CSV p ⾃自分が作りたいのは簡易易ツイッター p 今作ってるのはファイルのロック機能 p ファイルのロック機能が無いとサービスとしては機能しなくなる p けど俺がしたいのそこじゃない 2014/08/27

Slide 31

Slide 31 text

Database を使う必要ってあるの？ p 正直，遊びで作るものには別にいらない 2014/08/27

Slide 32

Slide 32 text

でも… p 複数⼈人が利利⽤用するサービスを考えると n データの⼀一貫性 (ロック機能) n 検索索速度度の向上 (インデックス機能) n 障害からの復復旧 (トランザクション機能) p ⾊色々出てくる問題 p 全部⾃自分で実装するの？ 2014/08/27

Slide 33

Slide 33 text

なんで Database を使うのか？ p ⾃自分の作りたいサービスに注⼒力力するため 2014/08/27

Slide 34

Slide 34 text

Slide 35

Slide 35 text

コンパクトなデータベース 2014/08/27

Slide 36

Slide 36 text

正規化って？ p データの関係を整理理する事 p データを整理理して何が起きるか？ n 重複の排除 n データ量量の削減 n 検索索パフォーマンスの向上 2014/08/27

Slide 37

Slide 37 text

もう少し細かく説明すると正規化とは、データを⼀一元管理理するための理理論論です。 1データ1箇所の原則を実現するために、1970年年に E.F.Codd⽒氏がリレーショナルモデルの理理論論として提案しました。正規化の理理論論は、データの冗⻑⾧長性を排除し、更更新時の整合性を維持しやすくすることを⽬目指しています。具体的には、属性間の関連性を分析し、属性の最適なグループ化を図ることを⽬目的としています。⼀一般には第3正規化まで⾏行行えば⼗十分といわれていますが、本来は、あてはまる場合にはきちんと第5正規化まで⾏行行う必要があります。 2014/08/27

Slide 38

Slide 38 text

正規化に関わる⽤用語説明 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

Slide 39

Slide 39 text

正規化の⼿手順 p  ⾮非正規形のデータから n  繰り返しの排除 p  第1正規化 n  完全関数従属 p  第2正規化 n  推移従属の排除 p  第3正規化 n  ⾮非キー属性による関数従属の排除 p  ボイスコッド正規化 n  多値従属性の分解 p  第4正規化 n  情報無損失分解 p  第5正規化 2014/08/27

Slide 40

Slide 40 text

そしてこれが今の皆の状態 2014/08/27

Slide 41

Slide 41 text

⽤用語とかについては後で⾃自分で調べてみてください． 2014/08/27

Slide 42

Slide 42 text

⾮非正規形ユーザーメール購⼊入商品購⼊入⽇日商品価格 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

Slide 43

Slide 43 text

第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

Slide 44

Slide 44 text

第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 ユーザーテーブル購⼊入テーブル商品テーブル

Slide 45

Slide 45 text

Slide 46

Slide 46 text

良良いデータベースは美しい 2014/08/27

Slide 47

Slide 47 text

「良良い」の定義は変わるもの p 「速い事」を「良良い事」とする p 「拡張性の⾼高さ」を「良良い事」とする p 「データの保証」を「良良い事」とする 2014/08/27

Slide 48

Slide 48 text

p 今回は拡張性に重きを置いて解説します（設計が⼀一番関わる領領域だから） 2014/08/27

Slide 49

Slide 49 text

さて， p 正規化の事を考えるとさっきの Twitter も少しは整理理されてる p でもまだダメ p さっきの Twitter の設計，何がダメ？ 2014/08/27

Slide 50

Slide 50 text

さっきのデータ構造 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

Slide 51

Slide 51 text

問題点 p username 使い回しすぎ n 同じデータが何回も出てくる n この設計では，usernameは実質変更更不不可能 p favorite のデータが無駄に⼤大きい n 元のツイートを削除した時の扱いが⼤大変 n ツイートをファボした⼈人を検索索すると⼤大変 2014/08/27

Slide 52

Slide 52 text

どうやって改善する？ p 皆で考えてみよう 2014/08/27

Slide 53

Slide 53 text

ちなみに俺の改善案 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

Slide 54

Slide 54 text

ちなみに俺の改善案 p Followers n followee_user_id n follower_user_id n followed_at p Favorites n tweet_id n user_id n favorated_at 2014/08/27

Slide 55

Slide 55 text

正規化以外に考える事 p テーブルや項⽬目の名前 p 容量量 (正規化を考えると⼤大体解消される) p 検索索 (インデックス) p フレームワークでは項⽬目として “id” がある事が前提とか 2014/08/27

Slide 56

Slide 56 text

今⽇日のおさらい p データベースを使おう n ⾃自分のサービス開発に集中するために p テーブルは出来るだけコンパクトに n プログラムを関数で⼩小分けにするのと⼀一緒 p まずは拡張性から． n 拡張性を考えてから，無駄な所は統合する 2014/08/27