새 기능 개발 전에 "ERD 먼저 그려봐"라는 말을 듣습니다. 네모와 선으로 이루어진 다이어그램인데, 어디서부터 시작해야 할지 모릅니다. 엔티티, 속성, 관계 — 이 세 가지를 정확히 이해해야 ERD가 코드보다 먼저 데이터 구조를 논의하는 팀 공용 언어가 됩니다.

확대

엔티티 (Entity)

엔티티는 비즈니스 도메인에서 독립적으로 식별 가능하고 데이터를 저장할 가치가 있는 객체나 개념입니다. ERD에서는 직사각형으로 표현되며, 데이터베이스에서 테이블이 됩니다.

엔티티를 식별할 때는 세 가지 질문을 던져봅니다. 이 개체에 대해 여러 데이터를 저장해야 하는가? 다른 개체와 구별되는 고유한 식별자가 있는가? 이 개체에 대한 쿼리가 자주 발생하는가? 쇼핑몰 도메인이라면 User, Product, Category, Order, OrderItem, Cart, Review가 엔티티 후보입니다.

강한 엔티티 vs 약한 엔티티:

모든 엔티티가 독립적으로 존재하는 것은 아닙니다. 부모 엔티티 없이는 의미가 없는 종속 엔티티를 약한 엔티티라고 부릅니다.

속성 (Attribute)

속성은 엔티티가 가지는 개별 데이터 항목입니다. ERD에서 타원으로 표현되며, DB에서 컬럼이 됩니다.

관계 (Relationship)와 카디널리티

관계는 두 엔티티 사이의 연관성을 나타냅니다. **카디널리티(Cardinality)**는 관계에 참여하는 인스턴스의 수입니다.

