Базы данных. Вводный курс

Назад Содержание Вперёд

21.3. Представления, над которыми возможны операции обновления

В подразделе 17.2.1. Общие синтаксические правила построения скалярных выражений лекции 17 было введено понятие представления (VIEW). Кратко повторим, что представление – это сохраняемое в каталоге базы данных выражение запросов, обладающее собственным именем и, возможно, собственными именами столбцов. Для удобства повторим синтаксические правила определения представления:

create_view ::= CREATE [ RECURSIVE ] VIEW table_name
      [ column_name_comma_list ]
   AS query_expression
   [ WITH [ CASCADED | LOCAL ] CHECK OPTION ]

В операциях выборки к любому представлению можно адресоваться таким же образом, как и к любой базовой таблице. Естественно, возникает вопрос: а можно ли использовать имена представлений и в операциях обновления базы данных и если такая возможность допускается, то как это следует понимать?

Напомним, что в соответствии с семантикой языка SQL при выполнении запроса, в разделе FROM которого прямо или косвенно присутствует имя представления, прежде всего, производится материализация представления, т.е. вычисляется результат соответствующего выражения запросов, сохраняется во временной базовой таблице, и далее запрос выполняется по отношению к этой базовой таблице. Хотя в реализациях SQL обычно стремятся избегать материализации представлений, любая реализация обязана обеспечить такое выполнение запроса над представлением, которое было бы эквивалентно выполнению запроса с явной материализацией представления.

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

21.3.1. Представления, допускающие применение операций обновления, в стандарте SQL/92

Поскольку базовым элементом выражения запросов является спецификация запроса, прежде всего нужно понять, какой класс спецификаций запросов является допускающим операции обновления (термин updatable – обновляемый, используемый в стандарте SQL, кажется не слишком удачным в русском варианте). В стандарте SQL/92 спецификация запроса считалась допускающей операции обновления в том и только в том случае, когда выполнялись следующие условия:

• в разделе SELECT спецификации запроса отсутствует ключевое слово DISTINCT (т.е. не требуется удаление строк-дубликатов из результата запроса);
• все элементы списка выборки раздела SELECT являются именами столбцов, и ни одно имя столбца не встречается в этом списке более одного раза;
• в разделе FROM присутствует только одна ссылка на таблицу, и она указывает либо на базовую таблицу, либо на порождаемую таблицу, допускающую операции обновления;
• прямые или косвенные ссылки на базовую таблицу, прямо или косвенно идентифицируемую ссылкой на таблицу в разделе FROM, не встречаются в разделе FROM ни одного подзапроса, участвующего в разделе WHERE спецификации запроса;
• в спецификации запроса отсутствуют разделы GROUP BY и HAVING.

Нетрудно убедиться в том, что эти требования являются достаточными для однозначной интерпретации операций обновления над представлениями. Например, пусть имеется следующая спецификация запроса (пример 21.9):

SELECT EMP_SAL
   FROM (SELECT EMP_SAL, DEPT_NO
         FROM EMP
         WHERE EMP_NAME = (SELECT EMP_NAME
                           FROM EMP
                           WHERE EMP_NO = 4425))
   WHERE DEPT_NO <> 630;

Эту спецификацию можно упростить до эквивалентной формулировки¹⁵⁴⁾:

SELECT EMP_SAL
   FROM EMP
   WHERE EMP_NAME = (SELECT EMP_NAME
                     FROM EMP
                     WHERE EMP_NO = 4425 )
                        AND DEPT_NO <> 630;

Предположим, что с данной спецификацией запроса связано представление с именем EMPSAL. Тогда операция

UPDATE EMPSAL SET EMP_SAL = EMP_SAL – 1000.00;

эквивалентна операции

UPDATE EMP SET EMP_SAL = EMP_SAL – 1000.00
   WHERE EMP_NAME = (SELECT EMP_NAME
                     FROM EMP
                     WHERE EMP_NO = 4425 )
                        AND DEPT_NO <> 630;

Операция

DELETE FROM EMPSAL WHERE EMP_SAL > 20000.00;

эквивалентна операции

DELETE EMPSAL
   WHERE EMP_SAL > 20000.00 AND
         EMP_NAME = (SELECT EMP_NAME
                     FROM EMP
                     WHERE EMP_NO = 4425 )
                        AND DEPT_NO <> 630;

Операция вставки над представлением EMPSAL

INSERT INTO EMPSAL 25000.00;

трактуется как

