View

상위 문서: SQL

개요

모든 유저들이 데이터베이스 내의 모든 logical model(relation)을 볼 수 있는 권한을 가지는 것은 보안상의 측면에서 권장되지 않는다. 또한 어떤 사용자는 특정 릴레이션(relation)에 접근할 수는 있어도, 모든 속성(attribute)에 접근하는 것이 바람직하지 않을 수 있다. 예를 들어, 어떤 직원(employee)는 강사(instructor)의 ID, name, dept_name 속성에 접근할 필요가 있지만, 강사의 salary 속성을 볼 필요는 없을 수 있다. 따라서 해당 직원은 다음과 같은 SQL 쿼리(query)로 표현된 릴레이션에 접근해야 한다.

select ID, name, dept_name from instructor;

즉, 위 쿼리의 결과를 계산하여 저장한 다음 저장된 릴레이션을 사용자에게 제공하는 방식으로 특정 사용자에게 제한된 릴레이션을 제공할 수 있다. 하지만 instructor, course, section 릴레이션 안의 데이터가 변경된다면, 저장된 쿼리 결과는 다시 쿼리를 실행했을 때의 결과와 일치하지 않는다.(out-of-date) 따라서 위와 같은 해결 방식, 즉 쿼리 결과를 계산해서 저장하는 것은 좋은 생각이 아니다.

대신 SQL에는 view라는 기능이 있다. View는 개념적인 모델(conceptual model)에는 없지만 사용자에게 virtual relation으로 보이도록 만든 릴레이션이다. 이를 위해 SQL은 쿼리에 의해 정의되는 virtual relation이라는 기능을 제공한다. Virtual relation은 미리 계산되어 저장되는 것이 아니라, virtual relation이 사용될 때마다 쿼리를 실행하여 계산된다. 이는 with 절과 유사한 기능이다.
즉, 해당 예시에서 view는 원본 릴레이션에 직접적으로 접근할 권한을 부여하지 않는다. 대신 salary 속성이 포함되지 않은 view를 만들고 해당 view에만 직원에게 접근 권한을 부여한다. 따라서 해당 직원은 salary를 제외한 속성만 볼 수 있게 된다.

View definition

SQL에서 view를 정의하기 위해서는 create view 명령어를 사용해야 한다. 또한 view를 정의하기 위해서는 이름을 부여해야 하며, view를 계산할 쿼리를 명시해야 한다. create view 명령어는 v라는 이름의 view를 정의하기 위해 아래와 같이 사용된다.

create view v as <query expression>;

이때 <query expression>는 어떤 쿼리 표현식이라도 문법만 맞다면 가능하다. 이를 활용하여 강사 릴레이션에서 salary 속성을 제외한 모든 속성에 접근하는 직원에게 제공하는 view는 다음과 정의된다.

create view faculty as select ID, name, dept_name from instructor;

또한, 2017년 가을 학기에 물리학과에서 개설한 모든 강의 섹션(course_id) 속성을, 각 섹션의 건물(building)과 강의실 번호(room_number) 속성과 함께 나열하는 view를 생성하려면, 다음과 같이 작성한다:

create view physics_fall_2017 as
select course.course_id, sec_id, building, room_number
from course, section
where course.course_id = section.course_id
  and course.dept_name = 'Physics'
  and section.semester = 'Fall'
  and section.year = 2017;

View definition은 위 문단에서 언급했듯이 해당 쿼리를 실행하여 릴레이션을 생성하는 것과는 구별된다. View definition은 단순히 표현식을 저장할 뿐이며, 해당 표현식을 통해 view relation이 필요할 때마다 즉시(on demand) 생성된다.

Using Views in SQL Queries

위에서 만들어진 faculty와 physics_fall_2017라는 view name은 추후에도 해당 view 정의를 통해서 만들어진 virtual relation을 호출하기 위해서 사용될 수 있다. 예를 들어 2017년 가을 학기에 Watson 건물에서 개설된 모든 물리학과 강좌들을 다음과 같이 찾아낼 수 있다:

select course_id
from physics_fall_2017
where building = 'Watson';

또한 view name은 쿼리 안에서 릴레이션이 나타날 수 있는 모든 위치에서 나타날 수 있다. 이때 view의 속성 이름은 다음과 같이 명시적으로 지정될 수 있다:

create view departments_total_salary(dept_name, total_salary) as
select dept_name, sum(salary)
from instructor
group by dept_name;

위 코드에서 정의된 view는 각 학과에 대해서 해당 학과와 모든 강사들의 급여의 총 합을 제공한다. 이때 sum(salary)라는 이름 대신, total_salary라는 이름을 명시적으로 지정한다.

Views Defined Using Other Views

View는 다른 view를 기반으로 정의할 수 있다. 이때 다음과 같은 용어가 사용된다:

• v1이 v2를 view를 정의하는데 직접 사용 → directly depends on
• v1이 v2에 view를 정의하는데 직접 또는 간접적으로 의존 → depends on
• v가 view를 정의하는데 자기 자신에 의존 → recursive

위 용어들을 통해서 view 간의 의존성을 명확하게 구분할 수 있으며, 나중에 시스템이 view를 확장할 때 올바르게 해석되도록 한다.
예를 들어 2017년 가을 학기에 Watson 건물에서 개설된 모든 물리학과 강좌와 해당 강좌의 강의실 번호를 나타내는 view는 다음과 같이 정의될 수 있다.

create view physics_fall_2017_watson as
  select course_id, room_number
  from physics_fall_2017
  where building = 'Watson';

View expansion

View는 쿼리를 단순화 시켜주지만, 실제 실행 시에는 원래의 정의로 대체(확장)된다. 예를 들어, 위 문단에서 작성한 physics_fall_2017_watson라는 view는 실제 실행 시 아래와 같이 확장(expansion)된다:

create view physics_fall_2017_watson as
  select course_id, room_number
  from (
    select course.course_id, building, room_number
    from course, section
    where course.course_id = section.course_id
      and course.dept_name = 'Physics'
      and section.semester = 'Fall'
      and section.year = '2017'
  )
  where building = 'Watson';

위와 같이 view는 실행시 내부적으로 정의된 쿼리로 확장되며, view가 중첩될 경우에는 계속해서 확장되는 구조이다. 이때 다른 view를 이용하여 정의된 view는 아래와 같은 view 확장 알고리즘을 통해서 처리된다.

반복:
  표현식 e₁에서 뷰 vᵢ를 찾는다
  vᵢ를 정의하는 쿼리 표현식으로 vᵢ를 대체한다
더 이상 뷰가 없을 때까지 반복

만약 recusive 방식으로 정의된 view가 아니라면 위 알고리즘은 항상 종료되며, 위 알고리즘 덕분에 SQL은 view를 매크로의 일종처럼 해석하여 처리할 수 있다.