Введение

В этой главе мы завершаем обсуждение предложения SELECT языка SQL. План этой главы следующий:

— В разделе 5.2 вводится понятие подзапроса (Subquery) или вложенного предложения SELECT. Представляет исторический интерес тот факт, что именно возможность вкладывать одно предложение SELECT внутрь другого первоначально послужила мотивировкой использования прилагательного «структуризованный» в названии языка «структуризованный язык запросов» (Structured Query Language—SQL). Однако более поздние дополнения к языку привели к тому, что сами по себе вложенные предложения SELECT стали значительно менее важными.

— В разделе 5.3 рассматривается квантор существования EXISTS (существует), который вместе с соединением расценивается, по мнению автора, как одна из наиболее важных и фундаментальных, хотя, может быть, и не самых легких для использования, возможностей полного языка SQL.

— В разделе 5.4 обсуждаются стандартные функции COUNT (число значений), SUM (сумма), AVG (среднее) и т. п. В нем описывается, в частности, использование в связи с этими функциями фраз GROUP BY (группировать по) и HAVING (имея).

— В разделе 5.5 обсуждается оператор UNION (объединение).

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

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

Необходимо сделать еще одно заключительное вводное замечание, которое может быть не совсем понятным пока не будет прочитана вся глава. Несмотря на то, что наша задача состоит в исчерпывающем обсуждении языка, в данную главу намеренно не включено какое-либо детальное описание вариантов ANY(любой) и ALL(все) операторов сравнения (>ANY,=ALL и т. д.), Читателя, которому необходимо такое детальное описание, отсылаем к фирменному руководству по системе. Причина исключения указанных операторов из этой книги состоит в том, что они совершенно излишни. Нет такого запроса, сформулированного с их использованием, который нельзя было бы в равной степени хорошо, а на самом деле лучше, сформулировать, используя конструкцию EXISTS (существует). Более того, они запутывают и, по мнению автора, порождают потенциальную опасность ошибок. Например, корректное предложение:

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

FROM S

WHERE S. ГОРОД Ø = ANY(SELECT P. ГОРОД FROM P);

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

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

FROM S

WHERE EXISTS (SELECT P. ГОРОД

FROM P

WHERE P. ГОРОД Ø= S. ГОРОД);

(«выдать номера поставщиков таких, что существует некоторый город хранения деталей, который отличается от города, где находится данный поставщик»). Естественная интуитивная интерпретация Ø=ANY как «не совпадает с любыми» и некорректна и весьма обманчива. Подобная критика относится ко всем операторам, использующим ANY и ALL.