[데이터베이스] 03. 데이터 모델링 (개체-관계 모델)
테이블을 곧장 만들기 전에, "현실 세계의 무엇을 어떻게 데이터로 옮길 것인가"를 먼저 설계해야 한다. 이 설계 과정이 데이터 모델링이고, 그 첫 단추가 개체-관계(ER, Entity-Relationship) 모델이다.
코드를 짜기 전에 그림을 그리는 단계라 처음엔 가볍게 봤는데, 여기서 구조를 잘못 잡으면 나중에 테이블·쿼리·정규화가 전부 어긋난다는 걸 알고 생각이 달라졌다. 오늘은 현실을 데이터로 번역하는 이 첫 단계를 정리했다.
1. 데이터 모델링과 데이터 모델
모델링은 추상도를 단계적으로 낮추며 진행된다. 현실에서 개념으로, 다시 논리로 내려가는 순서다.
| 단계 | 데이터 모델 | 결과물 |
|---|---|---|
| 개념적 | 개체-관계 모델(ER) | E-R 다이어그램(ERD) |
| 논리적 | 관계 데이터 모델 | 릴레이션(테이블) 스키마 |
이 글은 첫 단계인 개념적 모델링을 다룬다. 개념적 단계에서는 아직 "테이블이 몇 개고 열이 뭐다"를 정하지 않는다.
그보다 한 단계 위에서 "이 업무에는 어떤 대상들이 있고, 그들이 어떻게 엮이는가"를 사람이 알아보기 쉬운 그림으로 정리한다. DBMS(Database Management System) 종류(오라클이든 MySQL이든)와 무관하게 그릴 수 있다는 점이 핵심이라, 가장 먼저 그리고 가장 자유롭게 그린다.
2. 개체-관계 모델 (ER Model)
피터 첸(Peter Chen)이 제안한 개념적 데이터 모델. 현실 세계를 개체(Entity)와 개체 간 관계(Relationship)로 표현한다. 핵심 3요소는 개체·속성·관계다.
| 요소 | 의미 | ERD 기호 |
|---|---|---|
| 개체(Entity) | 서로 구별되는 사물·대상 | 사각형 |
| 속성(Attribute) | 개체가 갖는 특성 | 타원 |
| 관계(Relationship) | 개체 간의 연관성 | 마름모 |
예를 들어 수강 신청을 모델링한다면, "학생"과 "과목"이 개체(사각형), 학생의 "학번"·"이름"이 속성(타원), 둘을 잇는 "수강하다"가 관계(마름모)가 된다.
속성에도 종류가 있고, 이를 구분해두면 나중에 테이블 설계가 정확해진다.
속성의 종류
- 단일값 vs 다중값: 하나만 갖는 값(주민번호)과 여럿일 수 있는 값(전화번호 여러 개)으로 나뉜다. 다중값 속성은 이중 타원으로 표시한다.
- 단순 vs 복합: 더 못 쪼개는 값(나이)과 쪼갤 수 있는 값(주소 = 시+구+동)으로 나뉜다.
- 유도 속성: 다른 속성에서 계산되는 값(생년월일로부터 나이). 점선 타원으로 표시한다.
- 기본키(키) 속성: 개체를 유일하게 식별하는 속성. 타원 안 이름에 밑줄로 표시한다.
다중값 속성을 따로 구분하는 이유가 흥미로웠다. 관계형 테이블의 한 칸에는 값이 하나만 들어가야 한다는 원칙(1정규형)이 있어서, "전화번호 여러 개" 같은 다중값 속성은 그대로 한 칸에 넣을 수 없다.
그래서 개념 단계에서 이중 타원으로 표시해두면, 논리 단계에서 "이건 별도 테이블로 빼야겠다"는 판단으로 자연스럽게 이어진다. 개념적 표기 하나하나가 다 의미를 갖는 셈이다.
자기 속성만으로는 식별되지 않고 다른(강한) 개체에 의존해야만 존재하는 개체다. 예를 들어 "부양가족"은 어느 "직원"에 딸렸는지를 알아야 비로소 특정되고, 직원 데이터가 사라지면 함께 의미를 잃는다. ERD에서는 이중 사각형(개체)과 이중 마름모(관계)로 표시한다. "혼자 설 수 있는가"가 강한 개체와 약한 개체를 가르는 기준이다.
3. 관계의 유형 (매핑 카디널리티)
두 개체가 서로 몇 개씩 대응되는지를 나타내는 것이 매핑 카디널리티다.
| 유형 | 설명 | 예 |
|---|---|---|
| 일대일 (1:1) | 한쪽 하나가 다른 쪽 하나에만 대응 | 사람 ↔ 주민번호 |
| 일대다 (1:N) | 한쪽 하나가 다른 쪽 여럿에 대응 | 부서 ↔ 사원 |
| 다대다 (N:M) | 양쪽 모두 여럿에 대응 | 학생 ↔ 과목 |
논리적 모델로 변환할 때 다대다(N:M) 관계는 반드시 별도의 릴레이션(연결 테이블)으로 분리한다.
왜 N:M만 따로 테이블이 필요할까? 1:N은 "사원" 쪽에 소속 부서 번호 하나만 적어두면 표현된다(한 칸에 값 하나로 충분).
하지만 N:M에서는 한 학생이 여러 과목을, 한 과목이 여러 학생을 가지므로, 어느 쪽 테이블에 적어도 "한 칸에 값 여러 개"가 되어버린다. 다중값 문제와 똑같은 벽에 부딪히는 것이다.
그래서 "수강(학번, 과목번호)"처럼 두 키의 조합을 행으로 갖는 연결 테이블을 따로 만들어, (철수, DB) · (철수, OS) · (영희, DB)를 각각 한 행으로 푼다. N:M 관계가 연결 테이블을 요구하는 건 규칙이라서가 아니라, "한 칸에 값 하나"라는 원칙에서 필연적으로 따라오는 결과다.
오늘 느낀 점
- "코드보다 그림이 먼저"라는 게 격식 차리기가 아니라, 구조를 잘못 잡으면 뒤가 전부 어긋나기 때문이라는 걸 알았다. 개념 모델링을 가볍게 보던 시각이 바뀌었다.
- 다중값 속성, N:M 관계가 전부 "한 칸에 값 하나"라는 한 원칙에서 갈라져 나온다는 게 핵심이었다. 규칙을 따로 외우는 대신 원칙 하나로 묶이니 정리가 됐다.
- ERD 기호(사각형·타원·마름모)가 단순한 그림이 아니라, 논리 단계의 설계 판단으로 이어지는 신호라는 점이 인상에 남았다.
한 걸음 더
- 이 글의 사각형·타원·마름모는 피터 첸이 만든 원조 표기법(Chen notation)이다. 그런데 실무에서는 이보다 까마귀 발 표기법(Crow's Foot)이나 IE 표기법을 훨씬 많이 본다. 개체를 표로, 관계를 선으로 그리고 선 끝의 갈래(까마귀 발 모양)로 카디널리티를 나타내는 방식인데, ERD 툴(dbdiagram, ERwin 등)이 대부분 이 표기를 쓴다. 교재는 Chen, 현업은 Crow's Foot이라고 알아두면 양쪽이 헷갈리지 않는다.
- 약한 개체와 강한 개체를 잇는 관계를 식별 관계(identifying relationship)라 한다. 약한 개체의 기본키는 강한 개체의 키를 일부 빌려와 만들어지는데(예: 부양가족 키 = 직원번호 + 가족이름), 여러 속성을 묶어 하나의 키로 삼는다는 점에서 복합키(composite key)의 전형적인 사례이기도 하다.
- 개념적 모델링을 굳이 거치는 이유는, 이 단계 산출물(ERD)이 개발자뿐 아니라 현업·기획자와 소통하는 공통 언어가 되기 때문이다. SQL을 모르는 사람도 "학생과 과목이 N:M으로 엮인다"는 그림은 이해한다. 코드보다 그림이 먼저인 건, 기술이 아니라 합의를 먼저 맞추기 위해서다.