물리 데이터 모델 품질 검토 개요

물리 데이터 모델 설계가 완료되면 이를 데이터베이스 객체로 생성하고 개발 단계로 넘어가기 전 에 모델러를 비롯한 이해관계자들이 모여 물리 데이터 모델에 대한 리뷰 세션을 통해 작성된 데이터 모델의 품질을 검토하는 것이 바람직하다. 3장에서 언급한 바와 같이 데이터 모델 검토는 개념 데이 터 모델링, 논리 데이터 모델링, 물리 데이터 모델링의 각 단계가 수행된 후 각 단계에서 작성된 개념 데이터 모델, 논리 데이터 모델, 물리 데이터 모델에 대해 이루어진다. 특히 물리 데이터 모델은 시 스템 성능에 대해 직접적인 영향을 미치기 때문에 향후에 발생할 수 있는 성능 문제를 사전에 검토하 여 최소화하는 노력이 절대적으로 필요하다. 논리 데이터 모델의 검토 시와 마찬가지로 물리 데이터 모델을 검토하기 위해서는 모든 이해관계자가 동의하는 검토 기준이 필요하며, 이 또한 과목Ⅰ. 전사 아키텍처 이해 부분에서 설명한 데이터아키텍처 정책 수립 시 DA원칙/표준에 포함되어야할 중요한 사안이다.

물리 데이터 모델링의 범위에 대해서는 어느 정도의 이견이 있을 수 있기 때문에 여기서는 이 장에 서 설명한 내용을 중심으로 물리 데이터 모델의 품질 검토 기준을 예시하였으며, 조직에 따라서는 과 목 VI에서 설명하는 데이터베이스 설계 내용까지를 포함하여 품질 검토 범위에 포함하기도 하고, 데 이터베이스 설계 내용에 해당하는 부분을 별도의 품질 검토 대상으로 보기도 하므로, 각자의 환경에 맞게 적용하는 것이 중요하다. 기본적인 품질 검토 기준은 과목Ⅱ. 데이터 품질 관리 이해 부분에서 설명한 데이터 구조의 관리 기준을 준용할 수 있으며, 데이터 모델에 대한 품질 기준을 좀 더 세분화 해 보면 [표 4-4-1]과 같이 정의해 볼 수 있다. [표 4-4-1]은 3장의 논리 데이터 모델 품질 검토에 서 제시한 [표 4-3-1]의 내용을 물리 데이터 모델 관점으로 재작성한 것이다. 물리 데이터 모델 품 질 검토의 목적은‘성능’과‘오류 예방’의 관점에서 생각해 볼 수 있으며, 이에 따라 물리 데이터 모 델의 품질 기준도 조직에 따라 혹은 업무 상황이나 여건에 따라 가감하거나 변형하여 사용하기도 한 다.

[표 4-4-1] 물리 데이터 모델 품질 기준

