PostgreSQL 8.3.3문서
Prev Fast Backward Chapter 35. 룰 시스템 Fast Forward Next

35.2. 뷰와 룰 시스템

PostgreSQL에 있어서의 뷰는 룰 시스템을 사용해 구현되고 있습니다. 실제, 

CREATE VIEW myview AS SELECT * FROM mytab;

과의 2개의 명령의 사이에는 기본적인 차이는 없습니다. 

CREATE TABLE myview (
same column list as mytab
);
CREATE RULE "_RETURN" AS ON SELECT TO myview DO INSTEAD
    SELECT * FROM mytab;

이렇게 말하는 것은, CREATE VIEW명령에 의해 내부적으로 완전히 같은 명령을 하기 때문입니다. 그러나 부작용도 있습니다. 그 한 가지는 PostgreSQL시스템 목록의 뷰에 대한 정보는 테이블의 정보와 동일해서, 파서에 있어서도 테이블과 뷰는 같은 것이 된다는 것입니다. 이것들은 같은 것, 즉 릴레이션입니다.

35.2.1. SELECT룰의 활동

비록 명령이 INSERT, UPDATE, DELETE등이어도, ON SELECT룰은 모든 쿼리에 대해 마지막에 적용됩니다. 그리고, 이 룰은 다른 명령 종류의 룰과 다른 의미론을 가지고 있어, 퀄 트리를 신규에 생성하지 않고, 그 곳에 있는 것을 수정합니다. 따라서 SELECT룰이 제일 처음에 기술되지 않으면 안됩니다.

현재로서는, ON SELECT룰에서는 1개의 액션 밖에 허용되지 않고, 그것은 INSTEAD인 무조건의 SELECT액션이 아니면 안됩니다. 이 제약은, 일반의 사용자가 무엇을 해도, 룰 시스템이 견뢰하기 때문에 필요하고, ON SELECT의 룰은 뷰 같은 동작으로 한정됩니다.

본장의 예로서 들고 있는 것은, 약간의 연산을 하는 2개의 결합의 뷰와 다음에 이러한 기능을 이용하는 몇개의 뷰입니다. 최종 결과가 어떠한 마법의 기능에 의해 마치 실제 테이블과 같이 행동하는 뷰가 되도록, 처음의 2개의 뷰 가운데 하나는, INSERT, UPDATE, DELETE조작에 대한 룰을 다음에 추가하는 것으로 커스터마이즈 됩니다. 처음으로 배우기 위한 예로서는 결코 간단하지 않고 먼저 진행되는 것을 어렵게 할 수도 있습니다. 많은 다른 예를 꺼내 머리속을 혼란시키는 것다도, 모든 논점을 단계마다 쫓는 1개의 예를 드는 편이 좋을 것입니다.

이 예에서는, 2개의 정수로부터 작은 값을 돌려주는 약간의 min함수를 필요로 합니다. 함수의 생성은 이하와 같이 합니다. 

CREATE FUNCTION min(integer, integer) RETURNS integer AS $$
    SELECT CASE WHEN $1 < $2 THEN $1 ELSE $2 END
$$ LANGUAGE SQL STRICT;

최초의 두 개의 룰 시스템의 설명에 필요로 하는 실제 테이블을 이하에 나타냅니다. 

CREATE TABLE shoe_data (
    shoename   text,         --  주키
    sh_avail   integer,        -- 재고
    slcolor    text,          -- 가능한 신발끈의 색
    slminlen   real,          -- 신발끈의 최단 사이즈
    slmaxlen   real,          -- 신발끈의 최장 사이즈
    slunit     text           -- 길이의 단위
);

CREATE TABLE shoelace_data (
    sl_name    text,          -- 주키
    sl_avail   integer,       -- 재고
    sl_color   text,          -- 신발끈의 색
    sl_len     real,          -- 신발끈의 길이
    sl_unit    text           -- 길이의 단위
);

CREATE TABLE unit (
    un_name    text,          -- 주 키
    un_fact    real           -- cm로 변환하는 팩터
);

보이는 것처럼, 이것들은 신발가게의 데이터를 나타내고 있습니다.

뷰를 이하와 같이 작성합니다. 

CREATE VIEW shoe AS
    SELECT sh.shoename,
           sh.sh_avail,
           sh.slcolor,
           sh.slminlen,
           sh.slminlen * un.un_fact AS slminlen_cm,
           sh.slmaxlen,
           sh.slmaxlen * un.un_fact AS slmaxlen_cm,
           sh.slunit
      FROM shoe_data sh, unit un
     WHERE sh.slunit = un.un_name;

