3.10. Резюме

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

Реляционная база данных представлена пользователю как множество отношений или таблиц. Все значения в отношении атомарные или скалярные (нет групп повторе­ния). Реляционная система поддерживает реляционные базы данных и операции над ними, в частности включающие в себя операцию выборки строк RESTRICT (иногда называемую SELECT), операцию выборки столбцов PROJECT (также называемую проекцией) и операцию соединения таблиц JOIN. Эти и подобные операции выпол­няются на уровне множества. Свойство замкнутости реляционных систем означает, что результат операции имеет тот же тип, что и объекты, над которыми проводилась операция (все они являются отношениями); это позволяет использовать вложенные реляционные выражения.

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

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

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

Производная таблица — это таблица, полученная из других таблиц посредством ре­ляционного выражения. Базовая таблица— это таблица, не являющаяся производной. Представление— это именованная производная таблица, определение которой через другие таблицы содержится в каталоге. Пользователь может оперировать представления­ми практически так же, как и базовыми таблицами. Система выполняет операции над представлениями, заменяя ссылки на название представления выражением, определяю­щим его, т.е. преобразуя операцию над представлением в соответствующую операцию над базовыми таблицами. Этот метод реализации операций называется методом подстановки.

Стандартным языком для работы с реляционными базами данных является язык SQL. Для создания новой базовой таблицы используется оператор SQL CREATE TABLE. Оператор выборки SELECT (или SELECT-FROM-WHERE) языка SQL пре­доставляет функциональные возможности реляционных операторов RESTRICT, PROJECT и JOIN и даже больше. Операторы обновления SQL— это операторы INSERT, UPDATE и DELETE. Язык SQL очень важен с коммерческой точки зрения, но весьма далек от "идеального" реляционного языка.

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

И в заключение попробуем провести параллель между материалом этой главы и компонентами архитектуры ANSI/SPARC, описанной в главе 2. Это соответствие не всегда четкое, но полезное для лучшего понимания материала.

1. Базовые таблицы соответствуют концептуальному уровню архитектуры ANSI/ SPARC.

2. Как отмечалось в этой главе, представления соответствуют внешнему уровню ар­хитектуры ANSI/SPARC.

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

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

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

4. Язык SQL — это типичный (фактически стандартный) подъязык данных. В этом смысле он включает в себя язык определения данных и язык обработки данных. Как уже отмечалось, язык обработки данных SQL может использоваться как на внешнем, так и на концептуальном уровне. Так же и язык определения данных SQL можно использовать для определения объектов на внешнем уровне (представлений), концептуальном уровне (базовые таблицы) и в большинстве сис­тем (хотя эти возможности не входят в стандарт) даже на внутреннем уровне (например, для определения индексов). Более того, язык SQL предоставляет даже некоторые средства "управления данными", т.е. средства, которые нельзя отнести ни к языку определения данных, ни к языку обработки данных. Примером таких средств является оператор GRANT, который позволяет одному пользователю пе­редать определенные привилегии доступа другому пользователю (подробнее об этом в следующих частях книги).

5. Прикладные программы в SQL-системе могут получить доступ к базе данных из ба­зового языка, такого как COBOL, посредством встроенных SQL-операторов. Встро­енный язык SQL представляет "слабую связь" между языком SQL и базовым языком. В общем, любой оператор интерактивного языка SQL можно использовать во встроенном языке. Более того, существуют специальные операторы, которые можно использовать только во встроенном языке (подробнее это будет описано в главе 8).

Упражнения

3.1. Дайте определения следующим терминам: автоматическая навигация; пер­вичный ключ; базовая таблица; проекция; каталог; реляционная база данных; замкнутость; реляционная СУБД; производная таблица; реляционная модель; внешний ключ; выборка строк; соединение; операции на уровне множеств; оптимизация; представление.

3.2. Опишите содержимое таблиц каталога TABLES и COLUMNS для базы дан­ных поставщиков и деталей.

3.3. Как пояснялось в этой главе, каталог описывает сам себя, т.е. включает запи­си о самих таблицах каталога. Дополните рис. 3.4 так, чтобы он включал не­обходимые записи о самих таблицах TABLES и COLUMNS.

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

RESULT := ( ( S JOIN SP ) WHERE P# = 'P2' ) [ S#, CITY ] ;

Что получится в результате выполнения этого запроса?

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

CREATE VIEW V AS ( ( S JOIN SP ) WHERE P# = 'P2' ) [ S#, CITY ] ;

Теперь рассмотрим запрос

ANSWER := ( V WHERE CITY = 'London' ) [ S# ] ;

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

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

3.1. Codd E.F. Relational Database: A Practical Foundation for Productivity // CACM.— 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. Relational Technology: A Brief Introduction // C.J. Date and Hugh Harwen. Relational Database Writings 1989-1991. — Reading, Mass.:

Addison-Wesley, 1992.

В этой статье настоящая глава была частично опубликована в несколько иной форме.

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

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

TABLES

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

COLUMNS

TABNAME	COLNAME	……………
TABLES TABLES TABLES COLUMNS COLUMNS ……………	TABNAME COLCOUNT ROWCOUNT TABNAME COLNAME …………….	…………… …………… …………… …………… …………… ……………

Рис. 3.10. Записи каталога для самих таблиц TABLES и COLUMNS (схематически)

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

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

( ( ( ( S JOIN SP ) WHERE Р# = 'Р2' ) [ S#, CITY ] )

WHERE CITY = 'London' ) [ S# ]

Это выражение можно упростить следующим образом:

( ( S WHERE CITY = 'London' ) JOIN ( SP WHERE P# == 'Р2' ) ) [ S# ]

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