3.10. Резюме

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

Реляционная база данных— это такая база данных, которая воспринимается ее пользователями как множество переменных, значениями которых являются отношения (т.е. переменных-отношений— relvars) или, менее формально, таблиц. Реляционная система — это система, которая поддерживает реляционные базы данных и операции над ними, включая, в частности, операцию выборки строк RESTRICT (иначе называемую SELECT), операцию выборки столбцов PROJECT (также называемую проекцией) и опера- цию соединения таблиц JOIN. Эти и подобные им операции выполняются на уровне множеств. Свойство замкнутости реляционных систем означает, что результат выпол- нения операции имеет тот же тип, что и объекты, над которыми проводилась операция (все они являются отношениями). А это, в свою очередь, позволяет использовать вло- женные реляционные выражения. Значения переменных-отношений изменяются с помощью операций реляционного присвоения, причем привычные нам операции об- новления INSERT, UPDATE и DELETE можно считать сокращенной формой записи опера- ций реляционного присвоения определенных типов.

Формальная теория, положенная в основу реляционных систем, называется реля- ционной моделью данных. Реляционная модель изучает материал только на логиче- ском уровне и не затрагивает физический уровень. В модели рассматриваются три принципиальных аспекта данных — их структура, сохранение их целостности и ма- нипулирование данными. Структурный аспект касается собственно отношений, ас- пект целостности имеет отношение (помимо всего прочего) к первичным и внеш- ним ключам, а аспект манипулирования данными связан с операторами (RESTRICT, PROJECT, JOIN и т.д.). Информационный принцип утверждает, что все информацион- ное содержимое реляционной базы данных должно быть представлено одним и только одним способом, а именно— явным заданием значений, помещенных в позиции столбцов в строках отношений.

Каждое отношение имеет заголовок и тело; заголовок— это набор пар "имя- столбца:имя-типа", а тело отношения состоит из набора строк, которые соответствуют заголовку. Заголовок любого отношения можно рассматривать как предикат, а каж- дую строку в теле отношения — как некоторое истинное высказывание, образован- ное в результате подстановки определенных значений аргументов соответствующего типа вместо местодержателей или параметров этого предиката. Другими словами, типы — это что-то (множество чего-то), что мы можем обсуждать, а отношения — это то (множество чего-то), что мы можем сказать о том, что мы можем обсуждать. И ти- пы, и отношения необходимы и достаточны для представления любых данных (на логическом уровне).

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

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

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

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

Транзакция — это логическая единица работы, которая обычно включает выполнение нескольких операций базы данных. Выполнение транзакции начинается с выполнения опе- ратора BEGIN TRANSACTION и завершается выполнением оператора COMMIT (нормальное за- вершение) или ROLLBACK (аварийное завершение). Транзакции обладают свойствами ато- марности, продолжительности и изолированности одна от другой. При чередующемся выполнении операций нескольких параллельно обрабатываемых транзакций обычно гаран- тируется, что выполнение этих операций будет упорядоченным.

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

Упражнения

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

высказывание производная переменная-отношение

замкнутость реляционная база данных

каталог реляционная модель

операции на уровне множеств реляционная СУБД

оптимизация соединение

откат фиксация транзакции

2. Опишите содержимое переменных-отношений каталога TABLE и COLUMN для базы данных поставщиков и деталей.

3. Как пояснялось в разделе 3.6, каталог должен описывать самого себя, т.е. включать записи о переменных-отношениях самого каталога. Дополните рис. 3.6 так, чтобы он включал необходимые записи о самих переменных-отношениях TABLE и COLUMN.

4. Вот запрос для базы данных поставщиков и деталей.

RESULT := ( ( S JOIN SP ) WHERE Pi = 'P2' ) { Si, CITY } ; Что получится в результате его выполнения?

Замечание. Здесь может возникнуть небольшое затруднение, касающееся типа дан- ных столбца Pi. Мы возвратимся к этому вопросу в разделе 5.2 главы 5 (подраздел "Домены"). Аналогичное замечание относится и к следующему упражнению.

3.5. Предположим, что выражение, расположенное в запросе из упр. 3.4 справа, ис- пользуется для определения представления.

CREATE VIEW V AS

( ( S JOIN SP ) WHERE Pi = 'P2' ) { Si, CITY } ;

Теперь рассмотрим следующий запрос.

RESULT := { V WHERE CITY = 'London' ) { Si } ;

Что получится в результате его выполнения? Поясните, какой компонент исполь- зуется со стороны СУБД при выполнении запроса.

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

Список литературы

