힌트

힌트는 일종의 지시문 입니다. SQL 문장에 힌트를 추가하여 Tibero의 질의 최적화기(Optimizer)에 특정 행동을 지시하거나 질의 최적화기의 실행 계획을 변경합니다.

질의 최적화기가 항상 최적의 실행 계획을 수립할 수는 없으므로 개발자가 질의 최적화기의 실행 계획을 직접 수정할 수 있는 방법을 마련한 것이 바로 힌트입니다. SQL 문장의 한 블록당 힌트는 하나만 올 수 있으며, SELECT, UPDATE, INSERT, DELETE 절 바로 뒤에 위치해야 합니다.

힌트사용예시

(DELETE|INSERT|SELECT|UPDATE) /*+ hint [hint] ... */ 
또는
(DELETE|INSERT|SELECT|UPDATE) --+ hint [hint] ...

힌트 사용 시 주의점

• 힌트는 반드시 DELETE, INSERT, SELECT, UPDATE 절 뒤에만 올 수 있습니다.

• '+' 기호는 반드시 주석 구분자('/*' 또는 '--') 바로 뒤에 공백 없이 붙여 써야 합니다.

• 힌트와 '+' 기호 사이에 공백은 있거나 없어도 됩니다.

• 문법에 맞지 않는 힌트는 주석으로 취급되며, 오류는 발생하지 않습니다.

힌트 종류 (구성요소 별)

질의 변형

최적화 방법

접근 방법

조인 순서

조인 방법

병렬처리

실체화 뷰

기타

질의 변형

질의 변형(Query Transformation)에 대한 힌트를 사용하여 Tibero의 질의 변형 방식에 영향을 줄 수 있습니다.

NO_QUERY_TRANSFORMATION

NO_QUERY_TRANSFORMATION는 질의 변형기(Query Transformer)가 전체 쿼리에 대해 변형을 실행 하지 않도록 지시하는 힌트입니다. Tibero에서는 쿼리 변형이 자동으로 수행되며, 최적화된 형태로 쿼리를 변형하여 실행계획을 생성합니다. NO_QUERY_TRANSFORMATION 힌트를 사용한다면 디폴트로 수행되는 쿼리 변형을 막을 수 있습니다

문법

NO_MERGE

NO_MERGE는 질의 변형기(Query Transformer)가 특정 뷰에 대해 뷰 병합을 하지 않도록 지시하는 힌트 입니다. Tibero에서는 뷰 병합이 디폴트로 수행되며, 뷰가 병합이 가능할 경우 상위의 질의 블록과 결합해 하나의 질의 블록을 형성합니다. NO_MERGE 힌트를 사용하면 이렇게 디폴트로 수행되는 뷰의 병합을 막을 수 있습니다.

문법

예시

SELECT *
FROM T1, (SELECT /*+ NO_MERGE */ * FROM T2, T3 WHERE T2.A = T3.B) V 
WHERE T1.C = V.D

위의 예에서처럼 NO_MERGE 힌트는 병합되기를 원하지 않는 뷰의 질의 블록에 명시합니다.

힌트가 없다면 뷰가 병합되어 질의 최적화기에서 테이블 T1, T2, T3에 대한 조인 순서와 조인 방법을 고려하게 되지만, 위와 같이 힌트가 있을 경우는 뷰가 병합되지 못하기 때문에 T2와 T3가 먼저 조인되고 그 이후에 T1이 조인됩니다.

UNNEST

UNNEST는 질의 변형기가 특정 부질의(Subquery)를 언네스팅하도록 지시하는 힌트입니다. Tibero는 부질의 언네스팅을 디폴트로 수행하지만 특정 쿼리만 언네스팅 하기위해서는 초기화 파라미터에서 언네스팅을 해제하면 됩니다. 그러면 UNNEST 힌트를 이용할 수 있습니다. UNNEST 힌트는 부질의 블록에 명시합니다.

문법

NO_UNNEST

NO_UNNEST는 질의 변형기가 특정 부질의에 대해 언네스팅을 수행하지 않도록 지시하는 힌트입니다. Tibero는 부질의 언네스팅을 디폴트로 수행하며 언네스팅이 가능한 경우 부질의를 조인으로 변환합니다. 이 때 NO_UNNEST 힌트를 사용해서 언네스팅을 막을 수 있습니다. NO_UNNEST 힌트는 부질의 블록에 명시합니다.

문법

NO_JOIN_ELIMINATION

NO_JOIN_ELIMINATION는 질의 변형기(Query Transformer)가 불필요한 조인을 찾아서 제거하지 않도록 지시하는 힌트입니다. Tibero에서는 디폴트로 질의 결과를 생성하는데 필요하지 않은 조인들을 찾아서 제거하며, NO_JOIN_ELIMINATION 힌트를 사용하면 이를 막을 수 있습니다.

문법

예시

SELECT /*+ NO_JOIN_ELIMINATION */ T2.FK, T2.A FROM T1, T2 WHERE T2.FK = T1.PK

위의 예처럼 T2의 컬럼을 요청하였을 때 T1과 T2 사이에 참조 관계가 정의되어 있다면 T1과 조인을 하지 않아도 조건절에 주어진 T2.FK = T1.PK는 T2.FK가 NULL이 아닌 한 참임을 알 수 있습니다. 질의 변환기는 이처럼 필요하지 않은 조인을 찾아 제거하는데 NO_JOIN_ELIMINATION 힌트를 적용하면 이러한 기능을 막을 수 있습니다.

