[데이터베이스] 8장. 뷰와 시스템 카탈로그

경희대학교 이영구 교수님의 데이터베이스 수업 복습용 게시물입니다.

 

8.1. 뷰

뷰

• 관계 데이터베이스 시스템의 뷰(view): 다른 릴레이션으로부터 유도된 릴레이션(derived relation) -> ANSI/SPARC 3단계 아키텍처의 외부 뷰와 다름
• 데이터베이스의 보안 메커니즘
• 복잡한 질의를 간단하게 표현하는 수단
• 데이터독립성을 높이기 위해
• 한 사용자의 전체 외부 뷰 대신에 하나의 가상 릴레이션(virtual relation)을 의미
• 기존의 기본 릴레이션(base relation)에 대한 SELECT문의 형태로 정의
• 사용자는 여러 개의 릴레이션과 뷰를 사용할 수 있음
• 릴레이션으로부터 데이터를 검색하거나 갱신할 수 있는 동적인 창(dynamic window)의 역할

시스템 카탈로그

• 시스템 내의 객체(기본 릴레이션, 뷰, 인덱스, 사용자, 접근 권한 등)에 관한 정보 포함
• 시스템 카탈로그를 적절히 활용하여 원하는 릴레이션 탐색 가능 -> 그 릴레이션에 들어있는 애트리뷰트 정보도 파악 가능

스냅샷(snapshot)

• 어느 시점의 SELECT문의 결과를 기본 릴레이션 형태로 저장해놓은 것

 

 

 

뷰의 정의

• 뷰를 정의하는 SQL문의 구문

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

• 뷰 이름 다음 애트리뷰트 생략 -> SELECT 절에 열거된 애트리뷰트 이름과 동일

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

 

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 = '기획';

 

뷰를 사용하여 데이터를 접근할 때 관계 DBMS에서 거치는 과정

• 시스템 카탈로그로부터 뷰의 정의(SELECT문) 검색
• 기본 릴레이션에 대한 뷰의 접근 권한 검사
• 뷰에 대한 질의 -> 기본 릴레이션에 대한 동등한 질의로 변환

 

뷰의 장점

복잡한 질의를 간단하게 표현

• 기획부 근무하는 사원 중 직책이 부장인 사원의 사원 이름과 급여를 검색하는 질의 -> 기본 릴레이션을 사용하여 표현하면 아래와 같이 복잡해짐

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

• 뷰에 대해서 같은 결과를 검색하는 질의를 표현하면 다음과 같아짐

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

 

데이터 무결성을 보장하는 데 활용

• 기본적으로 뷰를 통해 튜플을 추가하거나 수정할 때, tuple이 뷰를 정의하는 SELECT문의 WHERE절의 기준에 맞지 않으면 뷰의 내용에서 사라짐

UPDATE EMP_DNO3
SET DNO = 2
WHERE ENO = 3427;

• 이 뷰를 정의할 때 WITH CHECK OPTION을 명시했다 가정

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

 

데이터 독립성을 제공

• DB의 구조가 바뀌어도 -> 기존의 질의(응용 프로그램)을 다시 작성할 필요성 줄이는데 사용
• ex) EMPLOYEE 릴레이션이 EMP1(EMPNO, EMPNAME, SALARY), EMP2(EMPNO, TITLE, MANAGER, DNO)로 분해됐을 때 -> 기존의 EMPLOYEE 릴레이션을 접근하던 SELECT문은 더이상 수행 X -> EMP1과 EMP2에 대한 SELECT문으로 변경해야 함 -> EMPLOYEE라는 뷰를 형태에 맞게 정의하면 기존 SELECT문 계속 사용 가능

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;

 

데이터 보안 기능 제공

• 뷰의 원본인 기본 릴레이션에 직접 접근할 수 있는 권한을 부여하지 X, 뷰를 통해 데이터를 접근하도록 함 -> 보안 메커니즘으로 사용
• ex) EMPLOYE 릴레이션에서 SALARY 애트리뷰트를 숨기고 뷰를 구성하여 SALARY 정보를 숨길 수 있음

 

동일한 데이터에 대한 여러 가지 뷰를 제공

 

뷰의 갱신

• 뷰에 대한 갱신도 기본 릴레이션에 대한 갱신으로 변환됨

갱신1: 한 relation 위에서 정의된 뷰에 대한 갱신

 

갱신2: 두 개의 릴레이션 위에서 정의된 뷰에 대한 갱신

 

갱신 3: 집단 함수 등을 포함한 뷰에 대한 갱신

 

갱신이 불가능한 뷰

• 한 릴레이션 위에서 정의되었으나 -> 해당 릴레이션의 기본 키 포함 X
• 기본 릴레이션의 애트리뷰트들 중에 뷰에 포함되지 않은 애트리뷰트에 대해 NOT NULL이 지정된 경우
• 집단 함수가 포함된 뷰
• 조인으로 정의된 뷰

 

8.2. 관계 DBMS의 시스템 카탈로그

시스템 카탈로그

