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

Вставка единственной записи

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

INSERT

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

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

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

Вставка единственной записи с опущенными именами полей

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

INSERT

INTO Р

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

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

Вставка единственной записи

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

INSERT

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

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

Подобно операциям UPDATE и DELETE операция INSERT при отсутствии соответствующего управления также может порож­дать проблему целостности по ссылкам (см. часть 2).

Вставка множества записей

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

CREATE TABLE ВРЕМЕННАЯ

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

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

INSERT

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

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

FROM SP

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

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

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

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

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

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

Использование insert ... select для построения внешнего соединения

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

CREATE TABLE ВНЕШ_СОЕДИНЕНИЕ

(НОМЕР_ПОСТАВЩИКА CHAR (5),

ФАМИЛИЯ CHAR (20),

СОСТОЯНИЕ SMALLINT,

ГОРОД CHAR (15),

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

INSERT

INTO ВНЕШ_СОЕДИНЕНИЕ

SELECT S.*, SP.НОМЕР_ДЕТАЛИ

FROM S, SP

WHERE S.НОМЕР_ПОСТАВЩИКА = SP.НОМЕР_ПОСТАВЩИКА;

INSERT

INTO ВНЕШ_СОЕДИНЕНИЕ

SELECT S.*, ’bb’

FROM S

WHERE NOT EXISTS

(SELECT *

FROM SP

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

S. НОМЕР_ПОСТАВЩИКА);

Пояснение. Первые двенадцать строк приведенного результата соответствуют первому из двух INSERT … SE­LECT и представляют собой обычное естественное соединение таблиц S и SP по номерам поставщиков, за исключением того, что не включен столбец КОЛИЧЕСТВО. Последняя строка результата соответствует второму INSERT … SELECT и сохраняет информа­цию для поставщика S5, который не поставляет никаких деталей. Полный результат представляет собой внешнее соединение таблиц S и SP по номерам поставщиков, в котором опущен столбец КОЛИЧЕСТВО. В противоположность этому обычное соединение называется иногда внутренним соединением.

Заметим, что нужны два отдельных INSERT … SELECT, по­скольку подзапрос не может содержать UNION.

Упражнения

Как обычно, все следующие упражнения основаны на базе данных поставщиков-деталей-изделий:

S (НОМЕР_ПОСТАВЩИКА, ФАМИЛИЯ, СОСТОЯНИЕ, ГОРОД)

Р (НОМЕР_ДЕТАЛИ, НАЗВАНИЕ, ЦВЕТ, ВЕС, ГОРОД)

J (НОМЕР_ИЗДЕЛИЯ, НАЗВАНИЕ, ГОРОД)

SPJ (НОМЕР_ПОСТАВЩИКА, НОМЕР_ДЕТАЛИ, НОМЕР_ИЗДЕЛИЯ,

КОЛИЧЕСТВО)

Запишите подходящее предложение INSERT, DELETE или UPDATE для каждой из следующих задач.

1. Измените цвет всех красных деталей на оранжевый.

2. Удалите все изделия, для которых нет поставок деталей.

3. Увеличьте размер поставки на 10 процентов для всех поставок тех поставщи­ков, которые поставляют какую-либо красную деталь.

4. Удалите все изделия из Рима и все соответствующие поставки.

5. Вставьте в таблицу S нового поставщика S10. Его фамилия и город — ’Уайт’ и ’Нью-Йорк’ соответственно, а состояние еще неизвестно.

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

7. Постройте таблицу, содержащую список номеров изделий, которые либо на­ходятся в Лондоне, либо для них поставляются детали каким-нибудь постав­щиком из Лондона.

8. Добавьте 10 к состоянию всех поставщиков, состояние которых в настоящее время меньше, чем состояние поставщика S4.

9. Постройте внешнее естественное соединение изделий и поставок по номерам изделий.

10. Постройте внешнее естественное соединение деталей и изделий по городам.

11. Постройте таблицу, содержащую полную информацию о поставщиках, деталях и изделиях, с указанием объема поставок для каждой поставки вместе с «сохранен­ной» информацией для каждого поставщика, детали и изделия, которые не вхо­дят в таблицу поставок.

ЗАКЛЮЧЕНИЕ

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

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

Вторая глава касается вопросов первого этапа моделирования при разработке баз данных – методам описания предметной области. Также рассмотрены различные модели представления данных.

В третьей главе пособия подробно рассматриваются вопросы, касающиеся реляционной алгебры данной модели хранения данных.

Четвертая глава содержит обзор этапов проектирования баз данных, а также отдельно освещен один из важнейших моментов при проектировании реляционных баз данных – нормализация отношений.

Пятая и шестые главы посвящены механизмам поддержания защищенности и целостности информационных массивов.

Седьмая глава рассмотривает различные аспекты эксплуатации баз данных.

Восьмая глава является подробным пособием по языку SQL – языку манипулирования данными в реляционных системах.

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

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1. Глушаков С., Ломотько Д. Базы данных. Харьков: Фолио, М.: АСТ, 2000. 504 с.

2. Гофман В, Хомоненко А. Работа с базами данных в Delphi. СПб: БХВ-Петербург, 2003. 656 с.

3. Коннолли Т, Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. СПб: Питер, 2000. 1120 с.

4. Шкарина Л. Язык SQL: учебный курс. СПб: Питер, 2001, 592 с.

5. Бобровски С. Oracle 7 и вычисления клиент/сервер: Пер. с англ. - М.: Изд-во «Лори», 1995. – 652 с.

6. Oracle 7.3. Энциклопедия пользователя / Ригардс Майкл и др.: Пер. с англ. – Киев: Изд-во «Диа Софт», 1997. – 832 с.

7. Дейт К. Руководство по реляционной СУБД DB2: Пер. с англ. – М.: «Финансы и статистика», 1988. – 320 с.

8. Хансен Г., Хансен Д. БД: разработка и управление: Пер с англ. – М.: ЗАО «Издательство БИНОМ», 1999, 704 с.

Учебное издание

Батищев Роман Вячеславович

Рыбалкина Юлия Николаевна

Асеев Вячеслав Николаевич

СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ

В авторской редакции

Компьютерный набор: Р.В. Батищева

Ю.Н. Рыбалкиной

В.Н. Асеева

Подписано к изданию 01.06.2005.

Уч. – изд. л. 16,0. «С»

Воронежский государственный технический университет

394026 Воронеж, Московский просп., 14

1 Кроме того, в качестве имен не могут использоваться зарезервированные и ключевые слова языка SQL. Первая литера любого имени должна быть буквой, а остальные ли­теры—буквами, цифрами или знаком подчеркивания. Использование # и $ специально оговаривается.

54