Notes

DB 08. View와 System Catalog

관계 데이터베이스의 View 개념, 갱신 가능성, System Catalog와 Oracle Data Dictionary의 역할을 정리한 학습 노트

Published: May 31, 2026
Updated: May 31, 2026
Area: Databases
Type: concept
Series: Database Systems
Category: Notes

databaseviewsystem-catalogoracledata-dictionaryquery-optimization

개요

관계 데이터베이스에서 View는 기본 릴레이션으로부터 유도된 가상 릴레이션이다. 사용자는 View를 실제 테이블처럼 조회할 수 있지만, 일반적으로 View 자체가 데이터를 독립적으로 저장하는 것은 아니다. DBMS는 View의 정의를 System Catalog에서 찾아 기본 릴레이션에 대한 질의로 변환한다.

System Catalog는 데이터베이스 객체와 구조에 대한 정보를 저장하는 메타데이터 저장소이다. Oracle에서는 이를 Data Dictionary라고 부르며, 사용자는 USER_xxx, ALL_xxx, DBA_xxx 형태의 데이터 사전 View를 통해 테이블, 컬럼, View, Index, 권한, 통계 정보를 확인할 수 있다.

1. View의 핵심 개념

1.1 View는 Derived Relation이다

관계 데이터베이스에서 View는 다른 릴레이션으로부터 유도된 릴레이션이다.

구분	의미
`Base relation`	실제 데이터가 저장된 기본 릴레이션
`View`	기본 릴레이션에 대한 `SELECT`문으로 정의된 가상 릴레이션
`Derived relation`	기존 릴레이션에서 유도된 릴레이션
`Virtual relation`	실제 테이블처럼 보이지만 독립 저장 테이블은 아닌 릴레이션

View는 ANSI/SPARC 3단계 아키텍처의 외부 View와 구분해야 한다. ANSI/SPARC의 외부 View는 특정 사용자가 바라보는 데이터베이스 전체 구조에 가깝지만, 관계 DBMS에서의 View는 하나의 가상 릴레이션을 의미한다.

1.2 View의 직관: Dynamic Window

View는 기본 릴레이션을 바라보는 **동적인 창(dynamic window)**으로 이해할 수 있다.

View는 SELECT문으로 정의된다.
사용자는 View를 테이블처럼 조회할 수 있다.
기본 릴레이션의 데이터가 변경되면 View를 통해 보이는 결과도 달라질 수 있다.
View는 보안, 질의 단순화, 데이터 독립성 확보에 사용된다.

예를 들어 EMPLOYEE 테이블에서 3번 부서 사원만 보여주는 View를 만들면, 사용자는 전체 EMPLOYEE 테이블을 보지 않고도 필요한 부분만 조회할 수 있다.

2. View와 Snapshot의 차이

Snapshot은 어느 시점의 SELECT 결과를 기본 릴레이션 형태로 저장한 것이다. View와 Snapshot은 모두 SELECT 결과와 관련 있지만 동작 방식이 다르다.

구분	View	Snapshot
성격	동적	정적
결과 저장	일반적으로 저장하지 않음	특정 시점의 결과를 저장
원본 변경 반영	원본 변경이 조회 결과에 반영될 수 있음	생성 시점의 결과를 유지
비유	창문	사진

View는 기본 릴레이션을 실시간으로 바라보는 창에 가깝고, Snapshot은 특정 시점의 상태를 저장해 둔 사진에 가깝다.

3. View 정의 문법

View는 CREATE VIEW문으로 정의한다.

CREATE VIEW 뷰이름 [(애트리뷰트(들))]
AS SELECT문
[WITH CHECK OPTION];

3.1 애트리뷰트 이름을 생략할 수 있는 경우

View 이름 뒤의 애트리뷰트 목록을 생략하면, SELECT절에 나열된 애트리뷰트 이름이 View의 애트리뷰트 이름으로 사용된다.

CREATE VIEW EMP_PLANNING
AS SELECT E.EMPNAME, E.TITLE, E.SALARY
FROM EMPLOYEE E, DEPARTMENT D
WHERE E.DNO = D.DEPTNO
AND D.DEPTNAME = '기획';

이 경우 View의 컬럼은 다음과 같다.

EMP_PLANNING(EMPNAME, TITLE, SALARY)

3.2 애트리뷰트 이름을 명시해야 하는 경우

