SQL 자격검정 실전문제 1과목 1차 오답노트 (23.06.03)

정답을 맞췄어도 햇갈리는 문제가 다수 있어 그냥 1번부터 52번까지 정답, 오답의 이유를 정리한다.
 
틀린 문제, 많이 햇갈린 문제 번호를 붉은색으로 표시.
 
 

1단원 1장. 데이터 모델링의 이해

 
 
1번
데이터 모델링은 시스템 구현만을 위해 수행하는 작업이 아니다. 시스템 구현, 업무분석, 업무 형상화를 하는 목적도 있다.
 
 
2번
데이터 모델링은 그 자체로서 업무를 설명하고 분석하는 부분에서 중요한 의미를 가지고 있다.
단순히 데이터베이스 구축만을 위한 작업이 아니다.
 
 
3번
데이터 모델링 시 유의사항 3가지. 중복, 비유연성, 비일관성.
 
중복: 데이터베이스가 여러 장소에 같은 정보를 저장하는 잘못을 저지르지 말아야 한다.
 
비유연성: 사소한 업무변화가 데이터 모델을 수시로 변경하지 않도록 데이터 모델을 설계한다. 비유연성을 지키지 않으면 유지보수가 어렵다. 사용 프로세스와 데이터를 분리햐여 유연성을 높일 수 있다.
 
비일관성: 데이터 모델링 시 데이터와 데이터 간의 상호 연관 관계에 대해 명확하게 정의하여 데이터가 일관성 있게 유지되도록 한다.
 
프로그램, 사용자가 처리하는 프로세스와 테이블의 연계성을 높이는 것은 데이터 모델의 유연성을 취약하게 만드는 단점에 해당한다.
 
 
4번
데이터 모델링 시 비유연성에 대한 핵심 설명 두가지.
* 데이터 모델을 어떻게 설계했느냐에 따라 사소한 업무변화에도 데이터 모델이 수시로 변경됨으로써 유지보수의 어려움을 가중시킬 수 있다.
* 데이터의 정의를 사용 프로세스(프로그램)과 분리함으로써 데이터 혹은 프로세스의 작은 변화가 데이터베이스에 중대한 변화를 일으킬 수 있는 가능성을 줄인다.
 
 
5번
개념적 데이터 모델링 - 추상화 수준 높고 업무중심적이고 포괄적인 수준의 모델링 진행. 전시적 데이터 모델링, EA 수립시 많이 이용.
논리적 데이터 모델링 - 시스템으로 구축하고자 하는 업무에 대해 키, 속성, 관계 등을 정확하게 표현. 재사용성 높음.
물리적 데이터 모델링 - 실제로 데이터베이스에 이식할 수 있도록 성능, 저장 등의 물리적인 성격을 고려하여 설계.
 
 
6번
외부 스키마 - 사용자, 응용 프로그램 개발자가 접근하는 스키마. (사용자 관점)
개념 스키마 - 모든 사용자 관점을 통합한 조직 전체 관점의 통합적 표현. 모든 응용시스템들이나 사용자들이 필요로 하는 데이터를 통합한 조직 전체의 데이터베이스를 기술한 것으로 데이터베이스에 저장되는 데이터와 그들 간의 관계를 표현하는 스키마. (통합 관점)
내부 스키마 - 데이터베이스가 물리적으로 저장된 형식을 표현한 스키마. (물리적 관점)
 
개념스키마(Conceptual schema) != 논리스키마(Logical schema). Logical schema를 검색하면 위키피디아 내용이 나오긴 하는데 시험에서도 선지에서나 나오고 한국어 자료도 영어 자료도 매우 적음. 이런게 있다는 것 정도만 알아두면 됨.
 
 
7번

Mandantory - 필수
Optional - 선택
 
보기의 ERD의 관계를 정리하자면
1. 고객 엔터티 - 주문 엔터티 관계는 1:M 관계.
2. 고객 엔터티에게 주문 엔터티는 선택사항. 주문 엔터티에게 고객 엔터티는 필수사항.
 
3번 선지는 주문 엔터티에 데이터를 입력하려면 필수 관계인 고객 엔터티의 데이터가 반드시 존재해야한다.
4번 선지는 고객 엔터티에 데이터를 입력할 때 주문 엔터티는 선택 관계이기에 주문 엔터티에 관계 없이 데이터 입력 가능하다.
 
필수, 선택 관계를 작대기, 동그라미가 아니라 점선, 실선으로 표시하기도 함. 
이때는 점선이 필수, 실선이 선택.
 
 
8번
ERD에 대한 설명 정리
 
* 1976년에 피터첸이 ERD(Entity-Relationship Model) 만들었다.
 
* 관계의 명칭은 관계 표현에 있어서 매우 중요하다.
 
