제5절 논리 데이터 모델 품질 검토

1. 논리 데이터 모델 품질 검토 개요

데이터 모델 설계가 완료되면 모델러를 비롯한 이해관계자는 데이터 모델 리뷰 세션을 통해 작성된 데이터 모델의 품질을 검토한다. 데이터 모델 검토는 개념 데이터 모델링, 논리 데이터 모델링, 물리 데이터 모델링의 각 단계가 수행된 후 각 단계에서 작성된 개념 데이터 모델, 논리 데이터 모델, 물리 데이터 모델에 대해 이루어진다. 일반적으로 논리 데이터 모델과 물리 데이터 모델은 모든 이해 관계자들이 가장 관심을 갖고 검토하는 산출물로, 데이터 모델의 중요성을 생각하면 이 검토 과정이야말로 향후의 모든 공정에 대해 영향을 미칠 수 있는 매우 의미 있는 작업이라 할 수 있다. 데이터 모델을 검토하기 위해서는 모든 이해관계자가 동의하는 검토 기준이 필요하며, 통상 논리·물리 데이터 모델에 대한 검토 기준은 과목Ⅰ. 전사아키텍처 이해 부분에서 설명한 데이터아키텍처 정책 수립 시 DA원칙/표준에 포함되어야할 중요한 사안이다.

데이터 모델의 품질 검토 기준은 주로 논리 데이터 모델과 물리 데이터 모델에 대해 적용하며, 조직에 따라서는 개념 데이터 모델에 대한 검토 기준을 추가하기도 한다. 기본적인 품질 검토 기준은 과목VI. 데이터 품질 관리 이해 부분에서 설명한 데이터 구조의 관리 기준을 준용할 수 있으며, 논리 데이터 모델에 대한 품질 기준을 좀 더 세분화해 보면 [표 4-3-1]과 같이 정의해 볼 수 있다. 논리 데이터 모델 품질 검토의 목적은‘완벽한 모델’보다‘(조직에) 적합한 모델’의 관점에서 생각해 볼 수 있으며, 이에 따라 논리 데이터 모델의 품질 기준도 조직에 따라 혹은 업무 상황이나 여건에 따라 가감하거나 변형하여 사용하기도 한다.

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

기준 항목	설 명	검토 관점 사례
정확성	데이터 모델이 표기법에 따라 정확하게 표현되었고, 업무영역 또는 요구사항이 정확하게 반영되었음을 의미함	◼ 사용된 표기법에 따라 데이터 모델이 정확하게 표현 되었는가 ◼ 대상 업무영역의 업무 개념과 내용이 정확하게 표현 되었는가 ◼ 요구사항의 내용이 정확하게 반영 되었는가 ◼ 업무규칙이 정확하게 표현 되었는가
완전성	데이터 모델의 구성 요소를 정의하는데 있어서 누락을 최소화하고, 요구사항 및 업무영역 반영에 있어서 누락이 없음을 의미함	◼ 모델 표현의 충실성(완성도) ◼ 필요한 항목(엔터티/속성 설명 등)들의 작성 상태 ◼ 논리 데이터 모델링 단계에서 결정해야할 항목들의 작성 상태(속성의 선택성(optionality), 식별자, 정규화, 엔터티/속성의 중복배제, 이력관리 등) ◼ 요구사항 반영 및 업무 영역 반영의 완전성: 목적하는 업무 영역을 기술(설계)하는데 있어서 논리 데이터 모델 구성요소(엔터티, 속성, 관계 등)들이 누락없이 정의 된 정도
준거성	제반 준수 요건들이 누락 없이 정확하게 준수되었음을 의미함	◼ 데이터 표준, 표준화 규칙 등을 준수하였는가 ◼ 법적 요건을 준수 하였는가
최신성	데이터 모델이 현행 시스템의 최신 상태를 반영하고 있고, 이슈사항들이 지체없이 반영되고 있음을 의미	◼ 업무상의 변경이나 결정사항 등이 시의 적절하게 반영되고 있는가 ◼ 최근의 이슈사항이 반영 되었는가 ◼ 현행 데이터 모델은 현행 시스템과 일치 하는가
일관성	여러 영역에서 공통 사용되는 데이터 요소가 전사 수준에서 한 번만 정의되고 이를 여러 다른 영역에서 참조·활용되면서, 모델 표현상의 일관성을 유지하고 있음을 의미함	◼ 여러 주제영역에서 공통적으로 사용되는 엔터티는 일관성 있게 사용되는가(전사 수준에서 한 번만 정의되고 이를 여러 다른 영역에서 참조·활용한다는 의미에서 통합성이라 하기도 함) ◼ 모델 표현상의 일관성을 유지하고 있는가
활용성	작성된 모델과 그 설명 내용이 이해관계자에게 의미를 충분하게 전달할 수 있으면서, 업무 변화 시에 설계 변경이 최소화되도록 유연하게 설계되어 있음을 의미	◼ 작성된 설명 내용이나 모델 표기 등이 사용자나 모델을 보는 사람에게 충분히 이해가 될 수 있고, 모델의 작성 의도를 명확하게 이해할 수 있는가(의사소통의 충분성) ◼ 데이터 모델은 유연성을 갖고 있는가(오류가 적고 업무변화에 유연하게 대응하여 데이터 구조의 변경이 최소화 될 수 있는 설계 결과)

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