STAR_TRANSFORMATION

STAR_TRANSFORMATION는 스타 변형 (STAR TRANSFORMATION)이 가능할 경우 변형을 시도하도록 지시하는 힌트입니다. Tibero에서는 디폴트로 스타 변형을 하지않도록 하는데, STAR_TRANSFORMATION 힌트를 사용하면 이를 사용할 수 있습니다.

문법

예시

SELECT /*+ STAR_TRANSFORMATION */ s.* FROM S, T1, T2
               WHERE S.C1 = T1.C1 AND S.C2 = T2.C2

스타 스키마(STAR SCHEMA)를 사용하는 데이터베이스 환경에서 위의 예처럼 쿼리를 쓰면 스타 변형 을 할 수 있습니다. 이 변형은 기존 INDEX JOIN으로만 풀린 플랜에서 BITMAP KEY ITERATION을 포함한 플랜으로 풀리게 하여 더 효율적인 결과를 얻게 합니다.

최적화 방법

최적화 방법이 적용된 힌트를 사용하여 처리 과정과 결과 표시를 최적화할 수 있습니다. 만약 최적화 방법이 적용된 힌트가 사용된 질의가 있다면 해당 질의에 대해서는 통계 정보와 초기화 파라미터의 최적화 방법 (OPTIMIZER MODE)의 값이 없는 것처럼 처리됩니다.

ALL_ROWS

ALL_ROWS는 최소한의 리소스를 사용하여 전체 결과에 대한 처리량이 가장 많도록 처리과정의 최적화 방법을 선택하는 힌트입니다.

문법

FIRST_ROWS

FIRST_ROWS는 첫 로우부터 파라미터로 입력된 번호의 로우까지 가장 빠르게 보여줄 수 있도록 결과 표시의 최적화 방법을 선택하는 힌트입니다.

문법

접근 방법

접근 방법이 적용된 힌트는 질의 최적화기가 특정 접근 방법의 사용이 가능한 경우, 그 방법을 사용하도록 명시합니다. 만일 힌트에서 명시한 방법을 사용할 수 없는 경우에는 질의 최적화기는 그 힌트를 무시힙니다.

힌트에 명시하는 테이블명은 SQL 문에서 사용하는 이름과 동일해야 합니다. 즉, 테이블 이름에 대한 별칭을 사용하였다면, 테이블 이름 대신에 별칭을 사용해야 합니다. SQL 문에서 테이블 이름에 스키마 이름을 포함하여 명시하였더라도 힌트에서는 테이블 이름만을 명시해야 합니다.

FULL

FULL은 명시한 테이블을 스캔할 때, 전체 테이블을 스캔하도록 지시하는 힌트입니다. WHERE 절에 명시된 조건식에 맞는 인덱스가 있더라도 전체 테이블 스캔을 사용합니다.

문법

INDEX

INDEX는 명시한 테이블을 스캔할 때, 명시한 인덱스를 사용하여 인덱스 스캔을 하도록 지시하는 힌트입니다.

문법

NO_INDEX

NO_INDEX는 명시한 테이블을 스캔할 때, 명시한 인덱스를 사용하는 인덱스 스캔을 하지 않도록 지시하는 힌트입니다. 만일 NO_INDEX 힌트와 INDEX 또는 INDEX_ASC, INDEX_DESC 힌트가 동일한 인덱스를 명시한다면 질의 최적화기는 이 두 힌트를 모두 무시합니다.

문법

INDEX_ASC

INDEX_ASC는 명시한 테이블을 스캔할 때, 명시한 인덱스를 사용하여 인덱스 스캔을 하도록 지시하는 힌트입니다. 만일 인덱스 범위 스캔을 사용하는 경우에는 인덱스를 오름차순으로 스캔하도록 합니다. 현재 Tibero의 인덱스 스캔의 기본 동작이 오름차순이기 때문에 INDEX_ASC는 INDEX와 동일한 작업을 수행합니다. 분할된 인덱스의 경우 분할된 각 영역 내에서 오름차순으로 스캔합니다.

문법

INDEX_DESC

INDEX_DESC는 명시한 테이블을 스캔할 때, 명시한 인덱스를 사용하여 인덱스 스캔을 하도록 지시하는 힌트입니다. 만일 인덱스 범위 스캔을 사용하는 경우에는 인덱스를 내림차순으로 스캔하도록 합니다. 분할된 인덱스의 경우 분할된 각 영역 내에서 내림차순으로 스캔합니다.

문법

INDEX_FFS

INDEX_FFS는 명시한 테이블에 대해 명시한 인덱스를 사용하여 빠른 전체 인덱스 스캔(Fast Full Index Scan)을 사용하도록 지시하는 힌트입니다.

문법

NO_INDEX_FFS

NO_INDEX_FFS는 명시한 테이블에 대해 명시한 인덱스를 사용하는 빠른 전체 인덱스 스캔을 사용하지 않도록 지시하는 힌트입니다.

문법

INDEX_RS

INDEX_RS는 명시한 테이블에 대해 명시한 인덱스를 사용하여 범위 인덱스 스캔(Range Index Scan)을 사용하도록 지시하는 힌트입니다.

