관계형 테이블로 전환

반정규화

무결성 제약 정의

(1) 입력 참조 무결성

• 데이터가 입력될 때 테이블의 PK에 대해 데이터의 정합성을 일치시켜 주는 기능이다.
• 6가지 기능
  • 의존 : 참조하고 있는 PK가 존재해야 한다.
  • 자동 : 참조하고 있는 테이블의 PK가 존재하지 않으면 PK를 생성하고 데이터를 생성한다.
  • 기본 : 참조하는 테이블의 PK를 기본값으로 바꾼 후 데이터를 입력한다.
  • 지정 : 정의한 일정한 조건을 만족한 후 입력한다.
  • Null : 참조하는 테이블의 PK가 없어도 입력한다. PK 값은 Null이 된다.
  • 미지정 : 참조하는 테이블의 PK가 없어도 입력한다. PK 컬럼값은 Null이 된다.

(2) 수정 참조 무결성

• 한 테이블의 PK가 수정되면 이 테이블을 참조하고 있는 모든 테이블의 FK도 수정하여 데이타의 정합성을 유지하는 기능이다.
• 수정참조 무결성을 유지하기 위한 2가지 기능
  • 제한:테이블의 PK를 수정하면 자신을 참조하는 테이블의 FK가 없어야 한다. 테이블의 FK가 존재하면 자신의 테이블의 PK가 수정되지 않는다.
  • 연쇄:테이블의 PK를 수정해아 한다면 참조되는 모든 테이블의 FK를 수정한 후 자신의 PK를 수정한다.

(3) 삭제참조 무결성

• 삭제참조 무결성을 유지하기 위한 6가지 기능
  • 제한:자신의 테이블의 레코드를 삭제하려면 자신을 참조하는 테이블의 레코드가 없어야 한다. 만약 이러한 레코드가 있다면 삭제해서는 안된다.
  • 연쇄:자신의 테이블의 레코드를 삭제하려면 참조하는 모든 테이블의 레코드를 삭제하고 난 후 자신의 레코드를 삭제한다.
  • 기본:참조하는 모든 테이블의 레코드를 기본값으로 변경한 후 자신의 레코드를 삭제한다. 주로 비식별자 관계에서 사용한다.
  • 지정:사용자가 정의해 놓은 일정한 조건을 만족한 이후에 자신의 레코드를 삭제한다.
  • NULL:참조하는 모든 테이블의 레코드를 NULL로 바꾼 후 자신의 레코드를 삭제한다. 비식별자 관계에서 사용한다.
  • 미지정:자신의 테이블의 레코드를 삭제해도 특별한 참조무결성 규칙을 적용하지 않는다. 조건없이 삭제가 가능하다.
    조건없이 삭제가 가능한 것이 어떻게 참조무결성을 유지하는 방법이 될 수가 있는가?

(4) 참조무결성 적용시 주의사항

• 한 테이블의 PK가 수정,삭제가 된다면 참조하고 있는 모든 테이블를 무결성 원칙에 따라 점검한다.(PK테이블의 입력는 자유롭다)
• FK가 있는 테이블에 입력,수정이 일어나면 PK가 있는 테이블에 레코드가 존재하는지 검사한다.(자식테이블에서의 삭제는 자유롭다)
• 이러한 이유로 성능이 저하되는 문제가 발생할 수도 있다.

(5) FK 제약이 걸려 있는 칼럼들의 인덱스 생성

• FK제약이 걸려있는 칼럼의 경우 인덱스를 생성하는게 좋다. 비록 업무상 그 인덱스를 사용하지 않을지라도 DBMS내부적으로 사용하기 때문이다.
• <사원>과 <발령>테이블이 사원번호로 연결되어 있는경우 <발령> 테이블의 사원번호에 인덱스를 생성하지 않으면 특정 사원정보가 삭제될 때 DBMS내부적으로는 <발령> 테이블을 풀스캔하여 삭제한 데이타를 찾기때문에 성능에 문제가 될 수 있다.
• 물론 FK의 인덱스도 평균분포도가 10~15%인 컬럼에 대해 지정하는 규칙은 적용된다

