21. Предложение delete. Удаление единственной записи. Удаление множества записей.

ПРЕДЛОЖЕНИЕ DELETE

Предложение DELETE имеет следующий общий формат:

DELETE

FROM таблица

[WHERE предикат];

Удаляются все записи в «таблице», которые удовлетворяют «предикату».

^ 6.3.1. УДАЛЕНИЕ ЕДИНСТВЕННОЙ ЗАПИСИ

Удалить поставщика S1.

DELETE

FROM S

WHERE НОМЕР_ПОСТАВЩИКА = 'S1’.

И снова, если таблица SP в настоящее время содержит какие-либо поставки для поставщика S1, это удаление нарушит непротиворечивость базы данных (сравните с примером 6.2.4; как и в случае предложения UPDATE, нет операций DELETE, воздействующих на несколько таблиц). См. главу 11, а также Приложения А и В.

^ 6.3.2. УДАЛЕНИЕ МНОЖЕСТВА ЗАПИСЕЙ

Удалить всех поставщиков из Лондона.

DELETE

FROM S ,

WHERE ГОРОД = 'Лондон';

6.3.3. УДАЛЕНИЕ МНОЖЕСТВА ЗАПИСЕЙ

Удалить все поставки.

DELETE

FROM SP;

SP — все еще известная таблица, но она теперь пуста. Удалить все записи—это не уничтожить таблицу (операция DROP).

4.2. Предложение DELETE

4.2.1. Удаление единственной записи

Удалить поставщика с ПС = 7.

DELETE

FROM Поставщики

WHERE ПС = 7;

Если таблица Поставки содержит в момент выполнения этого предложения какие-либо поставки для поставщика с ПС = 7, то такое удаление нарушит непротиворечивость базы данных. К сожалению нет операции удаления, одновременно воздействующей на несколько таблиц. Однако в некоторых СУБД реализованы механизмы поддержания целостности (см.п.2.5 в литературе [2]), позволяющие отменить некорректное удаление или каскадировать удаление на несколько таблиц.

4.2.2. Удаление множества записей

Удалить все поставки.

DELETE

FROM Поставки;

Поставки - все еще известная таблица, но в ней теперь нет строк. Для уничтожения таблицы надо выполнить операцию DROP TABLE Поставки (см.п.5.2).

Удалить все мясные блюда.

DELETE FROM Блюда

WHERE Основа = 'Мясо';

23. Предложение insert. Вставка единственной записи. Вставка множества записей.

ПРЕДЛОЖЕНИЕ INSERT

Предложение INSERT имеет следующий общий формат:

INSERT

INTO таблица [(поле [,поле] . . .)]

VALUES (константа [,константа] . . .);

ИЛИ:

INSERT

INTO таблица [(поле [,поле] . . .)]

подзапрос;

В первом формате в «таблицу» вставляется строка, имеющая заданные значения для указанных полей, причем 1-я константа в списке констант соответствует i-му полю в списке полей. Во втором формате вычисляется «подзапрос»; копия результата, представляющего собой, вообще говоря, множество строк, вставляется в «таблицу». При этом 1-й столбец этого результата соответствует f-му полю в списке полей. В обоих случаях отсутствие списка полей эквивалентно спецификации списка всех полей в таблице (см. ниже пример 6.4.2).

^ 6.4.1. ВСТАВКА ЕДИНСТВЕННОЙ ЗАПИСИ

Добавить в таблицу Р деталь Р7 (город 'Атенс', вес — 2, название и цвет в настоящее время неизвестны).

Insert

INTO Р (НОМЕР_ДЕТАЛИ, ГОРОД, BEC)

VALUES ('Р7', 'Атенс', 2);

Создается новая запись для детали с заданным номером, городом и весом, с неопределенными значениями для названия и цвета. Эти два последних поля не должны быть, конечно, определены как NOT NULL в предложении CREATE TABLE для таблицы Р. Порядок слева — направо, в котором поля указаны в предложении INSERT, не обязательно должен совпадать с порядком слева — направо, в котором поля были специфицированы в предложении CREATE (или ALTER).

