[SQLD] 요점정리 1- 2장 데이터 모델과 성능

- 성능데이터 모델링의 정의

  성능데이터 모델링이란 데이터베이스 성능향상을 목적으로 설계단계의 데이터 모델링 때부터 정규화, 비정규화, 테이블통합, 테이블분할, 조인구조, PK, FK 등 여러가지 성능과 관련된 사항이 데이터 모델링에 반영 될 수 있도록 하는 것이다. 

 

  성능이 저하되는 데이터 모델의 경우 첫번째, 데이터 모델구조에 의해 성능이 저하될 수도 있고 두번째, 데이터가 대용량이 됨으로써 불가피하게 저하될 수도 있음. 세번째, 인텍스 특성을 충분히 고려하지못하고 생성하여 성능저하되는 경우도 있음

 

- 성능 데이터 모델링 수행시점

  성능을 분석/설계 단계에서부터 성능에 대한 데이터 설계를 하지 않으면 시간이 지날수록 성능개선의 비용이 증가함.

 

- 성능 데이터 모델링 고려사항

  1. 데이터 모델링을 할 때 정규화를 정확하게 수행한다.

  2. 데이터베이스 용량산정을 수행한다.

  3. 데이터베이스에 발생되는 트랜잭션의 유형을 파악한다.

  4. 용량과 트랜잭션의 유형에 따라 반정규화를 수행한다.

  5. 이력모델의 조정, PK/FK의 조정, 슈퍼타입/서브타입 조정등을 수행한다.

  6. 성능관점에서 데이터 모델을 검증한다.

 

- 정규화를 통한 성능 향상 전략

  데이터 모델링을 하면서 정규화를 하는 것은 기본적으로 데이터에 대한 중복성을 제거하여 주고 데이터가 관심사별로 처리되는 경우가 많기 때문에 성능이 향상되는 특징을 가지고 있음

  정규화를 수행한다는 것은 데이터를 결정하는 결정자에 의해 함수적 종속을 가지고 있는 일반속성을 의존자로 하여 입력/수정/삭제 이상을 제거하는 것

  일반적으로 정규화를 수행해야 데이터 처리의 성능이 향상되며 데이터의 조회처리 트랜잭션시에 성능저하가 나타날 수 있음 

  일반적으로 정규화가 잘되어 있으면 입력/수정/삭제의 성능이 향상되고 반정규화를 많이 하면 조회의 성능이 향상된다고 인식 됨

 

[정규형 정리]

1차 정규형	모든 속성은 반드시 하나의 값을 가진다. 즉, 반복형태가 있어서는 안된다. -> 속성값의 중복제거
2차 정규형	식별자가 아닌 모든 속성들은 식별자 전체 속성에 완전 종속되어야 한다. -> 식별자에 종속되지 않는 속성의 중복제거
3차 정규형	2차 정규형을 만족하고 식별자를 제외한 나머지 속성들 간의 종속이 존재하면 안된다. 나머지 속성들간의 종속적 관계가 있으면 3차정규화 대상임

 

  - 반정규화된 테이블의 성능저하 사례1

    하나의 테이블을 부분키 종속을 정규화하여 두개의 테이블로 분리해 2차 정규화 시켰을 때 두개의 테이블을 조인해서 처리 

   아래의 경우 왼쪽테이블은 불필요하게 납부자 번호만큼 누적된 데이터를 읽어서 결과를 구분하여 보여주고 오른쪽테이블은 관서수만큼만 존재하는 데이터를 읽어 처리하기 때문에 2차정규화를 한 테이블이 훨씬 빠르다.