트랜잭션 분석

(1) 트랜잭션 정의

• 트랜잭션이란 데이타베이스에서 행해지는 작업의 논리적인 단위로써 테이블에 발생하는 업무 트랜잭션 양에 따라 데이타베이스의 용량을 산정하여 DB의 구조를 최적화하는데 트랜잭션 분석의 목적이 있다.

(2) 트랜잭션 분석

• 프로세스 모델링을 이용하여 단위 프로세스를 도출한다.
  

• 상관모델링을 이용하여 단위프로세스와 엔티티타입간의 관계인 CRUD MATRIX를 작성한다.
  

• 트랜잭션 분석도를 만들고 테이블별 총 트랜잭션 수를 파악한다.
  
  • 트랜잭션당:트랜잭션당 테이블을 읽는 횟수를 말한다. 제품과 주문목록이 5인 것은 하나의 주문에 제품 5개를 주문했다고 가정한것이다.
  • 트랜잭션수:주기 일당 총 일어나는 트랜잭션 수이다. 고객,주문이 200이므로 5번을 읽는 제품,주문목록은 1000이 된다.
  • 트랜잭션수의 총합인 2400이 하루동안 일어나는 총 트랜잭션 수가 된다.

(3) 트랜잭션 분석도 이용

• 용량산정의 근거자료가 된다.
  • 각 테이블의 생성 트랜잭션을 분석해 나가면 테이블에 저장되는 데이타 양을 유추할 수 있고 이를 근거로 DB용량을 산정할 수 있다
  • EX)사원이 10000명이고 사원 한명당 발령은 3번,급여는 상여포함 20번이 발생한다면 발령 테이블에는 30000건,급여테이블에는 600000건의 데이타가 발생할 것임을 유추할 수 있다.

• 디스크 구성의 이용
  • 트랜잭션 분석도를 이용하여 프로세스가 과도하게 발생하는 테이블에 대해서는 디스크를 여러군데 배치하여 디스크 입출력을 분산시켜 성능에 많은 향상을 기할 수 있다.

3.데이타베이스와 연결되는 채널의 분산

• 각 채널별로 집중화된 트랜잭션을 분산시킴으로써 대기현상이나 TIME-OUT현상을 방지할 수 있다.

뷰설계

(1) 뷰의 특징

• 테이블의 구조를 단순화한다.
  • <주문>과 주문의 상세내용을 담고 있는 <주문목록> 테이블이 있고 이들이 항상 조인되어 사용된다면 뷰를 만들어 사용함으로써 쿼리문을 간소화시킬 수 있다.
    

• 그렇다면 애초 테이블 설계시 하나의 테이블로 만들면 될 것을 분리해 놓고 막상 개발시는 두 테이블을 하나로 합친 뷰를 만들어 사용하는가?
  • 테이블을 하나로 합쳐 놓은 다면 주문번호,신청자명처럼 1쪽의 데이타는 중복이 일어나 디스크용량을 차지하게 된다.이 또한 정규화의 대상이 될 것이다. 그러나 뷰로 만든다면 효과는 하나의 테이블과 똑같은 효과를 내면서 sql문만 저장되기에 디스크 용량을 차지하는 일은 없을 것이다.

• 다양한 관점에서 데이타를 제시한다.
  • 많은 부서에서 수 많은 직원이 사용하는 테이블이 있지만 그 테이블에 있는 모든 칼럼을 보여줄 필요없이 각 사용자에게 필요한 칼럼만을 뷰로 만들어 제공할 수 있다.

• 데이타 보안유지
  • 사원테이블에는 학력등 인사담당자 외에는 제공되어서는 안되는 민감한 정보들이 있을 수 있다. 이때 테이블로만 제공한다면 어쩔 수 없이 모든 이에게 민감한 정보가 공개될 수밖에 없지만 뷰로 각 유저에게 필요한 만큼의 정보만을 제공할 수 있다.

