핵심 요약
핵심 판단
- 지문이 모델링의 목적, 성질, 단계 중 무엇을 묻는지 분리한다.
- 현재 화면이나 프로세스에 모델을 종속시키는 표현은 비유연성 위험으로 본다.
- DBMS 제품, 데이터 타입, 인덱스가 나오면 물리 모델인지 확인한다.
- 업무 의미와 정규화가 중심이면 논리 모델로 판단한다.
헷갈리는 개념 비교
| 단계 | 핵심 질문 | 대표 산출물 |
|---|---|---|
| 개념 모델 | 어떤 업무 대상을 관리하는가? | 핵심 엔터티와 큰 관계 |
| 논리 모델 | 어떤 속성과 식별자, 업무 규칙이 필요한가? | 정규화된 엔터티·속성·관계 |
| 물리 모델 | 선택한 DBMS에 어떻게 구현할 것인가? | 테이블·컬럼·PK·FK·인덱스 |
대표 예제
예를 들어 주문 업무라면 개념 단계에서는 고객·주문·상품의 관계를 잡고, 논리 단계에서는 주문번호와 주문일시 같은 속성과 카디널리티를 확정한다. 물리 단계에서는 VARCHAR2, NUMBER, 파티션과 인덱스 등을 결정한다.
학습 목표
- 데이터 모델링이 단순한 테이블 작성이 아닌 이유를 설명한다.
- 개념·논리·물리 모델의 산출물과 관심사를 구분한다.
본문
개념 지도
업무 범위→핵심 대상→개념 모델→논리 모델→물리 구현핵심 내용
데이터 모델링은 현실의 업무를 데이터, 관계, 규칙으로 단순화해 표현하는 과정이다. 좋은 모델은 현재 화면이나 특정 프로그램에만 맞지 않고, 업무가 바뀌어도 핵심 의미가 유지되어야 한다.
개념 비교표는 핵심 요약에서 확인한다.
대표 예제는 핵심 요약에서 확인한다.
하나의 업무를 세 단계로 발전시키기
“고객이 상품을 주문한다”는 요구를 예로 든다.
개념 모델
고객 ─ 주문 ─ 상품이라는 핵심 대상과 큰 관계 정의
논리 모델
고객번호·주문번호·상품번호, 카디널리티, 주문상품 연결 엔터티,
속성 도메인·정규화·업무 유일성 정의
물리 모델
Oracle NUMBER/VARCHAR2/DATE, Table·PK/FK·Index·Partition,
Tablespace·Naming·보안·운영 속성 결정
개념 모델은 전사 의사소통과 범위 합의, 논리 모델은 DBMS 독립적인 업무 규칙, 물리 모델은 특정 DBMS에서의 구현과 성능을 담당한다.
좋은 모델의 검증 질문
- 현재 화면이 바뀌어도 업무 사실과 관계가 유지되는가?
- 같은 사실이 여러 곳에 중복되어 비일관성이 생기지 않는가?
- 식별자와 관계가 데이터 생명주기를 표현하는가?
- 물리 성능 선택이 논리 의미를 훼손하지 않는가?
모델링은 ERD 그림 자체가 목적이 아니라 업무 사실을 명확하고 일관되게 저장해 변경과 조회를 예측 가능하게 만드는 과정이다.
시험 포인트
문항 풀이 보강: 모델링의 성질과 유의점
시험에서는 모델링의 세 가지 성질을 비슷한 표현으로 바꾸어 묻는다.
| 성질 | 의미 | 판별 문장 |
|---|---|---|
| 추상화 | 목적에 필요한 공통 특징을 뽑음 | 현실의 모든 세부를 그대로 옮기지 않는다 |
| 단순화 | 복잡한 현실을 약속된 표기와 구조로 줄임 | 누구나 같은 규칙으로 읽을 수 있게 한다 |
| 명확화 | 대상과 규칙을 모호하지 않게 표현 | 한 가지 의미로 해석되게 한다 |
데이터 모델링이 필요한 이유는 시스템 구현 전에 업무 정보를 구조화하고, 관계자 사이의 의사소통 기준을 만들며, 데이터 품질과 변경 영향도를 관리하기 위해서다. 단순히 데이터베이스만 구축하려는 작업이 아니며 업무 분석과 애플리케이션 설계에도 기준을 제공한다.
자주 출제되는 세 가지 유의점
- 중복(Duplication): 같은 사실을 여러 곳에 저장하면 갱신 누락과 불일치가 생긴다.
- 비유연성(Inflexibility): 데이터 정의가 현재 프로세스와 강하게 묶이면 작은 업무 변화에도 모델을 크게 고쳐야 한다. 데이터와 프로세스를 분리해 설계한다.
- 비일관성(Inconsistency): 서로 연관된 값 사이의 규칙이 모델에 드러나지 않으면 같은 사실이 다르게 표현된다. 관계와 제약조건으로 일관성을 지킨다.
개념·논리·물리 모델을 고르는 법
전사 핵심 업무와 큰 관계→개념 모델속성·식별자·정규화·관계 규칙→논리 모델DBMS 타입·테이블·인덱스·파티션→물리 모델“추상화 수준이 높고 전사적·업무 중심”이면 개념 모델, “실제 DB에 이식할 수 있도록 성능·저장 구조를 반영”하면 물리 모델이다.
문제에 적용하는 순서
판단 기준은 핵심 요약의 핵심 판단에서 확인한다.
자주 틀리는 부분
- 개념 모델은 DBMS의 데이터 타입이나 인덱스를 정하는 단계가 아니다.
- 논리 모델은 업무 의미를 상세화하고 정규화하며, 물리 모델은 제품과 성능 조건을 반영한다.
- 모델링은 현실을 그대로 복사하는 일이 아니라 목적에 맞게 추상화하는 일이다.
복습 문제
답을 생각한 뒤 정답과 근거를 펼쳐 보세요.
고객·주문·상품을 찾는 일은 어느 단계인가?
정답과 근거
핵심 업무 개체와 관계를 찾는 개념 모델링 단계입니다.
예를 들어 주문 업무라면 개념 단계에서는 고객·주문·상품의 관계를 잡고, 논리 단계에서는 주문번호와 주문일시 같은 속성과 카디널리티를 확정한다. 물리 단계에서는 VARCHAR2, NUMBER, 파티션과 인덱스 등을 결정한다.
PK 인덱스의 저장 옵션을 정하는 일은 어느 단계인가?
정답과 근거
인덱스 저장 옵션은 DBMS 구현을 정하는 물리 모델링 단계입니다.
예를 들어 주문 업무라면 개념 단계에서는 고객·주문·상품의 관계를 잡고, 논리 단계에서는 주문번호와 주문일시 같은 속성과 카디널리티를 확정한다. 물리 단계에서는 VARCHAR2, NUMBER, 파티션과 인덱스 등을 결정한다.
고객과 주문의 업무 관계를 정하는 작업과 인덱스 저장 옵션을 고르는 작업은 각각 어떤 모델링 단계인가?
정답과 근거
고객과 주문의 업무 관계는 개념 또는 논리 모델에서 정하고, 인덱스 저장 옵션은 물리 모델에서 정합니다.
예를 들어 주문 업무라면 개념 단계에서는 고객·주문·상품의 관계를 잡고, 논리 단계에서는 주문번호와 주문일시 같은 속성과 카디널리티를 확정한다. 물리 단계에서는 VARCHAR2, NUMBER, 파티션과 인덱스 등을 결정한다.