соединенной таблицы. Однако при попытке
зависимости stor_id -> stor_name и stor_id -> stor_address,
потому что stor_id - первичный ключ таблицы stores). Эти
зависимости сохраняются и в соединенной таблице (stores INNER
JOIN sales ON (stores.store_id = sales.stor_id)). Тем самым,
значения полей stor_name и stor_address являются общими
характеристиками группы c одинаковыми значениями stor_id
соединенной таблицы. Однако при попытке выполнить запрос мы
получим диагностику о недопустимости включения в список выборки
имен столбцов, не входящих в список группирования. И формально
это совершенно правильно, поскольку язык SQL не обязывает
реализацию выводить зависимости для порождаемых таблиц, и система
не имеет информации о существующих функциональных зависимостях.
Более того, язык SQL не предоставляет средств для выражения таких
функциональных зависимостей.
Мне казалось, что ситуация изменится, если мы огрубим ситуацию и
объявим столбцы stor_name и stor_address возможными ключами. Для
этого в языке SQL используется раздел UNIQUE определения таблицы.
В частности, в определении таблицы stores добавились бы строчки
UNIQUE (stor_name),
UNIQUE (stor_address)
Теперь уже система имеет полную информацию об однозначном
соответствии значений столбцов stor_id, stor_name и stor_address.
Однако запрос по-прежнему не выполняется, и диагностика
сохраняется той же самой. И опять-таки это формально правильно,
поскольку в спецификациях языка четко сказано, что если в запросе
используется раздел GROUP BY, то в списке выборки могут
участвовать только имена столбцов, входящих в список
группирования, и агрегатные функции, применяемые к другим
столбцам таблиц, которые перечислены в разделе FROM. Но
пользователям от этого не легче. Похожие таблицы очень вероятно
используются в практических базах данных, и запросы, подобные
приведенному выше, вполне естественны. Для того, чтобы получить
запрос, правильно воспринимаемый системой, его придется
переформулировать следующим образом:
SELECT stor_name, stor_address, sum(qty)
Содержание Назад Вперед