• 논리적인 데이타의 독립성을 제공한다.
  • 뷰의 근거가 되는 테이블의 구조가 변경되어도 뷰는 수정할 필요가 없다. 사원테이블에 취미라는 칼럼이 추가되었다면 취미칼럼을 필요로 하는 뷰를 제외한 나머지 뷰의 쿼리문은 수정할 필요는 없다.
    사원테이블에 취미라는 칼럼이 있었는데 어느 날 없어진다면 당근 취미를 조회하는 뷰의 쿼리문은 변경되어야 할 것이다.

• 데이타의 select기능은 제한이 없으나 입력,수정,삭제는 일부 제약이 있을 수 있다.

• 뷰에는 인덱스,클러스터링을 지정할 수 없다.

(2) 뷰의 정의

• 뷰의 대상이 되는 테이블
  • 외부 시스템과 인터페이스에 관여하는 테이블
  • 크러드메트릭스에서 자주 조인되는 테이블들
  • 많은 쿼리문에서 인라인 뷰 방식으로 접근되는 테이블은 인라인 뷰 쿼리로 뷰를 만든다.

• 뷰의 대상이 되는 칼럼선정
  • 사용하는 프로세스,유저등급등을 고려하여 원하는 대로 칼럼을 지정하여 뷰를 만들 수 있다.

• 뷰 정의서 작성
  • 뷰명:뷰 이름 기록
  • 설명:뷰의 기능 기록
  • 관련테이블:뷰가 생성되기 위한 원래의 테이블명
  • 칼럼명:뷰 내에 포함될 칼럼 이름
  • 데이타 타입:칼럼의 데이타 타입

인덱스 설계

(1) 인덱스 대상 선정

• 인덱스의 필요 판단기준은 DBMS가 테이블을 읽어 들일 때 수행하는 MULTI BLOCK READ수에 의해 판단한다.
  • MULTI BLOCK READ 란 테이블 엑세스시 한꺼번에 메모리에 읽어 들이는 블럭의 수이다.
  • MULTI BLOCK READ 가 16일 경우 테이블 크기가 16블럭 이상이면 인덱스를 설정하도록 한다.
    • 오라클의 경우 1블럭이 8K인 경우 8블럭을,4K인 경우 16블럭을 지정할 것을 권유하고 있슴
    • 8*8=64,4*16=64이므로 결국 64K 이내의 테이블은 인덱스를 설정하지 않고 테이블 풀스캔을 해도 별 지장이 없다는 결론
      그러나 다른 테이블에 의해 참조되는 관계이거나 조인에 의해 처리되는 경우 PK,FK에는 인덱스를 생성해 주는 것이 좋다.

• 아무리 작은 테이블일지라도 PK칼럼은 반드시 인덱스를 사용해야 한다.
• <부서>,<사원> 테이블이 있고 <사원>테이블에 소속부서 칼럼이 있는데 만일 <부서> 테이블의 데이타가 적다고 하여 PK인덱스를 사용하지 않는다고 가정해 보자.

SELECT A.사원번호,A.사원명,B.부서명
FROM 사원 A,부서 B
WHERE A.부서코드=B.부서코드
AND A.사원번호 BETWEEN '1' AND '100'

• 사원번호가 PK로 경합성에서 우수하므로 <사원> 테이블이 드라이빙 테이블이 된다.
• <사원>에서 하나의 로우가 추출된 후 부서명을 가져오기 위해 <부서> 테이블과 조인이 일어나는데 <부서> 테이블에는 PK인덱스가 없기에 결국 해당 사원이 속한 부서명을 찾기 위해 <부서> 테이블을 풀스캔해야 한다.
• 즉, <사원> 테이블에서 추출된 로우 수 만큼 <부서> 테이블에 풀스캔 엑세스가 일어나 성능에 심각한 문제점을 초래하게 된다. 그러나 만일 <부서>테이블의 부서코드에 PK인덱스가 걸려 있다면 <사원>에서 추출된 부서코드와 조인하여 단 한번의 테이블 엑세스로 부서명을 가져올 수 있게 될 것이다.