문법

NO_INDEX_RS

NO_INDEX_RS는 명시한 테이블에 대해 명시한 인덱스를 사용하는 범위 인덱스 스캔을 사용하지 않도록 지시하는 힌트입니다.

문법

INDEX_SS

INDEX_SS는 명시한 테이블에 대해 명시한 인덱스를 사용하여 인덱스 스킵 스캔(Index Skip Scan)을 사용하도록 지시하는 힌트입니다.

문법

NO_INDEX_SS

NO_INDEX_SS는 명시한 테이블에 대해 명시한 인덱스를 사용하는 인덱스 스킵 스캔을 사용하지 않도록 지시하는 힌트입니다.

문법

INDEX_JOIN

INDEX_JOIN은 명시한 테이블에 대해 명시한 두 개 이상의 힌트를 사용하여, 테이블을 스캔할 때 자체 조 인(Self Join)을 사용하도록 지시하는 힌트입니다.

문법

조인 순서

LEADING, ORDERED는 조인 순서를 결정하는 힌트입니다. LEADING 힌트가 ORDERED보다 질의 최적화기를 선택할 수 있는 폭이 넓어서 LEADING을 사용하는 것이 좋습니다.

LEADING

LEADING은 조인에서 먼저 조인되어야 할 테이블의 집합을 명시하는 힌트입니다. LEADING 힌트가 먼저 조인될 수 없는 테이블을 포함하는 경우 무시됩니다. 또한 LEADING 힌트끼리 충돌하는 경우에는 LEADING, ORDERED 힌트가 모두 무시된다. 만일 ORDERED 힌트가 사용되는 경우에는 LEADING 힌트는 모두 무시됩니다.

문법

ORDERED

ORDERED는 테이블을 FROM 절에 명시된 순서대로 조인하도록 지시하는 힌트입니다. 질의 최적화기는 조인의 결과 집합의 크기에 대한 정보를 추가로 알고 있습니다. 사용자가 그 정보를 통해 질의 최적화기의 조인 순서를 명확히 알고 있을 경우에만 ORDERED 힌트를 사용하는 것이 좋습니다.

문법

조인 방법

조인 방법이 적용된 힌트는 한 테이블에 대해서만 조인 방법을 지시합니다. 조인 방법이 적용된 힌트는 명시한 테이블이 조인의 내부 테이블로 사용될 경우에만 참조됩니다. 명시한 테이블을 외부 테이블로 사용하는 경우에는 조인 방법이 적용된 힌트는 무시됩니다.

USE_NL

USE_NL은 명시한 테이블을 다른 테이블과 조인하는 경우 중첩 루프 조인을 사용하도록 지시하는 힌트입니다.

문법

NO_USE_NL

NO_USE_NL은 명시한 테이블을 다른 테이블과 조인하는 경우 중첩 루프 조인을 사용하지 않도록 지시 하는 힌트입니다. 하지만, 특수한 경우에는 이 힌트가 주어졌더라도 질의 최적화기에서 중첩 루프 조인을 사용하는 플랜을 생성할 수 있습니다.

문법

USE_NL_WITH_INDEX

USE_NL_WITH_INDEX는 명시한 테이블을 다른 테이블과 조인하는 경우 중첩 루프 조인을 사용하도록 지시하는 힌트입니다. 이때 명시한 테이블에 대한 접근은 명시한 인덱스와 두 테이블에 대한 조인 조건을 이용하여 이뤄져야 합니다. 만일 인덱스를 사용할 수 없는 경우라면 힌트는 무시됩니다.

문법

USE_MERGE

USE_MERGE는 명시한 테이블을 다른 테이블과 조인하는 경우 합병 조인을 사용하도록 지시하는 힌트 입니다.

문법

NO_USE_MERGE

NO_USE_MERGE는 명시한 테이블을 다른 테이블과 조인하는 경우 합병 조인을 사용하지 않도록 지시 하는 힌트입니다.

문법

USE_HASH

USE_HASH는 명시한 테이블을 다른 테이블과 조인하는 경우 해시 조인을 사용하도록 지시하는 힌트입니다.

문법

NO_USE_HASH

NO_USE_HASH는 명시한 테이블을 다른 테이블과 조인하는 경우 해시 조인을 사용하지 않도록 지시하는 힌트입니다.

문법

HASH_SJ

HASH_SJ는 부질의를 언네스팅할 때 해시방법을 이용한 세미조인으로 하도록 지시하는 힌트입니다.

문법

HASH_AJ

HASH_AJ는 부질의를 언네스팅할 때 해시방법을 이용한 안티조인으로 하도록 지시하는 힌트입니다.

문법

MERGE_SJ

MERGE_SJ는 부질의를 언네스팅할 때 머지방법을 이용한 세미조인으로 하도록 지시하는 힌트입니다.

문법

MERGE_AJ

MERGE_AJ는 부질의를 언네스팅할 때 머지방법을 이용한 안티조인으로 하도록 지시하는 힌트입니다.

문법

NL_SJ

NL_SJ는 부질의를 언네스팅할 때 네스티드 루프 방법을 이용한 세미조인으로 하도록 지시하는 힌트입니다.

문법

NL_AJ