INSERT INTO EMP
   ROW (DEFAULT, DEFAULT, DEFAULT, 25000.00, DEFAULT, DEFAULT);

Понятно, что такая операция будет отвергнута системой, потому что для столбца EMP_NO таблицы EMP значения по умолчанию не определены (это первичный ключ таблицы, значения которого должны явно задаваться в любой операции вставки).

С другой стороны, условия допустимости операций обновления, специфицированные в SQL/92, не являются необходимыми. Например, над представлением EMPMNG, определенным над спецификацией запроса («выбрать данные о служащих, являющихся руководителями отделов»)

SELECT *
   FROM EMP
   WHERE EXISTS (SELECT *
                 FROM DEPT
                 WHERE DEPT_MNG = EMP_NO);

можно было бы совершенно корректно выполнять операции обновления (с некоторыми оговорками насчет операции вставки; см. ниже в этом разделе).

21.3.2. Представления, допускающие применение операций обновления, в стандарте SQL:1999

В стандарте SQL:1999 правила применимости операций обновления к спецификации запроса существенно уточнены.

Критерии применимости операций обновления

Введены понятия потенциальной применимости операций обновления, применимости операций обновления, простой применимости операций обновления и применимости операции вставки. К спецификации запроса потенциально применимы операции обновления в том и только в том случае, когда выполняются следующие условия:

• в разделе SELECT спецификации запроса отсутствует ключевое слово DISTINCT;
• элемент списка выборки раздела SELECT, состоящий из ссылки на некоторый столбец, не может присутствовать в этом списке более одного раза;
• в спецификации запроса отсутствуют разделы GROUP BY и HAVING.

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

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

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

Выражение запросов удовлетворяет условию применимости операций обновления, если по крайней мере к одному столбцу выражения запросов применимы операции обновления. Выражение запросов удовлетворяет условию простой применимости операций обновления, если в разделе FROM выражения запросов содержится ссылка только на одну таблицу, и все столбцы выражения запросов удовлетворяют условию применимости операций обновления.

Выражение запросов удовлетворит условию применимости операций вставки, если оно удовлетворяет условию применимости операций обновления; каждая из таблиц, от которых зависит это выражение (т.е. таблиц, на которые имеются ссылки в разделе FROM), удовлетворяет условию применимости операций вставки и выражение запросов не содержит операций UNION, INTERSECT и EXCEPT.Конечно, это определение базируется на том факте, что для любой базовой таблицы условие применимости операции вставки удовлетворяется (при наличии привилегии INSERT, см. следующую лекцию).

Правила функциональных зависимостей

Приведенный набор правил является достаточно грубым. В стандарте SQL:1999 он уточняется набором дополнительных правил, устанавливающих восприимчивость различных языковых конструкций к операциям обновления и вставки. В основе этих правил лежит понятие функциональной зависимости (Functional Dependency – FD, см. раздел 7.2. Функциональные зависимости). Полагая, что в целом понятие функциональной зависимости уже не должно вызывать у читателей каких-либо затруднений, приведем несколько дополнительных определений, требуемых для понимания подхода, используемого в SQL:1999.

• Пусть S обозначает некоторое множество столбцов таблицы T, а SS обозначает некоторое подмножество S (SS S). Тогда по первой аксиоме Армстронга (см. подраздел 7.2.2. Замыкание множества функциональных зависимостей. Аксиомы Армстронга. Замыкание множества атрибутов лекции 7) SSS. В терминологии SQL:1999 эта FD называется аксиоматической.Все ФЗ, не являющиеся аксиоматическими, называются неаксиоматическими.
• Все аксиоматические FD являются известными FD. В стандарте определяются правила определения других известных FD. Кроме того, стандарт оставляет свободу для реализаций SQL в пополнении этой системы правил с целью нахождения известных FD, не специфицированных в стандарте.
• Если некоторый столбец C1 виртуальной таблицы T1 (порождаемой таблицы или представления) определяется путем ссылки на столбец C2 некой другой (базовой или виртуальной) таблицы T2, на основе которой порождается T1, то C1 является двойником C2. Более точно, C1 является двойником C2 в соответствии с таблицей T2.
• Понятие двойников расширяется на множества столбцов. Если некоторое множество столбцов S1 виртуальной таблицы T1 определяется (путем отображения «один-в-один») множеством столбцов S2 определяющей таблицы T2, и каждый столбец из множества S1 является двойником соответствующего столбца из множества S2, то S1 называется двойником S2 в соответствии с таблицей T2.
• Если ни в одном из столбцов возможного ключа (набора столбцов, специфицированного в неоткладываемом ограничении уникальности) не допускается наличие неопределенных значений, то это множество столбцов называется BUC-множеством (акроним BUC происходит от Base table Unique Constraint). Любое множество столбцов, являющееся двойником BUC-множества, также есть BUC-множество, так что это свойство распространяется через различные выражения, производящие виртуальные таблицы. Если имеются два множества столбцов S1 и S2, такие, что S1S2, S1S2, и S2 является BUC-множеством, то и S1 является BUC-множеством. Могут существовать таблицы, у которых BUC-множество является пустым. Такая таблица может содержать не более одной строки¹⁵⁵⁾. С другой стороны, могут существовать таблицы, у которых вообще отсутствуют BUC-множества¹⁵⁶⁾.
• Множество столбцов, составляющих первичный ключ таблицы, называется ее BPK-множеством (акроним BPK происходит от Base table Primary Key). Понятно, что каждое BPK-множество является BUC-множеством. Если имеются два множества столбцов S1 и S2, такие, что S1S2, S1S2, и S2 является BPK-множеством, то и S1 является BPK-множеством. Подобно BUC-множествам, BPK-множества могут быть пустыми.