• PK와 유니크인덱스이 비교

• 유니크 인덱스만을 사용할 경우

<장점>

• • DBA가 데이타베이스를 관리하기가 쉽다. (?)
  • 개발 시점에 데이타 제약이 없으므로 개발이 용이하다.
  • PK,FK를 이용하지 않으므로 성능이 다소 좋아질 수 있다. (DBMS 내부적으로 데이타딕셔내리에 관리해야할 항목이 줄어든다 (?))

<단점>

• • 데이타의 무결성이 깨질 수 있다.
  • 데이타의 무결성이 깨진 경우 데이타 전환작업시 데이타 정리작업이 추가적으로 필요하다.
  • 데이타 모델과 테이블의 관계가 일치하지 않다.
  • 유니크 인덱스는 한개의 테이블이 여려개를 만들 수 있기에 PK가 무엇인지 구분할 수가 없다.

• 결론
  • 데이타베이스 구축과 운영시 중요도는 데이타정합성>성능>관리의 용이성>개발편의성이다.
  • 유니크 인덱스만을 사용할 경우 성능,관리면에서는 어느 정도 더 효율적일지 모르나 가장 중요한 데이타의 정합성이 깨질 우려가 있다는 점에서 반드시 PK를 사용하는 것이 좋다.

• FK칼럼에 인덱스가 걸려 있지 않다면 FK제약때문에 테이블 풀 스캔이 일어난다. (?)
• 또한 인덱스가 없다면 데이타의 입력,수정,삭제가 발생할 때 테이블 블럭을 유발한다. (?)
• 그러므로 FK칼럼에 반드시 인덱스를 걸어 주도록 한다.

• 테이블 내에서 자주 사용되며 분포도가 10~15% 정도인 칼럼을 대상으로 한다.

• • 분포도(%)=데이타별 평균로우수/테이블의 총 로우수*100

• 여러개의 컬럼이 항상 같이 사용되는 경우도 인덱스를 걸어주는게 좋다.

(2) 인데스 최적화

• 인덱스 칼럼은 자주 수정이 발생되지 않는 칼럼을 선정하는 것이 좋다.
• 평균 분포도가 10~15% 이내일지라도 분포가 기형적이면 인덱스를 설정하지 않는게 좋다. 한 칼럼의 값이 A,B,C,D 네가지 종류인데 이들의 평균분포도가 비록 15이내일지라도 어떤것은 1,어떤것은 30 이럴경우 테이블 풀 스캔이 더 좋을 수도 있는데 불필요하게 인덱스를 거쳐 테이블에 엑세스하여 성능이 저하될 수 있다.
• 한 테이블에 인덱스가 5개가 넘어가는 경우 진정으로 필요한 인덱스인지를 검토후 삭제하여 그 수를 줄일 필요가 있다.

• 데이타 길이가 변하는 칼럼의 경우 VARCHAR타입을 사용한다.
• 날짜타입의 경우 시,분,초까지 저장할 필요가 없다면 DATE형보다 VARCHAR형이 더 좋다.
• 가급적 NUMBER형 보단 VARCHAR형의 인덱스가 더 효율적이다.

• 인덱스를 사용하는 유형이 대부분 역정렬 형태라면 인덱스를 역정렬순서로 생성하여 INDEX_DESC 힌트를 추가적으로 사용하지 않도록 한다.
• 결합인덱스를 생성할시 첫번째 칼럼은 분포도가 좋고,항상 사용되고,=연산자로 비교되는(검색범위를 획기적으로 줄여줄 수 있다) 칼럼을 첫번째 칼럼으로 삼도록 한다.

