3.1. Введение

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

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

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

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

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

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

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

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

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

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

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

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

EMP

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

SELECT (RESTRICT): Результат:

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

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

DEPT#	DNAME	BUDGET
Dl D2	Marketing Development	10M 12M

PROJECT:	Результат:	DEPT#	BUDGET
Извлечение столбцов DEPT#, BUDGET		Dl	10M
		D2	12M
		D3	5M

JOIN:

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

DEPT#	DNAME	BUDGET	EMP#	ENAME	SALARY
Dl	Marketing	10M	El	Lopez	40K
Dl	Marketing	10M	E2	Cheng	42K
D2	Development	12M	E3	Finzi	30K
D2	Development	12M	E4	Saito	35K

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

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

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

DEPT#	DNAME	BUDGET
Dl	Marketing	10M

EMP#	ENAME	DEPT#	SALARY
El	Lopez	Dl	40K

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

DEPT#	DNAME	BUDGET	EMP#	ENAME	SALARY
Dl	Marketing	10M	El	Lopez	40K

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

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

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

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

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

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

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

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

■ Во-вторых, у реляционных баз данных есть одно замечательное свойство, назы- ваемое информационным принципом: все информационное содержимое базы данных представлено одним и только одним способом, а именно — явным зада-

' К сожалению, приходится констатировать, что большинство современных SQL-продуктов не обеспечивает должной поддержки этого аспекта теории. А точнее, они обычно в определен- ной степени поддерживают только отображения "концептуальный-внутренний " для операций выборки (как правило, отображают одну логическую таблицу непосредственно в один хранимый файл). И вследствие этого они не обеспечивают независимость от физических данных в той ме- ре, в какой это теоретически предусмотрено в реляционной технологии.

ниш значений, помещенных в позиции столбцов в строках таблицы. Этот метод представления единственно возможный для реляционных баз данных (естествен- но, на логическом уровне). В частности, нет никаких указателей, связывающих одну таблицу с другой. Например, на рис. 3.1 существует определенная связь ме- жду строкой 'Dl' в таблице DEPT и строкой 'Е1' в таблице ЕМР, указывающая, что служащий с номером 'Е1' работает в отделе с номером 'Dl'; но эта информация представлена не указателем, а наличием значения 'D1' в столбце DEPTt строки 'El' в таблице ЕМР. В нереляционных системах (например, в IMS и IDMS), напро- тив, такая информация обычно представляется (о чем шла речь в главе 1) неким указателем, который пользователь видит явно.

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

На этом закончим с вопросами, связанными со структурой и обработкой данных в ре- ляционной модели, и перейдем к рассмотрению аспекта целостности. Еще раз восполь- зуемся базой данных отделов и сотрудников, приведенной на рис. 3.1. На практике для такой базы данных потребовалось бы определить несколько ограничений поддержки це- лостности базы. Например, зарплата служащих не должна выходить за пределы диапазо- на, скажем, от 25 до 95 тыс. долларов в год, а бюджет отдела должен быть, например, в пределах от 1 до 15 млн долларов и т.д. Некоторые из таких правил имеют настолько важное практическое значение, что получили специальные названия. Рассмотрим их.

1. Каждая строка в таблице DEPT должна включать уникальное значение столбца DEPTf; аналогично каждая строка в таблице ЕМР должна включать уникальное значение столбца EMPi. Говорят, что столбцы DEPTt в таблице DEPT и EMPt в таб- лице ЕМР являются первичными ключами для своих таблиц. (Вспомните, что в главе 1 мы условились отмечать на рисунках столбцы первичных ключей двой- ным подчеркиванием.)

2. Каждое значение столбца DEPTt в таблице ЕМР должно существовать как значе- ние столбца DEPTt в таблице DEPT для отражения того факта, что каждый слу- жащий должен быть приписан к существующему отделу. Говорят, что столбец DEPTt в таблице ЕМР является внешним ключом, ссылающимся на первичный ключ таблицы DEPT.

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

1. Неограниченный набор скалярных типов (включая, в частности, логический тип или значение истины).

2. Генератор типов отношений и соответствующая интерпретация для таких сгене- рированных типов отношений.

1. Возможность определения переменных отношений для таких сгенерированных типов отношений.

2. Операция реляционного присвоения для присвоения реляционных значений та- ким переменным отношений.

3. Неограниченный набор общих реляционных операторов для получения значений отношений из других значений отношений.

Как видите, реляционная модель— это нечто большее, чем просто "таблицы плюс выборка, проекция и соединение", хотя ее неформально довольно часто характеризуют именно таким образом.

Замечание. Вас, возможно, удивило то, что в предыдущем определении отсутствует явное упоминание о правилах целостности. Однако на самом деле такие правила пред- ставляют собой просто приложения (хотя и очень важные), использующие реляционные операторы. Иначе говоря, такие правила формулируются (во всяком случае, концепту- ально) в терминах реляционных операторов, как мы сможем убедиться в главе 8.