Использование вложенных запросов
Зачем использовать подзапрос
Во многих случаях с помощью подзапроса можно получить тот же результат, что и с помощью объединения (JOIN). Как правило, сложность синтаксиса подзапроса сопоставима со сложностью синтаксиса объединения. Выбор способа построения запроса при этом часто становится делом вкуса пользователя базы данных. Одни предпочитают использовать объединения (JOIN), в то время как другие – применять вложенные запросы. Впрочем, иногда бывает так, что получить нужный результат с помощью объединений (JOIN) невозможно. Тогда приходится использовать вложенный запрос или разбивать задачу на несколько операторов SQL и выполнять их поочередно.
Что делают подзапросы
Подзапросы находятся в предложении WHERE внешнего оператора. Их роль состоит в том, чтобы задавать для этого предложения условия поиска. Разные виды подзапросов дают разные результаты. Некоторые подзапросы создают список значений, который затем передается замыкающему оператору. Другие подзапросы создают единственное значение, которое затем проверяется замыкающим оператором с помощью оператора сравнения. Существуют также и подзапросы, возвращающие логические значения.
Вложенные подзапросы, которые возвращают наборы строк
Предположим, что вы работаете на фирме по сборке компьютерных систем. В вашей компании, Zetec Corporation, из покупаемых комплектующих собирают системы, которые затем продают другим компаниям и правительственным агентствам. Информацию о своем бизнесе вы храните в реляционной базе данных. Она состоит из множества таблиц, но сейчас вас интересуют только три: PRODUCT (товар), COMP_USED (использованные компоненты) и COMPONENT (компонент). В таблице PRODUCT содержится список всех выпускаемых вашей фирмой стандартных товаров (табл. 11.1). В таблице COMPONENT перечисляются производственные компоненты товаров (табл. 11.2), а в таблице COMP_USED хранятся данные о том, из каких компонентов состоят произведенные товары (табл. 11.3).
Таблица 11.1. Таблица PRODUCT.
| Столбец | Тип | Ограничения |
|---|---|---|
| Model (модель) | Char (6) | PRIMARY KEY |
| ProdName (название товара) | Char (35) | |
| ProdDesc (описание товара) | Char (31) | |
| ListPrice (цена) | Numeric (9.2) |
Таблица 11.2. Таблица COMPONENT.
| Столбец | Тип | Ограничения |
|---|---|---|
| CompiD (идентификатор компонента) | char (6) | PRIMARY KEY |
| CompType (тип компонента) | char (10) | |
| CompDesс (описание компонента) | char (31) |
Таблица 11.3. Таблица COMPOSED.
| Столбец | Тип | Ограничения |
|---|---|---|
| Model (модель) | char (6) | FOREIGN KEY (ДЛЯ PRODUCT) |
| CompiD (идентификатор компонента) | char (б) | FOREIGN KEY (ДЛЯ COMPONENT) |
Компонент может использоваться во множестве товаров, а товар – состоять из множества компонентов (отношение "многие ко многим"). Такая ситуация может привести к нарушениям целостности данных. Чтобы этого не случилось, создайте промежуточную таблицу COMP_USED, связывающую COMPONENT с PRODUCT. Компонент может быть указан во многих строках COMEMJSED, но в каждой строке этой таблицы указывается только один компонент (отношение "один ко многим"). И, аналогично, товар может быть указан также во многих строках COMP_USED, но в каждой строке этой таблицы также указывается только один товар (еще одно отношение "один ко многим"). С помощью промежуточной таблицы сложное отношение "многие ко многим" разбивается на два относительно простых отношения "один ко многим". Этот процесс упрощения отношений – как раз один из примеров нормализации.