나현
# ch03. 개념모델 & 논리모델 & 물리모델
3.1 개념 모델(Conceptual Model)
목적: 업무에서 핵심적으로 사용되는 데이터의 견고한 토대를 세우는 것
주요 요소
- 핵심 엔티티
- 엔티티 간 관계
특징
- 고려 대상을 줄여 분석 단순화
- 빠른 이해·의사소통 지원
- 상위 수준 모델이라도 반드시 모형으로 존재해야 함
고려사항
- 핵심 엔티티 정의 + 관계 규명이 가장 중요
→ 엔티티 정의가 달라지면 속성과 관계가 모두 변함
→ 작은 정의 오류도 전체 시스템에 큰 영향 - 개념 모델은 논리 모델과 연결(Alignment) 되어야 함
→ 구조와 정의가 일관되게 유지되어야 함
개념 모델링 주요 Task
1. 요구 분석
- 데이터 관점의 요구사항 분석과 모델링을 동시에 진행
- 현행 데이터를 잘 아는 담당자와 최대한 많은 인터뷰
- 현행 문제점·개선점 파악
2. 중요 엔티티 선별
- 너무 상세하게 도출하지 말 것
- 논리 모델링의 30% 정도의 기간에 수행
3. 엔티티 정의
- 데이터 구성 요소, 속성, 결정자 속성 규명
- 데이터 성격(정체성)에 맞게 정의
4. 식별자 정의
- 식별자와 엔티티는 불가분 관계
- 식별자 + 2~3개의 핵심 속성만 표현 (가독성 유지)
5. 엔티티 통합
- 유사 데이터는 일반화(Generalization)
→ 주제 영역 잘못 설정 시 중복 엔티티 발생 - 모델 오너십: 주제 영역이 서로 다른 엔티티를 통합할 때는 통합된 엔티티가 속하게 되는 주제 영역이 어디인지를 결정 필요
6. 엔티티 간 관계 도출
- 핵심 엔티티 간 관계는 불변이어야 함
- 참조 무결성 제약과 직결 → 반드시 실제 존재하는 관계만 표현
3.2 논리 모델(Logical Model)
목적: 비즈니스 요건을 빠짐없이 정확히 반영 → 모델링의 완성 단계
개념 모델 vs 논리 모델
- 개념 모델: 방향성 제시, 핵심 엔티티·관계 중심
- 논리 모델: 모든 엔티티·속성·관계 도출 → 물리 모델과 거의 동일 구조
- 논리 모델이 완료되면 구조적으로 대부분 결정됨
주요 단계
1. 엔티티 정의
- 구축된 핵심 엔티티 중심으로 전체 엔티티 상세화
- 데이터의 정체성 유지, 중복/혼재 데이터 방지
- 주 식별자도 같이 정의
2. 관계 도출
- 엔티티 간 모든 관계 정의
- 참조 무결성 제약 없는 관계는 표현하지 않음
3. 속성 도출
- 모든 속성 포함 (시스템 속성 제외)
- 성능 고려는 제한적, 중복 속성은 최소화
- 성능 문제는 개발에 종속적이기 때문
개발 단계에서 물리 모델의 구조 변경 방지를 위해 논리 모델에 중복, 추출 속성을 무분별하게 반영해 놓는 것은 심각한 상황
4. 주 식별자 확정
- 주변 관계까지 고려하여 최종 확정
- 물리 모델 단계에서 PK 변경은 최소화
5. 정규화
- 완전한 정규형 모델을 지향
→ 성능 문제 발견 시 비정규화 검토
6. 이력 관리
- 내역 데이터 vs 이력 데이터 구분
- 내역 데이터는 데이터가 새로 생기는 경우
- 이력 데이터는 이미 생성된 데이터가 변경되는 경우
- 핵심 엔티티는 이력 관리 방법까지 함께 설계
- why? 이력 관리 방법에 따라 주 식별자가 달라질 수 있고 이로 인해 다른 엔티티 관계가 변경될 수 있음
7. 논리 모델 검증
- 현행 엔티티/속성, 애플리케이션(향후 화면), 사례 데이터와 매핑
- 검증보다 정확한 엔티티 정의가 우선
3.3 물리 모델(Physical Model)
목적: 성능 최적화를 위한 실행 가능한 데이터베이스 설계
특징
- 논리 모델이 구조를 결정 → 물리 모델은 물리적 요소 설계
- 구조 변화는 10% 이내여야 함
주요 고려사항
- 모델 차원(ERD)
- 성능 고려한 비정규화
- 집계·백업·복제 엔티티 추가 가능
- 서브타입 통합/분리 결정은 가능하면 일찍
- 시스템 속성은 DB 생성 직전에 추가
- 물리적 요소(DBMS)
- 인덱스, 파티션, 클러스터, 뷰 등
- 실제 데이터·SQL 기반으로 설계
- 데이터의 액세스 경로를 화면만으로 판단하는 것엔 무리가 있고, 실데이터가 존재해야 실행계획을 참조할 수 있어 모델이 데이터베이스 구현된 이후에 인덱스를 설계하는 것이 올바른 순서이다.
물리 모델링 주요 Task
1. 서브타입 모델 변환
- 통합/분리 결정은 빠를수록 좋음
2. 엔티티 합체·분해
- 주로 성능 문제 해결 목적
(일대일 관계와 연관, 비정규화와 구분)
3. 비정규화
- 성능 문제 해결 목적 외에는 지양
- 정규화 후 필요 시 비정규화
4. PK 확정
- 논리 모델의 주 식별자를 기반으로 최종 확정
(성능, 파티션, 비정규화 고려, 인덱스 효율성 등 고려한 약간의 조정)
5. 테이블 파티션 확정
- 성능 + 관리 + 가용성 측면 고려
- 백업 정책, 파티션 키에 따라 속성 변경 가능성 영향
- 파티션 대상이 되는 후보 엔티티는 이미 핵심 엔티티, 단계 상관없이 지속적 관심 필요
6. 데이터 저장 방법 확정
- 기본: 입력 순서 저장
- 필요 시 특정 속성 기준 클러스터링
7. 인덱스 설계
- 주·외래·후보 식별자가 1차 후보
- 실제 데이터·SQL 분석 후 최종 확정
8. 뷰 설계
- 조인 최소화, 중복 속성 감소, 무결성 향상
9. 시스템 속성 추가
- 최소화, 업무와 분리
- 논의는 빠르게, 적용은 DB 생성 직전에
한음
# ch3. 개념모델 & 논리 모델 & 물리모델
3.1 개념 모델(Conceptual Model)
- 이 책에서 언급하는 개념 모델은 당연히 데이터 모델이다.
- 주제 영역 모델 또는 비즈니스 모델로 불리기도 한다
- 중요한 데이터를 가장 간단하게 표현하는 것이 개념 모델의 목적이다
- 따라서 ERD를 사용할 수도 있고 UML을 사용할 수도 있다
- 개념 모델은 핵심 엔터티와 그 엔터티의 주요 속성이 도출된 모델이다
- 이때 엔터티를 어떻게 정의하느냐에 따라 속성과 관계가 달라지므로 중요하다
- 정의가 약간만 틀어져도 논리 모델링이나 물리 모델링, 심지어 개발, 테스트 단계에 큰 영향을 미칠 수 있다
- 개념 모델은 논리 모델로 연결(Alignment)되어야 한다
- 개념 모델에 표현되었던 엔터티는 논리, 물리 모델링에서도 그대로 표현되어야 한다
- 만약 엔터티를 잘못 도출하여 많은 부분을 누락시키면 노력이 헛되이 될 것이다
- 논리 모델링 기간의 3분의 1 정도만 사용하고 핵심 엔터티에 대한 정의와 모델 구조에만 집중해야 한다
- 의사소통을 위해 데이터로 간결하게 표현하는 것이 목표 이다
- 개념 모델은 핵심 데이터와 핵심 업무에 대한 개념을 한눈에 파악할 수 있게 해준다
- 개발 프로젝트가 아니더라도 시스템의 유지보수 차원에서 유용하게 쓰일 수 있다
- 개념 모델을 보면서 업무 담당자와 IT 담당자가 의사소통을 할 수 있다
- 중복 개발이 없어지며 데이터가 체계적으로 관리된다
- 따라서 개념 모델은 단순하고 명확해야 한다
요구 분석
- 필자는 요구 분석이 개념 모델링 단계에 속한다고 생각한다
- 어떤 업무를 하려면 어떤 데이터가 사용돼야 하는지, 데이터 구조를 어떻게 설계해야 하는지 등을 의미한다
- 일반적으로 인터뷰를 진행하며 모델링을 수행하는 중에 데이터 요구 사항이 도출된다
- 요구 사항 문서를 선(先)완성하려는 접근은 실익이 적다
- 인터뷰를 어떻게 진행하느냐에 따라 데이터의 품질이 결정되지만 현실적으로 쉽지 않다
- 모델러가 할 수 있는 것은 현행 데이터를 가지고 씨름하는 것이다
- 하지만 담당자와 최대한 많은 인터뷰를 통해 시간도 절약하고 잘못된 분석을 하지 않도록 해야 한다
중요 엔터티 선별
- 핵심 엔터티를 선별하고 엔터티를 너무 상세하게 도출하는 것을 지양한다
- 핵심적인 엔터티는 한정되므로 논리 모델링 단계를 더욱 길게 잡아야 한다
엔터티 정의
- 핵심 엔터티가 선별되었으면 엔터티를 분석하면서 정의를 명확하게 해야 한다
- 엔터티 정의란 그 엔터티가 어떠한 데이터로 구성되었으며 그 데이터를 묘사하는 요소들은 무엇이고, 그 요소 중에 결정자 역할을 하는 속성은 무엇인지 선언하는 것이다
- 데이터의 성격(정체성)에 맞도록 규명해야 한다
식별자 정의
- 식별자를 정의하는 것은 엔터티를 정의하는 것과 무관하지 않다
- 결정자를 모르고 엔터티를 안다는 것은 모순에 가깝기 때문이다
- 개념 모델에 식별자를 도출해야 할까?
- 엔터티 정의가 명확하면 식별자도 명확해진 상태인데, 개념 모델에 굳이 식별자를 표현하지 않을 이유가 없다
엔터티 통합
- 엔터티 통합이란 유사한 성격의 데이터를 일반화시키는 것이다
- 주제 영역이 서로 다른 엔터티를 통합할 때는 어떤 주제 영역으로 통합해야 하는지, 즉 통합된 엔터티가 속하게 되는 주제 영역이 어디인지를 결정해야 한다
- 이를 모델 오너십이라 한다
- 애플리케이션 오너십으로 말미암아 엔터티가 어떤 주제 영역에 속하는지를 의미하는 모델 오너십이 바뀌어서는 안 된다
엔터티 간 관계 도출
- 핵심 엔터티 간의 관계는 논리 모델이나 물리 모델에서도 불변이어야 하므로 개념 모델링 단계에서 명확하게 규명해야 한다
- 실제로 존재하지 않는 관계는 표현하지 말아야 하고, 실제로 존재하는 관계를 빠뜨려서도 안 된다
- 엔터티를 통합하기 위해서 반드시 선행돼야 하는 작업은 엔터티를 명확하게 정의하는 것이다
3.2 논리 모델(Logical Model)
- 개념 모델을 상세화하는 작업을 한다
- 관계를 포함한 사실상 모든 데이터 요소가 도출되어야 하므로 전체 모델링 과정에서 가장 오랜 시간이 소요된다
- 사실상 모델 구조적으로 거의 모든 결정이 이뤄진다
- 만약 물리 모델링 단계에서 큰 변화가 발생하면 논리 모델링을 잘못 수행한 것이다
- 논리 모델링의 목적은 비즈니스 요건을 빠짐없이 정확히 반영하는 것이다
- 시스템 속성을 제외한 전체 속성을 도출한다
- 삭제할 것이 더는 존재하지 않는 모델이 논리 모델이지만 성능을 고려하지 않을 이유는 없다
엔터티 정의
- 논리 모델링 단계에서는 구축된 핵심 엔터티를 중심으로 전체 엔터티를 상세화한다
- 상세화하는 과정에서 실체, 행위, 목적, 기준 엔터티가 모두 도출되며 누락되는 업무가 없어야 한다
관계 도출
- 논리 모델링 단계에서는 엔터티 간의 모든 관계를 도출해야 한다
- 참조 무결성 제약으로 관리되지 않는 관계를 추가하지 않도록 주의해야 한다
속성 도출
- 업무적으로 필요한 모든 속성이 도출되며, 시스템 속성만 제외한다
- 성능 문제는 심도 있게 논의하기 어렵다
- 개발 단계에서 물리 모델의 구조가 변경되는 것은 심각한 상황이지만, 비정규화에 의한 속성 추가, 삭제, 합체, 분해 등은 일어날 수 있고 자연스러운 것이다
주 식별자 확정
- 주 식별자는 엔터티를 정의하는 것과 동시에 도출되어야 한다
- 따라서 이 단계에서는 이미 도출된 주 식별자를 다시 한번 확인하는 단계다
- 물론 물리 모델링 단계에서 PK가 최종적으로 확정된다
정규화
- 원칙적인 논리 모델은 완전한 형태의 정규형 모델이다
- 중복 데이터를 제거해 아노말리가 발생하지 않도록 하는 게 논리 모델링 단계의 기본적인 목표이므로 정규화는 반드시 거쳐야 한다
- 이 과정을 거쳐야 데이터 구조가 되며 엔터티는 더욱 명확해지고 모델 구조는 견고해진다
이력 관리
- 최근에는 이력 데이터에 대한 관심과 관리 요구가 높아지고 있어 주의를 기울여야 한다
- 데이터가 새로 생기는 것은 내역 데이터이고, 이미 생성된 데이터가 변경되면 이력 데이터가 된다
- 이력 관리 방법에 따라 주 식별자가 달라질 수 있고, 다른 엔터티와 관계가 변경될 수 있으므로 반드시 고려해야 한다
- 특히 핵심 엔터티에 대해서는 이력 데이터까지 고려하는 것이 좋다
논리 모델 검증
- 논리 모델은 현행 엔터티를 기준으로 작업 진도를 어느 정도 정량적으로 계산할 수 있다
- 가장 기본적인 방법은 현행 엔터티와 매핑하는 것이다
- 현행 업무가 빠진 것이 있는지 검증할 수 있다
- 애플리케이션과의 매핑이 있다
- 사례 데이터를 작성함으로 검증할 수 있다
- 사례 데이터를 작성하고 의도대로 데이터가 생성되는지 검증한다
- 코드 매핑을 통해 심도 있는 검증을 할 수 있다
3.3 물리 모델(Physical Model)
- 물리 모델링 단계에서는 모델 구조에 대한 작업보다는 물리적 요소에 대한 작업이 이뤄진다
- 모형으로 표현하는데서 그치지 않고 DBMS 실행하는 것까지 포함된다
- 인덱스와 파티션, 테이블 타입, 뷰 등을 물리 모델링 단계에 포함한다
- 물리 모델링의 목표는 성능을 최적화하는 것이다
- 데이터베이스와 밀접한 관계가 있어 DBA나 튜너 같은 DBMS 전문가가 참여하는 것이 좋다
- 성능을 고려한 엔터티의 합체와 분해 때문에 모델 구조가 변경될 수 있다
- 하지만 이런 구조 변경은 논리 모델의 틀 안에서 이루어져야 한다
- 물리 모델은 데이터베이스 실행 모델로, 의사소통 도구로서 잘 활용되지 않는다
- 모델(ERD) 차원에서 수행되는 대표적인 것은 주로 성능을 고려해 비정규화를 하는 것이다
- 성능을 고려해 집계 엔터티가 추가되기도 하며 백업이나 복제 용도의 엔터티가 추가되기도 한다
- 물리 모델링 단계에서 서브타입 형태의 모델에 대한 통합과 분리가 결정되기도 한다
- 전체 엔터티에 공통으로 추가되는 시스템 속성은 물리 모델링 맨 마지막 단계, 데이터베이스 실행 직전에 수행하는 것이 좋다
- 하지만 공통 시스템 속성은 미리 결정해 충분하게 공감대를 형성해야 한다.
- 모델의 구조적인 모습만 고려하면 논리 모델과의 차이는 크지 않다.
- 물리 모델링 단계에서 변화는 많아야 10% 이내일 것이다
- 데이터 타입을 물리 모델링 단계에서 정의해야 한다는 주장도 있지만 도메인을 지정할 때 정해지므로 사실상 논리 모델링 단계에서 정해진다
- 인덱스는 물리 모델링 단계에서 중요한 요소이지만 성능 문제가 도출되지 않을 수 있어 개발 단계에서 인덱스가 생성될 때가 많다
서브타입 모델의 변환
테이블 형태로 결정되므로 보통 물리 모델링 단계에서 수행하기도 하지만, 서브타입은 핵심적인 엔터티에서 발생하므로 이 결정은 빠를수록 좋다
- 만약 서브타입이 개별 엔터티로 분리되면 관계 또한 전반적으로 바뀌므로 모델 구조가 많이 변할 것이다
엔터티 합체와 분해
- 주로 성능 문제를 해결하기 위해서 수행된다
비정규화
- 주로 데이터를 중복시키는 방법으로 수행된다
- 데이터 중복은 아노말리 현상을 초래해 데이터 무결성에 심각한 문제가 발생할 수 있다
- 특정 성능 문제를 해결하기 위한 목적이 아니라면 비정규화는 고려하지 않아야 한다
- 정규화를 수행하고 성능 문제가 도출되면 그 시점에 비정규화를 수행하면 된다
PK 확정
- 논리 모델링 단계에서 확정된 주 식별자는 대부분 물리 모델에서 PK가 된다
- 주 식별자는 논리 모델링 단계에서 충분히 검토해 확정하는 것이 바람직하다
- 특히 핵심적인 상위 엔터티에 대해서는 주 식별자를 확정해 PK로 사용해야 하위 엔터티에 미치는 파급 효과가 줄어든다
테이블 파티션 확정
- 파티션은 RDBMS에서 중요한 개념 중 하나이며 반드시 고려해야 할 사항이다. 성능뿐 아니라 관리와 가용성 측면까지 함께 검토해야 한다
- 파티션은 데이터 백업과도 연관되므로 파티션 적용 여부에 따라 백업 정책이 달라지고 모델이 변경될 수 있다
데이터 저장 방법
- 가장 일반적인 방법은 데이터가 입력되는 순서대로 저장하는 것이다
- 다른 방법은 성능 문제를 해결하기 위해 유사한 값을 모아서 저장한다
인덱스 설계
- 물리 모델링 단계에서 최적의 인덱스를 결정하는 것은 사실상 불가능하므로, 모델링 단계에서는 식별자 위주로 인덱스를 선정한다
- 최종 인덱스는 결국 개발이 끝나고 액세스 패턴을 분석하고 결정하거나 시스템을 가동하면서 사용 빈도까지 고려해야 한다
시스템 속성 추가
- 시스템 속성은 최소한으로 가져가는 게 바람직하며, 가능하면 업무적으로 사용하지 않는 것이 바람직하다
- 데이터 추적을 정밀하게 하려고 많은 속성을 채택하면 모델 관리를 불편하게 하며 성능에 악영향을 미치게 된다
- 시스템 속성을 추가하는 시점은 DBMS 생성하기 직전에 하고 반면 논의는 빠를 수록 좋다