[SQLD]1과목 - 3장. DB 구조와 성능

 

1절. DB 구조와 성능

1. 슈퍼타입/서브타입 데이터 모델 변환을 통한 성능 향상

• 부모의 속성 중에 더 작은 그룹으로 분리해서 관리할 필요가 있는 속성이 있을 때, 슈퍼타입 또는 서브타입 단위로 모델링한다.
• 그 중 슈퍼타입(전체를 하나의 테이블로 관리)에 정의된 공통 속성과 각 서브타입의 속성을 더하여 각각의 서브타입별로 테이블을 설계하는 방법이 서브타입 단위의 모델링이다.
• 트랜잭션은 전체를 통합하여 분석처리하는데 슈퍼-서브타입이 하나의 테이블로 통합되어 있으면 하나의 테이블에 집적된 테이블만 읽어 처리할 수 있기 때문에 다른 형식에 비해 더 성능이 우수하다. (개별로 유지하면 조인에 의해 성능이 저하될 수 있다.)
• 트랜잭션은 서브타입 개별로 처리하는데 테이블은 하나로 통합하여 변환하면 불필요하게 많은 양의 데이터가 집적되어 있어 성능이 저하될 수 있다.

 

 

---

2. 슈퍼타입 모델링

• 장점
  전체 사원에 대한 검색이 쉽다
  무결성에 유리하다

 

• 단점
  서브타입별 속성이 많다면 지나치게 NULL이 많이 발생한다.(공간의 낭비)

 

---

3. 서브타입 모델링

• 장점
  NULL이 없거나 줄어들고(공간의 낭비가 적다), 정규직과 임시직사원을 별개로 처리할때 효율이 좋다.
• 단점
  UNION 함수를 쓸 때 중복제거 되기 때문에, 사번의 유일성(Unique)을 잘 관리해야 한다.
  INTERSECT 연산 시 양쪽 테이블에 중복 사원이 안 나오도록 무결성을 유지하는 것이 중요하다.
  비효율적인 조인이나 합집합, 교집합이 발생할 수 있다.(속도 저하)

 

• 두 서브타입간에 교집합이 없을 경우 배타적exclusive 서브 카테고리 라고 한다.

교집합 없는 경우 표시법

 

• 두 서브타입 간에 교집합이 있을 경우 포괄적inclusive 서브 카테고리라고 하고, 표시법은 위에 X가 없음

 

 

---

4. ROLLUP & ROLLDOWM

Rollup을 실행하면 서브타입 → 슈퍼타입으로 변환
Rolldown을 실행하면 슈퍼타입 → 서브타입으로 변환

 

 

Rollup

• 슈퍼타입에 서브타입의 모든 컬럼을 통합하여 하나의 테이블로 생성.
• 전체 테이블을 같이 Access처리하는 것이 대부분인 경우
• 서브타입의 속성 개수가 적은 경우(1~2개)
• 서브타입과 관계를 맺은 엔티티가 별로 없는 경우
• 업무적으로 변화가능성이 작아 추가적인 서브타입이나 속성 추가의 가능성이 적은 경우

 

• 장점 :
  조인할 일이 없으므로 SQL문장 구성이 단순
  수행속도가 빨라지는 경우가 많다.
  서브타입을 구분하지 않고 데이터를 조회할 경우 처리가 용이하다.
• 단점 : 특정 서브타입의 NOT NULL 제한 불가 (NULL값이 많아질 수 있다)

 

 

Rolldown

• 슈퍼타입을 각각의 서브타입에 추가하여 서브타입별로 테이블 생성.
• 데이터 처리 서브타입을 구분하여 사용함에 따라 공통적인 속성들만 별도로 Access할 필요가 없는 경우
• 슈퍼타입의 속성개수가 많지 않은 경우
• 슈퍼타입과 관계를 맺은 엔티티가 거의 없는 경우

 

• 장점 : 정보를 각 서브타입 별로 조작할 경우, 조인하지 않아도 되며 Full Scan 발생시 유리 관계에 의해 발생하는 복잡한 참조 무결성 규칙을 적용할 수 있다.
• 단점 : 처리속도 감소할 수 있다. UID 유지 관리가 어렵다.

 

 

