«Boston • San Francisco • New York London • Toronto • Sydney • Tokyo • Singapore • Madrid Mexico City • Munich • Paris • Cape Town • Hong Kong • Montreal Введение в системы баз данных К. Дж. Дейт Москва • Санкт-Петербург ...»

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

100 Часть I. Основные понятия

УПРАЖНЕНИЯ

2.1. Начертите схему архитектуры системы баз данных, представленной в этой главе (архитектуры ANSI/SPARC).

2.2. Дайте определения следующим терминам:

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

2.4. Перечислите главные функции, выполняемые СУБД.

2.5. Укажите различия между логической и физической независимостью от данных.

2.6. Как вы понимаете термин метаданные?

2.7. Перечислите главные функции, выполняемые АБД.

2.8. Укажите различия между СУБД и системой управления файлами.

2.9. Приведите несколько примеров инструментальных средств, предоставляемых раз личными поставщиками.

2.10. Приведите несколько примеров утилит базы данных.

2.11. Проанализируйте любую доступную вам систему баз данных. Попытайтесь представить ее в соответствии с архитектурой ANSI/SPARC, как описано в этой главе. Полностью ли она поддерживает три уровня архитектуры? Как определе ны отображения между уровнями? Чем подобны различные языки определения данных (внешний, концептуальный и внутренний)? Какой подъязык данных поддерживает система? Какой язык является базовым? Кто выполняет функции АБД? Имеются ли какие-нибудь средства организации защиты и поддержания целостности данных? Существует ли в системе словарь? Описывает ли он сам себя? Какие приложения, предоставляемые поставщиками, поддерживает система? Какие утилиты входят в состав системы? Есть ли в системе отдельный компонент диспетчера передачи данных? Имеются ли какие-либо возможности распределенной обработки?

СПИСОК ЛИТЕРАТУРЫ

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

2.1. ANSI/X3/SPARC Study Group on Data Base Management Systems. Interim Report // FDT (ACM SIGMOD bulletin). - 1975. - 7, № 2.

2.2. Tsichritzis D.C. and Klug A. (eds). The ANSI/X3/SPARC Framework: Report of the Study Group on Data Base Management Systems // Information Systems. — 1978. — 3.

Эти два документа, [2.1] и [2.2],— соответственно, предварительный и окончательный отчеты группы ANSI/X3/SPARC Study Group. Группа ANSI/X3/SPARC (полное название — Study Group on Data Base Management Systems) была организована в 1972 году комитетом Standards Planning and Requirements Committee (SPARC) института American National Standards Institute on Computers and Information Processing (ANSI/X3).

Примечание. Примерно через 25 лет название ХЗ перешло к комитету NCITS (National Committee on Information Technology Standards — Национальный комитет по стандартам информационной технологии). Несколько лет спустя это название было снова передано, на этот раз комитету INCITS, в названии которого буквы IN, которые обозначают международный (INternational), заменили букву N, обозначавшую национальный (National) в названии NCITS.

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

2.3. Van Griethuysen J.J. (ed.). Concepts and Terminology for the Conceptual Schema and the Information Base // International Organization for Standardization (ISO) Technical Report ISO/TR9007. -July 1987.

Этот документ представляет собой отчет рабочей группы Международной организации по стандартизации (International Standard Organization — ISO), в который включено "определение понятий для языков концептуальных схем". В отчете рабочей группы предложено три альтернативных подхода (точнее, три группы подходов) к формализации концептуальной схемы. Каждый из подходов был применен к стандартному примеру, связанному с деятельностью гипотетического управления 102 Часть I. Основные понятия регистрацией автомобилей. Три группы — это подходы "сущность—атрибутсвязь", подходы с использованием бинарных связей и подходы, основанные на интерпретируемой предикатной логике. В отчете обсуждаются фундаментальные понятия, лежащие в основе понятия концептуальной схемы, а также излагаются принципы реализации системы, которая должным образом поддерживает концептуальную схему. Это достаточно сложный, однако очень важный документ для всех, кто серьезно интересуется концептуальным уровнем системы.

2.4. Kent W. Data and Reality. — Amsterdam, Netherlands: North-Holland; New York, N.Y.:

Elsevier Science, 1978.

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

2.5. Odysseas G. Tsatalos, Marvin H. Solomon, and Yannis E. Ioannidis. The GMAP:

A Versatile Tool for Phisical Data Independence. Proc. 20th Int. Conf. On Very Large Data Bases. — Santiago, Chile. — September 1994.

Сокращение GMAP означает обобщенный многоуровневый путь доступа (Generalized Multi-Level Access Path). Авторы статьи справедливо отмечают, что современные продукты баз данных "вынуждают пользователей составлять запросы в терминах логической схемы, которая непосредственно связана с физическими структурами", и поэтому усиливают зависимость от физических данных. В этой статье предлагается язык отображения "концептуальный-внутренний" (по терминологии данной главы), который можно использовать для значительно большего количества видов отображений, чем обычно обеспечивается в современных продуктах. Предоставляются конкретная логическая схема и язык, основанный на реляционной алгебре (см. главу 7), и следовательно, описательный, а не процедурный по своей природе, что позволяет определить множество физических схем, которые формально следуют из такой логической схемы. Кроме всего прочего, подобные физические схемы могут включать вертикальное и горизонтальное разделения (глава 21), произвольное количество путей физического доступа, группирование и контроль избыточности.

В статье также приводится алгоритм преобразования пользовательских операций над логической схемой в эквивалентные операции над физической схемой. Прототип реализации показывает, что АБД получает возможность настроить физическую схему так, чтобы "достичь значительно более высокой производительности по сравнению с той, которой можно добиться обычными методами".

Введение в реляционные базы данных 3.1. Введение 3.2. Реляционная модель 3.3. Отношения и переменные отношения 3.4. Смысл отношений 3.5. Оптимизация 3.7. Базовые переменные отношения и представления 3.8. Транзакции 3.9. База данных поставщиков и деталей 3.10. Резюме Как отмечалось в главе 1, в этой книге основное внимание сконцентрировано на реляционных системах. В части II подробно описаны теоретические основы таких систем, а точнее — реляционная модель данных.

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

3.2. РЕЛЯЦИОННАЯ МОДЕЛЬ Как уже неоднократно отмечалось, реляционные системы базируются на формальных основах, или теории, которая называется реляционной моделью данных. Интуитивно ясно, что, кроме всего прочего, в такой системе выполняются как минимум три условия.

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

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

Аспект обработки. В распоряжении пользователя имеются операторы манипулиро вания таблицами (например, предназначенные для поиска данных), которые гене рируют новые таблицы на основании уже имеющихся и среди которых есть, по крайней мере, операторы сокращения (restrict), проекции (project) и объединения На рис. 3.1 показан простой пример реляционной базы данных отделов (таблица DEPT) и служащих (таблица ЕМР). Очевидно, что эта база данных действительно "воспринимается как набор таблиц" (по-видимому, смысл этих таблиц не требует пояснений). На рис. 3. показаны некоторые примеры операций сокращения, проекции и соединения для этой базы данных. Ниже приведены (очень нестрогие!) определения этих операций.

