ドキュメント価格ブログ
お問い合わせ
ログイン無料で新規登録
Back to Tech Articles

Web開発におけるデータベース正規化と非正規化

7月 02, 2025
# Misc

James Reed

Infrastructure Engineer · Leapcell

この記事はEnglish、한국어、Deutschでも利用できます
Cover of "Web開発におけるデータベース正規化と非正規化"

はじめに

急速に進化するWeb開発の世界において、データはすべてのアプリケーションの基盤となります。Webアプリケーションの効率性、スケーラビリティ、保守性は、しばしばその基盤となるデータベースの設計の有効性に直接結びついています。データベース設計における最も重要な側面の一つであり、しばしば論争や最適化の的となるのが、正規化の原則への厳密な準拠と、非正規化の戦略的な適用との間の議論です。この議論は単なる学術的なものではなく、クエリパフォーマンス、データの整合性、開発の複雑さに直接影響します。1NF、2NF、3NFのニュアンスと、いつこれらのルールを意図的に破るべきかを理解することは、堅牢でパフォーマンスの高いWebソリューションの構築を目指す開発者にとって不可欠です。この記事では、これらの概念を掘り下げ、実際のWeb開発シナリオにおけるその重要性と実践的な適用を説明します。

コアコンセプト

正規化と非正規化の複雑な議論に入る前に、コア用語を明確に理解しましょう。

  • リレーショナルデータベース管理システム（RDBMS）: テーブルにデータを格納し、共通のフィールドでリンクするデータベースの一種で、構造化された大規模なデータコレクションを管理するための強力で柔軟な方法を提供します。例としては、MySQL、PostgreSQL、SQL Serverなどがあります。
  • テーブル（リレーション）: データベース内で構造化された形式で保持される関連データのコレクションです。行と列で構成されます。
  • 行（タプル/レコード）: テーブルの単一のエントリまたはレコードで、単一の、暗黙的に構造化されたデータ項目を表します。
  • 列（属性/フィールド）: テーブルの各行について、特定の単純な型のデータ値のセットです。
  • 主キー: テーブルの各レコードの一意の識別子です。NULL値を含むことはできず、各レコードで一意である必要があります。
  • 外部キー: テーブルの、もう一方のテーブルの主キーを参照する列または列のセットです。2つのテーブル間にリンクを確立します。
  • 関数従属: テーブルの属性間の関係で、1つの属性（または属性のセット）が別の属性（または属性のセット）の値を一意に決定します。X → Yと表記され、XがYを決定することを意味します。

データベース正規化の原則（1NF、2NF、3NF）

データベース正規化は、データ冗長性を最小限に抑え、データ整合性を向上させるためにリレーショナルデータベースを体系的に再構築するプロセスです。大きなテーブルをより小さなリンクされたテーブルに分割し、それらの間の関係を定義することを含みます。

第1正規形（1NF）

テーブルが1NFであるのは、以下の条件を満たす場合です。

  1. 各列にはアトミック（分割不可能）な値が含まれます。列の繰り返しグループはありません。
  2. 各行は一意であり、通常は主キーによって強制されます。

例: 顧客が複数のアイテムを注文でき、アイテムの詳細がOrdersテーブルに直接保存されていると仮定します。

1NFではない形式:

CREATE TABLE Orders (
    order_id INT PRIMARY KEY,
    customer_name VARCHAR(100),
    item1_name VARCHAR(100),
    item1_quantity INT,
    item2_name VARCHAR(100),
    item2_quantity INT
);

ここでは、item_nameとitem_quantityが繰り返しグループです。

1NFの解決策: 注文アイテムを独自のテーブルに分離し、order_idを介してOrdersテーブルにリンクします。

CREATE TABLE Orders (
    order_id INT PRIMARY KEY,
    customer_name VARCHAR(100),
    order_date DATE
);

CREATE TABLE OrderItems (
    order_item_id INT PRIMARY KEY AUTO_INCREMENT,
    order_id INT,
    item_name VARCHAR(100),
    quantity INT,
    FOREIGN KEY (order_id) REFERENCES Orders(order_id)
);

第2正規形（2NF）

