2) 그림 설명
- 클러스터 인덱스에 있는 Cluster Key ID는 cluster key 컬럼 값 마다 하나씩 존재
   ( 동일 의미 : 클러스터링 테이블의 각 row 헤더에는 cluster key Id를 가지고 있다.
- 클러스터 스캔방식
    : 클러스터 인덱스에 있는 클러스터 ID 정보(Cluster Key Id)를 통해 단위 클러스터를 찾는 작업
- 하나의 클러스터 인덱스(102)로 여러 개의 로우를 스캔 할 수 있으므로 기존의 인덱스보다 훨씬
   적은 비용이 듬
- 하나의 블록에 2개의 단위 클러스터만 존재 하도록 지정 가능(SIZE)
   (위 ‘단위 클러스터 추가 불가능’의 BLOCK은 이미 2개의 단위 클러스터가 존재했기 때문이며,
     ‘단위 클러스터 추가 기능’의 BLOCK은 하나의 단위 클러스터만 있기 때문에 추가가 가능하다.)
- 단위 클러스터에 동일한 Cluster Key 값이 모두 표시되어 있지만 실제로는 물리적으로 단 한번 저장
    < 블록헤더에 클러스터 키 ID와 클러스터키 값을 보유( 다중 테이블 클러스터링과 동일 ) >
- Cluster Key 값이 수정시, 일반 테이블 컬럼 수정 처럼, 로우 길이의 증가로 인해 로우 이주가 발생
    < 수정된 Cluster Key 값이 모여 있는 곳으로 이동해야 되는데, 이럴 경우 기존 자리에
      새로 이주해 가야할 곳의 Row ID를 남겨두고 현재 Row정보를 가지고 이동한다. >
- 약 5 - 8배 정도의 효율 향상 기대
- 일반 인덱스와 클러스터 인덱스의 차이점
   : 한번 클러스터 인덱스를 액세스 하여 여러건의 테이블 로우를 스캔방식으로 액세스 할 수 있다는 차이.



1.3.3 다중테이블 클러스터링
1) 정의 : 단위 클러스터에 2개 이상의 테이블 데이터를 함께 저장.
          같은 Cluster Key 값을 가진 각 테이블의 로우는 정해진 장소에 같이 저장 되므로 테이블의
          조인하는 속도를 향상시키고자 할 때 활용

2) 그림설명
- 첫 번째 블록에는 2개의 단위 클러스터가 입주한 상태
- 각 단위 클러스터에는 'DEPT' 테이블의 한 개의 Row와 'EMP' 테이블의 여러 개의 로우가
   클러스터키 컬럼인 'DEPTNO'를 기준으로 같이 저장되어 있다. ( DEPTNO = 110, 112, 111 )
- 각 Row에는 ‘Cluster Key Id'를 가지고 있으며, 블록헤더에는 Cluster Key 정보 존재.
   그래서, 점선으로 표현해 두었듯이 각 로우에 있는 ‘Cluster Key Value'는 실제로는 저장되지 않는다.
- 지역적 투명성 : 테이블을 같은 클러스터 내에 저장하더라도 각 테이블의 독립성은 존재
- 다중테이블 클러스터링은 정규화작업에 의해 어쩔 수 없이 분할된 테이블을 마치 하나의 테이블처럼 만듬.
   ( 분할 된 테이블을 조인 시 부담이 가중되나, 조인되는 컬럼을 기준으로 뭉쳐있기 때문에 다소 해결됨)
- 유연성 훼손 : 각 테이블은 또 다른 많은 테이블과의 다양한 관계를 맺고자 할 경우.
   ( 업무상 다른 테이블과의 관계를 고려하지 않고, 특정한 테이블끼리의 목적으로 클러스터링 했다면,
     추후에 큰 비용을 치를 수 있음 )
    


