데이터베이스 뷰
IT위키
더 많은 작업
- 관계형 데이터베이스에서 기본 테이블로부터 파생하여 만든 가상의 테이블
- 사용자에게 접근이 허용된 제한된 데이터만 보여주기 위해 구성
- 저장장치 내에 물리적으로 존재하지 않지만 사용자 입장에선 동일하게 보여짐
- 데이터 임시 열람, 보안적인 목적으로 제한된 범위 내 데이터 제공 등의 목적으로 사용될 수 있다.
뷰에 INSERT·UPDATE·DELETE 를 하면 DBMS 는 그 변경을 기본 테이블의 변경으로 바꾸어 실행해야 한다. 뷰의 한 행이 기본 테이블의 어느 행에 해당하는지 하나로 정해지지 않으면 바꿀 수 없으므로, 이론에서는 다음 뷰를 변경할 수 없는 뷰로 본다.
| 변경할 수 없는 뷰 | 이유 |
|---|---|
| 두 개 이상의 테이블을 조인해 정의한 뷰 | 뷰의 한 행이 여러 기본 테이블 행에서 나와, 무엇을 바꿀지 모호하다 |
| DISTINCT, GROUP BY(HAVING) 를 쓴 뷰 | 여러 행이 한 행으로 합쳐져 원래 행으로 되돌릴 수 없다 |
| 집계 함수를 쓴 뷰 | 합계·평균 값을 바꾸는 것을 기본 테이블 행의 변경으로 옮길 수 없다 |
| 열이 상수, 산술식, 함수로 만들어진 뷰 | 계산된 값은 기본 테이블에 저장된 열이 아니다 |
| 기본 테이블의 기본 키(또는 NOT NULL 열)를 포함하지 않는 뷰 | 뷰로 행을 넣으면 기본 키 값이 비게 되어 삽입할 수 없고, 갱신할 행을 키로 정할 수 없다 |
실제 DBMS 는 조건을 조금 더 구체적으로 정한다. PostgreSQL 은 FROM 절에 테이블(또는 갱신 가능한 뷰)이 하나만 있고, 최상위에 WITH·DISTINCT·GROUP BY·HAVING·LIMIT·OFFSET 과 UNION·INTERSECT·EXCEPT 가 없으며, SELECT 목록에 집계·윈도 함수가 없는 단순 뷰만 자동으로 갱신할 수 있게 하고, 기본 테이블 열을 그대로 참조한 열만 값을 바꿀 수 있게 한다.[1] 이런 조건 밖의 뷰도 INSTEAD OF 트리거나 규칙을 달면 변경할 수 있고, Oracle 처럼 키가 보존되는 조인 뷰의 일부 열을 갱신하게 하는 DBMS 도 있다.
뷰는 갱신 가능성으로 보면 세 겹의 포함 관계를 이룬다.
| 범위 | 뷰 | 뜻 |
|---|---|---|
| 가장 넓다 | 사용자가 정의할 수 있는 모든 뷰 | SELECT 문으로 만들 수 있는 뷰 전부. 조인·집계·DISTINCT 를 써도 된다 |
| 중간 | 이론적으로 갱신 가능한 뷰 | 뷰에 대한 삽입·삭제·변경을 기본 테이블의 변경으로 하나로 정해서 옮길 수 있는 뷰 |
| 가장 좁다 | 상용 관계 DBMS 가 갱신을 허용하는 뷰 | 제품이 실제로 갱신을 받아 주는 뷰. 보통 테이블 하나에서 열을 그대로 가져온 단순 뷰 |
- 실버샤츠(Silberschatz)는 조인 뷰에 행을 넣으면 어느 부서 행과 짝지을지 정할 수 없는 것처럼 하나로 옮길 수 없는 변경과 아예 옮길 수 없는 변경이 있다고 들고, 대부분의 SQL 구현은 FROM 절에 릴레이션이 하나이고 SELECT 절에 식·집계·DISTINCT 가 없으며 GROUP BY·HAVING 이 없는 단순 뷰만 갱신을 허용한다고 정리한다.[2]
- PostgreSQL 도 이런 조건을 갖춘 단순 뷰만 '자동으로 갱신 가능한 뷰'로 다루고, 그 밖의 뷰는 INSTEAD OF 트리거나 규칙을 달아야 변경할 수 있게 한다.[3]
- 코드(E. F. Codd)의 관계형 규칙 6(뷰 갱신 규칙)은 이론적으로 갱신 가능한 뷰는 시스템도 모두 갱신할 수 있어야 한다고 요구하지만, 상용 제품은 판정이 쉬운 일부만 허용한다. 그래서 상용 DBMS 가 허용하는 뷰는 이론적으로 갱신 가능한 뷰 안에 들어간다. 상용 DBMS 가 이론보다 넓게 갱신을 허용한다고 보면 틀린다
DBMS 가 뷰를 참조하는 질의를 실행하는 방법은 두 가지다.
- 질의 변경(query modification, 뷰 펼치기) - 질의에 나온 뷰 이름을 뷰 정의(SELECT 문)로 바꾸어, 기본 테이블에 대한 질의 하나로 고쳐 쓴 뒤 실행한다. 뷰의 칼럼은 정의에서 그 칼럼을 만든 기본 테이블의 칼럼으로 바뀌고, 뷰 정의의 WHERE 조건(조인 조건 포함)과 질의의 WHERE 조건이 AND 로 합쳐진다. 보통의 뷰는 이 방식으로 처리한다
- 뷰 실체화(view materialization) - 뷰의 결과를 실제 테이블로 만들어 저장해 두고 질의는 그 테이블을 읽는다. 기본 테이블이 바뀌면 저장된 결과도 고쳐야 한다(실체화 뷰, materialized view). 실체화 뷰는 보통의 뷰를 만드는 CREATE VIEW 가 아니라 CREATE MATERIALIZED VIEW 문으로 만든다. 질의 결과를 담는 데이터베이스 객체이며, FROM 절에 테이블·뷰·다른 실체화 뷰를 쓸 수 있다[4]
- 보통의 뷰는 CREATE VIEW, 실체화 뷰는 CREATE MATERIALIZED VIEW, 기본 테이블은 CREATE TABLE 로 만든다. "실체화 뷰는 CREATE VIEW, 그렇지 않은 뷰는 CREATE TABLE 로 만든다"는 설명은 둘을 뒤바꾼 데다 보통의 뷰를 테이블로 착각한 것이다
CREATE VIEW V_SEOUL (이름, 사번, 부서명) AS
SELECT E.이름, E.사번, D.부서명 FROM EMP E, DEPT D
WHERE E.부서번호 = D.부서번호 AND D.지역 = '서울';
SELECT 이름 FROM V_SEOUL WHERE 부서명 = '총무';
-- 질의 변경 결과
SELECT E.이름 FROM EMP E, DEPT D
WHERE E.부서번호 = D.부서번호 AND D.지역 = '서울' AND D.부서명 = '총무';
- 뷰의 '이름'은 정의에서 E.이름 이었으므로 E.이름 으로 바뀐다. 기본 테이블의 어느 칼럼인지 정의를 따라가야 한다
- 뷰 정의의 조인 조건(E.부서번호 = D.부서번호)을 빠뜨리면 두 테이블의 카티션 곱이 되어 결과가 달라진다. 변경된 질의에는 뷰 정의의 조건이 모두 남아 있어야 한다
"뷰 정의에 ORDER BY를 쓸 수 없다", "뷰는 ALTER문으로 변경할 수 없다"는 정보처리기사 등 이론 시험에서 자주 나오는 설명이지만, 모든 DBMS에 맞는 말은 아니다.
| 구분 | 오라클 | SQL Server |
|---|---|---|
| 뷰 정의 SELECT의 ORDER BY | 쓸 수 있다 | TOP 절(또는 OFFSET 절)과 함께 쓸 때만 쓸 수 있다 |
| ALTER VIEW로 정의(SELECT문) 변경 | 할 수 없다. CREATE OR REPLACE VIEW로 다시 정의한다. ALTER VIEW는 재컴파일(COMPILE)이나 제약조건 변경에 쓴다 |
할 수 있다. ALTER VIEW 뷰이름 AS SELECT ...
|
CREATE VIEW V_EMP AS
SELECT 사번, 이름, 급여 FROM EMP WHERE 부서 = 'IT'
ORDER BY 급여 DESC; -- 오류 없이 만들어진다
SELECT * FROM V_EMP; -- 박민수 6000, 김철수 5000 순서로 나온다
ALTER VIEW V_EMP AS SELECT 사번 FROM EMP;
-- ORA-00922: missing or invalid option
CREATE OR REPLACE VIEW V_EMP AS
SELECT 사번, 이름 FROM EMP ORDER BY 사번; -- 정의는 이렇게 바꾼다
CREATE VIEW V_EMP AS
SELECT 사번, 이름, 급여 FROM EMP ORDER BY 급여 DESC; -- 오류
CREATE VIEW V_EMP AS
SELECT TOP (3) 사번, 이름, 급여 FROM EMP ORDER BY 급여 DESC; -- 가능
ALTER VIEW V_EMP AS
SELECT 사번, 이름 FROM EMP; -- 정의 변경 가능
- SQL Server에서 TOP과 함께 쓴 ORDER BY는 어떤 행을 고를지만 정한다. 뷰를 조회한 결과가 그 순서로 나온다는 보장은 없으며, 순서가 필요하면 뷰를 조회하는 쿼리에 ORDER BY를 쓴다.
- 오라클에서도 결과 순서가 꼭 필요하면 뷰를 조회하는 바깥 쿼리에 ORDER BY를 쓰는 것이 안전하다.
- 이론 시험(정보처리기사 등)의 "뷰 정의에 ORDER BY 불가, ALTER로 변경 불가"는 일반론으로 출제된다. 문제의 보기가 이 설명을 기준으로 하는지 확인한다.
- SQL 개발자 시험처럼 오라클을 기준으로 하는 문제에서는 뷰 정의에 ORDER BY를 쓸 수 있고, 정의 변경은
CREATE OR REPLACE VIEW로 한다. - 뷰의 장점: 독립성(테이블 구조가 바뀌어도 뷰를 쓰는 응용은 그대로), 편리성(복잡한 질의를 단순하게), 보안성(보여 줄 칼럼·행만 공개)
- ↑ 「CREATE VIEW - Updatable Views」, PostgreSQL Documentation, https://www.postgresql.org/docs/current/sql-createview.html, 확인일: 2026-11-04.
- ↑ Silberschatz, Korth, Sudarshan, 「Database System Concepts 7th Edition - Chapter 4: Intermediate SQL」 강의 슬라이드, https://www.db-book.com/slides-dir/PDF-dir/ch4.pdf, 확인일: 2026-11-04.
- ↑ 「CREATE VIEW」, PostgreSQL Documentation, https://www.postgresql.org/docs/current/sql-createview.html, 확인일: 2026-11-04.
- ↑ 「CREATE MATERIALIZED VIEW」, Oracle Database SQL Language Reference 19c, https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/CREATE-MATERIALIZED-VIEW.html, 확인일: 2026-11-05.
- Ramez Elmasri·Shamkant B. Navathe, 『Fundamentals of Database Systems』 7판, Pearson, 2016, 7.3절 「Views (Virtual Tables) in SQL」 - View Implementation
- PostgreSQL Documentation - Views and the Rule System