[SQL] view

뷰(views) 

어떤 경우에는 모든 사용자에게 전체 논리적 모델(즉, 데이터베이스에 저장된 모든 실제 릴레이션)을 보여주는 것이 바람직하지 않을 수 있다.

 

예를 들어, 어떤 사용자가 instructor의 이름(name) 과 소속 학과(dept_name) 는 알아야 하지만, 급여(salary) 는 볼 필요가 없는 상황을 생각해보자.
이 사용자는 다음과 같은 SQL 문으로 정의된 릴레이션을 보게 되어야 한다.

 

SELECT ID, name, dept_name
FROM instructor;

 

뷰(view) 는 특정 사용자로부터 특정 데이터를 숨기는 메커니즘을 제공한다.

개념적 모델에 속하지 않지만, 사용자에게 보여지는 릴레이션은 "가상 릴레이션(virtual relation)"이라 불리며, 이를 뷰(view) 라고 한다.

 

 

이렇게 보면 SELECT 컬럼 FROM 테이블 WHERE 조건 으로 원하는 조건을 볼 수 있는데 왜 view를 쓰는걸까?

 

 

 

뷰(views) 를 사용하는 이유

 

1. 보안 및 접근 제어

• 예: 어떤 사용자는 salary 컬럼은 보면 안 되고, name, dept_name만 볼 수 있어야 할 때
• VIEW를 만들고, 해당 사용자에게 그 뷰만 접근 허용하면 됨

CREATE VIEW instructor_public AS
SELECT ID, name, dept_name FROM instructor;
-- 사용자에게 instructor_public만 권한 부여

 

 * WHERE절로 필터링하면 그걸 아는 사람만 필터를 거는 거고, 강제할 수는 없음

 

 

2. 복잡한 쿼리를 간단하게 재사용

• 복잡한 조인, 집계, 계산이 들어간 쿼리를 자주 사용할 때

 

CREATE VIEW course_summary AS
SELECT c.dept_name, COUNT(*) AS course_count
FROM course c
GROUP BY c.dept_name;

 

=> 이제부터는 간단하게 SELECT * FROM course_summary 만 쓰면 됨!

 

 

3. 논리적 데이터 모델 단순화 (가상 테이블)

• 여러 테이블이 연결된 복잡한 구조를 사용자에게는 하나의 테이블처럼 보여줄 수 있음

 

CREATE VIEW student_info AS
SELECT s.ID, s.name, d.building
FROM student s
JOIN department d ON s.dept_name = d.dept_name;

 

=>  사용자 입장에서는 그냥 student_info 테이블만 조회하면 됨

 

 

 

4. 변화로부터 보호 (추상화)

• 실제 테이블 구조가 바뀌더라도, 뷰를 유지하면
  기존 쿼리들은 뷰만 바라보므로 변경을 최소화할 수 있음

 

5. 쓰기 방지 (읽기 전용)

• VIEW에 따라 쓰기 권한을 제한할 수 있어
  예를 들어, 급여나 민감한 데이터가 있는 테이블에 직접 INSERT/UPDATE 못 하도록 막을 수 있음

 

 

뷰의 정의(view definition)

뷰(view)**는 create view 구문을 사용하여 정의되며, 그 형식은 다음과 같다.

 

create view v as <query expression>

 

여기서 <query expression>은 어떤 합법적인 SQL 표현식도 가능하며, v는 뷰의 이름을 나타낸다.

 

뷰의 정의는 쿼리 표현식을 평가하여 새로운 릴레이션을 생성하는 것과는 다르다.

오히려, 뷰 정의는 쿼리 식을 저장하고, 그 식을 뷰 이름을 통해 쿼리에 대체(substitute) 하도록 만든다.

 

즉, 뷰는 실제 테이블을 저장하는 게 아니라, 쿼리를 저장해 두고 마치 테이블처럼 사용하는 것이다.

 

 

 

실체화 뷰 (Materialized Views)

 

일부 데이터베이스 시스템은 뷰를 물리적으로 저장하는 것을 허용한다.

뷰가 정의될 때 **실제 복사본(데이터 사본)**이 생성된다.

이러한 뷰를 **실체화 뷰(Materialized view)**라고 한다.

 

쿼리에 사용된 릴레이션(기본 테이블들)이 변경되면, 실체화 뷰의 결과는 최신 상태가 아니게 된다.

따라서 뷰를 유지 관리(maintain) 해야 하며, 이는 기본 테이블이 갱신될 때마다 뷰도 함께 갱신해야 함을 의미한다.

 

 

 

뷰의 갱신 (Update of a View)

 

갱신 가능한 뷰의 조건 (모두 만족해야 가능)

✅ 단일 기본 테이블 기반일 것	뷰는 반드시 하나의 테이블만 참조해야 함 (JOIN 사용 시 불가)
✅ 집계 함수 없음	SUM, AVG, COUNT 같은 집계가 있으면 갱신 불가
✅ DISTINCT 사용 안 함	중복 제거는 어느 행을 갱신해야 할지 모호하게 만듦
✅ GROUP BY / HAVING 없음	집계된 그룹 데이터는 개별 행을 추적할 수 없어 갱신 불가
✅ 계산된 컬럼 없음	price * 1.1 같은 표현식은 원본 컬럼이 아님
✅ 모든 NOT NULL 컬럼이 포함되어야 함	NOT NULL 컬럼을 포함하지 않으면 INSERT가 불가능함
✅ PRIMARY KEY나 유일한 식별자가 포함되면 더 안정적	갱신 시 어떤 행을 바꿔야 하는지 명확해짐

 

---

 

갱신 불가능한 경우 예시 

CREATE VIEW v AS SELECT name, AVG(salary) FROM instructor GROUP BY name;	집계 함수, GROUP BY 있음
CREATE VIEW v AS SELECT * FROM instructor JOIN department ON ...;	JOIN 사용
CREATE VIEW v AS SELECT DISTINCT dept_name FROM instructor;	DISTINCT 사용
CREATE VIEW v AS SELECT ID, name, 'CS' AS dept_name FROM instructor;	계산된 컬럼 있음

 

                                                             출처 : CahtGPT 4.0

 

결론 : view는 갱신이 가능할 수도 불가능 할 수도 있다.

 

 

요약

 

VIEW는 창문이다.

 

원본 테이블이 바뀌면 창문을 통해 보이는 뷰의 내용도 즉시 달라진다. (자동 반영)

 

뷰가 업데이트 가능하다면 창문을 통해 손을 뻗어서 원본 집(instructor)을 바꿀 수도 있다.
(즉, INSERT, UPDATE, DELETE가 가능할 수도 있다.)

 

 

 

 

Materialized View는 사진이다.

 

테이블의 쿼리 결과를 딱 한 순간 찍어서 복사해 둔 것이다.

 

테이블이 바뀌어도 사진은 그대로다. → 자동으로 반영되지 않음

그래서 갱신(refresh)이 필요하고, 이건 "사진을 다시 찍는 행위"라고 볼 수 있다.