* ERD 작성 순서는 다음과 같다.
엔터티를 그린다(엔터티 도출) -> 엔터티를 적절하게 배치한다 -> 엔터티간 관계를 설정한다 -> 관계명을 기술한다 -> 관계의 참여도를 기술한다 -> 관계의 필수여부를 기술한다
 
* 사람 눈은 왼쪽에서 오른쪽, 위에서 아래로 움직이는 경향이 있음. 때문에 중요한 엔터티는 왼쪽 상단에 배치하고 이걸 중심으로 다른 엔터티를 나열함. 해당 업무에서 가장 중요한 엔터티는 왼쪽 상단에서 조금 아래쪽 중앙에 배치하여 전체 엔터티와 어울릴 수 있게 함.
 
 
9번
1. 보기의 업무에서 관리하고자 하는 건 '병원'이 아니라 '환자'
2. 병원은 병원 엔터티에 올 속성이 존재하지 않음. 보기의 병원은 'S병원' 하나라 엔터티로서 성립이 불가능.
3. 이름, 주소는 엔터티가 아니라 속성이고 이는 '환자' 엔터티의 속성으로 어울림.
 
 
10번
엔터티의 특징 정리
 
* 반드시 해당 업무에서 필요하고 관리하고자 하는 정보여야 한다. 9번 보기에서 '병원 엔터티'는 보기에서 소개한 업무에서 관리하고자 하는 정보가 아님.
 
* 유일한 식별자(키)에 의해 식별이 가능해야 한다
 
* 영속적으로 존재하는 두 개 이상(한 개 아님)의 인스턴스의 집합이어야 한다.
 
* 엔터티는 업무 프로세스에 의해 이용되어야 한다.
 
* 엔터티는 반드시 속성을 가져야 한다. 속성이 없는 엔터티는 존재할 수 없다. 한 개의 엔터티는 2개 이상의 속성을 갖는다.
 
* 엔터티는 다른 엔터티와 최소 한 개 이상의 관계가 있어야 한다.
 
1개의 엔터티는 여러 개(한 개가 아니라 두 개 이상)의 인스턴스를 가질 수 있고, 하나의 인스턴스는 여러 개의 속성을 가진다. 또한 하나의 속성은 단 하나의 속성값을 가지게 된다.
 
 
11번
10번의 설명 참고
 
 
12번
엔터티의 발생 시점에 따른 분류
기본 엔터티(키 엔터티) - 그 업무에 원래 존재하는 정보. 다른 엔터티와의 관계에 의해 생성되는 것이 아니라 독립적으로 생성이 가능. 타 엔터티의 부모 역할을 함. (사원, 부서, 고객, 상품, 자재)
중심 엔터티(메인 엔터티) - 기본 엔터티에서 발생되어 업무에서 중심 역할을 하는 엔터티. 행위 엔터티를 도출함. (계약, 사고, 예금원장, 청구, 주문, 매출)
행위 엔터티 - 2개 이상의 부모 엔터티로부터 발생되는 엔터티. 다양하고 복잡한 업무를 처리하는 과정에서 도출됨. (주문목록, 사원변경이력)
 
엔터티의 유무형에 따른 분류
유형 엔터티 - 물리적인 형태가 있는 엔터티. 실체가 존재하고 물리적인 형태가 있으며 안정적이고 지속적으로 활용되는 엔터티. (사원, 물품, 강사)
개념 엔터티 - 물리적인 형태가 없는 엔터티. 하지만  업무적으로 관리해야하는 개념적인 정보를 저장하는 엔터티. (조직, 보험상품)
사건 엔터티 - 비즈니스를 수행하면서 발생되는 엔터티. 유형, 개념 엔터티에 비해 발생량이 많고 다양한 통계 자료에 이용될 수 있음. (주문, 청구, 미납)
 
 
13번
엔터티 명명 규칙
* 업무 담당자들이 사용하는, 업계 용어 사용.
* 약어 사용 X
* 단수명사 (사원O 사원들X)
* 해당 모델 내에서, 모든 엔터티에서 유일한 이름이어야 함. 중복 불가.
* 생성한 의미에 맞게 이름을 부여.
 
 
14번
속성: 업무에서 필요로 하는 인스턴스에서 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위
속성값: 속성의 구체적인 값
 
속성값이라고 작성하고 틀렸음. 가장 작은 데이터의 단위가 '속성', 그 속성의 값이 '속성값'
 
 
15번
엔터티 : 인스턴스 = 1 : M
엔터티 : 속성 = 1 : M
인스턴스 : 속성 = 1: M 
속성 : 속성값 = 1 : 1
 
하나의 인스턴스에서 각각의 속성은 반드시 한 개의 속성값을 가져야 한다.
속성도 집합이다. 집합의 원소 개수는 1개도 가능하고, 원소의 개수가 0개인 공집합도 존재한다.
 
 
16번
보기에서 '이자율'은 '원금', '예치기간'과 함께 기본 속성이다. 이 3개의 기본 속성에서 파생된 속성이 '이자'라는 파생 속성이다.
예금분류는 업무 분석을 통해 도출된 속성이 아니라, 데이터 모델 설계를 하면서 보다 간결한 모델 제작을 위해 도출된 '설계 속성'이다.
 
