모델링 단계 (개념, 논리, 물리)

 

모델 정의

 

개념모델

요구사항 분석 - 중요 엔티티 선별 - 엔티티 정의 - 식별자 정의 - 엔티티 통합 - 엔티티 간 관계 도출

 

논리모델

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

 

논리모델 검증

검증 방법은 현행 엔티티와 매핑하는 것입니다. 현행 업무가 빠진 것이 있는지 검증이 가능합니다.

또 하나의 매핑으로 애플리케이션 매핑입니다. 애플리케이션 분석, 설계에 의한 산출물로 일부 선정이 가능합니다.

더 나아가 화면에서 사용한 항목과 엔티티 속성까지 매핑하면 상호 검증이 완료됩니다

 

물리모델

논리 모델까지 완료되면 모든 구조가 거의 결정됩니다.

데이터베이스를 구현하는 개념이 포함됩니다. 물리 모델링 모형을 표현하고 DBMS 실행까지 단계입니다.

 

DBMS를 설치하고 자원을 사이징, 설계합니다.

모델러가 초기 설계하기 적당하다 판단되면 인덱스와 파티션, 테이블 타입, 뷰 등을 물리 모델링 단계에 포함합니다.

 

물리모델링의 목표는 성능 최적화입니다.

성능과 밀접하게 관련되어 있어 DBA나 튜너와 같은 DBMS 전문가가 수행해야 하는 의견도 있습니다.

하지만, 업무를 모르고 수행하기 어려운 부분이 있어 모델러가 수행해야할 필요도 있습니다.

 

물리 모델링 단계는 크게 두 가지로 나눌 수 있습니다.

1. ERD 의미하는 모델 차원

2. DBMS를 의미하는 물리적 요소

 

ERD 차원에서 주로 성능을 고려해서 비정규화 하는 것입니다. 엔티티의 합체, 분해로 모델 구조가 다소 변경되며 중복, 추출 속성이 채택되면 모델(ERD) 변경이 발생합니다.

 

성능을 고려해 집계 엔티티 추가나 백업이나 복제 용도의 엔티티가 추가되기도 합니다.

모델 변경 업무는 추가나 변경에 의해서도 발생합니다. 이것은 데이터베이스가 실행되고 나서도 발생하는 사항입니다.

 

 

물리 모델링 단계

서브타입 모델의 변환

슈퍼타입과 서브타입으로 구성된 모델은 통합과 분리에 대한 검토가 필요합니다.

핵심적인 엔티티에 대한 결정은 가능한 빠른 단계에서 노출하여 충분히 논의 후 결정하는 것이 좋다

 

엔티티 합체와 분해

일대일 관계의 두 엔티티를 하나의 엔티티로 합치는 것, 하나의 엔티티를 두 개의 엔티티로 분해하는 것, 성능 문제를 해결하기 위해 수행된다.

 

비정규화

데이터를 중복시키는 방법으로 수행됩니다. 데이터 무결성에 문제를 발생시킬 수 있습니다. 그래서 도출된 특정 성능 문제를 해결하기 위한 목적이 아니라면 비정규화 고려는 하지 않아야 합니다.

 

PK 확정

주 식별자는 하위 엔티티에 미치는 영향도 크기 때문에 가능한 논리 모델링 단계에서 충분히 논의해서 확정하는 것이 좋습니다.

 

테이블 파티션 확정

성능뿐만 아니라 관리 측면과 가용성 측면에서도 고려해야 합니다. 파티션은 하나의 테이블을 여러 개의 부분 집합의 테이블로 나눠 물리적으로 관리하는 방법입니다.

 

파티션 대상 테이블 선정은 모델러가 아니어도 수행이 가능합니다. 하지만 파티션은 데이터 백업도 연관되어 파티션 적용 여부로 백업 정책이 달라지고 모델이 변경될 수 있습니다.

 

또한 파티션 키에따라 속성이 변경, 추가될 수 있어 해당 엔티티와 관련된 업무를 정확히 알아야 합니다.

 

데이터 저장방법 확정

특정한 설정이 없다면 데이터는 순서대로 저장됩니다. 주로 성능 문제를 해결하기 위해 특정 속성을 기준으로 유사한 값을 모아 저장합니다.

범위 검색할 때 좋은 성능을 보입니다. 이 방법으로는 클러스터링과 테이블 IOT(Index Organized Table)이 있습니다.

 

인덱스 설계

인덱스를 정확히 설계할 수 있는 조건은 실제 데이터와 SQL 구문이 존재해야 하므로 물리 모델링 단계에서 수행하는데 한계가 있습니다.

물리 모델링 단계에서 인덱스 결정하는 것은 사실상 불가하지만 주 식별자와, 외래 식별자, 후보 식별자 역할의 속성이 인덱스 1차 후보가 됩니다. 시스템을 가동하면서 사용 빈도까지 고려해서 결정해야 합니다.

 

뷰 설계

뷰는 중요성에 비해 소홀히 사용되는 요소입니다. 뷰에는 여러 장점이 있습니다.

인덱스 설계와 유사하게 논리, 물리 모델링 단계에서 수행은 어렵습니다. 뷰 설계의 의미는 SQL 구문이 존재해야 합니다. 최소한 화면이 있어야 뷰에 대한 분석, 설계가 시작될 수 있습니다.

 

뷰 사용을 적극 권장하면 중복 데이터를 상당히 줄일 수 있습니다. 최소한 조인을 하지 않으려고 중복 속성을 채택하는 일은 줄어들 것입니다. 이로 인해 데이터 무결성이 높아지며 개발 편의성도 좋아져 뷰를 적극적으로 활용하는 것을 권장합니다.

 

시스템 속성 추가

전체 엔티티에 공통으로 추가되는 시스템 속성은 최소한으로 설정하는 것이 좋습니다. 가능하면 업무적으로 사용하지 않는 것이 좋습니다.