데이터 모델링과 성능

참고 :

https://yganalyst.github.io/sql/SQL_5/

https://2030bigdata.tistory.com/206

https://dataonair.or.kr/db-tech-reference/d-guide/da-guide/?mod=document&uid=289

모델링의 순서

1) 정규화

2) 용량산정

3) 트랜잭션 유형 파악

4) 반정규화

5) 조정(PK,슈퍼타입,서브타입 조정)

6) 데이터 모델 검증

정규화

정규화는 데이터의 일관성, 최소한의 데이터 중복, 최소한의 데이터 유연성을 위한 방법이며 데이터를 분해하는 과정.

정규화는 왜 하는걸까 ?

• **데이터베이스의 변경시 이상 현상 제거 ( 삭제/삽입/갱신 이상 )**
• 불필요한 데이터를 입력하지 않아도 되기 때문에 중복 데이터가 제거된다. ( 저장 공간 최소화 )
• **데이터베이스 구조 확장시 재 디자인 최소화 ( 자료구조의 안정성 최대화 )**
  • 정규화된 데이터베이스 구조에서는 새로운 데이터 형의 추가로 인한 확장시, 그 구조를 변경하지 않아도 되거나 일부만 변경해도 되는 경우가 있다. 이는 이 데이터베이스와 연동된 응용 프로그램에 최소한의 영향만을 주며, 응용 프로그램의 생명을 연장시킨다.
• **사용자에게 데이터 모델을 더욱 의미있게**
  • 정규화된 테이블들과 정규화된 테이블들간의 관계들은 현실세계에서의 개념들과 그들간의 관계들을 반영한다. 즉 데이터 모델을 사용자에게 더욱 의미(informative)있게 한다. 마치 DDD의 도메인처럼..?
• 다양한 관점에서의 쿼리 지원 ( 효과적인 검색 알고리즘 )

정규화와 성능

정규화와 성능

정규화 종류

1차 정규화 : 속성이 원자값(Atomic Value)을 갖도록 함. “기본키” 보유.

• 같은 성격과 내용의 속성이 중복될 때,
• 중복 값은 제거
• 새로운 테이블 추가 (PK 추가)
• (기존 테이블과) 1:M 관계 형성
• 예제 : ‘기능분류코드’ 속성 차원에서, 같은 속성인데 칼럼 단위로 반복되고 있다.

• 1차 정규화 대상으로, 새 테이블을 추가하여 오른쪽과 같이 수정
  • (모델, 모델 유형기능분류 테이블은 각각 1:M 관계)
• 예제 :

• 일재고와 일재고 상세를 구분함으로써, 일재고에 발생되는 트랜잭션의 성능저하를 예방할 수 있게 되었다.

2차 정규화 : 기본키가 2개 이상의 속성일 때. “부분 함수 종속성 제거”

• PK(Primary Key)가 2개 이상일 때,종속되는 관계가 있다면 분리한다.
• 함수적 종속성(FD) : 데이터들이 어떠한 기준에 의해서 종속되는 것을 의미
  • 완전 함수 종속적 : 기본키에 대해서 그 속성이 완전히 종속될 때
  • 부분 함수적 종속 : 기본키 전체가 아니라, 일부에 대해 종속될 때
• 예시 : 기본키 ‘관서번호’, ‘납부자번호’가 2개 이상이므로, 이를 복합키라고 한다.복합키 일부분에 종속되는 속성이 있으므로, 이를 구분하여 분리해준다.

• 관서번호/ 관서번호,납부자번호로 분리하여, “2차 정규화”를 진행해주었다.
• 예시 : 미리 지정된 함수 종속성에 따라, 2차 정규화를 진행하여 분리해주었다.

• 예시 : 물건을 매각할 때 매각일자를 정하고 그 일자에 해당하는 매각시간과 매각장소가 결정하는 속성의 성격, 즉, 매각일자가 결정자가 되고 매각시간과 매각장소가 의존자가 되는 함수적 종속관계가 형성되는 관계 (매각일자가 같으면, 매각시간과 장소도 같다는 얘기)

