[11] 뷰 (View)

1. 뷰(View)란?

관계 데이터베이스 시스템에서의 뷰(view)는 다른 릴레이션으로부터 유도된 릴레이션(derived relation)으로 데이터베이스 구조의 3단계 아키텍처의 관점(view)와는 다릅니다.

뷰는 관계 데이터베이스 시스템에서 데이터베이스의 보안 메카니즘으로 복잡한 질의를 간단하게 표현하는 수단으로서 데이터 독립성을 높이기 위해서 사용됩니다. 이러한 뷰에 대한 정보는 시스템 카탈로그(데이터 사전)에 저장하고 관리하게 됩니다. 따라서 시스템 카탈로그를 적절히 활용하면 원하는 릴레이션을 데이터베이스에서 찾고 해당 릴레이션에 어떤 속성들이 있으며 각 속성의 데이터 타입은 무엇인가 등 쉽게 파악할 수 있습니다. 사용자는 해당 뷰안에 있는 속성들이 어떤 릴레이션에서 유도되었는지 알 수 없기 때문에 높은 보안성을 유지할 수 있으며 일반적으로 데이터 보정, 시험 등 임시적인 작업을 위한 용도로서 사용됩니다.

뷰는 저장장치 내에 물리적으로 존재하지 않지만 사용자에게 있는 것처럼 간주되며 일종의 가상 릴레이션(Virtual relation)입니다. 뷰는 기존의 기본 릴레이션(base relation)에 대한 SELECT문의 형태로 정의되며 뷰 또한 또 다른 뷰로 정의될 수 있습니다. 따라서 뷰는 데이터를 검색하거나 갱신할 수 있는 동적인 창(dynamic window)의 역할을 할 수 있습니다.

1.1. 뷰의 정의

CREATE VIEW 뷰이름 [(속성_이름)] # 기본 릴레이션에서 검색한 속성들의 이름과 달리 정의해도됨
AS SELECT 문
[WITH CHECK OPTION]; # 무결성 제약 조건

• 뷰의 이름 다음에 속성들을 생략하면 뷰를 정의하는데 사용된 SELECT문에 열겨된 속성들의 이름과 동일한 속성들이 뷰에 포함된다.

• 뷰를 정의하는 SELECT문에 산술식 또는 집계 함수에 사용된 속성이 있는 경우 또는 뷰의 정의에 조인이 포함되어 있고 두 개 이상의 다른 릴레이션으로부터 가져온 속성들의 이름이 같아서 뷰에서 두 개 이상의 속성의 이름이 같게 되는 경우에는 뷰를 정의할 때 모든 속성 이름을 지정해야 한다.

예시

CREATE VIEW EMP_DNO3 (ENO, ENAME, TITLE)
AS SELECT EMPNO, EMPNAME, TITLE
   FROM EMPLOYEE
   WHERE DNO = 3;
   
# 뷰를 이용한 검색
SELECT *
FROM EMP_DNO3
WHERE TITLE='사원';

# 뷰의 실제 쿼리
SELECT EMPNO, EMPNAME, TITLE
FROM EMPLOYEE
WHERE TITLE='사원' AND DNO=3;

시스템 카타탈로그에 저장된 뷰의 정의(SELECT문)을 검색하고 기본 릴레이션에 대한 뷰의 접근 권한을 검사합니다. 그 후 뷰에 대한 질의를 기본 릴레이션에 대한 동등한 질의로 변환하게 되는 과정을 거칩니다.

1.2. 뷰의 장점

• 뷰는 복잡한 질의를 간단하게 표현할 수 있게 한다.

• 뷰는 데이터 무결성을 보장하는데 활용된다.

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

UPDATE EMP_DNO3
SET DNO = 2
WHERE ENO = 3427;

위의 예시처럼 EMP_DNO3는 DNO가 3인 조건으로 생성된 뷰입니다. 만약 UPDATE문을 통해 DNO를 2로 바꾼다면 뷰를 생성하는 조건에 위배되고 있기 때문에 앞으로 해당 정보는 EMP_DNO3에서 사라집니다. 이런 상황은 논리적으로 어긋나며 뷰에 대한 UPDATE는 최소한 뷰에 대한 조건을 벗어나면 안됩니다. 마찬가지로 INSERT문을 사용하여 DNO가 2인 튜플을 뷰에 넣는 것도 마찬가지입니다.

CREATE VIEW ...
AS SELECT ...
   FROM ...
   WHERE ...
   WITH CHECK OPTION;

이런 논리적으로 어긋나는 상황을 방지하기 위해 WITH CHECK OPTION을 추가하여 데이터 무결성을 보장할 수 있습니다.

• 뷰는 데이터 독립성을 제공합니다.

