Дейт К. Введение в системы баз данных
Подождите немного. Документ загружается.
Аналогичные замечания можно сделать и для операций пересечения и
декартова произведения (но не вычитания). Заметим еще, что операции
объединения, пересечения и декартова произведения (но не вычитания) еще и
коммутативны, т.е. выражения
A UNION В
и
В UNION А
эквивалентны; точно так же и для операций пересечения и
произведения.
Замечание. К вопросу ассоциативности и коммутативности мы вернемся далее в
этой книге. А относительно операции декартова, произведения мимоходом заметим,
что эта операция в теории множеств не является ни, ассоциативной, ни
коммутативной, но ее расширенная версия, как мы определили, и ассоциативна и
коммутативна.
13[1]
Изначально эта операция называлась restrict (дословно — ограничение), но теперь ее чаше
называют select (выборка). Однако это последнее название не совсем удачное, поскольку его легко
перепутать с оператором SELECT в SQL, а это далеко не то же самое. На самом деле оператор
SELECT в SQL гораздо мощнее алгебраической операции restrict— он в основном включает
функциональные возможности всех первоначальных восьми алгебраических операций и еще кое-
что.
B
14[2]
В предыдущих изданиях этой книги, придерживаясь терминологии [6.2], для этого понятия
использовался термин union-compatible (дословно — совместимый для объединения), который
часто встречается в литературе. Причины, побудившие нас предпочесть термин type-compatible
(совместимо по типу), разъясняются далее в этой книге, где также исследуется определение этого
термина (и связанное с этим ослабление довольно строгих терминов для операций объединения,
пересечения и вычитания).
Язык SQL (стр. 222-228)
13
14
Глава 8
Язык SQL
13. 8.1. Введение
Как уже отмечалось ранее, язык 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], в значительной степени пересмотренных в соответствии с
требованиями данной книги. Обратите внимание на следующие отличия:
■ ■BBBBBBB Символ "#", который мы часто используем в именах доменов и столбцов, на
самом деле в стандарте SQL/92 не допустим.
■ ■BBBBBBB Мы используем символ ";" как признак конца оператора, хотя согласно
стандарту SQL/92 этот символ предусмотрен только для встроенного SQL и
только для определенных базовых языков.
■ ■BBBBBBB Мы часто используем названия для синтаксических категорий, которые
отличаются от стандартных названий, потому что терминология стандарта не
всегда подходит для наших целей.
Хотя здесь речь идет только об уровне SQL/92, следует отметить, что ни один
из коммерческих продуктов к моменту написания книги не поддерживал в полной
мере стандарта SQL/92. Те языки, которые обычно поддерживаются продуктами,
можно назвать "надмножествами подмножества" языка SQL/92. Другими словами,
любой данный продукт, не поддерживая некоторых аспектов стандарта, в других
отношениях, возможно, превосходит его. Например, продукт IBM DB2, безусловно,
не поддерживает всех средств SQL/92, касающихся целостности, но он превосходит
стандарт в отношении правил, связанных с обновлением представлений.
И последнее замечание: в SQL используются такие термины, как таблицы,
строки и столбцы вместо реляционных терминов отношение, кортеж и атрибут.
Поэтому для согласованности со стандартом SQL и продуктами, поддерживающими
SQL, мы также будем использовать эти термины в данной главе (и везде, где речь
идет о SQL).
14. 8.2. Определение данных
В этом разделе рассматриваются основные объекты данных и
соответствующие операторы языка определения данных (data definition language —
DDL) в SQL. Основные операторы DDL:
Существуют также операторы для создания и уничтожения ("сбрасывания" —
"dropping") представлений, но обсуждение представлений откладывается до главы
17.
Домены
К сожалению, "домены" в SQL далеки от настоящих реляционных доменов,
описываемых в этой книге; более того, эти два понятия настолько различны, что
желательно было бы для этой конструкции SQL использовать другое название.
Единственная цель доменов в SQL — обеспечить возможность один раз определить
элементарную спецификацию типа данных (такую как "S# CHAR(5)"), а затем
использовать ее одновременно для нескольких столбцов в нескольких базовых
таблицах. Ниже приводится список некоторых основных различий между
настоящими доменами и конструкциями SQL (смысл многих пунктов этого списка
будет разъяснен в последующих главах книги).
■ ■BBBBBBB Как уже отмечалось, на самом деле домены SQL— просто синтаксические
сокращения. Они, несомненно, не относятся к истинному типу данных,
определяемому пользователем.
■ ■BBBBBBB Нет никаких требований, которые применялись бы для доменов SQL:
столбцы в базовых таблицах могут определяться непосредственно в терминах
встроенных типов данных, определяемых системой, таких как FLOAT и
INTEGER.
■ ■BBBBBBB Отсутствует какая-либо поддержка SQL для "доменов доменов". Домен SQL
должен определяться в терминах одного из встроенных типов данных,
определяемых системой, а не в терминах другого домена, определенного
пользователем.
■ ■BBBBBBB Язык SQL не осуществляет строгого контроля типов. Нет никакой проверки
правильности типов. В частности, домены не "ограничивают сравнения" —
единственное требование для сравнений состоит в том, чтобы сравниваемые
операнды были одного и того же базового типа, т.е. оба были или числовыми,
или символьными строками и т.п. Аналогичное замечание применимо и к
числовым выражениям, выражениям с символьными строками и т.д. Во всех
случаях домены как таковые, по существу, ими не являются.
■ ■BBBBBBB Язык SQL не поддерживает возможность определения пользователем
операций, применяемых к данному домену.
■ ■BBBBBBB В языке SQL не делается четкого разграничения между доменом как таковым
(т.е. типом данных, определяемым пользователем) и представлением этого
домена в терминах одного из определяемых системой типов данных.
■ ■BBBBBBB В языке SQL нет никакой концепции подтипов, надтипов или наследования.
■ ■BBBBBBB И наконец, в SQL нет даже поддержки, бесспорно, самого фундаментального
из всех доменов — домена истинностных значений!
Ниже приводится синтаксис для создания домена SQL.
Замечание. Как и в главе 7, квадратные скобки "[" и "]" используются для
указания необязательных элементов, при отсутствии которых будут использованы
значения по умолчанию.
Пояснения:
1. 1.BBBBBBBBBBB Элемент domain — это название создаваемого домена с указанным типом
данных (data-type). В языке SQL поддерживаются приведенные ниже
скалярные типы данных, назначение большинства из которых понятно по
названию. (Также поддерживаются некоторые значения по умолчанию,
сокращения, альтернативные написания, например CHAR для CHARACTER.
Подробности мы опускаем.)
2. 2.BBBBBBBBBBB Необязательный элемент определения по умолчанию (default-definition)
указывает значение по умолчанию, которое применяется к каждому столбцу,
определенному на домене и не имеющему своего собственного определения
значения по умолчанию, записанного в виде "DEFAULT default", где default, в
«вою очередь, является литеральным значением, ссылкой к встроенной niladic-
функции (например, CURRENT_DATE) или NULL.
15[1]
Замечание. Niladic-функцией называется функция, не использующая никаких
аргументов.
3. 3.BBBBBBBBBBB Необязательный список определений ограничений доменов (domain-
constraint-definition-list) представляет набор ограничений
целостности, применяемых к каждому столбцу, основанному на этом домене.
Как будет объяснено в последующих главах книги, ограничения целостности
доменов концептуально не что иное, как перечисление значений, составляющих
15[1]
Подробное обсуждение поддержки пустых значений (называемых нулями) в SQL приводится в
последующих главах книги. Однако случайные ссылки к нулям в этой главе неизбежны.
домен (по крайней мере, так должно быть). Однако в 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 — это "значение по умолчанию,
используемое по умолчанию".
Существует три вида определений ограничения базовой таблицы:
■ ■BBBBBBB определение потенциального ключа,
■ ■BBBBBBB определение внешнего ключа,
■ ■BBBBBBB определение ''проверочного условия".
Ниже каждое из них обсуждается подробнее.
Замечание. Каждому определению может предшествовать инструкция вида
"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. .Поддерживаются следующие изменения:
■ ■BBBBBBB добавление новых столбцов;
■ ■BBBBBBB определение для существующего столбца нового значения по умолчанию
(заменяющего предыдущее значение, если оно было);
■ ■BBBBBBB удаление для столбца существующего значения по умолчанию;
■ ■BBBBBBB удаление существующего столбца;
■ ■BBBBBBB указание нового ограничения целостности для базовой таблицы;
■ ■BBBBBBB удаление существующего ограничения целостности для базовой таблицы.
Приведем пример лишь для первого случая:
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 будет выполнена (таблица будет удалена со всеми ее строками), а
любые определения представлений, которые имеют ссылки на эту таблицу, и
ограничения целостности будут также уничтожены.
Информационная схема
В SQL существует аналог того, что принято называть каталогом, — это
информационная схема. В действительности знакомые нам термины "каталог" и
"схема" используются в SQL, но с весьма специфическими для SQL значениями.
Нестрого говоря, каталог в SQL состоит из дескрипторов для отдельной базы
данных,
16[2]
а схема состоит из дескрипторов той части этой базы данных, которая
относится к некоторому отдельному пользователю. Другими словами, может быть
любое число каталогов, каждый из которых делится на произвольное число схем.
Однако требуется, чтобы каждый каталог содержал ровно одну схему, называемую
INFORMATION_SCHEMA, которая, с точки зрения пользователя, является схемой,
выполняющей функцию обычного "каталога".
Таким образом, информационная схема состоит из набора таблиц SQL,
содержимое которых фактически отражает (точно определенным образом) все
определения из всех остальных схем рассматриваемого каталога. Точнее,
информационная схема согласно определению содержит набор представлений
гипотетической "схемы определения". Для поддержки схемы определения
16[2]
Если быть точным, то необходимо отметить, что в стандарте SQL вообще не существует такого
понятия, как "база данных"! Есть набор данных, который описан определенным каталогом.
Однако неоправданно представлять это как базу данных.
реализации не требуется, но она требуется, во-первых, для поддержки некоторых
видов "схемы определения" и, во-вторых, для поддержки представлений таких
"схем определения", которые имеют вид, подобный информационной схеме.
Необходимо отметить следующие моменты:
1. 1.BBBBBB Смысл формулирования двух отдельных описанных только что требований
заключается в следующем. Существующие продукты, конечно, поддерживают
нечто близкое к "схеме определения". Однако такие "схемы определения"
заметно различаются в разных продуктах (даже если рассматриваемые продукты
имеют одного изготовителя). Поэтому требование, чтобы в реализации
поддерживались предопределенные представления ее "схемы определения",
имеет смысл.
2. 2.BBBBBB На самом деле нужно говорить "одна из информационных схем", а не просто
"информационная схема", так как мы видели, что одна такая схема содержится в
каждом каталоге. Вообще говоря, совокупность данных, доступных конкретному
пользователю, не будет описана с помощью единственной информационной
схемы. Однако, чтобы упростить изложение материала, мы будем продолжать
считать, что в действительности существует только одна схема.
Нет причин вдаваться здесь в детали содержимого информационной схемы.
Просто приведем некоторые наиболее важные представления информационной
схемы в надежде, что сами их названия позволят читателю получить некоторое
понятие о том, из чего состоит схема (однако следует отметить, что представление
TABLES (таблицы) включает информацию обо всех именованных таблицах,
представлениях и базовых таблицах; а представление VIEWS (представления)
содержит информацию, конечно же, только о представлениях). Более сложные
возможности умышленно пропускаются.
17[1]
Подробное обсуждение поддержки пустых значений (называемых нулями) в SQL приводится в
последующих главах книги. Однако случайные ссылки к нулям в этой главе неизбежны.
18[2]
Если быть точным, то необходимо отметить, что в стандарте SQL вообще не существует такого
понятия, как "база данных"! Есть набор данных, который описан определенным каталогом.
Однако неоправданно представлять это как базу данных.
Проектирование базы данных (стр. 269-279)
17
18