기본 속성 - 업무 분석을 통해 도출된 속성 (상가 엔터티의 상호명, 예금 엔터티의 원금, 예치기간, 이자율)
파생 속성 - 다른 속성에 의해서 계산이나 변형이 되어 생성되는 속성 (이자율과 예치기간을 근거로 한 원금에 대한 이자, 상가 엔터티의 주소를 기반으로 구한 위도와 경도 속성)
설계 속성 - 업무 분석을 통해 도출된 것은 아니지만 데이터 모델 설계를 하면서 더 나은 모델 설계를 위해 도출하는 속성
 
1번 선지는 예금 코드 엔터티를 별도로 생성하여
[예금코드 예금명]
[01       일반예금]
꼴로 만든 다음 예금코드 속성을 다른 엔터티에 가져다 사용한다는 의미이다.
 
 
17번
파생속성: 데이터를 조회할 때 빠른 성능을 낼 수 있도록 하기 위해 원래 속성의 값을 계산하여 저장할 수 있도록 만든 속성.
 
16번의 파생 속성과 같음.
select문으로 이자 데이터를 조회한다고 가정할 때, 조회할 때마다 '원금 * 이자율 * 예치기간' 과 같은 계산을 하는 것보다 '이자' 속성을 만들어 미리 계산하여 저장한 후 필요할 때마다 '이자'를 조회하는 것이 더 빠른 성능을 낸다.
 
 
18번
도메인(Domain): 속성이 가질 수 있는 값의 범위와 유형. 각 속성의 속성값은 정의된 도메인 이외의 값을 가질 수 없다.
 
 
19번
속성의 명명 규칙
* 업무에서 사용하는 이름을 부여
* 속성을 서술식으로 명명하지 않는다
* 약어 사용은 가급적 제한
* 전체 데이터 모델 내에서, 다른 엔터티에서 존재하지 않는 유일한 이름을 명명
* 복합 명사를 사용하여 애매모호하지 않게 구체적으로 명명
 
 
20번
* 관계에는 '존재에 의한 관계'와 '행위에 의한 관계'가 있으나 ERD에서는 이를 구분하지 않고 단일화 된 표법을 사용함.
* UML의 클래스다이어그램의 관계 중 '연관관계'와 '의존관계'가 있고 이것은 실선과 점선의 표기법으로 다르게 표현이 됨.
 
 
21번
1번 선지 - 20번 설명 참고
3번 선지 - '존재에 의한 관계'의 예시로는 부서와 사원 엔티티의 '소속' 관계가 있다. '행위에 의한 관계'의 예시로는 고객과 주문 엔터티의 관계가 있다.
4번 선지 - 주문을 했기에 배송을 한다. '배송근거' 관계는 행위에 의한 관계이다.
 
2번 선지 - 관계의 표기법은 관계명, 관계차수, 관계 선택사양(선택성)의 3가지 개념으로 표현한다.
관계차수는 1:1, 1:M, M:M 관계를 말한다.
관계 선택사양(선택성, 선택사양)은 관계의 필수관계, 선택관계를 말한다. 상술한 7번 문제 해설의 ERD 표기법의 그림이 이에 해당한다.
 
 
22번
21번 선지 해설 참고
 
 
23번, 24번
관계정의 시 체크사항
* 2개의 엔터티 사이에 관심 있는 연관 규칙이 존재하는가?
* 2개의 엔터티 사이에 정보의 조합이 발생되는가?
* 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?
* 업무기술서, 장표에 관계연결을 가능하게 하는 동사(Verb)가 있는가?
 
23번의 3번 선지는 동사가 아니라 명사라고 작성되어 오답.
24번의 보기 가, 나, 다, 라는 모두 옳다.
 
 
25번
보기의 가, 나, 다, 라 전부 옳은 내용이다.
 
식별자를 지정할 때 고려해야할 사향, 식별자의 특징
* 유일성: 주식별자에 의해 엔터티 내의 모든 인스턴스들이 유일하게 구분되어야 한다. (사원 엔터티의 사원번호 속성은 주식별자이고 모든 직원들에 대해 개인별로 고유하게 부여된다)
* 최소성: 주식별자를 구성하는 속성의 수는 최소한의 수로 이루어져야 한다. (사원번호만으로도 고유한데 [사원분류코드 + 사원번호] 조합으로 식별자가 구성되면 부적절한 주식별자 구조이다)
* 불변성: 주식별자가 한번 정해지면 그 값은 변하지 말아야 한다. (한번 정해진 사원번호는 다른 값으로 변경되지 않아야 한다)
* 존재성: 주식별자가 지정되면 반드시 데이터 값이 존재해야하고 주식별자는 NULL을 허용하지 않는다. (사원번호가 없는 회사원은 있을 수 없다)
* 해당 업무에서 자주 이용되는 속성을 주식별자로 지정해야한다.
 
 
26번
사원 엔터티의 식별자 '사번'은 사원 엔터티의 '주식별자'이고,
하나의 속성으로 구성된 '단일식별자'이고,
사원 엔터티 생성 시 내부에서 스스로 만들어진 '내부식별자'이며,
사원 엔터티 생성 시 업무상 만들어지는(부여되는) 속성이기에 '본질식별자'이다.
 
