Название: Базы данных. Концепция баз данных, реляционная модель данных, языки SQL и XML (Токмаков Г. П.)

Жанр: Информационные системы и технологии

Просмотров: 1420


1.2.3.  язык  за просо в  sql

 

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

В нашем примере информационная система должна отдельно сохранять метаданные о структуре файлов СЛУЖАЩИЕ и ОТДЕЛЫ, а также правила, опреде- ляющие условия целостности данных в этих файлах (принято считать, что пра- вила также составляют часть метаданных).

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

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

ницами данных. Например, число может появиться и в файле, и в базе данных,

но в файле это просто обезличенное число, а в базе данных число имеет смысл,

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

номер заказа, индекс продукта и т. д.

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

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

С этой целью:

– в файле СЛУЖАЩИЕ необходимо отыскать запись, для которой значение поля

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

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

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

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

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

рой значение поля ОТД_НОМЕР = n.

И так пришлось бы поступать всякий раз, как только возникала необходи-

мость в извлечении тех или иных данных. Было бы гораздо проще, если бы

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

Самое примечательное то, что эти языки разрабатываются в соответствии со стандартным интерфейсом SQL, который, в настоящее время, де факто явля-

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

сывать код всякий раз, когда в информационной системе меняется СУБД.

Например, при наличии языка запросов SQL наш запрос можно было бы вы-

разить в следующей форме (запрос1):

 

SELECT ОТД_ЧИСЛ

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

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

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

 

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

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

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

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

Возможна и другая формулировка того же запроса (запрос2):

 

SELECT ОТД_РАЗМЕР

FROM ОТДЕЛЫ

WHERE ОТД_НОМЕР =

(SELECT СЛЖ_ОТД_НОМЕР

FROM СЛУЖАЩИЕ

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

 

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

Приведенные примеры показывают, что при формулировке запроса с ис-

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

Наиболее вероятным способом выполнения запроса в обеих формулиров-

ках будет выборка записи из файла СЛУЖАЩИЕ со значением поля СЛЖ_ИМЯ, рав-

ным строке 'ПЕТР ИВАНОВИЧ ФЕДОРОВ', взятие из этой записи значения поля СЛЖ_ ОТД_НОМЕР и выборка из таблицы ОТДЕЛЫ записи с таким же значением поля ОТД_НОМ.

Если же, например, возникнет потребность в получении списка служащих,

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

 

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

FROM СЛУЖАЩИЕ

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

 

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

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