1.3.4.Язык запросов sql

Но обеспечение целостности данных – это далеко не все, что требуется от СУБД. Предположим, что пользователю информационной системы необходимо получить, например, общую численность отдела, в котором работает Петр Иванович Федоров. Для этого ему пришлось бы написать программу, которая работала бы в соответствии со следующим алгоритмом.

1. Установить номер отдела, в котором работает указанный служащий. С этой целью:

• в файле СЛУЖАЩИЕ необходимо отыскать запись, для которой значение поля СЛЖ_ИМЯ = 'ПЕТР ИВАНОВИЧ ФЕДОРОВ'.

• для найденной записи необходимо определить значение поля СЛЖ_ОТД_ НОМЕР. Пусть в файле СЛУЖАЩИЕ это будет запись, для которой значение поля СЛЖ_ОТД_НОМЕР = n.

2. Выбрать из файла ОТДЕЛЫ запись, для которой значение ОТД_НОМЕР = n.

3. Определить значение поля ОТД_ЧИСЛ в таблице ОТДЕЛЫ для записи, у которой значение поля ОТД_НОМЕР = n.

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

Но было бы гораздо проще, если бы в распоряжение пользователей был предоставлен язык, который позволял сформулировать незапланированный запрос, в ответ на который СУБД выдавала требуемый результат. В составе современных реляционных СУБД такие средства имеются и называются языками запросов к базам данных.

Например, при наличии языка запросов SQL наш запрос можно было бы выразить в следующей форме (запрос1):

SELECT ОТД_ЧИСЛ

FROM СЛУЖАЩИЕ, ОТДЕЛЫ

WHERE СЛЖ_ИМЯ = 'ПЕТР ИВАНОВИЧ ФЕДОРОВ' AND

СЛЖ_ОТД_НОМЕР = ОТД_НОМЕР;

Это пример запроса с «полусоединением», который характеризуется тем, что:

• запрос адресуется к двум файлам – СЛУЖАЩИЕ и ОТДЕЛЫ,

• но данные выбираются только из файла ОТДЕЛЫ.

Условие СЛЖ_ОТД_НОМЕР = ОТД_НОМЕР всего лишь «ограничивает» интересующий нас набор записей об отделах до одной записи, если Петр Иванович Федоров действительно работает на данном предприятии.

Если же Петр Иванович Федоров не работает на предприятии, то условие СЛЖ_ИМЯ = 'ПЕТР ИВАНОВИЧ ФЕДОРОВ' не будет удовлетворяться ни для одной записи файла СЛУЖАЩИЕ, и поэтому запрос выдаст пустой результат.

Приведенный пример показывает, что при формулировке запроса с использованием SQL можно не задумываться о том, как будет выполняться этот запрос. Среди метаданных базы данных будет содержаться информация о том, что поле СЛЖ_ИМЯ является ключевым для файла СЛУЖАЩИЕ (т. е. по заданному значению имени служащего можно быстро найти соответствующую запись или убедиться в том, что запись с таким значением поля СЛЖ_ИМЯ в файле отсутствует), а поле ОТД_НОМЕР – ключевое для файла ОТДЕЛЫ (и более того, оба ключа в соответствующих файлах являются уникальными), и система сама воспользуется этим.

Если же, например, возникнет потребность в получении списка служащих, должность которых еще не определена, то достаточно обратиться к системе с запросом (запрос2):

SELECT СЛЖ_ИМЯ, СЛЖ_НОМЕР

FROM СЛУЖАЩИЕ

WHERE СЛЖ_СТАТ = "НЕТ";

и система сама выполнит необходимый полный просмотр файла СЛУЖАЩИЕ, поскольку поле СЛЖ_СТАТ не является ключевым, и другого способа выполнения не существует.

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