인조식별자는 업무적으로 만들어지지는 않지만 본질식별자가 복잡한 구성을 갖고있을 시 인위적으로 만드는 식별자이다.
예시: 주문 엔터티에서 주문번호 속성의 값으로 '고객번호 + 주문순번'을 사용하지 않고 따로 '주문번호' 식별자를 만들어 시스템적으로 부여함.
식별자가 만약 8개면 select로 조회할 때 where 조건절 조건을 8개를 달아야 함. 이런 경우에 인조식별자를 부여하여 조건을 줄여 SQL문을 간결하게 만든다.
 

 
 
27번
2번 선지의 '이름'은 동명이인이 있을 수 있기에 주식별자로 부적절하다. 이외에 '명칭', '내역'과 같이 이름으로 기술되는 것들은 주식별자로 부적절하다.
 
 
28번
가. 해당 업무에서 자주 이용되는 속성을 주식별자로 지정한다 (O)
나. (X, 명칭, 내역 같이 이름으로 기술되는 것들은 이름이 겹칠 수 있으니 주식별자로 지정하면 안됨 )
다. 복합으로 주식별자를 구성할 경우 너무 많은 속성을 포함하지 않도록 한다 (O, 최소성)
라. (X, 주식별자가 자주 수정되면 자식 엔터티에 대한 연쇄 수정이 필요하여 시스템 상의 부하의 원인이 됨)
 
 
29번
식별자 관계와 비식별자 관계의 기준: 부모 엔터티의 식별자를 자식 엔터티에서 주식별자(외래키, 외부식별자, FK)로 사용하느냐, 물려받지 않고 자식 엔터티에서 별도의 주식별자를 생성하느냐.
 
1번: 강한 연결관계는 식별자 관계, 약한 연결관계는 비식별자 관계.
2번: 자식 테이블에서 주식별자(PK)를 가지길 원한다 -> 부모 엔터티의 주식별자를 받아오지 않는다 -> 약한 연결관계, 비식별자 관계
3번: 식별자 관계를 갖게 되어 테이블 간의 조인이 필연적으로 증가하고, 부모 - 자식 - 손자 엔터티가 식별자를 물려주고, 본인도 따로 식별자를 만들면서 식별자 속성 개수가 많아지게 되어 SQL문장이 길어지고 복잡해진다.
 
4번: 주식별자를 자식, 손자 엔터티에 흘려보내려면 비식별자 관계가 아니라 식별자 관계여야 한다.
 

 
 
30번
데이터의 생명주기(Life Cycle)을 다르게 관리할 경우, 예를 들어 부모 엔터티의 인스턴스가 자식의 엔터티와 관계를 가지고 있지만 자식만 남겨두고 먼저 소멸될 수 있는 경우는 비식별자 관계가 적절하다.
부모 엔터티의 인스턴스가 자식 엔터티와 같이 소멸되는 경우는 식별자 관계로 정의하여 강한 연결관계를 갖게 하는 것이 적절하다.
 
3번 선지에서 여러 개의 엔터티를 하나로 통합하면서 각각의 엔터티가 갖고 있던 여러 개의 개별 관계가 통합되면 관계들이 심하게 엉키니까 비식별자 관계로 관계들을 전부 약하게 만드는 것이 적절하다.
 
 
 
 

1단원 2장. 데이터 모델과 성능

 
 
31번
'성능이 저하된 결과를 대상으로 데이터모델 보다는 문제 발생 시점의 SQL을 중심으로 집중하여 튜닝을 한다.' 라는 문장은 성능 데이터 모델링과 무관한 내용이다.
 
 
32번
정답: 반정규화
반정규화는 다른 방법을 모두 검토한 후에 다른 해결책이 없다면 적용하는 기술이다.
 
 
33번
성능 데이터 모델링 시 고려 사항
1. 데이터 모델링 시 정규화 작업을 수행한다.
2. 데이터베이스의 용량을 산정한다
3. 데이터베이스에 발생되는 트랜잭션의 유형을 파악한다.
4. 데이터베이스 용량 및 트랜잭션의 유형에 따라 반정규화를 수행한다.
5. 이력 데이터 모델의 조정, PK/FK 조정, 슈퍼/서브 타입 변환 조정 등을 수행한다.
6. 성능 관점에서 데이터 모델을 검증한다.
 
 
34번
정규화와 성능
* 정규화를 수행한 후 전에 없었던 조인이 발생하게 되더라도 효율적인 인덱스 사용을 통해 연산을 수행하면 성능상의 단점은 거의 없다.
* 정규화를 수행한 후 중복된 데이터가 제거되어 적은 용량의 테이블이 생성된다면 조인 연산 시 적은 용량의 테이블을 먼저 읽어 조인을 수행하면 되므로 성능상 유리하다.
* 정규화가 제대로 되지 않으면 비슷한 종류의 속성이 여러 개가 되어 과도하게 많은 인덱스가 만들어질 수 있다. 정규화를 하면 하나의 인덱스만 만들어도 된다.
 
