7.5 뷰 설계

7.5.1 뷰의 특징

1.테이블의 구조를 단순화한다.

• <주문>과 주문의 상세내용을 담고 있는 <주문목록> 테이블이 있고 이들이 항상 조인되어 사용된다면 뷰를 만들어 사용함으로써 쿼리문을 간소화시킬 수 있다.

• (?) 그렇다면 애초 테이블 설계시 하나의 테이블로 만들면 될 것을 분리해 놓고 막상 개발시는 두 테이블을 하나로 합친 뷰를 만들어 사용하는가?
• ->테이블을 하나로 합쳐 놓은 다면 주문번호,신청자명처럼 1쪽의 데이타는 중복이 일어나 디스크용량을 차지하게 된다.이 또한 정규화의 대상이 될 것이다. 그러나 뷰로 만든다면 효과는 하나의 테이블과 똑같은 효과를 내면서 sql문만 저장되기에 디스크 용량을 차지하는 일은 없을 것이다.

2.다양한 관점에서 데이타를 제시한다.

• 많은 부서에서 수 많은 직원이 사용하는 테이블이 있지만 그 테이블에 있는 모든 칼럼을 보여줄 필요없이 각 사용자에게 필요한 칼럼만을 뷰로 만들어 제공할 수 있다.

3.데이타 보안유지

• 사원테이블에는 학력등 인사담당자 외에는 제공되어서는 안되는 민감한 정보들이 있을 수 있다. 이때 테이블로만 제공한다면 어쩔 수 없이 모든 이에게 민감한 정보가 공개될 수밖에 없지만 뷰로 각 유저에게 필요한 만큼의 정보만을 제공할 수 있다.

4.논리적인 데이타의 독립성을 제공한다.

• 뷰의 근거가 되는 테이블의 구조가 변경되어도 뷰는 수정할 필요가 없다. 사원테이블에 취미라는 칼럼이 추가되었다면 취미칼럼을 필요로 하는 뷰를 제외한 나머지 뷰의 쿼리문은 수정할 필요는 없다.
• (?)사원테이블에 취미라는 칼럼이 있었는데 어느 날 없어진다면 당근 취미를 조회하는 뷰의 쿼리문은 변경되어야 할 것이다.

5.데이타의 select기능은 제한이 없으나 입력,수정,삭제는 일부 제약이 있을 수 있다.

6.뷰에는 인덱스,클러스터링을 지정할 수 없다.

7.5.2 뷰의 정의

1.뷰의 대상이 되는 테이블

• 1)외부 시스템과 인터페이스에 관여하는 테이블
• 2)크러드메트릭스에서 자주 조인되는 테이블들
• 3)많은 쿼리문에서 인라인 뷰 방식으로 접근되는 테이블은 인라인 뷰 쿼리로 뷰를 만든다.

2.뷰의 대상이 되는 칼럼선정

• 사용하는 프로세스,유저등급등을 고려하여 원하는 대로 칼럼을 지정하여 뷰를 만들 수 있다.

3.뷰 정의서 작성

• 1)뷰명:뷰 이름 기록
• 2)설명:뷰의 기능 기록
• 3)관련테이블:뷰가 생성되기 위한 원래의 테이블명
• 4)칼럼명:뷰 내에 포함될 칼럼 이름
• 5)데이타 타입:칼럼의 데이타 타입