DBの種類はたくさんあり、主にRDBが使われています。
ー有名なDBー
リレーショナルデータベース（RDB）
グラフ型データベース
キー・バリューストア型データベース
ドキュメント指向データベース
DBMS（データベースマネジメントシステム）
・利用者とDBとのやりとりを整理してくれるシステムです。
RDBMS（リレーショナルデータベースマネジメントシステム）
・MySQL
・PostgreSQL
・Oracle
などがあります。
普段MySQLを使っているのであれば、それはDB本体ではなく、私たちユーザーとRDBの間に入って、「データを整理してくれているRDBMS」ということです。
ーーーーー ーーーー ーーーーーーー
｜ ユーザー ｜ → SQL ｜ RDBMS | ＜ー＞ 操作・取得 ｜RDB（テーブル）｜
ーーーーー ビュー ← ーーーー ーーーーーーー
３層スキーマ
DBは３層スキーマから成り立ちます。
３層スキーマとは、下記３つのスキーマのことです。
・外部スキーマ（ビュー、ユーザーから見たDB）
・概念スキーマ（テーブル、開発者から見たDB）
・内部スキーマ（データファイル、DBMSから見たDB）
それぞれの関係性は以下のようになっています。
ーーーーーー ーーーーーー ーーーーーー
｜外部スキーマ｜ ー ｜概念スキーマ｜ ー ｜内部スキーマ｜
（ビュー） （テーブル） （DB）
ーーーーーー ーーーーーー ーーーーーー
・外部スキーマと概念スキーマの関係性 → テーブルをSQLでビューに持ってくる
・概念スキーマと内部スキーマの関係性 → データファイルを、見やすいようテーブルにする
・外部スキーマと内部スキーマは直接的な関連を持たない
つまりテーブルは、「ビューとDBの直接的な関係を持たせないための仲介役」とも言えます。
それではなぜ概念スキーマ（テーブル）を用意するかというと
概念スキーマ（テーブル）は、データ独立性を確保するために、「絶対必要」だからです。
論理的データ独立性
・外部スキーマを変更しても、内部スキーマに影響がない状態を指します。
物理的データ独立性
・内部スキーマを変更しても、外部スキーマに影響がない状態を指します。
反対に考えると、概念スキーマ（テーブル）を変更すると、全てのスキーマに影響が出てしまいます。
なので論理設計は非常に重要です。
論理設計
論理設計（概念スキーマの設計）
・テーブル設計
・データを管理するためのデータモデルの設計
物理設計（内部スキーマの設計）
・DDLによる実装やストレージの構成などの設計
論理設計の４STEP
１, エンティティの抽出
・どんなデータを管理するエンティティ（テーブル）が必要かを明確化する
２, エンティティの定義
・エンティティ（テーブル）ごとにどんな属性（カラム）が必要かを明確化する
３, 正規化
・データの冗長性（ムダ・重複）をなくすために、テーブルを分割する
４, ER図作成
・エンティティ（テーブル）間の関係性を可視化して図にする
エンティティとは？
システムにおいて「管理する必要があるデータ」のことです。
RDBにおいてはテーブル名とイコールになります。
エンティティ（Entity）は日本語で「実体」という意味です。
顧客・店舗などの物理的実体と、予約・注文などの概念的実体があります。
エンティティの抽出とは？
実現したいシステムで、どんなエンティティを管理する必要があるか？を洗い出すプロセスです。
例：商品購入システム
必要なエンティティ
・商品
・販売者
・購入者
・発送日 など
どんなどんなシステムを実現したいのか？に依存しているので、要件定義と似たようなプロセスです。
エンティティの定義とは？
各エンティティがどのような属性（データ）を保持するかを決めるプロセスのことです。
RDBではどんな列（カラム）を持つのかを定義するプロセスです。
必要だと思われるカラムを列挙します。
テーブルとは？
共通点を持ったレコードの集合体
共通点を持っているため、テーブル名は全て複数形で書けています。
構成要素は３つです。
１, レコード/カラム
２, キー
３, 制約
キーとは？
あるデータを引き出すための鍵となるレコードです。
重要なものは「主キー」と「外部キー」があります。
主キーとは？
主キー（プライマリーキー[Primary key]）
・その値を指定すれば、必ず一行のレコードを特定できるカラムの組み合わせのことです。
・テーブルに１つ存在する必要があり、かつ１つしか存在してはいけないという決まりがあります。
例：商品テーブル
商品ID ｜
ーーーー｜
１ ｜
２ ｜
３ ｜
外部キーとは？
外部キー（フォーリンキー[Foreign key]）
２つのテーブル間のカラム同士の関連性を設定するものです。
存在しない販売者ユーザーのデータを商品テーブルに登録してしまうことを防止することができます。
これは、反対に商品テーブルに対して、「制約」を課しているとも言えます。（参照整合性制約）
例：商品テーブル
商品ID ｜ 価格 ユーザーID ←外部キー（ユーザーテーブルに存在
ーーーー｜ーーーーーーーー｜ーーーーーーーーー しない4~を防止できる）
１ ｜ 100 ｜ 3
２ ｜ 500 ｜ ２
３ ｜ 1000 ｜ １
ーーーーーーーーーーーーーーーーーーーーーーー
例：ユーザーテーブル
ユーザーID ｜ 名前
ーーーーーー｜ーーーーーー
１ ｜ 田中
２ ｜ 加藤
３ ｜ 右京
制約とは？
特定の条件を禁止したり、特定の条件のみを許可することができる決まりのことです。
以下のような制約があります。
NOT NULL制約
・NULL値を禁止
CHECK制約
・条件を指定し、条件を満たさないデータを禁止
一意性制約（UNIQUE KEY)
・重複したデータを禁止
・NULLを禁止するわけではない
主キー制約 (PRIMARY KEY)
・一意を保証
・重複とNULLを禁止
・1つのテーブルに1つ
外部キー制約 (FOREIGN KEY) ｜｜ 参照整合性制約
・他のテーブルの列を参照し、その列にないデータを禁止