강사 이름과 강의실 정보가 수강 테이블에 같이 있습니다. 강사가 이름을 바꾸면 그 강사가 담당하는 모든 수강 레코드를 하나씩 업데이트해야 합니다. 하나라도 빠지면 같은 강사인데 이름이 두 개가 됩니다. 이것이 수정 이상입니다. 정규화는 이런 이상 현상을 구조적으로 제거하는 설계 원칙입니다.

확대

나쁜 스키마 예시 — 모든 것을 한 테이블에

아래는 학생, 수강 과목, 담당 교수를 하나의 테이블에 넣은 비정규화 구조입니다. student_id와 course_id를 복합 PK로 사용한다고 가정합니다.

CREATE TABLE student_courses (
    student_id     INT,
    student_name   VARCHAR(100),
    course_id      VARCHAR(10),
    course_name    VARCHAR(100),
    professor_id   INT,
    professor_name VARCHAR(100),
    professor_dept VARCHAR(100)
);

실행 완료 또는 조회 결과가 표시됩니다.

실제 데이터를 채워보면 문제가 명확해집니다. 이교수의 이름과 소속이 CS101을 수강한 학생 수만큼 중복 저장됩니다.

student_id | student_name | course_id | course_name | professor_id | professor_name | professor_dept
-----------|--------------|-----------|-------------|--------------|----------------|---------------
1001       | 김학생       | CS101     | 데이터베이스 | 201          | 이교수          | 컴퓨터공학과
1001       | 김학생       | CS102     | 알고리즘     | 202          | 박교수          | 컴퓨터공학과
1002       | 박학생       | CS101     | 데이터베이스 | 201          | 이교수          | 컴퓨터공학과

3가지 이상 현상

1. 삽입 이상(Insertion Anomaly)

(student_id, course_id)가 복합 PK이면, 담당 과목과 수강 학생이 없는 신규 교수는 레코드 자체를 삽입할 수 없습니다. PK 컬럼에 NULL을 넣을 수 없기 때문입니다.

INSERT INTO student_courses VALUES
(NULL, NULL, NULL, NULL, 203, '정교수', '수학과');

2. 수정 이상(Update Anomaly)

이교수의 소속 학과를 변경하려면, CS101을 수강하는 모든 학생 행을 빠짐없이 업데이트해야 합니다. 한 행이라도 누락되면 같은 교수에 대해 서로 다른 소속 정보가 공존하는 데이터 불일치가 발생합니다.

UPDATE student_courses
SET professor_dept = 'AI학과'
WHERE professor_id = 201;

3. 삭제 이상(Deletion Anomaly)

박학생(1002)이 CS101 수강을 취소해 유일한 수강자가 사라지면, 그 행을 삭제할 때 이교수와 CS101 과목에 대한 정보까지 데이터베이스에서 완전히 사라집니다.

DELETE FROM student_courses
WHERE student_id = 1002 AND course_id = 'CS101';

정규화 전후 구조 비교

정규화 후에는 교수 정보가 professors 테이블 한 곳에만 존재합니다. 소속 학과를 변경할 때 단 1행만 수정하면 되고, 어떤 학생을 삭제해도 교수나 과목 정보는 영향받지 않습니다.

정규화 전 — 비정규화 테이블 student_courses (교수 정보가 행마다 중복)

정규화 후 — 4개 테이블로 분리

students

courses

professors

enrollments (연결 테이블)

정규화는 "한 번에 좋은 스키마를 만드는 것"이 아니라, 비정규 테이블에서 종속을 하나씩 걷어내는 단계적 분해입니다. 1NF → 2NF → 3NF → BCNF는 각 단계가 특정 종속(반복 그룹·부분 종속·이행 종속)을 제거하고, 그 대가로 특정 이상 현상 하나가 사라지도록 짜여 있습니다. 이 순서를 알면 "내 테이블이 지금 몇 단계까지 와 있나", "다음에 무엇을 쪼개야 하나"를 진단할 수 있습니다.

[비정규형 UNF]
  한 셀에 여러 값 · 반복 그룹 · 학생·과목·교수가 한 테이블에
   │
   │  ① 1NF — 원자값화: 반복 그룹·다중값을 별도 행으로 분리
   ▼
[1NF]  모든 컬럼이 원자값, 반복 그룹 없음
   │
   │  ② 2NF — 부분 함수 종속 제거: 복합 PK 일부에만 딸린 컬럼을 분리
   ▼
[2NF]  복합키 일부에만 종속된 컬럼 없음
   │
   │  ③ 3NF — 이행 함수 종속 제거: 비키 컬럼에 딸린 컬럼(A→B→C의 C)을 분리
   ▼