NL_AJ는 부질의를 언네스팅할 때 네스티드 루프 방법을 이용한 안티조인으로 하도록 지시하는 힌트입니다.

문법

SWAP_JOIN_INPUTS

SWAP_JOIN_INPUTS는 해시 조인을 수행하는 경우 명시한 테이블을 사용하여 해시 테이블을 빌드하도록 지시하는 힌트입니다.

문법

NO_SWAP_JOIN_INPUTS

NO_SWAP_JOIN_INPUTS는 해시 조인을 수행하는 경우 조인 순서가 바뀌는 경우, 명시한 테이블이 해시 테이블로 빌드되지 않도록 지시하는 힌트입니다.

문법

병렬 처리

PARALLEL

PARALLEL은 지정한 개수의 스레드를 사용해 질의의 수행을 병렬로 진행하도록 지시하는 힌트입니다.

문법

NO_PARALLEL

NO_PARALLEL은 질의의 수행을 병렬로 진행하지 않도록 지시하는 힌트입니다.

문법

PQ_DISTRIBUTE

PQ_DISTRIBUTE는 조인을 포함한 질의의 병렬 처리에서 조인될 로우의 분산 방법을 지시하는 힌트입니다. 분산 방법으로는 HASH-HASH, BROADCAST-NONE, NONE-BROADCAST, NONE-NONE이 있으며 특정한 분산 방법을 선택함으로써 병렬 처리에서 조인의 성능을 향상시킬 수 있습니다.

문법

아래는 각각의 속성에 대한 설명입니다.

실체화 뷰

REWRITE

REWRITE는 해당 질의 블록에서 비용의 비교 없이 실체화 뷰를 사용하여 질의의 다시 쓰기를 하도록 지시하는 힌트입니다. 따라서 최종으로는 REWRITE 힌트가 사용된 질의 블록만 다시 쓰기를 한 결과와 모든 블록에서 다시 쓰기를 한 결과의 비용을 비교해서 더 좋은 쪽을 질의 최적화기가 선택하게 됩니다.

실체화 뷰의 목록이 명시된 경우에는 목록에 있는 실체화 뷰만 사용하여 질의의 다시 쓰기를 시도합니다.

문법

NO_REWRITE

NO_REWRITE는 해당 질의 블록에서는 질의의 다시 쓰기를 하지 않도록 지시하는 힌트입니다.

문법

MATERIALIZE

MATERIALIZE는 With 절 안에 있는 Subquery를 실체화 뷰(Materialized View)로 만들도록 지시하는 힌트입니다.

문법

INLINE

INLINE은 With 절 안에 있는 Subquery를 실체화 뷰(Materialized View)로 만들지 않도록 지시하는 힌트입니다.

문법

기타

APPEND

APPEND는 DML 문장에서 직접 데이터 파일에 추가하는 삽입 방법 즉 Direct-Path 방식을 수행하도록 지시하는 힌트입니다.

Direct-Path 방식은 일반적인 삽입 방법과 달리 항상 새로운 데이터 블록을 할당받아서 데이터 삽입을 수행하며, 버퍼 캐시를 이용하지 않고 직접 데이터 파일을 추가하기 때문에 성능 향상에 많은 이점이 있습니다.

문법

APPEND_VALUES

APPEND_VALUES는 VALUES절을 사용하는 INSERT 문에서 직접 데이터 파일에 추가하는 삽입 방법 즉 Direct-Path 방식을 수행하도록 지시하는 힌트입니다.

Direct-Path 방식은 일반적인 삽입 방법과 달리 항상 새로운 데이터 블록을 할당받아서 데이터 삽입을 수 행하며, 버퍼 캐시를 이용하지 않고 직접 데이터 파일을 추가하므로 일괄 삽입에 사용하면 성능 향상에 많은 이점이 있습니다.

문법

NOAPPEND

NOAPPEND는 DML 문장에서 Direct-Path 방식을 수행하지 않도록 지시하는 힌트입니다.

문법

IGNORE_ROW_ON_DUPKEY_INDEX

single table INSERT문에서만 사용이 가능합니다. 유일키 제약조건을 위배하면 에러를 발생시키지 않고 삽입하던 로우를 롤백하고 다음 로우부터 삽입을 재개합니다.

인덱스를 명시하지 않은 경우, 여러 개의 인덱스를 명시한 경우, 명시된 인덱스가 UNIQUE 속성을 갖지 않는 경우에는 힌트이지만 오류를 발생시킵니다. 이 힌트를 명시하면 APPEND, PARALLEL 힌트는 무시됩니다.

문법

CARD

CARD는 쿼리 최적화 할 때에 지정 테이블의 Cardinality를 주어진 값을 이용하여 계산하도록 지시하는 힌트입니다.

문법

MONITOR

MONITOR는 쿼리를 수행할 때 쿼리 수행 정보를 모으도록 지시하는 힌트입니다.

문법

NO_MONITOR

NO_MONITOR는 쿼리를 수행할 때 쿼리 수행 정보를 모으지 않도록 지시하는 힌트입니다.

문법

USE_CONCAT

USE_CONCAT은 OR 조건문을 UNION ALL로 쪼개어 OR 양쪽에 대하여 별도의 플랜 노드를 만들어 합치는 OR expansion된 플랜이 만들어지도록 강제하는 힌트입니다.

문법

