Материал: Graber_Martin_-_SQL_dlya_prostykh_smertnykh_-_2014

Приложение F. SQL сегодня

выполнения каждого предложения ДJIЯ определения, что произоrшю при выполнении

предложения. Предусмотрены три возможные ситуации:

•Значение О определяет успешное завершение.

•Значение 100 определяет, что предложение выполнилось правильно, но не про­ извело никаких действий или не создало выходных данных. Например, если нет данных, удовлетворяющих запросу или была попытка удаления строки, кото­ рой нет в таблице, то в процессе выполнения этих команд SQLCODE принима­ ет значение 100.

•Любое отрицательное значение свидетельствует об ошибке.

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

Новый подход заключается в использовании другой переменной, названной SQLSTATE. Это текстовая строка длиной в пять символов со стандартными значения­ ми для различных классов ошибок, ошибочных ситуаций, зависящих от конкретной реализации. Фактически, есть два уровня детализации ошибок: классы и подклассы. Часто сообщение об ошибке будет использовать стандартный класс и соответствую­ щий подкласс. Таким образом стандарт определяет природу ошибки, а подкласс дает более конкретную информацию. Для подклассов стандарта нет, но если класс описы­ вает ошибку адекватно, то подкласс можно опустить (установить в ООО).

В настоящее время стандарт предоставляет собой область диагностики с множест­ вом сообщений и кодов, которые могут иметь место в процессе выполнения единст­ венного предложения. Доступ к ее использованию осуществляется с помощью предложения GET DIAGNOSТICS.

Поддержка динамического SQL. Динамический SQL - код SQL, генерируемый во время выполнения приложений, - специально не поддерживался в старом стандарте, хотя многие продукты используют его до сих пор. Новый стандарт учиты­

вает эту ситуацию. Самой важной характеристикой для поддержки динамического

SQL в стандарте 92 являются динамические курсоры, предложения, генерируемые из строк текста во время выполнения, области диагностики и области описания. Очень

важны также новые возможности связи.

Поддержка для С, ADA и MUMPS. Официальный стандарт 86 поддерживал только основной язык, но не встроенный SQL, хотя и содержал четыре добавления, оп-

366

SQL сегодня

ределяющие встроенный SQL для Pascal, Fortran, COBOL, PL/l. В стандарт 92 добавле­ ны· С, Ada, MUMPS и теперь все языки являются частью официального стандарта.

Домены. Теоретики реляционной модели данных, и среди них E.F.Codd - отец теории реляционных баз данных, стимулируют применение доАtенов (domains), исхо­ дя из того, что тип данных должен определяться более точно, чем это позволяет сде­ лать стандарт множества типов данных. Например, тип номеров телефонов отличается от типа номеров в кодах секретности. Хотя оба типа являются числовы­

ми, не имеет смысла непосредственно сравнивать эти значения, так как они опреде­

лены на различных доменах.

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

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

Утверждения и отсрочка огран11чений. Ограничения - это правила, устанав­

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

следовательно, могли содержать правила, используемые для контроля множества

столбцов таблицы. В обоих случаях ограничения могли быть либо определенного, за­ ранее известного типа, например, NOT NULL или UNIQUE, либо СНЕСК­ ограничениями, позволявшими создателю таблицы генерировать выражения значе­ ний из столбцов. Если выражение принимало значение FALSE, то ограничение не

удовлетворялось и предложение отвергалось.

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

вать основные принципы, которым должны удовлетворять данные, например, кон­

тролировать законность выполнения операций. Утверждения могут создаваться и

удаляться. Можно также размещать ограничения в домене (см. раздел "Домены" дан­ ной главы).

367

Приложение F. SQL сегодня

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

Итак, с целью управления можно задавать до конца транзакции как ограничения, так и утверждения (начиная с этого момента и до конца данного приложения ограничения и

утверждения будут обозначаться одним термином ограничения (constraitions) , если явно не оговорено нечто иное). Это может привести к некоторой неоднозначности. Ог­ раничения проверяются в любом из следующих случаев:

1.После выполнения каждого предложения, воздействующего на таблицу, на кото­

рую есть ссылка в предложении.

2.В конце каждой транзакции, содержащей одно или более предложений, влияю­ щих на содержимое таблиц, на которые они ссылаются.

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

операцию необходимо выполнить.

При определении ограничения устанавливается, должна ли проверка выполняться

непосредственно после выполнения каждого предложения или ее можно отложить до

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

какой режим проверки принимается по умолчанию. Затем, на протяжении выполнения

транзакции он может быть изменен с помощью установки вида ограничений (constraints mode). (Неотсроченные ограничения, по определению, должны проверять­ ся немедленно.) Можно установить способ проверки сразу для всех ограничений или для каждого отдельно. Если установить вид ограничений в значение lmmediate, то они будут проверяться немедленно. Это полезно делать в случаях, упомянутых в пункте 3

приведенного описания процедуры управления.

Существует ряд моментов, которые необходимо учесть в том случае, если ограни­ чения отличаются от рассматриваемых. Например, необходимо иметь две таблицы, в которых внешний ключ первой ссылается на вторую, а внешний ключ второй - на первую. Предположим, каждый внешний ключ содержит ограничение NOT NULL. Следовательно, некоторое значение внешнего ключа представлено в каждой строке любой таблицы любой момент времени. При попытке добавить содержимое какой­ либо таблицы в первую таблицу, необходимо на время отказаться от проверки сохра­ нения целостности, поскольку родительский ключ отсутствует в другой таблице непо­ средствен но после выполнения операции вставки. Это пример цикличности (ciгcиlaгity). Решение должно отличаться от проверки ограничения FOREIGN КЕУ до тех пор, пока не выполнена вставка строк в обе таблицы.