На основе этих определений в стандарте SQL:1999 устанавливаются правила функциональных зависимостей для 11 компонентов языка.

• Базовые таблицы. Если у таблицы имеется первичный ключ, то соответствующее множество столбцов образует BPK-множество этой таблицы. Если у таблицы имеется не откладываемое ограничение уникальности и ни у одного столбца, указанного в этом ограничении, не допускается наличие неопределенных значений, то соответствующее множество столбцов является BUC-множеством. Если множество столбцов UCL базовой таблицы – BUC-множество, а CT обозначает все множество столбцов этой таблицы, то FD UCLCT представляет собой известную функциональную зависимость базовой таблицы.
• Конструкторы табличных значений. Поскольку для конструкторов табличных значений невозможно определять ограничения, в стандарте SQL:1999 для них не специфицированы BUC- и BPK-множества. В стандарте не определяются известные функциональные зависимости для такого рода конструкций, отличные от аксиоматических. Однако стандарт допускает, чтобы реализации SQL включали дополнительные механизмы определения известных функциональных зависимостей.
• Соединенные таблицы. Если говорить о соединенных таблицах, получаемых в результате применения операций естественного соединения (NATUARAL JOIN) или соединения c заданием списка имен столбцов, значения которых должны совпадать (USING), то понятно, что соединенная таблица будет содержать двойников из одной или двух исходных таблиц. Если обозначить через S некоторое множество столбцов результирующей таблицы, а через CT – все множество столбцов этой таблицы, то S является BPK-множеством в том и только в том случае, когда имеет двойника в одной или обеих исходных таблицах. В таком случае во всех столбцах S не допускаются неопределенные значения, и FD SCT является известной функциональной зависимостью.

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

COALESCE (t1.colname, t2.colname) AS colname ¹⁵⁷⁾

Пусть JT обозначает ключевые слова, определяющие тип соединения (INNER, LEFT, RIGHT, FULL и т.д.), и пусть TN1 и TN2 обозначают имена таблиц или (если они заданы) имена псевдонимов двух таблиц-источников соответственно. Обозначим через IR результат вычисления следующего выражения запросов:

SELECT SLCC, T1*, T2* FROM T1 JT JOIN T2;

Тогда, в соответствии с правилами SQL, дополнительными известными функциональными зависимостями являются следующие:

• если JT задает INNER или LEFT, то действует FD COALESCE (T1.Ci, T2.Ci)T1.Ci для всех i от единицы до числа столбцов в IR;
• если JT задает INNER или RIGHT, то действует FD COALESCE (T1.Ci, T2.Ci)T2.Ci для всех i от единицы до числа столбцов в IR.

Обозначим через SL некоторый список выборки. Пусть:

• если все столбцы первой и второй таблиц-источников являются общими, то SL совпадает с SLCC;
• если среди столбцов таблиц-источников нет общих столбцов, то SL состоит из списка столбцов первой таблицы-источника, за которым следует список столбцов второй таблицы-источника;
• если все столбцы первой таблицы-источника являются общими, но у второй таблицы-источника имеются необщие столбцы, то SL состоит из SLCC, за которым следует список необщих столбцов второй таблицы-источника;
• аналогично, если все столбцы второй таблицы-источника являются общими, но у первой таблицы-источника имеются не общие столбцы, то SL состоит из SLCC, за которым следует список не общих столбцов первой таблицы-источника;
• наконец, если среди столбцов первой таблицы-источника и среди столбцов второй таблицы-источника имеются необщие столбцы, то SL состоит из SLCC, за которым следует список необщих столбцов первой таблицы-источника, а далее располагается список не общих столбцов второй таблицы-источника.

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