NO_EXPAND

NO_EXPAND는 OR expansion을 막음으로써 OR 조건문이 필터로 보존된 플랜을 만들도록 강제하는 힌트입니다.

문법

RESULT_CACHE

Query 결과를 Cache에 저장하기 위한 Result Cache를 사용하도록 지시하는 힌트입니다. RESULT_CACHE_MODE 초기 파라미터 값이 "MANUAL"일 때만 유효하며, "FORCE"일 때는 힌트의 존재 여부와 관계없이 모든 Query 결과를 Result Cache에 저장합니다.

문법

NO_SUBQUERY_CACHE

NO_SUBQUERY_CACHE는 특정 질의 블록에 대해 부질의 결과를 캐싱하지 않도록 강제하는 힌트입니다. Tibero는 가능하다면 부질의 결과 캐싱 기능을 사용하는 실행 계획을 수립합니다. 이때 이 힌트를 사용하여 특정 질의 블록에 대해 부질의 결과 캐싱을 강제로 막을 수 있습니다. NO_SUBQUERY_CACHE 힌트는 대상 질의 블록에 명시하며, 부질의의 실행 계획 최상위 노드로서 CACHE가 생기지 않습니다.

문법

예시

SELECT * FROM T1
WHERE EXISTS (SELECT /*+ NO_SUBQUERY_CACHE */ * FROM T2 WHERE T1.A = T2.A)

위에 예처럼 EXISTS절 질의 블록에 힌트를 명시할 경우, 해당 블록에 대해 부질의 결과를 캐싱하는 기능을 사용하지 않도록 강제합니다.

OPT_PARAM

쿼리가 수행되는 도중 초기화 환경변수를 바꿔서 수행하는 힌트입니다. 예를 들어 수행되는 쿼리에

/*+OPT_PARAM(OPTIMIZER_MODE FIRST_ROWS_1)*/ 이라는 힌트를 준다면, 해당 쿼리가 수행되는 동안에 한해서 OPTIMIZER_MODE가 FIRST_ROWS_1로 설정되어 수행됩니다.

문법

스키마 객체

데이터베이스는 여러 객체로 구성됩니다. 각 객체는 '데이터베이스 > 사용자 > 스키마 > 스키마 객체'의 순 으로 포함 관계를 갖고 하나의 데이터베이스는 여러 사용자가 공유하고 있습니다. 또한 사용자 중에는 데이터베이스를 관리하기 위해 특별한 권한을 부여 받고 있는 DBA가 있습니다.

스키마는 사용자가 소유한 객체의 모임(Collection)입니다. Tibero에서는 한 사용자가 하나의 스키마만을 정의할 수 있고, 스키마의 이름은 항상 사용자의 이름과 동일합니다. 이러한 스키마에 포함된 객체를 스키마 객체라 합니다. SQL 표준에서 정의한 스키마 객체 외에, 데이터베이스 시스템에 따라 추가적인 스키마 객체 를 제공하고 있습니다.

Tibero에서 제공하는 스키마 객체

• 테이블(Table)

• 인덱스(Index)

• 뷰(View)

• 시퀀스(Sequence)

• 동의어(Synonym)

테이블

테이블은 관계형 데이터베이스의 기본 저장 단위입니다. 다른 모든 스키마 객체는 테이블을 중심으로 정의됩니다. 테이블은 2차원 행렬(Matrix)의 형태를 갖습니다. 테이블은 하나 이상의 컬럼으로 구성되며 각 컬럼은 고유의 데이터 타입을 갖습니다. 하나의 테이블은 0개 이상의 로우를 포함힙니다. 각 로우는 각 컬럼에 해당하는 값을 갖습니다.

아래는 회사 직원의 정보를 저장하고 있는 EMP 테이블의 예시입니다.

EMP 테이블

    EMPNO   ENAME       ADDR                 SALARY   DEPTNO
---------- ------------ ---------------- ---------- --------
       35   John        Houston              30000         5
       54   Alicia      Castle               25000         4
       27   Ramesh      Humble               38000         5
       69   James       Houston              35000         4

위의 테이블은 'EMPNO, ENAME, ADDR, SALARY, DEPTNO'의 다섯 개의 컬럼으로 구성되며, 네 개의 로우를 포함하고 있습니다. 테이블을 구성하는 컬럼 정보는 거의 변경되지 않으나, 테이블에 포함된 로우의 개수는 수시로 변경될 수 있습니다.

컬럼의 데이터 타입 중에는 문자형과 같이 최대 길이를 미리 정해야 하는 것도 있고, NUMBER 타입과 같이 정밀도와 스케일을 정해야 하는 것도 있습니다. 일부 컬럼에 대해서는 기본값을 선언할 수도 있습니다.

데이터 타입에 대한 상세한 내용은 “데이터 타입”에서 확인할 수 있습니다.

테이블 전체 또는 일부 컬럼에 무결성 제약조건(Integrity Constraints)을 선언할 수 있습니다. 무결성 제약조건은 테이블에 어떠한 로우가 삽입되든 항상 만족되어야 합니다. 예를 들어 테이블 EMP의 한 컬럼 SALARY 에 대하여 다음과 같은 조건을 선언할 수 있습니다.

SALARY >= 0

