396. Mapping 규칙 (ER 모델을 테이블로 변환)

⚠️ 이 문서는 화이트보드에 동그라미와 네모로 예쁘게 그려놓은 ER 다이어그램(개념적 설계)을, **실제 데이터베이스(MySQL, Oracle)에 CREATE TABLE 명령어로 집어넣기 위해 논리적인 표(Table) 형태로 번역하는 공식 규칙인 'Mapping Rule'**을 다룹니다.

핵심 인사이트 (3줄 요약)

본질: E-R 다이어그램의 '개체(Entity)'와 '관계(Relationship)'를 관계형 데이터베이스의 릴레이션(Table)과 외래 키(Foreign Key)로 변환하는 기계적인 번역 과정이다.

관계 매핑의 핵심: 1:1, 1:N, N:M 관계에 따라 외래 키(FK)를 누가 가져갈 것인지, 아니면 아예 새로운 교차 테이블(Mapping Table)을 만들어야 하는지가 결정된다.

다중값 속성 처리: 관계형 DB는 한 칸에 여러 값을 넣을 수 없으므로(제1정규형 위반), 다중값 속성(예: 취미)은 반드시 별도의 독립된 테이블로 쪼개어 빼내야 한다.

Ⅰ. 개요: 그림을 코드로 바꾸는 법 (Context & Necessity)

데이터베이스 설계는 3단계로 이루어진다.

개념적 설계: 기획자랑 회의하면서 화이트보드에 ERD(개체-관계도)를 그린다. (네모, 마름모, 동그라미)
논리적 설계: 그려진 ERD를 표(Table) 모양으로 바꾼다. (← Mapping Rule 적용 단계!)
물리적 설계: 표를 바탕으로 CREATE TABLE SQL을 치고 디스크에 저장한다.

화이트보드에 그려진 [학생] ---<수강>--- [과목] 이라는 그림을 보고, 신입 개발자에게 "이거 테이블로 만들어봐"라고 하면 제각각 다른 모양으로 테이블을 만들 것이다. 이를 방지하기 위한 전 세계 공통의 변환 공식이 바로 **매핑 룰(Mapping Rule)**이다.

📢 섹션 요약 비유: ER 다이어그램이 **'건축 조감도(예쁜 스케치)'**라면, 매핑 룰은 이 조감도를 보고 철근과 콘크리트가 어디에 얼마나 들어가야 하는지 정확히 계산해 내는 **'실시설계 도면(청사진)'**으로 변환하는 공식입니다.

Ⅱ. Mapping Rule 5대 공식 ★

시험과 실무에서 가장 중요한 변환 공식들이다.

1. 개체(Entity) $\rightarrow$ 릴레이션(Table)

ERD의 네모(개체)는 무조건 하나의 테이블이 된다.
그 개체에 달린 동그라미(속성)들은 테이블의 컬럼이 되고, 밑줄 친 속성은 기본 키(PK)가 된다.

2. 다중값 속성(Multi-valued Attribute) $\rightarrow$ 독립된 테이블

동그라미가 두 줄로 그려진 속성(예: 한 학생이 여러 개의 '취미'를 가짐).
RDB는 한 칸에 '축구, 독서'라고 쓸 수 없다. 따라서 [학생_취미]라는 새로운 테이블을 만들어 분리하고, 학생의 PK(학번)를 외래 키로 가져와 붙인다.

3. 1:1 관계의 매핑

[남편] - (결혼) - [아내]
둘 중 아무 테이블이나 선택해서 상대방의 기본 키(PK)를 외래 키(FK)로 가져온다. (남편 테이블에 '아내 주민번호'를 넣거나, 그 반대로 해도 됨)

4. 1:N 관계의 매핑 ★ (가장 흔함)

[부서(1)] - (소속) - [직원(N)]
규칙: 무조건 'N' 쪽(직원) 테이블이 '1' 쪽(부서)의 기본 키를 외래 키(FK)로 가져온다.
이유: 부서 테이블에 직원 사번을 적으려면 한 칸에 100명의 사번을 적어야 하지만(불가능), 직원 테이블에 부서 번호를 적는 건 1개만 적으면 되기 때문이다.

