03 개념 모델 & 논리 모델 & 물리 모델

 

[ 바커 표기법에 따른 개념 데이터 모델 작성 사례: 출처 DBGuide.net ]

 

 

 

 

[ IE 표기법에 따른 개념 데이터 모델 작성 사례: 출처 DBGuide.net ]

 

 

 

 

 

3.1. 개념 모델(Conceptual Model)

 

 

- 데이터 모델이다.

 

- 주제 영역 모델(Subject Area Model) 또는 비즈니스 모델(Business Model)

 

- 중요한 데이터를 가장 간단하게 표현하는 것이 개념 모델의 목적이다.

 

- 해당 주제 영역에 존재하는 핵심적인 중요 엔터티와 그 엔터티의 주요 속성이 도출된 모델이다.

 

- 핵심적인 엔터티와 그 엔터티 사이의 관계를 도출한 것이다.

 

- 개념 모델은 논리 모델로 연결(Alignment)돼야 한다.

 

- 개념 도델링 단계에서는 핵심 엔터티 정의와 엔터티 간 관계를 충분히 논의해야 한다. 논리, 물리 모델링 과정을 거치면서 변하지 않을 뼈대를 만들어야 한다.

 

- 요구 사항을 사용자(User)나 IT담당자, 개발자 등이 이해할 수 있도록 데이터로 간결하게 표현하는 것이 개념 모델의 목표이다.

 

- 핵심적인 엔터티만으로 단순하게 표현해 방향성을 정해야 하므로 개념 모델은 단순하고 가독성이 좋아야 한다.

 

- 가독성 측면에서 데이터(엔터티) 위주의 표현(표기법)이 사용돼야 한다. 해석에 따라 의미가 달라지는 애매한 표현은 사용을 지양해야 한다.

 

- 경영자나 현업 담당자도 이해할 수 있을 만큼 개념 모델은 단순하고 명확해야 한다.

 

- 개념 모델링의 주요 타스트(Task)

• 순서대로 진행해야 하는 타스크라기보다 빠트려서는 안 되는 타스크로 이해하는 것이 더욱 적절하다.
• 요구분석
• 중요 엔터티 선별
• 엔터티 정의
• 식별자 정의
• 엔터티 통합
• 엔터티 간 관계 도출

 

- 요구 분석

• 데이터 모델링을 수행하는 데 필요한 데이터 관점의 요구 사항을 분석하는 타스크를 의미한다.
• 데이터 관점의 요구 사항은 어떤 업무를 하려면 어떤 데이터가 사용돼야 하는지, 좋은 품질의 데이터를 보유하고 업무를 빠르게 수행하려면 데이터 구조를 어떻게 해야 하는지 등을 의미한다.
• 이 타스크를 어떻게 진행하느냐에 따라 데이터 모델의 품질이 결정된다고 해도 과언이 아니다.
• 현행 데이터를 잘아는 IT 담당자가 반드시 상세한 인터뷰를 수행해줘야 한다. 또한 현행 데이터의 문제점과 개선해야 할 점을 요구해야 하며, 향후 추가되거나 보완해야 하는 업무에 대해서도 데이터 관점에서 요구해야 한다.

 

- 중요 엔터티 선별

• 개념 모델링의 사실상 첫 번째 타스크는 핵심적인 엔터티를 선별하는 것이다.
• 개념 모델링 단계에서 가장 피해야 할 것이 엔터티를 너무 상세하게 도출하는 것이다.

 

- 엔터티 정의

• 엔터티 정의가 엔터티에 대한 설명을 의미하는 것은 아니다. 엔터티 정의란 그 엔터티가 어떠한 데이터로 구성되었으며 그 데이터를 묘사하는 요소들은 무엇이고, 그 요소 중에 결정자 역할을 하는 속성은 무엇인지 등을 선언하는 것을 의미한다.
• 엔터티를 정의하는 가장 커다란 원칙은 데이터의 성격(정체성)에 맞도록 규명해야 한다는 것이다.

 

- 식별자 정의

• 엔터티에서 결정자(Determinant) 역할을 하는 속성이 식별자(Identifiers)이다.
• 식별자와 엔터티는 한 몸과 같다.

 

- 엔터티 통합

• 엔터티 통합이란 유사한 성격의 데이터를 일반화(Generalization)시키는 것이다.
• 주제 영역이 서로 다른 엔터티를 통합할 때는 어떤 주제 영역으로 통합해야 하는지, 즉 통합된 엔터티가 속하게 되는 주제 영역이 어디인지를 결정해야 한다. (모델 오너십;Model Ownership)

 

