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
50
ハッカソン用ピッチフォーマット
dmtc
1
600
Other Decks in Programming
See All in Programming
Synchronizationを支える技術
s_shimotori
1
150
Modern Angular: Renovation for Your Applications
manfredsteyer
PRO
0
210
CPython 인터프리터 구조 파헤치기 - PyCon Korea 24
kennethanceyer
0
250
AWS IaCの注目アップデート 2024年10月版
konokenj
3
3.1k
PHP でアセンブリ言語のように書く技術
memory1994
PRO
1
150
カラム追加で増えるActiveRecordのメモリサイズ イメージできますか?
asayamakk
4
1.6k
Java ジェネリクス入門 2024
nagise
0
610
Server Driven Compose With Firebase
skydoves
0
400
Dev ContainersとGitHub Codespacesの素敵な関係
ymd65536
1
130
Jakarta Concurrencyによる並行処理プログラミングの始め方 (JJUG CCC 2024 Fall)
tnagao7
1
230
Go言語でターミナルフレンドリーなAIコマンド、afaを作った/fukuokago20_afa
monochromegane
2
140
アジャイルを支えるテストアーキテクチャ設計/Test Architecting for Agile
goyoki
7
2.8k
Featured
See All Featured
Being A Developer After 40
akosma
86
590k
Writing Fast Ruby
sferik
626
61k
Side Projects
sachag
452
42k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
37
1.8k
Learning to Love Humans: Emotional Interface Design
aarron
272
40k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
3
370
Into the Great Unknown - MozCon
thekraken
31
1.5k
A Modern Web Designer's Workflow
chriscoyier
692
190k
Designing Experiences People Love
moore
138
23k
No one is an island. Learnings from fostering a developers community.
thoeni
19
3k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
328
21k
The Invisible Side of Design
smashingmag
297
50k
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