논리 데이터 모델의 품질 검토 기준에 따라서 논리 데이터 모델에 정의된 엔터티, 관계, 속성 등 데이터 모델의 주요 구성요소와 논리 데이터 모델 전반에 대한 체크리스트를 구성할 수 있으며, 이를 통해 논리 데이터 모델의 품질 검토를 보다 용이하게 수행할 수 있다. [표 4-3-2]는 논리 데이터 모델의 주요 구성 요소별로 품질 검토 기준 항목을 적용하여 작성한 품질 검토 체크리스트의 사례이다.

[표 4-3-2] 논리 데이터 모델 품질 검토 체크리스트 사례

검토대상	검토항목	검토 내용
엔터티	엔터티명	◼ 사용된 표기법에 따라 데이터 모델이 정확하게 표현 되었는가 ◼ 대상 업무영역의 업무 개념과 내용이 정확하확하게 반영 되었는가 ◼ 업무규칙이 정확하게 표현 되었는가 ◼ 데이터 집합의 개요나 성격, 관리 목적 등을 설명하였는가? ◼ 데이터 집합 구성상의 특징이 설명되어 있는가? ◼ 데이터 집합의 생명주기나 오너쉽 등을 비롯한 기타 특이사항에 대한 내용을 포함하고 있는가? ◼ 설명된 내용은 모든 이해관계자가 이해하고 의사소통 하는 데에 어려움이 없도록 쉽고 상세하게 기술되었는가?
엔터티 정의	◼ 도출된 엔터티는 요구사항을 충족하거나 업무 영역을 설명하기에 충분한가? ◼ 우선순위에 따른 엔터티 분류 관점에서 중요한 키엔터티나 메인엔터티가 누락되지 않았는가? ◼ 엔터티는 서브타입을 사용하여 구체적·입체적으로 정의되었는가? ◼ 서브타입 정의 시 구분자 속성은 명확하게 정의하였는가? ◼ 서브타입 구성은 엔터티의 성격을 설명하기에 충분한가? ◼ 서브타입은 충분하게 도출되었는가? (전체집합=Σ서브타입) ◼ 향후의 업무 변화 가능성에 대비하여 모델 변경을 최소화할 수 있도록 유연성, 확장성이 고려되었는가?
통합 수준	◼ 업무 행위의 주체가 될 수 있는 전사관계자와 같은 중요 기준데이터는 통합이 고려되었는가? ◼ 엔터티간 동질성을 부여할 수 있는 유사 목적·구성의 엔터티에 대해 통합이 고려되었는가? (서브타입 사용) ◼ 코드 엔터티는 통합이 고려되었는가? ◼ 계층구조 엔터티에 대한 통합은 고려되었는가? ◼ 배타관계 엔터티의 통합은 고려되었는가? ◼ 다른 영역에서 동일 목적의 엔터티는 동일 명칭과 구조로 일관되게 사용되었는가? ◼ 엔터티 분리는 명확하고 합리적인 근거와 목적에 의해 적절한 형태로 이루어졌는가?
권한	◼ 메타데이터 권한을 정의 하였는가? (엔터티 생성/변경/삭제) ◼ 데이터 오너쉽을 정의 하였는가? (데이터 생성/변경/삭제)
발생 건수/ 빈도	◼ 현재의 데이터 저장 건수/빈도는 파악하였는가? ◼ 향후 예상되는 데이터 저장 건수/빈도의 변화가능성은 파악하였는가?
다른 엔터티와의 관계	◼ 다른 엔터티와 하나 이상의 관계를 가지고 있는가?
법규 준수	◼ 관련 법규에서 요구하는 데이터를 보관하기 위한 엔터티를 정의하였는가? ◼ 조직 특성에 비추어 보호가 요구되는 엔터티를 식별하였는가?
요구사항 추적가능성	◼ 정의된 엔터티는 요구사항과 매핑이 되었는가?
속성	속성명	◼ 속성명은 명명규칙을 준수하였는가? ◼ 제한요건에 따라 약어를 사용한 경우 약어사용 규칙을 준수하였는가? ◼ 의미 전달이 명확한 명칭을 사용하였는가?
속성 정의	◼ 엔터티명이나 엔터티 성격에 맞는 속성이 도출되었는가? ◼ 엔터티의 성격이나 목적에 비추어 속성은 충분하게 도출되었는가? ◼ 속성의 선택성 결정은 적절한가? ◼ 유일값 원칙에 위배되는 속성이 존재하는가? ◼ 속성의 원자단위 구성은 적절한가? ◼ 속성의 관리 목적상 상세화 여부 검토가 수행되었는가? ◼ 인조 속성의 생성 단위나 생성 규칙이 정의되었는가?
속성 설명	◼ 속성의 개요나 성격, 관리 목적 등을 설명하였는가? ◼ 속성으로 관리하고자 하는 데이터의 형태적 혹은 구성상의 특징이 포함되어 있는가? ◼ 데이터 집합으로서 속성의 생명주기나 오너쉽 등을 비롯한 기타 특이사항에 대한 내용을 포함하고 있는가? ◼ 설명된 내용은 모든 이해관계자가 이해하고 의사소통 하는 데에 어려움이 없도록 쉽고 상세하게 기술되었는가?
속성 유형	◼ 엔터티 성격에 맞게 식별자가 정의되었는가? ◼ 관계를 통해 상속받은 관계속성은 명확한 역할명을 사용하고 있는가?
식별자 정의	◼ 모든 본질식별자가 적절하게 파악되었는가? ◼ 인조식별자 사용 시 대응하는 속성 구성이 파악되었는가? ◼ 실질식별자로서 본질식별자나 인조식별자를 사용하는 기준을 준수하고 있는가?
법규 준수	◼ 법규상 암호화 대상인 속성은 식별하였는가? ◼ 법규상 필요한 속성은 정의되었는가? ◼ 법규상 수집·보관에 따른 제약이 존재하는 속성은 처리 방안을 고려하고 적용하였는가?
도메인 정의	◼ 표준 도메인을 정의하여 적용하였는가? ◼ 속성의 도메인은 일관성 있게 정의되었는가?
추출 속성의 정의	◼ 추출 속성은 명확하고 합리적인 이유를 토대로 정의하였는가? ◼ 추출 속성의 원시 속성은 식별하였는가? ◼ 추출 속성은 추출 방법 또는 산식이 명확하게 정의되었는가? ◼ 추출 속성의 빈도(구성 수준)는 적절한가?
요구사항 추적가능성	- 속성 수준에서 필요한 요구사항 매핑은 수행되었는가?
오너쉽 정의	◼ 속성 수준에서 데이터 오너쉽 정의가 필요한 경우 데이터 오너쉽이 정의 되었는가?
관계	관계명	◼ 관계명이 누락된 관계가 존재하는가? ◼ 관계명 부여 규칙 존재 시 이를 준수하였는가? ◼ 두 엔터티 간의 업무적 관계를 자식(자식 엔터티)이 바라보는 부모(부모 엔터티)의 역할 관점으로 파악하여 관계명을 표현하였는가?
관계 정의	◼ 업무 영역을 설명하거나 요구사항을 충족하는데 있어서 필요한 관계들이 충분히 도출·정의되었는가? ◼ 관계 정의는 업무 영역의 내용이나 요구사항과 일치하는가? ◼ 배타적 관계가 정의된 경우 업무 내용과 일치하는가? ◼ 배타적 관계가 정의된 경우 현재의 업무 개선 관점이 고려되었는가? ◼ 배타 관계 해소를 위한 검토가 수행되었는가?
관계 설명	◼ 관계가 왜 존재해야 하는지의 관점에서 기술하고 있는가?(업무규칙, 정규화 등)
관계 표현	◼ 표기법에 따라 정확하게 표현하였는가? ◼ 관계에 표현된 기수성·선택성은 업무규칙을 정확하게 설명하는가?
식별자 상속	◼ 자식에 상속된 관계 속성은 정확한 역할명으로 표현되었는가? ◼ 모든 관계 속성들의 출처(또는 관계)가 명확하게 파악되었는가?
요구사항 추적가능성	◼ 관계에 대해 필요한 요구사항 매핑은 수행되었는가?
외부키 (외래키)*	◼ 외부키(외래키)가 부모 엔터티의 주식별자(실질식별자)와 일치하는가? ◼ 외부키 항목이 기본키와 기본키가 아닌 속성에 펼쳐져 있는가? ◼ 자식에 상속된 관계 속성의 선택성은 적절한가?
참조무결성**	◼ 업무규칙에 근거하여 참조무결성을 정의하였는가?
모델전반	주제영역 적절성	◼ 주제영역의 구성은 적절한가?
논리 모델 상세화	◼ 데이터 모델상에 정규화가 미흡한 부분이 존재하는가? ◼ 최종적인 논리 데이터 모델에서 다대다 관계는 모두 해소 하였는가?
이력 관리	◼ 이력관리 대상 선정과 이력관리 방법은 적절한가?