데이터베이스 구조에서 데이터 독립성은 하위 스키마가 변경될때 상위 스키마는 영향을 받지 않는 특성이라고 설명했습니다. 뷰에서도 데이터베이스 구조가 바뀌어도 기존의 질의를 다시 작성할 필요성을 줄이는데 사용될 수 있습니다.

예를 들어, 기존의 EMPLOYEE 릴레이션이 두 개의 릴레이션 EMP1(EMPNO, EMPNAME, SALARY)와 EMP2(EMPNO, TITLE, MANAGER, DNO)로 분해 되었다고 가정하겠습니다. 응용 프로그램에서 기존의 EMPOYEE 릴레이션을 접근하던 SELECT문은 더 이상 수행되지 않으므로 모든 코드를 EMP1과 EMP2에 대한 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;

따라서 위와 같이 뷰를 생성하여 응용 프로그램의 전체 코드를 그대로 사용할 수 있도록 할 수 있습니다.

• 뷰는 데이터 보안 기능을 제공한다.

뷰는 기본 릴레이션에 직접 접근할 수 있는 권한을 부여하지 않고 뷰를 통해 데이터를 접근하도록 하기 때문에 보안 메커니즘으로 사용할 수 있습니다. 뷰는 일반적으로 기본 릴레이션의 일부 속성들 또는 일부 튜플들을 검색하는 SELECT문으로 정의되므로 뷰를 통해서 기본 릴레이션을 접근하면 기본 릴레이션의 일부분만 검색할 수 있습니다.

예를 들어, EMPLOYEE 릴레이션의 SALARY 속성은 숨기고 나머지 속성들은 모든 사용자가 접근할 수 있도록 하려면 SALARY 속성을 제외하고 EMPLOYEE 릴레이션의 모든 속성을 포함하는 뷰를 정의하고 사용자에게는 해당 뷰에 대한 SELECT 접근 권한을 허가하면 됩니다. 이러한 데이터 보안을 동적(dynamic) 권한 부여 또는 content based control이라고 합니다.

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

사용자들에 따라 필요한 정보만 뷰를 정의하여 데이터 접근을 제어할 수 있습니다.

1.3. 뷰의 갱신

뷰는 기본 릴레이션에서 유도된 릴레이션이고 실제 물리적으로 저장된 릴레이션이 아닌 가상 릴레이션입니다. 그렇기 때문에 뷰에 대한 갱신도 결국 기본 릴레이션에 대한 갱신으로 변환됩니다. 기본 릴레이션으로의 갱신이 이루어진다면 뷰는 기본 릴레이션의 기본키를 포함하여야 하고 갱신 질의에도 기본키 속성값이 누락되지 않아야 합니다.

# 뷰 갱신
INSERT 
INTO EMP_DNO3 # 사원번호 : 포함
VALUES (4293, '철수', '사원');

# 변환된 실제 쿼리 (누락된 값은 NULL 값으로 처리됨)
INSERT
INTO EMPLOYEE # 사원번호 : 기본키
VALUES (4293, '철수', '사원', ...);

현대 대부분의 DBMS는 조인으로 만들어진 뷰는 갱신을 허용하지 않습니다. 물론 뷰가 여러 기본 릴레이션에 대한 기본키를 전부 포함하고 있고 논리적으로 가능하다면 갱신이 불가능하지 않습니다. 하지만 조인으로 이루어진 뷰에 대한 갱신과 그 기능을 실제로 구현하여 비용 관계를 놓고 보았을때 실제로는 사용자들이 거의 사용하지 않기 때문에 굳이 만들지 않는다고 합니다.

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;

INSERT INTO EMP_AVGSAL
VALUES (3, 3200000);

DNO가 2인 사람들의 SALARY의 평균을 300만으로 맞추는 것은 이론적으로 불가능하지는 않습니다. 하지만 이런 상황이 사실 의미가 없는 행위라고 판단하기 때문에 위와 같은 갱신은 허용하지 않습니다.

정리하자면, 기본키가 포함되지 않는 뷰, 뷰에 포함되지 않는 속성에 NOT NULL로 지정, 집계 함수 포함된 뷰, 조인으로 정의된 뷰는 갱신을 허용하지 않습니다.

2. 스냅샷 (Snapshot)

스냅샷은 어느 시점에 SELECT문의 결과를 기본 릴레이션의 형태로 저장해 놓은 것 입니다. 스냅샷은 사진을 찍는 것과 같아서 스냅샷을 정의하는 시점의 기본 릴레이션의 내용이 스냅샷에 반영됩니다. 예를 들어, 몇년 몇월 시점에 근무하던 사원들의 정보, 재고 정보 등이 스냅샷으로 정의될 수 있습니다.
따라서 스냅샷은 어떤 한 시점의 정보를 검색하는 릴레이션이라는 점에서 뷰와는 차이점이 있습니다.