티스토리 뷰
물리 데이터 모델 품질 검토
1. 물리 데이터 모델 품질 검토 개요
- 물리 데이터 모델은 시스템 성능에 대해 직접적인 영향을 미치기 때문에 향후에 발생할 수 있는 성능 문제를 사전에 검토하여 최소화하는 노력이 절대적으로 필요하다.
- 물리데이터 품질 검토의 목적은 ‘성능’과 ‘오류 예방’의 관점에서 생각해 볼 수 있으며, 이에 따라 물리 데이터 모델의 품질 기준도 조직에 따라 혹은 업무 상황이나 여건에 따라 가감하거나 변형하여 사용하기도 한다.
기준항목 | 설명 | 검토 관점 사례 |
정확성 | 데이터 모델이 표기법에 따라 정확하게 표현되었고, 업무 영역 또는 요구사항이 정확하게 반영되었음을 의미함 | • 사용된 표기법에 따라 물리 데이터 모델이 정확하게 표현되었는가 • 대상 업무영역의 업무 개념과 내용이 정확하게 표현되었는가 • 요구사항의 내용이 정확하게 반영되었는가 • 업무규칙이 정확하게 표현/적용되었는가 |
완전성 | 데이터 모델의 구성 요소를 정의하는데 있어서 누락을 최소화하고, 요구사항 및 업무 영역 반영에 있어서 누락이 없음을 의미함 | • 물리 데이터 모델 작성 항목의 충실성(완성도) • 필요한 설명 항목(테이블/칼럼 설명 등)들의 작성 상태 • 물리 모델링 단계에서 결정해야 할 항목들의 작성 상태(칼럼의 데이터 타입 및 길이, Null 허용 여부, 서브타입 변환, 배타관계 변환, PK, FK, 데이터 무결성 관련 제약사항 등등. 필요에 따라서는 저장공간 지정, 테이블/인덱스 생성 관련 파라미터 결정 사항 등 까지도 포함) • 요구사항 반영 및 업무 영역 반영의 완전성: 목적하는 업무 영역을 기술(설계)한 논리 데이터 모델의 구성요소(엔티티, 속성, 관계, 식별자 등)들이 누락없이 물리 데이터 모델로 변환되어 정의된 정도 (단, 특별한 목적에 의해 일부만 물리 데이터 모델로 변환될 수 있으며, 이 경우 목적이 명확해야함) |
준거성 | 제반 준수 요건들이 누락 없이 정확하게 준수되었음을 의미함 | • 데이터 표준, 표준화 규칙 등을 준수하였는가 • 법적 요건을 준수하였는가 • 법적 요건을 준수하기에 충분하도록 도메인이 정의되었는가 |
최신성 | 데이터 모델이 현행 시스템의 최신 상태를 반영하고 있고 이슈사항들이 지체 없이 반영되고 있음을 의미 | • 업무상의 변경이나 결정사항 등이 시의 적절하게 반영되고 있는가 • 최근의 이슈사항이 반영되었는가 • 현행 데이터 모델은 현행 시스템과 일치하는가 |
일관성 | 여러 영역에서 공통 사용되는 데이터 요소가 전사 수준에서 한 번만 정의되고 이를 여러 다른 영역에서 참조∙활용되면서, 모델 표현상의 일관성을 유지하고 있음을 의미함 | • 여러 주제영역에서 공통적으로 사용되는 엔티티는 일관성 있게 변환되었는가 (전사 수준에서 한 번만 정의되고 이를 여러 다른 영역에서 참조∙활용한다는 의미에서 통합성이라 하기도 함) • 모델 표현상의 일관성을 유지하고 있는가 • 동일∙유사 목적∙용도의 칼럼들은 일관성 있게 정의되었는가 • 조인 대상 칼럼들은 일관성 있게 정의되었는가 |
활용성 | 작성된 모델과 그 설명 내용이 이해관계자에게 의미를 충분하게 전달할 수 있으면서, 업무 변화 시에 설계 변경이 최소화되도록 유연하게 설계되어 있음을 의미 | • 작성된 설명 내용이나 모델 표기 등이 사용자나 모델을 보는 사람에게 충분히 이해가 될 수 있고, 모델의 작성 의도를 명확하게 이해할 수 있는가(의사소통의 충분성) • PK, UK 등의 칼럼 구성은 데이터 무결성을 보장하면서 데이터 액세스를 효율화하기에 충분한가 • 논리 데이터 모델의 유연성이 물리 데이터 모델에도 반영되었는가(오류가 적고 업무 변화에 유연하게 대응하여 데이터 구조의 변경이 최소화 될 수 있는 설계 결과) • 코드화 대상 칼럼에 대한 코드 정의는 업무 지원 및 적용에 충분한가 |
2. 물리 데이터 모델 품질 검토 체크리스트의 활용
검토대상 | 검토항목 | 검토 내용 |
테이블 | 테이블명 | • 명명 규칙을 준수하였는가? • 제한요건에 따라 약어를 사용한 경우 약어사용 규칙을 준수하였는가? • 의미 전달이 명확한 명칭을 사용하였는가? • 테이블 한글명은 엔티티 명칭과 일치하는가? |
테이블 설명 | • 데이터 집합의 개요나 성격, 관리 목적 등을 설명하였는가? • 데이터 집합 구성상의 특징이 설명되어 있는가? • 데이터 집합의 생명주기나 오너쉽 등을 비롯한 기타 특이사항에 대한 내용을 포함하고 있는가? • 설명된 내용은 모든 이해관계자가 이해하고 의사소통 하는 데에 어려움이 없도록 쉽고 상세하게 기술되었는가? | |
테이블 정의 | • 특별한 이유가 존재하지 않는 한 논리 데이터 모델의 엔티티가 누락 없이 물리 데이터 모델로 변환되었는가? • 테이블 형태는 성능을 고려하여 결정되었는가? (일반 힙 테이블, IOT, 클러스터, 클러스터드 테이블, 파티션 등) • 서브타입의 변환 형태는 명확한 판단 기준에 의해 결정되었는가? • 테이블 생성 관련 파라미터들은 적절하고 충분하게 정의되었는가? • 향후의 업무 변화 가능성에 대비하여 모델 변경을 최소화할 수 있도록 유연성, 확장성이 고려되었는가? | |
통합 수준 | • 다른 영역에서 동일 목적으로 사용되는 테이블은 동일 명칭과 구조로 일관되게 사용되었는가? | |
권한 | • 메타데이터 권한을 정의하였는가? (테이블 생성/변경/삭제) • 데이터 오너쉽을 정의하였는가? (테이블 생성/변경/삭제) • 테이블에 대한 접근 권한을 정의하였는가? • 테이블에 대한 접근 권한은 적절하게 정의되었는가? | |
발생 건수/ 빈도 | • 현재의 데이터 저장 건수/빈도는 파악하였는가? • 향후 예상되는 데이터 저장 건수/빈도의 변화가능성은 파악하였는가? | |
법규 준수 | • 관련 법규에서 요구하는 데이터를 보관하기 위한 테이블을 정의하였는가? • 조직 특성에 비추어 보호가 요구되는 테이블을 식별하였는가? | |
요구사항 추적가능성 | • 정의된 테이블은 요구사항과 매핑이 되었는가? | |
칼럼 | 칼럼명 | • 칼럼명은 명명규칙을 준수하였는가? • 제한요건에 따라 약어를 사용한 경우 약어사용 규칙을 준수하였는가? • 의미 전달이 명확한 명칭을 사용하였는가? • 칼럼의 한글명은 속성명과 일치하는가? |
칼럼 정의 | • 시스템 내부적으로만 사용되는 칼럼(입력자, 입력일시, 변경자, 변경일시, 내부적으로만 사용되는 identity 칼럼 등) 외에 논리 모델 상에 정의된 속성과의 얼라인먼트가 유지되고 있는가? • 논리 모델의 인조식별자와 같이 일련번호를 저장하는 칼럼의 일련번호 생성 규칙과 방법이 정의되었는가? (Identity 칼럼, Sequence 객체 등) | |
칼럼 설명 | • 논리 모델에 정의된 속성의 개요나 성격, 관리 목적, 저장 데이터의 형태적 또는 구성상의 특징 등이 물리 모델에 적합한 설명으로 작성되었는가? • 데이터 집합으로서 속성의 생명주기나 오너쉽 등을 비롯한 기타 특이사항에 대한 내용을 포함하고 있는가? • 설명된 내용은 모든 이해관계가자 이해하고 의사소통 하는 데에 어려움이 없도록 쉽고 상세하게 기술되었는가? | |
Primary | • PK 칼럼의 구성은 데이터의 유일성을 보장하기에 충분한가? • FK 칼럼에 대한 참조무결성 규칙은 정의되었는가?
| |
Unique Key | • PK 외에 본질식별자에 해당하는 모든 칼럼에 UK가 정의되었는가? • 대체식별자로 정의된 칼럼에 대해 UK가 정의되었는가? | |
법규 준수 | • 법규상 암호화 대상인 칼럼의 데이터타입과 길이는 암호화를 고려하여 정의되었는가? | |
도메인 정의 | • 표준 도메인을 정의하여 적용하였는가? • 칼럼의 도메인(데이터 타입, 길이, Not Null 제약, Default 제약, Check 제약 등)은 일관성 있게 정의되었는가? | |
추출 칼럼의 정의 | • 추출 칼럼에 대한 추출 방법 또는 산식이 명확하게 정의되었는가? • 추출 칼럼에 대한 추출 방법 또는 산식을 적용한 방법은 적절한가? (어플리케이션 로직, 트리거, 기타 등) | |
요구사항 추적가능성 | • 칼럼 수준에서 필요한 요구사항 매핑은 수행되었는가? | |
오너쉽 정의 | • 칼럼 수준에서 데이터 오너쉽 정의가 필요한 경우 데이터 오너쉽이 정의되었는가? | |
FK | 참조무결성 규칙 정의 | • 논리 모델 상의 관계들은 특별한 이유가 없는 한 누락 없이 참조무결성 규칙이 정의되었는가? • 정의된 참조무결성 규칙은 업무 영역의 내용이나 요구사항과 일치하는가? • 배타적 관계의 FK 칼럼에 대한 참조무결성 규칙을 적용하기 위한 방법은 적절한가? (DBMS의 FK 제약조건, 어플레킹션 로직, DB트리거 등) |
요구사항 추적가능성 | • 참조무결성 규칙에 대해 필요한 요구사항 매핑은 수행되었는가? | |
FK 일관성 | • FK 칼럼은 참조하는 PK 칼럼과 도메인 정의가 일치하는가? | |
모델 전반 | 반정규화 | • 반정규화 방법과 형태, 적용 범위는 적절한가? |
인덱스 정의 | • PK 인덱스 외에 추가적인 인덱스가 고려되었는가? • PK 인덱스를 포함하여 인덱스의 구성 칼럼들은 적절하게 선정되었는가? (액세스 경로 분석 수행 여부) • 인덱스 생성에 관련된 파라미터들은 충분하고 적절하게 정의되었는가? | |
스토리지 정의 | • 스토리지 구성은 I/O 분산과 액세스 성능을 고려하여 정의했는가? • 스토리지 정의 파라미터들은 적절하게 정의되었는가? • 테이블과 인덱스는 적절한 테이블스페이스에 할당되었는가? |
'자격증 > DAsP' 카테고리의 다른 글
실전문제 오답노트 - 전사아키텍처 이해 (0) | 2017.12.04 |
---|---|
DAsP 요약 목록 (0) | 2017.12.01 |
DAsP - 물리 데이터 모델링 [반정규화] (0) | 2017.11.29 |
DAsP - 물리 데이터 모델링 [논리-물리 모델 변환] (0) | 2017.11.28 |
DAsP - 물리 데이터 모델링 [물리 요소 조사 및 분석] (0) | 2017.11.27 |