다음과 같은 경우에는 View의 애트리뷰트 이름을 명시하는 것이 필요하다.

SELECT절에 산술식이 포함된 경우
SELECT절에 집단 함수가 포함된 경우
Join 결과에서 서로 다른 릴레이션의 애트리뷰트 이름이 중복되는 경우
결과 컬럼 이름이 명확하지 않은 경우

예를 들어 부서별 평균 급여 View는 AVG(SALARY)라는 표현을 그대로 컬럼명으로 쓰기 어렵기 때문에 별도 이름을 붙인다.

CREATE VIEW EMP_AVGSAL (DNO, AVGSAL)
AS SELECT DNO, AVG(SALARY)
FROM EMPLOYEE
GROUP BY DNO;

4. 단일 릴레이션 기반 View 예제

EMPLOYEE 릴레이션에서 3번 부서에 근무하는 사원들의 사원번호, 이름, 직책만 보여주는 View를 정의할 수 있다.

CREATE VIEW EMP_DNO3 (ENO, ENAME, TITLE)
AS SELECT EMPNO, EMPNAME, TITLE
FROM EMPLOYEE
WHERE DNO = 3;

이 View의 의미는 다음과 같다.

View 컬럼	원본 컬럼
`ENO`	`EMPNO`
`ENAME`	`EMPNAME`
`TITLE`	`TITLE`

즉, EMPLOYEE 테이블 전체가 아니라 다음 조건을 만족하는 일부 데이터만 View로 제공한다.

행 조건: DNO = 3
열 조건: EMPNO, EMPNAME, TITLE만 포함

이 방식은 행 제한과 열 제한을 동시에 수행할 수 있기 때문에 보안과 사용자별 정보 제공에 유용하다.

5. Join 기반 View 예제

두 릴레이션을 Join해서 View를 정의할 수도 있다. 예를 들어 EMPLOYEE와 DEPARTMENT를 Join하여 기획부 사원의 이름, 직책, 급여만 보여주는 View를 만들 수 있다.

CREATE VIEW EMP_PLANNING
AS SELECT E.EMPNAME, E.TITLE, E.SALARY
FROM EMPLOYEE E, DEPARTMENT D
WHERE E.DNO = D.DEPTNO
AND D.DEPTNAME = '기획';

이 View는 내부적으로 다음 관계를 사용한다.

EMPLOYEE.DNO = DEPARTMENT.DEPTNO

그리고 기획부만 남기기 위해 다음 조건을 적용한다.

DEPARTMENT.DEPTNAME = '기획'

사용자는 복잡한 Join 조건을 매번 작성하지 않고도 EMP_PLANNING View를 조회할 수 있다.

6. View 조회 시 DBMS 내부 과정

사용자가 View를 조회하면 DBMS는 View 자체를 실제 테이블처럼 그대로 읽는 것이 아니라, System Catalog에서 View의 정의를 찾아 기본 릴레이션에 대한 질의로 변환한다.

예를 들어 다음 질의가 있다고 하자.

SELECT *
FROM EMP_DNO3
WHERE TITLE = '사원';

EMP_DNO3는 다음과 같이 정의되어 있다.

CREATE VIEW EMP_DNO3 (ENO, ENAME, TITLE)
AS SELECT EMPNO, EMPNAME, TITLE
FROM EMPLOYEE
WHERE DNO = 3;

DBMS는 View 질의를 기본 릴레이션 질의로 변환할 수 있다.

SELECT EMPNO, EMPNAME, TITLE
FROM EMPLOYEE
WHERE TITLE = '사원'
AND DNO = 3;

View 조회 과정은 다음 순서로 정리할 수 있다.

System Catalog에서 View 정의를 검색한다.
View와 기본 릴레이션에 대한 접근 권한을 검사한다.
View에 대한 질의를 기본 릴레이션에 대한 동등한 질의로 변환한다.
변환된 질의를 최적화하고 실행한다.

7. View의 장점

7.1 복잡한 질의 단순화

기획부에 근무하는 사원 중 직책이 부장인 사원의 이름과 급여를 검색한다고 하자. 기본 릴레이션만 사용하면 Join 조건을 포함해야 한다.

SELECT E.EMPNAME, E.SALARY
FROM EMPLOYEE E, DEPARTMENT D
WHERE D.DEPTNAME = '기획'
AND D.DEPTNO = E.DNO
AND E.TITLE = '부장';