기준 항목	설 명	검토 관점 사례
정확성	데이터 모델이 표기법에 따라 정확하게 표현되었고, 업무 영역 또는 요구사항이 정확하게 반영되었음을 의미함	- 사용된 표기법에 따라 물리 데이터 모델이 정확하게 표 현 되었는가 - 대상 업무영역의 업무 개념과 내용이 정확하게 표현 되 었는가 - 요구사항의 내용이 정확하게 반영 되었는가 - 업무규칙이 정확하게 표현/적용 되었는가
완전성	데이터 모델의 구성 요소를 정의하는데 있어서 누락을 최 소화하고, 요구사항 및 업무 영역 반영에 있어서 누락이 없음을 의미함	- 물리 데이터 모델 작성 항목의 충실성(완성도) - 필요한 설명 항목(테이블/칼럼 설명 등)들의 작성 상태 - 물리 모델링 단계에서 결정해야할 항목들의 작성 상태(칼 럼의 데이터 타입 및 길이, Null 허용 여부, 서브타입 변 환, 배타관계 변환, PK, FK, 데이터 무결성 관련 제약사 항 등등. 필요에 따라서는 저장공간 지정, 테이블/인덱스 생성 관련 파라미터 결정 사항 등까지도 포함) - 요구사항 반영 및 업무 영역 반영의 완전성: 목적하는 업무 영역을 기술(설계)한 논리 데이터 모델의 구성요 소(엔터티, 속성, 관계, 식별자 등)들이 누락없이 물리 데이터 모델로 변환되어 정의된 정도 (단, 특별한 목적 에 의해 일부만 물리 데이터 모델로 변환될 수 있으며, 이 경우 목적이 명확해야함)
준거성	제반 준수 요건들이 누락 없이 정확하게 준수되었음을 의미함	- 데이터 표준, 표준화 규칙 등을 준수 하였는가 - 법적 요건을 준수 하였는가 - 법적 요건을 준수하기에 충분하도록 도메인이 정의되었는가
최신성	데이터 모델이 현행 시스템의 최신 상태를 반영하고 있고, 이슈사항들이 지체없이 반영되고 있음을 의미	- 업무상의 변경이나 결정사항 등이 시의 적절하게 반영되고 있는가 - 최근의 이슈사항이 반영 되었는가 - 현행 데이터 모델은 현행 시스템과 일치 하는가
일관성	여러 영역에서 공통 사용되는 데이터 요소가 전사 수준에서 한 번만 정의되고 이를 여러 다른 영역에서 참조·활용되면서, 모델 표현상의 일관성을 유지하고 있음을 의미함	- 여러 주제영역에서 공통적으로 사용되는 엔터티는 일관성 있게 변환되었는가 (전사 수준에서 한 번만 정의되고 이를 여러 다른 영역에서 참조·활용한다는 의미에서 통합성이라 하기도 함) - 모델 표현상의 일관성을 유지하고 있는가 - 동일·유사 목적·용도의 칼럼들은 일관성 있게 정의되었는가 - 조인 대상 칼럼들은 일관성 있게 정의 되었는가
활용성	작성된 모델과 그 설명 내용이 이해관계자에게 의미를 충분하게 전달할 수 있으면서, 업무 변화 시에 설계 변경이 최소화되도록 유연하게 설계되어 있음을 의미	- 작성된 설명 내용이나 모델 표기 등이 사용자나 모델을 보는 사람에게 충분히 이해가 될 수 있고, 모델의 작성 의도를 명확하게 이해할 수 있는가 (의사소통의 충분성) - PK, UK 등의 칼럼 구성은 데이터 무결성을 보장하면서 데이터 액세스를 효율화하기에 충분한가 - 논리 데이터 모델의 유연성이 물리 데이터 모델에도 반영되었는가 (오류가 적고 업무 변화에 유연하게 대응하여 데이터 구조의 변경이 최소화 될 수 있는 설계 결과) - 코드화 대상 칼럼에 대한 코드 정의는 업무 지원 및 적용에 충분한가

물리 데이터 모델 품질 검토 체크리스트의 활용

물리 데이터 모델의 품질 검토 기준에 따라서 물리 데이터 모델에 정의된 테이블, 칼럼, Key 구성, 무결성 제약조건 등 물리 데이터 모델의 주요 구성요소와 물리 데이터 모델 전반에 대한 체크리스트 를 구성할 수 있으며, 이를 통해 물리 데이터 모델의 품질 검토를 보다 용이하게 수행할 수 있다. [표 4-4-2]는 물리 데이터 모델의 주요 구성 요소별로 품질 검토 기준 항목을 적용하여 작성한 품질 검 토 체크리스트의 사례이다.

[표 4-4-2] 물리 데이터 모델 품질 검토 체크리스트 사례 제4장 물리 데이터 모델링 데이터아키텍처

검토대상	검토항목	검토 내용
테이블	테이블명	- 명명 규칙을 준수하였는가? - 제한요건에 따라 약어를 사용한 경우 약어사용 규칙을 준수하였는가? - 의미 전달이 명확한 명칭을 사용하였는가? - 테이블 한글명은 엔터티 명칭과 일치하는가?
	테이블 설명	- 데이터 집합의 개요나 성격, 관리 목적 등을 설명하였는가? - 데이터 집합 구성상의 특징이 설명되어 있는가? - 데이터 집합의 생명주기나 오너쉽 등을 비롯한 기타 특이사항에 대한 내용 을 포함하고 있는가? - 설명된 내용은 모든 이해관계자가 이해하고 의사소통 하는 데에 어려움이 없도록 쉽고 상세하게 기술되었는가?
	테이블 정의	- 특별한 이유가 존재하지 않는 한 논리 데이터 모델의 엔터티가 누락없이 물 리 데이터 모델로 변환되었는가? - 테이블 형태는 성능을 고려하여 결정되었는가? (일반 힙 테이블, IOT, 클 러스터, 클러스터드 테이블, 파티션 등) - 서브타입의 변환 형태는 명확한 판단 기준에 의해 결정되었는가? - 테이블 생성 관련 파라미터들은 적절하고 충분하게 정의되었는가? - 향후의 업무 변화 가능성에 대비하여 모델 변경을 최소화할 수 있도록 유연 성, 확장성이 고려되었는가?
	통합 수준	- 다른 영역에서 동일 목적으로 사용되는 테이블은 동일 명칭과 구조로 일관되게 사용되었는가?
	권한	- 메타데이터 권한을 정의 하였는가? (테이블 생성/변경/삭제) - 데이터 오너쉽을 정의 하였는가? (데이터 생성/변경/삭제) - 테이블에 대한 접근 권한을 정의하였는가? - 테이블에 대한 접근 권한은 적절하게 정의되었는가?
	발생 건수/ 빈도	- 현재의 데이터 저장 건수/빈도는 파악하였는가? - 향후 예상되는 데이터 저장 건수/빈도의 변화가능성은 파악하였는가?
	법규 준수	- 관련 법규에서 요구하는 데이터를 보관하기 위한 테이블을 정의하였는가? - 조직 특성에 비추어 보호가 요구되는 테이블을 식별하였는가?
	요구사항 추적가능성	- 정의된 테이블은 요구사항과 매핑이 되었는가?
