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

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

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

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

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

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

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

물리 데이터 모델의 품질 검토 기준에 따라서 물리 데이터 모델에 정의된 테이블, 칼럼, 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)는 방법론이나 모델링 도구에 따라 데이터베이스 설계의 검토 항목으로 보기도 함.

장 요약

• 제1절 물리 데이터 모델링 이해
  • 물리 데이터 모델링은 논리 데이터 모델을 기반으로 생성하게 된다.
  • 논리 데이터 모델을 일정한 기준과 규칙에 의해 변환하는 작업이 물리 데이터 모델링이다.
  • 물리 데이터 모델링은 데이터베이스 관리 시스템(DBMS)의 특성, 기능, 성능 등을 고려하여 데이터베이스의 물리적인 구조를 작성하는 과정이다.
• 제2절 물리 요소 조사 및 분석
  • 데이터베이스의 물리적인 구조를 생성하는 데 필요한 요소들을 파악한다.
  • 명명 규칙, 하드웨어 자원의 개략적 내용, 운영체제 및 데이터베이스 관리 시스템 버전(Version) 등이 포함된다.
• 제3절 논리-물리 모델 변환
  • 논리 데이터 모델의 각 요소들을 실제적인 데이터베이스 관리 시스템의 물리적인 객체(Object)로 변환하는 작업을 논리-물리 변환이라 한다.
  • 서브타입의 변환은 몇 가지의 형태가 존재하기 때문에 판단의 근거를 숙지하고 최적의 형태를 결정해야 한다.
  • 관계의 변환 시 배타적 관계의 변환에 대해서도 몇 가지 판단의 근거를 고려해야 한다.
• 제4절 반정규화
  • 반정규화는 하나의 테이블을 수직 또는 수평으로 분할하는 과정이다.
  • 특정 테이블에 데이터가 너무 많이 있고 레코드 중에서 특정한 범위를 주로 액세스(Access)하는 경우에는 수평 분할을 고려할 수 있다.
  • 조회 위주의 칼럼과 갱신 위주의 칼럼이 분명히 나뉘는 경우에는 수직 분할을 고려할 수 있다
  • 반정규화는 성능과 관리 효율을 증대시키지만 데이터의 일관성 및 정합성은 위험을 내포하고 있어 충분한 검토가 필요하다.
• 제5절 물리데이터 모델 품질 검토
  • 물리 데이터 모델 작성 후 설계의 정확성 및 적합성 등을 평가하기 위하여 사전에 데이터 모델 품질검토 기준을 정의하고, 이에 따라 품질검토 체크리스트를 작성하여 활용할 수 있다.
  • 물리 데이터 모델 품질검토 기준과 품질검토 체크리스트는 조직의 형편과 여건에 따라 가감하거나 변형하여 사용할 수 있다.
  • 데이터 모델 품질검토는 ‘성능’과 ‘오류 예방’ 이라 할 수 있다.

연습문제

문제 1. 다음 중 논리 데이터 모델을 근간으로 구현될 시스템의 물리적인 요소를 반영하여 실제 시스템에 구축될 오브젝트를 모델링하는 단계인 ‘물리 데이터 모델’에 대한 정의로 가장 부적절한 것은?

• ① 논리 데이터 모델의 특정 데이터베이스로 설계함으로써 생성된 데이터를 저장할 수 있는 물리적인 스키마를 말한다.
• ② 논리 데이터 모델의 엔터티는 하나의 테이블로 확정된다.
• ③ 하나의 논리 데이터 모델은 여러 개의 물리 데이터 모델로 설계될 수 있다.
• ④ 논리 데이터 모델의 일부 속성만으로 물리 데이터 모델에서 테이블로 설계하는 경우도 발생할 수 있다.

  하나의 엔터티는 물리적 요소들을 감안하여 경우에 따라서는 여러 개의 테이블로 생성될 수 있다. 특히, 성능의 문제를 고려하여 여러 테이블로 생성하는 경우도 종종 발생한다.

