[Database Modeling#4] 테이블 분리 규칙

관계형 데이터베이스를 설계할 때 가장 많이 하는 실수는 “무엇을 기준으로 테이블을 나눌 것인가?에 대한 기준 없이 시작하는 것입니다.

이 글에서는 실무와 학습에서 꼭 필요한 DB 테이블 분리 규칙 4가지를 예시 중심으로 정리했습니다.

 

규칙 1. 한 칸에는 한 가지 정보만 들어가도록 만들어라.

테이블의 각 컬럼은 하나의 의미만 담아야 합니다.

 

예를 들어, 아래와 같은 테이블과 같이 하나의 칸 내 쉼표 등으로 여러 이메일이 나눠있게 되면 나중에 데이터 삽입, 삭제 등 수정 시 오류 발생 가능성이 증가하게 됩니다.

id (PK)	이름	이메일
1	홍길동	gd123@naver.com, gd00@naver.com
2	김철수	king123@naver.com, queen123@naver.com

 

 

따라서 아래와 같이 테이블을 분리해야 합니다.

 

id (PK)	이름
1	홍길동
2	김철수

id (PK)	이메일	사용자 id (FK)
1	gd123@naver.com	1
2	gd00@naver.com	1
3	king123@naver.com	2
4	queen123@naver.com	2

 

하지만, '한 가지 정보'의 기준은 절대적이지 않습니다.

 

이름의 경우

아래와 같이, 하나의 칸에 '이름' 전체를 넣는 것이 맞을 수도 있고, 

'성'과 '이름'을 분리하는 것이 더 적절할 수도 있습ㄴ디ㅏ.

따라서, 이는 서비스 사용 방식에 따라 결정해야 합니다.

id	이름
1	홍길동

id	성	이름
1	홍	길동

 

규칙 2. 테이블 분리 후 FK의 위치가 애매할 땐 관계(1:1, 1:N, N:M)를 파악하라.

테이블을 나눌지, 외래 키를 어디 둘지 애매할 땐 데이터 간의 관계부터 파악하는 것이 필요합니다.

 

관계	설명	예시	설계 방식
1:1	양쪽이 하나씩만 가짐	유저 ↔ 프로필	나눌 수도, 합칠 수도 있음
1:N	한 쪽은 하나, 다른 쪽은 여러 개	작가 ↔ 책	다수 쪽(책)에 외래키
N:M	양쪽 모두 여러 개 가능	학생 ↔ 과목	중간 테이블 필요

관계 파악을 위해서는 아래 질문들을 던져보면 쉽게 파악 가능합니다.

 

• A는 B를 하나만 가질 수 있는가?
  → 예: 책은 작가를 하나만 가질 수 있음 → 1
• B는 A를 여러 개 가질 수 있는가?
  → 예: 작가는 여러 책을 쓸 수 있음 → N
• 양쪽 모두 여러 개를 가질 수 있는가?
  → 예: 학생도 여러 과목 수강, 과목도 여러 학생이 수강 → N:M

추가적으로, N:M 관계에서는 반드시 중간 테이블을 만드는 것이 필요합니다.

 

❌ 잘못된 구조
(한 칸에 여러 개의 값이 들어가 있어 규칙 1 위반)

id	이름	수강 과목
1	시온	수학, 영어, 과학

 

✅ 바람직한 구조
(중간 테이블을 사용해 관계를 명확하게 분리)

 

Students

id	이름
1	시온

Subjects

id	과목명
1	수학
2	영어
3	과학

Student_Subjects (중간 테이블)

student_id	subject_id
1	1
1	2
1	3

 

 

규칙 3. 가짜 중복과 진짜 중복을 구별해라.

테이블을 설계하다 보면, 겉으로 보기엔 데이터가 중복된 것처럼 보이는 상황이 자주 발생합니다.
하지만 이 중에는 실제로 중복된 정보도 있고, 단순히 같은 값이 반복된 것뿐인 정보도 있습니다.
이 둘을 정확히 구분하는 것이 중요합니다.

 

아래 예를 통해 알아보겠습니다.

 

posts (게시글)

id	제목	내용	작성자
1	[속보] 개발자 채용 확대	내용	홍길동
2	[속보] 개발자 채용 확대	내용	홍길동
3	[속보] 개발자 채용 확대	내용	홍길동

질문을 던져보자:

1. 1번 게시글의 작성자 이름을 수정하면, 2번도 같이 수정되어야 할까?
   → Yes! → 진짜 중복
2. 1번 게시글의 제목을 수정하면, 2번도 같이 수정되어야 할까?
   → No! → 가짜 중복
3. 1번 게시글의 내용을 수정하면, 2번도 같이 수정되어야 할까?
   → No! → 가짜 중복

 

규칙 4. 숨어있는 중복을 찾아라.

숨어있는 중복(hidden duplication)은 눈에 보이지 않지만, 데이터 흐름상 중복과 동일한 문제를 일으키는 구조입니다.

 

posts

id	제목	내용	좋아요 수	사용자 id
1	제목1	내용1	2	1

likes

id	사용자 id	게시글 id
1	1	1
2	2	1

 위 posts 테이블에서 저장되어 있는 '좋아요 수' 컬럼의 경우, 만일 어떤 사용자가 좋아요를 취소했을 경우, 해당 정보가 반영되기 어렵습니다.

 

따라서, '좋아요 수' 컬럼처럼 집계 함수가 포함된 컬럼의 경우 저장하지 않고 필요시 계산하는 것이 효율적입니다.