출처 : sqld 전문가가이드

  - 반정규화된 테이블의 성능저하 사례2

  두 개의 엔터티가 통합되어 반정규화 된 경우

  특정 매각장소에 대해 매각일자를 찾아 매각내역을 조회하려면 100만건의 데이터를 읽어 매각일자를 distinct 하여

  매각일자별 매각내역과 JOIN

  복합식별자 중에서 일반속성이 주식별자 속성 중 일부에만 종속관계를 가지고 있으므로 2차 정규화 대상이 된다.

  2차 정규화를 적용하여 매각일자를 pk로 하고 특정매각내역을 조회하려면 5천건의 매각기일과 매각일자별매각내역이

  JOIN되어 성능 향상

  - 반정규화된 테이블의 성능저하 사례3

   동일한 속성 형식을 두개 이상의 속성으로 나열하여 반정규화 한 경우

   아래의 경우 인덱스를 생성하려면 9개나 되는 인덱스를 추가해야 함

  중복 속성에 대한 분리가 필요하므로 1차 정규화를 적용

  - 반정규화된 테이블의 성능저하 사례4

- 함수적 종속성에 근거한 정규화 수행 필요

   함수의 종속성(Functional Dependency) : 데이터들이 어떤 기준값에 의해 종속되는 형상

   기준값- 결정자(Determinant) , 종속되는 값 - 종속자(Dependent)

   함수의 종속성은 데이터가 가지고 있는 근본적이 속성으로 인식되어짐

   ex) 이름,출생지, 주소는 주민등록번호에 함수 종속성을 가지고 있음

   기본적으로 데이터는 속성간의 함수종속성에 근거하여 정규화 되어야한다. 

   프로젝트 수행에서 정규화는 선택사항이 아니라 필수 사항이다. 

 

- 반정규화를 통한 성능 향상 전략

 1) 반정규화의 정의 

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

 

 2) 반정규화의 적용방법

  반정규화를 적용할 때는 기본적으로 데이터 무결성이 깨질 가능성이 많이 있기 때문에 반드시 데이터 무결성을 보장할 수 있는 방법을 고려한 이후에 반정규화를 적용하도록 해야 한다. 

  · 반정규화의 대상을 조사한다.

    데이터가 대량이고 성능이 저하될 것으로 예상이 되면 다음 4가지 경우를 고려하여 반정규화를 고려하게 된다.

     1. 자주 사용되는 테이블에 접근(Access)하는 프로세스의 수가 많고 항상 일정한 범위만을 조회하는 경우에 반정규화

        를 검토한다.

     2. 테이블에 대량의 데이터가 있고 대량의 데이터 범위를 자주 처리하는 경우에 처리범위를 일정하게 줄이지 않으면

        성능을 보장할 수 없을 경우에 반정규화를 검토한다.

     3. 통계성 프로세스에 의해 통계 정보를 필요로 할 때 별도의 통계테이블(반정규화 테이블)을 생성한다.

     4.  테이블에 지나치게 많은 조인(JOIN)이 걸려 데이터를 조회하는 작업이 기술적으로 어려울 경우 반정규화를 검토

        한다.

   ·  반정규화의 대상에 대해 다른 방법으로 처리 할 수 있는지 검토한다.

     1. 지나치게 많은 조인(JOIN)이 걸려 데이터를 조회하는 작업이 기술적으로 어려울 경우 뷰(VIEW)를 사용하면

        이를 해결할 수도 있다.

     2. 대량의 데이터처리나 부분처리에 의해 성능이 저하되는 경우에 클러스터링을 적용하거나 인덱스를 조정함으로써

        성능을 향상시킬 수 있다.

     3. 대량의 데이터는 Primary Key 의 성격에 따라 부분적인 테이블로 분리할 수 있다. 즉 파티셔닝 기법(Partitioning)

       이 적용되어 성능저하를 방지할 수 있다.

     4. 응용 애플리케이션에서 로직을 구사하는 방법을 변경함으로써 성능을 향상시킬 수 있다. 

   · 반정규화를 적용한다.

 

- 반정규화의 기법

   1)테이블 반정규화

기법분류	기법	내용
테이블 병합	1:1 관계 테이블 병합	1: 1 관계를 통합하여 성능향상
	1:M 관계 테이블 병합	1: M 관계를 통합하여 성능향상
	슈퍼 / 서브타입 테이블 병합	슈퍼/서브 관계를 통합하여 성능향상