문제 2. 다음 중 논리 데이터 모델의 관계변환에 대한 설명으로 가장 부적절한 것은?

• ① 일대다(1:M) 관계는 논리 데이터 모델에서 가장 흔한 관계의 형태이고, 물리 데이터 모델에서는 M쪽 관계의 형태에 따라서 해당 칼럼의 선택사항이 결정된다.
• ② 일대일(1:1) 관계에 의해서 생긴 모든 외래키는 Unique Constraints를 정의할 수 있다.
• ③ 선분이력을 관리하는 상위 엔터티와 관계에서는 상위 엔터티의 식별자 전체를 하위 엔터티에서 상속받지 않아도 데이터적인 연결을 수행할 수 있으므로 식별자 상속을 시키지 않을 수도 있다.
• ④ 일대일(1:1) 관계에서는 양쪽 집합의 선택사양에 따라서 외래키의 생성 위치가 달라질 수 있다. 즉, Optional 관계를 가진 쪽 집합에서 외래기를 생성하는 것이 유리하다.

  일대일(1:1) 관계에서는 Mandatory 관계를 가진쪽에 외래키를 생성하는 것이 바람직하다.

문제 3. 논리 데이터 모델에서 배타적 관계를 물리 데이터 모델로 변환하는 방법은 크게 외래키 분리 방법과 외래키 결합 방법으로 나눌 수 있다. 다음 중 두 방법에 대한 설명으로 가장 부적절한 것은?

• ① 외래키 분리 방법에서 가장 큰 단점은 새로운 관계를 추가 할 때 구조가 변경되어야 한다.는 것이다.
• ② 외래키는 분리 방법에서는 논리 데이터 모델의 배타적 관계를 비즈니스 규칙으로 구현하기 위해서 별도의 제약조건을 생성할 필요가 있다.
• ④ 외래키 결합 방법에서는 외래키 제약조건을 통하여 참조 무결성을 유지할 수 있다.
• ④ 외래키 결합 방법은 배타적 관계에 참여하는 관계들을 구분하기 위해서 추가적인 칼럼이 필요하다.

  외부키의 결합에서는 근본적으로 외부키 제약조건을 생성할 수 없기 때문에 User Defined Trigger 등의 방법을 통하여 해결해야 한다.

문제 4. 반정규화의 한 방법으로 테이블이나 칼럼에 대한 중복을 수행하고자 할 때, 다음 중 고려 및 권고사항으로 부적절한 것을 모두 고르시오.

• ① 넓은 범위를 자주 처리함으로써 수행속도의 저하가 우려되는 경우에는 집계 테이블의 추가를 고려해 볼 수 있다.
• ② 자주 사용되는 액세스 조건이 다른 테이블에 분산되어 있어 상세한 조건 부여에도 불구하고 엑세스 범위를 줄이지 못하는 경우에는 진행 테이블의 추가를 검토하는 것이 바람직하다.
• ③ 빈번하게 조인을 일으키는 칼럼에 대해서는 중복칼럼의 생성을 고려한다.
• ④ 계산된 값은 속성 정의에도 위배되고 함수적 종속이 존재하므로 정규형이 아니다. 하지만 계산하는 비용(노력)이 많이 발생하고 빈번하다면 계산 값을 중복시켜서 가져갈 수 있다.

  자주 사용되는 엑세스 조건이 다른 테이블에 분산되어 있어서 상세한 조건 부여에도 불구하고 엑세스 범위를 줄이지 못하는 경우에 자주 사용되는 조건들을 하나의 테이블로 모아서(칼럼의 중복 즉, 추출 속성으로 하나의 테이블에 모으는 경우를 의미함) 조건의 변별성을 극대화할 수 있다.

문제 5. 다음 중 반정규화의 한 방법으로 테이블이나 칼럼에 대한 중복을 고려할 때에 대한 설명으로 부적절한 것을 모두 고르시오