テーブルが2NFであるのは、以下の条件を満たす場合です。

  1. 1NFであること。
  2. すべての非キー属性が、複合主キー全体に完全に機能的に依存していること。これは、複合主キーを持つテーブルにのみ適用されます。テーブルに単一列の主キーがある場合、1NFであれば自動的に2NFになります。

例: OrderItemsテーブルにitem_priceとitem_descriptionを含めるように変更しましょう。item_idが複合主キー(order_id, item_id)の一部になったと仮定します。

2NFではない形式:

CREATE TABLE OrderItems (
    order_id INT,
    item_id INT,
    item_name VARCHAR(100),
    item_price DECIMAL(10, 2),
    item_description TEXT,
    quantity INT,
    PRIMARY KEY (order_id, item_id)
);

ここでは、item_name、item_price、item_descriptionは複合主キー(order_id, item_id)全体ではなく、item_idのみに機能的に依存しています。これは、同じitem_idに対する複数の注文がある場合、アイテムの名前、価格、説明が重複することを意味します。

2NFの解決策: アイテム固有の詳細を個別のItemsテーブルに抽出します。

CREATE TABLE Items (
    item_id INT PRIMARY KEY,
    item_name VARCHAR(100),
    item_price DECIMAL(10, 2),
    item_description TEXT
);

CREATE TABLE OrderItems (
    order_item_id INT PRIMARY KEY AUTO_INCREMENT,
    order_id INT,
    item_id INT,
    quantity INT,
    FOREIGN KEY (order_id) REFERENCES Orders(order_id),
    FOREIGN KEY (item_id) REFERENCES Items(item_id)
);

第3正規形（3NF）

テーブルが3NFであるのは、以下の条件を満たす場合です。

  1. 2NFであること。
  2. 推移的関数従属がないこと。つまり、非キー属性が別の非キー属性に機能的に依存していないこと。

例: customer_zip_codeとcustomer_cityを含むOrdersテーブルを考えます。

3NFではない形式:

CREATE TABLE Orders (
    order_id INT PRIMARY KEY,
    customer_id INT,
    customer_name VARCHAR(100),
    customer_address VARCHAR(255),
    customer_city VARCHAR(100),
    customer_zip_code VARCHAR(10),
    order_date DATE
);

ここでは、customer_cityはcustomer_zip_codeによって決定され（したがって、customer_zip_codeを決定するcustomer_idによって推移的に決定され）ます。これは、customer_cityが非キー属性customer_zip_codeに機能的に依存していることを意味します。

3NFの解決策: 顧客の詳細を個別のCustomersテーブルに抽出します。

CREATE TABLE Customers (
    customer_id INT PRIMARY KEY,
    customer_name VARCHAR(100),
    customer_address VARCHAR(255),
    customer_city VARCHAR(100),
    customer_zip_code VARCHAR(10)
);

CREATE TABLE Orders (
    order_id INT PRIMARY KEY,
    customer_id INT,
    order_date DATE,
    FOREIGN KEY (customer_id) REFERENCES Customers(customer_id)
);

非正規化

正規化はデータの整合性と冗長性の削減に不可欠ですが、データの取得には多くの場合、複数のテーブルを結合する必要があります。Webアプリケーション、特に読み込み負荷が高いアプリケーションでは、これらの結合はパフォーマンスのボトルネックになる可能性があります。非正規化は、書き込みパフォーマンスの低下とデータ冗長性の増加を犠牲にして、読み込みパフォーマンスを向上させるために、意図的に冗長なデータ（またはグループ化されたデータ）をデータベースに追加するプロセスです。

非正規化を検討すべき場合:

  • 頻繁で複雑な結合: 一般的なクエリが多数のテーブルの結合を必要とし、パフォーマンスが重要である場合。
  • レポート/分析: 集計テーブルやキャッシュされた集計は、分析ダッシュボードのクエリ時間を大幅に短縮できます。
  • 高い読み取り対書き込み比率: 主にデータを書き込むよりも読み取るアプリケーションは、大幅な恩恵を受けることができます。
  • マテリアライズドビュー: 一部のRDBMSでは、マテリアライズドビューが非正規化されたデータを自動的に処理し、同期を維持できます。

