３層スキーマは、データベースを以下の３つのスキーマに分けます。
これにより、異なる関係者に分けてシステムを開発できます。
(例：エンドユーザーからすると、保存方法はなんでもいい。必要なデータが見れればいい。)
なお、似たような３層モデルにWeb３層モデルがありますが、詳細は以下の記事をご覧ください。
| データベース設計 | |||||
|---|---|---|---|---|---|
外部スキーマ
データベースの見せ方を決定
外部スキーマでは、ユーザー見せ方を決定します。
見せるデータを絞れるので、セキュリティも向上します。
インターフェイスを決定
外部スキーマでは、インターフェイス（どのようにデータを見せるか）を決定します。
概念スキーマ
データベースの要素と関係を決定
これにより複数のデータを組み合わせて利用できます。
概念スキーマが無いとどうなる？
社内データの一部と社外データを組み合わせて、社内サイトを作りたいとします。
しかし、社内 & 社外用のデータが無いので、外部スキーマのために内部スキーマを変更しなければいけません。
そこで、概念スキーマを間に挟むことで、データを単一の概念に統一できます。
これにより、内部スキーマを変更せずに、外部スキーマを変更できます。
概念スキーマの設計 (論理設計)
概念スキーマの設計を論理設計と呼びます。
論理設計は以下の手順で行います。そのため、論理設計のアウトプットは ER 図です。
内部スキーマ
データベースの保存方法を決定
内部スキーマの設計 (物理設計)
内部スキーマの設計を物理設計と呼びます。
物理設計は以下の手順で行います。そのため、物理設計のアウトプットは動作する DBMS です。
- テーブル定義 (データ型の決定や、主キー、制約などの設定)
- インデックス定義（基本的に主キーのインデックスを使う）
- ハードウェアの決定（ストレージ/メモリ/CPU のサイズ）
- ストレージの冗長化 (RAID、クラスター)
- ファイルのストレージへの配置・ブロックサイズを決定
最後に
関連記事
| データベース設計 | |||||
|---|---|---|---|---|---|
参考記事
https://www.oracle.com/jp/a/tech/docs/technical-resources/dbdesign.pdf
Three-schema approach - Wikipedia
en.wikipedia.org