테이블

테이블은 행(Row)과 칼럼(Column)으로 구성되는 가장 기본적인 데이터베이스 객체로 데이터베 이스 내에서 모든 데이터는 테이블을 통해 저장된다. 상용 DBMS들은 데이터를 저장하는 방식이 상 이한 여러 종류의 테이블을 제공하고 있으므로 테이블 설계 시에 성능, 확장성, 가용성 등을 고려해 테이블 유형을 선택하여야 한다.

테이블, 칼럼 등 데이터베이스에서 사용되는 객체의 명명 규칙은 표준화 관점에서 별도로 정의한다.

테이블(Table)

상용 DBMS에서 제공되는 테이블들은 제품마다 명칭이나 기능이 다르다. 테이블은 데이터의 저장 형태, 파티션 여부, 데이터의 유지 기간 등에 따라 다양하게 분류할 수 있다.

Heap-Organized Table

대부분의 상용 DBMS에서 표준 테이블로 사용하고 있는 테이블 형태로, 테이블 내에서 로우의 저 장 위치는 특정 속성의 값에 기초하지 않고 해당 로우가 삽입될 때 결정된다.

Clustered Index Table

Primary Key 값이나 인덱스 키 값의 순서로 데이터가 저장되는 테이블을 클러스터 인덱스라 한다. 클러스터 인덱스는 B 트리의 리프 노드에 RID 대신 데이터 페이지가 존재하는 구조이다.
데이터 페이지가 검색하고자 하는 키 값의 순서로 정렬되어 있기 때문에 프리 패치가 가능하고, 인덱 스에서 테이블로 탐침하는 경로가 단축되기 때문에 일반적인 인덱스를 이용하는 것보다 데이터를 더 빠르게 액세스할 수 있다. 그러나 데이터가 삽입될 때 키 순서에 따라 지정된 위치에 저장되어야 하 므로 데이터 페이지를 유지하는 데 많은 비용이 발생한다. 그리고 Heap 테이블로 사용하던 중에 클 러스터 인덱스로 전환하게 되면 데이터 페이지의 개편이 일어나고 관련된 모든 인덱스의 RID가 클 러스터 인덱스의 PK로 변경되어야 하므로 많은 오버헤드가 발생한다.

Partitioned Table

파티셔닝은 대용량의 테이블을 파티션이라는 보다 작은 논리적인 단위로 나눔으로써 성능이 저하 되는 것을 방지하고 관리를 보다 수월하게 하고자 하는 개념으로, 파티셔닝을 하는 방식에 따라 범 위 분할(Range Partitioning), 해쉬 분할(Hash Partitioning), 결합 분할(Composite Partitioning) 등이 있다.

파티셔닝은 대용량 데이터를 관리하는 데 아주 효과적이지만 무조건 파티션만 한다고 해서 파티션 이 가지고 있는 이점을 모두 취할 수 있는 것은 아니다. 잘못된 인덱스가 오히려 처리 속도에 나쁜 영향을 미치듯이 파티션 키를 어떻게 구성하느냐에 따라 많은 비효율을 초래할 수도 있으므로 다 음과 같은 전략적인 관점에서 파티션 키가 결정되어야 한다.

첫째, 액세스 유형에 따라 파티셔닝이 이루어질 수 있도록 파티션 키를 선정해야 한다. 분포도가 나빠 인덱스를 사용할 수 없을 경우 테이블 스캔을 해야 하는데, 대상 테이블이 대용량일 경우 절 대적인 작업량 때문에 성능적인 문제를 해소하기 어렵게 된다. 이럴 경우 검색의 범위가 파티션의단위와 일치하면 인덱스를 이용하지 않고도 원하는 범위의 데이터를 읽을 수 있게 된다.