까마귀발 표기법 (Crow's Foot Notation)

까마귀발 표기법은 선 끝 기호로 최솟값(왼쪽 기호)과 최댓값(오른쪽 기호)을 동시에 표현합니다. 원(○)은 "0개 가능"을, 수직선(|)은 "정확히 1개"를, 까마귀발(<)은 "여러 개"를 나타냅니다.

확대

세 가지 관계 유형

1:1 관계 — 각 인스턴스가 정확히 하나의 상대 인스턴스와 연결됩니다. 구현 시 자식 테이블의 FK 컬럼에 UNIQUE 제약을 추가합니다.

User ──| ──| UserProfile — 한 사용자는 프로필을 정확히 하나만 가짐 (구현: UserProfile.user_id UNIQUE FK)

1:N 관계 — 하나의 인스턴스가 여러 상대 인스턴스와 연결됩니다. 가장 흔한 관계 유형입니다. 구현 시 N쪽 테이블에 FK 컬럼을 추가합니다.

Category ──| ──○< Product — 한 카테고리에 여러 상품이 속함 (구현: Product.category_id FK)

N:M 관계 — 양쪽 모두 여러 인스턴스와 연결됩니다. RDBMS에서는 직접 표현할 수 없으므로 중간 테이블로 분해합니다.

Order ○< ──── ○< Product — 한 주문에 여러 상품, 한 상품이 여러 주문에 포함 (구현: OrderItem 중간 테이블 필요)

ERD는 그렸는데 그 다음이 막막합니다 — 네모와 선을 어떻게 CREATE TABLE로 옮기죠? 다행히 변환은 감이 아니라 규칙입니다. 엔터티는 테이블, 속성은 컬럼, 식별자는 PK, 관계는 FK나 중간 테이블로 기계적으로 대응됩니다. 이 대응표를 손에 쥐면 ERD 리뷰가 끝나는 순간 스키마가 거의 자동으로 나오고, 흔한 실수(N:M을 FK로 직접 잇기)도 "규칙 위반"으로 즉시 걸러집니다.

[ERD 요소]                            [테이블 요소]
  엔터티(직사각형)          ──①──▶     테이블 하나
  속성(타원)                ──②──▶     컬럼 하나
  식별자(밑줄 친 속성)       ──③──▶     PRIMARY KEY
  관계 1:N (까마귀발)        ──④──▶     N쪽 테이블에 FK 컬럼
  관계 N:M (양쪽 까마귀발)   ──⑤──▶     중간(연결) 테이블 + FK 2개
  관계 1:1                  ──⑥──▶     한쪽에 FK + UNIQUE
  선택 참여(○, 0..)         ──⑦──▶     FK 컬럼 NULL 허용
  필수 참여(ㅣ, 1..)         ──⑦──▶     FK 컬럼 NOT NULL
   │
   ▼
  참조 순서대로(부모 먼저) CREATE TABLE → `\d 테이블`로 PK·FK·UNIQUE 검증

각 변환 규칙과, 여기서 자주 나는 실수:

즉 ERD → 테이블 변환은 요소별 1:1 대응이라 규칙만 지키면 기계적입니다. 두 축만 잡으면 대부분 풀립니다 — 관계의 카디널리티가 FK의 "위치"(N쪽)를 정하고, **참여(선택·필수)**가 FK의 "NULL 여부"를 정합니다. 가장 자주 터지는 N:M은 "관계형 DB는 N:M을 직접 못 잇는다 → 무조건 중간 테이블"로 외워 두세요. 그리고 관계선 하나를 FK로 옮길 때마다 "N쪽 FK 컬럼에 인덱스가 필요한가"를 세트로 결정하면, 뒤 심화에서 볼 부모 삭제 지연 사고를 미리 예방합니다.

ERD 표기법은 이해했는데 실제로 어떻게 그리는지 막막합니다. 상품, 주문, 사용자가 있는데 이들이 어떤 관계인지, N:M 관계를 테이블로 어떻게 표현하는지 모릅니다. 쇼핑몰 도메인은 JOIN, N:M, 중간 테이블을 모두 포함하는 실무 대표 케이스로, 이 설계를 따라가면 실제 프로젝트 ERD 작성이 가능해집니다.

확대

쇼핑몰 도메인 분석

SQL을 작성하기 전에 비즈니스 요구사항을 먼저 문장으로 정리합니다. 요구사항에서 명사는 엔티티 후보, 동사는 관계 후보가 됩니다.

• 사용자는 회원가입 후 로그인할 수 있다
• 상품은 카테고리에 속한다 (카테고리는 계층 구조)
• 사용자는 여러 상품을 장바구니에 담을 수 있다
• 사용자는 주문을 생성하고, 주문에는 여러 상품이 포함된다
• 사용자는 구매한 상품에 리뷰를 작성할 수 있다
• 상품은 여러 이미지를 가질 수 있다

쇼핑몰 ERD (까마귀발 ASCII 다이어그램)

아래 다이어그램에서 화살표 방향은 FK가 위치하는 쪽(N쪽)을 가리킵니다. categories의 parent_id는 같은 테이블을 참조하는 자기참조 관계로 계층 구조를 표현합니다.

확대

SQL 구현 — 핵심 테이블 생성

ERD를 확정한 뒤 SQL로 변환합니다. 테이블 생성 순서는 참조 방향에 따라 결정됩니다. 참조 대상(부모 테이블)을 먼저 생성해야 FK 선언이 가능합니다. 여기서는 categories → products → users → orders → order_items 순서입니다.

order_items의 unit_price는 products.price를 그대로 참조하는 것이 아니라 주문 시점의 가격을 별도로 저장합니다. 이후 상품 가격이 변경되어도 주문 당시 금액이 보존되어야 하기 때문입니다.

CREATE TABLE categories (
    id         SERIAL PRIMARY KEY,
    name       VARCHAR(100) NOT NULL,
    slug       VARCHAR(100) UNIQUE NOT NULL,
    parent_id  INT REFERENCES categories(id) ON DELETE SET NULL,
    created_at TIMESTAMP DEFAULT NOW()
);

CREATE TABLE products (
    id          SERIAL PRIMARY KEY,
    category_id INT NOT NULL REFERENCES categories(id),
    name        VARCHAR(255) NOT NULL,
    description TEXT,
    price       DECIMAL(12, 2) NOT NULL CHECK (price >= 0),
    stock       INT NOT NULL DEFAULT 0 CHECK (stock >= 0),
    created_at  TIMESTAMP DEFAULT NOW()
);

CREATE TABLE users (
    id         SERIAL PRIMARY KEY,
    email      VARCHAR(255) UNIQUE NOT NULL,
    password   CHAR(60) NOT NULL,
    name       VARCHAR(100) NOT NULL,
    created_at TIMESTAMP DEFAULT NOW()
);

CREATE TABLE orders (
    id         SERIAL PRIMARY KEY,
    user_id    INT NOT NULL REFERENCES users(id),
    status     VARCHAR(20) NOT NULL DEFAULT 'pending'
               CHECK (status IN ('pending','paid','shipped','delivered','cancelled')),
    total      DECIMAL(12, 2) NOT NULL,
    created_at TIMESTAMP DEFAULT NOW()
);

CREATE TABLE order_items (
    id         SERIAL PRIMARY KEY,
    order_id   INT NOT NULL REFERENCES orders(id) ON DELETE CASCADE,
    product_id INT NOT NULL REFERENCES products(id),
    quantity   INT NOT NULL CHECK (quantity > 0),
    unit_price DECIMAL(12, 2) NOT NULL,
    UNIQUE(order_id, product_id)
);

\d order_items

                          Table "public.order_items"
   Column   |     Type      | Nullable |              Default
------------+---------------+----------+-----------------------------------
 order_id   | integer       | not null |
 product_id | integer       | not null |
 unit_price | numeric(12,2) | not null |
Indexes:
    "order_items_pkey" PRIMARY KEY, btree (id)
    "order_items_order_id_product_id_key" UNIQUE CONSTRAINT, btree (order_id, product_id)
Foreign-key constraints:
    "order_items_order_id_fkey" FOREIGN KEY (order_id) REFERENCES orders(id) ON DELETE CASCADE
    "order_items_product_id_fkey" FOREIGN KEY (product_id) REFERENCES products(id)

N:M 중간 테이블의 핵심 원칙

N:M 관계를 중간 테이블로 분해할 때 지켜야 할 설계 원칙입니다. 두 FK의 조합에 UNIQUE 제약을 걸어야 같은 조합이 중복 삽입되는 것을 방지할 수 있습니다. 관계 자체에 속하는 데이터(수량, 가격 스냅샷 등)는 중간 테이블의 컬럼으로 추가합니다.

N:M 중간 테이블 설계 체크리스트:
  ✓ 양쪽 테이블의 PK를 FK로 포함
  ✓ 두 FK의 조합에 UNIQUE 제약 (중복 방지)
  ✓ 관계 자체에 속하는 속성은 중간 테이블 컬럼으로 추가
     예: order_items의 quantity, unit_price는 "주문-상품" 관계의 속성
  ✓ unit_price는 반드시 주문 시점 가격 스냅샷으로 저장
     (현재 products.price 참조 금지 — 가격 변경 시 과거 주문 금액 오염)

ERD에서 두 엔티티를 잇는 관계선 한 줄은, SQL에서 FK 제약 하나가 됩니다. 그리고 FK는 예쁜 그림이 아니라 런타임 비용과 잠금을 동반합니다. 관계선을 그릴 때 이 물리적 실체를 함께 결정해야 나중에 성능 사고를 피합니다.

• 자식에 INSERT하거나 FK 값을 UPDATE할 때, DB는 부모에 그 키가 있는지 확인합니다(참조 무결성 검사). 부모 PK에는 인덱스가 있으니 이 검사는 빠릅니다.
• 반대로 부모를 DELETE하거나 부모 키를 UPDATE할 때, DB는 그 값을 참조하는 자식이 있는지 확인해야 합니다. 이때 자식의 FK 컬럼에 인덱스가 없으면 자식 테이블을 순차 스캔하고, 그동안 관련 락을 잡습니다. PostgreSQL·MySQL 모두 자식 FK 컬럼 인덱스를 자동으로 만들어 주지 않습니다.
• 특히 ON DELETE CASCADE나 SET NULL이 걸린 관계, 부모를 자주 지우는 관계라면 자식 FK 컬럼 인덱스는 사실상 필수입니다.

여기에 더해, 중간(연결) 테이블의 PK를 두 FK의 복합 자연키로 할지 대리키(surrogate)로 할지도 조회·인덱스 설계에 영향을 줍니다. 결론은 하나입니다 — 관계선을 그릴 때 'N쪽(자식)의 FK 컬럼에 인덱스가 필요한가'를 세트로 결정하세요.