논리 데이터 모델링의 마지막에 진행되었던 정규화 작업이 완료되면 데이터 모델은 데이터의 중복 을 최소화하고 데이터의 일관성과 정확성, 안정성을 보장하는 데이터 구조가 완성된다. 이러한 정규 화된 데이터 모델은 시스템의 성능 향상, 개발 과정의 편의성, 운영의 단순화를 위해 정규화의 원칙 들에 위배되는 행위를 의도적으로 수행하게 된다. 이러한 일련의 과정을 반정규화 과정이라 할 수 있 다. 이러한 과정에는 크게 테이블 관점, 칼럼 관점에서의 반정규화 과정이 존재한다. 이러한 작업은 동전의 양면과도 같다. 즉, 반정규화된 데이터 구조는 성능과 관리효율을 증대시킬 수 있지만, 데이 터의 일관성 및 정합성을 해칠 위험을 내포하고 있고, 또한 이를 유지하는데도 그만큼 비용이 발생하 여 지나치면 오히려 성능에도 악영향을 미칠 수 있기 때문에, 데이터 모델의 각 구성 요소인 엔터티, 속성, 관계에 대해 데이터의 일관성과 무결성을 우선으로 할지 데이터베이스의 성능과 단순화에 우 선순위를 둘 것인지를 적절하게 조정하는 것이 중요하고, 또한 다양한 경험을 필요로 하는 작업이다.

테이블 분할

개념

하나의 테이블을 수직 혹은 수평 분할하는 것을 테이블 분할 또는 파티셔닝이라고 한다. 여기에서의 파티셔닝이라는 용어는 데이터베이스 디자인 단계에서의 데이터를 저장하는 방식의 파티셔닝과 는 구분되는 개념이다.

수평 분할(Horizontal Partitioning)

1) 개념

레코드(Record)를 기준으로 테이블을 분할하는 것을 말한다. [그림 4-4-30]의 사례는 EMP 테이 블에 대해 기본키인 ID 칼럼의 값이 10에서 30까지를 EMP 10-30이라는 테이블로 분할하고, 나머 지 40에서 60까지를 EMP 40-60이라는 테이블로 분리했다.

2) 사용 의의

• 하나의 테이블에 데이터가 너무 많이 있고, 레코드 중에서 특정한 덩어리의 범위만을 주로 액세스 하는 경우에 사용한다.
• 분할된 각 테이블은 서로 다른 디스크에 위치시켜 물리적인 디스크의 효용성을 극대화할 수 있다.
• 현재는 이러한 수평 테이블의 분할은 DBMS 차원에서 제공하고 있다. 특히 분할의 방법 다양하게 제공하고 있는 추세이다. 분할의 대표적인 방법으로는 범위 분할, 해쉬 분할, 복합 분할 등의 기법이 사용된다. 이러한 DBMS 차원의 분할은 데이터베이스 디자인에서 자세하게 다루어질 것이다.

수직 분할 (Vertical Partitioning)

1) 개념

하나의 테이블이 가지는 레코드의 개수가 많아서 수평 분할을 한다면 수직 분할은 하나의 테이블이 가지는 칼럼의 개수가 많아지기 때문에 일어난다. 이러한 수직 분할이 일어나는 이유는 다양하다.

• 조회 위주의 칼럼과 갱신 위주의 칼럼으로 나뉘는 경우
• 특별히 자주 조회되는 칼럼이 있는 경우
• 특정 칼럼 크기가 아주 큰 경우
• 특정 칼럼에 보안을 적용해야 하는 경우

그러면 각각의 내용에 대해서 간단하게 살펴본다.

2) 갱신 위주의 칼럼 수직 분할

가) 개념

갱신 위주의 칼럼들을 분할하는 이유는 데이터를 갱신하는 작업이 일어날 때 업데이트하려는 레코드(Record), 즉 레코드에 잠금(Locking)을 수행하기 때문이다. 잠금은 데이터의 무결성을 지키기 위한 수단으로 하나의 프로세스가 특정 데이터 값을 변경하려고 할 때 변경 작업이 끝날 때까지 다른 프로세스가 이 데이터의 값을 변경하지 못하도록 금지하는 것이다.

나) DBMS 버전별 적용 검토