테이블 분할	수직분할	컬럼단위의 테이블을 디스크 I/O를 분산처리 하기 위해 테이블을 1:1로 분리하여 성능향상(트랜잭션의 처리되는 유형파악이 선행)
	수평분할	로우 단위의 집중 발생되는 트랜잭션을 분석하여 디스크 I/O 및 데이터 접근의 효율성을 높여 성능을 향상하기 위해 로우단위로 테이블을 쪼갬
테이블추가	중복테이블 추가	다른 업무이거나 서버가 다른 경우 동일한 테이블구조를 중복하여 원격조인을 제거하여 성능을 향상
	통계테이블 추가	SUM,AVG 등을 미리 수행하여 계산해 둠으로써 조회 시 성능을 향상
	이력테이블 추가	이력테이블 중에는 마스터 테이블에 존재하는 레코드를 중복하여 이력테이블에 존재하는 방법은 반정규화의 유형
	부분테이블 추가	하나의 테이블의 전체 칼럼 중 자주 이용하는 집중회된 칼럼들이 있을때 디스크 I/O 를 줄이기 위해 해당 칼럼들을 모아놓은 별도의 반정규화 된 테이블을 생성

   2)칼럼 반정규화

반정규화 기법	내용
중복칼럼 추가	조인에 의해 처리할 때 성능저하를 예방하기 위해 즉, 조인을 감소시키기 위해 중복된 칼럼을 위치시킴
파생칼럼 추가	트랜잭션이 처리되는 시점에 계산에 의해 발생되는 성능저하를 에방하기 위해 미리 값을 계산하여 칼럼에 보관함 , Derived Column
이력테이블 컬럼 추가	대량의 이력데이터를 처리 할때 불특정 날 조회나 최근값을 조회할 때 나타날 수 있는 성능저하를 에방하기 위해 이력테이블에 기능성 컬럼(최근값 여부, 시작과 종료일자 등)을 추가
PK에 의한 칼럼 추가	복합의미를 갖는 PK를 단일속성으로 구성하였을 경우발생됨, 단일 PK안에서 특정값을 별도로 조회하는 경우 성능저하가 발생될 수있음,  이때 이미 PK안에 데이터가 존재하지만 성능향상을 위해 일반속성으로 포함하는 방법이 PK에 의한 컬럼추가 반정규화임
응용시스템 오작동을 위한 칼럼 추가	사용자가 데이터처리를 하다가 잘못 처리하여 원래값으로 복구하기를 원하는 경우 이전 데이터를 임시적으로 중복하여 보관하는 기법, 컬럼으로 이것을 보관하는것은 임시적기법

   3)관계 반정규화

반정규화 기법	내용
중복관계 추가	데이터를 처리하기 위한 여러경로를 거쳐 조인이 가능하지만 이 때 발생할 수 있는 성능저하를 예방하기 위하여 추가적인 관계를 맺는 방법

 

테이블과 칼럼의 반정규화는 데이터 무결성에 영향을 미치게 되나 관계의 반정규화는 데이터 무결성을 깨뜨릴 위험을 갖지 않고서도 데이터 처리의 성능을 향상 시킬 수 있는 반정규화 기법이 된다. 

 

 

- 정규화가 잘 정의된 데이터 모델에서 성능이 저하된 경우

  1)

공금자와 전화번호, 메일주소, 위치는 1:M 관계이므로 한명의 공급자당 여러개의 전화번호, 메일주소, 위치가 존재하므로 최근에 변경된 값을 가져오려면 각 테이블에서 MAX값을 가져와서 조인해야하므로 복잡한 SQL문을 작성

이때 반정규화를 적용하면 가장 최근에 변경 된 값을 마스터에 위치 시켜서 간단하게 SQL문을 작성할 수 있다. 