CREATE VIEW shoelace AS
    SELECT s.sl_name,
           s.sl_avail,
           s.sl_color,
           s.sl_len,
           s.sl_unit,
           s.sl_len * u.un_fact AS sl_len_cm
      FROM shoelace_data s, unit u
     WHERE s.sl_unit = u.un_name;

CREATE VIEW shoe_ready AS
    SELECT rsh.shoename,
           rsh.sh_avail,
           rsl.sl_name,
           rsl.sl_avail,
           min(rsh.sh_avail, rsl.sl_avail) AS total_avail
      FROM shoe rsh, shoelace rsl
     WHERE rsl.sl_color = rsh.slcolor
       AND rsl.sl_len_cm >= rsh.slminlen_cm
       AND rsl.sl_len_cm <= rsh.slmaxlen_cm;

shoelace뷰(지금 있는 제일 간단한 뷰)용의 CREATE VIEW명령은, shoelace릴레이션을 쿼리 범위 테이블 중에서 shoelace릴레이션이 참조될 때는 언제라도 적용되어야 할 재작성 룰의 존재를 나타내는 항목을 pg_rewrite에 만듭니다. 룰은 룰 조건(SELECT룰은 현재 가질 수 없기 때문에, 비SELECT룰에서 다룹니다)을 가지지 않는 INSTEAD입니다. 룰 조건은 쿼리 조건과는 다른 것에 주의해 주세요! 룰 동작은 쿼리 조건을 가지고 있습니다. 이 룰 동작은, 뷰 작성 명령내의 SELECT명령문의 복사인, 1개의 쿼리 트리입니다.

Note: pg_rewrite항목의 NEW와 OLD (역사적인 이유에 의해, 출력용의 쿼리 트리에서, *NEW*나 *CURRENT*라는 이름이 붙어 있습니다)에 대한 2개의 특별한 범위 테이블 항목은 SELECT룰 과는 관계가 없습니다.

그럼 여기서 unit shoe_data, shoelace_data에 데이터를 넣어 뷰에 간단한 쿼리를 실시합니다. 

INSERT INTO unit VALUES ('cm', 1.0);
INSERT INTO unit VALUES ('m', 100.0);
INSERT INTO unit VALUES ('inch', 2.54);

INSERT INTO shoe_data VALUES ('sh1', 2, 'black', 70.0, 90.0, 'cm');
INSERT INTO shoe_data VALUES ('sh2', 0, 'black', 30.0, 40.0, 'inch');
INSERT INTO shoe_data VALUES ('sh3', 4, 'brown', 50.0, 65.0, 'cm');
INSERT INTO shoe_data VALUES ('sh4', 3, 'brown', 40.0, 50.0, 'inch');

INSERT INTO shoelace_data VALUES ('sl1', 5, 'black', 80.0, 'cm');
INSERT INTO shoelace_data VALUES ('sl2', 6, 'black', 100.0, 'cm');
INSERT INTO shoelace_data VALUES ('sl3', 0, 'black', 35.0 , 'inch');
INSERT INTO shoelace_data VALUES ('sl4', 8, 'black', 40.0 , 'inch');
INSERT INTO shoelace_data VALUES ('sl5', 4, 'brown', 1.0 , 'm');
INSERT INTO shoelace_data VALUES ('sl6', 0, 'brown', 0.9 , 'm');
INSERT INTO shoelace_data VALUES ('sl7', 7, 'brown', 60 , 'cm');
INSERT INTO shoelace_data VALUES ('sl8', 1, 'brown', 40 , 'inch');

SELECT * FROM shoelace;

 sl_name   | sl_avail | sl_color | sl_len | sl_unit | sl_len_cm
-----------+----------+----------+--------+---------+-----------
 sl1       |        5 | black    |     80 | cm      |        80
 sl2       |        6 | black    |    100 | cm      |       100
 sl7       |        7 | brown    |     60 | cm      |        60
 sl3       |        0 | black    |     35 | inch    |      88.9
 sl4       |        8 | black    |     40 | inch    |     101.6
 sl8       |        1 | brown    |     40 | inch    |     101.6
 sl5       |        4 | brown    |      1 | m       |       100
 sl6       |        0 | brown    |    0.9 | m       |        90
(8 rows)