직원의 연봉이 0보다 작을 수 없으므로, 이러한 조건을 사용해 잘못된 데이터의 입력을 미리 막을 수 있습니다.

하나의 테이블에 무결성 제약조건을 선언할 수도 있고, 두 개의 테이블에 참조 무결성(Referential Integrity) 제약조건을 선언할 수도 있습니다.

아래는 회사의 부서 정보를 저장하는 DEPT 테이블의 예시입니다.

DEPT 테이블

    DEPTNO DNAME        LOC
---------- ------------ ----------------
         1 Accounting   Houston
         4 Research     Spring
         5 Sales        Houston

회사의 모든 직원이 하나의 특정 부서에 반드시 소속되어야 한다면, EMP 테이블 예시에서 테이블 EMP의 컬럼DEPTNO의 값은 반드시 위 예시에서의 DEPT 테이블의 DEPT의 컬럼 DEPTNO에 존재하는 값이어야 합니다.

인덱스

인덱스는 테이블과 별도의 저장공간을 이용하여 그 테이블의 특정 컬럼을 빠르게 검색 할 수 있게 하는 데이터 구조입니다. 테이블의 소유자는 어떤 컬럼에 대해 하나 이상의 인덱스를 생성할 수 있습니다.

아래는 인덱스에 대한 설명입니다.

자동 인덱싱

Tibero에서는 모든 테이블의 기본 키(Primary Key) 컬럼에 대해 자동으로 인덱스를 생성합니다.

기본 키 컬럼이란 테이블 내의 특정 로우를 유일하게 식별할 수 있는 값을 갖는 컬럼을 의미합니다.

하나의 테이블 내에서 어떤 로우도 다른 로우와 동일한 기본 키 컬럼 값을 가질 수 없습니다. 위의 EMP 테이블과 DEPT 테이블 예시에서는 각각 컬럼 EMPNO와 DEPTNO가 기본 키 컬럼이 될 수 있습니다.

컬럼의 중복 허용

인덱스는 컬럼 값의 중복 유무에 관계 없이 생성할 수 있습니다.

예를 들어 테이블 DEPT의 컬럼 DEPTNO 와 같이 중복이 없는 컬럼이나 테이블 EMP의 컬럼 DEPTNO와 같이 중복이 있는 컬럼에 대해서도 인덱스를 생성할 수 있습니다.

복수 컬럼 허용

인덱스는 하나의 컬럼뿐만 아니라 둘 이상의 컬럼 값을 하나로 접합하여 생성할 수도 있습니다.

예를 들어 테이블 EMP의 컬럼 ENAME과 ADDR 값을 합쳐서 인덱스를 만들 수 있습니다. 이러한 인덱스는 둘 이상의 컬럼이 동시에 검색 대상이 될 확률이 높은 경우에 유용합니다.

인덱스의 적용

사용자가 인덱스를 생성하더라도 바로 사용되지는 않습니다.

인덱스가 생성되면 SQL 질의를 수행할 때, 질의 최적화기가 인덱스를 사용할 때와 사용하지 않을 때의 실행 효율성을 비교하고, 더 효율적인 방향 으로 실제 질의를 실행하므로 질의대상 테이블에 대해서 생성된 인덱스를 이용할 것인지, 어떤 컬럼에 대해서 생성된 인덱스를 이용할 것인지는 데이터베이스 시스템에 의하여 자동적으로 결정됩니다.

인덱스의 관리

인덱스의 관리도 데이터베이스 시스템에서 자동적으로 이뤄집니다.

인덱스가 생성된 후에 테이블에 하나의 로우가 삽입되거나 갱신, 삭제되면 그 테이블에 대하여 생성된 모든 인덱스에서 그 로우에 대한 삽입, 갱신, 삭제가 이뤄집니다.

인덱스의 제거

인덱스가 더 이상 필요하지 않으면 언제라도 그 인덱스를 제거할 수 있습니다.

인덱스를 너무 많이 생성해 놓으면 테이블에 대한 갱신이 이루어질 때마다 인덱스에도 함께 반영해 주어야 하므로 성능 저하의 원인이 될 수 있으므로, 불필요한 인덱스는 제거하는 것이 바람직합니다.

뷰

뷰는 SQL 문장에 이름을 붙인 것으로, 빈번히 수행되는 질의의 결과를 테이블 형태로 이용할 수 있도록 정의한 것입니다. 뷰는 테이블 또는 다른 뷰를 이용하여 정의할 수 있으며, SQL 문장 내에서 일반 테이블과 동일하게 이용할 수 있습니다. 뷰가 정의된 테이블을 기반 테이블(base table)이라 합니다.

뷰를 정의하는 이유는, 하나의 테이블을 여러 사용자가 함께 접근할 수 있지만 사용자에 따라 테이블 내용의 일부를 숨김으로써 정보 보안을 유지하고자 하는 것입니다.

아래는 뷰에 대한 설명입니다.

뷰 병합

데이터베이스 시스템 내에서 뷰는 질의 문장을 문자열 형태로 관리합니다. 만약 뷰를 포함한 SQL 문장이 입력되면, 데이터베이스 시스템은 그 문장을 뷰를 포함하지 않는 기반 테이블에 대한 SQL 문장으로 변환합니다. 이러한 과정을 뷰 병합이라고 합니다.

뷰 활용 및 권한

