Глава 3.

Введение

в реляционные

базы данных

3.1. Введение

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

3.2. Реляционные системы

Реляционная система управления базами данных (или просто реляционная систе­ма) — это такая система, в которой, выполняются как минимум два условия.

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

2. В распоряжении пользователя имеются операторы (например, для выборки данных), которые генерируют новые таблицы из старых и среди которых, по крайней мере, есть операторы SELECT (также известный как RESTRICT), PROJECT и JOIN.

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

DEPT

DEPT#	DNAME	BUDGET
D1 D2 D3	Marketing Development Research	10M 12M 5M

EMP

EMP#	ENAME	DEPT#	SALARY
E1 E2 E3 E4	Lopez Cheng Finzi Saito	D1 D1 D2 D2	40K 42K 30K 35K

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

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

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

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

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

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

DEPT#

DNAME

BUDGET

Dl D2

Marketing Development

10M 12M

PROJECT: Pезультат Извлечение столбцов DEPT#, BUDGET

DEPT#

BUDGET

Dl D2 D3

10M 12M 5M

JOIN: Результат:

Соединение DEPT и EMP на основе столбца DEPT#

DEPT#

DNAME

BUDGET

EMP#

ENAME

SALARY

Dl Dl D2 D2

Marketing Marketing Development Development

10M 10M 12M 12M

El E2 E3 E4

Lopez Cheng Finzi Saito

4OK 42K 30K 35K

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

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

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

DEPT#	DNAME	BUDGET
D1	Marketing	10M

EMP#	ENAME	DEPT#	SALARY
El	Lopez	Dl	40K

(названия столбцов приведены для наглядности) можно соединить в результирующую строку

DEPT#	DNAME	BUDGET	ЕМР#	ENAME	SALARY
Dl	Marketing	10M	El	Lopez	40K

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

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

Замечание. Отмечая, что результатом каждой операции является таблица, мы име­ем в виду, что это таблица с концептуальной точки зрения. Мы не хотим сказать, что система обязательно должна полностью материализовать результат каждой отдельной операции. Предположим, например, что нам понадобилось выбрать строки (операция SELECT) из соединения таблиц. Тогда, как только данная строка соединения будет сформирована, система может немедленно применять ограничение к такой строке, чтобы проверить, будет ли она принадлежать конечному результату, и немедленно отбросить ее, если нет. Иначе говоря, промежуточный результат, который выводится операцией соединения, может никогда и не будет существовать в виде полной мате­риализованной таблицы как таковой. На практике, как правило, система весьма упор­но пытается не материализовать полностью промежуточные результаты по вполне понятной причине — чтобы не терять производительность.

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

Давайте вновь вернемся к рис. 3.1. Есть несколько замечаний, которые можно сделать, используя пример базы данных на этом рисунке.

• Во-первых, обратите внимание, что определение "реляционной системы" требует, чтобы база данных воспринималась пользователем только как таблицы. Таблицы в реляционной системе являются логическими, а не физическими структурами. На самом деле, на физическом уровне система может использовать любую или все применяемые структуры памяти — последовательные файлы, индексирование, хэширование, цепочки указателей, сжатие и т.п. — лишь бы обеспечивалась воз­можность отображать эти структуры в таблицы на логическом уровне. Это можно сказать и по-другому: таблицы представляют абстракцию способа физического хранения данных, в которой множество деталей на уровне памяти — размещение хранимой записи, последовательность хранимых записей, кодировка хранимых данных, префиксы хранимых записей, хранимые структуры доступа, такие как ин­дексы, и т.д. — скрыто от пользователя.

В данном случае термин "логическая структура" в терминологии ANSI/SPARC от­носится как к концептуальному, так и к внешнему уровню. Дело в том, что, как объ­яснялось в главе 2, концептуальный и внешний уровни в реляционной системе яв­ляются реляционными, а внутренний, или физический уровень — нет. На самом де­ле реляционная теория ничего не может сказать о внутреннем уровне вообще; она, как уже отмечалось, "заботится" о том, как база данных представлена пользователю.

• Во-вторых, у реляционных баз данных, подобных изображенной на рис. З.1, есть одно замечательное свойство: все информационное содержимое базы данных представлено одним и только одним способом, а именно: явным заданием значе­ний данных. Этот метод представления (задание явным образом значений позиций столбцов в строках таблицы) единственно возможный для реляционных баз дан­ных. В частности, нет никаких указателей, связывающих одну таблицу с другой. Например, существует связь между строкой D1 в таблице DEPT и строкой Е1 в таблице ЕМР, так как служащий Е1 работает в отделе D1; но эта информация представлена не указателем, а появлением значения D1 в столбце DEPT# строки Е1 в таблице ЕМР. А в нереляционных системах, напротив, такая информация представлена неким указателем, который пользователь видит явно.

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

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

DEPT#	EМР#
D1	Е1
D1	Е2

вместо

DEPT#	EMP#
D1 ……….	Е1,Е2 ………

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

В заключение отметим, что данное в начале раздела определение "реляционной системы" представляет собой лишь минимальное определение (оно взято из [3.1] и в основном использовалось в начале 1980-х). Конечно, в этом разделе можно и нужно было бы рассказать о реляционных системах значительно больше. В частности, за­метьте, что реляционная модель— это нечто большее, чем просто "таблицы плюс операции SELECT, PROJECT и JOIN".