이것은, 뷰에 대한 가장 간단한 SELECT이므로, 이 기회에 뷰 룰의 기본을 설명합니다. SELECT * FROM shoelace는 파서에 의해 처리되어 다음의 쿼리 트리가 생성됩니다. 

SELECT shoelace.sl_name, shoelace.sl_avail,
       shoelace.sl_color, shoelace.sl_len,
       shoelace.sl_unit, shoelace.sl_len_cm
  FROM shoelace shoelace;

이 트리가 룰 시스템에 전해집니다. 룰 시스템은 범위 테이블을 참조해, 릴레이션에 대해서 룰이 존재하는지 조사합니다. shoelace(현시점에서는 유일한 뷰)에 대한 범위 테이블 항목을 처리할 때, 쿼리 트리로 _RETURN룰을 검출합니다. 

SELECT s.sl_name, s.sl_avail,
       s.sl_color, s.sl_len, s.sl_unit,
       s.sl_len * u.un_fact AS sl_len_cm
  FROM shoelace *OLD*, shoelace *NEW*,
       shoelace_data s, unit u
 WHERE s.sl_unit = u.un_name;

뷰를 전개하기 위해서, 재작성은 단순하게 룰의 동작 쿼리 트리를 가지는 서브쿼리 범위 테이블의 항목을 만들어, 뷰를 참조하고 있던 본래 범위 테이블을 옮겨놓습니다. 재작성된 결과의 쿼리 트리는, 이하와 같이 입력했을 경우와 거의 같습니다. 

SELECT shoelace.sl_name, shoelace.sl_avail,
       shoelace.sl_color, shoelace.sl_len,
       shoelace.sl_unit, shoelace.sl_len_cm
  FROM (SELECT s.sl_name,
               s.sl_avail,
               s.sl_color,
               s.sl_len,
               s.sl_unit,
               s.sl_len * u.un_fact AS sl_len_cm
          FROM shoelace_data s, unit u
         WHERE s.sl_unit = u.un_name) shoelace;

그러나 한 가지의 차이가 있습니다. 서브쿼리의 범위 테이블이 2 개의 추가 항목 shoelace *OLD*와 shoelace *NEW*를 가지고 있는 것입니다. 이러한 항목은 서브쿼리의 결합 트리나 대상 리스트로 참조되지 않으므로, 직접 쿼리에서는 사용되지 않습니다. 재작성은 그것들을 사용해, 뷰를 참조한 범위 테이블의 항목에 원래 존재한 접근권한 확인 정보를 저장합니다. 이 방법으로, 재작성된 쿼리에서 직접 뷰를 사용하고 있지 않아도, 집행자는 사용자가 그 뷰에 접근하기 위한 올바른 권한을 가지고 있는지 확인합니다.

이것이 최초로 적용되는 룰입니다. 룰 시스템은 최상정도의 쿼리의 나머지(이 예에서는 더 이상 없습니다)의 범위 테이블의 항목을 계속 체크합니다. 그리고 룰 시스템은, 추가된 서브쿼리의 범위 테이블 항목이 뷰를 참조할지를 반복적으로 확인합니다 (그러나 *OLD*나 *NEW*는 전개하지 않습니다. 그렇지 않으면 무한 반복이 되어 버립니다! ). 이 예에서는 shoelace_data나 unit용의 재작성 룰은 없습니다. 따라서, 재작성이 완결되고, 상기가 플래너에게 건네지는 최종적인 결과가 됩니다.

그런데, 가게에 놓여져 있는 신발끈(의 색과 사이즈)에 일치하는 구두가 가게에 있는지, 완전하게 일치하는 신발끈의 재고수가 2이상 있을지 없을지를 파악하는 쿼리를 써 봅시다. 

SELECT * FROM shoe_ready WHERE total_avail >= 2;

 shoename | sh_avail | sl_name | sl_avail | total_avail
----------+----------+---------+----------+-------------
 sh1      |        2 | sl1     |        5 |           2
 sh3      |        4 | sl7     |        7 |           4
(2 rows)

이번 파서의 출력은 이하의 쿼리 트리입니다. 

SELECT shoe_ready.shoename, shoe_ready.sh_avail,
       shoe_ready.sl_name, shoe_ready.sl_avail,
       shoe_ready.total_avail
  FROM shoe_ready shoe_ready
 WHERE shoe_ready.total_avail >= 2;

최초로 적용되는 룰은 shoe_ready뷰용의 것으로, 쿼리 트리에 있어서의 결과는 이하리 같이 됩니다. 

