3.3. 물리 모델

• 물리 모델링의 목표는 성능의 최적화

• 물리 모델의 가장 중요한 역할은 데이터베이스에 실행되는 모델이라는 점

• 물리 모델링 단계에서 고려해야 할 일은 ERD를 의미하는 모델 차원과 DBMS를 의미하는 물리적 요소로 나눌 수 있음

• 모델(ERD) 차원에서 수행되는 대표적인 것은 주로 성능을 고려해 비정규화를 하는 것

• 엔터티의 합체, 분해에 의해서 모델의 구조가 다소 바뀌며 중복, 추출 속성이 채택되면 모델(ERD) 변경이 발생함

• 성능을 고려해 집계 엔터티가 추가되기도 하며 백업이나 복제 용도의 엔터티가 추가되기도 함

• 데이터 타입은 도메인을 지정할 때 정해지므로 사실상 논리 모델링 단계에서 정해짐

• 물리적 요소는 데이터 구조와 연관성이 없으며 성능과 밀접한 관계가 있음.

• 인덱스는 물리 모델링 단계에서 수행될 중요한 요소이지만 물리 모델링 단계에서 성능 문제가 도출되지 않을 수 있어 개발 단계에서 인덱스가 생성될 때가 많음

• 주로 화면을 개발하고 SQL을 작성하면서 필요한 인텍스가 도출됨

• 실데이터가 존재해야 플랜(Plan)을 참조할 수 있으므로 모델이 데이터베이스에 구현된 이후에 인덱스를 설계하는 것이 올바른 순서임

• 논리 모델이나 물리 모델에서는 주 식별자나 업무 식별자, 외부 식별지가 인덱스 생성 대상이라는 것을 공유하는 것으로 충분함

• 주 식별자가 여러 속성으로 구성되면 속성의 순서가 성능에 많은 영향을 미침

• 인덱스를 설계하는 단계에서 주 식별자 속성의 순서가 변경될 수 있음

서브타입 모델의 변환

• 서브타입은 엔터티 통합과 연관돼 있어 도출하는 것이 어렵지 도출된 후의 결정은 그다지 어렵지 않음

• 서브타입을 도출하는 과정에서 어떤 테이블 형태로 관리할지도 어느 정도 결정됨

• 테이블로 어떻게 결정되는지에 따라 논리 모델의 구조가 다소 변하게 됨

• 만약 서브타입이 개별 엔터티로 분리되면 관계 또한 전반적으로 바뀌므로 모델 구조가 많이 변함

엔터티 합체와 분해

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

• 엔터티 합체, 분해는 데이터를 중복시키는 것이 아니므로 비정규화와는 다르고 일대일(1:1) 관계와 연관됨

비정규화

• 비정규화를 수행하는 방법은 주로 데이터를 중복시키는 방법으로 수행됨

• 데이터 중복은 아노말리 현상을 초래해 데이터 무결성에 심각한 문제가 발생힐 수 있음

• 도출된 특정 성능 문제를 해결하기 위한 목적이 아니리면 비정규화는 고려하지 않아야 함

• 비정규화는 물리 모델링 단계에서 수행하지 않고 더 이른 단계에서 수행할 수도 있음

• 정규화를 수행하고 성능 문제가 도출되면 그 시점에 비정규화를 수행하면 됨

• 빠른 단계에서 노출된 문제는 충분한 논의를 거쳐 단계에 구애되지 않고 비정규화를 수행하는 것이 바람직

• 인텍스와 마찬가지로 성능 문제는 주로 개발 단계에서 발견되므로 물리 모델이 구축되고 나서 비정규화 요건이 발생함

PK 확정

• 논리 모델링 단계에서 확정된 주 식별자는 대부분 물리 모델에서 PK가 됨
  이는 논리 모델링 단계에서 업무 식별자를 그대로 사용할지 인조 식별자로 대체할지를 결정했기 때문임

• 주식별자는 자신의 엔터티뿐만 아니라 하위의 엔터티에 미치는 영향이 크므로 가능한 논리 모델링 단계에서 충분히 검토해 확정하는 것이 바람직함

• 핵심적인 상위(부모) 엔터티에 대해서는 주식별자를 확정해 PK로 사용해야 하위(자식) 엔터티에 미치는 파급 효과가 줄어듬

테이블 파티션 확정

• 피티션은 성능 관점에서만 고려하는게 아니며 관리 측면과 가용성 측면에서 고려해야함

• 파티션 키에 따라 속성이 변경, 추가될 수 있으며 해당 엔터티와 관련된 업무를 알아야 정확하게 대응할 수 있어 모델러가 수행하는 것이 바람직함

• 파티션 대상이 되는 후보 엔터티는 이미 핵심적인 엔터티임

데이터 저장 방법 확정

• 일반적으로 데이터는 입력되는 순서대로 저장됨

• 주로 성능 문제를 해결하려 특정 속성을 기준으로 유사한 값을 모아서 저장
  유사한 데이터가 모여 있으면 일정 부분에 대한 범위를 검색할 때 좋은 성능을 보임
  (클러스티링 테이블과 IOT 테이블)

인덱스 설계

• 인덱스는 데이타를 조회하는데 있어 없어서는 안될 중요한 요소

• 방대한 부분이라 모델링의 단위 타스크가 되기에는 적당하지 않을 수 있음

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

• 물리 모델링 단계에서 최적의 인덱스를 결정하는 것은 사실상 불가능하므로 모델링 단계에서 인덱스는 식별자 위주로 선택함

• 즉 주식별자와 외래 식별자, 후보 식별자 역할을 하는 속성이 인덱스의 1차 후보가 됨

• 하지만 최종 인덱스는 결국 개발이 끝나고 액세스 패턴을 분석하고 나서 결정하거나, 시스템을 기동하면서 사용 빈도까지 고려하여 결정해야 함

뷰 설계

• 인덱스 설계와 유사하게 뷰에 대한 설계도 논리 모델링이나 물리 모델링 단계에서 수행하기 어려운 부분이 있음

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

• 시스템에서 뷰의 사용을 적극적으로 권장하면 중복 데이터를 상당 부분 줄일 수 있음

• 조인을 하지 않으려고 중복 속성을 채택하는 일이 줄어듬

• 뷰는 유사한 쿼리를 통합해 일관되게 사용할 수 있으므로 개발자 및 프로젝트 차원에서 유용하게 사용될 수 있음

시스템 속성 추가

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

• 데이터 추적을 정밀하게 하려고 많은 속성을 채택하면 모델 관리를 불편하게 하며, 성능에 악영향을 미치게 됨

• 전체 엔터티에 시스템 속성을 추가하는 시점도 DBMS에 생성하기 바로 직전에 하는 것이 좋음

• 논리 모델링 단계에서부터 시스템 속성을 관리하면 모델 관리 차원에서 혼선이 발생
  반면에 시스템 속성에 대한 논의는 빠를수록 좋음. 어떤 항목을 사용할 것이며 업무적으로는 어떻게 사용할지 많은 논의를 통해 결정해야 함