例1：集計データのキャッシュ ブログプラットフォームで、投稿にコメントが付いていると想像してください。各投稿のコメント数を表示するには、通常、postsテーブルと結合されたcommentsテーブル全体をCOUNT集計する必要があります。

正規化された構造:

CREATE TABLE Posts (
    post_id INT PRIMARY KEY,
    title VARCHAR(255),
    content TEXT,
    author_id INT
);

CREATE TABLE Comments (
    comment_id INT PRIMARY KEY,
    post_id INT,
    user_id INT,
    comment_text TEXT,
    comment_date DATETIME
);

コメント数を含む投稿を取得するには:

SELECT p.title, COUNT(c.comment_id) AS comment_count
FROM Posts p
LEFT JOIN Comments c ON p.post_id = c.post_id
GROUP BY p.post_id;

多数の投稿とコメントがあると、このクエリは遅くなる可能性があります。

非正規化された解決策: Postsテーブルに直接comment_count列を追加します。

CREATE TABLE Posts (
    post_id INT PRIMARY KEY,
    title VARCHAR(255),
    content TEXT,
    author_id INT,
    comment_count INT DEFAULT 0 -- 非正規化された列
);

これで、comment_countの取得はPostsテーブルからの単純な読み取りで済みます。

SELECT title, comment_count FROM Posts;

更新の処理: 新しいコメントが追加または削除された場合、Posts.comment_countを更新することを忘れないでください。これは、アプリケーションロジック（例：Webフレームワークのモデル/サービスレイヤー）またはデータベーストリガーを使用して行うことができます。

例（アプリケーションロジック - Python/Flask）:

from flask import Flask, request, jsonify
from sqlalchemy import create_engine, Column, Integer, String, Text, DateTime, ForeignKey
from sqlalchemy.orm import sessionmaker, relationship
from sqlalchemy.ext.declarative import declarative_base
import datetime

DATABASE_URL = "sqlite:///app.db"
engine = create_engine(DATABASE_URL)
Base = declarative_base()
Session = sessionmaker(bind=engine)

class Post(Base):
    __tablename__ = 'posts'
    post_id = Column(Integer, primary_key=True)
    title = Column(String(255), nullable=False)
    content = Column(Text, nullable=False)
    author_id = Column(Integer)
    comment_count = Column(Integer, default=0) # 非正規化された列

    comments = relationship("Comment", back_populates="post")

class Comment(Base):
    __tablename__ = 'comments'
    comment_id = Column(Integer, primary_key=True)
    post_id = Column(Integer, ForeignKey('posts.post_id'))
    user_id = Column(Integer)
    comment_text = Column(Text, nullable=False)
    comment_date = Column(DateTime, default=datetime.datetime.now)

    post = relationship("Post", back_populates="comments")

Base.metadata.create_all(engine)

app = Flask(__name__)

@app.route('/posts', methods=['GET'])
def get_posts():
    session = Session()
    posts = session.query(Post).all()
    results = [{"post_id": p.post_id, "title": p.title, "content": p.content, "comment_count": p.comment_count} for p in posts]
    session.close()
    return jsonify(results)

@app.route('/posts/<int:post_id>/comments', methods=['POST'])
def add_comment(post_id):
    session = Session()
    post = session.query(Post).filter_by(post_id=post_id).first()
    if not post:
        session.close()
        return jsonify({"error": "Post not found"}), 404

    data = request.get_json()
    new_comment = Comment(
        post_id=post_id,
        user_id=data.get('user_id'),
        comment_text=data.get('comment_text')
    )
    session.add(new_comment)
    post.comment_count += 1 # 非正規化された列を更新
    session.commit()
    session.close()
    return jsonify({"message": "Comment added successfully", "comment_id": new_comment.comment_id}), 201

if __name__ == '__main__':
    app.run(debug=True)

このPythonの例は、新しいコメントが追加されたときにcomment_countが明示的に更新され、非正規化されたデータの一貫性が保たれることを示しています。