• 2차 정규화를 적용하여 매각일자를 PK로 하고 매각시간과 매각장소는 일반속성으로 하는 매각기일 테이블 생성
• 매각내역을 조회할때 읽어야 하는 테이블이 항상 100만건에서 5천건으로 변경되어 조회 성능이 빨라짐
• 즉, 매각기일과 일자별매각물건은 1:M 관계

3차 정규화 : 이진적 함수 종속 관계

• 기본 키에 의존하지 않고, 일반 컬럼에 의존하는 컬럼이 있다면 이를 제거한다.
• 예시 :

• 직원 테이블에 기본 키인 ‘사원번호’ 외에 의존하는 컬럼이 있다.
• 부서코드와 부서이름은 ‘부서’ 테이블에 속해야 할 사항이다.
• → 데이터가 중복되어, 저장 공간이 낭비되고 있다.

정규화 vs 정규형

• 정규화 : 데이터 분해 과정, 이상현상 제거
• 정규형 : 정규화로 도출된 데이터 모델이 갖춰야 할 특성

용량산정

성능 데이터 모델링 수행 시 용량산정은 전체적인 DB에서 발생되는 트랜잭션의 유형과 양을 분석하는 자료가 됨

• 정확한 데이터 용량 산정시 디스크 사용 효율을 높일 수 있음
• 업무량이 집중된 디스크를 분리,설계하여 디스크 I/O[입출력] 부하를 분산시킬 수 있음

반정규화

반정규화 : 정규화된 엔터티, 속성, 관계에 대해 시스템의 성능향상과 개발(Development)과 운영(Maintenance)의 단순화를 위해 중복, 통합, 분리 등을 수행하는 데이터 모델링의 기법

• 데이터를 조회할 때 디스크 I/O량이 많아서 성능이 저하되거나 경로가 너무 멀어 조인으로 인한 성능저하가 예상되거나 컬럼을 계산하여 읽을 때 성능이 저하될 것이 예상되는 경우 수행
• ex) 정규화가 되어서 다 분리되있으면, 조회하기 위해 Join하고 해야하는데, 이걸 그냥 중복된 값으로 다시 반정규화해서 조회성능을 올림
• 데이터 무결성이 깨질 가능성이 많음

반정규화 절차

1. 반정규화 대상조사
   • 자주 사용되는 테이블에 접근(Access)하는 프로세스의 수가 많고 항상 일정한 범위만을 조회하는 경우
   • 테이블에 대량의 데이터가 있고 대량의 데이터 범위를 자주 처리하는 경우에 처리범위를 일정하게 줄이지 않으면 성능을 보장할 수 없을 경우
   • 통계성 프로세스에 의해 통계 정보를 필요로 할 때 별도의 통계테이블(반정규화 테이블)을 생성
   • 테이블에 지나치게 많은 조인(JOIN)이 걸려 데이터를 조회는 작업이 기술적으로 어려울 경우
