Материализованные представления 1105

Столбец DEPTNO - первичный ключ таблицы DEPT. Это означает, что каждая строка в таблице ЕМР соответствует не более чем одной строке в таблице DEPT.

Столбец DEPTNO в таблице ЕМР - внешний ключ по столбцу DEPTNO таблицы DEPT. Если значение столбца DEPTNO в строке таблицы ЕМР непустое, она будет соединена со строкой в таблице DEPT (ни одна строка таблицы ЕМР с непустым значением при соединении потеряна не будет).

Для столбца DEPTNO в таблице ЕМР задано требование NOT NULL. В сочетании с требованием внешнего ключа это означает, что ни одна строка таблицы ЕМР не будет потеряна.

Эти три факта в совокупности означают, что при соединении таблиц ЕМР и DEPT каждая строка таблицы ЕМР будет входить в результирующее множество только один раз. Поскольку серверу Oracle об этом не сообщалось, он не смог использовать материализованное представление. Давайте же сообщим серверу все это:

tkyte@TKYTE816> alter table dept

2 add constraint dept pk primary key(deptno) ;

Table altered.

tkyte@TKYTE816> alter table emp

2 add constraint emp fk dept

3 foreign key(deptno) references dept(deptno); Table altered.

tkyte@TKYTE816> alter table emp modify deptno not null;

Table altered.

tkyte@TKYTE816> set autotrace on tkyte@TKYTE816> select count(*) from emp; COUNT(*)

Execution Plan

0 SELECT STATEMENT Optimizer=ALL ROWS (Cost=l Card=l Bytes=13)

1 0 SORT (AGGREGATE)

2 1 TABLE ACCESS (FULL) OF EMP DEPT (Cost=l Card=82 Bytes=1066)

Теперь сервер Oracle может переписать запрос с использованием материализованного представления EMP DEPT. Каждый раз, когда известно, что сервер мог бы использовать материализованное представление, но не использует (и проверено, что вообще использование материализованных представлений в сеансе возможно), более детально изучите данные и спросите себя: Какую информацию я не предоставил серверу Oracle? . В девяти случаях из десяти обнаружится фрагмент метаданных, при добавлении которого сервер Oracle будет переписывать запрос.

Итак, что же произойдет в реальном хранилище данных, где в представленных таблицах будут десятки миллионов записей? Дополнительные затраты ресурсов на проверку выполнения требования целостности нежелательны - в программе первичной обра-

1106

Глава 13

ботки данных это уже сделано, не так ли? В данном случае можно создать непроверяемое требование, которое используется для информирования сервера о взаимосвязи, но сервером не проверяется. Давайте рассмотрим предыдущий пример еще раз, но теперь сымитируем загрузку данных в существующее хранилище (хранилище представлено предыдущим примером). Удалим требования, загрузим данные, обновим материализованные представления и снова добавим требования. Начнем с удаления требований:

tkyte@TKYTE816> alter table emp drop constraint emp fk dept;

Table altered.

tkyte@TKYTE816> alter table dept drop constraint dept pk; Table altered.

tkyte@TKYTE816> alter table emp modify deptno null; Table altered.

Теперь, чтобы сымитировать загрузку, я вставлю новую строку (для демонстрационных целей этого вполне достаточно) в таблицу ЕМР. Затем мы обновим материализованное представление и сообщим серверу Oracle, что его можно считать актуальным (FRESH):

tkyte@TKYTE816> insert into emp (empno,deptno) values (1, 1) ; 1 row created.

tkyte@TKYTE816> exec dbms mview.refresh (EMP DEPT);

PL/SQL procedure successfully completed.

tkyte@TKYTE816> alter materialized view emp dept consider fresh; Materialized view altered.

Теперь сообщаем серверу о взаимосвязи таблиц ЕМР и DEPT:

tkyte@TKYTE816> alter table dept

2 add constraint dept pk primary key(deptno)

3 rely enable NOVALIDATE

Table altered.

tkyte@TKYTE816> alter table emp

2 add constraint emp fk dept

3 foreign key(deptno) references dept(deptno)

4 rely enable NOVALIDATE

Table altered.

tkyte@TKYTE816> alter table emp modify deptno not null NOVALIDATE;

Table altered.

Итак, мы сообщили серверу Oracle, что имеется, как и прежде, внешний ключ в таблице ЕМР, сс1лающийся на таблицу DEPT. Однако, поскольку перед загрузкой в хранилище данные уже обрабатывались, мы сообщаем серверу, что проверять выполнение требований не надо. Опция NOVALIDATE позволяет избежать проверки загруженных

Материализованные представления 1107

данн1х, а опция RELY требует, чтобы сервер рассматривал данные как целостные. По сути, мы сообщили серверу о необходимости считать, что при соединении таблиц ЕМР и DEPT по столбцу DEPTNO каждая строка в таблице ЕМР обязательно попадет в результат, причем не более одного раза.

Фактически мы обманули сервер, вставив в таблицу ЕМР строку, для которой нет соответствующей строки в таблице DEPT. Теперь все готово для выполнения запроса:

tkyte@TKYTE816> alter session set query rewrite integrity=enforced;

Session altered.

tkyte@TKYTE816> select count(*) from emp;

COUNT(*)

Execution Plan

0 SELECT STATEMENT Optimizer=ALL ROWS (Cost=l Card=l)

1 0 SORT (AGGREGATE)

2 1 TABLE ACCESS (FULL) OF EMP (Cost=l Card=164)

Поскольку установлено значение параметра QUERY REWRITE INTEGRITY=ENFORCED,

сервер Oracle не переписал запрос с использованием материализованного представления. Необходимо понизить уровень целостности запроса. Надо, чтобы сервер Oracle нам поверил :

tkyte@TKE816> alter session set query rewrite integrity=trusted; Session altered.

tkyte@TKYTE816> select count(*) from emp; COUNT(*)

Execution Plan

0 SELE ATEME Optimizer=ALL ROWS (Cost=1 Card=l Bytes=13)

1 0 SORT (AGGREGATE)

2 1 TABLE ACCESS (FULL) OF EMP DEPT (Cost=l Card=82 Bytes=1066)

В этом случае сервер Oracle переписал запрос, но побочным эффектом оказалось то, что вновь вставленные строки не учтены. Возвращается ошибочный ответ, поскольку факт сохранения каждой строки таблицы ЕМР в результатах соединения с таблицей DEPT при загруженных в таблицу данных - уже не факт. При обновлении материализованного представления вновь добавленная строка ЕМР в него не попала. Данные, которым сервер Oracle по нашему требованию доверял, оказались ненадежными. В результате мы приходим к двум важным умозаключениям:

можно очень эффективно использовать материализованные представления в больших хранилищах данных, без необходимости выполнять множество дополнительных и зачастую избыточных проверок данных;