둘째, 이력 데이터를 파티셔닝할 경우 파티션의 생성주기와 소멸주기를 일치시켜야 한다. 이력을 관리하는 데이터는 데이터 관리 전략 및 업무 규칙에 따라 그 수명이 다하게 되면 별도의 저장장치 에 기록되고 데이터베이스에서 삭제된다. 즉, 이력 데이터는 활용 가치에 따라 생성주기와 소멸주 기가 결정되므로 그 주기에 따라 데이터베이스를 정리해야만 한다. 만약 삭제해야 하는 데이터가 여러 파티션에 분산되어 있다면 그 데이터를 추출하여 삭제하는 데 많은 노력과 시간이 필요할 것 이다. 하지만 파티션이 데이터의 생성주기 및 소멸주기와 일치하면 파티션을 대상으로 작업을 수 행하므로 관리가 용이하게 된다.

External Table

외부 파일을 마치 데이터베이스 안에 존재하는 일반 테이블 형태로 이용할 수 있는 데이터베이스 객체이다. 데이터웨어하우스(DW, Data Warehouse)에서 ETL(Extraction, transformation, Loading) 작업 등에 유용한 테이블이다.

Temporary Table

트랜잭션이나 세션별로 데이터를 저장하고 처리할 수 있는 임시 테이블이다. 저장된 데이터는 트 랜잭션이 종료되면 휘발되며, 다른 세션에서 처리되는 데이터는 공유할 수 없다. 절차적인 처리를 하기 위해 임시적으로 사용할 수 있는 테이블이다.

칼럼(Column)

칼럼은 테이블을 구성하는 요소로, 데이터 타입(Data Type)과 길이(Length)로 정의된다. 데이터 타입은 데이터 일관성을 유지하는 가장 기본적인 기능이다. 표준화된 도메인을 정의하였다면 그에 따라 데이터 타입과 데이터 길이를 정의한다.

DBMS는 문자, 숫자, 시간, 대형 객체 등을 정의할 수 있는 내장 데이터 형식과 행, 컬렉션, 사용 자 정의 데이터 형식 등의 확장 데이터 형식을 지원하고 있다.

비교 연산에서 두 칼럼이 서로 데이터 타입과 길이가 다르면 DBMS는 내부적으로 데이터 타입을 변형한 후 비교 연산을 수행하므로 칼럼이 서로 참조 관계일 경우는 가능한 한 동일한 데이터 타입과 길이를 사용해야 한다. 만약 서로 다른 데이터 타입을 사용하게 되면 조인이나 비교 연산 시 인덱스 가 있어도 사용할 수 없게 되거나 실행 계획을 예측할 수 없게 된다.

칼럼 데이터 타입에 따라 물리적인 칼럼 순서 조정이 필요하다.

• 고정 길이 칼럼이고 NOT NULL인 칼럼은 선두에 정의한다.
• 가변 길이 칼럼을 뒤편으로 배치한다.
• NULL 값이 많을 것으로 예상되는 칼럼을 뒤편으로 배치한다.

이는 DBMS마다 차이는 있지만 값이 변경될 때 체인(Chain) 발생을 억제하고 저장 공간의 효율적 인 사용을 위해 필요하다.

오라클의 경우 인덱스를 구성하고 있는 모든 칼럼의 값이 NULL인 로우는 인덱스에 저장하지 않는 다. 그리고 NULL과의 비교는 IS NULL 혹은 IS NOT NULL을 통해서만 가능하다. 오라클의 NULL 처리 장점은 인덱스의 저장 공간을 절약하고 테이블을 전체 범위 스캔으로 쉽게 유도할 수 있다.SQL 서버는 NULL도 하나의 값으로 인식하고 관리하므로 인덱스를 구성하는 모든 칼럼 값이 NULL인 경우도 인덱스에 저장된다. 그리고 NULL과의 비교도 ansi_nulls 옵션을 적용하면 equal 연산자로도 비교가 가능하다.