1.3.4 클러스터링 테이블의 비용
  1) 클러스터링의 장점
    - RDBMS(관계형 데이터베이스 매니지먼트 시스템)의 최대약점인 넓은 범위의 처리를 해결
    - 조인의 효율성을 크게 높여 주므로 데이터 액세스에 대해 크게 효율적( 단, 특정한 상황)

  2) 클러스터링의 역할
    - 해결해야할 액세스 형태를 모두 수집하고, 보다 적은 비용이 드는 인덱스로 해결 할 방안 강구
    - 클러스터링으로 인한 부하의 부담도 충분히 고려

  3) 클러스터링으로 인한 부하의 정도
    - 클러스터링은 SELECT의 효율을 높여 줄 뿐이다.
    - DML(입력, 수정, 삭제)시는 추가적인 부하가 발생

    * Insert
      : 클러스터링 테이블에 데이터를 입력하게 되면 정해진 위치(단위 클러스터)를 찾아서 저장해야한다.
       - 일반테이블 insert 방법
        : RDBMS의 장점인 데이터 입력시 Freelist에 저장공간(Block)을 할당받아 거기에 무조건 저장하며,
         만약 저장되고 잇는 블록이 Pctfree에 도달하면 새로운 Block을 요구하여 데이터를 저장하는 방법
       - 클러스터링 테이블 insert 방법
        : 정해진 위치라는 뜻은 이미 생성되어 있는 Cluster Key Value가 있다면, 반드시 같은 값을
          가진 로우들은 그 위치를 찾아서 저장해야 된다는 뜻
      # 단점
       - 일반 테이블은 한 번 할당받은 블록에 100개의 로우를 한꺼번에 저장할 수 있지만,
         클러스터링 테이블은 최악의 경우 100개의 블록에 따로 저장하는 경우도 발생
         이유 : Cluster Key Value(컬럼값)가 값이 서로 이질적이고, 각각의 값들과 같은 값이 이미 다른
         블록에 이미 저장되어 있는 경우( 1개의 row마다 서로 다른 블록에 저장해야 하는 부하 발생)
        
    * Update
      : Cluster Key Value에 따라 저장되어 있으므로, 이 컬럼 값이 변한다는 것은 컬럼 값만 바뀌는 것이
        아니라 다른 단위 클러스터로 이동해야 되다는 것을 의미
        ( 일단 변경된 로우를 변경된 값들이 모여져 있는 단위 클러스터로 이동시키고, ROWID를 변경
          시키 지 않기 위해서 원래 위치에 이주해간 위치 정보를 남겨둔다.)
       # 단점
         일반 테이블의 migration과 다를 게 없으므로 큰 부하는 발생하지는 않으나, 클러스터링 팩터가
         나빠져 원래 목적으로 했던 것과는 반하는 구성이 된다. 그러므로 수정이 빈번하게 발생하는 컬럼을
         Cluster Key Value로 정하는것은 좋지 않다.

    * Delete
      : 클러스터링 테이블의 모든 로우를 삭제하더라도 클러스터 인덱스는 그대로 존재.
        (테이블 이외 추가 작업은 없다.)
       - 일반 테이블의 삭제
        : 'DROP'명령은 DDL 이므로 롤백을 하지 않고, 롤백세크먼트에 롤백정보를 저장하지 않는다.
      - 클러스터링 테이블의 삭제
        : ‘DROP'명령시, 내부적으로 'DELETE'를 수행하게된다. 롤백세그먼트를 할당받아 테이터를
          저장한다. 대용량의 테이블을 삭제한다면, 이에 맞는 충분한 롤백세그먼트가 있어야함.

          ( 동일한 단위 클러스터 내에 2개의 테이블이 같이 저장되어 있는데, DROP을 하여 한
            테이블을 삭제한다면, 단위 클러스터 입장에서는 자신의 ROW들중 일부가 제거되는거에
            불과하기 때문에, DELETE 작업을 할 수 밖에 없는 상황이다. )