하지만 EMP_PLANNING View를 사용하면 질의가 간단해진다.

SELECT EMPNAME, SALARY
FROM EMP_PLANNING
WHERE TITLE = '부장';

View는 반복적으로 사용되는 복잡한 Join 조건이나 필터 조건을 감추고, 사용자에게 단순한 인터페이스를 제공한다.

7.2 데이터 무결성 보장

WITH CHECK OPTION을 사용하면 View를 통해 삽입 또는 수정되는 데이터가 View의 조건을 만족하도록 강제할 수 있다.

CREATE VIEW EMP_DNO3 (ENO, ENAME, TITLE)
AS SELECT EMPNO, EMPNAME, TITLE
FROM EMPLOYEE
WHERE DNO = 3
WITH CHECK OPTION;

이 View는 DNO = 3인 사원만 보여준다. 따라서 View를 통해 데이터를 수정한 결과가 DNO = 3 조건을 만족하지 않으면 DBMS가 갱신을 거부할 수 있다.

WITH CHECK OPTION은 View 조건을 벗어나는 삽입 또는 수정을 막는 무결성 장치로 이해하면 된다.

7.3 데이터 독립성 제공

View는 데이터베이스 내부 구조가 변경되어도 기존 응용 프로그램의 변경을 줄이는 데 사용할 수 있다.

예를 들어 기존 EMPLOYEE 릴레이션이 다음과 같다고 하자.

EMPLOYEE(EMPNO, EMPNAME, TITLE, MANAGER, SALARY, DNO)

이후 설계 변경으로 두 개의 릴레이션으로 분해되었다고 하자.

EMP1(EMPNO, EMPNAME, SALARY)
EMP2(EMPNO, TITLE, MANAGER, DNO)

기존 응용 프로그램이 계속 EMPLOYEE를 조회해야 한다면, 다음과 같이 EMPLOYEE라는 이름의 View를 정의할 수 있다.

CREATE VIEW EMPLOYEE
AS SELECT E1.EMPNO, E1.EMPNAME, E2.TITLE, E2.MANAGER,
          E1.SALARY, E2.DNO
FROM EMP1 E1, EMP2 E2
WHERE E1.EMPNO = E2.EMPNO;

이렇게 하면 내부 구조는 EMP1, EMP2로 바뀌었지만, 외부에서는 여전히 EMPLOYEE라는 릴레이션을 사용하는 것처럼 보일 수 있다.

7.4 데이터 보안 제공

View는 기본 릴레이션의 일부 애트리뷰트 또는 일부 투플만 사용자에게 보여주는 보안 메커니즘으로 사용할 수 있다.

예를 들어 EMPLOYEE 테이블에서 SALARY를 숨기고 싶다면 다음과 같은 View를 만들 수 있다.

CREATE VIEW EMP_PUBLIC AS
SELECT EMPNO, EMPNAME, TITLE, MANAGER, DNO
FROM EMPLOYEE;

그리고 사용자에게 EMPLOYEE가 아니라 EMP_PUBLIC에 대한 SELECT 권한만 부여하면 된다.

접근 대상	사용자가 볼 수 있는 정보
`EMPLOYEE`	전체 사원 정보
`EMP_PUBLIC`	`SALARY`를 제외한 사원 정보

7.5 동일 데이터에 대한 여러 관점 제공

같은 데이터라도 사용자 그룹마다 필요한 정보는 다르다.

사용자 그룹	필요한 View 예시
일반 직원	급여를 제외한 사원 정보
인사팀	전체 사원 정보
부서장	자기 부서 사원 정보
회계팀	급여 및 비용 관련 정보

View를 사용하면 같은 기본 릴레이션을 여러 관점으로 제공할 수 있다.

8. View의 갱신 가능성

View에 대한 INSERT, UPDATE, DELETE는 결국 기본 릴레이션에 대한 갱신으로 변환되어야 한다. 하지만 모든 View가 갱신 가능한 것은 아니다.

8.1 단일 릴레이션 View의 갱신

다음 View에 데이터를 삽입한다고 하자.

INSERT INTO EMP_DNO3
VALUES (4293, '김정수', '사원');

이 삽입은 실제로는 EMPLOYEE 테이블에 대한 삽입으로 변환되어야 한다.

