어플리케이션개발/DB

데이터베이스물리설계

안잡아모찌 2018. 11. 7. 01:34

Multi-level indexs

- 저장해야할 정보이 양이 많을 때 , 인덱스의 인덱스를 만들어 멀티레벨로 파일을 저장하는것



빈칸이 존재 하지않는다.

탐색이 매우 빠르지만 , 삽입 삭제 업데이트 연산은 매우 비효율적이다.

일종의 트리구조이다.


Pointer , Key를 갖는다.

q개의 p와 q-1개의 k를 갖는다.

key는 정렬되어 있다.


tree로 변환.

insert시 원소의 갯수가 2개 이상이 되면 split과정을 통해 bottom-up이 된다.

기본구조는 계층구조이다.




Dynamic multi-level indexes using B-tress and B+-trees

  • 많은 멀티레벨 인덱스는 비트리와 비+트리를 이용한다 . 그 이유는 삽입,삭제 문제때문이다.

  • 비트리는 각 데이터 레코드에 포인터가 각각 전부 존재한다.

  • 비+트리는 가장 leaf노드에만 포인터가 존재한다. --> range searching에 유용하다

  • 트리들은 각 노드가 disk block과 상응한다.

  • 삽입,삭제가 매우 효율적이고 overflow시에는 split를 한다.

  • 비+트리는 일반적으로 비트리보다 height가 낮다. 

  • 두 트리의 성능은 비슷하다. 각 장점이 따로 있지만 비+트리를 일반적으로 사용한다.




모든 노드가 data의 위치정보를 갖고 있다.

만약 찾고자하는 인덱스가 루트이면 해당위치에서 바로 data record block을 찾을 수 있다.

하나의 노드에 2개의 키와 5개의 주소값 정보를 갖고 있다.






**range searching의 경우

만약 5-10까지 찾는다.

B tree는 전부 찾아야한다.

B+ tree는 모든 정보가 leaf노드에 저장되어 있기 때문에 leaf에서 순차적으로 찾으면 된다.




O(h+1) leaf노드에 최종의 정보들이 다 있다.

포인터 저장 X, 키만 저장 --> 저장정보량이 적다.






<Physical database for relational databases>

 

Physical DB design에 영향을 끼치는 요소들


1. DB의 쿼리와 트랜잭션을 분석 해야한다. ( 쿼리는 DML 질의 , 트랜잭션은 update같은 기능)

트랜잭션과 작동을 업데이트 하기 위해서 아래의 정보들이 필요하다.

  1. 업데이트될 파일

  2. 각 파일에서 작동의 타입 (삽입, 삭제, 갱신)

  3. 삭제나 업데이트를 위한 선택 조건이 명시된 속성들

  4. 조인조건이나 다수의 테이블 혹은 객체와 연결되어 명시되어 있는 속성들

  5. 업데이트에 의해 값이 변화될 속성들

 - C,D에 명시된 속성은 접근 구조의 정의를 위해 후보로 사용할 수 있지만, E에 명시된 속성은 접근구조를 피하기 위한 후보이다.

2. 쿼리 및 트랜잭션 호출의 예상 빈도 분석
3. 쿼리와 트랜잭션의 시간제약을 분석
4. 업데이트의 예상빈도를 분석
5. 속성에 대한 유일성 제약조건을 분석


 - 파일들은 쿼리에 의해서 접근되어야 한다.

 - selection conditions , join conditions 를 잘해야 attribute 실행시간이 빠르다. (검색)

 - 업데이트 기능은 업데이트 작동에 의해 속성의 값들이 변경된다.

 - selection conditions를 잘해야 한다. (업데이트) 

 - 자주 업데이트 되는 인덱스도 바꿔야 하므로 자주 찾는 속성은 access path를 만들지 않아야 한다.

 - 빈번한 업데이트 파일은 access path를 만들어 주지 않는다.(일반적으로)

 - 실행이 자주 많이 걸리는 순으로 해결을 해준다.

 - time critical : time constraint가 반드시 있어야 하는 질의를 우선순으로 처리해준다.

 - key의 후보군은 access method를 만들어준다.


Physical DB design for relational DB --> 인덱스는 꼭 만들어야함(어떻게 만들어야 하는지를 고민해야함)

 - 인덱싱에 대한 디자인 결정

 - 어떤 속성에 인덱스를 만들것인가?

 - clustered index를 사용할 것인가?

 - hash index를 할 것인가 tree index(B+)를 할것인가?

 - dynamic hashing 을 할것인가 ?
 -->Dynamic hashing , B tree, B+ tree


Physical design alternatives.

 - DB space ? Fixed(access가 빠름) / Variable(공간효율적사용) length record?

 - Unordered file VS ordered file VS hash file

 - what attribute to index on?

 - which types of index?





***

Nomalization : 정규화의 목적은 현실세계의 정보들을 네모로 쪼갠다고 가정했을 때, 효율성과 정확성의 trade-off이다.
                    논리적으로 연관된 속성들을 테이블로 쪼개는 것이고 중복을 최소화해서 이상현상을 줄이는 것이다.

De-normalization : 빈번한 쿼리와 트랜잭션의 성능을 향상시키는 것이다. 다시 table을 붙인다. --> 실행시간의 증진

저작자표시 비영리 (새창열림)