요약: 정규화는 기본적으로 중복된 데이터를 제거함으로써 조회 성능을 향상시킬 수 있다
 
 
35번
함수적 종속성 문제는 2차 정규화 대상이다.
식별속성(키)은 2개인데 그 중 하나의 식별속성 B에만 종속된 속성들이 존재한다. -> 식별속성 B와 그에 종속된 속성들을 기존 엔터티에서 독립시켜 다른 엔터티를 생성한다.

결국 2차 정규화는 [테이블 내의 속성들이 전부 주식별자에게 종속된 상태] 를 만드는 것이 목표이다.
그 상태에 방해되는 것들은 싹 쫓아내서 다른 테이블로 묶고 35번 문제도 이와 마찬가지다.
 
정규화 정리
1차 정규화 대상: 같은 유형의 속성이 여러개, 속성과 속성값의 관계가 일대일 관계를 위반하고 일대다 관계를 가짐.
2차 정규화 대상: 식별속성(기본키)에 종속되지 않은 칼럼이 존재함
3차 정규화 대상: 일반속성이 식별속성의 역할을 함. 일반속성에 종속된 칼럼이 존재함.
 
 
36번
식별자 매각물건번호에 최저매각가격, 물건상태코드가 종속되고,
식별자 매각일자에 매각시간, 매각장소가 종속된 상태.
 
식별자에 종속되지 않은 칼럼이 존재한다 - 2차 정규화 대상
특정 장소에 매각된 물건, 특정 시간에 매각된 물건, 특정 일자에 매각된 물건 이라는 관계가 존재하므로 1:M 관계가 될 수 있다.
 
 
37번
칼럼에 의한 반복적인 속성값을 갖는 형태는 1차 정규화 대상이 된다.
유형기능분류코드 각각에 대하여 개별로 인덱스를 생성하면 총 9개의 인덱스를 생성함.
그렇게 되면 DML(입력, 수정, 삭제) 성능에 영향을 주게 되고 기능분류코드 유형이 추가될 때마다 인덱스도 추가로 생성해야함.
1차 정규화를 수행한 후에 인덱스를 적용하는 것이 가장 적절하다.
 
'1번. 조회 조건이 유형기능분류코드에 따라 반복되는 그룹이 칼럼 단위로 되어 있으므로 제 1정규형이라고 할 수 있다.'를 선택하고 틀림.
'1차 정규형'은 1차 정규화가 완료된 테이블이다. 즉, 보기가 1차 정규화가 이미 완료된 상태라는 소리다.
'1차 정규형'과 '1차 정규화 대상'을 잘 구분하자
 
 
38번
같은 유형의 속성이 여러개라 1차 정규화 대상.
일재고와 일재고상세의 관계가 1:M 관계가 될 수 있음.
 
 
39번
식별자에 종속되지 않은 칼럼이 존재함 -> 2차 정규화 대상
2차 정규화 대상 -> 1차 정규화를 마친 상태 '1차 정규형'
 
 
40번
2번 - 탐색 대상 데이터의 크기가 기준이 아니라 다량의 조인 연산이 반복되는 지가 기준이다.
3번 - 이전 또는 이후의 레코드에 대한 탐색은 window function으로 접근이 가능하다
4번 - 집계 테이블 이외에도 다양한 유형에 대햐여 반정규화 테이블 적용이 필요할 수 있다.
 
정답: 1번 - 데이터를 조회할 때 다수 테이블에 대한 다량의 조인이 불가피하면 일부러 중복 칼럼을 추가하는 등의 방법으로 조인 연산에 의한 성능 저하를 방지한다.
 
선지 보충설명
*레코드 = 행 = 튜플. window function은 행과 행 간의 관계를 정의하기 위해 제공되는 함수.
*빌링의 잔액은 잔액 청구를 의미함. 아래의 설명을 보면 잔액을 조회하기 위해선 여러 테이블의 조인이 필요함.
[잔액 청구서는 제공자가 청구된 서비스의 총 비용과 보험이 지불하는 것의 차액을 환자에게 청구하는 의료 청구서입니다.]
빌링의 잔액 참고: https://academic-accelerator.com/encyclopedia/kr/balance-billing
 
 
41번
하나의 테이블의 전체 칼럼 중 자주 이용하는 집중화된 칼럼들이 있을 때 디스크 I/O를 줄이기 위해 해당 칼럼들을 별도로 모아놓는 반정규화 기법: 부분 테이블 추가
 