INSERT INTO EMPLOYEE
VALUES (4293, '김정수', '사원', ?, ?, ?);

문제는 EMP_DNO3 View에 포함되지 않은 MANAGER, SALARY, DNO 값을 어떻게 채울 것인가이다. 누락된 컬럼이 NULL을 허용하거나 기본값을 가진다면 가능할 수 있지만, NOT NULL 제약조건이 있으면 삽입이 불가능할 수 있다.

8.2 Join View의 갱신

EMP_PLANNING은 EMPLOYEE와 DEPARTMENT를 Join해서 만든 View이다.

INSERT INTO EMP_PLANNING
VALUES ('박지선', '대리', 2500000);

이 삽입은 다음 이유로 모호하다.

데이터를 EMPLOYEE에 넣어야 하는지 DEPARTMENT에 넣어야 하는지 명확하지 않다.
EMPLOYEE의 기본 키인 EMPNO가 View에 없다.
부서번호 DNO도 View에 없기 때문에 Join 관계를 구성하기 어렵다.

따라서 Join으로 정의된 View는 일반적으로 갱신이 어렵다.

8.3 집단 함수 View의 갱신

부서별 평균 급여 View를 생각해 보자.

CREATE VIEW EMP_AVGSAL (DNO, AVGSAL)
AS SELECT DNO, AVG(SALARY)
FROM EMPLOYEE
GROUP BY DNO;

다음 갱신은 원본 데이터로 되돌리기 어렵다.

UPDATE EMP_AVGSAL
SET AVGSAL = 3000000
WHERE DNO = 2;

평균값을 3000000으로 만들기 위해 각 사원의 급여를 어떻게 바꿔야 하는지 여러 가능성이 존재하기 때문이다. 따라서 집단 함수가 포함된 View는 일반적으로 갱신할 수 없다.

9. 갱신이 불가능한 View의 대표 조건

조건	갱신이 어려운 이유
기본 키가 포함되지 않은 View	원본 투플을 식별하기 어렵다
View에 포함되지 않은 컬럼이 `NOT NULL`인 경우	삽입 시 필수 값을 제공할 수 없다
집단 함수가 포함된 View	집계 결과를 원본 행으로 역변환할 수 없다
Join으로 정의된 View	여러 테이블 중 어느 쪽을 어떻게 갱신할지 모호하다

주의할 점은 이론적으로 갱신 가능한 View와 상용 DBMS가 실제로 갱신을 허용하는 View가 항상 일치하지는 않는다는 것이다. DBMS 구현 정책에 따라 더 엄격하게 제한될 수 있다.

10. System Catalog의 개념

System Catalog는 데이터베이스 객체와 구조에 관한 정보를 저장한다.

저장 정보	예시
사용자 정보	사용자 이름, 소유 객체
릴레이션 정보	테이블 이름, 소유자, 투플 수
애트리뷰트 정보	컬럼 이름, 타입, 길이
View 정보	View 이름, View 정의 SQL
Index 정보	인덱스 이름, 대상 컬럼, 통계
권한 정보	누가 어떤 객체에 접근 가능한지

System Catalog는 Metadata라고도 부른다. Metadata는 “데이터에 관한 데이터”라는 뜻이다.

예를 들어 EMPLOYEE 테이블의 실제 데이터가 사원 목록이라면, System Catalog는 다음과 같은 정보를 저장한다.

EMPLOYEE 테이블이 존재한다.
EMPLOYEE 테이블의 소유자는 KIM이다.
EMPLOYEE 테이블에는 EMPNO, EMPNAME, TITLE, MANAGER, SALARY, DNO 컬럼이 있다.
EMPNO는 기본 키이다.
DNO는 외래 키이다.

System Catalog는 Data Dictionary 또는 System Table이라고도 부른다.

11. System Catalog가 질의 처리에 사용되는 방식

사용자가 다음 질의를 실행한다고 하자.

SELECT EMPNAME, SALARY, SALARY * 1.1
FROM EMPLOYEE
WHERE TITLE = '과장' AND DNO = 2;

DBMS는 이 질의를 실행하기 전에 System Catalog를 이용해 여러 검사를 수행한다.

11.1 문법 검사

먼저 SELECT, FROM, WHERE 구조가 SQL 문법에 맞는지 검사한다.

11.2 릴레이션 존재 여부 검사