^ 6.4.2. ВСТАВКА ЕДИНСТВЕННОЙ ЗАПИСИ С ОПУЩЕННЫМИ ИМЕНАМИ ПОЛЕЙ

Добавить деталь Р8 в таблицу Р, при этом: название—'Звездочка', цвет — 'Розовый', вес— 14, город — 'Ницца'.

INSERT

INTO P

VALUES ('Р8', 'Звездочка', 'Розовый', 14, 'Ницца');

Отсутствие списка полей эквивалентно спецификации списка всех полей в таблице в порядке слева — направо, как они были определены в предложении CREATE (или ALTER). Как и «SELECT * », такая краткая нотация может быть удобной для интерактивного SQL. Она потенциально опасна, однако, во встроенном SQL, т. е. в предложениях SQL, используемых в прикладной программе, в связи с тем, что предполагаемый список полей может изменяться, если для программы заново осуществляется связывание, а определение таблицы было в этом промежутке времени изменено.

^ 6.4.3. ВСТАВКА ЕДИНСТВЕННОЙ ЗАПИСИ

Вставить новую поставку с номером поставщика S20, номером детали Р20 и количеством 1000.

INSERT

INTO SP (НОМЕР—ПОСТАВЩИКА, НОМЕР—ДЕТАЛИ, КОЛИЧЕСТВО)

VALUES ('S20', 'Р20', 1000);

Подобно операциям UPDATE и DELETE операция INSERT при отсутствии соответствующего управления также может порождать проблему целостности по ссылкам (см. главу 11, а также Приложения А и В). В рассматриваемом случае система DB2 не проверяет, имеется ли поставщик S20 в таблице S и деталь Р20 в таблице Р.

^ 6.4.4. ВСТАВКА МНОЖЕСТВА ЗАПИСЕЙ

Для каждой поставляемой детали получить ее номер и общий объем поставок, сохранить результат в базе данных (см. пример 5.4.7).

CREATE TABLE ВРЕМЕННАЯ

(НОМЕР_ДЕТАЛИ CHAR (6),

ОБЪЕМ_ПОСТАВКИ INTEGER);

INSERT

INTO ВРЕМЕННАЯ (НОМЕР_ДЕТАЛИ, ОБЪЕМ_ПОСТАВКИ)

SELECT НОМЕР_ДЕТАЛИ, SUM (КОЛИЧЕСТВО)

FROM SP

GROUP BY НОМЕР_ДЕТАЛИ;

Здесь предложение SELECT выполняется точно так же, как обычно, но результат не возвращается пользователю, а копируется в таблицу ВРЕМЕННАЯ. Теперь с этой копией пользователь может делать все, что он пожелает — делать дальнейшие запросы, печатать и даже обновлять ее. Никакая из этих операций не будет оказывать какого-либо влияния на первоначальные данные. В конечном счете таблицу ВРЕМЕННАЯ можно будет уничтожить, когда она больше не будет нужна:

DROP TABLE ВРЕМЕННАЯ;

Предыдущий пример очень хорошо показывает, почему свойство замкнутости реляционных систем, обсуждаемое во введении к разделу 4.2, является таким важным. Приведенная полная процедура работает именно в связи с тем, что результатом предложения SELECT является другая таблица. Она не работала бы, если бы результат был чем-либо иным, кроме таблицы.

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

Одно из важных применений INSERT.. .SELECT — построение так называемого внешнего соединения. Как указывалось в главе 4, обычное (естественное) соединение двух таблиц не включает в результате строк какой-либо из двух таблиц, для которых нет соответствующих строк в другой таблице. Например, обычное соединение таблиц S и Р по городам не включает какой-либо строки для поставщика S5 или для детали РЗ, поскольку в Атенсе не хранится никакая деталь и нет поставщиков, находящихся в Риме (см. пример 4.3.1). Следовательно, в некотором смысле можно считать, что при обычном соединении теряется информация для таких несоответствующих строк. Однако иногда может потребоваться способность сохранять эту информацию. Рассмотрим следующий пример.