Под представлениями (view), упомянутыми в заголовке этой статьи, понимаются не представления, а моментальные снимки. В ней приведен алгоритм поддержки моментальных снимков. Он позволяет одновременно выполнять транзакции сопровождения моментальных снимков и запросы к их данным.

9.15. Stonebraker M.R. Implementation of Views and Integrity Constraints by Query Modification Proc. ACM SIGMOD Intern. Conf on Management of Data. - San Jose, Calif., May, 1975.

Cm. комментарии к [9.7].

9.16. Zhuge Y., Garcia-Molina H., Hammer J. and Widom J. View Maintenance in a Warehousing Environment Proc. ACM SIGMOD Int. Conf on Management of Data. - San Jose, Calif, May, 1995.

Представлениями в этой статье именуются не представления, а моментальные снимки. После обновления некоторых исходных данных со стороны хранилища данных может потребоваться выдать запрос к базе данных прежде, чем будет выполнено необходимое сохранение снимка, и время задержки между таким запросом и обновлением исходной базы данных может привести к аномалиям. В статье представлен алгоритм для обработки подобных аномалий.

Ответы к некоторьш упражнения]

9.1. Приведенные ниже ответы пронумерованы как 9.\.п, где п- номер примера в разделе 9.1. Здесь используются нащи обычные допущения относительно переменных диапазона.

9.1.1. VAR REDPART VIEW

( РХ.Р#, РХ.PNAME, РХ.WEIGHT AS WT, PX.CITY ) WHERE PX.COLOR = COLOR ( Red ) ;

9.1.2. VAR PQ VIEW

( PX.Pi,

SUM ( SPX WHERE SPX.Pi = PX.Pi, QTY ) AS TOTQTY ) ;

9.1.3. VAR CITY PAIR VIEW

( SX.CITY AS SCITY, PX.CITY AS PCITY ) WHERE EXISTS SPX ( SPX.Si = SX.Si AND SPX.Pi = PX.Pi ) ;

9.1.4. VAR HEAVY REDPART VIEW

RPX WHERE RPX.WT > WEIGHT ( 12.0 ) ;

Здесь RPX - это переменная диапазона, которая изменяется на представлении REDPART.

9.2. VAR NON COLOCATED VIEW

( S TIMES P ) { St, Pi } MINUS ( S JOIN P ) { Si, Pi } ;

9.3. VAR LONDON SUPPLIER VIEW

( S WHERE CITY = London ) { ALL BUT CITY } ;

Замечание. Из представления исключен атрибут CITY, так как известно, что он всегда будет иметь значение London. Тем не менее следует заметить, что подобный пропуск атрибута приводит к тому, что любая операция INSERT для данного представления будет завершаться неудачей (только если для атрибута CITY в исходной переменной-отношении поставшиков не установлено принимаемое по умолчанию значение, равное London). Другими словами, подобные представления, вероятно, вовсе не могут поддерживать операцию INSERT. (В качестве альтернативы сушествует идея определения значения по умолчанию для атрибута CITY, равного значению London, но только для кортежей, вставляемых через данное представление. Идея значений по умолчанию, специфических для представления, требует более глубокого изучения.)

9.4. Проблема здесь состоит в следующем: Как определить атрибут QTY в представлении SP? . Разумным решением будет такой ответ: для данной пары St-Pt атрибут SP.QTY нужно определить как сумму всех значений SPJ.QTY, вычисляемую по всем номерам Jt для выбранной пары St-Pt.

VAR SP VIEW

SUMMARIZE SPJ PER SPJ { St, Pt }

AND SUM ( QTY ) AS QTY ;

9.5. VAR JC VIEW

( SPJ WHERE St = St ( SI ) ) { Jt } JOIN ( SPJ WHERE Pt = Pt ( PI ) ) { Jt } ) JOIN

J { Jt, CITY } ;

9.6. Преобразованные формы читателю предлагается записать самостоятельно. Тем не менее заметим, что случай д приведет к ошибке, так как вставляемый кортеж не удовлетворяет предикату представления.