SELECT shoe_ready.shoename, shoe_ready.sh_avail,
       shoe_ready.sl_name, shoe_ready.sl_avail,
       shoe_ready.total_avail
  FROM (SELECT rsh.shoename,
               rsh.sh_avail,
               rsl.sl_name,
               rsl.sl_avail,
               min(rsh.sh_avail, rsl.sl_avail) AS total_avail
          FROM shoe rsh, shoelace rsl
         WHERE rsl.sl_color = rsh.slcolor
           AND rsl.sl_len_cm >= rsh.slminlen_cm
           AND rsl.sl_len_cm <= rsh.slmaxlen_cm) shoe_ready
 WHERE shoe_ready.total_avail >= 2;

마찬가지로, shoe와shoelace용의 룰은 서브쿼리의 범위 테이블로서 대용되어 3 레벨의 최종 쿼리 트리로 이끕니다. 

SELECT shoe_ready.shoename, shoe_ready.sh_avail,
       shoe_ready.sl_name, shoe_ready.sl_avail,
       shoe_ready.total_avail
  FROM (SELECT rsh.shoename,
               rsh.sh_avail,
               rsl.sl_name,
               rsl.sl_avail,
               min(rsh.sh_avail, rsl.sl_avail) AS total_avail
          FROM (SELECT sh.shoename,
                       sh.sh_avail,
                       sh.slcolor,
                       sh.slminlen,
                       sh.slminlen * un.un_fact AS slminlen_cm,
                       sh.slmaxlen,
                       sh.slmaxlen * un.un_fact AS slmaxlen_cm,
                       sh.slunit
                  FROM shoe_data sh, unit un
                 WHERE sh.slunit = un.un_name) rsh,
               (SELECT s.sl_name,
                       s.sl_avail,
                       s.sl_color,
                       s.sl_len,
                       s.sl_unit,
                       s.sl_len * u.un_fact AS sl_len_cm
                  FROM shoelace_data s, unit u
                 WHERE s.sl_unit = u.un_name) rsl
         WHERE rsl.sl_color = rsh.slcolor
           AND rsl.sl_len_cm >= rsh.slminlen_cm
           AND rsl.sl_len_cm <= rsh.slmaxlen_cm) shoe_ready
 WHERE shoe_ready.total_avail > 2;

다음에 플래너는 이 트리를 2 레벨의 쿼리 트리로 줄입니다. 맨 밑의 SELECT명령은 따로 따로 처리할 필요가 없기 때문에, 2번째의 SELECT에 "끌어옵니다". 그러나 2번째의 SELECT는 집계 함수를 가지기 때문에, 정점으로부터는 구별됩니다. 만약 그것들을 끌어오게되면 맨 위의 SELECT의 동작을 바꾸게 되는데, 그것을 원치는 않습니다. 그러나, 쿼리 트리를 줄이는 최적화를, 재작성 시스템 자신으로 의식할 필요는 없습니다.

35.2.2. 비SELECT뷰 룰 명령문

지금까지의 뷰 룰의 설명에서는 쿼리 트리의 2가지 세부사항에 대하여 다루지 않았습니다. 그것들은, 명령 타입과 결과 릴레이션입니다. 실제, 뷰 룰는 이러한 정보를 필요로 하지 않습니다.

SELECT와 다른 명령에 대한 쿼리 트리의 사이에는 큰 차이는 없습니다. 그것들은 분명하게 다른 명령형을 가지고 있어, SELECT이외의 명령에서, 결과 릴레이션은 결과의 저장소가 되는 범위 테이블의 항목을 지시합니다. 그 이외에는 완전히 같습니다. 따라서, a와 b의 열을 가지는 테이블t1, t2에 대한 이하의 2개의 명령문의 쿼리 트리는, 거의 같습니다. 

SELECT t2.b FROM t1, t2 WHERE t1.a = t2.a;

UPDATE t1 SET b = t2.b FROM t2 WHERE t1.a = t2.a;

이하에, 구체적으로 가리킵니다.

결과적으로, 양쪽 모두의 쿼리 트리는 비슷한 실행 계획이 됩니다. 그것들은 2개의 테이블의 결합입니다. UPDATE에서는 t1로부터 빠져 있는 열은 플래너에 의해 대상 리스트에 추가되어, 최종의 쿼리 트리는 이하와 같이 됩니다. 

UPDATE t1 SET a = t1.a, b = t2.b FROM t2 WHERE t1.a = t2.a;

그리고, 결합을 실행한 집행자의 