- 엔터티 간 관계 도출

• 핵심 엔터티 간의 관계는 논리 모델이나 물리 모델에서도 불변이어야 하므로 개념 모델링 단계에서 명확하게 규명해야 한다.
• 데이터 발생 순서나 업무 프로세스, 또는 단순히 주 식별자가 같다는 이유 등으로 실제로 존재하지 않는 관계(참조 무결성 제약이 아닌 관계)를 표현하지 말아야 한다.

 

 

 

3.2. 논리 모델(Logical Model)

 

 

- 개념 모델을 상세화하는 작업을 한다.

 

- 이미 도출된 중요 속성 이외의 전체 속성을 도출해야 하고, 개념 모델링 단계에서 도출되지 않은 대부분의 엔터티가 도출돼야 한다.

 

- 논리 모델 구조는 물리 모델과 거의 유사하므로 논리 모델이 완료되면 사실상 모델 구조적으로는 거의 모든 결정이 이루어진다.

 

- 논리 모델은 모델링 완료 여부를 정량적으로 가늠해볼 수 있다.

 

- 논리 모델링의 목적은 비즈니스 요건을 빠짐없이 정확하게 반영하는 것이다.

 

- 논리 모델에는 실체, 행위, 목적 엔터티 등 모든 엔터티가 도출돼야 하며 시스템 속성을 제외한 전체 속성이 도출돼야 한다.

 

- 논리 모델은 더는 삭제할 엔터티나 속성이 없는 모델이다.

 

- 논리 모델링의 주요 단계

• 엔터티 정의
• 관계 도출
• 속성 도출
• 주 식별자 확정
• 정규화
• 이력 관리
• 논리 모델 검증

 

- 엔터티 정의

• 가장 중요한 원칙은 데이터의 성격(정체성)에 맞도록 엔터티를 도출해야 한다.
• 구축된 핵심 엔터티를 중심으로 전체 엔터티를 상세화해야 한다.
• 상세화하는 과정에서 실체, 행위, 목적, 기준 엔터티가 모두 도출되며 누락되는 업무가 없어야 한다.

 

- 관계 도출

• 엔터티 간의 모든 관계(1촌 관계)를 도출해야 한다.
• 일부 추출 관계는 물리 모델링 단계에서 추가될 수 있다.
• 관계를 도출할 때는 실제로 참조 무결성(RI, Referential Integrity) 제약으로 관리되지 않는 관계를 추가하지 않도록 주의해야 한다.

 

- 속성 도출

• 업무적으로 필요한 모든 속성이 도출돼야 한다. 즉 엔터티를 모샤하는 속성이 모두 존재해야 한다.
• 시스템 속성은 작업의 편이성을 위해 물리 모델에 일괄 적용하는 것이 효율적이다.

 

- 주 식별자 확정

• 주 식별자는 엔터티를 정의하는 것과 동시에 도출돼야 한다. 엔터티를 정의하는 과정에서 주 식별자는 대부분 결정된다.
• 따라서 이 단계에서는 이미 도출된 주 식별자를 다시 한 번 확인하는 단계이다.
• 다른 엔터티의 관계까지 고려해 주 식별자를 최종적으로 확정하는 단계이다.

 

- 정규화

• 중복 데이터를 제거해 아노말리가 발생하지 않도록 하는 게 논리 모델링 단계의 기본적인 목표이므로 정규화는 반드시 거쳐야 한다.

 

- 이력 관리

• 데이터가 새로 생기는 것은 내역 데이터다. 그리고 이미 생성된 데이터가 변경되면 이력 데이터가 된다. 내역과 이력은 발생 시점과 변경 시점에 생성되는 차이가 있다.
• 이력 데이터를 어떻게 관리할지는 개념 모델링 단계에서도 고려해야 한다. 이력 관리 방법에 따라 주 식별자가 달라질 수 있고 이로 말미암아 다른 엔터티와 관계가 변동될 수 있으므로 모델링 초반이라도 중요한 업무에 대해서는 반드시 고려해야 한다.

 

- 논리 모델 검증

• 논리 모델을 검증하는 가장 기본적인 방법은 현행 엔터티와 매핑(Mapping)하는 것이다. 이렇게함으로써 현행 업무가 빠진 것이 있는지를 검증할 수 있다.
• 더욱 상세한 검증은 현행 속성과의 매핑이다.
• 또 한 가지의 매핑은 어플리케이션과의 매핑이다.
• Tobe 화면, 엔터티, 화면에서 사용한 항목과 엔터티의 속성과 매핑이다.
• 중요한 데이터는 사례 데이터를 작성하고 의도한 대로 데이터가 생성되는지를 검증한다. 사례 데이터를 활용해 모델을 리뷰한다.
• 현행 코드와 향후 코드를 매핑함으로써 모델을 더욱 심도 있게 검증할 수 있다.

 

 