3.1. Codd E.F. Relational Database: A Practical Foundation for Productivity // CACM. — February, 1982. — 25, № 2. (Переиздано: Robert L. Ashenhurst (ed.). ACM Turing Award Lectures: The First Twenty Years 1966-1985.— Reading, Mass.: Addison-Wesley, 1989.)

Статья была представлена Коддом на соискание награды ACM Turing Award в 1981 году. В ней обсуждается хорошо известная проблема отставания разработ- ки приложений. Перефразируя ее, можно сказать: "Потребности в приложениях для компьютеров быстро возрастают — настолько быстро, что отделы информаци- онных систем (которые несут ответственность за написание приложений) отстают от них все больше и больше". Существует два дополнительных метода разрешения этой проблемы.

1. Предоставить специалистам по информационным технологиям новые средства для повышения продуктивности их работы.

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

Оба подхода необходимо развивать, причем в предлагаемой статье Кодда приво- дится обоснование того, что основу для обоих этих подходов дает применение ре- ляционной технологии.

3.2. Date C.J. Why Relational? // C.J. Date. Relational Database Writings 1985-1989. — Reading, Mass.: Addison-Wesley, 1990.

Попытка предоставить краткую, но достаточно основательную сводку основных преимуществ реляционного подхода. Приведем следующее высказывание из ста- тьи: "Среди многочисленных преимуществ реляционного подхода существует одно, которое следует особо подчеркнуть: наличие солидной теоретической базы". Цитирую:

"...реляционная действительно является иной. Она отличается тем, что не является произвольной. Прежние же системы, напротив, имели произвольно выбранную ор- ганизацию; они предоставляли решения для определенных задач того времени, но

у них не было твердой теоретической базы, тогда как у реляционных систем такая база есть... а это означает, что [они] надежны, как скала".

"Благодаря этому твердому основанию поведение реляционных систем отли- чается предсказуемостью и пользователь (возможно, не осознавая этого) дер- жит в голове простую модель этого поведения, позволяющую ему предвидеть, что сделает система в той или иной ситуации. Сюрпризов быть не может (или не должно быть). Предопределенность означает, что пользовательский интер- фейс прост для понимания, документирования, обучения, изучения, использо- вания и запоминания." 3.3. Date C.J. and Hugh Darwen. Foundation for Object/Relational Databases: The third manifesto. — Reading, Mass.: Addison-Wesley, 1998. Также см. вводный обзор ста- тьи "The third manifesto: Foundation for Object/Relational Databases" в издании Date C.J., Hugh Darwen, David McGoveran. Relational Database Writings 1994-1997. — Reading, Mass.: Addison-Wesley, 1998.

Третий манифест — это детализированное, формальное и подробное предложе- ние будущих направлений развития СУБД. Манифест можно рассматривать как абстрактный план проектирования СУБД и языка этой СУБД. Данный план ос- нован на классических фундаментальных понятиях тип, значение, переменная и оператор. Например, у нас может быть тип INTEGER; целое число "3" может быть значением этого типа; N может быть переменной этого типа, значение ко- торой в каждый момент — это некоторое целое значение (т.е. некоторое значе- ние этого типа); знак "+" может быть оператором, применяемым к целым значе- ниям (т.е. к значениям этого типа).

Ответы к некоторым упражнениям

3.3. На рис. 3.10 показаны строки таблиц TABLES и COLUMNS (остальные строки, описы- вающие пользовательские таблицы, пропущены). Понятно, что дать точные значе- ния в столбцах COLCOUNT и R0WC0UNT невозможно.

TABLES	TABNAME	COLCOUNT	ROWCOUNT	.....
	TABLES	(>3)	(>2)	.....
	COLUMNS	(>2)	(>5)

COLUMNS	TABNAME	COLNAME
	TABLES	TABNAME
	TABLES	COLCOUNT
	TABLES	ROWCOUNT
	COLUMNS	TABNAME
	COLUMNS	COLNAME

Рис. 3.10. Записи каталога для самих переменных-отношений TABLES и COLUMNS ^ (схематически)

•3.4. Запрос предназначен для выбора номеров и городов тех поставщиков, которые по- ставляют деталь с номером 'Р2'.

3.5. Значение этого запроса следующее: "Выбрать номер поставщика из Лондона, по- ставляющего деталь с номером 'Р2'". Первый шаг при выполнении запроса (замена имени V значением, определяющим переменную-отношение V) дает следующее.

( ( ( ( S JOIN SP ) WHERE Pt = 'P2' ) { Si, CITY } )

WHERE CITY = 'London' ) { Si }

Это выражение можно упростить.

( ( S WHERE CITY = 'London' ) JOIN ( SP WHERE Pi = 'P2' ) ) { Si }

Объяснение и дальнейшее обсуждение правил построения подобных выражений приводятся в главах 9 и 17.