데이터 모델링의 목적과 3단계

핵심 요약

업무 규칙을 데이터 구조로 바꾸는 이유와 개념·논리·물리 모델의 역할을 구분한다.

핵심 질문

1. 데이터 모델링의 목적과 3단계를 실제 업무 사례에서 어떤 기준으로 판별하는가?
2. 한 행이 나타내는 업무 사실과 유일성·필수성·변경 가능성은 무엇인가?
3. 잘못 모델링하면 어떤 중복·이상 현상·변경 영향이 발생하는가?
4. 여러 설계안 중 업무 의미와 변경 용이성을 가장 잘 보존하는 안을 어떻게 고르는가?

학습 목표

• 데이터 모델링이 단순한 테이블 작성이 아닌 이유를 설명한다.
• 개념·논리·물리 모델의 산출물과 관심사를 구분한다.

개념 지도

업무 범위 → 핵심 대상 → 개념 모델 → 논리 모델 → 물리 구현

핵심 내용

데이터 모델링은 현실의 업무를 데이터, 관계, 규칙으로 단순화해 표현하는 과정이다. 좋은 모델은 현재 화면이나 특정 프로그램에만 맞지 않고, 업무가 바뀌어도 핵심 의미가 유지되어야 한다.

예를 들어 주문 업무라면 개념 단계에서는 고객·주문·상품의 관계를 잡고, 논리 단계에서는 주문번호와 주문일시 같은 속성과 카디널리티를 확정한다. 물리 단계에서는 VARCHAR2, NUMBER, 파티션과 인덱스 등을 결정한다.

흔한 오해와 주의점

• 개념 모델은 DBMS의 데이터 타입이나 인덱스를 정하는 단계가 아니다.
• 논리 모델은 업무 의미를 상세화하고 정규화하며, 물리 모델은 제품과 성능 조건을 반영한다.
• 모델링은 현실을 그대로 복사하는 일이 아니라 목적에 맞게 추상화하는 일이다.

문항 풀이 보강: 모델링의 성질과 유의점

시험에서는 모델링의 세 가지 성질을 비슷한 표현으로 바꾸어 묻는다.

데이터 모델링이 필요한 이유는 시스템 구현 전에 업무 정보를 구조화하고, 관계자 사이의 의사소통 기준을 만들며, 데이터 품질과 변경 영향도를 관리하기 위해서다. 단순히 데이터베이스만 구축하려는 작업이 아니며 업무 분석과 애플리케이션 설계에도 기준을 제공한다.

자주 출제되는 세 가지 유의점

• 중복(Duplication): 같은 사실을 여러 곳에 저장하면 갱신 누락과 불일치가 생긴다.
• 비유연성(Inflexibility): 데이터 정의가 현재 프로세스와 강하게 묶이면 작은 업무 변화에도 모델을 크게 고쳐야 한다. 데이터와 프로세스를 분리해 설계한다.
• 비일관성(Inconsistency): 서로 연관된 값 사이의 규칙이 모델에 드러나지 않으면 같은 사실이 다르게 표현된다. 관계와 제약조건으로 일관성을 지킨다.

개념·논리·물리 모델을 고르는 법

전사 핵심 업무와 큰 관계       → 개념 모델
속성·식별자·정규화·관계 규칙  → 논리 모델
DBMS 타입·테이블·인덱스·파티션 → 물리 모델

“추상화 수준이 높고 전사적·업무 중심”이면 개념 모델, “실제 DB에 이식할 수 있도록 성능·저장 구조를 반영”하면 물리 모델이다.

문제에 적용하는 순서

1. 지문이 모델링의 목적, 성질, 단계 중 무엇을 묻는지 분리한다.
2. 현재 화면이나 프로세스에 모델을 종속시키는 표현은 비유연성 위험으로 본다.
3. DBMS 제품, 데이터 타입, 인덱스가 나오면 물리 모델인지 확인한다.
4. 업무 의미와 정규화가 중심이면 논리 모델로 판단한다.

하나의 업무를 세 단계로 발전시키기

“고객이 상품을 주문한다”는 요구를 예로 든다.

개념 모델
고객 ─ 주문 ─ 상품이라는 핵심 대상과 큰 관계 정의

논리 모델
고객번호·주문번호·상품번호, 카디널리티, 주문상품 연결 엔터티,
속성 도메인·정규화·업무 유일성 정의

물리 모델
Oracle NUMBER/VARCHAR2/DATE, Table·PK/FK·Index·Partition,
Tablespace·Naming·보안·운영 속성 결정

개념 모델은 전사 의사소통과 범위 합의, 논리 모델은 DBMS 독립적인 업무 규칙, 물리 모델은 특정 DBMS에서의 구현과 성능을 담당한다.

좋은 모델의 검증 질문

• 현재 화면이 바뀌어도 업무 사실과 관계가 유지되는가?
• 같은 사실이 여러 곳에 중복되어 비일관성이 생기지 않는가?
• 식별자와 관계가 데이터 생명주기를 표현하는가?
• 물리 성능 선택이 논리 의미를 훼손하지 않는가?

모델링은 ERD 그림 자체가 목적이 아니라 업무 사실을 명확하고 일관되게 저장해 변경과 조회를 예측 가능하게 만드는 과정이다.

사례를 판별하는 순서

1. 모델이 표현해야 하는 업무 사실과 행 단위(Grain)를 한 문장으로 정의합니다.
2. 각 인스턴스를 유일하게 식별할 수 있는 후보와 변경 가능성을 확인합니다.
3. 속성이 어느 사실에 종속되는지와 관계의 필수성·카디널리티를 확인합니다.
4. 중복 저장으로 삽입·갱신·삭제 이상이 생기는지 검토합니다.
5. 물리 성능을 이유로 구조를 바꿀 때 원천 데이터와 동기화·복구 규칙을 함께 설계합니다.

모델 품질 확인표

• 같은 업무 사실이 여러 곳에 중복 저장되지 않는가?
• 이름과 도메인이 한 가지 의미로 사용되는가?
• PK·FK가 실제 업무 관계와 선택성을 정확히 표현하는가?
• 현재 화면이나 프로세스에 과도하게 종속되지 않는가?
• 정규화와 성능 설계의 이유를 측정 가능한 근거로 설명할 수 있는가?

마지막 점검

• 화면의 입력 항목이나 현재 프로세스를 그대로 엔터티·관계로 옮기지 않습니다.
• 한 행의 업무 사실, 후보 식별자와 함수 종속성을 먼저 확정합니다.
• 중복과 비일관성을 만들면서 조회 편의만 얻는 설계를 정답으로 선택하지 않습니다.
• 반정규화와 물리 설계는 측정된 성능 문제와 동기화·복구 대책이 있을 때 적용합니다.

복습 문제

1. 고객·주문·상품을 찾는 일은 어느 단계인가?
2. PK 인덱스의 저장 옵션을 정하는 일은 어느 단계인가?
3. 이 개념을 실제 업무 사례에서 판별할 수 있는가?
4. 한 행의 업무 의미와 식별자를 설명할 수 있는가?