• ① 다량의 범위를 자주 처리함으로써 수행속도 저하가 우려되는 경우 집계 테이블 추가를 고려한다.
• ② 자주 사용되는 중복 테이블 유형으로는 집계(통계) 테이블과 진행 테이블이 있다.
• ③ 클러스터링, 결합인덱스, 고수준 SQL 등을 적절히 활용하면 집계테이블 없이도 양호한 수행속도를 얻을 수 있기 때문에 집계테이블 고려 시에 반드시 먼저 고려되어야 한다.
• ④ M:M 관계가 포함된 처리의 과정을 추적, 관리하고자 하는 경우에는 다중 테이블 클러스터링이나 조인 SQL의 정확한 구사 등으로 해결이 불가능하므로 반드시 진행 테이블 추가가 고려되어야 한다.

  M:M 관계가 포함된 처리의 과정을 추적, 관리하고자 하는 경우 진행 테이블 추가를 고려할 수 있으나, 다중 테이블 클러스터링이나 정확한 조인 SQL 구사 등을 통해 굳이 진행 테이블을 만들지 않아도 양호한 수행속도를 낼 수 있는 경우가 많이 있다.

문제 6. 다음 중 논리 데이터 모델을 물리 데이터 모델로 변환하는 과정에서 서브타입을 테이블로 변환하는 방법으로 보기 어려운 것은?

• ① 슈퍼타입을 기준으로 하나의 테이블로 변환
• ② 서브타입을 기준으로 여러 개의 테이블로 변환
• ③ 슈퍼타입과 서드타입 각각을 테이블로 변환
• ④ 서브타입을 기준으로 하나의 테이블로 변환

  서브타입을 테이블로 변환하는 방법은 ① ~ ③ 내용과 같음.

문제 7. 다음 중 전체 집합에서 임의의 집합을 추출가공하는 경우가 빈번하고, 복잡한 처리를 하나의 쿼리로 통합하고자 하는 경우 유리한 서브타입 변환 형태는?

• ① 슈퍼타입을 기준으로 하나의 테이블로 변환
• ② 서브타입을 기준으로 여러 개의 테이블로 변환
• ③ 슈퍼타입과 서드타입 각각을 테이블로 변환
• ④ 서브타입을 기준으로 하나의 테이블로 변환

  전체 집합에서 임의의 집합을 추출·가공하는 경우가 빈번하고, 복잡한 처리를 하나의 쿼리로 통합하고자 하는 경우 유리한 서브타입 변환 형태는 슈퍼타입을 기준으로 하나의 테이블로 변환하는 방법이다.

문제 8. 다음 중 물리 데이터 모델에서 데이터 표준을 적용하는 대상으로 보기 어려운 것은?

• ① 테이블
• ② 뷰
• ③ 칼럼
• ④ 데이터타입

  테이블, 뷰, 칼럼 등은 데이터 표준을 적용하는 대상이다.

문제 9. 다음 중 반정규화의 방법으로 테이블을 수직분할 할 때 얻을 수 있는 장점으로 보기 어려운 것은?

• ① 조회와 갱신 처리 중심의 칼럼들을 분할하여 레코드 감금 현상 최소화
• ② 특별히 자주 조회되는 칼럼들을 분할하여 I/O 처리 성능 항상
• ③ 특정 칼럼 크기가 아주 큰 경우의 수직분할은 조인 처리 감소
• ④ 특정 칼럼에 보안을 적용하기가 용이

  • 특정 칼럼 크기가 아주 큰 경우의 수직분할은 I/O 성능 향상에 유리하다.

문제 10. 다음 중 반정규화의 일환으로 중복 칼럼을 생성하는 상황으로 보기 어려운 것은?

• ① 여러 개의 로우로 구성되는 값을 하나의 로우에 칼럼으로 나열하여 관리
• ② 부모 테이블에 집계 칼럼을 추가
• ③ 접근 경로 단축을 위해 부모 테이블의 칼럼을 자식 테이블에 복사
• ④ 검색 조건으로 자주 사용되는 칼럼을 모아 인덱스로 생성

  • 인덱스 생성은 엄밀한 의미에서 반정규화로 보지 않는다.