[3NF]  비키 컬럼 간 종속 없음   ← 대부분의 OLTP는 여기서 멈춤
   │
   │  ④ BCNF — 모든 결정자를 후보키로: 3NF가 못 잡는 결정자 이상 제거
   ▼
[BCNF]  각 사실이 정확히 한 곳에만 → 삽입·수정·삭제 이상 소멸

각 단계가 무엇을 쪼개고, 안 하면 어떤 이상이 남는가:

즉 정규화의 각 단계는 이상 현상 하나씩을 책임집니다. 삽입 이상은 "수강생 없는 새 과목"처럼 넣고 싶은 사실이 무관한 사실(학생)에 묶여 못 들어가던 것이, 사실을 각자 테이블로 분리하면서 풀립니다. 삭제 이상은 마지막 수강 행을 지울 때 함께 사라지던 과목 정보가 별도 테이블로 나가면서 보존됩니다. 진단은 역순으로 하면 빠릅니다 — 지금 테이블에서 "한 셀에 여러 값"이 보이면 1NF부터, "같은 값이 여러 행에 중복"이면 어떤 종속 때문인지(복합키 일부냐·비키 컬럼 경유냐)를 보고 2NF/3NF 중 어디가 덜 됐는지 좁힙니다. 대부분의 OLTP는 3NF에서 멈추고, BCNF는 결정자가 후보키가 아닌 드문 경우에만 갑니다.

정규화가 필요하다는 건 알겠는데 실제로 어떻게 적용하는지 모릅니다. 1NF, 2NF, 3NF가 각각 어떤 기준인지 이론은 외울 수 있어도 실제 테이블에 어떻게 적용하는지는 다른 문제입니다. 단계별로 같은 예시 테이블을 변환하면서 따라가면 각 단계가 어떤 문제를 해결하는지 명확하게 보입니다.

확대

1NF — 원자값과 반복 그룹 제거

규칙: 모든 컬럼 값은 더 이상 분해될 수 없는 원자값(Atomic Value)이어야 합니다. 반복 그룹(Repeating Group)도 금지됩니다.

하나의 셀에 '사과,바나나,딸기'처럼 여러 값을 콤마로 저장하는 것이 대표적인 위반입니다. 이런 구조에서는 특정 상품의 포함 여부를 검색하거나 한 항목만 수정하는 것이 불가능합니다. 해결책은 반복되는 값을 별도 행으로 분리하는 것입니다.

CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    customer VARCHAR(100) NOT NULL
);

CREATE TABLE order_items (
    order_id INT REFERENCES orders(order_id),
    product  VARCHAR(100) NOT NULL,
    quantity INT NOT NULL DEFAULT 1,
    PRIMARY KEY (order_id, product)
);

2NF — 부분 함수 종속 제거

규칙: 1NF를 만족하고, 복합 기본키의 일부에만 종속되는 컬럼이 없어야 합니다.

(order_id, product_id)가 복합 PK인 테이블에서, product_name과 unit_price는 order_id와 무관하게 product_id 하나만으로 결정됩니다. 이런 부분 함수 종속 컬럼은 별도 테이블로 분리해야 합니다.

CREATE TABLE products (
    id         INT PRIMARY KEY,
    name       VARCHAR(100) NOT NULL,
    unit_price NUMERIC NOT NULL
);

CREATE TABLE order_items (
    order_id   INT REFERENCES orders(id),
    product_id INT REFERENCES products(id),
    quantity   INT NOT NULL DEFAULT 1,
    PRIMARY KEY (order_id, product_id)
);

3NF — 이행 함수 종속 제거

규칙: 2NF를 만족하고, PK가 아닌 컬럼이 다른 PK가 아닌 컬럼에 종속되면 안 됩니다.

student_id → zip_code → city라는 종속 체인이 그 예입니다. city는 PK인 student_id가 직접 결정하는 값이 아니라 zip_code를 거쳐 간접적으로 결정됩니다. 같은 우편번호를 가진 학생이 100명이면 city 값도 100번 중복 저장됩니다.

CREATE TABLE zip_codes (
    zip_code VARCHAR(10) PRIMARY KEY,
    city     VARCHAR(100) NOT NULL,
    district VARCHAR(100)
);

CREATE TABLE students (
    student_id INT PRIMARY KEY,
    name       VARCHAR(100) NOT NULL,
    zip_code   VARCHAR(10) REFERENCES zip_codes(zip_code)
);