FROM EMPLOYEE에서 참조한 EMPLOYEE 릴레이션이 실제로 존재하는지 확인한다.

11.3 애트리뷰트 존재 여부 검사

다음 애트리뷰트들이 EMPLOYEE 릴레이션에 존재하는지 확인한다.

EMPNAME
SALARY
TITLE
DNO

11.4 데이터 타입 검사

SALARY * 1.1은 산술 연산이므로 SALARY가 숫자형인지 확인한다.

SALARY * 1.1

TITLE = '과장'은 문자열 비교이므로 TITLE이 문자형인지 확인한다.

TITLE = '과장'

11.5 권한 검사

사용자가 EMPLOYEE 릴레이션의 EMPNAME, SALARY 애트리뷰트를 조회할 권한이 있는지 확인한다.

11.6 인덱스 확인

WHERE절에서 사용된 TITLE, DNO에 인덱스가 있는지 확인한다.

WHERE TITLE = '과장' AND DNO = 2

12. Query Optimization과 통계 정보

Query Optimization은 DBMS가 질의를 수행하는 여러 방법 중 가장 비용이 적게 드는 방법을 찾는 과정이다.

같은 SQL도 여러 방식으로 실행될 수 있다.

실행 방법	설명
Full table scan	테이블 전체를 순차적으로 읽음
`TITLE` index 사용	`TITLE = '과장'` 조건을 먼저 적용
`DNO` index 사용	`DNO = 2` 조건을 먼저 적용
복수 index 조합	두 조건의 index를 함께 활용

DBMS가 적절한 실행 계획을 선택하려면 System Catalog에 저장된 통계 정보가 정확해야 한다.

12.1 Selectivity

Selectivity는 조건이 전체 투플 중 얼마나 많은 투플을 선택하는지 나타낸다.

Selectivity = 조건을 만족하는 투플 수 / 전체 투플 수

선택율이 낮을수록 조건이 더 강하게 데이터를 걸러내며, 인덱스 사용 효과가 커질 가능성이 높다.

예를 들어 EMPLOYEE에 7개의 투플이 있고, TITLE에는 5가지 값, DNO에는 3가지 값이 있다고 하자.

애트리뷰트	상이한 값 개수
`TITLE`	5
`DNO`	3

일반적으로 상이한 값의 개수가 많은 TITLE 조건이 검색 대상을 더 좁힐 가능성이 높다. 따라서 TITLE 인덱스가 DNO 인덱스보다 유리할 수 있다.

13. System Catalog의 저장 방식과 갱신 제한

관계 DBMS의 System Catalog는 사용자 릴레이션과 유사한 형태로 저장된다. 따라서 SELECT문으로 내용을 조회할 수 있다.

예를 들어 단순화된 System Catalog는 다음과 같이 구성될 수 있다.

13.1 `SYS_RELATION`

SYS_RELATION은 릴레이션에 관한 정보를 저장한다.

컬럼	의미
`RelId`	릴레이션 이름
`RelOwner`	소유자
`RelTuples`	투플 수
`RelAtts`	애트리뷰트 수
`RelWidth`	투플 길이

13.2 `SYS_ATTRIBUTE`

SYS_ATTRIBUTE는 애트리뷰트에 관한 정보를 저장한다.

컬럼	의미
`AttRelId`	애트리뷰트가 속한 릴레이션
`AttID`	애트리뷰트 번호
`AttName`	애트리뷰트 이름
`AttOffset`	투플 내 시작 위치
`AttType`	데이터 타입
`AttLen`	애트리뷰트 길이
`PkorFk`	기본 키 또는 외래 키 여부

13.3 사용자는 System Catalog를 직접 갱신할 수 없다

System Catalog는 데이터베이스 구조의 기준이 되는 정보이므로 사용자가 직접 INSERT, UPDATE, DELETE할 수 없다.

예를 들어 EMPLOYEE에서 MANAGER 컬럼을 삭제하려면 다음과 같은 DDL을 사용해야 한다.

ALTER TABLE EMPLOYEE DROP COLUMN MANAGER;

System Catalog를 직접 삭제하려는 다음 방식은 허용되지 않는다.

DELETE FROM SYS_ATTRIBUTE
WHERE AttRelId = 'EMPLOYEE' AND AttName = 'MANAGER';

DBMS는 DDL 수행 결과에 따라 System Catalog를 자동으로 갱신한다.

