모델링 종합 실습 —
요구사항에서 ERD까지

이번 섹션의 여정

오늘 만들 것 — 상품 후기 기능

우리 shop에는 회원, 카테고리, 상품, 주문, 주문상세 다섯 테이블이 있습니다. 여기에 기능 하나를 얹어 볼게요.

이 문장 하나만 들고 바로 테이블을 그리기 시작하면 — 거의 반드시 다시 고치게 됩니다. 순서를 지켜서 가겠습니다.

① 요구사항의 빈칸부터 질문합니다

“회원이 상품에 후기를 남긴다” 는 문장만으로는 설계할 수 없습니다. 이 문장에는 정해지지 않은 것이 너무 많아요. 그러니 테이블을 만들기 전에 업무 담당자에게 물어봐야 합니다.

이번 실습에서는 담당자에게 이렇게 확인받았다고 하겠습니다.

그리고 이번 범위에서 정하지 않은 것도 있습니다. 이것을 따로 적어두는 게 중요해요.

② 새 테이블과 한 행의 의미를 정합니다

회원 정보는 members에, 상품 정보는 products에 이미 있습니다. 새로 필요한 건 회원과 상품 사이에 생긴 후기라는 기록이에요. 그래서 테이블 하나를 새로 만듭니다 — product_reviews.

그림보다 먼저 정할 것은 4-1에서 배운 그것입니다.

한 행의 의미가 정해지면 어떤 값이 필요한지가 따라 나옵니다.

여기서 넣고 싶어지는 컬럼이 하나씩 떠오를 거예요. 후기 목록에 회원 이름이랑 상품 이름도 같이 보여야 하는데, member_name이랑 product_name도 넣어둘까? — 4-5에서 다룬 그 유혹입니다.

반대로 rating, review_content, created_at은 그 후기에만 속한 사실입니다. 다른 어느 테이블에도 주인이 없어요. 그래서 여기에 둡니다.

③ 키 · 관계 · 제약을 업무 문장에서 옮깁니다

먼저 키입니다. 후기 한 건은 review_id로 구별합니다. member_id는 기존 회원을, product_id는 기존 상품을 가리키는 외래키예요.

다음은 관계입니다. 4-2에서 배운 대로 양쪽 방향에서 문장을 만들어 봅니다.

order_items가 orders와 products 두 부모를 참조했던 것과 같은 모양이에요. product_reviews도 부모가 둘입니다.

members  1..1 ───── 0..N  product_reviews  0..N ───── 1..1  products

product_reviews.member_id  → members.member_id
product_reviews.product_id → products.product_id

그런데 여기서 멈추면 요구사항 하나가 빠집니다.

그래서 관계선 밖의 제약을 따로 적습니다.

설계 결정이 코드로 어떻게 옮겨지는지

지금까지의 결정을 그대로 CREATE TABLE로 옮기면 이렇게 됩니다. 3-6에서 읽는 법을 배웠으니 — 문법을 외우려 하지 말고, 위에서 내린 결정이 어느 줄이 되었는지만 따라가 보세요.

CREATE TABLE product_reviews (
  review_id      INT      NOT NULL AUTO_INCREMENT,
  member_id      INT      NOT NULL,
  product_id     INT      NOT NULL,
  rating         INT      NOT NULL,
  review_content TEXT         NULL,
  created_at     DATETIME NOT NULL,
  updated_at     DATETIME     NULL,
  PRIMARY KEY (review_id),
  UNIQUE KEY uq_review_member_product (member_id, product_id),
  CONSTRAINT chk_review_rating CHECK (rating BETWEEN 1 AND 5),
  CONSTRAINT fk_review_member
    FOREIGN KEY (member_id)  REFERENCES members(member_id),
  CONSTRAINT fk_review_product
    FOREIGN KEY (product_id) REFERENCES products(product_id)
);

shop의 다른 테이블들과 비교해 보면 새로 등장한 제약은 두 개뿐입니다. UNIQUE KEY와 CHECK — 둘 다 요구사항을 지키기 위해 우리가 직접 결정해서 추가한 줄이에요.

④ 작은 사례로 검산합니다

여기까지가 설계입니다. 그런데 설계는 그려놓고 끝내는 게 아니라 검산해야 합니다. 실제 값을 몇 개 넣어보고, 처음 확인한 요구사항대로 허용되거나 막히는지 확인하는 거예요.

우리 shop의 진짜 데이터를 쓰겠습니다. 회원 1번은 김철수, 상품 23번은 데이터 모델링 실전(32,000원, 도서)입니다.

여덟 줄을 하나씩 짚어보면, 우리가 표로 적어둔 요구사항이 하나도 빠짐없이 구조 어딘가에서 지켜지고 있다는 걸 확인할 수 있습니다. 반대로 어떤 요구사항이 어느 줄에서도 지켜지지 않는다면 — 그건 설계에 구멍이 있다는 신호예요.

검산에서 걸러지지 않는 것도 있습니다. 예를 들어 “구매하지 않은 상품에도 후기를 쓸 수 있다” 는 지금 구조에서 그냥 통과해요. 이건 버그가 아니라 — 우리가 ①에서 “이번 버전에서는 조건으로 삼지 않는다”고 결정했기 때문입니다. 확인한 규칙과 미정 규칙을 분리해 뒀기 때문에, 통과한 이유를 설명할 수 있는 거죠.

⑤ AI는 설계자가 아니라 검토자로 씁니다

완성한 설계는 AI에게 검토를 맡길 수 있습니다. 다만 맡기는 방식이 결과를 완전히 바꿔요.

이렇게 요청하면 됩니다.

아래 요구사항과 제 설계를 비교해 주세요.
새 ERD를 다시 만들지 말고 다음 네 가지를 구분해서 알려주세요.

1. 제가 임의로 가정한 내용
2. 현재 구조가 막지 못하는 잘못된 사례
3. 빠진 제약
4. 최소 수정안

섹션 4가 쌓아 올린 것

오늘 한 바퀴 돌아본 과정은 사실 4-1부터 하나씩 배운 것들입니다.

한눈에 정리

관계선은 “존재하는 부모를 가리키는가”까지만 지켜줍니다. 중복 금지와 값의 범위처럼 선 밖의 규칙은 우리가 따로 적어야 해요. 그리고 그 모든 결정은 — 작은 사례를 넣어 검산했을 때 처음 확인한 요구사항과 같은 결과가 나와야 비로소 완성입니다.

여기까지가 데이터의 길을 만드는 일이었습니다. 이제 그 길에서 원하는 데이터를 실제로 꺼낼 차례예요. 모델링에서 만든 구조가 곧 SQL을 작성하는 지도가 됩니다.