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

웹 개발에서의 데이터베이스 정규화 및 비정규화

7月 02, 2025
# Misc

James Reed

Infrastructure Engineer · Leapcell

この記事はEnglish、日本語、Deutschでも利用できます
Cover of "웹 개발에서의 데이터베이스 정규화 및 비정규화"

소개

빠르게 변화하는 웹 개발 세계에서 데이터는 모든 애플리케이션 구축의 기반입니다. 웹 애플리케이션의 효율성, 확장성 및 유지보수성은 종종 그 기초가 되는 데이터베이스가 얼마나 효과적으로 설계되었는지에 직접적으로 달려 있습니다. 데이터베이스 설계에서 가장 중요한 측면 중 하나이며, 종종 논쟁과 최적화의 지점인 것은 정규화 원칙을 엄격히 준수하는 것과 비정규화를 전략적으로 적용하는 것 사이의 균형입니다. 이 논의는 단순히 학문적인 것이 아니라 쿼리 성능, 데이터 무결성 및 개발 복잡성에 직접적인 영향을 미칩니다. 1NF, 2NF, 3NF의 미묘한 차이와 이러한 규칙을 언제 의도적으로 깨뜨릴지를 이해하는 것은 강력하고 성능이 뛰어난 웹 솔루션을 구축하고자 하는 모든 개발자에게 매우 중요합니다. 이 글에서는 이러한 개념을 자세히 살펴보고 실제 웹 개발 시나리오에서 그 중요성과 실용적인 적용을 설명합니다.

핵심 개념

정규화와 비정규화의 복잡성에 대해 자세히 알아보기 전에 핵심 용어를 명확하게 이해해 봅시다.

  • 관계형 데이터베이스 관리 시스템(RDBMS): 공통 필드로 연결된 테이블에 데이터를 저장하는 데이터베이스 유형으로, 대규모 구조화된 데이터 컬렉션을 관리하는 강력하고 유연한 방법을 제공합니다. 예로는 MySQL, PostgreSQL, SQL Server가 있습니다.
  • 테이블(릴레이션): 데이터베이스 내에서 구조화된 형식으로 보유된 관련 데이터의 모음입니다. 행과 열로 구성됩니다.
  • 행(튜플/레코드): 테이블의 단일 항목 또는 레코드로, 단일하고 암시적으로 구조화된 데이터 항목을 나타냅니다.
  • 열(속성/필드): 테이블의 각 행에 대해 특정 단순 유형의 데이터 값 모음입니다.
  • 기본 키: 테이블의 각 레코드에 대한 고유 식별자입니다. NULL 값을 포함할 수 없으며 각 레코드마다 고유해야 합니다.
  • 외래 키: 두 테이블 간의 링크를 설정하는 두 테이블의 기본 키를 참조하는 테이블의 열 또는 열 집합입니다.
  • 함수 종속성: X → Y로 표시되는 X 속성(또는 속성 집합)이 다른 속성(또는 속성 집합)의 값을 고유하게 결정하는 테이블의 속성 간 관계. X가 Y를 결정함을 의미합니다.

데이터베이스 정규화 원칙 (1NF, 2NF, 3NF)

데이터베이스 정규화는 데이터 중복을 최소화하고 데이터 무결성을 개선하기 위해 관계형 데이터베이스를 재구성하는 체계적인 프로세스입니다. 대형 테이블을 더 작고 연결된 테이블로 분할하고 그들 간의 관계를 정의하는 것을 포함합니다.

제1 정규형 (1NF)

테이블이 1NF인 경우:

  1. 각 열은 원자적(나눌 수 없는) 값을 포함합니다. 반복되는 열 그룹이 없습니다.
  2. 각 행은 고유하며, 일반적으로 기본 키로 강제됩니다.

예시: 고객이 여러 항목을 주문할 수 있고 항목 세부 정보가 Orders 테이블 내에 직접 저장되는 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입니다.

예시: item_price와 item_description을 포함하도록 OrderItems 테이블을 수정해 보겠습니다. 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)
);

비정규화