• 분포도가 넓은 경우,즉 동일한 값들이 많이 분포하는 경우는 인덱스를 사용하는 것이 적합지 않다. 이럴경우 클러스터링을 사용하도록한다.
• 클러스터링은 칼럼값이 동일한 로우들을 한곳에 모아서 저장함으로써 대량의 조회시 획기적인 성능향상을 기할 수 있는 방법이다.
• 그러나 이 역시 조회속도는 향상시키지만 입력,수정,삭제시는 성능저하를 야기한다.

(3) 인덱스 정의서 작성

• 엔티티타입명:
• 인덱스 스페이스:인덱스가 물리적으로 생성할 테이블 스페이스 이름 (대용량의 DB라면 데이타가 저장되는 테이블 스페이스와 별로도 인덱스만의 테이블 스페이스를 지정하여 사용하기도 한다)
• 인덱스 유형:유니크,NON-유니크,클러스터
• 정렬:오름차순,내림차순
• 구분:PK인덱스,FK인덱스

h1.데이터베이스 용량설계

h2.데이타베이스 용량 분석의 목적

• 정확한 데이타 용량을 산정하여 디스크 사용의 효율을 높인다.
• 업무량이 집중되어 있는 디스크를 분리,설계하여 디스크에 대한 입출력 부하를 분산시킬 수 있다.
  데이터량이 많고 데이터의 증가량이 많을 수록 디스크에 대한 입출력 분산이 철저하게 고려되어야 성능을 향상시킬 수 있다.
• 여러 프로세스가 동시에 접근할 때 발생하는 디스크 입출력 경합을 최소화하여 데이터의 접근 성능을 향상시킨다.
• 데이터베이스 오브젝트의 익스텐트(범위,Extent) 발생을 줄인다.

데이터베이스 용량 분석 절차

(1) 용량분석을 위한 기초 데이터를 수집한다

(p313표 7-3 데이터베이스 용량설계-기초데이터 조사)

• 로우길이:해당 테이블의 컬럼길이를 모두 합하여 기록한다.
• 보존기간:테이블을 디스크에 어느 정도의 기간동안 보관할 것인지 기록.
• 초기건수:구축시스템을 운영하기 전 데이터가 어느정도인지 기록.
• 발생건수:일정주기별로 데이터가 얼마나 발생하는지 기록.
• 발생주기: 1년단위? 월단위?
• 년 증가율: 해가 바뀌어 감에 따라 증가 할 수 있는 데이터량을 기록.

(2)기초 데이터를 이용하여 DBMS에 이용하는 오브젝트별로 용량을 산정한다

1)오브젝트설계
2)테이블스페이스 용량산정
3)디스크 용량 산정

h1.접근 방법 설계

h2.스캔방식

• 테이블에 존재하는 데이터를 일정수준 이상 검색해야 하는 경우는 스캔방식으로 데이터를 가져오는 것이 더 효율적임.
• 전체 테이블을 모두 검색하는 것을 풀스캔이라고 하고, 정렬된 테이블에서 특정 부분만을 스캔하는 것을 범위스캔이라고 한다.

h2.B트리 인덱스

h3.B트리 인덱스의 기본구조

1)리프블록(Leaf Block)

• 테이블의 각 레코드의 인덱스 정보를 가지고 있는 블록.
• 테이블에서 입력,수정,삭제,조회가 발생하면 관련 인덱스가 리프블록내에서 입력,수정,삭제,조회를 발생시킨다.
• 블럭헤더:인덱스 칼럼의 구간값과 인덱스바의 물리적 위치 정보를 가지고 있다.

2)브랜치블록(Branched Block)

• 리프블록과 루트블록의 중간에서 블록사이의 정보에 대한 다리 역할을 하는 블록이다.
• 블록헤더 : 인덱스 칼럼의 구간값과 인덱스바의 물리적 위치정보가 있다

3)루트블록(Root Block)

• 트리의 최상위에 위치하며 조회,입력,수정,삭제시 제일 먼저 접근된다.

h3.B트리 인덱스의 검색원리

• B트리 인덱스의 검색은 루트로부터 리프블록까지 이루어진다.
• 해당 테이블 레코드 값이 필요하면 블록의 레코드 로우ID를 이용하여 해당 테이블에서 레코드를 읽어온다.

