Несколько синтаксических упрощений

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

(A UNION В) UNION С

и

A UNION (В UNION С)

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

A UNION В UNION С

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

A UNION В

и

В UNION А

эквивалентны; точно так же и для операций пересечения и произведения.

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

^[13][1]Изначально эта операция называлась restrict (дословно — ограничение), но теперь ее чаше называют select (выборка). Однако это последнее название не совсем удачное, поскольку его легко перепутать с оператором SELECT в SQL, а это далеко не то же самое. На самом деле оператор SELECT в SQL гораздо мощнее алгебраической операции restrict— он в основном включает функциональные возможности всех первоначальных восьми алгебраических операций и еще кое-что.

^[14][2]В предыдущих изданиях этой книги, придерживаясь терминологии [6.2], для этого понятия использовался термин union-compatible (дословно — совместимый для объединения), который часто встречается в литературе. Причины, побудившие нас предпочесть термин type-compatible (совместимо по типу), разъясняются далее в этой книге, где также исследуется определение этого термина (и связанное с этим ослабление довольно строгих терминов для операций объединения, пересечения и вычитания).

Язык SQL (стр. 222-228)

Глава 8

Язык SQL

Введение

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

Необходимо подчеркнуть, что SQL — очень объемный язык. Документ по его стандарту [8.1] содержит более 600 страниц, Поэтому в книге, такой как наша, невозможно дать исчерпывающее описание этого языка; достаточно полно можно описать лишь самые главные его аспекты. Хотелось бы предупредить читателя, что приведенное здесь описание языка во многих случаях беглое и поверхностное. В частности, мы не колеблясь опускали материал, не относящийся непосредственно к обсуждаемой теме и для краткости делали существенные упрощения. Более полное (но также учебное) описание можно найти в [8.5-8.7].

В этой главе затронуты следующие вопросы. Сначала обсуждаются средства определения данных; затем рассматриваются средства обработки данных (операции выборки и операции обновления). После этого описываются три ключевых конструкции SQL: табличные выражения (включая, в частности, выражения выборки), условные выражения и скалярные выражения. Далее приводятся некоторые соображения по применению "встроенного" языка SQL (т.е. средств для встраивания операторов SQL в программу на базовом языке). И, наконец, вкратце подводятся итоги главы.

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

Сделаем еще несколько предварительных замечаний. Прежде всего, приведенное обсуждение касается текущего стандарта [8.1], неформально известного как "SQL/92" ("SQL-92" или просто "SQL2"); официальное название стандарта — - Международный стандарт языка баз данных SQL (1992) (International Standard Database Language SQL). Наше изложение основано на материалах [8.5], в значительной степени пересмотренных в соответствии с требованиями данной книги. Обратите внимание на следующие отличия:

■ ■ Символ "#", который мы часто используем в именах доменов и столбцов, на самом деле в стандарте SQL/92 не допустим.

■ ■ Мы используем символ ";" как признак конца оператора, хотя согласно стандарту SQL/92 этот символ предусмотрен только для встроенного SQL и только для определенных базовых языков.

■ ■ Мы часто используем названия для синтаксических категорий, которые отличаются от стандартных названий, потому что терминология стандарта не всегда подходит для наших целей.

Хотя здесь речь идет только об уровне SQL/92, следует отметить, что ни один из коммерческих продуктов к моменту написания книги не поддерживал в полной мере стандарта SQL/92. Те языки, которые обычно поддерживаются продуктами, можно назвать "надмножествами подмножества" языка SQL/92. Другими словами, любой данный продукт, не поддерживая некоторых аспектов стандарта, в других отношениях, возможно, превосходит его. Например, продукт IBM DB2, безусловно, не поддерживает всех средств SQL/92, касающихся целостности, но он превосходит стандарт в отношении правил, связанных с обновлением представлений.

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

Определение данных

В этом разделе рассматриваются основные объекты данных и соответствующие операторы языка определения данных (data definition language — DDL) в SQL. Основные операторы DDL:

Существуют также операторы для создания и уничтожения ("сбрасывания" — "dropping") представлений, но обсуждение представлений откладывается до главы 17.

Домены

К сожалению, "домены" в SQL далеки от настоящих реляционных доменов, описываемых в этой книге; более того, эти два понятия настолько различны, что желательно было бы для этой конструкции SQL использовать другое название. Единственная цель доменов в SQL — обеспечить возможность один раз определить элементарную спецификацию типа данных (такую как "S# CHAR(5)"), а затем использовать ее одновременно для нескольких столбцов в нескольких базовых таблицах. Ниже приводится список некоторых основных различий между настоящими доменами и конструкциями SQL (смысл многих пунктов этого списка будет разъяснен в последующих главах книги).