Рис. 3.1. База данных отделов и служащих (приведенные в ней данные часто используются в качестве примера) Операция сокращения извлекает указанные строки из таблицы (в названии этой операции подразумевается, что кардинальность ее результата меньше или равна кардинальности исходной таблицы). Следует отметить, что операцию сокращения иногда называют выборкой; мы предпочитаем термин сокращение, поскольку соот ветствующий оператор не полностью соответствует оператору SELECT языка SQL.

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

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

Общий результат состоит из множества всех таких соединенных строк. Обратите внимание, что столбец DEPT# в каждой результирующей строке встречается один раз, а не два.

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

Рис. 3.2. Примеры применения операций сокращения, проекции и соединения Таблица 3.1. Строки таблиц ЕМР и DEPT перед соединением Таблица 3.2. Результат соединения Необходимо отметить одну важную особенность, очевидную из рис. 3.2: результат выполнения каждой из трех представленных операций — это еще одна таблица (другими словами, эти операторы фактически "порождают таблицы из таблиц", что и было указано ранее). Это —пример проявления реляционного свойства замкнутости. Оно имеет очень большое значение, главным образом потому, что результатом выполнения операции является объект того же рода, что и объект, над которым производилась операция, а именно — таблица. Но это значит, что к результатам операций можно снова применить 106 Часть I. Основные понятия какую-либо операцию. Например, можно сформировать проекцию соединения, соединение двух сокращений, сокращение проекции и т.д. Другими словами, можно использовать вложенные выражения, т.е. выражения, в которых операнды представлены выражениями, а не простыми именами таблиц. В данной и последующих главах показано, что этот факт имеет, в свою очередь, целый ряд важных следствий.

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

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

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

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

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

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

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

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

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

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

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

108 Часть I. Основные понятия базы данных потребовалось бы определить несколько ограничений поддержки целостности базы. Например, допустим, что зарплата служащих не должна выходить за пределы от 25 до 95 тыс. долл. в год, а бюджет отдела должен находиться в пределах от 1 до 15 млн.

долл. и т.д. Некоторые из таких правил имеют настолько важное практическое значение, что получили специальные названия. Рассмотрим их более подробно.

1. Каждая строка в таблице DEPT должна включать уникальное значение столбца DEPT#; аналогично, каждая строка в таблице ЕМР должна включать уникальное значение столбца ЕМР#. Говорят, что столбцы DEPT# В таблице DEPT И ЕМР# В таб лице ЕМР являются первичными ключами для своих таблиц. (Напомним, что в главе мы условились отмечать столбцы первичных ключей двойным подчеркиванием.) 2. Каждое значение столбца DEPT# в таблице ЕМР ДОЛЖНО быть представлено и в виде значения столбца DEPT# в таблице DEPT в соответствии с тем фактом, что каждый служащий должен быть приписан к существующему отделу. Говорят, что столбец DEPT# в таблице ЕМР является внешним ключом, ссылающимся на первичный ключ таблицы DEPT.

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

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

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

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

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

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

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

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

3.3. ОТНОШЕНИЯ И ПЕРЕМЕННЫЕ ОТНОШЕНИЯ

Если предположить, что реляционная база данных — это по существу просто база данных, в которой данные представлены в виде таблиц (а это так и есть), то возникает резонный вопрос: почему же мы называем такую базу данных именно реляционной, а не, скажем, табличной? Ответ прост (фактически он был дан еще в главе 1): термин "relation" (отношение) — это формальное название таблицы (точнее, определенного вида таблиц;

подробности будут приведены в главе 6). Например, можно сказать, что база данных отделов и служащих, представленная на рис. 3.1, содержит два отношения.

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

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

Принципы реляционной модели были сформулированы в 1969 и 1970 годах Е.Ф. Коддом (E.F. Codd), который в то время работал в корпорации IBM. В конце 1968 года Кодд, математик по образованию, впервые пришел к выводу, что для внедрения в сферу управления базами данных строгих и точных принципов можно использовать математические дисциплины. В то время данной области недостава ло именно этих качеств. Идеи Кодда впервые подробно были изложены в статье "A Relational Model of Data for Large Shared Data Banks", ставшей классической (см. [6.1] в главе 6).

С того времени эти идеи стали общепринятыми и оказали весьма существенное влияние на все аспекты технологии баз данных, а также на другие области, такие как искусственный интеллект, обработка естественных языков и проектирование аппаратных средств.

В теории реляционной модели, с того времени, как она была первоначально сформулирована Коддом, умышленно применялись лишь определенные, тщательно подобранные термины. Например, вначале сам термин отношение в сфере информационных технологий практически не использовался, хотя такое понятие иногда употреблялось в других областях. Суть заключалась в том, что многие распространенные тогда термины были очень нечеткими — им не хватало точности, необходимой для такой формальной теории, которую предложил Кодд. Например, рассмотрим термин запись. В разное время и в различных контекстах он мог означать экземпляр записи или тип записи, логическую запись или физическую запись, хранимую запись или виртуальную запись, а возможно, и еще что-нибудь. Поэтому в формальной реляционной модели термин запись не используется вообще — вместо него применяется термин кортеж (tuple), точное определение которого дал сам Кодд, когда ввел его впервые. Мы не станем приводить здесь это определение (оно дано в главе 6), а лишь отметим, что термин кортеж приблизительно соответствует понятию строки (так же, как термин отношение приблизительно соответствует понятию таблицы). Аналогичным образом, в реляционной модели не используется 110 Часть I. Основные понятия термин поле; вместо него используется термин атрибут, который в рассматриваемом контексте примерно соответствует понятию столбца таблицы.

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

Снова обратимся к базе данных отделов и сотрудников, представленной на рис. 3.1.

Заметим, что таблицы DEPT И ЕМР В базе данных фактически являются переменными отношения, т.е. их значения — это значения отношения (т.е. отношения принимают различные значения в разное время). Предположим, например, что таблица ЕМР в данный момент имеет значение (значение отношения), которое показано на рис. 3.1, и далее допустим, что мы удалили строку о сотруднике с фамилией Saito (его номер — Е4).

DELETE ЕМР WHERE ЕМР# = ЕМР# ('Е4') ;

Результат выполнения этой операции показан на рис. 3.3.

Рис. 3.3. Переменная отношения ЕМР после удаления строки сотрудника с кодом Е Концептуально это действие можно описать таким образом: старое значение отношения ЕМР было заменено в целом совершенно другим, новым значением отношения.

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