특정 DBMS의 경우에는 이러한 잠금이 레코드 전체에 걸리기 때문에 업데이트가 완료될 때까지 해당 레코드를 사용할 수 없게 하는 요인이 된다. 즉, 몇 개의 갱신 위주의 칼럼에 대한 작업이 나 머지 조회 위주의 칼럼 이용을 방해한다. 이러한 DBMS의 경우에는 이러한 갱신 위주의 칼럼들을 수직 분할하여 사용하는 것이 데이터 사용의 효율성을 증가시킨다.

3) 자주 조회되는 칼럼 분할

가) 개념

테이블의 특정한 칼럼들이 자주 조회된다면 이러한 칼럼들을 분리해서 별도의 테이블로 관리하면 조회되는 쿼리의 작업 성능을 향상시킬 수 있다. 즉 칼럼 수가 아주 많은 테이블에서 주로 사용 되어지는 칼럼들이 극히 일부라고 가정한다면 이러한 일부 칼럼들로 이루어진 테이블을 생성하여 실제 물리적인 I/O의 양을 줄여서 데이터 액세스 성능을 향상시킬 수 있다.

나) 물리적인 DBMS 메커니즘 고려

DBMS는 액세스하고자 하는 모든 데이터를 초기에 물리적인 데이터 파일에서 메모리로 읽어들이게 된다. 또한 한번 읽어들인 데이터는 읽고 나서 바로 지워지는 것이 아니라 일정기간 메모리에 저장되게 된다. 이러한 DBMS의 메커니즘상에서도 보듯이 읽어들이는 데이터의 양이 적다면 즉, 칼럼 수가 적은 테이블을 자주 읽는 작업을 많이 한다면 초기 데이터를 메모리로 적재하는 비용이 절약되고 또한 메모리상에 상대적으로 오래 머무를수 있기 때문에 데이터의 재사용성을 높여주는 효과를 가져올 수 있다.

다) 회원 인증 테이블 사례

[그림 4-4-33]에서와 같이 회원 테이블에서 성명, 암호 칼럼을 분할하여 회원인증이라는 테이 블로 만들었다. 애플리케이션마다 다르기는 하지만 이러한 두 가지 정보들은 회원 인증을 위해서 사이트에 접속할 때마다 반복해서 액세스되는 데이터이다.

4) 특정 칼럼의 크기가 아주 큰 경우 분할

가) 개념

특정 칼럼의 크기가 아주 큰 경우 분할이 일어나는 대개의 경우는 특정 칼럼의 크기가 크다는 것 보다는 특정한 데이터 형식에 기인하는 문형 문자열을 저장하기 위해 지원하는 데이터 타입은 크게는 2GB까지 저장할 수도 있다. 또는 이미지 데이터를 저장할 수도 있다. 이러한 텍스트 및 이미지와 같은 LOB(Large Objects) 데이터 형식을 지원하는 방법은 데이터베이스 시스템마다 약간의 차이는 있다. 하지만, 테이블의 칼럼에 이러한 텍스트 및 이미지 데이터가 포함될 때 성능이 저하될 가능성이 있다. 이것은 백업, 복원과 같은 관리나 프로그래밍과 같은 개발 부분에서 여러 가지 성능 저하 요인으로 작용할 수 있다는 것이다. 그래서 이러한 데이터 형식들을 분리할 수 있다.

나) 회원 사진 테이블 사례

[그림 4-4-34]는 회원의 이미지 데이터를 저장하는 사진 이미지 칼럼을 수직 분할하여 별도의 회원사진 테이블을 생성한 사례이다.

5) 특정 칼럼에 보안을 적용해야 하는 경우의 분할

가) 개념

많은 데이터베이스 시스템이 테이블이나 뷰와 같은 객체들에 대해서는 SELECT, UPDATE, DELETE 등과 같은 권한을 제어할 수 있는 기능을 제공하고 있다. 하지만 테이블 내의 칼럼에 대 해서는 이러한 권한(Permission) 제어 기능을 제공하지 않는다. 이러한 경우 해당 칼럼에 대해 권 한을 제어하기 위해서는 보안을 적용하고자 하는 칼럼을 분리해 이를 별도의 테이블로 만들어 그 테이블에 대한 권한을 제어하기 위한 목적으로 수직 분할을 할 수 있다.

나) 회원 등급 테이블 사례