-- 같은 zip_code인데 city가 2개 이상 = 갱신 이상이 이미 발생한 증거
SELECT zip_code, COUNT(DISTINCT city) AS city_variants
FROM students_bad
GROUP BY zip_code
HAVING COUNT(DISTINCT city) > 1;

-- zip_code당 city 중복 저장 횟수(낭비 규모)
SELECT zip_code, city, COUNT(*) AS dup_rows
FROM students_bad
GROUP BY zip_code, city
ORDER BY dup_rows DESC;

 zip_code | city_variants
----------+---------------
 06236    |             2   -- '서울특별시' / '서울시' 혼재 → 갱신 이상

 zip_code |    city    | dup_rows
----------+------------+----------
 06236    | 서울특별시 |       84

역정규화(Denormalization) — 성능을 위해 의도적으로 중복 허용

정규화가 항상 정답은 아닙니다. 읽기 집중(Read-Heavy) 환경에서는 잦은 JOIN이 성능 병목이 됩니다.

아래 예시는 주문 목록 조회 시 매번 users 테이블과 JOIN하는 비용을 피하기 위해 orders 테이블에 고객 이름과 이메일을 직접 복사해 두는 역정규화 패턴입니다. 단, 사용자가 이메일을 변경하면 orders 테이블도 별도로 업데이트해야 하므로 애플리케이션 레벨에서 일관성 유지 전략을 수립해야 합니다.

CREATE TABLE orders (
    id             BIGSERIAL PRIMARY KEY,
    user_id        BIGINT NOT NULL REFERENCES users(id),
    customer_name  VARCHAR(100) NOT NULL,
    customer_email VARCHAR(255) NOT NULL,
    total_amount   NUMERIC(12, 2) NOT NULL,
    created_at     TIMESTAMP DEFAULT NOW()
);

정규화 단계 요약표

각 정규형이 무엇을 추가로 요구하는지 단계별로 정리하면, 내가 설계한 테이블이 어느 단계까지 만족하는지 진단하는 기준이 됩니다.

실전 가이드: 대부분의 OLTP(트랜잭션 처리) 시스템은 3NF까지 적용합니다. 성능 문제가 실제로 측정된 경우에만 역정규화를 선택하고, 애플리케이션 레벨에서 데이터 일관성을 유지하는 전략을 수립하세요.

정규화는 중복을 없애 갱신 이상을 막습니다. 역정규화는 읽기 성능을 위해 그 중복을 의도적으로 되살립니다 — 그런데 그 순간, 정규화가 없애 줬던 갱신 이상도 함께 돌아옵니다. 이것을 DB가 대신 막아 주지 않는다는 게 핵심입니다.

• 복사한 값은 원본과 따로 늙습니다: 조회를 빠르게 하려고 orders에 customer_email을 복사해 두면, 사용자가 users에서 이메일을 바꿔도 orders의 사본은 그대로입니다. 앱이 두 곳을 함께 갱신하지 않으면 같은 사람의 이메일이 두 값으로 갈립니다 — 정규화 단원에서 봤던 바로 그 수정 이상입니다.
• DB는 이 중복을 지켜 주지 않습니다: FK는 참조 무결성은 지키지만 복사본을 원본과 같게 유지하라는 규칙은 없습니다. 그 일관성은 전적으로 애플리케이션의 책임이 됩니다 — 트리거, CDC, 또는 주기적 대사(reconciliation) 중 무엇으로 맞출지 설계해야 합니다.
• 스냅샷과 캐시는 다릅니다: 주문 시점의 배송지·가격처럼 그때 값을 일부러 얼려 두는 스냅샷은 원본이 바뀌어도 갱신하면 안 됩니다 — 이건 역정규화가 아니라 의도된 이력입니다. 반대로 최신을 빠르게 보여주려는 캐시성 복제는 원본이 바뀌면 반드시 따라 갱신돼야 합니다. 이 둘을 구분하지 않으면 왜 옛날 값이 남지와 왜 과거 주문 금액이 바뀌지가 동시에 터집니다.
• 넓은 행은 갱신 비용도 큽니다: 여러 사본을 한 테이블에 몰아 넓어진 행은, 그중 한 컬럼만 바꿔도 MVCC 상 행 전체가 새 버전으로 복사됩니다. dead tuple과 인덱스 갱신이 늘어, 역정규화가 읽기를 아낀 만큼 쓰기·vacuum 비용을 지불하게 됩니다.

핵심은, 역정규화가 무료 성능이 아니라 일관성 유지 책임을 앱으로 옮겨 온 거래라는 점입니다. 그 책임을 설계하지 않은 역정규화는 반드시 데이터 불일치로 돌아옵니다.