2. 다른 방법 유도 검토
   • 뷰(VIEW) 사용 : 지나치게 많은 조인(JOIN)이 걸려 데이터를 조회하는 작업이 기술적으로 어려울 경우, 조회의 성능을 향상시키진 않음.
     • 뷰(view)의 장점
       • 원하는 부분만 가져와서 사용할 수 있다.
       • 복잡한 쿼리를 단순화해서 사용 가능하다.
       • 데이터의 보안이 용이하다.
       • 사용자가 데이터를 관리하기가 쉽다.
       • 논리적 독립성을 제공한다.
     • 뷰(view)의 단점
       • 인덱스를 구성할 수 없다.
       • 한번 정의된 뷰는 수정이 불가하다.
       • 삽입, 갱신, 삭제 연산에 많은 제약이 있다.
   • 클러스터링 : 대량의 데이터처리나 부분처리에 의해 성능이 저하되는 경우에 클러스터링을 적용하거나 인덱스를 조정함으로써 성능을 향상
     

    - Active-Active 방식과 Active-StandBy 방식이 있다.
    - [그림 1]과 같이 모든 DB 서버가 Active 상태면 하나의 서버에 이상이 생기더라도 바로 다른 서버를 이용해 정상적인 서비스 운영이 가능하다.
     
    또한 클러스터링을 이용하게 되면 기존에 하나의 서버에 몰리던 부하를 여러 곳으로 분산시킬 수 있다. 즉, 로드밸런싱(Load Balancing)이 가능해진다.
    - 클러스터링은 여러 대의 서버가 데이터베이스를 공유하므로 병목현상이 발생해 더 많은 비용이 발생할 수 있다. 특히, Active-Active 방식은 모든 서버가 활성화된 상태이므로 병목 현상이 더 심하게 발생할 수 있다. 이러한 단점을 완화시킬 수 있는 방식이 바로 Active-StandBy 방식이다.
    - 하지만, 장애가 발생했을 경우 Stand-By 상태에서 Active 상태로 전환하는 시간동안 서비스를 사용할 수 없다는 단점도 존재한다. 또한, Active-Active는 여러 대의 서버를 온전히 사용하여 부하를 줄일 수 있는 장점이 있지만, Active-StandBy 방식은 부하 분산 기능의 효율이 줄어드는 단점이 있다.
- 파티셔닝 : 대량의 데이터는 Primary Key의 성격에 따라 부분적인 테이블로 분리(Partitioning)할 수 있음, 파티셔닝 Key에 의해 물리적인 저장공간이 구분
- 캐쉬 : 응용 애플리케이션에서 로직을 구사하는 방법을 변경

3. 반정규화 적용

반정규화 기법

• 테이블 반정규화

• 컬럼 반정규화

• 관계 반정규화

대량 데이터에 따른 성능

하나의 테이블에 대량의 데이터 발생시 문제점

• 아무리 설계가 잘된 데이터 모델이라도 하나의 테이블 및 하드웨어 공간에 대량의 데이터가 집약되어 있으면 성능 저하 발생 → 하나의 테이블에 대량의 데이터가 존재하면 인덱스의 Tree구조가 너무 커져 효율성이 떨어져 데이터를 처리[입력, 조회, 수정, 삭제]할 때 디스크 I/O를 많이 유발
• SQL문장에서 데이터 처리를 위한 I/O의 양이 증가 → 컬럼이 많아지면 하나의 데이터를 물리적인 디스크의 여러 블록에 저장해야됨 → 데이터 처리시, 여러 블록에서 데이터를 I/O해야 해 SQL문장의 성능이 저하

컬럼이 많아짐에 따라 성능이 저하되는 유형

로우 체이닝[ROW CHAINING]	로우 마이그레이션[ROW MIGRATION]
로우 길이가 너무 길어서 하나의 데이터 블록에 저장되지 않고 두 개 이상의 데이터 블록에 걸쳐 하나의 로우가 저장되는 현상	데이터 블록에서 수정이 발생하면 늘어나는 저장공간으로 인해 수정된 데이터를 해당 데이터 블록에서 저장하지 못하고 다른 블록의 빈 공간을 찾아 저장하는 방식
ROW 정보 검색을 위해 하나 이상의 데이터 블록을 SCAN해야 하므로 성능이 저하됨	MIGRATION된 ROW를 읽기 전 기존 블록에서 헤더를 통해 MIGRATION된 ROW를 읽으므로 성능이 감소
* 블록 크기를 크게 만듦	* PCTFREE를 크게 설정

• 객체를 EXPORT하고 삭제한후, IMPORT
• 객체를 MIGRATION하고 TRUNCATE |