[그림 4-4-35]에서 회원 등급 칼럼은 서비스 기업의 특정한 사용자들에게만 부여하는 권한이다. 이 권한은 기업이 제공하는 서비스를 제어하고 설정할 수 있도록 하기 때문에 상당히 주의해서 관리되어야만 한다. 그래서 특정 칼럼에 보안을 적용하기 위해서 이를 회원 등급이라는 테이블로 분리하고 이테이블에 대해서 데이터베이스가 제공하는 객체 권한(Object Priviledge)을 조정해서 특정 사용자에게만 권한을 부여할 수 있도록 한다.

중복 테이블 생성

개념

많은 양의 정보들을 자주 Group By, Sum 등과 같은 집계 함수를 이용해서 실시간으로 통계 정보들을 계산해 낼 수 있다. 하지만 대부분 이러한 계산의 유형은 매우 많은 양의 데이터가 대상이 되고, 하나의 테이블이 아닌 여러 개의 테이블에서 필요한 데이터를 추출하는 경우가 대부분이다. 이를 위해서 특정 통계 테이블을 두거나 중복 테이블을 추가할 수 있다.

중복 테이블 생성 판단 근거

• 정규화에 충실하면 종속성, 활용성은 향상되나 수행 속도 증가가 발생하는 경우 고려한다.
• 많은 범위를 자주 처리해야 하는 경우에 고려한다.
• 특정 범위의 데이터만 자주 처리되는 경우에 고려한다.
• 처리 범위를 줄이지 않고는 수행 속도를 개선할 수 없는 경우에 고려한다.
• 요약 자료만 주로 요구되는 경우에 고려한다.
• 추가된 테이블의 처리를 위한 오버헤드를 고려하여 결정한다.
• 인덱스의 조정이나 부분 범위 처리로 유도, 클러스터링을 이용하여 해결할 수 있는지를 철저히 검 토한 후 결정한다.

이와 같은 상황이 존재한다고 판단된다면 논리 데이터 모델에는 존재하지 않지만 물리 데이터 모델에서 중복 테이블을 추가하여 생성할 수 있다.

중복 테이블 유형

중복 테이블에는 다양한 유형이 존재한다. 집계, 진행 테이블 추가를 검토할 수 있는 상황에 대한 예를 들면 다음과 같다.

1) 집계(통계) 테이블 추가

가) 집계 테이블 유형

• 단일 테이블의 GROUP BY
• 여러 테이블의 조인 GROUP BY

나) 집계 테이블 생성시 유의사항

• 로우 수와 활용도를 분석하고 시뮬레이션을 통해서 그 효용성에 대한 면밀한 검토가 선행되어야 한다.
• 집계 테이블에 단일 테이블 클러스터링을 한다면 집계 레벨을 좀더 낮춰 활용도를 높일 수 있는지를 검토해야 한다.
• 클러스터링, 결합 인덱스, 고단위 SQL 을 활용하면 굳이 집계 테이블 없이도 양호한 수행 속도를 낼 수 있다. 이러한 부분도 사전 검토되어야 한다.
• 집계 테이블을 다시 집계, 조인하면 추출할 수 있는지를 검토하여 지나친 집계 테이블을 만들지 않는 것이 좋다.
• 추가된 집계 테이블을 기존 응용 프로그램이 이용할 수 있는지를 찾아 보정시키는 노력이 필요하다.
• 데이터베이스 트리거의 오버헤드에 주의하고 데이터의 일관성 보장에 유의하여야 한다. 즉 집계 테이블과 원본 데이터는 일관성 유지가 매우 중요하다.

2) 진행 테이블 추가

가) 진행 테이블 추가 상황

• 여러 테이블의 조인이 빈번히 발생하며 처리 범위도 넓은 경우
• M:M 관계가 포함된 처리의 과정을 추적, 관리하는 경우
• 검색 조건이 여러 테이블에 걸쳐 다양하게 사용되며 복잡하고 처리량이 많은 경우

나) 진행 테이블 생성시 유의 사항

• 데이터량이 적절하고 활용도가 좋아지도록 기본키를 선정
• 필요에 따라 적절한 추출(Derived) 칼럼을 추가하여 집계 테이블의 역할도 하는 다목적 테이블을 구상
• 다중 테이블 클러스터링이나 조인 SQL을 적절히 이용하면 굳이 진행 테이블을 만들지 않아도 양호한 수행 속도를 낼 수 있는 경우가 많다.

중복 칼럼 생성

개념