■ ■ Как уже отмечалось, на самом деле домены SQL— просто синтаксические сокращения. Они, несомненно, не относятся к истинному типу данных, определяемому пользователем.

■ ■ Нет никаких требований, которые применялись бы для доменов SQL: столбцы в базовых таблицах могут определяться непосредственно в терминах встроенных типов данных, определяемых системой, таких как FLOAT и INTEGER.

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

■ ■ Язык SQL не осуществляет строгого контроля типов. Нет никакой проверки правильности типов. В частности, домены не "ограничивают сравнения" — единственное требование для сравнений состоит в том, чтобы сравниваемые операнды были одного и того же базового типа, т.е. оба были или числовыми, или символьными строками и т.п. Аналогичное замечание применимо и к числовым выражениям, выражениям с символьными строками и т.д. Во всех случаях домены как таковые, по существу, ими не являются.

■ ■ Язык SQL не поддерживает возможность определения пользователем операций, применяемых к данному домену.

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

■ ■ В языке SQL нет никакой концепции подтипов, надтипов или наследования.

■ ■ И наконец, в SQL нет даже поддержки, бесспорно, самого фундаментального из всех доменов — домена истинностных значений!

Ниже приводится синтаксис для создания домена SQL.

Замечание. Как и в главе 7, квадратные скобки "[" и "]" используются для указания необязательных элементов, при отсутствии которых будут использованы значения по умолчанию.

Пояснения:

1. 1. Элемент domain — это название создаваемого домена с указанным типом данных (data-type). В языке SQL поддерживаются приведенные ниже скалярные типы данных, назначение большинства из которых понятно по названию. (Также поддерживаются некоторые значения по умолчанию, сокращения, альтернативные написания, например CHAR для CHARACTER. Подробности мы опускаем.)

2. 2. Необязательный элемент определения по умолчанию (default-definition) указывает значение по умолчанию, которое применяется к каждому столбцу, определенному на домене и не имеющему своего собственного определения значения по умолчанию, записанного в виде "DEFAULT default", где default, в «вою очередь, является литеральным значением, ссылкой к встроенной niladic-функции (например, CURRENT_DATE) или NULL.[15][1]

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

3. 3. Необязательный список определений ограничений доменов (domain-constraint-definition-list) представляет набор ограничений целостности, применяемых к каждому столбцу, основанному на этом домене. Как будет объяснено в последующих главах книги, ограничения целостности доменов концептуально не что иное, как перечисление значений, составляющих домен (по крайней мере, так должно быть). Однако в SQL допускается использование в ограничениях доменов логических выражений произвольной сложности. Мы предлагаем читателю в качестве упражнения поразмышлять о некоторых нежелательных последствиях такой вседозволенности.

Приведем пример определения доена:

Тогда оператор create table для базовой таблицы Р (таблицы деталей) может выглядеть следующим образом:

CREATE TABLE P (..., COLOR COLOR,...);

Если пользователь при вставке строки в таблицу Р не указывает значение столбца COLOR для этой строки, то по умолчанию в эту позицию помещается значение "???". А если пользователь укажет значение COLOR, но это значение не будет принадлежать диапазону допустимых значений, то операция не будет выполнена и система сгенерирует сообщение, в котором упоминается ограничение VALID_COLORS.

Существующий домен можно изменить в любое время с помощью оператора ALTER DOMAIN. В частности, этот оператор позволяет определить для такого домена новое значение по умолчанию (заменяя при этом старое значение, если оно было указано) или удалить существующее. Он также позволяет ввести новое ограничение целостности для данного домена или удалить уже существующее ограничение. Подробное изложение всех этих опций (а они довольно сложны) выходит за рамки этой книги. Интересующийся читатель может обратиться к [8.1, 8.5].

И наконец, существующий домен можно уничтожить с помощью оператора DROP DOMAIN, имеющего следующий синтаксис:

DROP DCMAIN domain option;

Здесь опция option может принимать значения RESTRICT или CASCADE. Общая идея такова: при выборе опции RESTRICT домен не будет уничтожен, если на него будут какие-либо ссылки; при выборе опции cascade операция будет выполнена и "каскадно" продолжена в различных направлениях (например, столбцы, которые были ранее определены на основе этого домена, будут рассматриваться как определенные непосредственно на основе типа данных этого домена). Механизм этой операции достаточно сложен и потому подробности опускаются. Дополнительные сведения можно найти в [8.1,8.5].

