View
- 때때로, 모든 유저에게 전체 모델을 보여주는 것은 바람직하지 못하다.
- 어떤 사람이 instructor의 salary를 제외한 속성을 봐야 한다면,
select ID, name, dept_name
from instructor- 이런 식으로 나온 relation을 봐야 한다.
- view는 특정 유저의 view에서 특정 데이터를 숨기는 메카니즘을 제공한다.
- 실제로 존재하는 relation은 아니기 때문에 일종의 "virtual relation"이라고 할 수 있다.
View Definition
create view v as <query expression>
- Once a view is defined, the view name can be used to refer to the virtual relation that the view generates
- View Definition is not the same as creating a new relation
대신, view definition은 표현을 저장하고 있는 느낌으로 보면 된다.
A view of instructors without their salary
create view faculty as
select ID, name, dept_name
from instructorFind all instructors in the Biology department
select name
from faculty
where dept_name = 'Biology'- faculty 대신 위에 select from 구문을 사용해도 결과는 같다. faculty가 그거니까.
Create a view of department salary totals
create view departments_total_salary(dept_name, total_salary) as
select dept_name, sum(salary)
from instructor
group by dept_name;View Defined Using Other Views
- One view may be used in the expression defining another view
v1 <- v2 <- v3
v1 : v2에 depend directly on
v1 : v3와 indirect. path는 존재 : 그냥 depend on
- recursive하게 만들기도 가능
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';create view physics_fall_2017_watson as
select course_id, room_number
from physics_fall_2017
where building = 'Watson';Expand
- 위에 physics_fall_2017 대신 실제 logical table을 쓰면 expand한다고 하나보다
create view physics_fall_2017_watson as
select cours_id, room_number
from (select cou...- View expansion of an expression repeats the following replacement step
repeat
Find any view relation vi in e1
Replace the view relation vi by the expression defining vi
until
no more view relations are present in e1- e1이 더 이상 view를 사용하는 형태가 아닐 때까지 반복한다.
- view의 장점은 하나의 table이기 때문에 다양한 형태로 접근하다는 점이지만,
단점은 여러 개가 연결되어 있을 때, v1 하나 찾으려고 v4, v5등 뒤로 계속 연산을 해야 한다는 것이다. 이러한 문제는 view가 저장되어 있는 것이 아니기 때문이다. - 이를 위해, Materialized Views가 있다.
Materialized Views
- Certain database systems allow view relations to be physically stored
- Physical copy created when the view is defined. Such views are called Materialized view
- 단점은, 그 view에 이용되는 relation이 update되어도, update 전의 정보를 저장하고 있다는 것이다. 즉, 옛날 data가 저장되어 있다.
- 이를 관리하기 위해서는, relation을 update할 때마다, materialized view도 update해주어야 한다
Update of a View
Add a new tuple to faculty view
insert into faculty
values('30765', 'Green', 'Music');- 이 value들은 instructor relation에 추가된다. 그렇다면, salary는 어떡하냐
- 이때부터 어떤 DB냐에 따라 방식이 달라진다. 두 가지의 접근 방식이 있다
- Reject the insert
- Inset the tuple ('30765', 'Green', 'Music', null)
Some update cannot be translated uniquely
create view instructor_info as
select ID, name, building
from instructor, department
where instructor.dept_name = department.dept_name;
insert into instructor_info
values('69987', 'White', 'Taylor')
// 골치아픈 문제가 생긴다...Issue
- 만약 'Taylor' 빌딩에 여러 학과가 있으면, 어떤 학과를 선택할래
- 만약 'Taylor' 빌딩에 학과가 없으면?
- instructor_info view에는 어떻게 하든 insert의 결과로 ('69987', 'White', 'Taylor')라는 튜플이 존재할 수 없다.
Most SQL implementations allow updates only on simple views
- The from clause has only one database relation
- The select clause contains only attribute names of relation, and does not have any expressions, aggregates, or distinct specification
- Any attribute not listed in the select clause can be set to null
- The query does not have a group by or having clause
create view history_instructors as
select *
from instructor
where dept_name = 'History';
insert into history_instructors
values('25566', 'Brown', 'Biology', 100000)
// 무슨 일이 생길까?- Views can be defined with a with check option clause at the end of the view definition
- inserted tuple이 view의 clause condition을 만족하지 못한다면, insertion은 reject된다.
- Updates are similarly rejected
