SQLD 데이터 모델링은 용어를 따로 외우면 금방 섞인다. 엔터티·속성·관계·식별자는 하나의 주문 업무를 데이터 구조로 바꾸는 도구이고, 정규화는 그 구조에서 중복과 이상 현상을 줄이는 과정이다. 이 글은 온라인 쇼핑 주문 예시 하나를 끝까지 사용해 개념 모델부터 정규화와 성능 검토까지 연결한다.
먼저 보는 결론: 업무를 엔터티·속성·관계로 표현하고 식별자로 구분한 뒤 정규화한다. 성능 보완은 처음부터 중복을 넣는 일이 아니라, 정규화된 모델을 실제 트랜잭션과 실행 결과로 검증한 다음 결정한다.
한국데이터산업진흥원의 현재 안내에서 SQLD는 2과목 50문항이며, 데이터 모델링의 이해는 10문항·20점이다. 이 영역은 ‘데이터 모델링의 이해’와 ‘데이터 모델과 SQL’로 나뉘며 엔터티·속성·관계·식별자, 정규화, 관계와 조인, 트랜잭션, NULL, 본질식별자와 인조식별자를 다룬다. 예전 자료의 ‘데이터 모델과 성능’ 목차만 외우기보다 공식 시험 범위를 기준으로 공부하는 편이 안전하다.
같은 고객명이 여러 주문서에 중복되면 이름 하나를 바꿀 때도 모든 행을 찾아 고쳐야 한다.
1. 데이터 모델링은 현실 업무를 데이터 구조로 바꾸는 일이다
데이터 모델링은 현실의 업무를 데이터 관점에서 분석하고, 데이터베이스로 구현할 수 있는 구조로 표현하는 과정이다. 온라인 쇼핑몰을 예로 들면 “고객이 상품을 주문한다”라는 문장을 고객·주문·상품·주문항목이라는 대상으로 나누고, 각각 어떤 정보를 가지며 어떻게 연결되는지 결정한다.
| 특징 | 뜻 | 주문 업무 예시 |
|---|---|---|
| 추상화 | 현실에서 필요한 부분만 뽑는다. | 고객의 모든 특징이 아니라 고객ID·이름처럼 주문에 필요한 정보만 선택한다. |
| 단순화 | 복잡한 현실을 정해진 표기법으로 줄인다. | “고객은 여러 번 주문할 수 있다”를 고객 1 : 주문 N으로 표현한다. |
| 명확화 | 애매함 없이 누구나 같은 뜻으로 읽게 한다. | 주문금액이 상품 정가인지 실제 결제 단가인지 속성 정의서에 구분한다. |
모델링은 데이터 관점, 프로세스 관점, 데이터와 프로세스의 상관 관점에서 살핀다. 데이터 관점은 무엇을 저장하는지, 프로세스 관점은 업무가 무엇을 하는지, 상관 관점은 특정 업무가 어떤 데이터를 만들고 조회하고 수정하는지 확인한다.
개념·논리·물리 모델의 차이
| 단계 | 핵심 질문 | 결과 |
|---|---|---|
| 개념 모델 | 업무에 어떤 핵심 대상이 있는가? | 고객·주문·상품 같은 핵심 엔터티와 큰 관계 |
| 논리 모델 | 각 대상은 어떤 속성과 식별자를 가지는가? | 엔터티·속성·관계·식별자·정규화가 반영된 구조 |
| 물리 모델 | 선택한 DBMS에 어떻게 구현할 것인가? | 테이블명, 컬럼명, 자료형, PK·FK, 인덱스, 파티션 |
개념 모델은 업무 담당자와 큰 그림을 맞추는 단계이고, 논리 모델은 DBMS와 독립적으로 데이터 구조를 구체화하는 단계다. 물리 모델에서 PostgreSQL이나 Oracle 같은 실제 DBMS의 자료형과 저장 방식, 성능 요소를 반영한다.
고객의 주문 업무가 개념·논리·물리 모델로 구체화되고, 정규화 후 실제 성능을 검증하는 흐름
2. 3층 스키마와 데이터 독립성은 서로 묶어서 외운다
개념·논리·물리 모델링 단계와 외부·개념·내부 스키마는 비슷하게 보여도 같은 분류가 아니다. 모델링 단계는 설계가 구체화되는 과정이고, 3층 스키마는 하나의 데이터베이스를 사용자·전체 구조·저장 구조 관점으로 나눈 것이다.
- 외부 스키마: 사용자나 응용 프로그램별로 필요한 데이터의 관점이다.
- 개념 스키마: 조직 전체 데이터베이스의 통합된 논리 구조다.
- 내부 스키마: 파일, 인덱스, 저장 위치처럼 데이터가 실제 저장되는 구조다.
원문 오류 교정: 논리적 독립성과 물리적 독립성의 설명이 서로 바뀌어 있었다. 아래 구분이 맞다.
| 독립성 | 바뀌는 것 | 영향받지 않아야 하는 것 | 예시 |
|---|---|---|---|
| 논리적 독립성 | 개념 스키마 | 외부 스키마와 응용 프로그램 | 고객 엔터티에 등급 속성을 추가해도 기존 주문 조회 화면은 유지된다. |
| 물리적 독립성 | 내부 스키마 | 개념·외부 스키마와 응용 프로그램 | 인덱스를 추가하거나 저장 장치를 바꿔도 테이블의 논리 구조는 유지된다. |
암기: 논리 구조 변경을 외부 사용자에게 숨기면 논리적 독립성, 저장 방식 변경을 논리 구조에 숨기면 물리적 독립성이다.
3. 엔터티·속성·관계·식별자는 한 문장으로 연결된다
“고객이 상품을 주문한다”를 모델로 바꾸면 고객·주문·상품·주문항목은 엔터티, 고객ID와 주문일은 속성, 고객과 주문 사이의 1:N 연결은 관계, 고객ID와 주문ID는 각 인스턴스를 구분하는 식별자가 된다.
엔터티와 인스턴스
엔터티는 업무에서 관리할 필요가 있는 대상의 집합이다. ‘고객’은 엔터티이고 ‘고객ID 101인 김하나’는 고객 엔터티의 인스턴스다. 속성과 인스턴스를 같은 것으로 보면 안 된다. 고객ID와 이름은 속성이며, 각 고객 한 명 한 명이 인스턴스다.
| 분류 기준 | 종류 | 예시 |
|---|---|---|
| 유·무형 | 유형 / 개념 / 사건 | 상품 / 조직 / 주문 |
| 발생 시점 | 기본 / 중심 / 행위 | 고객·상품 / 주문 / 주문항목 |
시험에서는 엔터티가 업무에 필요하고, 식별 가능하며, 인스턴스의 집합이고, 속성을 가지며, 업무 프로세스에서 사용되고, 다른 엔터티와 관계를 맺는지 확인한다. 다만 코드성 엔터티처럼 업무 특성상 관계가 생략될 수 있는 예외도 문맥과 함께 판단해야 한다.
속성과 도메인
속성은 업무에서 관리하려는 의미상 더 나누지 않는 최소 데이터 단위다. 고객 엔터티의 고객ID·이름, 주문 엔터티의 주문일이 속성이다. 하나의 인스턴스에서 하나의 속성은 원칙적으로 하나의 값을 가진다.
- 기본 속성: 이름처럼 업무에서 바로 얻은 값
- 설계 속성: 고객ID처럼 업무 규칙을 위해 만든 값
- 파생 속성: 주문합계처럼 다른 값에서 계산한 값
도메인은 속성이 가질 수 있는 값의 범위다. 수량은 1 이상의 정수, 주문상태는 ‘결제대기·결제완료·배송중·완료’ 중 하나라는 규칙이 도메인에 해당한다.
관계의 차수와 선택성
관계는 엔터티 인스턴스 사이의 논리적 연관이다. 관계명, 관계 차수, 선택성을 함께 읽어야 한다. 고객 한 명이 여러 주문을 만들 수 있으므로 고객과 주문은 1:N이다. 주문은 반드시 고객에 속하지만, 가입 직후 고객은 주문이 없을 수도 있다. 이때 고객 쪽에서 주문 참여는 선택적이다.
좋은 식별자의 네 조건
- 유일성: 모든 인스턴스를 하나씩 구분한다.
- 최소성: 유일성을 만족하는 최소 속성만 사용한다.
- 불변성: 값이 자주 바뀌지 않는다.
- 존재성: 반드시 값이 있어야 하며 NULL을 허용하지 않는다.
주식별자는 대표성이 있고 다른 엔터티에서 참조할 수 있다. 보조식별자는 유일하게 구분할 수 있지만 대표 식별자로 선택되지 않은 후보다. 내부식별자는 자신의 속성으로 만들고, 외부식별자는 다른 엔터티의 관계를 통해 받아온다. 주문항목의 주문ID는 주문 엔터티에서 받은 외부식별자다.
4. 정규화는 넓은 주문표를 역할별 테이블로 나누는 과정이다
다음처럼 한 행에 주문·고객·상품 정보를 모두 저장하면 같은 고객명과 상품명이 주문항목마다 반복된다.
주문상세(
주문ID, 주문일,
고객ID, 고객명,
상품ID, 상품명, 상품가격,
수량, 판매단가
)이 구조에서는 고객 이름을 바꿀 때 여러 행을 수정해야 하고, 주문이 없는 상품은 저장하기 어렵고, 마지막 주문항목을 지우다가 상품 정보까지 사라질 수 있다. 각각 수정 이상, 삽입 이상, 삭제 이상이다.
1차 정규형: 한 칸에는 하나의 값
하나의 주문 행에 ‘운동화, 가방, 머그컵’을 쉼표로 저장하면 상품별 수량이나 가격을 안정적으로 다룰 수 없다. 상품 하나를 주문항목 한 행으로 분리해 모든 속성이 원자값을 갖게 만든다.
2차 정규형: 복합키 일부에만 의존하는 속성 분리
주문항목의 식별자를 (주문ID, 상품ID)라고 하면 주문일과 고객ID는 주문ID에만 의존하고, 상품명과 상품가격은 상품ID에만 의존한다. 복합키 전체가 아니라 일부에만 의존하는 부분 함수 종속을 제거해 주문과 상품 테이블로 분리한다.
3차 정규형: 일반 속성에 의존하는 속성 분리
주문 테이블에 고객ID와 고객명을 함께 두면 고객명은 주문ID가 아니라 고객ID를 통해 결정된다. 주문ID → 고객ID → 고객명이라는 이행 함수 종속을 제거해 고객 테이블을 분리한다.
| 테이블 | 주요 속성 | 역할 |
|---|---|---|
| 고객 | 고객ID(PK), 이름 | 고객 정보는 한 번만 저장한다. |
| 주문 | 주문ID(PK), 주문일, 고객ID(FK) | 누가 언제 주문했는지 저장한다. |
| 상품 | 상품ID(PK), 상품명, 현재가격 | 상품의 현재 기준 정보를 저장한다. |
| 주문항목 | 주문ID(PK·FK), 상품ID(PK·FK), 수량, 판매단가 | 주문 당시의 상품별 수량과 실제 판매단가를 저장한다. |
판매단가는 왜 주문항목에 둘까? 상품의 현재가격이 나중에 바뀌어도 과거 주문의 실제 결제 단가는 유지돼야 한다. 판매단가는 주문과 상품의 조합에 종속되는 거래 사실이다.
5. 좋은 모델은 JOIN과 트랜잭션을 자연스럽게 설명한다
정규화된 테이블은 나뉘어 있지만 관계를 따라 다시 하나의 결과로 조합할 수 있다. 고객의 주문 상품을 조회하는 SQL은 모델의 관계를 그대로 따라간다.
SELECT c.이름,
o.주문ID,
p.상품명,
oi.수량,
oi.판매단가
FROM 고객 c
JOIN 주문 o
ON o.고객ID = c.고객ID
JOIN 주문항목 oi
ON oi.주문ID = o.주문ID
JOIN 상품 p
ON p.상품ID = oi.상품ID
WHERE c.고객ID = 101;관계가 모델에 빠져 있으면 JOIN 조건을 설명하기 어렵고, 불필요한 중복관계가 있으면 서로 다른 경로에서 결과가 달라질 수 있다. 모델의 관계는 단순히 선을 그리는 일이 아니라 SQL의 조인 경로를 정의하는 일이다.
트랜잭션은 모델의 필수 관계를 드러낸다
‘주문 등록’ 트랜잭션은 주문 한 건과 주문항목 여러 건을 함께 만든다. 주문 없는 주문항목이 존재할 수 없다면 주문항목의 주문 참여는 필수다. 업무 트랜잭션을 따라가면 관계의 차수와 필수 여부, 누락된 엔터티를 검증할 수 있다.
NULL은 0이나 빈 문자열이 아니다
NULL은 아직 알 수 없거나 적용되지 않는 값이다. 주문의 배송완료일은 결제 직후에는 NULL일 수 있지만, 수량 0과 같은 뜻은 아니다. 선택 속성을 무조건 필수로 만들면 가짜 날짜나 빈 문자열을 저장하게 되고, 반대로 필수 관계를 NULL로 허용하면 데이터 무결성이 약해진다.
본질식별자와 인조식별자
본질식별자는 업무에서 자연스럽게 생긴 식별자이고, 인조식별자는 편의성과 안정성을 위해 새로 만든 식별자다. 주민등록번호나 사업자등록번호는 본질식별자 후보가 될 수 있지만 변경·보안·개인정보 문제를 함께 봐야 한다. 주문ID처럼 시스템이 만든 일련번호는 조인과 참조가 단순하지만, 업무 중복을 막는 별도의 유일성 제약이 필요할 수 있다.
| 구분 | 장점 | 주의점 |
|---|---|---|
| 본질식별자 | 업무 의미와 중복 방지 규칙이 드러난다. | 값이 길거나 바뀌고 개인정보일 수 있다. |
| 인조식별자 | 짧고 안정적이며 참조가 단순하다. | 같은 업무 데이터의 중복을 별도 제약으로 막아야 한다. |
6. 성능은 정규화 후 측정하고 보완한다
정규화는 입력·수정·삭제 이상을 줄이고 데이터 일관성을 높인다. 반면 조회할 때 JOIN이 늘 수 있다. 그렇다고 처음부터 모든 값을 한 테이블에 중복 저장하면 변경 비용과 불일치 위험이 커진다. 기본 순서는 정규화 → 용량·트랜잭션 분석 → 실제 실행 검증 → 필요한 부분 보완이다.
- 정규화된 모델이 업무 규칙을 정확히 표현하는지 확인한다.
- 예상 데이터 건수와 증가량을 산정한다.
- 조회·등록·수정·삭제 트랜잭션의 빈도와 범위를 파악한다.
- SQL과 실행 계획으로 병목을 측정한다.
- 인덱스, SQL 개선, 파티션, 캐시나 뷰 같은 대안을 먼저 검토한다.
- 그래도 병목이 남을 때 반정규화의 이득과 일관성 비용을 비교한다.
반정규화의 대표 기법
| 대상 | 기법 | 예시 | 대가 |
|---|---|---|---|
| 테이블 | 병합·분할·통계 테이블 추가 | 월별 상품 매출 집계 테이블 | 집계 갱신과 검증 필요 |
| 컬럼 | 중복·파생 컬럼 추가 | 주문에 주문총액 저장 | 주문항목 변경 시 동기화 필요 |
| 관계 | 중복 관계 추가 | 여러 단계를 거치는 조회 경로 단축 | 두 관계의 일관성 유지 필요 |
수직 분할은 자주 쓰는 컬럼과 큰 비정형 컬럼을 나누는 방식이고, 수평 분할은 날짜나 지역처럼 행 범위를 나누는 방식이다. ORDER BY를 사용한다는 사실만으로 반정규화 대상이 되는 것은 아니다. 정렬 병목은 인덱스와 실행 계획부터 확인한다.
7. 시험에서 자주 틀리는 부분
논리적 독립성과 물리적 독립성을 반대로 외운다
개념 스키마 변경을 외부에 숨기는 것은 논리적 독립성이다. 내부 저장 구조 변경을 논리 구조에 숨기는 것은 물리적 독립성이다.
인스턴스를 속성이라고 생각한다
고객은 엔터티, 김하나는 인스턴스, 고객ID와 이름은 속성이다. 엔터티가 여러 속성을 갖는 것과 여러 인스턴스의 집합인 것은 다른 설명이다.
정규화하면 모든 SQL이 빨라진다고 생각한다
정규화의 직접 목적은 중복과 이상 현상 제거다. 조회 JOIN은 늘 수 있으므로 성능은 트랜잭션과 실행 계획으로 따로 검증한다.
반정규화를 정규화 이전에 적용한다
반정규화는 정확히 정규화된 모델에서 실제 성능 문제와 다른 대안을 검토한 뒤 선택한다. 근거 없이 중복 컬럼을 추가하는 것은 반정규화가 아니라 데이터 불일치의 원인이 될 수 있다.
인조식별자가 업무 중복까지 자동으로 막는다고 생각한다
새 일련번호는 각 행만 유일하게 만든다. 같은 고객·상품·날짜 조합의 중복 등록을 막으려면 업무 규칙에 맞는 UNIQUE 제약을 별도로 설계해야 한다.
8. 미니 문제로 확인하기
문제 1. 인덱스를 추가해 저장 구조가 바뀌어도 테이블 논리 구조가 유지되는 성질은?
정답: 물리적 독립성. 내부 스키마 변경이 개념·외부 스키마에 영향을 주지 않는 성질이다.
문제 2. 주문항목의 복합키가 주문ID·상품ID일 때 상품명이 상품ID에만 의존한다면 위반한 정규형은?
정답: 2차 정규형. 복합키 일부에만 의존하는 부분 함수 종속이 있으므로 상품 테이블로 분리한다.
문제 3. 주문ID → 고객ID → 고객명 관계에서 고객명을 주문 테이블에 저장하면 어떤 종속이 생기는가?
정답: 이행 함수 종속. 일반 속성인 고객ID를 통해 고객명이 결정되므로 고객 테이블로 분리해 3차 정규형을 만족한다.
문제 4. 조회 속도가 느리면 가장 먼저 반정규화를 적용해야 할까?
정답: 아니다. SQL, 실행 계획, 인덱스, 데이터 범위와 트랜잭션을 확인한 뒤 다른 방법으로 해결되지 않는 병목에 한해 검토한다.
문제 5. ‘고객’은 엔터티다. 그렇다면 고객ID 101인 김하나와 고객ID는 각각 무엇인가?
정답: 김하나는 인스턴스, 고객ID는 속성이다. 엔터티는 관리 대상의 집합이고 인스턴스는 그 집합에 속한 개별 사례다. 고객ID·이름처럼 사례를 설명하는 항목은 속성이다.
문제 6. 고객 한 명은 주문이 없을 수도 있고 여러 주문을 만들 수도 있다. 고객에서 주문으로 읽은 관계는?
정답: 선택적인 1:N 관계다. 한 고객이 여러 주문과 연결될 수 있으므로 1:N이며, 가입 직후 주문이 0건일 수 있으므로 고객 입장에서 주문 참여는 선택적이다.
문제 7. 주문 테이블의 저장 위치와 인덱스 구성을 바꿔도 개념 스키마와 사용자 화면이 영향을 받지 않았다. 어떤 독립성인가?
정답: 물리적 데이터 독립성이다. 내부 스키마의 변경을 개념·외부 스키마에 숨기는 성질이다. 개념 스키마 변경을 외부 스키마에 숨기는 것은 논리적 독립성이다.
문제 8. 주문항목에 일련번호 PK를 추가하면 같은 주문에 같은 상품이 두 번 등록되는 업무 중복도 자동으로 막을 수 있을까?
정답: 막을 수 없다. 일련번호는 각 행만 유일하게 만든다. 업무상 중복을 막으려면 주문ID·상품ID 조합처럼 실제 중복 기준에 UNIQUE 제약을 별도로 둬야 한다.
핵심 요약
- 데이터 모델링은 현실 업무를 추상화·단순화·명확화해 데이터 구조로 표현하는 과정이다.
- 개념·논리·물리 모델은 설계 단계이고, 외부·개념·내부 스키마는 데이터베이스 관점이다.
- 논리적 독립성은 개념 구조 변경, 물리적 독립성은 내부 저장 구조 변경을 상위 관점에 숨긴다.
- 엔터티의 개별 사례는 인스턴스이고, 관리할 최소 데이터 항목은 속성이다.
- 1·2·3차 정규화는 원자값, 부분 함수 종속, 이행 함수 종속을 차례로 점검한다.
- 성능 보완은 정규화된 모델과 실제 실행 결과를 확인한 뒤 선택한다.