- •Часть 5
- •Глава 17 Представления
- •17.1. Введение
- •17.2. Для чего нужны представления
- •17.3. Определение данных
- •17.4. Манипуляции с данными: операции выборки
- •17.5. Манипуляции с данными: операции обновления
- •17.6. Обновление операций объединения, пересечения и вычитания
- •Объединение
- •Пересечение
- •17.7. Обновление представлений других видов
- •17.8. Снимки
- •17.9. Поддержка sql
- •17.10. Резюме
17.8. Снимки
Здесь будет уместно, несколько отклонившись от основной темы, обсудить понятие снимков (snapshots) [17.1]. Снимки, также называемые снимками данных, имеют много общего с представлениями (но не следует путать эти понятия). Как описано в главе 4, снимок данных — это именованное производное отношение (т.е. реляционная переменная), как и представление. Тем не менее, в отличие от представления, снимок реален, а не виртуален: он представлен в базе данных не только своим определением в терминах других именованных отношений, но и (по крайней мере концептуально) своими собственными данными. Ниже приведен пример, заимствованный из главы 4.
CREATE SNAPSHOT SC AS
( (S JOIN SP ) WHERE P# = 'P2' ) [ S#, CITY ]
REFRESH EVERY DAY;
Создание снимка во многом походит на выполнение запроса, за исключением того, что, во-первых, результат запроса хранится в базе данных под указанным именем (в примере это SC) как отношение, которое допускает только чтение; во-вторых, периодически (в примере — каждый день (every day)) снимок данных обновляется, т.е. текущие данные аннулируются и запрос выполняется повторно, после чего результат запроса принимается в качестве нового значения снимка. Таким образом, снимок в примере представляет состояние данных, в котором они находились не более 24 часов назад.
Тонкость идеи снимков состоит в том, что многие приложения, возможно даже большинство приложений, могут использовать или даже запрашивать данные по состоянию на конкретный момент времени. Например, в эту категорию приложений попадают приложения для отчетности и бухгалтерского учета. Подобные приложения обычно требуют фиксирования состояния данных в нужный момент (например, в конце периода отчетности), и снимки позволяют выполнять такую фиксацию, не влияя на другие транзакции, обновляющие данные. Кроме того, как показано в главе 1, может понадобиться зафиксировать состояние данных большого объема для сложного запроса или приложения поддержки принятия решений без запрещения обновляющих транзакций.
Замечание. Эта идея становится еще привлекательнее в контексте распределенных баз данных (см. главу 21).
Приведем синтаксис инструкции create snapshot:
CREATE SNAPSHOT снимок AS выражение REFRESH EVERY время_обновления ;
В этом выражении в качестве еремя_обновления можно использовать, например, month (месяц), week (неделя), hour (час), n minutes (минуты), msnday (понедельник), weekday (день недели) и т.п. Ниже показан синтаксис соответствующего выражения
DESTROY:
DESTROY SNAPSHOT СНИМОК ;
В результате этой операции снимок данных будет уничтожен (т.е. из каталога базы данных будет удалено определение снимка данных).
Замечание. Операция destroy snapshot завершится неудачей, если какой-либо снимок данных или представление ссылаются в этот момент на удаляемый снимок данных. Дополнительно в определении снимка данных можно использовать операторы restricted или cascades. Детально такая возможность не будет обсуждаться в этой главе.