⇒ 트랜잭션을 분석하여 적절하게 1:1 관계로 분리함으로써 성능향상이 가능하도록 해야함

PCTFREE 20

○ PCTFREE란?

• 사용가능한 Block 공간 중에서 데이터 Row의 Update 등 데이터의 변경에 대비해서 확보해 놓은 BLOCK의 %값입니다.

• PCTFREE의 Default 값은 10%입니다.

• PCTFREE와 PCTUSED의 합이 100을 초과하지 않는 범위내에서 0~99까지 값을 PCTFREE값을 PCTFREE 값으로 사용할 수 있습니다.

테이블에 대한 수평/수직분할의 절차

• 데이터 모델링을 완성
• 데이터베이스 용량산정
• 대량 데이터가 처리되는 테이블에 대해서 트랜잭션 처리 패턴을 분석
• 컬럼 단위로 집중화된 처리가 발생하는지, 로우 단위로 집중화된 처리가 발생되는지 분석하여 집중화된 단위로 테이블을 분리하는 것을 검토

대량 데이터 발생에 따른 테이블 분할

• 대량의 데이터를 가진 테이블에서 트랜잭션이 발생될 때 테이블을 쪼개주면 디스크의 I/O가 감소하여 성능 개선
• 트랜잭션이 독립적으로 발생되는 경우 1:1관계로 분리 → 트랜잭션에 접근하는 컬럼 유형을 분석해 자주 접근하는 칼럼과 상대적으로 접근 빈도가 낮은 컬럼 구분 → 분리된 테이블은 디스크에 이전보다 적은 컬럼이 저장되어 로우체이닝과 로우마이그레이션이 많이 줄어듦
• 데이터가 채워지지 않고 NULL상태로 존재하는 칼럼은 뒤쪽에 모아 로우 길이를 감소시킴 → 추후에 NULL상태의 칼럼에 데이터가 채워질 경우, 더 많은 로우 체이닝이 발생 → 사용빈도에 따라 나눈후 별도의 1:1관계 엔터티로 분리하는 등의 데이터모델 설계 수정을 고려하는 것이 좋다.
• 테이블에 대한 수평/수직 분할은 4가지 원칙을 적용해 결정 1> 데이터 모델링을 완성한다. 2> 데이터 베이스 용량을 산정한다. ※ 용량산정은 어느 테이블에 데이터의 양이 대용량이 되는지 분석하는 것 3> 대량 데이터가 처리되는 테이블에 대해서 트랜잭션 처리 패턴을 분석한다. 4> 칼럼 단위로 집중화된 처리가 발생하는지, 로우 단위로 집중화된 처리가 발생하는지 분석해 집중화된 단위로 테이블을 분리하는 것을 검토
  

수직분할[Vertical Partitioning]

수평분할[Horizontal Partitioning]

레코드 개수가 많아 레코드를 기준으로 테이블을 분할하는 것

• 하나의 테이블에 데이터가 너무 많이 있고, 레코드 중 특정 범위만을 주로 엑세스하는 경우 사용
• 분할된 각 테이블은 서로 다른 디스크에 위치시켜 물리적인 디스크의 효용성을 극대화
• DBMS차원에서의 수평 테이블 분할 방법에는 범위 분할, 해쉬분할, 복합 분할 등이 있음

칼럼의 개수가 많아 칼럼을 기준으로 테이블을 분할한 것

수직 분할이 일어나는 경우조회 위주의 칼럼과 갱신 위주의 칼럼으로 나뉘는 경우 →

테이터 갱신 작업이 일어날 때 잠금[Locking]을 수행하므로 갱신 위주 칼럼들을 분할 →

데이터 무결성을 지키기 위해특별히 자주 조회되는 칼럼이 있는 경우 →

별도의 테이블로 관리하면 조회되는 쿼리 작업의 성능이 향상됨특정 칼럼 크기가 아주 큰 경우 →

