【書籍】達人に学ぶDB設計徹底指南書を読んで学んだこと【第2章】
第2章
論理設計と物理設計
論理設計を行った後に物理設計を行う。
論理設計
概念スキーマを定義する設計を論理設計という
何を情報のデータとして保存するか抽象的に決めるイメージ。
論理設計は名前のイメージ通り「机上」で設計できるので、この設計時はまだパソコンがなくても紙に書いて設計とかもできる。物理設計 内部スキーマを定義する設計を物理設計という
論理設計を元に具体的にどんな情報をRDBに保存するか具体名を考えて決めるイメージ
✍️論理設計を行うステップ
- エンティティの抽出
- エンティティの定義
- 正規化
- ER図の作成
以上の4つのステップで論理設計を行う。
エンティティとは？
RDBに格納するための「情報」を抽象的に表したもの。
【1】エンティティの抽出
エンティティ(= 情報)は最終的にはRDBに格納され保存されるが、エンティティを抽出した段階ではまだリストアップしただけなので、論理設計の工程的には抽出しただけであればまだRDBに保存できてない。
この工程では、まずRDBに格納する予定の情報をリストアップするということを行う。（顧客、社員、会社みたいなテーブル名を決めるイメージ）
ちなみにエンティティが格納される時は「テーブル」に格納される。
【2】エンティティの定義
エンティティを抽出できたら、次はエンティティをどの様な属性「attribute」で保存するかを決める必要がある。
エンティティを属性で定義しないと、RDBには保存することができない。
属性とは？
テーブルという表のフォーマットの中の縦列のことを属性という。
【3】正規化（重要）
正規化を行うことで、データベース内でエンティティをスムーズに利用することができる様になる。 なのでエンティティを抽出し、属性をつけて定義しても 、この「正規化」を行わないと保持されている情報をシステム側で利用することができない。
【4】ER図
ER図とはエンティティ・リレーションシップ・ディアグラムの略称で、テーブルに保存する情報を可視化して、情報（エンティティ）同士の関係性や格納情報を見やすくした見取り図みたいなもの。
大規模開発になるとER図が無いと全体像の把握が困難になってくるため、ER図がほぼ必須になる。
▼内部スキーマと物理設計
物理設計のステップ
- テーブル定義
- インデックス定義
- ハードウェアのサイジング
- ストレージの冗長構成決定
- ファイルの物理配置決定
【1】テーブル定義
論理設計で定義された概念スキーマを元にRDMS内へ格納するために「テーブル」という単位に変換する必要がある。
概念スキーマをテーブルに変換して最終的に物理モデルを作成する。（論理設計は最終的に論理モデルを作成する）
【2】インデックス定義
インデックスはパフォーマンスに関係してくる重要な部分で、牽引（目次）の様な役割をしているというイメージをしておけば良い。
インデックスがなくても問題なく機能はするが、特定の単語や情報が多くなってきた時にインデックスを定義していないと探すのが大変になる。
この様な理由から、結果的にパフォーマンスに影響が出てくるから、インデックスを定義することも大事になっってくる。
【3】ハードウェアのサイジング
サイジングとは、データ通信量がどのくらいになって、そのデータサイズはどれくらい大きくなって、それをストレージに保存するにはディスク容量がどのくらい必要になってくるとかの「見積もり」をすること。
どれくらいの画像が保存されるとかそういうDBに保存されるテーブル以外のことも加算して考える必要がある。
DBのディスク容量がパンパンになってくるとデータベースの性能が落ちてきて、システムのパフォーマンスが悪くなるという影響が出てくるので、この見積もりはとても重要。（最悪ストレージ（容量）が足らなくなるということも起きうる）
💡ポイント
精度の高いサイジングは難しいから、スケールしやすい、後から拡張しやすい構成でDBを設計することが大切。コスト面にも関わるところなので、この見積もりは難しいがとても大事になってくる。
ストレージの冗長構成
DB内に保存するデータを1箇所だけのディスク場所に保存しておくのは、何かあった時に全て失いかねないので、何かあった時にでも大丈夫な様にバックアップを持っておく必要がある。
そのために、RAIDと言われる「独立したディスク」を複数持ち、何かあってもいいよに分散さしておく技術を活用しておくと安心できる。
これは同じ情報が保存されたDBが入っているディスクを複数台用意することを指す。
RAIDという技術を使って、仮想的に複数のディスクを1つのグループにまとめたディスクのことを「RAIDグループ」という。
RAIDを活用して複数のバックアップを複数のディスクに保管しておくと安全だが、その分コストもかかってくるので、予算と相談して決める必要がありそう。
ファイルの物理配置
ストレージの冗長構成が決まったら、物理設計の最後にデータベースのファイルをどのディスク（またはどのRAIDグループ）に配置するか考える。
配置するファイルの種類
- データファイル
- インデックスファイル
- システムファイル
- 一時ファイル
- ログファイル
以上の5つのファイルの保管配置場所を考える。
①データファイル
ユーザー入力した情報をDBに保持するためのファイル。
SQLを通じてDB内部に情報を追加したり更新したりする時にも使用されるファイル。
②インデックスファイル
テーブルに格納されたインデックス（牽引）が格納されるファイル。
このファイルは、ユーザーも開発者も意識することはないファイルみたいです。
理由は、SQLではテーブルへアクセスする記述をすることがあっても、特定のインデックスに対する記述をすることがないから。
③システムファイル
DBMSの内部管理に使用されるデータを格納する。
ユーザーがアクセスすることはない。
④一時ファイル
DBMS内部で一時的にSQLとかで利用されたデータを格納する場所。
検索時やソート時などで一時的にSQLで選択して利用すると思うけど、その時に一時的に引っ張ってきて格納しておく場所のことを一時ファイルという。
⑤ログファイル
RDMSは、データベースに対する変更・更新の指令を受けた時にすぐさま実行しているのではなく、ログファイルに一時的に処理を保管し、一括してデータファイルに変更を反映させている。
その時に一時的に保管しておく場所。これも一時ファイルと同じ様な機能を果たしている。
ユーザーが行動してリクエストしたり指令したりしたときの実行コード（SQLでのクエリ）などを一時的に保管しておく。
