1. Join operations
course에는 CS-347에 대한 정보가 존재하지 않고, prereq 에는 CS-315에 대한 정보가 존재하지 않는다.
=> natural join을 실행하면 누락되는 정보가 생긴다. (선수과목이 없는 과목은 나타낼 수 없게 된다)
이러한 문제를 해결하기 위해서 Outer Join을 수행할 수 있다.
2. Outer Join
Outer Join은 양쪽의 relation에 join을 수행할 때 서로 공통으로 가지지 않는 tuple도 결과 relation에 포함시키며,
누락된 attribute를 null 값으로 채우는 것이다. Outer Join과 구분하기 위해서 기존의 Join 방법을 Inner Join이라고 부른다.
- natural left outer join
이 경우 왼쪽 relation에 존재하는 tuple들을 기준으로 오른쪽 relation 의 tuple과 natural join을 수행하며, 오른쪽 relation에 존재하지 않는 값을 null로 채우는 것이다. 이러한 방법을 통해 선수과목을 가지지 않는 과목 또한 누락하지 않고 relation에 포함할 수 있다.
- natural right outer join
이 경우 현재 예제에서는 의미있는 결과를 반환하진 못하지만, 오른쪽 relation에 존재하는 tuple들을 기준으로 왼쪽 relation 의 tuple과 natural join을 수행하며, 왼쪽 relation에 존재하지 않는 값을 null로 채우는 것이다.
- natural full outer join
이 경우는 앞의 두 방법을 합친 것이다.
3. Joined Relations
- Join operations
두 개의 relation을 인자로 받아 하나의 relation을 반환하는 연산이다.
- Join condition
두 relation을 join할 때, 어떤 attribute를 이용하여 연결할 것인지를 설정하며, 어떤 attributes를 보여줄 지를 결정한다.
'On' condition: where 절처럼 사용되고, 조건식의 마지막에 나타납니다.
- Join type
inner join, left outer join, right outer join, full outer join 등의 join 형태 중 하나를 결정한다.
Joined Relations - Example
ex1)
course inner join prereq on
course.course_id = prereq.course_id
위의 결과를 보면, on 절에서 course_id가 같은 tuple들에 대해서 join을 수행하게 했으며, natural join이 아닌 inner join을 사용했기 때문에, course_id가 두 번 나오는 것을 확인할 수 있다.
ex2)
course left outer join prereq on
course.course_id = prereq.course_id
다음 결과를 보면, left outer join을 사용하였기 때문에 course_id의 값이 일치하지 않는 tuple에 대해서도 null값을 사용해 결과에 포함시킨 것을 확인할 수 있다.
4. Views
DB를 사용하는 모든 사용자가 DB의 모든 내용을 보는 것은 효율적이지 않고, 보안상의 이유로 적절하지 않을 수도 있다. 예를 들어 교수들의 정보가 저장되어있는 instructor라는 relation에서 교수의 이름, 학과는 필요할지 몰라도, 연봉에 대한 정보는 불필요할 수 있다.
View는 실제 릴레이션을 기반으로 만들어진 가상 relation으로 실제 relation과 달리 데이터를 실제로 저장하고 있지 않고 논리적으로만 존재한다. 따라서 특정 View가 필요할 때마다 쿼리와 relation을 기반으로 새로 만들어서 사용한다. View를 만드는데 기반이 되는 물리적인 실제 relation을 기본 릴레이션(base relation)이라고 한다.
- View Definition
View를 정의할 때는 create view v as <query expression>를 사용하며, View가 만들어지면, View의 이름(relation의 이름과 사용법이 같음)을 사용하여 참조할 수 있다. 하지만 View가 저장되는 것은 아니다. 오히려 쿼리식을 저장하는 식으로 수행된다. View가 만들어진 상태에서 relation을 수정한다면 View는 수정되지 않는다. 하지만 쿼리식으로 저장되어 있기 때문에 relation을 수정한 뒤에 쿼리식을 다시 실행할 수 있다.
ex)
View 생성
create view faculty as
select ID, name, dept_name
from instructor
만들어진 View 참조
select name
from faculty
where dept_name = 'Biology'
create view departments_total_salary(dept_name, total_salary) as
select dept_name, sum(salary)
from instructor
group by dept_name;
- Views Defined Using Other Views
View를 참조하여 새로운 View를 생성하는 예제
create view physics_fall_2009 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 = '2009';
create view physics_fall_2009_watson as
select course_id, room_number
from physics_fall_2009
where building='Watson';
5. Materialized Views
Materialized Views란 View를 정의한 쿼리문의 결과인 모든 tuple을 물리적 테이블로 저장하는 것이다.
(그럴거면 relation을 새로 만들면 되지 왜 View로 만들지?)
Materialized Views의 기반이 되는 relation이 수정되었을 때, 이 View 또한 수정되어야 한다. 이를 수행하기 위한 방법은 다음과 같은 세 가지가 있다.
- any of the relations on which the view is defined is updated (relation의 수정이 일어날 때마다 업데이트)
- the view is accessed (View가 사용자에 의해 접근되었을 때에만 업데이트)
- systems update materialized views only periodically (사용자의 접근과 상관없이 일정 주기마다 업데이트)