2) 데이터베이스서버가 분리 되어 분산데이터베이스가 구성되어 있을 때 반정규화를 통해 성능을 향상시킬수 있는 경우

 서버 A 에 부서와 접수 테이블이 있고 서버 B 에 연계라는 테이블이 있는데 서버 B에서 데이터를 조회 할 때 빈번하게   조회되는 부서번호가 서버 A 에 존재하기 때문에 연계, 접수, 부서 테이블이 모두 조인이 걸리게 된다. 게다가 분산데이터베이스 환경이기 때문에 다른 서버간에도 조인이 걸리게 되어 성능이 저하됨

  이때는 서버 A에 있는 부서테이블의 부서명을 서버 B의 연계테이블에 부서명으로 속성 반정규화를 함으로써 조회 성능을 향상시킬 수 있다.

- 대량 데이터에 따른 테이블 분할 개요

  대량의 데이터가 존재하는 테이블에 많은 트랜잭션이 발생하여 성능이 저하되는 테이블 구조에 대해 수평(칼럼단위) /수직(로우단위) 분할 설계를 통해 성능저하를 예방 할 수 있음

  ex) 한 테이블에 데이터가 대량으로 집중되거나 하나의 테이블에 여러 개의 칼럼이 존재하여 디스크에 많은 블록을 점유하는 경우는 모두 I/O량이 증가하면서 성능저하를 유발

   · 로우체이닝 : 로우 길이가 너무 길어서 데이터 블록하나에 데이터가 모두 저장되지 않고 두 개 이상의 블록에 걸쳐         하나의 로우가 저장되어 있는 형태

   · 로우마이그레이션 : 데이터 블록에서 수정이 발생하면 수정된 데이터를 해당 데이터블록에서 저장하지 못하고 다른       블록의 빈 공간을 찾아 저장하는 방식

 

- 한 테이블에 많은 수의 칼럼을 가지고 있는 경우

  트랜잭션이 발생 될때 어떤 컬럼에 대해 집중적으로 발생하는지 분석하여 테이블을 쪼개어 주면 디스크 I/O가 감소하게 되어 성능이 개선됨

도서정보테이블에서 200개의 컬럼을 동시에 조회하던 경우를 전자출판유형에 대한 트랜잭션이 독립적으로 많이 발생되는 경우가 있으므로 도서전자출발테이블을 생성하여 1:1 관계로 분리

 

- 대랑 데이터 저장 및 처리로 인해 성능

  테이블에 많은 양의 데이터가 예상될 경우 파티셔닝을 적용하거나 PK에 의해 테이블을 분할하는 방법을 적용할 수

  있다

 

  1) RANGE PARTITION 적용

    대상 테이블이 날짜 또는 숫자값으로 분리가 가능하고 각 영역별로 트랜잭션이 분리된다면 Range Partition을 적용.

     또한 데이터보관주기에 따라 테이블에 데이터를 쉽게 지우는 것이 가능하므로(파티션 테이블 DROP)  데이터보관         주기에 따른 테이블관리가 용이

    ex) PK 가 요금일자+ 요금번호로 구성되어 있는 대용량테이블의 경우(데이터건수 1억2천만건) PK인 요금일자의

        년+월을 이용해 12개의 파티션 테이블(각 파티션 테이블당 평균 1000만건의 데이터) 을 만듦,

       그러면 SQL 문장을 처리 할 때는 마치 하나의 테이블처럼 보이는 요금 테이블을 이용하여 처리하면 되지만

       DBMS 내부적으로는 SQL WHERE 절에 비교된 요금일자에 의해 각 파티션에 있는 정보를 찾아가므로

       1000만건의 데이터에서 찾으면 되므로 성능이 개선

 

  2) LIST PARITTION 적용

     PK가 지점, 사업소, 사업장, 핵심적인 코드값 등으로 구성되어 있고 대량의 데이터가 있는 테이블이라면 값 각각에

     의해 파티셔닝이 되는 List Partition을 적용 할 수 있다. List Partition은 대용량 데이터를 특정값에 따라 분리 저장할       수는 있으나 Range Partition과 같이 데이터 보관주기에 따라 쉽게 삭제하는 기능은 제공 될 수 없다. 

    ex) 고객테이블에서 지역을 나타내는 사업소코드별로 고객_인천, 고객_서울 등등 List Partition을 적용하여 성능개선 

 

  3) HASH PARTITON 적용

    HASH 조건에 따라 해쉬 알고리즘이 적용되어 테이블이 분리되며 설계자는 테이블에 정확하게 어떻게 들어갔는지 알 수 없고 데이터 보관주기에 따라 쉽게 삭제하는 기능은 제공할 수 없다. 

 

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

  1) 데이터 모델링을 완성한다.

  2) 데이터베이스 용량산정을 한다. (칼럼수가많은지 확인)

  3) 대량 데이터가 처리되는 테이블에 대해서 트랜잭션 처리 패턴을 분석한다.

    (트랜잭션 특성에 따라 테이블을 1:1 형태로 분리할 수 있는 지 검증)

  4) 칼럼 단위로 집중화된 처리가 발생하는지, 로우단위로 집중화된 처리가 발생하는지 분석하여 집중화된 단위로

     테이블을 분리하는 것을 검토한다. 

 