※ *, ** 표기한 부분은 방법론이나 모델링 도구에 따라 물리 데이터 모델의 검토 항목으로 보기도 함.

장 요약

제1절 논리 데이터 모델링 이해
- 논리 데이터 모델링은 개념 데이터 모델링에서 정의한 핵심 엔터티와 관계를 바탕으로 속성을 정의하고 식별자를 확정하는 과정이다.
- 논리 데이터 모델링에서는 정규화를 통하여 새로운 엔터티가 생성되거나 또는 새로운 관계들이 생성된다.
- 논리 데이터 모델링은 많은 M:M 관계가 해소되면서 새로운 행위 엔터티들이 생성되는 과정이다.
제2절 속성 정의
- 속성은 엔터티에서 관리되는 구체적인 정보 항목을 말한다.
- 속성은 더 이상 분리될 수 없는 최소의 데이터 보관 단위이다.
- 속성도 엔터티와 같이 업무 내용, 다양한 문서들을 통하여 도출된다.
- 속성을 정의하는 순서는 먼저 후보들을 도출하고 속성이 될 수 있는 조건들에 부합하는지를 확인하여 최종적으로 속성을 정의한다.
제3절 엔티티 상세화
- 엔터티 상세화는 크게 4단계로 구체화된다.
  - 식별자 확정 단계
    - 이제까지 논리적 의미의 식별자(본질 식별자)를 기준으로 관계들이 생성되고 속성들이 정의되었다면 이 단계에서는 실질적 식별자를 생성한다.
  - 정규화 단계
    - 정규화는 논리적 데이터 모델의 일관성을 유지하고 중복을 제거하여 보다 안정적인 모델을 만드는 단계이다.
  - M:M 관계 해소 단계
    - 개념 데이터 모델에서 핵심 엔터티 간의 M:M 관계가 해소되면서 교차 엔터티(Intersection Entity)가 생성되는 단계이다.
  - 참조 무결성 정의 단계