1.3.5 해쉬(HASH) 클러스터링
  1) 정의
    - 클러스터링이기보다는 일종의 인덱스를 대신하는 개념
    - 물리적인 인덱스를 가지지 않고 해쉬값을 이용해 데이터를 액세스하려면 데이블의 데이터를
      약속된 장소에 저장
       * 클러스터링 개념 : 테이블에 데이터를 정해진 위치에 저장해야함,
       * 인덱스     개념 : 원하는 값을 찾아간다는 입장에서 보면 인덱스 개념
  
  2) 해쉬 클러스터링의 특징
   - SIZE, HASHKEYS, HASH IS 파라미터는 변경 할 수 없다.
   - ‘='로만 액세스해야 한다.
   - 클러스터가 생성되면서 저장공간이 미리 할당된다.
   - 지정된 단위 클러스터 보다 많은 로우가 들어오면 OVERFLOW영역에 저장된다.
   - 컬럼의 값이 고르게 분포되어 있지 않으면 해쉬키 값의 충돌(COLLISION)이 발생한다.
   - 인덱스를 경유하지 않고 해쉬 함수로 계산된 값으로 직접 테이블 액세스하므로 인덱스보다 효율적인
     액세스를 할 수 있다.

   3) 해쉬 클러스터링의 활용 범위
    - 검색조건 ‘=’ 로만 사용
    - 클러스터 키 컬럼의 값이 균등한 분포를 하고 있는 경우가 아니라면 비 추천(같은 값이 많으면 안좋음)
    - 소형테이블, 우편번호, 시스템 사용자 정보 테이블 추천
    - ‘사원정보’, ‘고객정보’ 테이터가 증가하는 추세가 완만하고, ‘=’로 액세스하는 경우 추천
    - 대개 테이블은 데이터가 증가하는 형태이기 때문에 비 추천
    - 대량의 데이터를 일정량의 해쉬 클러스터에 저장시키고자한다면 해쉬 파티션 추천
  
   4) 해쉬 클러스터의 정의
     CREATE CLUSTER[schema.] cluster
     (column datatype[,column datatype]...)
     HASHKEYS integer
     [HASH IS expression]
     [PCTFREE interger]
     {PCTUSED integer}
     [INITRANS interger]
     [MAXTRANS integer]
     [SIZE interger[K|M]]
     [storage_clasue]
     [TABLESPACE tablespace

    - HASHKEYS
      1) 해쉬 클러스터로 생성될 해쉬키 값의 개수
      2) 지정한 값보다 큰 소수가 적용(100을 지정하면 101로 정의)
      3) SIZE값과 더불어 클러스터가 생성될때 초기 저장공간을 할당적용

    - HASH IS
      1) 해쉬 함수 지정
      2) 클러스터 키 값이 다르면 해쉬값도 최대한 달라지도록 하는 것이 중요
        - 서로 다른 클러스트 키 값을 가진 로우가 같은 해쉬값을 가지게 되어 오버 플러우발생
        - 클러스터링 팩터가 나빠져 비효율
      3) 해쉬 함수를 적용한 결과는 양수
      4) 사용자 정의 저장형 함수를 해쉬함수의 일부로 사용 못함

    - SIZE
      1) 해쉬키값을 가지는 ROW ( 단위 클러스터에 저장될 ROW )들을 위해 확보한 클러스터의 크기
       - 수치 : 단위 클러스터에 저장될 수 있는 총 로우수를 결정
      2) 지정한 수치가 블록크기(DB_BLOCK_SIZE) 보다 크면 0/S의 블록크기 사용
      3) 지정하지 않으면, 각 단위 클러스터에 대해 하나의 테이블 블록을 할당
      4) 해쉬 클러스터를 적용 할 때 해쉬키 값을 충돌을 하면 액세스 효율이 떨어진다.
         - SIZE값을 약간은 여유있게 지정해야함
          
한 블록에 저장될 해쉬키의 개수    ||      설정할 SIZE 값
                1                                         계산한 SIZE 값 + 15%
                2                                         계산한 SIZE 값 + 12 %
                3                                         계산한 SIZE 값 + 8 %
              > 4                                         계산한 SIZE 값

  
5) 단일 테이블 해쉬 클러스터
  : 클러스터는 하나 이상의 테이블을 저장할 수 있는 개념으로 만들어 졌지만, 클러스터를 생성하면서
    단 하나의 테이블만 정의하겠다는 약속을 하면, 여러 테이블이 존재할 수 이 싸는 가정을 제거 하기
    때문에 효율적으로 액세스가 가능하다.

   Create cluster order_item (order_no NUMBER(6))
     SIZE 512
     SINGLE TABLE
     HASHKEYS 1000