- 슈퍼타입/서브타입 모델의 성능고려 방법

  · 슈퍼/서브타입 데이터 모델의 개요

   공통의 부분을 슈퍼타입으로 모델링하고 공통으로부터 상속받아 다른 엔터티와 차이가 있는 속성에 대해서는 별도의     서브엔터티로 구분하여 업무의 모습을 정확하게 표현하면서 물리적인 데이터 모델로 변환을 할 때 선택의 폭을 넓힐     수 있는 장점이 있다. 

   논리적인 데이터 모델에서 이용되는 형태이고 분석/설계 단계를 구분하자면, 분석단계에서 많이 쓰이는 모델이다.

   그러므로 물리적인 데이터 모델이 성능을 고려한 데이터 모델이 되어야한다는 점을 고려해야한다. 

 

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

   1) 트랜잭션은 항상 일괄로 처리하는데 테이블은 개별로 유지되어 Union 연산에 의해 성능이 저하될 수 있다. 

   2) 트랜잭션은 항상 서브타입 개별로 처리하는데 테이블은 하나로 통합되어 있어 불필요하게 많은 양의 데이터가 집약되어 있어 성능이 저하되는 경우가 있다.

   3) 트랜잭션은 항상 슈퍼+서브 타입을 공통으로 처리하는데 개별로 유지되어 있거나 하나의 테이블로 집약되어 성능이 저하되는 경우가 있다.

   그러므로 슈퍼/서브 타입을 성능을 고려한 물리적인 모델로 변환하는 기준은 데이터 양과 해당테이블에 발생되는 트랜잭션의 유형에 따라 결정된다. 

 

  · 슈퍼/서브타입 데이터 모델의 변환기술 

   데이터량이 많이 존재하고 지속적으로 증가하는 양도 많다면 슈퍼타입/ 서브타입에 대해 물리적인 모델로 변환하는 세가지 유형에 대해 세심하게 적용해야함 

   1) 개별로 발생되는 트랜잭션에 대해서는 개별 테이블로 구성

      슈퍼타입에도 꼭 필요한 속성만을 가지게 하고 서브타입에도 꼭 필요한 속성 및 자신이 타입에 맞는 데이터만 가지게 하기 위해서 모두 분리하여 1:1관계를 갖게함

      ex) 공통으로 처리하는 슈퍼타입테이블인 당사자정보를 미리조회 하고 원하는 내용을 클릭하면 거기에 따라서 서브타입인 세부적인 정보를 조회하는 방식

   2) 슈퍼타입+서브타입에 대해 발생도는 트랜잭션에 대해서는 슈퍼타입+서브타입 테이블로 구성

   3) 전체를 하나로 묶어 트랜잭션이 발생할 때는 하나의 테이블로 구성

 

  · 슈퍼/서브타입 데이터 모델의 변환타입 비교

   변환모델의 선택은 철저하게 데이터베이스에 발생되는 트랜잭션의 유형에 따라 선택을 해야한다. 