제4절 이력 관리 정의
- 이력 데이터의 관리는 모든 데이터를 대상으로 하지는 않는다.
- 실제 이력이 발생하는 데이터 중에서도 꼭 필요한 데이터에 한정해서 이력 관리를 수행한다.
- 이력 관리에서 중요한 사항은 이력 관리의 형태로 시점 이력과 선분 이력 중에 적합한 형태를 결정하는 것이 중요하다.
제5절 논리 데이터 모델 품질 검토
- 논리 데이터 모델 작성 후 설계의 정확성 및 적합성 등을 평가하기 위하여 사전에 데이터 모델 품질검토 기준을 정의하고, 이에 따라 품질검토 체크리스트를 작성하여 활용할 수 있다.
- 데이터 모델 품질검토 기준과 품질검토 체크리스트는 조직의 형편과 여건에 따라 가감하거나 변형하여 사용할 수 있다.
- 데이터 모델 품질검토는 ‘완벽한 모델’ 보다 ‘(조직에) 적합한 모델’ 을 얻기 위함이다.

연습문제

문제 1. 다음 중 논리 데이터 모델링의 필수 성공 요소로 부적절한 것은?

① 업무를 알고 있는 현업 사용자의 참여는 필수적이다.
② 절차(Procedure)보다는 데이터에 초점을 두고 모델링을 진행하여야 한다.
③ 데이터의 구조(Structure)와 무결성(Integrity)을 함께 고려해야 한다.
④ 데이터 모델링을 지원하는 CASE 도구의 사용은 필수적이다.