Identity

• 슈퍼타입과 서브타입 각각을 테이블로 생성(일부 서브타입은 슈퍼타입에 통합되는 경우도 존재)
• 슈퍼타입과 서브타입을 각각 적절히 Access하는 경우
• 슈퍼타입에 속한 공통속성들만 Access하는 빈도가 높은 경우
• 슈퍼타입과 서브타입 각각 별도 관계를 맺은 엔티티들이 존재하는 경우
• 업무적으로 변화가능성이 높아 유연성을 확보할 필요가 있는 경우
• 장점 : 각각의 테이블로 처리할 경우, 수행 속도가 빠르다.
  슈퍼 타입에 속한 정보만 조회하는 경우, 문장 작성이 용이하다.
  컬럼의 중복이 적으므로, 상대적으로 작은 공간을 차지한다.
  관계에 의해 발생하는 복잡한 참조 무결성 규칙을 적용할 수 있다.

 

---

5. 변환

• 변환을 통해 1정확하게 업무를 표현할 수 있고, 물리적 모델링 시 선택의 폭을 넓힐 수 있음
• 변환 기준 : 데이터 양, 트랜잭션 유형
• 변환 기술
  • 1:1 타입(OneToOne type) : 개별로 처리하는 트랜잭션에 대해 개별 테이블 구성, 슈퍼타입과 서브타입 각각 필요한 속성과 유형에 적합한 데이터만 가지도록 분리하여 1:1 관계를 갖도록 함
  • 슈퍼/서브 타입(Plus type) : 슈퍼타입과 서브타입을 공통으로 처리하는 트랜잭션에 대해 슈퍼타입과 서브타입 각각의 테이블 구성
  • All in One 타입(Single type) : 일괄 처리하는 트랜잭션에 대해 단일 테이블 구성

 

	1:1 타입	슈퍼/서브 타입	All in One 타입
특징	개별 테이블 유지	슈퍼/서브 타입 테이블 구성	단일 테이블 구성
트랜잭션 유형	개별 처리	슈퍼/서브 타입 공통 처리	일괄 처리
확장성	좋음 (테이블 추가 용이)	보통	나쁨
조인 성능	나쁨 (조인 많이 필요)	나쁨 (조인 많이 필요)	좋음
I/O 성능	좋음	좋음	나쁨 (항상 전체 데이터 조회)
관리용이성	나쁨	나쁨	좋음

 

 

---

6. 성능향상

• PK/FK 칼럼 순서 조절을 통한 성능 향상
  1. 등호‘=’
  2. BETWEEN<> 조건이 걸리는 칼럼을 맨앞으로 이동
     (여러 조건이 있을 경우 등호 조건이 걸리는 칼럼을 선두로 이동)
• 인덱스 특성을 고려한 PK/FK DB 성능 향상
  • 물리적인 테이블에 FK 제약을 걸어 인덱스를 생성
  • FK제약을 생력하는 경우에도 조인성능을 향상하기 위해 인덱스를 생성해주는 것이 좋다.

 

 

---

2절. 분산 DB 데이터에 따른 성능

1. 분산 DB

분산된 DB를 하나의 가상 시스템으로 사용할 수 있도록 한 DB, 물리적 사이트는 분산되어 있으나 논리적으로 동일한 시스템, 과거에는 위치 중심이었으나 현재는 업무 필요에 따라 분산 설계

 

1-1. 설계 방식

• 상향식: 지역 스키마 작성 후 전역 스키마 작성
• 하향식: 전역 스키마 작성 후 지역사상 스키마 작성

 

1-2. 장점 (신가, 속비, 용량, 자치, 효융, 규모, 요구) ★

• 신뢰성과 가용성 증가
• 빠른 응답 속도와 통신비용 절감
• 점증적 시스템 용량 확장
• 지역 자치성
• 효용성과 융통성
• 시스템 규모의 적절한 조절
• 각 지역 사용자의 요구 수용 증대

 