3.3. 물리 모델(Physical Model)

 

 

- 물리 모델링 단계에서는 모델 구조에 대한 작업보다는 물리적 요소에 대한 작업이 주로 이루어진다.

 

- 데이터베이스에 구현하는 개념을 포함하므로 모델을 도식화하는 모델링과는 차별된다.

 

- 물리 모델링의 목표는 성능을 최적화하는 것이다.

 

- 성능을 고려한 엔터티의 합체와 분해 때문에 모델 구조가 약간 변경될 수 있다. 하지만 이런 구조 변경은 논리 모델의 틀 안에서 이루어져야 한다.

 

- 물리 모델링의 주요 타스크

• 서브타입 모델의 변환
• 엔터티 합체와 분해
• 비정규화
• PK(Primary Key) 확정
• 테이블 파티션 확정
• 데이터 저장 방법 확정
• 인덱스 설계
• 뷰 설계
• 시스템 속성 추가

 

- 서브타입 모델의 변환

• 슈퍼타입(Supertypes)과 서브타입(Subtypes)으로 구성된 모델은 통합과 분리에 대한 검토가 필요하다. 테이블 형태로 결정되므로 보통 물리 모델링 단계에서 수행하기도 하지만 서브타입은 핵심적인 엔터티에서 발생하므로 이 결정은 빠를수록 좋다는 것이 필자의 생각이다.

 

- 엔터티 합체와 분해

• 1:1 관계의 두 엔터티를 하나의 엔터티로 합체하는 것과 하나의 엔터티를 두 개의 엔터티로 분해하는 것은 주로 성능 문제를 해결하기 위해서 수행된다.

 

- 비정규화

• 비정규화(Denormalization)은 주로 데이터를 중복시키는 방법으로 수행된다. 도출된 특정 성능 문제를 해결하기 위한 목적이 아니라면 비정규화는 고려하지 않아야 한다.
• 빠른 단계에서 노출된 문제는 충분한 논의를 거쳐 단계에 구애되지 않고 비정규화를 수행하는 것이 바람직하다.

 

- PK(Primary Key) 확정

• 주 식별자는 자신의 엔터티뿐만 아니라 하위의 엔터티에 미치는 영향이 크므로 가능한 논리 모델링 단계에서 충분히 검토해 확정하는 것이 바람직하다.
• 물리 모델링 단계에서는 파티션이나 엔터티 합체, 분해, 비정규화, 인덱스 효율성 등을 고려하고 약간의 조정을 거쳐 최종 PK를 확정한다.

 

- 테이블 파티션 확정

• 파티션은 하나의 테이블을 여러 개의 부분 집합 테이블로 나눠 물리적으로 관리하는 방법이다.
• 파티션 적용 여부에 따라 백업 정책이 달라지고 모델이 변경될 수 있다.
• 파티션 키(Key)에 따라 속성이 변경, 추가될 수 있으며 해당 엔터티와 관련된 업무를 알아야 정확하게 대응할 수 있어 모델러가 수행하는 것이 바람직하다.

 

- 데이터 저장 방법 확정

• 테이블에 데이터를 저장하는 가장 일반적인 방법은 데이터가 입력되는 순서대로 저장하는 것이다.
• 다른 방법은 주로 성능 문제를 해결하려 특정 속성을 기준으로 유사한 값을 모아서 저장한다. 유사한 데이터가 모여 있으면 일정 부분에 대한 범위를 검색할 때 좋은 성능을 보인다.

 

- 인덱스 설계

• 인덱스를 정확하게 설계할 수 있는 조건은 실제 데이터와 SQL 구문이 존재해야 하므로 물리 모델링 단계에서 수행하는 데 한계가 있다.
• 따라서 모델링 단계에서는 식별자 위주로 선택된다.

 

- 뷰 설계

• 뷰를 설계한다는 것은 SQL 구문이 존재해야 한다는 것이다. 최소한 화면이 있어야 뷰에 대한 분석, 설계가 시작될 수 있을 것이다.

 

- 시스템 속성 추가

• 전체 엔터티에 공통으로 추가되는 시스템 속성은 최소한으로 가져가는 게 바람직하며 가능하면 업무적으로 사용하지 않는 것이 바람직하다.