h3.B트리 인덱스의 입력, 수정, 삭제 원리

(그림 7-60 B트리 인덱스의 변경-블록추가)

1. 위 그림에서 각 블록은 세개까지 인덱스바를 저장할 수 있다고 가정한다.
2. 새로 추가되는 인덱스는 자신이 저장될 수 있는 구간값을 가지는 리프블록을 찾는다.
3. 만약, 블록의 인덱스바 세개로 더이상의 인덱스 값을 저장할 수 없으면 상위 브랜치 블록에 통보한다.
4. 브랜치블록은 인덱스바가 두개이므로 하나의 리프블록을 더 만든다.
5. 그리고 추가된 값을 포함하여 해당 인덱스 구간값을 가지는 리프블록의 인덱스바 수를 반으로 나누고, 그 반을 리프블록으로 이동시켜 새로운 인덱스 추가작업을 종료한다.

p323 참조 (그림 7-61 B트리 인덱스의 변경-레벨추가)
1. 새로운 두개의 인덱스가 추가된다고 가정한다.
2. 해당 구간 값을 가지는 리프 블록에 새로운 두 값을 더하면 모두 4개의 인덱스 바가 생성되므로 수용할 수 없게 된다.
3. 따라서 상위 브랜치 블록의 추가를 요청한다.
4. 브랜치 블록도 자신의 인덱스 바를 세개 가지고 있으므로 리프 블록을 추가 할 수 없다.
5. 따라서 루트 블록에 브랜치 블록의 추라글 요청한다.
6. 루트 블록도 세개의 인덱스바를 가지고 있어서 브랜치 블록의 추가가 불가능 하므로 상위 루트 블록을 만들고 자신은 브랜치 블록으로 변경된다.
7. 자신과 같은 레벨의 브랜치 블록을 새로 만들어 자신의 인덱스 바의 절반을 추라된 브랜치 블록에 넘겨준다.
8. 새로 추가된 브랜치 블록은 하위 레벨에 브랜치 블록을 새로 만들고, 같은 하위 레벨의 기존 값을 반으로 나누어 이를 새로운 하위 브랜치 블록에 넘겨준다.
9. 새로운 하위 레벨의 브랜치 블록은 새로운 리프 블록을 만들고, 이웃 리프블록으로부터 인덱스바의 절반을 넘겨 받는다.

h2.비트맵 인덱스

• 컬럼 정보를 0과 1을 이용하여 별도의 인덱스로 저장하는 방법.
  WHERE 조건의 AND나 OR 연산에 의해 데이터를 검색하는 방법.

출처: http://wiki.gurubee.net/pages/viewpage.action?pageId=1966785

출처: http://wiki.gurubee.net/pages/viewpage.action?pageId=3902465&

• B-tree의 leaf block은 Index key value + Rowid 로 구성이 되어 있지만, Bitmap Index는 Index key value + Start Rowid + End Rowid + Bitmap 엔트리로 구성되어 있다.
• 1개의 index값이 테이블상의 여러 개의 record를 표현하기 때문에 DML문을 사용할 경우 row level locking을 지원할 수 없다
• Start Rowid 와 End Rowid 의 Range사이에 있는 모든 row수만큼 Bitmap이 표현되어야 하지만, 오라클에서는 내부적인 압축 알고리즘을 사용하여 Bitmap을 생성하기 때문에 모두 표현되지 않는 경우도 있다

h3.비트맵 인덱스의 입력, 수정, 삭제의 원리

• 비트맵 인덱스의 입력,수정,삭제는 비트리 인덱스에 비해 상대적으로 처리속도가 매우 느리다.
• 총 20만건의 레코드가 있는 테이블에서 물리적인 위치가 10만번 째가 되는 새로운 인덱스를 삽입한다고 하자. 먼저 추가할 인덱스를 삽입하고 100,001부터 이후 모든 인덱스 값을 한 칸씩 뒤로 미루는 작업을 해 주어야 한다.
• 따라서 한건이 추가된다는 것은 인덱스 전체구조를 바꾼다는 것과 같다. 따라서 입력,수정,삭제가 빈번한 테이블에 대해서는 비트맵 인덱스가 적절하지 않다.