텍스트 및 이미지와 같은 LOB[Large Objects] 데이터 형식을 지원특정 칼럼에 보안을 적용해야 하는 경우 →

하나의 테이블 내에서 특정 칼럼들에게 SELECT,UPDATE,DELETE 등의 권한을 부여하지 않음 → 

특정 칼럼에 대해 권한을 부여하기 위해 별도의 테이블 생성

파티션 기법[파티셔닝, Partitioning]

하나의 테이블에 많은 양의 데이터가 예상될 경우, 파티션을 사용해 테이블을 분할하는 기법

• 파티션을 사용하면 논리적으로는 하나의 테이블이지만 물리적으로는 여러 개의 데이터 파일에 분산되어 저장됨 → 데이터 액세스 성능 향상, 데이터 관리 방법 개선 등의 장점이 있음 → 하나의 테이블에 많은 양의 데이터가 저장되어 인덱스 추가, 테이블 분할 등을 해도 성능 저하될 때 사용

Range Partition	데이터 값의 범위를 기준으로 파티션을 수행
List Partition	특정한 값을 지정하여 파티션을 수행
Hash Partition	해시 함수를 적용해 파티션을 수행    → DBMS에서 스스로 분할하고 관리
Composite Partition	범위[Range Partition]와 해시[Hash Partition]를 복합적으로 사용해 파티션을 수행

• Range Partition
  • 컬럼값의 범위를 기준으로 행을 분할.
  • 달/분기 등의 logical한 범위의 분산에 주로 사용 ( 범위가 예측가능할 때 효과적 )
  • 대상 테이블이 날짜 또는 숫자값으로 분리가 가능하고 각 영역별로 트랜잭션이 분리되는 경우
  • ex) 요금 테이블 → 요금_0401, 요금_0402, etc.
  • https://yadw.tistory.com/52
• Hash Partition
  • Partitioning Key에 해시 함수를 적용해 데이터를 분할하는 방식.
  • Range Partition으로 만들기 힘든 사항. 즉 조건을 주기 힘든 경우, 각 파티션이 고르게 나누어지지 않는 경우에 사용
  • 보관 주기 관리가 불가능한 문제가 있다.
  • 지정된 HASH 조건에 따라 해슁 알고리즘이 적용되어 테이블이 분리됨
  • 스토리지의 특정 위치에 I/O 가 몰리는 현상을 핫블럭(Hot Block) 현상이라고 하는데, 이때 Reverse Index 와 함께 Hash Partition 이 해결책이 될 수 있습니다.
  • https://jack-of-all-trades.tistory.com/67
• List Partition
  • 특정 컬럼의 특정 값으로 파티셔닝하는 방법.
  • 연관되지 않은, 순서에 맞지 않는 데이터의 그룹핑에 용이함.
  • 값 별로 분포도가 비슷하고 많은 SQL에서 해당 컬럼의 조건이 빈번하게 들어오는 경우 유용함.
  • 지점, 사업소, 사업장, 핵심적인 코드값 등으로 PK가 구성되어 있고 대량의 데이터가 있는 테이블이라면 값 각각에 의해 파티셔닝
  • ex) 고객 테이블 → 고객서울, 고객경기, etc.
  • https://yadw.tistory.com/54

# Range Partition

• 요금과 관련된 1억 2천만 건의 대용량 데이터를 처리하기 위해 월별로 12개의 파티션 테이블 생성 → 요금 특성상 월단위 데이터 처리를 하는 경우가 많으므로
• 월별로 데이터를 저장하므로 데이터 보관주기에 따라 쉽게 삭제 가능

# LIST PARTITION

지점, 사업장 코드값 등으로 PK가 구성된 테이블에서 대량의 데이터 처리시에는 LIST PARTITION 적용