• 데이터베이스의 객체(사용자, 릴레이션, 뷰, 인덱스, 권한 등)와 구조들에 관한 모든 데이터 포함
• 시스템 카탈로그를 메타데이터라고 함. -> 메타데이터: 데이터에 관한 데이터
• 시스템 카탈로그는 사용자 및 질의 최적화 모듈 등 DBMS 자신의 구성 요소에 의해서 사용됨
• 관계 DBMS마다 서로 다른 형태
• 데이터 사전(data dictionary) 혹은 시스템 테이블이라고도 부름

 

SELECT empname, salary, salary * 1.1
FROM employee
where title = '과장' AND dno = 2;

• SELECT문이 문법접으로 정확한가 검사
• 참조하는 employee 릴레이션이 데이터베이스에 존재하는가 검사
• select절& where절에 열거된 attributes가 릴레이션에 존재하는가 확인
• 수식에 사용된 애트리뷰트 -> 데이터 타입이 숫자형인가 검사
• 문자열과 비교된 애트리뷰트 -> 데이터 타입이 문자형인가 검사
• 질의 입력한 사용자 -> employee 릴레이션의 empname, salary 애트리뷰트를 검색할 권한이 있는가 확인
• title, dno에 인덱스가 정의되었는지 확인
• 각각 인덱스가 존재한다 가정 -> DBMS가 두 인덱스 중에서 조건을 만족하는 tuple수가 적은 것을 선택하기 위해 -> 관계데이터베이스 시스템에 데이터베이스 외에 추가로 정보를 유지해야 함
• 한 릴레이션의 전체 tuple 수와 그 릴레이션에 정의된 각 index에 존재하는 상이한 값들의 개수를 유지하면 -> 어느 인덱스를 사용하는 것이 유리한가 예상 가능
• title: [사원, 대리, 과장, 부장, 사장] 다섯 가지 값, dno: [1, 2, 3] 세 가지 값 -> title에 정의된 인덱스가 dno에 정의된 인덱스보다 대상 튜플을 더 좁혀주므로 유리

 

질의 최적화

• DBMS가 질의를 수행하는 여러 방법 중 가장 비용이 적게 드는 방법을 찾는 과정
• 질의 최적화 모듈이 정확한 결정을 내릴 수 있도록 -> DBMS는 자체 목적을 위해서 시스템 카탈로그에 다양한 정보 유지

 

관계 DBMS의 시스템 카탈로그

• 사용자 릴레이션에 적용되는 회복 기법과 동시성 제어 기법을 동일하게 사용 가능
• SELECT문을 사용하여 내용 검색 가능
• 릴레이션, 애트리뷰트, 인덱스, 사용자, 권한 등 각 유형마다 별도의 릴레이션 유지

 

-> relation, attribute에 관한 정보를 유지하는 릴레이션

 

시스템 카탈로그의 갱신

• 어떤 사용자도 시스템 카탈로그를 직접 갱신할 불가능 -> DELETE, UPDATE, INSERT 사용해서 변경 불가능

 

시스템 카탈로그에 유지되는 통계 정보

릴레이션마다

• 튜플의 크기
• 튜플 수
• 각 블록의 채우기 비율
• 블로킹 인수
• 릴레이션의 크기(블록 수)

뷰마다

• 뷰의 이름
• 뷰의 정의

애트리뷰트마다

• 애트리뷰트의 데이터 타입과 크기
• 애트리뷰트 내의 상이한 값들의 수
• 애트리뷰트 값의 범위, 선택율(조건을 만족하는 튜플 수/전체튜플 수)

사용자마다

• 접근할 수 있는 릴레이션
• 권한

인덱스마다

• 인덱스된 애트리뷰트(키 애트리뷰트 또는 비 키 애트리뷰트)
• 클러스터링 인덱스/비 클러스터링 인덱스 여부
• 밀집/희소 인덱스 여부
• 인덱스의 높이
• 1단계 인덱스의 블록 수

 

오라클의 시스템 카탈로그

• 데이터 사전(data dictionary)라고 부름
• 시스템 테이블스페이스에 저장됨
• 기본 테이블과 데이터 사전 뷰로 구성됨
• 기본 테이블 정보가 암호화된 형태로 저장 -> 사용자가 직접 접근할 필요가 거의 X -> 일반적으로 이해하기 쉬운 형식의 정보를 제공하는 데이터 사전 뷰에 접근

 

데이터 사전 뷰의 세 부류

DBA_xxx 뷰

• 데이터베이스 내의 모든 객체들에 관한 정보

ALL_xxx 뷰

• 현재의 사용자가 접근할 수 있는 객체들에 관한 정보

USER_xxx 뷰

• 현재의 사용자가 소유하고 있는 객체들에 관한 정보

 

 

ex) 

SELECT * 
FROM ALL_CATALOG
WHERE OWNER = 'KIM';

-> 사용자 KIM으로 Oracle SQL Developer에 로그인을 한 후에 -> 사용자 KIM이 소유한 테이블이나 뷰에 관한 정보를 검색하는 질의

• OWNER는 사용자의 이름, TABLE_NAME은 테이블이나 뷰의 이름, TABLE_TYPE은 테이블의 유형(테이블, 뷰)