SELECT SL FROM IR;

• Ссылки на таблицы. Столбцы виртуальной таблицы, производимой по ссылке на таблицу, являются естественными двойниками столбцов таблицы, которая идентифицируется ссылкой. Поэтому BUC- и BPK-множества результирующей таблицы являются двойниками BUC- и BPK-множеств исходной таблицы, и известные функциональные зависимости результирующей таблицы получаются путем замены имен столбцов исходной таблицы на имена столбцов результирующей таблицы в известных функциональных зависимостях исходной таблицы.
• Раздел FROM. Описывая в лекции 17 общую семантику оператора выборки, мы отмечали, что на первом шаге выполнения этого оператора производится (виртуальная) таблица, являющаяся расширенным декартовым произведением всех таблиц, специфицированных в разделе FROM. Поэтому в стандарте SQL естественным образом формулируются следующие правила. Если в списке ссылок на таблицы раздела FROM содержится всего одна ссылка, то BUC- и BPK-множества результирующей таблицы являются двойниками BUC- и BPK-множеств исходной таблицы. Если в списке раздела FROM содержатся две или более ссылки на таблицы, то, в соответствии со стандартом, BUC- и BPK-множества результирующей таблицы не определены. Известные функциональные зависимости результирующей таблицы состоят из известных функциональных зависимостей каждой таблицы, специфицированной в разделе FROM.
• Раздел WHERE. В стандарте содержится набор правил, позволяющих определить BUC- и BPK-множества результирующей таблицы этогораздела¹⁵⁸⁾, а также известные функциональные зависимости результирующей таблицы. Правила основываются на особенностях поведения предиката сравнения по равенству и логической операции AND.
• Раздел GROUP BY. Для определения BUC- и BPK-множеств и известных функциональных зависимостей результирующей таблицы раздела GROUP BY требуется фактическое образование в результирующей таблице нового столбца, значения которого могли бы каким-то образом идентифицировать строки исходной таблицы, образующие группы сгруппированной таблицы.
• Раздел HAVING. BUC- и BPK-множества и известные функциональные зависимости результирующей таблицы раздела HAVING получаются из соответствующих множеств и FD таблицы, к которой применяется этотраздел¹⁵⁹⁾, на основе правил, связанных с условным выражением раздела HAVING (как и в случае условия раздела WHERE, в данных правилах учитываются операции сравнения по равенству и логические операции AND).
• Раздел SELECT. На определение BUC- и BPK-множеств и известных функциональных зависимостей результата спецификации запроса влияет наличие в списке выборки выражений (value_expression), отличных от ссылок на столбцы.
• Выражение запроса. На определение BUC- и BPK-множеств и известных функциональных зависимостей результата выражения запроса влияет наличие в этом выражении операций UNION, INTERSECT и EXCEPT. В стандарте отсутствуют какие-либо правила для определения функциональных зависимостей в результатах рекурсивных запросов. Отмечается лишь возможность введения таких правил в реализациях.

154   Обратите внимание, что формально эта формулировка не отвечает требованиям SQL/92 для спецификаций запросов, допускающих применение операций обновления. Но в действительности здесь вложенный подзапрос вычисляется в единственное значение при отсутствии какой-либо корреляции с внешним вхождением таблицы EMP.

155   Множество, элементы которого невозможно различить, может быть либо пустым, либо содержать только один элемент.

156   В этом случае таблица соответствует понятию мультимножества.

157   Определение выражения COALESCE (V1, V2) см. в разделе 16.2. Средства определения, изменения и ликвидации базовых таблиц лекции 16.

158   Напомним из лекции 17, что в соответствии с семантикой оператора выборки в результат раздела WHERE входят все строки результата раздела FROM, для которых результатом вычисления логического условия раздела WHERE является true.

159   Напомним из лекции 17, что на вход раздела HAVING подается результат раздела GROUP BY, если этот раздел присутствует в спецификации запроса, иначе – результат раздела WHERE, если этот раздел присутствует в спецификации запроса, иначе – результат раздела FROM.

Назад Содержание Вперёд