정규화는 데이터 무결성과 중복 감소에 중요하지만, 데이터를 검색하려면 여러 테이블을 조인해야 하는 경우가 많습니다. 특히 읽기 작업이 많은 웹 애플리케이션의 경우 이러한 조인은 성능 병목 현상이 될 수 있습니다. 비정규화는 쓰기 성능을 일부 희생하고 데이터 중복을 늘리는 대가로 읽기 성능을 향상시키기 위해 의도적으로 중복 데이터를 데이터베이스에 추가하거나 데이터를 그룹화하는 프로세스입니다.

비정규화를 고려할 때:

  • 빈번하고 복잡한 조인: 일반적인 쿼리가 여러 테이블을 조인하고 성능이 중요한 경우.
  • 보고/분석: 요약 테이블 또는 캐시된 집계는 분석 대시보드의 쿼리 시간을 크게 향상시킬 수 있습니다.
  • 높은 읽기/쓰기 비율: 주로 데이터를 작성하는 것보다 읽는 애플리케이션은 상당한 이점을 얻을 수 있습니다.
  • 구체화된 뷰: 일부 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를 업데이트하는 것을 잊지 않아야 합니다. 이는 애플리케이션 로직(예: 웹 프레임워크의 모델/서비스 계층) 또는 데이터베이스 트리거를 사용하여 수행할 수 있습니다.

예시(애플리케이션 로직 - 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: 자주 액세스되는 속성 복제 전자 상거래 플랫폼에서 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)
);

비정규화된 해결책: OrderItems에 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가 이러한 스냅샷 열에 캡처됩니다. 이를 통해 나중에 상품의 이름이나 가격이 변경되어도 JOIN 없이 주문 세부 정보가 기록적으로 정확하게 유지됩니다.

비교 및 트레이드오프

특징정규화 (1NF, 2NF, 3NF)비정규화
데이터 중복최소화(의도적으로) 도입함
데이터 무결성높음 (업데이트 이상의 발생 가능성 적음)낮음 (신중하게 관리되지 않으면 업데이트 이상의 발생 가능성 있음)
쿼리 성능복잡한 쿼리의 경우 느림 (조인 때문)읽기 작업에 대해 빠름 (조인 적음, 사전 계산된 결과)
쓰기 성능빠름 (삽입/업데이트) (작은 테이블, 적은 인덱싱)느림 (삽입/업데이트) (더 많은 열 업데이트, 잠재적 트리거)
저장 공간적음많음
설계 복잡성관계 설계 및 유지 관리가 더 쉬움일관성 유지를 위해 신중한 계획 필요
애플리케이션OLTP (온라인 트랜잭션 처리) 시스템, 높은 데이터 무결성 요구 사항OLAP (온라인 분석 처리) 시스템, 보고, 읽기 중심 API

웹 개발에서는 종종 혼합 접근 방식이 가장 실용적입니다. 데이터 무결성과 명확한 논리적 구조를 보장하기 위해 정규화된 설계로 시작합니다. 그런 다음 프로파일링 도구를 사용하여 성능 병목 현상을 식별하고, 중요 읽기에 대해 상당한 성능 향상을 달성할 수 있는 특정 스키마 부분을 선택적으로 비정규화하여 애플리케이션 로직이나 트리거와 같은 데이터베이스 메커니즘을 통해 비정규화된 데이터의 일관성을 유지하도록 합니다.

결론

데이터베이스 정규화 (1NF, 2NF, 3NF)에 대한 이해는 웹 개발에서 강력하고 유지 가능한 데이터 모델을 만드는 데 필요한 기본 규율을 제공하여 데이터 중복을 방지하고 무결성을 보장합니다. 그러나 언제 어떻게 비정규화를 전략적으로 적용할지를 인식하는 것은 고도로 정규화된 구조에 내재된 성능 병목 현상을 극복하고 매우 응답성이 뛰어난 웹 애플리케이션을 제공하는 데 똑같이 중요합니다. 최적의 데이터베이스 설계는 정규화의 엄격함과 비정규화의 실용성을 균형 있게 유지하며, 항상 애플리케이션의 무결성과 성능 요구 사항을 모두 효과적으로 충족하는 솔루션을 목표로 합니다.

Share this article

HackerNews

More Posts from Leapcell

Popular Posts