データベース設計

見た目（UI）を先に設計し、それを実現するための論理設計をする

【論理的データ独立性】：外部スキーマを変更しても内部スキーマを変更する必要がない状態

　　　　　　　　　　　　　　　　　　　⇨

【物理的データ独立性】：内部スキーマを変更しても外部スキーマを変更する必要がない状態

　　　　　　　　　　　　　　　　　　　⇦

1. 何をするシステムかを考える
   中心となるエンティティを考える
2. エンティティの抽出
   中心の周辺のエンティティとしてどんなエンティティ（テーブル）が必要かを明確にする
   5W1Hで考える（誰が、何を、いつ、どこで、どのように、なぜ）
3. エンティティの定義
   エンティティ（テーブル）毎にどんなカラムが必要かを明確にする
   インターフェースまたは仕様書中の項目をエンティティの属性として入れていく
4. 主キーと外部キー（テーブル間のリレーション）を設定する
   主キーとして適切なカラムが存在するか？ なければIDを導入する
   最初に主キー、次に外部キー
5. 正規化
   テーブルを分割することでデータの冗長性（ムダ・重複）をなくす
   第1～第3の正規形を満たしているかを確認する
6. ER図の作成
   エンティティ（テーブル）間の関係を視覚的にわかりやすく作図する

エンティティは「実体」という意味だが、物理的なものや概念的なものもある。

システムで管理する必要があるデータ。

テーブルの名前になるもの。

抽出

定義・・・キーとなるカラムを決定する

テーブルと二次元表の違い

　テーブル：共通点を持った情報の集合、カラム名を複数形で書ける

　二次元表：共通点がなくても表は作れる

主キー（Primary key）

その値を指定すれば、必ず1行のレコードを一意に定めることができる。

すべてのテーブルに1つある

テーブルに重複行は存在できない

主キーの項目は下線を引く

外部キー

2つのテーブル間の列同士の関連性を設定する

外部キーの項目は太字にする

外部キーを設定することで、参照先のテーブルにある項目しか指定できないという制約を課している

（参照整合性制約）

制約

代表的な制約　

NOT NULL制約：NULLを禁止する制約

　　　　　　　 NULLはSQL上で様々な問題を引き起こすので可能な限り正規化し

　　　　　　　 NULLを入れる必要のないデータベース設計にする必要がある。