Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Базы данных.doc
Скачиваний:
114
Добавлен:
16.03.2016
Размер:
5.67 Mб
Скачать

21.2.3. Оператор delete для удаления строк в существующих таблицах

Общий синтаксис оператора DELETEвыглядит следующим образом:

DELETE FROM table_name

WHERE conditional_expression

В некотором смысле оператор DELETEявляется частным случаем оператораUPDATE(или, наоборот, действие оператораUPDATEпредставляет собой комбинацию действий операторовDELETEиINSERT).

Семантика оператора модификации существующих строк определяется следующим образом:

  1. для всех строк таблицы с именем table_nameвычисляется булевское выражениеconditional_expression. Строки, для которых значением этого булевского выражения являетсяtrue, считаются подлежащими удалению (обозначим множество таких строк черезTd);

  2. каждая строка s(s Td) удаляется из указанной таблицы.

С целью иллюстрации приведем два примера операции удаления строк.

Пример 21.7. Удалить из таблицы EMP все строки, относящиеся к служащим, которые участвуют в проекте с номером 772.

DELETE FROM EMP WHERE PRO_NO = 772;

Пример 21.8. Удалить из таблицы EMP все строки, относящиеся к служащим, размер заработной платы которых превышает размер заработной платы менеджеров их отделов.

DELETE FROM EMP WHERE EMP_SAL >

(SELECT EMP1.EMP_SAL

FROM EMP EMP1, DEPT

WHERE EMP.DEPT_NO = DEPT.DEPT_NO

AND DEPT.DEPT.MNG = EMP1.EMP_NO);

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

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 это всегда разрешалось), то в этом случае семантика материализации явно не подходит. На первое место выходит требование, чтобы операция обновления над представлением однозначно отображалась в одну или несколько операций обновления над теми постоянно хранимыми базовыми таблицами, над которыми прямо или косвенно определено данное представление.