CASE 도구의 사용은 권장사항이지만 필수사항은 아니다.

문제 2. 엔터티에서 실제 인스턴스 탄생의 주체에 해당하는 속성들을 ‘본질 식별자’라고 한다. 본질 식별자는 여러가지 목적으로 인해 본질 식별자를 대체할 인조 식별자를 지정하게 된다. 다음 중 인조 식별자 지정에 대한 설명으로 부적절한 것은?

① 최대한 범용적인 값을 사용한다.
② 유일한 값을 만들기 위해 인조 식별자를 사용한다.
③ 편의성 · 단순성 확보를 위해 인조 식별자를 사용할 수 있다.
④ 내부적으로 사용되는 인조식별자는 가급적 피한다.

경우에 따라서는 내부적으로만 사용되는 인조 식별자를 사용 할 수도 있다. 특히, 시스템에서 사용하는 데이터들에 이러한 유형의 식별자가 많이 존재한다.

문제 3. 데이터 모델링에서는 계층적으로 생기는 데이터를 관리하기 위해서 흔히 순환관계 모델을 생정하게 된다. 다음 중 순환관계 데이터 모델에 대한 설명으로 가장 부적절한 것은?

① 순환관계 모델은 새로운 계층의 추가 수정에 대해서 유연하게 대처할 수 있다. 즉, 구조의 변화가 필요 없이 변화에 대처할 있다.
② 순환관계 모델에서 최상위는 의미적으로 NULL이지만 물리적인 요소(수행 성능 등)를 고려해서 특정 값을 갖는 것이 바람직하다.
③ 다대다(M:M) 순환관계를 처리하기 위해서는 별도의 엔터티를 추가하여야 한다.
④ 순환관계 모델에서 구조가 변경되면 식별자가 변해야 하기 때문에 과거의 데이터에 대해서 수정작업을 수행해야 한다.

구조가 변경되더라도 식별자는 변경되지 않기 때문에 과거 데이터를 변경할 필요가 없다.

문제 4. A기업은 논리 데이터 모델링의 중간 단계에서 속성후보들을 도출하고 각각의 속성 후보에 대해서 타당성 작업을 수행하고 있는데, 다음 중 검증의 방법으로 가장 부적절한 것은?

① 최소 단위 분할 여부를 판단한다.
② 해당 속성 후보가 단일값을 갖는지 판단한다.
③ 추출 속성인지 판단한다.
④ 식별자로 사용되는 것인지 판단한다.

식별자 검증은 속성 검증이 완료되고 해당 엔터티내에서 식별자를 지정하게 된다. 따라서 식별자로 사용되는지를 판단하는 것은 속성검증과는 거리가 멀다.