h2.B트리 인덱스와 비트맵 인덱스 비교

해싱기법적용

해시 인덱스의 특징

• 6블록 이상 물리적인 블록의 크기를 갖는 테이블에 적용한다.
• 정렬순서에 따른 접근방식이 아니라 임의접근방식이 많이 발생하는 경우에 적합하다.
• 자주 변경되지 않는 칼럼값에 해시키를 적용한다.
• 클러스터키를 사용하는 비슷한 검색조건으로 부터 해시클러스터 인덱스는 인덱스 클러스터보다 빠른 성능을 제공한다.
• 하나의 테이블에는 하나의 해시키만 가지 수 있으므로 가장 많이 조회하거나 중요한 칼럼에 해시키를 지정한다.
• 해시 알고리즘은 범위검색에는 적용되지 않는다 ex) ORDDATE > '2007-07-01' 사용 못 함
• 정렬되어 있는 테이블의 데이터를 조회할 때는 해시 알고리즘은 이용되지 않는다.
• 여러개의 칼럼을 하나의 해시키로 구성하였을 때 만약 일부에 대해서만 비교한다면 해시 알고리즘은 이용되지 않는다.

클러스터링

클러스터링의 특징

• 6블록 이상의 테이블에 적용한다.
• 인덱스만을 이용하여 처리하려면 데이터의 분포도가 낮은 경우에 적용한다.
• 일정한 순서로 조회되는 경우가 많을 때 적용한다.
• 입력,수정,삭제가 자주 발생되지 않는 컬럼에 적용한다.
• 클러스터링을 생성한 기준값은 수정되지 않아야 한다.
• 테이블이 분할되어 있지만 거의 동시에 조인하여 조회하는 때가 많을 경우 적용한다.
• 일반 테이블보다 저장 공간을 많이 차지하므로 전체스켄을 할 경우 검색속도가 느리다.

클러스터링이 적용안되는 경우

• 테이블에 전체스캔이 종종 발생한다면 클러스터링을 적용하지 않는다
• 파티셔닝을 적용하면 클러스터링 기능을 사용할 수 없다.
• 동일한 클러스터 키를 가진 클러스터링된 데이터의 크기가 하나의 블럭을 초과할 경우 클러스터링을 적용하지 않는다.

h1.데이터베이스 분산설계

h2.테이블 위치 분산
정보를 이용하는 형태가 각 위치별로 차이가 있을 경우에 이용함.
테이블 위치를 파악할 수 있는 도식화된 위치별 데이타베이스 문서가 필요.

h2.테이블 분할 분산
각각의 테이블을 쪼개에 분산하는 방법.

h3.수평분할
지사별 테이블의 컬럼값을 기준으로 로우를 분리.
컬럼은 분할되지 않으며 모든 데이터가 지사별로 분리되어 있음.
각 지사에 있는 데이터와 다른 지사에 있는 데이터는 항상 배타적으로 존재하며 데이터를 한군데 집합시켜 놓아도 PK에 의해 중복이 발생하지 않음.

h3.수직분할
지사에 따라 컬럼을 기준으로 컬럼을 분리.
로우단위로는 분리되지 않으며 모든 데이터가 각 지사별로 분리되어 있음.
각각의 테이블에는 동일한 PK구조와 값을 가지고 있어야 함.

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

• 부분복제 : 통합된 테이블을 한군데(본사)에 가지고 있으면서 각 지사별로 해당 로우를 가지고 있는 형태.
• 광역복제 : 통합된 테이블을 한군데(본사)에 가지고 있으면서 각 지사에서도 본사와 동일한 데이터를 모두 가지고 있는 형태.

h2.테이블 요약 분산

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