• 고객 관련 1억건의 대용량 데이터를 처리하기 위해 지역을 나타내는 사업소코드별로 LIST PARTITION 적용
• 대용량 데이터를 특정값에 따라 분리 저장 가능
• RANGE PARTITION과 같이 데이터 보관주기에 따라 쉽게 삭제하는 기능은 제공하지 않음

파티션 인덱스[Partition Index]

Global Index	여러 개의 파티션에서 하나의 인덱스를 사용
Local Index	해당 파티션 별로 각자의 인덱스를 사용
Prefixed Index	파티션 키와 인덱스 키가 동일
Non Prefixed Index	파티션 키와 인덱스 키가 다름

트랜잭션 유형 파악

트랜잭션 분석

트랜잭션 분석의 목적은 CRUD 매트릭스를 기반으로 테이블에 발생하는 트랜잭션 양을 분석하여 테이블에 저장되는 데이터의 양을 유추하고 이를 근거로 DB 용량을 산정하고 DB 구조를 최적화하는 것이다.

• 트랜잭션 분석은 업무 개발 담당자가 수행
• 트랜잭션 분석을 통해 프로세스가 과도하게 접근하는 테이블을 확인하여 여러 디스크에 배치함으로써 디스크 입출력 분산을 통한 성능 향상을 가져올 수 있음

트랜잭션 분석서

트랜잭션 분석서는 단위 프로세스와 CRUD 매트릭스를 이용하여 작성하며, 구성 요소에는 단위 프로세스, CRUD 연산, 테이블명, 컬럼명, 등이 있다.

• 단위 프로세스 : 업무를 발생시키는 가장 작은 단위의 프로세스
• CRUD 연산 : 프로세스의 트랜잭션이나 데이터베이스 테이블에 영향을 주는 C, R, U, D의 4가지 연산
• 테이블명, 컬럼명 : 프로세스가 접근하는 데이터베이스의 테이블명을 기록. 필요한 경우 테이블의 컬럼명을 적음. 컬럼명을 적을 때는 마침표로 연결하여 '테이블.컬럼명'과 같이 적음
• 테이블 참조 횟수 : 프로세스가 테이블을 참조하는 횟수
• 트랜잭션 수 : 주기별로 수행되는 트랜잭션 횟수
• 발생 주기 : 연, 분기, 월, 일, 시간 등 트랜잭션 횟수를 측정하기 위한 발생 주기

조정(PK/FK,슈퍼타입/서브타입 조정)

인덱스 특성을 고려한 PK/FK 칼럼 순서

• PK/FK설계 시, 성능을 고려한 데이터베이스 설계가 될 수 있도록 설계단계 마지막에 칼럼의 순서를 조정
• 일반적으로 프로젝트에서는 PK/FK 칼럼 순서의 중요성을 잘 인지하지 못함 → 데이터 모델링이 되어 있는 그대로 DDL을 생성할 경우, 데이터베이스 데이터처리 성능에 문제를 유발
• PK순서는 실전 프로젝트에서 매우 중요 → 특히 물리적인 데이터 모델링 단계에서는 스스로 생성된 PK순서 이외에 다른 엔터티로부터 상속받아 발생되는 PK순서까지 항상 주의하여 표시해야 함. → 해당 해당테이블의 데이터를 접근할 가장 빈번하게 사용되는 유일한 인덱스(Unique Index)를 모두 자동 생성 → 인덱스 정렬구조를 이해한 상태에서 인덱스를 효율적으로 이용할 수 있도록 PK순서를 지정 → 여러 개의 속성이 하나의 인덱스로 구성되어 있을 때, 앞쪽에 위치한 속성 값이 가급적 ‘=’ 아니면 최소한 범위 ‘BETWEEN’ ‘< >’가 들어와야 인덱스 이용 가능
• 데이터 모델링 때 결정한 PK순서와 다르게 DDL문장을 통해 PK순서를 다르게 생성가능 → 대부분의 프로젝트에서는 데이터 모델의 PK 순서에 따라 그대로 PK를 생성 → 만약 다르게 생성할 경우, 데이터 모델과 데이터베이스 테이블의 구조가 다른 것처럼 보여 유지보수가 어려움
• FK는 데이터 조회시 조인의 경로를 제공하는 역할 수행 → FK는 반드시 인덱스 설정 → FK는 조회의 조건을 고려하여 접근이 가장 효율적인 칼럼 순서대로 인덱스를 생성