논리 데이터 모델링 과정에서 정규화를 통하여 중복 칼럼을 최대한 제거하는 작업을 수행한다. 이렇게 중복 데이터를 제거하는 이유는 여러 가지가 존재하지만 가장 중요한 이유 중에 하나는 데이터 의 정합성을 유지하기 위함이다. 그런데 물리 데이터 모델링 과정에서 이러한 정규화를 어기면서 다시 데이터의 중복(중복 칼럼 생성)을 수행하곤 한다.

중복 칼럼 생성 상황

• 빈번하게 조인을 일으키는 칼럼에 대해서 고려해 볼 수 있다.
• 조인의 범위가 다량인 경우를 온라인화해야 하는 경우처럼 속도가 중요한 칼럼에 대해서는 중복 칼럼을 고려할 수 있다.
• 액세스의 조건으로 자주 사용되는 칼럼에 대해서 고려해 볼 수 있다.
• 자주 사용되는 액세스 조건이 다른 테이블에 분산되어 있어 상세한 조건 부여에도 불구하고 액세스 범위를 줄이지 못하는 경우에 자주 사용되는 조건들을 하나의 테이블로 모아서 조건의 변별성 을 극대화할 수 있다.
• 복사된 칼럼의 도메인은 원본 칼럼과 동일하게 해야 한다. 이것은 데이터의 일관성을 위해서 필수 적인 사항이다.
• 접근 경로의 단축을 위해서 부모 테이블의 칼럼을 자식 테이블에 중복시킬 수 있다.
• 상위 레벨의 테이블에 집계된 칼럼을 추가(M:1 관계)할 수 있다. 즉, 집계 칼럼을 추가한다.
• 하위 레벨의 테이블로 중복 칼럼을 복사(M:1 관계)할 수 있다.
• 연산된 결과를 주로 사용하는 경우에도 미리 연산을 하여 중복 칼럼을 생성할 수 있다.
• 여러 칼럼들의 수 밖에 없는 값이 검색의 조건으로 사용되는 경우에는 연산의 결과를 중복 칼럼으로 생성할 수 있다.
• 여러 개의 로우로 구성되는 값을 하나의 로우에 나열하는 경우이다. 즉 로우로 관리하던 데이터를 칼럼으로 관리하는 경우이다.
• 기본키의 칼럼이 길거나 여러 개의 칼럼으로 구성되어 있는 경우 인위적인 기본키를 추가할 수 있다.

중복 칼럼 생성시 유의사항

• 다중 테이블 클러스터링으로 해결할 수 있는지 검토한다.
• SQL GROUP 함수 이용하여 처리할 수 있는지 검토한다.
• 저장 공간의 지나친 낭비를 고려하여 적절한 대비책을 마련해야 한다.
• 반복 칼럼은 특별한 경우를 제외하고는 절대 사용할 필요가 없고, 있다면 sum(decode.. ) 용법과 같은 SQL 기법 등을 활용하여 이러한 부분을 피할 수 있도록 한다.
• 경우에 따라 상대 테이블의 ROWID를 복사하는 경우가 효과적일 때도 있다.
• 데이터의 일관성 보장에 유의해야 한다. 성능을 향상시키기 위해서 데이터의 일관성을 그르치는 일이 일어나서는 안된다.
• 칼럼의 중복이 지나치게 심하면 데이터 처리의 오버헤드가 발생하게 된다.
• 사용자나 프로그램은 반드시 원본 칼럼만 수정하는 것이 바람직하다.
• 일반적으로 수행 속도를 우려해서 지나치게 많은 중복 칼럼을 생성하고 있는 것이 현실이다. 가능하 면 중복 칼럼을 적게 가져가는 것이 바람직하다.
• 클러스터링, 결합 인덱스, 적절한 SQL을 이용하면 특별한 경우를 제외하고는 거의 해결 가능하기 때문에 이 부분을 먼저 적극적으로 고려해 보는 것이 바람직하다.
• 중복 칼럼을 이용하면 손쉽게 액세스 효율을 개선할 수 있으나 지나친 중복화는 반드시 데이터 일관성 오류 발생의 개연성 증가 및 데이터 처리 오버헤드 증가라는 반대급부가 있다는 것을 염두 에 두고 수행해야 한다.
• JOIN, SUB-QUERY 액세스 경로의 최적화 방안을 보다 철저히 강구해야 한다.