정규화의 문제점

• 정규화는 데이터 조회(SELECT) 시에 조인(Join)을 유발하기 때문에 CPU와 메모리를 많이 사용한다.

  (직원)

  사원번호
  부서코드(FK)
  이름
  전화번호
  주소

  (부서)

  부서코드
  부서명

• 위와 같이 두 개의 테이블로 이루어진 경우 "사원번호, 부서코드, 부서명, 이름, 전화번호, 주소"를 조회하려면 조인을 해야 한다.

조인의 사용

SELECT
	사원번호, 부서코드, 부서명, 이름, 전화번호, 주소
FROM
	직원.부서
WHERE
	직원.부서코드 = 부서.부서코드;

• 위의 테이블은 직원과 부서 테이블에서 부서코드가 같은 것을 찾는 것
• 이것을 프로그램화 한다면 중첩된 루프(Nested Loop)를 사용해야 한다.

중첩된 루프

for(i=0; i<N; i=i+1)
	for(j=0; j<M; j=j+1)
    	if(직원_부서코드[i] == 부서_부서코드[j]){   }

• 위의 예에서 N은 직우너 테이블의 건수이고, M은 부서 테이블의 건수이다.
• 결과적으로 이중으로 for문을 사용해서 비교하는 기능을 만들어야 조인을 할 수 있다.
• 이러한 구조는 데이터양이 증가하면 비교해야 하는 건수도 증가한다.
• 물론 위와 같은 비효율은 실제에서 일어나지는 않는다. 이 문제를 해결하기 위해 인덱스와 옵티마이저가 있는 것이다.
• 결론적으로 조인이 부하를 유발하는 것은 분명하다.
• 정규화의 문제점을 해결하기 위해서 반정규화를 하여 하나의 테이블에 저장한다면 조인을 통한 성능 저하는 해결될 것이다.
• 이런 성능 저하를 해결하기 위해 반정규화가 있는 것이다.

정규화를 사용한 성능 튜닝

• 조인으로 인하여 성능이 저하되는 문제를 반정규화로 해결할 수 있다.

• 반정규화는 데이터를 중복시키기 때문에 또 다른 문제점을 발생시킨다.

  (계좌마스터)

  계좌번호
  계좌명
  계좌등록일자
  계좌구분
  상품구분
  휴면계좌여부
  최종계좌사용정보
  예수금
  평균잔고
  관리지점
  등록단말
  담당자
  고객등급

• 위처럼 계좌마스터의 칼럼이 계속적으로 증가하면 조인이 최소화되기 때문에 조회를 빠르게 할 수 있을 것이다.

• 하지만 너무 많은 칼럼이 추가되면 한 개 행의 크기가 데이터베이스 관리 시스템의 입출력 단위의 블록의 크기(Block Size)를 넘어서게 된다.

• 그렇게 되면 한 개의 행을 읽기 위해서 여러 개의 블록을 읽어야 한다.
  한 행을 읽기 위해서 여러 개의 블록을 읽게 되면 디스크 입출력이 증가하기 때문에 성능이 떨어지게 된다.
  반정규화는 이러한 문제점을 유발할 수 있다.

• 위와 같은 문제가 발생하면 테이블을 분해하는 방법밖에 없다.
  따라서 정규화는 입출력 데이터 양을 줄여서 성능을 향상시킬 수 있는 것이다.