Коллектив Авторов - Базы данных: конспект лекций

Поставщики ( Код поставщика , Имя поставщика, Город поставщика);

Инструменты ( Код инструмента , Имя инструмента, …);

Поставки ( Код поставщика , Код детали );

Подчеркнутые имена атрибутов [1]являются ключевыми (т. е. идентификационными) атрибутами, причем каждый в своем отношении.

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

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

1. образуем естественное соединение отношений «Поставщики» и «Поставки» для того, чтобы сопоставить с каждым поставщиком коды поставляемых им деталей. Новое отношение – результат применения операции естественного соединения – для удобства дальнейшего применения обозначим через r 1.

Поставщики × Поставки ≔ r 1(Код поставщика, Имя поставщика, Город поставщика, Код поставщика, Код инструмента);

В скобках мы перечислили все атрибуты отношений, участвующих в этой операции естественного соединения. Мы видим, что атрибут «Код поставщика» дублируется, но в итоговой записи операции каждое имя атрибута должно присутствовать только один раз, т. е.:

Поставщики × Поставки ≔ r 1(Код поставщика, Имя поставщика, Город поставщика, Код инструмента);

2. снова образуем естественное соединение, только на этот раз отношения, получившегося в пункте один и отношения Инструменты. Делаем это для того, чтобы с каждым кодом инструмента, получившемуся в предыдущем пункте, – сопоставить имя этого инструмента.

r 1× Инструменты [Код инструмента, Имя инструмента] ≔ r 2(Код поставщика, Имя поставщика, Город поставщика, Код инструмента, Код инструмента, Имя инструмента);

Получившийся результат обозначим r 2, дублирующиеся атрибуты исключаем:

r 1× Инструменты [Код инструмента, Имя инструмента] ≔ r 2(Код поставщика, Имя поставщика, Город поставщика, Код инструмента, Имя инструмента);

Заметим, что из отношения Инструменты мы берем только два атрибута: «Код инструмента» и «Имя инструмента». Чтобы это осуществить мы, как можно заметить из записи отношения r 2, применили унарную операцию проекции: Инструменты [Код инструмента, Имя инструмента], т. е., если бы отношение Инструменты было представлено в виде таблицы, результатом этой операции проекции стали бы два первых столбца с заголовками соответственно «Код инструмента» и «Имя инструмента».

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

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

3. Напишем унарную операцию выборки по условию <���«Имя инструмента» = «Плоскогубцы»> применительно к отношению r 2, полученному в предыдущем пункте. А к результату этой операции применим, в свою очередь, унарную операцию проекции [Код поставщика, Имя поставщика, Город поставщика], для того чтобы получить все значения этих атрибутов, потому что именно эту информацию нам и требуется получить исходя из заказа.

Итак:

( σ <���Имя инструмента = «Плоскогубцы»> r 2) [Код поставщика, Имя поставщика, Город поставщика] ≔ r 3(Код поставщика, Имя поставщика, Город поставщика, Код инструмента, Имя инструмента).

В результирующем отношении, обозначенном через r 3, оказались только те поставщики (со всеми своими опознавательными данными), которые поставляют инструменты с родовым именем «Плоскогубцы». Но нам в силу заказа необходимо выделить тех поставщиков, которые, наоборот, не поставляют таких инструментов. Поэтому перейдем к следующему действию нашего алгоритма и запишем последнее выражение реляционной алгебры, которое и даст нам искомую информацию.

4. Сначала составим разность отношения «Поставщики» и отношения r 3, а после применения этой бинарной операции применим унарную операцию проекции на атрибуты «Имя поставщика» и «Город поставщика».

(Поставщики \ r 3) [Имя поставщика, Город поставщика] ≔ r 4(Код поставщика, Имя поставщика, Город поставщика);

Результат обозначили r 4, в это отношение и вошли как раз только те кортежи исходного отношения «Поставщики», которые соответствуют условию нашего заказа.

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

Дадим сначала небольшую историческую справку.

Язык SQL, предназначенный для взаимодействия с базами данных, появился в середине 1970-х гг. (первые публикации датируются 1974 г.) и был разработан в компании IBM в рамках проекта экспериментальной реляционной системы управления базами данных. Исходное название языка – SEQUEL (Structured English Query Language) – только частично отражало суть этого языка. Первоначально, сразу после его изобретения и в первичный период эксплуатации языка SQL, его название являлось аббревиатурой от словосочетания Structured Query Language, что переводится как «Язык структурированных запросов». Конечно, язык был ориентирован главным образом на удобную и понятную пользователям формулировку запросов к реляционным базам данных. Но, в действительности, он почти с самого начала являлся полным языком баз данных, обеспечивающим, помимо средств формулирования запросов и манипулирования базами данных, следующие возможности:

1) средства определения и манипулирования схемой базы данных;

2) средства определения ограничений целостности и триггеров (о которых будет упомянуто позднее);

3) средства определения представлений баз данных;

4) средства определения структур физического уровня, поддерживающих эффективное выполнение запросов;

5) средства авторизации доступа к отношениям и их полям.

В языке отсутствовали средства явной синхронизации доступа к объектам баз данных со стороны параллельно выполняемых транзакций: с самого начала предполагалось, что необходимую синхронизацию неявно выполняет система управления базами данных.