자주 찾는 칼럼들만 모아서 테이블을 따로 만드는 반정규화 기법. 중복된 데이터를 저장하는 것을 감수하고 조회성능 향상을 얻는다.
 

테이블, 칼럼 반정규화 기법

응용시스템 오작동을 위한 칼럼 추가 - 사용자가 데이터 처리를 하다가 잘못 처리하여 원래의 값으로 복구를 원하는 경우 이전 데이터를 임시적으로 중복 보관하는 기법. 이력데이터 모델로 풀어내면 정상적인 데이터 모델의 기법이 될 수 있다.
 
3, 4번 선지 햇갈림.
*중복테이블 추가 - 다른 업무, 다른 서버일 경우 동일한 테이블 구조를 중복하여서 원격 조인을 제거시켜 성능을 향상함. 테이블을 멀리 조인해서 찾을 필요 없이 가까이에 복사해둠.
*부분 테이블 추가 - 특정 테이블의 전체 칼럼 중 자주 이용하는 집중화된 칼럼들이 있을 때 디스크 I/O를 줄이기 위해 해당 칼럼들을 별도로 모아놓는 반정규화 기법. 자주 쓰는 칼럼 조회할 때 테이블 내의 안쓰는 칼럼까지 조회하면서 성능 저하될 때 사용.  자주 찾는 칼럼들 모아서 테이블 따로 만들기.
 
 
42번
이력테이블이란? 시간에 따라 발생하는 데이터 형식을 이력이라고 한다. 이력 데이터는 시간에 따라 발생하고, 동일한 칼럼 유형에 발생한다. 또한 시간에 따라 반복적으로 발생하기 때문에 다른 테이블에 비해 대량의 데이터가 적재될 가능성이 크다.
 
이력테이블에 기능 칼럼을 추가한다 -> 대량의 이력 데이터를 처리할 때 불특정한 날을 조회하거나, 최근 값을 조회할 때 나타날 수 있는 성능 저하를 예방하기 위해 칼럼을 추가함. (최근값을 자주 조회한다면 최근값만 가진 칼럼을 추가)
 
정답: 'FK에 대한 속성을 추가한다.'라는 선지가 틀렸다. 외래키 속성 추가는 반정규화 기법이 아니라 데이터 모델링에서 관계를 연결할 때 나타나는 자연스러운 현상이다.
 
 
43번 중요!! 이해에 오래 걸렸음!!
오답을 먼저 정리한다.
 
1. 제품 엔터티에 단가를 합한 계산된 칼럼을 추가한다 (오답)
제품 테이블은 아래와 같은 상태임
[제품번호(식별자)   단가]
[     1                      500]
[     2                     400]
 
식별자가 '제품번호'인 테이블에 '주문번호별 단가 합계' 칼럼을 추가하자는 선지임.
문제는 '제품번호'는 여러 '주문번호'에 중복해서 존재할 확률이 높음. '1번 주문'에 '1번 제품 뽀로로 인형', '2번 주문'에 '1번 제품 뽀로로 인형'이 동시에 있을 수 있음.
즉, 제품번호와 주문번호의 관계가 1:M 관계라서 '주문번호별 단가 합계' 칼럼이 추가되면 특정 주문번호별 단가 합계를 골라낼 수가 없음.
'제품번호 1번 가지고 있는 주문번호 있니?' 하고 질의하면 여러 주문번호가 동시에 손들어버려서 식별이 불가능함.
 
 
2. 주문목록 엔터티에 단가를 합한 계산된 칼럼을 추가하도록 한다 (오답)
주문목록 테이블은 아래와 같은 상태임
[주문번호(식별자)   제품번호(식별자)]
[       1                            4, 5, 6       ]
[       2                            7, 5, 6       ]
 
주문번호뿐 아니라 제품번호도 식별자인 테이블임.
'주문번호별 단가 합계' 칼럼을 여기에 추가해버리면 한 '주문번호'에 속한 제품번호마다 동일한 '주문번호별 단가 합계' 금액을 반복적으로 저장해야함.
설명이 좀 틀릴 수 있는데 일단 이렇게 이해하기로 했다.
 
 
4. 제품 엔터티에 최근값 여부에 대한 칼럼을 추가하도록 한다 (오답)
문제랑 상관 없는 답이다
 
 
3. 주문 엔터티에 단가를 합한 계산된 칼럼을 추가하도록 한다 (정답!)
주문 엔터티에 단가를 합한 계산된 칼럼을 추가하면 이런 상태가 된다.
[ 주문번호    SUM(C.단가) ]
[       1                  5000     ]
 
