Глава J

Введение в реляционные базы данных

3.1. Введение

Как отмечалось в главе 1, в этой книге основное внимание сконцентрировано на реляционных системах. В части II подробно описаны теоретические основы таких систем, а точнее - реляционная модель данных. Эта глава является лишь предварительным и весьма неформальным введением в материал, подробно изложенный в части II (и в некоторой степени в материал последующих глав), которое послужит основой для лучшего понимания последующих частей книги. Большинство затронутых здесь тем рассматривается в дальнейшем более формально и значительно детальнее.

3.2. Реляционная модель

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

Структурный аспект. Данные в базе воспринимаются пользователем, как таблицы (и никак иначе).

Аспект целостности. Эти таблицы удовлетворяют определенным условиям целостности (что мы еще обсудим в конце раздела).

Аспект обработки. В распоряжении пользователя имеются операторы манипулирования данными (например, выборки информации), которые генерируют новые таблицы на основании уже имеющихся и среди которых есть по крайней мере операторы выборки (restrict), проекции (project) и объединения Qoin).

На рис. 3.1 показан простой пример реляционной базы данных отделов (таблица DEPT) и служащих (таблица ЕМР). Как видите, эта база данных действительно воспринимается, как набор таблиц (мы полагаем, что смысл этих таблиц не требует пояснений).

На рис. 3.2 показаны некоторые примеры операций SELECT, PROJECT и JOIN для этой базы данных. Ниже приведены (очень нестрогие!) определения этих операций.

Операция выборки SELECT (или RESTRICT) предназначена для извлечения определенных строк из таблицы.

Операция проекции PROJECT предназначена для извлечения определенных столбцов из таблицы.

Операция объединения JOIN предназначена для соединения двух таблиц на основе общих значений в общих столбцах.

DEPT

Рис. 3.1. База данных отделов и служащих (значения взяты для примера)

SELECT (RESTRICT): Выборка строк из DEPT, где BUDGET > 8М

Результат:

JOIN:

Соединение DEPT и EMP на основе столбца DEPT# Результат:

Рис. 3.2. Примеры выполнения операций SELECT, PROJECT и JOIN

Из трех приведенных здесь примеров в комментариях, по-видимому, нуждается только операция JOIN. Прежде всего, обратите внимание на то, что в таблицах DEPT и ЕМР есть общий столбец DEPTt, а следовательно, для этих таблиц можно выполнить операцию соединения на основе общих значений в этом столбце.

При выполнении данной операции строка таблицы DEPT соединяется со строкой таблицы ЕМР и образуется более длинная строка, но подобное происходит тогда и только тогда, когда у этих двух строк одинаковое значение поля DEPTt. Например, можно соединить в результирующую строку следующие строки таблиц DEPT и ЕМР (названия столбцов приведены для наглядности).

Это возможно, так как в общем столбце у данных строк одно и то же значение Dl. Вот эта результирующая строка.

Общий результат состоит из множества всех таких соединенных строк. Обратите внимание, что столбец DEPTt в каждой результирующей строке встречается один раз, а не два. Обратите также внимание на то, что, поскольку в поле DEPTt таблицы ЕМР нет значения D3 (т.е. нет служащих, работающих в отделе D3), нет и результирующих строк со значением D3 в этом поле, хотя строка со значением D3 в таблице DEPT присутствует.

Необходимо отметить один важный момент, очевидный из рис. 3.2: результат выполнения каждой из трех представленных операций - это еще одна таблица (другими словами, эти операторы - фактически такие операторы, которые порождают таблицы из таблиц , что мы подчеркивали ранее). Это реляционное свойство замкнутости. Оно имеет очень большое значение и, главным образом, потому, что результатом выполнения операции является объект того же рода, что и объект, над которым производилась операция, а именно - таблица. Но это значит, что над результатом операции можно вновь проделать какую-либо операцию. Например, можно выбрать столбцы (операция PROJECT) из результата соединения таблиц (операция JOIN) или соединить два результата выполнения операции SELECT и т.д. Другими словами, можно использовать вложенные выражения, т.е. выражения, в которых операнды представлены выражениями, а не простыми именами таблиц. В данной и последующих главах вы увидите, что этот факт имеет, в свою очередь, множество важных следствий.

Кстати, когда мы говорим, что результатом выполнения каждой операции является таблица, мы имеем в виду, что это таблица с концептуальной точки зрения. Мы не хотим сказать, что система обязательно должна полностью овеществлять результат каждой отдельной операции. Предположим, например, что понадобилось выбрать строки (операция SELECT) из соединения таблиц. В этом случае как только строка требуемого соединения будет сформирована, система может немедленно применить к ней заданное ограничение и проверить, будет ли она принадлежать конечному результату. Если это не так, система может немедленно отбросить данную строку. Иначе говоря, промежуточный результат, который создается операцией соединения, возможно, никогда и не будет существовать в виде полной овеществленной таблицы как таковой. На практике, как правило, каждая система настойчиво стремится избежать полного овеществления промежуточных результатов по вполне понятной причине - с целью повышения производительности.

Замечание. Если промежуточные результаты полностью овеществлены, стратегия вычисления выражения в целом называется (что неудивительно) овеществленными вычислениями; если промежуточные результаты передаются последующей операции по частям, то этот подход называется конвейерными вычислениями.