칼럼	칼럼명	- 칼럼명은 명명규칙을 준수하였는가? - 제한요건에 따라 약어를 사용한 경우 약어사용 규칙을 준수하였는가? - 의미 전달이 명확한 명칭을 사용하였는가? - 칼럼의 한글명은 속성명과 일치하는가?
	칼럼 정의	- 시스템 내부적으로만 사용되는 칼럼(입력자, 입력일시, 변경자, 변경일시, 내부적으로만 사용되는 identity 칼럼 등) 외에 논리 모델 상에 정의된 속성과의 얼라인먼트가 유지되고 있는가? - 논리 모델의 인조식별자와 같이 일련번호를 저장하는 칼럼의 일련번호 생성 규칙과 방법이 정의되었는가? (Identity 칼럼, Sequence 객체 등)
	칼럼 설명	- 논리 모델에 정의된 속성의 개요나 성격, 관리 목적, 저장 데이터의 형태적 또는 구성상의 특징 등이 물리 모델에 적합한 설명으로 작성되었는가? - 데이터 집합으로서 속성의 생명주기나 오너쉽 등을 비롯한 기타 특이사항에 대한 내용을 포함하고 있는가? - 설명된 내용은 모든 이해관계자가 이해하고 의사소통 하는 데에 어려움이 없도록 쉽고 상세하게 기술되었는가?
	Primary Key	- PK 칼럼의 구성은 데이터의 유일성을 보장하기에 충분한가? - FK 칼럼에 대한 참조무결성 규칙은 정의되었는가?
	Unique Key	- PK 외에 본질식별자에 해당하는 모든 칼럼에 UK가 정의되었는가? - 대체식별자로 정의된 칼럼에 대해 UK가 정의되었는가?
	법규 준수	- 법규상 암호화 대상인 칼럼의 데이터타입과 길이는 암호화를 고려하여 정의되었는가?
	도메인 정의	- 표준 도메인을 정의하여 적용하였는가? - 칼럼의 도메인(데이터 타입, 길이, Not Null 제약, Default 제약, Check 제약 등)은 일관성 있게 정의되었는가?
	추출 칼럼의 정의	- 추출 칼럼에 대한 추출 방법 또는 산식이 명확하게 정의되었는가? - 추출 칼럼에 대한 추출 방법 또는 산식을 적용한 방법은 적절한가? (어플리케이션 로직, 트리거, 기타 등)
	요구사항 추적가능성	- 칼럼 수준에서 필요한 요구사항 매핑은 수행되었는가?
	오너쉽 정의	- 칼럼 수준에서 데이터 오너쉽 정의가 필요한 경우 데이터 오너쉽이 정의되었는가?
FK	참조무결성 규칙 정의	- 논리 모델 상의 관계들은 특별한 이유가 없는 한 누락없이 참조무결성 규칙이 정의되었는가? - 정의된 참조무결성 규칙은 업무 영역의 내용이나 요구사항과 일치하는가? - 배타적 관계의 FK 칼럼에 대한 참조무결성 규칙을 적용하기 위한 방법은 적절한가? (DBMS의 FK 제약조건, 어플리케이션 로직, DB트리거 등)
	요구사항 추적가능성	- 참조무결성 규칙에 대해 필요한 요구사항 매핑은 수행되었는가?
	FK 일관성	- FK 칼럼은 참조하는 PK 칼럼과 도메인 정의가 일치하는가?
모델전반	반정규화	- 반정규화 방법과 형태, 적용 범위는 적절한가? - 반정규화된 테이블이나 칼럼은 명확한 목적에 근거하고 있는가?
	인덱스 정의?주1)	- PK 인덱스 외에 추가적인 인덱스가 고려되었는가? - PK 인덱스를 포함하여 인덱스의 구성 칼럼들은 절적하게 선정되었는가?(액세스 경로 분석 수행 여부) - 인덱스 생성에 관련된 파라미터들은 충분하고 적절하게 정의되었는가?
	스토리지 정의?주2)	- 스토리지 구성은 I/O 분산과 액세스 성능을 고려하여 정의했는가? - 스토리지 정의 파라미터들은 적절하게 정의되었는가? - 테이블과 인덱스는 적절한 테이블스페이스에 할당되었는가?

※ 주1)과 주2)는 방법론이나 모델링 도구에 따라 데이터베이스 설계의 검토 항목으로 보기도 함.