선지에 제시된 반정규화 이전에, 문제에 제시된 SQL 문을 수행하면 이런 결과가 나온다.
[ 주문번호    SUM(C.단가) ]
[       1                  5000     ]
 
특정 주문번호를 기준으로 나열해 단가의 합계를 구하는 SQL 문이라 주문번호 식별자만을 가지고 있는 주문 엔터티에 주문번호별로 합계가 계산된 칼럼을 추가하는 것이 가장 효과적인 반정규화 기법이다.
 
 
44번
1번 선지에 대한 이해가 미흡했음. 2, 3, 4번 선지는 전부 적절한 답이다.
 
1번: 공급자별로 최근에 변경된 전화번호, 메일주소, 위치와 공급자 이름을 같이 조회할 때 이 값들을 공급자 테이블에 반정규화로 갖고 있는 경우에 비해 조회 성능이 저하되지 않는다. (오답)
 
해설: 공급자 별로 전화번호(전화번호 엔터티), 메일주소(메일주소 엔터티), 위치(위치 엔터티), 공급자 이름(공급자 엔터티)를 같이 조회하면 1번 조회할 때 조인만 3번 일어난다. 조인이 많아서 반정규화로 공급자 테이블에 이 값들을 가지고 있는 경우보다 성능이 현저하게 저하한다.
 
 
45번
오답인 1, 2, 4번 선지 먼저 정리함.
 
1번. 한 테이블에 많은 칼럼을 가지고 있으면 조인이 발생되지 않아 여러개 테이블일 때에 비해 성능이 항상 우수하다고 할 수 있다.
조인이 발생하지 않아도 칼럼 몇개 읽으려고 select문 날려도 테이블 내의 수많은 칼럼을 모두 읽게 되어 불필요한 디스크 I/O가 발생함.
 
2번. 테이블 내에서 칼럼의 위치를 조정하는 것은 데이터 주로 채워지는 칼럼을 앞 쪽에 위치시키고, 데이터가 채워지지 않고 주로 NULL 상태로 존재하는 칼럼들을 뒤쪽에 모아둠으로써 로우의 길이를 어느 정도 감소시킬 수 있으나, NULL 상태이던 칼럼에 나중에 데이터가 채워지게 될 경우 더 많은 로우 체인이 발생할 수도 있기 때문에 바람직한 해결책이라고 보기에 부족함.
 
4번. 로우체이닝이 발생할 정도로 한 테이블에 많은 칼럼들이 있으면 조회성능저하가 발생할 수 있고, 이를  해결하기 위한 방법이 테이블 수직 분할이다. 매번 조회할 때마다 필요없는 수많은 칼럼을 읽어들이는 것 보다 조인 몇번 하는 것이 낫다.
 
정답 3번. 로우체이닝이 발생할 정도로 한 테이블에 많은 칼럼들이 존재할 경우 조회성능저하가 발생할 수 있다. 이때 트랜잭션이 접근하는 칼럼유형을 분석하여 1:1 관계로 테이블을 수직 분할하면 디스크I/O가 줄어서 조회성능을 향상시킬 수 있다.
 
 
테이블 수직 분할
* 수직 분할된 테이블 간의 관계는 1:1 관계이다.
* 분리된 테이블은 칼럼의 수가 적어지므로 1개의 행을 읽기 위해서 절대적으로 읽어야 할 데이터 블록의 수가 줄어들어 로우 마이그레이션과 로우 체이닝 현상이 감소한다.
* 마찬가지로 테이블 조회 시 디스크 I/O가 줄어들어 성능이 좋아진다.
 
로우 체이닝
로우 길이가 너무 길어서 데이터 블록 하나에 데이터가 모두 저장되지 않고 2개 이상의 블록에 걸쳐 하나의 로우가 저장되어 있는 형태이다. 하나의 행을 읽을 때 2개 이상의 데이터 블록을 일게 된다.
 
로우 마이그레이션
데이터 블록에서 수정이 발생하면 수정된 데이터를 해당 데이터 블록에서 저장하지 못하고 다른 블록의 빈 공간을 찾아 저장하는 방식이다. 해당 현상이 일어나면서 하나의 행을 읽을 때 2개 이상의 데이터 블록을 읽게 된다.
 
 
46번
정답: 파티셔닝
하나의 테이블에 많은 양의 데이터가 저장되면 인덱스를 추가하고 테이블을 몇 개로 쪼개도 성능이 저하되는 경우가 많다. 이때 논리적으로는 하나의 테이블이지만 물리적으로는 여러 개의 테이블로 분리하여 데이터 액세스 성능도 향상시키고, 데이터 관리 방법도 개선할 수 있도록 테이블에 적용하는 기법을 파티셔닝 이라고 한다.
 
 
47번
오답인 1, 3, 4번 먼저 정리한다.
 
