Zenn
😎

DBの3層スキーマ

2025/02/14に公開
DB
スキーマ
tech

Daily Blogging55日目

DB設計に欠かせない概念が3層スキーマだよ

スキーマとは

DB設計におけるスキーマとは、「DBのデータ構造やフォーマット」という意味を持つ。
簡単にいうと、DBの中でデータがどのように構成、整理されるかを定めた設計図みたいなやつ。

3層スキーマモデル

スキーマは次の３つの層から成る

  • 外部スキーマ(外部モデル)
    • ビューの世界
  • 概念スキーマ(論理データモデル)
    • テーブルの世界
  • 内部スキーマ(物理データモデル)
    • ファイルの世界

外部スキーマ(外部モデル)

ユーザから見たDB

簡単にいうと、システムを利用するユーザがどういうデータにアクセスできるのか、何を操作できるのかを決めるレイヤー
webアプリだと、画面に表示されるデータとかのこと

概念スキーマ(論理データモデル)

開発者から見たDB

データの論理的な構造や関係性を決めるレイヤー
エンティティ、リレーション、正規化などを考える
いわゆるテーブル設計、論理設計にあたる
※論理とは、物理層にとらわれないという意味

内部スキーマ(物理データモデル)

DBMSから見たDB

物理層のお話で、テーブルやインデックスなどDBMSが扱うファイルを諸々作成していく。
DBのストレージの最適化などもこのレイヤーで検討する。

概念スキーマの必要性

なんで３層に分ける必要があるのか？
別に分けなくても問題ないんじゃない？

逆に３層じゃなかった場合はどうなるのか
概念スキーマがなかったらどうなるのか

概念スキーマがないということは、テーブル設計をちゃんとやってないってこと
正規化もちゃんとできてないし、外部キー制約も検討できてないみたいな感じ
テーブル設計をちゃんとやっていないと、データの整合性をとるのが難しくなったり、DBの変更が難しくなったりする
例えばこういうテーブルを設計なしで作ったとすると

CREATE TABLE orders (
    id BIGINT PRIMARY KEY,
    user_email VARCHAR(255), -- ユーザーとのリレーションが曖昧
    product_name VARCHAR(255), -- 商品の管理がバラバラ
    amount INT
);

どのユーザと紐づいてるの？とかどの商品を買ったの？ってなる

ちゃんとテーブル設計すると

CREATE TABLE users (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    email VARCHAR(255) UNIQUE NOT NULL
);

CREATE TABLE products (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(255) NOT NULL,
    price DECIMAL(10,2) NOT NULL
);

CREATE TABLE orders (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    user_id BIGINT NOT NULL,
    product_id BIGINT NOT NULL,
    amount INT NOT NULL,
    FOREIGN KEY (user_id) REFERENCES users(id),
    FOREIGN KEY (product_id) REFERENCES products(id)
);

こんな感じになってデータの管理もしやすいしテーブル設計の変更も容易になる。

テーブル設計をちゃんとやっていないと、外部スキーマの変更が内部スキーマにモロに影響する可能性があるし逆もまた然り
つまり、スキーマ同士の依存関係が強くなる

概念スキーマを設けることで、それぞれの依存性を弱めることができる
これをデータ独立性というよ

まとめ

まぁオブジェクト指向にもあるインターフェースがDBにも必要ですよみたいなイメージ
いらんところは隠蔽しましょう的な

Discussion