Базовые таблицы

Прежде чем обсуждать базовые таблицы, необходимо сделать пару замечаний относительно таблиц SQL вообще. Во-первых, в таблицах SQL, в отличие от настоящих отношений, допустимы идентичные строки, поэтому им не требуется иметь каких-либо потенциальных ключей. Во-вторых, в таблицах SQL, в отличие от настоящих отношений, столбцы рассматриваются в порядке слева направо; например в таблице поставщиков S столбец S# может быть первым столбцом, столбец SNAME — вторым и т.д.

Перейдем непосредственно к базовым таблицам. Базовые таблицы определяются с помощью оператора create table (обратите внимание, что ключевое слово table означает здесь базовую таблицу, то же самое касается и операторов alter table и drop table, которые описываются ниже). Синтаксис выражения следующий:

CREATE TABLE base-table (base-table-element-commalist);

Здесь каждый элемент базовой таблицы (base-table-element) является либо определением столбца (column-definition), либо определением ограничения базовой таблицы (base-table-constraint-definition). Каждое определение столбца (по крайней мере одно такое определение должно выглядеть следующим образом:

column representation [ default-definition ]

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

Существует три вида определений ограничения базовой таблицы:

■ ■ определение потенциального ключа,

■ ■ определение внешнего ключа,

■ ■ определение ''проверочного условия".

Ниже каждое из них обсуждается подробнее.

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

Потенциальные ключи

Определение потенциального ключа записывается в виде.

В обоих случаях список column commalist не должен быть пустым. Для данной базовой таблицы существует не более одной спецификации PRIMARY KEY (первичный ключ) и любое количество спецификаций UNIQUE (альтернативные ключи). В случае первичного ключа для каждого из указанных столбцов дополнительно подразумевается спецификация not null, даже если эта спецификация не указана явно.

Замечание. Применяемые здесь условные обозначения (типа commalist) описывались ранее в этой книге.

Внешние ключи

Определение внешнего ключа записывается следующим образом:

Здесь option принимает значения NO ACTION, CASCADE, или SET CASCADE и SET NULL полностью соответствуют описанным ранее CASCADES и NULLIFIES (если вам необходимо освежить в памяти этот-материал, вернитесь к главе 5); опция NO ACTION, которая устанавливается по умолчанию, идентична описанной ранее RESTRICTED (подробнее см. [8.5]), а опция SET DEFAULT очевидна и говорит сама за себя.

Замечание. Второй список столбцов column-commalist требуется, если внешний ключ ссылается на потенциальный, который не является первичным ключом.

Проверочные условия

Определение проверочного условия (проверочного ограничения) имеет вид:

CHECK (conditional-expression)

Попытка создания строки в базовой таблице В рассматривается как нарушение проверочного условия для таблицы В, если в результате вычисления условного выражения, указанного в этом ограничении, получено значение ложь. Заметьте, что условное выражение может быть сколь угодно сложным; фактически не требуется, чтобы условие ограничения имело ссылки только на таблицу В, оно может иметь ссылки на что угодно в базе данных. В [8.19] предлагаются некоторые критические комментарии относительно такого подхода. Вот пример создания таблицы с помощью оператора create table:

Здесь подразумевается, что домены S#, Р# и QTY уже определены, a S# и Р# явно определены как первичные ключи для таблиц S и Р соответственно. Также здесь умышленно применяется соглашение по сокращению, благодаря которому проверочное условие вида

CHECK (column IS NOT NULL)

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

Далее существующая базовая таблица может быть изменена в любое время с помощью оператора ALTER TABLE..Поддерживаются следующие изменения:

■ ■ добавление новых столбцов;

■ ■ определение для существующего столбца нового значения по умолчанию (заменяющего предыдущее значение, если оно было);

■ ■ удаление для столбца существующего значения по умолчанию;

■ ■ удаление существующего столбца;

■ ■ указание нового ограничения целостности для базовой таблицы;

■ ■ удаление существующего ограничения целостности для базовой таблицы.

Приведем пример лишь для первого случая:

ALTER TABLE S ADD COLUMN DISCOUNT INTEGER DEFAULT -1;

С помощью этого оператора добавляется столбец DISCOUNT (типа INTEGER) в базовой таблице поставщиков S. Все существующие строки в этой таблице расширяются с четырех столбцов до пяти; во всех случаях значение нового пятого столбца равно –1.

И наконец, существующая базовая таблица может быть уничтожена с помощью оператора DROP TABLE, который имеет следующий синтаксис:

DROP TABLE base-table option;

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