Организация Web-доступа к базам данных с использованием SQL-запросов
Информация - Компьютеры, программирование
Другие материалы по предмету Компьютеры, программирование
?мер продукта ПР = 13 на ПР = 20.
UPDATEПродуктыUPDATEСостав
SETПР = 20SETПР = 20
WHEREПР = 13;WHEREПР = 13;
UPDATEПоставкиUPDATEНаличие
SETПР = 20SETПР = 20
WHEREПР = 13;WHEREПР = 13;
К сожалению в единственным запросе невозможно обновить более одной таблицы, а так как код продукта входит в четыре таблицы, то пришлось выдать четыре сходных запроса. Это может привести к противоречию базы данных (нарушению целостности по ссылкам), поскольку после выполнения первого предложения таблицы Состав, Поставки и Наличие ссылаются на уже несуществующий продукт. База становится непротиворечивой только после выполнения четвертого запроса.
О конструировании предложений модификации
Для тех, кто достаточно хорошо понял предложение SELECT, несложно овладеть конструированием предложений DELETE, INSERT и UPDATE. Но в процессе такого конструирования следует учитывать, что:
- Если в WHERE фразе предложений DELETE и UPDATE используется вложенный подзапрос, то во фразе FROM этого подзапроса не должна упоминаться таблица, из которой удаляются (в которой обновляются) строки. Аналогично, в подзапросе предложения INSERT не должна упоминаться таблица, в которую загружаются данные.
Так, SQL отвергнет предложение
INSERT
INTOВыбрано
SELECT(33), Т, БЛ
FROMВыбрано
WHEREСМ = 17;
позволяющее ввести информацию о том, что отдыхающий, сидящий на 33-м месте, выбирает тот же набор блюд, что и отдыхающий, сидящий на 17-м месте. Ввод придется осуществить через какую-либо промежуточную таблицу, например, таблицу Выбор:
DELETE
FROMВыбор;
INSERT
INTOВыбор (СМ, Т, БЛ)
SELECT(33), Т, БЛ
FROMВыбрано
WHEREСМ = 17;
INSERT
INTOВыбрано
SELECTСМ, Т, БЛ
FROMВыбор;
- Составляя предложения модификации данных, необходимо все время помнить о сохранении непротиворечивости базы данных. Об этом упоминалось ранее и подробно говорилось в литературе.
Предложение DELETE
Удаление единственной записи
Удалить поставщика с ПС = 7.
DELETE
FROM Поставщики
WHERE ПС = 7;
Если таблица Поставки содержит в момент выполнения этого предложения какие-либо поставки для поставщика с ПС = 7, то такое удаление нарушит непротиворечивость базы данных. К сожалению нет операции удаления, одновременно воздействующей на несколько таблиц. Однако в некоторых СУБД реализованы механизмы поддержания целостности, позволяющие отменить некорректное удаление или каскадировать удаление на несколько таблиц.
Удаление множества записей
Удалить все поставки.
DELETE
FROMПоставки;
Поставки все еще известная таблица, но в ней теперь нет строк. Для уничтожения таблицы надо выполнить операцию DROP TABLE Поставки.
Удалить все мясные блюда.
DELETE FROM Блюда
WHERE Основа = Мясо;
Удаление с вложенным подзапросом
Удалить все поставки для поставщика из Паневежиса.
DELETE
FROMПоставки
WHEREПС IN
(SELECT ПС
FROM Поставщики
WHERE Город = Паневежис);
Предложение INSERT
Вставка единственной записи в таблицу
Добавить в таблицу Блюда блюдо:
Шашлык (БЛ 34, Блюдо Шашлык, В Г, Основа Мясо, Выход 150)
при неизвестной пока трудоемкости приготовления этого блюда.
INSERT
INTOБлюда (БЛ, Блюдо, В, Основа, Выход)
VALUES(34, Шашлык, Г, Мясо, 150);
Создается новая запись для блюда с номером 34, с неопределенным значением в столбце Труд.
Порядок полей в INSERT не обязательно должен совпадать с порядком полей, в котором они определялись при создании таблицы. Вполне допустима и такая версия предыдущего предложения:
INSERT
INTOБлюда (Основа, В, Блюдо, БЛ, Выход)
VALUES(Мясо, Г, Шашлык, 34, 150);
При известной трудоемкости приготовления шашлыка (например, 5 коп) сведения о нем можно ввести с помощью укороченного предложения:
INSERT
INTOБлюда
VALUES(34, Шашлык, Г, Мясо, 150, 5);
в котором должен соблюдаться строгий порядок перечисления вводимых значений, так как, не имея перечня загружаемых столб-цов, СУБД может использовать лишь перечень, который определен при создании модифицируемой таблицы.
В предыдущих примерах проводилась модификация стержневой сущности, т.е. таблицы с первичным ключом БЛ. Почти все СУБД имеют механизмы для предотвращения ввода не уникального первичного ключа, например, ввода Шашлыка под номером, меньшим 34. А как быть с ассоциациями или другими таблицами, содержащими внешние ключи?
Пусть, например, потребовалось добавить в рецепт блюда Салат летний (БЛ = 1) немного (15 г) лука (ПР = 10), и мы воспользовались предложением
INSERT
INTOСостав (БЛ, ПР, Вес)
VALUES(1, 10, 15);
Подобно операции DELETE операция INSERT может нарушить непротиворечивость базы данных. Если не принять специальных мер, то СУБД не проверяет, имеется ли в таблице Блюда блюдо с первичным ключом БЛ = 1 и в таблице Продукты продукт с первичным ключом ПР = 10. Отсутствие любого из этих значений породит противоречие: в базе появится ссылка на несуществующую запись. Проблемы, возникающие при использовании внешних ключей, подробно рассмотрены в литературе, а здесь отме-тим, что все приличные СУБД имеют механизмы для предотв-ращения ввода записей со значениями внешних ключей, отсутст-вующих среди значений соответствующих первичных ключей.
Предложение UPDATE
Обновление единствен?/p>