14. System Catalog에 유지되는 통계 정보

System Catalog에는 질의 최적화를 위해 다양한 통계 정보가 저장된다.

14.1 릴레이션마다 유지되는 정보

정보	의미
투플 크기	한 행이 차지하는 크기
투플 수	전체 행 수
각 블록의 채우기 비율	저장 블록 사용률
블록킹 인수	한 블록에 저장 가능한 투플 수
릴레이션 크기	릴레이션이 차지하는 블록 수

14.2 View마다 유지되는 정보

정보	의미
View 이름	View 식별자
View 정의	View를 정의한 `SELECT`문

14.3 애트리뷰트마다 유지되는 정보

정보	의미
데이터 타입	`int`, `char`, `varchar` 등
크기	저장 길이
상이한 값 개수	distinct value 수
값의 범위	최솟값, 최댓값 등
선택율	조건 만족 투플 수 / 전체 투플 수

14.4 사용자마다 유지되는 정보

정보	의미
접근 가능한 릴레이션	사용자가 조회 또는 조작 가능한 객체
권한	`SELECT`, `INSERT`, `UPDATE`, `DELETE` 등

14.5 인덱스마다 유지되는 정보

정보	의미
인덱스된 애트리뷰트	인덱스 대상 컬럼
키/비키 여부	Key attribute인지 여부
클러스터링 여부	Clustering index인지 여부
밀집/희소 여부	Dense/Sparse index 여부
인덱스 높이	탐색 단계 수
1단계 인덱스 블록 수	인덱스 저장 구조 정보

15. Oracle Data Dictionary

Oracle에서는 System Catalog를 Data Dictionary라고 부른다.

항목	내용
명칭	`Data Dictionary`
저장 위치	System tablespace
구성	기본 테이블 + Data Dictionary View
일반 사용자 접근	주로 Data Dictionary View를 통해 접근

Oracle의 기본 테이블에는 내부 정보가 저장되어 있으므로, 일반 사용자는 보통 이해하기 쉬운 형태로 제공되는 Data Dictionary View를 조회한다.

16. Oracle Data Dictionary View의 세 부류

Oracle의 Data Dictionary View는 크게 DBA_xxx, ALL_xxx, USER_xxx로 나뉜다.

View 종류	범위	설명
`DBA_xxx`	가장 넓음	데이터베이스 내 모든 객체 정보
`ALL_xxx`	중간	현재 사용자가 접근할 수 있는 객체 정보
`USER_xxx`	가장 좁음	현재 사용자가 소유한 객체 정보

포함 관계는 다음과 같다.

DBA_xxx
└── ALL_xxx
    └── USER_xxx

구분 기준은 다음처럼 정리할 수 있다.

USER_xxx = 내가 소유한 객체
ALL_xxx = 내가 접근 가능한 객체
DBA_xxx = DB 전체 객체

17. 주요 Oracle Data Dictionary View

View	용도
`ALL_CATALOG`	접근 가능한 테이블, View, Synonym 정보
`ALL_CONSTRAINTS`	접근 가능한 제약조건 정보
`ALL_CONS_COLUMNS`	제약조건에 포함된 컬럼 정보
`ALL_TABLES`	접근 가능한 테이블 정보
`ALL_VIEWS`	접근 가능한 View 정보
`DICTIONARY` 또는 `DICT`	Data Dictionary View 목록
`TABLE_PRIVILEGES`	객체 권한 정보
`USER_CATALOG`	사용자가 소유한 테이블, View, Synonym 정보
`USER_TAB_COLUMNS`	사용자의 테이블과 View에 속한 컬럼 정보
`USER_VIEWS`	사용자가 소유한 View 정보
`USER_INDEXES`	사용자가 소유한 Index 정보
`USER_IND_COLUMNS`	사용자가 소유한 Index의 컬럼 정보
`USER_CONSTRAINTS`	사용자가 소유한 제약조건 정보

18. Oracle Data Dictionary 조회 예제

18.1 `ALL_CATALOG`: 접근 가능한 테이블과 View 조회

SELECT *
FROM ALL_CATALOG
WHERE OWNER = 'KIM';

컬럼	의미
`OWNER`	객체 소유자
`TABLE_NAME`	테이블 또는 View 이름
`TABLE_TYPE`	객체 유형

18.2 `USER_TAB_COLUMNS`: 테이블 컬럼 정보 조회

