지난 글에서는 데이터 모델링의 첫 단계인 개념 모델까지 다뤘습니다. 엔터티·속성·관계라는 세 단어로 사업 전체의 데이터 윤곽을 잡는 단계였습니다.
이 글은 그 다음 단계인 논리 모델입니다. 그중에서도 식별자, 식별/비식별 관계, M:N 관계 해소까지 다룹니다. 정규화는 다음 회차로 미룹니다.
1단계의 개념 모델이 "손으로 쓱 그린 스케치"였다면, 논리 모델은 그 스케치에 치수를 넣는 단계입니다. 정식 도면에 해당합니다.
논리 모델에서 확정하는 것은 세 가지입니다.
여기서 중요한 것은, 논리 모델에서는 아직 DBMS(Oracle / MySQL 등)를 신경 쓰지 않는다는 점입니다. 그것은 물리 모델에서 정합니다.
회원이 5천 명 있고 동명이인 "김민수"가 세 명이라면, 이름만으로는 한 명을 특정할 수 없습니다. 데이터는 각 줄을 확실하게 하나로 콕 집어낼 수단이 반드시 있어야 합니다. 그 수단을 식별자(Identifier)라고 부릅니다.
학번, 주민등록번호, 사원번호, 차량번호판 같은 것을 떠올리면 됩니다. "이것만 보면 누구인지 100% 특정된다"가 식별자의 핵심입니다. 물리 모델로 가면 식별자는 기본키(Primary Key, PK)가 됩니다.
| 조건 | 뜻 | 위반 예시 |
|---|---|---|
| 유일성 | 값이 절대 겹치지 않는다 | 이름 — 동명이인 때문에 탈락 |
| 최소성 | 구분에 필요한 만큼만, 군더더기 없이 | 회원번호로 충분한데 (회원번호+이름) 사용 시 위반 |
| 불변성 | 한번 정해진 값이 바뀌지 않는다 | 전화번호 — 변경되므로 부적절 |
이메일은 유일성은 만족하지만, 사용자가 변경하면 불변성이 깨집니다. 그래서 실무에서는 의미 없는 번호(회원번호)를 새로 만들어 식별자로 쓰는 경우가 많습니다.
분류 기준이 여러 개입니다. 기준별로 따로 보면 쉽습니다.
기준 ① 대표성
기준 ② 속성 개수
수강신청은 학번 + 과목코드를 합쳐야 한 줄이 특정됩니다.기준 ③ 의미 유무 (가장 중요)
id, 주문번호 등이 여기에 속합니다.자동 증가 id를 PK로 쓰는 것이 인조식별자입니다. 짧고, 안 변하고, 관리가 단순해서 실무에서 자주 씁니다. 다만 업무 식별자가 깔끔하면 본질식별자가 더 나을 때도 있습니다.
회원 1 : N 주문 관계에서, 주문 한 건은 "어느 회원의 주문인지" 알아야 합니다. 그래서 주문은 자기 속성에 회원번호를 가집니다. 이렇게 부모 엔터티의 식별자를 자식이 물려받은 속성을 외래식별자라고 부릅니다. 물리 모델로 가면 외래식별자는 외래키(Foreign Key, FK)가 됩니다.
여기서 핵심 질문이 갈립니다. 물려받은 부모 식별자를 자식은 어떤 자격으로 가지는가? 답에 따라 관계가 두 갈래로 나뉩니다.
부모 식별자가 자식에게 와서 자식의 주식별자(의 일부)로 쓰이는 경우입니다.
예를 들어 주문 → 주문상세 관계를 봅니다. 주문상세의 식별자는 주문번호 + 상품번호입니다. 부모(주문)의 주문번호가 자식 식별자의 일부로 들어와 있습니다. 이 경우 자식은 부모 없이는 존재 자체가 성립하지 않습니다.
부모 식별자가 자식에게 오긴 하지만, 자식의 식별자로는 안 쓰이고 참조용 일반 속성으로만 들어가는 경우입니다.
예를 들어 회원 → 주문 관계가 그렇습니다. 주문은 이미 자기 식별자 주문번호를 가집니다. 회원번호는 "누구 주문인지" 알려주는 참조 정보일 뿐입니다.
| 구분 | 식별관계 | 비식별관계 |
|---|---|---|
| 물려받은 부모 키의 역할 | 자식의 주식별자 일부 | 자식의 일반 속성 |
| 자식이 독립적으로 존재 가능? | 불가능 (부모 없으면 성립 안 됨) | 가능 (자기 식별자 있음) |
| 예시 | 주문 → 주문상세 | 회원 → 주문 |
판별법은 한 문장입니다. "자식이 자기 식별자만으로 한 줄을 콕 집어낼 수 있는가?" 못 하면 식별관계, 할 수 있으면 비식별관계입니다.
이 구분이 중요한 이유는 모델 전체의 모양을 좌우하기 때문입니다. 식별관계로 잡으면 자식 식별자가 점점 길어집니다(부모 키가 계속 쌓입니다). 비식별관계로 잡으면 식별자는 짧게 유지되지만 연결고리가 느슨해집니다. 어느 쪽으로 설계하느냐가 이후 테이블 모양과 조인 비용에 그대로 반영됩니다.
회원과 상품을 생각해 봅니다. 회원 한 명이 여러 상품을 찜하고(M), 상품 하나도 여러 회원이 찜합니다(N).
회원 테이블에 "찜한 상품 목록"을 넣으려면 한 칸에 여러 값을 욱여넣어야 합니다. 관계형 DB는 한 칸에 값 하나가 원칙이라 깔끔하게 표현되지 않습니다.
회원과 상품 사이에 새 엔터티 찜을 만듭니다.
| 회원번호 | 상품번호 | 찜한일시 |
|---|---|---|
| 1001 | A | 2026-05-01 |
| 1001 | B | 2026-05-02 |
| 1002 | A | 2026-05-03 |
"회원 1001이 상품 A를 찜했다"가 한 줄입니다. 찜할 때마다 줄이 하나 생깁니다.
이렇게 하면 M:N이 두 개의 1:N으로 쪼개집니다.
[변환 전]
회원 ───── M:N ───── 상품
[변환 후]
회원 ── 1:N ── 찜 ── N:1 ── 상품그리고 찜의 식별자는 회원번호 + 상품번호 복합식별자입니다. 앞 절에서 본 복합식별자와 식별관계가 그대로 적용되는 구조입니다.
교차 엔터티는 단순히 두 엔터티를 잇는 다리가 아닙니다. 자기만의 속성을 가질 수 있습니다.
찜은 찜한일시를 가집니다.수강신청이라면 신청일자, 성적 등이 들어갑니다.처음에는 단순 다리처럼 보이던 것이 나중에 가장 중요한 엔터티가 되기도 합니다. 주문 시스템에서 주문은 원래 회원과 상품 사이의 교차 엔터티에서 출발했지만, 실무에서는 가장 핵심 엔터티 중 하나가 되는 식입니다.
논리 모델은 개념 스케치에 치수를 넣는 단계입니다. 속성을 빠짐없이 채우고, 식별자를 정하고, 관계를 DB에서 다룰 수 있는 형태로 다듬습니다.
식별자는 데이터 한 줄을 콕 집어내는 열쇠이며, 물리 모델의 기본키(PK)가 됩니다. 갖춰야 할 조건은 유일성·최소성·불변성 세 가지이고, 분류 기준은 대표성(주/보조), 개수(단일/복합), 의미 유무(본질/인조) 세 가지입니다.
외래식별자는 부모 식별자를 자식이 물려받은 속성이며, 물리 모델의 외래키(FK)가 됩니다. 물려받은 키가 자식 식별자의 일부로 쓰이면 식별관계(주문 → 주문상세), 단순 참조 속성이면 비식별관계(회원 → 주문)입니다. 판별 기준은 한 문장으로 정리됩니다. "자식이 자기 식별자만으로 한 줄을 구분할 수 있는가?"
M:N 관계는 DB에 그대로 만들 수 없습니다. 사이에 교차 엔터티를 두어 1:N + 1:N으로 쪼갭니다. 교차 엔터티는 단순 다리가 아니라 자기 속성을 가질 수 있고, 때로는 모델의 중심이 됩니다.
다음 글에서는 논리 모델의 나머지 절반인 정규화를 다룹니다.