例2：頻繁にアクセスされる属性の複製 eコマースプラットフォームでは、product_nameとproduct_priceは、注文明細やショッピングカートを表示する際に頻繁に必要とされる場合があります。正規化された構造ではOrdersとOrderItemsをProductsに結合する必要がありますが、これらの特定のフィールドをOrderItemsに複製することで、過去の注文の取得を高速化できます。

正規化された構造:

CREATE TABLE Products (
    product_id INT PRIMARY KEY,
    product_name VARCHAR(255),
    product_description TEXT,
    unit_price DECIMAL(10, 2)
);

CREATE TABLE OrderItems (
    order_item_id INT PRIMARY KEY AUTO_INCREMENT,
    order_id INT,
    product_id INT,
    quantity INT,
    FOREIGN KEY (order_id) REFERENCES Orders(order_id),
    FOREIGN KEY (product_id) REFERENCES Products(product_id)
);

非正規化された解決策: order_itemsにproduct_name_snapshotとunit_price_snapshotを追加します。これは、製品の価格は時間とともに変化する可能性があり、注文は購入時の価格を反映する必要があるため、特に役立ちます。

CREATE TABLE OrderItems (
    order_item_id INT PRIMARY KEY AUTO_INCREMENT,
    order_id INT,
    product_id INT,
    quantity INT,
    product_name_snapshot VARCHAR(255), -- 履歴の正確性と速度のため非正規化
    unit_price_snapshot DECIMAL(10, 2), -- 履歴の正確性と速度のため非正規化
    FOREIGN KEY (order_id) REFERENCES Orders(order_id),
    FOREIGN KEY (product_id) REFERENCES Products(product_id)
);

注文アイテムが作成されると、現在のproduct_nameとunit_priceがこれらのスナップショット列にキャプチャされます。これにより、製品の名前や価格が後で変更された場合でも、結合を必要とせずに注文明細が履歴的に正確に保たれます。

比較とトレードオフ

特徴正規化（1NF、2NF、3NF）非正規化
データ冗長性最小限に抑えられる導入される（意図的に）
データ整合性高い（更新異常が少ない）低い（注意深く管理されない場合、更新異常の可能性あり）
クエリパフォーマンス複雑なクエリでは遅い（結合のため）高速（結合が少なく、結果が事前計算されている）読み取り負荷が高い操作
書き込みパフォーマンス高速な挿入/更新（テーブルが小さい、インデックスが少ない）低速な挿入/更新（更新する列が多く、トリガーの可能性あり）
ストレージ容量少ない多い
設計の複雑さ関係の設計と保守が容易一貫性の維持には注意深い計画が必要
アプリケーションOLTP（オンライン・トランザクション処理）システム、高いデータ整合性要件OLAP（オンライン・アナリティック処理）システム、レポート、読み取り負荷の高いAPI

Web開発では、ハイブリッドアプローチが最も実用的であることがよくあります。まず、データ整合性と明確な論理構造を確保するために正規化された設計から始めます。次に、プロファイリングツールを使用してパフォーマンスのボトルネックを特定し、重要な読み取りで大幅なパフォーマンス向上が得られる特定のスキーマ部分を非正規化します。これにより、アプリケーションロジックまたはトリガーのようなデータベースメカニズムを使用して、非正規化されたデータの一貫性を保ちます。

結論

データベース正規化（1NF、2NF、3NF）を理解することは、Web開発において堅牢で保守性の高いデータモデルを作成するための基本的な規律を提供し、データ冗長性から保護し、整合性を確保します。しかし、いつ、どのように非正規化を戦略的に適用するかを認識することも同様に重要であり、開発者は正規化された構造に固有のパフォーマンスのボトルネックを克服し、応答性の高いWebアプリケーションを提供できるようにします。最適なデータベース設計は、正規化の厳密さと非正規化の実用性をバランスさせ、常にアプリケーションの整合性とパフォーマンスの要求の両方を効果的に満たすソリューションを目指します。

Share this article

HackerNews

More Posts from Leapcell

cover

バックエンドテストにおけるモック、スタブ、フェイクの効果的な戦略

cover

データベースパフォーマンスをB-Treeインデックスで最適化する

Popular Posts