データベース設計について復習したのでメモを書いていきます。
主に下記書籍を参考にしています。
楽々ERDレッスン
達人に学ぶDB設計 徹底指南書
データベース設計
主に下記2つに分解することができます。
- 論理設計
- 物理設計
論理設計
- エンティティの抽出
- エンティティの定義
- 正規化
- ER図の作成
- 実際に値を入れ、ユースケースに耐えうるか確認
論理設計の重要な要素
- 正規化
- インデックス設計
エンティティの抽出
下記書籍の「病院の受付伝票」を例に進めます。
まあ患者さんが診察をするために受付をするくらいのイメージです。
楽々ERDレッスン
ブロックに分ける
上記例の場合、「患者」、「受付」などがメインのテーブルとしてあげられるでしょう。
このくらいの粒度でざっと分けてみます。
イベント系、リソース系エンティティの整理
イベント系エンティティ
「~する」と言えるかどうかで決まるエンティティです。
どのようにに当てはまります。
具体例でいうと、受付するとか、診察するとかです。
リソース系エンティティ
「~する」と言えないものは、こちらに属します。
誰に、誰が、何を、どこに当てはまります。
具体例でいうと、患者とか、担当医師などです。
整理するとわかりますが、リソース系エンティティがわりかし多く、イベント系エンティティはそこまで多くないことがわかります。
正規化
イベント系、リソース系エンティティの重複しているものなどがないかチェックします。
この正規化で必要な過程として、可逆性も担保できるようにしておきます。
あとで検索できるかどうかです。
インデックス設計
作るとデータ参照が速くなるやつ
MySQLでインデックスを貼る時に読みたいページまとめ(初心者向け） - Qiita より引用
詳細は下記記事などが参考になります。
MySQLパフォーマンスチューニングのためのインデックスの基礎知識 - 久保清隆のブログ
MySQL :: MySQL 5.6 リファレンスマニュアル :: MySQL 用語集
PostgreSQLでインデックスを効率良く利用しよう | TECHSCORE BLOG
パフォーマンスを考慮したIndex定義設計 | TECHSCORE BLOG
正規化とパフォーマンスの関係性[参考]
正規化すればするほど、整合性は担保できるが、パフィーマンスは落ちてしまう傾向があります。
ER図作成
何で書くか
下記のいづれかがおすすめです。
ユースケースに耐えうるか実際の値を入れて確認
スプレッドシートとかに実際に入るであろう値を入れていき、実装する機能を実現できるかを確認します。
この時に懸念事項があれば、エンティティの再確認、ER図修正などを行ったりします。
主なチェックリスト
- テーブル名は英語ならば複数形/複数名詞で書けるか
- 日本語を使っていないか
- 最初はアルファベットになっているか(test_2020のようにすべき)
- テーブル名は同じドメイン内で重複していないか
- 複数のテーブルをまとめていないか
- 主キーにidという名前を利用していないか
- 参照整合性制約をつけているか
- NOT NULL 制約はなるべくつけているか
4ステップで作成する、DB論理設計の手順とチェックポイントまとめ - Qiita より引用
参考記事
4ステップで作成する、DB論理設計の手順とチェックポイントまとめ - Qiita
SQLアンチパターンもりもりDBを設計しよう！ - Qiita
DB論理設計のノウハウ - Qiita
物理設計
- テーブル定義
- インデックス定義
- ハードウェアサイジング
- 冗長構成
- ファイルの物理配置
「データベースをつくってみよう！」 データベース物理設計-入門編
第５章 データベースの物理設計
インフラに関わる部分が多いです。
TODO
RDBかNoSQLか
そもそもデータベース設計に入るまでに、RDBが良いのか、それともNoSQLが良いのかはこれから判断基準を自分の中に落とし込んでいきたいなと思っています。
全体図
まずNoSQLが全体のどこに位置するのかは下記が非常にわかりやすい