슈퍼/서브타입 모델

논리적인 데이터 모델에서 이용되는 형태로 분석 단계에서 많이 쓰이는 모델

• 최근에 데이터 모델링할 때 자주 쓰이는 모델링 방법으로 Extended ER모델이라고도 함
• 업무를 구성하는 데이터를 공통점과 차이점의 특징을 고려해 효과적으로 표현 가능하여 자주 사용 → 공통 부분을 슈퍼타입으로 모델링, 차이나는 부분을 서브타입으로 구분해 표현
• Super type와 Sub type 간의 관계는 베타적 관계와 포괄적 관계가 있음  ex> 고객 엔터티가 개인고객과 법인 고객으로 분류되는 경우 Super type : 고객 엔터티 Sub type : 개인고객, 법인고객 베타적 관계 : 고객이 개인 고객이거나 법인고객인 경우 포괄적 관계 : 고객이 개인 고객일 수도 있고 법인 고객일 수도 있는 경우

슈퍼/서브타임 데이터 모델의 변환

OneToOne Type	Super Type과 Sub Type을 개별 테이블로 도출개별로 발생되는 트랜잭션에 대해서는 개별 테이블로 구성슈퍼타입이 각 서브탕비에 대해 기준역할을 하는 형식으로 사용할때 이러한 유형의 트랜잭션 발생테이블 수가 많아서 조인이 많이 발생하고 관리가 어려움
Plus Type	Super Type과 Sub Type 테이블로 도출슈터+서브 타입에 대해 발생되는 트랜잭션에 대해서는 슈퍼+서브 타입 테이블로 구성조인이 발생하고 관리가 어려움
Single Type	Super Type과 Sub Type을 하나의 테이블로 도출테이블들을 하나로 묶었을 때 각각의 속성별로 제약사항(NULL/NOT NULL, 기본값, 체크값)을 정확하게 지정하지 못할지라도 대용량이고 성능향상이 필요하다면 하나의 테이블로 묶어서 만들어 줌.조인 성능이 좋고 관리가 편리하지만 입출력 성능이 나쁨

• 슈퍼/서브타입에 대한 변환을 잘못하여 성능이 저하되는 경우[트랜잭션 특성을 고려하지 않고 테이블 설계]
  1. 트랜잭션이 항상 전체를 일괄 처리할 때, 테이블은 서브타입렬로 개별 유지되어 변환하면 Union연산에 의해 성능이 저하될 수 있음
  2. 트랜잭션이 항상 서브타입 개별로 처리할 때, 테이블은 하나로 통합하여 변환하면 불필요하게 많은 양의 데이터가 집접되어 있어 성능이 저하될 수 있음
  3. 트랜잭션은 항상 Super type과 Sub type을 함께 처리하는데 개별로 유지하면 조인에 의해 성능이 저하됨
• 성능이 중요한 트랜잭션이 빈번하게 처리되는 기준에 따라 테이블을 설계해야 성능저하현상을 예방
• 데이터 양이 소량일 경우 성능에 영향을 미치지 않으므로 데이터 처리의 유연성을 고려해 가급적 1:1관계를 유지

[개미의 걸음 SQLD 1과목] 성능 데이터 모델링 ④ PK/FK 칼럼순서&슈퍼타입/서브타입 모델

데이터 모델 검증

논리 데이터 모델 품질 검토

분산 DB 데이터에 따른 성능

1. 분산 데이터베이스의 개요