1-3. 단점

• 관리 및 통제 어려움
• 데이터 무결성 관리 어려움
• S/W 개발 비용 및 처리 비용 증가
• 불규칙한 응답 속도 
• 오류의 잠재성 증대

 

• Global Single Instance(GSI) : 통합된 한 개의 인스턴스, 즉 통합 데이터베이스 구조로 분산DB와는 반대이다.
• 공통코드,기준정보 등 마스터 데이터, 실시간 업무적인 특성을 갖고있을 때, 백업 사이트를 구성할 때 분산 적용

 

 

 

2. 분산 DB의 투명성 (분 위 지 중 장 병행)

• 분할 투명성(단편화) : 하나의 논리적 관계가 분할되어 각 단편의 사본이 여러 사이트에 저장됨
• 위치 투명성 : 사용하려는 데이터 저장 장소가 명시되지 않아도 됨, 위치정보가 시스템 카탈로그에 유지됨
• 지역사상 투명성 : 지역 DBMS와 물리적 DB 사이의 사상(Mapping)이 보장됨
• 중복 투명성 : DB 객체 중복 여부를 몰라도 됨
• 장애 투명성 : 구성요소(DBMS, 컴퓨터)의 장애에 무관하게 트랜잭션의 원자성이 유지됨
• 병행 투명성 : 다수의 트랜잭션을 동시 수행했을 때 결과의 일관성이 유지됨 (병렬 아님)

 

 

 

3. 분산 DB 적용 기법

테이블 위치 분산	테이블 구조 변경 X, 테이블이 다른 DB에 중복으로 생성 X 정보를 이용하는 형태가 각 위치별로 차이가 있는 경우 설계된 테이블의 위치를 분산함
테이블 분할 분산 (Table Fragmentation)	수평 분할	특정 컬럼 값 기준으로 로우 단위 분리 (칼럼은 분리X, PK에 의한 중복발생X) 타 지사에 있는 데이터 수정X, (무결성)자신 데이터만 수정함. 데이터가 지사별로 존재하므로 중복 발생X DB가 속한 서버가 지사에 존재하던 본사에 존재하던 DB 테이블들은 수평분할하여 조재
	수직 분할	칼럼 단위로 분리. 각 테이블은 동일한 기본키 구조와 값을 갖고있어야함 데이터를 한군데 집합시켜 놓아도 동일한 기본키는 하나로 표현하면 되므로 데이터 중복 발생X 테이블 전체 칼럼 데이터 조회. (실제 프로젝트에서 수직분할하는 사례는 드물다.)
테이블 복제 분산 (Table Replication)	동일한 테이블을 다른 지역이나 서버에서 동시 생성함 원격지 조인을 내부 조인으로 변경하여 성능 향상
	부분 복제	마스터 데이터는 테이블의 일부 내용만 다른 지역이나 서버에 위치 (공통코드, 기준정보) 본사엔 통합된 데이터, 각 지사별로는 지사에 해당하는 로우를 갖고있음 (본사= 지사 데이터들 합)
	광역 복제	통합된 테이블을 본사에 가지고 있으며 각 지사에 본사와 동일한 데이터 분배 본사나 지사나 데이터처리에 특별한 제약X, 다른 지역간 데이터 복제는 실시간 처리보다 배치처리 이용
테이블 요약 분산 (Table Summarization)	분석 요약	각 지사별로 존재하는 요약정보를 본사에서 통합하여 다시 전체 요약정보 산출 동일한 테이블 구조를 가지고 있으면서 분산되어 있는 동일한 내용의 데이터를 이용 테이블에 있는 모든 칼럼과 로우가 지사에도 동일하게 존재 모든 지사의 데이터를 이용하면 성능이 지연되고 각 지사 서버에 부하, 업무장애 발생
	통합 요약	각 지사별로 존재하는 별 다른 내용 정보를 본사에서 통합하여 전체 요약정보 산출 분석요약과 비슷하나 단지 지사에서 산출한 요약정보를 한군데 취합하여 보여주는 형태.