SELECT TABLE_NAME, COLUMN_NAME, DATA_TYPE
FROM USER_TAB_COLUMNS
WHERE TABLE_NAME = 'EMPLOYEE';

USER_TAB_COLUMNS를 통해 확인할 수 있는 정보는 다음과 같다.

컬럼 이름
데이터 타입
컬럼 길이
NULL 허용 여부
Default 값

18.3 `USER_VIEWS`: View 정의 조회

SELECT VIEW_NAME, TEXT
FROM USER_VIEWS;

컬럼	의미
`VIEW_NAME`	View 이름
`TEXT`	View를 정의한 SQL문

이 정보는 View 조회 시 DBMS가 View 정의를 찾아 기본 릴레이션 질의로 변환하는 과정과 연결된다.

19. Oracle에서 Join View 갱신 예제

EMP_PLANNING은 EMPLOYEE와 DEPARTMENT를 Join해서 정의한 View이다.

INSERT INTO EMP_PLANNING
VALUES ('김지민', '사원', 1500000);

이 삽입은 다음 이유로 실패할 수 있다.

EMPLOYEE의 기본 키인 EMPNO가 View에 포함되어 있지 않다.
DNO가 없기 때문에 DEPARTMENT와의 Join 관계를 구성하기 어렵다.
Join View이므로 어떤 기본 테이블을 어떻게 갱신해야 하는지 모호하다.

이 예제는 View 갱신 가능성의 제한을 보여준다.

20. Oracle Index와 통계 정보

20.1 Index 생성

EMPLOYEE 테이블의 DNO 컬럼에 Index를 생성한다.

CREATE INDEX EMPDNO_IDX ON EMPLOYEE(DNO);

20.2 `USER_INDEXES`: Index 통계 조회

SELECT INDEX_NAME, INITIAL_EXTENT, DISTINCT_KEYS,
       NUM_ROWS, SAMPLE_SIZE, LAST_ANALYZED
FROM USER_INDEXES
WHERE INDEX_NAME = 'EMPDNO_IDX';

컬럼	의미
`INDEX_NAME`	Index 이름
`INITIAL_EXTENT`	초기 Extent 크기
`DISTINCT_KEYS`	서로 다른 Index key 개수
`NUM_ROWS`	통계상 행 수
`SAMPLE_SIZE`	통계 분석에 사용된 표본 수
`LAST_ANALYZED`	마지막 통계 분석 시점

예시 상태는 다음처럼 해석할 수 있다.

DISTINCT_KEYS = 3
NUM_ROWS = 7
SAMPLE_SIZE = 7

DISTINCT_KEYS = 3은 DNO 값의 종류가 3개라는 뜻이다.

21. 통계 정보는 즉시 갱신되지 않을 수 있다

EMPLOYEE 테이블에 새로운 투플을 삽입한다고 하자.

INSERT INTO EMPLOYEE
VALUES (3428, '김지민', '사원', 2106, 1500000, 2);

실제 행 수는 증가하지만, USER_INDEXES의 통계 정보가 즉시 변경되지 않을 수 있다.

시점	실제 행 수	통계상 `NUM_ROWS`	설명
삽입 전	7	7	실제 데이터와 통계 일치
삽입 직후	8	7	통계 정보가 아직 갱신되지 않음
`ANALYZE` 후	8	8	통계 정보 갱신

주의할 점은 Optimizer가 통계 정보를 기반으로 실행 계획을 선택한다는 것이다. 통계 정보가 오래되면 실제 데이터 분포와 맞지 않는 실행 계획을 선택할 수 있다.

22. `ANALYZE`로 통계 정보 갱신

Index 통계 정보를 갱신하려면 다음 명령을 사용할 수 있다.

ANALYZE INDEX EMPDNO_IDX
COMPUTE STATISTICS;

일반 문법은 다음과 같다.

ANALYZE 객체_유형 객체_이름 연산 STATISTICS;

요소	예시	의미
객체 유형	`TABLE`, `INDEX`	분석 대상 종류
객체 이름	`EMPDNO_IDX`	분석 대상 이름
연산	`COMPUTE`, `ESTIMATE`	통계 계산 방식
`STATISTICS`	`STATISTICS`	통계 정보 대상

22.1 `COMPUTE`와 `ESTIMATE`

