DB Design Study for Beginners

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

Transcript

1. %#ઃܭೖ໳
   givery  Inc.   ⼩小⽥田  崇之 2014/08/27
2. ⾃自⼰己紹介 p ⼩小⽥田  崇之  (おだ  たかゆき)   p givery  Inc.  内定者   p 実は⼤大学4年年だったりします   p 実は24歳だったりします   p 実は午年年です 2014/08/27
3. 今回話す事 p データベースの必要性   p 正規化   p データベース設計の時に気をつける事とか   2014/08/27
4. 今⽇日話さない事 p インデックスについて   p トランザクションについて   p ⼤大規模開発の時のDBサーバー構築   2014/08/27
5. 今⽇日の内容:  Database  ⼊入⾨門 p ⾃自⼰己紹介   p なぜ  Database  は必要なのか？     p 正規化  :  Database設計の基礎知識識   p 良良い  Database  設計とは？   2014/08/27
6. 今⽇日の内容:  Database  ⼊入⾨門 p ⾃自⼰己紹介   p なぜ  Database  は必要なのか？     p 正規化  :  Database設計の基礎知識識   p 良良い  Database  設計とは？   2014/08/27
7. なんでなん？ 2014/08/27
8. じゃぁCSVでの管理理を考えよう 2014/08/27
9. お題:  簡易易ツイッター   「SIMPLE  TWITTER」を作ろう 2014/08/27
10. Simple  Twitterを作ろう  by  CSV p 保存する情報   n ユーザー情報  →  Users.csv   n ツイート情報  →  Tweets.csv   n フォロー情報  →  Followers.csv   n お気に⼊入り情報  →  Favorites.csv   p とりあえずこんな感じかな？   p 次のスライドで   それぞれの項⽬目をリストアップしてみます   2014/08/27
11. でもその前に 2014/08/27
12. p 今から⾒見見せる項⽬目はサービスの   データベースの設計としては酷いです   p 理理由はあとで解説します   p どこが酷いのか考えてみてね 2014/08/27
13. 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
14. 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
15. ちなみに   p 今⾒見見せたデータの構造は酷いです．   (⼤大事なことなので)   p 何が酷いかは後でまた⾒見見てみましょう 2014/08/27
16. Simple  Twitter  を作ろう  by  CSV p まずはユーザー登録から   p ユーザー登録はこんな感じかな？   n Users.csv  を読み込む n 新規のユーザー情報を末尾に追加   n 終了了   p なんだ結構簡単じゃん   2014/08/27
17. Simple  Twitter  を作ろう  by  CSV p あ，でも重複登録されると困るな   n Users.csv  を読み込む n 同じ名前が無いかをチェック   •  同じ名前が無ければ末尾に追加   •  同じ名前があればエラーを返す   n 終了了   p まぁまぁいけるねぇ 2014/08/27
18. Simple  Twitter  を作ろう  by  CSV p 次はユーザー情報の更更新だ！   p 更更新の⼿手順はこんな感じかな？   n Users.csv  を読み込む n 今ログインしてるユーザーの⾏行行を探す   n その⾏行行の情報を⼀一部更更新して末尾に追加   n 元にあった⾏行行は削除する   n 終了了   2014/08/27
19. あれ？データベース，いらないですやん． 2014/08/27
20. Simple  Twitter  を作ろう  by  CSV p じゃぁ次はツイートかな？   p 重複気にしなくて良良いから楽ちん♪   n Tweets.csvを読み込む n 末尾に新規のツイート追加   n 終了了   p おっしゃ次々〜～♪   2014/08/27
21. ちょっと待って 2014/08/27
22. 考えてますか？ 2014/08/27
23. あんなことや 2014/08/27
24. こんなこと  あったでしょう？ 2014/08/27
25. そう，こんなこと． 2014/08/27
26. 同時アクセス  ・  同時書き込み 2014/08/27
27. 何が起きる？ p 同時書き込みされると？   n ⽚片⽅方が上書きされて，⽚片⽅方が無かった事に   n 「あれ？ツイートしたのに・・・？」   p 対策は？   n 気にしない   n ロック機能を実装する   •  誰かが触ってる間は他の⼈人はアクセス禁⽌止！   2014/08/27
28. 同時書き込みイメージ p Tweets.csv読み込み   p Tweets.csvへ書き込み   p Tweets.csv保存完了了   データが消える   p Tweets.csv読み込み   p Tweets.csvへ書き込み   p Tweets.csv保存完了了   データが残る⽅方 2014/08/27
29. ロック機能を使うと p メリット   n 同時アクセスによる上書きの⼼心配は消える   n 同時アクセスによる重複の⼼心配も消える   p デメリット   n 読み込みしたいだけの⼈人もアクセス禁⽌止に •  「あれ？タイムライン真っ⽩白？」   •  「やけにロード⻑⾧長くない？」   2014/08/27
30. Simple  Twitterを作ろう  by  CSV p ⾃自分が作りたいのは簡易易ツイッター   p 今作ってるのはファイルのロック機能   p ファイルのロック機能が無いと   サービスとしては機能しなくなる   p けど俺がしたいのそこじゃない 2014/08/27
31. Database  を使う必要ってあるの？ p 正直，遊びで作るものには別にいらない   2014/08/27
32. でも… p 複数⼈人が利利⽤用するサービスを考えると   n データの⼀一貫性  (ロック機能)   n 検索索速度度の向上  (インデックス機能)   n 障害からの復復旧  (トランザクション機能)   p ⾊色々出てくる問題   p 全部⾃自分で実装するの？ 2014/08/27
33. なんで  Database  を使うのか？ p ⾃自分の作りたいサービスに注⼒力力するため   2014/08/27
34. 今⽇日の内容:  Database  ⼊入⾨門 p ⾃自⼰己紹介   p なぜ  Database  は必要なのか？     p 正規化  :  Database設計の基礎知識識   p 良良い  Database  設計とは？   2014/08/27
35. コンパクトなデータベース 2014/08/27
36. 正規化って？ p データの関係を整理理する事   p データを整理理して何が起きるか？   n 重複の排除   n データ量量の削減   n 検索索パフォーマンスの向上   2014/08/27
37. もう少し細かく説明すると 正規化とは、データを⼀一元管理理するための理理論論です。   1データ1箇所の原則を実現するために、1970年年に E.F.Codd⽒氏がリレーショナルモデルの理理論論として提 案しました。   正規化の理理論論は、データの冗⻑⾧長性を排除し、更更新時 の整合性を維持しやすくすることを⽬目指しています。     具体的には、属性間の関連性を分析し、属性の最適 なグループ化を図ることを⽬目的としています。  ⼀一般 には第3正規化まで⾏行行えば⼗十分といわれていますが、 本来は、あてはまる場合にはきちんと第5正規化ま で⾏行行う必要があります。 2014/08/27
38. 正規化に関わる⽤用語説明 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
39. 正規化の⼿手順 p  ⾮非正規形のデータから   n  繰り返しの排除   p  第1正規化   n  完全関数従属   p  第2正規化   n  推移従属の排除   p  第3正規化   n  ⾮非キー属性による関数従属の排除   p  ボイスコッド正規化   n  多値従属性の分解   p  第4正規化   n  情報無損失分解   p  第5正規化   2014/08/27
40. そしてこれが今の皆の状態 2014/08/27
41. ⽤用語とかについては   後で⾃自分で調べてみてください． 2014/08/27
42. ⾮非正規形 ユーザー メール 購⼊入商品 購⼊入⽇日 商品価格 Dさん d@d.asia AAA 2014/4/1 700 BBB 2014/6/3 230 DDD 2014/8/27 1200 Gさん g@g.co.jp CCC 2014/4/28 380 BBB 2014/8/27 230 Tさん t@t.com DDD 2014/3/21 1200 2014/08/27
43. 第1正規化 ユーザー メール 購⼊入商品 購⼊入⽇日 商品価格 Dさん d@d.asia AAA 2014/4/1 700 Dさん d@d.asia BBB 2014/6/3 230 Dさん d@d.asia DDD 2014/8/27 1200 Gさん g@g.co.jp CCC 2014/4/28 380 Gさん g@g.co.jp BBB 2014/8/27 230 Tさん t@t.com DDD 2014/3/21 1200 2014/08/27
44. 第3正規化 ユーザー メール Dさん d@d.asia Gさん g@g.co.jp Tさん t@t.com 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 ユーザーテーブル 購⼊入テーブル 商品テーブル
45. 今⽇日の内容:  Database  ⼊入⾨門 p ⾃自⼰己紹介   p なぜ  Database  は必要なのか？     p 正規化  :  Database設計の基礎知識識   p 良良い  Database  設計とは？   2014/08/27
46. 良良いデータベースは美しい 2014/08/27
47. 「良良い」の定義は変わるもの p 「速い事」を「良良い事」とする   p 「拡張性の⾼高さ」を「良良い事」とする   p 「データの保証」を「良良い事」とする   2014/08/27
48. p 今回は拡張性に重きを置いて解説します   （設計が⼀一番関わる領領域だから）   2014/08/27
49. さて， p 正規化の事を考えると   さっきの  Twitter  も少しは整理理されてる   p でもまだダメ   p さっきの  Twitter  の設計，何がダメ？   2014/08/27
50. さっきのデータ構造 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
51. 問題点 p username  使い回しすぎ   n 同じデータが何回も出てくる   n この設計では，usernameは実質変更更不不可能   p favorite  のデータが無駄に⼤大きい   n 元のツイートを削除した時の扱いが⼤大変   n ツイートをファボした⼈人を検索索すると⼤大変   2014/08/27
52. どうやって改善する？ p 皆で考えてみよう 2014/08/27
53. ちなみに俺の改善案 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
54. ちなみに俺の改善案 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
55. 正規化以外に考える事 p テーブルや項⽬目の名前   p 容量量  (正規化を考えると⼤大体解消される)   p 検索索  (インデックス)     p フレームワークでは   項⽬目として  “id”    がある事が前提とか 2014/08/27
56. 今⽇日のおさらい p データベースを使おう   n ⾃自分のサービス開発に集中するために   p テーブルは出来るだけコンパクトに   n プログラムを関数で⼩小分けにするのと⼀一緒   p まずは拡張性から．   n 拡張性を考えてから，無駄な所は統合する   2014/08/27
57. 以上！  …質問ありますか？ 2014/08/27
58. 演習 2014/08/27
59. チャットアプリのDB設計を考えよう！ 2014/08/27