Надо помнить, что если отложить проверку ограничений до конца транзакции,

можно потерять сведения о действиях, которые были выполнены в процессе транзак­

ции. Если детали этого процесса неважны, то можно сохранять последовательность

выполнения всех проверок, а можно выбрать и быстрый режим для нее, не откладывая

до конца транзакции.

368

SQL сегодня

Добавление и удаление объектов. Согласно стандарту SQL 86, однажды соз­

данную таблицу нельзя изменить или удалить. В реальной жизни возникают ситуа­

ции, когда следует изменить содержимое созданной таблицы или вовсе от нее отказаться. Поэтому предложения ALTER ТABLE и DROP ТABLE вошли в стандарт де-факто, наряду с CREATE ТABLE по спецификации OSI. К сожалению эти предло­ жения, из которых наиболее сложным является ALTER, не всегда выполнялись оди­ наково для различных программных продуктов. Однако теперь OSI решил сделать ALTER и DROP частью стандарта.

Можно изменять не только таблицы, но и все объекты: утверждения, домены, схе­ мы, наборы символов, объединения, транзакции и представления. Домены можно и удалять. Изменение доменов эквивалентно изменению значений, принятых по умолча­ нию, добавлению или удалению ограничений. Предложение ALTER TABLE позволяет добавлять, изменять и удалять правила умолчания или ограничения, а также добав­ лять или удалять столбцы.

Отмена и использование привилегий. Привилегии - это то, что дает иденти­ фикатору пользователя право выполнять действия на различных объектах базы дан­ ных. По старому стандарту нельзя было лишиться однажды полученных привилегий. Однако разработчики программных продуктов ввели предложение REVOКE, отме­ няющее привилегии, переданные по команде GRANT. Теперь REVOКE является ча­ стью стандарта SQL 92. Оно относится к чис.1у сложных предложений, прежде всего из-за необходимости прослеживать путь передачи привилегий от одного идентифика­

тора пользователя к другому.

Предложение GRANT можно применять также с привилегией USAGE, чтобы от­ крыть доступ к любому новому из числа возможных объектов схемы: к доменам, объе­ динениям, наборам символов, способам трансляции. USAGE применимо только к этим новым объектам схемы, тогда как другие привилегии относятся только к базовым таблицам и представлениям. INSERT же определено по-новому: оно употребляется те­ перь и со столбцами. ISO предполагает разработать специфицированный на уровне столбца SELECT в следующем стандарте, именно для этого предусмотрено место в Iпfonnation_Schema (информационной_схеме). Но в настоящее время эта заброниро­

ванная в стандарте возможность не используется.

Определенные пользователем наборы символов, сравнения и трансляции. Возможность поддержки разных наборов символов (национальных алфавитов) де­ лает SQL 92 действительно стандартом мирового сообщества. Новый стандарт по­ зволяет разработчикам и пользователям проявлять большую гибкость в определении их собственных наборов символов. Теперь символы не обязаны иметь длину в один байт, как это было принято для символов английского языка, они могут иметь различную длину, но обязательно должны быть упорядочиваемы­ ми. Для них должна быть определена такая последовательность сравнения (упоря­ дочения), при которой предложение типа <символ 1> <<символ 2> может быть оценено либо как "истина", либо как "ложь", при условии, что ни символ 1, ни символ 2 не имеют значения NULL. Обычно сравнение совпадает с алфавитным порядком. В любом случае сравнение может быть переопределено, даже для стан-

369

Приложение F. SQL сегодня

дартных наборов символов. Можно указать свои собственные способы трансля­ ции из одного набора символов в другой. Наборы символов, сравнения и способы трансляции - это объекты схемы и пользователи должны иметь привилегию USAGE для работы с ними.

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

•Дата содержит год, месяц и день.

•Время содержит часы, минуты, секунды и доли секунды.

•Временная метка является комбинацией даты и времени. Метка времени по умолчанию состоит из четырех компонентов, например, 11 :09:48.5839. По умолчанию время не включает долей секунды, но при необходимости они мо­ гут быть указаны. И время, и временная метка :'v!Oryт иметь индикатор зоны вре­

мени, показывающий точность времени относительно универсального

координатора времени (UCT, Universal Coordinated Time).

SQL 92 поддерживает также два типа интервалов (intervals): год-месяц и день­

время. Они используются для фиксации разницы между переменными даты и времени

J.I позволяют представить дату и время в арифметическом виде. Например, если вы­ честь время 2:00 из времени 5:30, получится интервал 3:30 (три с половиной часа). Аналогично, можно взять значение даты "июль 1993 г.", добавить интервал - значе­ ние месяца равно трем - и в результате получить дату "октябрь 1993 г.". Интервалы имеют формат или год-месяц, или день-время, но могут быть представлены не все компоненты года или времени. Реально интервал является арифметическим и работа­ ет так, как будет указано. Существует два типа интервалов, и в общем случае нельзя сказать, сколько дней содержит месяц (это зависит от месяца), т.е. при увеличении зна­

чений дня месяца неизвестно, о каком интервале идет речь и когда можно увеличивать

значение месяца.

Типы двоичных данных. Двоичный тип данных поддерживается не стандар­ том, а некоторыми программными продуктами. Он часто называется типом двоичных данных BLOPs (Biпary Large Objects - большие двоичные объекты) и обычно ис­ пользуется в многоплатформных базах данных для хранения графических изображе­ ний, звуковых данных и т.д. BLOPs полезен также в научных и технических базах

данных.

Существуют два типа двоичных данных: фиксированной и переменной длины. Не­

смотря на то, что на практике чаще нужны данные переменной длины, использование

данных фиксированной длины улучшает работу системы и сокращает необходимый

370