SELECT t1.a, t2.b FROM t1, t2 WHERE t1.a = t2.a;

결과 집합과 완전히 같은 결과 집합을 작성합니다. 그러나 UPDATE에 약간의 문제가 있습니다. 집행자는, 결합이 실시하는 처리의 결과가 무엇을 의미하고 있는지 관여하지 않습니다. 집행자는 단지 결과가 되는 행의 집합을 작성할 뿐입니다. 하나는 SELECT명령, 다른 하나는 UPDATE명령인 것의 차이는, 집행자를 호출하는 측에서 다루어집니다. 호출 측은(쿼리 트리를 보면), 이것이 UPDATE인 것을 알고 있어, 이 결과가 테이블t1에 들어가지 않으면 안 되는 것을 알고 있습니다. 그러나, 어떤 행이 새로운 행에 의해 치환되어야만 하는 것일까요?

이 문제를 해결하기 위해, UPDATE문(DELETE문의 경우도 마찬가지)의 대상 리스트에 다른 항목을 덧붙일 수 있습니다. 그것은, 현재의 타풀 ID(CTID)입니다. 이것은 그 행의 파일 블록 번호와 블록 상의 위치를 가지는 시스템열입니다. 테이블을 알고 있는 경우, CTID를 사용해, 본래의 t1행을 추출해 갱신할 수가 있습니다. CTID를 대상 리스트에 추가하면, 쿼리는 이하와 같이 됩니다. 

SELECT t1.a, t2.b, t1.ctid FROM t1, t2 WHERE t1.a = t2.a;

그럼, PostgreSQL의 다른 상세 설명에 들어갑니다. 테이블의 행은 덧쓰기되지 않으므로, ROLLBACK처리는 빠릅니다. UPDATE에서는, (CTID를 없앤 후) 테이블에 새로운 결과행이 삽입되어 CTID가 지시하는 오래된 행의 행 헤더 내의 cmax와 xmax항목은 현재의 명령 카운터와 현재의 트랜잭션 ID로 설정됩니다. 이와 같이 해, 오래된 행은 숨겨져 트랜잭션이 커밋된 후, 진공청소기(vacuum cleaner)에 의해 실제로 삭제할 수 있습니다.

이러한 세부사항을 전부 이해할 수 있으면, 어떤 명령에 대해서도 완전히 똑같이 해, 뷰의 룰을 간단하게 적용할 수가 있습니다. 차이가 없습니다.

35.2.3. PostgreSQL에 있어서의 뷰의 능력

여기까지, 룰 시스템이 어떻게 뷰의 정의를 원래의 쿼리 트리에 통합하는지를 해설했습니다. 두번째 예에서는, 1개의 뷰로부터의 단순한 SELECT에 의해, 최종적으로 4개의 테이블을 결합하는 쿼리 트리가 생성되었습니다(unit는 다른 이름으로 두번 사용되었습니다).

뷰를 룰 시스템으로 구현하는 이점은, 어느 테이블을 검색해야할 것인가, 그러한 테이블간의 관련성, 뷰로부터의 제약 조건, 본래의 쿼리 조건에 관한 정보를 모두, 플래너가 1개의 쿼리 트리안에 가지고 있는 것입니다. 본래의 쿼리가 이미 뷰에 대한 결합일 때도 같습니다. 플래너는 여기서 어떤 것이 쿼리 처리의 최적 경로인지를 결정하지 않으면 안됩니다. 플래너는 보관 유지하는 정보가 많으면 많을수록, 보다 좋은 결정을 내릴 수가 있습니다. 그리고 PostgreSQL에 구현되고 있는 룰 시스템은, 이것이 현시점에서 제공되고 있는 모든 정보임을 보증합니다.

35.2.4. 뷰의 갱신

뷰가 INSERT, UPDATE, DELETE등의 대상 릴레이션으로서 이름이 붙여졌을 경우는 어떻게 되는 것일까요? 위에서 설명한 것 같은 치환을 한 후에, 결과 릴레이션이 서브쿼리의 범위 테이블 항목을 가리키는 쿼리 트리가 생깁니다. 이것을 사용할 수 없으므로, 재작성은 그러한 것이 생성된 것을 알면 에러를 발생합니다.

이것을 바꾸기 위해서, 이러한 종류의 명령의 동작을 바꾸는 룰을 정의할 수가 있습니다. 그것이 다음 섹션의 논제가 됩니다.

Prev Home Next
쿼리 트리 Up INSERT, UPDATE, DELETE에 대한 룰