SQL에서의 관계형 뷰(View)
관계형 뷰(Relational Views): A view is single virtual table that is derived from other tables
Views는 대부분 read-only : 보는 것에 목적이 있다.
내가 볼 수 있는 형태의 view로 재생산
from Base Tables or other (previously defined) views => SQL Views 생성해서 보여줌.
Relational Views in SQL
1) view의 속성
• 테이블은 physical하게 디스크에 존재하는 파일들이다. 테이블 당 각각 파일.
• view는 가상. 순간적으로 즉석에서 만든 것. 테이블에서 긁어와서 보여주고, user가 나가면 사라짐.
• base table에서만 original 정보가 있고, 그걸 가져와서 보여주기만 하는것.
• 볼 수만 있음. 수정 불가능 (참조무결성 때문)
• 고객에게 제공하고 유령처럼 사라짐.
• 꼭 Base Table이 아니라 다른 view들로부터도 상위 view를 만들 수 있음.
• 그렇게 만들 수 있도록 미리 허락을 받아놓는 것이 CREATE VIEW
2) 특징
• One or more source tables make up a view
• Query follows “SELECT STATEMENT” format
- The view attribute names can be inherited from the attribute names of the tables in the defining query: 속성 상속 or 속성 나열(DEPT_INFO)
• Views generally read-only
• Views don’t require additional storage
3) 뷰 장점
• 논리적 독립성 제공
• 데이터 접근 제어로 보안성 제공
• 뷰로 SQL문을 간단하게 함.
• 여러 사용자의 상이한 응용이나 요구 지원
4) 뷰 단점
• 뷰 정의를 변경할 수 없음(DBMS에 따라 허용하는 경우도 있음)
• 삽입, 삭제, 갱신 연산에 많은 제한을 가짐. (이론적으로 변경이 가능한 경우라도 실제로는 변경이 허용되지 않는 경우가 있음.)
[질의] There are no limitations on querying a view
• view는 JOIN이 안되고, SELECTION만 수행 ➡️ 훨씬 싸고 편함.
• 빈도수가 많은 질의들을 단순화할 수 있음
• 근원 테이블이 갱신되면, 파생 view를 최신으로 바꿔줘야 함
• 그렇기 때문에 view는 definition 때 구성되지 않고, 그 view에 대한 질의가 명시되는 시점에서야 구성된다.
[갱신] A view does not necessarily exist in physical form, which limits the possible update operations that can be applied to views. (물리적 실체로 존재X. 갱신X)
* View 삭제
뷰를 없애고 싶을 때: DROP VIEW 사용
• 뷰는 보안/권한 문제가 중요할 때 사용된다.
View 구현
• 뷰는 데이터의 신선도를 위해서, 질의를 줬을 때 즉석으로 갖다 준다.
• 질의를 위한 view의 효율적 구현 전략
전략1) Query modification approach (질의 변환 전략)
- 생성 시) 필요한 때, 요구된 형태로 뷰 테이블을 가상으로 만든다.
물리적 형태로 뷰 내용 저장X
- 질의 시) 뷰 테이블에 대한 질의가 들어오면, 이 질의를 기반이 된 Base Table에 대한 질의로 변환함.
modification은 DBMS가 해줌.
Base table에 대한 쿼리를 가져와야 오리지널 쿼리를 base table에 대한 쿼리로 변환함.
- 단점) 변환 수행될 질의의 원래 형태가 매우 복잡해서 수행시간이 많이 드는 질의라면, 뷰에 대한 질의는 비효율적일 것임. (시간 오래 걸릴 수 O)
전략2) View materialization (뷰를 물리적 Table로 만드는 전략)
- 생성 시) 초기 VT 생성 시, 가상이 아닌 물리적 T로 생성한다. (하드디스크에 저장됨)
- 질의 시) 이후 따르는 질의도 본 T에서 계속 수용한다.
연이은 질의가 나온다는 확신이 있을 때, 그렇다고 가정, 민감한 정보 아닐 때, 잘 안 바뀌는 정보일 때
- 갱신 시) 만약, Base T이 수정된다면, View T도 따라서 수정
base가 연결되어 있으니까 base가 바뀌면 View도 바뀜
- Incremental update strategy for materialized views
: DBMS는 추후 연속될 갱신들에 대해 유지 책임을 져야 한다.
만들어진 물리적 파일에 대해 유지 책임을 가져야 함. base table까지 연관시켜서.
* 뷰 물리화 처리 방안들
1) immediate update strategy(즉각, 항상)
: 갱신이 들어올 때마다 즉각적으로 수정. 항상 바꿈. 쿼리의 빈도수가 낮을 때.
2) lazy update strategy(지연, 필요시)
: 모았다가, 로그가 다 차면 한꺼번에 묶어서 처리 (일정한 양이 되면 한번에 수정)
3) periodic update strategy(주기적, 정기적)
: 특정 시간이 지난 이후에 한번에 수정
View 갱신하기
희망사항: view의 갱신이 base table의 갱신으로 연결되었으면 좋겠다!
뷰 쿼리와 데이터베이스 사이에 매핑
▶ 사용자 의도에서 벗어나지만, 특정한 목적에 의해서는 허락해줄 수 있다.
하지만 DEPT_INFO view의 TOTAL_SAL 속성을 갱신하는 등 어떤 뷰 갱신은 의미 없다.(base에 영향 X)
평균이나 합계 등을 조작하는 건 허용하지 않음. MODIFY 쿼리 불가
뷰에 대한 쿼리는 언제나 다 해주는 게 아니라 할 수 있는 것만 해준다.
• View involving JOINs: 때로는 사용자가 의도한 갱신이 불가능할 때도 있다.
- 뷰와 베이스, 뷰와 뷰를 조인, 조인된 값을 변경하려고 할 때 안 될 수 있음.
<갱신이 가능한 뷰>
1) 하나의 베이스 테이블로부터 select 및 project 연산을 통해 정의된 뷰이어야 함.
2) 뷰 내의 한 속성이 베이스 테이블의 기본키 속성을 포함해야 함.
<⭐️갱신이 불가능한 뷰⭐️>
- 기본키를 가지는 뷰에 대해서는 갱신 불가능 (참조무결성 제약조건 위반)
- 뷰의 속성이 상수, 내장 함수, 연산식, 집단화 함수로부터 유도된 경우
- 뷰를 정의할 때 GROUP BY 구문을 포함해서 생성된 뷰
- 뷰를 정의할 때 FROM 구문에 여러 개의 테이블이 명시된 조인 뷰
- 갱신이 불가능한 뷰로부터 유도된 뷰
• WITH CHECK OPTION 절
- view를 유지하는 동안, 갱신된 튜플들을 base table과 같게 유지하기 원한다면, View definition 마지막에 WITH CHECK OPTION 옵션을 쓰면 된다.
- 뷰 테이블을 업데이트하려고 할 때
- 베이스 테이블까지 업데이트하고 싶을 때
* Views as authorization mechanism
• SQL query 권한 부여 문장인 GRANT(허락하는 명령어)와 REVOKE(허락했던 사실을 철회)를 사용함.
ex) Grant SELECT on V to B: View에 대한 SELECT를 B에게 허가함.
• View들은 권한이 없는 사용자들이 특정한 속성이나 튜플에 접근할 수 없도록, 정보를 감추는 목적으로 사용될 수 있다.
마무리
정보감리사 2022년 기출문제