5. M:N 관계의 매핑 ★ (가장 중요)

[학생(M)] - (수강) - [과목(N)]
학생 테이블에 과목 코드를 넣을 수도 없고, 과목 테이블에 학번을 넣을 수도 없다. (양쪽 다 다중값이 됨)
규칙: 관계 자체(마름모)를 **새로운 교차 테이블(Mapping Table)**로 만든다. 이름은 [수강_테이블]이 되고, 학생의 PK(학번)와 과목의 PK(과목코드)를 둘 다 외래 키로 가져와서 두 개를 합쳐서 자신의 복합 기본 키(PK)로 삼는다.

Ⅲ. 1:N 관계에서 FK 위치 찾기 꿀팁

시험 문제에서 "다음 ERD를 테이블로 바꿀 때, 외래 키(FK)는 어디에 위치하는가?"라고 물으면 1초 만에 대답해야 한다.

"까마귀 발(N)이 찍힌 쪽이 외래 키(FK)를 꿀꺽 삼킨다!"
예: [학과] 1 ---- N [학생] $\rightarrow$ 학생 테이블에 학과_코드(FK) 컬럼이 추가됨.

┌──────────────────────────────────────────────────────────────┐
│           M:N 관계를 교차 테이블로 해소하는 Mapping 과정 시각화         │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│ [ ERD (그림) ]                                                │
│  [학생(M)] ━━━━━ <수강> ━━━━━ [과목(N)]                          │
│                                                              │
│          ▼ (Mapping Rule 5번 적용)                             │
│                                                              │
│ [ 논리적 릴레이션 (표) ]                                          │
│  1. 학생 테이블:  [학번(PK), 이름]                                │
│  2. 과목 테이블:  [과목코드(PK), 과목명]                            │
│  3. 수강 테이블:  [학번(FK), 과목코드(FK), 수강년도]  ◀── (새로 탄생!)  │
│                                                              │
│ ★ 결과: M:N이라는 끔찍한 관계가, 두 개의 1:N 관계로 우아하게 풀림!        │
└──────────────────────────────────────────────────────────────┘

Ⅳ. 결론

"데이터베이스의 뼈대는 ERD를 그리는 순간 이미 90% 결정된다." Mapping Rule은 단순한 암기 공식이 아니다. 관계형 데이터베이스가 가진 물리적 한계(한 칸에는 하나의 값만 들어가야 한다)를 논리적으로 극복하기 위한 수십 년 된 지혜의 결정체다. 특히 N:M 관계를 교차 테이블로 풀어내는 과정은, JPA(Hibernate) 같은 현대의 ORM 프레임워크에서 @ManyToMany 애노테이션을 썼을 때 백그라운드에서 자동으로 매핑 테이블이 튀어나오는 원리와 100% 일치한다.

📌 관련 개념 맵

설계 단계: 개념적 설계 (ERD) $\rightarrow$ 논리적 설계 (Mapping Rule) $\rightarrow$ 물리적 설계
핵심 요소: Entity (개체), Attribute (속성), Relationship (관계), Cardinality (1:N 등)
제약 조건: Primary Key (기본 키), Foreign Key (외래 키)
정규화: 이 규칙을 완벽하게 지키면 자연스럽게 **제1정규형(1NF)**이 달성된다.

👶 어린이를 위한 3줄 비유 설명

ERD가 "레고로 멋진 성을 만들자!"라고 그린 '상상도 스케치'라면, 매핑 룰(Mapping Rule)은 그 스케치를 보고 "빨간 블록 10개, 파란 블록 5개가 필요해"라고 적어놓은 '조립 설명서'예요.
학생(N) 30명이 1개의 교실(1)에 들어가는 상황을 생각해 봐요.
교실 문패에 30명 이름을 다 적는 건 힘드니까, 학생 30명 각자의 가슴에 "나는 3반(교실 번호)"이라는 명찰(외래 키)을 달아주는 게 훨씬 똑똑한 방법이죠! 이게 바로 1:N 매핑 규칙이랍니다.