구분	OneToOne Type	Plus Type	Single Type
특징	개별테이블 유지	슈퍼+서브타입 테이블	하나의 테이블
확장성	우수함	보통	나쁨
조인성능	나쁨	나쁨	우수함
I/O량 성능	좋음	좋음	나쁨
관리용이성	좋지않음	좋지않음	좋음(1개)
트랜잭션 유형에 따른 선택방법	개별 테이블로 접근이 많은 경우 선택	슈퍼+서브 형식으로 데이터를 처리하는 경우 선택	전체를 일괄적으로 처리하는 경우 선택

- 인덱스 특성을 고려한 PK/FK 데이터베이스 성능향상

  · PK/FK 컬럼순서와 성능개요

  · PK 컬럼의 순서를 조정하지 않으면 성능의 저하 이유  

  · PK 순서를 잘못 지정하여 성능이 저하된 경우 - 간단한 오류

  · PK 순서를 잘못 지정하여 성능이 저하된 경우 - 복잡한 오류

 

- 물리적인 테이블에 FK제약이 걸려있지 않을 경우 인덱스 미생성으로 성능저하

  물리적인 테이블에 FK를 사용하지 않아도 데이터 모델관계에 의해 상속받은 FK속성들은 SQL WHERE 절에서 조인으로 이용되는 경우가 많이 있으므로 FK인덱스를 생성해야 성능이 좋은 경우가 빈번하다. 

  ex) FK 인덱스 미생성으로 FULL TABLE SCAN 발생하여 성능저하 -> FK인덱스 생성으로 INDEX SCAN발생하여 성능향상 ( 개발초기에는 데이터량이 얼마 되지 않아 성능저하가 나타나지 않지만 대용량일 경우)

 

- 분산 데이터베이스의 개요

  데이터베이스를 연결하는 빠른 네트워크 환경을 이용하여 데이터베이스를 여러 지역 여러 노드로 위치시켜

  사용성/성능 등을 극대화 시킨 데이터베이스

 

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

   분산데이터베이스가 되기 위해서는 6가지 투명성을 만족해야 한다. 

   1) 분할 투명성(단편화) : 하나의 논리적 Relation이 여러 단편으로 분할 되어 각 단편의 사본이 여러 site에 저장 

   2) 위치 투명성 : 사용하려는 데이터의 저장 장소 명시 불필요, 위치정보가 System Catalog에 유지되어야 함

   3) 지역사상 투명성 : 지역 DBMS 와 물리적 DB사이의 Mapping 보장, 각 지역시스템 이름과 무관한 이름 사용가능

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

   5) 장애 투명성 : 구성요소(DBMS) 의 장애에 무관한 Transaction의 원자성 유지

   6) 병행 투명성 : 다수 Transaction 동시 수행 시 결과의 일관성 유지, Time Stamp, 분산 2단계 Loking을 이용구현

 

- 분산 데이터 베이스의 적용 방법 및 장단점

   · 분산 데이터 베이스 적용 방법

    업무의 흐름을 보고 업무구성에 따른 아키텍처 특징에 따라 데이터베이스를 구성하는 것

 

   · 분산 데이터 베이스 장단점