9.7. И снова случай д приведет к ошибке, но теперь причина несколько иная. Во-первых, СУБД будет использовать для атрибута WEIGHT значение по умолчанию (скажем, w), поскольку пользователь не передает системе конкретного значения этого атрибута (и, конечно, не может этого сделать). Во-вторых, значение атрибута WT, которое указал пользователь, необязательно будет равным w*454, даже если (что в нашем примере не наблюдается) значение атрибута WT превышает 14.0. Следовательно, вставляемый кортеж опять не удовлетворяет предикату представления.

Замечание. Можно привести доводы, что значение атрибута WEIGHT в новом кортеже должно быть установлено правильно, т.е. равняться указанному для атрибута WT значению, деленному на 454. Эта возможность также требует дальнейшего изучения.

9.8. Приведенный список причин взят из [5.7].

Если вместо базовых переменных-отношений пользователи оперируют представлениями, то очевидно, что эти представления должны выглядеть для пользователей, как базовые переменные-отношения, насколько это возможно. В идеальном случае пользователь не должен даже догадываться, что оперирует представлениями, но ему должно быть позволено обращаться с представлениями, как с базовыми переменными-отношениями, в соответствии с принципом относительности базы данных. И подобно тому, как пользователю базовых переменных-отношений необходима информация об их потенциальных ключах (в общем случае), так и пользователю представ-

лений необходимы сведения о потенциальных ключах этих представлений (опять же, в общем случае). Явное объявление потенциальных ключей представлений- это очевидный способ сделать данную информацию доступной пользователям.

СУБД может не включать средств определения потенциальных ключей для собственных нужд (это утверждение истинно для всех современных СУБД). Таким образом, явное объявление потенциальных ключей- единственно доступный (для администратора базы данных) способ информирования СУБД и пользователей о наличии таких ключей.

Даже если бы СУБД могли самостоятельно определять потенциальные ключи для собственных нужд, явное объявление по крайней мере позволило бы системе удостовериться, что определенные ею ключи не являются несовместимыми с ключами, которые объявил администратор базы данных.

Администратор базы данных может располагать дополнительной информацией, которая не заложена в СУБД, и, следовательно, оптимизировать ключи, определенные СУБД автоматически. В [5.7] приведен пример такого случая.

В [11.3] предложен другой довод, который, по существу, сводится к тому, что подобная возможность (явное объявление потенциальных ключей) обеспечивает простой и удобный способ описания некоторых важных офаничений целостности, которые в противном случае потребовали бы весьма многословного описания.

9.9. Очевидно, что на эти вопросы невозможно дать окончательных ответов. Ниже изложены некоторые соображения.

Каждому представлению и каждому моментальному снимку в базе данных в ее каталоге будет соответствовать запись в переменной-отнощении RELVAR со значением View или Snapshot в атрибуте RVKIND соответственно.

Каждому определенному в базе данных представлению в ее каталоге будет также-соответствовать запись в новой переменной-отношении, которая может так и называться- VIEW. Запись должна включать то выражение, которое использовалось при определении данного представления.

Аналогично каждому определенному в базе данных моментальному снимку в каталоге будет соответствовать запись в еще одной новой переменной-отношении (например, SNAPSHOTS). Эта запись должна включать выражение, которое использовалось при определении данного моментального снимка, а также сведения об установленном для него интервале обновления.

Еще одна переменная-отношение в каталоге должна содержать сведения о том, какие переменные-отношения использовались в определениях каждого из представлений и моментальных снимков. Обратите внимание, что структура этой переменной-отношения в определенной степени подобна структуре переменной-отношения PART STRUCTURE (см. рис. 4.6 в главе 4): как одна деталь (или узел) может включать в себя другую, так и некоторое представление (или моментальный снимок) может быть определено в терминах других представлений (или снимков). Поэтому проблемы, обсуждавшиеся в ответе к упр. 7.7 в главе 7, имеют отношение и к данному случаю.

9.10. Да! Но отметим следующее. Предположим, что переменная-отношение S с данными о поставщиках заменена выборками SA и SB, где переменная-отношение SA содержит данные о поставщиках из Лондона, а переменная-отношение SB - данные о постав-