ЕМР := ЕМР WHERE NOT ( ЕМР# = ЕМР# ( ' Е4 ' ) ) ;

Как и при любом присваивании, здесь с концептуальной точки зрения сначала вычисляется выражение, расположенное справа от знака присваивания, а затем результат присваивается переменной, которая записана перед знаком присваивания (по определению перед знаком присваивания может стоять, естественно, только переменная). В целом, как уже отмечалось, задача заключается в том, чтобы заменить "старое" значение отношения ЕМР "новым".

Примечание. Как первоначальный оператор DELETE, так и равносильный ему оператор присваивания записаны на языке Tutorial D, который широко используется в данной книге.

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

Но вот что огорчает: во многих публикациях используется термин отношение, когда в действительности подразумевается переменная отношения (а также тогда, когда подразумевается само отношение, т.е. значение отношения). А это, как показывает практика, приводит к путанице. Поэтому в дальнейшем мы будем четко различать переменные отношения и сами отношения. Следуя примеру публикации [3.3], для переменной отношения (relation variable) будем использовать термин переменная отношения (сокращенный английский вариант — relvar), и только этот термин, во всех случаях, когда речь будет идти не об отношении, а о переменной отношения3. Обратите внимание на то, что с этого момента неуточненный термин отношение будет применяться именно для описания значения отношения (по такому же принципу, как, например, неуточненный термин целое число применяется исключительно для описания целочисленного значения), хотя время от времени мы будем также использовать уточненный термин значение отношения, чтобы подчеркнуть его отличие от переменной отношения.

Прежде чем перейти к дальнейшему изложению, следует предупредить читателя, что термин переменная отношения (relvar) не является общепринятым, хотя должен быть таковым! Мы действительно считаем, что очень важно различать сами отношения (т.е. значения отношений) и переменные отношения как таковые. (Автор должен признать, что такое требование не учитывалось в предыдущих изданиях настоящей книги, как и в другой литературе по базам данных. Мало того, до сих пор большинство специалистов в этой области игнорируют существенные различия между отношениями и переменными отношения.) Особое внимание следует обратить на то, что ограничения целостности и операции обновления, которые рассматриваются в главах 6 и 9, в соответствии с их определением, должны, безусловно, применяться к переменным отношения, а не к отношениям.

3.4. СМЫСЛ ОТНОШЕНИЙ В главе 1 отмечалось, что столбцы в отношениях связаны с типами данных. А в конце раздела 3.2 мы говорили, что реляционная модель включает "неограниченный набор типов [данных]". Помимо всего прочего, это означает, что пользователи могут определять собственные типы (а также, конечно, применять определяемые системой или встроенные типы). Например, определять типы можно представленным ниже способом (снова воспользуемся синтаксисом языка Tutorial D, причем многоточие "..." здесь заменяет сами определения, которые для нас сейчас не важны).

TYPE EMP#... ;

TYPE NAME... ; TYPE MONEY... ;

Тип ЕМР#, например, можно рассматривать, как множество всевозможных табельных номеров, тип NAME — как множество всевозможных имен и т.д.

Теперь обратимся к рис. 3.4, который фактически представляет собой часть представленного на рис. 3.1 отношения ЕМР, дополненного обозначениями типов столбцов. Как показано на этом рисунке, каждое отношение, точнее, каждое значение отношения, состоит из двух частей: набора пар "имя_столбца:имя_типа" (заголовка) и набора строк, согласованных с этим заголовком (тела). Следует отметить, что на практике компоненты заголовка "имя_типа" зачастую опускают, как это делали и мы во всех предыдущих примерах. Однако необходимо учитывать, что концептуально они всегда присутствуют.

Различие между значениями отношения и переменными отношения фактически представляют собой особый случай различия между значениями и переменными в целом. Последнее различие подробно анализируется в главе 5.

112 Часть I. Основные понятия Рис. 3.4. Пример значения отношения ЕМР с указанием типов столбцов Рассмотрим один важный, хотя и не столь распространенный, способ представления смысла отношений.

Во-первых, в определенном отношении r заголовок отношения r представляет со бой определенный предикат (под предикатом подразумевается просто функция с истинностными значениями, которая, как и все функции, имеет ряд формальных параметров).

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

Служащий с табельным номером ЕМР# и фамилией ENAME работает в отделе с номером DEPT# и получает зарплату SALARY.

Здесь формальными параметрами являются ЕМР#, ENAME, DEPT# И SALARY, которые, конечно же, соответствуют четырем столбцам переменной отношения ЕМР. Ниже приведены примеры соответствующих истинных утверждений.

Служащий с табельным номером Е1 и фамилией Lopez работает в отделе с номером D1 и получает зарплату 40 тыс. долл. в год.

(Получено путем подстановки в параметр ЕМР# значения Е1, в параметр NAME — значения Lopez, в параметр DEPT# — значения D1 и в параметр SALARY — значения 4 ОК.) Служащий с номером Е2 и фамилией Cheng работает в отделе с номером D1 и получает зарплату 42 тыс. долл. в год.

(Получено путем подстановки в параметр ЕМР# значения Е2, в параметр NAME — значения Cheng, в параметр DEPT# — значения D1 и в параметр SALARY — значения 42К.) Иными словами:

типы — это объекты (множества объектов), которые могут стать предметом отношения — это факты (множества фактов), касающиеся объектов, которые могут стать предметом обсуждения.

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

"Служащий с определенным табельным номером имеет определенное имя, работает в определенном отделе и получает определенную зарплату".

Из вышесказанного следует:

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

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

Кстати, важно понимать, что каждое отношение имеет связанный с ним предикат, включая отношения, полученные с помощью реляционных операторов, например оператора соединения. Отношение DEPT на рис. 3.1 и три результирующих отношения на рис. 3.2 имеют предикаты, которые определены следующим образом.

DEPT. "Отдел с номером DEPT# называется DNAME И имеет бюджет BUDGET".

Сокращение отношения DEPT, где BUDGET > 8М. "Отдел с номером DEPT# назы вается DNAME и имеет бюджет BUDGET, который превышает 8 млн. долл.".

Проекция, состоящая из столбцов DEPT# и BUDGET отношения DEPT. "Отдел с номером DEPT# имеет некоторое название и бюджет BUDGET".

Соединение переменных отношения DEPT и ЕМР на основе столбца DEPT#. "Отдел с номером DEPT# называется DNAME И имеет бюджет BUDGET, а служащий с номе ром ЕМР# по фамилии ENAME работает в отделе с номером DEPT# и получает зар плату SALARY" (заметим, что этот предикат имеет шесть параметров, а не семь, поскольку две ссылки на DEPT# обозначают один и тот же параметр).

Наконец, следует отметить, что переменные отношения также имеют предикаты.

Таковым является предикат, общий для всех отношений, которые представляют собой возможные значения рассматриваемой переменной отношения. Например, предикат для переменной отношения ЕМР можно представить следующим образом.

Служащий с табельным номером ЕМР# имеет фамилию ENAME, работает в отделе DEPT# и получает зарплату SALARY 114 Часть I. Основные понятия 3.5. ОПТИМИЗАЦИЯ Как было описано в разделе 3.2, все реляционные операции, такие как сокращение, проекция и соединение, выполняются на уровне множеств. Поэтому реляционные языки часто называют непроцедурными, так как пользователь указывает, что делать, а не как делать. Фактически пользователь сообщает лишь, что ему нужно, без указания процедуры получения результата. Процесс навигации (перемещения) по хранимой базе данных в целях удовлетворения запроса пользователя выполняется системой автоматически, а не пользователем вручную. Поэтому реляционные системы иногда называют системами автоматической навигации. В нереляционных системах за навигацию по базе данных в основном несет ответственность сам пользователь. На рис. 3.5 приведена яркая иллюстрация преимуществ автоматической навигации — оператору языка SQL INSERT противопоставлен код навигации, подготовленный "вручную". Для получения того же результата подобный код, вероятно, должен быть подготовлен пользователем любой нереляционной системы (в данном случае — сетевой системы CODASYL; пример взят из главы по сетевым базам данных в [1.5]). Следует отметить, что здесь в качестве примера снова используется база данных деталей и поставщиков. За подробностями обратитесь к разделу 3.9.

Несмотря на предыдущие замечания, следует отметить, что непроцедурный — это хотя и общепринятый, но не совсем точный термин, потому что процедурный и непроцедурный — понятия относительные. Обычно можно с уверенностью определить лишь то, является ли язык А более (или менее) процедурным, чем язык Б. Поэтому точнее будет сказать, что реляционные языки, такие как SQL, характеризуются более высоким уровнем абстракции, чем типичные языки программирования, подобные C++ или COBOL (либо подъязыки данных, обычно принадлежащие нереляционным СУБД; см. рис. 3.5). В принципе, именно более высокий уровень абстракции способствует повышению продуктивности труда программистов, свойственному для реляционных систем.

Ответственность за организацию выполнения автоматической навигации возложена на очень важный компонент СУБД — оптимизатор (мы уже упоминали о нем в главе 2).

Другими словами, работа оптимизатора заключается в том, чтобы выбрать самый эффективный способ выполнения для каждого запроса пользователя. Предположим, например, что пользователь сделал следующий запрос (снова воспользуемся языком Tutorial D).

( EMP WHERE ЕМР# = ЕМР# ('Е4') ) { SALARY } Пояснение. Выражение в первых скобках (EMP WHERE...) означает, что применяется операция сокращения текущего значения переменной отношения ЕМР, касающаяся той строки, в которой значение столбца ЕМР# равно Е4. Применяемая здесь языковая конструкция, представляющая собой имя столбца SALARY, заключенное в фигурные скобки, означает проекцию результата операции сокращения по столбцу SALARY. Результатом этой операции проекции становится отношение, состоящее из одного столбца и одной строки, которое содержит данные о заработке служащего Е4. (Обратите внимание, что в данном случае в неявном виде используется реляционное свойство замкнутости: мы написали вложенное выражение, в котором результат операции сокращения применяется в качестве входных данных для операции проекции.) Рис. 3.5. Примеры автоматической навигации и навигации вручную Даже в этом простом примере могут применяться по крайней мере два способа доступа к необходимым данным.

1. Последовательный физический просмотр (хранимой версии) переменной отношения ЕМР, пока требуемая запись не будет найдена.

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

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

116 Часть I. Основные понятия на какие переменные отношения есть ссылки в запросе;

насколько велики эти переменные отношения в настоящее время;

какие существуют индексы;

насколько избирательны эти индексы;

как физически группируются данные на диске;

какие реляционные операции используются; и т.д.

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

Более подробные сведения об оптимизаторе приводятся в главе 18.

3.6. КАТАЛОГ Как отмечалось в главе 2, каждая СУБД должна поддерживать функции каталога, или словаря. Каталог обычно размещается там, где хранятся различные схемы (внешние, концептуальные, внутренние) и все, что относится к отображениям ("внешнийконцептуальный", "концептуальный-внутренний", "внешний-внешний"). Иначе говоря, в каталоге содержится подробная информация (иногда называемая описательной информацией или метаданными), касающаяся различных объектов, которые имеют значение для самой системы. Примерами таких объектов могут служить переменные отношения, индексы, ограничения поддержки целостности, ограничения защиты и т.д. Описательная информация необходима для обеспечения правильной работы системы. Например, оптимизатор использует информацию каталога об индексах и других физических структурах хранения данных, а также прочую информацию, необходимую ему для принятия решения о том, как выполнить тот или иной запрос пользователя (см. главу 18). Аналогично, подсистема защиты использует информацию каталога о пользователях и установленных ограничениях защиты (глава 17), чтобы разрешить или запретить выполнение поступившего запроса.

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

Отметим, что исходя из наличия на этом рисунке столбца ROWCOUNT, можно сделать следующее за ключение: выполнение в базе данных операций INSERT и DELETE в качестве побочного эффекта потре бует обновления данных каталога. На практике столбец ROWCOUNT обычно обновляется только по спе циальному запросу (например, при запуске некоторой утилиты), поэтому значения этого столбца не всегда будут актуальными.

Рис. 3.6. Каталог базы данных отделов и служащих (изображен схематически) Примечание. Как упоминалось в главе 2, каталог должен также описывать сам себя, т.е.

включать записи, описывающие переменные отношения самого каталога (см. упр. 3.3).

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

Тогда необходимое выражение будет выглядеть следующим образом.

( COLUMNS WHERE TABNAME = 'DEPT' ) { COLNAME } Вот еще один пример. Пусть необходимо узнать, в каких переменных отношения есть столбец ЕМР#.

( COLUMNS WHERE COLNAME = 'ЕМР#' ) { TABNAME } Упражнение для самопроверки. Каким будет результат выполнения следующего выражения?

( ( TABLES JOIN COLUMNS )

3.7. БАЗОВЫЕ ПЕРЕМЕННЫЕ ОТНОШЕНИЯ И

ПРЕДСТАВЛЕНИЯ

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

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

118 Часть I. Основные понятия Примечание. В [3.3] базовые переменные отношения называются реальными переменными отношения.

Реляционные системы, очевидно, должны предоставлять средства для создания, в первую очередь, базовых переменных отношения. В языке SQL, например, эта функция обеспечивается оператором CREATE TABLE (здесь слово TABLE используется в узком смысле, как базовая переменная отношения). Базовые переменные отношения, конечно же, должны быть именованными, как, например, показано ниже.

CREATE TABLE EMP... ;

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

CREATE VIEW ТОРЕМР AS

) { EMP#, ENAME, SALARY } ;

Примечание. Поскольку в данный момент это несущественно, в примере для удобства используется смешанная нотация языков SQL и Tutorial D.

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

Рис. 3.7. Виртуальная переменная отношения ТОРЕМР (незатененные участки) как представление базовой переменной отношения ЕМР Примечание. Выше уже было сказано, что если такие переменные отношения, как и ЕМР, можно считать реальными, то переменную отношения ТОРЕМР следует расDEPT сматривать как виртуальную переменную отношения, иначе говоря, как переменную отношения, которая внешне существует как таковая, но на самом деле ее нет (значение этой переменной отношения в любой данный момент зависит от значений некоторых других переменных отношения). И действительно, в [3.3] представления называются виртуальными переменными отношения.

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

Аналогично, изменения, внесенные в переменную отношения ТОРЕМР, будут автоматически и немедленно применены к реальной переменной отношения ЕМР и, следовательно, станут видны через это окно (примеры будут приведены позднее).

Ниже показан пример запроса, использующего представление TОРЕМР.

( ТОРЕМР WHERE SALARY < 42К ) { ЕМР#, SALARY } Если в качестве исходных используются данные на рис. 3.7, то результат будет иметь вид, показанный на рис. 3.8.

Рис. 3.8. Результат использования представления ТОРЕМР С концептуальной точки зрения операции с представлениями, подобные рассмотренной выше, аналогичны операциям поиска, которые фактически реализуются посредством замены ссылки на имя представления выражением, которое определяет представление (т.е. выражением, сохраненным в каталоге). Поэтому в рассмотренном примере исходное выражение ( ТОРЕМР WHERE SALARY < 42К ) { ЕМР#, SALARY } модифицируется системой следующим образом.

( ( ( ЕМР WHERE SALARY > ЗЗК ) { ЕМР#, ENAME, Здесь курсивом выделено имя представления в исходном выражении и заменяющий текст в модифицированной версии. После определенного количества перегруппировок это выражение может быть упрощено (глава 18) и представлено в следующем виде.

( ЕМР WHERE SALARY > ЗЗК AND SALARY < 42К ) { ЕМР#, SALARY } Вычисление данного выражения приводит к результату, показанному выше. Иными словами, первоначальная операция над представлением просто преобразуется в эквивалентную операцию над соответствующей базовой переменной отношения, после чего 120 Часть I. Основные понятия полученная эквивалентная операция выполняется обычным образом (точнее, оптимизируется и выполняется обычным образом).

В качестве другого примера рассмотрим операцию удаления DELETE.

DELETE TOPEMP WHERE SALARY < 42K ;

На самом деле будет выполнена следующая операция.

DELETE EMP WHERE SALARY > ЗЗК AND SALARY < 42К ;

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

CREATE VIEW JOINEX AS

( ( EMP JOIN DEPT ) WHERE BUDGET > 7M ) { EMP#, DEPT# } ;

К вопросу определения и обработки представлений мы еще вернемся в главе 10. Между прочим, сейчас уже можно объяснить смысл приведенного в конце раздела 2.2 замечания, касающегося того, что термин представление (view) в реляционном контексте имеет довольно специфическое значение, не совпадающее со значением, приписанным ему в архитектуре ANSI/SPARC. На внешнем уровне этой архитектуры база данных воспринимается как внешнее представление, определяемое внешней схемой (и разные пользователи могут иметь разные внешние представления). В реляционных системах, наоборот, представление, как пояснялось выше, является специально именованной производной виртуальной переменной отношения. Поэтому реляционным аналогом внешнего представления ANSI/SPARC обычно служит множество из нескольких переменных отношения, каждая из которых является представлением в реляционном смысле. Внешняя схема состоит из определений таких представлений. (Из этого следует, что в реляционной модели представления являются одним из способов обеспечения логической независимости от данных, хотя еще раз следует отметить, что современные коммерческие продукты имеют серьезные недостатки в этой части. Подробности приведены в главе 10.) Архитектура ANSI/SPARC является достаточно общей и допускает произвольные преобразования между внешним и концептуальным уровнями. В принципе, даже типы структур данных, поддерживаемые на этих двух уровнях, могут быть различными:

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

отношения, так же важен для реляционных систем, как для математики важно то, что подмножество является множеством.

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

Есть еще один заслуживающий внимания вопрос, касающийся базовых переменных отношения и представлений. Различие между базовой переменной отношения и представлением часто характеризуют следующим образом.

Базовые переменные отношения "реально существуют" в том смысле, что они во площают в себе данные, которые действительно хранятся в базе данных.

Представления, наоборот, "реально не существуют", а просто предоставляют раз личные способы просмотра "реальных" данных.

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

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

Следующая цитата из одной недавно вышедшей книги демонстрирует некоторые недоразумения, обсуждаемые здесь, а также недоразумения, которые обсуждались в разделе 3.3: "Важно различать хранимые отношения, которые являются таблицами, и виртуальные отношения, которые являются представлениями... [Мы] будем использовать термин отношение только в тех случаях, когда вместо него можно использовать термин «таблица» или «представление». Если необходимо будет подчеркнуть, что данное отношение является хранимым отношением, а не представлением, то в этом случае мы будем использовать термин базовое отношение или базовая таблица." Подобные цитаты, к сожалению, — не редкость.

122 Часть I. Основные понятия 3.8. ТРАНЗАКЦИИ Примечание. Тему этого раздела нельзя отнести исключительно к теме реляционных систем. Тем не менее, она здесь уместна, поскольку понимание основной идеи необходимо для усвоения некоторых понятий и логичного перехода к части II. Однако здесь данная тема намеренно рассматривается лишь поверхностно.

В главе 1 указывалось, что транзакция — это логическая единица работы, обычно включающая несколько операций над базой данных. Также отмечалось, что пользователь должен иметь возможность указать системе, что отдельные операции являются частью одной транзакции. Для этого используются операции BEGIN TRANSACTION, COMMIT и ROLLBACK. Как правило, транзакция начинается при выполнении операции BEGIN TRANSACTION и прекращается при выполнении операции COMMIT ИЛИ ROLLBACK, как в следующем примере, написанном на псевдокоде.

BEGIN TRANSACTION ; /* Перевод денег со счета А на счет В UPDATE account A ; /* Списание денег со счета А */ UPDATE account В ; /* Зачисление денег на счет В */ THEN COMMIT ; /* Нормальное завершение */ ELSE ROLLBACK ; /* Аварийное завершение */ END IF ;

Отметим некоторые свойства транзакций.

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

2. Транзакции гарантируют сохранность результатов их выполнения в том смысле, что если транзакция успешно выполнила оператор COMMIT, TO все внесенные ею изменения гарантированно будут записаны в базе данных, даже если позднее в системе в какой-то момент произойдет сбой.

Примечание. По сути, благодаря именно этому свойству сохранности результатов транзакций данные в базе данных являются перманентными {постоянными) в том смысле, который указан в главе 1.

3. Для транзакций также гарантируется изолированность одной транзакции от другой.

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

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

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

Развернутое обсуждение всех остальных аспектов данной темы будет продолжено в главах 15 и 16.

3.9. БАЗА ДАННЫХ ПОСТАВЩИКОВ И ДЕТАЛЕЙ

В настоящей книге в большинстве примеров используется база данных, известная под названием базы данных поставщиков и деталей. Назначение настоящего раздела — ознакомить читателя с этой базой данных, которая будет служить примером для ссылок в следующих главах. На рис. 3.9 показано множество значений ее данных. Именно эти конкретные значения будут фактически использоваться в дальнейшем (где это имеет смысл)8. На рис. 3.10 показано определение базы данных, для которого снова используется язык Tutorial D (в этом языке ключевое слово VAR означает переменная). Обратите внимание на то, что несколько столбцов имеют типы данных, которым присвоено название, аналогичное названию соответствующего столбца. Столбцы STATUS И CITY определены как имеющие не пользовательский, а встроенный тип данных, соответственно, INTEGER (целое) и CHAR (строка символов произвольной длины). Наконец, необходимо отметить, что применительно к значениям, показанным в столбцах на рис. 3.9, должно быть сделано одно важное замечание, однако мы еще не готовы к этому. Поэтому обсуждение упомянутого замечания будет отложено до главы 5, точнее, до конца подраздела "Возможные форматы представления, селекторы и операторы ТНЕ_" в разделе 5.3.

Предполагается, что эта база данных имеет следующее назначение.

Переменная отношения S представляет поставщиков (точнее, поставщиков, рабо тающих по контракту). Каждый поставщик имеет уникальный номер (s#); имя (SNAME), не обязательно уникальное (хотя оно может быть уникальным, как в слу чае, представленном на рис. 3.9); значение рейтинга или статуса (STATUS); место расположения (CITY). Предполагается, что для каждого поставщика может быть указан только один город.

Переменная отношения Р представляет детали (точнее, виды деталей). У каждого вида детали есть номер детали (Р#), который является уникальным; название дета ли (PNAME); цвет (COLOR); вес (WEIGHT); город, где находится склад с деталями этого вида (CITY). Предполагается, что если вес детали имеет значение, то он указан в фунтах (ознакомьтесь также с тем, что сказано о единицах измерения в главе 5, Для тех читателей, которые знакомились с этими образцами данных в предыдущих изданиях, отметим, что деталь РЗ передана из Рима в Осло. Такое же изменение внесено на рис. 4.5 в следующей главе.

124 Часть I. Основные понятия раздел 5.4). Предполагается также, что каждый отдельный вид детали имеет только один цвет и хранится на складе только в одном городе.

Рис. 3.9. База данных поставщиков и деталей (пример значений) TYPE S#... ;

TYPE NAME... ;

TYPE P#... ;

TYPE COLOR... ;

TYPE WEIGHT...

; TYPE QTY... ;

VAR S BASE

STATUS INTEGER,

CITY CHAR

VAR P BASE RELATION

WEIGHT

PRIMARY KEY

VAR SP BASE RELATION

FOREIGN KEY { S# } REFERENCES S

FOREIGN KEY { P# } REFERENCES P ;

Рис. 3.10. База данных поставщиков и деталей (определение данных) Переменная отношения SP представляет поставки. Она в известном смысле служит для организации логической связи двух других переменных отношения.

Например, первая строка переменной отношения SP на рис. 3.9 связывает поставщика с номером S1 из переменной отношения S с соответствующей деталью, имеющей номер Р1 в переменной отношения Р, т.е. представляет факт поставки деталей типа Р1 поставщиком с номером S1 (а также указывает количество деталей — 300 штук). Таким образом, каждая поставка характеризуется номером поставщика (S#), номером детали (Р#) и количеством (QTY). Предполагается, что в одно и то же время может быть выполнено не больше одной поставки для одного поставщика и одного вида деталей, поэтому для каждой поставки комбинация значений столбцов s# и Р# уникальна с точки зрения набора текущих поставок, представленных в переменной отношения SP. Обратите внимание на то, что на рис. 3.9 с одним из поставщиков (с номером S5), не связано ни одной поставки.

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

И еще несколько заключительных замечаний.

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

Во-вторых, безусловно, не было бы ошибкой, если бы мы использовали более описательные названия переменных отношения, подобные SUPPLIERS (постав щики), PARTS (детали) и SHIPMENTS (поставки), вместо сокращенных названий S, Р и SP. Более того, на практике рекомендуется использовать именно такие опи сательные названия. Однако в нашем конкретном случае в последующих главах названия этих переменных отношения будут употребляться так часто, что целесо образнее использовать именно короткие названия.

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

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

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

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

Каждое отношение имеет заголовок и тело; заголовок — это набор пар "имя_столбца:

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

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

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

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

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

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

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

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

УПРАЖНЕНИЯ

3.1. Дайте определения следующим терминам:

автоматическая навигация предикат базовая переменная отношения представление высказывание производная переменная отношения 128 Часть I. Основные понятия операция на уровне множества реляционная СУБД 3.2. Опишите содержимое переменных отношения каталога TABLE и COLUMN для базы данных поставщиков и деталей.

3.3. Как пояснялось в разделе 3.6, каталог должен описывать самого себя, т.е. включать записи о переменных отношения самого каталога. Дополните рис. 3.6 так, чтобы он включал необходимые записи о самих переменных отношения TABLE 3.4. Ниже приведен запрос к базе данных поставщиков и деталей. Что получится в результате его выполнения? Какой предикат соответствует этому результату?

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

CREATE VIEW V AS

( ( S JOIN SP ) WHERE P# = P# ('P2') ) { S#, CITY } ;

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

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

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

3.7. Сформулируйте информационный принцип.

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

СПИСОК ЛИТЕРАТУРЫ

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, ACM Press Anthology Series. — 1987.) Статья была представлена Коддом по случаю получения им награды 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., Darwen H. Foundation for Object/Relational Databases: The Third Manifesto (2d edition). — Reading, Mass.: Addison-Wesley, 2000. См. также узел http: //www.thethirdmanifesto.com, где представлены некоторые формальные выдержки из этой книги, список обнаруженных опечаток и другие материалы по данной теме. Кроме того, к этой теме относится [20.1 ].

Третий манифест — это строгое, формальное и подробное предложение для выбора будущих направлений развития СУБД. Манифест можно рассматривать как абстрактный план проектирования СУБД и языка этой СУБД. Данный план основан на классических фундаментальных понятиях тип, значение, переменная и оператор.

Например, у нас может быть тип INTEGER; целое число 3 может быть значением этого типа; N может быть переменной этого типа, значение которой в каждый момент — это некоторое целое значение (т.е. некоторое значение этого типа); знак "+" может быть оператором, применяемым к целым значениям (т.е. к значениям 130 Часть I. Основные понятия того типа). Следует отметить, что в этой книге особое внимание уделено исследованию проблемы типов. Об этом свидетельствует даже ее подзаголовок: "Подробное изучение влияния теории типов на реляционную модель данных, включая всеобъемлющую модель наследования типов". Особый оттенок указанной направленности книги придает то, что теория типов и реляционная модель являются в определенной степени независимыми друг от друга. Точнее, реляционная модель не предписывает поддержку каких-либо конкретных типов (кроме логического); в ней лишь предусмотрено, что атрибуты отношений должны иметь некоторый тип;

таким образом, подразумевается, что должны поддерживаться некоторые (неопределенные) типы.

Термин переменная отношения (relation variable, или relvar) взят из этой книги. В связи с этим отметим, что в книге "Третий Манифест" сказано также следующее:

"В первой версии этого Манифеста проводилось различие между значениями базы данных и переменными базы данных, аналогичное различию между значениями отношения и переменными отношения. Кроме того, в ней было введен термин dbvar как сокращение от database variable (переменная базы данных). Хотя мы все еще полагаем, что указанное выше различие остается в силе, мы пришли к выводу, что оно почти не имеет непосредственного значения при обсуждении других, более важных аспектов этих предложений. Поэтому мы решили, в интересах использования знакомого всем языка, возвратиться к более традиционной терминологии". Но впоследствии оказалось, что это решение было неправильным... Как указано в [23.4]: "Мы сейчас можем констатировать, что было бы намного лучше преодолеть временные сложности и принять более правильные с точки зрения логики термины значение базы данных (database value) и переменная базы данных (database variable, или dbvar), несмотря на то, что они еще не нашли достаточно широкого распространения". В настоящей книге автор все еще придерживается привычного термина база данных, но принял решение об этом не в (полном) согласии со своими внутренними убеждениями. Необходимо отметить также следующее. В книге "Третий Манифест" есть такие слова: "Мы [признаем], что мы действительно чувствуем определенную неловкость в связи с тем, что назвали манифестом документ, имеющий главным образом техническое содержание.

Согласно словарю Chambers Twentieth Century Dictionary, манифест — это письменное объявление о намерениях, мнениях или мотивах некоторого лица или группы лиц (например политической партии). В отличие от этого, Третий Манифест... касается вопросов науки и логики, а не просто намерений, мнений или мотивов". Однако Третий Манифест был специально написан как ответ и возражение на два вышедших раньше документа: "Манифест объектноориентированных систем баз данных" [20.2], [25.1] и "Манифест систем баз данных третьего поколения" [26.44], поэтому выбор нами названия для своей книги был фактически предопределен чужим поступком.

3.4. С. J. Date: "Great News, The Relational Model Is Very Much Alive!", http:// www. dbdebunk. com (August 2000).

С тех пор как реляционная модель была впервые разработана в 1969 году, она подвергалась беспрецедентному количеству нападок во множестве различных публикаций. Один из последних примеров подобных публикаций имеет вполне типичное для них название: "Great News, The Relational Model Is Dead!" (Прекрасные новости — реляционная модель наконец-то мертва!). Настоящая статья была написана в качестве опровержения такой ПОЗИЦИИ.

3.5. С. J. Date: "There's Only One Relational Model!", http://www.dbdebunk.com (February 2001).

Co времени своего появления в 1969 году реляционная модель стала объектом невероятного количества попыток неправильного толкования и искажения в бесчисленных публикациях. Характерным примером может служить глава одной недавно вышедшей книги, озаглавленная "Разные реляционные модели", первое предложение который гласит: "Больше не существует такого понятия, как единая реляционная модель для баз данных (именно так?!), как нет и одной лишь геометрии". Настоящая статья также была написана в качестве опровержения указанной позиции.

4.1. Введение 4.2. Обзор языка SQL 4.3. Каталог 4.4. Представления 4.5. Транзакции 4.6. Внедрение операторов SQL 4.7. Несовершенство языка SQL 4.8. Резюме Как отмечалось в главе 1, SQL является стандартным языком для работы с реляционными базами данных и в настоящее время поддерживается практически всеми продуктами, представленными на рынке. Он был разработан в лаборатории IBM Research в начале 1970-х годов [4.9], [4.10]. Первой серьезной реализацией этого языка был продукт-прототип System R компании IBM [4.1]—[4.3], [4.12]—[4.14]; впоследствии он был реализован в многочисленных коммерческих продуктах как компании IBM [4.8], [4.14], [4.21], так и других изготовителей. В этой главе представлено введение в язык SQL, а дополнительные аспекты, касающиеся таких вопросов, как целостность, защита и т.п., обсуждаются в последующих главах, специально посвященных этим темам. При обсуждении языка SQL, если не указано иное1, мы будем основываться на текущей версии стандарта (т.е. SQL:1999). В [4.23] приведена формальная спецификация SQL: 1999; а в [4.24] можно найти значительное количество исправлений и дополнений к этой спецификации.

Примечание. Предыдущей версией стандарта была SQL: 1992, а версия SQL:

1999 предназначалась для использования в качестве совместимого расширения этой предыдущей После утверждения новой версии стандарта ("SQL:2003"), работа над которой началась в 2002 году и должна быть завершена в 2004 году, мы в следующих изданиях будем также иногда явно ссылаться на эту версию.

134 Часть I. Основные понятия версии. Однако пока можно со всей уверенностью утверждать только то, что в наши дни ни один программный продукт не поддерживает полностью даже SQL: 1992; вместо этого такие продукты, как правило, поддерживают то, что можно было бы назвать "надмножеством подмножества" стандарта (либо SQL: 1999, либо, с большей вероятностью, SQL: 1992). Вернее, большинство продуктов не поддерживают некоторые средства, обусловленные стандартом, и в то же время предлагают другие средства, которые не определены этим стандартом2. Например, программный продукт DB2 компании IBM не поддерживает все стандартные средства обеспечения целостности, но вместе с тем предусматривает возможность использовать некоторые операторы для переименования базовых таблиц, которые не определены в стандарте. И еще несколько предварительных замечаний.

Язык SQL первоначально разрабатывался конкретно как подъязык данных (см.

главу 2). Однако после включения в стандарт в конце 1996 года такого средства, как постоянные хранимые модули SQL (SQL Persistent Stored Modules — SQL/PSM, или сокращенно PSM), стандарт SQL стал полностью поддерживать все вычисли тельные конструкции (и сейчас в нем предусмотрены процедурные операторы, например CALL, RETURN, SET, CASE, IF, LOOP, LEAVE, WHILE, REPEAT, а также несколько связанных с ними функциональных возможностей, например, можно использовать переменные и обработчики исключительных ситуаций). Более под робное описание модулей PSM выходит за рамки данной книги, но подробное ин структивное руководство можно найти в [4.20].

В языке SQL вместо терминов отношение и переменная отношения используется термин таблица, а вместо терминов кортеж и атрибут — строка и столбец.

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

Необходимо подчеркнуть, что SQL — язык очень большого объема. Его специфи кация [4.23] содержит свыше 2000 страниц, не считая больше 300 страниц исправ лений в [4.24]. Поэтому в книге, подобной этой, невозможно дать исчерпывающее описание языка. Достаточно полно мы сможем рассмотреть лишь самые важные его особенности.

Наконец, нельзя не сказать о том (как уже неоднократно отмечалось в главах 1—3), что языку SQL еще очень далеко до совершенного реляционного языка. В нем много недостатков, появившихся в результате как недоделок, так и переделок. Од нако как бы там ни было, это — стандарт, он поддерживается практически всеми продуктами, представленными на рынке, и поэтому каждый специалист по базам данных должен быть знаком с этим языком, по крайней мере, в определенном объеме, поэтому он и рассматривается в данной книге.

На самом деле ни один из продуктов, по-видимому, и не смог бы в полной мере поддерживать этот стандарт, поскольку в нем на сегодняшний день содержится множество расхождений, ошибок и противоречий (о чем свидетельствуют [4.23] и [4.24]). Подробно этот вопрос рассматривается в [4.20].

4.2. ОБЗОР ЯЗЫКА SQL В языке SQL имеются операции как определения данных, так и манипулирования ими.

Сначала мы познакомимся с операциями определения данных. На рис. 4.1 показано, как с помощью средств языка SQL определяется база данных поставщиков и деталей (ср. с рис. 3.09 в главе 3). Как можно видеть, определение включает по одному оператору CREATE TYPE для каждого из шести определяемых пользователем типов (User-Defined Type — UDT) и по одному оператору CREATE TABLE ДЛЯ каждой из трех базовых таблиц (как было указано в главе 3, ключевое слово TABLE В операторе CREATE TABLE обозначает именно базовую таблицу). Каждый оператор CREATE TABLE задает имя создаваемой базовой таблицы, имена и типы данных столбцов этой таблицы, а также первичный ключ таблицы и любые внешние ключи, присутствующие в ней (кроме того, может быть указана другая дополнительная информация, которая не показана на рис. 4.1). Приведем еще пару замечаний по синтаксису.

CREATE TABLE S

SNAME NAME, STATUS

INTEGER, CITY

CHAR(15), PRIMARY

CREATE TABLE P

PNAME NAME, COLOR

COLOR, WEIGHT

WEIGHT, CITY CHAR(15)

CREATE TABLE SP

PRIMARY KEY ( S#, P# ), FOREIGN KEY ( S# ) REFERENCES S, FOREIGN

KEY ( P# ) REFERENCES P ) ;

Рис. 4.1. Определение базы данных поставщиков и деталей средствами языка SQL Обратите внимание, что символ "#", который иногда используется в книге, например, в названиях типов и в именах столбцов, на самом деле не определен в стандарте SQL.

136 Часть I. Основные понятия В качестве признака конца оператора мы здесь используем символ ";", хотя соглас но стандарту SQL, выбор используемого для этой цели символа зависит от реализа ции. Подробное рассмотрение данного вопроса выходит за рамки настоящей книги.

При использовании встроенного типа CHAR в определении таблицы на языке SQL необходимо указывать соответствующую длину (на рис. 4.1 это значение равно 15).

Определив базу данных, можно начинать выполнять в ней различные операции, задаваемые с помощью операторов манипулирования данными языка SQL: SELECT, INSERT, UPDATE и DELETE. В частности, можно выполнять с данными реляционные операции сокращения, проекции и соединения, причем во всех этих случаях следует использовать один и тот же оператор манипулирования данными языка SQL — оператор SELECT. Некоторые примеры операций показаны на рис. 4.2.

Примечание. Пример операции соединения на этом рисунке подтверждает, что в языке SQL иногда необходимо использовать уточненные имена (например s. S#, SP. S#), позволяющие устранить неоднозначность при указании столбцов. Согласно общему правилу (хотя есть и исключения), уточненные имена допустимы всегда, а неуточненные имена допустимы, только если при их использовании не возниьает неоднозначность.

Рис. 4.2. Примеры выполнения операций выборки, проекции и соединения на языке Отметим, что в языке SQL поддерживается сокращенная форма предложения SELECT, как показано в следующем примере.

SELECT *; /* или SELECT S.* (т.е. символ "*" может быть В результате выполнения этого запроса будет получена копия всей таблицы S. Символ "*"_ это сокращенное обозначение списка имен столбцов, разделенного запятыми (формальное определение этого понятия приведено в разделе 4.6). Во-первых, подразумевается, что в этом списке содержатся заданные слева направо имена всех столбцов первой таблицы, указанной в конструкции FROM, в том порядке, в котором эти столбцы определены в указанной таблице. Во вторых, за именами столбцов первой таблицы в нем следуют заданные слева направо имена всех столбцов второй таблицы, указанной в конструкции FROM, в том порядке, в котором эти столбцы определены в указанной таблице (и т.д., применительно ко всем остальным таблицам, приведенным в конструкции FROM).

Примечание. Согласно стандарту SQL, выражение SELECT * FROM т, где г— это имя таблицы, может быть сокращено до простого выражения TABLE г.

Значительно подробнее оператор SELECT обсуждается в главе 8 (раздел 8.6).

Перейдем к операциям обновления. Примеры операций INSERT, UPDATE и DELETE языка SQL приведены в главе 1. Однако во всех примерах этой главы намеренно использовались только операции обработки отдельных строк. Тем не менее, операции INSERT, UPDATE и DELETE, как и операция SELECT, обрабатывают данные на уровне множеств (некоторые упражнения и ответы к ним в главе 1 действительно демонстрировали эту возможность). Вот несколько примеров обновления на уровне множеств для базы данных поставщиков и деталей.

INSERT

INTO TEMP ( Р#, WEIGTH ) В этом примере подразумевается, что предварительно создана другая таблица TEMP с двумя столбцами, Р# и WEIGTH. Оператор INSERT вставляет в нее номера деталей и соответствующие веса всех деталей с цветом ' Red' (красный).

DELETE FROM

SP WHERE P# Этот оператор DELETE удаляет из таблицы SP все строки с информацией о поставках детали с номером ' Р2 '.

UPDATE S

SET STATUS = 2 * STATUS, WHERE CITY = 'Paris' ;

Приведенный выше оператор UPDATE увеличивает в два раза код статуса всех поставщиков в Париже и вносит в базу данных информацию о том, что эти поставщики переехали в Рим.

138 Часть I. Основные понятия Примечание. В язык SQL не включен прямой аналог операции реляционного присваивания. Но эту операцию можно эмулировать, сначала удалив все строки из целевой таблицы, а затем выполнив для нее операции INSERT... SELECT... (как это сделано выше, в первом примере).