장점	단점
- 지역 자치성, 검증적 시스템 용량 확장  - 신뢰성과 가용성  - 효용성과 융통성  - 빠른 응답 속도와 통신비용 절감  - 데이터의 가용성과 신뢰성 증가  - 시스템 규모의 적절한 조절  - 각 지역 사용자의 요구 수용 증대	- 소프트위어 개발 비용 - 오류의 잠재성 증대 - 처리 비용의 증대 - 설계, 관리의 복잡성과 비용 - 뷸규칙한 응답 속도 - 통제의 어려움 - 데이터 무결성에 대한 위협

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

  핵심가치 : 데이터 처리 성능,

                데이터를 분산 환경으로 구성하면 통합된 데이터베이스에서 제공할 수 없는 빠른 성능을 제공

 

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

  1) 테이블 위치 분산

     테이블의 위치는 변하지 않고 테이블이 다른 데이터베이스에 중복되어 생성되지도 않음, 다만 설계된 테이블의 위치

     를 각각 다르게 위치시킴

     ex) 자재품목은 본사에서 구입하여 관리하고 각 지사별로 자재품목을 이용하여 제품을 생산한다면 데이터베이스를

         본사와 지사단위로 분산, 각각 테이블마다 위치를 표기하여 테이블 생성 (자재품목 - 본사 , 생산제품-지사 )

    테이블별 위치 분산은 정보를 이용하는 형태가 각 위치별로 차이가 있을 경우에 이용

  2) 테이블 분할(Frgmentation) 분산

    단순히 위치만 다른 곳에 두는 것이 아니라 각각의 테이블을 쪼개어 분산하는 방법이다.  첫번째는 테이블의 로우(ROW) 단위로 분리하는 수평분할, 두번째는 테이블을 칼럼(COLUMN) 단위로 분할하는 수직분할이 있다.

    ·수평 분할 : 데이터를 수정할 때는 타 지사에 있는 데이터를 원칙적으로 수정하지 않고 자신의 데이터에 대해서

                    수정하도록 한다.

                    데이터가 지사별로 별도로 존재하므로 중복은 발생하지 않는다.

                    한 시점에는 한 지사(Node)에서 하나의 데이터만이 존재하므로 데이터의 무결성은 보장되는 형태이다.

    ·수직 분할 : 칼럼을 기준으로 분할하였기 때문에 각각의 테이블에는 동일한 Primary Key 구조와 값을 가지고 있어야

                    한다.

                    지사별로 쪼개어진 테이블들을 조합하면 Primary Key 가 동일한 데이터의 조합이 가능해야 하며 하나의

                   완전한 테이블이 구성되어야 한다.

                   데이터를 한군데 집합시켜 놓아도 동일한 Primary Key 는 하나로 표현하면 되므로 데이터 중복은

                   발생되지 않는다.   -> 사례가 드물다

  3) 테이블 복제(Replication) 분산

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

    부분복제 : 통합된 테이블을 한군데(본사)에 가지고 있으면서 각 지사별로는 지사에 해당된 로우를 가지고 있는 형태

    광역복제 : 통합된 테이블을 본사에 가지고 있으면서 각 지사에 본사와 동일한 데이터를 모두 가지고 있는 형태

  4) 테이블 요약(Summarization) 분산

    지역간에 또는 서버 간에 데이터가 비슷하지만 서로 다른 유형으로 존재하는 경우

    분석요약 : 각 지사별로 존재하는 요약정보를 본사에 통합하여 다시 전체에 대해서 요약정보를 산출하는 분산방법

    통합요약 : 각 지사별로 존재하는 다른 내용의 정보를 본사에 통합하여 다시 전체에 대해서 요약정보를 산출하는

                  분산방법

 

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

  · 성능이 중요한 사이트에 적용해야 한다.

  · 공통코드, 기준정보, 마스터 데이터 등에 대해 분산환경을 구성하면 성능이 좋아진다.  

  · 실시간 동기화가 요구되지 않을 때 좋다. 거의 실시간(Near Real Time)의 업무적인 특징을 가지고 있을 때도

    분산 환경을 구성할 수 있다.

  · 특정 서버에 부하가 집중이 될 때 부하를 분산할 때도 좋다.  

  · 백업 사이트(Disaster Recovery Site)를 구성할 때 간단하게 분산기능을 적용하여 구성할 수 있다