연산	의미	특징
`COMPUTE`	전체 데이터를 접근하여 통계 계산	정확하지만 비용이 큼
`ESTIMATE`	표본을 사용하여 통계 추정	빠르지만 정확도가 낮을 수 있음

대량의 데이터를 삽입, 삭제, 수정한 뒤에는 통계 정보가 실제 데이터와 달라질 수 있으므로 ANALYZE 작업이 필요할 수 있다.

23. `USER_IND_COLUMNS`: Index 대상 컬럼 확인

USER_IND_COLUMNS는 Index가 어떤 테이블의 어떤 컬럼에 정의되어 있는지 보여준다.

SELECT *
FROM USER_IND_COLUMNS
WHERE TABLE_NAME = 'EMPLOYEE';

컬럼	의미
`INDEX_NAME`	Index 이름
`TABLE_NAME`	Index가 정의된 테이블
`COLUMN_NAME`	Index가 정의된 컬럼
`COLUMN_POSITION`	복합 Index에서 컬럼 순서
`COLUMN_LENGTH`	컬럼 길이
`DESCEND`	정렬 방향

24. Oracle의 자동 Index 생성

Oracle은 특정 제약조건을 정의하면 자동으로 Index를 생성할 수 있다.

컬럼	조건	Index 생성 방식
`EMPNO`	`PRIMARY KEY`	Oracle이 자동 생성
`EMPNAME`	`UNIQUE`	Oracle이 자동 생성
`DNO`	사용자가 `CREATE INDEX` 수행	사용자 명시 생성

기본 키와 UNIQUE 제약조건은 중복 여부를 빠르게 검사해야 하므로 DBMS가 내부적으로 Index를 생성할 수 있다.

25. 자칫 실수하기 쉬운 부분

25.1 View와 Snapshot을 혼동하지 않기

구분	핵심
View	원본 릴레이션을 동적으로 바라보는 가상 릴레이션
Snapshot	특정 시점의 결과를 저장한 정적 릴레이션

25.2 View는 항상 갱신 가능한 것이 아니다

다음 조건이 있으면 갱신이 제한될 수 있다.

기본 키가 포함되지 않음
NOT NULL 컬럼이 View에 없음
집단 함수 포함
Join으로 정의됨

25.3 System Catalog는 직접 수정하지 않는다

System Catalog는 사용자가 직접 DELETE, UPDATE, INSERT로 수정하는 대상이 아니다. 테이블 구조 변경은 DDL로 수행해야 한다.

ALTER TABLE EMPLOYEE DROP COLUMN MANAGER;

25.4 통계 정보와 실제 데이터는 다를 수 있다

데이터가 변경되어도 Data Dictionary의 통계 정보가 즉시 갱신되지 않을 수 있다. Query Optimizer가 정확한 판단을 하려면 최신 통계가 필요하다.

26. 핵심 요약

주제	핵심
View	기본 릴레이션에 대한 `SELECT`문으로 정의되는 가상 릴레이션
Snapshot	특정 시점의 `SELECT` 결과를 저장한 릴레이션
`WITH CHECK OPTION`	View 조건을 만족하지 않는 삽입/수정을 방지
View 장점	질의 단순화, 무결성, 데이터 독립성, 보안, 다양한 관점 제공
갱신 불가능 View	기본 키 없음, `NOT NULL` 누락, 집단 함수, Join View
System Catalog	DB 객체와 구조에 대한 Metadata 저장소
Query Optimization	가장 비용이 적은 실행 방법을 선택하는 과정
Selectivity	조건 만족 투플 수 / 전체 투플 수
Oracle Data Dictionary	Oracle의 System Catalog
`DBA_xxx`	DB 전체 객체 정보
`ALL_xxx`	현재 사용자가 접근 가능한 객체 정보
`USER_xxx`	현재 사용자가 소유한 객체 정보
`USER_INDEXES`	Index 통계 정보
`USER_IND_COLUMNS`	Index가 걸린 컬럼 정보
`ANALYZE`	통계 정보 갱신 명령

8장의 전체 흐름은 다음처럼 정리할 수 있다.

View
→ View 정의는 System Catalog에 저장됨
→ DBMS는 System Catalog를 이용해 View 질의를 기본 릴레이션 질의로 변환
→ System Catalog의 통계 정보는 Query Optimization에 활용됨
→ Oracle에서는 System Catalog를 Data Dictionary View로 조회함

개요