정규화 직관 —
왜 테이블을 나누는가

이번 섹션의 여정

만약 테이블이 나뉘어 있지 않았다면

4-1에서 “거대한 표 하나로 만들면 안 될까요” 라는 질문을 잠깐 던지고 지나갔습니다. 오늘은 그 표를 실제로 만들어 놓고 하나씩 뜯어보겠습니다.

우리 shop의 값을 그대로 쓰되, 다섯 테이블을 한 장으로 합쳤다고 상상해 볼게요.

한 행은 주문에 담긴 상품 한 종류입니다. 그래서 주문 1번은 두 줄, 주문 7번도 두 줄이 되죠.

보기에는 꽤 편해 보입니다. 조회할 때 다른 테이블을 찾아갈 필요도 없고요. 그런데 이 표에는 이미 문제가 심어져 있습니다.

한 줄 안에 다섯 가지 사실이 섞여 있습니다

첫 두 줄을 다시 보세요. 김철수와 2025-02-01은 똑같이 반복되는데, 상품명 · 카테고리 · 가격 · 수량은 서로 다릅니다.

같은 행에 있다고 해서 같은 성격의 값이 아니라는 뜻이에요. 한 줄을 성격별로 갈라 보면 이렇게 됩니다.

3-1에서 배운 “이 테이블에서 한 행의 주인공은 무엇이지” 라는 질문을 이 표에 던져 보세요. 답이 하나로 나오지 않습니다. 주문의 표 같기도 하고, 상품의 표 같기도 하고, 회원의 표 같기도 하죠.

값이 반복되는 것 자체는 문제가 아닙니다

여기서 흔한 오해 하나를 먼저 지우고 갑니다. 같은 값이 여러 줄에 보인다고 무조건 잘못된 설계가 아닙니다.

실제 shop의 orders 테이블에도 member_id = 1은 여섯 번 나옵니다. 김철수 회원의 주문이 6건이니까요. 이건 관계를 저장하기 위한 정상적인 반복입니다.

외래키 값이 반복되는 것은 “이 행이 누구에게 속하는지” 를 가리키는 표지입니다. 문제는 사실 그 자체를 여러 곳에 복사해 놓고 각자 관리하는 상태예요.

이제 그 상태에서 평범한 작업 세 가지를 해보겠습니다.

상황 하나 — 이름 하나 바꾸는 데 열다섯 줄

기획팀에서 카테고리 이름을 “의류” 에서 “패션” 으로 바꾸기로 했습니다. 실제 shop이라면 categories 테이블의 한 줄만 고치면 끝이에요.

그런데 넓은 표에서는 의류 상품이 담긴 주문상세 줄을 전부 찾아야 합니다.

열다섯 줄을 고치는 것 자체보다 무서운 건 한 줄을 놓쳤을 때 입니다. 열네 줄은 “패션”, 한 줄은 “의류”가 되죠. 그러면 같은 카테고리인데 이름이 두 개인 상태가 됩니다. DB는 그 한 줄이 틀렸다는 걸 알 방법이 없어요 — 어느 쪽이 진짜인지 판단할 근거가 표 안에 없으니까요.

상품 쪽도 똑같습니다. 라운드 티셔츠 가격이 19,000원에서 21,000원으로 오르면 네 줄을 모두 찾아 고쳐야 합니다.

상황 둘 — 아직 팔리지 않은 것은 적을 자리가 없습니다

이번에는 새 데이터를 넣어 봅니다. 넓은 표의 한 행은 주문에 담긴 상품 한 종류였죠. 그래서 주문이 없으면 행 자체가 생기지 않습니다.

가입만 하고 아직 주문하지 않은 백서윤 회원은 존재하지 않는 회원이 됩니다. 창고에 쌓여 있는 다크 초콜릿도 없는 상품이 되고요.

억지로 넣을 방법이 없는 건 아닙니다. 주문번호 · 상품명 · 수량을 비워둔 유령 행을 하나 만들면 되니까요. 하지만 그 순간 “한 행은 주문에 담긴 상품 한 종류” 라는 약속이 깨집니다. 이후 모든 집계가 그 유령 행을 걸러내는 조건을 달고 다녀야 해요.

상황 셋 — 주문을 지웠더니 상품이 사라졌습니다

마지막은 삭제입니다. 주문 12번을 취소해서 관련 줄을 지운다고 해봅시다. 실제 shop의 주문 12번에는 두 상품이 들어 있어요.

무선 이어폰은 주문 3 · 6 · 12 · 19 · 22 · 27번에 담겨 있어서, 12번 줄이 사라져도 다른 줄에 이름과 가격이 남습니다. 그런데 USB-C 케이블은 40건의 주문 중 12번에만 들어 있어요.

넓은 표에서 그 줄을 지우는 순간 “USB-C 케이블이라는 상품이 8,000원에 팔리고 있다” 는 사실까지 함께 지워집니다. 우리는 주문 하나를 취소했을 뿐인데 상품 목록에서 상품이 하나 사라진 겁니다.

해결은 하나 — 사실을 주인에게 돌려보내기

문제의 원인이 “한 표가 다섯 주인의 사실을 떠안고 있다” 였으니, 해결은 단순합니다. 각 사실을 자기 주인에게 돌려보내는 것.

이렇게 나누면 아까의 세 상황이 전부 조용해집니다.

수량의 주인은 주문과 상품의 만남입니다

회원 · 주문 · 상품 · 카테고리는 주인을 찾기 쉬웠습니다. 그런데 하나가 애매하게 남습니다. 수량은 누구의 사실일까요?

먼저 상품의 사실인지 확인해 봅니다. 프리미엄 그래놀라의 수량이 정해져 있다면 products 테이블에 두면 되겠죠.

그럼 주문의 사실일까요? 주문 1번의 수량을 하나로 적으려면 곤란해집니다.

수량은 상품만으로도, 주문만으로도 정해지지 않습니다. 주문 1번과 상품 16번이 함께 지목되어야 비로소 2라는 값이 정해져요.

order_items의 기본키가 (order_id, product_id) 복합키인 것도 같은 이유입니다. 이 행을 특정하려면 두 번호가 모두 필요하니까요. 4-3에서 본 quantity = 2가 “그래놀라는 언제나 2개” 가 아니라 “주문 1번에 그래놀라가 2개” 였던 이유가 여기 있습니다.

헷갈릴 때 던지는 한 문장

새 컬럼을 어디에 둘지 고민될 때는 이 순서로 물어보세요.

한눈에 정리

값이 반복된다는 이유만으로 표를 나누는 것이 아닙니다. 같은 사실을 여러 줄에서 따로 관리하고 있다면 그 사실을 한 명의 주인에게 돌려보내는 것 — 그게 정규화입니다.

이제 다섯 테이블이 왜 다섯 개인지 알았습니다. 다음 강의에서는 이렇게 나뉜 테이블을 실제로 따라가 볼 차례입니다.