(새 문서: <div style="background:linear-gradient(135deg,#0f2b46 0%,#1d4e7a 55%,#2b7bb9 100%);color:#ffffff;padding:32px 36px;border-radius:14px;margin-bottom:24px;box-shadow:0 4px 14px rgba(15,43,70,0.25);"> <div style="font-size:12px;letter-spacing:3px;opacity:0.75;margin-bottom:6px;">DATA MODELING · FOUNDATION COURSE</div> <div style="font-size:30px;font-weight:700;line-height:1.3;">데이터 모델링 입문</div> <div style="font-size:15px;opacity:0.9;margin-top:10px;line-height:1.7;...) |
|||
| 834번째 줄: | 834번째 줄: | ||
<div style="margin-top:30px;padding:14px 20px;border-top:3px solid #0f2b46;background:#f6f9fc;border-radius:0 0 10px 10px;font-size:13px;color:#4a5a6a;"> | <div style="margin-top:30px;padding:14px 20px;border-top:3px solid #0f2b46;background:#f6f9fc;border-radius:0 0 10px 10px;font-size:13px;color:#4a5a6a;"> | ||
'''다음 학습''' → [[정규화 심화]] · [[ | '''다음 학습''' → [[데이터 모델링 정규화 심화]] · [[데이터 모델링 ERD작성 실습]] · [[Oracle 물리 설계]] · [[SQLD 데이터모델링 기출 정리]] | ||
</div> | </div> | ||
2026년 11월 4일 (수) 12:35 판
처음 시작하는 사람을 위한 단계별 가이드
난이도 · 입문 학습기간 · 12주 기준 DBMS · Oracle 19c 연계 자격 · SQLD / DAsP
1. 데이터 모델링이란
데이터 모델링(Data Modeling)은 현실 세계의 업무(비즈니스)를 분석하여, 그 업무에 필요한 데이터를 구조화된 형태로 정의하고 표현하는 과정이다. 결과물을 데이터 모델이라 하며, 보통 ERD(Entity Relationship Diagram)로 표현한다.
한 줄 정의
"업무에서 무엇을(What) 관리해야 하는지를 찾아내고, 그것들 사이의 관계를 약속된 표기법으로 그려내는 일"
1.1 데이터 모델링의 세 가지 관점
| 관점 | 질문 | 설명 |
|---|---|---|
| 데이터 관점 | What | 업무가 어떤 데이터와 관련 있는가, 데이터 간의 관계는 무엇인가 |
| 프로세스 관점 | How | 업무가 실제로 무엇을 하는가, 무엇을 해야 하는가 |
| 상관 관점 | Interaction | 프로세스 흐름에 따라 데이터가 어떻게 생성·변경·삭제(CRUD)되는가 |
1.2 왜 필요한가
- 의사소통 도구 — 현업 담당자, 기획자, 개발자, DBA가 같은 그림을 보고 대화한다.
- 품질 확보 — 중복·불일치를 설계 단계에서 제거한다. 잘못된 모델은 이후 어떤 SQL 튜닝으로도 완전히 회복되지 않는다.
- 비용 절감 — 설계 단계의 오류 수정 비용은 운영 단계 대비 수십 배 저렴하다.
- 시스템 확장성 — 업무 변화에 유연하게 대응할 수 있는 구조를 만든다.
💡 DBA의 시선 — 운영 중 만나는 성능 문제의 상당수는 SQL이 아니라 모델에서 시작된다. 잘못된 식별자 선정, 과도한 반정규화, 이력 관리 부재는 결국 대량 조인·락 경합·데이터 불일치로 돌아온다.
1.3 좋은 데이터 모델의 요건
| 요건 | 의미 |
|---|---|
| 완전성 (Completeness) | 업무에 필요한 데이터가 빠짐없이 정의되어 있다 |
| 중복 배제 (Non-Redundancy) | 하나의 사실은 한 곳에만 저장된다 |
| 업무 규칙 (Business Rules) | 업무 규칙이 모델(관계·제약)에 표현되어 있다 |
| 데이터 재사용 (Reusability) | 특정 프로그램이 아닌 전사 관점에서 통합·재사용 가능하다 |
| 의사소통 (Communication) | 모델만 보고도 업무를 이해할 수 있다 |
| 통합성 (Integration) | 동일한 데이터는 조직 전체에서 한 번만 정의된다 |
2. 데이터 모델링의 3단계
추상화 수준 높음
전사적·업무 중심
정규화 수행
DBMS 독립적
반정규화 · 성능 고려
DBMS 종속적
| 구분 | 개념적 | 논리적 | 물리적 |
|---|---|---|---|
| 목적 | 업무 범위와 핵심 개념 합의 | 업무 규칙의 정확한 표현 | 실제 DB 구현 |
| 주요 산출물 | 주제영역, 핵심 엔터티, 관계 | 전체 엔터티, 속성, PK/FK, 정규화된 ERD | 테이블, 컬럼, 데이터타입, 인덱스, DDL |
| 용어 | 엔터티 / 관계 | 엔터티 / 속성 / 식별자 | 테이블 / 컬럼 / 키 / 제약조건 |
| 주 참여자 | 현업, 기획자, DA | DA, 설계자 | DBA, 개발자 |
| DBMS 의존성 | 없음 | 없음 | 있음 (Oracle, MySQL 등) |
2.1 데이터 독립성과 ANSI/SPARC 3단계 스키마
| 스키마 | 관점 | 설명 |
|---|---|---|
| 외부 스키마 (External) | 사용자 | 각 사용자·응용 프로그램이 보는 개인적 DB 구조 (View) |
| 개념 스키마 (Conceptual) | 통합 | 모든 사용자 관점을 통합한 조직 전체의 DB 구조 |
| 내부 스키마 (Internal) | 물리 | 물리적 저장 구조 (파일, 블록, 인덱스) |
- 논리적 독립성 — 개념 스키마가 변경되어도 외부 스키마(응용)는 영향받지 않는다.
- 물리적 독립성 — 내부 스키마(저장 구조)가 변경되어도 개념 스키마는 영향받지 않는다.
3. 핵심 구성 요소
Entity · 무엇을
Attribute · 어떤 정보를
Relationship · 어떻게 연결
Identifier · 유일하게 구분
3.1 엔터티 (Entity)
업무에서 관리하고자 하는 대상으로, 두 개 이상의 인스턴스(행)와 속성을 가지는 집합이다. 예: 고객, 상품, 주문, 사원, 부서
엔터티의 조건
- 업무에서 필요하고 관리하고자 하는 정보여야 한다.
- 유일한 식별자로 구분 가능해야 한다.
- 두 개 이상의 인스턴스 집합이어야 한다. (1건뿐이면 엔터티가 아니다)
- 업무 프로세스에 의해 이용되어야 한다. (CRUD 발생)
- 반드시 속성을 가져야 한다.
- 다른 엔터티와 최소 한 개 이상의 관계를 가져야 한다. (코드·통계·로그성 예외)
엔터티의 분류
| 기준 | 분류 | 설명 | 예시 |
|---|---|---|---|
| 유무형 | 유형 엔터티 | 물리적 형태가 있는 대상 | 사원, 상품, 창고 |
| 개념 엔터티 | 물리적 형태 없이 관리할 개념 | 조직, 보험상품, 계정과목 | |
| 사건 엔터티 | 업무 수행 중 발생하는 사건 | 주문, 입금, 청구 | |
| 발생 시점 | 기본(키) 엔터티 | 독립적으로 생성, 고유 식별자 보유 | 고객, 상품, 부서 |
| 중심(메인) 엔터티 | 기본 엔터티로부터 발생, 업무의 중심 | 주문, 계약, 매출 | |
| 행위 엔터티 | 둘 이상의 엔터티로부터 발생, 이력성 | 주문상세, 상태변경이력 |
3.2 속성 (Attribute)
엔터티가 가지는 더 이상 분리되지 않는 최소 단위의 데이터. 하나의 인스턴스에서 하나의 속성은 하나의 값만 가진다.
| 분류 | 설명 | 예시 |
|---|---|---|
| 기본 속성 | 업무로부터 추출한 본래의 속성 | 상품명, 주문수량, 단가 |
| 설계 속성 | 업무에 없지만 설계상 만든 속성 (코드, 일련번호) | 주문번호, 상태코드 |
| 파생 속성 | 다른 속성으로부터 계산된 속성 (가급적 최소화) | 주문금액(=수량×단가), 합계 |
- 도메인(Domain) — 속성이 가질 수 있는 값의 범위. 데이터타입, 길이, 허용 값, 제약을 포함한다. (예: 성별 = {M, F}, 수량 ≥ 0)
- 속성 명명 원칙 — 업무 용어 사용, 약어 지양, 서술식 금지, 모델 전체에서 유일한 이름 사용 (예:
등록일✕ →고객등록일자○)
3.3 관계 (Relationship)
엔터티의 인스턴스 사이에 존재하는 논리적인 연관성.
관계의 구성 요소
| 요소 | 설명 | 예시 |
|---|---|---|
| 관계명 | 관계의 이름 (양방향으로 읽힘) | 고객은 주문을 한다 / 주문은 고객에 의해 접수된다 |
| 관계 차수 (Cardinality) | 참여하는 인스턴스의 수 | 1:1, 1:N, M:N |
| 관계 선택사양 (Optionality) | 필수 참여인지 선택 참여인지 | 주문은 반드시 고객이 있어야 한다 (필수) |
관계 차수 해석
| 차수 | 의미 | 예시 | 구현 |
|---|---|---|---|
| 1 : 1 | 한 건이 상대 한 건과만 연결 | 사원 – 사원상세 | 한쪽에 FK(+UNIQUE) 또는 통합 |
| 1 : N | 한 건이 상대 여러 건과 연결 | 부서 – 사원 | N쪽에 FK |
| M : N | 양쪽 모두 여러 건과 연결 | 학생 – 강좌 | 관계 엔터티(수강)로 해소 |
⚠ M:N 관계는 그대로 구현할 수 없다. 논리 모델 단계에서 반드시 교차(관계) 엔터티로 분해한다.
학생 (M) ── (N) 강좌 → 학생 (1) ── (N) 수강 (N) ── (1) 강좌
식별 관계 vs 비식별 관계
| 구분 | 식별 관계 (Identifying) | 비식별 관계 (Non-Identifying) |
|---|---|---|
| 정의 | 부모의 PK가 자식의 PK 일부가 됨 | 부모의 PK가 자식의 일반 속성(FK)이 됨 |
| 표기 | 실선 | 점선 |
| 연결 강도 | 강한 연결 (자식은 부모 없이 존재 불가) | 약한 연결 |
| 장점 | 부모 조건으로 자식 조회 시 조인 없이 PK 인덱스 활용 | 자식의 PK가 단순, 구조 변경에 유연 |
| 단점 | 하위로 갈수록 PK 컬럼 수 증가 (PK 비대화) | 상위 조건 조회 시 조인 증가 |
| 예시 | 주문 → 주문상세 (주문번호+순번) | 부서 → 사원 (사원번호, 부서번호는 FK) |
3.4 식별자 (Identifier)
엔터티 내에서 인스턴스를 유일하게 구분하는 속성(또는 속성 집합).
| 분류 기준 | 종류 | 설명 |
|---|---|---|
| 대표성 | 주식별자 (PK) | 대표 식별자. 다른 엔터티와 참조 관계 연결에 사용 |
| 보조식별자 (AK) | 유일성은 있지만 대표성이 없는 식별자 (예: 주민번호, 이메일) | |
| 생성 여부 | 내부식별자 | 엔터티 내부에서 스스로 생성 (예: 고객번호) |
| 외부식별자 | 다른 엔터티와의 관계를 통해 상속 (FK) | |
| 속성 수 | 단일식별자 | 하나의 속성으로 구성 |
| 복합식별자 | 둘 이상의 속성으로 구성 | |
| 대체 여부 | 본질식별자 | 업무에 의해 만들어진 식별자 (주문번호+상품코드) |
| 인조식별자 | 인위적으로 만든 식별자 (일련번호, 시퀀스) |
주식별자의 4가지 특징
| 유일성 | 최소성 | 불변성 | 존재성 |
|---|---|---|---|
| 모든 인스턴스를 유일하게 구분 | 유일성을 만족하는 최소 속성 수 | 한번 지정되면 값이 변하지 않음 | 반드시 값이 존재 (NOT NULL) |
💡 인조식별자 남용 주의 — 모든 테이블에 ID NUMBER 시퀀스를 PK로 두면, 본질식별자에 대한 UNIQUE 제약을 빠뜨려 중복 데이터가 쉽게 생긴다. 인조식별자를 쓰더라도 본질식별자에는 반드시 UNIQUE 인덱스를 둔다.
4. ERD 표기법
4.1 주요 표기법 비교
| 표기법 | 특징 | 사용처 |
|---|---|---|
| IE (Information Engineering) | 까마귀발(Crow's Foot)로 다(N)를 표현. 가장 널리 사용 | ERwin, DA#, 실무 대부분 |
| Barker | Oracle 사의 표기법. 점선/실선으로 선택·필수 표현, # 식별자, * 필수, o 선택 | Oracle SQL Developer Data Modeler |
| Chen | 엔터티(사각형), 관계(마름모), 속성(타원) | 교과서, 개념 설명용 |
| UML Class | 클래스 다이어그램으로 데이터 표현 | 객체지향 설계 |
4.2 IE 표기법 기호 읽기
기호 의미
──┼── 1 (필수, 정확히 하나)
──○┼─ 0 또는 1 (선택, 최대 하나)
──┼< 1 이상 (필수, 다수)
──○< 0 이상 (선택, 다수)
예) [부서] ──┼────────○< [사원]
"한 부서에는 0명 이상의 사원이 소속되고,
한 사원은 반드시 하나의 부서에 소속된다"
4.3 ERD 작성 순서
- 엔터티를 도출하고 그린다. (명사 찾기)
- 엔터티를 적절히 배치한다. — 중요 엔터티는 좌상단, 발생 순서대로 좌→우 / 상→하
- 엔터티 간 관계를 설정한다.
- 관계명을 기술한다. (양방향)
- 관계 참여도(차수)를 기술한다.
- 관계의 필수 여부(선택사양)를 기술한다.
5. 정규화 (Normalization)
정규화는 데이터의 중복을 제거하고 이상현상(Anomaly)을 방지하기 위해 함수 종속성에 근거하여 엔터티를 분해하는 과정이다.
5.1 이상현상 (Anomaly)
| 종류 | 설명 | 예 |
|---|---|---|
| 삽입 이상 | 불필요한 데이터가 있어야만 삽입 가능 | 주문이 없으면 신규 고객을 등록할 수 없음 |
| 갱신 이상 | 중복 데이터 일부만 변경되어 불일치 발생 | 고객 주소가 주문마다 저장되어 일부만 변경됨 |
| 삭제 이상 | 삭제 시 필요한 데이터까지 함께 삭제 | 마지막 주문 삭제 시 고객 정보도 사라짐 |
5.2 함수 종속성 (Functional Dependency)
속성 X의 값이 속성 Y의 값을 유일하게 결정할 때 X → Y로 표기하며, X를 결정자, Y를 종속자라 한다.
- 예:
고객번호 → 고객명, 주소 - 완전 함수 종속 — PK 전체에 종속
- 부분 함수 종속 — 복합 PK의 일부에만 종속 → 2NF 위반
- 이행 함수 종속 — A → B, B → C 이면 A → C → 3NF 위반
5.3 정규형 단계
원자값 · 반복그룹 제거
부분 종속 제거
이행 종속 제거
모든 결정자가 후보키
다치 · 조인 종속 제거
5.4 정규화 실습 예제
[비정규형] 주문 정보
| 주문번호 | 주문일자 | 고객번호 | 고객명 | 등급 | 할인율 | 상품코드 | 상품명 | 수량 |
|---|---|---|---|---|---|---|---|---|
| 1001 | 2026-11-01 | C01 | 김철수 | GOLD | 10% | P01, P02 | 키보드, 마우스 | 1, 2 |
→ 한 칸에 여러 값이 들어 있다. 원자값 위반
[1NF] 반복 그룹 제거
| 주문번호 | 상품코드 | 주문일자 | 고객번호 | 고객명 | 등급 | 할인율 | 상품명 | 수량 |
|---|---|---|---|---|---|---|---|---|
| 1001 | P01 | 2026-11-01 | C01 | 김철수 | GOLD | 10% | 키보드 | 1 |
| 1001 | P02 | 2026-11-01 | C01 | 김철수 | GOLD | 10% | 마우스 | 2 |
→ PK = (주문번호, 상품코드). 그러나 주문일자·고객정보는 주문번호에만, 상품명은 상품코드에만 종속 → 부분 종속
[2NF] 부분 종속 제거
| 주문번호 | 주문일자 | 고객번호 | 고객명 | 등급 | 할인율 |
|---|---|---|---|---|---|
| 1001 | 2026-11-01 | C01 | 김철수 | GOLD | 10% |
| 주문번호 | 상품코드 | 수량 |
|---|---|---|
| 1001 | P01 | 1 |
| 1001 | P02 | 2 |
| 상품코드 | 상품명 |
|---|---|
| P01 | 키보드 |
| P02 | 마우스 |
→ 주문 테이블에서 주문번호 → 고객번호 → 고객명, 등급, 등급 → 할인율 → 이행 종속
[3NF] 이행 종속 제거
| 주문번호 | 주문일자 | 고객번호(FK) |
|---|---|---|
| 1001 | 2026-11-01 | C01 |
| 고객번호 | 고객명 | 등급(FK) |
|---|---|---|
| C01 | 김철수 | GOLD |
| 등급 | 할인율 |
|---|---|
| GOLD | 10% |
→ 주문상세, 상품은 2NF 결과 그대로 유지. 최종적으로 5개 엔터티로 분해되어 각 사실이 한 곳에만 저장된다.
5.5 정규화의 장단점
| 장점 | 단점 |
|---|---|
|
|
6. 반정규화 (Denormalization)
정규화된 모델을 조회 성능 향상과 개발·운영의 단순화를 위해 의도적으로 중복·통합·분리하는 기법이다. 반정규화는 데이터 정합성을 희생하므로 반드시 근거와 정합성 유지 방안(트리거, 배치, 애플리케이션)이 함께 있어야 한다.
6.1 반정규화 절차
- 대상 조사 — 범위 처리 빈도, 대량 범위 조회, 통계성 프로세스, 과도한 조인
- 다른 방법 검토 — 뷰(View), 클러스터링, 인덱스 조정, 파티셔닝, 애플리케이션 캐시, Materialized View
- 반정규화 적용 — 위 방법으로 해결되지 않을 때만
6.2 반정규화 기법
| 대상 | 기법 | 설명 |
|---|---|---|
| 테이블 | 병합 | 1:1, 1:N 관계 테이블 통합, 슈퍼/서브타입 통합 |
| 분할 | 수직 분할(컬럼 단위), 수평 분할(행 단위 — 파티셔닝) | |
| 추가 (중복 테이블) | 동일 테이블을 다른 용도로 복제 | |
| 추가 (통계·이력·부분 테이블) | 집계 테이블, 최근 데이터 테이블 등 | |
| 컬럼 | 중복 컬럼 | 조인을 줄이기 위해 다른 테이블의 컬럼을 중복 보유 |
| 파생 컬럼 | 계산 결과를 미리 저장 (주문총액) | |
| 이력 테이블 컬럼 | 최신여부, 시작/종료일자 추가 | |
| PK에 의한 컬럼 | 복합 의미 PK의 일부를 별도 컬럼으로 | |
| 관계 | 중복 관계 추가 | 여러 단계를 거치는 조인 경로 단축 |
💡 Oracle 환경 팁 — 반정규화 전에 Materialized View(+Query Rewrite), 파티셔닝, Function-Based Index, Result Cache 등 DBMS 기능으로 해결 가능한지 먼저 검토한다. 정합성 관리 부담 없이 같은 효과를 얻을 수 있는 경우가 많다.
7. 고급 모델링 패턴
7.1 슈퍼타입 / 서브타입
공통 속성을 슈퍼타입에, 개별 속성을 서브타입에 두는 구조. (예: 고객 → 개인고객 / 법인고객)
| 변환 방식 | 설명 | 적합한 경우 |
|---|---|---|
| One To One (개별 테이블) | 슈퍼·서브 각각 테이블 | 서브타입별 처리가 독립적, 서브타입 속성이 많음 |
| Plus Type (서브타입 테이블) | 서브타입마다 테이블 (슈퍼 속성 포함) | 서브타입 단위 처리가 대부분 |
| Single Type (통합 테이블) | 하나의 테이블로 통합 + 구분 컬럼 | 데이터 양이 적고 통합 처리가 많음 |
7.2 이력 관리 모델
- 시점 이력 — 변경 발생 시점만 기록 (변경일자)
- 선분 이력 — 유효 시작일자 ~ 종료일자로 기간 관리 (예:
9999-12-31을 현재 유효 데이터로 사용) - 스냅샷 — 일/월 단위 전체 상태 저장
7.3 코드 설계
- 통합 코드 테이블(공통코드: 코드그룹 + 코드값) vs 개별 코드 테이블 — 통합은 관리 편리, 개별은 FK 무결성 보장
- 자주 바뀌지 않고 속성이 단순한 코드는 통합, 속성이 많거나 참조 무결성이 중요한 코드는 개별 테이블
7.4 순환 관계 (Recursive)
자기 자신을 참조하는 관계. 조직도, 메뉴 트리, BOM 등에 사용. Oracle에서는 CONNECT BY 또는 재귀 WITH로 조회한다.
8. 물리 모델링 (Oracle 기준)
8.1 논리 → 물리 변환
| 논리 모델 | 물리 모델 | Oracle 구현 |
|---|---|---|
| 엔터티 | 테이블 | CREATE TABLE
|
| 속성 | 컬럼 | VARCHAR2, NUMBER, DATE, TIMESTAMP
|
| 주식별자 | Primary Key | CONSTRAINT ... PRIMARY KEY
|
| 보조식별자 | Unique Key | UNIQUE
|
| 관계 | Foreign Key | REFERENCES (+ FK 컬럼 인덱스)
|
| 도메인 | 데이터타입 + 제약 | CHECK, NOT NULL, DEFAULT
|
8.2 예제 DDL
-- 고객
CREATE TABLE TB_CUSTOMER (
CUST_NO VARCHAR2(10) NOT NULL,
CUST_NM VARCHAR2(100) NOT NULL,
EMAIL VARCHAR2(200),
GRADE_CD VARCHAR2(10) NOT NULL,
REG_DT DATE DEFAULT SYSDATE NOT NULL,
CONSTRAINT PK_CUSTOMER PRIMARY KEY (CUST_NO),
CONSTRAINT UK_CUSTOMER_EMAIL UNIQUE (EMAIL),
CONSTRAINT FK_CUSTOMER_GRADE FOREIGN KEY (GRADE_CD)
REFERENCES TB_CUST_GRADE (GRADE_CD)
);
-- 주문 (월별 Range 파티션)
CREATE TABLE TB_ORDER (
ORDER_NO VARCHAR2(20) NOT NULL,
ORDER_DT DATE NOT NULL,
CUST_NO VARCHAR2(10) NOT NULL,
ORDER_STAT_CD VARCHAR2(2) DEFAULT '10' NOT NULL,
CONSTRAINT PK_ORDER PRIMARY KEY (ORDER_NO),
CONSTRAINT FK_ORDER_CUST FOREIGN KEY (CUST_NO)
REFERENCES TB_CUSTOMER (CUST_NO),
CONSTRAINT CK_ORDER_STAT CHECK (ORDER_STAT_CD IN ('10','20','30','90'))
)
PARTITION BY RANGE (ORDER_DT) INTERVAL (NUMTOYMINTERVAL(1,'MONTH'))
( PARTITION P_202601 VALUES LESS THAN (DATE '2026-02-01') );
-- FK 컬럼 인덱스 (부모 삭제·변경 시 Lock 경합 방지)
CREATE INDEX IX_ORDER_01 ON TB_ORDER (CUST_NO, ORDER_DT) LOCAL;
-- 주문상세 (식별 관계: 주문번호 + 순번)
CREATE TABLE TB_ORDER_ITEM (
ORDER_NO VARCHAR2(20) NOT NULL,
ITEM_SEQ NUMBER(5) NOT NULL,
PROD_CD VARCHAR2(10) NOT NULL,
ORDER_QTY NUMBER(7) NOT NULL,
UNIT_PRICE NUMBER(12,2) NOT NULL,
CONSTRAINT PK_ORDER_ITEM PRIMARY KEY (ORDER_NO, ITEM_SEQ),
CONSTRAINT FK_ORDER_ITEM_ORDER FOREIGN KEY (ORDER_NO)
REFERENCES TB_ORDER (ORDER_NO),
CONSTRAINT FK_ORDER_ITEM_PROD FOREIGN KEY (PROD_CD)
REFERENCES TB_PRODUCT (PROD_CD),
CONSTRAINT CK_ORDER_ITEM_QTY CHECK (ORDER_QTY > 0)
);
COMMENT ON TABLE TB_ORDER_ITEM IS '주문상세';
COMMENT ON COLUMN TB_ORDER_ITEM.ITEM_SEQ IS '주문상세순번';
8.3 물리 설계 체크포인트
| 항목 | 확인 내용 |
|---|---|
| 데이터타입 | 날짜는 DATE/TIMESTAMP로 (문자 'YYYYMMDD' 지양), 조인 컬럼 간 타입·길이 일치로 묵시적 형변환 방지
|
| NULL 허용 | 필수 속성은 NOT NULL. NULL은 인덱스(B-Tree) 미저장, 집계·비교 결과에 영향
|
| 인덱스 | PK/UK 자동 생성, FK 컬럼 인덱스 필수 검토, 조회 패턴 기반 결합 인덱스 순서 결정 |
| 파티셔닝 | 대용량 이력·트랜잭션 테이블은 Range/Interval, 분산 목적은 Hash, 코드성 분리는 List |
| 명명 규칙 | 테이블 TB_, PK PK_, FK FK_, 인덱스 IX_ 등 표준 수립 및 표준 단어 사전 운영
|
| 주석 | 모든 테이블·컬럼에 COMMENT 등록 (메타데이터 = 모델과 DB의 동기화)
|
| 용량 산정 | 초기 건수, 일 증가량, 보존 기간으로 테이블스페이스·파티션 전략 수립 |
9. 실전 예제 — 쇼핑몰 주문 모델
┌──────────────┐ ┌──────────────┐
│ 고객등급 │ │ 상품분류 │
│──────────────│ │──────────────│
│ # 등급코드 │ │ # 분류코드 │
│ * 등급명 │ │ * 분류명 │
│ * 할인율 │ │ o 상위분류코드 │──┐ (순환)
└──────┬───────┘ └──────┬───────┘◄─┘
│1 │1
│ │
○<N ○<N
┌──────┴───────┐ ┌──────┴───────┐
│ 고객 │ │ 상품 │
│──────────────│ │──────────────│
│ # 고객번호 │ │ # 상품코드 │
│ * 고객명 │ │ * 상품명 │
│ o 이메일 │ │ * 판매단가 │
└──────┬───────┘ └──────┬───────┘
│1 │1
○<N ○<N
┌──────┴───────┐ 1 1< ┌─────┴────────┐
│ 주문 │─────────│ 주문상세 │
│──────────────│ (식별) │──────────────│
│ # 주문번호 │ │ # 주문번호(FK)│
│ * 주문일자 │ │ # 순번 │
│ * 고객번호(FK)│ │ * 상품코드(FK)│
│ * 주문상태 │ │ * 수량 / 단가 │
└──────────────┘ └──────────────┘
# 식별자 * 필수 속성 o 선택 속성
읽는 법
- 한 고객은 주문을 0건 이상 할 수 있고, 한 주문은 반드시 한 고객에 의해 발생한다.
- 한 주문은 1건 이상의 주문상세를 가지며, 주문상세는 주문 없이 존재할 수 없다. (식별 관계)
- 상품분류는 자기 자신을 참조하는 순환 관계로 다단계 분류를 표현한다.
10. 학습 커리큘럼 (12주)
학습 대상 데이터베이스와 SQL 기초를 알고 있는 개발자·기획자·신입 DBA | 주당 학습 이론 3시간 + 실습 3시간 | 목표 중소 규모 업무의 논리·물리 모델을 독립적으로 설계
| 주차 | 단계 | 학습 주제 | 세부 내용 | 실습 / 산출물 |
|---|---|---|---|---|
| 1 | 기초 개념 이해 |
데이터베이스와 모델링 개요 | 데이터·정보·DB·DBMS, 관계형 모델, 모델링의 정의와 필요성, 3가지 관점 | 학습 환경 구성 (Oracle Free / ERD 툴) |
| 2 | 모델링 3단계와 스키마 | 개념·논리·물리 모델, ANSI/SPARC 3단계 스키마, 데이터 독립성 | 기존 시스템 ERD 읽기 연습 | |
| 3 | 핵심 구성 요소 |
엔터티 | 엔터티 조건·분류, 명명 규칙, 업무 기술서에서 명사 추출 | 도서관 업무 엔터티 도출 |
| 4 | 속성과 도메인 | 기본·설계·파생 속성, 도메인 정의, 표준 용어·단어 사전 | 속성 정의서 작성 | |
| 5 | 관계 | 관계명, 차수, 선택사양, M:N 해소, 식별/비식별 관계 | 관계 설정 및 ERD 1차본 | |
| 6 | 식별자 & ERD 표기법 | 주식별자 4대 특성, 본질 vs 인조식별자, IE/Barker 표기법 | ERD 툴로 논리 모델 완성 | |
| 7 | 심화 정규화 |
함수 종속성과 정규화 | 이상현상, 함수 종속, 1NF ~ 3NF, BCNF | 비정규 장표 → 3NF 분해 |
| 8 | 반정규화 | 반정규화 절차와 기법, 대안(MV, 파티션, 인덱스) 검토 | 성능 요구 기반 반정규화 판단 보고서 | |
| 9 | 응용 패턴·물리 |
고급 모델링 패턴 | 슈퍼/서브타입, 이력 모델, 코드 설계, 순환 관계 | 이력 관리 모델 설계 |
| 10 | 물리 모델링 (Oracle) | 데이터타입, 제약조건, 인덱스 설계, 파티셔닝, 용량 산정, DDL 생성 | 물리 모델 & DDL 스크립트 | |
| 11 | 실전 프로젝트 |
미니 프로젝트 ① | 요구사항 분석 → 개념 → 논리 모델 (쇼핑몰 / 수강신청 / 병원예약 중 택1) | 요구사항 정의서, 논리 ERD |
| 12 | 미니 프로젝트 ② & 리뷰 | 물리 모델, DDL 생성, 샘플 데이터 적재, 핵심 SQL 검증, 모델 리뷰 | 최종 ERD · DDL · 리뷰 발표 |
10.1 단계별 학습 목표
🟦 1~2주 · 기초
- 모델링의 목적을 설명할 수 있다
- 3단계 모델의 차이를 구분한다
- 기존 ERD를 읽고 해석한다
🟩 3~6주 · 핵심
- 업무 기술서에서 엔터티·속성을 도출한다
- 관계 차수와 선택사양을 정확히 표기한다
- 적절한 주식별자를 선정한다
🟧 7~8주 · 심화
- 이상현상을 찾아 정규화로 해소한다
- 3NF까지 스스로 분해한다
- 반정규화의 필요성을 근거로 판단한다
🟪 9~12주 · 응용·실전
- 이력·코드·슈퍼타입 패턴을 적용한다
- Oracle 물리 모델과 DDL을 작성한다
- 요구사항부터 DB 구현까지 완주한다
10.2 추천 도구
| 용도 | 도구 | 비고 |
|---|---|---|
| ERD 설계 | ERwin Data Modeler, DA# | 국내 실무 표준 |
| ERD 설계 (무료) | Oracle SQL Developer Data Modeler, ERDCloud, draw.io | Data Modeler는 Barker/IE 모두 지원, DDL 생성 가능 |
| 실습 DB | Oracle Database 23ai Free, Oracle Live SQL | 로컬 설치 또는 웹 실습 |
| 문서화 | 엔터티 정의서, 속성 정의서, 표준 단어/용어 사전 (Excel) | 산출물 템플릿 별도 제공 예정 |
10.3 연계 자격증
- SQLD (SQL 개발자) — 1과목 '데이터 모델링의 이해'가 본 과정 1~8주 내용과 직결
- SQLP (SQL 전문가) — 모델링 + 고급 SQL 활용·튜닝
- DAsP / DAP (데이터아키텍처 준전문가 / 전문가) — 본격적인 데이터 아키텍트 과정
11. 모델 검증 체크리스트
✅ 모델 리뷰 시 반드시 확인할 항목 (펼치기)
| 영역 | 점검 항목 |
|---|---|
| 엔터티 | □ 모든 엔터티가 업무 용어로 명명되었는가 |
| □ 인스턴스가 1건뿐이거나 속성이 없는 엔터티는 없는가 | |
| □ 관계가 없는 고립 엔터티에 타당한 이유가 있는가 | |
| 속성 | □ 하나의 속성에 여러 값(콤마 구분 등)이 저장되지 않는가 |
| □ 같은 의미의 속성이 다른 이름으로 존재하지 않는가 (표준 용어) | |
| □ 파생 속성은 근거와 정합성 유지 방안이 있는가 | |
| 관계 | □ M:N 관계가 모두 해소되었는가 |
| □ 관계의 차수·선택사양이 업무 규칙과 일치하는가 | |
| 식별자 | □ 주식별자가 유일성·최소성·불변성·존재성을 만족하는가 |
| □ 인조식별자 사용 시 본질식별자에 UNIQUE 제약이 있는가 | |
| 정규화 | □ 최소 3NF를 만족하며, 위반 시 반정규화 근거가 문서화되었는가 |
| 물리 | □ 조인 컬럼의 데이터타입·길이가 일치하는가 |
| □ FK 컬럼에 인덱스가 검토되었는가 | |
| □ 대용량 테이블의 파티션·보존 정책이 정의되었는가 |
12. 용어집
| 용어 | 영문 | 설명 |
|---|---|---|
| 엔터티 | Entity | 업무에서 관리해야 할 대상의 집합 |
| 인스턴스 | Instance | 엔터티의 개별 데이터 한 건 (행) |
| 속성 | Attribute | 엔터티를 구성하는 최소 단위의 정보 |
| 도메인 | Domain | 속성이 가질 수 있는 값의 범위 |
| 관계 | Relationship | 엔터티 인스턴스 간의 논리적 연관성 |
| 카디널리티 | Cardinality | 관계에 참여하는 인스턴스 수 (1:1, 1:N, M:N) |
| 옵셔널리티 | Optionality | 관계 참여의 필수/선택 여부 |
| 주식별자 | Primary Identifier (PK) | 인스턴스를 유일하게 식별하는 대표 키 |
| 외래키 | Foreign Key (FK) | 다른 엔터티의 PK를 참조하는 속성 |
| 후보키 | Candidate Key | 유일성과 최소성을 만족하는 키 |
| 함수 종속 | Functional Dependency | X 값이 Y 값을 유일하게 결정하는 관계 |
| 정규화 | Normalization | 중복 제거를 위한 엔터티 분해 과정 |
| 반정규화 | Denormalization | 성능을 위한 의도적 중복·통합·분리 |
| ERD | Entity Relationship Diagram | 엔터티와 관계를 그림으로 표현한 모델 |
| 메타데이터 | Metadata | 데이터에 대한 데이터 (정의서, 주석, 사전) |
13. 참고 자료
- 한국데이터산업진흥원, 데이터아키텍처 전문가 가이드 (DAP 가이드)
- 한국데이터산업진흥원, SQL 전문가 가이드 — 1과목 데이터 모델링의 이해
- Oracle, SQL Developer Data Modeler User's Guide
- Oracle, Database Concepts 19c — Tables and Table Clusters, Indexes, Partitions
- E. F. Codd, "A Relational Model of Data for Large Shared Data Banks" (1970)
- P. Chen, "The Entity-Relationship Model — Toward a Unified View of Data" (1976)
다음 학습 → 데이터 모델링 정규화 심화 · 데이터 모델링 ERD작성 실습 · Oracle 물리 설계 · SQLD 데이터모델링 기출 정리