1번. 
UNION: 두 집합의 결과를 합쳐서 출력. 중복값 제거하고 정렬함.
UNION ALL: 두 집합의 결과를 합쳐서 출력. 중복값 제거 안하고 정렬도 안함.
 
3번. 이 선지대로 개선하면 변한 게 없다.
 
4번. 세 개의 테이블을 통합한 중복테이블 하나 더 추가되는거지 조회 성능 향상이 되진 않음.
 
2번. 테이블 하나로 통합, PK 조합하여 구성하여 테이블 통합되어도 구분 가능, UNION ALL 사용할 필요 없음. 데이터 모델과 SQL 문이 명확하게 개선된다 (정답)
 
 
48번
모델링 단계에서 정의한 슈퍼/서브 타입을 물리 모델로 변환하지 않으면 성능이 저하됨.
 
슈퍼 타입/서브 타입 모델 변환의 중요성
* 트랜잭션은 항상 슈퍼 타입 기준으로 처리하는데 테이블은 개별 타입으로 유지되어 UNION 연산에 의해 성능이 저하될 수 있다. (슈퍼 타입 기준으로 테이블을 구성하는 것이 유리함)
* 트랜잭션은 항상 서브 타입을 기준으로 처리하는데 슈퍼 타입으로 되어 있는 경우 성능이 저하되는 경우가 있다. (서브 타입 기준으로 테이블을 구성하는 것이 유리함)
* 트랜잭션은 항상 개별 타입 기준으로 처리하는데 테이블은 슈퍼 타입으로 되어 있어서 불필요하게 많은 양의 데이터가 집약되어 성능이 저하되는 경우가 있다. (개별 타입으로 테이블을 구성하는 것이 유리함)
 
*슈퍼 타입(Single 타입, All in One 타입): 슈퍼/서브 타입 모델을 하나의 테이블로 변환한 것. (예. 고객 테이블 하나로만 구성했다.)
*서브 타입(Plus 타입, Super + Sub 타입): 슈퍼/서브 타입을 서브 타입 테이블들로 변환한 것이다. (예. 개인고객, 법인고객 테이블로 구성했다.)
도출된 각각의 서브 타입에는 변환 전 슈퍼 엔터티에 있던 칼럼들을 공통적으로 가지고 있다.
*개별타입(OneToOne 타입, 1:1 타입): 슈퍼/서브 타입을 슈퍼 타입과 서브 타입의 각각 개별 테이블로 변환한 것이다. (예. 고객, 개인고객, 법인고객 테이블로 구성했다.)
슈퍼 테이블, 서브 테이블 모두 생성한 것이다.
 
 
49번
인덱스는 생성시 기입한 컬럼 순서대로 내부 블록에 데이터를 정렬한 상태로 저장한다.
그리고 테이블 생성 시 PK는 DBMS에서 자동으로 인덱스도 같이 생성되기 때문에 PK가 복합PK일 경우 복합PK의 칼럼 순서가 성능에 영향을 미치게 된다.
정렬한 데이터를 탐색할 때 범위조건(BETWEEN)보다 동등조건(=)이 우선으로 와야 블록 탐색 효율이 높아진다.
 
문제에 제시된 SQL 문은 '사무소코드' PK에 동등조건, '거래일자' PK엔 범위조건을 걸었으므로 복합PK는 '사무소코드', '거래일자' 순으로 와야 인덱스 생성시 성능에 유리하다.
 
 
50번
49번과 같은 문제다.
 
 
51번
엔터티가 부모 자식 관계라면 두 엔터티가 밀접하게 연결되어 상호간에 조인이 자주 발생한다는 것을 의미한다.
 
수강신청 테이블이 부모인 학사기준 테이블에게 외래키(FK)로 받은 '학사기준번호'가 부모 테이블에서 이미 인덱스가 존재하더라도 그것과 관계 없이 조인 성능 향상을 위해, 조인에 의한 성능저하 예방을 위해 별도의 인덱스를 생성해주는 것이 좋다.
 
FK 제약조건 생성 여부와 관계 없이 조인 성능을 향상시키기 위해 인덱스를 생성해주는 것이 좋다.
 
 
52번
Global Single Instance(GSI)는 통합된 한 개의 인스턴스 즉, 통합 데이터베이스 구조를 의미하므로, 분산데이터베이스와는 대치되는 개념이다.

공통코드, 기준정보 등과 같은 마스터 데이터를 한 곳에 두고 운영하는 경우 원격지에서의 접근이 빈번할수록 실시간 업무처리에 대해 좋은 성능을 얻기가 어려울 수 있기 때문에 분산 환경에 복제분산 을 하는 방법으로 분산데이터베이스를 구성할 수 있다. 또한 백업 사이트 구성에 대해서도 분산 환경으 로 구성하여 적용할 수 있다.