DB 모델링 - 2. 개념 모델 & 논리 모델 & 물리 모델 : 2.3 물리 모델

2.3 물리 모델

 

물리 모델의 목표

   ▶ 성능의 최적화

 

물리모델 관계에서 고려해야 할 사항

   ▶ 성능을 고려해 반정규화 하는 것

      ■ 엔터티의 합체, 분해에 의해 모델구조가 다소 바뀌고 중복, 추출 속성이 채택되어 모델 변경이 발생.

         집계엔터티가 추가되거나, 백업/복제 용도의 엔터티가 추가되기도 함.

   ▶ 전체 엔터티에 공통으로 추가되는 시스템 속성 일괄 추가

 

1) 서브타입 모델의 변환

   ▶ 슈퍼타입과 서브타입으로 구성된 모델은 통합과 분리에 대한 검토하 필요함

   ▶ 서브타입은 보통 핵심적은 엔터티에서 발생하므로 충분히 논의하고 결정할 수 있도록 빠를수록 좋음

 

2) 엔터티 합체와 분해

   ▶ 주로 성능문제를 해결하기 위해 합체 또는 분해를 수행하게 됨

   ▶ 엔터티의 합체/분해는 데이터를 중복시키는 것이 아니므로 반정규화와는 다르고 1:1 관계와 연관됨

 

3) 반정규화

   ▶ 주로 데이터를 중복시키는 방법으로 수행됨

   ▶ 데이터 중복은 아노말리 현상을 초래해 데이터 무결성에 심각한 문제가 발생할 수 있으므로, 도출된 특정 성능 문제를 해결하기 위한 목적이

       아니라면 고려하지 않는게 좋음

   ▶ 물리모델링 단계가 아닌 더 이른 단계에서 수행할 수도 있으며, 정규화 수행 후 성능 문제가 도출되면 그 시점에서 충분한 논의를 거쳐 비정규화

       수행

 

4) PK(Primary Key) 확정

   ▶ 논리 모델링 단계에서 확정된 주 식별자는 대부분 물리 모델에서 PK(Primary Key)가 됨

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

   ▶ 상위 엔터티에 대해서 주 식별자를 확정해 사용해야 하위 엔터티에서 미치는 파급 효과가 줄어듦

   ▶ 파티션이나, 엔터티 합체/분해, 반정규화, 인덱스 효율성 등을 고려해서 약간의 조정을 거쳐 최종 PK 확정함

 

5) 테이블 파티션 확정

   ▶ 성능관점, 관리측면, 가용성 측면을 고려해 확정함

   ▶ 파티션은 데이터 백업과도 연관되며, 파티션 적용 여부에 따라 백업 정책이 달라지고 모델이 변경될 수 있음

   ▶ 파티션 키에 따라 속성이 변경/추가될 수 있으며, 해당 엔터티와 관련된 업무를 알아야 정확하게 대응할 수 있음

 

6) 데이터 저장 방법 확정

   ▶ 입력되는 순서대로 저장(기본)

   ▶ 성능을 고려해 특정 기준으로 유사한 값을 모아서 저장(클러스터링 테이블, IOT 테이블)

 

7) 인덱스 설계

   ▶ 실제 데이터와 SQL 구문이 존재해야 하므로 물리모델 단계에서 수행하는 것은 한계가 있음

   ▶ 물리 모델링 단계에서 주로 식별자 위주로 선택하며, 최종 인덱스는 개발이 끝나고 엑세스 패턴을 분석하거나 시스템을 가동하면서 사용 빈도를

       고려하여 결정해야 함

 

8) 뷰 설계

   ▶ 실제 데이터와 SQL구문 실제 화면이 있어야 분석 설계 가능함

   ▶ 시스템에서 뷰를 허용해준다면, 뷰의 사용으로 중복데이터를 상당부분 줄여줄 수도 있음

   ▶ 데이터 무결성이 높아지고 개발 편의성이 좋아질 수 있음

 

9) 시스템 속성 추가

   ▶ 전체 엔터티에 공통으로 추가되는 시스템 속성은 최소한으로 가져가는 것이 바람직함

   ▶ 가능하면 업무적으로는 사용하지 않는 것이 바람직함

   ▶ 너무 많은 시스템 속성은 모델 관리가 불편하며 성능에 악영향을 줄 수 있음

   ▶ DBMS 생성 직전에 추가하는 좋음(논리모델링부터 시스템 속성이 존재한다면 관리차원의 혼선 발생 가능성이 존재함)

   ▶ 다만, 논의는 빠를수록 좋음

 

[관련 keyword]    ▶ 개념, 논리, 물리 모델의 기본 개념에 대해 이해하고 있다.    ▶ 물리 모델 시 고려해야 하는 상황에 대하여 알고 있다.    ▶ 모델링의 순서를 이해하고 있다.