• 여러 곳으로 분산되어있는 데이터베이스를 하나의 가상 시스템으로 사용할 수 있도록 한 데이터베이스이다.
• 논리적으로 동일한 시스템에 속하나 , 네트워크를 통해 물리적으로 분산되어 있는 데이터들의 모임이다.

즉 분산 데이터베이스는,

데이터베이스를 연결하는 빠른 네트워크 환경을 이용하여 데이터베이스를 여러 지역 여러 노드로 위치시켜 사용성/성능 등을 극대화 시킨 데이터베이스이다.

---

2. 분산 데이터베이스의 투명성(Transparency)

분산 데이터베이스는 다음과 같은 6개의 투명성을 가져야 한다.

1. 분할 투명성(단편화)

하나의 논리적 Relation 이 여러 단편으로 분할되어 각 단편의 사본이 여러 site 에 저장

2. 위치 투명성

사용하려는 데이터 저장 명소 명시 불필요.

위치 정보가 System Catelog 에 유지되어야 함

3. 지역사상 투명성

지역 DBMS 와 물리적 DB 사이의 Mapping 보장.

각 지역시스템 이름과 무관한 이름 사용 가능

4. 중복 투명성

DB 객체가 여러 site 에 중복 되어 있는지 알 필요가 없는 성질

데이터베이스 객체가 여러 시스템에 중복되어 존재함에도 고객과는 무관하게 유지되는 데이터의 일관성

5. 장애 투명성

구성요소 (DBMS, Computer) 의 장애에 무관한 Transaction 의 원자성(무결성) 유지

6. 병행 투명성

다수 Transaction 동시 수행시 결과의 일관성 유지

여러 고객의 응용 프로그램이 동시에 분산 데이터베이스에 대한 트랜잭션을 수행하는 경우에도 이상없는 결과

Time Stamp, 분산 2 단계 Locking 을 이용 구현

3. 분산 데이터베이스의 적용 방법

• 업무의 흐름에 따른 아키텍쳐 특징으로 데이터베이스를 구성한다
• 즉, 업무 특징에 따라 데이터베이스 분산 구조를 선택적으로 설계할 수 있고 그 능력이 필요하다

4. 분산 데이터베이스의 장단점

5. 데이터베이스 분산구성의 가치

데이터를 분산환경으로 구성하였을 때 가장 핵심적인 가치는

"통합된 데이터베이스에서 제공할 수 없는 빠른 성능을 제공한다는 점이다."

---

6. 분산 데이터베이스의 적용 기법

1. 테이블 위치 분산

설계된 테이블의 위치를 각각 다르게 위치시키는 것이다.

테이블 구조는 변하지 않는다.

다른 데이터베이스에 중복되어 생성되지도 않는다.

정보를 이용하는 형태가 각 위치별로 차이가 있을 경우 사용한다.

테이블의 위치가 서로 다르기 때문에 테이블의 위치를 파악할 수 있는 도식화된 위치별 데이터베이스 문서가 필요하다.

2. 테이블 분할 분산

단순히 테이블의 위치만 다른곳에 두는 것이 아니라 , 각 각 의 테이블을 쪼개어 분산

수평분할(row 기준) , 수직분할(컬럼기준) 등이 있다.

3. 테이블 복제 분산

동일한 테이블을 다른 지역이나 서버에 동시에 생성하여 관리하는 유형

4. 테이블 요약 분산

7. 분산 데이터베이스를 적용하여 성능이 향상된 사례

• 성능이 중요한 사이트에 적용한다.
• 공통코드, 기준정보, 마스터 데이터 등에 대한 분산환경을 구성하면 성능이 좋아진다.
• 실시간 동기화가 요구되지 않을 때 좋다, 그러나 실시간의 업무적인 특징을 가지고있어도 분산환경 구축 가능하다
• 특정 서버에 부하가 집중될 때 부하를 분산 할 수 있다
• 백업사이트를 구성할 때 적용한다.