뷰가 이용되는 경우는 위에서와 같이 빈번한 질의를 단순화하고자 하는 경우 이외에, 뷰를 정의한 기반 테이블의 일부만을 드러내고자 하는 경우에도 사용됩니다. 예를 들어 테이블 EMP의 내용 중에서 컬럼 SALARY의 내용을 관리직이 아닌 일반 직원에게 드러내고 싶지 않은 경우에, 일반 직원이 테이블 EMP 를 직접 접근하지 못하고 뷰를 통해서만 접근하도록 할 수 있습니다.

이러한 경우 스키마 객체를 접근할 수 있는 권한(Authority)과 연관됩니다. 즉, 뷰를 정의한 사용자가 일 반 직원에게 그 뷰를 접근할 권한만을 부여하고 뷰가 정의된 기반 테이블 EMP를 접근할 권한을 부여하지 않으면, 일반 직원에게는 테이블 EMP 내의 데이터 중에서 그 뷰에 의해 볼 수 있는 일부만을 드러냅니다.

시퀀스

시퀀스는 유일한 연속적인 값을 생성해 낼 수 있는 스키마 객체입니다. 이 값은 보통 기본 키 또는 유일 키에 값을 채워 넣을 때 사용되며 항상 시퀀스의 이름에는 의사 컬럼을 붙여서 사용합니다.

SQL 문에서는 아래와 같은 의사 컬럼을 통해 시퀀스의 값을 읽어들입니다.

의사 컬럼과 함께 시퀀스를 사용하는 예시

seq1.currval 
seq2.nextval

위치에 따른 시퀀스 의사 컬럼의 사용 여부

시퀀스를 생성할 때 초기 값과 증감치가 결정됩니다.

NEXTVAL 의사 컬럼을 통해 최초로 시퀀스에 접근하면, 시퀀스는 초기값을 반환합니다. 이후 NEXTVAL을 사용할 때마다 시퀀스의 값은 증감치 만큼 증가하고, 새로 증가된 값을 반환합니다. CURRVAL 의사 컬럼은 항상 시퀀스의 현재 값을 반환하며, 이것은 가장 마지 막에 사용된 NEXTVAL이 반환한 값과 같습니다.

CURRVAL 의사 컬럼을 사용하기 전에 적어도 한 번 이상은 시퀀스에 NEXTVAL을 사용해서 초기화를 시켜야 합니다. SQL 문장에 사용된 NEXTVAL 의사 컬럼은 SQL 문장이 처리하는 행의 단위별로 시퀀스의 값 을 증가시킵니다.

시퀀스 값을 증가시키는 행

• 최상위 레벨의 SELECT 문이 출력하는 행

• INSERT ... SELECT 문에서 SELECT 문이 선택하는 행

• CREATE TABLE ... AS SELECT 문에서 SELECT 문이 선택하는 행

• UPDATE 문이 갱신하는 각각의 행

• VALUES 절을 포함한 INSERT 문이 삽입하는 행

한 행에 두 번 이상의 NEXTVAL이 나왔을 경우 시퀀스 값은 처음 한 번만 증가되며, 증가된 그 값이 다음 위치에 동일하게 사용됩니다. NEXTVAL과 CURRVAL이 한 행에 동시에 나왔을 경우 시퀀스 값은 역시 한 번만 증가되며, NEXTVAL에 사용된 값이 CURRVAL에 동일하게 사용됩니다.

동의어

동의어는 특정 스키마 객체에 정의하는 일종의 별칭(Alias) 입니다. 대개 긴 이름을 갖는 스키마 객체에 대하여 짧은 이름의 동의어를 정의하거나, 특별한 용도의 스키마 객체에 대하여 동의어를 정의합니다.

아래는 동의어에 대한 설명입니다.

동의어와 뷰의 차이점

동의어는 긴 이름 대신 사용한다는 점에서 뷰와 같습니다. 그러나 뷰는 하나의 완전한 SQL 문장에 대한 것이고, 동의어는 하나의 스키마 객체에 한정된다는 차이점이 있습니다. 또한 동의어는 뷰와 다르게 접근 권한이 별도로 설정되지 않습니다. 만약 특정 스키마 객체에 대한 접근 권한이 있다면 그에 대한 동의어에 대해서도 접근 권한을 갖게 됩니다.

동의어의 사용 설정

동의어는 기본적으로 동의어를 정의한 사용자만이 사용할 수 있으나, 다른 모든 사용자도 함께 사용하도록 공용으로 정의할 수도 있습니다. 이렇게 모든 사용자가 사용할 수 있는 동의어를 공유 동의어라고 합니다. Tibero에서는 DBA와 일반 사용자가 데이터 사전(Data Dictionary)의 정보를 쉽게 접근할 수 있도록, 여러가지 시스템 뷰를 정의하고 각각에 대한 동의어를 정의하고 있습니다.

스키마 객체의 이름

스키마 객체에 따라 사용자가 각각의 부분 또는 전체에 이름을 부여할 수 있거나 꼭 부여해야만 하는 경우가 있습니다. 테이블, 테이블의 컬럼, 인덱스, 무결성 제약조건, 테이블 파티션, 테이블 서브 파티션, 인덱스 파 티션, 인덱스 서브 파티션, 패키지와 패키지 내의 함수와 프러시저 등이 이에 해당합니다.

