물리 모델(Physical Model)

물리 모델의 목표

• 성능의 최적화

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

• 성능을 고려해 비정규화 하는것
• ERD차원 : 엔터티의 합체,분해에 의해 모델구조가 다소 바뀌고 중복,추출 속성이 채택되어 모델 변경이 발생.집계엔터티가 추가되거나, 백업 복제 용도의 엔터티가 추가되기도함.
• DBMS차원 : 전체 엔터티에 공통으로 추가되는 시스템 속성 일괄 추가

1.서브타입 모델의 변환

• 슈퍼타입과 서브타입으로 구성된 모델은 통합과 분리에 대한 검토가 필요함
• 서브타입은 보통 핵심적인 엔터티에서 발생하므로 충분히 논의하고 결정할수 있도록 빠를수록 좋음.

2.엔터티 합체와 분해

• 주로 성능문제를 해결하기위해 합체 또는 분해를 수행하게 됨.
• 엔터티의 합체,분해는 데이터를 중복시키는것이 아니므로 비정규화와는 다르고 1:1 관계와 연관됨.

3.비정규화

• 주로 데이터를 중복시키는 방법으로 수행됨.
• 데이터 중복은 아노말리 현상을 초래해 데이터 무결성에 심각한 문제가 발생할 수 있으므로 , 도출된 특정 성능 문제를 해결하기 위한 목적이 아니라면 고려하지 않는게 좋음
• 물리모델링 단계가 아닌 더 이른 단계에서 수행할 수도 있으며, 정규화 수행후 성능 문제가 도출되면 그 시점에서 충분한 논의를 거쳐 비정규화 수행.

4.PK(Primary Key)확정

• 논리 모델링 단계에서 확정된 주 식별자는 대부분 물리 모델에서 PK(Primry Key)가 됨.
• 주 식별자는 자신의 엔터티 뿐만 아니라 하위 엔터티에 미치는 영향이 크므로 가능한 논리 모델링 단계에서 확정하는것이 바람직함.
• 상위 엔터티에 대해서 주 식별자는 확정해 사용해야 하위 엔터티에서 미치는 파급 효과가 줄어듦.
• 파티션이나, 엔터티 합체,분해, 비정규화, 인덱스 효율성 등을 고려해서 약간의 조정을 거쳐 최종 PK 확정함.

5.테이블 파티션 확정

• 성능관점, 관리측면, 가용성 측면을 고려해 확정함.
• 파티션은 데이터 백업과도 연관되며, 파티션 적용 여부에 따라 백업 정책이 달라지고 모델이 변경 될 수 있음
• 파티션 키에 따라 속성이 변경/추가 될수 있으며, 해당 엔터티와 관련된 업무를 알아야 정확하게 대응할 수 있음

6.데이터 저장 방법 확정

• 입력되는 순서대로 저장(기본)
• 성능을 고려해 특정 기준으로 유사값을 모아서 저장(클러스터링 테이블, IOT테이블)

7.인덱스 설계

• 실제 데이터와 SQL 구문이 존재해야하므로 물리모델 단계에서 수행하는것은 한계가 있음
• 물리 모델링 단계에서는 주로 식별자 위주로 선택하며, 최종 인덱스는 개발이 끝나고 엑세스 패턴을 분석하거나 시스템을 가동하면서 사용 빈도를 고려하여 결정해야함.

8.뷰 설계

• 실제 데이터와 SQL구문 실제 화면이 있어야 분석 설계 가능함.
• 시스템에서 뷰를 허용해준다면, 뷰의 사용으로 중복데이터를 상당부분 줄여 줄 수도 있음
• 데이터 무결성이 높아지고 개발 편의성이 좋아질 수 있음

9.시스템 속성 추가

• 전체 엔터티에 공통으로 추가되는 시스템 속성은 최소한으로 가져가는것이 바람직함
• 가능하면 업무적으로는 사용하지 않는것이 바람직함
• 너무많은 시스템 속성은 모델 관리가 불편하며 성능에 악영향을 줄 수있음
• DBMS생성 직전에 추가하는것이 좋음(논리모델링부터 시스템속성이 존재한다면 관리차원의 혼선 발생 가능성이 존재함)
• 다만, 논의는 빠를수록 좋음.