set ansi_nulls off를 실행하면 where col1 = null과 같은 형태의 비교가 가능해지고, set ansi_nulls on을 실행하면 오라클과 마찬가지로 is null 또는 is not null 형태의 비교만 가능하게 된다. SQL 서버의 NULL 처리 장점은 is null 또는 is not null 같은 조건으로도 인덱스를 사용할 수 있다는 점이다.

데이터 타입과 길이 지정 시 다음과 같은 사항을 고려한다.

• 가변 길이 데이터 타입은 예상되는 최대 길이로 정의한다.
• 고정 길이 데이터 타입은 최소의 길이를 지정한다
• 소수점 이하 자리 수의 정의는 반올림되어 저장되므로 정확성을 확인하고 정의한다..

DBMS마다 다소 차이는 있지만 문자열을 비교하는 방법은 크게 두 가지로 구분할 수 있다. 하나 는 길이가 작은 칼럼 끝에 공백을 추가하여 길이를 같게 한 후 비교하는 방식이고, 다른 하나는 공백 을 추가하지 않고 비교하는 방식이다.

오라클의 경우 비교하는 칼럼이 모두 CHAR, NCHAR, 문자 상수인 경우나 사용자 정의 함수에 의하 여 리턴된 값일 경우에는 공백 추가 후 비교하는 방식을 사용하고, 비교하는 값 중에 VARCHAR2 혹은 NVARCHAR2가 존재하면 공백 추가 없이 비교를 수행한다. 이때 비교하는 칼럼의 길이가 서로 다르면 짧은 칼럼의 길이까지 비교하고 길이가 긴 칼럼을 크다고 판단하므로 CHAR와 VARCHAR2를 비교할 경우 VARCHAR2의 칼럼이 길이보다 짧은 값이 입력된 데이터는 동일한 데이터 값이 들어 있어도 서 로 다른 값으로 인식한다.

SQL 서버는 문자열을 처리하는 방식이 오라클과 약간 차이가 있다. 오라클의 경우 CHAR 타입은 공백이 추가되어 저장되고, VARCHAR 타입은 공백 추가 없이 저장하지만 SQL 서버는 ANSI_PADDING이라는 옵션에 의하여 공백 추가 여부를 결정한다. ON으로 설정하면 오라클과 동일 한 방식으로 저장되지만 OFF로 설정하면 CHAR와 VARCHAR 타입 모두 저장된 문자열 값에서 후행 공백이 지워진다. SQL 서버에서 ANSI_ PADDING을 ON으로 설정하고 CHAR와 VARCHAR를 비 교할 경우 오라클과 달리 길이보다 짧은 값이 입력된 데이터도 동일한 데이터로 인식한다.

다른 두 데이터 타입을 비교할 경우 오라클과 SQL 서버는 내부적으로 우선순위가 높은 데이터 타 입으로 변환하여 비교를 수행한다. 예를 들어 CHAR 데이터 타입과 NUMBER 데이터 타입을 비교 할 경우 NUMBER 데이터 타입이 CHAR 데이터 타입보다 우선순위가 높기 때문에 내부적으로 CHAR 데이터 타입을 NUMBER 데이터 타입으로 변환하여 비교를 수행한다. 이때 문자열 칼럼에 알파벳이 등이 섞여있어 변환이 불가능하면 SQL 오류가 발생한다.

그렇지만 다른 두 데이터 타입이 Like로 비교되면 위의 규칙과는 반대의 상황이 발생한다.

위 SQL에서 사원번호가 NUMBER 타입일 경우 앞에서 언급한 변환 규칙을 적용하면 문자열 ‘200902%’를 숫자로 변환해야 하지만 변환이 불가능한 문자를 포함하고 있다. 변환도 불가능하지 만 Like가 문자열을 비교하기 위한 연산자이므로 문자를 숫자로 변환하면 Like 비교가 불가능해진 다. 즉, Like 비교 시에는 위의 규칙을 적용하지 않고 비교 연산에 참여하는 대상을 문자열로 변환하 여 비교를 수행한다.

테이블 설계시 고려사항