SQL 문장에서 스키마 객체의 이름을 명시할 때는 '따옴표 있는 식별자' 또는 '따옴표 없는 식별자'를 사용합니다.

• 따옴표 있는 식별자는 큰따옴표(" ")로 시작해서 큰따옴표로 종결됩니다.

• 따옴표 없는 식별자는 큰따옴표로 여닫지 않습니다.

스키마 객체에 이름을 부여할 때는 위 두개 중 어떤 것을 사용해도 무방합니다.

따옴표 없는 식별자는 대소 문자를 구별하지 않으며, 모두 대문자로 간주되어 처리되며, 따옴표 있는 식별자는 대소문자를 구분합니다.

예를 들어 아래의 경우는 모두 서로 다른 식별자입니다.

department 
"department" 
"Department"

아래의 경우는 모두 서로 깉은 식별자입니다.

department 
DEPARTMENT 
"DEPARTMENT"

식별자를 기술할 때 지켜야 할 규칙은 아래와 같습니다.

• 길이는 30byte를 넘지 않습니다.

• 예약어는 따옴표 없는 식별자가 될 수 없습니다. 따옴표를 적용하여 예약어를 식별자로 만들 수 있으나, 권장하지는 않습니다.

• 따옴표 없는 식별자는 알파벳, 한글, 숫자, 언더바( _ ), $, #만 사용할 수 있습니다. 다만, 숫자, '$', '#'는 첫 글 자로 올 수 없습니다.

• 따옴표 있는 식별자는 공백을 포함한 어떤 문자라도 쓸 수 있습니다. 다만 큰따옴표(" ")는 사용할 수 없습니다.

• 하나의 네임스페이스 안에서 서로 다른 두 객체가 동일한 이름을 가질 수 없습니다.

• 하나의 테이블 내의 서로 다른 컬럼은 동일한 이름을 가질 수 없습니다.

• 서로 다른 테이블에 속해 있는 컬럼은 동일한 이름을 가질 수 있습니다.

• 한 패키지 내의 서로 다른 프러시저나 함수는 인자의 개수나 데이터 타입이 다른 경우에 한해서 동일한 이름을 가질 수 있습니다.

스키마 객체 관련 문법

SQL 문장에서 스키마 객체와 객체의 구성 요소를 명시하는 방법을 설명합니다.

문법

구성 요소

스키마 객체를 찾는 과정

SQL 문장 내에 명시된 스키마 객체를 찾는 과정은 아래와 같습니다.

1. SQL 문장의 문맥에 따라 네임스페이스가 결정됩니다.

2. 결정된 네임스페이스 내에서 객체를 찾습니다.

3. 객체의 타입이 SQL 문장 내의 객체가 명시된 위치에서 사용될 수 있는지 확인합니다.

4. 사용될 수 없는 타입이라면 에러를 반환합니다.

위의 스키마 객체를 찾는 과정을 설명하는 예시는 아래와 같습니다.

SELECT * FROM employees;

위의 SQL 문장을 입력했다고 가정하고, 위의 문장을 예로 스키마 객체를 찾는 과정 입니다. 각각의 숫자는 스키마 객체를 찾는 과정에서 각 단계를 설명할 때 사용된 숫자와 동일한 단계입니다.

1. 위의 SQL 문장은 스키마를 명시하지 않았으므로 사용자가 소유한 스키마를 네임스페이스로 결정합니다.

2. 결정된 네임스페이스에서 즉, 사용자가 소유한 스키마 내에서 employees라는 객체가 존재하는지 확인합니다. 만일 확인 못했다면 employees라는 공유 동의어가 존재하는지 확인합니다. 공유 동의어에도 employees 라는 객체가 없다면 오류를 반환합니다. 만약 찾은 객체가 동의어라면 동의어의 정의를 따라가서 동의어가 정의하고 있는 스키마 객체가 동의어인지 아닌지 확인합니다. 동의어라면 또 그 동의어의 정의를 따라갑니다. 동의어가 아닌 스키마 객체가 나올 때까지 이 과정을 반복합니다.

3. 해당 객체를 찾았으면 그 객체가 테이블인지 아니면 뷰인지 확인합니다. FROM 절에는 테이블 또는 뷰만 위치할 수 있습니다.

4. 만약 테이블 또는 뷰가 아닌 다른 객체라면 오류를 반환합니다.

원격 데이터베이스의 객체를 찾는 과정

원격 데이터베이스에 있는 객체를 명시하기 위해서는 객체 이름 다음에 "@" 표시와 함께 데이터베이스 링크(Database link) 이름을 명시합니다.

SQL 문장에서 데이터베이스 링크를 사용했을 경우 해당 객체를 찾는 과정은 아래과 같습니다.

1. 사용자의 스키마에서 해당 이름을 갖는 데이터베이스 링크가 존재하는지 확인합니다.

2. 존재하지 않으면 공유 데이터베이스 링크 중에서 해당 이름의 존재를 확인합니다.

3. 해당 데이터베이스 링크 존재를 확인했다면, 그 데이터베이스 링크를 이용해 원격 데이터베이스의 객체에 접근을 시도합니다.

4. 해당 원격 데이터베이스에서 스키마 객체를 찾는 과정은 "스키마 객체를 찾는 과정"과 동일합니다.