Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
DB Design Study for Beginners
Search
DMTC
August 27, 2014
Programming
0
110
DB Design Study for Beginners
DB設計入門で使った勉強会のスライド
DMTC
August 27, 2014
Tweet
Share
More Decks by DMTC
See All by DMTC
Web Server Study for Beginners
dmtc
0
79
Framework Study for Beginners
dmtc
0
49
リーダブルコード入門
dmtc
0
110
how to use "slack" in our Hackathon
dmtc
0
260
pitch_codeprep@ventureday
dmtc
0
52
ハッカソン用ピッチフォーマット
dmtc
1
610
Other Decks in Programming
See All in Programming
ふかぼれ!CSSセレクターモジュール / Fukabore! CSS Selectors Module
petamoriken
0
150
[Do iOS '24] Ship your app on a Friday...and enjoy your weekend!
polpielladev
0
110
Hotwire or React? ~アフタートーク・本編に含めなかった話~ / Hotwire or React? after talk
harunatsujita
1
120
Less waste, more joy, and a lot more green: How Quarkus makes Java better
hollycummins
0
100
Djangoの開発環境で工夫したこと - pre-commit / DevContainer
hiroki_yod
1
200
광고 소재 심사 과정에 AI를 도입하여 광고 서비스 생산성 향상시키기
kakao
PRO
0
170
Functional Event Sourcing using Sekiban
tomohisa
0
110
Quine, Polyglot, 良いコード
qnighy
4
650
Tauriでネイティブアプリを作りたい
tsucchinoko
0
380
as(型アサーション)を書く前にできること
marokanatani
10
2.8k
みんなでプロポーザルを書いてみた
yuriko1211
0
280
C++でシェーダを書く
fadis
6
4.1k
Featured
See All Featured
Facilitating Awesome Meetings
lara
50
6.1k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
126
18k
How to train your dragon (web standard)
notwaldorf
88
5.7k
Producing Creativity
orderedlist
PRO
341
39k
Designing on Purpose - Digital PM Summit 2013
jponch
115
7k
Agile that works and the tools we love
rasmusluckow
327
21k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
93
16k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.7k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
For a Future-Friendly Web
brad_frost
175
9.4k
GitHub's CSS Performance
jonrohan
1030
460k
How To Stay Up To Date on Web Technology
chriscoyier
788
250k
Transcript
%#ઃܭೖ givery Inc. ⼩小⽥田 崇之 2014/08/27
⾃自⼰己紹介 p ⼩小⽥田 崇之 (おだ たかゆき) p givery Inc. 内定者
p 実は⼤大学4年年だったりします p 実は24歳だったりします p 実は午年年です 2014/08/27
今回話す事 p データベースの必要性 p 正規化 p データベース設計の時に気をつける事とか 2014/08/27
今⽇日話さない事 p インデックスについて p トランザクションについて p ⼤大規模開発の時のDBサーバー構築 2014/08/27
今⽇日の内容: Database ⼊入⾨門 p ⾃自⼰己紹介 p なぜ Database は必要なのか?
p 正規化 : Database設計の基礎知識識 p 良良い Database 設計とは? 2014/08/27
今⽇日の内容: Database ⼊入⾨門 p ⾃自⼰己紹介 p なぜ Database は必要なのか?
p 正規化 : Database設計の基礎知識識 p 良良い Database 設計とは? 2014/08/27
なんでなん? 2014/08/27
じゃぁCSVでの管理理を考えよう 2014/08/27
お題: 簡易易ツイッター 「SIMPLE TWITTER」を作ろう 2014/08/27
Simple Twitterを作ろう by CSV p 保存する情報 n ユーザー情報 → Users.csv
n ツイート情報 → Tweets.csv n フォロー情報 → Followers.csv n お気に⼊入り情報 → Favorites.csv p とりあえずこんな感じかな? p 次のスライドで それぞれの項⽬目をリストアップしてみます 2014/08/27
でもその前に 2014/08/27
p 今から⾒見見せる項⽬目はサービスの データベースの設計としては酷いです p 理理由はあとで解説します p どこが酷いのか考えてみてね 2014/08/27
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
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
ちなみに p 今⾒見見せたデータの構造は酷いです. (⼤大事なことなので) p 何が酷いかは後でまた⾒見見てみましょう 2014/08/27
Simple Twitter を作ろう by CSV p まずはユーザー登録から p ユーザー登録はこんな感じかな? n Users.csv
を読み込む n 新規のユーザー情報を末尾に追加 n 終了了 p なんだ結構簡単じゃん 2014/08/27
Simple Twitter を作ろう by CSV p あ,でも重複登録されると困るな n Users.csv を読み込む n 同じ名前が無いかをチェック
• 同じ名前が無ければ末尾に追加 • 同じ名前があればエラーを返す n 終了了 p まぁまぁいけるねぇ 2014/08/27
Simple Twitter を作ろう by CSV p 次はユーザー情報の更更新だ! p 更更新の⼿手順はこんな感じかな? n Users.csv
を読み込む n 今ログインしてるユーザーの⾏行行を探す n その⾏行行の情報を⼀一部更更新して末尾に追加 n 元にあった⾏行行は削除する n 終了了 2014/08/27
あれ?データベース,いらないですやん. 2014/08/27
Simple Twitter を作ろう by CSV p じゃぁ次はツイートかな? p 重複気にしなくて良良いから楽ちん♪ n Tweets.csvを読み込む
n 末尾に新規のツイート追加 n 終了了 p おっしゃ次々〜~♪ 2014/08/27
ちょっと待って 2014/08/27
考えてますか? 2014/08/27
あんなことや 2014/08/27
こんなこと あったでしょう? 2014/08/27
そう,こんなこと. 2014/08/27
同時アクセス ・ 同時書き込み 2014/08/27
何が起きる? p 同時書き込みされると? n ⽚片⽅方が上書きされて,⽚片⽅方が無かった事に n 「あれ?ツイートしたのに・・・?」 p 対策は? n 気にしない
n ロック機能を実装する • 誰かが触ってる間は他の⼈人はアクセス禁⽌止! 2014/08/27
同時書き込みイメージ p Tweets.csv読み込み p Tweets.csvへ書き込み p Tweets.csv保存完了了 データが消える p Tweets.csv読み込み
p Tweets.csvへ書き込み p Tweets.csv保存完了了 データが残る⽅方 2014/08/27
ロック機能を使うと p メリット n 同時アクセスによる上書きの⼼心配は消える n 同時アクセスによる重複の⼼心配も消える p デメリット n 読み込みしたいだけの⼈人もアクセス禁⽌止に
• 「あれ?タイムライン真っ⽩白?」 • 「やけにロード⻑⾧長くない?」 2014/08/27
Simple Twitterを作ろう by CSV p ⾃自分が作りたいのは簡易易ツイッター p 今作ってるのはファイルのロック機能 p ファイルのロック機能が無いと
サービスとしては機能しなくなる p けど俺がしたいのそこじゃない 2014/08/27
Database を使う必要ってあるの? p 正直,遊びで作るものには別にいらない 2014/08/27
でも… p 複数⼈人が利利⽤用するサービスを考えると n データの⼀一貫性 (ロック機能) n 検索索速度度の向上 (インデックス機能) n 障害からの復復旧
(トランザクション機能) p ⾊色々出てくる問題 p 全部⾃自分で実装するの? 2014/08/27
なんで Database を使うのか? p ⾃自分の作りたいサービスに注⼒力力するため 2014/08/27
今⽇日の内容: Database ⼊入⾨門 p ⾃自⼰己紹介 p なぜ Database は必要なのか?
p 正規化 : Database設計の基礎知識識 p 良良い Database 設計とは? 2014/08/27
コンパクトなデータベース 2014/08/27
正規化って? p データの関係を整理理する事 p データを整理理して何が起きるか? n 重複の排除 n データ量量の削減 n 検索索パフォーマンスの向上
2014/08/27
もう少し細かく説明すると 正規化とは、データを⼀一元管理理するための理理論論です。 1データ1箇所の原則を実現するために、1970年年に E.F.Codd⽒氏がリレーショナルモデルの理理論論として提 案しました。 正規化の理理論論は、データの冗⻑⾧長性を排除し、更更新時 の整合性を維持しやすくすることを⽬目指しています。
具体的には、属性間の関連性を分析し、属性の最適 なグループ化を図ることを⽬目的としています。 ⼀一般 には第3正規化まで⾏行行えば⼗十分といわれていますが、 本来は、あてはまる場合にはきちんと第5正規化ま で⾏行行う必要があります。 2014/08/27
正規化に関わる⽤用語説明 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
正規化の⼿手順 p ⾮非正規形のデータから n 繰り返しの排除 p 第1正規化
n 完全関数従属 p 第2正規化 n 推移従属の排除 p 第3正規化 n ⾮非キー属性による関数従属の排除 p ボイスコッド正規化 n 多値従属性の分解 p 第4正規化 n 情報無損失分解 p 第5正規化 2014/08/27
そしてこれが今の皆の状態 2014/08/27
⽤用語とかについては 後で⾃自分で調べてみてください. 2014/08/27
⾮非正規形 ユーザー メール 購⼊入商品 購⼊入⽇日 商品価格 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
第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
第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 ユーザーテーブル 購⼊入テーブル 商品テーブル
今⽇日の内容: Database ⼊入⾨門 p ⾃自⼰己紹介 p なぜ Database は必要なのか?
p 正規化 : Database設計の基礎知識識 p 良良い Database 設計とは? 2014/08/27
良良いデータベースは美しい 2014/08/27
「良良い」の定義は変わるもの p 「速い事」を「良良い事」とする p 「拡張性の⾼高さ」を「良良い事」とする p 「データの保証」を「良良い事」とする 2014/08/27
p 今回は拡張性に重きを置いて解説します (設計が⼀一番関わる領領域だから) 2014/08/27
さて, p 正規化の事を考えると さっきの Twitter も少しは整理理されてる p でもまだダメ p さっきの
Twitter の設計,何がダメ? 2014/08/27
さっきのデータ構造 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
問題点 p username 使い回しすぎ n 同じデータが何回も出てくる n この設計では,usernameは実質変更更不不可能 p favorite のデータが無駄に⼤大きい
n 元のツイートを削除した時の扱いが⼤大変 n ツイートをファボした⼈人を検索索すると⼤大変 2014/08/27
どうやって改善する? p 皆で考えてみよう 2014/08/27
ちなみに俺の改善案 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
ちなみに俺の改善案 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
正規化以外に考える事 p テーブルや項⽬目の名前 p 容量量 (正規化を考えると⼤大体解消される) p 検索索 (インデックス)
p フレームワークでは 項⽬目として “id” がある事が前提とか 2014/08/27
今⽇日のおさらい p データベースを使おう n ⾃自分のサービス開発に集中するために p テーブルは出来るだけコンパクトに n プログラムを関数で⼩小分けにするのと⼀一緒 p まずは拡張性から.
n 拡張性を考えてから,無駄な所は統合する 2014/08/27
以上! …質問ありますか? 2014/08/27
演習 2014/08/27
チャットアプリのDB設計を考えよう! 2014/08/27