• 칼럼 데이터 길이 합이 1 블록(Block) 사이즈보다 큰 경우 수직 분할을 고려한다. 1 블록 사이즈보 다 크면 체인이 발생하여 속도 저하 현상을 유발한다.
• 칼럼 길이가 길고 특정 칼럼의 사용 빈도 차이가 심한 경우이거나 각기 다른 사용자 그룹이 특정 칼럼만을 사용하고 같이 처리되는 경우가 드문 경우는 수직 분할을 고려한다.
• 수직 분할을 고려할 때는 분할되는 테이블이 하나의 트랜잭션에 의해 동시에 처리되는 경우나 조 인이 빈번히 발생되는 경우가 없어야 한다.
• “주문일자”, “계약일자”등과 같이 검색 조건으로 빈번하게 사용되는 칼럼은 시간 데이터 타입을 사용하면 비교 연산을 하거나 조인일 때 동일 데이터 타입으로 가공하는 경우가 일어날 수 있으므 로 액세스 측면만 고려한다면 문자 타입을 사용하는 것이 더 효율적이다.
• 사건의 일자나 시간을 기록하는 속성을 문자 타입으로 정의하면 일자 범위를 벗어나는 값이 입력 될 수 있으므로 처리 시 문제가 발생하지 않도록 하려면 오류 데이터들을 클린징하거나 제외하기 위한 복잡한 로직을 추가해야 한다. 이러한 문제와 더불어 데이터 품질의 중요성이 대두되면서 최 근에는 시간을 기록하는 속성인 경우, 시간 데이터 타입을 선택하는 추세이다.

테이블(Table)과 테이블스페이스(Table space)

테이블은 테이블스페이스라는 논리적인 단위를 이용하여 관리하고, 테이블스페이스는 물리적인 데이터 파일을 지정하여 저장된다. 테이블, 테이블스페이스, 데이터 파일로 분리하여 관리함으로써 논리적인 구성이 물리적인 구성에 종속되지 않고 투명성을 보장할 수 있다.

테이블스페이스(파일 그룹)는 저장되는 내용에 따라 테이블용, 인덱스용, 임시(Temporary)용을 구분하여 설계한다. 이는 백업 단위나 공간 확장 단위인 물리적인 파일 크기를 적정하게 유지하기 위 해서이다. 따라서 테이블스페이스는 데이터 용량을 관리하는 단위로 이용된다.

다음은 일반적인 데이터용/인덱스용 테이블스페이스 설계 유형들이다.

• 테이블이 저장되는 테이블 스페이스는 업무별로 지정한다.
• 대용량 테이블은 독립적인 테이블 스페이스를 지정한다.
• 테이블과 인덱스는 분리하여 저장한다.
• LOB 타입 데이터는 독립적인 공간을 지정한다.

용량 설계

용량 설계는 다음과 같은 목적으로 진행된다.

• 정확한 데이터 용량을 예측하여 저장 공간을 효과적인 사용과 저장 공간에 대한 확장성을 보장하 여 가용성을 높이기 위함
• H/W 특성을 고려하여 디스크 채널 병목을 최소화하기 위함
• 디스크 I/O를 분산하여 접근 성능을 향상하기 위함
• 테이블이나 인덱스에 맞는 저장 옵션을 지정하기 위함

테이블 저장 옵션에 대한 고려사항은 다음과 같다.

• 초기 사이즈, 증가 사이즈
• 트랜잭션 관련 옵션
• 최대 사이즈와 자동 증가

저장 용량 설계 절차는 다음과 같다.

• 용량 분석 - 데이터 증가 예상 건수, 주기, 로우 길이(Row Length)등을 고려함
• 오브젝트별 용량 산정 - 테이블, 인덱스에 대한 크기
• 테이블스페이스별 용량 산정 - 테이블스페이스별 오브젝트 용량의 합계
• 디스크 용량 산정 - 테이블스페이스에 따른 디스크 용량과 I/O 분산 설계